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.
The beauty of open source is that if you miss the odd-kernel numbering system more, you can fork the kernel and make your own! Yay! Enjoy maintaining both a stable and experimental code tree, constantly backporting important security fixes and features everyone wants, when you could just be modifying only one tree. Hope you have lots of free time!
This doesn't seem like breaking news to me. It's not even like he's talking about ceasing to use a naming scheme. The scheme is no longer used, now there's just a name. And the name is just a number, which no longer has any (other than historical) relevance. That's all we're talking about, in fact: Getting rid of a vestigial number.
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?
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.
Well, at least with the kernel, it gave me an idea of whether I ought to expect a program to run with few problems, require recompiling to work with few problems or require porting and compiling to work with few problems.
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
_I_ _Really_ _hate_ reading Linus' _email_ with all _his_ _underlining_ for emphasis!!!_-_-_-_ _REALLY_!
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
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?
(news report sometime around the year 2500) People everywhere are stocking up on food, water and buying up home generators. No one is sure what will happen with the next kernel release, now that the version number 2.6.~ will no longer fit with in the ~ byte memory space where it is stored in most computers. Experts are unsure exactly what will happen but some of the things which may stop working include the electric grid, airplanes and automated teller machines. On the plus side, computer technicians are finding it easier than ever to acquire jobs as companies scramble to switch to Mac OS XXX which though it is otherwise inferior has avoided this problem by incrementing it's major version number. Let's go live to the street and see what people have to say. Some random person: Well... I'm just about done, I have a month's supply of food, a generator and duck tape. I had to take out a second mortgage. It wouldn't be so bad if it weren't for the gas. It almost cleaned me out just getting here. I sure hope they come out with that biofuel stuff soon. I'm glad those flying cars never took off though, Windows crashed my engine 3 times just on the way to the store. It's a good thing I wasn't in the air!
* 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.
Never trust a man wearing a coat and tie!
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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
Beware of bugs in the above code; I have only proved it correct, not tried it.
What has the kernel to do with printer drivers? It has always been CUPS domain.
Back in my day, used lpd, AND WE LIKED IT!
--fatboy
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
I propose Offset 2000 version numbers, i.e., "(y-2000).mm[.dd]". The first number is the year minus 2000, followed by "." and a two-digit month, optionally followed by "." and a two-digit day when there's more than one release in a month. So version 8.07 would be the first release in July 2008. If you made a later release on July 17, it'd be 8.07.17 (so if a project makes many releases in a month, you can again determine how old yours is).
Date-based version numbers have a lot going for them, because at a glance you know when it was released (and thus you can determine how old something is). If you choose the ISO order YYYY.MM.DD, the numbers sort very nicely; Debian packages often use YYYYMMDD for versioning. But there's a problem: full year numbers, or full dates in this format, are annoyingly large. For example, version numbers 2008.07.16 and 20080716 are painfully long version numbers to remember. That's not necessary.
So, use dates, but shorten then. Since nothing today can be released before 2000, shorten it by subtracting 2000. Note this is subtracting - there's no Y2K-like rollover problem, because the year 2100 becomes 100 and the year 3000 becomes 1000. The second number is the month; using a two-digit month means you don't have the ambiguity of determining if "2.2" is earlier or later than "2.10" (you would use "2.02" instead). If you need to disambiguate day releases (or you make additional releases in the same month), add "." and a two-digit day.
These version numbers are short, they're easy to compare, and they give you a clue about when it happened. Ubuntu already uses this scheme for the first two parts, so this scheme is already in use and familiar to many.
If you use a time-based release system, using this version numbering system is easy, and you can even talk about future releases the same way. But what if you release software based on when the features are ready, or want to talk about the system under development? You can't easily call it by the version number, since you don't know it yet, but that's not really a problem. In many cases, you can just talk about the "development" version or give a special name to the development version (e.g., "Rawhide" for Fedora). If you need to distinguish between multiple development versions, just give each of them a name (e.g., "Hardy Heron" for Ubuntu); on release you can announce the version number of a named branch (e.g., "Hardy Heron is 8.04"). This is more-or-less what many people do now, but if a lot of us used the same system, version numbers would have more meaning than they do now.
- David A. Wheeler (see my Secure Programming HOWTO)
I don't see why everyone is in an uproar over this. I also don't understand how one man can decide to change the way things are because "26 is a big number".
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 based on user account deletion
No, what is hurting Linux is that numbering is way to geeky. The next version shouldn't be 2.6.X. For more widespread adoption, we might try cutesy names like Fluffy Rabbit to attract more females and kids. Or for professional sounding names like Tranquil. Of even more generic like Balls. That would be hilarious in everyday conversation. "Today I installed a new set of Balls at work." Hey why is everyone leaving? Hello, is anyone out there?
Man, you totally forgot the logo. That damned penguin is way too threatening and doesn't make any sort of political message. What we need there is a stylized picture of a group of hippies standing in a circle holding hands. Also, we need more than new version names, we need a new name, period. Stop calling it Linux because that doesn't mean shit. What we need is to find some vaguely positive word, translate it into a language used in some third-world nation, and use that for the name. What the hell is the Sanskrit word for "awareness", or some shit like that? Can we use that for the name of our OS?
If Windows had a kernel numbered 1.33.7
Funnily enough, the build number of Windows XP is 2600.
It's official. Most of you are morons.
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.
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.
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
Just roll three d20's.
When ideas fail, words become very handy.
"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.
Ok, but comparing two numbers in X.Y.ZZ form is much, much quicker than reading the release notes for every version change from 2007.047 to 2008.198. Plus you wouldn't have a way to figure out the approximate number of releases between the two versions.
Generally the point of version numbers is to know which is newer, or to be able to provide a range for compatibility ("my program FooBar is compatible with 2.6.20 or newer"). Switching to a date-based system does not assist with either need.
$50 is a moot number because consumers are not volume buyers. Let's check the facts.
Dell Inspiron 1420, Ubuntu,$449
Dell Inspiron 1420, Vista Home: $649
http://www.dell.com/content/topics/segtopic.aspx/linux_3x?c=us&cs=19&l=en&s=dhs
http://www.dell.com/content/products/productdetails.aspx/inspnnb_1420?c=us&l=en&cs=19l=en&s=dhs (starting price model)
Sooo... Facts prove my point. Microsoft is more expensive. Please adjust your beliefs to better reflect reality.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
But Windows NT kernel does not have version numberin, (for developers there must be) but OS has the stupid NT x.y numbering and marketing names XP or Vista. So user does not know that XP is NT 5.1 and Vista is NT6 and next one is NT7 (Windows 7) and so on.
C:\>ver
Microsoft Windows [Version 5.2.3790]
C:\>
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(-)
Well actually, Windows has version numbers too but it is not shown to the user unless you ask for it (eg. winver), but to be fair, the version of the linux kernel is usually not shown to the user either unless you ask for it (eg. uname).
Where version numbers tend to be relevant is usually related to drivers and hardware compatibility. This is also the case with the linux kernel, especially if you are dealing with the vanilla one.
It is useful for users to have some sort of numbering to also report bugs. I would hate to have to provide support when it is impossible to determine the environment which is causing a problem.
But it would likely be perceived a better finished product.
Tyranny isn't the worst enemy of a democracy. Cynicism is.
If Windows had a kernel numbered 1.33.7 with a beta name of "Loopy Longhorn", would it be a better finished product?
I painted racing stripes on my car so it can go faster
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).
Also the names are not very helpful. Imagine the configuration of apache was in files named as /etc/apache/{6f35ff5c-5bcc-420d-a1f4-8e37af8eaf06}
I've probably left my head... somewhere. Please wait untill I find it.
Homepage: http://blog.piechotka.com.pl/
Actually it seems like Vista now implements something called XPS for printing, the GDI path is now legacy.
Much to my disappointment they've published the specifications and made them available royalty free, rather than patenting a few vital bits and releasing the rest to printer manufacturers under NDA. Pussies.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Why bother with Linux?, get a proper OS.
But Netcraft said BSD was dead !
May contain traces of nut.
Made from the freshest electrons.