A new aproach

Eddie Olsson ewt at avajadi.org
Tue Sep 24 10:02:52 PDT 2002


Hi

I think this is a brilliant approach, and I have a few variations on your ideas that may make this both achievable and even more useful:
* First a disagreement with your idea, albeit a small one: I think the main distribution form for the book should continue to be docbook and it's derivatives (html and so on generated from the docbook sgml). 
* That said, i think the  'native format' of the book (the format editors work with) , however, should be xml using an extended version of the alfs DTD. The extensions should be done so that both docbook and alfs profiles can be generated from that xml or, better still, used directly by alfs applications. 
*  The DTD should allow for 'alternatives' that can be viewed in the book and chosen in the alfs applications. This is to allow the users to choose between different paths through the installation ie do I use pam or not?, Do I use sendmail or postfix for the MTA? The latter one probably belonging in blfs, but the DTD should allow for a limited set of differentiations of the installed system like this. I realise this can turn in to a bit of a nightmare for editors, but the gains in terms of usefulness are big enough, imo, to at least remove technical obstacles for this. 

The benefits of this new approach, if indeed it is new, are quite obvious. It's equally obvious that there are some pitfalls with it, mainly that it could be hard for editors to readopt to a different model for writing, so I would very much like to get some input from them on this.

With the book available in xml format where the actual build actions are machine readable as well as human readable (through the application) you could easily read the book while do the installation step by step, making choices between alternatives where applicable or simply build it all in one go with the defaults all the way. It would also give editors a benefit in that they can more easily test a new version of the book by using it's automated capabilities to do a test build on a clean box for QA or whatever, something that I can well imagine being a bit of a pain with the current process.

/Eddie 

h2k1 <lfs-portugal at netcabo.pt> uttered the following on Tue, 24 Sep 2002 17:03:50 +0100:

> hello there!
> 
> with this post i do not want to start a new war on this group, but simply 
> give a opinion about this project.
> 
> first, i want to say that this is a good project and i would like to 
> congratulate everyone that ever contributed to it. the use of xml files in 
> a simple program is very different from using scripts. it shows the desire 
> from evolution to a more complex, but yet intuitive and powerful as xml, 
> system. i think that the main issue here is to build a lfs system from 
> scratch, by reading the book and working some aspects on the profiles so 
> that the system builds by itself. and not only copy and pasting the book to 
> a shell.
> 
> following this idea, i would like to see in the future a new aproach to the 
> ALFS program, being ALFS as:
> 
> 
> - ALFS itself;
>         continuing doing an automated lfs build.
> 
> - A book reader;
>         having the possibility of being possible to read the book while the 
>         system is being built.
> 
> - A book editor;
>         using the capabilities of vim.
> 
> - A lfs system files editor;
>         same as the book editor, but to write and edit the config files needed
>         by the system.
> 
> - Part of lfs;
>         being instaled on the lfs book (this may be an optional program) as the
>         official editor/reader of the book.
> 
> - A blfs editor / installer;
>         a blfs ALFS. a graphical frontend (qt/gtk?) for the ALFS. 
> 
> another important subject is the lfs.dtd . it should be a standard dtd for 
> the lfs project, and being used by the lfs/blfs book and ALFS. the project 
> needs to create his standards. details as program dependencies and book 
> translations could be easily integrated in the project. 
> 
> These are the features that i think the future ALFS should contain. i have 
> taken in account some of the thoughts brought up here in the last days / 
> weeks :) and the hunger for evolution that the current "zeitgeist" on this 
> list has revealed. maybe some of them are a bit irrealist, maybe not ;). 
> please feel free to comment.
> 
> bye for now
> hugo
> -- 
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe alfs-discuss' in the subject header of the message


-- 
Eddie Olsson <eddie at kinnekulle.com>
=========================================================================
Fingerprint: 2778 87FA 6708 58C0 8261 DFEB C8FA 4591 6E36 FCCB 
Key ID: 6E36FCCB
`Those who desire  to give up  freedom in order to gain security will not 
have, nor do they deserve, either one.' - Thomas Jefferson
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list