Agreed, building on the typical target is a terrible idea. None of my suggestions are to build on target, but rather specific units on some capable hardware of the same architecture. The main build will still run on your own workstation of any architecture. Only specific units get farmed out to another machine, but worst case can be run in QEMU user mode emulation if there is no native machine runner available.
This remote build runner is not implemented yet, just ideas.
I wrote the orignal draft, but used Claude to integrate some feedback. In hindsight, this was a mistake, and I will not do that again. Thanks for the frank feedback.
I'm glad Yocto is working for you.
I'm by no means a Yocto expert like many of you, but I've used OpenEmbedded/Yocto since the start, so I'm quite familiar with it. I started the following project, which Khem mostly maintains these days:
1) Cross compile. Yoe build still does this where it makes sense. (Go apps, likely kernel builds in the future)
2) QEMU user mode - 5-20x slow, but fine for some things.
3) Run yoe-build on any ARM machine (AWS, rPI5, Jetson)
4) Farm unit builds out to runners on cloud ARM machines. (future)
The yoe-build architecture allows for this. Choose the container, host architecture, and location that makes the most sense on a unit-by-unit basis.
Caching is also part of the vision, so we never rebuild something twice, unless it changes.
I’ve been experimenting with what a next-generation embedded Linux build system might look like: native builds on the target architecture, modern language package managers as first-class citizens, and AI as a primary interface to the system.
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.
I tried this yesterday and set it up for my wife. I was amazed at how many birds it picked up. There must be some amazing technology in the audio processing.
When we want to advance something, we often need to simplify it first. Piling on layers of complexity will only get us so far — at times, we need to go back to ground zero and re-think things.
There are many ways to specify contracts between systems, such as APIs and schemas. A more fundamental contract focuses on a more granular unit of data. Points in an IoT system are like atoms in matter. A Node tree in an IoT system is like the DNA in a living organism. The composition of points and structure of nodes (like atoms and DNA) is infinitely flexible. It is this simplicity and flexibility that allows atoms and DNA to define so many different types of matter and species of organisms. It is time to throw out the custom struct as the defined unit of data between systems and focus on something more granular, flexible, and scalable.