Linus on Kernel Version Numbering 416
walshy007 writes "In a recent thread it was asked what it would take for an 'unstable' 2.7 development tree to be created, to which Linus replied:
'Nothing. I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back. That said, I _am_ considering changing just the numbering. Not to go back to the old model, but because a constantly increasing minor number leads to big numbers. I'm not all that thrilled with "26" as a number: it's hard to remember. I think the time-based releases (ie the "2 weeks of merge window until -rc1, followed by roughly two months of stabilization") has been so successful that I'd prefer to skip the version numbering model too. We don't do releases based on "features" any more, so why should we do version _numbering_ based on "features"?'"
A suggestion (Score:0, Insightful)
Excellent notion (Score:5, Insightful)
Open Source (Score:3, Insightful)
A rose by any other name... (Score:3, Insightful)
customers rely on "features" (Score:5, Insightful)
Er, you don't do a release for specific "features," but once the release has been made, customers rely on knowing what "features" are (or are not) in the release they're using. There should be a sane and rational comparison rule to know if one version is newer (and likely to have more good "features" and fewer bad "features") or not. Ubuntu uses dorky names but anyone who knows the alphabet and the comparison rule can at least decide if "Beaver" is older or newer than "Walrus." I don't care what the kernel uses, but it should be something people can figure out the ordering.
Hey, I heard the Parameterized Ultra-Fair Order One Irreversible Hypoxic Process Scheduler is in the newest kernel. Wait, is that in 2.6.43.-12b34_+omicron-rc6, or not?
Re:Linus... (Score:2, Insightful)
Please...
These are such minor things that they are not even a blip on the Radar. I am not a true believer in the Church of Linus or the Church of RMS but this isn't a major problem for Linux.
I still say that Linux needs a stable binary interface for drivers. I have found no good technical reason not and I find flaws in the political reasons. I don't get to make that call however unless I want to fork the kernel and I know my limits.
I also think some drivers "Printers, serial ports, web cams..." need to be moved out of the kernel. They don't need the performance and any extra code in the kernel can lead to bad bugs.
But none of these things are terrible or show stoppers. Linus may not be pushing the community forward as much as you would like but he sure isn't the biggest problem the community has.
Re:Linus... (Score:5, Insightful)
http://lxr.linux.no/linux/Documentation/stable_api_nonsense.txt [linux.no]
Summary: Being able to improve the API regularly keeps Linux largely free of legacy cruft that slows down the development and runtime performance of other systems like Windows. That's why Linux maxes out hardware that runs like a dog under Windows.
Re:Excellent notion (Score:5, Insightful)
which not only tells us the version but also how old it is
Who cares how old it is? If it works and isn't known to have any stability or security issues (or at least not ones that affect your use of it), does it matter?
Software that is newer is not inherently more secure, software that is older is not inherently less secure. I really fail to see how this "date obsolescence effect" helps improve security - I know version 20080213 is older than 20080601, but then I also know that 2.2.12 is older than 2.2.25. Neither of these schemes in themselves say anything at all about the security of the software in question.
It also reflects... (Score:5, Insightful)
It is in part semantics, but at the same time it also represents the core not ostensibly having a bugfix-only branch. Distributions fill in the gap there to an extent. But it does reflect a departure from a lot of common practice of having a branch to follow for those content with featuresets, but needing the security and bug fixes too. As of the no-2.7 branch, this was already the case, this truly is just semantics. But the 2.7 decision was about more than semantics.
Re:A suggestion (Score:2, Insightful)
how about getting some drivers for linux so that it will work with my printer for example ?
What does that have to do with the kernel developers? Go complain to your manufacturer.
Re:Excellent notion (Score:5, Insightful)
date-based is good for continuous processes, which the development isn't and shouldn't be. From the user perspective, my primary concerns are comparisons - is this driver for my kernel version? Do I run the latest kernel version? Is this function available in my current version?
Numbers are easier to compare than dates. They are also international, while dates aren't. 07.01. means 1st of July in some countries and January 7th in others.
Major and minor numbers have their place, too. They tell me something about the amount of change. I'll update from 2.6.25 to 2.6.26 without a second thought, as I expect nothing important to have changed. I'll spend a few minutes on the Changelog when I go from 2.6 to 2.7 because I expect a couple of minor things to have changed. I know that going from 2 to 3 will be a major update and might result in all kinds of incompatabilities, so I'd better make sure all my apps are ready first.
That's why I hate MS year-based versioning system. "Word '97" tells me absolutely nothing about how it compares to '95, '96 or '98. A version number would at least tell me what the manufacturer thinks it's "worth" (even though with MS that was mostly a lie as well).
And if Linus thinks that "big" (26, yeah right) numbers are a problem for people, then dates will be as well. Quick, how many releases were between 2.6.20 and 2.6.24? Good. Now quick, how many days were between January 17 and March 11? And... how many releases?
Re:Linus... (Score:3, Insightful)
The way to fix this is to mandate that hardware manufacturers publish detailed specifications based upon which FLOSS drivers can be written. The way things stand now, the buggier their gear is, the more secretive they are about releasing anything about it.
Sunshine laws, not accommodation to the greedy, will fix this.
Re:A suggestion (Score:5, Insightful)
You mean like where Windows hides the registry?
Re:Linus... (Score:5, Insightful)
The name of that file cleverly describes its contents, even though it is attempting to describe the argument it 'debunks'.
You can have the best of both worlds (a stable API, and the ability to make changes). The fact of the matter is that the APIs don't change all that often, and frequently they change in a way that would allow for a trivial compatibility layer. Te fact of the matter is that it would *benefit* linux to force the developers of the various driver layers to have to consider interface stability when they make their changes. It would benefit the entire community to make it incredibly difficult for distributors *cough*redhat*cough* to change the driver API for a service layer and release the kernel with the same version number.
Summary: A stable API doesn't mean you're weighed down with cruft, and any argument based on that premise is nonsense. Any intelligent person making that argument is really saying that they think all drivers should be GPL.
Developers cant keep up with the releases (Score:1, Insightful)
The main problem I have right now is the sheer frequency of new kernel releases. A new release comes out every 90 days or so and contains a ton of new functionality, renamed functions, reworked innards, etc. It is a nightmare trying to keep my product's kernel modules working seamlessly across all revisions (i.e. - things I am interested in like memory management, process management, etc are constantly changing).
If Linux wants to get serious about becoming the standard platform for enterprise services, then it is going to have to get back to "stable" or "platform" releases that only come out once or twice a year. Either that, or just designate certain iterations (2.6.9, 2.6.18, 2.6.23, etc) as the platform release around which developers like me can focus our compatibility and testing efforts.
New model less stable? (Score:0, Insightful)
This will likely be modded down.
Is it just me, or has the 2.6 series been less stable for anyone else? Even sticking with the version shipped with Ubuntu's release rather than constantly updating to the latest version I get the feeling that the recent 2.6 kernels just aren't as stable as kernels released under the previous development model.
Nonsense (Score:1, Insightful)
I like old style versioning, fixed in 1.45 sounds better than fixed in r1445 and impossibly better than fixed in ad92c0626ae7e9ef92df3dfa4c967d93.
The only sane reason to go to date based versioning is to distinguish between features and/or stability. If you're not doing that (as linus contends), you may as well ditch version numbers all together -- good luck with that!
Re:Linus... (Score:2, Insightful)
When you say "no drivers" you actually mean "no third party drivers". That's a _good_ thing, because most third party drivers are written by idiots. I'd much rather have a system that encourages vendors to open source their drivers and get them into the kernel where they can be better maintained, than the Windows scenario where you have to install third party drivers that crash your system every half hour and fill your system with other junkware (wireless cards are a good example - how many of them force you to use their own buggy "monitoring app"?)
Re:It also reflects... (Score:5, Insightful)
There are multiple bugfix only branches. 2.6.16.x to 2.6.25.x are all still actively maintained.
The simple fact is that the new model has actually caused Linux distros to have more stable kernels now that vendors aren't trying to constantly backport things from the unstable branch.
Shorter dev cycles were one of the best ideas Linus ever had.
Re:Why versioning based on features? (Score:5, Insightful)
Re: Drivers (Score:2, Insightful)
* Drivers out of the kernel
* stable binary interface for drivers
My first reaction was this was an undercover M$ person or other proprietary type, that wants to hide their driver and not be bothered by the GPL.
Re:Linus... (Score:1, Insightful)
Re: Drivers (Score:3, Insightful)
Not really just a user.
I am all for FOSS drivers but having to recompile a driver is a pain. Having the driver in the Kernel makes the hardware developers dependent on the Kernel maintainers. They have no control over when it gets into the Kernel.
I would even be happy if drivers that used the binary API where REQIRED to be GPLed.
Moving drivers out of the kernel.
Notice that I limited it to low performance devices. A driver in kernel space can take out an entire system. I think it is dumb that a bad serial port or printer driver can take down a system.
As far as wanting to keep drives proprietary. Not really but the current system hasn't prevented it. It just makes them a pain for the end user.
Re:Linus... (Score:2, Insightful)
OK, if you want to "take control" of the manufacturers, it is quite simple... buy them. Once you own the companies, you can then dictate what they do.
Re:Linus... (Score:3, Insightful)
Any intelligent person making that argument is really saying that they think all drivers should be GPL.
Which may well be the reason -- it seems reasonable to me that an intelligent person could indeed believe that, in the long run, making it too easy for vendors to provide binary-only drivers would hurt Linux in particular, and users of computers in general. Especially if one is also of the belief that operating systems will eventually become "commoditized" and there'll be no money to be made from selling them.
A similar theory is that a "constantly" changing ABI requires (okay, encourages) any hardware vendor who does decide to release binary-only drivers to keep them up-to-date, rather than release it and leave it untouched for 3 years while still claiming "full Linux support*", where the * means "except for features less than 3 years old".
I think it almost certainly hurts Linux in the short term, but in the long term it may be for the better. There's definitely an "open source" trend starting to build. Not that long ago the idea of an open source phone was ridiculous, but now there's Google's Android platform and Nokia and friends are open-sourcing Symbian. There's a lot of good reasons for hardware manufacturers to want quality, fully-featured open-source drivers for their hardware.
Re:Linus... (Score:3, Insightful)
Oh I do think Linux does have a lot of drivers.
The problem is that a manufacture is going to have a hard time providing them in an easy to install way.
Let's say that I create a nice little printer and I want it to be compatibly with Linux. This printer needs a driver so I write it and even make it GPL.
Now I have to get it into the Kernel.... And now I have to wait for that Kernel to make it in to the major distros.....
All the time I am selling them for Windows.
Now if I could pack in a CD with a driver that I know will work with the kernel I can ship it now.
That is what a binary driver interface can give you.
What I want to do is to go to the store and look for a printer without check to see if there is a driver for it!
Re:Linus... (Score:3, Insightful)
"The way to fix this is to mandate that hardware manufacturers publish detailed specifications based upon which FLOSS drivers can be written."
Why?
Why should tell a hardware manufacture what they can and not do?
Take a look at the AMD/ATI driver project. AMD is releasing the info as fast as they can and they are helping to write the driver.
It is a huge project.
Define "lots" (Score:3, Insightful)
You are missing the point. "Lots" is a subjective term, and you need a definition or benchmark to measure by. The benchmark for drivers and device compatibility is Windows, and compared to Windows Linux does not have lots of drivers. Linux supports only a very small percentage of the devices Windows supports.
And this is another point you missed. When most people talk about "lots" of driver support, there is an additional factor they use for benchmarking, and that is current hardware. Windows and its support of the newest and most obscure hardware is the benchmark for the term "lots".
I'm a Linux user myself and love FOSS. I really wish things were different in this area, but anyone taking an objective look at the situation has to admit that Linux does not have lots of drivers. The only way you can say it does is to make up your own arbitrary definition of what "lots" means, but then the other 99% of PC users who have agreed on using Windows as the measuring stick are going to call BS on you. Having to list as many caveats as you did and still concluding that Linux has "lots" of drivers smacks of fanboyism.
Re:A suggestion (Score:4, Insightful)
Your comment conveniently ignores his role in the project. It seems like he doesn't really work at the nuts-and-bolts level of driver development. His comments lately lead one to believe he's pretty satisfied with the overall status of the kernel such that issues like this are important to him.
I know you and the moderators are not satisfied with some aspects of the project, but you would be barking up the wrong tree.
Why all the hubbub? (Score:2, Insightful)
Personally, I like the numbering system. The current numbering system is very easy to understand. Changes in the Major version number (and I think this is obvious because it's called the Major version) are major changes that may cause certain functionality to become obsolete or unsupported. Minor version changes will most likely not cause many issues. And the last number (I call it Bugfix, Patch, or whatever) probably has no adverse affects unless you have an application that relies on a bug to function.
Why not use both a date and a version number so that users can A) tell how much change has occurred between releases, and B) how much time has passed or how old their kernel is.
Comment removed (Score:5, Insightful)
I like version numbers that tell me something (Score:5, Insightful)
If I see a version number of 2.00, I can ASSume that there are significant changes from 1.X. Also, as an "ohoh" version, it's more likely to have bugs than 2.1.
A year-based version tells me when it was released, but not much else. Maybe there was a major change in August, and V2008.08.01 is an "ohoh" version.
Named versions tell me even less. I might ASSume that "Perfect Penguin" is later than "Ornery Onyx", but I don't know how much has changed, or how long it took to release.
Re:Linus... (Score:3, Insightful)
It's also why Windows is dying slowly. Attempting to be backwards-compatible with years of unmodifiable binary cruft, sucks.
In the short run, the no-binary-drivers rule sucks. It means you can't use Linux and play your games. It also means that Linux won't win the desktop war overnight (though I would argue that allowing binary drivers would have killed Linux before it could win). In the long run, it's a huge win.
There's practical reasons for the rule. Most of the kernel programmers are very--even notoriously--pragmatic. If they allow binary drivers...people will start making binary drivers. In theory, kernel developers wouldn't get blamed or harassed for problems with those drivers. In theory.
In fact, though, most of the major problems with Linux (wireless and graphics) occur in the two areas where binary drivers are common. You think that doesn't affect the kernel developers? They don't want to deal with that bullshit, and good for them. I'm willing to wait until the better model wins.
Re:A suggestion (Score:2, Insightful)
Well, yes, but what he (Linus) is really talking about is the development model. Do they need a debug tree, or not?
It's a bit silly for us care so much, though.
Re:Linus... (Score:2, Insightful)
How is it better in the long term, when long term the vendors simply choose to not release any drivers at all? It's silly to think that changing the api is a good way to "force" vendors to do anything. If they updated the windows drivers, why wouldn't they update the linux ones? If they actually let the drivers stagnate, you as a customer should complain.
This just sounds like one side not willing to compromise at all, then wondering why no one is playing with the gpl community.
Re:A suggestion (Score:4, Insightful)
Re:A suggestion (Score:2, Insightful)
I judge whether to download and try a program based on its version number. I know from experience that a version number less than about 0.8 is probably not worth my time.
The problem is that some open source projects use their own version numbering scheme that would make 0.8 a polished, finished product-- and there's no way to know that!
Why tell hardware manufacturers what to do? (Score:5, Insightful)
"The way to fix this is to mandate that hardware manufacturers publish detailed specifications based upon which FLOSS drivers can be written."
Why?
Why should tell a hardware manufacture what they can and not do?
Because if I am their customer, then I want them to act in a way that serves my interests. That is part of what I want for my money. I understand that I can't expect full indulgence from every hardware manufacturer - but I want them to understand, when I buy a piece of hardware I also want to have all the information necessary to make use of it. That is the message I want to send.
If you don't want to send a similar message, that's your business. I won't tell you you should think otherwise.
Re:Linus... (Score:5, Insightful)
Your argument is basically that writing shared libraries is just as easy as writing applications, and that maintaining API/ABI compatibility in shared libraries is "easy". Both of which contradict years of experience.
And, specifically from the kernel perspective, the usual example is the Solaris kernel in the 2.3/2.4/2.5 timeframe (memory is getting old) where they refused to fix a security bug because it would break ABI compatibility. So the corollary to your argument then is that Solaris kernel engineers are idiots?
Re:Linus... (Score:3, Insightful)
As a graphics driver developer, I have to tell you that the opposite is true in some cases. In the DRI, a graphics driver consists of three parts: the DDX, the DRM, and the 3d driver. In the current system, all of these components maintain stable ABIs with each other, and it's a nightmare. In fact, not being able to experiment freely with ABIs is one of the things that hold up the development of memory managers, and that in turn holds up a large number of advanced features (think render to texture, redirected direct rendering, ...).
Re:Linus... (Score:4, Insightful)
To me (to many software developers), stability doesn't mean "backwards compatible forever"... It means a reasonable attempt to maintain compatibility, and a minimum committed duration that a particular interface will be supported.
The attitude you describe does result in cruft, but that attitude has nothing to do with stability.
Announce the intention to break compatibility at least two releases ahead. Roll multiple trivial changes into a single release instead of releasing them at the maintainers fancy. Specify the interface somewhere other than in the code so your third-party distributors can't get away with breaking the interface and calling their kernel "Linux" with the same version number as the upstream edition. That is stability.
Re:Define "lots" (Score:3, Insightful)
The benchmark for drivers and device compatibility is Windows, and compared to Windows Linux does not have lots of drivers. Linux supports only a very small percentage of the devices Windows supports.
Windows does not support devices. Device manufacturers support devices. The reason why fewer devices work out of the box in Linux, frankly, is not Linux's fault. I would argue that Linux has much better driver support than Windows because the Linux community reverse engineers buggy, proprietary hardware and creates drivers that are sometimes more stable than the manufacturers' own provided Windows drivers. Let me know when Microsoft starts providing that service for their customers.
Lots of changes from 2.6.n to 2.6.n+1 (Score:5, Insightful)
Several slashdot readers have made comments like "I can easily upgrade from 2.6.n to 2.6.n+1 because not much will have changed".
This is all part of the delusion of version numbers. The changes between releases are only limited by how many can be squeezed into the merge window. With an increasing number of developers, and development tools that seem to be scaling the overall trend seems to be that the n+1 release is progressively more different that its predecessor. Here are the diffstats for the last few kernels:
2.6.15 -> 2.6.16 6721 files changed, 392461 insertions(+), 202469 deletions(-)
2.6.16 -> 2.6.17 6321 files changed, 416664 insertions(+), 308709 deletions(-)
2.6.17 -> 2.6.18 8972 files changed, 381890 insertions(+), 217058 deletions(-)
2.6.18 -> 2.6.19 8040 files changed, 515161 insertions(+), 291784 deletions(-)
2.6.19 -> 2.6.20 5825 files changed, 262475 insertions(+), 136162 deletions(-)
2.6.20 -> 2.6.21 6568 files changed, 319232 insertions(+), 175247 deletions(-)
2.6.21 -> 2.6.22 7620 files changed, 519591 insertions(+), 266699 deletions(-)
2.6.22 -> 2.6.23 7203 files changed, 406268 insertions(+), 339071 deletions(-)
2.6.23 -> 2.6.24 10209 files changed, 776107 insertions(+), 483031 deletions(-)
2.6.24 -> 2.6.25 9738 files changed, 777371 insertions(+), 404514 deletions(-)
2.6.25 -> 2.6.26 8676 files changed, 595389 insertions(+), 416139 deletions(-)
Re:It also reflects... (Score:5, Insightful)
You do realize that if you substitute 2.6.x-rc with 2.7.x, you are doing the same thing we've been doing when we had the experimental branch.
The only difference is that we no longer have to update the minor number, otherwise we would be on version 2.8 (or higher) by now.
I can see the advantages of the current version number scheme as it relates to the traditional desktop/server user.
But you're lucky enough to not have to compile a driver for a non-mainstream piece of embedded hardware, and have to spend time updating the driver code because something that was probably flagged as deprecated in 2.6.8 was removed completely in 2.6.9. However in the old system, the function would be deprecated in the 2.6 kernel and removed in the 2.8 kernel. Under the old system, a driver marked for the 2.6 kernel would compile without modification, but I would expect to have to update the driver for 2.8.
My point being that both number schemes has its advantages, it just the old system benefited me more. Now if we would tag versions that are considered a production release (like I suggested in my previous post), it would be a good compromise since you would continue to benefit from not having so many forks in the kernel and I would benefit by knowing where the removal of deprecated functions have taken place.
Re:Linus... (Score:3, Insightful)
Your argument is basically that writing shared libraries is just as easy as writing applications, and that maintaining API/ABI compatibility in shared libraries is "easy". Both of which contradict years of experience.
Actually I think the point is that when a product is well engineered, a stable API and ABI are quite feasible.
Supporting evidence for this is that basically every other platform _except_ Linux manages to keep a stable API and ABI.
The reason for this is, IMHO, large parts of Linux tend to be "trial and errored" into existence, rather than "specified, designed and implemented".
Stick with major.minor.patch (Score:5, Insightful)
Date-based versions don't help me very much. What I need/want from a version number is a clue as to how big the changes are. Is this version just bug-fixes and I shouldn't see much impact beyond fixing those errors? Is this a version that's got some significant enhancements and changes but my existing configuration should convert over without too much trouble and, while I'm going to see some impact, it shouldn't break my workflow and documents/code too badly? Or is this a big change with a whole new way of looking at large parts of the system, where I can expect major things to be a lot different and to have to adapt most everything to the new way the world is? The standard 3-part version numbers give me that kind of hint (at least when the developers stick to that accepted interpretation of the parts).
Re:A suggestion (Score:3, Insightful)
Re:Here's what I think (Score:3, Insightful)
1) Dates are unnecessary. On the one hand, if I don't care when the release happened, 2009.32 is telling me too much. On the other hand, if I care when it happened, 2009.32 doesn't tell me enough.
2) You still have the problem that you can miss the end of the year and have to rename your release.
3) [subjective] A release name like 2009.32 looks ugly to me. Perhaps an Ubuntu-like approach (9.32) would help with that.
4) Why dates? This is arbitrary information that has nothing to do with the fact that this release is a new version of the previous release. If one uses dates, one may as well use millions of lines of code or something.
My argument boils down to this: Linux is a kernel. It's a technical release, so it does not need PR anywhere but within the technical community (who can easily handle Linux 112). Let the distributions worry about catchy PHB-friendly names like Ubuntu 8.10 or openSuse 11.0
Re:Linus... (Score:3, Insightful)
Try instead: you *see* more of the trial-and-error on Linux. All operating systems rely on that to various degrees; their problems can't be specified in enough detail to allow a pure "waterfall" design/implementation process. The hardware keeps evolving, as do its applications; nothing stays still. In fact, that waterfall model has been widely discredited for years now, in large segments of the software industry. It's unworkable unless requirements are knowable a couple years in advance, and completely stable.
The project management issue is more or less when to allow interface changes to appear. You can argue about the policies Linux uses there, sure ... but frankly, delaying them for years and then merging lots of them into one mega-disaster release is a policy that I'm glad to see abandoned. Incremental change, as adopted by Linux and many open source projects, is much more effective.
Also, look at who complains about the lack of a binary interface. Not open source developers at all. Only folk who want to leverage community efforts without following community rules. Why should they have any say in this, at all? The folk who are actively moving the system forward have no problem working within those constraints.
Re:Linus... (Score:2, Insightful)
And then there was the whole fiasco of Norton changing their Corporate AV install such that it used IE components, requiring IE to be updated/reinstalled/etc., when the environment mostly used Netscape as the browser.
That was several years ago, I haven't done much work in a large network for quite a while but I'm sure the situation hasn't improved any. Though if I were going to deploy a large network of Linux desktops today, I'd probably be a little less concerned about the hardware than I would be if they were Windows desktops. Then I'd have the whole Vista or XP question to deal with and my head would probably explode trying to figure out the compatibility matrix, not to mention acceptable performance, with that one.