Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise news for all interests
Linux in the news
All in one big page
Here is the permanent site for this page.
See also: last week's LWN.
When is the right time to release free software? Red Hat has taken some grief recently for releasing development versions of the compiler and C library with Red Hat 7. One reason (of many) that has been put forward to explain this decision is that Red Hat is seeking to help stabilize the development of gcc 3.0 by increasing the development version's user base. By increasing the number of testers (also known as "users"), Red Hat 7 will flush out the remaining bugs and provide motivation for the gcc team to get 3.0 out there.
This situation reminds one of the infamous 5.0 release, which was the first mainstream distribution to include glibc2. Then, too, Red Hat justified its action as helping to bring about the stability of the C library.
The interesting thing is: Red Hat is almost certainly right. Until Red Hat 5.0 came out, few people outside the development community had tried to use glibc2. By including glibc2 in Red Hat 5.0, the company increased glibc2's user base by at least an order of magnitude. Those of us using the system can attest that quite a few bugs were found. The library soon stabilized. For a while, anyway.
The lore of free software says that no software is released before its time. By avoiding deadlines, free software developers give themselves the freedom to hold back a release until it is truly solid. That is the source of the extraordinary reliability of free software.
It appears that the lore has left out a step. It seems that the development community can only reach a certain degree of stability; thereafter it's necessary to spring the software on people who are trying to use it to get real work done. Only that level of testing can have a realistic hope of nailing down the last remaining serious bugs.
Thus Red Hat - and its users - may be doing the community a real favor by pushing out software relatively early. The pain suffered by Red Hat users allows all those smug Debian and SuSE administrators to have their rock-solid systems that much sooner.
Part of the dues we pay for our free software is being part of the bug-finding crew. That's just how it works. But an awful lot of people don't get into bug-flushing duty until the software is presented to them as being ready, or nearly so. Development projects are catching on to this dynamic; why else do we have a development kernel called 2.4.0-test9, rather than 2.3.70-something?
Of course, it is not only free software which operates this way. Proprietary software, which rarely comes in development versions, is often even farther away from stability when it is presented to its users. Anybody who attempted to install Solaris 2.0 understands this very well.
Free software users, at least, get their bugs fixed more quickly. Perhaps it would be appropriate to recognize this need for last-round testing more formally and visibly. That would certainly be preferable to surprising users with something that is supposed to be a stable release. In the end, helping get the last bugs out is a pretty small price to pay for the benefits of free software.
The StarOffice source is out. Right on time, Sun released the source for StarOffice - now renamed OpenOffice. There is obviously interest in this release - the download traffic on the first day was such that Sun's server evidently crashed from the load. At this point, a new distribution scheme via Akamai has been set up, and downloads are now fast.
At least, as fast as one could hope for. The source distribution weighs in at almost 80MB (370MB unpacked) - StarOffice was never a lightweight beast. The source consists of almost 35,000 files in over 2100 directories. Even so, it's not the full thing - some of StarOffice was built from third-party code and can not be redistributed under the GPL. These parts include little details like printing and spell checking.
Those wanting to dig into this source will have a daunting task ahead of them. "The source code is not as comprehensively commented as we'd like." says the OpenOffice source overview page in a rather understated way. If you do find comments in the code, they may just turn out to be in German. The build instructions are hard to find (there's no README file), terse, and incorrect. But, more importantly, consider that the code is in rapid and massive development, and the plan is to make major changes (i.e. to turn it all into GNOME components). Sun has a large number of engineers working on the project, and they will likely be the bulk of the developer community for some time.
In other words, OpenOffice looks an awful lot like Mozilla. So it should not surprise anybody if this project takes a very long time to get to its first truly stable release.
Then again, interesting things could happen much sooner. Consider this article on the KDE Dot News site which looks at how OpenOffice might be helpful to KDE - despite the fact that it's supposed to be a GNOME project. It seems the KDE folks see quite a few things that they could snarf out of OpenOffice to improve KOffice; the LGPL licensing of OpenOffice allows them to do that, of course. The end result could be truly ironic: KOffice may push ahead even faster as a result of the OpenOffice release while GNOME goes without a stable office suite for a long time. After all, OpenOffice will be a while until it's ready for prime time, but its release has taken some of the wind from the sails of AbiWord - the previous GNOME office suite project.
Feature Article: Sharing the Dream of Flight. For those of you who add a love of flying to your love of Open Source, we have the perfect present for you: an Open Source project that is working to build the best flight simulator ever seen. The project is called FlightGear. Liz Coolbaugh got a chance to investigate this project at the FlightGear booth during LinuxWorld San Jose 2000. As a result of that contact, we're now extremely pleased to provide you with this feature article about FlightGear, Sharing the Dream of Flight, written by FlightGear developer Alexander Perry.
"The FlightGear project is aiming to achieve "best of breed" by avoiding short-cuts and incorporating the best implementations of each aspect of the simulation. We are using open-source technology to achieve this goal. In fact, what makes the FlightGear project unique is that we are pioneering the use of "Open Source technology" towards improving flight simulation and making it more accessible, more usable, and more affordable than ever before."
Inside this week's Linux Weekly News:
This Week's LWN was brought to you by:
October 19, 2000