Vue lecture

Haiku a 23 ans et un quart

La dernière dépêche annuelle sur les nouveautés dans Haiku a dépassé la longueur maximale tolérée par Linuxfr (et été finalement découpée en plusieurs parties publiées séparément). Aussi, les nouveautés sur Haiku seront désormais publiées trimestriellement, pour faire face à l’augmentation d’activité dans le projet.

Sommaire

Ce rapport est basé sur les rapports mensuels d’activité d’août, septembre et octobre publiés sur le site de Haiku. Il couvre les changements de code survenus entre hrev57901 et hrev58291 de Haiku.

Certains des changements mentionnés dans ce rapport font partie des derniers développements du mois d'août, et étaient déjà présents dans la version R1 bêta 5 qui a été publiée début septembre 2024.

Les corrections de bugs sont appliquées sur la branche bêta 5 si elle est concernée, mais les nouveaux développements sont mis dans la branche principale et seront disponibles uniquement dans les « nighlty builds » (constructions journalières) puis dans la prochaine version, qui sera probablement étiquetée R1 bêta 6.

La version R1 est très attendue, mais la feuille de route comporte toujours environ 600 bugs et demandes d’amélioration. Jusqu’à ce qu’ils soient tous traités (corrigés, devenus obsolètes ou déplacés vers une version plus tardive), Haiku continue de publier des versions bêta.

Applications

Amélioration et corrections de textes de messages dans diverses applications (humdinger).

L’application Switcher — permettant de naviguer rapidement entre les différentes fenêtres et applications à l’aide d’un menu qui apparaît lorsque la souris se trouve sur les bords de l’écran — peut à nouveau être compilée. Cette application n’est pas terminée et non intégrée dans Haiku par défaut pour l’instant (nephele).

Dans les préférences de disposition clavier, des icônes avaient disparu de certains menus suite à un problème dans une modification précédente. Ces icônes sont maintenant de retour (jscipione).

Les réglages de polices de caractères de WebPositive peuvent faire des retours à la ligne dans le texte d’exemple utilisé pour visualiser la police choisie (correction récupérée depuis la fenêtre de réglage des polices du système, qui utilise une variante du même code). (nipos).

Le raccourci clavier « muet » permet d’alterner entre l’activation et la désactivation du son, au lieu de toujours passer en mode muet (korli).

Plusieurs applications pouvaient ouvrir leurs fenêtres en dehors de l’écran si leur dernière position enregistrée n’était pas bonne (après un changement de résolution d’écran par exemple). L’appel de la fonction MoveOnScreen() après la création d’une fenêtre permet de régler ce problème (korli, pinaraf, waddlesplash).

Icon-O-Matic ouvre ses dialogues de sélection de fichiers dans le dossier où se trouve l’icône en cours d’édition (nipos).

Il est possible de sélectionner une famille de polices directement dans FontDemo (nipos).

Améliorations du mode sombre

Modifications faites par nipos et nephele.

Depuis la version bêta 5 de Haiku, il est beaucoup plus simple de configurer un thème de couleurs dans Haiku (avec seulement 3 couleurs à sélectionner, les autres étant calculées automatiquement).

Cependant, toutes les applications et contrôles graphiques ne se comportent pas forcément très bien, en particulier si on choisit une couleur de fond de fenêtres sombre. Ce trimestre, on trouve donc des améliorations sur ColumnListView (contrôle permettant l’affichage de données en listes, en arbre et en colonnes), et dans les applications Debugger, Mail (en particulier les marqueurs de portions de message citées), WebPositive, ResEdit, FontDemo, Cortex, Sudoku et Tracker (les fenêtres de configuration des permissions de fichiers et de statut de copie de fichiers), ainsi que dans les préférences de disposition clavier (couleur des touches de clavier affichées), et de configuration des écrans et des écrans de veille. Ces applications utilisaient encore quelques couleurs codées « en dur » qui ne s’adaptaient pas automatiquement au thème choisi.

En outre, les formules de calcul utilisées pour générer le thème de couleurs ont été améliorées pour donner de meilleurs résultats dans le cas de couleurs sombres, assurant de conserver un bon contraste entre tous les éléments graphiques et une meilleure cohérence des couleurs.

AboutSystem

L’application AboutSystem donne quelques informations sur la machine (RAM, CPU), et surtout affiche les noms des développeurs et les messages de copyright et clauses de licences obligatoires de logiciels libres qui sont embarqués dans Haiku.

Correction d’un crash à cause d’une information de copyright mal enregistrée (madmax).

Mise à jour des crédits à l’occasion de la version Beta 5 : ajout des nouveaux membres de l’équipe, et passage dans la catégorie « anciens développeurs » de certaines personnes qui ne participent plus pour l’instant. (waddlesplash).

Débogueur

Haiku est fourni avec un débogueur graphique permettant d’investiguer facilement les problèmes dans les applications.

Waddlesplash a amélioré le désassembleur pour mieux décoder les adresses mémoire calculées à partir de la valeur d’un registre CPU. La correction a été remontée dans la bibliothèque tierce Zydis, utilisée pour le désassemblage.

Il a également modifié le code du Debugger pour ne pas essayer de télécharger des informations de debug lorsque l’outil est lancé en mode non-interactif (dans le cas d’une test suite automatisée par exemple). Plusieurs autres problèmes qui pouvaient causer un plantage du debugger ou un blocage dans un état invalide (avec l’application qui ne s’arrête jamais) ont été également traités.

DriveSetup

L’outil DriveSetup permet de modifier la table de partitions et de formater les partitions avec différents systèmes de fichiers.

Pour les partitions de type « Intel » (MBR), lorsqu’on crée une première partition, par défaut elle est marquée automatiquement comme partition active. Auparavant il fallait cocher une case pour cela, et de nombreux utilisateurs oubliaient de le faire, ce qui pouvait rendre le système impossible à démarrer (korli).

Dans certains messages, le nom des partitions n’était pas mis entre guillemets, ce qui pouvait prêter à confusion avec des noms de partitions choisis maladroitement (ou judicieusement, selon de quel point de vue on se place). Maintenant le nom de la partition est clairement identifiable dans le message (humdinger).

HaikuDepot

HaikuDepot est le frontal graphique du gestionnaire de paquets de Haiku. L’application est maintenue par apl et se compose d’une interface graphique native développée en C++ et d’un webservice développé en Java qui permet de stocker des métadonnées supplémentaires sur les paquets : captures d’écrans, notes et revues des utilisateurs, liste des paquets à mettre en avant.

  • Refactoring du « language model », de la gestion des chemins, de la récupération des données des paquets, de l’affichage des auteurs de paquets, de la gestion des notes données par les utilisateurs. (apl)
  • Fenêtre des conditions d’utilisation: correction de la couleur du texte, correction d’un crash si on clique dans la fenêtre avant que le texte soit chargé. (apl et jscipione)
  • Le bouton « Ouvrir » permettant de lancer une application installée ne fonctionnait pas toujours (apl).
  • Amélioration de la sélection d’un icône par défaut pour les paquets qui n’ont pas d’icône inclus (apl).

La liste de paquets mis en avant a été revue, un nouveau mainteneur (Michel) se charge de la tenir à jour avec des règles mieux définies : une sélection d’applications populaires (sur suggestion de participants aux forums de discussion) ainsi que des applications mises à jour récemment. Si vous utilisez Haiku, n’hésitez pas à passer un peu de temps à évaluer et noter les applications, peu de personnes le font et il est difficile d’exploiter les données de façon pertinente si beaucoup d’applications n’ont reçu qu’un seul vote.

Horloge

L’application horloge permet d’afficher l’heure (sans surprise). Elle propose diverses apparences de cadrans, peut être redimensionnée, et incrustée dans le bureau sous forme d’un replicant.

Un bug dans l’application conduisait à afficher une heure aléatoire (non initialisée) pendant quelques centièmes de secondes au démarrage avant de commencer à afficher l’heure courante (OscarL)

Les aiguilles de l’horloge étaient décalées de quelques pixels et ne pointaient pas précisément là ou elles devraient (dovsienko).

Tracker

Tracker est le gestionnaire de fichiers de Haiku. Il affiche le bureau et toutes les fenêtres de navigation et de recherche de fichiers. Il se distingue par son utilisation de la navigation dite « spatiale », où chaque dossier s’ouvre dans une fenêtre séparée dont la taille et la position à l’écran sont mémorisées.

jscipione continue son travail d’amélioration du Tracker (cela comporte de nombreux changements qui sont encore en gestation). Ce trimestre, les changements intégrés permettent :

  • la désactivation d’entrées du menu « Nouveau » lorsque les opérations ne sont pas disponibles,
  • la mise à jour dynamique de certains menus en fonction des opérations disponibles,
  • la préservation de la sélection après une opération de copie où de déplacement (avec quelques problèmes d’affichage corrigés au passage),
  • des corrections de bug sur le choix de couleurs utilisées dans la fenêtre « Ouvrir avec »,
  • la possibilité de créer un lien symbolique lorsqu’on fait un drag and drop depuis un dossier virtuel,
  • utilisation de la police de caractères « menu » de façon cohérente dans tous les menus.

Il a également travaillé sur des tâches de fond, sans changements visibles pour l’instant. Le code du Tracker provient de BeOS et est un peu vieillissant. Il est souvent nécessaire de faire beaucoup de nettoyage avant de pouvoir développer de nouvelles fonctionnalités sans casser autre chose. Cette fois-ci, on trouve entre autres une refonte de la gestion des raccourcis claviers, la fermeture automatique des fenêtres en double lors du passage en mode « navigation spatiale », et divers crashs liés à la gestion des menus popup.

humdinger a également travaillé sur le Tracker pour améliorer certains messages concernant la copie et la création de fichiers, pour les rendre plus faciles à traduire.

humdinger a également travaillé sur l’organisation du menu « templates » (affiché quand on fait un clic droit -> nouveau… et permettant de créer différents types de fichiers à partir de fichiers de référence). Ce menu peut maintenant être organisé en plusieurs sous-menus à l’aide d’une nouvelle option « New template folder », pour les personnes qui utilisent cette fonctionnalité avec de nombreux fichiers de référence au point d’avoir besoin de les organiser.

La fenêtre de requêtes (recherche de fichiers en fonction de leurs attributs étendus indexés dans le système de fichiers) permet maintenant d’afficher en temps réel les résultats lorsqu’on édite une requête. En outre, il est possible de filtrer les résultats pour afficher uniquement les fichiers contenus dans un répertoire donné (auparavant, on pouvait au mieux restreindre par volume disque). Ces changements ont été réalisés dans le cadre du Google Summer of Code par CalistoMathias, avec également une participation de jscipione, humdinger et waddleplash pour finaliser le travail.

Correction d’un crash du Tracker lors de changements de résolution d’écran (OscarL).

Terminal

Le Terminal permet d’exécuter des applications en ligne de commande.

Lors du changement de la taille de texte du Terminal, ce dernier ajuste le nombre de lignes et colonnes de texte visibles, au lieu de redimensionner sa fenêtre (nipos).

Prise en compte de la séquence d’échappement ANSI pour effacer l’historique de défilement (CodeForEvolution).

PowerStatus

L’application PowerStatus affiche des informations sur les batteries pour les ordinateurs portables.
sen a effectué plusieurs améliorations pour les systèmes avec plusieurs batteries:

  • Gestion de plusieurs emplacements pour batteries qui ne sont pas forcément tous utilisés,
  • Meilleur calcul des alertes de batterie faible,
  • Prise en compte de la déconnexion de batteries pendant le fonctionnement du système.

Outils en ligne de commande

La commande profile (qui permet d’analyser les performances d’autres applications et du système) peut maintenant afficher le nombre d’évènements qui n’ont pas pu être enregistrés par l’analyseur système (waddlesplash).

La commande package_repo update (utilisée pour mettre à jour un dépôt de paquets avec de nouveaux logiciels) peut maintenant fonctionner sans avoir accès au contenu complet des fichiers packages à inclure dans le dépôt (seuls les noms des paquets et quelques autres métadonnées sont réellement nécessaires).

La commande package_repo list dispose d’une option -f pour afficher le nom de fichiers correspondant aux paquets contenus dans un dépôt de paquets. Les fichiers peuvent ainsi être téléchargés facilement par un outil tiers. (waddlesplash)

Ces deux modifications sont utiles en particulier pour la ferme de build de HaikuPorts, qui souhaite héberger les fichiers dans des buckets S3 afin de simplifier l’infrastructure et de réduire les coûts de fonctionnement.

Amélioration du format de sortie de la commande launch_roster pour indiquer le statut des services et pas simplement leur nom (kallisti5 + waddlesplash).

Ajout dans strace du décodage des drapeaux de configurations de mutex (par exemple MUTEX_SHARED) (waddlesplash).

Serveurs

Les serveurs sont des applications fonctionnant en tâche de fond et qui implémentent une grande partie des fonctionnalités du système.

app_server

app_server est le serveur graphique qui se charge de l’affichage du bureau et des fenêtres.

madmax a travaillé sur la gestion des polices de caractères: correction de problèmes de verrouillage pour éviter des accès concurrents au gestionnaire de polices par plusieurs fils d’exécution, amélioration du traitement de l’ajout et du retrait de polices, et une optimisation pour éviter de scanner deux fois de suite les dossiers de polices au démarrage.

waddlesplash a complété ce changement en déplaçant une partie du code de gestion des polices pour éviter que d’autres parties de l’exécution soient bloquées par l’initialisation des polices, qui peut prendre beaucoup de temps (quelques secondes) au démarrage du système.

waddlesplash a corrigé un problème de calcul de délai d’expiration (probablement sans conséquence, découvert par hasard en investiguant un autre problème).

jscipione a corrigé un problème de rafraîchissement de l’affichage lorsque des fenêtres sont empilées, qui pouvait conduire à ne pas bien effacer la barre de titre dans certains cas.

Un clic simple sur le coin bas-droite de la fenêtre (coin de redimensionnement) déclenchait par erreur une minimisation de la fenêtre concernée (madmax).

media_server

Le media_server prend en charge les flux audio et vidéo et permet de router ces flux entre différentes applications ainsi que depuis et vers le matériel (cartes son, cartes d’acquisition vidéo, webcams…).

Travaux effectués par waddlesplash:

Correction de problèmes de calculs de temps dans le mixeur audio (problèmes découverts suite à l’amélioration de la détection d’erreurs dans BTimeSource, mentionné plus haut), et ajout de contrôles d’intégrité supplémentaires lors du démarrage du mixeur.

Cela corrige plusieurs bugs qui faisaient que le système n’avait pas de son au démarrage pendant un certain temps, avant que soudainement ça se mette à fonctionner.

D’autre part, des améliorations de performance sur la programmation des évènements, et des corrections de crash sur la connexion et déconnexion des nœuds média vers la sortie audio, et sur le nœud multi-audio avec certaines cartes sons qui exposent des types de contrôles invalides.

D’autres changements sont en cours pour pouvoir changer la sortie audio sans avoir besoin de redémarrer le serveur média, mais ça ne fonctionne pas encore.

registrar

Le registrar surveille quelles sont les applications déjà lancées et fournit divers services de communication entre applications, en particulier pour le presse-papier.

Ajout de vérification d’erreurs si un message de récupération du contenu du presse-papier échoue. Cela peut arriver si on a mis beaucoup de données dans le presse-papier et qu’il n’y a plus assez de mémoire disponible.

Des corrections du côté de la libbe permettent maintenant de gérer ces erreurs et de ne pas faire planter l’application concernée.

input_server

L’input_server` se charge des périphériques d’entrée (clavier, souris…)

Améliorations la validation des données des fichiers de configuration de souris, qui dans certains cas pouvaient empêcher la souris de fonctionner. Refonte de la gestion des accès concurrents à la liste des périphériques, pour supprimer des verrous inutiles et permettre les accès à la liste même si un thread de gestion d’un périphérique est bloqué. (madmax)

Les codes de touches pour la touche power et la touche \_ des claviers japonais s’étaient retrouvés assignées à des valeurs identiques (cela semble provenir tout droit de changements datant de BeOS, car ces touches non présentes sur un clavier de PC américain classiques sont assez mal documentées). La documentation a été mise à jour pour mieux expliquer quels sont les codes utilisés, et les différents pilotes (PS2, USB) ont été harmonisés pour utiliser les mêmes codes (x512 et PulkoMandy).

Le code power pourra également être utilisé par un pilote GPIO sur les machines où c’est nécessaire (souvent non compatibles PC).

net_server

Le net_server se charge de toutes les opérations liées au réseau.

mmlr a corrigé un problème dans le client DHCP, qui utilisait certaines variables sans les initialiser.

package_daemon

Le package_daemon vérifie la cohérence des paquets installés avec leurs dépendances, crée les dossiers de transactions et de sauvegarde de l’état passé du système, et se charge de lancer les scripts d’activation et de désactivation de paquets. L’accès au contenu des paquets est en revanche traité dans le noyau par le système de fichier packagefs.

Changement des couleurs des fenêtres « problèmes » et « résultats » qui apparaissent quand il y a des conflits ou d’autres problèmes de résolution de dépendances lors de l’activation des paquets (jscipione).

Kits

Les « kits » sont les composants de la bibliothèque standard de Haiku. Il s’agit principalement d’une convention de documentation et d’organisation de code source pour regrouper des fonctionnalités liées entre elles.

Interface

L’interface kit` permet l’ouverture de fenêtre et l’ajout de contrôles d’interface graphiques à l’intérieur de ces dernières.

Les objets BBitmap (permettant de stocker une image « raster ») avec le flag ACCEPT_VIEWS (permettant d’attacher une « vue" pour dessiner dans le bitmap ne sont plus automatiquement effacés. Cela permet de créer un bitmap à partir de données existantes, puis de dessiner autre chose par-dessus. Ce changement corrige un problème de compatibilité avec BeOS, et permet aussi d’utiliser cette méthode dans l’implémentation de WebKit pour Haiku (ZardShard).

Un changement précédent avait causé un problème de compatibilité d’API avec BeOS, qui déclenchait dans certains cas une récursion infinie et un crash lorsqu’on essayait de faire défiler une BListView par glisser-déplacer (par exemple dans l’application Wonderbrush). Waddlesplash a corrigé ce problème, et jscipione a également ajouté quelques améliorations sur la mise à jour des items sélectionnés lorsqu’on effectue cette opération.

Il est maintenant possible d’afficher des « checkmarks » (coche indiquant une option activée) sur les items de menus disposés en « matrice ». Habituellement les menus sont soit disposés sur une ligne, soit sur une colonne avec les items les un au-dessous des autres. Le mode « matrice » permet de s’affranchir de ces restrictions pour disposer les items librement avec du code applicatif.

Mise à jour en direct des couleurs dans les contrôles BSpinner, refonte de l’héritage des couleurs de la vue parente, et changement de la couleur de fond des boutons en mode sombre (jscipione).

Centrage vertical des dates dans BCalendarView (permettant d’afficher un calendrier) (nipos).

Factorisation de code dans BView pour l’envoi des données BShape vers app_server (x512).

La méthode de debug BPoint::PrintToStream affiche maintenant les coordonnées avec des décimales, permettant de détecter les points qui ne sont pas alignés avec la grille de pixels (ayu-ch).

Les boîtes de texte marquées comme « invalides » ont maintenant un fond rouge. La bordure rouge utilisée précédemment n’était pas assez visible (nephele).

Media

Le media kit permet aux applications de s’interfacer avec le media server, et fournit en plus une interface standardisée pour les codecs audio et vidéo.

Ajout d’assertions dans la classe BTimeSource pour empêcher les applications d’envoyer des temps avec un « drift » inférieur ou égal à 0. Le « drift" est utilisé comme multiplicateur et diviseur dans les calculs d’horloge, donc les valeurs inférieures ou égales à 0 causent des problèmes. Ceci a été mis en évidence par des corrections au niveau du noyau (voir plus loin dans la dépêche) et a ensuite permis de trouver encore d’autres problèmes en particulier dans les add-ons media (waddlesplash).

Locale

Le « locale » kit permet la traduction des applications, le formatage des nombres en fonction des préférences de chaque pays, la gestion des fuseaux horaires, et toutes les autres problématiques liées à l’internationalisation. Il s’agit principalement d’un enrobage de la bibliothèque ICU pour faciliter son utilisation avec les types natifs de Haiku.

Meilleure gestion des erreurs si la bibliothèque ICU ne peut pas être initialisée (waddlesplash).

Support

Le support kit contient diverses méthodes et classes utilitaires et génériques.

Contrôle d’intégrité des données lors de la déserialisation de BMessage (waddlesplash).

Correction d’incohérence de nommage de paramètres de fonction entre les fichiers .cpp et .h détectés par cppcheck (mt).

Pilotes de périphériques

Les pilotes sont indispensables pour assurer le fonctionnement de Haiku sur une grande variété de matériel. Certains sont développés à partir des spécifications du matériel spécifiquement pour Haiku, et d’autres ont été adaptés de travaux réalisés pour d’autres systèmes d’exploitation.

Le niveau de logging par défaut a été abaissé dans certains pilotes afin de ne pas trop polluer le journal système, en particulier:

  • Suppression de messages indiquant qu’aucun matériel compatible avec le pilote n’a été détecté,
  • Suppression de certains logs de debug dans les pilotes audio HDA et usb_audio.

Processeurs et économie d’énergie

Renommage du pilote intel_cstates en x86_cstates puisque les processeurs récents de chez AMD sont également pris en charge par ce pilote.

Appel à ce pilote à plus d’endroits dans le noyau pour mettre les processeurs en veille ou au ralenti quand ils ne sont pas utilisés.

Réseau

virtio_net

Le pilote virtio_net (carte réseau utilisée dans les machines virtuelles) implémente maintenant le « checksum offloading » pour les protocoles IP, TCP et UDP. En effet, dans le cas de ce pilote, les vérifications et calculs de sommes d’intégrité doivent être faits de toutes façons du côté de la machine hôte, il est donc inutile de les refaire dans la machine virtuelle.

Au passage, correction de quelques erreurs dans ce driver, et en particulier de problèmes de calcul de taille de buffers en mémoire.

broadcom750x

Utilisation des interruptions par messages (MSI) lorsque c’est nécessaire pour certaines versions du matériel (waddlesplash).

 vmxnet

Nouveau pilote porté depuis FreeBSD qui permet d’utiliser l’interface réseau paravirtualisée de VMWare (CodeForEvolution).

 Couches de compatibilité BSD

Haiku utilise des pilotes réseau venus de FreeBSD et OpenBSD, cela permet de mutualiser les ressources et de ne pas perdre du temps à réinventer la roue. Une couche de compatibilité permet de réutiliser les pilotes avec très peu de modification dans leur code et une simple recompilation.

Cette approche est également utilisée par d’autres systèmes d’exploitation comme RTEMS.

La couche de compatibilité a reçu des corrections de problèmes sur l’allocation de mémoire dédiée aux transferts DMA, ainsi qu’un problème sur le calcul de la taille d’un buffer de réception, qui empêchait les pilotes de fonctionner sur certains matériels.

 TCP

Waddlesplash a travaillé sur l’amélioration de l’implémentation de TCP :

  • Refonte de la gestion des ACK reçus dans le désordre,
  • Amélioration du code de débogage pour investiguer des crashs du noyau remontés par quelques utilisateurs,
  • Modification du code de mise à jour de la taille de fenêtre TCP pour éviter d’envoyer inutilement des changements de taille,
  • Correction de calcul du temps d’aller-retour,
  • Implémentation du redimensionnement dynamique de la fenêtre de réception (auparavant, elle était de taille fixe),
  • Ajout d’assertions à divers endroits dans la pile réseau pour détecter les problèmes à la source.

Ces améliorations permettent au trafic TCP d’être au moins 10 fois plus rapide, selon le type de connexion utilisé, et règle un problème de lenteur des téléchargements depuis Haiku qui était présent depuis assez longtemps.

 Ethernet

Du côté d’Ethernet, quelques améliorations et nettoyages sur le calcul de la MTU (taille maximale d’un paquet qui peut être envoyé). Pour l’instant, la découverte du « path MTU », la MTU du chemin complet entre deux machines, n’est pas encore disponible. Haiku ne s’autorise donc pas à envoyer du trafic plus large qu’une trame Ethernet standard, même si cela pourrait être possible pour le réseau local. Il reste donc une amélioration potentielle des performances réseau dans certains cas.

 UNIX domain sockets

Les sockets UNIX sont une méthode de communication entre processus standardisée par POSIX, utilisée surtout par des logiciels portés depuis d’autres systèmes (les applications natives pour Haiku utiliseront plus volontiers des BMessages ou des ports).

Amélioration et nettoyage du code autour de la gestion des données annexes dans les sockets UNIX. Correction de petites fuites de mémoire et d’un kernel panic qui pouvait se produire lors de la fermeture d’un socket (waddlesplash).

USB

Implémentation de l’USB « Super Speed Plus », qui permet des connexions USB avec un débit pouvant atteindre 10 gigabits par seconde (korli).

Refonte et consolidation du comptage de références dans la pile USB, ce qui met en évidence sous forme de kernel panic des cas où les choses ne sont pas bien faites. Ce n’est pas agréable, mais c’est tout de même mieux qu’une corruption mémoire difficile à investiguer (waddleplash).

Décodage des descripteurs USB Audio v2 dans la commande listusb, mais pas encore dans le pilote usb_audio qui implémente pour l’instant seulement la version 1 (gscrain).

PCI

Correction de problèmes d’accès au bus PCI sur les machines équipées de ACPI. Suite à une modification précédente, les accès sur 8 ou 16 bits étaient convertis en accès sur 32 bits, mais ce n’est pas le comportement attendu. En particulier, certains registres effacent automatiquement leur contenu lorsqu’ils sont lus, ou bien les données accessibles en lecture et en écriture ne sont pas les mêmes. (PulkoMandy)

Il n’est donc pas possible de lire une valeur sur 32 bits, remplacer 8 bits, et réécrire 32 bits pour simuler une écriture sur 8 bits dans un registre.

Les accès sont à nouveau traités correctement, ce qui permet à Haiku de fonctionner à nouveau normalement sur les machines concernées par ce type d’accès au bus PCI (cela dépend du matériel et des pilotes).

Périphériques de stockage

Petites améliorations de performances dans le pilote NVMe (waddlesplash).

Modification du pilote AHCI/SATA (waddlesplash) :
- Suppression de code dupliqué pour utiliser à la place des fonctions communes partagées avec d’autres pilotes,
- Correction d’une confusion entre adresses 32 et 64 bits qui empêchait de démarrer la version 32
bits de Haiku sur certains systèmes avec plus de 4Gio de RAM.

La pile SCSI prend mieux en compte les restrictions sur les adresses DMA. Chaque pilote de périphérique qui implémente SCSI peut indiquer ce qu’il est capable de faire, et la pile SCSI fait en sorte que les demandes de transferts DMA respectent ces contraintes, ce qui évite aux pilotes de devoir découper par eux-mêmes les transferts en unités qu’ils sont capables de traiter (waddlesplash).

ACPI

ACPI est une interface standardisée avec le matériel. Elle permet la gestion d’énergie (extinction de la machine par exemple), ainsi que l’accès à du matériel annexe tels que les boutons on/off, la détection de rabat de l’écran sur un PC portable, le contrôle des LEDs indicatrices ; ainsi que la découverte de matériel non connecté sur le bus PCI (comme certains modules eMMC dans des tablettes et ordinateurs à bas coût).

La spécification étant assez complexe, la bibliothèque ACPICA est utilisée pour implémenter les bases de ACPI. Ensuite, des pilotes dédiés permettent d’exposer chaque périphérique ACPI.

Mise à jour de ACPICA avec la dernière version publiée par Intel (publiée en mars), et un peu de nettoyage afin de pouvoir intégrer quelques patchs dans la version upstream de ACPICA (PulkoMandy).

Ajustement du pilote ACPI pour mapper sa mémoire physique en « write back » au lieu de désactiver complètement le cache. C’est nécessaire sur ARM64, car le cache permet d’intercepter les accès mémoire non alignés. Correction de problèmes liés au fait que la même zone de mémoire physique pouvait être mappée plusieurs fois avec des configurations différentes, ce qui est impossible (déclenche une « machine check exception ») (oanderso).

Graphiques

Avancées sur la prise en charge des cartes graphiques Intel de générations Tiger Lake, Ice Lake et Gemini Lake (ttmfx, ilzu, PulkoMandy). L’utilisation de ces cartes graphiques reste assez limité, sans accélération matérielle et sans possibilité d’utiliser plusieurs écrans pour l’instant.

virtio

Les pilotes virtio permettent l’utilisation de matériel virtuel défini pour tirer le meilleur parti des machines virtuelles. Plutôt que de copier le fonctionnement d’un matériel existant, l’interface peut être conçue pour rendre le travail plus simple aussi bien pour l’hôte que pour le système virtualisé.

Correction de problèmes dans l’allocation des files de messages virtio et amélioration de la gestion des erreurs (mmlr).

Vérification de l’état du périphérique après une réinitialisation, et correction d’un accès mémoire hors limite dans le pilote virtio_pci (korli).

PS/2

Les ports PS/2 ont disparu de la plupart des machines depuis de nombreuses années, mais le protocole est encore utilisé pour les claviers des ordinateurs portables ainsi que pour certains touchpads. Ces derniers utilisent de nombreuses extensions peu standardisées et mal documentées pour offrir des fonctions avancées qui n’existaient pas à l’époque des souris à deux boutons.

Le driver reçoit ce trimestre une refonte de la gestion des verrous entre ses différents composants, pour essayer de régler quelques problèmes de synchronisation (waddlesplash).

Systèmes de fichiers

ram_disk et ramfs

ram_disk est un périphérique bloc (block device) qui stocke ses données en RAM (non persistante au redémarrage). Il peut être formaté avec n’importe quel système de fichier.

ramfs est un système de fichiers qui stocke ses données en RAM, sans passer par un block device. Cela permet de meilleures performances (pas besoin de journalisation par exemple), une meilleure intégration avec le cache de fichiers (la mémoire peut être partagée directement entre ramfs et le cache), et de s’affranchir des limites habituelles des périphériques de bloc (par exemple: une taille fixe connue lors de la création du système de fichiers).

Un utilisateur a remonté un problème de compatibilité avec POSIX. Si on utilise mmap() sur un fichier stocké dans un ramfs, et que la taille du fichier n’est pas un multiple de la taille des pages de mémoire, la fin de la dernière page pouvait contenir des données aléatoires. Selon la spécification POSIX, il faut que cette zone soit remplie avec des 0, et le compilateur clang dépend de ce comportement pour implémenter une lecture rapide des fichiers sources compilés.

Le problème a été corrigé, avec au passage une commonalisation de code entre ramfs et ram_disk, de petits ajustements de performances, et un peu de nettoyage.

Enfin, la priorité des allocations mémoires de ces deux pilotes a été abaissée, ce qui permet d’éviter un gel du système s’il n’y a plus de mémoire disponible.

Le pilote ramfs continue d’être stabilisé, quelques problèmes qui pouvaient encore causer des kernel panic ont été corrigés.

packagefs

packagefs est un système de fichier virtuel qui expose le contenu de fichiers de packages au format hpkg. Des paquets peuvent être ajoutés et supprimés pendant le fonctionnement du système, et il n’est pas nécessaire d’extraire leurs données sur disque.

Plusieurs améliorations faites par waddlesplash :

  • Ajout de vérifications de la bonne utilisation de verrous entre différents threads et corrections de problèmes mineurs qu’elles ont mis en évidence,
  • Amélioration du message d’erreur si on essaie d’activer deux paquets qui entrent en conflit.

Un reproche qui est souvent fait au packagefs est d’avoir augmenté les besoins en RAM de Haiku, en effet, depuis la version Beta 1 de Haiku, la configuration mémoire minimum recommandée est de 384Mio de RAM, alors que les versions précédentes se contentaient de 128Mio.

  • Utilisation d’object_cache` (un allocateur mémoire pour des objets qui font tous la même taille) dans différents endroits de packagefs pour réduire sa consommation de mémoire,
  • Utilisation de listes chaînées simples au lieu de listes chaînées doubles là où ça ne pose pas de problème de performances,
  • Suppression de champs constants dans certaines classes,
  • « inlining » des compteurs de références pour rendre les structures de données plus compactes,
  • Réorganisation des structures pour réduire le padding,
  • Retrait des « dépôts d’objets » dans les arènes d'allocation,
  • Découpage des allocations en plusieurs zones distinctes,
  • Utilisation de verrous moins fins (par exemple, avoir un seul verrou pour tout un dossier au lieu de un par fichier),
  • Utilisation d’un « bump allocator » pour les objets à courte durée de vie.

La réduction de consommation mémoire avec ces changements est de près de 20%, soit environ 15Mio sur une installation de référence. En effet, un gain de quelques octets sur le stockage d’informations sur un fichier est multiplié par plusieurs milliers de fichiers présents sur le disque, ce qui fait que chaque petite optimisation est intéressante. Cependant, les investigations ont aussi permis de découvrir d’autres problèmes encore plus importants qui n’étaient pas directement liés au packagefs, on en reparle un peu plus loin.

Un autre changement a été fait par waddlesplash, non seulement pour packagefs mais aussi pour d’autres endroits où le même code était utilisé : La fonction pour calculer un hash de chaîne de caractères utilisait un algorithme obsolète. Elle a été remplacée par hashdjb2 qui génère moins de collisions.

FAT

FAT est un système de fichier développé par Microsoft. Il est utilisé en particulier sur les cartes SD et les clés USB, ainsi que pour les partitions systèmes EFI. Bien que sa conception soit quelque peu obsolète, il reste donc indispensable.

Le pilote FAT de Haiku, qui provenait tout droit d’un code source publié par Be, a été remplacé dans la version beta 5 par une nouvelle version basée sur le code de FreeBSD. Ce nouveau pilote reçoit depuis des améliorations régulières par Jim906, le développeur qui s’est chargé du portage du code de FreeBSD.

Ce trimestre, le pilote reçoit des corrections sur l’initialisation des « media bytes » dans l’en-tête des partitions, des améliorations de performances pour réduire le temps nécessaire au montage d’une partition FAT, ainsi qu’une meilleure gestion des erreurs dans le traitement des noms de volumes. Il est également possible de monter les volumes FAT de taille supérieure à 2TiO.

BFS

BFS est le système de fichier hérité de BeOS et utilisé pour les partitions natives de Haiku. Il propose une très bonne implémentation des attributs étendus (sans limite de taille, et typés) et permet en plus d’exécuter des requêtes sur ces attributs pour localiser très rapidement les fichiers répondant à certains critères.

L’implémentation du système de fichier BFS est assez mûre et reçoit habituellement peu d’évolutions. Cependant, il reste toujours des possibilités d’améliorer les performances.

C’est le cas de la fonction de recherche de blocs libres. Les blocs sont chacun représentés par un bit dans une structure indiquant s’ils sont disponibles ou pas. La recherche de blocs libres se faisait bit à bit, mais il est possible de gagner beaucoup de temps en testant 64 bits d’un coup pour savoir tout de suite qu’ils représentent tous des blocs occupés, et passer directement aux 64 bits suivants. Cela améliore les performances de la création et du redimensionnement de fichier, en particulier sur les architectures RISC-V (waddlesplash).

Query parser

Plusieurs systèmes de fichiers conçus pour BeOS ou Haiku (bfs, ramfs, et packagefs) permettent l’utilisation d’attributs indexés par le système de fichiers qui permettent d’effectuer des requêtes pour localiser des fichiers comme dans une base de données.

Depuis la version beta 5 de Haiku, ces 3 systèmes de fichiers partagent le code utilisé pour parser une requête (envoyée sous forme de texte) et la convertir en une opération de recherche exécutable.

Ce parser pouvait dans certains cas (requêtes trop complexes) déclencher volontairement un kernel panic. Celui-ci a été remplacé par une « simple » erreur, remontée à l’application qui a déclenché la requête. L’application aura la charge de remonter cette erreur à l’utilisateur, et de l’inviter à simplifier sa demande.

block_cache

Le cache de blocs, comme son nom l’indique, stocke en mémoire RAM une copie de certains blocs des systèmes de fichiers. Cela permet d’accélérer les opérations bas niveau sur le système de fichier, en particulier pour mettre en cache des structures internes du disque. Il complète le file_cache, qui lui se trouve à un niveau plus haut, et met en cache uniquement le contenu des fichiers lus et écrits par les applications.

Le seul changement notable sur le block_cache est le retrait de paramètres inutilisés dans certaines fonctions, afin de simplifier le code (waddlesplash).

kernel

Une correction de bug sur le blocage des threads avec timeout (par exemple, l’attente d’un mutex ou d’un sémaphore avec un délai maximum): dans certains cas, une fonction pouvait retourner B_TIMED_OUT pour d’autres raisons que l’expiration du timer. Ce n’était pas traité correctement, et le noyau supposait que le timeout avait expiré, alors qu’il s’agissait d’autre chose. Des vérifications supplémentaires permettent de traiter ce cas correctement.

Correction de problème sur la programmation des timeouts « absolus temps-réel ». Comme leur nom l’indique, ils référencent l’horloge « real time » (qui essaie de suivre l’heure et la date « réelle », par opposition à l’horloge système qui est basée sur l’uptime de la machine, mais garantit de ne jamais faire de saut ou revenir en arrière). Ces timers ne fonctionnaient pas du tout (ou alors, seulement sur un coup de chance), et restaient probablement bloqués pendant une durée beaucoup plus longue que demandé. Au passage, nettoyage du code de gestion des timers.

Dans le code de gestion des interruptions: ajout d’assertions pour investiguer un bug dans les addons vmware ou virtualbox.

Correction d’un bug dans l’implémentation de kqueue qui produisait un blocage au démarrage de la libevent (qui utilise maintenant kqueue pour Haiku).

Des petites améliorations de performances: sur l’allocateur mémoire du noyau, sur l’utilisation de verrous dans la gestion de la mémoire virtuelle, des fuites de mémoire dans l’allocation de page, des améliorations sur la détection de références devenues invalides (jpelczar + waddlesplash).

Le script de link du noyau refuse maintenant les sections inconnues avec un message d’erreur, au lieu de simplement les ignorer (korli).

Correction du décompte du temps CPU utilisé par le thread en cours d’exécution, pour donner des résultats plus fiables dans les applications qui affichent l’utilisation CPU (waddlesplash).

Refactorisation du décompte du temps d’exécution des appels systèmes. Seul le temps passé dans l’exécution du syscall est prise en compte, sans mesurer la mise en place d’un appel système et du retour vers l’espace utilisateur (qui ne peuvent de toutes façons pas être mesurées de façon fiable depuis le noyau). Cela rend l’affichage des durées d’exécution dans strace plus facile à interpréter (waddlesplash).

Réduction de la taille maximale des tampons mémoire pour stocker des dirent à 8Kio. La plupart des applications n’utilisent pas un tampon aussi large, et les quelques-unes qui le faisaient ont été modifiées pour réduire la taille. Cette réduction permet d’utiliser un allocateur spécialisé beaucoup plus rapide, ce qui devrait compenser les rares cas où le tampon est trop petit pour récupérer tout le contenu d’un dossier en une seule fois (waddlesplash).

Correction de plusieurs problèmes dans le système de gestion des ressources faibles (qui essaie de libérer de la mémoire quand il n’y en a plus assez de disponible). Dans certains cas, le système finit par geler ou déclencher un kernel panic, alors qu’il devrait toujours être possible de refuser des demandes d’allocation mémoire venant de l’espace utilisateur, et de conserver suffisamment de mémoire libre pour au moins afficher proprement une erreur.

Amélioration de la gestion des mutex (exclusions mutuelles entre threads):

  • Ajout d’assertions pour détecter des cas de réveil d’un thread qui ne devrait pas l’être.
  • Correction d’un problème introduit récemment et investigué à l’aide de ces nouvelles assertions.
  • L’ABI des locks est identiques entre les builds du kernel en version debug ou release, ce qui permet de ne pas avoir besoin de recompiler tous les pilotes dans le même mode que le kernel. Les pilotes compilés en mode release vont déclencher une erreur de symbole manquant si on essaie de les utiliser avec un noyau en mode debug, dans l’autre sens, il n’y a pas de problème. Auparavant, dans les deux cas on obtenait des crashes ou un gel complet du système, difficile à investiguer et faisant perdre du temps.
  • Ajout d’assertions dans plusieurs cas pour détecter les utilisations incorrectes des rw-locks. Certaines activées par défaut, et d’autres uniquement sur demande à la compilation du noyau en raison de coût de vérification trop importants.
  • Correction de mauvaises utilisations des rwlocks ainsi détectées.

Généralisation de l’utilisation de fonctions utilitaires partagées pour la conversion des timespec en durées en microsecondes. Cela permet aux fonctions concernées (entre autres kqueue) de bénéficier de contrôles de validité supplémentaires (waddlesplash).

Ajout d’informations de debug supplémentaires dans la sortie de la commande slab_object du debugger du noyau.

Réactivation de la calibration du TSC à partir d’informations du CPUID lorsque Haiku s’exécute dans un hyperviseur, comme c’était déjà le cas lorsqu’il s’exécute directement sur une machine physique. Le TSC est un timer interne du CPU qui permet des mesures de temps très rapides (une seule instruction CPU) mais dans une échelle de temps arbitraire qu’il faut corréler avec le « vrai » temps. Cela peut être fait soit à l’aide d’une mesure empirique (méthode historique), soit à l’aide d’informations sur cette horloge disponibles dans les informations retournées par l’instruction CPUID.

Affichage de plus de fonctionnalités du CPU reconnues dans les logs de debug pour les processeurs x86 (korli).

Ajout d’un raccourci clavier (Control+D) pour quitter le debugger noyau et reprendre l’exécution normale si possible (équivalent à la commande continue ou co) (mmlr).

Le chargement des pilotes de périphériques se fait en priorité depuis les dossiers non-packaged avant de rechercher les fichiers dans les paquets logiciels, ce qui permet de tester facilement une version modifiée d’un pilote - sauf si les dossiers non-packaged sont désactivés dans la configuration du noyau (korli).

VFS

Le VFS (virtual file system) est le composant de Haiku qui gère l’accès aux fichiers. Il fait l’intermédiaire entre les appels systèmes liés aux fichiers (open, read, write…) et les systèmes de fichiers eux-mêmes. Il implémente autant que possible ce qui peut être mis en commun entre tous les systèmes de fichiers: résolution de chemins relatifs, vérification de permissions…

Cela rend plus facile l’écriture d’un nouveau système de fichiers, qui peut alors se concentrer sur les aspects bas niveau et la gestion de ses structures de données.

Ajout de vérifications d’intégrités supplémentaires dans le VFS pour détecter des bugs dans les systèmes de fichiers le plus rapidement possible, au lieu d’obtenir un crash du noyau difficile à investiguer un peu plus tard.

Retrait d’un scan du bus SCSI et des pilotes associés par le device manager pour réduire un peu le temps de démarrage.

Correction d’un gros problème dans l’API du noyau IORequest qui aboutissait à une confusion entre la taille totale d’une requête et l’offset de la dernière donnée transférée (les transferts ne commençant pas forcément à l’offset 0). La conséquence était l’écrasement de données dans le cache de fichiers, déclenchant des crashes du noyau avec des messages d’erreur incompréhensibles à propos des structures de pages. Correction d’un problème de calcul d’offset qui faisait que certaines opérations étaient considérées comme réussies, alors qu’il y avait en fait une erreur.

Correction de problèmes de décomptage de références et de gestion du cache à l’interface entre ramfs et VFS, mis en évidence lors du travail de portage de Firefox.

Ajout d’une acquisition de référence sur un vnode qui manquait dans le cache de fichiers (waddlesplash).

Améliorations du cache d'entrées, dont en particulier la mise en cache du hash des noms de fichiers, pour éviter des comparaisons de chaînes de caractères inutiles.

Gestion de la mémoire

La gestion de la mémoire virtuelle est une des tâches essentielles d’un système d’exploitation. Elle garantit l’isolation entre les différents processus, permet d’utiliser la mémoire physique le mieux possible (éventuellement en déplaçant certaines allocations peu utilisées vers un espace d’échange sur disque), et permet aussi aux différents processus de se partager des données.

Il s’agit également d’un composant très sollicité, et dont les performances impactent beaucoup le comportement du système. Une mauvaise gestion de la mémoire peut fortement ralentir le système ou le rendre instable.

Ajout d’assertions dans le code gérant les pages de mémoire, pour essayer d’intercepter ce type de correction plus rapidement si elles se reproduisent.

Dans l’arbre des areas globales : ajout d’assertions pour détecter les identifiants d’areas dupliqués (chaque area doit bien sûr avoir un identifiant unique).

Implémentation de PAT (Page Attribute Table) pour les processeurs x86. Les PAT permettent de configurer des zones de mémoires qui peuvent ou ne peuvent pas être mises en cache (complètement ou en write-through). Elles remplacent les MTRR en permettant un contrôle plus fin et plus flexible. Au passage, nettoyage de l’implémentation des MTRR (préservée pour les processeurs plus anciens incompatibles avec PAT), ajout de nouvelles commandes dans le debugger noyau. Renommage des constantes B_MTR_* pour indiquer précisément leur rôle indépendamment des dénominations utilisées dans les registres MTRR qui ne sont pas très claires (mmlr).

Lorsque le système utilise PAT, ajout d’assertions pour détecter les tentatives d’accéder à la même zone de mémoire physique avec des configurations de cache différentes. Elles ne sont pas activées lorqu'on utilise les MTRR, car ces dernières ne permettent pas une configuration aussi fine (waddlesplash).

Ajout d’informations supplémentaire dans le message de kernel panic indiquant qu’une page devrait être libre mais qu’elle ne l’est pas. Modification de la commande page du debugger noyau pour récupérer la liste des espaces d’adressage depuis les structures du kernel plutôt que d’itérer sur tout l’espace d’adressage (ce qui pouvait fonctionner sur un espace 32 bit, mais pas en 64 bit).

Correction du code de « guarded heap » du noyau qui ne compilait plus. Il s’agit d’un allocateur mémoire plus lent mais avec de nombreuses vérifications d’intégrité pour détecter les débordements de tampons, double free, et autres problèmes de gestion de la mémoire dans le noyau (kallisti5).

Le fichier swap est automatiquement supprimé, et l’espace disque libéré, lors de la désactivation de la swap. Auparavant, un redémarrage était nécessaire (waddlesplash).

Correction d’un problème dans l’allocation de mémoire « early boot » (avant que l’allocation normale soit mise en place), qui empêchait le démarrage sur les systèmes pouvant gérer de grandes quantités de mémoire (plusieurs centaines de Gio) (waddlesplash).

libroot

La libroot regroupe tous les composants de la librairie standard C (parfois découpée en libc, libm et libpthread pour d’autres systèmes). Elle contient en plus un certain nombre d’extensions spécifiques à Haiku et à BeOS.

Changements effectués par waddlesplash, sauf mentions spécifiques:

Nettoyage de code dans la classe WeakReferenceable, une classe de comptage de références intrusive qui autorise les références "faibles".

Correction de problèmes dans le code d’interfaçage avec ICU pour la conversion de dates (nipos et waddlesplash).

libnetwork

Nettoyage de code de compatibilité avec BeOS dans la libnetwork, pour faire en sorte qu’il ne soit plus du tout compilé sur les architectures n’offrant pas de compatibilité avec BeOS.

Compatibilité POSIX

Implémentation minimale de mknod et mknodat dans le seul cas spécifié par POSIX, qui permet de réaliser une opération équivalente à mkfifo. La gestion des devices dans Haiku est très différente de celle utilisée traditionellement par UNIX, et ne se prête pas à l’implémentation des autres utilisations de ces fonctions.

Rectification de l’implémentation des fonctions *at (par exemple linkat) qui permettent de réaliser une opération à partir d’un descripteur de fichier au lieu d’un path. Dans la libroot, ces fonctions envoyaient la valeur -1 aux appels systèmes pour implémenter AT_FDCWD. La valeur de AT_FDCWD a été modifiée pour choisir autre chose que -1 (qui est souvent utilisé pour indiquer une erreur dans le code de retour d’autres fonctions). Les appels systèmes acceptent pour l’instant les valeurs -1 et AT_FDCWD, mais rejettent maintenant toutes les autres valeurs négatives.

Remplacement d’une partie du code de gestion des flux d’entrée-sortie par la version de la glibc. La bibliothèque libroot est un patchwork d’implémentations provenant de la glibc, de musl, et de divers BSD, un objectif à terme est d’essayer de se rapprocher d’une de ces implémentations, mais on ne sait pas encore trop de laquelle. En tout cas, le code des I/O provient majoritairement de la glibc afin d’être très compatible avec ce qui était utilisé dans BeOS.

La fonction gmtime retourne une struct tm avec le champ tm_zone contenant la chaîne "GMT" (waddlesplash).

Correction de la conversion des "surrogate pairs" dans la fonction mbrtowc.

Mise en conformité de l’implémentation des threads avec POSIX :

  • Ajustement de code d’erreurs retournés par les fonctions
  • Suppression de la possibilité de retourner EINTR depuis un rwlock
  • Correction de deadlocks dans les barriers
  • Correction de plusieurs problèmes dans l’implémentation des sémaphores anonymes.

Mise en place systématique de l’utilisation de _DEFAULT_SOURCE pour protéger les extensions à la norme POSIX, ce qui permet de les activer automatiquement via l’inclusion de features.h lorsque c’est possible.

Nettoyage de quelques fichiers d’en-tête, dont en particulier <sys/select.h>, pour éviter de polluer l’espace global avec des macros et des définitions en double (waddlesplash).

Prise en compte correcte du drapeau O_NONBLOCK lors de l’ouverture d’un FIFO (korli).

runtime_loader

Le runtime_loader est le composant responsable du chargement en mémoire des exécutables et du lancement de nouveaux processus. Il réalise la résolution des dépendances et la recherche des bibliothèques partagées nécessaires pour l’exécution d’un programme.

Il reçoit des évolutions suite au portage d’applications complexes venues de Linux, qui nécessitent souvent plusieurs dizaines de bibliothèques partagées.

Correction de problèmes détectés en testant un portage expérimental et instable de Firefox: crash du runtime_loader dans certains cas si on charge une bibliothèque (via dlopen ou load_add_on) dont il manque des dépendances.

Retrait de l’option -fno-builtin dans les drapeaux de compilation du runtime_loader, comme cela avait déjà été fait pour la majorité de la libroot. Cela permet à gcc de remplacer des appels à des fonctions standardisées par une implémentation inline plus performante (waddlesplash).

Outils de debug

Développement d’outils pour enregistrer ce qu’il se passe pendant le démarrage du système et détecter d’éventuels problèmes de latence, de 'lock contention', etc. Au passage, correction de divers problèmes liés à ces outils : les barres de défilement de DebugAnalyzer, les permissions noyau dans transfer_area, etc.

Amélioration de la remontée des valeurs de retour des appels systèmes vers strace sur les plateformes x86 32-bit.

Pour terminer, un changement réalisé par mmlr : amélioration de l’allocateur mémoire "guarded heap" pour le rendre utilisable plus facilement, y compris comme allocateur pour tout le système. Cet allocateur permet de détecter les accès au-delà de la fin d’une zone mémoire allouée avec malloc(), ainsi que les accès à de la mémoire déjà libérée, mais au prix d’une consommation mémoire nettement plus élevée qu’un allocateur classique. La disponibilité d’un espace d’adressage de 64 bits permet de limiter les cas où une adresse mémoire est initialement utilisée pour une allocation, puis libérée et allouée à nouveau pour autre chose.

Un problème de gestion d’erreur dans l’interfaçage entre le Debugger et le noyau pouvait conduire à un gel complet du système dans certains cas de plantage du debug_server, en particulier s’il n’y a plus assez de mémoire RAM disponible.

Bootloader

Ajout d’une vérification manquante pour prendre en compte l’option « BlockedEntries » dans le bootloader. Cette option s’appelait précédemment « EntriesBlacklist » mais a été renommée pour utiliser un terme non entaché de racisme. L’ancien nom continue de fonctionner pour ne pas casser les installations existantes, mais n’est plus documenté.

Augmentation de la taille maximum autorisée pour les allocations « standard » sur la pile. L’allocateur mémoire du bootloader traite séparément les allocations de grande taille, mais ces allocations ne sont pas correctement libérées lors du transfert de contrôle vers le noyau, en particulier sur les machines utilisant un BIOS non EFI. Pour l’instant, une correction complète du problème semble compliquée à mettre en place, mais la modification permet de libérer de la mémoire allouée pour l’accès au packagefs (le bootloader a besoin d’y accéder pour trouver le noyau, qui est stocké dans un paquet). Ce changement permet de libérer plusieurs dizaines de Mio de mémoire, et complète les changements mentionnés plus haut sur la gestion des paquets après démarrage. Il est possible de configurer Haiku pour fonctionner avec moins de 100Mio de mémoire (waddlesplash).

Réparation de la ré-initialisation des ports série sur le bootloader EFI. Le port série est utilisé à des fins de debug, mais il peut être accédé de plusieurs façons différentes (en adressant directement le matériel, ou bien via des services EFI dédiés). Le bootloader doit passer d’une méthode à l’autre à différentes étapes du démarrage: accès direct au port physique dans les premières étapes (en détectant s’il est bien présent à une adresse standard), accès via les services EFI une fois ceux-ci initialisés, puis à nouveau accès direct au matériel après l’arrêt des services EFI pour la dernière étape de passage de contrôle au noyau (cette fois-ci à une adresse qui peut être configurée dans les options du bootloader et du noyau). Ce fonctionnement ne s’insère pas forcément très bien dans la logique du bootloader, qui n’avait à l’origine pas été conçu pour une gestion aussi complexe des entrées-sorties (VoloDroid).

Réduction de la quantité de logs liés à la mise en place de SMP (gestion de plusieurs processeurs) dans le bootloader pour BIOS (waddlesplash).

Le menu de démarrage affiche la version (numéro 'hrev') du paquet système correspondant à chaque point de restauration disponible, ce qui facilite l’identification des états qui correspondent à un changement de version du système, et pas une simple installation, désinstallation ou mise à jour de paquets logiciels (waddlesplash).

Documentation

Haiku Book

Le « Haiku Book » est un projet de documentation des APIs publiques de Haiku. Il doit à terme remplacer le « Be Book », qui documente les APIs de BeOS, mais ne peut pas être mis à jour à cause de se license CC BY-NC-ND. Actuellement, il faut jongler entre ces deux documentations.

La documentation de B_INFINITE_TIMEOUT (constante permettant d’indiquer à certaines fonctions qu’on veut les exécuter sans timeout, et attendre indéfiniment) a été mise à jour pour indiquer explicitement que sa valeur numérique est INT64_MAX (waddlesplash).

Correction de fautes de frappe dans la documentation des API liées aux entrées clavier (drea233).

Haiku Interface Guidelines

Ce document présente les bonnes pratiques et conventions pour la conception d’interfaces graphiques fonctionnant avec Haiku.

Ajout d’une section sur la gestion des fichiers récemment utilisés et la façon dont ils peuvent être exposés aux utilisateurs.

Wiki et documentation interne

Le wiki contient des informations utiles aux développeurs de Haiku.

La documentation « interne" documente le fonctionnement de Haiku en s’adressant principalement aux contributeurs du système, par opposition aux personnes qui souhaitent seulement développer ou porter des applications.

Mise à jour de la page « release cookbook » indiquant toutes les étapes à suivre lors de la publication d’une version de Haiku.

Notes d’administration système : mise à jour des instructions pour instancier des machines Google Cloud Platform (kallisti5).

Système de build, environnement de compilation

La compilation d’un système d’exploitation complet n’est pas chose facile. D’autant plus pour Haiku, qui présente les particularités suivantes:

  • Utilisation de deux versions de gcc (gcc 2.95.3 et gcc 13) pour la version 32 bit de Haiku, afin d’assurer la compatibilité binaire avec BeOS,
  • Possibilité de compilation croisée depuis Linux, Mac OS et d’autres systèmes, ou depuis un hôte Haiku,
  • Compilation d’outils pour la machine hôte de la compilation croisée, avec si nécessaire une couche de compatibilité permettant d’écrire ces outils en utilisant des API et fonctionnalités spécifiques à Haiku,
  • Possibilité de compiler des applications pour un système hôte existant (une autre version de Haiku) à des fins de test,
  • Compilation d’un système complet (noyau, bibliothèques, applications, image disque) en une seule opération.

Pour ces raisons, l’utilisation d’un système de build haut niveau (CMake, Meson…) s’avère plutôt complexe. L’utilisation de make ou de ninja directement serait de trop bas niveau. Le choix de Haiku est donc d’utiliser l’outil jam, qui est malheureusement assez peu populaire et tombé à l’abandon dans sa version originale. Haiku maintient un fork de jam qui est concurrent de ceux maintenus par Boost et par Freetype.

Reformatage des fichiers Jamfile pour lister une seule cible par ligne au lieu de les rassembler, cela facilite les rebase et résolutions de conflits (x512).

Mise à jour de paquets en préparation pour la version beta 5: OpenSSL 3, Python 3.10, et autres mises à jour diverses (PulkoMandy, waddlesplash, kallisti5).

Ajout de l’inclusion de <features.h> dans <sched.h>. Le fichier d’en-tête features.h configure la visibilité des extensions GNU et BSD aux fichiers d’include standards C et POSIX, en fonction d’options de ligne de commande du compilateur. L’inclusion de ce fichier permet d’utiliser facilement et par défaut ces extensions (PulkoMandy).

Mise à jour des marque-pages fournis par défaut avec le navigateur WebPositive (waddlesplash).

Ajout des en-têtes de la bibliothèque linprog dans le paquet haiku_devel. Ces en-têtes sont nécessaires pour les applications associées au système de layout d’interfaces graphiques ALM (korli).

Correction de fautes de frappe dans des commentaires (jmairboeck) et d’un problème de compatibilité C89 dans un en-tête système (waddlesplash).

La taille des images « nightly build » de Haiku est maintenant de 650 Mo, ce qui laisse un peu plus de place disponible pour les utiliser et créer quelques fichiers (jscipione).

Diverses corrections pour une nouvelle fois essayer de faire fonctionner la compilation de Haiku avec Clang (waddlesplash, oanderso). Les choses en sont toujours au même point depuis plusieurs années, avec des corrections de temps en temps mais quelques parties du système qui ne fonctionnent toujours pas correctement.

La compilation du profil « nightly » n’a plus besoin de générer le paquet haiku_source contenant le code source de Haiku. Ce paquet est inclus uniquement dans les images de releases (pour faciliter le respect strict de la licence GPL de certains composants de Haiku), mais, pour des raisons de dépendances entre cibles dans le système de build, il était tout de même généré pour les autres profils, ralentissant la compilation (waddlesplash).

Améliorations du script ./configure (jessicah, OscarL et waddlesplash):

  • Le script vérifie que les options passées fournies sont valides, et rejette immédiatement les configurations incohérentes plutôt que de laisser la compilation échouer bien plus loin.
  • Validation que l’interpréteur Python sélectionné existe bien, et uniformisation de la syntaxe utilisée pour choisir un interpréteur avec la façon dont c’est fait pour d’autres outils.
  • Détection des options disponibles pour demander à wget de ré-essayer un téléchargement en cas d’échec, ce qui permet d’assurer la compatibilité avec wget2.
  • Utilisation automatique d’une version moderne de GCC pour compiler les outils « hôtes » lors de la compilation à partir d’une machine hôte fonctionnant sous Haiku en version 32 bit, en ignorant le compilateur par défaut qui est gcc 2 pour des raisons de compatibilité avec BeOS.

Réorganisation du code source de libroot pour déplacer les implémentations de malloc dans des sous-dossiers séparés, et faciliter l’expérimentation avec d’autres implémentations de malloc. L’allocateur hoard2 utilisé actuellement n’est pas adapté aux architectures 64 bits, une tentative a été faite il y a quelques années avec rpmalloc, mais ce dernier pose des problèmes sur les
architectures 32 bits. Des investigations sont en cours avec l’implémentation de malloc d’OpenBSD.

L’outil de dessin Wonderbrush est maintenant disponible sur toutes les architectures. Historiquement, le code de Wonderbrush n’était pas libre, mais une version gratuite était offerte aux utilisateurs de Haiku. Le développeur principal de Wonderbrush n’est plus très actif sur le projet et a décidé de publier les sources, ce qui a permis de recompiler le programme en version 64 bits et plus tard sur les autres architectures non x86. Mais ces nouvelles versions n’avaient jamais été incluses dans Haiku (PulkoMandy).

Nettoyage et centralisation des définitions préprocesseur pour la compatibilité avec BeOS. Désactivation de la compatibilité avec BeOS dans le noyau, la compatibilité avec les pilotes et modules noyau de BeOS n’étant plus assurée depuis quelque temps dans Haiku.

Suppression de définitions de règles obsolètes et inutilisées dans le Jamfile permettant de construire le fichier package_repo (CodeforEvolution).

Remise en service du test DiskDeviceManagerTest qui ne compilait plus (waddlesplash).

ARM & PowerPC

Actuellement, Haiku est disponible officiellement pour les architectures x86 32 et 64 bits. Une version RISC-V 64 bits expérimentale est également disponible mais pas encore totalement intégrée dans le dépôt de code principal, des discussions sont en cours sur la bonne façon de faire certains changements nécessaires. Les versions ARM (32 et 64 bits) et PowerPC sont les prochaines cibles sur la liste. La première, car c’est une architecture très populaire, la deuxième plutôt pour des raisons historiques : c’est l’une des architectures sur lesquelles fonctionne BeOS.

Renommage de structures qui étaient initialement spécifiques à l’architecture x86, mais qui sont finalement utilisées également sur d’autres CPU sans nécessiter de changements (waddlesplash).

Réparation de la console de texte du chargeur de démarrage OpenFirmware qui était cassée depuis l’adaptation pour OpenBOOT sur les machines SPARC (zeldakatze).

Sur ARM, utilisation de la bonne instruction CPU pour mettre le processeur en veille quand il n’y a rien à faire (archeYR).

oanderso continue le travail sur le portage ARM64:

  • Correction de plusieurs problèmes liés à la gestion du cache et de la MMU dans le bootloader, ce qui permet de démarrer le noyau dans une machine virtuelle sur un hôte Apple M1.
  • Correction de l’implémentation des timers dans le kernel qui ne fonctionnait pas dans les environnements virtualisés.
  • Quelques avancées sur la gestion de la MMU : Implémentation de la table de translation de la mémoire virtuelle, du traitement des exceptions matérielles (défauts de page), des TLBs.
  • Synchronisation du cache d’instructions.
  • Correction de problèmes de double lock.

Ajout de messages sur le port série traçant l’exécution de méthodes spécifiques à une architecture qui ne sont pas encore implémentées. Ceci permet de détecter facilement quelle est la prochaine fonction à implémenter (waddlesplash).

Nettoyage et documentation du fichier ArchitectureRules pour simplifier la configuration des options en ligne de commande du compilateur (qui doit savoir traiter deux versions de gcc et clang) (waddlesplash).

Commentaires : voir le flux Atom ouvrir dans le navigateur

Deno 2.0 est là

Le temps où Node.js régnait en maître comme la solution incontournable pour exécuter du code JavaScript côté serveur est-il révolu ? En tout cas, il a aujourd’hui des challengers de taille comme Bun (qui pourrait lui aussi mériter une dépêche) ou Deno. C'est donc de ce dernier qu'il sera question dans cette dépêche, à l'occasion de la sortie de sa version 2.0

Sommaire

Titre de l'image

Pour rappel

Deno est un runtime JavaScript et TypeScript. Il a vu le jour suite au constat de Ryan Dahl (créateur aussi de Node.js), que Node avait des problèmes de conceptions, et qu'il était nécessaire de repartir de zéro en tenant compte de l'expérience de Node pour ne pas refaire les mêmes erreurs. Il imagine Deno comme un runtime avec un modèle de sécurité par défaut plus strict. Les programmes Deno n'ont pas accès au système de fichiers, au réseau ou à l'environnement, sauf si on leur accorde explicitement ces permissions. Deno est écrit en Rust, et se base sur le moteur JavaScript V8 de Google. Deno se distingue également de Node en offrant la possibilité d'importer les dépendances via des URL, mettant en cache chaque module lors de l’importation pour améliorer la vitesse d’exécution.

La mascotte !

La première chose notable quand on passe de Node.js à Deno, c'est sa mascotte ! En effet, même si Node.js possède bien une petite tortue comme mascotte, celle-ci n'est utilisée nulle part ! Personnellement, j'ai toujours trouvé bien plus chouettes les projets qui ont des petites bestioles comme mascotte (Mozilla, Tux …). Et chez Deno, le dinosaure mascotte est omniprésent sur tout le site. Et en plus, à l'occasion de la version 2.0, on peut habiller notre dino sur la home page du projet ! Et ça c'est cool ! Voici le mien, qui est en compagnie de Ferris, la mascotte officieuse de Rust !

Mon dino

Bon, comme je ne suis pas sûr que tout le monde partage ma passion pour les mascottes, on va passer au côté plus technique ! 🤣

Deno 1.x, des débuts difficiles !

La version 1.0 sortie en mai 2020 a du mal à se faire une place et reste dans l'ombre de son grand frère. En effet, même si Deno offre un grand lot de nouveautés et est plus sécurisé par défaut, la très large adoption de Node et le fait que les projets développés pour Node ne sont pas forcément compatibles avec Deno rend l’adoption de ce dernier difficile. De plus, l'utilisation de CDN plutôt que d'installer les dépendances localement (dans le répertoire node_modules) a certes de nombreux avantages, mais cela rend votre projet dépendant de disponibilité du réseau ou peut entraîner des problèmes de performances si le CDN est éloigné géographiquement.

Les nouveautés de la version 2.0

Deno est désormais 100% compatible avec Node.js, et un gestionnaire de paquets officiel a vu le jour. Vous pouvez maintenant utiliser deno add et deno removepour ajouter ou retirer un paquet à votre projet.

Autour du projet Deno, JavaScript Registry (JSR) un dépôt de paquets JavaScript universel !

Le registre NPM s'est construit autour de Node.js afin de gérer facilement les dépendances de nos projets. Il a donc été développé pour Node.js à une époque où Node était la seule solution pour exécuter du code JavaScript côté serveur. En près de 15 ans, le registre NPM a rassemblé un peu moins de 3 millions de paquets et a très largement rempli sa mission toutes ces années. Mais aujourd'hui, la situation a changé, il existe plusieurs runtimes pouvant exécuter du code JavaScript (ou TypeScript) côté serveur. Et du côté front-end, les frameworks se sont multipliés et sont devenus de plus en plus complexes et nécessitent aussi l'utilisation d'un gestionnaire de paquets. Un registre de paquets fondé autour de Node.js uniquement est donc beaucoup moins pertinent qu'en 2010.
C'est donc pourquoi, à l'initiative du projet Deno, un nouveau registre de paquets JavaScript et TypeScript universel pointe aujourd'hui le bout de son nez. Il s'agit donc de JSR (JavaScript Registry).

Dans JSR, quand on va sur la page d'un paquet, en haut à droite, on a les logos des environnements compatibles avec le paquet :

Titre de l'image

Performances du runtime

Niveau performance, ça donne quoi ?

On voit souvent l'affirmation que Deno serait plus rapide que Node.js. Mais ça donne quoi en réalité ?

J'ai voulu faire un petit test sans prétentions pour voir ce que ça donne. Je voulais faire des tests plus poussés sur différents systèmes d'exploitation et architectures, mais par manque de temps, le test sera donc fait sur un seul système et un seul ordinateur et il s'agit d'un Mac… Un comble pour LinuxFr.org, mais c'est l'ordinateur que j'avais à disposition à ce moment-là. Mais sinon, je ne porte pas spécialement Apple dans mon cœur, bien au contraire !

J'ai testé l’exécution d'une même API sur Node. et Deno pour voir les différences de performance entre ces solutions. Pour ce test, j'ai utilisé une API Rest que j'ai développée pour le site de la société AudioSoft. J'ai fait la même requête POST 10 fois sur la même route avec les mêmes données. Il est important de préciser que c'est la première fois que je fais ce genre de tests, et que je ne fais peut-être pas tout dans les règles de l'art. Il y a des éléments extérieurs à Node et Deno qui peuvent influencer les scores. Notamment, la base de données utilisée pour le test était accessible via Internet, et des différences de débit ont pu fausser les tests.

Test sur un MacBook Pro (2,6 GHz Intel Core i7 6 cœurs, AMD Radeon Pro 5300M 4 Go Intel UHD Graphics 630 1536 Mo, 16 Go 2667 MHz DDR4) sous macOS Sonoma

Node: Le temps moyen pour exécuter le test de 126 millisecondes
Deno: Le temps moyen pour exécuter le test de 93 millisecondes

Performances du gestionnaire de paquets

Comme dit précédemment, Deno c'est aussi un gestionnaire de paquets. J'ai donc trouvé intéressant de tester les principaux gestionnaires de paquets sur différents environnements.
Pour ce test je me base sur la même API Rest que pour le test précédant, les dépendances à installer pour cette API sont : bcrypt, body-parser, dotenv, express, jsonwebtoken, mariadb, multer, mysql2, nodemailer, et sequelize. Le test a été fait sur un MacBook Pro. Pour effectuer ce test, le cache des gestionnaires de paquets ont été nettoyés et les fichiers-verrous supprimés.

Avec NPM, l'installation a mis 10 secondes.

Avec Deno, l'installation a mis 1 seconde.

Avec Bun, l'installation a mis 3 secondes.

On voit très clairement que NPM est beaucoup plus lent que ses deux concurrents. L'écart est plus faible entre Deno et Bun. Mais Deno est bien le plus rapide des trois.

Avant de réaliser ce test, j'en ai effectué un en oubliant de nettoyer le cache et de supprimer package-lock.json. Les résultats étaient alors 8 secondes pour NPM, 5 secondes pour Deno et 4 secondes pour Bun. Il est logique de constater que NPM est plus rapide, en revanche, je trouve surprenant que Deno et Bun aient été ralentis. Il est possible que les gestionnaires de paquets aient parcouru package-lock.json pour garder les versions présentes dans ce fichier, ce qui les aurait tous les trois ralentis. Et NPM a peut-être pu bénéficier de son cache (car je l'utilise bien plus que les deux autres sur mon ordinateur), Deno et Bun eux n'avaient peut-être pas grand-chose dans leurs caches, ont donc été ralentis. Il est donc important de supprimer les lockfile en cas de migration d'un projet.

Comme je le disais plus haut, c'est la première fois que j'effectue ce genre de test comparatif. Si vous avez des conseils sur les bonnes méthodes pour faire des tests plus fiables, ça m’intéresse !

Deno 2.1 est là

Étant donné que j'ai mis environ un siècle pour rédiger cette dépêche, Deno 2.1 est sortie entre temps ! 🤣
Je vous liste donc les principales nouveautés apportées à la version 2.1 sans les commenter 😉

  • Support natif de WebAssembly (Wasm) : Il est désormais possible d'importer directement des modules Wasm, simplifiant leur utilisation et améliorant les performances.
  • Version Long Term Support (LTS) : Deno 2.1 inaugure la première version LTS, garantissant des correctifs de bugs et des améliorations de performance pendant… Six mois… On n'est pas encore aux 30 mois des versions LTS de Node.js… Cela viendra peut-être plus tard. 🙂
  • Commande deno init --npm vite : Cette commande simplifie la création de nouveaux projets en utilisant des outils comme Vite, en automatisant l'initialisation et en réduisant la configuration manuelle.
  • Gestion des dépendances : Introduction de la commande deno outdated pour gérer les mises à jour des dépendances JSR et npm.

Conclusion

Si vous êtes développeur Node.js, je vous conseille de vous intéresser à Deno, et même à Bun. Je ne sais pas si ces deux runtime sont totalement prêts pour des projets en production (par exemple, Deno 2.1 n'a que 6 mois de durée de vie, ce qui est plutôt contraignant pour les serveurs.). Mais peut-être que dans un futur proche, il sera cohérent de migrer vers l'un de ces deux-là.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Venez nous retrouver à Open Source Experience les 4 et 5 décembre #OSXP2024

La quatrième édition d'Open Source Experience (ou OSXP2024 pour les intimes) arrive à grand pas les 4 et 5 décembre prochains au Palais des Congrès de Paris. C'est un événement désormais rituel qui propose à la fois :

  • une centaine de conférences avec 125 conférenciers, dont le programme est en ligne et détaillé dans la suite de la dépêche ;
  • une partie exposition avec 90 exposants, dont un village associatif un peu réduit cette année (sept stands)

Bannière OSXP24

Et LinuxFr.org répond présent comme d’habitude depuis de nombreuses années. Vous pourrez donc nous y retrouver, stand A02 (tout en bas à droite sur le plan). Une partie de l’équipe du site LinuxFr.org sera présente au sein du village associatif pour vous faire découvrir le site, discuter, répondre à toutes les questions que vous pourriez vous poser, vous donner des autocollants du site et vous faire gagner des kilos de livres, mais pas que (lisez plus bas, on renouvelle comme chaque année).

Ce sera aussi l’occasion de se retrouver en chair et en os pour celles et ceux qui pourront faire le déplacement et au vu du programme toujours très dense, on vous incite vraiment à venir y faire un tour.

Sommaire

Programme des conférences

Le programme de cette 4e édition d'Open Source Experience a été publié par les organisateurs. Plus d'une centaine de conférences, tables rondes, workshops à l'affiche, autour de trois thématiques qui veulent mettre en avant les enjeux et bénéfices de l'open source pour les organisations avec des cas d’utilisation concrets, le tout autour de cinq thématiques.

Thématiques

  • IA, Machine Learning & Data ;
  • Cloud, Infra & IoT ;
  • Cybersécurité ;
  • Solutions d'entreprise ;
  • Business et enjeux.

Temps forts

En marge des conférences vous retrouverez plusieurs événements dans l'événement :

  • L'AssoLution, le temps fort associatif
  • Le concours des Acteurs du Libre dont nous avons remporté le prix du numérique ouvert et éthique en 2019
  • Les trophées Territoire Numérique Libre

Vous pourrez également assister à plusieurs animations : podcasts, jeux, concerts,…

Découvrez le programme complet sur le site de OSXP !

Village associatif

Les associations présentes

Comme chaque année, un village associatif sera présent, mais il sera plus réduit cette année, suite à une réduction de l'espace exposition. Seront présents en plus de LinuxFr.org : Adullact, April, Framasoft, Libervia, MozFr, La Mouette, les Mongueurs de Perl, VLC et Wikimedia France.

Mais que vient faire LinuxFr.org à Open Source Experience ?

Nous serons en A02, exilés au bout du village des associations lui même dans le coin du salon, au plus loin des conférences et de l'espace VIP. Ferait-on trop de bruit avec notre mégaphone ? Une partie de l’équipe sera présente pour :

  • rencontrer les personnes contributrices et notre lectorat ;
  • expliquer le principe de LinuxFr.org aux personnes qui ne connaissent pas (encore) (bien) le site ;
  • inciter notre lectorat à contribuer : nous avons pu constater que certaines personnes ne se sentaient pas — à tort, le plus souvent – le niveau pour passer la modération (il y a les journaux aussi) et surtout affronter la communauté de LinuxFr.org, qui peut être très exigeante ;
  • vous faire gagner des livres (nous nous sommes encore démenés pour vous ! Merci aux éditions D-Booker, Eyrolles et ENI pour les dons) ;
  • vous donner (oui, on est comme ça, on donne) des autocollants LinuxFr.org inspirés de nos logos passés ou actuels (encore un énorme merci à nos amis de Grafik plus pour les impressions à un tarif proprement indécent) ;
  • parader avec nos nouveaux polos plus responsables ; polos LinuxFr
  • participer à quelques-unes des 100 conférences décrites plus haut
  • Et surtout animer avec Bookynette, la présidente de l'April, l'AssoLution, le temps fort associatif !
Le stand Linuxfr tirage au sort sur le stand

Merci à tous ceux qui passeront nous saluer mercredi et jeudi sur le stand B10, nous vous attendons de pied ferme. Nous allons tenter de relayer les nouvelles de l’événement via notre compte X @linuxfrorg et/ou BlueSky, en attendant un compte-rendu plus formel post-salon.

« L'AssoLution »

Après Section d’Assos , l’Assaut de Bien Fêteurs et la Zone Associative Déjantée, OSXP propose cette année L'AssoLution, l’absolution à la dissolution ! Comme chaque année, LinuxFr.org fait l’animation des associations, réunissant geeks, décideurs et lutins pour un moment festif et détendu. La partie musicale sera gérée par KPTN (aka Clément Oudot) de Worteks. Un bon moment festif en perspective. ! Et nous avons encore vu les choses en grand pour s’assurer de votre présence, moins de rébarbatif et plus de fun. Au menu :

  • Discours d’absolution aux codeurs propriétaires repentis
  • Après nos 25 ans l'année passée, Framasoft viendra nous faire un rapide bilan de ses 20 ans cette année (. Toujours une bonne occasion de célébrer !
  • Notre Quiz sympatico-ludique façon Burger Quizz avec plein de cadeaux et de goodies à remporter grâce à nos sympathiques mécènes (voir plus loin).
  • Vu que cela se déroule pendant la pause méridienne, nos amis des Fondations AlmaLinux OS, Eclipse et Open Source Initiative fourniront les cupcakes (une fois n'est pas coutume) !

📅 Jeudi 5 décembre 2024
⏰ 12h30
🗺️ Salle Laurent Séguin

quiz à l’OSXP 2023, la scène quizz à l’OSXP 2023, le public Les cupcakes de 2023

Des cadeaux en pagaille

C’est pas tout ça, mais on sait que vous venez aussi nous voir pour les cadeaux et les tirages au sort quotidien pour repartir avec votre dose de connaissance, mais aussi de joie et de bonne humeur !

L'année dernière, nous avions eu pas mal de succès avec notre Fairphone et nos Lego. On remet donc ça, mais pour les remporter, il faudra se distinguer au quiz pour tenter de remporter :

  • un Fairphone 5 vert (de chez Murena avec /e/OS dessus) ;
  • un casque audio Fairbuds XL vert ;
  • un kit de démarrage Raspberry Pi 5 ;
  • le jeu de société "Les Aventuriers du Rail : Légendes de l’Ouest" ;
  • une boîte de Lego architecture Notre-Dame de Paris vu qu'elle va rouvrir sous peu !
  • et des abonnements à la bibliothèque numérique des éditions ENI (en plus des livres, voir plus loin).

Liste des lots pour le quiz comprenant un Fairphone 5 vert (smartphone durable), un casque audio Fairbuds XL vert, un kit de démarrage Raspberry Pi 5, le jeu de société "Les Aventuriers du Rail : Légendes de l’Ouest", et une boîte LEGO représentant la cathédrale Notre-Dame de Paris dans la collection Architecture.

Nous en profitons pour remercier les sociétés Passbolt et AdmanTIC qui ont financé ces cadeaux.

Merci Passbolt Merci Admantic

Il y aura aussi plus de 25 de livres à gagner parmi 22 références de nos partenaires habituels : les éditions ENI, les éditions Eyrolles et désormais les éditions D-Booker.

Logo éditions ENI Logo éditions Eyrolles Logo éditions B-BookeR
     

Soyez présent, on remet en jeu tout lot non réclamé sur place ! Et nous aurons des lots de consolation.

Livres à gagner

Informations pratiques

Concrètement, pour nous rejoindre sur place

  • Adresse : Palais des Congrès – 2 Place de la Porte Maillot – 75017 Paris
  • Stand LinuxFr.org : A02
  • Dates : mercredi 4 et jeudi 5 décembre 2024
  • Horaires d’ouverture : de 9h00 à 18h00
  • Accès transport en commun
    • Métro Ligne 1, Station Porte Maillot – sortie 3.
    • RER Ligne C, Station Neuilly – Porte Maillot.
    • BUS Lignes 43, 73, 82, 244 PC

Commentaires : voir le flux Atom ouvrir dans le navigateur

FreeCAD 1.0

FreeCAD est sorti le 18 novembre 2024 en version 1.0 (voir l'annonce officielle et sa vidéo associée). Cette sortie est marquée par une amélioration majeure : l'atténuation du problème de dénomination topologique.

Nouveau logo FreeCAD

Sommaire

La dernière dépêche sur FreeCAD remonte à avril 2021 pour la sortie de la version 0.19. Depuis, il y a eu les versions 0.20 (juin 2022) et 0.21 (août 2023). Cette version 1.0 a porté le nom de 0.22 pendant son développement.

Qu'est-ce que FreeCAD ?

Exemple 1 utilisation

Extrait de wiki.freecad.org :
FreeCAD est un modeleur paramétrique de CAO 3D open source sous licence LGPL. FreeCAD est destiné à l'ingénierie mécanique et à la conception de produits mais — étant très générique — il s'adapte également à une gamme plus large d'utilisations autour de l'ingénierie, telles que l'architecture, l'analyse par éléments finis, l'impression 3D et d'autres tâches.

FreeCAD propose des outils similaires à CATIA, SolidWorks, Solid Edge ou Revit et entre donc également dans la catégorie CAO, GCVP, CFAO, IAO et BIM. Il s'agit d'un modélisateur paramétrique basé sur les caractéristiques d'une architecture logicielle modulaire qui permet de fournir des fonctionnalités supplémentaires sans modifier le système de base.

FreeCAD est aussi multiplateforme. Il fonctionne sous Windows, Linux/Unix et macOS avec la même apparence et les mêmes fonctionnalités sous toutes les plateformes.

Historique

La toute première version de FreeCAD est sortie en 2002. FreeCAD est développé en C++, Qt et Python et son cœur repose sur les bibliothèques OpenCASCADE (ou OCCT) spécialisées dans la CAO.

Son développement est assuré par un large panel de contributeurs : certains sont historiques, d'autres sont spécialisés sur un aspect particulier et beaucoup sont plus ou moins occasionnels.

Les versions se sont enchaînées à un rythme quasi annuel, apportant moult améliorations et fonctionnalités nouvelles.

En 2021, quelques contributeurs historiques fondent la FreeCAD Project Association (FPA) qui est un organisme indépendant à but non lucratif pour collecter des dons et apporter un soutien au développement du projet.
Ce soutien passe notamment par leur programme "FreeCAD Grant Program", qui permet d'embaucher ou de récompenser des personnes pour des projets spécifiques. Ce programme a un budget de 50k$ pour l'année 2024. A titre d'exemple récent, 500$ ont été octroyés pour une étude sur les runners CI de Github, 1000$ pour un gros travail de correction de bugs, et enfin 500$ pour la création d'une vidéo sur les nouvelles fonctionnalités de cette version 1.0.

FreeCAD bénéficie d'une communauté impliquée permettant notamment d'avoir une documentation complète, à jour et traduite dans de nombreuses langues.

Le problème de dénomination topologique

C'était un des points noirs de FreeCAD jusqu'à cette version 1.0.
Il faut imaginer que dans ce logiciel, la modélisation d'une pièce (dans le sens objet physique) passe par une suite d'opérations mathématiques et géométriques en définissant à chaque fois des contraintes ou des paramètres. Une opération est par exemple la création d'un trou borgne de 5 mm sur telle face à 10 mm des bords haut et gauche. Un autre exemple est d'ajouter une « languette » sur telle face cylindrique. Ou bien d'ajouter un chanfrein de 2 mm sur telle arête, etc.

Ainsi, petit à petit, la pièce modélisée se construit, prend forme, se détaille et se complexifie.

Cet historique de ces opérations successives est toujours présent et modifiable. À tout moment, il est possible de modifier une des étapes intermédiaires.

D'un point de vue technique, vous aurez sans doute compris que chaque opération s'applique à un élément précis et existant de la pièce à ce moment-là (une face ou une arête par exemple). Dans FreeCAD ces éléments ont tous un identifiant unique (Face6, Edge9, etc.), continu et incrémental. Si l'objet a 13 faces à une des étapes, les faces seront numérotées de Face1 à Face13. Chaque opération est rattachée à l'identifiant de l'élément (Face5 par exemple).

Et le problème se situe à ce niveau : lors d'une modification d'une étape intermédiaire, il arrive souvent que cela change la géométrie globale de la pièce et donc que les nombres de faces ou d'arêtes augmentent ou diminuent. Et FreeCAD réattribue alors ces identifiants uniques aux différents éléments.
Ainsi, si l'objet passe de 13 à 11 faces, c'est l'ensemble des faces qui vont recevoir un nouvel identifiant dans la plage Face1 à Face11, avec un très fort risque qu'une face, pourtant non touchée par la modification, porte un identifiant différent.

Et vous voyez le problème arriver : si une des opérations suivantes dans l'historique était de faire un perçage sur la Face6 qui est maintenant devenue la Face3… Toute la modélisation part en vrille.

Ce problème de dénomination topologique est documenté sur le wiki de FreeCAD : problème de dénomination topologique.

Pour éviter cela, il était conseillé de suivre un ensemble de bonnes pratiques de modélisation sous FreeCAD : Édition de fonctions. Il faudra certainement suivre l'évolution de cette page avec cette sortie.

Cette version 1.0 marque donc l'intégration de codes correctifs de cette problématique. Les notes de version indiquent tout de même que tout n'est pas résolu, et qu'il y aura d'autres améliorations dans les prochaines versions. Cette petite vidéo en anglais vous montre la différence de comportement entre la version 0.21 et 0.22dev (qui a servi de base à la 1.0).

Les autres améliorations

Un outil d'assemblage par défaut avec solveur dynamique

Le terme assemblage désigne la fonctionnalité de regrouper plusieurs éléments afin d'obtenir un objet fonctionnel. Ce peut être, par exemple, une boîte constituée d'un couvercle sur charnières maintenues par des vis avec des rangements amovibles à l'intérieur. Ou bien un moteur thermique avec ses carters, vilebrequin, bielles, pistons, soupapes, etc. Il est parfois utile de pouvoir fournir des indications de positionnement et/ou de liberté des éléments entre eux, et de pouvoir animer le tout.
Ces opérations d'assemblage n'étaient pas intégrées dans FreeCAD avant la version 1.0. Elles étaient néanmoins possibles grâce aux ateliers. Plusieurs ont été créés pour cela avec chacun leurs spécificités et leurs approches mais aussi une incompatibilité entre eux : A2plus, Assembly3 ou Assembly4.
Cette version 1.0 propose un nouvel atelier mais intégré par défaut. Il a été mis au point par la société Ondsel (voir plus bas). Il est encore jeune, et il est encore trop tôt pour savoir s'il finira par s'imposer par rapport à l'existant déjà en place. Un tutoriel concernant l'atelier d'assemblage est d'ores et déjà disponible pour une introduction à cette nouvelle fonctionnalité de la v1.0.

L'atelier sketcher amélioré

Cet atelier permet de dessiner les esquisses techniques utilisées dans la conception mécanique. C'est dans celui-ci que sont dessinés les « plans 2D » avec les cotes et les contraintes dimensionnelles et spatiales. Cette version apporte un nombre conséquent d'améliorations et de nouvelles fonctionnalités rendant son utilisation plus facile, plus puissante et plus rapide. Le mieux est de regarder les notes de version animées.

Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC

Si le titre est cryptique, c'est que l'on parle de BTP et d'outils destinés aux équipes de Maîtrise d'Œuvre impliquées dans la conception d'une opération construction (Architectes, Bureaux d'Études). Comme ce n'est pas forcément le lot commun des visiteurs de LinuxFr.org, résumons la situation:

  • L'atelier Arch, pour Architecture, exploite depuis longtemps les capacités de création 3D de FreeCAD pour dessiner facilement, fondations, murs, planchers, fenêtres, portes etc. Cet atelier se basait sur le format natif des fichiers FreeCAD, *.FcStd.

  • Dans l'atelier BIM (pour Building Information Model <= l'article Wikipedia_FR est bien écrit pour qui veut comprendre l'essentiel), on retrouve un certain nombre d'outils de dessin et de création d'objets qui s'avèrent redondants pour certains avec ceux de l'outil Arch tout en implémentant les paradigmes bien plus vastes qu'induit l'approche BIM d'un projet de construction <=> pas uniquement de la géométrie, mais aussi du prix, des données mécaniques, physiques, des fiches produit, du planning …

  • L'approche BIM tend à se généraliser dès lors que la complexité et le coût du projet le justifient. Elle repose (en théorie) sur un format d'échange IFC (pour Industry Foundation Class).
    Il est ouvert et au format texte.
    Oui avec vim, c'est possible de bidouiller ;)
    mais un fichier IFC fait rapidement quelques centaines de Mo voire quelques Go …

L'Association "Building Smart" en définit les caractéristiques. Tous les logiciels sur le marché savent ouvrir et exporter dans ce format, à la norme IFC 2.3 ad minima et IFC 4.2 voire 4.3 pour les up to date.

L'atelier BIM de FreeCAD utilisait jusqu'à présent IfcOpenShell, une application tierce Open Source pour convertir un fichier du format *.ifc vers du *.FcStd en passant (sans doute) par du OpenScad dans le processus.

Titre de l'image
Une image qui devrait parler au LinuxFrien (!) pour la classe IFC Material-Constituent-Set,

Pour la version 1.0 de FreeCAD, Yorik Van Havre, développeur historique de FreeCAD, (par ailleurs, architecte et Président la FreeCAD Project Association) a entrepris de fusionner ces deux ateliers, d'en faire une fonctionnalité native de FreeCAD, c'est-à-dire qui se passe du vaillant IfcOpenShell (grâce notamment au travail fait sur Blender-Bim) pour que FreeCAD puisse ouvrir et enregistrer directement au format IFC sans conversion inutile.

L'atelier FEM

Cet atelier d'analyse par éléments finis comporte également des améliorations considérées comme majeures avec cette version 1.0, détaillées dans un article de blog sur l'atelier FEM de FreeCAD.

Les avancées majeures sont liées à la prise en charge de fonctionnalités de CalculiX, un des solveurs utilisés par cet atelier : symétrie cyclique, analyses 2D et contraintes de corps rigide.

Le reste

Comme à chaque nouvelle version, beaucoup de choses ont été apportées, que ce soit dans l'interface, ou dans la plupart des ateliers intégrés. Les notes de version de la v1.0, comme très souvent détaillées en images, permettent de voir l'évolution de ce logiciel.

FreeCAD a également annoncé son nouveau logo, choisi après un appel à concourir auprès de la communauté (lien). Le logo en SVG est disponible sur cette page.

L'essai commercial d'Ondsel

Outre la création en 2021 de l'association FPA (voir plus haut), d'autres développeurs, notamment Brad Collette, mainteneur de longue date de l'atelier Path et auteur de deux livres sur FreeCAD, ont créé début 2023 la société américaine ONDSEL sous la forme d'une Public Benefit Corporation (PBC) qui pourrait se traduire par « une entreprise d'intérêt pour la société ». Malheureusement, après environ 2 ans, Brad Collette informe de l'arrêt de la société ONDSEL, faute d'avoir trouvé un marché.

La société voulait s'appuyer sur FreeCAD pour « apporter des fonctionnalités commerciales qui rendent FreeCAD plus utile aux utilisateurs commerciaux ». (Source)

Pour cela, ONDSEL a produit sa propre version de FreeCAD avec ses propres choix esthétiques et ergonomiques, et a fourni un cloud pour simplifier le travail en équipe et le partage.
À noter qu'ONDSEL indiquait soumettre ses améliorations à FreeCAD pour intégration et que son cloud était disponible sous forme de module dans FreeCAD. Ces améliorations se retrouvent dans cette version 1.0 de FreeCAD, notamment le nouvel outil intégré d'assemblage ainsi que les très nombreuses nouvelles fonctionnalités de l'atelier Sketcher.

La société ONDSEL avait détaillé sa relation avec le projet FreeCAD indiquant notamment leur mode de collaboration. Ils avaient également un blog en anglais intéressant, où ils abordent plusieurs thématiques, notamment sur l'évolution de CATIA ou bien la liste des nouveautés agrémentée de nombreuses animations.

Dans l'annonce de cet arrêt, Brad Collette revient également sur ce qu'ils ont apporté au projet FreeCAD. Tout ce qu'ils ont développé était en open source et déjà intégré pour la plupart à FreeCAD. Les fondateurs d'ONDSEL continueront de contribuer au projet directement.

Commentaires : voir le flux Atom ouvrir dans le navigateur

La conquête de l’espace : une affaire féminine, première partie du NACA à la NASA

Pour cette journée Ada Lovelace, on vous invite à la conquête de l’espace, une histoire qui n’aurait peut-être pas pu se faire sans les femmes. Pas uniquement parce que ce sont des femmes : les anonymes qui ont tressé les mémoires en tore de ferrite des missions Apollo, ou les plus connues qui ont voyagé dans l’espace. Mais aussi parce qu’elles ont calculé ou codé les explorations spatiales. Et comme c’est un sujet vaste, il s’agit, pour l’instant, de la première partie consacrée à trois femmes afro-américaines qui ont travaillé au NACA puis à la NASA : Dorothy Vaughan (1910 – 2008), Katherine Johnson (1919-2020) et Mary Jackson (1921 – 2005). Les portraits de ces trois femmes sont précédés d’une chronologie de la conquête de l’espace.

Journée Ada Lovelace

Sommaire

Préambule

La journée Ada Lovelace (en) (Ada Lovelace Day ou ALD en anglais) est une journée internationale consacrée aux réalisations des femmes en science, technologie, ingénierie et mathématiques (STIM ou STEM en anglais). Elle a lieu le deuxième mardi du mois d’octobre. En 2023, cette journée avait été, pour LinuxFr.org, l’occasion d’évoquer Lorinda Cherry, membre de l’équipe de conception d’Unix, Evi Nemeth et la première hackeuse Judith Milhon. Et c’est, on l’aura peut-être compris, surtout un prétexte pour parler de l’histoire de l’informatique.

Cette dépêche et sa suivante sont malheureusement américano-centrées. Et ce pour la bonne et simple raison que, s’il est facile de trouver de l’information sur les cosmonautes russes, en trouver sur les informaticiennes est beaucoup plus ardu. En fait, on n’en a pas trouvé d’autre que Rozetta Zhilina (en), 1933 – 2003, qui a plutôt travaillé dans un contexte militaire et dont la spécialité était les algorithmes en balistique et Ekaterina Samoutsevitch, née en 1982, membre du groupe de punk-rock féministe les Pussy Riot. C’est d’autant plus regrettable que l’URSS avait une réelle avance en matière de conquête de l’espace. Avance que la Russie a toujours sur certains points. Par exemple, le côté russe de la station spatiale internationale a des toilettes prévues pour que les femmes puissent avoir leur règles et changer ainsi leurs protections hygiéniques.

Les portraits des trois femmes qui figurent ci-dessous peuvent sembler assez idylliques. Dans la réalité elles ont dû affronter beaucoup de difficultés du fait de leur groupe ethnique et de leur genre : méprisées par les hommes blancs, peu valorisées, Dorothy Vaughan n’aura pas eu la promotion à laquelle elle pouvait prétendre du fait de ses fonctions, Mary Jackson verra sa carrière bloquée, et souvent pas assez outillées pour leur travail. Par exemple, Katherine Johnson n’aura pas toujours accès à l’intégralité des données dont elle avait besoin dans le cadre de son travail pour le « SpaceTask Group ».

Les portraits des femmes seront donnés dans l’ordre chronologique de leur naissance.

La conquête de l’espace en quelques dates

La conquête de l’espace a été d’abord marquée par la lutte entre les deux grands blocs : Est contre Ouest, la « Course à l’espace » (Race for Space en anglais). La Russie soviétique ayant conservé pendant plusieurs années son avance sur les USA. Une chronologie qui s’arrête à la fin du programme Apollo et qui est centrée sur les réalisations des deux géants.

Un aperçu de la chronologie de la conquête dans l’espace
Un rendu un peu plus visuel des dates qui sont données ci-après, la Russie est dans la colonne de gauche, les USA dans celle de droite. Le document est téléchargeable au format fichier pdf hybride et nettement plus lisible.

1957 : la Russie envoie dans l’espace le Spoutnik 1, premier satellite artificiel en octobre. En novembre c’est la chienne Laïka qui s’envole, c’est le premier animal vivant à réaliser une orbite dans l’espace.

1958 : création de la NASA.

1960 : les deux chiennes, Belka et Strelka que la Russie soviétique avait envoyées dans l’espace reviennent vivantes de leur vol orbital, ainsi que le lapin et les souris qui les accompagnaient.

1961 : en janvier, la NASA envoie le chimpanzé Ham accomplir un vol orbital. En avril c’est le Russe Youri Gagarine qui s’envole et devient le premier homme à avoir accompli un voyage dans l’espace, ainsi que la coqueluche des foules. Dix mois après les Russes, le 20 février 1962, les USA envoient John Glenn pour accomplir un vol orbital. La même année, en décembre, la sonde Mariner 2 survole Vénus. Le Royaume-uni et le Canada envoient leur premier satellite en orbite.

1963 : la cosmonaute russe Valentina Terchkova est la première femme à aller dans l’espace et, à ce jour, la seule à y avoir effectué une mission en solo. Le 18 mars 1965, le cosmonaute soviétique Alexeï Leonov effectue la première sortie dans l’espace. En juillet, la sonde américaine Mariner 4 survole Mars. La même année, la France lance la fusée-sonde LEX, l’Italie un satellite. La sonde russe Luna 9 se pose sur la Lune le 3 février 1966. Luna 10, quant à elle, se placera en orbite autour du satellite de la Terre.

1968 : septembre dans le cadre de la mission russe Zond 5, un vaisseau habité par des tortues survole la lune. Décembre, c’est au tour de la NASA d’envoyer un vaisseau habité vers la lune. Elle envoie un équipage en orbite lunaire, mission Apollo 8.

Juillet 1969 : tandis que les Russes lancent leur première navette spatiale, BOR-2, elle servira au programme Bourane, la mission Apollo 11 envoie Neil Armstrong et Buzz Aldrin sur la Lune.

1971 : en avril, les Russes lancent Saliout 1, première station spatiale habitée. En novembre, la sonde américaine Mariner 9 orbite autour de Mars. En décembre, la sonde russe Mars 3 se pose en douceur sur Mars.

1972 : Apollo 17 dernière mission lunaire du programme Apollo. La conquête de l’espace entre dans une autre phase peu après.

Le NACA (National Advisory Committee for Aeronautics, en français, Comité consultatif National pour l’Aéronautique), prédécesseur de la NASA

Le NACA est une agence fédérale états-unienne créée en 1915.

Comme son nom le suggère, l’objectif du NACA était de favoriser la recherche en aéronautique, un secteur qui commençait à se développer et sur lequel les États-Unis étaient en retard par rapport à l’Europe. Le centre de recherche Langley du NACA était basé à Hampton en Virginie. Dans cette Amérique ségrégationniste, les zones de travail entre Blancs et Noirs sont séparées, celle de l’unité de calcul de la zone ouest (West Area Computing Unit) étant réservées aux personnes afro-américaines où travailleront les trois héroïnes de cette dépêche. Quand le NACA disparaîtra en 1958 pour faire place à la NASA, les secteurs raciaux disparaîtront également et il n’y sera plus fait, sur le plan des locaux, de distinction entre les personnes selon leur couleur de peau ou selon leur sexe.

On doit au NACA (et peut-être même en partie à Mary Jackson) un type de prise d’air la prise d’air NACA qu’on verra par la suite sur à peu près toutes les voitures à partir de 1956.

Dorothy Vaughan (1910 – 2008), mathématicienne et informaticienne

Dorothy Vaughan naît en 1910. Elle obtient un Bachelor of Arts (l’équivalent d’une licence) de mathématique à l’université de Wilberforce (Ohio) en 1929, elle a dix-neuf ans. À la suite de ça, elle va enseigner les mathématiques dans un lycée afro-américain de Farmville (Virginie).

Arrive la deuxième guerre mondiale, le gouvernement états-unien fait appel aux travailleurs et travailleuses pour soutenir l’effort de guerre, le NACA recrute. Elle candidate au poste de « calculateur » à Langley. Elle est recrutée en décembre 1943 et affectée à l’unité de calcul de la zone ouest dont l’objet était de faire des calculs mathématiques pour les ingénieurs qui se livraient à des expériences aéronautiques. Pour cela, point d’ordinateur (le premier ordinateur reconnu comme tel date de 1942), mais des règles à calcul, des calculatrices mécaniques (merci Pascal), et le visionnage de films. Elles fournissaient ainsi aux ingénieurs les paramètres techniques en matière de vol et de soufflerie.

Au départ, les chefs de sa section seront des hommes, blancs. Finalement, elle sera promue à la tête de l’unité informatique de la zone ouest qu’elle dirigera de 1949 à 1958. Elle aura été la première femme afro-américaine à diriger un département du NACA tout en étant une mathématicienne aux compétences respectées. Il arrivait ainsi qu’on lui demande personnellement d’effectuer certains calculs complexes. Pendant cette période, elle co-écrira avec deux autres mathématiciennes, Sara Bullock et Vera Huckel, un manuel de méthodes algébriques pour les machines à calculer utilisées dans le groupe. Elle participera à la « Course à l’espace », cette période où les USA et l’URSS luttaient pour avoir la suprématie dans le domaine spatial.

Arrive 1958, le NACA est dissout remplacé par la NASA. Elle rejoint le « Numerical Techniques Branch » (section des techniques numériques) et acquiert une expertise en FORTRAN. Elle contribuera au programme de développement des lanceurs de fusée Scout. Elle continuera pendant toute sa carrière à apprendre les nouvelles technologies informatiques. Elle formera d’ailleurs ses collègues à ces disciplines.

Elle quitte la NASA en 1971.

Après sa mort, survenue en 2008, elle reçoit à titre posthume la Médaille d’or du congrès pour son travail pour la NASA.

Katherine Johnson (1918 – 2020), la calculatrice humaine

Katherine Johnson est née en 1918. Elle fait ses études au West Virginia State College, qui deviendra l’université d’État de Virginie occidentale (West Virginia State University). Elle en sort en 1937 avec un diplôme de mathématiques et de français. Elle intègre en 1939, avec deux autres étudiants afro-américains, l’université de Virginie occidentale qui accueille ainsi ses tout premiers étudiants afro-américains. Elle obtiendra un doctorat (PhD) de mathématiques.

Elle est recrutée en juin 1953 par le NACA où elle intègre la section de calcul de Langley. Elle fait partie des calculateurs humains noirs dans cette Amérique qui pratique encore la ségrégation raciale, plus précisément des calculatrices car la section était purement féminine. Deux semaines après son entrée en fonction, Dorothy Vaughan l’assigne à un projet dans la branche des charges de manœuvre (Maneuver Loads Branch) de la division des Recherches en vol (the Flight Research Division) pérennisant ainsi son poste. Elle effectuera toute sa carrière à la NASA qu’elle quittera en 1986.

L’année 1957 est une année charnière dans sa carrière et dans la conquête l’espace : la Russie, on l’a vu, y envoie le Spoutnik 1, premier satellite artificiel d’une famille de dix qui marque le début de la « course à l’espace ». Elle fournit une partie des calculs des « Notes on Space Technology (en) » de 1958. Ces notes font partie d’un cours de technologie spatiale donné à la division des Recherches en vol du NACA. Elle intègre ainsi le « SpaceTask Group » (groupe de travail de l’espace). Quand le NACA sera dissout pour faire place à la NASA, elle suivra naturellement le chemin.

Elle effectuera les analyses de trajectoire pour la capsule spatiale Freedom 7 d’Alan Shepard en mai 1961, premier Américain dans l’espace pour un vol suborbital. En 1960 elle co-écrit avec l’ingénieur Ted Skopinski la note technique « Determination of Azimuth Angle at Burnout for Placing a Satellite Over a Selected Earth Position (en) » qui expose les équations décrivant un vol spatial orbital dans lequel la position d’atterrissage du vaisseau spatial est spécifiée. Elle sera la première femme de la division des Recherches en vol du NACA à être créditée comme auteur.

En 1962, préparation du vol orbital de John Glenn : elle est appelée à y participer. C’est une opération complexe, qui entraîne des calculs complexes eux aussi. Les ordinateurs étaient programmés pour contrôler la trajectoire de la capsule Friendship 7. Cependant, les astronautes étaient réticents à l’idée de confier leur vie à des machines susceptibles de tomber en panne ou de subir des coupures de courant.

Dans le cadre de la liste de contrôle avant le vol, Glenn avait demandé aux ingénieurs de « demander à la fille » (Johnson) d’exécuter les mêmes nombres dans les mêmes équations que celles programmées dans l’ordinateur, mais à la main, sur sa machine à calculer mécanique de bureau. « Si elle dit qu’ils sont bons », se souvient Katherine Johnson, « alors je suis prêt à partir ». Le vol de Glenn fut un succès et marqua un tournant dans la compétition entre les États-Unis et l’Union soviétique dans l’espace.1

Elle aura aussi calculé la synchronisation du module lunaire d’Apollo 11 avec le module de commande et de service en orbite lunaire, ce qu’elle considérait comme sa plus grande contribution à la conquête de l’espace. Elle a travaillé aussi sur les navettes spatiales (Space Shuttle) et sur le programme d’observation de la Terre à des fins civiles Landsat (en).

En 2015, Barack Obama la décore de la plus haute décoration américaine : la médaille présidentielle de la Liberté.

Mary Jackson (1921 – 2005), l’ingénieure

Mary Jackson naît le 9 avril 1921 à Hampton, Virginie où elle passera toute sa vie. En 1942 elle obtient un BS en mathématiques et sciences physiques au Hampton Institute. Elle commence sa carrière professionnelle comme ses deux collègues en tant qu’enseignante dans un établissement d’enseignement pour enfants noirs. Après d’autres emplois (réceptionniste, comptable, secrétaire militaire), elle est embauchée par le NACA et rejoint la section de calcul de la zone ouest en 1951 dirigée par Dorothy Vaughan.

Deux ans après, elle reçoit une proposition de travail pour l’ingénieur aéronautique Kazimierz Czarnecki (en) (qui a un homonyme polonais et althérophile) sur la soufflerie supersonique. Il lui suggère de suivre une formation pour devenir ingénieure. Ce qu’elle fera avec succès, non sans avoir eu à obtenir une autorisation spéciale de la ville de Hampton pour suivre les cours car ils se déroulaient dans l’école secondaire, blanche, de la ville. Elle deviendra la première ingénieure afro-américaine de la NASA en 1958. Elle écrira aussi, avec Czarnecki, cette même année « Effects of Nose Angle and Mach Number on Transition on Cones at Supersonic Speeds » (en). Dans ses fonctions d’ingénieure aérospatiale, son travail portera sur l’analyse des données des expériences en souffleries et en vol à des vitesses supersoniques.

De 1958 à 1975, elle aura écrit en tout douze documents techniques pour le NACA et la NASA.

Elle change d’orientation en 1976 (avec diminution de salaire), sa carrière étant bloquée pour œuvrer en faveur de l’embauche et de la promotion de la nouvelle génération d’ingénieures, de mathématiciennes et scientifiques de la NASA. Elle prendra sa retraite en 1985. Mary Jackson meurt le 11 février 2005.

Le siège de la NASA à Washington DC est rebaptisé a sa mémoire en 2020 et s’appelle désormais le « Mary W. Jackson NASA Headquarters ».

Remarques incidentes

Les trois femmes ainsi portraiturées ont fait l’objet d’un film sorti en 2016 : «Hidden Figures » (Les Figures de l’ombre). Dans les pages qui leur sont consacrées sur le site de la NASA (en), le nom de l’actrice associée à chaque rôle dans le film est ajouté. Je me suis beaucoup inspirée de ces pages d’ailleurs. Il y a aussi, probablement, dans tout cela une excellente affaire de marketing dont on n’a pas l’équivalent pour la Russie qui a une histoire politique plus compliquée.

Ceci n’était que le premier volet, celui des calculatrices humaines. Le prochain consacrera une partie à l’environnement informatique, tant aux USA qu’en Russie. Il y aura aussi des portraits de femmes (américaines, mais si vous avez des noms et des liens d’informaticiennes russes à suggérer…) dont, évidemment Margaret Hamilton.

Cette dépêche ne saurait se terminer sans remercier vmagnin et Benoît Sibaud d’avoir pensé à mes longues soirées d’automne en m’ouvrant d’autres portes parce qu’en fait ce texte aurait dû n’être qu’en une seule partie et plus court.


  1. Biographie de Katherine Johnson (en sur le site de la NASA. 

Commentaires : voir le flux Atom ouvrir dans le navigateur

Haiku a 23 ans - Haiku R1 bêta 5 (partie 3 : documentation, finances et GSOC)

Les deux parties précédentes ont présenté les principales évolutions dans le code de Haiku. Mais le code ne fait pas tout.

Cette troisième (et dernière) partie présente les nouveautés dans la documentation, ainsi qu’un court aperçu du rapport financier et aux dons qui permettent à Haiku d’employer un développeur à plein temps de façon durable.

Enfin, elle présente la participation au Google Summer of Code et les travaux réalisés par les cinq étudiants encadrés par Haiku cette année.

Sommaire

Documentation

La documentation de Haiku se découpe en 3 parties principales : un manuel de l’utilisateur, une documentation d’API, et une documentation interne pour les développeurs qui travaillent sur les composants du système.

Ces documents sont complétés par de nombreuses pages et articles sur le site Internet, et deux livres pour apprendre à programmer en C++ avec Haiku, ou encore un document de référence pour la conception d’interfaces graphiques et un autre pour le style graphique des icônes.

Documentation d’API

La documentation d’API de BeOS était assez complète et de bonne qualité. L’entreprise Access Co Ltd qui a hérité de la propriété intellectuelle de BeOS a autorisé le projet Haiku à la réutiliser et à la redistribuer. Malheureusement, cette autorisation est faite avec une licence Creative Commons n’autorisant pas les modifications. Cette documentation ne peut donc pas être mise à jour, ni pour corriger les erreurs, ni pour ajouter des informations sur toutes les nouvelles fonctions ajoutées par Haiku ou les différences entre les deux systèmes.

Il est donc nécessaire de réécrire une nouvelle documentation à partir de zéro. Ce travail est assez ingrat lorsqu’il s’agit de re-décrire ce qui est déjà très bien expliqué dans la documentation existante. La nouvelle documentation a donc tendance à se concentrer sur les nouvelles fonctions, et il faut souvent jongler entre les deux documentations, le contenu des fichiers .h, et des exemples de code d’applications existantes pour découvrir toutes les possibilités offertes.

Il ne semble pas utile de lister chaque fonction ou méthode qui a été documentée. On peut mentionner une page d’explications sur la bibliothèque C standard, comprenant des liens vers les spécifications POSIX qui documentent déjà la plupart des choses, et quelques détails sur les différences avec d’autres systèmes.

Une autre nouvelle page documente les primitives de synchronisation qui sont disponibles pour le code s’exécutant dans le noyau.

Documentation interne

La documentation interne était à l’origine simplement une accumulation de fichiers dans divers format dans un dossier « docs » du dépôt Git de Haiku. Depuis 2021, ces fichiers ont été rassemblés et organisés à l’aide de Sphinx, qui permet de mettre à disposition une version navigable en HTML et de donner une meilleure visibilité à ces documents.

D’autres pages sont petit à petit migrées depuis le site web principal de Haiku, qui n’est pas un très bon support pour de la documentation, et bénéficiera un jour d’une refonte pour être plus tourné vers les utilisateurs que vers les développeurs.

Quelques nouvelles pages ajoutées cette année:

  • Une documentation sur l’utilisation de divers outils de complétion de code automatique avec le code source de Haiku
  • Une page présentant l’organisation du code source et les principaux dossiers et sous-dossiers
  • La documentation de l’outil rc utilisé pour compiler les « resources » attachées aux exécutables a été intégrée
  • Le système de fichier FAT a reçu également une page de documentation à l’occasion de sa réécriture

Un point sur le financement

L’association Haiku inc qui gère le compte en banque de Haiku publie chaque année un rapport financier.

Le financement provient principalement de dons des utilisateurs et soutiens de Haiku. Le projet reçoit également une compensation financière de Google pour le temps passé à encadrer les participants du Google Summer of Code (voir le paragraphe suivant). La contribution de Google cette année est de 3 300$.

Les plateformes de don les plus utilisées sont Paypal et Github sponsor. Ce dernier est recommandé car, pour les dons reçus via Github, c’est Microsoft qui paie les frais bancaires de la transaction. 100% de l’argent donné arrive donc sur le compte de Haiku. Tous les autres opérateurs ont un coût, soit fixe lors des retraits, soit un pourcentage de chaque don, soit un mélange des deux.

En 2023, l’association a reçu 25 422$ de dons et a dépensé 24 750$. Elle dispose d’une réserve confortable de 100 000$ (accumulés avant 2021, alors qu’il n’y avait pas de développeur salarié) ainsi que d’environ 150 000$ en cryptomonnaies.

Les dons en cryptomonnaies sont pour l’instant bloqués sur un compte Coinbase suite à des problèmes administratifs (le compte n’est pas correctement déclaré comme appartenant à une association, il faudrait donc payer un impôt sur le revenu lors de la conversion en vraie monnaie). Il semble difficile de contacter Coinbase pour régler ce problème.

Du côté des dépenses, le poste le plus important est le paiement de 21 000$ à Waddlesplash, développeur employé par Haiku inc pour faire avancer le projet Haiku. Il travaille à temps partiel et avec un salaire très bas par rapport au marché, comme cela a été fait pour les précédents contrats entre Haiku inc et d’autres développeurs. Les finances de l’association ne permettent pas encore d’assurer un emploi à plein temps avec un salaire correct sur le long terme (c’est faisable sur le court ou moyen terme à condition de puiser dans les réserves de trésorerie).

Le reste des dépenses concerne principalement le paiement de l’infrastructure (serveurs pour le site Internet, l’intégration continue, hébergement cloud pour les dépôts de paquets) pour environ 3 000$.

Il faut enfin compter environ 500$ de frais Paypal, puis quelques dépenses administratives (déclaration de changement d’adresse de l’association, déclaration d’embauche) pour des montants négligeables (moins de 10$ au total).

En 2024, l’objectif fixé en janvier était de récolter 20 000$ de dons supplémentaires. Cet objectif a été atteint dès le mois de juillet, et a donc été révisé pour tenter d’atteindre les 30 000$. Cela permettra de rémunérer Waddlesplash pour un plus grand nombre d’heures cette année, ou bien d’envisager l’embauche d’une deuxième personne si un ou une candidate se présente parmi les personnes contribuant au projet (l’embauche d’une personne extérieure ne se fera pas tant que l’association ne peut pas se permettre de proposer une rémunération raisonnable).

Google Summer of Code

Haiku participe au Google Summer of Code depuis 2007. Il s’agit d’un programme où des étudiants (et d’autres participants pas forcément étudiants, ces dernières années) sont payés par Google pendant deux mois pour découvrir la contribution à des projets de logiciels libres.

Ce programme a été monté par « l’Open source program office » de Google. Leur intérêt est de défendre leur image d’entreprise sympathique (bien mise à mal ces dernières années, c’est devenu un géant de la publicité en ligne et de l’aspiration des données personnelles), et de contribuer à la richesse d’un écosystème de logiciels libres dont ils bénéficient beaucoup. Cela permet aussi d’encourager des personnes à s’essayer au développement logiciel, facilitant indirectement le recrutement chez Google en augmentant le nombre de candidats. Ces justifications peuvent sembler hypothétiques ou très indirectes, mais elles ont convaincu Google d’attribuer un budget de quelques millions de dollars à ce programme.

Une équipe de Google choisit les projets de logiciel libres participants parmi de nombreuses candidatures. Chaque projet participant propose une liste « d’idées » (un peu sous la forme d’un sujet de stage) et a ensuite la responsabilité de choisir parmi les candidats qui ont répondu à cette offre (en respectant les critères de non-discrimination imposées par Google ainsi que les embargos imposés par les USA), et d’assurer l’encadrement des personnes sélectionnées. Google rémunère les participants, et dédommage les projets participants pour le temps investi.

Cette année les développeurs de Haiku encadrent cinq participants :

Calisto Mathias — Re-design de la fenêtre de recherche de fichiers

Le système de fichier BFS utilisé par Haiku permet l’exécution de requêtes (comme une base de données) exploitant les attributs étendus des fichiers, qui peuvent être indexés.

Ce système permet de faire beaucoup de choses, et la fenêtre de recherche du navigateur de fichier essaie d’en tirer parti. Cependant, l’interface résultante est trop complexe, et peu de personnes prennent le temps de concevoir des requêtes améliorant leur façon de travailler, se cantonnant aux quelques exemples fournis.

L’objectif de ce projet est de refondre l’interface de cette fenêtre pour obtenir quelque chose de plus intuitif, et également d’afficher en temps réel les résultats de la requête dès qu’elle est modifiée, pour encourager les utilisateurs à expérimenter avec des requêtes plus complexes.

Daniel Martin — Virtualisation matérielle accélérée avec NVMM

Haiku n’est pas encore parfait, et certaines tâches nécessitent encore l’utilisation d’autres systèmes d’exploitation. Une partie des utilisateurs ont donc une configuration en double boot, ou bien lancent Haiku dans une machine virtuelle.

L’objectif de ce projet est de permettre d’utiliser Haiku comme système principal, et de lancer les autres systèmes dans des machines virtuelles. Cela sera réalisé à l’aide d’un portage de NVMM, qui a été développé à l’origine par NetBSD et Dragonfly BSD. Cette bibliothèque a l’avantage d’être bien documentée et conçue pour faciliter son adaptation vers d’autres systèmes.

NVMM sera complétée par l’utilisation de QEMU qui pourra fournir un « front-end » à cette mécanique.

Diego Roux — Pilote pour les cartes sons virtuelles VirtIO

Pour les personnes utilisant Haiku dans une machine virtuelle, il est intéressant d’utiliser autant que possible la famille de périphériques VirtIO.

Il s’agit de périphériques virtuels conçus sans s’inspirer de matériel existant, et plutôt pour avoir l’interface la plus simple possible entre la machine virtualisée et son hôte.

Haiku dispose déjà d’un jeu de pilote Virtio relativement complet (réseau, stockage de masse, affichage graphique). Le but de ce projet est de compléter cet ensemble avec un pilote pour les cartes son VirtIO.

trungnt2910 — Portage de GDB

Haiku dispose de son propre débugger (appelé Debugger, de façon assez peu originale). Ce dernier présente une interface graphique confortable, mais une interface en ligne de commande beaucoup plus limitée. Il souffre également de quelques problèmes de performances et d’un manque de prise en charge des fichiers exécutables et bibliothèques compilés avec autre chose que GCC. Il est également incapable de faire du debug à distance ou de s’intégrer dans une interface graphique existante (par exemple au sein d’un IDE).

L’objectif de ce projet est de ressusciter la version de GDB ciblant Haiku. Cette version très ancienne était utilisée avant l’apparition du Debugger natif. Le projet est en bonne voie, le code d’interfaçage a été entièrement réécrit pour s’adapter aux versions modernes de GDB, et plusieurs évolutions et corrections ont été intégrées dans le système de debugging de Haiku (par exemple, pour mettre en pause tous les threads nouvellement créés afin que le debugger puisse les intercepter).

Zardshard — Migration du navigateur web WebPositive vers WebKit2

Le navigateur WebPositive utilise le moteur de rendu webKit. Actuellement, il s’interface avec ce moteur via l’API WebKitLegacy. Cette API exécute tout le moteur de rendu web dans un seul processus, et ne fournit pas les garanties d’isolation nécessaires pour les navigateurs web modernes (que ce soit en termes de sécurité, ou en termes de fiabilité).

L’objectif de ce projet est de reprendre les travaux déjà entamés en 2019 pour migrer WebPositive vers la nouvelle API « WebKit2 », et bénéficier d’une séparation entre l’interface graphique, la communication réseau, et le rendu HTML/CSS/JavaScript dans des applications séparées. Ainsi, un crash d’un de ces composants peut être récupéré de façon transparente sans faire disparaître toute l’application (et les données non enregistrées de l’utilisateur avec).

Le projet est également en bonne voie, un navigateur de test permet déjà d’afficher quelques pages ce qui montre que les bases sont en place. Il reste à régler de nombreux problèmes de rendu de texte, ainsi qu’à implémenter la gestion des entrées (clavier et souris) pour avoir un navigateur web utilisable. Il faudra ensuite migrer WebPositive vers ces nouvelles APIs.

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌