Greetings and a General Cleanup
gmakmail at gmail.com
Wed Nov 1 07:23:20 PST 2006
> 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
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
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
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
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
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.
More information about the alfs-discuss