AppImage Support für Ledger Hardware-Wallet

overflow

OpenBSD Enthusiast
Ich habe mir die Ledger Wallet gekauft und möchte nun die Software hierfür installieren.

Selbstverständlich wird *BSD nicht unterstützt.

Für Linux gibt es ein AppImage Installationsfile, was für mich bis dato unbekannt war.
(Blickt hier jemand in der Linuxwelt überhaupt noch durch... Was für ein Chaos...)

Für FreeBSD soll es ein AppImage Support geben, für OpenBSD ist dies vermutlich nicht verfügbar.
Ich frage dennoch mal hier... Vll hat ja jemand ähnliche Erfahrungen gemacht.

Was ich mir als Workaround vorstellen könnte ist in einer Docker Umgebung ein Linux-System bereitzustellen.
Dann können die Raspis auch mal sinnvollere Aufgaben übernehmen :)
 
AppImage heißt ja letztlich nix anderes, als das ein Programm mit all seinen Abhängigkeiten zusammengefasst wird und dann sozusagen wie ein static Binary ausführbar ist. Es ist also jetzt Container-Kram wo man auch ne Runtime für braucht.
AppImages sind in der Linux-Welt durchaus verbreitet.
Das es unter FreeBSD funktioniert liegt also weniger daran, das FreeBSD AppImage-Support hat, sondern das es Linux-Programme ausführen kann.

Was ich mir als Workaround vorstellen könnte ist in einer Docker Umgebung ein Linux-System bereitzustellen.
Ob es Docker für OpenBSD gibt weiß ich jetzt nicht. Nützt Dir aber im Zweifelsfall auch nicht so viel, da solcher Container in der Regel nicht betriebssystemfremd laufen (auch wenn es dafür inzwischen Lösungen gibt die das teilweise in Grenzen ermöglichen).
Wenn Du unter OpenBSD Linux-Kram laufen lassen willst, wirst Du wohl zu Virtualisierung (z.B. via vmm) greifen müssen.
 
Blickt hier jemand in der Linuxwelt überhaupt noch durch... Was für ein Chaos...
Wie üblich in der Linux-Welt haben sich 3 Gruppen unabhängig voneinander daran gemacht, wie man u.a. Desktop-Anwendungen mit Desktop-Integration als One-Click-Installer auf- und abwärtskompatibel (und auch Distributions-übergreifend) zur Verfügung stellen kann:
  • AppImage (machen reichlich Anpassungen für leichteren BSD-Support, vgl. #98)
  • Flatpak (Linux-only)
  • Snap (Linux-only)
Einen Vergleich findet man hier. Für Linux-User macht es wenig Unterschied, alle 3 Lösungen laufen überall.

Ob 3 Lösungen für ein Problem besser sind als keine Lösung für ein Problem, mag ein jeder für sich selbst beurteilen. :)

Ob es Docker für OpenBSD gibt weiß ich jetzt nicht.

Leider nicht; das ist eine traurige Geschichte.

Das Standardisierungsgremium der Open Container Initiative (Docker ist die bekannteste Implementation) hat vor vielen Jahren Kontakt zu FreeBSD aufgenommen, um sie mit ins Boot zu holen. FreeBSD hat kein Interesse gezeigt.

Inzwischen lässt sich die Bedeutung von Containern nicht mehr verleugnen. Im Rahmen der Standardisierung hätte man im Interesse der BSDs reichlich Details einbringen können, die man jetzt mit viel Aufwand von hinten durch die Brust ins Auge nachimplementieren muss.

Bei OpenBSD und NetBSD tut sich diesbezüglich meines Wissens gar nichts.
 
Wie üblich in der Linux-Welt haben sich 3 Gruppen unabhängig voneinander daran gemacht, wie man u.a. Desktop-Anwendungen mit Desktop-Integration als One-Click-Installer auf- und abwärtskompatibel (und auch Distributions-übergreifend) zur Verfügung stellen kann:
  • AppImage (machen reichlich Anpassungen für leichteren BSD-Support, vgl. #98)
  • Flatpak (Linux-only)
  • Snap (Linux-only)
Einen Vergleich findet man hier. Für Linux-User macht es wenig Unterschied, alle 3 Lösungen laufen überall.

Ob 3 Lösungen für ein Problem besser sind als keine Lösung für ein Problem, mag ein jeder für sich selbst beurteilen. :)

Als defacto-Standard hat sich eigentlich Faltpak durchgesetzt. Snap hat man nur wenn man ohnehin ein großes commitment für ubuntu hat und das will eigentlich niemand im professionellen Umfeld. Auch die Frage wie lange sich das noch hält, auch andere Eigenentwicklungen von cannonical sind ja schon eingestampft worden.

AppImage würde ich wie schon beschrieben eher als Alternative zu statisch gelinkten Binaries sehen - und hat in der Linux Welt auch sehr wenig Bedeutung.
 
Das Standardisierungsgremium der Open Container Initiative (Docker ist die bekannteste Implementation) hat vor vielen Jahren Kontakt zu FreeBSD aufgenommen, um sie mit ins Boot zu holen. FreeBSD hat kein Interesse gezeigt.

Inzwischen lässt sich die Bedeutung von Containern nicht mehr verleugnen. Im Rahmen der Standardisierung hätte man im Interesse der BSDs reichlich Details einbringen können, die man jetzt mit viel Aufwand von hinten durch die Brust ins Auge nachimplementieren muss.

Bei OpenBSD und NetBSD tut sich diesbezüglich meines Wissens gar nichts.

Naja, was heißt leider?

Docker scheint ja unter Linux größtenteils sauber zu funktionieren, hat ein klares breites mal mehr mal weniger sinniges Nutzungssprektrum und setzt ja soweit ich weiß in den meisten sinnvollen Szenarien auf Linux-Binaries.

Da müsste man aus OpenBSD sicht ja erstmal irgendwie ne Abstraktionsschicht bauen (Linux-Emulation gibts ja nicht, vill. was auf VMM Basis) und ganz viel drumherum und hätte am ende vermutlich etwas was nur begrenzt stabil ist und nicht den Qualitätsansprüchen des OpenBSD Teams entspricht.

Wo ist denn da der vorteil, wenn es schon zig Linuxe gibt die das viel besser können?

Ich glaube nicht das das OpenBSD Team das ziel hat jeden Usecase abzudecken, und sei er auch noch so breit und "interessant", sondern ein OS zu erstellen das seinen Kern gerecht wird, Sicherheit, Stabilität, Qualität, gute Doku.

Es gibt eine vielzahl an zeugs das man mit OpenBSD machen kann, und das ist doch Super, und wenn man was machen möchte was damit nicht läuft, nimmt man halt was anderes. Weder kann ich Netflix gucken noch Docker Container starten.

Ich weiß aus einem anderen Thread das Docker-Container von einigen als etwas angesehen werden das so breit ist das jedes OS Bald nutzlos wird wenns nicht unterstützt wird, aber aus "meiner" IT-Perspektive ist das extrem Faktenfern. Ja, in diesem "Webserver, Internetserver, Modernen Entwicklungszeugs" Szenario kommt man da kaum drann vorbei. Aus meiner beruflichen sicht gibts andererseits aber fast nur WindowsServer, alte Software von 2006 und nen paar Linux DHCP & Samba-Server - in keinen Szenario da macht Docker irgend einen sinn. Womit ich die breite Bedeutung nicht abstreiten möchte. So ähnlich auch im Desktop / flatpack bereich.

Um mal evtl. etwas zum OP zu schreiben: Ich glaube mit den OpenBSD Support siehts da sehr mau aus. Zwar kann man mit vmm nen linux emulieren, aber es gibt glaub ich kein USB-Support, und dann hättest du noch immer keine Verbindung zu den Apps mit denen du das verwenden kannst.

Es gibt aber USB Crypto-Lösungen die glaub ich unterstützt werden, zumindest meine ich mal etwas von den Yubikeys irgendwo gelesen zu haben.
 
Wo ist denn da der vorteil, wenn es schon zig Linuxe gibt die das viel besser können?

Weil man sich die Möglichkeit der einfachen Unterstützung eines offenen Standards mit interessanten Einsatzmöglichkeiten und großem Ökosystem offenhalten möchte?

OCI-Container sind ja nicht nur für Linux.

Ich weiß aus einem anderen Thread das Docker-Container von einigen als etwas angesehen werden das so breit ist das jedes OS Bald nutzlos wird wenns nicht unterstützt wird, aber aus "meiner" IT-Perspektive ist das extrem Faktenfern.

Wenn eine Technologie von einer breiten Gruppe im großen Maßstab genutzt wird, freue ich mich persönlich über die Unterstützung derselbigen in den von mir eingesetzen Betriebssystemen, selbst wenn ich persönlich (aktuell) keinen Bedarf dafür habe.

Ja, in diesem "Webserver, Internetserver, Modernen Entwicklungszeugs" Szenario kommt man da kaum drann vorbei.

Ich weiß nicht, wie es den anderen Nutzern hier im Forum geht - ich würde es schon begrüßen, wenn die BSDs mit dem technologischen Fortschritt mitgehen und nicht stehenbleiben.

Aus meiner beruflichen sicht gibts andererseits aber fast nur WindowsServer, alte Software von 2006 und nen paar Linux DHCP & Samba-Server - in keinen Szenario da macht Docker irgend einen sinn.

Dann bist du ja früher oder später ein Kandidat für OCI-Container unter Windows. :)
 
also mir gefallen als Endanwender diese Dinger nicht, also diese App-Images mit allen libs und evtl runtimes integriert.
Womöglich auch nicht OpenSource und wenn doch, von keinerlei Update-Diensten meines Systems erfasst. Mit jedem System-Update kann ich nur hoffen, dass mein App-Image noch korrekt arbeitet und zwar viel mehr, als das ohnehin bei 3rd-party SW schon der Fall ist. Und wenn diese Dinger sich dann auch noch stark ins System krallen und Zugriff auf HW haben möchten, habe ich dann ernsthafte Bedenken.
Und was ist daran einfach und modern?
Bei Mac hatten die das schon lange so (ähnlich) gemacht.

Mir gefiele es besser, wenn die Entwickler sich den bestehenden Mechanismen zuwenden würden und ihre Programme wie gewohnt anbieten.
Was kann denn einfacher sein, als etwas mit einem pkg oder apt install zu installieren? Dazu muss ich doch nicht Informatik studiert haben. Soviel kann man doch von jedem Anwender erwarten?
 
Was kann denn einfacher sein, als etwas mit einem pkg oder apt install zu installieren?
Die .app Ordner des macOS (X). Im Prinzip wohl sowas wie AppImage, aber es funktioniert, ist portabel und wird über den AppStore (auf Wunsch automatisch) aktualisiert.
Bei Linux gehen die AppImages gerne mal nicht weil immer noch irgendwelche Libs fehlen. Hatte ich in letzter Zeit aber selten wobei ich auch Linux selten benutze.
Ich werde wohl nie begreifen, wie man diese pkg Landschaft mit ihren Ganzen Abhängigkeiten und daraus resultierenden Nachteilen so schätzen tut gegenüber dem Mac Pendant oder Sachen wie Flatpak/apk/.exe Installer.
 
also mir gefallen als Endanwender diese Dinger nicht, also diese App-Images mit allen libs und evtl runtimes integriert.
Womöglich auch nicht OpenSource und wenn doch, von keinerlei Update-Diensten meines Systems erfasst. Mit jedem System-Update kann ich nur hoffen, dass mein App-Image noch korrekt arbeitet und zwar viel mehr, als das ohnehin bei 3rd-party SW schon der Fall ist. Und wenn diese Dinger sich dann auch noch stark ins System krallen und Zugriff auf HW haben möchten, habe ich dann ernsthafte Bedenken.
Und was ist daran einfach und modern?
Bei Mac hatten die das schon lange so (ähnlich) gemacht.

Mir gefiele es besser, wenn die Entwickler sich den bestehenden Mechanismen zuwenden würden und ihre Programme wie gewohnt anbieten.
Was kann denn einfacher sein, als etwas mit einem pkg oder apt install zu installieren? Dazu muss ich doch nicht Informatik studiert haben. Soviel kann man doch von jedem Anwender erwarten?

Der Sinn von solchen Dingern ist es ja, dass du dir eben keine Sorgen machen musst, dass nach einem Systemupdate noch alles funktioniert. Solange der Mechanismus von AppImage / Flatpak selbst nicht gebrochen ist läuft auch das Programm.

Der Vorteil liegt hier vielleicht weniger beim Anwender (wobei ich auch da welche sehe - aber durchaus auch bei apt/dnf/zypper) sondern beim Entwickler. Wenn du dein Programm veröffentlichst kannst du dich nicht um die zahlreichen Linuxdistros kümmern. Du musst darauf vertrauen, dass deine Anwendung relevant genug ist, dass sie von den Distributoren für ihre Distro verpackt werden und sich da jemand kümmert. Das ist wahrscheinlicher je relevanter und je portabler deine Anwendung ist.
Aber alleine bei Portabilität wirds schon schwer wenn man sich die gebräuchlichsten Linuxdistros ansieht: Da gibt es die Enterprise Dinger, RHEL 7 - eins der am weitesten verbreiteten (inkl. Centos/SL/OracleUBL) - ist 7 Jahre alt, RHEL6 - für das es immer noch Support seitens RedHat gibt - ist 11 Jahre.
Im Vergleich dazu hast du bleeding Edge Distros wie Fedora, Arch oder Tumbleweed.

Mit Flatpak muss das ganze genau einmal paketiert werden und es läuft auf all den genannten (bis auf RHEL6, da gibts keinen Flatpak support ;) ). Das kann idr. sogar der Entwickler selbst und er muss sich nicht auf irgendwelche anderen Leute verlassen.

Da kommt auch schon das nächste, nur weil etwas in einer Distribution mitgeliefert wird, heißt das nicht, dass das Paket dauerhaft gut supportet wird. Oder auch nur mit Sicherheitsupdates. Wie oft sind schon Pakete aus Distributionen geflogen weil man nicht zufrieden mit dem Zustand war / der Maintainer stillheimlich inaktiv ist / man keine neuen Maintainer findet, ....

Und wenn ich einem Maintainer von Distri X vertrauen kann, kann ich auch dem Maintainer des Flatpak vertrauen oder? Da ist kein Unterschied, das Flatpak wird im zweifel sogar mehr reviewed als das Paket für unbedeutende Gammeldistro XY.

Nun zum Thema proprietäre SW: Auch wenn mir OS immer lieber ist, gibt es doch einiges an CS die ich persönlich verwende. Da muss jeder selbst wissen wie er dazu steht. Aber ich finde es nicht verwerflich mit einem guten Produkt auch Geld verdienen zu wollen.
Gerade auch hier bieten Systeme wie Flatpak aber wieder Vorteile - wärend alles oben genannte auch für CS, sogar noch mehr da sich schwer jemand als Maintainer für CS findet, gilt, gibt es noch denk Faktor Sicherheit den du selbst ansprichst. Ich kann für ein Flatpak mit CS (z.b. den Spotify Client oder Steam) sehr wohl Rechte festlegen - und zwar genauer als ich das mit dem normalen Management unter Linux könnte (von Dingen wie SE Linux oder AppArmor mal abgesehen).



Und noch kurz zur Klarstellung: Bei Flatpak hast du nicht für jedes Flatpak alle Abhängigkeiten dabei. Es gibt runtimes die aufeinander Aufbauen. So installiere ich die Gnome-Runtime z.b. nur einmal für alle Flatpaks die dann Gnome-Anwendungen ausgeben.


Die .app Ordner des macOS (X). Im Prinzip wohl sowas wie AppImage, aber es funktioniert, ist portabel und wird über den AppStore (auf Wunsch automatisch) aktualisiert.
Bei Linux gehen die AppImages gerne mal nicht weil immer noch irgendwelche Libs fehlen. Hatte ich in letzter Zeit aber selten wobei ich auch Linux selten benutze.
Ich werde wohl nie begreifen, wie man diese pkg Landschaft mit ihren Ganzen Abhängigkeiten und daraus resultierenden Nachteilen so schätzen tut gegenüber dem Mac Pendant oder Sachen wie Flatpak/apk/.exe Installer.

Die Abhängigkeiten bei apt/dnf und co werden ja automatisch aufgelöst, wenn man als Anwender nur Sachen aus dem Systemrepo installiert hat man da sogut wie keine Probleme und wird auch (auf Wunsch) automatisch aktualisiert.
Und beim Mac ist auch nicht alles Grün, wenn ich da nämlich ein Programm abseits des AppStore installiere kann ich genau so Probleme haben das ordentlich zum laufen zu bekommen.

Wenn bei Linux AppImages nicht funktionieren liegt es daran, dass du für deine Distro nicht den AppImage support installiert hast. Der ist standardmäßig nirgends dabei, aber fast überall vorhanden. Ebenso wie du Flatpak installieren musst um Flatpaks zu nutzen.
 
Der ist standardmäßig nirgends dabei, aber fast überall vorhanden. Ebenso wie du Flatpak installieren musst um Flatpaks zu nutzen.
Womit man wieder beim Vorteil FreeBSD ist, da gibt es nicht 3 Möglichkeiten, es gibt halt Ports und PKGs die aber auf unterschiedliche Anforderungen zielen. Punkt. Die PKGs kann man ja auch relativ portabel halten nur muss das jeweilige OS je nach Anwendung und Abhängigkeiten in etwa auf dem gleichen Stand sein.

Beispiel: Eine unter FreeBSD 12.4 gesicherte PKG von Scribus inkl. Abhängigkeiten lässt sich wohl kaum so unter FreeBSD 13 verwenden. Aber so schlimm ist es eigentlich nicht.

Blöd nur wenn eine Anwendung eben von etwas abhängt, was (aus welchen Geünden auch immer) rausfliegt und man dann die Anwendung nicht mehr benutzen kann bzw seine PKGs nicht mehr aktualisieren kann ohne dass die Anwendung dann deinstalliert wird. Das find ich dann schon ziemlich blöd und in so einem Fall sowas wie snap / Flatpak dann schon besser.
 
Zurück
Oben