Nous venons de publier CryptPad 2025.3.0, suite collaborative chiffrée de bout en bout et open-source. Et, bien qu’il n’introduise pas de nouvelles applications majeures, il inclut d’importantes améliorations techniques, des corrections de bugs, et des ajustements de convivialité, en particulier pour les utilisateurs sur mobile ou avec des disques de grande taille.

Cette version marque également le début d’un effort de refonte plus large, visant à rendre CryptPad plus rapide, plus modulaire, et plus facile à maintenir et à étendre au fil du temps.

Le document #1 et la présentation sont maintenant ouverts sur cryptpad.fr

De nombreux utilisateurs ont demandé le support des documents (DOCX/ODT) et des présentations (PPTX/ODP) compatibles avec Office.

Grâce au travail de Wolfgang Ginolas, ces éditeurs sont disponibles en beta sur cryptpad.fr (même pour les utilisateurs gratuits) et font de CryptPad une alternative plus complète pour la collaboration en ligne sécurisée.

Vous pouvez commencer un document ou une présentation sur cryptpad.fr (aucun compte n’est requis).

Meilleure performance, en particulier sur les mobiles et les grands comptes

Si vous avez déjà attendu un certain temps pour que CryptPad se charge, en particulier lorsque vous travaillez avec un grand disque ou des dossiers d’équipe, cette version devrait faire une différence notable.

Nous avons restructuré la façon dont les blocs et les dossiers sont chargés : au lieu de tout charger en même temps, CryptPad donne maintenant la priorité au document que vous ouvrez, les autres contenus se chargeant en arrière-plan. Cela signifie :

• délai plus court pour la première interaction lors de l’ouverture d’un bloc-note,
• moins de retard lors de l’accès aux dossiers partagés et aux disques d’équipe,
• une expérience plus réactive sur les appareils mobiles.

Ce travail prépare également le terrain pour de futures améliorations, comme une API JavaScript, qui permettrait aux applications tierces de se connecter plus facilement aux serveurs CryptPad.

Autres améliorations et corrections

Cette version comprend également :

• nouveaux outils d’administration : les administrateurs peuvent maintenant ajouter ou supprimer d’autres administrateurs via l’interface,
• améliorations de l’écran tactile dans Kanban et Forms,
• améliorations de l’interface utilisateur pour les mobiles (meilleures dispositions, mode de prévisualisation pour le code, boutons améliorés),
• améliorations de l’accessibilité, en particulier dans le calendrier et l’interface d’administration,
• corrections pour les téléchargements de fichiers OnlyOffice et amélioration des messages d’erreur dans plusieurs parties de l’interface utilisateur,
• améliorations du backend et de l’utilisation de la mémoire pour aider les instances à s’adapter plus efficacement,
• corrections de sécurité. Si vous utilisez une instance CryptPad auto-hébergée, nous vous recommandons de la mettre à jour dès que possible,
• pour une liste complète des changements, consultez les notes de version.

Remarque : nous avions prévu de mettre à niveau les éditeurs OnlyOffice vers la version 8 dans cette version, mais nous travaillons toujours sur les problèmes d’intégration. Comme les mises à jour de documents ne peuvent pas être annulées, nous attendrons et inclurons ce changement dans la version 2025.3.1, une fois qu’elle sera stable.

Statistiques du projet

Voici un rapide aperçu de la situation actuelle de CryptPad :

• plus de 2 millions de pads ouverts par mois sur cryptpad.fr,
  • environ 200 000 utilisateurs par mois,
• 55 000 utilisateurs avec des lecteurs personnels,
  • plus de 1 000 abonnés soutenant le projet,
• plus de 1 400 instances CryptPad dans la nature.

Nous sommes reconnaissants à la communauté qui nous aide à tester, à rapporter les bugs, à aider les autres et à soutenir le projet par le biais de dons et d’abonnements.

Vous pouvez également contribuer à la viabilité financière de CryptPad. Si vous êtes un utilisateur individuel, vous pouvez faire un don via Open Collective ou en vous abonnant à CryptPad.fr. Les organisations peuvent contribuer par le biais d’abonnements ou de parrainages de fonctionnalités. Nous sommes totalement transparents sur notre financement et publions des mises à jour annuelles sur le blog CryptPad.

Prochaines étapes

Nous continuons à améliorer les performances, le support mobile et l’intégration d’OnlyOffice. Pour la prochaine version majeure (prévue pour l’été 2025), nous visons à apporter plus d’améliorations en termes de convivialité et de qualité de vie dans tous les domaines.

Comme toujours, nous nous efforçons de faire de CryptPad une alternative solide et respectueuse de la vie privée aux outils bureautiques classiques ; quelque chose sur lequel les gens peuvent compter sans renoncer au contrôle de leurs données.

Les méandres de l'espace de rédaction sont parfois mystérieux. La rédaction de certaines dépêches s'étalent parfois sur de long mois, parfois sans même comprendre pourquoi la dépêche ne part pas vers le stade de la publication. C'est ce qui est arrivé à cette dépêche qui ne suit donc pas autant qu'elle aurait pu l'actualité de la sortie de la nouvelle mouture de la microcarte de la Fondation Raspberry Pi, qui porte le nom très original de Raspberry Pi 5. Cette dépêche - qui nous offre une comparaison de cette nouvelle édition avec son illustre ancêtre ainsi qu'une investigation de ses nouveautés - reste substantielle et il nous a semblé qu'il valait mieux la publier même tardivement plutôt que de la plonger dans l'oubli éternel.

Sommaire

• Comparaison entre Raspberry Pi 4 et Raspberry Pi 5
• Détail des améliorations de la Raspberry Pi 5
  • Raspberry Pi 5 : Nouveau South Bridge RP1 vs Raspberry Pi 4
    • Architecture du South Bridge RP1
    • Sources des informations sur le RP1
  • Impacts du RP1
  • Évolution des performances
    • performances des I/O
    • Interfaces USB et Ethernet
    • Interfaces MIPI CSI/DSI
• Les points discutables/discutés
  • Le réarrangement de la carte
  • Le non réarrangement de la carte
  • Les limites du format carte de crédit

Cette dépêche ne traitera pas de l’ensemble de ce que l’on peut faire, la précédente dépêche sur les SoC faite pour la sortie de la Raspberry Pi 4 est toujours d’actualité en ce qui concerne ces sujets.

Comparaison entre Raspberry Pi 4 et Raspberry Pi 5

Sorti en 2019, le RPi4 avait fait forte impression—mais quasiment en constante pénurie entre 2020 et 2023, il commençait par accuser le coup par rapport à la concurrence du Rockchip RK3588 (Quad-core Cortex-A76 + Quad-core Cortex-A55).

Aussi, la Raspberry Pi 5 introduit des avancées significatives par rapport à la Raspberry Pi 4, dont le Tableau 1 présente une synthèse des différences.

Composants	Raspberry Pi 4	Raspberry Pi 5
SoC	Broadcom BCM2711	Broadcom BCM2712
CPU	Quad-core Cortex-A72 (1.8 GHz)	Quad-core Cortex-A76 (2.4 GHz)
GPU	VideoCore VI (500 MHz)	VideoCore VII (800 MHz)
Mémoire	1, 2, 4, 8 GB LPDDR4-3200 SDRAM	4, 8 GB LPDDR4X-4267 SDRAM
Wi-Fi	Dual-band 802.11ac	Dual-band 802.11ac
Bluetooth	5.0, BLE	5.0, BLE
USB	2 USB 3.0, 2 USB 2.0, 1 Type-C port	2 USB 3.0, 2 USB 2.0, 1 Type-C port
Stockage	MicroSD	MicroSD (SDR104⟹R/W↗ˣ²) + ligne PCIe pour NVME M.2 SSD
Ethernet	Gigabit Ethernet	Gigabit Ethernet
Puissance	Jusqu’à 7.5 W	2 modes : jusqu’à 15 W et jusqu’à 25 W
Gestion HDMI	2 HDMI 2.0 (1 gérant 4k@60 Hz)	2 HDMI 2.0 (tous les deux gérant 4k@60 Hz)
Format vidéo	H.264 (AVC)	H.265 (HEVC)
PCIe	Non	1 lane PCIe pour périphériques haute performance
Bouton d’alimentation	Non	Oui

Tableau 1 : comparatif des Raspberry Pi 4 et 5

Détail des améliorations de la Raspberry Pi 5

La Raspberry Pi 5 introduit des avancées significatives par rapport à la Raspberry Pi 4, en particulier avec l’introduction du southbridge RP1. Voici une comparaison détaillée mettant en évidence les principales différences et l’impact du RP1 :

• Processeur : La Raspberry Pi 5 est équipée d’un CPU ARM Cortex-A76, une amélioration substantielle par rapport au Cortex-A72 trouvé dans la Raspberry Pi 4. Cette mise à niveau fait que la Pi 5 est deux à trois fois plus rapide que son prédécesseur.
• RAM : La Raspberry Pi 5 utilise de la LPDDR4X-4267 SDRAM, nettement plus rapide que la LPDDR4-3200 SDRAM utilisée dans la Pi 4. Cette amélioration offre plus de bande passante, contribuant à des performances globalement plus rapides.
• Puissance graphique : La Raspberry Pi 5 dispose d’un GPU VideoCore VII plus puissant, cadencé à 800 MHz et prenant en charge OpenGL ES 3.1 et Vulkan 1.2. C’est une avancée par rapport au GPU VideoCore VI de la Raspberry Pi 4, qui prend en charge OpenGL ES 3.1 et Vulkan 1.0. Le GPU de la Pi 5 comprend également un nouveau processeur de signal d’image pour la gestion des données des caméras.
• Chip RP1 Southbridge : La puce RP1 est une innovation majeure dans la Raspberry Pi 5. Elle agit comme un southbridge, gérant la plupart des fonctions I/O (entrée/sortie), réduisant ainsi la charge sur le CPU. Cela permet une augmentation de la bande passante I/O, bénéficiant aux dispositifs de stockage, USB et autres périphériques.
• Vitesse des cartes MicroSD : Le port microSD de la Pi 5 prend en charge le mode haute vitesse HDR 104 avec les cartes microSD UHS-1, offrant des vitesses de lecture de 80-90 Mbps, soit le double de la vitesse de 40-50 Mbps de la Pi 4.
• Ports USB : Dans la Raspberry Pi 5, chacun des deux ports USB 3.0 dispose d’une bande passante dédiée de 5 Gbps, grâce à la puce RP1. C’est une amélioration par rapport à la Pi 4, où les deux ports USB 3.0 partageaient la bande passante de 5 Gbps.
• Connecteur PCIe : La Pi 5 inclut un connecteur PCIe (PCI Express), une nouvelle addition répondant à la demande pour des interfaces plus rapides. Cependant, l’interface PCIe de la Pi 5 n’est pas un connecteur M.2 standard ; elle nécessite un câble ruban pour se connecter à un HAT, et le dispositif M.2 se connectera au HAT. Caractéristiques
• Un bouton marche/arrêt : Eh oui, on est quand même dans le 3ᵉ millénaire ;-)
• Alimentation : Tout comme la Raspberry Pi 4, la Raspberry Pi 5 utilise un connecteur d’alimentation au format USB Type-C. En revanche, doublement de la puissance oblige, la puissance nécessaire à son fonctionnement passe de 7.5 W à 15 W, il faudra donc une alimentation en 3A minimum pour être tranquille. À noter que si vous souhaitez utiliser des périphériques externes qui consomment beaucoup comme des disques durs ou SSD, il est conseillé d’avoir une alimentation de 25 W (5A). La Raspberry Pi détecte si l’alimentation fournit plus de puissance et passe la limite de consommation USB à 1,6A au lieu de 1,2A.

Raspberry Pi 5 : Nouveau South Bridge RP1 vs Raspberry Pi 4

Le RP1 est un contrôleur d’entrée/sortie (I/O) conçu pour le Raspberry Pi 5, représentant le programme d’ingénierie le plus complexe et coûteux entrepris par Raspberry Pi, avec un développement s’étendant sur plus de sept ans et ayant coûté environ 25 millions de dollars. Ce contrôleur est le premier produit phare de Raspberry Pi à utiliser une puce conçue en interne​.

Architecture du South Bridge RP1

— Description : Le RP1 est un southbridge de 12×12 mm avec un pas de 0.65 mm en BGA (Ball Grid Array), fournissant la majorité des capacités d’E/S pour la Raspberry Pi 5.
— Caractéristiques : Il comprend un point de terminaison PCIe 2.0 à 4 voies, un contrôleur Ethernet MAC Gigabit et deux contrôleurs hôtes USB 3.
— Améliorations : Plus du double de la bande passante USB utilisable par rapport à la Raspberry Pi 4.
— Documentation RP1 : RP1 Datasheet

Sources des informations sur le RP1

— L’article d’Eben Upton pour annoncer le RP1 : RP1 : the silicon controlling Raspberry Pi 5 (ce court article est accompagné d’une vidéo YT de 35 minutes à ce sujet, mais dont le contenu est reproduit textuellement en suivant un lien)
— Lien direct vers la vidéo YT : RP1 : the silicon controlling Raspberry Pi 5

Impacts du RP1

Le RP1 constitue une avancée importante, puisque les GPIOs “physiques” de la carte ne sont plus directement reliées aux GPIOs du microprocesseur et de leurs fonctions possibles (SPI/I2C/UART/I2S) attribuées par le fondeur dans le silicium.

1. Connectivité principale : Le RP1 se connecte à un processeur d’application (AP) via un bus PCIe 2.0 x4, consolidant de nombreux contrôleurs numériques et PHYs analogiques pour les interfaces externes du Raspberry Pi 5​​.
2. Contrôle du trafic : Le tissu interne du RP1 permet de prioriser le trafic en temps réel de la caméra et de l’affichage sur le trafic non en temps réel de l’USB et de l’Ethernet. Des signaux de qualité de service (QoS) sur le lien PCI Express soutiennent la priorisation dynamique entre le trafic provenant du RP1 et le trafic des maîtres de bus en temps réel et non en temps réel au sein de l’AP​​.
3. Fonctionnalités supplémentaires : Pour une flexibilité maximale des cas d’utilisation, le RP1 dispose de plusieurs fonctionnalités telles qu’un contrôleur DMA à huit canaux pour les périphériques à basse vitesse, trois PLL intégrées pour la génération d’horloges vidéo et audio indépendantes, un convertisseur analogique-numérique à cinq entrées, 64kB de SRAM partagée, et des générateurs de base temporelle pour le rythme de la DMA ou pour le debouncing des événements GPIO​​​​.
4. Gestion des contrôleurs de bus : Les modules de régulation intégrés à chaque port de contrôleur de bus permettent de surveiller ou de limiter leur comportement. Ces modules régulent le flux de données selon le nombre de transactions en attente, assurent le respect des limites d’adresses AXI et PCIe, et disposent de compteurs statistiques pour évaluer la qualité de service ou les performances.
5. Interfaces clés externes : Le RP1 fournit des interfaces externes clés telles que deux contrôleurs XHCI indépendants connectés à un seul PHY USB 3.0 et un seul PHY USB 2.0, deux contrôleurs de caméra MIPI CSI-2 et deux contrôleurs d’affichage MIPI DSI connectés à deux PHY transceivers MIPI DPHY à 4 voies partagées, et un contrôleur d’accès média (MAC) intégré pour l’Ethernet Gigabit​​​​.
6. Compatibilité et évolution : Le RP1 maintient la compatibilité avec la gamme de fonctions offerte sur le Raspberry Pi 4 Model B, tout en permettant une évolution vers des processus de géométrie réduite, sans avoir à reproduire tous les éléments analogiques du système. Cela pourrait permettre à changer plus facilement de fournisseur de SoC.

Évolution des performances

Afin de permettre de mieux visualiser les évolutions des performances Alasdair Allan a fait un benchmark complet dont certains éléments sont repris ici.

Tout d’abord une analyse des performances du CPU avec geekbench. Les Figures 1 et 2 montrent une augmentation des performances en single core d’approximativement 2.2x,

Figure 1. : Comparaison des performances single core entre RPi4 et 5

Figure 2. : Comparaison des performances multi core entre RPi4 et 5

Compilation de différents benchmarks entre RPi 4 et 5

Benchmark	Unités	Raspberry Pi 4	Raspberry Pi 5	Augmentation de Performance
Sysbench Mono-Thread	MBps	699	1041	x1,49
Sysbench Multi-Thread	MBps	2794	4165	x1,49
Stress-ng Mono-Thread	op/s	104,78	182,68	x1,74
Stress-ng Multi-Thread	op/s	413,12	737,21	x1,78
Bzip Mono-Thread	secondes	44,98	20,53	x2,19
Bzip Multi-Thread	secondes	28,59	14,36	x1,99
Gimp Redimensionner	secondes	67,01	29,95	x2,24
Gimp Rotation	secondes	77,24	32,77	x2,36
Gimp Niveaux Auto	secondes	80,52	34,64	x2,32
Gimp Masque Flou	secondes	115,16	49,71	x2,32
Speedometer 2.1	score	20,5	62,5	x3,05
Glmark2	score	97	202	x2,08
Openarena Timedemo	FPS	8,77	27,05	x3,08
RAMspeed Écriture	MBps	4391	29355	x6,69
RAMspeed Lecture	MBps	5902	27931	x4,73
HDparm Lecture	MBps	43,81	90,05	x2,06
dd Écriture	MBps	34,49	61,23	x1,78
Iozone 4 K Écriture RAND	MBps	9,38	15,22	x1,62
Iozone 4 K Lecture RAND	MBps	4,71	4,6	x0,98
Temps de démarrage	secondes	33,4	19,1	x1,74

performances des I/O

La Figure 3. issue du travail d’Adafruit permet de mettre à jour le graphique sur la vitesse performance de la commutation des I/O proposé dans la dépêche sur la RPi4. La Figure 4. quant à elle montre une légère amélioration de la performance par Watt sur le nouveau modèle.

Figure 3. Évolution de la vitesse de commutation d’une sortie numérique

Figure 4. Évolution de la performance en fonction de la puissance électrique

Interfaces USB et Ethernet

— Interfaces: Le RP1 fournit deux interfaces USB 3.0 et deux interfaces USB 2.0, ainsi qu’un contrôleur Ethernet Gigabit.
— Source: Circuit Digest – The New Raspberry Pi 5 is here

Le Gigabit Ethernet fourni par le RP1 est en tout point semblable à celui du RBPi4 (voir : RP1 : the silicon controlling Raspberry Pi 5:

Liam 13:21: So we’ve got the Ethernet MAC but not the PHY. So the Ethernet’s brought out to an RGMII interface, which then connects to an on-board Ethernet PHY.

Eben 13:35: And this is a fairly similar architecture to Raspberry Pi 4, except that in that case, the MAC was in the Broadcom device, but there was still an external – in fact exactly the same external – PHY, [BCM]54213. Cool. So that’s the overall structure of the design.

Interfaces MIPI CSI/DSI

Ces interfaces d’entrée/sortie vidéo peuvent être qualifiées d’historiques dans l’écosystème RaspberryPi puisqu’elles sont présentes depuis la version 1. Le RBPi5 apporte toutefois une nouveauté assez remarquable par rapport à ses prédécesseurs : au lieu d’avoir un port CSI (pour une caméra) et un port DSI (pour un écran), les ports du RBPi5 peuvent être configurés pour l’une ou l’autre fonction. Malheureusement, cela s’est traduit par des changements notables au niveau de la disposition des composants sur la carte, qui ne sont pas sans susciter quelques grincements de dents parmi les utilisateurs.

Les points discutables/discutés

Le réarrangement de la carte

— Le port audio a disparu, pour laisser sa place au port MIPI DSI (qui peut faire CSI à présent), lui-même remplacé, au-dessus du lecteur de carte microSD, par un connecteur FPC exposant les lignes PCIe.
— le port DSI est passé de 15 pins à 22 pins (comme sur la carte CMIo4)
— Et, encore une fois, les ports Ethernet et USB ont été inversés.

Si cela ne pose pas de problèmes particuliers pour un utilisateur lambda, de nombreux projets basés sur les cartes RasperryPi à la recherche de performance de calcul (et donc potentiellement intéressés par ce nouveau RBPi5) doivent entièrement revoir la conception de leur matériel.

Le non réarrangement de la carte

C’est un reproche que l’on peut trouver dans de nombreux témoignages : mettre un HAT (carte d’extension) sur un RBPi, juste au dessus du CPU, c’est un non-sens en termes de refroidissement (et ce, quelle que soit la version du RBPi).
Mais, pour relativiser, on peut dire la même chose de quasiment toutes les autres solutions alternatives au RBPi.

Les limites du format carte de crédit

Ce format (86x56 mm) est devenu une référence pour presque tous les acteurs du monde des SBC. Et donc, il s’agit là aussi d’un constat plus général, non spécifiquement adressé à RaspberryPi. Mais sachant que ce sont les locomotives du marché, peut être pourraient-ils initier une nouvelle approche…
Certes, ce format permet d’élaborer des solutions compactes, mais l’on peut constater :

— qu’augmenter la puissance et les fonctionnalités des puces embarquées tout en restant sur ce format conduit à un gaspillage inutile de ressources : il est en effet impossible d’implémenter toutes les fonctionnalités matérielles proposées par les puces sur une si petite surface, et par ailleurs il devient difficile de refroidir efficacement le système.
— pour exposer le port PCIe, RaspberryPi a supprimé le port audio, déplacé le port DSI ; mais pour alimenter le bouzin, il vous faut du 5V 4A. Ensuite un peu tout le monde se trouve planté là : débrouillez-vous.

Et si le système d’exploitation (OS) libre et souverain dont le monde a besoin était basé sur GNOME ? C’est ce que propose Thibault Martin dans un billet posté le 28 février 2025 sur son blog. L’idée est ambitieuse, et bien entendu elle peut froisser les gens qui préfèrent d’autres environnements de bureau, mais elle présente l’intérêt de s’appuyer sur deux tendances notables dans l’actualité récente de Linux : l’avènement des systèmes atomiques et la demande d’un OS dit “souverain”. Nous vous proposons, à travers le billet de Martin, d’en apprendre plus sur ces deux tendances. Ce premier journal se concentre sur la première : les systèmes atomiques, et le changement de paradigme qu’ils préfigurent pour le bureau Linux.

Sommaire

• • De quoi ça parle ?
  • Les OS atomiques, ou la promesse du Linux qui juste-marche
  • La gouvernance des Linux : suffit-il d’être libre pour être souverain ?
  • Notes

De quoi ça parle ?

Dans ce billet titré « Prosthetics that don't betray » (« des prothèses qui ne trahissent pas »), Thibault Martin, ancien membre de la fondation GNOME, appelle à changer la gouvernance du projet pour se donner les moyens d’en faire un OS “indépendant” et prêt à l’emploi, financé par l’Union européenne. Il est question ici de vendre des ordinateurs et des téléphones avec un système Linux pré-installé dessus, assemblé par et basé sur GNOME, indépendant de toute distribution existante, et le tout idéalement financé par l’Union européenne (« ça se verrait à peine dans son budget », argue Martin).

Pourquoi GNOME ? Parce que c’est l'environnement de bureau préféré de Martin, évidemment. Il vante notamment sa bonne intégration au mobile : on l’ignore peut-être (car il reste nettement plus difficile d’installer un Linux sur un téléphone que sur un PC), mais les développeurs GNOME travaillent depuis quelques années à rendre leurs applis adaptables aux petits écrans. Il ne s’agit pas de versions différentes, mais bel et bien de vos applis de bureau, qui se redimensionnent automatiquement pour être utilisables à l’écran tactile. Nick du Linux Experiment en a récemment dit du bien dans une de ses vidéos. Bien entendu, il existe d’autres interfaces mobiles dans le monde Linux, au hasard celle de KDE, Plasma Mobile. Mais ce n’est pas sur cet argument que cette dépêche aimerait s’attarder ; plutôt que de parler des avantages et inconvénients de GNOME sur les autres environnements graphiques libres, nous allons nous pencher sur deux autres idées avancées par Thibault Martin dans son billet, à savoir :

• pour être « utilisable par les masses », cet OS de rêve doit adopter une technologie dite “atomique”
• sa vocation principale sera d’échapper à « l’hégémonie américaine » et « sécuriser la souveraineté numérique de l’UE »

Les OS atomiques, ou la promesse du Linux qui juste-marche

C’était le 25 février dernier, et il l’a dit au premier degré : "We believe that 2025 is truly the year of the Linux gaming desktop ». Pourtant, Nirav Patel précise bien cinq secondes avant que ses ordinateurs (il est le fondateur et le PDG de Framework) supportent aussi Windows. Mais il a l’air de sincèrement croire que cette année, quelque chose de différent est en train de se passer avec le bureau Linux ; et sur la diapo où est écrite cette phrase, on peut voir les logos de Playtron OS et Bazzite, deux projets de Linux orientés “gaming”, mais qui présentent aussi la particularité d’être basés sur Fedora Silverblue, sans doute le plus populaire des Linux atomiques.

À moins que ce ne soit l’inverse ? Le 13 février dernier, Jorge Castro, fondateur du projet Universal Blue (dont est issu Bazzite), montrait fièrement les statistiques des appareils actifs sous Fedora atomiques (si vous ne le saviez pas, toutes les installations de Fedora envoient par défaut un signal anonyme aux serveurs afin d’être recensées). On y voit les machines sous Bazzite doubler de nombre entre octobre dernier et février, dépassant de loin les propres variantes atomiques officielles de Fedora (mais encore très loin derrière “la” Fedora Workstation ordinaire, selon Castro).

Bazzite a tellement la cote qu’elle a été saluée comme « mettant la honte à Windows » dans un article sur The Verge, ce qui est surprenant de la part d’un média tech “généraliste” qui jusqu’à présent n’avait d’yeux que pour les GAFAM et ne s’intéressait guère au monde du libre. Il y a, bien sûr, une explication simple à ce succès : Bazzite vise une niche particulière, celle des utilisateurs et utilisatrices de Steam Deck et autres consoles portables à base de technologie PC, et on peut arguer que cette niche est non seulement en pleine croissance, mais aussi peut-être un peu délaissée par un Microsoft qui n’a pas encore bien optimisé son Windows à un tel cas d’usage. Ce serait comme attribuer la hausse des téléchargements de Linux il y a 15 ans à la mode des netbooks. Mais nous aimerions arguer ici que le succès de Bazzite est aussi dû à son choix technologique de bureau atomique.

Pour rappel, “atomique” est l’expression qui tend à remplacer celles d'“immuable” (traduction anglaise d'"immutable") ou "image-based", et qui désigne une façon bien particulière de construire et distribuer un système d’exploitation. Solène Rapenne propose une définition dans un billet de 2023, où elle résume les principes essentiels des systèmes immuables :

• les mises à jour système ne sont pas effectuées sur le système en cours d’utilisation (celui-ci n’est jamais censé changer, d’où le qualificatif d'“immuable”)
• les modifications de paquets sont appliqués au prochain démarrage (mais pas celles des Flatpak par exemple)
• vous pouvez revenir en arrière (roll back) et restaurer le système dans l’état exact où il se trouvait avant une mise à jour

Les systèmes atomiques peuvent avoir chacun leurs particularités : ainsi, NixOS (lisez à son sujet notre récente dépêche), Endless OS, les images Universal Blue, Vanilla OS, MicroOS ou encore AerynOS, mais aussi ChromeOS et Android ne fonctionnent pas tout à fait de la même façon, bien qu’ils partagent ces trois principes en commun. Mais le gros joueur dans ce domaine, c’est Fedora : Renault nous expliquait il y a bientôt cinq ans comment les expérimentations du projet ont donné naissance à Silverblue et comment ce dernier s’utilisait. Depuis, Silverblue a été décliné en versions Plasma, Sway, Budgie et bientôt COSMIC et Plasma Mobile ; certaines de ses briques sont amenées à évoluer, comme l’expliquait Timothée Ravier à la sortie de Silverblue 41 en automne dernier (voir la section Notes), mais les principes fondamentaux restent les mêmes, et vous pouvez les retrouver décrits dans la documentation commune (en version bêta) des Fedora atomiques. Ravier les rappelle dans un récent entretien qu’il nous a accordé (à paraître après le 21 avril) et nous partage son espoir de voir un jour l’atomique devenir le modèle par défaut pour Fedora :

Je l’espère ! Il est impossible de donner une échéance et cela ne dépend pas vraiment de moi. La difficulté la plus importante est la prise en charge du matériel et les pilotes qui ne sont pas intégrés dans Fedora. C’est un problème que l’on ne peut pas résoudre dans Fedora à cause des contraintes légales et qui sont traitées par le projet Universal Blue, dont la variante Bazzite est très populaire.

Capture d’écran du site officiel de Bazzite

Les possibilités ouvertes par cette approche sont telles qu’elles inspirent beaucoup de Linuxiens à assembler leur propre bureau Linux atomique, y compris hors des mainteneurs de distributions : c’est le cas de Jorge Castro et de Thibault Martin. Mais Martin n’est pas le premier à avoir eu l’idée parmi la communauté GNOME : il cite un billet d’Adrien Vovk paru en octobre dernier, titré « Un bureau pour tous », et qui appelle déjà à s’appuyer sur GNOME, et plus précisément le projet GNOME OS (lequel est déjà atomique), pour « construire un OS qui rend le bureau Linux utilisable pour les non-passionnés » :

Je pense à mes amis et à ma famille : ils ne méritent pas plus que nous d’être maltraités par les entreprises de la tech. Beaucoup d’entre eux adorent l’idée de Linux et sont d’accord avec nos valeurs, mais ont décidé de ne pas rester dessus après l’avoir essayé pour de vrai. Ils sont intéressés, mais juste pas assez intéressés pour surmonter nos barrières à l’entrée. Ils se moquent des paquets, des codecs, des pilotes, des brevets, des licences, ou de toutes ces choses qui sont devenues ce qu’on doit gérer en tant que passionnés de Linux. Je crois que beaucoup se mettront à se préoccuper de ces choses-là une fois qu’ils auront rejoint nos communautés, comme nous l’avons tous fait nous-même, mais à l’heure actuelle, ils ne nous rejoignent pas…

L’idée ne séduit pas que chez GNOME : Vovk dit lui-même avoir été inspiré par KDE, après que ceux-ci aient annoncé un projet similaire lors de la conférence Akademy en septembre 2024, sobrement baptisé « KDE Linux ». Et pour pallier les défauts que les devs reprochent à KDE neon, laquelle vieillit trop vite du fait d’être basée sur Ubuntu LTS, KDE Linux sera donc, lui aussi, un OS atomique et immuable : « les applis viendront de Flatpak (et peut-être aussi de Snap si ce n’est pas trop difficile et que l’UX est convenable) ». Et lui aussi aura vocation à s’adresser au plus large public possible, « des développeurs KDE aux utilisateurs et aux vendeurs de matériel ».

Or, pour atteindre un tel objectif d’universalité, Vovk considère que GNOME OS se doit d’être complètement immuable, sans permettre à l’utilisateur d’installer des paquets traditionnels, contrairement au « modèle immuable-hybride en vogue » qui est celui de Silverblue et ses dérivés (où il est possible de faire du layering pour installer des paquets de la distribution, faisant ainsi entorse à l’immuabilité) :

À mon avis, permettre l’overlay de paquets dissuade le développement de vraies solutions permanentes aux fonctionnalités manquantes dans l’OS, puisque les utilisateurs peuvent juste se reposer sur les surcouches. Au bout du compte, la nécessité d’installer des paquets pour contourner ces problèmes va juste garantir que personne n’utilisera les distributions immuables-hybrides de manière immuable, ce qui annule les bienfaits de l’immuabilité tout en soumettant l’utilisateur aux points de friction [sharp edges] supplémentaires qu’apporte l’immuabilité.

Comme le rappelle Vovk, cette idée a déjà été formulée par le fameux Lennart Poettering en mai 2022, dans un long billet où il détaille sa vision personnelle (« et non celle de mon employeur », qui à l’époque était soit Red Hat, soit Microsoft) de la direction dans laquelle le bureau Linux doit aller :

Avant toute chose, je pense qu’il faut se concentrer sur un design basé sur une image plutôt que sur des paquets. Pour la robustesse et la sécurité, il est essentiel de travailler avec des images reproductibles et immuables qui décrivent l’OS ou des grandes portions de celui-ci dans leur entièreté, plutôt que de toujours travailler avec des paquets détaillés façon RPM/dpkg. Ce n’est pas dire que les paquets ne sont pas pertinents (je trouve en réalité qu’ils ont beaucoup d’importance !), mais je pense qu’ils devraient être moins un outil de déploiement de code, mais plutôt un outil pour construire les objets à déployer. Une autre manière de voir la chose : tout OS construit ainsi doit être facile à répliquer sur un grand nombre d’instances, avec une variabilité minimale.

C’est donc bien un nouveau paradigme qui bouleverse les principes traditionnels des distros, selon lesquels les empaqueteurs se chargent d’assembler et distribuer toutes les applications qu’ils veulent rendre disponibles à leurs utilisateurs. Or, dans les préconisations de la documentation de l’outil Blue-build, dédié à la création d’images atomiques customisées, il faut au contraire « résister à la tentation d’intégrer tout l’univers » :

Les systèmes dans ce genre sont conçus autour d’un cœur petit, simple et efficace, maintenable et performant. Rappelez-vous que les mises à jour de l’image de base nécessitent un redémarrage, donc idéalement vous allez vouloir limiter sa taille – laissez Flatpak et d’autres outils de l’espace utilisateur s’occuper du reste.

Diapositive issue de la présentation « Bazzite: Building the Future of Linux Gaming Together » donnée par Kyle Gospodnetich et Noel Miller au salon SCALE 22x, le 8 mars 2025

Jorge Castro dit lui-même :

Je ne voulais pas refaire une autre distro. J’ai fait ça pendant dix ans [chez Canonical, NDLR], je ne voulais pas faire d’empaquetage, je comprends les difficultés que ça entraîne de faire une distro, je ne veux plus jamais refaire ça.

Et il ajoute :

Il nous faut avoir des applis en bac à sable, sans quoi autant faire nos valises et rentrer chez nous. Actuellement c’est flatpak via flathub. Malgré toutes les plaintes que vous pouvez lire sur le net au sujet de flatpak, il y a plein de monde qui en tire une bonne expérience. […] Et aussi nous avons abandonné tout l’aspect « allons empaqueter la planète entière nous-même » du modèle parce que nous savons que ça ne s’étend pas [it doesn't scale]. Ça veut dire que c’est aux développeurs d’applis de prendre en charge leur destin, et que c’est notre boulot de livrer tout ça à l’utilisateur. […] C’est aussi pour cela que nous ne sommes pas une distro – nous sommes trois distros, fedora pour la base, homebrew pour la ligne de commande, flatpak pour les applis à interface graphique. Oh et puisque vous avez aussi distrobox, n’importe quel autre paquet de distro.

Et évidemment, cet éloignement revendiqué du modèle de la bonne vieille distribution n’est pas sans causer quelques frictions, surtout au sein d’une communauté comme Fedora qui demeure avant tout dédiée à faire… une bonne vieille distribution. Le 21 janvier 2025, Michael Catanzaro demandait que Flathub devienne le dépôt Flatpak par défaut des Fedora, plutôt que le dépôt Flatpak de Fedora comme c’est le cas jusqu’alors, affirmant que ces flatpaks “maison” étaient « une source notable de problèmes de qualité », et citant des « plaintes de multiples développeurs upstream », notamment ceux du célèbre OBS qui sont allés jusqu’à réclamer formellement le retrait du Flatpak que Fedora distribue pour leur appli. Le conflit s’est depuis détendu et les développeurs d’OBS ont rétracté leur demande, mais pas sans que le Project Leader de Fedora Matthew Miller ne déclare sur la chaîne YouTube de Brodie Robertson que « les règles d’acceptation sur Flathub sont plutôt laxistes » et que rien ne garantissait l’absence de code malveillant dans leurs flatpaks, ce qui a provoqué une levée de boucliers et une clarification officielle de Flathub quant à leur processus de vérification. Miller a salué cette clarification et précisé sa pensée, et à l’heure actuelle, c’est toujours les dépôts de Fedora qui sont présélectionnés par défaut lorsqu’on cherche à installer un Flatpak via Logiciels ou Discover dans une Fedora.

Alors, faut-il imaginer un projet tout neuf et émancipé des distributions, comme GNOME et KDE aimeraient le faire, pour être digne d’être l’OS atomique dont l’Europe a besoin ? À moins que ce dont l’Europe ait besoin, ce n’est pas d’un seul mais de plusieurs OS atomiques ? C’est l’idée que défend openSUSE, qui propose aux gouvernements non pas d’adopter une seule et unique solution qui "surfe sur l’idée de souveraineté européenne", mais plutôt une stratégie multi-distributions, qui inclurait, au hasard, les propres projets atomiques d’openSUSE – Aeon (sous GNOME) et Kalpa (sous Plasma) :

L’idée globale dont les gouvernements ont besoin de débattre va au-delà du standard des distros. À l’âge du rançongiciel, du verrouillage dans le nuage et du capitalisme de surveillance, il est temps d’aller au-delà de la façon traditionnelle de penser les OS de bureaux. Le monde de l’open-source a déjà les outils pour avancer vers cette nouvelle façon de penser :

• L’immuabilité avec des mises à jour transactionnelles (MicroOS, Aeon, Kalpa, Kinoite)
• Une configuration système déclarative (Agama, Ansible)
• Des options de bureaux pour des besoins utilisateur variés (GNOME, KDE Plasma, Xfce)
• Des standards d’identités et d’authentification ouverts (LDAP, OpenID)
• Des formats de paquet transparents (Flatpak, RPM)

La gouvernance des Linux : suffit-il d’être libre pour être souverain ?

Ce second volet fera l’objet d’une dépêche future, à laquelle vous pouvez d’ores et déjà contribuer (comme à toutes les autres dépêches en cours de rédaction sur Linuxfr). À bientôt !

---

Notes

• Les Steam Deck sont vendus avec SteamOS, qui n’est pour l’instant pas disponible au téléchargement (Valve a déclaré vouloir le faire d’ici avril 2025), et qui est également un OS atomique. Bazzite est fortement inspiré de SteamOS et en reprend directement une partie de son code, publié sous licence libre par Valve.
• Un des signes distinctifs d’Universal Blue est son usage de bootc, qui permet purement et simplement de rendre des conteneurs bootables (ce que Jorge Castro résume par « Podman dans une boucle for » ; Colin Walters en parle dans une vidéo de Red Hat) et qui devrait bientôt être adopté par Fedora à son tour, en remplacement d’OSTree. Sur la feuille de route de ce projet, Timothée Ravier précisait en janvier dernier que, bien que ses propres machines reposent sur des conteneurs bootables, il considère que « ce n’est pas prêt pour l’usage général ».
• À l’heure actuelle, la distribution vitrine de Linux sur téléphones est sans doute postmarketOS. Les développeurs de celle-ci ont annoncé le 30 mars dernier travailler à une version immuable de pmOS, qui sera partiellement subventionnée par la fondation européenne NLnet (la question du financement des Linux sera abordée dans la 2ᵉ partie de cette dépêche).

Le site LinuxFr.org se dote en ce jour de nouveaux types de comptes (les comptes dits « Premium » et « Open »). Cette dépêche vise à détailler les différents avantages proposés par ces nouveautés, et à permettre à chacun et chacune de se positionner pour savoir comme ils ou elles souhaitent ou non faire évoluer leurs comptes basiques en version « Premium » ou « Open ». Ces offres sont susceptibles d’évoluer dans un futur proche, notamment en fonction de vos commentaires et retours de lectorat averti. La documentation du site sera mise à jour plus tard en fonction desdits retours et des éventuelles évolutions.

Nous espérons que cette segmentation et cette diversification de notre offre vous satisfera et permettra de dynamiser et de pérenniser notre site LinuxFr.org (notre trésorier vous remercie par avance).

Sommaire

• Les comptes dits « Premium »
• Les comptes dits « Open »
• Les comptes basiques (ou simples)

Les comptes dits « Premium »

Les comptes « Premium » sont disponibles pour sept fois le coût mensuel des comptes basiques, payable en euros ou en cryptomonnaie. Les NFT ne sont pas acceptés.

Les comptes « Premium » verront huit fois moins de publicité que les comptes basiques.

Les comptes « Premium » sont disponibles sans stockage de données personnelles sensibles au sens du RGPD.

Les données personnelles des comptes « Premium » ne sont transmises qu’à un dixième des partenaires habituellement utilisés pour les comptes basiques.

Les comptes « Premium » bénéficient de la législation française et seront modérés comme les comptes basiques.

Les comptes « Premium » permettent de renseigner son adresse XMPP ou son compte sur le Fedivers (souvent Mastodon).

Les comptes « Premium » permettent l’utilisation de caractères Unicode (dont les emojis), d’images et d’hyperliens dans les contenus et commentaires.

Les comptes « Premium » seront abonnés à deux fois moins de listes de diffusion et trois fois moins de réseaux sociaux que les comptes basiques.

Les comptes « Premium » disposent de deux fois plus de fonctionnalités d’intelligence artificielle que les comptes basiques.

Les comptes « Premium » verront le nombre de popups présenté divisé par quatre par rapport aux comptes basiques.

Les comptes « Premium » se verront présentés deux fois moins de liens sponsorisés ou de contenus sponsorisés que les comptes basiques.

Les comptes « Premium » disposent d’un identifiant unique en base de données dit « id ».

Les comptes « Premium » disposeront de deux fois plus de temps pour les fenêtres de validation des cookies ou de résolution des captchas.

Les comptes « Premium » peuvent être associés à des fournisseurs d'adresse de courriel privateurs.

Les comptes « Premium » disposent d'un espace nominatif permettant de publier sous leur nom leur propre contenu (une sorte d'espace de blog), dénommé « Journal ».

L'ouverture d'un compte « Premium » ne nécessite pas d'informations relatives à un casier judiciaire, ou la virginité d'icelui.

Il n'y a pas de lecture automatique / déclenchement automatique d'audio ou de vidéo pour les comptes « Premium ».

Les comptes « Premium » ont accès aux API du site.

Les comptes dits « Open »

Les comptes « Open » sont disponibles pour 2 fois le coût annuel des comptes basiques, payable en monnaies libres.

Les comptes « Open » ne verront que notre sélection de publicité libre, par rapport aux comptes basiques.

Les comptes « Open » auront les mêmes données personnelles stockées que les comptes basiques, et dans les mêmes conditions.

La moitié des données personnelles des comptes « Open » sera transmise qu’à la moitié de nos partenaires habituellement utilisés pour les comptes basiques.

Les comptes « Open » seront couverts par le droit français, mais leur modération sera comparable à celle des comptes basiques.

Les comptes « Open » permettent de publier sous licence libre et d’évoquer des thématiques comme les logiciels libres, les contenus libres et d’autres sujets liés à des licences libres.

Les comptes « Open » pourront utiliser une écriture inclusive, et des efforts seront faits pour que les contenus qui sont présentés à ces comptes et qui sont prévisualisés par la modération soient écrits de façon non discriminante, inclusive et ouverte.

Les comptes « Open » ne seront abonnés qu’aux listes de diffusion et réseaux sociaux sous licences libres parmi l’ensemble des listes de diffusion et réseaux sociaux auxquels nous abonnons les comptes basiques.

Les comptes « Open » peuvent gagner des prix mensuels.

Les comptes « Open » sont utilisables avec des protocoles normalisés, des formats ouverts et dans le respect de l'interopérabilité.

Les comptes « Open » disposent d’un avatar, image définie par la personne gérant le compte.

Il n'est pas nécessaire de contribuer au code du site pour disposer d'un compte « Open », même si cela est fortement recommandé.

Les comptes « Open » peuvent stocker deux fois plus d’informations dans la chaîne de blocs (en anglais « blockchain ») que les comptes basiques.

Les comptes « Open » verront, sous réserve d’utiliser le navigateur Firefox avec le greffon µBlock Origin, le nombre de popups présenté divisé par deux par rapport aux comptes basiques.

Les comptes « Open » peuvent venir nous voir sur notre stand sur les événements type Open Source Experience Paris par exemple.

Les comptes « Open » ne nécessitent pas d’en-têtes HTTP spécifiques, et ils seront dispensés de captchas.

Les comptes « Open » bénéficient d’un accès au code du site sous licence libre.

Les comptes basiques (ou simples)

Les comptes basiques sont gratuits (ne nécessitent pas d’un paiement initial ou régulier).

Les comptes basiques sont sans publicité.

Les comptes basiques sont créés avec un minimum de données personnelles, et celles-ci sont minimisées lorsqu’elles ne sont plus nécessaires.

Les données personnelles ne sont pas transmises ou vendues à des soi-disants partenaires qui seraient hypothétiquement soucieux ou non desdites données.

Les comptes basiques sont soumises aux règles de modération du site et à la législation française.

Les comptes basiques permettent de contribuer à la vie du site, de proposer des contenus et des commentaires.

Les comptes basiques sont optionnels, le site peut être lu sans avoir de compte. Voir les avantages d’avoir un compte.

Un compte basique n’implique pas d’être abonné à une liste de diffusion ou un réseau social.

Un compte basique n’est pas soumis à des popups intempestives.

Un compte basique n’a pas de captcha à résoudre.

Les comptes basiques ne sont pas soumis aux aléas d’une intelligence artificielle.

Les comptes basiques ne se voient présentés aucun lien sponsorisé ou de contenu sponsorisé (et arrêtez de nous écrire pour ça les pénibles du net).

Les comptes basiques n’ont pas de données stockées dans une chaîne de blocs.

Un compte basique n’est pas soumis à une validation de l’acceptation des cookies du site.

AgentJ est une solution anti-spam utilisé pour filtrer et bloquer les messages indésirables (spams) en entrée et en sortie.
Ce logiciel est une solution sous licence GNU Affero General Public License V3.

Voici une description générale de ses fonctionnalités :

• Filtrage du spam : Identifie les messages non sollicités ou suspects (spams) à l'aide d'algorithmes qui analysent le contenu, les adresses d'envoi, et d'autres facteurs.
• Apprentissage automatique : Utilise des techniques d'apprentissage automatique pour s'adapter aux nouveaux types de spam et améliorer son efficacité au fil du temps.
• Blocage des adresses : Peut bloquer ou mettre sur liste noire certaines adresses e-mail, domaines, ou adresses IP connues pour envoyer des spams.
• Authentification humaine : La première fois qu'un nouvel expéditeur vous contacte, un mail de confirmation lui est envoyé pour vérification
• Rapports et statistiques : Fournis des rapports pour suivre le nombre de spams bloqués, les tendances, et d'autres informations utiles pour les administrateurs.
• Personnalisation : Permet de définir des règles spécifiques, de créer des listes blanches (whitelist) et noires (blacklist), et d'adapter le niveau de filtrage en fonction des besoins.
• Gestion multi domaines mail distincts ou miroir.
• Rapport quotidien pour les utilisateurs qui les informe des mails en attente de déblocage.

Cette nouvelle version 2.1 amène son lot d’améliorations, mais elle est surtout marquée par une amélioration majeure : la gestion des mails envoyés / le filtrage de mail en sortie.

Filtrage de mails en sortie

Cela permet de gérer l’ensemble du flux de mails sortants.

Apprentissage des mails sortants

Cette fonctionnalité permet que, lors d’un envoi de mail par un utilisateur interne, les destinataires (to, cc et cci) soient automatiquement autorisés.
Nous retrouverons les adresses autorisées comme les adresses actuelles avec comme précision « autorisée par envoi de mail ».

Paramétrage du taux d’envoi de mail

L’objectif est de permettre le paramétrage du nombre de mails par heure, par utilisateur. Le paramétrage pourra se faire soit pour le domaine mail, soit pour un groupe d’utilisateur, soit pour un utilisateur.
Sur un compte utilisateur, il sera indiqué le taux en vigueur et l’usage actuel pour l’utilisateur.

Alerte sur évènements indésirables

Cette fonctionnalité permettra de paramétrer un envoi d’alerte à un ou des mails spécifiques.
Les alertes pourront être envoyées lors des événements suivant :
• Spam (le niveau considéré comme Spam sera réglable)
• Virus
• Dépassement du taux d’envoi

Recherche de mail

Nous avons ajouté une recherche de mail avancé pour l’administrateur.

Libération depuis le rapport mail

Maintenant, il n’est plus nécessaire de se loguer pour libérer un mail depuis le rapport quotidien envoyé par AgentJ un simple clique suffit.

Amélioration du tableau de bord

Nous avons amélioré le rendu du tableau de bord des statistiques

Prévisualisation sécurisée des emails

Vous pouvez désormais prévisualiser vos emails bloqués avant de décider de les libérer (ou non).

Test de performance

Nous avons effectué des tests de performance sur un VM avec 4 cœurs et 4 Go de RAM avec les paramétrages par défaut. AgentJ traite 10 000 mails en 11 min. Pour précision, les tests ont été effectués avec l’envoi de mail valides, car ils sont les plus longs en traitement comparé à des spams.

En ce mardi 18 mars 2025, la communauté du Projet Fedora sera ravie d’apprendre la disponibilité de la version bêta de Fedora Linux 42.

Malgré les risques concernant la stabilité d’une version bêta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 42 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 15 ou le 22 avril.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• Tester

Expérience utilisateur

• L’environnement de bureau GNOME est proposé dans sa version 48 ;
• L’environnement de bureau Xfce bénéficie de la version 4.20 ;
• L’environnement de bureau LXQt passe à la version 2.1 ;
• Le logiciel d’installation d’Anaconda devient une application Wayland native ;
• Anaconda a enfin une interface web UI pour l’étape du partitionnement ;
• Anaconda en profite pour également être une web UI par défaut pour Fedora Workstation ;
• L’édition KDE Plasma devient une édition à part entière, étant mise au même niveau que Fedora Workstation avec l’environnement GNOME ;
• L’écran de chargement lors du démarrage plymouth utilise simpledrm pour réduire l’attente qu’un GPU soit disponible ;
• L’environnement de bureau COSMIC bénéficie de sa propre édition Spin ;
• Activation de la mise à jour automatique par défaut pour la version atomique de KDE Plasma nommée Kinoite.

Gestion du matériel

• Amélioration de la prise en charge des webcams basées sur le protocole MIPI au lieu de USB dans les ordinateurs portables x86 ;
• L’Intel Compute Runtime, qui prend en charge notamment le fonctionnement de l’API OpenCL pour les processeurs Intel, a été mise à jour vers la version 24.39 qui signifie également une non prise en charge des processeurs d’avant 2020 (à partir de la 12ᵉ génération) ;
• Introduction de la pile Intel SGX pour permettre son utilisation dans le futur pour améliorer l’isolation et la protection mémoire en particulier pour les machines virtuelles ;
• Intégration du projet FEX dans les dépôts pour permettre l’exécution des programmes x86 / x86_64 depuis les architectures AArch64 ;
• L’installateur Anaconda utilise la norme GPT par défaut pour la table de partitionnement pour les architectures PPC64LE et s390x, l’architecture x86_64 et Aarch64 ayant déjà sauté le pas avec Fedora Linux 37 ;
• Les versions atomiques n’auront plus d’images compatibles avec l’architecture PPC64LE ;
• Le paquet du logiciel Zezere qui sert à automatiser l’installation et la configuration de systèmes IoT a été retiré des dépôts.

Internationalisation

• Mise à jour de l’entrée de saisie IBus 1.5.32 ;
• Son aide à la saisie pour le chinois ibus-libpinyin est aussi mise à jour à la version 1.16 ;
• Proposition d’une nouvelle aide à la saisie vocale avec Ibus Speech to Text via le paquet ibus-speech-to-text qui permet de faire de la reconnaissance vocale en local.

Administration système

• Les répertoires /usr/bin et /usr/sbin sont fusionnés ;
• DNF5 va proposer à l’utilisateur de supprimer les clés GPG qui ont expiré, ou qui ont été révoquées, évitant de devoir le faire à la main avec la commande rpmkeys --delete ;
• La commande fips-mode-setup a été retirée du paquet crypto-policies qui permet de rendre dynamiquement son système compatible avec les exigences du gouvernement américain concernant les modules cryptographiques. Cette option doit être activée lors de l’installation par d’autres moyens maintenant ;
• Le navigateur de fichiers pour Cockpit cockpit-navigator est remplacé par cockpit-files ;
• Les éditions dérivées de Fedora Workstation auront par défaut le pare-feu configuré avec l’option IPv6_rpfilter=loose, ce qui suit la politique appliquée pour l’IPv4 depuis Fedora 30 ;
• Ajout du paquet bpfman pour le déploiment et la gestion des programmes eBPF dans le système ;
• Réduction du nombre de règles SELinux liées au type unlabeled_t qui mènent à ne pas enregistrer dans le journal d’audit des erreurs détectées ;
• Mise à jour de l’outil de gestion de configuration Ansible à la version 11 ;
• Le serveur de proxy inverse Apache Traffic Server évolue vers sa 10ᵉ version ;
• La version de compatibilité PostgreSQL 15 a été retirée, PostgreSQL 16 reste la version par défaut ;
• Les utilitaires liés au projet OpenDMARC ont été mis dans des paquets individuels au lieu du paquet opendmarc qui les fournissait tous ;
• L’agent pam-ssh-agent a été supprimé des dépôts.

Développement

• La chaîne de compilation GNU bénéficie de GCC 15, binutils 2.44, glibc 2.41 et gdb 15 ;
• La chaîne de compilation LLVM progresse à la 20ᵉ version ;
• La boîte à outils Python nommée Django utilise la version 5.x ;
• Mise à jour du langage Go vers la version 1.24 ;
• Le langage Ruby brille avec la version 3.4 ;
• Le langage de programmation PHP s’impose de tout son poids à la version 8.4 ;
• Le compilateur du langage fonctionnel Haskell, GHC, passe à la version 9.8 et sa suite de paquets Stackage utilise la version 23 ;
• Le langage de programmation fonctionnel Idris dispose d’une mise à jour majeure vers sa 2ᵉ version ;
• Le langage de scripts Tcl/Tk a été mis à jour vers la 9ᵉ version ;
• La bibliothèque de calcul scientifique en Python NumPy passe à la version majeure 2 ;
• L’outil de développement de paquets Python Setuptools a été mis à jour vers la version 74 ;
• Mise à jour de la bibliothèque de compression zlib-ng à la version 2.2.x ;
• La bibliothèque graphique SDL utilise la version 3 pour assurer la compatibilité avec sa version 2 dorénavant ;
• Les anciennes versions de OpenJDK pour le langage Java à savoir 8, 11 et 17 ne sont plus fournies par les dépôts de Fedora mais devront être installés via un dépôt tiers tel que Adoptium Temurin dont le paquet adoptium-temurin-java-repository permet son activation ;
• Le paquet de compatibilité Python pour la version 3.8 a été retiré ;
• La bibliothèque Rust zbus version 1 a été supprimée, la version 4 ou supérieure reste proposée dans les dépôts ;
• La bibliothèque de compatibilité entre Rust et Python, PyO3, se voit retirer les anciennes versions 0.19, 0.20, et 0.21 ;
• L’utilitaire d’exécution des tests unitaires en Python python-pytest-runner est déprécié et sera supprimé dans un futur proche ;
• La bibliothèque de compatibilité entre GTK3 et Rust est marquée comme dépréciée et sera supprimée dans une prochaine version.

Projet Fedora

• Fedora Linux proposera des archives permettant d’être installé avec Windows Subsystem for Linux ;
• Les paquets RPM peuvent bénéficier de la fonction systemd sysusers.d pour créer des utilisateurs dédiés lors de l’installation des paquets RPM ;
• Les mises à jour de Fedora CoreOS passent de OSTree à OCI ;
• Les fichiers Kickstart seront distribués également comme des artéfacts OCI ;
• Activation par défaut de composefs pour les images atomiques bureautiques de Fedora Linux ;
• L’utilitaire edk2 est compilé avec des options de sécurité supplémentaires pour améliorer la sécurité des machines virtuelles reposant sur l’UEFI ;
• Les images live de Fedora Linux utilisent le système de fichiers EROFS en lieu et place de SquashFS ;
• Ajout d’un générateur de dépendances pour les extensions de GNOME Shell, permettant de lier la version de l’extension avec celle de gnome-shell à partir du fichier metadata.json de l’extension ;
• Redéfinition des dépendances de nombreux paquets de git vers git-core.

Tester

Durant le développement d’une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L’équipe d’assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l’élaboration d’un correctif.

C’est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une bêta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J’annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l’aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

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

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

En cas de bogue, n’oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N’oubliez pas de consulter les bogues déjà connus pour Fedora 42.

Bons tests à tous !

ATELIER du lundi 31 mars de 11h30 à 13h30 à Paris (participation en ligne possible).

Etes-vous prêts pour les échéances de 2026 et 2027 du Cyber Resilience Act (CRA) ?

Le CRA est un dispositif adpoté par la Commission Européenne en 2024 pour répondre à la vulnérabilité accrue aux cyberattaques des entreprises et services publics européens,. Il vise à renforcer la cybersécurité et la cyberrésilience des produits logiciels (et matériels qui comportent des éléments numériques) connectés.

Le premier guide de conformité au CRA dédié aux acteurs de l’open source, proposé par le CNLL et inno³ a pour objectif de faciliter la compréhension du CRA et les effets attendus, et de proposer des recommandations concrètes.

N'attendez pas pour commencer à évaluer vos obligations nouvelles à venir et les adaptations nécéssaires de vos processus, rejoignez l'atelier du 31 mars !

📅 Quand ? Le 31 mars de 11h30 à 13h30, la rencontre sera suivie d'un buffet pour les personnes sur place.

📍 Où ? 137 Boulevard de Magenta 75010 Paris (nombre de places limité, participation en ligne possible).

L'objectif est de rendre la session de discussion la plus active possible, n'hésitez pas à lire d'un œil critique et intéressé le guide en amont. Vous pouvez même nous envoyer dès aujourd'hui vos diverses questions ou remarques afin de nous aider à préparer l'atelier : mission-cra-cnll@framagroupes.org.

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…

🖥️ Prochain mini-webinaire : « Découvrir Parcours-PHP » 17 mars

Lundi 17 mars de 17h à 18h heure de Paris, à l’adresse https://scenari.org/visio/miniwebinaire.

Pour que la session colle au mieux aux besoins de la communauté, tu peux participer à ce fil de discussion sur le forum.

Situer Parcours-PHP.

Les enregistrements des mini-webinaires précédents sont sur la page dédiée de scenari.org et dans notre canal peertube.

Pour proposer des sujets, rends-toi sur ce fil de discussion.

💗 Parole de Scenariste

Les fonctionnalités souvent « originales » de SCENARI favorisent notre productivité. Facilité+++ de mise en ligne des contenus (FTP intégré), logique de « grains de contenu » et de réutilisation, chartes graphiques personnalisables => mise à disposition du même contenu à des entités différentes, affichage « dynamique » de plusieurs versions du même contenu (exemple : version originale de règlements alternant avec version résumée plus « pédagogique »)…

	Jean-Philippe Claude, dirigeant Organisme de Conseil et Formation. Vethyqua. Modèles utilisés : Opale, Optim, Dokiel

📣 Rappel : propose une communication/atelier pour les Rencontres Scenari 2025 avant le 11 mars !

Tu as jusqu’au 11 mars 2025 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 !

📣 Deux nouveaux outils autour de Scenari

Deux nouveaux outils ont été ajoutés à la page des « Outils autour de Scenari » :

1. Un outil pour exporter le référentiel ScoLOMFR afin de les utiliser dans Scenari.
2. Un autre outil pour exporter une bibliographie Zotero vers Opale ou Optim.

📣 Tu utilises Parcours ou Platine-suite ? Partage ton retour d’expérience

Katia a rejoint Kelis pour travailler sur les derniers outils Scenari pour la formation, notamment Parcours et Platine-suite.

Elle souhaite avoir des retours sur ton usage de ces deux outils si tu en utilises un.

Rends-toi sur son message sur le forum.

📣 Parler de Scenari aux Journées du Logiciel Libre (JDLL) à Lyon

Cette année les JDLL auront lieu le week-end du 24-25 mai 2025, à l’ENS de Lyon site René Descartes.

Tu es dans le coin, disponible et motivé pour y parler de ton usage de Scenari aux JDLL ?

Loïc peut t’aider sur la partie présentation de l’association, de la communauté et des principes de Scenari.

Tu as jusqu’au 16 mars pour faire une proposition de conférence ou atelier aux JDLL.

✨ Le savais-tu ?

Depuis la version 6.3 de Scenari, un bouton permet de vider d’un coup la corbeille d’un atelier. Plus besoin d’éliminer un par un les items.

Si tu utilises MySenari, nous te demandons de vider régulièrement tes corbeilles des ateliers afin d’économiser l’espace disque qui est partagé entre tous les utilisateurs et utilisatrices de MyScenari.

📊 Le chiffre du mois

	1372, C’est le nombre de membres sur le forum Scenari.

🦋 Scenari présent dans…

• Dans cette vidéo (à 7:28) liée au projet Pactes. Scenari est décrit comme un outil qui favorise l'accessibilité numérique.

Les calculatrices graphiques sont de lointains dérivés des ordinateurs de poche des années 1980, dans lesquelles subsiste cette capacité native à pouvoir être programmé.
J’en serais probablement resté à mon expérience de lycéen, et l’éternel combat Casio / Texas Instrument, s’il n’y avait pas eu un virage (pas forcément bien courbe) autour de Python dans la fin des années 2010.

Entre passion de l’informatique, doux rêveur, promesse de calculatrice libre et réalité du marché… j’avais l’envie de vous partager mes quelques heures de recherches et de réflexions sur le sujet.

Sommaire

• • Ordinateur de poche, calculatrice et langage BASIC
  • Une évolution de rupture
  • Libre - Un peu, beaucoup, à la folie, passionnément… pas du tout
  • Omega
  • Ma petite CASIO
  • NumWorks - L’esprit d’ouverture… ou pas
  • La magie du libre
  • Vers la fin des applications avancées

Ordinateur de poche, calculatrice et langage BASIC

Les ordinateurs de poche existent depuis les années 80 et ont fait le succès de sociétés telles que Sharp, Casio ou Psion. Ils se confondent avec les calculatrices les plus évoluées, et restent aujourd’hui les seules survivantes de ces deux mondes.

Elles sont programmables, majoritairement dans de nombreux dialectes du langage BASIC, directement sur la machine, mais aussi dans d’autres langages plus bas niveau, souvent via un ordinateur plus conventionnel.

Une évolution de rupture

Dans la fin des années 2010, deux évolutions sont poussées dans le monde des calculatrices : le « mode examen » et le besoin d’un langage plus moderne, beaucoup se tournant vers le langage Python.

C’est l’occasion pour NumWorks de se lancer dans ce marché très spécial. Deux point sont mis en avant :

• Le langage Python comme le langage de programmation utilisateur (alors que ce n’est qu’un autre ajout pour les constructeurs historiques).
• Un modèle « libre », qui as fait beaucoup parler de ce nouveau venu, notamment ici.

Libre - Un peu, beaucoup, à la folie, passionnément… pas du tout

La mise en application s’est vite montrée moins claire. La libération matérielle tient, à en juger par leur GitHub, à huit fichiers STL, sous licence CC-BY-NC-ND, et dont la dernière mise à jour date de 2020. Il est donc interdit d’en faire des modifications et/ou une utilisation commerciale… une liberté relative.

Le système d’exploitation, nommé epsilon, qui offre une bonne implémentation de Python, mais qui souffre de plusieurs problèmes de jeunesse, est bien disponible… mais également sous cette même licence CC-BY-NC-ND.

Omega

Critiquée pour cette différence entre le discours commercial de liberté, et la réalité de la licence, en mai 2018 elle fut finalement modifiée en CC-BY-NC-SA, autorisant donc la modification et la redistribution de versions modifiées. Il en naîtra notamment Omega un dérivé communautaire d’Epsilon, alors en version 11.

Ma petite CASIO

Dans un esprit de découverte, j’ai eu l’envie d’explorer moi-même ce nouveau monde du Python sur calculatrice. Peut-être un peu entrainé par les différentes lectures sur la calculatrice libre que je lisais un peu partout.

Cependant, l’interprétation assez personnelle de NumWorks du libre, et l’obligation de passer par leur site pour communiquer avec la calculatrice a orienté mon choix vers une Casio Graph 90E.

Pas que cette dernière soit plus libre, bien au contraire… juste qu’elle est simplement reconnue comme une clef USB pour y transférer des éléments depuis l’ordinateur et qu’elle a une communauté plus importante.

Le micro-python qui y est intégré est limité, et s’il permet de faire des choses… on voit que le constructeur s’est limité à ce qui était juste nécessaire. Ce qui limite les possibilités laissées aux utilisateurs.

J’aurais pu en rester là, et c’est même un peu ce que j’ai fait jusqu’à peu.

NumWorks - L’esprit d’ouverture… ou pas

Alors que j’explorais d’autres domaines, et que ma Casio prenait la poussière, le monde évoluait, et NumWorks en était à la 4ᵉ variante matérielle de sa calculatrice révolutionnaire.

La définition du « Libre » par l’entreprise avait elle aussi eu le temps d’évoluer.

Epsilon depuis sa version 16 du 30 novembre 2021, verrouille les calculatrices pour n’autoriser que les systèmes officiels du constructeur. Un peu à l’image des consoles de jeu, que certains hackent pour installer des homebrew ou firmware modifiés, il en devient de même pour la « calculatrice libre » : on chasse les évolutions communautaires.

Epsilon en est aujourd’hui (28 février 2025) à sa version 23… sans volonté affichée d’ouverture supplémentaire. Le dépôt GitHub n’affiche pas de licence dans ses métadonnées, mais une mention « Copyright - All rights reserved. NumWorks is a registered trademark. » figure en bas de la page de présentation.

Oméga a mis en pause son développement depuis février 2024, renvoyant vers une autre alternative Upsilon, qui ne s’installe pas mieux sur une calculatrice NumWorks verrouillée… mais quelqu’un a compilé pour la CASIO.

La magie du libre

C’est M. Bernard PARISSE qui a compilé une version d’Upsilon comme application pour la génération de CASIO que je possède. Je vous invite à en lire tous les détails sur la page de son projet.

Arrivant donc à avoir le meilleur des mondes, le travail de NumWorks, les additions de la communauté et plus de puissance supplémentaire de ce matériel.

Mais cela est conditionné par la possibilité de pouvoir faire fonctionner des applications tierces sur ces calculatrices…

Vers la fin des applications avancées

Il y a historiquement deux méthodes pour développer des applications pour ces calculatrices.

Un langage haut niveau, qui est un dialecte BASIC, une adaptation de Python, ou d’autres langages plus ou moins évolués, qui sont directement modifiables sur l’appareil (même si le clavier d’une calculatrice n’y est pas toujours optimal).

Un langage bas niveau, typiquement du C ou même de l’assembleur, édité et compilé sur un ordinateur puis transféré vers la calculatrice (même si certaines machines Sharp pouvaient se programmer en C directement sur la machine).

Et c’est un point que met en valeur Bernard PARISSE dans son argumentaire sur Upsilon pour CASIO : l’ouverture de ce constructeur aux développements tiers.

Mais voila, ce n’est pas forcément le sens que prennent les constructeurs, même chez CASIO.

Le test communautaire de la CASIO Math+, qui succède à la Graph 90E, ne permet pas ces applications tierces développées en langage de bas niveau, et la conclusion sur ce point est tout sauf optimiste.

---

Voila qui conclut ce petit tour dans le sous-domaine de l’informatique qu’est celui des calculatrices graphiques, même si ce n’est probablement pas ce qui vous servira dans une discussion autour de la machine à café (sauf, peut-être, si vous êtes prof de math).

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 3.0 RC3 du 10 février 2025 (en anglais).

Nous sommes ravis de partager la troisième version candidate de GIMP 3.0 pour ce qui (nous l'espérons) sera la dernière série de tests communautaires avant la version stable ! Cette version fait suite à la récente conférence GIMP 3 and Beyond de Jehan au FOSDEM 2025.

Sommaire

• Corrections de bogues et changements importants
  • Nouvelle version de GTK3
  • Améliorations du graphe d'images
  • Changements dans Projection Thread-safe
  • Procédures privées
• Améliorations
  • Script-fu
    • API Filtre
    • Nouvelle syntaxe de passage des arguments par noms
  • Formats de fichiers
    • PSD
    • DDS
  • AppImage: c'est officiel !
  • Divers
• GEGL
• Statistiques
• Autour de GIMP
  • Miroirs de téléchargement
  • Comment citer GIMP dans la recherche
• Télécharger GIMP 3.0 RC3
• Et ensuite ?

Corrections de bogues et changements importants

Alors que nous réduisions les quelques derniers bogues majeurs à néant, nous avons effectué un certain nombre de modifications qui selon nous nécessitent un sérieux coup d’œil de la communauté.
Jetez-en donc un, d’œil, sur les points suivants lorsque vous essayerez la Release Candidate:

Nouvelle version de GTK3

Juste à temps pour GIMP 3.0, une nouvelle version de GTK3 est sortie !
Entre autres changements, GTK 3.24.48 inclut des correctifs pour plusieurs bugs affectant GIMP avec des patchs initialement fournis par Jehan, comme un crash dans Wayland lors du déplacement de calques et des problèmes de texte dans certains widgets avec des langues de droite à gauche. Nous tenons à remercier Carlos Garnacho et Matthias Clasen pour leur aide sur ces patchs respectifs.

GTK 3.24.48 ajoute également la prise en charge de la version 2 de xdg_foreign pour Wayland (la v1 reste prise en charge en tant que solution de secours). Plus précisément, l'absence de cette prise en charge provoquait le blocage de GIMP avec certaines actions sur KDE/Wayland, ce qui est désormais corrigé.

En raison de ces problèmes (certains d'entre eux rendant GIMP vraiment instable sur Wayland), nous recommandons aux empaqueteurs de mettre à jour vers la dernière version de GTK3 lors de l'empaquetage de notre RC3. Cependant, veuillez nous informer si vous remarquez des régressions ou d'autres problèmes résultant de la nouvelle version de GTK3.

Améliorations du graphe d'images

Grâce à l'édition non destructive dans GIMP, les utilisateurs peuvent désormais empiler plusieurs filtres les uns sur les autres. Ces filtres fonctionnent généralement dans un format à haute résolution de bits, de sorte que les informations de l'image ne sont pas perdues. Cependant, la sortie de chaque filtre était convertie vers et depuis la résolution de l'image d'origine lors de l'empilement. Ainsi, si l'image n'était que de 8 bits, une grande quantité d'informations était perdue dans ces conversions constantes. Jehan a résolu ce problème en convertissant uniquement au format de l'image lorsque le filtre est censé être fusionné, plutôt que dans des piles non destructives. Comme il s'agit d'un changement important dans le fonctionnement des filtres, nous souhaitons que davantage d'utilisateurs testent ce changement pour détecter d'éventuelles régressions.

Changements dans Projection Thread-safe

Lorsque des modifications sont apportées à une image (comme une peinture), la projection de l'image doit être « vidée » pour afficher les nouvelles modifications à l'écran. Certains aspects de ce processus n'étaient pas « thread-safe », ce qui signifie que lorsque votre ordinateur utilisait plusieurs threads pour accélérer le travail, ils pouvaient entrer en conflit les uns avec les autres et provoquer un plantage. Cela a été observé dans notre fonctionnalité d'expansion automatique de calques. Jehan a corrigé la fonction pour qu'elle soit entièrement thread-safe. Cependant, les modifications apportées au multithreading peuvent laisser des bugs bien cachés, donc des tests communautaires supplémentaires seraient utiles.

Procédures privées

Le navigateur de base de données procédurale de GIMP montre aux développeurs de greffons et de scripts toutes les fonctions auxquelles ils peuvent accéder. Jusqu'à présent, il affichait également les fonctions « privées » qui ne sont utilisées qu'en interne. Jehan a ajouté un indicateur pour masquer ces fonctions. Dans un premier temps, nous avons ratissé trop large et caché certaines fonctions publiques importantes. Bien que nous ayons corrigé ces cas, nous aimerions que la communauté nous donne plus de détails pour nous assurer que nous n'avons oublié aucune fonction publique mal étiquetée.

Améliorations

Bien que nous soyons toujours en phase de gel des fonctionnalités majeures jusqu'à la version stable de GIMP 3.0, quelques améliorations mineures et autonomes ont été apportées aux greffons.

Script-fu

API Filtre

Le nouvel appel PDB (gimp-drawable-merge-filter) permet aux auteurs de Script-fu d'utiliser des étiquettes pour spécifier les propriétés des filtres. Cela donnera aux utilisateurs de Script-fu la même flexibilité pour appeler et mettre à jour les filtres que les développeurs de greffons C et Python ont dans l'API GIMP 3.0. À titre d'exemple, voici un appel au filtre Emboss :

(gimp-drawable-merge-new-filter mask-emboss "gegl:emboss" 0 LAYER-MODE-REPLACE 1.0 "azimuth" 315.0 "elevation" 45.0 "depth" 7 "type" "emboss")

Vous pouvez voir plus d'exemples dans notre dépôt de scripts.

Nouvelle syntaxe de passage des arguments par noms

Dans Script-Fu, toutes les fonctions générées à partir de la procédure PDB des greffons doivent désormais être appelées avec une toute nouvelle syntaxe d'argument nommé, inspirée de la variante Racket de Scheme.

Par exemple, disons que votre greffon souhaite appeler le greffon Foggify, au lieu d'appeler :

(python-fu-foggify RUN-NONINTERACTIVE 1 (car (gimp-image-get-layers 1)) "Clouds" '(50 4 4) 1.0 50.0)

Vous devez maintenant appeler :

(python-fu-foggify #:image 1 #:drawables (car (gimp-image-get-layers 1)) #:opacity 50.0 #:color '(50 4 4))

Cela présente quelques avantages :

• des appels beaucoup plus auto-documentés, d'autant plus que certains greffons ont beaucoup d'arguments (on pouvait donc se retrouver avec des fonctions avec une douzaine d'entiers ou de flottants et c'était très déroutant) ;
• l'ordre des arguments n'a plus d'importance ;
• vous pouvez ignorer les arguments lorsque vous les appelez avec des valeurs par défaut ;
• cela permet d'améliorer les procédures des greffons dans le futur en ajoutant de nouveaux arguments sans casser les scripts existants.

Ce dernier point en particulier est important, et l'ordre des arguments n'avait plus d'importance lors de l'appel de procédures PDB depuis l'API C, ainsi que toutes les liaisons introspectées. Script-Fu était la seule interface restante dont nous disposions qui se souciait encore de l'ordre et du nombre d'arguments. Ce n'est plus le cas et c'est donc un grand pas vers une API beaucoup plus robuste pour GIMP 3 !

Formats de fichiers

Toutes les modifications apportées aux greffons de chargement d'images sont vérifiées avec le cadriciel de tests automatisés créé par Jacob Boerema pour éviter les régressions.

PSD

En plus des corrections de bogues telles que l'enregistrement correct des images fusionnées CMJN, Jacob Boerema a ajouté la prise en charge du chargement des fichiers PSD LAB 16 bits par canal. Il a également mis à jour la boîte de dialogue d'exportation PSD pour utiliser les fonctions d'exportation de métadonnées intégrées de GIMP.

DDS

CMYK Student a implémenté la prise en charge très demandée du chargement d'images DDS avec prise en charge BC7. Jacob Boerema a travaillé pour corriger la compatibilité avec les fichiers DDS exportés à partir d'anciennes versions de GIMP.

AppImage: c'est officiel !

Après neuf mois d'incubation (le nombre est une simple coïncidence 🙂), nous présentons un « nouveau » format de distribution pour les utilisateurs Linux : .AppImage. Au départ, nous l'utilisions comme format interne pour les tests, comme déjà évoqué dans des articles précédents. Les efforts de Bruno Lopes nous ont permis d'améliorer le processus de construction. Nous sommes maintenant confiants avec l'AppImage générée et nous avons donc pour objectif de la rendre officielle.

En tant que package officiel en amont, aucun greffon tiers sophistiqué ou autre binaire arbitraire qui ne soit pas une dépendance de GIMP n'est ajouté pour ne pas le « surcharger ». C'est ce que certains appellent GIMP « vanilla », un GIMP propre mais complet pour la production (c'est-à-dire pour une utilisation générale).

Comme tout format d'empaquetage, il a ses propres caractéristiques et limites. Dans le cas de l'AppImage de GIMP, les outils inclus tels que gimp-console* et gimp-debug-tool* nécessitent une extraction préalable du fichier .AppImage avec la commande --appimage-extract. De plus, en partie à cause de la conception d'AppImage, les commandes qui pointent vers $PWD ne fonctionneront pas. Ces deux limitations de fonctionnalités sont les seules connues à ce jour. Donc, si vous en trouvez d'autres ou même des bogues, veuillez les signaler sur notre outil de suivi.

Divers

• Il est maintenant plus facile de charger des images depuis Google Drive ainsi que d'autres plateformes distantes ou dans le cloud, sans avoir a sélectionner un format de fichier pour essayer de l'ouvrir.

• Notre processus de création génère désormais des icônes supplémentaires avec l'extension -rtl, qui sont automatiquement utilisées avec les langues s'écrivant de droite à gauche. Les icônes de flèches gauche et droite en sont un exemple : elles sont désormais orientées dans la bonne direction dans les deux types de langues.

• Les développeurs de greffons n'ont plus besoin de créer des boutons de sélection de fichiers personnalisés - GimpProcedureDialog les crée désormais automatiquement lorsqu'un paramètre de type de fichier est utilisé. Vous pouvez également spécifier si le bouton sert à ouvrir ou à enregistrer des fichiers et des dossiers.

• Rupert Weber a continué ses efforts pour nettoyer notre greffon BMP. De plus, il travaille actuellement à ajouter la prise en charge de l'importation de profils de couleurs dans les BMP, qui, espérons-le, sera prête dans une future version.

• CMYK Student a mis à jour le greffon ICNS avec une nouvelle prise en charge des types d'icônes « ic05 » et des formats d'icônes ARGB. Ils ont également corrigé un bogue lors du chargement d'anciens formats ICNS sans masque de transparence. Lukas Oberhuber a aidé à diagnostiquer et à résoudre un bogue connu dans le format ICNS qui faisait que notre icône macOS affichait des pixels brouillés dans les petites tailles.

GEGL

La version 0.4.54 de GEGL contient également quelques améliorations et corrections de bogues. Thomas Manni a mis à jour le filtre Noise Spread pour éviter les bogues lorsqu'il est appliqué à des groupes de calques vides. Jonny Robbie a ajouté de nouvelles options et de nouveaux types de papier au filtre Negative Darkroom, et a optimisé certaines opérations en virgule flottante dans GEGL dans son ensemble.

Statistiques

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

• 85 rapports ont été fermés comme RÉPARÉS ;
• 56 demandes de fusion ont été acceptées ;
• 335 commits ont été poussés ;
• 19 traductions ont été mises à jour : basque, bulgare, catalan, chinois (Chine), danois, néerlandais, finnois, géorgien, italien, norvégien nynorsk, persan, portugais, slovaque, slovène, espagnol, suédois, turc, ukrainien, vietnamien.

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

• 13 développeurs pour le code principal : Jehan, Alx Sa, Jacob Boerema, Lloyd Konneker, Anders Jonsson, Thomas Manni, Bruno, Daniele Forsi, Lloyd Konneker, Lukas Oberhuber, Rupert, cheesequake, Øyvind Kolås ;
• 10 développeurs de greffons ou modules : Alx Sa, Jacob Boerema, Jehan, Rupert, Lloyd Konneker, Anders Jonsson, Bruno, Daniel Novomeský, Daniele Forsi, lillolollo ;
• 19 traducteurs : Alan Mortensen, Alexander Shopov, Nathan Follens, Kolbjørn Stuestøl, Hugo Carvalho, Asier Sarasua Garmendia, Ngọc Quân Trần, Jordi Mas, Marco Ciampa, Sabri Ünal, Anders Jonsson, Danial Behzadi, Ekaterine Papava, Jiri Grönroos, Jose Riha, Luming Zh, Martin, Rodrigo Lledó, Yuri Chornoivan ;
• 1 Concepteur de thème : Alx Sa ;
• 6 contributeurs pour la compilation, l’empaquetage ou l’intégration continue : Bruno, Jehan, Lloyd Konneker, Alx Sa, Rupert, Jacob Boerema.

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

• GEGL 0.4.54 est composé de 11 commits de 16 contributeurs : Øyvind Kolås, Alexander Shopov, Hugo Carvalho, JonnyRobbie, Alan Mortensen, Anders Jonsson, Asier Sarasua Garmendia, Bartłomiej Piotrowski, Jehan, Martin, Nathan Follens, Nils Philippsen, Rodrigo Lledó, Sam L, Thomas Manni, Yuri Chornoivan ;
• ctx a enregistré 233 commits depuis la sortie de RC2 par 1 contributeur : Øyvind Kolås ;
• gimp-data a enregistré 6 commits de 4 contributeurs : Bruno, Jehan, Alx Sa, Andre Klapper ;
• gimp-test-images (nouveau référentiel pour les tests de prise en charge des images) a enregistré 5 commits de 2 contributeurs : Jacob Boerema, Alx Sa ;
• la version gimp-macos-build (scripts de packaging macOS) a eu 6 commits par 2 contributeurs : Lukas Oberhuber, Bruno ;
• la version flatpak a eu 12 commits par 3 contributeurs après la version RC2 : Bruno Lopes, Jehan, Hubert Figuière ;
• notre site web principal a eu 42 commits par 6 contributeurs : Jehan, Alx Sa, Bruno, Jacob Boerema, Andre Klapper, Petr Vorel ;
• notre site web de développement a eu 18 commits par 5 contributeurs : Jehan, Bruno, Lukas Oberhuber, Alx Sa, Anders Jonsson ;
• notre documentation 3.0 comptait 373 commits de 13 contributeurs : Andre Klapper, Kolbjørn Stuestøl, Nathan Follens, Jacob Boerema, Alan Mortensen, Yuri Chornoivan, Dick Groskamp, ​​Jordi Mas, Alevtina Karashokova, Alx Sa, Anders Jonsson, Daniele Forsi, Hugo Carvalho.

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 divers 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

Depuis la publication de la nouvelle version 3.0RC2, deux nouveaux miroirs ont été ajoutés :

• Saswata Sarkar, Gurugram, Inde ;
• Hoobly Classifieds, États-Unis.

Les miroirs sont importants car ils aident le projet en répartissant la charge pour 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.

Comment citer GIMP dans la recherche

GIMP est souvent utilisé dans la recherche et est donc cité dans diverses publications scientifiques. Un chercheur utilisant GIMP pour le traitement d'images astronomiques nous a contactés pour savoir comment citer GIMP correctement, d'autant plus qu'il est utilisé pour effectuer une étape importante de son algorithme.

Comme cela semble être une question intéressante, nous avons mis à jour notre page « Citing GIMP and Linking to Us » avec une nouvelle sous-section « Citing GIMP in research » contenant la conclusion de cette discussion.

En particulier, une entrée BibTex, destinée aux chercheurs utilisant LaTeX pour gérer leur bibliographie, est disponible sur ce lien pour simplifier votre travail. Par exemple, disons que vous utilisez ce RC3 pour vos recherches, vous pouvez citer GIMP avec cette entrée :

@software{GIMP,
    author = {{The GIMP Development Team}},
    title = {GNU Image Manipulation Program (GIMP), Version 3.0.0-RC3. Community, Free Software (license GPLv3)},
    year = {2025},
    url = {https://gimp.org/},
    note = {Version 3.0.0-RC3, Free Software}
}

Merci à Cameron Leahy pour ce morceau de code BibTex !

Télécharger GIMP 3.0 RC3

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

• Linux AppImages pour x86 et ARM (64 bits) ;
• Linux Flatpaks pour x86 et ARM (64 bits) ;
• Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits) ;
• Paquet MSIX (GIMP Preview) 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.).

Et ensuite ?

Nous apprécions vraiment tous les tests et commentaires de la communauté que nous avons reçus au cours des deux dernières versions candidates !
Nous espérons que ce sera la dernière version candidate avant la version stable 3.0. Notre objectif est maintenant de terminer la résolution des quelques bugs restants dans notre liste de jalons 3.0, tout en gardant un œil sur les nouveaux rapports résultant des changements dans RC3.

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

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.