Slashdot Log In
Linus on Kernel Version Numbering
Posted by
CmdrTaco
on Wednesday July 16, @10:18AM
from the you're-using-slashdot-T_2_5_0_212 dept.
from the you're-using-slashdot-T_2_5_0_212 dept.
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"?'"
Related Stories
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
also known as kernel numbering (Score:5, Funny)
Reply to This
Re:A suggestion (Score:5, Interesting)
The previous post might sound like a troll, but it makes a great point. Debating over version number schemes feels even more arbitrary and trivial than debating over, say, Code names for projects. Do version numbers or project names really have that much of an influence on how well code is written? If Windows had a kernel numbered 1.33.7 with a beta name of "Loopy Longhorn", would it be a better finished product?
Reply to This
Parent
Re:A suggestion (Score:5, Funny)
If Windows had a kernel numbered 1.33.7 with a beta name of "Loopy Longhorn", would it be a better finished product?
The obvious answer is yes. It'd be 1337, of course it'd be better!
Reply to This
Parent
Re:A suggestion (Score:5, Insightful)
to which Linus answered no, as he is much at ease with thin new incremental changes policy, which is good for the kernel as there are less resource spent in backporting fixes/improvements, and because the incremental part of it forces the developers to refactor existing code, instead that rewrite a parallel version of unstable crappy almost similar but identically unmaintainable code; as reference, search all the history of the effort of reducing the sata/ata/scsi interface to a common device layer.
Reply to This
Parent
Re:Why versioning based on features? (Score:5, Insightful)
Reply to This
Parent
Re:A suggestion (Score:5, Informative)
Besides, it's not like they don't want to support all the hardware available, it's win-only hardware manufacturers that are the main obstacle towards better hardware support in linux.
Reply to This
Parent
Re:A suggestion (Score:5, Informative)
Why bother with Linux?, get a proper OS. You know, one that doesn't make you create everything yourself, and hide stuff with obscure names in obscure locations, unique for the developer who shat it out.
BeOS died long ago. And AmigaOS runs on specialized hardware. And OS X is UNIX-based so it does the "hide stuff with obscure names in obscure locations" and runs offically only on specialized hardware. And don't even get me started with Windows... So basically, all competition for OSes died after Windows 95. So either you get a UNIX-like OS such as Linux, or you get Windows.
Reply to This
Parent
Re:A suggestion (Score:5, Insightful)
You mean like where Windows hides the registry?
Reply to This
Parent
Linus... (Score:5, Funny)
Reply to This
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.
Reply to This
Parent
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.
Reply to This
Parent
Re:Linus... (Score:5, Informative)
This "no drivers" myth continues to be quite pervasive.
There are lots of drivers, as long as you don't want to install something non-mainstream and you're okay with the binary blob drivers for the NVIDIA and ATI/AMD graphics cards (although, my understanding is that the ATI/AMD front is changing and AMD is pushing the specs out the community now).
There are very good drivers for hardware in just about any class. Scanners, printers, digital cameras, webcams, video capture, bluetooth, USB, you name it.
The trick is that you have to buy hardware that is known to work well and be supported on Linux. You might have to buy stuff that's a bit behind, too. Here's an example: the Epson Stylus C120 has a release date of August 2007. The Gutenprint driver for the C120 just appeared within this last month or so in 5.2 Beta releases (I think it's been available in the CVS for sometime). That means distros that keep up like Ubuntu will probably start supporting it in their next releases.
So you had to a wait a year. Big deal. In that year, the list price dropped from $89.99 to $69.99.
If you're one of those people that just HAS to have the latest hardware NOW, you're probably a gamer and should use Windows anyhow.
Reply to This
Parent
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.
Reply to This
Parent
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.
Reply to This
Parent
Stop Raggin' on 26 (Score:5, Funny)
What did it ever do to you?
Besides, it's accomplished a lot:
In mathematics
Inherent mathematical properties
Twenty-six is a composite number [slashdot.org], its proper divisors [slashdot.org] being 1 [slashdot.org], 2 [slashdot.org], and 13 [slashdot.org]. 26 is the only number between a square number [slashdot.org] and a cube number [slashdot.org], the numbers being 25 (5 [slashdot.org] squared) and 27 (3 [slashdot.org] cubed). This was first proved by Pierre de Fermat [slashdot.org].
It is the 7th distinct biprime [slashdot.org] (2.13) and the 5th with 2 as its lowest non-unitary prime factor. The aliquot sum [slashdot.org] of 26 is 16 with an aliquot sequence of 8 members; (26,16,15,9,4,3,1,0), leading to 0 through the prime 3 the 6th composite number so to do and so the sixth member of the 3-aliquot tree.
There is no solution to the equation Ï [slashdot.org](x) = 26, making 26 a nontotient [slashdot.org]. Nor is there a solution to x - Ï(x) = 26, making 26 a noncototient [slashdot.org].
In the classification of finite simple groups [slashdot.org] there are 26 sporadic groups.
Properties of its positional representation in certain radixes
Twenty-six is a repdigit [slashdot.org] in base [slashdot.org] three [slashdot.org] (222) and in base twelve [slashdot.org] (22).
In base ten [slashdot.org], 26 is the smallest number that is not a palindrome [slashdot.org] to have a square [slashdot.org] which is (26^2=676 [slashdot.org]).
Twenty-six is the number of five-digit prime quadruplets [slashdot.org], the first of which is {13001, 13003, 13007, 13009}[1] [slashdot.org].
In science
Astronomy
Reply to This
Excellent notion (Score:5, Insightful)
Reply to This
Re:Excellent notion (Score:5, Informative)
An [microsoft.com] excellent [microsoft.com] point [microsoft.com], sir [microsoft.com].
Reply to This
Parent
Re:Excellent notion (Score:5, Funny)
Anyone who has problems with "large numbers such as 26" probably shouldn't be doing kernel coding ... just sayin' ;-)
Reply to This
Parent
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.
Reply to This
Parent
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?
Reply to This
Parent
Re:Excellent notion (Score:5, Informative)
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.
Kernel development no longer works that way--the current model is, every 2-3 months a new kernel is released, then there's a couple weeks to merge new work, then the rest of the time until the next release is spent tracking down regressions.
There's never going to be another long-lived development branch: having years where all the real development went on in a kernel that nobody actually used caused all sorts of problems: bugs would pile up because the development branch wasn't getting enough testing, and distro's had to backport a lot just to be able to distribute "stable" kernels with the features and hardware support their customers needed.
So the kernel version is *always* going to start with "2.6.". Hence the thought that maybe the version numbering doesn't explain the new process as well as something like "2008.07" might.
And as for incompatibilities, they shouldn't happen. You should be able to drop a new kernel into an old system and everything should work--if not, report it as a bug. There's a few exceptions where some interface is dropped or change, but normally the assumption is that it's something that won't cause a problem for people--so if it does, speak up, they need to hear from you.
(Of course, the above only applies to real userland interfaces, not to internal kernel interfaces. If you're trying to run a bunch of proprietary out-of-tree code (like the proprietary nVidia driver) inside the kernel, then you're on your own.)
Reply to This
Parent
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?
Reply to This
Here's what I think (Score:5, Interesting)
If the 2.6 is not going to change, drop it, it's redundant.
So we're down to 26. I personally find a name like "Linux 28" to be cool. "Linux 41 was released today...". There's nothing wrong with big numbers: see udev [kernel.org].
The problem with date-based numbering is that when you go from 2008.4 to 2008.10, it looks like you missed a few releases. And if you pre-announce a release, you have to meet your deadline or else rename the release.
So they could do what Gentoo [gentoo.org] does - 2007.0, 2007.1, 2008.0, 2008.1, etc. But you still have the problem that every year, you lose count of how many releases have happened. Was there a 2007.2 or did we just go to 2008.0 because we missed the Christmas deadline due to that last-minute security bug?
They could reduce the problem by using a longer period, such as a decade. (At 6 months for a release, for example, the number will only reach 20, which is not large.) But that's somewhat arbitrary. Plus, being in the 0th decade, we don't want to have 2.6.30 be called 0.3.
To reduce the complexity on all that, just drop the dates, and what's left is a single big number. No dots, no multiple numbers, easy. Linux 112 is fine by me.
Reply to This
Version 2.6.26? (Score:5, Funny)
Can anyone help? I installed the 2.6.26 kernel on my pentium, but it keeps saying I have version 2.6.25999999999993 installed?
Reply to This
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.
Reply to This