You probably don't need Yocto, and that's fine
Trainings<br>Customized Trainings<br>About<br>Blog<br>DE
embedded
26.05.2026
You probably don’t need Yocto, and that’s fine<br>New customers often look surprised when, during the planning phase, we ask whether they really need Yocto.<br>The unspoken assumption is usually that any serious embedded Linux project these days has to use Yocto.<br>We at sigma star gmbh consider ourselves power users and Yocto experts.<br>That’s exactly why we’re often the ones telling our customers to think twice before reaching for it.<br>So why is Yocto the default, and when is it the wrong default?<br>What is Yocto, actually?<br>People sometimes call it “the Yocto Linux distribution”.<br>That’s not what it is.<br>Yocto is a toolkit for building your own Linux distribution.<br>The Yocto Project itself ships a reference distribution called Poky, built from bitbake, openembedded-core, and meta-yocto1.<br>The ability to assemble a Linux system that matches your needs exactly makes Yocto incredibly powerful for embedded projects.<br>You can compile the whole user space for your CPU, apply patches to any component, toggle features on or off in any recipe, and pin or change every version.<br>On top of that, many System on Chip (SoC) vendors and hardware partners publish ready-to-use Board Support Package (BSP) layers, which give you a working starting point on real hardware.<br>That mix of flexibility and vendor support makes Yocto the default choice.<br>The same mix also turns it into a trap when you don’t actually need that much control.<br>Your distribution means your responsibility<br>With regulations like the Cyber Resilience Act (CRA)2, product vendors now have to keep the software they ship secure and provide security updates for the lifetime of the product.<br>That can be a long time to maintain a Linux system.<br>A regular Yocto release lives only about seven months, until the next release lands.<br>Long Term Support (LTS) releases get up to four years of updates, which is the current policy starting with Yocto 5.0 (Scarthgap)3.<br>One might ask why four years isn’t enough.<br>But there’s a less obvious problem.<br>To see it, we need to look at what a Yocto LTS release actually maintains.<br>A Yocto release is a set of bitbake recipes for software components, with specific versions and metadata, plus the reference distribution Poky.<br>During the maintenance period, the Yocto maintainers apply bug and security fixes to those components and to Poky.<br>For software components, those fixes usually take the form of backports from newer upstream versions.<br>And here’s the twist.<br>Since Yocto is a tool to build your own distribution, you’ve most likely made changes like these:<br>Non-trivial patches or local tweaks to a handful of components.<br>Extra components added on top of what Yocto ships.<br>Version bumps or pins to pick up a fix or hold a known-good state.<br>With every Yocto maintenance release, you’ll have to check whether your changes still apply cleanly on top of the new state.<br>On top of that, you need to confirm that the components you added or pinned still receive fixes from somewhere, because Yocto’s maintainers don’t know about them.<br>At the end of the day, it’s your maintenance work.<br>If you take Poky and use it almost unchanged, a fair question to ask is: Why are you using Yocto in the first place?<br>The elephant in the room: the Linux kernel<br>Yocto ships a Linux kernel and maintains it as part of each release.<br>But you probably won’t use it unmodified.<br>You almost always have to apply at least your vendor’s patches, and run a kernel new enough to include the drivers and fixes you depend on.<br>So once you factor in CVE tracking, the kernel alone is a big part of your maintenance work, whether you use Yocto or not.<br>There’s a way to keep that work under control.<br>We strongly advise our customers to build on top of an LTS kernel from kernel.org4 and keep all their changes in a tidy patch queue.<br>To stay current on security fixes, move to each new stable release and re-apply the patch queue.<br>kernel.org maintains LTS kernels for years, so your patch queue usually applies cleanly and only needs real work when you jump to a new LTS release.<br>Depending on your setup and security requirements, the same applies to the bootloader, which is usually just as vendor-specific.<br>And for completeness: sticking with the kernel your vendor ships is usually a bad idea.<br>Vendor kernels sit years behind kernel.org, rarely receive updates, and miss almost all security fixes.<br>Exceptions prove the rule.<br>The hidden cost of a custom distribution<br>Building “your own distribution” sounds great in a slide deck.<br>In practice, it costs real engineering time.<br>Build times. Yocto compiles practically everything from source. A clean build of a non-trivial image takes hours on a fast workstation. The sstate-cache and a shared DL_DIR make repeat builds faster, but the cache itself is fragile: a...