TL;DR: Haiku — ein Betriebssystem, das speziell für PCs entwickelt wurde, und somit einige Tricks besitzt, die seine Arbeitsumgebung deutlich besser machen als andere. Aber wie funktioniert es?
entdeckte ich Haiku, ein überraschend gutes System. Ich bin immer noch beeindruckt, wie reibungslos es funktioniert, besonders im Vergleich zu den Arbeitsumgebungen unter Linux. Heute werde ich einen Blick unter die Haube werfen. Wo es nötig ist, werde ich es mit dem ursprünglichen Macintosh, Mac OS X und den Linux-Arbeitsumgebungen (dem XDG-Standard von freedesktop.org) vergleichen.
Ressourcen in ELF-Dateien
Gestern erfuhr ich, dass IconOMatic in der Lage ist, Icons in rdef-Ressourcen in ausführbaren ELF-Dateien zu speichern. Heute möchte ich sehen, wie das tatsächlich funktioniert.
Ressourcen? ab , der ursprüngliche Autor des Macintosh Finders und „Vater“ des Macintosh Resource Managers:
Ich bin besorgt über die starre Art der traditionellen Programmierung. Die Idee einer Anwendung, die im Code festgefroren ist, ohne irgendetwas dynamisch ändern zu können, ist für mich völlig inakzeptabel. Es sollte möglich sein, so viel wie möglich zur Laufzeit zu ändern. Der Code selbst darf natürlich nicht verändert werden, aber einiges könnte auch ohne eine Neukompilierung des Codes geändert werden?
Beim originalen Macintosh wurde so gestaltet, dass diese Dateien eine "Daten-Sektion" und eine "Ressourcen-Sektion" haben, was das Speichern verschiedener Elemente, wie zum Beispiel Icons, Übersetzungen usw., in den ausführbaren Dateien erheblich erleichtert hat.
Auf dem Mac wird dafür , ein Grafikprogramm für – Überraschung! – die Bearbeitung von Ressourcen.
ResEdit auf dem ursprünglichen Macintosh
Ermöglichte es, Icons, Menüpunkte, Übersetzungen und Ähnliches relativ einfach zu bearbeiten, allerdings "reisen" sie dennoch mit den Anwendungen.
In jedem Fall hatte dieser Ansatz einen schweren Nachteil: Er funktionierte nur auf Apple-Dateisystemen, was einer der Gründe war, warum Apple beim Übergang zu Mac OS X auf die "Ressourcen-Sektion" verzichtete.
Unter Mac OS X wollte Apple eine plattformunabhängige Lösung, weshalb das Konzept der Pakete (von NeXT) eingeführt wurde. Diese Verzeichnisse werden vom Dateimanager als „opake Objekte“ behandelt, ähnlich wie Dateien und nicht wie Verzeichnisse. Jedes Paket mit einer Anwendung im Format .app enthält unter anderem die Datei Info.plist (in einem Analogon von JSON oder YAML von Apple), die Metadaten der Anwendung enthält.
Die Schlüssel der Datei Info.plist aus dem Mac OS X-Anwendungspaket.
Ressourcen wie Icons, UI-Dateien und ähnliches werden im Paket als Dateien gespeichert. Dieses Konzept geht quasi zurück zu den Ursprüngen bei NeXT.
Mathematica.app auf NeXTSTEP 1.0 im Jahr 1989: wird im Terminal als Verzeichnis mit Dateien angezeigt, erscheint jedoch als einzelnes Objekt im grafischen Dateimanager.
Kehren wir zu BeOS zurück, auf dessen Konzepten Haiku basiert. Deren Entwickler haben beim Wechsel von PEF (PowerPC) zu ELF (x86) (dem gleichen, das unter Linux verwendet wird) entschieden, einen Ressourcenteil an das Ende der ELF-Dateien anzuhängen. Dafür wurde kein eigenes ELF-Sektionsformat verwendet, sondern der Abschnitt wurde einfach ans Ende der ELF-Datei geschrieben. Infolgedessen sind die Programme strip Und andere aus den binutils, die davon nichts wissen, haben es einfach abgeschnitten. Daher ist es besser, beim Hinzufügen von Ressourcen zu einer ELF-Datei auf BeOS nicht mit Linux-Tools zu arbeiten.
Was passiert jetzt mit Haiku? Prinzipiell ist es mehr oder weniger dasselbe.
Theoretisch könnte man Ressourcen in den entsprechenden Abschnitt der ELF-Datei einfügen. Laut den Entwicklern im Kanal #haiku auf irc.freenode.net:
Eine Sektion mit ELF würde mehr Sinn machen … der einzige Grund, warum wir das nicht tun, ist, weil man es in BeOS so gemacht hat.
Das sollte man jetzt nicht ändern.
Ressourcenmanagement
Ressourcen werden in einem strukturierten „Ressourcen“-Format geschrieben: es ist im Wesentlichen eine Liste von Ressourcen mit Größen und anschließend deren Inhalt. Ich erinnere mich an .
Wie überprüft man Ressourcen in Haiku? Gibt es sowas wie ResEdit?
Laut :
Um Ressourcen, die im Anwendunspaket bereitgestellt werden, anzusehen, kann man die ausführbare Datei auf ein Programm wie ziehen. Man kann auch ins Terminal gehen und den Befehl
listres dateiname.
ausführen. Resourcer ist in HaikuDepot, aber bei mir stürzt es einfach ab.
Wie verwaltet man Ressourcen in ELF-Dateien? Mit Hilfe von rsrc und und. und rdef rsrcwerden Dateien in und . Die Datei rsrc wird im normalen Textformat gespeichert, sodass die Arbeit damit viel einfacher ist. Die Datei im Format
~> rc -h
Haiku Resource Compiler 1.1Um ein rdef-Script in eine Ressourcendatei zu kompilieren:
rc [Optionen] [-o ] ...Um eine Ressourcendatei zurück in ein rdef-Script zu konvertieren:
rc [Optionen] [-o ] -d ...Optionen:
-d --dekompilieren erstelle ein rdef-Script aus einer Ressourcendatei
--auto-namen konstruiere Ressourcennamen aus ID-Symbolen
-h --hilfe zeige diese Nachricht an
-I --include füge zur Liste der include-Pfade hinzu
-m --merge lösche keine vorhandenen Inhalte der Ausgabedatei
-o --ausgabe gebe den Namen der Ausgabedatei an, Standard ist out.xxx
-q --still zeige keine Fehlermeldungen an
-V --version zeige die Softwareversion und Lizenz anSie können das Programm xres zum Überprüfen und Verwalten verwenden:
/> xres
Usage: xres ( -h | --help )
xres -l <file> ...
xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)Nun, wollen wir es versuchen?
/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type ID size name
------ ----------- ----------- --------------------
'MIMS' 1 36 BEOS:APP_SIG
'APPF' 1 4 BEOS:APP_FLAGS
'MSGG' 1 421 BEOS:FILE_TYPES
'VICN' 101 7025 BEOS:ICON
'VICN' 201 91 kActionBack
'VICN' 202 91 kActionForward
'VICN' 203 300 kActionForward2
'VICN' 204 101 kActionStop
'VICN' 206 243 kActionGoStart
'MSGG' 205 1342 kActionGo
'APPV' 1 680 BEOS:APP_VERSIONMehr über Ressourcen und das Format und finden Sie hier. .
Standardressourcentypen
Obwohl man in Ressourcen alles Mögliche einfügen kann, gibt es einige spezifische Standardtypen:
app_signature: MIME-Typ der Anwendung, zum Zuordnen von zu öffnenden Dateien, starten, IPC usw.app_name_catalog_entry: Da der Name der Anwendung normalerweise in Englisch ist, können hier die Orte angegeben werden, an denen die übersetzten Namen liegen, sodass Benutzer verschiedener Sprachen das übersetzte Anwendungsnamen sehen können, wenn sie möchten.app_version: genau das, was Sie denkenapp_flags: gibt anregistrarwie man eine Anwendung behandelt. Ich denke, es gibt mehr, als es auf den ersten Blick erscheint. Zum Beispiel gibt esB_SINGLE_LAUNCH, das die System dazu bringt, jedes Mal einen neuen Anwendungsprozess auf Anfrage des Benutzers zu starten (dieselbe Logik wird für die meisten Anwendungen unter Linux verwendet). Es gibtB_MULTIPLE_LAUNCH, das einen Prozess für jedede Dateistartet. Schließlich gibt esB_EXCLUSIVE_LAUNCH, das das System zwingt, nur einen Prozess gleichzeitig zu starten, unabhängig davon, wie oft die Benutzer ihn starten (zum Beispiel wird Firefox unter Linux so gestartet; dasselbe Ergebnis kann in Qt-Anwendungen erzielt werden, indem die Funktion verwendet wird). Anwendungen mitB_EXCLUSIVE_LAUNCHwerden benachrichtigt, wenn der Benutzer versucht, sie erneut zu starten: zum Beispiel erhalten sie den Pfad der Datei, die der Benutzer mit ihnen öffnen möchte.vector_icon: Vektorikone der Anwendung (In BeOS gab es keine Vektorikonen, die meisten Anwendungen hatten stattdessen zwei rasterbasierte Icons in den ausführbaren Dateien).
Selbstverständlich können Ressourcen mit beliebigen IDs und Typen hinzugefügt werden, um sie anschließend in der Anwendung oder anderen Anwendungen mit Hilfe der Klasse zu lesen. BResources. Aber lassen Sie uns zunächst auf das spannende Thema der Icons eingehen.
Vektor-Icons im Haiku-Stil
Natürlich ist Haiku nicht das einzige, das das beste Icon-Format gewählt hat; in diesem Bereich sind die Arbeitsumgebungen von Linux alles andere als perfekt:
me@host:~$ ls /usr/share/icons/hicolor/
128x128 256x256 512x512 index.theme
160x160 28x28 64x64 scalable
16x16 32x32 72x72 symbolic
192x192 36x36 8x8
22x22 42x42 96x96
24x24 48x48 icon-theme.cacheSo etwas lässt bereits erahnen, woraus dieses Stück besteht.
Natürlich gibt es den Ordner 'scalable', der offensichtlich vektorbasierte Icons enthält. Warum gibt es also noch etwas anderes? Weil das Rendering vektorbasisierter Grafiken in kleinen Größen möglicherweise schlechter als ideal ausfällt. Man möchte verschiedene Varianten haben, die für unterschiedliche Größen optimiert sind. In den Linux-Arbeitsumgebungen wird dies erreicht, indem Icons unterschiedlicher Größen über das Dateisystem verteilt werden.
me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.pngBitte beachten Sie: Es gibt kein Konzept für verschiedene Versionen von Firefox. Daher kann die Situation mit mehreren Versionen der Anwendung im System nicht differenziert behandelt werden.
Verschiedene Icons von Firefox in unterschiedlichen Versionen. Bisher ist es nicht möglich, dies unter Linux ohne verschiedene Workarounds zu bearbeiten.
Mac OS X behandelt das etwas differenzierter:
Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icnsEs ist klar, dass es eine Datei gibt firefox.icns im Paket Firefox.app, die alle Größen enthält, sodass verschiedene Versionen einer Anwendung unterschiedliche Icons haben.
Viel besser! Die Icons reisen zusammen mit der Anwendung, alle Ressourcen in einer Datei.
Kehren wir zu Haiku zurück. Eine verblüffende Lösung, ohne Ausnahmen. Laut :
wurde ein spezielles, hochoptimiertes Format für kleine Größen und schnelle Renderings namens HVIF entwickelt. Deshalb sind unsere Icons größtenteils viel kleiner als im Rasterformat oder im weitverbreiteten SVG-Format.
Und sie sind tatsächlich optimiert:
Die Größen der Icons im HVIF im Vergleich zu anderen Formaten.
Die Unterschiede sind erheblich!
Doch die Magie endet hier nicht. Das gleiche HVIF kann je nach angezeigter Größe unterschiedliche Detaillierungsgrade zeigen, obwohl es sich um ein Vektorformat handelt.
Verschiedene Detaillierungsgrade (LOD) je nach Rendergröße
Nun zu den Nachteilen: Man kann nicht einfach eine SVG nehmen, sie in ImageMagick werfen und damit fertig sein. Es sind mehrere Zyklen erforderlich, um ein Icon im HVIF-Format zu erstellen. Erläuterungen. Allerdings kann IconOMatic SVG nicht perfekt importieren; etwa 90 % der SVG-Details werden mit einer gewissen Wahrscheinlichkeit importiert, die restlichen 10 % müssen manuell angepasst und geändert werden. Lesen Sie mehr darüber, wie HVIF seine Magie entfaltet im Blog
Hinzufügen eines Icons zur Anwendung
Jetzt kann ich das Icon zum Paket hinzufügen, das ich , unter Berücksichtigung aller gesammelten Informationen.
Da ich momentan nicht besonders motiviert bin, ein eigenes Icon für meine ‚Hallo, Welt‘ QtQuickApp zu zeichnen, ziehe ich es aus Qt Creator.
/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt CreatorLassen Sie uns überprüfen, ob das Icon kopiert wurde:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONSieht gut aus, aber warum wird das neue Icon nicht angezeigt, nachdem es kopiert wurde?
Die kopierte VICN:101:BEOS:ICONs wird momentan nicht als Ikone für die Anwendung im Dateimanager verwendet.
Was habe ich verpasst?
Kommentar des Entwicklers:
Ich muss eine Datei erstellen
undmit allen Ressourcen, dann den Befehl ausführenrc name.rdef, das erstellt die Datei.rsrc. Dann muss der Befehl ausgeführt werdenresattr -o binärname name.rsrc. Mindestens verwende ich solche Befehle, um Icons zu meinen Skripten hinzuzufügen.
Nun, ich wollte eigentlich eine Ressource und nicht ein Attribut erstellen. Ich bin wirklich verwirrt.
Intelligente Caching mit Dateisystemnutzung
Das Öffnen und Lesen von ELF-Attributen ist langsam. Wie ich bereits oben erwähnt habe, wird das Icon als Ressource in der Datei geschrieben. Diese Methode ist zuverlässiger und übersteht das Kopieren auf ein anderes Dateisystem. Es wird jedoch auch in das Attribut des Dateisystems kopiert, zum Beispiel BEOS:ICON. Es funktioniert nur mit bestimmten Dateisystemen, wie zum Beispiel BFS. Die vom System angezeigten Icons (im Tracker und Deskbar) werden aus diesem erweiterten Attribut gelesen, weil eine solche Lösung schnell arbeitet. An manchen Stellen (wo Geschwindigkeit nicht entscheidend ist, wie im typischen Fenster „Über das Programm“) erhält das System das Icon direkt aus der Ressource in der Datei. Doch das ist noch nicht alles. Denken Sie daran, dass Mac-User die Icons von Anwendungen, Verzeichnissen und Dokumenten durch eigene ersetzen konnten, da Mac die Möglichkeit bietet, solche „wichtigen“ Dinge zu tun, wie zum Beispiel . Unter Haiku sollte die Ressource (in der Datei) als das ursprüngliche Icon betrachtet werden, das mit der Anwendung geliefert wird, und das Attribut (im BFS-Dateisystem) als eine Möglichkeit, dem Benutzer zu erlauben, Änderungen nach Wunsch vorzunehmen (obwohl, ein Hinweis, die grafische Oberfläche zum Einfügen eines benutzerdefinierten Icons über das Standard-Icon noch nicht implementiert ist).
Überprüfung der Dateisystemattribute
Mit resaddr es besteht die Möglichkeit, die Dateisystemattribute zu überprüfen und festzulegen.
/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]
Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)Im Grunde genommen ist das „Kleber“, der eine bidirektionale Transformation zwischen (verlässlichen) Ressourcen und (schnellen) Attributen eines Dateisystems durchführt. Und da das System die Ressourcen beschafft und das Kopieren automatisch vornimmt, werde ich mir darüber keine weiteren Gedanken machen.
Die Magie der hpkg-Pakete
Aktuell werden (vor allem) Pakete verwendet, um Software auf Haiku bereitzustellen. .hpkg. Lassen Sie sich nicht von dem einfachen Namen täuschen: Das .hpkg-Format funktioniert völlig anders als andere Formate mit ähnlichen Namen, denen Sie begegnet sind, es hat echte Superkräfte.
Mit traditionellen Paketformaten war ich lange frustriert, weil ich oft eines (ein Paket) herunterlade, während in das System ein anderes (Dateien innerhalb des Pakets) installiert wird. Es ist ziemlich schwierig, mit den Dateien umzugehen (zum Beispiel, sie zu löschen), wenn ein Paket auf die traditionelle Weise installiert wird. Das liegt daran, dass der Inhalt des Pakets über das gesamte Dateisystem verteilt wird, einschließlich Stellen, an denen ein normaler Benutzer keinen Schreibzugriff haben kann. Dies erzeugt eine ganze Klasse von Programmen — Paketmanagern. Der Transfer bereits installierter Software, beispielsweise auf einen anderen Rechner, ein externes Laufwerk oder einen Dateiserver, wird sogar noch schwieriger oder gar unmöglich. In einem typischen Linux-System können leicht mehrere Hunderttausend bis Millionen von separaten Dateien existieren. Das ist zugleich zerbrechlich und langsam, insbesondere bei der Erstinstallation des Systems, der Installation, Aktualisierung und Deinstallation gewöhnlicher Pakete sowie beim Kopieren des Bootvolumens (des Root-Partitions) auf ein anderes Medium.
Ich arbeite an dem Projekt AppImage, einem teilweise improvisierten Ansatz für Endbenutzeranwendungen. Es handelt sich um ein Software-Verteilungsformat, das die Anwendung und alle ihre Abhängigkeiten in einem einzigen Dateisystem-Image bündelt, das beim Start der Anwendung eingebunden wird. Das vereinfacht vieles erheblich, da beispielsweise ImageMagick plötzlich zu einer einzigen Datei wird, die von normalen Benutzern im Dateimanager verwaltet werden kann. Der vorgeschlagene Ansatz funktioniert nur für Software, wie der Name des Projekts schon zeigt, und hat seine eigenen Probleme, da die Leute, die Software für Linux bereitstellen, immer die Verantwortung auf mich abschieben.
Lassen Sie uns zu Haiku zurückkehren. Ist es gelungen, das optimale Gleichgewicht zwischen traditionellen Paketverwaltungssystemen und der Bereitstellung von Software auf Basis von Images zu finden? Ihre Pakete .hpkg sind tatsächlich komprimierte Abbilder des Dateisystems. Beim Booten des Systems montiert der Kernel alle installierten und aktiven Pakete mit ungefähr den folgenden Kernelmeldungen:
KERN: package_daemon [16042853: 924] aktives Paket: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] aktives Paket: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] aktives Paket: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] aktives Paket: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] aktives Paket: "llvm_libs-5.0.0-3-x86_64.hpkg"Cool, oder? Halten Sie durch, es wird noch spannender!
Es gibt ein ganz besonderes Paket:
KERN: package_daemon [16040020: 924] aktives Paket: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Es enthält ein äußerst minimalistisches Betriebssystem, einschließlich des Kernels. Glauben Sie es oder nicht, aber selbst der Kernel wird nicht aus dem Bootvolume (Root-Partition) extrahiert, sondern wird sorgfältig aus dem Paket an seinen Platz geladen. .hpkg. Das ist ja erstaunlich! Ich habe bereits erwähnt, dass die Gesamtverfeinerung und Kohärenz von Haiku meiner Meinung nach darin begründet ist, dass das gesamte System, vom Kern und der grundlegenden Benutzeroberfläche bis hin zur Paketverwaltung und der Infrastruktur der Arbeitsumgebung, von einem einzigen Team gemeinsam entwickelt wird. Stellen Sie sich vor, wie viele verschiedene Gruppen und Teams nötig wären, um so etwas auf Linux-Basis zu starten. [Ich stelle mir das Projekt PuppyLinux vor, — Anm. d. Übers.]. Und dann stellen Sie sich vor, wie viel Zeit benötigt wird, um diesen Ansatz in die Distributionen zu integrieren. Man sagt ja: Nimm eine einfache Aufgabe, teile sie unter verschiedenen Ausführenden auf, und sie wird so kompliziert, dass sie nicht mehr lösbar ist. Haiku hat mir in diesem Fall die Augen geöffnet. Ich denke, genau das passiert gerade mit Linux (wobei Linux hier ein Sammelbegriff ist, der den Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu-Stack bezeichnet).
Systemrollbacks mit hpkg durchführen
Wie oft passiert folgende Situation: Das Update war erfolgreich, und dann stellt sich heraus, dass etwas nicht so funktioniert, wie es sollte? Bei der Verwendung herkömmlicher Paketmanager ist es schwierig, den Zustand des Systems auf den Zeitpunkt vor der Installation neuer Pakete zurückzusetzen (zum Beispiel, wenn etwas schiefgeht). Einige Systeme bieten Umgehungslösungen in Form von Snapshots des Dateisystems an, aber diese sind recht umständlich und werden nicht in allen Systemen verwendet. In Haiku wird dies mit Hilfe von Paketen gelöst. .hpkgJedes Mal, wenn Pakete im System geändert werden, werden die alten Pakete nicht gelöscht, sondern in Subkatalogen vom Typ gespeichert. /Haiku/system/packages/administrative/state-<...>/ ständig. Unvollendete Operationen speichern ihre Daten in Unterkatalogen. /Haiku/system/packages/administrative/transaction-<...>/.
Inhalt /Haiku/system/packages/administrativeDie „state…“-Verzeichnisse enthalten Textdateien mit den Namen aktiver Pakete, während „transaction…“ die Pakete selbst enthalten.
Der „alte aktive Zustand“, d.h. die Liste .hpkg der Pakete, die vor den Änderungen aktiv waren, wird nach jeder Operation im Dateimanager in einer Textdatei festgehalten. /Haiku/system/packages/administrative/state-<...>/activated-packagesÄhnlich wird der neue „aktive Zustand“ in einer Textdatei festgehalten. /Haiku/system/packages/administrative/activated-packages.
Verzeichnis /Haiku/system/packages/administrative/state-<...>/ enthält nur eine Textdatei mit einer Liste aktiver Pakete in diesem Zustand (im Falle der Installation von Paketen ohne Entfernung), während der state-Ordner alte Versionen der Pakete enthält, falls Pakete entfernt oder aktualisiert wurden.
Beim Systemstart wird basierend auf der Pakete-Liste entschieden, welche Pakete aktiviert (gemountet) werden. So einfach ist das! Sollte beim Booten etwas schiefgehen, kann der Boot-Manager angewiesen werden, eine andere, ältere Liste zu verwenden. Problem gelöst!
Haiku Bootloader. Jeder Einstiegspunkt spiegelt den entsprechenden „aktiven Zustand“ wider.
Ich schätze den Ansatz, einfache Textdateien als Liste des „aktiven Zustands“ zu verwenden, in denen verständliche Namen festgehalten werden. .hpkgDas steht im klaren Gegensatz zu den für Maschinen und nicht für Menschen erstellten von OSTree oder Flatpak im Dateisystem (auf der gleichen Ebene wie die Microsoft GUID).
Die Liste aktiver Pakete zu jedem Zeitpunkt
Konfigurationsdaten
Offensichtlich enthält das Verzeichnis /Haiku/system/packages/administrative/writable-files Schlüsseldateien für Pakete, jedoch schreibgeschützt. Denn, wie Sie sich erinnern, .hpkg sind nur schreibgeschützt montiert. Daher müssen diese Dateien vor dem Schreiben aus den Paketen kopiert werden. Das macht Sinn.
GUI-Integration für das .hpkg-System
Schauen wir uns nun an, wie diese beeindruckenden Pakete .hpkg mit der Integration in die Benutzeroberfläche (UX) umgehen. Schließlich ist Haiku für den persönlichen Gebrauch gedacht. Ich habe hohe Ansprüche, wenn ich das Benutzererlebnis mit den Paketen .app auf Macintosh vergleiche, die das gleiche Erlebnis bieten wie .hpkg. Ich will gar nicht erst die Situation in den Linux-Umgebungen vergleichen, denn die ist im Vergleich zu allen anderen absolut katastrophal.
Mir fallen folgende Szenarien ein:
- Ich möchte den Inhalt des Pakets anzeigen
.hpkg - Ich möchte das Paket installieren
- Ich möchte das Paket entfernen
- Ich möchte etwas entfernen, das als Teil des Pakets ins System gekommen ist
- Ich möchte etwas kopieren, das als Teil des Pakets ins System gekommen ist
- Ich möchte alle Abhängigkeiten des Pakets herunterladen, die nicht Teil jeder Haiku-Installation sein können (zum Beispiel, ich habe eine physisch isolierte Maschine ohne Internetzugang.)
- Ich möchte meine Pakete (oder einen Teil davon) getrennt an einen anderen Ort verschieben, der unabhängig vom Boot-Laufwerk (Root-Partition) ist (weil ich beispielsweise nicht genug Platz darauf habe).
Das sollte die meisten grundlegenden Fälle aus meinem Alltag abdecken. Lassen Sie uns anfangen.
Überprüfung des Inhalts des Pakets
Auf dem Mac klicke ich einfach mit der rechten Maustaste auf das Paket, um es zu öffnen und den Inhalt im Finder anzusehen. Es ist schließlich nur ein verkleideter Ordner! (Ich weiß, dass es Pakete .pkg für Systemteile gibt, die keine Anwendungen sind, aber normale Benutzer haben normalerweise nicht mit ihnen zu tun).
Auf Haiku klicke ich mit der rechten Maustaste auf das Paket und dann auf „Inhalte“, um zu sehen, was sich darin befindet. Es gibt jedoch nur eine Liste von Dateien, ohne dass ich sie durch Doppelklicken öffnen kann.
Es wäre viel besser, wenn es eine Möglichkeit gäbe, das Paket (vorübergehend) zu mounten, .hpkg um es über den Dateimanager anzusehen, ohne dass sich der Benutzer um Implementierungsdetails kümmern muss. (Übrigens kann man das Paket in .hpkg Expander öffnen, das es wie jedes andere Archiv entpacken kann)., der ihn wie jede andere Archive entpacken kann).
Im HaikuDepot-Interface können Sie eine Liste von Paketdateien einsehen, aber es gibt keine Möglichkeit, den Inhalt anzuzeigen, beispielsweise durch Doppelklicken auf die README.md.
In dieser Kategorie hat der Mac die Nase vorn, aber die erforderliche Funktionalität in HaikuDepot hinzuzufügen, sollte keine großen Schwierigkeiten bereiten.
Installation eines Pakets über die GUI
Auf dem Mac, die meisten Disk-Images .dmg enthalten Pakete .app. Öffnen Sie das Disk-Image durch Doppelklick, dann kopieren Sie das Paket, indem Sie es zum Beispiel in /Applications den Finder ziehen. Für mich ist das selbstverständlich, aber ich habe gehört, dass einige Anfänger damit Schwierigkeiten haben könnten. Standardmäßig "schlägt" Apple ein systemweites Verzeichnis vor /Applications (bei NeXT war es sowohl netzwerk- als auch benutzerspezifisch), aber Sie können Ihre Anwendungen leicht auf einem Dateiserver oder in einem Unterverzeichnis $HOME/Applications, ablegen, wenn Ihnen das lieber ist.
Auf Haiku, ein Doppelklick auf das Paket, dann ein Klick auf "Installieren", einfacher geht's nicht. Mich interessiert, was passiert, wenn das Paket Abhängigkeiten hat, die in HaikuPorts verfügbar, aber noch nicht installiert sind. In Linux weiß man eigentlich nicht, was in dieser Situation zu tun ist, aber die Lösung ist offensichtlich – den Benutzer fragen, ob die Abhängigkeiten heruntergeladen und installiert werden sollen. Genau das macht Haiku.
Ich habe das Paket 'sanity' manuell heruntergeladen und darauf geklickt; der Paketmanager weiß, woher er die Abhängigkeiten beziehen kann (vorausgesetzt, die Repositories sind bereits im System eingetragen). Nicht jede Linux-Distribution kann das.
Eine weitere Möglichkeit ist die Nutzung eines Dateimanagers; es reicht, das Paket einfach herüberzuziehen. .hpkg Das Paket oder in /Haiku/system/packages (für eine systemweite Installation, standardmäßig), oder in /Haiku/home/config/packages (für eine individuelle Installation; bei Doppelklick nicht verfügbar – das Wort „config“ an dieser Stelle stört mich immer noch, da es für mich in diesem Kontext ein Synonym für „Einstellungen“ ist). Dabei ist das Konzept mehrerer Nutzer noch nicht einmal für Haiku verfügbar (wahrscheinlich ist das der Grund, warum alles so einfach ist – ich weiß nicht, ob mehrbenutzerfähigkeiten die Sache für die Arbeitsumgebung eines PCs zu kompliziert machen würden).
In dieser Kategorie gewinnt Haiku, weil es nicht nur mit Anwendungen, sondern auch mit Systemprogrammen arbeiten kann.
Das Entfernen eines Pakets aus dem GUI
Auf dem Mac, erfordert, das App-Symbol in den Papierkorb zu ziehen, und das war's. Einfach!
Auf Haiku, zuerst muss man herausfinden, wo sich das Paket im System befindet, denn man installiert es selten dort, wo es hingehört (alles macht das System). Meistens muss man nach /Haiku/system/packages (bei einer allgemeinen Standardinstallation), oder in /Haiku/home/config/packages (ich habe bereits gesagt, dass „config“ der falsche Name ist?). Dann wird die App einfach in den Papierkorb gezogen, und das war's.
Ganz einfach! Allerdings würde ich das nicht so sagen. Hier ist, was in Wirklichkeit passiert:
Das passiert, wenn man die App aus /Haiku/system/packages
Ich habe versucht, meine gestrige App „Hallo, Welt“ auf QtQuickApp in den Papierkorb zu verschieben. Ich habe nicht versucht, das Systemverzeichnis zu verschieben, und da alle Pakete im Systemverzeichnis installiert werden, ist es unmöglich, ein Paket .hpkg ohne Änderung „seines Inhalts“. Ein normaler Benutzer würde sich erschrecken, auf die standardmäßig zugewiesene Taste „Abbrechen“ drücken.
Erklärt :
Diese Nachricht ist bereits über 10 Jahre alt. Wahrscheinlich müssen wir es so einstellen, dass die Warnung nur beim Verschieben des Pakets angezeigt wird. Normale Benutzer müssen das in jedem Fall nicht so machen.
Gut, vielleicht sollte ich das mit HaikuDepot versuchen? Ich klicke doppelt auf das Paket in /Haiku/system/packages, in der Erwartung, dass der „Deinstallieren“-Button erscheint. Nix da, es gibt (nur) „Installieren“. Wo bist du, „Deinstallieren“?
Ich habe aus Spaß versucht zu sehen, was passiert, wenn ich auf „Installieren“ für ein bereits installiertes Paket klicke. Es sieht so aus:
Das passiert, wenn Sie versuchen, ein bereits installiertes Paket zu installieren.
Daraufhin erscheint:
Wenn Sie im vorherigen Fenster auf „Änderungen anwenden“ klicken, sieht es so aus
Ich vermute, dass es sich um einen Softwarefehler handelt, der Link zur Anfrage ist bereits vorhanden. [der Autor hat keinen Link bereitgestellt, — Anm. des Übersetzers]
Schnelle Lösung: Fügen Sie eine Schaltfläche „Deinstallieren“ hinzu, wenn das Paket bereits in
/Haiku/system/packages, oder in/Haiku/home/config/packages.
Beim Durchsehen der in HaikuDepot installierten Pakete sehe ich mein Paket in der Liste und kann es löschen.
In dieser Kategorie gewinnt Mac. Aber ich kann mir vorstellen, dass das Benutzererlebnis auf Haiku bei entsprechender Konfiguration besser sein könnte als auf dem Mac. (Einer der Entwickler schätzte es so ein: „Weniger als eine Stunde, um die angegebene Funktionalität in HaikuDepot hinzuzufügen, wenn Sie ein wenig C++ wissen“, gibt es Freiwillige?)
Das Löschen von etwas aus dem Paket
Lassen Sie uns versuchen, die Anwendung selbst zu löschen, nicht das Paket .hpkg, aus dem sie stammt (ich bezweifle, dass es für „einfache Sterbliche“ einen Unterschied macht).
Auf dem Mac, der Benutzer arbeitet normalerweise tatsächlich mit der Datei .dmg, aus der das Anwendungs-Paket stammt. .app. Gewöhnlich werden die Abbildungen .dmg im Download-Verzeichnis gesammelt, während die Pakete vom Benutzer in /Applications. Es wird angenommen, dass viele Benutzer selbst nicht wissen, was sie tun; diese Hypothese wird von einem ehemaligen Apple-Mitarbeiter bestätigt. (Eine der Dinge, die ich an Mac nicht mag. Mit AppImage hingegen gibt es keinen Unterschied zwischen der Anwendung und dem Paket, in dem sie sich befindet. Ziehen Sie das Symbol in den Papierkorb = das war's. Ganz einfach!)
Auf Haiku, zudem gibt es eine Unterscheidung zwischen apps/ und packages/, weshalb ich bezweifle, dass das den Benutzern klarer wird. Aber was passiert, wenn man eine Anwendung aus apps/ in den Papierkorb zieht:
Das ist das Ergebnis, wenn man versucht, eine Anwendung zu löschen, die aus einer Datei stammt. .hpkg
Technisch gesehen ist das korrekt (da die Anwendung in erster Linie auf einem schreibgeschützten Dateisystem abgelegt ist), jedoch nicht besonders nützlich für den Benutzer.
Schnelle Lösung: Stattdessen über die GUI löschen anzubieten.
.hpkg
Ich habe zum Spaß versucht, die Anwendung zu duplizieren, indem ich Alt+D gedrückt habe. Ich erhielt die Nachricht: "Es ist nicht möglich, Objekte auf einem schreibgeschützten Volume zu verschieben oder zu kopieren." Das liegt daran, dass /system neben /system/packages und /system/settings) ein Mountpoint von packagefs ist (denken Sie daran, wie es in der Ausgabe erscheint. df?). К сожалению, вывод команды mount stellt die Situation nicht klar (wie in einem der vorherigen Artikel erwähnt), mountvolume zeigt nicht das Gesuchte (offenbar werden die über Loop eingebundenen Pakete nicht als „Volumes“ betrachtet), und ich habe auch die alternativen Befehle vergessen. .hpkg In dieser Kategorie hat niemand gewonnen, außer AppImage (wenn wir ehrlich sind, ist das eine subjektive Meinung). Man könnte sich jedoch vorstellen, dass nach Anpassungen die Benutzererfahrung auf Haiku besser ist als auf Mac.
Hinweis: Es muss geklärt werden, was unter „Volume“ im Verhältnis zu „Partition“ verstanden wird. Wahrscheinlich ist es vergleichbar mit dem Verhältnis von „Ordner“ zu „Verzeichnis“: Die meisten Verzeichnisse werden im Dateimanager als Ordner angezeigt, aber nicht alle (zum Beispiel Pakete, die wie Dateien behandelt werden). Macht mich diese Analogie offiziell zum Nerd?
Das Kopieren des Paket-Inhalts auf ein anderes System
, ich ziehe das Paket einfach rüber
Auf dem Mac, und da die Abhängigkeiten innerhalb des Pakets – werden sie zusammen bewegt. .app, ich ziehe die Anwendung rüber, aber die Abhängigkeiten werden überhaupt nicht behandelt.
Auf HaikuSchnelle Lösung: Lassen Sie stattdessen das Paket „`.hpkg“ vollständig einschließlich der Abhängigkeiten, falls vorhanden, rüberziehen.
Schnelle Lösung: Lassen Sie stattdessen das gesamte Paket «`.hpkg zusammen mit seinen Abhängigkeiten, falls vorhanden, per Drag & Drop anbieten.
In dieser Kategorie hat eindeutig der Mac die Oberhand. Zumindest für mich, der ich ein Fan seiner Paradigmen bin. Haiku könnte das kopieren. .hpkg anstatt der Anwendung, aber das System bietet mir das nicht an…
Das Herunterladen des Pakets mit all seinen Abhängigkeiten.
Nicht jeder Computer ist ständig mit dem Internet verbunden. Im Gegenteil, einige Systeme (ja, ich schaue euch an, moderne Windows-, Mac- und Linux-Varianten) vergessen das. Für mich ist es wichtig, dass ich, sagen wir, in ein Internetcafé gehen, Software auf ein Speichermedium herunterladen, dieses Medium in meinen Desktop-Computer stecken und sicher sein kann, dass alles funktioniert [mutiger Typ, so etwas auf Windows zu versuchen… – Anmerkung des Übersetzers].
In der Folge erhalte ich etwas häufiger als gewöhnlich unbefriedigende Abhängigkeiten unter Windows und Linux.
Auf dem Mac Das ist normalerweise eine Datei, alles, was man tun muss, ist herunterzuladen. .dmgIn den meisten Fällen hat es keine Abhängigkeiten, außer denjenigen, die standardmäßig mit macOS bereitgestellt werden. Ausnahmen sind komplexe Anwendungen, die eine entsprechende Laufzeitumgebung benötigen, zum Beispiel Java.
Auf Haiku Paket herunterladen. .hpkg Für dieselbe Java-Anwendung könnte es unzureichend sein, da Java auf dem Zielgerät sowohl installiert als auch nicht installiert sein kann. Gibt es eine Möglichkeit, alle Abhängigkeiten für dieses Paket herunterzuladen? .hpkg, abgesehen von denjenigen, die standardmäßig in Haiku installiert sind und daher auf jedem Haiku-System vorhanden sein sollten?
In dieser Kategorie gewinnt Mac mit einem kleinen Vorsprung.
Kommentar von mr. waddlesplash:
Um ein Programm zu schreiben, das alle Abhängigkeiten einer Anwendung als Paketset sammelt,
.hpkggenügt es jemandem, der mit den internen Funktionsweisen von Haiku vertraut ist, etwa 15 Minuten. Die Unterstützung hierfür hinzuzufügen, ist nicht allzu kompliziert, wenn es eine tatsächliche Notwendigkeit gibt. Aber für mich ist das eine rar vorkommende Situation.
Lassen Sie uns bis zum nächsten Artikel in dieser Reihe den Atem anhalten.
Verschieben von Paketen an einen separaten Ort
Wie ich bereits vorher erwähnt habe, möchte ich meine Pakete ablegen. .hpkg (oder einen Teil davon) an einen speziellen Ort, der von der regulären Platzierung auf dem Bootlaufwerk (der Root-Partition) getrennt ist. In der Regel (und das ist nicht nur theoretisch) liegt es daran, dass der Speicherplatz auf meinen (integrierten) Laufwerken ständig knapp wird, egal wie groß sie sind. Daher schließe ich normalerweise externe Festplatten oder Netzwerklösungen an, wo sich meine Anwendungen befinden.
Auf dem Mac Ich verschiebe einfach die Pakete .app auf ein externes Laufwerk oder einen Netzwerkordner im Finder, und das war's. Ich kann die Anwendung immer noch mit einem Doppelklick wie gewohnt vom Bootlaufwerk aus öffnen. Ganz einfach!
Auf Haiku, wie mir gesagt wurde, kann das erreicht werden, indem ich meine .hpkg Pakete auf ein externes Laufwerk oder einen Netzwerkordner verschiebe, aber dann muss ich einige nicht dokumentierte Befehle in der Konsole verwenden, um sie im System zu mounten. Ich weiß nicht, wie man das nur mit der GUI macht.
In dieser Kategorie gewinnt der Mac.
Laut Mr. waddlesplash:
Hier geht es um Optimierung für den regulären Gebrauch. Wenn die Nachfrage jedoch höher ist als die eines einzelnen Benutzers, werden wir das umsetzen. In jedem Fall gibt es die Möglichkeit einer Drittanbieter-Implementierung.
Darüber werden wir im nächsten Artikel berichten.
Wenn es um Netzverzeichnisse geht: Es wäre großartig (ich nehme an, LAN-Partys) einfache, entdeckbare, netzwerkweite Anwendungen (zum Beispiel durch Zeroconf) zu haben, die man auf den lokalen Computer kopieren oder direkt aus dem lokalen Netzwerk starten kann. Natürlich haben die Entwickler die Möglichkeit zur Ablehnung über app_flags.
Den Abschlussbericht zur Integration des hpkg mit GUI
Ich glaube, dass die Integration vor allem aufgrund der relativen Neuheit .hpkg mit GUI noch verbesserungswürdig ist. Auf jeden Fall gibt es einige Aspekte, die im Hinblick auf die Benutzererfahrung verbessert werden können…
Ein weiterer Punkt: Kernel Debug Land
Es wäre toll, bei Kernel-Panic die Möglichkeit zu haben, Befehle einzugeben, zum Beispiel syslog | grep usb. Nun, bei Haiku ist dies dank Kernel Debug Land möglich. Wie sieht man diese Magie in Aktion, wenn bei dir alles funktioniert, ohne in die Kernel-Panic zu geraten? Ganz einfach, indem du Alt+PrintScn+D drückst (Mnemonik Debug). Mir fällt sofort ein , der es den ursprünglichen Entwicklern von Macintosh ermöglichte, in den Debugger zu gelangen (sofern er natürlich installiert war).
Fazit
Ich beginne zu verstehen, dass die Raffinesse des Haiku-Systems daraus resultiert, dass es von einem kleinen Team mit einer klaren Ausrichtung auf die Arbeitsumgebung entwickelt wird, während alle Schichten des Systems verfügbar sind.
Ein krasser Kontrast zur Welt von Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, wo alles in so kleine Stücke zerlegt ist, dass Abstraktion auf Abstraktion sitzt und mit Krücken vorangetrieben wird.
Ich habe auch verstanden, wie das System .hpkg die besten Praktiken traditioneller Paketmanager, Snappy, Flatpak, AppImage, sogar btrfs kombiniert und sie mit dem Prinzip "es funktioniert einfach" von Mac mischt.
Es war, als hätte sich etwas "umschaltet" in meinem Kopf, und ich verstand, wie das System .hpkg Rollback-Funktionen bietet, — indem ich einfach einen Blick darauf werfe. Aber es ist nicht ich, sondern die Schönheit und Einfachheit des Systems. Vieles hier ist vom Geist des ursprünglichen Macs durchdrungen.
Ja, das Browsen kann ruckelig sein und die Leistung fühlt sich an wie bei einer Schnecke. Möglicherweise fehlen Anwendungen (kein Gtk, kein Electron – die Entwickler haben festgestellt, dass diese schlecht mit der Eleganz harmonieren), und die Video- und 3D-Beschleunigung könnte ganz fehlen. Dennoch gefällt mir dieses System. Denn viele dieser Dinge lassen sich beheben, und sie werden früher oder später verfügbar sein. Es ist nur eine Frage der Zeit und vielleicht ein wenig Geduld.
Ich kann keine Hilfe anbieten, aber ich denke, ab diesem Moment wird es losgehen. Jahr Haiku auf dem Desktop.
Zufällige Probleme
Gibt es bereits Anfragen, oder sollte ich neue eröffnen?
- BeScreenCapture sollte die Möglichkeit bieten, in GIF zu exportieren, wie es bei Peek der Fall ist. Das kann mit ffmpeg umgesetzt werden, das bereits für Haiku verfügbar ist. .
- Das Programm für Screenshots kann kein modales Fenster aufnehmen, sondern nimmt stattdessen den gesamten Bildschirm auf.
- Mit dem Zuschneidewerkzeug in WonderBrush können Screenshots nicht zugeschnitten werden, und das Ergebnis kann anschließend nicht in einer Datei gespeichert werden.
- Ich mag den Handzeiger in Haiku nicht besonders, aber ich glaube, das hängt mit warmen nostalgischen Gefühlen zusammen. Es ist besonders frustrierend, wenn man das Zuschneidewerkzeug in Krita verwendet, da es zu ungenauen Zuschnitten führt (siehe Screenshots mit Dialogfeldern in diesem Artikel). Ein Fadenkreuzzeiger wäre wunderbar. .
Probieren Sie es selbst! Das Haiku-Projekt bietet ISO-Images zum Herunterladen von DVD oder USB, die . Für die Installation genügt es, das Abbild herunterzuladen und mit Hilfe von
Haben Sie Fragen? Wir laden Sie ein in unseren russischsprachigen .
Fehlerübersicht:
Ab Übersetzung: dies ist der sechste Artikel aus der Reihe über Haiku.
Artikelübersicht:
Quelle: habr.com
