Developing and Deploying devices

[Dirk Hohndel]

> On Apr 14, 2016, at 12:40 AM, Jeroen Massar <jeroen at massar.ch> wrote:
>> 
>> 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 ;)

My car runs Linux as well. Didn't come in a box, though.

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

Yes. And if someone hacks one - I don't care :-)
If your Subsurface Box doesn't work as expected, just flash a new image.

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

In theory, not in reality. The complexities and permutation are insanely big.
That's why most of the cloud image folks (CoreOS, Clear Linux, Atomic) are
going away from using package based delivery.

> 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

No. Why would we do this as packages if the end user never gets to see
them? For me as a developer the work to fight with Debian packaging has
no possible upside but a TON of downside.

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

No, because that's not how CHIP delivers images. They deliver a complete
image of the flash. No packages involved.

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

I have no interest in that model. I'd do this exactly as I do this today.
For Subsurface the packages that distros use are a pain in the rear
and something that I am still doing because it's something that some
people expect. The main delivery vehicle for our software is
a) Windows installer
b) Mac DMG which contains a .app folder
c) Linux AppImage that contains basically the same thing
d) Android .apk (also the same thing - everything included)
e) iOS .ipa (guess what, the same thing - everything included)

I have no interest in fighting with the upstream Debian distro on which
version of bluez might be available for me. Or whether I am allowed
to link statically. Or any of this. So my expectation is that we'll have a
git tree with a shell script that installs the pieces that we need from
source, cleans the image up and makes it ready for file system level
packaging. A developer who wants to work on this simply skips the last
step and works on the device.

/D