Why Nix on Linux first

Updated

September 4, 2026

Why Nix on Linux first

Goal: Decide why to run the Nix package manager on Fedora (or another Linux) before NixOS, and design a dual-stack workflow that makes the later OS transition easy—not confusing.

Why this chapter matters

Switching distros and learning Nix at the same time multiplies failure modes: bootloader issues look like “Nix is hard,” and store GC looks like “Fedora broke.”

Nix-on-Linux separates concerns:

Layer Who owns it on Fedora + Nix Who owns it on NixOS
Kernel, bootloader, base OS Fedora (dnf, rpm-ostree, bootc…) NixOS modules + generations
/nix/store software Nix Nix (same mental model)
Project toolchains Nix flakes / devShells Same
User dotfiles Home Manager standalone or imperative Home Manager (often as NixOS module)
System services (sshd, nginx) systemd units / Fedora packages NixOS services.*

Everything in the middle rows transfers. Only the “OS owner” row changes later.

Three faces again (bridge framing)

From Concepts you know:

  1. Language — expressions
  2. Package manager — store, builds, profiles
  3. NixOS — OS as a module system

On Fedora you run (1) + (2) every day. (3) waits until you want the machine itself as a flake output (nixosConfigurations).

Today (Fedora 44 + Nix)
  dnf ──────────► OS packages, kernel, desktop, SELinux policy
  nix ──────────► toolchains, CLIs, project shells, optional HM

Later (NixOS)
  nixos-rebuild ► OS + services + kernel modules as code
  nix ──────────► same store / same flakes for packages & shells
  home-manager  ► often folded into the host flake

What Nix is good at on an existing distro

Strength Concrete use on Fedora
Reproducible project envs flake.nix + direnv → same Node/Go/Rust/Python as CI
Version coexistence Old glibc-sensitive tools without breaking desktop
Non-root software Install tools without waiting for RPM or COPR
Atomic user rollback (HM) Generations for your home config
Cross-machine sameness Same flake on Fedora laptop and NixOS server
Try packages safely nix shell nixpkgs#foo — no global pollution

What you should still leave to Fedora

Keep on dnf / Atomic image Why
Kernel, firmware, mesa, GPU stacks Closest to hardware; SELinux-integrated
Desktop session (GNOME/KDE), PipeWire Distro integration and portals
SELinux policy, firewalld defaults Security baseline of the OS
Flatpaks for sandboxed GUI apps (optional) Complements Nix; different trust model
System daemons you didn’t declare in Nix Avoid two sources of truth for sshd/nginx

Rule of thumb: OS and machine identity → Fedora for now. Development surface and portable CLI life → Nix.

Dual-stack anti-patterns

Anti-pattern What goes wrong Better
Install everything with nix profile Huge profile, slow GC, PATH chaos Flakes per project + small profile
Mix nix-env -i and flakes Two eras of tooling Modern CLI + flakes only
Put secrets in the store via HM World-readable store paths sops/age later; never commit secrets
Disable SELinux “to make Nix work” Trains bad ops habits Use Fedora packaging + docs
Skip locks “Works on my machine” returns Commit flake.lock
Expect Nix to replace dnf for Firefox+kernel Wrong layer Keep browser/kernel on Fedora

Skills map: bridge → NixOS

Skill on Fedora + Nix Same skill on NixOS New on NixOS
nix build / nix run Yes —
Flake inputs + lock Yes nixosConfigurations output
nix develop + direnv Yes Same
Store, closures, GC roots Yes System profile is also a root
nix profile Optional Prefer declarative system/HM
Home Manager standalone Yes Often home-manager.users.* module
systemd user services via HM Partial Full system units via modules
Roll back user env HM generations Boot generations + HM

You are not “wasting time” on Fedora—you are doing package-manager literacy with a normal desktop underneath.

Mental model: evaluation vs realization (ops view)

flake.nix + flake.lock
        │ nix develop / nix build
        ▼
   evaluate (pure-ish)
        │
        ▼
   derivation plans (.drv)
        │ nix-daemon realizes
        ▼
   /nix/store/<hash>-name
        │
        ├─► ephemeral shell (devShell) — dies when shell exits (roots may linger with direnv)
        └─► profile generation — GC root until removed

On NixOS, add another root: system generation → bootloader entry.

Worked decision: “Should this be Nix or dnf?”

Want… Choose
ripgrep, fd, latest helix for you Nix profile or HM
Project needs Go 1.26 + exact lib versions Flake devShell
System upgrade of GNOME dnf / Software
Kernel module for VPN Fedora packages
nginx on a lab VM you will reinstall as NixOS soon Either; prefer learning NixOS module on a VM, not production Fedora host
CI-identical toolchain Flake (Nix)

Lab

  1. Write a short charter in ~/lab/nixos-book/nix-on-linux/CHARTER.md:
# Nix on Fedora charter

## OS owner
Fedora 44 — dnf handles: ...

## Nix owner
Nix handles: ...

## Out of scope for Nix (for 90 days)
...

## Success metrics
- [ ] One real project uses nix develop + direnv
- [ ] HM manages shell + git
- [ ] Disk budget for /nix: __ GB
  1. List five tools you currently install via raw binaries or language version managers; mark each Nix candidate or keep distro.

Checkpoint

  • You can explain package manager vs NixOS in one breath
  • You have a written split of responsibilities (dnf vs Nix)
  • You know which skills transfer to NixOS unchanged

Further depth