Subject: Re: FS layout in Linux

From: [email-masked] (Dan Stromberg)
Date: Wed, 5 Feb 92 21:35:34 EST

Hi.

	Before I get started with specifics, let me spell out some of my
more general biases.

	First, background:
	As we all know, many true's and'ed with a false, yield a false.
	One true or'ed with many falses, is a true.

	IMO, there is a parallel here, between general socialism, and
software socialism.  General socialism requires the "and of many true's",
with the ever-present likelihood of a false - that is, many people
who might like to make socialism work, messed up by a few more concerned
with themselves (this is an argument *against* general socialism, BTW).
	Software socialism, seems to work in reverse.  One good,
sturdy package, can dominate a market, over many good sturdy commercial
packages.
	(Meanwhile, there will probably long be a market for people
who know how to install and improve those free packages.  By the time
there isn't, we may well all be Eloi - cf. H.G. Well's
_Time_Machine_).
	It is my opinion that the success of BSD Unix, is largely due
to the relatively free redistribution restrictions under which it
was placed.
	Linux takes that further.  It's quite redistributable,
if we ignore annoying little things like US export laws (I'm talking
about export, or even import-and-re-export, of DES routines - but that's
only of tangential relevance here in the US, and matters still less to
a site like nic.funet.fi).
	Anyway.
	To sum up the more political bit of my rambling, before I
completely lose your interest: I think linux may well really take off,
if one of the many free MACH-based packages doesn't gain critical mass
first.  Even if one does, there may still be a place for a small
SysVish system.
	One consequence of a system being in the domain of hackers,
as BSD has been, is that it will tend to mature into something fairly
useable, if not pretty nice.  Given that there's even so much as a
marginal possibility of linux becoming fairly substantial, we would do
the industry a service, to plan a bit beyond our expectations.  I'll
spare you the analogies with what MS-DOS has become to the field.

	Following, are my ideas on the file system, with the above
points in mind.

	The idea of a small root partition, with just enough to get
everything else rolling, is to be protected.  It makes fsck'ing on
reboot nicer, to say nothing of the reduced complexity in getting
a dead system back up.

	/bin and /usr/bin, I'd like to see distinct, in part to keep
the minimal-initial-system, and in part because it breaks things to
do otherwise, like the Kerberos Version IV "make install".

	I think S. Egdorf was really onto something, with the use of:
{/,/usr,/site,/local}{/bin,/etc,/lib}.
	If we could ignore our past, something like:
{/,/multiuser,/multiuser/package}{/executable,/data}{,/site,/local}
might be nicer still, but I can't pretend to believe something that
idealistic would gain much acceptance.  I think we can change
the fs tree a bit, given the indirection provided by $PATH, but
something like this would probably just be too "different", and
indeed, somewhat gratuitously so.

	I agree with tytso, that "etc" has taken on connotations of
"important system files", and should probably be avoided, except on
root.  "lib" should do.

	What's the rationale behind putting "linux" in pathnames?
I'm inclined to believe we'd have better luck with a standard fs tree,
if we avoided that word in paths.  I have *nothing* against linux
itself, or its name.  But will there be anything that is truly
linux-specific, on the system, but the source code?

	PATH, LIBPATH, MANPATH, and INCLUDEPATH are each quite worth
having, IMO.
	
	I agree that user's don't absolutely have to have system
files in the same place, on every machine.  The standard distribution
should be pretty consistent, and should provide guidelines for growth,
but PATH's are precisely the needed extra level of indirection.  I
realize this ignores bad habits like hard coding /usr/local/lib/gcc-cpp
into an executable.  An env var should be used, or, another name used
("gcpp"), if it really cannot be put first on the path, with the same
old name.
	In gcc's case, I like the idea of a cc'ish frontend, that changes
the PATH and LIBPATH as needed, to get gcc used - on systems that aren't
using gcc as the primary compiler.  'just an example.
	Of course all of my #!/usr/local/bin/bash scripts aren't going
anywhere in a hurry...  But somehow I'd rather see bash going in /usr/bin,
or even /bin, than put standard stuff in a "local" directory.  In fact,
I rather favor the idea of a stripped down, bournish bash put in /bin,
and a full fledged, gigundus bash in /usr/bin - one for scripts, and
one loaded with interactive features.  (I'd like to see Byron's rc
in /bin, too...  but sadly, making it the primary shell for system scripts
would probably be going too far).

	Is there a workable alternative to #! ?  It's valuable, but it's
a *hack*.  Someday, someone should implement a #$ that scans a (optionally
intrascript specified) path for the proper interpreter.  Or perhaps, it
should be incorporated into the file system, as is being done with ACL's...
It might make sense to tackle both at the same time, with the addition of
an abstraction for "whatever's associated with this file" for tar's sake.

	A couple of people have mentioned proprietary methods of
installing and uninstalling packages.  I'm familiar with SCO's custom,
myself - but it didn't strike me as much of a solution, to
sometimes-complicated installations.  Packages that are intended to
*partially* replace the functionality of other packages, would not
necessarily work well, with installation programs that reach into
/usr/bin and such.
	I realize people have been saying lots of separate directories
is a very bad idea, but I've seen no rationales presented.  I'm open to
be being persuaded otherwise, but honestly I currently like the idea of
separate directories, for each package.  Such is the method being used
on our primary fileserver at the univ of cinti engineering dept, and
it seems to work well.
	I've *no* problems with it's speed, and the provided orthogonality
is elegant.  The fileserver is admittedly fast, but the PATH searches
are almost exclusively done on slower machines, via network communication.
The fact that many shells (including bash) hash paths, and that the VFS
would allow nonlinear searches of directories, support the idea as well.
In fact, the C library could be easily changed to do non-linear scanning
of PATHs, as well, taking care not to cache *too* much information.  As
UNIX grows, this will only become more important.
	I think both a "custom" program, *and* separate directories, is
called for, in order to hack in and out those pesky inetd.conf entries,
and such.  But the more simplistic the custom program, the better.  I'd
hate to see things written for a custom program starting to outsmart each
other - EG, imagine the problems associated with (de)installing two
packages, both intended to replace intersecting but non-identical portions
of a third...  especially if they try to rename pieces of the third,
so they can fall back on the old versions...

	Back to the fs tree:
	I think my ideal system, for both my own personal use, and for a
large site, would look like:

/		home for root.
/dev		How could we ever forget this?  :-)
/bin		minimal executables for single user operation
/etc		system configuration stuff.  The traditional.
/lib		libraries for single user-only use.  Maybe someday a small
		terminfo database, so we could put a full screen editor or
		two in /bin?  Actually, that might be about *all* that
		needs to go here...  and that could get stuffed into /etc.
/usr		mounted in /etc/rc.  Little to nothing but mount points here.
/usr/bin	system executables for multiuser mode.
/usr/lib	system datafiles for multiuser mode.
/usr/home	home directories, or mount points for disks with users....
/usr/app	Little to nothing but mount points.
/usr/app/name	where 'name' is the name of a package

	/usr/bin and /usr/lib, would be there for old installation
scripts.  They should be deprecated, IMO.  I'd actually be pretty
happy to see a distributed system with present, but empty, /usr/bin
and /usr/lib.
	Termcap could be an app.  Terminfo could be an app.  gcc
could be an app, to make room for any other compilers that may be
coming.  Shell-of-the-month's that aren't trusted enough for system
scripts, could be apps.  The idea is that no piece of software is really
central to the system's existence.   Ok, init and /bin/sh probably
should, though the sh is arguable.
	Ideally, /,/bin,/etc, /lib, and /dev could be copied to a
(moderately sized) floppy filesystem, to get another system running
enough to de-tar an entire distribution from diskettes/tapes/cd-roms/
network, and edit some config files, or invoke some simplistic
installation scripts/binaries.
	In fact, a really nicely polished system might have two
password files: one for single user mode, on root, and one for multiuser,
on /usr somewhere, maybe /usr/etc.  I'm less than happy about the
number of systems I've seen, that had /etc/passwd (and attendant
databases), outgrow their root partition.  Putting just logins
for root, system accounts, and sysadmins in /etc/passwd (perhaps only
these would be allowed to log in on the console), and the bulk of
users in /usr/etc/passwd, would be kind of nice.

	My comments on the filesystem layout are done.

	S. Egdorf has mentioned that much of the reason for UNIX's
lack of acceptance, is its lack of shrink-wrapped software.  I support
his conclusion (that /site in some form, make sense, though it
could be replaced fully or in part, but /usr/app), but not his
reasoning...  IMO, this is technically, and politically (I'll not get
started again...) a reason for UNIX's resilience, as well.
	The fact that we don't have something as constrictive as
the BIOS hampering UNIX's growth, is in part a strength.  POSIX
is testament to the flexibility, and viability, of a Better Way.
	Honestly, I shudder at all the emphasis that's been put
on ABI's lately.  It's great for distribution, but it's harmful to
flexibility.  ...and what we're seeing is the same problems hashed
out, more cryptically.  In the C world, we worry that we don't
have functions present with names like "strrchr".  In the ABI world,
we have to concern ourselves with missing system calls, often identified
by *numbers*.  Semantically, I believe they almost identical, but one
is considerably less mnemonic, and much more given to being used for
multiple, conflicting purpose.
	IMO, it makes far more sense to compile ML or Eiffel or whatever,
into ANSI C, extended just enough to allow symbolic debugging of the
source language.
	Writing or compiling to portable C, isn't all *that* hard...
It's just an unfortunate part of the C tradition, not to.

	Anyway.  Those're my thoughts.

(Skip, you get my vote for best contribution to the layout discussion,
*and* most emperor's-new-clothes idea.  That's something of an Honour,
IMO - no sarcasm whatsoever)

---

From: [email-masked]
Date: Thu, 6 Feb 92 16:19:33 MET

> 	Before I get started with specifics, let me spell out some of my

   [political stuff deleted]

> {/,/usr,/site,/local}{/bin,/etc,/lib}.

Agreed.

> idealistic would gain much acceptance. 

Ideal, hmmmph.

> 	PATH, LIBPATH, MANPATH, and INCLUDEPATH are each quite worth

Certainly.

> an abstraction for "whatever's associated with this file" for tar's sake.

Ugh! #! must only accept an absolute path for the interpreter, or you open
a can of worms, securitywise.

> happy to see a distributed system with present, but empty, /usr/bin

I don't really see anything wrong with /usr/lib and /usr/bin.

> should, though the sh is arguable.

Does this mean that termcap and terminfo should be programs (applications? :-)
or shuld they just reside in /usr/app

> installation scripts/binaries.

Good idea.

> users in /usr/etc/passwd, would be kind of nice.

Never heard of YP^H^H NIS?

> is testament to the flexibility, and viability, of a Better Way.

Does anyone really think we will ever have shrik-wrapped apps. for linux??

I view linux as a hackers system, where we can have source for everything, and
not have to rely on shrinkwrapped binaries-only packages.

On another note, beware of the tendency to make linux an "design by commitee"
system. I belive that linux is as good as it is, because it was designed and 
implemented by one man (Linus). This doesn't mean that we should stop making
contributions and extensions, as Linus can't do everything for us.

Trying to forge standards at this early stage seems a bit futile to me,
time will tell where linux goes.... (This will probably make my mailbox
bloat with flames, Oh well..)

   - Peter.

---

From: [email-masked] (Dan Stromberg)
Date: Sun, 9 Feb 92 11:32:28 EST

>> idealistic would gain much acceptance. 
:-)
Isn't that just what I'd said..?

It's a bit over-different, but isn't the idea to separate the
code from the data?

>a can of worms, securitywise.
Well...

I wasn't all that serious about the change, though it's still something
I'd like to see.

I'm not eager to start changing all my scripts from starting with
#!/usr/local/bin/bash to wherever bash starts going.  But I'd rather
not see bash stay in /usr/local/bin forever, either.

I'll end up changing it anyway.  What I'd like to see, is provision
made for avoiding the same thing happening again, when some other
wonderful new interpreter gains acceptance.

I fully acknowledge the abundance of kernel's that are stuck with 32
bytes, due to the a.out stuff.  It'll be a *long* time before any
benefit *might* be reaped.  That doesn't mean we can't start speculating
about solutions now...

Actually, maybe such a change should go in the shell, at least until
people stop using kernels provided by people who can't share.  :-)

The point of including the search path *within* the script, of course,
was to address precisely the security problem you raised, while still
providing a bit more flexibility.

>I don't really see anything wrong with /usr/lib and /usr/bin.
I suppose there's no getting away from them.

I'm less than completely happy with them, because they give a priviledged
status to certain programs.

Consider:

"Hm.  I'm running gcc 1.40.  I'd like to run gcc 2.0 now that it's out.
I've got gcc-related stuff in /usr/lib and /usr/bin Hm.  gcc 2.0 wants
to go there *too*, and some of the names conflict, some don't.  Well,
I guess I'll just back up {my system|those directories}, figure out
which files are used by gcc 1.40 *only*, and copy in the files for
2.0"

That's good enough, as long it's not followed by:

"Gee, gcc 2.0 isn't quite stable enough yet.  But /usr/lib has changed in
more ways than just updating the compiler...  Now I have to sort out what's
changed, and what hasn't...  I'll want to hack up a shell script to figure
out what to keep, based on the dates, *excluding* the list of gcc 1.40
files, which I can pick out of the distribution...."

Or worse still:

"Gee, gcc 2.0 is great...  but this program requires gcc 1.40 to compile...
(Viz X windows or something)  I guess I'll restore 1.40 temporarily,
compile, and put gcc 2.0 back..."

Sure, it doesn't happen that often.  But it's a headache when it does.
It's the avoidable headaches that I personally find the most annoying.
(Essentialy complexity I can live with, and even appreciate.  Accidental
complexity, I find dehumanizing)

I'd much prefer to be able to leave both on the system at various times,
and change environment variables to indicate which I want to use for a
given compilation.  I'd probably leave only one on the system, most
of the time, but for those special cases...

>or shuld they just reside in /usr/app
They'd just reside there, selbstverstandlich.

"/usr/package", or an abbreviation thereof, might be preferable.

>> installation scripts/binaries.
'tanks.

>Never heard of YP^H^H NIS?
Shrug.  My Master's work has been replicating the passwd map, in a more
secure manner...

It was an offhanded idea, but it's not too far from what I've done
in my MS stuff - the root partition on our machines here are just too
small our password databases.  I've put an /etc/passwd-formatted file
at /usr/local/etc on our systems, and allow remote getpwnam's against
it, but not the /etc/passwd database itself.

>Does anyone really think we will ever have shrik-wrapped apps. for linux??
Well...

Linux' doing a lot of the UNIX API already, you know?  If UNIX gets
shrink-wrap going, it might be worth looking into for linux, in
*whatever* form.

>not have to rely on shrinkwrapped binaries-only packages.
I must admit, I like the extra flexibility of packages that come in source
form.  I believe that's why UNIX is out-living MS-DOS, despite predating
MS-DOS.

What I'm not crazy about, is the repetitive mapping of index to strchr and
such.  I'd be perfectly happy to grab a copy of the latest raytracer off
the net, and not have to diddle any configuration parameters...

>bloat with flames, Oh well..)
Ah!  Politics!  :-)

I don't see this as a flame; you might: I'd rather see linux guided by
a group of people who can make suggestions, without getting crazy if
something gets voted down, than a more usual committee, or even just
letting it take its course.

Given Linus' discussion with Tannenbaum on comp.os.minix, I'd he's
pretty realistic about the fact that lots of people will have lots
of different desires, with regard to Linux' future.

In fact, I'd say his choice of copyright mandates it.

>   - Peter.

- Dan