AppImage
-
Ein AppImage ist eine Datei für Linux, die eine Anwendung und alles was diese zum Ausführen braucht enthält. Ähnlich zu einem .dmg auf macOS.
Hier gibt es ein AppImage für MediathekView:
bintray.com/probono/AppImages/MediathekView/_latestVersion#files
Es enthält MediathekView und Java. Einfach herunterladen, ausführbar machen, doppelklicken, fertig. Sollte auf fast jedem Linux-System laufen.
Dies ist die Datei, die die Generierung des AppImage steuert:
github.com/probonopd/AppImages/blob/master/recipes/meta/MediathekView.ymlKönnte beispielsweise auch für Nightly Builds eingesetzt werden. Zusammen mit AppImageUpdate kann man Binär-Delta-Updates machen, d.h. es muss nur das heruntergeladen werden, was sich zwischen Build und Build auch tatsächlich geändert hat.
-
Ich hatte da auch schon drüber nachgedacht, bin aber noch nicht dazu gekommen das auszuprobieren.
Bitte nicht von sourceforge downloaden. -
Wäre das weiterhin wünschenswert?
-
Wieso will man das als Endandwender haben? Es ist doch gerade das schöne eines Paketmanagers, alle Updates an nur einer einzigen Stelle machen zu müssen, alle Installation auf die selbe (einfachste) Art und Weise zu bewerkstelligen, und nicht für jedes Programm immer einzeln schauen zu müssen, ob es Updates gibt und dieses für jedes Programm manuell zu installieren.
Warum für jede Applikation die Java braucht, Java mitliefern, für jede Applikation hoffen, dass der Entwickler die Abhängigkeiten (ich schaue hier inbesondere auf solche wie OpenSSL) aktuell hält?
Als Benutzer möchte ich eine Anwendung direkt vom Autor herunterladen und auf meinem Linux-Desktop-System ausführen, so wie ich es mit einer Windows- oder Mac-Anwendung tun würde.
Quelle: AppImageHier schaut man sich eine meiner Meinung nach stark negative “Eigeschaft” von den Platzhirschen ab und versucht diese auf Linux durchzusetzten?
Klar, wenn ich mir ein Debian als Desktopsystem hinstellen würde, würde ich mir sowas wahrscheinlich auch wünschen, um nicht mit uralter Software arbeiten zu müssen. Aber dann ist man selbst schuld.
-
@bagbag
Die Frage stelle ich mir auch.
Als Benutzer möchte ich eine Anwendung wie Java von meiner Distribution herunterladen, die Securitysupport leistet und Updates bereitstellt, und nicht auf Pakte aus unbekannter Drittquelle vertrauen. Alles andere ist Windows.
Aber jeder wie er es braucht, Windows-Umsteiger mit KlickibuntubuntuInstallationen mögen das vielleicht.Und ich benutze Debian seit 20 Jahren als Server und Desktop-System ohne ein Problem mit “Uralt-Software” zu haben, das ist FUD.
-
@vitusson
Hast du mit den Softwareversionen keine Probleme, weil du sid / experimental nutzt, oder weil es dir nichts macht? Alleine wenn ich mir jetzt bspw. Firefox anschaue, das wäre mir mit Version 52 (ESR) zu alt.
Auf Servern nutze ich auch ausnahmslos Debian, aber auf dem Desktop bevorzuge ich Rolling-Release wie Arch/Antergos. -
@bagbag sagte: Hier schaut man sich eine meiner Meinung nach stark negative “Eigeschaft” von den Platzhirschen ab
Und was ist daran – aus Sicht des einfachen User – negativ, dass man eine Applikation durch simples Kopieren irgendwohin lauffähig und sofort verwenden kann?
Nichts gegen Linux, ich verwende unter macOS auch einen Paketmanager, aber nur für Programme, die es eben nur auf diesem Wege gibt. Da muss ich immer wieder wieder Probleme auf der Kommandozeile korrigieren. Benutzerfreundlich ist das nicht, mal abgesehen davon, dass diese ganze Idee u.a. auch aus der Zeit stammt, wo Festplattenspeicher kostbar war…
Schön ist es doch, wenn man die Wahl hat, entweder via Paketmanager oder dann via AppImage. Das würde auch ich die Verbreitung von Linux fördern.
-
Gut, aus der Sicht eines einfachen Users mag das etwas tolles sein, aber dem ist eben auch meist egal wie vertraueswürdig die Quelle ist und ob es aktualisiert wird (falls denn überhaupt bekannt ist, was ein Update ist). Ich habe da mehr aus der Sicht eines “Power-Users” und Administrators gesprochen.
Wenn ich mir die Probleme anschaue, die ich mal unter Windows Server und der Installation einer offiziellen(!) Erweiterung für den IIS hatte, weil diese die Installation bei der neusten IIS Version verweigerte (obwohl funktionsfähig, die Erweiterung hat einfach nur kein Update mit “geht auch da” erhalten)… da musste ich in den Registry-Editor, dort paar Werte ändern um den Installer vorzugaukeln es wäre eine andere IIS Version installiert, und dann die ganzen Änderungen wieder rückgängig machen. Da habe ich lieber meinen Paketmanager, dem ich --force mitgeben kann (ich habe das noch nie gebraucht), sollte er mal etwas verweigern und ein Terminal wo ich schnell mal “sudo nano /etc/abc/xyz.conf” eingebe, anstatt da Ewigkeiten durch die Registry zu navigieren.
Ob Benutzerfreundlich oder nicht, das ist wohl Geschmackssache. Ich konfiguriere wesentlich lieber ein Linux-Server mit einem (oder mehreren) Terminal(s), als ein Windows Server mit der - aus meiner Sicht für diesen Zweck - ollen GUI.
Mag sein, dass die Idee einer Paketverwaltung alt ist, doch ist sie keineswegs outdated. Ich bin mit Windows groß geworden, doch habe Linux seit einigen Jahren lieben gelernt, unter anderem genau deswegen. Ich bin gerade 20 geworden, also war Speicherplatz sparen für mich nie ein Thema und ist daher für mich auch kein Argument das für das “outdated” sein spricht.
Wenn mehr Verbreitung für Linux bedeutet, dass es wie Windows werden muss, dann ist das meiner Meinung nach kein Ziel, dass weiterverfolgt werden sollte. Denn genau so etwas haben wir schon: Windoof. Wenn Jemand zu Linux geht und meckert, dass es nicht wie Windows ist… der geht am besten zurück, da es für DAUs und einfache Nutzer wohl wirklich besser geeignet ist.
PS: Geschrieben unter einem Windows 10 System. Ich bin also keineswegs Anti-Windoof, ich ziehe Linux lediglich für einige Dinge vor.
-
@bagbag sagte: Ich habe da mehr aus der Sicht eines “Power-Users” und Administrators gesprochen.
Ja, ich kann auch deiner Argumentation folgen, aber mit dem Anliegen des OP dürfte das nicht viel zu tun haben. Es geht nicht darum, wo Windows schlecht ist, sondern was gegen das zusätzliche Angebot eines App-Images spricht. Das mit dem Vertrauen hast du erwähnt, das ist sicher ein Punkt, auf der anderen Seite installiere ich seit bald 20 Jahren macOS-Software direkt von den Entwicklern (also nicht von irgendwo von irgendwem) als AppBundle auf mein System (so auch MV). Ich hatte in der Praxis noch nie eine negative Auswirkung. Warum sollte das gerade bei Linux anders sein?
PS: Geschrieben von einem, der während dem ganzen Studium auf Unix-Systemen arbeitete.
-
was gegen das zusätzliche Angebot eines App-Images spricht
Außer mehr Aufwand nichts. Also genau das, was AppImage verringern will. Denn meiner Meinung nach ist AppImage kein Ersatz für die Paketmanager der Distributionen, sondern lediglich eine zusätzliche Alternative (mal abgesehen davon, dass es von MediathekView meines wissens nach keine offiziellen Pakete gibt).
Ja, direkt bei den Entwicklern ist wohl meist eine Vertrauenswürdige Quelle, doch gehe ich davon aus, dass du kein einfacher Nutzer bist. DAUs installieren VLC auch gerne mal von vlc.de oder über mir suspekte Downloader wie von Chip oder Softonic oder … (anstatt von videolan.org) und haben so gleich Adware und wer weiß was noch dabei. Ich wüsste nicht, wieso das bei einer Durchsetzung von AppImages anders sein sollte.
-
-
(mal abgesehen davon, dass es von MediathekView meines wissens nach keine offiziellen Pakete gibt).
https://packages.debian.org/en/stretch/mediathekview
Das ist aber kein offizielles von MediathekView, zumindest wüsste ich nicht, dass Markus Koschany irgendwie zu uns gehört.
-
@bagbag sagte: zumindest wüsste ich nicht, dass Markus Koschany irgendwie zu uns gehört.
“apoleon” ist zumindest in den Credits von MV aufgeführt und schon über 6 Jahre dabei und hat viel Positives beigetragen.
@bagbag sagte
@styroll sagte: Es geht […] darum, […] was gegen das zusätzliche Angebot eines App-Images spricht
Außer mehr Aufwand nichts.
Dann sind wir ja gleicher Meinung…
