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. )


1:

ALFS -
 
  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. 

"MetaLinux" -

  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
  "environment".


2:

ALFS -
  
  Wants a fairly simple XML specification for the profile
  authors.

"MetaLinux" -
  
  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.


3:

ALFS -

  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.

"MetaLinux" -

  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.
   

4:

ALFS - 

  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
  manners.

"MetaLinux" -

  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.


5:

ALFS -

  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
  it.

"MetaLinux" -

  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
approaches.

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
follow. 

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
manner. 

It it is still *slightly* possible that I will chose Python 
instead of Perl - I'll make that decision by the week's end.


Cheers,

Corey

-- 
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 mailing list