Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

GIMP 3.0 RC2 est sorti

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

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

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

GIMP 3.0 RC2: écran de démarrage

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

Sommaire

Corrections de bugs importantes

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

Migration des paramètres de la 2.10

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

Console Windows

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

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

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

GIMP 3.0.0 RC2 : le package officiel de macOS contient désormais Pango sans polices cassées

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

Intégration de darktable

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

Améliorations

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

API de filtre GEGL

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

Applying filters through libgimp 3.0.0 API (Script-fu et al.) - GIMP 3.0.0 RC2

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

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

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

Espaces de fusion de calques et composition dans les fichiers XCF

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

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

Paquets

AppImage

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

Flatpak

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

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

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

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

Améliorations du greffon BMP

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

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

Mises à jour diverses

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

History search in Python Console - GIMP 3.0.0 RC2
Recherche dans l’historique de commande (console Python) - GIMP 3.0.0 RC2

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

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

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

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

Aperçu des changements depuis la version 2.10

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

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

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

GEGL

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

Statistiques de sortie

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

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

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

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

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

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

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

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

Autour de GIMP

Miroirs de téléchargement

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

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

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

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

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

Changements dans les miroirs

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

  • Sahil Dhiman, Mumbai, Inde

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

Financer des exécuteurs ("runner") GitLab

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

Télécharger GIMP 3.0 RC2

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

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

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

🛈 Notes:

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

Et ensuite ?

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

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

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

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

Commentaires : voir le flux Atom ouvrir dans le navigateur

GIMP 3.0 RC1 est sorti

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

Nous sommes très heureux de partager la première version candidate de la très attendue GIMP 3.0 ! Nous avons travaillé dur depuis notre dernière mise à jour de développement pour la préparer, et nous avons hâte que tout le monde puisse enfin voir le résultat.

GIMP 3.0 RC1: écran de démarrage

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

Alors, qu’est-ce qu’une « version candidate » (release candidate, RC, en anglais) exactement ? Une version candidate est quelque chose qui pourrait être prêt à être GIMP 3.0, mais nous voulons que la communauté la plus large la teste en premier et rapporte les problèmes qu’elle trouve. Si les retours des utilisateurs ne révèlent que des bugs mineurs et faciles à corriger, nous résoudrons ces problèmes et publierons le résultat sous la forme de GIMP 3.0. Cependant, nous espérons et nous nous attendons à ce qu’un public beaucoup plus large essaie la 3.0 RC1 — y compris de nombreuses personnes qui n’ont utilisé que la 2.10 jusqu’à présent. Si des bugs et des régressions importants sont découverts et nécessitent des modifications de code substantielles, nous devrons peut-être publier une deuxième version candidate pour des tests plus approfondis.

Sommaire

Nouveaux graphismes

Icônes de Wilber

Le logo actuel de Wilber a été créé par Jakub Steiner pour GIMP 2.6 en 2008 ! Bien qu’il s’agisse toujours d’un logo fantastique, les tendances en matière de design ont quelque peu changé au cours des seize dernières années et l’apparence plus détaillée de Wilber détonne sur les ordinateurs de bureau modernes.

C’est pourquoi, en collaboration avec d’autres contributeurs, Aryeom a développé notre nouveau logo pour GIMP 3.0 !

New Wilber Icon

Nouvelle icône de Wilber, par Aryeom (CC by-sa 4.0)

Si vous souhaitez en savoir plus sur les choix de conception, d’utilisation et les variantes de conception, veuillez consulter notre guide du logo. Nous avons également documenté l’histoire du logo Wilber.

Écran de démarrage (Splash Screen)

Notre magnifique nouvel écran d’accueil (présenté en haut de cet article) a été créé par le contributeur et artiste de longue date Sevenix ! Vous pouvez voir plus de ses réalisations sur sa page d’art personnelle.

À l’avenir, nous prévoyons de changer plus souvent l’image de démarrage pour mettre en valeur toutes sortes d’œuvres créées avec GIMP (photographie, illustration, design…).
À ce sujet, nous avons aussi créé une page d’archive des écrans de démarrage pour garder en mémoire les œuvres présentes et passées contribuées par des artistes au projet.

Améliorations du thème d’icônes Legacy

L’une des principales améliorations apportées par le portage GTK3 est que les icônes vectorielles de l’interface utilisateur s’adaptent désormais plus proprement à vos préférences. Cependant, notre thème d’icônes Legacy était principalement constitué d’images raster (PNG), il ne pouvait donc pas tirer parti du système de mise à l’échelle de GTK3. Le contributeur Denis Rangelov a relevé le défi de taille de recréer les icônes d’outils Legacy en SVG. Désormais, les deux thèmes d’icônes de GIMP sont superbes sur les écrans HiDPI !

Vectorized Legacy Icon theme

Icônes d’outils du thème Legacy Icon à l’échelle par Denis Rangelov (CC by-sa 4.0)

Le travail n’est pas terminé, car de nombreuses icônes ne sont toujours pas adaptatives et certaines icônes sont toujours manquantes. Denis a exprimé son intérêt à continuer d’améliorer le thème d’icônes Legacy, nous espérons donc le renommer Classic lorsque ce projet sera terminé, pour montrer qu’il est désormais bien maintenu.

Invasion de l’espace colorimétrique

L’un des changements clés de la version 2.99.18 a été l’amélioration massive de la gestion des couleurs dans GIMP. Comme ce travail n’était pas entièrement terminé dans la version 2.99.18, il a constitué un obstacle majeur à la sortie de la version 3.0 RC1.

Depuis cette version, nous avons trouvé et corrigé un certain nombre de bugs et de zones manquantes qui devaient être compatibles avec l’espace colorimétrique. Nous avons également examiné les rapports de l’experte en couleurs Elle Stone pour nous assurer que les valeurs de couleur affichées par GIMP sont aussi précises que possible. En même temps, il est très important de garantir que les fichiers de projet XCF créés dans GIMP 2.10 et avant s’afficheront de la même manière lorsqu’ils sont ouverts dans 3.0. Par exemple, l’un des premiers logos Google a été créé dans GIMP — et si vous ouvrez le fichier de projet XCF d’origine dans GIMP 3.0 RC1, il apparaît toujours de la même manière qu’à sa création en 1998 !
Par conséquent, nous avons examiné en profondeur les différents modes de calque pour garantir que l’engagement en matière de compatibilité soit conservé pour cette version.

L’invasion de l’espace colorimétrique est un projet de longue haleine, qui se poursuivra après la sortie de GIMP 3.0.

Finalisation de l’API publique

Une autre tâche qui devait être terminée avant la sortie de la version 3.0 est de finaliser l’API publique. Depuis notre dernier article, nous avons terminé les changements majeurs restants — le remplacement de toutes les instances de nos structures de couleurs personnalisées GimpRGB par la GeglColor mieux gérée en termes de couleurs et l’amélioration de nos formats de tableau afin que le nombre d’éléments n’ait pas à être spécifié séparément. Ce travail a été un long processus de la part de Jehan et Lloyd Konneker, avec beaucoup de tests de bon fonctionnement et de retours de la part d'Anders Jonsson.

En outre, un certain nombre de fonctions ont été ajoutées, renommées ou supprimées de l’API publique par rapport à la version 2.10. Par exemple, un ancien patch de Massimo Valentini ajoute gimp-context-get-emulate-brush-dynamics et gimp-context-set-emulate-brush-dynamics, qui permettent aux développeurs de scripts et de greffons d’utiliser le paramètre Émuler la dynamique du pinceau lors de la peinture. D’autre part, les différentes fonctions gauss ont toutes été regroupées en une seule fonction, plug-in-gauss. Bien que ce changement nécessite quelques mises à jour dans les scripts existants, les développeurs ont désormais un contrôle plus direct sur l’effet de flou gaussien plutôt que de s’appuyer sur des valeurs prédéfinies cachées.

L’API étant désormais stable, les développeurs de greffons et de scripts peuvent commencer à porter leurs scripts 2.10 basés sur cette version. Vous pouvez trouver la documentation initiale de l’API sur notre site de développement. Nous avons l’intention d’ajouter davantage de tutoriels et de guides de portage sur le site pendant la phase de publication. Nous vous encourageons également à consulter les greffons Script-fu et Python dans notre référentiel pour voir des exemples fonctionnels de la nouvelle API.

Mises à jour de l’édition non destructive

Depuis notre dernière mise à jour, nous avons continué à apporter des améliorations et des corrections de bugs à notre code de filtre non destructif. Bon nombre de ces problèmes ont été signalés par Sam Lester lors du développement et des tests de ses filtres GEGL tiers.

Bien que les filtres non destructifs aient été un ajout très populaire à GIMP 3.0, certains des premiers utilisateurs ont demandé que nous fournissions un moyen de revenir au flux de travail destructif d’origine. Par conséquent, nous avons ajouté une case à cocher facultative « Fusionner les filtres » au bas des filtres NDE. Si cette case est cochée, le filtre sera immédiatement fusionné après sa validation. Notez que les filtres ne peuvent pas être appliqués de manière destructive sur des groupes de calques — dans ces cas, l’option de fusion des filtres n’est pas disponible.

Example of Merge Filter checkbox

Exemple de filtre avec la case à cocher « Merge Filter » (Fusionner les filtres) - GIMP 3.0 RC1

Dans le même ordre d’idées, Jehan a également implémenté le stockage de la version des filtres dans les fichiers de projet XCF de GIMP. Cela nous permettra de mettre à jour les filtres à l’avenir sans affecter l’apparence des anciens fichiers de projet lorsqu’ils sont ouverts. Des travaux supplémentaires seront nécessaires dans GEGL pour implémenter complètement cette fonctionnalité, mais cela peut être fait après la version 3.0 sans affecter les fichiers de projets existants.

Interface utilisateur

GIMP 3.0 RC1 contient plusieurs mises à jour de l’interface utilisateur. Par exemple, davantage d’aspects du GUI peuvent désormais tirer parti des fonctionnalités de sélection multiple implémentées par Jehan dans les versions antérieures de 2.99.

Nous avons également restauré la possibilité d’utiliser la molette de défilement de la souris pour parcourir les différents onglets de dialogue ancrables. Cette fonctionnalité existait dans GTK2 mais supprimée dans GTK3. À la demande d’un utilisateur, nous avons réimplémenté cette fonctionnalité dans GIMP lui-même sur la base d’une implémentation similaire dans geany.

Au cours du développement, nous avons reçu un rapport indiquant que le défilement des crédits dans notre boîte de dialogue À Propos pouvait provoquer une gêne en raison de son mouvement. Par conséquent, nous avons ajouté un code pour vérifier le paramètre « Animation réduite » de votre système d’exploitation et désactiver ces animations dans GIMP selon vos paramètres de préférence.

Greffons

Comme nous sommes en période de gel des fonctionnalités depuis la dernière version 2.99, la plupart des modifications apportées aux greffons ont été des mises à jour d’API et des corrections de bugs (certaines d’entre elles pour des problèmes qui étaient assez anciens). Cependant, quelques améliorations plus petites ont été implémentées.

BMP

Le format BMP prend désormais en charge les images 64 bits par pixel. Le nouveau contributeur Rupert Weber nous a aidé à ajouter la prise en charge de l’importation correcte de ce format BMP. Il a également soumis des correctifs avec plus de corrections pour notre greffon BMP et notre pipeline de test.

TIFF

Depuis GIMP 2.99.16, nous pouvons importer des fichiers TIFF avec des calques au format Photoshop. Cependant, le programme Alias/Autodesk Sketchbook a créé sa propre norme pour enregistrer les calques, ce qui n’était pas compatible. Comme cela a été signalé comme un bug dans notre outil de suivi des problèmes, nous avons également ajouté la prise en charge du chargement de calques à partir de fichiers TIFF enregistrés au format Sketchbook.

GEGL et babl

GEGL et babl ont tous deux connu un certain nombre de mises à jour depuis leurs dernières versions en février.

GEGL 0.4.50 introduit plusieurs nouveaux filtres créés par Sam Lester.

  • Lueur intérieure (Inner Glow)

  • Biseau (Bevel)

  • Styles GEGL (GEGL Styles)

"GEGL Styles" effect in GIMP 3.0 RC1

Vous pouvez y accéder via l’outil Opérations GEGL ou en les recherchant avec le raccourci d’action de recherche /.

Øyvind Kolås a apporté un certain nombre de corrections de bugs et d’améliorations à la stabilité de GEGL. Plusieurs modifications ont également été apportées en rapport avec l’invasion de l’espace colorimétrique dans GIMP, comme l’ajout de méthodes pratiques pour obtenir et définir les GeglColor dans les modèles de couleurs HSV(A) et HSL(A), implémentées par Alx Sa. Jacob Boerema et son étudiant du Google Summer of Code (GSoC) Varun Samaga B L ont fusionné un certain nombre d’améliorations à la version OpenCL des filtres. Bien que GIMP n’active toujours pas OpenCL par défaut, leur travail nous rapproche beaucoup de la possibilité de le faire. Nous discuterons de ces améliorations dans un prochain article.

babl 0.1.110 a également reçu quelques contributions au cours de ce cycle. Jehan a implémenté de nouveaux processus de conversion entre les modèles de couleurs RVB et HSL, ce qui améliore les performances d’un certain nombre de filtres par rapport à GIMP 2.99.18. Il a également corrigé certaines parties du code qui se comportaient différemment selon que votre processeur prenait en charge SSE2 ou non. Øyvind Kolås a amélioré la précision de plusieurs sections de code lors de la conversion de valeurs à virgule flottante en valeurs entières. De plus, Lukas Oberhuber a trouvé et corrigé une fuite de mémoire et Jacob Boerema a corrigé un problème où les images avec Not a Number/NaN pouvaient provoquer un plantage.

Statistiques de sortie

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

  • 384 rapports ont été fermés comme CORRIGÉS.
  • 442 demandes de fusion ont été acceptées.
  • 1892 commits ont été poussés.
  • 31 traductions ont été mises à jour : basque, biélorusse, brésilien portugais, anglais britannique, bulgare, catalan, chinois (Chine), chinois (Taïwan), danois, néerlandais, galicien, géorgien, allemand, grec, hongrois, islandais, italien, coréen, letton, norvégien nynorsk, polonais, portugais, russe, serbe, serbe (latin), slovène, espagnol, suédois, turc, ukrainien, vietnamien.

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

  • 27 développeurs pour coder le code principal : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Øyvind Kolås, Cheesequake, cheesequake, Niels De Graef, Idriss Fekir, Simon Budig, lillolollo, lloyd konneker, Andre Klapper, Andrzej Hunt, Bruno, Joachim Priesner, Nils Philippsen, Alfred Wingate, Bruno Lopes, Elle Stone, Kamil Burda, Luca Bacci, Mark Sweeney, Massimo Valentini, Oleg Kapitonov, Stanislav Grinkov, megakite.
  • 15 développeurs de greffons ou modules : Alx Sa, Jehan, Lloyd Konneker, bootchk, Jacob Boerema, Anders Jonsson, Nils Philippsen, Andrzej Hunt, Andre Klapper, Rupert, Bruno Lopes, Daniel Novomeský, Mark Sweeney, Stanislav Grinkov, lillolollo .
  • 42 traducteurs : Martin, Yuri Chornoivan, Luming Zh, Rodrigo Lledó, Kolbjørn Stuestøl, Ekaterine Papava, Cheng-Chia Tseng, Sabri Ünal, Marco Ciampa, Tim Sabsch, Jordi Mas, Alexander Shopov, Anders Jonsson, Alan Mortensen, Asier Sarasua Garmendia, Sveinn í Felli, Andi Chandler, Balázs Úr, dimspingos, Juliano de Souza Camargo, Ngọc Quân Trần, Vasil Pupkin, Alexandre Prokoudine, Bruce Cowan, Jürgen Benvenuti, Nathan Follens, Милош Поповић, Balázs Meskó, Christian Kirbach, Daniel, Emin Tufan Cetin, Fran Dieguez, Guntupalli Karunakar, Hugo Carvalho, Jehan, Philipp Kiemle, Piotr Drąg, Robin Mehdee, Rūdolfs Mazurs, Seong-ho Cho, Víttor Paulo Vieira da Costa, Ayesha Akhtar.
  • 7 créateurs de ressources (icônes, thèmes, curseurs, écran de démarrage, métadonnées… même si une bonne partie d’entre eux ont été déplacés vers le référentiel gimp-data) : Alx Sa, Jehan, Bruno Lopes, Anders Jonsson, Jacob Boerema, bootchk, nb1 .
  • 10 contributeurs à la documentation : Jehan, Bruno, Lloyd Konneker, Alx Sa, Bruno Lopes, Anders Jonsson, bootchk, Lukas Oberhuber, Andre Klapper, Jacob Boerema.
  • 11 contributeurs pour la compilation, l’empaquetage ou l’intégration continue : Bruno Lopes, Jehan, bootchk, Alx Sa, Lloyd Konneker, Jacob Boerema, Niels De Graef, Alfred Wingate, Lukas Oberhuber, Michael Schumacher, Anders Jonsson.

Contributions sur d’autres dépôts dans GIMPverse  :

  • babl 0.1.110 est composé de 22 commits par 7 contributeurs : Øyvind Kolås, Jehan, Bruno Lopes, Anders Jonsson, Biswapriyo Nath, Jacob Boerema, Lukas Oberhuber.
  • GEGL 0.4.50 est composé de 204 commits par 33 contributeurs : Øyvind Kolås, Sam Lester, Martin, Varun Samaga B L, Yuri Chornoivan, Luming Zh, Rodrigo Lledó, Jehan, Jordi Mas, Anders Jonsson, Kolbjørn Stuestøl, Marco Ciampa, Sabri Ünal, Bruno Lopes, Alan Mortensen, Asier Sarasua Garmendia, Ekaterine Papava, Bruce Cowan, Lukas Oberhuber, Tim Sabsch, psykose, Alexandre Prokoudine, Alx Sa, Andi Chandler, Andre Klapper, ArtSin, Daniel Șerbănescu, Jacob Boerema, Joe Locash, Morgane Glidic, Niels De Graef, dimspingos, lillolollo.
  • ctx a enregistré 616 commits depuis la sortie de la version 2.99.18 par 2 contributeurs : Øyvind Kolås, Ian Geiser.
  • gimp-data (nouveau référentiel contenant des images, des splashes, des icônes et d’autres données binaires pour le logiciel) ont eu 76 commits par 7 contributeurs : Jehan, Aryeom, Bruno, Alx Sa, Denis Rangelov, Anders Jonsson, Bruno Lopes.
  • La version gimp-macos-build (scripts d’empaquetage pour macOS) a eu 41 commits par 3 contributeurs : Lukas Oberhuber, Bruno Lopes, Jehan.
  • La version flatpak a compté 38 commits de 4 contributeurs : Bruno Lopes, Jehan, Hubert Figuière, Will Thompson.
  • Notre site Web principal a enregistré 60 commits depuis la sortie de la version 2.10.38 par 5 contributeurs : Jehan, Alx Sa, Andre Klapper, Bruno Lopes et Denis Rangelov.
  • Notre site Web de développeur a enregistré 33 commits depuis la sortie de la version 2.10.38 par 5 contributeurs : Bruno Lopes, Jehan, Lloyd Konneker, Alx Sa, Lukas Oberhuber.
  • Notre documentation 3.0 a enregistré 928 commits depuis la version 2.99.18 par 14 contributeurs : Andre Klapper, Kolbjørn Stuestøl, Jacob Boerema, Alan Mortensen, Yuri Chornoivan, Jordi Mas, Marco Ciampa, Anders Jonsson, Sabri Ünal, dimspingos, Alx Sa, Andi Chandler, Daniel, Nathan Follens.

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 !

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

Modifications futures du processus de publication

Nous sommes bien conscients que le chemin vers GIMP 3.0 a été long et que les utilisateurs de GIMP 2.10 n’ont pas eu accès à toutes les nouvelles fonctionnalités sur lesquelles nous avons travaillé au fil des ans. À l’avenir, nous restructurerons notre processus de développement pour réduire le temps entre les versions. Comme mentionné brièvement dans notre feuille de route 3.0, nous voulons nous concentrer sur des versions plus petites et axées sur les fonctionnalités. Cela signifie que nous visons la sortie de GIMP 3.2 dans l’année qui suit la sortie finale de 3.0, plutôt qu’en 2050 comme on le dit souvent en plaisantant ! Des micro-versions avec des corrections de bugs peuvent survenir entre-temps.

Des versions plus petites avec quelques « grosses » fonctionnalités nous permettront également de tester plus en profondeur chaque changement, améliorant encore la stabilité de chaque version. Au cours du processus de développement de la version 3.0, des développeurs comme Jacob Boerema, Lloyd Konneker, Bruno Lopes et Jehan ont créé et amélioré nos processus de tests automatisés pour détecter et identifier les bugs plus tôt. Nous parlerons plus en détail de ces améliorations dans de futurs articles.

Autour de GIMP

Miroirs de téléchargement

Depuis notre dernière actualité, 8 nouveaux miroirs ont été proposés à GIMP par :

  • Sahil Dhiman, Inde
  • FCIX, en République Dominicaine, en Australie et 2 aux USA.
  • Taiwan Digital Streaming Co., Taïwan
  • OSSPlanet, Taïwan
  • Shrirang Kahale, Inde

Cela nous amène à un total de 56 miroirs du monde entier !

World Map of GIMP Mirror locations

Carte des miroirs GIMP dans le monde, générée à partir de MirrorBits

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

Modifications de l’infrastructure

Bruno Lopes a véritablement pris des initiatives pour améliorer notre processus de construction et d’empaquetage sur plusieurs plateformes.

Au cours de l’été, il a créé une version expérimentale d’AppImage (comme détaillé dans un article d’actualité précédent). Si vous souhaitez l’améliorer davantage et, espérons-le, le rendre disponible en téléchargement standard, veuillez nous contacter ! Bruno a également créé des scripts de construction flatpak pour rendre le processus de création de votre propre flatpak GIMP beaucoup plus facile.

Beaucoup de travail a été fait pour améliorer notre présence sur le Microsoft Store pour la version 3.0. Notre application GIMP 2.10 n’était pas entièrement intégrée à la plateforme du store en raison de certaines limitations — il s’agit en réalité simplement d’un wrapper pour notre installateur GIMP existant. Par conséquent, elle ne se mettait pas automatiquement à jour pour les utilisateurs et il n’était pas possible d’automatiser les installations avec des outils comme Microsoft Intune. Grâce aux nombreux efforts de Bruno, nous aurons une nouvelle application GIMP dans le Microsoft Store qui résout ces problèmes (et bien d’autres) pour la version finale de GIMP 3.0. À partir de maintenant, nous disposons également d’une version séparée de GIMP (Preview) qui vous permet d’installer des versions de développement de manière similaire au flatpak Bêta sur Linux. Vous pouvez l’essayer sur ce lien vers le Microsoft Store pour GIMP (Preview).

(Pour des raisons techniques et de maintenance décrites ici, les binaires 32 bits ne seront pas disponibles dans les nouveaux paquets MSIX de GIMP, ce qui supprime malheureusement la prise en charge du greffon TWAIN hérité dans les paquets x64 et arm64 utilisés pour la numérisation rapide. Si vous dépendez de ceux-ci, le programme d’installation .exe prend toujours en charge les processeurs 32 bits. Cependant, la prise en charge de cette architecture devrait être abandonnée à l’avenir)

En outre, l’installateur Windows standard a été mis à jour pour une conception plus moderne. Il vous permet également d’installer des paquets de langue individuels et de démarrer GIMP immédiatement après la fin de l’installation. Pour les plus férus de technologie, les scripts de build Windows ont également été portés pour utiliser PowerShell, et les scripts de build croisés peuvent désormais s’exécuter localement.

En raison des changements et des mises à jour de notre infrastructure de création de logiciels, nous avons dû augmenter la configuration minimale requise pour le système d’exploitation MacOS à Big Sur (MacOS 11).

Accord d’hébergement fiscal de la Fondation GNOME

Plus tôt cette année, la Fondation GNOME a annoncé un accord de parrainage fiscal avec GIMP. Tout cela est dû au travail acharné de Jehan pendant de nombreux mois. Nos objectifs avec cet accord sont de pouvoir proposer un financement stable pour les développeurs intéressés par un travail à long terme sur GIMP par le biais de bourses, et de fournir des moyens plus faciles pour les gens de contribuer au développement de GIMP. Ce travail est toujours en cours, nous ferons donc une annonce plus détaillée une fois que tout sera stabilisé.

Traductions

Grâce à des traducteurs bénévoles, nous disposons désormais d’une traduction de GIMP en bengali ! Si vous souhaitez traduire GIMP dans votre propre langue ou participer à une traduction existante, vous pouvez découvrir comment ici.

Télécharger GIMP 3.0 RC1

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

  • Paquets Linux flatpaks pour x86 et ARM (64 bits) avec des nightly-builds permettant de suivre l’avancement des développements
  • Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
  • Paquet MSIX (aperçu GIMP) pour x86 (64 bits uniquement) 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 sont évidemment attendus (paquets de distributions Linux ou *BSD, etc.).

Et ensuite ?

Nous entrons maintenant dans la dernière étape de cette version majeure : les candidats à la version finale ! Bien qu’il soit toujours possible d’espérer obtenir une Release Candidate correcte du premier coup, l’expérience nous dit que cette RC1 — qui est le résultat de plus de 6 ans de travail — comportera possiblement des problèmes, des bugs, probablement des plantages désagréables. C’est là que nous avons besoin de vous tous ! Nous comptons sur tout le monde pour trouver et signaler les problèmes afin que la version 3.0.0 puisse vraiment être considérée comme stable. 🤗

Certains petits bugs peuvent être considérés comme secondaires (bien que nous acceptions toujours les rapports pour tous les bugs, même les plus petits !), car la perfection n’existe pas vraiment dans les logiciels. Il y a d’autres choses en particulier que nous voulons vraiment détecter, comme :

  • toute incohérence ou problème dans l’API (elle restera stable pour toute la série v3, donc s’il y a des problèmes à trouver, c’est maintenant ; nous voulons un framework de greffon robuste) ;
  • bugs lors de la lecture ou du rendu de fichiers XCF existants créés par d’anciennes versions stables de GIMP ;
  • plantages ;
  • régressions ;
  • migration correcte de la configuration à partir des versions stables précédentes.

Nous ne donnons pas d’estimation de date pour la sortie de la version 3.0.0, tout d’abord parce que nous ne pouvons pas le savoir avec certitude, ensuite parce qu’à chaque fois que nous le faisons, les médias semblent simplement survoler chaque avertissement de notre texte et transformer nos mots en promesses indéfectibles. Sachez simplement que nous voulons également que cela se produise le plus tôt possible, c’est-à-dire lorsque nous pourrons considérer que notre logiciel est suffisamment stable.

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

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de LyX 2.4

15 octobre 2024 à 05:34

Revenons sur les nouveautés de LyX 2.4 à l’occasion de la sortie de la 2.4.2, qui apporte son lot de correctifs.

LyX est un éditeur de documents WYSIWYM (what you see is what you mean) prévu pour l’environnement TeX et disponible sous licence GPL. Contrairement à Word ou LibreOffice, par exemple, l’utilisateur ne voit pas directement à l’écran le même résultat que s’il imprimait le document (WYSIWYG). Ce mécanisme est voulu, car TeX impose de « compiler » les documents avant de les visualiser : LyX permet donc de visualiser la sémantique du document avant d’en générer un PDF.

La version 2.4 est sortie le 1er juin 2024 et apporte un grand lot de nouveautés, après six ans de développement. Cette version est constituée de 8700 commits par 40 personnes et a permis de fermer 800 problèmes connus.

Logo Lyx

Fenêtre principale de LyX

Parmi les changements principaux, LyX utilise désormais UTF-8 en interne pour la représentation des documents, une évolution qui suit de près LaTeX, qui a fait le même mouvement en 2018 (bien après les moteurs modernes comme XeTeX ou LuaTeX).

Au niveau de l’interface graphique, les thèmes sombres fonctionnent bien mieux qu’avant, notamment au niveau de l’éditeur de formules. Pour Windows, le thème Fusion de Qt est nécessaire pour obtenir une interface sombre.

Au niveau des exports vers d’autres formats que des dérivés de TeX, LyX 2.4 génère désormais du XHTML 5 (c’est-à-dire du HTML5 mais lisible comme du XML). La sortie DocBook a été entièrement réécrite, de telle sorte qu’elle s’utilise désormais sur la majorité des types de documents LyX (à l’exception notable des présentations Beamer). Précédemment, seuls des documents suivant un modèle spécifique à DocBook pouvaient être exportés en DocBook, mais pas en LaTeX : maintenant, un même document pourra être exporté en DocBook et LaTeX. Cette sortie DocBook a aussi été l’occasion d’implémenter une sortie en ePub 3 (utilisant DocBook et les outils standard de DocBook pour convertir un document en ePub 3).

Le développement de LyX se poursuit activement, avec la branche 2.5 en préparation parallèlement aux mises à jour de la branche 2.4. Les améliorations et corrections en cours sont détaillées dans le système de suivi du projet, accessible au public.

Il est remarquable de noter que LyX, lancé initialement en 1995, approche bientôt de ses 30 ans d'existence. Cette longévité témoigne de la qualité et de l'utilité durable de ce logiciel. Il n'a jamais cessé d'évoluer pour répondre aux exigences de ses utilisateurs, en particulier dans le domaine de l'édition scientifique et académique.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Haiku a 23 ans - Haiku R1 bêta 5 (partie 2 : le noyau)

21 septembre 2024 à 04:02

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

Après la présentation des applications de Haiku, voici une incursion dans le noyau et la chaîne de compilation. Au menu de ce chapitre notamment : processeurs, réseau, périphériques, son et image, système de fichier, améliorations des performances, etc.

Sommaire

Noyau

Le noyau de Haiku est similaire à celui de BeOS : il s’agit d’un noyau monolithique, avec du multitâche préemptif et protection mémoire. Rien de très inhabituel. Il est développé en C++ (comme le reste du système), ce qui permet de rendre le code plus lisible que du C tout en conservant des bonnes performances pour ce code bas niveau.

Un point intéressant, le noyau offre une API et une ABI stable pour les pilotes, ce qui fait qu’il est en théorie possible de développer un pilote hors du projet Haiku et de le faire fonctionner avec plusieurs versions du noyau. En pratique, peu de personnes se lancent dans ce genre de chose, il est plus simple d’intégrer les pilotes dans le dépôt de sources de Haiku pour l’instant.

Pilotes

Commençons justement par regarder les nouveautés du côté des pilotes matériels. Il s’agit pour tout système d’exploitation d’un point de difficulté, indispensable pour fonctionner sur une large variété de systèmes.

Processeurs

En principe, un processeur est un matériel assez bien standardisé, qui implémente un jeu d’instruction bien défini et ne devrait pas nécessiter de pilote spécifique. Cependant, le matériel moderne de plus en plus complexe, offrant de plus en plus de fonctionnalités dans une seule puce électronique, fait qu’il faut tout de même prendre en compte quelques cas particuliers.

  • Ajout de nouvelles générations de machines Intel dans le driver PCH thermal (récupération de la température du CPU au travers du platform control hub).
  • Implémentation du contournement pour la faille Zenbleed dans les processeurs AMD.
  • La mise à jour du microcode pour les processeurs Intel n’est pas faite si le CPU est déjà à jour (pour gagner un peu de temps au redémarrage du système).

Réseau

Les cartes réseau restent aujourd’hui le composant le moins bien standardisé sur les ordinateurs. Il n’existe pas d’interface standardisée, et chaque fabricant propose sa propre façon de faire.

Aujourd’hui, la plupart des autres périphériques suivent des spécifications (xHCI pour les contrôleurs USB3, AHCI pour le SATA, Intel HDA pour les cartes son…) ou bien il ne reste que peu de concepteurs de composants (par exemple pour les cartes graphiques où on ne trouve que Intel, AMD et NVidia).

Écrire des pilotes pour toutes ces cartes réseau demanderait beaucoup trop de travail. C’est pourquoi, depuis 2007, Haiku s’est doté d’une couche de compatibilité avec FreeBSD, permettant de réutiliser les pilotes écrits pour ce dernier (une approche également utilisée par le système d’exploitation temps réel RTEMS).

Cependant, les développeurs de FreeBSD font face au même problème, et ont décidé d’adopter la même solution : une couche de compatibilité permettant d’utiliser les pilotes de Linux. Cela pose deux problèmes pour Haiku : il ne semble pas souhaitable d’empiler les couches de compatibilité, et il ne semble pas raisonnable d’écrire une couche de compatibilité avec Linux, dont les API internes évoluent beaucoup trop vite, ce qui nécessiterait une réécriture permanente de la couche de compatibilité pour suivre le rythme.

Finalement, la solution retenue pour Haiku est d’utiliser les pilotes activement développés par OpenBSD et en particulier par Stefan Sperling. La couche de compatibilité avec FreeBSD est également maintenue, et Haiku bénéficie donc des pilotes développés pour ces deux systèmes, en plus des siens propres.

Par exemple, les pilotes wifi iaxwifi200 et idualwifi7260 proviennent de OpenBSD, tandis que ipro1000 et intel22x sont ceux de FreeBSD 14. Les couches de compatibilité reçoivent régulièrement des corrections et améliorations.

En dehors des cartes réseaux physiques, Haiku dispose d’un nouveau pilote tun permettant de créeer des tunnels réseau. Celui-ci a été développé dans le cadre du Google Summer of Code 2023, et permet par exemple d’utiliser un client OpenVPN sous Haiku.

Enfin, une évolution qui concerne tous les pilotes réseaux : le nombre de paquets et d’octets reçus et envoyés pour une interface réseau est maintenant décompté par la pile réseau, plutôt que par chaque pilote d’interface réseau. Les pilotes doivent toujours tenir à jour les compteurs d’erreurs. Ce changement permet de regrouper le code de comptage à un seul endroit, et d’éviter des comportements différents entre pilotes. En particulier, le comptage des paquets pour l’interface localhost n’était pas correct.

Périphériques d’entrée

Haiku permet d’utiliser les claviers et souris connectés en USB et en PS/2 (encore utilisé dans certains ordinateurs portables, mais il semble en voie de disparition). Les pilotes pour les touchpads et claviers i2c sont encore en cours de développement, et le Bluetooth arrivera un peu plus tard.

Commençons par le pilote PS/2. Il reçoit relativement peu d’évolutions, cependant, les ordinateurs portables récents n’implémentent plus forcément complètement le matériel nécessaire (l’interface PS/2 étant simulée par l'embedded controller). Le pilote PS/2 de Haiku qui essaie de détecter de nombreux cas de configuration possibles est parfois un peu dérouté par ces écarts. Cela pouvait provoquer un blocage empêchant d’utiliser le clavier pendant plusieurs secondes après le lancement de la machine, le temps que le pilote finisse d’énumérer les périphériques PS/2. Le problème a été corrigé en réduisant le temps d’attente avant de décider qu’il n’y a aucun périphérique connecté.

Du côté de l’USB, une première correction concerne la prise en compte de l’attribut « minimum » dans les rapports HID. Le protocole HID permet de définir toutes sortes de périphériques (claviers, souris, mais aussi clubs de golf, simulateurs de tanks…). Les périphériques USB HID envoient à l’ordinateur une description des contrôles dont ils disposent (groupes de boutons, axes, etc). Pour les boutons et touches de clavier, la valeur « minimum » indique le code du premier bouton dans le groupe, les autres étant déduits en incrémentant la valeur pour chaque bouton présent. Ce cas n’était pas bien pris en compte par le pilote de clavier, ce qui provoquait l’envoi de mauvais codes aux applications pour les claviers concernés.

D’autre part, et de façon plus spécifique, le pilote de souris bénéficie maintenant d’un quirk, c’est-à-dire d’une procédure de contournement d’un problème, pour les souris et trackballs de la marque Elecom. Ces dernières utilisent en effet toutes le même descripteur HID, indiquant la présence de 5 boutons, alors que certains modèles ont en fait un 6me bouton non déclaré. Le descripteur est corrigé à la volée pour les périphériques concernés.

Son et image

Haiku dispose d’un pilote pour les périphériques USB Audio. Ce pilote est en développement depuis très longtemps (cela remonte avant l’apparition de l’USB 2.0), mais il n’avait jamais pu être finalisé en raison du manque de prise en charge des transferts isochrones. Ces problèmes ont enfin été corrigés, mais le pilote nécessite encore des travaux pour le rendre compatible avec plus de matériel (en particulier les périphériques implémentant la version 2.0 de la spécification USB Audio) et probablement également quelques corrections dans le serveur média pour le préparer à l’apparition et la disparition de cartes son pendant que le système est en train de tourner (actuellement, cela nécessitera un redémarrage du serveur).

Du côté des cartes son PCI, pas de grande nouveauté, mais un gros nettoyage dans le cadre de travaux pour supprimer tous les avertissements du compilateur. Ce travail se fait petit à petit, dossier par dossier dans le code de Haiku. L’analyse du dossier contenant les pilotes de cartes son a révélé l’existence de trois pilotes ciblant le même matériel, ainsi que de plusieurs fichiers qui avaient été dupliqués dans plusieurs pilotes (développés avant leur rassemblement dans le dépôt de sources de Haiku à partir du mème exemple de code), puis qui avaient divergé au cours du développement de chaque pilote. Ce code a été réunifié dans une version partagée qui inclut toutes les corrections et améliorations de chaque version.

Du côté des cartes graphiques, des travaux sont en cours pour pouvoir piloter correctement les cartes graphiques Intel de 12me génération. Le pilote existant fonctionne déjà dans certains cas, mais se repose beaucoup sur le travail fait par le firmware (BIOS ou EFI) pour initialiser l’affichage. Il est ainsi impossible d’utiliser un écran qui n’a pas été configuré au démarrage de la machine (passer d’une sortie HDMI à l’écran d’un PC portable ou inversement, par exemple).

Machines virtuelles

Haiku est utilisé dans des machines virtuelles pour diverses raisons : à des fins de test par les développeurs, pour l’infrastructure de compilation des paquets, ou encore par des utilisateurs qui veulent le tester sans l’installer sur une machine physique dédiée.

Des pilotes spécifiques et quelques adaptations sont nécessaires pour un bon fonctionnement sur ces machines. En particulier, des pilotes sont nécessaires pour certains périphériques virtio, qui permettent aux machines virtuelles d’émuler un matériel simplifié, ne correspondant pas à un matériel réel existant. Ceci permet de meilleures performances.

Le pilote virtio de Haiku a été mis à jour pour implémenter la version 1.0 de la spécification. Cela a permis de corriger des problèmes dans le pilote virtio_block (support de stockage virtualisé).

Un nouveau pilote virtio_gpu permet l’affichage de l’écran sans avoir à passer par un pilote pour une carte graphique, ni par les pilotes VESA ou framebuffer EFI qui montrent assez vite leurs limitations (choix de résolutions d’écran limité, par exemple). Plus tard, ce pilote pourrait permettre également d’expérimenter avec la virtualisation de OpenGL, et donc d’expérimenter avec l’accélération du rendu 3D sans avoir à développer un pilote graphique capable de le faire.

Ces pilotes virtualisés facilitent également le travail de portage de Haiku vers de nouvelles architectures : il est possible de lancer Haiku dans QEMU avec n’importe quel processeur, et un ensemble de périphériques virtio pour lesquels les pilotes ont pu d’abord être testés sur une autre architecture déjà fonctionnelle.

Autres

La bibliothèque ACPICA a été mise à jour avec la dernière version 20230628, et les changements nécessaires pour son fonctionnement dans Haiku ont été intégrées en amont, ce qui facilitera les prochaines mises à jour. ACPICA est développée par Intel et permet d’implémenter la spécification ACPI, pour la gestion d’énergie, l’énumération du matériel présent sur une machine, et diverses fonctionnalités liées (détection de la fermeture d’un ordinateur portable, récupération du niveau de charge des batteries, par exemple).

Le pilote poke, qui permet aux applications de manipuler directement la mémoire physique sans l’aide d’un pilote spécifique, a été remis à jour et finalisé. Il est utile principalement pour expérimenter avec le matériel avant de développer un pilote spécifique.

La pile Bluetooth a reçu un premier coup de nettoyage. Pas de grosses évolutions pour l’instant, seules les couches les plus basses sont implémentées, on pourra au mieux énumérer les périphériques Bluetooth présents à proximité. Le développement des fonctionnalités suivantes attendra au moins la publication de la version Bêta 5.

Systèmes de fichiers

Haiku implémente plusieurs systèmes de fichiers. Celui utilisé pour le système est BFS, hérité de BeOS et qui fournit quelques fonctions indispensables à Haiku (comme les requêtes qui permettent d’indexer des attributs étendus de fichiers dans une base de données). Mais de nombreux autres systèmes de fichiers peuvent être lus, et pour certains, écrits. Cela permet de facilement partager des fichiers avec d’autres systèmes d’exploitation.

Le système de fichier UFS2 est maintenant complètement implémenté (en lecture seule), inter-opérable avec FreeBSD, et sera disponible dans l’installation de base pour les prochaines versions de Haiku.

Du côté de Linux, l’interopérabilité est possible en lecture et en écriture avec les systèmes de fichiers ext2, 3, et 4 (tous les 3 implémentés dans un seul pilote qui sait les reconnaître et les différencier). Cette implémentation a reçu quelques corrections de bugs ainsi qu’une implémentation de F_SETFL.

Enfin du côté de Windows, la prise en charge de NTFS avait déjà été mise à jour et grandement améliorée (en réutilisant les sources de NTFS-3g). Cette année, c’est le tour des systèmes de fichiers FAT. Le pilote utilisé jusqu’à maintenant avait été publié par Be il y a très longtemps. Il avait été mis à jour pour Haiku mais comportait de nombreux problèmes : mauvaise gestion des dates de modification des fichiers, interopérabilité avec d’autres implémentations, voire crash du système lors de tentative de lecture de partitions corrompues. Ce code a été entièrement remplacé par un pilote utilisant l’implémentation du FAT de FreeBSD.

Enfin, le système de fichier ramfs (pour stocker des fichiers dans la RAM de l’ordinateur de façon non persistente) a reçu des corrections sur la fonction preallocate. Cela corrige en particulier des fuites de mémoire dans les navigateurs web basés sur QWebEngine, qui utilisent ce système de fichiers pour partager de la mémoire entre plusieurs processus.

Un changement un peu plus global, et pas lié à un système de fichier spécifique, est la réunification du code pour parser les requêtes. Il s’agit d’une méthode pour rechercher des fichiers à partir de leurs attributs étendus (xattrs) qui sont indexés à la façon d’une base de données. Au départ, cette fonctionnalité était propre au système de fichier BFS, mais elle a été implémentée également pour ramfs et packagefs (système de fichier permettant d’accéder au contenu des paquets logiciels sans les décompresser). Lors du développement de ces deux nouveaux systèmes de fichiers, le code permettant de convertir une chaîne de caractères exprimant une requête en opération exécutable avait été extrait du pilote BFS pour en faire un module générique. Mais le pilote BFS n’avait pas encore été mis à jour pour utiliser ce module. C’est désormais chose faite, ce qui assure que le comportement entre les 3 systèmes de fichiers est le même, et que les corrections de bugs bénéficieront à tous les trois.

Pour terminer sur les systèmes de fichiers, l’outil fs_shell, qui permet d’exécuter le code d’un système de fichier en espace utilisateur, a reçu deux nouvelles commandes : truncate et touch. Cet outil permet de tester les systèmes de fichiers en cours de développement dans un environnement plus confortable et mieux contrôlé, et il est aussi utilisé lors de la compilation de Haiku pour générer les images disques.

Réseau

La pile réseau proprement dite a principalement évolué avec de la mise en commun de code. Par exemple, l’implémentation de l’ioctl FIONBIO (non standardisé, mais largement implémenté) pour passer un descripteur de fichier en mode non bloquant a été réécrite pour partager du code avec le flag O_NONBLOCK configurable par fcntl et F_SETFL. Également, le flag MSG_PEEK qui permet de lire des données d’un socket sans les retirer de son buffer de réception, est maintenant implémenté directement par la pile réseau au lieu d’avoir une version spécifique à chaque type de socket.

Sockets UNIX

Les sockets de la famille AF_UNIX sont utilisés pour les communications locales entre applications sur une même machine. Ils sont en particulier utilisés par WebKit et de nombreux autres moteurs de rendu web, mais assez peu par les applications natives pour Haiku, qui disposent d’autres méthodes de communications (en particullier les BMessage et les ports).

L’implémentation des sockets UNIX est maintenant complète et suffisante pour faire fonctionner toutes les applications qui en ont l’utilité.

 TCP

La pile TCP de Haiku est devenue au fil du temps un goulot d’étranglement des performances. D’une part parce que toutes les autres parties du système se sont améliorées, et d’autre part parce que les interfaces réseaux sont de plus en plus rapides et de plus en plus sollicitées.

Le travail sur la pile TCP cette année a commencé par la remise en route de l’outil tcp_shell, qui permet de tester l’implémentation de TCP en espace utilisateur et en isolation du reste du système. Cet outil avait été utilisé au tout début du développement de la pile TCP, mais n’avait pas été tenu à jour depuis. Il permet maintenant de tester la pile TCP communiquant avec elle-même, et aussi d’injecter des paquets à partir de fichier pcap. Pour l’instant, la fonction permettant de communiquer avec l’extérieur n’a pas été remise en place.

Cet outil a permis d’identifier et d’analyser certains des problèmes rencontrés.

Le premier problème était un envoi d’acquittements TCP en double. À première vue, cela ne devrait pas poser de gros problèmes, il y a seulement un peu de redondance. Mais, en pratique, une implémentation de TCP qui reçoit des acquittements en double suppose qu’il y a eu un problème de congestion réseau lors de l’envoi de données dans l’autre sens. Les algorithmes de contrôle de la congestion se mettent en jeu, et le trafic ralentit pour éviter une congestion qui n’existe pas. Par exemple, la taille de la fenêtre de transmission TCP (le nombre maximum d’octets qui peuvent être envoyés sans attendre d’acquittement) peut être réduite.

Et, malheureusement, cela déclenche un autre problème : la taille de cette fenêtre peut atteindre 0 octet, et dans ce cas, HAiku ne s’autorisait plus à émettre aucun paquet. Cela pouvait se produire au même moment dans les deux directions sur une connexion TCP, ce qui fait qu’aucune des deux machines connectées ne s’autorise à envoyer de données à l’autre. Ce problème a été corrigé, les transmissions peuvent maintenant continuer à débit réduit, puis reprendre une vitesse optimale petit à petit.

Après ces corrections, une mesure des performances de TCP dans un environnement de test montre que la pile TCP est capable de traiter jusqu’à 5.4 Gbits/s de trafic, alors que le débit plafonnait à 45 Mbits/s auparavant. C’est donc un centuplage des performances.

Autres

Plusieurs autres évolutions diverses dans le noyau :

L’implémentation de kqueue, ajoutée l’année dernière, a reçu plusieurs corrections et améliorations. Elle couvre déjà plusieurs usages et permet l’utilisation de plus de logiciels portés depuis d’autres systèmes, mais les cas d’utilisation les plus avancés ne sont pas encore tout à fait fonctionnels.

Pour rappel, kqueue est une fonction des systèmes BSD permettant à un thread utilisateur de se mettre en attente de plusieurs types d’évènements et de ressources du noyau. L’usage est similaire à celui de epoll sous Linux mais l’API est différente.

La classe ConditionVariable, utilisée pour la synchronisation entre threads et interruptions dans le noyau, a reçu plusieurs mises à jour. Un article sur le site de Haiku détaille l’utilisation et le fonctionnement de cette classe.

La boucle principale du débugger noyau (KDL), qui prend la main sur tous les processeurs en cas de crash du système ou sur demande de l’utilisateur pour investiguer des problèmes, inclus maintenant une instruction PAUSE. Cela permet d’informer le CPU qu’il n’est pas nécessaire d’exécuter cette boucle à la vitesse maximale, évitant de faire surchauffer la machine sans raison. Cette boucle est principalement en attente d’instructions de l’utilisateur, via un clavier ou un port série.

Du refactoring sur les parties du code qui sont spécifiques à chaque architecture : arch_debug_get_caller est maintenant implémenté via un builtin gcc plutôt que du code assembleur à écrire à la main pour chaque machine. arch_debug_call_with_fault_handler appelait une fonction avec un mauvais alignement de pile sur x8_64, pouvant conduire à un crash si la fonction appelée utilisait des instructions SSE par exemple. Correction également d’un problème qui pouvait causer la perte d’une interruption inter-CPU (permettant à un cœur de processeur d’interrompre l’exécution de code en cours sur un autre cœur) dans certains cas.

Une modification sur la gestion des descripteurs de fichiers: la structure interne des descripteurs de fichiers était pourvue d’un champ indiquant le type (fichier, socket, pipe…). Ce champ et tout le code qui en dépendait ont été supprimés. Ceci permet à des add-ons du kernel de déclarer leurs propres types de fichiers sans avoir à modifier le noyau. Cela pourrait par exemple être utile pour développer une couche de compatibilité avec Linux, qui fait un usage généreux des descripteurs de fichiers de tous types (eventfd, signalfd, timerfd…).

Réécriture du code de debug activé par l’option B_DEBUG_SPINLOCK_CONTENTION qui permet d’investiguer les problèmes de performances liés à l’utilisation de spinlocks (attente active sur une interruption matérielle).

Un petit changement d’algorithme sur l’allocateur de pages du noyau. Cet allocateur alloue des pages mémoires par blocs multiples de 4Ko. Les pages libérées étaient réinsérées une par une dans une liste chaînée. Cela conduit à insérer les pages dans l’ordre inverse de leurs adresses (la dernière page d’une zone mémoire se retrouve au début de la liste). Lors des prochaines allocations, cette page se retrouve donc allouées en premier, puis celle qui se trouve juste avant, et ainsi de suite. La zone mémoire construite par toutes ses pages est donc considérée comme discontinue. En inversant l’ordre d’insertion des pages dans la liste, on préserve les pages dans un ordre globalement croissant d’adresse mémoire, et on augmente les chances qu’une allocation de plusieurs pages se trouve avec des pages contiguës et dans le bon ordre. Cela est utile en particulier pour les allocations qui vont être utilisées pour des transferts DMA: il sera possible de programmer un seul gros transfert DMA au lieu de plusieurs petits.

L’état de la FPU du processeur n’était pas complètement sauvegardé lors d’un changement de contexte. Certains drapeaux de configuration pouvaient donc rester positionnés avec les valeurs configurées par un thread, pendant l’exécution d’un autre. Au mieux cela donnait des résultats inattendus, au pire, un crash (par exemple si le FPU est configuré pour lever une exception matérielle, dans un thread qui ne s’y attend pas). Le nouveau code de sauvegarde utilise des instructions dédiées qui sauvegardent d’un coup tout l’état du FPU, ce qui fait qu’en plus de fonctionner correctement, il est plus rapide que ce qui était fait précédemment.

Une évolution sur les sémaphores: la fonction release_sem_etc permet de donner une valeur négative au paramètre « count ». Dans ce cas, le thread qui était en attente d’un acquire_sem sera réveillé, mais la fonction acquire_sem retournera une erreur indiquant que le sémaphore n’a pas pu être obtenu. Cela permet de simplifier un peu le code de certaines utilisations classiques des sémaphores.

Une correction de bug sur le code traitant les « doubles fautes ». Le fonctionnement d’un système d’exploitation est en partie basé sur l’interception des « fautes », par exemple, un programme qui essaie d’accéder à de la mémoire qui a été évacuée dans la swap. Cette mémoire n’est pas immédiatement accessible, le programme est donc interrompu, le noyau prend la main, va récupérer cette mémoire, puis rend la main au programme qui n’y voit que du feu et continue son exécution comme si de rien n’était. Les fautes peuvent également se produire dans le cas où un programme essaie d’accéder à une zone mémoire non allouée, on aura alors une erreur de segmentation.

Tout ça est très bien, mais que se passe-t-il si le code qui traite ces problèmes déclenche lui-même une faute ? C’est prévu : il existe un deuxième morceau de code qui va intercepter ces problèmes et tout arrêter pour lancer le debugger noyau, et permettre à un humain d’examiner la situation.

Oui, mais que se passe-t-il si ce code déclenche lui-même une faute ? C’est ce qu’on appelle une triple faute, dans ce cas, la solution de dernier recours est d’immédiatement redémarrer la machine.

Des utilisateurs se sont plaints de redémarrages intempestifs, et une étude attentive du code traitant les doubles fautes a révélé un problème qui déclenchait systématiquement une triple faute (difficile à analyser, car on n’a pas de journaux ou de moyen d’investiguer le problème). Espérons que l’accès au debugger noyau lors des doubles fautes permettra désormais de comprendre d’où elles proviennent.

Tout autre sujet, le noyau dispose maintenant d’APIs pour configurer l’affinité des threads, par exemple pour interdire à un thread de s’exécuter sur certains cœurs de processeurs. Cela peut être utile sur des machines avec des processeurs hétérogènes (par exemple ARM BIG.Little), ou encore si le développeur d’une application pense pouvoir faire mieux que l’ordonnanceur par défaut pour répartir ses threads sur différents cœurs.

Pour terminer sur les évolutions dans le noyau, la calibration du TSC peut maintenant être faite à partir d’informations obtenues via l’instruction CPUID. Le TSC est un compteur de cycles qui s’incrémente à une vitesse plus ou moins liée à la fréquence du processeur. Il est utile de connaître la durée en microsecondes ou nanosecondes d’un « tick » du TSC pour différents usages. Historiquement, cette durée est calculée en utilisant le Programmable Interval Timer, un composant présent dans les ordinateurs compatibles PC depuis le tout début. Ce composant n’a plus beaucoup d’autres utilités aujourd’hui, et certains chipsets ne l’implémentent plus, ou pas correctement. Ou encore, dans les machines virtuelles, l’émulation du processeur (virtualisé) n’est pas forcément exécutée de façon synchrone avec celle du timer, rendant cette mesure peu fiable. L’instruction CPUID permet de récupérer l’information de façon plus directe. Un changement similaire dans FreeBSD donne un bon aperçu de la situation.

Portages ARM, RISC-V et autres

Historiquement, Haiku est développé en premier pour les machines x86 32-bit. Une version 64 bit est apparue en 2012. D’autres versions pour les processeurs PowerPC, ARM (32 et 64 bits), RISC-V, Sparc ou encore Motorola 68000 sont dans des états d’avancement divers. Les versions ARM et RISC-V sont actuellement celles qui reçoivent le plus d’attention des développeurs. Il existe un fork de Haiku qui est entièrement fonctionnel sur certaines machines RISC-V, les changements sont intégrés petit à petit avec pas mal de nettoyage à faire.

Une des problématiques pour ces nouvelles architectures est la procédure de « bootstrap ». Pour gagner du temps et simplifier la procédure, la compilation de Haiku se base sur un certain nombre de dépendances qui sont pré-compilées depuis une machine fonctionnant sous Haiku. Cela permet de ne pas avoir à compiler des douzaines de bibliothèques tierces, avec un environnement de compilation peu contrôlé (on peut compiler Haiku depuis un système Haiku, depuis un grand nombre de distributions Linux, depuis Mac OS, depuis un BSD, ou même depuis Windows avec WSL).

Cependant, lors du développement de Haiku pour une nouvelle architecture, ces paquets précompilés ne sont bien entendu pas encore disponibles. Il est donc nécessaire d’utiliser une procédure de « bootstrap », qui va se baser sur un autre système et compiler ce qui est nécessaire en compilation croisée, pour aboutir à un système Haiku réduit au minimum de fonctionnalités, juste de quoi pouvoir lancer l’outil haikuports, qui va lui-même ensuite compiler tous les autres paquets.

Ce processus est assez complexe, et a été laissé un peu à l’abandon. Il a été récemment remis en route, avec des corrections de bugs dans l’outil haikuporter, des mises à jour dans les paquets cross-compilés (par exemple pour passer de Python 2 à Python 3), et divers autres petits problèmes. Il est maintenant à nouveau possible de construire une image disque de bootstrap au moins pour la version PowerPC.

Le portage RISC-V a reçu une mise à jour vers gcc 13 (c’était déjà le cas pour les autres architectures) et a pu être utilisé pour compiler LLVM puis Mesa (l’intégration dans la ferme de compilation de Haikuports n’est pas encore en place, donc ces compilations doivent être faites par un développeur qui lance les commandes haikuports nécessaire et patiente longtemps pendant la compilation de ces gros projets).

Les versions 68000 et PowerPC ont été un peu dépoussiérées, mais il manque toujours un certain nombre de pilotes matériels de base pour pouvoir les utiliser sur de vraies machines et même dans une certaine mesure dans QEMU (ce dernier permettant d’émuler une machine utilisant de nombreux périphériques VirtIO, ce qui pourrait simplifier un peu les choses).

La bibliothèque libroot a reçu plusieurs mises à jour dans les parties qui nécessitent du code spécifique à chaque architecture, pour ajouter en particulier le RISC-V, et au passage plusieurs autres familles de processeurs.

Une partie de Haiku qui nécessite de grosses évolutions est la gestion des bus PCI. Le pilote existant supposait la présence d’un BIOS pour effectuer la découverte du bus, ou pouvait également utiliser des tables ACPI, mais d’une façon un peu limitée, qui repose tout de même sur le BIOS ou un quelconque firmware pour assigner des adresses valides à toutes les cartes PCI. Un problème identifié depuis longtemps puisqu’il s’agit du bug numéro 3 dans l’outil de suivi de bugs de Haiku. Ce bug fêtera ses 20 ans en mars prochain, espérons qu’il soit corrigé d’ici là. Les choses avancent, puisque le pilote PCI va maintenant s’attacher correctement aux nœuds ACPI correspondants dans le device tree, ce qui permet ensuite d’interroger ACPI pour découvrir les plages d’adresses mémoires disponibles pour l’allocation d’une adresse à chaque carte PCI connectée. Du côté des nouveaux ports de Haiku, cela va également permettre d’avoir plusieurs bus PCI « racine » indépendants. Et ces développements pourraient également Être utiles pour une prise en charge complète de Thunderbolt et USB 4.

Un autre pilote qui sera utile pour les versions ARM et RISC-V est le pilote SDHCI, qui permet de s’interfacer avec les lecteurs de cartes SD ainsi que les modules eMMC. Initialement destiné uniquement aux modules connectés sur un bus PCI, le pilote a été conçu pour être facilement extensible, et permet maintenant d’utiliser également les contrôleurs SDHCI exposés via ACPI. Cependant, le pilote a encore quelques problèmes de fiabilité, et il manque une implémentation des commandes nécessaiers pour les modules eMMC, qui partagent le même protocole de communication que les cartes SD, mais utilisent un jeu de commandes différent (il y a une petite guerre de standards, le format SD s’est imposé pour les cartes amovibles, mais MMC qui n’a pas de royalties a pu prendre le marché des modules soudés sur les cartes mères, où l’interopérabilité avec le matériel existant ne pose pas autant problèmes).

Le portage sur ARM64 avance petit à petit, il parvient à démarrer une partie de l’espace utilisateur et a reçu dernièrement des corrections sur le code permettant les changements de contexte entre différents threads. L’affichage du bureau complet pour la première fois sur une machine ARM64 ne devrait donc plus être très loin.

Bootloader

Le démarrage de Haiku est pris en charge par un bootloader spécifique nommé haiku_loader. Contrairement au noyau Linux, qui peut s’initialiser tout seul quasiment dès le démarrage du matériel, le noyau de Haiku a besoin que son bootloader prépare une grande partie de l’environnement (activation de la mémoire virtuelle, initialisation de l’affichage et mise en place du « splash screen », par exemple). Le bootloader prend en charge toutes ces tâches et permet en plus de configurer des options de démarrage via un menu en mode texte, de démarrer via le réseau, d’utiliser un snapshot plus ancien du système si une mise à jour s’est mal passée.

Le bootloader a peu évolué cette année, le changement principal étant la suppression de logs de warning lors du chagement de fichiers ELF, pour les sections non traitées PT_EH_FRAME (généré par les versions modernes de gcc) ainsi que d’autres sections spécifiques aux processeurs RISC-V qui ne nécessitent pas de traitement spécifique dans ce cas.

Amélioration de performances

Beaucoup de travail a été fait sur l’amélioration des performances. C’est un sujet qui a été un peu laissé de côté au début du développement de Haiku. Le premier but était de faire fonctionner les choses, avant de les rendre plus rapides. Maintenant que les développements sont assez avancés, il est temps de commencer à étudier ce problème et à essayer de se rapprocher des perfomances d’autres systèmes.

Implémentation des IO vectorisées sur les périphériques de type bloc

Lorsqu’on veut lire ou écrire sur un disque, il faut envoyer une commande pour accéder à des secteurs consécutifs. Dans le cas normal, c'est le cache du système de fichiers qui se charge de regrouper les différents accès et de les ordonnancer de façon optimale.

Mais il y a un cas particulier pour les accès directs au disque. Par exemple, si on ouvre le disque directement (via son device dans /dev/disk/) ou encore lorsqu’un système de fichier veut écrire son journal (qui ne passe pas par le cache). Les écritures dans le journal sont faites avec des accès vectorisés (via readv ou writev) qui contiennent chacun une liste d’endroits où lire ou écrire des données. Ces accès étaient implémentés sous forme d’une boucle appelant plusieurs fois read ou write. Maintenant, la liste est directement transmise au pilote de disque qui peut ainsi mieux traiter ces accès.

Réparation du profiler

Haiku dispose d’un outil de profiling, mais celui-ci ne fonctionnait plus et retournait des données incohérentes. Plusieurs problèmes ont été corrigés pour faciliter les mesures de performances et vérifier que les optimisations rendent réellement les choses plus rapides.

Réduction des verrouillages du device manager

Le problème initial qui a conduit à ces améliorations était la lenteur du lancement de nouveaux processus. Un goulet d’étranglement qui a été identifié est le verrouillage du device_manager pour accéder au périphérique /dev/random pour initialiser le stack protector (qui a besoin d’écrire des valeurs aléatoires sur la pile). Toutes les ouvertures de fichiers dans /dev nécessitent d’acquérir un verrou qui empêche l’exécution en parallèle avec de nombreuses autres tâches liées aux périphériques matériels.

Le problème a été corrigé de deux façons : d’abord, le stack protector utilise une API permettant de générer des nombres aléatoires sans ouvrir de fichier dans /dev. D’autre part, une analyse a montré que la pile USB passait beaucoup de temps à exécuter du code en ayant verrouillé l’accès au device manager. Ce code a été modifié pour libérer le verrou plus souvent.

DT_GNU_HASH dans les fichiers ELF

Un autre aspect assez lent du lancement de processus est le chargement des bibliothèques et la recherche des symboles dans ces bibliothèques. Pour identifier si une bibliothèque contient un symbole, la recherche se fait par un hash du nom de la fonction recherchée.

Historiquement, c’est la section DT_HASH qui est utilisée, mais les utils GNU implémentent également DT_GNU_HASH, qui utilise une meilleure fonction de hash et ajoute également un bloom filter qui permet de tester très rapidement, mais de façon imparfaite, la présence d’un symbole dans une bibliothèque.

Le chargeur de bibliothèques de Haiku sait maintenant utiliser les tables DT_GNU_HASH, mais ce n’est pas encore déployé car les gains de performances ne justifient pas l’augmentation de taille des bibliothèques (il faut stocker les tables dans l’ancien et dans le nouveau format). Il sera toutefois possible de l’ajouter au cas par cas sur les bibliothèques où le gain est important (par exemple s’il y a beaucoup de symboles).

premapping de mmap

La fonction mmap permet de mapper un fichier directement en mémoire. Les écritures en mémoire sont ensuite directement enregistrées sur disque. Il n’est pas souhaitable de charger tout le fichier d’un coup au moment de l’appel à mmap, ce serait trop lent. Mais il ne fait pas non plus attendre que le logiciel accède à cette mémoire et remplir les données au goutte-à-goutte (ou plus précisément, une page de 4Kio à la fois).

Un cas particulier est le traitement des bibliothèques partagées, qui sont chargées en mémoire de cette façon. Dans ce cas, le fichier est probablement déjà chargé quelque part en mémoire pour un autre processus, et il devrait être possible de réutiliser les mêmes données. Le code testant cette possibilité ne fonctionnait pas à tous les coups, ce qui fait que des fichiers qui auraient pu être mappés tout de suite, ne l’étaient pas.

Une autre amélioration est d’utiliser plusieurs allocateurs séparés pour chaque processeur, pour réduire les blocages entre différents threads qui ont besoin de manipuler des pages de mémoire.

Suppression des zones mémoire

Les applications Haiku peuvent créer des zones de mémoires (appelées areas) qui disposent d’un identifiant unique et peuvent être partagées avec d’autres processus.

Lorsqu’une application s’arrête, il faut supprimer toutes les areas qui ont été créées. Cela était fait par une simple boucle supprimant ces zones une par une. Mais cela pose un problème: chaque suppression doit verrouiller la liste des areas puis la déverrouiller. Le code a été modifié pour verrouiller la liste une seule fois et retirer de la liste toutes les zones d’un seul coup, avant de faire les autres opérations de suppression qui n’ont pas besoin d’accéder à la liste.

Au total, toutes ces améliorations conduisent à une amélioration des performances de plus de 25% sur un test en conditions réelles (compilation d’une partie des sources de Haiku).

Calcul des sommes de contrôles des paquets réseau par le matériel

Dans un autre domaine, une perte de temps conséquente est le calcul des checksums pour les paquets réseau reçus et envoyés. En effet, ce calcul était fait systématiquement par le logiciel, même si le matériel est capable de s’en charger. Il est maintenant possible pour les pilotes réseaux qu’ils sont capables de vérifier et de générer ces checksums par eux-mêmes, et ainsi la pile réseau peut s’en dispenser. Cela permet aussi de se passer entièrement de checksums sur les interfaces localhost, qui ne devraient pas subir de corruption de paquets, et ne gagnent rien à cette vérification.

Cela a été également l’occasion de supprimer quelques copies des données des paquets réseau.

user_mutex

La structure user_mutex joue un rôle similaire aux futex de Linux. Elle est utilisée pour implémenter, par exemple, pthread_mutex et pthread_rwlock. L’implémentation avait plusieurs bugs (race conditions), et a été remplacée par un nouveau système plus efficace.

Au total, toutes ces améliorations permettent des performances 25% meilleures que la version beta 4 de Haiku. Il reste cependant de quoi faire, puisque certains benchmarks (compilation d’une partie du code source de Haiku) restent près de deux fois plus lent que l’opération équivalente sous Linux.

Chaîne de compilation

Haiku est compilé avec gcc, ld et les binutils. Ils nécessitent tout trois un petit nombre de patchs maintenus dans un dépôt git dédié et reversés dans les versions upstream autant que possible. Une version de gcc 2.95.3 est également utilisée pour les parties du système assurant encore la rétro compatibilité avec BeOS, les versions plus récentes utilisent un mangling différent et ne sont pas inter opérables.

L’outil de compilation utilisé est Jam, développé à l’origine par Perforce et dont il existe plusieurs forks dont un maintenu par Boost et un autre par Freetype. Haiku utilise sa propre version de Jam avec de nombreuses évolutions.

Commençons la liste des changements dans cette section avec des mises à jour de dépendances : Haiku est maintenant compilé avec GCC 13.2 (la version 14 sera intégrée prochainement). La bibliothèque ICU utilisée pour implémenter toutes les fonctions d’internationalisation (qui se trouve donc avoir un rôle assez important dans la bibliothèque C standard) a été mise à jour en version 74.

Le travail pour supprimer tous les avertissements du compilateur se poursuit petit à petit, mais les problèmes restants sont de plus en plus difficiles à corriger, soit parce qu’il s’agit de code tiers (qu’il est plus facile de garder en l’état pour le synchroniser avec de nouvelles versions), soit parce que l’avertissement ne peut pas être corrigé proprement sans perte de performance, ou encore d’une façon qui contente à la fois gcc 13 et gcc 2 pour les parties du code compilées avec ces deux versions.

On peut toutefois mentionner que tous les trigraphes présents dans le code (par accident, par exemple il est facile d’écrire « ??! » dans un commentaire) ont été supprimés. Ils ne sont plus disponibles dans C++ à partir de la version 17 et génèrent des erreurs de compilation.

D’autre part, l’option de compilation -Wno-error=deprecated a pu être désactivée, car plus aucun code ne déclenche cette erreur.

Puisqu’on parle d’options de compilation : l’optimisation « autovectorisation » pour la compilation du noyau a été désactivée pour l’instant. Cette option fait que le code utilise des instructions SSE, et faire cela dans le noyau problématique pour la plupart des machines virtuelles (QEMU, VMWare et Virtual Box). La plupart des autres noyaux n’utilisent pas ces instructions, ce qui fait que des bugs dans les hyperviseurs sont tout à fait possibles, par manque de tests. Mais le problème pourrait aussi venir de Haiku. L’investigation est, pour l’instant, remise à plus tard.

Un dernier changement dans le système de build consiste à permettre l’utilisation de git worktree. Quelques commandes git sont utilisées lors de la compilation pour calculer le numéro de version du code en train d’être compilé, et ça ne fonctionnait pas correctement dans ce cas de figure.

Commentaires : voir le flux Atom ouvrir dans le navigateur

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

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

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

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

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

Sommaire

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

Applications

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

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

AboutSystem

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

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

AboutSystem en mode clair
AboutSystem en mode sombre

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

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

CharacterMap

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

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

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

CharacterMap affichant des caractères manquants

CodyCam

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

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

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

Debugger

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

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

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

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

Deskbar

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

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

Quelques changements dans la DeskBar :

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

GLTeapot

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

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

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

HaikuDepot

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

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

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

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

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

Icon-O-Matic

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

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

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

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

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

Magnify

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

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

Magnify avec une 'règle'

MediaPlayer

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

PowerStatus

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

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

Elle a reçu plusieurs améliorations importantes :

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

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

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

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

SerialConnect

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

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

ShowImage

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

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

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

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

Terminal

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

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

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

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

Tracker

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

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

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

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

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

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

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

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

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

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

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

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

TV

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

WebPositive

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

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

Zip-O-Matic

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

Haikuports

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

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

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

Applications natives

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

HaikuUtils

WorkspaceNumber

PonpokoDiff

PecoRename

2pow

BatchRename

Applications portées

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

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

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

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

GCompris

DrawTerm

KDE Mah Jong

NetBeans

Frogatto

CudaText

Cantor

Panneaux de préférences

Appearance

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

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

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

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

Le mode automatique dans l’application Appearance

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

Keymap (disposition clavier)

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

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

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

Screen (Affichage)

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

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

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

Outils en ligne de commande

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

df

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

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

filteredquery

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

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

ping, traceroute, telnet, ftpd

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

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

pkgman

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

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

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

strace

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

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

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

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

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

et après :

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

whence

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

Serveurs

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

app_server

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

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

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

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

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

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

Plusieurs modifications ont permis d’obtenir un meilleur compromis.

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

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

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

input_server

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

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

registrar

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

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

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

Kits

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

Interface

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

 BColumnListView

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

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

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

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

BTextView

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

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

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

BMenu

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

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

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

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

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

 BSpinner

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

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

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

rgb_color

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

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

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

Locale

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

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

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

Media

Le media kit se charge de tous les aspects multimedia.

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

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

Support

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

BDataIO

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

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

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

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

Bibliothèques C

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

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

Libroot

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

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

Libnetwork

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

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

LibBSD

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

LibGNU

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

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

Commentaires : voir le flux Atom ouvrir dans le navigateur

BlueMind sort sa version 5.0 : tous les détails techniques

BlueMind est une suite logicielle libre (AGPL v3) de messagerie d’entreprise, d’agendas et de travail collaboratif.

Poursuivant l’objectif global de permettre aux utilisateurs de concrétiser l’abandon des messageries Microsoft, Exchange et 365, cette nouvelle version apporte plusieurs nouveautés et des changements profonds d’architecture, pour supporter les différents clients et simplifier la transition des utilisateurs.

Sommaire

Nouveautés architecture

Le Remplacement de Cyrus-IMAP

Jusqu’à sa version 4 incluse, BlueMind intégrait Cyrus-imap – une brique open source bien connue – comme serveur de stockage des mails.

BlueMind 5 a remplacé Cyrus Imap par un composant maison.

Il y a plusieurs raisons derrière ce choix :

  1. La première consistait à se libérer de la dépendance à un code non écrit par BlueMind qui apportait des limitations techniques de plus en plus contraignantes sans possibilité réelle d’évolution.
  2. La deuxième raison majeure concernait le stockage objet, un point faible de Cyrus qui ne correspondait plus aux besoins d’évolution de BlueMind.
    Jusque-là, beaucoup d’éléments de BlueMind étaient construits de façon à s’adapter ou contourner les limitations de Cyrus-imap. Le choix a donc été fait de s’en affranchir.

Les limitations de Cyrus IMAP

Cyrus accuse son âge et engendre des limites de plus en plus fortes dans un contexte de messagerie moderne, en plus des contraintes inhérentes au protocole IMAP, loin d’être toujours efficient (performances & limites fonctionnelles). Les principaux inconvénients de Cyrus sont :

  • Consommation de ressources élevée (RAM et CPU). Le modèle 1 connexion = 1 process a fait long feu.
  • Pas adapté au stockage objet, car conçu pour stockage disque local (les mails et toutes les méta-données sont stockés directement sur le filesystem local, et les traitements sont adaptés à ceci).
  • Les partages sont limités au périmètre d’un backend, donc à ce que peut supporter un seul serveur. Pas de partage global. Les mécanismes de contournement sont très archaïques, limités et peu fiables.
  • Modèle de mail figé et limité, qui ne permet pas d’ajouter des informations (catégories enrichies, infos diverses de collaboration ou gérées par des plugins, etc.) ou de façon très limitée.

À noter : BlueMind 4 intègre de nombreux contournements ou palliatifs afin de dépasser ces limites.

La fin de la réplication

BlueMind propose le support natif d’Outlook, sans ajout d’extension ou modification d’Outlook (que ce soit au niveau des IHM, des fonctionnalités ou du comportement), car c’est ce que veulent les utilisateurs : Outlook (tel qu’il fonctionne aujourd’hui chez nous avec Exchange). Cela se traduit par le support des protocoles/formats natifs d’Exchange/Outlook, soit MAPI côté serveur.

Cependant, MAPI fonctionne comme une base de données, par synchronisation, et les requêtes qu’effectue Outlook ne sont absolument pas compatibles avec le fonctionnement/principes d’un serveur IMAP.

Pour supporter MAPI et répondre de façon correcte et rapidement à ses requêtes, qui nécessitent des lectures/écritures très rapides et très fréquentes, il était nécessaire de contourner le serveur IMAP Cyrus et donc de stocker les données des e-mails (plus exactement les méta-données et la structure des e-mails) dans une base de données. Le corps des e-mails étant gardé uniquement dans Cyrus.

C’est ce qui a été fait dans BlueMind 4, mais cela engendre une double gestion des données et donc la nécessité d’assurer la cohérence globale entre les deux stockages de données (Cyrus et la BD) avec la complexité inhérente à ce type de système.

Assurer cette cohérence était le rôle de la réplication de BlueMind 4 qui utilisait la réplication native Cyrus. Cette opération est coûteuse et nécessite d’attendre que Cyrus ait effectué ses opérations avant de les répliquer. Ce processus asynchrone passait par des workers de réplication qui devaient faire un retour après chaque opération afin de communiquer les modifications à Outlook (et aux mobiles). Il pouvait occasionner un délai entre les actions et donc générer une différence entre le client et le serveur. Une opération contradictoire pouvait casser la synchronisation avec Outlook.

Nous arrivions donc aux limites du système, contraignant les transitions vers une architecture cloud-ready, les grosses montées en charge, le support très avancé du client Outlook et les interfaces intelligentes vers les outils de Digital Workplace.

Les gains

Avec la version 5 de BlueMind, Cyrus a donc tiré sa révérence. Les fonctionnalités de stockage et gestion qui lui incombaient encore sont maintenant prises en charge directement par le cœur de BlueMind, de façon plus moderne et sans les limitations précitées.

En v5, quand un e-mail arrive, là où BlueMind stockait dans Cyrus puis attendait la notification de la réplication avant de stocker en base de données, BlueMind effectue simplement un insert en base de données, suivi d’une copie du mail dans le stockage sur le disque (ou objet), et a immédiatement tous les éléments nécessaires à la communication avec Outlook.

À noter : Au-delà d’Outlook, cette nouvelle infrastructure prend en compte et améliore la communication avec les clients IMAP, mobiles, Thunderbird et Apple Mail.

Des gains importants sont constatés au niveau de :

  • La consommation de ressources, notamment la RAM.
  • La fin de la limitation de partages au niveau d’un backend.
  • Le format d’un e-mail, maintenant évolutif, qui permet le développement de fonctionnalités comme les catégories.
  • L’implémentation possible et réalisée du stockage objet.

Le stockage objet

En version 5, avec la suppression de Cyrus, BlueMind a fait le choix de passer nativement sur un stockage objet pour les raisons suivantes :

  • Capacité à traiter de gros volumes.
  • Avoir une architecture plus cloud-ready au niveau du stockage.
  • Permettre la corbeille à double-fond (l’e-mail est stocké sous forme d’un fichier sur le disque ou réseau, auquel est associé une clé - hash du mail - en BD. Lorsqu’un client demande un accès au fichier, BlueMind sait très rapidement dire au client où sont stockées les données et comment y accéder).
  • Backup plus simple et direct.
  • Meilleure sécurité. Par exemple, l’API S3 permet de rendre immuable un objet, une fois qu’il est écrit il ne peut pas être modifié et donc, un ransomware par exemple, ne pourra jamais chiffrer le fichier.

L’ensemble de BlueMind a été modifié pour s’adapter à la conception objet. En effet, il ne s’agit pas uniquement de changer les appels de lecture ou d’écriture des informations, mais d’adapter l’application (modélisation et traitements), du backend aux clients comme le webmail, aux paradigmes du stockage objet (latences sur la récupération des objets, gestion des listes d’objets ou mails via les méta-données, etc.) sous peine d’obtenir une application aux performances déplorables.

BlueMind v5 est compatible S3 et Scality et permet de fonctionner avec un disque local en émulant nativement un stockage objet sur des disques.

Ainsi, les installations actuelles ou nouvelles de BlueMind n’ont pas à subir de modifications, le disque local suffit et le stockage objet est possible sur les partitions habituelles.

OpenID et le SSO

À partir de sa version 5, BlueMind prend en charge le protocole OpenID, notamment pour avoir un support SSO (Single-Sign On) et pouvoir s’inclure dans un système d’information proposant déjà un service de SSO.

OpenID est mis en place par l’intermédiaire de Keycloak.

Cela va permettre d’ajouter progressivement de nouvelles fonctionnalités comme le MFA (authentification multi-facteurs).

Note : Le Keycloak intégré à BlueMind n’a pas vocation à être la brique SSO centrale du SI client. Si un client veut mettre en place un SSO global pour son système d’information, il faut qu’il mette en place un système externe (un Keycloak par exemple). BlueMind a choisi de rester maître de sa brique Keycloak et de communiquer avec la brique SSO externe.

AuditLog

Afin d’améliorer la traçabilité métier (voir le parcours d’un email dans le système), BlueMind 5 inclut un Auditlog, outil basé sur ElasticSearch et RocksDB, qui permet de stocker de nombreuses informations pertinentes dans le cadre de l’administration d’un serveur BlueMind :

  • Toutes les opérations de chaque e-mail : les déplacements, les suppressions, les différents flags (lu/non-lu, important, deleted…), les timestamps et les auteurs.
  • Les événements et les séries d’événements, ou sur les ACL les grant et revoke accès sur les partages de dossiers, de mailshares, sur les calendriers ou les carnets de contacts, etc.
  • Les connexions des utilisateurs, peu importe le moyen de connexion.

Auditlog est actuellement disponible uniquement en CLI. Une IHM sera proposée ultérieurement.

Nouveautés utilisateur

Le nouveau webmail est le webmail officiel

Le nouveau webmail, proposé en test à partir de BlueMind 4.6, s’est considérablement enrichi et est maintenant l’interface officielle. Il est aux normes de l’architecture logicielle de BlueMind (application JS qui fonctionne via API et synchronisation en utilisant le cache du navigateur).

L’ancien webmail, qui était basé sur Roundcube, peut encore être installé (il ne l’est plus par défaut sur les nouvelles installations), mais il n’est plus recommandé, notamment pour des raisons de sécurité.

Parmi les nouveautés du webmail :

  • Meilleure intégration des carnets d’adresse.
  • Corbeille à double fond.
  • Disponibilité d’un mode sombre et accessibilité encore augmentée.
  • Plus de capacités de tris et filtres.
  • Prévisualisation des messages attachés à un mail.
  • Support du S/MIME.

Autres nouveautés

De nombreuses autres nouveautés sont apportées par la v5, comme :

  • Un plugin BlueMind Visioconférence pour Outlook.
  • La gestion des délégations « à la » Microsoft.
  • Le transfert d’invitation de réunion.
  • Les disponibilités affichables sous forme d’agenda dans l’agenda.
  • Gestion de l’état Annulé d’une réunion.

Le détail des nouveautés est disponible dans le changelog.

Le passage en version 5

La version 5 recommande maintenant 24 Go minimum.

L’outil de migration bm-migrator permet de passer d’Office365/Exchange/Zimbra/Kerio/Kopano/Dovecot, etc., à BlueMind 5, en automatisant la récupération de presque toutes les données.

À noter : Une migration nécessite toujours un travail et des tests préparatoires.

Commentaires : voir le flux Atom ouvrir dans le navigateur

GIMP 2.10.38 est sorti

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.10.38 du 3 mai 2024 (en anglais).

Cette (peut-être dernière) version stable de GIMP 2 apporte des rétroportages très demandés de GTK3, y compris une prise en charge améliorée des tablettes sous Windows. Un certain nombre de corrections de bugs et d’améliorations mineures sont également incluses dans cette version.

Sommaire

Cette actualité répertorie les changements les plus notables et visibles. En particulier, nous ne répertorions pas toutes les corrections de bogues ou améliorations mineures. Pour obtenir une liste plus complète des modifications, vous devez vous référer au fichier NEWS ou consulter l'historique des commits.

Nouvelles fonctionnalités et améliorations

Prise en charge améliorée des tablettes sous Windows

Avant cette version, GIMP prenait uniquement en charge la connexion de tablettes sous Windows via les pilotes WinTab plutôt que les nouveaux pilotes Windows Ink. Pour cette raison, nous avons reçu un certain nombre de rapports concernant des tablettes présentant des problèmes avec des boutons qui ne répondent pas, une sensibilité à la pression incorrecte, un mouvement de brosse retardé et des changements de position à mi-course.

Ces problèmes étaient dus à une limitation de GTK2, car la prise en charge de Windows Ink a été implémentée dans GTK3 par Luca Bacci, contributeur de longue date. Pour cette version, Luca a eu la gentillesse de rétroporter ce support vers GTK2. Vous pouvez désormais basculer entre les pilotes WinTab et Windows Ink (s’ils sont pris en charge par votre ordinateur) dans la boîte de dialogue Préférences sous les paramètres du périphérique d’entrée.

Windows Pointer Input API option in GIMP 2.10.38
Windows Pointer Input API peut être changé maintenant - GIMP 2.10.38

Rétroportages d’autres fonctionnalités de GTK3

Luca a également contribué à plusieurs autres fonctionnalités portées de GTK3 à GTK2. Certaines des améliorations rétroportées incluent la mise à jour de la taille de la boîte de dialogue d’impression afin que les boutons ne soient pas coupés, la résolution de problèmes avec les boîtes de dialogue contextuelles apparaissant derrière les précédentes et plusieurs correctifs concernant la saisie au clavier.

Ces améliorations concernent principalement Windows et sont déjà incluses dans la version de développement 2.99. Cependant, nous sommes très heureux que ces améliorations de la qualité de vie soient désormais disponibles dans cette version stable de GIMP 2.10 !

Corrections de bogues

Crashs récents

Deux crashs fréquemment signalés ont été corrigés. Un changement dans GLib 2.80 a exposé un bogue dans notre processus de fermeture et provoqué un crash à la sortie. Luca Bacci a une fois de plus conçu un correctif pour la version 2.10.38 et la prochaine version candidate 3.0. Un autre crash que certains utilisateurs rencontraient lors de très petites sélections a également été corrigé.

Autres correctifs

Un certain nombre d’autres petits bugs ont été corrigés dans cette version. Parmi eux :

  • Les PNG indexés avec transparence sont désormais exportés avec les bonnes couleurs
  • Anders Jonsson a corrigé les plages d’entrée de plusieurs filtres tels que Waves et Distort
  • Le champ de personnalisation de la barre de titre prend désormais en charge les caractères UTF-8
  • Les commentaires d’images existants ne « fuient » plus dans les images nouvellement créées

Statistiques de sortie

Depuis GIMP 2.10.36 :

  • 16 rapports ont été clos comme CORRIGÉS dans la version 2.10.38
  • 9 demandes de fusion ont été exécutées
  • 81 commits ont été poussés
  • 1 nouvelle traduction a été ajoutée : kabyle
  • 16 traductions ont été mises à jour : biélorusse, portugais brésilien, anglais britannique, danois, géorgien, allemand, grec, hongrois, islandais, italien, norvégien nynorsk, slovène, espagnol, suédois, turc, espagnol

25 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.10.36 (l’ordre est déterminé par le nombre de commits) :

  • 7 développeurs : Alx Sa, Jehan, Luca Bacci, Jacob Boerema, Lukas Oberhuber, lillolollo, Øyvind Kolås
  • 19 traducteurs : Kolbjørn Stuestøl, Sabri Ünal, Bruce Cowan, Yuri Chornoivan, Vasil Pupkin, Anders Jonsson, Rodrigo Lledó, Jürgen Benvenuti, Sveinn í Felli, Andi Chandler, Juliano de Souza Camargo, Ekaterine Papava, Balázs Úr, Martin, Philipp Kiemle, Alan Mortensen, Dimitris Spingos, Marco Ciampa, Yacine Bouklif

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

  • La branche gimp-2-10 de gimp-macos-build (scripts de build macOS) a eu 30 commits depuis la version 2.10.36 par 2 contributeurs : Lukas Oberhuber, Bruno Lopes.
  • La version flatpak est composée de 11 commits par 3 contributeurs : Jehan, Hubert Figuière et Bruno Lopes.
  • Notre site Web principal a eu 42 commits depuis la sortie du 2.99.18 par 4 contributeurs : Jehan, Alx Sa, Andre Klapper et Lukas Oberhuber.
  • Notre site Web du développeur a enregistré 34 commits depuis la version 2.99.18 par 6 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Alpesh Jamgade et Robin Swift.
  • Notre documentation 2.10 a eu 35 commits depuis la version 2.10.36 par 8 contributeurs : Alan Mortensen, Anders Jonsson, Rodrigo Lledó, Jacob Boerema, Kolbjørn Stuestøl, Marco Ciampa, Andi Chandler et Vittor Paulo Vieira da Costa.

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

Remarque : compte tenu du nombre de composants dans GIMP et son univers, et de la manière 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 manqué ou mal catégorisé certains contributeurs ou contributions.

Nouvelles de l’équipe et processus de publication

Idriss, contributeur du GSoC 2023, a récemment obtenu un accès « développeur » sur le référentiel source principal, pour le travail formidable qu’il a continué depuis lors.

Ville Pätsi, contributeur de très longue date (plus de 20 ans !), sur divers sujets (design, thématisation et plus) a obtenu l’accès « reporter » à Gitlab pour aider au tri et à l’organisation directement dans le tracker.

Autour de GIMP

Des nouvelles des miroirs

Depuis nos dernières nouvelles, 3 nouveaux miroirs accueillent GIMP :

  • Clarkson Open Source Institute, États-Unis
  • FCIX, Suisse
  • Tomás Leite de Castro, Portugal

Cela nous amène à un total de 49 miroirs répartis dans le monde.

Les miroirs sont importants, car ils aident le projet en partageant la charge de dizaines de milliers de téléchargements quotidiens. De plus, en disposant de miroirs répartis à travers le monde, nous garantissons que tous aient un accès rapide au téléchargement de GIMP.

Sponsors d’infrastructure et de matériel

Nous avons amélioré la page sponsor avec 2 sections :

  • "Infrastructure Sponsors" répertorie les sponsors qui aident GIMP au niveau de l’infrastructure :

    • CircleCI et MacStadium rendent possible notre plateforme d’intégration continue macOS.
    • Arm Ltd. sponsorise et administre plusieurs exécuteurs « Aarch64 » sur Windows pour notre version ARM 64 bits pour Windows ; et Microsoft avait offert des frais uniques pour leur Microsoft Store.
  • "Hardware Sponsors" répertorie les sponsors qui ont fait don de matériel aux contributeurs pour les aider dans leur travail de développement :

    • Arm Ltd. a récemment fait don d’un kit de développement Windows 2023 pour prendre en charge notre récent support Aarch64/Windows.
    • Purism a fait don d’un Librem Mini en 2021.

Télécharger GIMP 2.10.38

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

  • Flatpaks Linux pour x86 et ARM (64 bits)
  • Installateur Windows universel pour x86 (32 et 64 bits) et pour 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 des distributions Linux ou *BSD, etc.).

Et ensuite ?

C’est clairement l’une des plus petites versions de la série 2.10, et elle pourrait être notre dernière. Nous verrons, même si nous savons aussi que certaines personnes restent bloquées plus longtemps que d’autres sur des séries plus anciennes (en particulier lors de l’utilisation des distributions Long Term Support (LTS) de systèmes d’exploitation de logiciels libres), si nous pourrions donc faire (si nous pensons que c’est nécessaire), une version 2.10.40 avec des corrections de bogues juste avant ou juste après la sortie de GIMP 3.0.0, en guise de conclusion.

Dans tous les cas, nous arrêtons désormais le rétroportage des fonctionnalités de la série 2.10. Ces améliorations de la prise en charge des tablettes graphiques pour Windows sont suffisamment importantes pour qu’elles aient dû être intégrées ; mais à partir de maintenant, nous voulons nous concentrer uniquement sur la sortie de GIMP 3.0.0.

Maintenant, vous vous demandez peut-être quand cela se produira-t-il ? Très bientôt ! Nous sommes sur le dernier sprint vers la release candidate. Cela inclut de nombreuses corrections de bugs, mais également des modifications de l’API en cours. Nous vous tiendrons au courant !

N’oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, comme moyen de redonner et accélérer le développement de GIMP. L’engagement communautaire permet au projet de se renforcer ! 💪🥳

Commentaires : voir le flux Atom ouvrir dans le navigateur

Fedora Linux 40 est de sortie avec un nouveau GNOME et KDE Plasma

Par : Renault
23 avril 2024 à 05:09

En ce mardi 23 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 40.

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

Cette 40e édition propose principalement une mise à jour de son interface principale GNOME 46 et de son concurrent KDE Plasma 6 qui passe à Wayland par défaut au passage.

Bureau de GNOME

Sommaire

Expérience utilisateur

Passage à GNOME 46. Cette version se démarque par beaucoup d'améliorations pour son navigateur de fichiers nommé Fichiers. Il dispose dorénavant, en plus d'une recherche dans le dossier et sous-dossiers en cours, d'une recherche globale utilisable via le bouton dédié avec une icône de loupe ou par le raccourci clavier Ctrl+Shift+F (contrairement à la recherche locale qui se fait via le raccourci Ctrl+F). Il permet de chercher dans l'ensemble du répertoire utilisateur voire davantage selon les préférences de l'utilisateur.

L'icône de loupe prend place où était l'icône de progression lors des opérations sur les fichiers comme les décompressions ou la copie de fichiers. De fait ces opérations sont affichées en bas de la barre latérale ce qui permet d'afficher plus d'informations en un coup d’œil. L'application bénéficie en outre d'améliorations de performances en particulier pour afficher de gros dossiers avec des images ou lors du passage d'une vue liste à une vue par icônes et vice-versa. Plus de périphériques sur le réseau peuvent être découverts automatiquement permettant notamment de parcourir leurs fichiers.

GNOME prend en charge les comptes Microsoft OneDrive ce qui permet de facilement parcourir les fichiers sauvegardés avec ce service. Dans les comptes à distance, le protocole WebDAV est aussi pris en charge pour l'accès à des calendriers, listes de contacts et autres fichiers partagés. Pour l'authentification de ces comptes en ligne, le navigateur par défaut est utilisé dorénavant ce qui permet d'utiliser une plus grande diversité de moyens d'authentifications comme l'usage de périphériques USB dédiés.

Pour les amateurs de la connexion distante, il est maintenant possible de se connecter à GNOME graphiquement à distance via le protocole RDP. Auparavant seulement une session ouverte pouvait être pilotée ainsi. Cette option est désactivée par défaut et nécessite des droits appropriés, tout se configure via le panneau de configuration tout comme le bureau distant.

En parlant du panneau de configuration, ce dernier a été amélioré en regroupant plusieurs configurations par sections afin d'améliorer la clarté de l'application. La liste des menus devenait particulièrement importante et rendait difficile la localisation des éléments à configurer. De plus, la configuration du pavé tactile a été améliorée pour permettre de choisir entre le clic dans un coin ou le clic à deux doigts pour réaliser l'équivalent d'un clic droit avec ce périphérique.

Côté accessibilité, le lecteur d'écran Orca a été modernisé pour le rendre plus performant, plus fiable et plus compatible avec les applications Wayland ou celles exécutées dans un bac à sable tel que Flatpak. Il est possible de couper temporairement Orca avec le raccourci clavier Ctrl+Alt+Shift+Q ce qui est particulièrement utile en cas de conflit entre deux lecteurs d'écran ou si une application utilise du son aussi.

Les notifications dans GNOME indiquent par quelle application elles ont été émises. Il est maintenant possible d'étendre facilement la notification afin de pouvoir la visualiser en entier, utilisant une vue plus compacte par défaut.

De manière plus générale, GNOME bénéfice d'améliorations de performances notamment pour son terminal, son moniteur système qui bénéficie aussi d'un graphe dédié aux entrées / sorties sur les espaces de stockage, pour l'enregistrement de l'écran, le visionneur d'images ou encore pour la recherche globale de GNOME. L'ensemble des applications GTK4 bénéficie d'un nouveau moteur de rendu qui améliore le rendu du texte mais aussi les performances.

Bureau de KDE Plasma

L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6. Au passage Plasma 6 utilise Wayland par défaut, et s'il était prévu de supprimer totalement la possibilité de l'utiliser avec X11 pour simplifier la maintenance, des volontaires ont permis de repousser l'échéance pour l'instant.

Sous le capot, cette version utilise la nouvelle bibliothèque majeure graphique qu'elle emploie à savoir Qt 6. C'était l'occasion par ailleurs de rationaliser les différentes couches techniques et APIs internes afin de supprimer ce qui n'était plus au goût du jour ou trop peu employé pour être maintenu.

Cette version propose la prise en charge partielle du rendu des couleurs en HDR pour les applications et matériel compatibles, mais aussi un profil de couleur spécifique par écran afin d'avoir un rendu fidèle des couleurs. Dans cette thématique pour les personnes souffrant de daltonisme ou d'autres formes de maladies dichromatiques peuvent utiliser des filtres pour améliorer la lisibilité des applications et de leur contenu.

Dans les changements plus classiques, la barre principale est par défaut en mode flottant comme pour beaucoup de docks d'autres environnement de bureaux ou systèmes d'exploitation. Il est bien sûr possible de changer tout cela dans les paramètres et plus encore concernant cette barre principale. Concernant l'affichage principal, l'effet cube en cas de changement de bureau virtuel est de nouveau disponible. Pour la capture d'écran, il est possible de choisir une zone arbitraire de l'écran, d'utiliser le codec VP9 pour les enregistrements vidéos et de choisir sa qualité.

Le thème par défaut de l'environnement nommé Breeze bénéficie d'un rafraichissement, il utilise moins de cadres et a un affichage un peu plus compact.

Comme pour GNOME, la recherche a bénéficié d'un effort important. En plus de permettre la conversion de fuseaux horaires ou de trier les résultats par type, les performances sont grandement améliorées : jusqu'à 200% plus rapide pour chercher des documents, jusqu'à 60% plus rapide pour trouver une application, le tout jusqu'à moins 30% d'usage du processeur. La recherche obtient les résultats pour les textes traduits dans votre langue ou en anglais pour les noms ou les descriptions d'applications par exemple.

Il est dorénavant possible de s'authentifier par mot de passe ou par empreinte digitale en même temps, il n'est plus nécessaire de forcer l'une des deux options.

Et tant d'autres changements encore.

Gestion du matériel

Fourniture de ROCm 6 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d'AMD. Il concerne notamment les puces AMD Instinct MI300A et MI300X, et fournit de nouveaux algorithmes optimisés du mécanisme d'attention et de bibliothèques de communication. Il permet l'usage de flottant 8 bits pour gagner en consommation mémoire au détriment de la précision du modèle pour PyTorch et hipblasLT. Via la plateforme AMD Infinity Hub, il est possible d'obtenir des paquets prêts à l'usage pour certains travaux en IA ou calculs haute performance notamment pour les calculs scientifiques.

Les nouvelles notifications de GNOME

Passage à l'étape 2 de la prise en charge du noyau unifié nommée UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet. L'objectif dans cette phase est de pouvoir démarrer sur de tels noyaux directement sans chargeur de démarrage intermédiaire, tout en offrant la possibilité de démarrer sur d'autres noyaux et de passer automatiquement au noyau suivant par défaut suite à une mise à jour. Les machines Aarch64 (ARM 64 bits) peuvent également s'en servir maintenant. Une image pour cette architecture et x86_64 doit également être fournie pour un contexte de virtualisation en étant basée sur ces fichiers kickstart.

Si vous souhaitez tester cela sur un système existant, vous pouvez installer les paquets virt-firmware, uki-direct avant d'exécuter le script sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh pour configurer les partitions proprement afin d'être découvrables par le système, puis enfin installer le paquet kernel-uki-virt pour qu'il installe le noyau proprement avec la nouvelle méthode. Il est préférable de tester cela sur une machine virtuelle ou si vous savez ce que vous faites avec du matériel standard type ahci / nvme pour le stockage principal. Bien sûr ce travail reste expérimental et est réservé à ceux qui savent comment faire pour réparer le système en cas de problèmes.

Internationalisation

Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30. Les commandes pour lancer et relancer IBus fonctionnent depuis l'environnement Plasma Wayland dorénavant, et pour cet environnement aussi les préférences sont maintenant accessibles depuis le menu non contextuel.

Mise à jour de ibus-anthy 1.5.16 pour la saisie du japonais. Le principal changement est la conversion possible d'ère japonaise avec 2024.

Administration système

NetworkManager tente de détecter par défaut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection (RFC 5227) avant de l'attribuer à la machine. En somme au moment de s'attribuer une adresse IP donnée, une requête ARP est envoyée au réseau concernant cette adresse. Si une réponse est obtenue, l'adresse est déjà utilisée et n'est donc pas exploitable sans perturber le réseau. Ce mécanisme existe pour les réseaux avec IP fixes ou même avec un serveur DHCP central car rien n'empêche la présence d'une machine configurée avec une IP fixe dans le réseau malgré tout. Si le réseau a un serveur DHCP et qu'un conflit est détecté, la réponse DHCPDECLINE sera envoyée pour obtenir peut être une autre adresse. En cas de conflit une erreur sera rapportée permettant à l'utilisateur de diagnostiquer le problème et d'y apporter une solution. Par défaut le système attendra 200 ms avant de décider qu'il n'y a aucune réponse. Pour l'IPv6 cela est inclus dans le standard RFC 4862 ce qui rend ce changement non nécessaire dans ce cas de figure.

NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. En effet, certains systèmes utilisent l'adresse Mac pour identifier les machines en déplacement de réseau en réseau permettant une pseudo géolocalisation ce qui nuit à la vie privée. Mais la méthode usuelle de changer d'adresse MAC aléatoirement à chaque connexion pose un problème en cas de réseau restreignant l'accès à certaines adresses MAC uniquement ou en changeant d'adresse IP à chaque reconnexion. Cette méthode est un compromis entre le respect de la vie privée et le confort d'utilisation. Cela est fait en ajoutant la configuration wifi.cloned-mac-address="stable-ssid" dans le nouveau fichier /usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.conf.

Les entrées des politiques SELinux qui font référence au répertoire /var/run font maintenant référence au répertoire /run. Il y a dix ans déjà que le premier répertoire a bougé vers le deuxième chemin mais SELinux a gardé les vieilles règles en utilisant un lien d'équivalence entre eux pour permettre leur utilisation. Cependant certains outils comme restorecon ne gèrent pas bien cette situation tout comme les administrateurs systèmes qui ne sont pas sûrs de comment écrire proprement de nouvelles règles. Pour résoudre le problème le lien d'équivalence passe de /run = /var/run à /var/run = /run.

La recherche globale dans Fichiers

L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux. Il pouvait exploiter les fichiers /etc/passwd et /etc/group via l'utilisation de l'option id_provider=files. Cependant cette option n'est plus proposée par le projet officiel et n'était à l'époque conservée que pour permettre l'authentification via des cartes à puce ou l'enregistrement de sessions. Mais dans les deux cas il est possible de passer à la méthode proxy via l'option id_provider=proxy pour le remplacer dans ces cas d'usage. Un guide officiel est proposé pour effectuer la conversion pour ceux qui en ont besoin.

DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets. Jusqu'à présent il le faisait par défaut parmi d'autres métadonnées, mais cette information n'est en réalité nécessaire que dans certains cas précis qui ne concernent pas celui de la majorité des utilisateurs. Notamment pour quelques paquets ayant une dépendance envers un fichier particulier plutôt qu'un paquet donné ou si on cherche un paquet fournissant un fichier spécifique. Cela permet de réduire les ressources consommées chez les utilisateurs mais aussi au sein de l'infrastructure de Fedora car il n'est plus nécessaire de fournir ces données assez conséquentes de manière systématique.

L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares. Ce fichier qui représente environ 1 Mio est téléchargé quotidiennement parfois sur des liaisons coûteuses. Ainsi la pression est réduite sur les infrastructures notamment le CDN fwupd et la bande passante en utilisant localement la ressource quand elle est disponible. Passim utilise avahi pour signaler son service sur le réseau local qui est disponible via le port 27500 afin que les autres clients puissent identifier si des métadonnées sont disponibles localement.

Les systèmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise à jour du chargeur de démarrage. Par conception les systèmes avec rpm-ostree comme ceux-ci n'ont pas le chargeur de démarrage qui se met à jour par ce biais car cela n'est pas une opération sûre. En effet, la mise à jour de ces systèmes repose sur le principe de transaction pour que le passage d'un état à un autre soit fiable, cependant ce mécanisme ne fonctionne pas bien pour le chargeur de démarrage qui est un composant distinct et critique. On retrouve la même problématique pour les systèmes utilisant un mécanisme de mise à jour basé sur une partition A et B et passant de l'un à l'autre. D'où la création de cet utilitaire qui est mis à disposition pour ceux qui le souhaitent, du moins pour les machines disposant d'un EFI. La mise à jour est pour le moment manuelle à la demande avec la commande bootupctl update. La mise à jour automatique sera prévue dans le futur.

Le paquet libuser est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimé. La bibliothèque libuser sert à cacher les différences entre les utilisateurs locaux et distants via le protocole LDAP. Mais la prise en charge de ce protocole reste incomplet et il n'y a pas de plan pour aller plus loin, comme sssd peut la remplacer dans ce rôle, la décision de la supprimer prochainement de Fedora fait sens. Pour l'instant seuls les paquets usermode et util-linux en ont encore besoin. Le paquet passwd quant à lui disparaît pour se débarrasser de la dépendance à libuser. La commande pour changer de mot de passe ne change pas, mais est fournie par le paquet shadow-utils.

Le paquet cyrus-sasl-ntlm a été supprimé. Le protocole d'identification NTLM n'est plus maintenu, au profit du protocole Kerberos et ce composant dans SASL n'est plus maintenu depuis des années justifiant une telle décision.

La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM. BerkeleyDB 5.x fourni par Fedora n'est plus à jour ce qui pose des soucis en terme de bogues et de sécurité, d'autant plus avec le rôle de PAM dans le système. La licence de BerkeleyDB a changé dans la branche 6.x, passant de BSD à AGPL rendant impossible l'adoption de cette version plus à jour pour ce composant, les licences n'étant pas compatibles. Ainsi GDBM se pose comme une alternative pour résoudre ce problème. BerkeleyDB 5.x a débuté sa sortie du projet Fedora depuis Fedora 33, ceci est une étape de plus dans cette direction.

Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne. La raison est analogue au paragraphe précédent.

Le serveur LDAP 389 passe de la version 2.4.4 à la version 3.0.0. Le projet abandonne la prise en charge de BerkeleyDB pour sa base de données interne pour la même raison que précédemment. En dehors de cela qui introduit des incompatibilités, cette mise à jour est en réalité assez mineure sur les autres aspects en fournissant essentiellement des correctifs de bogues.

Le paquet iotop est remplacé par iotop-c. Si le nom du paquet change, celui du binaire installé ne change pas. iotop n'est plus vraiment maintenu depuis une dizaine d'années et est sévèrement concurrencé par iotop-c sur cet aspect qui bénéfice en plus d'une empreinte mémoire plus petite étant rédigé en C au lieu de Python. Il n'est pas pertinent aux yeux des mainteneurs de maintenir les deux ainsi.

L'orchestrateur de conteneurs Kubernetes évolue de la version 1.27 à la version 1.29. Ce changement est communiqué car Kubernetes déconseille le saut des versions ce que Fedora fait actuellement en passant à la version 1.28 en fournissant ainsi la dernière version disponible. Cette version propose aux utilisateurs la possibilité d'avoir un écart de version de n-2 à n-3 pour les versions mineures entre le nœud principal et le plan de contrôle. Il est également possible si un nœud est indisponible suite à une panne ou à un état non récupérable de démarrer les services qu'il gérait dans un autre nœud dans un état sain. Le mode d'accès aux données ReadWriteOncePod devient accessible sans restrictions, permettant de restreindre l'accès à des données à un seul pod à la fois plutôt qu'à un seul nœud, pour réduire le risque d'accès concurrents en particulier en écriture. De même le module KMS v2 est disponible à tous pour réaliser les services de chiffrement pour vos APIs.

Par ailleurs les paquets de Kubernetes sont restructurés. L'objectif est de se rapprocher de l'organisation du projet upstream et de simplifier la vie des utilisateurs. Ainsi le paquet kubernetes récupère l'utilitaire kubelet qui avait son paquet dédié et les services fournis via l'ancien sous-paquet kubernetes-master sont renommés kubernetes-systemd. Les paquets kubernetes-client et kubernetes-kubeadm restent inchangés.

Pendant que podman est mis à jour vers la version 5. Cette version abandonne la prise en charge des cgroupv1 du noyau, de même que les plugins CNI ou la base de données clé / valeur Boltdb au profit de SQLite pour les nouvelles instances. Le format des fichiers de configuration pour les podman machines a été profondément remanié, rendant nécessaire la recréation des machines virtuelles concernées conçues avant cette version.

Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version. Cette version propose du code multithreadé et qui télécharge plus vite grâce à la prise en charge du protocole HTTP2 avec la compression ou le téléchargement parallèle. Il propose plus d'options, il a également plus de tests automatiques pour s'assurer de sa robustesse dans le temps. Sa réécriture dans un style plus moderne devrait faciliter l'adoption de nouveaux protocoles à l'avenir. Par contre les protocoles dépassés WARC et FTP sont moins bien pris en charge. La licence change pour GPLv3+, de même que sa bibliothèque libwget2 vers LGPLv3+.

Améliorations du moniteur système

Le gestionnaire de base de données PostgreSQL migre vers sa 16e version. De part l'arrêt des modules, les paquets pour des versions alternatives sont également réintroduits. Ainsi les paquets postgresql15* font leur apparition pour la prise en charge de la version précédente, et les paquets postgresql17* seront proposés quand la 17e version sera disponible. En terme de changements apportés par cette nouvelle version, les jointures FULL ou OUTER sur des hash peuvent être parallélisées pour de meilleures performances. Il est dorénavant possible de répliquer des données depuis des serveurs dans un état standby, de même la réplication peut être appliquée en parallèle pour de larges transactions afin d'améliorer les performances de l'opération. La vue pg_stat_io fournit des informations statistiques concernant les entrées et sorties. SQL/JSON qui est introduit dans le standard SQL bénéficie de constructeurs dédiés pour créer des objets JSON mais aussi des fonctions identités pour connaître le type des clés. Et ce parmi de nombreuses corrections de bogues et d'amélioration de performances.

Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11 pour MariaDB. Le paquet community-mysql est renommé mysql tandis que le paquet mariadb ne fourni plus de binaires avec le nom mysql. En effet la décision à l'époque a été prise car il semblait convenu que MariaDB remplacerait MySQL tout comme LibreOffice a supplanté OpenOffice.org mais force est de constater que les deux projets vont cohabiter longtemps. Cela rend le tout plus simple pour l'utilisateur. Cependant, puisque ces logiciels évoluent séparément, ils deviennent peu à peu incompatibles et le mainteneur abandonne la possibilité d'utiliser MariaDB comme serveur avec MySQL comme client et vice-versa. Aucune autre distribution en fournissait une telle possibilité et cela devenait difficile à maintenir car cela était source de problèmes.

En terme de nouvelles fonctionnalités pour MariaDB, il est possible de lire entièrement les tables Information Schema Parameters et Information Schema Routines tout en améliorant les performances dans la procédure. Il est possible de savoir combien de temps une requête passe dans l'optimiseur via l'option ANALYZE FORMAT=JSON. Les semi-jointures pour la mise à jour ou la suppression de données sont optimisées. Les privilèges SUPER et READ ONLY ADMIN sont dorénavant distincts, à ce sujet il est possible de fournir à tous les utilisateurs des droits spécifiques via la requête GRANT <privilege> ON <database>.<object> TO PUBLIC.

Développement

Mise à jour de la suite de compilation GNU : GCC 14.0, binutils 2,41, glibc 2.39 et gdb 14.1.

Concernant la suite de compilateurs GCC, elle continue l'amélioration de la prise en charge des langages C23 et C++23, alors que débute la prise en charge de la future norme C++26. De nombreux modèles de puces Aarch64 et x86_64 bénéficient de micro-optimisations, tandis qu'il y a un début de prise en charge des nouvelles instructions pour l'architecture x86_64 d'Intel dénommées APX et AVX10. L'analyseur statique de code peut afficher visuellement les dépassements de tampons pour mieux comprendre ce qui se passe en mémoire.

Pour la suite d'outils binutils, cela se concentre surtout sur la prise en charge plus étendue des instructions des architectures Aarch64, RISC-V et x86_64.

Quant à la bibliothèque standard C glibc, cela se traduit par de nombreuses améliorations comme la prise en charge de la pile cachée pour éviter les attaques par modification d'adresse de retour, ce que Fedora Linux active par ailleurs. De même pour limiter certaines attaques, la glibc propose de pouvoir réécrire au lancement la PLT pour obtenir les adresses des fonctions des bibliothèques dynamiques plutôt que de les avoir lors du premier appel à chaque fonction. Le programme démarre plus lentement mais est plus sûr pour la suite. L'en-tête <stdbit.h> fait son apparition pour les manipulations sur les bits, opérations basées sur la norme de C20. Et une nouvelle fonction posix_spawnattr_setcgroup_np est ajoutée pour démarrer un processus dans un cgroup donné afin d'éviter des situations de concurrence entre le moment où le processus est démarré et où les restrictions s'appliquent.

Enfin le débogueur gdb propose un début de prise en charge du protocole de Microsoft Debugger Adapter Protocol pour faire le lien entre les débogueurs et des IDEs ou éditeurs de code afin de faciliter leur intégration mutuelle. Il peut également gérer des entiers au delà de 64 bits, de même que d'appeler une commande shell avec l'instruction $_shell pour obtenir son résultat. Les instructions de l'architecture Aarch64 SME et SME2 commencent à être gérées et l'API Python est considérablement étoffée pour ceux qui veulent scripter le débogueur.

La suite de compilateurs LLVM est mise à jour à la version 18. Fedora en profite pour que CLang utilise des informations de débogage au format DWARF-5 au lieu de DWARF-4 par défaut comme appliqué par le projet amont. Pour simplifier la procédure de compilation de Fedora pour les paquets utilisant cette chaîne de compilation, le Fat-LTO sera employé pour permettre l'usage du LTO quand c'est possible comme cela était déjà le cas avec GCC. Jusqu'alors ces paquets étaient compilés avec LTO par défaut avec une éventuelle conversion vers ELF à la main si la compatibilité le nécessitait ce qui était particulièrement lourd. Par ailleurs les paquets de compatibilité des versions précédentes fournissent les binaires des différents utilitaires et non plus seulement les bibliothèques et en-têtes.

Concernant les nouveautés apportées par le projet en lui même, comme pour la chaîne de compilation GNU, les architectures Aarch64, x86_64 ou RISC-V sont mieux gérées. Le compilateur CLang suit GCC avec du travail sur C++20, C++23 pour améliorer la compatibilité avec le standard et le début de prise en charge de la future norme C++26.

Mise à jour de la bibliothèque C++ Boost à la version 1.83. Depuis la version 1.81, cette bibliothèque propose un module pour communiquer avec les bases de données MySQL ou encore une bibliothèque Compat: pour fournir en code compatible C++11 des ajouts proposés par les standards ultérieurs.

Le langage Go passe à la version 1.22. La sémantique de la boucle for évolue un peu avec la création de la variable de boucle à chaque itération de boucle plutôt qu'à la première avec mise à jour à chaque passage. De plus il accepte l'usage des plages de valeurs basées sur des entiers. L'exécution des programmes gagne 1 à 3% grâce à l'optimisation de la localisation mémoire des métadonnées du ramasse miette. Les programmes compilés avec un profil d'optimisation peuvent gagner entre 2 et 14% de performances par rapport à la version précédente grâce à la possibilité d'appliquer la technique sur plus de fonctions qu'avant.

Le JDK de référence pour Java passe de la version 17 à 21. OpenJDK peut maintenant faire du filtrage par motif dans une instruction switch. Il est possible aussi d'affecter le résultat d'une identification de type dans une variable directement afin de pouvoir s'en servir immédiatement. Des fils d'exécution virtuels font leur apparition qui sont plus légers et performants, plutôt dédiés à des tâches courtes avec beaucoup d'attentes, ces tâches peuvent ainsi bénéficier de meilleure performance notamment en terme de latence. Il introduit également une API pour les collections d'objet en séquence (donc ordonnées). De même une nouvelle API pour manipuler les clés cryptographiques symétriques fait son entrée. Le ramasse miette Z Garbage Collector améliore ses performances.

Ruby 3.3 surveille sa syntaxe avec Prism. Prism est un gem introduisant un nouveau parseur très flexible qui a vocation à remplacer Ripper. Le compilateur juste à temps YJIT bénéficie de nombreuses améliorations comme de meilleures performances, une réduction de la consommation mémoire avec un code généré plus compact et avec moins de métadonnées et un temps de compilation plus court. Un concurrent RJIT fait son entrée, écrit en pur Ruby et non en C comme YJIT, il a plus vocation à servir de terrain d'expérimentation. Le ramasse miette est également plus performant.

Connexion à distance dans GNOME

Le langage PHP utilise la version 8.3. Cette version permet de définir des classes constantes, il propose également un attribut #[\Override] si une classe surcharge une méthode d'une classe parente. Une nouvelle fonction json_validate permet de vérifier la validité d'un JSON sans le décoder. Le Randomizer a plus de méthodes pour permettre de générer des noms ou nombres aléatoires suivant les besoins.

La boîte à outils pour le machine learning PyTorch fait son entrée dans Fedora. L'objectif est de fournir une meilleure expérience pour les développeurs de ce genre de solution. Un groupe de travail dédié s'est mis en place avec une réunion bi-hebdommadaire. Pour le moment l'architecture x86_64 est la seule prise en charge avec un effort important mis sur les solutions AMD.

Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité. Cette version apporte entre autre de l'annotation de type ce qui permet de construire des ORM sur un modèle déclaratif. Les opérations d'insertions sont aussi bien plus performantes quelque soit le gestionnaire de base de données derrière.

La bibliothèque de validation des données Pydantic utilise dorénavant la version 2. Outre l'amélioration des performances, il change radicalement son API ce qui coupe la compatibilité ascendante.

La bibliothèque Thread Building Blocks passe du fil 2020.3 au fil 2021.8. De même la compatibilité ascendante n'est pas garantie ce qui a rendu ce portage compliqué.

La bibliothèque OpenSSL 1.1 est supprimée ne laissant que la dernière version de la branche 3.x. Depuis Fedora 36 la branche 3 est employée par défaut dans Fedora. OpenSSL 1.1 n'est plus maintenue depuis fin de l'année dernière ce qui rend sa maintenance délicate et non sûre d'où son abandon malgré la faible compatibilité entre les deux versions pour ceux qui s'en servait encore.

Les bibliothèques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant. Ces versions sont plus rapides grâce à l'emploi des instructions plus modernes des processeurs actuels tout en gardant la compatibilité par rapport à l'implémentation de référence.

Le langage Python ne bénéficie plus de la version 3.7. Depuis juin de l'année dernière cette version n'est plus maintenue et il n'y a pas de raison de poursuivre son maintien dans les dépôts en tant que version de compatibilité.

Projet Fedora

L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji. L'utilitaire ImageFactory employé jusqu'à présent n'est plus maintenu. Les outils mkosi et osbuild ont été considérés mais non retenus, le premier car il manque de flexibilité pour fournir toutes les images souhaitées, tandis que le second est certes adopté par l'équipe de Fedora Workstation mais ne semble pas adapté aux besoins des images clouds qui reposent sur d'autres technologies dont rpm-ostree et doit fournir des délivrables plus variés également. En effet l'image cloud cible Vagrant, Azure, AWS, GCP et peut dorénavant viser aussi les images pour WSL2 ou pour conteneurs directement.

Tandis que l'édition Workstation aura son image ISO générée avec l'outil Image Builder. En effet ce dernier bien que déjà employé par Fedora Workstation bénéficie enfin de la prise en charge des images ISO live. Il remplace donc les outils lorax/livemedia-creator qui avaient beaucoup de problèmes. Il devient aussi plus simple pour quiconque de générer son image ISO avec un simple fichier TOML pour le décrire et quelques utilitaires en ligne de commande.

L'image minimale ARM sera construite avec l'outil OSBuild. Comme dans le cadre de l'édition Cloud, il remplace l'utilitaire ImageFactory qui montrait ses limites. L'objectif à terme est de pouvoir supprimer totalement ou partiellement les hacks nécessaires à ce jour pour utiliser cette image sur une grande variété de systèmes ARM.

Fedora IoT bénéficiera d'images pouvant démarrer dans des conteneurs. Ainsi il est possible de tester le système dans des conteneurs plutôt que via de la virtualisation classique ou sur des machines physiques. Cette flexibilité peut aider le test par les utilisateurs mais également par ses mainteneurs.

Il bénéficiera également des images Simplified Provisioning. Fedora IoT peut ainsi utiliser l'utilitaire coreos-installer pour l'installer sur le disque directement et ce en utilisant un argument noyau pour savoir sur quel disque l'installer. Ainsi pas besoin de fichier kickstart ou d’interaction avec l'utilisateur ce qui simplifie la procédure et son automatisation. Cela s'intègre parfaitement avec les dispositifs Fido Device Onboarding et Ignition pour la configuration de tels systèmes dans un environnement de production.

Et le tout sera construit en utilisant rpm-ostree unified core. L'ancien mode n'est en effet plus maintenu et moins testé. Le mode unifié permet au compose server, qui est l'image de base créée à partir de RPM, de fonctionner de manière similaire au client qui ajoute des commits par dessus pour personnaliser le contenu du système. Cela permet de simplifier la maintenance côté rpm-ostree mais aussi de résoudre certaines difficultés notamment pour la gestion du démarrage avec bootupd, les labels SELinux et l'utilisation de conteneurs pour les scriplets pré et post installations des paquets. Depuis Fedora Linux 39 où Silverblue et Kinoite ont amorcé la transition, l'édition IoT était la dernière variante à ne pas avoir franchi le pas.

Fedora sera construit avec DNF 5 en interne. Ainsi les outils Mock, Koji et Copr passent le cap, en attendant Fedora Linux 41 pour que cela soit le cas pour les utilisateurs de la distribution. L'objectif est ici double. Les développeurs de DNF auront un retour d'expérience grandeur nature sur cette version et permettra d'identifier d'éventuels problèmes. Pour l'infrastructure, DNF 5 est plus léger en mémoire, plus performant et consomme moins d'espace disque ce qui permettrait de gagner du temps dans la construction des RPM et des images et de réduire la pression sur le matériel employé à ces tâches.

KDE Plasma avec des applications

Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros. Ces projets sont maintenant distincts upstream et ce premier dépend maintenant du second. L'objectif est de simplifier la possibilité d'exécuter des tests automatiques sur ces macros afin d'améliorer leur fiabilité.

Phase 3 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora. L'objectif de cette phase est de poursuivre le travail entamé dans les versions précédentes en convertissant l'essentiel des paquets RPM vers ce nouveau format. Cependant le travail devrait être achevé pour l'ensemble des paquets pour Fedora Linux 41.

La construction de certains paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction. C'est la macro %{hardened_build} qui est étendue pour fournir ce service, cela ne concerne que les paquets l'utilisant. Il peut ainsi générer une telle erreur s'il détecte une pile exécutable, un segment chargeable en mémoire avec des permissions en lecture, écriture et exécutable ou un fil d'exécution local ayant un segment exécutable. L'objectif est donc de renforcer le caractère non modifiable des sections mémoires exécutables pour limiter le risque de failles de sécurité. Cela est fait grâce à l'éditeur de lien BFD qui fournit de telles vérifications. Jusqu'à présent ces cas étaient détectés mais ne généraient que des avertissements qui étaient de fait ignorés.

Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C. L'objectif est de supprimer de plus en plus de code utilisant d'anciennes constructions qui sont source de bogues d'une part, mais qui seront aussi progressivement interdites par défaut avec les futures versions de GCC. Par ailleurs, certains de ces éléments pouvaient être bloquants pour l'adoption d'une nouvelle norme C de référence pour certains paquets.

Voici la liste des changements opérés :

  • Suppression des déclarations implicites de fonctions : 54 paquets concernés ;
  • Suppression du type implicite int quand le type est omis : 5 paquets concernés ;
  • Obligation de mentionner les types dans les arguments lors de la déclaration de fonctions : aucun paquet concerné ;
  • Interdiction de conversions implicites entre entier et pointeurs : 100 paquets concernés ;
  • L'instruction return doit avoir les arguments qui correspondent au type de retour d'une fonction (donc pas d'argument si void, et non vide si un entier est attendu par exemple) : 13 paquets concernés ;
  • Interdiction des conversions implicites de pointeurs de types différents : 381 paquets concernés.

Certains changements devraient voir le jour dans le futur :

  • Interdiction des déclarations de fonctions dans le style pré-C89 ;
  • Interdiction d'utiliser des mots clés bool, true ou false avec des définitions locales plutôt que d'utiliser l'en-tête de la bibliothèque standard ;
  • Déclarer une fonction sans argument comme void foo() aurait le même sens qu'en C++, à savoir équivalent à void foo(void) plutôt qu'à accepter n'importe quel type d'arguments.

Clap de fin pour la construction des mises à jour au format Delta RPM. Ils sont désactivés par défaut dans la configuration de DNF et Fedora ne les générera plus. Cette fonctionnalité permettait pour les mises à jour de ne télécharger que la différence entre le paquet déjà installé et celui à mettre à jour. Cela permettait de réduire la quantité de données à télécharger, la machine de l'utilisateur pouvait reconstruire le paquet à partir de ces informations et ainsi obtenir la nouvelle version. Mais en pratique la fonctionnalité se révèle de moins en moins pertinente. Tout d'abord le processus n'est pas fiable à 100%, parfois la reconstruction échoue et dans ce cas le nouveau paquet est totalement téléchargé à nouveau ce qui conduit à un gaspillage de ressources. De plus peu de paquets étaient concernés, les delta RPM étaient d'ailleurs construits en général que d'une version à une autre ce qui la rend fonctionnelle surtout pour ceux qui mettent à jour très régulièrement leur système. Et pour que cette fonctionnalité soit exploitable, ces fichiers delta rpm font partie des métadonnées que DNF télécharge. Sauf que c'est le cas même si les delta rpm sont désactivés par l'utilisateur, ou pour les systèmes reposant sur rpm-ostree ou utilisant un GUI comme GNOME Logiciels car PackageKit comme rpm-ostree ne se servent pas de ces métadonnées. Au final cela pénalise toute l'infrastructure qui doit générer et stocker ces données, et beaucoup d'utilisateurs qui subissent les inconvénients sans les avantages le tout pour un gain jugé marginal pour ceux qui s'en servent : moins de 8% de réduction de la taille des téléchargements en moyenne.

Les JDKs ne sont générés qu'une fois, et rempaquetés ainsi à toutes les variantes du système. Pour cela les paquets du JDK sont générés à partir de la version la plus ancienne de Fedora Linux encore maintenue, et le résultat est directement réutilisé pour former les paquets des autres versions du système. Cela réduit considérablement le temps de validation de chaque JDK car il y a cinq fois moins de versions différentes à gérer. Cela permettra aux mainteneurs de maintenir la diversité actuelle des JDK à savoir les versions 1.8.0, 11, 17 et la dernière (actuellement la version 20). Si ce résultat ne permet pas de libérer assez de temps aux mainteneurs, la réduction du nombre de JDK à l'avenir pourrait être considérée.

Les images immuables pour les systèmes personnels comme Silverblue seront nommées sous la dénomination Atomic pour éviter la référence au terme immuable qui est confus pour les utilisateurs. Les noms de variantes Silverblue, Kinoite, Sericea et Onyx vont être préservés, l'objectif est de donner une dénomination commune qui utilise le terme Atomic déjà employé par l'édition Cloud par exemple. Le terme immuable est en effet considéré comme peu clair car si le système principal est majoritairement en lecture seule, il ne l'est pas totalement notamment pour la configuration ou les parties dynamiques du système. Alors que le système repose sur le concept d'atomicité en ayant une approche par état du système, d'où la nécessité de redémarrer pour changer cet état notamment lors d'une mise à jour par ailleurs.

L'objectif est donc purement au niveau de la communication autour de ces systèmes. Cependant les nouvelles variantes devraient utiliser ce terme dans ce nom comme par exemple Fedora XCFE Atomic si jamais cette variante prend vie un jour.

La communauté francophone

L'association

Logo de Boorsalinux-fr

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

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

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

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

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

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

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

La documentation

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

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

La synchronisation du travail se passe sur le forum.

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

Comment se procurer Fedora Linux 40 ?

Logo de Fedora Media Writer

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

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

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

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

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de GIMP 2.99.18 (version de développement)

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.99.18 du 21 février 2024 (en anglais).

Voici enfin la dernière version de développement avant GIMP 3 ! Bien que la sortie de la version 2.99.18 soit un peu en retard par rapport au planning espéré, celle-ci contient un certain nombre de fonctionnalités et d'améliorations que nous sommes ravis de pouvoir partager avec vous.

⚠️ ☢️ Nous vous rappelons qu'une version de développement sert à présenter les travaux en cours, mais vous permet aussi de détecter et signaler les problèmes au plus tôt. En d'autres termes, cette version est instable et nous ne recommandons pas son usage en production. Utilisez-là parce que vous voulez aider à améliorer GIMP en signalant des bogues.

En particulier, cette version 2.99.18 est peut-être l'une des versions les plus instables de la série 2.99 à cause du projet « space invasion » (NDT : « invasion venue de l'espace », un jeu de mots avec l'anglais colorspace signifiant espace de couleurs). Cela est parfaitement attendu et normal. ⚠️ ☢️

    Sommaire

    Cette dépêche présente les changements les plus notables et les plus visibles. En particulier, elle ne contient pas de liste exhaustive des correctifs de bogues ou des améliorations un peu moins importantes. Pour une liste plus complète des changements, nous vous invitons à consulter le fichier NEWS ou à jeter un coup d’œil à l'historique du dépôt Git.

    L'invasion de l'espace (des couleurs) !

    Nous avons travaillé dur sur le projet Space Invasion, qui est — comme vous vous en rappelez peut-être — le nom de code que nous avons donné au projet visant à rendre GIMP plus correct en ce qui concerne les couleurs.

    Ces derniers temps, nous avons réalisé le portage des anciennes structures de couleurs utilisées en interne (GimpRGB, GimpCMYK, GimpHSV…) dont nous nous servions pour stocker les informations de couleurs vers GeglColor. Cet objet générique peut contenir n'importe quelle donnée de couleur, quel que soit le modèle colorimétrique, la précision ou l'espace, du moment que ceux-ci sont pris en charge par babl, notre moteur pour l'encodage des pixels.

    En ce qui concerne la justesse des couleurs, cela signifie que nous ferons maintenant les conversions de couleurs uniquement si cela est nécessaire (conversions à la dernière minute), ce qui permettra de ne pas perdre d'information lorsque cela peut être évité. Par exemple, imaginons que vous utilisiez la pipette à couleurs sur une image : si nous convertissions cette couleur vers un format intermédiaire avant de l'utiliser sur une autre image (qui peut avoir le même format de couleurs ou un format différent), deux conversions auraient lieu. Cela augmente les possibilités de perte de précision. Ce problème est encore plus flagrant si les formats d'entrée et de sortie sont les mêmes (autrement dit, lorsqu'aucune conversion n'est nécessaire). Et cela sera encore plus problématique lorsque le modèle CMJN sera pris en charge nativement (nous voulons éviter à tout prix de faire un aller-retour entre un format intermédiaire et le CMJN, qui n'a pas de relation bijective avec la plupart des autres modèles de couleurs, même en travaillant sans bornes et en ignorant les problèmes de précision).

    Définition d'un espace non borné (ajout par rapport à la dépêche originelle) : lorsque la précision est entière, l'espace est toujours borné (par exemple [0-255] en 8-bit). Par contre, en flottant, où l'espace de travail standard est [0, 1], on peut décider d'accepter les valeurs négatives et supérieures à 1. Cela rend les conversions entre beaucoup d'espaces de couleurs bijectives, aux erreurs de précisions près. Notamment, les conversions entre deux espaces RVB, ou même un espace RVB et divers autres modèles, deviennent bijectives. Ce n'est pas le cas entre RVB et CMJN, même en espace de couleurs infini.

    Nous sommes également en train de migrer le stockage des données de couleur vers ce type d'objet générique. Cela signifie entre autres que les palettes de couleurs pourront comporter des couleurs au format CMJN, CIELAB ou bien encore dans tout autre modèle pris en charge (et pas seulement ces couleurs après une étape de conversion vers le sRVB non borné - « unbounded sRGB »).

    Une conséquence pour la maintenance logicielle est qu'il sera beaucoup plus facile de gérer les conversions de couleurs au sein de notre code, étant donné que cette structure comprend à la fois les données et leur « signification ». Cela rend la gestion des couleurs beaucoup moins susceptible d'introduire des bogues par rapport à l'approche précédente, qui consistait à faire suivre les deux types d'information séparément.

    Finalement, nous travaillons à faire apparaître l'information concernant l'espace de couleurs à plusieurs endroits de l'interface où cela est pertinent, par exemple lorsque des données RVB, CMJN, TSL ou TSV sont affichées ou peuvent être choisies. Les valeurs brutes dans ces modèles de couleurs en l'absence de la connaissance de l'espace de couleurs associé n'ont pratiquement aucun sens. L'affichage dans l'interface de valeurs RVB sans autre précision est un reliquat du passé, lorsque cela signifait le plus souvent sRVB. Cela n'est plus vrai dans un contexte graphique moderne et l'interface devrait être claire à ce sujet.

    La vidéo ci-dessous montre quelques aspects de ce travail sur l'interface, par exemple le fait que les modèles RVB, TSV ou CMJN affichent à tout instant l'espace de couleurs dans lequel les valeurs sont considérées (ce qui très souvent correspond au nom du profil ICC). Cela est déjà fait pour la pipette à couleurs, les échantillons de couleurs, l'ancrable des couleurs de premier/d'arrière plan, la boîte de dialogue « Changer la couleur de premier/d'arrière plan », ainsi qu'à d'autres endroits.

    Non seulement cela, mais lorsque les gens sélectionnent un profil d’épreuve sur écran et activent l'épreuve sur écran (par exemple grâce à la nouvelle bascule de simulation qui a été ajoutée dans GIMP 2.99.12), nous afficherons également non seulement la zone hors gamme de l'espace colorimétrique de l'image, mais également celle de l'espace d’épreuve.

    Invasion de l'espace dans l'interface - GIMP 2.99.18
    Invasion de l'espace dans l'interface - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

    Avertissement très important : il s'agit encore une fois d'un portage énorme dans notre base de code, ce qui a impacté littéralement des milliers de lignes de code. Ce travail est inachevé mais il devra être terminé avant la première version candidate. Des instabilités ou des bugs sont à prévoir dans cette mise à jour donc si vous rencontrez un problème, nous recommandons de le rapporter.

    Amélioration des algorithmes de couleur

    Øyvind Kolås a amélioré quelques algorithmes internes :

    • Les pixels achromatiques de l'outil Teinte-Saturation sont désormais un cas spécial afin que les pixels en niveaux de gris (saturation de 0) ne soient modifiés que par le réglage principal, pas par le réglage rouge.
    • Les dégradés en niveaux de gris restent désormais achromatiques même avec "Tramage" coché dans l'outil Dégradé.

    Au fur et à mesure que le projet space invasion avance, obtenir des résultats cohérents devient plus facile dans divers algorithmes liés aux couleurs, nous permettant ainsi de découvrir rapidement les problèmes et de les résoudre.

    Édition non-destructive, première mouture

    Un domaine dans lequel nous sommes « en avance sur le planning » est l'édition non destructive, qui était très demandée ! Les fondations de ces fonctionnalités ont été mises en place par de nombreux développeurs au cours de nombreuses années, depuis l'introduction de GEGL dans GIMP. Bien qu'initialement prévue pour la feuille de route de la version 3.2, une première implémentation a vu le jour en tant que continuation d'un projet Google Summer of Code. Si vous n'êtes pas familier avec ce terme, « édition non destructive » implique notamment que des effets de filtres tels qu'un effet de flou sont stockés séparément des pixels du calque. Cela signifie que si vous désirez plus tard modifier un réglage, réarranger ou même retirer le filtre, vous pouvez le faire très facilement sans affecter le reste de l'image. Jusqu'à présent, GIMP utilisait une procédure d'édition destructive où les effets étaient immédiatement appliqués sur le calque, c'est donc un changement majeur !

    Toute opération GEGL munie d'une interface graphique est désormais appliquée aux calques de manière non destructive. (Les effets non destructifs pour les masques de calques et les canaux sont prévus pour les versions ultérieures.) Cela inclut les greffons GEGL tiers et les opérations personnalisées créées avec notre outil GEGL Graph. Ces effets peuvent être sauvegardés et chargés via les fichiers de projet .xcf, bien que toutes les propriétés GEGL ne soient pas encore prises en charge dans la version actuelle.

    Une fois qu'un filtre a été appliqué, vous pouvez continuer à interagir avec lui en cliquant sur l'icône de filtre dans l'ancrable des calques. Cela ouvrira une boîte de dialogue montrant tous les filtres actuellement appliqués au calque. À partir de là, vous pouvez alterner l'état de visibilité du filtre, modifier ses réglages, réordonner les filtres et retirer les effets un à un. Vous pouvez aussi fusionner tous les filtres et les appliquer à l'image pour retrouver une procédure d'édition destructive.

    Effets non destructifs - GIMP 2.99.18
    Effets non destructifs - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

    Notez bien que tout cela est seulement une première implémentation, et beaucoup de travail reste à faire pour disposer d'une édition non destructive complète et riche. Nous allons continuer à affiner les fonctionnalités existantes pour la sortie de la version 3.0 en nous basant sur les tests et les retours des utilisateurs, et nous les développerons davantage par la suite. L'interface elle-même ne correspond pas à notre vision idéale de cette fonctionnalité, et un premier jet de spécifications a été écrit pour définir un processus d'édition bien plus intégré.

    La capture d'écran ci-dessous est une maquette réalisée à partir de ces premières spécifications. Elle montre les effets de calque placés au sein de la liste principale des calques, partageant les mêmes boutons « œil » et « cadenas », mais également avec leurs propres masques faciles à éditer :

    Maquette des spécifications pour l'application non-destructive d'effets de calque

    Maquette des spécifications : les effets de calque sont visibles directement dans la liste des calques, avec leur propres masques

    Néanmoins, l'implémentation de cette nouvelle interface sera un défi en elle-même et nous avons donc décidé de la remettre à après la sortie de GIMP 3 et de proposer cette première mouture en premier lieu.

    N'hésitez pas à partager vos opinions dans les forums de discussion et dans le suivi des incidents !

    Amélioration de la prise en charge des polices de caractères

    Idriss Fekir, un autre étudiant du GSoC 2023, a travaillé avec Liam Quinn, un développeur de longue date, sur l'amélioration de la prise en charge des polices de caractères par GIMP. Une grande partie de ce travail concerne le code interne de GIMP afin d'améliorer sa capacité à gérer les futures mises à jour de polices et de texte. Certains changements plus visibles sont par exemple :

    • GIMP n'a plus besoin que les noms des polices de caractères soient uniques pour pouvoir les distinguer les unes des autres. Cela signifie qu'il n'ajoutera plus « #1 », « #2 » et ainsi de suite, mais gardera à présent les noms originaux dans la liste de sélection des polices. Malgré des noms apparemment identiques, deux polices avec le même nom fonctionneront désormais correctement.
    • GIMP peut maintenant charger des polices avec des styles personnalisés (en contournant l'utilisation de Pango qui n'est pas capable de les charger).
    • Nous pouvons à présent charger davantage de types de polices qu'auparavant. Si jamais nous ne prenons pas encore en charge une police donnée (ou si elle est inexistante), nous sommes mieux à même de le détecter et nous pouvons nous replier sur une police par défaut. Cela permet d'améliorer la prise en charge d'un fichier .xcf créé sur un autre ordinateur avec différentes polices disponibles.
    • Sous Windows, nous forçons le moteur Pango à toujours utiliser l'anticrénelage. Cela augmente la lisibilité du texte des menus sous ce système d'exploitation, en particulier lorsqu'un thème sombre est utilisé.
    • Le code pour la sauvegarde au format XCF stocke désormais les informations concernant les polices de manière bien plus précise, ce qui aide à éviter de charger une police incorrecte lors de la réouverture d'un fichier XCF.
    • L'alignement du texte dans les calques de texte pour les langues écrites de la droite vers la gauche est maintenant plus cohérent avec la manière dont cela fonctionne dans d'autres programmes (par exemple LibreOffice et Scribus).

    Ces changements sont beaucoup moins voyants que certaines autres fonctionnalités et pourraient sembler moins importants, mais ils constituent en fait les fondations qui permettront d'avoir une gestion du texte bien plus fiable dans GIMP. Notre vision pour le futur est d'avoir une édition de texte plus simple tout en étant plus puissante et plus riche en fonctionnalités (en particulier les fonctionnalités OpenType qui sont quelques-unes des améliorations majeures que nous espérons ajouter un jour ou l'autre).

    Expansion automatique des calques

    Le troisième projet GSoC de l'été dernier par l'étudiant Shubham Daule a apporté une fonctionnalité demandée depuis longtemps : l'expansion automatique de calques ! Les outils de peinture ont désormais une option supplémentaire « Étendre les calques ». Lorsque cette case est cochée, peindre au-delà des limites des calques les fera s'étendre automatiquement afin que vous n'ayez pas à gérer vous-même la taille du calque. Si vous souhaitez étendre le calque au-delà de la taille actuelle du canevas, vous devrez également cocher l'option « Afficher tout » dans le menu Affichage.

    Calques à expansion automatique - démonstration de GIMP 2.99.18
    Calques à expansion automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

    L'option d'expansion des calques comporte également des paramètres supplémentaires lorsqu'elle est sélectionnée. Vous pouvez décider dans quelle mesure vous souhaitez que les limites du calque s'étendent chaque fois que le pinceau les atteint. Il existe également des options pour spécifier comment les nouvelles zones du calque et du masque de calque doivent être remplies une fois étendues.

    Nouvelles options d'alignement

    Le nouveau contributeur mr. fantastic a développé deux nouvelles options pour aligner les calques sur le canevas. Avec « Snap to Bounding Boxes » (« Aligner sur les boîtes englobantes ») activé, des guides dynamiques s'afficheront désormais pour vous montrer quand le calque que vous déplacez est aligné avec le centre ou les côtés des autres. Le calque actif s'alignera également sur ces bordures pour vous aider à les organiser correctement. La deuxième option, « Snap to Equidistance » (« Aligner à équidistance »), vous permet un alignement entre trois calques équidistants les uns des autres.

    Aligner sur les boîtes englobantes et Aligner à équidistance - démonstration de GIMP 2.99.18
    Nouvelles options d'alignement automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

    Thèmes

    Nous avons continué à améliorer l'interface utilisateur et le style de cette version. L’une des améliorations les plus importantes concernait la gestion des « fuites de thèmes système ». Il existe des styles qui n'ont pas été spécifiquement définis dans nos thèmes, donnant ainsi l'opportunité aux règles de style du thème système de "fuiter" de manière conflictuelle dans notre interface. Avec l’aide et les retours de plusieurs contributeurs et utilisateurs, nous avons beaucoup progressé dans la définition de ces styles afin que tous aient une expérience cohérente !

    Récemment, Jehan a travaillé sur la réorganisation et la simplification de notre système de thèmes. Dans les versions de développement précédentes, nous avions cinq thèmes différents : Par Défaut, Gris, Système, Plus Sombre et Compact (chacun avec des options claires et sombres). Ceux-ci ont été simplifiés dans le thème Système et un seul thème par défaut avec trois états possibles : clair, foncé et gris. De même, nos quatre thèmes d'icônes distincts ont été condensés dans l'ensemble Legacy et un thème d'icôns par défaut avec des variantes couleur et symbolique. Nous pensons que ces changements réduiront la confusion des utilisateurs et leur permettront de trouver plus facilement leur apparence d'interface préférée.

    De plus, sous Windows, la barre de titre principale (et la plupart des barres de titre des boîtes de dialogue) s'ajuste désormais au mode clair ou sombre en fonction du thème sélectionné.

    Boîte de dialogue de bienvenue

    La boîte de dialogue de bienvenue a été étendue pour fournir un accès rapide à un certain nombre de fonctionnalités et d'options utiles. Elle comporte ainsi quatre nouvelles sections :

    • Personnaliser : Plusieurs options de personnalisation nécessitent de fouiller dans la boîte de dialogue des Préférences pour être modifiées. À présent, vous pouvez facilement modifier les thèmes de couleurs et d'icônes, la langue et la taille de la police de l'interface utilisateur, ainsi que certains réglages en fonction du système d'exploitation.
    • Créer : Cette section affiche les huit images que vous avez ouvertes en dernier et vous permet de les rouvrir rapidement. Des boutons pour créer une nouvelle image ou pour en charger une existante sont également présents. À l'instar d'autres programmes, vous pouvez demander à ce que cet écran apparaisse automatiquement au démarrage de GIMP pour un accès direct à ces fonctionnalités.
    • Contribuer : Nous avons réuni ici quelques-unes des nombreuses façons dont vous pouvez participer au développement de GIMP. Cette section comporte des liens pour le signalement de bogues, pour écrire du code, pour aider aux traductions ou pour faire un don.
    • Notes de version : Précédemment, le lien vers ces notes étaient affichées dans la moitié inférieure de la boîte de dialogue de bienvenue. À présent, nous avons un onglet entier dédié à ces notes pour une lecture plus aisée.

    Formats de fichiers

    Comme cela était déjà le cas avec les versions précédentes, nous avons amélioré la prise en charge de formats de fichiers déjà existants et nous avons ajouté la prise en charge de l'importation et de l'exportation pour de nouveaux formats.

    DDS

    Stayd, un nouveau contributeur, a travaillé avec notre développeur Jacob Boerema pour apporter de nombreuses améliorations au greffon DDS. Pour commencer, les fonctions d'importation ont été écrites afin d'être plus simples et plus faciles à étendre dans le futur. Les mises à jour supplémentaires incluent également :

    • Le chargement d'images DDS RVBA 16 et 32 bits/canal est maintenant possible.
    • Le filtre cubique Catmull-Rom a été ajouté pour la génération de mipmaps, et tous les calculs pour générer les mipmaps sont effectués avec une précision de 32 bits.
    • Les images DDS aux formats R8G8, R16 et R16G16 peuvent maintenant également être chargées.
    • Une option pour renverser verticalement les images DDS lors de l'importation a été ajoutée pour faire écho à l'option d'exportation correspondante, étant donné que certaines images de jeux stockent leurs données de cette manière.

    GIF

    Par le passé, écraser un fichier GIF à la sauvegarde (plutôt que de l'exporter) le convertissait systématiquement en un fichier avec une seule image. Désormais nous vérifions lors du chargement si le fichier GIF est une animation, de manière à également sauvegarder une animation lors de l'écrasement.

    HEIF et JPEG-XL

    Les deux greffons utilisent maintenant leurs bibliothèques respectives (libheif et libjxl) pour le chargement des métadonnées. Cela nous a permis de retirer notre code maison chargé d'interpréter l'orientation des images et d'utiliser à la place les informations fournies par ces bibliothèques.

    OpenEXR

    Le format OpenEXR permet aux canaux d'avoir des noms personnalisés, outre le type de couleur. Dans ce cas, nous considérons maintenant toute image à un seul canal avec un nom non conventionnel comme étant en niveaux de gris. Lors de l'importation, nous affichons une notification afin que les utilisateurs soient prévenus de cette conversion.

    PDF

    L'option d'exportation « Calques en tant que pages » fonctionne maintenant même s'il y a un seul groupe de calques. Auparavant, cette option n'était pas disponible car le greffon vérifiait seulement s'il y avait plus d'un « calque » sans examiner s'il s'agissait d'un groupe de calques avec de multiples sous-calques.

    PNG

    Les fragments de fichiers PNG qui sont « copiables sans risque » (« safe-to-copy chunks ») sont maintenant préservés lors de l'importation et inclus dans l'image exportée. Un autre souci qui existait lors de l'exportation de PNGs indexés avec transparence (et qui nous avait été souvent signalé) a été résolu. Désormais les couleurs indexées devraient être affichées correctement après exportation.

    PSD

    Jacob Boerema a poursuivi son travail d'amélioration du greffon PSD. En plus d'avoir résolu des bogues, par exemple dans l'ordre des calques lors de l'importation, il a aussi clarifié l'avertissement présenté lors de l'exportation et concernant la compatibilité des modes de calques entre GIMP et Photoshop.

    PSP

    Le greffon Paintshop Pro peut maintenant importer davantage de caractéristiques depuis un fichier projet, comme par exemple le profil de couleurs ICC, les guides, les grilles, et la sélection active lors de la sauvegarde. Les failles de sécurité ZDI-CAN-22096 et ZDI-CAN-22097 ont également été corrigées dans cette version.

    Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2

    Nous avons récemment ajouté la prise en charge de l'importation et de l'exportation pour le format Farbfeld, un format d'image sRVB conçu pour être facile à lire, à envoyer dans des pipes et à compresser avec des outils tiers.

    Nous avons aussi ajouté la prise en charge de l'importation seule pour les nouveaux formats suivants :

    • Esm Software PIX : Un format JPEG modifié utilisé exclusivement par l'entreprise Esm Software pour stocker leurs images propres. Cela a été implementé en réponse à un signalement de bogue qui avait confondu ce format avec le format Alias PIX que nous prenions déjà en charge.
    • HEJ2 : Un ajout à notre greffon HEIF déjà existant fourni par Daniel Novomeský qui permet d'importer des images JPEG 2000 compressées.

    Nouveau format de palette pris en charge : Swatchbooker

    Swatchbooker est un programme libre de création et de conversion de palettes de couleurs qui prend en charge de nombreux formats. Bien que le programme lui-même n'ait pas été mis à jour depuis de nombreuses années, son format de palette propre .sbz est le plus complet de tous ceux que nous prenons en charge actuellement. Parmi ses nombreuses fonctionnalités, on peut citer la possibilité de définir des couleurs dans plusieurs modèles de couleurs pour chaque entrée d'une palette, des noms et des descriptions régionalisables, et la prise en charge de profils de couleurs ICC différents pour chaque entrée.

    Via notre travail sur la prise en charge de son importation, nous avons pu fournir des informations qui ont conduit à un correctif de bogue dans la prise en charge de Swatchbooker par Krita. C'est toujours sympa quand des projets peuvent collaborer et s'entraider !

    Interactions avec les pads de tablettes graphiques sous Wayland

    Carlos Garnacho, un contributeur GNOME de longue date, a ajouté la prise en charge de l'interaction directe des boutons de tablettes graphiques (pad) avec GIMP. Quand une tablette est branchée, vous pouvez désormais assigner différentes actions aux contrôles de la tablette depuis la boîte de dialogue « Périphériques d'entrée » dans le menu Édition.

    Assigner des actions aux boutons d'une tablette graphique
    Assigner des actions aux boutons d'une tablette graphique - GIMP 2.99.18

    Ce travail a aussi impliqué le portage de fonctionnalités vers GTK 3, la boîte à outils utilisée par GIMP pour son interface graphique. Notez que cette fonctionnalité est seulement disponible sous Wayland pour le moment.

    Mise à jour de l'API

    L'interface de programmation d'application (API), destinée aux créateurs de greffons, est régulièrement retravaillée dans le cadre de la refonte de GIMP 3. Une partie de ce travail est de migrer l'API vers l'utilisation de GeglColor lorsque les couleurs sont impliquées, ce qui entre dans le cadre plus général du projet Space Invasion. Malgré tout, ce n’est qu’une petite partie de l’ensemble des améliorations de l’API.

    Nous nous orientons également vers plus de classes pour représenter les différentes ressources gérées par GIMP (pinceaux, polices, motifs, etc.) au lieu de les représenter uniquement par des noms (ce qui était une limitation historique alors qu'il est tout à fait possible à 2 créateurs de ressources de choisir le même nom et le fait est que nous voyons de tels cas dans la nature — par exemple, 2 polices créées indépendamment peuvent avoir le même nom).

    Un autre grand pas consiste à remplacer le GimpValueArray représentant les arguments ordonnés d'une procédure d'un greffon par un GimpProcedureConfig qui contient les arguments par nom plutôt que par ordre. Cela permet une utilisation beaucoup plus sémantique des procédures de greffon (surtout lorsqu'elles ont une longue liste d'arguments) et facilitera également l'amélioration des greffons à l'avenir, avec des arguments nouveaux ou réorganisés sans créer de nouvelles procédures, car l'ordre et le nombre des arguments comptent beaucoup moins. Cela signifie que l'ajout de nouveaux arguments dans le futur ne brisera plus les scripts déjà existants qui dépendaient des versions antérieures de ces greffons (les auteurs de greffons devront toujours choisir des valeurs par défaut appropriées pour les nouveaux arguments afin que cela soit vrai, bien sûr).

    En parallèle, nous continuons d'améliorer la capacité de création automatique d'interfaces graphiques offerte aux greffons, rendant la création de boîtes de dialogue plus simple que jamais. Cela inclut (parmi de nombreuses autres améliorations) un nouveau type d'argument de procédure nommé GimpChoice qui est une liste de choix sous forme de chaînes de caractères qui peut être présentée aux créateurs sous forme de widgets de liste déroulante dans la boîte de dialogue de votre greffon.

    Nous prévoyons d'écrire et de publier un didacticiel pour les rédacteurs de greffons dans la section Développement de ressources de notre site Web pour développeur en même temps que la sortie de GIMP 3, ou peu de temps après.

    GEGL et babl

    Cette version de GIMP est accompagnée de nouvelles versions de GEGL et babl, qui contribuent toutes deux au projet (Color) Space Invasion.

    babl 0.1.108 apporte une nouvelle fonction babl_space_is_rgb pour nous aider à confirmer directement qu'un espace colorimétrique est RVB (plutôt que de faire plusieurs tests pour voir s'il n'est pas CMJN ou niveaux de gris). Plusieurs améliorations ont également été apportées au processus de compilation et à l'outil d'interface de ligne de commande de babl.

    GEGL 0.4.48 fournit plusieurs mises à jour de l'objet GeglColor qui prend désormais en charge une grande partie des opérations de couleur de GIMP. Les améliorations spécifiques incluent la possibilité d'obtenir et de définir directement les valeurs de couleur CMJN, ainsi que l'attribution de l'espace colorimétrique lors de la définition des couleurs RVB(A).

    Un crash dans le filtre gegl:voroni existant a été corrigé, et un bogue de longue date avec le filtre gegl:dropshadow qui empêchait l'effet de rétrécir a également été corrigé.

    Enfin, un nouveau filtre gegl:shuffle-search a été ajouté à l'atelier. Il mélange les pixels voisins pour créer un effet de tramage plus optimisé.

    Statistiques de sortie

    Hormis la première version de la série (2.99.2), GIMP 2.99.18 est clairement la plus grosse mise à jour à bien des égards. Depuis la version 2.99.16 :

    • 238 rapports ont été clôturés comme CORRIGÉS.
    • 201 demandes de fusion ont été acceptées.
    • 1358 commits ont été poussés.
    • 26 traductions ont été mises à jour : allemand, basque, biélorusse, portugais brésilien, bulgare, catalan, chinois (Chine), danois, espagnol, espéranto, finnois, géorgien, grec, hongrois, islandais, italien, lituanien, norvégien nynorsk, persan, polonais, russe , slovène, suédois, turc, ukrainien, vietnamien.

    60 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.99.18 (l'ordre est déterminé par le nombre de commits; certaines personnes apparaissent dans plusieurs groupes) :

    • 23 développeurs pour le code principal : Jehan, Alx Sa, Shubham, Jacob Boerema, Idriss Fekir, bootchk, Anders Jonsson, Carlos Garnacho, mr.fantastic, Stanislav Grinkov, lillolollo, Øyvind Kolås, Sabri Ünal, programmer_ceds, Lukas Oberhuber, programmer-ceds, James Golden, Luca Bacci, Massimo Valentini, Niels De Graef, Zander Brown, psykose, sonia.
    • 17 développeurs de greffons ou de modules : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Stayd, Zander Brown, Bruno Lopes, Daniel Novomeský, Sabri Ünal, programmer_ceds, Kamil Burda, Mark, Michael Schumacher, Stanislav Grinkov, programmer-ceds, sonia.
    • 31 traducteurs : Yuri Chornoivan, Martin, Ekaterine Papava, Luming Zh, Sabri Ünal, Anders Jonsson, Rodrigo Lledó, Jordi Mas, Alan Mortensen, Vasil Pupkin, Asier Sarasua Garmendia, Kolbjørn Stuestøl, Boyuan Yang, Víttor Paulo Vieira da Costa, dimspingos, Alexander Shopov, Alexandre Prokoudine, Aurimas Černius, Balázs Úr, Marco Ciampa, Sveinn í Felli, Danial Behzadi, Ngọc Quân Trần, Jürgen Benvenuti, Piotr Drąg, Timo Jyrinki, Andre Klapper, Kristjan SCHMIDT, MohammadSaleh Kamyab, Rafael Fontenelle, Tim Sabsch.
    • 9 créateurs de ressources (icônes, thèmes, curseurs, splash screen, métadonnées…) : Alx Sa, Jehan, Ferry Jérémie, Stanislav Grinkov, Anders Jonsson, Bruno Lopes, Jacob Boerema, Sabri Ünal, mr.fantastic.
    • 5 contributeurs à la documentation : Jehan, Bruno Lopes, Jacob Boerema, Alx Sa, Anders Jonsson.
    • 14 contributeurs pour la compilation, l'empaquetage ou l'intégration continue : Jehan, Bruno Lopes, bootchk, Alx Sa, Zander Brown, Jacob Boerema, Jacob Boerema, Stayd, Carlos Garnacho, Heiko Becker, mr.fantastic, Daniel Novomeský, U-YGGDRASIL\ender, lillolollo.

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

    • babl 0.1.108 est composé de 17 commits par 6 contributeurs : Jehan, Øyvind Kolås, John Marshall, Andre Klapper, John, sid.
    • GEGL 0.4.48 est composé de 77 commits par 20 contributeurs : Øyvind Kolås, Jehan, Anders Jonsson, Jacob Boerema, Yuri Chornoivan, Alan Mortensen, Sabri Ünal, Andre Klapper, Ekaterine Papava, Jan Tojnar, Jordi Mas, Luming Zh, Martin , Piotr Drąg, Víttor Paulo Vieira da Costa, Asier Sarasua Garmendia, Marco Ciampa, Rodrigo Lledó, dimspingos, woob.
    • ctx a eu 308 commits depuis la version 2.99.14 par 1 contributeur : Øyvind Kolås.
    • La version gimp-macos-build (scripts d'empaquetage macOS) est composée de 32 commits par 1 contributeur : Lukas Oberhuber.
    • La version flatpak est composée de 15 commits par 3 contributeurs : Jehan, Daniel Novomeský et Hubert Figuière.
    • Notre site Web principal a eu 31 commits depuis la sortie du 2.10.36 par 6 contributeurs : Jehan, Alx Sa, Sabri Ünal, Anders Jonsson, Bruno Lopes, Jonathan Demeyer.
    • Notre site Web des développeurs a eu 30 commits depuis la version 2.10.36 par 5 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Robin Swift.
    • Notre documentation 3.0 a enregistré 247 commits depuis la version 2.99.16 par 17 contributeurs : Andre Klapper, Jacob Boerema, Yuri Chornoivan, Alx Sa, Jordi Mas, Alan Mortensen, Dimspingos, Anders Jonsson, Boyuan Yang, Sabri Ünal, Víttor Paulo Vieira da Costa, Juliano de Souza Camargo, Rodrigo Lledó, Kolbjørn Stuestøl, Marco Ciampa, Danial Behzadi, Emin Tufan Çetin.

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

    Remarque : compte tenu du nombre de pièces qui composent GIMP et son environnement, et de la manière dont nous obtenons des statistiques via des scripts git, des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous dire si nous avons manqué ou mal catégorisé certains contributeurs ou contributions.

    Nouvelles de l'équipe et procédure de sortie

    Les droits d'accès au dépôt git ont été récemment accordés à Bruno Lopes (qui a été très actif dans l'amélioration de notre processus de compilation et de l'empaquetage pour Windows).

    Plusieurs développeurs ou empaqueteurs de longue date ou plus récents qui ont commencé à contribuer au nouveau site Web des développeurs ont également reçu l'accès au dépôt git associé.

    De plus en plus de contributeurs participent désormais activement aux tests des versions et du processus d'empaquetage, et c'est la première dépêche depuis des années (NDT : cela désigne la news originale sur le site de GIMP) que Jehan n'a pas écrite presque entièrement ! Merci beaucoup à Alx Sa (alias Nikc ou CmykStudent) d'avoir entamé la rédaction collaborative de la nouvelle !

    Il est clair que nous consolidons jour après jour une solide équipe de contributeurs et cela se voit dans notre processus de publication, avec de plus en plus de retours à chaque version.

    Nous sommes également particulièrement heureux et fiers que les 4 projets GSoC que nous avons eus, depuis que nous avons recommencé à souscrire à ce programme de mentorat, aient tous été couronnés de succès et ont fini par être fusionnés avec la branche principale du code au plus tard six mois après la fin du stage.

    Autour de GIMP

    Des nouvelles des miroirs

    Depuis la dernière dépêche, un nouveau miroir a été apporté à GIMP par :

    • Sahil Dhiman, à Nuremberg, en Allemagne, comme projet personnel.

    Cela nous amène à un total de 46 miroirs répartis dans le monde.

    Les miroirs sont importants car ils aident le projet en partageant la charge de dizaines de milliers de téléchargements quotidiens. De plus, en disposant de miroirs répartis à travers le monde, nous garantissons que tout le monde puisse avoir un accès rapide au téléchargement de GIMP.

    GIMP sous Windows/ARM

    Depuis notre annonce d'une version expérimentale sur Windows pour l'architecture ARM 64 bits (en anglais), nous avons reçu l'aide de Hernan Martinez, contributeur bien connu du projet MSYS2, qui a hébergé notre tout premier runner pour l'intégration continue (CI) pour Windows sur l'architecture Aarch64. Bien que cela n'ait été qu'une configuration temporaire (littéralement une machine de compilation dans le salon de quelqu'un) en attendant une situation plus stable, nous sommes extrêmement reconnaissants envers Hernan qui nous a aidés à faire notre deuxième pas sur cette plateforme (la première étape a été effectuée par Jernej, qui a créé notre premier installateur expérimental), s'est assuré que notre processus de compilation automatique fonctionne sur cette machine, et plus encore.

    Depuis lors, la situation plus stable est arrivée : Arm Ltd. eux-mêmes se sont mobilisés et ont officiellement contribué trois runners pour notre processus d'intégration continue dans Gitlab ! Arm Ltd. a également sponsorisé un kit de développement Windows pour l'un de nos développeurs.

    Bien que nous considérions toujours cette version comme expérimentale, en raison du manque de tests et du fait que seuls 2 contributeurs disposent actuellement d'une machine capable de l'exécuter, le plus gros facteur bloquant a été supprimé et nous sommes heureux d'annoncer que notre programme d'installation Windows universel pour GIMP 2.99.18 contient GIMP pour les 3 plates-formes (x86 32 et 64 bits, et maintenant ARM 64 bits) !

    Télécharger GIMP 2.99.18

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

    • Flatpaks Linux pour x86 et ARM (64 bits)
    • Installateur Windows universel pour x86 (32 et 64 bits) et pour 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 des distributions Linux ou *BSD, etc.).

    Et ensuite ?

    Alors que nous sommes maintenant entrés dans un gel des fonctionnalités, notre attention s'est déplacée vers la correction des bogues, le nettoyage et la préparation de la première version candidate 3.0.

    Nous pensons en effet qu'il s'agit de la dernière version de développement puisqu'aucune nouvelle fonctionnalité ne sera introduite désormais, du moins au niveau de l'interface utilisateur (l'API est encore en évolution jusqu'à la première version candidate). Donc, ce que vous voyez maintenant est essentiellement ce que vous devriez obtenir dans GIMP 3.0.0, en termes de fonctionnalités.

    C'est pourquoi nous avons sorti cette version même si nous savons qu'elle est assez instable. C'est l'heure des commentaires de dernière minute ! C'est aussi le moment de signaler et de corriger les bogues comme si demain n'existait pas. Nous espérons pouvoir bientôt livrer une RC1 et elle devrait être aussi dépourvue de bogue que possible.

    Nous espérons actuellement pouvoir publier GIMP pour le prochain Libre Graphics Meeting du 9 au 12 mai. Pour être honnête, ce n’est pas un objectif facile et nous ne sommes donc pas sûrs de pouvoir l’atteindre. Ce qui est sûr, c'est que même si nous n'y parvenons pas à temps, cela ne devrait pas arriver trop longtemps après. En particulier, nous ne publierons pas simplement parce que nous avons fixé une date limite. Nous voulons offrir la meilleure expérience possible, ce qui signifie que si nous découvrons des bogues bloquants de dernière minute, nous retarderons la sortie jusqu'à ce qu'ils soient corrigés.

    N'oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, c'est un moyen de donner en retour et d'accélérer le développement de GIMP. L’engagement communautaire permet au projet de se renforcer ! 💪🥳

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    ❌
    ❌