%Mastodon -- file hierarchy %David Parsons % #Mastodon file hierarchy# I'm thinking about slightly trimming the traditional hierarchy The root filesystem will contain the things that there system absolutely needs to get into user mode. These are most of the things that ship with the core distribution. `/usr` contains the things that make the system useful to users (logging in/out, compilers, fancy text editors and other denial of service programs.) `/opt` (see `/usr/local`) contains third party programs that want to live in a directory called `/opt`. Some programs have 30 years of history demanding that they live in certain directories, so they may have to break the placement rules. =[`/bin`](bin.html)= The vast majority of the programs that ship with the core distribution. =`/boot`= The now-traditional tiny boot partition (to keep the bootstrap in the lower 1000 cylinders of a PC disk) =`/dev`= Either (a) the traditional Unix magic device name directory or (b) a devfs (if that even exists anymore.) =`/etc`= The big pile of configuration settings =`/etc/rc.d`= where runscripts live. =`/home`= The traditional place for home directories. `~root` lives there. =`/lib`= libraries (shared & static), cpp. =`/lib/modules`= kernel module trees. =`/mnt`= scratch mount point. =`/opt`= (see `/usr/local`) =`/proc`= The traditional kernel state directory. =`/sbin`= programs absolutely necessary for boot & maintenance, and which you don't want the user to get their grubby fingers on. =`/sys`= A slightly differently formatted kernel state directory. =`/tmp`= Super-volatile files that can be blown away at a moment's notice. =`/var`= Volatile (and volatile-ish) files. The traditional Unix `/bin` (for boot, system maintenance & repair programs plus their prerequisites) vs `/usr/bin` (all other user-accessable system programs) may not work for me, because (at least on other Unices) I tend to use basically everything I can get my hands on in the system when writing initscripts. And, speaking of `/usr`, this is what I'm thinking of for it: =`/usr/bin`= "user" programs means everything that's not installed by the core system. =`/usr/dict`= system dictionaries. =`/usr/games`= standard games directory. =`/usr/include`= C compiler include files. =`/usr/lib`= even more shared & static libraries. =`/usr/local`= `/usr`'s `/usr` (see `/opt`) =`/usr/man`= manpages (but not for items in `/usr/local`). =`/usr/sbin`= non-essential programs that only root needs to use. =`/usr/src`= Source code that comes with the core system. Modern Unices come with a `/usr/share` directory, which is a gumbo of miscellaneous files. I'm still undecided just whether to care about it. If I put it in, I'll just create a `/usr/etc` and softlink `/usr/dict` -> `/usr/etc/dict`, `/usr/share` -> `/usr/etc`, and `/usr/dict` -> `/usr/etc/dict`. X11 will have to live in `/usr`. `/usr/local` is another hodge-podge directory. The traditional layout is that it has the usual crop of `bin`,`sbin`,`src`,`etc`,`man` subdirectories, but it also has package subdirectories. So it's essentially the same thing as /opt, so either (a) `/opt` is a symlink to `/usr/local` '''or'' (b) `/usr/local` is a symlink to `/opt`. I'm leaning towards having `/opt` symlink to `/usr/local` But what about the Linux FHS™? It's very nice, I'm sure, but * There are already a lot of Linux distributions out there that follow it, * And, to be brutally honest, the userbase for Mastodon is basically me. I need a platform that's stable, moderately up to date, as free of GNUware as is practical with Linux (I have no objections to the software coming from the FSF; A lot of it, possibly most of it, is very good. But with the software comes some very sleazy marketing that I do not wish to be associated with,) and that is easy for me to experiment with. The FHS is another Unixism that makes it difficult to experiment.