Hacker News Reader

Comment by pfp | Hacker News Reader

No. The user data, preferences etc under ~/Library/ belong to you - whether it's 3 kB of preference toggles or 3 decades of email.

It would be "unbelievable" if a multibillion company decided to be helpful and erase your data just because you deleted the binary that created them (actually, it wouldn't, but let's not digress into how those companies are stripping away our agency by mobile-ossifying everything).

The whole Mac idea was that there's no "uninstall process" with opaque windoze registries etc; what the Finder shows you is simple enough for an average user to understand. Like dragging an "Application" or a CD-ROM into the Trash to get rid of it. Of course they ruined all that with ~/Library/{Preferences,Application Whatever,Kitchen Sink}/.

Turns out your UNIX with a human face ate its children afterall. With relish.

Also, "uninstallable" means "cannot be installed"

View on HN

Consider that sometimes people do actually want to clean up all artifacts of an installation, and don't want to go digging around in a bunch of machine-generated directories trying to guess what to delete.

I think I agree that the default behavior should be to leave all that data on the user's system. But I also think that apps should have some kind of associated file manifest, which you can use to automatically clean up after the app, or at minimum get a definitive list that you can go through manually or with a script.

It turns out that Apple installer packages do include a manifest (cutely called a BOM) of package contents, but users don't typically keep package installers around after completing installation successfully, and it says nothing about files that may be written by the app itself while in use.

I don't see how you could possibly claim that the user library "ruined" anything. Most apps need to save some kind of settings and/or transient data files. Where else would they go?

> sometimes people do actually want to clean up

There are two scenarios I want the cleanup to happen: 1) app is buggy and I'm trying to fix it by reinstalling from scratch, 2) I need to free disk space. Both are pretty rare, and in the second case I am already using a specialized utility like DaisyDisk to see where my space has gone.

> transient data files

/tmp? That gets actually auto cleaned up!

> settings

Maybe. Do we want macOS to introduce the concept of uninstall to shave a few of those kilobytes? Hoping programmers do not screw up with rm -rf /? I already hate it when I have to use an installer so that's a no from me.

> 1) app is buggy and I'm trying to fix it by reinstalling from scratch

You don't specify and it's highly dependent but in most cases when an app is misbehaving it's an issue with preferences. You can reset most apps with `defaults` without blowing away all its data. There are some intricacies with how macOS handles preferences, so you should avoid manually editing related .plist.

Note that if I am trying to fix an app that I want to keep using I sure as hell may want to keep the preferences.

The case where I want it to auto clean up is where it is repeatedly broken and I never really got to using and configuring it yet. It's pretty rare.

> Note that if I am trying to fix an app that I want to keep using I sure as hell may want to keep the preferences.

Of course, `man defaults`. You can modify the preferences and potentially fix it, backup preferences, etc. Again I must stress that you use `defaults`, the .plist on disk isn't always accurate even if you terminate the app and reboot the machine.

> The case where I want it to auto clean up is where it is repeatedly broken and I never really got to using and configuring it yet. It's pretty rare.

There isn't really a one size fits all perfect automatic solution. Not all apps are good macOS citizens.

So the only scenarios automatic uninstall is useful are far and between and even then no one size fits all, which is why I don't like the idea...

/tmp isn't really suitable for storing the exact kinds of persistent config files that you say shouldn't be uninstallable.

How on earth transient data files is the same thing as persistent config files?

Cache files are frequently non-trivial in size and go into ~/Library/Caches, and those are not cleaned up automatically.

>opaque windoze registries etc

Thanks for demonstrating your lack of credibility.

Uninstallers by and large only do the reverse of what an installer did by going through the install log and undoing what it did.

This means any additional files made after the the installation that weren't properly appended to the log, any additional information added to the Registry that weren't properly appended to the log, and any user files created after installation (eg: save files) will not be touched by the uninstaller.

Should everything be properly logged for clean uninstalling? Yes; Linux package managers are a decent example. But reality is not ideal, so we have to deal with practicality. This presumably is the case whether it's Windows, Mac, or Linux.

Most windows installers do not bother to clean up /Program Data or ~/AppData

Nor do most linux programs remove dot files when they go away.

Especially ~/AppData (and ~/Library) is problematic because the person uninstalling the app might not be the person who was previously using the app.

Reaching into another account‘s home directory to remove stuff feels very intrusive.

Which would mean that any uninstall trying to also clean out library data is going to be incomplete.

I think the consistent behavior of always keeping it is a win

I'd love if they'd clean up registry keys, or if windows did. But broadly I agree with you.

The user-specific parts of the registry are powered by files in the user‘s profile and ACLs do not normally allow other users to have access, so the same issue applies there too

lots of them leave crud in HKLM/System and HKLM/Software, as well as I think HKey_Curent_Config

I dont mind the per user settings crud, I do mind the system wide crud, because it can make reinstating the app to resolve an issue fraught, and I have to go manually find whatever opaque keys were set and remove them.

Some uninstallers do ask you if you wish to retain configuration clutter.

> The whole Mac idea was that there's no "uninstall process" with opaque windoze registries etc; what the Finder shows you is simple enough for an average user to understand. Like dragging an "Application" or a CD-ROM into the Trash to get rid of it. Of course they ruined all that with ~/Library/{Preferences,Application Whatever,Kitchen Sink}/.

The Windows registry is a simple key-value store, just like the macOS defaults system. Windows installers/uninstallers may create/remove some registry entries, but those are typically entries for file associations and the installed program list, and perhaps some global settings. But then the app is free to write its configuration data to any registry key it likes (usually ones named after the app), or to files in ~\AppData, or perhaps C:\ProgramData. It’s not much different to macOS in that regard. The uninstaller may offer to remove the stuff in AppData, or it might keep it as-is.

(~\AppData is a bit less messy than ~/Library, because there are only three folders in AppData where application folders could go, but Library has all these folders with various meanings.)

I think on macOS programs are able to store data "inside" themselves, because .app files are just folders. They usually shouldn't put stuff in Library.

That's wrong, of course they should put stuff in the ~/Library if necessary. That's why if you update an app it just replaces the whole .app directory, and also if you uninstall something and then install it again all your settings will still be there.

Not dynamic data. Everything in an .app should be checksummed/signed & verified

> Also, "uninstallable" means "cannot be installed"

Nope. In writing, it's technically ambiguous -- it could mean both "can't be installed" or "can't be uninstalled" but to me it means "can't be uninstalled". In spoken language, it depends how you stress the first syllable and both could be used, I guess.

That's why if you want to denote the installability of something, you should use the nonambiguous installable-noninstallable pair and leave the word "uninstallable" for the "can't be uninstalled" meaning. AFAICT, whether you should spell it as "non-installable" or "noninstallable" (note the hyphen) is up to you.

Again, in my personal experience, uninstallable definitely means 2 in [1]: "uninstall-able". Pretty sure I never saw that word used as "un-installable".

[1]: https://en.wiktionary.org/wiki/uninstallable

The ambiguous uninstallable meanings would be:

* cannot be installed

* can be uninstalled

The Wikipedia link you posted agrees with that interpretation.

I think “can’t be uninstalled” would be “non-uninstallable”.

Ah yes, of course. A "mental" typo from my part, I guess.

You could use “uninstall-able”.

This makes it clear (or at least clearer) that “able” is the modifying suffix to the root concept “uninstall”.

When I delete an app on an iPhone, all its data is also deleted. Gone. Why can't it be the same for the Mac?

That's what the average end-user understands by removing an app from the system nowadays.

> When I delete an app on an iPhone, all its data is also deleted. Gone. Why can't it be the same for the Mac?

Because on iPhone the app is completely sandboxed. Think Docker, with virtualised OS paths, but on OS level. When Apple tried to introduce a very light version of sandboxing, the world was ablaze in pitchforks and torches.

There is an exception on iOS as well. Apps can register write access to a custom location on iCloud that will persist after the app has been deleted. You can see all the leftovers in Files.app

iOS apps usually store all user data in the cloud, so you can delete their data without much risk.

  When I delete an app on an iPhone, all its data is also deleted. Gone.

Nope. Delete your Google apps. Reinstall one. It'll still pick up the accounts you used prior. Well, it used to anyways. It's not an iCloud keychain thing (or it wasn't).

https://apple.stackexchange.com/questions/441112/how-can-i-r...

https://apple.stackexchange.com/questions/332574/deleting-an...

The helpful part would be for the huge company to give users visibility and an easy choice, not your simple "delete everything" strawman The data doesn't "belong to me", that entirely depends on the specific app/type of data (and this concept of a few kbs of very important stuff I've carefully changed in the app's settings menu and would even like to track in vcs vs all the other junk is also largely missing, though that's also on the app devs)

In Ubuntu i can do apt remove to just uninstall the binary or i can apt purge to remove config files as well. Is there an native macOS equivalent for this?

The package manager will never attempt to clear stuff under user's home directories, just like macOS will not clear stuff under ~/Library. The package manager doesn't and cannot know what content an application has created while in use. Only the application itself knows that.

Flatpak applications under Linux get their little sandboxes under ~/.var/app/$application-id where they can create whatever they want and the user can remove it from there when needed. Except for that, any other path that the app can access is decleared in the permissions; or the user is very well aware, because he picked the file via filechooser (portal).

Soma macOS applications can use similar scheme, under ~/Library/Containers/$application-id, but for the user more difficult to know which one is supposed to and which isn't.

> Also, "uninstallable" means "cannot be installed"

It means both cannot be installed and can be uninstalled, depending on context.

At least provide a user friendly way to manage it. For instance, offer the option to either delete, backup, or leave in place when uninstalling. For things left in place, have a GUI to view and manage them.

Reply on news.ycombinator.com