Slashdot Mirror
Linux Kernel 3.0?
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..."
Though some of the improvements may have been a real boost (the O(1) scheduler, etc), the decision to call it "3.0" won't come until some serious marketing decisions are made.
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 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.
If you blog it...
Uhh
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.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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.
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
"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.
Will I retire or break 10K?
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.
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}
BD Phone Home!
Shameless plug. Like you weren't expecting it.
Argh! The first digit in the kernel version number was always meant to indicate the ABI version! They should NOT change it from 2. to 3. unless they intend to make major (backwards-incompatible) changes to the kernel ABI. If they do this then we will lose the second-to-last piece of information in kernel version numbers. (the last piece being the even/odd stable/development thing)
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.
There's something strange about making a bumping a major version number as an afterthought, don't you think?
.
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
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."
If the distributions are the Linux Kernel + GNU Utilities shouldn't it be called Linux/GNU?
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!
Dr. Demento On The 'Net!
I'm a "semi-power user" and I had the same thoughts. Allthough I was kinda *forced* into testing 2.5.x because all the patches I wanted to 2.4.x wouldn't play nice together (preempt, O(1), VM, xfs) and they had all been merged into 2.5.
I tried 2.5.38, but then alas, nvidia does not support the 2.5.x series! After doing a little googling 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 I've found, it is for the NVIDIA_kernel-2960 (Thanks to Nicholas Petreley & Mark Hurenkamp). After adding a xfs cvs patch 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.
There have been some excellent and very valid points made in the comments here - bumping it gives a media boost because everyone will devote a few screen inches to it. That therefore needs to be balanced with a collection of new features that people can be sold on. "It runs millions more threads than you will ever see, it does it in the blink of a very small and fast blinking bat" isn't quite the same as "we put in all new disk management and resizing tools, all new enterprise-class filing systems, top notch new security controls..", etc, etc.
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?
Chris "Ng" Jones
cmsj@tenshu.net
www.tenshu.net