Gendisk OS

            ░░░░░░
        ░▒▓▓▓▓▓▓▓▓▓▓▓▒░
      ▒▓▓▓▓▓▓▓▓▒▒▒▓▓▓▓▓▓▒░
    ░▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓░
    █▓▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒ ░▒▓▓▒
   ▒█▒▒▒▒░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▒▓▓▒
   ▒█▒▒▒▒▒▒▒▒▒▓▒▒░▒▒▒▒▒▓▒▓▒▒▒▒▒▓▓▒
    ▓▓▒▒▒▒▒▒▒▓░ ░░░ ░▓▒▓▒▒▒▒▓▒▒▒▒▓▓▒
     ▓▓▒▒▒▒▒▓▒ ▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒░▒▓▓
     ▓▓▒▒▒▒▒▒▓░░░▒░░░▓▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓
    ▓▓▒▒▒▒▒▒▒▒▓▒░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▒
   ▒█▒▒░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▒
   ▒█▒▒▒▒░▒▓▒▒▒▒▒▒▒▒▒▒▓▒▒▒▒▒▓▓▓▒
    █▓▒▒▒▒▓█▒▓▓▒▓▒▒▓▒▒▓▒▒▒▓▓▓▒
    ░▓▓▒▒▒▒▒▒▓▓▒▓▒▒▒▒▒▒▒▓▓▓░
      ▒▓▓▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▒░
        ░▒▓▓▓▓▓▓▓▓▓▓▒▒░
            ░░░░░░

            ▓▓▓▓▓▓
        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
    ▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓
   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
    ▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
     ▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
     ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
   ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
            ▓▓▓▓▓▓

What this is: a documented 3 a.m. systems fever dream. It is not implemented, not planned, and possibly a terrible idea. Gendisk is a speculative remix of Gentoo, Plan 9, Inferno, and Sun-style network computing in which one Linux substrate generates many isolated userland and ABI “worlds” on demand. The page preserves the idea so it can ask one useful question: is the Linux distribution the wrong abstraction layer? It is not a roadmap, product proposal, or claim that this system should be built.

One Kernel. One Disk. Many Worlds.

The provocation

Traditional Linux distributions usually present one machine as one coherent system: one global userspace, one preferred package model, one library graph, one runtime identity, and one root filesystem.

Gendisk rejects that equation.

one machine ≠ one system
one machine = many execution worlds

Linux becomes a shared substrate. Above it sit multiple isolated worlds, each carrying its own userspace, ABI, runtime, package ecosystem, and state history. The machine is no longer the main unit of organisation. The root is—and later, even the root becomes only an address in a larger execution space.

This is a remix of Gentoo as an idea, not a new Gentoo derivative. Portage moves below daily package management and becomes a policy engine describing what the system is allowed to build. Prebuilt environments provide normal daily operation.

Conceptual ancestry

The thought experiment intentionally collides several traditions:

• Plan 9: per-process namespaces rather than one unquestioned global view;
• Inferno: the network treated as an extension of the system;
• Sun Microsystems: networked workstations and the idea that system boundaries need not end at one chassis;
• BeOS: indexed metadata and live queries as an interface to state;
• Gentoo and Portage: policy, source-level variation, and explicit build decisions;
• Bedrock Linux: federation between otherwise incompatible distribution ecosystems;
• Btrfs: cheap snapshots, cloning, promotion, rollback, and replication.

These references are inspirations, not claims that their designs can simply be combined. Their assumptions conflict. That conflict is part of the experiment.

The fractal state model

The same conceptual structure repeats at several scales:

Universe
└── Node
    └── Root
        └── Subroot
            └── Process namespace

Every level can be discovered, queried, selected, entered, cloned, and discarded. A root resembles a node; a node resembles a small cluster; a cluster can still be addressed as one system. This recursion is why the model is described as fractal state on demand.

Universe

The Universe is global policy rather than global installed state. Portage lives here as the build authority and dependency-graph engine. It describes possible states through profiles, USE flags, accepted package variants, patches, hardware policy, and binary-generation rules.

The Universe answers:

what is allowed to exist?

It does not answer:

what is running here now?

Node

A node is one participating machine: desktop, laptop, server, VM, edge device, or worker. Every node is complete locally. Networking enlarges the address space but is not required for the machine to function.

Root

A root is a filesystem state, ABI domain, and execution world. It is neither a full VM nor merely a container image. Roots share one kernel and hardware substrate while owning their own libraries, tools, desktop, package ecosystem, and rollback history.

Possible roots might include:

stable      gaming       ai
testing     legacy       throwaway
rice-niri   rice-hyprland

Subroot

A root may contain another isolated root. The rule is recursive rather than special-cased: a subroot can be queried and entered using the same language as its parent.

ABI per stratum

Gendisk deliberately refuses global ABI unification. Imported runtime ecosystems—called strata—retain their own assumptions.

A stratum could provide binaries and userspace from Arch, Debian, Alpine, Artix, or Gentoo. The goal is not to merge all of them into one /usr. The system selects the correct coherent environment for each process.

This knowingly duplicates libraries, package databases, and support tools. It is less storage-efficient and less elegant than a unified dependency graph. That waste is accepted to explore whether incompatibility becomes easier to reason about when it is spatially explicit instead of hidden behind global compatibility machinery.

Three package scopes

The conceptual package model separates responsibility:

• @world describes one root’s execution environment;
• @system describes node-level hardware and shared support;
• @universe describes global build policy and allowed variants.

Daily use is binary-first. Portage is invoked beneath that layer when a specific patch, USE flag, optimisation, or unusual compatibility build is needed. In theory this combines fast iteration with source-level authority. In practice it creates difficult provenance and dependency questions that this page does not solve.

Query-driven execution

Paths remain real, local, and inspectable, but they stop being the primary user interface to execution. Roots advertise indexed metadata:

gpu=amd
state=stable
abi=mesa
seat=0

A request could look like:

gendisk run abi=mesa state=stable firefox

The system resolves a compatible root, binds the process namespace, and starts the program inside that world. Search is therefore not only about finding files; it selects an execution context.

Search is not truth

Indexes are projections. They may be stale, incomplete, federated, or discarded. Truth remains the local filesystems, manifests, snapshots, process state, and logs that a node can inspect without a central service.

Every node would run a coordinator called gendiskd for local indexing, queries, root discovery, execution orchestration, event watching, and optional mesh participation. The daemon coordinates state but never becomes its source of truth.

Optional mesh

A standalone node must remain complete. When nodes connect, their execution worlds become addressable as pairs:

desktop:stable
server:ai
laptop:mobile

Queries may federate and a remote world may expose capabilities, metadata, or execution. Adding a machine should expand the address space without changing the underlying model.

This is where the Inferno and Sun influence becomes most visible—and where the idea becomes least resolved. Authentication, latency, failure semantics, hardware transport, observability, and distributed policy are all open problems.

State lifecycle

Btrfs subvolumes supply the imagined state primitive:

build → snapshot → test → promote → rollback

Roots can be cloned cheaply, modified, promoted to stable use, or discarded. A testing world becoming stable is a snapshot transition rather than a long sequence of mutations applied to the only installed system.

The Cookbook is a conceptual artifact store containing binary packages, metadata, build definitions, and variants generated from Universe policy. Builds happen once, while roots consume prebuilt artifacts and retain the source decisions that produced them.

Shells, seats, and hardware

System plumbing uses POSIX sh for portability between strata. Human-facing shells remain a user choice. An object-oriented shell such as PowerShell could optionally express structured queries, but it is not fundamental to the model.

Seats are treated as execution domains. One seat might bind an AMD GPU and a gaming root while another binds an NVIDIA GPU and a control or build root—all under one kernel. This is an attractive diagram and an extremely difficult hardware-isolation problem.

Where the idea probably breaks

The thought experiment deliberately does not hide its liabilities:

• one shared kernel is both the main efficiency and the main isolation limit;
• incompatible userspace expectations do not disappear because they receive separate names;
• GPU stacks, device ownership, kernel modules, and seats resist clean recursive composition;
• duplicated ABIs multiply storage, patching, vulnerability, and provenance work;
• metadata queries introduce indexing races and ambiguous selection;
• recursive roots make debugging and ownership harder;
• federation creates authentication, trust, latency, and split-brain problems;
• Portage policy plus foreign binary strata may be more complicated than simply operating several normal systems;
• promotion and rollback do not automatically preserve mutable application data safely.

No performance model, threat model, bootstrap process, package format, daemon protocol, namespace implementation, or recovery specification has been designed.

Why preserve it?

Gendisk is useful as a question even if it would be awful as software.

It asks whether distributions bundle together concerns that could be addressed independently: build policy, runtime ABI, hardware support, user environment, state history, and network identity. It asks whether deliberate duplication can sometimes make boundaries more understandable, and whether execution worlds are a better interface than a single globally mutable installation.

The final image is not a machine running one operating system. It is a local substrate hosting many addressable worlds, with the same vocabulary extending outward when another node appears:

discover → query → select → execute

That is the complete ambition—and, intentionally, the end of the project.