Noch etwas: Haiku-App-Pakete?

TL; DR : Kann Haiku Anwendungspakete wie Anwendungsverzeichnisse (wie .app auf Mac) und / oder Anwendungsimages (Linux AppImage ) ordnungsgemäß unterstützen? Es scheint mir, dass dies eine würdige Ergänzung sein wird, die einfacher korrekt zu implementieren ist als in anderen Systemen, da der größte Teil der Infrastruktur bereits vorhanden ist.

Vor einer Woche entdeckte ich Haiku, ein unerwartet gutes System. Nun, da ich mich seit langem für Kataloge und Anwendungsbilder interessiere (inspiriert von der Einfachheit des Macintosh), ist es nicht verwunderlich, dass mir eine Idee in den Sinn kam ...

Zum vollständigen Verständnis: Ich bin der Ersteller und Autor von AppImage, einem Linux-Anwendungsverteilungsformat, das auf die Einfachheit des Mac abzielt und Anwendungsautoren und Endbenutzern vollständige Kontrolle bietet (Sie möchten mehr wissen - siehe Wiki und Dokumentation ).

Was ist, wenn wir ein AppImage für Haiku machen?

Lassen Sie uns rein theoretisch ein wenig darüber nachdenken: Was muss getan werden, um ein AppImage oder ähnliches auf Haiku zu erhalten? Es ist momentan nicht notwendig, etwas zu erstellen, da das System, das sich bereits in Haiku befindet, erstaunlich funktioniert, aber ein imaginäres Experiment würde sich als schön herausstellen. Er demonstriert auch die Raffinesse von Haiku im Vergleich zu Linux-Desktop-Umgebungen, in denen solche Dinge furchtbar schwierig sind (ich habe das Recht zu sagen: Ich debugge jetzt seit 10 Jahren).

Auf Macintosh System 1 war jede Anwendung eine separate Datei, die im Finder „verwaltet“ wurde. Mit AppImage versuche ich, die gleiche Benutzererfahrung unter Linux wiederherzustellen.

Was ist AppImage? Dies ist ein System zum Freigeben von Anwendungen von Drittanbietern (z. B. Ultimaker Cura ), mit dem Sie Anwendungen freigeben können, wann und wie sie suchen : Sie müssen die Funktionen verschiedener Distributionen nicht kennen, keine Richtlinien erstellen oder keine Infrastruktur erstellen, sie benötigen keine Unterstützung von Betreuern und sie sagen den Benutzern nicht, was (nicht) kann auf Computern installiert werden. AppImage sollte als ein Paket für Mac im .app Format in einem .dmg -Image verstanden werden. Der Hauptunterschied besteht darin, dass Anwendungen nicht kopiert werden, sondern immer in AppImage verbleiben, ähnlich wie die Haiku .hpkg Pakete installiert sind und niemals im üblichen Sinne installiert werden.

Über mehr als 10 Jahre seines Bestehens gewann AppImage an Attraktivität und Popularität: Linus Torvalds selbst genehmigte es öffentlich, und weit verbreitete Projekte (z. B. LibreOffice, Krita, Inkscape, Scribus, ImageMagick) akzeptierten es als Hauptmethode für die Verteilung kontinuierlicher oder nächtlicher Baugruppen, nicht Störung installierter oder nicht installierter Benutzeranwendungen. Linux-Desktops und -Distributionen halten jedoch meist immer noch am traditionellen, zentralisierten Distributionsmodell fest, das auf den Betreuern basiert, und / oder fördern ihre eigenen Unternehmens- und / oder Engineering-Programme, die auf Flatpak (RedHat, Fedora, GNOME) und Snappy (Canonical, Ubuntu) basieren. . Kommt zu lustig .

Wie funktioniert es?

• Jedes AppImage enthält zwei Teile: einen kleinen ausführbaren Doppelklick-ELF (den sogenannten runtime.c ), gefolgt vom SquashFS- Dateisystem-Image.

• Das SquashFS-Dateisystem enthält eine Nutzlast in Form einer Anwendung und alles, was Sie zum Ausführen benötigen. Dies kann Ihrer Meinung nach nicht als Teil der Standardinstallation für jedes relativ neue Zielsystem (Linux-Distribution) betrachtet werden. Es enthält auch Metadaten, z. B. Anwendungsname, Symbole, MIME-Typen usw. usw.

• Beim Start durch den Benutzer verwendet die Laufzeit FUSE und squashfuse, um das Dateisystem bereitzustellen. Anschließend wird der Start eines Einstiegspunkts (des sogenannten AppRun) innerhalb des bereitgestellten AppImage verarbeitet.
  Das Dateisystem wird nach Abschluss des Vorgangs nicht mehr bereitgestellt.

Es scheint, dass alles einfach ist.

Und diese Dinge erschweren die Dinge:

• Bei einer solchen Vielzahl von Linux-Distributionen gibt es nichts, was Sie als "Teil der Standardinstallation für jedes neue Zielsystem" bezeichnen können. Wir umgehen dieses Problem, indem wir eine Ausschlussliste zusammenstellen , mit der wir bestimmen können, was in AppImage verpackt wird und was woanders aufgenommen werden muss. Gleichzeitig vermissen wir manchmal, obwohl im Allgemeinen alles gut funktioniert. Aus diesem Grund empfehlen wir Paketerstellern, AppImages auf allen Zielsystemen (Distributionen) zu überprüfen.
• Anwendungen in Form einer Nutzlast müssen sich im Dateisystem bewegen. Leider sind in vielen Anwendungen absolute Pfade zu beispielsweise Ressourcen in /usr/share fest codiert. Dies muss irgendwie behoben werden. Darüber hinaus müssen Sie entweder LD_LIBRARY_PATH exportieren oder rpath damit der Loader verwandte Bibliotheken finden kann. Die erste Methode hat ihre Nachteile (die auf komplexe Weise verwaltet werden), und die zweite ist einfach umständlich.
• Die größte UX-Falle für Benutzer besteht darin , das ausführbare Bit nach dem Herunterladen auf die AppImage-Datei zu setzen . Ob Sie es glauben oder nicht, für manche ist es eine echte Barriere. Die Notwendigkeit, ein ausführbares Bit zu setzen, ist selbst für fortgeschrittene Benutzer umständlich. Als Problemumgehung haben wir vorgeschlagen, einen kleinen Dienst zu installieren, der AppImage-Dateien überwacht und das ausführbare Bit für diese setzt. In seiner reinen Form nicht die beste Lösung, da es nicht sofort funktioniert. Linux-Distributionen bieten diesen Service nicht an, daher geht es Standardbenutzern nicht gut.
• Linux-Benutzer erwarten, dass die neue Anwendung ein Symbol im Startmenü hat. Sie können dem System nicht sagen: "Schauen Sie, es gibt eine neue Anwendung, lass uns arbeiten." Stattdessen müssen Sie gemäß der XDG-Spezifikation die .desktop Datei für die systemweite Installation an den gewünschten Speicherort in /usr oder für die individuelle Installation in $HOME kopieren. Symbole bestimmter Größen gemäß der Spezifikation XDG, Sie müssen es an bestimmten Stellen in usr oder $HOME und dann Befehle in der Arbeitsumgebung ausführen, um den Symbolcache zu aktualisieren, oder hoffen, dass der Arbeitsumgebungsmanager es herausfindet und automatisch alles erkennt. Ähnlich wie bei MIME-Typen. Als Problemumgehung bietet es Um denselben Dienst zu verwenden, der zusätzlich zum Setzen des Ausführungsflags in AppImage Symbole usw. von AppImage an die richtigen Stellen gemäß XDG kopiert, wird davon ausgegangen, dass der Dienst beim Löschen oder Verschieben alles löscht. Natürlich gibt es Unterschiede im Verhalten Arbeitsumgebung in grafischen Dateiformaten, deren Größe, Speicherorte und Möglichkeiten zum Aktualisieren von Caches, was ein Problem darstellt. Kurz gesagt, diese Methode ist eine Krücke.
• Wenn dies nicht ausreicht, befindet sich im Dateimanager kein AppImage-Symbol. In der Linux-Welt haben sie sich (trotz der Diskussion und Implementierung ) immer noch nicht für die Implementierung von elficon entschieden, sodass es unmöglich ist, das Symbol direkt in die Anwendung einzubetten. Es stellt sich also heraus, dass die Anwendungen im Dateimanager keine eigenen Symbole haben (kein Unterschied, AppImage oder etwas anderes), sondern nur im Startmenü. Um dieses Problem zu umgehen, verwenden wir Miniaturansichten - ein Mechanismus, der ursprünglich entwickelt wurde, damit Desktop-Manager Miniaturansichten für die Vorschau von Grafikdateien als Symbole anzeigen können. Daher fungiert der Dienst zum Setzen des ausführbaren Bits auch als „Miniaturisierer“, der Miniaturansichten von Symbolen an den entsprechenden Stellen /usr und $HOME erstellt und aufzeichnet. Dieser Dienst führt auch ein Strippen durch, wenn das AppImage gelöscht oder verschoben wird. Aufgrund der Tatsache, dass sich jeder Desktop-Manager etwas anders verhält, z. B. in welchen Formaten er Symbole akzeptiert, in welchen Größen oder an welchen Orten, ist dies alles sehr schmerzhaft.
• Die Anwendung stürzt einfach zur Laufzeit ab, wenn Fehler auftreten (z. B. gibt es eine Bibliothek, die nicht Teil des Basissystems ist und nicht in AppImage bereitgestellt wird), und niemand teilt dem Benutzer in der GUI mit, was genau passiert. Wir haben damit begonnen, dies mithilfe von Benachrichtigungen auf dem Desktop zu umgehen. Dies bedeutet, dass wir Fehler über die Befehlszeile abfangen und in benutzerverständliche Nachrichten konvertieren müssen, die dann noch auf dem Desktop angezeigt werden müssen. Und natürlich behandelt jede Arbeitsumgebung sie ein wenig anders.
• Im Moment (September 2019, ca. Übersetzer) habe ich keine einfache Möglichkeit gefunden, dem System mitzuteilen, dass die 1.png Datei mit Krita und 2.png mit GIMP geöffnet werden 1.png .

Der Speicherort für die von GNOME , KDE und Xfce verwendeten Cross-Desktop-Spezifikationen ist freedesktop.org

Aufgrund der XDG- Spezifikationen von freedesktop.org für Cross-Desktop sowie der Implementierung von Desktop-Managern basierend auf diesen Spezifikationen ist es schwierig, wenn nicht unmöglich, ein Niveau zu erreichen, das tief in Haikus Arbeitsumgebung eingebunden ist. Als Beispiel können wir ein systemweites Firefox-Symbol anführen: Anscheinend haben die Autoren von XDG nicht einmal gedacht, dass der Benutzer mehrere Versionen derselben Anwendung haben kann.

Symbole verschiedener Versionen von Firefox

Ich habe mich gefragt, was die Linux-Welt von Mac OS X lernen kann, um die Systemintegration nicht zu beeinträchtigen. Wenn Sie Zeit haben und dies tun, lesen Sie unbedingt, was Arno Gourdol, einer der ersten Mac OS X-Ingenieure, sagte:

Wir wollten die Anwendung so einfach wie das Ziehen des Anwendungssymbols von irgendwo (Server, externes Laufwerk) auf die Festplatte Ihres Computers installieren. Zu diesem Zweck werden alle Informationen im Anwendungspaket gespeichert, einschließlich der Symbole, der Version, des zu verarbeitenden Dateityps und der Art der URL-Schemata, die das System zur Verarbeitung der Anwendung kennen muss. Dies umfasst auch Informationen zur zentralen Speicherung in der Datenbank "Icon Services" und "Launch Services". Um die Leistung aufrechtzuerhalten, werden Anwendungen an mehreren "bekannten" Stellen "entdeckt": im System- und Benutzerverzeichnis Anwendungen sowie in einigen anderen automatisch, wenn der Benutzer zum Finder in das Verzeichnis gewechselt ist, in dem sich die Anwendung befindet. In der Praxis hat dies sehr gut funktioniert.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 Session 144 - Mac OS X: Verpacken von Anwendungen und Drucken von Dokumenten.

Auf Linux-Desktops gibt es nichts Vergleichbares zu dieser Infrastruktur. Daher suchen wir nach Problemumgehungen für die strukturellen Einschränkungen im AppImage-Projekt.

Hat Haiku es eilig zu helfen?

Und noch etwas: Linux-Plattformen als Grundlage für Arbeitsumgebungen sind in der Regel so wenig spezifiziert, dass viele Dinge, die in einem konsistenten System mit vollem Stack sehr einfach sind, die Fragmentierung und Komplexität von Linux enttäuschen. Ich habe einen ganzen Bericht über Probleme im Zusammenhang mit der Linux-Plattform für Arbeitsumgebungen verfasst (sachkundige Entwickler haben bestätigt: Alles wird noch sehr lange so bleiben).

Mein Bericht über Linux-Desktop-Umgebungen im Jahr 2018

Sogar Linus Torvalds gab zu, dass die Idee der Arbeitsumgebung aufgrund der Fragmentierung gescheitert war.

Schön, Haiku zu sehen!

Mit Haiku ist alles erstaunlich einfach.

Obwohl der naive Ansatz für die Portierung von AppImage nach Haiku darin besteht, einfach zu versuchen (hauptsächlich runtime.c und service), seine Komponenten zu erstellen (was möglicherweise sogar möglich ist!), Wird dies Haiku keinen großen Nutzen bringen. Denn tatsächlich wurden die meisten dieser Probleme von Haiku gelöst und konzeptionell gerechtfertigt. Haiku bietet genau die Bausteine ​​für die Systeminfrastruktur, nach denen ich in Linux-Desktop-Umgebungen so lange gesucht habe und die ich nicht glauben konnte, dass sie nicht vorhanden sind. Nämlich:

Ob Sie es glauben oder nicht, viele Linux-Benutzer können dies nicht überwinden. Bei Haiku wird alles automatisch erledigt!

• ELF-Dateien, die kein ausführbares Bit haben, erhalten es automatisch, wenn Sie im Dateimanager doppelklicken.
• Anwendungen können eingebettete Ressourcen haben, z. B. Symbole, die im Dateimanager angezeigt werden. Sie müssen keine Bilder in spezielle Symbolverzeichnisse kopieren und müssen sie daher nach dem Löschen oder Verschieben der Anwendung nicht bereinigen.
• Es gibt eine Datenbank zum Verknüpfen von Anwendungen mit Dokumenten. Dafür müssen keine Dateien kopiert werden.
• Im Verzeichnis lib / neben der ausführbaren Datei werden Bibliotheken standardmäßig durchsucht.
• Es gibt keine zahlreichen Distributionen und Desktop-Umgebungen, alles was funktioniert - funktioniert überall.
• Es gibt kein separates Modul zum Starten, das sich vom Anwendungsverzeichnis unterscheidet.
• Anwendungen haben keine integrierten absoluten Pfade zu ihren Ressourcen. Es gibt spezielle Funktionen zum Bestimmen des Speicherorts zur Laufzeit.
• Die Idee von komprimierten Dateisystem-Images wurde eingeführt: Dies ist ein beliebiges HPKG-Paket. Alle von ihnen sind am Kern montiert.
• Jede Datei wird von der Anwendung geöffnet, die sie erstellt hat, es sei denn, Sie geben ausdrücklich etwas anderes an. Wie großartig es ist!

Zwei PNG-Dateien. Achten Sie auf verschiedene Symbole, die anzeigen, dass sie von verschiedenen Anwendungen durch Doppelklicken geöffnet werden. Beachten Sie auch das Dropdown-Menü "Öffnen mit:", in dem der Benutzer eine separate Anwendung auswählen kann. Wie einfach!

Es sieht so aus, als ob viele der von AppImage unter Linux benötigten Krücken und Problemumgehungen unter Haiku unnötig werden. Haiku basiert auf Einfachheit und Raffinesse, dank derer es die meisten unserer Anforderungen erfüllt.

Brauchen Haiku am Ende Anwendungspakete?

Dies führt zu einer großen Frage. Wenn es um eine Größenordnung einfacher wäre, ein System wie AppImage unter Haiku als unter Linux zu erstellen, wäre es das wert? Oder hat Haiku mit seinem HPKG-Paketsystem die Notwendigkeit, eine solche Idee zu entwickeln, praktisch beseitigt? Nun, für die Antwort müssen Sie sich die Motivation für die Existenz von AppImages ansehen.

Ansicht vom Benutzer

Schauen Sie sich unseren Endbenutzer an:

• Ich möchte die Anwendung installieren, ohne nach dem Administratorkennwort (root) zu fragen. Auf Haiku gibt es kein Administrator-Konzept, der Benutzer hat die volle Kontrolle, da dies ein persönliches System ist! (Im Prinzip können Sie sich dies im Mehrbenutzermodus vorstellen. Ich hoffe, die Entwickler werden die Einfachheit beibehalten.)
• Ich möchte die neuesten und besten Versionen von Anwendungen erhalten und nicht darauf warten, dass sie in meiner Distribution erscheinen (meistens bedeutet dies "nie", zumindest wenn Sie nicht das gesamte Betriebssystem aktualisieren). Auf Haiku wird dies mit Floating Releases "gelöst". Dies bedeutet, dass es möglich ist, die neuesten und besten Versionen von Anwendungen zu erhalten. Dazu müssen Sie jedoch den Rest des Systems ständig aktualisieren, um es tatsächlich zu einem "sich bewegenden Ziel" zu machen .
• Ich möchte mehrere Versionen derselben Anwendung in der Nähe haben, da Sie nicht herausfinden können, was in der neuesten Version defekt war, oder wenn ich beispielsweise als Webentwickler meine Arbeit unter verschiedenen Versionen des Browsers überprüfen muss. Haiku löste das erste, aber nicht das zweite Problem. Updates werden zurückgesetzt, aber nur für das gesamte System ist es (wie ich weiß) unmöglich, beispielsweise mehrere Versionen von WebPositive oder LibreOffice gleichzeitig zu starten.

Einer der Entwickler schreibt:

Im Wesentlichen lautet die Begründung: Der Anwendungsfall ist so selten, dass eine Optimierung für ihn keinen Sinn ergibt. Die Behandlung als Sonderfall bei HaikuPorts scheint mehr als akzeptabel.

• Ich muss Anwendungen speichern, wo ich möchte, und nicht auf der Startdiskette. Ich habe oft keinen Speicherplatz mehr auf den Festplatten, daher muss ich ein externes Laufwerk oder Netzwerkverzeichnis anschließen, um Anwendungen zu speichern (alle Versionen, die ich heruntergeladen habe). Wenn ich ein solches Laufwerk anschließe, müssen die Anwendungen durch Doppelklicken gestartet werden. Haiku speichert ältere Versionen von Paketen, aber ich weiß nicht, wie ich sie auf ein externes Laufwerk verschieben oder später von dort aus Anwendungen aufrufen kann.

Entwicklerkommentar:

Technisch ist dies bereits mit dem Befehl mount möglich. Natürlich werden wir eine GUI dafür erstellen, sobald genügend interessierte Benutzer gesammelt sind.

• Ich benötige nicht Millionen von Dateien im Dateisystem, die ich nicht manuell verwalten kann. Ich möchte eine Datei pro Anwendung, die ich einfach herunterladen, verschieben und löschen kann. Auf Haiku wurde dieses Problem mithilfe von .hpkg Paketen gelöst, die beispielsweise Python von Tausenden von Dateien in eine übertragen. Aber wenn es zum Beispiel Scribus gibt, der Python verwendet, muss ich mich mit mindestens zwei Dateien befassen. Und ich muss darauf achten, dass ihre Versionen miteinander funktionieren.

Zahlreiche Versionen von AppImages werden unter einem einzigen Linux nebeneinander ausgeführt

Ansicht von der Seite des Anwendungsentwicklers

Lassen Sie uns aus der Sicht des Anwendungsentwicklers schauen:

• Ich möchte die gesamte Benutzererfahrung verwalten. Ich möchte nicht vom Betriebssystem abhängig sein, das mir sagt, wann und wie ich Anwendungen freigeben soll. Bei Haiku können Entwickler mit ihren eigenen HPKG-Repositorys arbeiten. Dies bedeutet jedoch, dass Benutzer diese manuell konfigurieren müssen, was diese Idee weniger attraktiv macht.
• Ich habe eine Download-Seite auf meiner Website, auf der ich .exe für Windows, .dmg für Mac und .AppImage für Linux .AppImage . Oder möchte ich den Zugriff auf diese Seite monetarisieren, kann das alles sein? Was muss ich dort für Haiku posten? Genug .hpkg Datei nur mit .hpkg Abhängigkeiten
• Meine Software benötigt bestimmte Versionen anderer Software. Es ist beispielsweise bekannt, dass Krita eine feste Version von Qt oder Qt benötigt, die auf eine bestimmte Version von Krita abgestimmt ist, zumindest bis die Korrekturen wieder zu Qt zurückkehren. Sie können Ihr eigenes Qt für die Anwendung in das .hpkg Paket .hpkg , dies ist jedoch höchstwahrscheinlich nicht erwünscht.

Normale Anwendungs-Download-Seite. Was kann man hier für Haiku platzieren?

Werden Bundles (die als Anwendungsverzeichnisse wie AppDir oder .app im Apple-Stil vorhanden sind) und / oder Bilder (als stark modifizierte AppImages oder .dmg Apple) nützliche Ergänzungen zur Haiku-Arbeitsumgebung sein? Oder wird es das ganze Bild verwässern und zur Fragmentierung führen und damit die Komplexität erhöhen? Ich bin hin und her gerissen: Einerseits basiert die Schönheit und Raffinesse von Haiku auf der Tatsache, dass es normalerweise einen Weg gibt, etwas zu tun, nicht viel. , / , , .

mr. waddlesplash

Linux ( , — . ) . Haiku .

?

...

, : — Haiku:

Haiku,

, , , Macintosh Finder. , QtCreator "QtCreator", ?

:

, , ? , - ?

Haiku, ? , .

mr. waddlesplash:

, : , , - . BeOS R5 Haiku — ...

!

Haiku?

hpkg, :

• .hpkg
• ( , ) .hpkg ( 80% )
• , .hpkg , ( , QtCreator): .hpkg , .

mr. waddlesplash :

, , — /system/apps , Deskbar , /system/apps , ( MacOS). Haiku , , , .

• Haiku , , , , " ", , ( 20% ). .hpkg , , — . (, .hpkg , — , . ! — .) , .hpkg , , HaikuDepot… ).

mr. waddlesplash:

. "" pkgman .

hpkg, . , .

Fazit

Haiku , , , Linux. .hpkg — , . , Haiku . — , Haiku, , . Haiku . , , , Haiku. , «-». 10 Linux, Haiku, , , . , , Haiku , , — . , , hpkg , . , Haiku , , ( ) "". , ?

! Haiku DVD USB, .
? telegram- .

: C C++. Haiku OS

: Haiku.

: