🥇Noch etwas: Haiku Anwendungspakete?

TL;DR: Kann Haiku angemessene Unterstützung für Anwendungs-Pakete bieten, wie zum Beispiel Anwendungskataloge (ähnlich .app wie auf Mac) und/oder Anwendungs-Images (Linux AppImage)? Ich denke, das wäre eine sinnvolle Ergänzung, die einfacher zu implementieren wäre als in anderen Systemen, da die meiste Infrastruktur bereits vorhanden ist.

Vor einer Woche entdeckte ich Haiku, ein überraschend gutes System. Da ich mich schon lange für Kataloge und Images von Anwendungen interessiere (inspiriert von der Einfachheit des Macintosh), ist es nicht verwunderlich, dass mir die Idee kam...

Um das klarzustellen: Ich bin der Erfinder und Autor von AppImage, einem Linux-Anwendungsdistribution-Format, das auf die Einfachheit von Mac abzielt und vollständige Kontrolle für Anwendungsautoren und Endbenutzer bietet (wenn Sie mehr erfahren möchten - siehe Wiki und Dokumentation).

Was wäre, wenn wir AppImage für Haiku erstellen?

Lassen Sie uns hypothetisch darüber nachdenken: Was müsste getan werden, um... AppImage, oder etwas Ähnliches auf Haiku? Es ist nicht erforderlich, sofort etwas zu erstellen, denn das System, das bereits in Haiku existiert, funktioniert erstaunlich gut. Ein imaginäres Experiment wäre jedoch interessant und zeigt die Raffinesse von Haiku im Vergleich zu den Linux-Arbeitsumgebungen, wo solche Dinge extrem schwierig sind (ich darf das sagen: Ich kämpfe seit 10 Jahren mit Debugging).

Auf Macintosh System 1 war jede Anwendung eine separate Datei, die im Finder 'verwaltet' wurde. Mit AppImage versuche ich, dasselbe Benutzererlebnis auf Linux nachzubilden.

Zunächst, was ist AppImage? Es ist ein System zum Veröffentlichen von Anwendungen von Drittanbietern (z. B. Ultimaker Cura), das es ermöglicht, Anwendungen nach Belieben zu veröffentlichen: man muss sich nicht mit den Besonderheiten verschiedener Distributionen, Build-Politiken oder Build-Infrastrukturen auseinandersetzen, es ist keine Unterstützung für Begleitdaten erforderlich, und sie geben den Benutzern nicht vor, was sie (nicht) auf ihren Computern installieren dürfen. Man sollte AppImage als etwas betrachten, das ähnlich ist wie ein Paket für Mac im Format .app innerhalb des Disk-Images .dmg. Der Hauptunterschied besteht darin, dass die Anwendungen nicht kopiert werden, sondern immer innerhalb des AppImage bleiben, ähnlich wie die Haiku-Pakete .hpkg werden montiert und niemals im herkömmlichen Sinne installiert.

AppImage hat sich in über 10 Jahren einen gewissen Reiz und Popularität erarbeitet: Linus Torvalds selbst hat es öffentlich anerkannt, und verbreitete Projekte (wie LibreOffice, Krita, Inkscape, Scribus, ImageMagick) haben es als Hauptmethode zur Verbreitung kontinuierlicher oder nächtlicher Builds angenommen, die keine Störungen für installierte oder nicht installierte Benutzeranwendungen verursachen. Dennoch halten Arbeitsumgebungen und Linux-Distributionen häufig an dem traditionellen, zentralisierten Verbreitungsmodell fest, das auf Begleitsoftware basiert und/oder eigene Unternehmens- und/oder Ingenieursprogramme fördert. Flatpak (RedHat, Fedora, GNOME) und Snappy (Canonical, Ubuntu). Es wird lächerlich.

Wie alles funktioniert

Jedes AppImage besteht aus zwei Teilen: einer kleinen ausführbaren ELF-Datei (z.B. runtime.c), gefolgt von einem Abbild des Dateisystems SquashFS.

Das SquashFS-Dateisystem enthält eine Nutzlast in Form einer Anwendung sowie alles Notwendige für deren Ausführung, was in einem gesunden Verstand nicht als Teil einer Standardinstallation für jedes einigermaßen aktuelle Zielsystem (Linux-Distribution) betrachtet werden kann. Es enthält außerdem Metadaten, wie den Namen der Anwendung, Icons, MIME-Typen und weitere Informationen.

Beim Start verwendet die Runtime FUSE und squashfuse, um das Dateisystem zu mounten, und danach wird ein bestimmter Einstiegspunkt (der sogenannte AppRun) innerhalb des gemounteten AppImage verarbeitet.
Das Dateisystem wird nach Abschluss des Prozesses wieder unmounten.

Eigentlich ganz einfach.

Aber diese Aspekte komplizieren alles:

Bei einer solchen Vielfalt an Linux-Distributionen kann man mit gesundem Menschenverstand nichts mehr als «Teil einer Standardinstallation für jedes aktuelle Zielsystem» bezeichnen. Wir umgehen dieses Problem, indem wir eine excludelisterstellen, die es ermöglicht festzulegen, was im AppImage verpackt wird und was woandersher bezogen werden muss. Trotzdem können wir manchmal danebenliegen, auch wenn im Großen und Ganzen alles einwandfrei funktioniert. Aus diesem Grund empfehlen wir den Paketentwicklern, AppImages auf allen Zielsystemen (Distributionen) zu testen.
Anwendungen in Form von Payloads sollten im Dateisystem portierbar sein. Leider ist in vielen Anwendungen der absolute Pfad zu Ressourcen wie beispielsweise in /usr/share. Das muss irgendwie behoben werden. Zusätzlich ist es notwendig, entweder zu exportieren LD_LIBRARY_PATH, oder zu korrigieren rpath , damit der Loader die abhängigen Bibliotheken finden kann. Die erste Methode hat ihre eigenen Nachteile (die komplizierte Lösungen erfordern), und die zweite ist einfach umständlich.
Die größte UX-Falle für Nutzer ist, dass sie das Ausführungsbit der AppImage-Datei nach dem Download setzen müssen. Glauben Sie es oder nicht, aber für manche ist das eine echte Hürde. Die Notwendigkeit, das Ausführungsbit zu setzen, ist selbst für erfahrene Nutzer umständlich. Als Workaround haben wir die Installation eines kleinen Dienstes vorgeschlagen, der die AppImage-Dateien überwacht und das Ausführungsbit setzt. Im reinsten Sinne ist das keine optimale Lösung, da sie nicht „out of the box“ funktioniert. Linux-Distributionen liefern diesen Dienst nicht mit, folglich haben die Nutzer „out of the box“ ein Problem.
Linux-Nutzer erwarten, dass die neue Anwendung ein Symbol im Startmenü erhält. Man kann es dem System nicht einfach sagen: „Schau, da ist eine neue Anwendung, lass uns arbeiten“. Stattdessen muss man gemäß der XDG-Spezifikation die Datei .desktop an den richtigen Ort kopieren in /usr für eine systemweite Installation oder in $HOME für eine individuelle. Symbole bestimmter Größen müssen gemäß der XDG-Spezifikation an festgelegte Orte in usr oder $HOMEplatziert werden, danach müssen Befehle in der Arbeitsumgebung ausgeführt werden, um den Icon-Cache zu aktualisieren, oder man hofft, dass der Desktop-Manager es versteht und alles automatisch erkennt. Ähnlich verhält es sich mit MIME-Typen. Als Umgehungslösung wird vorgeschlagen, denselben Dienst zu verwenden, der neben der Einstellung des Ausführbarkeitsattributs auch, falls vorhanden, Symbole und andere Elemente aus AppImage gemäß XDG an die richtigen Orte kopiert. Beim Entfernen oder Verschieben wird dieser Dienst voraussichtlich alles aufräumen. Natürlich gibt es Unterschiede im Verhalten jeder Arbeitsumgebung, in den Formaten grafischer Dateien, deren Größen, Ablageorten und in den Methoden zur Aktualisierung von Caches, was das Problem verursacht. Kurz gesagt, diese Methode ist ein Notbehelf.
Falls die oben genannten Punkte nicht ausreichen, gibt es im Dateimanager kein AppImage-Symbol. In der Linux-Welt wurde bisher keine Entscheidung zur Integration von elficon getroffen (trotz der Tatsache, dass es diskutiert wird), weshalb es unmöglich ist, das Symbol direkt in die Anwendung einzubetten. So kommt es, dass Anwendungen im Dateimanager keine eigenen Symbole haben (unabhängig davon, ob es sich um AppImage oder etwas anderes handelt); sie sind nur im Startmenü vorhanden. Als Workaround verwenden wir Miniaturansichten – einen Mechanismus, der ursprünglich entwickelt wurde, damit Desktop-Manager verkleinerte Bilder zur Vorschau von Grafikdateien als deren Symbole anzeigen können. Folglich funktioniert der Dienst zur Festlegung von Ausführungsbits auch als „Miniaturisierer“, der Miniaturansichten für Icons erstellt und an den entsprechenden Stellen speichert. Diskussion über und ImplementierungDieser Dienst führt auch eine Bereinigung durch, wenn das AppImage gelöscht oder verschoben wird. Da jeder Desktop-Manager sich etwas unterschiedlich verhält – z. B. in Bezug darauf, welche Formate er akzeptiert, in welchen Größen oder an welchen Orten – kann das alles wirklich schmerzhaft sein. /usr und $HOME. Dieser Service sorgt zudem für eine Bereinigung, wenn die AppImage gelöscht oder verschoben wird. Da jeder Desktop-Manager sich etwas anders verhält, z. B. in Bezug auf die akzeptierten Icon-Formate, Größen oder Positionen, kann das in der Praxis durchaus problematisch sein.
Die Anwendung stürzt einfach ab, wenn Fehler auftreten (zum Beispiel, wenn eine Bibliothek nicht Teil des Basissystems ist und nicht im AppImage enthalten ist), und niemand informiert den Benutzer im GUI darüber, was genau passiert. Wir haben damit begonnen, dies zu umgehen, indem wir Benachrichtigungen auf dem Desktop verwenden, was bedeutet, dass wir Fehler aus der Befehlszeile abfangen und in verständliche Nachrichten für den Benutzer umwandeln müssen, die dann auch auf dem Desktop angezeigt werden. Und natürlich behandelt jede Arbeitsumgebung sie ein wenig anders.
Bis zum heutigen Zeitpunkt (September 2019, Anmerkung des Übersetzers) habe ich keinen einfachen Weg gefunden, dem System zu sagen, dass die Datei 1.png mit Krita geöffnet werden soll, während 2.png sie mit GIMP geöffnet werden soll.

Der Ort zur Speicherung von plattformübergreifenden Spezifikationen, die in und wird nun im Projekt, KDE und Xfce verwendet werden, ist freedesktop.org.

Das Erreichen eines Niveaus an Raffinesse, das tief in die Haiku-Arbeitsumgebung verwoben ist, wird erschwert, um nicht zu sagen 'unmöglich', aufgrund der Spezifikationen von XDG von freedesktop.org. für cross-desktop sowie Implementierungen von Desktop-Managern, die auf diesen Spezifikationen basieren. Ein Beispiel ist das allgemeine Symbol für Firefox: Offenbar hatte es die XDG-Entwickler nicht in den Sinn gekommen, dass der Benutzer mehrere Versionen derselben Anwendung installiert haben könnte.

Symbole verschiedener Firefox-Versionen

Ich war neugierig, was die Linux-Welt von Mac OS X lernen könnte, um bei der Systemintegration keine Fehler zu machen. Wenn Sie Zeit haben und sich damit beschäftigen, lesen Sie unbedingt, was Arnaud Gurdol, einer der ersten Ingenieure von Mac OS X, gesagt hat:

Wir wollten, dass die Installation einer Anwendung so einfach ist wie das Ziehen und Ablegen des Symbols von irgendwoher (Server, externe Festplatte) auf die Festplatte Ihres Computers. Dazu wird im Anwendungspaket alle Informationen gespeichert, einschließlich Symbole, Version, zu verarbeitender Dateityp und der URL-Schema-Typ, den das System für die Verarbeitung der Anwendung benötigt. Ebenso gehört die Information für die 'zentralisierte Speicherung' in der Icon Services- und Launch Services-Datenbank dazu. Um die Leistung der Anwendung zu unterstützen, werden sie an mehreren 'bekannten' Orten 'erkannt': im System- und Benutzerverzeichnis Applications sowie an einigen anderen Orten automatisch, wenn der Benutzer im Finder in das Verzeichnis wechselt, das die Anwendung enthält. In der Praxis hat das sehr gut funktioniert.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 Sitzung 144 – Mac OS X: Anwendungspakete und Dokumentendruck.

Eine derartige Infrastruktur existiert in Linux-Produktionsumgebungen nicht, daher suchen wir nach Lösungen für die strukturellen Einschränkungen im AppImage-Projekt.

Eilt Haiku wirklich zur Rettung?

Und außerdem: Linux-Plattformen als Basis für Arbeitsumgebungen sind in der Regel so unter-spezifiziert, dass viele Dinge, die in einem konsistenten System mit vollem Stack recht einfach sind, aufgrund von Fragmentierung und Komplexität in Linux frustrierend sind. Ich habe einen ganzen Vortrag über die Herausforderungen der Linux-Plattform für Arbeitsumgebungen gehalten (erfahrene Entwickler haben bestätigt: das wird sich noch sehr lange so bleiben).

Mein Vortrag über die Herausforderungen von Linux-Arbeitsumgebungen im Jahr 2018

Sogar Linus Torvalds erkannte, dass die Idee von Arbeitsumgebungen aufgrund der Fragmentierung gescheitert ist.

Schön, Haiku zu sehen!

Mit Haiku wird alles unglaublich einfach

Obwohl der naive Ansatz, AppImage auf Haiku zu "portieren", darin besteht, einfach zu versuchen, seine Komponenten (hauptsächlich runtime.c und den Dienst) zu kompilieren (was vielleicht sogar möglich ist!), wird das Haiku nicht wirklich zugutekommen. Denn tatsächlich sind die meisten dieser Probleme auf Haiku gelöst und konzeptionell fundiert. Haiku bietet genau die Bausteine für die Systeminfrastruktur, die ich so lange in Linux-Arbeitsumgebungen gesucht habe und nicht glauben konnte, dass sie dort nicht existieren. Nämlich:

Glauben Sie es oder nicht, aber viele Linux-Nutzer können damit nicht umgehen. Bei Haiku geschieht alles automatisch!

ELF-Dateien, die kein Ausführungsbit haben, erhalten es automatisch durch einen Doppelklick im Dateimanager.
Anwendungen können eingebettete Ressourcen wie Icons haben, die im Dateimanager angezeigt werden. Es ist nicht nötig, zahlreiche Bilder in spezielle Verzeichnisse für Icons zu kopieren, und somit müssen diese nach dem Löschen oder Verschieben der Anwendung nicht aufgeräumt werden.
Es gibt eine Datenbank zur Verknüpfung von Anwendungen mit Dokumenten, sodass keine Dateien dafür kopiert werden müssen.
Im lib/ Verzeichnis werden standardmäßig Bibliotheken neben der ausführbaren Datei gesucht.
Es gibt keine Vielzahl von Distributionen und Desktop-Umgebungen; alles, was funktioniert, funktioniert überall.
Es gibt kein separates Modul zum Starten, das sich vom Verzeichnis Applications unterscheidet.
Anwendungen enthalten keine eingebetteten absoluten Pfade zu ihren Ressourcen; es gibt spezielle Funktionen, um den Standort zur Laufzeit zu bestimmen.
Die Idee von komprimierten Dateisystemabbildern wurde umgesetzt: das ist jedes Paket hpkg. Alle werden vom Kern gemountet.
Jede Datei wird von der Anwendung geöffnet, die sie erstellt hat, es sei denn, etwas anderes wird ausdrücklich angegeben. Wie großartig ist das!

Zwei PNG-Dateien. Achten Sie auf die unterschiedlichen Icons, die anzeigen, dass sie von verschiedenen Anwendungen durch Doppelklick geöffnet werden. Beachten Sie auch das Dropdown-Menü „Öffnen mit:“, in dem der Benutzer eine bestimmte Anwendung auswählen kann. So einfach!

Es sieht so aus, als wären viele der Hacks und Workarounds, die AppImage unter Linux benötigt, unter Haiku, das auf Einfachheit und Raffinesse basiert, überflüssig. Damit deckt es die meisten unserer Anforderungen ab.

Braucht Haiku letztendlich Anwendungs-Pakete?

Das führt zu einer großen Frage. Wenn es auf Haiku einfacher wäre, ein System wie AppImage zu erstellen als unter Linux, sollte man dann dies in Betracht ziehen? Oder hat Haiku mit ihrem Paket-System hpkg die Notwendigkeit für eine solche Entwicklung tatsächlich beseitigt? Um das zu beantworten, müssen wir die Motivation hinter AppImages betrachten.

Ein Blick aus der Sicht des Benutzers

Schauen wir uns unseren Endbenutzer an:

Ich möchte eine Anwendung installieren, ohne nach dem Passwort des Administrators (root) gefragt zu werden. Bei Haiku gibt es kein Administratorkonzept; der Benutzer hat die volle Kontrolle, da es sich um ein persönliches System handelt! (Im Prinzip kann man sich das auch im Mehrbenutzermodus vorstellen, ich hoffe, die Entwickler erhalten die Einfachheit.)
Ich möchte die neuesten und besten Versionen von Anwendungen erhalten, ohne darauf warten zu müssen, dass sie in meiner Distribution erscheinen (das bedeutet in den meisten Fällen: „nie“, es sei denn, das gesamte Betriebssystem wird aktualisiert). In Haiku wird dies durch rollierende Updates gelöst. Das bedeutet, dass es die Möglichkeit gibt, die neuesten und besten Versionen von Anwendungen zu erhalten, aber dazu muss das gesamte System ständig aktualisiert werden, was es faktisch zu einem „beweglichen Ziel“ macht..
Ich möchte mehrere Versionen der gleichen Anwendung nebeneinander haben, da ich nicht herausfinden kann, was in der letzten Version kaputt gemacht wurde, oder beispielsweise als Webentwickler meine Arbeit unter verschiedenen Browser-Versionen testen muss. In Haiku ist das erste Problem gelöst, aber nicht das zweite. Updates können zurückgesetzt werden, jedoch nur für das gesamte System; es ist (meines Wissens nach) nicht möglich, zum Beispiel mehrere Versionen von WebPositive oder LibreOffice gleichzeitig auszuführen.

Einer der Entwickler schreibt:

Im Grunde lautet die Begründung folgendermassen: Das Nutzungsszenario ist so selten, dass eine Optimierung dafür keinen Sinn macht; die Behandlung als Sonderfall in HaikuPorts erscheint mehr als akzeptabel.

Ich möchte Anwendungen dort speichern, wo es mir gefällt, und nicht auf dem Startlaufwerk. Auf den Laufwerken ist oft der Platz knapp, daher muss ich eine externe Festplatte oder ein Netzwerkverzeichnis zum Speichern von Anwendungen (allen Versionen, die ich heruntergeladen habe) anschließen. Wenn ich ein solches Laufwerk anschließe, sollten die Anwendungen per Doppelklick gestartet werden. Haiku speichert alte Versionen von Paketen, aber ich weiß nicht, wie ich sie auf eine externe Festplatte verschieben kann und wie ich anschließend Anwendungen von dort aus aufrufen kann.

Kommentar des Entwicklers:

Technisch ist das bereits mit dem mount-Befehl möglich. Natürlich werden wir dafür ein GUI erstellen, sobald ausreichend interessierte Benutzer vorhanden sind.

Ich brauche nicht Millionen von Dateien, die über das Dateisystem verstreut sind und die ich nicht manuell verwalten kann. Ich möchte eine Datei pro Anwendung, die ich einfach herunterladen, verschieben oder löschen kann. In Haiku wurde dieses Problem durch Pakete gelöst. .hpkg, die beispielsweise Python aus tausenden von Dateien in eine einzige zusammenführen. Aber wenn es beispielsweise Scribus gibt, das Python verwendet, muss ich mit mindestens zwei Dateien umgehen. Und ich muss sicherstellen, dass ich ihre funktionierenden Versionen beibehalte.

Verschiedene Versionen von AppImages, die nebeneinander auf einem Linux ausgeführt werden.

Eine Sichtweise aus der Perspektive des Anwendungsentwicklers.

Lassen Sie uns die Perspektive des Anwendungsentwicklers betrachten:

Ich möchte das Benutzererlebnis vollständig steuern. Ich möchte nicht von dem Betriebssystem abhängig sein, das mir sagt, wann und wie ich Anwendungen veröffentlichen soll. In Haiku können Entwickler mit ihren eigenen hpkg-Repositories arbeiten, aber das bedeutet, dass Benutzer diese manuell einrichten müssen, was diese Idee „weniger attraktiv“ macht.
Ich habe eine Download-Seite auf meiner Website, wo ich .exe für Windows, .dmg für Mac und .AppImage für Linux. Oder vielleicht möchte ich den Zugang zu dieser Seite monetarisieren, was auch immer möglich ist? Was sollte ich dort für Haiku platzieren? Genug einer Datei .hpkg mit Abhängigkeiten nur von HaikuPorts.
Meine Software benötigt bestimmte Versionen anderer Software. Zum Beispiel ist bekannt, dass für Krita eine angepasste Version von Qt erforderlich ist, oder Qt, das speziell auf eine bestimmte Version von Krita abgestimmt ist, zumindest bis die Korrekturen wieder in Qt zurückgeführt werden. Es ist möglich, eigene Qt-Versionen für die Anwendung in Paketen zu verpacken .hpkg, aber wahrscheinlich wird dies nicht unterstützt.

Eine normale Download-Seite für die Anwendung. Was sollte hier für Haiku stehen?

Werden Kits (bestehend in Form von Anwendungsordnern, wie AppDir oder .app im Apple-Stil) und/oder Images (in Form von stark modifizierten AppImages oder .dmg von Apple) von Anwendungen eine nützliche Ergänzung für die Haiku-Umgebung darstellen? Oder wird dies das Gesamtbild verwässern und zu Fragmentierung führen, was wiederum die Komplexität erhöht? Ich bin hin- und hergerissen: Auf der einen Seite basiert die Schönheit und Eleganz von Haiku darauf, dass es normalerweise einen Weg gibt, etwas zu tun, und nicht viele. Auf der anderen Seite ist bereits ein Großteil der Infrastruktur für Ordner und/oder Anwendungskits vorhanden, daher ruft das System danach, dass die restlichen Prozentsätze ihren Platz finden.

Laut dem Entwickler mr. waddlesplash

Auf Linux sind sie (Kataloge und Anwendungspakete – Anmerkung des Übersetzers) sind wahrscheinlich technische Lösungen für Systemprobleme. Bei Haiku ziehen wir es vor, Systemprobleme einfach zu lösen.

Was denken Sie darüber?

Bevor Sie antworten…

Warten Sie, wir machen eine schnelle Realitätprüfung: Tatsächlich Anwendungs-Kataloge — sind bereits Teil von Haiku:

Anwendungs-Kataloge existieren bereits in Haiku, werden jedoch derzeit im Dateimanager nicht unterstützt.

Sie werden einfach nicht so gut unterstützt wie zum Beispiel im Macintosh Finder. Wie cool wäre es, wenn der QtCreator-Katalog in der oberen linken Ecke den Namen und das Symbol „QtCreator“ hätte, um die Anwendung mit einem Doppelklick zu starten?

Ich hatte bereits früher gefragt:

Sind Sie sich sicher, dass Sie Ihre zehn Jahre alten Anwendungen heute ausführen können, wenn alle App-Stores und Distribution-Repositories sie und ihre Abhängigkeiten vergessen haben? Sind Sie sich sicher, dass Sie in Zukunft weiterhin auf Ihre aktuelle Arbeit zugreifen können?

Gibt es bereits eine Rückmeldung seitens Haiku, oder können Kataloge und Anwendungspakete hier helfen? Ich denke, sie können.

Laut Mr. waddlesplash:

Ja, wir haben eine Antwort auf die Frage: Wir werden diese Anwendungen einfach solange unterstützen, wie es nötig ist, bis jemand in der Lage ist, ihre Dateiformate korrekt zu lesen oder eine 1:1-Funktionalität bereitzustellen. Unser Bestreben, die Anwendungen von BeOS R5 auf Haiku zum Laufen zu bringen, beweist dies direkt...

Genau!

Welche Maßnahmen sollte Haiku ergreifen?

Ich kann mir ein harmonisches Zusammenleben von hpkg, Verzeichnissen und Anwendungsbildern vorstellen:

Die Systemsoftware verwendet .hpkg
Für die am häufigsten genutzte Software (insbesondere für Software, die geplante Release-Zyklen benötigt) wird .hpkg (ungefähr 80% aller Fälle)
Einige, die über .hpkg, Anwendungen werden von einem Wechsel zu einer Infrastruktur mit Anwendungsverzeichnissen profitieren (zum Beispiel QtCreator): Sie werden weiterhin in Form von .hpkg, wie gewohnt, verteilt.

mr. waddlesplash schreibt:

Wenn alles, was benötigt wird, eine Ansicht der Anwendungen in /system/apps, dann sollten stattdessen die Verzeichnisse in der Deskbar benutzerfreundlicher gestaltet werden, da /system/apps ist nicht dafür gedacht, dass Benutzer regelmäßig darauf zugreifen und es ansehen (im Gegensatz zu MacOS). Für solche Situationen hat Haiku eine andere Paradigmen, aber diese Option ist im Grunde akzeptabel.

Haiku erhält die Infrastruktur zum Ausführen von Anwendungsimages, nächtlichen, kontinuierlichen und Testsoftware-Bauten sowie in Fällen, in denen der Benutzer es "zeitlich einfrieren" möchte, für private und interne Software und andere spezielle Anwendungsfälle (etwa 20 % aller Fälle). Diese Images enthalten die erforderlichen Dateien zum Ausführen der Anwendung, .hpkg, die vom System gemountet werden und nach Abschluss der Anwendung wieder unmounted werden. (Vielleicht könnte der Dateimanager Dateien in die Anwendungsimages einfügen, .hpkg automatisch oder auf Anfrage des Benutzers – so wie bei Drag & Drop einer Anwendung in ein Netzwerkverzeichnis oder auf eine externe Festplatte. Das ist einfach großartig! Genauer gesagt, es ist Poesie – ein Haiku.) Auf der anderen Seite könnte der Benutzer möchten, dass der Inhalt des Images als Dateien installiert wird,.hpkg, die dann genauso aktualisiert und verarbeitet werden, als ob sie über HaikuDepot installiert wurden… Ein Brainstorming könnte hilfreich sein.)

Zitat von mr. waddlesplash:

Das Starten von Anwendungen von externen Laufwerken oder Netzwerkordnern kann durchaus nützlich sein. Die Möglichkeit, mehr "Zonen" für pkgman zu konfigurieren, wäre definitiv eine sinnvolle Funktion.

Ein solches System würde die Vorteile von hpkg, Verzeichnissen und Anwendungsbildern nutzen. Sie sind einzeln gut, aber zusammen werden sie unschlagbar.

Fazit

Für Haiku gibt es eine Infrastruktur, die eine einfache und raffinierte Benutzeroberfläche für PCs bietet und weit über das hinausgeht, was normalerweise für Linux-PCs bereitgestellt wird. Das Paketmanagementsystem .hpkg — eines dieser Beispiele, aber auch andere Teile des Systems sind von Raffinesse durchdrungen. Dennoch könnte Haiku von einer soliden Unterstützung für Kataloge und Anwendungsbilder profitieren. Wie das am besten erreicht werden kann, sollte mit Menschen besprochen werden, die Haiku, dessen Philosophie und Architektur viel besser verstehen als ich. Schließlich benutze ich Haiku erst etwas mehr als eine Woche. Nichtsdestotrotz denke ich, dass dieser frische Blick für Designer, Entwickler und Architekten von Haiku nützlich sein wird. Zumindest bin ich gerne bereit, als "Sparringspartner" für sie zu fungieren. Ich habe über 10 Jahre praktische Erfahrung mit Katalogen und Anwendungssätzen für Linux und möchte deren Anwendung für Haiku finden, da ich denke, dass sie perfekt zur Konzepterstellung passen. Die von mir vorgeschlagenen potenziellen Lösungen sind keineswegs die einzig richtigen für die von mir beschriebenen Probleme, und wenn das Haiku-Team beschließt, andere, elegantere Lösungen zu finden, unterstütze ich das voll und ganz. Grundsätzlich denke ich bereits über die Idee nach, wie man das System verbessern kann. hpkg Es wird immer noch erstaunlicher, ohne die Funktionsweise zu ändern. Offensichtlich hat das Haiku-Team schon lange über Anwendungssets nachgedacht, als sie das Paketverwaltungssystem implementierten, aber leider scheint die Idee in die 'Vergangenheit' gefallen zu sein. Vielleicht ist es an der Zeit, sie wiederzubeleben?

Probieren Sie es selbst! Das Haiku-Projekt bietet ISO-Images zum Herunterladen von DVD oder USB, die täglich.
Haben Sie Fragen? Wir laden Sie ein in unseren russischsprachigen Telegram-Kanal.

Fehlerübersicht: Wie man sich mit C und C++ selbst ins Knie schießt. Eine Sammlung von Rezepten für Haiku OS

Ab Autor Übersetzung: Dies ist der achte und letzte Artikel in der Reihe über Haiku.

Artikelübersicht: Erster Die zweite Dritte Vierter Fünfter Sechster Siebter

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?