D. J. Bernstein
UNIX
The /package hierarchy

Finding files

Filesystem Hierarchy Standard (FHS) 2.2: ``This standard enables software to predict the location of installed files and directories, and users to predict the location of installed files and directories.''

/package does the same thing, and does it much more reliably. FHS doesn't actually let software and users confidently access files; /package does.

Example: Is the lynx configuration file in /etc/lynx.cfg, or is it in /usr/local/etc/lynx.cfg? With FHS, software and users can't tell. The answer depends on whether lynx was a ``system'' package or a ``local'' package.

In contrast, /package provides names that don't change when ``local'' packages are integrated into ``the system.''

Another example: Is the statistics program in the hylafax package called xferstats, or xferstat, or xferfaxstats? With FHS, software and users can't tell. The original xferstats name was used by a different statistics program in the wu-ftpd package; one OS distributor resolved the conflict by changing the name to xferstat; another OS distributor resolved the conflict by changing the name to xferfaxstats.

In contrast, names in /package are globally allocated, so conflicts don't happen in the first place. This is one of the essential features of /package.

Contrary opinions

``Software should never ever assume it knows where to get files from,'' someone once wrote. (He says I'm taking his quote out of context, so I won't identify him here.)

Here was my sarcastic response: 

     Yes, that's a very important principle!

     Let's take, for example, csh, which uses /etc/csh.cshrc and /dev/log and
     /bin/sh and many other files. The reason that all those filenames are
     listed in /etc/csh.conf is so that they can be changed.

     Now, some people want to move /etc/csh.conf itself. That's why csh looks
     for the /etc/csh.conf filename in a hashed /etc/registry.db file.

     Of course, on some machines, we need to move /etc/registry.db. That's
     why the registry filename is listed in a COMPILEDFREGISTRY environment
     variable.

     There's still the possibility of conflict with previous uses of the
     COMPILEDFREGISTRY variable. That's why the name of that variable is
     listed in /etc/fregistry_variable_name.txt.

     You say you want to move /etc/fregistry_variable_name.txt? You fool! We
     have billions of programs that read /etc/fregistry_variable_name.txt at
     the top of main(). Everything _else_ has to be configurable, obviously,
     but /etc/fregistry_variable_name.txt isn't going anywhere.