Posted Oct 31, 2011 16:58 UTC (Mon) by khim
In reply to: Bwahahah
Parent article: The embedded long-term support initiative
So updating set-top boxes in a closed environment is a significantly different (and easier) problem to a general "update Linux on any embedded device".
Sure. But my point still stands:
1. It's possible to safely upgrade software in a device.
2. People tolerate updates just fine as long as they "just work".
3. Reversions, bandwidth requirements and changelogs don't affect acceptance at all.
3a. As you've noted people rarely care about bandwidth, but they do care about money spent on bandwidth. This is different - and solveable - problem.
Some set-top boxes have an architecture where they keep two copies of the system software so they can revert to the previous version if it all goes wrong.
Sure, but this is the same approach ChromeOS is using. This is mereluy detail of upgrade mechanism implementation which makes it more robust. I've never seen a set top box which allowed you to arbitrarily select one of two version of software to boot. Sometimes it can be accomplished using some combinations of knobs, but it's usually part of "recovery procedure", not something end-user is supposed to do.
When (and if) btrfs will be mature enough snapshots can do the same with smaller overhead.
to post comments)