[ On Tue, December 15, 1998 at 20:43:53 (-0800), What EES eet man? wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> Greg A. Woods sez:
> /*
>  * There's a subtle mis-conception in there...  /usr isn't designed to be
>  * shared amongst multiple machines of a single architecture.  It's
>  * designed to be shared (in conjunction with /usr/share) amongst multiple
>  * heterogenous machines.
> 
> Um..."No".

Uh, well, you missed the point, I think, and I wasn't explicit enough in
what I meant!  ;-)

Without /usr/share then it's only possible to share /usr on homogeneous
architectures.  *With* /usr/share it's *possible* to set up
heterogeneous sharing.  You're right though that hier(7) only goes part
way specifying a complete heterogeneous solution.  I think there's
something somewhere in the GNU coding standards about doing this the
right way.

> Just where, perchance, did you intend to keep /share and /local?  You're
> implying that they live under root, and you're further implying by extension
> that the entire system lives on one big unhappy filesystem.  /share and
> /local live under /usr because it's a bigger filesystem.  /usr/local
> is more likely to be its own filesystem than is /usr/share, which would
> grant /local, but that is (for better or for worse) not the canonical
> layout, for aesthetic reasons that I could go into but won't.

I generally like lots of filesystems....  at least in some circumstances.
(big common filesystems can make disk management easy, but they can also
lead to lots of waste due to the 10% "minfree" law)

And besides, the only reason for separating /bin and /sbin from /usr is
so that there'll be a smaller and more stable root filesystem.

In reality this only matters for unstable machines, and if you're
building a stable server then you may as well just build a complete
system filesystem with /, /usr, /local, /pkg, etc all in one.  Only /var
and /home (or other user/application filesystems) need be segregated for
for extremely high stability of the root filesystem on a stable server.

And of course when you need to put /local or /pkg (or /home or whatever)
on some other big common filesystem it's easy enough to use a symlink
(just like I usually do with /tmo -> var/tmp [just remember to create
/var/tmp on your root filesystem for use in single user mode without
/var mounted!]).

Then there's the issue of contention management on a general-purpose
server.  For example you probably want to keep /var/mail and /var/log on
separate filesystems (and /var/spool and /var/spool/news, and so on) if
you don't want various different subsystems and/or users to cause each
other grief when disk space gets tight.  These issues don't usually
apply to / and /usr on *BSD systems that adhere strictly to heir(7), so
there's yet another reason to just combine them.

>  * (not to mention the redundant and silly looking "./" prefix in the
>  * links! ;-)
> 
> Redundant, perhaps; silly, maybe.  Clear?  Yes.  They did it for clarity's
> sake.

Definitely silly.  And possibly costing one extra run through namei too.

Relative pathanames have been with Unix since day one (or at least since
V7) and they're *very* clear all on their own.  If there's no leading
slash then it's a relative pathname.

I could even argue that the "./" prefix is possibly misleading if you
view it on a poor terminal or with sleepy eyes and the "." isn't
perfectly obvious leading you to think it's just "/".....  ;-)

<FLAME burst directed at nobody in particular>
Explicitly putting a "./" in front of a relative pathname is extreme
newbie-ness, just as silly as putting ":.:" in a shell PATH, though not
quite as stupid as putting ":.:" at the end of your PATH and causing the
current directory to be searched twice.
</FLAME>

(Actually I suspect the "./" prefix on those SunOS-5.6 symlinks are
probably there because they're created by a program that's not careful
enough to strip them off when it can....)

> What do you mean by that one?  All daemon(3) does is detach and run
> in the background.  There are no built-in mechanisms for start/stop/reload
> per se (there are canonical guidelines, but nothing is set in stone.
> This is, after all, (effectively) UNIX, trademark be damned).  Which,
> of course, is why we have the scripts to start/stop/reload.

I'm thinking of a single subroutine that would take (argc, argv) [and
possibly other things] and "do the right thing", including PID file
management and all.

If you want real "UNIX" then run your daemons with nohup or from
/etc/inittab!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>