Re: SEUL: SOTs comments

[Erik Walthinsen <omega@aracnet.com>]

> the names were arbitrarily chosen to
> reflect a situation which does not exist in any home, anywhere in the
> world. bin doesn't "make sense" for programs, and neither does
> /usr/local/bin -- they're conventions of the unix world, and make no
> sense to anyone from outside.
I fail to see how this is an issue.  Unix was designed 30 years ago at AT&T, 
yes.  The unix filesystem structure hasn't changed in 30 years for one 
reason: it works.  It doesn't make complete sense.  That's because it doesn't
have to.  When a new user gets on a system, they don't go poking around in
the depths of the filesystem the first chance they get.  They don't give a
damn what it looks like.  They want to write a letter to Mom:
/home/newbie/To\ Mom.txt  (spaces appropriately expanded by the app)

> the word "etc" is not what comes into your head. face it.
/etc is for system-level configuration, which we'll be wrapping behind a UI 
anyway.  My goal is to change only what we have to, and as we will be writing 
an interface to /etc and friends anyway, why change it?  If we do, we will 
end up with a wholly incompatible system (can you say "Be"?) with another 
shelf at your local tech bookstore dedicated to becoming an SEUL Master 
Administrator, or whatever the publisher wants to call it.

Yes, I'm diverging, but think about it: the end user doesn't care what's
behind the system, and the filesystem structure is the very *last* thing on 
their list of things to learn.  For people who maintain these systems, 
learning a completely new structure takes time, money, and patience.  Why 
would anyone want to learn a new, untried, non-M$, and essentially 
proprietary system, when they can buy Sun's with Solaris and apply the Unix 
knowledge they already have?  This knowledge should apply to SEUL just as 
directly. There's also the fact that SEUL machines will be controlled 
by bigger Linux servers, with really big Unix boxen running the databases.  
Unix, Unix, and Unix.  (vs. Unix, NT[vms], and W95[dos])

> no. as another user of the list mentionned, it involves chrooting them
> and having pleasing names point to things outside their home directory.
> but I don't know if that works
It doesn't.  chroot completely hides everything below it (like mounting a 
filesystem on top of a directory that has stuff in it), so all symlinks end 
up pointing to files that don't exist.  And no, we aren't going to be able to 
fix that.

> --real filesystem------///--user's view of chroot("/home/username")--
>                         |
> /bin, /usr/bin...       | /programs
> /var/spool/mail/user    | /email
> /etc/profiles/user      | /preferences
> /lib                    | ___________
> /boot                   | *invisible*
> /proc                   | ~~~~~~~~~~~
Again, the assumption is that the user will be seeing the filesystem 
structure at all.  If we have the right set of programs, they won't care 
how things are organized.  Also, they won't have programs(binaries) in their 
home dir, symlinked or not.  That's what the WM's menu is for.  Preferences 
will be behind something like the Dotfile Generator, so they don't need to 
move anywhere.  They're hidden from normal view anyway.

> is there union-fs support in the kernel yet? 
There was something back in 0.99.10 that did that, I think, but 2.x doesn't 
have it.  It should, IMO.

TTYL,
    Omega

      Erik Walthinsen - SEUL Project infrastructure/system architecture
        __
       /  \           omega@sequent.com         Work: (503)578-5314
      |    | M E G A  omega@aracnet.com         Home: (503)281-4281
      _\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS

       SEUL: Simple End-User Linux - creating a Linux distribution
     http://www.seul.org/            for the average home/office user