Date:        Fri, 02 Apr 1999 14:56:52 +0200
    From:        Feico Dillema <dillema@acm.org>
    Message-ID:  <199904021256.OAA13251@dillema.cs.uit.no>

  | Is there value in hte idea, to move user-modifiable (like users' crontabs)
  | files into a /usr/etc directory?

Please, no, /usr is already able to be made read only, let's not break that.

I treat /var as meaning "variable" - ie: files that are intended to change,
not just (but including) "files that don't have to be saved".

Others seem to treat it as "blow awayable" (ie: no need to bother dumping
this filesys, if it's lost, it's lost, build a new one).

I don't know where the latter interpretation originated - /var contains things
like /var/mail (people who use mail readers like elm tend to actually keep
their mailbox there, it isn't just newly arrived mail, it is everything),
/var/tmp/vi.recover (which ought to be moved out of /var/tmp), /var/db/pkg
(and /var/db in general) /var/games (so, not everyone wants their fantastic
high score in snake lost...)  (etc, etc).   Most of that ought not be
lost.   Just because some of what is in /var/tmp, all of /var/run, and
some of what is in /var/spool are almost files that could live in /tmp
doesn't mean that all of /var is.

Of course, different sites have different policies, if no mail is being
delivered to /var/mail, no log files that matter are in /var/log (syslog logs
to a remote host), users don't care about games, no-one runs vi, outgoing
mail never lasts longer than it takes to get it to a better relay (so it
is always a race whether it existed enough to be sent before any crash),
(etc), then /var starts looking pertty volatile, leaving not much that
needs to be saved from there (/var/cron is the notable directory).  Of
course if you also assume "users don't run crontabs on this system" then
/var/cron doesn't need to be saved either...   That's no bigger an assumption
than all of the earlier ones (I have more netbsd systems where users run
vi than systems where users have crontabs, by a wide margin).

kre