Is It Time for a New Embedded Linux Build System? — [yoe]

Is It Time for a New Embedded Linux Build System?

2026-06-11

strategy,

vision

I’ve been building products using embedded Linux for the past 20 years. The<br>first time I tried OpenEmbedded (the precursor to Yocto), it felt like a gift to<br>be able to run a single command and build a bootable ARM image from my x86<br>workstation. But things are changing. We have more and more components (both<br>hardware and software) available. We have AI tools. We have powerful processors<br>with loads of memory. Small teams (startups and industrial companies building<br>small/medium volume connected products) want to do bigger things, yet they<br>struggle with the complexity of stitching it all together, miss their shipping<br>dates, and strain to maintain these systems once they’re in the field. This<br>article explores what has changed, and how we can build and maintain embedded<br>Linux systems more efficiently.

The Embedded Systems Golden Age

We live in a remarkable time for embedded systems engineering. We have:

A large number of Linux system-on-modules (SOMs), perfect hardware building<br>blocks for industrial products.

Zephyr, an excellent OS for building software on MCU platforms.

Mature tools (compilers, build systems, etc.).

A vast array of open source software we can apply to these systems.

Fast, reasonably priced prototyping (PCB assembly, mechanical 3D printing,<br>etc.).

More vendors upstreaming their Linux kernel support.

Yocto’s solid tooling for building images and custom parts of the system.

And all of this is available to companies of any size. It’s a bit like<br>inheriting a mansion: open source has handed us a sprawling house full of rooms<br>and features we’d never have built ourselves, and we have to live in it to stay<br>competitive. The catch is that nobody handed us the tools to keep the place<br>running. There is nothing holding us back, except our ability to put it all<br>together.

How Embedded Linux Systems are currently built

Embedded Linux build systems solve the problem of putting all the pieces<br>together, and the existing ones have served us well. Buildroot (2001) and<br>OpenEmbedded/Yocto (2003) are now the standard, supported by most SOC/SOM<br>vendors, and some teams ship successfully on Debian, Ubuntu, or even Arch (as<br>Valve does with the Steam Deck).

The shape of mainstream embedded Linux development has held remarkably steady<br>for ~20 years: cross-compile on a powerful x86 workstation, assemble a BSP<br>(board support package), freeze an SDK (software development kit), ship the<br>image, and hold that line for years. It’s a model built for a static,<br>single-purpose, rarely updated product, and until recently, for that product, it<br>worked well.

But things are changing …

The products have changed more than the tools that build them. Edge devices have<br>started behaving like cloud systems. They run containers, pull OTA (over the<br>air) updates, stream telemetry, and are managed remotely over their entire life.<br>A device is no longer a static artifact you flash once and forget; it’s a system<br>that keeps moving forward after it ships. That inverts the old release cadence:<br>instead of freezing an SDK and holding it for years, teams track upstream<br>continuously and push updates as a matter of course. The long LTS (long-term<br>support) freeze that the cross-compile model was built around no longer fits a<br>new class of products.

At the same time, the software itself has outgrown the cross-compile model.<br>Modern languages each ship their own package ecosystem: Python (wrapping<br>C/C++/CUDA via NumPy and PyTorch), JavaScript (linking to C libraries), Go,<br>Rust, and vcpkg (for C/C++). Most of it is written for desktop/server, not<br>cross-compilation. That puts the cross-compile burden squarely on embedded<br>developers, and maintaining recipes for thousands of packages has been a steady<br>drain on the Yocto community. Yocto compounds this by blocking network access<br>during the build, so language package tooling doesn’t work without complex<br>do_fetch integration. That’s useful when you must control every source, but<br>unnecessary friction for many projects.

Each of these solutions trades one problem for another. Building everything from<br>source in Yocto means long builds, heavy memory use, and powerful workstations.<br>A stock binary distro like Debian starts development faster but lacks the<br>tooling to integrate the custom parts. And vendor BSPs frozen on a 4-year-old<br>Yocto make it hard to integrate modern software at all.

We could go on, but the cause is structural. Talented teams working hard still<br>hit this, because the problem is inherently difficult and the software keeps<br>getting harder to build.

To summarize, three things have changed:

Products never stop moving. Edge devices now behave like cloud systems:<br>continuous OTA updates, not a multi-year freeze.

Software outgrew cross-compilation. Every modern language brings its own<br>package ecosystem that doesn’t always cross-compile cleanly.

The old...