Weekly Edition
Return to the Kernel pageSponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Quotes of the week
-- David Miller
-- Jeff Garzik (among others) is concerned about the current development model.
(Log in to post comments)
Stabilization is for Distibutors
Posted Oct 8, 2004 2:19 UTC (Fri) by miallen (guest, #10195) [Link]
How many Linux users download their kernel from kernel.org? If you want stability use a distro that picks a kernel and then goes through cycles of regression testing and patching. I believe RH does this. If you want a consistent non-changing interface then stick to POSIX or only interfaces that survived one minor number (ie 2.4 -> 2.6). I would rather give the developers freedom to be creative so they can have fun which encourages them to work on it and let the distros do their job in creating a nice hardend kernel for mainstream users.
re: Stabilization is for Distibutors
Posted Oct 8, 2004 12:45 UTC (Fri) by cajal (guest, #4167) [Link]
I, for one, always use the kernel.org kernels specifically because I don't want one patched with who-knows-what. And I utterly fail to understand why so many Linux users just chant the party line that "stabilization is for distributions" -- why is it so unreasonable to expect the kernel developers to stabilize and test their code before they release a "stable" kernel? If the only test for a "stable kernel" is "does it compile on x86" then they might as well not bother calling it stable. It makes no sense for RedHat, Novell/Suse, gentoo, et al to all do duplicate testing and patching.
Stabilization is for Distibutors
Posted Oct 8, 2004 16:16 UTC (Fri) by giraffedata (subscriber, #1954) [Link]
I agree with that. But we have a real problem to face: distributors have not yet accepted that responsibility.
AFAICS, they still use the same kernel maintenance methods they did when kernel.org had someone (e.g. Marcelo) maintaining a stabilizing yet not antiquated version. I.e. they frequently replace their "current" kernel with the highest numbered even-major release from kernel.org. To do what's required with 2.6, they would have to branch off of some kernel.org version and for a long, long time add to their branch only low-risk high-reward patches, while kernel.org marches on. Like Marcelo.
Is any distributor doing that?
Stabilization is for Distibutors
Posted Oct 10, 2004 22:27 UTC (Sun) by miallen (guest, #10195) [Link]
AFAICS, they still use the same kernel maintenance methods they did when kernel.org had someone (e.g. Marcelo) maintaining a stabilizing yet not antiquated version. I.e. they frequently replace their "current" kernel with the highest numbered even-major release from kernel.org.. Well, I'm still using RH 7.3 on my laptop so things may have changed but last I checked what you say is/was not really true for RH. If you looked at the kernel spec file and the tarball that was in the src.rpm it was actually some particular starting kernel version that was heavily patched. Newer releases were the same kernel with an extra few patches. They were NOT stock kernel.org kernels. Also, the OSS shotgun testing is fundamentally different from a controlled testing environment like RH uses to test the whole system under load. IIRC there have been consecutive kernel.org releases that were plauged with problems (e.g. VM thrashing). I think RH dealt with that better. At least they did not just "replace their 'current' kernel with the highest numbered even-major release from kernel.org".
Stabilization is for Distibutors
Posted Oct 10, 2004 23:20 UTC (Sun) by giraffedata (subscriber, #1954) [Link]
I agree that it's an oversimplification to say that Red Hat "replaces" its kernel with something from kernel.org. Red Hat never ships kernel.org kernels.
I also agree that Red Hat ignores some kernel.org releases.
But based on the naming of Red Hat kernels, it appears to me that they track kernel.org pretty closely. Within a few months of 2.4.X appearing on kernel.org, Red Hat has a kernel called 2.4.X-Y and doesn't support anything earlier. I guess Red Hat might be carefully scrutinizing all the changes from kernel.org and omitting destabilizing ones, but I think only a modicum of that could be practical and consistent with the naming.
By contrast,that practice isn't going to cut it with 2.6. Red Hat needs to change its kernel much more slowly than Linus changes his to have a viable commercial product.
Stabilization is for Distibutors
Posted Oct 14, 2004 6:44 UTC (Thu) by wmshub (guest, #3995) [Link]
If you are using the Red Hat enterprise, then they clearly do *NOT* put things out without a lot of testing. RHEL3's latest kernel is based on 2.4.21 - with, of course, a very large number of patches. RHEL isn't planning on releasing a 2.6-based version until around next Spring - a year or more after 2.6 was out!
So I think that, for enterprise products, Red Hat does test very well, and very differently from kernel.org. I haven't used SUSE et al, but I would guess that they would do the same.
Now if you're on Fedora, you are getting something with a lot less testing...but then, if you really want high stability (for example, if your business depended on the system's stability), then you wouldn't be on Fedora.
Stabilization is for Distibutors
Posted Oct 14, 2004 20:07 UTC (Thu) by huaz (guest, #10168) [Link]
If the mainline kernel is unstable, all distros are affected. Why is it so hard to understand that? Are the employees in vendors smarter than those woking on the mainline kernel and able to make better kernels? Geez, I'm so tired of such excuses.
Stabilization is for Distibutors
Posted Oct 15, 2004 0:32 UTC (Fri) by amikins (subscriber, #451) [Link]
That's just silly. The parent of your comment was talking -stabilization of interface-, not stability of code. The expectation is that if you need something that works in a consistent way, you need to be pulling your stuff from someone that agrees on the consistent way it should be done.The mainline kernel has to fit a lot of possible roles, and so is going to be never 100% matching the needs of a particular role.
That's why we have forking.