Is the 2.6 kernel ready for general distribution?

Mandrake 10 has it, SUSE’s rolling it out in 9.1, Gentoo has had a “test” version with it since last year, and now we’ll probably see almost every commercial distribution move to 2.6.x within the next month or two because of competitive pressure. This is not in line with the basic “it’s ready when it’s ready” dictum that is given as the reason open source software is often technically superior to proprietary competitors.One distribution developer I know feels pressured to come out with a 2.6 version by May 1 at the latest. He believes downloads and sales will suffer if his company’s products lag behind others’.

Why a May 1 deadline? Once again, a business imperative. IT industry sales traditionally slow down during the summer months. In many marketers’ eyes, there’s no point in releasing anything new while people are thinking about vacations, not about buying new hardware or software. They say, “If you can’t have your latest (whatever) on the market soon enough to get a ‘bump’ in sales before summer comes around, you might as well wait until September.”

This is sound marketing logic. It’s also poor logic on the development side of things. Our distro packager friend would just as soon bring out a new release in April based on the 2.4.x kernel and hold off on a 2.6.x version until September or October. He’s a little scared of the rapid rate of change in 2.6 at the moment, and worries that if he grabs the latest version on Monday, Wednesday’s revision will have 10 new features or bugfixes he should have waited for, and that if he keeps changing things he’ll face stacks of small, annoying bugs that will irritate his users.

At the same time, however, users keep asking, “When are you going to come out with a release that uses 2.6?”

Non-commercial distributions like Fedora and Debian are faced with the same challenge: Should they go with a proven kernel or yield to (some) users’ pressure to keep up with the Geckos. Most yield to the pressure. Debian holds off pressure to always have the “latest and greatest” by producing “stable,” “testing,” and “unstable” versions. Debian “unstable” is generally considered at least as stable as most commercial Linux publishers’ latest releases, with “testing” more solid than most, and “stable” Debian the gold standard against which all others must be measured on the reliability front. Fedora has “test” and “core” releases, and Mandrake (which is somewhere on the edge between commercial and noncommercial) has “cooker” and final releases, but the Debian system has proven, over time, to provide the best set of choices for a wide range of users.

If you do a system-wide upgrade in Debian, even from the “unstable” servers, your kernel will not be upgraded to 2.6.x unless you specifically do an apt-get for it in addition to your other upgrades and updates. Debian
“stable” is only up to kernel 2.4.18 — and Debian install images with the venerable 2.2.20 kernel are still available if you want to be ultra-conservative.

Linux is about choice

Some Linux users make their own choices, but a majority let the distribution publishers make kernel choices for them. Nobody questions that the 2.6 kernel offers many advantages over earlier kernels. The only question is whether products that depend on it should be rushed to market or whether prudent Linux distributors should wait before boasting about including the 2.6 kernel in their latest releases.

But it’s hard to stop a 100-kilogram ball when it starts to roll down a steep hill, and the “our latest release includes the latest kernel” ball is moving well over 100 kph and gathering momentum, not slowing.

My distribution developer friend hopes that by the time he’s ready for his next release, probably in mid-April, the 2.6 kernel bugs that worry him will have been corrected. He may have a patch or two of his own to submit in order to hurry the process along, but because of the unscheduled nature of true open source development, he realizes that he’s taking a risk when he bases a major business decision on his anticipation of Linux kernel development speed.

But this is his choice to make, and he’s made it, just as other Linux distribution publishers make choices every day about what (free) software to include or leave out, often based on where they expect that software’s development path to take it by the time their next release is ready.

It could be worse, though. Imagine software development schedules controlled by marketing departments that want to set firm release dates and start new product publicity many months in advance, then release their software as scheduled even if still has glaring flaws. No company that worked this way could survive for long in an environment as competitive as the IT industry — at least not when faced with competition that waits until its code is stable before declaring it ready for widespread use instead of taking a “Ready or not, here I come!” attitude toward product debuts.