Torvalds: Test The kernel, 2.6 May Be Out In 2003

Jan Stafford writes "In this interview, Linus Torvalds talks up the test version of the 2.6 Linux kernel released last weekend. He also hints at when a stable, production 2.6.0 might be released." Specifically, Linux encourages big shops to test out the improved high-end capabilities.

Comments

Linux or Linus?

[Anonymous Coward]

Specifically, Linux encourages big shops to test out the improved high-end capabilities.

I simply must meet this Linux guy, no Linux company, no, no... ahhh damn.

Release date

[GreyWolf3000]

So with the above in mind, right now the tentative schedule is to release test10 in another week and let that just simmer for a while. If that looks like it might be 'the thing,' we'll end up calling it 2.6.0 (trying hard to avoid last-minute fixes). If we find any issues that need attention, we'll cut a test11 and so on, but the hope really is that we'll be done by early December.

If y'all want to see 2.6.0 by early December, get out and try it! I've been using 2.6 test kernels for a while, and haven't encountered any troubles.

Early December

[Bishop923]

Linus mentions that he hopes to have 2.6 out by "Early December". Who wants to take bets we aren't talking about December 2003? :-)

OK, I've had problems

[wowbagger]

Since installing 2.6.0-test9 under RH9, and after pulling the updated module-init tools, I had the following problems:

RPM died - had to get the bleeding edge version from Rawhide and install it.
Vi would coredump on exit - had to get the latest glibc* from Rawhide.
Wine died - still working on that one.

I had to fight to get the new module tools to load the correct AGPGART module to support the radeon DRI driver.

I'm a little worried that a kernel change is breaking fairly generic userspace apps like RPM and vi (Wine I can understand to some extent....)

Re:OK, I've had problems

[zenyu]

I think this documents the right glibc bug. The 2.6 kernel makes TSC support optional. TSC suffers from clock drift which is especially a problem when using frequency scaling or on NUMA systems. Instead you can use another timer. But glibc compiled for i686 uses TSC without checking for availability, because it assumes all those on that platform would have one. The 2.4 kernels always offered it on that platform so it wasn't a problem, now it is.

Andrew an Alan

[4of12]

The real test of 2.6.0 will be seeing if fantastic Andrew Morton can field the breadth and depth of kernel issues as well as the amazing Alan Cox.

Re:Andrew an Alan

[devphil]

Why is that the real test?

I choose particular models/versions of hardware and software based on many factors, and the champion individual maintainers have never figured into it. I'm curious why that should make a difference.

("Hey, you! Developer! The Customer says that the kernel version you required with our latest product sets the building on fire!" "But, but, but, that's a minor detail! The real test of the core of an operating system is how well the maintainer dude handles patches and bug reports! And this kernel version is maintained by a guy with cool hair, too!")

Sorry, I'm not flaming you, I'm just poking fun. Good maintainership means a lot to every project -- look how well XFree86 isn't doing in this regard -- but I'm missing how it's "the real test". Help me out here?

Something to notice:

[legerde]

"Anyway, I'm waffling. This is a decision that the IT center needs to make on its own." -- Linus.

Point 1: When would any corporate software PR person ever admit "I'm waffling."

Point 2: When would any corporate software PR person ever encourage an IT center to make a decision on its own. They would tell you that you "must" upgrade a pay because newer is better.

I'm Confused

[bruthasj]

Now, I'm a fan of open source and use Linux almost exclusively at work. But, I couldn't help but think about the different cultures we find in the different open source projects. It seems that we, as users of the projects, are taken for granted. Here, an open source project, is reaching out and trying to gain more tested systems by enlisting beta testers to go through the config; make; install process and run a few applications to see if it works.

But, see, this is where the fun ends. When there is a problem, what next? Well, it really depends, of course, on the user's tone. But, more often than not it depends on a given projects team and whether they're willing to take the criticism/bug report as something that will help improve their system even better.

In a majority of the open source projects you get one of the following as a response to your bug reports:

1. Developers begin to whine about how they lack funding.
2. Developers whine about how they're doing this in their free time.
3. The bug goes completely ignored for one or two years, then it's "magically" fixed in HEAD, which won't be available for packaging for another 3 to 4 months.
4. Someone says, "It works in HEAD." Then the next minor release, it's still broken.

Usually the above responses come with reports that talk about more aesthetic issues, but, sometimes even serious problems go neglected at times.

Anyway, the point is: project developers are wanting, are asking, for more users. With that request, developers need to realize what they're getting into. By complaining about lack of funding and using up their free time does not get past to about 1mm deep into the skins of the project's users.

If developers are spending their "free" time working on these projects, then, what, I ask, kind of time are the users using? I mean, there is some mentality among some projects that users are bloodsucking the life out of developers. Had it occurred to anyone that developers and users live out more of a symbiotic relationship improving the project on both sides?

I know this is a rant; I just needed to get it out the door. When Linus and other open source projects make a call for Beta testers, then they need to realize that the call might bring in users who aren't particularly adept at programming and/or have knowledge of the internals of the system. How many of us are scared silly to post even the simplest of emails onto LKML? Trust me, that mailing list isn't for the weak and prideful.

My call to developers is before you write that next email about how you're spending "free" time, think about and take for granted the fact these users are spending *time* to communicate with you! I know I'm preaching to the choir posting this to /., but I hope this comment is useful and that someone can extract a morsel of truth out of it.