<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 30 November 2013 04:22, Carsten Haitzler <span dir="ltr"><<a href="mailto:tizen@rasterman.com" target="_blank">tizen@rasterman.com</a>></span> wrote:<br>

<div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">[...]<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

i think that your cases, while they do exist, are for a shrinking mindset. more<br>
and more operators don't lock devices even with contracts. they use actual<br>
contracts and legal means for that. it's a practice that is in decline.<br></blockquote><div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">well ... this might be a matter of perception - I'd rather not get into a debate of<br>

I think/you think</div> <br></div><div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">unfortunately I'm not able to provide hard data about the use case, I can only say<br>

that so far this has been a requirement from several/many operators toward OEMs<br><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
as for the DRM scenario - eventually the user is going to have to make a choice<br>
- older software with bugs or missing features... vs crackable DRM. it<br>
discourages them and in the end is a small price to pay imho.<br>
<br>
and for both of the above they can still factory-reset anyway, so it's no<br>
different. if they really want to get around these mechanisms... just factory<br>
reset and presto. (and if its a particular update after that just walk forward<br>
one update at a time until you get there).<br></blockquote><div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">I think here you might have missed part of my point.<br>

</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">Which was to drop the concept of "factory reset" and instead replace it with<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">

"reset to latest supported configuration" which might very well be what is flashed<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">in he factory, but not necessarily what was flashed on _that_ device in the factory.<br>

</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">Rather, it ought to be "what is currently flashed in the factory".<br><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


i think one of the most important aspects to realize is that these days<br>
products are not done and finished when shipped. software is large and complex<br>
and FULL of bugs. always. and always will be. there is nothing you can do to<br>
change that. the most important thing to any producer of a product is to be<br>
able to update in the field. probably 100% the most important thing. the device<br>
has to be able to function enough to be able to update and "be fixed". as a<br>
direct bi-product of this, should a fix render the device unable to do another<br>
update after this (a buggy update not tested well enough), you just bricked a<br>
whole bunch of devices out there. a rollback mechanism is an absolute<br>
requirement of any update-in-the-field mechanism. since the update mechanism is<br>
a requirement, then so is a rollback, by definition. not having such a<br>
mechanism is living life on the edge.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">

Sorry, but I cannot agree with this.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline">You are somehow implying that the end user would not be able to flash the sw<br>

on a bricked device.</div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;display:inline"> Which is not true.</div></div></div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

Both x86 and ARM nowadays support the cold flashing of signed FW, through the execution<br>of ROM code or some other means that a broken update cannot cripple.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

So that's your recovery path, in the extreme case. All is needed is that the OEM provides<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">a chain of trust FW->kernel->OS.<br>

</div><br clear="all"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Sure, OTA upgrades are nice, but the real safety net lies in cold flashing.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

You can equally have buggy rollback mechanism :-)<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Of course this applies to the cold-flashing mechanism as well, but in general that's much simpler<br>

</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">and extremely more tested, so I think it's fair to expect it to be safer.<br></div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

Final few considerations:<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">1) given the dynamics of how testing works and the fact that testing teams<br>have only so many devices available, it's much more likely that cold flashing gets<br>

significant more testing than OTA. I won't get into details, but it's obvious that they<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">have to test many releases and typically the testing starts with flashing a new image.<br>

</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Only a limited amount of devices are reserved to real OTA updates, because it<br>requires more complex IT infrastructure.<br>

</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">2) alternatively, one could use cloud storage to keep track of user data<br>

</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">and configuration (like apps installed and related keys) and just rebuild the user's<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

customized setup on top of a new build.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Even with a rollback, there will be the problem that the use might want to re-install whatever<br>

</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">was non-offending and got installed in between the restored snapshot and the failure that needed reset.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

And even re-installing, the user data might be in a non-consistent state.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

3) how to decide to take a snapshot?<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">- let the user choose<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

- whenever some native app is installed<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">- before a distro upgrade, like windows does?<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

- a mixture of the options above<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">If I were to decide, probably I would either do it all the time or misjudge and skip it when<br>

it would really turn out to be useful. Probably I would do both :-)<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

The rollback, to me, makes some sense only in certain corner cases, like:<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">- no access to broadband connection<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

- no access to a PC<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">- hard requirement of 99.999% availability<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

So it might fit cases where you have rural users, but if we can assume that the<br>device is targeting city dwellers, the reconstruction seems more attractive.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

Which is btw, what Apple does.<br><br>I'm not saying that it's right just because they do it, but certainly we will all agree<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">

that they have a large use base which is not necessarily tech savvy and yet they<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">manage to keep the bricking to an acceptable level.<br>

</div><br>-- <br>cheers, igor
</div></div>