🥇Mon sixième jour avec Haiku : sous le capot des ressources, des icônes et des paquets

TL;DR: Haiku — un système d'exploitation spécialement conçu pour les PC, ce qui lui confère plusieurs astuces qui rendent son environnement de travail bien meilleur que d'autres. Mais comment cela fonctionne-t-il ?

Récemment J'ai découvert Haiku, un système incroyablement bon. Je suis encore étonné de la fluidité avec laquelle il fonctionne, en particulier par rapport aux environnements de travail sur Linux. Aujourd'hui, je vais jeter un œil sous le capot. Là où cela sera nécessaire pour une compréhension plus profonde, je ferai des comparaisons avec le Macintosh original, Mac OS X et les environnements de travail Linux (la norme XDG de freedesktop.org).

Ressources dans les fichiers ELF

Hier, j'ai appris qu'IconOMatic peut enregistrer des icônes dans les ressources rdef des fichiers exécutables ELF. Aujourd'hui, je veux voir comment cela fonctionne réellement.

Ressources ? Citation à partir de Bruce Horn, l'auteur original du programme Macintosh Finder et le « père » du Macintosh Resource Manager :

Je suis préoccupé par la nature rigide de l'écriture traditionnelle de code. Pour moi, l'idée même d'une application figée dans le code, sans possibilité de modifier quoi que ce soit dynamiquement, est une aberration. Il devrait y avoir la possibilité de modifier autant que possible au moment de l'exécution. Bien sûr, le code de l'application lui-même ne peut pas être modifié, mais ne peut-on pas changer certaines choses sans recompilation du code ?

Sur le Macintosh original, il a été conçu de manière à ce que ces fichiers aient une « section de données » et une « section de ressources », ce qui a extrêmement facilité la sauvegarde de diverses choses, comme des icônes, des traductions, etc., dans les fichiers exécutables.

Sur le Mac, cela est fait avec ResEdit, un programme graphique pour — surprise — l'édition de ressources.

ResEdit sur le Macintosh original

En conséquence, il est devenu possible de modifier des icônes, des éléments de menu, des traductions, etc., assez facilement, mais elles « voyagent » quand même avec les applications.
Quoi qu'il en soit, cette approche avait un grand inconvénient : elle ne fonctionnait que sur les systèmes de fichiers Apple, ce qui a été l'une des raisons pour lesquelles Apple a abandonné la « section de ressources » lors du passage à Mac OS X.
Sur Mac OS X, Apple souhaitait une solution indépendante du système de fichiers, ils ont donc adopté le concept de paquets (provenant de NeXT), des répertoires qui sont traités par le gestionnaire de fichiers comme des « objets opaques », semblables à des fichiers, et non des répertoires. Tout paquet d'application au format .app possède, entre autres, un fichier Info.plist (dans une sorte d'analogue JSON ou YAML d'Apple), contenant les métadonnées de l'application.

Clés du fichier Info.plist dans le paquet d'application Mac OS X.

Les ressources, comme les icônes, les fichiers UI et d'autres, sont stockées dans le paquet sous forme de fichiers. Le concept est en fait revenu à ses racines dans NeXT.

Mathematica.app sur NeXTSTEP 1.0 en 1989 : apparaît comme un répertoire de fichiers dans le terminal, mais comme un seul objet dans le gestionnaire de fichiers graphique.

Revenons à BeOS, sur lesquelles les concepts de Haiku sont basés. Ses développeurs, lors du passage de PEF (PowerPC) à ELF (x86) (le même utilisé sur Linux), ont décidé d'ajouter une section de ressources à la fin des fichiers ELF. Pour cela, aucune section ELF proprement dite n’a été utilisée, elle était simplement ajoutée à la fin du fichier ELF. En conséquence, les programmes strip et autres de binutils, qui ne connaissaient pas cela, l'ont simplement supprimée. Par conséquent, en ajoutant des ressources au fichier ELF sur BeOS, il vaut mieux ne pas travailler avec lui en utilisant des outils Linux.

Et que se passe-t-il maintenant avec Haiku ? En principe, plus ou moins la même chose.

En théorie, il serait possible de placer les ressources dans la section ELF appropriée. Selon les développeurs sur le canal #haiku dans le réseau irc.freenode.net :

Avec ELF, la section aurait plus de sens... la seule raison pour laquelle nous ne le faisons pas, c'est que c'est ainsi que cela se faisait dans BeOS.
Et il ne vaut pas la peine de changer cela maintenant.

Gestion des ressources

Les ressources sont écrites dans un format 'ressource' structuré : il s’agit essentiellement d’une liste de ressources avec des tailles, puis de leur contenu. Je me suis souvenu du format ar.
Comment vérifier les ressources dans Haiku ? Y a-t-il quelque chose comme ResEdit ?
Selon documentation:

Pour visualiser les ressources fournies dans le paquet d'application, vous pouvez faire glisser le fichier exécutable sur un programme comme Resourcer. Vous pouvez également ouvrir le terminal et exécuter la commande listres nom_du_fichier.

Resourcer est disponible dans HaikuDepot, mais il plante simplement chez moi.

Comment gérer les ressources dans les fichiers ELF ? En utilisant rsrc et rdef. rdef les fichiers sont rassemblés dans rsrc. Le fichier rdef est stocké dans un format texte ordinaire, ce qui le rend beaucoup plus facile à manipuler. Le fichier au format rsrc est ajouté à la fin du fichier ELF. Essayons de jouer :

~> rc -h
Compilateur de ressources Haiku 1.1Pour compiler un script rdef en un fichier de ressources :
    rc [options] [-o ] ...Pour convertir un fichier de ressources en un script rdef :
    rc [options] [-o ] -d ...Options :
    -d --decompiler       créer un script rdef à partir d'un fichier de ressources
       --auto-names      construire des noms de ressources à partir de symboles ID
    -h --help            afficher ce message
    -I --include    ajouter  à la liste des chemins d'inclusion
    -m --merge           ne pas effacer le contenu existant du fichier de sortie
    -o --output          spécifier le nom du fichier de sortie, par défaut c'est out.xxx
    -q --quiet           ne pas afficher de messages d'erreur
    -V --version         afficher la version et la licence du logiciel

Vous pouvez utiliser le programme xres pour vérifier et gérer :

/> 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.
(...)

Bien, essayons ?

/> 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_VERSION

Plus sur les ressources et le format rdef vous pouvez lire davantage ici.

Types de ressources standards

Bien que vous puissiez mettre n'importe quoi dans les ressources, il existe plusieurs types standards spécifiques :

app_signature: type MIME de l'application, pour associer les fichiers à ouvrir, le démarrage, l'IPC, etc.
app_name_catalog_entry: Comme le nom de l'application est généralement en anglais, vous pouvez ici indiquer des emplacements où se trouvent les noms traduits, afin que les utilisateurs de différentes langues puissent voir le nom traduit de l'application s'ils le souhaitent.
app_version: exactement ce que vous pensez
app_flags: indique registrar : comment traiter l'application. Je pense qu'il y a plus que ce qu'il semble à première vue. Par exemple, il y a B_SINGLE_LAUNCH, qui oblige le système à lancer un nouveau processus de l'application à chaque fois, à la demande de l'utilisateur (le même principe est utilisé pour la plupart des applications sur Linux). Il y a B_MULTIPLE_LAUNCH, qui oblige à lancer un processus pour chaque fichier. Enfin, il y a B_EXCLUSIVE_LAUNCH, qui oblige le système à ne lancer qu'un seul processus à la fois, peu importe à quelle fréquence les utilisateurs le lancent (par exemple, c'est ainsi que Firefox se lance sur Linux ; le même résultat peut être obtenu dans les applications Qt, en utilisant la fonction QtSingleApplication). Les applications avec B_EXCLUSIVE_LAUNCH : sont notifiées lorsque l'utilisateur essaie de les relancer : par exemple, elles reçoivent le chemin du fichier que l'utilisateur souhaite ouvrir avec elles.
vector_icon: Icône vectorielle de l'application (Dans BeOS, il n'y avait pas d'icônes vectorielles, la plupart des applications avaient deux icônes bitmap dans les fichiers exécutables à la place).

Bien sûr, vous pouvez ajouter des ressources avec tous les ID et types souhaités, puis les lire dans l'application elle-même ou dans d'autres applications à l'aide de la classe BResources. Mais d'abord, arrêtons-nous sur le sujet passionnant des icônes.

Icônes vectorielles au style Haiku

Évidemment, ce n'est pas seulement Haiku qui a choisi le meilleur format d'icônes, la situation des environnements de bureau Linux est loin d'être idéale :

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.cache

En voyant tout ça, on peut déjà ressentir de quoi il s'agit.

Bien sûr, il existe des icônes vectorielles scalable. Mais pourquoi y a-t-il autre chose ? Parce que le rendu graphique des icônes vectorielles à petite échelle peut être inférieur à l'idéal. Nous aimerions avoir différentes versions, optimisées pour des tailles variées. Dans les environnements de travail Linux, cela est accompli en dispersant les icônes de différentes tailles dans le système de fichiers.

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.png

Notez qu'il n'y a pas de concept de différentes versions de Firefox. Par conséquent, il n'est pas possible de gérer délicatement la situation de la présence de plusieurs versions de l'application dans le système.

Différentes icônes de Firefox dans différentes versions. Pour l'instant, il est impossible de gérer cela sur Linux sans divers contournements.

Mac OS X gère cela de façon un peu plus raffinée :

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.icns

On voit qu'il y a un fichier firefox.icns dans le paquet Firefox.app, contenant toutes les tailles, de sorte que différentes versions d'une même application aient différentes icônes.
Beaucoup mieux ! Les icônes voyagent avec l'application, toutes les ressources sont dans un seul fichier.

Revenons à Haiku. Une solution époustouflante, sans exceptions. Selon documentation:

Un format HVIF a été spécialement conçu, hautement optimisé pour les petites tailles et des rendus rapides. Ainsi, nos icônes sont généralement bien plus petites que dans des formats raster ou le format SVG largement utilisé.

Et elles sont en effet optimisées :

Les tailles des icônes en HVIF comparées à d'autres formats.

La différence est d'un ordre de grandeur !

Mais la magie ne s'arrête pas là. Un même HVIF peut afficher différents niveaux de détail en fonction de la taille d'affichage, même si c'est un format vectoriel.

Différents niveaux de détail (LOD) en fonction de la taille de rendu

Maintenant, concernant les inconvénients : on ne peut pas prendre un SVG, l'envoyer dans ImageMagick et s'arrêter là, il faut passer par plusieurs cycles pour créer une icône au format HVIF. Ici d'explications. Cependant, IconOMatic peut importer de manière assez imparfaite les SVG ; environ 90 % des détails SVG sont importés avec une certaine probabilité, les 10 % restants devront être ajustés et modifiés manuellement. Lisez plus sur la façon dont HVIF opère sa magie est possible dans le blog Léa Genson

Ajout d'une icône à l'application

Maintenant, je peux ajouter une icône au paquet créé la dernière fois, en tenant compte de toutes les informations reçues.
Eh bien, comme je n'ai pas vraiment envie de dessiner ma propre icône pour mon « Bonjour, Monde » QtQuickApp en ce moment, je vais la prendre dans 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 Creator

Vérifions que l'icône a été copiée :

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

Ça a l'air bien, mais pourquoi, lorsque la nouvelle icône est copiée, elle ne s'affiche pas ?

L'icône VICN:101:BEOS:ICON kopieé n'est pas encore utilisée comme icône pour l'application dans le gestionnaire de fichiers.

Qu'est-ce que j'ai raté ?

Commentaire du développeur :

Il faut créer un fichier rdef avec toutes les ressources, puis exécuter la commande rc nom.rdef, cela créera le fichier .rsrc. Ensuite, il faut exécuter la commande resattr -o nom_binaire nom.rsrc. Au minimum, j'utilise des commandes similaires pour ajouter des icônes à mes scripts.

Eh bien, je voulais créer une ressource, pas un attribut. Je suis complètement confus.

Mise en cache intelligente utilisant le système de fichiers.

L'ouverture et la lecture des attributs ELF sont lentes. Comme je l'ai dit plus haut, l'icône est écrite en tant que ressource dans le fichier lui-même. Cette méthode est plus fiable, permettant de survivre à la copie vers un autre système de fichiers. Cependant, ensuite, elle est également copiée dans l'attribut du système de fichiers, par exemple BEOS:ICON. Cela ne fonctionne que sur certains systèmes de fichiers, par exemple BFS. Les icônes affichées par le système (dans Tracker et Deskbar) sont lues depuis cet attribut étendu, car cette solution fonctionne rapidement. À certains endroits (là où la vitesse n'est pas importante, par exemple la fenêtre « À propos »), le système obtient l'icône directement à partir de la ressource dans le fichier. Mais ce n'est pas encore fini. Rappelez-vous, sur Mac, les utilisateurs pouvaient remplacer les icônes des applications, des dossiers, des documents par les leurs, car Mac permet de faire ces « choses importantes », par exemple remplacer la nouvelle icône de Slack par l'ancienne. Sur Haiku, il est préférable de considérer la ressource (dans le fichier) comme l'icône d'origine fournie avec l'application, et l'attribut (dans le système de fichiers BFS) comme quelque chose permettant à l'utilisateur d'apporter des modifications si désiré (bien qu'une petite note, l'interface graphique pour insérer une icône personnalisée au-dessus de l'icône par défaut n'ait pas encore été réalisée).

Vérification des attributs du système de fichiers

Avec resaddr il est possible de vérifier et de définir les attributs du système de fichiers.

/> 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.
(...)

En essence, c'est une « colle » qui effectue une conversion bilatérale entre des ressources (fiables) et des attributs (rapides) du système de fichiers. Et puisque le système est censé récupérer les ressources et effectue la copie automatiquement, je ne vais pas m'en préoccuper davantage.

La magie des paquets hpkg

Actuellement, on utilise principalement des paquets pour obtenir des programmes sur Haiku. .hpkg. Ne vous laissez pas tromper par son nom simple : le format .hpkg fonctionne de manière entièrement différente des autres formats aux noms similaires que vous avez pu rencontrer, il possède de véritables super-pouvoirs.

Avec les formats de paquets traditionnels, j'ai longtemps été frustré par ce fait : vous téléchargez un (paquet), mais ce qui est installé sur le système est autre chose (fichiers à l'intérieur du paquet). Il est assez difficile de gérer les fichiers (par exemple, de les supprimer) lorsque l'on installe un paquet de la manière traditionnelle. Et tout cela parce que le contenu du paquet est dispersé à travers tout le système de fichiers,, y compris dans des endroits où l'utilisateur ordinaire peut ne pas avoir d'accès en écriture. Cela engendre toute une classe de programmes — gestionnaires de paquets.Et le transfert de logiciels déjà installés, par exemple, vers un autre ordinateur, un disque amovible ou un serveur de fichiers devient encore plus difficile, voire impossible. Dans un système basé sur Linux, il peut facilement y avoir de plusieurs centaines de milliers à des millions de fichiers isolés. Cela va sans dire, cela est à la fois fragile et lent, par exemple lors de l'installation initiale du système, ainsi que lors de l'installation, de la mise à jour et de la suppression de paquets traditionnels, et lors de la copie du volume de démarrage (partition racine) sur un autre support.

Je travaille sur le projet AppImage, une sorte de solution temporaire pour les applications destinées aux utilisateurs finaux. C'est un format de distribution de logiciels qui regroupe l'application et toutes ses dépendances dans une seule image de système de fichiers, montée lors du démarrage de l'application. Cela simplifie considérablement les choses, puisque le même ImageMagick se transforme soudainement en un seul fichier, géré dans le gestionnaire de fichiers par des mortels ordinaires. La méthode proposée ne fonctionne que pour les logiciels, comme le reflète le nom du projet, et présente également son propre ensemble de problèmes, car les personnes en charge de la distribution de logiciels pour Linux cherchent toujours à blâmer les autres.

Revenons à Haiku. Avez-vous réussi à trouver un équilibre optimal entre les systèmes de paquet traditionnels et la livraison de logiciels sous forme d'images ? Ses paquets .hpkg sont en fait des images de système de fichiers compressées. Lors du démarrage du système, le noyau monte tous les paquets installés et actifs avec des messages de noyau comme suit :

KERN: package_daemon [16042853:   924] paquet actif : "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] paquet actif : "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] paquet actif : "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] paquet actif : "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] paquet actif : "llvm_libs-5.0.0-3-x86_64.hpkg"

Impressionnant, n'est-ce pas ? Accrochez-vous, ça va devenir encore meilleur !

Il y a un paquet très spécial :

KERN: package_daemon [16040020:   924] paquet actif : "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

Il contient un système d'exploitation très minimaliste, y compris le noyau. Croyez-le ou non, mais même le noyau lui-même n'est pas extrait du volume de démarrage (partition racine), mais se charge soigneusement à sa place depuis le paquet .hpkg. Eh bien, dites donc ! J'ai déjà mentionné que, selon moi, une partie de l'élégance et de la cohérence de Haiku est due au fait que tout le système, du noyau et de l'environnement utilisateur de base à la gestion des paquets et à l'infrastructure de l'environnement de travail, est développé ensemble par une seule équipe. Imaginez combien de groupes et d'équipes différents il faudrait pour lancer quelque chose de similaire basé sur Linux. [je pense au projet PuppyLinux, — note du traducteur]. Ensuite, imaginez combien de temps il faudrait pour que cette approche soit mise en œuvre dans les distributions. On dit souvent : prenez une tâche simple, divisez-la entre différents exécutants, et elle deviendra tellement compliquée qu'elle ne pourra plus être résolue. Haiku m'a ouvert les yeux à ce sujet. Je pense que c'est exactement ce qui se passe sur Linux en ce moment (Linux étant ici un terme général pour désigner la pile Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Restauration du système à l'aide de hpkg

À quelle fréquence se présente la situation suivante : la mise à jour s'est bien passée, mais ensuite il s'avère que quelque chose ne fonctionne pas comme il le faudrait ? Lorsqu'on utilise des gestionnaires de paquets classiques, il est difficile de ramener l'état du système à un moment donné avant l'installation de nouveaux paquets (par exemple, en cas de problème). Certains systèmes offrent des solutions sous forme de snapshots du système de fichiers, mais elles sont assez encombrantes et ne s'appliquent pas à tous les systèmes. Dans Haiku, cela est résolu grâce aux paquets. .hpkg. Chaque fois que des paquets sont modifiés dans le système, les anciens paquets ne sont pas supprimés, mais sont conservés dans le système dans des sous-répertoires de type /Haiku/system/packages/administrative/state-<...>/ en permanence. Les opérations inachevées conservent leurs données dans des sous-répertoires /Haiku/system/packages/administrative/transaction-<...>/.

Contenu /Haiku/system/packages/administrative. Les répertoires « state… » contiennent des fichiers texte avec les noms des paquets actifs, « transaction… » — les paquets eux-mêmes.

L'« ancien état actif », c'est-à-dire la liste .hpkg des paquets actifs avant les modifications, est enregistré après chaque opération dans le gestionnaire de fichiers dans un fichier texte /Haiku/system/packages/administrative/state-<...>/activated-packages. De manière similaire, le nouvel « état actif » est écrit dans un fichier texte /Haiku/system/packages/administrative/activated-packages.

Le répertoire /Haiku/system/packages/administrative/state-<...>/ qui contient uniquement un fichier texte avec la liste des paquets actifs de cet état (en cas d'installation de paquets sans suppression), et si des paquets ont été supprimés ou mis à jour, le répertoire state contient les anciennes versions des paquets.

Au démarrage du système, une décision est prise sur l'activation (le montage) des paquets en fonction de la liste des paquets. C'est aussi simple que cela ! Si quelque chose ne va pas lors du démarrage, il est possible de demander au gestionnaire de démarrage d'utiliser une autre liste, plus ancienne. Problème résolu !

Le chargeur de démarrage Haiku. Chaque point d'entrée reflète le « état actif » correspondant

J'apprécie l'approche avec des fichiers texte simples en tant que liste de « état actif », contenant des noms faciles à comprendre .hpkg. Cela contraste fortement avec le tas créé-pour-les-machines-et-non-pour-les-humains de OSTree ou de Flatpak dans le système de fichiers (au même niveau que les GUID de Microsoft). La liste des paquets actifs pour chaque instant

Les données de configuration

Apparemment, dans le répertoire

se trouvent des fichiers de configuration pour les paquets, mais ceux-ci sont disponibles en écriture. Car, comme vous vous en souvenez, /Haiku/system/packages/administrative/writable-files ils sont montés uniquement en lecture. Ainsi, ces fichiers doivent être copiés à partir des paquets avant d'écrire. Cela a du sens. .hpkg Intégration de l'interface graphique pour le système .hpkg

Intégration GUI pour le système .hpkg

Voyons maintenant comment ces paquets brillants .hpkg s'intègrent dans l'environnement de travail utilisateur (UX). Après tout, Haiku est destiné à un usage personnel. Personnellement, j'ai mis la barre haute en comparant l'expérience utilisateur avec celle des paquets .app sur Macintosh avec la même expérience sur .hpkg. Je ne vais même pas comparer la situation avec les environnements de travail sur Linux, car elle est absolument horrible comparée à d'autres.

Les scénarios suivants me viennent à l'esprit :

Je veux voir le contenu du paquet .hpkg
Je veux installer le paquet
Je veux supprimer le paquet
Je veux supprimer quelque chose qui est arrivé dans le système dans le cadre du paquet
Je veux copier quelque chose qui est arrivé dans le système dans le cadre du paquet
Je veux télécharger toutes les dépendances du paquet qui ne peuvent pas faire partie de chaque installation de Haiku (par exemple, j'ai une machine physiquement isolée sans accès Internet).
Je veux déplacer mes paquets (ou une partie d'eux) séparément à un autre endroit, distinct du volume de démarrage (partition racine) (parce que, par exemple, je manque d'espace dessus).

Cela devrait couvrir la plupart des cas principaux de mon travail quotidien. Alors, commençons.

Vérification du contenu du paquet

Sur Mac je clique simplement avec le bouton droit sur le paquet pour l'ouvrir et voir son contenu dans Finder. Car en réalité, c'est simplement un répertoire déguisé ! (Je sais qu'il existe des paquets .pkg pour des parties du système qui ne sont pas des applications, mais les utilisateurs classiques n'interagissent généralement pas avec eux).

Sur Haiku je clique avec le bouton droit de la souris sur le paquet, puis clique sur « Contents » pour voir ce qu'il y a à l'intérieur. Mais ici, il n'y a qu'une liste de fichiers sans possibilité de les ouvrir en double-cliquant.
Il serait beaucoup mieux d'avoir un moyen (temporaire) de monter le paquet .hpkg pour l'afficher via le gestionnaire de fichiers, sans que l'utilisateur ait à se soucier des détails de mise en œuvre. (En passant, on peut ouvrir .hpkg le paquet dans Expander, qui peut le décompresser comme n'importe quelle autre archive).

Dans l'interface de HaikuDepot, on peut voir la liste des fichiers du paquet, mais il n'y a pas de moyen d'afficher le contenu, par exemple en double-cliquant sur README.md.

Dans cette catégorie, Mac l'emporte, mais l'ajout de la fonctionnalité nécessaire à HaikuDepot ne devrait pas poser de grandes difficultés.

Installation du paquet via l'interface graphique

Sur Mac, la plupart des images disque .dmg contiennent des paquets .app. Ouvrons l'image disque par un double-clic, puis copions le paquet, par exemple, en le faisant glisser dans /Applications Finder. Pour moi, c'est évident, mais j'ai entendu dire que certains débutants peuvent avoir du mal avec cela. Par défaut, Apple "propose" un répertoire système général /Applications (sur NeXT, il était à la fois réseau et individuel), mais on peut facilement placer ses applications sur un serveur de fichiers ou dans un sous-répertoire $HOME/Applications, si cela vous convient.

Sur Haiku, double-clic sur le paquet, puis clic sur "Installer", c'est simple comme bonjour. Je me demande ce qui se passe si le paquet a des dépendances disponibles dans HaikuPorts, mais encore non installées. Sous Linux, ils ne savent vraiment pas quoi faire dans cette situation, mais la solution est évidente — demander à l'utilisateur s'il faut télécharger et installer les dépendances. C'est exactement ce que fait Haiku.

J'ai téléchargé le paquet 'sanity' manuellement et j'ai cliqué dessus, le gestionnaire de paquets sait d'où prendre ses dépendances (à condition que les dépôts soient déjà listés dans le système). Tous les distributions Linux ne peuvent pas faire cela.

Une autre méthode consiste à utiliser le gestionnaire de fichiers, il suffit de faire glisser .hpkg le paquet soit dans /Haiku/system/packages (pour une installation système générale, par défaut), ou dans /Haiku/home/config/packages (pour une installation individuelle ; pas disponible par double-clic — le mot "config" me gêne encore à cet endroit, qui pour moi est synonyme de "paramètres"). Et la notion de plusieurs utilisateurs n'est même pas encore disponible sur Haiku (c'est probablement pour ça que tout est si simple — je ne sais pas, peut-être que les capacités multi-utilisateurs compliquent trop les choses pour un environnement de bureau sur un ordinateur personnel).

Dans cette catégorie, Haiku l'emporte, car il peut gérer non seulement des applications, mais aussi des programmes système.

Supprimer un paquet via l'interface graphique

Sur Mac, il suffit de faire glisser l'icône de l'application dans la corbeille, et c'est tout. Facile !

Sur Haiku, tout d'abord, il faut trouver où se situe le paquet dans le système, car vous ne l'installerez que rarement où il faut (tout est fait par le système). En général, il faut chercher dans /Haiku/system/packages (pour une installation système générale par défaut), ou dans /Haiku/home/config/packages (ai-je déjà dit que "config" est un mauvais nom ?). Ensuite, l'application est simplement glissée dans la corbeille, et c'est tout.
Facile ! Cependant, je ne dirais pas cela. Voici ce qui se passe en réalité :

Voici ce qui se passe si vous faites glisser une application dans la corbeille depuis /Haiku/system/packages

J'ai juste essayé de déplacer mon application d'hier « Bonjour, monde » sur QtQuickApp vers la corbeille. Je n'ai pas essayé de déplacer le répertoire système, et comme tous les paquets s'installent dans le répertoire système, il est impossible de supprimer un paquet .hpkg sans modifier « son contenu ». Un utilisateur normal aurait eu peur, aurait cliqué sur le bouton « Annuler » par défaut.

Explique mr. waddlesplash:

Ce message a plus de 10 ans. Il est probable que nous devions le configurer de sorte que l'avertissement apparaisse uniquement lors du déplacement du paquet lui-même. De toute façon, les utilisateurs normaux n'ont pas besoin de faire cela.

Bien, peut-être devrions-nous le faire en utilisant HaikuDepot ? Je double-clique sur le paquet dans /Haiku/system/packages, en espérant que le bouton « Désinstaller » apparaîtra. Non, il y a (seulement) « Installer ». « Désinstaller », où es-tu ?

Pour le plaisir, j'ai essayé de voir ce qui se passerait si je cliquais sur « Installer » pour un paquet déjà installé. Cela donne :

Voilà ce qui se passe si vous essayez d'installer un paquet déjà installé.

Ensuite, il apparaît :

Si vous cliquez sur « Appliquer les changements » dans la fenêtre précédente, cela donnera

Je suppose qu'il s'agit d'un bug, il y a déjà un lien vers un ticket. [l'auteur n'a pas fourni de lien, — note du traducteur]

Solution rapide : Ajouter un bouton « Désinstaller » si le paquet est déjà présent dans /Haiku/system/packages, ou dans /Haiku/home/config/packages.

En consultant la liste des paquets installés dans HaikuDepot, je vois mon paquet dans la liste et je peux le supprimer.

Dans cette catégorie, Mac l'emporte. Mais je peux imaginer qu'avec les bonnes configurations, l'expérience utilisateur sur Haiku pourrait être mieux que sur Mac. (Un des développeurs a évalué cela ainsi : « Moins d'une heure pour ajouter la fonctionnalité mentionnée dans HaikuDepot, si vous connaissez un peu le C++ », y a-t-il des volontaires ?)

Supprimer quelque chose du paquet

Essayons de supprimer l'application elle-même, et non le paquet .hpkg, à partir duquel elle est apparue (je doute qu'il y ait une quelconque différence pour les « simples mortels »).

Sur Mac, l'utilisateur travaille généralement avec le fichier .dmg, dont provient le paquet de l'application .app. En général, les images .dmg s'accumulent dans le répertoire de téléchargements, tandis que les paquets sont copiés par l'utilisateur dans /Applications. Il existe une opinion selon laquelle de nombreux utilisateurs ne savent pas ce qu'ils font, cette hypothèse est corroborée par un ancien employé d'Apple. (Une des choses que je n'aime pas sur Mac. Par exemple, avec AppImage, il n'y a pas de différence entre l'application et le paquet dans lequel elle se trouve. J'ai fait glisser l'icône dans la corbeille = c'est tout. Facile!)

Sur Haiku, il existe également une séparation entre applications/ et paquets/, donc je doute que ce soit plus clair pour les utilisateurs. Voici ce qui se passe si vous faites glisser l'application de applications/ dans la corbeille :

Voici ce qui arrive lorsque vous essayez de supprimer une application provenant d'un fichier .hpkg

Techniquement, c'est correct (puisque l'application est dans un système de fichiers en lecture seule, en premier lieu), mais cela n'est pas très utile pour l'utilisateur.

Solution rapide : proposer plutôt de supprimer via l'interface graphique .hpkg

Pour rire, j'ai essayé de dupliquer l'application en appuyant sur Alt+D. J'ai reçu le message « Impossible de déplacer ou de copier des objets sur un volume en lecture seule ». Tout cela parce que /system en plus de /system/packages et /system/settings) est un point de montage de packagefs (souvenez-vous comment il apparaît dans la sortie df?). К сожалению, вывод команды mount ne clarifie pas la situation (comme cela a été dit dans un des précédents articles), mountvolume ne montre pas ce que je cherche (manifestement, les paquets montés via loop .hpkg ne sont pas considérés comme des « volumes »), et j'ai également oublié les commandes alternatives.

Dans cette catégorie, personne n'a gagné, sauf AppImage (mais pour être totalement honnête, c'est un avis biaisé). Cependant, on peut imaginer qu'après ajustement, l'expérience utilisateur sur Haiku sera meilleure que sur Mac.

Remarque : il faut déterminer ce qu'est un « volume » par rapport à « section ». Cela ressemble probablement à une relation entre « dossier » et « répertoire » : la plupart des répertoires apparaissent dans le gestionnaire de fichiers sous forme de dossiers, mais pas tous (par exemple, les paquets, traités comme des fichiers). De telles conclusions font de moi un nerd aux yeux officiels ?

Copier le contenu d'un paquet sur un autre système

Sur Mac, je fais simplement glisser le paquet .app, et puisque les dépendances à l'intérieur du paquet se déplacent avec lui.

Sur Haiku, je fais glisser l'application, mais les dépendances ne sont pas du tout traitées.

Solution rapide : il serait préférable de proposer de faire glisser le paquet « `.hpkg » dans son intégralité, avec ses dépendances, le cas échéant.

Dans cette catégorie, Mac l'emporte indéniablement. Du moins pour moi, un amateur de leur paradigme. Haiku devrait s'inspirer. .hpkg au lieu de l'application, mais le système ne me propose pas cela…

Téléchargement du package avec toutes ses dépendances

Toutes les machines ne sont pas toujours connectées à Internet. Au contraire, certaines machines (oui, je pense à vous, Windows, Mac et Linux modernes) oublient cela. Pour moi, il est important de pouvoir aller, par exemple, dans un café Internet, télécharger des logiciels sur un support amovible, insérer ce support dans mon ordinateur à domicile et être sûr que tout fonctionnera [un gars à risque, tenter cela sur Windows… — note du traducteur].

En conséquence, un peu plus souvent qu'à l'accoutumée, je rencontre généralement des dépendances non satisfaites sur Windows et Linux.

Sur Mac c'est généralement un seul fichier, tout ce qu'il faut — c'est de télécharger .dmg. La plupart du temps, il n'a pas de dépendances, sauf celles fournies par MacOS par défaut. En revanche, des applications complexes nécessitant un environnement d'exécution approprié, comme Java, peuvent être une exception.

Sur Haiku télécharger le package .hpkg pour, disons, la même application Java, cela peut être insuffisant, car Java peut être présent ou absent sur la machine cible. Y a-t-il un moyen de télécharger toutes les dépendances pour ce package .hpkg, sauf celles qui sont installées par défaut dans Haiku et qui doivent donc être présentes sur chaque système Haiku ?

Dans cette catégorie, Mac l'emporte avec une légère avance.

Commente mr. waddlesplash :

Pour écrire un programme visant à rassembler toutes les dépendances d'une application sous forme de paquetages .hpkg pour quelqu'un qui connaît le fonctionnement interne de Haiku, cela prend environ 15 minutes. Ajouter ce support n'est pas si compliqué que cela, s'il y a un réel besoin. Mais pour moi, c'est une situation rare.

Retenons notre souffle jusqu'à l'article suivant de ce cycle.

Déplacement des paquets dans un endroit séparé

Comme je l'ai déjà mentionné, je veux placer mes paquets .hpkg (ou une partie d'entre eux) dans un endroit spécial, éloigné de l'emplacement habituel sur le volume de démarrage (la partition racine). En général (ce n'est pas totalement théorique), la raison en est que je manque constamment d'espace libre sur mes disques (internes), peu importe combien ils sont grands. Et j'accroche généralement des disques externes ou des ressources réseau, où se trouvent mes applications.

Sur Mac je déplace simplement les paquets .app sur un disque amovible ou un répertoire réseau dans le Finder, et c'est tout. Je peux toujours ouvrir l'application par double-clic comme je le faisais auparavant avec le volume de démarrage. C'est simple !

Sur Haiku, comme on me l'a dit, cela peut être accompli en déplaçant mes .hpkg paquets sur un disque amovible ou un répertoire réseau, mais ensuite, il faut utiliser certaines commandes non documentées dans le terminal pour les monter dans le système. Je ne sais pas comment faire cela en utilisant uniquement l'interface graphique.

Dans cette catégorie, c'est Mac qui l'emporte.

Selon Mr. waddlesplash :

Il s'agit d'optimisation pour une utilisation normale. S'il y a plus de demande qu'un seul utilisateur, nous le mettrons en œuvre. De toute façon, il existe une option pour une mise en œuvre tierce.

Nous en parlerons dans le prochain article.

En ce qui concerne les répertoires réseau : ce serait formidable (je suppose en LAN party) d'avoir des applications réseau simples et détectables (par exemple via Zeroconf), que l'on peut copier sur l'ordinateur local ou lancer directement depuis le réseau local. Bien sûr, les développeurs ont la possibilité de refuser via app_flags.

Le rapport final sur l'intégration du système hpkg avec l'interface graphique

Je pense qu'en raison de la relative nouveauté, l'intégration .hpkg avec l'interface graphique laisse encore à désirer. En tout cas, il y a plusieurs choses qui peuvent être améliorées en termes d'expérience utilisateur…

Une autre chose : Kernel Debug Land

Ce serait génial d'avoir la possibilité d'entrer des commandes lors d'un kernel panic, par exemple syslog | grep usb. Eh bien, sur Haiku, c'est possible grâce à Kernel Debug Land. Comment voir cette magie en action si tout fonctionne comme prévu sans passer par un kernel panic ? Facile, en appuyant sur Alt+PrintScn+D (mnémotechnique Debug). Je me souviens immédiatement de la touche Programmeur, qui permettait aux développeurs originaux de Macintosh d'entrer dans le débogueur (s'il était installé, bien sûr).

Conclusion

Je commence à comprendre que la sophistication du système Haiku vient du fait qu'il est développé par une petite équipe avec une orientation claire sur l'environnement de travail tout en ayant accès à tous les niveaux du système.
Cela contraste fortement avec le monde de Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, où tout est fragmenté en si petits morceaux que l'abstraction repose sur l'abstraction, soutenue par des béquilles.
Il est également devenu clair comment le système .hpkg combine les meilleures pratiques des gestionnaires de paquets traditionnels, Snappy, Flatpak, AppImage, même btrfs, et les mélange avec le principe du « ça fonctionne simplement » de Mac.

Comme si quelque chose s'était « basculé » dans ma tête, et j'ai compris comment le système .hpkg sait revenir en arrière, simplement en le regardant. Mais ce n'est pas moi, c'est la beauté et la simplicité du système. Beaucoup de choses ici sont empreintes de l'esprit du Mac originel.

Oui, naviguer sur les pages dans le navigateur peut être saccadé et fonctionner comme une limace, il peut manquer d'applications (pas de Gtk, Electron — les développeurs ont conclu qu'elles ne s'harmonisaient pas avec la subtilité), l'accélération vidéo et 3D peut même faire défaut, mais j'apprécie quand même ce système. Car ces choses peuvent être corrigées et apparaîtront tôt ou tard. C'est juste une question de temps et, peut-être, un peu de fatigue oculaire.

Je ne peux pas offrir d'aide, mais je pense que c'est à partir de ce moment que commencera l'année Haiku sur le bureau.

Problèmes aléatoires

Y a-t-il déjà des demandes, ou dois-je en ouvrir ?

BeScreenCapture devrait avoir la possibilité d'exporter en GIF, comme dans Peek. Cela peut être réalisé avec ffmpeg, déjà disponible pour Haiku. Demande.
Le programme de capture d'écran ne peut pas capturer une fenêtre modale, prenant plutôt l'ensemble de l'écran
On ne peut pas rogner les captures d'écran avec l'outil de rognage dans WonderBrush, puis sauvegarder le résultat dans un fichier
Je n'aime pas particulièrement le curseur en forme de main dans Haiku, mais je pense que cela est lié à des sentiments nostalgiques. Cela devient particulièrement irritant lors de l'utilisation de l'outil de rognage dans Krita, car cela donne un rognage imprécis (voir les captures d'écran avec les dialogues modaux dans cet article). Un curseur en forme de croix serait merveilleux. Demande.

Essayez par vous-même ! En effet, le projet Haiku fournit des images à télécharger sur DVD ou USB, générées quotidiennement. Pour l'installation, il suffit de télécharger l'image et de l'écrire sur une clé USB à l'aide de Etcher

Vous avez des questions ? Nous vous invitons sur notre canal Telegram en russe.

Revue des erreurs : Comment se tirer une balle dans le pied en C et C++. Recueil de recettes Haiku OS

De l'auteur traduction : c'est le sixième article d'une série sur Haiku.

Liste des articles : Premier Deuxième Troisième Quatrième Cinquième

Source : habr.com