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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
