new to the list - fresh perspectives

Greetings, everyone!

I've completed a handful of LFS builds over the course of time, as well 
as a few successful jhalfs and the preceding script as well.  I'd like 
to take a few minutes to voice some thoughts I have.

First and foremost, I thank each and every contributor, no matter the 
scope of your involvement, for keeping the project going.  With so many 
things now moving to containerized software packages, and traditional 
package managers are starting to spin uncontrollably on the bloat boat, 
I feel like LFS is extremely important.  For the love of goodness, don't 
give up! (A wonderful article on jmmv.dev entitled "Fast Machines Slow 
Machines" explores the problems of the current development paradigm very 
well.)  Truly, thank you.

On to some suggestions.  Please understand that I haven't taken the time 
to try learning how the jhalfs script works, and some suggestions may be 
unreasonable.

1) when I first move into the jhlfs directory and issue make, one of the 
first menu options to configure is which version of the book to build.  
However, I don't understand how to pick a specific version using the 
information that's provided.  It would be far more clear if a user could 
put in a version number, or have an additional xml file to download to 
the root of the jhalfs directory

2) xml files are the next thing on my mind.  As I recall, there is an 
option to use a supplied XML to work from.  Would it be an issue to have 
a list of such files directly on the alfs -> downloads page?

3) bootable media is something that I dearly miss.  download the iso, 
boot it, and now you instantly have everything you need right in front 
of you to build the system.  I have an i586 beside me that is begging 
for a LFS build.  As it is, I need to install debian jessie on it, 
compile a new kernel, do some upgrading, and now it's able to compile a 
current LFS.  Having an ISO to download that's built on a 586 would be 
quite the boon!  Please correct me if I'm wrong, but I'm of the 
understanding that running something build on 586 libs will work, and 
produce correct objects, for modern arch's.

4) a single tar file that includes all patches and sources would also be 
a big benefit.  I see that at some point in the past week or two, 
someone updated the zlib1.2.13 link.  I found myself very frustrated 
trying to find that version elsewhere, and then to get the script to 
just accept the version I manually downloaded.  I've had to hunt down 
sources in the past, but never got as irritated as I did with zlib.

5) while the build script is running, it's very clear which package is 
being built, and how long it's been running. Personally, I'd like to see 
something of the following nature:
____a) after the ch5 binutils SBU has been time'd, the other handfull of 
the toolchain lists the first SBU time - and does the math for the 
approximate build time of {current} package
____b) each of the handful of the toolchain is also time'd
____c) when ch5 is complete, the SBU is re-calculated
____d) moving though chapters 6,7, and 8 the SBU value and approximate 
build time is displayed using the recalculated average of all of ch5
Benefit being here is to hopefully have a more accurate SBU presented, 
and to give the impatient human behind the screen a very reasonable 
estimation of when to come back and check on things.

I should probably conclude my first email at this point, before I write 
an entire volume.

Once again developers, what you are doing in this project IS very 
important.
Thank you so much.

-- 
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page