Fwd: Re: 2.4/2.6 kernels

Archaic archaic at linuxfromscratch.org
Thu Apr 21 17:23:57 PDT 2005


On Thu, Apr 21, 2005 at 05:03:24PM -0400, Robert Connolly wrote:
> The way I see it, linux-2.6 is the only unstable package we have. Its 
> practically cvs snapshots. 2.4 is safe, stable, and still supports most 
> modern hardware.

How can it be stable and still support modern hardware if that modern
hardware requires adding functionality to a kernel? That addition of
functionality is exactly what is being used as a bases for assuming the
2.6 branch is unstable.

> uClibc may also be unstable, but in all this time with 0.9.27 there
> has yet to be a vulnerability. The uClibc releases are much more
> conservative than the linux-2.6 releases.

And in all that time there have been *multiple* 2.4 kernel
vulnerabilies, so if the comparison is between known vulnerabilites of
uClibc and the kernel, then 2.4 is apparently not safe enough to use,
either.

> Anyway, the way I was picturing it was when gcc-4.1 is out, hopefully 
> linux-2.7 will have branched, and glibc-2.3.6 may already be out. But we 
> don't need to wait for all this for a stable hlfs book.

No, but we do need a more complete book. We still need documentation.
There a loads of things left on the punch list. We are at 0.3. I cannot
see what reason there might be for rushing a 1.0 release and jumping
over all the other release versions.

> I should also mention there are 3 glibc-2.3.5 testsuite bugs/failures with 
> 2.6.11* kernels that won't be fixed before glibc-2.3.6.

And those failures are because 2.6.11 changed to a non-blocking pipe,
which is a good thing as it avoids certain types of DoS scenarios (both
intentional and accidental). The test only fails because the test case
makes an incorrect assumption. I have not been able to find any
information that suggests that *any* part of glibc is miscompiled
because of this, so the point is moot.

> So far hlfs has been parallel with lfs-unstable as far as package versions. 
> But rather than trying to keep up with the bleeding edge, I think its best to 
> take a back seat to lfs-unstable and refocus on the security enhancements.

I also don't think we need to follow unstable. However, LFS is in
testing phase and the 2.6.11.* kernels have not been shown to be
unstable. LFS is finalizing the testing phase and is soon to release
while unstable continues roaring past. I have no problems with slowing
down. I encourage it. But I don't think going backwards is the solution.

> I'm running linux-2.4 at my house because I got tired of following the 2.6 
> branch, it was just like following the glibc-cvs snapshots. I would like the 
> rest of you to vote on this because its a fairly serious change.

There is nothing that says that we have to update the kernel every
single time a new one comes out, especially when it is a dot release.
2.6.11.{4,6,7} have all worked perfectly for me on 5 machines of wildly
differing hardware.

> The uClibc and binutils versions would need testing. And there are more ways 
> to mix these versions.

I'm not sure I follow. Are you advocating not using uClibc or are you
just unsure about version numbers at this point?

As far as roadmaps, the more I work on them, the more I'm convinced
they are futile because all of the LFS books are by nature extremely
dependant on the release schedules of the major packages installed and
the impact of any new technologies that may or may not be introduced. As
we fill in the documentation, add more packages, and otherwise tweak the
book in preparation to release an extremely well tested and well
polished 1.0, we can have no idea what packages will have become
available. As far as stability goes, I would even tend to hold off a 2.0
release until the 1.x release hits 4 or 5, unlike LFS. Then we can play
slowly on the bleeding edge stuff in preparation not for an imminent
release, but rather a future-looking release. For example, even by the
time gcc-4.1 comes out, there will likely have been enough changes that
certain packages are still waiting for upstream to fix their code. By
all accounts of stability, we generally would avoid the very first
release of these secondary packages that implement such code changes
until those packages prove themselves in the field. That is where LFS
comes in so handy as a testing platform for us since they will blaze on
ahead.

-- 
Archaic

Want control, education, and security from your operating system?
Hardened Linux From Scratch
http://www.linuxfromscratch.org/hlfs




More information about the hlfs-dev mailing list