Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel 2.6.8 Released

Posted by CowboyNeal on from the compile-reboot-repeat dept.

J ROC writes "According to The Linux Kernel Archives kernel 2.6.8 is now out. It includes some fixes from 2.6.7. Happy upgrading." You may want to read this earlier story and think twice before upgrading.

6 of 203 comments (clear)

  1. 2.6.8.1 is really the latest by scotsgit · · Score: 5, Informative

    Due to an NFS bug a brown paper bag release was produced.

    1. Re:2.6.8.1 is really the latest by hrakers · · Score: 5, Informative

      See http://www.uwsg.iu.edu/hypermail/linux/kernel/0408 .1/2049.html for more info

    2. Re:2.6.8.1 is really the latest by Dave2+Wickham · · Score: 5, Informative

      From what I understand it's basically a release with a screw-up somewhere. A symbol of embarassment (don't know how to put that better...) is to wear a brown paper bag on your head. The dodgy release was embarassing, hence the brown paper bag release.

  2. 2.6.8.1 by calibanDNS · · Score: 5, Informative

    The latest is actually 2.6.8.1. The (very short) change log for that version can be found here. Looks like there was an NFS bug in the 2.6.8 release that needed to be fixed.

  3. Re:Summary? by Anonymous Coward · · Score: 5, Informative

    Lots of memory leaks fixed.
    Lots of USB issues fixed.
    A few patches for prism based wireless card too.
    Several filesystem patches:
    EXT3 deadlocks removed and buffer issue fixed.
    EXT2, Reiser + JFS I/O errors lost issue fixed.
    Network oops, I/O oops created in 2.6.7, smbfs + nfs oops, SATA + Highmem oops
    X86_64 Memory corruption fix's + "small + serious" bugs.
    New hardware support for latest VIA K8%, KT%, VT%, PM% chipsets.
    NX (No eXecute) support for x86

  4. Re:Codepage for FAT by Anonymous Coward · · Score: 5, Informative

    Most of the new options seem pretty normal, but can someone explain this "Default codepage for FAT" option? Cheers...

    This one goes to the stone age of DOS... Under DOS you could write file names that included ASCII characters with codes above 127. When first localized versions of DOS appeared, you bumped into what most people still don't understand today: under your local codepage (here we used to use CP 850, US one was 437) different codes represent different characters. Since we're talking about times when Unicode was still just a thought in some lonesome head, the characters you typed for filename appeared differently when DIRed under different codepage settings.

    Now enter 21st century... most of the charcter strings are already in one or the other UCS/Unicode format. This means that we're mostly talking about Unicode character "small e with caron", not the character 152 in CP 850. The problem you have with this is to guess what was the original codepage used to write the text file or filename so you can convert from Unicode to local CP and back.

    In MS Windows this is solved by defining default system codepage. If you're a long-time MS user, then you have basicaly went all the way from the end of '80s to now using default codepages for your particular region and all this is transparent to you.

    When you come to the Linux however, what particular application considers to be your codepage has no bearing to what the kernel wants to know about you. Kernel simply doesn't do codepages. Glibc can do them, but hardware as a rule doesn't care whether it runs in China or in US. Thus, for this particular FAT problem, you have to explain the kernel module what do you consider to be a default codepage so it knows how to convert filenames from disk to userland and back.

    In short: if you live in a region that considers ISO-8859-1 to be a default, then 437 is for you, if you live somewhere else, you probably already know all this, and you have only read it this far to see if you could correct some of more glaring mistakes I have made.

    Anonymous Cowards Unite