tag: NixOS

I’ve mentioned the insane power of NixOS’ QEMU-based integration tests. If you're wondering why you (yes, you!) should care at all about this random Linux distro, expand this carat for my summary. For those not in the know, a **NixOS configuration** is a data structure that fully determines a Linux system, from the kernel to the users and the systemd processes. It's a highly reproducible artifact backed by the largest open-source package repo in existence. You can: Put it in version control and use it for your daily driver to make hardware migrations painless Deploy to bare metal VPS with low-resource “build-then-push” tooling Build Docker/OCI containers from it to appease corporate goons Run it in CI/CD pipelines Share it with teammates for identical dev environments Parameterize it to define a cluster of nodes The integration test framework lets you define virtualized nodes with pass/fail conditions on the behavior of the components therein. Furthermore the nodes can be embedded within an arbitrary network topology to test the overall system-of-systems behavior. With the tests defined, they’re wrapped into the very notion of validity for your configuration(s). ...

There’s a lot going on in the Nix ecosystem. If you haven’t slogged through the thesis then it might seem downright opaque. This is my attempt at an easy explainer for newcomers. The Tool and the Language Let’s bootstrap ourselves with some circular facts. Nix is a tool for building (or “packaging”) software components using instructions expressed in the Nix language. The Nix language is even able to package the Nix tool (which is mostly written in C++), thus closing the epistemological loop. ...

In the marketplace of developer skills, there’s a certain category that I’m long-term bearish on. They don’t warrant investing free time trying to level up. Devs should limit their exposure to the minimum necessary to do their job. I’m talking about tools like Docker, Kubernetes, and the intricate managed hosting platforms of Azure and AWS. These are tools that help manage social problems caused by scaling organizations to thousands of engineers existing complexity laziness or desire to throw money at a problem rather than solve it While they do solve real technical problems, I’ll argue here that there’s superior tooling for most use cases outside of big tech and legacy systems. ...

Our starting point here is a node that is freshly infected with NixOS. For changing the system, we have 2 options. SSH in and edit the configuration files (or copy them over) and then run nixos-rebuild switch which triggers the node to pull and build all the necessary items. Check and build the configuration locally, and copy the entire closure across. At a glance there might not be an advantage to one or the other. But consider if you’re deploying custom content that isn’t part of nixOS builtin configuration. To use method (1) you would need to clone all your repos on the server to be able to rebuild. Then every update requires you to ssh in and pull. ...

Here’s an easy way to get a NixOS node spun up using nixos-infect. 1) Set up a new droplet Choose Ubuntu 22.04 Add SSH keys for something you have a local IdentityFile for. Under “Advanced Options” -> “Add initialization scripts” paste #cloud-config write_files: - path: /etc/nixos/host.nix permissions: '0644' content: | {pkgs, ...}: { environment.systemPackages = with pkgs; [ vim ]; } runcmd: - curl https://raw.githubusercontent.com/elitak/nixos-infect/master/nixos-infect | PROVIDER=digitalocean NIXOS_IMPORT=./host.nix NIX_CHANNEL=nixos-25.05 bash 2>&1 | tee /tmp/infect.log 2) SSH in and copy config down Add the node’s SSH config to ~/.ssh/config ...