Greetings and a General Cleanup

George Makrydakis gmakmail at gmail.com
Wed Nov 1 07:23:20 PST 2006


M.Canales.es wrote:

> El Martes, 31 de Octubre de 2006 22:52, George Makrydakis escribió:
> 
>> With jhalfs being "the" tool for autobuilding LFS something alternative
>> should not simply be an option but a much more versatile solution. And
>> that, as you very well know, takes time - will aside. Some people could
>> see this as competition for "the" tool, something it is not at all.
> 
> I think that yuou know that we are thinking on changing how jhalfs is
> coded to do it more versatile and cunstomizable via pluggable modules.
> 
> Maybe several of your code and ideas could help creating such new code.
> 

Yes but based on what and why?

I cannot but compliment you for the work you are doing so far, and i wish to 
stress that out. I would be very happy to discuss my view of things when I 
will be asked to and the setting allows it; I would really be honored. Thank 
you for the vote :).

That said, I would not like to interfere with the _current_ state of affairs. 
Past comments have taught me enough regarding policies that should be 
followed in _this_ particular mailing list. Discussing things that are not in 
the _current_ jhalfs codebase will only bring forth irrelevant "point the 
obvious" attitudes that is best to completely avoid because of their high 
entropy.

As a prelude, I would like to address you directly, knowing that you are the 
XSL/XML architect of the book so far. The book does require a new form to 
present the critical content and non critical content. It has required so for 
quite some time. If we are to assume that LFS is to be a distribution system 
of its own, then there is a definite need for overhauling and, at times, 
abrupt changes. I hardly think that it is the case to discuss them without a 
public production ready solution, both because of the average result expected 
from readers and "interpreters" of this mailing list. The use of the word 
overhauling (and even in gargantual doses) is the target of this paragraph. 
CLFS is the base and the example that represents the prototype for the 
n-level solution of this equation. BLFS is an ancillary problem once a more 
flexible and water fluid layout for CLFS  is achieved. I stress the fact that 
CLFS is the major winner in what the LFS project has to offer to anyone 
because of the sheer power of the concept itself.

I do think that what jhalfs has done, asides its obvious goal, is to challenge 
the fate of lfs itself. I also think that any automation system should not 
just "build" the thing. It should make you build it with something more 
than "optimization" or "package manager support". It should be tighted deeply 
into even how the system handles its self - hosting character and internal 
structure and dependencies, and more... _much_ more that only lfs - derived 
can achieve by a versatile automation core.

All of the above may seem incomplete but definitely not confusing or even 
partial to the people who require extreme tailor made suits for their 
hardware. Most of all it is what some users like yours truly _require_. I 
have the moto "your distro, your rules" from the end user's view to be more 
like "no rules is your rules" from a developer p.o.v.

Also take note that offering a yottabyte - level number of packages in an end 
user "distribution" is usually a source of getting out of the right QA and 
inner core innovation necessary to push things forward. This is why most if 
not  _all_ distros look and work alike, despite their will to take care of 
different "needs" they all face the same problems, and not solving them in 
really, _really_ different manners. (Most ) Distributions have ended up 
becoming _huge_ junkyards of "depended" binaries nowadays. Any "common core" 
initiatives quickly fall into oblivion because of this mentality. This is my 
personal opinion of course.

*LFS is/are not a simple educational project since end users are to be 
deploying in larger scale as production ready systems from the very day 
Jeremy introduced the Live CD, _officially_ bringing it to its self - hosting 
age. 

With this in mind, the lfs family of projects, should they accept that bit of 
extra firepower they deserve, can be extremely more antagonistic than Gentoo, 
the T2 project ( _the_ major lfs competitor imvho), Debian, Fedora, Ubuntu 
<favorite distribution meta - source or non here>, because it/they _can_ and 
_should_ and _must_ be any of them and none of them if you are to use it as 
an everyday system.

I tend to think of this variant way of implementing a production ready, 
dependable and services oriented meta source system out of *lfs / diy-linux / 
(homegrown specified system) as something similar to Jeet Kune Do 
(http://en.wikipedia.org/wiki/Jeet_kune_do).

This requires patience, study and most of all targeted interventions in parts 
that can cause entropy if promptly discussed without seeing a _valid_ result 
_first_. I will be available as a helping hand should a task appear, but 
because of the path chosen, I have to stick to the principles above. It is 
not just a tool for me, it is a concept, a design and a _framework_. In any 
other case, the wheel is reinvented when you do not need anything more than 
to swim. This is one of the reasons why I quickly decided to switch to a 
completely C++ self hosted way of resolving the problem. This may serve as a 
response as to how I wish to implement my current variant, and indeed 
implementing it.

Time is coming for it, despite my original concerns. But for starters, and for 
what concerns the current status of the mailing list I will limit myself to 
monitoring and posting when absolutely necessary. As for the implementation 
in hand, I will open it up soon enough when I believe that I can further add 
things on top to it without eventually reaching a point of having to redesign 
it soon enough for it to be pointless to even start with. Complete self - 
hosting features are taken for granted. Disclosing parts of a bigger design 
without explaining he extent where they are eventually to evolve leads to 
misunderstandings, of which a gargantual dose is already present in this 
timespace setting.

I am always available under the right light of things, here, elsewhere and 
_elsewhere_. Keep up the excellent work, especially in the redesign of the 
book structure, you being the major XML/XSL architect for it. I believe that 
this preludial post is serving its purpose in clearing my stance in the 
overall issue(s). Thank you for lending me your time by reading this.

Count me in for the ride.

Best Regards,

George M.



More information about the alfs-discuss mailing list