The cost of bad installers
I’ve spent a lot of time lately at my “real” job setting up new Mac Pros. That’s required me to install Adobe CS3 on these machines and run the various updates. My antipathy for Adobe’s installers has been previously documented. But there’s more to this disdain than just inconvenience.
For most people, a less-than-optimal installer is something they think of only once when they first install the application. Once that’s done, then so’s the installer, unless something goes wrong, forcing you to reinstall an application. Of course, that line of thought ignores a rather significant issue—updates. Whenever we update our installed applications to fix bugs, or—more important from my point of view—plug security holes, the installer comes into play.
Any installer—even a really bad one—is not a huge problem if you only ever install it on one machine. Oh sure, it’s annoying, but it’s one machine. It’s when you have to install that same update on ten machines, or 100 machines, or 1,000 machines that annoyances for a single instance become major problems.
If a developer does an installer correctly, there are real benefits on a network, besides not annoying the user. First, a good installer is usable with a wide range of tools. For example, on a network of Macs, if I have an installer that is either a straight file copy, or an Apple Installer, then I can use nearly any tool I want to distribute and run that installer on multiple Macs on a network. Apple, LANRev, Casper, LANDesk, Radmind, home-grown scripts, whatever—it’ll work in a predictable fashion.
If I’m managing Windows machines, then the same is true for MSI installers. In my case, once I do whatever testing of the update is necessary, I just push it out with Apple Remote Desktop. Since I have a separate Apple Remote Desktop Task Server, if the update is an installer package, I can even push it out to laptops that aren’t connected because I know that when they do connect, they’ll get the update(s) automatically. Doing this with Apple Remote Desktop takes me four steps:
- Select the Macs I want the update to go to
- Drop the installer package on the Apple Remote Desktop Window
- Set restart and Task Server options
- Click “OK”
That’s it, whether I’m handling five machines or 50. If it’s a file copy, I follow the same process, only without the Task Server. What does this mean? Well, the biggest advantage is that the only delays in deployment are download time and testing time. When we decide to push a properly packaged update out, it happens really quickly. It means that security patches can get pushed out before someone gets attacked. It means that bug fixes get pushed out sooner rather than later. All of these are good things, contributing to increased customer peace of mind.
What happens when you have a bad installer? Patches don’t get pushed out as quickly. It also means that the administrator has to waste a lot of time dealing with a very manual update process that’s usually fragile or complicated or both, instead of working on other things. And it means that unless the administrator repackages the installer files, they can’t directly use the installer with their tools and have it just work.
Let’s take the desktop side of my network as an example. It’s a mixture of Intel- and PowerPC-based Macs, with more of the former. We’ll consider how various installer decisions affect my ability to push patches out in a timely manner, focusing specifically on the Adobe Acrobat and Flash updates since they cover the gamut of good and bad.
In this scenario, I have some machines that need Acrobat Pro 8 updated and some that need only Reader updated; all the machines need Flash updates. Like most networks, mine does not allow administrator rights for users on the machines, which means the responsibility for updates logically falls on those of us in IT. Using the built-in update feature for Acrobat Pro and Reader is the worst option, as it is completely manual. Even if I run it remotely, I’m doing the same thing almost 200 times. This is highly sub-optimal, to put it mildly. What I want to do is push out an update and install it on all these machines via Apple Remote Desktop, our current management tool of choice.
But Adobe has made some decisions with its installers that prevent me from doing that. With the exception of Acrobat Pro, the installers are architecture-specific. Both Flash and Reader have PPC and Intel versions of the updater. That means I have to create separate groups by architecture in Apple Remote Desktop and then separately deploy the updaters to each. That’s more work, further delaying installation of security patches. Adobe’s Flash “Intel” updater says “Universal Binary,” but there’s still a separate PPC version. Do I gamble that the Intel updater works on both architectures? No, because gambling tends to make life interesting, and as an IT administrator, I dislike interesting. Acrobat Pro is the class of Adobe’s installers by this measure, since there’s only one updater; theoretically, I can push it out to any of my Acrobat Pro users’ Macs.
What about the installer files themselves? Well, Flash, in spite of its Universal-or-just-Intel updaters, does well here. The PPC update files are the plugin and the .xpt file. That’s just a file copy, and a reminder to users to restart their browsers once it’s done copying. I can’t use the Apple Remote Desktop Task Server, but, that’s a minor issue. The “Universal” updater is an Apple installer package, and Flash gets a win here. I select all my Intel Macs, drag, drop, set a couple options, and go. Then I send some messages/e-mails to users as needed, and I’m done. Since I can use the Task Manager for this one, I don’t even have to remember to keep an eye out for users who were off the network: they get their updates with as little delay as possible. Security holes are plugged, bugs are fixed in a timely fashion, and everything’s good.
Adobe Reader 8 however, is full of fail. First, it’s architecture-specific. Secondly, it’s using some custom compression engine from NOS Microsystems, so the only way I can deploy this thing without doing it manually on every machine is to install it on one Mac manually, repackage it as either separate files or an Apple Installer, test out the repackaging, then distribute it. Oh, and I have to do this twice, once for Intel, once for PPC. Same thing for the Acrobat 8 Pro Patch, without the separate PPC/Intel versions. Either way, Acrobat patches take far more work than they should.
As a result, Acrobat patches don’t get deployed in as timely a manner as the Flash versions, because they cannot be “properly” deployed. Since these are security patches, that unavoidable additional delay is A Bad Thing. It’s not the users’ fault. It’s not my fault. It’s the fault of a person or committee who didn’t think enough about what happens when someone has to push these out to hundreds of Macs. To its credit, Adobe seems to be learning. The Adobe Reader 9 installers are proper Apple Installer packages, even if there are still separate Intel and PPC installers.
If that trend continues for Reader 9 updates, then the inane amount of extra work that IT administrators have to deal with for Reader 8 goes away. Adobe abandoning proprietary “Adobe only” installers and using the native installers for the platforms they support means that the Adobe product teams can count on a radically smaller delta between patch release and patch install. This doesn’t just apply to Adobe, mind you—the same thing goes for every other software vendor. While people complain about a lot of things with Office 2008, the fact that the Mac BU is now using Apple Installer packages is something I was rather overjoyed about.
I get the impulse to use custom installers. They allow developers to do things their way, not the way some OS platform engineer or sysadmin thinks they should. And after all, developers know better than OS vendors and sysadmins since it’s their product and their customers, right?
While it seems picayune to those who don’t deal with it on the scale I do or on the far larger scales some of my friends do, making installation and updates harder, different, or more annoying is never a long-term win. Yes, it’s frustrating waiting for Apple or Microsoft to update their installer mechanisms for something you really want. But that’s not a reason to inflict an installer that works with nothing on someone just trying to keep a few hundred or a few thousand machines up to date in an organized fashion. That’s not a reason to create an even more complicated workaround for the non-standard installer so that developers don’t have to abandon it. That’s not a reason to leave customers and users at risk to actual harm just so developers’ lives can be easier. Software companies need to realize: It’s not about you, it’s about us—the people who pay for, and/or use your software, and the people who support those users.
It’s about making things work the way we need them to, so that when a company distributes a patch for a major security hole, we can install it on hundreds or thousands of those customers’ machines within hours, instead of days or weeks. It’s about helping us, your customers, be safer.
If that’s not enough impetus for Adobe, and every other company in the Mac and Windows market to stop playing custom installer games, then I have no idea what is.
[John C. Welch is a senior systems administrator for The Zimmerman Agency, and a long-time Mac IT pundit.]