Fwd: Re: 2.4/2.6 kernels
archaic at linuxfromscratch.org
Thu Apr 21 07:04:33 PDT 2005
----- Forwarded message from pinotj at club-internet.fr -----
To: hlfs-book at linuxfromscratch.org
From: pinotj at club-internet.fr
Date: Thu, 21 Apr 2005 15:22:03 +0200
Subject: Re: 2.4/2.6 kernels
>IMO, we are stretched too thin. 4 books with basically only one guy
>developing is a really bad thing.
Agreed. We should define a roadmap with a specific target. If we are
going too wide, we will have difficulties to reach objectives.
>I vote for keeping 2.6 and uClibc.
Choice of 2.4/2.6 and uClibc is actually relative to the release date of
the 1st stable HLFS. If we plan to release 1.0 in a short time, 2.4 and
glibc should be prefered because of their well known behaviour (in LFS).
We will have to move to 2.6 one day or another anyway but it could be
done in a later release. If we choose to release after a longer time
(more test), we should use 2.6.
>2) Security fixes come fast and are often relevant to 2.4 kernels, as
Right, check http://www.frsirt.com/exploits/20050409.ong_bak.c.php for
example and there were a lot of flaws for kernel < 2.6.11
I agree too with most of this. My point is we should not go too fast,
and so plan to build around 2.6. If it's not ready yet, let's wait and
use the time for testing. I guess we will not have to wait a long time
according to the kernel dev speed.
About the libc, I'm not so sure. As Archaic said, the use of uClibc is
logical, and actually, I appreciate the lightweight and modularity of
the package that can lead to better control of the ground system. On the
other way, I don't know the devs of uClibc but I guess it's not moving
as fast as the kernel. I'm afraid we will have to stick we an unfinished
libc (as for gettext) for longer time. Need more informations here, from
people following the uClibc development.
It's all about roadmap, but the use of only one kernel and one libc
seems better to me.
Unsubscribe: See the above information page
----- End forwarded message -----
More information about the hlfs-dev