Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Linux Business Software Linux

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by 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 (Score:3, Informative)

    by GreyWolf3000 ( 468618 ) on Wednesday October 29, 2003 @01:44PM (#7339843) Journal
    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.

    • by wowbagger ( 69688 ) on Wednesday October 29, 2003 @01:48PM (#7339895) Homepage Journal
      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....)

      • Still haven't figured out how to convert from LVM 1 -> 2. Have a nice new kernel that I haven't been able to boot yet.

        • The LVM2 tools can read the old LVM1 disk format just fine, no worries. Just leave it LVM1 format until you're sure you'll never boot another non-LVM2/DM enabled kernel.

          - RustyTaco
      • Yes, that is pretty wierd. Upgrading glibc fixed things? I find that odd, since glibc is built against /usr/include's kernel headers, not whatever kernel that you're running. Since kernel headers are never symlinked, and instead copied, there shouldn't be any problems; glibc should happily use the old 2.4.x headers with a shiny 2.6.x kernel running.

        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


      • 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
        • One would expect that, were this missing code, it would fail on all versions of the kernel, not just the latest.
          • One would expect that, were this missing code, it would fail on all versions of the kernel, not just the latest.
            Were you using a custom 2.4, then?
            • I was using 2.4.22, and all was well.

              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.
          • by zenyu ( 248067 ) on Thursday October 30, 2003 @12:05PM (#7348679)
            I think this [ibm.com] 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.

    • (I accidentally cut a bunch of my post out)

      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.

      • by Anonymous Coward
        I have tried the Gentoo ebuild of 2.6.0-test9 and it works great!
  • by Bishop923 ( 109840 ) on Wednesday October 29, 2003 @01:46PM (#7339863)
    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? :-)
  • Andrew an Alan (Score:3, Interesting)

    by 4of12 ( 97621 ) on Wednesday October 29, 2003 @01:57PM (#7339968) Homepage Journal

    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)

      by devphil ( 51341 )

      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

  • by legerde ( 583680 ) on Wednesday October 29, 2003 @02:49PM (#7340456) Journal
    "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.
  • This is /. You should know that it's Linus, not Linux!

  • Anyone have any testing or feelings of how the 2.6 vs the 2.4-CK patches [optusnet.com.au] patches from Con Kolivas match up?

    The 2.4.x-CK patch bundle sure has made a difference, havnt used 2.6.x-TEST fulltime on a desktop yet.

  • by bruthasj ( 175228 ) <bruthasj@yaho o . c om> on Wednesday October 29, 2003 @06:35PM (#7342519) Homepage Journal
    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.
    • 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.

      5. "PGA."
      6. Prof... no, maybe not.

  • It's so damn frustrating: on the one hand the 2.6.0 kernels run really great, I finally have a decent Gentoo installation and now...

    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

A person with one watch knows what time it is; a person with two watches is never sure. Proverb

Working...