Linux Kernel Release Numbering Revisited

An anonymous reader writes "KernelTrap has a summary of a lengthy discussion on the Linux kernel mailing list, in which Linus Torvalds has suggested using an alternative numbering scheme for kernel development. The current 2.6 kernel has been different than older development trees, as active development has been happening at a rapid rate in the officially "stable" kernel, instead of forking the expected 2.7 "development branch" for this effort. In Linus' latest proposal, he suggests using the same odd and even arrangement where an odd number signifies a development release, and an even number signifies a stable release. The difference being that this will all happen under 2.6 and thus at a much more rapid rate. For example, the upcoming 2.6.12 release would focus on fixing bugs and thus be more stable, while the following 2.6.13 release would include new functionality and thus could be less stable."

Comments

suggestion

[Arctic Dragon]

Just call the next kernel Linux XP. Worked for Microsoft!

Re:suggestion

[Anonymous Coward]

133t windows users refer to it as 5.1.2600

Then they point out it's clearly a number greater than 2.6.11

Re:suggestion

[Anonymous Coward]

or just call it Linux 3.1!!!!!111oneone

LOLOLOL OMG UR so FUNNY! R U on MySpace!?

that's what -rcX is for

[rsw]

Why not add new functionality in release candidates, and only make it an official release once it's stable?

-rsw

Re:that's what -rcX is for

[Anonymous Coward]

Why not just state the obvious?

Re:that's what -rcX is for

[SpaceLifeForm]

Because there is too much changing too quickly.

Basically, problems are found that need to be fixed before new functionality that is in an RC has really been tested.

If you want a stable kernel that you don't have time to mess with every week, then stick to the 2.4.x series.

Re:that's what -rcX is for

[aneroid]

lol

Re:that's what -rcX is for

[Shulai]

Stable kernels is what Stable series used to be about.
Who cares if changes are quickly in the stable branch if the branch really is unstable and never stabilizes?
This just means you can't use a vanilla Linux kernel. You are forced to use patched kernels from large distros (those endorsing OSDL??), and hope they _really_ do their job, or stick with 2.4...
I'm not against short release cycles. But kernels won't be nearly as stable as they become in earlier stable branches... 2.2.16 or 2.4.18 were rock solid kernels... I don't expect 2.6.18 to have anything near the quality of these.
For short release cycles, use TWO branches again, number them anyway you like, but do them short, and let the stable branch stabilize without putting immediately another bunch of breakages on it.

2.7?

[JVert]

Does this mean there will be no 2.7? or 2.7 will be based on an odd minor version of 2.6? confused and I cant read it again cause all I see is this: .x.x: Linus went crazy, broke absolutely _everything_, and rewrote
the kernel to be a microkernel using a special message-passing version
of Visual Basic. (timeframe: "we expect that he will be released from
the mental institution in a decade or two").

Re:2.7?

[SunFan]

Well, perhaps Linux is maturing enough where it could be 2.6 forever. Solaris has had the SunOS 5.X kernels for a decade or so, now.

This would be a good thing, IMO. A mature base is necessary to really tackle Windows in the years ahead.

Re:2.7?

[Aeiri]

Well, perhaps Linux is maturing enough where it could be 2.6 forever.

That's like saying, back in 1996 or so, that Windows 95 is mature enough that we don't need any new operating systems.

There is always room for improvement, new ideas, new architectures, hardware, etc that open up new pathways to more flexible or secure operating system organization.

For the grandparent, it was announced back when 2.6.1 or so was released that there would be no 2.7.x. 2.6.x would be used as development releases, however there would be no official "stable" version, the distributions had to decide which were stable enough for their OSes. I think this was a huge mistake, but the old method wasn't much better. Linus' new proposal fixes pretty much everything that was wrong with the labelling in my opinion.

Re:2.7?

[TopSpin]

Where is 2.7? I'd like to know this too.

I read in a recent Linus interview that he is waiting for all major distributions to move to 2.6. How is that suppose to happen if 2.6 is where all development is happening? Wouldn't handing 2.6 off to the Alan Cox's of the Linux world where development is restricted to "fixes" be a better way to encourage the distribution vendors to move, as it has for the all previous "stable" kernels? Distribution vendors are always one release behind the development kernel, and this is as it should be.

I fail to understand...

Re:2.7?

[Jussi K. Kojootti]

It's explained right there in the blurb: 2.6.even is supposed to be the stable kernel, the one Distro vendors will use. 2.6.odd is the version with new features.

It's the same as before, just on a more rapid cycle.

Re:2.7?

[superpulpsicle]

I swear not every kernel is suitable with every distro. We need to start calling the source 2.6.x.x_redhat, 2.6.x.x_debian or something.

Re:2.7?

[Gherald]

Uhm, that is done already. For intance, gentoo calls its kernels "linux-2.6.x-gentoo-rx"

Re:2.7?

[kbielefe]

I swear not every kernel is suitable with every distro.

Exactly why Linus thought the lack of a 2.7 kernel series would work out. Every distro applies their chosen set of patches to the vanilla kernel, uses their own specific configuration, and does their own testing. Gentoo x86 users can choose from about 10 different kernels, all with the same version number. I'm sure he was thinking that if he didn't do a stable kernel, that the distros would.

Rolling your own stable kernel isn't that hard to do, especially with the resources of a distro. In fact, since one man's stable is another man's unstable, it is probably the only way to make sure that it is stable for you, which is what's important.

I maintain 3 kernels for myself: a stable, medium, and unstable. The stable kernel is a 2.4.20 with only security patches applied. (2.4.21 broke some commercial software that I use occasionally). My unstable is the latest 2.6 release. The medium is a couple of 2.6 releases back, with only security patches applied. My wife uses medium all the time. I use medium when doing something important and unstable otherwise. Once I have used an unstable kernel long enough without problems, it becomes my new medium kernel and the cycle continues.

Interestingly, the last three 2.6 releases have failed to become my medium kernel because of instabilities. Perhaps enough people are having similar experiences to prompt the rethink in process? I personally think the proposal would be an excellent compromise, and would actually fit better with how other open source projects are run.

Re:2.7?

[greppling]

Well, perhaps Linux is maturing enough where it could be 2.6 forever.

There is always room for improvement, new ideas, new architectures, hardware, etc that open up new pathways to more flexible or secure operating system organization.

What you are missing that the linux kernel development process has matured quite a lot. Now there is a steady stream of new features into 2.6. There is no backlog of huge patches that introduce new features and are available only in vendor kernels.

I wouldn't bet a lot of money on it, but I wouldn't be surprised if the current kernel in 5 years was 2.6.xx (which still would look completely different to current 2.6.11).

Re:2.7?

[physx]

It's hard to argue against "improvement, new ideas, new architectures, hardware, etc" but I'll toss one thing in: we are talking about the kernel here, and not the whole system.

That's why I would disagree with the Windows 95 comparison (not the only reason ;) ). Looking at the GNU/Linux system, yeah- there's room for improvement, new ideas, etc., but in a different way than for the kernel.

Linus himself has said in interviews that he sees the kernel overall as becoming more stable, and that the next big revolutionary type stuff wouldn't be in the kernel, but in the other stuff (like apps).

Still, I'd agree that (on the whole) some difference between the dev and stable kernels makes sense. I'd just wonder though--when would changes under this scheme get big enough to warrant a big number shift (ie-> 2.7)?

Re:2.7?

[stevesliva]

Can I get this kernel thing from Windows Update? I want to make sure my computer is patched. Thanks!

Re:2.7?

[Zork the Almighty]

For the grandparent, it was announced back when 2.6.1 or so was released that there would be no 2.7.x. 2.6.x would be used as development releases, however there would be no official "stable" version, the distributions had to decide which were stable enough for their OSes.

So, how long until Linus admits that this was a mistake ? It was the right decision initially, and I think the 2.6 kernel is better now for it, but it's not feasible in the long run. People want a stable branch, especially if this kernel is going to last 5+ years. It is ridiculous (please people, note the spelling of this word!) to have no official stable version for that period of time. It will only complicate things and slow Linux adoption. I think we are seeing the beginnings of that already.

Re:2.7?

[BinLadenMyHero]

Well, perhaps Linux is maturing enough where it could be 2.6 forever.

Only if Linux had a fixed goal, and it's not the case. Like TeX, that does what it does and that's it: it's perfect, nothing more to envolve. It's version number is converging to "pi", and is now 3.14159 IIRC. Each release adds a new digit. :)

Re:2.7?

[drinkypoo]

I think this is a big mistake. It changes the meaning of the numbering scheme to no useful end. There is no good reason that we should not have separate stable and development branches. There are many good reasons why such a division should exist, however.

One thing I am not clear on is how the backported features are tested. Are they just someone's patchset until the bugs are worked out, or are they backported to the development release before the release you're updating and tested before the stable release is incremented? In such a scenario, the old unstable release would have to be a fork of the stable release you're updating - which seems reasonable enough to me, but might give some people fits.

Where's the document I can read about how this all works now, and how it has worked in the past? I slept through all of it (using Linux for one thing or another all the while) because I've always tried not to get involved with anything other than use and occasional advocacy.

Re:2.7?

[spudgun]

Every distro applies their chosen set of patches to the vanilla kernel, uses their own specific configuration, and does their own testing.

Slackware doesn't
I don't

I make my servers with 2.6.x and mostly slackware.
I really do wish Linus would atleast put out a 2.6.11u on an "unstable" kernel , and then 2.6.12 for a "stable" one. - telegraph it for the stupid out there.

( am I the only one missing out on LKML since ECN was turned on )

Re:2.7?

[BrokenHalo]

I've generally found the current 2.6 series to be reasonably solid, but I can't say I've been entirely happy with the way development has happened over the hast few "stable" releases.

I've had a policy of using mainstream brand-name hardware components for some years for ease of configuration, but using "make oldconfig" on a basis of a known-to-be-good .config file has left me with devices not working (properly) with 2.6.8, 2.6.8.1 and 2.6.10. However, 2.6.5, 2.6.7 and 2.6.9 all worked fine. I was beginning to wonder if someone had adopted an ODD_VERSION_NUMBER==unstable policy without telling anybody...

Re:2.7?

[BrokenHalo]

I appear to have an underdeveloped proofreading gland; that should have been ODD_VERSION_NUMBER==stable.

Re:2.7?

[Anonymous Coward]

Every distro applies their chosen set of patches to the vanilla kernel, uses their own specific configuration, and does their own testing.

"its chosen set", "its own specific", "its own testing". ("Every" is singular.)

Re:2.7?

[ArbitraryConstant]

"Well, perhaps Linux is maturing enough where it could be 2.6 forever."

If that were true, my CD drive would work.

Not a troll: libata doesn't work for PATA drives, but my kernel uses it anyway and reports the CD drive as not supported. Ultimately it proved easier to add a spare Promise ATA card than to fix the problem.

I've had plenty of problems like this with 2.6, but Linux wouldn't be acceptable as a desktop OS to me without the responsiveness of 2.6. It's the best alternative because Linux has better reliability/security than Windows and better desktop software support than BSD.

But there's no way I'd let a Linux 2.6 system touch a server. None of the distros that care about stability will touch 2.6 (Debian, Slackware, etc). If I couldn't use OpenBSD, those are the only Linuxes I would touch.

It's annoying because Linux 2.4 getting pretty long in tooth. This obsession with new features is keeping the kernel that already has lots of good features from being usable.

Re:2.7?

[SunFan]

"But there's no way I'd let a Linux 2.6 system touch a server. None of the distros that care about stability will touch 2.6 (Debian, Slackware, etc). If I couldn't use OpenBSD, those are the only Linuxes I would touch.

It's annoying because Linux 2.4 getting pretty long in tooth. This obsession with new features is keeping the kernel that already has lots of good features from being usable."

This is why you should be using Solaris 10 on your servers ;)

Re:2.7?

[ArbitraryConstant]

"This is why you should be using Solaris 10 on your servers ;)"

hehe :)

Well no matter how new it is, I'd trust Solaris to stabalize over time. The issue with Linux is that it's as bad now as it was when 2.6.0 was released.

So that's why

[Anonymous Coward]

2.6.11 crashed. Damn ;P

Re:So that's why

[haplo21112]

Yeah I have been having nothing but problems with 2.6.11...several things are just not functioning right currently....

This would be helpful

[SunFan]

One thing hurting Linux' credibility is that it is hard to predict volatility in it. If it works out that I would know to avoid odd 2.6.x releases, that would be very helpful.

People want everything, so obviously it's difficult to balance development against stability. This is one area where Solaris has an edge, where even though it takes longer from something to get into the commercial release, at least someone took a look at it before putting it there. Only now has GNOME made it officially into Solaris 10, but there are few issues with it, which is nice.

Re:This would be helpful

[Anonymous Coward]

What's wrong with 2.4?

where even though it takes longer from something to get into the commercial release

Well, wait a little longer for a stable 2.6 and stick with 2.4. Seriously, what's wrong with 2.4 again? If you're willing to wait for SUN's releases, why don't you do the same for linux?

Re:This would be helpful

[SunFan]

What's wrong with 2.4?

Nothing, it's just that in the most recent kernels, they are being versioned as "stable" when some people find they are not. It's a matter of what the label says and what's actually in the can.

Re:This would be helpful

[Otter]

It's a matter of what the label says and what's actually in the can.

Yeah, but for that very reason, why would the situation be any better under the new numbering scheme?

The real answer, I think, is that the best path to stability is to trust the maintainer of your favorite distro. The way Linux development works, following kernels instead of distribution updates is always going to have disasters every so often.

why does it matter?

[capoccia]

why does it matter what the versioning scheme is?

Re:why does it matter?

[wizbit]

Because Linus appoints release managers for each kernel version, and if he gets to keep Andrew Morton around a little longer so they can keep working together on it, he'd like to.

At least, that's how I see it.

Re:why does it matter?

[kbielefe]

It isn't just a question of what to label the kernels, it is mostly about how they are developed. Maintaining software is a constant cycle of adding features, which unavoidably introduce bugs (creating instability), which are then fixed (adding stability). Since open source software is used as it is developed, the timing of each part of that cycle can make a big difference to the user.

Right now each kernel developer is going through that cycle at their own rate. At any given time, some developers are in the unstable half of the cycle and some are in the stable half, resulting in reduced stability overall. Linus is just trying to synchronize everyone to the same phase in a much faster cycle than 2.4-2.5-2.6 was in order to try to get the best of both worlds.

Re:why does it matter?

[MikeCapone]

why does it matter what the versioning scheme is?

What it is; not so important.

People knowing what it is and agreeing on what it should be; yeah, that's pretty important.

what's the point?

[Suppafly]

Do they not want to have a 2.7, does it really need to stay at some version of 2.6.x.x.x forever?

Re:what's the point?

[wild_berry]

Should some major reworking of the guts of the kernel break a lot of stuff, which in turn requires a lot of fixing, then there will be a 2.7 developmental fork to tidy up this and to ease the adoption of the newer systems stuffed into the kernel. It's also possible that 2.6.all.your.base.are.belong.to.us will be renamed 2.7 or 2.8 to simplify the numbers.

At the moment, there aren't a great number of changes to major kernel architecture -- or at least changes which damage the way other stuff works -- so as to need a new minor (2.blah.x) version number. There is a great speed to the current spate of fixing and including stuff, but too few people testing the newer features.

I wonder if this process will be harmful to testing, should most home users (or their distributions) stick to an 2.6.even kernel for the sake of stability.

I have a much better idea.

[jd]

Let's have two testing phases. Phase 1, the -dev part of the cycle, would be where you have all of the development, adding of new features, breaking of random drivers, etc. Phase 1 finishes when Andrew Morton passes out from shock because all the usable code from his patches has been integrated in the official kernel.

Phase 2, the -pre part of the cycle, would be where you have the stabilization and verification. It would be less a soft freeze and more a slushy, but the idea is to make sure everything works. Phase 2 finishes when Linus Torvalds is bodily hauled out of the computer room to play five-dimensional scrabble with his kids.

What you'd end up with is a release that is reasonably stable, AND YET developers would still get to increase the pace of development. You can have it both ways, provided you keep things in sync.

Re:I have a much better idea.

[dubious9]

Except the problem is that distro maintainers will never include an dev kernel as the default choice. Most end users, especially businesses, don't want any part of a dev kernel. And I don't really understand how your version is different than the old major.even-stable/major.old-dev model.

I find that less people will use the dev branch and it'll in turn get less testing. Therefore development slows down for stabilities sake. Thus having a labeled dev branch slows development.

What I think Linus was thinking for the 2.6 kernel is as follows. Linux was approaching a level of stability that the latest vinilla kernel will be called stable and still be developed on. Problems will get flushed out sooner because more people are using the latest snapshot. If distros want more stability, they can lag four or five versions back + security fixes. I thought it was the best of both worlds.

Now that he's decided to label dev and stable versions again, it brings back some of the problems, but here the time between stable and dev kernels should be significantly shorter. 2.6.12 and 14 will come out a heck of a lot faster than, say, the time difference between 2.4 and 2.6.

Thus people get their vaunted labels and development features get tested more widely. Distros can ship with the latest they fell comfortable with. Thus we, presumably, get the same stability with the addition of faster development.

It may not work out this way, but I think it's a great idea.

Re:I have a much better idea.

[Mornelithe]

I believe he was suggesting that instead of:

2.6.(2n+1) == add features
2.6.(2n) == stabilize

We instead do:

2.6.n-devK == add features
2.6.n-preK == fix bugs
2.6.n == fairly stable

I get the Linux kernel mailing list delivered to my inbox, and although I don't read it thoroughly, it does seem that there isn't a lot of "only fix bugs" time before a kernel is released. There are even changes between the final "release candidate" and the final version (when generally, a release candidate is a version that you put out there, and see if there are any bugs, and if not, then it becomes the final version, with no changes in between).

You don't need separate minor or even patch versions to have alternating development and bug fixing. However, that's not how Linux seems to work currently.

Re:I have a much better idea.

[Spy Hunter]

The problem with your approach is that phase 1 will never end, and nobody will want to work on phase 2. Andrew Morton's not going to stop writing patches, and neither is anyone else. You've gotta cut the updates off sometime if you want to release within our lifetimes. This means that some good code won't make it in, but it isn't the end of the world if the release cycle is short enough; you can just add it next cycle and it will be in a stable released kernel in a month or two.

If you look at Linus's proposal, it's just your idea with short release cycles. He gives an odd version number to the end of your "Phase 1" and an even one to the end of your "Phase 2". It sounds like an excellent proposal to me.

Bigger!

[mrbaggs]

They should just put the version numbers up really high. Everything with a high number is popular. Maybe put an XL or a GT on the end for good measure.

I like it

[LordNimon]

The problem with major development trees like 2.4.x vs 2.5.x was that the release cycles were too long, and that people hated the back- and forward-porting.

This is my #1 complaint with the Linux version numbering scheme as it is now. Basically, the version number means nothing. Features are being back-ported to older releases, so that you have "feature gaps" in the releases. For instance, a new feature that was introduced in 2.6.5 could be ported to 2.4.20. What that means is that this feature would exist in versions 2.4.20 through 2.4.29, and 2.6.5 through 2.6.11, but not in 2.6.0 through 2.6.4. The current numbering scheme makes this kind of behavior too tempting.

I would love to see an end to back-porting of features, from both Linus and the distributions.

Re:I like it

[Compenguin]

This isn't such an issue if yoyu were migrating from 2.4.20-29 you wouldn't go to 2.6.0-7 you'd go for 8/9/10/11. Thre really isn't a feature gap because even though 2.6.0 is bigger than 2.4.29 it is from a parrellel branch. It was released much earlier than 2.4.29. You really shouldn't be going to a kernel that is significantly chronologiclly older. 2.4.29 is there for people who can't don't want to migrate to 2.6 series kernels. It would be much more chaotic and dangerous to drop the old kernel series as soon as a new one is released. Furthermore, 99% of backports are bug fixes and drivers.

Re:I like it

[LordNimon]

What if you're writing a driver that needs to support all 2.4 and 2.6 kernels?

Re:I like it

[Creepy Crawler]

Well, its the positive aspect of Open SOurce under GPL.

Pay somebody who does Linux kernel programming (not cutting teeth on mm or somesuch) to write it for you.

Re:I like it

[LordNimon]

I don't need to pay someone else to do my job. What I would like is to have kernel development make more sense, so that I don't have to go through so many hoops to get my drivers to compile.

Re:I like it

[snorklewacker]

Features are being back-ported to older releases, so that you have "feature gaps" in the releases. For instance, a new feature that was introduced in 2.6.5 could be ported to 2.4.20. What that means is that this feature would exist in versions 2.4.20 through 2.4.29, and 2.6.5 through 2.6.11, but not in 2.6.0 through 2.6.4. The current numbering scheme makes this kind of behavior too tempting.

FreeBSD fixed this problem by using build dates for its patchlevels. If Linux used this scheme, you could have a 2.4-20050215 and 2.6-20040605 and you know the 2.4 kernel is more recently modified. Patchlevel numbers by themself are useless.

They also don't go crazy on the STABLE branch with experimental features either, so backports are done for stuff that's actually necessary.

I don't expect Linus to adopt anything sane like that though ... he seems too enamored of his current idea of adding even MORE churn to the stable kernels, distancing vendors even more from the original branch. Redhat 2.4 kernels are practically an all-out fork nowadays.

Re:I like it

[Compenguin]

Although its nice to say that your driver supports all 2.4 and 2.6 kernels, the trewth is that the driver doesn't need to support the oldest kernels of a stable series. Furthermore, if the kernel team hadn't backported the feature you want the driver would only work with 2.6 kernels period. So at least you have some 2.4 compatibilty.

Re:I like it

[Anonymous Coward]

That's the point. Version numbers *should* be chronological, or they serve no real purpose.

Re:I like it

[LordNimon]

A lot of the back-ported features are just renaming functions or replacing them with some equivalents. In other words, you don't get any new capability, but you have to change your code anyway.

And yes, my driver DOES need to support the oldest kernels of a stable series. Our customers use a wide variety of 2.4 and 2.6 kernels.

Re:I like it

[Compenguin]

$ grep -i backport ChangeLog-2.4.29
o [SCTP] Remove sk_xxx macros to be consistent with the rest of networking cod
e and to avoid backporting issues.
o [NETFILTER]: Backport fixes for ip6t_LOG
o [NETFILTER]: Backport fixes for ip6t_dst
o [NETFILTER]: Backport fixes for ip6t_eui64
o [NETFILTER]: Backport fixes for ip6t_frag
o [NETFILTER]: Backport fixes for ip6t_hbh
o [NETFILTER]: Backport fixes for ip6t_ipv6header
o [NETFILTER]: Backport fixes for ip6t_multiport
o [NETFILTER]: Backport fixes for ip6t_rt
o [NETFILTER]: Backport fixes for ip6tables
o Backport of 2.6 fix to insert_vm_struct to make it return an error rather th
an BUG()
o backport v2.6: Fix pty race condition
o Jason Baron: Backport v2.6 tty/ldisc locking fixes
o backport v2.6 fork/thread file descriptor race fix
o Tigran Aivazian: backport sigmatch() issue in microcode.c
o backport v2.6 largefile isofs fix
o [NETLINK]: Backport pid hashing changes from 2.6
o [libata] fix minor 2.6 backport problems
o Backport of the 0.30 forcedeth driver to 2.4. It's a new backport, starting
from the 2.6 tree.
o Task name handling static copy v2.6 backport
o ricoh.h, mem0 wrong definition v2.6 backport
o DAC960 firmware/alpha backport from 2.6
o intermezzo, backport some fixes from 2.6
o intermezzo, backport some more fixes from 2.6

So which of these are break your driver?

And your customers shouldn't be using early 2.4/2.6 kernels because they have bugs and flaws up the wazoo, unless they themselves are guilty of backporting

Re:I like it

[Anonymous Coward]

Oh! What a surprise. An uninformed FreeBSD zealot making a random attack on Linux.

Let me set a few things straight for you: first, vendors are by far the biggest consumers of kernel.org kernels. Second, this new style of continual development is precisely aimed to satisfy vendors and keep in synch with them. The RedHat 2.4 kernel is an all-out fork precisely because the 2.4 tree became outdated too quickly for RedHat after it went stable.

Re:I like it

[snorklewacker]

> Oh! What a surprise. An uninformed FreeBSD zealot making a random attack on Linux.

I run several flavors of Linux and currently zero of BSD (there's a NetBSD box kicking around here, but it's not mine). I just call them as I see them. I guess Linux has to defend itself against the notion of TIME now, as Linus's numbering scheme is so unimpeachably good, anything that FreeBSD does is zealotry.

So let me get this straight: you think that revving the kernels FASTER is going to make any existing point-in-time version MORE up to date? Golly.

This is good

[Anonymous Coward]

This would be a good idea. I compiled 2.6.11 this morning on my laptop, and the alsa nm256 driver locks up the machine on boot :(. This has been happening on and off for some time. I found patches in the module developer's cvs that helped me fix it in 2.6.10, but apparently these didn't make it into 2.6.11 (or it got broken in some other way).

2.6 is great and there are lots of great new features and development in the kernel. But it would be good if some dot releases were only bugfix releases because right now I think 2.6 is much less reliable than late 2.4 kernels were. On my laptop this only serves to annoy me, but I run servers at work (and a webserver @ home), and right now I don't feel confident at all running newer 2.6 kernels on a production server.

Re:This is good

[Anonymous Coward]

Well I am running Debian Sarge on one of my servers and with kernel 2.6.8 which is going to be an official Sarge kernel I had a kernel panic each three days because of an APC BacUPS 500 connected using a USB cable. Even when special no driver was loaded, just the USB subsystem. I ended up downgrading to kernel to 2.4 which works fine.

Now given the fact that kernels after 2.6.8 have had some big modifications in USB subsystem, the problem may even be nonexistent in 2.6.11, but I am not going to know because I cannot afford to wait a week prepared for a kernel panic at any time. And even if the UPS problem is fixed, some other problem may arise, since 2.6.8 and 2.6.11 are quite different kernels.

My point is, that I don't trust the 2.6 kernel anymore and I hear a lot from people who also don't. Many people claim that 2.6 is more stable then 2.4 but I really can't see how can they tell that -- 2.4 worked for them without problems, and 2.6 works without problems too -- how can you make any conclusion from that? Yes, many parts of the kernel are now better, but it takes just one bug to make the better parts unusable together with the whole kernel. Just try to use google and you will find a lot of people who don't trust 2.6 anymore because of some little obscure problem most probably caused by rapid changes done during 2.6 development.

In earlier kernel versions, you could be pretty sure that you can upgrade within a x.y stable tree (like 2.2, 2.4) without any problems. Whereas in 2.6 series, you can't be sure you can safely upgrade from 2.6.8 to say 2.6.10 without something breaking up... Now you will be able to upgrade safely from 2.6.1 to 2.6.11.5, but only until 2.6.12 is released, which is really quite unusable.

I am sure that this new development model is more fun for the developers, but from users perspective it is starting to be a disaster. I know that I get the whole kernel for free, so I probably shouldn't complain, but then again I may be tempted to move to a kernel that has a more user-centric development model... there are a few possible choices.

chicken/egg

[smittyoneeach]

No one wants to mess with a new kernel until it's stable.
The ALSA drivers were held up as an example of something that worked until it hit userland, and suddenly, ALSA was salsa on Thinkpads.
The marketing question *gasp* becomes, How do we entice users into compiling and testing on broader architectures?
Actually, Gentoo, for one, at least makes it semi-manageable to have a fistful of kernels--I may actually emerge something for fun.
(The agony of getting my 11g with WEP and nVidia all configured has been non-trivial. I still have to become root briefly and run a script when I boot, as I haven't fully grokked the 'right' way to set all of these parameters).

Re:chicken/egg

[Gherald]

Of course you could always start the script from /etc/conf.d/local.start

Re:chicken/egg

[Anonymous Coward]

argh, these kinds of comments drive me nuts. I use Gentoo, and gentoo makes it no easier than any other distribution to install multiple kernels.

Re:chicken/egg

[smittyoneeach]

>genkernel --menuconfig at least offers the appearance of making things easier.
You still have to know your hardware cold, at a low level.
And, yeah, you can certainly do the same with other distros.
However, I think it's fair to say that Gentoo facilitates the task better, relative to other offerings (that I have tried, mainly Fedora).

Not granular enough

[m50d]

One release is not enough to get all the bugs out of a new feature. You need at least three before you can begin to call it stable. I can see why 2.4/2.5 is considered too long, but 2.6.12 and 2.6.13 isn't enough of a gap. Unless they want to move to lots of use of the fourth number, which I suppose is a possible strategy. 2.6.11 has new features which will be stable by 2.6.12.3. But if they do that there will be too many stable releases, or too many stable releases which aren't actually stable. So I think they need to move to having lots of unstable releases with the same first three version numbers. So we will have 2.6.12.x and 2.6.13.x trees running in parallel like 2.4 and 2.5, but not as separated, maybe 5 or 6 versions under each before moving on to 2.6.14.x and 2.6.15.x. That could work.

Re:Not granular enough

[haplo21112]

good I wish...I had mod points right now...not only is this NOT insightful its stupid.

Re:Not granular enough

[m50d]

If I'm wrong, correct me and tell me why. I'm perfectly willing to be convinced if you know why this wouldn't work.

Asymptote...

[physx]

Anyone got a guess on where the kernel number will converge? I'm looking forward to linux version 3.14159...

Re:Asymptote...

[Anonymous Coward]

At the rate it's going, I'd guess e...

On a serious note, why don't we just fork the kernel? As long as the ABI remains the same, it won't matter to anyone except kernel developers, and if the driver interface could be standardized it wouldn't be an issue for driver writers. We could have an openbsd-like branch for rock solid stability, a "standard" branch, a "performance" branch, and perhaps a few development branches. It's high time the kernel becomes standardized enough to do this sort of whole-scale forking while retaining drivers and ABI compatibility. As it is, these forks already exist in clustering projects and the linux router project, but they have to continually change needlessly when kernel versions increment.

Of course, the Linux kernel is nowhere near "finished", in that there are plenty of areas left to explore. I'd like to see *real* capabilities ala keykos or eros become an option, or at least general persistance and clustering become somewhat mainstream so that you don't need a lot of huge patches to build grid computing or high availability clusters. It will probably be a while before the kernel internals are abstracted enough to make this easy, though.

Re:Asymptote...

[wild_berry]

2.7182818 is closer...

Good old days?

[Zo0ok]

Why not go back to the good old days? When new version were released very often. Then: 1.3.5->1.3.6->1.3.7 were rapid (ok, maybe its a bad example, but you get the point).

Now instead its 2.6.11-r3->2.6.11.r4->2.6.11.r5.

This is just an inflations problem. Why not accept that development is faster now when so much more resources and so many more developers are involved?

Call it 2.7.1->2.7.2->2.7.3. Release 2.8 in a matter of weeks. When 2.8 is really good, call 2.8.XX final, and go on with 2.9. Its not like we're running out of numbers. Who will complain?

It seems the idea is abandoned

[greppling]

While a few developers liked the idea, most preferred to get more serious about the 2.6.x.y idea. And since Greg "the USB-guy" KH and Chris Wright volunteered to maintain it, it seems like this will be taken seriously this time.

This sounds like the best solution in the best interest of actual users.

Just do it the OLD WAY

[Malor]

I do NOT understnnd why he won't just fork off 2.7. 2.6 is unstable and untrustworthy, and it's not going to GET stable until they STOP SCREWING WITH IT.

Linux 2.4, the last stable kernel, has had 29 versions as of this post. Admittedly, the chaos of the first 10 or 11 releases were from exactly the same kind of stupidity we're seeing now, development continuing in the 'stable' branch.

Since 2.4.11, there have been EIGHTEEN PATCHES to get 2.4 to the relative stability it's at now, and even so, it's still not as good as 2.2 on a lot of hardware. A single release is NOT ENOUGH to get things stable. 2.4 is still not that robust, on many configurations, after eighteen patches. There's no way that one patch is gonna do it.

Linux, PLEASE go play in 2.7 and let everyone else get 2.6 stable. It's not trustworthy now, and I will not use 2.6 kernels in any kind of serious production environment because of it. A single release is NOT going to be stable. If you freeze it right this second and branch off to 2.7, the kernel should actually be fairly stable by 2.6.25. With all the extra code in the 2.6 tree, it wouldn't surprise me if it got to 2.6.60 before it was really and truly 'finished'.

Claiming that 'distributions will make it stable' is basically waving your hand in the air and hoping that other people will fix it, while you madly add new problems by dumping untested code into the 'stable' tree.

It's not working, and it's not ever going to work. The longer you keep trying to call a development branch 'stable', the more damage you do to Linux.

Re:Just do it the OLD WAY

[Xtifr]

YES!!! I was going to mod you insightful, but decided to post my enthusiastic agreement instead. The two-pronged approach, with the stable branch and the development branch, was one of the most amazing and innovative development models I'd seen in years, and it's proved itself time and time again, not just on the kernel but on other projects as well.

The 2.6 series has just been a mess. I upgraded briefly, but quickly retreated to 2.4. Frankly, if Linus doesn't go ahead and make himself a new playground/branch soon, I might try to get some motivated, like-minded developers together to try to create a stable branch off of 2.6 somewhere. Maybe we can call it 2.7, and force Linus and crew to jump to 2.8 when they want to make a new experimental branch. :)

Re:Just do it the OLD WAY

[drinkypoo]

This is absolutely correct. New features should NEVER be integrated into an older stable kernel until they are already into a newer stable kernel. In other words, it's okay to backport stuff from 2.4 to 2.2 and kick out a later 2.2 release, that makes some sense although in other senses, people should just bloody go to 2.4. But, putting new things that haven't even been tested into any 2. kernel is ridiculous. Even drivers shouldn't make it into a "stable" kernel until they have had some test time on the unstable version.

Re:Just do it the OLD WAY

[alonsoac]

I don't know what exactly is your problem but I have been using 2.6 kernels for a while in my 2 home PC's and on 6 PCs in my company, some 2.6.8 and 2.6.10 and they all work fine.

Re:Just do it the OLD WAY

[Anonymous Coward]

Ooh, let's all take advice about release schedules from someone who doesn't know the difference between a release and a patch!

Re:Just do it the OLD WAY

[cpeterso]

I like Linus' new proposal (and I even thought of this years ago), but I think it is mostly psychological. Bugs will be fixed in both 2.6.even and 2.6.odd releases, but with 2.6.even releases "themed" to be stabilizing bugfix releases, kernel developers will focus more on bugfixes and less on pushing out immat ure features. Plus, the 2.6.even releases will increase the rate of kernel releases, so bugs will get fixed sooner. Currently, some bug in 2.6.10 (let's say) wouldn't get fixed until 2.6.11 and users would have to wait for bug fixes AND new features to mature in 2.6.11rc pre-releases.

However, what DOES scare me is that Linus thinks (and he proves it time and time again) that HUGE kernel changes are safe within stable releases. In 2.4, he dumped the VM. In 2.6, he gave the example of switching from 3-level page tables to 4-level page tables. Linus, that is NOT a minor change!

Re:Just do it the OLD WAY

[Anonymous Coward]

In 2.6, he gave the example of switching from 3-level page tables to 4-level page tables. Linus, that is NOT a minor change!

Actually, it isn't as big a change as it sounds like. And it is something that, if it breaks will *really* blow up in a big way, not just silent data corruption for 4 people with usb asdf dongles. So it was easy to iron out the bugs in testing.

Re:Just do it the OLD WAY

[Anonymous Coward]

Linux, PLEASE go play

"Linus". (Linux is the OS; Linus is the person.)

Re:Just do it the OLD WAY

[RedWizzard]

I do NOT understnnd why he won't just fork off 2.7.
...
Linux 2.4, the last stable kernel, has had 29 versions as of this post. Admittedly, the chaos of the first 10 or 11 releases were from exactly the same kind of stupidity we're seeing now, development continuing in the 'stable' branch.

Since 2.4.11, there have been EIGHTEEN PATCHES to get 2.4 to the relative stability it's at now, and even so, it's still not as good as 2.2 on a lot of hardware.

Has it occurred to you that having a big development cycle (2.3) caused the instability with 2.4, and that's what Linus is trying to avoid by not forking 2.7? The problem with big development branches is that there are not enough people testing them.

Re:Just do it the OLD WAY

[Malor]

Then they need a longer release-candidate cycle. What they REALLY need is a big bank of machines on which they can run automated test cycles. I would happily contribute both money and hardware to such a cause. Linux is complex enough that it needs QA now. I don't mind testing when I know it's testing. I resent very much being FORCED to test.

Once a kernel line is declared stable, it should be STABLE... you stop screwing with it! You fix the problems, perhaps backport support for new hardware, and mostly leave it alone. 2.4 still isn't all that robust on some hardware even now. Shoveling new features into 2.6 every 30 days is pretty much a guarantee that it's NEVER going to be really stable.

Yes, it's a lot of work maintaining the two trees. No, it's not a lot of fun. But the alternative is inflicting exponentially greater amounts of pain on the rest of the world. At the moment, the most current stable tree in Linux IS NOT STABLE.

How much more damning an indictment of an operating system could one possibly make?

Use exponential notation

[timotten]

2^6^8 would be bigger than 2.6.8.

2^6^8 - 2.6.8 == 281474976710656 - 2.68 == 281474976710653.32

2.6.8 / 2^6^8 == 2.68 / 281474976710656 == 9.521272659e-15

Way bigger.

Multiple branches are a good thing

[maxphunk]

Look at FreeBSD, -STABLE and -CURRENT tags for any given release simply let one know whats up. You can upgrade to -STABLE, and get all your bug/security fixes without worrying about throwing off the system. If you do feel adventurous, you can for -CURRENT... BUT it contains new stuff and should not be used in production. I think Linux needs similar levels of distinction.

Re:Multiple branches are a good thing

[openglx]

Ever heard about Debian STABLE and Debian TESTING? Yeah, that's another good example. STABLE is really stable, but not everybody can run "old" software on their machines. I run Debian TESTING (sarge) on my machines, but would run to UNSTABLE (sid) because I don't need bleeding egde updates.

Linux Kernel Versioning

[Josepdin]

I think it makes sense to provide a plan that can set expectations, particularly one that is easily explained. Version numers should rarely change, implying a leap of technology that cannot be represented in the release number. The release number should represent significant changes to the sub-functions, but not on the level that would be considered a technology leap. The modification number would be exactly for patches and incidental changes. The template for this looks like v.rr.mm and mirrors versioning used by other OS developerment companies, including those with TLA's for a name. I like the odd/even paradigm as it gives me the insight I need when I am making a decision as to which kernel to go with. If it's a critical path system, then I'm staying with stable release code, otherwise, maybe I can go with the more forward moving code.

Split out the driver system, just read below..

[haplo21112]

...before you write me off, give me a serious listen.

Spilt off the development of drivers out of the main kernel tree. I great deal of instability arises from the drivers and how they interact with the kernel systems. Virtualize the drivers interface (further tahn it already is), such that the kernel talks through virtual hardware, doing something network related talk to the Vnic. The Vnic would then be interfaced with the actual network driver which is built in a seperate build process. Its coded to talk to the actual hardware, and send back only the things that the kernel actually needs. This is really just an extention of the existing module system...

Re:Split out the driver system, just read below..

[Anonymous Coward]

Spilt off the development of drivers out of the main kernel tree. I great deal of instability arises from the drivers and how they interact with the kernel systems. Virtualize the drivers interface (further tahn it already is), such that the kernel talks through virtual hardware, doing something network related talk to the Vnic. The Vnic would then be interfaced with the actual network driver which is built in a seperate build process. Its coded to talk to the actual hardware, and send back only the things that the kernel actually needs. This is really just an extention of the existing module system...

Excellent idea!!! Just do it in 2.7, not in 2.6.

The stable branch, in order to remain stable, needs to fix bugs and add zero new functionality. Period. Stabilize 2.6 by not adding anything new. Let it mature for a few years and it will become stable by itself.

Synchronicity...

[Anonymous Coward]

apropos quote at the bottom of my screen:

A computer scientist is someone who fixes things that aren't broken.

Asymptotic versioning.

[Grendel Drago]

Nah, TeX already has that. METAFONT has a lock on e, too. So what do we use? Is there some kind of sexy constant between 2.6 and 3?

--grendel drago

Ah, I've heard tell of you.

[Grendel Drago]

Didn't they make Debian stable for people like you?

--grendel drago

That's because

[ahdeoz]

That's because nothing has been added to Linux since 2.4. You've got a bunch of guys tweaking VMs and messing with latency, but really, Linux reached a brick wall a long time ago, and kernel development is really just a research project for really smark hobbyists. 2.4 was important because it brought USB drivers, but nobody has figured out yet how to tune it successfully for the desktop, and what we really need now is wifi drivers, that's the new USB, and it's already 2 years too late. 2.6 should have been pressured to get out because of that, and DSPs.