Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Aujourd’hui — 21 décembre 2024Flux principal

Tuxemon Tower 0 : sortie de la première version !

Tuxemon Tower 0 est un petit jeu vidéo très sobre. Il est inspiré des jeux Pokémon classiques et consorts, mais il est 100% libre et ne cherche aucunement à être un clone.

Sommaire

En bref

Qu'est-ce que Tuxemon Tower 0 ?

Tuxemon Tower 0 est un jeu vidéo de combats en tour par tour. Les combattants peuvent avoir un ou des types, ont des statistiques, et une ou plusieurs capacités. En gagnant assez d'expérience, ils montent de niveau et ainsi deviennent plus forts. Un genre simple et classique, mais efficace.

Et dans le cas de Tuxemon Tower 0, la réalisation est très basique. Cela est vrai autant du point de vue graphique que de celui du moteur. De plus, on accorde qu'on peut parfois juger que l'expérience des joueurs est médiocre (notamment car, hormis être meilleur que nous, vous allez devoir vous fader des combats juste pour avoir un niveau suffisant et on reconnaît qu'il n'y a pas trop d'intérêt ludique à regagner le même combat contre une dresseuse ou commettre un crime contre la biodiversité en enchaînant à gogo les créatures sauvages de la même zone, mais augmenter la vitesse de défilement du texte et garder enfoncé sur le bouton A permet d'écourter le temps de mise à niveau). Mais le jeu est court, donc il est escompté que la découverte et la curiosité qui l'accompagne permettent d'avoir une expérience agréable de ce mini-jeu.

Télécharger Tuxemon Tower 0

Le téléchargement des sources (code, images, etc.), de la documentation générée et des constructions pour certaines plateformes (distributions GNU/Linux et Windows) se fait via BitTorrent à travers un lien magnet. On promeut en effet la décentralisation et le fédéralisme, mais aussi la non-disponibilité permanente. De plus, ça oblige tout le monde à partager le coût (hormis les trackers, certes) et à avoir une copie des sources, tout en étant résilient.

Ce serait sympa de partager pendant l'obtention et aussi après que ce soit fait. Et on prévient : on n'est que rarement à la fois connecté à Internet (on n'a volontairement pas d'accès chez nous) et en mesure de partager via BitTorrent (on ne veut pas faire ça au boulot et il faut que ce soit permis par le réseau), donc ayez de la patience (ou ne vous plaignez pas inutilement). C'est également pour ça qu'on encourage fortement que vous continuez de partager le torrent après l'avoir entièrement obtenu et de préférence sans ratio (puisqu'il n'est pas bien lourd à la vue de la normalité actuelle, et est tout à fait légal, ça ne devrait pas vous être bien problématique).

Quelques clients BitTorrent libres

Au cas où vous n'auriez pas de client BitTorrent (ou un qui soit propriétaire), en voici quelques-uns qui sont libres :

Images du jeu

Images de cartes

Images de cartes

Images de combats

Images de combats

Images de menus

Images de menus

Comment contribuer ?

Avant d'éventuellement contribuer, n'oubliez pas plutôt en priorité de faire des choses plus importantes. En effet selon nous, mieux vaut s'activer pour l'émancipation sociale universelle et tendre vers une société écologique que de contribuer à un jeu.

  1. Pour nous, la meilleure manière de contribuer est de mettre à disposition des sprites pour des créatures et des dresseurs. En effet, nous sommes très mauvais pour produire ça et cela ajouterait de la diversité bienvenue (pendant que celle sur Terre s'effondre…). Si ça vous branche, faites-le en respectant le style des actuels, avec une taille adéquate (64×64 et/ou 56×56 et/ou 48×48), et de préférence en faisant l'avant et l'arrière (car avec juste l'avant on ne peut pas jouer la créature ou la personne dresseuse mais juste l'affronter), voire en vous restreignant à 4 couleurs (c'est là la contrainte ultime, mais qui serait utile pour économiser de l'espace et deviendra nécessaire si un jour un port sur GameBoy Color est fait) et alternativement c'est déjà ça si ça ne dépasse pas la barre des 8 (qui va nous servir de transition entre 16 et 4, tout en permettant de réduire l'usage mémoire avec une petite astuce ou de la compression plus poussée que nous ne ferons probablement pas).
  2. Nous n'avons pas l'intention de gérer une communauté autour de ce jeu. C'est pourquoi nous n'avons pas mis le code source sur une forge et nous ne comptons pas le faire. Rien ne vous empêche toutefois de faire une version dérivée et de la publier, peut-être que nous irons y piocher des trucs en vous créditant si nous en avons connaissance.
  3. Bien sûr, si vous voulez que nous intégrions peut-être un jour une contribution, veillez à la mettre sous une licence compatible quand vous n'y êtes pas de toute façon obligé par le gauche d'auteur. Utilisez donc une licence libre, avec de préférence la GNU AGPLv3+ pour le code source et la Creative Commmons BY-SA v4.0 pour le reste.
  4. Mais où mettre ce que vous produisez ? Ça vous regarde. Mais, pour que ce soit visible, le wiki du projet Tuxemon est un bon endroit ou vous pouvez faire un commentaire ci-dessous (pointant par exemple vers votre dépôt sur OpenGameArt).
  5. Si vous vous y connaissez en portage ou en packaging pour votre système favori, n'hésitez pas à faire un joli paquet pour le jeu et à tenter honnêtement de le faire officiellement intégrer. Toutefois, cela ne vaut pas pour Apple iOS, Google Play, Microsoft Store, Steam de Valve, Origin d'Electronic Arts, et consorts.
  6. Évidemment une autre forme de contribution est tout simplement de faire la promotion du jeu. Parlez-en !
  7. Enfin, il existe un moyen rudimentaire : partager le contenu du torrent, pour qu'il soit disponible le plus de temps possible. En effet, nous sommes très loin d'être en permanence avec un accès à Internet et nous n'ouvrons pas systématiquement notre client BitTorrent favori quand nous le sommes.

Le droit d'auteur

Les licences utilisées

Les conséquences

Remerciements

En plus long ?

Le comité éditorial de LinuxFr.org a jugé inappropriée la version longue qui était prévue et qui lui a été soumise. De plus, il a suggéré de feuilletonner l'annonce d'origine. Mais cela ne correspond pas à notre vision éditoriale et plus généralement notre vision anthropologique (le brouhaha communicationnel nous apparaît comme néfaste et donc à ne surtout pas alimenter), et nous n'avons de toute façon pas envie d'y passer du temps (il y a pour nous bien plus important que ce petit jeu vidéo, dont la réalisation est plus pour nous un plaisir coupable qu'autre chose, à fortiori dans une phase très nette de fascisation et d'écocide).

Néanmoins l'annonce d'origine, qui contient bien plus d'explications, reste disponible. Dans le torrent, il y a les sources (sources.tar.xz) et dans celle-ci il y a l'annonce prévue à la base (news/fr/version-1-0-0_annonce.md). Et si vous voulez la publier ailleurs (en mentionnant que nous en sommes à l'origine et en différenciant bien toute modification), en entier ou sous forme partielle, elle est sous licences libres (vous pouvez choisir celle qui vous convient le mieux) avec gauche d'auteur : Creative Commons BY-SA 3.0, Creative Commons BY-SA 4.0 et GNU GPL 3.0.

Données du jeu

Consultation en jeu

Dans le menu de lancement, proposant de démarrer une nouvelle partie ou d'en charger une existante, appuyez sur Start (ou plutôt l'un des boutons qui y correspond si vous n'utilisez pas une manette ou qu'elle n'est pas reconnue ou pas bien). Cela vous fera changer de menu. Vous aurez alors une entrée « Explorer les données ». Ce n'est pas parce que ça existe que c'est exhaustif.

Documentation HTML

Dans le torrent, avec les sources et les constructions, il y a de la documentation sous forme de fichiers HTML, que vous pouvez consulter avec un navigateur web. Vous pouvez aussi la regénérer depuis les sources. Comme pour la consultation en jeu, ce n'est pas nécessairement exhaustif, mais c'est déjà ça.

Images

Liste des créatures

Liste des créatures

Liste des dresseurs et dresseuses

Liste des dresseurs et dresseuses

Annexe : temps et motivation

Au début d'un projet personnel, la motivation est souvent grande. Mais tant qu'il n'y a pas quelque chose de finalisée, il est à priori courant que la motivation tende à décroitre. En tout cas, c'est notre cas.

C'est en partie pour cela que le jeu est très simple (système ultra-basique pour les cartes, pas de possibilité d'esclavagir, pas de statut, pas de possibilité de manipulation par le joueur/joueuse d'objets non-visuels, pseudo-aléatoire en guise de non-intelligence artificielle, etc.). L'autre grosse partie de l'explication est la volonté de faire de la basse technologie (d'où entre autres que ce soit graphiquement en niveaux de gris, malgré des sprites avec des couleurs au-delà de ce spectre) et la restante est l'ajout de complexité qui nuise à l'expérience de la mécanique du jeu en ajoutant du « bruit », mais ce n'est là pas le sujet.

Venir reprocher ou se plaindre de la trop grande simplicité du jeu (qu'il aurait fallu qu'il y ait ceci et cela, etc.) peut être en soi une critique pertinente. Néanmoins, ça ferait totalement fi de l'aspect humain en ce qui concerne la production. En effet, si le jeu n'était pas aussi basique, il ne serait probablement jamais sorti de par la baisse de motivation.

C'est pourquoi le jeu est volontairement très simple. Mais c'est une fin en soi et une base. Tout ce qui a été fait pour la version 1.0.0 de ce jeu ne sera plus à faire pour une ou des éventuelles versions améliorées et un ou des éventuels autres jeux exploitant tout ou partie de ce qui a été réalisé pour celui-là.

Approximation de l'évolution de la motivation

Dans le cadre du développement de ce jeu, on utilise git, un logiciel de gestion de version. Tous les changements y sont consignés et datés. À partir des informations qu'il a enregistrées, il est donc possible d'avoir une idée de l'évolution de la motivation.

Toutefois, on ne va pas vous livrer le dépôt git (et on a expliqué pourquoi). Vous n'en aurez donc ci-après qu'une vue fort approximative, dont la génération a été faite par git-bars.

Il fournit une vue par mois du nombre de commits. C'est donc très approximatif. En effet, un commit peut avoir une taille très variable et être pour des changements importants ou mineurs. Néanmoins, ça donne tout de même une image plutôt réaliste de l'évolution de notre motivation.

On peut notamment bien voir que les débuts sont des périodes fastes. Pour début 2023, on peut constater que c'est assez peu garni, ce qui s'explique par la contre-réforme des retraites. Mais ça montre aussi un biais : en mars et en avril 2023, on n'a fait que des petits trucs pas bien importants, mais ça a engendré pas mal de commits.

Statistiques de commits par nous pour ce nouveau jeu

2024-11  61   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-10  52   ▀▀▀▀▀▀▀▀▀▀▀
2024-09  45   ▀▀▀▀▀▀▀▀▀▀
2024-08  77   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-07  19   ▀▀▀▀
2024-06  34   ▀▀▀▀▀▀▀
2024-05  62   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-04  126  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-03  59   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-02  96   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-01  89   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-12  52   ▀▀▀▀▀▀▀▀▀▀▀
2023-11  78   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-10  117  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-09  224  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-08  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-07  87   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-06  56   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-05  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-04  92   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-03  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-02  10   ▀▀
2023-01  19   ▀▀▀▀
2022-12  34   ▀▀▀▀▀▀▀
2022-11  80   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-10  87   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-09  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-08  88   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-07  138  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-06  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-05  50   ▀▀▀▀▀▀▀▀▀▀▀
2022-04  28   ▀▀▀▀▀▀
2022-03  121  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-02  131  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-01  144  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-12  133  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-11  81   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-10  26   ▀▀▀▀▀
2021-09  35   ▀▀▀▀▀▀▀
2021-08  45   ▀▀▀▀▀▀▀▀▀▀
2021-07  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-06  5    ▀
2021-05  18   ▀▀▀▀
2021-04  55   ▀▀▀▀▀▀▀▀▀▀▀▀
2021-03  79   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-02  112  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-01  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀

Statistiques de commits par nous pour Greycess Knight RPG

Greycess Knight RPG est la base de ce nouveau jeu. Il part donc du même dépôt git. Puisque des changements sont valables pour les 2 jeux, on les fait dans Greycess Knight RPG, ce qui occasionne des commits de fusion dans le nouveau jeu. De plus, en soustrayant les nombres de commits par mois de Greycess Knight RPG à ceux du nouveau jeu, on peut avoir le nombre de commits qui touchent aux changements nécessaires au nouveau, ou du moins en partie puisqu'on fait parfois le changement dans le nouveau jeu avant de le mettre aussi dans l'ancien ou le (quasi-)même changement dans les 2 pour faciliter la fusion. C'est pour ça qu'on met ci-après les statistiques pour Greycess Knight RPG.

2024-11  17   ▀▀▀▀▀▀▀
2024-10  9    ▀▀▀▀
2024-09  4    ▀
2024-08  20   ▀▀▀▀▀▀▀▀
2024-07  1    
2024-06  8    ▀▀▀
2024-05  15   ▀▀▀▀▀▀
2024-04  34   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-03  3    ▀
2024-02  10   ▀▀▀▀
2024-01  12   ▀▀▀▀▀
2023-12  16   ▀▀▀▀▀▀▀
2023-11  15   ▀▀▀▀▀▀
2023-10  13   ▀▀▀▀▀
2023-09  29   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-08  26   ▀▀▀▀▀▀▀▀▀▀▀
2023-07  25   ▀▀▀▀▀▀▀▀▀▀▀
2023-06  26   ▀▀▀▀▀▀▀▀▀▀▀
2023-05  25   ▀▀▀▀▀▀▀▀▀▀▀
2023-04  35   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-03  27   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-02  4    ▀
2023-01  3    ▀
2022-12  9    ▀▀▀▀
2022-11  22   ▀▀▀▀▀▀▀▀▀
2022-10  15   ▀▀▀▀▀▀
2022-09  14   ▀▀▀▀▀▀
2022-08  27   ▀▀▀▀▀▀▀▀▀▀▀▀
2022-07  44   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-06  14   ▀▀▀▀▀▀
2022-05  16   ▀▀▀▀▀▀▀
2022-04  6    ▀▀
2022-03  22   ▀▀▀▀▀▀▀▀▀
2022-02  33   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-01  54   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-12  92   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-11  81   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-10  26   ▀▀▀▀▀▀▀▀▀▀▀
2021-09  35   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-08  45   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-07  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-06  5    ▀▀
2021-05  18   ▀▀▀▀▀▀▀▀
2021-04  55   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-03  79   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-02  112  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-01  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

Par ailleurs, comme vous pouvez le voir, ça a bougé du côté de Greycess Knight RPG. Une version 1.0.2 est en cours. Mais du point de vue de l'expérience de jeu, elle n'apporte rien ou presque. Ce sera une mise à jour technique : elle consistera essentiellement en une amélioration du code source (de diverses manières et à divers endroits) et en une réduction par 3 de la taille du binaire sans la bibliothèque SDL2 statiquement liée (ce qui l'amènera à environ 250 ko grâce à la correction d'une erreur stupide).

Commentaires : voir le flux Atom ouvrir dans le navigateur

Haiku a 23 ans et un quart

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

Sommaire

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

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

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

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

Applications

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

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

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

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

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

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

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

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

Améliorations du mode sombre

Modifications faites par nipos et nephele.

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

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

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

AboutSystem

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

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

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

Débogueur

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

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

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

DriveSetup

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

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

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

HaikuDepot

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

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

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

Horloge

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

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

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

Tracker

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

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

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

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

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

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

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

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

Terminal

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

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

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

PowerStatus

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

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

Outils en ligne de commande

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

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

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

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

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

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

Serveurs

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

app_server

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

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

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

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

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

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

media_server

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

Travaux effectués par waddlesplash:

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

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

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

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

registrar

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

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

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

input_server

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

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

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

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

net_server

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

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

package_daemon

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

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

Kits

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

Interface

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

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

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

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

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

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

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

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

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

Media

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

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

Locale

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

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

Support

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

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

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

Pilotes de périphériques

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

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

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

Processeurs et économie d’énergie

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

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

Réseau

virtio_net

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

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

broadcom750x

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

 vmxnet

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

 Couches de compatibilité BSD

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

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

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

 TCP

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

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

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

 Ethernet

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

 UNIX domain sockets

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

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

USB

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

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

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

PCI

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

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

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

Périphériques de stockage

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

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

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

ACPI

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

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

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

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

Graphiques

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

virtio

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

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

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

PS/2

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

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

Systèmes de fichiers

ram_disk et ramfs

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

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

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

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

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

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

packagefs

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

Plusieurs améliorations faites par waddlesplash :

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

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

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

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

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

FAT

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

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

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

BFS

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

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

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

Query parser

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

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

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

block_cache

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

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

kernel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VFS

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

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

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

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

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

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

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

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

Gestion de la mémoire

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

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

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

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

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

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

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

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

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

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

libroot

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

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

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

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

libnetwork

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

Compatibilité POSIX

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

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

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

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

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

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

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

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

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

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

runtime_loader

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

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

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

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

Outils de debug

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

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

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

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

Bootloader

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

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

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

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

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

Documentation

Haiku Book

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

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

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

Haiku Interface Guidelines

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

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

Wiki et documentation interne

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

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

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

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

Système de build, environnement de compilation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ARM & PowerPC

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

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

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

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

oanderso continue le travail sur le portage ARM64:

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

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

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

Commentaires : voir le flux Atom ouvrir dans le navigateur

À partir d’avant-hierFlux principal

Dons aux associations, épisode 13

Cette dépêche est la treizième de sa série, après celles de 2011, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 et 2023. Elle tient compte des suggestions des années passées.

Montre ton amour au Libre

Bissextile ou pas, cette année encore, je m’adresse à toi libriste, qui procrastine en se disant qu’il reste quasi tout décembre pour faire des dons en 2024, déductibles des impôts ou non. Toute l’année on escompte soutenir telle ou telle action sur tel ou tel sujet qui nous méritait vraiment, car c’est important. Donnons quelques exemples d’associations de promotion et défense du Libre, des droits dans l’espace numérique ou de la liberté d’expression, dont les dons sont déductibles en France : Acrimed, Amnesty France, Basta!, Debian France, Disclose, Framasoft (20 ans <3), Fédération internationale pour les droits humains (FIDH), Fonds pour une Presse Libre, Libre à Toi / Radio Cause Commune, Ligue des Droits de l’Homme (LDH), Open Food Facts, OpenStreetMap France, Politis, Reporterre, Reporters Sans Frontières (RSF), Wikimédia France, (qui n’est pas la Wikimedia Foundation états-unienne qui collecte aussi des dons), etc. Ce premier mardi de décembre (jour de rédaction de cette dépêche) est aussi le Giving Tuesday (aussi appelée journée mondiale de la générosité et de la solidarité).

    Sommaire

    Et comme tu fais vivre les principes du Libre, que tu contribues à des projets libres et défends des idées, tu soutiens aussi des associations ne bénéficiant pas de la déductibilité des dons en France (par exemple, des associations jugées trop dérangeantes ou trop critiques par le gouvernement… ou des associations européennes ou non, voire des associations n’ayant jamais fait la démarche, comme LinuxFr). Citons par exemple AFUL, April, Debian CH (déductible en Suisse), European Digital Rights (EDRi), En Vente Libre, Exodus Privacy, FACIL, FFII, FreeBSD Foundation, FSF (avec une longue liste de méthodes pour donner), FSFE (déductibilité dans plusieurs pays), Paheko, GNOME et GIMP, Haiku (déductible aux États‐Unis), IHateMoney, Internet Archive (déductible aux États‐Unis), KDE e.V (déductible en Allemagne), Léa-Linux, LILA, LQDN, Mageia, Nos Oignons, noyb, OKFN, PHP Foundation, SlackBuild.org, Tails (déductible en Allemagne), TechInquiry (déductible aux États-Unis), Toile Libre, Tor (déductible aux États-Unis et en Europe], Ubuntu-Fr, XSF, etc. (notez qu’elles peuvent parfois avoir la déductibilité des dons dans d’autres pays, voir la décision C-318/07 mentionnée plus bas).

    Cette dépêche récurrente vit aussi grâce à vos remarques, propositions d’ajouts, de compléments et vos retours sur les systèmes fiscaux et les dons dans vos pays respectifs. N’hésitez pas à la commenter pour l’enrichir. Bien que récurrente, cette dépêche est mise à jour et enrichie chaque année.

    Précision : la dépêche parle bien de « don » (je soutiens sans rien obtenir à titre personnel), pas de « financement participatif avec contrepartie » (je cofinance en échange de goodies ou avantages), les deux étant destinés à des choses différentes. Si vous avez lu jusqu’ici, un dessin xkcd sur le sujet en récompense (et d’autres images plus loin pour récompenser les libristes patients qui liront jusqu’au bout).

    Pourquoi les associations ayant des permanents ont des besoins récurrents d’argent ? (tiré de l’épisode 12 mais mis à jour)

    Quand une association veut passer de zéro à un permanent ou à un permanent de plus, elle n’a généralement pas en réserve de quoi le payer sur une année complète. Elle prend donc un risque avec une visibilité sur x mois (comme n’importe quel chef d’entreprise), en faisant de son mieux pour que l’argent rentre (le nouveau permanent va « produire », une campagne de communication ou d’appel à don ou autres sera lancée, une subvention sera recherchée, une convention sera signée avec tel ou tel, des goodies seront vendus, etc.).

    Soutenez Framasoft, parce que le Libre n’est pas qu’une question de logiciel

    Une association qui ne veut pas s’embêter à rechercher des fonds ou qui ne vise pas à passer le cap du premier permanent n’a pas du tout ce souci et peut être très indolente si elle veut.

    Dès qu’il y a un besoin récurrent de payer des salariés, de payer à date les charges de l’employeur — qu’il faut prévoir à trois mois s’il faut gérer un préavis de licenciement économique ou pas, etc. —, cela devient plus compliqué (comme pour n’importe quel chef d’entreprise). Une association militante qui ne prendrait pas de risque financier du tout, ce n’est pas envisageable à mon avis. Toute la question étant de savoir combien elle réussit à faire rentrer d’argent au moment où c’est nécessaire, si elle peut continuer à embaucher pour grossir, faire plus d’actions ou faire mieux, si elle doit licencier, ou bien si elle doit stagner ou continuer ainsi dans l’immédiat.

    Donc, oui, on a toujours l’impression que les associations ayant des permanents recherchent de l’argent (et décembre est particulier, car c’est la fin de l’exercice fiscal et traditionnellement la période des dons défiscalisés, notamment côté humanitaire associé aux bons sentiments des fêtes de fin d’année). Et oui, en décembre, la Croix Rouge ou le Secours Populaire, April, RSF, LQDN, la FSF, Amnesty, Framasoft et bien d’autres font des appels à don.

    Soutenons La Quadrature du Net !

    En dehors de la simple mais cruciale question de la trésorerie (pérennité / continuité), il y a bien évidemment aussi les projets et actions futures à financer. Citons par exemple la justification de Framasoft (une dizaine de permanents) en six points :

    1. parce que l’enfermement, c’est maintenant ;
    2. pour plus d’alternatives libres ;
    3. parce que les gentils, c’est nous !
    4. pour décider où vont vos impôts (avec défiscalisation) ;
    5. parce que l’économie du don rend indépendant ;
    6. pour changer le monde ensemble.

    Quelques chiffres : « Chacun s’accorde pour estimer que près de 90% des associations fonctionnent exclusivement grâce à leurs bénévoles. Vitale dans ces associations, cette ressource humaine reste essentielle dans les 10 à 12% d’associations employant des salariés »
    « en 2022, l’emploi privé non lucratif au sein des associations et des fondations représente plus de 155 000 employeurs, plus de 2 millions de salariés, soit 9,5% du total des salariés du secteur privé, et une masse salariale de plus de 54,4 milliards d’euros (près de 7% de la masse salariale du secteur privé) » (Recherche et Solidarités)

    Et sur l’évolution des bénévoles et du mécénat de compétences :

    « Les 25-34 ans sont de plus en plus nombreux à s’engager (30% en 2024 pour 22% en 2019), quand les 70 ans et plus perdent 10 points pour n’être que 24% aujourd’hui. »
    « En 2024, 9% des Français sont présents chaque semaine dans leurs associations, ils étaient 10% en 2019 et 12,5% en 2010. »
    « Ces tendances fragilisent la colonne vertébrale des associations, à savoir celles et ceux qui les font vivre au quotidien qui se trouvent privées de l’expérience et de la disponibilité des seniors »
    « Parmi les perspectives positives, le mécénat de compétences poursuit sa percée avec 27% de bénévoles tentés par l’expérience en 2024 ; ils étaient 23% en 2022 et 20% en 2019. » (Recherche et Solidarités et France Générosités)

    Petit rappel sur les impôts en France (tiré de l’épisode 10 mais mis à jour)

    • l’article 200 du Code général des impôts prévoit pour un particulier une déduction fiscale de 66 % (réduction d’impôt sur le revenu dans la limite de 20 % du revenu imposable, reportable sur cinq ans en cas de dépassement de ce plafond) des dons vers les associations d’intérêt général ou reconnues d’utilité publique ; ce pourcentage monte même à 75 % pour les organismes d’aide aux personnes en difficulté (dans la limite de 521 €, au‐delà, on retombe sur les 66 %) ;
    • l’article 238 bis du CGI prévoit une déduction fiscale de 60 % des dons pour une entreprise (réduction d’impôt sur le revenu ou d’impôt sur les sociétés dans la limite de 5 ‰ du chiffre d’affaires hors taxes, reportable sur cinq ans en cas de dépassement de ce plafond) vers les associations d’intérêt général ou reconnues d’utilité publique ;
    • fiche pratique ServicePublic.fr : « À noter : l’organisme peut être en France ou dans un État membre de l’Union européenne : Allemagne, Autriche, Belgique, Bulgarie, Chypre, Croatie, Danemark, Espagne, Estonie, Finlande, France, Grèce, Hongrie, Irlande, Italie, Lituanie, Lettonie, Luxembourg, Malte, Pays-Bas, Pologne, Portugal, République tchèque, Roumanie, Slovaquie, Slovénie, Suède, en Islande, en Norvège ou au Liechtenstein. S’il n’est pas agréé, vous devez justifier qu’il a un objectif et des caractéristiques similaires aux organismes situés en France et pouvant bénéficier du dispositif. »
    • loi n° 2021-1109 du 24 août 2021 : « Art. 222 bis.-A l’exception de ceux mentionnés au 3 de l’article 200, les organismes qui délivrent des reçus, des attestations ou tous autres documents par lesquels ils indiquent à un contribuable qu’il est en droit de bénéficier des réductions d’impôt prévues aux articles 200,238 bis et 978 sont tenus de déclarer chaque année à l’administration fiscale, dans les délais prévus à l’article 223, le montant global des dons et versements mentionnés sur ces documents et perçus au cours de l’année civile précédente ou au cours du dernier exercice clos s’il ne coïncide pas avec l’année civile ainsi que le nombre de documents délivrés au cours de cette période ou de cet exercice. »

    France générosités mentionne des évolutions récentes (juillet 2024), notamment le fait que les dons des particuliers aux organismes d’intérêt général qui concourent à l’égalité entre les femmes et les hommes ouvrent droit à réduction d’impôt et la prorogation jusqu’au 31 décembre 2026 du plafond dérogatoire de 1 000 € applicable aux dons retenus pour la réduction d’impôt de 75 % accordée au titre des dons versés aux organismes qui apportent une aide gratuite aux personnes en difficulté.

    Exemple pour un particulier : je suis imposable et donne 99 € à l’association XYZ bénéficiant de la déductibilité des dons à hauteur de 66 %. Mon don me coûte en fait (au final) 33 €, j’ai temporairement avancé 66 € qui seront ensuite déduits de mon imposition fiscale (dit autrement, j’ai choisi l’attribution de 66 € du budget de l’État).

    Soutenir Framasoft

    Autres infos :

    Les dons en France (tiré de l’épisode 11 mais mis à jour)

    « 51 % des Français déclarent avoir donné au moins une fois en 2023 à une fondation ou à un organisme caritatif (+1 point par rapport à 2022). »

    (Baromètre de la solidarité 2024)

    « En 2023, la générosité des Français tient bon dans un contexte encore difficile, avec une progression de 2,1% des dons par rapport à 2022 en euros courants. » (ainsi que la « poursuite de la baisse des petits dons » et un « focus sur les urgences médiatisées »)

    (Baromètre de la générosité 2023)

    « l’augmentation des investissements est aussi due à des coûts d’acquisition en hausse (+ 28%) en raison d’une concurrence accrue pour atteindre 33 € de coût d’acquisition moyen par donateur sur les campagnes de fin d’année (CFA) 2022 du panel de l’étude mais pour un don moyen de 172 € (+ 10%). »
    (Baromètre Orixa Fundraising 2023)

    « L’étude de Recherches & Solidarités montre une progression de 6,3% du montant total des dons déclarés au titre de l’IR en 2022 par rapport à 2021.
    L’étude de Recherches & Solidarités montre une progression de 3,9% du nombre de foyers fiscaux donateurs en 2022 par rapport à 2021. »
    (Étude 2023 sur les dons déclarés 2022 – Recherches & Solidarités)

    « en 2022 : en moyenne, les donateurs de 35-54 ans correspondent à une pénétration de 5,5% des Français de cette tranche d’âge. Soit le plus faible taux comparé aux autres tranches d’âge. » (Étude sur le don des 35-54 ans – France)

    Admincal indique que « seulement 4,61 % des entreprises assujettis à l’Impôt sur les Sociétés (IS) déduisent des dons du mécénat ».

    Selon Infodon.fr (via une enquête Ifop pour France générosités, réalisée sur un échantillon représentatif de la population française (4031 personnes) – Mai 2023)
    « 69% des Français déclarent soutenir financièrement assos et fondations, « 46 % donnent au moins une fois par an ». À comparer avec les chiffres donnés en 2022 (72% 48%), 2021 (58%, 45%) et 2020 (52%, 40%).

    Petit rappel sur les impôts d’autres pays (tiré de l’épisode 12 mais mis à jour)

    Forcément, je connais mieux le sujet pour la France, mais voici néanmoins quelques infos glanées pour d’autres pays (et je ne doute pas que les visiteurs compléteront dans les commentaires) :

    Exemple de dons (source)

    Exemple de dons financiers et parfois de temps

    « Sacrifier une partie de son revenu pour faire un don à une association, c’est une affaire sérieuse. » (patrick_g)
    Liste non exhaustive de dons financiers ou de temps à des associations du Libre ou pour libérer quelque chose :

    Pour les exemples plus ou moins exhaustifs sur les 11 premières années de cette série de dépêches, voir la section de l’année 2022

    Exemple de dons de matériel ou ressources

    Pour les exemples plus ou moins exhaustifs sur les 11 premières années de cette série de dépêches, voir la section de l’année 2022.

    Johann « nojhan » — CC-BY-SA-fr, LAL, GFDL

    Diffusion des idées et questionnements autour du don

    Pour les exemples plus ou moins exhaustifs sur les 11 premières années de cette série de dépêches, voir la section de l’année passée.

    Lettre au Père Noël — Clément Clem Quaquin — Licence Art libre

    Don à une entreprise ? (tiré de l’épisode 11 mais mis à jour)

    Une question un peu annexe ici vu le titre « dons aux associations » mais qui a déjà été posée ici ou sur LinuxFr.org : peut‐on faire un don (sans contrepartie) à une entreprise ? Pour prendre quelques sites que j’aime bien : Next.ink anciennement Next INpact (SARL de presse) a opté pour un mélange de comptes premium (avec contrepartie, donc), publicités et dons. Voir les appels à dons 2023 pour le Fonds pour une presse libre ou Next.ink par exemple). Tandis que Reflets.info (SAS) accepte les dons.

    Lors d’une recherche rapide précédente, j’avais vu évoquer l’utilisation du compte 7713 « libéralités perçues » du plan comptable, d’un justificatif clair pour la comptabilité (un expert comptable et/ou un notaire sont évoqués), d’une exonération de TVA si aucune vente de bien ou de service n’est associée. Bref, la question des taxes et impôts à payer pour le donateur (60 % entre non‐parents ?) et l’entreprise n’est pas forcément claire. Cela reste assez flou et hypothétique, et ça mériterait une question aux impôts.

    « Oups, j’ai procrastiné sur mes dons » généré avec https://framalab.org/gknd-creator/.

    Logiciels libres pour gérer les dons (tiré de l’épisode 12 mais mis à jour)

    La question avait été posée lors de l’épisode 3 de cette série de dépêches : quel(s) logiciel(s) libre(s) utiliser pour faire les dons ? Ou pour les gérer ? En général, pour les faire, un navigateur fait l’affaire : paiement en ligne, réception de l’éventuel reçu fiscal, réception d’un éventuel message de remerciement.

    Pour les reçus fiscaux, il convient de les conserver avec les documents des impôts pendant le temps nécessaire (suivant la législation locale).

    Pour les dons via des intermédiaires, par exemple Liberapay ou HelloAsso, il faut conserver soigneusement les identifiants du compte créé pour l’année suivante.

    Si vous avez opté pour l’adhésion à une structure plutôt que le don, vous allez recevoir des identifiants aussi et probablement une lettre interne ou des choses du genre, ainsi que certainement une convocation à une assemblée générale annuelle.

    Et si vous avez opté pour versement régulier (virement ou prélèvement), ça ne change pas fondamentalement les choses ; éventuellement, l’organisme qui prélève vous prévient un peu avant chaque prélèvement par courriel.

    Il existe aussi dans le Libre des logiciels ou des événements spécialement prévus pour les dons :

    À ma connaissance, le site HelloAsso, structure ayant obtenu son agrément « Entreprise solidaire d’utilité sociale », évoqué dans un commentaire de 2015, n’utilise pas une plate‑forme libre, contrairement à Liberapay.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Deno 2.0 est là

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

    Sommaire

    Titre de l'image

    Pour rappel

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

    La mascotte !

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

    Mon dino

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

    Deno 1.x, des débuts difficiles !

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

    Les nouveautés de la version 2.0

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

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

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

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

    Titre de l'image

    Performances du runtime

    Niveau performance, ça donne quoi ?

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

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

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

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

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

    Performances du gestionnaire de paquets

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

    Avec NPM, l'installation a mis 10 secondes.

    Avec Deno, l'installation a mis 1 seconde.

    Avec Bun, l'installation a mis 3 secondes.

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

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

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

    Deno 2.1 est là

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

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

    Conclusion

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

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    L' appel à présentations de la conférence OW2con'25 est ouvert !

    OW2 est ravi d'annoncer l'ouverture de l'appel à présentations d'OW2con'25 ! La conférence annuelle aura lieu les 17 et 18 juin 2025, sur le site des Jardins de l'Innovation de Orange à Paris-Châtillon. Communauté open source internationale et indépendante, OW2 est dédiée au développement de logiciels professionnels de qualité industrielle, et regroupe des entreprises, des collectivités et des organismes de recherche de premier plan dont Orange, l’Inria, la Mairie de Paris et l'institut allemand Fraunhofer Fokus.

    OW2con25

    OW2con est la conférence open source européenne organisée par OW2. Rencontre internationale de contributeurs, éditeurs, ESN, académiques, et organisations à but non lucratif, OW2con rassemble l'ensemble de la communauté open source. OW2con est ouvert à tous, l’évènement est gratuit et les conférences ont lieu en anglais.

    Appel à présentations :

    Cette année l'accent sera mis sur le thème de l'open source et l'IA responsable. Au-delà du buzz de l'IA nous souhaitons aborder des sujets tel que : open source et communs, technologies et innovations, données, souveraineté, vie privée, cadre juridique, financement et économie, durabilité, impact sur le travail et la société, etc. Comment l'open source contribuera-t-il à cette transformation ?

    Merci de soumettre vos propositions, en anglais, avant le 23 février 2025 dans ce thème ou dans l'un des sujets annoncés dans le formulaire de l'appel à présentations.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Bénévalibre - « Libre à vous ! » du 12 novembre 2024 - Podcasts et références

    22 novembre 2024 à 04:27

    Deux-cent-vingt-sixième émission « Libre à vous ! » de l’April. Podcast et programme :

    • sujet principal : Bénévalibre, un logiciel libre pour faciliter la valorisation du bénévolat
    • la chronique « Que libérer d’autre que du logiciel » avec Antanak, intitulée : « Identité numérique »
    • « À la rencontre du libre » poursuit son tour de France avec Martin Hardy, professeur en cursus Bachelor « Expert en informatique » à Agen, dans le Lot-et-Garonne, à l'ESIA : « comment utilise-t-il les logiciels libres dans cette école ? »

    Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 FM en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune.

    Pas d'émission inédite le 26 novembre.

    Mardi 3 décembre 2024, nous recevrons Philippe Bareille, en charge de l'Open Source, et Magali Lemaire, la cheffe du bureau de l'ingénierie logicielle, de la ville de Paris.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    🏆 Meilleures contributions LinuxFr.org : les primées d'octobre 2024

    14 novembre 2024 à 01:25

    Nous continuons sur notre lancée de récompenser celles et ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un livre des éditions Eyrolles, ENI et D-Booker. Voici les gagnants du mois d'octobre 2024 :

    Les livres gagnés sont détaillés en seconde partie de la dépêche. N’oubliez pas de contribuer, LinuxFr.org vit pour vous et par vous !

    Les livres 📚 sélectionnés

    Bandeau LinuxFr.org

    Certaines personnes n’ont pas pu être jointes ou n’ont pas répondu. Les lots ont été réattribués automatiquement. N’oubliez pas de mettre une adresse de courriel valable dans votre compte ou lors de la proposition d’une dépêche. En effet, c’est notre seul moyen de vous contacter, que ce soit pour les lots ou des questions sur votre dépêche lors de sa modération. Tous nos remerciements aux contributeurs du site ainsi qu’aux éditions Eyrolles, ENI et D-Booker.

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

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Capitole du Libre 2024 - au programme du 16 et 17 novembre

    Le Capitole du Libre est un week-end dédié au logiciel libre et à la culture libre en Occitanie. Cette année, la onzième édition se tiendra les samedi 16 et dimanche 17 novembre 2024 à l’ENSEEIHT, dans le centre‐ville de Toulouse (INP-N7).

    Capitole du Libre

    En quelques mots

    Le Capitole du Libre, c'est:

    • Près de 100 conférences
    • Une dizaine d'ateliers
    • Une trentaine de stands associatifs
    • Une communauté présente en nombre : plus de 1000 participants tous les ans
    • Tous les publics représentés, du curieux au développeur noyau, en passant par les geeks et les supporters de la culture libre

    Présentation

    Complètement gratuit, le Capitole du Libre regroupe un large ensemble d'activités:

    • des conférences, qui couvrent un large ensemble de sujets et permettront à tous les publics de découvrir ou d'approfondir des sujets techniques, leur maîtrise d'un logiciel, les actualités relatives au numérique, etc.
    • des ateliers, pour découvrir par la pratique des logiciels libres
    • une table ronde: cette année, elle portera sur le thème des modèles de gouvernance des projets libres

    Un village associatif sera également présent pour vous permettre de rencontrer et discuter avec de nombreux acteurs du monde libre.

    ⚠️ L'accès est gratuit, mais une inscription est obligatoire.

    Flyer de l'évènement

    Keynotes

    Deux moments sont proposés pour cette édition:

    Ateliers

    Venez découvrir le logiciel libre lors d’ateliers avec des experts pour vous assister.

    Les ateliers au programme cette année traiteront de logiciels de dessin, de réalisation de jeu vidéo, de réalisation physique d'objets, de développement, de résolution de problèmes, d'éditeurs de textes, etc.

    Village associatif

    Retrouvez les associations qui œuvrent pour le logiciel libre : Framasoft, April, Toulibre, CHATONS…

    Install party

    Venez-vous faire aider pour installer Linux, pour corriger les problèmes que vous rencontrez avec votre installation ou pour toute question autour du logiciel libre.
    Un atelier permanent est dédié tout le week-end.

    Boutique

    Repartez avec un T-shirt de l’événement, un sweatshirt d'un logiciel libre que vous appréciez, un mug, …
    Les ventes permettent de financer le Capitole du Libre.

    LAN party

    Pour les jeunes (et moins jeunes) qui souhaiteraient s'amuser tout en restant dans le thème du logiciel libre, venez jouer à quelques jeux libres avec la LAN party.

    Cocktail

    Comme chaque année, un moment de convivialité ouvert à tous et toutes est prévu le samedi soir.

    MiniDebConf

    Logo de la MiniDebConf

    Cette année, une conférence MiniDebConf aura lieu en parallèle du Capitole du Libre, accessible directement à partir du hall principal de l'école, et vous pourrez donc profiter des conférences des deux évènements à votre guise, rencontrer des développeurs Debian, etc.

    Pour plus d'information sur la MiniDebConf…

    Informations pratiques

    Restauration

    Des food trucks sont à votre disposition les midis, directement à l'intérieur de l'établissement.

    Si vous préférez vous restaurer à l'extérieur, le quartier possède également de nombreux restaurants et boulangeries.

    Entrée

    Comme tous les ans, l’accès à l’événement est totalement gratuit !

    ⚠️ Attention, puisque l'établissement qui nous accueille est une école, une inscription en ligne est obligatoire et le personnel de sécurité demandera à inspecter vos sacs à l'entrée.

    Les portes seront ouvertes:

    • le samedi 16 novembre 2024 de 9h30 à 22h
    • le dimanche 17 novembre 2024 de 10h à 16h30

    Nous vous attendons nombreux !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Fedora Linux 41 est dans la place

    En ce mardi 29 octobre 2024, les utilisateurs du Projet Fedora seront ravis d’apprendre la disponibilité de la version Fedora Linux 41.

    Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

    Bureau GNOME

    Sommaire

    Expérience utilisateur

    Passage à GNOME 47. Cette nouvelle version de l’environnement phare de Fedora propose de nombreuses améliorations. Tout d’abord, il est maintenant possible de personnaliser une couleur "accentuée" (accent color) qui influencera la couleur de nombreux éléments graphiques comme des boutons. Cela intègre donc un changement en place chez Ubuntu depuis quelques années. Pour ceux disposant de petits écrans, certains boutons et autres icônes sont agrandies pour rendre leur interaction plus aisée dans ce contexte.

    L’interface a été en partie remaniée au niveau des boîtes de dialogue pour rendre leur interaction plus simple notamment avec des petits écrans avec des boutons plus gros et plus espacés entre eux. Et bien sûr ces boutons tiennent compte maintenant de la couleur accentuée explicitée précédemment. L’interface pour ouvrir ou sauvegarder un fichier repose maintenant sur le code du navigateur de fichiers nommé Fichiers plutôt que d’utiliser un code indépendant jusqu’ici. Cela simplifie la maintenance mais permet surtout de fournir l’ensemble des fonctionnalités du navigateur de fichiers pour cette tâche. Par exemple il est possible de renommer des fichiers depuis cette interface, de changer l’ordre d’affichage en vue icônes, prévisualiser les fichiers sans les ouvrir, etc. Par ailleurs, le navigateur de fichiers s’améliore aussi. Les périphériques réseaux sont maintenant classifiés permettant d’identifier les ressources où on est déjà connecté, qu’on a précédemment utilisé et les autres. L’ensemble des disques durs internes sont également affichés dans la barre latérale et groupés ensemble pour rendre cela plus accessible et facile d’utilisation. Il est possible également de supprimer les dossiers par défaut dans la barre latérale pour faire de la place si on le souhaite. Et quelques autres changements plus mineurs.

    Dans la configuration de l’interface, il est possible via le menu Accessibilité de configurer le changement automatique de focus d’une fenêtre à une autre par le simple survol de la souris. Option désactivée par défaut. De même lors de l’ajout de nouvelles dispositions clavier, la prévisualisation de cette disposition peut être effectuée avant de la sélectionner pour s’assurer que c’est bien celle souhaitée. De manière générale, l’affichage des préférences est plus cohérente dans le choix des éléments graphiques pour les représenter à travers l’interface.

    Les comptes en ligne progressent également, les informations IMAP ou SMTP sont préremplies en se basant sur l’adresse électronique. La synchronisation du calendrier, des courriels et des contacts a été ajoutée pour les comptes Microsoft 365 pendant que la configuration d’un nouveau compte WebDAV permet de découvrir les services accessibles depuis ce compte pour faciliter l’expérience utilisateur.

    Le navigateur web maison n’est pas en reste et propose quelques améliorations dont le pré remplissage des formulaires en se basant sur les entrées précédentes ce qui est disponible dans de nombreux navigateur. L’option peut être désactivée dans les préférences si nécessaire. Les marques pages ont été aussi remaniés en étant affichés dans un volet latéral et en proposant une barre de recherche intégrée pour retrouver celui qu’on souhaite. Le navigateur peut afficher le nombre de trackers publicitaires qui ont été bloqués. Malheureusement la synchronisation des éléments via Firefox Sync n’est plus possible en ce moment à cause d’un changement dans la procédure d’authentification par Mozilla.

    L’application calendrier a été également améliorée avec par exemple une icône de cadenas qui s’affiche pour les événements qui sont en lecture seule. La mise en page est plus cohérente notamment dans l’espacement entre les éléments visuels. L’importation ou l’édition d’événements gèrent mieux les calendriers cachés ou en lecture seule. L’application de cartographie a été aussi légèrement améliorée en utilisant les cartes vectorisées par défaut et en proposant les trajets en transport en commun en exploitant le service Transitous plutôt qu’une solution commerciale.

    Pour les amateurs d’enregistrement de leur écran en vidéo, cette tâche peut être effectuée dans la mesure du possible avec de l’accélération matérielle ce qui diminue la consommation d’énergie et améliore les performances du système dans ce cadre. Dans la même veine, le rendu effectué par la bibliothèque graphique GTK se fait via Vulkan dorénavant ce qui améliore les performances en particulier pour les machines plus anciennes et avec moins d’effets visuels indésirables due à la lenteur de certaines opérations. Dans la même veine, il y a une amélioration des performances des applications vidéos, photos et du navigateur web maison par la réduction quand c’est possible du nombre de copies en mémoire des données d’une vidéo ou d’une image.

    Pour ceux qui ont accès à leur session à distance, il est dorénavant possible de rendre cette session persistante. En cas de déconnexion il est possible de revenir plus tard et de retrouver la session dans l’état où elle était.

    Pour les utilisateurs avancés, il y a des changements expérimentaux qui sont proposés. Si vous souhaitez utiliser la mise à échelle fractionnaire de l’interface pour les applications utilisant X11 via XWayland, vous pouvez l’activer via la commande suivante :

    $ gsettings set org.gnome.mutter experimental-features '["scale-monitor-framebuffer", "xwayland-native-scaling"]'

    Couleur d’accentuation dans GNOME

    L’environnement de bureau léger LXQt passe à la version 2.0. Cette mise à jour importante est essentiellement technique avec un port complet vers la bibliothèque graphique Qt 6 au lieu de Qt 5 qui n’est bientôt plus maintenue. La prise en charge de Wayland est disponible à titre expérimental, cela devrait être stabilisé pour la version 2.1 à venir.

    L’éditeur d’image GIMP utilise la branche de développement qui deviendra la version 3. Cette décision a été prise car GIMP devenait la raison principale pour maintenir le langage Python 2.7 dans la distribution qui n’est plus maintenue depuis quelques années. Alors que GIMP 3 devrait sortir sous peu, il a été décidé de prendre potentiellement un peu d’avance pour permettre de supprimer cette dépendance assez lourde et complexe de Fedora.

    Outre cette décision, cette version de l’application propose entre autres une meilleure gestion des couleurs avec notamment la visualisation, l’import ou l’export d’images avec la colorimétrie CMJN. Les tablettes graphiques ont une expérience utilisateur améliorée avec notamment la possibilité de personnaliser l’action des boutons de ce matériel sous Wayland, et la prise en charge des écrans avec une définition HiDPI est aussi améliorée. L’édition non destructive est également possible pour séparer l’application des effets des calques de l’image pour permettre de revenir dessus plus tard. Si on le souhaite, un calque peut se redimensionner automatiquement lors de son édition lors d’un dessin par exemple. Et bien d’autres changements.

    Le gestionnaire de listes de tâches Taskwarrior évolue à la version 3. Cette version a surtout changé la manière de stocker les données sauvegardées et n’est pas rétrocompatible avec l’ancienne méthode. Il est donc nécessaire d’exporter les tâches avec l’ancienne version par l’usage de la commande task export et de les importer avec la nouvelle version avec la commande task import rc.hooks=0. La tâche de sauvegarde est aussi confiée à un nouveau module TaskChampion écrit en Rust.

    La mise à jour du cœur des systèmes atomiques de bureau peut se faire sans droits administrateurs, mais pas les mises à niveau de celui-ci à savoir par exemple passer d’une version Fedora Linux Silverblue 40 à Fedora Linux Silverblue 41. Cela était déjà le cas pour Fedora Silverblue avec l’usage de GNOME Logiciels mais a été de fait généralisé. L’objectif est de simplifier la procédure de mise à jour du système, qui dans le cadre d’un système atomique est considéré comme plus sûre que dans un système traditionnel de par sa conception qui permet facilement de revenir à l’état précédent et par la faible quantité de logiciels installés dans le cœur du système.

    Les autres opérations ne sont pas considérées à ce stade car trop risquées pour être confiées à un simple utilisateur. Pour certaines opérations le mot de passe administrateur sera systématiquement demandé telles que l’installation d’un nouveau paquet local, la mise à niveau complet du système (qui consiste en une opération de rebase avec une autre branche de travail), ou changer les paramètres du noyau. Pour d’autres comme l’installation d’un paquet provenant d’un dépôt, la mise à jour, le retour dans un état précédent ou l’annulation d’une commande peut se faire sans demander systématiquement le mot de passe, comme lors de l’usage de commandes via sudo si les opérations ne sont pas trop espacées.

    Mise à disposition des images Spin KDE Plasma Mobile et Fedora Kinoite Mobile. L’objectif est de fournir une image native avec cet environnement qui fonctionne aussi bien pour téléphone que pour les tablettes ou petits ordinateurs portables 2-1 avec possibilité de détacher l’écran tactile du clavier.

    De même le gestionnaire de fenêtres en mode pavant Miracle exploitant Wayland est proposé dans Fedora et bénéficie de son propre Spin. Cette interface moderne prend en charge aussi les fenêtres flottantes, prend en charge les dernières montures de Wayland tout en permettant l’usage des pilotes propriétaires de Nvidia. Il consomme également peu de ressources ce qui le rend intéressant dans l’usage de machines peu performantes ou anciennes tout en exploitant une pile graphique très moderne et flexible.

    L’installation de Fedora Workstation se fera avec le protocole d’affichage Wayland uniquement, les sessions GNOME X11 restent disponibles et installables après. Cela suit l’effort entrepris depuis longtemps de faire de Wayland le protocole d’affichage par défaut de Fedora et par l’abandon progressif de X11 par GNOME également. L’état actuel du système permet de franchir ce cap par défaut ce qui allège également un peu le média d’installation. Cependant pour ceux qui veulent toujours utiliser GNOME avec X11 après l’installation pour différentes raisons, il reste possible d’installer les paquets gnome-session-xsession et gnome-classic-session-xsession depuis les dépôts officiels.

    Prévisualisation du clavier dans GNOME

    Gestion du matériel

    L’installation du pilote propriétaire de Nvidia via GNOME Logiciels est compatible avec les systèmes utilisant l’option Secure Boot. Ce mode de sécurité s’assure que tous les éléments de la chaine de démarrage de la machine sont signés avec une des clés cryptographiques autorisées. L’objectif est d’éviter qu’une tierce personne puisse modifier un de ces composants dans le dos d’un utilisateur afin de réaliser une attaque plus tard. Le chargeur de démarrage GRUB, le noyau Linux et ses pilotes sont évidemment concernés, et installer le pilote propriétaire de Nvidia qui n’est pas signé pouvait rendre la machine impossible à démarrer.

    Même si Fedora ne fournit pas ce pilote, car il est non libre, l’objectif reste d’avoir un système fonctionnel et simple à utiliser. Dans ce contexte, GNOME logiciels permet d’outre passer cette limitation en utilisant l’outil mokutil pour auto signer le pilote Nvidia. L’utilisateur devra saisir un mot de passe à l’installation du paquet, et au redémarrage suivant cet outil sera affiché pour confirmer la clé de sécurité et ainsi autoriser le chargement du dit pilote sans encombre.

    Prise en charge des caméras MIPI pour les systèmes utilisant Intel IPU6 qui concerne de nombreux ordinateurs portables actuels. En effet, de nombreux modèles utilisent le bus MIPI CSI2 au lieu du traditionnel USB UVC qui était la norme jusqu’à présent. En effet ce protocole permet des bandes passantes plus élevées, en consommant moins d’énergie et plus facile à intégrer. Sauf que la prise en charge de ce bus n’était pas pleinement gérée, car les images envoyées sont un peu brutes et nécessitent des traitements notamment concernant la balance des blancs ou le dématriçage de l’image ou le contrôle pour l’exposition et le gain. Cela est complexe, car chaque caméra a ses propres caractéristiques qui nécessitent une approche au cas par cas en espace utilisateur. Un travail d’intégration a été fait entre le noyau Linux, libcamera, pipewire et Firefox pour rendre cela possible. Le noyau Linux fourni l’API de base et un pilote pour chaque type de modèles, avec un pilote commun pour la prise en charge du protocole en lui-même. Le flux vidéo est récupéré par libcamera qui applique des traitements tels que le dématriçage en prenant en compte le modèle considéré, qui envoie le flux vidéo obtenu par pipewire vers le navigateur Firefox.

    L’installateur Anaconda prend en charge le chiffrement matériel des disques via le standard TCG OPAL2 disponible sur certains péripériques SATA ou NVMe, mais cela nécessite de passer via un fichier kickstart pour personnaliser l’installation. L’outil cryptsetup n’a pris en charge ce standard que très récemment, l’objectif est de fournir les arguments --hw-opal-only ou --hw-opal à cet utilitaire dans le fichier kickstart. Le premier argument n’active que le chiffrement matériel, ce qui est recommandé uniquement pour des périphériques où l’usage du CPU pour cette tâche nuirait grandement aux performances, alors que le second utilise un chiffrement matériel et logiciel. Il n’est pas prévu de fournir cette fonctionnalité par défaut et restera pendant un moment une option pour les utilisateurs avancés, car la sécurité de l’ensemble dépend de la qualité des firmwares de ces périphériques de stockage et qui doivent être maintenus à jour dans le temps ce qui n’est pas garanti.

    Utilisation par défaut de l’outil tuned au lieu de power-profiles-daemon pour la gestion de l’énergie de la machine. C’est l’outil qui permet notamment de passer du mode économie d’énergie à performance pour moduler la puissance du CPU en fonction de la consommation d’énergie souhaitée, ce qui est très appréciable sur les ordinateurs portables en particulier. Cependant power-profiles-daemon est très simple, en dehors de ces modes très génériques et d’appliquer cela sur les CPU ou les plateformes matérielles supportées, il ne permettait une configuration plus fine ou l’ajout de modes personnalisées. Les utilisateurs avancés étaient contraints d’installer un utilitaire additionnel comme tuned pour cela. Il a été ajouté un paquet tuned-ppd qui fourni une API DBus compatible avec l’interface de power-profiles-daemon, ainsi les applications telles que le centre de configuration de GNOME, Plasma ou Budgie peuvent s’en servir directement à la place sans régression, tout en permettant aux utilisateurs avancés d’aller plus loin s’ils le souhaitent en modifiant le contenu de /etc/tuned/ppd.conf comme en changeant les réglages périphérique par périphérique.

    Mise à jour de ROCm 6.2 pour améliorer la prise en charge de l’IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d’AMD. Il fournit entre autres des nouveaux composants tels que Omniperf pour l’étude et l’analyse de performance, Omnitrace pour tracer l’exécution des fonctions sur le CPU ou le GPU, rocPyDecode comme implémentation de l’API rocDecode en Python pour l’analyse des données de profilage faits avec cet outil en C ou C++ ou ROCprofiler-SDK pour identifier les points bloquants de performance. Il prend en charge également les dernières versions des outils PyTorch et TensorFlow.

    L’outil de développement et de débogage des tables ACPI nommé acpica-tools ne prend plus en charge les architectures gros boutistes tels que s390x. En effet, ce standard qui est conçu pour les machines petits boutistes n’a pas beaucoup de sens pour cette architecture, les paquets qui en avaient besoin pour s390x ont de moins en moins cette dépendance et comme l’usage de cette architecture reste faible surtout pour cet usage, il a été décidé de retirer la prise en charge de cette spécificité. 49 correctifs sur 69 concernant ce paquet sont liés à cette prise en charge, car le projet n’a jamais voulu les adopter par manque d’intérêt, ce qui impliquait beaucoup de test et de développement ralentissant la fréquence des mises à jour du paquet. Ces correctifs sont maintenant supprimés.

    PHP ne prend plus en charge les processeurs x86 32 bits. Il n’y avait déjà plus de paquets PHP 32 bits dans les dépôts, mais PHP était toujours compilé pour permettre à d’autres dépendances de l’être pour cette architecture. Des restrictions ont été ajoutées à ces dépendances pour que cela ne soit plus bloquant. PHP était souvent utilisé dans le cadre de tests ou pour gérer des plugins ou extensions qui pouvaient être désactivées. L’architecture x86 32 bits n’est pour rappel plus pris en charge par Fedora depuis quelques années maintenant, ces paquets ne sont utilisables que sur des machines x86 64 bits pour des raisons de compatibilité. Ce nettoyage permet en contrepartie un gain de temps machine et de développeurs, car il n’y a plus à gérer ce cas de figure.

    Internationalisation

    Le gestionnaire d’entrées IBus par défaut pour la langue traditionnelle chinoise de Taiwan passe de ibus-libzhuyin à ibus-chewing. En effet la bibliothèque chewing sous-jacent semble avoir une communauté dynamique qui fournit une bonne maintenance contrairement à libzhuyin qui n’est d’ailleurs pas maintenu en ce moment par un locuteur de cette langue ce qui pose quelques difficultés. Le code semble également mieux organisé et plus maintenable.

    Nouvelles options de focus dans GNOME

    Administration système

    Le gestionnaire de paquet dnf est mis à jour vers sa 5ᵉ version. Cette version écrite en C++ au lieu de Python est bien plus rapide à l’usage et consomme moins d’espace disque et requiert moins de dépendances pour tourner, l’ensemble est 60% plus léger sur le disque. Par ailleurs dnf5daemon remplace PackageKit comme couche de compatibilité pour dnf dans GNOME Logiciels, ce qui permet notamment le partage des caches entre l’interface console et l’interface graphique évitant un gaspillage d’espace disque et de bande passante. Niveau performance, certaines opérations sont maintenant parallélisées comme le téléchargement et le traitement des données des dépôts qui doit être jusqu’à deux fois plus rapide. Les plugins sont également mieux intégrés ce qui en simplifie leur installation et leur maintenance. Cependant certains plugins n’ont pas été encore portés, vous pouvez suivre l’avancement pour ceux qui manquent à l’appel. Mais cela ne devrait concerner que peu d’utilisateurs. Certaines options de la ligne de commande n’existent plus par ailleurs, cela vous sera rappelé si vous les invoquiez. L’historique des précédentes transactions de paquets comme les mises à jour ou installations ne sont pas compatibles entre l’ancienne et la nouvelle version, vous ne pourrez donc pas voir vos anciennes transactions pour les annuler par exemple.

    Tandis que la commande rpm utilise la version 4.20. Cette version permet de lister ou de supprimer les clés pour signer les paquets via la commande rpmkeys alors que l’outil rpmsign permet de signer les paquets avec l’algorithme ECDSA. La commande rpm elle-même permet d’afficher une sortie en format JSON, en plus du format XML déjà pris en charge depuis longtemps. Un nouveau plugin rpm-plugin-unshare apparaît pour empêcher à des scripts d’installation de faire certaines opérations sur le système de fichiers ou via le réseau pour des raisons de sécurité. Côté création de paquet, l’introduction de la directive BuildSystem est sans doute la plus importante pour permettre de définir de manière unique et générique la création de paquets basés sur des outils communs tels que autotools ou cmake. L’empaqueteur n’aurait pas besoin de rappeler pour ces outils courants chaque étape pour la création du paquet, sauf en cas de particularité, ce qui permet une meilleure maintenance et cohérence au sein de la distribution par exemple.

    Les systèmes Fedora atomiques de bureau et Fedora IoT disposent de bootupd pour la mise à jour du chargeur de démarrage. La mise à jour du chargeur de démarrage au sein d’un système atomique n’est pas trivial, car ce n’est pas une opération facile à fiabiliser. Par conséquent rpm-ostree ne prenait pas cela en charge, et c’est pourquoi bootupd a été créé et est maintenant intégré dans ces versions. Il était déjà présent depuis quelque temps sur la version CoreOS ce qui a déjà donné un retour d’expérience en conditions réelles. Il peut prendre en charge les systèmes UEFI et BIOS, mais la mise à jour reste une étape manuelle pour être automatisée dans le futur, notamment quand le composant shim sera à jour pour rendre la mise à jour moins risquée sur les systèmes UEFI si la mise à jour est coupée au milieu de l’opération comme lors d’une coupure de courant ou lors d’un plantage. Il permet également de pouvoir bloquer l’usage de versions du chargeur de démarrage plus anciens ayant des failles connues, par l’usage de Secure Boot dbx et le paquet ostree-grub2 pourra être progressivement retiré, ce qui notamment mettra un terme au bogue où chaque déploiement est affiché deux fois dans l’interface de sélection de GRUB et devrait réduire le risque d’avoir certains problèmes lors de la mise à jour du système.

    Les images atomiques de Fedora proposent les outils dnf et bootc, ce premier est utilisable dans un contexte de développement pour l’instant mais le second peut commencer à servir à déployer des images du système qui sont bootables. Plus tard il est prévu que dnf puisse remplacer rpm-ostree pour certaines actions. En attendant, en cas d’usage de dnf sur de tels systèmes, le message d’erreur sera plus explicite concernant les outils à employer pour réaliser ces actions. L’objectif est de fournir aux administrateurs systèmes des outils plus familiers pour ces différentes actions tout en ayant un outil clairement identifié pour chaque type de tâches.

    Introduction de l’outil fedora-repoquery pour faire des requêtes sur les dépôts comme savoir la version exacte d’un paquet spécifique dans une autre version de Fedora, la date de mise à jour d’un dépôt, ou connaître les paquets qui dépendent d’un paquet spécifique (dépendance inverse donc), etc. Il fonctionne par-dessus dnf concernant cette fonction mais permet de facilement obtenir des informations depuis les dépôts Fedora, CentOS ou EPEL.

    La bibliothèque de sécurité OpenSSL n’accepte plus les signatures cryptographiques avec l’algorithme SHA-1. Cet algorithme n’est plus considéré comme sûr, car il devient de plus en plus facile de générer des collisions à la demande. Si vous souhaitez les autoriser à nouveau pour des raisons légitimes, malgré le risque de sécurité, cela reste possible de le faire via la commande

    # update-crypto-policies --set FEDORA40

    Commande qui devrait être prise en charge pendant quelques versions encore.

    Le gestionnaire de réseaux NetworkManager ne prend plus en charge la configuration dans le format ifcfg qui était déjà désuet depuis des années. Cela fait suite aux tentatives progressives d’utiliser massivement le format keyfile. Fedora Linux 33 en l’utilisant comme format par défaut pour les nouveaux profils de connexions, tandis que Fedora Linux 36 a poussé la prise en charge de l’ancien format dans un paquet dédié non installé par défaut nommé NetworkManager-initscripts-ifcfg-rh et enfin Fedora Linux 39 a entamé la conversion automatique vers le nouveau format. Et depuis longtemps NetworkManager ne fait que maintenir ce format, de nombreuses options ou types de connexions n’étant de fait pas possibles avec l’ancien format. Cela permet de préparer la suppression future de la prise en charge de ce format de fichier de NetworkManager lui-même.

    Dans la même veine, le paquet network-scripts a été retiré, mettant fin à la gestion du réseau via les scripts ifup et ifdown. Depuis 2018 ces outils sont considérés comme obsolète et soumis à une suppression planifiée future. D’ailleurs le projet officiel ne fait plus une maintenance très active de ces outils.

    Les interfaces réseaux pour les éditions Cloud vont utiliser les nouveaux noms par défaut (par exemple enp2s0f0) comme adoptés par les autres éditions il y a des années au lieu de conserver les noms traditionnels (tels que eth0). Cela signifie que le noyau ne recevra plus pour ces systèmes le paramètre net.ifnames=0 pour maintenir cet ancien comportement. Le reste de l’écosystème avait adopté la nouvelle nomenclature avec Fedora… 15 en 2011 ! Ce retard est attribuable à certains problèmes avec certains outils tels que cloud-init avec cette convention de nommage qui ont été résolus à la fin des années 2010 seulement. Ainsi les périphériques auront maintenant une correspondance physique, leur rôle devrait être plus facilement identifiable et limiter le risque de problèmes suite à des changements dynamiques des interfaces.

    Le gestionnaire de virtualisation libvirt utilise maintenant par défaut le pare-feu nftables au lieu de iptables pour son interface réseau vibr0. En effet Fedora utilise par défaut nftables maintenant et par ailleurs utiliser iptables signifiait créer des règles nftables sous le capot. Cette transition est faite pour améliorer les performances et réduire le risque d’une suppression accidentelle de règles par une application tierce, car tout sera mis dans les règles associées à la table libvirt_network. iptables sera cependant utilisé si nftables n’est pas présent dans le système et le comportement peut être changé dans le fichier de configuration /etc/libvirt/network.conf.

    L’outil Netavark pour gérer la pile réseau des conteneurs, notamment avec podman, utilise également par défaut le pare-feu nftables au lieu de iptables. Les avantages du changement sont assez similaires à ce qui est expliqué au point précédent, les règles associées à l’outil seront mises dans la table dédiée netavark. La possibilité d’envoyer les règles par lot peut améliorer de manière légère le temps de démarrage des conteneurs par ailleurs.

    Le gestionnaire de conteneurs Kubernetes a des nouveaux paquets versionnés, permettant d’avoir plusieurs versions en parallèle. Ici les versions 1.29, 1.30 et 1.31 sont proposées avec des noms comme kubernetes1.31. Cela devenait nécessaire car Kubernetes maintient 3 versions sur une période de 4 mois par version seulement ce qui rend nécessaire un tel montage. Cela permet aussi de découpler la version de Kubernetes avec la version de Fedora Linux ce qui facilite la gestion pour les administrateurs.

    L’implémentation des interfaces de Kubernetes fait par l’OCI a ses propres paquets cri-o et cri-tools qui sont également versionnés pour pouvoir suivre les versions de Kubernetes.

    GIMP 3

    Développement

    Mise à jour de la suite de compilation GNU : binutils 2.42, glibc 2.40 et gdb 15.

    Pour la suite d’outils binutils, cela se concentre surtout sur la prise en charge plus étendue des instructions des architectures Aarch64, RISC-V et x86_64. Il gère notamment les registres supplémentaires et les instructions associées proposés par l’évolution de l’architecture x86 avec Intel APX. L’assembleur BPF améliore son interopérabilité avec les outils de LLVM en suivant les mêmes conventions.

    La bibliothèque standard C commence une prise en charge expérimentale de la norme C23. La capacité de renforcer la sûreté des programmes compilés avec le compilateur Clang a été aussi améliorée pour se rapprocher de ce qui est possible de faire avec le compilateur GCC. De nombreuses fonctions mathématiques ont une version vectorisée pour l’architecture Aarch64 ce qui peut améliorer les performances pour cette architecture.

    Pour finir le débogueur améliore significativement son API Python pour faciliter sa manipulation à travers un programme ou script écrit dans ce langage. La prise en charge du protocole Debugger Adapter Protocol s’améliore encore pour faciliter sa manipulation par divers IDE qui s’en servent pour l’intégrer. Les informations de débogage du programme cible au format DWARF sont lues dans un fil d’exécution dédié pour améliorer le temps de chargement.

    Mise à niveau de la suite de compilateurs LLVM vers la version 19. Les paquets versionnés des versions précédentes sont toujours disponibles pour ceux qui ont besoin de la compatibilité avec les anciennes bibliothèques. Les paquets clang, compiler-rt, lld et libomp sont maintenant générés à partir du fichier de spécification du paquet llvm ce qui n’était pas le cas avant. Cela permet entre autres de simplifier leur maintenance mais aussi d’appliquer une optimisation Profile-Guided Optimizations sur ces binaires pour améliorer les performances. Les paquets Fedora compilés avec Clang bénéficient aussi de la compilation avec l’option -ffat-lto pour avoir des bibliothèques ayant le bitcode LTO en plus du binaire au format ELF, ce qui permet de réduire le temps de l’édition de lien quand ces bibliothèques sont impliquées. Le tout sans recourir à des macros pour obtenir le résultat après la compilation des paquets et sans renoncer à la compatibilité pour les logiciels non compilés avec ce mode activé.

    Retrait de Python 2.7 dans les dépôts, seule la branche 3 est maintenue dorénavant. Enfin, cela est vrai pour l’implémentation de référence, il reste possible de le faire via PyPy qui fourni toujours un support de la version 2.7 via le paquet pypy. Pour rappel, Python 2.7 n’est plus maintenu depuis début 2020, mais ce maintien était nécessaire pour certains paquets qui n’avaient toujours pas terminé leur portage, en particulier le logiciel GIMP, cas abordé plus haut. Les autres paquets concernés n’étaient plus vraiment maintenus de fait et ont été retirés. Cela devenait nécessaire car avec la fin de support de RHEL 7 prochainement, plus aucun correctif pour Python 2 ne sera développé à l’avenir rendant la situation plus critique encore.

    D’ailleurs Python bénéficie de la version 3.13. Cette version fournit un nouvel interpréteur interactif avec la coloration activée par défaut pour le prompt ou les erreurs. Il donne la possibilité d’avoir de l’édition multi-lignes qui est préservée dans l’historique. Les touches F1, F2 et F3 donnent respectivement l’accès à une aide interactive, à la navigation de l’historique de l’édition et à un mode de copie plus simple pour copier-coller de gros blocs de code. Les messages d’erreur sont également plus clairs.

    En dehors de cela, Python dispose du tant attendu mode sans verrou global nommé GIL ce qui permet d’améliorer les performances et de faire de réels fils d’exécution parallèle dans un programme. Mais ce mode étant expérimental, il faut installer le paquet python3.13-freethreading et exécuter Python avec la commande python3.13t pour en profiter.

    Le compilateur juste à temps n’est quant à lui pas fourni d’une façon ou d’une autre, cette fonctionnalité étant aussi expérimentale.

    Python est aussi compilé avec l’optimisation -O3 activée, en ligne avec la manière de faire par le projet officiel et améliorant les performances. Selon le test pyperformance le gain de performance est en moyenne 1,04 fois plus rapide rien qu’avec cette option. Auparavant Python était compilé avec l’optimisation -O2 qui est moins agressive, cependant la nouvelle option augmente la taille des binaires concernés d’environ 1.2% (soit 489 kio).

    Le framework d’écriture de tests en Python, Pytest se teste avec sa version 8. Cette version n’est pas compatible avec la version précédente, de nombreux éléments obsolètes sont maintenant traités comme des erreurs, et de même la façon dont les tests sont récupérés dans l’arborescence d’un code source a été modifiée ce qui peut poser différents problèmes.

    En termes d’amélioration, il propose un meilleur affichage des diff en cas d’erreur lors de l’exécution d’un test, le rendant plus lisible et plus proche du visuel d’un différentiel généré à partir de la commande diff.

    Mise à jour du langage Go vers la version 1.23. Cette version apporte la télémétrie pour collecter des données sur l’usage de la chaine de compilation Go aux développeurs du projet, par défaut dans Fedora la télémétrie est activée mais reste uniquement sur votre machine, rien n’est envoyé aux serveurs du projet. Ce comportement peut être changé dans les options.

    Autrement, quand le temps de compilation est amélioré lorsqu’un profil d’optimisation est utilisé, passant d’un délai supplémentaire pouvant aller jusqu’au double du temps de compilation normal à maximum 10% supplémentaire maintenant. Les applications Go ont un usage de la pile qui est légèrement réduit tandis que pour l’architecture x86_64, au détriment d’une légère augmentation de la taille du binaire, les boucles peuvent avoir une amélioration de performances d’environ 1-1,5%.

    Mise à jour dans l’écosystème Haskell GHC 9.6 et Stackage LTS 22. Le compilateur en lui-même propose de compiler le code pour être exécuté en tant que programme WebAssembly ou JavaScript. Les deux sont cependant considérés comme en développement et peuvent être sujets à des bogues. L’ensemble des messages d’erreur ont maintenant un code unique, permettant de simplifier la recherche d’une explication et d’une solution concernant celui-ci.

    Le langage Perl passe à la version 5.40. Un nouveau mot clé __CLASS__ donne la classe d’exécution réelle dont l’instance d’objet est membre, ce qui est utile pour les constructeurs de classes enfants, car l’accès à $self n’étant pas autorisé dans ce contexte. Un autre mot clé :reader est proposé, ajouté à un membre de classe il permet de définir automatiquement une fonction du même nom que le membre, qui renvoie cette valeur. Un nouvel opérateur ^^ est disponible, étant l’équivalent de && et || mais pour la fonction logique ou exclusif.

    Node.js 22 devient la version de référence, tandis que la version 20 et 18 restent disponibles en parallèle. Cette version propose entre autres un client Websocket natif sans dépendances additionnelles, une mise à jour habituelle du moteur JavaScript V8 vers la version 12.4 qui propose notamment un ramasse-miette WebAssembly. Les flux de données passent par défaut d’un buffer de 16 kib à 64 kib ce qui augmente les performances au détriment de la consommation de mémoire vive. Enfin le compilateur JIT Maglev fourni par le moteur V8 est activé par défaut, qui améliore les performances en particulier pour les petits programmes exécutés en ligne de commande.

    Pour des raisons de changement de licence, le gestionnaire de bases de données clé-valeur Redis est remplacé par Valkey. En effet Redis a adopté la licence RASLv2/SSPL en remplacement de la licence BSD qui n’est pas une licence libre ce qui est en conflit avec les règles de Fedora concernant les licences des logiciels proposés dans ses dépôts. Valkey est un fork de Redis qui réutilise la même licence originelle. À ce jour pas d’incompatibilité est à prévoir pour les utilisateurs de ce logiciel, mais un paquet valkey-compat est proposé pour migrer la configuration et les données depuis Redis. Le changement est effectué automatiquement lors de la mise à niveau de Fedora pour ces utilisateurs.

    La bibliothèque Python d’apprentissage profond Pytorch est éclairée avec sa version 2.4. Le changement majeur de cette version est la prise en charge de ROCm pour tirer parti de l’accélération matérielle de l’intelligence artificielle proposée par AMD. Il y a également une amélioration de performances pour ceux utilisant GenAI sur un CPU ou encore exécutant sur des processeurs AWS Graviton3 à base d’architecture Aarch64.

    L’API engine de la bibliothèque OpenSSL est dépréciée car non maintenue tout en gardant une ABI stable. En effet cette API n’est pas conforme aux standards FIPS et n’est plus maintenue depuis la version 3.0 d’OpenSSL. Aucun nouveau paquet ne peut dépendre de celui-ci jusqu’à sa suppression définitive pour simplifier la transition. Le code lié à cette API est fourni par le paquet indépendant openssl-engine-devel pour ceux qui en ont besoin. L’objectif à terme est de simplifier la maintenance tout en réduisant la surface d’attaque.

    Projet Fedora

    L’édition de Fedora KDE pour l’architecture AArch64 est maintenant bloquante pour les sorties d’une nouvelle version. L’édition doit être suffisamment stable pour qu’une nouvelle version de Fedora Linux voit le jour. Cela était déjà le cas pour Fedora Workstation de cette architecture et pour Fedora KDE pour l’architecture x86_64. L’objectif est de garantir une certaine fiabilité pour ses utilisateurs.

    Phase 4 de l’usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora. Cela devait être l’ultime phase mais quelques contretemps repoussent à nouveau l’échéance. Cette étape et la suivante sont en fait la conversion massive des paquets vers le nouveau format, comme rapporté par ce document, la progression reste rapide et près de 98,5% des licences mentionnées dans les paquets sont déjà converties.

    Les bibliothèques Java n’ont plus une dépendance explicite envers le runtime de Java pour simplifier la maintenance, rien ne change concernant les applications. L’objectif est d’éviter de spécifier une version spécifique de la version de Java pour du code qui finalement n’est pas exécuté directement, la dépendance revenant plutôt aux applications à ce sujet. Cela peut faciliter les utilisateurs ou mainteneurs d’utiliser différents JDK pour ces bibliothèques. Cela simplifie considérablement aussi la maintenance des paquets Java dans Fedora, car il n’est plus nécessaire de mettre à jour la valeur de la version du JRE requis.

    Le paquet systemtap-sdt-devel n’a plus l’outil dtrace qui a été mis dans le paquet systemtap-sdt-dtrace. L’objectif est de supprimer la dépendance Python dans ce paquet qui est utilisé pour l’image de compilation des paquets de Fedora. Plusieurs centaines de paquets peuvent ainsi être générés plus rapidement par cette dépendance en moins.

    Ajout d’une tâche de nettoyage lors de la génération des paquets RPM pour améliorer la reproductibilité des paquets. Depuis quelques années Fedora fait un effort pour rendre la conception de ses paquets reproductibles. L’objectif est qu’un utilisateur devrait être en mesure de recompiler un paquet de son côté avec le fichier spec RPM + sources additionnelles de Fedora et obtenir exactement le même paquet, au bit près, garantissant que le paquet a été généré avec ces éléments sans altérations malveillantes. Cela peut également faciliter le développement, car il rend la comparaison entre versions d’un paquet plus facile à analyser car seuls les changements dans le code sont différents et non des éléments annexes.

    Un effort a été fait récemment qui repose notamment sur l’usage du programme add-determinism pour retirer du code source des éléments non déterministes comme la date de compilation. Ce programme est appelé à la fin de la génération du paquet. Fedora n’a pas réutilisé le travail de Debian à base du script strip-nondeterminism qui est un script Perl qui ajouterait une dépendance relativement lourde pour générer tous les paquets de Fedora.

    Mise à jour de createrepo_c à la version 1.0 qui gère la génération des métadonnées des dépôts de Fedora. Les versions stables et Rawhide de Fedora vont partager maintenant la même configuration des métadonnées, ce qui rendra la maintenance côté infrastructure plus simple et cohérente. Toutes les métadonnées sont compressées, avant seulement les métadonnées primaires l’étaient pour les versions stables de Fedora par exemple. Certaines données ou métadonnées étaient compressées suivant différents algorithmes :

    • gzip pour les métadonnées des dépôts ;
    • XZ pour les données XML concernant les mises à jour dans les dépôts concernés.

    Maintenant tout cela utilise l’algorithme zstd ce qui devrait améliorer un peu la bande passante et la consommation d’espace de stockage. Il n’est pas exclu de basculer à l’avenir sur zlib-ng dans ce but.

    Les fichiers sqlite renseignant la composition des dépôts n’étaient utiles que pour le gestionnaire de paquets YUM, avec son remplacement par DNF depuis quelques années il est inutile de les générer ce qui avait un coût en espace de stockage.

    La communauté francophone

    L’association

    Logo de Boorsalinux-fr

    Borsalinux-fr est l’association qui gère la promotion de Fedora dans l’espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l’association.

    Nous lançons donc un appel à nous rejoindre afin de nous aider.

    L’association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l’ensemble des évènements majeurs concernant le libre à travers la France principalement.

    Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

    • adhérer à l’association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
    • participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l’association sur différents évènements francophones ;
    • concevoir des goodies ;
    • organiser des évènements type Rencontres Fedora dans votre ville.

    Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.

    Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuelles chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l’avons mis en place en visioconférence sur Jitsi.

    La documentation

    Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.

    Le moins que l’on puisse dire, c’est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
    Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège et les autres contributeurs et relecteurs pour leurs contributions.

    La synchronisation du travail se passe sur le forum.

    Si vous avez des idées d’articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n’hésitez pas à participer.

    Comment se procurer Fedora Linux 41 ?

    Logo de Fedora Media Writer

    Si vous avez déjà Fedora Linux 40 ou 39 sur votre machine, vous pouvez faire une mise à niveau vers Fedora Linux 41. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

    Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.

    Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

    De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 41.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Projets Libres ! Saison 3 épisode 3 : la fondation Eclipse

    Pour ce troisième épisode du podcast Projets Libres depuis la rentrée, nous recevons Gaël Blondelle pour parler de la fondation Eclipse.

    Logos Podcast Projets Libres et Fondation Eclipse

    Avec Gaël, qui est un des dirigeants exécutifs de la fondation et membre du board de l'Open Source Initiative (OSI), nous parlons des sujets suivants :

    • l'histoire et la création de la fondation
    • les raisons de son déménagement en Europe et sa forme juridique
    • à quoi sert une fondation ?
    • Eclipse et la souveraineté digitale européenne
    • les principaux projets hébergés par la fondation Eclipse
    • la collaboration avec les autres fondations dans le cadre du Cyber Resilience Act (CRA)
    • constituer un lobby européen de l'Open Source
    • le futur de la fondation

    Bonne écoute !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Des nouvelles de Unvanquished

    La dernière dépêche sur le jeu Unvanquished a été publiée ici en 2023, pour son dixième anniversaire. La dernière version annoncée ici était la version 0.53, en 2022. Alors que nous sommes à deux mois de 2025 et à quelques jours de la prochaine version 0.55, c’est l’occasion de faire un point sur ce qui s’est passé ces dernières années et d’ajouter un épisode à la série « des nouvelles de [votre jeu préféré] » et de faire suite à celui sur Xonotic.

    Unvanquished

    Laisse-moi sortir de là ! — réclame la version 0.55…

    Unvanquished est un jeu de stratégie en temps réel (RTS) à la première personne (FPS) où des extraterrestres évolutifs et des humains lourdement armés s’affrontent pour leur survie. Son développement, basé sur Tremulous, a commencé en 2011.

    Sommaire

    Quelques nouvelles en vrac

    Un nouveau lanceur

    En prévision de la prochaine version 0.55 qui arrive (deux « release candidates » ont déjà été publiées), le « lanceur » (aussi appelé « updater ») a été mis à jour en juillet dernier.

    Le lanceur est le moyen recommandé d’installer Unvanquished : il permet une intégration optimale avec le système (possibilité de cliquer sur des liens pour lancer une partie) et propose la mise à jour du jeu quand une nouvelle version est disponible. Le lanceur sait aussi se mettre à jour et c’est ce qui a été fait en juillet.

    Des améliorations graphiques

    L’année dernière le projet Unvanquished avait annoncé être en recherche d’un développeur spécialisé dans les moteurs de rendus. Reaper a rejoint l’équipe et a réalisé un gros travail : débugage et finalisation des miroirs récursifs et d’autres choses. Il fait aussi progresser le moteur pour tirer partie d’OpenGL 4.6 et autre techniques avancées (« bindless textures », etc.).

    Un explorateur de serveur minimaliste

    Viech a publié un explorateur de serveur de jeu minimaliste qui tient dans la barre de notification (tray browser). C’est à la fois simple et pratique.

    Des vidéos et un compte Mastodon

    Diverses vidéo montrant les avancées du développement ont été publiées sur la chaîne Youtube d’Unvanquished, c’est l’occasion de rappeler l’existence de cette chaîne : https://www.youtube.com/@UNVofficial

    Pour ceux qui préfèrent Peertube, qui permet aussi de s’abonner aux chaînes à travers Mastodon et plus globalement le Fédiverse, avec la publication de certaines parties : https://vdo.unvanquished.greboca.com/

    Un compte Mastodon a été créé sur l’instance idtech.space dédiée aux technologies id Tech et projets associés (le moteur d’Unvanquished dérive d’id Tech 3) : https://idtech.space/users/UNVofficial

    Ce compte Mastodon s’ajoute aux comptes X et Facebook. Le public libriste sera peut-être plus intéressé par ce compte Mastodon.

    Unvanquished, ARMé et dangereux

    De nouvelles architectures

    La version 0.54 de Unvanquished sortie en janvier 2023 avait été la première à être jouable autrement que sur PC (x86 et x86-64), en proposant des binaires pour les processeurs ARM (sous Linux seulement pour l’instant).

    Côté moteur la version 0.54 avait reçu de nombreuses optimisations pour mieux tourner sur des machines moins performances, par exemple, Certaines ressources logiciels optionnelles comme les deluxemaps ne sont plus chargées si désactivées, ceci économise non seulement le calcul, mais aussi la mémoire de la carte graphique. Les lightstyles peuvent être désactivés, ce qui peut accélérer le rendu graphique, etc. La compatibilité matérielle sera encore étendue avec la version 0.55.

    À partir de la version 0.54 tous les binaires pour toutes les architectures matérielles et systèmes d’exploitation sont compilés dans des containers Docker, y compris les binaires macOS compilés dans un container Linux en utilisant Darling, Darling étant à macOS ce que Wine est à Windows. La version 0.55 sera produite de la même manière.

    La version 0.55 apportera la compatibilité pour un nouveau système d’exploitation ! 🤫️

    Interface, jouabilité et bots

    Chargement de carte

    Le nouvel écran de chargement des cartes.

    L’interface avait été revue à l’occasion de la version 0.54 :

    • Nouvelles icônes d’inventaire contribuées par Nanaa, Gireen et Bob Vador
      Ces icônes donnent un coup de fraîcheur, on distingue mieux les deux types de grenades et les armures ainsi que le mode de déplacement.
    • L’écran de chargement des cartes affiche le nom de la carte et des auteurs (si renseigné) depuis les métadonnées. Historiquement, les artistes inscrivaient ces informations sur l’image d’illustration de la carte avec un logiciel de dessin… (!!!)
    • La version 0.55 apportera des modifications d’interface réalisées par Grise.

    Côté jouabilité, la version 0.54 avait corrigé le momentum négatif qui était particulièrement pénalisant. Le momentum, est généré par les Leech (Alien) ou les Drills (Humain). Il faut qu’il y ait assez de momentum pour pouvoir construire d’autres éléments.

    La version 0.54 a apporté toute une série de nouveautés au niveau des bots (entités qui remplacent les joueurs afin de compléter les équipes) :

    • Amélioration de l’évitement d’obstacles pour les bots.
    • Les bots peuvent viser des cibles situées sur des navmesh différents.
    • Certains bots n’hésiteront pas à sauter pour atteindre une cible en hauteur, d’autres se retiennent d’exécuter une attaque qui pourraient les blesser si la cible est trop proche…

    Depuis quelque temps, le développement des bots suscite un regain d’intérêt. La version 0.55 ne sera pas la plus riche à ce sujet car elle apportera surtout des améliorations du moteur. Le développement de gameplay ne s’est pas ralenti mais s’est surtout focalisé sur des mods dont il faudra fusionner les avancées dans le tronc commun après la sortie de la version 0.55. Ces améliorations de gameplay sont déjà jouables sur des serveurs en ligne.

    L’amélioration du comportement des bots à permis un nouveau type de jeu : Le PVE. C’est à dire que les joueurs peuvent jouer ensemble contre l’ennemi piloté par le serveur. Certaines cartes ont été créées spécifiquement pour ce type de jeu, et d’autres ont été adaptées à l’aide de layout qui étaient déjà utilisés pour créer des variantes de parties.

    La version 0.54.1 n’avait pas vraiment proposé de modifications des données, il s’agissait surtout de publier des correctifs de bugs gênant du moteur. La version 0.55 viendra avec une mise à jour des données et donc avec les corrections attendues. Par exemple un bug dans la chaîne logicielle de conversion d’images avait produit des artefacts dans certaines textures, ce sera corrigé dans la version 0.55.

    La danse des submodules

                _________________
               /                 \
              |         ✝         |  
              |                   |
              |      beloved      |
              |     submodule     |
              |                   |
              |    2017-12-30     |
              |     2023-04-11    |
              |                   |
              |       R.I.P.      |
              |                   |  🄵
      (,,)é   |                   |   ɘ̀(⹁⹁)  ɘ̀(⹁⹁)
    ////////////////////////////////////////////////
    

    Press F to Pay Respects!

    Tous ceux qui doivent traiter avec Git savent que les submodules sont très pratiques mais parfois bien ennuyeux. Un travail de fond réalisé sur les outils de production des données a permis la réintégration du dossier source unvanquished_src.dpkdir. Le générateur de code CBSE qui produit la plomberie pour la logique de jeu a été réintégré aussi. Cela rend plus facile de travailler sur des mods en évitant de devoir gérer plusieurs dépôts différents.

    Contributions

    Unvanquished recrute
    Voulez-vous en savoir plus ?

    Comme vous le voyez, ce cycle de développement a aussi vu de nouveaux contributeurs apporter leur concours au projet. Certaines de leurs améliorations ont déjà été publiées dans la version mineure 0.54.1, d’autres arriveront avec la version 0.55.

    Récement, le développeur Slipher qui est un des développeurs Unvanquished les plus prolifiques et les plus fidèles a étendu ses activités au moteur de rendu et a rejoint la petite élite de ceux qui savent comment le moteur fonctionne. Il a corrigé entre autre le rendu de vidéo sur des surfaces et une fonctionnalité de sprites.

    La liste de régressions depuis le désormais lointain ancêtre d’Unvanquished, Tremulous, est maintenant réduite à peau de chagrin.

    Des traductions !

    La grosse nouveauté de la version 0.54.1 publiée en décembre 2023 a été de proposer à nouveau des traductions intégrées au jeu. L’outil de traduction est gracieuseuement hébergé par Weblate.

    L’interface Weblate

    L’interface de traduction Weblate.

    Il y a longtemps, le jeu était traduit, mais suite à de très profonds changements (par exemple le remplacement total de la technologie utilisée pour faire des menus, désormais sous RmlUi), l’effort de traduction avait été interrompu.

    La traduction francophone est bien avancée, mais la traduction en breton a besoin de plus de contributions. Si vous souhaitez contribuer votre langue régionale, vous êtes les bienvenus, c’est ici que cela se passe !

    La 0.55 arrive !

    Préparez votre souris et votre clavier, la version 0.55 arrive très bientôt.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Le Lama déchaîné ou la nouvelle campagne de soutien financier de l'April

    2015 est la date de la dernière campagne d’adhésion de l’April. Neuf ans sans recrutement, il était temps de s’y remettre. Mais la formule change en cette année 2024 !

    Mais commençons par le début :

    L'April, c’est l’association qui promeut et défend le logiciel libre et les libertés informatiques. Au fur et à mesure des années, sa tâche s’est accrue, le nombre de dossiers à traiter, toujours plus urgents les uns que les autres, augmentant sans cesse. Et pourtant, depuis 2015, aucune campagne d’adhésions n’a été proposée…

    L’April en difficulté financière

    Depuis deux ans, notre situation financière n’étant plus à l’équilibre, il nous a paru opportun de relancer la machine en cette fin d’année. Pour finir sereinement l’année 2024, une somme de 20 000 € nous serait nécessaire.

    Le Lama déchaîné

    Pour cette nouvelle campagne, nous n’allons pas vous proposer un seul et unique texte, aussi encourageant soit-il, sur un site de campagne, mais neuf, un pour chacune de ces années sans sollicitation !

    Ce défi a été fièrement et, nous espérons, dignement relevé par notre équipe devenue, pour un temps, une rédaction de journalistes. Soyez à l’affût, car à partir d’aujourd’hui et durant neuf semaines, chaque mercredi, paraîtra un exemplaire de ce magazine automnal, Le Lama déchaîné. Diverses rubriques vous présenteront les différentes actions de l’association durant toutes ces années ! Mais pas que, puisque nous avons invité également des plumes extérieures à l’April afin de parler du Libre et que nous vous confions quelques anecdotes rigolotes. Sans oublier les mots croisés et le concours de dessins générés !
    Le Lama déchaîné

    À vous de décider, numéro après numéro, si notre initiative est suffisamment convaincante pour susciter de votre part une adhésion ou, à minima, si elle vous encourage à faire de temps en temps un don ponctuel pour nous soutenir. Nous avons fait le choix de l’indépendance vis-à-vis des institutions en n’ayant recours à aucune subvention et le rescrit d’intérêt fiscal nous a été refusé deux fois.

    Sans vos apports financiers, l’April ne pourrait pas agir aussi librement !

    Découvrez le numéro 0 du Lama déchaîné

    Numéro 0 car, en informatique, tout commence à 0.

    Lisez-le, dévorez-le d’un seul coup, dégustez-le lentement un ou deux articles par jour, parcourez-le rubrique après rubrique, n’hésitez pas à participer à l’un des numéros suivants en proposant un dessin et, surtout, parlez-en autour de vous et relayez le plus possible !

    Nous comptons sur chacun et chacune d’entre vous. Merci d’avance !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Minetest, l'autre pays du minage - « Libre à vous ! » du 10 septembre 2024 - Podcasts et références

    28 septembre 2024 à 02:49

    Deux-cent dix-septième émission « Libre à vous ! » de l’April. Podcast et programme :

    • sujet principal : « Minetest : l’autre pays du minage »

    • la chronique « Que libérer d’autre que du logiciel » avec Antanak, sur la pratique de double système d’exploitation

    • la chronique « Pépite libre » de Jean-Christophe Becquet, vice-président de l’April, sur le thème « L’Accueillette : un outil d’autodiagnostic de lieux d’accueil »

    Rendez‐vous en direct chaque mardi de 15h30 à 17h00 sur 93,1 FM en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

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

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

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

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

    Sommaire

    Documentation

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

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

    Documentation d’API

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

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

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

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

    Documentation interne

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

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

    Quelques nouvelles pages ajoutées cette année:

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

    Un point sur le financement

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

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

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

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

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

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

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

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

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

    Google Summer of Code

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

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

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

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

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

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

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

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

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

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

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

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

    Diego Roux — Pilote pour les cartes sons virtuelles VirtIO

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

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

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

    trungnt2910 — Portage de GDB

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

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

    Zardshard — Migration du navigateur web WebPositive vers WebKit2

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

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

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

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Haiku a 23 ans - Haiku R1 bêta 5 (partie 1 : applications)

    Haiku est un système d’exploitation libre destiné aux ordinateurs personnels ou de bureau (pas de serveurs, pas de systèmes embarqués, pas de tablettes ni de téléphones). Il s’agit au départ d’une réécriture libre de BeOS, préservant la compatibilité binaire avec ce dernier (les applications BeOS peuvent tourner sur certaines versions de Haiku).

    Le projet Haiku (au départ nommé OpenBeOS) a démarré officiellement le 18 août 2001 avec le premier message sur la liste de diffusion : Ok, let's start (OK, allons-y). Cet anniversaire est l’occasion de faire un point sur les développements de l’année dans Haiku et ce qui est en préparation.

    La dépêche a été un peu retardée cette année, pour être synchronisée avec la version R1 bêta 5 de Haiku, publiée le vendredi 13 septembre 2024.

    Le projet emploie un développeur presque à plein temps depuis 2021 et le reste de l’équipe contribue bénévolement. La dernière version bêta a été publiée fin 2023 et la Bêta 5 est désormais disponible : l’occasion de revenir en trois parties sur ce que propose Haiku, d’abord des applications, un noyau et des améliorations de la documentation.

    Sommaire

    Près de 350 tickets ont été clos dans le cadre du travail sur la version R1 bêta 5. Il y a bien sûr de très nombreuses corrections de bugs, qui ne seront pas listées dans cet article. On se concentrera plutôt sur les nouveautés, sauf dans les cas où la correction est vraiment importante ou permet d’ouvrir de nouvelles possibilités d’utilisation.

    Applications

    Haiku est un système d’exploitation complet, fourni avec un certain nombre d’applications permettant d’accomplir les tâches les plus courantes. En plus de ces applications de base, le gestionnaire de paquets HaikuDepot, alimenté principalement par le travail du projet HaikuPorts, apporte à la fois des applications portées depuis d’autres systèmes et des applications développées spécifiquement pour Haiku.

    De façon générale, on trouve cette année dans les applications de Haiku des améliorations sur le rendu des nombres, l’utilisation d’un symbole de multiplication à la place d’une lettre x là où c’est pertinent, et de nombreuses petites corrections et améliorations sur la mise en page des fenêtres, des corrections de problèmes de traduction et ainsi de suite.

    AboutSystem

    AboutSystem est la fenêtre d’information sur le système Haiku. Elle fournit quelques informations sur la machine sur laquelle le système fonctionne (quantité de RAM, marque et modèle du CPU, uptime) ainsi que les noms des développeurs et autres logiciels libres ayant participé au développement de Haiku.

    Cette application reçoit tout d’abord une mise à jour cosmétique : si le système est configuré en « mode sombre », le logo Haiku correspondant (avec un lettrage blanc et des dégradés de couleurs un peu différents) sera utilisé. Sinon, ce sera le logo avec lettrage noir.

    AboutSystem en mode clair
    AboutSystem en mode sombre

    Elle reçoit également quelques mises à jour de contenu : en plus de l’ajout de quelques nouveaux contributeurs qui ont rejoint le projet, on trouvera maintenant un lien vers la page web permettant de faire un don à Haiku. Plusieurs liens vers des bibliothèques tierces utilisées dans Haiku, qui ne fonctionnaient plus, ont été soit supprimés, soit remplacés par des liens mis à jour.

    Enfin, il est désormais possible d’utiliser AboutSystem comme un « réplicant », c’est-à-dire de l’installer directement sur le bureau pour avoir en permanence sous les yeux les statistiques sur l’utilisation mémoire et l’uptime ainsi que le numéro de build de Haiku en cours d’exécution (ce qui peut être utile par exemple lorsqu’on lance beaucoup de machines virtuelles avec des versions différentes de Haiku pour comparer un comportement, ou si on veut stocker des captures d’écran de plusieurs versions et s’y retrouver facilement).

    CharacterMap

    L’application « table de caractères » permet d’étudier de près les différents glyphes et symboles présents dans une police de caractères. En principe, elle permet de choisir une police spécifique, mais le serveur graphique de Haiku substitue automatiquement une autre police si on lui demande d’afficher un caractère qui n’est pas disponible dans la police demandée.

    Cela peut être gênant dans certains contextes, par exemple si on envisage d’embarquer une police dans un fichier PDF, il est difficile de savoir quelle police contient vraiment les caractères qu’on veut utiliser.

    L’application a été améliorée pour traiter ce cas et affiche maintenant ces caractères en grisé.

    CharacterMap affichant des caractères manquants

    CodyCam

    CodyCam est une application permettant de tester une webcam et de l’utiliser pour envoyer périodiquement des images vers un serveur HTTP.

    L’évolution principale a été la mise à jour de l’icône de l’application. L’utilité de CodyCam est limitée par le manque de pilotes : il faudra soit trouver une webcam Sonix du début des années 90, seul modèle USB à disposer d’un pilote fonctionnel, soit utiliser un ordiphone Android équipé d’un logiciel permettant de le transformer en caméra IP (ou encore une vraie caméra IP).

    Le pilote pour les WebCams UVC — standard utilisé pour les caméras USB modernes — n’est pas encore au point et n’est pas inclus dans les versions publiées de Haiku.

    Debugger

    Debugger est, comme son nom l’indique, le debugger de Haiku. Il est développé spécifiquement pour le projet sans s’appuyer sur les outils existants (gdb ou lldb). Il dispose à la fois d’une interface graphique et d’une interface en ligne de commande, plus limitée. Cette dernière est surtout utilisée pour investiguer des problèmes dans les composants de Haiku qui sont nécessaires pour l’utilisation d’une application graphique : app_server, input_server ou encore registrar.

    La version en ligne de commande a reçu quelques petites améliorations, mais la principale nouveauté est la prise en charge des formats DWARF-4 et DWARF-5 pour les informations de debug. Cela permet de charger les informations générées par les versions modernes de GCC, sans avoir besoin de forcer la génération d’une version plus ancienne du format DWARF.

    Le désassembleur udis86, qui n’est plus maintenu et ne reconnaît pas certaines instructions ajoutées récemment dans les processeurs x86, a été remplacé par Zydis.

    Enfin, un bug assez gênant a été corrigé : si une instance de Debugger était déjà en train de débugger une application et qu’une deuxième application venait à planter, il n’était pas possible d’attacher une deuxième instance de Debugger à cette application. Les problèmes impliquant plusieurs processus pouvaient donc être un peu compliqués à investiguer. C’est maintenant résolu.

    Deskbar

    L’application DeskBar fournit la « barre des tâches » de Haiku. Elle permet de naviguer entre les fenêtres et applications ouvertes, de lancer de nouvelles applications via un menu (similaire au « menu démarrer » de Windows), ou encore d’afficher une horloge et des icônes fournis par d’autres applications (sous forme de réplicants).

    Elle fait partie, avec le Tracker, des applications qui ont été publiées sous license libre lors de l’abandon de BeOS par Be Inc.

    Quelques changements dans la DeskBar :

    • Tous les menus utilisent maintenant la police « menu » choisie dans les préférences d’apparence du système. Auparavant, la police « menu » et la police « plain » étaient mélangées. Ces deux polices étant identiques dans la configuration par défaut, le problème n’avait pas été repéré.
    • Si un nom de fenêtre est tronqué dans la liste des fenêtres, le nom complet peut être affiché dans une infobulle.
    • L’icône pour les fenêtres dans la DeskBar a été remplacée. La nouvelle icône indique plus clairement si une fenêtre se trouve dans un autre bureau virtuel (dans ce cas, activer cette fenêtre provoquera un changement de bureau).

    GLTeapot

    GLTeapot est une application permettant de tester le rendu OpenGL, en affichant un modèle 3D de la théière de l’Utah.

    En plus de la théière, cette application affiche un compteur du nombre d’images affichées par secondes. Bien que les chiffres affichés ne soient pas du tout représentatifs des performances d’un rendu 3D réaliste, certains utilisateurs insistent lourdement pour pouvoir faire le concours de gros chiffres de nombre d’images par seconde.

    Il est donc à nouveau possible de désactiver la synchronisation sur le rafraîchissement de l’écran, et demander au processeur de réafficher la théière plusieurs centaines de fois par seconde, bien que l’écran soit incapable de suivre le rythme. Par défaut, la synchronisation est activée et le rafraîchissement ne dépassera jamais 60 FPS, si toutefois le pilote graphique implémente les fonctions de synchronisation nécessaires.

    HaikuDepot

    HaikuDepot est un hybride entre un gestionnaire de paquets et un magasin d’applications.

    Il se compose d’un serveur (développé en Java) fournissant une API REST et permettant de collecter les informations sur les applications (icônes, captures d’écrans, catégories, votes et revues des utilisateurs, choix de la rédaction pour les applications mises en avant…), d’un frontend web minimaliste et d’une application native C++ permettant d’afficher ces données.

    La principale nouveauté est l’intégration du système de single-sign-on (SSO) permettant d’utiliser un compte utilisateur commun avec d’autres services en ligne de Haiku. Actuellement, l’outil de revue de code Gerrit
    utilise ce même compte, mais ce n’est pas encore le cas pour Trac (outil de suivi des bugs) ni pour le forum. Ce sera mis en place plus tard.

    De façon peut-être moins visible, mais pas moins importante, le code C++ de l’application a reçu de nombreuses améliorations et optimisations « sous le capot », rendant l’application plus rapide et plus fiable, mais qui sont un peu difficiles à résumer dans le cadre de cette dépêche.

    Enfin, l’apparence de l’application a été légèrement retravaillée pour mieux s’adapter aux écrans à haute définition (ce qui nécessite d’avoir des marges et espacements de taille dynamique en fonction de la taille de texte choisie par l’utilisateur).

    Icon-O-Matic

    Capture d’écran de l’éditeur d’icônes

    Icon-O-Matic est un éditeur d’icônes. Il permet d’exporter les fichiers au format HVIF, un format vectoriel compact qui permet de stocker les icônes dans l’inode d’en-tête des fichiers pour un chargement et un affichage rapide.

    Cette application a bénéficié du travail de Zardshard pendant le Google Summer of Code 2023, elle a donc reçu plusieurs évolutions et corrections importantes (dont certaines sont mentionnées dans la dépêche anniversaire de l’année dernière).

    Citons en particulier l’ajout d’un nouveau type de transformation, « perspective », qui permet de facilement déformer un ensemble de chemins vectoriels selon une projection de perspective, ce qui est assez utile pour concevoir plus facilement une icône avec un aspect tridimensionnel (bien qu’en pratique l’apparence habituelle des icônes de Haiku soit un intermédiaire entre une projection perspective et une vue isométrique, ne se prêtant pas forcément à l’utilisation de cette opération de transformation purement mathématique).

    Une autre petite amélioration est l’ajout d’une vérification pour empêcher la fenêtre de Icon-O-Matic de se positionner en dehors de l’écran, par exemple si on a déplacé la fenêtre vers le bas de l’écran, enregistré cette position, puis relancé l’application dans une résolution d’écran plus réduite. Dans ce cas, la fenêtre sera automatiquement ramenée dans la zone visible de l’affichage.

    Magnify

    L’application Magnify permet d’afficher une vue zoomée d’une partie de l’écran. Elle peut servir pour améliorer l’accessibilité (mais n’est pas idéale pour cet usage), mais aussi pour les développeurs d’interfaces graphiques qui ont parfois besoin de compter les pixels pour s’assurer que leurs fenêtres sont bien construites.

    En plus de l’affichage zoomé, l’application permet d’afficher l’encodage RGB de la couleur d’un pixel, ou encore de placer des « règles » permettant de vérifier l’alignement des objets. Ces dernières ont reçu une petite mise à jour, avec une amélioration de l’affichage de leur largeur et hauteur pour les rendre plus lisibles.

    Magnify avec une 'règle'

    MediaPlayer

    L’affichage des sous-titres ne fonctionnait pas correctement, il manquait une partie du texte. C’est maintenant corrigé.

    PowerStatus

    Capture d’écran de PowerStatus: fenêtre principale et icône de la DeskBar avec son menu

    L’application PowerStatus permet de surveiller l’état de la batterie pour les ordinateurs qui en disposent.

    Elle a reçu plusieurs améliorations importantes :

    Une notification a été ajoutée pour un niveau de décharge très faible (en plus du niveau faible déjà présent). Ces deux niveaux peuvent être paramétrés à un pourcentage choisi de décharge de la batterie, et associé à des sons d’alerte spécifiques. Avant ces changements, il était facile de ne pas voir le message d’alerte (affiché seulement pendant quelques secondes) ou de se dire qu’avec 15% de batterie on a encore le temps de faire plein de trucs, puis se retrouver un peu plus tard avec une batterie vide sans autre avertissement.

    L’état « not charging » est maintenant détecté et correctement affiché, pour une batterie au repos : ni en train de se charger, ni en train d’alimenter la machine. C’est en particulier le cas d’une batterie déjà chargée à 100%, si la machine reste connectée au réseau électrique.

    L’icône de statut de la batterie s’installe automatiquement dans la DeskBar au premier démarrage de Haiku sur les machines disposant d’une batterie.

    Le réglage du mode « performance » ou « économie d’énergie" est enregistré et ré-appliqué lors des prochains démarrages (ces modes configurent l’ordonnanceur du noyau pour exécuter un maximum de tâches sur tous les cœurs du processeur, ou bien au contraire pour essayer de garder ces cœurs en veille autant que possible s’ils ne sont pas nécessaires).

    SerialConnect

    SerialConnect est une application de terminal série, utile principalement aux développeurs de systèmes embarqués et autres gadgets électroniques.

    Elle est encore en cours de développement et propose pour l’instant les fonctions les plus basiques. Il est maintenant possible de coller du texte depuis le presse-papier pour l’envoyer sur un port série, ce qui est pratique si on veut envoyer plusieurs fois la même séquence de commandes.

    ShowImage

    ShowImage est la visionneuse d’images de Haiku. Elle utilise les traducteurs, des greffons avec une API standardisée qui permettent de convertir différents formats de fichiers entre eux.

    L’interface graphique de ShowImage a été mise à jour pour utiliser le « layout system ». Historiquement, dans BeOS, tous les éléments des interfaces graphiques devaient être positionnés manuellement avec des coordonnées en pixels, ce qui est pénible à faire, surtout si on doit traiter tous les cas (polices de caractères de différentes tailles, remplacement des textes lors de traductions, utilisation de thème d’interfaces différents), et aussi lors d’évolution de l’application (si on veut insérer un élément en plein milieu, il faut souvent décaler tout ce qui se trouve autour).

    Le « layout system » fournit un ensemble d’outils pour automatiser ce travail, soit à l’aide d’éléments prédéfinis (grilles, groupes, « cartes » superposées), soit à l’aide d’un système de définition de contraintes et de programmation linéaire.

    D’autre part, ShowImage dispose maintenant d’un menu permettant d’ouvrir l’image affichée dans un éditeur d’images.

    Terminal

    Le Terminal de Haiku permet d’exécuter un shell (c’est bash par défaut) et toutes les applications conçues pour un affichage en console.

    Les principaux changements cette année sont la correction d’un problème sur la configuration des couleurs utilisées par le Terminal (il y avait un mélange entre le nom anglais et le nom traduit des couleurs, empêchant d’enregistrer et de relire correctement le fichier de configuration), ainsi que des modifications sur les raccourcis clavier utilisés par le Terminal lui-même (en particulier pour naviguer entre plusieurs onglets) qui entraient en conflit avec ceux utilisés par les applications lancées dans le terminal.

    Le terminal est également capable de traiter les « bracketed paste », c’est-à-dire que les applications en console sont informées que des caractères en entrée proviennent du presse-papier. Cela permet par exemple à bash de ne pas exécuter directement des commandes qui sont collées, mais de les mettre en surbrillance et d’attendre que l’utilisateur valide cette saisie.

    D’un point de vue plus bas niveau, les pilotes TTY utilisés pour les ports série et pour le Terminal, qui étaient indépendants, ont été unifiés afin d’éviter de devoir corriger tous les bugs deux fois dans deux versions du code presque identiques.

    Tracker

    Tracker est le navigateur de fichiers de Haiku. Tout comme la DeskBar, il fait partie des quelques rares morceaux de BeOS qui ont été publiés sous licence libre par Be et ont donc pu être repris directement par Haiku. Contrairement à la DeskBar, la publication du code du Tracker avait conduit à l’apparition de nombreux forks, chacun améliorant à sa façon le logiciel. La version utilisée par Haiku provient principalement du projet OpenTracker, mais a réintégré ou réimplémenté au fil du temps les modifications faites dans d’autres variantes.

    Le Tracker est un composant central de l’interface de Haiku et a donc reçu un nombre assez important d’évolutions :

    La taille des fichiers est maintenant affichée à l’aide de la fonction string_for_size qui s’adapte aux conventions de la langue et du pays choisi par l’utilisateur.

    Les brouillons de courrier électronique disposent maintenant de leur propre type MIME et de l’icône associée. Ils s’ouvriront dans un éditeur de mail plutôt que dans une fenêtre de lecture de message.

    Pour les fichiers qui disposent d’un attribut « rating » (évaluation), ce dernier est affiché avec des étoiles pleines ou vides selon la note attribuée. La note va de 0 à 10 mais il n’y a que 5 étoiles. Le caractère demi-étoile permet d’afficher la note exacte avec les versions récentes d’Unicode (depuis 2018 en fait, mais il a fallu attendre la disponibilité dans une police de caractères).

    Une fenêtre du Tracker, montrant la colonne taille et la colonne rating

    La gestion des dossiers en lecture seule a été améliorée. Ils sont affichés sur fond gris (au lieu d’un fond blanc pour les dossiers modifiables) et tous les menus correspondant à des opérations non autorisées sont désactivés (au lieu d’être activés, mais d’aboutir sur une erreur car le dossier est en lecture seule).

    Dans le même esprit, le bouton « ouvrir » des boîtes de dialogues d’ouverture de fichier est désactivé si le fichier sélectionné ne peut pas être ouvert (c’était déjà le cas, mais tous les cas possibles n’étaient pas bien pris en compte).

    Un problème d’affichage sur le système de fichier packagefs a été corrigé : les dossiers n’ont pas de taille et affichent donc - au lieu d’une taille fixe de 4 Kio qui n’a aucune signification.

    La fenêtre de recherche a reçu quelques évolutions, voir plus bas dans la section dédiée au Google Summer of Code, qui détaille le travail réalisé à ce sujet.

    Le menu « templates », utilisé quand on fait un 'clic droit -> Nouveau…' et qui permet de créer différents types de fichiers et de dossiers à partir de fichiers de référence, peut maintenant contenir des sous-dossiers, pour les personnes qui utilisent beaucoup cette possibilité, avec par exemple des modèles de documents pré-remplis pour différents usages.

    Enfin, un peu de nettoyage interne : les classes NavMenu et SlowContextPopup, qui permettent la navigation dans les sous-dossiers via des menus popup, ont été fusionnées en une seule classe car elles sont toujours utilisées ensemble. Cela simplifie le code pour l’affichage de ces menus, qui a quelques particularités pour permettre une navigation confortable même sur un disque dur un peu lent.

    TV

    L’application TV utilisée pour recevoir la TNT à l’aide d’un tuner approprié a été déplacée dans le paquet haiku_extras et n’est donc plus installée par défaut. La plupart des gens ne disposant pas d’un tuner compatible sur leur ordinateur, cette application était source de confusion et de nombreuses questions sur le forum.

    WebPositive

    WebPositive est le navigateur web de Haiku. Il utilise le moteur WebKit développé conjointement par Apple, Igalia et Sony principalement.

    En dehors de la mise à jour du moteur vers une version plus récente, WebPositive reçoit actuellement peu d’évolutions, les développeurs étant malheureusement trop occupés par ailleurs. On peut toutefois mentionner une correction sur la barre de signets : celle-ci ne s’affichait jamais lorsque la langue du système était autre chose que l’anglais.

    Zip-O-Matic

    Zip-O-Matic est un outil permettant de créer une archive zip facilement depuis le Tracker. Il a reçu une amélioration qui est en fait une correction d’un problème qui existait depuis longtemps : l’archive créée est maintenant automatiquement sélectionnée dans le navigateur de fichier à la fin du processus, ce qui permet de facilement la retrouver pour la renommer, la déplacer ou l'envoyer à son destinataire.

    Haikuports

    Haikuports est un projet indépendant de Haiku, il se charge d’alimenter le dépôt de paquets. Au départ il s’agissait principalement d’un projet pour le portage de bibliothèque et de programmes venant d’autres systèmes (d’où son nom), mais il est également utilisé pour la plupart des applications natives développées pour Haiku.

    Le dépôt de paquets contient actuellement 4193 paquets, il est mis à jour en continu par une petite équipe de bénévoles qui ne sont pas forcément tous développeurs, mais tout de même capables de faire les tâches de maintenance ainsi que le développement de quelques patchs simples.

    Il est impossible de lister toutes les mises à jour et ajouts, le projet HaikuPorts étant très actif. Donc voici une sélection arbitraire de quelques nouveautés et mises à jour.

    Applications natives

    • Mises à jour de Renga (client XMPP), PonpokoDiff (outil de diff), 2pow (clone de 2048), StreamRadio (lecteur de podcasts), NetSurf (navigateur web léger)…
    • Genio, un IDE pour Haiku avec gestion de la complétion de code via le protocole LSP (compatible avec les outils développés pour VS Code par exemple).
    • Ajout de HaikuUtils, un ensemble d’outils de développement et de debug divers.
    • WorkspaceNumber, un replicant pour afficher le numéro du bureau actif dans la DeskBar.
    • KeyCursor, un outil pour contrôler le curseur de souris à l’aide du clavier.
    • BatchRename, un outil pour renommer automatiquement des fichiers par lot.

    HaikuUtils

    WorkspaceNumber

    PonpokoDiff

    PecoRename

    2pow

    BatchRename

    Applications portées

    • Un gros travail a été fait sur le portage de KDE Frameworks et des applications l’utilisant. De très nombreuses applications Qt et KDE sont donc disponibles.
    • Du côté de GTK, il n’existait pas de version de GTK pour Haiku, le problème a été résolu à l’aide d’une couche de compatibilité avec Wayland qui n’implémente pas le protocole Wayland mais réimplémente l’API de la libwayland. Les applications GTK arrivent petit à petit, mais l’intégration est pour l’instant beaucoup moins bonne qu’avec Qt, qui dispose lui d’un vrai port utilisant les APIs natives directement. L’apparence des applications est très visiblement différente, certaines touches du clavier ne fonctionnent pas. C’est donc encore un peu expérimental.
    • Enfin, pour compléter les possibilités d’outils graphiques, la bibliothèque Xlibe implémente les APIs de la libx11 (mais pas le protocole de communication de X) et permet de porter les applications FLTK par exemple, ainsi que celles utilisant directement la libx11. Il reste encore des problèmes avec les applications utilisant Tk (si vous connaissez Tk ou X, les développeurs de Xlibe aimeraient bien un petit coup de main). En attendant, les applications Tk sont utilisables à travers un portage de undroidwish, mais ça reste peu confortable.

    Du côté des compilateurs et des langages de programmation : LLVM a été mis à jour en version 17. GCC est disponible en version 13 et peut maintenant être utilisé pour compiler du FORTRAN et de l’Objective-C. Les dernières versions de Python sont disponibles, et en plus avec des performances améliorées. Node.JS est également mis à jour, ou si vous préférez le langage R, vous le trouverez également, avec son IDE associé rkward.

    Bien sûr, la plupart des bibliothèques et outils disponibles sur d’autres systèmes sont aussi disponibles : ffmpeg (en version 6), Git, libreoffice, Wireshark…

    Mentionnons enfin un pilote FUSE pour monter des volumes réseau NFS, qui vient compléter les deux implémentations de NFS présentes dans le noyau (une obsolète qui implémente NFS2, et une plus récente implémentant NFS4, mais qui est instable et pas activement maintenue actuellement).

    GCompris

    DrawTerm

    KDE Mah Jong

    NetBeans

    Frogatto

    CudaText

    Cantor

    Panneaux de préférences

    Appearance

    Les préférences « Appearance » permettent de configurer l’apparence du système et des applications : principalement les polices de caractères et les choix de couleurs.

    C’est ce dernier qui reçoit une mise à jour en profondeur, avec l’ajout d’un mode automatique. Auparavant, chaque couleur utilisée par le système devait être configurée manuellement, ce qui permet un contrôle très fin, mais demande de passer un certain temps à faire des ajustements. Le mode automatique permet de configurer seulement 3 couleurs : le fond des fenêtres, les barres de titres, et une couleur d’« accentuation ». Les autres couleurs et nuances sont calculées automatiquement à partir de cette palette de base.

    En particulier, il devient beaucoup plus facile de choisir un fond sombre pour se retrouver avec un système en mode sombre, très à la mode chez certain·e·s utilisateurices de Haiku.

    Il est toujours possible d’activer le mode avancé pour affiner les réglages si nécessaire (ou si vous aimez les interfaces graphiques bariolées et multicolores).

    Le mode automatique dans l’application Appearance

    La même capture d’écran avec une configuration « mode sombre »

    Keymap (disposition clavier)

    L’application Keymap permet de configurer la disposition de touches du clavier. Le point qui a reçu un peu d’attention est la gestion de la configuration des touches modificatrices.

    Haiku est un dérivé de BeOS qui lui-même a été au départ inspiré de Mac OS. On conserve de cet héritage l’utilisation des touches commande et option au lieu de meta et alt sur les claviers de PC. Mais BeOS et Haiku sont conçus pour être utilisés avec des claviers de PC. La touche commande qui prend la place de la touche ALT est donc celle utilisée pour la plupart des raccourcis claviers. Cela se complique si on essaie d’utiliser un clavier fabriqué par Apple (les codes de touches renvoyés par le clavier pour des touches situées au même endroit ne sont pas les mêmes), ou encore si on a besoin d’une touche AltGr (historiquement utilisée comme touche option par BeOS, mais aujourd’hui ce rôle est plutôt attribué à la touche windows apparue un peu plus tard). Une page sur le wiki de développement de Haiku tente de résumer l’historique et la situation actuelle.

    La configuration des touches modificatrices est donc un sujet complexe, et il est probable que le comportement sera à nouveau modifié plus tard. Quoi qu’il en soit, en attendant, l’application Keymap permet toutes les permutations possibles de configuration de ces touches.

    Screen (Affichage)

    Les préférences d’affichage, en plus de permettre de changer la résolution d’écran, affichent quelques informations essentielles sur la carte graphique et l’écran en cours d’utilisation. Pour les écrans, ces informations sont généralement extraites des données EDID, mais il y a une exception : les dalles d’affichage des PC portables n’implémentent en général pas ce protocole. Les informations sont donc récupérées par d’autres moyens parfois moins bien normalisés. Par exemple, l’identifiant du fabricant est un code à 3 lettres. En principe, les fabricants doivent s’enregistrer auprès d’un organisme qui attribue ces codes, afin d’en garantir l’unicité.

    Cependant, certains fabricants ne l’ont pas fait, et se sont choisi eux-mêmes un code qui semblait inutilisé. La base de données officielle réserve donc ces codes et en interdit l’utilisation, afin d’éviter des conflits. Il arrivait donc que le fabriquant d’un écran soit affiché comme étant « DO NOT USE », ce qui a inquiété quelques utilisateurs de Haiku se demandant s’ils risquaient d’endommager leur matériel.

    Ces entrées de la liste sont maintenant filtrées et remplacées par les noms des fabricants de panneaux d’affichages concernés (lorsqu’on sait de qui il s’agit).

    Outils en ligne de commande

    Haiku est fourni avec un terminal et un shell bash (par défaut, d’autres shells peuvent également être utilisés). Les outils définis dans la spécification POSIX sont fournis, ainsi que des compléments permettant d’utiliser les fonctionnalités supplémentaires de Haiku.

    df

    La commande df affiche l’espace disque disponible sur chaque volume de stockage actuellement monté.

    Les colonnes de l’affichage ont été réorganisées, pour être plus lisibles, et se rapprocher un peu du format spécifié par POSIX (mais pas complètement lorsqu’on lance la commande sans options particulières : des informations supplémentaires sont alors affichées).

    filteredquery

    L’outil filteredquery permet d’effectuer une requête sur les attributs étendus du système de fichiers (permettant de requêter le système de fichiers comme une base de données, plutôt que de naviguer de façon hiérarchique dans les dossiers), puis de filtrer le résultat pour ne conserver que les réponses contenues dans un sous-dossier spécifique. En effet, les requêtes étant indépendantes de l’organisation des dossiers, il est nécessaire de faire ce filtrage par post-traitement des résultats (ce qui reste tout de même généralement plus rapide que de faire l’inverse : parcourir tous les fichiers d’un dossier pour trouver ceux correspondant à un critère particulier).

    Cet outil n’a pas reçu de nouvelles fonctionnalités, mais de nombreuses corrections et nettoyages qui le rendent véritablement utilisable.

    ping, traceroute, telnet, ftpd

    Ces commandes liées à des opérations sur le réseau ont été remplacées par les dernières versions développées par FreeBSD, permettant de bénéficier d’une version moderne, avec plus de fonctionnalités et moins de bugs.

    La commande ping6 est supprimée, car ping peut maintenant utiliser l’IPv6 aussi bien que l’IPv4.

    pkgman

    L’outil pkgman permet de télécharger et d’installer des logiciels et des mises à jour.

    Il a peu évolué, mais on peut tout de même noter l’utilisation d’un algorithme de tri « naturel » pour l’affichage des résultats dans l’ordre alphabétique (par exemple, llvm12 sera affiché après llvm9).

    Une fonction qui n’est toujours pas disponible dans pkgman est le nettoyage des dépendances non utilisées. Un script fourni dans le dépôt Git de Haiku permet de réaliser manuellement une analyse des paquets installés sur le système pour détecter ceux qui n’ont pas de dépendances, il faudra pour l’instant se contenter de cette solution.

    strace

    L’outil strace permet d’afficher les appels systèmes effectués par une application, pour comprendre son interfaçage avec le noyau et investiguer certains problèmes de performances ou de mauvais comportements.

    L’interfaçage avec le noyau pour extraire ces informations étant assez spécifique, l’implémentation de strace est faite à partir de zéro, et ne partage pas de code avec la commande du même nom disponible par exemple sous Linux.

    strace est mis à jour régulièrement et en fonction des besoins des développeurs de Haiku pour décoder et afficher de plus en plus d’informations. Par exemple, elle peut maintenant afficher le contenu des iovec (par exemple pour les fonctions readv ou writev), ainsi que les objets manipulés par wait_for_object et event_queue.

    Un exemple de sortie de strace (traçant l’ouverture d’un fichier et le chargement d’une bibliothèque partagée) avant ces changements:

    open(0x5, "plaintext", 0x2042, 0x0) = 0x8000000f () (49 us)
    map_file("libicuuc.so.66 mmap area", 0x7f04c2675228, 0x6, 0x1ababd0, 0x1, 0x0, true, 0x3, 0x0) = 0x329a0 () (108 us)
    

    et après :

    open(0x5, "plaintext", O_RDWR|O_NOTRAVERSE|O_CLOEXEC, 0x0) = 0x8000000f Operation not allowed (57 us)
    map_file("libicuuc.so.66 mmap area", [0x0], B_RANDOMIZED_ANY_ADDRESS, 0x1ababd0, B_READ_AREA, 0x0, true, 0x3, 0x0) = 0x73e8 ([0x6392223000]) (135 us)
    

    whence

    La commande whence permettait de trouver dans le PATH un exécutable à partir de son nom. Elle était implémentée sous forme d’une fonction bash dans le fichier profile par défaut. Cependant, cette implémentation posait problème pour charger le fichier profile avec d’autres shells, elle a donc été supprimée. La commande which peut être utilisée à la place, puisqu’elle remplit un rôle équivalent.

    Serveurs

    Les serveurs sont l’équivalent des daemons pour UNIX ou des services sous Windows : il s’agit d’applications lancées par le système pour rendre différents services et coordonner l’ensemble des applications.

    app_server

    app_server est le serveur graphique de Haiku, équivalent de X ou de Wayland. Il se distingue par un rendu graphique fait principalement côté serveur (pour les applications natives), ce qui permet de l’utiliser de façon fluide à travers une connexion réseau.

    Bien que ce soit le serveur graphique, et qu’il ait reçu plusieurs améliorations importantes, les différences sont subtiles. Elles sont toutefois importantes pour proposer un système qui semble réactif et confortable à utiliser.

    Un premier changement est une réarchitecture du code qui traite le rafraîchissement de l’écran. Ce rafraîchissement se fait en général en plusieurs étapes, par exemple, si on déplace une fenêtre :

    • Le contenu de la fenêtre déplacée peut être directement recopié de l’ancienne position vers la nouvelle,
    • La zone où se trouvait la fenêtre auparavant doit être re-remplie avec ce qui se trouvait en dessous de la fenêtre déplacée. Cela peut être plusieurs morceaux de fenêtres d’autres applications, qui vont devoir chacune ré-afficher une partie de cette zone.

    Le problème étant que certaines applications peuvent mettre un peu de temps à répondre à cette demande de ré-affichage (par exemple parce qu’elles sont occupées ailleurs, ou alors parce que la zone à redessiner est relativement complexe).

    Différentes stratégies peuvent être mises en place dans ce cas : laisser à l’écran le contenu obsolète, ou remplir la zone en blanc en attendant que les données deviennent disponibles, par exemple. Ou encore, tout simplement ne rien mettre à jour du tout tant que tout l’écran n’est pas prêt à être affiché. Il faut faire un compromis entre la réactivité (déplacer la fenêtre tout de suite), la fluidité (éviter les clignotements de zones blanches) et la précision (affichage d’information cohérente et à jour).

    Plusieurs modifications ont permis d’obtenir un meilleur compromis.

    Dans un autre domaine, la police de caractères par défaut « Noto Sans Display » a été remplacée par « Noto Sans », ce qui donne un affichage du texte légèrement différent. La police « display » avait été choisie suite à une mauvaise compréhension de la signification de ce mot en typographie : il signifie que c’est une police de caractères à utiliser pour des gros titres et autres textes courts. Il ne signifie pas que c’est une police à utiliser sur un écran d’ordinateur. De toutes façons la police Noto Display n’est plus maintenue par Google et a disparu des dernières versions du jeu de polices Noto.

    Toujours dans le domaine des polices de caractères, app_server sait maintenant charger les fichiers « variable fonts ». Ces fichiers contiennent plusieurs polices de caractères définies à partir de glyphes de base, et d’algorithmes de transformation et de déformation (pour rendre une police plus ou moins grasse, plus ou moins italique…). Pour l’instant, app_server sait charger les valeurs de ces paramètres qui sont préconfigurées dans le fichier. Cela permet de réduire la place utilisée par les polices de caractères sur le media d’installation de Haiku (c’est l’un des plus gros consommateurs d’espace disque, qui nous empêche de faire tenir une version complète de Haiku sur un CD de démonstration par exemple).

    Plus tard, il sera également possible de configurer plus finement ces paramètres pour générer des variantes intermédiaires des polices de caractères, ainsi que d’exploiter certaines polices qui offrent des paramètres configurables supplémentaires.

    input_server

    L’input_server se charge de lire les données venant des périphériques d’entrée (clavier et souris) et de les convertir en évènements distribués aux applications. Il est extensible par des add-ons qui peuvent générer ou filtrer des évènements, ce qui peut être utilisé pour de l’accessibilité (émuler une souris à partir de touches du clavier), de l’automatisation (envoi de commandes pré-enregistrées), du confort d’utilisation (bloquer le touchpad d’un ordinateur portable lorsque le clavier est en cours d’utilisation) et bien d’autres choses.

    L’input_server a reçu des corrections de problèmes sur la gestion des réglages de souris, permettant en particulier d’utiliser des réglages différents pour plusieurs périphériques (souris, touchpad), et que ceux-ci soient bien enregistrés.

    registrar

    Le serveur registrar suit les applications en cours de fonctionnement, et leur permet de communiquer entre elles au travers de l’envoi de messages. Il assure également le suivi de la base de données des types MIME et des associations de types de fichiers avec les applications correspondantes.

    L’implémentation de BMessageRunner, qui permet d’envoyer des messages périodiques (par exemple pour faire clignoter le curseur des zones de texte à la bonne vitesse), autorise maintenant des intervalles de répétition en dessous de 50 millisecondes. Cela permet d’utiliser ce système pour des animations fluides de l’interface graphique, par exemple.

    D’autre part, la liste des applications et documents récemment lancés est maintenant limitée à 100 entrées. Cela évite un fichier qui grossit indéfiniment et finit par contenir surtout des vieilles informations sans intérêt.

    Kits

    Le système Haiku fournit les mêmes APIs que BeOS. Elles couvrent les usages basiques d’une application, et sont découpées (dans la documentation de BeOS et de Haiku, au moins) en « kits » qui prennent chacun en charge une partie spécifique (interface graphique, multimédia, jeux vidéos, accès au matériel, etc).

    Interface

    L’interface kit est la partie de la bibliothèque standard qui se charge des interfaces graphiques.

     BColumnListView

    BColumnListView est un ajout de Haiku par rapport à BeOS. Il s’agit d’un élément d’interface permettant de présenter une liste avec plusieurs colonnes, de trier les lignes selon le contenu de ces colonnes, et aussi d’avoir des items hiérarchisés avec la possibilité de plier et déplier une partie de l’arborescence.

    Cette classe remplace avantageusement BListView et surtout BColumnListView, les classes historiques de BeOS, qui sont beaucoup plus limitées.

    Un certain nombre de type de colonnes prédéfinis sont également disponibles, ce qui facilite la construction d’interfaces présentant les données de différentes applications avec le même formatage.

    La classe BColumnListView elle-même n’a pas changé. Par contre, les colonnes de type « taille » (pour afficher une taille en Kio, Mio, Gio…) et « date » utilisent la langue choisie dans les préférences système au lieu d’un format anglais par défaut.

    BTextView

    BTextView est une classe permettant d’afficher une zone de texte éditable. Elle implémente les fonctionnalités de base (curseur, sélection, retour à la ligne automatique) ainsi que quelques possibilités de mise en forme (couleurs, polices de caractères).

    BTextView peut également être utilisée pour des zones de textes non éditables, souvent plus courtes. Cela permet de réutiliser une partie des algorithmes de mise en page et de formatage du texte dans différents contextes. Dans le cadre de l’utilisation du « layout system », une vue doit pouvoir indiquer sa taille minimale, maximale et optimale. Le « layout system » va ensuite calculer la meilleure disposition de fenêtre possible pour satisfaire ces contraintes.

    Le cas des zones de texte est particulier, car la hauteur optimale dépend du nombre de lignes de texte, qui lui-même peut être plus ou moins grand si la largeur de la vue oblige à ajouter des retours à la ligne. Le « layout kit » prend en compte ce cas particulier, mais les algorithmes ne sont pas encore tout à fait au point et peuvent conduire à des résultats inattendus dans certains cas. Un de ces cas particuliers sur les zones de texte non éditables a été corrigé.

    BMenu

    La classe BMenu permet d’afficher un menu. Elle est utilisée de plusieurs façons, puisqu’on trouve des menus dans des barres de menu, dans des contrôles de type « popup », ou encore en faisant un clic droit sur certains éléments de l’interface.

    Les menus sont également particuliers parce qu’ils peuvent d’étendre en dehors de la fenêtre dont ils sont originaires. Ils sont donc implémentés sous forme de fenêtres indépendantes. Mais cela pose un autre problème : dans Haiku, chaque fenêtre exécute son propre thread et sa propre boucle d’évènements. Si on navigue dans un grand nombre de menus et de sous-menus, cela peut causer quelques problèmes de synchronisation et de performances.

    Le code contient également un grand nombre de cas particuliers pour, par exemple, aligner les raccourcis claviers et les flèches indiquant la présence de sous-menus ente les différents items d’un menu, ou encore détecter si un déplacement de souris a pour but de sélectionner un autre menu (en dessous ou au-dessus de celui actif), ou bien plutôt de naviguer vers un sous-menu.

    Les nouveautés suivantes sont apparues cette année:

    • Correction de problèmes de race condition lors de l’ajout d’items dans un menu pendant qu’il est affiché à l’écran. Ce problème se manifestait par exemple dans les menus affichant la liste des réseaux Wifi, qui sont mis à jour en temps réel.
    • Finalisation de l’implémentation de la navigation au clavier (avec les flèches directionnelles) dans les menus.
    • Affichage des symboles graphiques UNICODE pour « backspace » (⌫) et « delete » (⌦) si ces touches sont utilisées comme raccourcis clavier pour un item de menu.
    • Utilisation d’un algorithme de tri stable pour la fonction SortItems. Ce type d’algorithme préserve l’ordre relatif des items qui sont égaux d’après la fonction de comparaison. Ce n’est pas le cas de certains algorithmes de tri classiques, notamment le quicksort. La conséquence était que trier un menu déjà trié pouvait changer l'ordre des items. C’était visible encore une fois sur le menu listant les réseaux Wifi, qui est trié par puissance du signal reçu.

     BSpinner

    BSpinner est un contrôle permettant de choisir une valeur numérique, soit à l’aide de boutons +/- pour modifier la valeur par incréments, soit en entrant directement la valeur dans une zone de texte.

    Il s’agit d’une extension de Haiku par rapport à BeOS qui ne proposait pas cette fonctionnalité.

    Cette classe est encore en cours de développement. Elle a reçu des améliorations pour désactiver correctement les boutons +/- lorsque la valeur atteint le minimum ou le maximum autorisé, et aussi une correction sur le message de notification envoyé lors des changements de valeurs du spinner, qui ne contenaient pas la bonne valeur.

    rgb_color

    La structure rgb_color permet de représenter une couleur par la valeur de ses composantes rouge, vert, bleu (comme son nom l’indique) et alpha (comme son nom ne l’indique pas). Elle fournit également un certain nombre de fonctions pour mélanger des couleurs, les éclaircir ou les assombrir.

    La méthode Brightness() dans la classe rgb_color implémentante maintenant l’algorithme perceptual brightness documenté par Darel Rex Finley, qui donne des meilleurs résultats que l’algorithme utilisé précédemment (qui était celui de la luminosité dans l’espace de couleurs Y'IQ. La fonction perceptual_brightness devenue redondante est supprimée.

    Cette méthode permet en particulier de déterminer si une couleur est « sombre » ou « claire », et ainsi de décider si du texte affiché par-dessus doit être blanc ou noir (comme démontré ici par exemple).

    Locale

    Le locale kit se charge de tous les aspects liés à la localisation : traductions des applications, formatage des messages en utilisant les règles de pluralisation de chaque langue, formatage de dates, de nombres avec et sans unités, de pourcentages, nom des fuseaux horaires…

    Il utilise ICU pour implémenter la plupart de ces fonctionnalités, mais fournit une surcouche avec une API s’intégrant mieux avec les autres kits.

    La principale évolution cette année est l’implémentation de BNumberFormat, qui permet de formater des nombres. Elle permet de choisir une précision (nombre de décimales - pour les langues qui utilisent un système décimal), d’afficher ou non des séparateurs de groupes (de milliers en français, mais par exemple en Inde la séparation se fait traditionnellement par multiples de 10 000).

    Media

    Le media kit se charge de tous les aspects multimedia.

    Il se compose de deux parties. D’une part, un système de gestion de flux média temps réel, permettant de transférer des données multimédia (son ou flux vidéo par exemple) entre différentes applications qui vont les manipuler, le tout avec un certain contrôle du temps de traitement ajouté par chaque opération, pour tenter de minimiser la latence tout en évitant les vidages de tampons qui produiraient une interruption dans le flux. D’autre part, des classes permettant d’encoder et de décoder des fichiers média et d’en extraire des flux de données (encodées ou décodées).

    C’est surtout cette deuxième partie qui a reçu quelques évolutions. La version de ffmpeg utilisée pour le décodage de presque tous les formats audio et video est maintenant la dernière version ffmpeg 6. Quelques autres problèmes (erreurs d’arrondis, gestion des tampons partiels en fin de fichier) ont également été corrigés, ce qui permet de faire fonctionner à nouveau le jeu BePac Deluxe qui est extrêmement intolérant au moindre écart de comportement par rapport à l’implémentation du Media Kit dans BeOS.

    Support

    Le support kit contient un ensemble de classes basiques mais indispensables : gestion des chaînes de caractères, des tampons en mémoire, etc. Il fournit les briques de bases utilisées par les autres kits.

    BDataIO

    BDataIO est une classe abstraite avec des fonctions de lecture et d’écriture. Plusieurs autres classes sont des instances de BDataIO, par exemple BFile (représentant un fichier), mais aussi BMemoryIO (permettant d’accéder à une zone mémoire).

    Plusieurs autres classes acceptent BDataIO (ou sa sous-classe BPositionIO, qui ajoute la possibilité de se déplacer à une position donnée dans le flux) comme entrée ou comme sortie. Il est donc facilement possible de réaliser les mêmes opérations sur un fichier, une zone de données en mémoire, un socket réseau, ou tout autre objet susceptible de fournir une interface similaire.

    BDataIO elle-même n’a pas évolué, mais deux de ses implémentations, BBufferedDataIO et BAdapterIO, ont été améliorées. Ces deux classes permettent de construire un objet BDataIO à partir d’un autre, en ajoutant un cache en mémoire pour accélérer les opérations ou encore pour rendre compatible avec BPositionIO un objet qui ne l’est pas.

    Ces classes sont en particulier utilisées par l’application StreamRadio, qui implémente la lecture de podcasts en connectant directement le résultat d’une requête HTTP (effectuée grace au network kit) dans un décodeur audio (via la classe BMediaFile du media kit). La mise en tampon permet de revenir en arrière dans la lecture d’un épisode, de télécharger en avance les données qui vont être lues, et d’éviter de conserver inutilement en mémoire les données qui sont déjà lues par l’application.

    Bibliothèques C

    Les « kits » mentionnés ci-dessus sont l’API en C++ utilisée par les applications Haiku.

    Il existe aussi des APIs en C, en grande partie implémentant la bibliothèque C standard et les fonctions décrites dans la spécification POSIX.

    Libroot

    Libroot implémente la bibliothèque standard C. Elle regroupe entre autres la libc, la libm, et la libpthread, qui sont parfois implémentées comme 3 bibliothèques différentes pour d’autres systèmes. Les évolutions consistent à compléter l’implémentation de la spécification POSIX, et à suivre les évolutions de cette dernière ainsi que des nouvelles versions du langage C. On trouve également des corrections de bugs découverts en essayant de faire fonctionner de plus en plus d’applications sur Haiku, ce qui permet de mettre en évidence des différences de comportement avec d’autres systèmes.

    • Ajout de getentropy pour initialiser les générateurs de nombres aléatoires
    • Correction de problèmes de locks au niveau de l’allocateur mémoire lors d’un fork
    • Plusieurs corrections sur l’implémentation de locale_t, remplacement de code écrit pour Haiku ou provenant de FreeBSD par une implémentation simplifiée mais suffisante, provenant de la bibliothèque C musl.
    • Ajout de static_assert en C11
    • Correction d’un crash lors de l’utilisation de certaines fonctions XSI
    • Ajout de stpncpy
    • La fonction open utilisée sur un lien symbolique pointant vers un fichier non existant peut maintenant créer le fichier cible.
    • Il est possible d’utiliser mmap sur un fichier plus grand que la mémoire disponible sans avoir besoin de spécifier le flag MAP_NORESERVE
    • Utiliser rename pour renommer un fichier vers lui-même ne retourne plus d’erreur (conformément à la spécification POSIX).
    • Ajout de pthread_sigqueue

    Libnetwork

    La libnetwork implémente les APIs nécessaire pour se connecter au réseau (sockets, résolution DNS…). Elle est séparée de la bibliothèque C pour des raisons historiques : l’implémentation de TCP/IP pour BeOS avait été réalisée entièrement en espace utilisateur (le noyau n’offrant qu’une interface pour envoyer et recevoir des paquets ethernet sur la carte réseau). Cela a posé des problèmes de compatibilité avec d’autres systèmes, et des problèmes de performance. Haiku est donc compatible avec la version "BONE" de BeOS, qui implémente la pile réseau dans le noyau.

    • Mise à jour du résolveur DNS à partir du code de NetBSD 9.3. Précédement le code utilisé était celui du projet netresolv de NetBSD, mais ce projet n’a pas connu de nouvelles publications et le code est à nouveau maintenu directement dans NetBSD sans publication séparée.
    • Correction d’un crash lors de l’utilisation de multicast IPv4

    LibBSD

    La libbsd implémente plusieurs extensions fournies par la libc de certains systèmes BSD. Elle est séparée de la bibliothèque C principale pour limiter les problèmes de compatibilité: certaines applications préfèrent fournir leur propre version de ces fonctions, ou d’autres fonctions avec le même nom mais un comportement différent. Elles peuvent alors s’isoler en n’utilisant pas la libbsd pour éviter toute interférence.

    LibGNU

    De façon similaire à la libbsd, la libgnu fournit des fonctions qui sont disponibles dans la glibc (la bibliothèque C du projet GNU) mais ne font pas partie d’un standard (C ou POSIX).

    • Ajout de sched_getcpu pour savoir sur quel cœur de CPU le thread appelant est en train de s’exécuter.
    • Ajout de pthread_timedjoin_np, pour attendre la fin de l’exécution d’un thread (comme pthread_join mais avec un timeout.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Entrevue avec Christophe Grenier, développeur de testdisk et photorec

    testdisk et photorec sont deux outils libres (GPLv2+) formidables… que l’on souhaite pourtant ne jamais avoir à utiliser ! En effet, les deux sont dédiés à la récupération de données après une panne matérielle, ou une bévue.

    TestDisk

    Le premier est axé supports de stockage et leurs partitions, le second orienté récupérations de fichiers (mais il est loin de se limiter aux images).

    Cocorico : le développeur de ces outils est français, et il a bien voulu répondre à notre sollicitation d’entrevue :).

    Bonjour Christophe ! Pouvez-vous présenter votre parcours ?

    Quand j’ai commencé à développer testdisk, mon premier outil de récupération de données, j’étais encore étudiant en école d’ingénieur.
    Maintenant, cela fait plus de 20 ans que je suis diplômé de l’ESIEA, j’interviens d’ailleurs dans son Mastère Spécialisé Sécurité et Information des systèmes depuis 2004.
    Après avoir travaillé dans la sécurité informatique, j’ai travaillé autours des systèmes Linux, du réseau et de la sécurité.
    Depuis un peu plus de 10 ans, je suis directeur d’exploitation pour un hébergeur parisien.
    Dans le cadre de mon auto-entreprise, je fais de la récupération de données.

    Comment avez-vous démarré ce projet ?

    Un ami développeur professionnel sous Windows venait d’acheter un nouveau disque dur et pour éviter d’avoir trop de lettres de lecteurs (C:, D:, E:, …) avait décidé de réduire le nombre de partitions de son disque de données ; ce disque contenait 3 partitions.
    Il a sauvegardé les données, supprimé les 3 partitions, en a créé 2 et — au moment de restaurer les données — il s’est rendu compte qu’il avait été trop vite et qu’il lui manquait la sauvegarde d’une des partitions.
    Sachant que j’avais des connaissances sur le partitionnement des PC (je m’étais intéressé au fonctionnement des virus de boot qui se logeaient dans le premier secteur des disques durs), il m’a contacté.

    Armé d’un éditeur hexadécimal, il nous avait fallu la journée pour reconstruire manuellement la table des partitions et récupérer ces données. Un peu plus tard ayant appris les rudiments de la programmation en C, je me suis dit qu’il devait être possible d’automatiser la récupération des partitions et c’est ainsi qu’est né testdisk en 1998.

    Pour photorec, il a fallu attendre mon premier appareil photo numérique en 2002. Ayant peur de perdre des photos (effacement par mégarde de photos non sauvegardées, reformatage de la mauvaise carte mémoire…), avant même de partir en voyage, j’ai bricolé un programme en C sous Linux capable de récupérer les photos et vidéos prises par mon appareil photo. C’est ainsi que photorec est né pour récupérer des photos. Il a gardé son nom même s’il récupère des centaines de formats de fichier différents.

    Quels sont les points marquants qui ont, selon vous, marqué l’évolution de ces logiciels ?

    Les points principaux ayant permis le succès de ces logiciels sont :

    • de rendre ces logiciels multiplateformes pour PC : MS-Dos et Linux, puis Windows. La prise en charge de macOS est venu bien plus tard et a eu peu d’impact.
    • de distribuer ces logiciels gratuitement. L’utilisation d’une licence opensource (GPL v2+) m’a aussi permis d’avoir quelques contributions.
    • d’être plutôt à l’écoute des utilisateurs et d’enrichir les formats de fichiers gérés par photorec. Certains sont vraiment exotiques.
    • de la documentation en plusieurs langues à une époque où les traductions automatiques étaient quasi-inexploitables. Mais aujourd’hui, la documentation principale de plus de 60 pages est en anglais.

    Un point marquant a été la reconnaissance officielle de l’utilisation de ces logiciels par des organismes étatiques.

    testdisk a été conçu pour un public technique, j’ai eu des retours de différents sociétés de récupération de données de part le monde l’utilisant mais en général, elles ne souhaitent pas communiquer sur leur utilisation de logiciels (libres ou du commerce).

    Un tournant a eu lieu en 2014 quand le NIST, dans le cadre du Computer Forensics Tool Testing Program (CFTT), a testé et publié ses résultats sur les capacités de photorec. En comparant les résultats de chaque outil, on découvre que photorec a les meilleurs résultats (1ère place ex aequo).
    Ainsi, photorec figure dans le catalogue de logiciels que les agences d’États américains peuvent utiliser.

    photorec apparaît dans les diapositives de la formation SecNum Academie de l’ANSSI.

    Pourquoi un seul paquet pour deux logiciels, ou pourquoi pas un seul logiciel ?

    Quand on parle de testdisk et photorec, il y a aussi fidentify, un outil en ligne de commande qui permet de tester rapidement l’identification de fichiers en utilisant les mêmes parsers que photorec, sans oublier qphotorec, une version graphique de photorec.

    Selon les distributions, vous pouvez avoir un package testdisk comprenant testdisk, photorec et fidentify et un package qphotorec pour qphotorec.

    testdisk utilise un accès en écriture au disque, photorec n’utilise qu’un accès en lecture. photorec est plus facile d’utilisation que testdisk, c’est presque du next/next/next, il ne fait que du « file carving » (récupération de fichiers par identification des entêtes).

    Quelles sont les fonctionnalités les plus attendues que vous pensez implémenter ?

    La vérification formelle du code des parsers de photorec est ce qui m’a le plus occupé ces dernières années, je continue de travailler dessus.
    Je n’ai pas prévu d’implémenter de nouvelles fonctionnalités dans l’immédiat.

    Avez-vous des retours d’utilisateurs, des remerciements de personnes qui ont pu grâce à ces outils retrouver une partie de leur vie numérique, ou de grincheux ?

    Perdre une partie de sa vie numérique est très stressant.
    De fait, j’ai été confronté à des grincheux très agressifs dont un cas extrême de menaces répétées de mort de la part d’un individu qui n’avait pas pu récupérer ses données. Les hébergeurs de ses messageries successives ont agi rapidement lorsque j’ai signalé ses messages, mais je me suis posé la question à ce moment-là si cela valait bien la peine de m’investir autant pour risquer cette violence numérique.

    Les retours positifs des utilisateurs et leurs remerciements sont ce qui a permis de me motiver à continuer de développer sur toutes ces années ce projet.
    À une époque, je recevais quotidiennement des mails de remerciements et/ou des donations. C’est moins fréquent désormais, mais c’est peut-être parce que les sauvegardes vers le cloud sont beaucoup plus courantes et qu’ainsi les gens ont moins recours à la récupération de données.

    Effectivement, perdre une partie de sa vie numérique est très stressant, avez-vous des conseils à donner sur la sauvegarde ?

    Ce sont des conseils très généraux :

    • que cela soit au niveau personnel ou au niveau professionnel, il est important de vérifier le périmètre de la sauvegarde. Si vous n’aviez plus que votre dernière sauvegarde, que vous manquerait-il ?
    • testez une restauration de données
    • si possible, multipliez les sauvegardes (sauvegarde avec historique ou versionning, pas une simple synchronisation)
    • dans l’idéal, plusieurs lieux de sauvegarde.

    Sur ces projets, y a-t-il d’autres contributeurs ?

    testdisk et photorec reçoivent principalement des contributions ponctuelles. J’en profite pour remercier toutes les personnes qui m’ont aidé pour les traductions, pour avoir partagé des fichiers dans des formats exotiques, ou pour avoir contribué au code.
    Merci aussi aux personnes ayant participé à la modération du forum et au modérateur actuel !

    Y a-t-il des fonctionnalités importantes qui ne seront pas développées, et pourquoi ?

    À moins de recevoir des contributions, je ne pense pas pousser davantage le support mac.
    Le chiffrement des disques sous Windows va devenir la norme, comme c’est le cas sous macOS. Je pense que cela va freiner le développement de testdisk et photorec. La récupération va devenir bien plus complexe en exigeant un déchiffrement préalable.

    Des souvenirs marquants de cette expérience ?

    Je crois que l’une des anecdotes qui m’a le plus amusé est celle que j’ai reçue en janvier 2007 : dans un premier mail, l’utilisateur explique qu’un appareil photo a été volé dans sa voiture, mais qu’une semaine plus tard, la police a trouvé le coupable et a pu restituer l’appareil photo. Le contenu avait été effacé, mais grâce à photorec, l’utilisateur avait récupéré plus de 300 photos.

    Currently I am recovering over 300 photos using PhotoRec that my sister in law took over the holidays. Our car was broken into and the camera was stolen. A week later the police found the guy! They found the camera, but it had been wiped.
    I had read about recovering photo's from flash cards via a story on slashdot, and now here I am.

    Quelques heures plus tard, j’ai reçu la suite de l’histoire :

    I have recovered some pictures that look to be taken by the thief […]
    I am submitting a CD of the data I have recovered to the Detective involved in the case. My little camera was involved in a much larger theft, so hopefully the pictures they took will help nail them all!

    Le voleur avait utilisé l’appareil photo, photorec a permis de récupérer des photos ayant beaucoup intéressé le détective en charge du dossier : celui-ci espère découvrir les autres personnes impliquées dans un vol de plus grande envergure.

    Avez-vous eu des échanges avec des éditeurs de logiciels similaires (opensource ou propriétaires) ?

    photorec a été victime de plusieurs contrefaçons.

    Dans un cas, un fabricant de carte mémoire a distribué un logiciel de récupération de données, ce fabricant avait sous-traité le développement qui avait « optimisé » son temps de développement en récupérant le code source de photorec, remplaçant tous les entêtes de copyright et ajoutant une interface graphique.
    Après avoir contacté le fabricant, celui-ci a fait rétablir les copyrights manquants et le code a été distribué en GPLv3.

    Dans d’autres cas, des développeurs ont volontairement publié des contrefaçons qu’ils revendaient. Après avoir fait fermer leur hébergement plusieurs fois, ils ont fini par trouver un hébergeur bullet-proof, un hébergeur qui ne répondait plus aux plaintes…

    Concernant le forum, avez-vous déjà rencontré des difficultés avec le respect du code de conduite ?

    La modération sur le forum est obligatoire, les spammeurs sont très nombreux et inventifs en réutilisant par exemple du contenu d’autres sujets. Aucun code de conduite n’a été formalisé.
    Le forum ne tient plus que grâce à la présence d’un modérateur, je ne sais pas si cette partie du projet va perdurer.

    Quel est votre modèle économique ?

    Le projet est né comme un projet personnel et reste géré comme tel.
    Je travaille chez Global Service Provider, une société de services et hébergement informatique, qui me permet de disposer gracieusement (Merci à eux) de machines virtuelles (VM), sauvegarde, monitoring pour le projet.
    Diverses donations ponctuelles couvrent les frais des différents noms de domaine, mon équipement informatique personnel…

    Au niveau personnel, quels logiciels libres utilisez-vous, sur quel système d’exploitation ?

    À l’exception des raspberry pi sous Raspbian, les différents ordinateurs de la maison sont sous Fedora Linux.
    J’utilise gnome comme environnement graphique, alpine et roundcube pour la messagerie, vim comme éditeur de texte, du docker avec moby, gcc, python…

    Et au niveau professionnel ?

    Mon ordi portable est aussi Fedora Linux.
    Les serveurs Linux que mon équipe et moi gérons sont principalement sous AlmaLinux et Debian.

    J’utilise tous les jours ansible (automatisation des configurations), git (versionning), netbox (gestion de datacenters), oxidized (sauvegarde réseau), mediawiki (documentation)…

    Merci pour votre disponibilité, et pour ces merveilleux outils !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Parcours libriste avec lareinedeselfes — « Libre à vous ! » du 3 septembre — Podcasts et références

    13 septembre 2024 à 10:21

    Deux cent dix-huitième émission « Libre à vous ! » de l’April. Podcast et programme :

    • sujet principal : Parcours libriste avec lareinedeselfes
    • chronique F/H/X de Florence Chabanois sur le thème « Formulations excluantes et invisibilisantes »
    • chronique À la rencontre du libre de Julie Chaumard sur le thème « Les-Tilleuls.coop - Une coopérative basée sur le logiciel libre »

    Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 MHz en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune. Vous pouvez nous laisser un message sur le répondeur de la radio : pour réagir à l’un des sujets de l’émission, pour partager un témoignage, vos idées, vos suggestions, vos encouragements ou pour nous poser une question. Le numéro du répondeur : +33 9 72 51 55 46.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Recommandations de lecture: RE2020, CSTB, STD, ACV, FDES, INIES, HQE, coup de gueule et FOSS

    En passant dernièrement dans l’espace de rédaction de LinuxFr.org, au sujet de FreeCad 1.0 (dépêche en cours de rédaction, mais la RC1 est pour dans quelques jours), un intervenant parle de Gestion du Cycle de Vie d'un Produit.

    Dans le domaine du bâtiment / BTP, on est en plein dedans et depuis quelque temps déjà. Effectivement, un logiciel libre comme FreeCad pourrait, à priori, tout à fait trouver sa place dans ce domaine, mais les obstacles sont nombreux et pour certains, très difficiles à surmonter.

    Je vous propose un petit tour parmi ces acronymes pour vous en convaincre.

    Et en commençant par un petit rappel à la loi si vous ne suivez pas l’actualité :)

      Sommaire

      La RE2020 est en vigueur

      RE2020

      C’est l'arrêté du 4 août 2021 qui a définitivement activé la Réglementation Environnementale 2020.

      Depuis le 1ᵉʳ janvier 2022, tous les nouveaux projets de construction de bâtiment doivent être conformes à la RE2020. Elle reprend dans son volet « Énergie » l’esprit de la Réglementation Thermique RT2012 (et des Réglementations Thermiques précédentes, RT2008, RT2004) en vigueur jusqu’à cette date. Elle y ajoute à présent un volet « bilan Carbone » sur le cycle de vie de l’ouvrage (50 ans minimum).

      Je vous recommande ce guide plutôt complet de 93 pages (à ouvrir et à garder sous le coude pour la suite ;).

      Remarque: Ce document (2.2 page 26/93) contextualise la RE2020 par rapport à la précédente RT2012.
      L’objectif initial des RT était (et est toujours) de réduire les pertes d’énergie entre l’intérieur et l’extérieur. Une bonne idée, tout le monde en convient.
      Les RT2004 et RT2008 étaient plutôt « prescriptives » (« obligation de moyens » dans le jargon du BTP) tandis que la RT2012 impose une « obligation de résultats » suivant des critères qui lui sont propres.

      Sur le site du Ministère du Développement durable, on peut trouver énormément d’infos utiles et ces liens spécifiques à la suite du propos :

      Bien que le mot logiciel ait attisé votre curiosité, parlons de la référence en matière de bâtiment en France: le CSTB.

      Le Centre Scientifique et Technique du Bâtiment (CSTB)

      Présentation

      Le Centre Scientifique et Technique du Bâtiment a été créé en 1947 et fonctionne aujourd’hui sous le statut d’Établissement Public à caractère Industriel et Commercial (EPIC). Son existence est entérinée dans le Code de la Construction et de l’Habitat, (en particulier, ses missions dans l’article 121-1)

      I.
      - réaliser ou faire réaliser des recherches touchant à la technique, l’économie, l’environnement, la performance énergétique, la qualité sanitaire, la sociologie et, plus largement, au développement durable dans la construction et l’habitat ;
      - réaliser, pour le compte des services du ministre chargé de la construction et des autres ministères, des études contribuant à la définition, la mise en œuvre ou l’évaluation des politiques publiques dans le champ de la construction et de l’habitat. En particulier, il participe aux travaux d’une commission, constituée auprès du ministre chargé de la construction par arrêté de ce ministre, et chargée de formuler les avis techniques et les documents techniques d’application sur des procédés, matériaux, éléments, ou équipements utilisés dans la construction, lorsque leur nouveauté ou celle de l’emploi qui en est fait nécessite une expertise collective pour en apprécier l’aptitude à l’emploi.

      Il contribue à la diffusion et à la valorisation des connaissances scientifiques et techniques en matière d’habitation et de construction durable produites dans le cadre de ses recherches et études, par des publications et toutes autres mesures appropriées, dont la normalisation. Il participe également, en liaison avec les services intéressés et sous le contrôle du ministre chargé de la construction, aux activités de coopération technique internationale concernant l’habitation et la construction. Il peut se voir confier toutes missions ayant trait à ces mêmes matières dans le domaine international.

      II. - Parallèlement à ses missions d’intérêt général décrites à l’article L. 121-1, le Centre scientifique et technique du bâtiment apporte son concours aux organismes, groupements, collectivités et personnes physiques ou morales qui le sollicitent pour des missions se rattachant à l’objet de ses activités, notamment par la réalisation de prestations d’études et de conseil, d’essais, et la délivrance de certifications.

      C’est donc un acteur incontournable dans le domaine de la construction tant son champ d’intervention est vaste.

      En particulier, en ce qui nous intéresse, il lui revient la responsabilité d’évaluer la conformité d’une application destinée à faire une étude RE2020.
      Cet audit par le CSTB dure de 3 à 7 mois et se réalise suivant des règles.

      En voici un extrait (page 14/16):

      12 TARIFS
      Tarif pour l’évaluation d’un logiciel thermique : 5 700 € HT, dont 700 € HT de frais administratifs.
      Tarif pour l’évaluation d’un logiciel environnement : 4 000 € HT

      Ce n’est pas donné, mais supposons que je sois riche et venons-en enfin à nos logiciels.

      Calculs « Partie énergie »

      C’est peut-être la partie la plus simple à priori puisqu’il n’y a pas de moteur de calcul à programmer. Il n’y en a qu’un seul et il est fourni par le CSTB en version compilée appliquant les règles dites « Th-BCE 2020 ».

      Cela tombe bien car l’annexe III le pavé décrivant les modalités du calcul fait plus de 1800 pages.

      La figure 1 sur la page 5 du règlement d’évaluation (voir ci-dessus) présente l’architecture globale d’une application. Elle consiste à arranger des données synthétiques sur l’ouvrage, dans un format XML en entrée du moteur et à présenter convenablement les synthèses des résultats en sortie.

      Ainsi, toutes les applications « pro » ne différent que par leur interface utilisateur. FreeCad est tout à fait adapté à agréger les données pour générer le XML attendu en entrée par le moteur de calcul. Le module « Schedule » de l’atelier « BIM » pourrait être une bonne base de départ.

      Mais il n’y a ni accès direct à ce moteur de calcul (distribué en tant que *.dll semble-t-il !), ni a sa documentation.

      Toutefois, le CSTB met gratuitement à disposition l’application (sous Windows donc) COMETH. Il faut ouvrir cette plaquette PDF de 2 pages pour trouver l’adresse mél à qui écrire pour savoir comment accéder à l’application.

      Th-BCE != STD

      À noter que les règles Th-BCE utilisées par le moteur de calcul et présentées dans l’annexe III demandent la saisie d’un nombre assez conséquent d’informations. Pourtant, à quelques modifications près, rien de nouveau sous le soleil, car ce sont sensiblement les mêmes que pour la RT2012.

      Elles permettent de qualifier, après un passage à la moulinette logicielle, la performance de l’enveloppe du bâtiment (grosso modo: isolation+fenêtres/portes+étanchéité à l’air) avec un Bbio, une consommation en énergie avec un Cep, etc qui devront respecter certains seuils (voir 4.1 page 49/93 du guide RE2020) pour avoir le certificat.

      C’est une méthode approchée qui n’a rien d’une Simulation Thermique Dynamique.

      Ainsi, concernant les scénarios d’occupation, pour les règles Th-BCE (voir page 10/93 du guide RE2020)

      …, il s’agit toujours de scénarios conventionnels et de profils moyens, de sorte que les résultats ne peuvent être utilisés comme outil de prédiction des consommations.

      Une STD prendra en compte les « vrais cas d’usage » en fonction de scénarios bien plus précis (comme la variation journalière et saisonnière de la fréquentation, de l’utilisation des équipements, des apports naturels solaires etc).

      Pour cela, le CSTB vend le logiciel TRNSYS v18 en 1ʳᵉ installation à 4 500 € HT.

      Calculs « partie Carbone »

      C’est un grand changement réglementaire qu’introduit la RE2020. L’objectif affiché par le législateur est celui de la lutte contre le réchauffement climatique et pour cela considère que le « bilan carbone sur le cycle de vie » est un bon indicateur.
      En vérité, le seul terme « Carbone » est un peu réducteur. Si le « bilan Carbone » est bien l’unique critère environnemental qu’il faudra respecter selon les termes de la RE2020, l’étude porte en elle-même sur 36 données environnementales (voir page 39/93 du guide RE2020):

      Le calcul réglementaire réalise donc simultanément le calcul de 36 indicateurs
      correspondant aux 36 indicateurs inclus dans les données environnementales

      NDR: tout est en place pour une prise en compte ultérieure par le législateur d’autres critères environnementaux (eutrophisation des sols, impacts sur l’eau…)

      Le calcul est on ne peut plus simple: récupérer les quantités des différents types de produits et les multiplier par les données environnementales correspondantes (à peu de choses près, voir illustration 12 page 56/93 du guide RE2020).

      Avant de quitter brièvement le CSTB et de partir à la recherche de ces « données environnementales », je signale que son logiciel COMENV fait ces calculs d’impact « Carbone ». Il faut ouvrir cette plaquette PDF de 2 pages pour savoir qu’il vous en coûtera 100 € HT/an et pour trouver l'adresse du formulaire de contact (mais il y a une erreur de certificat) !

      L’Analyse du Cycle de Vie (ACV)

      Si vous avez lu Gestion du Cycle de Vie d’un Produit, vous n’apprendrez pas grand-chose de plus en lisant la page Wikipedia pour l'Analyse du Cycle de Vie.

      Il s’agit du même concept: évaluer suivant différents indicateurs l’impact environnemental d’un produit sur l’ensemble de sa durée de vie.

      Les grandes étapes du cycle de vie d’un produit

      Dans notre cas il faut distinguer deux types d’ACV.

      ACV Globale

      C’est ce que fait la RE2020 (voir 4.2 page 53/93 du guide) en ventilant l’impact « carbone » sur les différentes étapes du cycle de vie de l’ouvrage et sur des indicateurs Ic.. hybrides décrivant la part des composants, du chantier, de l’énergie en exploitation, de l’eau en exploitation (page 39/93).

      ACV Unitaire

      Comme on l’a vu, la RE2020 s’appuie sur des quantités (que FreeCad pourrait provisionner) et des données environnementales unitaires pour un produit donné (ou d’un type, d’une gamme). Par exemple 1 m³ de béton, 1 m² de placo BA13, 1 kg de colle à placo, etc. Dans le jargon de l’ACV, c’est une UF, Unité Fonctionnelle.

      Ces données environnementales, dans le cadre d’une étude RE2020 proviennent de plusieurs sources tel que précisé dans cette note explicative page 3/10.

      L’esprit est que si le fabricant n’a pas fourni de données environnementales pour son produit, des valeurs par défaut ou forfaitaires sont prises en compte dans le calcul. Ces valeurs sont volontairement défavorables pour inciter les acteurs de la fourniture de « composants » à publier des FDES.
      (voir également page 43/93 et l’organigramme page 44/93 du guide RE2020)

      Les FDES

      Les Fiches de Déclaration Environnementale et Sanitaire sont donc la base d’une étude RE2020 sur son aspect environnemental.

      Pour plus d’info sur les FDES

      Elles doivent répondre aux exigences de la Norme NF EN 15804+A2 (Contribution des ouvrages de construction au développement durable - Déclarations environnementales sur les produits - Règles régissant les catégories de produits de construction), à retrouver sur la boutique de l’AFNOR.
      Oui, ce n’est pas donné pour à peu près 25 pages franchement pertinentes sur un total de 51.

      La Loi n’impose pas aux fabricants des produits utilisés dans une opération de construction à publier une FDES mais, comme on l’a vu, cherche à les y inciter.

      Pour faire établir une FDES, il faut passer par un organisme agréé comme le CSTB: https://www.cstb.fr/nos-offres/toutes-nos-offres/declaration-environnementale-fdes

      Le ticket d’entrée est à partir de 6 500 € HT d’après cette plaquette PDF.

      Exemple de FDES pour un complexe plaque de plâtre 13 mm + isolant de 140 mm:
      https://www.base-inies.fr/iniesV4/dist/infos-produit/40016

      Les 36 données environnementales sont dans l’onglet « indicateurs » et sont ordonnées de la manière suivante:

      • en catégories: Impacts environnementaux, Consommation des ressources, Déchets, Flux sortants, Stockage du carbone
      • et chaque indicateur est détaillé pour chaque étape de son cycle de vie.

      Le lecteur perspicace aura relevé dans les adresses la chaîne de caractères inies, alors allons-y.

      L’INIES

      La base de données environnementales

      Appelée INIES, elle permet de consulter les FDES. Elle est déclarée en accès libre. https://www.base-inies.fr/ vous renvoie l’erreur 403 de l’Apache « Tomcat » pas content, il faut aller librement sur https://www.base-inies.fr/iniesV4/dist/consultation.html .

      Pas mal de changements depuis mes dernières visites il y a 10 ans au moins.

      • l’interface s’est modernisée (javascript) pour le meilleur. Ça marche très bien.
      • il y a beaucoup plus de produits référencés.
      • il y a maintenant des « configurateurs »
      • mais malgré tout, en connaissant la diversité de l’offre, il reste plein de trous dans la raquette: https://www.inies.fr/la-re2020-booster-de-la-production-des-fdes-et-des-pep/ (fin 2023: 3630 FDES et 961 PEP seulement)
      • et puis comment utiliser tout ça dans le cadre de l’ACV Globale pour pouvoir vérifier la conformité à la RE2020 ?

      Le webservice de l’INIES

      Par un service web bien entendu: https://www.inies.fr/programmes-et-services/le-webservice-des-donnees-numerisees/

      Il faut d’abord demander l’accès au service: https://www.inies.fr/ressource/formulaire-de-demande-dacces-au-webservice/

      Dans ce formulaire, le cas du logiciel libre est envisagé.
      Mais il faudra passer l’examen de la demande par le CSIB (d’après les CGV):

      Le Conseil de surveillance de la base INIES (CSIB) : désigne les membres constitutifs de ce comité qui définissent la politique générale en matière de contenu de la base INIES et approuvent les demandes d’accès au webservice.

      Plus d’informations sur la base INIES, son utilisation (stats et logiciels qui l’utilisent), les configurateurs de FDES, les PEP et l’ICV dans cette présentation synthétique de 35 pages.

      L’organisme INIES

      Organisation INIES

      Source: https://www.inies.fr/inies-et-ses-donnees/qui-sommes-nous/

      l’Alliance HQE-GBC a un rôle central aux côtés de l’AFNOR, du CSTB, de l’ADEME, de la FFB, de la CAPEB…

      HQE

      Logo marque HQE

      Source: https://www.hqegbc.org/qui-sommes-nous-alliance-hqe-gbc/usage-de-la-marque-hqe/

      Obtenir un label HQE est une démarche volontaire de la part du Maître d’Ouvrage (celui qui paye). Cela nécessite une certification délivrée par l’alliance HQE-GBC.

      J’en ai entendu parler (par la presse spécialisée) quand les premières certifications ont eu lieu vers 2005/2006

      https://www.hqegbc.org/qui-sommes-nous-alliance-hqe-gbc/notre-histoire-alliance-hqe-gbc/

      Quand soudain, patatras,

      Le coup de gueule de Rudy Riccioti

      Le bonhomme

      Résidence Argo

      Résidence Argo, Source: https://rudyricciotti.com/

      RR (son acronyme ;) est un architecte plutôt connu, qui aime le béton et a le verbe haut des gens du midi. Un sacré numéro.

      Comme d’autres qui ne sont pas du tout débordés dans leur vie de tous les jours (Ministre, moule de LinuxFr.org, etc), il aime aussi écrire: 14 bouquins pour sa part (!) dont

      La trilogie « HQE »

      Les liens sont vers le site Babelio

      1. HQE Transbordeurs (22/03/2007)
      2. HQE les renards du temple Al Dante (21/11/2009)
      3. HQE - La HQE brille comme ses initiales sur la chevalière au doigt Le Gac Press (25/04/2013) Le Gac Press (25/04/2013)

      Citations de Babelio aussi:

      « La HQE, véritable privilège des pays riches de niquer davantage la nature en paraissant vertueux. »
      R.R., conférence 12.07.27, Palembang

      « Le sigle le plus démagogue jamais inventé protège ses initiales, confirmant là ce désir de pouvoir sur un territoire d’intérêt public… »

      Ce que j’en pense

      C’est un pamphlet pas bien épais. Le numéro 2 est une version revue et légèrement augmentée du 1 (pour répondre à la polémique sans doute ;) et le troisième reprend les deux premiers en y ajoutant un épilogue.
      Comme conseil de lecture je dirais de prendre le trois.

      Le ton est incisif et rentre dedans jusqu’à parfois paraître outrancier. Mais sur le fond, l’essentiel du propos me semblait pertinent à l’époque: HQE, un lobby technico-scientifico-économique a mis la main sur une usine à gaz (qu’il va construire et imposer) qui demande à « numériser » l’acte de construire et à en décomposer le moindre élément constitutif (FDES, ACV).

      J’y ai vu « pff, encore plus d’informatique quoi ». La RT2012 (obligatoire contrairement à une labellisation HQE) étant dans les tuyaux à cette époque-là, il y avait déjà de quoi faire. RR y voit un appauvrissement des savoirs et de la créativité par des règles aux origines douteuses qui produiront des solutions technico-économiques toutes faites pour des résultats médiocres en tous points.

      RR a raison

      Source: https://qualiteconstruction.com/ressource/batiment/decollement-ite-renovation/

      Conseil de lecture: N’hésitez pas à visiter ce site, il regorge d’excellentes fiches techniques.

      Sur ce point, il est vrai que l’on voit pas mal d’immeubles de 10/15 ans d’âge dans un état assez pitoyable. C’est plutôt rageant.

      Ce qui est paradoxal dans le propos de RR, c’est que l’industrie du béton (qui pèse très lourd), son matériau de prédilection, a été en pointe sur ce sujet. Les premières FDES en étaient toutes issues (parpaing, bordure de trottoir, prédalle…) suivie par les plaques de plâtre et les isolants.
      Pour le premier concerné, le bilan carbone est au centre de ses préoccupations au vu des quantités astronomiques mises en œuvre et du mode de production du ciment, très énergivore. Être au plus près des faiseurs de lois était une décision naturelle. Avec ses gros moyens elle a pu s’adapter sans trop de mal à cette nouvelle donne.

      Aujourd’hui de quelques adhérents à HQE (c’est une association, rapport moral et activité 2023 en date de juin 2024) le panel s’est bien diversifié et on y trouve tous les aspects du métier.

      La base INIES s’est bien diversifiée et (cela m’intéresse) j’ai eu la bonne surprise de trouver cette FDES:

      https://www.base-inies.fr/iniesV4/dist/consultation.html?id=28898

      Mur en Adobe (Terre crue + paille + granulats éventuels)

      UF: Assurer la fonction de mur porteur sur 1 m² de paroi, pour une épaisseur comprise entre 14,5 et 35 cm, une conductivité thermique comprise entre 0,4 et 0,6, et une durée de vie de référence (DVR) de 100 ans.

      Cette FDES (que je vous recommande de lire si le(s) sujet(s) vous intéress(ent), elle est dans l’onglet « Documents ») est générique pour toute opération mettant en œuvre cette technique en France. Ce qui est remarquable.
      Elle est à l’initiative de la Confédération Nationale de Construction en Terre Crue.

      Une FDES doit être renouvelée et affinée, ils continuent donc de collecter des données relatives aux chantiers auprès des acteurs de la filière

      Lien vers le questionnaire

      Bravo les gars, avec peu de moyens ils ont fait rentrer une méthode de construction ancestrale et à l’impact carbone très faible dans l’ère de la numérisation à tout-va.

      Sur ces bonnes nouvelles, passons à

      La suite et la fin

      Formats ouverts IFC, BCF, le BIM, les BET, la MOE, et autres acronymes

      Dans une prochaine dépêche sans doute. On y retrouvera FreeCad. Il n’a pas dit son dernier mot.

      Et le logiciel pour faire l’étude et émettre des attestations RE2020 ?

      Aux problèmes d’accès aux ressources et services qui ont été abordés, il faut ajouter que les cahiers des charges sont bien entendu plus touffus que ce qui a été présenté et surtout, que la RE2020 évolue régulièrement. Par exemple ce qui y est intégré au fur et à mesure au nom du titre V (des systèmes: VMC, PAC… 66 à ce jour, chacun avec sa façon d’être pris en charge par la RE2020 pour calculer les différents Ic..)

      https://rt-re-batiment.developpement-durable.gouv.fr/titre-v-r322.html

      Question bonus

      https://mdegd.dimn-cstb.fr/tickets

      Il y a un lien avec le propos ci-dessus, lequel ?

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      24 ans de libcurl

      Curl est un outil en ligne de commande destiné à récupérer le contenu d’une ressource accessible par un réseau informatique et gérant de nombreux protocoles.

      Curl est un outil essentiel pour de nombreux usages, pris en charge par une gamme très large de systèmes d’exploitation, d’architectures matérielles, de l’objet connecté à l’embarqué spatial en passant par l’informatique classique ou les consoles de jeux. Il évolue rapidement et fréquemment, voir par exemple l’arrivée prochaine de HTTP3 pour curl dans Debian unstable (avec le backend gnutls). Son domaine d’utilisation pourrait encore s’étendre avec l’apparition de wcurl dans Debian et bientôt dans le monde entier ?

      Il y a 24 ans, une division du code entre une interface ligne de commande et une bibliothèque a été faite.

      (Cette dépêche est principalement basée sur l’annonce anglophone par Daniel Stenberg, auteur principal de curl et libcurl ; dépêche rédigée sur un téléphone embarquant curl 7.80, pas vraiment la dernière version…).

      La première version de libcurl, baptisée 7.1, date du 7 août 2000. La version de curl précédente, la 6.5.2, pas encore séparée entre une interface ligne de commande et une bibliothèque. Il s’agit de l’écart le plus long entre deux versions de curl. La création de la bibliothèque a été très largement réalisée par Daniel Stenberg seul.

      Il décrit son choix de division ainsi : c'était juste une intuition et une conjecture. Je ne savais pas. Je n’avais pas fait de recherches sur cela ou autre chose. Je me suis juste lancé en me disant qu’on verrait plus tard si j’avais raison ou tort.

      Le nom de la bibliothèque a été choisi faute d’une meilleure idée. L’API a été définie comme étant bas niveau (on peut toujours ajouter une API de plus haut niveau par-dessus), en observant ioctl(), fcntl() et les fonctions du genre. Le code est en C, langage de prédilection de l’auteur principal.

      L’API a bien vieilli : 17 fonctions encore présentes proviennent de la 7.1 ; elle est passée de 17 000 lignes à 171 000 ; elle a survécu aux révolutions HTTP/2 (transferts multiples multiplexés) et HTTP/3 (passer de TCP à UDP).

      L’usage a aussi bien progressé depuis l’entrée dans PHP 4.0.2 comme premier binding (ici rendre utilisable en langage PHP), moins d’un mois après la publication de la bibliothèque.

      En 2002 a été ajoutée une API multi pour gérer des transferts parallèles concurrents de façon illimitée dans un même thread.

      Puis en 2006 vient en surplus le multi_action avec des mécanismes orientés événements, avec une boucle événementielle (comme epoll).

      Les premiers changements douloureux sur l’interface binaire (ABI) ont entraîné une volonté de stabilité, de ne jamais casser volontairement cette interface, et ce depuis 2006.

      libcurl possède des bindings vers au moins 65 langages de programmation, fonctionne sur au moins 103 systèmes d’exploitation et 28 architectures de processeur, est présent dans les bibliothèques standard de langages de programmation (Python, Java, Rust ou .Net). Son ancien concurrent principal libwww n’est plus développé. Bref 18 ans de stabilité d’API et d’ABI.

      L’utilisation de libcurl continue de croître (de plus en plus d’objets connectés notamment). Et curl de manière générale supporte rapidement les nouveaux protocoles et leurs évolutions. À noter que l’auteur principal ne mentionne pas dans ses projections ce qui me semble le plus gros risque pour Curl/libcurl, la difficulté d’avoir une personne prête à lui succéder si quand cela s’avérera nécessaire.

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      S.M.A.R.T. badblocks badblocks2

      S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il utilise une réserve de secteurs de rechange pour réparer quand il détecte un secteur en anomalie.
      Le programme Linux badblocks teste les blocs d’un média par écriture+relecture+comparaison. À l’origine il servait à mettre les blocs mauvais en liste noire dans le file-system.

      Est-il utile de nos jours de vérifier ses médias ?
      Comment se situe S.M.A.R.T. par rapport à l’outil badblocks ?
      Comment vérifier un média en tenant compte de sa surveillance par S.M.A.R.T. ?

      C'est ce que nous allons voir dans la suite de la dépêche.

      smart-drive

      Sommaire

      Préambule

      Quelle précaution prendre vis-à-vis du risque de mauvaise qualité du stockage, quand je viens d’acheter un média (disque SSD, disque rotatif, clé USB, carte SD) ou un appareil sous Linux équipé d’un espace de stockage dont j’ignore la technologie ?
      Sans être parano, je me dis qu’avant d’envoyer des données précieuses sur l’espace de stockage, c’est le moment de faire certaines vérifications. Mais quelles vérifications ? Qu’est-il possible de faire ?

      Sur un média connectable, tout est possible.
      Sur un appareil neuf sans système ni données, tout est possible en utilisant une distrib Live.
      Sur les autres, ça dépend, il y en a où on n’a même pas un accès root pour lancer une vérification « dure » ou « molle » (Android, routeur…).

      En écrivant cet article, je me suis rendu compte que je ne me suis jusqu’ici jamais posé de questions sur l’opportunité de vérifier les espaces de stockage de mes téléphones, PC portables, routeurs, box… bref tous les appareils vendus prêts à être utilisés. Pourtant, que sais-je de la vérification faite par celui qui a installé le système ? Rien, et j’utilise, sans penser que l’espace de stockage de l’appareil n’est ni plus ni moins robuste que celui du PC Linux que j’ai installé dernièrement, mais que j’ai vérifié consciencieusement.

      S.M.A.R.T.

      S.M.A.R.T. est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il surveille un maximum de paramètres (température, temps de fonctionnement, vitesse de rotation pour les disques magnétiques, nombre de démarrages et d’arrêts…) et dépend de l’expérience du fabricant. La réparation de secteurs utilise une réserve de secteurs et le mapping entre secteurs logiques et secteurs physiques.

      On pourrait se dire que, de nos jours, les supports sont fiables et testés par les intégrateurs. D’autres considèrent que la technologie S.M.A.R.T. suffit… et c’est bien commode de ne plus se soucier de la fiabilité des supports de stockage. Mais à la première galère due à un média défaillant, tu évolueras dans ta confiance.

      Sais-tu seulement sur lesquels de tes médias S.M.A.R.T. est installé et actif ?
      Si tu utilises un RaspberryPi, ton média système est… une carte SD. Elle n’a pas S.M.A.R.T.. Idem pour l’extension de mémoire que tu as ajoutée à ton téléphone.

      Je t’invite à lire la page Wikipedia sur S.M.A.R.T. et son paragraphe « Standard, implémentation et limitations ». Que fait et que ne fait pas le S.M.A.R.T. qui fonctionne sur le disque du PC qui te permet de lire cet article ? Difficile de savoir. Comment est-il configuré ? Fais un sondage autour de toi à ce sujet et tu seras pris pour un parano.

      Sur ton PC, sais-tu qu’il y a une option S.M.A.R.T. dans le BIOS (ou UEFI) ? Sais-tu qu’il y a un service smartd dans ton Linux ? As-tu compris aussi qu’avec du RAID il n’est pas toujours opportun d’activer S.M.A.R.T. ? Les communications entre S.M.A.R.T. RAID et l’O.S. peuvent se passer plus ou moins bien selon la qualité de ces éléments. Il te faut bien comprendre ce qu’il est possible de paramétrer et deviner comment ça marche derrière.

      Si tu demandes une vérification à S.M.A.R.T. par smartctl, sais-tu ce qu’il fait ? Se contente-t-il de lire ou fait-il un test en écriture ?

      Enfin, quand S.M.A.R.T. détecte qu’un secteur est devenu défectueux, il ne peut pas deviner quels bits sont défaillants, aussi il renseigne le secteur de secours avec ce qu’il peut, qui est l’état du secteur après défaillance. S.M.A.R.T. a ses limites, il répare comme il peut. S’il est configuré pour, il alerte quand il prévoit de la défaillance, mais sais-tu reconnaître ses alertes ? As-tu compris ce que tu dois faire en réponse aux alertes ?

      Je t’invite à apercevoir la complexité de prise en main de S.M.A.R.T. en faisant quelques recherches sur ces listes de mots :

      smartctl howto
      smartctl configure self test
      smartd howto
      

      et tu verras que ce n’est pas simple à comprendre et à configurer.

      Tu peux te dire naïvement que tout est bien configuré par défaut et que tes médias seront toujours impeccables. Sinon, il va falloir investir en temps et faire quelques essais. À toi de choisir.

      S.M.A.R.T. est une belle avancée technologique, mais il est dangereux de lui attribuer des mérites indus.

      BADBLOCKS

      Le programme Linux badblocks a été créé en même temps que le paquetage e2fsprogs (mkfs.ext2, mkfs.ext3, mkfs.ext4, fsck.ext2…). À l’époque S.M.A.R.T. n’existait pas et il n’y avait pas de mapping entre les adresses logiques et physiques. C’est le file-system qui devait tout gérer quand il détectait un bloc défectueux, notamment la mise du bloc en liste noire. C’est pour cela que mke2fs et e2fsck lancent un badblocks « dur » quand on leur spécifie deux fois l’option -c. Cela dure trèèès longtemps car les paramètres par défaut ne sont plus bien optimisés.

      Depuis l’arrivée de S.M.A.R.T., certains considèrent badblocks comme obsolète. Mais qui peut affirmer que TOUS les médias utilisés par TOUS les usages de Linux sont équipés de S.M.A.R.T. ?
      Peut-être qu’au M.I.T. avec un réseau de classe A, on ne s’abaisse pas à utiliser une clé USB ou un RaspberryPi. Je me demande dans quel type de bulle vivent ceux qui pensent que S.M.A.R.T. est sur tous les médias de stockage.

      Quand j’achète une clé USB, je lui passe badblocks dessus et s’il y a des mauvais blocs, je la rends et je me fais rembourser.
      J’ai essayé d’interroger les fonctionnalités S.M.A.R.T. de diverses clés USB et je n’ai rien obtenu, comme si cette utilité n’y était pas installée :

      # smartctl --scan-open
      # smartctl -x /dev/sdc
      # smartctl -i -d scsi -T verypermissive /dev/sdc
      

      Mes recherches sur Internet n’ont abouti à rien qui me permette de voir une réponse de la part de clés USB. Peut-être que si j’achetais (cher) des clés USB de très haute qualité, j’y trouverais S.M.A.R.T. ?

      Comme l’intervenant du message #25 de ce rapport de bug (en), je pense que badblocks est loin d’être obsolète.
      J’ai envie d’imiter le message #20 juste au-dessus en disant : « Je dois demander --- ***pourquoi*** vous (et d’autres personnes) mettez de l’essence dans vos voitures en 2024 ? L’essence en tant que chose a commencé à devenir inutile pour les voitures vers 2011, lorsque la voiture électrique s’est répandue, et que les batteries sont devenues suffisamment énergétiques pour faire rouler des véhicules sur des centaines de km ».

      Je t’invite aussi à une recherche sur la liste de mots « courbe en baignoire composants électroniques ». Le programme badblocks peut servir au déverminage. On sait en détail ce qu’il fait. Son résultat est clair, contrairement aux implémentations propriétaires de S.M.A.R.T..
      Sans déverminage (rodage) on court le risque de subir trop tôt une réparation discrète incomplète : le secteur réparé sera physiquement bon mais son contenu sera corrompu. La conséquence peut être catastrophiquement discrète. Par exemple, un fichier LibreOffice est une archive zip (compressée), la corruption d’un seul bit y a des conséquences imprévisibles.

      De mon côté, j’utilise badblocks pour tester les médias nouvellement acquis et pour effacer ceux bons à réformer. Ce programme permet aussi la chasse aux médias « fake-size », du genre carte SD de 1To qui accepte de recevoir 1To de fichiers, mais qui ne stocke en réalité que 8Go. On trouve de nos jours (juin 2024) des clés USB de 16To vendues au prix de 5 € ! L’application h2testw sous windows et son équivalent f3 sous linux sont spécialement conçus pour cette chasse. Le microprogramme de ces clés USB ou de ces disques a été détourné pour déclarer un espace de stockage falsifié. C’est de l’escroquerie.

      BADBLOCKS2

      Mon usage du badblocks du paquetage e2fsprogs-1.47.0 m’a amené à y caractériser un bug reproductible en novembre 2023. J’ai eu l’intention de remonter le bug aux équipes ad hoc de ma distribution (Mageia) mais je me suis d’abord mis à regarder le source.

      J’y ai trouvé l’origine du bug, et j’ai trouvé d’autres bugs. En ajoutant des instructions de traçage et de simulation d’erreurs du média, j’ai mis en évidence encore d’autres bugs. De fil en aiguille, j’ai fini par retoucher profondément certains algorithmes, et j’ai appelé badblocks2 cette nouvelle version. J’y ai ajouté diverses options faciles à programmer et commodes à l’usage. J’ai copieusement testé.

      Si tu veux essayer badblocks2 et/ou prendre connaissance de ma démarche, je livre tout sur mon site. Tu verras pourquoi je me suis rabattu sur la création d’une nouvelle version, plutôt que de faire remplacer l’ancienne (ce qui aurait profité à tous).
      Tu peux te faire une idée des fonctionnalités ajoutées en consultant les *.8.txt .
      Tu peux t’inspirer des tests décrits dans le fichier Alire.txt, tester diverses valeurs pour -c -t et voir l’effet sur la vitesse de traitement. Tu peux même jouer à arracher la clé en cours de test (Ctrl-C pour arrêter) !

      J’espère que ce programme servira à d’autres que moi.

      En pratique

      Voici une suggestion d’actions à faire lors de l’acquisition d’un nouveau média (disque SSD, disque rotatif, clé USB, carte SD…). Les commandes doivent être lancées par l’opérateur root.
      Avec cela, quand dans quelques années tu satureras le média, tu seras sûr que le dernier secteur utilisé aura été déverminé avant la mise en production.

      ATTENTION : les usages de badblocks proposés sont destructifs pour les données présentes sur le média. Le mode non-destructif du badblocks actuel comporte des bugs (version e2fsprogs-1.47.0). Celui de badblocks2 a été corrigé.
      ATTENTION : la liste des mauvais blocs renvoyée par le badblocks actuel est fausse (version e2fsprogs-1.47.0). Le nombre de mauvais blocs est correct. La liste renvoyée par badblocks2 est correcte.
      ATTENTION : le paramètre device du média est supposé être /dev/sdc. Ne pas se tromper, au risque d’effacer un autre média en cours d’usage.

      D’abord déterminer le block-size du noyau, c’est une bonne valeur à prendre comme block-size du file-system :

      # blockdev --getbsz /dev/sdc
      

      Dans ce qui suit, je suppose que la valeur 4096 a été renvoyée.

      Ensuite déterminer si S.M.A.R.T. est sur le média :

      # smartctl --scan-open
      # smartctl -x /dev/sdc
      # smartctl -i -d scsi -T verypermissive /dev/sdc
      

      Si S.M.A.R.T. n’est pas sur le média

      Passer badblocks2 pour voir s’il y a 0 ou peu de mauvais blocs :

      # badblocks2 -b 4096 -c 32768 -wrrvvss -t r -t r -e 40 -o /tmp/sdc.bb /dev/sdc
      

      L’option -e peut être supprimée ou modifiée selon la limite du nombre de mauvais blocs considérée acceptable ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man).

      S’il y a trop de mauvais blocs, refuser d’utiliser le média (->garantie ?).

      S’il y a 0 mauvais bloc on peut formater en toute tranquillité (partitionner éventuellement avant) :

      # mkfs.ext? -b 4096 ... /dev/sdc
      

      S’il y a quelques mauvais blocs, sans que la limite -e soit atteinte, on pourra formater en utilisant la liste sauvée de mauvais blocs :

      # mkfs.ext? -b 4096 -l /tmp/sdc.bb ... /dev/sdc
      

      Si l’on veut partitionner, il faudra recalculer la liste des mauvais blocs de chaque partition avant de formater (remplacer sdc par sdc1 dans les commandes badblocks2 et mkfs.ext? ci-dessus).

      Si l’on veut formater en vfat exfat ou f2fs (clés USB en général), il n’est pas possible d’utiliser la liste des mauvais blocs détectés ; la seule solution est de refuser d’utiliser le média s’il y a des mauvais blocs (ou alors de restreindre l’usage à une zone saine… à localiser)

      Si S.M.A.R.T. est sur le média

      On peut vérifier son activation par smartctl :

      # smartctl -i /dev/sdc
      

      Ensuite, il faut interroger le média sur l’état et les capacités de son S.M.A.R.T. :

      # smartctl -a /dev/sdc
      

      Noter le nombre de réallocations faites et prévues :

      # smartctl -a /dev/sdc | grep -i _sector
      

      Puis faire une passe de déverminage, en écriture+lecture car on ne sait pas si l’écriture seule suffit ; ne pas utiliser l’option -p de badblocks ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man) :

      # badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb1 /dev/sdc
      

      Faire une passe de vérification, il ne devrait plus y avoir de mauvais blocs :

      # badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb2 /dev/sdc
      

      S’il y a encore des mauvais blocs, c’est soit que le déverminage n’est pas terminé, soit que le média et/ou son S.M.A.R.T. sont foireux (il ne détecte pas les mauvais secteurs vus par badblocks2 ou les secteurs de réserve sont mauvais ou… pire) ; relancer des passes une par une jusqu’à ce qu’il n’y ait plus de mauvais bloc détecté.

      Re-interroger S.M.A.R.T. pour voir l’évolution des réallocations :

      # smartctl -a /dev/sdc | grep -i _sector
      

      Ensuite on peut formater (partitionner éventuellement avant) en considérant que le média a remappé tous ses mauvais secteurs et est donc impeccable pour l’utilisation :

      # mkfs.ext? -b 4096 ... /dev/sdc
      

      Par la suite, on pourra de temps en temps consulter l’état de santé du média en service :

      # smartctl -H /dev/sda
      

      Si on est courageux, on peut lancer de temps en temps un contrôle du média par son S.M.A.R.T.
      Si on est encore plus courageux, on configurera smartd pour que ces vérifications soient automatiques et pour que les alertes soient envoyées par courriel.

      Attention à la communication entre l’O.S., S.M.A.R.T. et RAID (niveau carte mère / niveau OS / contrôleurs bas de gamme), voir la page Wikipedia sur S.M.A.R.T..

      Que l’esprit « aware » soit en toi, sur tes données et sur ton espace de stockage

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      ❌
      ❌