2026-06-28 · GuixPkgs: every Guix package, as a Nix flake

Transcript

Transcript. Paraphrased; sources in notes.md.

HostWelcome to June 28th, 2026. I am Daniel, and joining me today is our resident systems skeptic, Fred. We have a packed slate today. We are looking at a project that tries to bridge the gap between Nix and Guix, a new policy from NLNet Labs regarding AI-generated code, and finally, a deep dive into why shell startup times feel like they are stuck in the mud. Fred, I saw you eyeing that Guix-to-Nix story earlier. You looked like you were ready to start a fight.

GuestA fight, Daniel? I am just looking for the inevitable segfaults. But honestly, the idea of pulling every Guix package into the Nix ecosystem is the kind of massive, beautiful disaster that makes me want to pull out my terminal and run some builds just to watch them fail.

HostWell, let us jump into that. The author of the blog post, Farid Zakaria, has released GuixPkgs. It is essentially a tool that translates the entire GNU Guix package repository into Nix flakes. For those who do not spend their days in the weeds of functional package managers, Nix and Guix are both systems that treat packages as pure functions of their inputs, designed for reproducible builds. But they are notoriously different beasts. This tool uses something called guix-transfer to rewrite the derivations.

GuestAnd that is exactly where the skepticism kicks in. You have two systems that represent the world in fundamentally different ways. The author is essentially trying to perform a translation layer between two different languages, and compilers are never as smart as you think they are. Over on Lobsters, a user named jackdk already hit a brick wall with the bootstrap dependencies. If you cannot get the basic bootstrap package to build, you do not have a repository, you have a pile of broken symlinks.

HostThat seems to be the consensus. Some users in the Lobsters thread are excited about the cross-pollination, but the practical hurdles of porting the bootstrap logic seem significant. Does this just feel like academic tinkering to you?

GuestIt is definitely vibecoded. To quote a Lobsters user called tusharhero, that is the sentiment here. When you see a project trying to bridge these two complex ecosystems, you have to ask what the maintenance cost is going to be when the underlying Guix bootstrap changes. You are not just building packages, you are building an emulator for another package manager. That sounds like a long-term headache for whoever tries to keep it synced.

HostMoving on to something that is causing a bit of a stir in the open-source world, NLNet Labs has implemented a strict policy against LLM-generated code in their projects. They are effectively telling contributors that if you are using AI, you better be prepared to defend and explain every single line, and for the most part, they just want human-written code.

GuestFinally, some sanity. This is not about being a Luddite. It is about accountability. As NLNet Labs points out in their thread, code is not just a bunch of characters that happen to work. It is a communication between humans. If you dump ten thousand lines of LLM-generated code on a maintainer for a project that powers internet infrastructure, you are not contributing. You are giving them a security debt that they have to pay off with their own free time.

HostA user named jaredkrinke on Lobsters asked for the reasoning behind this, and the reply from Alex Band was pretty blunt. They essentially said that LLMs provide the illusion of a solution without the developer actually understanding the problem space.

GuestExactly. When you write code, you create a mental model of the system. If you prompt an LLM to generate a fix, you are bypassing that mental model. When that code inevitably breaks in production three years from now, and the original developer has moved on, the maintainer is left staring at a black box. I see this in code reviews constantly. People want the output, not the work.

HostLastly, let us talk about performance. A blog post from the team behind devenv, a tool for creating fast, reproducible developer environments, is highlighting a persistent issue in nixpkgs. They are pointing to the dynamic loader, which essentially wastes time checking hundreds of directory paths before finding the library it needs. They call it a stat storm, and it is adding significant latency to every shell prompt.

GuestI have been waiting for someone to put a spotlight on this. The dynamic linker in Linux has been doing this dance for decades, but when you combine it with the way Nix structures its store, you are essentially adding a tax on every single command you run. I have actually been profiling this in my own local shell setup, and it is infuriating. You can see the overhead spike just by tracing the openat system calls. You are basically doing a filesystem walk just to run ls.

HostIn the Lobsters thread, a user named a5rocks pointed out that the post itself was accused of being AI-generated, which they found ironic given the previous topic. But focusing on the technical side, the author is proposing absolute path linking to bypass the search overhead.

GuestIt is a valid approach, but it is a massive change for the ecosystem. You are basically asking every developer to rewrite how they link their binaries to avoid the search path. Nixpkgs is huge, and refactoring the entire dependency graph to use absolute paths is the kind of project that takes years. It is a perfect example of how technical debt in the foundation ends up costing every single user cycles on their CPU.

HostIt is fascinating how these all tie together. Whether it is package management or build performance, it seems like we are constantly trying to patch over these foundational issues with more layers of abstraction.

GuestThat is the loop we are stuck in, Daniel. We keep building these abstractions, and then we spend the rest of our time trying to optimize the performance cost of the abstraction itself. I am going to spend my weekend digging into that linking issue, just to see if I can force a local override on a few packages. I need to know if the speed gains actually outweigh the complexity of managing the paths manually.

HostI suspect you will find a lot more broken symlinks than speed gains, but I know you will have fun doing it. Thanks for coming on, Fred. And to our listeners, thanks for tuning in. All the stories we discussed today are over on Lobsters. We will see you tomorrow.