Olaf Meeuwissen said on Mon, 18 Oct 2021 18:52:05 +0900

>Hi Steve,
>
>Steve Litt writes:

>> On more thing. When *I* write a program, I never put it in /usr/bin
>> or /usr/local/bin or /opt. I have my own directory, called /d/bats
>> (last century it was called D:\BATS when I used Windows), to contain
>> all executables

[snip]

>Might I suggest $HOME/bin :-)

~/bin isn't ideal for two reasons:

1) It's integrated with all sorts of config, cache, and who knows what,
and can easily be lost or wiped out in a re-installation.

2) On a *personal* computer, a place to store all self developed data
is needed.

I have nothing against the standard File Hierarchy System (FHS) for
servers. It works, it's stood the test of time for 40 years, and it's
standard.

How different things are on a *personal* computer. On a server, it's
all about the computer (virtual or metal), and the user is incidental.
On the personal computer, it's all about the user, and the computer is
incidental.

On a server, it's just fine (sort of) to store all locally developed
and/or used data, config and executables under /usr/local. But on a
personal computer I sure wouldn't want to store my stuff in a directory
owned by root, or under a directory owned by root. I want it in a
directory fully navagable by slitt all the way down.

So isn't that what /home/slitt is for? Not really. /home/slitt is a
huge, disorganized mess with data, config, cache, and all sorts of
other stuff. /home/slitt gets destroyed in every clean install, so I
have a choice:

1) Do a mass copy of the old /home/slitt tree to the new one, and
probably mess up programs whose config system has changed.

2) One by one search the tree for non-config files that are made by
Steve Litt. That this is time consuming is an annoyance. That it's
error prone is very, very bad.

There's also the matter of backup. Do I really want to back up 40,000
files worth of cache to back up my home grown data? Not this iteration
of Steve Litt.

About /home/slitt/bin: Welllll, maybe, but if I need a place to put all
homegrown anyway, why not put my executables there too, and just put it
on my executable path?

So I personally defy FHS by creating /d, owned by Steve Litt, to
contain all my home grown data, programs, config for those programs,
etc. It's really a minor violation of FHS, but it does me immense good.
90% of what I use a computer for is backed up from one tree and laid
back down in that tree. My programs. My books. My copy of the
Troubleshooters.Com website, and my various other websites. All in one
tree, ready to back up or restore at a moment's notice, and small
enough to put on some fairly small media, without cache files and
downloaded files to bloat me up to Blu-Ray size. My stuff under /d is
the important stuff, the stuff whose loss would put me out of business.
Losing the other stuff would be in inconvenience.

I actually violate FHS in a lot of other ways, which I won't elaborate,
to granularize my backup and restore. This works because I'm the one
and only user. Some Personal Computer owners shouldn't do this because
they're not cognizant of different kinds of data. They should probably
do it the FHS way and figure out some backup system, probably brute
force back up all drives, to accommodate their backup needs. But for
the "power user", FHS violations can be helpful and don't do any harm.

SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques