back
17 comments
This looks like a great project. I have a few questions in case the maintainers read this.

- Do you plan to stay up-to-date with new Moby releases, or is it a one-time hard fork?

- Do you plan on contributing some of the IoT optimizations back into mainline Moby over time?

- If you have contributed to Moby in the past, what's your experience of contributing, is the community welcoming?

- What's the planned differenciation between Balena and Resin.io?

For some extra context (differences, features, comparison), here are the slides introducing Balena at the Moby Summit last year:

https://www.slideshare.net/resin_io/balena-a-mobybased-conta...

(too bad that the talk wasn't recorded by the organizers, as far as I know)

but why, tho?

What sorts of devices would benefit from a system like this? Can someone give me sone use cases where being able to run containers on embedded devices would be useful? The tech seems pretty cool, but I am just having a hard time wrapping my head around it as someone who's experience with embedded stops at hacking on raspi/arduino/esp* devices

hey there -- resin.io founder here.

We built balena after running docker for millions of hours on resinOS devices. Turns out, containers are not just a good, but probably the best way to manage software on embedded linux devices. The whole "edge computing" wave that's started moving now is based on the idea of deploying containerised workloads to these devices. What we found though, is that Docker tends to have several subtle biases towards cloud usage that become apparent in the embedded context. So we made Balena to embed our improvements into Docker.

I can talk about this stuff for hours, but suffice to say we have customers doing building automation, smart retail, digital signage, industrial automation, automotive, etc. My current favourite though is the guys that put devices on the back of sea turtles in the galapagos. Check this footage out: https://www.youtube.com/watch?v=JfkfLsgEN9Q

Edited to add: On the hardware question, resinOS works on many many device types including niche industrial boards and well-known maker SBCs. We've made it relatively easy to port to new devices so we can keep expanding our supported types of devices. In the meantime, we're working on our own "industrial" raspberry pi variant, which, based on our experience so far, should be good enough for 60-80% of serious use cases. https://resin.io/blog/introducing-project-fin-a-board-for-fl...

Can confirm, resin.io is brilliant. The new multicontainer functionality looks like a great improvement!

Source: have photographed fish with resin/docker.

That's great. The headline alone made me wonder why anyone would bother to do this, but on reading the resin.io site, there really are lots of compelling reasons for the approach.

Btw, also a big fan of Etcher!

Looks like a great project! What is stopping Docker from using binary diffing in general? It seems it would be a big win for them, I imagine their AWS bandwidth bill is absolutely gigantic.
curl www.foo.bar | sh

Yeah, right.

> Or Download

Literally immediately below the install script. I wish people would leave these low-effort comments on reddit where they belong.

And? Just because "smoking creates cancer" stickers on cigarettes they don't kill people anymore?

Just having that suggestion burried somewhere on page 300 of a documentation is worth enough to mention it.

It's not a question of free choice but a question of how we educate people to develop software.

I thinks it’s a matter of how we educate our arm-chair security experts, actually.

What is the difference between blindly trusting a script piped directly from the source and blindly trusting a script packaged in a tarball? Can you honestly say that you’ve audited every piece of code that you execute on your system, and can say with complete confidence that no data on your system has been tampered with? Do you reverse engineer and audit your unsigned binary installers before executing them? If not, then I’m very curious to hear why you believe that you are somehow avoiding the same risks posed by a curl | sh script such as this one.

why not though? how is 'git clone a huge repo and run an obfuscated makefile' safer?
I do genuinely wonder if all the folks on the "let's make fun of curl | sh" train also steadfastly refuse to run ./configure on tarballs from SourceForge, and instead spend the time to audit every custom M4 macro in the project along with every Makefile.am (lest either of them shell out to something untoward) and run autoreconf themselves.
Why stop there? Most projects probably don't sign every commit, and even if they do, you'd still want to code review just to make sure mistakes or planted routines didn't make it in. I'm assuming, of course, that any code you compile, you'd eventually want to /run/ somewhere. And if you're going to sandbox it or use permissions to restrict it, well, you could always do the same with the curl command. ;-)
git check certificates to make sure the source is (more likely to be) legit. And as far as I know it doesn't randomly executes downloaded files without giving you the opportunity to review them.
curl also checks the HTTPS certificate.
Hmm, Moby is quite avant-garde, or at least was back in the day... But why would anyone want to build IoT products on top of an aging DJ?

(... I'll show myself out.)