[Dev] [RFC] Tizen system rollback
a.katovich at samsung.com
Mon Dec 2 08:56:55 GMT 2013
> On 30 November 2013 04:22, Carsten Haitzler <tizen at rasterman.com>
> i think that your cases, while they do exist, are for a shrinking
> mindset. more
> and more operators don't lock devices even with contracts. they use
> contracts and legal means for that. it's a practice that is in
> well ... this might be a matter of perception - I'd rather not get into
> a debate of
> I think/you think
> unfortunately I'm not able to provide hard data about the use case, I
> can only say
> that so far this has been a requirement from several/many operators
> toward OEMs
> as for the DRM scenario - eventually the user is going to have to
> make a choice
> - older software with bugs or missing features... vs crackable DRM.
> discourages them and in the end is a small price to pay imho.
> and for both of the above they can still factory-reset anyway, so
> it's no
> different. if they really want to get around these mechanisms...
> just factory
> reset and presto. (and if its a particular update after that just
> walk forward
> one update at a time until you get there).
> I think here you might have missed part of my point.
> Which was to drop the concept of "factory reset" and instead replace it
> "reset to latest supported configuration" which might very well be what
> is flashed
> in he factory, but not necessarily what was flashed on _that_ device in
> the factory.
> Rather, it ought to be "what is currently flashed in the factory".
I do not see any issues with supporting this concept in proposed
> i think one of the most important aspects to realize is that these
> products are not done and finished when shipped. software is large
> and complex
> and FULL of bugs. always. and always will be. there is nothing you
> can do to
> change that. the most important thing to any producer of a product
> is to be
> able to update in the field. probably 100% the most important thing.
> the device
> has to be able to function enough to be able to update and "be
> fixed". as a
> direct bi-product of this, should a fix render the device unable to
> do another
> update after this (a buggy update not tested well enough), you just
> bricked a
> whole bunch of devices out there. a rollback mechanism is an
> requirement of any update-in-the-field mechanism. since the update
> mechanism is
> a requirement, then so is a rollback, by definition. not having such
> mechanism is living life on the edge.
> Sorry, but I cannot agree with this.
> You are somehow implying that the end user would not be able to flash
> the sw
> on a bricked device.
This sounds like a real statement rather than implication to me: User
will not be able to restore malfunctioning after update device being
away from PC or being not connected to network.
> Which is not true.
> Both x86 and ARM nowadays support the cold flashing of signed FW,
> through the execution
> of ROM code or some other means that a broken update cannot cripple.
> So that's your recovery path, in the extreme case. All is needed is
> that the OEM provides
> a chain of trust FW->kernel->OS.
> Sure, OTA upgrades are nice, but the real safety net lies in cold
Again, OTA upgrades are already part of our lives - so it is not just
nice but rather mandatory thing nowadays.
> You can equally have buggy rollback mechanism :-)
No doubts ;)
> Of course this applies to the cold-flashing mechanism as well, but in
> general that's much simpler
> and extremely more tested, so I think it's fair to expect it to be
Expectations are not always safer way to go.
> Final few considerations:
> 1) given the dynamics of how testing works and the fact that testing
> have only so many devices available, it's much more likely that cold
> flashing gets
> significant more testing than OTA. I won't get into details, but it's
> obvious that they
> have to test many releases and typically the testing starts with
> flashing a new image.
> Only a limited amount of devices are reserved to real OTA updates,
> because it
> requires more complex IT infrastructure.
I do not see your point here. Are you trying to say that no new features
should be added because testing is hard to arrange?
> 2) alternatively, one could use cloud storage to keep track of user
> and configuration (like apps installed and related keys) and just
> rebuild the user's
> customized setup on top of a new build.
> Even with a rollback, there will be the problem that the use might want
> to re-install whatever
> was non-offending and got installed in between the restored snapshot
> and the failure that needed reset.
> And even re-installing, the user data might be in a non-consistent
This is far less tested than anything.
> 3) how to decide to take a snapshot?
> - let the user choose
> - whenever some native app is installed
> - before a distro upgrade, like windows does?
> - a mixture of the options above
> If I were to decide, probably I would either do it all the time or
> misjudge and skip it when
> it would really turn out to be useful. Probably I would do both :-)
> The rollback, to me, makes some sense only in certain corner cases,
> - no access to broadband connection
> - no access to a PC
> - hard requirement of 99.999% availability
those three above _are_ real! Look:
User received update being connected to internet. Update worked just
fine first two hours and then something started to malfunction. User
has no data connectivity nor PC accessibility at that point of time
but desperately needs stable working device. Maybe it _can_ be called
a corner case but to me _possibility_ to restore device to known working
configuration regardless of connectivity status or PC availability is
> So it might fit cases where you have rural users, but if we can assume
> that the
> device is targeting city dwellers, the reconstruction seems more
> Which is btw, what Apple does.
> I'm not saying that it's right just because they do it, but certainly
> we will all agree
> that they have a large use base which is not necessarily tech savvy and
> yet they
> manage to keep the bricking to an acceptable level.
> cheers, igor
> 1. mailto:tizen at rasterman.com
More information about the Dev