The [Linux Filesystem Hierarchy Standard](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)
is a good, longstanding convention for where files normally go on a Linux system. Now *I expect
authors of Linux software to adhere to this standard*, such as binaries in `/usr/bin` if installed
by the packaging system, `/usr/local/bin` if not, or possibly somewhere in `/opt`. Home dirs
go in `/home/`, and so on.

That said, however, I use the command line heavily, and prize efficiency. Thus I happily
break the FHS when organising my own files. The principles are these:
1. Those directories in the FHS intended to be managed by the OS, such as `/usr/bin`
    I leave alone.
2. Commonly used paths should be the shortest. It is far quicker to type `cd /d/b/vid`
    than to type `cd /media/user/MyVideos` or such. It is far quicker to do this
    than to bother trying to manage files using the mouse and Dolphin.
3. Typing `~` is awkward compared to `/` due to the layout on the keyboard:
    the `~` requires shift, and moving from the home position, and even
    then, to refer to a file in your home directory, you still need to type the `/`.
    So the easiest thing finger-wise is to have a bunch of directories with 1-3 character
    names in the root directory. E.g. on my music player, `/mus` is a symlink to `/data/music`,
    and `/pod` is a symlink to `/data/music/podcasts` and so on.
4. Provided nothing else us using a name in the root directory (like e.g. `/bin` or `/dev`),
    I feel free to have as many directories and symlinks in the root as needed.
5. Storage drives go under `/d`, usually `/d/a`, `/d/b`, and so on.

I presently store all my scripts in a hierarchy under `/usr/jda`, so `/usr/jda/bin` is where
all my scripts end up. I have a git repo at `/usr/jda/cmds`, and scripts are organised
by categories under this `/usr/jda/cmds/fs` and `/usr/jda/cmds/media` and so on. This makes
it easy to keep everything sync'd between my machines. (I have a once per minute cron job
to check of `/usr/jda/cmds` is up to date, and a prompt function to alert me if not.)

## Snaps

One thing I detest about snaps is how they strongly dictate filesystem access, and crucially
have no easy means to grant permission to snaps. For example I'd like to permit a given
snap to access anything under `/d`. But alas I can't. The fix for me is to have
entries in the `fstab` like
```
/ /home/me/root none defaults,bind,nofail,user 0 0
/d/a /home/me/d/a none defaults,bind,nofail,user 0 0
```
and so on. Then I can effectively grant permission by making these mounts.

## My Nonstandard Mount Points
1. Local drives go in `/d` (for 'drive'), such as `/d/a`.
2. Network drives go in `/n` (for 'network'), such as `/n/dink`.
    * These typically mount via sshfs into the `/d` dir on the target

The end result are lines like this in the `/etc/fstab`
```
UUID=... /d/a ext4 defaults,nofail,user,noatime 0 0
sshfs#md@dink:/d /n/dink fuse defaults,user,_netdev,allow_other 0 0
```

## Finally

* Under cygwin, since its root is at `C:\Cygwin64`, I can make whatever directories
    and symlinks in the root that cygwin sees without issue.
* Under macos, naturally, I can't do any of this. To me, macos is like trying to 
    knit in rubber gloves. It's great as an appliance for creative software,
    but gets annoying once you get away from such creative software.
    I get the idea if immutable distros, so I understand Apple doing this.
    It would be good for Windows to have the core of the OS immutable in some
    way, but isn't something you can do with the way Windows organises files,
    and you can't change this organisation without breaking stuff.