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