This has always been the case on Windows. In fact if anything, nowadays it’s better than its ever been because thanks to the UAC and other controls Microsoft have put in place, developers aren’t so free to do whatever they like to the host machine. But that’s remember a time before the UAC when it would often be common practice to reinstall the OS on a semi-regular basis (not something I personally engaged in but a great many of my peers used to).

> And it’s same on all known OSes

It really isn’t. On platforms with a proper package manager you can query what files get installed where. A great many package managers even let you query a file system file and see which package installed it.

Of course you still have the problem of the software writing files during its operation but that should be limited to $HOME (on POSIX systems) or any path that is writable by the owner / group of the user that application runs as (which should be limited even if it’s a system service).

Even the UAC aside, on Windows you now have the application data directory and permissions on the registry which both take some reliance off random files dumped anywhere. Before then Windows was like the wild west. And we're not talking that long ago in terms of the history of Windows - Vista was released 11 years ago and it took a few years after that for developers to catch up.

Plus with the trend of moving everything to the web, you're getting fewer native applications which can write those random files in seemingly random locations (that's one of the few good things about the move to web applications in my personal opinion).

You'll always have problems with developers having their own opinions - that's inescapable. But things used to be so much worse.

I think you need to support that statement. I believe the vast majority of software on common Unix distros creates no files in $HOME[1], and of those that do the majority use one folder in home[2], which *should+ be used for configuration, and often you don't want it automatically uninstalled on software removal.

The few I can think of that quote to multiple locations do so because the extra locations are shared folders. For example, I would not want my downloads directory removed on uninstallation of Firefox.

  1: E.g. Most things in /bin, and /usr/bin.

  2: other than what I outlined above, I can't think of any that use multiple directories. If it's truly a common as you say, you should be able to provide some examples.

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

Those proper package managers still rely on the packager doing things correctly - just as it would creating a windows .msi.

There's plenty of linux packages that creates files during operation in their designated /var/log/xxx /var/db/xxx /etc/xxx /home/xxx/ directories that you're not able to query using the package manager.

Those two paragraphs are talking about different OSs. 1st paragraph is talking about Windows, 2nd paragraph is talking about non-Windows systems with first-class package managers such as ArchLinux, Debian, CentOS, FreeBSD, etc.

> Those proper package managers still rely on the packager doing things correctly

Sure, but the point is you can query what the package manager has done.

> There's plenty of linux packages that creates files during operation in their designated /var/log/xxx /var/db/xxx /etc/xxx /home/xxx/ directories that you're not able to query using the package manager.

That's half true. You can query that /var/db/xxx and /var/log/xxx has been created by the package manager and often the directories (and their contents) will be owned by the user which the daemon runs under.

However I do agree with the point regarding your $HOME directory and actually made that point myself:

> Of course you still have the problem of the software writing files during its operation but that should be limited to $HOME (on POSIX systems) or any path that is writable by the owner / group of the user that application runs as (which should be limited even if it’s a system service).

As an aside, you can also query what files a particular application has open. In fact there are a few ways to do this from querying the /proc/$PID directory through to tools like `lsof`.

I'm not arguing that a decent package manager is a better than none - but they are solving all issues you claim they do.

Pretty much all OSs, including windows, have ways to view which processes has a file open

Got any examples of that? You'd expect only docker to write to /var/lib/docker, mysql to write to /var/lib/mysql. etc. Not discounted that I've overlooked something but a quick look in my /var/lib and it's easy to see what is managed by what. So I'm curious what instances you have of a package manager creating a directory and then a completely unrelated daemon writing to that directory.

> I'm not arguing that a decent package manager is a better than none - but they are solving all issues you claim they do.

I'm not claiming they solve all the problems - in fact I literally identified a few problems they don't solve! Plus even those points I identified aside, there will always be edge cases for thing that package manager should have solved but failed to do so.

Perhaps we should turn this discussion on it's head and discuss better ways to solve the problems people are describing? What would your solution be? Or are you ostensibly agreeing with my points but being contrary just for the sake of playing devils advocate?

> Pretty much all OSs, including windows, have ways to view which processes has a file open

Isn't that literally what I just said? (plus I gave a few examples too).

Not the person you were talking to, but looking at certbot, it puts files into /lib/systemd/system/ and /etc/cron.d/ with root:root.

I shouldn't expect too much in /lib/systemd/system is installed outside of package managers but I agree it does happen and at least they're generally quite easy to identify which service file does what.

crontab is definitely one of those nasty things that can often get forgotten about though (and I speak from unfortunate experience there hah!)

We're really drifting into the domain of Puppet and it's ilk now though.

dpkg -L helps a lot when figuring out where all the files get spread.

Well yeah, that was the central point of this conversation :)

Not to hot on linux management options I just install the thing over and over.

I actually always run that way most applications that do not fully adhere to the XDG base dir specification.

The really tricky problem is when a package must modify an existing shared resource. Such as appending lines to an existing config for example.

This is currently solved by having applications support both a config file and a config.d directory. The primary owner (package) of the resource modifies the conf file, while secondary packages drop their own config in conf.d/${package}. Numerous examples exist: logrotate, rsyslog, apache, nginx, systemd and apt come to mind.

Pacman creates a .pacnew file and lets you merge it yourself for this very reason.

Obviously this wouldn't be to everyone's tastes but it's good that market is catered in my opinion (but then I would say that as I'm very much a hands on person).

It's true that Linux package managers used to be buggy and problematic in the 90s but those days have long since gone. And while I'm not discounting that a package upgrade could damage your system, the instances when they do are highly unusual rather than a typical problem users face with each and every upgrade. In fact Windows sysadmins have far more dread with running Windows updates than Linux admins do and yet Windows updates are only focused on Microsoft products rather than every piece of software on the system.

> It's all up to packagers to author their packages right so they don't leave garbage on your machine that you have to manually clean up (or give up and reformat).

Actually it's not. It's up to the application developers to do that. If you specify a package to install a file `x` to location `y` then the package manager will uninstall that file automatically too. You don't specifically need to tell the package manager to do that (or at least not with any of the packaging systems I've used). But if the application developer writes the application to spew out thousands of files into $HOME, that happens outside of the package manager. There isn't a whole lot you can do to stop that aside limit the directories which your application has permission to write to (either via chroot, containerisation, user/group permissions, SELinux, or other forms of ACL. There's actually plenty of tools on Linux / UNIX to handle that problem).

ps: coincidentally, I was just starting to use linux firejail on a daily basis.. very very useful.

File writes for application files are rarely the problem any more.

The problem is that in order to function correctly (For some definition of correct, but say e.g. to associate file extensions, create shortcuts, start automatically, install a dependency such as a C++ runtime patch, whatever) the program needs to write to subsystems of the OS in a non-reversible way. It's also very HARD to do these things (create setups) because systems like Windows Installer aren't trivial to use. Every time a setup author makes a mistake there is a risk of stuff being left behind.

Fundamentally, what you are doing is you are in state A when installing the program, creating state B. Then you continue to modify the system simply by using it or installing some more software creating state C. If you now uninstall the first software you don't have anything but a script undoing A->B, which run backwards can only do B->A, but you are in state C and you don't want to first run C->B because you want to keep the other parts of state C. So the uninstall script has to run in unknown territory (a file may have changed, a later dependency version may have been installed globally, a registry entry may not exist because they are NOT isolated per application etc) so the uninstall script just has to do what it can.

A sandbox could be a solution to this, where the sandbox contains diff views over some immutable base image. It probably is a lot easier to do (and do efficiently) with OS support.

But I was talking about all files that app creates. Like files in home dir (eg. ~/Library). If you remove the app, those files stay there and occupy space.

The only way you can partly clean up the mess, is to delete home dir from time to time (but backup important files first). Even then, there might still be files in /usr/local etc.

For example, the other day I moved Word to the trash, 5 seconds later I get the AppCleaner pop up letting me know it found an additional 2GB of shit that Word just littered around my machine that wouldn’t have gotten removed by just deleting the app. And unfortunately, that definitely hasn’t even been the worst offender I’ve run into, and at this point I’m very rarely not surprised by the amount of leftover crap that doesn’t get removed when deleting an app.

Unless I am mistaken, I don't think this is the case for iOS, Android, ChromeOS, FirefoxOS, and many game consoles.

This is really just a problem with desktop and server operating systems, not with operating systems as a whole. It's also getting bettwe with package managers, the Windows Store, and UAC.

At least on Windows I have my pick of thousands of Portable Apps (and most Windows software can act as a portable app if you just extract it without installing it anyway, albeit still leaving junk in the registry). You know what's a great feeling? Being able to reinstall your OS and just pointing a new toolbar at wherever you keep your portable apps and being good to go.

If I download an app, I’m anticipating a .dmg to mount, which holds a self-contained .app which runs anywhere, and a link to /Applications, to suggest a sensible place to put it.

It’s not enforced, but it is the norm.

I guess you're missing one. Android allows you to remove everything that app created.