Files
hq/01-RESEARCH/018-the-operators-machine-as-modules/04-the-seats-of-the-environment.md
T
jochen 7fb59bde98 Research 018: the operator's machine as modules
The predecessor is retired on every node and what it still owned on the two
workstations — some thirty modules of dotfiles, user units and /etc files — is
owned by nothing. To-be 29 covers one directory under the home; the operator
wants the whole machine, system folders and home alike, as modules: one
default configuration each, varied per node by settings or a kept region,
never an edit; roles the machine has once as node-scoped seats with tool
contracts; the graphical stack gated by a capability so the same catalogue
serves the servers.

Four documents: the intended behaviour in the mesh's words; the predecessor's
desktop measured (34 modules, one with 88 files, 4 flavors and ~90 theme
variables) against what the records already give and what is missing (the
account is empty on every node, no user-scoped units, settings leak, tools run
in a container per module per node); the direction the operator set for where
tools run — one executor per node, host-side, module-agnostic, the console
renamed and moved out of its container, superseding 0047/0150 for tools; and
the candidate seats of the environment with first verbs, the shell first.
2026-10-02 15:19:25 +02:00

4.5 KiB

04 — The seats of the environment

Candidates, not decisions. To-be 33 says which verbs a seat serves is a decision per seat, taken slowly, because a seat's tools bind every future holder. This document lists the roles the operator's machine has once, who could hold each, what gates it, and a first verb or two — so each record has a starting point.

The rule for what is a seat here

A role the machine fills at most once is a node-scoped seat, declared by the module family that fills it (ADR 0126). A thing several of which coexist without contention — editors, browsers, media players — is not a seat; each is a module with its own tools, and nothing is singular about it. A seat is held by one assignment per node; other modules of the same family may be installed beside it without holding it (ADR 0040 §1, read with the sharper distinction: installed is not holding).

Candidate seats

seat holders gated by first verbs
login shell zsh, fish, bash nothing: universal execute(command); show-config; the holding itself sets the account's login shell through the host's user shape
service manager systemd the service-manager capability the profile reports units: list, status, start, stop, restart, enable, journal; user scope on each
boot grub, systemd-boot a machine that boots itself (not a container host) rebuild-images; entries
package manager pacman, apt the package-manager capability search, installed, upgrade, orphans; today a capability the host uses, not a seat anyone holds
display server xorg, wayland compositors that are their own server the graphical-session capability displays; layout
display session i3, sway the display server seat held on the node; i3 needs x11, sway needs wayland reload; workspaces; windows; move
terminal emulator xterm, alacritty, foot display session open; font
launcher rofi, dmenu display session show; theme
notifier dunst, mako display session send; history; rule
compositor picom display server (x11 only) restart; effects
lock screen i3lock, swaylock display session lock
bar i3status-rust, waybar display session reload; blocks
login manager lemurs, greetd graphical session sessions; default-session
audio pipewire, pulseaudio the machine reports a sound device sinks, sources, default, volume, mute
clipboard greenclip, cliphist display session history; clear

Not seats, modules with their own tools: the editor, the browser, the mail client, the file manager, the media player, the chat client, the agent at the terminal, the downloads folder, the scripts folder, the sync client, the power and thermal daemons that are specific to one machine's hardware.

What the table implies

Capabilities come first. graphical-session, service-manager and package-manager are reported today. A display server is held is not a capability but a seat being held, and a module that needs it declares a dependency on the seat, not on a capability: i3 needs the display server seat held by xorg. Whether a held seat can gate another's assignment is a question for the controller's resolver, and the first environment module after the shell will ask it.

The service manager comes early. Four of the predecessor's modules ship user units, and the executor itself is a unit. User scope on the host's service shape is a host change whichever module holds the seat; the seat's holder answers the questions about units, it does not apply them — the host does, as it does for every declared resource.

The shell comes first. Universal, no capability, one verb that is immediately useful on every node, and the user shape already makes the login shell declared state. It is the module that proves the pattern: a package, files under the home owned by the account, a seat claim, tools served by the executor, settings for the few things that vary per node, and a kept region for the operator's own lines.

The login manager is the first system-scope one, because it needs nothing new: a package, two files under /etc, a service — the same shape the ssh daemon module has today — and the session script it owns is the file that was hand-fixed the day this effort opened.