[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
tool--jhalfs.

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