Linux 2.4.16 Released

tekniklr writes: "They just released Kernel 2.4.16. Download it here, and you can read the changelog here. This hopefully fixes the error that 2.4.15 had of corrupting filesystems on unmount." Update: 11/26 14:14 GMT by T : p.s. Don't forget to look in the mirrors.

Comments

Linking

[jeriqo]

Current bandwidth utilization 96.75 Mbit/s

Out of 100mbps..

Linking directly to the .tar.gz from the slashdot homepage was not a good idea, timothy.

You should have pointed to the mirrors, instead:

Re:Linking

[jeriqo]

Considering that the people who downloaded the 2.4.15 kernel got their file-system crashed, i guess they will have to re-download the whole 26MB package :)

-J

What's the best kernel?

[Griim]

I've been following all the kernel releses, and their bugs. I was just curious, what is the best way to tell which kernel is currently the most stable, without jumping immediately to the latest release? Obviously there is no way of knowing if it is, without it being out there for at least a couple of weeks.

I was hoping that kernel.org or somewhere would list what is currently the most stable. I know that from roughly 2.4.5 through to 2.4.11 or so suffer from some sort of swapping/memory leak, I can't remember. This is just from loosely following what has been posted to slashdot in the past few weeks.

Is there any resource tracking for this? What is the most stable of the latest kernels?

Re:What's the best kernel?

[ajs]

What's the best way to tell which kernel is best? Run it for about 2 months on a wide variety of hardware, with a wide variety of software loads. Record incidents and map those against known problems, apply available patches for those that will impact you the most. Re-test.

Then again, your distribution vendor already does this, so why would you be grabbing the latest development release (don't let the term "stable" fool you, that refers to interfaces, not field performance)? Red Hat is now up to 2.4.9 . I know that there's a lot of work going on in the VM world, and it seems to have been sorted out, but as you are noticing, there are other things in the kernel besides VM. If you want a kernel whose performance charactaristics are known, and whose primary bugs have been addressed, you have to sacrifice bleeding-edge fixes.

Not an easy pill for the "I want my tarball now!" world of Open Source, is it? Look on the bright side, 2.4.9 updates from Red Hat on 11/2 beats the heck out of the too-little-too-late geological updates from any closed-source proprietary OS vendor. Q/A is hard work and cannot happen in zero-time.

Open Letter to Linus

[jd]

This is ONLY a suggestion, not a flame. But could you please make better use of that -pre qualifier? Don't be in such a rush to make releases. Sure, the essence of Free Software is "release early, release often", but that's what the -pre stage is for.

Kick back, relax, take it easy, and run some automated burn-in tests for the kernel. Releasing code doesn't need to be a strain, or rushed. Remember, you're not doing it for "them". There is no "them", except in Sci-Fi, or paranoid extremist literature. Rushing is a self-inflicted injury. If you need to do self-harm, use a rubber razor-blade or something.

Many of the major shifts in the kernel have been the Right Thing To Do(tm), but those are the times you need to relax -MORE-, not less. Anyone with a penguin as a mascot understands cool. Cool is good. Cool is exactly what that penguin needs. Cool is what YOU need. You can't run at top gear, indefinitely, and expect to be even close to 100% of your ability.

As I recall, we went through something in excess of 120 pre-releases for one early kernel, and other early kernels often went through 20-30 pre-releases. (Oh, for the days of using a-z for the pre-release number! Sometimes the kernel fell off the end of z, and I think that was part of the incentive to switch to numbers.)

When Alan Cox maintained his series, he would often get into the tens, I suspect much for the same reason. A kernel is a complex thing, and the interactions can be hideously obscure. It takes a lot of testing and validating to work even just the worst of these glitches out.

If we reach 2.5.0-pre100, with the understanding that 2.5.1 will be solid enough to do new work, without forever struggling to figure out if a bug is in new code or a cold kipper from 2.4.x, nobody is going to complain. Well, nobody with any sense. The rest we can secretly smuggle into Afghanistan, where nobody'll care what they think.

I'd rather see 2.5.1 for Thanksgiving -NEXT- year, than be unable to do any serious development work for it. A solid foundation and a late, but perfect structure, is a billion times better than a sky-scraper made from twigs and built on straw, even if the sky-scraper is built on time.

You, like anybody, are undoubtably feeling all sorts of pressures - from work, to the family, to the economy, etc. Many of those pressures are bogus. Worrying about job security won't give Transmeta a greater profit. If it itches, scratch it (just be careful what you scratch in public), and if it doesn't, forget about it. You don't need to go creating problems. We have a Government to do that for us.

None of what I've written is new to you. Little, if any, is probably new to anybody. But it's all stuff we need to hear, from time to time. And when I see someone who is no idiot repeatedly making some very basic coding errors over a relatively short time, I think it's not unreasonable to think that there's a guy who is burning themselves out in the hamster wheel of life, and that that guy might benefit from kicking back & kicking the wheel over. Sometimes we go the furthest by making the least effort.

Re:how to implement ext3

[Draoi]

You need to get the latest e2fsprogs (1.22) and the latest util-linux (2.11). Don't install the
login utils if you're installing from a source tarball instead of an rpm.

When done, type "tune2fs -j /dev/hdwhatever". Done! A journal will be created automatically. Remember to only run this on a clean ext2 partition (make sure you're not running 2.4.15! :) ). If you're going to convert over the boot volume, make sure ext3 is built into the kernel and not a module. You shouldn't have to set any particular LILO flags (I didn't & I'm typing this
on ext3/2.4.16pre1). Update your /etc/fstab to show the new filesystem type.

Not sure about the Slackware stuff, but I doubt if there are any config file changes.

Andrew Morton's EXT3 page has all the details.

2.4.16 and ALSA

[pwagland]

Well, this was posted for 2.4.15, but it is also relevant for 2.4.16:

While we are talking about incompatible kernel patches, please be aware that ALSA 0.5.12 does not work under 2.4.15. You need to get the CVS version, as described here . ALSA 0.5.12 compiles, but does not work.

9 paranoia-steps for upgrading out of the bug.

[aussersterne]

0) Make sure you have compiled and installed a patched kernel.

1) "shutdown now" or "init 1" as root to go single-user.

2) sync

3) umount all non-busy filesystems (usually only root is busy for most people).

4) sync

5) mount -n -o remount,ro /
(so now the root filesystem is read-only -- this step *is* important).

6) e2fsck -f /dev/partiton
(once for each partition, starting with root [/] device, substitute e2fsck with reiserfsck, etc., as necessary -- force a check on each filesystem)

7) sync, hit reset

8) make sure not to ever boot into the buggy kernel again!

Release? Mabe this was an escape...

[IdleMindUI]

Perhaps we've got some Klingon Programmers working on the kernel now.

8) "What is this talk of 'release'? Klingons do not make software 'releases'. Our software 'escapes' leaving a bloody trail of designers and quality assurance people in it's wake."