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.
Mirrors
News for nerds, stuff that matters...? ;)
"An infinite number of monkeys typing into GNU emacs would never make a good program."
".1" is the new archive format that Linus adopted with 2.6.7. Just google for "un1", then download and install un1, download the linux-kernel-2.6.8.1 file, cd to /usr/src, and type "un1 -r x ~/linux-kernel-2.6.8.1"
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.
Has the 2.6 branch been patched with exec-shield yet? I know there is some compatibility issues, but Linus said he was going to allow it anyway.
I scanned the Changelog briefly and didn't see anything major. I usually grep for 'thinkpad' or 'laptop' (my main system), to see if there is anything nice to try out. There are some laptop_mode improvements (disk IO buffering, keeps hard drive spun down for as long as possible) which should benefit any laptop user.
On occasion, someone will write up a nice summary of highlights. Anyone seen such a thing for 2.6.8?
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.
I care, I bet a lot of others care too. Thus /. is serving its purpose for me.
Upgrading your kernel is good for the soul.
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.
The OP asked if this Linux kernel version fixes the problem, the reply was that it did not involve the kernel.
The question is answered: No, this does not fix your bootloader. Not Grub nor Partition Magic; Neither Lilo, "the bootloader that has no name", nor any other bootloader are in any way altered by this software.
people who use NFS should wait for 2.6.8.1: 2.6.8 oopses with nfs
Linux updates aren't Slashdot's subject matter?
I hate memes as much as anybody, but... Are you new here?
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
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
Windows would write upper and linux would see it as lower. I'm hoping that you are the bearer of good news.....
Under MS Windows, when you write a filename that conforms into 8.3 format and consists of all upper-case characters, only basic FAT entry will be written, not the VFAT entry.
When you list the name of such file under linux, two things happen:
I belive that knowing this two rules, and behaviour of MS Windows, you will be able to find the solution to your problem.
Anonymous Cowards Unite
Since I'm running the 2.4 kernel without any problems, and I have had massive issues previously with a kernel update. As it is, I know I'm using a really old version of the 2.4 kernel, but I can't justify the risk in updating. I don't want to have to reformat my Linux system again.
Haec merda tauri est. Ceterum censeo Carthaginem esse delendam.
Hope your friends are ok! It's now too late in the day, my shortwave reception has dropped off. I saw some pics uploaded last night from another forum that showed some nasty destruction in I think port charlotte, someone still had net connection some how. Whole buildings smashed, etc.
I've been through at least three I can remember the names of, agnes, frederick and opal. Agnes I though we were goners, we were supposed to evac, but all we had were bicycles so we stayed put and buttoned it down, little duplex on the beach I had with two girls, hmm, this was 72. It flooded the block and tore a lot of shingles off, etc. the next day we wandered around looking at what we called sea monsters, all kinza huge fish washed ashore and stranded. It was quite the mess. That whole neighborhood is gone now, it's all very expensive beachfront high rise hotels, etc. That was at madeira beach florida. Agnes hit much further north, we only got the sideways edge of it and it was one spooky night, tell ya what. Frederick I was living in my VW camper at the time, I stayed down at the beach as long as I could to enjoy it,sto9rms are pretty nifty if you like that sort of thing, then went inland to some campground and parked it in the middle of a field away from any trees with the windshield pointed towards the storm front. Pretty high winds but I don't think they went past 70 mph or so, so it was like driving on the freeway but sitting still except for some rocking. That was outside tampa as well. Hurricane Opal I was up in atlanta, it churned it's way a;; the way up there and knocked down thousands of trees all over, lady up the street from me had a huge tree squish her real pretty old 60's barracuda. My landlady at the time evacced to her basement, a big tree fell, penetrated her roof and drove a tree branch right through her bed where she would have been sleeping. Man, I got a lot of free woodchips and firewood after that storm, the powerline guys were begging for places to put the stuff, so I filled my driveway with it, then used it landscaping, etc. What a mess that storm was.
I've also been through some dandy blizzards and floods and forest fires and tornadoes, which got ot be the worst I think because the destruction is so total. Seen most of the usual natural disasters except for a big earthquake, and I'll pass on that.
the kernel seems to have a rsync mirror. I haven't tried it yet, but that way you would be able to download the kernel in cvs style by only downloading what you need. this ofcourse only has a adventage when you download new kernel versions all the time, but most people that download from kernel.org seem to do just that. I also like the all in one package. this way I don't have bother 'bout searching for supported hardware. if it ain't in linus tree, it's not worth it for me.
Is there a simple way to know which kernel upgrades include security patches, and which do not? The changelogs are huge, it would be great if someone did the work and shared it with all.
2, 6, 8, who do we appreciate? Linus! Linus!
Try the stuff found in http://linux.netpimpz.com/mx700/, the very first hit on the most obvious google search.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
In my case, it was necessary to change Protocol to "ImPS/2" (from "auto") and add Resolution=400 (actually any number was ok, as long as the line was present). With Protocol="Auto" my mouse didn't work, so changing that might help you, too.
Adjusting the screen brightness makes a slightly larger difference, but not much (maybe 20 minutes between second brightest and most dim).
What really makes the difference is CPU load. If I run a lot of cpu-intensive stuff, and let the system adaptively raise the cpu frequency to handle it, it can cut battery life by more than half! Luckly I can comfortably play movies and do word processing with the CPU locked at the slowest speed (600Mhz), but to do much development work at the same time it really helps to let the cpu ramp up.
Thanks but neither worked. (Nor did the google suggestion from the other poster).
Here's more information on the issue (which is caused by the bootloader modifying the disk geometry reported in the partition table), including how to fix it.
-jim