Nix wrote half of my debugger
A developer explains how the Nix package manager's deterministic build system significantly simplified the creation of a debugger for a virtual machine. By leveraging Nix's ability to track inputs and dependencies, the author was able to reproduce and solve complex race conditions.
Why it matters
This demonstrates the practical utility of functional programming and deterministic build tools in solving difficult software engineering problems.
A few days ago I wrote about Rewind VM , a deterministic VM where every run of a Nix build is a pure function of its inputs, thread schedule included!
I have been using it to find, reproduce and solve numerous race conditions in Nix builds, but it’s been making me feel a little crazy . What is this superpower, and why is nobody else using it?
The tool has quickly grown a source panel, stack frames, bookmarks, a “Compare” tab, a lot more gdb support, thread lanes, which show who held the CPU at every step, and “Check from here”, which helps find the exact step where a race condition happens.
I went into each new feature thinking it would be a big code-lift but I kept running into the same thing: the hard part of each feature was already done, and Nix had done it.
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in