[LWN Logo]

Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise news for all interests

 Main page
 Linux in the news
 Linux History
All in one big page

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

 Use LWN headlines
 Advertise here
 Contact us

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.

See also: last week's LWN.

Leading items and editorials

The 2.5 kernel is coming, really, this time. Linus's 2.4.15-pre4 prepatch concluded the process of merging in the "high priority" items from Alan Cox's "ac" kernel series. Among other things, these items include the ext3 journaling filesystem (merged in -pre2). Says Linus: "I'm done with 2.4.x and ready to pass it on to Marcelo [Tosatti]"

This pass has not yet occurred, but there is little sign of any problems with the 2.4.15 prepatch that would prevent it from happening. With luck, both 2.4.15 and 2.5.0 will hit the net in the near future. This long-awaited transition is, perhaps, a good time to look back at how 2.4 development has played out.

This has been the longest period ever without a development kernel. Here's the history:

Stable KernelDevelopment kernel Days
1.0March 3, 19941.1April 6, 1994 34
1.2March 7, 19951.3June 12, 1995 97
2.0June 9, 19962.1September 30, 1996 113
2.2January 26, 19992.3May 11, 1999 105
2.4January 4, 20012.5"any day now" 315

The final "days" figure is still growing as of this writing; it's calculated on November 15. The point, anyway, should be clear: this is, by a factor of three, the longest that Linux has ever been without a development kernel. If one counts the freeze prior to the 2.4.0 release, it is now over a year since there was any place for new kernel code to go.

Of course, things have not been quite that way: quite a few bleeding edge features have found their way into the kernel in the last year. But the following facts remain:

  • Many kernel developers have had no target for new code in a year.
  • The 2.4 kernel has been a very long time in stabilizing.
One could easily argue that both of the above are bad things. Given that conclusion, what can be done to make things work better in the future?

Clearly, one thing to do would be to get a better handle on the development kernel process. Numerous people have said that the number of changes going into a development kernel should be strictly limited, and that the window for adding changes should be short. It would also help if the feature freezes were real: both the 2.1 and 2.3 kernels saw multiple "freezes," and serious changes were still going into the 2.4.0-test series just days before 2.4.0 came out.

Unfortunately, when the 2.5 series starts, there is going to be a major flood of far-reaching, backed up changes trying for inclusion. Very few parts of the kernel will be left untouched. Keeping the 2.5 change list short seems like a battle that has already been lost.

Despite the delays, it seems clear, in retrospect, that 2.4.0 still came out too soon. It only truly began to stabilize after 2.4.10, when the virtual memory subsystem was replaced, and it may be 2.4.18 or so before it is generally recognized as being solid. 2.4.0 should never have been released without a rock-solid VM implementation.

Could it be, though, that the long freezes required to stabilize something as complex as the kernel are self-defeating? By the time the bugs and performance problems are really ironed out, the pressure to add new features and major changes is intense. Linus has not always been able to resist that pressure, and it's unlikely that any other maintainer would do better. A freeze can be sustained for a month or so; to try to keep one in place for six months or a year is asking too much.

Linus has always refused to start a development kernel series until the stable kernel is truly stable. The idea, of course, is to keep the developers focused on fixing things until all the serious bugs are gone. To an extent, that approach certainly works; it's also true, however, that many developers go off making bigger changes anyway, and that some of them get into the "frozen" kernel.

Maybe it is time for the kernel development process to take a cue from the Debian Project. Debian development does not stop when a release is frozen; the development and stabilization processes go on in parallel. Debian is no faster than the kernel at producing new major releases, but those releases, when the finally come, tend to be solid. The continued presence of an unstable release relieves the temptation to throw inappropriate things into the frozen version.

When the time comes to impose a freeze for 2.6 (or 3.0?), the kernel developers may want to give some thought to firing off a 2.7 (or 3.1) shortly thereafter. Rather than pulling developers away from the task of stabilizing the production kernel, a parallel process could help keep them from destabilizing it.

IBM goes into the prebuilt clusters business. IBM has sent out an announcement regarding its new line of "eCluster" servers. IBM has been selling Linux-based clusters for some time, of course; what's different here is that the cluster comes as a single, off-the-shelf package. It's not a cheap package, though: an eight-node "eServer Cluster 1600" will set you back $85,000.

The clusters are made up of eServer x330 and x342 servers - thin, rack-mount boxes with Intel processors. The operating system is Red Hat Linux 7.1. In addition, IBM has ensured that a number of commercial applications are available for its clusters, including high-availability packages, WebSphere, DB2, workload management tools, and transaction processing utilities. There is also a set of bundled cluster management utilities, brought over from the Unix world.

The Linux cluster industry has long shown great promise; how else can anybody get such computing power for so little money? It has been slow to grow up, however. Linux appeals to "do it yourself" types, but even the most independent users can balk at receiving a pallet full of boxes and cables, marked "some assembly required." As the products, management utilities, and applications mature, it is to be expected that cluster adoption will grow tremendously.

Next week's LWN.net Weekly Edition will be published on November 21 - one day early - so that we can get it out of the way and go off to enjoy the (U.S.) Thanksgiving holiday.

Inside this LWN.net weekly edition:

  • Security: A new PhpNuke at last.
  • Kernel: Coding styles; the cost of loadable modules.
  • Distributions: Ranking distributions (DistroWatch); Beehive Linux.
  • Development: Gnome Assistive Technology Projects, milter.org, making RPMs, Evolution 1 rc, Gimp 1.3, XNotesPlus v3.4.0, Anjuta and gIDE merge.
  • Commerce: Covalent launches Enterprise Ready Server; Compaq and OSDN create Clustering Foundry; OSDL announces 2nd Enterprise Achievement Award Contest.
  • History: The dangers of trojan horse software; Digital Creations released the source for Principia; The first LBE at Comdex.
  • Letters: Legal coverage; EULAs, bug reporting.
...plus the usual array of reports, updates, and announcements.

This Week's LWN was brought to you by:

November 15, 2001


Next: Security

Eklektix, Inc. Linux powered! Copyright © 2001 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds