A recap of DEFCON34 and the nix.vegas community gathering, covering three talks given: relocatable Nix binaries (exploring $ORIGIN in RUNPATH and an eBPF-based binfmt_misc approach to Linux kernel support), Guix by Nix (a project rewriting Guix derivations into Nix derivations via guix-transfer and GuixPkgs so Guix packages become buildable by Nix, including a source-bootstrapped JDK missing from nixpkgs), and a rant talk titled 'How to piss off your Nix friends' arguing Nix and nixpkgs optimize for social comfort at the expense of technical ambition. Also recounts meeting Bitcoin Core developer Carl Dong, who works on Bitcoin's reproducible builds using Guix.
Table of contents
§ What is nix.vegas?§ Relocatable Nix Binaries§ Guix by Nix§ How to piss off your Nix friendsQuestions this post answers
Why can't you just change the /nix/store path prefix in Nix without rebuilding everything?
Changing the Nix store prefix alters the hash of every derivation in the closure, down to core tools like bash, because Nix derivations are content-addressed by their absolute store path. This means moving the store location forces a full rebuild of the entire dependency graph before you can even run something as simple as hello, rather than a quick relocation. Developers wrestling with Nix store portability can follow deep dives like this on daily.dev.
What is the GuixPkgs project and how does it let Nix build Guix packages?
GuixPkgs is a project that rewrites Guix derivations into Nix derivations so every Guix package becomes buildable through Nix, using tooling called guix-transfer. One practical benefit is gaining access to Guix's source-bootstrapped JDK, a fully reproducible Java build that nixpkgs does not currently provide. Anyone comparing Nix and Guix reproducibility approaches can track projects like this on daily.dev.