Earlier this month, Mark Pilgrim wrote about his experience with Linux for a year, after switching away from the Mac. (There was a bit of a furor in various Mac weblogs regarding some of the reasons that Pilgrim decided to switch; Daring Fireball has a good commentary on the whole shebang.)

Pilgrim, in his one-year roundup, wrote primarily about one of the big things that he liked about Linux over Mac OS X: he can easily update all the installed software on his machine with one single command -- open source software, including both the operating system as well as third-party applications, often use the same package manager, meaning that you can easily search, download, and install all updates for your entire system, all from one command-line utility. That's powerful.

And it's true, there's nothing like it on the Mac. Sure, there's Software Update for the operating system and for Apple applications, but beyond that, you have to deal with manually downloading and installing updates yourself, or relying on each application's update mechanism. As far as I know, things are similar on the Windows side of things.

The problem with catch-all software updaters is that they have to be implemented from the bottom up for it to be viable: developers have to support software update mechanisms in their software themselves. Otherwise, you get well-meaning projects that attempt to scan your hard drive for installed software, attempt to ascertain their version number, attempt to find each correct download URL, and then attempt to correctly download and install each application. And then, of course, as a user, you're subject to the project running out of steam, or the website backbone of the software going down, in addition to all the myriad problems that could happen along the way. I've seen a large number of these come and go, and I've even paid a few bucks for some of this software; the software is never very satisfying. (I believe VersionTracker and MacUpdate, the two major websites that track new software releases, both have software that takes this approach; I used the precursor to the MacUpdate software.)

That's why the Sparkle update framework, originally created by Andy Matuschak, has been gaining a lot of steam. (TuneTagger uses it, and I plan to migrate all of my other software away from my home-grown software update mechanisms to Sparkle.) It's not software that attempts a top-down approach to software updating, it's a framework for developers that allows them to quickly and easily add software updating to their own applications.

Sparkle isn't subject to the problems that the MacUpdate and VersionTracker software is. Each piece of software knows exactly which version is installed and the latest version to install. It'll know the correct URL from the appcast, since they're created by the developer. And individual developer websites may go down, but you can still install updates to other software. (Besides, you wouldn't have been able to download and install the update manually anyway given that the developer's site is down.) Props definitely go to Matuschak for creating such a useful framework.

(The only other framework that matches the widespread adoption of Sparkle is the Growl framework, which standardizes app notifications, with the obvious exception of Apple applications. This caveat doesn't apply to Sparkle, since Apple's applications already have an update mechanism.)

But while Sparkle is nice, it only addresses part of the problem. Sure, Sparkle could eventually morph into a mechanism that will update all your software at once rather than relying on individual apps to do it themselves. But the framework only applies to users. What about administrators who want control over which updates are installed, when they are installed, and on what machines? More problematic is having to deal with the bandwidth issue: if you want to update a given application on a lab of 30 computers, Sparkle will cause a download to be initiated on each and every one of those machines. Not ideal.

As it exists now, Sparkle can't solve any of these problems, but it has the potential to do so. I can envision each Sparkle-aware app registering themselves with the general Sparkle update application (much like Mac OS X applications do to take control of specific file types or extensions). Then when you want to update your software, just launch the Sparkle app, and all registered apps will go through the update process much as they already do, but without the need for the application to be open to realize that it needs an update. A command-line tool could be created to interface with the Sparkle application, and then you could interact with Sparkle via Apple Remote Desktop simply by issuing UNIX commands. (This last part is key for allowing admins to manage software updates through Sparkle.)

That's basically how the Apple Software Update mechanism works, with a few extra goodies thrown in. When I want to update the lab of 30 Macs at the elementary school where I worked, I would just fire up Apple Remote Desktop and send the UNIX command "softwareupdate -i --all". Very simple. Mac OS X 10.4 Server even caches all updates from Apple's main software update server, and then when a client needs an update, it fetches it from your local server, not Apple's main server. This dramatically cuts down on download time and bandwidth usage.

A potential Sparkle Server could do the same thing -- although I would imagine that you would only want to cache those updates which you have already downloaded once, instead of caching every single update from all time. That would require quite a bit of space. Or it could scan client systems and pre-download updates for any Sparkle-aware software on those systems.

The other problem is that Sparkle currently only works for applications. What about preference panes, or device drivers, or input managers, or contextual menu items? The roadmap for Sparkle indicates that a client-side updater and support for bundles are both slated for the 2.0 release. But Sparkle is currently on version 1.1, with a 1.5 release also projected in the interim between the current version and 2.0, and no projected release date for the magical 2.0 release.

Nat posted a comment regarding Sparkle back at Pilgrim's year-in-review entry. He writes:

As a sysadmin responsible for about a hundred Macs, Sparkle doesn’t help me address the problem. Users who lack admin privileges (the majority) can’t update software installed centrally, and users who are admins or who install things in ~/Applications can run widespread updates at inconvenient times of day, degrading office bandwidth.

I’d like to be able to mirror updates on our local network the way I can with Apple’s software update server in OSXS (at least for 10.4 clients; our remaining 10.3 clients have to be coddled). Drag-copyable updates like Firefox are manageable with some creative Apple Remote Desktop scripting. Installers like Office that require manual intervention get deferred, sometimes indefinitely. It sucks.

Obviously, he's not alone in wanting a solution to this massive problem.

And yes, it is a massive problem. He mentions Office. Oh god. Oh god. The HORROR. Yes, as usual, it's Microsoft to the rescue from an altogether pleasant dream about the future of Sparkle.

Let me tell you about the absolute joy it is to upgrade Microsoft Office.

See, when I want to update an application for a lab of 30 Macs, I don't want to use the auto-update mechanism, chiefly because it's impractical to download the same update 30 times over. At the elementary school, not only would it sap the bandwidth if all 30 downloads were done at once, but even an individual download of the 50 MB updater still takes about five minutes or so. I also need to perform all the updates all at once and without any interaction so that I can issue the update and get on with my day, without babysitting each and every installer.

So I go to the developer's website (in this case Microsoft's) and download the latest update to the software. Surely I can download the installer, copy it to all the 30 client Macs, and then launch them, right?

Well guess what? That latest installer you just downloaded? It's not a combo installer. You'll have to get the previous version downloaded and installed before you can install this one. This is true, for example, of the Office 2004 10.3.4 update as well as the Office 2004 10.2.6 update. I can remember at least one case where I downloaded the latest version, which required the immediate previous version, which itself required me to download the version previous to that. Only if you are blessed with one of the more significant updates do you get a combo installer from Microsoft.

Microsoft's updates are also VISE X installers. Unlike standard Apple installer packages which can be distributed easily via Apple Remote Desktop, these things require manual interaction. You have to copy them to each Mac, open them on each Mac, put in the administrator login and password on each Mac, click "Continue" a couple times on each Mac, wait a minute and a half for each installer to verify that the previous update has been installed, and then delete the installer from each Mac once it's done installing.

You have to do this process for each installer. Remember that installers from Microsoft often have dependencies, which means you might have to go through this process twice or three times for each machine. It's precisely because of these horribly-designed installers that I hardly ever installed Office updates unless there were problems, just like Nat apparently does.

I also had a similarly enjoyable experience with, no surprise, an installer from HP. The elementary school has a large-format poster printer that requires a specialized printer driver installed on each Mac that wants to use it. It, too, uses a VISE X installer. The twist on this one is that HP's installer brings down a sheet that extolls the virtue of the printer you already bought, and requires you to click on an extra button to dismiss the sheet. I was attempting to create an AppleScript that used GUI scripting to automate the installer process, and of course this annoying sheet stopped me in my tracks, because the normal method of clicking buttons via GUI scripting didn't work for this one fucking button on the sheet.

For any of you other sysadmins out there, here's a hint the next time you need to mass-deploy VISE X installers. They actually have a scripting dictionary; somehow I stumbled upon this when I was frustrated. You can run a script via Apple Remote Desktop along the lines of:

tell application "Office 2004 11.3.5 Update"
        DoInstall
end tell

where you replace the application name with the name of your installer. This will immediately start the installation process, bypassing all the intermediate screens that you usually need to click through before the installation will start. You'll still have to manually copy each updater and launch them via ARD, and you'll still have to manually put in the admin password for each, but it at least makes deploying VISE X installers tolerable.

I actually approached the VISE X developers about this at MacWorld 2007. They said they've heard requests for direct support via Apple Remote Desktop, but they have no plans to implement such a feature anytime in the future. *sigh*

Unfortunately, I don't foresee situations like this going away anytime soon. Sure, Sparkle is great for indie Mac developers, but it doesn't do anything for sysadmins at this point, and good luck getting large corporations like HP or Microsoft to adopt the framework. Maybe if Sparkle really got some huge momentum behind it, but I'm not holding my breath.

It's very frustrating, too, because Apple's installer packages offer everything a developer needs to deploy their software, and they're mass deployable via Apple Remote Desktop. Why do VISE X or FileStorm installers (that other annoying type that doesn't tell you where files are being installed) exist anymore? Are there real advantages that they offer over Apple's packages, or is it yet another remnant from the Classic Mac OS days, like StuffIt?

As an administrator and as a user, a one-line command that updates every app on a single client (and that could conceivably be issued to multiple clients at once) is very appealing. So I can see why Pilgrim doesn't seem to have any qualms over his recent switch to Linux.