Depends on the embedded system. It has precompiled binaries for aarch64-linux, but idk about others. There's definitely no public binary cache for bespoke, proprietary platforms though.

> Also, afaiu, Nix is tied to a particular version of libc which has a high probability of not working with the vendor-installed libraries on my systems.

Nix ships a whole dependency tree with every package, down to and including a libc. If you have another libc, Nix won't care.

On the other hand, if your hardware isn't supported by the libc Nix ships, the natural path is probably to package whatever given libc in Nix and build against that. Then you are back to building from source via Nix.

Nix has pretty good support for cross-compilation, multilib, and 'remote builders', though. You can set your embedded systems up so that Nix builds happen on more powerful machines and then get copied over.

Nix evaluation itself requires a lot of RAM, though, so if you use Nix for embedded you probably still want to push packages to the weaker systems from the outside.

So for you maybe not nix? I'd have never known given the original comment

I've been enjoying gokrazy. Makes cross compiling and updating my rpi server a breeze. Still an early project though but it works well for my needs.

Isn't it always a matter of choosing which problems you prefer?

The problems that Nix gives you are much nicer to have than the problems of tbe FHS absurdity.