Comment by foresto
4 days ago
Does anyone know why, when Lennart and friends wrote their XDG Base Directory Specification, they decided that each user should replicate /usr/local/ subdirectories under $HOME/.local/?
Doesn't being under $HOME make .local redundant? I guess one could argue for binaries going in an architecture-specific subdirectory if $HOME was on a shared filesystem, but that's not what's being done here.
To me, $HOME/.local/share and its siblings are just a needless level of indirection, forcing me to jump through an extra hoop every time I want to access what's in there.
(I know it's sometimes possible to override it with an environment variable, but the predictably spotty support for those overrides means I would then have to look for things in two places. I think sensible defaults would be nicer.)
> Does anyone know why, when Lennart and friends wrote their XDG Base Directory Specification,
It is Microsoft thing. You must pollute the user's /home as much as you can. Can i say that i have 3 daemons on my computer respobsible for ... credentials. This is the way to go.
Dunno the historical reason but I sure as heck find it nice to know without ambiguity that the folder called "share" corresponds to that special directory and isn't a random folder in my home directory for files that were intended to be e.g. shared with someone.
Sure, but I think the better choice for $HOME/.local/share would be $HOME/.share, not $HOME/share
This would match the more recent $HOME/.var that's in widespread use via Flatpak.
The ~/.local prefix is so that you don't pollute the home directory too much.
That doesn't align with their choice of $HOME/.cache (to which users need to navigate much less frequently than $HOME/.local/share), nor with how few items $HOME/.local typically saves from landing in $HOME, nor with the normally hidden state of everything starting with a dot.
So if that was their reasoning, it reinforces my view that they didn't think their design through very well.