22 Feb 2008

Application Installation 101

Just having switched back from OS X to Windows, or rather unswitched, as I installed a couple dozen applications it struck me how much more streamlined the process is on OS X. More often than not, you just drag a .app file to a folder on the hard disc, and you're done. All dependencies are in the package itself. The best installation procedure is one that doesn't exist at all. Would you like it if you download a PDF file and you're about to view it, but, no, wait a minute, you can't -- you have to go through an involved "installation" process before you can open it. Same is the case -- you want to run an application, and the OS should get out of the way and let you do it right away without further ado. Anything else is Bad Design.

On Windows many installers ask you whether to put an entry in the start menu, and where. And I have to go back and move the start menu folders outside the Programs folder. In OS X, there's no need for a start menu to manage -- your applications folder is so clutter-free that you can use it as a menu of applications. This is because apps appear as individual files (bundles) that launch when clicked. After all, what's the most common thing to do to an app other than to launch it? [1] Since the applications folder is so clean, you don't need a separate hierarchy of shortcuts to applications. Which also means there's no start menu to manage or questions to answer about where you want shortcuts created. And if you want to organize applications, because they're self-contained, generally you can just drag the .app file to a different folder without breaking the app.

As Paul Graham put it:
What would Apple's next product look like if you replaced Steve Jobs with a committee of 100 random people? Windows.

The Linux people blow it, as well -- I don't want to deal with a package manager. There's already a way to organize files, and it's called the filesystem. I want to "install" an application the same way I "install" a PDF file -- copy it to the filesystem. Don't make me go through a different process. And what if the app you want to install doesn't exist in your distro's repository? That has happened to me more than once. Or it exists but is called something else because of some idealogical or political storm in a teacup that you care nothing about? Besides, package managers sometime get into an inconsistent state where they demand you repair them before you do anything else. And sometimes the repair doesn't work. Not to mention that in the grand Linux tradition of fragmentation, different distros have different package managers, which means knowledge you pick up on one distro doesn't serve you on another. This is a problem with the whole idea of multiple distributions, but if application installation did not use package managers, you wouldn't have to deal with differences between them.

The open-source Unix argument here seems to be to eliminate duplication of files, but I'd much rather solve the problem with more memory and marginally more disk space. In fact, that may be part of the reason the Linux approach is bad -- they optimize for the wrong thing -- system resources instead of user experience. [2] But then, since when is Linux known for a solid user experience?

On OS X things work so smoothly that you don't realize how much better it is till you start using Windows or Linux.

[1] There's also a Show Contents option when you need it.
[2] Maybe that's an artificial tradeoff to some extent -- with ZFS, since files are checksummed, duplicate copies of libraries in different applications can be merged on disk, and the OS can use the checksum to load only one copy into memory. But even otherwise, I'd much rather install more memory than "install" applications.


  1. Babau8:25 am

    I agree with you to an extent here. I can definitely see the day coming where programs no longer have dependencies and don't need to be installed. Storage is getting cheaper and cheaper after all. Bandwidth, however, isn't quite there yet. I'm not real keen on spending my expensive Australian bandwidth on re-downloading the same lib that's been baked into a bunch of different packages.

    Also, there are still plenty of use cases where storage is very finite. I have an original 701 eeepc, for example. With only 4 gigs of storage, space gets pretty tight, and you start to appreciate the Linux paradigm of "reduce re-use and recycle". Consider mobile phones, too.

  2. That's an interesting perspective.

    I wonder if it's possible to eat your cake and have it too -- the server hosts an .app file (that contains all the dependencies in one file), but the client, instead of downloading the whole file, first reads the ToC (http partial content [1]), and then downloads only the files in the bundle that it doesn't have. After download, the other files become symlinks to copies that exist elsewhere on the system. Though it would be better if the filesystem supports copy-on-write so that if one app is deleted, etc, the other isn't affected.

    If the server (or an intervening proxy) doesn't support http partial content to download parts of an .app file, the server can explode the bundle into several files and serve these instead. Either way, the client can download a ToC file that lists what dependencies this bundle contains, with hashes and download URLs.

    In any case, this solves the combinatorial explosion problem -- if there are M packages and N distros, there need to be MxN instances of the package. Which means that if I come up with a new app, I have to work with the maintainers of all the dozens or hundreds of existing distros. And there will always be some apps that are left out of distro X, and some distros that don't have app Y. Maybe the ideal is for a package manager to just consist of a box where you type in the URL of an app, and it downloads necessary parts of the app as I described.

  3. babau6:18 pm

    I lack the technical knowledge to discuss a copy-on-write system, but if it can overcome the issues involved with deleting the pseudo-dependencies that would be created then yeah, sounds like a really elegant way to do things.

    Personally I've never had much trouble with things being unavailable for my distribution. There are plenty of .debs around, and anything that has an rpm can generally be converted with alien. Works for me.