Reinventing the Upgrade Wheel

The internet is a hostile place. Viruses, worms, and worse are constantly trying to break or break into your computer. Software developers are constantly fixing the holes that can let them in. It’s become critical to keep your system up to date. Unfortunately this can be very frustrating, even for a power user, for one simple reason: you have to keep track of each program individually.

Sure, the operating systems have their own centralized places. Microsoft has Windows Update, and Apple has Software Update. But every application that exposes itself to the network directly or opens untrusted files has to be updated, and there are many that aren’t part of the operating system.

So Symantec has Live Update. Real Player has its own updater. iTunes and QuickTime for Windows can update themselves. Adobe Reader has an update function. Firefox is redesigning its update system. Games check for updates when they connect to the network.

But wouldn’t it be nice if Windows would grab the Acrobat updates overnight, instead of waiting until the next time you launched it? Wouldn’t you like to be able to patch everything on your system at once and just not worry about it? As a software developer, wouldn’t you like to be able to let someone else deal with the update problem instead of re-inventing the wheel yet again?

It turns out that Linux has the edge. Because most of the software used on Linux platforms allows redistribution, a lot of applications can be included with the operating system. And because they’re included with the OS install, they can be updated along with it.

More importantly, the major Linux update systems, Apt and Yum*, are extensible. For several years projects like FreshRPMs have created repositories of third-party software. If you’re a software developer, you don’t have to wait for Red Hat or Debian. You don’t even have to wait for FreshRPMs. You can tell Yum or Apt where to find updated versions of your program. Now, when your customer updates his system, he gets your updates too.

In theory, this should be possible on Windows or Mac as well. Developers should be able to make a deal with Microsoft or Apple to get their software included in the system update channels. To date, I haven’t seen anyone do this but driver manufacturers. Maybe neither company is offering.

But wouldn’t it be nice?

*The same may be true of YaST, URPMI, and Portage, but I’m less familiar with those.

3 thoughts on “Reinventing the Upgrade Wheel

  1. Pingback: Apple Software Update: a Simple Solution | K-Squared Ramblings

  2. Chris Quirke

    The problem is with the “ship it broken, fix it later” mentality. You have 50 vendor’s sware installed; do you have 50 different updaters? What about scumbags like Apple, who shovel unwanted software as “updates”?

    So you suggest having an OS updater that also pulls updates from an unbounded set of “software vendors”. What’s wrong with that picture?

    The risks of having your code base changed at the whim of software vendors is two-fold.

    First, by definition, a vendor that has to push fixes is a buggy vendor. If buggy code is pushed out to the whole userbase within 24 hours, the result can be widespread system failures or other DDoS effects.

    Second, who is to say what is a “vendor”? How well do vendors protect their update systems against malware hi-jack? If malware enters any one vendor’s “update” channel, the result is instant mass infection that drills right through your defenses.

    When there’s a single OS update system that accepts “updates” from anything that calls itself a software vendor, the risk increases, because now there’s a single point of possible exploitation.

    Nope, the only real answer is to severely penalize software vendors who screw up. Let them carry the full cost of product recall, rather than get away with popping code on a server and expecting users to pull it down.

    That’s the only way you can definitively fix this mess.

    Reply
  3. Kelson Post author

    So how would these severe penalties apply to an open source project that has, say, half a dozen developers but no company? Are they individually liable? That would make getting involved in the process a bit risky, wouldn’t it?

    And speaking of open-source development, would a project/company be liable for every release, including unfinished versions pulled off of their publicly-available versioning system? Or only for “final” versions?

    We’d see a lot more perpetual betas, I think.

    Reply

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.