Item — HN Reader

I hate XDG stuff so much. I just wish every app had their own folder in which they can put whatever they want. If home directory clutter is the issue, then just ~/crap/.{app1,..n} can be standardised.

Basically, I want app/kinds-of-data and not the other way around.

3 comments

$XDG_CONFIG_HOME is usually "~/.config/{app1,...n}" so, it's close? Plus it allows a user to redirect it to a path of their choice, if all apps used it to begin with.

Don't get me wrong -- some of the choices made by the XDG/FreeDesktop folks rub me the wrong way too ...

No, not quite. XDG-compliant programs end up storing stuff in one or more of the following places:

~/.cache and ~/.config and ~/.local/share and ~/.local/state and ~/.local/bin

I used to get annoyed by non-compliance to XDG. Now I wonder if I'd actually prefer apps to reverse the hierarchy (eg, ~/.apps/nvim/{cache,config,state}).

I find it obnoxious when apps make me hunt for all of their cache directories. Just put all the cache data in one place.

Make it clear what needs to be backed up, what is ephemeral, and so on. Just put everything in ~/.cache. Chromium in particular is bad at this and has many types of cache.

That's where I would probably split myself... ~/.cache/appname for cache data, and ~/.???/appname/* for everything else.

This is a huge part of why I like docker-compose and docker in general, I can put everything I need to backup in a set of volume maps next to each other.

I would definitely prefer this. I've never wanted to see the "cache" stores for all (XDG-compliant) apps, but often want to see everything for a single app.

It’s less about wanting to see all the caches, and more about excluding all the caches, e.g. from backups. Likewise, there is one directory for machine-independent configuration which you might share, and another for machine-specific state (such as window positions).

Is the spec perfect? No, of course not. But is it thoughtful, and does it address genuine needs? Yes, certainly.

It also enables you do things like:

a) store caches & libdata on different disk

b) consistently 'reset' cached data for kiosk style logins

c) make config read-only, or reset to a known good state

d) Roaming profiles where the cache is excluded from sync across machines

Most computers + home directories are 'personal' where this largly doesn't matter, but there are often sound operational reasons for this seperation in cases where you are responsible for a fleet of computers. I too perfer the 'everything related to this app in one dir' approach. Crazy idea: for apps adhering to XDG, you could point all these vars at a directory under a FUSE-style mount, which then remaps the storage any way you'd like. :)

The reasoning behind historical convention of kinds-of-data/app in Unix is so you can partition the disk easily and apply policies based on type (like backup /etc, tmpfs on /tmp, mount /usr read-only)

Although I'll never forgive XDG for renaming etc to config and var to state. Would be so convenient to set PREFIX=~/.local for some things

as someone who works on 3 different machines regularly and likes to have the same environment on all of them... i would LOVE if applications would stop cluttering my .config with cache data and other bullshit i keep having to exclude from sync.

`rsync` should have something like `.nosync` akin to `.nomedia`, and the directory should be added explicitly if one wants it to be synced. Or something like a `--profile` option where `.nosync` then can contain an allow/disallow filter for profiles.

I have the same issue with the scripts which trigger `rsync` getting confusingly complex because of all the include/exclude arguments.

I've been using a .rsync-filter file for something like what you mean for ages for my homedirs backups. It's a bit tricky probably to make it right the first time but once it's there it just works.

https://manpages.debian.org/bookworm/rsync/rsync.1.en.html#f...

That's generally what the Cache Directory Specification attempts to cover: https://bford.info/cachedir/

Lots of things like the Rust tool chain now create the CACHEDIR.TAG files so that backup tools can ignore that part of the hierarchy. Alas, I believe the rsync folks refuse to implement it.