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..."
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.
on to 3.11! Oops!
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.
A rose by any other name would still have thorns.
Linus said:
--
Linus agreed that if the VM is as good as it seems to be, indeed the upcoming release deserves to be called 3.0. But he also pointed out that there are many silent users who tend not to speak up until there is an official release. He asks, "people who are having VM trouble with the current 2.5.x series, please _complain_, and tell what your workload is. Don't sit silent and make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x thing."
---
So does this mean that us semi-power users should be going ahead and testing the 2.5 kernel? If so to what degree.. Should we be running 2.5 on our desktop boxes? What about video drivers (nvidia) and all that?... When does it actually get into the 'testing' time frame, hence things start to become stable?
Cheers
craz
stuff
Emacs adheres religiously to the maxim of only bumping up the release number for really major changes (i.e., those that created backwards incompatibility.). Consequently, they are on point release 21 or something--they have dropped the initial 1. or 2. because it apparently seemed redundant.
- SMJ - (It's not just a name: it's a bad aftertaste.)
As Linus said, it doesn't really matter what it's called, so long as people use it. Versions don't have any real technical meaning (other than the even/odd kernels which signify stable/development).
Since it doesn't have any technical meaning, it shouldn't be argued on technical merit. However, version numbers play a big roll in the business world. Business and marketing folk get the biggerbetterfaster vibe from increasing version numbers.
Several distributions just released new versions in the last couple of months, or are on the verge of releasing new versions. Redhat, Mandrake, Debian, etc. Good stuff. Let the hype play out, and don't trump it by releasing a Brand New Big Version Kernel that none of the distros contain.
Make this one 2.6. Technical people in the know, the ones who run the servers, the ones who really need the performance increases, will upgrade accordingly. Rumors in the press will be able to convince people that Linux is growing and kicking ass.
Make the 3.0 switch after distributions have caught their breath, and after some of the other nifty things that impact userland have been completed: the POSIX stuff, further refinement of the new VM system, FS improvements (resizing, reiser 4, etc).
Then everyone can whoop and holler about what a great new kernel it is, and how much more added value it gives to distribution version increments, etc. etc.
Linux is great technology. Fantastic technology. It's development shouldn't be dictated by fickle marketroids. But version numbers are the most publicly visible attribute of the kernel, and should be treated accordingly.
Yeah right..
2005-03-28: Debian 3.1 is released!
It includes the advanced Linux 2.4.8-kernel, KDE 2.2.1 and
four year old versions of another 20000 or so packages.
Get it here!
My other account has a 3-digit UID.
There's no 2.6 in the list of What Software Version Numbers Really Mean, so obviously it can't be 2.6. Therefore it must be at least 3.0. In fact, I'm stil confused as to how a 2.4 release got out.
I think we should speed up development and annoint a dedicated "version czar" who will make sure that the Linux kernels stay ahead of Windows. Hard as it may be, I'm willing to ``do my share'' and volunteer for this position. My first step would be to shift the decimal point 3 places to the right. This decimal has been hogging the #2 spot in the release number for too long; it is time it got relegated to the #5 spot, where it rightfully belongs.
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!
The truth is changing major version numbers would give the Linux business a major shot in the arm. Every press establishment would have no choice but to run a story about Linux and it's capibilities at a time when MS is chasing it's customers off, and everybody would have to upgrade their Linux mascot.
Do you really think there would be version wars if the announcments didn't make the participants money?
Novel theory: Modern Man evolved from psychopath
NT 4.0 is STILL NT4.0 despite the fact that most recent software REQUIRES a recent service pack.
I've taken up calling Microsoft service packs by major.minor.servicepack. Therefore, Windows NT 4 is up to 4.0.7, Windows 2000 is up to 5.0.3, and Windows XP is up to 5.1.1. Currently maintained IE versions are 5.5.2 (?) and 6.0.1.
Will I retire or break 10K?
"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?
Linux IV, becuase Free software needs free press, too.
-- @rjamestaylor on Ello
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.
Wow, KDE 2 is out?! I'll have to pick that up.
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden
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.
The change from 1.x to 2.0 was made at the time that the a.out format was dropped in favor of elf. But wasn't this just a library change? Anyway after 2.8 they could go to 2.10, no reason the second number can't be two digits. Still the changes to vm, and /dev alone might be enough to jump it to 3.0, especially if the changes for SMT with kernel pre-emption are added.
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!
Heck, Netscape even skips MAJOR version numbers (they skipped 5.0)
Microsoft skipped 91 major version numbers from 3.11 to 95...and it *still* wasn't much of an upgrade.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
Things just don't work like this. It's difficult to say before a release whether it will be extremely robust. The only way to test stability is to get a whole lot of people to pound on the kernel and find stability problems. Unfortunately, this doesn't happen until Linus declares that the kernel is stable. But he's really just saying "As far as I can tell, the kernel is stable."
Anyway, not everyone had results as good as you with the 2.2 kernels. In fact, you may recall that 2.2.0 wasn't stable at all; 2.2.1 was release shortly thereafter to fix a major bug. When I switched from 2.0 to 2.2, I had plenty of stability problems, mostly due to buggy drivers. Things gradually improved through the 2.2 releases, until I finally stopped having problems around 2.2.14. From looking at LKML archives, I suspect this is the norm, rather than the exception.
In fact, I would say that linux kernel development has the following general pattern:
"Any fool can make a rule, and any fool will mind it."
--Henry David Thoreau
No, as long as Linus is in charge there will never be binary compatibility of modules between minor kernel versions (or even different configurations of a single version, e.g. UP or SMP). Linus considers it too much trouble to be worth the effort.
/proc interfaces. There has been some talk about revising the module loading/unloading process (since the current methods still have some problems), but no action has been taken yet.
AFAIK the new driver model basically puts all drivers in a uniform structure, primarily for the purposes of handling power management (sleep states) uniformly, and of moving towards a simple, standardized layout for
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
If you really want marketing.
May we never see th