What is the experience with Google 'Omaha' (their auto-update engine for Chrome)?

Question

Google has open-sourced the auto update mechanism used in Google Chrome as Omaha.

It seems quite complicated and difficult to configure for anybody who isn\'t Google

Answer 1

An auto-update mechanism is something I'd personally code myself, and always have in the past. Unless you have a multi-gigabyte application and want to upload bits and pieces only, just rely on your own code/installer. That said, I've not looked at Google's open source library at all.. and didn't even know it existed. I can't imagine it offering anything superior to what you could code yourself, and with your own code you aren't bound by any licensing restrictions.

Answer 2

I've been using Omaha in various projects since 2016. The projects had between a handful and millions of update clients. Target operating systems were mostly Windows, but also some Linux devices and (via Sparkle) macOS.

Omaha is difficult to set up because it requires you to edit Google's C++ implementation. You also need a corresponding server. The standard implementation is omaha-server and does not come from Google. However, in return it also supports Sparkle for automatic updates on Mac (hence why I mentioned Sparkle above).

While setting up the above components is difficult, once they are configured they are work extremely well. This is perhaps not surprising given that Google use Omaha to update millions (billions?) of devices.

To help others get started with Omaha, I wrote a tutorial that gives a quick overview of how it works.

Answer 3

In the .NET world you might want to take a look at ClickOnce deployment.

Answer 4

Perhaps, you can leverage the courgette algorithm, which is the update mechanism that is used in Google Chrome. It is really easy to use and apply to your infrastructure. Currently, it just works for Windows operating systems. Windows users of Chrome receive updates in small chunks, unlike Mac and Linux users who still receive the chunks in total size.

You can find the source code here in the Chromium SVN repository. It is a compression algorithm to apply small updates to Google Chrome instead of sending the whole distribution all the time. Rather than push the whole 10 MB to the user, you can push just the diff of the changes.

More information on how Courgette works can be found here and the official blog post about it here.

It works like this:

server:
    hint = make_hint(original, update)
    guess = make_guess(original, hint)
    diff = bsdiff(concat(original, guess), update)
    transmit hint, diff

client
    receive hint, diff
    guess = make_guess(original, hint)
    update = bspatch(concat(original, guess), diff)

When you check out the source, you can compile it as an executable (right click compile in Visual Studio) and you can use the application in that form for testing:

Usage:

  courgette -dis <executable_file> <binary_assembly_file>
  courgette -asm <binary_assembly_file> <executable_file>
  courgette -disadj <executable_file> <reference> <binary_assembly_file>
  courgette -gen <v1> <v2> <patch>
  courgette -apply <v1> <patch> <v2>

Or, you can include that within your application and do the updates from there. You can imitate the Omaha auto update environment by creating your own service that you periodically check and run Courgette.

Answer 5

UPDATE

• Customizing google omaha isn't that easy espacialy if you have no knowledge about c++, python or com.
• Updates aren't published that frequently
  • crystalnix/omaha is managed by the community and they try to merge the main repo into their's; additional features are implemented and basic things are fixed
  • google/omaha is more active and changes from google are added but not frequently
• To implement manual updates in any language you can use the com classes

Resume

• google omaha is still alive but in a lazy way
• bugs are fixed but do not expect hotfixes
• google omaha fits for windows client apps supported from windows vista and upwards
• the server side I'm using supports also sparkle for crossplatform support
• feedbacks and crashes are also supported on the server
  • feedbacks are sent with the google protocol buffers
  • crash handling is done with breakpad

I personaly would go for google omaha instead of implementing my own solution. However we will discuss this internal.

Answer 6

We use Omaha for our products. Initially there was quite a bit of work to change hardcoded URLs and strings. We also had to implement the server ourselves, because there was not yet an open source implementation. Today, I would use omaha-server.

There are no regrets with ditching our old client update solution and going with Omaha.