1. 39
  1.  

  2. 13

    To those of you reading this: I beg you. Avoid creating files or directories of any kind in your user’s $HOME directory in order to store your configuration or data. This practice is bizarre at best and it is time to end it. I am sorry to say that many (if not most) programs are guilty of doing this while there are significantly better places that can be used for storing per-user program data.

    I would love if one day something like $HOME/config (instead of the hidden directory .config) becomes a standard in Linux/*BSD. I think (totally personal opinion here) making everything non-hidden inside a non-hidden directory config would be less rude than whatever place configuration files are put as hidden files. At least I wouldn’t have to worry “is there a hidden configuration here?”, I would know they are all visible in $HOME/config.

    That said, “dotfiles madness” is bad, I agree, but I still prefer it over the gsettings/dconf that tries to do everything and saves it somewhere out of my sight (feels like a regedit wannabe).

    1. 9

      I would love if one day something like $HOME/config (instead of the hidden directory .config) becomes a standard in Linux/*BSD.

      Why wait? You can do this today by setting XDG_CONFIG_HOME to ~/config and be done.

      1. 6

        But then there are the applications which just pretend to support that variable, and instead hardcode ~/.config

        1. 13

          Then submit a patch. It will be vastly easier to fix those applications than applications from developers who don’t support XDG in the first place.

      2. 4

        I appreciate the standardization that gsettings/dconf bring; and I do prefer it to crappy dotfiles. I wrote a few wrapper scripts around gsettings to do backup/restore of settings in my Dotfiles repo. They persist in a standard ini format which is easy to manipulate, too.

        1. 3

          GSettings also has great support for live reloading (not having to restart apps to apply settings) and it makes settings very discoverable thanks to schemas (unlike the Windows registry — you open dconf-editor and you can see descriptions for all the things! and there are more types than bool/number/string).

          1. 1

            Do you have a link to that script? I’d like to use it; IIRC I looked into doing to the same thing years ago but couldn’t make it work.

        2. 8

          The arch linux wiki has a nice page documenting how to fix various software: https://wiki.archlinux.org/index.php/XDG_Base_Directory

          1. 10

            Ugh, scattering crap across .local and .cache and .hootenanny is possibly worse. Now I have to go digging around in several places to find what’s wrong.

            1. 17

              I’m actually kind of a fan of .cache because in theory I can delete the entire thing at any time, and avoid backing it up.

              1. 5

                oh, you mean like /bin, /usr/bin, /usr/local/bin and /opt/… ?

                1. 5

                  I’ve had fewer problems with binaries corrupting themselves.

              2. 6

                So… am I the only person who’s never been bothered by this? Those files are hidden by default in most tools, they’re easy to find, paths stay reasonably short. But every time it comes up, I only see people complaining bitterly about all these dotfiles (that they have to explicitly choose to look at).

                1. 4

                  So… am I the only person who’s never been bothered by this?

                  No. I mean, I grant I found it slightly annoying at first, but once I realized there was no real practical way to avoid it, I stopped worrying about it. I’m pretty sure this is a case of a very very loud vocal minority. It’s so easy to bitch about, but what’s the point in commenting to say, “doesn’t bother me,” especially when it makes you an easy target for said vocal minority to redirect their zeal towards you. Thus, you hear the complaints but will very rarely hear from folks that don’t care.

                  Of course, this is just speculation. There’s no real way to know.

                2. 5

                  The situation is just as bad on macOS and Windows. The documents folder on my Windows machine is littered with inane directories like “My Assassin’s Creed Odyssey Save Games.” The same lack of respect for the user also shows up on Mac, with apps avoiding the Library directory and cluttering up the home directory instead.

                  1. 3

                    At this point, it feels like there is no will to fix this in numerous projects. I almost wonder if a kernel solution is needed to put an end to it once and for all. I was wondering if something like map of file/globs to some other location, that would be encoded and stored as an xattr on a user’s home folder, makes sense.

                    1. 8

                      I solved this problem for me by making my $HOME read-only.

                      I documented my solution a while ago: https://soc.github.io/standards/defending-home

                      Additionally, I wrote libraries for Rust and Java, which do everything correctly out of the box on Linux, Redox, Windows and macOS: directories (Rust), dirs (Rust) and directories-jvm (Java)

                      You can use them, and have the guarantee that your application follows the operating system conventions everywhere; no ifs, no buts.

                      1. 6

                        FWIW, there appear to be a lot of programs which have added support over the years.

                      2. 3

                        I’d love to see an opinionated package manager or package manager overlay that targets this issue: all packages would either comply with the XDG standard, or have a patch set adding compliance. Dotfile purists could rally around the package set and concentrate their work even for unreceptive upstreams. Then, as the package set gained momentum, it would be easier to advocate for merging the patches into reluctant upstream projects, because the patchset would already be implemented and tested by the community.

                        1. 5

                          Enforcing this on the package manager level has not worked out well in the past. For example Debian enforces that packages (mostly) should use shared libraries, and patching every program to do that has just been a massive sinkhole for developer time when trying to figure out Debian-specific issues, and also for package managers’ time who need to keep the patches for that up-to-date.

                          If dotfile purists make a linux distro just for dotfile purists, nobody will care. If this rule makes it into a larger distro, application devs will just be annoyed, if they aren’t already. It’s unlikely you’ll make them cooperate when they have nothing to gain from it; The Linux package repo is not a for-profit app store, there is no incentive to play by the store owner’s rules.

                          1. 3

                            Then, as the package set gained momentum, it would be easier to advocate for merging the patches into reluctant upstream projects, because the patchset would already be implemented and tested by the community.

                            I would love this, but I think it’s unrealistic. Have a look at which packages ignore XDG, and you’ll see that it’s pointless from the start. Be prepared to maintain your patches against upstream forever.