From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: random historical lore (directory locations, sync) Date: 28 Jan 1992 17:38:48 GMT
A couple of questions in this group are related to Unix history that
it seems worth explaining:
At some point somebody asked about doing sync more than once.
Traditionally before taking down a system people type sync three
times. There is actually a reason. The first sync simply scheduled
all dirty blocks for writing. But it didn't wait for them all to be
written. However a second sync would block until the first one had
finished, i.e. all dirty blocks had actually been written out. So if
you wanted to make sure the disk was up to date, you had to do two
syncs. Why 3 rather than 2 I couldn't say though.
Recently somebody was asking where to put binaries. The question was
whether to abandon the distinction betweeen /bin and /usr/bin, as
SunOS has done. I'm not sure what I think, but let me suggest reasons
why the current structure might still make sense. In older systems, I
can think of two reasons for having separate /bin and /usr/bin: (1)
Because non-BSD systems search their directories linearly, you don't
want a commonly used directory to get too big. By putting the most
common programs like "ls" and "pwd" in /bin, you avoid having to
search through a single huge directory. Indeed the suggestion is that
no directory should be allowed to grow too large, so if you have lots
of utilities, splitting them into /usr/bin, /usr/gnu/bin, etc., might
make sense. (2) Most Unix systems had more than one partition. The
root partition was kept small, and had only the most essential files
and programs. The idea was to minimize the likelihood of file system
damage on root in a crash by keeping it small (and ideally having no
files on it that changed regularly -- /etc/wtmp and /etc/utmp of
course violated this, but they could be symlinks to /usr/adm).
However the root file system should have all the tools that would be
needed in doing file system diagnosis and repair, so that if /usr was
damaged, you could fix it with tools on root.
SunOS ended up getting rid of /bin, making it simply a symlink
to /usr/bin. There were several reasons for this:
- under BSD, the directories are not searched linearly, so
you can handle bigger directories.
- /usr is intended to have only things that don't change, so
it can be mounted readonly. Since nothing on it is
changing, there isn't much chance of file system
damage in a crash. Thus tools are actually safer on
/usr than root, even through /usr is bigger. This was
a consequence of the split into /usr and /var, which
was done to allow readonly mounting of /usr.
Linux is probably closer to a traditional Unix system than to SunOS.
It does search directories linearly, and /usr typically has files that
change. Thus the original arguments for a separate /bin still make
sense. In fact there's now a new one: for ease of installation and
diagnosis of damaged disks, you really want to have a reasonable
subset of software on a floppy. I'd suggest that having /bin be the
utilities that we want to be on the floppy, and /usr/bin be everything
else. I do not suggest using /sbin. /sbin is really only software
for use in single-user or during boot. It's not normally even on the
PATH, so it would typically contain duplicate copies of essential
binaries (except maybe for init, which is only needed during boot).
You only need it if you get rid of /bin and move all executables to
/usr/bin. I don't think that's something we need to do.
By the way, I'm against using /usr/local/bin for standard system
software. The whole point of /usr/local is that it's an area for
software supplied by the site. The separation makes new releases
easier to install: you can just replace /usr/bin with the contents of
the new release. Since everything installed by the site is on
/usr/local, blowing away /usr/bin and replacing it with software from
the new release won't hurt you. Having standard parts of Linux be on
/usr/local defeats the purpose: /usr/local is local. No operating
system vendor should ever put stuff there.
Also, I'd like to put in a plug for avoiding the Gnu convention of
starting everything with g's. When I put up the man pages, I noticed
that the man pages had the Gnu names: gcp instead of cp, grm instead
of rm, etc. This makes sense in the usual Gnu environment. Since
there isn't yet a GnuOS, most Gnu utilities are optional extras which
will coexist with standard utilities from the vendor. Then "cp" is
the normal system "cp" from Sun or whoever, and gcp is the Gnu
version. But for Linux, the Gnu utilities are the the basic ones that
come with the system. Thus they should be given the basic names. I
don't really want all the commands to start with g.