Core and Layers

[Erik Walthinsen <omega@omegacs.net>]

> This is not useful either.  It makes the core irrelevant.  Instead of
> saying "We include whatever we want and call it core" we say "The core
> means that you have a linux system of some sort," which is almost the same
> thing, and not very useful.  The core "Versions" then become equivalent to
> glibc and kernel versions, and we have that already.
Exactly.  At that level, RedHat ~= Debian ~= Slackware ~= Caldera, already.

> Is not the purpose of the core to have a system which developers and users
> alike can call a standard?  I would think that would imply some degree of
> standardization...
Yes.  This idea is still being refined in my poor, overloaded little brain, 
but here's the idea as it stands:

The Core would be the basics for a system to run, do some basic useful 
things.  This would include most of the things that are currently in RedHat 
or Debian's "Base" groups.

Functional Layers could be added, for instance, a mail layer, an X layer, a 
configuration layer, a development layer, etc., ad nauseum.  We'll have to 
decide how much of this we need to do now for SEUL, and how much can be 
done later for use in other distribs, but now I'm diverging... (hey, it's 
1:30 and I'm supposed to be asleep)

Once these things are defined, we will do two things (for every Core 
version):

1) Document the Core and all the Layers both internally and externally.  
For any implementation to be Core- and/or Layer- Compliant, it *must* 
comply with the *external* spec.  Internally it can do "whatever it wants", 
which might mean a patched kernel, a uprev'd version of glibc (with a fix 
for CERT #xyz or whatever), etc.

2) Create and maintain a "Reference implementation" that matches both our 
internal and external specs.  Or rather, the internal spec must match the 
reference implementation. Whatever.  The reference implementation could 
then be taken by any group to build a distrib on top of.  SEUL will be its 
first "customer", then others as time goes on.


I'll mention this while I'm thinking of it: a Layer is an abstraction that 
provides capabilities X, Y, and Z.  Any number of implementations of a 
given Layer might exist, and dependencies might be done between Layers.  
For instance, there might be a bare-bones mail setup that's just enough to 
deal with root's mail, for use in a system where all the users have MUA's 
with built-in pop/imap (i.e. Netscrape).  This entire Layer could be 
replaced by a complete, highly configurable, server-scale sendmail/smail 
implementation that provides all the services of the bare-bones version, 
and more.

Dependencies could get interesting, such as how do you tell the system that 
package or Layer X requires capability Y from Layer Z, when only Layer 
implementations B and C provide capability Y?  I'm sure there are ways to 
deal with that, using a combination of Layer and virtual-package deps.

One very interesting future application of this might be the use of a "UI" 
Layer virtual thingy.  It would initially consists of X and Gtk, plus misc 
glue.  Eventually, it could even be replaced by Berlin and BiG/Gtk.  If 
applications are coded to use the Gtk .so exclusively (no Xlib), then *all* 
X-based Gtk applications would *work*.  BiG/Gtk (currently a fictional 
entity) would simply provide the "Gtk" virtual package, in the context of 
the UI Layer, and all the apps that depend on it just continue on their 
merry way.

This could allow for some useful upgrade paths, if done correctly.  For a 
given version of the Core (which implies a set of Layers of the same 
version), the *primary* product of the entire effort would be the *external 
spec*.

I sleep now...

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user