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"?'"
An excellent point, sir.
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.
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.
My blog
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.)