How I like to install NixOS (declaratively)

Original Article ↗ Hacker News Discussion ↗

Cross‑posting bot and HN norms

  • A sizable subthread investigates an account that auto‑reposts links from Lobsters to HN, with timing data showing ~140s average lag and many near‑simultaneous duplicates.
  • Some see this as “karma arbitrage” or Digg/Reddit‑style fake‑user behavior that can bury an original author’s self‑submission.
  • Others, including moderation, argue HN is better with these submissions than without, but that author posts should ideally “win” and some automation might help detect conflicts.
  • Concerns: bots vs “authentic” users, lack of bot labeling, and a perception that special cases are tolerated in ways that wouldn’t scale.

Declarative NixOS installation approaches

  • Many are enthusiastic about fully declarative installs using custom ISOs, nixos-anywhere, and disko for disk layouts, especially for VMs, appliances, PXE boot, and disaster recovery.
  • One commenter notes you can get most of the benefit by running a boot‑time script on a vanilla installer instead of building a custom image.
  • disko’s RAM use can be problematic on low‑memory machines, especially when invoked via nixos-anywhere; alternatives include simpler partition scripts or calling disko directly.
  • Related patterns: ephemeral RAM‑booted systems, “lustrating” an existing Linux install into NixOS, and VM‑based testing of configs before deploying to hardware.

Learning curve, docs, and ecosystem complexity

  • Many praise NixOS’ power and reproducibility but describe a “harsh” or “vertical” learning curve.
  • The language itself is often called simple enough; the real difficulty is the ecosystem: overlays, options, builders, multiple ways to do packaging, and under‑documented tradeoffs (e.g. Python packaging, containers).
  • A common workflow is to learn by reading nixpkgs source and other people’s configs; several note this is hostile to newcomers.
  • NixOS’ GUI installer is considered fine for a one‑off laptop, but insufficient when you want reproducible servers or VMs.

Declarative vs imperative tools (Ansible, Puppet, others)

  • Some argue the time to automate installs declaratively isn’t worth it for a single personal machine; partition + mount + nixos-install is “5 minutes”.
  • Others counter that front‑loading effort pays off for many machines, quick VM spin‑up, and reliable recovery.
  • Comparisons:
    • Ansible/Puppet: easier to reuse across distros and less “all‑in”, but more imperative and less hermetic than Nix.
    • Arch/Ubuntu: could theoretically add declarative layers, but in practice tools like Ansible fill that niche.
    • Distrobox and containers are suggested as escape hatches for “normal” C/C++ or Python workflows on Nix.

Nix language and module system debate

  • Several people “love Nix, hate the language,” wishing for F#/Scheme‑like alternatives, or a VM that other languages can target.
  • Others strongly defend the language as already ergonomic; they say the hard part is the module system, packaging conventions, and poor error messages.
  • The module system (options, fixed points) is criticized as effectively a second language with little tooling support (no good LSP), making debugging and comprehension hard.
  • Guix is mentioned positively as having a nicer language and better documentation, though it comes with its own tradeoffs.

Real‑world experiences: successes and frustrations

  • Success stories:
    • Complex audio setups (with musnix and RT kernels) made reliable and low‑latency, something users couldn’t achieve on Ubuntu.
    • Easy NixOS integration tests and VM builds that catch bad configs before they brick headless servers.
    • Clean abstractions for specialized use cases (e.g. PXE boot, blue/green deployments, custom installers per host).
  • Pain points:
    • Nix‑Darwin seen as buggier and rougher than pure NixOS.
    • Occasional package conflicts and confusing error messages undermine the “everything’s isolated” model for some.
    • Non‑FHS layout breaks assumptions of many C/C++ and Python projects; workarounds include steam-run, nix-ld, or writing flakes/devshells.
  • Some eventually return to traditional distros plus Ansible, preferring familiar tools and less conceptual overhead.

Politics and forks

  • Brief mention of governance/politics issues in the Nix community; forks like Aux and Lix are noted.
  • Consensus in the thread is that these forks have limited impact so far; most ecosystem development continues in “mainline” Nix.