Greetings and a General Cleanup

George Makrydakis gmakmail at gmail.com
Fri Nov 3 05:39:24 PST 2006


M.Canales.es wrote:

> The new jhalfs code may be something totally different, thus the
> discussion is open to any one that would expose thier point of view.
> 

Totally different. Does this mean that the C++ route is acceptable? I take 
that for granted. How much of the original script code would be used in that 
setting? You decide that since my approach since the principle is: no other 
dependency other than a compiler.

> The prominent goal of the LFS Project is to create educational books about
> how to create Linux systems using source code. Any of the books should be
> view as a distribution but as a guide.

Not a problem. Optional sections in the layout could be of use to more 
advanced users. If that is not a main goal and it seems it is not, I am 
certain that it could be a nice feature to be offered by yours truly who is 
actually desiring such an option. The entire deal is building the toolchain 
correctly, either the LFS or the diy-linux way. There is no need for the tool 
to be hard - locked to LFS.

> To create distribution systems from LFS books is for the readers. And here
> is
> where the ALFS Project at a whole, and jhalfs in particular,  could have
> something to say.

I am interested in automation. Extreme, powerful, automation that puts 
everything else into the sweet embrace of Oblivion (polite and constructive 
comment :) ).

> To change the books sources to allow a better automatization and
> customization of a concret book version is a desiderable goal for the ALFS
> team, but is something that need be discussed and decided by all editors
> and the community. We, as jhalfs developers, can't rely our work on
> hipothetical books changes that may no occur.

There is no common way of writing the books if i am _not_ mistaken. I am not 
referring to the xml schema used, but also in the way XQuery, XPath, XPointer 
and other X - candy are used in different settings. The single rewrite could 
involve a more unified view of what to use and what no to use in various 
settings, in a more predictable way. Since I do not have anything to say, 
that can be done in auto mode via options in the tool itself.


> But, if the planned jhalfs redesing could be implemented, book changes
> don't must to affect the core jhalfs code, only the code for that book
> plugin and how much customizable systems based on that book may be.
> 

If according to your initial statement the new jhalfs code may be entirely 
different, then what you really want  to say is that you need to make sure is 
that you can build older versions of the books. The offered solution should 
be completely agnostic, so what could be done is that there can be preconf 
files that only touch sections of the bash output after things are processed.

I do not see backwards compatibility as a problem.

What you need right now is to see a prototype that builds the system the 
intended way. Then add ins are to follow to that. My own work after the 
prototype is to be focused on making the output code flexible enough to 
create package management and build an lfs core as an example using rpm, deb 
or <put worst nightmare here> via such a "plugin" structure. That said, and 
by offering all code under header files, one may choose how to develop 
various strains of the tool. This way nobody gets away from the educational 
side.

I have to say though, that my personal goal is far from educational only. No 
harm done if that is to be kept separate and free for any other re - 
implementations or ex novo implementation of the LFS/diy-linux idea. If 
things are not accepted by a board of elders, there is no reason why there 
should not exist, separately. If the tool or tools are based on a common set 
of libraries, it is easy to build anything custom made.

That said I will work on a prototype using some of the header files this 
weekend, concentrating on the current _stable_ version of the book. You will 
only be seeing a single bash script, coming out of the processing binary 
tool, compiling the entire system and configuring it. Nothing else is to be 
presented for the sake of simplicity.

Do also take under consideration that binary code must be safe code, but also 
extensible code. It is not like developing things in the bash way where you 
add things along the way the "hackish" way. Either you provide a layout and 
plan on what things need to be done and the extent of the extensibility from 
the beginning or you pay the consequences later.

> To change the books sources to allow a better automatization and
> customization of a concret book version is a desiderable goal for the ALFS
> team, but is something that need be discussed and decided by all editors
> and the community. We, as jhalfs developers, can't rely our work on
> hipothetical books changes that may no occur.

In anycase, i can keep the optional material i need separate and use the 
unlicensed from the community edition to substitute my current stable and 
operational distribution environment If I desire to do so. You only need a 
prototype for working out your side of the details, but as I said, whether 
the book changes or not, it can be made to change automatically, so that it 
behaves as it should for personal purposes.

Take the best from everyone. "No rules, is the rule", meant in the polite and 
constructive way.

Thanks for responding and commenting as always. Keep up the good work. You 
will get the prototype in a couple of days tops.

George M.




More information about the alfs-discuss mailing list