[RFC] The Future of the ALFS project
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
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
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.
More information about the alfs-discuss