Notice:

This page has been converted from a dynamic Wordpress article to a static HTML document. As a result, some content may missing or not rendered correctly.

A Package Management Comparison ~ Sun, 28 Mar 2010 16:17:44 +0000

This post is about application installation and management on Mac OS X. I know someone who is about to make their first Mac purchase (at least since OS X was released). I think they will find this information useful.

As we all know, almost all applications for Microsoft Windows are installed via an installer application. It is mostly a process of blindly clicking a "Next" button until a progress bar shows up. Once the progress bar is done a "Finished" button is clicked and then you can start using the program. We will call this method (A). There is a less common way to install Windows applications. This second method, (B), is much easier. You simply put the program somewhere on your file system. A good example of this type of installation is the PuTTY terminal emulator.

Each method has its plusses and minuses. Method (A) is rather arduous, and you're never quite sure what it is doing to your system. All you really know is that the program is most likely being installed to the system "Program Files" directory, of which there are two for 64-bit Windows. Method (B) is totally transparent in regard to its installation. The trade-off comes when you want to remove the installed program. Method (A) typically provides an uninstaller, or at least a hook into the system-wide uninstaller, that cleans up the program and any files it has created (in theory). Method (B) may seem simple, just delete the program, but what about the files it has created? You have to delete those yourself. This can be difficult, especially since the program likely stored all of its settings somewhere inside the Windows Registry.

OS X actually shares methods (A) and (B) with Windows, except the prevalence is reversed. On OS X, method (B) is the most common. Before I continue, I need to explain a bit about OS X's Unix history. On a Unix operating system program binaries and resources (help files, images, etcetera) are installed to very specific directories. For example, the program <a href="http://www.jedsoft.org/most/index.html">most</a>, a pager, has a binary in /usr/bin and documentation in /usr/share/man on Arch Linux. Since OS X is based on a Unix derived operating system, it uses a lot of the same structure.

Most OS X programs that a typical computer user will install don't need to install their resources to system directories. So almost all OS X programs are packaged into a ".app" (known as an Application Bundle). This .app is merely a directory that contains the program binaries and resources. So if there were a Microsoft Paint-like application for OS X it might be named "Paint.app". When a user double clicks a .app they do not see the contents of the directory. Instead, the named program is launched. This leads directly to method (B) being the most common, and preferred, way of installing applications on OS X.

However, there are a few applications, like NeoOffice, that use method (A). Typically, these programs only install a .app to the default OS X applications directory, /Applications. There are a few rare applications that install other files. Usually these are programs that have to install a system driver (kernel extension).

So far this all sounds very similar to Windows. There are some key differences, though. Since OS X is a Unix derivative, it inherits some common path conventions. As I mentioned, OS X's default program (for GUI programs) directory is /Applications. This is where you will find all of Apple's programs like Mail.app, iPhoto, and iChat. So /Applications is where one would install programs that any user of the system should be able to use. But anyone familiar with a Unix-like operating system should know that that isn't the only option. It is entirely possible to create your own personal file system within your home directory.

For example, let's say you have two users on your Mac: yourself and a spouse. Let's assume that your spouse only uses the applications shipped with OS X and couldn't care any less about third party applications. You, however, like to use Camino for web surfing and Adium for instant messaging. Instead of installing these applications, which are installed via method (B), to /Applications and annoying your spouse, you can install them to an "Applications" directory in your own home directory (the equivalent of ~/bin on a traditional Unix system). This way, you have the applications you want installed (and you didn't have to have administrator privileges either) without affecting any other users on the system.

There is, however, a problem, and it is the same problem that (B) had on Windows. Every program you use has to store settings somewhere so that the next time you use the program it behaves as you told it to the last time (e.g. always show the tab bar in Camino). These settings are not stored in the .app, but are instead stored ~/Library/ and/or ~/Library/Preferences/ (where ~ = /Users/your_user_name). When you delete a program from ~/Applications these settings files are not removed. In fact, if you install an application on OS X via method (A), and it included an uninstaller application, these settings files are not removed. Typically, these files are very small and can be ignored. But if you really don't want these files on your system, it is annoying to have to remember to track down these files and remove them.

Here's where OS X outclasses Windows (yet again). There are a couple common conventions used to create these settings files:

1. Most application settings use a system API NSUserDefaults to store basic preferences, and almost every third party OS X developer will have read the Apple tutorial, or the discussion in Cocoa Programming for OS X (awesome book). Therefore, most application settings will be stored in a file in `~/Library/Preferences` that is named according to the developer's website. For example, let's assume you downloaded SuperApp from SuperSoft's website at example.com. SuperApp's preferences would be stored in `~/Library/Preferences/com.example.SuperApp`.
2. Sometimes an application needs to store more than the basic settings than NSUserDefaults is designed to handle. This is when an application would use a whole directory in `~/Libary/`. Chances are pretty good that this directory will be named the same as the application. So SuperApp could have settings in `~/Library/SuperApp/` as well. But maybe SuperSoft has more than one application so they decided to keep things a little cleaner. Then SuperApp could have settings in `~/Library/SuperSoft/SuperApp/`.

So, we have a fairly common system for storing settings. This makes finding settings an a per application basis somewhat easy. But we also have an even better tool at our disposal than sheer intuition -- Spotlight. As each application is writing its settings files, Spotlight is indexing them. This means that we can use Spotlight to find files in our ~/Library/ directory that are associated with any of the applications we use. But, again, this can be tedious. And we are not the first ones to notice this problem. Thus, several third party applications have been written to remove applications on OS X.

1. For applications installed via method (A), and do not include a separate uninstaller program or have one built into the original installer, there is DesInstaller3. However, this program has not been updated in quite some time and has always been a bit flaky. This sounds like an interesting project to work on.
2. For applications installed via method (B), there are several options. Three of them are AppCleaner, AppDelete, and AppZapper.

Hopefully this post clears up any questions you might be having about how to manage packages on OS X. Personally, I find package management on OS X to be the easiest to use when installers are not involved. I try to avoid applications that use an installer, and applications that use an installer for no good reason make me quickly look for alternatives.

I like keeping applications in my ~/Applications/ directory, and sub-directories within that, because it makes migrating to new installations easier. Almost everything I need on my Mac is stored in my home directory. Give it a shot, I'm sure you'll like it.

I also prefer the Application Bundle method of distribution to the way packages are distributed in Linux. Sure, distributions like Debian and Arch Linux make it easy to install and remove applications that are tracked in their repositories. But I think it is even simpler to have everything, except system libraries, that an application needs to run contained within one parent directory that pertains specifically to that application. It just makes sense.

Note about this post: I wrote half of this post July 5, 2009 and didn't get around to finishing it until now. Halfway through writing it I was unsure if I actually wanted to post it. But a recent post by Ben Simpson made me want to complete my article.

Linux,  OS X,  Package Management,  Technology,  Windows

Comments