NotTheFhs

The Linux 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.