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