GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Linux-Paketmanager im Vergleich – AppImage vs. Snap vs. Flatpak

Paketmanager Bereitstellung einer Möglichkeit zum Packen, Verteilen, Installieren und Verwalten von Apps in einem Betriebssystem. Mit modernen Desktop-, Server- und IoT-Anwendungen des Linux-Betriebssystems und den Hunderten von verschiedenen Distributionen, die es gibt, wird es notwendig, von plattformspezifischen Verpackungsmethoden zu plattformunabhängigen zu wechseln. Dieser Beitrag untersucht 3 solcher Tools, nämlich AppImage , Snap und Flatpak , die jeweils darauf abzielen, die Zukunft der Softwarebereitstellung und -verwaltung unter Linux zu sein. Am Ende fassen wir einige wichtige Erkenntnisse zusammen.

1. AppImage

AppImage folgt einem Konzept namens "Eine App =eine Datei" . Dies ist so zu verstehen, dass ein AppImage eine reguläre unabhängige „Datei“ ist, die eine Anwendung mit allem enthält, was sie zum Ausführen in dieser Datei benötigt. Einmal ausführbar gemacht, kann das AppImage wie jede Anwendung auf einem Computer ausgeführt werden, indem man einfach im Dateisystem des Benutzers darauf doppelklickt.[1]

Es ist ein Format zum Erstellen portabler Software für Linux, ohne dass der Benutzer die besagte Anwendung installieren muss. Das Format ermöglicht es den ursprünglichen Entwicklern der Software (Upstream-Entwicklern), eine plattform- und verteilungsunabhängige (auch als verteilungsunabhängige Binärdatei bezeichnete) Version ihrer Anwendung zu erstellen, die im Grunde auf jeder Linux-Variante läuft.

AppImage gibt es schon lange. Klick , ein Vorgänger von AppImage, wurde von Simon Peter erstellt im Jahr 2004. Das Projekt wurde 2011 eingestellt, nachdem es die Beta-Phase nicht bestanden hatte. Ein Projekt namens PortableLinuxApps wurde ungefähr zur gleichen Zeit von Simon erstellt und das Format wurde von einigen Portalen aufgegriffen, die Software für Linux-Benutzer anbieten. Das Projekt wurde 2013 erneut in seinen aktuellen Namen AppImage umbenannt und seit 2018 wird in GitHub (Projektlink) ein Repository mit den neuesten Änderungen desselben gepflegt.[2][3]

Hauptsächlich in C geschrieben und Anlegen der MIT-Lizenz seit 2013 wird AppImage derzeit von The AppImage project entwickelt . Es ist eine sehr bequeme Möglichkeit, Anwendungen zu verwenden, wie die folgenden Merkmale zeigen:

  1. AppImages kann auf praktisch jedem Linux-System ausgeführt werden. Wie bereits erwähnt, leiten Anwendungen viele Funktionen vom Betriebssystem und einigen gängigen Bibliotheken ab. Dies ist eine gängige Praxis in der Softwarewelt, denn wenn etwas bereits erledigt ist, macht es keinen Sinn, es noch einmal zu tun, wenn Sie auswählen können, welche Teile davon verwendet werden sollen. Das Problem ist, dass viele Linux-Distributionen möglicherweise nicht über alle Dateien verfügen, die eine bestimmte Anwendung zum Ausführen benötigt, da es den Entwicklern dieser bestimmten Distribution überlassen bleibt, die erforderlichen Pakete einzuschließen. Daher müssen Entwickler die Abhängigkeiten der Anwendung für jede Linux-Distribution, für die sie ihre App veröffentlichen, separat einschließen. Mit dem AppImage-Format können Entwickler alle Bibliotheken und Dateien einbeziehen, von denen sie unmöglich hoffen können, dass das Zielbetriebssystem sie als Teil der AppImage-Datei enthält. Daher kann dieselbe Datei im AppImage-Format auf verschiedenen Betriebssystemen und Computern funktionieren, ohne dass eine granulare Steuerung erforderlich ist.
  2. Die One-App-One-File-Philosophie bedeutet, dass die Benutzererfahrung einfach und elegant ist, da Benutzer nur eine Datei herunterladen und ausführen müssen, die ihren Anforderungen für die Verwendung der Anwendung entspricht.
  3. Kein Root-Zugriff erforderlich . Systemadministratoren verlangen, dass Benutzer Root-Zugriff haben, um sie daran zu hindern, sich mit Computern und deren Standardeinstellungen herumzuschlagen. Das bedeutet auch, dass Personen ohne Root-Zugriff oder Superuser-Rechte die benötigten Apps nicht nach Belieben installieren können. Diese Praxis ist in einer öffentlichen Umgebung üblich (z. B. Bibliotheks- oder Universitätscomputer oder auf Unternehmenssystemen). Die AppImage-Datei erfordert nicht, dass Benutzer irgendetwas „installieren“, und Benutzer müssen daher nur die besagte Datei herunterladen und ausführbar machen um damit zu beginnen. Dies beseitigt die Zugriffsprobleme, die Systemadministratoren haben, und erleichtert ihre Arbeit, ohne die Benutzererfahrung zu beeinträchtigen.
  4. Keine Auswirkung auf Kernbetriebssystem . Das AppImage-Anwendungsformat ermöglicht es, Anwendungen mit ihrer vollen Funktionalität zu nutzen, ohne die meisten Systemdateien ändern oder sogar darauf zugreifen zu müssen. Das heißt, was auch immer die Anwendungen tun, das Kern-Betriebssystem-Setup und die Dateien bleiben unberührt.
  5. Ein AppImage kann von einem Entwickler für eine bestimmte Version seiner Anwendung erstellt werden. Jede aktualisierte Version wird als ein anderes AppImage erstellt. Daher können Benutzer bei Bedarf mehrere Versionen derselben Anwendung testen indem Sie verschiedene Instanzen mit verschiedenen AppImages ausführen. Dies ist eine unschätzbare Funktion, wenn Sie Ihre Anwendungen von einem Endbenutzer aus testen müssen, um Unterschiede festzustellen.
  6. Nehmen Sie Ihre Bewerbungen überallhin mit. Wie bereits erwähnt, sind AppImages archivierte Dateien aller Dateien, die eine Anwendung benötigt, und können verwendet werden, ohne die vom System verwendete Distribution zu installieren oder sich überhaupt darum zu kümmern. Wenn Sie also eine Reihe von Apps haben, die Sie regelmäßig verwenden, können Sie sogar ein paar AppImage-Dateien auf einem USB-Stick mounten und mitnehmen, um sie auf mehreren Computern mit mehreren verschiedenen Distributionen zu verwenden, ohne sich Gedanken darüber zu machen, ob sie funktionieren oder nicht. li>

Außerdem das AppImageKit ermöglicht Benutzern mit allen Hintergründen, ihre eigenen AppImages aus Anwendungen zu erstellen, die sie bereits haben, oder für Anwendungen, denen kein AppImage von ihrem Upstream-Entwickler bereitgestellt wird.

Der Paketmanager ist plattformunabhängig, konzentriert sich jedoch hauptsächlich auf die Softwareverteilung an Endbenutzer auf ihren Desktops mit einem dedizierten Daemon AppImaged zur Integration der AppImage-Formate in jeweilige Desktop-Umgebungen. AppImage wird jetzt nativ von einer Vielzahl von Distributionen wie Ubuntu, Debian, openSUSE, CentOS, Fedora usw. unterstützt und andere können es nach ihren Bedürfnissen einrichten. AppImages kann über die mitgelieferten CLI-Tools auch auf Servern mit eingeschränkter Funktionalität ausgeführt werden.

Weitere Informationen zu AppImages finden Sie in der offiziellen AppImage-Dokumentation Seite.

Empfohlener Text:

  • Integrieren Sie AppImages mit AppImageLauncher in das Anwendungsmenü
  • Linux-Anwendungen auf AppImage-, Flathub- und Snapcraft-Plattformen durchsuchen

2. Bissig

Bissig ist ein Softwarebereitstellungs- und Paketverwaltungssystem wie AppImage oder ein anderer Paketmanager für diese Instanz. Es wurde ursprünglich für das inzwischen nicht mehr existierende Ubuntu Touch entwickelt Betriebssystem. Mit Snappy können Entwickler Softwarepakete zur Verwendung in einer Vielzahl von Linux-basierten Distributionen erstellen. Die ursprüngliche Absicht hinter der Erstellung von Snappy und der Bereitstellung von "Snaps" auf Ubuntu-basierten Systemen besteht darin, ein einheitliches Einzelformat zu erhalten, das in allem verwendet werden kann, von IoT-Geräten bis hin zu vollwertigen Computersystemen, auf denen eine Version von Ubuntu und im weiteren Sinne Linux selbst ausgeführt wird.[4]

Der leitende Entwickler hinter dem Projekt ist Canonical , dieselbe Firma, die das Ubuntu-Projekt pilotiert. Ubuntu hatte native Snap-Unterstützung ab Version 16.04 LTS, wobei immer mehr Distributionen dies heutzutage standardmäßig oder über ein einfaches Setup unterstützen. Wenn Sie Arch oder Debian oder openSUSE verwenden, können Sie die Unterstützung für den Paketmanager einfach installieren, indem Sie einfache Befehle im Terminal verwenden, wie später in diesem Abschnitt erläutert wird. Dies wird auch dadurch ermöglicht, dass die notwendigen Snap-Plattform-Dateien auf den jeweiligen Repos verfügbar gemacht werden.[5]

Snappy hat die folgenden wichtigen Komponenten, die das gesamte Paketverwaltungssystem ausmachen.[6]

  • Snap – ist das Dateiformat der Pakete selbst. Einzelne Anwendungen, die mit Snappy bereitgestellt werden, werden „Snaps“ genannt. Jede Anwendung kann mit den bereitgestellten Tools gepackt werden, um einen Snap zu erstellen, der auf einem anderen Linux-System ausgeführt werden soll. Snap ist, ähnlich wie AppImage, eine allumfassende Datei und enthält alle Abhängigkeiten, die die Anwendung zum Ausführen benötigt, ohne sie als Teil des Zielsystems zu übernehmen.
  • Snapcraft – ist das Tool, mit dem Entwickler Schnappschüsse ihrer Anwendungen erstellen können. Es ist im Grunde ein Befehl, der Teil des Snap-Systems ist, sowie ein Framework, mit dem Sie Ihre eigenen Snaps erstellen können.
  • Snapd – ist der Hintergrund-Daemon, der alle Snaps verwaltet, die in Ihrem System installiert sind. Es integriert sich in die Desktop-Umgebung und verwaltet alle Dateien und Prozesse im Zusammenhang mit der Arbeit mit Snaps. Der Snapd-Daemon sucht normalerweise auch viermal am Tag nach Updates sofern nicht anders eingestellt.
  • Snap Store – ist eine Art Online-Galerie, mit der Entwickler ihre Schnappschüsse in das Repository hochladen können. Snap Store ist auch ein Anwendungserkennungsmedium für Benutzer und lässt Benutzer die Anwendungsbibliothek sehen und erleben, bevor sie sie herunterladen und installieren.

Die snapd-Komponente ist hauptsächlich in C geschrieben und Golang während das Snapcraft-Framework mit Python erstellt wird . Obwohl beide Module die GPLv3-Lizenz verwenden, ist anzumerken, dass snapd über proprietären Code von Canonical für seine serverseitigen Operationen verfügt, wobei nur die Client-Seite unter der GPL-Lizenz veröffentlicht wird. Dies ist ein wichtiger Streitpunkt mit Entwicklern, da Entwickler ein CLA-Formular unterzeichnen müssen, um an der Entwicklung von Snap teilzunehmen.[7]

Um tiefer in die feineren Details des Snappy-Paketmanagers einzusteigen, sei Folgendes angemerkt:

  1. Snaps sind, wie bereits erwähnt, allumfassend und enthalten alle notwendigen Dateien (Abhängigkeiten), die die Anwendung zum Ausführen benötigt. Daher müssen Entwickler keine unterschiedlichen Schnappschüsse für die verschiedenen Distributionen erstellen, auf die sie abzielen. Wenn Basislaufzeiten vom Snap ausgeschlossen sind, müssen Sie lediglich auf die Laufzeiten achten.
  2. Snappy-Pakete sollen Transaktionsaktualisierungen unterstützen. Eine solche Transaktionsaktualisierung ist atomar und vollständig umkehrbar, was bedeutet, dass Sie die Anwendung verwenden können, während sie aktualisiert wird, und dass Sie, wenn sich eine Aktualisierung nicht so verhält, wie sie soll, dies ohne weitere Auswirkungen rückgängig machen kann. Das Konzept wird auch als Delta-Programmierung bezeichnet bei dem statt des gesamten Pakets nur Änderungen an der Anwendung als Update übertragen werden. Ein Ubuntu-Derivat namens Ubuntu Core verspricht dem Betriebssystem selbst sogar das knackige Update-Protokoll.[8]
  3. Ein wesentlicher Unterschied zwischen Snaps und AppImages besteht darin, wie sie mit Versionsunterschieden umgehen. Verwenden von AppImages Verschiedene Versionen der Anwendung haben unterschiedliche AppImages, sodass Sie gleichzeitig zwei oder mehr verschiedene Versionen derselben Anwendung verwenden können. Die Verwendung von Snaps bedeutet jedoch, dass Sie dem Transaktions- oder Delta-Update-System entsprechen. Dies bedeutet zwar schnellere Updates, hält Sie jedoch davon ab, zwei Instanzen derselben Anwendung gleichzeitig auszuführen. Wenn Sie die alte Version einer App verwenden müssen, müssen Sie die neue Version rückgängig machen oder deinstallieren. Snappy unterstützt eine Funktion namens „Parallel Install“ mit dem Benutzer ähnliche Ziele erreichen können, befindet sich jedoch noch in einem experimentellen Stadium und kann nicht als stabile Implementierung angesehen werden. Snappy nutzt auch Channels, was bedeutet, dass Sie die Beta oder den nächtlichen Build einer App und die stabile Version gleichzeitig verwenden können.[9]
  4. Umfangreiche Unterstützung von großen Linux-Distributionen und großen Entwicklern wie Google, Mozilla, Microsoft usw.[4]
  5. Snapd, das Desktop-Integrationstool, unterstützt das Erstellen von „Schnappschüssen“ des aktuellen Zustands aller installierten Snaps im System. Auf diese Weise können Benutzer den aktuellen Konfigurationsstatus aller Anwendungen speichern, die über den Snappy-Paketmanager installiert wurden, und Benutzer können zu diesem Status zurückkehren, wann immer sie dies wünschen. Dieselbe Funktion kann auch so eingestellt werden, dass Schnappschüsse automatisch in einer vom Benutzer als notwendig erachteten Häufigkeit erstellt werden. Snapshots können mit dem Snap-Save-Befehl erstellt werden im snapd-Framework.[10]
  6. Snaps sind so konzipiert, dass sie während des Betriebs in einer Sandbox gespeichert werden. Dies bietet Benutzern eine dringend benötigte Sicherheits- und Isolationsebene. Benutzer müssen sich keine Sorgen darüber machen, dass Snap-basierte Anwendungen mit der restlichen Software auf ihrem Computer herumspielen. Sandboxing wird mit drei Isolationsstufen implementiert, nämlich klassisch , streng und devmode . Jede Isolationsebene ermöglicht der App verschiedene Zugriffsebenen innerhalb des Dateisystems und des Computers.[11]

Auf der anderen Seite werden Snaps weithin dafür kritisiert, dass sie sich auf den Modus Operandi von Canonical konzentrieren . Die meisten Zusagen für das Projekt stammen von Mitarbeitern oder Auftragnehmern von Canonical, und andere Mitwirkende müssen ein Freigabeformular (CLA) unterzeichnen. Die Sandboxing-Funktion, die in der Tat aus Sicherheitsgründen sehr wichtig ist, ist insofern fehlerhaft, als das Sandboxing tatsächlich bestimmte andere Kerndienste erfordert, um ausgeführt zu werden (wie Mir), während Anwendungen, auf denen der X11-Desktop ausgeführt wird, die besagte Isolation nicht unterstützen, wodurch die besagtes Sicherheitsmerkmal irrelevant. Fragwürdige Pressemitteilungen und andere Marketingbemühungen von Canonical und dem „zentralen“ und geschlossenen App-Repository sind ebenfalls häufig kritisierte Aspekte von Snappy. Außerdem sind die Dateigrößen der verschiedenen Snaps auch vergleichsweise sehr groß im Vergleich zu den App-Größen der Pakete, die mit AppImage erstellt wurden.[7]

Weitere Einzelheiten finden Sie in der offiziellen Dokumentation von Snap .

Verwandte Lektüre:

  • Installieren Sie Snap-Pakete in Arch Linux und Fedora

3. Flatpak

Wie der oben aufgeführte Snap/Snappy, Flatpak ist auch ein Softwarebereitstellungstool, das darauf abzielt, die Softwareverteilung und -verwendung unter Linux zu vereinfachen. Flatpak war zuvor als „xdg-app“ bekannt und basierte auf einem Konzept von Lennart Poettering im Jahr 2004. Die Idee war, Anwendungen in einer sicheren virtuellen Sandbox zu enthalten, die es ermöglicht, Anwendungen ohne die Notwendigkeit von Root-Rechten zu verwenden und ohne Kompromisse bei der Systemsicherheit. Alex begann mit Klik (vermutlich eine frühere Version von AppImage) zu basteln und wollte das Konzept besser umsetzen. Alexander Larsson der damals mit Red Hat zusammenarbeitete, schrieb 2015 eine Implementierung namens xdg-app, die als Vorläufer des aktuellen Flatpak-Formats fungierte.

Flatpak kam offiziell 2016 mit Unterstützung von Red Hat, Endless Computers und Collabora auf den Markt. Flathub ist das offizielle Repository aller Flatpak-Anwendungspakete. An seiner Oberfläche ist Flatpak wie das andere ein Framework zum Erstellen und Packen von verteilungsunabhängigen Anwendungen für Linux. Es erfordert lediglich, dass die Entwickler einige Richtlinien für Desktop-Umgebungen einhalten, damit die Anwendung erfolgreich in die Flatpak-Umgebung integriert werden kann.

In erster Linie auf die drei gängigen Desktop-Implementierungen FreeDesktop ausgerichtet , KDE und GNOME , das Flatpak-Framework selbst ist in C geschrieben und arbeitet auf einer LGPL Lizenz. Auf das Wartungs-Repository kann hier über den GitHub-Link zugegriffen werden .

Einige Merkmale von Flatpak, die es von anderen abheben, sind unten aufgeführt. Beachten Sie, dass Funktionen, die Flatpak mit AppImage und Snappy teilt, hier weggelassen werden.

  • Tiefe Integration in beliebte Linux-Desktop-Umgebungen wie GNOME und KDE, sodass Benutzer Flatpaks einfach mit grafischen Softwareverwaltungstools verwenden können, anstatt auf das Terminal zurückzugreifen. Flatpak kann jetzt aus den Standard-Repositories der wichtigsten Desktop-Umgebungen installiert werden, und sobald die Apps selbst eingerichtet sind, können sie verwendet werden und bieten ähnliche Funktionen wie normale Desktop-Anwendungen.[12][13]
  • Aufwärtskompatibilität – Flatpaks werden von Grund auf neu erstellt, wobei der Kernel und die Laufzeiten des Betriebssystems berücksichtigt werden. Selbst wenn Sie Ihre Distribution upgraden oder aktualisieren, sollten die Flatpaks, die Sie haben, immer noch funktionieren, es sei denn, es gibt ein Core-Update. Dies ist besonders wichtig für Leute, die es vorziehen, auf laufenden Betas oder Entwicklungsversionen ihrer Distributionen zu bleiben. Da die Macken des Betriebssystems selbst normalerweise nicht ausgebügelt werden, läuft die Flatpak-Anwendung für solche Leute nahtlos, ohne dass sie für ihren Betrieb auf die Betriebssystemdateien oder -bibliotheken angewiesen sind.[13]
  • Sandboxing mit Bubblewrap – Snapshots werden auch standardmäßig in einer Sandbox gespeichert, da sie isoliert von den übrigen Anwendungen ausgeführt werden, die ausgeführt werden, während Sie Ihren Computer verwenden. Flatpaks schützen die Anwendung jedoch standardmäßig vollständig vor dem Zugriff auf Betriebssystemdateien und Benutzerdateien während des Betriebs. Dies bedeutet im Wesentlichen, dass Systemadministratoren sicher sein können, dass Flatpaks, die in ihren Systemen installiert sind, den Computer und die darin enthaltenen Dateien nicht ausnutzen können, während dies für Endbenutzer bedeutet, dass für den Zugriff auf einige bestimmte Funktionen oder Benutzerdaten eine Root-Berechtigung erforderlich ist. [14]
  • Flatpak unterstützt nativ die dezentrale Verteilung von Anwendungen, aber das Team hinter Flatpak unterhält weiterhin ein zentrales Online-Repository für Apps/Flatpaks namens Flathub . Benutzer können Flatpak tatsächlich so konfigurieren, dass mehrere Remote-Repositories verwendet werden, wenn sie dies für erforderlich halten. Im Gegensatz zu Snap können Sie mehrere Repositories haben.[13]
  • Modularer Zugriff über die Sandbox. Obwohl diese Fähigkeit mit großen potenziellen Kosten für die Integrität des Systems einhergeht, ermöglicht das Flatpak-Framework die Erstellung von Kanälen durch die Sandbox für den Austausch spezifischer Informationen aus der Sandbox zum Hostsystem oder umgekehrt. Der Kanal wird in diesem Fall als Portal bezeichnet. Ein Nachteil dieser Funktion wird später in diesem Abschnitt diskutiert.[14]

Einer der am meisten kritisierten Aspekte von Flatpak ist jedoch die Sandbox-Funktion selbst. Durch Sandboxing implementieren Paketmanager wie Snappy und Flatpak wichtige Sicherheitsfunktionen. Sandboxing isoliert im Wesentlichen die Anwendung von allem anderen im System und ermöglicht nur einen benutzerdefinierten Informationsaustausch von innerhalb der Sandbox nach außen. Der Fehler des Konzepts besteht darin, dass die Sandbox nicht von Natur aus uneinnehmbar sein kann. Daten müssen schließlich zwischen den beiden Domänen übertragen werden, und einfache Linux-Befehle können die Sandbox-Beschränkung einfach aufheben, was bedeutet, dass bösartige Anwendungen möglicherweise aus der besagten Sandbox springen könnten.[15]

Dies in Kombination mit dem schlechter als erwarteten Engagement für die Einführung von Sicherheitsupdates für Flatpak hat zu weit verbreiteter Kritik an dem hohen Anspruch des Teams geführt, ein sicheres Framework bereitzustellen. Der Blog (mit dem Namen flatkill ), der am Ende dieses Leitfadens verlinkt ist, erwähnt tatsächlich einige Exploits, die vom Flatpak-Team nicht so schnell behoben wurden, wie sie es hätten tun sollen.[15]

Für weitere Details empfehle ich Ihnen, die offizielle Flatpak-Dokumentation zu lesen .

Verwandte Lektüre:

  • Ein Anfängerleitfaden für Flatpak
  • So konfigurieren Sie ganz einfach Flatpak-App-Berechtigungen mit Flatseal

AppImage vs. Snap vs. Flatpak

Die unten angehängte Tabelle fasst alle oben genannten Ergebnisse in einem prägnanten und technischen Vergleich der drei Frameworks zusammen.

Funktion AppImage Snappy Flatpak
Einzigartige Funktion
Kein Appstore oder Repository, sondern einfach ein Verpackungsformat für die Softwareverteilung. Unter der Leitung von Canonical (dasselbe Unternehmen wie Ubuntu), mit zentralem App-Repository und aktivem Beitrag von Canonical. Verfügt über einen App Store namens FlatHub, Einzelpersonen können jedoch weiterhin Pakete hosten und verteilen.
Zielsystem Desktops und Server. Desktops, Server, IoT-Geräte, eingebettete Geräte usw. Desktops und eingeschränkte Funktion auf Servern.
Bibliotheken/Abhängigkeiten Basissystem. Laufzeiten optional, Bibliotheken und andere Abhängigkeiten gepackt. Basissystem oder über Plugins oder paketierbar. GNOME, KDE, Freedesktop gebündelt oder benutzerdefiniert gebündelt.
Entwickler Gemeinschaftsgetrieben unter der Leitung von Simon Peter. Unternehmen von Canonical Ltd. Community betrieben von Flatpak-Team unterstützt von Unternehmen.
Eingeschrieben C. Golang, C und Python. C.
Erstversion 2004. 2014. 2015.
Sandboxing Kann implementiert werden. 3 Modi - Strict, Classic und Devmode mit unterschiedlichen Confinement-Möglichkeiten. Wird isoliert ausgeführt. Isoliert, verwendet aber standardmäßig Systemdateien zum Ausführen von Anwendungen.
Sandboxing-Plattform Firejail, AppArmor, Bubblewrap. AppArmor. Luftpolsterfolie.
App-Installation Nicht erforderlich. Fungiert als selbstmontierte Disc. Installation mit snapd. Mit Flatpak-Client-Tools installiert.
App-Ausführung Kann ausgeführt werden, nachdem das Ausführungsbit gesetzt wurde. Mit Desktop-integrierten Snap-Tools. Läuft isoliert mit benutzerdefinierten Ressourcen. Muss mit dem Flatpak-Befehl ausgeführt werden, wenn CLI verwendet wird.
Benutzerberechtigungen Kann ohne Root-Benutzerzugriff ausgeführt werden. Kann ohne Root-Benutzerzugriff ausgeführt werden. Selektiv erforderlich.
Hosting-Anwendungen Kann überall von jedem gehostet werden. Muss auf Canonical-Servern gehostet werden, die proprietär sind. Kann überall von jedem gehostet werden.
Portable Ausführung von systemfremden Standorten Ja. Nein. Ja, nachdem der Flatpak-Client konfiguriert wurde.
Zentrales Repository AppImageHub. Snap Store. Flathub.
Ausführen mehrerer Versionen der App Möglich, beliebig viele Versionen gleichzeitig. Eine Version der App in einem Kanal. Muss für mehr separat konfiguriert werden. Ja.
Aktualisierung von Anwendungen Mit dem CLI-Befehl AppImageUpdate oder über ein in AppImage integriertes Updater-Tool. Erfordert die Installation von snapd. Unterstützt Delta-Updates, wird automatisch aktualisiert. Erforderliches Flatpak installiert. Aktualisieren Sie mit dem Befehl flatpak update.
Paketgrößen auf der Festplatte Bewerbung bleibt archiviert. Bewerbung bleibt archiviert. Clientseite ist unkomprimiert.

Hier ist ein langer tabellarischer Vergleich der Funktionen von AppImage vs. Snap vs. Flatpak. Bitte beachten Sie, dass der Vergleich aus einer AppImage-Perspektive erfolgt.

  • https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison

Schlussfolgerung

Während alle drei dieser Plattformen viel gemeinsam haben und darauf abzielen, einen plattformunabhängigen Ansatz zu verfolgen, bieten sie in einigen Bereichen unterschiedliche Kompetenzniveaus. Während Snaps auf einer Vielzahl von Geräten ausgeführt werden kann, einschließlich eingebetteter Geräte, wurden AppImages und Flatpaks für den Desktop-Benutzer entwickelt. AppImages beliebter Anwendungen hingegen hatten überlegene Verpackungsgrößen und Portabilität, während Flatpak wirklich mit seiner Aufwärtskompatibilität glänzt, wenn es in einem Set-it-and-forget-it-System verwendet wird.

Referenzen:

  • [1] Konzepte – AppImage-Dokumentation
  • [2] Slashdot – Point-and-Klik-Linux-Softwareinstallation
  • [3] Geschichte des AppImage-Projekts
  • [4] Snapcraft - Snaps sind universelle Linux-Pakete
  • [5] Installieren von snapd - Snap-Dokumentation
  • [6] Snap-Dokumentation
  • [7] Über Snappy und Flatpak:Business as usual in der kanonischen Propagandaabteilung
  • [8] Snap-Updates werden immer kleiner, hier ist der Grund dafür
  • [9] Was sind Linux-Snap-Pakete? Warum sie verwenden?
  • [10] Snapshots - Snap-Dokumentation
  • [11] Snap-Einschränkung - Snap-Dokumentation
  • [12] Desktop-Integration – Flatpak-Dokumentation
  • [13] Einführung in Flatpak - Flatpak-Dokumentation
  • [14] Sandbox-Berechtigungen – Flatpak-Dokumentation
  • [15] Flatpak - ein Sicherheitsalptraum

Linux
  1. Linux-Paketmanager:dnf vs apt

  2. 5 Gründe für die Verwendung von Linux-Paketmanagern

  3. Verwenden von AppImage für die Linux-Paketverwaltung

  4. So installieren und verwenden Sie den Snap-Paket-Manager unter Alma Linux 8

  5. SMPlayer 21.8.0 Fügt macOS-Unterstützung, Linux Appimage, Flatpak und Snap hinzu

Flatpak vs. Snap vs. AppImage

So führen Sie ein Downgrade von Paketen auf einem Linux-System durch:Der ultimative Leitfaden

Top 10 der besten Mailinglisten-Manager für Linux-Systeme

So führen Sie .run- und .bin-Pakete im Linux-System aus

So installieren Sie Snap Package Manager in Linux-Distributionen

Die 15 besten Komprimierungs- oder Archivmanager für Linux-Systeme