What is the advantage of UNIX-like filesystem hierarchy standard? Why is it my fate to go through millions of config files (or things created after the installation that are not tracked by the package manager) in /etc?
I kinda understand why people chose this way, but I don't think the people came up with it estimated the growth in complexity of third party applications.
What I would really love is having a base system set up in this fashion and additional stuff contained within themselves, and symlinked for compatibility. So that when I use my package manager, I can just check the base directory for invalid symlinks and it would be just fine.
>>55860181
It exists and is called Gobo Linux. find, grep, and man basically make it not worth the time.
>>55860203
Oh, didn't know that. It looks cool.
My issue is not really finding them, it's more about not being able to completely and confidently removing programs. Bits and pieces left everywhere that are not tracked by package manager which may also be named weirdly so you may not be able to find them using logic.
But I thought I was the only one got fed up with this. Apparently there are others and now my thread seems a bit pointless.
>>55860273
Problem is with the package not having certain files being tracked. In any case, I've had the same problems in Windows, with uninstallers leaving shit around. Visual Studio's uninstaller is complete crap.
>>55860315
But if all the related files are collected in one directory and only symlinked, you can just look at the directory and find out what remains in theory.
Gobo is half-assed, and not the right half of the ass.
Read up on NixOS. Every package is built in isolation in its own content-addressed write-once location in the store. Symlink trees that serve as profiles are also built as packages in this store. Lots of interesting properties: install and upgrade are atomic, repeatable, portable, downgrade is guaranteed to work, nonadmin package install is a possibility, etc.