-The script starts a "subhost" with a dedicated network namespace, and
-the mount and pid namespaces separated from the main host by means of
-+unshare+. A subhost root file system may in particular be set up as
-an overlay of the main host filesystem to keep the specifics of a
-service distinctly separate from the main host while sharing files
-wherever sensible.
-
-A subhost is started by identifyinf its configuration file on the
-command line for *overlay-boot*. The configuration file is a plain
-text file with a small collection of "variables" that tell how the
-subhost is set up. When all is good, *overlay-boot* spawns a
-subprocess that invokes a command shell within an chroot into
-"unshared" subhost root filesystem, all similar to the bootup of any
-odd computer.
-
-The subhost execution environment may be "entered" to perform
-adminstrative tasks with *overlay-go*, and it is later stopped with
-*overlay-stop*.
+The script starts a "subhost" whose root filesystem is an overlay on
+the main host filesystem, and with separate mount, network and pid
+namespaces. In effect an administrative sandboxing that is
+prepopulated with a copy of the overlaid filesystem.
+
+The subhost is defined by means of a configuration file, __conf__,
+that is a simple text file with small collection of "variables"
+telling how the subhost is set up. *overlay-boot* spawns a subprocess
+that performs the boot-up of the "subhost" as an init script that ends
+with a pid 1 +reaper+ that simply "reaps" any terminated child
+processes.
+
+The administrator may "enter" the subhost execution environment to
+perform adminstrative tasks by means of *overlay-go*, which starts an
+interactive shell within the subhost namespaces. Usually this is only
+used initially for configuring the subhost's network and set up an
+_sshd_ service for subsequent access.
+
+Subhost execution is stopped with *overlay-stop*.