Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Whilst I find yocto perfectly fine. I also see that it has its limitations. I think there is a need to make yocto more nimble rather than designing a whole new build system.

    yoebuild does seem interesting at least as a proof-of-concept.

    by looopTools
  • This sounds like fun, but I'm not sure how changing build systems fixes the vendor problem. They will just ship their proprietary blobs built on top of this new build system instead of the old one, and will not change other behavior. Buying from vendors who upstream or minimally open source their work might help.

    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.

    by sn
  • Yes, and if they have done the hard work to deliver features in the kernel that provide a moat, that blob is the hardware.

    Reversing and reimplementing the closed bits are what I want my Buildroot pipelines to do.

    That’s my use case though; targeting COTS devices with (mainline) Linux support that don’t do all they could.

    I have done it the ugly way (in production) and I want elegance in my old age.

    by itomato
  • I just use Debian these days
    by klysm
  • Wow, no cross-compilation as a feature?!

    Architecture emulation with qemu-userspace is 5-10x slower than running a native build.

    The only 'proper' no-friction cross-compilation system I know is Debian/Ubuntu, because it allows to install foreign architecture libraries into your native system, and has all the wrappers for cross-compilation in dpkg-buildpackage.

    This way you don't have to maintain cross-compiler or toolchain/sysroot, you just install whatever dependencies you need with the regular `apt install` of another architecture.

    I'd like to have more friendly tooling around that instead of a slow compilation of architecture emulation.

    by ValdikSS
  • Thanks, I was not aware of this - will look into this more.
    by cbrake
  • The problems building with Linux and GNU environments exist because they were terribly designed with assumptions like

    - 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.

    by okanat
  • Gentoo is literally designed for this but people keep coming up with other non-solutions. A Gentoo stage 3 with a custom kernel can run on a potato.
    by hparadiz
  • Doesn't Yocto come from Gentoo to some extent?
    by palata
  • I haven't used it, but there's also Avocado OS [1]. Myself, I use Yocto for our embedded build. It's not perfect but for our application, which involves building a bunch of software that uses both Swift and Flutter for an embedded audio product running on a RPi CM4, it works just fine. Shout out to Mender for A/B updates.

    [1] https://www.peridio.com/avocado-os

    by lukeh
  • I've used buildroot extensively, and an occasional yockto.

    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-/

    by johnea
  • Are you proposing compiling on the target? For a vast number of embedded systems that is not only impossible (insufficient disk and memory) but also incredibly slow.

    At the end of the day you need some cross compilation just for board bring up.

    If you're playing with some platform for which this has already been done, then sure, but that's not really the "normal" way of doing embedded.

    by xyzzy_plugh
  • I'm surprised to see no mention of Guix. It solves all of these issues, and already has a good story both for cross and native builds on a variety of architectures.

    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...

    by wasting_time
  • Does guix have any advantage here over nix?
    by yjftsjthsd-h
  • Modern SBCs are just normal computers and not "embedded" in the traditional sense. You can generally just use Debian, and spend time on the actual project, instead of wrestling with the system
    by dima55
  • Except you may have just a 512 M industrial sd card to run on. Or even less.
    by nottorp
  • I agree. In the past, I have successfully used Debian and Alpine for embedded. Never needed to compile OS kernels or standard DLLs, other people already did and published in these package repositories.
    by Const-me
  • For more mainstream SBCs, totally agree. However a lot of the niche industry boards (especially new ones) only support Yocto out of the gate. Debian might be "supported" by the SoM/CPU vendor but manually reapplying kernel patches and praying it boots is a PITA.
    by j4k0bfr
  • They aren't normal computers in the same way x86 is. They usually need proprietary drivers in custom boot processes, forked kernels with patches, etc. I'm yet to see a single SBC I can just download the iso from the debian website and get going. You always need some custom build.
    by Gigachad
  • I share some of the same observations that seem to have motivated this project, but my solution was to just use Alpine on the same architecture as the target (possibly via qemu) and then export a subset of it to a filesystem image. I implemented it as a perl module collection with no dependencies other than core perl modules, and then run the export from within the image itself. Among other things, it lets me use strace to find the runtime library dependencies of the things that need to be in the image.

    https://metacpan.org/pod/Sys::Export

    by nrdvana
  • I've been using Nix for "embedded" systems for few years now and it works fine. I don't quite understand why "embedded" has historically meant learning a completely separate tool. I've been building for x86 and ARM servers for 5+ years now, so why should targeting an ARM board be any different?

    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).

    by KingMachiavelli
  • Hey, you completely forgot about embedded devices that dont run linux. It's not all linux ya know
    by superxpro12
  • I was thinking the same.

    However, reading through the docs, the author clearly knows about Nix/Nixpks and has factored some of its properties into the design: https://docs.yoebuild.org/nix.html

    by jo-m
  • I'm not very familiar with nix, how well does it do with cross compiling? is anyone actually using it for yocto sorts of domains?
    by Palomides
  • > I don't quite understand why "embedded" has historically meant learning a completely separate tool.

    Because historically, and I would argue should still, refer to very limited hardware, in terms of memory, processing power, and energy.

    by jimktrains2
  • > I don't quite understand why "embedded" has historically meant learning a completely separate tool. I've been building for x86 and ARM servers for 5+ years now, so why should targeting an ARM board be any different?

    Because embedded usually means dealing with complete functionality provided by the soc, bare minimum for the init system to get quick boot times.

    If you just want to boot the CPU and run some IoT app, device tree + kernel + uboot should be enough.

    But for anything with a GUI, You'd probably need the vendor provided binary blobs for GPU accelerated UI, proper gstreamer packages with all the patches to make it work with the binary blobs... properly packaged Qt etc ... Not to mention read only rootfs and A/B partitions for upgrades to deal with power loss headaches.

    I haven't used Nix for any of these but most of these things are available ready to use with the vendor provided buildroot or yocto setups. And it would've been just more work to get this all working with yet another build system/package manager

    by saidinesh5