On 30 November 2013 04:22, Carsten Haitzler <[email protected]> wrote:
[...] > 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 actual > contracts and legal means for that. it's a practice that is in decline. > 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. it > 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 with "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 think one of the most important aspects to realize is that these days > 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 absolute > 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 a > 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. 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 flashing. You can equally have buggy rollback mechanism :-) 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 safer. Final few considerations: 1) given the dynamics of how testing works and the fact that testing teams 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. 2) alternatively, one could use cloud storage to keep track of user data 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 state. 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, like: - no access to broadband connection - no access to a PC - hard requirement of 99.999% availability 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 attractive. 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
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
