Linux Kernel 2.6.3 Has Been Released [updated] 72
justinarthur writes "At 04:36 UTC, Linux kernel version 2.6.3 has been made available. As is typical, downloaders are advised to utilize a mirror upon file availability. There are many changes from version 2.6.2, including recent ALSA patches, XFS fixes, and updates in many other areas." Update: 02/18 14:15 GMT by T : Peter Willis points out that kernel 2.4.25 (changelog) was also released, and writes "Incidentally, a security advisory dated today states there is an exploit in kernels up to 2.4.24 and 2.6.2, but the two releases today don't seem to reflect any changes, so get ready to patch up as soon as a patch pops up. More details on the vulnerability here."
Re:Gentoo disappointment... (Score:5, Informative)
Btw, the problem was that 2.6.1 actually supported the 103rd European key, and users couldn't cope with that. Now (2.6.2+) it's treated like a regular backslash key, even though they're two different keys in reality.
Changes include (Score:4, Informative)
network driver updates, compiler warning fixes, PPC updates, a major ALSA update and SCSI updates, NFSv4 update, XFS fixes, ARM and sparc updates
Changelogs.. (Score:5, Informative)
2.4 kernel tracking can be done here [bkbits.com]
Re:Changes include (Score:2, Informative)
out-of-the-box ppc/ppc64 support, complete with G5 support (64-bit), large radeonfb driver updates, IDE oops fixes (and cleanups), and a SELinux update
Slashdot really should consider linking to kerneltrap for each kernel update that has to be reported...
Re:Is any distro already with 2.6 kernel series? (Score:5, Informative)
improvements are nothing short of stunning, but I haven't tried it yet.
Re:Is any distro already with 2.6 kernel series? (Score:5, Informative)
OTOH, even without rebuilding glibc to take advantage of the new kernel-based pthread support, I have found really nice interactivity improvements on the desktop. It's really quite nice, I wouldn't want to go back to 2.4.
Comment removed (Score:5, Informative)
Re:distributions (Score:2, Informative)
Re:distributions (Score:3, Informative)
Re:TODO: (Score:3, Informative)
Done [netsonic.fi].
Many's the time I've been guily of awhen awould have done just as well...
Re:Great work! (Score:3, Informative)
It still crashes :( (Score:3, Informative)
The lockup can be easily triggered by running "hdparm -t
I know, I know, it's easy (as well as unfair) for me to bitch and moan, since I'm not a kernel developer. But knowing that there are patches out there that could solve this problem, but still haven't made it into the kernel, it's frustrating.
For what it's worth: I haven't noticed any speed advantages between an APIC-enabled and non-APIC-enabled kernel, so I guess it's not too much of a loss.
Does anybody here have any better experiences with this?
Vulnerabitily fixed in 2.6.3 and 2.4.25 (Score:5, Informative)
Re:SCO's code is available for perusal (Score:4, Informative)
http://linuxupdate.sco.com/scolinux/SRPMS/ [sco.com]
The thing is they are compliant to the GPL :-)
Today they put up a new web-based "buy a year's license for the SCO IP" thing on their website. But why bother when you can license any SCO IP under the GPL irrevocably and for free, from the same website? Its just madness from SCO.
ACPI cure for 2.4.25 HOW-TO (Score:5, Informative)
The cause is a brand new ACPI implementation which has a cutoff date of January 1st 2001. If your computer's BIOS is older than that, any ACPI support that might be present will be completely ignored by the kernel. ACPI hacker Len Brown explains that while the cutoff date is indeed arbitrary, it was already being used by certain distributions who noticed a pattern in when BIOSes with broken ACPI support where manufactured, so the ACPI hackers stuck by that concensus.
If you know for fact that ACPI worked fine on your computer until 2.4.21, you can enable it again: the cure is to put acpi=force in your bootloader configuration options.
Len also noted that there might eventually be a whitelist of older BIOS versions whose ACPI support is spotless. If you feel that your motherboard is one of those that should be whitelisted, file a bug at Kernel.org [kernel.org]. Len makes absolutely no promise whatsoever that such a whitelist will ever be implemented, but still leaves the door open for people to manifest their interest via the above bug report form.