Other stuff:
Daily Updates
Calendar
Linux Stocks Page
Book reviews
Penguin Gallery

Contact us
Archives/search
Use LWN headlines

Recent features:
- RMS Interview
- 2001 Timeline
- O'Reilly Open Source Conference
- OLS 2001
- Gaël Duval
- Kernel Summit
- Singapore Linux Conference
- djbdns

Here is the permanent site for this page.

Leading items and editorials

"While the Windows world is all too accustomed to dealing with delays and vapourware, the Linux camp had until recently enjoyed a fairly regular nine- to 12-month update cycle. But at the current rate of development, Linux 2.4 may not reach final status until October."

Of course, in the usual style, nobody has ever committed to a delivery date for the 2.4 kernel (with the amusing exception of Colin Tenwick of Red Hat Europe, who felt entitled to tell the world that the kernel would be released at the same time as Windows 2000). Nonetheless, Linus has made noises in the past about a Fall 1999 or (later) a Q1 2000 release. Not only has that not happened, but it seems clear that 2.4.0 will not be forthcoming until sometime this summer at best. This kernel is coming out later than its developers had wanted.

It is true that free software projects are often poor at putting out releases in a timely manner. Yet advocates claim speed of development as one of the advantages of free software. As evidenced by the ZDNet article, some members of the press are starting to see an inconsistency here.

The problem - if there is a problem - is not with the speed of development. It is instead with the ability to produce stable releases quickly. New capabilities get developed and bugs get fixed quickly, but it can take a long time to package up those developments for general use. One can think of a few reasons why the stable release process seems to take forever:

• Proprietary software often ships with known bugs, often very serious ones. No self-respecting free software project will package up buggy software as a stable release. High standards are a great thing, but meeting them takes longer.

• Creating a stable release takes a great deal of discipline - the project has to simply stop adding shiny new features for a long time. The 2.3 development kernel has reworked the block and network driver API, added devfs, and thrown in many other features - all after an alleged code freeze. All of the stuff that went in at a late date is worthwhile, but it all delays the stable release.

• Stabilizing software for release involves quite a bit of relatively uninteresting, detailed work. It is probably true that a subset of free software developers have little interest in this kind of work. It is more fun creating exciting, new features, and, after all, the development releases work great for them. Nonetheless, this is probably a minor factor at most.

A more predictable release schedule for important free software components would be nice, but it is hard to imagine many cures to the "problem" that would improve things overall. Imposing deadlines on software development is usually a mistake, and the free software community has been good at avoiding them. Free software ships when it is ready, and that is the way it should be.

Software Carpentry Design Contest finalists. The Software Carpentry contest has announced its finalists that will go to the last round of judging. The contest is trying to spur the development of replacements for some well-known development tools; the entries at this point consist of proposals for new tools. There is no code available - yet.

Three of the finalists in the "Build" category, which is intended to produce a replacement for the venerable "make" program, have taken a similar approach. Rich Miller's PyMake, Steven Knight's sccons, and Tom Tromey's SC Build all turn the traditional makefile into a Python script. Doing things in this way makes the parsing easy, and adds a new type of procedural power and extensibility to the build process; it also turns configuring the build process into a Python programming exercise, which may not appeal to everybody. Sccons adds the concept of "environments," which replace the variable definitions in makefiles; they make it easy to build things in multiple ways, or to define build parameters (flags, installation locations) on a system-wide basis. Sccons also defines "scanner objects" which automate the process of setting up dependencies.

Black by David Ascher and Trent Mick takes a different approach. The makefile becomes an XML data structure defining the system to be built, the rules to use, dependencies, and so on. The authors recognize that "XML is a terrible user interface," however, and have thus specified a graphical interface for Black as well. It includes intelligence that allows it to set up most of the build process automatically; in addition to figuring out dependencies, it can find which source file defines the main program and make a guess at the name of the executable from that.

In the "build configuration" category, two of the entries (BuildConf by Vassilis Virvilis and SapCat by R. Lindsay Todd) have essentially defined an updated version of autoconf. Both of them require the developer to specify how the program is to be built as well, leading to a degree of overlap with the "build" category. Stefan Knappmann's ConfBase, instead, takes the form of a globally-available knowledge base which is used to generate makefiles. It includes an interactive approach, where build "problems" are fed back into the system in an attempt to find a remedy in the knowledge base. Only David Ascher's Tan explicitly addresses the overlap with the "build" category; it is intended to be used along with Black. Thus, like Black, it works off an XML database (explicitly patterned after the Windows registry) which describes system features, available tools, etc.

There are also four entries in the "Track" (problem and issue tracking) category that are worth a look. Four finalists were selected for the "Test" category as well, but the contest organizers have decided not to award a prize in that area for now. Apparently they want to reopen it after reworking the requirements to better inspire the sort of entries they would like to see.

The above descriptions are necessarily overly short; they overlook a number of interesting features in each of the entries. Interested folks are encouraged to look at the actual proposals on the Software Carpentry site.

The Microsoft breakup proposal. There is actually not much to add to the debate on this topic that we have not said in the past. It's worth pointing out, however, that nothing is likely to happen along the lines of a breakup for years. Both sides seem determined to fight until the bitter end, with the result that a lot of time will be spent in the courts. People wanting Office on Linux will have to be patient.

As an aside, another example of the Microsoft way of doing business was passed on to us by Jeremy Allison. It seems that Microsoft has finally made available its "embrace and extend" changes to the Kerberos protocol - sort of. You can only get the information in the form of a self-extracting executable file, which puts up an intimidating "click wrap" license first. It seems that the Kerberos extensions are presented as a trade secret, and can not be passed on - or implemented in open source software. If Microsoft allows others to implement the extensions, it will be via licensing agreements. So much for open standards.

Inside this week's Linux Weekly News:

• Security: SSH 2 support in OpenSSH, a new DDoS tool, this week's security reports.
• Kernel: Resize2fs to be released; a look at the Linux-Mandrake kernel.
• Distributions: Tucows distribution download statistics, Debian test cycle begins.
• Development: Another look at gnucash, miscellaneous development updates.
• Commerce: Gartner's latest, Layoffs at Linuxcare, Andover.Net acquisition changed, VA acquires Precision Insight.
• Back page: Linux links and letters to the editor

This Week's LWN was brought to you by:

• Jonathan Corbet, Executive Editor
• Elizabeth O. Coolbaugh, Managing Editor

Next: Security