Greetings and a General Cleanup

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.w
ikipedia.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.
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

Greetings and a General Cleanup

Thread: Greetings and a General Cleanup