CleanPress

Schlagwort: AppImage

  • AppImagePool: App Store für den Desktop

    AppImage wird oft in einem Atemzug mit Flatpak und Snap genannt. Dabei ist dieses Paketformat mit einem Alter von 17 Jahren einerseits schon länger verfügbar und unterscheidet sich auch vom Paketformat selbst von den beiden anderen. Während Flatpak und Snap auf eine vorinstallierte Basis von Laufzeitumgebungen angewiesen sind, bringt AppImage alle benötigten Bestandteile im Paket selbst mit. Das bedeutet auch, es lässt sich mit einem Klick rückstandslos wieder entfernen.

    Zwei Nachteile

    AppImage hatte bisher jedoch zwei Nachteile gegenüber der Konkurrenz. Das betrifft die Updates und die Desktop-Integration. Updates von AppImages sind überwiegend immer noch Sache des Anwenders, der die alte Version manuell gegen eine neue austauscht. Es gibt zwar AppImageUpdate, das aber auf bisher kaum vorhandene Update-Informationen im AppImage selbst angewiesen ist. Hier sind die AppImage-Entwickler dabei, dies per libappimageupdate nachzubessern.

    Was die Desktop-Integration angeht, so gibt es seit einiger Zeit AppImageLauncher, das alle auf dem Rechner befindlichen AppImages zentral verwaltet und über das Menü der Desktop-Umgebung startfähig macht. Falls ein AppImage dies unterstützt, übernimmt AppImageLauncher auch die Aktualisierungen. Wenn es aber um das Stöbern durch den Bestand an verfügbaren AppImages ging, war der User bisher weitestgehend auf AppImageHub im Browser angewiesen.

    AppImagePool

    Für diesen App Store gibt es jetzt mit AppImagePool ein mit Flutter erstelltes GUI-Frontend, das den Weg in den Browser erspart und zudem noch extra Funktionalität mitbringt. Die AppImages werden direkt von GitHub heruntergeladen und können sowohl Upgrades als auch Downgrades erhalten, sofern das jeweilige AppImage dies unterstützt. Es bietet die Apps als Raster oder Liste an und verfügt über einen Dark Mode. AppImagePool steht als Flatpak, und, wen wundert’s, als AppImage zur Verfügung.

  • AppImages in den Desktop integrieren

    Seit einigen Jahren machen neue distributionsunabhängige Paketformate wie Flatpak, Snap und AppImage den althergebrachten Paketmanagern Konkurrenz. Während Flatpak aus der Ecke von Red Hat kommt und Snap von Canonical entwickelt wurde, gibt es AppImage schon sehr viel länger. Es erhielt durch den Erfolg der beiden Konkurrenten Auftrieb und genießt dadurch in den letzten Jahren einen höheren Bekanntheitsgrad.

    Vor- und Nachteile

    Während Flatpak und Snap auf die Installation von unterstützender Software angewiesen sind, kommt AppImage völlig eigenständig daher. Neben den Vorteilen der Unabhängigkeit und der Portabilität bringt AppImage für den Anwender den Nachteil, dass sich die derart gepackten Apps sich nur manuell in das jeweilige Applikationsmenü der Distributionen einfügen lassen und ansonsten entweder von der Kommandozeile aus oder per Klick auf die Anwendung im Dateimanager gestartet werden müssen, nachdem sie ausführbar gemacht wurden. Ein weiterer Nachteil ist der fehlende Update-Mechanismus, der dem Anwender verfügbare Updates ankündigt oder ausführt.

    Gestern entdeckte ich zufällig das kleine Tool AppImageLauncher, das angetreten ist, diese Nachteile auszubügeln. Das Tool wird auf GitHub entwickelt und wer viele AppImages nutzt, spart damit einiges an Zeit und gewinnt an Komfort. Außer der Installation per PPA bietet der Entwickler freundlicherweise neben dem Quellcode auch Pakete in den Formaten DEB und RPM für die Architekturen x86-64, i386 und armhf an. Zusätzlich gibt es die Anwendung auch – wer hätte es gedacht – als AppImage.

    AppImageLauncher

    Beim ersten Start von AppImageLauncher wird der Anwender gefragt, wo AppImages künftig zentral gespeichert werden sollen. Voreingestellt ist ~/Applications. Wird nun ein AppImage auf herkömmliche Weise gestartet, meldet sich AppImageLauncher und fragt, ob die App in den Desktop integriert werden soll. Stimmt der Anwender zu, wird das Image in den vorher festgelegten Ordner verschoben und samt Icon ins Applikationsmenü oder den genutzten Anwendungsstarter eingebunden. Dort bietet das Kontextmenü der Anwendung dann neue Einträge zum Löschen und Aktualisieren der Anwendung, letzteres nur, wenn das AppImage die Funktion AppImageUpdate unterstützt.

    Mit AppImageLauncher lassen sich AppImages zentral verwalten und über das Menü der Desktop-Umgebung starten, entfernen und, falls unterstützt, auch aktualisieren. Damit können die Nachteile von AppImage gegenüber Flatpak und Snap egalisiert werden und die Vorteile überwiegen.

  • AppImage – das unbekannte Wesen

    Bild: AppImage-Logo | Lizenz: Public Domain

    AppImage wird häufig in einem Atemzug mit den neuen Paketsystemen Flatpak und Snap genannt. Dabei ist AppImage keineswegs neu, sondern existiert bereits seit über fünfzehn Jahren. Zudem will es nicht mit den Mitbewerbern konkurrieren, sondern hat seine eigene Motivation.

    Richtig ist allerdings, das AppImage bis zum Auftauchen von Flatpak und Snap eher ein Schattendasein führte. Das hat sich in den letzten Jahren grundlegend geändert und auf AppImageHub stehen heute rund 1.000 Anwendungen zur Auswahl.

    Wo kommt AppImage her?

    Die Geschichte von AppImage beziehungsweise seiner Vorläufer begann bereits 2004. Entwickler Simon Peters, der auch heute noch hinter der Software steht, startet das Projekt klik, das nach einer Schaffenspause in PortableLinuxApps umbenannt und seit 2013 als AppImage verfügbar ist.

    Ziel war immer ein einfaches und distributionsunabhängiges Paketformat, das weder Root-Rechte noch eine Installation voraussetzt. Das Host-System soll dabei unverändert bleiben wie bei der Nutzung einer Live-Distribution. Anwendungen sollen schnell vom Entwickler zum Anwender kommen. Dieser muss das Paket lediglich ausführbar machen und kann loslegen.

    Wo sind die Unterschiede?

    AppImage hat zwar grob betrachtet die gleichen Ziele wie Flatpak und Snap, jedoch gibt es entscheidende Unterschiede. So wird im Gegensatz zu den Mitbewerbern keine Installation einer Basis-Software vorausgesetzt. AppImage verzichtet ebenfalls auf die bei Flatpak eingesetzten Laufzeitumgebungen, die desktopspezifisch oft benötige Bibliotheken bündeln und somit verhindern, dass jedes Paket alle benötigten Abhängigkeiten erneut mitbringen muss, auch wenn diese auf dem System bereits vorhanden sind.

    Andererseits muss ein AppImage nur einmal heruntergeladen werden, auch wenn es in Dualboot-Umgebungen eingesetzt wird, denn es läuft wahlweise auch von einem USB-Stick. Dabei lassen sich ohne viel Aufwand auch Anpassungen der Konfiguration mitführen. Das Erstellen von AppImages per AppImageKit ist einfacher als bei der Konkurrenz.

    Keine Sandbox

    AppImage verzichtet derzeit von Hause aus auf ein Sicherheitsmodell wie es Flatpak und Snap in Form von Sandboxen bieten. Hier muss der Anwender noch selbst tätig werden und kann die Anwendungen beispielsweise in Firejail laufen lassen.

    Ein weiterer Nachteil von AppImage ist derzeit noch die Update-Funktion. Diese kann zwar in die Pakete eingebaut werden und aktualisiert dann nur die Differenz zwischen alt und neu, wird aber bisher nur wenig eingesetzt. Simon arbeitet derzeit an einem Werkzeug, dass diesen Schritt für Entwickler vereinfachen soll, wie er kürzlich in einem Interview erläuterte.

  • Video-Editor OpenShot 2.4 verbessert die Stabilität

    Video-Editor OpenShot 2.4
    Screenshot: F. Thommes

    Open-Shot ist ein nichtlinearer Video-Editor aus dem Open-Source-Bereich, der sich auch an Anfänger und mit der Materie weniger vertraute Anwender richtet. Die jetzt veröffentlichte Version OpenShot 2.4 soll eine verbesserte Stabilität und somit weniger Abstürze aufweisen, die in der Vergangenheit recht häufig auftraten. Neben zahlreichen Fehlerbereinigungen und der Stabilisierung können sich Anwender aber auch über verbesserte Funktionalität freuen.

    Video-Editor für Anfänger

    Seit Version 2.0 des 2008 von Entwickler Jonathan Thomas gestarteten Projekts ist OpenShot in C++ geschrieben, verfügt über eine Python-API und bietet eine Qt-basierte Oberfläche. Unter der Haube kommen zur Manipulation von Videos Funktionen der FFmpeg-Bibliothek zum Einsatz, die jetzt voll unterstützt wird. Die Oberfläche ist, gemessen an der Komplexität der zu erledigenden Aufgabe recht übersichtlich geraten. Das Editieren von Videomaterial kann in weiten Teilen per Drag&Drop in mehreren parallelen Spuren unter Einbeziehen von Effekten und Animationen erledigt werden. 

    Absturzursache beseitigt

    Für OpenShot 2.4 lag der Schwerpunkt neben der bereits genannten Stabilisierung auf der weiteren Verbesserung der Benutzerführung. Bei der Stabilisierung ging es darum, eine Absturzursache in Version 2.x zu isolieren, die während des Editieren oder des Verarbeitens die Bibliothek libopenshot zum Absturz bringen konnte. Nach monatelangen Testläufen fanden die Entwickler heraus, dass unter bestimmten Bedingungen bei vielen Threads Speicherbereiche geleert wurden, die noch in Benutzung waren und so den Absturz herbeiführten. Diese Ursache ist nun abgestellt.

    Besseres Undo/Redo

    Bei der Arbeit an der besseren Benutzerführung wurde die Funktion Undo/Redo weiter ausgebaut. Die letzten Undo/Redo-Aktionen speichert die Anwendung automatisch in der jeweiligen Projektdatei. Die gewünschte Anzahl kann der Anwender selbst festlegen. Der Export von Einzelbildern unterstützt weitere Formate wie unter anderem PNG, JPG, PPM und BMP. Hinzu kamen die Export-Optionen Audio Only und Video Only. Die Funktionen Freeze und Freeze & Zoom erlauben die Auswahl neuer Voreinstellungen. Alle Änderungen können im Blog von OpenShot nachgelesen werden.

    OpenShot 2.4 steht für Linux, macOS und Windows sowie als Quellcode auf der Projektseite zum Download bereit. Für Linux steht zum jetzigen Zeitpunkt nur ein AppImage der Anwendung bereit. Diese 140 MByte große, distributions-unabhängige Paket kann nach dem Download und dem Setzen der Rechte als ausführbares Programm mittels des Befehls chmod +x OpenShot-v2.4.0-x86_64.AppImage durch Doppelklick oder in der Konsole per  ./OpenShot-v2.4.0-x86_64.AppImage gestartet werden.