Haiku est un système d’exploitation pour les ordinateurs personnels. Il s’agit à l’origine d’une réécriture de BeOS. Le projet a démarré en 2001 et est actuellement en phase de beta-test pour une première version stable avec support à long terme. Depuis 2024, l’activité du projet Haiku s’accélère grâce entre autres à l’embauche d’un développeur à plein temps. Les dépêches sur Haiku sont donc désormais publiées tous les 3 mois au lieu de tous les ans pour leur conserver une longueur digeste.

La complète liste des changements survenus pendant ces 3 mois comporte près de 300 commits. La dépêche ne rentre pas dans les détails de chaque changement et met en valeur les plus importants.

Les grosses évolutions sont un nouveau port de Iceweasel (Firefox), et des grosses améliorations sur la gestion de la mémoire.

Comme on est en début d’année, c’est aussi le moment du bilan financier.

Sommaire

• Rapport financier 2024
  • Recettes
  • Dépenses
  • Réserves
• Applications
  • Iceweasel
  • Tracker
  • TeamMonitor
  • HaikuDepot
  • Préférences
  • Expander
  • Cortex
  • Icon-O-Matic
  • PowerStatus
  • StyledEdit
  • WebPositive
  • Mode sombre et configuration des couleurs
  • Outils en ligne de commande
• Kits
  • Application kit
  • Debug kit
  • Device Kit
  • Interface kit
  • Media Kit
  • libshared
• Servers
  • app_server
  • input_server
  • net_server
  • notification_server
  • mail_daemon
  • runtime_loader
• Drivers
  • Périphériques de stockage
  • Cartes son
  • Réseau
  • Pilotes FreeBSD
  • Pilotes spécifiques à Haiku
  • USB
  • PS/2
  • virtio_pci
  • ACPI
  • Sondes de température
  • Pilotes graphiques
• Systèmes de fichiers
  • FAT
  • BFS
  • packagefs
  • NFS4
  • ramfs et ram_disk
  • Autres
• libroot
  • Compatibilité POSIX-2024
    • ioctl et posix_devctl
• Kernel
  • VFS
  • Console et affichage
  • Réseau
  • Gestion de la mémoire
  • Autres
• Chargeur de démarrage
• Outils de compilation
• Documentation
  • Documentation interne
  • Documentation d’API
• Traductions de Haiku

Rapport financier 2024

Recettes

L’association Haiku inc (association de type 501(c)3 aux USA) publie chaque année un rapport financier. Le rôle de l’association est de récolter les dons et de les redistribuer pour aider au développement de Haiku. Elle ne prend pas part aux décisions techniques sur l’orientation du projet, et habituellement les dépenses sont faites en réponse aux demandes des développeurs du projet.

L’objectif en début d’année 2024 était de récolter 20 000$ de dons. Cet objectif a été largement atteint, il a dû être mis à jour 2 fois en cours d’année et finalement ce sont plus de 31 000$ qui ont été reçus ! Cela en particulier grace à un assez gros don de 7 500$.

Les dons sont récoltés via différentes plateformes: Github Sponsors (intéressant, car il n’y a aucun frais de traitement), PayPal, Liberapay, Benevity (une plateforme de « corporate matching »), ainsi que des paiements par chèque, virements bancaires, et en espèce lors de la tenue de stands dans des conférences de logiciels libres. La vente de T-Shirts et autre merchandising via la boutique Freewear reste anecdotique (une centaine de dollars cette année).

Il faut ajouter à ces dons une contribution de 4 400$ de la part de Google en compensation du temps passé à l’encadrement des participants au Google Summer of Code.

Il faut également ajouter des dons en crypto-monnaies, principalement en bitcoins. Le rapport financier présente les chiffres en détail en tenant une compatibilité séparée en dollars, en euros, et en crypto-monnaies, avant de convertir le total en dollars pour dresser un bilan complet.

Une mauvaise nouvelle tout de même: le service de microdons Flattr a fermé ses portes. L’entreprise propose maintenant un service de bloqueur de publicités payant, qui reverse de l’argent aux sites dont les publicités sont bloquées.

Le compte Flattr de Haiku avait été créé pour recevoir des dons sur la plateforme, mais n’avait jamais été configuré pour transférer ces dons vers le compte en banque de l’association. Malgré un certain temps passé à discuter avec le service client de Flattr et à leur fournir tous les documents demandés, il n’a pas été possible de trouver une solution pour récupérer cet argent. Ce sont donc 800$ qui ne reviendront finalement pas au projet Haiku.

Au final, les recettes sont de 36 479 dollars, de loin la plus grosse somme reçue par le projet en un an.

Dépenses

La dépense principale est le paiement de Waddlesplash, le développeur actuellement employé par Haiku inc pour accélérer le développement du système (les autres développeurs participent uniquement sur leur temps libre, en fonction de leurs autres activités). Cela représente 25 500$, un coût assez faible par rapport au travail réalisé.

Le deuxième poste de dépenses est l’infrastructure, c’est-à dire le paiement pour l’hébergement de serveurs, les noms de domaines, et quelques services « cloud » en particulier pour le stockage des dépôts de paquets.

Le reste des dépenses consiste en frais divers (commission PayPal par exemple), remboursement de déplacements pour la participation à des conférences, ainsi que le renouvellement de la marque déposée sur le logo Haiku.

Le total des dépenses s’élève à 31 467$. C’est moins que les recettes, et l’association continue donc de mettre de l’argent de côté. L’année 2022 a été la seule à être déficitaire, suite au démarrage du contrat de Waddlesplash. Ce contrat est à présent couvert par les donations reçues.

Réserves

L’association dispose de plus de 100 000$ répartis sur son compte en banque, un compte PayPal (qui permet de conserver des fonds en euros pour les paiements en euros et ainsi d’éviter des frais de change), et un compte Payoneer (utilisé pour recevoir les paiements de Google).

Elle dispose également de près de 350 000$ en crypto-monnaies dont la valeur continue d’augmenter. Cependant, actuellement ces fonds ne sont pas accessibles directement, en raison de problèmes administratifs avec Coinbase, l’entreprise qui gère ce portefeuille de crypto-monnaies. Le compte n’est pas configuré correctement comme appartenant à une association à but non lucratif et cela pose des problèmes de déclaration de taxes lorsque on souhaite vendre des crypto-monnaies contre du vrai argent. Cette situation persiste depuis plusieurs années, mais l’association n’a pour l’instant pas besoin de récupérer cet argent, les réserves dans le compte en banque principal étant suffisantes.

Applications

Iceweasel

Le navigateur web Iceweasel est disponible dans les dépôts de paquets (seulement pour la version 64 bits pour l’instant). Il s’agit d’un portage de Firefox utilisant la couche de compatibilité Wayland. Le nom Firefox ne peut pas être utilisé puisqu’il ne s’agit pas d’un produit officiel de Mozilla.

En plus du travail de portage pour réussir à faire fonctionner le navigateur, cela a nécessité un gros travail d’amélioration au niveau de la gestion de la mémoire, une partie du système qui est fortement mise à contribution par ce navigateur. On en reparle plus loin dans la dépêche.

Le navigateur est encore considéré comme expérimental: plusieurs fonctions sont manquantes et il peut y avoir des plantages. WebPositive (le navigateur natif basé sur WebKit) reste donc le navigateur installé par défaut avec Haiku, mais les deux sont complémentaires. Par exemple, Iceweasel permet d’afficher les vidéos Youtube avec des performances acceptables.

Tracker

Tracker est le gestionnaire de fichiers de Haiku. Il implémente une interface « spatiale », c’est-à-dire que chaque dossier s’ouvre dans une fenêtre séparée et enregistre sa position à l’écran.

Le code du Tracker fait partie des composants qui ont pu être récupérés de BeOS. Cela signifie que certaines parties du code ont été développées il y a près de 30 ans, dans un contexte où l’élégance du code n’était pas la priorité (il fallait pour les développeurs de BeOS, d’une part livrer un système fonctionnel dans un temps raisonable, et d’autre part, fonctionner sur les machines relativement peu performantes de l’époque).

Les évolutions sur le Tracker nécessitent donc souvent du nettoyage dans de nombreuses parties du code, et provoquent souvent des régressions sur d’autres fonctionnalités. Toutefois, les choses s’améliorent petit à petit.

Ce trimestre, on a vu par exemple arriver la correction d’un problème avec l’utilisation de la touche « echap ». Cette touche peut servir à plusieurs choses:

• Fermer une fenêtre de chargement ou d’enregistrement de fichier,
• Annuler le renommage d’un fichier,
• Annuler une recherche rapide « type ahead » qui consiste à taper quelques lettres et voir immédiatement la liste de fichiers du dossier courant se réduire à ceux qui contiennent cette chaîne de caractères.

Ces différentes utilisations peuvent entrer en conflit. Plus précisément, lorsqu’on utilise le filtrage « type ahead », puis qu’on change d’avis et qu’on appuie sur la touche « echap », il ne faut pas que cela ferme la fenêtre en même temps.

Un autre changement concerne plutôt la validation des données: Tracker interdit l’insertion de caractères de contrôle ASCII dans le nom de fichiers. Ce n’est pas strictement interdit (ni par Haiku, ni par ses systèmes de fichiers, ni par POSIX) en dehors de deux caractères spéciaux: le '/' et le 0 qui termine une chaîne de caractères. Mais, c’est très probablement une mauvaise idée d’avoir un retour à la ligne ou un autre caractère de contrôle enregistré dans un nom de fichier. Le Tracker interdit donc désormais de le faire et si vous êtes vraiment résolu à y parvenir, il faudra passer par le terminal.

Enfin, une nouvelle fonctionnalité dans le Tracker est la mise à jour en temps réel des menus pop-up. Cela peut se produire pour plusieurs raisons, par exemple, l’appui sur la touche « command » modifie le comportement de certains menus. Avant ce changement, il fallait ré-ouvrir le menu (command + clic droit) pour voir ces options modifiées. Maintenant, on peut d’abord ouvrir le menu, puis maintenir la touche command enfoncée pour voir les options modifiées.

Cela a nécessité une refonte complète de la gestion de ces menus (qui proposent de nombreuses autres choses comme la navigation « rayons X »). Au passage, certaines options qui étaient uniquement disponibles au travers de raccourcis claviers ou de la barre de menu des fenêtres du Tracker sont maintenant aussi affichées dans le menu pop-up.

TeamMonitor

TeamMonitor est le gestionnaire d’applications affiché quand on utilise la combinaison de touches Ctrl+Alt+Suppr. Il permet de stopper des programmes, de redémarrer la machine, et autres manipulations d’urgence si le système ne fonctionne pas comme il faut.

Les processus lancés par une même application sont maintenant regroupés et peuvent être tous arrêtés d’un seul coup. Ce changement est nécessaire suite à l’apparition de IceWeasel, qui crée beaucoup de processus en tâche de fond pour une seule instance du navigateur web.

HaikuDepot

HaikuDepot est l’interface graphique pour le système de paquets de Haiku. Il se présente comme un magasin d’applications, permettant non seulement d’installer et de désinstaller des logiciels, mais aussi de les évaluer avec une note et un commentaire.

• Ajout d’un marqueur sur les icônes des paquets qui sont déjà installés, et remplacement du marqueur utilisé pour indiquer les applications « natives » (utilisant le toolkit graphique de Haiku, par opposition à Qt et GTK par exemple).
• Affichage plus rapide de l’état « en attente d’installation » lorsqu’on demande l’installation d’un paquet.
• L’interface pour noter un paquet est masquée si l’attribution de notes n’est pas possible.

Préférences

Diverses améliorations dans les fenêtres de préférences:

• Correction d’un crash dans les préférences d’affichage (korli).
• Les préférences de fond d’écran n’acceptent plus le glisser-déposer d’une couleur sur un contrôle de choix de couleur désactivé. La modification de la position X et Y de l’image de fond se met à jour en temps réel quand on édite la valeur des contrôles correspondants.
• Ajout de réglages supplémentaires (vitesse, accélération, défilement) dans les préférences des pavés tactiles. Ces options étaient déjà implémentées dans l’input_server, mais configurable uniquement pour les souris.
• Suppression de code mort et amélioration de la gestion des polices de caractères dans les préférences d’apparence.

Plusieurs améliorations sur les préférences de sons de notifications:

• La fenêtre de sélection de fichiers retient le dernier dossier utilisé,
• Elle permet également d’écouter un son avant de le sélectionner,
• Les menus de sélection rapide de sons affichent uniquement les fichiers et pas les dossiers,
• Certains sons ont été renommés.

La plupart des sons ne sont cependant toujours pas utilisés par le système.

Expander

Expander est un outil permettant d’extraire plusieurs types de fichiers archivés.

Peu de changement sur cet outil qui est assez simple et fonctionnel. La seule amélioration ce mois-ci concerne un changement des proportions de la fenêtre pour éviter un espace vide disgracieux.

Cortex

Cortex est une application permettant de visualiser et de manipuler les nœuds de traitement de données du Media Kit.

Le composant « logging consumer » qui reçoit des données d’un autre noeud et les enregistre dans un fichier de log pour analyse a été amélioré pour enregistrer un peu plus d’informations.

Icon-O-Matic

L’éditeur d’icônes vectoriels Icon-O-Matic évolue peu, après un projet Google Summer of Code qui a ajouté la plupart des fonctionnalités manquantes. Ce trimestre, un seul changement: l’ajout d’une entrée menu pour supprimer un « transformeur ».

PowerStatus

L’application PowerStatus affiche l’état de la batterie. Cela peut se présenter comme une icône dans la barre des tâches. L’icône est de taille réduite, et les différents états n’étaient pas forcément bien visibles. Ce problème a été corrigé avec des nouveaux marqueurs pour l’état de la batterie (en charge ou inactive).

StyledEdit

StyledEdit est un éditeur de texte simple, permettant tout de même de formater le texte (un peu comme WordPad pour Windows).

L’application reçoit une nouvelle option pour écrire du texte barré. Le code nécessaire a également été ajouté dans app_server, puisque cette possibilité était prévue, mais non implémentée.

WebPositive

Le navigateur WebPositive reçoit peu d’évolutions en ce moment, en dehors de la maintenance du moteur WebKit. On peut tout de même mentionner l’ajout d’un menu contextuel sur les marque-pages, permettant de les renommer et de les supprimer. Ce développement est issu d’un vieux patch réalisé par un candidat au Google Summer of Code, qui ne fonctionnait pas et n’avait jamais été finalisé.

Mode sombre et configuration des couleurs

Depuis la version Beta 5, Haiku dispose d’un nouveau système de configuration des couleurs, permettant d’obtenir facilement un affichage en « mode sombre ». Cependant, cet affichage est loin d’être parfait, et de petits ajustements sont à faire petit à petit dans toutes les applications qui n’avaient pas été pensées pour cela. En particulier, le changement de couleurs se fait en direct lorsqu’on change les réglages. On trouve ces trois derniers mois des changements dans DeskBar, Tracker, HaikuDepot, l’horloge, ainsi que la classe BTextView.

Outils en ligne de commande

pkgman peut rechercher les paquets installés et qui n’ont aucun autre paquet dépendant d’eux. Cela permet de trouver des paquets inutiles qui peuvent être désinstallés (il manque encore la possibilité de marquer un paquet comme étant « installé manuellement » avant de pouvoir automatiser le nettoyage).

La commande route accepte la syntaxe utilisée par openvpn pour la configuration d’une route par défaut, ce qui facilite l’utilisation de VPN avec Haiku.

Correction d’un problème dans le compilateur de ressources: la commande rc -d ne savait pas décompiler la structure app_version des applications Haiku, uniquement le format plus ancien utilisé par BeOS.

La commande screenmode permet maintenant de récupérer la valeur actuelle du réglage du rétro-éclairage (en plus de permettre de changer cette valeur).

Kits

La bibliothèque de fonctions de Haiku est découpée en « kits » qui regroupent un ensemble de classes et de fonctionnalités liées.

Application kit

L’Application Kit permet, comme son nom l’indique, de lancer des applications. Il offre également toutes les fonctionnalités de boucles d’évènements, et d’envoi de messages entre applications et entre composants d’une application.

Correction d’un problème de suppression d’un port dans la classe BApplication.

Debug kit

Le Debug Kit fournit les services nécessaires au Debugger pour débugger une application. Cela consiste d’une part en un accès privilégie à l’espace mémoire d’une application, et d’autre part en outils pour analyser les fichiers ELF des exécutables et bibliothèques.

Le Debug Kit reçoit ce trimestre plusieurs évolutions et corrections permettant le décodage des stack traces dans les programmes compilés avec clang et lld. Par exemple, les fichiers ELF générés par ces outils sont découpés en plusieurs segments, alors que ce n’est pas le cas pour gcc.

Device Kit

Le Device Kit regroupe tout ce qui concerne l’accès direct au matériel et aux entrées-sorties depuis l’espace utilisateur: ports série, accès direct aux périphériques USB, accès aux joysticks et manettes de jeu.

Les ports série RS232 peuvent être configurés avec des valeurs en baud personnalisées (pour l’instant uniquement pour les adaptateurs série USB).

Interface kit

L’Interface Kit regroupe tout ce qui concerne l’affichage de fenêtres et de vues à l’écran et les interactions avec ces fenêtres.

• Ajout de constructeur « move » et d’opérateur d’assignation pour BRegion et BShape pour améliorer les performances en évitant les copie d’objet immédiatement suivies de suppression.
• Ajout d’un constructeur pour BRect avec deux arguments (largeur et hauteur) pour les rectangles alignés en haut à gauche ou dont la position n’a pas d’importance.
• Remise en place d’un cas particulier dans BBitmap::SetBits pour la gestion du canal alpha afin d’avoir un comportement plus proche de celui de BeOS.
• BColorControl réagit correctement et déclenche les évènements nécessaires lorsqu’on modifie sa couleur par glisser-déposer.

Media Kit

Correction d’une assertion vérifiant la mauvaise condition dans BTimeSource.

Réécriture de la classe BTimedEventQueue pour améliorer ses performances en évitant d’allouer de la mémoire dynamique.

Amélioration de l’affichage des « media controls » (sliders de contrôle de volume par exemple) en mode sombre.

libshared

La « libshared » contient plusieurs classes expérimentales, en cours de développement, mais déjà utilisées par plusieurs applications. Il s’agit d’une bibliothèque statique, ce qui permet de changer facilement son contenu sans casser l’ABI des applications existantes.

Ajout de la classe ColorPreview qui existait en plusieurs exemplaires dans le code de Haiku (préférences d’apparence et Terminal). Cette classe permet d’afficher une couleur dans un petit rectangle. Elle est utilisée à plusieurs endroits dans des contrôles de choix de couleur plus complexes, tels que des listes ou des menus.

Servers

Les servers sont des processus systèmes implémentant différentes fonctionnalités de Haiku. Le concept est similaire à celui des daemons dans UNIX, ou des services dans Windows NT et systemd.

app_server

L’app_server s’occupe de l’affichage des applications à l’écran.

Suppression de code inutilisé depuis longtemps permettant l’accélération matérielle d’opérations de dessin en 2D (blit, tracé de lignes, remplissage de rectangles…).

Sur les cartes graphiques PCI, ces opérations étaient souvent réalisées plus rapidement par le CPU qui tourne à une fréquence bien plus rapide que la carte. Sur les cartes AGP, l’accès en lecture à la mémoire vidéo par le CPU est très lent, et il était donc plus intéressant de faire ces opérations en RAM centrale avant d’envoyer un buffer prêt à afficher à la carte graphique. Enfin sur les cartes PCI express modernes, ces fonctions d’accélération ont disparu ou en tout cas n’ont pas du tout une interface compatible avec les besoins de Haiku. Il est donc temps de jeter ce code.

Modification de la façon dont les applications récupèrent la palette de couleurs en mode graphique 256 couleurs: elle utilise maintenant une mémoire partagée, et il n’est plus nécessaire que chaque application demandent au serveur graphique d’en obtenir une copie.

input_server

L’input_server se charge des entrées souris et clavier. Cela comprend les méthodes d’entrée de texte (par exemple pour le Japonais) ainsi que des filtres permettant de manipuler et d’intercepter ces évènements d’entrée avant leur distribution dans les applications.

Améliorations du filtre PadBlocker pour bloquer le touchpad quand le clavier est en cours d’utilisation sur les PC portables: gestion des répétitions de touches, blocage uniquement du touchpad et pas des autres périphériques de pointage.

net_server

Le net_server se charge de la configuration des interfaces réseau.

Arrêt du client d’autoconfiguration (DHCP par exemple) lors de la perte du lien sur un port Ethernet, pour ne pas essayer d’envoyer des paquets alors que le câble est débranché.

notification_server

notification_server se charge de l’affichage de panneaux de notification pour divers évènements tels que la connexion et déconnexion d’interfaces réseau, un niveau dangereusement bas de la batterie, la fin d’un téléchargement…

La fenêtre de notification a été retravaillée pour mieux s’adapter à la taille de police d’affichage choisie par l’utilisateur.

mail_daemon

mail_daemon permet d’envoyer et de recevoir des e-mails. Les messages sont stockés sous forme de fichiers avec des attributs étendus pour les métadonnées (sujet, expéditeur…). Plusieurs applications clientes permettent de rédiger ou de lire ces fichiers. Ainsi chaque application n’a pas besoin de réimplémenter les protocoles IMAP ou SMTP.

Amélioration de la fenêtre de logs pour la compatibilité avec le mode sombre.

runtime_loader

Le runtime_loader est l’outil qui permet de démarrer un exécutable. Il se charge de trouver toutes les bibliothèques partagées nécessaires et de les placer dans la mémoire.

Ajout du flag PF_EXECUTE qui rend exécutable uniquement les sections ELF qui le nécessitent (auparavant, toutes les sections qui n’étaient pas accessibles en écriture étaient exécutables). Cela est utilisé en particulier par clang, qui sépare une zone en lecture seule (pour les constantes) et une autre en lecture et exécution (pour le code). Avec gcc, les deux sont habituellement regroupées dans la même section.

Drivers

Périphériques de stockage

Correction de bugs dans la couche SCSI (utilisée également pour d’autres périphériques de stockage qui encapsulent des commandes SCSI). Des drapeaux d’état n’étaient pas remis à 0 au bon moment, ce qui causait des kernel panic avec le message « no such range! ».

Cela a été l’occasion de faire du ménage : suppression de champs inutilisés dans des structures de données, et suppression du module d’allocation mémoire locked_pool qui n’était utilisé que par la pile SCSI. À la place, utilisation des fonctions d’allocation mémoire standard du noyau, qui sont amplement suffisantes pour répondre aux besoins de ce module (waddlesplash).

Cartes son

Correction d’erreurs dans le code de gestion mémoire des pilotes es1370 et auvia. Ces drivers utilisaient deux copies d’un code d’allocation identique, mais avaient divergé l’un de l’autre. Ils ont été réunifiés mais cela a provoqué quelques régressions, avec des difficultés pour trouver des machines permettant de tester chacune des cartes son concernées. Haiku peut heureusement compter sur des utilisateurs « avancés » qui testent régulièrement les nightly builds pour détecter ce type de régression (korli).

Réseau

Correction d’une fuite mémoire lors de l’utilisation de sockets « raw » permettant d’envoyer et de recevoir directement des paquets ethernet (en contournant la couche IP).

Pilotes FreeBSD

Une grande partie des pilotes de carte réseau de Haiku sont en fait ceux de FreeBSD ou d’OpenBSD. Une couche de compatibilité permet de réutiliser ces pilotes avec très peu de changement dans leur code source. Ainsi, les évolutions et corrections peuvent être partagées avec l’un ou l’autre de ces systèmes. La collaboration avec les *BSD pour les pilotes réseau se passe de mieux en mieux : suite au développement d’une couche de compatibilité permettant d’utiliser les pilotes OpenBSD dans Haiku, les développeurs de FreeBSD étudient la possibilité de réutiliser également ces pilotes. De plus, les développeurs de Haiku et d’OpenBSD sont en contact pour coordonner les mises à jour et les tests.

Génération de statistiques plus fiables sur les paquets réseaux dans la couche de compatibilité FreeBSD et remontée des statistiques générées par les pilotes associés.

Synchronisation du pilote realtekwifi avec la version de FreeBSD et reconnaissance d’un identifiant de périphérique USB supplémentaire dans ce pilote.

Amélioration de la couche de compatibilité pour se comporter plus précisément comme FreeBSD, et suppression de patchs correspondants dans les pilotes qui sont devenus superflus.

Amélioration des performances de la couche de compatibilité: retrait de comparaisons de chaînes de caractères et d’allocations inutiles.

Pilotes spécifiques à Haiku

Amélioration du comportement du pilote USB RNDIS (partage de connexion sur USB de certains téléphones Android) lorsque le câble USB est déconnecté. Le pilote incluait du code pour tenter de restaurer la connexion existante si le même appareil est reconnecté, mais les périphériques RNDIS utilisent des adresses MAC aléatoires qui changent à chaque connexion, donc cela ne pouvait pas fonctionner. De plus, certains transferts USB n’étaient pas correctement annulés pour laisser la pile USB dans un état propre après la déconnexion du périphérique.

USB

Ajout d’une annulation de transferts de données en attente dans le pilote pour les périphériques de stockage USB, ce qui corrige un kernel panic lors de l’utilisation de lecteurs de disquettes USB. Arrêt immédiat des opérations (au lieu de ré-essayer pendant quelques secondes) si le périphérique indique « no media present » (CD ou disquette éjectée de son lecteur par exemple).

Ajout d’une vérification de pointeur NULL et de libération de mémoire manquantes dans la pile USB, ce qui corrige des fuites de mémoires (qui étaient là depuis longtemps) et une assertion qui se déclenchait (introduite plus récemment).

Le pilote de webcam UVC est mis à jour pour utiliser des constantes (identifiants de types de descripteurs…) partagées avec le reste du système au lieu de toutes les redéfinir une deuxième fois. L’affichage des descripteurs dans listusb est également complété pour décoder toutes les informations disponibles. Le pilote n’est toujours pas complètement fonctionnel: l’établissement des transferts au niveau USB fonctionne, mais pour l’instant le pilote ne parvient pas à décoder les données vidéo reçues correctement.

Le pilote HID sait reconnaître les « feature reports », qui permettent de configurer un périphérique. Par exemple, cela peut permettre de configurer un touchpad en mode multi-point (dans lequel le système doit effectuer lui-même le suivi de chaque doigt sur la surface tactile pour convertir cela en mouvements de pointeur de souris) ou en mode émulation de souris (où on ne peut utiliser qu’un doigt à la fois, mais avec un pilote beaucoup plus simple).

Le pilote pour les tablettes Wacom reconnaît la tablette CTH-470.

PS/2

Les ports PS/2 ont disparu de la plupart des machines ces dernières années, mais le protocole reste utilisé pour le clavier des ordinateurs portables, ainsi que pour certains touchpads. Malheureusement, le protocole est seulement émulé au niveau de l’« embedded controller » (le microprocesseur qui se charge de l’interfaçage de divers composants annexes). Le résultat est que l’implémentation du protocole et des registres d’interface peut s’éloigner considérablement des documents officiels.

Amélioration de la détection des contrôleurs PS/2 supportant le protocole « active multiplexing » permettant de connecter à la fois une souris et un touchpad. La procédure de détection officielle peut générer des faux positifs: certains contrôleurs répondent bien à cette commande, mais n’implémentent en fait pas du tout le protocole. Cela provoquait un long délai au démarrage alors que le pilote tente d’énumérer des périphériques de pointage qui n’existent pas. Une vérification supplémentaire après l’activation du mode multiplexé permet de détecter ce cas.

virtio_pci

virtio est un standard matériel pour les machines virtuelles. Plutôt que d’émuler un vrai matériel (carte réseau, carte graphique…), une machine virtuelle peut émuler un matériel qui n’a jamais été fabriqué, mais dont la programmation est beaucoup plus simple. Cela permet également des opérations inimaginables sur du matériel réel, comme la possibilité de changer la taille de la RAM en cours d’exécution pour mieux partager la mémoire de l’hôte entre différentes machines virtuelles.

Le pilote virtio_pci est à la racine du système virtio. Il détecte la « carte PCI » virtio et implémente les primitives de base d’envoi et de réception de messages entre l’hôte et la machine virtualisée (du côté virtualisé, pour le côté hôte, c’est le virtualisateur, par exemple QEMU, qui s’en charge).

Correction de plusieurs problèmes avec les numéros de files virtio qui rendaient les pilotes instables.

ACPI

ACPI est un cadriciel pour la gestion de l’énergie et l’accès au matériel. Le fabricant du matériel fournit (dans la ROM du BIOS) un ensemble de « tables » contenant une description du matériel disponible, ainsi que des méthodes compilées en bytecode pour piloter ce matériel. Le système d’exploitation doit fournir un interpréteur pour ce bytecode, puis réaliser les entrées-sorties vers le matériel demandé lors de l’exécution.

Haiku utilise actuellement ACPICA, une bibliothèque ACPI développée principalement par Intel.

Correction d’un problème d’accès à de la mémoire non cachée. Une modification faite pour les machines ARM a déclenché un problème sur les machines x86.

Sondes de température

Ajout d’un nouveau pilote amd_thermal, ajout de ce dernier ainsi que des pilotes pch_thermal et acpi_thermal dans l’image disque par défaut. Ces pilotes devraient permettre de récupérer la température du processeur sur la plupart des machines. Il reste maintenant à intégrer cela dans les outils en espace utilisateur pour faire un bon usage de ces informations.

Pilotes graphiques

Ajout de deux nouvelles générations de cartes graphiques dans le pilote intel_extreme.

Le pilote VESA est capable de patcher le BIOS de certaines cartes graphiques à la volée pour y injecter des modes graphiques supplémentaires (la spécification VESA permettant à l’OS uniquement de choisir un mode parmi une liste fournie par la carte graphique, liste souvent assez peu fournie). Ce mode est désormais activé par défaut sur les cartes graphiques où il a pu être testé avec succès.

Systèmes de fichiers

FAT

FAT est un système de fichier développé par Microsoft et qui remonte aux premiers jours de MS-DOS. Il est encore utilisé sur certaines clés USB et cartes SD, bien que exFAT tend à le remplacer petit à petit. Il est également utilisé pour les partitions systèmes EFI.

Le pilote de Haiku a été récemment réécrit à partir de celui de FreeBSD. L’amélioration de ce nouveau pilote se poursuit, avec ce mois-ci :

• Les noms de volumes FAT sont convertis en minuscules comme le faisait l’ancien pilote FAT,
• Le cache de blocs implémente maintenant un mécanisme de prefetch pour récupérer plusieurs blocs disque d’un coup, et le pilote FAT utilise cette nouvelle possibilité pour améliorer en particulier le temps de montage,
• Correction de problèmes dans le cache de fichiers si deux applications accèdent au même fichier mais avec des noms différents par la casse (le système de fichier ignorant ces différences).

BFS

BFS est le système de fichier principal de BeOS et de Haiku. Il se distingue des autres systèmes de fichiers par une gestion poussée des attributs étendus, avec en particulier la possibilité de les indexer et d’effectuer des requêtes pour trouver les fichiers correspondants à certains critères.

Clarification de la description des options disponibles lors de l’initialisation d’un volume BFS.

Correction des fonctions d’entrées/sorties asynchrones pour référencer correctement les inodes, ce qui corrige un très ancien rapport de bug. Des corrections similaires ont été faites également dans les pilotes FAT et EXFAT.

Correction des requêtes sur l’attribut « dernière modification », et amélioration de la gestion du type « time » pour éviter les conversions inutiles (ce type d’attribut est historiquement stocké en 32 bits mais migré en 64 bits lorsque c’est possible pour éviter le bug de l’an 2038, aussi le code doit être capable de traiter ces 2 formats de stockage).

packagefs

Le système de fichier packagefs est au centre de la gestion des paquets logiciels dans Haiku. Les paquets ne sont pas extraits sur le disque, mais montés dans un système de fichier spécifique (qui implémente une version tout-en-un de ce qui pourrait être réalisé sous Linux avec squashfs et overlayfs).

Ce système de fichier se trouve donc sur le chemin critique en termes de performances, ce qui fait que même de petites optimisations peuvent déboucher sur de gros gains de performance.

Optimisation de la gestion de la mémoire: utilisation d’un allocateur dédié pour allouer et désallouer très rapidement de la mémoire de travail avec une durée de vie courte.

Ajout d’une vérification manquante sur la présence du dossier parent, qui pouvait déclencher un kernel panic.

NFS4

Le pilote NFS4 permet de monter des partages réseau NFS. Cependant, le pilote ne fonctionne pas toujours, et certains utilisateurs doivent se rabattre sur le pilote NFS v2 (ancienne version du protocole de moins en moins utilisée), ou encore sur des systèmes de fichiers FUSE comme SMB ou sshfs.

Le pilote NFS4 peut maintenant être compilé avec userlandfs (équivalent de FUSE pour Haiku) pour s’exécuter en espace utilisateur. Cela facilitera le déboguage.

ramfs et ram_disk

ram_disk est un périphérique de stockage qui stocke les données en RAM, il a une taille fixe et doit être formaté avec un système de fichiers avant de pouvoir être utilisé.
ramfs est un système de fichier stockant les données directement en RAM sans passer par un périphérique de stockage de type bloc. Sa taille est dynamique en fonction des fichiers qui sont stockés dedans.

Ces deux pilotes ont reçu divers nettoyages et corrections, suite à des problèmes mis en évidence par des assertions ajoutées précédemment dans le code.

Dans le ramfs, nettoyage de code dupliqué, réduction de la contention sur les verrous, amélioration de la fonction readdir pour retourner plusieurs entrées d’un coup au lieu de les égréner une par une.

Ajout de la gestion des fichiers « spéciaux » (FIFOs nommés, sockets UNIX) dans ramfs.

Autres

Refonte de l’algorithme de « scoring » des requêtes sur les systèmes de fichiers. Cet algorithme permet d’estimer quels sont les termes de la requête les moins coûteux à évaluer, afin de réduire rapidement le nombre de fichiers répondant aux critères, et d’effectuer les opérations complexes seulement sur un petit nombre de fichiers restants. Les requêtes s’exécutent ainsi encore plus rapidement (waddlesplash).

Réécriture du code pour identifier les partitions dans mount_server. Ce code permet de re-monter les mêmes partitions après un redémarrage de la machine, mais l’ancien algorithme pouvait trouver de faux positifs et monter des partitions supplémentaires (OscarL et waddlesplash).

Correction d’une option de debug pour intercepter les accès aux adresses non initialisées (0xcccccccc) ou déjà libérées (0xdeadbeef). Cela permet de détecter certains accès à des pointeurs invalides. Cette option ne fonctionnait correctement que sur les systèmes 32 bit, maintenant, l’adresse correspondante pour les machines 64 bit est également protégée.

libroot

La libroot est la librairie C de base de Haiku. Elle regroupe les fonctions parfois implémentées dans les libc, libm, libpthread, librt et libdl pour d’autres systèmes. Haiku choisit une approche tout-en-un, car il est excessivement rare qu’une application n’ait pas besoin de toutes ces bibliothèques.

Du fait de la grande diversité des services rendus par cette bibliothèque, il est difficile de présenter les changements de façon cohérente et organisée.

Correction de quelques cas particuliers dans le traitement des tableaux de descripteurs de fichiers pour select() et déplacement d’une partie des définitions de sys/select.h vers des en-têtes privés non exposés aux applications (waddlesplash).

Ajout d’une fonction manquante dans les « stubs » de la libroot, qui sont utilisés lors de la compilation de Haiku en mode « bootstrap » (sans aucune dépendance précompilée externe). Les stubs sont normalement générés à l’aide d’un script, mais celui-ci n’avait pas pris en compte une fonction nécessaire seulement sur les architectures x86.

Poursuite du travail d’unification des fonctions de manipulation des temps d’attentes pour toutes les fonctions de la libroot qui peuvent déclencher un timeout. Correction d’un cas où la fonction pthread_testcancel retournait NULL au lieu de la valeur attendue PTHREAD_CANCELED.

Optimisation de la fonction strcmp, remplacement d’autres fonctions avec de meilleures implémentations provenant de la bibliothèque C musl.

Compatibilité POSIX-2024

La spécification POSIX Issue 8 a été publiée et comporte de nombreux changements. Après la version 7, la façon de travailler est devenue plus ouverte, avec un outil de suivi de bugs permettant de proposer des améliorations. Cela conduit à la standardisation de nombreuses extensions qui sont communes entre les systèmes GNU et BSD, rendant plus facile d’écrire du code portable entre tous les systèmes compatibles POSIX.

• Ajout de fonctions qui ouvrent des descripteurs de fichiers avec le drapeau O_CLOEXEC activé par défaut (dup2, pipe3)
• Ajout de reallocarray (un mélange de calloc et realloc)
• Ajout de memmem (recherche d’une suite d’octets dans une zone de mémoire)
• Ajout de mkostemp
• Ajout de posix_devctl et modifications de l’implémentation de ioctl
• Ajout de pthread_getcpuclockid pour mesurer le temps CPU consommé par un thread
• Ajout de la constante d’erreur ESOCKTNOSUPPORT bien qu’elle ne soit jamais utilisée (cela facilite le portage d’applications qui attendent l’existence de ce code d’erreur)
• Correction d’une boucle infinie dans pipe2
• Suppression des fonctions *randr48_r des en-têtes publics. Il s’agit d’une extension disponible uniquement dans la glibc, et qui ne devrait donc pas être disponible dans la libroot. Cependant, l’implémentation est conservée pour assurer la compatibilité d’ABI avec les applications existantes.

ioctl et posix_devctl

La fonction ioctl existe depuis le début de UNIX et permet de réaliser des opérations spéciales sur les descripteurs de fichiers (tout ce qui n’est pas une simple lecture ou écriture). En particulier, elle est beaucoup utilisée pour les pilotes de périphériques qui exposent une interface sous forme de fichiers dans /dev.

L’existence de cette fonction était demandée dans la spécification POSIX, mais son fonctionnement n’était pas documenté à l’exception de quelques cas particuliers. La documentation spécifie une fonction avec un nombre d’arguments variable : un numéro de descripteur de fichier, un identifiant de l’opération à effectuer, puis des paramètres qui dépendent de l’opération. On trouve des opérations avec aucun, un, ou deux paramètres.

Dans UNIX et la plupart de ses dérivés, la liste des opérations possibles est définie à l’avance, et le format des numéros identifiants permet de déterminer de façon prédictible quel est le nombre de paramètres attendus. Ce n’est pas le cas dans Haiku : les pilotes de périphériques ont le choix d’assigner n’importe quelle valeur à n’importe quelle opération, et la même valeur numérique peut donc avoir une signification différente selon le type de fichier.

L’opération ioctl est donc en réalité implémentée avec toujours 4 arguments pour Haiku : en plus des deux déjà mentionnés, il faut ajouter un pointeur vers une zone de mémoire, et un entier indiquant la taille de cette zone. Des acrobaties à base de macros permettent de remplir ces deux paramètres avec des valeurs par défaut lorsqu’ils ne sont pas nécessaires (au moins pour les programmes écrits en C ; en C++, ces deux paramètres sont simplement déclarés avec une valeur par défaut).

Heureusement, ces problèmes avec ioctl vont être résolus, puisque POSIX a introduit une nouvelle fonction en remplacement : posix_devctl. Celle-ci fonctionne comme l’implémentation de ioctl dans Haiku, mais les arguments doivent toujours être spécifiés explicitement. Cela va donc permettre de disposer d’une interface réellement portable pour ces opérations.

Kernel

Correction de la taille du tampon mémoire par défaut de la classe KPath qui permet au noyau de manipuler des chemins dans le système de fichiers (waddlesplash).

VFS

Le VFS (virtual filesystem) est l’interface entre les appels systèmes d’accès aux fichiers (open, read, write…) et les systèmes de fichiers proprement dit. En plus de ce travail d’interfaçage (par exemple : convertir un chemin de fichier absolu en chemin relatif à un point de montage), cette couche regroupe un ensemble de fonctionnalités qui n’ont pas besoin d’être réimplémentées par chaque système de fichier: vérification des permissions, mémoire cache pour limiter les accès au disque.

Si les systèmes de fichiers identifient chaque objet par un inode (en général lié à la position de l’objet sur le disque ou dans la partition de stockage), le VFS travaille lui avec des vnode qui existent uniquement en RAM et sont alloués dynamiquement pour les fichiers en cours d’utilisation.

D’autre part, les systèmes de fichiers peuvent se reposer sur un cache de blocs. Ce dernier se trouve plutôt à l’interface entre un système de fichier et le support de stockage correspondant, puisqu’il fonctionne au niveau des blocs de données stockées sur disque. Mais son intégration avec le VFS est nécessaire pour savoir quels sont les fichiers en cours d’utilisation et les opérations prévisibles sur chacun (par exemple, il est utile de pré-charger la suite d’un fichier lorsque un programme demande à en lire le début, car il est probable que ces informations vont bientôt être nécessaires).

Le VFS est donc un élément central en particulier pour obtenir de bonnes performances sur les accès aux fichiers, en minimisant les accès aux vrais systèmes de fichiers qui doivent maintenir beaucoup d’informations à jour sur les disques. Tout ce qui peut être traité en utilisant uniquement la RAM grâce à la mise en cache est beaucoup plus rapide.

Investigation et amélioration des performances de la commande git status qui prenait beaucoup plus de temps à s’exécuter que sur d’autres systèmes (waddlesplash):

• Meilleure gestion des vnodes inutilisés à l’aide d’une liste chaînée 'inline' protégée par un spinlock, à la place d’un mutex peu performant dans ce code très fréquemment appelé.
• Modification de la structure io_context pour utiliser un verrou en lecture-écriture (permettant plusieurs accès concurrents en lecture, mais un seul en modification).
• Ajout d’un chemin rapide dans le cas le plus simple de la recherche de vnode.

Avec ces changements, les performances sont améliorées au moins lorsque les données nécessaires sont déjà disponibles dans le cache disque.

Nettoyage et corrections dans les fonctions d’entrées-sorties vectorisées et asynchrones do_iterative_fd_io et do_fd_io utilisées par les systèmes de fichiers: meilleure gestion des références et prise en compte de certains cas particuliers. Cela permet de simplifier un peu le code de pré-remplissage du cache de blocs (waddlesplash).

La prise en compte des drapeaux O_RDONLY|O_TRUNC lors de l’ouverture d’un fichier est maintenant faite directement dans le VFS, il n’est plus nécessaire de transmettre la requête au système de fichier. Cette combinaison de drapeaux est un comportement indéfini dans POSIX, et supprime le contenu du fichier dans Linux. Dans Haiku, elle remonte une erreur.

Correction du comportement de l’ouverture d’un symlink invalide (ne pointant pas sur un fichier) avec le flag O_CREAT.

Le parser de requêtes pouvait essayer de lire des données invalides (la taille de clé d’un index inexistant) dans certains cas particuliers.

Nettoyage de logs dans tous les systèmes de fichiers qui affichaient un message lors de chaque tentative d’identification. On avait donc un message de chaque système de fichier pour chaque partition. Maintenant, le cas le plus courant (le système de fichier ne reconnaît pas du tout la partition) ne déclenche plus de logs.

Correction d’une erreur dans userlandfs sur la fonction file_cache_read pour les tentatives d’accès après la fin d’un fichier (cas particulier nécessaire pour implémenter correctement mmap).

Correction d’une mauvaise gestion du errno dans le cache de blocs, qui pouvait aboutir à un kernel panic.

Diverses améliorations, nettoyages et corrections de fuites mémoire: dans la gestion des fichiers montés comme image disques, dans les entrées-sorties asynchrones, dans l’enregistreur d’évènements scheduling recorder.

Console et affichage

Unification du code d’affichage du splash screen (par le bootloader) et des icônes de la séquence de démarrage (par le kernel) pour éviter qu’ils prennent des décisions différentes sur le positionnement (par exemple si l’un est compilé pour afficher le logo de Haiku, et l’autre en version « dégriffée » sans ce logo qui est une marque déposée) (waddlesplash).

Initialisation de la console framebuffer beaucoup plus tôt dans le démarrage du noyau, ce qui permet d’afficher un message à l’écran en cas de kernel panic y compris dans les premières étapes du démarrage (par exemple, l’initialisation de la mémoire virtuelle). Auparavant, ces informations étaient disponibles uniquement dans le syslog (inaccessible si le système ne démarre pas) ou via un port série (en voie de disparition sur les machines modernes) (waddlesplash).

Réseau

Remontée des données annexes (ancillary data) en une seule fois lorsque c’est possible. Ces données sont utilisées en particulier dans les sockets de domaine AF_UNIX pour permettre d’échanger des descripteurs de fichiers entre processus. Ce regroupement de données n’est pas exigé par la spécification POSIX, mais c’est le comportement attendu par le code de communication interprocessus de Firefox et de Chromium (ils utilisent tous les deux le même code) (waddlesplash).

Gestion de la mémoire

Comme indiqué plus haut dans la dépêche, l’apparition du navigateur Iceweasel a mis en évidence de nombreux problèmes autour de la gestion de la mémoire. Cela a donc été l’objet d’un gros travail de stabilisation et d’amélioration.

• Le cache d’objets du noyau pouvait parfois ignorer le paramètre indiquant la réserve minimum d’objets devant toujours être disponibles (waddlesplash)
• Amélioration de l’implémentation de la famille de fonctions autour de mprotect, qui permettent une gestion fine et bas niveau de la mémoire. En particulier, plusieurs problèmes se posaient lors de l’utilisation de ces fonctions lors d’un appel à fork, les deux processus se retrouvant dans un état incohérent,
• Suppression de logs présents dans les méthodes de défaut de page, qui sont peu appelées pour les applications classiques, mais exploitées volontairement par d’autres applications (machines virtuelles Java ou Javascript par exemple). Les logs étaient donc superflus dans ce cas (waddlesplash),
• Optimisation de l’écriture par lot de plusieurs pages de mémoire vers le swap,
• Meilleure gestion des permissions d’accès page par page,
• Correction de plusieurs problèmes conduisant à un blocage ou fort ralentissement du système quand il n’y a plus assez de mémoire libre,
• Amélioration de la stratégie d’allocation de la table des descripteurs de fichiers,
• Regroupement de code dupliqué pour chaque plateforme qui était en fait générique.

Ce travail se poursuit avec un remplacement de l’allocateur mémoire actuel, qui est basé sur hoard2. Cette implémentation est assez ancienne et montre aujourd’hui ses limites. Des essais sont en cours avec l’implémentation de malloc d’OpenBSD, ainsi qu’avec mimalloc de Microsoft, pour déterminer lequel des deux sera utilisé. D’autres allocateurs ont été rejetés, car ils ne répondent pas au besoin de Haiku, en particulier la possibilité de fonctionner efficacement sur un système 32 bits ou l’espace d’adressage est une ressource limitée.

Autres

Sécurisation des permissions sur les zones mémoire partagées: une application ne peut pas ajouter des permissions en écriture aux zones mémoire d’une autre application. Une application qui n’est pas lancée par l’utilisateur root ne peut pas inspecter la mémoire d’une application lancée par l’utilisateur root. Ajout toutefois de cas particuliers pour permettre au Debugger de faire son travail (il a besoin d’accéder à la mémoire d’autres applications).

Ajout et amélioration de commandes dans le debugger noyau pour investiguer l’état de l’ordonnanceur d’entrées-sorties, qui se charge de programmer les accès disque dans un ordre le plus efficace possible (waddlesplash).

La fonction vfork n’appelle plus les fonctions pre-fork. Haiku n’implémente pas complètement vfork, mais peut se permettre des optimisations sur le travail qu’un duo fork + exec classique demanderait normalement.

La configuration de la randomization de l’espace mémoire (ASLR) est maintenant faite par la libroot et pas par le noyau. Ainsi une application peut utiliser une version différente de la libroot pour avoir une politique de randomization différente.

Optimisation de l’accès par un thread à sa propre structure Thread

Chargeur de démarrage

L’écran de démarrage s’affiche correctement sur les systèmes EFI utilisant un mode écran avec une profondeur de couleur 16 bits (korli).

Affichage de la taille des partitions démarrables dans le menu de démarrage, pour faciliter leur identification (waddlesplash).

Activation des warnings du compilateur sur les chaînes printf invalides.

Augmentation de la zone de mémoire utilisée pour la décompression de l’archive de démarrage lors du boot sur le réseau, l’archive était devenue trop grosse suite à l’ajout de nouveaux pilotes.

Refactorisation du code de gestion de la mémoire entre le bootloader et le runtime_loader, ajout de tests pour cette implémentation, et optimisation de l’utilisation mémoire du bootloader.

Amélioration du comportement si le device tree définit un port série sans spécifier de baudrate: le bootloader suppose que le baudrate est déjà configuré, et utilise le port sans essayer de le réinitialiser.

Outils de compilation

La compilation de Haiku est un processus relativement complexe: il faut utiliser deux compilateurs pour Haiku lui-même (un gcc récent plus une version plus ancienne pour assurer la compatibilité avec BeOS) ainsi que un compilateur pour le systême hôte de la compilation (qui peut être Linux, BSD, Mac OS ou Windows) pour générer des outils nécessaires à la compilation elle-même. L’outil retenu est Jam, une alternative à Make avec une meilleure gestion des règles génériques réutilisables.

• Ajout de vérification pour éviter d’avoir un build partiellement configuré, avec des ConfigVars définies mais vides.
• Retrait d’un warning incorrect dans l’outil de build jam si on spécifie à la fois un profil et une cible de compilation sur la ligne de commande.
• Reconnaissance des processeurs hôtes ARM et RISC-V pour la compilation croisée, correction d’autres problèmes avec les architectures non-x86.
• Ajout de dépendances manquantes dans les règles de compilation de packagefs.
• Suppression de fichiers de licence fournis avec Haiku mais concernant du code qui avait été supprimé de Haiku auparavant.
• Amélioration de la remontée d’erreur du script configure si un interpréteur Python n’a pas été trouvé.
• Correction de messages d’avertissement de awk pour l’utilisation de fonctions qui n’existent plus dans le traitement des fichiers d’identifiants matériels USB et PCI.

Documentation

Documentation interne

Ajout de documentation sur les détails d’implémentation de ioctl et posix_devctl et les spécificités de Haiku pour la première (PulkoMandy).

Correction de fautes de frappe dans l’introduction au launch_daemon.

Remplacement de toutes les références à "OpenBeOS" par "Haiku".

Documentation d’API

Ajout de documentation pour les méthodes GetFontAndColor et SetFontAndColor de BTextView.

Ajout de documentation pour les classes BShelf et BGameSound.

Réorganisation de la liste des caractères de contrôles dans la documentation du clavier, ajout d’entrées manquantes dans cette liste et ajoute de commentaires indiquant à quelles combinaisons de touches ces caractères sont normalement associés.

Traductions de Haiku

La traduction du système dans différentes langues est un facteur important d’inclusivité et d’accessibilité (même si la communication avec l’équipe de développeurs pour le support n’est pas toujours simple).

Haiku est disponible dans 30 langues, la trentième étant le coréen, pour lequel il y a un nouveau responsable des traductions (le précédent avait cessé toute activité et laissé la traduction inachevée).

Haiku recherche des volontaires pour s’occuper des traductions en biélorusse, croate, bulgare, hindi, punjabi et slovène, pour lesquelles les précédents responsables de relectures n’ont plus le temps d’assurer le rôle. Ainsi bien sûr que de l’aide pour la traduction du système, du manuel d’utilisation, et des applications tierces, que ce soit pour ajouter de nouvelles langues ou pour renforcer les équipes s’occupant de langues existantes. Le point d’entrée est le portail d’internationalisation de Haiku.

La traduction du système Haiku s’effectue avec Pootle. L’outil n’est plus développé et des investigations sont en cours pour le remplacer par Weblate. La traduction du manuel d’utilisation s’effectue avec [un outil spécifiquement développé pour cela](https://github.com/haiku/userguide-translator. La traduction des applications s’effectue également avec un outil personnalisé nommé Polyglot.

Voici une série de vidéos (62) consacrée à la distribution Linux Mint 22 intitulée « Pas à pas pour les débutants ».

Je suis passé à Linux Mint voilà à peu prés cinq ans. J'ai été aidé pour cela par l'équipe Linux de l'époque du Forum SOSPC (Mia, Darksky, Azamos, …).
Animé par cet esprit de partage, j'ai voulu à mon tour rendre la pareille. Je viens donc de terminer une série de vidéos sur Linux Mint 22. De petites vidéos (à part la 1 et la 62) qui traitent chacune d'un thème bien précis. Ces vidéos s'adressent exclusivement à un public de débutants (et faite par un débutant… de 5 ans).

de :

à

Visibles à partir de la liste de vidéos YouTube, d'une durée d'une quinzaine de minutes pour la première et la dernière, quelques minutes pour les autres :

1. C'est quoi Mint ?
2. Possible pour vous ?
3. Télécharger Cinnamon
4. Vérifier avec 7Zip
5. Créer la clé d'installation
6. Créer une clé persistante
7. Graver un DVD
8. Démarrage rapide
9. Edge à Firefox
10. Chrome à Firefox
11. Exporter thunderbird
12. Export carnets d'adresses
13. Export Agenda
14. Ouvrir le BIOS
15. Visite en Français
16. Installation
17. Démarrage et dualboot
18. Veille contrôllée
19. Écran de bienvenue
20. Timeshift
21. Gestionnaire de pilotes
22. Gestionnaire de mise à jour
23. Pare-feu
24. Couleurs du Bureau
25. Une mise à jour
26. Paramètres du système
27. Personnaliser le Bureau
28. Une mise à jour du noyau
29. La Logithèque
30. Flatpack
31. Alternativeto
32. Paramètres du panneau
33. Configuration Liste groupée de fenêtres
34. Ajouter des Applets
35. Mode d’édition du panneau (1)
36. Mode d’édition du panneau (2)
37. Réglage du MENU
38. Applications préférées
39. La corbeille
40. Barre d'outils
41. Ranger les éléments
42. Marque pages
43. Panneau latéral
44. Menus contextuels
45. Imprimante et Scanner
46. Informations système
47. la suite LibreOffice (une petite erreur à corriger)
48. Installer les polices Microsoft sur Linux
49. Capture d'écran et Flameshot
50. PDF Visionneur de document ou Okular
51. La Télévision avec FreetuxTV
52. Thunderbird
53. Carnets d’adresses
54. Agenda
55. Paramètres et paramètres des comptes
56. Injecter le profil de Firefox de Windows dans Linux
57. Sauvegarde des données avec Grsync
58. Gparted renommer le disque de sauvegarde
59. Vider le cache de Linux avec le Terminal
60. Restaurer avec Timeshift
61. Démarrage - enlever ou mettre un mot de passe
62. Petit bilan et conseils

Pour télécharger également le PDF (Pack débutant (partie 1) - Linux Mint 22 - Pas à pas sur YouTube en Libre accès
Sur celui-ci, chaque vidéo est présentée par un petit texte, chaque vignette est active et permet en cliquant dessus de rejoindre la vidéo choisie, la durée de chaque vidéo est indiquée.

Si cela peut intéresser quelqu’un.

Scenari est un ensemble de logiciels open source dédiés à la production collaborative, publication et diffusion de documents multi-support. Vous rédigez une seule fois votre contenu et vous pouvez les générer sous plusieurs formes : site web, PDF, OpenDocument, diaporama, paquet SCORM (Sharable Content Object Reference Model)… Vous ne vous concentrez que sur le contenu et l’outil se charge de créer un rendu professionnel accessible et responsive (qui s'adapte à la taille de l'écran).

À chaque métier/contexte son modèle Scenari :

• Opale pour la formation ;
• Dokiel pour la documentation ;
• Optim pour les présentations génériques ;
• Topaze pour les études de cas ;
• et bien d'autres…

🖥️ Pas de mini-webinaire en février

Les dates des vacances de février compliquent l’organisation d’un mini-webinaire en milieu du mois de février.

On se retrouvera donc le 17 mars à 17h pour le prochain mini-webinaire. On y abordera Parcours-PHP.

💗 Parole de Scenariste

J'utilise Canoprof au lycée pour produire mes séquences et séances de cours, les partager et les faire évoluer avec mes collègues. A l'université, nous proposons aux étudiants en master et DIU enseignement Sciences de la Vie et de la Terre de se familiariser avec un gabarit que nous avons créé pour réaliser des outils professionnels de préparation de séquence et de séances.

Le glossaire nous a permis de mettre à leur disposition des fondamentaux de didactique intégrables directement à leurs préparations. Canoprof facilite grandement la réflexion professionnelle et aide à la formaliser.

Delphine Séchet, Professeure de SVT Lycée de l'Essouriau Les Ulis & formatrice académique MEEF2 SVT université Paris-Saclay.
Modèle utilisé : Canoprof

📣 Rencontres 2025 : Appel à communication - rappel

Rappel !

Tu as jusqu’au 11 mars pour nous envoyer ta proposition de retour d’expérience ou d’atelier à l’adresse rencontres@scenari.org en indiquant :

• nom / prénom des intervenants
• structure (ton université/entreprise/association…)
• titre provisoire
• descriptif provisoire
• éventuelles indisponibilités inéluctables

Partager tes usages de Scenari c’est une occasion pour apporter à la communauté et pour que la communauté t’apporte aussi, alors n’hésite pas à faire une proposition !

Merci de relayer cet appel dans tes réseaux sur Mastodon, Telegram et LinkedIn !

📣 Nouvelle version de Parcours

Une nouvelle version de maintenance de Parcours est disponible : Parcours 1.0.3.

Cette version apporte des corrections et des améliorations.

À noter qu’une version avec de nouvelles fonctionnalités et une ergonomie de l’éditeur simplifiée, basée sur la technologie SCENARI 6.4, est en développement, prévue pour cet été 2025.

📣 Appel à formation en ligne pour doctorants et doctorantes au Maroc

Nous relayons un appel d'un adhérent du Maroc :

« Je suis ravi de vous annoncer que le Laboratoire Larslam lance des formations en ligne destinées à ses doctorants ainsi qu'à ceux des laboratoires partenaires. Ces formations se dérouleront durant les mois de janvier et février 2025, avec des séances programmées chaque samedi de 10h à 12h. D'autres créneaux pourront être proposés selon vos disponibilités.

Votre contribution en tant qu'intervenant à ces formations est cruciale pour doter les futurs docteurs des compétences rédactionnelles, méthodologiques, didactiques et pédagogiques nécessaires à la réussite de leur parcours.

Nous vous offrons la liberté de choisir les thématiques de votre intervention. Pour cela, merci de bien vouloir remplir le formulaire suivant : Formulaire d'inscription. »

Une bonne occasion d'aider à la diffusion de Scenari dans le Maghreb.

En cas de doute contacte Adil, l'auteur de cet appel.

✨ Le savais-tu ?

Sur une configuration serveur (MyScenari ou votre propre serveur standard), il est possible d'exporter la liste des utilisateurs créés.

Il faut aller sur l'url https://####/~~chain/web/u/adminWsp?cdaction=ExportConfig (remplacer « #### » par « [nom de ton instance].scenari-community.org » pour MyScenari, ou par « [url de ton serveur Scenari]/starter » pour une installation serveur standard).

Tu obtiendras un xml.

Ensuite dedans, en faisant par exemple une recherche sur la chaîne « <s k="userType">user</s> », le nombre d’occurrences te donnera le nombre d'utilisateurs créés.

📊 Le chiffre du mois

28, C'est le nombre de nouveaux adhérents depuis les Rencontres Scenari 2025, dont 8 Utilisateurs Personne Morale !

👋 Nouvelles adhésions d'organisations

Souhaitons la bienvenue à :

• Service Départemental d'Incendie et de Secours d'Indre-et-Loire, qui nous a rejoint dans le collège des Utilisateurs Personne Morale. Outil utilisé : :scprocess: Process.

Cette dépêche est issue du journal d'Antoine Catton qui passe en revue le marché des imprimantes 3D à l'occasion verrouillage récent de l'accès à l'impression par le fabricant Bambu Lab.

Plus de détails dans la suite de la dépêche.

Il y a quelques années, je suis tombé dans la marmite de l'impression 3D. Mon employeur nous donne accès à un « makerspace » d'entreprise, en tant qu'avantage en nature. Il y a, entre autres, quelques imprimantes 3D.

Au bout d'un moment, j'en avais marre de ne pouvoir imprimer qu'au boulot, donc j'ai passé le pas. Ch'suis pas dépensier, ch'suis pas fan de bagnoles, ni de foot, j'achète un nouvel ordi tous les 5-6 ans en moyenne, donc j'ai cassé la banque et me suis fait plaisir en m'achetant une imprimante 3D.

Je sais pas si tu sais, mais il y a plusieurs types d'imprimantes 3D. Le type le plus connu, c'est le type « FDM » ou « dépôt de fil fondu » dans la langue de Molière. La meilleure description, c'est « un pistolet à colle chaude sur une table traçante. » Aujourd'hui, c'est ce que la majorité des gens imagine quand on dit « imprimante 3D. » Il y a d'autres types d'imprimantes 3D, comme, par exemple, les imprimantes à résine, qui utilisent un écran LCD ultraviolet pour solidifier de la résine au fond d'un bac de résine liquide. Ces imprimantes 3D sont, en général, utilisées pour imprimer des détails plus fins, surtout pour les otakus qui impriment des figurines de Manga et Animés, entre autres. Dans ce journal, je ne parle que d'imprimantes dites « FDM », c'est-à-dire, « l'imprimante 3D normale, » comme dirait François Hollande.

Je sais pas si tu sais, mais, en gros, y a cinq « marques » principales d'imprimantes 3D pour les « prosumer », comme disent les Américains qui ont la classe. (En françois on pourrait traduire ça par « utilisateur quasi-pro », j'ai aussi vu la traduction « prosommateur », mouais…)

Dans l'ordre de ce que j'estime la plus grosse part de marché à la petite:

• Bambu Lab : un constructeur de Shenzhen, en Chine, j'en parle plus tard dans ce journal.
• Creality : un autre constructeur de Shenzhen, avec les prix parmi les plus bas du marché, pour une qualité médiocre.
• Prusa : un constructeur tchèque, j'en parle plus tard dans ce journal.
• Anycubic : un troisième constructeur de Shenzhen, avec les prix et la qualité qui rivalisent avec Creality.
• Voron : c'est pas vraiment une marque, mais plus une gamme d'imprimantes conçue par des ingénieurs sur leur temps libre. Ils collaborent et publient les plans sur Internet, le tout sous licence libre. Si tu veux une imprimante de cette marque, il faut commander les pièces individuellement sur Amazon, Alibaba & Cie. Ya aussi des entreprises qui vendent des kits à assembler, comme chez Ikea, si tu veux pas trop t'embêter. La qualité des kits est… variable, on va dire.

Si t'es comme moi, et que tu traînais dans les salons Linux et les conférences de logiciels libres ya 10-15 ans, je sais pas si tu te rappelles, y'avait toujours le geek du coin qui voulait se la raconter. Le mec ramenait son imprimante 3D pour la montrer, comme d'autres montrent leur Porsche dans les salons auto. C'était toujours une imprimante avec un châssis en contreplaqué, découpé au laser, et avec « Ultimaker » ou « Makerbot » écrit dessus, brûlé au laser. Tu t'souviens ? Eh bien, ces marques ont fusionné, maintenant, ils ne vendent que des imprimantes 3D professionnelles à plus de 5 000 €.

Bref, pour en revenir à nos marques, je sais pas si t'as remarqué, mais la plupart sont de Shenzhen. C'est pas une coïncidence : Shenzhen, c'est La Mecque du composant électronique. Des servomoteurs ? Des circuits imprimés ? Tu trouves ça sur le marché local du coin pour faire du prototypage. Et, une fois que je veux fabriquer, ya 100 usines qui sont prêtes à mettre en production ton projet. Voilà pourquoi il est bien normal que ce soit plus facile pour un constructeur d'imprimante 3D de faire tourner une entreprise sur place, quand ses fournisseurs sont à 30 min de trajet.

En dehors de Voron, y'a un constructeur qui sort du lot : Prusa. Alors, je suis partial, je suis fan de ce constructeur. Ils étaient parmi les premiers, après Ultimaker et Makerbot, à vendre des imprimantes 3D directement aux bidouilleurs en tout genre. Au début, c'était un mec dans son garage qui achetait des pièces détachées en gros, et les mettait en détail dans des kits qu'il revendait. C'était l'esprit RepRap. Depuis, ils ont grossi et utilisent leurs propres imprimantes pour imprimer les pièces en plastique des imprimantes qu'ils vendent. Beaucoup de leurs composants, surtout électroniques, viennent de Chine, mais ils disent qu'ils essaient de faire marcher au max des fabricants européens.

Au fil des années 2010-2020, Prusa est devenu la référence de l'imprimante quasi-pro de qualité. Pendant cette période, Prusa a fait évoluer son imprimante petit à petit. Certaines pièces peuvent être imprimées avec l'imprimante pour que les utilisateurs puissent profiter des mêmes améliorations que les nouvelles imprimantes vendues. Une fois tous les 2 ou 3 ans, ils sortent une nouvelle version majeure de leur imprimante et vendent des kits à bas coût. Ça permet aux anciens clients de pouvoir moderniser leur imprimante. C'est l'esprit bidouille et réparabilité.

Petit aparté : pour imprimer en 3D, il te faut un modèle 3D, ça va de soi. Mais, il te faut aussi un « slicer », en bon français, un « logiciel de découpage en tranches ». Ce logiciel convertit le modèle 3D en instructions physiques pour l'imprimante 3D : « va 2cm à droite, 5cm vers l'avant, etc. » On appelle ça du découpage en tranche, parce que ces instructions physiques permettent d'imprimer les couches successives de plastique.

J'en parle, parce que ce qui a contribué significativement à l'ascension de Prusa comme référence pour l'impression, c'est son slicer. Ils ont très rapidement forké un logiciel libre sous AGPL : Slic3r. Ils l'ont amélioré grandement pour que les utilisateurs puissent profiter de leur imprimante au mieux.

Très rapidement, Prusa Slicer est devenu la référence du logiciel de découpage en tranche, au côté de Ultimaker Cura.

Mais, soudain, en 2020, un nouveau constructeur apparaît ! Bambu Lab.

C'est le chamboulement ! Le nouveau constructeur vend une imprimante avec une qualité d'impression aussi bonne que Prusa, mais avec une vitesse supérieure incomparable, pour 900 € au lieu de 1 500 € chez Prusa. À ce prix-là, il y a aussi plus d'accessoires que Prusa. La Bambu Lab P1S vient avec un boîtier et un filtre à air d'origine (Le boîtier chez Prusa est dans les 300 € de plus et le filtre à air un peu en dessous de 100 € chez Prusa).

C'est un carnage : le monde des « makers » se retourne contre Prusa et ne fait l'éloge que de Bambu Lab. Prusa est comparé à Blackberry et Nokia qui ont loupé le tournant du smartphone. Prusa est critiqué à chaque tournant.

Pendant ce temps-là, les libristes et les makers originaux se sentent mal. Bambu Lab est l'iPhone de l'imprimante 3D. L'imprimante est fabriquée en grosses séries, avec du plastique moulé par injection.

L'entreprise a forké Prusa Slicer, et a renommé le tout « Bambu Studio ». C'est dans leur droit, le logiciel est libre. Ils ont préservé la licence, et précisent bien dans leur README que c'est une reprise de Prusa Slicer. Jusque-là, tout va bien. Il n'y a pas réellement de fonctionnalité supplémentaire par rapport à Prusa Slicer, mais ils ont implémenté la compensation de la résonance. C'est compréhensible, c'est ça qui leur permet d'imprimer aussi vite, et à l'époque Prusa Slicer n'avait pas cette fonctionnalité.

Le problème, c'est la partie impression… Bambu Lab promeut « le cloud. » Pour imprimer, il faut envoyer le modèle 3D sur des serveurs avec logiciel proprio, en dehors de l'Europe. L'imprimante se connecte aux mêmes serveurs et reçoit les instructions pour l'impression. Les gens s'en foutent, ce qui importe, c'est que ça marche et que l'interface utilisateur soit facile et harmonieuse ! On peut même imprimer depuis son téléphone, dis-donc !

Tu dois te demander, pourquoi je te raconte tout ça ? Bein voilà… Il y a quelques jours, Bambu Lab a fait une mise à jour du logiciel interne de ses imprimantes. Ils prétendent que, pour des raisons de sécurité, ils ont dû verrouiller l'accès à l'impression. Maintenant, si tu veux imprimer avec ta Bambu Lab, de ce que j'ai compris, tu ne peux passer que par l'appli proprio « Bambu Connect » qui utilise des clés de chiffrement privées. Si j'étais dans les théories du complot, je dirais que ça sent la fermeture à distance d'un produit acheté.

C'est le fameux Bait-and-Switch, comme Gandi. Bientôt, je vais être connu sur DLFP comme la moule qui dénonce les tromperies sur marchandises.

Bref, j'ai acheté une Prusa, donc je m'en contrefiche. Mais, y'a deux ans, les gens me prenaient pour un loser qui avait encore un BlackBerry en 2010. Maintenant, je biche.

Si t'es affecté, il y a des guides pour contourner les mesures techniques de « protection ».

Sinon, si t'as pas d'imprimante, mais après cette dépêche tu réfléchis à t'en acheter une, tu dois te demander : j'achète quoi ?

Avertissement : je suis un fanboy de Prusa, donc je suis pas impartial. Fais-toi ta propre idée. Je n'ai aucun lien financier direct ou indirect avec ces constructeurs, à part avoir été acheteur d'une Prusa MK4, qui a été modernisée en MK4S depuis.

• Si tu fais attention à tes dépenses et que tu veux pas trop acheter de la crotte, regarde du côté de la Creality Ender-3. C'est principalement proprio, c'est pas la meilleure qualité, mais une bonne affaire pour le prix. Il y a une grosse communauté qui propose des améliorations avec les moyens du bord.
• Si tu veux pas t'embêter, et que t'es prêt à mettre de l'argent, et que tu veux quelque chose à 80% ouvert et de bonne qualité, je conseillerai la Prusa MK4S pré-assemblée, avec l'option boîtier. Achète l'option filtre plus tard si besoin. Je sais que la Prusa Core One a été annoncée, mais personne ne l'a encore testée. Moi, j'attendrais le résultat des tests de consommateurs avant de juger.
• Si t'es prêt à mettre plus d'argent, un ou deux week-ends d'assemblage, que tu veux quelque chose de presque totalement ouvert et de bonne qualité, il y a la Voron 2.4. Il va falloir que tu trouves un kit de qualité si tu veux pas acheter les pièces individuellement. Si tu veux pas trop te prendre la tête, regarde la Rat Rig V-Core 4 en kit à assembler sois-même. C'est une boite portugaise, c'est pas une Voron 2.4, mais c'est similaire et le kit arrive avec tout (Contrairement à la plupart de kits de Voron qui te demandent d'imprimer les pièces en plastique toi-même).

En tout cas, si t'es libriste, j'espère que je t'ai empêché d'acheter une Bambu Lab.

J'ai mis aucun lien vers les constructeurs pour éviter la pub, mais votre moteur de recherche vous mènera au bon site.

Note: même si je ne suis pas journaliste, et que le droit de réponse ne s'applique pas, Bambu Lab a communiqué sur l'affaire. Je met un lien pour être fair-play.

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 3.0 RC2 du 27 décembre 2024 (en anglais).

Après la première série de retours de la communauté, nous sommes heureux de partager la deuxième version candidate de GIMP 3.0 ! Les gens nous ont donné des commentaires très utiles sur la première version candidate et nous avons pu corriger de nombreux bugs.

C’est notre petit cadeau sous le sapin 🎄 pour vous tous ! (NdM: disons fourré dans la galette/le gâteau des rois désormais ?)

Écran de démarrage de la nouvelle version candidate, par Sevenix (CC by-sa 4.0) - GIMP 3.0 RC2

Sommaire

• Corrections de bugs importantes
  • Migration des paramètres de la 2.10
  • Console Windows
  • Problèmes de polices d’interface utilisateur manquantes sur macOS
  • Intégration de darktable
• Améliorations
  • API de filtre GEGL
  • Espaces de fusion de calques et composition dans les fichiers XCF
  • Paquets
    • AppImage
    • Flatpak
  • Améliorations du greffon BMP
  • Mises à jour diverses
• Aperçu des changements depuis la version 2.10
• GEGL
• Statistiques de sortie
• Autour de GIMP
  • Miroirs de téléchargement
    • Comment devenir un miroir officiel (mise à jour de la procédure)
    • Changements dans les miroirs
  • Financer des exécuteurs ("runner") GitLab
• Télécharger GIMP 3.0 RC2
• Et ensuite ?

Corrections de bugs importantes

Plusieurs correctifs ont été apportés depuis la version RC1. Nous souhaitons mettre en évidence les bugs les plus importants afin que les utilisateurs en soient informés et puissent effectuer des tests supplémentaires. Pour plus de détails sur les autres correctifs de bugs, veuillez consulter notre page NEWS sur GitLab.

Migration des paramètres de la 2.10

Lors des tests communautaires, nous avons découvert que les paramètres des utilisateurs de la 2.10 n’étaient pas migrés vers GIMP 3.0 en raison de certaines hypothèses incorrectes dans le code d’importation. Étant donné que la plupart des développeurs utilisent exclusivement GIMP 3.0 depuis un certain temps, nous n’avions pas remarqué ce problème. Le bug devrait maintenant être corrigé, nous demandons donc des rapports de bugs si des préférences 2.10 ne sont pas importées correctement dans RC2. Notez que si vous avez déjà utilisé 3.0 RC1, vous devrez d’abord supprimer ces configurations, sinon RC2 n’essaiera pas d’importer les préférences 2.10 (assurez-vous de sauvegarder vos paramètres bien sûr !).

Console Windows

Dans les versions de développement 2.99, les versions Windows lançaient automatiquement un affichage de console en plus de GIMP lui-même. C’est très utile pour les développeurs Windows pour voir les messages de débogage, mais la console n’était pas destinée à être affichée pendant les versions stables. Comme nous avons modifié notre processus de construction pour utiliser Meson au lieu d’Autotools, nous avons appris que nous devions apporter des modifications supplémentaires pour empêcher l’affichage de la console. Cela devrait être corrigé maintenant grâce à Jehan - si vous voyez toujours la console sous Windows, veuillez remplir un nouveau rapport de bogue !

Problèmes de polices d’interface utilisateur manquantes sur macOS

Il y a un problème de longue date où certains utilisateurs de macOS ne voyaient que des symboles « Unicode manquants » au lieu des textes d’interface dans GIMP (à la fois dans la version 2.10 et dans la version 3.0). Cela était dû à un bug dans Pango, la bibliothèque que nous utilisons pour les mises en page de texte. Ce problème a été résolu avec la récente version Pango 1.55.0, nous encourageons donc tous les empaqueteurs macOS tiers à mettre à jour vers cette version lorsqu’ils construisent GIMP pour le distribuer.

Si vous aviez ce problème de polices cassées sur macOS (à gauche), il est désormais résolu (à droite) - captures d’écran de rapporteurs de bug - GIMP 3.0.0 RC2

Intégration de darktable

Après la sortie de la version 3.0 RC1, nous avons reçu des rapports de certains utilisateurs indiquant qu’ils ne pouvaient toujours pas importer et exporter d’images entre GIMP et darktable. Nous avons travaillé avec les développeurs de darktable pour éliminer les bugs restants, de sorte que l’intégration entre darktable 5.0.0 et GIMP 3.0 RC2 devrait désormais fonctionner pour tout le monde. Cependant, veuillez déposer un nouveau rapport de bogue si vous continuez à rencontrer des problèmes pour connecter les deux !

Améliorations

Bien que l’objectif principal du développement de la version 3.0 RC2 ait été la correction de bugs et le peaufinage, certaines nouvelles fonctionnalités ont également été implémentées.

API de filtre GEGL

De nombreux anciens wrappers d’API pour les opérations GEGL ont été supprimés dans la version RC1. Bien que cela ait réduit la dette technique, cela a également causé des problèmes à de nombreux développeurs de greffons et de scripts tiers qui souhaitaient porter leurs greffons vers la version 3.0. Alors que notre plan initial était d’implémenter la nouvelle API publique de filtre après la sortie de la version 3.0, les commentaires de la communauté nous ont convaincu de l’ajouter pour la version 3.0 RC2.

Application de filtres via l’API libgimp 3.0.0 (Script-fu et al.) - GIMP 3.0.0 RC2

Le travail de Jehan permet aux développeurs d’appliquer des effets de filtre soit immédiatement, soit de manière non destructrice. Vous pouvez voir des exemples de la manière de procéder en C, Python et Script-Fu dans la requête de fusion, ou en recherchant gimp-drawable-filter dans le navigateur de procédures de GIMP. Nous avons également commencé à utiliser l’API de filtre dans nos scripts Python pour créer automatiquement des effets d’arrière-plan flou pour le programme d’installation Windows, et avec cette même API en C, Alx Sa a ajouté la prise en charge de l’importation de l’ancien style de calque Color Overlay de Photoshop.

Nous sommes preneurs des retours et des rapports de bugs d’auteurs de greffons et de scripts qui utilisent la nouvelle API de filtrage dans leur travail ! Nous avons également prévu d’autres mises à jour pour GIMP 3.0.

Espaces de fusion de calques et composition dans les fichiers XCF

Les discussions entre les experts en science des couleurs Elle Stone et Øyvind Kolås ont révélé un autre domaine nécessitant des améliorations dans le cadre de notre projet Color Space Invasion. Plus précisément, les images avec des profils de couleurs qui ont des courbes de reproduction des tons non perceptives peuvent ne pas être rendues correctement lorsqu’elles sont définies sur certains modes de calque.

Øyvind a implémenté une correction pour ce problème en ajoutant un espace perceptuel approprié par défaut à des modes de calque spécifiques. Bien que nous pensions que cette amélioration ne devrait pas avoir d’impact sur les fichiers XCF plus anciens, n’hésitez pas à rapporter tous problèmes de compatibilité avec la version 3.0 RC2 !

Paquets

AppImage

Grâce aux efforts continus de Bruno Lopes et avec l’aide de Samueru et de la communauté AppImage, notre AppImage expérimentale fonctionne désormais sur la plupart des distributions Linux. Nous souhaitons encourager davantage de tests, dans l’espoir de pouvoir la proposer comme une autre version Linux en plus de notre Flatpak. Vous pouvez consulter les instructions pour installer les paquets expérimentaux AppImage sur notre page de téléchargement des versions de développement.

Flatpak

Notre flatpak journalier a maintenant un App-ID dédié org.gimp.GIMP.Nightly. Cela signifie principalement qu’il peut être installé côte à côte avec le flatpak stable tandis que les deux sont visibles dans vos menus (plus besoin de sélectionner quelle version doit être affichée avec flatpak make-current).

Mais cela signifie également que tous ceux qui avaient le flatpak journalier jusqu’à présent ne verront pas de mise à jour arriver de sitôt. Afin de continuer à utiliser le flatpak journalier, désinstallez celui existant et installez le nouveau avec ces commandes :

flatpak uninstall org.gimp.GIMP//master
flatpak install https://nightly.gnome.org/repo/appstream/org.gimp.GIMP.Nightly.flatpakref

⚠️ Rappel : le flatpak journalier contient le code de développement actuel tel qu’il se présente dans le dépôt source. Parfois, il peut même être très cassé ou rendre vos fichiers de projet invalides. Nous ne le recommandons pas pour la production ! Utilisez cette version pour nous aider à déboguer en signalant les problèmes ou si vous aimez vraiment les risques pour tester les dernières fonctionnalités.

Améliorations du greffon BMP

Le nouveau contributeur Rupert Weber a été très occupé depuis la dernière mise à jour avec de nouvelles mises à jour de notre greffon BMP. Quelques points de son travail à mettre en avant :

• Les fichiers BMP sont désormais importés sans perte dans leur précision d’origine, plutôt que d’être convertis en précision entière de 8 bits.
• Le greffon prend désormais en charge le chargement de fichiers BMP avec compression RLE24 et Huffman.
• Nous chargeons désormais les fichiers BMP par morceaux plutôt que d’essayer de charger l’image entière en une seule fois. Des travaux connexes nous permettent également de charger des fichiers BMP beaucoup plus volumineux.
• Rupert a également effectué beaucoup de nettoyage et de maintenance du code, afin de rendre le greffon plus facile à maintenir à l’avenir.

Mises à jour diverses

• Jehan a apporté quelques améliorations d’usage de la console Python. Vous pouvez désormais utiliser les raccourcis Ctrl+R et Ctrl+S pour parcourir votre historique de commandes, et Page précédente et Page suivante vous permettent désormais de faire défiler l’historique en plus des touches fléchées Haut et Bas.

Recherche dans l’historique de commande (console Python) - GIMP 3.0.0 RC2

• Alx Sa a implémenté le chargement des fichiers CMJN PAM dans le greffon PNM.

• Sous Windows, nous avons également ajouté la possibilité d’ouvrir des images via des raccourcis Windows (fichiers .lnk) directement depuis la boîte de dialogue de sélection de fichiers. Ce travail est également réalisé par Alx Sa.

• D’autres modifications et améliorations ont été apportées au thème. En particulier, le style du « curseur compact » a été considérablement amélioré après les commentaires et le travail de Denis Rangelov. Denis a également créé de nouvelles icônes pour la boîte de dialogue de navigation ancrable, remplaçant les doublons par des symboles distincts. Anders Jonsson a également révisé le thème et supprimé certaines solutions de contournement qui étaient nécessaires dans GIMP 2.10, mais qui ne sont plus nécessaires avec nos nouveaux thèmes 3.0.

• Idriss Fekir a apporté des améliorations à notre code de chargement de polices XCF, pour améliorer la compatibilité lors de l’importation d’anciens fichiers XCF.

Aperçu des changements depuis la version 2.10

Pour ceux qui n’ont pas suivi de près le développement de GIMP, cet article ne couvre que les changements progressifs depuis la dernière version. Ils ne répertorient pas tous les changements ou améliorations apportés à GIMP 3.0 - ce serait un article très long !

Bien que nous aurons des notes de version complètes pour la version finale 3.0, nous avons pensé qu’il serait utile de résumer quelques-uns des changements majeurs apportés au cours du processus de développement de la version 2.99 :

• Le travail initial de portage de GIMP vers GTK3 a eu lieu dans 2.99.2. Cette version a également introduit la sélection multi-calque, ainsi que des modifications initiales de l’API et des améliorations de la gestion de l’espace colorimétrique.
• D’autres mises à jour de l’API ont été effectuées dans 2.99.4, notamment la possibilité de générer automatiquement des interfaces utilisateur de greffon en fonction des entrées de l’utilisateur. Diverses améliorations de convivialité ont également été apportées, ainsi que l’introduction de l’outil expérimental Paint Select.
• 2.99.6 a apporté davantage de mises à jour de l’API et de travaux internes. D’autres fonctionnalités destinées à l’utilisateur incluent la possibilité de placer des guides en dehors du canevas, une meilleure prise en charge du pavé tactile et une meilleure prise en charge des différentes métadonnées de couleur PNG.
• Le pipeline de développement a été considérablement amélioré dans 2.99.8, permettant des temps de construction et une automatisation plus rapides. La prise en charge de nouveaux formats de fichiers tels que PSB et JPEGXL a été ajoutée dans cette version, ainsi que la prise en charge des pilotes Windows Ink de tablette graphique.
• 2.99.10 a introduit des « ensembles de calques », remplaçant l’ancien concept de calques liés. La dynamique de peinture a été rationalisée dans cette version, ainsi que la première version de la boîte de dialogue de bienvenue.
• La prise en charge de la liaison anticipée CMJN a été implémentée dans 2.99.12. Les thèmes de l’interface graphique CSS ont également fait l’objet d’une refonte majeure dans cette version, ainsi que davantage de prise en charge de formats de fichiers et d’améliorations majeures de Script-Fu.
• 2.99.14 a vu l’introduction de contours non destructifs pour l’outil de texte. L’outil d’alignement a également été révisé, la mise à l’échelle des thèmes et des icônes a été améliorée et les sélections flottantes ont été largement remplacées dans le flux de travail.
• Le portage GTK3 a finalement été achevé dans 2.99.16. La fenêtre contextuelle de recherche / a été mise à jour pour afficher le chemin du menu pour toutes les entrées, ainsi que pour permettre de chercher parmi les filtres.
• Les filtres non destructifs ont été introduits pour la première fois dans 2.99.18. Des améliorations majeures de la gestion des couleurs ont également été apportées, et de nouvelles options d’extension automatique des limites de calque et d’accrochage ont également été implémentées.

GEGL

Tout comme pour GIMP, la version 0.4.52 de GEGL a été corrigée. Øyvind Kolås a corrigé certaines étiquettes génériques « Entrée auxiliaire » pour qu’elles soient plus significatives. Elles seront également visibles dans les filtres de GIMP. Il a également amélioré la précision du traitement des couleurs de certains filtres. Thomas Manni, contributeur de longue date, a également corrigé les plantages lorsque certains filtres étaient exécutés sur de très petits calques.

Statistiques de sortie

Depuis GIMP 3.0 RC1, dans le dépôt principal de GIMP :

• 73 rapports ont été fermés comme CORRIGÉS.
• 71 demandes de fusion ont été acceptées.
• 277 commits ont été poussés.
• 18 traductions ont été mises à jour : bulgare, catalan, chinois (Chine), chinois (Taïwan), danois, finnois, géorgien, islandais, italien, letton, lituanien, norvégien nynorsk, persan, portugais, russe, slovène, suédois, ukrainien.

35 personnes ont contribué à des modifications ou des correctifs à la base de code de GIMP 3.0.0 RC2 (l’ordre est déterminé par le nombre de commits ; certaines personnes sont dans plusieurs groupes) :

• 12 développeurs pour le code principal : Jehan, Alx Sa, Michael Schumacher, Anders Jonsson, Lloyd Konneker, Øyvind Kolås, Idriss Fekir, Andre Klapper, Jacob Boerema, Michael Natterer, Rupert Weber, Thomas Manni.
• 11 développeurs de plug-ins ou modules : Jehan, Lloyd Konneker, Alx Sa, Rupert Weber, Daniel Novomeský, Jacob Boerema, Aki, Bruno, Ryan Sims, Simon Munton.
• 19 traducteurs : Alan Mortensen, Cheng-Chia Tseng, Kolbjørn Stuestøl, Rūdolfs Mazurs, Jiri Grönroos, Sveinn í Felli, Alexander Shopov, Aurimas Černius, Marco Ciampa, Danial Behzadi, Hugo Carvalho, Jordi Mas, Anders Jonsson, Ekaterine Papava, Julia Dronova, Luming Zh, Martin, Michael Schumacher, Youri Chornoivan.
• 2 concepteurs de thèmes : Alx Sa, Anders Jonnson.
• 2 contributeurs à la documentation : Jehan, Bruno.
• 5 contributeurs pour la compilation, l’empaquetage ou l’intégration continue : Bruno, Jehan, Lloyd Konneker, Alx Sa, Jacob Boerema, Rupert Weber.

Contributions sur d’autres dépôts du GIMPverse (l’ordre est déterminé par le nombre de commits) :

• GEGL 0.4.52 est composé de 31 commits de 16 contributeurs : Øyvind Kolås, Sam L, Thomas Manni, lillolollo, Alan Mortensen, Anders Jonsson, Ekaterine Papava, Hugo Carvalho, Jordi Mas, Juliano de Souza Camargo, Kolbjørn Stuestøl, Lukas Oberhuber, Luming Zh, Marco Ciampa, Martin, Yuri Chornoivan.
• ctx a enregistré 48 commits depuis la sortie de la RC1 par 1 contributeur : Øyvind Kolås.
• gimp-data a enregistré 6 commits de 5 contributeurs : Anders Jonsson, Jehan, Sevenix, Alx Sa et Denis Rangelov.
• gimp-test-images (nouveau référentiel pour les tests de prise en charge des images) a enregistré 2 commits de 1 contributeur : Rupert.
• La version gimp-macos-build (scripts d’empaquetage pour macOS) a reçu 5 commits de 1 contributeur : Lukas Oberhuber.
• La version flatpak a reçu 4 commits de 2 contributeurs : Bruno Lopes, Jehan.
• Notre site Web principal a reçu 29 commits de 3 contributeurs : Jehan, Alx Sa, Andrea Veri.
• Notre site Web de développement a reçu 16 commits de 2 contributeurs : Jehan, Bruno Lopes.
• Notre documentation pour GIMP 3.0 a reçu 157 commits de 10 contributeurs : Andre Klapper, Kolbjørn Stuestøl, Jacob Boerema, Alan Mortensen, Anders Jonsson, Marco Ciampa, Jordi Mas, Yuri Chornoivan, Alx Sa, Jiri Grönroos.

N’oublions pas de remercier toutes les personnes qui nous aident à trier dans Gitlab, à signaler les bugs et à discuter des améliorations possibles avec nous. Notre communauté est également profondément reconnaissante envers les guerriers d’Internet qui gèrent nos différents canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de parties dans GIMP et de la façon dont nous obtenons des statistiques via les scripts git, des erreurs peuvent se glisser dans ces statistiques. N’hésitez pas à nous dire si nous avons oublié ou mal classé certains contributeurs ou contributions.

Autour de GIMP

Miroirs de téléchargement

GNOME a abandonné l’utilisation de miroirs lors de sa dernière mise à jour d’infrastructure. Comme nos miroirs de téléchargement sont hébergés par eux, on nous a demandé si nous voulions également faire la même chose. En tant que projet communautaire, nous apprécions tous ceux qui contribuent un miroir pour rendre GIMP plus accessible dans leur région. Par conséquent, nous avons décidé de continuer à utiliser des miroirs pour distribuer GIMP.

Si vous souhaiter contribuer à un miroir pour votre région, voici la nouvelle procédure :

Comment devenir un miroir officiel (mise à jour de la procédure)

1. Créez une demande de miroir sur le tracker gimp-web
2. Dites-nous pourquoi vous souhaitez créer un miroir de GIMP, pour quels autres logiciels libres vous en contribuez déjà un, quelle est votre configuration, l’emplacement du serveur…
3. Parlez-nous de vous : êtes-vous une organisation ou un particulier ? Donnez-nous le nom et l’URL spécifiques à afficher dans la liste des sponsors de miroir.
4. Une fois que nous aurons terminé de vérifier votre organisation, les identifiants rsync seront échangés de manière sécurisée, vous permettant de synchroniser votre miroir avec le serveur source
5. Il n’y a rien de particulier à faire pour apparaître sur la page des sponsors qui sera mise à jour régulièrement via des scripts. Pourtant, cela peut prendre quelques jours, voire quelques semaines parfois. Ne vous inquiétez donc pas si le nom de votre organisation n’apparaît pas immédiatement !

🛈 Nous vérifions automatiquement à intervalles aléatoires que les miroirs sont mis à jour suffisamment rapidement et que les données correspondent pour des raisons de sécurité évidentes.

Changements dans les miroirs

De plus, depuis la publication de la nouvelle 3.0RC1, un nouveau miroir a été ajouté :

• Sahil Dhiman, Mumbai, Inde

Les miroirs sont importants, car ils aident le projet en répartissant la charge des dizaines de milliers de téléchargements quotidiens. De plus, en ayant des miroirs répartis dans le monde entier, nous garantissons que tout le monde peut avoir un accès rapide au téléchargement de GIMP.

Financer des exécuteurs ("runner") GitLab

Le dépôt de code de GIMP est également hébergé sur la plateforme GitLab de GNOME. Andrea Veri a demandé si nous pouvions financer un exécuteur [NDA: un "runner" est une sorte de serveur dédié à la compilation ou à l’intégration continue de manière générale] sur la plateforme, ce qui permet à tout projet sur la plateforme de tester la construction de son logiciel avant, pendant et après les modifications de code. Après un vote du comité de GIMP, nous avons accepté et sommes désormais les sponsors d’un exécuteur CI/CD x86 !

Télécharger GIMP 3.0 RC2

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

• Paquets Linux flatpaks pour x86 et ARM (64 bits)
• Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
• Paquet MSIX (aperçu GIMP) pour x86 et ARM (64 bits)
• Paquets macOS DMG pour le matériel Intel
• Paquets macOS DMG pour le matériel Apple Silicon

D’autres paquets réalisés par des tiers devraient évidemment suivre (paquets de distributions Linux ou *BSD, etc.).

🛈 Notes:

• Les 2 paquets DMG macOS seront probablement en retard, car nous attendons la validation de la mise à jour Apple par la Fondation GNOME avant de pouvoir signer nos paquets.
• Le paquet MSIX prend généralement quelques jours ouvrables de validation par Microsoft. (le paquet MSIX est disponible)

Et ensuite ?

Grâce au grand nombre de retours que nous avons reçus pour notre premier candidat à la version finale, nous sommes en mesure de vous présenter cette deuxième version qui en est d’autant plus robuste. Comme vous l’avez vu, quelques surprises supplémentaires 🎁 sont arrivées avec les corrections de bugs, notamment la nouvelle API de filtre, qui a déclenché la prise en charge de l’importation de l’ancien effet Color Overlay de PSD, des modes de fusion et de composition améliorés, et plus encore. Nous avons pensé que cela valait la peine de rompre le gel des fonctionnalités pour ces changements et que cela fera toute la différence !

Avec cette deuxième version candidate, nous sommes plus proches que jamais de la version 3.0.0 de GIMP. Comme d’habitude, nous attendons avec impatience les nouveaux rapports de problèmes de la communauté qui nous permettront de finaliser la version 3.0.0 ! 🤗

N’oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, afin de donner en retour et d’accélérer le développement de GIMP. L’engagement de la communauté aide le projet à se renforcer ! 💪🥳

🎅🎄🎉 Et bien sûr, toute l’équipe vous souhaite de joyeuses fêtes de fin d’année (MAJ de Jehan) nos meilleurs vœux pour la nouvelle année ! 🥳🥂🎆

Commencée le 16 octobre 2024, la campagne du Lama Déchaînée avait deux objectifs :

• obtenir de quoi finir l’année 2024 sereinement
• faire connaître les actions de l’April

Grâce à de très nombreuses personnes qui ont adhéré ou fait un don, le premier objectif a été atteint le mercredi 25 décembre (beau cadeau de Noël !) et l’April a pu récupérer la somme dont elle avait besoin. Toute l’équipe ayant mis en place la campagne est reconnaissante des nombreux retours reçus. Et tout le monde respire mieux. Merci !

Quant au deuxième objectif : faire connaître les actions de l’April, il a fallu faire un choix et donc ces dix numéros ne vous ont présentés qu’une sélection que je me propose de résumer ici (sous forme de liste, parce que j’adore les listes !). N’hésitez pas à passer et aller directement à la longue ligne plus bas si vous avez lu tous les numéros du Lama.

Dans les éditos de la présidente :

• La lutte contre le monopole de Microsoft
• Le travail avec les parlementaires et les demandes CADA
• L’art Libre, ses différentes licences, ses différentes formes
• La position officielle sur les impacts du numérique
• La priorité aux logiciels libres au sein des associations
• La réflexion, la mise en place de différentes actions dont la position finale sur l’inclusivité et la diversité
• Les rapports de la Cour des comptes qui servent à l’April, mais aussi aux parlementaires
• Le projet de loi sur le contrôle parental
• La menace sur les logiciels libres de caisse

Dans les compte-rendus d’activités de notre vice-président (dur dur de se limiter à un seul dossier par numéro) :

• 2002, la tentative d’entrer au patrimoine mondial
• 2005, l’engagement d’un premier salarié et le combat sur les brevets
• 2006, la lutte contre la vente forcée
• 2007, DAVDSI et DRM
• 2012, la Circulaire Ayrault
• le groupe diversité de l’April
• 2007, l’initiative Candidats-fr
• 2018, l’Open Bar (dossier historique depuis 2008, renouvelé en 2013)
• la 2CV, une parabole libriste

Les actu brûlantes, sont apparues en cours de route, pour réagir sur l’actualité qui a été assez particulière en cette fin d’année :

• le projet de loi finances 2025 qui menaçait les logiciels libres de caisse,
• le changement de gouvernement, et le ministre des Armées Sébastien Lecornu qui aurait mieux fait de se taire…
• la future date de l’assemblée générale (AG) : le 15 mars 2025 (save the date! ou notez-le sur votre agenda !)
• le futur ministre au Logiciel Libre ou du Jurançon

Dans les logiciels de la semaine, nous avons présenté certains des services du chapril, accessibles à toustes :

• Mumble, un logiciel d’audio-conférence
• Nextcloud, partage de documents mais pas que
• Minetest nouvellement Luanti, un moteur de jeu vidéo
• Firefox send, service permettant de partager des fichiers rapidement et simplement
• Framadate, service de sondage (date ou autre)
• Jitsi Meet, multiplateforme de messagerie instantanée
• Mastodon, Réseau social et logiciel de microblogage
• Etherpad, éditeur de texte libre
• Wiki, création, modification et illustration collaboratives de pages web
• Gitea, service libre de forge

Dans les citations, nous avons voulu mettre en avant deux sites de l’April :

• celui de l’émission Libre à vous ! diffusée sur la radio Cause Commune
• celui de Libre à Lire ! site qui publie de très nombreuses transcriptions de fichiers média utiles à la communauté, facilitant leur accessibilité.

Dans Parole de…, nous avons essayé de mettre des visages et des mots sur les personnes les plus actives (et surtout les moins timides) de l’association. Mais nous étions limités en nombre…

Dès le départ, nous avons choisi de laisser la plume à des personnes extérieures à l’April afin de mettre en lumière d’autres projets ou pensées importantes qui nous tiennent à cœur. Merci à :

• Claudine Chassagne, élue de Saint-Martin-d’Urillage,
• Tristant Nitot,
• Clément Oudot alias KPTN,
• Isabelle Carrère d’Antanak,
• Angie de Framasoft,
• Florence Chabanois de la Place des Grenouilles,
• Marie-Jo Kopp Castinel de la Mouette et d’OpenGo,
• Stéphane Bortzmeyer,
• Ploum, auteur du nouveau livre Bikepunk aux éditions PVH. Et merci à Frédéric Couchet, pour sa plume infiltrée, fếtant les 28 ans de l’April!

Nous avons également parlé :

• des autres campagnes Candidats.fr
• de l’Agenda du Libre
• du projet GNU
• de LinuxFr.org
• de DRM
• de groupes de travail de l’April: transcriptions, trad-gnu, revue de presse, sensibilisation
• de l’Expolibre
• de copie publique
• de noms de serveurs
• de Wikipedia
• de Framaspace et d’Émancip'asso, projet de Framasoft
• de Toulibre et du Capitole, de Parinux et de son PSL XXL, de GCU au Salon Solution GNU/Linux
• de Blender
• de Nanine Vallain, grâce à Élisa de Castro Guerra, lors du numéro « Girl Power »
• d’Elles font le Libre, de parcours libristes et de nombreuses associations de femmes dans la tech: Duchess France, PyLadies, Debian women, Ladies of Code Paris, Des Codeuses, Compositech
• de comment se démysogyner
• de rescrit fiscal, refusé deux fois !!
• des vieux rapports de bug
• de Douglas Adams
• d’embarqué
• et d’Henri Verdier.

Le tout allégé par des dessins satiriques de Gee (mais quel talent !) et des anecdotes rigolotes (comme les sons émis par les mammouths ou les t-shirts et les serviettes jaune poussin)

Nous avons aussi laissé la possibilité de participer aux personnes qui le voulaient grâce au concours de dessins (dé)générés et au courrier des lecteurices. Merci à celles qui ont mis du leur !

Et j’ai failli oublier les fameux mots croisés, incontournables pourtant, faits à la sueur de vingt doigts et la liquéfaction de deux cerveaux, chaque semaine.

---

Cette campagne, indispensable pour l’April s’est déroulée dans la bonne humeur. Sa préparation s’est beaucoup faite en amont, mais les réunions hebdomadaires ont apporté leurs lots de surprises, comme:

• la mise en place de la rubrique actu brûlante
• le prototype aéronautique que vous avez pu tester sur différents événements
• la possibilité d’impression puis la distribution du format papier du Lama Déchaîné par nos 'tits gavroches aux jolies casquettes
• le numéro bonus
• les solutions des mots croisés directement accessibles en fin de campagne (il suffit de retourner sur les fameuses grilles et de cliquer sur le bouton “révéler”)
• les menaces faites au Lama sur un réseau social dans les derniers jours de la campagne.

C’est parce que nous avons su travailler ensemble et réagir rapidement, que cette campagne est pour nous un bon moment et restera un souvenir très positif. Nous espérons qu’il en sera de même pour vous.

J’en profite pour vous envoyer tous mes vœux de bonheur pour cette année 2025 à venir et, vu le contexte actuel, je pense que l’on en aura bien besoin !!

PS: j’ai pensé à mettre des espaces fines devant mes ponctuations pour couper court à certains trolleurs… :-p

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 ?
  • Télécharger Tuxemon Tower 0
    • Quelques clients BitTorrent libres
  • Images du jeu
    • Images de cartes
    • Images de combats
    • Images de menus
  • Comment contribuer ?
  • Le droit d'auteur
    • Les licences utilisées
    • Les conséquences
  • Remerciements
• En plus long ?
• Données du jeu
  • Consultation en jeu
  • Documentation HTML
  • Images
    • Liste des créatures
    • Liste des dresseurs et dresseuses
• Annexe : temps et motivation
  • Approximation de l'évolution de la motivation
    • Statistiques de commits par nous pour ce nouveau jeu
    • Statistiques de commits par nous pour Greycess Knight RPG

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 :

• GNU/Linux, *BSD, Windows et/ou macOS
  • Transmission
  • Deluge
  • KTorrent
  • qBittorrent
• Android
  • LibreTorrent
  • BiglyBT

Images du jeu

Images de cartes

Images de combats

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

• La très vaste majorité du code source est sous la licence GNU AGPL en version 3.0 ou plus. Le faible reste est dans le domaine public (via une version très légèrement augmentée de la licence GNU All-Permissive ou FSFAP dans la nomenclature SPDX).
• Les sprites 16×16 sont dans le domaine public (via la licence Creative Commons 0).
• Les sprites 64×64 ont été faits par de multiples personnes et sont donc sous de multiples licences libres.

Les conséquences

• Pour le code sous GNU AGPL, c'est avec gauche d'auteur contaminant, y compris pour la fourniture par réseau (c'est l'amélioration par rapport à la GNU GPL). Si vous distribuez une version modifiée, vous devez donc en distribuer le code source et ce sous une licence compatible (le plus simple est d'utiliser la même licence et à notre connaissance c'est la seule pour du déjà existant, mais vous pouvez utiliser la GPLv3 pour du nouveau code mis dans un nouveau fichier).
• Vous pouvez faire ce que vous voulez du code sous licence GNU All-Permissive et de tous les sprites 16×16.
• Si vous utilisez un ou des sprites 64×64, vous devez au moins en créditer la ou les personnes autrices et mentionner la licence. Pour certaines, vous devez partager sous les mêmes conditions même si modification(s) (de par le gauche d'auteur de la Creative Commons BY-SA et de la GNU GPL).

Remerciements

• le projet Tuxemon originel, pour le concept et le rassemblement des sprites 64×64 et la création d'un certain nombre
• OpenGameArt et Kenney, pour les sprites 16×16
• le projet GNU, pour notamment sa « philosophie » et ses licences, ainsi que GCC
• GNU make et CMake, pour l'orchestration de la compilation et des tests
• Trisquel GNU/Linux et Debian GNU/Linux, les deux systèmes d'exploitation utilisés
• GDB et Valgrind, pour avoir bien aidé à déboguer et résoudre des problèmes de mémoire
• check, pour des tests automatiques d'exécution
• Clang, pour ses messages complémentaires à GCC
• cppcheck et splint, ainsi que KWStyle, pour des tests statiques complémentaires aux compilateurs
• toutes celles et ceux qu'on a oubliés (moyen facile de demi-esquive !)

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