Snaps, Flatpaks, unveränderliche (immutable) Distributionen - oder auch Ansprüche an Paket Maintainer die noch nie erfüllt wurden!

Zurzeit findet extrem viel Entwicklung in der Linux Welt statt. Das ist nicht wirklich neu, da Linux ständig in Entwicklung ist, aber gerade Dinge wie systemd wurden zwar von Nerds massiv diskutiert und begleitet -> haben aber für den "Otto-Normal-Desktop-Nutzer" absolut keinen Unterschied gemacht. Jemand der Linux als Desktop System verwendet interessiert sich nicht dafür ob nun systemd, upstart, sysVInit oder Benjamin Blümchen die Services beim Systemstart startet.

Nun kommen wir aber mit Veränderungen an einen Punkt wo man auch in der Desktop Welt viel spürbar wird. Und wir kommen zu einem klaren Paradigmenwechsel.

Linux auf dem Desktop hat bisher so funktioniert: Man wählt eine Distribution seiner Wahl und kann dann über die Paketverwaltung die Software installieren die dir deine Distribution zur Verfügung stellt.

Die Pakete die die Distribution zur Verfügung stellt werden von Paketmaintainern (ehrenamtlich, oder gegen Bezahlung) gebaut.

Das ganze wird von vielen immer wieder als das "perfekte" System angesehen. Man muss Bibliotheken nur einmal auf dem Rechner haben, braucht weniger Arbeitsspeicher und weniger Festplattenspeicher. Und man kann alles aus einer Quelle aktualisieren - und dank den Paketmaintainer hat man immer noch mal ein Extra Paar Augen, dass sich den Quellcode der Software anschaut.

Diese "bisher" Paradigma, das nun gefühlt 20 Jahre seine Gültigkeit hatte verändert sich langsam. Snaps und Flatpaks werden zunehmen bei vielen Distributionen per Default installiert und aktiviert. Und über diese distributionsübergreifenden Paketformaten können nun Software-Entwickler erstmals unkompliziert ihre Software direkt an den Linux-Endkunden ausspielen - ohne dass eine Distribution dazwischen sitzt.

Um zu verstehen wie die Entwicklung von Snap und Flatpak zum laufen kam müssen wir verstehen was die Probleme bei Paketverwaltungen und den Maintainern ist.

Die Vorteile von Paketverwaltungen und Paketmaintainern die aufgezählt habe, sind nur auf dem Papier wirklich gut. In der Praxis gibt es da durchaus viele Problematiken.

Viel schlimer wird es dann noch, wenn Paket Maintainer einer Distribution Pakete selbstständig anpassen und so massive Sicherheitslücken einbauen. Man erinnere sich an Debian zurück, die den Zufallsgenerator in openSSL kaputt gepatcht haben, was dazu führte das 18 Monate lang einfach knackbare SSL-Zertifikate weltweit ausgespielt wurden und wohl einer der grössen SSL-Lücken der Geschichte war.

Diese Sicherheitslücke kam nicht davon, dass die Entwickler von OpenSSL Mist gebaut haben, sondern ein Paketmaintainer versuchte etwas zu patchen, dass er offensichtlich nicht verstanden hat.

Paket-Maintainer - zusätzliche Augen werfen einen Blick auf die Software

Hier muss wirklich einfach einen Blick auf die Realität werfen. In der Regel ist man als Paketmaintainer für eine bestimmte Anzahl Software zuständig. Als Beispiel wenn du das Paket "FileZilla" für eine Distribution pflegen musst. Dann hast du in der Regel ein fertiges Build-Script das du dir vor 10 Jahren mal für FileZilla zusammen gebastelt hast.

Dieses Script aktualisiert du dann mit dem Code der neuen FileZilla Version und lässt das Script laufen. Wenn alles gut geht kompiliert die Software ohne Probleme durch und du bekommst ein funktionierendes DEB oder RPM Paket. Du checkst dann noch ob du das Programm öffnen kannst ohne das es Abstürzt -> und das wars dann auch schon.

Wenn du Pech hast, gibt es beim kompilieren einen Fehler (meist weil sich eine Abhängigkeit verändert hat), dann wirfst du einen Blick in die Release Notes von der neuen FileZilla Version, passt die Abhängigkeiten in deinem Build-Script an und gut ist.

Hier findet kein wirkliches "Testing" statt. Das führte z.b. dazu das ArchLinux ein nicht funktionierendes Kdenlive Paket ausgeliefert hat. Kdenlive wurde zwar kompiliert, konnte auch starten. Sobald man aber Videos zum schneiden importiert hat ist es abgestürzt.

Aber auch viele Firefox Entwickler sagten auf Twitter immer wieder - wir empfehlen nicht die Builds der Distribution zu benutzen, sondern die Firefox Anwendung von unserer Webseite herunterzuladen.

Bei gewissen Distributionen, wurde das Firefox Build Script seit Jahren nicht mehr aktualisiert und das Paket wird mit uralten Compilern, und uralten Bibliotheken gebaut.

Das Maintainer die "Software" die Sie in ihrer Distribution pflegen nicht prüfen sieht man z.b. auch am Beispiel vom "KDE Partition Manager". Dieses Programm wurde von unzähligen Paketmaintainern von unzähligen Distributionen über Jahre gebaut, in die jeweilige Distribution eingepflegt und angeblich auch "geprüft".

Erst als ein angestellter von Suse sich eher zufällig dieses Paket mal genauer angesehen hat, hat er massive Sicherheitsmängel festgestellt.

Zitat

Gerrit Heim: Viel bei Open Source basiert auf Vertrauen. Anwender vertrauen ihren Distributionen, die Projekte den Maintainern, diese Maintainer den Upstream-Entwicklern etc. pp.

Glaubt ihr dem Zitat nicht? Wann habt ihr dann das letzte mal den Code von LibreOffice geprüft bevor ihr es installiert habt?

Shared Librarys - mehr schein als sein und Speicherplatz

Der Vorteil einer globalen Paketverwaltung ist, dass wenn ein Programm das ich geöffnet habe und dieses Programm nun Bibliothek Y braucht und ich danach ein zweites Programm öffne, das ebenfalls Bibliothek Y braucht ich diese Bibliothek nur einmal im Arbeitsspeicher habe.

Grundsätzlich stimmt das, aber auch das ist wieder sehr theoretisch. Fakt ist das Programme unterschiedliche Versionen von Bibliotheken brauchen. In der Realität wird es eher so sein, dass Programm 1 Bibliothek Y in Version 3 braucht und Programm 2 die selbe Bibliothek in Version 5.

Wie handeln das die Paketmanager der Distributionen? Naja ziemlich simpel - sie installieren unterschiedliche Versionen der Bibliotheken. Als Beispiel die Bibliothek "libgcc" die von so gut wie jeder Software gebraucht wird. Das aktuelle Ubuntu LTS liefert diese Paket direkt in 3 Versionen aus, libgcc10, libgcc11 und libgcc12.

Daher die Chance, dass trotz Paketverwaltung mehrere Versionen einer Bibliothek in eurem Arbeitsspeicher rumspucken sind ziemlich hoch.

Die Realität ist aber auch, das Arbeitsspeicher heute eigentlich kein Problem mehr sein soll. Selbst ein super günstiges Einsteigernotebook bei Media Markt (für 300CHF entspricht etwa 300 Euro) kommt bereits mit 8GB Arbeitsspeicher - was mehr als genug ist um ein paar Bibliotheken auch doppelt oder 50fach im Arbeitsspeicher zu haben.

Bild vom Media Markt Angebot, falls der Link irgendwann mal nicht mehr funktioniert:

Anspruch und Wirklichkeit

Im Grunde werden extrem viele Ansprüche an Paketmaintainer gestellt. Denen sie gar nicht gerecht werden können. Gleichzeitig haben wir Linux News Medien die immer wieder die Linux Paket Maintainer auf ein Podest stellen (z.b. hier und hier). Obwohl das System offensichtlich Probleme hat und nicht wirklich funktioniert.

Es gibt keine Fähigkeitsausweis für Paketmaintainer. Jeder von uns hier kann Paketmaintainer werden ohne irgendwelche Grundkenntnisse zu haben. Die Distributionen sind ja froh, wenn sich überhaupt jemand für diesen undankbaren Job freiweillig meldet.

Ich war als 15 jähriger Schüler ohne grosse Kenntnisse Paketmaintainer. Meine ersten Build Scripte habe ich mehr oder weniger von den Debian Build Scripten abgeschrieben - ohne das ich wirklich wusste was ich da wirklich mache.

Der Weg zu Snaps und Flatpaks

Dieser Beitrag soll kein Front oder hate gegenüber Paketmaintainern sein, wie bereits erwähnt ist das eine ziemlich undankbare Aufgabe. Kontakt zur Community hat man nur wenn irgendwas nicht funktioniert und sonst ist man da eher "unsichtbar". Insgesamt können wir aber froh sein, dass es sie gibt.

Aber für alle die etwas tiefer und länger in diesem System sind, ist klar das System ist nicht so perfekt wie es oft hergeschrieben oder von der Linux-Community verkauft wird.

Auf die Problematik der App-Entwickler die dann von Debian Usern irgendwelche Bug Reports für Fehler bekommen, die eigentlich seit 3 Programmversionen längst behoben sind, werde ich hier gar nicht eingehen.

Aber all diese Dinge sind der Grund, warum wir auf dem Desktop-Linux gerade so einen starken Umbruch erleben. Snaps und Flatpaks kommen zurzeit immer mehr.

Viele Gnome Apps empfehlen sogar ganz offiziell, das man sie bitte als Flatpak installieren soll.

Eine App die als Snap oder Flatpak kommt, hat keinen Paketmaintainer mehr dazwischen geschaltet. Man bekommt seine Anwendung so wie sie vom Entwickler eben bereit gestellt wurde.

Anwendungen als Snap und Flatpak sind aber erst der erste Schritt -> der nächste Schritt sind die unveränderteren "Basis-Systeme". Fedora testet das schon länger mit Fedora Silverblue und Fedora Kinoite. Canonical hat mit Ubuntu Core auch schon länger so ein Produkt im Portfolio und die nächste Version openSuse Leap bzw Suse Linux Enterprise soll ebenfalls so ein System sein.

Die Idee einer "unveränderteren" Distribution ist, dass das Grundsystem (Kernel, Desktop und alles was es braucht damit Kernel und Desktop läuft) wird von der Distribution geliefert. Im System selbst werden diese Basis-Komponenten im "Read Only Modus" geladen. Anwendungen laufen als Snap oder Flatpak Container und können nicht direkt mit dem Basis System interagieren.

Eigentlich ist das nichts neues, wir kennen diese Entwicklung bereits im Smartphone Bereich. Wo wir eine klare Trennung zwischen Betriebssystem (Android oder iOS) und den Anwendungen (Apps) haben. Die Entwicklung im Linux-Desktop wird zunehmend in diese Richtung laufen.

Und wie bei systemd, Wayland, PulseAudio und vielen anderen Entwicklungen, wird es wieder viele geben die dagegen Argumentieren - die Kommentar- und Forenspalten vollschreiben werden. Und am Ende wird sich das ganze dennoch als Gewinn für alle herauskristallisieren.

Ich kann bei dieser konkreten Frage nur über Snaps sprechen. Da ich Snaps einfach viel viel besser kenne als Flatpaks.

Das automatisierte Testing muss, in der Theorie ja eh dort passieren wo die Software angeboten wird. Bei Snap ist das logischerweise der Snap Store, da es dort keine alternativen Möglichkeiten gibt.

Bei Flatpak wird das ja schon komplizierter. Da es da unterschiedliche Repositorys gibt und ob da alle testen und alle gleich stark testen - naja ich bezweifle es - weiss es aber nicht.

Automatisiertes Testing von Software ist immer etwas sehr komplexes und in der Regel ist es auch nur immer halb automatisiert.

Dieses Testing beginnt - bei seriöser Software aber nicht erst bei der Software-Verteilung sondern bereits bei der Software-Entwicklung statt.

Hier ist es spannend sich z.b. mal den Code von LibreOffice anzusehen, die haben automatisierte Test die z.b. komplexe Word, Excel oder PowerPoint Dokumente erstellen -> und die nachher halt korrekt aussehen müssen, etc.

Diese Tests bringen natürlich nicht mehr viel, wenn Paketmaintainer nachher die Software eigenhändig patchen und diese Tests dann nicht mehr ausführen.

Wenn eine App bei Snapcraft in den Store hochgeladen wird, laufen dort einen Malware Scanner - und auch automatisierte Tests drüber.

Diese Test dürften aber relativ "Basic" sein. Also im Sinne von lässt sich App öffnen, gibt es Compile Errors, etc.

Das Problem mit diesen "automatisierten" Test ist, das sie eben nicht so einfach sind und immer halbautomatisch. In der Regel muss man quasi für jede Software einzeln in ein automatisches Script schreiben was und wie getestet werden soll. Es erklärt sich von selbst das eine Software wie z.b. LibreOffice andere Tests braucht als z.b. ein Musik Player oder E-Mail Programm.

Wirklich komplett automatisierte Tests, testen in der Regel der Code auf Programmfehler. Ich mache hier ein simples Beispiel in PHP weil es leicht verständlich ist. Als Beispiel ich schreibe eine Funktion die mir die Nutzerdaten anhand der NutzerID zurückliefern soll:

Das sieht dann oft z.b. irgendwie so aus:

<?php
function get_user_data_by_userid( $user_id ) {
    $user_data = $db->query( 'SELECT * FROM users WHERE id = " . $user_id . "' );
    return $user_data->fetchRow();
}

Ist jetzt ein super simples Beispiel. Aber Code den ich oft so sehe. Das Problem ist dieser Code geht davon aus, dass wenn jemand die Funktion aufruft z.b. so: get_user_data_by_userid( 5 ); also die quasi die User Daten von User Numer 5 will das hier immer ein Zahl übergeben wird.

Die Funktion selbst prüft den Wert der $user_id nicht, was passiert wenn nun jemand keine Zahl mitliefert oder Buchstaben statt zahlen, etc. Theoretisch müsste man den Code prüfen:

<?php
function get_user_data_by_userid( $user_id ) {
    if( is_int( $user_id ) ) {
        $user_data = $db->query( 'SELECT * FROM users WHERE id = " . $user_id . "' );
        return $user_data->fetchRow();
    } else {
        //$user_id ist keine Zahl -> hier muss jetzt irgendwas anderes passieren
    }
}

Der nächste Punkt ist, das hier auch nicht geprüft wird ob es überhaupt einen User mit der ID 5 gibt, etc. Solche "Fehler" oder potentielle Fehler kann man sehr sehr gut mit automatisiertem Testen herausfinden. In dem man über ein automatisiertes Testsystem alle möglichen Funktionen mit unterschiedlichsten werten aufruft und prüft ob es zu Fehlermeldung oder Abbrüchen kommt.

Ich bezweifle allerdings das beim Snap-Store bzw den Flatpak Repositorys solche Tests gemacht werden. Das würde bedingen, dass man immer und jederzeit Zugriff auf den Quellcode hat.

Da aber bei beidem auch die Installation von closed-source Anwendung möglich ist -> machen dort solche Tests wenig sinn.