CleanPress

Schlagwort: OSTree

  • Ist das die Zukunft? Fedora Silverblue im Alltagstest

    Ist das die Zukunft? Fedora Silverblue im Alltagstest

    Gestern erschien Fedora 35 offiziell. Während die neuen Features überschaubar sind, nutzte ich die Chance, mit der neuen Version ein Experiment einzugehen: Der Wechsel von der klassischen Workstation-Variante auf Fedora Silverblue. Diese Ausgabe soll laut eigener Vorstellung die Zukunft von Fedora darstellen.

    Silverblue und Kinoite

    Parallel zu Silverblue gibt es seit kurzem auch Kinoite mit dem gleichen Konzept, nur die Desktopumgebung ist dann KDE statt GNOME. Das Konzept wurde auf Linuxnews auch bereits ausführlicher erklärt: Sowohl Silverblue als auch Kinoite gehören zu den unveränderbaren (immutable) Betriebssystemen. Das erklärt sich dadurch, dass ihr Root-Dateisystem nur lesbar ist. Alle Änderungen werden außerhalb des Root-Dateisystems auf einer separaten Ebene gespeichert. Updates werden als komplettes Abbild ausgeliefert und lassen sich somit zurückrollen auf einen vorherigen Stand.

    Für Software-Installationen gibt es drei Wege, der »klassische« Weg über den Paketmanager dnf entfällt dabei allerdings. Stattdessen soll die Anwendungsinstallation bevorzugt über Flatpaks stattfinden. Entwicklerwerkzeuge lassen sich über die »Toolbox« installieren, die Container-basiert ist. Über RPM/OSTree lassen sich aber schließlich auch noch klassische RPMs installieren.

    Warum der Aufwand? Auch die neuen Versionen sollen sich anfühlen und verhalten wie eine normale Distribution, aber zugleich das Betriebssystem stabil und unveränderlich machen durch die strikte Trennung zwischen System und Anwendung. Das erinnert an die mobilen Betriebssysteme. Für die kommende Zeit möchte ich diese Zukunft ausprobieren und von meinen Erfahrungen als »klassischer« Anwender berichten.

    Instalation mit Troubleshooting

    Auch für die Installation soll gelten, dass diese wie bei einer normalem Distribution aussieht und sich so verhält. Dafür wird der klassische Installationsmanager von Fedora genutzt. Allerdings unterscheidet sich die Installation bei mir in einem wesentlichen Punkt: Sie bricht bei mir mit Fehlermeldungen ab. Der Fehler ist auf EFI-Systemen bekannt, wenn weitere Betriebssysteme installiert sind. Workarounds werden angeboten, funktionieren bei mir aber nicht wirklich. Anstelle von allzu umfangreichem Troubleshooting entschließe ich mich daher, Silverblue meine ganze Platte zu geben und mein Dualboot damit aufzulösen.

    Einrichten: Viele Flatpaks

    Silverblue wird sehr spartanisch ausgeliefert, es richtet sich schließlich gegenwärtig noch an erfahrene Nutzer. Auch der Software-Store (GNOME Software) ist zu Beginn noch recht überschaubar ausgestattet. Erstaunlich ist, dass man beim Starten zwar gefragt wird, ob man auch Flathub.org als Software-Quelle hinzufügen möchte, dies aber scheinbar nur für ausgewählte Pakete für Flathub gilt. Das ist wenig transparent, letztlich lässt sich aber auf gewohntem Wege Flathub freischalten.


    Dank Flathub steigt die Auswahl an Software auch spürbar an, bislang vermisse ich keine Anwendung. So wirklich gut gelöst ist die Softwareinstallation über GNOME Software allerdings nicht. Im Gegensatz zu Fedora 34 ist das Programm für mich immerhin praktisch nutzbar, wenngleich sich mir manche Ladevorgänge noch immer nicht erschließen. Außerdem wird etwa der Firefox mit zwei separaten Einträgen in GNOME Software gelistet und mir werden insgesamt drei Installationswege angeboten: Vorinstalliert ist ein RPM, außerdem habe ich die Möglichkeit als Flatpak über Flathub oder als Flatpak über Fedora. Die konkrete Quelle herauszufinden gelingt mal auf den ersten Blick, mal nur in den tieferen Informationen beim Durchklicken. Das ist suboptimal gelöst, vor allem die Tatsache, dass Fedora ein eigenes Flatpak-Repository pflegt, statt in Flathub einzupflegen, läuft der Idee von Flatpaks ein Stückchen zu wider.


    Grundsätzlich sind Flatpaks ein Thema für sich, da gibt es unterschiedliche, aber gleichsam legitime Meinungen. Ich persönlich habe kein Problem mit Flatpaks, nur hätte ich sie gerne aus einer zentralen Quelle, die eine gute Qualitätssicherung hat. Beides ist in meinen Augen im Augenblick nicht gegeben: Weder ist es bislang zentral auf Flathub, noch ist dort besonders transparent, ob dort eine Qualitätssicherung stattfindet. Dem kann man natürlich entgegenhalten, dass dies bei klassischen Dritt-Quellen ebenfalls nicht der Fall ist und auch in den Repositorys oft veraltete Software liegt.


    Die Verwendung der Flatpak-Applikationen funktioniert im Alltag bei mir gut. Ich habe keine Latenzen. Lediglich muss einem bewusst sein, dass Flatpaks gelegentlich Restriktionen haben, beispielsweise wenn man auf Dateien abseits des Home-Verzeichnisses zurückgreifen möchte. Diese Restriktionen wurden allerdings bewusst eingefügt und lassen sich auch umkonfigurieren bei Bedarf.

    Manipulation am System möglich, aber nervig

    Allerdings gibt es auch Pakete, die keine Flatpaks sind. So waren es bei mir die Druckertreiber, Multimedia-Codecs und tlp, da bei mir die neuen Energie-Optionen aus GNOME 41 leider nicht als Alternative reichten. Was sonst alles durch die Kommandozeile fix erledigt ist, funktioniert mit Silverblue so nicht mehr. Immerhin, ist das Paket in Paketquellen hinterlegt, so funktioniert die Installation mittels rpm-ostree install. Danach ist nur noch ein Neustart erforderlich. Die Anzahl an notwendigen Neustarts kann man auch noch erhöhen: Für Multimediacodecs müssen unter Fedora Repositorys freigeschaltet werden, die ebenfalls erst nach einem Neustart funktionieren. Anschließend wird nach der Installation noch einmal ein Neustart durchgeführt.


    Nervig wird es auch, wenn man vom Hersteller ein Paket für beispielsweise Treiber bekommt. Denn dann gilt auch hier: Abhängigkeiten installieren, Neustart, Paket installieren, Neustart.
    Sicherlich, es ist ja eben Sinn und Zweck von Silverblue, Manipulationen am System so stark wie möglich zu reduzieren. Dennoch macht es in meinem Falle die Einrichtung meines Systems erst mal deutlich langwieriger, als wenn ich schnell meine eigene Checkliste abarbeite und mit Copy & Paste altbewährte Befehle nutze.

    Die Zukunft?

    Ist das nun die Zukunft? An Fedora schätze ich eigentlich, dass ich bei jedem Release ein weitestgehend rundes Paket bekomme, welches ich schnell installieren und dann nur noch kurz einrichten muss, wenn es um das Nachrüsten von Codecs, tlp und dem Druckertreiber geht. Dieser Prozess hat jetzt erst mal länger gedauert. Und auch die gesamte Installation wurde durch bekannte Bugs gestört.


    Ist man bei den alltäglichen Aufgaben, so fühlt sich Silverblue an wie jedes andere Linux-System mit GNOME. Da bin ich bislang auf keine Probleme getroffen. Die Ansätze für ein anwenderfreundlicheres Betriebssystem sind klar erkennbar: Alte Linux-Hasen nutzen gerne die Kommandozeile und das auch vollkommen zu Recht. Allerdings wird gerne mal vergessen, dass dies wenig technikaffinen Anwendern schnell zum Verhängnis wird, weil sie bei für manch ein Programm nicht umhinkommen, das Terminal zu nutzen oder bei dem Copy & Paste aus Internetanleitungen sich das System zerschießen. Ein funktionierender Software-Store, der auf Flatpaks zurückgreift und OSTree können diese Probleme lösen. Während für diese Anwender Silverblue noch aus Kinderkrankheiten herauswachsen muss, werden bei mir die kommenden Wochen zeigen, wie praktikabel das System im Alltagseinsatz sein wird und ob ich mit der »Toolbox« etwas anzufangen weiß.

  • Flatpak strebt Version 1.0 an

    Flatpack 1.0
    Quelle: NeONBRAND auf Unsplash

    Das im Umfeld von Fedora und GNOME entwickelte alternative Paketsystem Flatpak strebt die Version Flatpak 1.0 an, die gemeinhin die Reife für den produktiven Einsatz signalisiert. Dazu hat Hauptentwickler Alex Larsson nun Flatpak 0.99.1 als ersten Release-Kandidaten zu 1.0 veröffentlicht. Bis zur Veröffentlichung der stabilen 1.0 sollen nur noch Fehler beseitigt, aber keine neuen Funktionen mehr hinzugefügt werden. In den Archiven der Distributionen befindet sich noch eine ältere stabile Version, meist 0.11.8.

    P2P als Update-Option

    Die neue Version 0.99.1 setzt Ostree 2018.6 voraus, womit P2P als alternative Update-Option für Flatpak standardmäßig aktiv und nicht mehr, wie bisher,  optional ist. Die Befehle install, update und uninstall listen nun zunächst alle auszuführenden Operationen auf, bevor sie die Erlaubnis zum Start abfragen. Durch weniger fsync-Aufrufe sollen systemweite Installationen schneller als bisher ablaufen.

    Für Anwender und Entwickler

    Flatpak ist neben Ubuntus Snap ein alternatives Paketsystem, das Anwender in die Lage versetzt, mit wenigen Mausklicks aktuelle Software in Versionen zu installieren, die in den Distributionen noch nicht verfügbar ist. Dabei können zusätzlich zu einer per Paketmanagement installierten Version nebeneinander mehrere Versionen der Software installiert werden. Davon profitieren unter anderem auch Entwickler, die mehrere Versionen einer Software testen möchten. Zudem sind die Pakete über die Grenzen von Distributionen hinaus einsetzbar.

    Vor- und Nachteile

    Den neuen Formaten werden aber auch negative Punkte angelastet. So sind die neuen Pakete wesentlich größer als die Anwendung selbst, die sie ausliefern. Das kommt durch die im Paket enthaltenen Bibliotheken und weitere zur Ausführung benötigte Dateien. Diese werden bei mehreren installierten Paketen auch schon mal multipliziert. Bei den heutigen Kapazitäten von Festplatten und fetten Internetleitungen liegt hier das Problem eher in der duplizierten Datenhaltung. Nicht zu vergessen ist dabei die Aktualisierung dieser Pakete mitsamt ihren Abhängigkeiten. Ist eine grundlegende Bibliothek kaputt, muss sie in allen Paketen, in denen sie enthalten ist, aktualisiert werden.

     

  • OpenSUSE Leap 15 steht vor der Tür

     

    openSUSE Leap 15
    Logo: openSUSE | Lizenz: GFDL 1.2

    Am 25. Mai soll openSUSE Leap 15 offiziell freigegeben werden. Die Distribution steht im bereits seit einem Vierteljahrhundert rotierenden SUSE-Produktuniversum in der Mitte zwischen  dem Rolling-Release Tumbleweed und der kommerziellen Ausgabe SUSE Linux Enterprise Server (SLES) und speist sich aus beiden. Im Februar hatte ich bereits auf einen Blick auf einen Snapshot im Betas-Status geworfen. Heute geht es eher um ein herausragendes Merkmal des neuen openSUSE Leap – die transaktionalen Updates.

    Neue Herausforderungen

    In den letzten Jahren trugen die Weiterentwicklung des Linux-Kernels und die Entstehung neuer Paketformate und Container dazu bei, dass sich vielerorts die Art und Weise, wie Software und deren Konglomerierung zu Distributionen aktualisiert wird, veränderte. Im Internet der Dinge (IoT), wo Linux auf eingebetteten Geräten läuft, sind Updates einerseits enorm wichtig, andererseits aber sehr schwierig. Sie müssen zentralisiert und automatisiert durchgeführt und kontrolliert werden. Geht dabei etwas schief, wäre bei herkömmlichen Methoden der Aktualisierung guter Rat teuer.

    Deswegen kommen dort und anderswo sogenannte atomare Updates, auch als transaktionale Updates bezeichnet, zum Einsatz. Dabei wird ein Update gebündelt, nicht ungleich einem Image vollzogen. Geht dabei etwas schief, wird das gesamte Update zurückgerollt und der Zustand vor dem Update wieder hergestellt. So aktualisiert etwa Canonical seine Snaps, die bereits in vielen Geräten des IoT werkeln.

    OSTree

    Auch die Container-Variante von Fedora, Atomic-Workstation, trägt diese Art der Aktualisierung bereits im Namen. Gerade arbeiten die Fedora-Entwickler daran, die Workstation-Ausgabe der Distribution im Rahmen des Projekts Silverblue transaktional zu gestalten. Den Update-Mechanismen liegt die Bibliothek libostree zugrunde, die zusammen mit einigen Kommandozeilentools als OSTree bezeichnet wird. Das Paketformat Flatpak bedient sich dieses Modells ebenso wie die gerade in Version 3.4 erschienene Endless OS. Dazu wurde bei Endless eigens ein  Updater geschrieben.

    Btrfs + Snapper + Zypper

    OpenSuse verfügt durch die Verwendung von Btrfs als Dateisystem und per Snapper kontrollierte Snapshots des Systems bereits seit längerem über ein ähnliches System, allerdings entkoppelt vom Aktualisierungsmechanismus der Distribution. Zu festgelegten Zeiten oder vor einem umfangreichen Update wird mit Snapper ein Snapshot erstellt, der eingespielt wird, falls das Update schiefgeht. Mit openSUSE Leap 15 wird dieses System nun direkt mit den Aktualisierungen verknüpft. Aus dem auf Tumbleweed basierenden Projekt Kubic, das der Entwicklung von Container-Technologien dient, stammt die Entwicklung, die künftig den Anwendern von openSUSE Leap alternativ transaktionale Updates bescheren wird.

    Dabei werden Aktualisierungen entweder in einer einzigen Transaktion oder gar nicht auf das System angewendet. Dies geschieht ohne Beeinflussung des laufenden Systems. Wenn ein Update fehlschlägt oder wenn das erfolgreiche Update als inkompatibel oder anderweitig fehlerhaft angesehen wird, kann es verworfen werden, um das System sofort wieder in seinen vorherigen Betriebszustand zu versetzen.

    Unberührt

    Transaktions-Updates berühren nie direkt das laufende System. Anstatt das aktuelle System zu patchen, erstellt das Transaktions-Update-Tool einen neuen Snapshot. Alle für das Update erforderlichen Operationen werden vorerst nur in diesem Snapshot ausgeführt. Am Ende des Updates wird bei erfolgreicher Aktualisierung ein abgeschlossener Snapshot als neuer Standard markiert. Diese Updates werden dann beim Neustart des Systems wirksam. Wenn die Aktualisierung nicht erfolgreich war, wird der Snapshot verworfen und keine Änderung am System vorgenommen.

    Wer die neue Technik bereits jetzt testen möchte, wählt bei der Installation von openSUSE Leap 15 im Tab »User Interface« die Option »Transactional Server«. Das Image der Beta-Version ist rund 3.6 GByte groß. Viel Spaß beim Testen.

  • Flatpak von innen

    Installation per Flatpak-Hub
    Screenshot: FThommes

    Flatpak ist grundsätzlich ein Bündelungssystem, und als solches hat es im Vergleich zu anderen Paketsystemen den Nachteil des prinzipbedingt größeren Umfangs. Nach Meinung von GNOME- und Flatpak-Entwickler Alexander Larsson kompensieren die Vorteile der Bündelung aber die Nachteile. In einem Blogpost erklärt er, was in der Entwicklung gegen das Aufblähen getan wird.

    Maßnahmen gegen Bloat

    Bereits das Grundgerüst der Flatpak-Infrastruktur versucht, Bloat zu vermeiden. Das geschieht durch die Aufteilung in Laufzeitumgebung und Anwendungen. Das bedeutet, dass Anwendungen nicht alles bündeln müssen und dass gemeinsame Abhängigkeiten zwischen verschiedenen Anwendungen geteilt werden.

    Bei der Konzeption von Flatpak war die Eindämmung von Bloat allerdings nicht das Hauptargument für den Einsatz von Laufzeitumgebungen. Dabei ging es vordergründig um Dinge wie Wartung, gemeinsame Eigentümerschaft und darum, Kernfunktionalitäten separat veröffentlichen zu können. Hier stehen  beispielsweise Sicherheitsaktualisierungen im Fokus, die Anwendungsautoren weder beherrschen noch Interesse daran haben.

    OSTree ist mit Git vergleichbar

    Für die Anwendungsspeicherung nutzt Flatpak ein System namens OSTree, welches durch Deduplikation auf Dateiebene bereits eine Doppelung von Daten verhindert. Larsson versucht OSTree zu erklären, wenn er sagt:  »Es ist wie Git, aber für Verzeichnisse mit großen Binärdateien«. Für Flatpak bedeutet das, dass jede Runtime (es können mehrere installiert sein) und jede Anwendung einen Zweig in einem OSTree-Repository darstellen, der einem Git-Branch entspricht. Dabei sind alle Verzeichnisse und Dateien, vereinfacht dargestellt, mit IDs versehen. Alle identischen Dateien werden so erkannt und dabei zwischen den Anwendungen geteilt. Das entlastet nicht nur RAM und Plattenplatz sondern spart Bandbreite beim  Download.

    Effektive Einsparung

    Dass das effektiv funktioniert, zeigt das Beispiel der beiden Laufzeitumgebungen von GNOME und freedesktop.org. Letztere hat eine Größe von 435 MByte, die von GNOME wirft 665 MByte in die Waagschale. Dabei ist die GNOME-Runtime eine Kopie der Runtime von freedesktop.org mit einigen entfernten und einigen hinzugekommenen Dateien.

    Wird die GNOME-Runtime zusätzlich zu der von freedesktop.org installiert, werden lediglich 18 MByte mehr belegt anstatt 230 MByte. Das gleiche gilt für die KDE-Runtime und weitere, unter Umständen auch selbst erstellte Laufzeitumgebungen. Auch die Installation von x86-64- und i386-Builds der GNOME-Laufzeitumgebung spart 220 MByte ein.