5 Tons of Flax

What the deuce!

Mac OS needs an uninstaller?

Posted by Jon on 28 November, 2007

I’m preparing right now for an upgrade to Mac OS 10.5 (Leopard!) on my old iBook G4. One thing I’m doing is listing all the third party software I’m going to need to reinstall, and reflecting a little bit on the accumulation of software I’ve installed and no longer use.

As per an older discussion I came across here, I think one major thing missing from the Mac OS is an easier method of purging the detritus files left behind when you trash an application. That doesn’t mean the horrible Window-style uninstallation process, but something more elegant. Building on a few other people’s thoughts at the discussion linked above, here’s my thoughts and what I’d like to see:

First off, on the whole, a Mac deals with applications in a much more elegant and intuitive manner than a Windows system. My understanding is that, with rare exceptions, Windows programs are installed by a separate installation program that is either unique to the applicaiton in question or a generic installer. This process scatters files all over the hard drive. When it comes time to uninstall, you’re dependent on that installation/uninstallation program that came with your app; the Windows “Add/Remove Programs” panel really just points you to wherever that uninstaller is located.

Mac applications, on the other hand, are almost always treated as a single file; each app is actually a folder of files, but packaged in such a way that it can be dealt with as a single file. The Mac approach is far more intuitive; with rare exceptions (I’m looking at you, Adobe and Microsoft), “installing” an app means simply copying it from the source (e.g., a disk) to the hard drive. Putting it in the designated Applications folder is more about good organization than (generally speaking) necessity. The problem comes when you run the app – the app itself (not a separate installer) creates support files (e.g. preferences) in various places. If the programmer is responsible, these will be in the appropriate places; a preference .plist file might be in ~/Library/Preferences/AppName/ for example.

The problem of course, comes when you trash the app. The app is “uninstalled” effortlessly, but its support files, preferences, caches, etc. are left behind. This uses up space, very occassionally can cause conflicts, and worst is inelegant.

My solution would be similar to some that people suggested in the above discussion, but with a few minor variations:

In /Library/Receipts/ and ~/Library/Receipts/, the operating system should create a file for each application that lists each file they create in the corresponding library. Any files created to root, or /System/ or /Applications/ or ~/Applications/ would also be included on the user- or system-level receipt for that application.

Note that this doesn’t seem to involve any effort on the application programmer’s part, since it’s done at the operating system level (that is, the system is put in place by apple). Nor does it include any files in ~/Documents/ or the other user data folders. Each time an application makes or alters a file, the file is logged in Receipts (though you don’t need it to duplicate entries), and if the app deletes a file, it’s removed by the operating system from the Receipt log. Finally, if two or more apps modify or read the same file, it’s entered into both of their receipt logs independently.

That’s the operating system backend. The front end would be a “Receipts Manager” app that Apple would include with the other Apple utilities. It’s function would be to consolidate the data from all the receipts in the system and user libraries.

So how would all this work from the user’s point of view?

  • Installation is unchanged: apps are bundled folders, there are no “installers”
  • Uninstallation of an app is unchanged: drag it to the trash; support files/prefs/etc. remain in place. This means that people can do manual upgrades just as they do today, or can trash the app and reinstall it without losing preferences.
  • The critical difference is that all the support files are logged as being associated with a given application (in a simple text file, not a monolithic registry). The receipts manager would allow you to view all the files (in, e.g., Library, not Documents, etc.) logged as associated with a particular app. You could then have several basic actions:
    • delete all associated files for AppX
    • delete all associated files for AppX within the user’s home folder, or just the system level, or another user’s home folder (dependent on user’s administrator status)
    • don’t delete files that are listed on two or more applications’ receipts. This is critical for avoiding “dependency” issues where multiple applications rely on a common file (e.g. Microsoft Office apps). Using a Receipts Manager program to consolidate all the different apps receipts and cross check for common listings is the key here.

This system wouldn’t be perfect, but it would seem to address some of the Mac method’s deficiencies, while still steering clear of the horrible Window’s system where everything requires an uninstaller. The apps are the same as today’s, but the operating system now bothers to keep track of where they put things.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: