Bwahahah
Bwahahah
Posted Oct 31, 2011 7:35 UTC (Mon) by khim (subscriber, #9252)In reply to: The embedded long-term support initiative by nix
Parent article: The embedded long-term support initiative
I wasn't trying to argue against proper update mechanisms, with reversion and non-insane bandwidth requirements and maybe even *gasp* a changelog you can see as the download happens.
It's not even funny. When geeks start talking about "proper update mechanism" they invariably raise insane requirements which are totally pointless and useless.
Most people encounter "almost perfect" update mechanism (with almost 100% updated devices!) every day and don't even know that. Where are these devices? How come noone talks about them? Well... why should they? They "just work"(tm) - and that's enough. And people cheerfully keep then up-to-date without any complains!
Heresy? Fantasy? Nope. I'm talking about your cable TV set-top box. These are quite complex devices novadays (with built-in browser, the ability to write and replay TV programs, etc, etc). They are regularly updated (when TV company decides to sell you new capabilities) - and people rarely complain.
Note: no reversion mechanism, no "sane bandwidth requirements" and no changelogs. Just two things are required:
1. It must be invisible (i.e.: update is pushed not when it urgently needed but slow and steady - this way bandwidth requirements are hidden).
2. "It must work"(tm): if update goew haywire then it's not something user should fix somehow, this occasion should be treated the same way power brick explosion is treated (and it should happen rarely - like power brick explosions).
ChromeOS updates are decent imitations but sadly they are not as robust for now...
Posted Oct 31, 2011 15:50 UTC (Mon)
by aginnes (subscriber, #81011)
[Link] (3 responses)
It's a lot easier for the set-top box software to be tested before it is downloaded, plus they own the broadcast bandwidth, so they can use as much as they want. The cable (or satellite, or IPTV) company is operating in a highly constrained environment, they control what devices are connected to their network, they know exactly what hardware is out there. So they can test the software on every different type of hardware that they have deployed before it goes out. This may take them a couple of months. Of course they have a big incentive to make sure their updates don't break the box as every call to their customer support call centre costs money, and if they brick the box, a truck roll costs an arm and a leg!
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".
Posted Oct 31, 2011 16:21 UTC (Mon)
by martinfick (subscriber, #4455)
[Link] (1 responses)
Posted Oct 31, 2011 20:15 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Even older boxes had customization capabilities (for example you had the ability to select few "favorite" channels). Newer ones often include DVR capabilities and video rent capabilities so personal information is most definitely there. What you probably meant is "they contain no unclassified personal data in there"... but is a good thing to have on your embedded device? We are entering era of parental computing - and set-top boxes show that people are quite willing to accept it if it means hassle-free gadgets.
Posted Oct 31, 2011 16:58 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Sure. But my point still stands: 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.
Posted Oct 31, 2011 17:43 UTC (Mon)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Oct 31, 2011 20:50 UTC (Mon)
by khim (subscriber, #9252)
[Link] (1 responses)
Sure, BIOS updates sometimes fail - but that just means they were not designed to be constantly updated. Aforementioned set-top boxes are significantly more complex then BIOSes - yet they are routinely upgraded with no ill effects. Actually another example fits as well: PS3 upgrades may be annoying because they routinely remove features, but situation when they break something they are not designed to break are exceedingly rare. It's not hard or impossible to develop thing which can be safely auto-updated, that just means that you must severely restrict it. Complexity has nothing to do with the ability to reliably upgrade something. Diversity is the killer.
Posted Nov 1, 2011 14:22 UTC (Tue)
by nix (subscriber, #2304)
[Link]
I do wonder, though, how much of the set-top boxes' firmware is actually upgraded by an update. If the components necessary to boot and do an update don't change, then that might reduce the likelihood of failure -- though the fact that we rarely see them fail in any way suggests that this is not the problem.
So... continuous upgrading works for stuff (even complex stuff) that runs in simple or consistent environments or that is not itself necessary to run the upgrade process. That's probably enough for embedded stuff, since their environments are normally nailed down by the vendor and all variations known. Just look out for embedded systems that run as part of larger systems, and whose upgrading is controlled by the upstream vendor: those may not have been tested in the environment they're being upgraded in. (This, too, is probably rare: the integrator would probably want to control the upgrade stream in such a case, since it's them on the line if things go wrong.)
Posted Oct 31, 2011 17:47 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Who owns the system, who is responsible for doing the maintenance? That's the person who wants access to manage revisions and read changelogs although certainly they decide to just apply changes as they become available. Having a robust mechanism makes that easier.
Posted Oct 31, 2011 21:11 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Technically - yes, they can. But then they next picture you'll see on TV when you'll connect them to network is "please wait while system update is installed". IOW: revert capability is only there to assist in upgrade process, it's not designed to be used by end-user (except when directed by tech support to "properly" upgrade device). Does not make any difference in all cases I've encountered: yes, you can buy the box - but this only affects you monthly payments, if you buy it you can do whatever you want with it till you connect it to cable network. But if you do want to connect it to cable network - you automatically agree to install network's firmware. These are two different question - and they naturally have different answers. That's true for plumbing, electric wiring, cars and so on... so why should it be the same for computers and gadgets? Right, but how to help the guy who actually does maintenance is separate issue from how to push updates to end-user. Even there changelogs are not all that helpful: someone who's responsible for pushing updates to end-user does not need to know what changes are there, s/he only needs to know what can go wrong and how to fix the problems.
Posted Nov 1, 2011 1:49 UTC (Tue)
by foom (subscriber, #14868)
[Link]
Even though that's the case, people still don't tend to complain...very much...because it's just recorded TV programs, after all, not something *important*.
Bwahahah
Bwahahah
Of course they do!
Sure...
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".
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.
Bwahahah
BIOS is certainly less complex then set-top box :-)
BIOS is certainly less complex then set-top box :-)
Bwahahah
Perhaps your providers are different from mine...
These devices certainly do allow updates to be reverted.
Further more cable boxes are often owned by the cable company, not the subscriber, and they certainly do test and read changelogs before updating their own hardware.
Who owns the system, who is responsible for doing the maintenance?
That's the person who wants access to manage revisions and read changelogs although certainly they decide to just apply changes as they become available. Having a robust mechanism makes that easier.
Bwahahah