Slashdot Mirror
Linus on Kernel Version Numbering
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"?'"
version 2.0 ...
Linus... has... jumped the shark. The number versions... his version control insanities... He's no longer Linux's greatest advantage. He's now doing more to hold back the community than anything else. (dear god this is going to hurt the karma)
Modding Trolls +1 inciteful since 1999
What did it ever do to you?
Besides, it's accomplished a lot:
In mathematics
Inherent mathematical properties
Twenty-six is a composite number, its proper divisors being 1, 2, and 13. 26 is the only number between a square number and a cube number, the numbers being 25 (5 squared) and 27 (3 cubed). This was first proved by Pierre de Fermat.
It is the 7th distinct biprime (2.13) and the 5th with 2 as its lowest non-unitary prime factor. The aliquot sum 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 Ï(x) = 26, making 26 a nontotient. Nor is there a solution to x - Ï(x) = 26, making 26 a noncototient.
In the classification of finite simple groups there are 26 sporadic groups.
Properties of its positional representation in certain radixes
Twenty-six is a repdigit in base three (222) and in base twelve (22).
In base ten, 26 is the smallest number that is not a palindrome to have a square which is (26^2=676).
Twenty-six is the number of five-digit prime quadruplets, the first of which is {13001, 13003, 13007, 13009}[1].
In science
Astronomy
Linus' idea to switch to date-based version numbering seems excellent to me. From a psychological perspective, humans have difficulties with numbers, especially larger numbers. Also, a purely incremental numbering system without any external relationships (let's call it "semantic anchors" or something) are just that: numbers. By using dates we tie in with an already establish cognitive category which not only tells us the version but also how old it is. Since we Linux folks are usually very conscious about keeping up-to-date (at least the /. crowd) it would be a good and automatic reminder of the state of our system. That is, we use the "date obsolescence effect" (the reason Microsoft stopped naming their software after the year released) to the advantage for security rather than the disadvantage of negative sales.
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?
[
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.
XML is like violence. If it doesn't solve the problem, use more.
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?
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!
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
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.
Taxation is legalized theft, no more, no less.
You mean like where Windows hides the registry?
No tyrant thrives when every subject says no.
(because surely someone must care)
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.
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 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.
What has the kernel to do with printer drivers? It has always been CUPS domain.
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.
Can anyone help? I installed the 2.6.26 kernel on my pentium, but it keeps saying I have version 2.6.25999999999993 installed?
I agree. Exactly. It aids non linux developers in troubleshooting issues and knowing if package b will work with package a and kernel x or if I need to update to kernel y.
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.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Comment removed based on user account deletion
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.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
The POSIX API is hardly obscure, nor are the file system and naming conventions. It's an ISO standard FFS!
C|N>K
_O_
|
_/|\_
me
"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.
Bow-ties are cool.
This is bollocks. I no longer bother to check whether the hardware I buy is Linux compatible; I assume if it's selling in large quantities it will work. And it does. Maybe I'm lucky, but all the Linux users I know hold a similar view: hardware drivers are no longer an issue. Just for giggles, I recently had to reinstall Windows and my main desktop. Ubuntu took me an hour to install, and another hour to install all my favourite programs. Two weeks later, I have given up on finding a windows driver for an old Canon scanner that Ubuntu is more than happy to talk to. And don't talk to me about having to explain to India that no, I am not pirating Windows, I am merely reinstalling it, because it is so crappy that that is the only way to keep it functional is to reinstall it six-monthly.
[FUCK BETA]
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(-)
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).
kernel x or if I need to update to kernel y
So you are a fan of letter based versioning then?