Linux auf dem Desktop

Doch stellt sich die Frage, stimmt dass denn. Sind point-releases das bessere Release Model, rolling release Nutzer die Betatester der Linux Community und semi-rolling in keinem von beiden besonders gut ist? Um dies vernünftig beurteilen zu können müssen wir erst verstehen wie die verschiedenen Release Modell genau funktionieren. Aber zuvor möchte ich noch einige Begriffe aus der Softwareentwicklung erläutern die ich hier verwenden werde.

Maintainer: Ein Maintainer ist eine Person oder eine Gruppe von Personen die sich um eine Software, ein Softwarepaket oder um eine ganze Linux Distribution kümmern. Diese weiter entwickeln, verbessern, korrigieren usw.

Upstream: Als Upstream wird in der Softwareentwicklung der Stand einer Software bezeichnet wie er vom original Entwickler stammt. Sprich der Upstream ist die Basis von der alle Linux Distributionen ihren Ursprungscode herbekommen.

Downstream: Ist der Stand einer Software der unabhängig vom Upstream entwickelt wird. Dies sind oft zusätzliche Erweiterungen die Linux Distributionsmaintainer bereit stellen, diese aber nicht im Upstream enthalten sind. Sprich, läd sich jemand anderes den Upstreamcode herunter sind diese Änderungen nicht enthalten. Oft ist das auch nicht notwendig wenn es sich nur um sehr spezifische Änderungen handelt die nur für eine bestimmte Linux Distribution notwendig waren. Manchmal entsteht aber auch ein Patch der dann wieder in den Upstream integriert wird, oft aber eher nicht.

Major, Minor und Patch Versionierung: Software wird durchnummeriert um zu kennzeichnen um welche Version der Software es sich tatsächlich handelt. Hier bei spielt es eine rolle, auf welcher Seite eine Nummer vom Punkt steht und zwar: MAJOR.MINOR.PATCH. Zusätzlich hat dies auch eine tragende Bedeutung.

Major: bedeutet, dass sich zum Vorgänger alles geändert haben kann. Schnittstellen im Code, erwartet Ein- oder Ausgaben. Einfach alles. Oft auch als „Breaking changes“ bezeichnet. Sprich eine Software die mit einer Bibliothek entwickelt wurde in der Version 1.0 kann sich nicht darauf verlassen das 2.0 noch genau so funktioniert. Evtl gibt es neue Funktionen die etwas besser oder ganz anders machen. Evlt. sind Funktionen nicht mehr vorhanden, die der Vorgänger noch hatte. Oder in extrem Fällen wurde vielleicht sogar die ganze Programmiersprache geändert und der gesamte Prozess um aus dem Quelltext das ausführbare Programm zu generieren muss geändert werden.

Minor: Ist weniger kritisch, normalerweise wird hier nichts entfernt, höchstens etwas hinzugefügt. Evtl. als Vorbereitung auf die nächste Major Version werden neue Funktionen beriet gestellt, die in Zukunft bestehende ersetzten werden. Sprich es gibt Teile im Programm die als „Deprecated“ markiert werden und demnach zwar aus Kompatibilitätsgründen noch existieren aber in absehbarer Zeit entfernt werden. Vielleicht gibt es noch ein kleines neues Feature was auf dem bestehenden Code aufbaut usw.

Patch: Sind oft die kleinsten Änderungen und beziehen sich auf Fehlerbhebungen und Sicherheitsupdates die kein all zu großen Umbau am Quellcode erfordern. Vielleicht wurde ein Absturz oder ein unerwarteter Nebeneffekt behoben. Kleinigkeiten. Kombiniert man all dass noch mit dem Terminus Up-/Downstream kann eine Versionsnummer einer Software sogar so aussehen: 1.2.3-4. Major Version 1, Minor 2, Patch 3 und Downstreamänderungen in der 4ten Revision.

Die Entwicklung einer neuen Version eines Point-Releases läuft im allg. in mehreren Phasen ab. Oft gibt es eine sogenannte Testing oder Unstable Variante der jeweiligen Linux Distribution. Bei Debian ist das z.B. Debian Sid (auch Debian Unstable genannt). Hier werden kontinuierlich neue Pakete bereitgestellt, bestehende durch eine neuere Version ausgetauscht und dass auch oft recht zügig. Tests sind hier oft nur manuell wenn überhaupt durch die Distributionsmaintiner und auch nur dass was bei der Entwicklung auffällt. Generell wird hier kein Gewehr dafür übernommen dass das System funktioniert oder zuverlässig läuft.

Dann nach einer Weile landen einige der Änderungen von den „Unstable“ Versionen in ihrem jeweiligen Testing Varianten. Bei Debian z.B. Debian Testing. Dies ist sozusagen der Vorläufer des nächsten Releases. Solange sich die Distribution noch in der Entwicklung befindet werden hier auch öfter Pakete aktualisiert aber der Fokus liegt darauf das was man schon hat zu testen, zu korrigieren, testen, abermals zu korrigieren usw.

Bei openSUSE auf dem Open Build Service sieht der Prozess in etwa so aus: Development -> Factory -> Staging -> Tumbleweed -> Slowroll -> Leap -> SLE (SUSE Linux Enterprice). Manchmal, bei neu hinzugefügten Softwarepakten, steht noch ein weiterer schritt vor Development.

Dann kommt der sogenannte Feature Freeze. Dies ist ein Punkt in der Entwicklung an dem keine neuen Features mehr angenommen werden. Sprich es wird keine Major oder Minor Versionsänderungen geben. Haben wir also ein Paket, nennen wir es Foo, in der Version 1.0 und der Featurefreeze hat statt gefunden, wird Foo bis zur nächsten Version, oft in 2 bis 4 Jahren, auf Version 1.0 bleiben. Maximal Patches oder Downstreamänderungen werden hier angenommen z.B. 1.0.1-2. In seltenen Fällen und auch nur unter Ausnahmen mal eine Minor Version. Aber auch nur wenn sich das nicht auch als Downstream Patch realisieren lässt.

Das heißt aber auch auch dass eine Linux Distribution, die Foo 1.0.1 ausliefert andere Downstreamänderungen haben kann als andere Distributionen. Sprich Distribution A mit Foo 1.0.1-3 ist ein anderes Paket als das von Distribution B mit Foo 1.0.1-3. Obwohl beide die gleiche Downstreamrevisionsnummer besitzen können. Da diese aber nicht synchronisiert sind ist nicht gewährleistetet das Distribution A die selben Änderungen wie B vorgenommen hat. Oft ist es auch nicht notwendig, da Distribution A Paket Foo 1.0.1 patchen musste um mit einer anderen Bibliothek, nenne wir sie Bar 3.4.5-2, zusammen zu funktionieren.

Während dem Featurefreez wird die Distribution gepatched, gestestet, nochmal geptacht usw. und irgendwann für „stabil“ befunden. Dann gibt es noch einige Release Candiates (RC) bei denen bereitetes Feedback von der Community eingeholt wird. Dann schließlich wird die neue Linux Distribution 2.0 veröffentlicht. Oft wird sich hier immer an den selben Zeitraum gehalten, also z.B. alle 4 Jahre am 1. August oder ähnliches.

Das bedeutet aber auch, dass zu dem Zeitpunkt, zu dem Linux Distribution 2.0 veröffentlicht wurde diese nicht den aktuellen Upstream Code aller verwendeten Bibliotheken und Programme zu genau diesem Zeitpunkt enthält. Sonder dass was während des Featurefreeze aktuell war. Und selbst dass muss nicht die neuste Upstream Version gewesen sein sondern kann schon ein paar Monate oder in extrem Fällen Jahre alt sein. Pakete die es schon lange in einer Distribution gibt, sind oft an einer sehr großen Downstreamrevisionsnummer zu erkennen: Foo 1.0.1-1234 z.B.

Nehmen wir also an, dass wir zwei Distributionen A und B haben. Beide am 1ten August des selben Jahres in Version 2.0 veröffentlicht wurde. Kann es sehr wohl sein, und so ist es meistens, dass A mit Foo 1.0.1 aber B evtl Foo 1.1.0 oder vielleicht sogar mit Foo 2.0 ausgeliefert wird. Plus das beide zudem noch ihre eigenen Downstreamänderungen mit bringen. Das würde ich an dieser Stelle liebevoll als „Frankensteinsoftware“ bezeichnen.

Hinzu kommt dann noch ein extensiver Versionupdateprozess um von Distribution 1.0 auf 2.0 zu aktualisieren. Hier wird bei einigen Distributionen empfohlen einfach das System neu zu installieren, um Seiteneffekte zu minimieren. Manche bieten Upgradeassistenten an die im Grunde jedes einzelne Paket einmal durch eine neuere Version ersetzten. Das dabei etwas schief gehen kann, wenn sich einmal alles ändert und die Frage im Raum steht wie gut der Upgradeprozess getestet wurde, scheint fast offensichtlich. Abgesehen von der sogenannten „Downtime“ also die Zeit, die man den Rechner nicht oder nur eingeschränkt benutzten kann, da dieser entweder neu installiert wird oder sich während des Updates Bibliotheken ändern und bereits laufende Programme instabil werden können.

Rolling releases haben zwar auch in Grundzügen die Phasen eines point-releases, diese sind aber sehr viel kürzer und je nach Linux Distribution stark Automatisiert. Außerdem gibt es kein wirkliches Featurefreeze, sprich neue Major und Minor Versionen können durchaus schon am nächsten Tag enthalten sein. Ob und wie gut diese neue Software dann getestet wird liegt stark bei der Distribution selbst:

So benutzt Tumbleweed (und auch Fedora) z.B. ein System was auf den Namen OpenQA hört um automatisiert die top aktuellen Versionen durch testet. Erst wenn diese für gut befunden wurden werden die neuen Pakete an die Benutzer ausgeliefert. Dadurch das diese Tests automatisiert erfolgen, können diese schneller, detaillierter und viel mehr Tests durchgeführt werden. Gegebenenfalls muss ein Test angepasst werden oder es muss ein neuer beriet gestellt werden. Das ist aber Situationsabhängig. Auch einige der gängige point-releases benutzten automatisierte Testinfrastrukturen.

Andere Linux Distributionen, am prominentesten ist hier Arch Linux, verlassen sich auf Benutzertests. Da es sich um eine ausschließlich von der Community geführten Linux Distribution handelt stehen weniger Ressourcen für aufwändige Infrastrukturen bereit. Erst kürzlich stellte Valve eine sogenannte Signing Authority für Arch Linux zur Verfügung um automatisiert Pakete zu signieren so das Nutzer sicherstellen können dass sie keine Verfuschte Version einer Software installiert. Zuvor wurden diese Pakete manuell von den jeweiligen Paket Maintianern mit jeweils ihren eigenen privaten Signingkeys signiert. Diese müssen nicht einmal zwingen von einer zentralen Signing Authority stammen, also deren Echtheit kann nicht unbedingt gewährleistet werden. Das hat sich dank Valve aber zum Glück zum besseren gewendet.

Automatisierte Testframeworks besitzt Arch Linux meines Wissens nach nicht (Valves SteamOS vielleicht, abgesehen davon dass SteamOS sehr viel weit verbietet ist, automatisiert Absturzberichte an Valve sendet etc. ist hier selbst der „Community“ Anteil sehr viel größer). Daher wohl auch der bekannte Ruf dass Arch Linux sehr Wartungsintensiv ist. Plus dass das Grundkonzept absichtlich DIY ist. Also der Benutzer nicht nur entscheiden kann welche Software er genau verwenden will, sondern dies auch von vornherein machen muss. Was zudem ein standardisierten Testablauf erschwert, da es eben keine klare Standartauslieferung gibt. Da Arch Linux sich einer gewissen Berühmtheit kürt, bedeutet das aber leider auch der allgemein schlechte Ruf sich auch auf anderen rolling-releases fälschlicherweise überträgt.

Zudem übertragen sich die meisten dieser Schwächen (oder stärken, je nach dem wen man Fragt) auch auf Ableger von Arch Linux. Zwar besitzen Distributionen wie Manjaro einen expliziten Testingzweig und eine Standartausführung, aber da es sich auch hier um eine fast ausschließlich Communitybasierte Distribution handelt wird auch hier auf manuelle Tests gesetzt. Das gepaart mit einem deutlich geringeren Maitniaeranteil führ das dazu das viele Pakete einige Zeit im Testingzweig liegen und wenn sich kein Benutzter beschwert, diese dann für gut befunden und ausgeliefert werden. Eine größere Community führ in beiden Fällen dazu dass die gesamte Distribution besser getestet ist. Hilft aber leider der schlechten Reputation anderer rolling-releases nicht, die sich anderer Konzepte bedienen.

Natürlich ist der Vergleich nicht fair, da hinter Fedora Red Hat sitzt und openSUSE hauptsächlich von SUSE gesponsert wird, nicht nur finanzielle sondern auch mit Hardware. Demnach wenig verwunderlich dass hier mehr Infrastruktur zur Verfügung steht. Aber zeitgleich sind solche Distributionen sehr vom guten Willen eines Multimillionen Dollar Unternehmens abhängig. Das kann gut, aber auch schlecht sein.

Der Natur des Testens ungeachtet haben aber alle rolling-releases einen großen Vorteil. Sie aktualisieren sich schnell, aber die tasächliche Menge an Software bzw. die Versionsprünge die tatsächlich stattfinden ist überschaubar. Immerhin gibt es von Foo und Bar nicht jede Woche eine neue Major Version. Außerdem, da es keine fixen Distributionsnummern mit Featurefreeze gibt, muss auch keine lange Downtime eingeplant werden um das System auf die neuste Veröffentlichung zu aktualisieren. Die gibt es ja so gesehen nicht. Stadtessen aktualisieren diese sich kontinuierlich in vielen kleinen Schritten.

Semi rolling zu erklären ergibt sich fast. Hier wird versucht einen größeren Testzeitraum zu schaffen und zeitgleich aber auch dafür zu sorgen, dass die Software nicht zu alt ist. Doch auch hier muss eine gewisse Zeit eingeplant werden, in der das System durch die neue Version ersetzt werden soll und eine Downtime mit in Betracht gezogen werden sollte.

Also irgendwie versucht man das beste aus beiden Welten zu vereinen, die Downtime beim aktualisieren soll geringer sein, da der geänderte Softwareumfang in der kürzeren Zeit nicht so groß ist, aber immer noch größer als bei einem rolling-release, aber kleiner als bei einem point-release. Außerdem sollen Benutzter nicht zu lange auf neue Features und Treiber warten müssen, und dennoch genug Zeit zum Testen eingeplant sein.

Nach der ganzen Einleitung haben wir noch immer nicht die eigentliche Frage geklärt. Was eignet sich für den Desktop betrieb den nun am besten?

Point-releases: Haben den klaren Nachteil, dass Nutzer auf Featureupdates jahrelang verzichten müssen. Gerade im Bereich von Hardwaretreibern, die bei Linux mit dem Linux Kernel kommen, ist das problematisch. Es stellt sich schnell die Fragen: „Kann ich die neue CPU in meinem Rechner verbauen?“, „Läuft die neue Grafikkarte oder fehlen Treiber?“, „Wird der WLAN-Stick erkannt, wenn ja funktioniert er auch ordnungsgemäß?“, „Ich will mir einen neuen Laptop kaufen, doch wird mein lieblings-point-release darauf laufen?“, „Gibt es die neuste Firmware für meine Hardware die einen kritischen Hardwarefehler behebt?“ usw.

Kurzum, all diese Fragen werden zu einem Mienenfeld. Als Endanwender kann ich vollkommen verstehen, dass man erwartet das neue Hardware auch mit dem eigenen System funktioniert. Ich finde dass ist auch ein Anspruch, den man gerade an seinen privaten Desktop oder Laptop stellen darf.

Außerdem stellt sich die Frage: Traue ich jedem Nutzer zu ein Versionupgrade durchführen zu können, wenn Distribution 3.0 kommt? Oder fahre ich lieber selbst 2h zu meinen Großeltern und aktualisiere ihren Rechner dann übers Wochenende auf die neuste LTS Version und mache für den Fall der Fälle vorherher noch ein umfangreiches Backup?

Rolling-releases: Diese bekommen schnell und oft neue Features, neue Hardware wird recht bald oder evtl. sogar schon vor dem offiziellen Release unterstützt. Versionsupgrades bleiben aus, einmal am Tag oder einmal die Woche einen automatisierten Skript laufen zu lassen der das System einmal auffrischt scheint auch nicht schwer. Manche Distributionen bieten sogar ein Option in den Updateeinstellungen an um genau das auf regelmäßiger Basis zu tun.

Aber was wenn dann doch mal ein Fehler auftritt? Bei dem ein point-release noch vor dem nächsten Version Upgrade genug Zeit gehabt hätte diesen im Vorfeld zu beheben? Traue ich hier jedem Nutzer zu das Update rückgängig zu machen oder entsprechendes Troubleshooting zu betrieben um den Fehler händisch zu korrigieren? Also dann doch lieber semi-rolling? Diese bergen aber immer noch das Problem mit Versionsupgrades von Zeit zu zeit. Aber last minute Fehler werden evtl. noch rechtzeitig korrigiert?

Allerdings haben wir ein Problem noch nicht beleuchtet. Linux Distributionen bestehen nicht nur aus Treibern, Bibliotheken und einer schicken Desktopoberfläche. Sondern auch aus Anwendersoftware.

Bei point-releases überträgt sich Analog das Featurefreeze auch auf diese. Sprich ein Browser ist evtl. auf unabsehbare Zeit in einer alten Version gefangen oder kommt nur als Extendet Support Release daher. Sprich als eine art Lang-Zeit-Untertüzungs (Long-Term-Support) Version, um einerseits dem point-release Konzept genüge zu tun, aber andererseits immer noch die Nutzer mit wichtigen Sicherheitsupdates zu versorgen. Oder aber Distributionsmaintainer führen für bestimmte Ausnahmeregeln für bestimmte Software ein, die erlauben eine brandaktuelle Version auszuliefern. Bei rolling-releases besteht das Problem wiederum nicht.

Außerdem sorgen point-releases verstärkt dazu das Endnutzer (wenn sie das dann mal machen) Bugreport an den Upstream stellen bzgl. eines Fehlers der vielleicht schon seit etlichen Versionen korrigiert ist. Da evtl nicht klar kommuniziert wurde beim Fehlerbericht um welche Version der Software es sich handelt und der Upstream evtl. davon ausgeht, dass der Benutzter die neuste Version meint, den Fehler sucht, ihn aber nicht finden kann. Bis dann am Ende sich herausstellt, dass es sich um Foo 1.0 handelt aber seit Foo 1.1 dieser schon lange korrigiert ist.

Vor nicht all zu langer Zeit haben z.B. die Entwickler der beliebten Software Bottles ein Statement veröffentlicht „Please don’t unofficially ship Bottles in distribution repositories“ um genau diesem Problem zu entgehen. Distributionsmaintainer die eine veraltete Version im neusten Release ihre Distribution ausliefern. Das und dass sie extensiven Downstreampatching entgegenwirken wollen und somit Fehlerberichte erhalten, die nur in einer einzigen Distribution auftauchen, und dass auch nur weil irgendwas manuell von den Distributionsmaintainern an der Software angepasst wurde, damit die Softwate mit der Frankensteinsoftware die die Maintainer über die Zeit entwickelt haben „funktioniert“ oder gerade genau deswegen übehaupt Probleme auftreten.

Kurzum der Trend geht gegen rolling-release. Die Software ist aktueller, Anwendersoftware ist stets auf dem neusten Stand und neue Hardware, sofern sie überhaupt mit Linux funktioniert, wird auch gut bis sehr gut unterstützt. Außerdem werden Upstreamentwicklern unnütze Fehlerberichte erspart. Es muss keine Downtime für einen „Upgradetag“ eingeplant werden. Updates sind zwar viele aber nur kleine Änderungen.

Wer denn dennoch lieber auf ein point-release setzten will, dem empfehle ich Anwendungssoftware nicht über die Softwarequellen der eigene Distribution zu installieren sondern, lieber auf Flatpaks von Flathub oder Snaps von Snapcraft zurück zu greifen. Oder in seltenen Fällen auf AppImages. Wobei AppImages ein Thema für sich alleine sind, was ich in einem extra Blogeintrag erläutern würde.

Nun habe ich viel über das Thema geredet, doch muss ich zugeben, gehe ich auf meiner privaten Hardware sogar noch weiter. Hier setzte ich auf immutable, rolling-releases. Namentlich Aeon, Kalpa und für meine Server MicroOS.

Die Gründe dafür sind vielseitig. Zum einen ist allen 3 gemein, dass sie immer bei jedem Update einen Snpashot vom System erstellen. Sprich, da es sich um rolling-releases handelt die zwar von OpenQA getestet sind, möchte ich dem selten Fall dass ein Update mal nicht glatt gelaufen ist, entgegen wirken. Somit kann ich bereits beim Starten des Rechners einen älteren, funktionierenden, Snapshot starten und einfach weiter machen wo ich aufgehört habe.

Außerdem handelt es sich um immutable Distributionen, das bedeutet, dass bis auf das Nutzerverzeichnis und einige wenige Systempfade, nichts zur Laufzeit verändert werden kann. Dass wiederum setzt voraus, dass Systemupdates unabhängig vom laufendem System durchgeführt werden müssen. Das wiederum hat den Vorteil, dass Anwendungen, die gerade Laufen, wie oben erwähnt, nicht plötzlich instabil werden, weil sich Systembibliotheken geändert haben. Oder der neuste nVidia Treiber mit dem neusten Linux Kernel nicht kompatibel ist, da das System beim Update das Problem erkennt, das Update gefahrlos verworfen werden kann, und zu einem späteren Zeitpunkt, wenn das Problem hoffentlich behoben ist, erneut durchgeführt werden kann.

Wobei das Problem zusätzlich geringer ist, da die meisten Nutzeranwendungen eh aus Flathub kommen, und somit von vorneherein unabhängig vom System laufen und aktualisiert werden. Das wiederum hat den Vorteil, dass ich persönlich die Anwendersoftware direkt von den Upstreamentwicklern verwende, die neuste Version und ohne Distributionsspezifische Veränderungen. Sprich, wenn ein Fehler besteht besteht er für alle Nutzer und ich kann gefahrlos das Problem melden. Von dem Bonus der verbesserten Sicherheit durch die flatpak Sandbox, und den abgesicherten Basissystem ganz zu schweigen.

Was sich nicht auf Flathub finden lässt, wird dann wiederum via Distrobox installiert und auch hier unabhängig von Basissystem. Mit dem Bonus dass ich nun sogar Zugriff auf Softwarepakete aller gängigen Linux Distributionen habe. Arch Linux’s AUR, Ubuntus PPAs oder zugriff auf proprietäre Software wie DaVinci Resolve, welches nur offiziell unter Rocky Linux unterstützt wird oder AMDs ROCm, welches offiziell nur unter Ubuntu, SUSE Linux Enterprise, Debian, RHEL, Oracle Linux, Azure Linux also sprich enterprise point-releases unterstützt wird. Ich muss mich also nicht einmal darauf verlassen, dass ich meine Distribution glücklicherweise richtig gewählt habe um die nötige Software für meinen Workflow zu finden. Ich kann hier aus dem Vollen der gesammten Linux Community schöpfen.

Ein weiteres angenehmes Feature ist, das Tumbleweed, auf dem Aeon, Kalpa und MicroOS aufbauen auf unterstützer Hardware sogar x86_64_v3 optimierte Pakete installiert. Dies verbessert merklich die Leistung auf modernen CPU Architekturen. Ein Schmankerln welches die meisten Distributionen nicht bieten. Oftmals wird entweder ein bestimmter Standard Vorausgesetzt und optimierte Pakete für neuere Architekturen gibt es dann oft nicht.

Demnach ist meine klare persönliche Empfehlung für Linux auf dem Desktop: Aeon und Kalpa!