5 ms·

I personally don't like xdg. I have bin files from pip and other stuff in ~/.local/bin. I have huge amounts of cache files in both .cache and .config. It's sup

I personally don't like xdg. I have bin files from pip and other stuff in ~/.local/bin. I have huge amounts of cache files in both .cache and .config. It's supposed to make my life easier by being able to backup .config and dump everything. but in reality this doesnt happen. Backing up .config for just the user defined configs is a massive PITA. you have to put so many gitignore exceptions and I'm not even talking about the gigs of data all the chromium derivatives put into that folder.

gumby 8y ago
Can you ln -s /tmp .cache. ?
- lugg 8y ago
  You can try. I mount .cache as tmpfs. You need at least 500mb for your browser alone. Browsers tend to work fine. Some apps just fail badly like rofi (command history stored there oof) For what it's worth I also tmpfs+asd .nvm, .npm, and */node_modules, without any major headaches. I did have to fix a couple minor pathing dramas but nothing too drastic.
- OJFord 8y ago
  You can export XDG_CACHE_HOME=/tmp
chmln 8y ago
> you have to put so many gitignore exceptions and I'm not even talking about the gigs of data all the chromium derivatives put into that folder Yeah but chrome devs half-assing the trivial xdg spec doesn't mean that xdg sucks - its just not implemented properly.
- Something1234 8y ago
  I think xdg has an issue of being obtuse when I googled it a while ago, it was very confusing, and I didn't find any real definitions. However I didn't look that hard.
  - AnIdiotOnTheNet 8y ago
    Freedesktop standards are nothing if not overly complicated and confusing.
  - wilmoore 8y ago
    I agree, you didn't look very hard.
PostThisTooFast 8y ago
XDG does indeed seem like shite, calling for such nonsense as this: "a default equal to $HOME/.local/share should be used." NO. Nobody should be creating HIDDEN directories and files. That's just a lazy, sneaky way of trying to hide turds from the user. Either you're storing legitimate config files that should be visible to the user but kept in a tidy location, or you're littering his storage with turds that should, likewise, be kept elsewhere. Apple's history of polluting every visited volume is a great example. Their excuse was storing file-browser state (for example, which directories were expanded) as invisible files all over the place, even on shared network drives. Of course, this design is a failure, because the next person to visit that volume will overwrite the turds. Not to mention the arrogance of polluting everyone ELSE's system, instead of just storing all this crap as URL/state on the local machine in one directory designated for that purpose.

gumby 8y ago

Can you ln -s /tmp .cache. ?

lugg 8y ago
You can try. I mount .cache as tmpfs. You need at least 500mb for your browser alone. Browsers tend to work fine. Some apps just fail badly like rofi (command history stored there oof) For what it's worth I also tmpfs+asd .nvm, .npm, and */node_modules, without any major headaches. I did have to fix a couple minor pathing dramas but nothing too drastic.
OJFord 8y ago
You can export XDG_CACHE_HOME=/tmp

chmln 8y ago

> you have to put so many gitignore exceptions and I'm not even talking about the gigs of data all the chromium derivatives put into that folder Yeah but chrome devs half-assing the trivial xdg spec doesn't mean that xdg sucks - its just not implemented properly.

Something1234 8y ago
I think xdg has an issue of being obtuse when I googled it a while ago, it was very confusing, and I didn't find any real definitions. However I didn't look that hard.
- AnIdiotOnTheNet 8y ago
  Freedesktop standards are nothing if not overly complicated and confusing.
- wilmoore 8y ago
  I agree, you didn't look very hard.

PostThisTooFast 8y ago

XDG does indeed seem like shite, calling for such nonsense as this: "a default equal to $HOME/.local/share should be used." NO. Nobody should be creating HIDDEN directories and files. That's just a lazy, sneaky way of trying to hide turds from the user. Either you're storing legitimate config files that should be visible to the user but kept in a tidy location, or you're littering his storage with turds that should, likewise, be kept elsewhere. Apple's history of polluting every visited volume is a great example. Their excuse was storing file-browser state (for example, which directories were expanded) as invisible files all over the place, even on shared network drives. Of course, this design is a failure, because the next person to visit that volume will overwrite the turds. Not to mention the arrogance of polluting everyone ELSE's system, instead of just storing all this crap as URL/state on the local machine in one directory designated for that purpose.