One thing I like about Linux package managers is that you can query any file to see which package owns it. How does Windows not track this?
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-...
And there is no written or unwritten rule about that. In fact, /home is a subdirectory of / which is owned by root.
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.
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?
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.
Maybe the reason no one does that is simply that no one shares your preference.
- 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
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
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.