I'm using Docker more and I do like it (after a fashion), but I don't want to move my embedded software to this model. I've got one OSS project written in Python and it can run on python-mini (used on OpenWRT) on tiny configurations (<8MB rootfs).
It has minimal dependencies and doesn't even need a virtual-env. It's prepackaged in rpms, debs and apks. It needs raw access to GPIO and USB. ResinOS, which technically interesting, seems like way too much and another layer I just don't need.
I don't want to sound like a dick, because I'm sure the authors put a lot of work into this, but I really don't think this is a good pattern at all.
If I had to write my client again today, I'd probably write it in RUST/LLVM, giving me even less of a reason to stick it in a docker container on my device with <8MB storage space.
Our model is not a commandment for everyone. There will always be cases where containers don't make sense. However, every new level of abstraction meets this instinctive reaction at first. People didn't want VMs in the data centre messing with their bare metal either, I'll bet.
The point of containers is to make updateability easy. To bring embedded software closer in line with what's going on in the cloud. To enable the kinds of workflows we have had in every other part of the development world for decades. It may or may not be right for your project. So long as you understand the intention and make informed choices about the tradeoffs, there will always be cases that fall in the one or the other side of the fence. I don't perceive this as being a dick, you're stating a reasonable case for a model that does indeed work for a lot of cases.
We will continue working to reduce overhead, hopefully power requirements and cost will go down, and somewhere along the curve, we may even meet your needs at some point. Whatever the case, we're pretty sure we'll never cover everything so if we gave the impression that resinOS will end all embedded OSes, then it was the wrong impression to give. :)
We used to release anually in the data centre too. If the benefits of incremental and iterative deployment don't move you, consider all the iot security issues recently. And if that doesnt do it either, consider NASA's Mars rovers, Tesla, nest, and the multitude other embedded products that use updating to great effect. You may disagree, but gibberish is a bit harsh don't you think?
I don't agree. Today you can push out packages to embedded device easily; even tiny <4MB rom devices like openwrt.
You can push out regular updates, but you have to be very careful. You need to have full testing environments and real lab units of all generations to test on before you push to production and realize you now have a brick on the roof of an 80 story building that takes a week to get a roof permit form.
The cloud stuff is gibberish. Today's cloud is rebranded hosted platforms. I agree, I don't see the argument of making _embedded like the cloud_ being meaningful either. I know on my embedded projects we had a tight ship pipeline and you need that for the reason stated above. Sure you can do that with Docker/ResinOS, and it might help with building a piece of that, but I have a feeling it adds as much complexity as it might mitigate.
The embedded systems I work on are never internet connected and updated manually by trained service technicians when necessary.
Like the discussion at the top of this thread, we've really muddied up the waters when it comes to defining "embedded devices".
There are devices like mine, which are the early definition of the term (single purpose, low cost, tightly defined I/O) and then we have low cost highly compact computers, literally servers, that can be multi-purpose and are internet connected 100% of the time by design.
I discovered that docker can be helpful during development for embedded stuff even without using docker on the device itself,. E.g. we put the target distribution for an embedded device incl. the whole development toolchain (gcc&co) in an image. That way the build environment can be easily stored and distributed through a docker registry
It has minimal dependencies and doesn't even need a virtual-env. It's prepackaged in rpms, debs and apks. It needs raw access to GPIO and USB. ResinOS, which technically interesting, seems like way too much and another layer I just don't need.
I don't want to sound like a dick, because I'm sure the authors put a lot of work into this, but I really don't think this is a good pattern at all.
If I had to write my client again today, I'd probably write it in RUST/LLVM, giving me even less of a reason to stick it in a docker container on my device with <8MB storage space.