Kernel release status [LWN.net]

The current 2.6 kernel is 2.6.0. Linus released the second 2.6.1 release candidate on January 6 without an announcement; the (relatively small) list of changes can be seen in the long-format changelog. Previously, 2.6.1-rc1 (announcement, changelog) had been released on December 31. It included quite a few fixes, along with a couple of internal API changes (see below), the restoration of the old /proc/pid/maps formatting, the ability to compile with -Os on embedded systems, message signaled interrupt support (covered here last August), and extensible firmware interface (EFI) support.

Linus's BitKeeper tree contains a very small number of fixes added since 2.6.1-rc2 came out.

The latest tree from Andrew Morton is 2.6.1-rc1-mm2. Recent additions of interest include the laptop mode patch (see below), a mechanism for rate-limiting printk() messages, a number of architecture updates, and a great many fixes.

The current 2.4 kernel is 2.4.24, released by Marcelo on January 5. Unusually, Marcelo deferred the patches in the 2.4.24 prepatches and released a kernel containing only the mremap() and RTC security fixes and a couple of other small repairs. The previous 2.4.24 prepatches have been reissued (with the addition of some ext2/ext3 filesystem updates, a number of architecture updates, and various other fixes) as 2.4.25-pre4.

(Log in to post comments)

Kernel release status - typo

Posted Jan 8, 2004 2:18 UTC (Thu) by ds2horner (subscriber, #13438) [Link]

you meant 2.6.1-rc1 (not 2.6.2-rc1)
Being a newby it took me a while to figure this out.
I've greatly enjoyed your reporting.
(feel free to delete this once the typos corrected)

2.4 Fast Release Should not be Unusual

Posted Jan 9, 2004 1:59 UTC (Fri) by AnswerGuy (subscriber, #1256) [Link]

"Unusually, Marcelo deferred the patches in the 2.4.24 prepatches and released a kernel containing only the mremap() and RTC security fixes and a couple of other small repairs."

That's the way it should be. I think he should be publicly lauded for this just as I publicly lambasted him for failing to take this approach in the past.

Security fixes should take precedence; should be as immediate as they can be correctly tested, and should include minimal other changes. These allow the maximum number of potentially vulnerable sites to secure themselves in the mimimum time frame with minimal risk.

Do we need to draw a picture to drive this point home?

In the future we're likely to see more "flash attack" worms. Fully automated scripts that exploits a sequence of vulnerabilities in ubiquitous Linux software (the kernel, ssh, etc) to spread as widely as possible on "zero day." We're also certain to see more agressive "day one" activity (script kiddies and crackers who know of a vulnerability unleashing their attacks as soon as they hear that a given vulnerability or string of vulnerabilities has been patched).

These are inevitable consequences of systems that can be securely, reliably and automatically updated. It's evitable as Linux becomes dramatically more widespread.

2.4 Fast Release Should not be Unusual

Posted Jan 9, 2004 15:43 UTC (Fri) by wolfrider (guest, #3105) [Link]

> I think he should be publicly lauded for this just as I publicly lambasted him for failing to take this approach in the past.

--I agree. Yay Marcello! Huzzah!