Slashdot Mirror


Linux 2.6.26 Out

diegocgteleline.es writes "After three months, Linux 2.6.26 has been released. It adds support for read-only bind mounts, x86 PAT (Page Attribute Tables), PCI Express ASPM (Active State Power Management), ports of KVM to IA64, S390 and PPC, other KVM improvements including basic paravirtualization support, preliminary support of the future 802.11s wireless mesh standard, much improved webcam support thanks to a driver for UVC devices, a built-in memory tester, a kernel debugger, BDI statistics and parameters exposure in /sys/class/bdi, a new /proc/PID/mountinfo file for more accurate information about mounts, per-process securebits, device white-list for containers users, support for the OLPC, some new drivers and many small improvements. Here is the full list of changes."

9 of 288 comments (clear)

  1. Intelfb still broke by CRCulver · · Score: 5, Informative

    They have still not enabled mode switching in the intelfb driver on laptops, meaning that I am forced to use ugly, unaccelerated VESA instead of the right driver for this sytem. This bug has been reported on kernel dev mailing lists and forums for at least three years, but no one with the skills seems to want to fix it.

    1. Re:Intelfb still broke by Anonymous Coward · · Score: 5, Informative

      It's coming in 2.6.27 along with the GEM branch that was merged into master. Read Phoronix if you're into this sort of thing.

  2. Re:Real writeable NTFS? by Anonymous Coward · · Score: 5, Informative

    http://www.ntfs-3g.org/

    Not sure why it isn't in the kernel. But works great for me.

  3. Good Featurelist by Doc+Ruby · · Score: 5, Informative

    I wish every kernel release announcement included a highlevel featurelist like that. Not just a ChangeLog, as each bug is fixed or small feature is added. But rather a fairly highlevel list of new and improved (and fixed) features like the one in this Slashdot story. Best if in the announcement itself, but at the very least always in the release package.

    That way most of us can decide whether to upgrade, or to wait (perhaps for the x.1 version, which is typically a higher quality bugfixed delivery). Since kernel upgrades require rebooting (and again to downgrade after test), knowing whether to ignore a release based on its highlevel upgraded features itemization is a very effective announcement feature, which makes all of us using the releases more productive.

    --

    --
    make install -not war

  4. Re:Real writeable NTFS? by aliquis · · Score: 5, Informative

    Here: http://www.ntfs-3g.org/

    Why is it needed in the kernel?

  5. Re:Translation please? by JohnFluxx · · Score: 5, Informative

    Click the link in the story: http://kernelnewbies.org/Linux_2_6_26

    and it explains it all there

  6. Kernel debugger considered harmful by Linus by tucuxi · · Score: 5, Informative

    Reading on it, it seems that Linus never has been a great fan of kernel debuggers. From a famous post,

    I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. [...]

    I agree that stepping with a debugger instead of thinking real hard about the code (and using abundant log statements) is generally a waste of time, and that expecting to catch rare occurrences of weird race conditions with a debugger is not worth the effort. Sloppy programmers don't take the time to think, and rely too much on fixing what they could have not broken. Unit tests, although more expensive to code, can be reused many times - debugging sessions are one-shot.

    On the other hand, even good programmers can get stuck and benefit from a debugger every once and then. I guess this argument finally won the day.

    1. Re:Kernel debugger considered harmful by Linus by Fallen+Andy · · Score: 5, Informative
      These days I'm too lazy to bang around fiddling with OS's, but back in the early 80's when I ported the UCSD p-system to many machines, we didn't usually have *any* kind of debugger except our own log statements. So, one day I got given an Orion Instruments logic analyser (which could do hardware debugging for MC68000). Beautiful. Best productivity disabler I've ever seen. On the other hand, because of a really bad experience on my first p-system port, my own diagnostic code for a later port made me screw up my deadlines badly.

      With high level code, a decent debugger is really really useful. With low level code, not so much.

      (It's amazing though how many high level programmers don't understand the way debugging changes program behaviour (variable initialization etc - don't even mention heisenbugs)).

      The best ever debugger is the "cardboard man". If you really get stuck you explain the code to anyone (including the cleaner). That way, (even though the cleaner doesn't understand anything) you exercise another part of your mind and *see* the problem (... well here we shift left (wtf? right?) oops).

      Andy

  7. Re:Is Linux kernel 2.6.26 == Linux 2.6.26 ? by plus_M · · Score: 5, Informative

    Is Linux kernel 2.6.26 == Linux 2.6.26 ?

    Yes. When people refer to entire distributions as "linux" they are being technically incorrect, as the GNU folks are kind to point out at the drop of a hat. The entire operating system is GNU/Linux - Linux is just the kernel.