Comment by mschuster91 | Hacker News Reader

Comment by mschuster91 | Hacker News Reader

Parent Full thread

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.

> 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.

https://www.bleepingcomputer.com/news/security/buggy-google-...

Everything you need to know about Chrome can be summarized by the fact that ‘cmd-q’ doesn’t quit Chrome.

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!)

>> I wish that packages got their own folders as standard, contained all the required libraries and had unique "internal" names

Hello, and welcome to Fedora Silverblue. Where everything is a container (flatpak)

With the minor exception of system drivers.

https://fedoraproject.org/silverblue/

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.

> 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.

> 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.

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.

Reply on news.ycombinator.com