Core problem is there has never been a standard database of which files belong to a package in Windows and macOS.
Most Linux distributions at least keeps package assets tracked (easy enough, given that packages aren't much more than a tarball that's extracted to / and a few scripts, and installation paths being relatively standardized). User configuration data is another issue entirely (edit: as are self-built programs, you need to keep the original build folder around and hope that the authors have made `make uninstall` actually work).
In contrast, Apple only follows the convention that a package's assets should be in /Applications/AppName.app... but apps are completely free to ignore that and install to anywhere not being protected by SIP, or to install LaunchAgents and whatnot without having to document that anywhere. That in turn means it's impossible to fully uninstall an Apple program that uses any of these features, and in addition macOS shares the same issue as Linux regarding user configuration data.
And Windows is the worst of the mess. It's essentially a free-for-all outside the Microsoft store, MSI (aka MS's attempt to copy Linux packages) is decent but tedious to package so you'll usually only find it used in enterprise software which needs to be packaged in a way suitable for deployment via GPOs, and on top of file cluttering Windows adds the Registry to the mess. Oh, and the bloatware of anything not installed from a Microsoft install medium.
yeah, this is the root of the problem. a lot of programs put files wherever they want. ugly and really cluttered. i like traditional linux (and friends) way to install and uninstall program. there's a ultimate source of truth what files belong to which program.
> In contrast, Apple only follows the convention that a package's assets should be in /Applications/AppName.app... but apps are completely free to ignore that and install to anywhere
If you can't install a normal Mac app via drag and drop, I'm not installing it. It's a great signal that you're dealing with an inexperienced Mac developer.
I absolutely refused to install Chrome for Mac, for instance, until they rewrote it to install via normal drag and drop after their custom installer/update workflow rendered computers unbootable.
> A wave of reported Macs being no longer able to boot was caused by a recent Google Chrome update that was corrupting a necessary operating system folder. Once the update was installed, affected users found they were no longer able to boot into macOS.
I wish that linux installs were more self contained though. Directly dumping everything into a global folder is a bit messy and you can only ever have one version of a shared library installed unless each version is uniquely named (a problem which Windows 3.1 also had).
I wish that packages got their own folders as standard, contained all the required libraries and had unique "internal" names like java packages to avoid conflicts. Very much like what Android and Nix do.
It's a bit of a pain for the package makers and some may call it bloat but there's less chance of non-main-repo programs forcing you to connect to their own repo and potentially creating a franken distro if it's not been updated (or has been updated too far!)
> or to install LaunchAgents and whatnot without having to document that anywhere
Yes! All OSs have this problem (I think that's what you meant later too?). There are two ways to solve this:
a) Put applications in their own containers (I believe that's what Android and iOS do?), and have them have to ask permission when wanting to access files outside
b) Have something like lsof attach itself to every application process (_like_ lsof, not actually lsof, because although you could get it to work, the costs would make it impractical)
Unfortunately, I think we're heading towards option (a).
Containers :: MSIx / AppX tries to do this on Windows. I think it's poorly executed since you also need all of the dependent libraries installers as well (AppX) since they don't get bundled and you're back to square one.
I agree that it's a total mess on all sides, but I do want to clarify that MSI is a database of what should be installed. I also want to push the note about MSI files being difficult to nearly impossible (outside of a project in visual studio) to make - I wanted to package something I wrote in vscode in an MSI and honestly I still cant figure out WiX after messing with it for hours.
The worst is install shield wrappers around MSI files. I assume it's easier to make but it makes them awful to use for an enterprise.
It's been many years but I used to be in charge of the installers for a small company. WIX was an incredible gift compared to InstallShield and company but it did have a steep learning curve. Much easier to do as I pleased in CI/CD though.
In regards to the exe wrappers, handy for bundling dependencies but also useful for elevating permissions in ways you can't do in a standard MSI which only allows elevated permissions during certain stages of the install.
> but apps are completely free to ignore that and install to anywhere
To be fair, I'm not aware of any package managers (other than container-based ones) that enforce installation locations; AFAIK you can create a .deb or .rpm that will drop files in /home and run arbitrary scripts on install and uninstall. The thing imposing order on the filesystem is what the distro policy imposes on their first party packaging, not a technical limitation in the packaging system.
Indeed, but at least for .deb packages, any file dropped by dpkg will be removed during uninstallation. Script-created files are a different beast, though.
I prefer the ui of bulk crap uninstaller more than uninstallr.
Uninstaller are powerful tools and for that I prefer ugly ui with more information.
Beside that if I think about uninstaller my first thought is maleware and shady practices from the uninstallers itself (e.g. ccleaner). Like most virus scanners nowadays.
Exactly right: the only quality I look for in utilities like these is that they are on GitHub and developed in the open and not full of ads or only downloadable from shadysoft inc or the shadytools website.
Tools like:
System Cleaner "If you are asking “How to make Windows faster” or “Why is my computer slow” – you just found the answer"
, Internet Optimizer
For example, the mentioned system cleaner can be used to remove leftover temporary files. Too much of which will slow down your computer. There is a benchmark to show this in the blog as well, I don't think I can link to it, because of spam filters here.
The Internet Optimizer tool simply benchmarks which DNS server is the fastest for the user's system. Again, what is dubious about that?
I know the author acknowledges that UI tastes differ, but I find it funny how far it goes sometimes. BCUninstaller looks so much better, clearer, and more intuitive than their tool. Sure, it not working properly is an issue, but if I had to go only from the screenshots in the posts, I’d choose BCU every time. Color for types, clear and easy filters, clear sorting.
Also, the Windows Store isn’t so bad, as long as you use the winget command line tool to install store apps and not the atrocious GUI ;)
An “everything” software listing and uninstaller front end for the various install methods (nuget, steam, msi, …) to see everything in one place is an excellent idea. Even better if it allowed plugins so you could add methods (e.g a developer might want a node env listing). It should stick to being a front end though and not try to be too clever when it comes to deleting things.
A misconception is that it’s possible to accurately determine whether something can or should be removed, when it’s usually impossible. The only thing that can uninstall windows software in general is the installer that installed it (if it’s correct), or a program that at least observed and recorded the installation of it.
Any software that claims otherwise is lying, and at best it will fail and at worst it will make a mess of your system.
These days it’s more and more common to completely ignore the windows installer system and install per-user to app data, which has the benefit of allowing a better self-updating experience without elevated permissions, and lower risk of pollution of system files.
The worst offenders in my experience when it comes to traditional windows installers are those that are not using Windows Installer but instead simply act as scripts dumping files and reg entries without concern for transactionality, sharing etc. For example some flavors of installshield and similar.
The Windows installer system for all its flaws IS a pretty robust - but quite complicated - system for managing installs. The problem is that it’s either unused or misused, which is a consequence of it being too complex I guess.
I'm amazed how much MS is failing with the MSI. You'd expect that in Visual Studio (the proper one, not code) there would be a simple way to say: this project - compile it and stick into MSI with just bare defaults. But no, you essentially have to get a third party thing to manage creating that for you, and even those involve custom scripting that requires another custom generator on top to get the list of files to install (looking at you, Vix). And no, the publish to Azure or ClickOnce are not reasonable options.
VB5 came with a built in installer generator - how did we regress from there?
MSIs are so bloated and horribly designed, it isn't even funny. Why does it insist on storing a copy of the entire .msi - and any patches - in C:\Windows\Installer? From what I've observed, the original MSI is required to perform repairs and reconfiguration, or setting up new-user defaults for that app. This seems horribly inefficient to me, and on heavily used system this can easily waste space on the C: drive.
And occasionally you run into issues with the MSI database corrupting, where you can't install/upgrade/uninstall something (we see this commonly with Adobe apps) , so you'd need to resort to third-party tools like MSI Zapper to get rid of all the references from the database. What a messy system.
I miss the days when programs used to use NSIS (Nullsoft) installers - they were tiny, and super easy to make and automate.
To make an uninstall of course you need the msi db parts (but you wouldn’t need the entire binary content). To make a reinstall (aka repair) you DO need both the db and the content.
I haven’t heard msis being bloated. I assume they contain exactly what they need to contain (though unsure about compression methods).
In the past when storage was scarce it seems like a strange design but these days I can’t say it feels so wrong.
> These days it’s more and more common to completely ignore the windows installer system and install per-user to app data, which has the benefit of allowing a better self-updating experience without elevated permissions, and lower risk of pollution of system files.
On the flip side, this is a nightmare to manage as sysadmins, who try to maintain a tight ship using AppLocker polices. So many apps these days have a standard installer, but then they download an update and try to run the newer version from AppData, and of course, it gets blocked and we get calls from angry users saying that their app no longer works. Of course, we could whitelist the digitally-signed executable, but some apps aren't even digitally signed (or only partially signed), sometimes the digital signature changes completely... it's a mess.
Then there's the problem of dumping large binaries and entire applications into the AppData folders, which bloats up user profiles. This can be a bit of an issue with certain roaming profile systems like Citrix User Profile Manager, which by default works in a blacklist mode (ie, you have to explicitly blacklist paths that you don't want to roam). If you don't stay on top of this and add new AppData subfolders to the exclusion list, then you'll find all your large Chrome updates or whatever (with several versioned folders) all syncing back up to the profile server, wasting space, bandwidth, and increasing logon, backup, and AV Scan times. In a large organization with several thousands of users, this is a disaster waiting to happen.
Also, using AppData to store entire apps is just plan wrong - that's NOT what it was meant for. AppData was meant for storing app data, and the apps themselves are supposed to be stored in Program Files.
These self-updating apps are the worst thing that could ever happen in a corporate environment.
I see two main camps of modern application installers, if you want to call them modern. one is Squirrel which is userland based (Microsoft Teams, Spotify, Slack irrc use this) and it's all but impossible to deal with as an admin.
the other camp is Omaha which chrome uses (along with Edge) and runs as a service to handle updates and install.
Neither of these handle the actual problem but push it down the road a bit - you'll find .exe and .MSI installers for both flavors of these applications (usually a boot strap to install the updater and then have that install the application)
I think one push for userland installers was that "you don't need admin" and to some developers it feels like the right place to install an app (user profiles) however I absolutely agree, this makes it a nightmare to deal with as an admin for windows devices.
I really do not like how squirrel handles updates since it feels like any app that uses it you have an in-your-face update experience vs. Omaha where it does background updates and you typically have no idea as a user anything even happened.
As far as code signing I went on a tangent one day trying to figure out why most code isn't signed and I think it's just too expensive and or complicated for developers not forced to be in a position to actually need it - enterprise or an app store requiring it.
Squirrel doesn’t have any installation gui or specific process. It downloads and installs version N+1 in the background. Next start will run that version. Any decision to show even a notification that this happened is entirely up to the developer. I think it’s even near impossible to show an “installer” in the traditional sense for the initial install. You can show a splash at initial install that’s it.
As far as userland installers go they are all (almost by definition) the same in the end
I can see the concern but from the user perspective what’s the solution assuming I want the one week release cycle of dozens of apps?
In the end I think the idea that apps install elevated but run under lower user privs is now completely outdated. One can’t and shouldn’t separate the idea of the user and the application maintainer.
> Also, using AppData to store entire apps is just plan wrong - that's NOT what it was meant for.
It doesn’t seem conceptually wrong to use program files for system wide (not per user) executables and localappdata for per user program files, regardless of whether they are program binaries or program data. Since they aren’t roaming and typically not backed up, what’s the harm in having teams.exe in there?
If chrome dumps large volumes of program binaries into app data\roaming (does it really?) then that sounds really bad. Similarly for any system that would roam anything outside of appdata\roaming.
Windows registry is such a good place to get lost it's been used by many trial software to leave hard to detect marks there.
Instead of trying to solve an impossible task like attempting to detect and remove "leftovers", it's more reasonable to prevent it from happening in the first place.
Most programs don't even need installers and work after simply unpacking into a directory like a zip archive.
For the rest, running programs in a sandbox like Sandboxie keeps their file and registry changes contained to a specific directory that you can simply delete. Coincidentally, it also makes all programs portable so you don't have to reinstall them when you reinstall Windows.
But of course all of that is quickly growing irrelevant as Windows itself is becoming more and more of crapware.
28 comments
[ 0.21 ms ] story [ 79.9 ms ] threadMost Linux distributions at least keeps package assets tracked (easy enough, given that packages aren't much more than a tarball that's extracted to / and a few scripts, and installation paths being relatively standardized). User configuration data is another issue entirely (edit: as are self-built programs, you need to keep the original build folder around and hope that the authors have made `make uninstall` actually work).
In contrast, Apple only follows the convention that a package's assets should be in /Applications/AppName.app... but apps are completely free to ignore that and install to anywhere not being protected by SIP, or to install LaunchAgents and whatnot without having to document that anywhere. That in turn means it's impossible to fully uninstall an Apple program that uses any of these features, and in addition macOS shares the same issue as Linux regarding user configuration data.
And Windows is the worst of the mess. It's essentially a free-for-all outside the Microsoft store, MSI (aka MS's attempt to copy Linux packages) is decent but tedious to package so you'll usually only find it used in enterprise software which needs to be packaged in a way suitable for deployment via GPOs, and on top of file cluttering Windows adds the Registry to the mess. Oh, and the bloatware of anything not installed from a Microsoft install medium.
If you can't install a normal Mac app via drag and drop, I'm not installing it. It's a great signal that you're dealing with an inexperienced Mac developer.
I absolutely refused to install Chrome for Mac, for instance, until they rewrote it to install via normal drag and drop after their custom installer/update workflow rendered computers unbootable.
> A wave of reported Macs being no longer able to boot was caused by a recent Google Chrome update that was corrupting a necessary operating system folder. Once the update was installed, affected users found they were no longer able to boot into macOS.
https://www.bleepingcomputer.com/news/security/buggy-google-...
I wish that packages got their own folders as standard, contained all the required libraries and had unique "internal" names like java packages to avoid conflicts. Very much like what Android and Nix do.
It's a bit of a pain for the package makers and some may call it bloat but there's less chance of non-main-repo programs forcing you to connect to their own repo and potentially creating a franken distro if it's not been updated (or has been updated too far!)
Hello, and welcome to Fedora Silverblue. Where everything is a container (flatpak)
With the minor exception of system drivers.
https://fedoraproject.org/silverblue/
Yes! All OSs have this problem (I think that's what you meant later too?). There are two ways to solve this:
a) Put applications in their own containers (I believe that's what Android and iOS do?), and have them have to ask permission when wanting to access files outside
b) Have something like lsof attach itself to every application process (_like_ lsof, not actually lsof, because although you could get it to work, the costs would make it impractical)
Unfortunately, I think we're heading towards option (a).
The worst is install shield wrappers around MSI files. I assume it's easier to make but it makes them awful to use for an enterprise.
In regards to the exe wrappers, handy for bundling dependencies but also useful for elevating permissions in ways you can't do in a standard MSI which only allows elevated permissions during certain stages of the install.
To be fair, I'm not aware of any package managers (other than container-based ones) that enforce installation locations; AFAIK you can create a .deb or .rpm that will drop files in /home and run arbitrary scripts on install and uninstall. The thing imposing order on the filesystem is what the distro policy imposes on their first party packaging, not a technical limitation in the packaging system.
Uninstaller are powerful tools and for that I prefer ugly ui with more information.
Beside that if I think about uninstaller my first thought is maleware and shady practices from the uninstallers itself (e.g. ccleaner). Like most virus scanners nowadays.
Tools like: System Cleaner "If you are asking “How to make Windows faster” or “Why is my computer slow” – you just found the answer" , Internet Optimizer
Very very dubious.
For example, the mentioned system cleaner can be used to remove leftover temporary files. Too much of which will slow down your computer. There is a benchmark to show this in the blog as well, I don't think I can link to it, because of spam filters here.
The Internet Optimizer tool simply benchmarks which DNS server is the fastest for the user's system. Again, what is dubious about that?
Also, the Windows Store isn’t so bad, as long as you use the winget command line tool to install store apps and not the atrocious GUI ;)
Personally, I just reinstall Windows once a year.
A misconception is that it’s possible to accurately determine whether something can or should be removed, when it’s usually impossible. The only thing that can uninstall windows software in general is the installer that installed it (if it’s correct), or a program that at least observed and recorded the installation of it. Any software that claims otherwise is lying, and at best it will fail and at worst it will make a mess of your system.
These days it’s more and more common to completely ignore the windows installer system and install per-user to app data, which has the benefit of allowing a better self-updating experience without elevated permissions, and lower risk of pollution of system files.
The worst offenders in my experience when it comes to traditional windows installers are those that are not using Windows Installer but instead simply act as scripts dumping files and reg entries without concern for transactionality, sharing etc. For example some flavors of installshield and similar.
The Windows installer system for all its flaws IS a pretty robust - but quite complicated - system for managing installs. The problem is that it’s either unused or misused, which is a consequence of it being too complex I guess.
VB5 came with a built in installer generator - how did we regress from there?
And occasionally you run into issues with the MSI database corrupting, where you can't install/upgrade/uninstall something (we see this commonly with Adobe apps) , so you'd need to resort to third-party tools like MSI Zapper to get rid of all the references from the database. What a messy system.
I miss the days when programs used to use NSIS (Nullsoft) installers - they were tiny, and super easy to make and automate.
I haven’t heard msis being bloated. I assume they contain exactly what they need to contain (though unsure about compression methods).
In the past when storage was scarce it seems like a strange design but these days I can’t say it feels so wrong.
On the flip side, this is a nightmare to manage as sysadmins, who try to maintain a tight ship using AppLocker polices. So many apps these days have a standard installer, but then they download an update and try to run the newer version from AppData, and of course, it gets blocked and we get calls from angry users saying that their app no longer works. Of course, we could whitelist the digitally-signed executable, but some apps aren't even digitally signed (or only partially signed), sometimes the digital signature changes completely... it's a mess.
Then there's the problem of dumping large binaries and entire applications into the AppData folders, which bloats up user profiles. This can be a bit of an issue with certain roaming profile systems like Citrix User Profile Manager, which by default works in a blacklist mode (ie, you have to explicitly blacklist paths that you don't want to roam). If you don't stay on top of this and add new AppData subfolders to the exclusion list, then you'll find all your large Chrome updates or whatever (with several versioned folders) all syncing back up to the profile server, wasting space, bandwidth, and increasing logon, backup, and AV Scan times. In a large organization with several thousands of users, this is a disaster waiting to happen.
Also, using AppData to store entire apps is just plan wrong - that's NOT what it was meant for. AppData was meant for storing app data, and the apps themselves are supposed to be stored in Program Files.
These self-updating apps are the worst thing that could ever happen in a corporate environment.
the other camp is Omaha which chrome uses (along with Edge) and runs as a service to handle updates and install.
Neither of these handle the actual problem but push it down the road a bit - you'll find .exe and .MSI installers for both flavors of these applications (usually a boot strap to install the updater and then have that install the application)
I think one push for userland installers was that "you don't need admin" and to some developers it feels like the right place to install an app (user profiles) however I absolutely agree, this makes it a nightmare to deal with as an admin for windows devices.
I really do not like how squirrel handles updates since it feels like any app that uses it you have an in-your-face update experience vs. Omaha where it does background updates and you typically have no idea as a user anything even happened.
As far as code signing I went on a tangent one day trying to figure out why most code isn't signed and I think it's just too expensive and or complicated for developers not forced to be in a position to actually need it - enterprise or an app store requiring it.
In the end I think the idea that apps install elevated but run under lower user privs is now completely outdated. One can’t and shouldn’t separate the idea of the user and the application maintainer.
> Also, using AppData to store entire apps is just plan wrong - that's NOT what it was meant for.
It doesn’t seem conceptually wrong to use program files for system wide (not per user) executables and localappdata for per user program files, regardless of whether they are program binaries or program data. Since they aren’t roaming and typically not backed up, what’s the harm in having teams.exe in there?
If chrome dumps large volumes of program binaries into app data\roaming (does it really?) then that sounds really bad. Similarly for any system that would roam anything outside of appdata\roaming.
Instead of trying to solve an impossible task like attempting to detect and remove "leftovers", it's more reasonable to prevent it from happening in the first place.
Most programs don't even need installers and work after simply unpacking into a directory like a zip archive.
For the rest, running programs in a sandbox like Sandboxie keeps their file and registry changes contained to a specific directory that you can simply delete. Coincidentally, it also makes all programs portable so you don't have to reinstall them when you reinstall Windows.
But of course all of that is quickly growing irrelevant as Windows itself is becoming more and more of crapware.
As SYSTEM user (via psexec):
Then good ol regCleaner.exe and sometimes regClean too. Gonna give Uninstalr a try.