Hello,
I'd like to introduce a project I've been designing: GNU AI, an
artificial intelligence stack built entirely as GNU/Hurd
translators.
The idea follows the Hurd philosophy to the letter: every
responsibility lives in its own translator, and all interactions
between components go through the filesystem — never through
sockets, proprietary APIs or linked libraries.
The stack consists of five translators:
* inference-translator — the human interface: takes prompts,
composition in any $EDITOR (nano, vim, emacs…), explains each
action it takes, colored and animated CLI; exposes the prompt
as a structured request.
* orchestrator-translator — pure coordination: scheduler,
supervisor, evaluator, aggregator. It starts N
neuron-translator instances on /llm1…/llmN with different
topologies and merges their outputs (majority vote / weighted
average).
* neuron-translator — the compute unit: a feedforward sigmoid
network driven by plain POSIX writes and reads.
* httpfs-translator — pure HTTP transport: a URL becomes a
filesystem tree (content, headers, status). A non-200 status
is data, not an error.
* data-base-translator — PostgreSQL persistence (libpq): the
only component allowed to speak SQL.
The core contract is a JSON trio, frozen at phase 0:
* request — prompt → structured request (task, URLs, params)
* status — execution tracking
* result — final aggregated output
So a complete run looks like:
echo "summarize https://…"; | tee /inference/prompt
the orchestrator reads /inference/request, mounts httpfs on the
URL, archives the fetched content as training data (SHA-256
dedup), runs N networks, aggregates — and the answer is readable
with cat /orchestrate/result.
The same stack runs on one machine or in a datacenter / local
cluster: the user's interface connects through SSH with
per-user keys, and a server process spawned per session relays
the trio. No dedicated listening ports, no certificates —
encryption and authentication are delegated to OpenSSH. Public
keys live in a PostgreSQL registry that is the single source of
truth for authorized_keys.
Technical choices: C23, POSIX.1-2008, trivfs for the MVP (netfs
later), GPLv3+, zero allocation in hot paths, prepared statements
at mount time.
The full roadmap, contracts and phase-by-phase plan are here:
https://gnu-ai.org/doku.php?id=plan
Everything is still at the design stage — the contracts are being
frozen now, no code yet. I would really appreciate feedback from
the Hurd community, especially on:
* the translator-based decomposition — does splitting an
AI stack this way fit the Hurd model?
* trivfs vs netfs for the /inference tree;
* the per-session SSH server process as a remote-access
pattern.
Thanks,
Claire Ivanenka
https://gnu-ai.org
