Torvalds: Test The kernel, 2.6 May Be Out In 2003 59
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.
Linux or Linus? (Score:2, Funny)
I simply must meet this Linux guy, no Linux company, no, no... ahhh damn.
Release date (Score:3, Informative)
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.
OK, I've had problems (Score:5, Interesting)
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....)
You've had problems (Score:1)
Re:You've had problems (Score:1)
- RustyTaco
Re:OK, I've had problems (Score:2)
Look through kernel.org's bugzilla. I am not a kernel developer, so I can't really help you. Any references I made to "we" are made to "we who want 2.6.0 f
Re:OK, I've had problems (Score:2)
Vi would coredump on exit - had to get the latest glibc* from Rawhide.
Were you using a i686 version of glibc? There was an error where it assumed all i686 builds had some kind of timer code that is actually optional on newer hardware. I don't remember the datails, but I think the kernel hackers recomended using the same version of glibc, but compiled for i386, or using a newer glibc where the bug is fixed.
Could this have been part of your RPM problem too? glibc is a rather important library on your typi
Re:OK, I've had problems (Score:2)
Re:OK, I've had problems (Score:1)
Re:OK, I've had problems (Score:2)
I started using 2.6.0-test9 and things started acting strange.
I did find out that Wine didn't like using NPTL - removing that fixed the problems with it.
I did find out that Seti@home was a problem with Seti's servers.
BUT, that still doesn't explain why RPM and vi died.
Re:OK, I've had problems (Score:5, Informative)
Re:OK, I've had problems (Score:2)
I'll check to see if I have TSC support enabled, and see what happens.
Re:Release date (Score:2)
Basically, don't forget that "testing" in this case does not mean seeing if it works for you, but seeing if it doesn't work for you. Lots of folks have problems with it, and then just revert back to 2.4. We need people that experience problems to a) see if others are having that problem and have reported it, and if not, b) send a report back to Bugzilla [kernel.org]. Also, read This document [kernel.org] before sending any reports.
Re:Release date (Score:1, Funny)
Re:Release date (Score:1)
Early December (Score:5, Funny)
Re:Early December (Score:2)
Re:Early December (Score:2)
Re:It's crap! (Score:1)
$ yes > /dev/mem /dev/mem: Permission denied
-bash:
That's why you don't run everything as root. :)
Re:It's crap! (Score:1)
Nice attempt at humor. That might've been funny back in 1994
Re:Yes, but (Score:2)
Will it support Longhorn? Longhorn is the future of computing, man.
Well, the scary thing is that if Linus does pull off the december of '03 promise, and following linux's usual release cycle of '2 years between major versions', we'll be releasing 2.8.0 at about the same time Longhorn ships in 2006.
Re:Yes, but (Score:1)
Re:Yes, but (Score:1)
Andrew an Alan (Score:3, Interesting)
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 (Score:3, Interesting)
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 repo
Re:Promise RAID (Score:2)
Something to notice: (Score:5, Insightful)
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.
Re:Yeah, right (Score:1, Interesting)
We have i386 boxes running 2.4.10 with 16meg of RAM on a 32meg Doc. Go complain somewhere else or rebuild your kernel
Fer rastermans sake.. (Score:2)
This is /. You should know that it's Linus, not Linux!
Re:Fer rastermans sake.. (Score:2)
Re:Fer rastermans sake.. (Score:1)
Re:Fer rastermans sake.. (Score:2)
2.6 vs 2.4-CK (Score:2)
The 2.4.x-CK patch bundle sure has made a difference, havnt used 2.6.x-TEST fulltime on a desktop yet.
I'm Confused (Score:5, Funny)
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
You missed a couple. (Score:1)
5. "PGA."
6. Prof... no, maybe not.
Anyone else here experiencing system freezes? (Score:1)
On the other hand, my system freezes occasionaly during disc activity and/or when using the mouse or keyboard. Actually, I'm not really sure why or in what situations the system freezes. It seems to occur randomly, whenever there is some form of activity.
I have tried recompiling the kernels, leaving out certain features such as ACPI, APM, etc, but to no avail.
The 2.4 kernel
Re:Anyone else here experiencing system freezes? (Score:1)
Re:Anyone else here experiencing system freezes? (Score:1)
Re:Anyone else here experiencing system freezes? (Score:1)