On Fri, 29 Nov 2013 19:01:22 +0200 "Stoppa, Igor" <[email protected]> said:
> Hello, > > > On 29 November 2013 17:07, Aliaksei Katovich <[email protected]> wrote: > > > hi all; > > > > I would like to bring to your attention Tizen system rollback > > feature. > > The idea is to provide possibility to roll back Tizen based system > > to > > one of several known working configurations. Most obvious > > use-cases are: > > > > * system update or upgrade failed; > > * there are regressions introduced by system update; > > * User does not like features added by system update; > > * User wants to restore device to first time configuration; > > * User wants to restore device to factory defaults. > > > > Proposed architecture is based on device-mapper thin-provisioning > > capabilities. Please find more details in attached document. > > > > Before starting actual implementation of this feature I would like > > to > > hear your opinion about presented architecture and the idea in > > general. > > > > I see some reasons why part of these options are unfeasible/undesirable > under certain circumstances: > > * user has subsidized device > If a way is found to break the simlock for a certain SW revision, the > operator should > be able to forcibly update all the units deployed in the field that are > made available w/ subsidy. > The user should not be able to rollback to some unlockable version. > > * hole in DRM scheme is found > This is a bit similar to the previous case but applies to both locked and > unlocked devices. > If a certain SW version is found to be exploitable for cracking DRM > content, the OEM/operator > should have the means to issue (possibly) non-mandatory irreversible > updates. > I'm not a lawyer but I suppose that neither OEM nor operator have the > rights to impose a SW update > on user-owned devices, however they can easily make it so that the > following user-issued upgrade > prevents any rollback. Preceded by some warning, of course. > > So I think there should be means to forcibly and voluntarily permanently > flush the queue or > prevent any rollback, from before a certain version. > > Furthermore, I think it's not such a great idea to tie factory settings and > overall device status. > I would prefer if each SW update would also include its own specific set of > "clean slate" configuration values. > Without talking about factory. > > Red Hat, afaik, targets different type of products where these issues are > not present. 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. 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 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. -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
