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."
Just call the next kernel Linux XP. Worked for Microsoft!
Why not add new functionality in release candidates, and only make it an official release once it's stable?
-rsw
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.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
why does it matter what the versioning scheme is?
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
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.
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.
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).
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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
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.
This space intentionally left blank.
Anyone got a guess on where the kernel number will converge? I'm looking forward to linux version 3.14159...
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.