Fwd: Re: 2.4/2.6 kernels

Jeremy Huntwork jhuntwork at linuxfromscratch.org
Thu Apr 21 07:38:37 PDT 2005


Archaic wrote:
> That *is* better. The only reason there are two at the moment is that
> uClibc has been the libc of choice since nearly the beginning, but is
> not quite ready. When 1.0 releases (which I do not think we are anywhere
> near ready for), unless uClibc starts developing like crazy then
> technically 1.0 will only be a half stable release. The glibc half. But
> I do believe uClibc is the future and I keep my eye on that future.
> Until then, it is usuable (if lacking somewhat), which is why it is
> still in trunk and why we are rendering 2 books.
> 
> Thanks for the input, Jerome!
> 

I think for the most part, I agree with Archaic's sentiments. I 
understand that stability and security are your prime focuses with this 
book, so there is no real need to be bleeding edge on everything. 
However, as was mentioned 2.6 is now the prime focus for nearly all 
development. Any security or stability issues that arise are likely to 
be quickly fixed. Since you are still some ways away from a release 
date, due to other constraints, there is no rush that says you must make 
a completely stable release available now using 2.4.

I especially like the idea of generally following the development of LFS 
in this regard. The HLFS book takes on added value then because it helps 
  new ones to see how with some slight modifications the current (or at 
least, very recent) LFS book can be hardened, producing something more 
secure and stable. It helps keep interest in HLFS alive and well.

In any case, there will *always* be some aspect of any system that will 
be vulnerable to attack, or exist as a point of failure. New 
circumstances and conditions are always arising.  As long as they are 
just as quickly being dealt with, that's really the best that you can 
do. I say, choose a target, (2.6 kernel + uClibc) and make that your 
aim. Focus your energy and development on that to make it secure and stable.

That's about all I got. :)

--
Jeremy Huntwork



More information about the hlfs-dev mailing list