Hi: I have a PostgreSQL CRUD's translator, programmed with trivfs. Here it's the original code
https://gitlab.com/AlmuHS/hurd-translator-in-rust/-/tree/main/postgresql_crud_translator/initial_code?ref_type=heads This translator has a version in Rust. The documentation of both versions are here https://gitlab.com/AlmuHS/hurd-translator-in-rust/-/blob/main/postgresql_crud_translator/pgcrud-rust/docs/translator.en.md?ref_type=heads In the project README you can find more information about how load and use this translator https://gitlab.com/AlmuHS/hurd-translator-in-rust/#postgresql-translators-postgresql_crud_translator Maybe this can be useful for your project El sábado 3 de octubre de 2026, Claire escribió: > 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 > > > -- Enviado desde mi dispositivo Sailfish
