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"?'"
Re:Linus... (Score:1, Interesting)
And when he writes stuff like
http://article.gmane.org/gmane.linux.kernel/706950
it just goes to further your point.
(anon for karma backlash)
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?
Re:Linus... (Score:4, Interesting)
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)
Rename article title as "Linus on Crack". You are right, Linus is now only Linux's second greatest advantage, Andrew Morton is the greatest. Linus has always been erratic but great. Lately, he really stepped in it a lot, but he is still maybe the best bug hunter that ever lived. Mind you, he tends to have a large hand in creating the horrible complexities that lead to the need for the bug hunt in the first place, but then if he did not we would never have the pleasure of watching him exercise his art.
http://lwn.net/Articles/215868/ [lwn.net]
And yes, I agree, Linus is on crack about the version numbers. Just drop the 2. at the beginning and it will all be fixed.
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.
Re:Linus... (Score:4, Interesting)
Might also point out that the kernel driver maintainers have a standing offer: anybody who provides specs gets a free driver written, maintained, and kept in the kernel. Companies should be developing hardware specs and taking advantage of all that free development work.
Maybe what we should be doing isn't writing an NDIS wrapper for Linux, we need to write an NDIS wrapper for Windows. That way companies can provide the specs to the Linux team and then use the wrapper to drop them into Windows as they are written.
Suggestion: "offset 2000 dates", (y-2000).mm[.dd] (Score:3, Interesting)
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 [debian.org]. 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 [ubuntu.com], 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.
Re:Linus... (Score:4, Interesting)
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.
Exactly.
It was written by Greg Kroah Hartman who famously broke the Philips webcam driver, causing the maintainer to quit.
http://www.smcc.demon.nl/webcam/ [demon.nl]
Re:A suggestion (Score:1, Interesting)
Instead of posting stupid complaints, why don't you:
a) Realize that the task of the kernel is supporting USB, paralel, serial, bluethooth, etc. Considering this, The Linux kernel has support for ALL Printers. Then it's the task of CUPS or LPD to support your actual printer, as long as the port for your printer exists in the kernel.
b) Don't complain, Develop. You Can't develop? Offer a bounty to anyone that develops what you need. You don't have money? Shut up.
This is developed and supported by the community. We don't need anymore lurkers. Contribute, or shut the fuck up and use what's available.
Re:It also reflects... (Score:5, Interesting)
Talk about rose tinted glasses.. The 2.4 /2.5 split that I remember left me at times with TWO unstable kernel series thanks to 2.5.x not being ready for production yet and maintainers trying to backport drivers and to 2.4.x so it could still handle the latest hardware.
At the worst of it I recall setting up a state of the art server with a SCSI card that crashed randomly on 2.4.x and wouldn't boot on 2.5.x series kernels. Lucky for me the bug was fixed in 2.5.x a week later.
The new way is easy.. new features and drivers get added to the latest 2.6.x-rc only and only bug fixes get added to the old kernels. This means that if I want to be sure I'm rock solid I just install the latest patch to the kernel I'm running and I can be sure no one has tried to add new features or drivers that would otherwise destabilize my stuff.
Why anyone would possibly want to go back to the old way is beyond me.
Re:Linus... (Score:4, Interesting)
Show me where I said it's easy. I said that changes are frequently trivial....
Stability doesn't mean the interface never changes. Stability means that interface doesn't change on a whim... That small changes should be rolled up to minimize the frequency of changes. That compatibility changes should be announced well in advance. That two kernels with the same name and version number from multiple distributors provide the same interface... It means that backwards compatibility should be a goal, but not that you can't break it.
"Stable" doesn't mean "supported forever". It means "changes as little as possible".
I'm not sure how you derived the "Solaris kernel engineers are idiots" argument from what I said. Whomever (and I'm sure it wasn't an engineer) decided that maintaining compatibility was more important than fixing a security hole, is an idiot. If breaking compatibility is what you need to do to fix a serious issue, then you break compatibility. If you think I was saying meant that Solaris engineers should have been able to fix the security issue and still maintain compatibility, you need to go back and read what I said again.
Re:Define "lots" (Score:5, Interesting)
You are wrong (Score:2, Interesting)
$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 [dell.com]
http://www.dell.com/content/products/productdetails.aspx/inspnnb_1420?c=us&l=en&cs=19l=en&s=dhs [dell.com] (starting price model)
Sooo... Facts prove my point. Microsoft is more expensive. Please adjust your beliefs to better reflect reality.
Re:Linus... (Score:3, Interesting)
Sure... For "free". Unfortunately upkeep can simply mean making sure the driver compiles... Or disabling features and reducing functionality until the maintainer re-adds it (as was the case in the instance that led to the creation of the "api_nonsense" document in the first place).
And then there's the definition of "free". What is the cost to the vendor to put their code in the mainstream kernel? Sometimes feature-rich drivers are sold independently of white-box hardware. (I have written such software under contract in the past and, in fact, make my primary living doing such work) You're basically saying that device-level software isn't fair-game for commercial development... Only as a carrot to support hardware sales.
Lastly there are people who use code that interfaces to the kernel for private use. Code that probably isn't interesting to anybody else, and wouldn't be accepted back into the kernel anyway, or can't be submitted for security-clearance reasons, etc... These people are "users" of the kernel too, and they deserve the same stability as users of the system call interface (or at least a basic attempt at stability).
Regardless, we've gotten off on a tangent on whether closed commercial development is appropriate, which pretty much illustrates my point. That's what the debate is really about when it comes to stabilizing interfaces. Not that the kernel will get "crufty".
Re:Linus... (Score:3, Interesting)
Let me give you an example device, and based on that you may or may not chose to reconsider your position.
Consider a Fibre Channel HBA with a storage virtualization processor on it. Depending on the driver software, it has the power to be a simple HBA to connect you to a storage array, a RAID card, a CDP processor... If can fully virtualize your storage, perform optimizations based on what arrays it's connected to, or it can provide base functionality. The simple functions of the device are basically the same as any other HBA, but the more complex functions haven't even all been dreamed up yet, and some that have require dozens of developers working on the code for years.
Should all the code that runs on that device be GPLed and in the kernel tree? Does it really seem unreasonable to be able to sell a closed-source driver for that device?
Now, consider that many other devices contain programmable elements like DSPs, Video Processors, etc... Devices that don't simply need a driver to connect them to the rest of the system... Devices where the driver defines the functionality of the device...