[KingMachiavelli]

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

[saidinesh5]

> 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

[jimktrains2]

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

[zamadatix]

If you're sticking the Linux kernel into something you've already past the scale this should require a separate build system to accomplish.

[Brian_K_White]

I guess this was just so true everyone found it uninteresting like saying water is wet eh?

[Palomides]

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?

[sollniss]

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

[throwawayqqq11]

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.

[actionfromafar]

At some point it's a matter of perspective. If the emulated system is fast, it feels the same as "true" cross compilation. In the end it's a bunch of bits and bytes which produces some other bits and bytes when we poke it. If it goes fast, it's good. If it goes slow, it's painful.

[cbrake]

Is this similar to QEMU user mode emulation?

[nine_k]

We do Nix-based cross-compiling for non-embedded software (ARM vs x64). I'd say it works mostly transparently.

[rendaw]

Nixos can cross build os images for Le Potato with device tree stuff: https://hub.libre.computer/t/nixos-for-aml-s905x-cc-le-potat...

[jo-m]

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

[KingMachiavelli]

Actually, quite an honest and in-depth review with many genuine good points about the state of Nix. If you genuinely need sub 1GB image sizes, you would have to reimplement many of the Nixpkgs conventions like glibc/systemd.

I’d still probably just implement this in Nix/Nixpkgs so I could leverage the rest of the ecosystem but that’s not trivial at all.

I wouldn’t even say Nix as a language is better than Starlark. The author is certainly well informed in the choices made.

[superxpro12]

Hey, you completely forgot about embedded devices that dont run linux. It's not all linux ya know