Slashdot Mirror


Linux Kernel 2.6.0-test10 Released

antrix angler writes "Linus Torvalds released the 2.6.0-test10 Linux kernel today, tentatively calling it the "stoned beaver" release. Linus plans to hand the kernel over to Andrew Morton in a few weeks, and then it will be up to Andrew to decide when we see the final 2.6.0 stable kernel. Download it from a mirror."

6 of 306 comments (clear)

  1. Re:Stoned Beaver? by samadhi · · Score: 4, Insightful

    Your boss would probably be more interested why you were running a test kernel on his hardware, rather than what code name it had!

  2. Re:Honest Question by crimsun · · Score: 3, Insightful

    I suppose the real answer is "it depends, but generally yes." I don't use kernel preemptibility, and it sure seems "feels" faster -- which is of course such a rambling description that it's difficult to qualify.

    I'll point you to the response I made here:
    http://www.osnews.com/comment.php?news_id=5208&off set=29&rows=30

    (Mine's #29.) Yes, I know it's much more so the combination of XFS and mm than it is just mm. I should amend that comment...

  3. Re:Stoned Beaver? by dumeinst · · Score: 3, Insightful

    I thought that since some big corporations like IBM and Novell are picking up Linux, things would get a little more professional.

    Why? so that yet another culture can get swalled into the soulless, humourless, corporate machine? I for one don't want linux to be synonymous with IBM

  4. Re:Honest Question by arth1 · · Score: 3, Insightful
    Is 2.6 really noticably faster than 2.4 for regular desktop use (X responsiveness, etc...)?


    No, it isn't -- it's actually slower, as it spends more time in the core kernel than the older versions. But it *feels* faster, because it is better at giving time to processes when they need it.

    Worst-case scenario: Start two CPU-bound tasks on a single CPU, and measure their performance.
    Best-case scenario: Start a huge amount of small tasks with unpredictable CPU needs, but which all in all saturates the bus. You'll see a gain.

    My guess is that the old kernel scheduler is a little better for games and single-application server-use, while the new one is much better for normal desktop users or overloaded boxes.

    Regards,
    --
    *Art
  5. Re:Honest Question by Richard+W.M.+Jones · · Score: 4, Insightful
    Thanks for that tip about renicing the X server. It made a huge improvement for me (using 2.6.0-test9).

    For reference here's how I fixed this, on my Debian machine: I edited /etc/X11/Xwrapper.config and removed completely the line which sets nice_value.

    If you don't want to restart your X server to make the change have effect, then you can instead do:

    renice 0 PID

    where PID is the process ID of the X server.

    Rich.

  6. Re:Udev by iabervon · · Score: 3, Insightful

    The reason that devfs is not yet deprecated in favor of udev yet is that udev depends on the kernel using the new driver model for everything that gets a device. Of course, that's not udev work per se, but it means that, for example, input devices (IIRC) don't yet work quite right with it.

    The kernel having explicit knowledge of what it's doing in a uniform format is a new feature in 2.6, and it's not completely universal yet. Once that all works correctly, udev should work perfectly, and it is a better design than devfs, because it puts device naming in userspace, but device numbering comes from the kernel, and the kernel tells userspace what each device actually is. This is how the division of labor is supposed to be: the kernel has internal information, which it maintains, and an API, which it defines, but userspace can use that API to specify policy.