Subject: re: Seen in comp.os.minix

From: [email-masked] (Mike Murphy)
Date: Thu, 20 Feb 92 12:36:41 PST

_Mark_ <[email-masked]> writes:

>A few people are...
still :-)
>>>> Strongly agreed that admin binaries should be in /etc, including, but not
>	Sorry... either have binaries there, or config files -- *Not*
>both. The BSD 4.4 model (which I think is what one of the draft posix
>standards is related to, if not derived from) has config files in /etc
>and executables in /usr/etc/ (DEC Ultrix and SunOS have already
>adopted this.) Having executables in /etc may be "traditional", but
>that's just because it is a traditional mistake...

Not a mistake :-) It follows the KISS principle, which, I would suggest, has been
sorely ignored in "modern" U**X. Again, oh, well.

I kind of like the root path "/bin:/etc:/usr/bin". The implication is that the
executables required for system maintenance/startup are in /etc (maybe symlinks,
who cares except for KISS), and that they are not, nor do they need to be, in the
"normal" user path. I'd also like to see the permissions for something like
/etc/fsck be 0110, owned by root and group sys or system or the like.

Sticking executables in /usr/etc may be or may not be a "good thing" otherwise, but
it can really make backup/restore cycles a pain. It also can make life a royal pain
if in single user mode the /usr filesystem(s) aren't mounted. It is shortsighted to
be a purist WRT splitting of configuration and executable, I think.

I would propose a far simpler directory structure:

/                 root, to contain as little as possible, just what's required for
		  single user mode

At the next lowest level:
/bin/             commonly used binaries, necessary for single user nothing else but
		  the root device mounted
/dev/             device special files 
/etc/             system configuration, startup, maintenance
/export/          mount point for directories/filesystems to be exported over a network
/home/            mount point for directories of groups of users homed on the system
/lib/             libraries required for system operation, e.g., shared libraries, just what's
		  required for single user mode
/lost+found/      disaster recovery :-)
/usr/             mount point for system components required for more than single user
		  maintenance functions, such as /usr/adm/, /usr/bin/, /usr/lib/, and
		  /usr/spool
/vmlinux          :-)

Note that I specifically leave out /mnt

And then, heirarchically, stuff like:
/dev/dsk/          disks
/dev/lp/           printers
/dev/net/          networks
/dev/tty/          locally connected serial ports
..
/etc/conf.d/       configuration
..
/etc/rc0.d/        single user rc
/etc/rc2.d/        multi-user rc (and so on...)
..

Setting up a system that won't run single user with nothing mounted is probably a pretty
bad idea. Setting up a system that can't be expanded to cope with 4 SCSI controllers with
2 tapes, 10 disk drives, 6 printers,  and a coffee pot interface is also probably a shame
if it can be easily avoided.
--
Mike Murphy  [email-masked]  ucsd!optigfx!mrm    +1 619 292 6060 x 265
Optigraphics Corporation  9339 Carroll Park Drive  San Diego, CA  92121
The opinion(s) expressed above are  mine  and not those of my employer.

---

From: [email-masked] (Theodore Ts'o)
Date: Fri, 21 Feb 92 00:04:40 -0500

Date: Thu, 20 Feb 92 12:36:41 PST
   From: [email-masked] (Mike Murphy)
 
   Not a mistake :-) It follows the KISS principle, which, I would
   suggest, has been sorely ignored in "modern" U**X. Again, oh, well.....

   [....]

Somehow, I have trouble reconciling your first statement about KISS with
your proposal where you have hierarchies under /dev.  I suspect this
will break more than a few programs, as well as people's mindsets.  (It
would certainly break my stock login scripts, which play funky games
with `ttyname`.)

I am correct in assuming that the current draft proposal does *NOT*
suggest use of such a hierarchy in /dev, right?  If so, I hope we keep
it that way....

						- Ted