Ich habe gerade [Meet Etcher, A Stylish Open-Source USB Image Writer Tool] (http://www.omgubuntu.co.uk/2016/05/etcher-usb-image-burner-tool-linux-open-source) gelesen. Darin geht es um das Herunterladen eines AppImages.
Die Linux-Pakete werden als .appimage für 32-Bit- und 64-Bit-Distributionen verteilt und sollten auf allen wichtigen Linux-Distributionen ohne Probleme laufen. Das Team hat derzeit keine Pläne, ein natives .deb (oder .rpm) Installationsprogramm anzubieten.
Was sind AppImages? Wie unterscheiden sie sich von Snaps?
Ich zitiere hier die appImage-Projektseite:
AppImages können heruntergeladen und ohne Installation oder die Notwendigkeit für Root-Rechte.
Ausführbar machen
Sie können das appImage wie folgt ausführbar machen:
chmod a+x exampleName.AppImage
Sie können ein appImage wie folgt ausführen:
./exampleName.AppImage
Sie können einige allgemeine Informationen über appImage hier finden. Ich zitiere hier die appImage-Projektseite: Der Grundgedanke des AppImage-Formats ist: eine App = eine Datei. Jedes
AppImage enthält eine App und alle Dateien, die die App zum Ausführen benötigt. In anderen Worten, jedes AppImage hat keine anderen Abhängigkeiten als die, die in dem/den angestrebten Basisbetriebssystem(en) enthalten ist. Wikipedia fügt hinzu AppImage (und die Vorgänger klik und portablelinuxapps) installieren keine installieren keine Software im traditionellen Sinne (d.h., sie legen keine Dateien überall im System).
Es verwendet eine Datei pro Anwendung. Jede Datei ist in sich geschlossen: Sie enthält alle Bibliotheken, von denen die Anwendung von denen die Anwendung abhängt und die nicht Teil des Basissystems sind. In dieser Hinsicht, ist es ähnlich wie "Anwendungsvirtualisierung". Man kann eine AppImage Datei verwenden, auch wenn man kein Superuser ist oder eine Live-CD verwendet. AppImage-Dateien sind oft einfacher als das Kompilieren und Installieren einer Anwendung, da keine Installation stattfindet. Die AppImage-Datei ist ein komprimiertes Abbild, das vorübergehend gemountet wird, um den Zugriff auf das Programm zu ermöglichen, ohne dass das Programm extrahiert oder das zugrunde liegende System. Die
README.md
des AppImageKit-Projekts bietet eine Menge zusätzlicher Informationen wie Anwendungsfälle, den Problemraum und Ziele. Anwendungsfälle
- Als Benutzer möchte ich zu einer Upstream-Download-Seite gehen, eine Anwendung vom Originalautor herunterladen und sie auf meinem Linux-Desktop-System ausführen, genauso wie ich es mit einer Windows- oder Mac-Anwendung tun würde.
- Als Tester möchte ich in der Lage sein, die neueste Version einer Anwendung von einem Continuous-Build-Server zu erhalten und sie auf meinem System zu testen, ohne sie kompilieren zu müssen und ohne mir Sorgen machen zu müssen, dass ich mein System beschädigen könnte.
Als Anwendungsautor oder ISV möchte ich Pakete für Linux-Desktop-Systeme bereitstellen, so wie ich es für Windows und OS X tue, ohne dass ich sie in eine Distribution einbinden muss und ohne dass ich sie für zahllose verschiedene Distributionen erstellen muss. Zielsetzung
- Einfach sein. AppImage soll ein sehr einfaches Format sein, das leicht zu verstehen, erstellen und verwalten lässt.
- Binäre Kompatibilität beibehalten. AppImage ist ein Format für die binäre Softwareverteilung. Software die als AppImage verpackt wird, soll so binärkompatibel wie möglich sein wie möglich mit so vielen Systemen wie möglich kompatibel sein. Die Notwendigkeit der (Neu-)Kompilierung von Software sollte stark reduziert werden.
Distributionsunabhängig sein. Ein AppImage sollte auf allen Basisbetriebssystemen (Distributionen) laufen
für die es erstellt wurde (und spätere Versionen). Zum Beispiel könnten Sie Ubuntu 9.10, openSUSE 11.2 und Fedora 13 (und spätere Versionen) gleichzeitig ansprechen, ohne für jedes Zielsystem separate Pakete erstellen und pflegen zu müssen Pakete für jedes Zielsystem zu erstellen und zu pflegen.
Keine Installation mehr erforderlich. AppImages enthalten die Anwendung in einem Format, in dem sie direkt aus dem Archiv ausgeführt werden kann. AppImages enthalten die Anwendung in einem Format, in dem sie direkt aus dem Archiv ausgeführt werden kann, ohne dass sie zuerst installiert werden muss. Dies ist
vergleichbar mit einer Live-CD. Vor Live-CDs mussten Betriebssysteme Betriebssysteme erst installiert werden, bevor man sie benutzen konnte.
Die Anwendungen bleiben immer komprimiert. Da die Anwendung die ganze Zeit über komprimiert bleibt, ist sie nie
unkomprimiert auf der Festplatte. Der Computer dekomprimiert die Anwendung während des Zugriffs dekomprimiert. Da die Dekomprimierung schneller ist als das Lesen von der Festplatte auf den meisten Systemen, hat dies einen Geschwindigkeits neben der Platzersparnis auch einen Geschwindigkeitsvorteil. Außerdem entfällt die Zeit, die für die Installation benötigt wird, entfällt vollständig.
Erlaubt es, Apps überall zu platzieren. AppImages sind "relocatable", so dass der Benutzer zu speichern und
sie von jedem beliebigen Ort aus zu speichern und auszuführen (einschließlich CD-ROMs, DVDs, Wechselmedien Disketten, USB-Sticks).
Anwendungen schreibgeschützt machen. Da AppImages von vornherein schreibgeschützt sind, kann der Benutzer einigermaßen sicher sein
sicher sein, dass sich eine Anwendung während des Betriebs nicht selbst verändert.
Keine Neukompilierung erfordern. AppImages müssen aus bereits existierenden Binärdateien erstellt werden können,
ohne die Notwendigkeit einer Neukompilierung. Dies beschleunigt den AppImage-Erstellung erheblich, da kein Compiler beteiligt sein muss. Diese ermöglicht es auch Dritten, Closed-Source-Anwendungen als AppImages zu verpacken. (Nichtsdestotrotz kann es für Upstream-Entwickler von Vorteil sein Anwendungsentwickler aus dem Quellcode zu bauen, speziell für den Zweck der Erzeugung eines AppImage).
Das Basisbetriebssystem unberührt lassen. Da AppImages dazu gedacht sind, auf einfachen Systemen zu laufen, die nicht
von einem Administrator speziell vorbereitet wurden, dürfen AppImages keine keine ungewöhnliche Vorbereitung des Basisbetriebssystems. Daher können sie können sich nicht auf spezielle Kernel-Patches, Kernel-Module oder andere Anwendungen, die nicht standardmäßig in den Ziel-Distributionen enthalten sind Standard.
Sie benötigen kein Root-Recht. Da AppImages für die Ausführung durch Endbenutzer gedacht sind, sollten sie nicht
kein Administratorkonto (Root) für die Installation oder Verwendung erforderlich sein. Sie können jedoch von einem Administrator installiert werden (z. B. in Mehrbenutzer Szenarien), wenn dies gewünscht wird.
Die Grundidee der beiden Systeme mag ähnlich sein, aber es gibt einige Designunterschiede zwischen Snaps und Appimages.
Einige große Unterschiede, die mir in den Sinn kommen, sind:
Sicherheit, im Sinne von Einschränkung. Snap-Pakete laufen in einer Sandbox und es ist ihnen nicht erlaubt, daraus zu entkommen und andere Teile des Systems zu erreichen, die sie nicht berühren sollten. Dies ist eine stärkere Sicherheitsschicht, die parallel zum Rechtesystem läuft. Natürlich ist es am Anfang (und auch später) etwas frustrierend, damit umzugehen, aber wenn man es aus der Sicht der Systemadministration betrachtet, ist das genau das, was ein Administrator für seine Benutzer möchte.
Die Sicherheit. Die Installation von Software aus dem Netz ist so sicher, als würde man auf der Straße Stöcke lecken. Manchmal passiert nichts, manchmal bekommt man sehr große Gesundheitsprobleme. Snap-Pakete haben ihre eigenen Repositories, die von Canonical kontrolliert werden, wie die üblichen Standard-Ubuntu-Repositories. Sie können `.deb'-Dateien von irgendwoher installieren, aber das ist Ihre Entscheidung und kein Designproblem.
Die Installation. AppImages sollen das Äquivalent zu den "portablen ausführbaren Windows-Dateien" sein. Alle Bibliotheken sind in sich geschlossen und jeder Benutzer kann einfach eine davon herunterladen und ausführen. Auf der anderen Seite sind snap
Pakete richtige Pakete, und sie müssen (als root
, oder mit sudo
) über den entsprechenden Paketmanager installiert werden (snap install tic-tac-toe
wirft einen Fehler: es braucht sudo
!)
Deinstallation. Um ein Snap-Paket zu entfernen, müssen Sie den Paketmanager snap remove ...
mit den entsprechenden Rechten verwenden. Appimages, auf der anderen Seite, sind einfach "da". Wenn also ein Benutzer das Appimage nicht haben will? Er/sie entfernt einfach die Datei und schon ist sie weg.
Ich empfehle zwar, bei der Verwendung von Appimages vorsichtig zu sein, aber ich verwende selbst einige von ihnen.
Ich finde sie besonders auf meinem Arbeitssystem nützlich, wo ich keinen root
-Zugang habe (den hat nur der Administrator), aber die neueste Version einer bestimmten Software benötige, die der Entwickler glücklicherweise in Form eines Appimage zur Verfügung gestellt hat.
Ich habe ein wenig Angst, dass darin tatsächlich bösartiger Code enthalten ist, also habe ich die Identität des Herausgebers so weit wie möglich überprüft. Ich bin mir nicht zu 100 % sicher, dass diese Software gutartig ist, aber ich habe alles getan, was ich konnte.
Während snap sich nur auf Ubuntu konzentriert, ist AppImage verteilungsübergreifend und läuft auch auf Fedora, debian, openSUSE, CentOS usw.
AppImage benötigt keine Laufzeit- oder Infrastrukturunterstützung durch die Linux-Distribution und läuft daher fast überall. Es ermöglicht Anwendungsautoren, ihre Software direkt an Linux-Benutzer auszuliefern, so wie sie es für Windows und OS X tun; ohne Canonical oder irgendjemand anderen, der zwischen dem Softwareautor und dem Endbenutzer steht.
Wenn eine Anwendung im AppImage-Format zur Verfügung gestellt wird, kann der Benutzer auf die Website des Originalautors gehen, um sie herunterzuladen, z. B. MuseScore von https://musescore.org/en/download. Machen Sie das AppImage ausführbar (entweder mit Ihrem Dateimanager oder chmod a+x ./IhrAppImage
), dann können Sie die Anwendung einfach per Doppelklick ausführen.