Linux Kernel 3.0? 369
An anonymous reader writes "A discussion on the Linux kernel mailing list between Linux creator Linus Torvalds, Linux guru Ingo Molnar, and a few others debated the name of the upcoming stable kernel release. The choices: 2.6 or 3.0. Evidently there's been enough improvements, most notably the VM, that they're leaning towards calling it 3.0..."
It's all marketing (Score:3, Insightful)
Linux is not an underground system anymore -- it is a competitor in a business market and means billions of dollars to people and businesses, as unsuccessful [yahoo.com] as they may be.
Calling the kernel 3.0 is just a name, a marketing strategy, that will give the idea to people who aren't in the know that something truly significant and revolutionary has happened.
There's clearly a war going on between the idealists and the realists in that mailing list, and a simple number like "3.0" can make or break millions of dollars.
Re:Consumer Marketing (Score:4, Insightful)
Re:It's all marketing (Score:3, Insightful)
Actually, those people are already given warm fuzzies by the distribution version numbers. Non-geeks really wouldn't pay attention to the kernel version number, doubly so since it wouldn't have any _visible_ impact on the system's behavior.
Re:Take a lesson from emacs here (Score:2, Insightful)
they have dropped the initial 1. or 2. because it apparently seemed redundant.
I think you are arguing against yourself here. Wouldn't the situation be the same if they just called it Emacs 21.0, since the major has become irrelevant?
The minor has become the de facto major, is what I am trying to say. Their strict adherance to not incrementing the major has accomplished the opposite of what they wanted.
Consumer marketing is irrelevant to the kernel (Score:4, Insightful)
The Linux kernel alone is not a consumer product.
By itself, it is not very useful, but when you bundle it with a couple of hundred other utilities, applications and environments and call it a distribution, the distribution becomes a consumer product. When you strip it bare and embed it into a device, the device becomes a consumer product. When you load it onto a general purpose computer and call it an appliance, the appliance becomes a consumer product.
When it comes to the kernel, there is no need for consumer level marketing trickery.
"Linux kernel" because it's a trademark (Score:5, Insightful)
"Linux kernel" is redundant
No. Under USA trademark law, product and brand names are adjectives and should be followed by a generic noun. Thus, "Linux kernel", "Windows operating system", "Mac OS", "Macintosh computer", "Kleenex tissue", "SPAM luncheon meat", "Xerox copier", etc.
Re:This is the biggest problem with Linux (Score:3, Insightful)
Re:Hm (Score:4, Insightful)
Nope .. He always makes the speach go something like thigs:
"Linux is the kernel, which was written by Linus (and others). The distributions are the Linux kernel + GNU Utitilites - so Linux distributions should be called GNU/Linux"
On that basis the Linux Kernel is just Linux.
Re:guru? (Score:2, Insightful)
Remember that the Linux kernel is a compilation of hundreds of unique efforts by people with individual talents in each of their respective fields. There's physical and virtual memory, CPU slicing, SMP, filesystems, framebuffering, DMA access, scheduling, not to mention support for a plethora of hardware that exists on today's market - ranging from low-end to mainframe.
Per your assessment, there is potential for hundreds of Linux Kernel gurus. {smile}
Version number abuse (Score:3, Insightful)
I guess Linus is falling into the same trap as most other free software developers. Already in most software packages, version numbers provide nothing more than an ordered sequence of releases. There is no way to tell just by looking at a version number what ABI/API version is exported, whether it is a stable or development release, etc. Pathetic.
Afterthought? (Score:4, Insightful)
Don't get me wrong... I have all the confidence in the world in Linus, and he knows way more about what he's doing than I do. I'm just surprised that a project that organized wouldn't have a "3.0 List" by now of all the new stuff they plan to do in 3.0 one of these days... and when they start putting all those pieces together in a source tree, they would call that the "3.0 code" from the beginning.
At least that's the way I would imagine it. But don't miscontrue anything I've said as a suggestion that I have any idea what I'm talking about
RP
I prefer 2.6 (Score:3, Insightful)
If the VM improvements are really so cool. just stick them into 2.6, get it out the door, and save your grand schemes for the next release. I know it must be tempting to stick in the next great idea that seems just around the corner, but that just leads to endless delays and demoralizes the hackers that finished their work "on time" as they're waiting out to feature freeze while everyone else is still cleaning their code for release.
Ideal would be, I think, to call a 2.6 feature freeze very soon, and very shortly thereafter, open a 2.7 (2.9?) unstable branch where "anything goes."
Re:Hm (Score:3, Insightful)
Should not be 3.0 until 64-bit through and through (Score:5, Insightful)
I believe the Linux kernel should not be called 3.0 until it is 64-bit through and through.
The difference between 1.x and 2.x was a major architectural change: multiprocessor capability and portability to different platforms. The difference of 3.x should be equally as large: widening of all interfaces and data structures that are currently reaching their limits.
This includes 64-bit memory access, 64-bit file size access, 64-bit block counts on filesystems, and so on. Important external interfaces such as networking and filesystems must also be widened. A fully complete and robust IPv6 stack is a must: something that isn't quite there yet, but is getting close.
Essentially all fields in stat() require widening! Major and minor device numbers desperately need more room. Inode numbers and file size 64-bit, of course. Timestamps need to fix the Y2038 problem: 64-bit, possibly with added precision as well (to guarantee each file can be unambiguously sorted by time even on fast systems with such applications as parallel make). Security needs to be more fine grained (full ACL support). 32-bit UID and GID numbers. And finally, the filename itself needs to have full Unicode support without loss of field width (255 Unicode characters should be accepted). The output of the ls(1) command is a call to action: essentially every field there is in need of widening!
The main difference should be in the defaults: currently, standard stat() file limits and IPv4 are the defaults, and programs must go out of their way to request larger sizes (O_LARGEFILE) and IPv6. The programming model should be changed to provide programs with the widened resources as standard. This will take a long time, and is a gradual evolution, so there is a definite need for 2.6 and possibly 2.8 as transitional steps. The widening of these critical system resources is probably the main thing keeping Linux from large commercial UNIX installations!
Re:Testing 2.5 (Score:3, Insightful)
I tried 2.5.38, but then alas, nvidia does not support the 2.5.x series! After doing a little googling [google.com] I found that nvidia's driver is only broken on the source side (as opposed to the binary only part) and that people have had some success patching for 2.5.
Here's the best patch [xs4all.nl] I've found, it is for the NVIDIA_kernel-2960 (Thanks to Nicholas Petreley & Mark Hurenkamp). After adding a xfs cvs patch [profinet.sk] on 2.5.24-dj2 and recompiling the nvidia driver, my system was up and running (faster than ever).
The improvements in 2.5.x are wonderful, and while I agree with both Linux and Igno have to say, I too am leaning toward 3.0, but it's only a number; distros will happily roll whatever [improvements/number] Linus and friends gives them.
You're all right, but I'm righter ;) (Score:4, Insightful)
Those are all perfectly true and someone needs to work that out, not to mention work out if it really matters.
What I think really does matter is what the 3.0 release comes from, not when. I really wouldn't like to see 2.5 or 2.9 go straight into 3.0. Sure it may be a lovely new kernel, but if it's going to take until 3.0.14 to get stable enough, people are going to be unhappy.
I guess my suggestion therefore would be to turn 2.5 into 2.6, get it stable and into all the major distros, then run two development trees, an experimental 3.1 for way out new core stuff, but also a 2.9 that simply adds non-core things to 2.6 (e.g. Reiser4, EVMS, MACs, etc.) so that it has a stable base to sit on while integration work is done. The wonderous BitKeeper ought to make back/forward porting work done on each tree relatively simple, plus we get to announce a big 3.0 release that not only has tons of sweet new features, but also has many months of proven stability because it's core is really 2.6. Nes pas?