4.2 Request - readonly ROOT filesystem

[Walt Lazear]

The Air Force did indeed use a form of read-only root filesystem, as a
strategy to avoid the hassles of integrating software releases into
operational filesystems.  All we distributed was a root on which there
should be no lasting changes, so that if it crashed or trashed, you 
could read a fresh copy from the distribution tape (we duplicated the
original Bell 'tp' format for distribution tapes).

Two points, however.  First, we found we could not mount the root truly
read-only.  There are updates to inodes (I forget what, but probably
last accessed times) that must occur, so we lived with a normally mounted
root that could be 'refreshed' at any point by reading in a new copy.

The second point is even more important.  IT WAS A LOT OF WORK TO GET THERE!!
The overall scheme was to have the /usr filesystem be where volatile and
site specific stuff resided.  As Joe Yao pointed out, that means moving
Bell supplied programs from /usr/bin to /bin, and databases from /etc
(passwd, group, ttys) to /usr/etc.  You would be amazed at how incestuous
programs were, even back in V6!  One would call another to do certain
functions, and would use an absolute pathname (not unreasonable, since
there were no search rules with exec(2)).  All references to /usr/bin
had to be changed to /bin and programs recompiled (before 'make' was
around).

Overall, the effort was worth it.  Sites had merely to boot a new root
to activate the software release, they did not have to dump that filesystem
(ever) because they had a copy sitting on the distribution tape, and
their local applications were nicely partitioned from system stuff.
Alas, all this disappeared when they bit the bullet and adopted SysIII and
SysV, but they decided not to be the central distribution center for the
Air Force any longer.  Sites should go directly to ATT for software and
support (and to fend for themselves generally).

Sorry to go on so long, but I wanted to indicate that there was merit in
the idea, especially when you might be supporting distant sites (ours were
in Mississippi, Alabama, and Ohio, while we were in the Pentagon in DC)
with inexperienced word processor operators as your system administrators.

           Walt (Lazear at MITRE)