Live data from Hacker News

Is it time for a new Embedded Linux build system?

yoebuild.org

51–60 of 92 posts

Re: Is it time for a new Embedded Linux build system?

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

Re: Is it time for a new Embedded Linux build system?

#52

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…

> 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

Re: Is it time for a new Embedded Linux build system?

#53
post #43

Earlier quoted context omitted.

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

It was true in 2005, but still? As I described in another post here, a modern strategy is to get a beefy server than can run the same ABI, then start a docker container and assemble a system from Alpine's package repo, then compile a kernel and a few in-house things, then extract a subset of that into an image. No cross-compile, and most of the useful software is in pre-built binary packages with the compile-time opt…

There are no beefy RISC-V servers. There are no beefy 32-bit ARM servers.

Re: Is it time for a new Embedded Linux build system?

#54

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…

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

Re: Is it time for a new Embedded Linux build system?

#55
post #34

Earlier quoted context omitted.

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.

ARM boards need a custom kernel and bootloader. These aren't things managed by the distro. The userspace IS managed by the distro and IS standard. Using yocto to manage userspace maybe made sense 15 years ago, but it has long since become far more trouble than its worth. Debian supports most architectures out of the box, has good cross-building infrastructure, many thousands of ready-to-use packages, and is non-weird…

You're missing the point that when you're building the product, and not using SBC just for fun, the image you are building, and yes even the userspace, is highly customized. Running a full-blown Linux distro is a non-requirement, and often incorrect.

Re: Is it time for a new Embedded Linux build system?

#56
post #13

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

Except you may have just a 512 M industrial sd card to run on. Or even less.

Re: Is it time for a new Embedded Linux build system?

#57
post #34

Earlier quoted context omitted.

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.

ARM boards need a custom kernel and bootloader. These aren't things managed by the distro. The userspace IS managed by the distro and IS standard. Using yocto to manage userspace maybe made sense 15 years ago, but it has long since become far more trouble than its worth. Debian supports most architectures out of the box, has good cross-building infrastructure, many thousands of ready-to-use packages, and is non-weird…

[deleted]

Re: Is it time for a new Embedded Linux build system?

#58

Earlier quoted context omitted.

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?

You can generally remotely build for any supported architecture[1]. The build process will be painfully slow though if you have cache misses. [1] https://search.nixos.org/options?channel=26.05&query=boot.bi...

Nitpick: binfmt.emulatedSystems is not true cross compilation. It sets up a nixos to enable emulated native compilation. After painful tinkering, i prefer this way too. When i recall correctly, for cross compilation you'd have to use nixpkgs flags.

Re: Is it time for a new Embedded Linux build system?

#60

Earlier quoted context omitted.

I didn't know Nix had support for embedded systems. Where are the images defined?

What do you mean by image? In Nix you instantiate a NixOS system and specify the architecture. There are a number of tools to build a disk image from a NixOS system. $ my-arm-system = nixpkgs.lib.nixosSystem { system = "aarch64-linux"; modules = [ ./configuration.nix ]; }; $ :b arm-system.config.system.build.images.iso

PSA:

nixos-rebuild build-vm (--flake DIR#HOSTNAME / configuration.nix)

./result/bin/SCRIPT

to build and launch a nixos vm with qemu.

Post reply on HN