Nixpkgs has a due-process problem. A project has a due-process problem when people have real power but the rules around it are vague. Nixpkgs committers can merge and close pull requests. Reviewers can block them. Teams can remove commit access and decide policy. Yet the project does not always say what standard applies, who decides, or how a mistake can be corrected. This is not an argument against strict review. Security, licensing, attribution, maintainer time, and contributor conduct all matter. The glibc work I recently submitted changes the dynamic loader and rebuilds the world. It should be reviewed unusually carefully. I have also made bad merges.

~4.5 years ago I bought Dell XPS 15. It was a powerhorse without a match for that size/price. I must admit that I wasn’t happy about it: Webcam is positioned below the screen, recording my typing fingers instead of my face. Battery getting swollen (and being forced to fly that way wasn’t fun), after replacing it happened again. The CPU fan is loud and throttles a lot. There’s only one company in Slovenia that does warranty repairs and takes the law-specified 40 working days to finish their job (replacing a battery, for example). Too heavy (over 2kg) I’ve decided to go back to Thinkpads, as they are unmatched by the overall experience and quality to run Linux.

In the last 6 years working with Nix and mostly in last two years full-time, I’ve noticed a few patterns. These are mostly direct or indirect result of not having a “good enough” infrastructure to support how much Nix has grown (1600+ contributors, 1500 pull requests per month). Without further ado, I am announcing https://cachix.org - Binary Cache as a Service that is ready to be used after two months of work. What problem(s) does cachix solve? The main motivation is to save you time and compute resources waiting for your packages to build. By using a shared cache of already built packages, you’ll only have to build your project once.

Every now and then (actually quite often), people complain on twitter they’re afraid of our simple bash installer for Nix package manager: $ bash <(curl https://nixos.org/nix/install) Example (from today): There are popular blog posts discouraging use of it. Ask yourself a question, how would package manager install itself? Via another package manager? If we assume nixos.org is not compromised (which is really hard to detect), using TLS to secure connection and with our simple trick to prevent partial download execution (you haven’t read the script yet, right?), what can really go wrong?

This particular blog post was sitting on my mind for a long time. I don’t want to start a flame war, but at the same time I also don’t wish for Linux community to build and grow upon ad-hoc solutions that we’ve accumulated over the last 30 years to the packaging and deployment problems. History of Linux automation Remember (old-timer?) Linux user typing commands into terminal that goes and mutates the state of the Linux machine. They’ll go and stop a process, change configuration file and start the process again. They’re the one connecting to the machine and making sure the state of the Linux machine is mutated correctly. Let’s call this method Imperative Configuration.