Deploying GNU AI on a Hurd Cluster: Feasibility Assessment ============================================================
(A working note in English, assessing cluster deployment against the current state of GNU/Hurd and future projections. Grounded in the PLAN.md files and the existing QEMU/CI tooling of the project.) 1. What GNU AI requires from the host system --------------------------------------------- The stack has modest and very specific requirements: - Hurd translator interfaces: trivfs (MVP) and netfs (full namespace navigation) — the core abstraction of the whole stack. - A C23/POSIX.1-2008 toolchain (GCC 12+ is already used). - PostgreSQL reachable through libpq — but only by data-base-translator, one component. - OpenSSH for the remote mode (sshd, ssh binary, authorized_keys). - An HTTP client capability for httpfs-translator. - No GPU requirement for the current compute layer (CPU, float32 feedforward networks). None of this is exotic. The hard requirement is the first one: translators, which means GNU/Hurd — there is no portable substitute for settrans/passive translators on Linux. 2. State of the system today (late 2026) ---------------------------------------- What works: - Debian GNU/Hurd is installable and usable as a development platform. The 32-bit port is the stable one; 64-bit (amd64) images exist and boot — the project already runs them under QEMU (mistral-vm-debian-hurd: debian-hurd-amd64 images, GRUB boot, serial console automation). - The stack already builds and passes tests on real GNU/Hurd: the httpfs-translator CI runs the full test suite (raw transport, Range/seek, parser chain) on real GNU/Hurd inside QEMU. This is not a projection: it is today's CI. - PostgreSQL, OpenSSH, GCC, make and autotools all run on Debian GNU/Hurd today. The persistence and remote-mode bricks of the stack therefore have no exotic dependency. What is still weak: - SMP: multi-core support in GNU Mach is experimental. A cluster node today is effectively treated as a modest CPU machine; the stack design (no runtime allocation, sequential access) already fits that constraint, but per-node throughput is bounded. - 64-bit: the amd64 port is pre-release quality. It boots, it builds, but it is not what one would call production-hardened. - Device drivers: supported hardware is limited (network via the DDE layer wrapping Linux drivers, storage support narrower than Linux). Cluster hardware must be chosen accordingly — or virtualized. - No GPU layer exists in Mach today. The compute layer is CPU by necessity, which caps model size at the small-model category. - Real-world long-run robustness: translators are not exercised by large fleets in production anywhere; memory leaks or long-lived-node issues will surface in a cluster faster than on a laptop. 3. Gap analysis for a cluster deployment ---------------------------------------- >From the stack's side, the gaps are honest but small: - The orchestrator currently assumes local settrans of /llm1.../llmN. Remote multi-machine launch is specified (remote mode, per-session SSH servers) but not implemented — it is a phase 5 goal of inference-translator and a natural orchestrator extension. - The supervisor persists incidents, but cross-machine restart (failover to another node) is not yet specified. - data-base-translator assumes one PostgreSQL instance; cluster failover of PostgreSQL itself is deliberately out of scope (the conninfo can point at a redundant server — the contract does not care). >From the system's side, the gaps are bigger: - Per-node performance is bounded by SMP immaturity; this is mitigated by the architecture itself (N nodes rather than one big node — the orchestrator was designed for N instances from day one). - Cluster transport rides on SSH over the network stack; SSH is proven, the network driver layer is the thinner part. - Operational monitoring does not exist: everything is cat-able, which is excellent for inspection, but no dashboards exist. 4. Feasible deployment models, in order of difficulty ------------------------------------------------------ Tier 1 — Single node (feasible today, partially proven). One GNU/Hurd machine (bare metal or QEMU), full stack mounted locally: /inference, /llm*, /db, /web. Everything except the SSH remote mode is designed for this and largely CI-tested. Effort: completing the MVP phases of the individual PLANs, not system work. Tier 2 — Small SSH cluster (feasible near-term). 2-5 GNU/Hurd nodes, one orchestrator node, users enter by SSH with revocable keys from /db, neuron-translators distributed via remote settrans/launch. The blocking work is in the stack (remote launch orchestration), not in Hurd. Requires only what Hurd already does: sshd, translators, TCP/IP via DDE. Tier 3 — Datacenter-scale cluster (projection, not yet). Many nodes, redundant PostgreSQL, GPU compute layer. This tier depends on Hurd projections rather than Hurd today: mature SMP, hardened amd64, a Mach GPU layer (none exists), driver coverage for real datacenter hardware. Feasible only as a long-term goal, "pas a pas, marche apres marche". 5. Future projections that change the assessment ------------------------------------------------- - 64-bit maturation: the amd64 port is the single biggest lever. It removes the 4 GiB-class memory ceiling and aligns with commodity hardware. The project already boots amd64 images in CI, which keeps it ready rather than locked to i386. - SMP in GNU Mach: experimental multi-core work directly multiplies per-node throughput for the hot paths (forward passes), since the stack is already designed with explicit locking and no global mutable state. - A GPU layer for Mach: the long-term wish of the project. If it ever exists, the architecture needs no change: the neuron translator is replaceable by settrans, the contracts do not mention how the compute is done. - DDE driver development: every new wrapped driver widens the hardware a cluster node can run on. 6. Verdict ---------- - Feasible today: full stack, single node, on Debian GNU/Hurd, with the existing QEMU-based CI as evidence. The remaining work is stack work (the MVP phases), not system work. - Feasible near-term: a small heterogeneous Hurd cluster over SSH, multi-user with revocable keys — the architecture was designed for exactly this shape; the delta is orchestration code plus Hurd's current immaturity in long-run operations. - Feasible long-term only: datacenter scale and GPU models, gated by system-level progress in Hurd (SMP, amd64 hardening, a GPU layer) more than by anything in GNU AI. The honest summary: GNU AI is deployable at cluster scale as soon as Hurd is, and the stack's design (N replaceable nodes, filesystem contracts, everything persistent) is precisely the shape that benefits most from each increment of Hurd progress. The stack does not need Hurd to become Linux; it needs Hurd to remain Hurd, with more cores and better drivers. Claire Ivanenka — [email protected] GNU AI — https://gnu-ai.org
