Fwd: Re: 2.4/2.6 kernels

Archaic archaic at linuxfromscratch.org
Thu Apr 21 07:03:17 PDT 2005

This email was posted mistakenly to hlfs-book not hlfs-dev.

To all who are lurking out there (we have a few hundred subscribed
members and less than 10 people who post anything). This email is long,
however it affects the direction of HLFS (if only for the short term).
We need your input. This is meant to be a community effort. Please read
and reply with comments and/or suggestions.

It has been proposed that we create a 2.4 kernel book. This would
increase us to 4 books (2 kernels, 2 libcs). IMO, we are stretched too
thin already. 4 books with basically only one guy developing is a really
bad thing. I will lay out my points below:

First, I use the term server to designate a system that needs only
minimal features from a kernel. Desktop will designate systems that need
the latest and greatest features to drive their latest and greatest

1) You mentioned the instability of the kernel due to it's constant
feature additions. However, many people have hardware that will require
the drivers in the 2.6 kernel. Some of these drivers can be found
backported, but then it requires patching a 2.4 kernel or using 3rd
party modules. Both scenarios have the strong possibility of being not
well tested respective to their 2.6 counterparts. Also, if your basis
for argument is indeed the fact that the 2.6 branch is receiving too
much feature development, then the exact same scenario can be applied to
uClibc. uClibc is not stablized and will not be for a long time. So now
we are left with 2 contradicting philosophies which require either
pulling uClibc and 2.6, or sticking to both just for the sake of
consistancy. I vote for keeping 2.6 and uClibc. And also for note is the
fact that a server will not be needing all these fancy new features and
thus will be unaffected by them as they will not be built.

2) Security fixes come fast and are often relevant to 2.4 kernels, as
well. This makes 2.6 not likely to be any less secure, especially since
grsec actively maintains patches that do the same thing as their 2.4
patches. And as above, many of the features needed for a server will
likely use the same (possibly updated) code as was used in 2.4. Core
functions required for servers (which usually means core functions of
the kernel itself) are generally backported to 2.4 anyway, so the code
base is basically the same in the areas affecting servers. So now, with
2.6 on a server, we get updated code that receives the brunt of
developer's time debugging and testing.

3) We already have 2.6 and all of our current testing has gone into it.
I have yet to see anyone requiring a patch to the kernel to fix
stability issues introduced by the kernel itself. I'm not saying they
aren't there, but we have had a really good track record with 2.6. Short
of hiring a tiger team, I have tried everything I could to attack a
recent HLFS build. Not only will the introduction of a new (old) kernel
further divide our development time, it will negatively impact our
testing audience because either one or the other will hardly get tested
at all, or it will be split and both kernel branches will suffer
tremendously. We are already plagued with this with uClibc, but we are
looking forward to the day when we can remove glibc. A 2.4 kernel is, in
essence, looking backwards. I see no reason to further reduce our
ability to test our products especially when 2 of those products will
have a very limited shelf life.

Final thoughts:

2.4 will disappear soon. That is inevitable. We have 2.6 now. It works
now. It has a longer lifespan. It has more eyes on it. It is actively
developed for new hardware requirements. All software we use that
depends on the kernel and/or its includes either does currently develop
for 2.6 or soon will. Lastly, due to the much larger audience of vanilla
LFS than HLFS, we get to piggyback on the testing that finds bugs
exclusive to the LFS method of building software. Any time we have the
opportunity to mimic package versions, we also gain the testing time
that went into it. That is a very useful and much needed resource.


Want control, education, and security from your operating system?
Hardened Linux From Scratch

More information about the hlfs-dev mailing list