Il est temps de s'intéresser à nouveau aux nouveautés de Haiku pour ce dernier trimestre.

Les gros changements sont:

• Un nouvel allocateur mémoire qui permet enfin d'allouer plus de 3GiB par application (un reste de l'historique de Haiku sur les systèmes 32 bits), tout en étant plus rapide et moins gourmand en mémoire,
• Des raccourcis claviers sans touches modificatrices,
• De grosses mises à jour dans la bibliothèque C,
• La poursuite du nettoyage de code et de l'optimisation du navigateur de fichiers Tracker,
• La reprise du travail sur le pilote NFS4 pour les systèmes de fichiers en réseau,
• Et bien sûr, de très nombreuses corrections de bugs et petites améliorations un peu partout dans le système.

Sommaire

• Google Summer of Code
• Applications
  • Tracker
  • MediaPlayer
  • WebPositive
  • HaikuDepot
  • ProcessController
  • Terminal
  • StyledEdit
  • Screenshot
  • Préférences
  • Outils en ligne de commande
• Kits
  • Interface Kit
  • Support Kit
  • Storage Kit
• Serveurs
  • input server
  • screen blanker
  • launch daemon
  • app server
• Pilotes
• Systèmes de fichiers
• libroot
  • Bibliothèque C standard
  • Gestion de la mémoire
  • Autres changements
• Noyau
  • Bootloader
• Scripts de compilation
• Documentation

Google Summer of Code

Le Google Summer of Code est un programme organisé par Google pour encourager de nouveaux développeurs à se lancer dans la contribution aux logiciels libres. Il prend la forme d'un stage, où un projet de logiciel libre fournit un sujet et une équipe d'encadrement, et Google se charge de financer le nouveau contributeur pour quelques semaines.

Cette année, la candidature de Haiku a été rejetée, la préférence étant donnée à des projets engagés dans l'intelligence artificielle et dans la cybersécurité (deux domaines beaucoup demandés par les personnes souhaitant participer au programme). Ce n'est finalement peut-être pas une mauvaise chose pour Haiku: les développeurs d'autres projets se sont plaints d'avoir reçu des centaines de candidatures visiblement générées par des LLM sans aucun travail de préparation, ce qui leur demande donc beaucoup de temps pour faire le tri dans les candidatures. Les développeurs de Haiku vont cette année pouvoir se consacrer à d'autres tâches.

Applications

Tracker

Le travail de refonte du Tracker se poursuit. Les changements intégrés en début d'année ont provoqué un certain nombre de régressions qui sont corrigées petit à petit:

• Il est à nouveau possible d'ouvrir le dossier contenant un résultat de requête en double cliquant la colonne "emplacement" dans les résultats.
• Correction d'un crash et de problèmes de gestion de la mémoire et de problèmes de synchronisation entre threads.
• Ré-optimisation de la gestion des menus dynamiques pour éviter de les reconstruire à chaque clic de souris, mise en cache de certaines parties du menu dont la construction nécessite des accès disque (liste de patrons pour le menu "nouveau document", liste d'add-ons)

Toujours beaucoup de nettoyage de code à faire dans le Tracker:

• correction de dimensions en dur dans les menus spéciaux du Tracker,
• nettoyage du glisser-déposer,
• refactorisation de la logique de dessin,
• amélioraiton du chargement des add-ons,

Optimisation de la méthode de surveillance des dossiers, utilisation d'un "node monitor" (équivalent de inotify sous Linux) récursif pour surveiller un dossier et tous ses sous-dossiers au lieu de créer un monitor pour chaque dossier. Cela a nécessité des changements au niveau du noyau avec l'ajout du flag B_QUERY_WATCH_ALL pour couvrir ce cas d'usage.

Par jscipione, waddlesplash

MediaPlayer

L'infobulle sur le "scrubber" (barre de navigation temporelle dans le fichier) s'affiche dès que la souris est au-dessus de la barre. Elle contient le marqueur de temps correspondant à la position de la souris, permettant de naviguer avec précision dans le fichier. Ceci a nécessité des évolutions dans BToolTip, la classe responsable des infobulles, qui n'était pas prévue pour faire des infobulles persistantes poursuivant le déplacement de la souris.

Ajout d'une option pour afficher une vidéo à 25% de sa taille originale (les contenus en 4K ou plus se faisant plus courants).

Par AkashKumar7902, x512, waddlesplash

WebPositive

WebPositive ne prétend plus savoir traiter les liens utilsant le protocole gopher. Ces liens ne fonctionnaient plus depuis le retour à l'utilisation de cURL pour la couche réseau de WebKit au lieu d'essayer de réimplémenter un client HTTP maison.

Amélioration de la gestion des sessions : sauvegarde du workspace utilisé pour chaque fenêtre, restauration de la session complète lorsque le navigateur est démarré en cliquant sur un lien, avec ouverture du lien dans une fenêtre du workspace courant s'il y en a déjà une, et dans une nouvelle fenêtre sinon.

Par nephele, ilzu

HaikuDepot

Amélioration de performances, en particulier lors de l'affichage des résultats de recherche, qui étaient très très lents sur les machines un peu anciennes.

Par apl, oco, waddlesplash

ProcessController

Affichage de "system resources" avant "caches" afin de rendre les statistiques d'utilisation mémoire plus claires et plus lisibles.

Correction de problèmes dans la mesure d'utilisation de resources par le noyau.

Par OscarL, waddlesplash

Terminal

Correction d'un bug d'initialisation de la couleur du curseur, visible principalement lorsque le terminal est utilisé comme réplicant dans une autre application. Cette possibilité est utilisée dans l'IDE Genio par exemple.

Par jackburton

StyledEdit

Interdiction d'entrer des caractères de contrôle ASCII dans un fichier texte (via les raccourcis clavier control+une lettre).

Par OscarL

Screenshot

Ajout de la possibilité de sélectionner un rectangle à capturer (en plus des possibilités existantes de capturer tout l'écran ou la fenêtre active).

Préférences

Nettoyage de code inutile dans les préférences d'affichage

Amélioration de la gestion des erreurs dans les préférences de sons si le dossier où devraient se trouver les fichiers son n'existe pas.

Par captain0xff, humdinger

Outils en ligne de commande

strace: Décodage des arguments passés à rlimit ainsi que de l'argument "type" pour mmap, affichage correct des valeurs de type ssize_t ne pouvant pas être représentées sur 32 bits.

Fusion des outils query et filteredquery. Ces deux outils permettent de rechercher des fichiers à partir de leurs attributs (xattrs) qui sont indexés par le système de fichier. Cette méthode de recherche retourne tous les résultats, le filtrage pour limiter à certains dossiers doit donc être fait par l'outil après avoir récupéré les résultats de la recherche. Cette fonction étant très utile, il n'y a pas de raison de l'implémenter comme un outil séparé.

keymap: l'option -h affiche l'aide, en conformité avec les bonnes pratiques d'interface utilisateur. L'option pour afficher un header est donc réaffectée et devient -H.

leakanalyzer (outil d'analyse des fuites mémoire): ignore la mémoire allouée en interne par le "locale kit" pour le support des locales dans la librairie C, cette mémoire ne peut pas être libérée.

listusb: correction de l'alignement vertical du statut des ports qui n'était pas en face des autres informations affichées.

waitfor (petite application permettant d'attendre différents évènements, très utile dans certains scripts) peut maintenant attendre la disponibilité d'une connexion réseau.

Par humdinger, jmairboeck, korli, OscarL, waddlesplash

Kits

Interface Kit

Les raccourcis claviers pour les menus peuvent maintenant ne pas utiliser la touche "Commande" du clavier. Cela permet de définir des raccourcis sans touches modificatrices ou avec des touches non-standard. L'utilisation de ce type de raccourcis est relativement rare, mais nécessaire dans quelques cas particuliers. Par exemple, la touche "Supprimer" peut être utilisée pour supprimer un fichier ou un élément de liste de lecture, la touche "F2" pour renommer un fichier dans le Tracker, …

Correction de la gestion des raccourcis claviers dans BPopUpMenu qui pouvaient être associés à la mauvaise fenêtre.

Amélioration du mode sombre: meilleure méthode de choix de la couleur de fond dans BTextView, utilisation d'une combinaison de couleurs cohérentes pour les boutons des barres de défilement.

Ajout de définitions et de documentation pour tous les côdes de contrôle ASCII dans InterfaceDefs.h. Certains d'entre eux n'étaient pas documentés, ce qui pouvait laisser penser qu'il restait de la place libre utilisable pour coder d'autres choses.

Ajout de vérifications dans BMenuField::SetLabel pour traiter correctement les labels NULL.

Optimisations de BScrollView et BColumnListView pour limiter les rafraîchissements inutiles de l'affichage (dans le cadre des améliorations de performances pour HaikuDepot). Dans BColumnListView, ajout d'APIs pour ajouter et supprimer un ensemble d'éléments d'un seul coup, ce qui est beaucoup plus rapide que de les traiter un par un.

Meilleure gestion du sémaphore de synchronisation des menus dans BWindow. Tous les menus dans Haiku sont implémentés comme des fenêtres, ce qui signifie que chaque menu s'exécute dans un thread dédié avec sa propre boucle d'évènements. La synchronisation peut donc être particulièrement complexe.

Correction d'un use-after-free (utilisation de mémoire libérée qui ne devrait logiquement plus être accédée) dans BSlider.

BDecimalSpinner (un contrôle pour changer une valeur numérique au clavier ou avec des boutons '+' et '-') utilise BNumberFormat et affiche donc le nombre en fonction des préférences de localisation.

Par apl, bitigchi, jscipione, korli, nipos, nephele, PulkoMandy, waddlesplash, x512

Support Kit

Modification de BObjectList pour passer l'argument "owning" en paramètre de template plutôt qu'en paramètre du constructeur. Cela améliore les résultats d'analyse statique qui détectaient de nombreux faux positifs "double free" ou "use after free", et rend également plus difficile de faire des erreurs sur la gestion de la mémoire avec ces listes.

Certaines utilisations de BObjectList<BString> ont été remplacées par la classe dédiée BStringList, plus simple à utiliser pour ce cas particulier.

Amélioration de performances dans BList, BMessage et certaines parties du code les utilisant beaucoup pour réduire la quantité d'allocations mémoire dynamiques, en utilisant la pile comme stockage temporaire ou simplement en retardant au maximum les allocations. Par exemple, plutôt que de pré-allouer de la mémoire pour une liste dès la création de cette dernière, on attend l'insertion du premier élément dans la liste. On élimine ainsi des allocations dans les cas où du code crée une liste, mais n'insère finalement jamais rien dedans.

Amélioration des erreurs remontées par les classes de traitement de fichiers JSON.

Ajout de vérifications de pointeurs NULL manquantes dans BString pour corriger des crashs quand il n'y a plus de mémoire et qu'une allocation échoue.

Par ilzu, waddlesplash

Storage Kit

Amélioration de BFilePanel pour mieux réagir lorsque le dossier de destination n'existe pas.

Inhibition de BBlockCache lors de l'utilisation d'un allocateur mémoire de debug ou avec des gardes pour détecter les mauvaises utilisations mémoire. Dans ce cas, il vaut mieux se dispenser des gains de performance de la mise en cache mais détecter correctement l'utilisation de mémoire après sa remise à disposition dans le cache.

Ajout d'un type MIME pour les BMessage serialisés sur disque (souvent utilisés pour sauvegarder les préférences d'applications par exemple).

Par augiedoggie, nephele, waddlesplash

Serveurs

input server

Amélioration du clavier virtuel pour se mettre à jour automatiquement lors des changements de résolution d'écran et de disposition du clavier. Ce clavier virtuel n'est pas inclus par défaut dans l'installation de Haiku, il est réservé aux personnes aventureuses qui utilisent Haiku sur une tablette ou qui débugguent un pilote de clavier en ne disposant que d'un écran tactile comme périphérique d'entrée.

Correction du traitement des appels systèmes interrompus (SIGINT), ce qui permet à input server de s'arrêter (et de se redémarrer) lorsqu'on le lui demande. Cela est principalement utile pour tester les pilotes de périphériques d'entrée.

screen blanker

L'écran de veille utilise le mot de passe "système" (configuré dans /etc/passwd) au lieu d'implémenter son propre système de mot de passe. La commande screen_blanker permet de lancer l'écran de veille immédiatement, et peut être configurée comme un raccourci clavier pour implémenter un verrouillage simple de la session (note: ne faites pas confiance à l'écran de veille pour sécuriser votre session, actuellement il est assez facile à contourner par exemple à l'aide du debugger noyau).

launch daemon

Améliorations sur le launch_daemon: correction du traitement des conditions échouées pour lancer un service, ajout de la possibilité de définir une condition sur le contenu d'un fichier au format "driver settings" (format similaire aux fichiers ini) en plus des fichiers BMessage (format binaire), correction de l'arrêt des services.

app server

Remise en route du test_app_server (outil de test permettant de lancer un deuxième app_server dans une fenêtre, et donc de tester des changements sur le serveur graphique sans avoir besoin de redémarrer tout le système).

Correction de bugs dans app_server pour l'affichage de texte: retrait de code dupliqué, ajout de nouveaux cas de test, meilleure gestion du clipping et des "bounding boxes" des glyphes, correction de problèmes sur les lignes de "décoration" (texte souligné, barré) utilisées en combinaison avec une transformation (rotation, déformation).

Par augiedoggie, korli, nipos, madmax

Pilotes

Le pilote i2c prend en charge les plateformes AMD en plus des machines PCH Intel. Le module i2c utilisé (conçu par Designware) est le même pour les deux fabricants à quelques petits détails près.

Amélioration de la détection du pointeur racine ACPI: ce pointeur était fourni par le bootloader sur les machines EFI, mais détecté par l'OS après démarrage sur les machines BIOS. C'est désormais la seule responsabilité du bootloader dans les deux cas, ce qui simplifie le code.

Correction d'un crash sur certaines machines dans le pilote des batteries ACPI.

Ajout de vérifications supplémentaires et corrections du traitement de quelques cas particuliers dans la pile XHCI (USB3).

La gestion des "révisions" des périphériques virtio a été mise en conformité avec la spécification virtio. Pour les anciennes versions de virtio, ce champ de la configuration PCI indiquait la version du protocole virtio à utiliser. Mais cela implique qu'un seul pilote virtio (identifiant les périphériques par leur ID PCI uniquement) doit implémenter toutes les versions de virtio. Pour les nouvelles spécifications, ce sera donc le "device ID" qui va changer, et il sera beaucoup plus simple de développer des pilotes spécifiques "virtio v1", "virtio v2", etc pour chaque version majeure.

Mise à jour des pilotes wifi iaxwifi200 (nommé iwx chez BSD) et ethernet atheros813x pour supporter de nouvelles générations de matériel. Import du nouveau pilote FreeBSD pour les cartes MT7601U, mais il n'y a pas encore de confirmation de son bon fonctionnement sous Haiku.

Nettoyage de code dans les pilotes SCSI et ralinkwifi.

Dans le pilote NVMe, activation de l'option de mise en veille automatique qui permet de réduire la consommation électrique lorsque le disque n'est pas sollicité (réduction de 1W constatée sur certaines machines).

Correction de problèmes dans les pilotes d'entrée (clavier, souris) qui empêchent de redémarrer l'input_server et de retrouver l'usage de ces périphériques.

Ajout de la tablette graphique Cintiq13HD dans le pilote Wacom.

Correction du pilote framebuffer pour ne mapper en mémoire que la zone utilisée pour le framebuffer, et pas toute la mémoire de la carte graphique. Non seulement cela réduit la consommation mémoire reportée, mais surtout, le reste de la mémoire peut ainsi être configuré pour autre chose (par exemple, de l'accélération 3D).

Ajout des cartes Polaris 10 et correction de quelques erreurs de versions du chipset pour d'autres cartes dans le pilote Radeon HD. Ces cartes récentes sont toujours désactivées dans le pilote, le support reste expérimental et peut conduire à un écran noir. Il vaut mieux donc utiliser les pilotes VESA ou framebuffer pour l'instant.

Par ilzu, korli, Lt-Henry, waddlesplash

Systèmes de fichiers

Poursuite d'investigations pour améliorer le temps d'exécution de "git status" qui est anormalement lent par rapport à la même opération sous Linux. Amélioration de l'itération sur les arbres B+ dans BFS, qui faisaient plusieurs "get" et "put" du même bloc disque successif (les opérations "get" et "put" permettent d'obtenir l'accès exclusif à un bloc disque, puis de le libérer, le cache de blocs se chargeant de lire les blocs depuis le disque, puis de les réécrire lorsque c'est nécessaire).

Amélioration également des verrous de parallélisme dans BFS, ce qui devrait corriger quelques kernel panic.

Correction d'un blocage de ramfs lors de l'utilisation de "trim" pour libérer de la mémoire.

Ajout d'un contrôle du flag O_DIRECTORY dans plusieurs systèmes de fichiers lors de l'ouverture d'un fichier. En particulier cela permet d'écrire une image disque sur un disque à l'aide de la commande cp fichier.image /dev/disk/.../raw.

Plusieurs corrections sur le pilote NFS4 qui était délaissé depuis quelque temps: gestion des inodes "périmés" (fichier présent dans un cache local, mais supprimé par une autre machine sur le serveur), et correction d'autres problèmes rendant le pilote instable. Ajout également de divers outils de debug pour investiguer l'état du pilote.

Le serveur userlandfs peut être lancé plusieurs fois (B_MULTIPLE_LAUNCH), ce qui permet d'utiliser plusieurs systèmes de fichiers FUSE ou userlandfs en même temps.

Par augiedoggie, Jim906, waddlesplash, x512

libroot

Bibliothèque C standard

dlsym(RTLD_NEXT) et d'autres fonctions similaires du runtime_loader recherchent maintenant les symboles dans toutes les régions ELF chargées, et pas seulement dans la première.

Ajout de RTLD_NOLOAD dans la fonction dlopen, ce qui permet d'accéder à des symboles déjà présents dans l'exécutable sans charger un fichier de librairie à nouveau. Il ne s'agit pas d'une fonction standard C ou POSIX, mais d'une extension proposée par GNU et la glibc.

Ajout de la fonction getloadavg qui permet d'obtenir une mesure de la charge du système. Cela peut être simplement informatif (dans des outils comme htop) ou utilisé pour allouer au mieux les ressources CPU (l'outil de build ninja peut par exemple utiliser cette valeur pour décider combien de jobs lancer en parallèle)

Mise en conformité de l'ordre d'appel des destructeurs de pthread_key (il faut potentiellement appeler les destructeurs plusieurs fois, jusqu'à PTHREAD_DESTRUCTOR_ITERATIONS, pour contourner les problèmes d'interdépendances). Correction de l'ordre d'appel des destructeurs lors de l'arrêt d'une application: les destructeurs globaux C++ doivent être appelés avant les destructeurs de threads (il existe plusieurs méthodes pour enregistrer des fonctions à exécuter à l'arrêt d'un thread ou d'un programme, et c'est assez compliqué de toutes les séquencer correctement).

Une petite optimisation de pthread_cond_signal pour éviter un appel système dans certains cas.

Poursuite du remplacement de fonctions de la libroot par les versions provenant de musl: memmove, strlen, strlcat, ainsi que toutes les fonctions de conversions entre chaînes de caractères et nombres flottants.

Synchronisation de l'implémentation de glob avec FreeBSD.

Optimisation de la famille de fonctions memcmp, strcmp, strncmp: utilisation de comparaisons sur 64 bits lorsque c'est pertinent, retrait de calculs inutiles.

Réécriture et optimisation des fonctions génériques memcpy et memset (utilisées pour les machines qui n'ont pas une version optimisée manuellement en assembleur). Utilisation de la version optimisée de NetBSD pour les machines x86 32 bits. Pour la version 64 bits, le code utilisé par Haiku est meilleur que celui des autres systèmes, et reste donc en place. Le bootloader utilise uniquement la version générique pour simplifier les choses (il n'a pas besoin de fonctions de très haute performance).

Correction de la fonction write() avec une taille supèrieure à 2Gio sur les systèmes 64 bits (la taille était accidentellement tronquée à 32 bits).

Mise en conformité POSIX de la fonction dup3: retour de EINVAL si l'ancien et le nouveau descripteur de fichier sont identiques.

Déplacement de la fonction qsort_r de la libgnu vers la libroot (elle a été standardisée dans POSIX Issue 8). Il s'agit d'une version de qsort permettant de passer un paramètre supplémentaire à la fonction de comparaison contenant un contexte réservé à l'utilisateur de la fonction.

Nettoyage du code restant dans la libroot qui provient de la glibc: retrait de déclarations internes présentes dans les en-têtes publics, retrait de fonctions qui ont déjà été remplacées, suppression de fichiers non utilisés, remplacement d'un maximum de fonctions par les versions de musl ou de BSD, ajout des fonctions stdio_ext de musl en remplacement des fonctions privées supprimées, retrait d'une partie des fonctions mathématiques au profit de celles de musl, retrait d'une couche d'abstraction pour l'interfaçage entre la glibc et le support des locales dans Haiku. Certaines parties de la glibc continuent d'être utilisées pour assurer la compatibilité avec BeOS, mais l'objectif est de minimiser cette partie et d'utiliser les fonctions de BSD ou de musl, qui sont souvent beaucoup plus simples. La raison est que la glibc est conçue pour pouvoir être utilisée comme librairie C alternative sur de nombreux systèmes, et doit donc avoir un comportement très proche de la librairie C originale. Par exemple, le format des nombres "long double" peut être différent d'une architecture et d'un système à l'autre, et la glibc implémente de nombreux formats spécifiques, là où musl se contente des formats les plus classiques.

Mise à jour de getopt, printf et scanf avec la verson de la glibc 2.41. Pour l'instant ces fonctions continuent d'utiliser la version de la glibc, afin de préserver la compatibilité avec les applications existantes (notamment les applications pour BeOS). En effet, des structures internes sont exposées dans l'ABI et ne peuvent pas être facilement remplacées par une autre implémentation.

Tous ces changements sur la librairie C standard sont faits également en collaboration avec un développeur de la gnulib, dont la suite de tests permet de repérer de nombreux comportements incorrects ou non standards.

Gestion de la mémoire

Finalisation d'un gros chantier de refonte de la gestion de la mémoire, avec en particulier la possibilité de fusionner des zones de mémoire adjacentes lorsqu'elles sont redimensionnées. Suite à ces changements, l'allocateur mémoire hoard2 a pu être remplacé par une nouvelle implémentation basée sur celle de OpenBSD, avec quelques adaptations et améliorations spécifiques à Haiku, dont en particulier un cache d'allocation global pour chaque application. Le nouvel allocateur est légèrement plus rapide en général, et plusieurs ordres de grandeur plus rapide sur certains cas particuliers (par exemple: gcc avec les options de link-time-optimization, ou le compilateur SDCC, ou un test de compilation passe de plusieurs heures à une ou deux minutes). Ce nouvel allocateur est également moins consommateur de mémoire et permet aux applications d'allouer plus de mémoire (hoard2 limitait les allocations à environ 3Go y compris sur les systèms 64 bits).

Amélioration des messsages d'erreur de la "guarded heap" (allocateur mémoire de débug) pour afficher des messages d'erreurs plus spécifiques au lieu de "generic segfault".

Autres changements

Ajout de macros manquantes dans le fichier elf.h ainsi que de la constante MAP_FILE (inutile mais présente sur Linux et tous les systèmes BSD) pour faciliter le portage de WebKit.

Interdiction de l'appel de create_sem avec un compteur négatif. Cela était interdit par BeOS mais autorisé par Haiku et il n'y a pas vraiment de raison de le faire.

Modification du code assembleur d'appel des appels systèmes pour inclure des informations de debug sur la pile d'appels. D'autre part, dladdr a été modifié pour pouvoir accéder aux informations sur ces symboles, qui sont chargés dans la commpage (une zone de mémoire partagée entre le noyau et les processus utilisateurs, qui n'est pas à proprement parler une section de code classique en mémoire). Cela permet à libunwind d'analyser une stacktrace comprenant un appel système.

Par korli, PulkoMandy, trungnt2910, waddlesplash, zeldakatze

Noyau

Désactivation des états de veille C5 et C6 sur les machines Intel "Skylake", car elles empêchent ces machines de démarrer correctement pour l'instant.

Réparation du cache d'objets "guarded heap" qui permet de détecter et d'investiguer certains problèmes d'allocation mémoire dans le noyau.

Traitement d'un cas d'erreur dans le cache de fichiers, si la taille d'un fichier est devenue plus petite que son cache entre le moment ou une application demande un accès et le moment où l'accès va effectivement être réalisé.

Protection de l'accès à certains "spinlock" par des mutex. L'accès aux spinlocks doit être rapide, puisque l'attente est faite de façon active et monopolise un coeur de CPU. Il faut donc s'assurer que le spinlock pourra être rapidement disponible. En particulier, l'affichage de logs à l'écran lors du démarrage pouvait considérablement ralentir les choses (l'affichage se fait page à page et le processus de démarrage est mis en pause en attendant que l'utilisateur appuie sur une touche).

Déplacement de la calibration du timer APIc x86 dans le noyau au lieu du bootloader. Amélioration de la précision de la mesure et utilisation de la calibration fournie via les registres CPUID si elle est disponible (c'est le cas pour certains hyperviseurs par exemple, sur lesquels le système virtualisé peut difficilement faire lui-même une mesure fiable).

Correction du traitement d'un cas particulier par mprotect, qui se manifestait par un kernel panic lors de l'utilisation du navigateur Iceweasel.

Ajout d'un timeout sur l'envoi d'infos sur le port série sur les machines x86. Par exemple sur le Steam Deck, le port série n'est pas du tout présent et cela empêchait le démarrage du système.

Réécriture de la fonction x86_{read|write}_msr pour les machines 32 bit en tant que fonction inline (c'était déjà le cas pour les machines 64 bits).

Correction de problèmes trouvés en essayant de démarrer Haiku sur un laptop très récent: ajout du support de X2APIC dans le bootloader EFI, allocation de la page "PML4" avec une adresse physique < 4Go pouvant être codée sur 32 bits, et à l'inverse traitement correct de la table GDT lorsqu'elle se trouve au-delà de cette limite de 4Go.

Déplacement de code de bfs vers le VMCache générique pour traiter le cas particulier du mmap sur un fichier dont la taille n'est pas un multiple de la taille de pages du système. La dernière page doit alors être remplie avec des 0. Cela avait été corrigé pour bfs, mais le problème était également présent pour d'autres systèmes de fichiers dont en particulier ramfs.

Réécriture des FIFOs noyaux (utilisés pour implémenter pipe(2)). Le benchmark stress-ng --pipe 1 passe de 230 Mo/s à 2.5Go/s (dans une machine virtuelle).

Ajout d'une option syslog_max_history pour pouvoir conserver plus que 2 fichiers de syslog (ce qui reste l'option par défaut).

Nettoyage et optimisation de la structure Thread utilisée dans le noyau pour représenter les threads: utilisation d'une liste doublement chaînée pour accélérer les manipulations de la liste, correction du décomptage du temps CPU utilisé par les processus, correction d'une fuite mémoire, et correction d'un problème dans la fonction get_next_thread_info si les identifiants de threads bouclent (c'est-à dire que plus de 4 milliards de threads ont été créés et que des identifiants de threads ont donc dû être recyclés).

Le kernel panic se produisant si un thread tente de libérer un mutex qui ne lui appartient pas affiche automatiquement la stacktrace du thread qui est propriétaire du mutex.

Ajout d'un appel à cpu_pause dans le code des conditions variables pour réduire la consommation électrique inutile lors d'une attente active.

Correction de plusieurs problèmes de sauvegarde du contexte de la FPU pour l'architecture x86_64:

• Remise à 0 de l'état de la FPU lors des changements de threads,
• Stockage de l'état de la FPU dans la structure d'info sur le thread au lieu de la stocker sur la pile,
• Envoi des bons codes d'exception FPE_* lors des exceptions SIGFPE,
• Gestion des "control words" lors des changements de contexte.

Cela corrige des crashs d'application et même des kernel panic dans certains cas.

Les drapeaux de protection des zones de mémoire du noyau ne sont plus visibles par les utilisateurs non privilégiés. L'utilisateur "user" principal peut toujours y accéder, cela est utilisé par exemple par ProcessController. Correction d'un flag mal positionné pour les zones mémoire de l'allocateur "slab", qui n'étaient pas indiquées comme accessibles en écriture.

Renommage des fonctions concernant la gestion des interruptions pour éviter l'abbréviation "int" qui pouvait prêter à confusion avec "integer" dans certains cas. Utilisation du mot complet "interrupt" lorsque c'est possible, ou à défaut de "intr".

Correction d'une fuite de mémoire dans la gestion de la mémoire physique avec du paging à 5 niveaux (LA57).

Correction d'un interblocage dans le cache du système de fichier identifié à l'aide des tests de gVisor.

Correction d'un bug dans la fonction vsnprintf du noyau qui n'affichait pas correctement les nombres inférieurs à 0.1 (les 0 après le point étaient perdus, et donc 0.01, 0.001. 0.0001, … étaient tous affichés comme 0.1).

L'appel système create_dir retourne EEXIST si un fichier ou un dossier existe déjà à l'endroit demandé, et ce, même si le système de fichier est en lecture seule. Auparavant, l'appel système retournait EROFS, ce qui perturbe certaines applications.

Amélioration du traitement des "doubles fautes" (lorsque le traitement d'une exception matérielle déclenche une autre exception matérielle) sur x86. Le registre GS était corrompu, ce qui empêchait l'utilisation du debugger dans ce cas, et plusieurs autres problèmes conduisaient vraissemblablement à une "triple faute" (une exception dans le traitement de l'exception dans le traitement de… bon vous voyez le principe), et à un redémarrage de la machine car à ce stade il est peu probable qu'aucune autre opération ne remette le système dans un état cohérent.

Bootloader

Amélioration du bootloader PXE pour afficher clairement "Network" dans la méthode de démarrage, ainsi que l'adresse IP du serveur de disque fournissant le rootfs.

Remise en route du développement sur la console graphique utilisée pour simuler un mode texte pour le menu de démarrage, lorsque la machine ne fournit pas un mode texte matériel ou au niveau de son BIOS (c'est le cas par exemple sur certains Chromebooks avec SeaBIOS). Pour l'instant, cela nécessite une version du bootloader compilée spécifiquement pour ce cas de figure, car on ne sait pas encore détecter de façon fiable si le mode texte du BIOS est disponible.

Par Anarchos, augiedoggie, korli, phcoder, waddleslplash

Scripts de compilation

Poursuite du travail pour corriger tous les warnings détectés par le compilateur, ainsi que quelques problèmes détectés par les sanitizers de gcc (libasan et libubsan) qui sont maintenant compatibles avec Haiku.

Correction de problèmes empêchant de cross-compiler Haiku depuis FreeBSD ou un système Linux utilisant la libc musl. Correction également de problèmes pour le build depuis macOS.

Suppression de fichiers inutiles dans la version de unzip intégrée dans le build de Haiku.

Généralisation des options permettant d'activer la "stack protection" à plus de parties du système.

Remplacement de la commande which par command -v. Cette dernière est un builtin de la plupart des shells, elle est donc plus rapide à exécuter et ne nécessite pas une dépendance supplémentaire.

Migration de Python 2 à Python 3 pour le script générant les fichiers "libroot stubs" (utilisé uniquement lors du bootstrapping de Haiku pour une nouvelle architecture).

Mise à jour de la version de m4 utilisée pour le bootstrap de Haiku (compilation de tous les paquets à partir des sources, utile en particulier pour le portage sur une nouvelle architecture).

Ajout des modules PCI manquants dans l'image de bootstrap.

Par korli, PulkoMandy, waddlesplash

Documentation

Ce trimestre, il y a principalement du travail sur la documentation interne. Il s'agit d'un document destiné aux développeurs de Haiku, par opposition aux développeurs d'applications pour Haiku, qui se tourneront plutôt vers le Haiku book pour les informations sur les interfaces publiques du système.

Mise à jour de la documentation sur la procédure à suivre pour synchroniser du code avec d'autres systèmes. Haiku réutilise du code de FreeBSD, NetBSD, OpenBSD, musl et quelques autres, et maintient également deux copies de gcc et des binutils. Il est important d'avoir une procédure bien définie pour tracer ce qui a été importé, depuis quelle version, et quels changements ont été effectués. Plusieurs documentations existaient avec différentes fçons de faire, dont certaines étaient obsolètes.

Dans la documentation du device manager, ajout d'une image montrant un exemple de device tree, pour mieux visualiser ce qui est expliqué dans la page.

Déplacement d'articles sur l'implémentation des appels systèmes du site web principal vers la documentation interne (dans le cadre d'un très long projet pour réorganiser la documentation et libérer le site principal de nombreux articles techniques pour en faire une vitrine plus orientée vers les utilisateurs).

Ajout dans la documentation interne d'un article sur le profilage et l'analyse de performance des applications.

Correction de liens internes morts dans la documentation interne sur la gestion des paquets, suite à des erreurs de formatage.

Mise à jour de la documentation interne sur le processus de bootstrap.

Par kuku929, oco, PulkoMandy, waddlesplash

Le livre ./code --poetry est un objet original réunissant programmation, poésie et graphisme, que l’amoureux du code peut prendre plaisir à avoir dans sa bibliothèque pour le feuilleter de temps en temps et méditer sur toute cette littérature pour machines qu’il a écrite depuis ses premiers émois binaires. Attelage a priori improbable, Daniel Holden est programmeur et travaille dans les jeux vidéos à Montréal alors que Chris Kerr est un poète qui vit à Londres. Ils ont en fait fréquenté la même école et se connaissent depuis l’âge de onze ans. Explorons leur livre :

• Daniel Holden et Chris Kerr, ./code --poetry, Broken Sleep Books, 2023, ISBN 978-1-915760-89-0.

Sommaire

• Sources et rendus
• Autres textes pour « massive nerds »
• Le logos informatique
• Notes diverses
• Bibliographie

Sources et rendus

Un code poem est un code source mélangé à de la poésie, alors on pourrait traduire l’expression par un mot composé comme code-poème ou poème-source. J’utiliserai plutôt cette dernière traduction, le mot « source » ayant clairement des connotations poétiques. Pour ce qui est du concept de code poetry, poésie-source me satisfait moins. À vous de voir.

Dans les poèmes-sources du livre, parfois les mot-clés du langage utilisé font partie du texte du poème, parfois le poème est simplement contenu dans des commentaires que la coloration syntaxique et la mise en page aideront à mettre en valeur. Utiliser des chaînes de caractères est une autre solution facile. On peut aussi généralement utiliser des noms de variables (éventuellement inutilisées), de fonctions, de labels, etc. Dans certains poèmes-sources les parties de code imprononçables sont isolées en haut ou en bas du code source comme dans chernobyl.rkt. Le code est toujours mis en forme avec soin et constitue parfois un calligramme, mot inventé par Apollinaire, par exemple une raquette de tennis pour Processing. Les auteurs se réclament également de la poésie concrète.

On notera que dans le cas où l’on utilise également les mots-clés du langage dans le texte poétique, on sera bien sûr dans la plupart des langages plutôt incité à écrire en anglais. Mais on pourrait aussi considérer leurs mots-clés comme des parties d’un mot, par exemple for(midable=0;;) // j’étais fort minable. Sinon, on pourra utiliser un langage Logo en français ou quelques autres rares langages pour batracien hexagonal que vous pourrez citer en commentaires.

Une contrainte majeure respectée dans le livre est qu’un programme doit être exécutable : il produit alors souvent de l’art ASCII, soit statique soit le plus souvent dynamique comme dans water.c, mais peut aussi produire un texte mixant poésie et codes informatiques (des balises HTML par exemple dans divide.php). Quant au titre du poème, c’est simplement le nom du fichier source.

Les sujets abordés dans ces poèmes sont variés : expériences personnelles, théories du complot, dystopies, technologie et environnement, etc. D’après l’introduction du livre, chaque poème-source et sa sortie sont censés refléter le caractère du langage informatique utilisé. On trouvera pour chacun des vingt-six poèmes le code source sur la page gauche, avec coloration syntaxique, sur fond clair ou sombre, et sur la page droite la sortie. Le livre se double d’un site compagnon https://code-poetry.com/ qui a l’avantage de montrer les versions animées des sorties. Le livre essaie néanmoins de rendre cela par des successions de copies d’écran quand c’est possible. Comme la bannière en haut du site web semble boguée ou incomplète, voici les liens directs vers les vingt-six codes disponibles : Javascript, Julia, PHP, Racket, C++, Piet, Bash, Shakespeare, Perl, C, Haskell, C, J, Batch, Ruby, Objective C, Go, Processing, Ante, Befunge, C#, Python, Python, Erlang, Lua, Brainfuck. On notera que parmi les langages vedettes, le C et le Python ont droit à deux codes. Et on saluera les efforts du programmeur pour arriver à maîtriser les bases de tous ces langages pour la rédaction du livre. Si vous y trouvez un de vos langages préférés, vous pouvez partager en commentaires les particularités ou astuces des codes présentés (on frise parfois l’offuscation).

Autres textes pour « massive nerds »

Après les vingt-six poèmes, nous tombons sur la Code Poetry Manual Page, placée dans la section 7 des man-pages (Overview, conventions, and miscellaneous) : ./code --poetry - A collection of executable art. Chaque poème ou langage a droit à un paragraphe de commentaires (techniques, littéraires ou humoristiques).

Le livre se termine par un texte de chaque auteur. Le premier texte, celui du poète, explique les contraintes liées à la mise en page et à la présentation graphique des codes sources et de leurs sorties à la fois dans le livre et sur le site compagnon, puis se termine par une liste d’autres livres déjà publiés sur le sujet, en insistant sur ce en quoi le présent livre s’en démarque.

Le second texte est écrit par le programmeur du tandem et s’intitule (si l’on interprète le graphisme d’introduction) « I love ASCII ». Il tente d’abord d’expliquer au candide (qui serait tombé par hasard sur ce livre ?) ce qu’est un langage de programmation pour l’introduire à la culture geek. Il explique par exemple la multiplicité des langages et dit :

Les gens ont donc tendance à s’identifier à certains langages plus qu’à d’autres, ce qui entraîne un effet d’amplification. Au fur et à mesure que les gens affluent vers le langage qui leur correspond le mieux, la culture s’homogénéise. Des frontières sont tracées, des nations se développent et des drapeaux sont hissés.
Ces factions sont connues pour se livrer à des « guerres de religion » à propos du meilleur style de programmation. La lecture des arguments est une expérience en soi, quelque part entre un débat théorique entre physiciens des particules et une dispute enfantine sur Porsche versus Ferrari.

Le texte se termine par la déclaration d’amour au code ASCII annoncée en titre, avec des explications intéressantes sur les origines de certains caractères. Mais quand l’auteur taquine sa compagne en lui disant qu’il va se faire tatouer les quatre-vingt-quinze caractères imprimables du code ASCII, elle lui répond en substance : « Please don’t, you massive nerd! »

Finalement, la dernière page imprimée du livre nous invite à nous mettre au travail avec la chaîne de caractères layoutyourunrest écrite en majuscules puis en minuscules. On peut traduire ça par : « exposez votre trouble ». C’est en fait la devise de la maison d’édition Broken Sleep Books (dont le fondateur est insomniaque !), spécialisé dans la poésie et basée au Pays de Galles. Alors lecteur linuxien, es-tu inspiré ? N’es-tu pas en mal de défi depuis que TapTempo a été porté dans ton langage favori ? Are you experienced?

Le logos informatique

Le verbe créateur est bien sûr un thème biblique. Wikipedia rappelle également que :

Le terme « poésie » et ses dérivés « poète », « poème » viennent du grec ancien ποίησις / poíesis par le verbe ποιέω / poiéō, « faire, créer » : le poète est donc un créateur, un inventeur de formes expressives […]

On sait bien que les écrivains créent des mondes, certains poussant même la chose à l’extrême, comme J.R.R. Tolkien qui a créé tout un monde avec sa mythologie, son histoire, sa géographie, ses créatures, ses langues, ses poèmes et chansons, etc. Mais les développeurs ne sont pas en reste. Que le logos informatique soit créateur et crée des mondes, voire le monde, pour le meilleur et pour le pire, quiconque a vécu l’évolution de notre société depuis les débuts du web pourra difficilement en douter.

Notes diverses

• Difficile après cette conclusion de ne pas avoir envie de réécouter Un autre monde (1984) de Téléphone. « Dansent les ombres du monde ».
• Cette alliance de la poésie et de la technologie m’a fait aussi penser à Anne Clark, qui dans les années 80 déclamait ses textes dans un style dit « spoken word » sur fond de musique électronique new wave. Son morceau le plus connu est Our Darkness (1984), qualifié plus récemment par certains de proto-house. Elle a continué sa carrière et en 2022 a sorti un album Borderland (Found Music for a Lost World) dans un style musique de chambre. On y trouve en particulier un poème de Mary E. Coleridge (1861-1907) intitulé L’oiseau bleu récité par Anne Clark : The Bluebird. Enfin, sur son site officiel, on voit qu’en 2024 elle a prêté sa voix à des installations réalisées par l’artiste Clemens von Wedemeyer qui s’intéresse entre autres aux relations sociales, comme on peut le voir sur ces photos montrant des graphes : Social Geometry. Malheureusement, on ne l’entendra pas ; il aurait fallu aller à Berlin.
• Cette dépêche n’est pas sans lien non plus avec Des nouvelles de Fortran n°6 où j’évoquais récemment l’utilisation du langage dans les années 60-70 pour explorer la génération automatique de poèmes.
• On notera que comprendre la poésie moderne anglo-saxonne peut parfois être ardu, la syntaxe de la langue, déjà plutôt souple, subissant des contorsions et le vocabulaire puisant dans le vaste répertoire de la langue anglaise. Sans compter ici le mélange avec le code source qui brouille parfois la lecture (faut-il lire les mots-clés du langage ?).

Bibliographie

• Chris Kerr et Daniel Holden, « Optimizing Code for Performance: Reading ./code --poetry » in Poetry and Contemporary Visual Culture / Lyrik und zeitgenössische Visuelle Kultur, édité par Magdalena Elisabeth Korecka et Wiebke Vorrath, Berlin, Boston: De Gruyter, pages 167-184, 2023, https://doi.org/10.1515/9783111299334-009, licence CC BY-NC-ND 4.0. Dans ce chapitre, on trouvera en particulier des explications éclairantes sur certains des poèmes-sources du livre.
• Interview des auteurs du livre (en), Daniel Holden et Chris Kerr, par Aaron Kent, 11 octobre 2023.
• Alan Riddell, Typewritter Art, London Magazine Editions, 1975, PDF en ligne. Ce livre contient de belles illustrations de cet art de la machine à écrire, une forme de poésie concrète.
• L’entrée nerd dans Linguee.
• Le livre avait été évoqué dans la section Liens en août 2023 : https://linuxfr.org/users/gilcot/liens/what-is-code-poetry .
• Quatre poèmes-sources du livre avaient déjà été publiés en 2019 sur le site https://www.welcometothejungle.com/fr/tags/developers-poem-programs .

Le consortium Unicode a annoncé la sortie de la version 16.0.0 de sa norme d’encodage des caractères le 10 septembre 2024. En bref, cette version voit le nombre de caractères passer de 149 813 à 154 998, soit 5 185 caractères supplémentaires. Elle ajoute sept nouvelles écritures, de nouveaux fichiers de données et quatre normes techniques Unicode sont versionnées pour être synchrones avec la norme Unicode. Elle remplace toutes les autres versions, la précédente datant de 2022.

Quelques-uns de ces changements sont détaillés ci-après, et, évidemment, tout figure dans les notes de version (en).

Sommaire

• Afrique
  • Les hiéroglyphes égyptiens, le principal ajout en nombre de caractères
  • L’alphabet Garay
• Asie
  • Les écritures de langues indiennes
  • Japon
• Albanie
• Émoji et héritage informatique
• Synchronisation
• Montée en version vers Unicode 16
• Fin

Afrique

Les hiéroglyphes égyptiens, le principal ajout en nombre de caractères

On se souvient peut-être des réactions des égyptologues, lors de l’introduction des hiéroglyphes égyptiens dans le standard Unicode en 2009. Il ne contenait que les sept-cent signes de base répertoriés par l’égyptologue britannique Alan H. Gardiner (1879 – 1963). Le gros reproche était le faible nombre de hiéroglyphes retenus : on en connaît plus de 6 000. Unicode 16 a rajouté 3 995 caractères aux 1 654 existants déjà dans le standard. Ce qui porte à 5 649 le nombre de hiéroglyphes égyptiens du catalogue Unicode

Les hiéroglyphes égyptiens occupent les blocs Unicode 13460 à 1355F.

L’alphabet Garay

L’alphabet Garay fait son entrée dans les blocs Unicode 10D40 à 10D8F.

Cet alphabet a été créé en 1961 par El Hadji Assane Faye, qui fut, entre autres, président du mouvement des enseignants en langues africaines. L’objectif étant de retranscrire « les caractéristiques sociolinguistiques africaines ». L’alphabet Garay comporte vingt-cinq consonnes et quatorze voyelles. Il est notamment utilisé pour le wolof, langue nationale du Sénégal, de la Mauritanie et de la Gambie. Il s’écrit de droite à gauche.

Asie

Les écritures de langues indiennes

Cinq écritures sont ajoutées à cette version d’Unicode. Les quatre premiers alphabets sont récents :

• Gurung Khema ou Khema est l’une des écritures utilisées pour retranscrire le Gurung (en), une langue parlée dans le Népal, il s’écrit de gauche à droite et occupe les blocs Unicode 16100 à 1613F,
• Kirat Rai (en), qui s’écrit de gauche à droite, est utilisé pour écrire le Bantawa, une langue parlée dans l’est de l’Himalaya et l’est du Népal, les blocs Unicode 16D40 à 16D7F lui sont réservés,
• Ol Onal a été inventé entre 1981 et 1992 (en) par Mahendra Nath Sardar pour transcrire la langue Bhumij, une langue parlée par quelques populations de l’ouest du Bengale et des états indiens Jharkhand, Odisha et Assam. Elle s’écrit de gauche à droite et on la retrouvera dans les blocs Unicode 1E5D0 à 1E5FF,
• Sunuwar (en), une écriture qui a été développée en 1942 par Krishna Bahadur Jentich (1926 - 1991) pour écrire la langue éponyme parlée dans le Sikkim, un État du nord de l’Inde, et au Népal, s’écrit de gauche à droite et figure dans les blocs Unicode 11BC0 à 11BFF,
• Tulu-Tigalari ou Tilagari est une écriture plus ancienne. L’alphabet a été conçu à partir de l’alphabet Grantha, une écriture du sud de l’Inde, depuis le XI^e siècle. Utilisé au départ pour le sanscrit, le Tilagari (en) sera aussi l’écriture du Tulu, une langue du sud-ouest de l’Inde à partir du XV^e siècle. Il s’écrit de gauche à droite et occupe les blocs Unicode 11380 à 113FF.

Japon

La base de données des caractères japonais « Moji Jōhō Kiban » (文字情報基盤) a été ajoutée comme source de référence (en) aux 36 000 idéogrammes unifiés CJC (chinois, japonais, coréen). Ce qui se reflète dans les tableaux de codes de pratiquement tous les blocs d’idéogrammes unifiés CJC par des glyphes représentatifs supplémentaires dans la colonne « J ».

Albanie

L’alphabet Todhri (en) a été inventé par Todhri Haxhifilipi (1811 - 1869) pour écrire en langue albanaise. Composée de cinquante-deux caractères, il s’écrit de gauche à droite et semble dériver de l’écriture cursive romaine.

Les blocs Unicode 105C0 à 105FF lui sont réservés.

Émoji et héritage informatique

Sept nouveaux émojis font leur entrée :

• une tête avec des valises sous les yeux (face with bags under eyes), 1FAE9,
• une empreinte digitale (fingerprint), 1FAC6,
• un arbre sans feuille (leafless tree), 1FABE,
• un radis (root végétable), 1FADC,
• une harpe (harp), 1FA89,
• une pelle (shovel), 1FA8F,
• une éclaboussure (splatter), 1FADF.

À cela s’ajoutent sept-cent symboles (en) d’environnements informatiques, blocs Unicode 1CC00 à 1CEBF (Symbols for Legacy Computing Supplement).

Synchronisation

Plusieurs spécifications Unicode importantes ont été mises à jour. Notamment les quatre standards UTS #10, UTS #39, UTS #46, et UTS #51. Ils sont maintenant versionnés de façon synchronisée avec le standard Unicode, leurs fichiers de données couvrant les mêmes répertoires. Ils ont tous été mis à jour en version 16.

Ces modifications sont susceptibles de nécessiter des changements dans les implémentations. Les sections migrations et modifications des standards UTS #10 (en), UTS #39, (en), UTS #46 (en) et UTS #51 (en) indiquent comment y procéder.

Montée en version vers Unicode 16

Quels impacts pour cette montée en version, outre les modifications apportées par l’ajout de nouveaux caractères et de nouveaux systèmes d’écriture ? Ils semblent plutôt mineurs, le changement le plus notable concerne sans doute celui de l’accès aux spécifications Unicode :

• les spécifications de base ont été complètement remaniées pour Unicode 16.0 et, converties en HTML, elles sont déployées dans un sous-site autonome,
• plusieurs des caractères ajoutés peuvent avoir quelques implications sur certaines optimisations de la normalisation; cela ne modifie pas l’algorithme de normalisation, mais il peut y avoir des conséquences sur la dérivation et l’utilisation des propriétés Quick_Check pour l’optimisation de la détection des formes de normalisation, voir UAX #15 (en),
• des modifications ont été apportées sur les sauts de lignes apportées au guillemet simple gauche, U+2018 ‘ et aux guillemets directionnels similaires dans les contextes spécifiques d’Asie de l’Est afin de corriger les sauts de ligne en chinois simplifié et mieux coller aux spécifications au comportement de l’ICU (International Components for Unicode, bibliothèque logicielle, à ne pas confondre avec la fédération internationale des cheerleaders), voir UAX #14 (en),
• quelques changements ont été apportés à la spécification afin de mieux s’aligner sur les pratiques courantes et simplifier les éléments transitoires qui ne sont plus nécessaires.

Fin

On laissera le mot de la fin à St00e9phane Bortzmeyer¹ au sujet d’un site (de 2023) codé avec les pieds et une faible connaissance d’Unicode :

Si tu n’es pas assez fort pour lire les points de code Unicode, c’est que tu ne t’appliques pas assez de discipline.

J’en profite pour le remercier d’avoir fait passer l’information sur la sortie d’Unicode 16 sur Mastodon, sinon je l’aurais complètement ratée.

Dans cette nouvelle excursion du Transimpressux, nous voyagerons chez les Mayas de l’époque pré-colombienne ainsi que dans la Rome antique. Nous ferons un rapide tour des monastères médiévaux, nous irons rendre une courte visite à Aloys Senefelder à Munich. Nous en profiterons pour aller voir Isaac Newton, Tintin et Astérix et on terminera notre voyage à Kreutzal, en Allemagne. On n’y parlera pas de Rahan, quoique. On aura compris qu’il sera question d’image, d’écriture et de texte.

Le bar du Transimpressux vous propose un vaste échantillon issu du pas si grand livre des recettes de LinuxFr.org. En espérant qu’à la lecture de cette dépêche vous aurez fait un beau voyage.

Sommaire

• Préambule
• Quelques définitions avant de commencer
• L’écriture et l’image, des concepts différents vraiment ?
  • L’exemple des hiéroglyphes mayas
  • Le contre exemple romain
• La séparation du texte et de l’image
  • Les manuscrits médiévaux, une séparation parfois extrême
  • L’imprimerie : des typographies ornementales
  • La bande dessinée : des métiers différents
• Qu’est-ce que le texte ?
• Nouveau Drop Caps : une police de lettrines
• Les textes et documents qui ont servi à alimenter cette dépêche
• Postambule

Préambule

Au départ, j’avais prévu de parler aussi de formats, mais, à l’arrivée, c’est déjà bien long. La question des formats fera donc l’objet d’une autre dépêche de la série.

J’utilise indifféremment les termes de fonte, police, police de caractère ou typographie. Et, comme il sera question de périodes très éloignées dans le temps, celles antérieures à notre ère seront indiquées sous la forme AEC (avant l’ère commune).

Quelques définitions avant de commencer

Il est possible que certaines notions ne vous soient pas claires, ces quelques définitions vous seront peut-être utiles.

• Codex : livre formé de feuilles pliées et assemblées en cahiers, et couvert d'une reliure tel que nous le connaissons.
• Logogramme, logographique : un logogramme est un dessin représentatif d'une idée ou d'une suite de sons, utilisé dans une écriture idéographique.
• Pictogramme, pictographique : un pictogramme est un dessin figuratif ou symbolique utilisé pour communiquer sans langage parlé.
• Idéographique : qui représente directement les idées par des signes propres à les suggérer.
• Phonogramme, phonographique : dans ce contexte, signe graphique susceptible de représenter un son.
• Glyphe : représentation visuelle des caractères.

L’écriture et l’image, des concepts différents vraiment ?

L’écriture n’est pas de l’image, l’image n’est pas de l’écriture. Oui et non.

L’exemple des hiéroglyphes mayas

Le système d’écriture maya n’est pas purement logographique. D’ailleurs est-ce qu’un système d’écriture uniquement logographique ou pictographique existe vraiment ? On a vu précédemment sur LinuxFr.org concernant les systèmes d'écriture que les hiéroglyphes égyptiens et les sinogrammes n’étaient pas composés que de pictogrammes, mais qu’ils allaient de pair avec d’autres signes, notamment phonographiques. Il en va de même avec l’écriture maya qui

est un système graphique normalisé qui, au moyen de quelques centaines de « signes-mots » (ou logogrammes) et environ 150 phonogrammes marquant des syllabes de type Consonne-Voyelle¹.

L’écriture maya est apparue, à notre connaissance vers 400 AEC et a été utilisée jusqu’au XVII^e siècle où l’envahisseur espagnol a tout fait pour l’éradiquer, y compris en brûlant des codex. Entre les Espagnols et le climat chaud et humide de la sphère d’influence maya, on ne connaît plus que trois codex mayas précolombiens² : le codex de Dresde, celui de Paris et celui de Madrid. Un quatrième codex, le codex Grolier, conservé à Mexico est sujet à controverses, sa datation et son authenticité ne sont pas certaines. Mais on retrouve aussi l’écriture maya sur des monuments et du mobilier. On trouve également des graffitis, signe, sans doute, d’un certain niveau d’alphabétisation de la population maya. L’écriture maya devait transcrire plusieurs langues amérindiennes, lesquelles langues ont toujours des locuteurs.

Deux pages du codex de Paris

Pour autant qu’on sache, pour les Mayas, leur écriture tout au moins, l’image était importante. Selon Jean-Michel Hoppan :

Cette écriture est rigoureuse et, tout à la fois, très souple. Elle n’est pas normalisée, au contraire de l’idée qu’on se fait habituellement d’une écriture. Le scribe peut privilégier l’esthétisme au détriment de la compréhension immédiate (en tout cas pour nous). C’est encore plus évident sur les céramiques, où le texte est parfois complètement inintelligible. Le glyphe est là, toujours chargé du pouvoir de l’écrit, mais le contenu de la parole n’est plus. Il devient image. Il y a une grande partie de la céramique où l’on voit de l’écriture, mais qui, de fait, est constituée de pseudoglyphes.³

Les hiéroglyphes mayas n’ont pas de bloc Unicode, même si les chiffres y figurent depuis la version 11.0 (juin 2018). Un billet du blog du consortium (en) du 23 janvier 2020 annonçait l’existence d’une subvention « pour restituer numériquement des écritures historiques et modernes supplémentaires, y compris des hiéroglyphes mayas. ». L’idée étant aussi de faire progresser la recherche de la connaissance de l’écriture et de la culture maya sur les sites de la période 250 – 900, une étape importante pour déterminer les signes à intégrer à Unicode, et d’aboutir à la création de polices OpenType. La dernière version de la norme Unicode, 15.1.0, date du 12 septembre 2023, un peu juste pour incorporer les hiéroglyphes mayas quand on sait que la création d’une police peut prendre de quatorze à seize mois.

Le contre exemple romain

L’alphabet latin puise ses origines dans l’alphabet étrusque, qui, lui-même, provient du système d’écriture grecque et c’est, bien entendu, celui que nous utilisons sur LinuxFr.org (le latin, pas le grec, suivez un peu). C’est celui de l’ASCII. Il figure dans l’Unicode, évidemment, où il dispose de plusieurs blocs. Le bloc latin de base contient en fait tous les caractères et commandes de l’ASCII. Il n’a pas été modifié depuis la version 1.0.0 d’Unicode.

D’après les écrits qui nous sont arrivés, les Romains avaient une vision très « utilitariste » de l’écriture. Pour eux (les écrits qui nous sont parvenus sur le sujet proviennent essentiellement d’hommes) :

l’écriture est essentiellement destinée à (…) représenter [le langage]. De plus, dans sa version alphabétique, qui est à peu près la seule à laquelle pensent les Latins, l’écriture est une notation des sons, les lettres renvoient à des sons élémentaires et l’alphabet correspond terme à terme (en principe) à un inventaire fini de ces sons.⁴

Il s’agissait donc pour les anciens Romains non pas de

faire une science de la langue à travers sa représentation graphique, mais bien une science de l’écrit en tant qu’il renvoie à la langue. (Françoise Desbordes).

Un support du langage bien imparfait d’ailleurs puisqu’il ne rend pas les effets du discours oral. Et ce facteur explique aussi que la graphie ait mis du temps à se normaliser. L’écrit étant l’image de l’oral : la langue pouvait être prononcée par des locuteurs avec des accents différents et s’écrire ainsi en fonction de la prononciation.

Les écrits des Romains étaient variés, indépendamment des discours, naturellement et sous diverses formes : monumentales, tablettes de cire, papyrus, mais aussi graffitis que l’on pouvait retrouver sur les murs des édifices privés. Des graffitis qui étaient destinés à être lus et étaient très liés à l’oral :

les messages interpellant parfois nommément, au vocatif, une personne – homme ou femme. Ainsi s’explique aussi l’abondance des exclamations (feliciter ! salutem !), des salutations (salve vale !) et des vœux (votum aux Lares pour la salus du maître de maison). Leur caractère performatif ne fait pas de doute.⁵

Graffiti de Pompéi vantant les exploits sexuels du miles Floronius (CIL, IV, 8767). Wolff 2012, 19, fig. 7.

La séparation du texte et de l’image

Des compétences, des métiers et des techniques différentes.

Les manuscrits médiévaux, une séparation parfois extrême

Le travail de copie des monastères médiévaux, notamment (la profession se sécularisera à partir du XIII^e siècle), différait en fonction des lieux et des époques. Au début, le, ou les copistes, suivant en cela, semble-t-il, les traditions grecques et romaines, étaient également chargés de l’ornementation. Les copistes, parce que la copie d’un manuscrit pouvait être distribuée en plusieurs cahiers à différents copistes pour accélérer le travail de copie. La ponctuation, quant à elle, était généralement du ressort des correcteurs, quand il y en avait, pas des copistes.

Il arrivait aussi qu’il y ait un copiste pour le texte et un pour les enluminures, surtout pour les manuscrits les plus riches. Dans ce cas, le ou la copiste écrivait la lettre à enluminer et laissait la place nécessaire, à charge pour l’enlumineur ou l’enlumineuse d’orner le parchemin. Les copies n’étant pas du ressort unique des monastères, les enlumineurs et les enlumineuses étaient souvent des peintres.

Et parce que le travail était ainsi le fait de corps de métier différents, il subsiste des manuscrits médiévaux pas finis, avec des « blancs » pour des enluminures qui ne verront jamais le jour.

L’imprimerie : des typographies ornementales

Jusqu’à la fin du XVIII^e siècle, les techniques d’impression ont assez peu évolué. Il y avait des perfectionnements et des améliorations, certes, mais, les techniques restaient grosso modo celles de Gutenberg. Les illustrations étaient gravées à part, puis, après la découverte fortuite de la lithographie par Aloys Senefelder en 1796 dessinées sur la pierre, ce qui permettait aux artistes de travailler directement sur la pierre sans avoir à passer par l’intermédiaire d’un graveur. La lithographie permet en effet de dessiner le motif sur la pierre, à l’origine. Senefelder travaillera aussi sur plaque de zinc. La lithographie repose sur le principe de l’antagonisme de l’eau et de la graisse : les zones à imprimer sont traités à la graisse, les autres sont mouillées. L’encre grasse se dépose ainsi seulement sur les zones grasses.

Si l’impression en noir et blanc pouvait se faire d’une traite, celle en couleurs, selon les exigences et les techniques utilisées, pouvait requérir jusqu’à quatorze opérations différentes, et presque autant de passages couleurs. L’offset actuel, un procédé qui dérive de la lithographie, fonctionne en quadrichromie : cyan, magenta, jaune et noir (CMJN) et autant de passages couleur.

Les ornements plus susceptibles d’être réutilisés : lettrines, culs-de-lampe et autres fleurons, lignes et arabesques faisaient l’objet, quant à eux, de fontes ornementales spécifiques. Il y avait même des graveurs typographes spécialistes de typographie ornementale comme Joseph-Gaspard Gillé (pdf) (1766-1826). Aujourd’hui, ce genre de fonte peut se trouver, dans les blocs Unicode de systèmes d’écriture, notamment, latin. On y retrouve d’ailleurs bon nombre de ces polices ornementales purement figuratives même si leur dessin ne correspond pas à une lettre. Mais elles pourraient aussi bien figurer dans les flèches, les filets, les pavés, le bloc casseau ou encore les deux zones supplémentaires.

Les symboles du zodiaque de la collection de fontes de Gillé. Les symboles du zodiaque figurent dans les points de code Unicode U+2648 à 2653 (avec des dessins moins figuratifs).

Toutes les techniques d’imprimerie continuent à exister, de façon plus ou moins anedoctique. Les deux plus répandues étant l’offset, pour les gros volumes, et l’impression numérique (laser ou jet d’encre). Cette dernière étant la seule à imprimer les couleurs d’une seule traite.

La bande dessinée : des métiers différents

La bande dessinée ce n’est pas un métier mais quatre métiers différents qui peuvent ou non, être assurés par la même personne :

• le scénario,
• le dessin,
• la couleur,
• et le lettrage qui nous intéresse ici.

Le lettrage, dans la bande dessinée ce sont en fait plusieurs types d’écriture :

le paratexte (titres, signatures, numérotation), les interventions du narrateur (récitatifs, didascalies, commentaires), toute la notation des sons (dialogues, onomatopées, bruits) – le lettrage assume ainsi une part très importante du « régime sonore » de la bande dessinée, au point que l’on appelle « muettes » les bandes dessinées qui n’en comportent pas du tout (puisque le lettrage n’est pas indispensable à la réalisation d’une bande dessinée).⁶

Gotlib (les Dingodossiers, la Rubrique à brac, Super Dupont, Gai-Luron) est entré en bande dessinée par la voie du lettrage.

Un extrait des Dingodossiers de Gotlib, scénario de Goscinny. L’image comporte des didascalies à gauche et en haut à droite, une bulle de texte, en-dessous, du texte « sonore. »

D’autres auront leur lettreur attitré, comme Hergé. Arsène Lemey a assuré le lettrage de ses Tintin à partir de la version allemande du Secret de la licorne, le onzième album de la série. La police de caractère créée par Arsène Lemey pour Tintin est l’Arleson, elle sera intégrée à la photocomposeuse de Casterman dans les années 1970. Pour la série Astérix ce sont les lettrages de Michel Janvier, en charge de cette tâche pour un certain nombre d’album depuis 1989, qui ont été numérisés. Trois famille principale de typographies ont ainsi été créées par Le Typophage : Regularus pour les bulles, Boldus pour l’écriture très grasse et Graphix pour les onomatopées et les symboles graphiques.

Avoir sa propre police est actuellement assez facile en passant par des sites comme le Calligraphe qui permettent de générer une typographie à partir de son écriture manuscrite. C’est ce qu’a fait notamment heyheymomo (en) qui offre sa police en téléchargement (en).

Qu’est-ce que le texte ?

Au début de l’informatique, chez IBM l’unité de mesure était le mot (word). La capacité d’une machine s’évaluait donc en nombre de mots. Un mot étant, selon le manuel de l’IBM 605 constitué de « dix chiffres et d’un signe algébrique ». Ainsi l’IBM 605 avait une capacité de 1 000 à 2 000 mots. Le texte n’était pas bien loin.

Mais, qu’est-ce que le texte ? Selon les points de vue, la notion de texte peut être très vaste. En musique par exemple, il est question de sous-texte et ça n’a rien à voir avec les paroles de chanson ou de mélodies ou le livret des opéras. Dans le cadre de cette série qui, globalement, traite de l’informatique dans le contexte historique de l’écriture, j’opte pour une définition restrictive et axée sur l’écriture et la lecture.

Le texte est ainsi de l’écriture qui peut se lire avec les yeux, les oreilles ou les doigts et qui peut aussi être lue par des robots. C’est du texte fait pour être lu pas pour être exécuté dans le cadre d’un logiciel par exemple. Ce qui exclut le code informatique de la définition, même si c’est écrit avec des éditeurs de texte⁷. On doit pouvoir faire des recherches dans le texte, naviguer dedans, en extraire une partie pour la réutiliser ailleurs, etc.

Il s’ensuit qu’une image avec de l’écriture dessus, ce n’est pas du texte. Un fichier PDF, fac-similé d’un livre imprimé n’est pas du texte. Et les versions PDF des livres numérisés que propose la BnF Gallica par exemple ne sont pas du texte. Un formulaire en PDF qui est en fait une image que l’on aura modifiée avec un outil de dessin (ou imprimé et modifié à la main puis numérisé) n’est pas du texte.

En revanche, si, de mon point de vue, la structure d’une base de données n’est pas du texte, son contenu par contre, oui. Ainsi, au hasard, celle de LinuxFr.org, est du texte, la partie publique tout au moins. Et ce n’est pas Claude qui me contredira.

Un genre d’allégorie des tables de la base de données de LinuxFr.org.

Il est d’autant plus important d’insister là-dessus qu’il se trouve encore des personnes qui ne font pas la différence entre les deux. Et ce, tout simplement parce que c’est écrit et qu’elles, elles, peuvent lire ce qui est écrit.

Nouveau Drop Caps : une police de lettrines

Puisque qu’il a été question plus haut de typographies purement décoratives, c’est l’occasion de vous présenter une police qui ne peut servir qu’à des lettrines ou des titres.

Nouveau Drop Caps est une fonte générée par Dieter Steffmann (en) un typographe de formation qui a créé plus de trois-cent-cinquante polices. La plupart sont plutôt plus à des fins décoratives que des polices de texte. Dans l’ensemble, ses polices peuvent être utilisées pour la langue française, elles ont les caractères qu’il faut. La position de Dieter Steffmann sur son travail est la suivante :

je considère les polices de caractères comme un patrimoine culturel, je ne suis pas d’accord avec leur commercialisation. Les polices autrefois fabriquées à partir de caractères métalliques avaient évidemment un prix en fonction de la valeur du métal, et le coût de conception, de découpe et de moulage est convaincant, d’autant plus que l’acheteur devenait également propriétaire des polices achetées !

Le site sur lesquelles il les dépose, 1001 fonts a, d’ailleurs, une licence (en), avec une disposition assez originale. La police

peut être téléchargée et utilisée gratuitement pour un usage personnel et commercial, à condition que son utilisation ne soit pas raciste ou illégale. (…)

Les fontes peuvent être librement copiées et transmises à d'autres personnes pour un usage privé mais pas être vendues ou publiées sans l’autorisation écrite des auteurs et autrices.

Les textes et documents qui ont servi à alimenter cette dépêche

Les références sont données à peu près dans leur ordre d’apparition dans le texte. La plupart sont accessibles en ligne, et, volontairement, il y a un minimum de références à Wikipédia. Il y a, également, le minimum possible de sources en anglais.

L’écriture maya

Jean-Michel Hoppan est l’un des seuls (le seul ?) spécialiste français d’un domaine de recherche (l’écriture maya) qui ne compte qu’une centaine de personnes dans le monde.

• L’écriture maya, Jean-Michel Hoppan, INALCO (2014, 2015 ?).
• Les glyphes mayas et leur déchiffrement, Jean-Michel Hoppan, 2009.
• L’écriture figurative des Mayas Jean-Michel Hoppan, 2008.

La vision romaine de l’écriture

• Idées romaines sur l’écriture, Françoise Desbordes, 1990, EPUB : ISBN 9782402324168, PDF : ISBN 9782402657495, marquage filigrane. La maison d’édition FeniXX qui édite ce livre est spécialisée dans la réédition des livres indisponibles du XX^e siècle.
• L’écriture en liberté : les graffitis dans la culture romaine, Michelle Corbier, extrait de Langages et communication : écrits, images, sons, Corbier Mireille et Sauron Gilles (dir.), éd. électronique, Paris, Éd. du Comité des travaux historiques et scientifiques (Actes des congrès nationaux des sociétés historiques et scientifiques), 2017.

Les manuscrits médiévaux

On peut se procurer ces livres au format PDF (fac-similé), en texte brut (je travaille sur une version que je compte mettre en ligne pour chacun de ces livres), les emprunter en version EPUB à la BnF si l'on a un compte, ou acheter l’EPUB. À noter que, selon les librairies, le fichier EPUB a ou non une protection numérique : ainsi, Le Furet du Nord indique qu’ils n’en ont pas, Cultura annonce une DRM LCP, et la FNAC une DRM Adobe.

• Les manuscrits et les miniatures, Auguste Molinier, Librairie Hachette, 1892.
• Histoire de l’imprimerie et des arts et professions qui se rattachent à la typographie…, Paul Lacroix, Édouard Fournier, Ferdinand Seré, Séré, 1852.

Bonus ! Si vous voulez vous rincer l’œil, l’IRTH (Institut de recherche et d’histoire des textes) a dressé une liste de sites pour accéder au manuscrit médiéval numérisé.

L’imprimerie

• Les techniques d’illustration du livre imprimé, BnF Gallica.
• Imprimer et illustrer en couleur, album de la BnF.
• Impression offset. Qu’est-ce que c’est et comment ça marche ?, Richard H., 24 mars 2022.
• L’Imprimerie, Charles-Lucien Huard, 1892 à télécharger en versions EPUB, PDF et PDF hybride, ou récupérer en image ou en texte brut sur gallica.bnf.fr.
• Notice pour le concours des progrès de l’industrie française en 1819, Joseph-Gaspard Gillé, à télécharger en versions EPUB, PDF et PDF hybride. Le texte de ces versions est précédé d’une présentation avec un mini-glossaire, des notices sur les imprimeurs et inventeurs cités dans l’ouvrage et une biographie de l’auteur. On peut aussi le récupérer en image ou en texte brut sur gallica.bnf.fr.

La bande dessinée

• Lettrage, Laurent Gerbier, Cité internationale de la bande dessinée et de l’image, septembre 2017.

Postambule

La question des formats sera abordée dans le prochain chapitre qui est déjà bien avancé. Et ce n’est pas plus mal, finalement.

Dans le cadre de cette série, il va me falloir traiter aussi de la question des codes (sur laquelle j’ai quelques lacunes, vos suggestions sont bienvenues). Unicode, bien que déjà pas mal abordé, mérite un chapitre à lui tout seul : histoire, composition du consortium, comment on ajoute un système d’écriture à Unicode, et quelques paragraphes sur le code lui-même (et là…). Je pense que je pourrais peut-être caser la norme ISO des écritures dans ce chapitre. Si j’ai parlé de conservation, il va falloir parler de l’archivage : protocoles, accès, ce qui me permettra d’évoquer aussi de la science ouverte, je pense.

Capture d’écran de la page de statut d’Argos

En un CLIC, une installation simplifiée et ergonomique.

Le portail de sélection des services a été travaillé graphiquement.

Des boîtiers pour nano-ordinateurs Odroid.

La chatravane, un prototype de serveur nomade alimenté par des panneaux solaires.