Linus says 2.6 kernel will be out by June 2003

Xpilot writes "C|Net reports that Linus Torvalds predicts 2.6 will be out by June next year during a talk on his Geek Cruise. Linus called the next release '2.6', but knowing him that may be just a working title;)" Update: 10/26 17:29 GMT by T : An anonymous reader adds "Rob Landley has published the latest list of features being considered for inclusion" in the new kernel; ... "the long and impressive list is available in more or less human readable form on Linux and Main."

Comments

WARNING: incorrect quote

[kryps]

He never said that.

Nowhere in the article did he even imply anything like the last part of this quote (it's an all-new instruction set that the Transmeta Crusoe processors can't emulate). If you wanted to make a point you should have put this statement outside of the quote.

I can't understand why the parent was modded up.

-- kryps

Re:It's "GNU/Linux 2.6"

[fok]

No.. this is just the kernel... and it is called linux

Robert Love predicts January 2004

[Xpilot]

In this interview with Robert Love in July, he predicted 18 months before 2.6 gets released(that would make the release early in 2004).

I'm more inclined to go with Robert Love's estimate considering 2.4's late release.

Offtopic : Hey, my story submission got accepted! :) Now that's a first.

Re:Robert Love predicts January 2004

[sagei]

In this interview with Robert Love in July, he predicted 18 months before 2.6 gets released(that would make the release early in 2004).

I'm more inclined to go with Robert Love's estimate considering 2.4's late release.

I think I may need to revise that (although I did go on to say a year from then, which would be summer of 2003)... the kernel is remarkably stable at this point and if we can stick to the freeze and get enough testers, I really believe we can have a code freeze in early 2003 and a release not too long thereafter. Five or six months from now seems very doable.

And I really encourage testers. We need you. Part of the VM debacle in 2.4 was we just did not understand the corner-cases because there were not enough testers testing on enough different machines on enough different workloads. We need to know where catatrophic VM failures are, where areas of high latency exist, and in general where the bad behavior is. This kernel is remarkably better in all aspects than 2.4... it is very smooth. But it needs testers to ease us into a stable release.

No more 9.9-pre-beta-5116.0002-r3-pre-patch-ac4-02

[dattaway]

To prevent this dreaded war upon version numbers, a good formula would be something like:

V=1-1/X

As your revisions increment, you will be closer to the famed 1.0 release, but never quite there. The press can always ask, "ARE WE THERE YET?" and always be told, "IN A FEW MINUTES!"

Re:Transmeta

[Anonymous Coward]

Friend, Linux is a registered trademark of Linus Torvalds. Using it in a diluted form, ("GNU/Linux") is against the rules. Please make a note of this in the future.

That feature list is just the late list

[Anonymous Coward]

That list is just the list of features that are not yet merged and thus need an imminent decision before the feature freeze next Thursday. It's also not especially long or impressive, since these are minor features and a much greater number of patches of that kind are already in. Of the stuff on that list, probably only IPSEC and one of the LVM replacements (needed since LVM1 has been removed) will impact most users, though the crash dumps would also be nice.

The significant changes in 2.6 will be the new block layer and attendant performance/scalability improvements, the new NPTL thread support, ALSA, and the XFS and JFS merges. See Guillaume Boissiere's list for more.

Re:That feature list is just the late list

[badhack]

It is the scheduler in 2.6. As far as I am aware, the only major shortcoming is it's lack of hyperthreading support.

badhack

Compatibility is not the issue

[mbrubeck]

Linux goes to 3.x when it breaks compatability with 2.x.

Nope. In this lkml thread, Linus says:

We've never had that as any criteria for major numbers in the kernel. Binary compatibility has _never_ been broken as a release policy, only as a "that code is old, and we've given people 5 years to migrate to the new system calls, the old ones are TOAST".

The only policy for major numbers has always been "major capability changes". 1.0 was "networking is stable and generally usable" (by the standards of that time), while 2.0 was "SMP and true multi-architecture support". My planned point for 3.0 was NuMA support, but while we actually have some of that, the hardware just isn't relevant enough to matter.

Kernel Traffic summary

[mbrubeck]

Kernel Traffic has a good summary of the 2.6 vs 3.0 discussion. In one post, Linus writes:

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.

Re:This just seems wrong...

[badhack]

Technically, they replaced the 0(N) with the 0(1) scheduler. :)

badhack

Re:I thought...

[Anonymous Coward]

yes, they do.
As a matter of fact caldera network desktop 1.0 ran linux kernel 1.2.13 and was elf based.
another example was slackware 3.0 which was elf and used kernel 1.2.13 I believed.
slackware 2.3 was a.out based, and it was the last a.out based distro by slackware.
RH 1.0 was elf, and it used a 1.2.x kernel.
so a 1.2.x could be ran on a.out or ELF, older kernels were only a.out, but newer ones had support for a.out for compatibility.