Steve Litt writes:

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

In the case of $HOME/bin getting lost or wiped out in a re-installation
I'd argue you have bigger problems than just losing $HOME/bin. You have
most likely lost all of your $HOME, and maybe even other users' $HOME as
well.

Personally, I haven found it being "integrated with all sorts of config,
cache and who knows what". Yes, if $HOME/bin is in my $PATH, that may
affect some programs. In that case, it's a bug of my own making and I
can fix it by removing $HOME/bin from my $PATH or renaming whatever
program in $HOME/bin causes the trouble.

FTR, most of my $HOME/bin consists of scripts or stuff that you might
want to install in /usr/local/bin or /usr/local/sbin. In addition, I
tend to choose script names carefully so as to not collide with things
that are in the default $PATH. My $HOME/bin/emacs is an exception ;-)

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

On a *personal* computer, my *personal* directory is $HOME. $HOME/bin
is therefore my *personal* collection of (self developed) programs.

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

ACK.

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

Eh, isn't that what $HOME is all about? Giving you a place of your own,
fully navigable and controllable by $USER (or $LOGNAME in case you're
running from `cron` ;-).

>From what you write it sounds as if `root` owns your $HOME. That'd be
really unusual because user accounts, by default, get a dedicated $HOME
directory, owned by that user. You'd have to bend over backward to get
the Devuan installer or `adduser` to do something else.

olaf@quark:~$ echo $USER
olaf
olaf@quark:~$ ls -ld $HOME
drwxr-xr-x 1 olaf olaf 1686 Oct 21 18:37 /home/olaf

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

Ah! So the problem is really one of *personal* hygiene ;-P

# Not saying I'm squeaky clean myself, mind you!

> /home/slitt gets destroyed in every clean install,

If "clean install" means wiping the partition table, then yes, same here
(`sed 's/slitt/olaf/') but there are occasions where I don't do that and
preserve the partition that holds `dirname $HOME` and remount it there.
Especially when the machine caters to other users as well.

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

What's wrong with fixing issues as they are discovered?

I haven't really run into many issues myself in the course of close to
two decades. Some programs update their configuration files for you
when they discover a version change, others only need a minor tweak.

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

You could track your hand-crafted files elsewhere and copy from there
(or symlink to it). Personally, I use vcsh in combination with myrepos
to version control sets of configuration files. This lets me share my
configuration tweak across machines and activate only those sets I need
on a particular machine.

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

  olaf@quark:~$ find -type f | wc -l
  239613
  olaf@quark:~$ find .cache/ -type f | wc -l
  28202              # if I look harder I can bump this to ~32,000

I don't know what you use as your backup solution but I have found rsync
in combination with .rsync-filter files to exclude stuff a quite decent
solution for my $HOME. That is, after you get your .rsync-filter files
in shape but that's a matter of rinse-and-repeat-until-satisfied issue.

If you want to keep timestamped backups that's something you can easily
do with `cp -lR` on the backup target. I get by fine with a latest-only
backup that's rsync'd weekly courtesy of cron (deleting files on the
backup target that no longer exist locally).

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

I don't care about the minor violation of the FHS at all. That's your
prerogative. It's just that is soooo 20th century Windows ;-P

> 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 don't run a business so our priorities probably differ. I backup to a
NAS and can restore from there if needed. Doing a full restore would
probably take a couple of hours but, when in a pinch, I would cherrypick
the backup for what I need rightaway.

In terms of backup size, I'm quite beyond Blu-Ray size as I tend to err
on the safe side. I even back up stuff that's backed by public git
repositories just so I don't loose stuff that I haven't pushed yet :-)

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

This "power user" has arrived at a different solution that Just Works,
for him at least, and keeps everything below $HOME. Maybe it works for
others too. If so, the more, the merrier :-)

BTW, about doing it "the FHS way" merely means that you put and keep all
your *personal* stuff below your $HOME. You could easily have put that
/d of yours at $HOME/d and be FHS-compliant ;-P
Oh, and while you're at it, rename bats to bin :-P

FWIW, I also have $HOME/etc, $HOME/tmp and $HOME/var. Guess I spend too
much time doing system administration :-)

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join