Construir software de sistemas con Nix: entornos reproducibles para Rust y BPF

Nix es, a la vez, un gestor de paquetes, un sistema de compilación, un lenguaje para definir builds y la base de la distribución Linux NixOS. Su pieza más práctica para equipos de desarrollo son los flakes, que funcionan como un lockfile universal: fijan una revisión concreta del repositorio nixpkgs y garantizan que todas las dependencias (compiladores, librerías nativas, cabeceras del kernel, herramientas) se resuelvan exactamente igual en cualquier máquina. El artículo muestra cómo aplicar esto al software de sistemas, concretamente a proyectos en Rust que usan BPF (como runqslower). En ese ecosistema conviven rustc, cargo, clang, gcc, libelf, zlib, libbpf, libc, las cabeceras del kernel vmlinux.h, bpftool, el linker, el cargador dinámico y el entorno, una lista tan larga que cualquier apt upgrade puede romper el build sin que quede registro del estado anterior. Con Nix, una sola orden (nix develop) reproduce ese entorno de forma idéntica mañana, dentro de un año o en el portátil de un colaborador con otra distribución. Entre las ventajas concretas que describe el autor están: entornos de desarrollo consistentes entre distribuciones, bisección de regresiones casi trivial, y defaults más estrictos. Como ejemplo real, al cambiar de clang 19 a clang 21 descubrió que la nueva ISA v3 de BPF, activada por defecto, rompía kernels antiguos; el cambio quedó aislado en diez líneas de Nix. También relata cómo un proyecto en C++ que crashaba solo bajo Nix reveló un comportamiento indefinido gracias a la política de seguridad por defecto del gestor de paquetes. La conclusión es clara: para software de sistemas, donde el toolchain cambia bajo los pies del desarrollador, Nix ofrece una caja fuerte reproducible que separa el build del estado del sistema operativo.