[alexandros]

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

[TickleSteve]

"The point of containers is to make updateability easy".

No.

The difficulty in performing upgrades is not in upgrading the code.... that's relatively easy.

The real difficulty is making your data and the current state of your application upgradable.

This is not going to be solved by containers.

[joezydeco]

"To bring embedded software closer in line with what's going on in the cloud."

Can you give some examples of types of software that would benefit from this?

[alexandros]

anything that would benefit from a consistent build pipeline, fast deployments, isolated failures, etc etc.

[joezydeco]

Sorry, I'm a long-time embedded developer and that's gibberish to me.

We don't deploy fast. We deploy once.

[alexandros]

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?

[djsumdog]

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.

[tokenizerrr]

I'm sure your customers will appreciate that when it turns out you have some massive security vulnerability and you won't be updating anything.

[joezydeco]

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.

[hueving]

Container management software.