Hacker News Reader

Comment by stonogo | Hacker News Reader

Before this, when I wanted to remove a program's detritus from my disk, I did rm -rf $HOME/.program

After this, it's an easter egg hunt to guess what dot-directories got spammed.

As far as I can tell, the XDG spec only benefits people who care really hard about how many hidden files are in $HOME. It definitely breaks behavior for people who DO want those per-app directories/files in $HOME, because the XDG spec does not mandate that the files created under e.g. .config/ are dotfiles themselves. So setting $XDG_CONFIG_HOME=$HOME just creates non-hidden files in the home directory.

At no point in this article is a technical justification made for this rigamarole, but this article goes to great lengths to accuse people against it of cowardice, ignorance, or arrogance. Just... why?

View on HN

With XDG a program's user files are split into pieces with varying degrees of detritusness. You generally only have to look in four places in ~ when cleaning up after a program called foo:

- ~/.config/foo -- only you write files here, so it's your detritus, not the program's :)

- ~/.cache/foo -- this is non-essential cached data, by definition detritus. Go ahead and clear out all of ~/.cache whenever you feel like it

- ~/.local/share/foo -- this is the program's user-specific data, data which it may have created or which you may have created. Whether it is detritus is up to you

I think the strongest justification for XDG is that it makes it stupid easy to configure backups so as to exclude cache files. And the separation of config from data also makes it easy to keep a git repo for all your ~/.config files.

> - ~/.config/foo -- only you write files here, so it's your detritus, not the program's :)

That's not true.

> ls ~/.config/cef_user_data/Dictionaries

> en-US-9-0.bdic

That's a dictionary file written in a binary format. I don't even know what program wrote this crap there, only that it's embedding chrome (CEF).

> ls ~/.config/ibus/bus/

> dcf58003d1744e71aa86dd97e951d49d-unix-0 dcf58003d1744e71aa86dd97e951d49d-unix-1 dcf58003d1744e71aa86dd97e951d49d-unix-wayland-0

Files describing how to do IPC with current processes. They belong to ~/.local/state not .config.

This time, I won't even try to make a judgement as to what is "my detritus" as opposed to the program's because there are too many files involved, and will just show how much they occupy on my drive despite being in .config when 90% of them really ought to be in .local/share and .cache

> cd ~/.config/google-chrome

> du -h

> 999M .

Ahem. I think the idealism toward the XDG spec has not panned out.

By the way, Chrome does have folders in .cache :

> cd ~/.cache/google-chrome

> du -h

> 651M .

But, I believe it doesn't put "local storage" stuff from webapps there.

It doesn't use ~/.local at all.

~/.config is broken beyond belief and not the place where you just have "your config files".

The only sane way to manage "your config files" is to put them in a git managed folder and use a symlink farm program.

> The only sane way to manage "your config files" is to put them in a git managed folder and use a symlink farm program.

Another option is to ignore all files and selectively allow the ones you want to track. That's what I'm doing now.

> Files describing how to do IPC with current processes. They belong to ~/.local/state not .config.

XDG_RUNTIME_DIR (i.e.: /run/user/1000)

It's a misunderstanding that only the user writes to config. It is meant for persistent user configuration, possibly generated by the app - the type you might want to back up. You are not supposed to understand or be able to read every file in there, just be able to know the usage.

.local is rather new, so .config has been misused for what was meant to go there. Some applications are broken and stuff caches in there (Google stuffs shader caches in there it seems?), but minor misuses is one thing - .config and .local are conceptually very close for example - intentional disobedience another.

The spec is well adopted (I have hundreds of folders in ~/.config, only tens in ~), and there is no reason not to follow it - especially for cross-platform things where path logic must already exist. There are just some projects that decide to stubbornly go against community and user wishes and disallow improvements.

>It is meant for persistent user configuration, possibly generated by the app - the type you might want to back up. You are not supposed to understand or be able to read every file in there, just be able to know the usage.

I understand your point, but there is a lot more going on than just "configuration that isn't human readable" unfortunately.

> (Google stuffs shader caches in there it seems?)

They also stuff web storage.

And despite their misuses of .config they also still pollute the root $HOME by creating $HOME/.pki. Deleting the folder and restarting Chrome will always create this thing.

> And the separation of config from data also makes it easy to keep a git repo for all your ~/.config files.

This is what i do, so with `git status` i see all the shit that i didn't put there. So

> ~/.config/foo -- only you write files here, so it's your detritus, not the program's :)

... is obviously not true.

> At no point in this article is a technical justification made...

> Just... why?

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.

And therefore developers should try to adhere to the standard even if it is difficult to implement, since software is written for users, first and foremost.

Genuine question: was that not clear enough?

> 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.

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.

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.

The position is clear, but I don't think it's a valid position. If I, the user, want my dotfiles to exist per-app in $HOME, the way they have since I started using UNIX in the 1980s, I have no recourse. Not being able to configure the location of config files to the place they already were in the name of "user choice" is incoherent at best.

A fellow commenter pointed out that it makes excluding cache files from backups much easier. That is a great technical justification, which hilariously does not apply to vim, which by default drops swapfiles in pwd anyway.

I further reject the notion that this is something being "done to the user" by the software. Software is a tool of the user, refusing to learn how the tool works and pretending that the program you chose to execute is some kind of rude houseguest is just wheelspinning.

> which hilariously does not apply to vim, which by default drops swapfiles in pwd anyway.

That's configurable! Check out :h directory , or just add *.sw? as a filter in .gitignore.

Configurable is best. XDG peeps get what they want, the rest of us get what we want.

I know it's configurable; that's why I included the phrase "by default." The linked issue does not address this.

And I'm not sure, maybe you just didn't read the rest of my comment, but in it I explain that when XDG people get what they want, it becomes literally impossible to configure the software to revert to the previous norm. In other words, when XDG people get what they want, nobody else can.

I'm not sure I'm following you. What state are we considering to be "what XDG wants"? If it's just adding XDG as an option for where config is, then that's fine. If it's replacing custom config location with XDG only, then I would certainly agree that they are unduly influencing things.

It depends on how XDG dirs are handled by the software. If we're forced to use the env vars then it's not really optional anymore. But if the program can default to another location without those env vars set (trivial with an ldpreload script or something), then it supports both.

Vim can be configured to use XDG dirs, if you really want to. Does Neovim limit users to only XDG for its config? I can't think of many pieces of software that outright force XDG. Maybe GNOME stuff?

Every software that follows XDG-basedir stores config in ~/.config if the env var isn't set.

Imagine you have program "foo" which has config, cache, and so on. What XDG-basedir env vars can you set to make it use ~/.foo for all of that? If you try, then because software following XDG-basedir probably doesn't anticipate that XDG_CONFIG_HOME and XDG_CACHE_HOME might have the same value (and because your time is more valuable than auditing the code to find out whether they did anticipate this), you are left with .foo/config, .foo/cache, and .foo/local.

You have created a new "home", and, more importantly, you disallow "foo" from ever spawning a separate program that also uses the same XDG vars. Spawning programs is rather a central Unix principle if you have many tools that each do one thing well.

If you want an application to use a directory all to itself, you can set $XDG_CONFIG_HOME when running that program. Some software has no facility to choose the location of configuration and cache files at all; this specification at least ensures that the user has a choice.

Reply on news.ycombinator.com