Re: SEUL: SOTs comments

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

i'm going to address 2 issues: restructuring the filesystem, and hiding
the filesystem-oddities (which is the [important] reason that the
restructuring was suggested).

part I:
=======
restructuring the linux filesystem is a bad idea. period.
1. it will have an inherent tendency to break programs written with the
   "normal" (even if non-intuitive) fs standard in mind.
2. hacking things both nicely and thoroughly enough that nothing breaks
   would be a systems programming nightmare.
a simple kludge like chroot'ing the user's dir appropriately or whatever
is not going to fix things magically.  they may be appropriate ways of looking
at things, in designing a filesystem viewer of some sort, but actually doing
any of that at the system level would lose, since it would not only change
the user's view (the desired effect), but also affect the running of any
programs under an affected user's login (which presumably would be any
human login). these side-effects would have to be then dealt with by further
hacks, and it would just be too much work for too little effect that is
actually related to the goal, not to mention i'd expect the resulting system
to be flaky for several years, before we [might] squash most bugs in this
entirely new system layout we invented.
i could go on, but i hope you get the idea, and i don't have to...

part II:
========
still, the basis for the above is well-intentioned, and is in fact the same
reason i suggested (a long while ago now), the "seul db", also referred to
semi-(un)fondly as an equivalent to the windows "registry".  (please note
that is only a comparison to give a quick idea though, i would not be willing
to implement anything with the the obvious holes that existing the windows
registry system).

to make the issue clear, as graydon said:

>...  every button a user can press,
>they will.  if you can't limit them to a small box, they'll break
>everything they can find that isn't immediately obvious. You'll get users
>who load the kernel into the gimp and gaussian blur it. they'll get rid
>of "all the ugly hash-marks at the beginning of comment lines". Someone
>has to administer the system -- who's gonna do it?
>
>If you can't isolate the user (mac), and you can't rename things so they
>make more sense (NT), the linux remains linux and seul remains
>nonexistent. 

right on key.

and this is what i had a discussion about a few months ago, with some other
linux system hackers here (who also work in tech support, and know the
above scenario well)...
so, the (first stage) conclusion i had after one of the more
technically-oriented dinner discussions i've been in:

* we have to somehow abstract the user out of the existing ("shell")
  interface to linux.  and we have to somehow "enforce" that abstraction,
  or the user will always be able to go wild (and "g-blur the kernel" :^)

this prompted the immediate idea of a "seul database" which stores boatloads
of info on things that are important to average, day to day, system operations.
most noteably, package installation/deinstallation (let's hear it for
package managers -- they are /halfway/ there), and config files for common
things, such as the gui, and any apps we decide are "standard" for our users.
the reason the db helps, is because it provides a comprehensive, well-defined
interface layer between system-ugliness and user-tools.
(it also prompted ideas on where to place the abstraction so as to enforce it,
 but i'm going to defer the "enforcement" issue, since i've confirmed that
 solutions are possible, but the discussion is hairy and not appropriate yet
 in this thread's context...)

the second stage was presenting this idea to seul-project (see talk about
seul-dev-admin (1-2 months ago?)), where it was met with notable opposition.
in particular, doing this in such a way that it works well, is a pretty
huge undertaking, and the criticism was that we don't have time to pull it
off before technology advances and we become obsolete, and our programmers
get bored and go away, and seul turns into hurd...
i took this to be correct, and went on with the no-database plan, basically
on the argument that the db would be too much effort.
however, i think this should be re-evaluated, since there definitely needs to
be _some_ carefully-planned abstraction placed between the user and the system,
or things _will_ fail as graydon pointed out above.
i use the term "abstraction" accurately, since we want to preserve the
underlying system structure (since it has a lot to do with why linux is
better and more stable than other os's), but it is important that the average
user has a different view on things (grep for "learning curve" in anything
written about unix, if you don't believe me yet...).

so, i think the appropriate thing to do with this thread now, is review
the stuff that was posted a while ago, and think about that as well as
brainstorm alternate ways to implement the system/user abstraction.
we certainly can't neglect the issue, but we may need to minimize the effort
needed, based on how much we can expect out of the people working on this
project.
i for one will be putting quite a lot of work into this over the next year
at least, provided that it is more than just a weekend hack.  specifically,
the two things i see distinguishing this from an easy job (and the reason i
don't just code it myself when bored) is the above seul-dev-admin
(a misnomer, oops) abstraction, and the system-wide gui standard, which are
things that linux (and unix in general) are not known for doing well, and i
feel should be fixed, provided we have the backing needed to do it right.
(also, long-term linux support and standardization is something that may
come of seul, but building a system worth starting with must come before even
thinking about that.)

so... if this sounds like a noble cause to you, worth putting more than a
short-term effort into, now is the time to speak up, so we know there are
people behind it.

and specific things to think about/discuss:
1. discuss the validity of creating the system/user barrier that i mentioned,
   if you have some insight into why it may not be necessary at all.
   don't say "the fs (or anything else) is not that complicated" -- it is
   complicated enough to be hindering the acceptance of unix-like systems.
   but i could have overlooked some obvious easy way to make things
   "nice enough" -- if you can think of it, i want to hear it...
2. renew the discussion of the seuldb (read the archives first, please),
   and why it would appropriate or inapproriate for creating the
   system/user abstraction.
   for now, do not discuss timeframes or feasibility given our resources;
   we need to decide what we are working toward and why, and then it will be
   easy to analyze feasiblilty and scale down if necessary (or redesign if
   the system we devise is off-base enough that it can't scale down). just
   don't jump the gun on this one...
3. brainstorm (and post) any new ideas on how to create the system/user
   abstraction.  other than the db ("registry") concept (which i'm not
   elaborating on enough here, so check the archives), are there different
   approaches which could create the abstraction barrier we want?


=====-----------------------------------------=====
 Peter Luka            ...            luka@mit.edu
 SEUL Project development leader/systems architect
               http://www.seul.org
-----=========================================-----