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.
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.
11 comments
[ 3.5 ms ] story [ 31.8 ms ] threadServer-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...
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.
http://lwn.net/Articles/359939/
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.
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.