Initial Ideas

Oryx intends to explore a few newer and lesser-used options for building an embedded Linux distribution on top of OpenEmbedded. Here are a few initial ideas...

musl libc

Oryx will use musl to provide a modern, lightweight libc implementation. musl compares very favourably to other libc implementations and is licensed under an MIT license.

This should be a fairly easy switch as musl looks to already be well supported in OpenEmbedded.

toybox

Oryx will use toybox to provide the basic system utilities, effectively replacing busybox. Toybox has a very clean and straightforward code base and is licensed under a "zero clause" BSD license.

Toybox is a work-in-progress and doesn't yet provide all the utilities needed for a full embedded Linux system. Therefore the move from busybox to toybox won't be an immediate one. We'll need to support Toybox development and integration into the meta-openembedded layer to get to a point where busybox is not needed anymore.

Init System

Init systems seem to be fairly controversial these days. OpenEmbedded offers two options, a traditional sysvinit and the more modern systemd. Neither of these is a good fit for Oryx: sysvinit is clunky and shows its age whereas systemd is large, overly complex and prone to making breaking changes. We'll need to look elsewhere for an init system for Oryx.

A good candidate would be runit. This is a fairly simple init system with service supervision (ensuring that daemons are restarted automatically if they crash), licensed under a 3-clause BSD license. It doesn't look like runit has been integrated with OpenEmbedded before so this would require some work. We'd need to first write a recipe for runit itself and then integrate run scripts for each service that we use. This development can be started in the meta-oryx layer and then moved out into a more suitable layer in the future if it proves useful outside of the Oryx distro.

Clang/LLVM

There are no plans to move Oryx over to the clang C compiler any time soon. We should keep an eye on developments in this area though. If clang does become a drop-in replacement for GCC in OpenEmbedded then we should consider switching over.