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.
This is awesome!<p>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.<p>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...<p>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 :)
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).<p>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.<p>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.<p>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.
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!
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?)
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.<p>[1] <a href="http://nerves-project.org" rel="nofollow">http://nerves-project.org</a>
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.
<i>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.</i><p>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.
Some more notes and details from the blog: <a href="https://resin.io/blog/introducing-resinos/" rel="nofollow">https://resin.io/blog/introducing-resinos/</a>