bobb at netslyder.net
Wed Sep 27 13:41:59 PDT 2006
To answer your questions...
1. I run SVN-20060717 in a few places, and to be honest I was surprised
there was no effort to stabalize it as well. But I think that is more
about what Robert Connolly was saying about how he doesn't want to stop
focusing on improving his development version. (My current plan was to
stabalize this version, with the kernel change.)
2. Again I am running 2.6.17.x in a few places on those HLFS boxes, and
no issues have come out of it. I have been, and still remain open to
suggestions on the matter myself.
3. See above, but if the decision is to stick with 2.4 then well you
know what has to happen, and I am working to make sure I can make those
changes if necessary. (Allways be prepared and what not.)
4. Just because you have not had an issue with any of the testsuites
does not mean that they wont present a problem with differet hardware,
or under any number of different circumstances....
Most of these comments raise good points, aside from number 4
anyhow...And I have been trying to be very open in asking for any input
from any one on the list that would like to offer suggestions. I am sure
the differing oppinions are worth listening to, and I am not set in
stone as of yet.
To comment further about the 2.6 kernel stability. My major reason for
agreeing with Robert on that one was because 2.6 is in a state of rapid
flux. This is not an issue for everyone, but it does introduce more of a
margin for error. Whereas the 2.4 version is mostly bug fixes, and it
does not seem to change too greatly from version to version. Heck even
the grsecurity team is picking and choosing which 2.6 kernels to skip
due to stability issues.
Still I am open to any point of view on this issue.
Sebastian Faulborn wrote:
> I somehow have the feeling that there are different opinions on
> how to get to a stable HLFS.
> Basically I would assume that if you want to get to a stable HLFS,
> you would try to leave as much as possible unchanged, unless it proves
> to be unstable. Otherwise you start another development branch.
> I personally agree very much with Kevin Day:
> For a stable project to happen, you should probably fight the urge to
> make any kind of change whatsoever.
> To do that, plan the entire project in a manner similar to the following:
> 1) Make a list of sources/projects/scripts/hacks/instructions that are
> currently stable
> 2) Make a list of $(above) that are currently unstable
> 3) Make a list of what you intend to get working and what versions
> with whatever features you want.
> So my opinion is:
> 1) HLFS SVN-20060717 is pretty stable already. I really wonder why there
> was not even an attempt to produce a stable HLFS - beeing so close to
> 2) Whats wrong with kernel 126.96.36.199? I have been using 2.6.* kernels for
> over 1 year without a single problem - all other distros are using them,
> how long do you want to wait before you consider 2.6.* stable enough?
> The new patches from Robert work against 188.8.131.52 (frandom, etc.) LFS-6.2
> stable just came out with kernel 184.108.40.206 and they consider it to be
> too! Grsecurity considers 220.127.116.11 stable enough to bring out there
> new version.
> 3) As a result, there is no need to change to GCC-2.95.3, udev, init
> and module-init-tools
> 4) There should be no problems with testsuites. I only had once a
> slight problem
> with the results in bash's testsuite - however this was compiling from
> a pax
> enabled kernel. Bash itself worked fine however.
> Actually there are only minor tweaks necessary to make HLFS stable.
> Maybe everyone could
> post problems he had with HLFS SVN-20060717 to this mailing list to
> see where we need to
> fix things?
> Sebastian Faulborn
> Homepage: http://www.secure-slinux.org
>>> HLFS-Testing status
>>> Robert Baker <bobb at netslyder.net>
>>> Mon, 25 Sep 2006 08:23:47 -0500
>>> Hardened LFS Development List <hlfs-dev at linuxfromscratch.org>
>>> Ok, I ended up falling short of my goal of delivering my edited book
>>> this weekend. This is mostly due to the kernel maintainers
>>> recommendation that GCC-2.95.3 be used to compile the kernel to ensure
>>> kernel stability. Beyond that I still have to remove the udev
>>> instructions, back port a few of the init scripts, and replace
>>> module-init-tools with modutils. After all of those items are in place
>>> it looks like I should have a good start. I hope to get a good several
>>> hours to work on this tonight.
>>> Can anyone see anything I may have overlooked?
>>> Robert Baker
>>> [This E-mail scanned for viruses courtesy of Netslyder,
[This E-mail scanned for viruses courtesy of Netslyder, Inc.(http://www.netslyder.net)]
More information about the hlfs-dev