Es gibt unter Linux kaum ein Jucken, was nicht auch gekratzt wird. Vor rund drei Wochen erklärte Canonical, dass die Ubuntu-Flavours kein Flatpak auf ihren Abbildern mehr ausliefern dürfen. Jetzt tritt Ubuntu Flatpak Remix als inoffizielles Derivat auf den Plan, um den Ubuntunutzern, die Flatpak bevorzugen und kein Snap mögen, eine einfache Möglichkeit bieten, dies zu erreichen.
Flatpak integriert
Verantwortlich für Flatpak Remix ist der YouTuber Jay LaCroix, der für den Kanal Learn Linux TV verantwortlich ist. Basierend auf Ubuntu 22.04 LTS bietet Flatpak Remix eine vorkonfigurierte Flatpak-Umgebung und verzichtet dafür komplett auf Snaps. Das bedeutet, dass Pakete wie Firefox, Thunderbird und aus Gründen der Aktualität auch LibreOffice als Flatpaks vorinstalliert sind. Der App-Store Gnome Software ist auf Flatpaks vorbereitet und Flathub ist eingebunden.
Mit Cubic erstellt
LaCroix erklärt, dass er Flatpak Remix erstellt hat, um für Canonicals verstärkte Hinwendung zum Snap-Paketformat eine Alternative zu bieten, die einfach zugänglich ist. Er hat das Derivat mit Cubic erstellt, einem einfachen Tool zum Editieren von ISO-Images. Über den Austausch von Snap gegen Flatpak gibt es keine weiteren Änderungen. Da er derzeit nicht wisse, ob Interesse an Flathub Remix besteht, gebe es derzeit keine weitere Infrastruktur außer der Möglichkeit, Bugs zu melden. Das könne sich bei entsprechendem Interesse aber ändern. Derzeit sei das Projekt im Alpha-Stadium und enthalte vermutlich Bugs. Es wird in der Anfangsphase nur als Torrent angeboten.
Vermutlich wird es Anwender geben, die den Flatpak Remix einer händischen Integration von Flatpak in Ubuntu vorziehen. Für mich besteht der größte mögliche Gewinn dieses Unterfangens darin, dass Interessierte sich das YouTube anschauen und dabei den Kanal Learn Linux TV kennenlernen, der eine große Zahl an Videos bietet, die Linux vom Einsteiger bis zum Profi abdecken.
Schön Distro für Leute die dieses Setup manuell machen würden 🙂 Das aus dem Artikel der typische und schon so viele Jahre anhaltende Glaubenskrieg entsteht, ist etwas schade. Das schöne ist doch, jeder kann nutzen was er mag! Und ich finde das niemand sich rechtfertigen muss dafür was er einsetzt am Desktop! Und wenn man eh etwas nicht mag und nie einsetzen wird, ergibt es wenig Sinn es zu kritisieren……. aber oft reicht ja das Wort “Canonical” in einem Artikel und es geht los xD wie viele Jahre geht diese Diskussion denn noch? xD Naja schönen Tag euch xD
Auch wenn Snap, Flatpak und AppImages aus Anwendersicht in erster Linie dazu da sind um Applikationen möglichst einfach zu installieren, gibt es aus Entwicklersicht einige wesentliche Unterschiede.
Einer der größten Unterschiede ist, dass Snap und Flatpak in einer Art Sandbox ausgeführt werden. Dies kann je nach Umsetzung der Sandbox einige Probleme verursachen. AppImages werden ohne Sandbox ausgeführt und dürfen somit alles, was auch der Benutzer darf, unter dem die Applikation gestartet wurde.
Eines der bekanntesten Beispiele für Probleme mit der Sandbox von Snap ist der Browser Firefox. Erst in aktuellen Versionen ist es möglich, dass Firefox (Snap Version) mit Passwortmanagern kommunizieren darf (wenn auch weiterhin mit Einschränkungen).
Als Entwickler bietet Snap eine einfache Infrastruktur, die sich um die Erstellung der Snaps kümmert. Darüberhinaus wird regelmäßig auch ein Security Check durchgeführt der den Entwickler informiert, wenn das erstellte Snap Sicherheitslücken beinhaltet. Um eine neue Version zu erstellen, muss nur auf Github in den Hauptbranch Code gepusht werden. Somit ist die Entwicklung sehr einfach und bequem.
Flatpak bietet zwar auch eine zentrale Infrastruktur, die als Entwickler genutzt werden kann, jedoch ist die Integration (aus meiner Sicht) nicht so einfach wie bei Snap. Hauptunterschied ist, dass das zentrale Github Repo geclont werden muss und die Änderungen, die für die Erstellung der eigenen Applikation notwendig sind, als Pull-Request gemacht werden müssen. Auch die Erstellung selber ist komplett anders als bei Snap. Flatpaks werden in mehreren Schritten erstellt. Im ersten Schritt werden sämtliche Abhängigkeiten definiert. Diese werden auch auf Integrität geprüft, was die Erstellung von reproduzierbarer Software ermöglicht. Bei jedem Update müssen somit sämtliche Abhängigkeiten überprüft werden und entsprechend angepasst werden.
Für AppImages gibt es keinen zentralen Anbieter, der die Erstellung übernimmt. Somit muss der Entwickler selber sicherstellen, dass die Software richtig gebaut und verteilt wird. Dafür sind AppImages aber am einfachsten zu verteilen, weil diese nur ausführtbar gemacht werden müssen. Eventuell muss fuse installiert werden, was aber durch das Entpacken des AppImages ebenfalls vermieden werden kann.
Aus Entwicklersicht stellen Snap und AppImages die einfachsten Möglichkeiten dar meine Software zu verteilen. Flatpak würde ich gerne einsetzen, jedoch ist der Aufwand für die Wartung der Flatpaks wesentlich höher, weshalb ich bisher noch keine produktive Version als Flatpak veröffentlicht habe.
Für mich war es damals als eine Abschätzung, wie ich meine (Frei-)Zeit am besten Nutze um meine Software zu deployen. Bisher war auch der Aufwand für die Erstellung von Packages für Debian, damit meine Software direkt über den Package-Manager von Debian/Ubuntu installiert werden kann, nicht verhältnismäßig.
Ich finde es gut, dass es mehrere Formate gibt, weil jedes Format unterschiedliche Funktionen und Einsatzzwecke bietet.
Flatpak gewährleistet, dass eine bestimmte Version auch mit den Quellen übereinstimmt, aus denen es erstellt wurde.
Snap ist dafür einfacher umzusetzen und leichter zu aktualisieren, was wiederum schnellen Sicherheitsupdates zugute kommt.
AppImages können wiederum einfach auf jedem System ausgeführt werden, das mit dem AppImage kompatibel ist.
Da bist Du aber dennoch begrenzt, denn es gibt jede menge Menschen, die weder snap noch flatpack haben wollen. Ausserdem sehe ich da eine gewisse Anhängikeit.
Für mich wären beide keine Lösung. Aber das ist Ansichtssache.
Ist es nicht das Einfachste die Pakete als source zu geben? Wer es haben möchte, der kann doch sehr schnell ein eigenes Paket bauen, ist doch kein Hexenwerk oder aber die sourcen selbst kompilieren.
Viele Anwender (mich eingeschlossen) bevorzugen fertige Software, die sie einfach ausführen können.
Mir persönlich ist es egal, wie die Software installiert wird. Ich bevorzuge AppImages, weil die fast überall ohne zusätzliche Abhängigkeiten ausführbar sind. Dadurch, dass ich mich mit Snap aus Entwicklersicht auskenne, habe ich auch kein Problem Snaps zu verwenden.
Ich finde Flatpak aus technischer Sicht interessant, aber bisher war es mir zu aufwendig – vermutlich muss ich mal etwas mehr Zeit investieren.
Falls sich jemand mit der Erstellung von Flatpaks auskennt, würde ich mich über Unterstützung freuen 😉
Repo zu meinem Flatpak Manifest für SSH-MITM: https://github.com/ssh-mitm/at.ssh_mitm.server
Ich stimme dir nur im ersten Punkt zu.
Ich möchte fertige Sofware einfach installieren und ausführen.
Aber eben nicht über snap, flatpack und appimage.
Snap absolut gar nicht.
Flatpack und appimage nur zum Testen.
Und hier ist mir sogar appimage lieber.
Denn das ist ruckzuck herunter geladen, ausgeführt und wieder gelöscht.
Flatpack dauert ewig zum installieren.
Und snap geht aus bekannten Gründen gar nicht.
Am liebsten ist mir eben übder den Paketmanager.
Der hat sich bewehrt und funktioniert seit Jahren.
Wenn ich die Nachteile von sanp, flatpack und appimage dauerhaft möchte, und ich sas “Feeling” dieser Instalationen möchte, dann nehm ich das Original. Und das ist Windows.
Da wir aber unter Linux sind, ist das einzig wahre der Paketmanager.
Nichts besseres, sicheres und perfomanteres.
Und was an einem spec files so schwierig sein soll erschließt sich mir auch nicht.
Einmal erstellt, ist im normalfall schnell ein Update erstellt.
Das einzige was öfters Schwirigkeiten macht ist die mangelende Dokumentation der Entwickler.
Deine Argumentation verstehe ich. Wenn möglich ist der Package Manager am zuverlässigsten und ich verwende ihn in 90% der Fälle.
Ab und zu gibt es aber Software, die nicht als Deb oder RPM verfügbar ist. Das sind dann die Fälle wo msn Alternativen braucht.
Man muss aber auch bedenken, dass die Repos und Packages gewartet werde müssen und das kostet Zeit und Geld. Nicht für jede Applikation gibt es Maintainer, die die Integration in sämtliche Distris übernehmen können.
Hier ist die Stärke aber auch gleichzeitig das Problem bon Snap/Flatpak/AppImage. Die Arbeit kann vom Entwickler selber übernommen werden und es läuft auf den meisten Linux Distris ohne Probleme. Jedoch ist dann auch der Entwickler für die Aktualisierung zuständig, was leider nicht von jedem im entdprechendfm Ausmaß gemacht wird
Aber auch klassische Package Manager haben Probleme.
Bei einer Distri mit Rolling Release muss die Software regelmäßig getestet werden, was viel Zeit (und Geld) kostet. Da kann es schon passieren dass kurzfristig etwas nicht geht.
Bei Releases, wie es Debian und Ubuntu haben, darf der Aufwand auch nicht unterschätzt werden. Sicherheitslücken müssen in alten Versionen gefixt werden und das mitunter über einige Jahre. Aus diesen Gründen werden irgendwann virle Applikationen offiziell nicht mehr mit Sicherheitsupdates versorgt, obwohl das EoL des Releases noch nicht erreicht wurde.
Es ist somit ein Kompromiss was man Verwendet und ich finde es gut, dass es möglichst viele Alternativen gibt.
Also ich persölich rate jedem nicht snap und flatpack zu verwenden.
AppImage muss man sich mal damit befassen, was das im Hintergrund so treibt.
Ich finde , das ich wissen muss, was mein System macht. Deswegen verwende ich auch nur selbst eine ganz kleine Distribution, wo aus den sourcen jedes Programm compiliert und installiert wird.
Bei KundenProjekten prinzipiell Debian aber auch ohne snap und Flatpack, sonst erlischt von meiner Seiter her der freie der support und ab da muss er gekauft werden.
Schon mal eine PKGBUILD erstellt?
Da das Kompilieren nicht immer ganz einfach ist, verfolge ich unter anderem auch den Ansatz deb2snap und deb2flatpak. Ein Snap-Paket aus einem Ubuntu-Paket zu erst erstellen, war relativ einfach. Schwieriger war das mit einem Flatpak-Paket. Dafür musste ich eine eigene Runtime mit debootstrap erstellen. Im Forum https://discourse.flathub.org/ habe ich dazu etwas geschrieben (ffDiaporama in the sandbox).
Das verstehe ich nun gar nicht.
Ich kenne zwar die Programme nicht aber ein dep2flatpack sugeriert mir, da wird aus einem Debian paket ein flatpack erstellt.
Das bedeuet es gibt schon ein Paket im Paketmanager. Für was brauch ich dann noch ein flatpack?.
Ich verwende das “Ubuntu-Paket” über Flatpak unter Arch Linux, da ich mit dem gleichen Paket aus dem AUR nicht zufrieden bin. Das “Ubuntu-Paket” läuft besser.
Ubuntu ist auch nicht mehr das, was es mal war.
Aber ein Hoch auf Debian, slack, gentoo etc. und die vielen distributionen ausserhalb des ubuntu-Umfeldes.
https://www.youtube.com/watch?v=3YHIa3le_1k
Die ewige Diskussion um das was besser ist lähmt extrem, vor allem weil viel im Netz verbreitet ist was dem persönlichen Befindlichkeiten entspringt.
Die meisten Linuxdistributionen sind aus persönlichem Empfinden entstanden und entstehen und genau das ist doch das, was Linux aus macht (schon immer). Deswegen hat sich die Linuxgemeinde auch niemals vereinnahmen lassen.
Einheitsbrei ist nicht und wird es hoffentlich niemals geben.
Das eine hat nichts mit dem anderen zu tun. Viel mehr meinte ich die Fehlinformationen die seit Jahren zum Thema Snap verbreitet werden und immer wieder den angeblichen Vorteil von Flatpak in den Raum stellen.
Das Video zeigt diese Fehlinterpretation seitens der Community auf und DT trifft den Nagel genauest auf den Kopf.
Für mich haben Beide keinerlei Vorteile. Mir kommt das Zeugs nicht ins System.
Das Video geht mit keinem Wort auf die Lizezproblematik ein. Der Snap-Store kann nur von Canonical betrieben werden. Ich benutze keine Techniken die mich von einem einzigen Anbieter abhängig machen.
Das ist doch nichts schlechtes? Das heisst ja nicht das man Snaps nur vom Store herunterladen kann oder das man gezwungen wird Ubuntu zu nutzen. Aber für Entwickler / Anbieter von Software ergibt sich ein lukrativer Marktplatz, genau wie Google-Play, Apple-Store auf dem Smartphone. Alles besser als vorher wie ich finde.
Ich sehe auch Google und Apple sehr kritisch. Ein Marktplatz kann etwas gutes sein, aber wenn nur einer darüber herrscht, dann ist das kein fairer und offener Austausch mehr.
Doch geht er schon und er geht sogar noch weiter indem er erklärt wo Snaps Ursprung liegt und wo vor allen der administrative Unterschied liegt.
Keiner ist gezwungen es zu verwenden, Administratoren der Canonical Infrastruktur wissen sehr genau warum sie die Plattform nutzen.
Es ist eine Infrastrukturfrage wie sie auch bei RHEL vorhanden ist und erweitert für den 0815er eben als Plattform dient sein System ensure zu halten. Closed Source ist auch in der Linuxwelt sehr verbreitet und da beißt sich die Katze keinen Schwanz ab… Gesehen am Beispiel Davinci Resolve, LWKS uvm.
Was soll das Schwachsinnsargument: “Keiner ist gezwungen es zu verwenden”. Du wirst ja auch nicht dazu gezwungen weiter zu leben und trotzdem kann es Umstände geben, die du lieber vermieden hättest.
Genauso ist die Anmerkung: “Dient [dazu} sein System ensure zu halten”
eine hohle Phrase, wie auch die Feststllung, dass es in der Linuxwelt auch “Closed Source” gibt kein Argument für oder gegen irgendwas ist.
Canonical baut mit snap ein walled garden und ich bin nicht bereit in diesen Garten der hohlen Versprechungen einzutreten.
Wenn nichts mehr kommt wird man frech und unfreundlich?
Schon mehrfach beobachtet dient es zur Selbstdarstellung und wird somit Disqualifizierend.
gelesen eventuell, verstanden eher weniger.
Gute Grüße
Canonical bietet die Möglichkeit einen eigenen Snap Store zu betreiben. Dieser kann sogar komplett offline verwendet werden und hat damit keine Verbindung mehr zu dem von Canonical betriebenen Snap Store.
https://docs.ubuntu.com/snap-store-proxy/en/airgap
Theoretisch ist es somit möglich einen eigenen App Store für Snap zu betreiben.
Es hat auch schon Bestrebungen gegeben eine Alternative für den Snap Store von Canonical zu entwickeln: https://github.com/freetocompute/kebe
Anscheinend war das Interesse an einer unabhängigen Alternative nicht so groß, dass das Projekt langfristig weiterverfolgt wurde.
Man muss aber auch bedeneken, dass ein alternativer Snap Store vermutlich nur von sehr wenigen Serverbetreibern auch installiert und gewartet wird. Man kann ihr eventuell einen Vergleich zu Googles Play Store und F-Droid (und anderen kommerziellen App Stores) ziehen. Für viele Anwender ist es keine Alternative F-Droid zu verwenden, weil sie froh sind, dass der Google Play Store funktioniert. Bei den anderen App-Stores ist es vermutlich ähnlich und diese ziehlen dann auch eher auf die eigenen Geräte (Amazon, Huawei, …) ab.
F-Droid ist hier eventuell auch ein sehr gutes Beispiel, weil es Open Source ist und somit von jedem installiert werden kann. Dennoch gibt es sehr wenig Server, die eigne F-Droid Repos zur Verfügung stellen: https://f-droid.org/docs/Setup_an_F-Droid_App_Repo/
Bei Android Geräten macht es eventuell noch Sinn einen eigenen App-Store für die einfache Installation anzubieten, weil dieser in der F-Droid App einfacher zu integrieren ist. Außerdem liest es sich besser, wenn man Apps über einen App Store installieren kann und nicht umbedingt Sicherheitsfunktionen von Android deaktivieren muss um eine App Side-Loaden zu können (Installation aus nicht vertrauenswürdigen Quellen).
Unter Linux gibt es wenstlich mehr Möglichkeiten eine Software zu installieren. Wenn diese nicht umbedingt im Repo der eigenen Distri zu finden ist, kann man relativ einfach eine Dep/Rpm Datei downloaden und installieren oder alternativ Snap/Flatpak/AppImage verwenden. Wer möchte, kann natürlich auch die Software aus den Sourcen kompillieren, sofern dies möglich ist 😉
Die Anwender suchen sich dann relativ schnell die Lösung, die ihnen am besten passt.
Man kann somit nicht die App Stores von mobilen Geräten mit den von Snap vergleichen. Sollte es tatsächlich den Bedarf für selbstgehostete Snap Stores geben, dann würden die entsprechenden Projekte, wie das bereits erwähnte Kebe, weiterentwickelt werden.
Es steht somit jedem Frei sich an der Entwicklung eines alternativen Snap Stores zu beteiligen und wenn das Interesse groß genug ist, wird es in Zukunft auch einfachere Möglichkeiten der Integration in den bestehenden Snap Client geben.
Danke für die Infos und die Links. Dass Canonical auch anderen die Möglichkeit bietet, einen eigenen Snap-Store zu betreiben war mir neu.
Ich denke aber, dass es Canonical trotzdem gelingt, über das snap Format ein gewisses Monopol auszuüben.
Das Linux-System das ich bevorzuge lebt davon, dass einzelne Konzerne kein Übergewicht bekommen und Techniken allgemein verfügbar bleiben.
Das wird nur klappen, solange es noch das Maintainment von einzelnen Paketen gibt. Snaps mögen ihre spezifischen Vorteile haben, ob die einsetzende Kommerzialisierg jedoch in der Lage ist ein freies System aufrecht zu erhalten, halte ich für mehr als fragwürdig.