FAQ

A NixOS distribution for personal computing (em·a·nix — *Em*acs + *Nix*OS). It is the common core every host shares, reasoned about with the IOSHI three-concern architecture and laid out in two tiers, home/ and modules/, split by module system.

It was called eminix until 2026-08-30, when it was renamed to sit closer to the two things it is actually built from.

The distribution is a flake, not a download. It ships an installer ISO (built by your flake, so it can carry your host keys) and can also be applied to an existing NixOS install. See Installation.

Anything NixOS supports. It runs today on a laptop as a full graphical desktop, on a headless always-on server, and inside NixOS-WSL on a Windows machine — from one distribution with no per-shape variants, because shape is composed by the consuming flake rather than chosen from a menu here.

Per-machine hardware facts are not in this repository; they are a module you write (the flake carries nixos-hardware for the common laptop models). What the distribution ships is the capability — emanix.hardware.gpu and the redistributable-firmware default — never a fact about your machine. That makes adding a machine a module, not a fork.

Technically yes, practically no. Emacs is the intelligence interface, not an editor choice — the compositor runs inside the Emacs process and the agent tooling are Emacs packages. Removing Emacs leaves you with the substrate and the architecture, which is a reasonable thing to fork but is not emanix.

A Wayland compositor written in Rust on Smithay, loaded as a dynamic module inside Emacs. Windows, workspaces and status bar are Emacs objects, so keybindings and configuration are one language everywhere. EWM is an upstream project — codeberg.org/ezemtsov/ewm — not part of Emanix. Emanix packages it, launches it, and themes it.

Three concerns:

• i — intelligence interface — the workspace
• os — operating system — the substrate
• hi — hardware / internet — the machine and its network, of which the distribution ships the capability and none of the facts

They are how the distribution is reasoned about. The directories are split another way — by module system, into home/ and modules/. See Architecture.

cd ~/dotfiles
nix flake check
nix flake update
nix flake check
sudo nixos-rebuild switch --flake .#<host>
git commit flake.lock -m "flake.lock: bump all inputs"

Updates move the flake's input pins. There is no apt upgrade. The first check runs against the pins you have and the second against the pins you just moved to, so a failure tells you which side of the update it came from. Commit the lock or the next checkout will silently rebuild the old pins. Full detail, including which input moves which piece of software, is in Build and Deploy.

sudo nixos-rebuild switch --rollback

Every rebuild creates a generation. The bootloader lists them too, which is the way out when a change breaks the graphical session.

A rollback restores the system closure, not the pins. If the broken thing was an update, flake.lock still names the new revisions and the next rebuild builds the broken system again — revert the lock as well (git checkout -- flake.lock, or revert the commit) before rolling forward.

Note what rollback does not restore: live-edited files symlinked out of the store, and any data a service mutated. See Build and Deploy.

Age-encrypted in the repository, decrypted at activation by each host's own SSH host key. See Secrets.

Because recipient status and use are different things. A host is granted decryption by the recipient list; whether it deploys the credential is a separate flag. Setting that flag false does not remove the host from the recipient list — edit the recipients and re-encrypt if that is what you want.

That file is a build product. Change the option that generates it and rebuild. This is correct declarative behaviour and it surprises everyone once.

Check the spelling. emanix.theme is an enum, so an unknown name is an eval error that names the valid set — a typo fails the build rather than quietly falling back to the default. See Theming.

A machine file, a username, and a build: copy the template's host.nix, set the username in the flake, and let lib.mkDisk build the layout from the four disk values. See Adding a Host.

It was named after an individual until 2026-08-14. The namespace is the distribution's public API, and naming it after a person made it both awkward to adopt and wrong in principle. See Options.

Yes, and the seams are documented for exactly that. The tier structure, the module layout, the theme system and the host composer generalize. The shell aliases, agent instructions, git identity and mesh enrolment do not — replace them rather than inheriting them. See Adding a Host.

• Philosophy — why emanix exists
• Architecture — the two tiers
• Options — the full emanix.* reference
• NixOS Manual — the foundation
• Nix Flakes Wiki — the configuration system