On Mon, 2016-12-12 at 09:49 -0600, Mariano Lopez wrote: > > On 12/12/16 09:41, Patrick Ohly wrote: > > On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote: > >>>> In particular the "complexity" column is a bit subjective. Stefano, I > >>>> hope you don't mind that I did not quite buy the "easy to use" > >>>> characterization of swupdate ;-) > >>> No worry...and I have not written myself. It was inserted by Mariano, so > >>> it looks like that swupdate at least for Mariano is "easy to use". > >>> I think it is correct to point out that customization is required. > >> Compared to other update mechanism that I tested it was the easier to > >> implement. > > Which "getting started" document or presentation were you using? The > > documentation for mender (https://docs.mender.io/) is very > > straight-forward (partly of course because it doesn't need to cover many > > variations), while for swupdate > > (http://sbabic.github.io/swupdate/swupdate.html) I found it less clear > > how to begin. > > > > When I did a research in update mechanism, mender wasn't yet available, > and indeed it seems very straight forward (need to test it before final > veredict). But if you compare SWUpdate, swupd, and OSTree; SWUpdate is > by far less complex than the other two
Ease-of-use is not necessarily determined by the complexity. Good integration and documentation can go a long way towards making a complex solution easy to use - when sticking to the pre-defined usage patterns. The opposite is also true: a simple solution may be hard to use if all one gets is the source code and one first has to reverse-engineer the usage model. I agree that the complexity is roughly swupdate < ostree < swupd and there's also no doubt that the latter two aren't easy to use (mostly due to lacking documentation and integration), but I'm still not sure what documentation the "easy to use" verdict for swupdate is based on. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
