Xylem

1.The thesis & the inversion

Today's industry stack is OS → container runtime → orchestrator, where the orchestrator (Kubernetes, Nomad, Borg, OpenStack) is an external control plane doing scheduling, replication, health-checking, failover, and autoscaling against an OS that knows nothing about the cluster. Xylem inverts that: it folds the control plane into the kernel.

A "service" becomes a first-class kernel object carrying a desired replica count and a supervision policy. Redundancy, scaling, and failover become kernel verbs — not YAML reconciled by an outside controller.

The arborist vs. the tissue

The name is the plant tissue. Xylem is a distributed transport and support network spanning the whole organism, redundant by construction: when a vessel cavitates (a local failure), flow reroutes around the dead vessel — built-in failover as a structural property. It regrows each season (self-healing / self-scaling) and it is load-bearing (structural).

2.Why JefeOS, why now

JefeOS needs an identity that differentiates it from "yet another hobby Unix clone." The owner's decision is to be a natively-clustered OS — self-redundant, self-scaling, failure-resistant — chosen because it is more fun and less saturated than re-treading POSIX. The honest secondary reason it fits: failure-resistance is already JefeOS's de-facto through-line. The recent engineering culture has been reliability-first without anyone calling it "the cluster story," and that work is exactly the substrate Xylem needs.

The "why now" is honest, too: the isolation unit Xylem operates on — the JSL-2 cell — is scoped and its gates have cleared (the NTFS dir-index gate closed 2026-06-17; Alpine apk read/write is functional, with the interactive login-prompt the last in-progress item). For the first time there is a concrete near-term substrate to build the long arc on top of. Xylem does not start now; its prerequisite just stopped being blocked.

3.JSL ⊥ Xylem — two orthogonal axes that compose at the cell

The single most important conceptual guard-rail in this document: JSL is not Xylem, and calling Xylem a "JSL tier" would be wrong. They are orthogonal axes that compose at exactly one point — the cell.

JSL is the horizontal axis (run more kinds of software on one node): JSL-1 is WSL1-style syscall translation, near-done through Alpine; JSL-2 is native containers, a single-node isolation cell. Xylem is the vertical axis (run the same software on more nodes, self-healingly). They meet at the cell:

The payoff of keeping them separate: a cell's payload is content-agnostic, so a Linux workload in a Xylem cell inherits self-replication, migration, and self-healing for free — because those are properties of the cell, not of Linux. A Linux container on stock Linux is cluster-blind until k8s wraps it from outside; a Linux workload in a Xylem cell is cluster-aware by inheritance, with no external control plane. The capability is JefeOS's, not Linux's — which is exactly why calling Xylem a "JSL tier" would bury the differentiator.

4.The Linux-host fork: WSL1 vs WSL2 inside a cell

JefeOS still aims to be a great Linux host — "WSL 2.0"-class. That goal predates Xylem and it stays, reframed as the ecosystem on-ramp in service of the Xylem identity, not a competing destination. A Linux workload in a cell inherits Xylem's verbs for free (§3). But how Linux executes inside the cell is a genuine multi-year architectural fork — one to surface honestly, not paper over. It maps cleanly onto the WSL1 → WSL2 lineage:

The lineage trap, stated plainly: the entire existing JSL/Alpine investment is Path A. Path B does not extend it — it stands beside it. That is why this is a fork to surface, not a step to schedule. The hybrid is probably the real answer over time: translate now, real-kernel-in-cell later, with both presenting to the fabric as "a cell." The fork is inside the cell; Xylem above it does not change.

5.Prior art as gold standards, NOT clone targets

Cluster orchestrators — lessons to inherit, surfaces NOT to clone

The OS-native resilience lineage — what Xylem inherits

Folding resilience into the kernel is one of the most repeatedly-attempted ideas in systems history, and most attempts died — almost never because the idea was wrong, but because they were beautiful islands with no software: technically superb systems stranded outside the ecosystem gravity well.

6.The architecture, at a high level

The cell — the unit Xylem manages

A cell is the atom of supervision: a named, supervised, relocatable unit of execution with a declared identity and a supervision contract. Xylem never schedules "a process" or "a container" directly — it schedules cells. The cell is the JSL-2 isolation cell, reused. Its payload is content-agnostic: a native JefeOS service inherits Xylem directly; a Linux workload (a JSL-1-translated process tree inside a JSL-2 cell) inherits it for free — the workload is Linux but the capability is JefeOS's.

Cluster membership — kernels watching each other

Before anything can be redundant, nodes must agree on who is alive. The differentiator: join / leave / death arrive as kernel events — node_up(id), node_down(id, reason), node_suspect(id) — delivered to the reconcile loop the way an IRQ or page fault is, not log lines an external watcher scrapes. The minimal viable protocol is a deliberate split: gossip (SWIM-style) for liveness, and a small Raft group (3–5 voters) holding the authoritative desired-state log. We invent the state machine that rides the wire, not the wire protocol or crypto.

Service as a first-class kernel object

A service is the durable thing the user declares; a cell is a runtime instance. In Xylem it is a kernel object, not a YAML manifest — carrying name, payload spec, desired_replicas, a supervision policy, a placement policy, and a scaling rule. The reconcile loop lives inside the scheduler, because the scheduler already holds ground truth at zero sampling latency:

Self-redundancy, self-scaling, live migration

• Self-redundancy is RAID for compute. desired_replicas = N is an invariant the kernel maintains. When node_down(B) fires, every cell B hosted is a deficit, and the reconcile loop schedules replacements onto survivors — honoring anti-affinity so it doesn't recreate the single point of failure. Re-replication must be single-writer (the Raft group arbitrates an ownership lease).
• Self-scaling is the same reconcile loop with desired_replicas free to move between min/max on in-kernel load and memory signals. The autoscaler and the scheduler are the same loop, so a scale-out decision and its placement are one atomic act, not two controllers negotiating over the network.
• Live migration is the second dividend of per-process page tables. A cell that owns a private PML4 is exactly a cell whose entire user address space can be walked, serialized, and reconstructed on a peer (the classic MOSIX trick). We didn't build migration machinery; we built isolation, and isolation is most of the checkpoint.

7.The hard problems, stated honestly

The thesis is seductive; the discipline this section imposes is the price of the differentiator. Every hard problem k8s has, Xylem also has — now inside ring 0, where bugs are panics instead of crash-looped pods.

8.The proof-of-thesis MVP — 2-node failover

The single demo that proves Xylem is real, concretely:

• It is the inversion, made visible. The failover happens with no external control plane anywhere — something you literally cannot demonstrate on stock Linux + k8s, where the orchestrator is the thing doing the failover.
• It is honestly scoped. Stateless → no consensus-on-data, no stateful dragon. It still needs the tractable hard parts (membership, a kernel event, single-writer re-replication arbitration), so it is not a toy. It deliberately sidesteps the §6 addressing gap — called out, not hidden.
• It is showable in one screen recording: tasklist on both nodes, kill one, watch the survivor's tasklist grow the replacement cell — driven by kernel logs, not a control-plane dashboard.

9.Phased roadmap (reliability-first sequencing)

Xylem is the long arc. Each phase is small, gated, and testable; the dev loop stays reliability-first throughout (a wedge or regression always preempts Xylem work). Effort figures are deliberately omitted — this is a direction, not a schedule, and distributed systems resist estimation.

1. Phase 0 — Solidify the cell JSL-2 isolation cell (namespaces + cgroups). Xylem cannot supervise cells it cannot cleanly isolate. Gate: JSL-2's own track.
2. Phase 1 — Kernel membership ✓ Implemented DONE (2026-06-26): two nodes discover + watch each other; node_up/down/suspect as kernel events via a SWIM-style gossip protocol (Cluster Protocol v0) over UDP. Running on both kernels, interoperating byte-for-byte, converging headless; demonstrated 2-node (C++↔C++ and cross-kernel C++↔Rust). The authoritative-desired-state Raft group is still to come.
3. Phase 2 — Single-service supervision A service kernel object + in-kernel reconcile loop that restarts a failed local cell (QNX-HAM-on-one-node, generalized). Gate: inherits the hardened teardown/reaper paths.
4. Phase 3 — Multi-node replicas + failover ★ The MVP replicas=2 across two nodes; kill a node → survivor auto-respawns the replica. Single-writer re-replication via the Raft group. Gate: Phases 1+2 and the partition/split-brain story.
5. Phase 4 — Service addressing + observability A stable front-door so a client reaches a service whose cells moved, and a xylem status view of fleet/replica state. Gate: service-VIP / DNS-SD layer is new.
6. Phase 5 — Live migration Checkpoint / ship / resume a stateless, connection-light cell — drain a node without killing the workload. Gate: connection/fd migration needs absent per-netns + shared storage.
7. Phase 6 — Autoscale desired_replicas moves between min/max on in-kernel load/memory signals, with hysteresis. Gate: coupled to SMP / cgroup-v2 CPU accounting maturity.
8. Phase 7 — Stateful cells (last, hardest) Durable replicated state — the dragon. Gate: likely needs an external/replicated storage substrate; explicitly the long, dangerous arc.

The sequencing is the point: stateless across a trusted fleet is the honest, reachable milestone (Phase 3); consensus, partitions, and stateful cells are the long, hard arc — the same arc every serious cluster system walks, now walked in C++ at ring 0.

10.Design decisions / direction

The owner resolved several of the design doc's open questions on 2026-06-17. These are direction, not shipped work:

11.Open & breakout items

Two threads are explicitly held open for dedicated future sessions: