SEUL: White paper (part I)

[Luka@pop3.aracnet.com (Peter) <luka@mit.edu>]

So, I've been up too long.  I'm not going to have the entire document
promised done tonight, because (I admit it) I do need sleep.  (And it
would really not turn out too well if i tried to finish it in this state.)

But... here's the first half.  It includes some neat long-awaited stuff,
that should probably end up on the web after thorough review by you.
Covers, to some extent, a definition and quick analysis of out target user,
and a very general overview of what SEUL's exact goals are and what needs
to be done for us to accomplish them.
Please read and criticize freely, though be careful not to respond to
the bits about actual implementation issues, since they are just foreshadowing
what isn't available for reading yet...
What is important in this part so far is the overall statement of goals
and target (discounting implementation feasibility).  Yays and nays as
to whether this is the track people want SEUL to follow would be good.

This document is already somewhat large, and meant to be read from the top
down.  So if you read nothing else, read the first section, since
other sections refer back to it.

So you know where this is all leading, the next part deals with
my design for the SEUL implementation, which just happens to be in
line with a lot of the implementation suggestions mentioned below,
and is designed to sit on top of an existing distribution to provide
the functionality we desire for SEUL.
But that is a story for another day (or later today, at any rate).
All of that will be pending discussion once i finish and post the thing.
For now, this should be enough to chew on...


I think this is best classified as a SEUL white paper, at this point...


PROJECT GOAL
(a.k.a "Who is the end user and what does he have to do with us?")

 <begin mission statement-type thing>
The Simple End User Linux (SEUL) project, plans to create a distribution
of linux which is simple enough in its interface to allow an "end-user",
a person with no major expertise in programming or system hacking, to
install it, and get it to do useful things, while running in a stable and
reliable manner.
 <end mission statement-type thing>

The exact target user has not yet been fully nailed down.  (See mail
archives for attempts at it.)  Not much is assumed for the purposes
of this document, beyond the above statement however.  It is assumed
that the end-user is not completely clueless, but the exact skill
threshhold is under debate.

Here, I will consider anyone who can install and operate a non-linux OS
to be targetable.  Someone who is _absolutely_ only interested in buying
a system preinstalled (or otherwise having someone else do all system
administration), regardless of which OS is in use, is not in the target group.
This person's dealer or other system installer, however, _is_ a target.
Note that this includes business sysadmins, as well as home users.  This
is important as it has a great impact on the design plan.  Those are
also two relatively concrete types of people you can think of as the
abstract "end-user".  No need to name names here - just picture people
you know personally in those categories (common business user, common
home user), if you want an even more concrete target.  And if everyone
picks a different person to have in mind when thinking about this project,
it should keep us from falling in the trap of targeting one person, rather
than one user, which would be a waste of effort; diversity in thought
(though within the above bounds), will keep the project on a course tending
toward widespread usefulness.

So... this categorization includes a lot of people!  Thus having a large
enough market to care about will not be considered here.  What will
be focused on instead is just how far we can go to meet the needs of that
group before our goals become technically unfeasible.  Given the design
plan which follows, it seems that we should be able to go quite far,
actually.  If it turns out that a lot of things have to be changed,
and it seems that we may be losing much of the above target user group,
then the project should be re-evaluated in this same form, to make sure
there is still enough of an audience left to justify the project, and
to restate the definition of our "end-user" and continue development
based on the new project goal statement.


TOP-LEVEL PROJECT OVERVIEW
(a.k.a. "how general can we get?")

The pieces that will be assembled to form SEUL have been discussed extensively
on the seul-project mailing.  Look at the monthly updates posted by cl@txcc.net
for some summary brainstorming.  And the rest of the list mail also contains
valuable ideas, which could be slapped into a crude faq sometime -- may
be quite useful to have a list of topics that have been brought up like that.

This section deals with these pieces only at the most abstract level,
presenting only a few large, relatively indisputable pieces to the
definition of the SEUL project, along with some brainstorming over what's
and why's and goals to keep in mind later in the design process.

The pieces themselves are the following:
 1.  An installation system, and
 2.  A runtime system setup,
both designed to meet the project goals described above.
As you can see, each is pretty vague at this point in the discussion.
("System" is such a wonderfully general term.)  The installation "system"
can (so far) be something much like a traditional Linux installer,
or something drastically different.  The runtime system may be as little
as a friendly hello on first startup, or a full-blown off-the-wall
distribution unlike anything ever seen before.  (Most likely something
in between, of course.)

So the other thing to look at in this section is a general overview
of what goals we have for each of the above pieces, which would further
the mission of the SEUL project.  Note that these are just brainstorming
topics -- the plans we really wish to implement follow later (though they
may be remarkably similiar to the ideas mentioned here).

The Installation System:
 + should be as non-destructive as possible
   current installs tend to be a bit dangerous, and thus scare off
   a lot of potential users.  this is the number one gripe i hear
   from people who haven't installed linux, and i also hear complaints
   about it from people who do use linux (fips'ing win95 tends to suck).
 + should provide different levels of help depending on the exact user.
   the min/typical/custom install options fit in as an aid to solve this.
   also, providing extra help, or at least pointers to help anywhere that
   it could be required is essential.  do not leave the user stranded.
 + good UI.
   face it -- the UI is what makes or breaks a product in today's
   world.  (ask me for references if you must.)
   This does not mean we need a full-blown X install.  It just means the
   install must look and FEEL (mouse-lovers can mouse, typists can type)
   good and solid.  The stability thing may also be considered a reason
   to discourage running X at this stage.  At any rate, this stuff has to
   all be balanced in the end with the goal of a "good UI" in mind.
 + consideration: space
   on thing to consider as a restriction on us in this system is
   that of space on the installation medium.  the actual medium has not
   been etched in stone yet, but this will remain an issue.  floppies
   are self-explanatory.  cd's help solve the space problem, but at
   the cost of some compatibility and $$.  in the case of net-install,
   the space issue equates with bandwidth, and transfer costs.
 ...and lots of other stuff, but these were some major points.
 As mentioned, compiling a faq-section that just lists these considerations
 that have been brought up on the mailing list would be a good idea.
 For now, read through the archives for more info.

The Runtime System:
  This seems to fit pretty well in two broad categories, which sort
of compete with each other.  Once Linux is up and running, the user
wants two things out of it.  It should be USEFUL, and it should be STABLE.

Specific usefulness features are dependent on the user.  Common things
are games (yes - many people value games a lot), probably a word
processor ( wordprocessor != emacs ), and many other apps... all of these
are dependent on the user for exactly what is desired, but a certain base
set of these end-user-targeted apps should be offered for excessively
quick, easy installation, early on, and thus their proper integration
should be supported (to some extent) directly by the SEUL project.
I've done a bit of casual surveying of our potential users myself, and games
and wp's are high on the lists of home users.  Business users care a lot
about networking and client-server services.  Also people in general are
more commonly net-connected and need it supported through simple
net configuration applications (for modem and ether, for both static and
dynamic configurations).

Also important to usefulness is a GOOD online help system.  Supporting
online help for every app out there would be simply ludicrous for us to
take on.  However, providing some form of a well-designed help system for
the core system and the base set of SEUL-supported apps is probably a good
way to go.  If the help system standard is made simple and useful enough, then
app developers could eventually start to write SEUL-compatible help packages
for their programs as well.  Thus the exact nature of the help system needs
careful consideration.  Html and other formats have been mentioned, but much
more thorough discussion (not pertinent at this level), must still be done.
(Note: what does LDP use?)

Of course, UI has to be considered carefully.  X has been somewhat conceded
as an absolute on the seul-project list, but it should not be considered
so at this level.  As a note, shell happens; thus it also needs to be
_reasonably_ friendly, but this can all be discussed later.

As apps are added and removed and updated, things that are dependent on
them do (or should do) things.... to say the least.  Sometimes things break,
or even crash in really bad ways.  Thus something else that must be considered
in the runtime system we support is a method (nice generic term again),
for keeping things in sync.  This will be influenced by the packaging
system in use.  It may also involve use of some sort of database or
registry that stores information like this, and perhaps the addition
of completely new features by SEUL if necessary to fully support
this sort of complete synchronization.  The impact of this system on the
UI (which should probably provide many services that are dependent on
what's actually on the user's machine), should be considered carefully.

And that sort of got into the realm of Stability toward the end there
as well.  Linux is free, and free stuff has a bad name for one thing
because of a tendency to be unstable and unsupported.  On the contrary,
the linux kernel beats many other commercial OS's in stability.
However, adding all the features we want for SEUL may begin to hurt
things.  Also, some (linux or non) apps just suck, to put it bluntly.
The user could be protected from bad apps a bit by putting SEUL-approval
on products.  Cool stickers, when carefully placed, can make things
seem much more comfy and reliable, and with appropriate testing measures
will really ensure greater stability for people who stick only need
approved apps (which should cover those major-use areas still to be
discussed further).  Also, tightening up the install/uninstall/upgrade
system beyond that offered by current pkging systems will help with this
stability goal.

Still, thing to keep in mind in design is that as we add greater
functionality and diversity to SEUL, maintaining stability will
get harder.  However, stability in the final release is still just
as important as the addition of the features for which SEUL was created.


next up on my list...
BEGINNING CONCRETE DESIGNS
rest to be posted as soon as i wake up again and finish things...

----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------