another long one ( introducing "MetaLinux" )
corey at axcelerant.com
corey at axcelerant.com
Sun Jul 1 02:43:00 PDT 2001
OK - I finally got tired trying to defend/promote my personal
preference/vision for the design and implementation of ALFS,
and so yesterday afternoon desided to simply summarize what
my own project would look like, should I choose to bail out on
attempting to contribute to ALFS and instead create a similar
"competing" project. I'm going to present it here first to all
of you on ALFS for two reasons - 1: so you can finally perhaps
see succinctly and summarily the full view of what I believe to
be a valid and logical approach to a system for defining and
automating a completely customized linux system; and 2: to lay
that view down on the line and published somewhere soon as possible
so that there can be no issues concerning the implementation of
ideas later down the road. Also, I sure wouldn't mind any feedback
you all may have.
It seems to me the major differences of philosophy between ALFS
and my own ideas are the following:
( note that the "MetaLinux" points tend to provide more detail
than the ALFS points -- this is only to explain/rationalize
the choices made by MetaLinux and not to detract from ALFS's
entirely valid aims. )
Primarly concerned with creating a Schema/DTD for use in
any implemented backend - ALFS is not interested in how
any backend shall work or how it interprets/takes action
from the XML.
Very much concerned with a tightly coupled "backend" and
XML spec. It is in fact a primary project goal to provide
a complete, coherent and fully interworking *system*, or
Wants a fairly simple XML specification for the profile
Believes a more complex XML specification will be required
to achieve the exact desired results for profile authors.
However there will be means of simplifying the process for
those who wish.
Wants to abstract the directives described in the XML as much
as possible and leave the actual implementation/decision making
to whatever the myriads of backends created may choose.
Intends quite the opposite in its XML spec -- there will be
*no* abstraction, all directives are explicit. The XML will
wrap *structure* around the directives, not *abstraction*.
Meaning the backend(s) will *always* act reliably and
predictably - control is in the hands of the individual
profile author - not the hands of the backend writers.
Believes it is important and beneficial to have a variety
and large collected body of different backends - whether
written in different programing languages, or merely
executing the tasks requested via the profile in different
Does not see importance or usefullness in the availability of
multiple backends to the user base. While it certainly will
be entirely possible for anyone to decide to port MetaLinux
to another language - such extraneous activity is of no concern
to the MetaLinux project as a whole.
It is a primary decision that profiles shall be easily ported
between differing systems -- once created, a profile can then
be used by *any* platform or environment desiring to install
While profile portability is certainly a very advantageous and
desirable feature, the MetaLinux project does not believe such
a virtue is so worthy to comprimise any of its other, percieve
more important, goals. Instead, a different approach shall be
taken to provide portability. This approach will have its
requirments, and will necitate an extra step for those profile
authors wishing gain portability - however, ultimately it will
achieve the same desired affect.
( Please let me know if I have misinterpreted any of the above
ALFS points. )
To summarize, in terms of a kernel analogy - it looks as though
ALFS would be a "micro-kernel", while MetaLinux is more of a
"monolithic" kernel. Not to say either of the two projects
are definitively "better" or "worse" -- just merely different
So, at this point, it may very well be that we officially have
two similar projects with different ideologies - GNOME vs KDE,
VI vs Emacs, etc., etc.
ALFS already has plenty of steam behind it, an online presence,
recognition and a even a smallish community. MetaLinux is brand
new and currently consists of one developer, so it's entirely
possible that it just simply doesn't ever get off the ground -
but I guess we'll see.
Whatever the case - choice is good, right? (c8=
The next message in this thread will contain the MetaLinux
draft proposal and introduction. This shall be the reference
document by which the rest of the development will closely
My next steps are to define each of the components in more
detail, and create UML diagrams defining the interface. From
there, actual coding shall commence in a systematic, logical
It it is still *slightly* possible that I will chose Python
instead of Perl - I'll make that decision by the week's end.
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss