4 ms·

Uninstaller should not exist. Installers should not exist either. Every OS should have a package manager. The name clearly implies what it does: it manages pack

Uninstaller should not exist. Installers should not exist either. Every OS should have a package manager. The name clearly implies what it does: it manages packages; this task should be left to a specialized software, not to the user. Linux distros were pioneers in this aspect and "stores" of the modern world are just a clothed versions of package managers. of course, a power user should should have the right to change software sources (repositories). It should be possible to add decentralized package managers like it is possible with flatpack. Installers and uninstallers are a relic of a time were most software people used were proprietary running under a proprietary environment. Many windows users are still locked in that proprietary closed world. If "Any sufficiently advanced uninstaller is indistinguishable from malware", I'd say that most (all?) microsoft software comes with extremely advanced uninstallers.

threatofrain 3y ago
I find that Linux software culture also leaves stuff behind and leaves it up to the assumed system mastery of the user to clean things up.
- koiueo 3y ago
  That's too broad and misleading. Package manager tracks every single file installed by a package, preventing overwrites by other packages. Strict permissions prohibit software from littering all over the place. What are you taking about? Do you want package manager to remove yourb personal data of it was created by an application your decided to remove?
  - deleted 3y ago
    [deleted]
  - kroltan 3y ago
    Maybe I do! Many Windows custom uninstallers have an option to remove "settings" while uninstalling. I sure have lots of junk in ~/.config I don't use anymore and probably never will.
  - SAI_Peregrinus 3y ago
    It should certainly be capable of removing everything the application created that wasn't manually exported by the user or saved into a user data directory. E.g. everything it made in XDG_CONFIG_HOME, XDG_STATE_HOME, XDG_DATA_HOME, XDG_CACHE_HOME, etc. Probably not anything from XDG_DOCUMENTS_DIR or the other "user data" directories.
  - deleted 3y ago
    [deleted]
sebazzz 3y ago
> The name clearly implies what it does: it manages packages; this task should be left to a specialized software Yes, but the modifications that are possible are limited by what the API of the package manager provides. Like Windows Installer does. If that doesn't work you create custom install uninstall logic, which has the potential to be less robust/reliable than what the package manager provides.
- Spivak 3y ago
  I mean all Linux package managers allow running arbitrary code on install/uninstall and it seems to work well enough.
  - sebazzz 3y ago
    It has also failed enough times for me, but luckily it often works like "on error resume next" do the package manager doesn't get stuck in a bad state. Regardless, installation on Linux is often just dropping some files somewhere and perhaps a modprobe. In Windows you have so many things you can do: filesystem, registry, COM registration, GAC, file associations, etc.
    - Spivak 3y ago
      It's not really that dissimilar. People like to act that Windows is so complicated and convoluted when in time the Linux desktop has invented all the same concepts. registry -> dconf com registration -> dbus objects gac -> shared libs file associations -> dconf settings windows scheduler entries -> systemd user session
      - sebazzz 3y ago
        Right, but most of these entries are still (1) only files or (2) are almost never touched by most packages. And the GAC isn't really comparable, perhaps WinSxS is comparable, but the GAC requires a specific API and isn't a matter of just dropping a file in /usr/lib.
  - 3y ago
mattashii 3y ago
> Uninstaller should not exist. Installers should not exist either. Every OS should have a package manager What is a package manager, if not an (un)installer shared between projects?
- systems 3y ago
  well you would normally trust the package manager that comes from your OS/Distro provider, as opposed to an uninstalling script from a developer anonymous to you
- haswell 3y ago
  It’s a single, standardized uninstaller governed by the creators of the OS. Sharing between projects is not how I’d frame this. Using a shared/standard OS facility is closer. This matters quite a bit when it comes to establishing trust.
PaulHoule 3y ago
It's not proprietary or not, it's the level of discipline about installing software. iOS is completely proprietary and has a very disciplined system for installing and uninstalling apps. The Windows non-system of installers/uninstallers is really anarchy except to the end user it looks like a system because the installers/uninstaller mostly look the same, mainly because https://en.wikipedia.org/wiki/InstallShield https://en.wikipedia.org/wiki/InstallShield became a defacto standard endorsed by Microsoft and everybody else tries to look like it. The real Windows "quirk" that this article skirts around is that Windows won't let you delete a file which is open and of course if you are running an executable that counts as an open file. This of course can be a huge hassle if you need to delete something and can't find the process which is holding the file open. It's particularly annoying for things like software builds where you really want a script that automatically and reliably clears a lot of stuff away so you can make a fresh start. Now, POSIX has the opposite "quirk" that you can "delete" an open file and it completes right away because all you did was delete the link from the directory to the file. The file still exists because it has a link from the process that has it open, it really gets deleted when that link goes away. That can get you in just as much or more trouble than the way Windows does it can, for instance if some series of events caused your system log to fill the disk, you can "rm" the log and the disk is still full. To really free up the space you need to "rm" and then restart the log daemon. As for Linux it's got the problem of a proliferation of package managers in the sense of things like flatpak and snap and generally the (dumpster fire I think) of Docker images (like the place where they thought Docker would help stabilize their Python installations but somehow our data scientists kept finding strangely broken Python images that were real nightmare fuel for me; e.g. default character encodings that I didn't think anybody actually used) Windows has realized the ability to install software in C:/Program Files/ and D:/Program Files/ and often in a user's home directory (if the installer supports it.) 20 years ago I thought rpm's sucked and thought "any software worth installing is worth building from source" where I could do make-install --prefix=/usr|/usr/local|$HOME that is I didn't have to beg for my sysadmin to do something like apt-get install nethack I am impressed with the comparative speed of installing from a package manager, but I still can't install a local copy of software with one, and I should be able to.
deleted 3y ago
[deleted]
troyvit 3y ago
You are right. Linux distros were pioneers and it used to be great, but it's gone off the rails now. Running kde-neon I have pkcon, apt/aptitude (for when I forget pkcon or one of its commands), flatpaks, AppImages, and the usual rigamarole of uninstalling snap and then setting up app-level installers for the things that previously only had snap candidates (lookin' at you Firefox). On the RH side I have both yum and dnf? Mokay. Back when I was installing KDE on top of another distro, I'd also have the Discover front-end sitting next to Gnome's Software Center (or whatever it was). That should be somewhat expected and is more an indication of the bloat that major window managers have embraced. The front-ends are decent about showing what source a piece of software came from, which is nice, but the last time I used them they didn't stop one from installing the same piece of software from two different sources. All to say, back in the day it was so convenient to have yum or aptitude just take care of things installing software, resolving conflicts, etc. Now we're in a bit of a mire.
alkonaut 3y ago
The difference between a "package being installed by a package manager" and "an application being installed by an installer" can be as small as you want. Linux packages have "installers and uninstallers" in the sense that inside a .deb file for example there are scripts doing necessary tasks for installing and uninstalling. And whether they make a mess is only dependent on these scripts behaving in a way that doesn't make a mess. So having a package format or package repository doesn't necessarily prevent packages from doing arbitrary or stupid things (there is no difference between a .deb file or an .msi file in that regard). The app store ore repository might add a level of human vetting, but technically there is no difference. I would argue that it's better to have most of the vetting be technical: ensure that the package/installer format doesn't allow making a mess. Sandbox everything, prevent writes in the wrong places etc. More modern formats like flakpak/msix/etc are of course better in this regard. And the key thing about them is that they prevent a mess on the technical level so that the human vetting (and thus repository) isn't really required.

threatofrain 3y ago

I find that Linux software culture also leaves stuff behind and leaves it up to the assumed system mastery of the user to clean things up.

koiueo 3y ago
That's too broad and misleading. Package manager tracks every single file installed by a package, preventing overwrites by other packages. Strict permissions prohibit software from littering all over the place. What are you taking about? Do you want package manager to remove yourb personal data of it was created by an application your decided to remove?
- deleted 3y ago
  [deleted]
- kroltan 3y ago
  Maybe I do! Many Windows custom uninstallers have an option to remove "settings" while uninstalling. I sure have lots of junk in ~/.config I don't use anymore and probably never will.
- SAI_Peregrinus 3y ago
  It should certainly be capable of removing everything the application created that wasn't manually exported by the user or saved into a user data directory. E.g. everything it made in XDG_CONFIG_HOME, XDG_STATE_HOME, XDG_DATA_HOME, XDG_CACHE_HOME, etc. Probably not anything from XDG_DOCUMENTS_DIR or the other "user data" directories.
- deleted 3y ago
  [deleted]

sebazzz 3y ago

> The name clearly implies what it does: it manages packages; this task should be left to a specialized software Yes, but the modifications that are possible are limited by what the API of the package manager provides. Like Windows Installer does. If that doesn't work you create custom install uninstall logic, which has the potential to be less robust/reliable than what the package manager provides.

Spivak 3y ago
I mean all Linux package managers allow running arbitrary code on install/uninstall and it seems to work well enough.
- sebazzz 3y ago
  It has also failed enough times for me, but luckily it often works like "on error resume next" do the package manager doesn't get stuck in a bad state. Regardless, installation on Linux is often just dropping some files somewhere and perhaps a modprobe. In Windows you have so many things you can do: filesystem, registry, COM registration, GAC, file associations, etc.
  - Spivak 3y ago
    It's not really that dissimilar. People like to act that Windows is so complicated and convoluted when in time the Linux desktop has invented all the same concepts. registry -> dconf com registration -> dbus objects gac -> shared libs file associations -> dconf settings windows scheduler entries -> systemd user session
    - sebazzz 3y ago
      Right, but most of these entries are still (1) only files or (2) are almost never touched by most packages. And the GAC isn't really comparable, perhaps WinSxS is comparable, but the GAC requires a specific API and isn't a matter of just dropping a file in /usr/lib.
- 3y ago

mattashii 3y ago

> Uninstaller should not exist. Installers should not exist either. Every OS should have a package manager What is a package manager, if not an (un)installer shared between projects?

systems 3y ago
well you would normally trust the package manager that comes from your OS/Distro provider, as opposed to an uninstalling script from a developer anonymous to you
haswell 3y ago
It’s a single, standardized uninstaller governed by the creators of the OS. Sharing between projects is not how I’d frame this. Using a shared/standard OS facility is closer. This matters quite a bit when it comes to establishing trust.

PaulHoule 3y ago

It's not proprietary or not, it's the level of discipline about installing software. iOS is completely proprietary and has a very disciplined system for installing and uninstalling apps. The Windows non-system of installers/uninstallers is really anarchy except to the end user it looks like a system because the installers/uninstaller mostly look the same, mainly because https://en.wikipedia.org/wiki/InstallShield https://en.wikipedia.org/wiki/InstallShield became a defacto standard endorsed by Microsoft and everybody else tries to look like it. The real Windows "quirk" that this article skirts around is that Windows won't let you delete a file which is open and of course if you are running an executable that counts as an open file. This of course can be a huge hassle if you need to delete something and can't find the process which is holding the file open. It's particularly annoying for things like software builds where you really want a script that automatically and reliably clears a lot of stuff away so you can make a fresh start. Now, POSIX has the opposite "quirk" that you can "delete" an open file and it completes right away because all you did was delete the link from the directory to the file. The file still exists because it has a link from the process that has it open, it really gets deleted when that link goes away. That can get you in just as much or more trouble than the way Windows does it can, for instance if some series of events caused your system log to fill the disk, you can "rm" the log and the disk is still full. To really free up the space you need to "rm" and then restart the log daemon. As for Linux it's got the problem of a proliferation of package managers in the sense of things like flatpak and snap and generally the (dumpster fire I think) of Docker images (like the place where they thought Docker would help stabilize their Python installations but somehow our data scientists kept finding strangely broken Python images that were real nightmare fuel for me; e.g. default character encodings that I didn't think anybody actually used) Windows has realized the ability to install software in C:/Program Files/ and D:/Program Files/ and often in a user's home directory (if the installer supports it.) 20 years ago I thought rpm's sucked and thought "any software worth installing is worth building from source" where I could do make-install --prefix=/usr|/usr/local|$HOME that is I didn't have to beg for my sysadmin to do something like apt-get install nethack I am impressed with the comparative speed of installing from a package manager, but I still can't install a local copy of software with one, and I should be able to.

deleted 3y ago

[deleted]

troyvit 3y ago

You are right. Linux distros were pioneers and it used to be great, but it's gone off the rails now. Running kde-neon I have pkcon, apt/aptitude (for when I forget pkcon or one of its commands), flatpaks, AppImages, and the usual rigamarole of uninstalling snap and then setting up app-level installers for the things that previously only had snap candidates (lookin' at you Firefox). On the RH side I have both yum and dnf? Mokay. Back when I was installing KDE on top of another distro, I'd also have the Discover front-end sitting next to Gnome's Software Center (or whatever it was). That should be somewhat expected and is more an indication of the bloat that major window managers have embraced. The front-ends are decent about showing what source a piece of software came from, which is nice, but the last time I used them they didn't stop one from installing the same piece of software from two different sources. All to say, back in the day it was so convenient to have yum or aptitude just take care of things installing software, resolving conflicts, etc. Now we're in a bit of a mire.

alkonaut 3y ago

The difference between a "package being installed by a package manager" and "an application being installed by an installer" can be as small as you want. Linux packages have "installers and uninstallers" in the sense that inside a .deb file for example there are scripts doing necessary tasks for installing and uninstalling. And whether they make a mess is only dependent on these scripts behaving in a way that doesn't make a mess. So having a package format or package repository doesn't necessarily prevent packages from doing arbitrary or stupid things (there is no difference between a .deb file or an .msi file in that regard). The app store ore repository might add a level of human vetting, but technically there is no difference. I would argue that it's better to have most of the vetting be technical: ensure that the package/installer format doesn't allow making a mess. Sandbox everything, prevent writes in the wrong places etc. More modern formats like flakpak/msix/etc are of course better in this regard. And the key thing about them is that they prevent a mess on the technical level so that the human vetting (and thus repository) isn't really required.