Fwd: Re: 2.4/2.6 kernels
jhuntwork at linuxfromscratch.org
Thu Apr 21 07:38:37 PDT 2005
> 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. :)
More information about the hlfs-dev