login
Search
A recent lkml thread explored an interesting tangent when Jeff Garzik asked about what was to follow the 2.5 development kernel, "is it definitely to be named 2.6? Maybe it's just my impression from development speed, but it felt more like a 3.0 to me :)". Linux creator Linus Torvalds first suggested that there was no reason to skip from 2.5 to 3.0, qualifying it with, "But hey, it's just a number. I don't feel that strongly either way."
Ingo Molnar reflected on the significant improvements we've seen to the VM and the IO subsystem, going so far as to say, "I think due to these improvements if we dont call the next kernel 3.0 then probably no Linux kernel in the future will deserve a major number. In 2-4 years we'll only jump to 3.0 because there's no better number available after 2.8."
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."
From: Linus Torvalds Subject: Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice driver Date: Thu, 26 Sep 2002 16:07:06 -0700 (PDT) On Thu, 26 Sep 2002, Jeff Garzik wrote: > > no need to be mindful of that. > > Let's get it right, rather than rush it... Which imples that it's 2.7 material. For 2.6.x I care about getting the drivers _working_. The whole logging discussion with hardened drivers etc is _not_ adding value to normal people until much much later, and it sound very much to me like one of those patch sets that some vendors will care about deeply because they have some big company that cares and pays them. Those kinds of patch-sets sometimes never make it into the standard kernel. They have to prove their worth to real people first, and I could care less (but not much) about paperwork reasons. Linus
From: Jeff Garzik Subject: Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice driver Date: Thu, 26 Sep 2002 22:27:59 -0400 Linus Torvalds wrote: > For 2.6.x I care about getting the drivers _working_. Tangent question, is it definitely to be named 2.6? Maybe it's just my impression from development speed, but it felt more like a 3.0 to me :) Jeff
From: Linus Torvalds Subject: Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice driver Date: Thu, 26 Sep 2002 21:45:51 -0700 (PDT) On Thu, 26 Sep 2002, Jeff Garzik wrote: > > Linus Torvalds wrote: > > For 2.6.x I care about getting the drivers _working_. > > Tangent question, is it definitely to be named 2.6? I see no real reason to call it 3.0. The order-of-magnitude threading improvements might just come closest to being a "new thing", but yeah, I still consider it 2.6.x. We don't have new architectures or other really fundamental stuff. In many ways the jump from 2.2 -> 2.4 was bigger than the 2.4 -> 2.6 thing will be, I suspect. But hey, it's just a number. I don't feel that strongly either way. I think version number inflation (can anybody say "distribution makers"?) is a bit silly, and the way the kernel numbering works there is no reason to bump the major number for regular releases. Linus
From: Ingo Molnar Subject: Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice driver Date: Sat, 28 Sep 2002 09:46:35 +0200 (CEST) On Thu, 26 Sep 2002, Linus Torvalds wrote: > On Thu, 26 Sep 2002, Jeff Garzik wrote: > > Tangent question, is it definitely to be named 2.6? > > I see no real reason to call it 3.0. > > The order-of-magnitude threading improvements might just come closest to > being a "new thing", but yeah, I still consider it 2.6.x. We don't have > new architectures or other really fundamental stuff. In many ways the > jump from 2.2 -> 2.4 was bigger than the 2.4 -> 2.6 thing will be, I > suspect. i consider the VM and IO improvements one of the most important things that happened in the past 5 years - and it's definitely something that users will notice. Finally we have a top-notch VM and IO subsystem (in addition to the already world-class networking subsystem) giving significant improvements both on the desktop and the server - the jump from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4. I think due to these improvements if we dont call the next kernel 3.0 then probably no Linux kernel in the future will deserve a major number. In 2-4 years we'll only jump to 3.0 because there's no better number available after 2.8. That i consider to be ... boring :) [while kernel releases are supposed to be a bit boring, i dont think they should be _that_ boring.] Ingo
From: jw schultz Subject: Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice driver Date: Sat, 28 Sep 2002 02:16:34 -0700 On Sat, Sep 28, 2002 at 09:46:35AM +0200, Ingo Molnar wrote: > > On Thu, 26 Sep 2002, Linus Torvalds wrote: > > On Thu, 26 Sep 2002, Jeff Garzik wrote: > > > Tangent question, is it definitely to be named 2.6? > > > > I see no real reason to call it 3.0. > > > > The order-of-magnitude threading improvements might just come closest to > > being a "new thing", but yeah, I still consider it 2.6.x. We don't have > > new architectures or other really fundamental stuff. In many ways the > > jump from 2.2 -> 2.4 was bigger than the 2.4 -> 2.6 thing will be, I > > suspect. > > i consider the VM and IO improvements one of the most important things > that happened in the past 5 years - and it's definitely something that > users will notice. Finally we have a top-notch VM and IO subsystem (in > addition to the already world-class networking subsystem) giving > significant improvements both on the desktop and the server - the jump > from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4. > > I think due to these improvements if we dont call the next kernel 3.0 then > probably no Linux kernel in the future will deserve a major number. In 2-4 > years we'll only jump to 3.0 because there's no better number available > after 2.8. That i consider to be ... boring :) [while kernel releases are > supposed to be a bit boring, i dont think they should be _that_ boring.] > Ingo, I agree with Linus. My recollection of when we moved to 2.0 was that the major number reflected the userkernel ABI. I have no problem with a version 2.42 if things stay stable that long. I hope they don't but that is another issue. Version 3.0 implies incompatibility with binaries from 2.x The distributions can play around with version numbers reflecting the GUI interface, libraries or installers but the kernel major version should stay the same until binary compatibility is broken. When we move old syscalls (such as 32 bit file ops) from deprecated to unsupported is when we increment the major number. It may be that 2.7 will see the cruft cut out and be the end of 2.x but 2.5 isn't that. So far 2.5 is performance enhancement. Terrific performance enhancement, thanks to you and many others. But it isn't adding major new features nor is it removing old interfaces. In many ways 2.6 looks like a sign that the 2.x kernel is getting mature. 2.6 means users can expect improvements but don't have to make big changes. 2.6 is an upgrade, 3.0 would be a replacement. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email blocked] Remember Cernan and Schmitt
From: Horst von Brand Subject: Kernel version [Was: Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice driver] Date: Sat, 28 Sep 2002 11:40:22 -0400 Ingo Molnar said: > On Thu, 26 Sep 2002, Linus Torvalds wrote: > > On Thu, 26 Sep 2002, Jeff Garzik wrote: > > > Tangent question, is it definitely to be named 2.6? > > > > I see no real reason to call it 3.0. > > > > The order-of-magnitude threading improvements might just come closest to > > being a "new thing", but yeah, I still consider it 2.6.x. We don't have > > new architectures or other really fundamental stuff. In many ways the > > jump from 2.2 -> 2.4 was bigger than the 2.4 -> 2.6 thing will be, I > > suspect. > > i consider the VM and IO improvements one of the most important things > that happened in the past 5 years - and it's definitely something that > users will notice. Finally we have a top-notch VM and IO subsystem (in > addition to the already world-class networking subsystem) giving > significant improvements both on the desktop and the server - the jump > from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4. But is is as large as the jump from 1.2.x to 2.0.x? > I think due to these improvements if we dont call the next kernel 3.0 then > probably no Linux kernel in the future will deserve a major number. In 2-4 > years we'll only jump to 3.0 because there's no better number available > after 2.8. That i consider to be ... boring :) [while kernel releases are > supposed to be a bit boring, i dont think they should be _that_ boring.] What is wrong with 2.10, or 2.256 for that matter? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +[blocked] Universidad Tecnica Federico Santa Maria +[blocked] Casilla 110-V, Valparaiso, Chile Fax: +[blocked]
From: Linus Torvalds Subject: Re: v2.6 vs v3.0 Date: Sat, 28 Sep 2002 18:31:45 -0700 (PDT) On Sat, 28 Sep 2002, Ingo Molnar wrote: > > i consider the VM and IO improvements one of the most important things > that happened in the past 5 years - and it's definitely something that > users will notice. Finally we have a top-notch VM and IO subsystem (in > addition to the already world-class networking subsystem) giving > significant improvements both on the desktop and the server - the jump > from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4. Hey, _if_ people actually are universally happy with the VM in the current 2.5.x tree, I'll happily call the dang thing 5.0 or whatever (just kidding, but yeah, that would be a good enough reason to bump the major number). However, I'll believe that when I see it. Usually people don't complain during a development kernel, because they think they shouldn't, and then when it becomes stable (ie when the version number changes) they are surprised that the behabviour didn't magically improve, and _then_ we get tons of complaints about how bad the VM is under their load. Am I hapyy with current 2.5.x? Sure. Are others? Apparently. But does that mean that we have a top-notch VM and we should bump the major number? I wish. The block IO cleanups are important, and that was the major thing _I_ personally wanted from the 2.5.x tree when it was opened. I agree with you there. But I don't think they are major-number-material. Anyway, 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. Linus
As far as I'm concerned...
it outa be 3.0 considering how drastic a jump it is in performance alone. I/O, threading, VM - all of it is kicked into high gear. Thoughts?
Slow and steady wins the race
Let's not get too far ahead of ourselves now. Although the kernel
has come quite far, lets not forget how far is left to go.
These performance enhancements will probably put linux based systems
at the head of the performance pack, however, there is much in the way of features left to go. Take a look at the kernelnewbies status page, while it may not be a totally accurate picture, it gives a general guide for what was at least desired in the 2.5.x series.
There are probably things in that list that should be there before
3.0.x. And peek at the second list, which gives a little insight as to linux POSIX compliance, provided between the kernel and glibc.
Since its so close, why not aim for full POSIX compliance for a 3.0.x release?
http://www.kernelnewbies.org/status/latest.html
http://people.redhat.com/drepper/posix-option-groups.html
I'm looking forward to the vm thrashing control planned by rik being put in place, reiser4, mandatory access controls being put in place through the lsm, and IBM's evms, as well as online resizing support for each of the major filesystems.
Also, in retrospect, I know for a fact that I'm going to have to beat off the BSD users who will point and use this as an example of how "inconsistent" linux development is, bloating major numbers because
a few performance limitations were broken through.
Let's stick to the original plan, and have these performance enhancements well tested through a 2.6 stable series first, before slapping a 3.0.x tag on there.
-alan at cotse
Call this one 2.6
It seems like most of the stuff that's 'waiting until 2.7' are big structural changes, interface changes, etc. That seems like a more natural breaking point for 2.x vs. 3.x. Of course, then again, we're adding aio, direct I/O, O(1) scheduler, and lots of scalability changes -- it's a tough call. I still think this should be 2.6.
Basically, the major version number should rev when there's some fundamental change, for instance the ABI changes, the semantics of syscalls change, etc. That's when you rev the major version number.
Solaris is a prime example here, if you look at their SunOS version numbers. (Not the marketing-inflated Solaris version numbers as of 2.7 or so.) IIRC, SunOS 4.0.x ran on the last of Sun 3 series and the short-lived Sun 386i and bridged into the first Sparc-based Suns. SunOS 4.1.x (Solaris 1.0 through 1.1). There were a lot of changes in SunOS between 4.1.0 through 4.1.4, but none of them were big enough to warrant incrementing even the minor version number.
SunOS 5.0 (Solaris 2.0) earned a major-version increment when the kernel switched from its BSD core to an SVR4 core. (And looking at this timeline, it's evident that people really preferred the BSD version for quite awhile...) From that point, the version numbers were pretty sane. From 5.0 to 5.4, there was a new version every approx 6 months, which is reasonable considering that the new core was maturing. From 5.5 onwards, a new minor number a year. The jump to 64-bit between 5.6 and 5.7 only rated a minor version number tick.
(Well, ok, the marketing dweebs decided to jump from Solaris 2.6 to Solaris 7. ??!? We can filter those guys out. uname reports the real version numbers...)
My point? The only thing in that sequence that rated a major version number increment was the switch from BSD to SysV. Changing from 32-bit Sparc to 64-bit UltraSparc didn't rate a major number. Switching from 68K and 386 to Sparc didn't either.
I think Linux should follow a similar path. Maybe once we start adding all the Plan 9 abstraction features (we already have some) and make those the default modus operandi, then we can call it 3.0. Kinda like Solaris is doing for their next major rev....
Re: call this one 2.6
I enjoyed reading your informational comment.
Still, your central point was not consistant. 2.6 and 2.7 refer to an OS release number
the same as redhat 7 moving to redhat 8. Your linux distro, too, will reveal the real
kernel version number if you use uname.
Wow. That was interesting. I just got to correct a nitpick detail.
HAND! (Have a nice day)
Solaris 2.6 -> Solaris 7
Actually, the point of my ranting aside about Solaris 2.6 -> 7 was just that it was purely marketing driven. Otherwise, all the Solaris version numbers were as sane as the SunOS version numbers up to that point.
Slackware made a similar jump (from 4.x to 7, IIRC). Wheee....
My central point was that the Linux kernel versions, which are similar to the SunOS version numbers, should follow a similarly conservative path of increments. 2.6 -> 2.7 was a major jump interally (32-bit kernel to 64-bit kernel), and yet it was a minor version number tick.
RedHat, Mandrake, SuSE, Slackware and company can all get into version-number wars, with 8.0 or 10.x or whatever, just like Solaris jumped from 2.6 to 7. That's irrelevant to the kernel version number.
Solaris 2.6 -> 7
Slackware's reason for doing that and Solaris's jump from 2.6 to 7 were for different reasons. Slackware did it for "keeping up with the Jones's" reasons which was kinda daft.
What happened with Solaris was quite common in the commercial software world. SunOS 2.6 became a defacto standard that third party vendors targeted their software at. It gets to the point where calling the next version of their OS 2.7 would have caused lots of drones to say "sorry, we don't support 2.7, only the standard 2.6" even though the difference is less than between 2.5 and 2.6. The solution is to change the naming of the software and call it backwards compatible with 2.6 (even though it's an incremental change). It happened with the System x naming of Unix (which got stuck at System V) and it'll happen again with Solaris. When that gets stuck at Solaris 10.3 Sun'll probably bring out Ra-is 4 or something similar.
RE: Call this one 2.6
2.6 sounds fine. If you look at the feature enhancements from 1.2 to 2.0, the a.out only kernel replaced by ELF kernel.
There hasn't been a binary change made in the kernel, the other parts have changed, but its still binary compatible with 2.0, 2.2, 2.4 and 2.5
The micro^W stupid direction to go, would be a year number or two initial, like eXperimental Program!
I think it should be 2.6
2.6 uber alles
I agree. A certain giant Seattle-based software company insists that each upgrade is major, even though many are not much more than a graphical facelift (remember WinXP?) plus improving on their already legendary security. Just because VM is increased and more hardware is supported in the new kernel is not a good reason to make the jump, you could apply similar logic to any release.
Such a leap without a major compatibility change is just going to confuse people ("will my linux 2.4 programs work with 3.0?"). If the new kernel is that good it will sell itself, the good press will follow. Linux has a reputation for stability, and continuing a conservative/predictable numbering convention even with great performance improvements will make it that much more respectable.
Inflation is bad wherever it is found. Keep it 2.6, maybe when the world moves to DNA bioprocessors 20+ years from now it will be time for 3.0.
just to be devils advocate.
I tend to think calling the kernel 2.6 is the right thing to dotm however, things like the scheduler hints, driverfs, and even devfs, do require changes to many userspace programs.
Maybe if 2.4 was 3.0 more userspace programs would have been modified to use devfs. Right now many user space programs still default to using the /dev symlinks I keep.
Who knows if acls make it in as well, maybe it would be good to make it 3.0. Let everyone port their apps to the new standard, and make distributions clean up as much cruft as possible. If there are multiple changes that require lots of userspace programs to change in some way, a new version number is a fine thing.
That said I think most of these comments about marketing are kind of pointless. 2.4 got huge amounts of press. 2.6 or 3.0 will also get lots of press. And 2.6 or 3.0 will have lots of bugs, people who claim that naming it 2.6 will make it more stable are forgeting 2.4.
support for usb 2.0, Serial ATA?
Will 3.0 include support for USB 2.0 and Serial ATA? These are some of the big improvements now coming out, and if its to be called 3.0 it should at least include these, should it not? Also, will it include support for HD's above 137GB?
USB 2.0 is here now
I'm currently running USB 2.0 on my Shuttle ss40g. Kernel 2.4.20-pre2 now, but it was working fine under 2.4.18 too.
Porting
Hi,
Its interesting to here this.
I am trying to implement the USB 2.0 in 2.4.18 but fails,i am getting the error -90,while sending descriptor.
I have copied the USB source from the 2.4.22 in to 2.4.18 and changed the configuration for path but iam getting this error.
If u say me the manner how u used the USB2.0 in 2.4.18 kernel,it will be a great help for me.
With Regards,
naidu.
Bye.
support for usb 2.0, Serial ATA
Correct me if I'm wrong here, but, I don't believe that any software changes are required for the switch to serial ATA. It sounds strange, but from what I've read, the OS won't even know that the difference. The differences are essentially hardware to hardware, and get handled at that layer.
Serial ATA
While no changes are needed to use Serial ATA, you wont be able to use any of its extra features without updating the OS/drivers.
Re: Serial ATA
> extra features
Such as? DRM?
Meaningless
The number is meaningless. Who would we be trying to prove a point to by naming it 3.0? Would someone take it more seriously as a 3.0 instead of 2.6? Are enterprise rollouts going to be delayed because "I'm waiting till they release 3.0".
The number itself is meaningless. The only factor I can see is we'll suffer the same ridiculous high version number problem everyone else is suffering if we go for 3. Going back to the original argument of how Linux is pronounced, I'll quote Linus "Call it what you want, just use it".
customers. think about custom
customers. think about customers. Why doesn't MS call their OS Win 2000.2, Win 2000.3 ...? Exactly, cause Win XP sounds EVEN NEWER! and therefor better. (Even if it isn't)
..Just my thoughts thou :)
RE: customers. think about custom
Ehh, hate to break you style, but Microsoft does, in fact, have Win 2000.2 (except they call it, "Win2k Service Pack 2 / 3, etc.).
Hate to break YOUR style
Just start->run->comand and hit "Ver"
Then look at the REAL version numbers.
RE: customers. think about custom
Of course, Win 2000 is really Windows 5, XP is 5.1, so by your numbering XP SP1 is 5.1.1 etc.
no...
xp sp1 is 5.1.2600, same as xp without the sp.
even in the computer it's still 5.1.2600, ms just puts a service pack 1 tag on it.
I vote for 2.6 for the next version.
Complete OS vs Kernel
If you compare Windows to Linux, please keep in mind Windows is a complete OS (you need nothing else to use it, if you like working with programs like WordPad at least), while Linux is just a kernel (it would be better to compare Linux to SuSE or RedHat).
somewhat related
What happened with IDE? Did they just decide to keep the 2.4 stuff or is there going to be a new IDE?
IDE
They started work on a new IDE implementation, it didn't work out, so they reverted to the 2.4 version and started making incremental improvements.
2.4 ac work
Andre Hedrick is doing most of the IDE work on 2.4-ac kernels (there's a novelty idea, do development on the stable kernel) because of no moving target for the new API. Then when he and AC are finished he will up port it to 2.5.
Standard naming scheme?
I consider the "compatibility" thing a good reson for naming it 2.6. The VM and stuff are ground-breaking enhancements, no question, but enhancement in itself is business as usual and shouldn't mean bumping the major version.
Additionally, i believe that keeping the major version underlines the stability of the kernel in a subconscious way, indicating we're going the way step by step rather than skipping around...
blubb
call it what you want, i do not care if it is called 3.0 or whatever..
yeah!
just release it already :)
You already *do* have it!
http://www.kernel.org
The number is just an indication (theirs) of how much has changed. It *really* doesn't matter to everyone the same way what it is called. You can just go and download whichever version you want. That's the beauty of Free Software.
Go with version 3.
Go with version 3. Come on, all the cool people are doing it.
Stability and perception
On one end there are a lot of arbitrary things coming out of marketing dweebs that lack technical values. Some has good points and some does not. And on the other hand we as Linux developers/users want to produce the best possible products for joy, pride, recognition, etc.
These days it is not just a matter of either considering technical or marketing merits in what we do. The public perception, whether we like to or not, is becoming more and more important as our user base expands.
We did catch flak on stability issues on 2.4 for whatever the reasons. The way I see it we should not move to 3.0 until it's been running stable under at least 2.6. The less technical the person the more valuable perception becomes. By only moving to 3.0 when 2.x is seen as totally stable, more new (corporate) people will consider it as the foundation for their infrastructure. Look at views of 2.2...
Besides, stability must be more important than features!
steve szmidt
3.0 and bad press
This is not to detract from the revolution(s) in the new kernel one bit.
I hate to say it but Linux is bigger than it ever has been. That makes the number question relatively important, not to disappoint people and not to get too much bad press.
Reporters etc... will pick up on a pivotal number change and linux should be damn ready when they do. If linux wants to be seen as secure and stable we should act secure and stable whenever possible. 2.6
Alternately move it to 2.8 with instructions to really use it. If after six months the problems stop coming in go to 3. In the mean time you can start hammering away at 2.9 or 3.1. I know it sounds a little daft but it gets linux two news bytes and underscores its commitment to stability.
The other thing that being conservative right now might make easier is pressure on the person maintaining the stable kernel.
When you guys take your bows for kernel 3.0 lets not have any potshots from detractors.
Bosah
new device driver model
IMHO the version jump could be justified because of the new driver model and better hotplugging support. If many apps start to use them and will be incompatible with older kernel versions, a version jump seems appropriate.
Idea
Name it 3.0, it's gonna have support for the new 64 bit X86 arch right? I think that makes the timing correct myself.
A Simple Compromise
Here's what i suggest. Mind it's just a suggestion, and nobody will consider it serious, but i like to hear myself talk :P
First off I don't believe there have been improvements so vast as to support a change from 2.4 to 3.0, but it's just a number, as linus said. Secondly I do think more attention should be given to current code and stabilizing it. The 2.4 kernels i've used are abhorrently far less stable than 2.2 kernels of the same revision/minor number. I've also had a few issues with the current VM and feel that it's not ready for 3.0. But i'll live with it if we have to go there.
So here's my simple suggestion: release 2.6, then don't add a ton of features. Make it the most damn stable kernel you can. Then release 3.0. That way we have a way of justifying a 3.0 release (as it'll be stable enough for most any use) and can run from there with a much less buggy kernel.
Yours Truly,
An Appreciative Linux User
Please report these bugs
As Linus asked: please report all problems you have with the VM, so they can be fixed before the next stable version is release (whatever it may be, 2.6, 3.0 or whatever)
Go for 2.6
Reasons:
* 3.0 means stable, although most gurus would know that 3.0.1 would be better. Lets make 3.0 that stable.
* There are many more things to include in the kernel. Lets get those in there.. I've heard mentions of ACLs and seen many patches around, why dont we mainstream them? Make them ready for all users if they are not.
* Other goals and the todo list. Lets finish getting these other features in there and then stablise it.
* Ports - The 64 bit chips coming out.
Surely a jump to 3.0 could be made MORE worthy.
Re: Go for 2.6
> Reasons:
> * 3.0 means stable, although most gurus would know that 3.0.1 would
> be better. Lets make 3.0 that stable.
Nope. 3.0 doesn't mean stable, I think even the opposite way!
3.0 suggests there were major changes in the codebase involved, wereas 2.6 suggests there were minor features (e.g. new/updated drivers) and lots of bugfixes.
> * There are many more things to include in the kernel. Lets get
> those in there.. I've heard mentions of ACLs and seen many patches
> around, why dont we mainstream them? Make them ready for all users
> if they are not.
> * Other goals and the todo list. Lets finish getting these other
> features in there and then stablise it.
IMHO that would be the wrong thing to do. It's nice to have lots of new features, especially if you want to skip to the next major version number. But this also means that all these features have to be well tested, stable and well designed (not a quick'n'dirty thing that will be soon replaced by a full reimplementation). I think it's okay to include thinks like XFS, JFS, UML etc. since they existed quite a long time as seperate patches and were tested for quite some time by the linux community, i.e. they should be stable.
The less new features the less trouble. It's really difficult to find bugs when there a many potential places (new code) where they could be. That's one of the reasons why submitted patches are usually atomic, i.e. they just change small things or one thing at a time. A new feature therefore will be split into many small, atomic patches to make it more easy to see what patch introduced new bugs/regressions. Just look at the linux kernel mailing list.
> * Ports - The 64 bit chips coming out.
They are out already ;) (Sun/Fujitsu UltraSPARC/SPARC64, HP PARISC64 and DEC Alpha, MIPS64, IBM PPC64 and S/390). I think you mean Intel IPF (IA64) and AMD x86-64.
Personally I don't care whether 2.6 or 3.0. Jeff makes a valid point: It's a major difference in user experience, but on the other hand the other major releases where more due to severe API/ABI changes.
As much as I like big flashy numbers ;)...
I think we should keep it at 2.6, because if we keep following the version numbering scheme, then when it DOES hit 3.0, it will be that much better.
There is nothing stopping the
There is nothing stopping the numbering scheme from going to 2.10, or even 2.754 for that matter, instead of going to 3.0.
Backwards compatibility with 32-bit architectures
Linux already supports 64-bit CPUs, and it is already "backwards-compatible" with 32-bit CPUs. It does so by keeping the architecture-specific stuff in separate directories. So, if you want to add support for, say, the new sliderule 512-bit architecture, just create an arch/sliderule subdirectory, put your include files in include/asm-sliderule. You don't even affect the other architectures. So adding support for a new architecture won't break support for others.
re: 2.6 or 3.0?
Clearly the minor minor revision increments can happen past .9 (2.4.18), why can't the minor revision increments happen past .9 (2.10.1, 2.12.1, 2.14.1, etc.)?
So that brings to mind the question: What does categorize a major release?
Major Releases.
Well, there have been two major releases so far. 1.0 was released in 1994(?) and was the initial major release. 2.0 came in 1996, and sported two major architectural updates: modules and SMP support.
That should give an idea of the architectural differences needed to trigger a major release. On the horizon is NUMA, the support of which would be a good candidate for another major release.
3.0 only after 2.6 has become really stable
My experience with past kernels was, that the even the stable kernels (2.4.x and 2.2.x) where only really stable after x>12. So I suggest you call the next release 2.6 and when that 2.6 has become rock solid stable you call it 3.0.
A major release must be stable and well tested and most people don't test the unstable kernels. There will be a lot problems that pop up only after 2.6 is released. Don't be too fast or it may backleash on the reputation of the Linux kernel stability. Rather strife for an absolute stable 3.0 release. At the point where 2.6 is renames 3.0 the current development kernel 2.7.x should be renamed 3.1.x.
Let's not throw around big numbers unless those can be backed up by solidity.
3.0 will be a big theme in the news because of it's version number. Make sure it won't be a failure on reputation.
2.6 vs. 3.0
IMHO based partially on information gained by reading the posts up to this point, here is what makes sense to me.
1. If performance improvements are the only big change: 2.6
2. If functional changes that are big from an end user perspective (ie: plug-n-play, automatic driver/module discovery/downloads, etc): 3.0
3. If backward compatible (no ABI changes): 2.6 else 3.0
Having said that, I'd agree that if the preceeding logic ends up in 3.0, I'd still be tempted to put in a short term 2.x (meaning long enough to get some real implementations of the new features that caused the number to jump to the next version) to get as stable as is reasonably possible before releasing a 3.x.
pi.0
I think the real reason to move to 3.0 (or not) is for the developers to give themselves a pat on the back for a job well done. I have no patches in this kernel so my opinion on 2.6 vs. 3.0 really ought not to matter, and neither should yours if you haven't written code. This thread demonstrated just how arbitrary any move to a new major number is, so it might as well keep the kernel hackers happy. If they move to pi.0 it'd be all the same to me.
Why go from an odd minor number to 3.0?
I think it would be better to wait until 2.6 (or more likely 2.8) is at a respectable revision number then rename it to 3.0 (and the then development kernel to 3.1). Then you get a rock-solid major version release. That is to say, go to 3.0 from an even-numbered stable kernel, rather than an odd-numbered development kernel.
russian words
as low your speed as long way you go!(I dont known English language)
russian proverb
my translation:
the slower you go the farther you get
Where did all you "Marketing" people come from?
Version numbers are unimportant. The only people who care about them are the trolls in Marketing and Sales. Just start downloading the newest 2.5 kernel patches and start testing it.
--adam