Author: JT Smith
Category:
Author: JT Smith
Author: JT Smith
Category:
Author: JT Smith
Author: JT Smith
Author: JT Smith
OpenGL for Java (abbrev.: GL4Java) 2.8.2 maps the complete
OpenGL 1.3 API and the complete GLU 1.2 API to Java and integrates all managment functions, while using the JavaTM-Native-Interface (JNI) and the JDirect-Interface of MS-JVM !
GL4Java uses the native OpenGL library of the underlying operating System !”
Category:
Author: JT Smith
In many ways, 2001 wasn’t a good year for the Open Source and Free Software communities. Many Open Source-related businesses struggled to find working business plans; the U.S. government explored ways to limit the freedom to code; community nemesis Microsoft took all kinds of potshots at Linux and Free Software license; and it looks as though Microsoft will get off with a slap on the wrist for its antitrust violations. But through it all, the community of Open Source/Free Software coders and users continued to thrive and crank out good software.
The year started out with the release of the long-anticipated Linux 2.4 kernel, with its broader support for USB, PCMCIA and, perhaps most important, enterprise server architectures. You couldn’t swing a virtual dead cat last January without hitting a story about what the 2.4 kernel could or couldn’t do.
The enterprise — or big business — focus of the 2.4 kernel probably contributed to some cool things happening during the year, including IBM promoting the heck out of Linux when most Linux companies didn’t have a dime to spare for marketing. IBM’s Linux PR team was busy as a beaver in 2001, cranking out press releases ranging from pre-packaged Linux clusters to a Linux test drive program for small- and medium-sized businesses.
For many other Linux- and Open Source-related businesses, 2001 was not a banner year. Of course, the fate of Open Source businesses wasn’t much different than other tech businesses.
Among the leading Open Source businesses that laid off employees this year: MandrakeSoft, SuSE, Penguin Computing, Caldera, Lineo, and NeTraverse, and that’s only a partial list of names. Several other companies, including high-profile Linux desktop company Eazel, went one step further and closed up shop.
Turbolinux and Linuxcare first announced a merger in February and then called it off in May. Linuxcare then announced layoffs. Turbolinux’s layoffs happened before the merger was called off.
Linux gaming company Loki Software filed for bankruptcy in August but continued to release games.
Then there was the strange case of Corel. The Canadian company had been heavy into Linux until Microsoft invested in the company in 2000. After all kinds of rumors to that effect, Corel sold its Linux unit to a startup called Xandros Corp.
Bucking the trend was French Linux distributor MandrakeSoft, which went public on the EuroNext Marché Libre.
In short, it wasn’t a good year to be an employee at an Open Source company, but then, your job wasn’t safe this year at all kinds of tech giants, including Palm, Sun Microsystems, and Compaq.
The good news, not that stock prices have anything to do with layoffs or company performance as a whole, is that stock prices seem to be rebounding from lows following the Sept. 11 terrorist attacks on the United States. At least investors should be happy with stock performance in the last couple of months.
For example, Red Hat ended the Dec. 31 trading day at 7.10. That’s lower than Red Hat’s 52-week high of 10.125 back in late January, but it’s a heck of a lot better than the 2.40 it posted a couple of weeks after Sept. 11. Of all the companies that experimented with Linux over the past couple of years, Red Hat seems to be the one with the traction — the company actually reported quarterly profits earlier this year, although those ever-present “charges” don’t seem to count.
Caldera seems to be rebounding as well, although its stock is still closer to the 52-week low than the year’s high. Caldera ended Dec. 31 at 0.86, up from a low of 0.22, but down from a high of 4.00 in early 2001.
Borland Software actually peaked for the year this past month at 17.49. Its 52-week low was 5.40, which came in late March, not September. Borland closed the year at 15.66.
Programming freedom, or the lack thereof
If 2001 won’t be remembered as the Year of the Disappearing Open Source business plan, it might be remembered as the Year of the Assault on Online Free Speech.
Under the U.S. Digital Millennium Copyright Act, a lawsuit continued against 2600.com for linking to the DeCSS code, which allows users to copy DVDs and play them on Linux machines. The latest in that case: a U.S. Second Circuit Court of Appeals decision affirming a lower court’s ruling against 2600.com.
A similar lawsuit using California’s trade secret laws progressed against several other Web sites that posted the DeCSS code. This fall, a California appeals court overturned an injunction against posting the code.
Stayed tuned. Neither of those court battles is over yet.
Another case with just as much potential impact is Princeton Professor Ed Felten’s fight against the Secure Digital Music Initiative. Felten and his research crew cracked open the SDMI’s watermarking techniques and then were threatened with a lawsuit under the DMCA if they published the results in a research paper. The good news is that Felten’s team finally presented its research at a USENIX conference in August. The bad news is that a judge dismissed Felten’s case against the music industry, and all kinds of questions remain over the DMCA and its anti-circumvention provisions, which outlaw any technology that circumvents other technology.
The DMCA was even used to arrest Russian programmer Dmitry Sklyarov after he spoke at a U.S. technology convention this summer. Sklyarov created a program that allows users to read Adobe e-Books without buying an Adobe program, and that landed in him jail for months. Sklyarov was released in December, but the legal wrangling involving charges against his company continues. Reports had him released for agreeing to testify against his boss, but he still maintains the innocence of both himself and his employer.
As if the DMCA weren’t enough of a drag on generally accepted good ideas like free speech, Congress is now considering a law that would require anti-copying controls on every piece of hardware — and potentially software — sold in the United States. The Security Systems Standards and Certification Act hasn’t gone anywhere in Congress after being drafted early this fall, but it hasn’t been run out of town, either.
See also, The New York Times’ The Year in Internet Law.
Microsoft vs. Open Source
The boys in Redmond took several shots at the Open Source and Free Software communities this year. As far as we can tell, Microsoft’s main objection seems to the the GNU General Public License, which requires people who build software based on a program released under the GPL to also release their source code. Microsoft seems to confuse that issue with several others, however.
Antitrust? So what?
It appears as though the multi-year U.S. government antitrust case will come to a whimpering end sometime in 2002, with the software giant getting off with a slap on the wrist. It seems like the George W. Bush administration is doing everything it can to settle the case and make it go away, and one of the remedies Microsoft is proposing for itself is giving away a billion dollars worth of software and hardware to schools, what critics say is an attempt by Microsoft to use the settlement to legally monopolize the schools market. Several Open Source companies and educational projects are banding together to fight that proposal.
Meanwhile, nine states that rejected the proposed federal settlement are proposing their own remedies. They’re also accusing Microsoft of delaying the remedy hearings.
The beat goes on
It sounds like a year of bad news, doesn’t it? While Open Source companies laid off people and Microsoft took potshots, developers just kept on cranking out good Open Source software.
Among the hotly debated issues of Open Source software development: Is Linux ready for the desktop?
One computer veteran said no way, based on his experience installing Linux for three friends. Other Linux fans kept hope alive, saying true competition with Windows was just around the corner.
However, some of the most convincing information came in the form of people whose offices or classrooms have switched. Despite continued claims that Linux is too difficult for the average user, the city of Largo, Florida, is using Linux on desktops, and yes, office workers can figure it out. In other places, school kids are using Linux with little problem.
Reviews of the latest releases by major Linux distributions are also getting kudos for their ease of use. Looking for a flavor of Linux that you can use on the desktop? Try Red Hat 7.2, SuSE 7.3 or Mandrake 8.1. A couple of other distributions show promise as well, including Redmond Linux.
The KDE and GNOME desktop environment camps also kept churning out code to make Linux easier to use on the desktop. Dozens of other Open Source projects, too numerous to mention here, also made significant improvements.
In other Linux news, there was some turnover near the top of the kernel team, as Alan Cox turned over maintenance of the 2.4 kernel to Marcelo Tosatti.
Other 2001 wrap-ups
The stats
For all you stats lovers out there: NewsForge published or linked to approximately 13,600 stories in 2001, of which approximately 620 were our original reports. Some of the readers’ favorites over the past year, in case you missed them:
News reporting
Opinions/commentary
Reviews and how-tos
Whew! That’s a lot of good stuff — we hope you enjoyed it. As always, please let us know what we’re doing well and what we could do better. And, oh, Happy New Year!
Category:
Author: JT Smith
Patch against 2.5.1 vanilla is available from: http://www.codemonkey.org.uk/patches/2.5/patch-2.5.1-dj10.diff.bz2 Enjoy, and happy new year, -- Davej. 2.5.1-dj10 o Sync against 2.5.2-pre5 o Remove one of the NFS changes. Better fix in mainline. (Me) o Add switch to enable 486 string copies. (Me) | 486 users please try this out, and give feedback | so we can see how broken this actually is. | It's in the 'kernel hacking' menu. o JFFS2 corruption fix. (David Woodhouse) o Bridging CONFIG_INET cleanup. (Lennert Buytenhek) o Briding recursion bugfix. (Lennert Buytenhek) o Fix up port state handling. (Lennert Buytenhek) o Improved fbdev init. (James Simmons) o PNPOS simple bootflag fix. (Thomas Hood) o Drop most of the USB changes on Greg's request. | Newer versions should appear in -linus soon. | Some bits still remain, but if I've broke it, blame | me and not Greg. o Experimental preload_cache() function. (Me) o Ugly hack to file_read_actor() to use the above (Me) | Just playing, this needs more work.
Category:
Author: JT Smith
1. What happened this past year
2. GNU Bayonne 1.0 Introduction
3. What will Bayonne 1.0 have?
4. What has been dropped in 1.0?
5. What are Olorin and Babylon?
6. GNU Bayonne events in 2002
7. What is next
What happened this past year
Actually quite a bit happened this past year. We went thru two major
releases and with the help of OSDL and others we were finally able to
deliver high density digital telephony services thru GNU Bayonne using
Dialogic hardware.
To make GNU Bayonne more widely used, we had help from Kai
Germaschewski
who did some excellent work getting CAPI 2.0 support to work for
European
ISDN users.
One of the big changes in GNU Bayonne this year had been development of
XML services. These are being carried forward to their logical
conclusion
in the 1.0 release, but we are getting ahead here.
At the start of the year we received the “Best new Enterprise
Application”
award from the Singapore Linux Conference. We have been trying to
live up to this award all year long!
This year I also had been serving as the communities elected
representative to the International Softswitch Consortium. This
actually
involved a bit of travel and resulted in some interesting contacts. It
also perhaps most profoundly effected my decision to finally introduce
as
free software a softswitch application server, Olorin, to compliment
the
GNUCOMM softswitch effort.
Perhaps one of the most interesting and useful things to happen for GNU
Bayonne has been it’s acceptance as a project in OSDL. This has
provided
us with access to enterprise and carrier level hardware to develop and
test GNU Bayonne. This facility has been used somewhat minimally so
far
this year, especially since soon after it’s availability late this year
I
had marched off to work on Bayonne 1.0, but I expect to see much
greater
use of it occur during the next year.
The most important development however has been the increasing
commercial
acceptance of GNU Bayonne. This perhaps is represented in part by it’s
acceptance in OSDL, but also in the use of GNU Bayonne in e-government
by
the State of Maine and similar commercial venues, and by the
demonstration
of a Bayonne based unified messaging product at Linux World in San
Francisco.
However, all these things have been overshadowed by events in December,
leading to the introduction of GNU Bayonne 1.0, and the first
acceptance
of Bayonne by a commercial carrier to deliver various dialtone services
starting next year.
GNU Bayonne 1.0 Introduction
During early 2002 we will be introducing the 1.0 release of GNU
Bayonne.
This release and the ones that will be immediately prior have been
drawn
from an entirely new code base that was created starting in December.
This new code base is used to generate Bayonne, Olorin, and Babylon,
from
a single source package.
The plan for release of GNU Bayonne 1.0 will start with the transfer of
the new code base to public cvs on Savannah. This will be placed under
the “BayonneNG” module name in the Bayonne cvs repository on Savannah,
and should be in place at the time this document is distributed, or on
January 1st.
This new code base is drawn from entirely newly written code. The
entire
server, including class hierarchy, has been reviewed and selectively
re-implemented from scratch over the month of December. Those features
that will be part of a final 1.0 release have been kept, and some
features
have been selectively abandoned.
The initial builds of Bayonne 1.0 will likely be labeled 0.9, and the
first 0.9 release will be distributed around the end of January. In
fact,
it will likely take all of January to bring the new server code to the
point where it is usable in a release. This will be followed by a
final
set of 0.99 releases, and the full 1.0 release of Bayonne, perhaps
around
May, where I hope I may be able to formally introduce it as part of a
GNU
Telephony WiP at SANE in the Netherlands.
The 0.9 release will immediately introduce the new Olorin and Babylon
servers which are also to become a standard part of Bayonne and the 1.0
package release. These servers are still in somewhat preliminary form,
and may not mature until mid-year. Perhaps the “2.0” release of
Bayonne
will include what one might consider to be the actual “1.0” release of
Olorin and Babylon, depending on how progress on testing and
documentation
occur in these two additional servers over the new year.
What will Bayonne 1.0 have?
To better support carrier class services and hardware, Bayonne has been
rewritten to support hot swap (cPCI) services. This allows Bayonne to
take ports or groups of spans selectively out of service into a standby
mode and return resources to the OS.
Perhaps by far the most important part of Bayonne 1.0 is what will
actually be introduced at “GNU/”LinuxWorld in NYC. What I will say of
it
at this time is that it is an entirely new framework for building and
supporting all forms of telephony media devices and that it will
probably
change the way all telephony applications are written in the future for
free operating systems, not just for Bayonne. In fact, the
introduction of this framework was one of the principle reasons for a
complete rewrite of Bayonne to be undertaken at this time.
For testing purposes, it is now possible to execute Bayonne without any
special telephony hardware. A functional “dummy” device exists which
can
simulate hardware behavior and allow applications to be tested and
executed under keyboard control. If the machine has an OSS based sound
card, it will be used to perform audio processing operations on the
local
PC, and hence allow one to simulate behavior of Bayonne applications
and
demonstrate services without any telephony hardware.
Integration of Bayonne with PreViking based Infotel services is also a
major change for the 1.0 release. The Viking Infotel server will be
used
provide standard database access in much the way BayonneDB had been
intended for things like call detail records, for balance lookup on
debit
transactions, etc.
System monitoring thru a tcp port connection will also become a
standard
part of Bayonne 1.0. This will allow both command driven “shell”
access
to the Bayonne server’s internal operation states, and the ability to
create a front-end gui to monitor running servers. Between system
monitoring and the ability to pre-test servers, it should be possible
to
more effectively deploy and debug both applications and running servers
to
the level needed for a commercial network operations center.
The use of XML in Bayonne has been extended for 1.0. Bayonne, Olorin,
and
Babylon will now parse an shared XML based “configuration document”.
This document can either reside on the local file system as a /etc
file,
or it can be fetched from an internal web server during startup. This
should allow one to globally configure a group of Bayonne, Olorin,
and/or
Babylon servers from a central server. Remote fetching of scripts and
voice libraries during startup is also being worked on.
To better support creation of dedicated commodity and embedded
telephony
applications, such as turnkey voice mail systems, it will soon become
possible to compile and build Bayonne servers in a “light” mode which
uses
no XML support. This will be done by constructing a GNU Common C++
library without XML support. I am also looking at generating a further
function reduced GNU Common C++ build that will reduce the footprint of
Bayonne even further when so desired.
Another change is support for user scripting. User scripting enabled
anyone with a login id on a box running a Bayonne, Olorin, or Babylon
server to create and manage their own telephony application service
with
their own prompt library once they are added to the bayonne group by
the
system admin and by assigning number routing to such user services thru
Infotel, such as by DNIS, for example. This is conceptually similar to
how users might create personal web sites on an Apache server by
placing a
public_html folder in their home. This permits one to host telephony
“services” for outside users and easily create a telephony ASP even
without using XML.
Where in the past Bayonne has been distributed without prebuilt sample
applications, this will be changed starting with the 1.0 release.
Currently there are several different groups working on Bayonne
applications for both the current and the 1.0 release series, both in
the
US and abroad. Some of these we expect to demonstrate at
GNU/LinuxWorld
in NYC next month.
Perhaps the greatest single change in the whole project is that the
entire
source tree has been simplified. It is now possible to intelligibly
find
where sources for various parts of Bayonne are without having to go
thru
several directory levels.
FAX support is an interesting question that currently is being
re-visited
in Bayonne 1.0. We have not supported FAX operations in the past
except
in conjunction with Hylafax, but we expect to do so directly sometime
in
the future. I am not sure if FAX support will make it in time for 1.0,
however. It may have to wait for “1.1”.
Finally, GNU Bayonne is absorbing functionality from the PreViking
telephony server. PreViking, along with Infotel, and some other soon
to
be announced things, are GPL licensed telephony related projects that
are
sponsored by Telesave in the UK. Bayonne 1.0 will directly offer
functional services constructed thru scripting that match those
currently
provided by PreViking, including debit calling and answering services,
and
will also offer some additional services related to building of ACD
systems, unified messaging, and hosting of voice commerce.
What has been dropped in 1.0?
I have chosen not to implement the Pika driver for the 1.0 release of
Bayonne. This is due to the fact that the card and software are not
actively maintained for GNU/Linux any longer.
There have also been a lot of odd ways of integrating Bayonne with web
services, including cgi wrappers, and even ssh stuff. All of this
cruft
has been removed. XMLRPC as provided thru the GNUCOMM Apennine server
will become the standard way to interact with a running GNUCOMM
services,
whether from the web or other applications.
I am sure there are enough minor differences to confuse some. In fact,
one of the biggest problems is that the current project documentation
is
already well obsolete, even before the rewrite. Hence, the current
documentation, in effect, is being dropped.
What are Olorin and Babylon?
One of the changes not so visible has been how we restructured the
primary
class hierarchy of Bayonne in the 1.0 series. The most striking change
is
that, like GNU ccScript, the entire processing state engine of GNU
Bayonne
is now represented thru a class extensible state machine that is now
found
in the primary server rather than having to be coded in each and every
driver, as was the case with the past.
This change has made it possible to directly derive alternate servers
out
of the common Bayonne source tree by changing some middle classes. The
result is that we now can build at least three servers out of a common
source package; Bayonne, Olorin, and Babylon. Both Olorin and Babylon
each share many common attributes with Bayonne, but have specific sets
of
functionality that is branched from the main Bayonne tree. Since they
share many of the same server base classes, they can also use the same
plugins.
What Olorin does is provide a Bayonne-like server for next generation
telephone networks. It essentially provides a script driven
application
server that resides on top of a RTP media session stack. To manage
session control, a SIP stack is used in Olorin. Each RTP session has
an
instance of an Olorin interpreter just as each instance of a Bayonne
telephony port has a Bayonne interpreter. The dialects are similar,
though not identical. For example, Olorin provides access to “sdes”
RTP
source info, where such a concept does not exist in Bayonne. Olorin
requires no hardware and operates purely with VoIP telephone networks.
Olorin directly provides both media and application scripting services
in
one server. With Bayonne’s support for XML parsing thru transcoding,
Olorin will act as a XML based softswitch application server.
Babylon is a media-free server that is used to provide pure application
scripting logic for traditional PBX systems. Babylon also differs from
Bayonne in that it provides extra support to implement the TOSI spec
for
third party call control and provides other provisions for standard
switch
integration protocols. Babylon requires drivers that are aware of
native
and sometimes proprietary protocols that are used by PBX systems.
These
are often carried on serial links, and Babylon also can provide a means
of
taking these native protocols and making them network accessible as
well
as script driven. Babylon shares the state model of Bayonne and
Olorin,
where switching equipment often has it’s own call control model,
sometimes
derived from CSTA. This makes Babylon drivers far more complex than
Bayonne ones.
Collectively, Bayonne, Olorin, and Babylon provide application services
in
GNUCOMM for both current and next generation telephone systems. They
also
are to be the foundation of telephony services in GNU Enterprise and
packages that reflect GNU Enterprise modules will also be created as
part
of GNU Bayonne, such as GNU Bayonne Customer Relations Management,
which
will do telephony operations related to that portion of GNUe.
GNU Bayonne Events in 2002
I have been kindly asked by Greg Herlein to run this year’s Telephony
BOF
at next year’s GNU/LinuxWorld in NYC on Thursday night. I also happen
to
be speaking at GNU/LW at the DotGNU panel on Wednesday as I happen to
chair that project, and will generally be around the GNUCOMM booth in
the
.org pavilion where I and others will be demonstrating GNU Bayonne old
and new, and the “other” thing that should be introduced then.
In May I currently hope to return to the Netherlands to give a BoF
and/or
WiP on GNU Telephony and GNUCOMM as a whole at next year’s SANE
conference, as that should be the right time to distribute the final
Bayonne 1.0 release.
In July I expect to be back in France to speak at next year’s LSM
event,
to be held in the second or third week of July at the University of
Bordeaux. I expect it is likely I will be speaking both about GNU
Bayonne
and DotGNU, as we will have a gathering of the DotGNU steering
committee
during the LSM.
What is next
Now that GNU Bayonne is getting close to 1.0, we can start looking to
where we wish to take telephony application services in the future with
free software. In this sense, three projects will become ever
more intermingled with the future of GNU Bayonne; the GNU project
itself
as a whole, phpGroupWare and by extension DotGNU, and GNU Enterprise.
The role of GNU Enterprise and GNU Bayonne had been addressed before,
when
Bayonne replaced the EWOK component of GNU Enterprise. This role will
become more important as we focus more on delivering applications with
GNU
Bayonne. We do intend to deliver applications that are integral with
those of GNU Enterprise where GNU Enterprise requires telephony
services,
as well as providing general enterprise level telephony application
services.
phpGroupWare represents how we wish to make GNU Bayonne usable as part
of
everyday life for the enterprise worker. By enabling XMLRPC support
thru
Apennine and it’s future decedent, we expend to enable things like
having
the phpGroupWare address book dial out to people using Bayonne,
Babylon,
or Olorin, depending on the user’s enterprise environment. Another big
area left to be explored is delivery of unified web based messaging and
GNU Bayonne voice mail thru phpGroupWare.
Finally, GNU Bayonne is, of course, part of the GNU project. This
means
we should work better as a natural part of GNU, and look at ways that
other parts of GNU can work with GNU Bayonne. Supporting guile for TGI
applications is one way we can do this. Supporting pnet as part of GNU
Bayonne is another way, and we do expect to provide a pnetlib framework
for providing telephony enabled web services as an effort related to
GNU
Bayonne.
Our mission in GNUCOMM as a whole is to provide and standardize
telephony
services for the individual user, for the enterprise, and for
commercial
carriers, under free software. For this reason, GNU Bayonne will
continue
to evolve as the standard telephony application services platform of
the
GNU project.
Any questions or comments can be addressed to David Sugar
sugar@gnu.org.
Author: JT Smith
Category:
