![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/main.png)
|
|
|
Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise
news for all interests
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Linux History Letters All in one big page
Other LWN stuff:
Archives/search
Recent features: Here is the permanent site for this page. See also: last week's LWN.
|
Leading items and editorialsThe 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:
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:
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:
This Week's LWN was brought to you by:
|
November 15, 2001
| ||||||||||||||||||||||||||||||||||
Copyright © 2001
Eklektix, Inc., all rights reserved
Next: Security