Backend</th>	Dev-image rootfs</th></tr></thead>
Alpine</td>	~230 MB</td></tr>
Debian</td>	~390 MB</td></tr>
Ubuntu</td>	~1,130 MB</td></tr> </tbody></table> That Ubuntu figure looks alarming next to the others, but it’s mostly low-hanging fruit. Two directories account for the bulk of it: linux-firmware</code> ships 677 MB</strong> of vendor blobs for every device the distro might ever boot on, and the stock kernel’s module tree adds another 154 MB</strong> — together about 70% of the image. A real device needs the firmware and modules for its own silicon, not the entire catalog, so trimming linux-firmware</code> to the target’s blobs and swapping the distro kernel for a tailored build cuts the image roughly in half before touching anything else. Locales, docs, and man pages are easy wins on top of that. It’s the same size story Debian tells</a> — most of the weight is stock-distribution generality, and most of it comes off once you know the target.</p> `The encouraging result is the one the video opens with: supporting another distribution in this family was not a lot of work. The next focus is moving past QEMU onto real hardware, and trading the stock distro kernel for a custom one — which is where embedded Linux gets interesting.</p>` Get involved</a></h2> The full set of walkthroughs is on the Videos page</a>. A few ways to go further:</p> Try a build</strong> — the Getting Started guide</a> covers install and your first image.</li> Star and watch the repo</strong> — star it and click Watch to follow progress on GitHub</a>.</li> Subscribe to the newsletter</strong> — occasional progress notes; the email signup is at the foot of every page on yoebuild.org</a>.</li> Add a machine or image</strong> — the /new-machine</code> and /new-module</code> AI skills</a> scaffold support for new boards and distros.</li> Open a discussion</strong> — questions, ideas, or a board you’d like ported next go in GitHub Discussions</a>.</li> Send a note</strong> — reach the team at info@yoebuild.org</a>.</li> </ul> Adding Debian — and what it weighs 2026-06-03T00:00:00+00:00 [yoe]</code> started Alpine-first: musl, busybox, OpenRC, and apk</code>. That stack is small, fast, and clean to wrap, and it remains the default for new projects. But not every workload fits it. Some binaries are built for glibc and never ported to musl — CUDA, vendor camera and radio drivers, a lot of enterprise software. Some teams already run a Debian/Ubuntu-based fleet and want their edge devices to match it. And the apt ecosystem is vast.</p> So [yoe]</code> now has a second backend: Debian. The latest video</a> walks through it. The same project can build Alpine and Debian images side by side, choosing the distro per image. A unit’s source build runs in whichever toolchain the consuming image needs — musl for an Alpine image, glibc for a Debian one — and produces a libc-correct binary either way. You pick the platform the workload requires, image by image.</p> The same machinery, a much bigger feed</a></h2> Under the hood, the Debian backend reuses the unit model Alpine already runs on. [yoe]</code> targets Trixie, Debian’s current stable release, and Debian main alone exposes nearly 69,000 packages — against roughly 25,000 in Alpine’s main</code> and community</code> repos combined. Rather than ingest all of that up front, [yoe]</code> parses the package index files on startup and materializes units on demand, exactly as it does for Alpine. Even against a feed that size, the TUI still comes up in about a second.</p> The one place the two worlds diverge is naming. The same library often goes by a different package name on each base — Python is python3</code> on Alpine but python3.11</code> on Debian — so a unit now carries per-distro build and runtime dependencies, and the build system resolves the right ones for the image it’s assembling. Some source packages needed adjusting to compile cleanly against either base, but once that’s done a single unit builds on both. Picking a platform is then just a project setting: flip the default distro between Alpine and Debian and rebuild.</p> Choose per image, pay only where you need it</a></h2> [yoe]</code> lets you reach for the base distribution without committing the whole project to it. If you don’t have a hard reason for Debian — a glibc-only library, a vendor binary, an existing Debian fleet — Alpine keeps the image small and the defaults work. If you do, Debian’s plumbing is there: feeds resolve, packages mirror, the rootfs assembles in a single mmdebstrap</code> pass, and the project’s own repo emits a signed index.</p> The pattern this enables is mixing the two in one project — a glibc Debian host image running vendor agents and a container runtime, with small musl Alpine application containers deployed inside it. The host pays for compatibility where it needs it; the workloads stay lean. You spend the extra megabytes exactly once, exactly where they earn their place, instead of across the whole device.</p> The tradeoff is size</a></h2> Debian buys compatibility, and it costs space. To measure that honestly, we built the same minimal image on each backend: the smallest thing that boots and accepts an SSH login, with no extra developer tooling on either side. Just a kernel, an init system, libc, a shell, the package manager, sshd</code>, DHCP networking, and a login user. Same job, same qemu-x86_64</code> target.</p> Backend</th> Packages available</th> Minimal ssh-image</code> rootfs</th> Dev image assembly</th></tr></thead> Alpine</td> ~25,000</td> 85 MB</td> ~10 s</td></tr> Debian</td> ~69,000</td> 405 MB</td> ~100 s</td></tr> </tbody></table> Debian’s draw is the catalog — about 69,000 packages in main</code>, against Alpine’s ~25,000 across main</code> and community</code>. The cost is size and time: roughly 4.8× on disk — the apples-to-apples platform floor for a real device you can log into — and close to 10× in assembly. The build-time column is the cached image-assembly step for the dev image, a notch up from this minimal one; the sections below break down where each gap comes from.</p> Where the difference comes from</a></h2> Two things, and most of it is the kernel.</p> The kernel.</strong> Most of the gap is the stock linux-image-amd64</code> package — its module tree alone is about 107 MB, because a distribution kernel ships a driver for every machine it might ever run on. Alpine here boots a kernel [yoe]</code> built from source, tailored to the target, so its modules are a few megabytes rather than a hundred-plus. This part of the gap isn’t really “Debian vs Alpine” — it’s “stock distribution kernel vs tailored build,” and a production Debian image on [yoe]</code> can swap in a tailored kernel too. Out of the box, though, the distro kernel brings everything.</p> The userland.</strong> The remainder is the platform itself: glibc and its multiarch libraries, systemd and NetworkManager, the full apt and dpkg stack, complete coreutils instead of busybox applets, locales, udev rules. musl plus busybox plus OpenRC is simply a lighter foundation, and on a device that difference compounds.</p> Size isn’t the only difference — assembly is heavier too</a></h2> The two images are also assembled differently, and it comes down to what a package does</em> when it installs.</p> Assembling the Alpine image is essentially one step: apk</code> extracts the packages into the root filesystem, resolves their dependencies, and checks for file conflicts. Alpine packages are largely self-contained — the install-time logic is minimal, mostly busybox wiring up its own applet symlinks. Few moving parts, and it’s fast.</p> A Debian .deb</code> carries maintainer scripts — preinst</code>, postinst</code> — that have to run to finish the install: creating users, enabling systemd services, running ldconfig</code>, registering alternatives. So [yoe]</code> assembles the Debian rootfs with mmdebstrap</code> driving apt</code> and dpkg</code>, then runs every package’s scripts to reach a fully configured state. And because those scripts assume a complete base system is already in place, assembly carries ordering subtleties the Alpine path never hits. A concrete one: openssh-server</code>’s post-install reaches for awk</code> before the package that provides it has been configured, so the assembler pre-stages the awk</code> alternative ahead of time to keep the script from failing. For a foreign architecture, all of those scripts run under QEMU emulation as well.</p> None of this is a knock on Debian — that maintainer-script model is exactly what makes the broad apt ecosystem drop in and just work</em>, users and services configured the way the package author intended. It’s the same tradeoff as the size: the richness that earns Debian its place is also what makes it heavier to assemble. Alpine does less at install time, so there’s less to do at build time.</p> It shows up on the clock, too. With every dependency package already built and cached — so the timer captures only the image-assembly step, not the source builds behind it — reassembling the dev image (a working image with editors and diagnostics, a notch up from the minimal one measured above) on the same qemu-x86_64</code> target takes about 10 seconds on Alpine and roughly 100 on Debian</strong>: close to a 10× gap. Alpine’s side is a single apk</code> extract; Debian’s is mmdebstrap</code> plus dpkg</code> configuring every package and running its maintainer scripts, under QEMU for a foreign architecture. The Debian time also wanders more from run to run (90–120 s), because it leans on apt and dpkg doing real work rather than a near-deterministic unpack.</p> Where it stands</a></h2> Debian support is experimental but real: the image measured above boots and accepts SSH, so it’s a device you can log into and work on, not a paper target. The build path is solid and the size numbers are measurements, not estimates. There’s still plenty to harden, and honest comparisons — like this one — are how we keep the tradeoffs in view as it matures.</p> What’s next</a></h2> Hardening the Debian path from experimental toward production — tailoring the kernel down from the stock one, and proving it out across more targets. The Videos page</a> has the full walkthrough set.</p> If you have a workload that needs glibc, we’d love to hear how it goes — open a discussion</a> or send a note</a>. To follow [yoe]</code> as it grows, star and watch the repo</a> and subscribe for updates</a> — there’s an email signup at the foot of every page, too.</p> It's Not About Competition 2026-06-02T00:00:00+00:00 Thinking competitively comes naturally - our society trains us for it. There must always be a winner and a loser. So with the Next Gen Embedded Linux</a> project, it is tempting to assume something new can only succeed if Yocto loses. That is not what I am seeing. The market keeps expanding and growing. Yocto is established and will continue to serve teams that need to build everything from source, that care deeply about binary reproducibility, and so on. Alongside them, a growing segment of companies lacks the resources to maintain a Yocto build system. I keep seeing small teams with different priorities: they want a simpler way to bring advanced technology to their products. They want to lean on existing package ecosystems while keeping the tools to customize and maintain what they ship.</p> The Debian and Alpine Linux distributions offer a useful parallel. Alpine did not replace Debian; it met a different need - a lightweight base for building containers. Both keep growing because the market and its needs keep expanding.</p> </p> Fast Binary Packages from the APK Index 2026-05-29T00:00:00+00:00 The Qt post</a> mentioned that [yoe]</code> pulls packages from Alpine and presents the prebuilt binaries as virtual units. A new video</a> digs into how that works now, because the mechanism recently changed in a way that’s worth explaining: instead of generating a file per package up front, [yoe]</code> reads Alpine’s package index directly and builds units on demand.</p> The old way: a file per package</a></h2> The previous approach was to keep an alpine/units</code> folder full of autogenerated files, each one wrapping a single Alpine package. main</code> had over 2,000 of them. Scripts generated and updated the set. The community repo was handled more lazily — it has over 10,000 packages, and generating a wrapper file for every one wasn’t worth it, so those were generated only as needed.</p> This worked. But it meant carrying thousands of generated artifacts in the module and keeping them in sync with upstream.</p> Parse the index instead</a></h2> Alpine already ships an APK index that contains exactly the information those wrapper files were duplicating — each package’s metadata and its dependencies. So the question became: why generate the files at all? Parse the index, and construct a virtual unit for any Alpine package directly from it.</p> That’s the change. The Alpine module now carries just a handful of files — the APK indexes themselves. main</code> is about 2.2 MB per architecture and lists roughly 5,000 packages; community</code> is about 8.7 MB and lists nearly 20,000. The index is dense but simple: a flat list of packages, what each one is, and what it depends on. Everything needed to construct a unit is already in there, so there’s nothing to generate and keep in sync.</p> Only what an image needs</a></h2> There’s one more wrinkle that keeps this fast. Alpine offers around 25,000 packages across both feeds, but [yoe]</code> shows only a few hundred units — in the demo, 363. It doesn’t materialize a unit for every package in the index. On startup it scans all the images, walks their dependencies recursively, and generates virtual units only for the packages those images actually reference.</p> Adding a package is then just adding its name to an image. [yoe]</code> notices the reference, wraps the package, signs it with its key, and serves it from the [yoe]</code> feed automatically. You get access to the entire distribution without paying to enumerate it.</p> Why it matters</a></h2> This is the difference between a tool that knows about 25,000 packages and one that drags 25,000 packages around. The app starts fast and stays responsive because it holds exactly the information that images need and nothing more. The full Alpine catalog is one image edit away, but it costs nothing until you reach for it.</p> What’s next</a></h2> Possibly Debian as an additional package source alongside Alpine. The Videos page</a> has the full walkthrough set. If you’ve got thoughts on how [yoe]</code> consumes packages, open a discussion</a> or send a note</a>.</p> Qt Support in [yoe] 2026-05-29T00:00:00+00:00 [yoe]</code> can now build and run a Qt application, shown in a short demo video</a>. Qt is worth supporting because it’s the mainstay graphical toolkit for embedded native apps — if your device has a display and you want a polished interface, Qt is very often the answer. But the toolkit is just the occasion. The parts worth talking about are how those dependencies get into a build, and where the graphical app actually runs while you develop it.</p> Wrapping binaries instead of building them</a></h2> A Qt app pulls in a pile of dependencies: qtdeclarative</code>, qtbase</code>, X11, fonts. In a traditional embedded build you’d own a recipe for each — fetch source, patch it, compile it. That’s where a lot of the cost and fragility of building embedded Linux lives.</p> [yoe]</code> takes a different path: it pulls these packages straight from the Alpine community repo (and hopefully Debian will be an option soon) and presents the prebuilt binaries as virtual units. You figure out which Alpine package you need, and the build system pulls it into your feed and wraps its assets automatically. No custom recipes, no source builds for the toolkit itself.</p> This is the same mechanism behind the Python tooling for the Beagle Play BSP</a> and pip and npm on the target</a> — a flat list of pkg</code>-style dependencies that resolve against a maintained binary distribution. Adding a graphical toolkit ends up looking like adding any other dependency: name the packages, rebuild. The leverage is in not reinventing a package set that Alpine or Debian already maintains.</p> QEMU as a first-class development target</a></h2> QEMU is a really useful tool that I hadn’t used much before. I would develop apps natively, and then build an image for embedded targets, but QEMU sits between these domains and allows you to quickly and efficiently develop your image build system. [yoe]</code> makes running on QEMU easy.</p> In this development cycle support was added for enabling the QEMU display, setting the memory allocated, and configuring the network port mapping from the QEMU instance to the host.</p> What’s next</a></h2> More toolkit and application coverage, and more targets to run it on. The Videos page</a> has the full walkthrough set. If there’s an app or framework you’d like to see running under [yoe]</code>, open a discussion</a> or send a note</a>.</p> [yoe] Is Now Self-Hosting 2026-05-28T00:00:00+00:00 [yoe]</code> can now build itself. The latest video</a> walks through a short proof: build a selfhost-image</code> with [yoe]</code>, boot it in QEMU, SSH in, and run [yoe]</code> to build another image. The demo runs two levels deep — host workstation, a QEMU instance built by [yoe]</code>, and another [yoe]</code> build running inside that.</p> What’s in the image</a></h2> The selfhost-image</code> carries everything needed to develop with [yoe]</code> on the target: the yoe</code> CLI, Docker with buildx</code> and containerd</code>, the Go toolchain, git</code>, bubblewrap</code> for sandboxing, and the developer toolkit — Helix, Yazi, Zellij. A first-boot service grows the rootfs to fill the storage device.</p> Two levels deep</a></h2> The video runs [yoe]</code> inside a QEMU instance that [yoe]</code> built. SSH in from another tab — the terminal behaves better than the QEMU console — and the inner base-image</code> build is already complete. Running the result needs a port remap to avoid colliding with the outer QEMU and a memory cap below the host’s 4 GB. KVM is not available in the nested setup, so the inner boot is a bit slower, but it boots and runs.</p> Why it matters</a></h2> The interesting case is not nested QEMU. It’s a Raspberry Pi 5 with an NVMe HAT acting as a standalone [yoe]</code> build host. Builds run natively on ARM64 — no QEMU user-mode emulation in the loop — and right now that is the fastest way to build an ARM image with [yoe]</code>. It is also a step toward a build farm of cheap ARM nodes.</p> The self-host docs</a> cover the hardware: Pi 5 with 8 GB of RAM (16 GB if you want concurrent kernel or LLVM builds), NVMe via PCIe HAT for 10–20× the throughput of microSD, and a 27 W USB-PD supply to drive it.</p> What’s next</a></h2> V1 of selfhost-image</code> is single-arch, with no A/B partitioning or headless install yet. The Videos page</a> has the full walkthrough set. If you’d like to see this run on different hardware or in a build-farm configuration, open a discussion</a> or send a note</a>.</p> Running [yoe] on a Beagle Play 2026-05-21T00:00:00+00:00 [yoe]</code> now boots a Beagle Play. The latest video</a> walks through building the image, flashing the SD card, and watching the TI AM625 step through its four-stage boot. But the more interesting story is how the BSP got written: I pointed Claude Code at the existing meta-ti</code> Yocto layer, asked it to “create machine support for a Beagle Play,” and most of it landed in one shot.</p> What’s in the video</a></h2> yoe update</code> and yoe sync</code> to refresh the modules, then yoe</code> to open the TUI. Pick beagleplay</code> from the machine list, pick the development image, press F</code> to flash. [yoe]</code> figures out which block devices are removable so you can’t accidentally write to your workstation’s main disk, remembers the device you used last time, and writes the SD card.</p> Hold the user button down while powering on the board and it boots from SD instead of the on-board eMMC — useful so an old eMMC bootloader can’t sneak into the chain. The serial console then shows the boot stepping through its stages.</p> Four stages of bootloader</a></h2> The AM625 is not a simple part. The on-chip ROM brings up a 32-bit R5 core and loads a first-stage SPL onto it. That hands control to the 64-bit A53 cores, which load a second SPL, then U-Boot, then the kernel. So [yoe]</code> needs two U-Boot binaries (one 32-bit, one 64-bit), an extra 32-bit ARM toolchain alongside the default 64-bit one, and a pile of Python build-time tools that the TI build scripts call out to.</p> Those Python tools come straight from Alpine packages — no custom recipes, no source builds. Hitting e</code> on a unit pops you into your editor, and the dependency list reads as a flat enumeration of py3-</code> packages.</p> The build itself runs in a bwrap</code> sandbox against a per-unit sysroot. Dependencies are hard-linked in, so it’s fast, and the unit only sees what it declared — nothing leaks from a sibling. That sandbox is what turns “add another py3-</code> and rebuild” into a safe operation instead of a debugging adventure.</p> The part that mattered</a></h2> [yoe]</code> rests on a bet: that an AI agent can take a Yocto BSP from a vendor’s layer and reshape it into a [yoe]</code> module quickly. If that bet doesn’t hold, the project doesn’t work — every new SoC becomes a multi-week porting job, and the productivity case collapses.</p> The Beagle Play is the first real test. It’s not a Raspberry Pi clone with a mainline kernel and a one-line config. It’s a current-generation TI part with vendor-specific firmware, a 32-bit SPL stage, and a custom toolchain requirement. Claude wrote most of it from a single prompt. The remaining work was iterating on missing Python dependencies — a build would fail, the error named a missing tool, the fix was another Alpine package. A handful of cycles later, the image booted.</p> That’s the kind of porting loop the project needs to be cheap, and right now it looks like it is.</p> What’s next</a></h2> More BSPs. The Beagle Play machine docs</a> cover how to use this one, and the Videos page</a> has the full walkthrough set. If there’s a board you’d like to see ported next, open a discussion</a> or send a note</a>.</p> Why the Build Tool Is a TUI 2026-05-19T00:00:00+00:00 A terminal UI looks primitive next to a web app or a native desktop app, and those alternatives are genuinely more capable. So why does [yoe]</code> use a TUI? The latest video</a> walks through the reasoning, and it comes down to one thing: most of the work already happens in the terminal, and a TUI build tool sits right next to it.</p> We already live here</a></h2> Open a developer’s terminal and look at what’s running. An editor — Helix or Vim — for finding files and making changes. A file manager like Yazi</a> for moving through build directories. lazygit</a> for the day-to-day git work. Zellij</a> as a multiplexer, holding saved sessions that you can reattach from another machine — the demo is recorded from a laptop attached to a workstation session — split into named tabs and panes. ripgrep</code> for searching the tree.</p> These tools are fast, keyboard-driven, and composable. They are where the work happens. A build tool that opens a separate window asks you to leave that environment every time you switch between building the system and changing the code.</p> Proximity is the feature</a></h2> Because [yoe]</code> is a TUI, it starts up inside that same environment. Highlight a unit and press e</code>, and you land in the same editor you use for everything else — not a built-in editor that almost works, but your</em> editor. Press $</code> and you drop into a shell in that unit’s build directory, where yazi</code>, rg</code>, and the rest of your toolkit are already waiting.</p> A TUI is not the most powerful interface for any single one of these jobs. A native app could draw a richer view of any one of them. But the TUI inherits an effectively unbounded set of powerful, programmer-focused tools for free, and the toolkit [yoe]</code> is built on makes wiring up to them straightforward. The build tool stops being a destination you visit and becomes one more pane in the environment you never left.</p> Speed, and hands on the keyboard</a></h2> The terminal tools share another trait: you drive them from the keyboard. Switching units, opening an editor, shelling in, searching — each is a keystroke, not a trip to the mouse to hunt for the right window. Hands stay on the keyboard, and the loop between I want to change this</em> and the change is made</em> stays short.</p> That is the whole argument. A TUI is a constrained surface — characters on a screen, no pixels to spare on chrome. The constraint buys speed, keyboard control, and a clean seam between the build tool and every other tool a developer already trusts.</p> Why this matters</a></h2> The first goal in What a Modern Embedded Linux Build System Could Look Like</a> was to shrink the loop between an idea and a running image. A lot of that loop is the friction of moving between tools. Choosing a TUI removes a category of that friction by refusing to pull you out of the environment where the rest of the work already lives.</p> The full set of walkthroughs is on the Videos page</a>. What part of the workflow would you like to see next? Open a discussion</a> or send a note</a>.</p> Editing a Unit's Source Without Leaving the Build 2026-05-15T00:00:00+00:00 Editing the source of a unit is one of the most common things you do while building an embedded Linux system. You hit a bug in an application, you need a patch in the kernel, you want to try a change before it lands upstream. In most build systems that means dropping out of the tool, cloning the repo somewhere else, wiring up a patch or a local override, and rebuilding. The latest walkthrough</a> shows [yoe]</code> doing the whole loop in place.</p> Pinned by default, development on demand</a></h2> Every unit pins to a release tag by default and checks out over HTTPS for convenience. That is the right default for a reproducible build, but it is the wrong shape for making a change: the source lives in [yoe]</code>’s download cache, and you can’t push a fix back to a cache.</p> Pressing the dev-mode key switches the unit over. [yoe]</code> re-points the checkout at the upstream repository, optionally swaps the HTTPS remote for the SSH URL most of us push through, and asks how much history you want. A shallow clone of 100 commits is plenty for a quick change — and for something like the Linux kernel, skipping the full history saves a large download. Shell into the source directory and you land on the upstream branch, connected to the remote you can actually push to.</p> The build follows the source</a></h2> Once a unit is in development mode, the cache key comes from a git diff</code> of the working tree rather than the pinned tag. Change a line and the cache invalidates on its own — no manual flag, no stale artifact. The unit’s status moves from pinned to dev modified</code> to dev dirty</code> as you switch modes and accumulate uncommitted changes, so the state is always visible at a glance.</p> From there the loop is short: build the unit, deploy it with a single key to the target you last deployed to, and watch the change land on the target instance. Because [yoe]</code> is built to run several sessions at once, the build and the running target sit side by side while you iterate.</p> Pinning the change back</a></h2> When a change is worth keeping, commit it in the source tree — the status drops out of dev dirty</code> — and pin the recipe to the new commit. The pin command writes the current HEAD</code> back into the unit’s tag field, preferring a real tag over a raw hash when one exists at that commit. The unit is reproducible again, now at your change, and the next build is back to a clean cached state.</p> Why this matters</a></h2> Two goals from Hello, [yoe]</a> and What a Modern Embedded Linux Build System Could Look Like</a> were to shrink the idea-to-running-image loop and to keep the application development experience tightly coupled to the system build. This workflow is that idea applied to source: one tool, one screen, and a clean switch between a pinned release and a live checkout for any unit — without the extra layers other build systems put between you and the code.</p> What part of the development loop would you like to see demoed next? Open a discussion</a> or send a note</a>.</p> When LTS fits — and when it doesn't 2026-05-14T00:00:00+00:00 LTS stands for Long-Term Support, which refers to software versions that receive updates, bug fixes, and security patches for an extended period, typically aimed at providing stability and reliability. For deeply embedded, single-purpose systems, or locked-down enterprise laptops where users are not allowed to install software, LTS makes sense.</p> For dynamic software systems (the browser is a good example), the only path is forward. It’s hard to predict exactly what pages need loading tomorrow, where the user will go next, what problems will occur, what security issues need patching, what new features need supporting, etc. Edge systems are trending in that direction. They are capable, expandable platforms whose future needs are hard to predict.</p> Trying to keep an operating system pinned to an LTS release while continuously evolving everything on top is a bit like freezing a creature’s skeleton while expecting the rest of its body to grow and adapt around it. The structure may be stable, but over time the muscles, organs, and connective tissue stop fitting cleanly. Eventually, the mismatch creates friction, limits movement, and makes further growth harder instead of easier.</p> When implementing an embedded OS, it’s important to decide: is this 1) a traditional static embedded system, or 2) a dynamic edge system? These are different problems and require different tool-sets. [yoe]</code> is being built for the second case — see What a Modern Embedded Linux Build System Could Look Like</a> for where that’s headed.</p> </p> Pip and Npm Belong on the Target too 2026-05-13T00:00:00+00:00 Application developers reach for pip install</code> or npm install</code> without thinking. The moment that code needs to land on an embedded Linux target, the same one-line dependency install usually becomes a hand-written recipe per package. That’s the friction the third walkthrough</a> aims to remove.</p> The idea</a></h2> Let the language’s own package manager do the resolution. Capture its output. Ship it.</p> [yoe]</code> now has units for three runtimes:</p> Python</a></strong> — a virtual-environment class creates a venv named after the unit, runs pip install</code>, and packages the resulting venv as an .apk</code> that the target installs directly. Each application gets its own venv, so dependencies stay isolated.</li> Node.js</a></strong> — npm install</code> runs at build time, and node_modules/</code> rides along with the app in the same package.</li> Bun</a></strong> — same flow as Node, but with the lighter-weight Zig-based runtime. Worth a look if you want a smaller footprint than full Node on the target.</li> </ul> The unit author writes the same dependency manifest they’d write on their laptop — requirements.txt</code>, package.json</code>. The build system handles the rest, including pulling in any development dependencies — compilers, headers, native build tools — that pip or npm need to compile packages with C or Rust extensions. Those tools live in the build environment, not on the target.</p> Python in particular benefits from the wheel ecosystem: pip caches built wheels extensively, and most of PyPI is now distributed as prebuilt wheels for common architectures. [yoe]</code> is set up to leverage those caches rather than rebuild from source on every run, which keeps Python builds fast even when the dependency graph is large.</p> Why this matters</a></h2> Two of the goals in Hello, [yoe]</a> and What a Modern Embedded Linux Build System Could Look Like</a> were: don’t reinvent dependency resolution, and don’t force application developers to learn a second packaging system to ship what they already wrote. This is what that looks like in practice — pip, npm, and bun composed in rather than replaced.</p> What’s next</a></h2> Rust and Zig units are queued up next, along with Python ML workloads where the dependency graph gets a lot more interesting. The YouTube playlist</a> is the place to subscribe for new walkthroughs as features land.</p> What development workflow would you like to see demoed next? Open a discussion</a> or send a note</a>.</p> First Walkthroughs: Overview and Package Deploy 2026-05-12T00:00:00+00:00 A build system is easier to evaluate when you can watch it in motion. The first two walkthroughs are up on the Videos page</a>, and they cover the parts of [yoe]</code> that are most different from what you’d expect coming from Yocto or Buildroot.</p> Video 1 — Overview</a></h2> A tour of the build system end-to-end: yoe init</code> to scaffold a project, the TUI with its live progress bar, background builds, search, and inline status — all in one screen. Then yoe run</code> to boot the resulting image in QEMU. The aim is to show the full idea-to-running-image loop without an SDK install, a cross-toolchain, or generated shell scripts to read through.</p> If you’ve only seen the earlier post</a>, this is the version where the claims become concrete.</p> Video 2 — Deploying packages</a></h2> The iteration loop, zoomed in. Once an image is running, the interesting question is how fast you can change a package on the target and try the new version. This video walks through building a package, resolving its dependencies, and pushing the result to a live target in a single step — no full image rebuild, no manual scp</code> dance.</p> This is the part of the experience that most rewards the design decisions in Hello, [yoe]</a>: one binary, language-native package managers composed in, and content-addressed .apk</code> outputs that the target can install directly.</p> What’s next</a></h2> More videos are planned as features land — Docker on the target, Go and Rust units, BSP authoring, and the AI-assisted workflows. The full playlist lives on the Videos page</a>, and the YouTube playlist</a> is the place to subscribe if you’d like a ping when new ones go up.</p> Feedback is welcome — what would you want to see demoed next? Open a discussion</a> or send a note</a>.</p> What a Modern Embedded Linux Build System Could Look Like 2026-05-11T00:00:00+00:00 Seven weeks ago we started experimenting</a> to find out. The result is a tool that builds QEMU and Raspberry Pi images today, with Docker support working. The goals driving the project, and where each one stands so far:</p> Drastically improve developer productivity</strong> — shrink the loop between an idea and a running image. Today: one binary, no SDK to install. yoe init && yoe</code> opens a TUI with a live build progress bar, and yoe run</code> boots the image in QEMU. Background builds, search, and inline status sit in one screen.</li> Easily integrate complex workloads</strong> — let modern languages keep their own package managers, and let containers ride along. Today: Go modules build end-to-end, and Docker runs on the resulting image. Rust, Zig, and Python ML come next.</li> Scale to build anything</strong> — one tool, one mental model from small images to distributed systems. Today: two modules (module-core</code>, module-rpi</code>) covering x86_64 QEMU and Raspberry Pi, with QEMU user-mode emulation building ARM64 on x86 — no cross-toolchain. Zephyr, AI workloads, distributed builds, and farm-scale caching are still ahead.</li> </ol> There is a long way to go, and the risks are real. But seven weeks in — 38 releases, a working build flow — the path forward feels solid.</p> </p> Hello, [yoe] 2026-05-02T00:00:00+00:00 After years of maintaining and shipping products with the Yoe Distribution</a>, we kept running into the same friction — much of it inherited from how embedded Linux has historically been built. We started fresh, kept the lessons that mattered most, and built the tool we always wanted to use.</p> What we kept</a></h2> Machine abstraction and image composition.</strong> Yocto got a lot right here.</li> Module composition.</strong> Pulling units directly from GitHub URLs scales naturally to vendor BSPs.</li> Tracking upstream closely.</strong> The cloud has been doing this for a decade.</li> </ul> What we dropped</a></h2> Cross-compilation as the default.</strong> Modern ARM and RISC-V boards build natively at full speed. Cloud CI runs arm64 cheaper than ever. QEMU user-mode emulation covers the rest.</li> The SDK boundary.</strong> One Go binary builds the kernel, the rootfs, and the application — no frozen sysroot, no drift between teams, one shared view of the build.</li> Reinventing dependency resolution.</strong> Cargo, Go modules, pip, and npm already solved this. [yoe]</code> composes with them instead of replacing them.</li> Generated shell scripts.</strong> When something fails, you read the code you wrote — not a stack trace deep in machine-generated output.</li> </ul> What we’re betting on</a></h2> AI as a first-class interface.</strong> Starlark units, queryable graphs, structured logs. An assistant that understands the system can take the cognitive load of “which knob, and why” off the developer.</li> One tool, three interfaces.</strong> AI conversation, interactive TUI, traditional CLI — same engine, same commands. Use whichever fits the moment.</li> Functional equivalence over bit-for-bit reproducibility.</strong> Hermetic builds and content-addressed input hashing, without the years-long effort required for bit-perfect reproducibility.</li> </ul> [yoe]</code> is pre-1.0 and moving fast. Take it for a spin and let us know how it goes — we’d love to hear what works for you and what doesn’t.</p> The opportunity is here … come build the future of embedded Linux with us.</p> — Cliff Brake</p>

Is It Time for a New Embedded Linux Build System?

2026-06-11T00:00:00+00:00

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

The Embedded Systems Golden Age</a></h2>
We live in a remarkable time for embedded systems engineering. We have:</p>

A large number of Linux system-on-modules (SOMs), perfect hardware building blocks for industrial products.</li>
Zephyr, an excellent OS for building software on MCU platforms.</li>
Mature tools (compilers, build systems, etc.).</li>
A vast array of open source software we can apply to these systems.</li>
Fast, reasonably priced prototyping (PCB assembly, mechanical 3D printing, etc.).</li>
More vendors upstreaming their Linux kernel support.</li>
Yocto’s solid tooling for building images and custom parts of the system.</li> </ul>
And all of this is available to companies of any size. It’s a bit like inheriting a mansion: open source has handed us a sprawling house full of rooms and features we’d never have built ourselves, and we have to live in it to stay competitive. The catch is that nobody handed us the tools to keep the place running. There is nothing holding us back, except our ability to put it all together.</p>
How Embedded Linux Systems are currently built</a></h2>
Embedded Linux build systems solve the problem of putting all the pieces together, and the existing ones have served us well. Buildroot (2001) and OpenEmbedded/Yocto (2003) are now the standard, supported by most SOC/SOM vendors, and some teams ship successfully on Debian, Ubuntu, or even Arch (as Valve does with the Steam Deck).</p>
The shape of mainstream embedded Linux development has held remarkably steady for ~20 years: cross-compile on a powerful x86 workstation, assemble a BSP (board support package), freeze an SDK (software development kit), ship the image, and hold that line for years. It’s a model built for a static, single-purpose, rarely updated product, and until recently, for that product, it worked well.</p>
But things are changing …</a></h2>
The products have changed more than the tools that build them. Edge devices have started behaving like cloud systems. They run containers, pull OTA (over the air) updates, stream telemetry, and are managed remotely over their entire life. A device is no longer a static artifact you flash once and forget; it’s a system that keeps moving forward after it ships. That inverts the old release cadence: instead of freezing an SDK and holding it for years, teams track upstream continuously and push updates as a matter of course. The long LTS (long-term support) freeze that the cross-compile model was built around no longer fits a new class of products.</p>
At the same time, the software itself has outgrown the cross-compile model. Modern languages each ship their own package ecosystem: Python (wrapping C/C++/CUDA via NumPy and PyTorch), JavaScript (linking to C libraries), Go, Rust, and vcpkg (for C/C++). Most of it is written for desktop/server, not cross-compilation. That puts the cross-compile burden squarely on embedded developers, and maintaining recipes for thousands of packages has been a steady drain on the Yocto community. Yocto compounds this by blocking network access during the build, so language package tooling doesn’t work without complex `do_fetch</code> integration. That’s useful when you must control every source, but unnecessary friction for many projects.</p>`
`Each of these solutions trades one problem for another. Building everything from source in Yocto means long builds, heavy memory use, and powerful workstations. A stock binary distro like Debian starts development faster but lacks the tooling to integrate the custom parts. And vendor BSPs frozen on a 4-year-old Yocto make it hard to integrate modern software at all.</p>`
`We could go on, but the cause is structural. Talented teams working hard still hit this, because the problem is inherently difficult and the software keeps getting harder to build.</p>`
`To summarize, three things have changed:</p>`
`Products never stop moving.</strong> Edge devices now behave like cloud systems: continuous OTA updates, not a multi-year freeze.</li> Software outgrew cross-compilation.</strong> Every modern language brings its own package ecosystem that doesn’t always cross-compile cleanly.</li>`The old tradeoffs got sharper.</strong> Build-from-source is slow and heavy; stock distros lack custom tooling; BSPs freeze you in time.</li> </ol> The old model is good. The real question is whether it still fits the product you’re building and the team you have.</p> Small teams have different problems, not smaller ones</a></h2> I’ve been talking to a lot of people building products, and keep hearing a consistent message. First, the ground has shifted: both the products and the way we have to put them together. Second, what works for a big team doesn’t always work for a small one.</p> Small teams and startups need to build and ship. They often don’t have the resources to sustain multi-year development cycles. They don’t have dedicated build or platform engineers experienced in creating complex build infrastructure and debugging hard build problems. Simplicity and ease of build/deployment often matter more than binary-reproducible builds or building everything from scratch. Easily deploying the latest open-source releases is frequently required to leverage new technologies.</p> These teams are often hampered by three things: vendor BSPs that lock them into old versions of Yocto, frustrating debug cycles where a critical component won’t build, and the heavy effort of back-porting needed components into a system frozen in time. A large organization can hire dedicated experts and throw resources at these problems. A small organization does not have this luxury.</p> To be clear, small != hobbyist. These are often startups or industrial products produced at moderate scale (100’s to 1000’s of units) that sit between the one-off maker projects and consumer scale mass production.</p> The new opportunity</a></h2> Buildroot and OpenEmbedded were created in an era when ARM-based computers were slow, and cross-compiling software on powerful x86 workstations was the only practical option. When we were building a limited set of C/C++-based applications, these systems worked great. However, several things have changed in recent times:</p> Application development is moving to modern languages (Python, JS, Go, Rust, Zig). These languages have their own package ecosystems, caching, etc.</li> The hardware story has flipped. We now have fast ARM computers (AWS Graviton, Hetzner CAX) available for building and are no longer constrained to x86 workstations.</li> AI has emerged as a powerful tool for creating software, including build systems.</li> </ol> We need to leverage these change agents and rethink the world of connected products. The key shift is this: stop borrowing only the technology</em> of modern ecosystems, and start borrowing their process</em> too. When we adopt Rust or Python and take the language but force it into the old build process, it’s a bit like running a train on a paved road. The win comes from adopting how those ecosystems build, package, and cache, not just what they produce.</p> We now have an opportunity to rethink embedded Linux build systems. For me, this got personal. It hit me recently — if I’m going to keep doing this for another 20 years, I want something different, something that better fits the problems my customers and I are actually trying to solve, instead of fighting the tools.</p> So I’ve been experimenting. Over the past couple of months I’ve been building real pieces of this in the open, and the early results have been encouraging: software that used to mean a day of fighting cross-compilation now goes from idea to running on target hardware in minutes, using the same tooling on my laptop and in CI. It’s rough and early, but it’s enough to convince me this approach is worth pursuing.</p> What if …</a></h2> … we could:</p> Get to market faster.</strong> Shorten the path from idea to a working product. Takes an idea to running on target hardware in seconds to minutes, not days or weeks.</li> Doesn’t require cross-compilation.</li> Leverages modern language ecosystems (Python, JavaScript, Rust, Go, Zig, pkgbuild, etc.).</li> Caches builds so no piece of software is built twice.</li> Provides the convenience of pre-built packages from mainstream distributions with the tooling benefits of Yocto.</li> </ul> </li> Do more with a small team.</strong> One toolset the whole team (and AI) can use, so you don’t need dedicated build specialists. Provides one build system for applications and system software: the same tooling on laptop, cloud CI, and build farms.</li> Is easy for humans and AI to understand.</li> Includes tooling that works well with AI agents.</li> Leverages AI to do most of the low-level work.</li> Provides error messages that clearly point to the problem.</li> </ul> </li> Keep products current and supportable in the field.</strong> Stay on modern software and maintain devices over their whole life. Tracks current software versions easily, without being held back by vendor BSPs.</li> Scales from system to application to CI with consistent tooling throughout.</li> Deploys updates to fielded devices easily.</li> </ul> </li> </ul> (These problems seem universal, but they hit small teams disproportionately hard, since those teams rarely have dedicated resources to solve them.)</p> This is what I am experimenting with in this next-generation Embedded Linux build system</a>. A few examples of how this tool makes development easier:</p> Alpine</a>, Debian</a>, and Ubuntu</a> are all supported base distributions that get us going quickly without rebuilding the world.</li> Integrate Python and JavaScript</a> native package ecosystems instead of fighting them.</li> First-class AI support</a>.</li> The terminal user interface (TUI)</a> is fast, and allows us to easily monitor what is going on and drill down into detailed information as needed.</li> </ul> A few key features are still missing, such as distributed caching and remote build runners, but these are coming soon.</p> The old models still have their place</a></h2> None of this means the old models are going away, or should. For deeply embedded regulated products (compliance-certified, bit-reproducible, built entirely from source, and intentionally frozen for years), Yocto is battle-tested and remains the right tool. It does exactly what those products need, and it does it well.</p> We’ve seen this pattern before. Alpine Linux didn’t replace Debian. It answered a different need: minimal, container-friendly images. Both distributions still ship today, serving different points in the design space. Nobody frames it as a competition; they’re simply shaped for different jobs.</p> The same is true here. Dynamic, connected, frequently updated devices built with modern languages are a different job, and they deserve a tool built for that job.</p> So, is it time?</a></h2> For a real and growing class of teams and products, I think the answer is yes. [yoe]</code> build</a> is an early experiment exploring what that could look like. It’s pre-1.0 and developed in the open, rough edges and all. It’s a bet that this is a problem worth solving, and an invitation to work out the shape of the solution together.</p> It depends on you: the teams building products and the vendors that support them. Provide feedback. What am I missing? Test it out and let me know how it works. Sign up</a> for my newsletter. Tell your vendors you need something like this. Like/watch the GitHub repo</a>. Share it with someone who might be interested. Contribute improvements. Fund development or infrastructure. Many small teams need this, and these small companies form a significant portion of the global economy (the long tail). Startups are where a lot of innovation happens. And if a community emerges who can leverage modern AI tools, it will happen. The progress in the past two months</a> demonstrates this is possible.</p>

Adding Ubuntu — almost for free

2026-06-08T00:00:00+00:00

Standing up the Debian backend was real work — mmdebstrap</code> rootfs assembly, .deb</code> packaging, on-device apt, a glibc toolchain alongside the musl one. Adding Ubuntu on top of that was almost free. Thelatest video</a> walks through it, and the headline is how little there was to do: Ubuntu is apt, so it rides the same machinery, and a [yoe]</code> project can now build Alpine, Debian, and Ubuntu images side by side.</p>

One backend, a family of distros</a></h2> The interesting part isn’t Ubuntu itself — it’s what Ubuntu proves. The Debian work</a> built out the apt plumbing: the mmdebstrap</code> assembly pass, the .deb</code> packaging path, the apt feed resolver, the on-device package manager. None of that is Debian-specific. It’s apt-family machinery, and Ubuntu is the first test of whether it generalizes.</p> It does. The Ubuntu module is thin — what differs from Debian is the feed identity, the suite ([yoe]</code> pins Ubuntu’s Resolute Raccoon / 26.04 LTS), and the mirror. The packaging mechanism, the dependency model, the rootfs assembly are all shared. The clearest sign of that is in the code itself: the old debian_feed</code> class generalized into an apt_feed</code> class, with Debian and Ubuntu as two configurations of it rather than two implementations. That’s the bet paying off — the second backend wasn’t “Debian support,” it was “apt support,” and the marginal cost of the next distro in the family turns out to be small.</p> The one place they diverge: zstd</a></h2> Not quite zero, though. Ubuntu compresses its .deb</code> payloads with zstd where Debian leans on xz, and that surfaced a bug in the packaging path — the kind of detail that stays hidden until a second distro in the same family exercises it. Once fixed, the rest fell into line. A useful reminder that “almost the same” is where the sharp edges live, and that a second consumer of shared code is the cheapest way to find them.</p> Three distros, one project</a></h2> In the demo, switching from Debian to Ubuntu is a settings change — pick the distro, pick the dev image, build. Underneath, all three bases now coexist in a single project: a yoe build-distro</code> against Alpine, Debian, and Ubuntu each resolves and builds from cache, and the build tree keeps a separate directory and package feed per distro. The Debian and Ubuntu feeds look nearly identical — which is exactly the point. You choose the base image by image, and the build system assembles whichever one the workload asks for.</p> Mixing our own source into an Ubuntu base</a></h2> One deliberate stress test in the video: rather than pull bash</code>, coreutils</code>, ca-certificates</code>, and file</code> straight from Ubuntu’s feeds, this build still compiles them from [yoe]</code>’s own source units — against Ubuntu’s libraries, in the same per-unit sandbox the rest of the system uses. Each unit builds under bwrap</code> against a sysroot hard-linked with only its declared dependencies, so it sees Ubuntu’s headers and shared libraries and nothing from the host. It’s the isolation model [yoe]</code> borrows from Yocto, pointed at an Ubuntu base.</p> You wouldn’t ship it this way — for a production image you’d pin those packages to Ubuntu’s own binaries and let the distro maintain them. The point of building them from source here is to exercise the whole mechanism end to end: our source packages compiling cleanly against an apt-family base, with the dependency resolution and sandboxing doing their jobs.</p> Where it stands</a></h2> Honest status: the base image boots in QEMU on Ubuntu’s own stock kernel, and the foundation is solid enough to build and run a development image. It’s main</code> only for now — a little over 6,000 packages — with universe, where most of Ubuntu’s catalog actually lives, still to be wired in.</p> It’s also big. Building the same development image on each backend, against the same qemu-x86_64</code> target, the assembled rootfs comes out to:</p> Backend</th> Dev-image rootfs</th></tr></thead> Alpine</td> ~230 MB</td></tr> Debian</td> ~390 MB</td></tr> Ubuntu</td> ~1,130 MB</td></tr> </tbody></table> That Ubuntu figure looks alarming next to the others, but it’s mostly low-hanging fruit. Two directories account for the bulk of it: linux-firmware</code> ships 677 MB</strong> of vendor blobs for every device the distro might ever boot on, and the stock kernel’s module tree adds another 154 MB</strong> — together about 70% of the image. A real device needs the firmware and modules for its own silicon, not the entire catalog, so trimming linux-firmware</code> to the target’s blobs and swapping the distro kernel for a tailored build cuts the image roughly in half before touching anything else. Locales, docs, and man pages are easy wins on top of that. It’s the same size story Debian tells</a> — most of the weight is stock-distribution generality, and most of it comes off once you know the target.</p> The encouraging result is the one the video opens with: supporting another distribution in this family was not a lot of work. The next focus is moving past QEMU onto real hardware, and trading the stock distro kernel for a custom one — which is where embedded Linux gets interesting.</p> Get involved</a></h2> The full set of walkthroughs is on the Videos page</a>. A few ways to go further:</p> Try a build</strong> — the Getting Started guide</a> covers install and your first image.</li> Star and watch the repo</strong> — star it and click Watch to follow progress on GitHub</a>.</li> Subscribe to the newsletter</strong> — occasional progress notes; the email signup is at the foot of every page on yoebuild.org</a>.</li> Add a machine or image</strong> — the /new-machine</code> and /new-module</code> AI skills</a> scaffold support for new boards and distros.</li> Open a discussion</strong> — questions, ideas, or a board you’d like ported next go in GitHub Discussions</a>.</li> Send a note</strong> — reach the team at info@yoebuild.org</a>.</li> </ul> Adding Debian — and what it weighs 2026-06-03T00:00:00+00:00 [yoe]</code> started Alpine-first: musl, busybox, OpenRC, and apk</code>. That stack is small, fast, and clean to wrap, and it remains the default for new projects. But not every workload fits it. Some binaries are built for glibc and never ported to musl — CUDA, vendor camera and radio drivers, a lot of enterprise software. Some teams already run a Debian/Ubuntu-based fleet and want their edge devices to match it. And the apt ecosystem is vast.</p> So [yoe]</code> now has a second backend: Debian. The latest video</a> walks through it. The same project can build Alpine and Debian images side by side, choosing the distro per image. A unit’s source build runs in whichever toolchain the consuming image needs — musl for an Alpine image, glibc for a Debian one — and produces a libc-correct binary either way. You pick the platform the workload requires, image by image.</p> The same machinery, a much bigger feed</a></h2> Under the hood, the Debian backend reuses the unit model Alpine already runs on. [yoe]</code> targets Trixie, Debian’s current stable release, and Debian main alone exposes nearly 69,000 packages — against roughly 25,000 in Alpine’s main</code> and community</code> repos combined. Rather than ingest all of that up front, [yoe]</code> parses the package index files on startup and materializes units on demand, exactly as it does for Alpine. Even against a feed that size, the TUI still comes up in about a second.</p> The one place the two worlds diverge is naming. The same library often goes by a different package name on each base — Python is python3</code> on Alpine but python3.11</code> on Debian — so a unit now carries per-distro build and runtime dependencies, and the build system resolves the right ones for the image it’s assembling. Some source packages needed adjusting to compile cleanly against either base, but once that’s done a single unit builds on both. Picking a platform is then just a project setting: flip the default distro between Alpine and Debian and rebuild.</p> Choose per image, pay only where you need it</a></h2> [yoe]</code> lets you reach for the base distribution without committing the whole project to it. If you don’t have a hard reason for Debian — a glibc-only library, a vendor binary, an existing Debian fleet — Alpine keeps the image small and the defaults work. If you do, Debian’s plumbing is there: feeds resolve, packages mirror, the rootfs assembles in a single mmdebstrap</code> pass, and the project’s own repo emits a signed index.</p> The pattern this enables is mixing the two in one project — a glibc Debian host image running vendor agents and a container runtime, with small musl Alpine application containers deployed inside it. The host pays for compatibility where it needs it; the workloads stay lean. You spend the extra megabytes exactly once, exactly where they earn their place, instead of across the whole device.</p> The tradeoff is size</a></h2> Debian buys compatibility, and it costs space. To measure that honestly, we built the same minimal image on each backend: the smallest thing that boots and accepts an SSH login, with no extra developer tooling on either side. Just a kernel, an init system, libc, a shell, the package manager, sshd</code>, DHCP networking, and a login user. Same job, same qemu-x86_64</code> target.</p> Backend</th> Packages available</th> Minimal ssh-image</code> rootfs</th> Dev image assembly</th></tr></thead> Alpine</td> ~25,000</td> 85 MB</td> ~10 s</td></tr> Debian</td> ~69,000</td> 405 MB</td> ~100 s</td></tr> </tbody></table> Debian’s draw is the catalog — about 69,000 packages in main</code>, against Alpine’s ~25,000 across main</code> and community</code>. The cost is size and time: roughly 4.8× on disk — the apples-to-apples platform floor for a real device you can log into — and close to 10× in assembly. The build-time column is the cached image-assembly step for the dev image, a notch up from this minimal one; the sections below break down where each gap comes from.</p> Where the difference comes from</a></h2> Two things, and most of it is the kernel.</p> The kernel.</strong> Most of the gap is the stock linux-image-amd64</code> package — its module tree alone is about 107 MB, because a distribution kernel ships a driver for every machine it might ever run on. Alpine here boots a kernel [yoe]</code> built from source, tailored to the target, so its modules are a few megabytes rather than a hundred-plus. This part of the gap isn’t really “Debian vs Alpine” — it’s “stock distribution kernel vs tailored build,” and a production Debian image on [yoe]</code> can swap in a tailored kernel too. Out of the box, though, the distro kernel brings everything.</p> The userland.</strong> The remainder is the platform itself: glibc and its multiarch libraries, systemd and NetworkManager, the full apt and dpkg stack, complete coreutils instead of busybox applets, locales, udev rules. musl plus busybox plus OpenRC is simply a lighter foundation, and on a device that difference compounds.</p> Size isn’t the only difference — assembly is heavier too</a></h2> The two images are also assembled differently, and it comes down to what a package does</em> when it installs.</p> Assembling the Alpine image is essentially one step: apk</code> extracts the packages into the root filesystem, resolves their dependencies, and checks for file conflicts. Alpine packages are largely self-contained — the install-time logic is minimal, mostly busybox wiring up its own applet symlinks. Few moving parts, and it’s fast.</p> A Debian .deb</code> carries maintainer scripts — preinst</code>, postinst</code> — that have to run to finish the install: creating users, enabling systemd services, running ldconfig</code>, registering alternatives. So [yoe]</code> assembles the Debian rootfs with mmdebstrap</code> driving apt</code> and dpkg</code>, then runs every package’s scripts to reach a fully configured state. And because those scripts assume a complete base system is already in place, assembly carries ordering subtleties the Alpine path never hits. A concrete one: openssh-server</code>’s post-install reaches for awk</code> before the package that provides it has been configured, so the assembler pre-stages the awk</code> alternative ahead of time to keep the script from failing. For a foreign architecture, all of those scripts run under QEMU emulation as well.</p> None of this is a knock on Debian — that maintainer-script model is exactly what makes the broad apt ecosystem drop in and just work</em>, users and services configured the way the package author intended. It’s the same tradeoff as the size: the richness that earns Debian its place is also what makes it heavier to assemble. Alpine does less at install time, so there’s less to do at build time.</p> It shows up on the clock, too. With every dependency package already built and cached — so the timer captures only the image-assembly step, not the source builds behind it — reassembling the dev image (a working image with editors and diagnostics, a notch up from the minimal one measured above) on the same qemu-x86_64</code> target takes about 10 seconds on Alpine and roughly 100 on Debian</strong>: close to a 10× gap. Alpine’s side is a single apk</code> extract; Debian’s is mmdebstrap</code> plus dpkg</code> configuring every package and running its maintainer scripts, under QEMU for a foreign architecture. The Debian time also wanders more from run to run (90–120 s), because it leans on apt and dpkg doing real work rather than a near-deterministic unpack.</p> Where it stands</a></h2> Debian support is experimental but real: the image measured above boots and accepts SSH, so it’s a device you can log into and work on, not a paper target. The build path is solid and the size numbers are measurements, not estimates. There’s still plenty to harden, and honest comparisons — like this one — are how we keep the tradeoffs in view as it matures.</p> What’s next</a></h2> Hardening the Debian path from experimental toward production — tailoring the kernel down from the stock one, and proving it out across more targets. The Videos page</a> has the full walkthrough set.</p> If you have a workload that needs glibc, we’d love to hear how it goes — open a discussion</a> or send a note</a>. To follow [yoe]</code> as it grows, star and watch the repo</a> and subscribe for updates</a> — there’s an email signup at the foot of every page, too.</p> It's Not About Competition 2026-06-02T00:00:00+00:00 Thinking competitively comes naturally - our society trains us for it. There must always be a winner and a loser. So with the Next Gen Embedded Linux</a> project, it is tempting to assume something new can only succeed if Yocto loses. That is not what I am seeing. The market keeps expanding and growing. Yocto is established and will continue to serve teams that need to build everything from source, that care deeply about binary reproducibility, and so on. Alongside them, a growing segment of companies lacks the resources to maintain a Yocto build system. I keep seeing small teams with different priorities: they want a simpler way to bring advanced technology to their products. They want to lean on existing package ecosystems while keeping the tools to customize and maintain what they ship.</p> The Debian and Alpine Linux distributions offer a useful parallel. Alpine did not replace Debian; it met a different need - a lightweight base for building containers. Both keep growing because the market and its needs keep expanding.</p> </p> Fast Binary Packages from the APK Index 2026-05-29T00:00:00+00:00 The Qt post</a> mentioned that [yoe]</code> pulls packages from Alpine and presents the prebuilt binaries as virtual units. A new video</a> digs into how that works now, because the mechanism recently changed in a way that’s worth explaining: instead of generating a file per package up front, [yoe]</code> reads Alpine’s package index directly and builds units on demand.</p> The old way: a file per package</a></h2> The previous approach was to keep an alpine/units</code> folder full of autogenerated files, each one wrapping a single Alpine package. main</code> had over 2,000 of them. Scripts generated and updated the set. The community repo was handled more lazily — it has over 10,000 packages, and generating a wrapper file for every one wasn’t worth it, so those were generated only as needed.</p> This worked. But it meant carrying thousands of generated artifacts in the module and keeping them in sync with upstream.</p> Parse the index instead</a></h2> Alpine already ships an APK index that contains exactly the information those wrapper files were duplicating — each package’s metadata and its dependencies. So the question became: why generate the files at all? Parse the index, and construct a virtual unit for any Alpine package directly from it.</p> That’s the change. The Alpine module now carries just a handful of files — the APK indexes themselves. main</code> is about 2.2 MB per architecture and lists roughly 5,000 packages; community</code> is about 8.7 MB and lists nearly 20,000. The index is dense but simple: a flat list of packages, what each one is, and what it depends on. Everything needed to construct a unit is already in there, so there’s nothing to generate and keep in sync.</p> Only what an image needs</a></h2> There’s one more wrinkle that keeps this fast. Alpine offers around 25,000 packages across both feeds, but [yoe]</code> shows only a few hundred units — in the demo, 363. It doesn’t materialize a unit for every package in the index. On startup it scans all the images, walks their dependencies recursively, and generates virtual units only for the packages those images actually reference.</p> Adding a package is then just adding its name to an image. [yoe]</code> notices the reference, wraps the package, signs it with its key, and serves it from the [yoe]</code> feed automatically. You get access to the entire distribution without paying to enumerate it.</p> Why it matters</a></h2> This is the difference between a tool that knows about 25,000 packages and one that drags 25,000 packages around. The app starts fast and stays responsive because it holds exactly the information that images need and nothing more. The full Alpine catalog is one image edit away, but it costs nothing until you reach for it.</p> What’s next</a></h2> Possibly Debian as an additional package source alongside Alpine. The Videos page</a> has the full walkthrough set. If you’ve got thoughts on how [yoe]</code> consumes packages, open a discussion</a> or send a note</a>.</p> Qt Support in [yoe] 2026-05-29T00:00:00+00:00 [yoe]</code> can now build and run a Qt application, shown in a short demo video</a>. Qt is worth supporting because it’s the mainstay graphical toolkit for embedded native apps — if your device has a display and you want a polished interface, Qt is very often the answer. But the toolkit is just the occasion. The parts worth talking about are how those dependencies get into a build, and where the graphical app actually runs while you develop it.</p> Wrapping binaries instead of building them</a></h2> A Qt app pulls in a pile of dependencies: qtdeclarative</code>, qtbase</code>, X11, fonts. In a traditional embedded build you’d own a recipe for each — fetch source, patch it, compile it. That’s where a lot of the cost and fragility of building embedded Linux lives.</p> [yoe]</code> takes a different path: it pulls these packages straight from the Alpine community repo (and hopefully Debian will be an option soon) and presents the prebuilt binaries as virtual units. You figure out which Alpine package you need, and the build system pulls it into your feed and wraps its assets automatically. No custom recipes, no source builds for the toolkit itself.</p> This is the same mechanism behind the Python tooling for the Beagle Play BSP</a> and pip and npm on the target</a> — a flat list of pkg</code>-style dependencies that resolve against a maintained binary distribution. Adding a graphical toolkit ends up looking like adding any other dependency: name the packages, rebuild. The leverage is in not reinventing a package set that Alpine or Debian already maintains.</p> QEMU as a first-class development target</a></h2> QEMU is a really useful tool that I hadn’t used much before. I would develop apps natively, and then build an image for embedded targets, but QEMU sits between these domains and allows you to quickly and efficiently develop your image build system. [yoe]</code> makes running on QEMU easy.</p> In this development cycle support was added for enabling the QEMU display, setting the memory allocated, and configuring the network port mapping from the QEMU instance to the host.</p> What’s next</a></h2> More toolkit and application coverage, and more targets to run it on. The Videos page</a> has the full walkthrough set. If there’s an app or framework you’d like to see running under [yoe]</code>, open a discussion</a> or send a note</a>.</p> [yoe] Is Now Self-Hosting 2026-05-28T00:00:00+00:00 [yoe]</code> can now build itself. The latest video</a> walks through a short proof: build a selfhost-image</code> with [yoe]</code>, boot it in QEMU, SSH in, and run [yoe]</code> to build another image. The demo runs two levels deep — host workstation, a QEMU instance built by [yoe]</code>, and another [yoe]</code> build running inside that.</p> What’s in the image</a></h2> The selfhost-image</code> carries everything needed to develop with [yoe]</code> on the target: the yoe</code> CLI, Docker with buildx</code> and containerd</code>, the Go toolchain, git</code>, bubblewrap</code> for sandboxing, and the developer toolkit — Helix, Yazi, Zellij. A first-boot service grows the rootfs to fill the storage device.</p> Two levels deep</a></h2> The video runs [yoe]</code> inside a QEMU instance that [yoe]</code> built. SSH in from another tab — the terminal behaves better than the QEMU console — and the inner base-image</code> build is already complete. Running the result needs a port remap to avoid colliding with the outer QEMU and a memory cap below the host’s 4 GB. KVM is not available in the nested setup, so the inner boot is a bit slower, but it boots and runs.</p> Why it matters</a></h2> The interesting case is not nested QEMU. It’s a Raspberry Pi 5 with an NVMe HAT acting as a standalone [yoe]</code> build host. Builds run natively on ARM64 — no QEMU user-mode emulation in the loop — and right now that is the fastest way to build an ARM image with [yoe]</code>. It is also a step toward a build farm of cheap ARM nodes.</p> The self-host docs</a> cover the hardware: Pi 5 with 8 GB of RAM (16 GB if you want concurrent kernel or LLVM builds), NVMe via PCIe HAT for 10–20× the throughput of microSD, and a 27 W USB-PD supply to drive it.</p> What’s next</a></h2> V1 of selfhost-image</code> is single-arch, with no A/B partitioning or headless install yet. The Videos page</a> has the full walkthrough set. If you’d like to see this run on different hardware or in a build-farm configuration, open a discussion</a> or send a note</a>.</p> Running [yoe] on a Beagle Play 2026-05-21T00:00:00+00:00 [yoe]</code> now boots a Beagle Play. The latest video</a> walks through building the image, flashing the SD card, and watching the TI AM625 step through its four-stage boot. But the more interesting story is how the BSP got written: I pointed Claude Code at the existing meta-ti</code> Yocto layer, asked it to “create machine support for a Beagle Play,” and most of it landed in one shot.</p> What’s in the video</a></h2> yoe update</code> and yoe sync</code> to refresh the modules, then yoe</code> to open the TUI. Pick beagleplay</code> from the machine list, pick the development image, press F</code> to flash. [yoe]</code> figures out which block devices are removable so you can’t accidentally write to your workstation’s main disk, remembers the device you used last time, and writes the SD card.</p> Hold the user button down while powering on the board and it boots from SD instead of the on-board eMMC — useful so an old eMMC bootloader can’t sneak into the chain. The serial console then shows the boot stepping through its stages.</p> Four stages of bootloader</a></h2> The AM625 is not a simple part. The on-chip ROM brings up a 32-bit R5 core and loads a first-stage SPL onto it. That hands control to the 64-bit A53 cores, which load a second SPL, then U-Boot, then the kernel. So [yoe]</code> needs two U-Boot binaries (one 32-bit, one 64-bit), an extra 32-bit ARM toolchain alongside the default 64-bit one, and a pile of Python build-time tools that the TI build scripts call out to.</p> Those Python tools come straight from Alpine packages — no custom recipes, no source builds. Hitting e</code> on a unit pops you into your editor, and the dependency list reads as a flat enumeration of py3-</code> packages.</p> The build itself runs in a bwrap</code> sandbox against a per-unit sysroot. Dependencies are hard-linked in, so it’s fast, and the unit only sees what it declared — nothing leaks from a sibling. That sandbox is what turns “add another py3-</code> and rebuild” into a safe operation instead of a debugging adventure.</p> The part that mattered</a></h2> [yoe]</code> rests on a bet: that an AI agent can take a Yocto BSP from a vendor’s layer and reshape it into a [yoe]</code> module quickly. If that bet doesn’t hold, the project doesn’t work — every new SoC becomes a multi-week porting job, and the productivity case collapses.</p> The Beagle Play is the first real test. It’s not a Raspberry Pi clone with a mainline kernel and a one-line config. It’s a current-generation TI part with vendor-specific firmware, a 32-bit SPL stage, and a custom toolchain requirement. Claude wrote most of it from a single prompt. The remaining work was iterating on missing Python dependencies — a build would fail, the error named a missing tool, the fix was another Alpine package. A handful of cycles later, the image booted.</p> That’s the kind of porting loop the project needs to be cheap, and right now it looks like it is.</p> What’s next</a></h2> More BSPs. The Beagle Play machine docs</a> cover how to use this one, and the Videos page</a> has the full walkthrough set. If there’s a board you’d like to see ported next, open a discussion</a> or send a note</a>.</p> Why the Build Tool Is a TUI 2026-05-19T00:00:00+00:00 A terminal UI looks primitive next to a web app or a native desktop app, and those alternatives are genuinely more capable. So why does [yoe]</code> use a TUI? The latest video</a> walks through the reasoning, and it comes down to one thing: most of the work already happens in the terminal, and a TUI build tool sits right next to it.</p> We already live here</a></h2> Open a developer’s terminal and look at what’s running. An editor — Helix or Vim — for finding files and making changes. A file manager like Yazi</a> for moving through build directories. lazygit</a> for the day-to-day git work. Zellij</a> as a multiplexer, holding saved sessions that you can reattach from another machine — the demo is recorded from a laptop attached to a workstation session — split into named tabs and panes. ripgrep</code> for searching the tree.</p> These tools are fast, keyboard-driven, and composable. They are where the work happens. A build tool that opens a separate window asks you to leave that environment every time you switch between building the system and changing the code.</p> Proximity is the feature</a></h2> Because [yoe]</code> is a TUI, it starts up inside that same environment. Highlight a unit and press e</code>, and you land in the same editor you use for everything else — not a built-in editor that almost works, but your</em> editor. Press $</code> and you drop into a shell in that unit’s build directory, where yazi</code>, rg</code>, and the rest of your toolkit are already waiting.</p> A TUI is not the most powerful interface for any single one of these jobs. A native app could draw a richer view of any one of them. But the TUI inherits an effectively unbounded set of powerful, programmer-focused tools for free, and the toolkit [yoe]</code> is built on makes wiring up to them straightforward. The build tool stops being a destination you visit and becomes one more pane in the environment you never left.</p> Speed, and hands on the keyboard</a></h2> The terminal tools share another trait: you drive them from the keyboard. Switching units, opening an editor, shelling in, searching — each is a keystroke, not a trip to the mouse to hunt for the right window. Hands stay on the keyboard, and the loop between I want to change this</em> and the change is made</em> stays short.</p> That is the whole argument. A TUI is a constrained surface — characters on a screen, no pixels to spare on chrome. The constraint buys speed, keyboard control, and a clean seam between the build tool and every other tool a developer already trusts.</p> Why this matters</a></h2> The first goal in What a Modern Embedded Linux Build System Could Look Like</a> was to shrink the loop between an idea and a running image. A lot of that loop is the friction of moving between tools. Choosing a TUI removes a category of that friction by refusing to pull you out of the environment where the rest of the work already lives.</p> The full set of walkthroughs is on the Videos page</a>. What part of the workflow would you like to see next? Open a discussion</a> or send a note</a>.</p> Editing a Unit's Source Without Leaving the Build 2026-05-15T00:00:00+00:00 Editing the source of a unit is one of the most common things you do while building an embedded Linux system. You hit a bug in an application, you need a patch in the kernel, you want to try a change before it lands upstream. In most build systems that means dropping out of the tool, cloning the repo somewhere else, wiring up a patch or a local override, and rebuilding. The latest walkthrough</a> shows [yoe]</code> doing the whole loop in place.</p> Pinned by default, development on demand</a></h2> Every unit pins to a release tag by default and checks out over HTTPS for convenience. That is the right default for a reproducible build, but it is the wrong shape for making a change: the source lives in [yoe]</code>’s download cache, and you can’t push a fix back to a cache.</p> Pressing the dev-mode key switches the unit over. [yoe]</code> re-points the checkout at the upstream repository, optionally swaps the HTTPS remote for the SSH URL most of us push through, and asks how much history you want. A shallow clone of 100 commits is plenty for a quick change — and for something like the Linux kernel, skipping the full history saves a large download. Shell into the source directory and you land on the upstream branch, connected to the remote you can actually push to.</p> The build follows the source</a></h2> Once a unit is in development mode, the cache key comes from a git diff</code> of the working tree rather than the pinned tag. Change a line and the cache invalidates on its own — no manual flag, no stale artifact. The unit’s status moves from pinned to dev modified</code> to dev dirty</code> as you switch modes and accumulate uncommitted changes, so the state is always visible at a glance.</p> From there the loop is short: build the unit, deploy it with a single key to the target you last deployed to, and watch the change land on the target instance. Because [yoe]</code> is built to run several sessions at once, the build and the running target sit side by side while you iterate.</p> Pinning the change back</a></h2> When a change is worth keeping, commit it in the source tree — the status drops out of dev dirty</code> — and pin the recipe to the new commit. The pin command writes the current HEAD</code> back into the unit’s tag field, preferring a real tag over a raw hash when one exists at that commit. The unit is reproducible again, now at your change, and the next build is back to a clean cached state.</p> Why this matters</a></h2> Two goals from Hello, [yoe]</a> and What a Modern Embedded Linux Build System Could Look Like</a> were to shrink the idea-to-running-image loop and to keep the application development experience tightly coupled to the system build. This workflow is that idea applied to source: one tool, one screen, and a clean switch between a pinned release and a live checkout for any unit — without the extra layers other build systems put between you and the code.</p> What part of the development loop would you like to see demoed next? Open a discussion</a> or send a note</a>.</p> When LTS fits — and when it doesn't 2026-05-14T00:00:00+00:00 LTS stands for Long-Term Support, which refers to software versions that receive updates, bug fixes, and security patches for an extended period, typically aimed at providing stability and reliability. For deeply embedded, single-purpose systems, or locked-down enterprise laptops where users are not allowed to install software, LTS makes sense.</p> For dynamic software systems (the browser is a good example), the only path is forward. It’s hard to predict exactly what pages need loading tomorrow, where the user will go next, what problems will occur, what security issues need patching, what new features need supporting, etc. Edge systems are trending in that direction. They are capable, expandable platforms whose future needs are hard to predict.</p> Trying to keep an operating system pinned to an LTS release while continuously evolving everything on top is a bit like freezing a creature’s skeleton while expecting the rest of its body to grow and adapt around it. The structure may be stable, but over time the muscles, organs, and connective tissue stop fitting cleanly. Eventually, the mismatch creates friction, limits movement, and makes further growth harder instead of easier.</p> When implementing an embedded OS, it’s important to decide: is this 1) a traditional static embedded system, or 2) a dynamic edge system? These are different problems and require different tool-sets. [yoe]</code> is being built for the second case — see What a Modern Embedded Linux Build System Could Look Like</a> for where that’s headed.</p> </p> Pip and Npm Belong on the Target too 2026-05-13T00:00:00+00:00 Application developers reach for pip install</code> or npm install</code> without thinking. The moment that code needs to land on an embedded Linux target, the same one-line dependency install usually becomes a hand-written recipe per package. That’s the friction the third walkthrough</a> aims to remove.</p> The idea</a></h2> Let the language’s own package manager do the resolution. Capture its output. Ship it.</p> [yoe]</code> now has units for three runtimes:</p> Python</a></strong> — a virtual-environment class creates a venv named after the unit, runs pip install</code>, and packages the resulting venv as an .apk</code> that the target installs directly. Each application gets its own venv, so dependencies stay isolated.</li> Node.js</a></strong> — npm install</code> runs at build time, and node_modules/</code> rides along with the app in the same package.</li> Bun</a></strong> — same flow as Node, but with the lighter-weight Zig-based runtime. Worth a look if you want a smaller footprint than full Node on the target.</li> </ul> The unit author writes the same dependency manifest they’d write on their laptop — requirements.txt</code>, package.json</code>. The build system handles the rest, including pulling in any development dependencies — compilers, headers, native build tools — that pip or npm need to compile packages with C or Rust extensions. Those tools live in the build environment, not on the target.</p> Python in particular benefits from the wheel ecosystem: pip caches built wheels extensively, and most of PyPI is now distributed as prebuilt wheels for common architectures. [yoe]</code> is set up to leverage those caches rather than rebuild from source on every run, which keeps Python builds fast even when the dependency graph is large.</p> Why this matters</a></h2> Two of the goals in Hello, [yoe]</a> and What a Modern Embedded Linux Build System Could Look Like</a> were: don’t reinvent dependency resolution, and don’t force application developers to learn a second packaging system to ship what they already wrote. This is what that looks like in practice — pip, npm, and bun composed in rather than replaced.</p> What’s next</a></h2> Rust and Zig units are queued up next, along with Python ML workloads where the dependency graph gets a lot more interesting. The YouTube playlist</a> is the place to subscribe for new walkthroughs as features land.</p> What development workflow would you like to see demoed next? Open a discussion</a> or send a note</a>.</p> First Walkthroughs: Overview and Package Deploy 2026-05-12T00:00:00+00:00 A build system is easier to evaluate when you can watch it in motion. The first two walkthroughs are up on the Videos page</a>, and they cover the parts of [yoe]</code> that are most different from what you’d expect coming from Yocto or Buildroot.</p> Video 1 — Overview</a></h2> A tour of the build system end-to-end: yoe init</code> to scaffold a project, the TUI with its live progress bar, background builds, search, and inline status — all in one screen. Then yoe run</code> to boot the resulting image in QEMU. The aim is to show the full idea-to-running-image loop without an SDK install, a cross-toolchain, or generated shell scripts to read through.</p> If you’ve only seen the earlier post</a>, this is the version where the claims become concrete.</p> Video 2 — Deploying packages</a></h2> The iteration loop, zoomed in. Once an image is running, the interesting question is how fast you can change a package on the target and try the new version. This video walks through building a package, resolving its dependencies, and pushing the result to a live target in a single step — no full image rebuild, no manual scp</code> dance.</p> This is the part of the experience that most rewards the design decisions in Hello, [yoe]</a>: one binary, language-native package managers composed in, and content-addressed .apk</code> outputs that the target can install directly.</p> What’s next</a></h2> More videos are planned as features land — Docker on the target, Go and Rust units, BSP authoring, and the AI-assisted workflows. The full playlist lives on the Videos page</a>, and the YouTube playlist</a> is the place to subscribe if you’d like a ping when new ones go up.</p> Feedback is welcome — what would you want to see demoed next? Open a discussion</a> or send a note</a>.</p> What a Modern Embedded Linux Build System Could Look Like 2026-05-11T00:00:00+00:00 Seven weeks ago we started experimenting</a> to find out. The result is a tool that builds QEMU and Raspberry Pi images today, with Docker support working. The goals driving the project, and where each one stands so far:</p> Drastically improve developer productivity</strong> — shrink the loop between an idea and a running image. Today: one binary, no SDK to install. yoe init && yoe</code> opens a TUI with a live build progress bar, and yoe run</code> boots the image in QEMU. Background builds, search, and inline status sit in one screen.</li> Easily integrate complex workloads</strong> — let modern languages keep their own package managers, and let containers ride along. Today: Go modules build end-to-end, and Docker runs on the resulting image. Rust, Zig, and Python ML come next.</li> Scale to build anything</strong> — one tool, one mental model from small images to distributed systems. Today: two modules (module-core</code>, module-rpi</code>) covering x86_64 QEMU and Raspberry Pi, with QEMU user-mode emulation building ARM64 on x86 — no cross-toolchain. Zephyr, AI workloads, distributed builds, and farm-scale caching are still ahead.</li> </ol> There is a long way to go, and the risks are real. But seven weeks in — 38 releases, a working build flow — the path forward feels solid.</p> </p> Hello, [yoe] 2026-05-02T00:00:00+00:00 After years of maintaining and shipping products with the Yoe Distribution</a>, we kept running into the same friction — much of it inherited from how embedded Linux has historically been built. We started fresh, kept the lessons that mattered most, and built the tool we always wanted to use.</p> What we kept</a></h2> Machine abstraction and image composition.</strong> Yocto got a lot right here.</li> Module composition.</strong> Pulling units directly from GitHub URLs scales naturally to vendor BSPs.</li> Tracking upstream closely.</strong> The cloud has been doing this for a decade.</li> </ul> What we dropped</a></h2> Cross-compilation as the default.</strong> Modern ARM and RISC-V boards build natively at full speed. Cloud CI runs arm64 cheaper than ever. QEMU user-mode emulation covers the rest.</li> The SDK boundary.</strong> One Go binary builds the kernel, the rootfs, and the application — no frozen sysroot, no drift between teams, one shared view of the build.</li> Reinventing dependency resolution.</strong> Cargo, Go modules, pip, and npm already solved this. [yoe]</code> composes with them instead of replacing them.</li> Generated shell scripts.</strong> When something fails, you read the code you wrote — not a stack trace deep in machine-generated output.</li> </ul> What we’re betting on</a></h2> AI as a first-class interface.</strong> Starlark units, queryable graphs, structured logs. An assistant that understands the system can take the cognitive load of “which knob, and why” off the developer.</li> One tool, three interfaces.</strong> AI conversation, interactive TUI, traditional CLI — same engine, same commands. Use whichever fits the moment.</li> Functional equivalence over bit-for-bit reproducibility.</strong> Hermetic builds and content-addressed input hashing, without the years-long effort required for bit-perfect reproducibility.</li> </ul> [yoe]</code> is pre-1.0 and moving fast. Take it for a spin and let us know how it goes — we’d love to hear what works for you and what doesn’t.</p> The opportunity is here … come build the future of embedded Linux with us.</p> — Cliff Brake</p>

Adding Debian — and what it weighs

It's Not About Competition

Fast Binary Packages from the APK Index

What’s next</a></h2>
Possibly Debian as an additional package source alongside Alpine. The Videos page</a> has the full walkthrough set. If you’ve got thoughts on how `[yoe]</code> consumes packages,open a discussion</a> or send a note</a>.</p>`

Qt Support in [yoe]

`What’s next</a></h2> More toolkit and application coverage, and more targets to run it on. The Videos page</a> has the full walkthrough set. If there’s an app or framework you’d like to see running under [yoe]</code>, open a discussion</a> or send a note</a>.</p>`

[yoe] Is Now Self-Hosting

Running [yoe] on a Beagle Play

`What’s next</a></h2> More BSPs. The Beagle Play machine docs</a> cover how to use this one, and the Videos page</a> has the full walkthrough set. If there’s a board you’d like to see ported next, open a discussion</a> or send a note</a>.</p>`

Why the Build Tool Is a TUI

Editing a Unit's Source Without Leaving the Build

When LTS fits — and when it doesn't

Pip and Npm Belong on the Target too

First Walkthroughs: Overview and Package Deploy

What a Modern Embedded Linux Build System Could Look Like

Hello, [yoe]

[yoe] - Blog

AI in the Build Loop [yoe]

Is It Time for a New Embedded Linux Build System?

End-to-End Testing Across the Whole Matrix

Adding Ubuntu — almost for free