Slashdot Mirror
Linux Kernel 2.6.8 Released
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.
← Back to Stories (view on slashdot.org)
Because we all know no OS is stable without a few service packs applied.
Due to an NFS bug a brown paper bag release was produced.
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.
That didn't have anything at all do do with the kernel.
I believe that it was the way Red Hat installer, Anaconda, installed GRUB, the GRand Unified Bootloader, that was at fault. The Linux kernel is generally quite solid, and I certainly will be upgrading.
Finding a specific change from kernel ChangeLogs is like finding a girl on /.; you've heard rumors, but you'll never find what you want once you start looking!
"An infinite number of monkeys typing into GNU emacs would never make a good program."
I'm repeating this message from OSNews, which had the story first.
I think Linux is a great kernel, but a 42 MB download is really a bit too much for my liking. Much of that is code for hardware that I don't have or features that I don't want. I am a great advocate of modularity, and I would like to see it applied not only to the compiled kernel, but also to the sources. I am aware that this will add some administrative overhead, but it could save a lot of traffic and CPU time.
Here are some ideas:
- Split the distribution in a base that has the common stuff, and optional add-ons for lesser-used network devices, filesystems, etc. etc.
- Employ a BSD ports like system that downloads the sources on request (i.e. when compilation of some part is requested)
- Distribute only the configuration interface, and download only the parts actually needed based on the configuration selected.
I am too occupied now to come up with a proper proposal, but I hope this will set some people thinking.
Please correct me if I got my facts wrong.
Those problems were not in the kernel per se but in the way the auxillary pieces were deployed -- mainly the boot loader.
PS: This is being written on the system which which I had that issue. Solved now.
All my previous sigs now look like this one, I wish they were permanetly recorded when used.
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
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
A couple of things here. Sticking with 2.4 is reasonable, but running an old version of 2.4 is a bad idea IMO. There are enough security vulns fixed every few releases that I'd seriously consider patching, if I were you. Know how we all pick on Windows kiddes for not updating? Linux doesn't give you a free pass to run unsecure versions either.
Second, even if a particular kernel has issues on your machine, there is *no* reason you would have to reformat. Simply create a new entry in your bootloader and leave the old Kernel as an option. That way if you forget to compile something you need in, you still have the old kernel to fall back on. This is the reason why when my laptop boots up, GRUB offers me a choice of the stock Slackware 2.4 kernel, and 4 or 5 2.6 revisions. HD space is cheap and kernel binaries are small - there's no reason not to.