TL;DR: Haiku ist ein Betriebssystem, das speziell für PCs entwickelt wurde, weshalb es einige Tricks gibt, die seine Arbeitsumgebung viel besser machen als andere. Aber wie funktioniert es?
entdeckte ich Haiku, ein unerwartet gutes System. Ich bin nach wie vor erstaunt, wie flüssig es läuft, besonders im Vergleich zu Linux-Arbeitsumgebungen. Heute werde ich einen Blick unter die Haube werfen. Wo es für ein tieferes Verständnis notwendig ist, werde ich Vergleiche mit dem ursprünglichen Macintosh, Mac OS X und Linux-Arbeitsumgebungen (Standard XDG von freedesktop.org) anstellen.
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 will ich mir anschauen, wie das tatsächlich funktioniert.
Ressourcen? ab , der ursprüngliche Schöpfer des Macintosh Finders und "Vater" des Macintosh Resource Managers:
Es stört mich, dass die traditionelle Codierung so starr ist. Für mich ist die Idee einer Anwendung, die in Code eingefroren ist, ohne die Möglichkeit, irgendetwas dynamisch zu ändern, ein echter Wahnsinn. Es sollte möglich sein, so viel wie möglich zur Laufzeit zu ändern. Natürlich kann der Code der Anwendung selbst nicht verändert werden, aber es gibt doch Dinge, die ohne Neukompilierung geändert werden können?
Auf dem ursprünglichen Macintosh wurde es so gestaltet, dass diese Dateien eine "Datensektion" und eine "Ressourcensektion" haben, was das Speichern verschiedener Dinge, wie Icons, Übersetzungen usw., in ausführbaren Dateien erheblich erleichterte.
Auf dem Mac wird dafür , ein grafisches Programm — überraschenderweise — zur Bearbeitung von Ressourcen, verwendet.
ResEdit auf dem ursprünglichen Macintosh
Ermöglichte es, Icons, Menüpunkte, Übersetzungen usw. relativ einfach zu bearbeiten, allerdings "reisen" sie dennoch mit den Anwendungen.
In jedem Fall hatte dieser Ansatz einen großen Nachteil: Er funktionierte nur auf Dateisystemen von Apple, was einer der Gründe war, warum Apple die "Ressourcensektion" beim Übergang zu Mac OS X aufgegeben hat.
In Mac OS X wollte Apple eine lösungsunabhängige Struktur, daher wurden Pakete (von NeXT) verwendet, Verzeichnisse, die vom Dateimanager wie "undurchsichtige Objekte", ähnlich Dateien und nicht Verzeichnissen, behandelt werden. Jedes Paket mit einer Anwendung im Format .app hat unter anderem die Datei Info.plist (in einer Art JSON oder YAML von Apple), das Metadaten der Anwendung enthält.
Schlüssel der Info.plist Datei im Mac OS X Anwendungsbundle.
Ressourcen, wie Icons, UI-Dateien und andere, werden im Bundle als Dateien gespeichert. Das Konzept ist im Grunde zu den Wurzeln in NeXT zurückgekehrt.
Mathematica.app auf NeXTSTEP 1.0 im Jahr 1989: erscheint als Verzeichnis mit Dateien im Terminal, aber als ein einzelnes Objekt im grafischen Dateimanager.
Kehren wir zu BeOS zurück, auf dessen Konzepten Haiku basiert. Ihre Entwickler entschieden bei der Umstellung von PEF (PowerPC) auf ELF (x86) (das gleiche, was auf Linux verwendet wird), eine Ressourcensektion an das Ende der ELF-Dateien anzufügen. Hierfür wurde keine eigene, zuständige ELF-Sektion verwendet; sie wurde einfach an das Ende der ELF-Datei angehängt. Infolgedessen haben Programme strip und andere aus binutils, die nichts davon wissen, sie einfach entfernt. Daher ist es besser, mit Tools aus Linux nicht an ELF-Dateien zu arbeiten, in die Ressourcen auf BeOS hinzugefügt wurden.
Und was passiert jetzt mit Haiku? Im Prinzip mehr oder weniger dasselbe.
Theoretisch könnte man Ressourcen in der passenden ELF-Sektion unterbringen. Laut den Entwicklern im Kanal #haiku im irc.freenode.net:
Mit ELF würde die Sektion mehr Sinn machen ... der einzige Grund, warum wir es nicht so machen, ist, weil man es in BeOS so gemacht hat.
Und es ist jetzt nicht sinnvoll, das zu ändern.
Ressourcenverwaltung
Ressourcen werden in einem strukturierten 'Ressourcen'-Format geschrieben: im Grunde eine Liste von Ressourcen mit Größen und dann deren Inhalt. Mir fiel .
ein. Wie prüft man Ressourcen in Haiku? Gibt es so etwas wie ResEdit?
Laut :
Um die Ressourcen, die im Anwendungsbundle geliefert werden, anzusehen, kann man die ausführbare Datei in ein Programm wie ziehen. Man kann auch das Terminal öffnen und den Befehl
listres dateiname.
ausführen. Resourcer ist im HaikuDepot verfügbar, aber bei mir stürzt es einfach ab.
Wie verwaltet man Ressourcen in ELF-Dateien? Mit rsrc und werden. werden rdef rsrcDateien in werden . Die Datei rsrc wird im normalen Textformat gespeichert, sodass die Arbeit mit ihr viel einfacher ist. Die Datei im Format wird an das Ende der ELF-Datei angehängt. Lassen Sie uns versuchen, ein bisschen zu experimentieren:
~> rc -h
Haiku Resource Compiler 1.1Um ein rdef-Skript in eine Ressourcendatei zu kompilieren:
rc [Optionen] [-o ] ...Um eine Ressourcendatei wieder in ein rdef-Skript zu konvertieren:
rc [Optionen] [-o ] -d ...Optionen:
-d --decompile erstellt ein rdef-Skript aus einer Ressourcendatei
--auto-names konstruiert Ressourcennamen aus ID-Symbolen
-h --help zeigt diese Nachricht an
-I --include fügt zur Liste der Include-Pfade hinzu
-m --merge löscht den Inhalt der Ausgabedatei nicht
-o --output gibt den Namen der Ausgabedatei an, Standard ist out.xxx
-q --quiet zeigt keine Fehlermeldungen an
-V --version zeigt die Softwareversion und Lizenz anDas Programm kann verwendet werden xres zum Überprüfen und Verwalten:
/> 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 werden kann gelesen werden .
Standardressourcentypen
Obwohl man alles Mögliche in Ressourcen speichern kann, gibt es einige bestimmte Standardtypen:
app_signature: MIME-Typ der Anwendung, zur Zuordnung von geöffneten Dateien, damit sie gestartet werden, IPC usw.app_name_catalog_entry: Da der Anwendungsname normalerweise auf Englisch ist, kann hier angegeben werden, wo die übersetzten Namen gespeichert sind, sodass Benutzer verschiedener Sprachen bei Bedarf den übersetzten Anwendungsnamen sehen.app_version: genau das, was Sie denkenapp_flags: gibt anregistrarwie die Anwendung verarbeitet werden soll. Ich glaube, es gibt mehr, als es auf den ersten Blick scheint. Zum Beispiel gibt esB_SINGLE_LAUNCH, das das System zwingt, jedes Mal einen neuen Anwendungsprozess auf Anfrage des Benutzers zu starten (dieses Prinzip wird für die meisten Anwendungen unter Linux verwendet). Es gibtB_MULTIPLE_LAUNCH, das einen Prozess für jede Datei. Schließlich gibt esB_EXCLUSIVE_LAUNCH, das das System zwingt, immer nur einen Prozess gleichzeitig zu starten, egal wie oft Benutzer ihn starten (zum Beispiel wird Firefox unter Linux auf die gleiche Weise gestartet; das gleiche Ergebnis kann in Qt-Anwendungen erzielt werden, indem man die Funktion ). Anwendungen mitB_EXCLUSIVE_LAUNCHwerden benachrichtigt, wenn der Benutzer versucht, sie erneut zu starten: sie erhalten beispielsweise den Pfad zur Datei, die der Benutzer damit öffnen möchte.vector_icon: Vektoricon der Anwendung (In BeOS gab es keine Vektoricons; die meisten Anwendungen hatten stattdessen zwei Rastericons in den ausführbaren Dateien).
Natürlich kann man Ressourcen mit beliebigen IDs und Typen hinzufügen, die dann im Anwendung selbst oder in anderen Anwendungen mit der Klasse BResourcesgelesen werden können. Aber zuerst lasst uns bei dem spannenden Thema der Icons bleiben.
Vektor-Icons im Haiku-Stil
Natürlich hat nicht nur Haiku das beste Icon-Format ausgewählt, die Situation mit den Desktop-Umgebungen unter Linux ist in diesem Bereich alles andere als ideal:
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.cacheAnschauen kann man schon spüren, worum es sich bei diesem Stück handelt.
Es gibt natürlich auch scalable, das, wie man verstehen kann, vektorbasierte Icons enthält. Warum gibt es dann noch etwas anderes? Weil die Darstellung von Vektorgrafiken in kleinen Größen schlechter sein kann als ideal. Man möchte verschiedene Varianten haben, die für unterschiedliche Größen optimiert sind. In Desktop-Umgebungen unter Linux wird dies durch das Streuen von Icons mit unterschiedlichen Größen im Dateisystem erreicht.
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.pngBeachten Sie: Es gibt kein Konzept verschiedener Versionen von Firefox. Daher kann die Situation mit mehreren Versionen der Anwendung im System nicht differenziert behandelt werden.
Verschiedene Icons von Firefox in verschiedenen Versionen. Bisher ist es unter Linux nicht möglich, dies ohne verschiedene Hacks zu behandeln.
Mac OS X behandelt dies etwas raffinierter:
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 sichtbar, dass es eine Datei 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 befinden sich in einer Datei.
Kommen wir zurück zu Haiku. Eine verblüffende Lösung, ohne Ausnahmen. Laut :
wurde ein spezielles, hochoptimiertes Format für kleine Größen und schnelle Darstellung, das HVIF, entwickelt. Deshalb sind unsere Icons meistens viel kleiner als im Raster- oder allgemein verwendeten SVG-Format.
Und sie sind tatsächlich optimiert:
Die Größen des Icons im HVIF im Vergleich zu anderen Formaten.
Der Unterschied ist erheblich!
Aber die Magie hört hier nicht auf. Das gleiche HVIF kann unterschiedliche Detaillierungsstufen abhängig von der angezeigten Größe zeigen, obwohl es ein Vektorformat ist.
Verschiedene Detaillierungsstufen (LOD) je nach Größe der Darstellung
Jetzt zu den Nachteilen: Man kann nicht einfach SVG nehmen, in ImageMagick stecken und damit aufhören, man muss mehrere Zyklen durchlaufen, um ein Icon im HVIF-Format zu erstellen. Erklärungen. Allerdings kann IconOMatic SVGs nicht perfekt importieren; etwa 90 % der SVG-Details werden mit einer gewissen Wahrscheinlichkeit importiert, die verbleibenden 10 % müssen manuell angepasst und geändert werden. Lesen Sie mehr darüber, wie HVIF seine Magie wirkt. im Blog
Hinzufügen eines Icons zur Anwendung
Jetzt kann ich das Icon zu dem erstellten Paket hinzufügen, , unter Berücksichtigung aller gesammelten Informationen.
Und da ich momentan keine große Lust habe, ein eigenes Icon für meine "Hallo, Welt" QtQuickApp zu zeichnen – hole ich es mir 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 CreatorLass 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?
Das kopierte VICN:101:BEOS:ICONs wird vorerst nicht als Icon für die Anwendung im Dateimanager verwendet.
Was habe ich übersehen?
Kommentar des Entwicklers:
Eine Datei muss erstellt werden
werdenmit allen Ressourcen, dann den Befehl ausführenrc name.rdef, das wird eine Datei erzeugen.rsrc. Dann muss der Befehl ausgeführt werdenresattr -o name_binary name.rsrc. Zumindest verwende ich ähnliche Befehle, um Icons zu meinen Skripten hinzuzufügen.
Nun, ich wollte eine Ressource erstellen, kein Attribut. Ich bin total verwirrt.
Intelligente Speicherung mit dem Dateisystem
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 die Kopie auf ein anderes Dateisystem. Danach wird es jedoch auch in das Attribut des Dateisystems kopiert, zum Beispiel BEOS:ICON. Das funktioniert nur auf bestimmten Dateisystemen, wie zum Beispiel BFS. Die vom System angezeigten Icons (im Tracker und in der Deskbar) werden aus diesem erweiterten Attribut gelesen, da diese Lösung schnell funktioniert. An einigen Stellen (wo Geschwindigkeit nicht entscheidend ist, wie im Infofenster „Über“) erhält das System das Icon direkt aus der Ressource in der Datei. Aber das ist noch nicht das Ende. Denken Sie daran, dass Benutzer auf dem Mac die Icons von Anwendungen, Verzeichnissen und Dokumenten durch ihre eigenen ersetzen konnten, da der Mac die Möglichkeit bietet, solche "wichtigen" Dinge zu tun, wie . Auf Haiku sollte man die Ressource (in der Datei) als das ursprüngliche Symbol ansehen, das mit der Anwendung geliefert wird, und das Attribut (im Dateisystem BFS) als etwas, das dem Benutzer ermöglicht, Änderungen nach Belieben vorzunehmen (obwohl, Hinweis, die grafische Benutzeroberfläche für das Einfügen eines benutzerdefinierten Symbols über das Standardsymbol bisher noch nicht umgesetzt ist).
Überprüfung der Dateisystemattribute
Mit Hilfe von resaddr gibt es die Möglichkeit, die Dateisystemattribute zu prü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 ist es "Kleber", der die Umwandlung hin und her zwischen (zuverlässigen) Ressourcen und (schnellen) Dateisystemattributen vornimmt. Und da das System die Ressourcenerfassung vorsieht und die Kopie automatisch durchführt, werde ich mir keine weiteren Gedanken darüber machen.
Die Magie der hpkg-Pakete
Derzeit (am häufigsten) werden Pakete verwendet, um Programme auf Haiku zu erhalten. .hpkg. Lassen Sie sich nicht von dem einfachen Namen täuschen: Das Format .hpkg funktioniert völlig anders als andere Formate mit ähnlichen Namen, mit denen Sie möglicherweise in Berührung gekommen sind; es hat echte Superkräfte.
Mit traditionellen Paketformaten habe ich mich lange über diese Tatsache geärgert: Man lädt eines herunter (Paket), aber im System wird ein anderes installiert (Dateien im Paket). Es ist ziemlich schwierig, mit Dateien umzugehen (zum Beispiel sie zu löschen), wenn ein Paket auf traditionelle Weise installiert wird. Das liegt daran, dass der Inhalt des Pakets sich über das gesamte Dateisystem verteilt, einschließlich der Orte, an denen ein normaler Benutzer möglicherweise keinen Schreibzugriff hat. Das führt zu einer ganzen Klasse von Programmen — Paketmanagern. Und tatsächlich wird der Transfer bereits installierter Software, zum Beispiel auf einen anderen Computer, ein Wechseldatenträger oder einen Dateiserver, sogar noch schwieriger, wenn nicht gar unmöglich. In einem typischen Linux-basierten System können leicht mehrere hunderttausend bis Millionen isolierter Dateien existieren. Das liegt auf der Hand, dass dies gleichzeitig sowohl fragil als auch langsam ist, zum Beispiel bei der anfänglichen Systeminstallation, bei der Installation, Aktualisierung und Deinstallation herkömmlicher Pakete sowie beim Kopieren des Bootvolumes (der Root-Partition) auf ein anderes Medium.
Ich arbeite an dem Projekt AppImage, einem teilweisen Workaround für Anwendungen von Endbenutzern. Es handelt sich um ein Software-Verteilungsformat, das die Anwendung und alle ihre Abhängigkeiten in ein einzelnes Abbild des Dateisystems bündelt, das beim Start der Anwendung eingebunden wird. Das vereinfacht vieles, da das gleiche ImageMagick plötzlich in eine Datei verwandelt wird, die von normalen Nutzern im Dateimanager verwaltet wird. Das vorgeschlagene Verfahren funktioniert nur für Software, wie der Name des Projekts schon sagt, und hat auch seine eigenen Probleme, da diejenigen, die Software für Linux bereitstellen, immer die Verantwortung auf mich schieben.
Kommen wir zu Haiku zurück. Ist es gelungen, das optimale Gleichgewicht zwischen traditionellen Paketverwaltungssystemen und der Bereitstellung von Software in Form von Abbildern zu finden? Ihre Pakete .hpkg sind tatsächlich komprimierte Abbilder des Dateisystems. Beim Booten des Systems bindet der Kernel alle installierten und aktiven Pakete mit etwa folgenden Kernel-Meldungen ein:
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 sich fest, es wird noch besser!
Es gibt ein sehr spezielles 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 direkt aus dem Bootvolume (der Root-Partition) extrahiert, sondern wird ordentlich aus dem Paket an seinen Platz geladen. .hpkgWow! Ich habe bereits angedeutet, dass ich der Meinung bin, dass ein Teil der allgemeinen Raffinesse und Kohärenz von Haiku darauf zurückzuführen ist, dass das gesamte System, von Kern und Benutzeroberfläche bis hin zur Paketverwaltung und Infrastruktur der Arbeitsumgebung, von einem einzigen Team gemeinsam entwickelt wird. Stellen Sie sich vor, wie viele verschiedene Gruppen und Teams benötigt werden, um etwas Ähnliches auf Linux-Basis zu starten. [Ich stelle mir das Projekt PuppyLinux vor, Anm. des Übersetzers]. Stellen Sie sich vor, wie viel Zeit es in Anspruch nehmen würde, bis dieser Ansatz in die Distributionen integriert ist. Es heißt doch: Nimm eine einfache Aufgabe, teile sie unter verschiedenen Ausführenden auf, und schon wird sie so kompliziert, dass sie nicht mehr zu lösen ist. Haiku hat mir in diesem Fall die Augen geöffnet. Ich denke, genau das passiert gerade mit Linux (Linux ist hier ein Sammelbegriff für den Stack Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Systemrollback mit hpkg
Wie oft kommt es vor, dass ein Update erfolgreich war, aber dann stellt sich heraus, dass etwas nicht so funktioniert, wie es sollte? Wenn man gewöhnliche Paketmanager verwendet, ist es schwierig, den Zustand des Systems auf den Zeitpunkt vor der Installation neuer Pakete zurückzusetzen (zum Beispiel, wenn etwas schiefgelaufen ist). Einige Systeme bieten Umgehungslösungen in Form von Snapshots des Dateisystems an, aber diese sind recht umständlich und werden nicht in allen Systemen angewendet. In Haiku wird dies durch Pakete gelöst. .hpkg. Jedes Mal, wenn Pakete im System geändert werden, werden die alten Pakete nicht gelöscht, sondern im System in Unterverzeichnissen gespeichert, die /Haiku/system/packages/administrative/state-<...>/ ständig. Unvollendete Operationen speichern ihre Daten in Unterverzeichnissen /Haiku/system/packages/administrative/transaction-<...>/.
Inhalt /Haiku/system/packages/administrative. Die Verzeichnisse „state…“ enthalten Textdateien mit den Namen aktiver Pakete, „transaction…“ – die Pakete selbst.
Der „alte aktive Zustand“, d. h. die Liste .hpkg von Paketen, die vor den Änderungen aktiv waren, wird nach jeder Operation im Dateimanager in einer Textdatei gespeichert. /Haiku/system/packages/administrative/state-<...>/activated-packages. In ähnlicher Weise wird der neue „aktive Zustand“ in einer Textdatei geschrieben. /Haiku/system/packages/administrative/activated-packages.
Verzeichnis /Haiku/system/packages/administrative/state-<...>/ enthält nur eine Textdatei mit der Liste der aktiven Pakete dieses Zustands (im Falle der Installation von Paketen ohne Löschung), und wenn Pakete gelöscht oder aktualisiert wurden, enthält das Zustandsverzeichnis die alten Versionen der Pakete.
Beim Booten des Systems wird auf Basis der Paketliste entschieden, ob Pakete aktiviert (gemountet) werden. So einfach ist das! Wenn beim Booten etwas schiefgeht, kann der Boot-Manager angewiesen werden, eine andere, ältere Liste zu verwenden. Problem gelöst!
Der Bootloader von Haiku. Jeder Einstiegspunkt spiegelt den entsprechenden „aktiven Zustand“ wider.
Mir gefällt der Ansatz mit einfachen Textdateien als Liste des „aktiven Zustands“, in denen verständliche Namen aufgezeichnet sind. .hpkg. Das steht in starkem Kontrast zu dem für Maschinen und nicht für Menschen Geschaffenen von OSTree oder Flatpak im Dateisystem (auf derselben Ebene wie Microsoft GUID).
Liste aktiver Pakete zu jedem Zeitpunkt
Konfigurationsdaten
Offensichtlich befinden sich im Verzeichnis /Haiku/system/packages/administrative/writable-files Einstellungsdateien für Pakete, jedoch schreibgeschützt. Denn, wie Sie sich erinnern, .hpkg werden nur schreibgeschützte eingehängt. Daher müssen diese Dateien vor dem Schreiben aus Paketen kopiert werden. Das macht Sinn.
GUI-Integration für das System .hpkg
Schauen wir uns nun an, wie diese großartigen Pakete .hpkg die Integration in die Benutzeroberfläche (UX) handhaben. Schließlich ist Haiku für den persönlichen Gebrauch gedacht. Persönlich habe ich hohe Maßstäbe gesetzt und die Benutzererfahrung mit Paketen .app auf Macintosh mit derselben Erfahrung auf .hpkg. Ich will die Situation mit Arbeitsumgebungen auf Linux gar nicht vergleichen, denn sie ist im Vergleich zu allen anderen absolut schrecklich.
Folgende Szenarien kommen mir in den Sinn:
- Ich möchte den Inhalt des Pakets ansehen
.hpkg - Ich möchte ein Paket installieren
- Ich möchte ein Paket entfernen
- Ich möchte etwas entfernen, das als Teil eines Pakets in das System gekommen ist
- Ich möchte etwas kopieren, das als Teil eines Pakets in das 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, abseits vom Bootvolume (Hauptpartition), da ich beispielsweise nicht genügend Platz habe.
Das sollte die meisten grundlegenden Fälle aus meinem Alltag abdecken. Nun, lassen Sie uns beginnen.
Überprüfung des Paketinhalt
Auf dem Mac klicke ich einfach mit der rechten Maustaste auf das Paket, um es zu öffnen und den Inhalt im Finder anzuzeigen. Das ist schließlich nur ein maskierter Ordner! (Ich weiß, dass es Pakete .pkg für Teile des Systems gibt, die keine Anwendungen sind, aber normale Benutzer interagieren seltener damit).
Auf Haiku klicke ich mit der rechten Maustaste auf das Paket, dann auf 'Inhalte', um zu sehen, was drin ist. Aber hier gibt es einfach nur eine Liste von Dateien ohne Möglichkeit, sie durch Doppelklicken zu öffnen.
Es wäre viel besser, wenn es eine Möglichkeit (vorübergehendes) gäbe, das Paket zu mounten .hpkg um über den Dateimanager zu betrachten, damit der Benutzer sich nicht um die Implementierungsdetails kümmern muss. (Übrigens kann man öffnen .hpkg das Paket in Expander, das es entpacken kann wie jede andere Archivdatei).
Im HaikuDepot-Interface kann man die Dateiliste des Pakets einsehen, aber es gibt keine Möglichkeit, den Inhalt anzuzeigen, zum Beispiel indem man zweimal auf die README.md klickt.
In dieser Kategorie hat Mac die Nase vorn, aber das Hinzufügen der benötigten Funktionalität zu HaikuDepot sollte keine größeren Schwierigkeiten bereiten.
Installation des Pakets über das GUI
Auf dem Mac, die meisten Disk-Images .dmg enthalten Pakete .app. Wir öffnen das Disk-Image mit einem Doppelklick, danach kopieren wir das Paket, zum Beispiel, indem wir es 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 „bietet“ Apple ein gemeinsames Verzeichnis an /Applications (bei NeXT war es netzwerkbasiert und auch individuell), aber man kann seine Anwendungen leicht auf einem Dateiserver oder in einem Unterverzeichnis ablegen $HOME/Applications, wenn es einem so gefällt.
Auf Haiku, Doppelklick auf das Paket, dann Klick auf „Install“, einfacher geht es nicht. Mich interessiert, was passiert, wenn das Paket Abhängigkeiten hat, die in HaikuPorts verfügbar, aber noch nicht installiert sind. Unter Linux weiß man in dieser Situation wirklich nicht, was zu tun ist, aber die Lösung ist offensichtlich – den Benutzer fragen, ob er die Abhängigkeiten herunterladen und installieren möchte. Genau das macht Haiku.
Ich habe das Paket ‚sanity‘ manuell heruntergeladen und darauf geklickt, der Paketmanager weiß, wo er die Abhängigkeiten herbekommen kann (vorausgesetzt, die Repositories sind bereits im System eingetragen). Nicht jede Linux-Distribution kann das.
Ein weiterer Weg ist die Verwendung des Dateimanagers, man muss nur das Paket ziehen .hpkg oder in /Haiku/system/packages (für die systemweite Installation, standardmäßig), oder in /Haiku/home/config/packages (für die individuelle Installation; beim Doppelklick nicht verfügbar – das Wort „config“ an dieser Stelle ärgert mich immer noch, weil es für mich hier ein Synonym für „settings“ ist). Dabei ist das Konzept mehrerer Benutzer für Haiku noch nicht einmal verfügbar (wahrscheinlich ist das der Grund, warum alles so einfach ist – ich weiß nicht, vielleicht würden mehrbenutzermöglichkeiten die Dinge für die Arbeitsumgebung eines Personal Computers unnötig komplizieren).
In dieser Kategorie gewinnt Haiku, weil es nicht nur mit Anwendungen, sondern auch mit Systemprogrammen umgehen kann.
Deinstallation des Pakets über das GUI
Auf dem Mac, Sie müssen das Anwendungssymbol in den Papierkorb ziehen, und das war's. Ganz einfach!
Auf Haiku, erstens müssen Sie finden, wo das Paket im System ist, denn es ist selten, dass Sie es an den richtigen Ort installieren (das macht das System). Normalerweise muss man in /Haiku/system/packages (bei einer Standardinstallation auf Gesamtsystemebene) suchen oder in /Haiku/home/config/packages (habe ich schon gesagt, dass „config“ der falsche Name ist?). Dann wird die Anwendung einfach in den Papierkorb gezogen, und das war's.
Ganz einfach! Allerdings würde ich das nicht so sagen. Folgendes passiert tatsächlich:
Das passiert, wenn Sie die Anwendung aus /Haiku/system/packages
versuchen, die Anwendung „Hallo, Welt“ von QtQuickApp in den Papierkorb zu verschieben. Ich habe nicht versucht, das Systemverzeichnis zu verschieben, und da alle Pakete im Systemverzeichnis installiert werden, kann das Paket nicht entfernt werden .hpkg ohne das seine Inhalte. Ein normaler Benutzer wäre wahrscheinlich erschrocken und hätte die standardmäßig zugewiesene Schaltfläche „Abbrechen“ gedrückt.
Erklärt :
Diese Nachricht ist über 10 Jahre alt. Wahrscheinlich müssen wir sie so einrichten, dass die Warnung nur beim Verschieben des eigentlichen Pakets erscheint. Normale Benutzer müssen das in jedem Fall nicht tun.
Gut, vielleicht sollte ich das tun, indem ich HaikuDepot benutze? Ich doppelklicke auf das Paket in /Haiku/system/packages, in der Erwartung, dass die Schaltfläche „Deinstallieren“ angezeigt wird. Nope, es gibt (nur) „Installieren“. Wo bist du, „Deinstallieren“?
Zur Abwechslung habe ich versucht zu sehen, was passiert, wenn ich „Installieren“ für ein bereits installiertes Paket klicke. Es passiert Folgendes:
Das passiert, wenn Sie versuchen, ein bereits installiertes Paket zu installieren.
Dann erscheint:
Wenn Sie im vorherigen Fenster auf „Änderungen anwenden“ klicken, passiert Folgendes:
Ich vermute, das ist ein Softwarefehler, der Antrag auf einen Bug-Report existiert bereits. [Der Autor hat keinen Link bereitgestellt, Anm. d. Übersetzer]
Schnelle Lösung: Fügen Sie die Schaltfläche „Deinstallieren“ hinzu, wenn das Paket bereits in
/Haiku/system/packages, oder in/Haiku/home/config/packages.
Wenn ich die Liste der in HaikuDepot installierten Pakete durchsehe, sehe ich mein Paket in der Liste und kann es entfernen.
In dieser Kategorie gewinnt der Mac. Aber ich kann mir vorstellen, dass bei entsprechender Konfiguration das Benutzererlebnis auf Haiku besser sein wird als auf dem Mac. (Einer der Entwickler hat das so bewertet: „Weniger als eine Stunde, um die angegebene Funktionalität in HaikuDepot hinzuzufügen, wenn Sie ein wenig über C++ wissen“, gibt es Freiwillige?)
Das Entfernen von etwas aus dem Paket
Lassen Sie uns versuchen, die Anwendung selbst zu entfernen und nicht das Paket. .hpkg, aus dem es hervorgegangen ist (ich bezweifle, dass es für „einfache Sterbliche“ irgendeinen Unterschied macht).
Auf dem Mac, der Benutzer tatsächlich in der Regel mit der Datei arbeitet, .dmg, wo das Anwendungs-Paket herkommt, .app. In der Regel werden die Images .dmg im Download-Verzeichnis gespeichert, die Pakete jedoch vom Benutzer nach /Applicationskopiert. Es gibt die Meinung, dass viele Benutzer selbst nicht wissen, was sie tun; diese Hypothese wird von einem ehemaligen Apple-Mitarbeiter bestätigt. (Eine der Sachen, die ich am Mac nicht mag. Bei AppImage gibt es zum Beispiel keinen Unterschied zwischen der Anwendung und dem Paket, in dem sie enthalten ist. Icon in den Papierkorb gezogen = das ist alles. Einfach!)
Auf Haiku, es gibt auch eine Trennung zwischen apps/ und packages/,so dass ich bezweifle, dass es den Benutzern dadurch klarer geworden ist. Was jedoch passiert, wenn Sie eine Anwendung aus apps/ in den Papierkorb ziehen:
Das passiert, wenn Sie versuchen, eine Anwendung zu löschen, die aus einer Datei .hpkg
stammt. Technisch gesehen ist es korrekt (denn die Anwendung ist auf einem nur lesbaren Dateisystem abgelegt, in erster Linie), aber es ist dem Benutzer nicht besonders nützlich.
Schnelle Lösung: Stattdessen durch die GUI löschen lassen,
.hpkg
Um es zum Spaß zu probieren, habe ich versucht, die Anwendung zu duplizieren, indem ich Alt+D gedrückt habe. Ich erhielt die Meldung „Objekte können auf einem nur lesbaren Volume nicht verschoben oder kopiert werden“. Und das alles, weil /system neben /system/packages und /system/settings) der Mountpunkt packagefs ist (erinnern Sie sich daran, wie es in der Ausgabe erscheint, df?). К сожалению, вывод команды mount klärt die Situation nicht (wie in einem der vorherigen Artikel erwähnt), mountvolume zeigt das Gesuchte nicht an (offensichtlich werden über loop gemountete Pakete nicht als „Volumes“ betrachtet), außerdem habe ich die alternativen Befehle vergessen. .hpkg In dieser Kategorie hat niemand gewonnen, außer AppImage (aber ganz ehrlich ist das eine voreingenommene Meinung). Man kann sich jedoch vorstellen, dass die Benutzererfahrung auf Haiku nach der Anpassung besser sein wird als auf dem Mac.
Hinweis: Es muss geklärt werden, was ein „Volume“ im Verhältnis zu einem „Verzeichnis“ ist. Wahrscheinlich ist es ähnlich wie das Verhältnis von „Ordner“ zu „Verzeichnis“: Die meisten Verzeichnisse werden im Dateimanager als Ordner angezeigt, aber nicht alle (zum Beispiel werden Pakete als Dateien verarbeitet). Macht mich solche Überlegungen offiziell zu einem Nerd?
Den Inhalt des Pakets auf ein anderes System kopieren,
, indem ich einfach das Paket ziehe,
Auf dem Mac, und da die Abhängigkeiten innerhalb des Pakets – sie werden zusammen verschoben. .app, ich ziehe die Anwendung, aber die Abhängigkeiten werden überhaupt nicht verarbeitet.
Auf Haiku, ich ziehe die App, aber die Abhängigkeiten werden überhaupt nicht verarbeitet.
Schnelle Lösung: Lassen Sie stattdessen den gesamten `hpkg`-Paket mit Abhängigkeiten, falls vorhanden, ziehen.
In dieser Kategorie gewinnt eindeutig Mac. Jedenfalls für mich, einen Liebhaber ihrer Paradigmen. Haiku sollte das kopieren. .hpkg anstatt der Anwendung, aber das System bietet mir so etwas nicht an…
Herunterladen des Pakets mit all seinen Abhängigkeiten.
Nicht jede Maschine ist ständig mit dem Netzwerk verbunden. Im Gegenteil, einige Maschinen (ja, ich schaue dich an, moderne Windows, Mac und Linux) vergessen das. Für mich ist es wichtig, dass ich zum Beispiel in ein Internetcafé gehen, Software auf ein tragbares Medium herunterladen, dieses Medium in meinen Heimcomputer einstecken und sicher sein kann, dass alles funktioniert [riskanter Typ, so etwas unter Windows durchzuziehen… — Anm. d. Übersetzers].
Infolgedessen erhalte ich etwas häufiger als gewöhnlich unerfüllte Abhängigkeiten unter Windows und Linux.
Auf dem Mac Es handelt sich normalerweise um eine Datei, alles, was nötig ist — herunterladen. .dmg. Meistens hat es keine Abhängigkeiten, außer denjenigen, die standardmäßig von macOS bereitgestellt werden. Einzige Ausnahme sind komplexe Anwendungen, die eine entsprechende Laufzeitumgebung erfordern, zum Beispiel Java.
Auf Haiku Paket herunterladen .hpkg für, sagen wir, dieselbe Anwendung auf Java, kann sich als unzureichend herausstellen, da Java sowohl auf der Zielmaschine vorhanden als auch nicht vorhanden sein kann. Gibt es eine Möglichkeit, alle Abhängigkeiten für dieses Paket herunterzuladen, .hpkgaußer denen, die standardmäßig in Haiku installiert werden und daher in jedem Haiku-System vorhanden sein sollten?
In dieser Kategorie gewinnt Mac mit einigem Abstand.
Kommentiert mr. waddlesplash:
Um ein Programm zur Sammlung aller Abhängigkeiten einer Anwendung in Form eines Satzes von Paketen zu schreiben,
.hpkgfür jemanden, der mit der internen Struktur von Haiku vertraut ist, reichen etwa 15 Minuten aus. Unterstützung dafür hinzuzufügen ist nicht allzu kompliziert, wenn es dafür einen echten Bedarf gibt. Aber für mich ist das eine seltene Situation.
Halten wir bis zum nächsten Artikel in dieser Reihe den Atem an.
Verschieben von Paketen an einen separaten Ort
Wie ich bereits zuvor geschrieben habe, möchte ich meine Pakete ablegen. .hpkg (oder Teil davon) an einen speziellen Ort, der vom normalen Speicherort auf dem Bootlaufwerk (Hauptpartition) getrennt ist. Normalerweise (nicht so theoretisch) ist der Grund dafür, dass der freie Speicherplatz auf meinen (internen) Festplatten ständig zur Neige geht, egal wie groß sie sind. Und ich schließe normalerweise externe Festplatten oder Netzwerkressourcen an, wo sich meine Anwendungen befinden.
Auf dem Mac Ich verschiebe einfach die Pakete .app auf ein externes Laufwerk oder ein Netzwerkverzeichnis im Finder, und das war's. Ich kann die Anwendung immer noch mit einem Doppelklick öffnen, so wie ich es normalerweise vom Bootlaufwerk gemacht habe. Ganz einfach!
Auf Haiku, wie mir gesagt wurde, kann das erreicht werden, indem ich meine .hpkg Pakete auf ein externes Laufwerk oder ein Netzwerkverzeichnis verschiebe, aber dann muss ich einige undocumented Kommandos im Terminal verwenden, um sie in das System einzuhängen. Ich weiß nicht, wie man das nur mit der GUI macht.
In dieser Kategorie gewinnt der Mac.
Laut Mr. Waddlesplash:
Hier gibt es eine Optimierung basierend auf der normalen Verwendung. Falls jedoch die Nachfrage größer ist als bei einem Benutzer, werden wir dies umsetzen. In jedem Fall gibt es die Möglichkeit einer Drittanbieterlösung.
Darüber werden wir im nächsten Artikel berichten.
Wenn es um Netzwerkverzeichnisse geht: Es wäre großartig (ich nehme an, LAN-Party), einfache, auffindbare, netzwerkbasierte Anwendungen (z.B. über Zeroconf) zu haben, die auf den lokalen Computer kopiert oder sofort aus dem lokalen Netzwerk gestartet werden können. Natürlich haben die Entwickler die Möglichkeit, dies abzulehnen über app_flags.
Den Abschlussbericht zur Integration des hpkg mit der GUI
Ich denke, dass die Integration .hpkg mit der GUI aufgrund der relativen Neuheit immer noch verbesserungswürdig ist. Auf jeden Fall gibt es einige Dinge, die im Hinblick auf die Benutzererfahrung verbessert werden können...
Eine weitere Sache: Kernel Debug Land
Es wäre großartig, bei einem Kernel-Panic die Möglichkeit zu haben, Befehle einzugeben, zum Beispiel syslog | grep usb. Nun, das ist bei Haiku dank Kernel Debug Land möglich. Wie kann man diese Magie in Aktion sehen, wenn bei Ihnen alles funktioniert, ohne dass es zu einem Kernel-Panic kommt? Ganz einfach, indem Sie Alt+PrintScn+D drücken (mnemonisch Debug). Mir fällt sofort ein , die es den ursprünglichen Entwicklern von Macintosh ermöglichte, in den Debugger einzusteigen (sofern dieser installiert war, versteht sich).
Fazit
Ich beginne zu verstehen, dass die Raffinesse des Haiku-Systems daher rührt, dass die Arbeit von einem kleinen Team mit einem klaren Fokus auf die Arbeitsumgebung ausgeführt wird, während alle Schichten des Systems verfügbar sind.
Ein starker Kontrast zur Welt von Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, wo alles in so kleine Teile zerlegt ist, dass Abstraktion auf Abstraktion sitzt und mit Krücken vorangetrieben wird.
Es kam auch das Verständnis, wie das System .hpkg die besten Praktiken traditioneller Paketmanager, Snappy, Flatpak, AppImage, selbst btrfs, kombiniert und sie mit dem Prinzip „einfach funktioniert“ von Mac mischt.
Es war, als ob sich etwas im Kopf „umgeschaltet“ hätte, und ich erkannte, wie das System .hpkg Rücksetzungen durchführen kann – einfach, indem ich es anschaue. Aber das bin nicht ich, sondern die Schönheit und Einfachheit des Systems. Vieles hier ist vom Geist des ursprünglichen Mac durchdrungen.
Ja, das Browsen von Seiten kann ruckartig sein und wie eine Schnecke laufen, es fehlen möglicherweise Anwendungen (kein Gtk, Electron – die Entwickler kamen zu dem Schluss, dass sie schlecht zur Raffinesse passen), Video- und 3D-Beschleunigung kann ganz fehlen, aber trotzdem gefällt mir dieses System. Denn diese Dinge können behoben werden und sie werden früher oder später kommen. Es ist nur eine Frage der Zeit und vielleicht ein wenig von roten Augen.
Ich kann keine Hilfe anbieten, aber ich denke, ab diesem Moment beginnt das Jahr von Haiku auf dem Desktop..
Zufällige Probleme
Gibt es vielleicht schon Anfragen oder soll ich welche eröffnen?
- BeScreenCapture sollte die Möglichkeit haben, in GIF zu exportieren, wie in Peek. Das kann mit ffmpeg gemacht werden, das bereits für Haiku vorhanden ist. .
- Das Programm zum Erstellen von Screenshots kann keinen Screenshot eines Modal-Fensters machen, sondern macht stattdessen einen Screenshot des gesamten Bildschirms.
- Screenshots können nicht mit dem Zuschneidewerkzeug in WonderBrush zugeschnitten werden, und das Ergebnis kann danach nicht in einer Datei gespeichert werden.
- Ich mag den Handzeiger in Haiku nicht besonders, aber ich glaube, das liegt an warmen nostalgischen Gefühlen. Es ist besonders frustrierend bei der Verwendung des Zuschneidewerkzeugs in Krita, da es zu ungenauen Zuschnitten führt (siehe Screenshots mit modalen Dialogen in diesem Artikel). Ein Kreuzcursor wäre großartig. .
Probieren Sie es selbst aus! Das Haiku-Projekt bietet Images zum Herunterladen von DVD oder USB, die täglich erstellt werden. . Um es zu installieren, müssen Sie nur das Image herunterladen und es mit
Fragen? Wir laden Sie in den russischsprachigen .
Fehlerübersicht:
Von Übersetzung: Dies ist der sechste Artikel aus der Reihe über Haiku.
Artikelübersicht:
Quelle: habr.com
