🥇Noch etwas: Haiku-Anwendungspakete?

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

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

Zum vollständigen Verständnis: Ich bin der Ersteller und Autor von AppImage, einem Format zur Distribution von Linux-Anwendungen, das auf die Einfachheit von Mac abzielt und vollständige Kontrolle für Anwendungsautoren und Endbenutzer ermöglicht (möchten Sie mehr wissen – siehe. wiki und Dokumentation).

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

Lassen Sie uns theoretisch darüber nachdenken: Was müsste getan werden, um AppImage, oder etwas ähnliches, auf Haiku zu bekommen? Es ist nicht zwingend erforderlich, jetzt etwas zu erstellen, denn das System, das bereits in Haiku existiert, funktioniert erstaunlich, aber dieses gedankliche Experiment wäre interessant. Außerdem zeigt es die Raffinesse von Haiku im Vergleich zu Linux-Desktop-Umgebungen, wo ähnliche Dinge schrecklich schwierig sind (ich habe das Recht, so zu sprechen: Seit 10 Jahren kämpfe ich mit Debugging).

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

Was ist AppImage? Es ist ein System zur Veröffentlichung von Anwendungen von Drittanbietern (zum Beispiel, Ultimaker Cura), das es ermöglicht, Anwendungen nach Belieben zu veröffentlichen: Es ist nicht nötig, die Besonderheiten verschiedener Distributionen, Build-Politiken oder Build-Infrastrukturen zu kennen, es ist keine Unterstützung von Begleitern erforderlich, und sie weisen die Benutzer nicht darauf hin, was sie auf ihren Computern (nicht) installieren können. Man kann AppImage als etwas verstehen, das einem Mac-Paket im Format ähnelt .app innerhalb eines Disk-Images .dmg. Der Hauptunterschied besteht darin, dass Anwendungen nicht kopiert, sondern innerhalb von AppImage verbleiben, ähnlich wie Haiku-Pakete .hpkg eingehängt werden und niemals im herkömmlichen Sinne installiert werden.

AppImage hat im Laufe von mehr als 10 Jahren an Anziehungskraft und Popularität gewonnen: Linus Torvalds selbst hat es öffentlich anerkannt, und verbreitete Projekte (zum Beispiel LibreOffice, Krita, Inkscape, Scribus, ImageMagick) haben es als Hauptmethode zur Verbreitung kontinuierlicher oder nächtlicher Builds angenommen, die die installierten oder nicht installierten Anwendungen der Benutzer nicht stören. Allerdings halten sich Desktop-Umgebungen und Linux-Distributionen immer noch an das traditionelle, zentralisierte Verbreitungsmodell basierend auf Begleitsoftware und/oder fördern eigene Unternehmens- und/oder Ingenieurprogramme basierend auf Flatpak (RedHat, Fedora, GNOME) und Snappy (Canonical, Ubuntu). Es geht bis zu Absurditäten.

Wie alles funktioniert

Jedes AppImage enthält zwei Teile: einen kleinen doppelclickbaren ELF-Ausführungsprozess (genannt runtime.c), gefolgt von einem Abbild des Dateisystems SquashFS.

Das SquashFS-Dateisystem enthält die Nutzlast in Form der Anwendung und allem, was zu ihrem Start erforderlich ist, was vernünftigerweise nicht als Teil der Standardinstallation für jedes ausreichend aktuelle Zielsystem (Linux-Distribution) angesehen werden kann. Es enthält auch Metadaten wie den Namen der Anwendung, Icons, MIME-Typen usw.

Beim Start wird von runtime FUSE und squashfuse verwendet, um das Dateisystem zu mounten, woraufhin ein Punkt des Einstiegs (das sogenannte AppRun) innerhalb des gemounteten AppImage ausgeführt wird.
Das Dateisystem wird nach Abschluss des Prozesses ungemountet.

Scheint alles einfach zu sein.

Aber diese Faktoren erschweren alles:

Bei der Vielzahl von Linux-Distributionen kann man schon nichts mehr als „vernünftig“ bezeichnen, was „Teil der Standardinstallation für jedes aktuelle Zielsystem“ ist. Wir umgehen dieses Problem, indem wir eine excludelisterstellen, die festlegt, was in das AppImage gepackt wird und was woanders beschafft werden muss. Dabei treffen wir manchmal falsche Entscheidungen, auch wenn insgesamt alles gut funktioniert. Aus diesem Grund empfehlen wir den Paketautoren, AppImages auf allen Zielsystemen (Distributionen) zu testen.
Die Anwendungen in Form der Nutzlast müssen im Dateisystem verschiebbar sein. Leider sind viele Anwendungen fest auf absolute Pfade zu Ressourcen in /usr/sharefestgelegt. Das muss irgendwie korrigiert werden. Darüber hinaus müssen entweder LD_LIBRARY_PATHexportiert oder rpath Damit der Loader die zugehörigen Bibliotheken finden kann. Der erste Ansatz hat seine eigenen Nachteile (die sich durch komplizierte Methoden umgehen lassen), während der zweite einfach unhandlich ist.
Die größte UX-Falle für Benutzer ist, dass man das Ausführungsbit für die AppImage-Datei nach dem Herunterladen setzen muss. 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 Benutzer umständlich. Als Umgehungslösung haben wir die Installation eines kleinen Dienstes vorgeschlagen, der die AppImage-Dateien überwacht und ihnen das Ausführungsbit zuweist. Rein theoretisch ist das keine optimale Lösung, da es nicht „out of the box“ funktioniert. Linux-Distributionen liefern diesen Dienst nicht mit, daher ist für die Benutzer „out of the box“ alles schlecht.
Linux-Benutzer erwarten, dass eine neue Anwendung ein Symbol im Startmenü hat. Man kann der System nicht sagen: „Sieh mal, da ist eine neue Anwendung, lass uns arbeiten“. Stattdessen muss man gemäß der XDG-Spezifikation die Datei .desktop an den richtigen Ort in /usr für eine systemweite Installation kopieren oder in $HOME für eine persönliche Installation. Symbole bestimmter Größen müssen gemäß der XDG-Spezifikation an bestimmten Orten in usr oder $HOMEplatzieren und anschließend Befehle in der Arbeitsumgebung zum Aktualisieren des Symbol-Caches ausführen oder hoffen, dass der Desktop-Manager es erkennt und alles automatisch findet. Gleiches gilt für MIME-Typen. Als Umgehungslösung wird vorgeschlagen, denselben Dienst zu verwenden, der neben der Einrichtung des Ausführungsbits auch, falls vorhanden, Symbole usw. aus der AppImage in die entsprechenden Orte gemäß XDG kopiert. Bei der Löschung oder Verschiebung wird der Dienst voraussichtlich alles sauber entfernen. Natürlich gibt es Unterschiede im Verhalten der einzelnen Desktop-Umgebungen, in den Formaten der Grafikdateien, deren Größen, Speicherorten und Methoden zur Aktualisierung der Caches, was das Problem erzeugt. Kurz gesagt, diese Methode ist ein Workaround.
Wenn all dies nicht ausreicht, fehlt im Dateimanager immer noch das AppImage-Symbol. In der Linux-Welt wurde bisher keine Entscheidung über die Einführung von elficon getroffen (trotz der diskutiert und Implementierung.), so dass es unmöglich ist, das Symbol direkt in die Anwendung einzufügen. Daher haben Anwendungen im Dateimanager keine eigenen Symbole (egal, ob AppImage oder etwas anderes), sie existieren nur im Startmenü. Als Umgehung nutzen wir Thumbnails — ein 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 des Ausführungsbits auch als „Thumbnail-Generator“, der Thumbnails von Symbolen erstellt und an den entsprechenden Stellen speichert. /usr und $HOME. Außerdem führt dieser Dienst eine Bereinigung durch, wenn ein AppImage gelöscht oder verschoben wird. Da sich jeder Desktop-Manager etwas anders verhält, zum Beispiel, in welchen Formaten er Symbole akzeptiert, in welchen Größen oder an welchen Orten, ist das alles wirklich schmerzhaft.
Die Anwendung stürzt einfach ab, wenn beim Ausführen Fehler auftreten (zum Beispiel, wenn es eine Bibliothek gibt, die nicht Teil des Basissystems ist und nicht mit dem AppImage geliefert wird), und niemand sagt dem Benutzer im GUI, was genau passiert. Wir haben begonnen, dies zu umgehen, indem wir einer Benachrichtigung am Desktop, und das bedeutet, dass wir Fehler aus der Befehlszeile abfangen müssen, sie in verständliche Benutzerbenachrichtigungen umwandeln, die dann noch auf dem Desktop angezeigt werden müssen. Und natürlich verarbeitet jede Desktop-Umgebung sie etwas anders.
Derzeit (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, und 2.png — mit GIMP.

Der Speicherort für cross-desktop Spezifikationen, die in GNOME, KDE und Xfce verwendet werden, ist freedesktop.org.

Ein Niveau an Raffinesse zu erreichen, das tief in das Haiku-Arbeitsumfeld verwoben ist, ist schwierig, um nicht zu sagen „unmöglich“, aufgrund der Spezifikationen XDG von freedesktop.org für cross-desktop sowie den Umsetzungen der Desktop-Manager, die auf diesen Spezifikationen basieren. Ein Beispiel ist ein allgemeines Systemsymbol für Firefox: Offensichtlich kam den Autoren von XDG nicht in den Sinn, dass der Benutzer mehrere Versionen derselben Anwendung installiert haben könnte.

Symbole verschiedener Firefox-Versionen.

Es interessierte mich, 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 Arno Gourdol, einer der ersten Ingenieure von Mac OS X, gesagt hat:

Wir wollten, dass die Installation einer Anwendung so einfach ist, wie das Ziehen des Anwendungssymbols irgendwoher (Server, externe Festplatte) auf das Laufwerk Ihres Computers. Zu diesem Zweck sind im Anwendungs-Paket alle Informationen gespeichert, einschließlich der Symbole, der Version, des verarbeiteten Dateityps, der URL-Schemata, die das System zur Verarbeitung der Anwendung kennen muss. Dies schließt auch die Informationen für die 'zentralisierte Speicherung' in der Datenbank Icon Services und Launch Services ein. Um die Leistung der Anwendung zu unterstützen, werden sie an mehreren 'gut bekannten' Orten 'entdeckt': im System- und Benutzerverzeichnis Anwendungen sowie an einigen anderen automatisch, wenn der Benutzer im Finder in das Verzeichnis gewechselt ist, das die Anwendung enthält. In der Praxis hat das sehr gut funktioniert.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 Session 144 — Mac OS X: Paketierung von Anwendungen und Druck von Dokumenten.

Nichts Derartiges ist in der Infrastruktur der Arbeitsumgebungen von Linux vorhanden, daher suchen wir nach alternativen Wegen, um die strukturellen Einschränkungen im Projekt AppImage zu umgehen.

Eilt Haiku zur Hilfe?

Außerdem sind die Linux-Plattformen als Basis für Arbeitsumgebungen in der Regel so unzureichend spezifiziert, dass viele Dinge, die in einem konsistenten System mit vollem Stack recht einfach sind, durch Fragmentierung und Komplexität in Linux frustrierend sind. Ich widmete ein ganzes Referat den Fragen im Zusammenhang mit der Linux-Plattform für Arbeitsumgebungen (kenntnisreiche Entwickler bestätigten: Das wird noch lange so bleiben).

Mein Vortrag über die Probleme der Linux-Arbeitsumgebungen im Jahr 2018

Selbst Linus Torvalds gab zu, dass die Idee der Arbeitsumgebungen aufgrund der Fragmentierung nicht gelungen ist.

Es ist schön, Haiku zu sehen!

Mit Haiku wird alles unglaublich einfach.

Obwohl der naive Ansatz zur "Übertragung" von AppImage auf Haiku darin besteht, lediglich zu versuchen, die Komponenten (hauptsächlich runtime.c und den Service) zu kompilieren (was möglicherweise sogar möglich ist!), wird dies für Haiku nicht besonders nützlich sein. Denn in Wirklichkeit sind die meisten dieser Probleme bereits für Haiku gelöst und konzeptionell gut begründet. Haiku bietet genau die Bausteine für die Systeminfrastruktur, die ich so lange in Arbeitsumgebungen unter Linux gesucht habe und nicht glauben konnte, dass sie dort nicht vorhanden sind. Nämlich:

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

ELF-Dateien, die kein Ausführungsbit haben, erhalten dies automatisch durch einen Doppelklick im Dateimanager.
Anwendungen können eingebettete Ressourcen haben, wie z. B. Icons, die im Dateimanager angezeigt werden. Es ist nicht nötig, eine Menge Bilder in spezielle Icon-Verzeichnisse zu kopieren, und folglich muss man sie nach dem Löschen oder Verschieben der Anwendung nicht bereinigen.
Es gibt eine Datenbank zur Verknüpfung von Anwendungen mit Dokumenten, es ist nicht erforderlich, irgendwelche Dateien dafür zu kopieren.
Im lib/-Verzeichnis werden die Bibliotheken standardmäßig neben dem ausführbaren Datei gesucht.
Es gibt keine zahlreichen Distributionen und Desktop-Umgebungen; alles, was funktioniert, funktioniert überall.
Es gibt kein separates Startmodul, das sich vom Verzeichnis Applications unterscheidet.
In den Anwendungen gibt es keine fest einprogrammierten absoluten Pfade zu ihren Ressourcen; es gibt spezielle Funktionen zur Bestimmung des Standorts zur Laufzeit.
Die Idee von komprimierten Dateisystemabbildern ist integriert: das ist jedes hpkg-Paket. Alle werden vom Kernel eingebunden.
Jede Datei wird von der Anwendung geöffnet, die sie erstellt hat, es sei denn, es wird ausdrücklich etwas anderes angegeben. Wie cool ist das!

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

Es sieht so aus, als ob viele Workarounds und Hacks, die für AppImage unter Linux notwendig sind, in Haiku nicht mehr erforderlich sind, das in seiner Basis Einfachheit und Raffinesse hat, die es ihm ermöglicht, die meisten unserer Bedürfnisse zu erfüllen.

Sind am Ende des Tages Haiku-Anwendungspakete notwendig?

Das führt zu einer wichtigen Frage. Wäre es lohnenswert, ein System wie AppImage auf Haiku zu erstellen, wenn das deutlich einfacher wäre als auf Linux? Oder hat Haiku mit ihrem Paketverwaltungssystem hpkg die Notwendigkeit für eine solche Idee bereits beseitigt? Um das zu beantworten, müssen wir auf die Motivation für die Existenz von AppImages schauen.

Blick aus der Sicht des Benutzers

Betrachten wir unseren Endbenutzer:

Ich möchte eine Anwendung installieren, ohne nach dem Administratorpasswort (root) gefragt zu werden. Auf Haiku gibt es kein Konzept eines Administrators, der Benutzer hat die volle Kontrolle, da es sich um ein persönliches System handelt! (Prinzipiell könnte man sich das auch im Mehrbenutzermodus vorstellen, ich hoffe, die Entwickler behalten die Einfachheit bei)
Ich möchte die neuesten und besten Versionen von Anwendungen erhalten, ohne warten zu müssen, bis sie in meinem Distribution erscheinen (meistens bedeutet das "nie", es sei denn, man aktualisiert das gesamte Betriebssystem). Auf Haiku wird dies durch schwebende Versionen "gelöst". Das bedeutet, dass es die Möglichkeit gibt, die neuesten und besten Versionen von Anwendungen zu erhalten, aber dafür muss man ständig den Rest des Systems aktualisieren, was es effektiv zu einem "beweglichen Ziel" macht..
Ich möchte mehrere Versionen derselben Anwendung nebeneinander haben, da ich nicht wissen kann, was in der letzten Version kaputt gemacht wurde oder, sagen wir, als Webentwickler meine Arbeit unter verschiedenen Browserversionen testen muss. In Haiku ist das erste Problem gelöst, aber nicht das zweite. Updates können zurückgesetzt werden, aber nur für das gesamte System, es ist (soweit ich weiß) nicht möglich, beispielsweise mehrere Versionen von WebPositive oder LibreOffice gleichzeitig auszuführen.

Einer der Entwickler schreibt:

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

Ich möchte Anwendungen dort speichern, wo ich es mag, und nicht auf der Bootdisk. Auf den Laufwerken habe ich oft nicht genügend Platz, also muss ich eine externe Festplatte oder ein Netzwerkverzeichnis für die Speicherung von Anwendungen (aller Versionen, die ich heruntergeladen habe) anschließen. Wenn ich so eine Festplatte anschließe, müssen die Anwendungen mit einem Doppelklick starten. Haiku speichert alte Versionen von Paketen, aber ich weiß nicht, wie ich sie auf eine externe Festplatte verschieben kann und wie ich die Anwendungen von dort dann aufrufen kann.

Kommentar des Entwicklers:

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

Ich brauche keine Millionen von Dateien, die über das Dateisystem verteilt sind und die ich nicht selbstständig verwalten kann. Ich möchte eine Datei pro Anwendung, die ich einfach herunterladen, verschieben und löschen kann. Auf Haiku wird dieses Problem durch Pakete gelöst .hpkg, die beispielsweise Python von tausenden von Dateien in eine einzige übertragen. Aber wenn es zum Beispiel Scribus gibt, das Python verwendet, muss ich mindestens mit zwei Dateien umgehen. Und ich muss darauf achten, die Versionen, die miteinander funktionieren, zu speichern.

Zahlreiche AppImage-Versionen, die nebeneinander auf einem Linux laufen

Ein Blick aus der Sicht eines Anwendungsentwicklers

Lassen Sie uns die Perspektive eines Anwendungsentwicklers betrachten:

Ich möchte das Benutzererlebnis insgesamt steuern. Ich möchte mich nicht auf ein Betriebssystem verlassen, 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 verbreite. Und vielleicht möchte ich den Zugriff auf diese Seite monetarisieren, wer weiß? Was muss ich dort für Haiku bereitstellen? Eine Datei .hpkg mit Abhängigkeiten nur von HaikuPorts
Mein Software benötigt bestimmte Versionen anderer Software. Zum Beispiel ist bekannt, dass Krita eine angepasste Version von Qt benötigt, oder Qt, das genau auf eine bestimmte Version von Krita abgestimmt ist, zumindest bis die Korrekturen zurück in Qt fließen. Es ist möglich, die eigene Qt-Version in einem Paket zu verpacken .hpkg, aber das wird wahrscheinlich nicht begrüßt.

Eine normale Download-Seite für Anwendungen. Was sollte ich hier für Haiku bereitstellen?

Werden Bundles (existierend in Form von Anwendungsordnern, wie AppDir oder .app im Apple-Stil) und/oder Images (in Form von stark modifizierten AppImages oder .dmg Sind Anwendungen von Apple eine nützliche Ergänzung für die Arbeitsumgebung von Haiku? Oder wird dies das Gesamtkonzept verwässern und zu einer Fragmentierung führen, wodurch es komplizierter wird? Ich bin hin- und hergerissen: Auf der einen Seite basiert die Schönheit und Raffinesse von Haiku darauf, dass es normalerweise einen Weg gibt, etwas zu tun und nicht viele. Auf der anderen Seite ist ein Großteil der Infrastruktur für Kataloge und/oder Anwendungspakete bereits vorhanden, daher verlangt das System danach, dass auch die verbleibenden Prozentsätze an ihren Platz kommen.

Laut dem Entwickler mr. waddlesplash

Auf Linux sind sie (Kataloge und Anwendungspakete, Anm. d. Übersetzers) wahrscheinlich eine technische Lösung für systembedingte Probleme. In Haiku ziehen wir es vor, einfach die systembedingten Probleme zu lösen.

Was denken Sie darüber?

Bevor Sie antworten…

Warten Sie, wir machen einen schnellen Realitätscheck: Tatsächlich Anwendungskataloge sind bereits Teil von Haiku:

Anwendungskataloge existieren bereits in Haiku, werden aber noch nicht im Dateimanager unterstützt.

Sie werden einfach nicht so gut unterstützt wie beispielsweise im Macintosh Finder. Wie cool wäre es, wenn der Katalog von QtCreator in der oberen linken Ecke den Namen und das Symbol 'QtCreator' hätte, das die Anwendung durch Doppelklick startet?

Ich habe bereits gefragt:

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

Gibt es bereits eine Antwort von 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 so lange unterstützen, wie es nötig ist, bis jemand in der Lage ist, ihre Dateiformate korrekt zu lesen oder Eins-zu-eins-Funktionalität zu gewährleisten. Unser Bestreben, BeOS R5-Anwendungen in Haiku zu unterstützen, ist ein direktes Beispiel dafür...

Das ist richtig!

Welchen Handlungsplan sollte Haiku verfolgen?

Ich kann mir ein harmonisches Nebeneinander von hpkg, Katalogen und Anwendungsgrafiken vorstellen:

Systemsoftware verwendet .hpkg
Für die am häufigsten verwendete Software (insbesondere für solche, die schwankende Veröffentlichungen planen müssen) wird genutzt .hpkg (ungefähr 80 % aller Fälle)
Einige, die über .hpkg, Anwendungen werden von der Umstellung auf Infrastruktur mit Anwendungskatalogen (zum Beispiel QtCreator) profitieren: Sie werden in Form von .hpkg, wie zuvor.

mr. waddlesplash schreibt:

Wenn alles, was benötigt wird, die Anzeige von Anwendungen in /system/apps, sollte die Verwaltung der Kataloge im Deskbar für die Benutzer benutzerfreundlicher gestaltet werden, da /system/apps nicht dafür gedacht ist, dass Benutzer es regelmäßig öffnen und anschauen (im Gegensatz zu MacOS). Für solche Situationen hat Haiku ein anderes Paradigma, aber diese Option ist theoretisch akzeptabel.

Haiku erhält die Infrastruktur für die Ausführung von Anwendungsabbildern, nächtlichen, kontinuierlichen und Test-Softwareversionen sowie für Fälle, in denen der Benutzer es «in der Zeit einfrieren» möchte, für private und interne Software und andere spezielle Anwendungsfälle (etwa 20 % aller). Diese Abbilder enthalten die für die Ausführung der Anwendung erforderlichen Dateien .hpkg, die vom System bereitgestellt werden, und werden nach Abschluss der Anwendung wieder unmontiert. (Es wäre möglich, dass der Dateimanager Dateien .hpkg in Anwendungsabbilder einfügt, automatisch oder auf Benutzeranfrage – so wie wenn man eine Anwendung in ein Netzwerkverzeichnis oder auf eine externe Festplatte zieht. Das ist einfach fantastisch! Oder besser gesagt: Poesie – ein Haiku.) Andererseits könnte der Benutzer möchten, dass der Inhalt des Abbilds als Dateien installiert wird.hpkg, die dann genauso aktualisiert und verarbeitet werden, als ob sie über HaikuDepot installiert worden wären… Man sollte ein Brainstorming durchführen).

Zitat von mr. waddlesplash:

Das Starten von Anwendungen von externen Festplatten oder Netzwerkverzeichnissen könnte potenziell nützlich sein. Und die Möglichkeit, mehr «Zonen» für pkgman anzupassen, wäre definitiv eine gute Funktion.

Ein solches System würde die Vorteile von hpkg, Katalogen und Anwendungsabbildern nutzen. Sie sind einzeln gut, aber zusammen unschlagbar.

Fazit

Für Haiku gibt es eine Infrastruktur, die eine einfache und raffinierte Benutzeroberfläche für PCs bereitstellt und weit über das hinausgeht, was normalerweise für PCs unter Linux angeboten wird. Das Paketverwaltungssystem .hpkg — ein Beispiel dafür, aber auch die anderen Teile des Systems sind von Raffinesse durchdrungen. Dennoch würde die richtige Unterstützung der Kataloge und der Anwendungsmuster von Haiku profitieren. Wie dies am besten zu erreichen ist, sollte mit Menschen diskutiert werden, die Haiku, seine Philosophie und Architektur viel besser kennen als ich. Schließlich benutze ich Haiku seit etwas mehr als einer Woche. Dennoch glaube ich, dass dieser frische Blick für Designer, Entwickler und Architekten von Haiku hilfreich sein wird. Zumindest bin ich gerne bereit, für sie „Sparringspartner“ zu sein. Ich habe über 10 Jahre praktische Erfahrung mit Katalogen und Anwendungssätzen für Linux, und ich würde gerne Möglichkeiten finden, diese für Haiku anzuwenden, dessen Konzept ich für ideal halte. Die von mir vorgeschlagenen potenziellen Lösungen sind keineswegs die einzig richtigen für die Probleme, die ich beschrieben habe, und wenn das Haiku-Team beschließt, nach anderen, eleganteren Lösungen zu suchen – ich unterstütze das voll und ganz. Grundsätzlich denke ich bereits über die Idee nach, wie das System hpkg noch erstaunlicher gemacht werden kann, ohne die Funktionsweise zu ändern. Es scheint, dass das Haiku-Team schon lange über Anwendungssätze bei der Einführung des Paketmanagementsystems nachgedacht hat, doch leider ist (meiner Meinung nach) die Idee in die „Veralteten“ eingegangen. Vielleicht ist es an der Zeit, sie wiederzubeleben?

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

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

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

Artikelübersicht: Erster Zweiter Dritte Vierter Fünfter Sechste Siebte

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.