ThermOS

Think: NixOS meets macOS.

A declarative Linux system. Easy to use, joyful to configure.

Under active research

Why

NixOS proved declarative system management works. But it was built by hackers for hackers. There is no boundary between what users should see and what modules use internally. That makes a real GUI impossible.

ThermOS draws that boundary. User-facing options are separated from internal wiring, making a real configuration interface possible. Not a code editor, but something closer to system settings.

Why Adios?

A stable user experience requires stable module boundaries. When you change a module, the effect should be local and traceable.

NixOS modules share a single global fixpoint. config is both input and output. Every module reads from the same namespace it writes to. There is no boundary between what a module consumes and what it produces, so there is no way to tell what a change will affect.

Adios separates inputs from outputs. A module declares what it reads, publishes what it produces, and cannot reach into another module without declaring the dependency. That separation is what makes stable interfaces possible, and stable interfaces are what makes a GUI possible.

How it works

Try it

Requires Nix. Container boot needs systemd-nspawn, QEMU boot needs qemu-system-x86_64 with KVM.

git clone https://github.com/hsjobeki/thermos
cd thermos
./run.sh          # nspawn container
./run.sh --qemu   # QEMU VM (serial console + SSH on :2222)

Login: root / thermos. Stop nspawn: poweroff. Stop QEMU: Ctrl-a x.

SSH into the QEMU VM. Root login is key-only; the authorized key is in systems/qemu.nix (swap in your own).

ssh -p 2222 root@localhost

Roadmap