[RFC] The Future of the ALFS project

Bruce Dubbs bdubbs at swbell.net
Tue Feb 28 11:07:54 PST 2006

Jeremy Huntwork wrote:

> Did I read you right, though, that you don't think a new alfs tool is
> necessary?

Yes, that is what I was saying.  However, your point about dependencies
is something I didn't think about.  For developers, it is a non-issue.
I can't imagine an LFS developer not having libxml2 or libxslt on their
system.  It may be an issue for non-developer users, but IMO, not a
major one.  There are no required dependencies of these packages and the
total build time is less than 2 SBU.

If you want to practice coding in C (or any other language) and use ALFS
as a vehicle, then that's great.  I just don't think the project needs
it.  What it needs is polishing and enhancing an already excellent

The time for jhalfs is mostly in the xsltproc parsing.  How often does
the book change that you have to run jhalfs.  Certainly not several
times a day.  In any case:

[root@~]# time jhalfs
mkdir: created directory `/mnt/lfs/jhalfs'
`/usr/share/jhalfs/functions' -> `/mnt/lfs/jhalfs/functions'
mkdir: created directory `/mnt/lfs/jhalfs/logs'
Downloading the LFS Book, version development... done
Extracting commands... done
Creating Makefile... done

real    0m22.100s
user    0m14.705s
sys     0m1.352s

Is all that effort really needed to improve a 22 second process that
runs at most a few time a day?  I'll also say that I do have a 3GHz
system and slower systems will take proportionally longer.

Please also note that I'm *not* saying to abandon the idea of a compiled
system.  If you have an itch, scratch it.  I *am* saying that if I was
running a commercial enterprise where I was paying a programmer, I
wouldn't do it because it is not an effective use of time.

  -- Bruce

More information about the alfs-discuss mailing list