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
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

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.