== The not so secret history of _/var_

Originally, Unix had no _/var_; what is currently put there went
into _/usr_ instead (with some of it going into _/etc_), so you had
_/usr/log_, _/usr/spool_, _/usr/tmp_, and so on. Remnants of this
era still linger on in _/etc_, where you still find a certain number of
frequently updated data files like _/etc/passwd_.

(One might sensibly ask why Unix had both _/tmp_ and _/usr/tmp_. My
guess is that it goes back to [[the days before _/usr_
BinDirectoryOrigins]], and so _/tmp_ had to be retained when _/usr_ was
added but at the same time people wanted a bigger scratch space, so
_/usr/tmp_ was created.)

Then along came the idea of diskless workstations (I believe originally
from Sun). Even back then, _/usr_ was the biggest system filesystem, so
no one was really enthused about the idea of each diskless system having
its own copy. Since at this point symlinks had been introduced, people
came up with the idea of moving everything writable from _/usr_ into a
new filesystem, _/var_, and leaving symlinks behind so that people and
programs could continue to use old paths like _/usr/tmp_. This left
_/usr_ read-only and shareable among all of your diskless clients,
which saved a lot of disk space.

(Indeed, a shared _/usr_ and the accompanying disk space savings
are probably what made diskless clients viable in the first place.)

Over the years since then, the symlinks have been progressively removed
on many systems. But today you can still find them on some systems that
especially value backwards compatibility, for example Solaris 10.

In addition to moving things from _/usr_ to _/var_, a certain number of
things were relocated from _/etc_ to _/var_. Practically speaking this
was much less important, since you needed a separate _/_ filesystem for
each diskless client anyways, but it did create a culture where system
daemons shouldn't normally write to _/etc_ to store PID files and so on.