Look at ~/.wine for example... config files, whole C drive, everything in one simple folder. Want to upgrade to an alpha version to test something, but don't want to break anything that's now working? Just backup that one single folder. Restore or migrate configuration to another computer? One single folder. Remove any trace of that app? Again, one simple folder.

Want to do the same with google chrome? .config/google-chrome... oh wait, what if there's something in .local too? Still doesn't work? Oh wait, you forgot the .cache directory, and have been loading an old version of something.

Except it isn't really. Just a few days ago I tried to purge Wine from my system. Uninstalled through pacman, cleaned up orphaned dependencies. Killed the ./wine folder and various other leftovers too, because depite your claim, there they were, though I didn't commit to memory exactly where and what. Removed some autostart shortcuts, cleared a few icons from desktop, and manually edited the Plasma menu to remove some stubborn links.

And yet ... I still get suggestions to open my jpg's and png's with something called Wine Internet Explorer. Which i don't really believe is distro specific, since I've seen the same thing happen in both Debian and RedHat derivatives.

https://wiki.winehq.org/FAQ#How_do_I_clean_the_Open_With_Lis...

If you ever want to prevent this integration from happening in the first place, you can do it by editing the registry in a given wine prefix. You can run regedit with the usual command, `wine regedit`, then locate the key:

HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices\winemenubuilder

Set it to empty to disable the integration entirely. Or, just remove the `-a` switch and you will still get desktop icons, just not file associations.

It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it, since those various files need to be in their respective locations to reasonably be picked up. (Maybe it could use symlinks instead, but even if it did, they'd need to get cleaned up by something when the target gets deleted.)

There is a way around unwanted and unexpected associations though: make the integration opt-in instead of opt-out and/or filter associations that the user is unlikely to ever want (like standard file types that will almost certainly already be handled outside Wine). Wine's Internet Explorer is there for compatibilty with Windows programs that expect IE, exposing it outside the Wine environment does not make any sense.

Since I use multiple prefixes, including temporary ones, editing registry in each one of them is not an option so I have my package manager set not to install winemenubuilder at all.

I kind of agree with you that the defaults are not great, or at least if things haven't changed. We could always see if maybe they'll accept patches to filter out more stuff by default.

Like with privacy issues, once you realize you want to opt out the mess has already been made.

Backups are the main reason why I want programs to follow the XDG Base Directory Specification. I don't want my backups to includes gigabytes of files that should be in ~/.cache, which is a directory I never back up. The shell script that I wrote to back up my PC includes dozens of rsync exclusions for files in ~/.mozilla, etc. that should be in ~/.cache.

You mean, this is why that kind of software should use a .programX directory. Evidently many don't. And of you think about doing it, just move it into .config for good measure...

Crap like wget just keeps shoving files directly into my home instead. When they added hsts support they had the chance to finally create a directory, ideally in .config, so if they need to add even more files in the future they wouldn't have to clutter $HOME even more. But no, that would be too forward-thinking. Just put the hsts file in home and be done.

    vault
    flyctl
    yarn
    npm
    vscode
    terraform
    rustup
    kubernetes
    fzf
    eclipse
    docker
    cargo
    aws (cli)

[0] - https://specifications.freedesktop.org/basedir-spec/basedir-...

If i want to completely remove wine from my profile, how many folders do I have to delete doing it the old way? One - ~/.wine. How many using the new? One in .config, then .local/share, probably one in .cache... oh wait, .local/state too.. Probably.. well, maybe, I'd have to check manually. Same for other software. One folder to remove, one folder to backup, one folder to restore.

The biggest problem is programs that don't even let you change where they store the stuff, so even if you're okay with the default not being XDG you dont even have the option to make it respect XDG base directory specification.

[0] https://www.gnu.org/software/stow/

> most all of the Linux software dumping dotfiles in my homedir

then is it really true, that the standard is in fact "well established"?

.w3m - w3m cli browser

These are the ones I couldn't change the behavior of, in my dotfiles I've managed to fix at least a dozen of programs that were previously misbehaving but offered environment variables to change their behaviors.

The thing that bothers me most about these is that most of these folders are simply cache and logs, I can always delete them and the application will keep working, but of course the folders will be recreated. It's truly mind-numbing.

  # Save shell wrapper as '~/.local/bin/firefox'

  { while kill -0 $$ 2> /dev/null; do rm -rf $HOME/.mozilla; done; } &
  /bin/firefox --profile $XDG_DATA_HOME/firefox $@

  # set env variable
  export NPM_CONFIG_USERCONFIG=$XDG_CONFIG_HOME/npm/npmrc

  # and in npmrc:
  prefix=${XDG_DATA_HOME}/npm
  cache=${XDG_CACHE_HOME}/npm
  tmp=${XDG_RUNTIME_DIR}/npm
  init-module=${XDG_CONFIG_HOME}/npm/config/npm-init.js

  Steam actually creates only symlinks for backward
  compatibility as some games (may) expect them in $HOME.
  You can safely launch it with modified HOME variable:
    $ HOME="$XDG_DATA_HOME/Steam" steam
  (and/or put it into a wrapper script like with Firefox)

  I don't know how it's with SpaceVim,
  but with regular vimrc you can make it follow the spec:
    https://blog.joren.ga/vim-xdg

  export W3M_DIR="$XDG_DATA_HOME/w3m"

There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.

There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME.

Neither of those environment variables is defined on a stock Ubuntu 22.04.1 LTS.

$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.

https://specifications.freedesktop.org/basedir-spec/basedir-...

[0] of course one shouldn't assume that a totalitarian decision is a mistake, because it's just as likely that the decision-maker has priorities other than "support users"

[1] yes of course users have agency with respect to where XDG is implemented, but the simpler rule would also have given them agency with respect to whether it is implemented

But take a step further back: why should anyone care about what the XDG says in first place? This isn't a dictatorship, and things were doing just fine long before a handful of people who wrote the XDG thought their ideas were the best approach.

It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy. The fact that the XDG file layout still isn't universally used suggests it doesn't have as much value as its proponents think.

Because their users are asking them to not pollute the home directory? This isn't bikeshedding config locations without reason, there is a clear motivation for letting users a) specify where data should go and b) separate different types of data.

> It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy.

The XDG basedir spec has been adopted broadly amongs many organizations and individual devlopers including all major desktop environments. It is not adopted universally yet, but few things are.

This isn't a standard, it's a convention at best. A freedesktop.org specification. Basically a scheme Red Hat people thought up and implemented widely in the open source software projects they control. It may be a useful abstraction but there's absolutely no obligation to conform to it. There doesn't have to be an "excuse" or any form of justification at all. "I just don't like it" is enough. I don't like those unsightly XDG variables either and it's entirely within my power as a software developer to trash the entire concept of XDG and do things in any way I see fit.

https://www.freedesktop.org/wiki/Specifications/

> freedesktop.org produces specifications for interoperability, but we are not an official standards body.

> There is no requirement for projects to implement all of these specifications, nor certification.

But those are all generally poor ways to write software, and a great way to get your users to complain. So it is with ignoring XDG.

So is, like, basically all of userland in a UNIX system. Maybe we need to start looking at that as a problem instead of an excuse.

It is within your power as a developer to delete the user's home directory if you want to as well, that doesn't mean you should do it!

My sympathy is lacking, as is my respect for those running projects that hardcode paths. Stop hardcoding paths and the world will be a better place.

This also had the side effect of hiding entries that had names beginning with ".", and over time an implementation bug/quirk became accepted behaviour, and was post-hoc rationalised as "hidden" files.

But when people are talking about compliance, and hardcoding very few people are talking about those applications - there are hundreds of other applications do the wrong thing, and some scripts hardcode things as a result.

If you get to the point where you need another file for something, put it in a directory under .config so whenever you need to add even more, you don't keep cluttering my home.

OTOH if you want to completely remove your cache, or completely backup your config...

Do people seriously resist such non-destructive improvements just because they think it's offensive when younger programmers have opinions on legacy software?

/hides

I realize that you wrote "new kids" in quotes, but these "new kids" might have grandchildren at this point given that the initial draft of the XDG Base Directory Specification was published in 2002.

https://web.archive.org/web/20180827160401/https://plus.goog...

Obviously, we are now stuck with dotfiles as a "feature", but that doesn't mean we need to have more of them than necessary. Cluttering the home folder with a disorganized mess of files with different modalities next to eachother is ridiculous, pointless, and a collective waste of time.

Almost all of the apps people are complaining about not following XDG were created long after the XDG base directory specification existed. It's time to move on.

P.S.: it'd be preferable also if it wasn't simply implied that everyone who's been around Linux/UNIX for a couple decades hates change. Churn for the sake of churn is bad, but churn is not all wasted. Standardizing once-disorganized directory hierarchy is certainly not a waste of time.

Having a couple of directories to clean up is a bit annoying, but they used to stick the config file in your home and then make an application directory so we were already having to deal with multiple locations.

The software can look at $XDG_WHATEVER/tool/config first and ~/.toolrc second. Everyone who wants the clutter can keep using that.