Re: update mechanisms

[Patrick Ohly <patrick.ohly@intel.com>]

Hello everyone!

Thanks for contributing directly to the page. It's great to see this
done collaboratively.

On Tue, 2016-12-06 at 23:38 +0100, Stefano Babic wrote:
> Hi Philip,
> 
> On 06/12/2016 19:45, Philip Balister wrote:
> > On 12/06/2016 06:11 AM, Lopez, Mariano wrote:
> >> I agree with you, that we need to have a section per project, the table
> >> is too limiting.
> > 
> > I just skimmed the page and the table format isn't working well with the
> > length of the blocks of text.
> > 
> 
> Agree - I think it is better to have a section per project.

That always has been the goal, and I now updated the page accordingly. I
tried to summarize the key aspects of each mechanism in the table
itself. That's something that I haven't seen elsewhere and something
that the page can  I tried to be as fair and objective as possible,
please shout if I messed something up or you don't agree with my
summary.

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 ;-) For a system that is as flexible as
swupdate, I'd expect a more difficult learning curve and some need to
customize the system before using it, so I added a "(but requires
customization!?)" comment to that statement.

Kristian, I added a comment that Mender requires U-Boot. That is
correct, isn't it? I understand that this restriction allows you to
implement things like automatic rollback, but it's worth mentioning that
this comes with that limitation.


-- 
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.