openUSE Aeon ist ein Transaktionales System. Das bedeutet, dass vorherige Zustände, z.B vor einem Systemupdate auch später noch zur Verfügung stehen. Zu Grunde liegt hier das Sprichwort „never touch a running system“.

Außerdem bauen Updates auf dem vorherigen Zustand auf. So werden nur Änderungen am installierten Paketen und Dateien gespeichert statt einer vollständigen Kopie. Dies reduziert den Speicherverbrauch für Wiederherstellungspunkte enorm.

Ausnahme bilden hier Anwendungen die vom Nutzer via dem Softwarecenter oder einer Distrobox (dazu später mehr) installiert wurden. Diese werden bei einem Update durch eine neu Version ersetzt. Alte Versionen der Software stehen dann nur zur Verfügung wenn diese explizit angeboten werden. Ein Beispiel wäre hier die Godot Game Engine, diese ist in der neusten Version und in der Version 3 verfügbar.

openSUSE Aeon wendet System update „atomar“ an. Das bedeutet dass, dass das Updates entweder ganz oder gar nicht angewendet werden.

In anderen Worten: sollte bei der Installation eines Updates ein Fehler auftreten, egal wie gravierend dieser ist wird das Update verworfen und zu einem späteren Zeitpunkt erneut versucht.

Ein Klassisches Szenario ist hier z.B. der proprietären nVidia Grafikkarten Treiber. Das Kernelmodul muss bei einem Betriebssystemkern update neu kompiliert werden, damit der Treiber normal mit dem Kern interagieren kann.

Aber auch andere Probleme wie fehlgeschlagene Datei-Integritätsprüfungen können ein Update verhindern. Solche Dateien sollten eh nicht installiert werden.

Ziel dabei ist es das System niemals in einem undefinierten oder teilweise kaputten Zustand zurück zu lassen.

Im Zusammenhang mit Transkationalen und Atomaren Updates behält openSUSE Aeon Systemschnappschüsse vorheriger Versionen immer Bereit.

Sprich, sollte ein Update erfolgreich durchlaufen, aber es zu anderen Problem zur Laufzeit kommen, kann hier manuell oder semi-automatisiert, auf einen Vorherigen Zustand zurück gewechselt werden.

openSUSE Aeon bedient sich zusätzlich dem Konzept des „Verified Boot“, das Prüft, ob das System ordnungsmäßig gestartet wurde. Sollte dies nicht der Fall sein, wird Aeon selbständig auf einen Vorherigen, funktionierende Zustand wechseln.

Es gilt aber zu erwähnen, das nicht alle jemals angelegten Snapshots aufbewahrt werden. Tatsächlich räumt openSUSE Aeon alte Snapshots regelmäßig auf.

So ist z.B immer der Zustand nach der Erstinstallation verfügbar, einige der jüngsten (funktionierenden) Snapshots und welche, die als „important“ markiert sind.

Dank BtrFS sind diese generell recht klein, da nur Änderungen zum vorherigen Schnapsschuss gespeichert werden, statt einer ganzen Kopie eures Systems.

ACHTUNG: Wer ein manuelles Rollback durchführen will benutzt unter openSUSE Aeon (und Kalpa) nicht snapper, sondern:

sudo transactional-update rollback <snapshot-nummer>

Da snapper nicht über die Änderungen im /etc Verzeichnis beschied weiß. Da wie zuvor im Abschnitt „Immutable“ erwähnt es sich heir um ein Overlay file system handelt.

Flatpak: Da wir zuvor erwähnt das Basissystem nicht verändert werden kann müssen Nutzeranwendungen von anderer Quelle bezogen werden. Im Falle von openSUSE Aeon sind dies Flatpkas von Flathub.

Diese werden im Nutzerverzeichnis installiert und sind damit vollständig unabhängig vom Hauptsystem.
Durch die Flatpak Laufzeitumgebungen sind alle über das Softearecenter installierten Anwendungen außerdem in einer Sandbox und haben somit nur limitierten Zugriff auf das Betriebssystem.

Ein weiterer VOrteil ist, dass durch die Laufzeitumgebung auch alle nötigen Bilbiotheken für eine Flatpak Anwendung zur Verfügung stehen, damit diese reibungslos funktionieren.

Das bedeutet, dass wir nicht in unser Hauptsystem Abhängigkeiten installieren müssen, damit Anwendung richtig oder überhaupt funktionieren.

Weiterhin sind die Laufzeitumgebungen immer alle gleich. Sprich eine Anwendung die als Flatpak zur Verfügung steht läuft auf allen Linux Distributionen auf denen flatpak installiert ist.

Für Anwendungen die ihr nicht auf Flathub oder in anderen Flatpak Repositorien finden könnt, bietet openSUSE Aeon (und auch Kalpa) Distrobox an.

Distrobox erlaubt es euch über das in Aeon und Kalpa vorinstallierte podman, andere Linux Distributionen in einem Container aufzuführen.

So könnt ihr z.B. ein Arch Linux laufen lassen um Gebrauch der AUR zu machen, oder ein Ubuntu um diverse PPAs zu verwenden, oder Fedora um von RPM Fusion zu profitieren und vieles mehr.

Auch wenn die Interaktion mit einem Container über die Kommandozeile stattfindet gibt es die Möglichkeit Anwendungen aus einer Distrobox heraus zu exportieren und sie wie native Anwendungen über den Anwendungsstarter auf eurem openSUSE Aeon oder Kalpa auszuführen.

Ein praktisches Grafisches Tool zum anlegen und verwalten von diversen Distrobox Umgebungen ist BoxBuddy.

Achtung: Anwendungen in einer Distrobox laufen nicht in einer Sandbox. Diese haben vollen Zugriff auf eurer System, sowie euer lokale Benutzer.

Neben Anwendungen die es nicht auf Flathub gibt, z.B. Kommandozeilentools, gitb es eine Reihe weiterer Anwendungsmöglichkeiten, mit denen man das maximum aus openSUSE Aeon und Kalpa heraus holen kann.

Proprietäre Anwendungen: Es passiert zwar nicht all zu oft, aber ab und an gibt es proprietäre Anwendungen mit einer nativen Linux version. Nicht selten ist es dann der Fall, dass diese nut bestimmte Linux Distributionen offiziell unterstützen. Hier bietet es sich dann an eine Distrobox mit einer unterstützen Distribution anzulegen und die Anwendung darin zu betreiben.

DaVinci Resolve ist z.B. ein solches Programm. Läuft zwar auch unter anderen Distributionen kann aber beliebig aufwändig werden. Mehr erfahrt ihr in dem extra Artikel.

Oder die Breitbandmessung Desktop App der Bundesnetzagentur unterstützt offiziell nur Ubuntu 18.04 und Debain 12. Tatsächlich prüft diese Anwendung explizit das System und verweigert somit das Ausführen auf anderen Distributionen.

Entwicklungsumgebungen: Für Softwareentwickler ist Distrobox schon fast der heilige Gral. Ob nun explizit um Container entwickelt wird, Kommandozeilentools, Desktop Anwendungen oder Spielentwicklung. Mit einer entsprechend präparierten Distrobox. und einer Distrobox Assemble Datei, kann man sich seine Entwicklungsumgebung in Minuten und vollkommen automatisiert auf jedem beliebigen Rechner aufsetzten.

Gerade da openSUSE Aeon und Kalpa immutbale sind, ist es recht kompliziert Headerdateien für C oder C++ Entwicklung zu installieren. Oder zusätzliche Entwicklungspakete für das ein oder andere rust Crate.

Oder steht eine bestimmte IDE nur offizielle für bestimmte Distributionen zur Verfügung, wie die ROS Toolchain. Dann ist auch eine Distrobox mit Ubuntu hier die Lösung.

Zusätzliche Softwarequellen: Evtl besteht auch Bedarf dafür bestimmte Programme aus den Arch User Repositories zu installieren, aus einem Ubuntu PPA oder von Fedoras RPM Fusion. Auch heir kann eine Arch Linux, Ubuntu oder Fedora Distrobox endlose Möglichkeiten bieten.

Allerdings gibt es eine Limitierung, bei der ihr mit einer Distrobox dem Problem nicht her werdet. Da Distrobox den Linux Kernel von eures openSUSE Aeon bzw Kalpa mit jeder Container Distribution teilt, könnt ihr keinen anderen Kernel in die Distrobox installieren. Manchmal kann es sich dabei um zusätzliche Kernel Module handeln, oder aber um einen Kernel der mit bestimmten Patches oder Features kompiliert wurde. Dass ist mit einer Distrobox nicht möglich.

Hier müsstet ihr dann den Kernel in euren openSUSE Aeon oder Kalpa verändern. Dieser ist dann aber für alle Distroboxen verändert worden.

Im Punkto Gaming steht openSUSE Aeon einer traditionellen Linux Distrubtion in nichts nach.

Alle gängigen Gaming Anwendungen für Linux stehen als Flatpaks zur Verfügung.
Demnach, Steam, Bottles, Heroic Games launcher, Lutris, ProtonUp-Qt, Proton+, ja sogar das gute alte PlayOnLinux und zusätzliche Tools wie Gamescope oder MangoHUD.

Ich müsste aber lügen, wenn ich nicht erwähnen würde, dass dennoch ein minimaler manueller Aufwand notwendig war, bis alles so lief wie es soll.

So musste ich z.B. ein Paket steam-devices, manuell in das Hauptsystem installieren, damit Steam Input meine angeschlossenen Gamepads verwalten konnte. Dies war aber recht simpel mit dem Befehlt:

sudo transactional-update -c pkg install steam-devices

Nach einem System Neustart war dann alles bereit.

Außerdem musste ich die SELinux Konfiguration von openSUSE Aeon noch anpassen, da es hier durch die doch recht restriktiven Standards zu Einschränkungen kam.

Dies zog sich von Abstürzten in nativen Spielen wie Stellaris, bis hin zu Proton und Wine welche nicht in der Lage waren alle Abhängigkeit in ihren Präfixen zu installieren.

sudo setsebool -P selinuxuser_execmod 1
sudo setsebool -P selinuxuser_execstack 1

Danach konnte ich ohne Neustart alles so Spielen wie ich es von openSUSE Tumbleweed gewohnt war.
Für weiter Troubleshootings empfehle ich gerne die offizielle Guide von openSUSE.

Wer Software unter openSUSE Aeon entwickeln wird, wird um Distrobox nicht herum kommen.
Hier für habe ich mit eine dedizierte Distrobox angelegt, mit eigenem Nutzerverzeichnis, in dem ich alle Tools die ich brauche installiert habe.

distrobox-create --name develop --home $HOME/distrobx/develop_home/ --nvidia

Anschließend habe ich hier git, rustup, JetBrains Toolbox und diverse Development Header installiert.

Da die Distrobox eine vollwertige Linux Umgebung bereitstellt verlief danach alles wie gewohnt.

Damit allerdings JetBrains Tool vernünftig liefen musste ich in der Distrobox noch ein paar Abhängigkeiten nach installieren:

sudo zypper in fuse libfuse2 libgthread-2_0-0

Mit distrobox-export habe können dann die Anwendungen in das Host System exportiert werden:

distrobox-export -b /usr/bin/git
distrobox-export -a intellij
distrobox-export -a pycharm
distrobox-export -a webstorm
distrobox-export -a jetbrains-toolbox
distrobox-export -a rustrover
distrobox-export -a code

So hatte ich dann meine gewohnte Entwicklungsumgebung auch auf openSUSE Aeon verfügbar.

Mit dem Bonus, dass ich mein Hauptsystem und mein Nutzerverzechnis nicht mit unnötigen Dateien und Abhängigkeiten vollstopfen musste. Außerdem besteht nicht mehr die Gefahr durch neue Entwicklungspakete oder diversen Experimente das Hauptsystem zu zerschießen. Sollte die Distrobox irreversibel kaputt sein, legt man sie eben neu an.

Auch im Punkto Content Creation steht openSUSE Aeon einer klassischen Distribution in nichts nach.
Blender, OBS Studio, Kdenlive, Shotcut, Gimp, Krita, Inkscape und vieles mehr stehen als Flatpaks zur Verfügung und können einfach installiert und benutzt werden.

Lediglich wer DaVinci Resolve verwenden will wird auch hier um eine Rocky Linux 8 Distrobox nicht herumkommen. Hierzu habe ich einen eigenen Artikel verfasst, den ihr hier lesen könnt.

Zugegeben, der Begriff Audioproduktion wird eher selten mit Linux assoziiert, aber es ist dennoch möglich. Tools wie Ardour, LMMS, Audacity, coppwr, qpwgraph und Carla existieren als Flatpaks und machen genau das was sie sollen.

Da openSUSE Aeon auch mit Pipewire daher kommt, ist für Musikproduzenten und Low latency Enthusiasten alles dabei was man brauchen könnte.

Mit Ausnahme natürlich der großen Tools wie Apples Logic oder Pro Tools. Dass ist eher ein generelles Linux Problem als etwas was unter openSUSE Aeon nicht möglich wäre.

Aber auch hier, steht Aeon, traditionellen Distributionen in nichts nach.
Sofern Audioproduktion für euch unter Linux bereits Thema ist, werdet ihr auch mit openSUSE Aeon hier zufrieden sein.

Als jemand der einen Studiengang im Bereich der Medienproduktion besucht hat, bin ich auf jeden Fall gut zurecht gekommen und jede Abgabe war ein voller Erfolg. Ohne Windows oder MacOS.

Büroanwendungen, wie Libre Office, PDFs lesen, bearbeiten, neu Arrangieren, Scannen, Drucken, E-Mails oder Webbrowsing ist auch kein Problem.

Persönlich würde ich sogar sagen, verglichen mit openSUSE Tumbleweed oder Leap, sogar simpler, da die Konfiguration über YaST weg fällt, die ab und an etwas umständlich sein kann wenn es um Netzwerkdrucker geht.

Hier funktioniert alles out-of-the-box, Drucker und Scanner-software sind als Flatpaks vorhanden und erkennen Netzwerk, sowie USB Drucker direkt.

Auch das Verknüpfen mit Online Accounts, wie Nextcloud, oder Google funktionieren tadellos dank Gnomes integrierter Online-Accounts Feature.

Im Punkto Spieleentwicklung hängt es stark davon ab welche Engine ihr Benutzen wollt.

Wer mit Godot arbeitet kann sie sowohl Godot 4 als auch Godot 3 direkt von Flathub ziehen und so weiter machen wie gewohnt.

Wer Unity oder die Unreal Engine verwenden will, kann dies auch über Unity Hub oder dem Epic Asset Manager tun.
Beide sind auf flathub verfügbar. Allerdings unterstützt Unity kein Flatpak und es kann zu unerwarteten Problem kommen.

Außerdem werden sowohl für Unity als auch für die Unreal Engine externe IDEs benötigt um C# oder C++ Code zu schreiben. Daher würde sich auf lange Sicht hier eine Distobox empfehlen.

Wer openSUSE Kalpa verwendet wird evtl schnell feststellen, dass die Plasma X11 Sitzung nicht aufgeführt ist. Diese ist standardmäßig bei Kalpa nicht mehr installiert.

Wer X11 nutzen möchte muss hier lediglich das Paket plasma6-session-x11 installieren und nach dem nächsten Neustart sollte die X11 Sitzung im Anmeldebildschirm angeboten werden.

sudo transactional-update -c pkg install plasma6-session-x11

Eine der Häufigsten, im Kern nicht falsche, Kritik an Flatpaks und damit an Distrobox Containern ist der Speicherverbraucht.

So bringt z.B. Flatpak seine eigenen Laufzeitumgebungen in verschiedenen Versionen mit, diese werden automatisch mit installiert sobald eine Anwendung diese benötigt. Werden aber auch wieder entfernt, sobald keine Anwendungen mehr installiert ist, die von dieser Abhängig ist. Zum Zeitpunkt dieses Artikels belegen bei mir alleine die Flatpak Runtimes 16,8 GB, bei 210 installierten flatpak Anwendungen.

Verschärft wird diese Kritik dadurch, dass flapaks of pro Nutzer installiert werden.
Sprich auf einem System, das mehrere Personen benutzen, mit eigenen Benutzerkonten, eigenen Apps etc. wird jeder Nutzer eben diese Runtimes ebenfalls installiert haben.

Ähnliches gilt natürlich auch für Distrobox Container. Hier ist der Container die Laufzeitumgebung, mit seinen eigenen Bibliotheken und Anwendungen. Dadurch entsteht natürlich eine gewisse Redundanz.

Tatsächlich ist dieser Overhead dank BtrFS unter openSUSE Aeon und Kalpa aber minimal. Da es sich bei BtrFS um ein Copy-On-Write Dateisystem handelt werden nur Änderungen an Dateien gespeichert, satt ganze Kopien. Da auf Blockebene des Dateisystems nach identischen Blöcken gesucht wird, werden diese nur einmal physikalisch auf euren Speichermedien abgelegt.

Gibt es nun eine leicht veränderte Version dieser Datei werden nur die unterscheide zum „original“ gesichert, statt einer Kopie. Außerdem sind mehrfach vorhandene Dateien, wie z.B. die einzelnen Runtimes für einzelne Benutzer tatsächlich nur einmal auf eure Festplatten oder SSDs vorhanden.

Von diesem Konzept profitieren auch die System snapshots sowie unsere Distrobox Containern.

Ändert ihr natürlich in Eigenverantwortung das Dateisystem eures Nutzerverzeichnisses zu ext4 oder einem anderen Dateisystem ohne COW (copy-on-write), verfällt dieser Bonus gänzlich.

Alles in allem betrachte ich dies daher als vernachlässigbar kleines Problem.

Außerdem kommen viele Desktopsysteme im Schnitt mit 500GB oder gar bis zu 2 TB Speicher daher. Selbst auf einer 64GB SD-Karte auf meinem LCD Steam Deck mit openSUSE Aeon im dual Boot fahre ich sehr platzsparend.

Eine weitere gängige Kritik die man öfter liest sind die ewigen Reboots.

Da das System Aktualisierungen nicht zur Laufzeit angewendet seid ihr dazu angehalten in abständen euer System neu zu starten um von den neusten Updates Gebrauch zu machen. Diese Kritik trifft voll und ganz zu.

Randnotiz: Es gibt den Befehl transactional-update apply, dieser setzt einen für den nächste Startvorgang als zu aktivierenden Systemschanpschuss direkt aktiv.

Allerdings, auch wenn dies generell unter Linux weniger ein Problem darstellt, kann es bei klassischen Distributionen durch Updates zur Laufzeit zu unvorhergesehen Problem kommen. Ein Beispiel, wäre der leidige nVidia Treiber:

Man stelle sich vor, es gab ein Linux Kernel update. Das nVidia Kernelmodul wurde für den neuen Kernel gebaut und man startet danach eine Anwendung die auf eben dieses Kernel Modul angewiesen ist.

Die Wahrscheinlichkeit dass das nach hinten los gehen ist recht hoch. Die Anwendung wird das neue Kernel Modul für den neue Kernel laden, während aber noch der alte Kernel im Betrieb ist, und abstürzten.

Ähnliche Seiteneffekte können auch mit Anwendungen auftreten die noch auf einer älteren Bibliotheksauswahl laufen, diese aber nicht ABI kompatibel mit neueren Bestandteilen sind. Startet man die Anwendung neu, mit neuen Bibliotheken etc, ist alles fein, aber läuft diese noch mit dem alten Bestand kann es auch hier zu unvorhergesehen Problemen kommen.

Worauf ich hinaus will, der Ansatz, never reboot, unter alteingesessenen Linux-Nutzern ist im Kern weniger Sinnvoll und ein Neustart dann und wann bietet sich an.
Allein um Laufende Bibliotheken neu zu laden um Sicherheitslücken zu schließen.

Daher betrachte ich dies als vernachlässigbar kleines Problem. Zudem der Endnutzer trasnactional-update idealerweise nur einmal zur Ersteinrichtung zusätzlicher Treiber und VPN Software benutzt und sonst hoffentlich nie wieder. Die meiste Software kommt als flatpak oder über einen Distrobox Container und diese sind beide nicht von diesem Problem betroffen.

Wer traditionelle Linux Distributionen gewohnt ist, so wie es auch mir ergangen ist, wird sich zunächst unter openSUSE Aeon, und vergleichbaren Distributionen, etwas dumm vorkommen. Da durch die neuen Konzepte einiges and (Um-)Lehrarbeit gefragt ist. Wie man unter der Sektion openSUSE Aeon im täglichen Einsatz ganz gut sehen kann.

Anwendungen laufen als Flatpkas oder in einer Distrobox. Das Sandboxing könnte für den ein oder Anderen ungewohnt sein. So kann es vorkommen, das Anwendungen über Flatpak gewisse Systempfade nicht sehen, weil sie keinen Zugriff darauf haben.
Oder gar der Zugriff auf ganze Geräte könnte fehlen.

Hier empfehle ich euch Flatseal um in einer schönen Oberfläche eben solche Kleinigkeiten zu regulieren.

Weiterhin bedarf es einer gewissen Selbstdisziplin nicht alles via transactional-update zu installieren sondern zunächst den Weg über eine Distrobox zu gehen. Gerade hier spreche ich aus eigener Erfahrung.

Dem ein oder anderen dürfte aufgefallen sein, dass der älteste Snapshot in meinem Snapper Screenshot nicht der 9 November 2022 ist, sondern vom März 2023. Nun könnt ihr euch denken warum.

Wer openSUSE schon lange nutzt wird evtl. auch YaST zunächst vermissen.Zugegebenermaßen, YaST ist ein so nie dagewesenes Systemkonfigurationstools, welches eines der Herzausstellungsmerkmale von openSUSE ist. Wer Jahre lang openSUSE Maschinen verwaltet hat, wird YaST ziemlich sicher lieben gelernt haben.

Dass YaST allerdings nicht vorhanden ist tatsächlich besser so. Dadurch ist man eher daran gehindert das Basissystem zu verändern anstatt den Weg über Distrobox oder Flatpak zu gehen. Auch ein Grund, warum sudo transactional-update -c pkg install ein so ewig langer Befehl ist.

Aber auch wenn diese Lernkurve aus gutem Grund existiert, ist sie dennoch eine (Um-)Lernkurve. Persönlich finde ich die Vorteile dieser neuen Konzepte überwiegen die „Nachteile“ bei weitem. Wobei die meisten Nachteil nicht wirklich welche zu sein scheinen.