u/anandsuresh81

"The hash comes from the inputs" is the usual answer, and it's incomplete — it never says what Nix hashed: the file you wrote, the derivation it evaluates to, the built bytes, or the dependencies.

- Most package paths are input-addressed. Nix names the output from the derivation (the concrete build recipe) before the build runs. That's why editing a .nix file doesn't always move the path — two expressions can evaluate to the same recipe — and why changing a real recipe input does.

- Some paths are content-addressed. `nix store add` hashes bytes that already exist. Both live under /nix/store, so calling every store path "content-addressed" misses the split.

The name is also only part of the record: built paths reference other paths, Nix records the graph, and the closure is everything that must travel with a path to another machine.

Disclosure: I build LabCraft, and I just shipped this as a free, hands-on lesson. You inspect a real NixOS machine (the OS itself is the biggest store object) and predict what moves a path before the machine answers. No Nix language required: https://www.labcraft.dev/blog/nix-store-paths?utm_source=reddit-personal&utm_medium=social&utm_campaign=nix-store-paths-2026q3&utm_content=r-nixos-hash-names-01

I wrote up a small LabCraft engineering note from teaching Nix in real Linux VMs.

The short version: nix search nixpkgs jq looks like a tiny lookup, but cold evaluation of nixpkgs averaged 3865.4 MiB peak RSS in our measurement. In a 2 GiB training VM, that meant the learner saw warnings, silence, then Killed.

We kept the learner-facing command unchanged, pinned the Determinate installer + nixpkgs revision, proved the eval-cache key, and baked the sqlite into the image layer. Warm path averaged 586.5 MiB.

https://www.labcraft.dev/blog/nix-didnt-hang-it-was-evaluating-the-world?utm_source=reddit&utm_medium=community&utm_campaign=nix_didnt_hang&utm_content=post

I’m Anand, and I’m building LabCraft, a hands-on learning platform for infrastructure and systems tools. The first course is Nix/NixOS.

I’m starting here because Nix has been a major part of my own learning path over the past six years, and because I’ve seen how hard it can be to onboard people without someone experienced nearby.

The course is built around the places people usually get stuck: shell/profile setup, disabled experimental features, flakes that work but don’t make sense yet, confusing build errors, and the gap between copying a working snippet and understanding the system underneath it.

The course runs in a real VM, not a browser emulator. Steps are checked against what actually happened on the machine, not quiz answers or exact command strings.

I wrote up the thinking here: https://www.labcraft.dev/blog/introducing-labcraft

The course is opening in small batches while I settle the VM capacity, checks, and content.

I’d especially value feedback from people who have learned Nix, taught it, onboarded a team to it, or watched people bounce off it. What were the points where people actually got stuck?