alt Hacker NewsWhy cant we just use Nix for building anything? A unified approach to building stuff.
Replies
Nix is very awkward (and slow) to use for fine-grained caching, which is price of entry for a decent build system.
It also comes (practically) shackled to nixpkgs which is a barely-documented cataclysm of packages that extensively bake in assumptions that you are also going to use Nix as your runtime environment.
The principles behind Nix are nice but the implementation is sorely lacking in my experience.
Is Nix really appropriate for building a complete rootfs? Could I start from scratch and write a nix build script or whatever and end up with a rootfs I could run on some aarch64 SBC or SoM?
And how is the Nix story for going from a rootfs to a bootable image? On e.g Rockchip you need to make an image where there's some firmware blob in one are of the flash which jumps to a uBoot in another area which loads the kernel/initramfs/devicetree, how does that look in Nix land?
How does it handle building vendor kernels or carrying kernel patches instead of mainline?
Because of the elitist, exclusionist air it has gathered around itself, I guess. Trying to get something to work with zero knowledge about it is a maze of twisty passages, all alike.
After following breadcrumbs across blogs, I found the proper incantation, executed it, got "too many arguments" from shell, along with multi-megabyte error wall, did not find anything related to the issue, wrote my own slop-makefile.
nix is escape room
Regardless of whether this would actually be a good idea, it's unquestionably an instance of
Disclaimer: I work at Amutable but not on tine (though we did discuss this internally a fair bit, as you might expect).
Nix does have a similar model in some respects (in particular the idea of input-hashed build graphs) and so solves a lot of similar problems but there were a few important factors that made us not go with Nix (or NixOS) and instead go with Buck2.
As the blog post mentions, the ability to build directly from a wide variety of upstream distribution artefacts and maintain temporary deltas was incredibly important to us. Our team has a lot of old-school packaging experience (I've done packaging for (open)SUSE for over a decade now and we have former and current Fedora, RHEL, Ubuntu, and Debian packaging folks with even longer histories) and our view is that distributions do a lot of thankless and incredibly valuable work and the most painful part of maintaining a distribution is the deltas you have to maintain forever after you've hard-forked packages or repackaged them. Buck2 allows us to create models for these concepts (which are in tine) without needing to boil the ocean repackaging upstream packages. But Daan and Martin are far better equipped to get into the weeds on this topic.
On the more general topic of why not use NixOS, as discussed in one of our other recent blog posts[1] we are make heavy use of sysexts and the /nix/store combined with the general linking model of NixOS (while very technically impressive) does not play particularly well with that model. I should also mention that we have a NixOS guy on our team too so you'd better believe NixOS came up in conversation. :D
[1]: https://amutable.com/blog/it-starts-upstream-kernel#image-ba...