Developing and Deploying devices

[Jeroen Massar]

[Two replies in one]

On 2016-04-14 08:48, Robert Helling wrote:
> Hi,
>
>> On 14.04.2016, at 08:05, Jeroen Massar <jeroen at massar.ch
>> <mailto:jeroen at massar.ch>> wrote:
>>
>> Thus in the case of a 'wrong flash', we could have a tool that just
>> flashes it that way as a way of recovery ;)
>
> I am convinced that “flash the whole thing” should be the default
> upgrade path. The problem is only you cannot do it while running.
> So you need a desktop.

For end-users that is likely the best path yes.

But that is fine, that is the case for 99% of the small devices that
upgrade anyway (GoPro's run Linux if you where not aware... yep no GPL
markers or other such things on that box ;)

Most likely folks will only upgrade for major releases or when their DC
is not properly supported.

And we can get away with that as it won't be Internet connected, nor
have anything that can be remotely exploited. Thus security concerns of
such a device are comparatively low.

On 2016-04-14 08:27, Tim Wootton wrote:
> On 14/04/16 07:05, Jeroen Massar wrote:
>> On 2016-04-14 07:54, Tim Wootton wrote:
>>> On 12/04/16 15:58, Dirk Hohndel wrote:
>> [..]
>>> The disadvantage is that a full image download is needed for each
>>> upgrade, which provides an intensive to make it as minimal as possible.
>>> Group A users can always side-load their favourite tools after updating.
>> Binary diff's have existed for a while ;)
>>
>> But it is the  same situation for a a apt-get updates on a filesystem
>> you know exactly what is there: you know what is there, thus you can
>> upgrade that perfectly without any issues.
> 
> well yes and no, .debs run scripts on deployment, some of those take
> actions depending on what they find on the system. Results can vary
> based on where you started and what's happened on your system since the
> last upgrade. A full image gets everyone back to a known state on each
> upgrade.

Known Image + changes in .deb => Known Image.

Indeed, if somebody modified things then it is an Unknown Image, but
then, people can also manually fix things.

Thus we should more than easily be able to take:
 - The default CHIP image
 - install our modifications in the form of packages
   this primarily so that it can also run on other
   Debian-based platforms
 - make that "our" image

Then when an updated release comes out:
 - install the new package
 - re-image that
 - binary diff with previous => release it

Users thus simply install images, advanced users can just take the
Debian packages if they wish.

Apparently I'll be having a CHIP shortly if the FEDex driver gets
through the weather still today, and I should be able to actually dig
into it more over the weekend.

Greets,
 Jeroen