4 ms·

This is particularly weird, since click (snap's "predecessor" at Canonical/Ubuntu) was fully XDG compliant, even encouraging developers to separate data from ca

This is particularly weird, since click (snap's "predecessor" at Canonical/Ubuntu) was fully XDG compliant, even encouraging developers to separate data from cache etc. (unlike flatpak which just dumps everything in ~/.local/share/[...], though that is still infinitely better than using ~/snap).

rjzzleep 8y ago
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.
afiori 8y ago
> unlike flatpak which just dumps everything in ~/.local/share/[...] Here you are referring to separating the config and data? Is this actually a problem? I can see how for things like games it would be valuable to have a special location for thing like saves games, like how you can move the roaming save for minecraft from a computer to another; but I never understood the net gain from splitting the application files in config/data
- JetSpiegel 8y ago
  Config is the personal, but public data. "Data" is personal private data.
- wilmoore 8y ago
  Curated configuration generally outlives data. If storage space becomes an issue, there is value in recovering storage space but config is generally small and much more important in the long term.
h1d 8y ago
I just use 'exa' with --ignore-glob option to filter out unnecessary folders as 'ls' replacement and things are clean. It also has an option to ignore entries listed in your .gitignore.
- wilmoore 8y ago
  So, invest in yet another program that likely further exacerbates the issue just to sweep the underlying issue under the rug?

rjzzleep 8y ago

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.

afiori 8y ago

> unlike flatpak which just dumps everything in ~/.local/share/[...] Here you are referring to separating the config and data? Is this actually a problem? I can see how for things like games it would be valuable to have a special location for thing like saves games, like how you can move the roaming save for minecraft from a computer to another; but I never understood the net gain from splitting the application files in config/data

JetSpiegel 8y ago
Config is the personal, but public data. "Data" is personal private data.
wilmoore 8y ago
Curated configuration generally outlives data. If storage space becomes an issue, there is value in recovering storage space but config is generally small and much more important in the long term.

h1d 8y ago

I just use 'exa' with --ignore-glob option to filter out unnecessary folders as 'ls' replacement and things are clean. It also has an option to ignore entries listed in your .gitignore.

wilmoore 8y ago
So, invest in yet another program that likely further exacerbates the issue just to sweep the underlying issue under the rug?