Projekt / Betriebssystem
experimentellFF00 Ark
Ein in Entwicklung befindliches Gentoo-Recovery- und Betriebssystem, das sich in den RAM lädt, dein System bereitstellt und deinen Zustand wiederherstellt.
- Gentoo
- Portage
- OpenRC
- Fish
- Catalyst
- QEMU
Load Thyself. Deploy Thy System. Recover Thy State.
In Arbeit
FF00 Ark ist ein aktives Produkt in Entwicklung. Diese Seite hält fest, was tatsächlich nachgewiesen wurde. Es gibt jedoch noch kein öffentliches Quellcode-Repository, ISO oder Entwicklungsdownload. Die Implementierung bleibt bis zur vollständigen v1 privat, damit Veröffentlichung, Verpackung und Support unfertiger Zwischenstände nicht zum Ersatz für das Fertigstellen des Betriebssystems werden.
Wenn v1 bereit ist, erscheint der vollständige polierte Quellcode auf Forgejo als kanonischem Repository und auf GitHub als öffentlichem Release-Spiegel. Das Release wird Boot-Image, Prüfsummen, Lizenzen, Dokumentation und den Reproduktionsweg enthalten, den ich von jedem fertigen FF00-Open-Source-Produkt erwarte.
FF00 Ark ist die zweite Generation meiner Idee des Portable Bridge Workspace. Die ursprüngliche Bridge machte einen Wechseldatenträger zur tragbaren Werkbank. Ark stellt die nächste Frage: Was wäre, wenn ein solches Gerät auf einer verfügbaren x86-64-Maschine zusätzlich seine eigene bekannte Umgebung booten könnte?
Das geplante Ergebnis ist ein Gentoo-basiertes Recovery- und Betriebssystem im
RAM. Es soll nützlich bleiben, wenn das installierte Betriebssystem defekt,
nicht vorhanden oder schlicht nicht meines ist. Auf der Konsole will ich Fish,
tmux, Reparaturwerkzeuge, Netzwerk, Dokumentation und geführte Chroot-Helfer.
Wenn die Grafik funktioniert, soll startx meine vertraute Xorg- und
i3-Werkbank für Browser, VS Code, Codex und normale Kommunikation öffnen.
Ark ist kein automatischer Lösch-und-neu-installieren-Apparat. Es ist ein überprüfbares Multi-Tool, das dem Operator eine fähige Umgebung bereitstellt und destruktive Entscheidungen explizit hält.
Warum Gentoo
Der erste Gedanke war Arch, weil Recovery-Werkzeuge dort leicht verfügbar sind. Das war kein ausreichender architektonischer Grund. Die weitere Arbeit am FF00-Betriebssystem läuft bereits auf Portage, explizite Policy und OpenRC zu. Gentoo liefert die nötigen Stellschrauben für ungewöhnliche Recovery-Jobs und erlaubt Ark-Releases trotzdem, Binärpakete zu verwenden, statt auf einer Notfallmaschine zu kompilieren.
Die Portage-Policy ist deshalb Teil des Produkts. Ark definiert geprüfte
Paketsets wie @ark-core, zeichnet USE- und Lizenzentscheidungen auf, bewahrt
den exakt akzeptierten Binärabschluss und behandelt einen beweglichen Binhost
nicht als reproduzierbare Eingabe.
Was heute existiert
Das ist nicht mehr nur ein Architekturdokument. Der private Arbeitsstand hat:
- authentifizierte, zeitgestempelte Gentoo-Stage- und Kontrollmedien-Eingaben;
- gepinnte Gentoo-, Catalyst- und Release-Engineering-Revisionen;
- eine saubere Ark-Core-Root mit 309 Paketen, offline reproduziert;
- native GPKG-Signaturprüfungen und einen nachgewiesenen Ablehnungspfad bei fehlendem Schlüssel;
- einen bewahrten und gehashten Paketpool statt eines unbegrenzten Live-Binhost;
- Prüfungen auf geheime Schlüssel, Build-Caches und Labor-Konfiguration;
- ein softwareemuliertes QEMU- und UEFI-Boot-Labor;
- eine eingeschränkte Catalyst-Mount-Umgebung ohne sichtbares Blockgerät;
- Architektur, Entscheidungen, Status, Build-Journal sowie Workflows für Menschen und LLMs.
Die saubere Core-Root misst derzeit 3’073’874’563 Bytes vor der endgültigen Kompression des Live-Images. Das sortierte Inventar installierter Pakete ist als Hash aufgezeichnet und wird automatisch geprüft.
Was noch nicht existiert
Heute gibt es kein FF00-Ark-ISO. Copy-to-RAM-Boot, Fish-Konsolenpräsentation,
der Benutzer bridge, Recovery-Suiten, geführte Chroots, Xorg/i3, die
Image-Bibliothek, Linux-zu-Ark über kexec und Selbstreplikation durch Ark
Media bleiben Meilensteine.
Diese Unterscheidung ist wichtig. Die Arbeit ist real, ein internes Build-Labor ist aber noch kein Produkt-Release.
Das spätere Gerät
Das öffentliche Betriebssystem und das private Bridge-Profil sind getrennte Schichten. Das öffentliche Ark-Image soll von allen sicher heruntergeladen, geprüft, kopiert und angepasst werden können. Mein privates Gerät darf zusätzlich verschlüsselte Arbeits- und Infrastrukturmaterialien tragen. Diese Zugangsdaten sind aber weder in Ark eingebettet noch Teil seines öffentlichen Recovery-Versprechens.
Dasselbe Gerät soll später bereitstellen:
- Ark selbst als primäre Werkbank im RAM;
- eine getestete Image-Bibliothek für ausgewählte Installations- und Recovery-Medien;
- einen verifizierten Weg, Ark auf einen anderen Datenträger zu kopieren;
- einen privaten, separat geschützten Bridge-Arbeitsbereich;
- eine direkte
kexec-Übergabe aus einem kompatiblen laufenden Linux-System, wenn Policy und Hardware dies erlauben.
Release-Grenze
Absichtlich gibt es noch nichts herunterzuladen. Entwicklungs-Snapshots werden nicht stückweise hochgeladen. Der erste öffentliche Code soll der vollständige v1-Quellcode neben einem nutzbaren, verifizierten Release sein—kein Repository, das Besucher auffordert, das Versprechen selbst zusammenzubauen.
Forgejo wird mit v1 zum kanonischen Entwicklungs- und Quell-Repository. GitHub wird der polierte öffentliche Spiegel für Auffindbarkeit, getaggten Quellcode, Prüfsummen und Release-Downloads. Ark ist weiterhin für eine Veröffentlichung unter AGPL-3.0-or-later vorgesehen.
Nächste Schranke
Der nächste Schritt ist absichtlich upstream und langweilig: das gepinnte Catalyst 4.1.1 im eingeschränkten Labor installieren, Gentoos unveränderte zweistufige Minimalmedien-Spezifikationen validieren, diese Kontrolle zweimal bauen und alle Unterschiede erklären, bevor Ark-Anpassungen beginnen.
So soll dieses Projekt durchgehend vorgehen: Plan zeigen, Entscheidung anwenden, Ergebnis aufzeichnen und einen Weg zurück behalten.