Hi Steve,

Steve Litt writes:

> Simon said on Sat, 23 Oct 2021 15:00:26 +0100
>
>>Olaf Meeuwissen via Dng <dng@???> wrote:
>>
>>>>> 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.
>>
>>Agreed.
>>The most logical place for personal stuff is in your $HOME.
>
> Well, yes, it would have been logical. But everybody, and I mean
> everybody --- The distros, the standards makers, the dweebs at
> Freedesktop.org, everybody made a flinking mess of $HOME. Is the config
> for program myapp in ~/.myapp.rc, ~/.config/myapp/*, ~/.myapp/*?

The FHS says[1] to use $HOME/.myapp.rc if one file suffices and use
files below $HOME/.myapp/ if an application needs more. These have been
pretty standard for a long time. The FHS also acknowledges a number of
later standardization efforts that, for better of for worse, complicated
the situation by adding $HOME/.config. Actually, that is controlled by
the XDG_CONFIG_HOME environment variable, per XDG Base Directory
Specification[2].

[1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#homeUserHomeDirectories
[2]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#basics

So, your apps just put their config files where the "standard(s)" they
follow tells them to :-/

Some, like git for example, now use both, having started with .gitconfig
and .gitignore and now also honoring $XDG_CONFIG_HOME/git/config and
$XDG_CONFIG_HOME/git/ignore. It may eventually deprecate the former and
even remove them sometime.

> Gotta love the way Python puts its cache in ~/__pycache__ instead of
> ~/.cache/__pycache__, where it can be discarded along with all other
> unnecessary cache. I have a ~/node_modules tree with over 300 files,
> and I'm pretty sure node.js installation put them there.

I don't really know about Python but for Node.js, that node_modules is
created by running `npm install` or `yarn install` as a user. Looks
like you ran that with a package.json in your $HOME.

Back to Python, I guess __pycache__ was created when you ran a Python
script you put in your $HOME, or maybe a `pip install` for some little
Python utility you wanted to try out. Not saying $HOME/__pycache__ is
a bright idea but, like the Node.js case, I think it's something you
inflicted upon yourself.

If simply installing packages from your distribution, or you using
software provided by those packages, was responsible for this, I'd
consider it a bug and would file a bug report.

FWIW, I typically create a dedicated directory, under $HOME/tmp/ or
$HOME/src, when I try out other people's code or extract an archive.
This makes it a lot easier to keep things out of each others and your
own way. It also makes cleaning up afterwards easier and if I put it
below $HOME/tmp a cronjob will do that for me, eventually, if I don't
do it myself.

> Directories "~/Schember, John" and "~/Litt, Steve" were kindly
> contributed by Calibre. Gotta love those spaces and commas.

Good reason not to use Calibre ;-)
Why would you create a directory named after the user in that user's
$HOME directory? And with spaces and commas for crying out loud!
Here's wondering how well they cope with full names using non-Latin
scripts. I've got a few of those at home ;-)

> At this point I can't be sure because I run a rolling release, but I
> think ~/Music, Documents and ~/Videos were put there by the distro ---
> I'd have no reason to do that.

They were very likely created by your desktop manager or application in
an attempt to adhere to the XDG user directories (which themselves seem
to hark back to the Glib user directory[3] conventions).

[3]: https://docs.gtk.org/glib/enum.UserDirectory.html

FWIW, you can customize these names to taste and prevent them from being
updated (or translated if using a different locale when logging in).
Check user-dir.dirs(5) and user-dir.conf(5) for details.

> They could have put all three within something called ~/Media, and
> called the current ~/Media ~/Automounts. But even moving them like
> that doesn't change the fact that some of your documents were produced
> by you and can never be replaced, and others were things that could be
> re-bought if lost. This has a huge impact on backup. For a *Personal
> Computer*, $HOME is a zoo, and I either have to live with it,
> reorganize it only to get broken again with the next major upgrade, or
> violate FHS.

First of, you're not violating the FHS in the least bit. You're just
organizing your stuff in a somewhat unusual way. As long as you have
given "extremely careful consideration of the consequences" to creating
additional directories in the root hierarchy, you're FHS compliant.
As to configuration files and "default" directories, the XDG Base and
user directories, those are fully configurable so you can really put
them wherever you please.

Next, the importance and restorability of your self-created documents
and those that were created by others. As long as you keep those neatly
separated, which you seem to do, then there is not much of a problem and
backing up is not much of a hassle. $HOME might be a bit of a zoo, but
it's not a jungle.

About your "get broken again with the next major upgrade", you said
you're using a rolling release at this point. That means you probably
get your upgrades in bits at a time, implying stuff only breaks in
relatively minor ways or at least not all over the place. At least
that's what I have experienced with tracking "testing" for many years
(first Debian, later Devuan). I've just been fixing up my stuff and
systems as the need arose and even that wasn't very often (excluding
systemd upgrades). When testing is declared stable there's a bit more
chance of breakage but you can always put packages on hold until you're
ready to deal with them possibly breaking things.

> Parodying Billy Joel, I didn't start the fire.

But you can try to put it out ... or run into it, grab whatever's dear
to you and put it in a safebox.
Looks like you chose the latter ;-)

>> <a bit
>>tongue in cheek> If it’s a mess at home, then tidy up a bit
>
> This would be much more true if not for the fact that a bunch of
> invaders called upgrades would again mess up my home.

What "invaders"? There's no need for drama. You're the one running
`apt upgrade`, right? Or whatever package management tool you use.

Besides, I have yet to encounter an upgrade that messed up my $HOME. At
worst, an upgrade would no longer honour the configuration settings that
I put in place. I can fix up the configuration, insofar possible, or
downgrade the package in question if in a pinch.

>> - better
>>than deciding home is too much of a mess and effectively just moving
>>house to start again at another home.
>
> Let's examine the preceding sentence fragment. Is it really better to
> try to manage the mess if the new home would be free and the invader
> upgrades couldn't touch my new house?

The cost is managing two (or more) houses instead of one.

BTW, I assume both root and $USER have read/write access to your new
house. In that case, "invader upgrades" can touch your new house. It
will be very unlikely but they can. If preventing those "invader
upgrades" from tampering with things, your new house is really just a
case of "security through obscurity".

> I'm not saying everybody should do it my way, but what I don't
> understand is the resistance to a method with no cost, at least as long
> as I'm in charge of the computer, which will be til the day I die.

I'm not saying you should do it my way either. What I don't understand
is why one would bother with two (or more) houses instead of one (for
each user).

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