Files
hq/01-RESEARCH/018-the-operators-machine-as-modules/02-what-exists-and-what-is-missing.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

6.9 KiB
Raw Blame History

02 — What exists, and what is missing

Measured 2026-10-02 on one installation: two workstations, two servers, all four converged to the mesh; the predecessor retired on the last workstation the day before. Numbers are from the machines and the repositories, not from memory.

1. What the predecessor's desktop looks like

The predecessor's catalogue on the laptop held 34 modules, of which 28 are the operator's environment rather than services. By what they declare:

shape count examples
package only 9 browser, mail client, process monitor, media player, file manager, chat
package + /etc files + system service 5 login manager, display server, power and thermal daemons, package manager configuration
package + files under the home 6 shell and prompt, the agent at the terminal, scripts, the sync client, a music player
files under the home + user units + hooks 2 the desktop environment, audio
third-party organisation tooling 6 out of scope here

The desktop module alone declares 88 files, 4 flavors (the window-manager stack, and one per class of machine), 2 user units with a hook to enable them, 8 files under /etc, a wallpaper shipped as an asset, and reads about 90 environment variables as theme knobs, substituted into its templates at sync time and set through a theming tool. Its hook exists because shipping a unit file does not run it: one unit had been deployed for months and ran on one machine only, because somebody had enabled it there by hand.

The shell module ships ~/.zshrc, the prompt configuration, an ~/.ssh/config that the predecessor generated from its registry, and a LOGIN_SHELL variable applied with chsh by a hook. Two flavors: the prompt theme, and autocompletion.

Other modules write into the desktop module's files. The chat client places i3 and notifier snippets into config.d directories the desktop module owns, and its launch flags, window placement and notification colours are each a variable with a default.

One-off steps live in hooks across the set: enable user units, chsh, create a swap file, mkinitcpio, enable a vendor VPN service the package ships disabled. Every one is state the host could declare or a verb a seat could serve; none is today.

2. What the migration did with them

The migration's module to-do scoped the whole set out as desktop / workstation ricing — the workstation's own environment and node/OS tooling — managed on the node, never catalogue. The last workstation's runbook then split the same set three ways: A, system scope, which the host's vocabulary can express today (the login manager, the display server, the power daemons, the package manager, the container runtime); B, under a home or a user unit, waiting on to-be 29; C, package only, the operator's call. The migration log closes the workstation with the operator's desktop awaiting its design.

Two things followed from scoping them out. Nothing regenerates those files now, so a fix is a hand edit — the login manager's session script was fixed this way on the day of writing, and recorded in a repository nothing deploys from. And the one piece of this family written as a mesh module, the ssh client, was closed on hold in the catalogue until the controller carried the account fact.

3. What the records already give

wanted record state
one module per managed thing; every module may have tools ADR 0040 accepted; examples are services, and the shell is named as a shared seat
a module declares its own node-scoped seat ADR 0121, ADR 0126 accepted
a seat's contract is its tools; a holder may add its own ADR 0132, ADR 0170 accepted; one node seat serves verbs live
a capability the machine reports gates a holder ADR 0161 §3 accepted; the profile already reports graphical-session
the account as a node fact; a file under the home owned by it to-be 29 §1–2 built in the controller; its record proposed in an open change
inside a home: owned, written into, written by the module, found proposed in the same change proposed
a setting declared with type, meaning, default and cost proposed with the container-runtime records proposed
a managed file is derived; an edit is overwritten ADR 0011 accepted
the mesh writes into a shared file, never over it ADR 0102 accepted
a module names no path; the host resolves the home ADR 0112 accepted
the user shape: a login shell is declared state to-be 05 designed; used by no module

4. What is missing

  1. The account is recorded nowhere. The node record has the column; on all four nodes it is empty. Every home-scoped module is unassignable until the operator states it.
  2. User-scoped units. The host's service shape has no user scope. To-be 29 says it plainly: a workstation's per-user daemons have no form the mesh can send. The desktop module's two units, the audio masks, the power module's memory guard and the thermal daemon's profile switcher all need it.
  3. One-off steps. mkinitcpio, chsh, creating a swap file. Each is either declared state the host lacks a shape for, or a verb a seat should serve. An action in a declaration is refused over the link, and rightly.
  4. Settings leak (issue 168): a setting reaches every mergeable file and every contribution of its module. Ninety theme knobs on that mechanism would reach ninety files. The proposed settings record says a setting names the file it lands in; that has to ship first.
  5. Where tools run. Every module that serves a tool today does so from its own container per node. See 03.
  6. A seat's verbs are undecided for every seat but three. To-be 33 leaves which verbs each seat serves as a decision per seat, slowly. The environment adds a dozen seats.
  7. Catalogue placement. The media chain left this catalogue for its own; whether the environment does the same, and whether a third-party organisation's tooling belongs in a public catalogue, are unasked.