3 ms·

The problem with the XDG spec is that it now forces you to have different paths on different platforms. It just increases the complexity and at the end of the d

The problem with the XDG spec is that it now forces you to have different paths on different platforms. It just increases the complexity and at the end of the day unless all software adheres to it, you still end up with a “polluted HOME”. I’m not a fan of config directories being in different locations on different platforms because it’s now one extra thing everyone needs to handle. (Disclaimer: I work on Pi but I dislike XDG in all settings)

dust42 2mo ago
As a user I still prefer .pi right there in my home directory.
oblio 2mo ago
Platform standards already require things to be in different locations compared to *NIX dotfiles and dotdirectories - for example Windows %APPDATA%. I find it a bit shocking that someone working on an agent harness can't be bothered to spend 5 minutes to research this with the help of an LLM and holds such rigid and uninformed views. And if you don't want to respect platform standards, just respect XDG on all platforms. The .app solution is the laziest one possible. Just follow XDG everywhere and create .config/app & co everywhere, at least that way there's a chance more apps end up in subfolders instead of ending up with a million folders in the user directory on BOTH Linux and non-Linux.
- gwerbin 2mo ago
  I suspect some people are out there who actually like the single directory style. Obviously it's easier for the software developer, but I suspect some users like it too because everything's all in one place. It's very likely that Mario is one of those people.
  - nasduia 2mo ago
    it's certainly easier to keep a single directory under version control and share between Linux and macOS
    - oblio 2mo ago
      As in, $HOME? Version controlling it needs to be done very carefully.
    - gwerbin 2mo ago
      Yeah but what happens when it's a mix of config and local state like logs and the app database?
      - Defletter 2mo ago
        Looking around my own cluttered home folder, the pattern seems to be that applications will split their "singlefolder" into a subtree. For example: - .sdkman has: bin, candidates, contrib, etc, ext, libexec, src, tmp, var - .gitkraken has: logs, notif, profiles, repohooks, service, themes - .mullvad-browser has: Downloads, .cache, .config, .local, .mullvad - .dropbox has: events, instance1, instance_db, logs, machine_storage, metrics, ssa_events - .steam has: bin, bin32, bin64, debian-installation, root, sdk32, sdk64, steam - .xpipe has: cache, logs, settings, shell, storage, webview ...etc I will say that even though I really don't like having a cluttered home folder, I do appreciate things being more or less in one place and so can be easily uninstalled and cleaned up. Flatsweep even being a thing is a testament to the tedium created by dispersing everything across the file system. It reminds me of macOS and not in a good way: I had an equivalent to Flatsweep on my old macbook but I couldn't remember its name so I searched "macos app cleanup tool", and the first page is just a bunch of comparison articles for the 10 (or whatever) best cleanup tools. This shouldn't be a thing. Alas, it is because applications can't or wont clean up after themselves.
        gwerbin 2mo ago
        Totally valid, and the Unix-style filesystem sprawl is definitely a pain sometimes. On the other hand, when an application does follow standards, you always know where something is, and just by looking at the name of the directory you know what's in there. The other thing that's nice about the XDG standard is that it generally encourages developers to split binary state data, configuration, etc. even if you do it all within one folder, that's better (for the user) than jumbling it altogether in one big SQLite database or whatever. It is a note that a lot of applications and even package managers are kind of moving back to the model you describe. For example Homebrew installs each package into its own prefix and symlinks into /opt/homebrew/bin,lib,etc... I still don't like hard coding the MYAPP_HOME dir in ~/.myapp and prefer an environment variable to configure it. Personally I put all such folders into ~/.local/opt/$MYAPP if possible.

dust42 2mo ago

As a user I still prefer .pi right there in my home directory.

oblio 2mo ago

Platform standards already require things to be in different locations compared to *NIX dotfiles and dotdirectories - for example Windows %APPDATA%. I find it a bit shocking that someone working on an agent harness can't be bothered to spend 5 minutes to research this with the help of an LLM and holds such rigid and uninformed views. And if you don't want to respect platform standards, just respect XDG on all platforms. The .app solution is the laziest one possible. Just follow XDG everywhere and create .config/app & co everywhere, at least that way there's a chance more apps end up in subfolders instead of ending up with a million folders in the user directory on BOTH Linux and non-Linux.

gwerbin 2mo ago
I suspect some people are out there who actually like the single directory style. Obviously it's easier for the software developer, but I suspect some users like it too because everything's all in one place. It's very likely that Mario is one of those people.
- nasduia 2mo ago
  it's certainly easier to keep a single directory under version control and share between Linux and macOS
  - oblio 2mo ago
    As in, $HOME? Version controlling it needs to be done very carefully.
  - gwerbin 2mo ago
    Yeah but what happens when it's a mix of config and local state like logs and the app database?
    - Defletter 2mo ago
      Looking around my own cluttered home folder, the pattern seems to be that applications will split their "singlefolder" into a subtree. For example: - .sdkman has: bin, candidates, contrib, etc, ext, libexec, src, tmp, var - .gitkraken has: logs, notif, profiles, repohooks, service, themes - .mullvad-browser has: Downloads, .cache, .config, .local, .mullvad - .dropbox has: events, instance1, instance_db, logs, machine_storage, metrics, ssa_events - .steam has: bin, bin32, bin64, debian-installation, root, sdk32, sdk64, steam - .xpipe has: cache, logs, settings, shell, storage, webview ...etc I will say that even though I really don't like having a cluttered home folder, I do appreciate things being more or less in one place and so can be easily uninstalled and cleaned up. Flatsweep even being a thing is a testament to the tedium created by dispersing everything across the file system. It reminds me of macOS and not in a good way: I had an equivalent to Flatsweep on my old macbook but I couldn't remember its name so I searched "macos app cleanup tool", and the first page is just a bunch of comparison articles for the 10 (or whatever) best cleanup tools. This shouldn't be a thing. Alas, it is because applications can't or wont clean up after themselves.
      - gwerbin 2mo ago
        Totally valid, and the Unix-style filesystem sprawl is definitely a pain sometimes. On the other hand, when an application does follow standards, you always know where something is, and just by looking at the name of the directory you know what's in there. The other thing that's nice about the XDG standard is that it generally encourages developers to split binary state data, configuration, etc. even if you do it all within one folder, that's better (for the user) than jumbling it altogether in one big SQLite database or whatever. It is a note that a lot of applications and even package managers are kind of moving back to the model you describe. For example Homebrew installs each package into its own prefix and symlinks into /opt/homebrew/bin,lib,etc... I still don't like hard coding the MYAPP_HOME dir in ~/.myapp and prefer an environment variable to configure it. Personally I put all such folders into ~/.local/opt/$MYAPP if possible.