Subject: Re: FS layout in Linux

From: Chuck Boyer <[email-masked]>
Date: Wed, 5 Feb 92 06:16:20 -0800

Thanks Julian, Miss Masey McMillon here. I like your ideas set out here
in your mail on directories. I vote for your suggestions. My concern is
that from the beginning I have taken from the various mails a certain
setup suggestion of partitions for Linux to be up and running; 4M for
the Root file system, whatever for the main Linux (I have 29M) and
an additional 8M for swap disk. So, having done that, I find that I
must put a lot of stuff in /usr (as I begin using the compiler for
third party stuff it looks for stuff in the headers and Makefiles...)
so will my 4M Root which has /usr on it (with /usr/bin and /usr/root
which has the dot.login files) be full too fast? So that sends me
seeking a way to mount 29M /tmp onto /usr instead, so I don't fear
running out of space.
Some information only.
thanks.

---

From: [email-masked] (Skip Egdorf)
Date: Wed, 5 Feb 92 09:39:28 MST

> /site is a nice idea
   > /local nice too.

   Not sure about this one.  Could someone please explain to me the difference
   between /site and /local?  I seem to have missed it.  No need to send to the
   group, private e-mail is fine [and stupid looks are STILL free].

As I am the originator of these, I will reply to the whole net.
We probably don't need both /site and /local on linux (??).
They are both hierarchys with bin, lib, etc.
On my  network, /site is mounted from a server for the appropriate
architecture (eg sun3, sun4, PDP-11 :-) just as /usr is.
/local is used when a machine a) has a local disk b) has some special
hardware that needs a special version of a command.
The typical example is some program that uses graphics, and one machine
has a special graphics accelerator. The guiding principle is to allow
any user on the net to sit down at any machine and have a familier
environment. On one of the normal machines, the command "do-graphics"
gets the plain vanilla version from /site/bin. On the machine with
the accelerator, the command comes from /local/bin (before /site/bin in
PATH). In other words, /local allows the ability to override the SITE-wide
default command on a LOCAL machine.

   > Having seperate directories for each package i julian's sense
   > (eg. ci co rcs .. in /app/rcs/bin) is a *very* bad idea.

   Yup.

A *VERY* *VERY* bad idea. 

   >                                                          What
   > we need instead is way to shrink packages so that installation
   > AND UNINSTALLATION is trivial. (eg. Interative Unix's approch
   > or Next .pkg).

   Now, I'm not so sure about this.. How many packages are we looking at to start?

   When we start getting things like:  UNIFY, Lotus 1-2-3, etc, then I agree.
   But for now, [perhaps] tunnel vision is better...

There is no reason to be short sighted unless the solution is hard. In
this case, the solution is easy. And there will be a LOT of packages.

In my not-so-humble opinion, the single largest reason for lack of
acceptance of Unix in the commercial world is the difficulty of
selling a piece of shrink-wrapped software that just loads. This is
NOT because of SPARC vs 386 vs whatever. It is because nobody ever
made a simple standard that ALL third party commands go in /site/bin,
and ALL support files go in /site/lib (/site/lib/package/... is
perfectly acceptable as long as the libraries are rooted somewhere.)

Take a look at framemaker sometime as an example. For any user to
use framemaker, the user must run a script that edits a PATH variable
into the user's .login!!! This, naturally fails for any user who
does anything even vaguely complex with PATH. Framemaker would not need
to do this if it could depend on something like /site/bin being in
every user's PATH and /site/lib being available for creation of
a /site/lib/frame/...

I am not wedded to the name /site. I propose it because I am currently
using it, and because I believe that ANY scheme that can be agreed
upon will be better than the anarchy that now exists.

					Skip Egdorf
					[email-masked]

---

From: Alan B Clegg <[email-masked]>
Date: Wed, 5 Feb 92 13:00:46 EST

[email-masked]
In-Reply-To: <[email-masked]>; from "Skip Egdorf" at Feb 5, 92 9:39 am
X-Mailer: ELM [version 2.3 PL11]

> They are both hierarchys with bin, lib, etc.

Well, why not just call it /usr/local (pretty standard) and allow for the
future use of /usr/site.  Seems that we might be a fair distance from NFS..
[See end of message for full reasoning behind slight pessimism].

> perfectly acceptable as long as the libraries are rooted somewhere.)

Ok, Data General got around this with /var/pkg, with each package living in
/var/pkg, with links into /usr/bin [I believe, memory is fuzzy]. 

> Take a look at framemaker sometime as an example.

I helped with the port of Framemaker 1.2 to the AViiON platform.  It IS a mess,
but it resolves some problems.  For those that are unfamiliar with the product,
it has a shell 'wrapper' that determines the type of platform that you are
running on, and then executes the correct binaries.   This allows all of the 
different versions of Framemaker to be loaded into the same directory tree
and be available via NFS from the same place for all archetectures.

> upon will be better than the anarchy that now exists.

I guess I am somewhat biased by my feeling that Linux will [and feel free to
flame me in private mail if you disagree] be 99% for hackers.  I don't see
commercial vendors running to port their products to it.  Please don't get me
wrong with this, I believe that Linux has great possibilities, but probably
won't rival SCO/ISC/BSD386/etc for the commercial market.  [in fact, I don't
think that BSD386 will rival the others in the commercial market, but again,
that is my opinion].

UNIX Gurus[tm] have been trying to get this file system separation resolved
for *YEARS* and [obviously] have not yet gotten it [just] right.

I am putting together a proposal for file system structure that I will post
tomorrow.  At that point, have your red pens ready to mark up my thoughts.
I don't think we can solve the problems of the world [or even of just UNIX],
but I do think we need to get a decision made so that the next steps can
begin.

-abc

BTW:  If you note, there has been a lot of heat about the malloc(0) not being
	doing exactly what it does on other platforms, so I can imagine what
	would occur if the 'standards' list came out with a directory structure
	that was 'non-standard'... [grumble grumble]
-- 
[email-masked]				Alan Clegg - Network Programmer
KD4JML (just my luck!)			MCNC -- Center for Communications