Instead of cross-compiling with a large meta-layer stack, the tool builds kernel, rootfs, and applications together using one engine, with a CLI, TUI, and AI assistant talking to the same core. All you need is the tool, Docker, and Git — no global SDKs or hidden state.
It’s pre-1.0 and rough around the edges; I’m sharing it early to get feedback from people who live in Yocto/OpenEmbedded, Buildroot, Nix, etc. I’d love to hear where this breaks on your boards, what workflows feel wrong, and whether the “native builds + AI-aware build graph” direction seems promising.
This is the complete opposite way, actually.
We need cross-compiling that is just as effortless as native compilation.
You should be able to build complex software on a powerful computer and perform costly optimization, then run it on a low-powered device.
Even if you don't have a beefy server of the same architecture, you can probably run it in qemu instead of docker to the same effect. And even if qemu is slow, you can run a build of the kernel and your in-house stuff in parallel on 64 cores and not really be affected by the qemu slowdown.
I'm interested to hear counterexamples, though.
What if this hegemony in ISAs is partially because of the high costs of porting software and toolchains?
Maybe the next generation of embedded devices will have ISAs that are, say, extremely optimized for real time industrial controllers, but terrible at compiling C++.
It seems a little silly to give up on cross-compilation just because _today_ everything runs on ARM.
Especially because cross-compilation is not a particularly hard problem, the problem is with decades of tooling assuming the build and target environments are the same.
I’m already sitting at an expensive computer, if everything else were equal I’d rather cross compile than buy more hardware.
I’m open to reasons that’s presently too hard of a workflow to enable so I’m (literally) paying for a penalty, but I don’t see how it’s a better idea.
The workflow for user space can definitely improve some of this pain but I feel like a large portion of any embedded Linux development effort still ends up in the weeds for boot related items (secure boot, proper updates, nuanced kernel patches, bootloaders, device trees, and supporting machine variants, etc). Solving those to make them easy is a hard problem for sure.
As a long time user of Bitbake and Yocto, and watcher of Yoe Linux... I kind of have to respectfully disagree with the approach.
One look at the Python or Node packaging ecosystem, and you can see how difficult trying to integrate those in a 'sane' way in embedded, with repeatability and security in mind, nevertheless wrangling something like C/C++ dependencies and native packages in a qemu-cross (or binfmt emulation) environment.
I feel like Bitbake and the wider Yocto ecosystem has essentially 'solved' cross compiling. Sure there are the incredibly complex codebases like Chromium that require lots and lots of study and patience, or esoteric compilers, etc. but for most applications I feel that especially AI tooling can write up a good basic recipe for integration with Yocto.
The unfortunate thing about AI tooling is Kernighan's law (where debugging is twice as hard as writing it the first time.) Especially in Embedded Linux, where 99.99% of the product code is written by others, trying to figure out where the AI didn't quite get it right or missed something can break things unexpectedly and impossibly for the unaware developer to fix, even breaking at runtime. So the build environment has to be simple and predictable. I think Yocto/Bitbake already strikes a good balance here, with other nice things like offline builds, repeatable builds, sstate caching across machines, PRbuild servers... things useful for big teams, so consider those as well.
Although, if someone does a 'uv'-like rewrite of Bitbake into Rust with the same feature set but faster, I am all for it...
Maybe, having Yoe or some other centralized distro make specific opinionated choices and then provide an open sstate feed, working inside Bitbake, could get a lot of the speed and customizability gains back without a big rewrite effort.
Like the article points out, the software stacks people use for embedded devices are the same as people use non-embedded use; Rust, Go, NodeJS, and sure still C++. The only real difference with embedded devices is non-OS components like the bootloader (u-boot, EDK2) and customizing the device tree. (And of course firmware flashing). Fundamentally those are all just packages that I can describe in Nix. I don't need a separate tool just because the board is small.
IMO the embedded space, especially in the US, is already pretty Niche. Most companies either just ship the vendors BSP example (Ubuntu/Debian/Yocto) and pay very little attention to the detail or re-useablity. Once you vendor declares the BSP EOL you are stuck unless you re-implement it yourself.
Using Nix (or Guix) has the massive advantage of a large and active community that isn't fractured like the Yoctoo/Buildroot community. (By fractured I mean there may by many, many people using those tools at $DAYJOB but due to vendor BSP customization they likely share much less with the upstream community maintained sources).
Adding new targets is deceptively easy, just copy an existing template and substitute your values.
https://codeberg.org/guix/guix/src/branch/master/gnu/system/...
https://codeberg.org/guix/guix/src/branch/master/gnu/bootloa...
Yes, skipping builds from source can be faster, and, I don't know that you need to throw away yocto to do that https://rootcommit.com/pub/conferences/2024/elce/yocto-binar...
From the statement about "Caches builds so no piece of software is built twice." I'm guessing that the author has not enabled sstate caching https://docs.yoctoproject.org/dev/overview-manual/concepts.h...
I'm a little doubtful on the post's assertion that yocto is only needed for "deeply embedded regulated products." For products that have to follow the https://en.wikipedia.org/wiki/Cyber_Resilience_Act coming up, they will almost certainly need:
* SBOM management https://docs.yoctoproject.org/next/dev-manual/sbom.html
* CVE (or its successor) tracking https://docs.yoctoproject.org/dev/security-manual/vulnerabil...
* License management https://docs.yoctoproject.org/next/dev-manual/licenses.html
And I'll echo what some other folks have said here: if you don't need features like that, bundle your custom bootloaders and kernel with a binary distribution like Debian and call it a day.
yoebuild does seem interesting at least as a proof-of-concept.
- You're building on the same native system as GNU and Linux packages, you install them globally in the same places that servers and desktops use
- Your C, C++ compiler and entire toolchain and other binary utilities with the kernel is a one single unit that you can only change one part at a time
- You use the same up to date headers with glibc, gcc and Linux kernel
- You're building software in the same universe of all the other packages, especially gcc libraries (libgcc_s, libstdc++), glibc (especially bad since ld-linux.so is part of it)
- The build system only uses standard paths
The reason Yocto is so complicated is that developing in a Linux environment actually sucks when you're not writing web-oriented or server / VM software. Yocto fixes it. It introduces a good set of abstractions that work around terrible design decisions that were made in overall Linux ecosystem. There are a lot because the OS design is fundamentally broken, especially with C-based toolchains which is 99.999% of the ecosystem. Current C toolchains including MSVC strongly ties OS with the C's internal types and bad decisions of 70s.
As always all articles whose title asks a question are answered with NO, 99% time. By taking away the cross-compiling abilities and the workarounds doesn't fix the brokenness of Linux and overall FOSS ecosystem.
If you're looking for how a better embedded environment looks like, look at Rust toolchains. For Linux take a look at musl-libc based ones (you 100% need a systemd distro to get away from nss complexities that musl introduces). Or even better take a look at relibc. There are barely any assumptions about the target filesystem and tooling in Rust toolchains, unlike C/C++/Make toolchains. There is redox OS but it is still in slow development and they stuck with Make, which I think was a bad decision. Android uses its own build tooling but cannot run away from C/C++ tooling unless Google revives Fuschia.
My impression in recent years is that these image cross build environments are just not as frequently needed as they were back in the day of their invention.
My most recent embedded linux environments were just embedded archlinux.
No need to cross build an image, just install and run the minimized linux environment right on the target.
Of course, a big part of the need for these cross-tools is that it seems most modern embedded linux developers are running windoze on their development workstations 8-/
And "I've been experiment with" seems to just mean "I've been vibe coding"
RAM is expensive now. Reasonably priced seems to be counter to that fact.
The whole article feels like a promo-tour.
> The catch is that nobody handed us the tools to keep the place running.
Software such as homebrew exists. Why is the article ignoring this? Not only does it feel like promo, it now feels like propaganda. Homebrew is also just one example; LFS/BLFS also exists for embedded linux. Perhaps the quality is less than for desktop computer systems but it exists.
> Edge devices have started behaving like cloud systems. They run increasingly complex stacks, are frequently updated, and are managed remotely over their entire life.
Companies want to become dependent on others? Because that is what cloud is all about. Top-down control. A mafia for later blackmail rack-up-the-price strategies.
> 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
Seems untrue. If you have a compiler that works, you can compile. Thousands of packages? I am tracking 3888 right now. That covers really most software by far, including python pypi addons. If a single person can do that, a team has an even easier time. The whole article seems to narrate a story that is just made up.
> Building everything from source in Yocto means long builds, heavy memory use, and powerful workstations.
No it does not. I do so every day. You need a reasonably fast computer and RAM, which is now driven up by the existing hardware mafia that must be put in jail, but it is easily possible for solo persons too. Now imagine a team.
The whole article is really really crap. Absolute garbage. The claims it makes are for the most part simply not correct. It narrates a story as if all linux developers are incompetent. I highly doubt that. It also never mentions any existing software here that would change the rhetoric such as homebrew, LFS/BLFS and so forth. It feels as if that article is just engineered to tell a "we thus need xyz". That's not good writing. I mean just look at this:
"We can leverage these change agents and rethink the world of connected products."
What does that even mean? Did AI write this? Because humans are usually smarter when it comes to opinion pieces. "connected products" - everything is now connected?
