[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEUL: SOTs comments
> 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
> --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.
Erik Walthinsen - SEUL Project infrastructure/system architecture
/ \ email@example.com Work: (503)578-5314
| | M E G A firstname.lastname@example.org Home: (503)281-4281
_\ /_ email@example.com Majoring in CS
SEUL: Simple End-User Linux - creating a Linux distribution
http://www.seul.org/ for the average home/office user