Hacker News Reader

Comment by rascul | Hacker News Reader

> Author here; I was under the impression the quote from the Vim issue tracker in §3.1 was a good cornerstone for the article, which is that accepting and implementing an existing standard—however hard it might be for developers now—is good for users in the long term, because it makes life easier for them.

In my opinion, ~/.something is easier for me as a user than using the various XDG directories. But in practice, I really don't care what scheme an application uses.

View on HN

The XDG spec gives YOU as the user CONTROL to get it like how you want it to be. That is why you can set the $XDG* variables, so that the software listens to your wishes. Without XDG adherence, software packages just piss all over the place, wherever they like to.

There are programs that even manage to create multiple dirs, like .something1/ and .something2/. Some other programs are even worse and put files just into $HOME. Good luck with backups.

With XDG adherence applications might comply and put files scattered around the various XDG directories. Before XDG, applications that pissed all over my $HOME were rare, applications generally played nice and kept only on dot file or directory.

Backups are even harder now because I have to cherry pick what to backup from even more places. I don't backup all of $HOME because it's loaded with junk I don't want to waste backup space on.

As another user, I do care, and I dislike the XDG directories. ~/.local/share/foo in particular is obnoxiously longer than ~/.foo, and the existence of the XDG spec means that if I don’t know where a program stores its files, I now have to check three possible locations (~/.foo, ~/.config/foo, ~/.local/share/foo).

The point is that you could use those locations if you wanted, but many apps don’t make it easy to make them respect your desired config.

Many apps that claim to respect XDG…don't respect XDG fully and mix executables, config, temporary files, and persistent files in some combination of the spread of XDG directories.

Not really - since XDG decided to go for non-hidden files inside the XDG dirs. So you can't just set your XDG config dir to be your home dir, since all the app config folders will be non-hidden folders in your home dir. And setting up multiple XDG dirs to point to the same dir will probably cause even more havoc, if apps use the same file name with different meanings in different XDG dirs.

Now I have to scan whenever ~/.foo/tmp, ~/.foo/cache, ~/.foo/cef/Cache or whatever hell has the useless uncompressible, duplicated and always changing data to exclude from backups and synchronization, for every program that fills random dotdirectories.

I find it easier to exclude all .* from the rsync I do to synchronize documents/data etc, and exclusively manage the dotfiles through another program, homeshick, where instead of making exclusions, I make explicit inclusions. The config files I care about are far, far fewer in numbers than the random crap programs spew in dot folders.

I like the XDG specs, but even programs that pretend to follow it don't follow it. CMUS, a music player, moved into ~/.config.. moved everything, including files that belong to .cache and .local/state. Google Chrome has 999 mb worth of files in its .config folder on my computer. The truth of the matter is that XDG only managed to encourage developers to move their files away from the root of $HOME but they didn't manage to make people respect a proper hierarchy of files.

> The truth of the matter is that XDG only managed to encourage developers to move their files away from the root of $HOME but they didn't manage to make people respect a proper hierarchy of files.

This is a great point, honestly. XDG actually does specify where things are supposed to go, and distinguishes between config, cache, state, and strictly-user files, but devs don't respect that hierarchy, either.

Apps dumping cache/state into ~/.config/myapp/ is still better than ~/.myapp in the vast majority of situations. I can still usually afford to sync / strongly back up ~/.config even with a few bad apples barfing heavyweight cache/data there (and I can always use ignore rules), while syncing all of $HOME is just a nonstarter.

> I can still usually afford to [backup huge caches incorrectly placed into ~/.config], while syncing all of $HOME is just a nonstarter.

I completely fail to understand this viewpoint. The non-config files that I intentionally put into $HOME are infinitely more valuable than anything I would want to backup from .config.

I have hundreds of gigabytes in non-hidden sub-directories of $HOME, such as all my family photos, all my health-related documents, all my email, and so on -- and they are backed-up every single day.

Why is backing up your actual files in $HOME a non-starter? What makes your .config more valuable than everything else in your $HOME?

As another user, I find it infuriating that 95% of all applications I run respect XDG and go into ~/.config (where I have hundreds of folders), but a handful or two do not and litter in my home folder.

If only the last stubborn applications would comply, I would have just 1 place to look for config, and one place to wipe caches.

Plenty of apps which use .config use it for everything, caches included. The percentage of apps which fully respect the XDG spec is much lower than the percentage that use the XDG config dir. And this is to be expected - changing the default config dir is one thing, changing your code to put different kinds of files in different places is much more work.

Reply on news.ycombinator.com