2026-04-25 Sat
Frustrations
Nix Performance Issues
- I have a CI job which runs a daily update to keep my software up to date. It recently jumped from 7.5 min to timing out at 1.5 hrs. When I sync my system, it's taking longer and longer. It's impacting how often I run my nix sync, which is also impacting how often I configure my machine.
- Part of the problem that caused the jump from 7.5 min to 1.5 hrs was because I switched to using Numtide/llm-agents.nix without configuring them to be a binary cache provider as they recommend. I was trying to install Codex/CLI through them, which is an Open Source Rust project. As a result, it was doing all the build activities Numtide already does in CI.
- In this case, I was lucky, in a sense, because Numtide is a nix consulting firm, so they know what's what; they actually have a CICD/CI system that exports a Binary/Cache that's updated once a day. But in practice, I've been exploring the nix ecosystem using LLMs to write my flakes, and it didn't suggest that I add that caching setup, and I didn't even think to set that up.
- Other dependencies like mise are much more out of date; nixos packages show the latest version at this time to be 2026.4.6, even though @jdx has released more than a dozen versions since then.
the problem with Nix is its Pur/ity
- By design, nix is trying to build all software in a pure way, which is a very ambitious and lofty goal.
- I love this goal, particularly for the reproducibility of software. It ensures that software can be built by people who are independent of the core maintainers. This part reminds me of how the IETF requires multiple, independent reference implementations to move a protocol forward.
- Part of the design of this system is that the build dependencies are expressed in a terse functional programming language, Nix/Lang. Someone has to write the Nix/flake for each package, which describes how to build the package. Then someone else has to build it. And, preferably, it wouldn't need to be built more than once for each platform.
- Most of the time, the person who describes how to build the software in a Nix/flake with Nix/Lang is just an enthusiast about the underlying software. They don't have tons of time to set up a robust build pipeline that includes tests. They are most likely just doing it for themselves. Once they get it working, they share that work with others.
- But this means that the vast majority of people who use Nix/flakes are not getting binaries built by the people who made the software. This is very inefficient. The most knowledgable people about a particular piece of software are the core maintainers. Those maintainers often go out of their way to generate binaries for multiple platforms. And then, most of the time, as far as I understand it, nix doesn't use them, because it wants to build them.
- For example, the mise Nix/flake here is maintained by a polish developer Person/Konrad Malik. It doesn't use any of the binaries that @jdx has GitHub/Actions generate.
- If I look at their github surface area, they appear to be a competent dev, and I can see they are struggling with some of the things I am with nix; Person/Konrad Malik/GitHub/neovim-flake has
- in the assumptions section,
- in the experimentation section,
- It's notable that in spite of the availability of options such as those explored in Username/luixos/YouTube/26/01/Neovim on NixOS - Nixvim vs NixCats vs NVF - nixvim, nixCats-nvim, nvf, Konrad chose to make his own nix flake!
- If I look at their github surface area, they appear to be a competent dev, and I can see they are struggling with some of the things I am with nix; Person/Konrad Malik/GitHub/neovim-flake has
- As a relatively new adopter of Nix, I don't even know whether there's a convention for how to just "rely on the original binaries" when making a nix flake. It seems like it goes against the whole ethos of the nix ecosystem.
- It's seems ironic to me that one of the reasons why people choose Nix instead of Docker is performance. They both provide increased reproducibility and require people to pay for that with increased complexity of abstractions. In addition to that base cost, Docker adds the cost of both build time performance issues and runtime overhead, particularly with filesystem mounts, but at least Docker has opinions about caching. Nix's build-time complexity has less industry support, and so individuals must decide where and how they will add caching.
More Beads/Bug/Dolt Difficulties
- yet another instance of corruption, this time on Beads/v/1.0.2. By now I think about 40% of my usage of beads is fixing beads. Time to move to another Git-Friendly Task Management provider.
Gard/Diff
Filed
- Logseq/v/0/10/15 seems like a solid upgrade. a bit late to the game.
- Numtide/blueprint
- Binary/Cache
- Cachix
- Logseq/Entity/Organization
- IETF
- Person/Konrad Malik
- Person/Konrad Malik/GitHub/dotfiles
- Person/Konrad Malik/GitHub/neovim-flake
- Person/Konrad Malik/GitHub/darwin-docker
- Person/Konrad Malik/GitHub/incomplete.nvim
- Person/Konrad Malik/GitHub/baywatch
Updated