The four essential laws of software updates | Hacker News Reader

The four essential laws of software updates

philltopia.com

14 pointsphilltopia17 comments

Why is this necessary at all? Why does every program have its own updater, some of which are even resident? Why can't the OS just do all of this for us? Linux and the BSDs have package managers, but there's a solution just as easy for the rest/majority:

Both Microsoft Update and Apple Software Update could be modified, very simply, to read updates for additional software from signed RSS feeds, and queue them into a background downloading service (on Windows it's called BITS, I'm sure OSX has an equivalent) when they see them. There would need be no central repository; each software package installed would simply install a subscription, and a public key for checking against it. The updates would all be installed in the operating system's "update mode" that starts after shutdown, negating any worry of updating a running program. It wouldn't even need to trouble the download centers themselves—the RSS subscriptions could be torrent containers, and every PC could be configured to serve as a peer.

Now, if it were me, I'd move the Mobile App Store from iTunes to Software Update on OSX and make it into a Multi-platform App Store, and create a similar store for Windows in their own update service... but that's perhaps, as they say on the Internets, "too much win."

... could be modified, very simply, to read updates for additional software ...

It's only so simple when you have a single binary file with no dependencies running only on the developer's machine.

Beyond that, it's quite a complex problem. I could give you a list of about a thousand major problems that need to be solved to make a "one size fits all" updater. Plus, it's not in the self interest of either Microsoft or Apple to allow update installation from unverified sources.

... similar store for Windows in their own update service ...

The store has been tried before (once by MS, many many times by 3rd parties). Each time it was a failure. Largely due to the uncoupled nature of the "Windows ecosystem".

Sparkle (http://sparkle.andymatuschak.org/ ) seems to be becoming a de-facto standard on OSX, and I'd say it does a pretty good job when judged against the points in the article.

I think the update-at-shutdown isn't such a great idea, most programs don't need the computer to be restarted after they update.

Sparkle is just awesome - and I really wish Apple had the guts to roll this sort of thing (if not simply roll Sparkle in) as a standard recommendation for all apps.

The problem isn't so much that apps are rolling their own updaters, it's the fact that these updaters are often extremely heavy-weight but aren't justifiably so.

I actually agree with you, completely. Many times I've wondered why we need this complex, inefficient mess of individual programs doing what a central system could do better.

But nonetheless, for now that's the way things are. Might as well do a good job in the meantime.

Disclaimer: I'm a newbie blogger and member of HN (though I've been reading it for a while, I just joined a week ago). But any comments, criticism, or advice you might have are all definitely welcome. Thanks!

An OK article. But if you have seen most good usability and UI design texts, they cite actual applications. You have your own, prototype, "hopefully not your application" dialog boxes as examples. If you can't find real-world examples of the problems you're fixing, maybe they're not that big of a deal? (which they ARE, you just haven't been researching this long enough, I am guessing.)

I clicked on the link hoping to find technical information on automatic software updating, like:

http://www.cl.cam.ac.uk/~pes20/update-popl-2005.pdf

http://citeseer.ist.psu.edu/old/hicks01dynamic.html

It's not that I didn't have anything in mind (I did, and, in earlier drafts, used some), it's that I felt this got the point across faster and simpler. Using the examples I gave and real-life screenshots felt too much like flamebait for my taste. I definitely see your point though.

That's OK, welcome to HN and I would love to read you next article.

Cheers!

My company develops an updater/patcher. The updater is open source (wyUpdate) and the update creator is commercial (wyBuild).

You make a few good points in your post. We get a lot of customers trying to solve the very problems you describe. Auto updating in particular is an exceedingly hard problem to solve.

Besides all of the immediately obvious technical considerations (Self updating, inter-process communication, update rollback on failure) there are many problems that developers don't think about until it's too late (admin rights, Vista/7 UAC).

You might be interested in the series of posts I've been writing on creating an updater from scratch: http://wyday.com/blog/

Oh wow, it looks like you've written a lot of what I did already. I guess I should have searched more deeply before I wrote this. :P

Did you mean "few" or "a few"?

Oops, typo. I meant "a few".

Law Five: Finish the job - Hopefully not your program: "Update has been downloaded. Have fun installing it. Bye!" - Dunce: Wordpress

Law Six: Stay alive - Hopefully not your program: "Software updated. Go have a coffee while I tear down all your work and restart myself." - Dunce: Firefox, Windows

Law Seven: Get with the times - Hopefully not your program: "You can't install that, it's brand new! Play it safe and use this two year old beta with many known vulnerabilities." - Dunce: Ubuntu

(I gave up on the formatting, sorry)

Wait, what's wrong with Wordpress's update mechanism? I've only used it for a short while but I've been nothing short of amazed how simple and easy it is (two button presses), compared to years of downloading packages, diffing files, uploading files, running database upload scripts, fixing errors, and so on under phpBB/IPB/MediaWiki.

So it does. Somehow I missed it when trying to upgrade a friend's blog.

A good reason to make sure your nightly (or whatever) build process generates deliverable installers as early as possible, and then conduct all deployments (test, demo, beta etc.) via these installers. Stress points soon get removed.

Throwing a finished executable over the wall to some poor sod at -1 week away from ship date may deliver a poor experience.

Essential laws?

Reply on news.ycombinator.com