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..."

Comments

Re:Consumer Marketing

[no soup for you]

To a consumer, 3.0 sounds like a better product than 2.6
My vote would be to make it Linux 10.0 to make it compatible with the SuSe & mandrake number systems. :-)

In my opinion a consumer will never notice the kernel version number. They'll see the distribution version numbers, but won't bother to check which kernel the system is using -- because to do so would mean they'd have to understand that a kernel existed in the first place.

Consumer marketing is irrelevant to the kernel

[BluBrick]

To a consumer, 3.0 sounds like a better product than 2.6

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

[yerricde]

"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:Hm

[stevey]

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.

Afterthought?

[ReadParse]

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

Should not be 3.0 until 64-bit through and through

[Krellan]

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!

You're all right, but I'm righter ;)

[ChrisJones]

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?