❌

Vue lecture

↗️

Haiku a 24 ans - nouvelles de l'été 2025

✇LinuxFr.org : les dépêches
Par :pulkomandy · Benoît Sibaud · orfenor · Arkem · palm123

Haiku est un système d’exploitation pensé pour les ordinateurs de bureau. Il est basé sur BeOS mais propose aujourd’hui une implémentation modernisée, performante, et qui conserve les idées qui rendaient BeOS intéressant: une interface intuitive mais permettant une utilisation avancée, une API unifiée et cohérente, et une priorisation de l’interface graphique par rapport à la ligne de commande pour l’administration du système.

Le projet est actuellement (depuis 2021) en phase de beta test. La plupart des fonctionnalités sont implémentées et l’attention des développeurs se porte sur la correction de bugs, l’amélioration de la stabilité et des performances, et plus généralement, les finitions et petits détails. Une autre part du travail est le suivi de l’évolution de l’environnement technologique: nouveaux pilotes de périphériques, suivi des derniers standards du web, etc.

Les trois derniers mois ont été un peu plus calmes que d’habitude pour Haiku, mais cela est largement compensé par une très forte activité du côté de Haikuports. Cela révèle que le système lui-même devient plus mature et qu’il devient de plus en plus facile de développer ou de porter une application sans tomber sur des problèmes du système qui doivent être corrigés au préalable.

Sommaire

Applications

Tracker

Tracker est le navigateur de fichiers de Haiku. Le code est hérité directement de BeOS (cette partie avait été publiée sous licence libre lors de l’abandon de BeOS par Be) et fait l’objet depuis de nombreuses années d’un gros travail de nettoyage et de modernisation.

Pas de grosses nouveautés ces derniers mois, mais des corrections pour plusieurs régressions suites à du nettoyage effectué précédemment. Par exemple, les icônes des disques montés sont à nouveaux affichés sur le bureau dans les dialogues d’ouverture et d’enregistrement de fichiers. L’annulation du filtrage du contenu d’un dossier en tapant un nom de fichier partiel est correctement annulé si on appuie sur échap.

Enfin, des problèmes de synchronisation de l’icône de la poubelle, qui apparaissait pleine alors qu’elle était vide, ont été corrigés. Ces problèmes étaient déjà présents dans BeOS.

Terminal

Le terminal permet de lancer des applications en ligne de commande.

Un chantier en cours consiste à rendre le terminal utilisable comme un “replicant”, c’est-à-dire de pouvoir l’intégrer dans d’autres applications telles que l’IDE Genio. Cette approche demande de restructurer beaucoup de choses, et pour l’instant, il est plus simple pour les développeurs de Genio de recopier une partie des sources du Terminal dans leur projet et de les intégrer de façon plus statique. Les problèmes sont corrigés petit à petit.

Une autre correction mérite d’être mentionnée: le terminal se plaçait lui-même dans le dossier de travail du shell lancé lors de l’ouverture d’un nouvel onglet. Si ce dossier se trouve dans un disque qu’on essaie par la suite de démonter, le démontage échoue (même si l’application lancée dans le terminal a elle-même changé de dossier entretemps). Désormais le terminal ne modifie pas son dossier actif et ne bloque plus le démontage des disques.

Mail

L’application Mail permet de lire et d’envoyer du courrier électronique. Elle est composée d’un serveur de synchronisation et d’une interface graphique indépendante. Entre les deux, les mails sont stockés sous forme de fichiers augmentés d’attributs étendus, ce qui permet d’utiliser Tracker et les requêtes BFS comme outil principal pour traiter les messages.

Les changements listés ici concernent l’application de lecture et rédaction de messages:

  • Correction du comportement du menu « Fermer et marquer comme… » lorsqu’il est appliqué à plusieurs messages.

    • Modifications pour éviter de montrer des informations vides, en double, ou absentes dans les détails des adresses mail (nom d’expéditeur, de destinataire, etc).

HaikuDepot

HaikuDepot est à la fois le gestionnaire de paquets et le magasin d’applications de Haiku. Ce double rôle conduit pour l’instant à une interface qui prête un peu à confusion, et l’interface devrait être repensée pour un fonctionnement plus intuitif. En attendant, quelques petites améliorations ont tout de même été faites pour rendre les problèmes moins gênants.

Lorsqu’une recherche dans la vue « paquets mis en avant » ne donne aucun résultat, il y a affichage d’un lien permettant de poursuivre la recherche dans la liste complète des paquets. En effet, de nombreux utilisateurs se sont plaints de ne pas trouver certains logiciels en effectuant une recherche, sans se rendre compte qu’ils faisaient une recherche dans une liste de quelques dizaines de paquets et pas dans tout ce qui est disponible.

TextSearch

TextSearch est un outil de recherche dans le contenu des fichiers par expressions régulières (une version graphique de grep).

Il reçoit ce trimestre une fonction pour filtrer les fichiers à rechercher, équivalent à l’option grep --include.

Debug Analyzer

Debug Analyzer est un outil de profiling et d’analyse de traces d’exécution.

Correction d’un problème de compilation suite à des changements dans l’API de BObjectList (cet outil n’est pas compilé par défaut, il avait donc été oublié lors du changement d’API au trimestre précédent).

Préférences d’apparence

Dans la configuration des couleurs du système, renommage de la couleur « barre d’état » en « barre de progression ». Le nom « barre d’état » (status bar en anglais) correspond à la classe BStatusBar utilisée par BeOS et Haiku, mais tout le monde appelle ça une barre de progression. On peut au moins éviter la confusion pour les utilisateurs, à défaut de pouvoir le faire pour les développeurs d’applications en renommant la classe elle-même (ce qui causerait des problèmes de compatibilité d’API et d’ABI).

Utilisation de IconMenuItem

Ce changement concerne l’application ShowImage (visualiseur d’images) ainsi que FileTypes (les préférences d’association de types fichiers avec des applications). Ces deux applications utilisent un menu pour sélectionner une application (pour ouvrir une image dans un éditeur, ou pour associer un type de fichier à une application, respectivement).

Les applications pour Haiku utilisant des icônes colorées et facilement identifiables, c’est beaucoup mieux qu’une liste de noms pour s’y retrouver rapidement. Ces deux applications utilisent donc maintenant des IconMenuItem dans ces menus, pour afficher les applications avec leur icône respective.

Adaptation aux écrans à très haute réolution

Un travail en cours sur les applications concerne l’adaptation aux écrans à très haute résolution.

Presque toutes les applications pour Haiku utilisent un système de mise en page dynamique, et toutes les ressources (police de caractères, icônes…) sont vectorielles. Cela permet en théorie d’afficher l’interface avec un niveau de zoom arbitraire. Cependant, une partie du code a été écrit avec des tailles en pixels « en dur » et ne s’adapte pas comme il faudrait (la bonne façon de faire est de se baser par exemple sur la taille de la police de caractères sélectionnée par l’utilisateur).

Ce trimestre, on trouve des évolutions à ce sujet dans plusieurs applications:

  • Expander (décompression d’archives)
  • SerialConnect (communication par port série)
  • Mise à l’échelle de la barre de défilement
  • Préférences d’imprimantes
  • Mise à l’échelle des icônes

Outils en ligne de commande

Remote Desktop

L’outil de connexion au bureau à distance n’est pas vraiment une application en ligne de commande. Cependant, il nécessite pour l’instant un lancement depuis un terminal avec les bonnes options, et selon les cas, la mise en place d’un tunnel SSH. Une interface grapique plus simple d’uitlisation sera probablement ajoutée plus tard.

  • Amélioration du parsing de la ligne de commande et en particulier de l’option pour choisir un port SSH
  • Activation de l’option SO_REUSEADDR permettant de plus facilement relancer l’outil s’il plante, sans attendre un timeout de la connexion précédente qui n’a pas été fermée proprement

Time

Le panneau de préférences de date et heure peut être lancé en ligne de commande avec une option spécifique pour forcer une synchronisation NTP. Cette fonctionnalité n’est pas vraiment documentée, à l’origine il s’agit plutôt d’une astuce interne au système. L’application reconnaît maintenant l’option --help standardisée et affiche un message d’aide qui documente cette fonctionnalité.

Il peut être utile de relancer cette commande manuellement si jamais la synchronisation au démarrage n’a pas fonctionné (par exemple si le réseau n’était pas disponible à ce moment-là). En particulier, cela peut être utilisé dans des scripts d’automatisation et pour des machines où l’interface graphique n’est pas facilement accessible (serveurs de build par exemple).

pkgman

pkgman est une commande permettant d’installer, mettre à jour et rechercher des paquets logiciels.

Ajout d’une option --no-refresh pour ne pas retélécharger la base de données des paquets.

Cette base de données contient non seulement les noms des paquets, mais aussi leur description courte et la liste des “provides” (par exemple: commandes et bibliothèques fournies par chaque paquet). pkgman vérifié déjà si une nouvelle version de la base de données est disponible, mais cette dernière peut être mise à jour plusieurs fois par jour par l’intégration continue.

Le nombre de paquets augmentant, la taille de la base de données devient non négligeable (plusieurs méga-octets), ce qui pose problème en particulier pour les utilisateurs et développeurs ne disposant pas d’un accès internet illimité.

su

La commande su est peu utilisée puisque l’utilisateur par défaut a déjà tous les droits. Son implémentation était donc un peu incomplète. Elle peut toutefois être utile pour avoir des utilisateurs supplémentaires restraints, par exemple pour un accès à distance par ssh.

  • La commande su ne demande pas de mot de passe si l’utilisateur dispose déjà de l’accès root
  • Toutes les commandes liées à la gestion des utilisateurs (su, login…) configurent les groupes actifs lors du changement d’utilisateur

listarea

listarea est une commande de debug permettant de lister les zones mémoire allouées à différentes applications. Elle affiche maintenant le verrouillage et les protections de ces zones (swappable ou non, exécutabele ou non, accessible en écriture ou non).

fdinfo

fdinfo permet d’examiner les descripteurs de fichiers ouverts (un peu comme lsof). Cette commande peut maintenant afficher en plus le dossier courant de chaque application (ce qui aurait été bien utile pour identifier le problème avec le dossier courant du Terminal ci-dessus).

install-wifi-firmwares

Ce script permet d’installer les firmwares pour certaines très anciennes cartes Wifi. Les firmwares publiés à l’époque sont disponibles avec des licenses n’autorisant pas la redistribution ou les modifications de packaging, ce qui empêche l’intégration dans le système de paquets habituel. Le problème a été corrigé depuis longtemps par les fabricants de cartes Wifi, mais les anciens firmwares n’ont jamais été republiés avec des licenses mises à jour.

Le script a été mis à jour pour récupérer certains firmwares depuis un nouveau serveur, l’ancien emplacement utilisé n’étant plus disponible.

Kits

La bibliothèque de fonctions de Haiku est découpée en kits qui regroupent des ensembles de fonctions et de classes par thématique (stockage sur disque, interface graphique…). Dans certains cas il s’agit principalement d’une méthode d’organisation du code source et de la documentation (les kits pouvent être très interdépendants). Certains kits sont toutefois fournis sous forme de bibliothèques séparées.

Support kit

Ce kit contient diverses fonctions utilitaires et basiques du système.

Changement d’API pour la classe BUrl. Dans l’ancienne version de cette classe, il était possible de construire un objet BUrl représentant une URL encodée ou non-encodée (échappement des caractères réservés). Cela rendait trop facile d’oublier d’encoder une URL avant de l’utiliser, ou bien d’encoder plusieurs fois une URL et de se retrouver avec un lien invalide.

La nouvelle API impose d’indiquer dès la création d’un objet BUrl si la chaîne de caractères servant de base est déjà encodée ou non. L’objet BUrl construit représentera toujours une URL déjà encodée, qui peut éventuellement être décodée pour affichage si nécessaire.

Interface kit

Ce kit contient tout ce qui se rapporte à l’interface graphique: fenêtres, vues, contrôles, mise en page…

Retour en arrière sur une modification des raccourcis claviers de BTextView pour naviguer vers les mots suivant et précédent. Les nouveaux raccourcis entrent en conflit avec des raccourcis déjà utilisés par plusieurs applications, et n’apportaient pas grand-chose.

Correction de problèmes de compatibilité dans le format des données stockées par la classe BPicture (il s’agit d’un enregistrement de commandes envoyées au serveur graphique, qui peuvent être rejouées plus tard). Le format des données stockées était différent de celui de BeOS. Certaines applications utilisant un objet BPicture enregistré dans une ressource de l’application, ne s’affichaient pas correctement.

Amélioration de la gestion des sous-menus, en particulier cela corrige un crash si un sous-menu est fermé en utilisant la touche échap.

Remise à plat de tous les calculs accumulés au cours des années pour générer les couleurs de l’interface graphique en fonction des couleurs choisies par l’utilisateur. Chaque morceau de code concernait faisait ses propres calculs pour générer de jolis dégradés, des variantes plus sombres et plus claires, etc. Cela fonctionnait bien avec le thème par défaut, mais pas forcément avec des choix de couleurs qui en sont très éloignés. Le nouveau code est plus simple, plus prédictible, et permet de rassembler ces calculs dans la classe « control look », qui peut être remplacée par un add-on pour fournir une apparence complètement différente.

Cela peut nécessiter d’ajuster un peu les couleurs dans les préférences d’apparence si vous les avez personnalisées.

Storage kit

Ce kit regroupe tout ce qui concerne le stockage de masse et la gestion des fichiers.

Harmonisation de la nouvelle fonction BQuery::SetFlags avec d’autres fonctions similaires, et ajout d’une page de documentation pour cette fonction.

Correction d’un crash lorsqu’on enregistre un type MIME alors que le type parent n’existe pas (par exemple si on enregistre image/gif alors que le type image n’existe pas).

Ajout d’une constante pour identifier les systèmes de fichiers FAT16 parmi la liste des systèmes de fichiers connus.

Shared kit

Le shared kit contient des fonctions expérimentales en cours de développement mais déjà utilisées par plusieurs applications.

Contrairement aux autres kits, il est fourni sous forme d’une bibliothèque statique, ainsi chaque application peut en utiliser une version différente (choisie au moment de la compilation) et il n’y a pas de contraintes pour conserver une stabilité d’API ou d’ABI. Les fonctions développées dans le shared kit peuvent ensuite être migrées vers les autres kits une fois qu’elles sont finalisées.

La classe « color list » (utilisée par exemple dans les préférences d’apparence) accepte maintenant le glisser-déposer de couleurs.

Serveurs

Les serveurs sont des applications lancées au démarrage du système. Ils sont similaires aux services systemd. Ils fournissent des services utiles à l’implémentation de la bibliothèque standard, car tout ne peut pas être fait dans une bibliothèque partagée.

app_server

app_server regroupe le serveur graphique de Haiku (utilisé au travers de l’interface kit) ainsi que la gestion des applications en lien avec l’application kit.

Correction d’un problème d’initialisation de variables indiquant dans quels workspaces (bureaux virtuels) une fenêtre doit être présente. Cela se manifestait par l’apparition de morceaux incomplets de la fenêtre si on change de bureau virtuel pendant son apparition. Le bug existait depuis 15 ans mais n’avait jusque-là pas pu être identifié.

Les curseurs de souris ne sont plus générés en bitmap à la compilation à partir des sources vectorielles. C’est maintenant fait lors de l’initialisation du serveur graphique, ce qui permet d’avoir un plus gros curseur sur les écrans à très haute résolution.

input_server

input_server se charge des périphériques d’entrée utilisateurs (claviers, souris et autres périphériques de saisie et de pointage).

Correction de la keymap espagnole latino-américaine dans laquelle plusieurs combinaisons de touches ne fonctionnaient pas comme sur les autres systèmes.

Pilotes

ACPI, gestion d’énergie, système

Mise à jour de ACPICA pour la prise en charge de ACPI avec la dernière version disponible.

Correction de problèmes dans le pilote poke (permettant l’accès direct à la mémoire pour écrire certains pilotes en espace utilisateur) pour mieux valider les paramètres des ioctl et éviter de pouvoir facilement déclencher un kernel panic suite à une mauvaise utilisation du pilote.

Réseau

Correction d’un problème dans la pile TCP ou les retransmissions de paquets lors de l’établissement de la connexion n’étaient pas faits, si le premier paquet était perdu, la connexion ne s’établissait jamais.

Lorsque IP_HDRINCL est activé (une application demande à envoyer et recevoir elle-même les en-têtes IP des paquets reçus), la pile réseau s’assure tout de même que les en-têtes générés ont bien un checksum valide. Cela permet à traceroute de fonctionner correctement par exemple.

Mise en place de l’infrastructure pour la découverte de MTU deu chemin. Cela permet de déterminer la taille maximale des paquets qu’on peut envoyer vers un serveur, sans que de la fragmentation IP soit mise en jeu en cours de route (ce qui, au mieux dégraderait les performances, au pire empêcherait la connexion de fonctionner correctement):

  • Ajout de l’option IP_DONTFRAG pour demander aux routeurs de ne pas redécouper certains paquets,
  • Remontée de l’information ICMP FRAGMENTATION_NEEDED pour détecter qu’on a essayé d’envoyer un paquet trop gros.

Cela permet déjà de détecter les problèmes de MTU, mais pas encore de les corriger automatiquement. La suite du code est encore en cours de test.

Remplacement du pilote iprowifi3945 par la version mise à jour disponible dans OpenBSD (pilote “wpi”) à la place de celle de FreeBSD qui est actuellement moins bien maintenue.

Interface homme-machine

Ajout de la tablette Intuos 4 dans le pilote pour les tablettes Wacom, ainsi que du support de la molette présente sur certaines tablettes.

Systèmes de fichiers

NFS4

NFS est un système de fichier en réseau. Une machine serveur se charge réellement du stockage des fichiers, et d’autres machines peuvent monter ce disque et accéder aux fichiers partagés. Plusieurs machines peuvent accéder au même serveur en même temps et modifier les fichiers, ce qui nécessite une attention particulière lors de l’implémentation d’un système de fichier client.

Le travail sur le pilote NFSv4 se poursuit pour le stabiliser et améliorer sa compatibilité avec les serveurs NFS existants.

Correction de problèmes de gestion du cache et de libération anticipée d’inodes`, points sur lesquels NFS est un peu inhabituel par rapport à d’autres systèmes de fichiers puisque des évènements peuvent arriver du serveur NFS concernant un fichier qui a été supprimé localement, par exemple.

Correction d’un problème qui pouvait conduire un fichier nouvellement redimensionné à contenir des données non initialisées au lieu d’octets à 0.

Cela permet de corriger des problèmes détectés par des tests NFSv4 existants pour d’autres systèmes.

EXT4

Le pilote ext4 permet de monter, en lecture et en écriture, les systèmes de fichiers ext2, ext3 et ext4 développés pour Linux.

Implémentation et activation de la fonctionnalité « metadata_csum_seed » qui est activée par défaut pour les systèmes de fichiers nouvellement créés sous Linux.

Corrections dans le « tree splitting » qui n’était pas implémenté correctement, empêchant d’accéder à des dossiers contenant un trop grand nombre de fichiers.

RAMFS

RAMFS est un système de fichiers non persistant, stockant les fichiers uniquement dans la RAM. Il est plus rapide qu’un système de fichier traditionnel.

Correction de crashs lors de la création de gros fichiers et lors du remplacement d’un hardlink par un autre fichier.

FAT

FAT est un système de fichiers développé par Microsoft pour DOS et les anciennes versions de Windows. Il est assez répandu et sert un peu de format d’échange standard en particulier pour les supports de stockage externes (clés USB, cartes SD, disquettes…).

Ajout d’assertions et de vérifications d’intégrité supplémentaires. Le pilote FAT utilisé actuellement provient de FreeBSD, dont les développeurs nous ont assuré qu’il était bien testé et maintenu. Mais, de façon similaire aux pilotes Wifi, on se rend compte que les bases d’utilisateurs de Haiku et de BSD ne sont pas du tout les mêmes, et nous sommes face à beaucoup de systèmes de fichiers FAT corrompus ou inhabituels, ce qui se produit peut-être moins souvent dans les utilisations de FreeBSD sur un serveur par exemple.

libroot

La libroot contient l’équivalent de la libc, libdl, libpthread et libm d’un système UNIX standard, ainsi que des fonctions bas niveau spécifiques à BeOS.

Les extensions GNU et BSD sont déportées dans des bibliothèques séparées (libgnu et libbsd), ce qui permet de respecter au mieux la spécification POSIX sans avoir à utiliser des astuces telles que des « weak symbols ».

Mise à jour de la libio

La bibliothèque standard de Haiku est à l’origine un fork de la glibc, utilisant exactement la même version que BeOS afin de garantir une compatibilité d’ABI optimale avec ce dernier. Cependant, cette version ancienne et obsolète ne répond pas aux besoins des applications modernes.

Petit à petit, des parties de la bibliothèque C sont donc remplacées par des composants venant de FreeBSD, NetBSD, OpenBSD ou plus récemment de musl. Certaines choses sont très bien standardisées et ne posent pas de problèmes, pour d’autres parties, des symboles internes de la bibliothèque sont exposés et parfois exploités par des applications (directement par des développeurs applicatifs pour contourner un bug, ou alors parce que les développeurs de la glibc ont mal isolé les choses et ont exposé des détails internes).

Ce trimestre, la partie libio (gestion des flux d’entrée-sortie) a été mise à jour avec la dernière version de la glibc. Il n’est pas possible d’utiliser une autre bibliothèque C pour cette partie sans casser l’ABI, mais la mise à jour est possible.

Correction de multiples problèmes dans les fonctions standard C et les extensions BSD:

  • Ajout d’une vérification de la locale passée à setlocale pour retourner une erreur si la locale demandée est invalide.

  • L’ouverture d’un chemin se finissant par un / avec open() échoue si le fichier n’est pas un dossier (par exemple open("/home/user/foo.txt/")).

  • Validation du paramètre “how” de la fonction shutdown() et retour d’une erreur si le paramètre n’est pas une valeur connue.

  • Les queues d’évènement créées par kqueue ne sont pas conservées lors d’un fork (même comportement que les BSD).

  • Un socket sur lequel il n’y a jamais eu d’appel à listen() ou connect() ne doit pas déclencher les erreurs EPIPE ni ENOTCONN.

  • La fonction socket() retourne maintenant les bons codes d’erreurs détaillés si elle ne peut pas créer le socket: EPROTOTYPE si le type de protocole est inconnu, EPROTONOSUPPORT s’il est connu mais pas disponible, EAFNOSUPPORT si la famille d’adresse n’est pas disponible. Auparavant, tous ces cas renvoyaient EAFNOSUPPORT.

  • Amélioration de la gestion des erreurs dans accept()

  • Gestion de cas particuliers pour bind() en UDP

  • Ajout de l’option RTLD_GROUP pour dlopen(). Il s’agit d’une extension développée par Solaris qui permet d’avoir plusieurs espaces de noms pour la résolution de symboles lors du chargement de bibliothèques partagées. En particulier, dosemu l’utilise pour fournir aux programmes DOS une bibliothèque C indépendante de celle de l’hôte (fournissant donc des fonctions memcpy, memset… qui entreraient en conflit avec celles de l’hôte). L’implémentation est triviale, car le même comportement était déjà en place pour la gestion des add-ons de BeOS; il n’était simplement pas accessible au travers de l’API POSIX dlopen(). Linux implémente ce flag sous un autre nom, cependant, la documentation de la glibc n’est pas correcte, et FreeBSD a implémenté ce qui est documenté pour la glibc avec le même nom. C’est pourquoi le nom utilisé par Solaris, qui n’est pas ambigu, est utilisé pour l’instant, en espérant que la méprise entre Linux et FreeBSD pourra être corrigée.

  • sethostname() retourne une erreur si le hostname proposé est trop long (auparavant il était simplement tronqué).

Intégration des changements de POSIX-2024

La spécification POSIX a été mise à jour en 2024. Cette mise à jour est assez importante grâce à un changement de la méthode de travail de l’Austin Group qui maintient la spéficication. Le groupe de travail a ouvert un bug tracker sur lequel il est possible de remonter des problèmes et de proposer des améliorations (à conditions que ces dernières soient déjà implémentées sous forme d’extensions sur un assez grand nombre de systèmes).

Cela a permis à plus de monde de prendre part à la spécification et de standardiser beaucoup de nouvelles choses. Haiku intègre ces changements petits à petits, parfois par anticipation, parfois parce que l’extension correspondante était déjà disponible, et parfois parce que le portage d’un logiciel le nécessite.

  • Ajout de O_CLOFORK, MSG_CMSG_CLOEXEC, et MSG_CMSG_CLOFORK pour fermer des descripteurs de fichiers lors d’un fork (équivalent de O_CLOEXEC qui ferme lors d’un exec, typiquement après un fork). Au passage, ajout dans la libbsd de closefrom() et closerange(), ces deux fonctions permettant de lancer des tests développés pour BSD pour ces nouveaux drapeaux.
  • Ajout de fdatasync(), une fonction qui s’assure que le contenu d’un fichier est bien enregistré sur disque et pas seulement dans le cache.

Améliorations sur la gestion de la mémoire

La gestion de la mémoire est un sujet central pour un système POSIX. L’API proposée (malloc, realloc, calloc et free) est à la fois très simple d’utilisation et très générique. Elle a donc tendance à être très sollicitée par les applications, ce qui en fait un composant critique de l’optilisation des performances du système. De plus, les applications sont de plus en plus consommatrices de mémoire et le matériel a tendance à en contenir de plus en plus.

L’allocateur mémoire a été remplacé il y a quelques mois, l’ancien allocateur hoard2 ne permettant pas d’agrandir dynamiquement l’espace alloué à une application. Après plusieurs essais, c’est pour l’instant l’allocateur d’OpenBSD qui a été retenu. En effet, beaucoup d’allocateurs plus modernes supposent un espace d’adressage 64 bit et sont peu économes en termes de réservation d’espace mémoire.

Cependant, même l’allocateur d’OpenBSD montrait ses limites sur les systèmes 32 bit. Son paramétrage a été amélioré, et d’autres modifications ont également été faites pour réduire la fragmentation de l’espace mémoire. Cela corrige des problèmes ou GCC ne parvient pas à allouer assez de mémoire lors de la compilation de très gros fichiers (par exemple lors de la compilation de clang ou de webkit). Il reste recommandé de désactiver l’ASLR (randomization de l’espace d’adressage) dans les cas où on a besoin de beaucoup de mémoire pour une application 32 bits.

Noyau

Le noyau de Haiku est un noyau monolithique tout à fait classique pour un système UNIX. Il permet le chargement dynamique de modules, et fournit une API relativement stable pour ces derniers, ce qui permet de maintenir des pilotes facilement en dehors du dépôt de sources de Haiku.

Correction de problèmes causant le kernel panic « failed to acquire spinlock for a long time » lorsque l’affichage à l’écran des logs du noyau est activé.

Ajout d’assertions supplémentaires dans le code de gestion de la mémoire virtuelle pour essayer de détecter des problèmes au plus tôt et avant de risquer de corrompre des données importantes.

Correction de l’affichage des paramètres des appels systèmes dans strace sur x86.

Correction de problèmes dans la gestion des permissions pour write_stat (modification des informations sur un fichier comme la date de modification) dans le noyau ainsi que dans les systèmes de fichiers RAMFS, BFS et EXT4. Cela corrige des comportements étranges observés lors de l’utilisation de rsync.

Ajout d’un test vérifiant le bon fonctionnement des exceptions remontées par le FPU lors de calculs en virgule flottante (ces exceptions sont un peu difficiles à traiter dans un système multitâche, et en particulier dans Haiku où le code du noyau peut lui-même utiliser le FPU alors que ce n’est pas le cas pour d’autres systèmes).

Correction de problèmes liés au découpage et au redimensionnement des areas (zones de mémoires allouées par les APIs prévues à cet effet de BeOS, ou indirectement par mmap et d’autres fonctions permettant de manipuler l’espace mémoire). Cela corrige des problèmes pour RAMFS ainsi qu’un kernel panic observé lors du lancement de dosemu.

Correction de problèmes avec les areas en lecture seule, qui pouvaient aboutir dans certains cas à une sous-évaluation de la mémoire utilisée, aboutissant à un kernel panic, car il n’y a plus de mémoire disponible à un moment où le noyau ne s’y attend pas. Cela a été mis en évidence en particulier avec l’utilisation mémoire de certains navigateurs web, qui ont tendance à gérer la mémoire directement sans passer par l’allocateur standard du système, pour des raisons de performance.

Remise en route de guarded_heap (un allocateur mémoire qui détecte les dépassements de buffers, au prix d’une consommation mémoire fortement augmentée). Correction de problèmes mis en évidence par cet allocateur dans quelques pilotes.

Dans la structure mcontext/ucontext passée aux fonctions de traitement de signaux, ajout de plusieurs registres manquants (registres de segments, addresse de faute…). Cela est utilisé par le JIT de dosemu et va probablement permettre d’utiliser le JIT dans d’autres applications également. En effet, une approche possible pour le JIT est de déclencher volontairement un signal, afin d’intercepter l’état des registres, éventuellement de le manipuler, puis de reprendre l’exécution là où elle s’était arrêtée.

Ajout de vérification de permissions manquantes dans l’appel système get_extended_team_info.

Correction d’une possible fuite d’un descripteur de fichier dans le VFS.

Bootloader

Mise à 0 de tous les registres non utilisés lors de l’appel de fonctions du BIOS, afin d’aider à investiguer des problèmes avec certains BIOS capricieux.

Amélioration des messages d’erreurs lorsque le bootloader ne parvient pas à charger le fichier ELF du noyau. Le chargeur de fichiers ELF du noyau est volontairement incomplet pour simplifier les choses (après tout, il a besoin seulement de charger le noyau), mais cela pose problème lors de mises à jour de GCC ou lors du portage sur de nouvelles architectures, si l’organisation du fichier ELF du noyau se trouve modifiée.

Correction de problèmes de compilation lorsque des logs de debug optionels sont activés.

Documentation

La documentation de Haiku se découpe principalement en trois parties:

  • Un guide de l’utilisateur,
  • Une documentation d’API pour les développeurs d’applications,
  • Une documentation d’implémentation pour les développeurs du système lui-même.

API (Haiku book)

Documentation de la classe BControl (classe abstraite qui fournit l’API standard de la plupart des contrôles utilisables dans l’interface graphique, les rendant interchangeables dans une certaine mesure).

Documentation de AdoptSystemColors et HasSystemColors pour la classe BButton.

Ajout de documentation pour les extensions à dlfcn.h par rapport à ce qui est déjà spécifié par POSIX.

Environnement de compilation

Haiku est écrit en C++ et utilise jam (un concurrent de make) comme outil principal de compilation. Cet outil a été retenu, car il permet de définir des règles de compilation génériques et réutilisables pour faire toutes sortes de choses. La compilation de Haiku pouvant mettre en jeu trois compilateurs différents (un pour le système hôte, un pour le système Haiku cible, et un troisième pour la couche de compatibilité avec BeOS), la plupart des autres outils ne répondent pas bien aux besoins.

Suppression de règles Jam redondantes. Jam repose sur des règles nommées pour savoir quelles actions sont nécessaires pour générer une cible à partir de sources. Les règles “Application”, “Server”, “Preferences” et “Executable” étaient toutes identiques, elles ont donc toutes été remplacées par “Application” pour simplifier le système de build.

Correction de “warnings” du compilateur pour des variables inutilisées et suppression de code mort (dans le cadre du maintien d’un code propre et lisible, une tâche plus ou moins continue pour suivre l’évolution des bonnes pratiques, la disponibilité de nouveaux outils d’analyse, et absorber la dette technique qui peut s’accumuler au cours d’un projet aussi ancien).

Début de support pour GCC 15: il est ajouté dans la liste des versions du compilateur reconnues pour le système hôte, ce qui permet de compiler Haiku depuis un système Linux très récent. L’intégration en tant que compilateur cible viendra plus tard.

Remplacement de la commande which utilisée dans certains scripts de build par l’équivalent command -v, ce qui évite une dépendance à une commande non standard qui n’est pas forcément installée par défaut partout.

Dans le makefile engine (un template de makefile proposé pour développer facilement des applications pour Haiku), ajout de documentation et d’exemples pour les variables INSTALL_DIR et TARGET_DIR.

Portage de Haiku sur d’autres CPUs

RISC-V

Correction d’un problème dans un script de link qui empêchait le démarrage du noyau.

Mise à jour de paquets utilisés pour compiler le système de base.

Mise en place d’un serveur de compilation de paquets pour RISC-V, ce qui permet de remplir le dépôt de paquets pour cette architecture et d’envisager une version officielle de Haiku pour RISC-V lors de la prochaine version bêta. L’architecture RISC-V s’ajoutera ainsi au x86 (32 et 64 bit) déjà supporté.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  
  • ↗️
↗️

Debian GNU/Linux 13 : prêt pour le service

✇LinuxFr.org : les dépêches
Par :j · daissi · Benoît Sibaud · palm123 · BAud · Florent Zara · anubis · orfenor

Précédemment chez Debian… Le contrat social a été modifié afin de permettre l’inclusion de microprogrammes non libres dès l’installation. « Les médias officiels peuvent inclure des microprogrammes qui autrement ne font pas partie du système pour permettre l’utilisation de Debian avec un matériel qui a besoin de ces microprogrammes ». (cf. épisode 12)

Bannière Debian 13

Debian GNU/Linux 13 — nom de code : Trixie — est sortie en version stable le 9 août 2025.

Cette nouvelle version repose sur un noyau Linux 6.12 (LTS) et la bibliothèque C de GNU 2.41 ; GCC 14.2, OpenJDK 21, Emacs 30.1 et VIM 9.1 sont inclus dans la distribution.

En termes d’environnements de bureau, GNOME 48, KDE Plasma 6.3 et Xfce 4.20 sont présents avec LibreOffice 25 et de nombreuses applications comme GnuCash 5.10, GIMP 3.0.4, Inkscape 1.4.

La distribution contient 69 830 paquets dont 14 116 nouveaux. Et pour gérer l’ensemble, APT a été mis à jour (version 3.0.3).

En termes de plateformes : PC 64 bits (amd64), ARM 64 bits (arm64), ARM EABI (armel), ARMv7 (ARM avec unité de calcul flottant, armhf), PowerPC 64 bits petit-boutiste (ppc64el), RISC-V 64 bit petit-boutiste (riscv64), IBM System z (s390x). L’architecture i386 n’est plus prise en charge comme les autres : pas d’installateur et moins de paquets sont disponibles, i386 est désormais destinée uniquement à être utilisée sur les processeurs 64 bits (amd64).

Le thème graphique de Debian 13 s’appelle Ceratopsian en référence à Trixie le triceratops de Toy Story 3.

Pour éviter le [[bug de l’an 2038]], Debian a basculé son horloge en 64 bits.

La précédente version stable (Bookworm) va être maintenue jusqu’en juin 2026, puis jusqu’en juin 2028 par le programme LTS.

Un statut concernant XMPP est détaillé pour les clients, serveurs, bibliothèques et passerelles/transports disponibles avec Trixie.

Clipart d'un Tricératops

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  
  • ↗️
↗️

S'informer sur la licence pro CoLibre (Communication et Logiciels Libres) - visio et plus

✇LinuxFr.org : les dépêches
Par :Mabillot Vincent · Benoît Sibaud · palm123

La licence professionnelle « CoLibre » (Métiers de la communication, conduite de projets et logiciels libres) ouvre sa seconde session de candidature jusqu’au 25 août 2025.

Pour mieux connaître ce parcours de formation, pour y candidater, pour proposer des alternances ou des projets tuteurés, des visios sont organisées pendant l’été.

Elles auront lieu le 24 juillet et le 18 août à 18h.

La licence pro forme en un an au métier de chef·f de projets en communication à l’ICOM (Université Lyon2) pour des personnes ayant acquis un bac+2 quelque qu’il soit.

Pendant une année, la formation organise un parcours varié pour acquérir et affirmer des compétences professionnelles dans les domaines de la communication, de la conduite de projet et les pratiques numériques.

Au fil du parcours, les étudiants et étudiantes vont aussi approfondir au choix une spécialisation : création numérique (PAO, infographie, audio-visuel, multimédia…), organisation (ressources humaines, pratique du changement, didactique, comptabilité…), développement (programmation, développement web, administration système…), événementiel (mercatique, planification, réseaux sociaux, gestion événement…).

Chaque fois que l’on utilise des logiciels ou des applications, elles sont systématiquement libres pour ajouter une connaissance approfondie et choisie du numérique en plus d’une approche éthique et inclusive.

Ce parcours est ouvert à toute personne ayant un bac+2 et elle peut être suivi en alternance, en formation continue ou en parcours classique.

À l’issue de la formation, les étudiantes et étudiants sont diplômés à Bac+3.

Attention la formation est réalisée en présentiel à l’Université Lyon2.

Annonce visios ouvertes

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  
  • ↗️
↗️

Agenda du Libre pour la semaine 30 de l'année 2025

✇LinuxFr.org : les dépêches
Par :Benoît Sibaud · palm123

Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 13 événements (France: 12, Internet : 1) est en seconde partie de dépêche.

Sommaire

[FR Grenoble] TupperVim - Le lundi 21 juillet 2025 de 19h00 à 23h00.

TupperVim à Grenoble ⛰️

Les TupperVim sont des réunions informelles d’utilisateurs et utilisatrices des éditeurs de texte libres Vim et neovim (débutant·es ou avancé·es) durant lesquelles chacun des participant·es échange des trucs et astuces.

La famille des éditeurs Vim étant très riche et hautement paramétrable, ces sessions sont l’occasion de s’initier à leurs utilisations, d’approfondir ses connaissances, d’échanger ses vimrc respectifs, ou encore de découvrir des greffons pour aller plus loin.

Toute personne, quel que soit son niveau, est la bienvenue.

Pour profiter au mieux de l’atelier, il est vivement conseillé aux débutant·es complets de faire le tutoriel Vim avant de venir (vimtutor).

On encourage les utilisateur·ices avancé·es qui le souhaitent à proposer une petite présentation rapide (~ 10 min) d’une fonctionnalité ou d’un plugin. Un support n’est pas obligatoire, une présentation en direct depuis Vim est tout aussi efficace.

Aussi, vous pouvez venir dès dix-neuf heures (19 h) pour avoir une séance d’initiation à Vim (prévoir une heure).

Vous pouvez annoncer une présentation sur l’Etherpad (lien en bas de message).

Traditionnellement, ces ateliers sont aussi l’occasion de découvrir des outils qui ne sont pas directement liés à Vim, mais qui s’inscrivent dans la même philosophie : ergonomie, minimalisme, efficacité.

Programme

La recette reste immuable depuis des temps immémoriaux :

  • 19 h à 22 h, grignotte : chacun·e amène quelque chose ;
  • 19 h à 20 h, initiation pour les débutant·es & apéro pour les initié·es, grâce à une technologie de parallélisation des tâches que le monde entier nous envie depuis toujours ;
  • 20 h à 22 h, enlarge your productivity : atelier participatif, chacun·e propose des sujets ou pose des questions techniques ;
  • 22 h à 23 h, on finit au bar 🍻

Important

  • Merci de vous inscrire sur meetup afin d’aider les organisateurs de l’événement.

  • Si vous avez des questions, des suggestions de contenu à présenter, et pour vous coordonner le contenu de l’apéro, tout cela est possible sur l’etherpad de l’événement.

  • La Turbine.coop, La Turbine.coop, 5 esplanade Andry Farcy, Grenoble, Auvergne-Rhône-Alpes, France

  • https://tuppervim.org

  • tuppervim, vim, atelier, initiation, séance, neovim, libre, réunion

[FR Chaumont] Permanence associative - Le mardi 22 juillet 2025 de 18h00 à 20h00.

Permanence associative du Schmilblik Numérique.

L'occasion de s'entraider dans nos usages des solutions libres au sein du Schmilblik, tiers-lieu dédié à la culture et la création artistique, à Chaumont.

Des boissons chaudes, de la bienveillance et beaucoup de convivialité.

Tous les niveaux techniques sont les bienvenus, de parfait·e débutant·e à expert·e chevronné·e.

[FR Le Mans] Permanence du mercredi - Le mercredi 23 juillet 2025 de 12h30 à 17h00.

Assistance technique et démonstration concernant les logiciels libres.

Il est préférable de réserver votre place à contact (at) linuxmaine (point) org 

Planning des réservations consultable ici.

[FR Le Blanc] Ateliers "Libres" de Linux - Le mercredi 23 juillet 2025 de 14h00 à 17h00.

Installer ou configurer Linux, diagnostiquer mon ordinateur,
installer ou configurer un logiciel libre,
échanger sur GNU/Linux et les Logiciels Libres,
trouver des réponses à mes questions

[FR Agen] Permanence d’aGeNUx - Le mercredi 23 juillet 2025 de 17h30 à 19h30.

Pour l’année 2025 notre association aGeNUx tiendra ses permanences tous les mercredis après-midi de 17h30 à 19h30 sauf les jours fériés et pendant les vacances d’été.

Elles ont lieu au Campus Numérique 47 à la salle Barjavel.

Ces permanences sont ouvertes à tous et à toutes, membres de l’association ou non. On peut s’y informer sur les logiciels libres, en tester, poser des questions ou tout simplement venir rencontrer d’autres utilisateurs de logiciels libres.

[FR Quimper] Redistribution gratuite d’ordinateurs de bureau sous Debian - Le jeudi 24 juillet 2025 de 09h30 à 10h30.

La distribution gratuite d’ordinateurs de bureau sous Debian au Centre social des Abeilles de Quimper continue tout l’été 2025 et même après…:-)

Le Centre des Abeilles, avec l’aide technique de Linux Quimper, récupère depuis 2009 des ordinateurs déclassées par des administrations et des entreprises. Ces ordinateurs sont reconditionnés avec des logiciels libres autour de Linux qui est un système équivalent à Windows et MacOs mais libre et gratuit. Ils sont utilisables immédiatement, gratuitement et en toute légalité dans tous les domaines de l’informatique comme la bureautique, internet, le graphisme, l’audio-vidéo, etc… Plus de 5500 ont été donnés depuis 2009 à des personnes et associations. Si cette action de solidarité vise à réduire la fracture numérique en permettant l’accès à l’informatique aux personnes et associations qui en sont écartées pour des raisons financières, elle a aussi pour but  de diffuser largement les logiciels libres et en particulier Linux. Elle a aussi pour objectif de limiter le gaspillage du matériel informatique, réduire les déchets et ainsi de participer à la limitation du changement climatique à notre petite échelle…

Ces dons sont ouverts aux adhérent·e·s du Centre des Abeilles. L’adhésion (13€) peut se faire au moment du don.

La distribution a lieu en général tout les jeudis matin mais les bénévoles du Centre des Abeilles peuvent s’adapter aux disponibilités des personnes désirant bénéficier de ce don.

ATTENTION: Cette proposition ne s’adresse qu’aux personnes habitant le Sud-Finistère.

Inscription préalable au 07 44 61 10 61.

[internet] Découverte de Scenari (en visio) - Le jeudi 24 juillet 2025 de 16h00 à 17h00.

🤔 Vous avez  des questions sur Scenari avant de tester ?

🧙‍♂️ Vous voudriez une petite démo ?

🚀 Vous commencer à utiliser Scenari et vous avez besoin d'un peu de soutien ?

Cette visio est faite pour vous 🤩

[FR Beauvais] Stand d'information sur Paheko, logiciel de gestion d'association (membres et compta) - Le jeudi 24 juillet 2025 de 18h00 à 20h00.

L'association Oisux est invitée par le Service de la Vie Associative de la Ville de Beauvais pour informer les visiteurs sur l'emploi du logiciel Paheko, qui permet de gérer l'activité d'une association:

"Paheko (mot de la langue Māori qui signifie « coopérer », illustrant le but du logiciel: améliorer ensemble le quotidien de la gestion d'une association) est un logiciel de gestion associative.
Il est l'outil de prédilection pour gérer une association, un club sportif, une ONG, etc.
Il est conçu pour répondre aux besoins d'une structure de petite à moyenne taille: gestion des adhérents, comptabilité, site web, prise de notes en réunion, archivage et partage des documents de fonctionnement de l'association, discussion entre adhérents." Source https://paheko.cloud/

[FR Vallauris - Sophia Antipolis] Rencontre Accès Libre - Le vendredi 25 juillet 2025 de 18h00 à 21h00.

Rencontres Accès Libre

Certains les appellent «install party», d’autres encore «Soirées Linux», mais les Rencontres Accès Libre sont tout cela en même temps, et bien plus encore…

Entre autres, c'est l’occasion de:

  • discuter, échanger, expliquer;
  • installer des logiciels libres;
  • et, toute autre idée coopérative de solidarité à but non lucratif!

C'est un évènement organisé conjointement par Linux Azur et le SHL.

[FR Nantes] Repair Café + Install Party - Le samedi 26 juillet 2025 de 09h30 à 12h00.

Un ordinateur qui rame ou qui refuse de démarrer, venez le réparer en notre compagnie.

Marre de Windows et envie d'un peu de liberté, venez le libérer!

Un ordinateur qui rame ou qui refuse de démarrer, venez le réparer en notre compagnie.

Marre de Windows et envie d'un peu de liberté, venez le libérer!

[FR Ploulec'h] Stand infothema avec Emmaüs - Le samedi 26 juillet 2025 de 10h00 à 18h00.

Le 26 juillet 2025 de 10h00 à 18h00, lors d'une vente exceptionnelle d'ordinateurs sous GNU/Linux par Emmaüs Lannion-Ploulec'h, l'association informatique bégarroise INFOTHEMA tiendra un stand de présentation de ses activités axées GNU/Linux et les logiciels libres.

Merci à la structure Emmaüs pour son accueil et sa bonne ambiance

Vive le Logiciel Libre !

[FR Ramonville Saint-Agne] Les ateliers du CULTe - Le samedi 26 juillet 2025 de 14h00 à 18h00.

Le CULTe est le "Club des utilisateurs de logiciels libres et de gnu/linux de Toulouse et des environs".

Le samedi après-midi tous les quinze jours, le CULTe organise un atelier d'informatique "libre", de 14h à 18h.

La séance est consacrée à l'information du public, à l'entraide entre membres et/ou visiteurs pour notamment installer et configurer des logiciels libres, système d'exploitation ("Linux") ou "applications" (programmes informatiques).

L'entraide peut également concerner le matériel afin d'aider le membre ou le visiteur a faire évoluer son ordinateur (ajout de mémoire, changement de disque dur…), étant précisé que si des avis peuvent être bien entendu émis pour de tels achats, le CULTe quand à lui n'a aucune activité commerciale, directe ou indirecte.

Chacun peut amener son ordinateur pour la séance. S'il s'agit d'une "Unité Centrale" (Ordinateur de bureau) il est inutile d'amener également écran clavier et souris, qui peuvent être prêtés sur place. Au besoin nous pourrons aussi vous prêter une machine pour la séance.

Afin de préparer votre venue, nous vous recommandons vivement de nous prévenir par courrier électronique en expliquant succintement votre projet ou votre besoin à l'adresse suivante:

president@o2.culte.org

L'adhésion au CULTe n'est en aucun cas obligatoire pour participer à nos activités.

NB: Les personnes qui souhaitent adhérer ou faire un don peuvent bénéficier d'un reçu fiscal en vue d'une réduction d'impôt (66% en 2022) notre association étant reconnue "Organisme d'Intérêt Général" éligible au mécénat. (Rescrit fiscal 2021/228)

PS: Notre club met à la disposition de tous une liste de discussion dédiée à l'informatique "libre": "linux-31@o2.culte.org". Vous pouvez sans attendre demander à y être inscrit pour, le cas échéant, y exposer une difficulté et bénéficier de l'aide et de conseils d'une centaine de participants. Il vous suffit de vous rendre à cette adresse et d'y formuler votre demande d'inscription:

https://sympa.culte.org/sympa/subscribe/linux-31?previous_action=info

[FR Quimper] Permanence Linux Quimper - Le samedi 26 juillet 2025 de 16h00 à 18h00.

Tous les samedis de 16h à 18h, Linux Quimper vous donne rendez-vous au centre social des Abeilles, 4 rue Sergent Le Flao (quartier de la Terre Noire) Quimper.

Nous vous proposons lors de ces rencontres d’échanger autour du Libre et de Linux en particulier

Vous pouvez venir pour vous faire aider, ou aider, à installer et paramétrer une distribution GNU/Linux de votre choix ou des logiciels libres sur votre ordinateur.

Recommandations:

  • Sauvegardez vos données avant de venir.
  • Pour une installation de Linux si vous voulez conserver Windows, libérez de la place sur le disque dur (20 Go minimum) et défragmentez Windows.
  • Nous prévenir, éventuellement, de votre passage via le forum.

Vous pouvez aussi venir pour une première prise d’informations et de contacts.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  
  • ↗️
↗️

Cryptographie embarquée : briques de base et communication avec serialguard

✇LinuxFr.org : les dépêches
Par :Nicolas Boulay · palm123 · Benoît Sibaud · HowardJuarez11

Il était une fois un petit ESP32, installé dans une cave, qui voulait communiquer avec son copain sur le toit pour envoyer des données par 4G. Il parlait peu, donc il pouvait utiliser la norme radio LoRa. Elle est à bas débit, mais permet une portée bien plus grande qu’une modulation classique. Le problème, c’est qu’il parlait en clair, et que n’importe qui pouvait écouter ou pire : injecter de fausses données, voire corrompre le serveur distant.

Le protocole de communication à la mode est celui de Signal, utilisé aussi par WhatsApp et Messenger. Un autre protocole en vogue est WireGuard, dont l’objectif est d’offrir un VPN léger pour Linux, en s’appuyant sur un ensemble restreint de briques cryptographiques modernes et fortement recommandées, qui ne sont plus laissées au choix de l’utilisateur.

L’idée était donc de trouver une implémentation de ce type pour l’embarqué. Eh bien, je n’ai presque rien trouvé.

Sommaire

Briques de base

TLS est la référence absolue pour tous les algos, mais c’est à vous de faire votre choix. Libsodium est une implémentation des derniers algos recommandés et fait le choix pour vous. Ces deux bibliothèques sont énormes et sont optimisées pour PC. Un professeur de cryptographie a écrit une série de tweets qui contient une petite lib qui reprend les algorithmes de libsodium en version auditable (https://tweetnacl.cr.yp.to/). Mais elle est lente.

Une autre personne écrit ce que je cherche : Monocypher. C’est un fichier .c avec les algo principaux de libsodium et qui compile en pur C sans dépendance ! C’est parfait pour mon besoin.

Cette bibliothèque fournit uniquement les briques de base, on est très loin d’un protocole Signal. Quand on parle de cryptographie, on pense à AES pour le chiffrement symétrique, à RSA pour le chiffrement à clef publique et la signature, aux hashs SHA1 ou SHA512 pour un hash de qualité cryptographique. Les propriétés nécessaires sont fascinantes mais cela ne dit pas comment bien les utiliser ensuite.

Le chiffrement symétrique

Il s’agit de chiffrer un bloc avec une clé de taille fixe. Le représentant le plus connu est AES, avec des clés de 128 ou 256 bits. On a un bloc, on a une clé, et on obtient un bloc plus ou moins aléatoire. AES utilise des modes (GCM, XTS, …) pour renforcer le mélange et garantir la sécurité selon différents contextes.

Ici, l’algorithme recommandé est ChaCha20. Pas besoin de mode externe : tout est prévu dans l’algorithme de base.

Au déchiffrement, la brique ne se pose pas de question : si la donnée a été altérée, le résultat le sera aussi.Il faut donc ajouter un protocole d’authentification, qui utilise la même clé et un hash pour vérifier l’intégrité. Les algorithmes classiques sont MAC, HMAC, mais il est facile de faire une erreur dans leur utilisation.

Monocypher utilise Poly1305 pour authentifier le message (AEAD – Authenticated Encryption with Associated Data). Son API combine XChaCha20 et Poly1305, ce qui évite de se poser des questions : en cas de modification du message chiffré, la fonction de déchiffrement renvoie une erreur explicite.

Cette fonction nécessite un NONCE ("Number used once"), qui doit être différent à chaque appel.

Le hash

Un hash prend un bloc de données, fait une grosse salade et rend un chiffre de taille fixe avec de bonnes propriétés crypto. Le but est d’avoir une empreinte de taille fixe pour un bloc de données, et qu’il soit impossible de forger un hash identique en modifiant un peu les données d’origine. En gros.

Le hash recommandé est BLAKE2b : “as secure as SHA-3 and as fast as MD5”. Il fait 256 ou 512 bits.

“Password hashing” ou la création de clef à partir de mot de passe

Lorsqu’un mot de passe est saisi, il n’est jamais utilisé tel quel : il est d’abord transformé en une valeur de taille fixe via une fonction de hachage. Pour contrer les attaques par force brute, on a commencé par appliquer des centaines d’itérations de SHA1, avant d’adopter des fonctions de hachage volontairement lentes, comme bcrypt ou scrypt. Le but étant justement d’éviter qu’elles soient rapides, contrairement aux fonctions de hachage classiques.

Aujourd’hui, Argon2 est recommandé.

Chiffrement à clef publique

L’image est souvent celle d’un cadenas ouvert : n’importe qui peut fermer le cadenas, mais seul le possesseur de la clef peut l’ouvrir. RSA a été le premier algorithme inventé avec cette propriété. Aujourd’hui, la mode est aux courbes elliptiques avec X25519.

La fonction principale est basée sur l’échange Diffie-Hellman (DH). C’est le truc magique de la crypto asymétrique.

DH(Clef publique de A, Clé privée de B) = DH(Clef publique de B, Clé privée de A) = N

Sans une clef privée, il est cryptographiquement impossible de retrouver N.

Comment créer une clef privée ? C’est simplement 32 octets très aléatoires. Toute la sécurité dépend de cela. On se rappelle de la faille Debian utilisant un générateur prévisible en 2008.

Générateur d’aléatoire

Pour faire de la cryptographie sérieusement, il faut un vrai générateur aléatoire de qualité cryptographique. Monocypher, par exemple, n’en fournit pas, car cela dépend trop du matériel utilisé. C’est donc à vous d'en fournir un correct.

Ne surtout pas utiliser random() ou rand() : ces fonctions ne sont pas prévues pour la sécurité. Elles offrent souvent à peine 32 bits d’entropie, ce qui signifie qu’elles peuvent générer des valeurs qui tournent en boucle après seulement 4 milliards de cas, ce qui est trivial à explorer pour un attaquant moderne.

Un bon générateur s’appuie sur des sources d’entropie, autrement dit, des phénomènes imprévisibles : le bruit du système, les délais entre événements, la température, etc. Ensuite, ces sources sont mélangées (souvent via un gros hash) pour produire des nombres avec des propriétés statistiques solides.

Par exemple, Linux collecte plein de métriques internes (activité réseau, mouvements de la souris, etc.) pour alimenter son générateur aléatoire /dev/urandom.

Côté matériel, certaines plateformes proposent un vrai générateur physique : il peut mesurer le bruit électrique à travers une diode via un convertisseur analogique-numérique (ADC), ou encore exploiter les légères variations de vitesse d’oscillateurs internes (anneaux d’inverseurs), qui sont ensuite mélangées avec des circuits comme des LFSR combinés via XOR.

Utilisez le générateur cryptographique fourni par votre plateforme (par exemple getrandom(), arc4random(), ou un TRNG matériel si vous êtes en embarqué).

Il ne faut pas se créer son propre générateur sans savoir exactement ce que l’on fait. Le pire étant de réutiliser des données (des clefs par exemple) pour générer d’autres nombres. On crée ainsi une énorme dépendance entre eux, qui n’ont plus rien d’aléatoire.

Les dernières failles des imprimantes Brother proviennent du fait que les mots de passe d’administration sont dérivés de leur numéro de série (!).

Signature

On a un bloc de données, on signe avec une clef privée, on vérifie la signature avec la clef publique.

Monocypher propose EdDSA.

Serial Guard, le protocole de communication

Il ne faut pas créer sa propre cryptographie, c’est trop facile de se tromper. C’est pourtant exactement ce que j’ai fait. La suite peut donc contenir des erreurs. L’idée est de créer un protocole léger de communication. Si des experts passent par là et voient une horreur, qu’ils n’hésitent pas à crier.

On a maintenant les blocs de base. Et il faut maintenant les agencer comme il faut. On veut que A communique avec B (Alice et Bob), sans que E puisse comprendre les messages, insérer des messages, modifier des messages, rejouer des messages, récupérer les messages dans le futur s’il a tout enregistré et récupérer les clefs privées.

Dans le monde de l’embarqué « simple », on communique avec des read et des write sur lien série. L’idéal est d’avoir à peu près la même API.

Il faut réduire au minimum l’échange d’informations préalable pour être le plus léger possible.

Je laisse de coté le "framing", c'est à dire la mise en paquet pour être envoyé sur un lien physique. Un lien série envoie des octets, serialguard fonctionne par paquets d'octet. Il faut reconstituer un paquet avant de l'envoyer dans la bibliothèque.

La base est d’avoir une clef privée chacun, à longue durée de vie. Cela permet de s’authentifier selon le principe : si c’est toujours la même clef depuis l’installation, c’est toujours le même pair : TOFU.

Si on a besoin de faire mieux, il faudrait qu’une « clef de confiance » signe cette clef. Mais on entre dans les méandres complexes d’une public key infrastructure, des certificats ou des web of trust type GPG.

Pour pouvoir tout de même changer une clef privée à long terme, tout en ayant de la sécurité pour éviter les man-in-the-middle, il faut garder un secret partagé dans tous les pairs. Cela peut être très compliqué sur un réseau de serveurs, mais ici, chaque boîtier est programmé au même endroit.

Il s’agit simplement d’un nombre de 32 octets aléatoire partagé par tous. C’est nommé pompeusement pre-shared key (PSK).

Il faudra éviter de la laisser traîner dans le code source.

Une clef de session est une clef temporaire, renouvelable. L’idée est d’utiliser la cryptographie asymétrique pour se mettre d’accord sur une clef symétrique.

Si on utilise le nombre généré par Diffie-Hellman (DH) directement, il est unique par pair de clefs privées : ce n’est pas top. On pourrait échanger des nombres aléatoires pour se mettre d’accord sur une clef symétrique, mais je veux limiter les échanges au minimum.

Pour cela, je vais utiliser une clef de session asymétrique, qui est l’invention du protocole Signal. Une fois la clef symétrique générée, la clef privée éphémère est jetée. Il sera impossible ensuite de déchiffrer la session, même dans le futur.

On commence donc par un échange de 2 clefs publiques : l’une à durée de vie longue et l’autre éphémère.
On croise les 8 clefs (2 publiques et 2 privées de chaque côté) dans 3 échanges DH, on trie les nombres pour avoir le même ordre des 2 côtés, et le résultat est donné à la fonction de hachage avec la PSK.

On a ainsi notre clef de session symétrique.

Le rejeu

Tant que la session est active, l’envoi d’un message précédent reste valide. Pour éviter cela, un NONCE est utilisé dans le chiffrement symétrique. C’est un nombre fourni quelconque mais qui ne doit jamais être identique d’un paquet à l’autre. Il peut être transmis avec le paquet, mais cela prend de la place.

J’ai choisi d’utiliser un simple compteur, cela évite de devoir se rappeler les NONCE passés pour éviter le rejeu.

Les liaisons n’étant pas fiables, un paquet peut être corrompu : il faut pouvoir décoder le paquet suivant. J’ai simplement choisi de tester les 10 nombres successifs en cas d’erreurs, avant d’échouer.

Durée de session

Une session doit être limitée en temps ou en quantité d’informations transmises. Il faut trouver un événement symétrique des 2 côtés pour redéclencher un handshake. J’ai laissé ce point à l’application. Cela pourrait être inclus dans le protocole réseau de plus haut niveau.

Schéma

Envoi d’un seul message

Ce schéma ne couvre pas le cas d’envoi d’un seul message.

Dans l’Internet des objets, on pousse un message dans MQTT et on ne s’attend pas à une réponse. Cela serait bien plus pratique de pouvoir le faire. Il faut pouvoir faire l’envoi sans handshake préalable. Mais il faut tout de même envoyer les clefs publiques, ce qui prend de la place.

Le système a besoin de la clef publique du serveur et du PSK, et tout le reste est fourni en plus du chiffré (NONCE, clef publique, et clef publique éphémère) dans le message envoyé.

La différence est qu’il n’y a que 2 DH, et pas de clef éphémère du côté serveur.

Travail en cours

C’est encore un travail en cours. Il manque des tests sur le terrain et l’évaluation des performances sur plusieurs plateformes.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  
  • ↗️
↗️

20 ans de Fedora-fr : dernier entretien avec Aurélien membre de l'équipe infrastructure de Fedora

✇LinuxFr.org : les dépêches
Par :Renault · Benoît Sibaud · BAud · Ysabeau 🧶 · palm123

Dans le cadre des 20 ans de Fedora-fr (et du Projet Fedora en lui-même), Charles-Antoine Couret (Renault) et Nicolas Berrehouc (Nicosss) avons souhaité poser des questions à des contributeurs francophones du projet Fedora et de Fedora-fr.

Grâce à la diversité des profils, cela permet de voir le fonctionnement du projet Fedora sous différents angles pour voir le projet au-delà de la distribution mais aussi comment il est organisé et conçu. Notons que sur certains points, certaines remarques restent d’application pour d’autres distributions.

N’oublions pas que le projet Fedora reste un projet mondial et un travail d’équipe, ce que ces entretiens ne permettent pas forcément de refléter. Mais la communauté francophone a de la chance d’avoir suffisamment de contributeurs et de contributrices de qualité pour permettre d’avoir un aperçu de beaucoup de sous projets de la distribution.

Chaque semaine un nouvel entretien sera publié sur le forum Fedora-fr.org, LinuxFr.org et le blog de Renault.

L’entretien du jour concerne Aurélien Bompard (pseudo abompard), développeur au sein du projet Fedora et employé Red Hat affecté au projet Fedora en particulier dans l’équipe infrastructure.

    Sommaire

    Bonjour Aurélien, peux-tu présenter brièvement ton parcours ?

    Je m’appelle Aurélien, je suis informaticien, et c’est pendant mon école d’ingé que j’ai découvert le logiciel libre, par le biais d’une association étudiante. J’ai vite accroché et j’ai décidé de travailler autant que possible là-dedans quand j’en suis sorti (en 2003).
    J’ai commencé avec Mandrake Linux à l’époque, alors que KDE venait de sortir en version 2.0 (et le kernel en 2.4). Malgré tous les efforts de Mandrakesoft, ce n’était quand même pas évident de tourner sous Linux à l’époque. J’ai mis 2 semaines à faire fonctionner ma carte son (une SoundBlaster pourtant !), il fallait régler les fréquences de rafraîchissement de l’écran soi-même dans le fichier de conf de XFree86, et je n’avais qu’un seul ordinateur ! (et pas de smartphone, lol). Le dual boot et son partitionnement m’a donné quelques sueurs froides, et tout le temps passé sous Linux était du temps coupé du réseau des élèves. Fallait quand même être un peu motivé :-)
    Mais j’ai tenu bon, et j’ai installé des applications libres sous Windows aussi : Phoenix (maintenant Firefox), StarOffice (maintenant LibreOffice), etc. Parce que ce qui m’a attiré c’est la philosophie du logiciel libre, et pas seulement la technicité de Linux.

    En 2003, j’ai fait mon stage de fin d’études chez Mandrakesoft, mais la société était en redressement judiciaire à l’époque, et ça n’offrait pas des perspectives d’embauche intéressantes.
    Après quelques candidatures j’ai été pris à la fin de l’été 2003 dans une SSII en logiciel libre en tant qu’administrateur système pour installer des serveurs Linux chez des PME.
    Le contrat qui avait donné lieu à mon embauche s’est arrêté prématurément, et la société ayant aussi une activité de développement autour de Zope/CPS, on m’a proposé de me former à Python (version 2.2 à l’époque si je me souviens bien). J’ai accepté et suis devenu développeur. C’est à cette époque que j’ai quitté Mandrake Linux pour passer sur Red Hat 9, en me disant que c’était plus pertinent de monter en compétences dessus pour le travail. À l’époque il y avait une petite communauté de packageurs qui publiait des RPM supplémentaires pour Red Hat 9, autour du domaine fedora.us.
    Début 2004, Red Hat a décidé qu’il y avait trop de confusion entre leurs offres commerciales à destination des entreprises et leur distribution Linux gratuite, et ont décidé de scinder leur distribution en Red Hat Enterprise Linux d’un côté, et une distribution Linux communautaire de l’autre. Ils ont embauché le fondateur de fedora.us, rassemblé les contributeurs et lancé la distribution Fedora Linux.

    La communauté a mis pas mal de temps à se former, et c’était passionnant de voir ça en direct. On avait :

    • les contributeurs qui disaient « regarde on n’a jamais été aussi libres de faire ce qu’on veut, c’est bien mieux qu’avant avec RH9 qui était poussée hors des murs de Red Hat sans qu’on puisse rien y faire » ;
    • les utilisateurs des « autres distribs » (kof kof Debian kof kof) qui disaient « vous êtes exploités par une société, ce sera jamais vraiment communautaire, Red Hat se transforme en Microsoft » ;
    • les commerciaux de Red Hat qui disaient « Fedora c’est une version bêta, c’est pas stable, faut surtout pas l’utiliser en entreprise, achetez plutôt RHEL » ;
    • la communication Red Hat qui disait "Si si c'est communautaire j'vous assure" Si vous ne l'avez pas lue et que vous lisez l'anglais, cette fausse conversation IRC a fait rire jaune beaucoup de monde à l'époque.

    Enfin bref, la communauté a fini par grossir significativement, Fedora Core et Fedora Extras on fusionné, etc. Ma dispo pour contribuer au projet a été assez variable au fil des années, mais j'ai toujours utilisé Fedora.
    En 2012, un poste s'est ouvert chez Red Hat dans l'équipe qui s'occupe de l'infrastructure Fedora, j'ai postulé, et j'ai été pris.

    Peux-tu présenter brièvement tes contributions au projet Fedora ?

    Au début j'empaquetais les logiciels que j'avais à dispo dans Mandrake Linux mais qui n'existaient pas dans Fedora Extras, et tous les logiciels sympas que je voyais passer. J'ai aussi fait beaucoup de revues de fichiers .spec pour leur inclusion dans la distrib.
    Après avoir été embauché par Red Hat, j'ai travaillé sur HyperKitty, le logiciel d'archivage / visualisation de Mailman 3. Puis j'ai travaillé sur plein d'autres trucs au sein de l'équipe Fedora Infra, les dernières étant Fedora Messaging, Noggin/FASJSON et FMN. Je suis aujourd'hui responsable technique côté Fedora dans l'équipe (par opposition au côté CentOS) et je travaille surtout sur les applications en tant que dev, beaucoup moins sur la partie sysadmin.

    Qu'est-ce qui fait que tu es venu sur Fedora et que tu y es resté ?

    J'y suis venu parce que monter en compétences sur une distribution Red Hat me semblait pertinent pour mon métier, en tant que sysadmin Linux.
    J'y suis resté parce que Fedora est pour moi le parfait équilibre entre nouveauté et stabilité, tout en étant très ancré dans la défense du logiciel libre, même au prix de quelques complications (le MP3, les pilotes Nvidia, etc.).

    Pourquoi contribuer à Fedora en particulier ?

    Parce que je l'utilise. Je crois que c'est une constante dans ma vie, c'est rare que je reste uniquement utilisateur/consommateur, je suis souvent amené à contribuer à ce que j'utilise ou aux associations dont je fais partie.

    Contribues-tu à d'autres Logiciels Libres ? Si oui, lesquels et comment ?

    J'ai été amené à développer sur mon temps libre quelques logiciels pour des associations auxquelles je participe, et c'est toujours en logiciel libre. Le dernier en date c'est Speaking List (licence AGPL).

    Est-ce que tes contributions dans Fedora se font entièrement dans le cadre de ton travail ? Si non, pourquoi ?

    Avant non, parce que je packageais des outils que j'utilisais personnellement (Grisbi, Amarok, etc.). Maintenant oui :-)

    Est-ce que être employé Red Hat te donne d'autres droits ou opportunités au sein du projet Fedora ?

    Oui, j'aimerais que ce ne soit pas le cas mais c'est sûr que je suis plus près des prises de décisions, j'ai des accès plus directs aux personnes influentes et aux évolutions. Ce n'est pas un "droit" au sens strict, qui me serait attribué non pas sur la base de mes contributions mais sur celle de mon employeur, heureusement. Mais disons que je baigne toute la journée dedans, je pense que ça ouvre plus d'opportunités que quand j'étais contributeur "externe".

    Tu as été membre de Fedora Infrastructure, peux-tu nous expliquer sur l'importance de cette équipe pour la distribution ? Quels services maintenais-tu ?

    Cette équipe est totalement indispensable. Il y a en permanence des problèmes qui apparaissent dans la distrib, des choses qui tombent en panne, de nouveaux services à intégrer, d'anciennes applis qui ne marchent plus sur les nouvelles distributions ou les nouveaux services et qu'il faut porter, etc.
    J'ai commencé sur Mailman / HyperKitty mais je me suis diversifié depuis, je dirais qu'aujourd'hui je me concentre sur l'aspect applicatif : maintenance de nos applis, portages, adaptations, évolutions, etc. Les dernières applis sur lesquelles j'ai travaillé sont Fedora Messaging, Noggin/IPA (authentification), Datanommer/Datagrepper, FMN (notifications), MirrorManager, et plus récemment Badges.

    Tu as notamment beaucoup contribué à mailman et hypperkitty pour les listes de diffusion du projet. Qu'est-ce que tu as fait ? La migration a-t-elle été difficile ? Quelle importance ont encore les listes de diffusion aujourd'hui au sein du projet Fedora ?

    C'était mon premier travail lorsque j'ai été embauché par Red Hat, oui. J'ai fait le développement de HyperKitty, en suivant les travaux de conception d'interface réalisés par Mo Duffy. J'ai travaillé aussi sur Mailman 3 lui-même quand c'était son développement qui me bloquait pour HyperKitty ou pour le déploiement du tout. J'ai écrit un script de migration qui a pas trop mal marché je pense, quand on prend en compte la longue historique des listes de diffusion du projet. Il fait partie de HyperKitty et va maintenant être utilisé pour la migration des listes de CentOS.

    Le sujet des listes de diffusion a presque toujours été assez conflictuel chez Fedora. Il y a une quinzaine d'années, avant que je sois embauché pour travailler sur HyperKitty, notre communauté était déjà fractionnée entre les contributeurs plutôt réguliers qui utilisaient les listes, et les utilisateurs et contributeurs occasionnels qui étaient plutôt sur des forums web. En effet, utiliser une liste de diffusion est plus engageant qu'un forum, il faut s'y abonner, mettre en place des filtres dans sa messagerie, gérer l'espace de son compte mail en conséquence, c'est impossible de répondre à un message envoyé avant qu'on s'y abonne, on ne peut pas éditer ses messages, etc. Quand on veut juste poser une question rapidement ou répondre rapidement à quelque chose, les forums peuvent être plus pratiques et plus intuitifs. L'utilisation des listes de diffusion peut être intimidant et contre-intuitif : combien de personnes ont envoyé "unsubscribe" à une liste en voulant se désinscrire ?

    La promesse d'HyperKitty était d'offrir une interface de type forum aux listes de diffusion, pour faire le pont entre les deux communautés, et permettre plus facilement la conversion d'utilisateurs en contributeurs tout en permettant aux contributeurs d'être plus facilement confrontés aux problèmes rencontrés par les utilisateurs. Ça n'a pas bien fonctionné, mais c'est un sujet qui reste d'actualité aujourd'hui avec l'intégration de Discourse dans le projet. Je crois que le projet essaie de migrer de plus en plus de processus depuis les listes de diffusion vers Discourse, pour que ça atteigne le maximum d'utilisateurs et de contributeurs.

    Puis également sur le compte unique au sein du projet Fedora (nommé FAS), quelle est l'importance de ce projet et ce que tu y as fait ?

    C'est un projet qu'on a gardé longtemps dans les cartons, peut-être trop longtemps même. L'idée était de remplacer FAS (Fedora Account System), une base de donnée des utilisateurs avec une API maison, par FreeIPA, une intégration de LDAP et Kerberos pour gérer les comptes utilisateurs en entreprise. On utilisait en fait déjà IPA pour la partie Kerberos dans l'infra, mais la base de référence des comptes était FAS. Or, FAS n'était plus maintenu, et sa ré-écriture par un membre de la communauté (un français ! petit clin d'œil à Xavier au passage) prenait un peu trop de temps. FAS tournait sur EL6 et la fin de vie approchait.
    Migrer la base de comptes sur IPA a été assez complexe parce que beaucoup d'applications s'intégraient avec, il a donc fallu tout convertir vers le nouveau système. IPA étant prévu pour des entreprises à la base, il n'y a pas de système d'auto-enregistrement et de gestion avancée de son propre compte. Nous avons donc dû développer cette interface, qui s'appelle Noggin. Nous avons aussi écrit une API REST pour IPA, appelée FASJSON. Enfin, il a fallu personnaliser IPA pour qu'il stocke les données dont nous avions besoin dans l'annuaire LDAP.
    J'ai été développeur et responsable technique sur ce projet, donc je me suis surtout concentré sur la conception et les points d'implémentation délicats.

    Tu fais parti des gros contributeurs du composant Bodhi et même l'infrastructure de la compilation des paquets en général, là encore quel a été ton rôle là dedans et en quoi ces composants sont importants pour le projet ?

    Bodhi est vraiment au cœur du cycle de vie d'un paquet RPM dans Fedora. C'est aussi une des seules applications de l'infra qui soit significativement maintenue par un membre de la communauté qui n'est pas un employé de Red Hat (Mattia). Elle permet de proposer une mise à jour des paquets, s'intègre avec les composants de tests de paquets, et permet de commenter une mise à jour.
    J'ai travaillé dessus de manière sommaire seulement, depuis le départ de Randy (bowlofeggs) qui la maintenait auparavant. J'ai converti le système d'authentification version OIDC, j'ai écrit les tests d'intégration, j'ai travaillé un peu sur l'intégration continue, mais c'est tout.

    Peux-tu expliquer rapidement l'architecture derrière cette mécanique ?

    Et bien, disons qu'en résumé quand un packageur veut proposer une mise à jour, il met à jour son fichier spec dans son dépôt, lance une construction du paquet avec fedpkg dans Koji, et doit ensuite déclarer et donner les détails de sa mise à jour dans Bodhi. C'est là que les tests d'intégration des paquets se déclenchent, et au bout d'un certain temps (ou d'un certain nombre de commentaires positifs) la mise à jour arrive sur les miroirs.

    Tu as aussi beaucoup travaillé sur Fedora-Hubs, peux-tu revenir sur les ambitions de ce projet ? Pourquoi il n'a finalement pas été adopté et concrétisé comme prévu ?

    L'objectif de Fedora Hubs était de centraliser l'information venant de différentes applications Fedora sur une même page, avec une interface qui explique clairement ce que ça veut dire et quelles sont les étapes suivantes. Une sorte de tableau de bord pour contributeur, et pas seulement pour packageur, un peu dans l'esprit de ce que fait aujourd'hui https://packager-dashboard.fedoraproject.org/.
    Malheureusement la proposition a été faite à un moment où il y avait d'autres priorités plus urgentes, et vu que c'était quand même pas mal de boulot on a laissé tomber pour s'occuper du reste.

    Est-ce qu'il y a des collaborations concernant l'infrastructure entre les projets RHEL, CentOS et Fedora ou même d'autres entités externes ?

    Oui, on essaye de partager le maximum ! Le système d'authentification est commun entre CentOS et Fedora, par exemple. On essaie d'échanger sur nos rôles Ansible, sur la surveillance de l'infra, etc.

    Si tu avais la possibilité de changer quelque chose dans la distribution Fedora ou dans sa manière de fonctionner, qu'est-ce que ce serait ?

    J'adorerais qu'il y ait plus de contributeurs qui participent aussi à l'infrastructure, et notamment à nos applications. À vrai dire je cherche en ce moment des moyens de motiver les gens à venir y mettre les mains. C'est super intéressant, et vous pouvez directement affecter la vie des milliers de contributeurs au projet ! Je suis même prêt à mettre de l'énergie là-dedans si besoin, sous forme de présentations, ateliers, questions/réponses, etc. Et je pose donc la question à tout le monde : si Fedora vous intéresse, si le développement vous intéresse, qu'est-ce qui vous freine pour contribuer aux applis de l'infra ?

    À l'inverse, est-ce qu'il y a quelque chose que tu souhaiterais conserver à tout prix dans la distribution ou le projet en lui même ?

    Je crois que c'est notre capacité à innover, à proposer les dernières nouveautés du logiciel libre :-)

    Que penses-tu de la communauté Fedora-fr que ce soit son évolution et sa situation actuelle ? Qu'est-ce que tu améliorerais si tu en avais la possibilité ?

    À vrai dire je n'ai pas suivi de près les évolutions de la communauté française. Mon boulot m'amène à communiquer quasi-exclusivement en anglais, donc j'interagis plus avec la communauté anglophone.

    Quelque chose à ajouter ?

    Non, rien de spécial, à part revenir sur ma question : si vous avez eu envie d'améliorer l'infra et/ou les applis de l'infra de Fedora, qu'est-ce qui vous a freiné ? Qu'est-ce qui vous freine aujourd'hui ? N'hésitez pas à me contacter sur Matrix (abompard@fedora.im) et sur Discourse.

    Merci pour ta contribution !

    Merci à vous, et joyeux anniversaire à Fedora-Fr !

    Conclusion

    Nous espérons que cet entretien vous a permis d'en découvrir un peu plus sur l'infrastructure du projet Fedora.

    Si vous avez des questions ou que vous souhaitez participer au projet Fedora ou Fedora-fr, ou simplement l'utiliser et l'installer sur votre machine, n'hésitez pas à en discuter avec nous en commentaire ou sur le forum Fedora-fr.

    Et ainsi s'achève notre série d'entretiens. On espère que cela vous aura plus et peut être à dans quelques années pour savoir ce qui a changé. :)

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    •  
    • ↗️
    ↗️

    muttum, un nouveau jeu de devinette de mots pour Linux

    ✇LinuxFr.org : les dépêches
    Par :Adrien Dorsaz · Julien Jorge · cli345 · palm123 · Benoît Sibaud

    muttum est un jeu libre dont le but est de retrouver un mot en quelques essais. La première lettre est fixe pour avoir des plateaux différents à chaque fois. Une première version de muttum est publiée sur Flathub depuis le début de l’été.

    Sommaire

    Histoire

    plateau de jeu

    Le projet muttum est né suite à la découverte des jeux Wordle et Sutom qui proposent également de deviner un mot une fois par jour dans le dictionnaire anglais pour le premier et français pour le second.

    J’ai décidé de me lancer dans l’aventure de développer muttum sur mon temps libre pour proposer le jeu de devinette sans avoir besoin d’Internet et pour pouvoir essayer plusieurs mots dans la même journée sans limitation artificielle.

    Une autre de mes motivations était d’apprendre à créer une application avec les bibliothèques GTK et GObject. J’avais déjà joué avec GTK quelques fois, mais je n’avais pas utilisé le concept des objets proposé par GObject et il me semblait que GObject pouvait simplifier l’utilisation des composant GTK complexes. Par exemple, après avoir implémenté la vue en table des budgets HomeBank, j’ai eu l’impression que ça aurait été plus facile de créer la table GTK si les données à afficher avait déjà été mises en forme avec GObject.

    Je voulais également essayer également d’utiliser le langage C directement, le langage utilisé par GTK, pour ne pas avoir besoin de dépendre des introspections (interfaces de GTK avec les autres langages de programmation, comme Python, C++…).

    C’est ainsi que le développement a commencé en février 2022 sous le nom temporaire LeBonMot avec une structure assez simple qui mélangeait le moteur logique du jeu et l’interface graphique dans un seul et même code source.

    Après quelques semaines de développement, j’ai trouvé le nom muttum et j’ai débuté la location du nom de domaine muttum.org en avril 2022 :

    $ rdap muttum.org
    Domain:
    Domain Name: muttum.org
    Domain Name (Unicode): > muttum.org
    […]
    Event:
    Action: registration
    Date: 2022-04-12T08:46:16.285Z

    muttum serait, d’après le Wiktionnaire, un nom commun latin qui signifie bruit, grognement et dont la dérivation en français a formé le nom commun mot. Cette information m’a bien plu puisque justement le but du jeu est de retrouver le bon mot et que, en plus, c’est un palindrome.

    Durant la même période, j’ai commencé une réorganisation du code pour séparer la partie moteur de calcul de la partie graphique, ce qui permettra dans le futur de développer plusieurs styles d’interface graphique. Pour l’instant muttum ne propose qu’une interface développée pour la plateforme GNOME, car elle dépend de la bibliothèque libadwaita.

    Quand je décide de faire cette séparation, j’ai deux idées d’interfaces  : une qui serait multi-plateforme en n’utilisant que GTK (sans libadwaita) et une interface web en utilisant WebAssembly pour utiliser le moteur de muttum. Pour l’instant, aucune de ces 2 interfaces n’a été développée. La version multiplateforme sera assez rapide à implémenter (il faut enlever libadwaita des dépendances) et la version web ne sera peut-être jamais utile finalement : depuis 2025 GTK propose un portage expérimental pour la plateforme Android.

    Gagné !

    Vers septembre 2022, je décide de séparer le code source dans deux répertoires différents: muttum ne contiendra que l’interface graphique et libmuttum ne contiendra que le moteur du jeu. Le travail est donc continué sur libmuttum jusqu’à fin janvier 2023 (séparation du moteur, ajout de tests pour le moteur…).

    Le projet est en pause complète jusqu’en novembre 2024, je ne sais plus pourquoi, mais certainement parce que les rénovations de ma maison ont débuté en 2023 et que je n’avais plus la tête à coder sur mon temps libre.

    En novembre 2024, le premier commit de la reprise indique que je reprends le code du moteur avec le langage Rust et ce pour plusieurs raisons :

    1. je souhaitais apprendre Rust et le code de ce moteur était un bon bac à sable pour apprendre un nouveau langage. Il m’avait d’ailleurs déjà permis d’apprendre à utiliser C et GObject ;
    2. je ne retrouve plus la référence exacte, mais un des développeurs principaux de GTK conseillait d’utiliser Rust pour débuter de nouvelles applications (c’était probablement l’article On Vala d’Emmanuele Bassi) ;
    3. les éditions ENI m’ont offert le livre Rust, Développez des programmes robustes et sécurisés pour une de mes contributions à LinuxFr.

    Enfin, en juin 2025, la première version publique a été publiée sur Flathub.

    Fonctionnalités

    muttum fonctionne avec des dictionnaires : ce sont des fichiers textes qui contiennent un mot connu par ligne et qui sont encodés en UTF-8. Les dictionnaires distribués avec la version Flathub proviennent des projets:

    • wfrench pour le français
    • scowl pour les dictionnaires anglais
    • igerman98 pour les dictionnaires allemands

    muttum permet aux distributeurs de définir n’importe quel dictionnaire avec un fichier de configuration. Ceci permet aux empaqueteurs d’utiliser les paquets déjà existant pour les dictionnaires et de donner le chemin à charger pour chaque langue. Ce fichier de configuration est également utilisé dans le dialogue À propos des dictionnaires pour créditer les projets qui ont créé les dictionnaires.

    À propos des dictionnaires

    muttum sait gérer l’alphabet latin, mais il est architecturé pour définir d’autres alphabets. Pour ce faire, il faut définir les caractères de base. muttum utilise cette liste pour filtrer les caractères entrés par l’utilisateur et pour filtrer les mots valides.

    À mesure que l’utilisateur essaie des mots différents, muttum met à jour l’alphabet affiché en dessous du plateau pour indiquer si toutes les occurrences d’une lettre ont été trouvées (couleur verte), si des occurrences ont été trouvées et qu’il pourrait en exister plus (couleur orange) ou si une lettre n’existe pas dans le mot (couleur grise).

    Limitations

    muttum nécessite un clavier pour saisir les caractères, il n’y a pour l’instant pas de possibilité de saisir les caractères avec un écran tactile. L’écran doit aussi être assez grand pour pouvoir afficher le plateau complètement, donc pour l’instant il n’est pas utilisable sur les smartphones.

    muttum n’applique pas de filtres sur les mots des dictionnaires, il contrôle uniquement qu’un mot est valide selon l’alphabet défini. Par exemple, il est conseillé qu’un dictionnaire contienne les conjugaisons complètes des verbes et donc un mot à deviner peut être n’importe quelle forme du verbe.

    Développements futurs

    Pour l’instant, je vais faire une pause dans le développement de ce jeu, parce que je souhaite travailler sur d’autres projets.

    Néanmoins, j’ai déjà quelques idées pour la suite de ce projet :

    1. ajouter un dialogue pour expliquer comment jouer (utilisation du clavier), la signification des couleurs et la mise à jour de l’alphabet sous le plateau
    2. ajouter un chronomètre en sous-titre de la fenêtre et afficher le temps pour terminer le plateau dans le dialogue de fin de jeu
    3. dans le dialogue de fin, j’aimerai ajouter un bouton de partage comme le fait Sutom. Pour que ce soit intéressant, il faudra que j’ajoute un lien pour que les amis puissent essayer le même plateau. Donc il faut que muttum gère le schéma d’application muttum:// et il faudrait mettre le mot à trouver encodé en base64 et les paramètres du plateau dans le lien
    4. vers la fin du projet, j’ai appris l’existence de l’option pedantic pour le linter clippy et je voudrais corriger les points qu’il remonte pour avoir un meilleur style de code.
    5. la bibliothèque icu a sorti une nouvelle version majeur, il faudrait mettre à jour le code de muttum pour celle-ci.
    6. rendre l’application compatible avec les smartphones. Ça passera sûrement par l’utilisation d’entrées textes à la place des labels dans le plateau, cacher l’alphabet par défaut et rendre le plateau défilable.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    •  
    • ↗️
    ↗️

    Incident du 26 juin 2025 ayant touché les serveurs de production et de développement

    ✇LinuxFr.org : les dépêches
    Par :Benoît Sibaud · Florent Zara · palm123 · bobble bubble

    Ayant simultanément ressenti un trouble dans la force, vos administrateurs des serveurs LinuxFr.org ont noté un souci sur le site hier matin. Et d'autres personnes de l'équipe ont aussi signalé le problème (supervision efficace et réactive par le lectorat).

    Le serveur hébergeant les conteneurs de production et de développement a redémarré (hors de toute opération planifiée) à 06h15 Paris le 26 juin 2025, et contrairement aux redémarrages habituels pour les mises à jour, cela a entraîné un changement des adresses IP internes des conteneurs de production et de développement, après redémarrage (06h18). Tous les services avaient bien redémarré, mais les accès aux sites web n'étaient plus possibles : le serveur web frontal ne pouvait plus joindre les adresses prévues, aboutissant à des réponses techniques 502 Bad Gateway.

    La correction sur les adresses IP a été faite à 08h08 pour la production et 08h16 pour le développement.

    Les deux autres serveurs hébergés au même endroit n'ont pas été affectés.

      Changement d'adresses IP

      Les conteneurs de production et de développement sont configurés en DHCP et gardent normalement les mêmes adresses sur les redémarrages.

      Exemple de redémarrage propre pour des mises à jours de sécurité :

      mai 24 10:06:08 oups dnsmasq-dhcp[1256]: DHCPREQUEST(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa
mai 24 10:06:08 oups dnsmasq-dhcp[1256]: DHCPACK(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa prod
mai 24 10:06:22 oups dnsmasq-dhcp[1256]: DHCPRELEASE(lxc0) 192.168.0.2 aa:aa:aa:aa:aa:aa
---redémarrage---
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPDISCOVER(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPOFFER(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPREQUEST(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb
mai 24 10:08:57 oups dnsmasq-dhcp[1228]: DHCPACK(lxc0) 192.168.0.2 bb:bb:bb:bb:bb:bb prod

      (les IP, MAC et interfaces ont été changées)
      On a demande et attribution de l'IP pour une adresse MAC donnée, puis elle est relâchée à l'arrêt de la machine, puis réattribuée au démarrage.

      Incident :

      juin 26 03:57:46 oups dnsmasq-dhcp[951195]: DHCPREQUEST(lxc0) 192.168.0.2 cc:cc:cc:cc:cc:cc
juin 26 03:57:46 oups dnsmasq-dhcp[951195]: DHCPACK(lxc0) 192.168.0.2 cc:cc:cc:cc:cc:cc prod
---redémarrage---
juin 26 04:18:42 oups dnsmasq-dhcp[1222]: DHCPREQUEST(lxc0) 192.168.0.2 dd:dd:dd:dd:dd:dd
juin 26 04:18:42 oups dnsmasq-dhcp[1222]: DHCPNAK(lxc0) 192.168.0.2 dd:dd:dd:dd:dd:dd address in use
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPDISCOVER(lxc0) dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPOFFER(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPREQUEST(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd
juin 26 04:18:46 oups dnsmasq-dhcp[1222]: DHCPACK(lxc0) 192.168.0.100 dd:dd:dd:dd:dd:dd prod

      On a demande et attribution de l'IP pour une adresse MAC donnée. Elle n'est pas relâchée à l'arrêt de la machine, n'est pas disponible au redémarrage, et une autre est alors attribuée.

      Nature du redémarrage

      Le redémarrage a été brutal, sans arrêt propre des services. Il ne s'agit donc pas d'un arrêt logiciel propre depuis le serveur.

      La cause possible peut donc être un souci d'instabilité électrique, l'arrêt/extinction physique sur le serveur, un bug ou une faille logicielle, ou encore le redémarrage électrique via la carte d'administration. Cette cause n'est actuellement pas connue.

      Mesures préventives et correctives

      Il pourrait être utile de figer les IP internes et/ou d'assurer la synchronisation/reconfiguration du frontal web.

      Il n'est pas prévu d'avoir de la redondance sur la production à court/moyen terme, donc un souci sur le conteneur de production continuera à avoir un effet visible.

      La supervision peut certainement être améliorée (et l'état des services rendu visible depuis un simple navigateur web).

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      •  
      • ↗️