Hallo und herzlich willkommen zu meinem Vortrag, Paketformate der Zukunft, App Image, Flatpak und Snap im Vergleich. Aber zunächst mal schön, dass ihr alle gekommen seid. Ich weiß nicht, wie es euch geht, aber so nach zwei Jahren nur zu Hause im Homeoffice sitzen und auch Konferenzen nur in irgendwelchen virtuellen Sessions zu haben, ist es echt

schön mal wieder echte Menschen zu sehen, so echtes Feedback zu bekommen und nicht ins Schwarze zu moderieren. Von daher, schön, dass ihr da seid und vielen Dank für die tolle Organisation vom Froscon und C3 Vogue-Team. Sehr schön, dass das wieder stattfinden kann. Habe ich mich sehr darauf gefreut. Ja, ich bin Christian

Stankovic und ich beschäftige mich gerne mit Linux und Virtualisierung und generell Infrastructure as Code. Da ich ein sehr fauler Mensch bin, versuche ich mir alles ein bisschen zurecht zu automatisieren, wo möglich. Ich findet mich auf Twitter, auf Mastodon, ich blogge auch schon seit einigen Jahren und seit Kurzem habe ich auch

die Freude, einen Linux-Podcast moderieren zu dürfen, der Focus on Linux heißt. Und heute geht es auch um Linux-Thema, wie gesagt, um drei Paketformate, wo wir uns die Frage so ein bisschen stellen, ist das die Zukunft? Ja oder nein? Das wollen wir so ein bisschen beleuchten. Deswegen werfen wir mal einen Blick auf die Agenda. Was wird das Erste sein, das wir uns anschauen? Generell erst mal

die Motivation. Woher kommt das Ganze überhaupt? Warum sollen wir uns damit beschäftigen? Und dann gucken wir uns konkret mal die einzelnen Frameworks an. App Image, Flatpak und SnapCraft. Und am Ende will ich euch so ein bisschen einen Ausblick geben und euch ein paar Links an die Hand geben, wo ihr euch eben weiter belesen könnt. Also warum überhaupt Paketmanager oder

so weiteres? Es gibt ja schon einige. Vielleicht sollten wir erst mal zusammenfassen, was wir als User eigentlich wollen, wenn wir Software konsumieren. Wir wollen im Prinzip Stabilität, wir wollen Aktualität, funktionale Updates. Das Ganze soll benutzbar sein und wir wollen eigentlich so diese One-Click-Experience. Also ist jetzt vielleicht kein schöner

Vergleich, aber wir wollen irgendwie so was wie ein Excel-File, wo wir doppelt draufklicken und der Kram läuft einfach. Also wir wollen uns nicht mit Abhängigkeiten und Libraries in irgendeiner Art und Weise auseinandersetzen müssen, sondern wir wollen draufklicken, der Kram so laufen.

Demgegenüber steht so ein bisschen, was EntwicklerInnen eigentlich wollen. Einige werden das jetzt total verwundern, aber EntwicklerInnen wollen Codes schreiben. Die wollen sich eigentlich nicht damit rumärgern, wie wir Pakete in irgendeiner Art und Weise pflegen und verwalten. Also ich will als Entwickler, als Entwicklerin Codes schreiben, mich auf die Funktionalität fokussieren, ein Produkt irgendwie schaffen, gucken, ob die Erwartungen

auch erfüllt werden. Und hier solche Sachen, Pakete bauen, das macht keinen Spaß. Also ich weiß nicht, wer von euch hat schon mal ein RPM oder ein Paket oder sonst was gebaut? Da gehen einige Hände hoch. Wie viele von euch hat das Spaß gemacht? Da sind einige Hände jetzt runtergegangen. Einige sind

oben geblieben. Es gibt auch Leute, denen macht das Spaß. Ich selbst muss zugeben, ich gehöre eher so zu der Kategorie, wenn es eine Möglichkeit gibt, das weg zu automatisieren oder jemand anderem in die Hand zu drücken, dann mache ich das. Okay, also wir haben festgehalten, wir

wollen das Ding einfach laufen und EntwicklerInnen wollen Codes schreiben und wollen sich nicht mit Paketierung herum ärgern. Das große Problem ist jetzt allerdings, wenn wir uns Linux anschauen, das ist ja historisch gewachsen, könnte man sagen. Das ist ja so ein schöner Ausdruck, den man auch immer mal hört. Die Ausfall ist halt sehr groß. Also ich kann mich mit zehn Leuten über Linux unterhalten und diese zehn Leute werden vermutlich unterschiedliche Distributionen einsetzen. Das heißt

im Endeffekt, wir haben so dieses RPM-Lager. Wir haben Leute, die benutzen Jam, DNF oder Zipper. Und auch da gibt es schon Unterschiede. Wenn ich DPN-basierte Distributionen nutze, dann habe ich meistens mit Abt oder AbtGET zu tun. Art User haben Pacman und das sind erst mal

nur so drei große. Es gibt noch andere Tools. Es gibt Slack Package, es gibt APK, es gibt nix und so weiter. Also ihr könnt die Liste beliebig weiterführen. Und Ubuntu ist ja auch das PPA auch noch ein spannendes Thema. Also die Personal Package Archives, die persönlichen Debt Proposities, die jetzt noch gar nicht auf der Folie stehen. Und das ist ja auch ein spannendes Thema.

Als wäre das nicht schon genug, gibt es auch noch ergänzend ja quellenbasierte Paketmanager. Das heißt, wenn ihr sagt, naja, das, was mir meine Distri schippt, ist halt irgendwie zu alt oder ist gar nicht drin, weil es den Qualitätsstandard nicht erfüllt, dann kann man sich ja auch selbst immer noch mal Pakete bauen. Da gibt es zum Beispiel das AOR, das Art User Repository, wo man eben eine Art Bauanleitung

bekommt. Und wenn ich so ein Paket installiere, dann werden Sources runtergeladen, Bibliotheken kompiliert und übersetzt und schlussendlich das Artefakt, das was raus purzelt, wird dann meinem System hinzugefügt. Das gibt es auch für Crux, nennt sich da Ports und Portage. Ich hoffe, man spricht da so aus, aus Gentoo, ist halt eben auch so ein Tool. Und das basiert alles auch so ein bisschen

auf der BSD-Welt. Also in der BSD-Welt gibt es dieses Ports-System schon sehr lange und verschiedene Linux-Distributionen haben das eben adaptiert. Das heißt, ich brauche einen Compiler und das Ganze wird eben übersetzt. Ja, und wenn ich jetzt eine tolle Software geschrieben habe und ich kenne mich vielleicht nicht unbedingt mit Linux aus und dann habe ich ein Tool geschrieben und habe dann diese Anforderungen

für diese Distributionen Pakete zu schreiben. Und da würde ich behaupten, da kann die Frustrationsgrenze sehr schnell erreicht sein bei den einzelnen Leuten. Um es kurz tabellarisch nochmal zu vergleichen, hier so ein grober Überblick mal über so gängige Linux-Distributionen. Ich denke,

die ein oder andere kennt ihr vielleicht auch. Wir haben natürlich Mainstream-Distros wie einen Ubuntu und einen Debian und einen Rell, haben aber auch eher nicht so weit verbreitet, wie ein Open Source, Tumbleweed, Arch oder Nixos. Und ihr seht allein schon nur, wenn wir mal so drauf gucken, hier gibt es in puncto Releases und Zyklen große Unterschiede. Ja, ich habe auf der einen Seite Distros, die

kann ich 13 Jahre lang benutzen und habe aber auch Rolling-Release-Distros, wo ich heute Pakete installiere, die morgen schon wieder veraltet sein könnten. Und eben, was man hier auch sieht, ist, die Distros haben alle unterschiedliche Fokus-Szenarien. Also die Langläufer, die dienen natürlich eher so ein bisschen der Stabilität und der Aktualität weniger.

Das heißt, es ist vor allen Dingen für Enterprise oder Geschäftskunden halt ein Thema, da will man kein Bleeding Edge, während vielleicht Entwickler, Entwicklerinnen eher Bleeding Edge wollen oder eine Distro haben wollen, wo die Paketauswahl ein bisschen moderner ist. Und wenn man jetzt wirklich nicht aus der Flossecke kommt und soll hierfür in irgendeiner Art und Weise Pakete schreiben, dann ist das

natürlich nicht so schön. Es führt dann dazu, dass eben für Fühler, Entwicklerinnen Linux eine etwas zu komplexe Plattform ist. Die Auswahl ist sehr groß, wie wir gerade gesehen haben. Es gibt viele Distros, viele Paketmanager und es gibt auch zu unterschiedliche Versionsstände. Also wenn wir jetzt mal über so was

rudimentäres nachdenken, wie so diese diese G-Lib-C, also die C-Base-Library, die von Linux verwendet wird, da gibt es auch wirklich große Unterschiede. Wenn ich mir das mal jetzt auf einem RHEL 6 anschaue gegenüber einem aktuellen Arch Linux oder sowas und das sind ja je nachdem, was ich programmiere, ist das auch wieder relevant, das auch noch im Hinterkopf zu behalten.

Gäbe es da doch nur eine Lösung für, um dieses Thema zu vereinfachen. Das führt im Prinzip dazu, dass man sich gesagt hat, naja, wie wäre es mit weiteren Paketmanagern? Das habe ich jetzt mal bewusst hier in Anführungsstrichen gesetzt, weil so neu sind diese Paketmanager eigentlich gar nicht, wie wir noch feststellen werden.

Es gibt im Wesentlichen drei Frameworks, die so als Problemlösungsoptionen angesehen werden, eben namentlich App Image, Flatpak und SnapCraft. Und wichtig ist hier, diese verstehen sich lediglich als Ergänzung und nicht als Ersatz. Das heißt, die ersetzen nicht euer Depp, euer Yam, Zyper, Pacman, was auch immer eure Linux-Distro benutzen mag, sondern es ist eine

Ergänzung. Sie wird parallel verwendet. Ihr habt nach wie vor euer Betriebssystem mit eurem Paketmanager, worüber ihr eure normalen Paketupdates bezieht und für einzelne Applikationen gibt es ergänzend eben jene zusätzlichen Paketmanager. Das ist schon mal ganz wichtig am Anfang zu verstehen. Und da wird vorschlagen, schauen wir

uns einfach die einzelnen Tools mal an und beginnen würde ich hier gerne mit App Image. App Image ist ein Framework, das es eigentlich schon relativ lange gibt, nämlich seit 2004. Das wurde von Simon Pieter als Click gestartet. Also da hört man auch schon so da geht es offensichtlich um eine einfache Experience, wo ich drauf klicke und dann meine Anwendung

benutzen kann. Und ja, der Fokus liegt auch ganz klar auf Desktop Anwendung und Desktop User. Also es ist nicht unbedingt für den Adminen designt worden, der eine zentrale Lösung sucht, um an zentraler Stelle Paketupdates irgendwie orchestrieren zu können. Dafür ist es nie gedacht worden. Vorteil von dem Tool ist, ihr

braucht keine Runtime. Also ihr müsst nichts tun, dass eure Linux-Distro mit App Image eben klarkommt. Und ihr müsst das Ganze auch nicht installieren. Ihr könnt das einfach ausführen. One-Click-Experience. Das heißt, so ein bisschen die Vorlage, auch wenn das nicht gerne gesagt wird, es war schon so ein bisschen an die Excel-Files oder die DMG-Files unter macOS oder die Portable

Apps angelehnt. Wer die noch kennt, das war so ein Ding, der Anfang Mitte 2000er. Und das Problem, das damit einherkommt, ist, dass es natürlich mit den vollen Rechten des Users läuft, der das Ganze ausführt. Das heißt, das sollte man nie als Root ausführen. Wenn ihr irgendwo eine App Image runterladet, wo vielleicht sich

ein Krypto-Miner drin verbirgt, dann läuft der halt mit Rootrechten auf eurer Maschine. Das wäre nicht so cool. Technisch sieht das Ganze so aus. Das ist ein Abbild, das eben im Squash-FS-Format vorliegt. Das braucht auch keine Sandbox-Umgebung, bietet auch keine. Das hat man ja gerade schon festgestellt, dass das eben im vollen Kontext eures Users läuft.

Und es gibt aber ein sogenanntes App Image Hub. Das ist eine Webseite. Und da gibt es eben 1300 Anwendungen, die man da mittlerweile findet. Also es ist schon eine relativ große Anzahl an Anwendungen, die man darunter laden kann von Office-Suite über Videoschnitt-Software. Also durchaus die Software, die vielleicht in eurer Distro nicht regelmäßig aktualisiert wird.

Ich hatte gerade gesagt, Squash-FS-Format V1, die es schon lange nicht mehr gibt, die hat noch das ISO-Format genutzt. Aber aktuell ist eben Squash-FS. Wie benutzt man sowas? Ist relativ einfach. Ihr ladet euch diese Datei herunter aus dem Git Repository von App Image Hub oder eben einer anderen Webseite, macht das Ganze ausführbar mit dem CH-Mod, wie man das

auch mit anderen Dingen tut. Und dann könnt ihr mit Punkt-Släche einfach das App Image ausführen. Es gibt auch noch ein paar Parameter, die man nicht sofort mit der Help-Funktion sieht. Also das Paket-Format selbst liefert euch auch ein paar Parameter mit, um eben mit dem Container-Format selbst zu interagieren. Ihr könnt zum Beispiel mit App Image Help euch die Hilfe

des Containers anzeigen lassen. Ihr könnt auch mit App Image Extract immer das Paket entpacken, wenn ihr es debuggen wollt. Vielleicht habt ihr einen Bug gefunden, wollt ihr nachstellen, könnt ihr da einen Blick reinwerfen. Und ihr könnt eben auch das User Home und eben den Punkt-Config-Ordner, der in eurem User Home liegt, wo ihr Anwendung gerne ihre Einstellungen ablegen. Das könnt ihr auch noch mal

anpassen, ist auch vor allen Dingen für Debugging recht interessant. Wie verwaltet man das Ganze? Wie gerade schon gesagt, die werden einfach runtergeladen und ausgeführt, diese App Images. Das heißt, es gibt keine zentrale Verwaltung in dem Sinne. Es gibt kein Repository, wo ihr irgendwie einen App Image Install, App Image Update oder so

machen könnt, wie man es von den klassischen Paketmanagern kennt. Das ist auch so nicht gewollt. Also die Philosophie dahinter ist One App ist gleich One File. Und wenn ihr jetzt eben eine neuere Version von dieser Anwendung haben wollt, dann ladet ihr die runter und führt die mit einem Doppelklick aus. Das ist so der Grundgedanke hinter dem dem Ganzen. Ja, und Simon Peter,

der das Ganze gegründet oder erfunden hat, der definiert es auch als Feature, dass er eben sagt, naja, du kannst halt die Datei mehrfach runterladen und die parallel ausführen und hast dann keine Konflikte. Versucht mal ein App Paket parallel in mehreren Versionen zu installieren. Das funktioniert so nicht. Mit App Images geht es eben auch. Und ja, Abhilfe gibt es aber auch.

Es gibt so zwei Tools einmal eben das App Image Update und das App Image Pool. Das sind zwei Tools, mit dem man da so ein bisschen ich will ich nenne es mal Patch Management vereinfachen kann. App Image Update ist eben so ein Dienst, der im Hintergrund laufen kann und der euch dann im Panel so eine Notification schicken kann. Hey, da in App Image,

da gibt es eine neue Version. Willst du updaten? Und dann kann man da eben das Update installieren. Und es gibt auch einen Store, der in Flutter geschrieben ist. Das ist eben das App Image Pool. Und ja, Simon Peter sieht da persönlich keinen Sinn in diesen Stores, weil er sagt, naja, es ist halt ein Single File, das man runterlädt und ausführt. Freut sich aber, wenn andere User da irgendwie

App Image, das integrieren in Shop Software. Das sieht dann so aus. Sieht halt aus wie so ein typischer Software Shop. Die sehen ja mittlerweile alle ähnlich aus, egal ob man sich die unter Linux oder anderen Betriebssystemen anschaut. Man hat Kategorien, in denen könnt ihr browsern, könnt hier oben auch nach verschiedenen Paketen suchen, bekommt hier ein paar Screenshots angezeigt und eine kurze Beschreibung,

wie das halt so aussieht. Ich hatte ja gerade schon gesagt, das eine Problem ist, dass App Images immer mit den vollen Benutzerberechtigungen laufen. Das machen die anderen Lösungen ein bisschen anders. Aber bevor wir da einen Blick drauf werfen, ist es, glaube ich, ganz interessant, wenn wir mal über die

DBus Portals sprechen. Kleiner Exkurs. Was ist DBus? DBus ist der Desktop Bus. Das ist die Bibliothek für die Interprozess Kommunikation. Das ist ein Teil von freedustop.org und eigentlich so jede Linux-Distro der letzten zehn Jahre benutzt das auch. Das heißt, wenn ihr jetzt nicht gerade die letzte Legacy

Rail 4 Installation irgendwo rumstehen habt, dann habt ihr das eigentlich ohnehin schon lange auf eurem System, ohne es vielleicht zu wissen. Und da hat man sich irgendwann mal hingesetzt und hat mal so ein paar Api-Definitionen runtergeschrieben, wie man vielleicht so eine rechte Verwaltung von so einer Anwendung in irgendeiner Art und Weise steuern könnte. Also dass man so sagt, so eine Anwendung, die kriegt halt Berechtigung

in Form von Flex, die aktiviert oder deaktiviert werden. Und dann darf eine Anwendung Dinge tun oder eben nicht. Das, denke ich mal, kennt ihr auch alle von eurem Smartphone, ist ja auch so, wenn ihr euch da eine App runterladet, dann kriegt ihr hier so eine Anfrage. Die Anwendung möchte gerne hierauf zugreifen und dann kann man die einzelnen Berechtigungen aktivieren oder deaktivieren. Ist hier eben ähnlich.

Ein so ein Beispiel ist hier org.freedesktop.portal.account. Das ist eben hier die Berechtigung, die es der Anwendung erlaubt, persönliche Informationen abzufragen. User Home, User Name, voller Name, sowas eben. Und das ist halt dann der Name setzt sich immer eben aus dieser Prefix zusammen und dann hinten steht genau,

was das für eine Berechtigung ist. Punkt Camera, ihr ahnt das schon. Da geht es um Webcam, Punkt Location, Standortinformation und so weiter. Screenshot, Screencast ist eben, wenn ihr eine Anwendung habt, die den Bildschirm abfotografieren oder filmen will. Das machen so Tools wie TeamViewer oder so Collaboration Software wie Teams oder sowas. Die nutzen das gerne

und mit Filechooser kann man eben Dateien lesen und speichern. Ist nun außen. Die Liste ist relativ lang. Wenn ihr da nochmal nachlesen wollt, findet ihr hier unten den Link und könnt euch das noch mal anschauen. So viel zu den Depos-Portals. Wie sieht denn jetzt so ein App-Image-Paket aus? Na ja, prinzipiell, ihr habt einen Ordner, der ist meistens zusammengesetzt

im Namen eurer App Punkt App-Dear. Also irgendwie hannah-montana-app.app-dear und dann ist unterhalb dieses Ordners die Ordnerstruktur, wo eure App drin liegt. Ja, zum Beispiel gibt es da eben App-Run. Das ist immer so das Startscript, so eine Art Auto-Exit-Bud, wo eben dann die Anwendung gestartet wird. Und dann habt ihr noch mal

so ein Desktop-File. Das kennt ihr vielleicht schon. Das findet ihr ja auch immer unter User-Share-Applications oder User-Share-Desktop. Gibt es ja dieses Dateiformat, wo genau definiert wird, was für ein Icon hat der Menü Eintrag, in welcher Kategorie und dann zeigt halt euer Gnome, KDE oder was auch immer für ein Desktop, benutzt euch in der richtigen Rubrik im App-Launcher dann dieses Symbol an.

Das sollte da drin liegen und passend dazu auch noch ein Icon. Und unterhalb des Ordners gibt es dann aber auch noch mal die vollständige Slash-USR-Struktur. Das heißt, ihr habt unter User Bin eure Anwendung. Unter User Lib habt ihr die Bibliotheken, die eure Anwendung benutzt und so weiter. Ja, und App-Run ist halt die zentrale Komponente,

die halt die Anwendung startet. Ihr könnt euch da selbst einen Skript schreiben oder was auch Sinn ergibt. Es gibt ein fertiges Beispiel auf GitHub. Das habe ich euch hier verlinkt. Das setzt halt eben einfach so verschiedene Umgebungsvariablen, also zum Beispiel das hier der LD Library Path, wo nach Bibliotheken gesucht wird. Der wird halt auch noch mal auf den Ordner gesetzt,

das App-Images. Das halt quasi, wenn die Anwendung gestartet wird, auch in dem Ordner-Kontext des App-Images nach Bibliotheken gesucht wird, weil das ist ja der Grund, warum ihr die Anwendung als App-Image packetiert, weil ihr eben nicht die systemweiten Bibliotheken verwenden könnt oder wollt. Und das Ganze halt eben auch noch mal für Perl beispielsweise oder für Qt-Plugins.

Und das sucht sich dann halt eben auch diese Anwendung aus dieser .desktop-Datei raus und startet dann halt eben die Anwendung. Wie erstellt man sowas? Gibt es mehrere Möglichkeiten? Zum einen kann man den Open Build Service von Suse benutzen und man kann aber auch bestehende Binär-Dateien

einfach konvertieren. Das funktioniert auch. Es gibt ein Plugin für die Travis CI, wenn ihr eben eure Software direkt mit einer CI übersetzen lasst. Für Qt-Anwendungen gibt es noch ein eigenes Skript für Elektron-Anwendungen ebenso. Und man kann sich aber auch manuell die Ordner-Struktur einfach anlegen und kann dann so ein Paket erstellen. Das ist nicht so die Rocket Science.

Wir gucken uns jetzt nicht alle an. Das würde ein bisschen den Rahmen sprengen, aber ich wollte auf jeden Fall noch kurz was zum Open Build Service sagen. Das ist dann sinnvoll, wenn ihr eh in einem großen Open Source Projekt irgendwie arbeitet und ihr sowieso vielleicht Pipelines habt, um eure Anwendungen zu testen. Das ist nämlich ein Service, wo ihr automatisiert Pakete erstellen könnt. Die nutzen ja auch andere Distributionen,

also nicht nur Open Suse, auch andere Projekte nutzen das ja. Da gibt es den Open Suse Build Service. Das kann man kostenlos nutzen, wenn man halt eben ein Open Source Projekt ist oder Open Source Code zur Verfügung stellt. Das könnt ihr aber auch in-house hosten. Also wenn ihr jetzt für ein Unternehmen arbeitet und ihr wollt das nicht aus der Hand geben, dann könnt ihr das auch selbst bei euch im Rechenzentrum hosten. Vorteil bei dem Open

Build Service ist eben, wenn ihr jetzt Bibliotheken benutzt, die auch auf OBS liegen, dann wird automatisch, wenn jetzt die Bibliothek eine neue Version rausbringt, euer Paket neu gebaut, wenn ihr das möchtet. Das heißt, ihr spart euch die Mühe, selbst gucken zu müssen. Gibt es was Neues? Das macht automatisch OBS für euch. Und ihr könnt dann auch eben automatisch den Code signieren lassen,

dass eben die Pakete, die ihr verteilt, auch klar mit euch in Verbindung gebracht werden können. Und das hat noch ein weiteres Feature, das ich ganz nett finde. Man kann dann auch, wenn ihr eine neue Version rausbringt, kann man so binär Delta Updates implementieren, in dem halt eben OBS dann auch erkennt, was hat sich gegenüber der vorherigen Version geändert?

Und dann gibt es halt ein Delta Update. Das heißt, eurer 100 Megabyte App Image Paket muss dann nicht nur mal komplett neu runtergeladen werden, sondern nur das Delta hat dazwischen. Das kann auch ganz interessant sein, gerade wenn man so schlank Elektron Apps paketiert, wie das ja im Moment total in Mode ist. Das Feature gibt es schon relativ lange, seit 2017.

Und ich selbst habe es jetzt nicht getestet, also habe ich hier keinen Open Build Service, den ich irgendwie nutze, aber ist auf jeden Fall empfohlen, wenn ihr an Open Source Projekten arbeitet. Eine andere Option ist es, binär Pakete einfach zu konvertieren. Und dafür gibt es ein Skript, das heißt Package to App Image. Und das soll euch so ein bisschen dabei helfen.

Und was macht das Tool? Na ja, das lädt eben binär Dateien zum Beispiel von so einem Debian Repository oder von der Webseite runter und führt dann ein Skript aus, das ihr vorher angelegt habt, um eben die Daten anzupassen. Also zum Beispiel es lädt ein Package runter, exportiert das, verändert ein paar Dateien, damit es eben als App Image funktioniert und erstellt euch

dann anschließend eben so ein App Image Abbild, das ihr dann wieder verteilen könnt. Das Ganze wird als Jaml-Datei konfiguriert und es gibt auch fertige Vorlagen, sogenannte Recipes auf GitHub. Könnt ihr euch einfach anschauen, gibt es ein eigenes Projekt beziehungsweise ja, ist ein eigenes Projekt. Und da ist halt viel schon drin und da kann man sich so ein bisschen

daran orientieren, wie andere Entwicklerinnen das vorher schon gemacht haben. Setzt aber natürlich voraus, dass ihr so ein bisschen die Struktur des Pakets kennt. Also wenn ihr jetzt LeapView Office darüber paketieren wollt, dann müsstet ihr halt schon wissen, naja, was ist denn in dem LeapView Office-Depian-Paket so drin? Also man muss halt vorher selbst ein bisschen damit gebastelt haben.

Hier ein kleines Beispiel, das ich im Forum von App Image gefunden habe und zwar ZDoom, wie man das hier eben umsetzen würde. Wir sehen hier, das ist ein Jaml-Dokument. Wir haben hier einmal den App-Namen ZDoom. Unter Ingredients geben wir so ein bisschen an. Was sind denn da für Inhalte drin, die konvertiert werden sollen? Das ist hier zum Beispiel einmal aus der Ubuntu Precise

Distribution verschiedene Quellen. Das heißt, wir geben hier die URLs an. Die kommen euch vielleicht bekannt vor. Das sind so diese üblichen Ubuntu Repositories, wo die Updates drin liegen. Da wird auch irgendwo ZDoom drin liegen und die ganzen Libraries, die ZDoom eben benötigt. Und dann habt ihr hier in dem Ingredient Step schon direkt ein Skript. Das lädt dann eben

nochmal hier FreeDoom runter. Also ZDoom ist ja quasi nur das Stück Software, das Doom ausführt. Und Doom selbst ist ja immer noch Copyright geschützt und FreeDoom ist quasi eine quelloffene Variante von Doom. Und das wird hier quasi von GitHub das letzte oder ein spezifisches FreeDoom Release runtergeladen, die 0.11.1. Und das Zipfile wird eben entpackt.

Und was das Skript dann schlussendlich nach dem Runterladen macht, ist, dass halt eben hier aus dem ZDoom-Ordner das wird in das App Image eben unter User Bin verschoben. Es wird ein Ordner angelegt und das, was eben in dem FreeDoom drin liegt, das wird nach UserShare Games Doom verschoben. Und so erkennt dann ZDoom

beim Starten OK, dass da ein FreeDoom vorhanden ist. Das ist so das einfachste Beispiel, das ich so so finden konnte. Wie konvertiert man das Ganze? Also wenn wir dieses YAML-File haben, dann führt ja einfach Package to App Image aus, gefolgt von dem Dateinamen. Dann läuft das Teil los, lädt die ganzen Informationen runter, packetiert das Ganze entsprechend mit den Skripten.

Und im Endeffekt kommt dann am Ende purzelt hier so ein App Image raus. Und ihr seht das, das liegt halt eben hier auf der Festplatte. Ja, und schon habt ihr einen App Image. Herzlichen Glückwunsch. Manchmal will man es aber vielleicht auch manuell bauen. Kann ja auch sein, dass man das mal schnell nachstellen will. Es ist zu komplex. Ihr habt kein Debian Paket

oder ein anderes Paket, das ihr konvertieren wollt. Dann ist das manuell auch eigentlich gar nicht mal so schwer. Konvention haben wir ja schon gehört. Immer Name eurer Anwendung gefolgt von Punkt App dir. Und dann gibt es hier auch wieder ein Tool, das App Image Tool. Das hilft euch dabei, Images zu erstellen. Das heißt, das erstellt dann eben diesen Container,

schiebt die ganzen Dateien rein, die man benötigt. Und ja, das manuell zu tun wäre vermutlich ein bisschen aufwendiger. Ja, hier auch ein Beispiel. Da habe ich jetzt so gemacht. Ich habe mir mal es ist echt schwer, da so ein einfaches Hello World zu zu finden. Und ich habe mir gedacht, das einfachste Beispiel ist irgendwie Leafpad, das lange im Debian Repository drin war.

Das ist so das kleinste, einfache grafische Programm, das ich gefunden habe, das nicht irgendwie hunderte Megabytes an Bibliotheken zum Bauen oder so hat. Das heißt, ich lade mir hier einfach einmal dieses Leafpad-Debian-File runter und leg mir ein Ordner an, leafpad.appdir, wechsle da rein und mit dpkg-x könnte ja ein Debian-Paket extrahieren.

Das heißt, ich extrahiere mir einfach, was in diesem leafpad.depp-File drin ist, in meinen leafpad.appdir-Ordner rein. Und dort kopiere ich dann so ein paar Dateien. Wir haben ja gehört, es muss ein Icon geben, weil dann hat das App Image auch so ein schönes Icon, wenn man es auf dem Desktop hat. Das ist, was hier eben passiert mit dem CP. Da kopiere ich hier einmal das PNG und einmal das SVG.

Dann kann halt eben, je nachdem, was für eine Auflösung ich habe, das passende Icon angezeigt werden. Ja, und hier unter user.applications leafpad.desktop ist auch ein Beispielpunkt desktop-File. Das kopiere ich auch in das root-Verzeichnis von diesem leafpad.appdir-Verzeichnis. Und anschließend sieht das so aus. Wir sind hier in diesem Ordner drin. Es gibt das app-run,

habe ich mir noch runtergeladen vorher. Und ich habe hier einmal das leafpad.desktop, einmal das Icon und dann eben hier lib plus die Bibliotheken aus diesem leafpad-Paket und unter user.bin habe ich dann auch das leafpad-Programm anschließend drin. So, war klar bis hier hin? Okay.

Ja, wenn ich diese Ordner-Struktur angelegt habe, dann genügt es eigentlich schon, eine Ordner-Ebene zurückzugehen und einmal mit App-Image-Tool leafpad.appdir eben das Bauen von so einem Abbild zu veranlassen. Ja, das läuft dann hier los und dann wird auch hier wieder ein Squash-FS-Image erstellt. Es wird ausführbar gemacht. Eine MT5-Hash wird eben berechnet

und fertig. Und so baut man sich einen App-Image. Vielleicht zum Abschluss noch ein paar Tipps, die man dabei beachten sollte. Also generell sollte es schon so sein, dass in dem App-Image die Bibliotheken drin sind, die nicht zur Grundinstallation

der Distros dazugehört, die ihr irgendwie supporten wollt. Also es wird jetzt wenig Sinn ergeben, immer eine G-Lib-C mitzuliefern, wenn ihr eh nur die Standard-G-Lib-C braucht. Dann habt ihr halt ein großes App-Image und verschenkt halt Speicherplatz. Wir wollen ja auf der einen Seite auch nicht jedes Mal 500 Megabyte App-Images runterladen, wenn wir einfach eine Editor haben wollen.

Und wichtig ist auch, dass man eine möglichst alte Distro zum Kompilieren nehmen sollte, die unterstützt werden soll. Und da wurde auch im Forum immer wieder genannt, dass halt lange Images auch auf CentOS 6 gebaut wurden, weil das war noch supportet, hatte eine relativ alte G-Lib-C Version. Und man hat dann halt gleich gemerkt, OK, G-Lib-C ist zu alt und dann kann man halt dann die weiteren Bibliotheken

mit mit reinnehmen. Also wenn ihr halt was auf einem CentOS Stream 9 baut, dann wird es halt nicht auf einem CentOS 7 laufen. Also möglichst alte Versionen halt eben nehmen und auf den System, die ihr supporten wollt, ausgiebig testen. Und ganz wichtig, wenn ihr selbst Code schreibt, aber das sollte eigentlich generell selbstverständlich sein, keine Hard-Codierten Pfade verwenden. Es gibt nichts Schlimmeres als Hard-Codierte Pfade, die zu finden und zu beheben

ist halt echt pain in the ass. Könnte man sagen. Also da sind auch so ein paar Tipps drin, wie man da mit Regex irgendwie automatisch von Fremdsoftware Hard-Codierte Pfade findet und die dann versucht zu ersetzen. Generell ist die Doku im App Image Wiki auch ziemlich gut, muss ich sagen. Also da gibt es auch viele gute Beispiele, mit denen man starten kann.

Wenn ihr jetzt nicht das älteste supportete LTS-Release nehmen wollt, dann nehmt ihr wenigstens nicht die aktuellste Version. Also kein Ubuntu 22.04, sondern vielleicht nur 20.04. So viel zu App Image. Wie sieht es denn mit Flatpak aus? Wo ist da der Unterschied? Nun, Flatpak ist 2007 einmal als Glick

vorgestellt worden, als wäre das eine Anspielung auf das Folge-Tool und ist aber seit 2016 als Flatpak bekannt, fokussiert sich auch auf Desktop-Anwendungen, benötigt allerdings eine Runtime. Also sieht man auch hier das neue Projektlogo. Das heißt, ihr müsst das Ganze auch installieren. Also es ist nicht nur einfach mit einem Runterladen getan.

Ihr müsst das Ganze installieren. Und das Ganze, das ist der Vorteil gegenüber App Images, startet die Anwendung eben in einer Sandbox-Umgebung. Und da habt ihr auch die rechte Verwaltung mit den XTG-Portals, die wir gerade kurz besprochen haben. Und die könnt ihr entweder über euren Desktop konfigurieren. Ich glaube, in der neuesten GNOME-Version und in der neuesten KDE-Version ist Flatpak Support schon mit drin.

Das heißt, da könnt ihr direkt schon sagen, das Flatpak soll bitte keine Berechtigung für mein Mikrofon haben, zum Beispiel. Oder es gibt ein total tolles Tool, das heißt FlatSeal. Da könnt ihr das auch nochmal einstellen. Also hieß Klick, dann hieß es mal Klick 2, Bundler, XTG-App. Und jetzt heißt es halt eben Flatpak. Wie sieht das Ganze technisch aus?

Da ist es so, dass Flatpak eben OS-Tree oder OCI-Images verwendet. Es gibt hier einen zentralen Store, wenn ihr so wollt, den sogenannten Flathub-Store. Und da findet ihr 1.700 Anwendungen. Das ist schon echt beachtlich. Das ist eine große Anzahl. Und das Schöne an Flatpak ist, es ist dezentral konzipiert worden.

Das heißt, es gibt natürlich Flathub, aber ihr müsst nicht Flathub benutzen. Ihr könnt auch einen anderen Store benutzen. Und einige Distributionen tun das auch. Beispielsweise elementary OS oder Pop OS. Die haben einen eigenen Flatpak-Store, der auch per default eingerichtet ist. Und da kuratieren die auch so ein bisschen, dass die halt nicht die neuste Version von den einzelnen Flatpaks drin haben,

sondern halt eben welche, die sie auch selbst getestet haben. Aber es hält euch niemand davon ab, eben auch nochmal direkt Flathub einzubinden und dann Latest und Greatest zu benutzen. Das ist auf jeden Fall interessant. Und ihr könnt ja das auch als als User benutzen. Ihr könnt euch in eurem User Kontext einen Flatpak installieren oder man kann es auch systemweit installieren.

Updates bedeuten hier immer eine neues Image und generell sind derzeit 33 Distributionen unterstützt und auf vielen ist das Ganze auch schon vorinstalliert. Also sowas wie Pop OS oder Fedora. Die haben das schon lange mit drin und es ist defaultmäßig schon mit dabei. Habt ihr vielleicht gesehen, wenn ihr in den Shop reingeht und eine Anwendung installiert, dann steht da manchmal irgendwie RPM und manchmal eben Flatpak.

Gesetzt im Falle, ihr habt eine Distro, die nicht standardmäßig mit Flatpak schon ausgeliefert wird. Wie könnt ihr das Ganze nachrüsten? Das ist relativ easy. Ihr habt eine Runtime, die könnt ihr installieren. Ich habe das mal hier die gängigen Befehle mal aufgelistet. Jam, Updates über Pacman, Install, Minus S, Flatpak. Das zieht dann automatisch

die ganzen Pakete nach, die man eben so so braucht. Und dann der erste Befehl ist, dass ihr einen Store definiert. Das geht mit dem Flatpak Kommando Flatpak Remote Minus Add. Und dann könnt ihr auch noch sagen, wenn ihr wollt, if not exists, gibt dem Ganzen einen Namen, Flathub zum Beispiel. Und dann gibt es hier so eine URL.

HTTPS flathub.org repo flathub.flatpak zum Beispiel. Also es ist halt im Prinzip ein Web repository, wie es auch bei Upd oder Jam oder anderen Paketmanagern auch der Fall ist. Wenn ihr das gemacht habt, dann könnt ihr einfach sagen, Flatpak install, Flathub, gefolgt von dem Namen. Und die Namen, die haben halt auch alle hier so im URL Format

wird dann immer eine Anwendung auch einer Organisation oder einem Entwickler, einer Entwicklerin zugeordnet. Hier zum Beispiel das Flatseal Programm, von dem ich gerade gesprochen habe. Das hat halt den Namen com github c t c h x 84 Punkt Flatseal. Ist manchmal ein bisschen blödsinnig, das zu merken, aber so würde man

das Ganze installieren. Flatseal selbst sieht so aus. Ich hatte es ja gerade schon kurz erwähnt, dass halt eben die Desktop environments euch eigentlich auch schon Werkzeug an die Hand geben, um die Berechtigung zu beschneiden. Wenn das nicht der Fall ist, dann gibt es hier Flatseal. Da habt ihr hier links erst mal eine Liste aller Flatpaks, die ihr installiert habt. Da seht ihr zum Beispiel

Teams habe ich hier installiert und Signal und was auch immer. Und dann habt ihr hier die einzelnen Berechtigungen und könnt ihr auch an oder ausknipsen. Zum Beispiel, ich könnte Teams hier den Netzwerkzugriff verbieten. Dann könnte ich Teams zwar nicht mehr nutzen, aber prinzipiell kann ich das Ganze tun. Es gibt hier Berechtigungen für Sockelzugriff, für Webcam, Mikrofon und so weiter. Die Liste ist wirklich lang

und ihr könnt auch Flatseal selbst die Berechtigung über Flatseal entziehen. Dann könnt ihr halt keine Flatpaks mehr konfigurieren. Aber prinzipiell geht auch das. Ja, sehr feine Sache, wie ich finde. Und hier noch ein Beispiel aus dem Pop Shop, außer Pop OS Distribution. Wenn man da jetzt Anwendung installiert,

dann ist hier auch Flatpak direkt integriert. Das heißt, ihr seht hier direkt Name, Icon. Könnt das Ganze updaten oder entfernen. Habt ihr Screenshots und eine kurze Beschreibung, wie halt App Stores heutzutage aussehen? Schön und gut. Aber wie erstellt man so einen Flatpak? Ist das schwer? Es ist ein bisschen schwieriger als App Images,

behaupte ich jetzt mal, ist aber trotzdem machbar. Es gibt nämlich einen SDK. Das kann man installieren. Und dann ist da ein Binary enthalten, das Flatpak minus Bilder heißt. Und auch das könnt ihr über Flatpak installieren. Und im Endeffekt, wie auch bei anderen Tools, es gibt ein Jaml-Manifest.

Also wir sind ja heute auch sowieso alle Jaml-Engineer. Keiner ist mehr Admin oder Software-Entwicklerin. Das sind alle Jaml-Engineers. Deswegen haben wir ein Jaml-Manifest, wo wir Quellen definieren. Zum Beispiel ist es ein Archiv, das wir runterladen. Wollen wir ein bestimmtes Git Repository auschecken, da irgendwie Dateien patchen, aktualisieren.

Das definieren wir da alles und das unterstützt auch mehrere Build-Systeme. Also wirklich gängige Dinge wie Auto-Tool, C-Make, Q-Make, das ist alles mit drin. Und ja, das schreibe ich da alles rein. Und dann baue ich mir so ein Paket und teste das natürlich, dass das auch funktioniert. Und dann, und das ist ein bisschen komplexer jetzt,

habe ich halt dann ein lokales Repository, wo ich dieses Paket hinzufüge. Wir haben ja gehört, dass es halt eben entweder OCI-Images sind oder eben OS-Tree-Images. Da brauche ich immer halt so ein Repository. Und das kann ich dann zu einer lokalen Quelle hinzufügen und kann das Paket dann lokal, über ein lokales Repository installieren

und kann das aber auch wieder dann hochladen, wenn ich irgendwo ein Web-Mirror habe. Also ein bisschen komplexer. Wir gucken uns mal konkret an einem Beispiel an. Wie könnte sowas aussehen? Na ja, zunächst würde man vielleicht mal so ein, dieses SDK installieren mit Flatpak-Install und dann eben das Org-Free-Desktop-SDK.

Dann kommt das direkt mit. Und dann nehmen wir jetzt mal an, die Anwendung soll jetzt hier so ein einfaches Shell-Script sein, wo irgendwie Ohio-Frostkorn ausgegeben wird. Das soll jetzt unsere Anwendung sein, die wir eben mit Flatpak paketieren wollen. Ja, das heißt, wir brauchen erst mal ein org.flatpak.hello.yml-Dokument. Das wäre jetzt quasi der Name des Programms. Also würde ich das auf GitHub veröffentlichen,

würde das irgendwie heißen com-github-st-devel-hello.yml. Ja. Und dann habe ich als erstes hier mal eine App-ID, also auch wieder hier dieser Name, wie das Paket heißt. Dann gebe ich eine Runtime an. Also ich brauche hier die org-free-desktop-Plattform, also Flatpak. Und dann kann ich auch eine konkrete Version angeben.

Das wäre jetzt in dem Fall meiner Tests, die 21.08 war da aktuell. Ich gebe hier auch nochmal das SDK an. Und hier im Prinzip command hello.sh. Das ist eigentlich der Entry-Point, wo mein Flatpak starten soll. Ich will ja dieses hello.sh-Script einfach nur ausführen. Und wie das da reinkommt in dieses Flatpak, das wird eben über Module gelöst.

Ich habe nämlich ein Modul, das benutzt das Bildsystem Simple, weil es kopiert einfach nur ganz stupide Dateien von A nach B. Wie gesagt, habt ihr jetzt eine C-Anwendung, habt ihr irgendwie QMAC, CMAC, whatever. Ich wollte hier ein möglichst einfaches Beispiel. Deswegen Bildsystem Simple. Und als Bild-Commons, was wird gemacht? Das Install-Commando installiert mir das hello.sh nach

slash app slash bin slash hello.sh. Das ist ja alles in einer Sandbox bei Flatpak. Sehr der Vorteil gegenüber AppImage. Ja, und als Sources gebe ich einfach nur an. Naja, die hello.sh, die hat hier diesen spezifischen Pfad. Und das ist halt Typefile. Das kommt nicht aus dem GitHub-Repository oder sonst woher. Das liegt direkt in dem Ordner,

wo der Quellcode auch drin liegt. Abgesehen davon, dass das viele verschiedene Parameter sind, die man sich alle nicht merken kann, halbwegs nachvollziehbar, was wir hier gerade machen. Wenn wir dieses Dokument geschrieben haben, dann führen wir einmal den Flatpak-Builder aus. Da sagen wir einmal Flatpak-Builder,

geben hier builds.dir. Und builds.dir ist quasi dann der Ordner, wo das Ganze dann landen soll, also wo die Artefakte landen. Und dann gebe ich hier einmal das YAML-Dokument an. Das Tool läuft dann los, lädt sich die Quellcodes runter. In dem Fall ist das ja relativ einfach. Das liegt ja direkt in dem Ordner drin. Und dann läuft die Buildstage los.

Wir sehen auch hier, dass hier dieses Install-Kommando ausgeführt wird. Beim komplexeren Beispiel würde jetzt hier euer CMake, UMake, whatever loslaufen. Und anschließend wird hier das Ganze, die App gebaut und wird eben hier in so ein Cache-Ordner reingeschoben und noch Metadaten ergänzt und so weiter.

Das sieht dann konkret auf der Platte so aus. Wir haben diesen Builddir-Ordner. In diesem Ordner gibt es eben hier Export-Files. Da liegt dann auch das Binary drin. Wir haben hier so ein JSON-Manifest, das gebaut wird, Metadaten, verschiedener Wahlkram. Also das ist so das Skelett unseres Flatpacks, könnte man sagen.

Das heißt jetzt aber noch nicht, dass das installiert ist und benutzt werden kann. Dazu kommen wir jetzt nämlich erst noch. Denn bevor wir das installieren, testen wir diese Anwendung erst mal. Wir sagen dann Flatpack-Builder, User, im User-Kontext nicht systemweit. Installieren wir das doch bitte mal. Und zwar aus folgendem Ordner. Das ist ja hier unser Artefakte-Output-Ordner.

Und zwar bitte dieses Flatpack, das sich über diese Datei erstellt habe. Und dann wird hier quasi das einmal diese Anwendung hier installiert aus dem lokalen Verzeichnis. Und wenn das getan wurde, dann sollte das dann auch in oder umständlich in eurer GUI auftauchen, wenn wir da jetzt ein paar Informationen noch mehr drin hätten. Oder ihr könnt es einfach mit Flatpack run und gefolgt

von dem Paketenamen ausführen. Und dann kommt hier auch unser Ohai-Frostcon. Das aber immer noch rein für die Entwicklung gedacht. Das heißt, es ist jetzt nichts, was direkt im Internet verfügbar ist. Das würde dann so aussehen, dass wir dann anschließend den Flatpack-Builder nochmal laufen lassen.

Und dann wird eben hier dieses Paket in ein lokales Repository exportiert. Und das kann man dann, wenn man will, hier einhängen lokal. GVG-Verification, skippen und installieren. Oder man kopiert das Ganze dann auf so ein Web-Mirror. Also ihr seht, das ist alles schon ein bisschen komplexer. Nicht ganz so einfach wie App-Image, aber ist halt technologisch

wie ich finde, der etwas schönere Ansatz. Wir haben eine Sandbox-Umgebung und wir haben eine saubere Rechteverwaltung. Ja, und das ist je nach Anwendung durchaus relevant. Das dritte Tool in dem Kontext ist SnapCraft. Berühmt, berüchtigt und umstritten könnte man sagen. Aber schauen wir es uns mal an. Was macht SnapCraft aus?

Es ist 2014 von Canonical vorgestellt und entwickelt worden. Der Fokus ist hier ein bisschen erweitert. Also es fokussiert natürlich Desktop-Anwendung ganz klar, aber eben auch Serverdienste und Druckerstacks. Also es ist ursprünglich mal für so IoT-Use-Cases entwickelt worden. Und man hat dann aber festgestellt,

naja, das wäre eigentlich auch für Desktop-Anwendung ganz, ganz cool. Und so Druckerstack, Druckertreiber ist generell Drucker machen ja keinen Spaß. Also ich habe keinen Spaß damit, einen Drucker zu benutzen. Egal unter welchem Betriebssystem. Weiß nicht, wie es euch geht. Aber immer wenn ich Drucker höre, habe ich instant Stress. Ja, was funktioniert heute nicht? Ist der Toner leer? Funktioniert die Netzwerkerkennung nicht? Also es gibt ja immer Dinge, die nicht funktionieren.

Und das wurde halt in Ubuntu schon lange ausgelagert. Das Ganze nutzt System-D-Features wie Socket-Activation. Und deswegen ist es auch so ein bisschen umstritten, weil es heißt dann so, naja, das läuft dann halt nur mit einem System-D-Linux und nicht mit einem editbasierten Linux, was bei App-Images eben nicht der Fall ist. Ja, man braucht auch hier eine Runtime.

Das heißt, ihr müsst auch diese Snaps installieren. Und es gibt einen Hintergrunddienst, der Snap-D, der aktualisiert eure Snaps auch. Und das Blöde ist und das ist auch so ein bisschen die Kritik. Man spricht hier von der Bevormundung oder viele sprechen davon. Man kann das nicht deaktivieren. Ihr könnt maximal 60 Tage diese App jetzt herauszögern und dann werden die installiert.

Kommt, was ihr wollt. Außer ihr knippst das Internet ab. Aber dann klar ist euer Rechner halt offline. Ja, und da wird gerne auch mal der Vergleich gezogen zu Microsoft Windows, wo es ja eine ähnliche Politik gibt, was eben Updates anbelangt. Da habe ich ja auch als User nicht mehr die volle Hoheit über mein Gerät. Und das ist im Prinzip bei Snap-Craft nicht anders, muss man sagen.

Vorteil davon ist allerdings, dass eben diese Apps auch wieder in der Sandbox ausgeführt werden. Wir haben hier wieder diese XTG-Destro Portals, die wir besprochen haben. Das heißt, wir können granular genau definieren, welche Anwendung was darf auf dem System. Und App Armor wird auch genutzt. Es gibt bisher noch keinen offiziellen SE Linux Support, aber das Apple Repository, das denke ich mal die Fedora und Centos

und Rocky und Allmar Linux User von euch kennen, die haben da ein Paket für gebaut. Das heißt Snap-DSE Linux. Ich habe es nicht getestet. Also können Sie gerne mal ausprobieren, wie es mit SE Linux aussieht. Aber offiziell ist es nicht unterstützt derzeit. Und das große Problem ist, dass man halt eben auch themes irgendwie dediziert verteilen muss.

Und der größte Kritikpunkt ist eigentlich der, dass man sagt, es gibt diesen zentralen Snap-Store und der ist halt proprietär. Also da hat halt Canonical die Hoheit drüber. Da machen die im Hintergrund auch irgendwie so einen automatischen Malware-Scan. Trotzdem gab es aber vor vier Jahren irgendwie Apps, die einen Krypto-Miner drin hatten. Da stellt sich halt die Frage, wie kann das passieren,

wenn das doch euer Unix-Selling-Point ist, dass das nicht passieren soll? Und das ist halt so ein bisschen der Widerspruch zum Open-Source-Gedanken. Also das Schöne ist ja bei FlatHub, man kann das zentral nutzen. Ihr könnt aber auch euer Ereignis hochziehen. Aber man kann sich nicht halt selbst einen Snap-Store hochziehen. Und ich weiß auch nicht, wie viele Pakete es im Snap-Store gibt, weil die API nicht wirklich dokumentiert ist und ich nicht einfach rankomme.

Das ist halt so ein bisschen das Problem irgendwie an der Stelle. Technisch sieht es so aus, ihr habt auch hier wieder ein Squash-FS-Image mit der .snap-Datei-Erweiterung. Und da ist eben die Anwendung drin und die Bibliotheken, die die Anwendung benötigt. Und das Image wird eben eingehängt und die Dateien werden on-demand dann eben entpackt.

Standardmäßig wird dafür ein XZ-Container benutzt. Da hat man halt geringere Größen, aber nicht so die beste Performance. Und es gibt jetzt aber auch optional LZO. Da ist das Pfeil ein bisschen größer, aber es ist schneller zu entpacken, was gerade auf nicht so starker Hardware wie so dem Raspberry Pi durchaus eine interessante Sache sein kann. Dazu gleich noch mehr.

Das Ganze ist nicht nur für Ubuntu konzipiert. Das gibt es auch für Rell oder für Debian-artige Distros. Fedora ist unterstützt. OpenSuse, Solos und Arch Linux. Und es hat transaktionale Updates. Also so ein Update kann mehrere Steps beinhalten. Und nur wenn alles sauber durchgeführt werden, gilt ein Paket als aktualisiert.

Die Begrifflichkeiten bei dem Tool finde ich immer so ein bisschen schwierig, weil manche sagen Snap, manche sagen Snapcraft. SnapD ist auch immer so ein Wort, das gerne mal genannt wird. Also da hat sich echt irgendwie das Marketing hat richtig reingekickt. Also Snap bezeichnet hier eigentlich die Anwendung plus die Abhängigkeiten, die eben benötigt werden, damit diese Anwendung auch ohne Anpassungen

auf verschiedenen Plattformen läuft. Rell 6, Ubuntu 20.04, whatever. SnapD ist der Dienst, der im Hintergrund läuft und eben diese Snaps für euch automatisch verwaltet. Es gibt den Snap Store. Das ist der zentrale proprietäre Online Store von Canonical. Und SnapCraft wiederum ist eigentlich nur die Technik,

also das Framework und die Applikation, die ihr benutzt, um eure Anwendung damit zu bauen. Und um das Ganze noch ein bisschen komplexer zu machen, gibt es auch sogenannte Channels. Also wenn jetzt so eine Anwendung im Snap Store ist, dann kann es da mehrere Veröffentlichungskanäle geben. Und das Format, was man hier benutzt, ist irgendwie Track slash Risk slash Branch.

Und Track ist eben ein unterstütztes Release, also sowas wie Latest für die letzte Version oder Insider für den letzten Developer Build zum Beispiel. Risk ist die Stabilität. Es kann sowas sein wie Stable, Candidate, Beta, Edge. Also je nachdem, wie man das leben will.

Und Branch wiederum kann sich auf den Entwicklungszweig beziehen, also zum Beispiel auch auf so einen Branch Namen von eurem Git Repository beispielsweise. Das heißt, so ein Channel könnte beispielsweise lauten Latest slash Stable. Das wäre dann die letzte stabile Version. Da könnte aber auch lauten Insider slash Edge.

Das wäre dann quasi von der Entwicklungsversion die letzte Bleeding Edge Version, die gerade heute Nacht irgendwie von der Entwicklerin gebaut wurde, damit ihr Bleeding Edge Software testen könnt. Also gibt es mehrere Builds. Und ihr seht das auch, wenn man in dem Snap Store ist und ihr dann eine Anwendung auswählt. Dann könnt ihr immer genau auswählen, welche Version ihr jetzt gerade konkret benutzen wollt.

Ich habe ja gerade schon so ein bisschen über die Kompression gesprochen. Wir müssen ein bisschen jetzt über die Never Ending Story Snap und Firefox reden. Ihr habt sicherlich über die Medien mitbekommen. Ab Ubuntu 21.10 war es so, dass Ubuntu Firefox primär als Snap angeboten hat.

Man konnte aber trotzdem noch parallel das Ganze als klassisches Debian-Paket bekommen. Das hat sich mit 22.04 geändert. Seitdem wird Firefox nämlich ausschließlich als Snap angeboten. Vorteil ist natürlich, und das verstehe ich auch, Mozilla, die ja auch Firefox entwickeln, die am besten wissen, wie Firefox tickt, die paketieren das Teil selbst.

Und auf der anderen Seite Canonical hat weniger Verantwortung. Die Leute von Canonical müssen sich nicht damit beschäftigen, die letzte Firefox-Version in die Pipeline reinzubekommen. Das macht ja alles Mozilla. Nachteil ist, deutlich langsamerer Firefox-Startzeiten bedingt durch die Technik. Wir haben ja gerade schon gehört, das ist eine Compression.

Ich habe das mal getestet, als das rauskam, auf einer, wie ich finde, relativ potenten Hardware. Auch hier so ein E7 Workstation-Kiste in der VM mit zwei CPUs und zwei Gigabit. Hab das auch mal hier gebenctmarkt in einem Blogpost. Könnt ihr gerne nachlesen. Und da war es so, der Kaltstart, die native Debian-Version, war in acht Sekunden

über Snap 21. Und so ein normaler Start, wenn es das erste Mal gelaufen ist und sich eingerichtet hat, das waren knapp drei Sekunden native und 8,5 eben über Snap und auch diese Jetstream-2-Benchmarks, also so ein Browser-Benchmark, war auch ein kleines bisschen schlechter. Und das ist jetzt wirklich relativ gute Hardware.

Aber nicht jeder hat eine Workstation zu Hause. Es gibt Leute, die haben echt irgendwie noch ein altes Netbook, irgendwie, das sie nicht wegwerfen wollen. Weil, warum wegwerfen? Das ist ja der Vorteil von Linux, auch alte Hardware weiter nutzen zu können. Während mir Microsoft schon lange den Support eingestellt hat und ich kein Windows 11 mehr installieren kann, weil CPU zu alt, kann ich auf meinem alten 32-Bit-i5 von vor,

keine Ahnung wie viele Jahren, immer noch ein aktuelles Linux betreiben. Und da gab es natürlich sehr eindeutig negatives Feedback aus der Community. Das hätte man auch durchaus vorher erahnen können. Es gab irgendwie Leute, die gesagt haben, sie haben relativ aktuell ein i3-Laptop, der jetzt 45 Sekunden braucht, um Webbrowser zu starten.

Das darf nicht sein. Und, naja, Canonical hat sich erst mal so ein bisschen gerechtfällig. Die haben halt gesagt, das ist voll sinnvoll, weil Firefox hat ja eine Sandbox und Snap hat auch eine Sandbox. Du hast quasi noch eine Sandbox. Das ist viel sicherer und so. Das ist ein Argument.

Aber das Problem war auch, dass das Snap-Paket beim ersten Start alle 98 Sprachpakete kopiert hat auf die lokale Platte. Und jetzt stellt euch mal vor, ihr habt ein nicht so neues Notebook mit einem i3, mit drehendem Rost statt einer SSD. Und für 98 Sprachpakete werden Dateien installiert. Oder ihr habt einen alten Raspberry Pi.

Das dauert ewig. Könnt ihr vergessen. Und es wurde halt eben auch die XZ-Kompression verwendet. Und Mozilla hat dann mit dem Firefox 100.0 Snap eben auch noch so ein paar Compilerflex verändert. Also konkret geht es hier um PGO. Das ist die Profile Guided Optimization und LTO Link Time Optimization.

Da sind dann die Start- und Laufzeiten ein bisschen schneller geworden. Und am Anfang war es auch so, dass beim Raspberry Pi und bei AMD basierten Systemen leider irgendwie der falsche GPU-Treiber gewählt wurde und deswegen super ineffizientes Software-Rendering verwendet wurde. Aber genug der Häme. Canonical und Mozilla haben an den Snaps gearbeitet.

Ja, also Firefox lädt jetzt nur noch benötigte Übersetzungen runter. Ihr habt ja die Environment-Variablen und dann wird halt immer für eure Sprache das Sprachpaket runtergeladen und US halt noch. Und die ganzen GTK-Snaps, die verwenden jetzt halt statt XZ eben LZO, was halt ein bisschen größer ist, aber schneller entpackt werden kann, gerade auf älteren Maschinen.

Und davon sollten dann auch andere Snaps profitieren, die GTK nutzen. Und das hat dann in Summe dazu geführt, dass man 50 Prozent schnellere Kaltstarts auf so einem Raspberry Pi hat und auf so einem X86 29 bis 42 Prozent. Also da hat sich schon durchaus was getan. Es ist bedeutend schneller. Es ist nicht ganz so schnell wie nativ, aber es ist auf jeden Fall

in einem brauchbaren Rahmen, würde ich sagen. Und in Zukunft wollen sie aber noch mehr optimieren. Zum einen haben sie gesagt, naja, diese Squash-FSD-Komprimierung, die ist unter Ubuntu Single Threaded. Das heißt, ihr habt so einen tollen AMD Thread Ripper mit 128 Threads. Das Modul nutzt halt nur einen.

Das ist dem so ein bisschen geschuldet, der Kern-Modul-Konfiguration. Jeder, der schon mal einen Lieblingskern kombiniert hat, kennt das ja. Ihr wählt eure Module aus und könnt die auch noch konfigurieren. Und da gibt es halt dieses eine Flag, das halt Multithreading für Squash-FS nutzt. Das ist halt nicht gesetzt. Also wenn man halt dieses Snap dann auf Ubuntu Benchmark gegenüber,

wie es auf Arch oder auf Fedora läuft, sieht man halt eben auch, dass es nur unter Ubuntu wirklich nochmal eine ganze Ecke langsamer ist. Und ansonsten ist auch geplant, für GTK-Anwendungen so ein Precaching zu aktivieren. Wie das jetzt aussieht, dass vielleicht beim Login schon irgendwie Dinge vorgeladen werden, weiß man noch nicht. Aber das ist auf jeden Fall geplant. Wie wird das Ganze umgesetzt?

Also so ein Snap-Paket, auch hier wieder, ihr ahnt es vielleicht. Man hat eine Jammel-Datei. Dort gibt man den Namen des Pakets an, die Version, die Beschreibung und auch so ein Berechtigungsmodell. Da gibt es so drei verschiedene Modelle hier. Und das ist halt auch wieder so ein bisschen schwierig, wie ich persönlich finde. Um so ein Snap-Paket zu bauen,

müsst ihr Multipass installiert haben. Und Multipass ist halt eben, ich sage immer so spaßenscheidbar, Poor Man's Vagrant. Also Vagrant kennt ihr ja vielleicht das Tool von Haschikob, wo ihr halt unabhängig vom Hypervisor, Xen, KVM, Hyper wie VirtualBox, was auch immer eben VMS standardisiert hochziehen könnt. Sowas ist Multipass. Das erstellt euch nämlich eine Ubuntu VM,

egal ob Linux, Mac oder Windows. Und in dieser VM wird dann dieses Paket gebaut und dann eben anschließend so ein Snap-File generiert. Ja, das sieht dann eben so aus. Ihr habt hier Namen. Das ist hier ein Beispiel. Das habe ich einfach aus dem Wiki von denen kopiert. Gibt Namen an, hier so ein Offline iMap-Dummy-Tool,

eine Version, eine kurze Beschreibung und eine Description, was das Tool hier macht. Und dann gibt man eben hier auch einen Base an. Also es gibt immer diese Runtime, gibt es in verschiedenen Versionen. Es gibt Core 18, Core 20, Core 22. Das sind so die gängigen. Und da gibt es verschiedene Plugins auch, wie man das Ganze dann baut. Ihr seht hier unter Parts

gibt es diesen Job Test Offline Dummy und unter Plugin steht hier Python. Da steht Python, weil es halt ein Python-Tool ist, was halt eben hier genutzt wird. Es gibt auch Plugins für andere Sprachen, wie irgendwie Rust für Golang. Also da gibt es vorgefertigte Plugins, die ihr benutzen könnt, die dann eure Anwendung halt mit allen Abhängigkeiten sauber paketieren.

Da gibt ihr eine Quelle an. Also hier zum Beispiel wird ein Git Repository angegeben. Und dann wird hier auch gesagt, na ja, in das Snap willst du vielleicht auch das Python 6 Kommando installieren. Und by the way, es ist ein Python 2 Paket. Ja, und anschließend gibt man unten unter Apps hier auch nochmal das Kommando zu dem Tool an, das man eben hier starten möchte. Also hier bin offline

im App in dem Fall. Yet another Jaml Definition. Muss man halt auswendig lernen oder sich Beispiele angucken. Dann ist die Doku recht gut, muss man sagen. Es gibt viele viele Beispiele. Es gibt so einen Assistent, da wählt ihr aus. Ich habe diese Programmiersprache und dann purzelt da euch direkt hier so ein Beispiel aus. Wenn man das erstellen will, dann hat man diese Snapcraft Jaml,

die halt eben aus diesem Wissert rausgeputzelt ist oder die ihr selbst gebaut habt. Und ihr müsst euch halt einen Ordner anlegen, der sinnvoll benannt ist. Also hier zum Beispiel auch Test Offline IMAP Dummy. In diesem Ordner legt dieses Jaml Dokument und den Ordner wechselt ihr rein und führt einfach nur Snapcraft aus. Und dann kommt eben Multipass. Das installiert euch dann eine Ubuntu Instanz via LXD.

Das ist so der Nachfolger von LXC, könnte man sagen, mit ein paar Features mehr. Und der zieht dann halt eben auf eurem Xen beziehungsweise KVM. Ist es, was hier genutzt wird. Es muss also auch ein lokales KVM installiert sein. Eine Ubuntu VM hoch, wo dann eben je nachdem, ob ihr Core 18, 20 oder 22

eingetragen habt, wird halt eben da eine passende Version hochgezogen, Buildscript da ausgeführt und dann anschließend habt ihr so ein Snapfile und das könnt ihr lokal, wenn ihr wollt, installieren mit Snapinstall DevMode Dangerous. Und dann gebt ihr halt den Namen des Pakets ein und dann habt ihr das Snap Paket installiert.

Werfen wir noch mal kurz einen Blick auf eine Zusammenfassung. Also was haben wir jetzt in den letzten Minuten gehört? Na ja, es gibt diese drei Frameworks, App Image, Flatpak und SnapCraft. Die sind alle schon mehr oder weniger einige Jahre alt. App Image ist das älteste, SnapCraft das jüngste. Wir sehen hier, wer das entwickelt hat, wo der Fokus eben ist.

Wir sehen hier ganz klar, App Image ist möglichst simple. Wir haben keine Runtime. Wir müssen es nicht installieren. Wir haben aber auch keine Sandbox, was jetzt auch wieder ein Sicherheitsrisiko darstellen kann, wenn ihr so wollt. Das sieht bei Flatpak und SnapCraft anders aus. Das muss man installieren. Da gibt es eine Runtime, aber wir haben halt eben auch eine saubere rechte Verwaltung, denn wir haben nämlich hier die Option,

die XDG Desktop Portals zu verwenden. Und bei SnapCraft haben wir in Ergänzung sogar App Armor, was wir nutzen können, was prinzipiell eine feine Sache ist. Es gibt verschiedene Stores. App Image Hub, FlatHub, SnapCraft. App Image Hub hat ca. 1300 Apps, FlatHub 1700. Und bei SnapCraft, ich weiß es wirklich nicht. Ich habe die Webseite

mir lange angeschaut, konnte die Info nicht finden. Ich habe SnapCraft angetwittert. Hey, wie komme ich an die Infos? Wollte mir keiner sagen. Deswegen weiß ich es leider nicht. Wenn man so ein Update hat, ist es bei App Image prinzipiell immer ein neues Image. Oder wenn ich OBS nutze, diese Binary Deltas. Bei Flatpak ist es ein neues Image. Und bei SnapCraft habe ich eben

transaktionale Updates, was im Prinzip ein bisschen intelligenter ist. Wie könnte man das jetzt zusammenfassen? Ich persönlich bin der Meinung, App Image ist für Desktop Anwendung die schlankste und einfachste Lösung. Flatpaks sind weit verbreitet, integrieren sich auch super in diese Software Shops, die die Distros ja mittlerweile so haben. Und SnapCraft kämpft halt leider mit technischen Details,

Kompression und dieser Never Ending Story mit Firefox und auch der Akzeptanz, weil halt eben einfach es war abzusehen, wohin die Reise gehen könnte oder wie das Feedback sein könnte. Und man hat zu spät darauf reagiert. Man hat darauf reagiert, dass das Problem ist jetzt weitestgehend gelöst. Aber man hätte das eigentlich schöner machen können. Man hätte proaktiver und schneller auf das Feedback.

Meiner Meinung nach eingehen müssen. Ich bin auch der Meinung, quelloffen und dezentral sollte immer. Präferiert werden gegenüber proprietären Shops. Das ist gerade in der Open Source Ecke will man eigentlich nichts Proprietäres. Und ich finde auch persönlich den Umweg über Multipass und LXD unnötig komplex. Es gibt Tools wie Vagrant,

die nutzen zahlreiche Frameworks und viele Entwicklerinnen draußen nutzen das. Warum nimmt man das nicht einfach? Das wäre das, was halt eben Usus ist ein Stück weit auch. Und ich bin auch der Meinung, also diese Tools haben alle ihre Daseinsberechtigung und ich sehe das auch für einzelne Anwendung. Bin aber der Meinung, so ein Webbrowser ist heutzutage eine kritische Anwendung,

die weiterhin vom Distributor geschippt werden sollte als klassisches Paket. Weil wir hängen den ganzen Tag irgendwie im Netz ab, haben irgendwelche Konferenzen oder irgendwelche Online-Termine. Und es findet ja alles online statt heutzutage. Und wenn ich jedes Mal so ewig lang warten muss, bis mein Webbrowser da ist, weiß ich nicht, ob man sich da so einen großen Gefallen mit tut oder um es anders auszudrücken,

ist es eigentlich scheißegal, was für ein Browser du benutzt, solange er halt immer noch in dem normalen, konventionellen Paketformat in irgendeiner Art und Weise ausgerollt wird und nicht als Snap-Paket. Aber genug der Häme. Zum Abschluss habe ich noch ein paar Links für euch. Und zwar gibt es hier verschiedene Wikis und Dokumentationen,

die ich euch verlinkt habe. Es gibt zum Beispiel auch von Simon Peter, der App-Image erfunden hat, ein interessantes Interview. Der hat auch einen Vortrag auf der Susecon 2017 gehalten. Hier sind auch Tutorials und die Dokus verlinkt. Auch ein Hello World für Snap. Die Snapcraft-Doku ist, wie gesagt, sehr gut, wie ich finde. Und wenn euch irgendeines der Tools interessiert für eins eurer Projekte, guckt es euch gerne einfach an.

Und wenn euch Themen wie diese interessieren, könnt ihr euch die auch alle zwei Wochen in dem Focus und Linux Podcast anhören, wenn ihr wollt. Das ist ein recht neues Format. Das haben wir dieses Jahr erst angefangen. Gibt einmal am Monatsende so ein bisschen der News zusammenfassen, was es so Neues gibt aus der Linux-Ecke. Und in der Mitte des Monats gibt es immer noch mal so thematische Sonderfolgen.

Da reden wir über Dinge wie Vim zum Beispiel haben wir zuletzt gesprochen oder wir haben auch mal über Serenity OS gesprochen. Das war ein sehr, sehr spannendes Thema. Da sind auch zwei Leute anwesend und auch jedes Mal gibt es ein paar Tooltips für euch an die Hand. Und das gibt es überall, wo es Podcasts gibt. Vor allem uns immer über Feedback. Wenn ihr Ideen habt oder selbst mal mitmachen wollt, lasst uns gerne wissen.

Und damit bin ich fertig und danke euch für die Aufmerksamkeit. Und wenn ihr noch Fragen habt, dann könnt ihr die jetzt sehr gerne stellen, wenn ihr wollt. Ich fange mal mit einer Anfängerfrage an, auch um das Mikrofon zu testen.

Du hast sehr oft das Wort Sandbox erwähnt und ich habe mich gefragt bei Flatpak hast du den Bash Interpreter einfach so eingesetzen können, wo ich mich sofort gefragt habe, ist der jetzt automatisch Teil dieses ganzen Bundles oder also wie muss ich mir die Sandbox vorstellen?

Wie voll ist die oder wie leer ist die? Und ist die Sandbox nur das Recht im Management, ob ich auf einzelne Dinge des Betriebssystems zugreifen darf oder nicht? Oder wie voll ist das Bundle? Also ist die Sandbox versteht sich dem Kontext so, dass die Prozesse, die da gestartet werden, die können erst mal natürlich

die Berechtigung, wenn XTG unterstützt wird, dürfen sie diverse Dinge nicht tun. Webcam, Mikrofon, was auch immer. Und die Prozesse sind auch in einem abgeschotteten Bereich. Also sie können jetzt auch nicht auf Daten zugreifen, die direkt in der User Home drin liegen. Also das muss auch wirklich berechtigt werden, auf welcher Ordner zugegriffen werden darf.

Also ein Flatpak, das du ausführst oder ein Snap kann jetzt nicht deine privaten Gehaltsabrechtung oder so, die du hast, dann irgendwie raushauen ins Internet oder so. Hilft das weiter? Hat geholfen. Das bedeutet aber, ich muss auf die allen Eventualitäten der unterschiedlichen Bash Implementationen

Rücksicht nehmen. Ich kann nicht davon ausgehen, dass ich mit der Bash Implementierung ausgeliefert werde, mit der ich gebundelt habe. Das fällt dann unter das Testen. Ja, also das ist dann immer so der Pain. So das Paket ist schnell erstellt, aber dann zu gucken, ob die Berechtigungen alle soweit greifen. Das ist halt dann das, wo es ein bisschen unangenehm wird. Aber es hast du ja auch bei anderen Lösungen.

Danke. Gerne. Ich glaube, hier war irgendwo eine Frage. Also mir geht es drum. Ich meine, ich habe hier.

Bei den allermeisten Softwarelösungen, wenn es gerade kein Hello World ist, irgendwelche Abhängigkeiten, irgendwelche Bibliotheken, die ich benötige. Die müssen ja dann jeweils in dem Paket mitgeliefert und damit installiert werden. Damit habe ich aber eventuell zehn verschiedene Versionen der gleichen Bibliothek vorrätig.

War es nichts über Sicherheitsaktualisierungen, ähnliches. Da sehe ich halt gewisse Probleme gegenüber den Standard-RPM-Dev und sonstigen Managern, wo das zentral gemanagt wird, wo ich eine Version meiner Bibliothek habe. Absolut, also du hast absolut recht. Du hast dann im schlimmsten Fall verschiedene Bibliotheken doppelt und dreifach auf deinem Rechner.

Deswegen ist es ja auch so, dass sich diese Tools nur als Ergänzung verstehen. Also du willst nicht jede Anwendung, die du auf deinem Rechner hast, damit ausrollen, sondern es geht ja primär um Anwendungen, die sich sehr häufig verändern, wo man sagt, da kommt der Distributor nicht hinterher, das zu shippen.

Und das ist ja auch der Grund, warum Canonical sagt, naja, so ein Firefox ist ein guter Kandidat dafür, weil da gibt es ja ständig neue Versionen mit neuen Features, mit neuen Security-Fixes. Ja, genau. Also es ist nicht die Lösung für alles. Da hast du absolut recht. Du hattest bei Firefox und Snap hauptsächlich als einziges Problem die Start-up-Zeiten erwähnen, wenn ich mich recht entsinne.

Da gab es ja noch ein rechter Problem, dass das Firefox von Snap irgendwie nicht so mit KeepersX reden konnte. Ja, genau. Da gab es auch Probleme. Ich habe es nicht im Detail verfolgt. Ich habe nur mitbekommen, dass die auch für diverse Plugins, auch für so Screensharing-Sachen, also Screensharing ist ja auch so ein Beispiel, wenn du irgendwo eine Zoom- oder Teams-Einladung bekommst,

da haben halt auch Rechte gefehlt. Also da haben sie wirklich in den letzten Monaten viel gemacht, muss man ganz ehrlich sagen. Also, auch wenn das der eine oder andere Seitenhieb gerade war, sie haben sich schon darum gekümmert und es gab auch viel neue Versionen dieser Pakete, damit es auch besser wird. Ich denke, es dürfte jetzt auch generell besser sein.

Also das ist keine Frage, aber eine kleine Anmerkung. Bei SnapCraft muss man LXD oder Multipass nicht benutzen. Nicht unbedingt. Echt? Ja. Man kann auch mit dem sogenannten Destructive Mode ausführen und dann wird es lokal gebaut. Man kann es dann mit Vagrant oder was auch immer kombinieren. Ach cool, super. Interessant, das habe ich in der Doku gar nicht gefunden.

Wie bist du drauf gekommen? Also durch ausprobieren oder? Ich bin Snap-Entwickler, ich arbeite bei Canonical. Ah, okay, cool. Bitte schieß mir nicht. Super. Wir sollten uns mal unterhalten, weil ich suche schon lange Leute, die für Canonical arbeiten und Deutsch sprechen, weil ich die gerne mal auch zum Podcast einladen würde.

Also, wenn du Bock hast. Super. Einer der zentralen Gründe, die du jetzt erwähnt hast für diese ganzen Package-Manager, ist ja, dass die Software zu schnell released für den Distributor.

Dann ist, wäre meine Gegenfrage, warum bekommt so eine Firma wie Canonical das nicht hin, aber so eine kleine Distro wie Arch Linux schon oder Manjaro oder so, die sehr schnelle Releases machen, dann halt Bleeding Edge sind, aber das ließe sich ja auch gestaffelt implementieren, wenn die Firmen wirklich mehr Stabilität haben wollen.

Das ist schwierig. Ja, ist ein guter Punkt. Und ich glaube, hier sind wir wieder, kannst du mir gerne wieder sprechen, aber jede Distro hat ja einen anderen Fokus. Also ich meine, ein Arch, ein NixOS hat einen ganz anderen Anspruch als Ubuntu zum Beispiel. Also Ubuntu legt ja einen Wert drauf. Sie wollen aktuell, aber sie wollen auch stabil sein.

Das heißt, man will in Ubuntu keinen Bleeding Edge drin haben, man will jetzt aber auch halbwegs aktuelle Software drin haben. Deswegen, das ist glaube ich, ich stelle mir das echt schwer vor, so bei irgendeiner Distro Package-Manager zu sein und irgendwie die Schere da zu finden. Entweder ist es den Leuten zu alt oder den Leuten ist es zu instabil.

So diese Mitte zu finden ist glaube ich super schwierig oder wie siehst du das? Man muss dann auch eine vernünftige Version finden, wo es stabil und benutzbar ist. Das finde ich auch eine coole Sache.

Also die LTS-Releases, wer es nicht weiß, von Ubuntu, die waren halt früher nur 5 Jahre gab es die. Und jetzt vor einem Jahr, glaube ich, wurde ja angekündigt, dass man es gegen extra Münze bis zu 10 Jahre macht. Und das ist halt, das musst du dir halt überlegen. Also du willst halt 10 Jahre lang oder 5 Jahre lang willst oder musst du was supporten.

Deswegen ist es glaube ich echt schwierig. Da kann man glaube ich einen eigenen Talk mal drüber machen. Also die Freuden und die Freude des Drehen eines Package-Managers. Gut, habt ihr weitere Fragen oder Anmerkungen?

Kannst du noch mal Sandbox genauer definieren? Also ist das nur ein Change-Route mit C Groups obendrauf? Weil du hast Ab-Armor auch noch genannt. Also da gibt es ja große Unterschiede, was das eigentlich bedeutet Sandbox.

Genau. Da bin ich mir nicht ganz 100% sicher, um ehrlich zu sein. Ich bin aber der Meinung, dass C Groups auf jeden Fall ein Thema sind, die relevant sind. Weil das brauchst du ja, um die Prozesse voneinander abzuschotten. Weil sonst sieht ja deine Sandbox trotzdem, dass du einen Firefox M Player whatever offen hast.

Und primär geht es aber darum, dass die ausgeführten Programme nicht die Dateien deines Dateisystems sofort sehen. Sie sehen halt nicht, dass du in der Home irgendwo deine Gehaltsabrechnung oder sonst was hast. Sondern nur explizit das, was sie dürfen. Also der Firefox darf zum Beispiel nur unter Punkt, Konfig, Mozilla da seine Firefox-Konfig sehen.

Und nicht die Konfig von da im Keypass oder sowas. Hilft das weiter? War das richtig für SnapCraft mit C Groups? Die Anmerkung war gerade, dass da die SysMD-Komponenten auch benutzt werden.

Genau. Okay. Gut, dann vielen lieben Dank fürs Zuhören. Ich wünsche euch noch ganz viel Spaß auf der FrostCon.