
ResinOS, run Docker containers on embedded devices - lifeeth_
https://resinos.io/
======
chapingt
I always have trouble calling platforms that can run a system of this
magnitude "embedded." For some reason I always had the term "single-purpose"
linked with the idea of an embedded system. Once you add tons of RAM, a
relatively powerful processor, and can only last a couple of hours on a
battery--I feel like then it's just a small general purpose computer.

~~~
Matthias247
I think there are simply 2 views for the systems: One is the developers view,
the other the end users view.

From the developers view these Linux based systems are pretty much general
purpose computers.

However what mostly counts for the definition of "embedded system" is the end
users view. The end user (customer) gets a complete system for a specific
purpose, he can't install any own applications and partly can't even update
the system.

~~~
chapingt
This is the most useful argument I've ever heard on this. Thanks!

------
mrlambchop
This is awesome!

I always loved Arduino as it promoted a few core ideas (apps are highly
portable, the environment is standardized over boards and devices) - this
allows the hobbyist / stack overflow reader to make some awesome hacks in a
few hours and really reduces the barrier to entry for maker projects. However,
in the last few years, I've wanted a similar type of environment for all the
Linux boards that now clutter my desk - the ability to run different apps on
multiple boards without having to understand the depths of GPIO alternative
function mapping and quirks of various distros.

Having a docker container approach where the app is sandboxed away is the
right approach I think for this, but there should be a "standard API" as well
put in place that the apps that be written against (and bindings to python,
rust etc...) that is also emulated in a desktop or webpage environment. This
container doesn't support any HDMI output or full Debian environment - just a
basic API to start with. Add PIP/Cargo etc.. for advanced use cases. A
movement away from Arduino might be around the corner if there is something as
accessible but much more powerful available. The block is no doubt "power
management" \- suspending/hibernating Linux boards for battery operation
etc...

I hacked up a version of resinOS last year (using Android as the base Linux
port) and running docker on a root FS but never took it anywhere as the day
job (a different kind of startup) takes most cycles still. Can't wait to
install this later on a few Pi's :)

~~~
creshal
> A movement away from Arduino might be around the corner if there is
> something as accessible but much more powerful available. The block is no
> doubt "power management" \- suspending/hibernating Linux boards for battery
> operation etc...

What are RasPi and similar boards lacking? Power management? Not enough GPIO
pins?

~~~
noonespecial
>What are RasPi and similar boards lacking? Power management? Not enough GPIO
pins?

For me its the ability to "blink" (sleep a designated time and then re-awaken
for a brief burst of activity) and so perform some task for 6 months straight
on a pair of alkaline AA batteries.

~~~
pharkmillups
If you're looking for a sensor platform that will let you quickly deploy a
sensor that will run for a few __years __on a pair of AAs, check out what we
're putting together at Helium [1]. We just rolled out the presale of our
Helium Atom Development Board [2] which uses the Atom - our drop in
connectivity and compute module - as the basis for a sensor development board
that is actually fit for production. The OS that runs on the module - cleverly
named Helium OS [3] - is the basis for our edge programmability and abstracts
the annoying, hard things like battery/power management, wireless, and
security. Also OTA upgrades are built in. :)

mark@helium.com

[1] helium.com [2] [https://store.helium.com/](https://store.helium.com/) [3]
[https://www.helium.com/helium-os/](https://www.helium.com/helium-os/)

~~~
noonespecial
Don't know if you'll still see this. Cool. But one thing. It would be easier
for me to get a sign-off from management on a one time purchase of $10k than a
$4/month recurring. Corporate sales is funny like that.

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

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

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

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

------
alexandros
Hi everyone, resin.io founder here, happy to answer any and all questions. We
just released resinOS at ELCE a few hours ago (Embedded Linux Coference,
Europe), happy to see it made HN!

~~~
roymurdock
I think I see where you fit in - deeply embedded systems with real-time
constraints tend to use a certified hypervisor solution to separate runtimes.
Traditional IT solutions can use Linux KVM or a full Docker implementation.
ResinOS fits in the middle.

Familiarity with Docker will allow makers to get multiple runtimes up and
running on higher-end (but small) SoCs...but for what type of applications?

~~~
alexandros
There are a _lot_ of companies looking at the intersection of containers and
embedded. Some call it "Fog Computing" others "Edge Computing", others still
"Industrial Internet" and so forth. We have a number of use cases on the
resin.io website of people using this technology in production today, but some
of the larger ones we're not allowed to talk about :(. ResinOS does include a
full Docker engine however. It's just that a lot more is needed to do
containers right on embedded Linux devices.

~~~
pjmlp
Would that include high integrity like support? Just curious.

------
timanglade
Congrats on launching! Testing & deployment of stable configs is arguably even
more of an issue in embedded development than in web, so I'm sure this will
make a lot of people very giddy! Are y'all 100% happy with the technical
design assumptions & requirements of Docker, or did you mainly pick it so you
could bridge with the existing community (or a bit of both?)

~~~
alexandros
Very good question. We find that we have to add functionality for the embedded
world in quite a few cases, and part of the resinOS roadmap is to package that
up for the OS. But the base Docker, other than its recently growing size, is a
very strong foundation, and one that keeps improving. We're particularly
excited about the new security features and in general our approach is that we
can move a lot faster by filling the gap between Docker and embedded devices,
rather than starting from scratch and building Yet Another Container Engine.

------
woodcut
I think nerves[1] needs a mention here... it'll pack your elixir application
with a minimal linux kernel onto a read only sd card for use with a raspberry
pi or BeagleBone.

[1] [http://nerves-project.org](http://nerves-project.org)

------
tostitos1979
Very cool stuff! Some boards, like the beaglebone, have specialized hw like
PRUs or I2C pins. Is it possible to access these with Docker containers? Also,
what is the minimum memory footprint? i.e. how many containers can I fit
within say 1 GB.

~~~
alexandros
The version of Docker on the OS right now is 1.10 so the ram footprint of the
OS is fairly small. The team is all asleep (being in Berlin and whatnot), but
I'd estimate about 50mb is a decent approximation. We're working on getting a
newer Docker but its RAM footprint is one of our concerns, though we do have
ways forward.

The number of containers is kinda a red herring for a couple reasons. For one,
you can make a trivial container and launch as many containers as you like, it
really depends on what's in them. For another, embedded devices don't usually
need hundreds of containers, they run payloads that are either single-
container, or look a lot more like a docker-compose file with a few
microservices.

~~~
ohstopitu
quick question...would the images have to be specifically built for arm? (we
were looking to build a cluster of RPis that we could orchestrate containers
on.)

~~~
alexandros
Yes. We build _many_ container base images for all architectures. have a
browse and pick what works for you --
[https://hub.docker.com/r/resin/](https://hub.docker.com/r/resin/) and also
[http://docs.resin.io/runtime/resin-base-
images/](http://docs.resin.io/runtime/resin-base-images/)

------
CamperBob2
_After about 30 seconds or so your device should be up and connected to your
local network, you should see it broadcasting itself as resin.local._

Why does it take so long to boot? Is it limited by the speed of the SD card? I
wonder how it would do on a Zynq platform with QSPI flash.

------
imrehg
Some more notes and details from the blog: [https://resin.io/blog/introducing-
resinos/](https://resin.io/blog/introducing-resinos/)

