Slashdot Mirror
Kernel 2.4.17 Out
ThatComputerGuy writes "Linux kernel 2.4.17 is final, with a lot of fixes/updates. Check out the huge changelog. If you're on a desktop machine, you should try using RML's preempt patch, it definitely helps response times."
← Back to Stories (view on slashdot.org)
It looks like we're actually seeing 99% bug fixes this time around, rather than new features being added. Yay for having a 2.5 branch, it seems to be getting the experimental code now. This may be the first 2.4 kernel I compile for my system (I'm not saying I'm still stuck in 2.2, just that I've kept the default 2.4 kernels from my Mandrake and SuSE installs). I also see a couple ext3 fixes, which means I'm pretty comfortable having this replace the patched-to-use-ext3 2.4.10 kernel in my SuSE 7.3 box.
My Greasemonkey scripts for Digg &
Looks like the new kernel maintainer is really working out. I enjoy seeing these kind of detailed changelogs, to determine whether there is anything critical enough to upgrade my system.
Seems like Alan and Linux lately haven't been all that hot about doing the drudge detail work. This arrangement seems to be the best solution for everyone.
A bios upgrade fixed the problem for me. Look for an update on your motherboard vendor's website.
Actually, there is a final 2.4.17 patch, but it's not on the page linked to. Go tom l/ preempt-kernel/v2.4/ and grab it from there (or use a mirror).
http://www.kernel.org/pub/linux/kernel/people/r
-Todd
"The details of my life are quite inconsequential..."
After several of the last few kernels being released with major bugs, I thought the consensus on LKML was to use -rc versions for bugfixes, and then release a 'final' without making any changes in it. Yet, when I read this changelog, I see that changes were made in the final version. A lot of people will only download a 'final' kernel, because they think that it contains only tested, stable code. That is what the -rc system was to ensure, but releasing a 'final' with changes means that a partially untested kernel is being released to the unsuspecting public. Now, I will admit that there's a very good solution that any user can implement - just don't upgrade. However, these recent quality control problems have given Linux something of a black eye in the public's mind. Therefore, it just seems common sense to not release a kernel with code that hasn't been in for at least one -pre or -rc revision. So, if I were a kernel maintainer, about to release kernel 2.4.18, and I received a 'critical' patch from a project maintainer, I'd make one last -rc release to ensure that the code gets tested before I release it. However, I'm not a kernel maintainer, so take this as you will. I don't mean it as a flame, and I think that Linus and Marcelo have done a wonderful job so far with Linux 2.4.
SSE requires some extra effort on the OS on context-switch, since the SSE registeres are not normally saved/restored (they are only available on SSE-enabled CPUs). So SSE has been unusable on K7 up until now since you might have your programs screwed up by a context switch.
-._''_.-
I had similar problems with 2.4.14 and the kernel preemption patch, but I'm running it against 2.4.16 right now with spectacular results. I can play a DVD full screen when the system load (i/o bound) is greater than 3 on my single-Athlon 900. No skips, pops, jumps, anything. Smooth as silk.
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
Rule of thumb: If it's in the base kernel sources, you're OK. If it's a patch to the kernel sources, be careful but not overly concerned. If it's a pre-compiled binary (even if only in part), be very cautious. Remember: Google is your friend.
Example: The Alcatel external USB DSL modem, for example, has a binary part that isn't fully SMP-safe. Because of that, it can't be used with the preempt patch even on a system with a single main CPU.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
If so, he would have to possess the kernel.org secret keys. If he does, we have some really nasty security problems that we didn't know about :-/
This isn't just an md5sum, it's a gpg signature. You can verify it as long as you have the public key, which is widely available.
Something I feel like asking as 2.4.17 (bz2) trickles down the connection at 0.2K/sec from Australia's Planetmirror...
The kernel's are posted in both GZ and BZ2 formats. What do you guys mostly use? I can't see much point these days with having the Gzip format, I mean is there still a point to downloading it? Or even having them available in that format?
From what I can see, removing the Gzipped versions
*reduces network congestion
*saves space on the mirrors
*saves space on local storage (yeah only a couple megs)
Of course, it requires more processing time to extract, but that seems to be no big deal these days. I'm pretty sure everyone has bzip2 installed , and those who don't can easily get it, so that can't be a problem.
So is it really just traditional reasons it's posted in Gzipped format? Tell me if I've missed something. It would be interesting to know what everyone thinks about this.
There are two things here. Preemptive in userspace, and preemptive in kernel space. Linux is preemptive in user space, meaning that when a process is running application code, it can be preempted. When it is running kernel code, however (ie. during a system call) the scheduler will not preempt the thread, even if a higher priority one becomes available. Essentially (on a single processor) the kernel code is cooperatively multitasked. Kernel code runs until schedule() is called to invoke the scheduler. Some kernel code paths are very long, which leads to long periods where the current process cannot be preempted, which kills latency.
Also, to expand on the original question, there are a couple objections to the patch: It has the potential total throughput, because more locking must be used since the kernel can be preempted at any time, not just at specified points. However, in practice, the effect on throughput seems to be negligible. It also increases complexity, due to additional locking, but most of the complexity is there anyway, in the form of the SMP locks.
A deep unwavering belief is a sure sign you're missing something...