Gendisk OS

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

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

Was das ist: ein dokumentierter System-Fiebertraum von drei Uhr morgens. Er ist nicht implementiert, nicht geplant und möglicherweise eine furchtbare Idee. Gendisk ist ein spekulativer Remix aus Gentoo, Plan 9, Inferno und Netzwerk-Computing im Stil von Sun: Ein gemeinsamer Linux-Untergrund erzeugt bei Bedarf viele isolierte Userspace- und ABI-«Welten». Die Seite bewahrt die Idee, um eine nützliche Frage zu stellen: Ist die Linux-Distribution die falsche Abstraktionsebene? Sie ist weder Roadmap noch Produktvorschlag oder Behauptung, dass dieses System gebaut werden sollte.

Ein Kernel. Ein Datenträger. Viele Welten.

Die Provokation

Traditionelle Linux-Distributionen präsentieren eine Maschine meist als ein kohärentes System: ein globaler Userspace, ein bevorzugtes Paketmodell, ein Bibliotheksgraph, eine Laufzeitidentität und ein Root-Dateisystem.

Gendisk verwirft diese Gleichung.

eine Maschine ≠ ein System
eine Maschine = viele Ausführungswelten

Linux wird zum gemeinsamen Untergrund. Darüber liegen mehrere isolierte Welten, jeweils mit eigenem Userspace, eigener ABI, Laufzeit, Paketumgebung und Zustandsgeschichte. Nicht mehr die Maschine ist die wichtigste Organisationseinheit, sondern die Root. Später wird selbst die Root nur noch zu einer Adresse in einem grösseren Ausführungsraum.

Das ist ein Remix der Gentoo-Idee, kein neuer Gentoo-Ableger. Portage wandert unter die tägliche Paketverwaltung und beschreibt als Policy-Engine, was das System bauen darf. Vorgefertigte Umgebungen übernehmen den Alltag.

Gedankliche Herkunft

Das Experiment lässt bewusst mehrere Traditionen aufeinanderprallen:

• Plan 9: prozessbezogene Namespaces statt einer unhinterfragten globalen Sicht;
• Inferno: das Netzwerk als Erweiterung des Systems;
• Sun Microsystems: vernetzte Workstations und Systemgrenzen jenseits eines einzelnen Gehäuses;
• BeOS: indexierte Metadaten und Live-Abfragen als Zugang zu Zustand;
• Gentoo und Portage: Policy, Quellcodevarianten und explizite Build-Entscheidungen;
• Bedrock Linux: Föderation eigentlich inkompatibler Distributionsumgebungen;
• Btrfs: günstige Snapshots, Klonen, Promotion, Rollback und Replikation.

Diese Systeme sind Inspirationen. Es wird nicht behauptet, ihre Entwürfe liessen sich einfach kombinieren. Ihre Annahmen widersprechen einander—und dieser Widerspruch gehört zum Experiment.

Das fraktale Zustandsmodell

Dieselbe Struktur wiederholt sich auf mehreren Ebenen:

Universum
└── Node
    └── Root
        └── Subroot
            └── Prozess-Namespace

Jede Ebene kann entdeckt, abgefragt, ausgewählt, betreten, geklont und verworfen werden. Eine Root ähnelt einer Node, eine Node einem kleinen Cluster, und ein Cluster lässt sich weiterhin als ein System adressieren. Diese Wiederholung erklärt den Begriff fraktaler Zustand auf Abruf.

Universum

Das Universum ist globale Policy, nicht global installierter Zustand. Portage lebt hier als Build-Autorität und Engine für Abhängigkeitsgraphen. Profile, USE-Flags, erlaubte Paketvarianten, Patches, Hardware-Policy und Regeln für Binärartefakte beschreiben mögliche Zustände.

Das Universum beantwortet:

Was darf existieren?

Nicht:

Was läuft hier gerade?

Node

Eine Node ist eine teilnehmende Maschine: Desktop, Laptop, Server, VM, Edge-Gerät oder Worker. Jede Node bleibt lokal vollständig. Vernetzung vergrössert den Adressraum, ist aber keine Voraussetzung für den Betrieb.

Root

Eine Root ist Dateisystemzustand, ABI-Domäne und Ausführungswelt. Sie ist weder eine vollständige VM noch bloss ein Container-Image. Roots teilen Kernel und Hardware, besitzen aber eigene Bibliotheken, Werkzeuge, Desktops, Paketumgebungen und Rollback-Geschichten.

Mögliche Roots:

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

Subroot

Eine Root kann eine weitere isolierte Root enthalten. Die Regel bleibt rekursiv: Eine Subroot wird mit derselben Sprache abgefragt und betreten wie ihr Elternsystem.

ABI pro Stratum

Gendisk verweigert bewusst eine globale ABI-Vereinheitlichung. Importierte Laufzeitökosysteme—Strata—behalten ihre eigenen Annahmen.

Ein Stratum könnte Binärdateien und Userspace von Arch, Debian, Alpine, Artix oder Gentoo liefern. Das Ziel ist nicht, alles in einem /usr zu vermischen. Für jeden Prozess wird eine passende, in sich kohärente Umgebung ausgewählt.

Dadurch werden Bibliotheken, Paketdatenbanken und Hilfswerkzeuge absichtlich dupliziert. Das verbraucht mehr Speicher und ist weniger elegant als ein einheitlicher Abhängigkeitsgraph. Die Verschwendung wird akzeptiert, um zu fragen, ob Inkompatibilität verständlicher wird, wenn sie räumlich sichtbar ist, statt sich hinter globaler Kompatibilitätslogik zu verstecken.

Drei Paketbereiche

Das Modell trennt Verantwortung:

• @world beschreibt die Ausführungsumgebung einer Root;
• @system beschreibt Hardware und gemeinsame Unterstützung einer Node;
• @universe beschreibt globale Build-Policy und erlaubte Varianten.

Der Alltag ist binary-first. Portage wird darunter nur für bestimmte Patches, USE-Flags, Optimierungen oder ungewöhnliche Kompatibilitäts-Builds verwendet. Theoretisch verbindet das schnelle Iteration mit Autorität auf Quellcodeebene. Praktisch entstehen schwierige Fragen zu Herkunft und Abhängigkeiten, die diese Seite nicht löst.

Abfragegesteuerte Ausführung

Pfade bleiben real, lokal und überprüfbar, verlieren aber ihre Rolle als primäre Bedienoberfläche. Roots veröffentlichen indexierte Metadaten:

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

Eine Anfrage könnte so aussehen:

gendisk run abi=mesa state=stable firefox

Das System löst eine kompatible Root auf, bindet den Prozess-Namespace und startet das Programm in dieser Welt. Suche findet damit nicht nur Dateien, sondern wählt einen Ausführungskontext.

Suche ist nicht Wahrheit

Indizes sind Projektionen. Sie können veraltet, unvollständig, föderiert oder verworfen sein. Wahrheit bleibt in lokalen Dateisystemen, Manifesten, Snapshots, Prozessen und Logs, die eine Node ohne zentrale Instanz prüfen kann.

Jede Node hätte einen Koordinator namens gendiskd für lokale Indizierung, Abfragen, Root-Erkennung, Ausführungssteuerung, Ereignisse und optionale Mesh-Teilnahme. Der Daemon koordiniert Zustand, wird aber nie dessen Quelle.

Optionales Mesh

Eine einzelne Node muss vollständig bleiben. Verbinden sich Nodes, werden ihre Ausführungswelten als Paare adressierbar:

desktop:stable
server:ai
laptop:mobile

Abfragen können föderieren; entfernte Welten können Fähigkeiten, Metadaten oder Ausführung anbieten. Eine neue Maschine erweitert den Adressraum, ohne das Grundmodell zu verändern.

Hier werden die Einflüsse von Inferno und Sun am deutlichsten—und der Entwurf am wenigsten gelöst. Authentifizierung, Latenz, Fehlersignale, Hardwaretransport, Beobachtbarkeit und verteilte Policy bleiben offene Probleme.

Zustandslebenszyklus

Btrfs-Subvolumes liefern die gedachte Zustandsprimitive:

build → snapshot → test → promote → rollback

Roots lassen sich günstig klonen, verändern, stabil schalten oder verwerfen. Eine Testwelt wird durch einen Snapshot-Übergang stabil, nicht durch eine lange Folge von Mutationen am einzigen installierten System.

Das Cookbook ist ein gedachter Artefaktspeicher für Binärpakete, Metadaten, Build-Definitionen und Varianten aus der Universum-Policy. Ein Build entsteht einmal; Roots konsumieren vorgefertigte Artefakte und behalten die Quellentscheidungen, aus denen sie entstanden.

Shells, Seats und Hardware

Systemnahe Abläufe verwenden portables POSIX-sh. Die Shell für Menschen bleibt freie Wahl. Eine objektorientierte Shell wie PowerShell könnte optional strukturierte Abfragen ausdrücken, gehört aber nicht zum Kernmodell.

Seats gelten als Ausführungsdomänen. Ein Seat könnte eine AMD-GPU und eine Gaming-Root binden, ein anderer eine NVIDIA-GPU und eine Kontroll- oder Build-Root—alles unter einem Kernel. Das ist ein attraktives Diagramm und ein extrem schwieriges Problem der Hardwareisolation.

Wo die Idee vermutlich zerbricht

Das Gedankenexperiment versteckt seine Schwächen nicht:

• ein gemeinsamer Kernel ist zugleich Effizienzgewinn und Isolationsgrenze;
• inkompatible Userspace-Erwartungen verschwinden nicht durch neue Namen;
• GPU-Stacks, Gerätebesitz, Kernelmodule und Seats widersetzen sich sauberer Rekursion;
• duplizierte ABIs vervielfachen Speicher-, Patch-, Sicherheits- und Herkunftsarbeit;
• Metadatenabfragen erzeugen Indexrennen und mehrdeutige Auswahl;
• rekursive Roots erschweren Debugging und Besitzverhältnisse;
• Föderation bringt Vertrauen, Authentifizierung, Latenz und Split-Brain;
• Portage-Policy plus fremde Binär-Strata könnte komplizierter sein als mehrere normale Systeme;
• Promotion und Rollback schützen veränderliche Anwendungsdaten nicht automatisch.

Es gibt kein Leistungsmodell, Bedrohungsmodell, Bootstrap-Verfahren, Paketformat, Daemon-Protokoll, Namespace-Design und keine Wiederherstellungsspezifikation.

Warum die Idee bewahren?

Gendisk ist als Frage nützlich, selbst wenn es als Software schrecklich wäre.

Es fragt, ob Distributionen mehrere Anliegen unnötig zusammenbinden: Build-Policy, Laufzeit-ABI, Hardwareunterstützung, Benutzerumgebung, Zustandsgeschichte und Netzwerkidentität. Es fragt, ob bewusste Duplizierung Grenzen manchmal verständlicher macht und ob Ausführungswelten eine bessere Oberfläche sein könnten als eine einzelne global veränderliche Installation.

Das Schlussbild ist keine Maschine mit einem Betriebssystem. Es ist ein lokaler Untergrund mit vielen adressierbaren Welten, dessen Sprache sich nach aussen fortsetzt, sobald eine weitere Node erscheint:

discover → query → select → execute

Das ist die gesamte Ambition—und bewusst das Ende des Projekts.