Software Updates: Courgette (2009) | Hacker News Reader

Software Updates: Courgette (2009)

chromium.org

34 pointsgws11 comments

From 2009. Here's the blog post announcing it: http://blog.chromium.org/2009/07/smaller-is-faster-and-safer...

What happened to software patent litigation against Google concerning Courgette?

Good question. http://www.law360.com/articles/236158/google-dodges-injuncti... shows that in 2011, Red Bend did not get a preliminary injunction.

What happened after that is a good question. But https://bugzilla.mozilla.org/show_bug.cgi?id=504624 includes a comment dated 2013-09-24 12:57:04 PDT saying that things are sorted out, and Courgette can be used.

So apparently some sort of private settlement resulted with little publicity.

I was thinking the same when i saw Opera will be using Courgette for update too.

Is bandwidth really the limiting factor for updating desktop applications?

If you had asked me I would have guessed the limitation would be QA time. Surely they need to do some manual QA before pushing a release to prod, and surely that is more expensive than bandwidth.

That being said, it's a really cool project and I'm not at all arguing it shouldn't exist because it does improve the user's experience.

I think the argument is that users are more likely to be happy with software updating itself if the updates are un-noticeably tiny.

The end-user's bandwidth is the thing they're trying to save, not Google's.

Chrome has Chromium, canary, dev, and beta channels all of which act as a stage of manual QA.

I note there are quite a few recent commits with fixes to what could be security vulnerabilities.

e.g. Robust ELF header parsing, NULL pointer access, memory leak, undefined behavior.

So probably should update if you use it!

What is the bet someone has been stressing it with American Fuzzy Lop.

I wonder how useful this could be for large-scale server-side code deploys?

Courgette is a very CPU-intensive transformation. It pays a large time/space tradeoff to minimize bandwidth required.

Server-side code deploys are usually not so bandwidth limited.

Facebook used a BitTorrent-based approach for a while: http://arstechnica.com/business/2012/04/exclusive-a-behind-t...

Reply on news.ycombinator.com