From 186d594706db92550f8b5ccbd3a10858b54a3876 Mon Sep 17 00:00:00 2001 From: Boris Kraut Date: Mon, 24 Mar 2025 21:15:28 +0100 Subject: [PATCH] Fix textwidth --- 2025-02-08_Fedora_und_Flatpak.eml | 232 ++++++++++++++++++++++++++---- 1 file changed, 204 insertions(+), 28 deletions(-) diff --git a/2025-02-08_Fedora_und_Flatpak.eml b/2025-02-08_Fedora_und_Flatpak.eml index 3d60506..22e3b26 100644 --- a/2025-02-08_Fedora_und_Flatpak.eml +++ b/2025-02-08_Fedora_und_Flatpak.eml @@ -10,37 +10,193 @@ Content-Transfer-Encoding: 8bit # Fedora und Flatpak -Für die Dauer meines berufbegleitenden Studiums war es nötig, einen Windows-Laptop zur Verfügung zu haben. Daher habe ich mir damals ein brandneues Thinkpad T480 von Lenovo gekauft – technisch in vielerlei Hinsicht und unter den negativen Vorzeichen des Marktes aka aktueller Trends eines der besten Notebooks, die es zu der Zeit gab. Und auch heute noch verspüre ich kein Bedürfnis mir ein neueres Geräte anzuschaffen. - -Selbst Windows hat sich auffällig stabil angefühlt und stand einem wenig im Weg rum, auch wenn es abseits der studiumsbedingten Zwangsanwendungen nicht mehr als ein aufgedunsener Windowmanager für Thunderbird, Firefox, Zettlr und TexStudio war. Auf der Kommandozeile versorgte micht Git for Windows mit einem akzeptablen Minimalsatz an Anwendungen, sodass ich viele meiner Helfer-Skripte direkt oder mit wenig Portierungsaufwand weiternutzen konnte. Alles weitere fand sowieso remote per SSH statt – ob auf einen Linuxserver, auf einer lokalen VM oder auf der Termux-Installation eines Android-Smartphones. - -Kurz gesagt: Abseits einiger moralischer Bedenken gab es kein Grund irgendetwas an meinem Setup zu ändern. Ich spielte sogar mal wieder mit der Hoffnung bzw. dem Gedanken, dass die Konvergenz von Smartphone, PC und Tablet doch so greifbar nahe ist, dass ich nach einem irreparablen, technischen Defekt gar kein Notebook mehr bräuchte und dass Windows so wie es war auch bis dahin "gut genug" wäre. Ob diese Prämisse diesesmal wahr wird, muss sich noch zeigen. Schon seit ca. 2013 warte ich ja darauf und trotz USB-C (AltMode, OTG usw.) und Android-Desktop-Mode sind wir jetzt in 2025 immer noch nicht so weit. Wie dem auch sei, ich schweife mal wieder ab. - -Leider hatte sich meine Hoffnung, nicht unnötige Lebenszeit in die Änderung der Softwarestacks stecken zu müssen, nicht erfüllt. Microsoft hatte und hat es sich in den Kopf gesetzt, Windows 11, kürzere Nutzungszyklen und vor allem Services zu pushen. Natürlich muss dazu der "Nutzer" bzw. der "Benutzte" immer weiter gegängelt und seine Daten abgeschorchelt werden. Immer wieder hat sich ungewollt Werbung in meine Windows-Installation geschmuggelt – Bing-Wetter in der Taskbar, Seelenfänger-Apps im Startmenü und großflächig Windows11-Update-"Hinweise" mit allen Dark-Patterns die man von dubiosen Webseiten (oder jetzt Apps) und Scammern kennt: - -Hey, Microsoft, ich finde auch das System- und Softwareaupdates wichtig sind. Aber wenn ich schon vor dem Update mitgeteilt habe, dass ich bei Windows 10 bleiben will, indem ich nicht den farbigen Wechselknopf, sondern den grauen "alles soll so bleiben"-Knopf gedrückt habe, dann respektiert das. Ich werde einen Grund haben, vermutlich, weil ihr entweder kein interessantes Produktupgrade bietet oder weil ich gerade etwas zu tun habe, ich mit dem Geräte gerade arbeite. Glaubt ihr wirklich, dass ein solcher Nutzer es gut findet, wenn er nach dem Update mit einer bildschirmfüllenden, mehrseitigen Werbebotschaft zu den "Vorzügen" von Windows 11 beglückt wird, durch die er sich Durchklicken muss (ohne auf die versteckten Tretminen-Upgrade-Knöpfe zu kommen)? Denkt ihr wirklich, dass mich ein solches Verhalten nicht noch mehr anwidern wird? - -Die Antwort ist klar, Microsoft ist es scheissegal, was der Nutzer will. Sie wollen, dass Windows 11 installiert wird. Und ist man nicht willig, so braucht man Gewalt… und ein unnötiges Support-Ende des "Für Immer"-Windows (10). Wie dem auch sei, ein Wechsel würde kommen, also dann lieber geplant und nach meinen Regeln. +Für die Dauer meines berufbegleitenden Studiums war es nötig, einen +Windows-Laptop zur Verfügung zu haben. Daher habe ich mir damals ein +brandneues Thinkpad T480 von Lenovo gekauft – technisch in vielerlei +Hinsicht und unter den negativen Vorzeichen des Marktes aka aktueller +Trends eines der besten Notebooks, die es zu der Zeit gab. Und auch +heute noch verspüre ich kein Bedürfnis mir ein neueres Geräte +anzuschaffen. + +Selbst Windows hat sich auffällig stabil angefühlt und stand einem +wenig im Weg rum, auch wenn es abseits der studiumsbedingten +Zwangsanwendungen nicht mehr als ein aufgedunsener Windowmanager für +Thunderbird, Firefox, Zettlr und TexStudio war. Auf der Kommandozeile +versorgte micht Git for Windows mit einem akzeptablen Minimalsatz an +Anwendungen, sodass ich viele meiner Helfer-Skripte direkt oder mit +wenig Portierungsaufwand weiternutzen konnte. Alles weitere fand +sowieso remote per SSH statt – ob auf einen Linuxserver, auf einer +lokalen VM oder auf der Termux-Installation eines Android-Smartphones. + +Kurz gesagt: Abseits einiger moralischer Bedenken gab es kein Grund +irgendetwas an meinem Setup zu ändern. Ich spielte sogar mal wieder +mit der Hoffnung bzw. dem Gedanken, dass die Konvergenz von +Smartphone, PC und Tablet doch so greifbar nahe ist, dass ich nach +einem irreparablen, technischen Defekt gar kein Notebook mehr bräuchte +und dass Windows so wie es war auch bis dahin "gut genug" wäre. Ob +diese Prämisse diesesmal wahr wird, muss sich noch zeigen. Schon seit +ca. 2013 warte ich ja darauf und trotz USB-C (AltMode, OTG usw.) und +Android-Desktop-Mode sind wir jetzt in 2025 immer noch nicht so weit. +Wie dem auch sei, ich schweife mal wieder ab. + +Leider hatte sich meine Hoffnung, nicht unnötige Lebenszeit in die +Änderung der Softwarestacks stecken zu müssen, nicht erfüllt. +Microsoft hatte und hat es sich in den Kopf gesetzt, Windows 11, +kürzere Nutzungszyklen und vor allem Services zu pushen. Natürlich +muss dazu der "Nutzer" bzw. der "Benutzte" immer weiter gegängelt und +seine Daten abgeschorchelt werden. Immer wieder hat sich ungewollt +Werbung in meine Windows-Installation geschmuggelt – Bing-Wetter in +der Taskbar, Seelenfänger-Apps im Startmenü und großflächig +Windows11-Update-"Hinweise" mit allen Dark-Patterns die man von +dubiosen Webseiten (oder jetzt Apps) und Scammern kennt: + +Hey, Microsoft, ich finde auch das System- und Softwareaupdates +wichtig sind. Aber wenn ich schon vor dem Update mitgeteilt habe, dass +ich bei Windows 10 bleiben will, indem ich nicht den farbigen +Wechselknopf, sondern den grauen "alles soll so bleiben"-Knopf +gedrückt habe, dann respektiert das. Ich werde einen Grund haben, +vermutlich, weil ihr entweder kein interessantes Produktupgrade bietet +oder weil ich gerade etwas zu tun habe, ich mit dem Geräte gerade +arbeite. Glaubt ihr wirklich, dass ein solcher Nutzer es gut findet, +wenn er nach dem Update mit einer bildschirmfüllenden, mehrseitigen +Werbebotschaft zu den "Vorzügen" von Windows 11 beglückt wird, durch +die er sich Durchklicken muss (ohne auf die versteckten +Tretminen-Upgrade-Knöpfe zu kommen)? Denkt ihr wirklich, dass mich ein +solches Verhalten nicht noch mehr anwidern wird? + +Die Antwort ist klar, Microsoft ist es scheissegal, was der Nutzer +will. Sie wollen, dass Windows 11 installiert wird. Und ist man nicht +willig, so braucht man Gewalt… und ein unnötiges Support-Ende des "Für +Immer"-Windows (10). Wie dem auch sei, ein Wechsel würde kommen, also +dann lieber geplant und nach meinen Regeln. ## Distribution -Die Linux-Distribution der Wahl ist für mich seit langem Alpine Linux: ein auf *musl libc* und *busybox* aufbauendes, schnell bootendes CLI-Live-System, das manuell oder mit einem an OpenBSD erinnerndem Frage-Antwort-Setup-Skript alle wesentlichen Basis-Konfigurationen abdeckt, die für eine Installation nötig sind. Fokus liegt generell auf Kompaktheit, Einfachheit und Sicherheit. Die Philosophie ist, dass eine maßgeschneiderte Lauftzeitumgebung nicht nur die Angriffsfläche verkleinert, sondern dass ein solches System auch noch gut zu verstehen ist: je mündiger der Nutzer, desto sicherer das System. Ebenfalls sprechen mich die leicht konfigurierbaren Betriebs- bzw. Installationsmodi sehr an. Hier wird zwischen *diskless* , *data disk* und *system disk* unterschieden, wobei der letztgenannte eine klassisches Installation ist, die beiden anderen aber das System von einem idealerweisen regelmäßig aktualisiertem, unveränderlichem Bootmedium starten und für die Dauer der Sitzung im RAM halten. Das Problem ist, dass ich hier noch nie ein grafisches System zusammengebaut hatte und eigentlich keine Zeit für Technik-Spielereien hatte. Auch wenn ich vorerst von dem Thema Abstand nahm, sollte später auf jeden Fall ein schneller wechsel auf Alpine möglich sein. - -Das Konzept von *diskless* Systemen mit verschiedenen Datenpersistenz-Möglichkeiten habe ich früher immer wieder ausprobiert. Von daher bin ich zunächst zu meinem alten Bekannten TinyCore Linux weitergezogen, das eigentlich die Rolle einer reinen Laufzeitumgebung für audiovisuelle Anwendungen schon damals sehr gut erfüllt hat. Leider ist die IT-Welt komplexer geworden und ich habe TC nicht zum Zusammenspiel mit UEFI und SecureBoot bekommen. Prinzipiell sind die Installationsdateien reine ISO-Images, müssen also vor dem Schreiben auf einen USB-Stick mit `isohybrid` angepasst werden. Eigentlich sollte dort der Schalter `--uefi` auch das Booten von UEFI-Systemen erlauben, tat es aber bei mir nicht. Da inzwischen auch mein Windows nicht mehr vorhanden war, habe ich einige Abende damit verbracht auf meinem Android-Smartphone ein Alpine-Image auf den – ja, Singular… irgendwie ist die Zeit der USB-Sticks auch schon lange vorbei – USB-Stick zu kopieren, damit das Thinkpad zu starten, im Live-System das TC-Image vorzubereiten und auf den selbigen Stick zu schreiben. Der Erfolg stellte sich dabei trotz verschiedener UEFI- und SecureBoot-Einstellungen nicht ein… Wie war das? Keine Zeit für Technik-Spielereien… - -Kurzentschlossen zumindest irgendein lauffähiges System zu haben, wendete ich mich den üblichen bekannten Verdächtigen a la Ubuntu, Debian, Suse oder Fedora zu. Allerdings war auch hier nicht alles so perfekt, wie man es erwarten würde. Am Ende scheiterten alle an einer halbautomatischen Installation auf der SSD des Thinkpads: sie blieben hängen oder brachen mit nichtssagenden Fehlermeldungen ab. Die Lösung brachte manuelles Partitionieren und inzwischen vermute ich einen Hardware-Defekt. Somit ist es gut, dass ich mich zum Wechsel auf Linux durchgerungen habe und das Problem nicht unbemerkt vor sich hin gammelte, bis es zu einem schleichenden Datenverlust bis in die Sicherungskopien hinein gekommen wäre. Trotzdem hätte die Installationserfahrung eine andere sein sollen, zumindest bessere Fehlermeldungen wären – wie immer – hilfreich gewesen. Interessant wäre für mich auch, wie eine Windows-Neuinstallation mit der SSD umgegangen wäre, aber auch für diese Frage, fehlte leider die Zeit. - -Am Ende stand ein System, Fedora um genau zu sein, mit dem ich zumindest wieder halbwegs arbeiten konnte. Sicherlich ein Fortschritt, wenn auch ein sehr kleiner. Der Plan mit TC oder Alpine ist aber nur aufgeschoben! +Die Linux-Distribution der Wahl ist für mich seit langem Alpine Linux: +ein auf *musl libc* und *busybox* aufbauendes, schnell bootendes +CLI-Live-System, das manuell oder mit einem an OpenBSD erinnerndem +Frage-Antwort-Setup-Skript alle wesentlichen Basis-Konfigurationen +abdeckt, die für eine Installation nötig sind. Fokus liegt generell +auf Kompaktheit, Einfachheit und Sicherheit. Die Philosophie ist, dass +eine maßgeschneiderte Lauftzeitumgebung nicht nur die Angriffsfläche +verkleinert, sondern dass ein solches System auch noch gut zu +verstehen ist: je mündiger der Nutzer, desto sicherer das System. +Ebenfalls sprechen mich die leicht konfigurierbaren Betriebs- bzw. +Installationsmodi sehr an. Hier wird zwischen *diskless* , *data disk* +und *system disk* unterschieden, wobei der letztgenannte eine +klassisches Installation ist, die beiden anderen aber das System von +einem idealerweisen regelmäßig aktualisiertem, unveränderlichem +Bootmedium starten und für die Dauer der Sitzung im RAM halten. Das +Problem ist, dass ich hier noch nie ein grafisches System +zusammengebaut hatte und eigentlich keine Zeit für Technik-Spielereien +hatte. Auch wenn ich vorerst von dem Thema Abstand nahm, sollte später +auf jeden Fall ein schneller wechsel auf Alpine möglich sein. + +Das Konzept von *diskless* Systemen mit verschiedenen +Datenpersistenz-Möglichkeiten habe ich früher immer wieder +ausprobiert. Von daher bin ich zunächst zu meinem alten Bekannten +TinyCore Linux weitergezogen, das eigentlich die Rolle einer reinen +Laufzeitumgebung für audiovisuelle Anwendungen schon damals sehr gut +erfüllt hat. Leider ist die IT-Welt komplexer geworden und ich habe TC +nicht zum Zusammenspiel mit UEFI und SecureBoot bekommen. Prinzipiell +sind die Installationsdateien reine ISO-Images, müssen also vor dem +Schreiben auf einen USB-Stick mit `isohybrid` angepasst werden. +Eigentlich sollte dort der Schalter `--uefi` auch das Booten von +UEFI-Systemen erlauben, tat es aber bei mir nicht. Da inzwischen auch +mein Windows nicht mehr vorhanden war, habe ich einige Abende damit +verbracht auf meinem Android-Smartphone ein Alpine-Image auf den – ja, +Singular… irgendwie ist die Zeit der USB-Sticks auch schon lange +vorbei – USB-Stick zu kopieren, damit das Thinkpad zu starten, im +Live-System das TC-Image vorzubereiten und auf den selbigen Stick zu +schreiben. Der Erfolg stellte sich dabei trotz verschiedener UEFI- und +SecureBoot-Einstellungen nicht ein… Wie war das? Keine Zeit für +Technik-Spielereien… + +Kurzentschlossen zumindest irgendein lauffähiges System zu haben, +wendete ich mich den üblichen bekannten Verdächtigen a la Ubuntu, +Debian, Suse oder Fedora zu. Allerdings war auch hier nicht alles so +perfekt, wie man es erwarten würde. Am Ende scheiterten alle an einer +halbautomatischen Installation auf der SSD des Thinkpads: sie blieben +hängen oder brachen mit nichtssagenden Fehlermeldungen ab. Die Lösung +brachte manuelles Partitionieren und inzwischen vermute ich einen +Hardware-Defekt. Somit ist es gut, dass ich mich zum Wechsel auf Linux +durchgerungen habe und das Problem nicht unbemerkt vor sich hin +gammelte, bis es zu einem schleichenden Datenverlust bis in die +Sicherungskopien hinein gekommen wäre. Trotzdem hätte die +Installationserfahrung eine andere sein sollen, zumindest bessere +Fehlermeldungen wären – wie immer – hilfreich gewesen. Interessant +wäre für mich auch, wie eine Windows-Neuinstallation mit der SSD +umgegangen wäre, aber auch für diese Frage, fehlte leider die Zeit. + +Am Ende stand ein System, Fedora um genau zu sein, mit dem ich +zumindest wieder halbwegs arbeiten konnte. Sicherlich ein Fortschritt, +wenn auch ein sehr kleiner. Der Plan mit TC oder Alpine ist aber nur +aufgeschoben! ## Flatpaks, Snaps oder AppImages -Die Anwendungen selbst kamen früher als Binärpakete von der Distribution oder wurden – ggf. mit mehr oder weniger mächtigen Hilfsskripten – aus den Quellen gebaut. Als Jugendlicher dachte ich eigentlich, dass wir irgendwann keine Binaries mehr nötig haben, weil Computer so schnell werden, dass man sowieso alles in kürzester Zeit und angepasst auf das eigene System kompilieren kann, aber ganz so ist es in den aller meisten Fällen nicht gekommen. Ein wohlüberlegtes Basissystem lässt sich tatsächlich in erträglicher Zeit selbst kompilieren, aber da mit der Mächtigkeit der Rechenmaschinen auch die Komplexität der Anwendungen gestiegen ist, lässt sich das nicht für das komplette System sagen. Jeder, der mal versucht hat Firefox o.ä. von Hand zu erstellen, wird das nachfühlen können: teils ist die Komplexitätsdichte der nötigen Toolchain(s) und Abhängigkeiten schon so hoch, dass man Stunden damit verbringen kann sich Schritt für Schritt vorzutasten. - -Auf der Haben-Seite sind wir aber mit reproduzierbaren Builds deutlich weitergekommen, d.h. es können von mehreren unabhängigen Stellen Binaries erstellt werden, die identisch sind. Man muss also nicht mehr dem einen Herausgeber vertrauen, sondern kann die Vertrauenslast auf mehrere Schultern verteilen. Nicht ideal, aber ein tragbarer Ersatz, wenn der Weg aus den Quellen ungangbar scheint. - -Auch beim Kampf der Paketformate sind wir weiter. Statt *.deb und *.rpm gibt es nun noch zig weitere Kandidaten in der Arena, aber es haben sich auch Paketformate hervorgetan, die distributionsunabhängig funktionieren soll(ten): Flatpaks, Snaps und AppImages. Früher stand ich diesen Paketierungslösung ziemlich kritisch gegenüber, sind sie doch wenig an das Basissystem angepasst, bringen viele Abhängigkeiten pro Paket in mehrfacher Ausführung mit sich und haben einen riesigen Overhead – sei es an Dateigröße, RAM-Bedarf oder Startgeschwindigkeit. Meine Erfahrungen aus der Android bzw. F-Droid-Welt auf der einen Seite und Container-Lösungen auf der anderen, haben mich aber etwas milder gestimmt und ich sehe sie durchaus als gute Ergänzung: Die Isolation von Anwendungen untereinander und gegenüber des Systems ist ein Sicherheitsgewinn, die Vereinheitlichung – wenn es da nicht mal wieder zig verschiedene Lösungen gäbe… – erlaubt es schnell auf einem neuen System arbeitsfähig zu werden. Meine Trennung habe ich zwischen GUI und CLI gezogen. Letzteres kommt über das Paketmanagement der Distribution, dann kann ich diese zu einem beliebigen Zeitpunkt (auch später) so wählen, dass sie meinen Ansprüchen entspricht und ich sie verstehe, während ersteres mir all das in einfacher und gleichbleibender Weise bringt, was ich an Kompexität nicht mehr verstehen kann, aber das ich in der aktuellen Zeit trotzdem benötige. - -Welches der drei Format jetzt das beste ist, kann ich nicht sagen. Mit AppImages habe ich immer mal wieder gearbeitet: ausführbare One-Click-Images mit allen Abhängigkeiten und Bibliotheken. Beim Starten wird das interne Dateisystem der Anwendung gemountet und der entsprechende Einstiegspunkt ausgeführt. Größere Mankos hier waren die fehlende bzw. extern zu gewährleistende Isolierung vom Restsystem, die schlechte Integration in die existierende Umgebung und – je nachdem wen man fragt – dass die Images meist durch Dritte bzw. die Community erfolgt. Flatpak ist ein neuerer Ansatz, der u.a. durch RedHat unterstützt wird und sowohl die Integration wie auch die Isolation deutlich besser unterstützt. Für mich ausschlaggebend war aber die Sofwareverfügbarkeit. Neben Firefox und Thunderbird existieren Flatpaks für Signal und Zettlr – beides Anwendungen, die ich im zentralen AppImages-Store nicht gefunden habe. Zettlr gibt es zwar direkt von der Website der Entwickler als AppImage, aber für Signal musste ich mich durch mehrere verschiedene Anbieter durchkämpfen. Da ist Flatpak deutlich angenehmer: +Die Anwendungen selbst kamen früher als Binärpakete von der +Distribution oder wurden – ggf. mit mehr oder weniger mächtigen +Hilfsskripten – aus den Quellen gebaut. Als Jugendlicher dachte ich +eigentlich, dass wir irgendwann keine Binaries mehr nötig haben, weil +Computer so schnell werden, dass man sowieso alles in kürzester Zeit +und angepasst auf das eigene System kompilieren kann, aber ganz so ist +es in den aller meisten Fällen nicht gekommen. Ein wohlüberlegtes +Basissystem lässt sich tatsächlich in erträglicher Zeit selbst +kompilieren, aber da mit der Mächtigkeit der Rechenmaschinen auch die +Komplexität der Anwendungen gestiegen ist, lässt sich das nicht für +das komplette System sagen. Jeder, der mal versucht hat Firefox o.ä. +von Hand zu erstellen, wird das nachfühlen können: teils ist die +Komplexitätsdichte der nötigen Toolchain(s) und Abhängigkeiten schon +so hoch, dass man Stunden damit verbringen kann sich Schritt für +Schritt vorzutasten. + +Auf der Haben-Seite sind wir aber mit reproduzierbaren Builds deutlich +weitergekommen, d.h. es können von mehreren unabhängigen Stellen +Binaries erstellt werden, die identisch sind. Man muss also nicht mehr +dem einen Herausgeber vertrauen, sondern kann die Vertrauenslast auf +mehrere Schultern verteilen. Nicht ideal, aber ein tragbarer Ersatz, +wenn der Weg aus den Quellen ungangbar scheint. + +Auch beim Kampf der Paketformate sind wir weiter. Statt *.deb und +*.rpm gibt es nun noch zig weitere Kandidaten in der Arena, aber es +haben sich auch Paketformate hervorgetan, die distributionsunabhängig +funktionieren soll(ten): Flatpaks, Snaps und AppImages. Früher stand +ich diesen Paketierungslösung ziemlich kritisch gegenüber, sind sie +doch wenig an das Basissystem angepasst, bringen viele Abhängigkeiten +pro Paket in mehrfacher Ausführung mit sich und haben einen riesigen +Overhead – sei es an Dateigröße, RAM-Bedarf oder Startgeschwindigkeit. +Meine Erfahrungen aus der Android bzw. F-Droid-Welt auf der einen +Seite und Container-Lösungen auf der anderen, haben mich aber etwas +milder gestimmt und ich sehe sie durchaus als gute Ergänzung: Die +Isolation von Anwendungen untereinander und gegenüber des Systems ist +ein Sicherheitsgewinn, die Vereinheitlichung – wenn es da nicht mal +wieder zig verschiedene Lösungen gäbe… – erlaubt es schnell auf einem +neuen System arbeitsfähig zu werden. Meine Trennung habe ich zwischen +GUI und CLI gezogen. Letzteres kommt über das Paketmanagement der +Distribution, dann kann ich diese zu einem beliebigen Zeitpunkt (auch +später) so wählen, dass sie meinen Ansprüchen entspricht und ich sie +verstehe, während ersteres mir all das in einfacher und +gleichbleibender Weise bringt, was ich an Kompexität nicht mehr +verstehen kann, aber das ich in der aktuellen Zeit trotzdem benötige. + +Welches der drei Format jetzt das beste ist, kann ich nicht sagen. Mit +AppImages habe ich immer mal wieder gearbeitet: ausführbare +One-Click-Images mit allen Abhängigkeiten und Bibliotheken. Beim +Starten wird das interne Dateisystem der Anwendung gemountet und der +entsprechende Einstiegspunkt ausgeführt. Größere Mankos hier waren die +fehlende bzw. extern zu gewährleistende Isolierung vom Restsystem, die +schlechte Integration in die existierende Umgebung und – je nachdem +wen man fragt – dass die Images meist durch Dritte bzw. die Community +erfolgt. Flatpak ist ein neuerer Ansatz, der u.a. durch RedHat +unterstützt wird und sowohl die Integration wie auch die Isolation +deutlich besser unterstützt. Für mich ausschlaggebend war aber die +Sofwareverfügbarkeit. Neben Firefox und Thunderbird existieren +Flatpaks für Signal und Zettlr – beides Anwendungen, die ich im +zentralen AppImages-Store nicht gefunden habe. Zettlr gibt es zwar +direkt von der Website der Entwickler als AppImage, aber für Signal +musste ich mich durch mehrere verschiedene Anbieter durchkämpfen. Da +ist Flatpak deutlich angenehmer: ``` flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo @@ -50,7 +206,27 @@ flatpak install flathub org.signal.Signal flatpak install flathub com.zettlr.Zettlr ``` -Zu Snaps kan ich dagegen nicht viel sagen. Technisch sollen sie wohl ganz gut umgesetzt sein. aber Canonical als Entwickler forciert stark den eigenen zentralen und proprietären Store. Die einzige Erfahrung, die ich machen durfte, war ein ungefragtes Ersetzen meines nativen Firefox durch eine Snap-Variante. Unabhägig, ob das gut oder schlecht war, hätte das nicht ohne Benutzerbestätigung passieren dürfen. Von daher waren Snaps ganz unten auf der Liste und Flatpak hat eben erstmal das getan, was es sollte. - -Und funktioniert das auch? Nun, eigentlich ja, erstaunlich gut. Die Integration ins Look'n'Feel der Desktop-Umgebung ist gut, da habe ich auch bei nativen Paketen schon schlimmere Integrationen (z.B. Qt/GTK) gesehen. Die Isolation hat bei mir bei Signal sogar etwas zu gut funktioniert: Ich konnte keine Anhänge in meinem Benutzer-Ordner speichern, womit ich per se auch kein Problem hätte, wenn Signal dann wenigstens einen Fehler geworfen hätte. Aber viele Anhänge runterzuladen und dann festzustellen, dass der Speicherort leer ist, hätte auch ins Auge gehen können. Auch beim Upload von Daten zu OpenStreetMap kam es in Firefox zu Problemen, die ich jetzt erstmal auf das Sandboxing bzw. die Berechtigungen zurückführe. Unschön ist, dass hier die Anwendung so eingefroren ist, dass nichtmal ein `kill` bzw. `flatpak kill` gegriffen hat. Das muss ich im Auge behalten… und später mit mehr Zeit an die Sache rangehen. +Zu Snaps kan ich dagegen nicht viel sagen. Technisch sollen sie wohl +ganz gut umgesetzt sein. aber Canonical als Entwickler forciert stark +den eigenen zentralen und proprietären Store. Die einzige Erfahrung, +die ich machen durfte, war ein ungefragtes Ersetzen meines nativen +Firefox durch eine Snap-Variante. Unabhägig, ob das gut oder schlecht +war, hätte das nicht ohne Benutzerbestätigung passieren dürfen. Von +daher waren Snaps ganz unten auf der Liste und Flatpak hat eben +erstmal das getan, was es sollte. + +Und funktioniert das auch? Nun, eigentlich ja, erstaunlich gut. Die +Integration ins Look'n'Feel der Desktop-Umgebung ist gut, da habe ich +auch bei nativen Paketen schon schlimmere Integrationen (z.B. Qt/GTK) +gesehen. Die Isolation hat bei mir bei Signal sogar etwas zu gut +funktioniert: Ich konnte keine Anhänge in meinem Benutzer-Ordner +speichern, womit ich per se auch kein Problem hätte, wenn Signal dann +wenigstens einen Fehler geworfen hätte. Aber viele Anhänge +runterzuladen und dann festzustellen, dass der Speicherort leer ist, +hätte auch ins Auge gehen können. Auch beim Upload von Daten zu +OpenStreetMap kam es in Firefox zu Problemen, die ich jetzt erstmal +auf das Sandboxing bzw. die Berechtigungen zurückführe. Unschön ist, +dass hier die Anwendung so eingefroren ist, dass nichtmal ein `kill` +bzw. `flatpak kill` gegriffen hat. Das muss ich im Auge behalten… und +später mit mehr Zeit an die Sache rangehen. -- 2.39.5