My first remarks ...

Lederrey Guillaume GLederrey at
Fri Jun 29 16:59:46 PDT 2001

  OK, I am reading the archives !  God, how can you write (and read) so much in just one month !!!  I still have a couple of 100's of pages, but I give you my first 
remarks here.  They might already be outdated as I didnt finish reading yet ...

  All the remarks are in no specific order.

  Excuse me, but this mail is quite long, some of the questions / remarks might have already answered ...  I did my best ...

  First : we really need a manual which resume the archive.  It is really a Very Long an Boring Stuff (tm) to read 100's of mails quoting each other.  I'll do it as soon as I 
have time (having exams right now ... and then going on holydays !).

  The mailing lists that are "closed" are still listed on the web site.  I think they should be removed.

  Is there any documentation about the current implementation in Perl ?  I downladed it (ALFS-0.0.7.tar.bz2) and couldnt find any inside.  Do we just have to read the 
code ?

<useless remark>

> I may get some flak for this, but has anyone considered java? I don't know
> the ins and outs of how feasible this would be, but it's a very clean,
> forgiving language with great exception support and so on. It's use also
> promotes good design (usually) because of its
> "almost-everything-is-an-object" stance. Good design would be it very
> flexible for extending the code etc.

  If you want stability, object oriented programming, good design and so on ...  but as a compiled languge, there is ADA.  There is a very good Open Source compiler, 
interface with QT for GUI.   The only problem is there is not so many developpers ...

</useless remark>

  Is there somewhere (outside the archive) a documentation of what are exactly the goals of the front end / back end / ...  and what are the interfaces ?

  Talking about internationalization (how do you write that word ?) : if you have s/t to translate into french, I'm here.

> Can you tell RPM to read a configuration file (XML or whatever format)
> and then parse it and run commands based on it that compile a package
> and install it according to the instructions laid out in that file?

  As I see it, the commands to compile the package are in the RPM spec file.  In my vision, all the commands to compile / install a package should be in that package.  
All there is to add are some option (where to install, optimisation at compile time, ...).  If a Makefile is buggy, we should fix it and not put a "wrapper" around to correct 
the error at "install time".  That's what Micro$oft did with windows ...  and that doesnt work that well ...

> We could add another layer to the backend, which provides the facility to
> grab the packages from a multitude of locations. For instance, for deploying
> on a network multiple times, grab the profile and packages from a HTTP
> server, with a be module that supports this. Another module could be written
> to grab things from CVS, another from a CD. This would provide a great deal
> of flexibility for deploying ALFS.

  That would be SO COOL !  And to have a really good automated installation ...

What I also miss is default configurations like /etc/profile, ... That should
be a main reason to use ALFS.

> And now new stuff: What do you think of xml based init scripts? Consider
> something like this:
> <deleted>
> I hate all the sh-based config files, because they are all not proper designed,
> every distro has other configs, ... they are simply not real configs. But
> with this stuff, we have both the power of real config files and system
> independance (ever created a system daemon and create init scripts for the
> distros out there -> the hell).

  I dont like all the actual config files myself, but that would be a BIG mistake not to stick 
with the actual standard.  For myself, one of the main reason to use LFS is that the standard are 
respected much more than any other distro.  The other option is to re-write all the progs to use 
our own config-file, use a non-SysV start up, reinvent the wheel, and in 4-5 years we might have 
the best OS around (if we get there ...)

> With Perl for example, the Perl interpreter has to be installed, 
> and all the extensions we use, too. In case of a installation CD (or disk)
> we would have to provide it.
> The C/C++ aproach would have the advantage that we have some executables
> which are small and work out of the box.

  What's the problem with providing Perl ?  We have all the place we need on a CD.  We can put all 
the extensions as well.  They are open source, that's to use them and distribute them !

  Ok, that's all folks.   I'm around 12 june in my reading.  I'll keep you informed of what I find 


Unsubscribe: send email to alfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list