Mathieu developed embedded systems with Buildroot, yocto and Alchemy (an Android-based build system). GNU Guix (pronounced “geeks”) was originally an innovative package manager, but it gained possibilities to generate rootfs, provision containers, and run CI.
For embedded you need a tool that can generate root filesystem images and can take into account the variation between boards and features.
Mathieu wanted to try Guix on embedded. So he did an experiment with installing ArduPilot on a Pine64 board, comparing this with yocto.
Yocto requires a lot of steps before even starting the build. It also throws a warning that Ubuntu-19.10 is not supported. This is not nice, a build should be independent of the environment on which you build. It takes a lot of space and time and you get a rootfs. You need layers from different providers, the quality of which may vary a lot.
In Guix, everything is written in Guile. You write (in Guile) an operating system configuration that specifies which bootloader, modules, etc. you want to use. ArduPilot is already packaged (by Mathieu) so you can just add it. Guix also supports cross-target rootfs generation. It downloads binary packages (see below). It only supports 4 architectures.
In Guix, builds are done in isolated environments, so you don’t depend on paths or build environment for reproducible builds. Only the Guix version needs to be the same to be reproducible. “Reproducible” here doesn’t necessarily mean bit-for-bit identical: at least timestamps that are encoded in files may be different. It was not very clear if the build environment manages paths (i.e. filesystem namespace) and uids (user namespace).
To build a package, you have to write a functions that builds it. Generally you take one input (the source) and generate one output (the binary). The binaries are cached on the build server, so you can just download it if anyone has ever built it before. This is called “substitutes” in Guix. Similar to sstate in yocto, but if you’re running on a different distro you probably don’t hit anything.
Guix supports multiple ways of creating a deploying images built-in, e.g. start a vm with it or deploy to a target.
Guix is written in a single language, Guile, so you can program directly in that language. E.g. to collect all licenses and format them in a certain way, or to filter the licenses, you can program it directly rather than requiring a feature for it to be pre-implemented. Basically, Guix is a Guile library.
Guix is pretty young, so still has some limitations. The minimal image is still very large (1.5GB). Some packages fail to cross-compile. It doesn’t support alternative libc’s. The number of boards with builtin support is quite limited.