NixOS is not reproducible

Original Article ↗ Hacker News Discussion ↗

Critics of NixOS argue that, despite its marketing around “reproducible builds,” it primarily guarantees repeatable dependency graphs rather than bit-for-bit identical artifacts, and that much of the wider toolchain remains non-deterministic anyway. Many commenters highlight steep learning curves, confusing documentation, a non-standard filesystem layout, and opaque configuration layers as major barriers compared to more conventional distros, especially when problems arise. Supporters counter that NixOS still delivers strong practical benefits—like transactional system upgrades, easy rollbacks, and portable declarative configurations—and note ongoing work on content-addressed derivations to move closer to true reproducibility.

Scope of “Reproducible”

  • Many argue Nix/NixOS is not truly “reproducible” in the strict, bit‑for‑bit sense because:
    • Store paths are currently input-addressed (hashes of dependency graphs), not content-addressed.
    • Toolchains and upstream build systems often inject nondeterminism (timestamps, concurrency, filesystem quirks).
  • Others distinguish:
    • Strict reproducibility (identical artifacts) vs.
    • Practical repeatability/determinism (same versions, same behavior).
  • Some note ongoing work on content-addressed derivations and reproducibility dashboards, but acknowledge it’s incomplete.

Practical Benefits Cited

  • Strong support for:
    • Declarative system configuration in one place.
    • Atomic, transactional upgrades and easy rollbacks via bootloader generations.
    • Reusable configs across machines; consistent dev environments and CI parity.
    • Deep control over dependencies, SBOMs, and patching sub-dependencies.
  • Several users say NixOS reduced “random breakage” vs. traditional distros and increased confidence in updating.

Complexity, UX, and Onboarding Problems

  • Frequent complaints that:
    • Nix language is odd, dynamic, and hard to discover; ecosystem APIs feel ad hoc.
    • NixOS configuration replaces simple /etc edits with layers of modules and options.
    • Non-FHS filesystem and heavy symlink use are confusing.
    • Overlays and abstractions hide complexity, making debugging failures harder.
  • Examples: adb/Android tooling needing extra config; broken or missing packages on some platforms; hard integration with Python, Flutter, iOS, macOS apps.
  • Documentation and messaging described as fragmented, flakes vs “old” Nix confusing, poor search discoverability.
  • Some feel community often frames problems as user “skill issues”, which is off-putting.

Alternatives and Comparisons

  • Guix mentioned as philosophically similar (and stricter on free software) but niche; ideological stance on non-free software is a turn-off for some.
  • Other strategies: Docker/containers + config management; immutable distros with snapshots; Btrfs+Snapper; language-specific tools (e.g., Zig build).
  • Some see Nix as over-engineered for typical desktop/server use; others say once learned, it makes other distros feel fragile.