Slashdot Mirror
Linux Kernel 2.4.6 Released
If the prospect of fireworks wasn't enough to make you happy today, there's a new Linux kernel in town. (Note: be patient; some of the mirrors aren't yet updated.) sheol writes of the new 2.4.6 release: "Yep, it's out there. Run, jump, dance in the streets. Drink and be merry. Prepare yourself for a full kernel recompile." Reader dschl says: "Looks like fixes to the Reiserfs bugs in 2.4.5 are included." Here's the changelog as well.
The change from 2.2.x to 2.4.x is surprisingly painless (much less painful than any "user-level" major change, like back when the day when going from libc5 to glibc2 practically needed reinstallation of the whole dist). No recompilation or reinstallation of stuff was necessary.
Personally, the only thing that needed special attention was the firewall thing, and even that wasn't top priority (because the kernel has an ipchains comparibility mode). Ultimately, the conversion of my firewall script from ipchains to iptables was rather easy.
Well, not exactly wrong :)
The bigger problem is finding out what exactly is wrong. The only information available so far has been reverse engineered (AFAIK) and posted on the 3rd party site viahardware.com. So far all the information we have is "before BIOS update X" and "after BIOS update X" snapshots of the system setup.
It's pretty easy to figure out real quick which systems are broken. It's tougher to figure out what is broken, and what the right fix is.
No doubt I am biased, but I disagree.
There are noteworthy VM fixes, buffer I/O deadlock fixes, and vfs fixes.
Plus the usual raft of driver fixes and merges from Alan Cox's tree. See Alan Cox's changelog as a supplement to the official changelog from Linus. Linus compresses many changes from Alan into a single word in the changelog, "merges."
LWP's are Solaris-specific. Linux threads are implemented as processes which share memory, filehandles, etc.
Linux threads can't block other threads since there is no difference to a process. And offcource, a process can't block all other processes ;-)
You may want to switch to another pthreads implementation. Quite a few (at least three) implementations exist and you're probably using the all-userspace implementation. This one simulates threads in userspace and doesn't use native threads.
AFAIK the later glibc 2.x implementations use native threads.
This is your sig. There are thousands more, but this one is yours.
Well, not exactly wrong. What I gathered from the kernel mailing list, the problem seems to be that VIA has shipped a whole series of different chipsets with bugs using the same version number. The problem is that there is no way one could make a nice workaround. As the owner of a motherboard with a VIA 686 chipset I can assure you that is a real PITA. I encountered the most horrible lockups. Luckily enough I had a Promise ATA100 PCI controller and ever since I put my HD on that one my system has been rock solid.
-- Spelling and grammar errors tend to be a sign of erroneous thinking.
I have been reading Kernel Traffic regularly (looks like there's a new one tonight incedentally). Seems like there are some problems they've been having trouble sorting out. To my knowledge (again, limited to KT), they are still pending and in fact the latest kernels would be considered rather unstable for a stable series. In particular, the Virtual Memory subsystem has problems. I don't understand the details but higher memory systems >256MB can run into FS corruption. And last I heard they've written off VIA as an incompetent chipset manufacturer meaning they haven't a clue why VIA machines lock up. Someone *please* flame me for being wrong!
I believe that despite what the documentation says, any thread (at least under pthreads) that performs disc IO may block the entire process and prevent other threads from running. This is a problem the Flash high-performance web server had to get around by using multiple processes just for disc IO. Can anyone tell me categorically that this bug has been fixed or give me some idea of when it will be fixed?
Allow me to remind you not to download the WHOLE kernel tarball over and over again.
Use the kernel patches and patch your kernel source as described in the Kernel HOWTO.
This will save you precious time, bandwidth and will cause less load on the servers.
I've always used Windows NT based OSs on the desktop and Slackware Linux on the server.
People seem to think they have to choose between the two operating systems. I used them both at the same time. They both have advantages and disadvantages. Windows is a well rounded, stable workstation OS, Linux is a stable, powerful server OS.
In reverse, I would consider them both to be useless. Why sacrifice one set of advantages? Use them both!
xx Stuii!