4 ms·

The XDG config/data spec was made to manage systems that mount over NFS; ~/.local would stay on the local workstation, ~/.cache matters so little it could be on

by chungy 3y ago

The XDG config/data spec was made to manage systems that mount over NFS; ~/.local would stay on the local workstation, ~/.cache matters so little it could be on tmpfs, and ~/.config is the permanent romaing storage (and being config, could be on a slower server than the rest of $HOME). Quite a lot of programs don't ever care for these distinctions. "All in ~/.config" or "all in ~/.local/share" are both common and both wrong (programs that do this usually ignore that ~/.cache exists). Sometimes they're split over seemingly arbitrary and nonsensical reasons, and are inter-dependent enough that you have to really double check all three locations if you want to clear or modify a program's config outside of the program itself. All of this is just a nightmare and I much prefer the simpler ~/.program or ~/.programrc approach. It's findable, it fits perfectly fine in the non-NFS use case, and just stop running "ls -A" on every invocation. (Sadly, the Windows stuff really screws up running games through Wine, since it will default to connecting the Windows "Documents" to ~/Documents and ... ick. I disable this feature in Wine just to make it separate. They can muck up Wine's Windows folders as much as they want, it's invisible to me.)

thayne 3y ago
I find the split into three directories useful for different reasons. I keep .config in a VCS. I include .local/share in periodic backups. And I don't backup .cache at all. Programs that put everything in .config or .local/share mess that up.
exceptione 3y ago
$HOME is for my documents, don´t pollute it with 30+ .$program folders please. Can we as users have just at least one sanctuary place for our own docs that will not be messed with by stupid programs? The XDG spec is so simple, if a software developer still lacks the mental capacity to adhere to it he/she might be better of finding different hobbies. Come on now.
- chungy 3y ago
  I think it only appears "polluted" if you keep listing with "ls -A" all the time. If you don't list hidden files, you don't have a real problem. Besides, if you think that's polluted, then pushing it off to ~/.config and ~/.local/share is just sweeping it under the rug.
  - exceptione 3y ago
    .local and .config are 2 directories instead of 30. We make the problem managable. If you want to create a mess, you are free to do so with XDG variables. Read my other comments for that. Stop pissing in my $HOME and don´t tell me I should have no problem with that. Just adhere to XDG, $HOME is for me and I decide what I want there. You don´t.
    - sweettea 3y ago
      But XDG specifically decides what can go in my $HOME for me too -- .config etc. If I want .chromium, .0ad, etc. instead of .config, I'm SOL.
      - exceptione 3y ago
        No, XDG limits it to __2 known names__ in $HOME, versus __infinite unknown names__ in $HOME for non-XDG. If you want to shit around in $HOME, you can make symlinks from $HOME or set your XDG-vars to $HOME. In the non-XDG world we don´t have that control. Such software shits into $HOME, and it sticks there because it refuses to listen for user preferences (XDG-vars). As a user that deals with non-xdg software I don´t have control on the one directory that was meant for ME. -- The only improvement I can think of is that XDG would provide functions that software could call into instead of vars to get dir paths. That way, the user could have very fine control (even per application) when they write their own bash override.
      - kortex 3y ago
        The whole point is it's only deciding (3) things (config, data, cache), not (N_programs) things. > If I want .chromium, .0ad, etc. instead of .config, I'm SOL. Technically not SOL, you just need to set the launcher of whatever binary to set the XDG env vars to $HOME/.programname on launch. Or use links.
- tremon 3y ago
  So instead of 30+ .$program directories (not folders please), you get up to 120+ directories of the form .cache/$program, .config/$program, .local/share/$program and .local/state/$program ? I'm not convinced that one is unequivocally better than the other. For me personally, I prefer a flat namespace to having to hunt down directories in a tree of varying depth.
  - exceptione 3y ago
    > I'm not convinced that is any better. I manage $HOME, this is meant for valuable personal documents. I manage them manually. You as a software distributor better are not gonna clash with what I am doing there with your shitty engineering. If you insist on making a mess of your $HOME, XDG allows for that. You can set all your XDG variables to $HOME. And even without doing so, you can create symlinks to make your $HOME like you want. That is an unfair advantage you get with XDG adherence. XDG gives you as the user more control. If you don´t adhere to XDG, you take that control away from the user.
    - skywhopper 3y ago
      I have to disagree here. XDG is a poor spec. It makes assumptions about structure that may not hold. If I want all my config, cache, and local stores in per-program directories, XDG makes that impossible. If I want a specific program’s config directory somewhere other than the XDG setting, that’s not possible.
      - exceptione 3y ago
        You complain XDG makes assumptions while we are discussing software that makes the assumption that $USER has no say over $HOME. At least XDG is user configurable. XDG allows for a superior partitioning. If you don´t like it, you are likely to complain about Linux as well. XDG separates config, run state, cache and data, which is quite reasonable for a Linux system as that is what Linux does. --- > If I want a specific program’s config directory somewhere other than the XDG setting, that’s not possible. 1. $XDG_CONFIG_DIRS even allows for more multiple paths to be searched. 2. You could even override XDG-vars per application in a launch script or in the shortcut. > If I want all my config, cache, and local stores in per-program directories, XDG makes that impossible. You can set all the relevant $XDG_vars to $HOME and all your foo stuff ends up in $HOME/foo. Or symlink from $HOME. The XDG world gives you options, while the non-XDG world doesn´t. --- XDG could have opted for user overridable utils instead of variables. But you have already lots of options now.
- bmacho 3y ago
  > Can we as users have just at least one sanctuary place for our own docs that will not be messed with by stupid programs? What about $HOME/Documents? But yeah, I hear you, I gave up on $HOME as my personal space, I put my stuff in /data (I use my computer alone) and let any software pollute my $HOME.
- gilcot 3y ago
  My settings documents are also my documents, so I want my ${program}rc to be right there too. I don't install 30+ stupid programs so I don't feel polluted, that's so simple.
Anon_Forever 3y ago
>The XDG config/data spec was made to manage systems that mount over NFS Which makes sense in theory, but the execution is horrible. The ~/.cache directory is also on NFS now... You NEVER want cache on NFS. >~/.local would stay on the local workstation Never seen this in practice. This dir is also created on the NFS share, which it should be, since you need to bring these files to other machines as well. The standard is poorly thought out and poorly implemented.
- chungy 3y ago
  It's the rationale behind the XDG directories, nonetheless. The "ideal" setup is to have ~/.config on the remote NFS server, ~/.local on the local workstation, and ~/.cache on the local workstation (either disk or tmpfs). And yeah, poor implementation means that ~/.local not roaming around with you just makes things worse, despite the obvious name and intention. Developers almost never know when to properly implement it. XDG is just overcomplicated nonsense. The only part I like is ~/.cache. I don't buy for one bit the "clutter" argument about having some dotfiles (and no, setting $XDG_CONFIG_DIR=$HOME and $XDG_DATA_HOME=$HOME does not solve it; first, conflicts; second, files won't be prefixed with a dot).
  - Anon_Forever 3y ago
    Spot on chungy! I wish this was better thought out and implemented. There's a lot of room for improvement in this area.

by chungy 3y ago

thayne 3y ago

I find the split into three directories useful for different reasons. I keep .config in a VCS. I include .local/share in periodic backups. And I don't backup .cache at all. Programs that put everything in .config or .local/share mess that up.

exceptione 3y ago

$HOME is for my documents, don´t pollute it with 30+ .$program folders please. Can we as users have just at least one sanctuary place for our own docs that will not be messed with by stupid programs? The XDG spec is so simple, if a software developer still lacks the mental capacity to adhere to it he/she might be better of finding different hobbies. Come on now.

chungy 3y ago
I think it only appears "polluted" if you keep listing with "ls -A" all the time. If you don't list hidden files, you don't have a real problem. Besides, if you think that's polluted, then pushing it off to ~/.config and ~/.local/share is just sweeping it under the rug.
- exceptione 3y ago
  .local and .config are 2 directories instead of 30. We make the problem managable. If you want to create a mess, you are free to do so with XDG variables. Read my other comments for that. Stop pissing in my $HOME and don´t tell me I should have no problem with that. Just adhere to XDG, $HOME is for me and I decide what I want there. You don´t.
  - sweettea 3y ago
    But XDG specifically decides what can go in my $HOME for me too -- .config etc. If I want .chromium, .0ad, etc. instead of .config, I'm SOL.
    - exceptione 3y ago
      No, XDG limits it to __2 known names__ in $HOME, versus __infinite unknown names__ in $HOME for non-XDG. If you want to shit around in $HOME, you can make symlinks from $HOME or set your XDG-vars to $HOME. In the non-XDG world we don´t have that control. Such software shits into $HOME, and it sticks there because it refuses to listen for user preferences (XDG-vars). As a user that deals with non-xdg software I don´t have control on the one directory that was meant for ME. -- The only improvement I can think of is that XDG would provide functions that software could call into instead of vars to get dir paths. That way, the user could have very fine control (even per application) when they write their own bash override.
    - kortex 3y ago
      The whole point is it's only deciding (3) things (config, data, cache), not (N_programs) things. > If I want .chromium, .0ad, etc. instead of .config, I'm SOL. Technically not SOL, you just need to set the launcher of whatever binary to set the XDG env vars to $HOME/.programname on launch. Or use links.
tremon 3y ago
So instead of 30+ .$program directories (not folders please), you get up to 120+ directories of the form .cache/$program, .config/$program, .local/share/$program and .local/state/$program ? I'm not convinced that one is unequivocally better than the other. For me personally, I prefer a flat namespace to having to hunt down directories in a tree of varying depth.
- exceptione 3y ago
  > I'm not convinced that is any better. I manage $HOME, this is meant for valuable personal documents. I manage them manually. You as a software distributor better are not gonna clash with what I am doing there with your shitty engineering. If you insist on making a mess of your $HOME, XDG allows for that. You can set all your XDG variables to $HOME. And even without doing so, you can create symlinks to make your $HOME like you want. That is an unfair advantage you get with XDG adherence. XDG gives you as the user more control. If you don´t adhere to XDG, you take that control away from the user.
  - skywhopper 3y ago
    I have to disagree here. XDG is a poor spec. It makes assumptions about structure that may not hold. If I want all my config, cache, and local stores in per-program directories, XDG makes that impossible. If I want a specific program’s config directory somewhere other than the XDG setting, that’s not possible.
    - exceptione 3y ago
      You complain XDG makes assumptions while we are discussing software that makes the assumption that $USER has no say over $HOME. At least XDG is user configurable. XDG allows for a superior partitioning. If you don´t like it, you are likely to complain about Linux as well. XDG separates config, run state, cache and data, which is quite reasonable for a Linux system as that is what Linux does. --- > If I want a specific program’s config directory somewhere other than the XDG setting, that’s not possible. 1. $XDG_CONFIG_DIRS even allows for more multiple paths to be searched. 2. You could even override XDG-vars per application in a launch script or in the shortcut. > If I want all my config, cache, and local stores in per-program directories, XDG makes that impossible. You can set all the relevant $XDG_vars to $HOME and all your foo stuff ends up in $HOME/foo. Or symlink from $HOME. The XDG world gives you options, while the non-XDG world doesn´t. --- XDG could have opted for user overridable utils instead of variables. But you have already lots of options now.
bmacho 3y ago
> Can we as users have just at least one sanctuary place for our own docs that will not be messed with by stupid programs? What about $HOME/Documents? But yeah, I hear you, I gave up on $HOME as my personal space, I put my stuff in /data (I use my computer alone) and let any software pollute my $HOME.
gilcot 3y ago
My settings documents are also my documents, so I want my ${program}rc to be right there too. I don't install 30+ stupid programs so I don't feel polluted, that's so simple.

Anon_Forever 3y ago

>The XDG config/data spec was made to manage systems that mount over NFS Which makes sense in theory, but the execution is horrible. The ~/.cache directory is also on NFS now... You NEVER want cache on NFS. >~/.local would stay on the local workstation Never seen this in practice. This dir is also created on the NFS share, which it should be, since you need to bring these files to other machines as well. The standard is poorly thought out and poorly implemented.

chungy 3y ago
It's the rationale behind the XDG directories, nonetheless. The "ideal" setup is to have ~/.config on the remote NFS server, ~/.local on the local workstation, and ~/.cache on the local workstation (either disk or tmpfs). And yeah, poor implementation means that ~/.local not roaming around with you just makes things worse, despite the obvious name and intention. Developers almost never know when to properly implement it. XDG is just overcomplicated nonsense. The only part I like is ~/.cache. I don't buy for one bit the "clutter" argument about having some dotfiles (and no, setting $XDG_CONFIG_DIR=$HOME and $XDG_DATA_HOME=$HOME does not solve it; first, conflicts; second, files won't be prefixed with a dot).
- Anon_Forever 3y ago
  Spot on chungy! I wish this was better thought out and implemented. There's a lot of room for improvement in this area.