Slashdot Mirror
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."
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.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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.
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.
I am trolling
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.
Why, o why must the sky fall when I've learned to fly?
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).
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.
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.
"The chief enemy of creativity is 'good taste'" -Pablo Picasso
...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...
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.