Nichts besitzen, was man erben kann.
smaragd ist eine Schicht, kein Fork. Die Basis wird nie neu gebaut, nie gepatcht, nie ersetzt. Eigene Software entsteht nur dort, wo ein Nutzer den Unterschied merkt. Alles hier beschreibt den umgesetzten Stand vom September 2026 — was geplant, aber nicht gebaut ist, steht auf der Vision.
Vier Schichten, eine Frage
Wo die Grenze verläuft, entscheidet ein einziger Prüfsatz: Würde ein Nutzer merken, dass dieses Teil unverändert von openSUSE kommt? Wenn nein: erben. Wenn ja: selbst bauen.
Warum die Schicht dünn ist
Jedes eigene Paket ist ein Abonnement: CVE-Wache, Neubau, ein E2E-Szenario, ein Handbuchkapitel, zwei Sprachen — für immer. Und jedes eigene Paket baut gegen die Bibliotheken der Basis. Je mehr wir besitzen, desto teurer wird ein Basiswechsel, nicht billiger. Flexibilität entsteht durch wenig Code an der Grenze.
Die Zerfallsregel
Fällt smaragd weg, bleibt ein funktionierendes openSUSE zurück. Kein Paket von smaragd darf so tief sitzen, dass sein Ausbleiben das System bricht. Die Basis-Repositories bleiben aktiv, ergänzt statt ersetzt. Und der Rückweg wird bei jedem Release maschinell bewiesen.
Kein einziges signiertes Programm wird angefasst
Was in dieser Kette uns gehört: Konfiguration, Themes, zwei kleine systemd-Dienste. Das ist der einzige Grund, warum Secure Boot überlebt — und warum ein NVIDIA-Treiber nur als signiertes Kernelmodul kommen darf.
- Firmware, UEFI mit Secure BootMisst in PCR 7. Der TPM versiegelt den Festplattenschlüssel nur dagegen — plus eine PIN.Gerät
- shimVon Microsoft signiert, trägt die Vertrauenskette. Wird niemals neu gebaut.signiert
- GRUBDas Programm ist SUSE-signiert und bleibt unberührt. Unser Teil:Theme + Konfiguration
/etc/grub.d/und das Theme — der Rettungsbildschirm (M3) und der Bootzähler (M2). - Kernel und initrdSUSE-signiert. PCR 4, 8, 9 und 11 werden bewusst nicht verwendet: Sie messen Kernel und initrd, und ein automatischer Rückfall würde die Platte nicht mehr entsperren.signiert
- systemdzwei Dienste
system-update.targetspielt Updates ein, ohne Desktop und ohne offene Dateien (M1).smaragd-bootwaechterzählt Starts und setzt zurück, sobald der Anmeldebildschirm steht (M2). - SDDMDas Programm geerbt, das Theme unseres. Immer Urgestein.Theme
- PlasmaGeerbt. Standardwerte ausTheme + Standardwerte
smaragd-defaults-desktop, Farbschemata Kalkstein und Urgestein, Wallpapers, Launcher-Symbol.
Bewiesen, nicht behauptet: Secure Boot mit Negativkontrolle
Am 28. August 2026 startete smaragd 2026.11 Build 7.1 unter QEMU mit einem OVMF, das nur die Microsoft-Schlüssel kennt: shim wurde akzeptiert, das ganze ISO bootete bis zum grafischen Ziel. Dieselbe Firmware wies das SUSE-signierte grub.efi aus demselben ISO ab, wenn es ohne shim geladen wurde — Access Denied — und lehnte zufällige Bytes ab. Ein Test, der aus dem falschen Grund grün ist, ist schlimmer als kein Test, weil man ihm glaubt.
Sechs Mechanismen statt Atomarität
smaragd ist ein klassisches System mit zypper, snapper und RPM — weil ein Werkzeug zum Fehlersuchen nie einen Neustart kosten darf. Die Lücke, die ein atomares System gratis schließt, schließen diese sechs Mechanismen.
M0 Der Werkzeugkasten ist immer schon da gebaut
Eine namentliche Liste von Diagnosewerkzeugen — strace, tcpdump, smartctl, htop, git und einige Dutzend mehr — ist im Abbild garantiert und vom Umfangsbudget ausgenommen. Der Torwächter bricht den Bau, wenn ein Eintrag verschwindet. Wer einen Fehler sucht, findet sein Werkzeug vor. Es gibt nichts nachzuinstallieren, also auch nichts, wofür man neu starten müsste.
M1 Updates werden nicht im laufenden Betrieb eingespielt gebaut, im Prüfstand offen
Etwas Neues installieren geht immer sofort, live, ohne Neustart. Nur das Aktualisieren vorhandener Pakete wartet auf den Neustart, den es ohnehin bräuchte, und läuft dann in einer minimalen Umgebung: kein Desktop, keine laufenden Programme, keine offenen Dateien. Ein Zustand, nie ein halber. Der Browser als Flatpak wartet nicht. smaragd-updater: täglicher Timer, nur am Netzteil, genau eine Polkit-Aktion.
M2 Bootfehler werden erkannt und automatisch zurückgenommen gebaut, im Prüfstand offen
Ein Zähler unter /boot zählt Starts; erreicht das System den Anmeldebildschirm, wird er gelöscht. Zweimal nicht erreicht, und GRUB startet den letzten funktionierenden Snapshot. /home liegt auf einem eigenen Subvolume und wird nie berührt — deshalb darf der Rückfall überhaupt automatisch sein. Gemessen: der Zähler zählt und löscht, jeder Start merkt sich den Rückfall-Snapshot. Noch nicht gemessen: dass GRUB nach zwei Fehlstarts wirklich vorwählt — das ist Szenario 4 im Prüfstand, und bis es läuft, ist das Verhalten am Bootloader eine Behauptung.
M3 Der Rettungsbildschirm statt des GRUB-Menüs ausgeliefert seit 1. September
Statt openSUSE Slowroll, with Linux 6.11.4-1-default (Snapshot #247) steht dort: smaragd starten · Letzten funktionierenden Stand starten · Frühere Stände … · Etwas reparieren. Reine Konfiguration und reines Theme, kein Patch. Der Rettungseintrag erscheint nur, wenn es einen Stand gibt, zu dem man zurück kann.
M4 Anwendungen sind Flatpaks, das System ist RPM Phase 3
Eine Flatpak-Installation im Benutzerbereich fragt nie nach einem Passwort, weil sie keine Systemrechte braucht. Discover bevorzugt Flatpak für Anwendungen; distrobox ist für Werkstattarbeit dabei. Das hält das Umfangsbudget und die Angriffsfläche klein.
M5 Fremdquellen sind eingehegt Phase 2
Alle Quellen, die smaragd anbietet, kommen über die Ergänzungsliste, sind vendor-gepinnt und werden mitgetestet. Fügt jemand von Hand eine Quelle hinzu, gibt es eine einmalige Warnung in normaler Sprache — und einen Eintrag im Verlauf, damit später jemand die Ursache findet.
M6 Zurück zum Standard Phase 5
Die einzige echte Schwäche des klassischen Wegs: Ein System vergisst nie, was man zum Fehlersuchen installiert hat. Die Wiederaufbau-Liste berechnet, worin das Gerät vom Standard abweicht, und bietet es zum Entfernen an — mit einer Begründungsspalte, die sagt, warum wireshark vor drei Monaten dazukam. Nichts wird automatisch entfernt. Entscheiden darf nur der Mensch.
Was auf dem Build Service liegt
Gegen die Basis wird gebaut, aber nur die eigenen Pakete existieren: ein Repository-Pfad statt eines Projekt-Links. Zehn Quellpakete und zwei Abbilder, Stand 10. September 2026.
home:sm0x:smaragd:desktop
smaragd-release · patterns-smaragd · smaragd-branding · smaragd-defaults-desktop · smaragd-agama-product · smaragd-agama-branding · smaragd-bootnames · smaragd-bootwaechter · smaragd-updater · libsmaragd-supplements
Kein Erbe, deshalb billig. Sechs Theme-RPMs aus einer Quelle, per zypper auf jedem Tumbleweed installierbar.
home:sm0x:smaragd:images
Das Live-Abbild aus einer KIWI-Beschreibung und das Installationsmedium als Link auf den Agama-Installer — 39 Zeilen dazu, 5 weg, ein viertes Produktprofil neben openSUSE, Leap und SLE.
Aktuell: Build 8.2 vom 9. September 2026, 890 MB, Prüfsumme und Signatur geprüft.
smaragd:testing · :release · :patched
Das Aggregat dessen, was gebaut ist; das Aggregat, auf das Nutzergeräte zeigen — erst nach grünem Prüfstand und menschlicher Freigabe; und das einzige Projekt mit Link auf die Basis, das leer startet. Jedes Paket darin wäre eine ADR und eine Schuld.
Der Namensraum smaragd: wird vor dem ersten öffentlichen ISO beantragt. Nichts hängt am Namen — Pfade und Vendor-Lock werden aus product.yaml erzeugt.
Eine Paketliste, drei Leser
image/packagelists/{minimal,desktop,toolbox}.list
│
│ packaging/patterns/generate.py
├──→ patterns-smaragd.spec ← was ein Gerät installiert
├──→ image/smaragd.kiwi nennt NUR die Patterns
└──→ der Basiswächter meldet wöchentlich, wenn
ein Paket aus der Basis fälltDie Unantastbaren
Diese Pakete werden niemals neu gebaut, gepatcht oder ersetzt. Der Torwächter bricht den Bau, wenn eines davon in einem smaragd-Projekt auftaucht:
shim grub2-*-efi kernel-* *-kmp-* dracut mkinitrd
glibc gcc-libs systemd dbus
Qt6* KF6* plasma* mozilla-nss openssl* gnutlsZwei Gründe: Signaturkette (oben) und Bauzeit (unten — ein glibc-Neubau zieht tausende Pakete nach sich). Erlaubt bleiben Konfiguration, Themes, ein danebenliegendes Paket, das eine Datei ablegt, und *-branding-smaragd mit Provides und Conflicts.
Jede Einstellung hat genau einen Schreiber
Die wichtigste Tabelle der ganzen Architektur — weil YaST genau daran gestorben ist: Zwei Stellen schreiben dieselbe Datei, und die letzte gewinnt.
| Was | Schreibt | Wohin |
|---|---|---|
| Unsere Standardwerte | das Paket smaragd-defaults-desktop | /etc/xdg/* — gehört uns |
| Desktop-Einstellungen des Nutzers | Plasma, der Nutzer | ~/.config/* — gehört dem Nutzer |
| Aktive Ergänzungen | Ergänzungs-Oberfläche → zypper | Paketzustand, /etc/zypp/repos.d/ |
| Fingerabdrücke | fprintd | /var/lib/fprint/ — nie in einer Sicherung |
| Wiederherstellungsschlüssel | der Nutzer, beim Verschlüsseln | ausgedruckt oder in der Cloud — nie nur auf dem Gerät |
| Passwörter und Schlüssel | Anwendungen | KWallet, per PAM entsperrt |
| Verlauf | smaragd-core | /var/lib/smaragd/history.db |
| Wiederaufbau-Liste | die Sicherung, bei jedem Lauf | mit der Sicherung, wenige Kilobyte — sie ist die Wiederherstellung |
Kein Einstellungsmodul schreibt Systemzustand direkt. Alles läuft über smaragd-core — das ist der Mechanismus gegen das YaST-Problem.
Der Automat baut, die Maschine prüft, der Mensch nimmt ab
Der Product Owner liest keinen Code. Das ist keine Lücke, für die man sich entschuldigt — es ist eine Konstruktionsbedingung. Also verschiebt sich die Prüfung vom Diff auf das Verhalten.
Tor 1–3 und 6: der Torwächter
Bau mit Warnungen als Fehler, Lizenzköpfe, Geheimnis-Scanner, kein literaler Farbwert, kein unantastbares Paket, keine Handänderung in erzeugten Verzeichnissen, Werkzeugkasten vollständig, Kontrast nach WCAG AA. 38 Prüfungen, bei jedem Push, in einem Container, der dem Runner gleicht — seit dem 10. September 2026 auch dort grün.
Tor 4: der Prüfagent
Ein zweiter Lauf, getrennter Kontext, anderer Auftrag: „Finde, was hier schiefgehen kann.“ Er kennt die Begründung des Autors nicht. Am 9. September fand er in einer eigenen Sitzung, dass eine Vorprüfung etwas verlangte, das kein openSUSE erfüllt — und die Suite war grün, weil ihre Attrappe es zurückgab.
Tor 5: der Prüfstand
Sechs Kernszenarien auf einem eigenen Dauerläufer: Secure Boot, Installation mit TPM, Offline-Update, künstlicher Bootfehler mit Rückfall, Flatpak ohne Passwort, smaragd-verlassen. Rauchtest je PR, volle Suite je Merge, Kettentest wöchentlich, Dauerlauf monatlich.
Was der Mensch am Sonntag tut
Eigenschaften lesen — ist die Liste richtig und vollständig? Rechte-Diff ansehen — wird irgendwo mehr erlaubt als vorher? Ampeln ansehen. Prüferbericht lesen. Das ISO selbst benutzen. Abnehmen. Keiner dieser Schritte verlangt Programmierkenntnis, und die beiden, die tatsächlich Fehler finden, sind der erste und der fünfte. Am 1. September 2026 fand er zwei Defekte in zwanzig Minuten, indem er auf ein Bootmenü sah — der gesamte Torwächter hatte sie nicht.
Jedes Nein hat eine Nummer
Jede dieser Entscheidungen steht in einer ADR mit Begründung und Rücknahmebedingung. Ein Einwand, der nur im Gespräch fällt, ist in sechs Monaten weg.
Kein eigener Anmeldedienst
Verknüpfen gegen die eigene Cloud ja, Anmeldedienst sein nein. Die einzige Entscheidung, die sich nicht billig zurücknehmen ließe.
Kein eigenes Konfigurationsprogramm
Die KDE-Systemeinstellungen sind der Ort. YaST, Cockpit und Myrlyn sind nicht im Abbild.
Keine Spins, kein ARM64
Ein ISO, ein Desktop, eine Zusammenstellung. Nur x86_64 — die Geräte, die von Windows 10 fallen, sind ausnahmslos x86_64.
Kein Wiki, keine Telemetrie
Ein Wiki veraltet unabhängig vom Produkt. Und gezählt wird höchstens ein Bit in der Repository-Anfrage, nie ein Profil.
Kein eigener Symbolsatz
Breeze als Grundlage, eigene Symbole nur für das, was es dort nicht gibt.
Kein Virenscanner im Dauerbetrieb auf schwachen Geräten
clamd hält rund 1,4 GB im Speicher. Unter 8 GB RAM ist der Wächter aus — mit einem ehrlichen Satz daneben.
Keine Patches an der Basis
smaragd:patched startet leer. Ein Patch kostet ein E2E-Szenario und eine Konfliktprüfung pro Woche, für immer.
Kein Upload-Dienst für Fehlerberichte
Er würde uns zum Verarbeiter fremder personenbezogener Daten machen. Das Diagnosepaket bleibt auf dem Gerät.