The company blog of Resin.io, which builds tools for deploying Docker containers to IoT and Raspberry Pi devices.
HN links it for Raspberry Pi and container posts, and the company's staff use threads to describe their support practices and post job openings.
Resin.io | Data / Software / Finance Engineer | REMOTE | FULL-TIME | https://resin.io
Resin.io is solving the myriad problems that come up when developers trying to manage software on thousands of intelligent devices in edge computing/iot/embedded scenarios. Our customers are working on everything from self-driving trucks to drones to sea turtles with cameras on them to smart buildings and smart everything else. We've pioneered bringing linux containers to ARM devices, and have built a complete solution around that, including an OS, cloud services, a beautiful UX, and of course, etcher.io.
We are looking for a person with a solid combination of Data, Finance, and Software engineering skills to work directly with the founders on building an end-to-end data & forecasting model for the whole company, tying together product metrics, financial data, revenues and expenditures, as well as team data & metrics. The resulting model should give high-level visibility into any problem areas and allow highly accurate scenario forecasting into the future.
If that sounds like a project you'd love to dive into, you're detail-oriented and believe that everything is systems all the way down, drop us a line at join4data@resin.io with a CV and a story of how you used data and/or code to solve a problem people wouldn't expect can be solved that way.
On x86-64 Debian hosts you can install binfmt-support an qemu-user-static packages. You'll need to copy the qemu-armeb-static binary inside the container image.
Then you just build inside a container normally, and the kernel will run the ARM binaries inside qemu-user, translating the ARM system calls to x86-64.
If you don't control the host (ie, someone else's hosted CI service), you can do some sleazy hacks documented here:
https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/
I've been meaning to try copying a cross-compiler and cross-binutil into the container, to make things faster (no need to binary-translate ARM gcc/ld to x86-64), but without statically linking the compiler/binutils, it turns into a library nightmare. In theory this should be possible with multi-arch, but I haven't invested the time to try to make it go yet.
On our team at https://resin.io every engineer takes turns on customer support, something like a 5-day week with a 4-hour shift each day (and each day 4 of those shifts distributed across people), and repeat every few weeks. Sometimes it feels it's a big drain on people's time (for those weeks half your time is on support), but the end result is an amazing amount of learning across the entire team. What are the most important issues at any given time, what improvements would have the biggest impact, etc. It also feels that it makes it very easy to ask help across the whole team to debug any issue you find, as people are very open, supportive, and aware of what this "support-driven" approach requires to work. I'm only half on the technical side, but can find me doing support too. ;)
For those interested in rolling their own RPi rootfs builds:
- Spindle is a collection of scripts that's used to build the 'official' Raspbian images. It's hardly stripped-down as-is, and far from my favorite rootfs building strategy, but is a starting point: https://github.com/asb/spindle
- Yocto / OpenEmbedded recipes are available for truly stripped-down build possibilities. Here's a random blog post specific to RPi: https://delog.wordpress.com/2014/09/16/embedded-linux-system-for-raspberry-pi-with-yocto-project/
- The resin.io folks are trying to do "docker for embedded devices", with RPi as one of the initial targets. They have a pre-built rootfs that pulls your docker images via their (proprietary) cloud service. https://resin.io/
It can be:
https://resin.io
A Raspberry Pi is a surprisingly useful and cost effective device when it comes to IOT. Most industrially hardened devices of similar capacity cost a bit north of an order of magnitude more.
There are really only a couple of things that would need to be addressed, a good weather-tight case that allowed for heat dissipation, decent storage (most microSD has a short lifespan), and a good 5v power supply.
In many cases, designing a system that is cheap, expendable, and expected to fail is way less costly than the alternative.
Only technically so. The parts they send you are open source because of the GPL. A substantial portion of the parts in the cloud (which are 100% required to use the platform in any manner) are not open source. They've been suggesting that they will open source enough of the backend to actually run resin.io on your own (without several features) for 3 years now, most recent target release was 2017.
Here's the latest update I could find on the topic: https://resin.io/blog/open-source-resin-io-progress-and-next-steps/