mirror of
https://github.com/Smaug123/static-site-pipeline
synced 2025-10-06 00:38:39 +00:00
78 lines
2.9 KiB
Markdown
78 lines
2.9 KiB
Markdown
---
|
|
lastmod: "2023-10-05T20:00:00.0000000+01:00"
|
|
author: patrick
|
|
categories:
|
|
- programming
|
|
- g-research
|
|
date: "2023-10-05T20:00:00.0000000+01:00"
|
|
title: Nix fireside chat outline
|
|
summary: "A talk I gave at work about the Nix build system."
|
|
---
|
|
|
|
This is simply an outline, with no actual content.
|
|
|
|
The source of truth remains [Eelco Dolstra's thesis](https://edolstra.github.io/pubs/phd-thesis.pdf).
|
|
|
|
# Why Nix
|
|
|
|
* "Works on my machine"
|
|
* Rollbacks and deletion
|
|
* Multiple simultaneous installations of things
|
|
* Deduplicate precisely what can be deduplicated
|
|
|
|
# Basic ideas
|
|
|
|
* Every package describes its build- and run-time dependencies precisely
|
|
* Cryptographic hashing to identify dependencies
|
|
* A package is identified by a hash which encompasses itself and all its dependencies
|
|
* Can find uses of a dependencies by dumb search for hash strings! This… actually works in practice (empirically)!
|
|
* Lots of rewriting of e.g. hashbangs, library loads, etc
|
|
* Can dynamically link, but you must know at build time precisely what you'll be dynamically linking
|
|
* Atomic changes
|
|
* The *Nix store* holds every package
|
|
* So you can't just assume something will be in `/usr/bin`
|
|
* Dynamic linker is intentionally crippled
|
|
* Notionally read-only and contains the entire world (garbage-collector required)
|
|
* Reproducible builds
|
|
* Can cache build results centrally and then download them, rather than rebuilding from source
|
|
* Upcoming feature: content-addressed Nix store
|
|
|
|
# NixOS (and Guix)
|
|
|
|
* Key insight: an operating system is just another package
|
|
* Kernel
|
|
* Bootloader
|
|
* Systemd jobs
|
|
* Shell
|
|
* All symlinks into the Nix store
|
|
* Benefits:
|
|
* Trivial rollback
|
|
* Can create the new version during normal operation, and then atomically switch to it by flipping a symlink when it's ready
|
|
* (asterisk: systemd restarts etc)
|
|
* Same for user environments: `$PATH` is set to a single symlink, and then the target of that symlink is atomically changed for each update
|
|
* Very unlike most other Linuxes!
|
|
|
|
# How a Nix installation works
|
|
|
|
* Daemon controls the store, you ask it to build stuff
|
|
* `/nix/store` is notionally infinite but you can only store finite chunks of it
|
|
* Database stores:
|
|
* which parts of the infinite `/nix/store` are known to be correctly instantiated locally
|
|
* cache of reference graphs
|
|
* mapping of "which derivation caused each path to be reified on disk"
|
|
* content hashes, to detect tampering
|
|
|
|
# How a package is built
|
|
|
|
* Write a Nix expression describing the package
|
|
* *Instantiate* that expression into a *store derivation*, and put in store
|
|
* Low-level build instructions for the package
|
|
* *Realise* (build) that derivation into the store
|
|
* Download any build artefacts (sources, compilers)
|
|
* Build e.g. any compilers recursively if necessary, and put in store
|
|
* Put sources directly into store
|
|
* Execute the package's builder with the inputs that now exist
|
|
* Place result in store
|
|
|
|
# Flakes (if we have time)
|