NixOS Introduction at the "Tech Over Tea" Podcast

Links
1

@RossComputerGuy in an interview with Brodie Robertson

Youtube:

Podcast

Tech Over Tea #268, you can find it via Antennapod, Kasts etc.

10 Likes
2

I was going to share it here but forgot lol. It was fun being on Brodie’s podcast.

5 Likes
3

I loved listening to this. I’m missing a lot of knowledge on nixpkgs and the build side of things so it was really interesting to hear about that!

I think a lot of the terminology around nix is better explained once you understand what the store looks like. When trying to explain these nix concepts I usually go something along these lines.

  • The Nix Store is a bundle of software. All of these are named with a hash of their build inputs, so every version and set of flags represents a unique Store object.
  • Each of these objects can be seen as a node in a DAG, and form a great big tangle of dependent software. But importantly, you can take any one of these nodes and you’ll be able to traverse the tree of all its dependencies.
  • Nix is not immutable because you can’t change the store, but it’s immutable because adding software only adds to the store. The only time store paths are removed is during garbage collection.
  • There are profiles, which represent entry points to the store.
  • There’s a special system profile, which contains all the system dependencies and an activation script.
  • Because store paths are not removed, any update to the system or a package in the system results in a new system generation.
  • This also means that none of the old store paths are removed, meaning you can switch back to a previous profile generation and it will not have been changed.
  • This makes Nix atomic, not only are packages installed atomicly (I.e. no half installed Firefox) but system updates are atomic too, opposed to something like arch where you could be halfway through a system update and then have a failure and failed role back which leaves you with a half updated system.

Opposed to image based immutability, you get a lot more fine grained control of dependencies. Images don’t really solve dependency management at a theoretical level, though it’s a great practical solution. Nix dependency trees are also a lot more lightweight, since they only include what’s needed. Whereas even alpine Linux images have a lot of base libraries and dependencies that might be needed by all kinds of software.

I think the biggest point in favor of nix on non-nixos systems are Dev environments. Direnv makes it pretty magical, and a lot of the pain points with devcontainers such as running and developing graphical programs.

The example I usually go to for build reproducibillity is how it enables the CA store, which would let enable stuff like bittorrent or ipfs caching.

5 Likes