Ok, I see what you're saying here, still, Linux's way is better, I'd rather have my system cluttered with useless files of deleted programs than be exploited because of something that was solved decades ago.

Except they all leave files everywhere in ~, ~/.cache, ~/.config, ~/.whatevertheyfeellike

The ~/.whatevertheyfeellike is an antipattern (that is annoying) but the others are well defined in the xdg_desktop spec[0].

Personally I appreciate knowing where the config/cache for each application is. (Though it does annoy me when programs don't follow this as in your third example)

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

Why does the XDG spec have authority over software?

Software specifications are usually adopted by convention and implemented to minimize surprise and make things interoperable. They are not authorities and cannot make anyone do anything. One of the most common software failure modes is to implement a specification too tightly or in a way that nobody wants although the reverse is a problem as well.

It usually doesn't, and it's mostly a good standards recommendation that even the most GPL of GPL codebases doesn't always follow (looking at you, emacs).

Emacs has respected $XDG_CONFIG_HOME for a while now. There are worse offenders (e.g. not likely to see the end of .mozilla any time soon).

GNU emacs was created at 1984. XDG Base Directory spec was started around 2003..

Also Emacs will reapect files being placed in XDG directories, it just doesn't put them there...

They don't. XDG specifications are recommendations. Their only power is that your software will integrate poorly with other software (specially desktop software) if you ignore their guidelines.

Those files are user data, not part of the software package.

I would disagree, files that the user cannot edit or should not edit should not be going into their home directory. Things like cache files should go into a system wide cache directory instead.

Cache files might contain user's sensitive data. Makes sense to keep in them in the user's home directory in those cases.

File permissions?

Isn't that very anti-linux though, to have a directory owned by root but populated with subfolders owned by other users? /home is the only exception I can think of that does this.

Anti-linux I don't know, but it was not uncommon in unices to have home directories in /usr/home.

And there is no written or unwritten rule about that. In fact, /home is a subdirectory of / which is owned by root.

True, but /usr/home is no longer a common place to store home directories. It used to be, particularly in Bell Labs Unix. (Does FreeBSD still do this?)

The Linux Foundation’s File Hierarchy Standard puts user homes in /home, but it’s by no means mandatory.

/home being the *nix home folder directory isn’t written in stone, but plenty of software expects it. Of course you shouldn’t hard code things like that, but that has never stopped anyone from doing it. (Not that we should reward that with de facto standards necessarily.)

I understand the various reasons why a root file system hierarchy isn’t part of the Single UNIX Specification, but it might have been nice.

/tmp

And /run/user

also mail and cron

There's no other path that the user is guaranteed to have write permissions to (except maybe /tmp, I guess).

Why would you want that?

If you have separate partitions, would you really want user data to go to the system partition? Or a third partition?

Do you find having more places that user programs can write a benefit?

I would favor a /var/user/something directory.

The fact that nobody does that is pretty much a consequence of the difficulty of coordinating multiple projects that do not have a common authority, not because it is a bad idea.

Again, what do you prefer about that?

Maybe the reason no one does that is simply that no one shares your preference.

Having a clear separation between actual user data files / documents and stuff like cache for different reasons:

- easier to cleanup/wipe without risking deleting works/personnal files

- backup solution doesn't have to have a town of entries in an ignore/exclude file

- same as above for syncing software

- tier storage separation possibility

- disk space allocation separation depending on data vs volatile stuff

Should that count towards user disk quota?

I agree cache file should not go into their home directory, however I don't agree they aren't user data and that they would be part of the software installation.

If I uninstall ssh I still want to have have my authorized hosts. If I uninstall some firefox version firefox I want to keep my profiles. XDG defines a thumbnailing hierarchy followed by multiple libraries, uninstalling any of those shouldn't clear thumbnail caches.

Persistent user-specific state needs to live in a persistent user-specific location. You could choose not to use the concept of a home directory, but you would be doomed to reinvent it.

That's a feature so that users can keep configuration files and even move them across systems.

That is not part of the software itself so it is still correctly installed/uninstalled.

Now I believe all software should have a manpage, dialog and a cli argument that describes where all the files[1] generated by default go but that is another subject.

[1] cache, config and even default save

Try opening C:\Users\%USERNAME%\Documents\My Games

MSIX packaged apps do support this, Windows redirects file writes outside of home dirs and other user locations to a package-specific directory that's overlayed back onto the system so the app thinks it's writing to wherever, but it's actually a package-private location.

> you can query any file to see which package owns it

Presumably you mean something like using dpkg/apt for a Debian-style system?

I think that only works if a file is actually installed from within the framework. As soon as you've installed a file via npm, flatpak, pip, snap, specialist plug-in, standalone binary, that ancient program you had to install by hand, or one of the other squillions of ways of getting an executable program, you're out of luck and have to figure it out manually.