Hacker News Reader

Comment by AbusiveHNAdmin | Hacker News Reader

[flagged]

I'll help you out by offering this common scenario:

You have an application which is a normal app bundle. It doesn't update itself because, well, few developers have bothered taking this route, so you download a new version of it and you throw the old one in the trash. Now all of your preferences are gone and you have to set everything up again.

That would not be a pleasant user experience, would it. Dropping the bundle in the trash doesn't remove your preferences because it would be an idiotic thing to do.

I agree. How is that "helping me out?" I never said dragging stuff to the trash should do that. I said there should be an UNINSTALLER, which is the whole topic at hand here.

It helped you understand why dropping app bundles in the trash does not clean out per-user property lists.

App bundles are never installed anywhere as they are self-contained products, hence they cannot be uninstalled. For applications that actually come in the form of package installers which may place files in "annoying" locations like /usr/local/, you also get the functionality of uninstalling the software, because these packages contain manifests describing what files go in what locations.

Why are you telling ME this? I never said trashing app bundles clears out property collections or settings.

You must be replying to the wrong person.

The Windows apologists are non the wiser :). Windows still has no full uninstaller that can clean the registry droppings many apps leave and other files, requiring to use specialized apps for that. And sometimes it would also fail to uninstall the binary. And Windows bizarely needs to retain the huge installers, so that part is strictly worse vs Mac

In fairness to Microsoft, that's only true for apps that don't use the official packaging format. Official packaging format? Yep, if you distribute your app as an MSIX file then you get:

• Integrated automatic uninstall (which is fast).

• Automatic online updates.

• Apps have their registry and AppData writes redirected to a private location, which Windows can then clean up. It's a bit like the macOS app sandbox but the app isn't actually sandboxed, it's much lighter than that and there only for clean uninstalls.

• No need to retain downloaded packages or installers.

• If you use the .appinstaller feature, only the parts of the package that the user doesn't already have are downloaded so apps that use big runtimes (electron, jvm, flutter etc) can turn into small downloads if the user already has such an app.

• Don't need admin rights to install.

• Integration with Windows network admin tools. MSIX is declarative so Windows can do things like make apps appear without them being actually installed.

• There's a tool that monitors other installers and converts them into MSIX files.

So Windows has solutions for a lot of these problems. Unfortunately developers don't know about it and that's partly because Windows has a lot of bugs, especially in Windows 10 (which hasn't been receiving bug backports for a long time now). The best way to get these features is to use Conveyor which is a tool that abstracts you from the packaging tech and automatically works around the bugs (Disclosure: I wrote Conveyor). It also extends it with other useful features like checking for and automatically applying updates every time the app is run (if you want that):

https://hydraulic.software/

How is this fair at all? 1. This is "only true" for almost all the apps 2. A much better alternative without that waste already exists in 3rd-party apps, so no new packaging format is needed to fix it 3. Is this new shiny toy MSIX the one that doesn't even allow changing installation path?

The problems you're describing are technically problems of apps, not really problems of Windows (any more). Yes arguably the line is blurred, you can say this is a pedantic distinction because Windows = the apps that people use. But the tech is there.

MSIX indeed picks the install path for you but very few users want to change it these days. Chrome installer doesn't let you pick either.

The old tech is also the official OS one, so all the responsibility for not fixing it lies with the OS, can't blur it with the apps

Having a better alternative while still not fixing the old system does not shield the OS from this.

Neither does the existence of other bad apps like Chrome shield the new system from the blame for making the same obvious mistake, especially when the example of macOS with its simple bundled app folders that you can just drag&drop around has been right there the whole time

Your post went dead for some reason, but that seemed unfair so I vouched for you and upvoted it. We may not fully agree on this, but your discussion is civilized and should not have been flagged.

I think we can choose between either full managed app store mode like on ios (no low-level control but full automatic uninstallation + synced settings and such) or Unix-style where you have full control.

Something inbetween the two is worse, you get installers and uninstallers that are half-broken because they can never assume stuff about your system and just be broken but you never know exactly what they're doing.

Windows and macOS are both inbetween to various degrees, but I think macOS is a bit closer to Unix style (excluding App Store apps).

But we were not lied to in that regard.

The lie is that "uninstall" uninstalls when in reality it just uninstalls*

You're not supposed to speak unkind of Apple products [0] or its peripherals North Face, Patagonia.

How is any operating system supposed to log everything an application does and then remove it? If it's allowed to add data beyond its birth directory, would not an "uninstaller" only remove whatever the devs chose to and not 100% of its effect on the OS?

[0] https://stuffwhitepeoplelike.com/2008/01/30/39-apple-product...

Sent from my MacBook Pro

It isn't supposed to, of course. But there should be a standard facility offered by the OS that well-behaved apps can use to install components, through which the OS WILL log each of them and be able to remove them later.

The main challenge is shared libraries; these are hard to delete reliably, even if the installer keeps a "use count" that it can increment and decrement. Just one non-compliant dependency will be broken if you remove all the compliant ones and a lib it needs gets blown away.

Reply on news.ycombinator.com