Can I also soapbox about the XDG_CONFIG_HOME (~/.config) folder having gigs of temp data in it? (I'm looking at you, Slack !) How awesome would it be to be able to back up my custom app configs just by copying around one tiny folder? Or throwing it in a git repo and knowing what config changed when? :\
Should've kept Slack in a containered in a browser tab where it belongs so it can't go messing with your system or prevent you from blocking their tracking.
And then I've seen websites hoggi g gigs of local storage after you visit them once a blue moon. The trend is blatantly towards no optimization whatsoever. Apart from profits and squeezing the last drop off your customers by any means necessary
Hah I was literally just complaining about applications not following the XDG directory spec today. there's a non-exhaustive list of applications on the archwiki [0] that put their config/data in dotfiles in the home directory. surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce. a Reddit thread has some list of issues where the…
I mean, from the perspective of a person that hasn't heard about it before, this is just another standard[0].
I opened your links. There's no easy way to judge the traction or popularity of this. Why do you think maintainers should just apply another standard that's thrown at them?
I don't mean to be dismissive nor criticize the standard itself. I'm trying to give you a glimpse of what a person that hasn't heard about XDG before sees, when they open your links.
Hah I was literally just complaining about applications not following the XDG directory spec today. there's a non-exhaustive list of applications on the archwiki [0] that put their config/data in dotfiles in the home directory. surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce. a Reddit thread has some list of issues where the…
The dotfiles and dotfolders directly in the home folder is "the way it was always done", and now some "new kids" came and want changes done to software which has existed before they were even born. People have muscle memory for those folders, some have hardcoded those paths in other scripts, others just don't care, and things stay as they always were. On one hand, it's great to have all the stuff in the same place, o…
The XDG base directory specification[0] was initially introduced in 2003; 20 years ago now. Yes there's plenty of software that existed before 2003 which didn't respect XDG, but most all of the Linux software dumping dotfiles in my homedir where written not just after 2003, but many years after 2003. For example, the following pieces of software all have dumped garbage in my homedir, and all are much less than 20 years (or even 15 years) old:
There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short (seriously, the standard's contents fit entirely on three A4 pieces of paper)
Hah I was literally just complaining about applications not following the XDG directory spec today. there's a non-exhaustive list of applications on the archwiki [0] that put their config/data in dotfiles in the home directory. surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce. a Reddit thread has some list of issues where the…
The dotfiles and dotfolders directly in the home folder is "the way it was always done", and now some "new kids" came and want changes done to software which has existed before they were even born. People have muscle memory for those folders, some have hardcoded those paths in other scripts, others just don't care, and things stay as they always were. On one hand, it's great to have all the stuff in the same place, o…
The really fun part is when you have a program that has ~/.programX, but also ~/.programXy, ~/.programX_cache, ~/.programxrc, ~/.programx_init, ~/.programx/a_whole_directory, ~/.otherthing, ~/.maybe_a_database_for_good_measure.sqlite, ~/.and_the_kitchen_sink_too. And that's not even getting into questions like "can I nuke ~/.programX_db to clear the program's cache without losing my configurations?". I agree that the XDG spec isn't an improvement for programs that have _precisely_ one config file, but it's a _major_ improvement for programs that need multiple config files, config directories, separate configs and caches, and more, and it's not a _regression_ from single-file configs.
Can I also soapbox about the XDG_CONFIG_HOME (~/.config) folder having gigs of temp data in it? (I'm looking at you, Slack !) How awesome would it be to be able to back up my custom app configs just by copying around one tiny folder? Or throwing it in a git repo and knowing what config changed when? :\
$ du -sch ~/.config/Slack 846M $HOME/.config/Slack 846M total ... this is on a two day old machine. WTF, Slack? Junk cached data belongs in ~/.local/share ($XDG_DATA_HOME), not ~/.config.
a bunch of windows stuff does this too putting config in appdata/local and huge cache assets in appdata/roaming.
anything that depends on good behaviour is doomed imo like Google wave circles
The dotfiles and dotfolders directly in the home folder is "the way it was always done", and now some "new kids" came and want changes done to software which has existed before they were even born. People have muscle memory for those folders, some have hardcoded those paths in other scripts, others just don't care, and things stay as they always were. On one hand, it's great to have all the stuff in the same place, o…
The XDG base directory specification[0] was initially introduced in 2003; 20 years ago now. Yes there's plenty of software that existed before 2003 which didn't respect XDG, but most all of the Linux software dumping dotfiles in my homedir where written not just after 2003, but many years after 2003. For example, the following pieces of software all have dumped garbage in my homedir, and all are much less than 20 yea…
But why should developers conform to that specific standard, if (for them, and many of their users) it makes more sense to use a "~/.wine" (or whatever other) folder?
If i want to completely remove wine from my profile, how many folders do I have to delete doing it the old way? One - ~/.wine. How many using the new? One in .config, then .local/share, probably one in .cache... oh wait, .local/state too.. Probably.. well, maybe, I'd have to check manually. Same for other software. One folder to remove, one folder to backup, one folder to restore.
The dotfiles and dotfolders directly in the home folder is "the way it was always done", and now some "new kids" came and want changes done to software which has existed before they were even born. People have muscle memory for those folders, some have hardcoded those paths in other scripts, others just don't care, and things stay as they always were. On one hand, it's great to have all the stuff in the same place, o…
The really fun part is when you have a program that has ~/.programX, but also ~/.programXy, ~/.programX_cache, ~/.programxrc, ~/.programx_init, ~/.programx/a_whole_directory, ~/.otherthing, ~/.maybe_a_database_for_good_measure.sqlite, ~/.and_the_kitchen_sink_too. And that's not even getting into questions like "can I nuke ~/.programX_db to clear the program's cache without losing my configurations?". I agree that the…
That's why that kind of software uses a .programX directory, where everything like that can be put in.
Look at ~/.wine for example... config files, whole C drive, everything in one simple folder. Want to upgrade to an alpha version to test something, but don't want to break anything that's now working? Just backup that one single folder. Restore or migrate configuration to another computer? One single folder. Remove any trace of that app? Again, one simple folder.
Want to do the same with google chrome? .config/google-chrome... oh wait, what if there's something in .local too? Still doesn't work? Oh wait, you forgot the .cache directory, and have been loading an old version of something.
Would be cool if there was a tool that could detect that configured path was attempted to be opened, and redirect the open() syscall to the real path... But that would most likely require kernel support. Boxxy seems good enough for userspace.
I actually attempted using ptrace to rewrite syscalls first! It was... horribly painful, and didn't work anywhere near as well as the bind-mount version.
For a structured approach to ptrace/syscall rewriting, you could try FB's reverie. I worked on and used it during an internship a few years back; it's pretty amazing at what it does.