TL; DR: Kann Haiku ordnungsgemäße Unterstützung für Anwendungspakete erhalten, z. B. Anwendungsverzeichnisse (wie .app auf Mac) und/oder Anwendungsbilder (Linux AppImage)? Ich denke, dass dies eine lohnenswerte Ergänzung wäre, die einfacher korrekt zu implementieren ist als andere Systeme, da der Großteil der Infrastruktur bereits vorhanden ist.
Ich habe Haiku entdeckt, ein unerwartet gutes System. Nun, da ich mich schon lange für Verzeichnisse und Anwendungsbilder interessiere (inspiriert von der Einfachheit des Macintosh), ist es nicht verwunderlich, dass mir eine Idee kam ...
Zum vollständigen Verständnis: Ich bin der Schöpfer und Autor von AppImage, einem Linux-Anwendungsverteilungsformat, das auf Mac-Einfachheit abzielt und Anwendungsautoren und Endbenutzern die volle Kontrolle gibt (mehr erfahren Sie unter и ).
Was wäre, wenn wir ein AppImage für Haiku erstellen würden?
Denken wir ein wenig rein theoretisch darüber nach: Was muss getan werden, um zu bekommen , oder etwas Ähnliches, auf Haiku? Es ist nicht notwendig, jetzt etwas zu erschaffen, denn das System, das bereits im Haiku existiert, funktioniert erstaunlich gut, aber ein imaginäres Experiment wäre schön. Es zeigt auch die Ausgereiftheit von Haiku im Vergleich zu Linux-Desktop-Umgebungen, wo solche Dinge furchtbar schwierig sind (ich habe das Recht, das zu sagen: Ich habe seit 10 Jahren mit dem Debuggen zu kämpfen).
Auf dem Macintosh System 1 wurde jede Anwendung als separate Datei im Finder „verwaltet“. Mit AppImage versuche ich, die gleiche Benutzererfahrung unter Linux wiederherzustellen.
Erstens: Was ist ein AppImage? Hierbei handelt es sich um ein System zur Freigabe von Drittanwendungen (z. B. ), sodass Anwendungen veröffentlicht werden können, wann und wie sie wollen: Es besteht keine Notwendigkeit, die Besonderheiten verschiedener Distributionen, Build-Richtlinien oder Build-Infrastruktur zu kennen, es ist keine Unterstützung durch den Betreuer erforderlich und sie sagen den Benutzern nicht, was sie installieren können (nicht). auf ihren Computern. AppImage sollte im Format als etwas Ähnliches wie ein Mac-Paket verstanden werden .app im Disk-Image .dmg. Der Hauptunterschied besteht darin, dass Anwendungen nicht kopiert werden, sondern für immer im AppImage verbleiben, ähnlich wie Haiku-Pakete .hpkg montiert und nie im üblichen Sinne installiert.
Im Laufe seines mehr als zehnjährigen Bestehens hat AppImage an Attraktivität und Popularität gewonnen: Linus Torvalds selbst hat es öffentlich befürwortet, und gängige Projekte (z. B. LibreOffice, Krita, Inkscape, Scribus, ImageMagick) haben es als Hauptmethode übernommen um kontinuierliche oder nächtliche Builds zu verteilen, ohne installierte oder deinstallierte Benutzeranwendungen zu beeinträchtigen. Allerdings halten sich Linux-Desktop-Umgebungen und -Distributionen meist immer noch an das traditionelle, zentralisierte, auf Betreuern basierende Distributionsmodell und/oder fördern ihre eigenen Unternehmensgeschäfts- und/oder Engineering-Programme, die darauf basieren (RedHat, Fedora, GNOME) und (Kanonisch, Ubuntu). Es kommt .
Wie funktioniert es
- Jedes AppImage enthält 2 Teile: ein kleines Doppelklick-ELF (sog.
runtime.c), gefolgt von einem Dateisystem-Image .
- Das SquashFS-Dateisystem enthält die Nutzlast der Anwendung und alles, was zu deren Ausführung erforderlich ist, was bei klarem Verstand nicht als Teil der Standardinstallation für jedes relativ aktuelle Zielsystem (Linux-Distribution) angesehen werden kann. Es enthält auch Metadaten wie den Anwendungsnamen, Symbole, MIME-Typen usw. usw.
- Bei der Ausführung durch den Benutzer verwendet die Laufzeit FUSE und Squashfuse, um das Dateisystem zu mounten, und kümmert sich dann um die Ausführung eines Einstiegspunkts (auch bekannt als AppRun) innerhalb des gemounteten AppImage.
Das Dateisystem wird nach Abschluss des Vorgangs ausgehängt.
Alles scheint einfach.
Und diese Dinge erschweren alles:
- Bei einer solchen Vielfalt an Linux-Distributionen kann nichts „bei klarem Verstand“ als „Teil der Standardinstallation für jedes neue Zielsystem“ bezeichnet werden. Wir umgehen dieses Problem, indem wir bauen So können Sie bestimmen, was im AppImage verpackt wird und was woanders hingebracht werden muss. Gleichzeitig vermissen wir manchmal, obwohl im Allgemeinen alles großartig funktioniert. Aus diesem Grund empfehlen wir Paketerstellern, AppImages auf allen Zielsystemen (Distributionen) zu testen.
- Anwendungsnutzlasten müssen im gesamten Dateisystem verschiebbar sein. Leider verfügen viele Anwendungen über fest codierte absolute Pfade, beispielsweise zu Ressourcen in
/usr/share. Das muss irgendwie behoben werden. Darüber hinaus müssen Sie entweder exportierenLD_LIBRARY_PATH, oder reparierenrpathdamit der Loader verwandte Bibliotheken finden kann. Die erste Methode hat ihre Nachteile (die auf komplexe Weise überwunden werden können), und die zweite ist einfach umständlich. - Das ist die größte UX-Falle für Benutzer AppImage-Datei nach dem Herunterladen. Ob Sie es glauben oder nicht, für manche stellt dies eine echte Hürde dar. Das Setzen des Ausführbarkeitsbits ist selbst für erfahrene Benutzer umständlich. Als Workaround haben wir die Installation eines kleinen Dienstes vorgeschlagen, der AppImage-Dateien überwacht und deren Ausführbarkeitsbit festlegt. In seiner reinen Form ist es nicht die beste Lösung, da es nicht sofort funktioniert. Linux-Distributionen bieten diesen Dienst nicht an, daher haben Benutzer sofort ein schlechtes Erlebnis.
- Linux-Benutzer erwarten, dass eine neue Anwendung ein Symbol im Startmenü hat. Man kann dem System nicht sagen: „Schau, es gibt eine neue Anwendung, lass uns arbeiten.“ Stattdessen müssen Sie gemäß der XDG-Spezifikation die Datei kopieren
.desktopan der richtigen Stelle in/usrfür eine systemweite Installation, oder in$HOMEfür Einzelpersonen. Symbole bestimmter Größen müssen gemäß der XDG-Spezifikation an bestimmten Stellen in platziert werdenusroder$HOME, und führen Sie dann Befehle in der Arbeitsumgebung aus, um den Symbolcache zu aktualisieren, oder hoffen Sie, dass der Arbeitsumgebungsmanager es herausfindet und alles automatisch erkennt. Das Gleiche gilt für MIME-Typen. Um dieses Problem zu umgehen, wird vorgeschlagen, denselben Dienst zu verwenden, der zusätzlich zum Setzen des Ausführbarkeitsflags dies auch tut, wenn Symbole usw. vorhanden sind. in AppImage kopieren Sie sie laut XDG von AppImage an die richtigen Stellen. Beim Löschen oder Verschieben wird vom Dienst erwartet, dass er alles löscht. Natürlich gibt es Unterschiede im Verhalten der einzelnen Arbeitsumgebungen, in den Grafikdateiformaten, deren Größen, Speicherorten und Methoden zur Cache-Aktualisierung, was ein Problem darstellt. Kurz gesagt, diese Methode ist eine Krücke. - Wenn das oben Genannte nicht ausreicht, gibt es im Dateimanager immer noch kein AppImage-Symbol. Die Linux-Welt hat sich noch nicht für die Implementierung von elficon entschieden (trotz и ), sodass es nicht möglich ist, das Symbol direkt in die Anwendung einzubetten. Es stellt sich also heraus, dass 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, einen Mechanismus, der ursprünglich dafür entwickelt wurde, Desktop-Managern die Anzeige von Miniaturvorschaubildern von Grafikdateien als Symbole zu ermöglichen. Folglich fungiert der Dienst zum Setzen des Ausführbarkeitsbits auch als „Miniaturisierer“, indem er Miniaturansichten von Symbolen erstellt und an die entsprechenden Stellen schreibt
/usrи$HOME. Dieser Dienst führt auch eine Bereinigung durch, wenn das AppImage gelöscht oder verschoben wird. Aufgrund der Tatsache, dass sich jeder Desktop-Manager etwas anders verhält, beispielsweise in welchen Formaten er Symbole akzeptiert, in welchen Größen oder an welchen Stellen, ist das alles sehr schmerzhaft. - Die Anwendung stürzt bei der Ausführung einfach ab, wenn Fehler auftreten (zum Beispiel gibt es eine Bibliothek, die nicht Teil des Basissystems ist und nicht in AppImage bereitgestellt wird), und es gibt niemanden, der dem Benutzer in der GUI sagt, was genau passiert. Wir haben begonnen, dies zu umgehen, indem wir verwendet haben auf dem Desktop, was bedeutet, dass wir Fehler über die Befehlszeile abfangen und sie in vom Benutzer verständliche Meldungen umwandeln müssen, die dann auf dem Desktop angezeigt werden müssen. Und natürlich geht jede Desktop-Umgebung etwas anders damit um.
- Im Moment (September 2019 – Anmerkung des Übersetzers) habe ich keine einfache Möglichkeit gefunden, dem System mitzuteilen, dass die Datei
1.pngmuss mit Krita geöffnet werden, und2.png- mit GIMP.
Speicherort für Desktop-übergreifende Spezifikationen, die in verwendet werden , и ist freedesktop.org
Aufgrund der Vorgaben ist es schwierig, wenn nicht sogar unmöglich, den Grad an Raffinesse zu erreichen, der tief in der Haiku-Arbeitsumgebung verankert ist für Cross-Desktop, sowie Implementierungen von Desktop-Managern basierend auf diesen Spezifikationen. Als Beispiel können wir ein systemweites Firefox-Symbol nennen: Anscheinend haben die Autoren von XDG nicht einmal gedacht, dass ein Benutzer mehrere Versionen derselben Anwendung installiert haben könnte.
Symbole für verschiedene Versionen von Firefox
Ich habe mich gefragt, was die Linux-Welt von Mac OS X lernen könnte, um die Systemintegration nicht zu vermasseln. Wenn Sie Zeit haben und sich dafür interessieren, lesen Sie unbedingt, was Arnaud Gurdol, einer der ersten Mac OS X-Ingenieure, gesagt hat:
Wir wollten die Installation der Anwendung so einfach machen wie das Ziehen des Anwendungssymbols von irgendwo (Server, externes Laufwerk) auf Ihr Computerlaufwerk. Zu diesem Zweck speichert das Anwendungspaket alle Informationen, einschließlich Symbole, Version, verarbeiteter Dateityp und Typ der URL-Schemata, die das System kennen muss, um die Anwendung zu verarbeiten. Dazu gehören auch Informationen zur „zentralen Speicherung“ in der Icon Services- und Launch Services-Datenbank. Um die Leistung zu unterstützen, werden Anwendungen an mehreren „bekannten“ Orten „entdeckt“: den System- und Benutzeranwendungsverzeichnissen und einigen anderen automatisch, wenn der Benutzer zum Finder in dem Verzeichnis navigiert, das die Anwendung enthält. In der Praxis hat das sehr gut funktioniert.
Apple WWDC 2000 Sitzung 144 – Mac OS X: Anwendungen packen und Dokumente drucken.
Auf Linux-Desktops gibt es nichts Vergleichbares wie diese Infrastruktur, daher suchen wir nach Workarounds zur Umgehung der strukturellen Einschränkungen im AppImage-Projekt.
Kommt Haiku zur Rettung?
Und noch etwas: Linux-Plattformen als Basis von Desktop-Umgebungen sind in der Regel so unzureichend spezifiziert, dass viele Dinge, die in einem konsistenten Full-Stack-System recht einfach sind, unter Linux frustrierend fragmentiert und komplex sind. Ich habe einen ganzen Bericht den Problemen im Zusammenhang mit der Linux-Plattform für Desktop-Umgebungen gewidmet (sachkundige Entwickler haben bestätigt, dass alles noch sehr lange so bleiben wird).
Mein Bericht zu den Problemen von Linux-Desktop-Umgebungen im Jahr 2018
Sogar Linus Torvalds gab zu, dass die Fragmentierung der Grund für das Scheitern der Arbeitsplatzidee war.
Schön, Haiku zu sehen!
Haiku macht alles erstaunlich einfach
Während der naive Ansatz beim „Portieren“ von AppImage nach Haiku darin besteht, einfach zu versuchen, seine Komponenten zu erstellen (hauptsächlich runtime.c und service) (was möglicherweise sogar möglich ist!), wird dies Haiku keinen großen Nutzen bringen. Denn tatsächlich werden die meisten dieser Probleme im Haiku gelöst und sind konzeptionell fundiert. Haiku bietet genau die Systeminfrastrukturbausteine, nach denen ich in Linux-Desktop-Umgebungen so lange gesucht habe und von denen ich nicht glauben konnte, dass sie nicht da sind. Nämlich:
Ob Sie es glauben oder nicht, viele Linux-Benutzer können damit nicht umgehen. Bei Haiku geschieht alles automatisch!
- ELF-Dateien, die kein Ausführbarkeitsbit haben, erhalten eines automatisch, wenn im Dateimanager darauf doppelgeklickt wird.
- Anwendungen können über integrierte Ressourcen verfügen, z. B. Symbole, die im Dateimanager angezeigt werden. Es ist nicht erforderlich, eine Reihe von Bildern in spezielle Verzeichnisse mit Symbolen zu kopieren und sie daher nach dem Löschen oder Verschieben der Anwendung nicht zu bereinigen.
- Für die Verknüpfung von Bewerbungen mit Dokumenten steht eine Datenbank zur Verfügung, ein Kopieren von Dateien ist hierfür nicht erforderlich.
- Im lib/-Verzeichnis neben der ausführbaren Datei wird standardmäßig nach Bibliotheken gesucht.
- Es gibt keine zahlreichen Distributionen und Desktop-Umgebungen; was funktioniert, funktioniert überall.
- Es gibt kein separates Modul zum Ausführen, das sich vom Anwendungsverzeichnis unterscheidet.
- Anwendungen verfügen nicht über integrierte absolute Pfade zu ihren Ressourcen; sie verfügen über spezielle Funktionen zur Bestimmung des Speicherorts zur Laufzeit.
- Die Idee komprimierter Dateisystem-Images wurde eingeführt: Dies ist ein beliebiges HPKG-Paket. Alle werden vom Kernel gemountet.
- Jede Datei wird von der Anwendung geöffnet, die sie erstellt hat, sofern Sie nicht ausdrücklich etwas anderes angeben. Wie cool ist das!
Zwei PNG-Dateien. Beachten Sie die unterschiedlichen Symbole, die darauf hinweisen, dass sie bei einem Doppelklick von verschiedenen Anwendungen geöffnet werden. Beachten Sie auch das Dropdown-Menü „Öffnen mit:“, in dem der Benutzer eine einzelne Anwendung auswählen kann. Wie einfach!
Es sieht so aus, als ob viele der Krücken und Problemumgehungen, die AppImage unter Linux erfordert, bei Haiku überflüssig werden, das im Kern über die Einfachheit und Raffinesse verfügt, die es für die meisten unserer Anforderungen geeignet macht.
Braucht Haiku überhaupt App-Pakete?
Dies führt zu einer großen Frage. Wenn es um eine Größenordnung einfacher wäre, ein System wie AppImage unter Haiku zu erstellen als unter Linux, wäre es dann sinnvoll, es zu tun? Oder hat Haiku mit seinem hpkg-Paketsystem die Notwendigkeit, eine solche Idee zu entwickeln, effektiv überflüssig gemacht? Um dies zu beantworten, müssen wir uns die Motivation hinter der Existenz von AppImages ansehen.
Benutzerperspektive
Schauen wir uns unseren Endbenutzer an:
- Ich möchte eine Anwendung installieren, ohne nach einem Administratorkennwort (Root-Kennwort) zu fragen. Bei Haiku gibt es kein Konzept für einen Administrator, der Benutzer hat die volle Kontrolle, da es sich um ein persönliches System handelt! (Im Prinzip kann man sich das im Mehrspielermodus vorstellen, ich hoffe, die Entwickler halten es einfach)
- Ich möchte die neuesten und besten Versionen von Anwendungen erhalten, ohne darauf warten zu müssen, dass sie in meiner Distribution erscheinen (meistens bedeutet dies „nie“, zumindest es sei denn, ich aktualisiere das gesamte Betriebssystem). Auf Haiku wird dies durch 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 und es so effektiv in ein „bewegliches Ziel“ verwandeln..
- Ich möchte mehrere Versionen derselben Anwendung nebeneinander haben, da es keine Möglichkeit gibt, herauszufinden, was in der neuesten Version fehlerhaft war, oder weil ich beispielsweise als Webentwickler meine Arbeit unter verschiedenen Versionen des Browsers testen muss. Haiku löst das erste Problem, nicht jedoch das zweite. Updates werden zurückgesetzt, allerdings 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:
Der Grundgedanke ist im Wesentlichen folgender: Der Anwendungsfall ist so selten, dass eine Optimierung dafür keinen Sinn ergibt; Es scheint mehr als akzeptabel, es in HaikuPorts als Sonderfall zu behandeln.
- Ich muss Apps dort behalten, wo ich sie mag, nicht auf meinem Startlaufwerk. Da mir oft der Speicherplatz ausgeht, muss ich ein externes Laufwerk oder ein Netzwerkverzeichnis anschließen, um Anwendungen (alle Versionen, die ich heruntergeladen habe) zu speichern. Wenn ich ein solches Laufwerk anschließe, müssen Anwendungen per Doppelklick gestartet werden. Haiku speichert alte Versionen von Paketen, aber ich weiß nicht, wie ich sie auf ein externes Laufwerk verschieben oder später Anwendungen von dort starten kann.
Entwicklerkommentar:
Technisch ist dies bereits mit dem Mount-Befehl möglich. Selbstverständlich werden wir hierfür eine GUI erstellen, sobald wir genügend interessierte Nutzer haben.
- Ich brauche keine Millionen von Dateien, die über das Dateisystem verstreut sind und die ich nicht selbst manuell verwalten kann. Ich möchte eine Datei pro Anwendung, die ich einfach herunterladen, verschieben und löschen kann. Auf Haiku wird dieses Problem mithilfe von Paketen gelöst
.hpkg, die beispielsweise Python aus Tausenden von Dateien in eine übertragen. Aber wenn Scribus beispielsweise Python verwendet, muss ich mich mit mindestens zwei Dateien befassen. Und ich muss darauf achten, Versionen davon zu behalten, die miteinander funktionieren.
Mehrere Versionen von AppImages laufen nebeneinander unter demselben Linux
Die Perspektive eines Anwendungsentwicklers
Betrachten wir es aus der Sicht eines Anwendungsentwicklers:
- Ich möchte die gesamte Benutzererfahrung kontrollieren. Ich möchte nicht darauf angewiesen sein, dass mir ein Betriebssystem sagt, wann und wie ich Anwendungen veröffentlichen soll. Haiku ermöglicht es Entwicklern, mit ihren eigenen HPKG-Repositories zu arbeiten, was jedoch bedeutet, dass Benutzer diese manuell einrichten müssen, was die Idee „weniger attraktiv“ macht.
- Ich habe eine Download-Seite auf meiner Website, auf der ich sie verteile
.exefür Windows,.dmgfür Mac und.AppImagefür Linux. Oder vielleicht möchte ich den Zugriff auf diese Seite monetarisieren, alles ist möglich? Was soll ich dort für Haiku eintragen? Die Datei reicht aus.hpkgmit Abhängigkeiten nur von HaikuPorts - Meine Software erfordert bestimmte Versionen anderer Software. Es ist beispielsweise bekannt, dass Krita eine gepatchte Version von Qt oder Qt erfordert, das auf eine bestimmte Version von Krita abgestimmt ist, zumindest bis die Patches wieder in Qt eingespielt werden. Sie können Ihr eigenes Qt für Ihre Anwendung in einem Paket packen
.hpkg, aber höchstwahrscheinlich ist dies nicht erwünscht.
Reguläre Seite zum Herunterladen von Anwendungen. Was soll ich hier zum Thema Haiku posten?
Werden Bundles (existierend als Anwendungsverzeichnisse wie AppDir oder .app im Apple-Stil) und/oder Bilder (in Form von stark modifizierten AppImages oder .dmg von Apple) Anwendungen eine sinnvolle Ergänzung zur Haiku-Desktop-Umgebung? Oder wird es das Gesamtbild verwässern und zu einer Fragmentierung und somit zu mehr Komplexität führen? Ich bin hin- und hergerissen: Einerseits beruht die Schönheit und Raffinesse des Haiku auf der Tatsache, dass es normalerweise nur eine Möglichkeit gibt, etwas zu tun, und nicht viele. Andererseits ist der Großteil der Infrastruktur für Kataloge und/oder Anwendungssuiten bereits vorhanden, sodass das System darauf schreit, dass die verbleibenden paar Prozent bereitgestellt werden.
Nach Angaben des Entwicklers
Unter Linux sind sie (Kataloge und Anwendungskits, - ca. Übersetzer) sind höchstwahrscheinlich eine technische Lösung für systemische Probleme. Bei Haiku lösen wir lieber einfach Systemprobleme.
Was denkst du
Bevor Sie antworten...
Moment, machen wir mal einen kurzen Realitätscheck: tatsächlich Anwendungsverzeichnisse - bereits Teil von Haiku:
Anwendungsverzeichnisse existieren bereits auf Haiku, werden aber im Dateimanager noch nicht unterstützt
Sie werden einfach nicht so gut unterstützt wie beispielsweise der Macintosh Finder. Wie cool wäre es, wenn das QtCreator-Verzeichnis in der oberen linken Ecke einen „QtCreator“-Namen und ein Symbol hätte, das die Anwendung startet, wenn man darauf doppelklickt?
Etwas früher habe ich schon :
Sind Sie sicher, dass Sie Ihre jahrzehntealten Apps heute noch ausführen können, wenn alle App-Stores und Distributions-Repositorys sie und ihre Abhängigkeiten vergessen haben? Sind Sie zuversichtlich, dass Sie auch in Zukunft auf Ihren aktuellen Job zugreifen können?
Gibt es bereits eine Antwort von Haiku oder können Kataloge und Anwendungspakete hier weiterhelfen? Ich denke, sie können es.
Laut Herrn. waddlesplash:
Ja, wir haben die Antwort auf die Frage: Wir unterstützen diese Anwendungen einfach so lange wie nötig, bis jemand ihre Dateiformate richtig lesen oder eine Eins-zu-Eins-Funktionalität bereitstellen kann. Unser Engagement für die Unterstützung von BeOS R5-Apps auf Haiku ist der Beweis dafür ...
Das ist richtig!
Welche Vorgehensweise sollte Haiku ergreifen?
Ich kann mir das friedliche Zusammenleben von HPKG, Verzeichnissen und Anwendungsbildern vorstellen:
- Systemsoftware verwendet
.hpkg - Verwenden Sie für die am häufigsten verwendete Software (insbesondere solche, für die fortlaufende Veröffentlichungen geplant werden müssen).
.hpkg(ca. 80 % aller Fälle) - Einige wurden über installiert
.hpkgAnwendungen profitieren von der Umstellung auf eine Anwendungsverzeichnis-Infrastruktur (z. B. QtCreator): Sie werden als verteilt.hpkg, wie vorher.
Herr. waddlesplash schreibt:
Wenn Sie lediglich Bewerbungen anzeigen müssen
/system/apps, stattdessen sollten wir die Verzeichnisse in Deskbar für Benutzer übersichtlicher gestalten, da/system/appsist nicht dazu gedacht, regelmäßig von Benutzern geöffnet und angezeigt zu werden (im Gegensatz zu MacOS). Für solche Situationen hat das Haiku ein anderes Paradigma, aber diese Option ist theoretisch akzeptabel.
- Haiku erhält die Infrastruktur zum Ausführen von Anwendungs-Images, nächtlichen, kontinuierlichen und Test-Builds von Software sowie für Fälle, in denen der Benutzer sie „rechtzeitig einfrieren“ möchte, für private und interne Software und andere spezielle Anwendungsfälle (ca. 20 %). von allen). Diese Bilder enthalten die zum Ausführen der Anwendung erforderlichen Dateien
.hpkg, vom System gemountet und nach Abschluss der Anwendung wieder ausgehängt. (Vielleicht könnte ein Dateimanager Dateien ablegen.hpkgautomatisch oder auf Wunsch des Benutzers in Anwendungsbilder umwandeln – beispielsweise, wenn Sie eine Anwendung in ein Netzwerkverzeichnis oder ein externes Laufwerk ziehen. Es ist nur ein Lied! Oder besser gesagt Poesie – Haiku.) Andererseits möchte der Benutzer möglicherweise den Inhalt des Bildes in Form von Dateien installieren.hpkg, danach werden sie auf die gleiche Weise aktualisiert und verarbeitet, als ob sie über HaikuDepot installiert worden wären... Wir müssen ein Brainstorming durchführen.
Zitat von Herrn waddlesplash:
Das Ausführen von Anwendungen von externen Laufwerken oder Netzwerkverzeichnissen kann möglicherweise nützlich sein. Und die Möglichkeit hinzuzufügen, mehr „Zonen“ für pkgman zu konfigurieren, wäre definitiv eine nette Funktion.
Ein solches System würde HPKG, Verzeichnisse und Anwendungsbilder nutzen. Einzeln sind sie gut, aber zusammen werden sie unbesiegbar.
Abschluss
Haiku verfügt über ein Framework, das eine einfache und anspruchsvolle Benutzererfahrung für den PC bietet und weit über das hinausgeht, was normalerweise für den Linux-PC bereitgestellt wird. Paketsystem .hpkg ist ein solches Beispiel, aber auch der Rest des Systems ist von Raffinesse durchdrungen. Allerdings würde Haiku von einer ordnungsgemäßen Unterstützung für Verzeichnisse und Anwendungsimages profitieren. Wie man das am besten macht, ist eine Diskussion mit Leuten, die Haiku, seine Philosophie und Architektur viel besser kennen als ich. Immerhin benutze ich Haiku seit etwas mehr als einer Woche. Dennoch glaube ich, dass Haikus Designer, Entwickler und Architekten von dieser neuen Perspektive profitieren werden. Zumindest wäre ich gerne ihr „Sparringspartner“. Ich verfüge über mehr als 10 Jahre praktische Erfahrung mit Linux-Anwendungskatalogen und -Bundles und würde gerne eine Verwendung dafür in Haiku finden, wofür sie meiner Meinung nach perfekt geeignet sind. Die möglichen Lösungen, die ich vorgeschlagen habe, 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, bin ich voll und ganz dafür. Im Grunde denke ich bereits über die Idee nach, wie man ein System erstellen könnte hpkg noch erstaunlicher, ohne die Art und Weise zu ändern, wie es funktioniert. Es stellte sich heraus, dass das Haiku-Team bei der Implementierung eines Paketverwaltungssystems schon lange über Anwendungspakete nachgedacht hatte, aber leider (glaube ich) wurde die Idee „obsolet“. Vielleicht ist es an der Zeit, es wiederzubeleben?
Versuch es selber! Immerhin stellt das Haiku-Projekt Images zum Booten von DVD oder USB bereit .
Haben Sie irgendwelche Fragen? Wir laden Sie zum Russischsprechen ein .
Fehlerübersicht:
Von Übersetzung: Dies ist der achte und letzte Artikel der Serie über Haiku.
Liste der Artikel:
An der Umfrage können nur registrierte Benutzer teilnehmen. bitte.
Ist es sinnvoll, das hpkg-System auf Linux zu portieren?
-
Ja
-
Nein
-
Bereits umgesetzt, schreibe ich in die Kommentare
20 Benutzer haben abgestimmt. 5 Benutzer enthielten sich der Stimme.
Source: habr.com