Kernel 2.5.3 Released

cybercyst writes: "You know the drill... Lets go hit those servers!" As usual, see kernel.org for the download or the changelog. Anyone using 2.5 for anything except testing?

Comments

Small Notes

[worldwideweber]

(1) If you get any link errors when compiling your new kernel which refer to lock_kernel and unlock_kernel. Just add #include to whatever files generate the complaints.

(2) If you have any SCSI drives that were broken because of the Block IO Layer changes, then this kernel most likely fixes them. Apparently, the "various scsi driver fixes" includes the parallel port zip driver (ppa.c) for any who care :).

Patches!!

[The Pi-Guy]

Ok ok ok - we all know that kernel.org's got some cashflow problems, so people PLEASE use the mirrors and patches!! To apply the patch, from the older version, CD in, then use patch -p1 kernel-2.5.3.patch (or whatever.) Make sure to make clean first also, just for paranoia. Anyway, have fun.

--joshua
P.S. Not redundant, no one's said this yet.

Re:Patches!!

[GigsVT]

You know, the kernel.org guys never claimed cash flow problems, they just wanted another "main site" mirror for redundancy.

After the outage when /. ran the story, everyone just ASS-U-ME ed that it was cash flow problems, when the LKML archive clearly shows it was just technical difficulties.

That said, people should be getting diffs when they can anyway, there is no point in wasting bandwidth.

Re:Patches!!

[Phexro]

a better way to do it:

$ tar -xzjf linux-x.y.z.tar.bz2
$ sh ./linux/scripts/patch-kernel ./linux /path/to/patches

this will apply all the patches in /path/to/patches in the correct order to bring the source tree to the latest version you have a patch for.

Re:Patches!!

[hpa]

Technically it's feasible because many people has already done this for commercial servers. Is there any difficulties(political? Legal? Ownership?) make it impossible?

The difficulties are administrative/ownership. We (the kernel.org staff) has no real control of the mirrors, so I can't guarantee that any particular mirror is always up to date. For that reason, it seems more fair to let users at least know that they're using a mirror.

That being said, the mirror system participants provide a huge service, without which we would certainly have bandwidth problems.

Re:Use The Mirrors, Luke!

[tom.allender]

You should link directly to the list of mirrors.

Yeah, but not the list of sites that kernel.org mirrors themselves as they currently are.

http://kernel.org/mirrors/

mirrors

[Xandu]

Note:

mirrors.kernel.org is NOT the list of mirrors of the kernel, it's the list of mirrors of other sites.

For the kernel, you want www.kernel.org/mirrors/ to find your local mirror of kernel.org (which is usually www.COUNTRYCODE.kernel.org).

Re:mirrors

[hpa]

We don't have any problem covering our bandwidth bills, because ISC graciously gives us bandwidth at no charge. I would like to get another server for redundancy, but that's a completely different issue.

As far as mirrors of other sites are concerned, that's what class-based queueing is for. If we are saturated (which we rarely are) traffic gets prioritized, with outbound mirrors getting high priority and our mirrors of other sites getting low priority.

Nathan Scott: extended attributes ??!

[Adnans]

But where is XFS? Extended attributes (arbitrary tuples for files) support would be cool. But we need XFS for that since that's the only Linux FS that supports this right now, I think.

Re:Using it?

[MindStalker]

No, the point is that 2.4.19 should be fixed, but it isn't. Luckly pathes (these exist in the windows world too) exist, to give you this same functionality in the 2.4.18 kernel untill .19 is ready. For example you could have practically patch windows2000 to reach the stability of XP while waiting for XP to come out. Same thing, just not as simple to understand all the time.

Re:What I'd like to see in "New Kernel" announceme

[jsoderba]

Have you tried reading the Linux Weekly News kernel update? Reading that every week keeps me quite well informed. For instance, this week's (or next week's, depending on how you look at it) kernel page reads

The current development kernel release is 2.5.3, which was released on January 30 (changelog). The biggest change in the more recent prepatches has been the split of the massive (> 1MB) Configure.help file into multiple, smaller files spread out over the source tree. This change will make those files easier to maintain (it is hoped); in the mean time, however, it has broken a number of the configuration tools. Other changes include a large ReiserFS update and the inclusion of Nathan Scott's extended attribute patch, which paves the way for access control lists and other useful stuff in the future.

And it goes on into more detail after that. The previous issue talked about the new ATA drivers.

(I'm not affiliated with LWN. I just like the service.)

Re:Future of Linux kernel

[Deven]

I hope you moderators appreciate this is just this guy's idea, and not actually the current release versioning system used for 2.5. The fact that he made 2.5.3 bold would lead you to believe otherwise.

Actually, it was my idea (posted to the linux-kernel mailing list on May 10, 2000), but the other poster above didn't bother to attribute credit for it. (Although I think it was really more of a sarcastic comment on 2.5.3's stability, the way that section was bolded.)

That was an idea I came up with off the top of my head, looking for a way to move the "should be stable but oops, not" kernels out of the "stable" series into the "development" series (thinking of 2.2.0 for example) -- by adding a fourth digit to indicate the status, so that release candidates could get production testing before getting branded as "stable". Once a fourth digit was added, I figured that I might as well try to fill in the other numbers with vague-but-useful state indicators for earlier stages of development. That post to linux-kernel was my first attempt, off the top of my head.

I developed this idea further, in response to some of the discussion on linux-kernel about my idea, but in the end I decided against using it. My brother convinced me that encoding this much meaning into numeric identifiers required a lot of advance knowledge about the system to make any sense of the version numbers, and harried system administrators wouldn't take the time to learn.

I finally decided to use a different approach, where "stable" releases are all-numeric numbers (e.g. 1.0.0) while "development" releases always contain an alphabetic intended-state tag (e.g. 1.0.0.beta.1) and discarding the even/odd notion from Linux. This way, development versions are more self-identifying, and release candidates (suitable for production testing) would have an "rc" tag (e.g. 1.0.0.rc.3).

The idea is that the "stable" release (e.g. 1.0.0) would be completely identical to the last "rc" release (e.g. 1.0.0.rc.3) except for the version number change. If there's a temptation to add "one last patch" (no matter how minor), make a new "rc" version and let it make the rounds first. This would avoid embarassments like 2.2.0 and certain 2.4.x releases, which are marked "stable" by their version number, but were quite unstable in practice...

I tried to include my writeup of the all-numeric system I ended up with before I gave up on it, but Slashdot's "lameness filter" rejected it. Maybe it's a sign. :-) (Interested parties can send me email and I'll mail a copy of the writeup...)