Issue 213: what the container gives it, measured

04-ISSUES/213-the-controller-is-a-go-program-run-in-a-container/00-report.md

@@ -31,8 +31,9 @@ The controller is the one piece of the mesh's own Go code still shipped as an im
 §1 says a module's own code is bundles, never an image, and §3 that a bundle that is a service is a
 `process` the host runs. The controller breaks the rule it is the mechanism of: the registration
 gate that will refuse an image of a module's own code has to exempt the controller, or refuse it.
-It also costs what an image costs — a container runtime on its machine as a hard requirement, a
-container network between it and the bus and store, an image rebuild for a binary change — and
+It also costs what an image costs — a container runtime on its machine as a hard requirement,
+eight mounts standing in for files a process would simply read, an image rebuild for a binary
+change — and
 every restart of it is a container recreation, which is how the controller restarts in the middle
 of a plan today.
 
@@ -41,8 +42,9 @@ of a plan today.
 - The controller's module declares a Go bundle (`system`, `binary`) and a `process` running it
   (`./<binary>`, mesh-host #81), with its credential and store connection as files and words, not
   container mounts and a container network name.
-- What the container gives it now that a process would not: its view of the store and the bus by
-  container name, its own user, any files it writes. Each named and replaced.
+- What the container gives it now that a process would not: it runs on the host's network already,
+  as an unprivileged user (65534), with eight mounts. Each mount named and replaced by a path, and
+  the user by an account the host declares.
 - The handover: the controller restarting itself as a process, on the one machine that runs it,
   without a window where nothing answers the mesh's verbs.