Yocto, RockPi and SBOMs: Building modern embedded Linux images

Original Article ↗ Hacker News Discussion ↗

Perceived strengths of Yocto

  • Widely seen as powerful for building fully custom embedded distros, including SDKs, cross‑toolchains, and highly tailored images (e.g. scientific instruments, Qt setups, Swift/Flutter images).
  • Good support for cross‑compilation and packaging everything into deployable SDK installers for other developers.
  • Supports transactional A/B image updates and integration with update frameworks (Mender, RAUC, swupdate, etc.).
  • Strong documentation and a large ecosystem of BSP/meta layers; when SoC vendors or community do good Yocto layers, life is easier.

Learning curve & developer experience

  • Many describe the learning curve as “pure brutality”: opaque errors, complex layer/recipe/meta concepts, and a mix of Python, BitBake, and shell.
  • Out‑of‑the‑box configurations often “just work”, but small deviations or non‑standard build systems can require deep debugging.
  • Error messages from BitBake/Yocto builds are considered very noisy; finding the real compiler error in thousands of lines is painful.
  • Some find the docs good for “what is possible” but insufficient for “how exactly to do it”, often falling back to reading recipes or using bitbake -e.

Yocto vs Buildroot (and other systems)

  • Buildroot is repeatedly praised as simpler, faster to grasp, and good for smaller/less complex projects or bring‑up.
  • Yocto is preferred by some for long‑term maintainability, parallel builds, dependency tracking between packages, and richer tooling.
  • Critiques of Yocto: feels like an organically grown “ball of mud”; dependency modeling in BitBake is said to be incomplete, sometimes requiring full rebuilds after config changes.
  • Buildroot criticisms: historically weaker dependency tracking, slower rebuilds; mitigations include per‑package build directories and ccache.
  • Other contenders mentioned: Nix, Bazel/Buck, Gentoo (for native builds), LFS for fundamentals, niche tools like e2factory, and specialized projects like SkiffOS or makrocosm.

Setup, project structure, and helpers

  • Common pain: managing multiple layer repos, commits, and bblayers.conf/local.conf. Many teams script this or use git submodules/monorepos.
  • Tools like kas, emerging bitbake-setup, and smaller helpers (e.g. yb) aim to standardize and simplify environment setup.

SBOMs and supply chain

  • Yocto’s SBOM generation is appreciated for compliance, but criticized as low fidelity: manifests often include components not present in the final binaries, and don’t reflect patches well.
  • Industry tools (e.g. binary scanners) also misidentify versions and miss Yocto‑applied CVE fixes; commenters say higher‑quality, aligned SBOM/BCA tooling is still 1–3 years away.

Updates and deployment models

  • Strong preference from experienced practitioners for immutable full‑image updates (A/B partitions, rollback) over on‑device package updates (apt, deb, etc.), especially for large IoT fleets.
  • Yocto‑based solutions often use RAUC, swupdate (sometimes with Suricatta/WFX), or commercial stacks (Mender, Torizon, Balena, Ubuntu Core).
  • For Raspberry Pis and small fleets, some suggest sticking with distro tools (Debian/RPi OS, pi‑gen) plus external update systems, or container‑centric approaches (Balena, bootc, OSTree‑based distros).

Embedded Linux vs “just run Debian/containers”

  • Counter‑argument to “just use a normal distro”: embedded boards lack BIOS, have highly specific SoCs/boot chains, and often need vendor or BSP‑specific kernels and bootloaders that mainline distros don’t support.
  • Vendors frequently don’t upstream fully or quickly; Yocto/Buildroot remain the practical way to ship products on niche or low‑volume hardware.
  • Some foresee eventual convergence between embedded image builders and container tooling, but acknowledge that today they operate at different layers.

General sentiment

  • Strong split: some love Yocto and even fear losing it as a job skill; others see it as overcomplicated legacy that should be replaced.
  • Shared recognition: when it finally works, it’s extremely satisfying—but getting there can be slow, fragile, and mentally expensive.