Schlagwort: immutable


  • Unveränderliche Pinguine

    Einsortiert in:
    Unveränderliche Pinguine

    Die GNU/Linux-Welt scheint gerade im kommerziellen Umfeld vor einem großen Wandel zu stehen. Distributionen wie Fedora, openSUSE und neuerdings auch Ubuntu machen seit einiger Zeit anstalten, ihr Distributionsmodell vollkommen umzukrempeln: Anstelle traditioneller Software-Pakete sollen in Zukunft verstärkt Container-Technologien wie Flatpak oder Snap zum Einsatz kommen. Diese werden dann in der Regel auf ein unveränderliches Basissystem aufgesetzt, welches von „normalen“ Nutzern nur über Umwege umfassend angepasst werden kann. Mit dieser Umstrukturierung sollen die Distributionen sicherer und gegebenenfalls auch weniger wartungsintensiv werden. So lassen sich Distributionen, die unveränderlich, dass heißt „immutable“, werden wollen, zusammenfassen. In der Gemeinschaft rund um das freie Betriebssystem mit Pinguin gibt es seit einigen Monaten wohl kaum ein Thema, welches mehr diskutiert wird. Die unveränderlichen Systeme stellen eine radikale Änderung gegenüber dem Betriebssystem-Aufbau dar, den Linux-Nutzer in der Vergangenheit gewohnt waren.

    Wer in den letzten Monaten die einschlägigen Nachrichtenportale rund um freie Software verfolgt hat, wird wohl auch festgestellt haben, dass das Thema immer häufiger aufkommt. Spätestens seitdem klar geworden ist, dass auch Ubuntu-Distributor Canonical für die Version 24.04 eine unveränderliche Variante plant, kommt man um das Thema eigentlich nicht mehr herum. Auch ich interessiere mich für diese neuen Entwicklungen und habe selbst bereits unveränderliche Systeme ausprobiert. Konkret waren das bisher Fedora Silverblue und openSUSE MicroOS Desktop („Aeon“). Bisher habe ich oftmals den Standpunkt vertreten, dass Nutzer, die den „Immutables“ kritisch gegenüberstehen, selbst einmal einen Blick darauf werfen sollten. Auch wenn das Konzept ersteinmal befremdlich oder kompliziert klingen mag, bieten diese Systeme für die alltägliche Nutzung sicherlich einen Großteil dessen, was sich die meisten Anwender wünschen würden. Das Potential in diesem Distributionsansatz ist durchaus gegeben. Wie genau unveränderliche Systeme aber in einer bestimmten Situation sinnvoll wären – darüber lässt sich sicherlich streiten.

    Ich kann auch Anwender verstehen, die sich noch unwohl mit dem momentanen Trend fühlen – und auch ich selbst plane nicht, in Zukunft mit immutablen Distributionen zu arbeiten. Das liegt bei mir aber nicht daran, dass ich neuen Entwicklungen im Linux-Umfeld grundsätzlich kritisch gegenüberstehen würde. Wie bereits erwähnt bin ich bei meinen bisherigen Tests eigentlich gut mit Silverblue und Aeon klargekommen. Doch hier und da ist mir doch aufgefallen, warum derartige Systeme nicht immer mit offenen Armen begrüßt werden. Distributionen, die vermehrt auf Containertechnologien setzen, gehen auch davon aus, auf halbwegs moderner Hardware genutzt zu werden. So können der Arbeitsspeicher-, vor allem aber der Bedarf an Plattenplatz deutlich über bisher gewohnten Systemanforderungen liegen. Und dann ist es schon nachvollziehbar, wenn Anwender abwägen, ob die Vorteile eines solchen Systems wirklich überwiegen.

    Hinzu kommt, dass die Ziele der immutablen Distros teils noch unbeantwortet in der Luft stehen. Es ist zum Beispiel als wären erst die immutablen Systeme ein sicherer oder wartungsarmer Weg, eine GNU/Linux-Distribution zu nutzen. Im Gegenteil ist das bei Distributionen wie Debian GNU/Linux meiner Ansicht nach ein jahrelang erfüllter Standard geworden. Auch ohne Flatpaks, Snaps oder OSTree sind GNU/Linux-Systeme heute nutzbar, anwenderfreundlich und sicher. Die Frage, ob es immutable Systeme also wirklich auf dem heimischen Rechner braucht, ist durchaus berechtigt. Selbst wenn ein paar Vorteile dafür sprechen sollten, müssen wir doch noch den frühen Entwicklungsstand einiger unveränderlicher Desktop-Distributionen im Hinterkopf behalten.

    Ich plane, mit Debian 12 welches in einer Woche erscheinen wird, wieder auf meine Lieblingsdistribution zu wechseln. In absehbarer Zeit wird sich Debian wohl nicht in eine unveränderliche Richtung entwickeln. Und so sehr mich Fedora und openSUSE mit ihren immutablen Distributionen bereits beeindrucken konnten, sehe ich die absehbare Zukunft Debians als veränderliches System als Vorteil. In einem vorangegangenen Blogartikel habe ich schon einmal beschrieben, wie sehr mich Debian als Distribution und auch Projekt abholt. Ich sehe auch für mich nicht das Maß an Vorteilen in den immutablen Distributionen, die es bräuchte, damit ich sie gegenüber Debian in Betracht ziehe. Dennoch bin ich gespannt, wohin sich Distributionen, die in Zukunft wohl unveränderlich sein werden, entwickeln. Wie steht ihr zu diesem Thema?


  • MicroOS und der Plattenplatz

    Einsortiert in:

    Immutable Distributionen gelten nicht gerade als genügsam, wenn es um den Plattenplatz geht: Containertechnologien wie Flatpak können nur dann eine wirkliche Isolierung erbringen, wenn alle notwendigen Abhängigkeiten einer Anwendung auch im Container stecken – und wer mehrere Container-Anwendungen installiert, muss auch damit rechnen, dass gewisse Runtimes und Bibliotheken zumindest teilweise redundant installiert werden.

    Ähnlich hungrig scheint auch die „Distrobox“ zu sein, über die ich im letzten Blogeintrag berichtet habe. Als ich MicroOS installiert habe, hat mir YaST bei der Installation einen initialen Plattenplatzbedarf von 2,6 GB attestiert (wenn ich mich richtig erinnere). Da ging es logischer Weise nur um das Kernsystem – ohne Flatpaks. Was das angeht, kann man im Vergleich zu anderen Distributionen und insbesondere den bisher geläufigen Ausgaben von openSUSE von einer reduzierten Größe des Basis-Systems sprechen.

    Nachdem ich meine GUI-Anwendungen über Flatpak installiert hatte – momentan komme ich auf 45 Flatpaks – habe ich erneut den benötigten Plattenplatz gemessen: Da wollte MicroOS dann schon 15 GB Plattenplatz. Übrigens: Die btrfs-Snapshots fallen tatsächlich nicht sonderlich stark ins Gewicht, da diese immer nur die Veränderungen zum jeweils vorher erstellten Schnappschuss beinhalten. Ich vermute außerdem, dass die Pakete, die ich über transactional-update in das Basis-System eingebunden habe (vor allem CLI-Anwendungen für Systeminformationen und die Gnome-Hintergrundbilder), sonderlich viel Plattenplatz wegnehmen, da ich mich damit wirklich zurückgehalten habe.

    Einen größeren Anteil scheint da die genannte Tumbleweed-Distrobox auszumachen. Ich habe aus Interesse noch einmal gemessen: Jetzt liegt der belegte Platz auf der Platte schon bei 35 GB. Die Snapshots machen momentan nur etwa einen halben Gigabyte aus. Hier zeigt sich also: Die Distrobox muss schon ein bisschen Platz zur Verfügung haben. Interessant finde ich das vor allem, weil ich darin ebenfalls nur sehr sparsam ein paar CLI-Programme installiert habe. Und falls jemand fragt: Meine persönlichen Dateien sollten wirklich nur einen Bruchteil des Gesamtwerts ausmachen, da ich den Großteil dieser noch nicht in das neue System kopiert habe.

    Insgesamt ist es natürlich berechtigt zu hinterfragen, ob diese Werte für MicroOS im Allgemeinen sprechen können, da sie doch von meiner persönlichen Nutzung abhängen. Außerdem kann man natürlich argumentieren, dass immutable Distributionen darauf bauen, ausreichend Speicherplatz zur Verfügung zu haben. Für MicroOS werden beispielsweise 20 GB für die Root-Partition und 40 GB für die /var-Partition empfohlen. Dahingehend sollte ich mit meiner 256 GB-SSD eigentlich keine Probleme haben. Allerdings heißt es in Diskussionen zu immutablen Distributionen immer wieder, dass derartige Systeme sehr „aufgebläht“ seien. Meiner Ansicht nach muss das jeder anhand seiner eigenen Nutzungsgewohnheiten und tatsächlicher Praxiswerten abstecken – daher auch dieser Blogeintrag.

    Abschließend nur so viel: Die hier beschriebenen Zahlen liegen teils deutlich über denen, die meine Installationen von klassischen Distributionen bisher vorgewiesen haben, als astronomisch hoch würde ich diese trotzdem nicht bezeichnen. Und dass ich in naher Zukunft Speicherplatz sparen müsste, halte ich bei MicroOS auch für sehr unwahrscheinlich. 🙂


  • Distroboxen in MicroOS

    Einsortiert in:

    Als ich meine Ersteindrücke bezüglich MicroOS dargelegt habe, bin ich auch darauf eingegangen, dass Software bei immutablen Distributionen primär über Container installiert wird oder installiert werden soll. Während für grafische Anwendungen vor allem Flatpak geeignet ist, ist „Distrobox“ meist die erste Wahl, wenn es um Konsolen-basierte Anwendungen geht.

    Ich habe gerade ein bisschen mit der Distrobox herumgespielt. Um eine neue Distrobox anzulegen, habe ich zunächst folgenden Befehl im Terminal ausgeführt:

    distrobox enter

    Entsprechend der Standardeinstellungen wurde dann ein Tumbleweed-Container (mit den nötigsten Paketen) zusammengestellt und im Anschluss betreten. In diesem Container läuft dann also ein openSUSE Tumbleweed, in dem sich zum Beispiel der Paketmanager „zypper“ wie gewohnt verwenden lässt. So kann man dann zum Beispiel den „Midnight Commander“ installieren:

    sudo zypper install mc

    Dieser ist dann nur im Tumbleweed-Container verfügbar, kann also auch nur dort ausgeführt werden. Interessanter Weise legt MicroOS dann auch gleich einen Desktop-Starter für den Container an. Darüber kann dann ein Terminalfenster gestartet werden, in dem die Distrobox schon betreten wurde. So spart man sich also die Zeile, mit der man die bereits erstellte Standard-Distrobox betreten kann:

    distrobox enter

    Insgesamt macht die Integration von Distrobox auf mich als Neueinsteiger einen stimmigen Eindruck. Mit der erhöhten Sicherheit des Systems geht eben teilweise auch ein kleiner Kompromiss in Sachen Komfort einher. Der angelegte Starter ergänzt hier also gut. Ob das jetzt ein Verdienst von MicroOS oder Distrobox ist, weiß ich (noch) nicht.

    Fakt ist aber auch, dass sich durch den immutablen Ansatz eine verstärkte Komplexität in der Software- bzw. Paket-Verwaltung ergibt: Wo bei anderen Distributionen der hauseigene Paketmanager ausreicht (ein gutes Beispiel wäre apt bei Debian) sollte man bei MicroOS eben Flatpak für die GUI, Distrobox für die CLI und transactional-update für sonstige Systempakete verwenden. Umso sinnvoller finde ich es daher, so viel wie möglich zu automatisieren – das ist ja ein Stück weit auch der Grundgedanke hinter MicroOS.

    So viel also erst einmal dazu. 🙂


  • Erste Eindrücke zu openSUSE MicroOS Desktop

    Einsortiert in:

    Gestern Abend habe ich mir openSUSE MicroOS Desktop installiert, mit Gnome, um genau zu sein. MicroOS reiht sich ein in die Familie der immutablen GNU/Linux-Distributionen und ähnelt dahingehend Fedora Silverblue oder auch VanillaOS: Die wichtigen Systemdateien und -verzeichnisse sind für die Nutzer, egal ob root oder nicht, nur lesbar eingehängt und können in der Regel nicht ohne weiteres überschrieben oder verändert werden. Stattdessen arbeiten „unveränderliche“ Distributionen primär mit Containerformaten, die Anwendungen auf der Nutzerebene zur Verfügung stellen sollen. Für grafische Anwendungen nutzt man bei MicroOS also in erster Linie Flatpaks aus dem Flathub. Anwendungen für die CLI lassen sich in virtualisierten bzw. containerisierten Umgebungen installieren, also zum Beispiel in einer Distro- oder Toolbox. Soll eine Anwendung persistenter Teil des unveränderlichen Betriebssystems werden, kann es in einen Snapshot eingebunden werden, über ein transaktionales Update. Nach einem Neustart kann dann der Computer mit diesem neuen Betriebssystem-Abbild gestartet werden.

    Mit dieser Vorgehensweise bieten immutable Distributionen einen großen Sicherheits- und Stabilitätsvorteil, können aber trotzdem sehr aktuell sein: Die kleinen Abbilder des unterliegenden Betriebssystems sind für Distributoren leichter zu warten, da sie überschaubarer sind als herkömmliche Distributionen. Für Nutzer wird das Software-Angebot auf die Container-Lösungen zusammengefasst, wobei allgemeine Paketquellen wie das Flathub eine sinnvolle Vereinfachung darstellen. Insgesamt bieten immutable Distributionen maßgebliche Vorteile für Desktop-Anwender. Diese werden aber nicht unbedingt auf den ersten Blick ersichtlich. Wer sich zum Beispiel die Diskussionen auf den einschlägen FLOSS-Portalen zu diesem Thema anschaut, wird schnell eine gewisse Skepsis feststellen können, die nicht immer begründet ist.

    Auch ich war lange Zeit skeptisch, ob immutable Distributionen wirklich die Zukunft für GNU/Linux darstellen sollten. Doch nachdem ich bereits Silverblue und mittlerweile auch MicroOS ausprobiert habe, kann ich beruhigt sagen: Das Potential, was viele dem immutablen Distributionsansatz zusprechen, ist in jedem Fall gegeben. Meiner Ansicht nach sollte sich jeder ein eigenes Bild von den Immutables machen – besten Falls auf dedizierter Hardware. Sicher, die Entwicklungen in diese Richtung steckt momentan noch in den Kinderschuhen. Nutzbar ist sie aber im Desktop-Bereich insbesondere mit Gnome schon heute. Wer sich also unsicher ist, dem steht eigentlich nichts im Weg, sich selbst ein Bild zu machen.

    Je nach Distribution unterscheiden sich aber auch die unveränderlichen GNU/Linux-Betriebssysteme, vor allem auf technischer Ebene: Fedora Silverblue baut auf dem Veröffentlichungs-Zyklus der Fedora-Hauptdistributionen auf, erscheint also alle sechs Monate. Diese statischen Veröffentlichungen werden dann genau so lang, wie die Fedora-Hauptdistributionen unterstützt. Sobald eine neue Silverblue-Version zur Verfügung steht, sollten Nutzer ein sogenanntes „Rebase“ vornehmen. Dabei wird das unterliegende Betriebssystem auf die neue Version angehoben. Hier fällt also auf: Wer Silverblue nutzt, ist daran gebunden, entsprechend des Support-Zeitraums Aktualisierungen vorzunehmen; Anwendungs-Updates kommen dabei noch oben drauf. Ein weiterer Unterschied zu MicroOS liegt darin, das Silverblue auf rpm-ostree als Layer-Technologie, also für die Erstellung der Betriebssystem-Abbilder setzt.

    openSUSE geht mit MicroOS einen etwas anderen Weg und setzt darauf, so viel wie nur möglich zu automatisieren: MicroOS basiert auf dem rollenden Tumbleweed-Zeig der Distribution, kann also fortlaufend aktualisiert werden. Hier sind keine zyklischen Versionssprünge nötig. Dabei versucht MicroOS entsprechend des Namens das Basis-Abbild so klein wie irgend möglich zu halten, „Micro“ eben. MicroOS aktualisiert sich stets von selbst und legt bei jeder Aktualisierung einen btrfs-Snapshot als neues Abbild an. Sollte beim Boot-Vorgang dann etwas schief laufen, fällt MicroOS automatisch auf den letzten funktionierenden Snapshot zurück. MicroOS ist also fortlaufend auf dem neuesten Stand der Software- und System-Entwicklung, aber trotzdem sehr gut abgesichert.

    MicroOS als rollende immutable Distribution löst damit das größte Problem rollender Distributionen: Wer openSUSE Tumbleweed, Arch Linux oder Debian Sid nutzen möchte, der muss manchmal gewisse Kompromisse hinnehmen, wenn es um die Stabilität oder Verlässlichkeit der jeweiligen Distribution angeht. Wer nun aber auf MicroOS setzt, der muss sich „keine Sorgen“ um sein System machen – zumindest wenn es nach den Entwicklern der Distribution geht. Man merkt mir vielleicht an: Ich bin ziemlich angetan von diesem System. Theoretisch könnte ich es jetzt einfach vergessen – denn es aktualisiert sich ja fortlaufend selbst, so weit ich weiß gilt das auch für Flatpaks. 🙂

    Dem entsprechend bin ich gespannt, wie sich openSUSE in Zukunft als immutable Distribution weiterentwickelt.