Subject: Re: /etc/daily and /scratch
To: None <jfw@FunHouse.com>
From: Objects In Mirror Are Closer Than They Appear <jgraham@defender.VAS.viewlogic.com>
List: current-users
Date: 03/25/1996 11:26:58
John Woods sez:
/*
 * > I prefer to think of /scratch not being backed up but persisting across
 * > reboots.  Most other sites I know of which support a "/scratch" have used
 * > this philosophy.
 * >As far as I'm concerned, NetBSD should _NOT_ have touched it.
 *
 *
 * "I prefer to think of /bin as being a bin where I can throw random stuff.
 * NetBSD should _NOT_ be trying to find programs there!"  (Hmm, would /usr/bin
 * be where I throw random users?)

Come on, this is a straw man, analagous to guilt by association.
Since it ISN'T doc'd, this is pretty unfriendly.  How do I know that
it's not next going to pick some other directory that I choose?  For
all intents and purposes, we might as well have picked the directory
/foobar or /tree or [gasp] /users.

 * If NetBSD *is* going to scratch the stuff in /scratch, it should probably be
 * documented somewhere -- but who reads documentation, anyway?

Given the current quirks of NetBSD, I'm _always_ reading the docos.
[I've been SunOSified beyond the point of rational thought, and so spend
 much time trying to readjust to a pure BSD system.]

 * Personally, I've always used "/stuff" for persistent "stuff", and see no
 * semantic trouble in treating a /scratch partition like a "scratch tape"...

Well, it takes all kinds, I guess, _but_...

I agree with the necessary end result-to-be, here:  If we're going
to skrog a filesystem, we _need_ to document the thing, or else our
assumptions and the user's assumptions are going to have a meeting
of the minds, and we all know that two different objects cannot occupy the
exact same space at the same time.

Rule #2 (?) of programming (that I remember) says something about
"Never try to second-guess the needs of your program's end user."

(Also, remember that "assume" is really 3 words crammed together...)

-- 
# "Operator Precedence is that which causes statements such as *foo->bar to
# work properly.  It is also that which causes statements such as *foo->bar
# NOT to work properly."
# greywolf@starwolf.com