Linux Kernel Release Numbering Revisited 93
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."
suggestion (Score:2, Funny)
that's what -rcX is for (Score:3, Interesting)
-rsw
Re:that's what -rcX is for (Score:1)
Re:that's what -rcX is for (Score:2)
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 (Score:1)
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 ke
chicken/egg (Score:3, Interesting)
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
Re:chicken/egg (Score:2)
Re:chicken/egg (Score:2)
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).
2.7? (Score:2)
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? (Score:2)
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.
Comment removed (Score:5, Insightful)
Re:2.7? (Score:4, Insightful)
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? (Score:2)
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 relea
Re:2.7? (Score:1)
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
Re:2.7? (Score:1)
Re:2.7? (Score:1)
That's why I would disagree with the Windows 95 comparison (not the only reason
Linus himself has said in interviews that he sees the kernel overall as becoming more stable, and that the next big r
Re:2.7? (Score:1)
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 kern
Re:2.7? (Score:1, Troll)
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? (Score:2)
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 r
Re:2.7? (Score:2)
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? (Score:2)
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.
Re:2.7? (Score:1)
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, a
Re:2.7? (Score:2)
It's the same as before, just on a more rapid cycle.
Re:2.7? (Score:2)
Re:2.7? (Score:2)
Re:2.7? (Score:3, Interesting)
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, esp
Re:2.7? (Score:2)
Re:2.7? (Score:1)
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:So that's why (Score:2)
This would be helpful (Score:4, Interesting)
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 (Score:2)
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 (Score:2)
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? (Score:2, Interesting)
Re:why does it matter? (Score:2)
At least, that's how I see it.
Re:why does it matter? (Score:2)
Right now each kernel developer is going through that cycle at their own rate. At any given time, some developers are i
Re:why does it matter? (Score:2)
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? (Score:2)
Re:what's the point? (Score:1)
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
I have a much better idea. (Score:4, Interesting)
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. (Score:3, Insightful)
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 th
Re:I have a much better idea. (Score:2)
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
Re:I have a much better idea. (Score:2)
If you look at Linus's p
Bigger! (Score:4, Funny)
Use exponential notation (Score:2)
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.
I like it (Score:4, Insightful)
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 (Score:4, Informative)
Re:I like it (Score:1)
Re:I like it (Score:2)
Pay somebody who does Linux kernel programming (not cutting teeth on mm or somesuch) to write it for you.
Re:I like it (Score:1)
Re:I like it (Score:2)
Re:I like it (Score:1)
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 (Score:2)
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 fixe
Re:I like it (Score:2)
FreeBSD fixed this problem by using build dates for its patchlevels. If Linux used this scheme, you could have a 2
Re:I like it (Score:2)
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
This is good (Score:4, Interesting)
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.
Not granular enough (Score:4, Insightful)
Re:Not granular enough (Score:2)
Re:Not granular enough (Score:2)
Asymptote... (Score:2, Funny)
Re:Asymptote... (Score:1)
Asymptotic versioning. (Score:2)
--grendel drago
Good old days? (Score:2)
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
It seems the idea is abandoned (Score:2)
This sounds like the best solution in the best interest of actual users.
Just do it the OLD WAY (Score:5, Insightful)
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 (Score:3, Insightful)
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
Re:Just do it the OLD WAY (Score:2)
Re:Just do it the OLD WAY (Score:2)
Re:Just do it the OLD WAY (Score:3, Interesting)
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
Re:Just do it the OLD WAY (Score:1, Interesting)
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.
Ah, I've heard tell of you. (Score:2)
--grendel drago
Re:Just do it the OLD WAY (Score:2)
Has it occurred to you that having a big development
Re:Just do it the OLD WAY (Score:2)
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 most
Multiple branches are a good thing (Score:3, Insightful)
Re:Multiple branches are a good thing (Score:1)
Linux Kernel Versioning (Score:1)
Split out the driver system, just read below.. (Score:3, Insightful)
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...
That's because (Score:1)