Sixos: A nix OS without systemd [video]

Original Article ↗ Hacker News Discussion ↗

Sixos goals and relationship to NixOS

  • Sixos is presented as “a Nix OS without systemd,” not a fork of NixOS itself.
  • Most of the stack is standard nixpkgs; the differentiation is in the init system (s6) and a new configuration model (“infusions”).
  • Several commenters note that systemd’s deep integration into NixOS makes pluggable inits very hard; they see Sixos as a clean-slate experiment rather than a drop‑in replacement.

Encrypted / “ownerbooted” boot and threat model

  • The “ownerbooted” design aims to avoid any unencrypted writable storage in the boot chain, using coreboot + an immutable pre‑kexec kernel in write‑protected SPI flash, then decrypting and kexec’ing into the main system.
  • Some praise this as a huge improvement over common initrd secrets patterns and over complex secure‑boot chains that have repeatedly suffered exploits.
  • Others argue that without TPM/SEP, secrets in an EEPROM can be trivially desoldered and read; they see TPM‑based binding as the only real defense against “steal the laptop” attacks.
  • One commenter objects to TPM on control/ownership grounds, seeing it as shifting power from user to hardware vendor.

Infusions vs NixOS modules

  • Multiple people find the “infusions” idea more interesting than “no systemd”: a more composable way to structure system configuration compared to NixOS’s module system.
  • Pain point called out: NixOS modules make it awkward to run multiple instances of the same service with slightly different configs; infusions are seen as a step toward solving that.
  • A linked nixpkgs PR is mentioned as another attempt to decouple from systemd and support multi‑instance services.

Systemd controversy in the thread

  • A very large subthread re‑litigates systemd:
    • Criticisms: scope creep (“eats the world”), tight coupling, harder portability to BSD/other inits, binary logging, dbus‑heavy design, bugs in resolved/networkd/timers, opaque failures, and cultural/”monoculture” concerns.
    • Defenses: unified service management, dependency handling, socket/timer activation, cgroup‑based security, consistent logging, easier packaging, widespread testing, and being “good enough” compared to shell‑script inits.
  • Some say “systemd wars are over” and alternatives are niche; others argue the ecosystem’s assumption of systemd removes real choice and justifies projects like Sixos.

Init diversity and related projects

  • Alternatives mentioned: s6, dinit, OpenRC, runit, Shepherd, launchd, SMF, and various non‑systemd distros (Artix, Devuan, Void, Alpine, Chimera, Guix, *BSDs).
  • Experiences vary: some report much greater reliability and simplicity on non‑systemd setups; others see them as fragmentation with weaker tooling and ecosystem support.