Une nouvelle année démarre, mais en 2025, nous continuons sur notre lancée de récompenser celles et ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logo, journaux, correctifs, etc.). Vous n’êtes pas sans risquer de gagner un livre des éditions Eyrolles, ENI et D-Booker. Voici les derniers gagnants de 2024 avant d'attaquer la promotion 2025 :

• vmagnin, pour sa dépêche « Des nouvelles de Fortran n°6 - décembre 2024 » ;
• karchnu, pour sa dépêche « Netlibre, un service libre et un nom de domaine gratuit » ;
• sbillois, pour sa dépêche « Deno 2.0 est là » ;
• gnoucat2, pour sa dépêche « Tuxemon Tower 0 : sortie de la première version ! ».

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

Les livres 📚 sélectionnés

• Synthèse d'images avec OpenGL (ES) ;
• Programmation shell sous Unix/Linux — ksh, bash, norme POSIX (avec exercices corrigés) — 7^e édition ;

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

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

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

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

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

Sommaire

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

Corrections de bugs importantes

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

Migration des paramètres de la 2.10

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

Console Windows

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

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

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

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

Intégration de darktable

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

Améliorations

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

API de filtre GEGL

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

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

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

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

Espaces de fusion de calques et composition dans les fichiers XCF

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

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

Paquets

AppImage

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

Flatpak

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

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

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

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

Améliorations du greffon BMP

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

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

Mises à jour diverses

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

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

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

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

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

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

Aperçu des changements depuis la version 2.10

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

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

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

GEGL

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

Statistiques de sortie

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

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

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

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

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

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

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

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

Autour de GIMP

Miroirs de téléchargement

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

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

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

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

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

Changements dans les miroirs

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

• Sahil Dhiman, Mumbai, Inde

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

Financer des exécuteurs ("runner") GitLab

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

Télécharger GIMP 3.0 RC2

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

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

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

🛈 Notes:

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

Et ensuite ?

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

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

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

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

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du dernier mois de 2024.

• « De GCC à Clang en passant par Firefox » par serge_sans_paille ;
• « Quelques nouvelles à propos du serveur de vidéconférence Galène » par jch ;
• « J'ai créé une visualisation et une description interactive d'iptables » par zersh ;
• « Personnaliser sa montre GPS Garmin avec le SDK Connect IQ » par Funix ;
• « Quelques notes de lecture » par Ysabeau 🧶 ;
• « Un câble USB qui permet de pirater un ordinateur. » par Walter5 ;
• « Framasoft €$ : Souhaitons leur un Joyeux Anniversaire et Joyeux Noël » par Apichat ;
• « Debian 13 (Trixie) : à quand le gel ? » par Eridor ;
• « Diffusion audio multicanal avec bluetooth » par Funix ;
• « Sortie de Bim! en version 3 pour les fêtes » par Julien Jorge.

Une dépêche de 2008 introduisait TuxFamily.org ainsi : « Présent sur Internet depuis 1999, TuxFamily.org fournit gratuitement des services d’hébergement pour tous les projets sous licence libre et permet ainsi la promotion du libre sous toutes ses formes (art libre, logiciel libre, etc.). »

Récemment, nous évoquions un incident DNS chez TuxFamily.org avec perte de nos deux DNS (entre le 9 décembre 2024 vers 23h ou minuit, et le 10 décembre 08:38) et un besoin de bascule de DNS pour revenir en ligne. Sur le site de TuxFamily, la page des nouvelles ne remonte depuis 2019 que des incidents. Alors un utilisateur a fini par poser poliment la question (en anglais) « Est-ce que TuxFamily est en train de mourir lentement ? », car il y a eu de nombreux incidents, dont certains non mentionnés dans les nouvelles et qu’il y a des soucis d’accès à cause de bibliothèques de crypto trop anciennes laissés sans réponse. Est-ce un problème de motivation, un creux temporaire, comment aider ?

Et la réponse est arrivée, remerciant le demandeur de l’avoir posée : oui TuxFamily.org se meurt, oui la motivation est partie, tout est devenu vieux : les gens, les machines, les centres de données, l’architecture des services. TuxFamily.org ne serait plus pertinent techniquement et les efforts pour juste le maintenir ne sont plus suffisants. Et encore plus clairement dit : la vérité est que les meilleures choses à faire sont : 1. migrer votre projet hors de TuxFamily.org (…) 2. parlez-en, ici ou en dehors de TuxFamily.org, pour que les autres projets restants aient une liste de suggestions d’hébergeurs.

Concernant LinuxFr.org: la gestion du DNS ne sera pas remise sur TuxFamily.org (voir l’entrée de suivi). Nous tenons à remercier TuxFamily.org et les personnes derrière pour les services rendus pendant des années. Et nous arrêtons à regret de vanter cet hébergeur : il n’est plus listé dans les projets amis dans notre bas de page et la bannière affichée en rotation a été retirée.

TuxFamily.org utilise comme solution technique VHFFS (la dernière version présentée sur LinuxFr.org est la 4.4 et la dernière version parue est la 4.6 en octobre 2016).

Souvenirs

• Problèmes chez TuxFamily (2002)
• L'avenir de Tux Family est en jeu (2004)
• L'hébergeur TuxFamily appelle les adeptes du libre à soutenir leur initiative (2008)
• TuxFamily.org lance sa campagne de dons 2011

TuxFamily.org est par exemple l'hébergeur de Kaos Fantasy, et était celui de Lent Ciné, et de bien d'autres projets. C'est aussi l'hébergeur de nombreuses listes de diffusion.

Nota bene : c'est loin d'être une première, beaucoup d'autres forges logicielles ont fermé et d'outils de forges ont disparu, comme Berlios.de, Google Code, Gitorious, Alioth (Debian), Betavine, CodeHaus, CodePlex, Fedora Hosted, Gna!, java.net, Phabricator, Tigris, Mozdev, LibreSource, Codendi, InDefero, CodingTeam, Django-Simple-Forge, Anvil, etc. (liste tirée de Wikipédia et de la dépêche « Forges logicielles et hébergement de projets libres »). On a d'ailleurs vu des migrations de Sourceforge à TuxFamily.org par exemple.

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

• Jona, pour sa dépêche « GIMP 3.0 RC1 est sorti » ;
• Axone, pour sa dépêche « FreeCAD 1.0 » ;
• Adrien Bourmault, pour sa dépêche « Lettre d'information XMPP de septembre 2024 » et les précédentes ;
• fcartegnie, pour son journal « Quand le phishing se joue des serveurs DNS ».

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

Les livres 📚 sélectionnés

• Rust - Développez des programmes robustes et sécurisés ;
• Python, Raspberry Pi et Flask — Capturez des données télémétriques et réalisez des tableaux de bord web — 2^e édition ;
• Traitement d'images et de vidéos avec OpenCV 4 en Python (Windows, Linux, Raspberry).

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

🎄 Joyeux Noël 🎁

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du mois de novembre passé.

• « Quand le phishing se joue des serveurs DNS » par fcartegnie ;
• « Thunderbird pour mobile » par Jean-Baptiste Faure ;
• « Peter Saville et le nouvel ordre informatique » par vmagnin ;
• « PERA: vote sur les Brevets Logiciels au Sénat US » par Benjamin Henrion ;
• « MIDI 2.0 : Trouver MIDI à quatorze heures » par Enzo Bricolo 🛠⚙🛠 ;
• « Démarchage robotisé » par 🚲 Tanguy Ortolo ;
• « Flow » par TBTB ;
• « Gestion domestique de l'énergie: OpenHEMS » par abriotde ;
• « TapTempo en Slint » par Gof ;
• « Souriez, vous êtes filmé » par Funix.

La conférence ConFoo est de retour pour sa 23e édition, du 26 au 28 février 2025 à l’Hôtel Bonaventure de Montréal !

Avec plus de 190 présentations offertes par une centaine d’experts de partout à travers le monde, venez découvrir pourquoi Confoo est devenu l’un des événements phares pour les développeurs en Amérique du Nord et de partout à travers le monde.

Notre programmation officielle est d’ailleurs disponible dès maintenant sur notre site web! Consultez nos toutes nouvelles présentations axées sur le développement FullStack OpenSource, l’intelligence artificielle, le devops et plus encore. Organisé au cœur d’un environnement spécialement conçu pour les développeurs, ConFoo est aussi l’endroit parfait pour rencontrer de potentiels employeurs et réseauter avec les meilleurs de l’industrie.

Réservez vos billets dès maintenant et profitez d’un rabais de 175$ sur votre inscription jusqu’au 13 décembre !

Faites partie de l’aventure et découvrez comment l’intelligence humaine façonne le milieu des hautes technologies!

La quatrième édition d'Open Source Experience (ou OSXP2024 pour les intimes) arrive à grand pas les 4 et 5 décembre prochains au Palais des Congrès de Paris. C'est un événement désormais rituel qui propose à la fois :

• une centaine de conférences avec 125 conférenciers, dont le programme est en ligne et détaillé dans la suite de la dépêche ;
• une partie exposition avec 90 exposants, dont un village associatif un peu réduit cette année (sept stands)

Et LinuxFr.org répond présent comme d’habitude depuis de nombreuses années. Vous pourrez donc nous y retrouver, stand A02 (tout en bas à droite sur le plan). Une partie de l’équipe du site LinuxFr.org sera présente au sein du village associatif pour vous faire découvrir le site, discuter, répondre à toutes les questions que vous pourriez vous poser, vous donner des autocollants du site et vous faire gagner des kilos de livres, mais pas que (lisez plus bas, on renouvelle comme chaque année).

Ce sera aussi l’occasion de se retrouver en chair et en os pour celles et ceux qui pourront faire le déplacement et au vu du programme toujours très dense, on vous incite vraiment à venir y faire un tour.

Sommaire

• • Programme des conférences
    • Thématiques
    • Temps forts
  • Village associatif
    • Les associations présentes
  • Mais que vient faire LinuxFr.org à Open Source Experience ?
  • « L'AssoLution »
  • Des cadeaux en pagaille
  • Informations pratiques

Programme des conférences

Le programme de cette 4^e édition d'Open Source Experience a été publié par les organisateurs. Plus d'une centaine de conférences, tables rondes, workshops à l'affiche, autour de trois thématiques qui veulent mettre en avant les enjeux et bénéfices de l'open source pour les organisations avec des cas d’utilisation concrets, le tout autour de cinq thématiques.

Thématiques

• IA, Machine Learning & Data ;
• Cloud, Infra & IoT ;
• Cybersécurité ;
• Solutions d'entreprise ;
• Business et enjeux.

Temps forts

En marge des conférences vous retrouverez plusieurs événements dans l'événement :

• L'AssoLution, le temps fort associatif
• Le concours des Acteurs du Libre dont nous avons remporté le prix du numérique ouvert et éthique en 2019
• Les trophées Territoire Numérique Libre

Vous pourrez également assister à plusieurs animations : podcasts, jeux, concerts,…

Découvrez le programme complet sur le site de OSXP !

Village associatif

Les associations présentes

Comme chaque année, un village associatif sera présent, mais il sera plus réduit cette année, suite à une réduction de l'espace exposition. Seront présents en plus de LinuxFr.org : Adullact, April, Framasoft, Libervia, MozFr, La Mouette, les Mongueurs de Perl, VLC et Wikimedia France.

Mais que vient faire LinuxFr.org à Open Source Experience ?

Nous serons en A02, exilés au bout du village des associations lui même dans le coin du salon, au plus loin des conférences et de l'espace VIP. Ferait-on trop de bruit avec notre mégaphone ? Une partie de l’équipe sera présente pour :

• rencontrer les personnes contributrices et notre lectorat ;
• expliquer le principe de LinuxFr.org aux personnes qui ne connaissent pas (encore) (bien) le site ;
• inciter notre lectorat à contribuer : nous avons pu constater que certaines personnes ne se sentaient pas — à tort, le plus souvent – le niveau pour passer la modération (il y a les journaux aussi) et surtout affronter la communauté de LinuxFr.org, qui peut être très exigeante ;
• vous faire gagner des livres (nous nous sommes encore démenés pour vous ! Merci aux éditions D-Booker, Eyrolles et ENI pour les dons) ;
• vous donner (oui, on est comme ça, on donne) des autocollants LinuxFr.org inspirés de nos logos passés ou actuels (encore un énorme merci à nos amis de Grafik plus pour les impressions à un tarif proprement indécent) ;
• parader avec nos nouveaux polos plus responsables ;
• participer à quelques-unes des 100 conférences décrites plus haut
• Et surtout animer avec Bookynette, la présidente de l'April, l'AssoLution, le temps fort associatif !

Merci à tous ceux qui passeront nous saluer mercredi et jeudi sur le stand B10, nous vous attendons de pied ferme. Nous allons tenter de relayer les nouvelles de l’événement via notre compte X @linuxfrorg et/ou BlueSky, en attendant un compte-rendu plus formel post-salon.

« L'AssoLution »

Après Section d’Assos , l’Assaut de Bien Fêteurs et la Zone Associative Déjantée, OSXP propose cette année L'AssoLution, l’absolution à la dissolution ! Comme chaque année, LinuxFr.org fait l’animation des associations, réunissant geeks, décideurs et lutins pour un moment festif et détendu. La partie musicale sera gérée par KPTN (aka Clément Oudot) de Worteks. Un bon moment festif en perspective. ! Et nous avons encore vu les choses en grand pour s’assurer de votre présence, moins de rébarbatif et plus de fun. Au menu :

• Discours d’absolution aux codeurs propriétaires repentis
• Après nos 25 ans l'année passée, Framasoft viendra nous faire un rapide bilan de ses 20 ans cette année (. Toujours une bonne occasion de célébrer !
• Notre Quiz sympatico-ludique façon Burger Quizz avec plein de cadeaux et de goodies à remporter grâce à nos sympathiques mécènes (voir plus loin).
• Vu que cela se déroule pendant la pause méridienne, nos amis des Fondations AlmaLinux OS, Eclipse et Open Source Initiative fourniront les cupcakes (une fois n'est pas coutume) !

📅 Jeudi 5 décembre 2024
⏰ 12h30
🗺️ Salle Laurent Séguin

Des cadeaux en pagaille

C’est pas tout ça, mais on sait que vous venez aussi nous voir pour les cadeaux et les tirages au sort quotidien pour repartir avec votre dose de connaissance, mais aussi de joie et de bonne humeur !

L'année dernière, nous avions eu pas mal de succès avec notre Fairphone et nos Lego. On remet donc ça, mais pour les remporter, il faudra se distinguer au quiz pour tenter de remporter :

• un Fairphone 5 vert (de chez Murena avec /e/OS dessus) ;
• un casque audio Fairbuds XL vert ;
• un kit de démarrage Raspberry Pi 5 ;
• le jeu de société "Les Aventuriers du Rail : Légendes de l’Ouest" ;
• une boîte de Lego architecture Notre-Dame de Paris vu qu'elle va rouvrir sous peu !
• et des abonnements à la bibliothèque numérique des éditions ENI (en plus des livres, voir plus loin).

Nous en profitons pour remercier les sociétés Passbolt et AdmanTIC qui ont financé ces cadeaux.

Il y aura aussi plus de 25 de livres à gagner parmi 22 références de nos partenaires habituels : les éditions ENI, les éditions Eyrolles et désormais les éditions D-Booker.

Soyez présent, on remet en jeu tout lot non réclamé sur place ! Et nous aurons des lots de consolation.

Informations pratiques

Concrètement, pour nous rejoindre sur place

• Adresse : Palais des Congrès – 2 Place de la Porte Maillot – 75017 Paris
• Stand LinuxFr.org : A02
• Dates : mercredi 4 et jeudi 5 décembre 2024
• Horaires d’ouverture : de 9h00 à 18h00
• Accès transport en commun
  • Métro Ligne 1, Station Porte Maillot – sortie 3.
  • RER Ligne C, Station Neuilly – Porte Maillot.
  • BUS Lignes 43, 73, 82, 244 PC

FreeCAD est sorti le 18 novembre 2024 en version 1.0 (voir l'annonce officielle et sa vidéo associée). Cette sortie est marquée par une amélioration majeure : l'atténuation du problème de dénomination topologique.

Sommaire

• Qu'est-ce que FreeCAD ?
• Historique
• Le problème de dénomination topologique
• Les autres améliorations
  • Un outil d'assemblage par défaut avec solveur dynamique
  • L'atelier sketcher amélioré
  • Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC
  • L'atelier FEM
  • Le reste
• L'essai commercial d'Ondsel

La dernière dépêche sur FreeCAD remonte à avril 2021 pour la sortie de la version 0.19. Depuis, il y a eu les versions 0.20 (juin 2022) et 0.21 (août 2023). Cette version 1.0 a porté le nom de 0.22 pendant son développement.

Qu'est-ce que FreeCAD ?

Extrait de wiki.freecad.org :
FreeCAD est un modeleur paramétrique de CAO 3D open source sous licence LGPL. FreeCAD est destiné à l'ingénierie mécanique et à la conception de produits mais — étant très générique — il s'adapte également à une gamme plus large d'utilisations autour de l'ingénierie, telles que l'architecture, l'analyse par éléments finis, l'impression 3D et d'autres tâches.

FreeCAD propose des outils similaires à CATIA, SolidWorks, Solid Edge ou Revit et entre donc également dans la catégorie CAO, GCVP, CFAO, IAO et BIM. Il s'agit d'un modélisateur paramétrique basé sur les caractéristiques d'une architecture logicielle modulaire qui permet de fournir des fonctionnalités supplémentaires sans modifier le système de base.

FreeCAD est aussi multiplateforme. Il fonctionne sous Windows, Linux/Unix et macOS avec la même apparence et les mêmes fonctionnalités sous toutes les plateformes.

Historique

La toute première version de FreeCAD est sortie en 2002. FreeCAD est développé en C++, Qt et Python et son cœur repose sur les bibliothèques OpenCASCADE (ou OCCT) spécialisées dans la CAO.

Son développement est assuré par un large panel de contributeurs : certains sont historiques, d'autres sont spécialisés sur un aspect particulier et beaucoup sont plus ou moins occasionnels.

Les versions se sont enchaînées à un rythme quasi annuel, apportant moult améliorations et fonctionnalités nouvelles.

En 2021, quelques contributeurs historiques fondent la FreeCAD Project Association (FPA) qui est un organisme indépendant à but non lucratif pour collecter des dons et apporter un soutien au développement du projet.
Ce soutien passe notamment par leur programme "FreeCAD Grant Program", qui permet d'embaucher ou de récompenser des personnes pour des projets spécifiques. Ce programme a un budget de 50k$ pour l'année 2024. A titre d'exemple récent, 500$ ont été octroyés pour une étude sur les runners CI de Github, 1000$ pour un gros travail de correction de bugs, et enfin 500$ pour la création d'une vidéo sur les nouvelles fonctionnalités de cette version 1.0.

FreeCAD bénéficie d'une communauté impliquée permettant notamment d'avoir une documentation complète, à jour et traduite dans de nombreuses langues.

Le problème de dénomination topologique

C'était un des points noirs de FreeCAD jusqu'à cette version 1.0.
Il faut imaginer que dans ce logiciel, la modélisation d'une pièce (dans le sens objet physique) passe par une suite d'opérations mathématiques et géométriques en définissant à chaque fois des contraintes ou des paramètres. Une opération est par exemple la création d'un trou borgne de 5 mm sur telle face à 10 mm des bords haut et gauche. Un autre exemple est d'ajouter une « languette » sur telle face cylindrique. Ou bien d'ajouter un chanfrein de 2 mm sur telle arête, etc.

Ainsi, petit à petit, la pièce modélisée se construit, prend forme, se détaille et se complexifie.

Cet historique de ces opérations successives est toujours présent et modifiable. À tout moment, il est possible de modifier une des étapes intermédiaires.

D'un point de vue technique, vous aurez sans doute compris que chaque opération s'applique à un élément précis et existant de la pièce à ce moment-là (une face ou une arête par exemple). Dans FreeCAD ces éléments ont tous un identifiant unique (Face6, Edge9, etc.), continu et incrémental. Si l'objet a 13 faces à une des étapes, les faces seront numérotées de Face1 à Face13. Chaque opération est rattachée à l'identifiant de l'élément (Face5 par exemple).

Et le problème se situe à ce niveau : lors d'une modification d'une étape intermédiaire, il arrive souvent que cela change la géométrie globale de la pièce et donc que les nombres de faces ou d'arêtes augmentent ou diminuent. Et FreeCAD réattribue alors ces identifiants uniques aux différents éléments.
Ainsi, si l'objet passe de 13 à 11 faces, c'est l'ensemble des faces qui vont recevoir un nouvel identifiant dans la plage Face1 à Face11, avec un très fort risque qu'une face, pourtant non touchée par la modification, porte un identifiant différent.

Et vous voyez le problème arriver : si une des opérations suivantes dans l'historique était de faire un perçage sur la Face6 qui est maintenant devenue la Face3… Toute la modélisation part en vrille.

Ce problème de dénomination topologique est documenté sur le wiki de FreeCAD : problème de dénomination topologique.

Pour éviter cela, il était conseillé de suivre un ensemble de bonnes pratiques de modélisation sous FreeCAD : Édition de fonctions. Il faudra certainement suivre l'évolution de cette page avec cette sortie.

Cette version 1.0 marque donc l'intégration de codes correctifs de cette problématique. Les notes de version indiquent tout de même que tout n'est pas résolu, et qu'il y aura d'autres améliorations dans les prochaines versions. Cette petite vidéo en anglais vous montre la différence de comportement entre la version 0.21 et 0.22dev (qui a servi de base à la 1.0).

Les autres améliorations

Un outil d'assemblage par défaut avec solveur dynamique

Le terme assemblage désigne la fonctionnalité de regrouper plusieurs éléments afin d'obtenir un objet fonctionnel. Ce peut être, par exemple, une boîte constituée d'un couvercle sur charnières maintenues par des vis avec des rangements amovibles à l'intérieur. Ou bien un moteur thermique avec ses carters, vilebrequin, bielles, pistons, soupapes, etc. Il est parfois utile de pouvoir fournir des indications de positionnement et/ou de liberté des éléments entre eux, et de pouvoir animer le tout.
Ces opérations d'assemblage n'étaient pas intégrées dans FreeCAD avant la version 1.0. Elles étaient néanmoins possibles grâce aux ateliers. Plusieurs ont été créés pour cela avec chacun leurs spécificités et leurs approches mais aussi une incompatibilité entre eux : A2plus, Assembly3 ou Assembly4.
Cette version 1.0 propose un nouvel atelier mais intégré par défaut. Il a été mis au point par la société Ondsel (voir plus bas). Il est encore jeune, et il est encore trop tôt pour savoir s'il finira par s'imposer par rapport à l'existant déjà en place. Un tutoriel concernant l'atelier d'assemblage est d'ores et déjà disponible pour une introduction à cette nouvelle fonctionnalité de la v1.0.

L'atelier sketcher amélioré

Cet atelier permet de dessiner les esquisses techniques utilisées dans la conception mécanique. C'est dans celui-ci que sont dessinés les « plans 2D » avec les cotes et les contraintes dimensionnelles et spatiales. Cette version apporte un nombre conséquent d'améliorations et de nouvelles fonctionnalités rendant son utilisation plus facile, plus puissante et plus rapide. Le mieux est de regarder les notes de version animées.

Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC

Si le titre est cryptique, c'est que l'on parle de BTP et d'outils destinés aux équipes de Maîtrise d'Œuvre impliquées dans la conception d'une opération construction (Architectes, Bureaux d'Études). Comme ce n'est pas forcément le lot commun des visiteurs de LinuxFr.org, résumons la situation:

• L'atelier Arch, pour Architecture, exploite depuis longtemps les capacités de création 3D de FreeCAD pour dessiner facilement, fondations, murs, planchers, fenêtres, portes etc. Cet atelier se basait sur le format natif des fichiers FreeCAD, *.FcStd.

• Dans l'atelier BIM (pour Building Information Model <= l'article Wikipedia_FR est bien écrit pour qui veut comprendre l'essentiel), on retrouve un certain nombre d'outils de dessin et de création d'objets qui s'avèrent redondants pour certains avec ceux de l'outil Arch tout en implémentant les paradigmes bien plus vastes qu'induit l'approche BIM d'un projet de construction <=> pas uniquement de la géométrie, mais aussi du prix, des données mécaniques, physiques, des fiches produit, du planning …

• L'approche BIM tend à se généraliser dès lors que la complexité et le coût du projet le justifient. Elle repose (en théorie) sur un format d'échange IFC (pour Industry Foundation Class).
  Il est ouvert et au format texte.
  Oui avec vim, c'est possible de bidouiller ;)
  mais un fichier IFC fait rapidement quelques centaines de Mo voire quelques Go …

L'Association "Building Smart" en définit les caractéristiques. Tous les logiciels sur le marché savent ouvrir et exporter dans ce format, à la norme IFC 2.3 ad minima et IFC 4.2 voire 4.3 pour les up to date.

L'atelier BIM de FreeCAD utilisait jusqu'à présent IfcOpenShell, une application tierce Open Source pour convertir un fichier du format *.ifc vers du *.FcStd en passant (sans doute) par du OpenScad dans le processus.

Une image qui devrait parler au LinuxFrien (!) pour la classe IFC Material-Constituent-Set,

Pour la version 1.0 de FreeCAD, Yorik Van Havre, développeur historique de FreeCAD, (par ailleurs, architecte et Président la FreeCAD Project Association) a entrepris de fusionner ces deux ateliers, d'en faire une fonctionnalité native de FreeCAD, c'est-à-dire qui se passe du vaillant IfcOpenShell (grâce notamment au travail fait sur Blender-Bim) pour que FreeCAD puisse ouvrir et enregistrer directement au format IFC sans conversion inutile.

L'atelier FEM

Cet atelier d'analyse par éléments finis comporte également des améliorations considérées comme majeures avec cette version 1.0, détaillées dans un article de blog sur l'atelier FEM de FreeCAD.

Les avancées majeures sont liées à la prise en charge de fonctionnalités de CalculiX, un des solveurs utilisés par cet atelier : symétrie cyclique, analyses 2D et contraintes de corps rigide.

Le reste

Comme à chaque nouvelle version, beaucoup de choses ont été apportées, que ce soit dans l'interface, ou dans la plupart des ateliers intégrés. Les notes de version de la v1.0, comme très souvent détaillées en images, permettent de voir l'évolution de ce logiciel.

FreeCAD a également annoncé son nouveau logo, choisi après un appel à concourir auprès de la communauté (lien). Le logo en SVG est disponible sur cette page.

L'essai commercial d'Ondsel

Outre la création en 2021 de l'association FPA (voir plus haut), d'autres développeurs, notamment Brad Collette, mainteneur de longue date de l'atelier Path et auteur de deux livres sur FreeCAD, ont créé début 2023 la société américaine ONDSEL sous la forme d'une Public Benefit Corporation (PBC) qui pourrait se traduire par « une entreprise d'intérêt pour la société ». Malheureusement, après environ 2 ans, Brad Collette informe de l'arrêt de la société ONDSEL, faute d'avoir trouvé un marché.

La société voulait s'appuyer sur FreeCAD pour « apporter des fonctionnalités commerciales qui rendent FreeCAD plus utile aux utilisateurs commerciaux ». (Source)

Pour cela, ONDSEL a produit sa propre version de FreeCAD avec ses propres choix esthétiques et ergonomiques, et a fourni un cloud pour simplifier le travail en équipe et le partage.
À noter qu'ONDSEL indiquait soumettre ses améliorations à FreeCAD pour intégration et que son cloud était disponible sous forme de module dans FreeCAD. Ces améliorations se retrouvent dans cette version 1.0 de FreeCAD, notamment le nouvel outil intégré d'assemblage ainsi que les très nombreuses nouvelles fonctionnalités de l'atelier Sketcher.

La société ONDSEL avait détaillé sa relation avec le projet FreeCAD indiquant notamment leur mode de collaboration. Ils avaient également un blog en anglais intéressant, où ils abordent plusieurs thématiques, notamment sur l'évolution de CATIA ou bien la liste des nouveautés agrémentée de nombreuses animations.

Dans l'annonce de cet arrêt, Brad Collette revient également sur ce qu'ils ont apporté au projet FreeCAD. Tout ce qu'ils ont développé était en open source et déjà intégré pour la plupart à FreeCAD. Les fondateurs d'ONDSEL continueront de contribuer au projet directement.

Vous le savez sûrement, les éditions ENI font partie des partenaires de LinuxFr.org qui permettent de motiver et récompenser chaque mois les meilleurs contributeurs du site (accompagnés en cela par les éditions Eyrolles et D-Booker). D’ailleurs, chacun de ces éditeurs a déjà mis en place des solutions d’accès numérique à ses livres et/ou revues, que ce soient des livres électroniques au format EPUB, HTML, PDF ou des bases documentaires accessibles en ligne sous forme d’abonnement, ce qui est le cas d’ENI.

Ce type de solution a ses avantages et ses défauts, ses aficionados et ses détracteurs, mais pour vous faire une idée et afin de mieux faire connaître leur bibliothèque numérique, les éditions ENI la mettent en libre accès pendant deux jours les 22 et 23 novembre prochains.

Vous aurez accès à l’ensemble de leur catalogue de livres, vidéos, articles, etc. Comme il y en a pour tous les goûts (ou presque), vous devriez trouver votre bonheur, même si vous êtes contre votre gré aux prises avec un système d’exploitation propriétaire ;-) On rappelle que parmi les auteurs, certains sont des lecteurs ou contributeurs de LinuxFr.org, comme Sébastien Rohaut, par exemple. Ce qui fait que leur catalogue ne manque pas d’ouvrages sur les technologies libres et open source, que ce soit, en vrac, sur :

• GNU/Linux, principalement Debian, Ubuntu et Red Hat ;
• les langages de programmation : Python, Rust, Java, C, C++, Javascript, etc.
• ou encore tous les sujets du moment, qu’ils soient techniques (Cloud, AI, Data, Sécurité) ou non (RGPD, gestion d’entreprises, marketing, etc.)
• mais aussi du classique avec les environnements LAMP et les SGC / CMS qui tournent dessus : WordPress, Joomla, Drupal, etc. les bases de données relationnelles (MySQL, PostgreSQL, etc.) ;

Bref, vous avez deux jours (dont un sur le week-end) pour vous faire une idée sur le fond de leurs ouvrages, la forme de la bibliothèque numérique, voire choisir votre récompense pour votre prochaine contribution sur LinuxFr.org !

• Capture d’écran d’une recherche du terme Linux
  

• Extrait d’un ouvrage (Expressions régulières — Syntaxe et mise en œuvre (avec exercices et corrigés) (2^e édition))
  

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

• Ysabeau, pour ses dépêches « La conquête de l’espace : une affaire féminine, première partie du NACA à la NASA »  et « La conquête de l’espace : une affaire féminine, deuxième partie les missions Apollo » 
• Benoît Sibaud, pour sa dépêche « img, le cache d’images sur LinuxFr.org » ;
• pieq, pour son journal « Helix, une excellente alternative à vim ! » ;
• dourouc05, pour sa dépêche « Sortie de LyX 2.4 ».

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

Les livres 📚 sélectionnés

• L’intelligence artificielle expliquée — Des concepts de base aux applications avancées de l’IA ;
• Rust – Développez des programmes robustes et sécurisés — Développez des programmes robustes et sécurisés ;
• Pygame — Initiez-vous au développement de jeux vidéo en Python — 2^e édition.

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

La conférence 2024 de l'APELL avait rassemblé l'été dernier à Berlin des acteurs clés du logiciel libre et des décideurs politiques pour échanger sur l'avenir des politiques open source en Europe. Les discussions ont abordé, notamment, les thèmes de la souveraineté numérique, du renforcement de la collaboration entre les pays et de l'adoption de politiques publiques favorisant le logiciel libre. Un compte-rendu détaillé de la conférence (PDF, 33 pages) est à présent disponible.

Les participants ont formulé ou rappelé de nombreuses propositions concrètes pour promouvoir et dynamiser la filière européenne de l'open source. Les participants ont notamment débattu d'initiatives visant à harmoniser les politiques publiques, à soutenir la formation, à plus communiquer sur les réussites. Le rôle central de l'APELL, en tant que voix unifiée de l'open source professionnel en Europe, a été souligné, ainsi que l'importance de créer et de promouvoir standards ouverts et de développer des partenariats transfrontaliers. In fine, les participants ont appelé à une mobilisation collective pour ancrer l'open source au cœur de la stratégie numérique européenne, garantissant résilience et innovation sur le continent.

Sommaire

• Renforcer la souveraineté numérique par l'open source
• Cinq idées fortes
• Initiatives et propositions concrètes
• Redéfinir le message autour du logiciel libre
• La voie à suivre : une mobilisation collective

La conférence APELL 2024 a été l'occasion de discuter des enjeux stratégiques et d'élaborer des propositions concrètes visant à renforcer l'open source en Europe.

Renforcer la souveraineté numérique par l'open source

Les discussions ont mis en avant l'importance de dépasser les simples questions de conformité légale pour intégrer la souveraineté numérique dans la culture et la pratique des institutions européennes. Le logiciel libre a été reconnu comme un levier essentiel pour garantir la liberté de choix et l'innovation technologique. Les participants ont proposé que l'Union européenne fixe l'objectif ambitieux de ne financer que des solutions open source dans l'administration publique à l'horizon 2035. Cette idée repose sur un engagement à long terme soutenu par des financements ciblés et des stratégies de mise en œuvre durable.

Cinq idées fortes

Cinq points clés ont particulièrement marqué les débats et témoignent de la portée des discussions :

1. Le passage à l'open source pour la souveraineté numérique : Le consensus parmi les participants était clair : adopter et promouvoir les logiciels libres est une étape stratégique incontournable pour que l'Europe atteigne une véritable souveraineté numérique. Dans un monde où les dépendances technologiques peuvent fragiliser des économies entières, l'open source offre un moyen de regagner du contrôle sur les infrastructures numériques.
2. L'importance des logiciels libres dans les produits et services technologiques innovants : Les logiciels open source ne se limitent pas à représenter des alternatives à des solutions dominant le marché, mais sont présents dans 96 % des bases de code actuelles, selon les experts présents. Ils sont essentiels pour soutenir l'innovation dans des domaines aussi divers que le cloud, l'IoT, l'intelligence artificielle et l'analyse des données massives (big data). Selon Manuel Hoffman, économiste à la Harvard Business School, qui est intervenu pendant la conférence, sans les logiciels libres, les entreprises auraient besoin de tripler leurs dépenses en logiciels (cf. Hoffmann, Manuel, Frank Nagle, and Yanuo Zhou. "The Value of Open Source Software." Harvard Business School Working Paper, No. 24-038, January 2024.). Ce constat met en évidence le caractère irremplaçable des logiciels libres dans le développement technologique et économique.
3. Les standards ouverts et le projet Sovereign Cloud Stack : Le projet Sovereign Cloud Stack (SCS) a été cité en exemple pour illustrer la manière dont les standards ouverts peuvent servir de fondement à la souveraineté numérique. SCS combine les principes de liberté de choix, d'innovation, de conformité et de concurrence, permettant aux utilisateurs de ne pas être enfermés dans un écosystème unique. Cette approche favorise une plus grande résilience et réduit les coûts de transition entre solutions.
4. Renforcer la coopération transfrontalière : Un autre point crucial a été l'appel à intensifier les efforts de collaboration entre les pays européens. En unissant leurs forces et en coordonnant leurs efforts, ceux-ci peuvent sensibiliser davantage les décideurs à l'importance stratégique de l'open source et orienter les investissements publics et privés vers des initiatives qui soutiennent cet écosystème. Cette collaboration est essentielle pour maintenir la compétitivité de l'Europe face aux géants mondiaux de la technologie (e.g. les GAFAM).
5. Le rôle central de l'APELL : En tant qu'association européenne des entreprises de logiciel libre, l'APELL a réaffirmé son engagement à défendre et à promouvoir des politiques qui soutiennent l'écosystème open source. L'association se positionne comme une voix unifiée pour représenter les intérêts de la filière du logiciel libre à l'échelle européenne, encourageant des actions politiques cohérentes et des initiatives qui renforcent l'innovation collective.

Initiatives et propositions concrètes

Plusieurs propositions et recommandations ont émergé des ateliers et des discussions :

1. Harmonisation des politiques "Public Money, Public Code" : Inspirées des cadres législatifs existants en France et en Italie, les recommandations du groupe de travail appellent à une harmonisation de ces principes à l'échelle européenne, accompagnée de financements pour des programmes de formation et des études d'impact sur l'adoption de l'open source.
2. Développement des compétences et formations : Pour répondre au manque de main-d'œuvre qualifiée, les participants ont suggéré la création de partenariats entre les universités et l'industrie pour développer et standardiser les enseignements spécifiques au logiciel libre, et des travaux de fin d'études axés sur des contributions aux projets open source. Le financement de formations spécialisées dans des domaines stratégiques tels que la cybersécurité a également été discuté.
3. Collaboration transfrontalière : Afin de renforcer l'écosystème open source, l'APELL a été invitée à encourager la création d'associations professionnelles nationales là où elles manquent, comme en Pologne et en République tchèque, ou encore d'aider à la relance d'une association en Espagne. L'objectif est de créer un réseau européen plus intégré capable de partager ressources et meilleures pratiques, et de peser au niveau des institutions de l'Union.
4. Promotion de la transparence et de la confiance : Les participants ont recommandé de créer des outils et des campagnes de sensibilisation pour promouvoir la transparence et la fiabilité des solutions open source, particulièrement dans les secteurs réglementés tels que la finance et la santé.
5. Réglementation et standards ouverts : La conférence a plaidé pour l'élaboration de nouvelles régulations favorisant l'interopérabilité et les standards ouverts, en s'appuyant sur des cadres tels que le cadre européen d'interopérabilité (EIF). L’adoption de solutions modulaires, permettant une flexibilité accrue et des coûts de migration réduits, a été recommandée pour soutenir la transformation numérique des administrations publiques de manière durable et pérenne. Ces réglementations devraient également inclure une obligation pour les administrations publiques de privilégier des solutions open source lorsque celles-ci répondent aux besoins. Toutefois, l’expérience en France et en Italie montre qu’un cadre légal ne suffit pas à lui seul à provoquer un changement durable. Pour que cette adoption soit efficace, un soutien actif à la mise en œuvre est essentiel, qui doit être l'objet de plan cohérents.
6. Soutien aux initiatives de "proof of concept" : Pour surmonter les réticences des administrations, l'encouragement à financer des projets pilotes démontrant la valeur des solutions open source a été recommandé par les participants, afin de prouver l'efficacité et les avantages à long terme de ces solutions.

Redéfinir le message autour du logiciel libre

Un des thèmes centraux abordés lors de la conférence a été l’importance de choisir le bon message pour promouvoir l’open source. Les participants ont débattu de l’efficacité de mettre en avant la "mitigation des risques" – un argument souvent utilisé pour justifier l’adoption des logiciels libres, en particulier auprès des administrations publiques. Bien que pertinent, cet argument reste dans un "espace de problème" plutôt que de présenter l’open source comme un outil "d’opportunités et d'innovation". Pour une communication plus impactante, les experts ont proposé de recentrer le discours sur le potentiel de l’open source à favoriser l'innovation et la collaboration.

L'open source ne se limite pas à réduire les risques; il constitue aussi une source de croissance et de compétitivité. Par exemple, dans l'industrie automobile, où l’interopérabilité entre divers sous-systèmes est cruciale, l'open source permet aux grandes entreprises et à leurs nombreux sous-traitants de collaborer plus efficacement et de garantir la compatibilité de leurs systèmes. Les développeurs, en travaillant dans un écosystème open source, peuvent ainsi obtenir des résultats plus rapidement que s'ils travaillaient de manière isolée sur des solutions propriétaires.

La voie à suivre : une mobilisation collective

La conférence s'est conclue par un appel à l'action pour une mobilisation collective et proactive afin de garantir que le logiciel libre devienne durablement un pilier de la politique numérique européenne. La mise en place de prix et de trophées européens pour célébrer les réussites open source (ex: Acteurs du Libre en France ou les EU Open Source Awards), la publication régulière d'études pour attirer l'attention des médias (cf. les publications du CNLL ou celles de l'OSBA, etc.), et l'organisation d'événements dédiés ont été identifiés comme des moyens de stimuler l'intérêt et l'engagement.

La conférence APELL 2025 aura vraisemblablement lieu à Varsovie au début de l'été 2025 et sera l'occasion de faire le bilan des actions en cours, au niveau des institutions européennes comme des États membres.

Dans l’objectif, certes légitime, de lutter contre la fraude à la TVA via des logiciels de caisse, l’Assemblée a voté la fin du dispositif d’« attestation individuelle » qui permettait à un éditeur ou un intégrateur de solution, d’attester de la conformité de son système. L’Assemblée impose ainsi une procédure lourde et onéreuse de certification, qui impacterait tout particulièrement les logiciels libres.

Afin d’alerter sur ce risque important pour les écosystèmes des logiciels libres intégrant des fonctionnalités de caisse, l'April a publié un communiqué, où elle revient plus en détails sur le contexte et les enjeux, et où elle appelle à se mobiliser en vue des travaux à venir au Sénat : « Qui veut la peau des logiciels libres de caisse ? »

Supprimer la possibilité de « l’attestation individuelle » revient à soumettre toute activité économique autour des logiciels de caisse, libres ou non, à une très importante pression financière et réglementaire, et à imposer une responsabilité contractuelle auprès de l’organisme certifiant.

L’amendement adopté à l’Assemblée témoigne malheureusement à nouveau d’un manque de compréhension de comment fonctionnent les différents modèles de développement logiciel, notamment libre.

L’April ne manquera pas de contacter les sénateurs et sénatrices pour les informer de la situation et les inviter à rétablir l'article 286 3° bis du Code général des impôts dans sa rédaction initiale. L’April appelle également toutes les personnes concernées — développeurs et développeuses, utilisatrices et utilisateurs, entreprises, associations ou fondations en charge d’un projet de logiciel libre de caisse — à faire de même.

Si le sujet vous intéresse, n’hésitez pas aussi à rejoindre notre liste publique dédiée à ce sujet pour partager vos interrogations, vos réflexions et arguments, et participer à cette mobilisation.

Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers (Debian, MariaDB, Redis - version d’avant le changement de licence, nginx, Postfix, conteneurs LXC et Docker, Ruby On Rails, Sympa, etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img, la tribune board, le convertisseur EPUB 3 epub, le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg. Cette dépêche va s’intéresser à epub, un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le convertisseur EPUB3 à la volée de LinuxFr.org, et elle vient accompagner la précédente sur img, le cache d’images sur LinuxFr.org.

Sommaire

• Des EPUB de vos contenus et commentaires
• Côté code Ruby on Rails
• Côté epub
• Historique
• Évolutions récentes
  • Dockerfile
  • La suite de tests
• Les problématiques restantes
• Conclusion ?

Des EPUB de vos contenus et commentaires

LinuxFr.org vous permet de lire les contenus et commentaires du site, au format EPUB3, par exemple dans votre liseuse préférée. Il y a une exception à cela, les liens, parce que certes ça ferait des EPUB tout mignons, mais surtout petits voire un poil inutiles. Le lien EPUB est présent automatiquement sur chaque contenu (hormis les liens donc).

Le principe est simple : on donne un lien vers un contenu HTML à epub, il le demande à la partie Ruby on Rails du site, ainsi que les images associées, convertit le tout au format EPUB3 et le renvoie à la personne qui l’a demandé. Techniquement epub n'est pas exposé frontalement mais se trouve derrière un nginx.

Côté code Ruby on Rails

C’est assez basique : on ajoute juste sur chaque contenu un lien pour télécharger au format EPUB. Ainsi, y compris sur cette dépêche, vous allez trouver un lien à la fin pour récupérer le tout au format EPUB (et un autre pour récupérer le source en Markdown mais c’est un autre sujet).

app/views/news/_news.atom.builder:    epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
app/views/polls/_poll.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
app/views/posts/_post.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
app/views/nodes/_actions.html.haml:    = link_to "EPUB", "#{path_for_content node.content}.epub", title: "Télécharger ce contenu au format EPUB", class: "action download"
app/views/diaries/_diary.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
app/views/wiki_pages/_wiki_page.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))

Côté epub

Le service est plutôt simple, par rapport à img, car il n’a pas de dépendance sur redis par exemple, et qu’il a, au final, peu de paramétrage (un couple adresse+port d’écoute, un fichier de trace et un hôte pour aller chercher les contenus).

Il est possible de faire un GET /status et on obtient une réponse HTTP 200 avec un contenu OK. C’est utile pour tester que le service est lancé (depuis l’intérieur de la plateforme).

Sinon on lui demande une dépêche, un journal, une entrée de forum, un sondage, une entrée de suivi ou une page wiki en prenant le chemin sur LinuxFr.org et ajoutant un petit .epub à la fin, et il va renvoyer un fichier EPUB. Ou bien il va répondre un contenu non trouvé HTTP 404 s’il y a un souci. Et vu son fonctionnement, si on a un souci de HTML non valide ou si img a un problème avec une image, alors derrière epub pourrait avoir le même souci.

epub est un binaire dynamique en Go. Il impose le https pour l’hôte (du coup on aura tous les liens en HTTPS en interne normalement). Il ne peut pas vraiment être compilé statiquement (on a besoin de libxml2, libonig2 et de la même version de la libc au déploiement). Il ne gère pas les images in-line.

Dans les logs on va trouver des infos comme :

2024/11/03 16:34:02 Status code of http:/example.invalid/exemple.png is: 404
(…)
2024/11/03 16:38:23 Fetch https://linuxfr.org/news/capitole-du-libre-2024-au-programme-du-16-et-17-novembre
2024/11/03 16:38:24 Fetch https://linuxfr.org/users/liberf0rce/journaux/libreast-2006-is-out-of-order

Historique

epub a été créé par Bruno Michel en 2013 et Bruno est le seul à travailler dessus (48 commits) jusqu’en 2018. Comme img, on peut considérer que epub a fait le job pendant ce temps-là, sans besoin de retouche.

Mon premier commit de 2021 concerne la gestion d’un cas de collision de nommages des images.

En 2022, Bruno quitte l’équipe du site, et par ailleurs il y a des montées de versions et des migrations à faire sur les serveurs de LinuxFr.org, et epub fait partie des services à reprendre en main. Ce qui veut dire le comprendre, le documenter et au besoin l’améliorer.

Bref je décide de me plonger dans epub (2022-2024), dans la foulée de img, car a priori ce n’est pas un composant compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer - divulgâchage en fait non pas seulement).

Le choix est le même que pour img (cf la dépêche précédente) : ajouter un Dockerfile permettant de recompiler epub dans un conteneur, en contrôlant la version de Go utilisée, en effectuant une détection d’éventuelles vulnérabilités au passage avec govulncheck. Cela me permet de valider que l’on sait produire le binaire d’une part, et que l’on offre à tout le monde la possibilité de contribuer facilement sur ce composant. Et de découvrir qu’une version statique n’est pas facilement envisageable.

Puis je vais tester le composant pour vérifier qu’il fonctionne comme je le pense et qu’il fait ce qu’on attend de lui. Je vais ajouter une suite des tests qui couvrent les différentes fonctionnalités et les vérifient en IPv4 et en IPv6, en HTTP 1.1 et en HTTP 2.0. Les tests utilisent Hurl et docker-compose, et encore une fois l’idée de donner la possibilité de contribuer facilement. Ils comprennent des tests de types de contenus non pris en charge, le test de la limite à 5 MiB, différents types de contenus, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). Et surtout de vérifier avec epubcheck que le fichier epub produit est correct. Le choix des cas de tests est basé sur le trafic réellement constaté sur le serveur de production, sur les différents cas dans le code et un peu sur l’expérience du testeur.

Les différents travaux effectués vont permettre de détecter et corriger quelques soucis :

• le besoin de pouvoir choisir l’hôte (histoire de ne pas toujours tester sur la production)
• mieux gérer certaines erreurs comme les réponses inattendues
• corriger les zip sans extension unix, le logo en couverture
• documenter les cas pouvant être mieux gérer : image trop grande, non récupérable, format inconnu, etc. en fournissant les tests en attendant la correction

Et à la fin, j’écris une dépêche pour parler de tout cela.

Évolutions récentes

Dockerfile

Le fichier Dockerfile du projet permet :

• de partir d’une image officielle Go d’une version donnée, basée sur une distribution Debian (en raison des dépendances)
• de l’utiliser pendant la construction en prenant la liste des dépendances de compilation, en les téléchargeant, en prenant l’unique fichier source epub.go et en le compilant dynamiquement avec l’option pour retirer les chemins de compilation
• de rechercher les éventuelles vulnérabilités avec govulncheck
• de tester avec golangci/golangci-lint le code (fait à la construction de l’image, car on dispose de toutes les dépendances à ce moment-là)
• de repartir d’une base Debian en y mettant les autorités de certification, les dépendances de fonctionnement et le binaire issus de la partie construction, de déclarer le port d’écoute et de lancer le binaire avec des variables disposant de valeurs par défaut.

La suite de tests

Pour l’utiliser, c’est assez simple, il faut aller dans le répertoire tests et lancer un docker-compose up --build, qui va produire le conteneur contenant epub, et démarrer le nginx-cert qui fournit les certificats et le nginx préconfiguré pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

linuxfr.org-epub-test_1  | All tests look good!
tests_linuxfr.org-epub-test_1 exited with code 0

Rentrons un peu dans les détails.

D’abord un fichier docker-compose.yaml qui décrit le réseau IPv4/IPv6 utilisé pour les tests, l’image nginx-cert qui sera utilisée pour créer une autorité de certification et un certificat serveur de test, l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image epub et son paramétrage (dont l’accès au nginx) ainsi que le répertoire de l’autorité de certification de tests et enfin l’image de la suite de tests qui est construit avec son Dockerfile et son répertoire de dépôt des fichiers EPUB.

Le Dockerfile de tests est basé sur une image Hurl (un outil pour faire des tests HTTP). On ajoute les fichiers de tests en .hurl, le script shell qui pilote le tout, on prévoit d’avoir les paquets dont on aura besoin : bash (pas par défaut dans les Alpine), curl, openjdk17 (pour epubcheck), openssl, unzip (transitoirement), bind-tools et shellcheck. On installe epubcheck. Et on lance les tests par défaut.

La configuration nginx de test écoute en HTTP sur le port 80 en IPV4 et IPv6 et permet de définir des chemins avec des réponses en HTTP 301, 302, 308, 400, 401, 403, etc. jusqu’à 530 et même 666 pour les codes invalides, ainsi qu’une redirection infinie.

Dans les données de tests servies par nginx, on trouve des contenus du mauvais type, des contenus dans divers formats, une image très grande et des images qui ne seront pas accessibles.

Sont aussi présents deux fichiers de tests avec une extension en .hurl :

• le test de vie et les chemins hors des contenus autorisés
• les tests sur les contenus

Vient enfin le script shell qui pilote le tout :

• on définit les variables pour les cibles IPv4/IPv6 que l’on veut utiliser dans les autres conteneurs Docker
• on purge le stockage des EPUB sur disque
• on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
• sur chaque EPUB produit, on lance epubcheck et on regarde si la validation donne le résultat attendu (succès ou échec)
• si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

Les problématiques restantes

Il y a quelques entrées encore ouvertes dans le suivi :

• les images trop grandes (en octet), non récupérables, de format inconnu, etc. : la suite de tests actuelle « couvre » le cas des images de plus de 5 MiB ou non récupérables, avec des tests qui échouent, comme prévu, vu que c’est img qui est censé faire le job de les éviter. Cependant il pourrait être sympa de remplacer toute image non disponible/invalide par une image de remplacement « Image indisponible » du bon Content-Type et du bon nom (vu qu’elle est déclarée dans le MANIFEST).
• les images trop grandes (en pixel) : globalement on revient à la question des images que laisse passer img
• les epub non fonctionnels en rédaction et modération : pour des questions de droits, la génération EPUB ne marche pas dans les espaces de rédaction et de modération, à voir si on trouve un contournement ou si on évite de proposer le lien.

Il y a la question habituelle de la montée de versions des dépendances (pour nous actuellement contraintes celles du code Ruby on Rails). Et des questions à se poser sur l’avenir de nginx ?. Les dépendances pendant le fonctionnement amènent aussi leur lot de contraintes.

Conclusion ?

Encore une fois, sans surprise et me répétant, il reste des problématiques et du code à faire pour les gérer (c’est rare un composant sans demandes d’évolution ou de correction). Yapuka (mais probablement plus tard, il faut aussi partager le temps avec les autres composants, ou avoir plus de contributions).

epub rend la fonction que l’on attend de lui, même si on pourrait faire un peu mieux. Plonger dans ce composant s’est avéré assez intéressant et formateur (et nécessaire) : techniquement cela a été l’occasion de faire du Go, du docker et du docker-compose, du nginx, du hurl, de l’HTTP et de gérer des problématiques statique/dynamique et des dépendances. Il s’agissait encore de comprendre ce que faisait un code écrit par une autre personne, de se poser des questions pour choisir les tests et le contenu de la documentation, de se demander pour quelles raisons tel ou tel choix a été fait, de rendre ce composant plus « contribuable », et de compléter le tout de façon détaillée avec une dépêche.

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

En quelques mots

Le Capitole du Libre, c'est:

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

Présentation

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

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

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

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

Keynotes

Deux moments sont proposés pour cette édition:

• une intervention de Jean-Baptiste Kempf à 14h le samedi
• une table ronde sur les modèles de gouvernance des projets libres à 18h30 le samedi

Ateliers

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

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

Village associatif

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

Install party

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

Boutique

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

LAN party

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

Cocktail

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

MiniDebConf

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

Pour plus d'information sur la MiniDebConf…

Informations pratiques

Restauration

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

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

Entrée

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

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

Les portes seront ouvertes:

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

Nous vous attendons nombreux !

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

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

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

Bonne écoute !

Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers (Debian, MariaDB, Redis - version d’avant le changement de licence, nginx, Postfix, conteneurs LXC et Docker, Ruby On Rails, Sympa, etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img, la tribune board, le convertisseur EPUB 3 epub, le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg. Cette dépêche va s’intéresser à img, un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le cache d’images de LinuxFr.org, complétée d’une demande d’un « article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… ».

Sommaire

• Des images sur le site
• Buts du cache d’images
• À l’utilisation
• Côté code Ruby on Rails
• Côté img
• Historique
• Évolutions récentes
  • Dockerfile
  • La suite de tests
  • L’audit interne
• Le grand nettoyage
• Les problématiques restantes
• Conclusion ?

Des images sur le site

LinuxFr.org vous permet d’utiliser des images externes dans les contenus et commentaires du site. Ces images sont incluses en syntaxe markdown avec ![description textuelle](adresse "titre optionnel") (soit en saisissant directement du Markdown, soit en cliquant sur l’icône d’ajout d’image dans l’éditeur). Profitons-en pour rappeler que pour utiliser une image sur LinuxFr.org, vous devez vous assurer de respecter sa licence.

Nous vous encourageons donc à utiliser des images sous licence libre et à citer les auteurs (c’est même obligatoire pour les licences CC-by et CC-by-sa). Cette citation est tirée de la dépêche d’annonce Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org de 2012.

Il est aussi recommandé de mettre une vraie description textuelle, qui finira dans l’attribut alt de la balise img utilisée pour l’accessibilité ou si l’image ne peut être chargée. Il peut être utile de lui donner un titre qui apparaîtra l’autre du survol de l’image à la souris par exemple.

Exemple :

![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png "L’actualité du logiciel libre et des sujets voisins (DIY, Open Hardware, Open Data, les Communs, etc.), sur un site francophone contributif géré par une équipe bénévole par et pour des libristes enthousiastes.")

Buts du cache d’images

Les raisons évoquées à la mise en place de img (sans ordre particulier) :

• la sécurité : si une image externe n’est servie qu’en HTTP (en clair donc) et est appelée au milieu d’une page LinuxFr.org elle-même servie en HTTPS, alors le navigateur va râler sur le mélange des genres. img permet de servir toutes les images identiquement (par exemple en HTTPS, et avec le certificat de LinuxFr.org, via le serveur frontal devant img). À noter que ces images ne sont pas servies directement depuis le domaine principal linuxfr.org mais depuis un sous-domaine img.linuxfr.org pour éviter que le JavaScript embarqué dans les images en SVG puisse servir de vecteur d’attaque contre le site.
• la protection de la vie privée des personnes visitant LinuxFr.org : seul LinuxFr.org voit les informations en provenance de leur navigateur (dont l’adresse IP). Les équipes d’administration des différents sites ne les voient plus (elles voient l’adresse IP du serveur LinuxFr.org).
• une meilleure gestion du trafic : au lieu d’envoyer tout notre public chercher individuellement chaque image, LinuxFr.org la récupère une fois et la rend disponible. Si le site externe fournissant l’image est un serveur à faibles ressources (liaison ADSL avec faible débit montant par exemple), la mise en cache permet de garantir qu’il ne recevra qu’un faible volume de requêtes (la récupération se faisant initialement toutes les 10 min tant que des demandes arrivent, le cache expirant après 10 min).
• la conservation des images : les images incluses depuis des sites externes peuvent ne plus être disponibles (l’entité a disparu, le serveur a été arrêté, le domaine a été perdu, l’adresse a changé, etc.). Nous avons donc un mécanisme de cache pour que nous puissions continuer à servir une image même si elle devient indisponible.

Parmi les conséquences de cette implémentation initiale, on peut citer :

• si le fichier est changé sur le serveur distant (modifié, converti dans un autre format), l’ancien fichier est servi jusqu’à la prochaine récupération et le nouveau fichier ne sera servi qu’à la prochaine récupération ;
• si le fichier est supprimé sur le serveur distant, l’image ne sera plus servie après la prochaine récupération (car le serveur a répondu que l’image n’existe plus) ;
• il est possible de modifier l’image au passage : les images d’avatar sont retaillées pour une hauteur de 64 pixels par exemple ;
• il est possible de bloquer des images : les images problématiques (pub/spam, contenus pour adultes, images injurieuses, etc.) peuvent être bloquées et ne plus être servies ;
• par ailleurs img n’accepte de servir que les images connues de LinuxFr.org dont le poids fait moins de 5 MiB.

À l’utilisation

Lors de l’écriture d’un commentaire ou d’un contenu sur LinuxFr.org, une personne va ajouter une image externe via la syntaxe Markdown, par exemple ![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png)

Ce qui donne à l’affichage :

Et côté code HTML :

<img src="https://linuxfr.org/images/logos/linuxfr2_classic_back.png" alt="Logo LinuxFr.org">

OK, mauvais exemple ce n’est pas une image externe, puisqu’elle est hébergée sur LinuxFr.org justement. Prenons un autre exemple ![April - Campagne d’adhésion](https://april.org/campagne-2024/relais/banniereCampagneApril.svg).

Ce qui donne à l’affichage :

Et côté code :

<img src="//img.linuxfr.org/img/68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667/banniereCampagneApril.svg" alt="April - Campagne d’adhésion" title="Source : https://april.org/campagne-2024/relais/banniereCampagneApril.svg">

Donc on sert l’image via le sous-domaine img.linuxfr.org. On peut aussi noter le titre rempli automatiquement avec la source. Expliquons la nouvelle adresse :

• // on sert en https si la page est en https et en http si la page est en http (c’est plutôt un oubli qu’autre chose, vu que le site est uniquement en https)
• img.linuxfr.org on sert depuis un sous-domaine du site
• 68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667 est la version en texte-vers-hexadécimal de l’adresse d’origine (68 pour h, 74 pour t (deux fois), 70 pour p, etc.). Il existe des sites et des outils en local pour faire cette conversion, mais cela ne concerne pas la simple utilisation du site.
• banniereCampagneApril.svg on met à la fin le nom du fichier pour être sympa si vous voulez sauver l’image en local avec un nom plus explicite

Ceci était le cas où tout se passe bien, comme prévu, comme le voulait la personne qui voulait utiliser une image externe.

Voyons maintenant ce qui se passe dans le cas pas si rare où la personne a donné une adresse d’image invalide, une adresse ne pointant pas vers une image vers autre chose (cas extrêmement fréquent), une image trop grosse (plus de 5 MiB), etc. Il se passe la même chose côté code, mais côté affichage, pas d’image, et on voit seulement le texte alternatif dans son navigateur. Dans les coulisses, img a répondu 404, cette adresse n’est pas disponible.

On note donc qu’une même image servie en http:// ou en https:// aura une adresse convertie en hexadécimal différente, donc sera vue comme une autre image par img. Même chose si le serveur externe accepte des adresses sans tenir compte de la casse, ou si on rajoute des paramètres dans l’adresse comme « ?mot_magique=merci ».

Côté code Ruby on Rails

Un contenu ou commentaire est en cours de création et une image externe a été mentionnée. Le code de gestion des images va vérifier que l’image est déclarée dans redis (créer l’entrée img/<adresse> avec adresse l’adresse de l’image en clair, ajouter un champ created_at avec l’horodatage, ajouter l’adresse dans la liste des dernières images img/latest) et renvoyer l’adresse via img.

Le code peut aussi modifier le champ status d’une image dans redis pour mettre ou enlever un blocage (valeur Blocked) par l’équipe du site, et l’ajouter/enlever de la liste des images bloquées img/blocked.

Côté img

Les schémas dans la documentation du service img explicitent les possibilités et les comportements.

Il est possible de faire un GET /status et on obtient une réponse HTTP 200 avec un contenu OK. C’est utile pour tester que le service est lancé (depuis l’intérieur de la plateforme).

Sinon, on peut envoyer des requêtes GET /img/<adresse_en_hexa> or GET /img/<adresse_en_hexa>/<nom_de_fichier> pour les images, et GET /avatars/<adresse_en_hexa> ou GET /avatars/<adresse_en_hexa>/<nom_de_fichier> pour les avatars.

En se limitant aux requêtes légitimes, le comportement de img est le suivant :

• l’adresse demandée a été précédemment déclarée (dans redis par la partie code Ruby On Rails) sinon il répond 404 ;
• l’adresse demandée n’est pas bloquée par l’équipe du site sinon il répond 404 ;
• l’adresse est déjà dans le cache disque, alors il renvoie l’image ;
• l’adresse n’est pas dans le cache disque et la récupération échoue, il renvoie 404 (et va noter temporairement l’échec dans img/err/<uri>) ;
• l’adresse n’est pas dans le cache disque et la récupération a lieu (noté temporairement dans img/update/<uri>): si le serveur répond positivement à la demande, avec une image comme attendue, pas trop volumineuse, alors on la met en cache disque. Si c’est un avatar, on peut retailler l’image. On aura des champs supplémentaires stockés type avec la nature de l’image (en-tête Content-Type), checksum avec un hachage SHA1 et etag avec la valeur ETag (entête ETag).

Le cache est rafraîchi régulièrement.

img est un binaire statique en Go. Il offre des options pour définir le couple adresse:port d’écoute, pour définir où envoyer les logs, pour se connecter à une base redis, pour définir le répertoire du cache disque, pour choisir le User-Agent qui sera utilisé pour les requêtes externes, pour définir l’avatar qui sera renvoyé par défaut, et la possibilité de le lancer uniquement en mode audit interne pour vérifier la cohérence et l’état des données et des fichiers.

Dans les logs on va trouver des infos comme :

2024/10/20 20:39:24 Status code of http://example.invalid/exemple1.png is: 404
2024/10/20 20:39:24 Fail to fetch http://example.invalid/exemple1.png (serve from disk cache anyway)
2024/10/20 20:44:12 Fetch http://example.invalid/exemple2.png (image/png) (ETag: "be5e-4dba836030980")
2024/10/20 20:44:12 http://example.invalid/exemple3.png has an invalid content-type: text/html;charset=UTF-8
2024/10/20 20:44:12 Fail to fetch http://example.invalid/exemple3.png (serve from disk cache anyway)

Ici l’exemple 1 est déjà en cache et peut être servi même si on échoue à le récupérer à ce moment-là. L’exemple 2 vient d’être récupéré. L’exemple 3 a désormais une adresse invalide (qui renvoie une page HTML au lieu d’une image) mais il existe en cache une image précédemment récupérée.

Historique

img a été créé par Bruno Michel en 2012. Adrien Kunysz amène 5 commits en novembre 2013, mais globalement Bruno est le seul à travailler dessus (43 commits) jusqu’en 2018. img fait le job et il n’est pas besoin d’y retoucher trop souvent.

En 2022, Bruno quitte l’équipe du site, et par ailleurs il y a des montées de versions et des migrations à faire sur les serveurs de LinuxFr.org, et img fait partie des services à reprendre en main. Ce qui veut dire le comprendre, le documenter et au besoin l’améliorer.

Bref je décide de me plonger dans img (2022-2024), car a priori ce n’est pas le composant le plus compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer).

Étape 1 : je vais commencer par ajouter un Dockerfile permettant de recompiler img dans un conteneur, en contrôlant la version de Go utilisée, en effectuant une détection d’éventuelles vulnérabilités au passage avec govulncheck. Cela me permet de valider que l’on sait produire le binaire d’une part, et que l’on offre à tout le monde la possibilité de contribuer facilement sur ce composant.

Étape 2 : je vais tester le composant pour vérifier qu’il fonctionne comme je le pense et qu’il fait ce qu’on attend de lui. Je vais ajouter une suite des tests qui couvrent les différentes fonctionnalités et les vérifient en IPv4 et en IPv6, en HTTP 1.1 et en HTTP 2.0. Les tests utilisent Hurl et docker-compose (avec des images redis et nginx), et encore une fois l’idée de donner la possibilité de contribuer facilement. Ils comprennent des tests de types de contenus non pris en charge, le test de la limite à 5 MiB, différents types d’images, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). Le choix des cas de tests est basé sur le trafic réellement constaté sur le serveur de production, sur les différents cas dans le code et un peu sur l’expérience du testeur.

Étape 2,5 : l’avatar par défaut renvoie sur le site de production, y compris sur les tests en développement en local et sur le serveur de test du site. J’en profite pour ajouter un paramètre pour cela (et cela permettra de passer du PNG au SVG par défaut).

Étape 3 : encore une fois essayons de simplifier la vie d’hypothétiques personnes contributrices. Une petite modification pour que hurl et redis soient fournis via docker-compose et ne soient plus nécessaires sur le poste de développement.

Étape 4 : il est temps de documenter plus le fonctionnement. J’avais déjà décrit les infos stockées dans redis, mais pour comprendre le système de cache, autant fournir des diagrammes pour illustrer ce qui se passe lors d’une requête et comment on passe d’un état à un autre. C’est aussi l’occasion de compléter la suite de tests en ajoutant des tests avant et après expiration du cache, histoire de pouvoir documenter ces cas précis.

Étape 5 : en cas d’échec de récupération, une image était indisponible jusqu’à la prochaine récupération (donc potentiellement pendant 10 min). Autant servir l’ancienne version en cache lorsque cela se produit : je modifie le code et les tests en conséquence.

Étape 6 : je sais que certaines images ont été perdues, que des adresses d’images ont toujours été erronées, que des contenus et commentaires ont été supprimés et qu’il n’y a donc plus lieu de garder les images associées. Je décide d’implémenter dans img un audit interne qui indiquera si des anomalies sont présentes dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image. Et j’ajoute cet audit dans la suite de tests.

Étape 7 : j’écris une dépêche pour parler de tout cela.

Évolutions récentes

Dockerfile

Le fichier Dockerfile du projet permet :

• de partir d’une image officielle Go d’une version donnée, basée sur une distribution minimale Alpine
• de l’utiliser pendant la construction en prenant la liste des dépendances, en les téléchargeant, en prenant l’unique fichier source img.go et en le compilant statiquement avec l’option pour retirer les chemins de compilation
• de rechercher les éventuelles vulnérabilités avec govulncheck
• d’ajouter le paquet tzdata pour avoir les définitions fuseaux horaires (nécessaire pour les conversions de/vers GMT pour les entêtes type Last-Modified).
• de repartir d’une base Alpine en y mettant les définitions de fuseaux horaires et le binaire issus de la partie construction, de déclarer le port d’écoute et de lancer le binaire avec des variables disposant de valeurs par défaut.

La suite de tests

Pour l’utiliser, c’est assez simple, il faut aller dans le répertoire tests et lancer un docker-compose up --build, qui va produire le conteneur contenant img, et démarrer le redis et le nginx préconfigurés pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

linuxfr.org-img-test_1  | All tests look good!
tests_linuxfr.org-img-test_1 exited with code 0

Rentrons un peu dans les détails.

D’abord un fichier docker-compose.yaml qui décrit le réseau IPv4/IPv6 utilisé pour les tests, l’image redis qui sera utilisée (stockage géré par docker), l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image img et son paramétrage (dont l’accès au redis et au nginx) ainsi que le répertoire du cache et enfin l’image de la suite de tests qui est construit avec son Dockerfile, prévue pour faire du Docker-in-Docker et avoir accès au cache img et aux fichiers nginx.

Le Dockerfile de tests est basé sur une image Hurl (un outil pour faire des tests HTTP). On ajoute les fichiers de tests en .hurl, le script shell qui pilote le tout, on prévoit d’avoir les paquets dont on aura besoin : bash (pas par défaut dans les Alpine), coreutils, docker et xxd (pour les conversions texte vers hexadécimal). Et on lance les tests par défaut.

La configuration nginx de test écoute en HTTP sur le port 80 en IPV4 et IPv6 et permet de définir des chemins avec des réponses en HTTP 301, 302, 308, 400, 401, 403, etc. jusqu’à 530 et même 666 pour les codes invalides, ainsi qu’une redirection infinie.

Dans les données de tests servies par nginx, on trouve des contenus du mauvais type, une image destinée à être bloquée, des images dans divers formats, une image très grande en pixels mais pas trop en octets, une image trop grande en octets, et un avatar à servir par défaut.

Sont aussi présents cinq fichiers de tests avec une extension en .hurl :

• le test de vie et les chemins hors img/ et avatars/
• les tests sur les avatars : adresse valide ou invalide, image inexistante, bon et mauvais types, comportements sur les différents codes HTTP et sur une boucle de redirection infinie
• les tests sur les images (découpés en trois parties, la partie initiale, la partie entre la récupération initiale et l’expiration du cache et enfin la partie après la récupération et l’expiration du cache.

Vient enfin le script shell qui pilote le tout :

• on définit les variables pour les cibles IPv4/IPv6 et les binaires redis et img que l’on veut utiliser dans les autres conteneurs Docker
• on liste les images dans différentes catégories :
  • celles qui vont échouer et ne comporteront donc qu’une entrée dans redis sans rien dans le cache disque (avec sous-catégories possibles bloquées/non-bloquées)
  • les images devant être en erreur
  • les images qui iront normalement dans le cache
• on prépare des images qui seront altérées plus tard
• on purge le cache sur disque, on nettoie redis et on déclare toutes nos images comme le faire le code Ruby on Rails. Certaines sont déclarées bloquées pour les tests.
• on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
• on modifie certaines images pour simuler un changement sur le serveur externe, une suppression sur le serveur externe ou un blocage par l’équipe de site
• on lance les tests post-récupération initiale mais avant l’expiration du cache (toujours avec toutes les variantes)
• on force l’expiration du cache
• on lance les tests post-expiration du cache (toujours avec toutes les variantes)
• si on est arrivé jusqu’ici, c’est qu’on a passé tous les tests Hurl, alors maintenant on recompte ce que l’on a dans redis et sur disque et on vérifie si ça correspond à nos attentes
• on nettoie les images mises volontairement en échec
• on lance le test d’audit interne qui doit nous dire que tout va bien
• si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

L’audit interne

L’objectif est de vérifier la cohérence des données dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image.

Le binaire d’img peut donc être appelé en mode audit et lancer des contrôles internes.

D’abord il collecte la liste des fichiers dans le cache disque.

Ensuite il vérifie que toutes les images listées dans les dernières images (img/latest) existent comme entrées individuelles.

Puis il vérifie s’il existe des images bloquées (il râlera s’il y en a) et si chacune existe comme entrée individuelle le cas échéant.

Ensuite on parcourt tous les entrées individuelles d’images :

• on râle si on tombe sur une entrée img/updated/ ou img/err/ sans date d’expiration
• on râle si on tombe sur une entrée img/ sans champ created_at, sans type ou d’un type inconnu, sans checksum, avec un statut inconnu, une image bloquée non présente dans les images bloquées, un champ inconnu, une présence inattendue dans le cache disque, etc. Et on marque les images que l’on a vu passer comme attendu dans le cache.
• on râle sur tous les fichiers du cache restants (ne correspondant à aucune image)
• si on a râlé, on renvoie 1, sinon 0

Le grand nettoyage

img a fonctionné pendant 12 ans en production : il a rencontré des bugs, des comportements inattendus, des contenus et commentaires ont été supprimés ou réédités, etc. Il est donc probable qu’il y ait besoin d’aller dépoussiérer un peu tout cela et de retirer ce qui est inutile.

Les traces du grand nettoyage sont d’abord visibles dans la rétrospective de la première quinzaine de septembre 2024 :

• une « image » sur sept présente un souci (n’est pas une image, adresse invalide, trop grosse, etc.) et n’est donc pas dans le cache sur disque (ce qui a conduit à pas mal de taf sur la partie gestion des images)
• les types de contenu (Content-Type) en provenance de sites variés et divers, c’est quelque chose… entre les « image/JPEG » ou « image/PNG » en majuscules parce que, les charset=utf-8 ou UTF-8 ou… sur du binaire, les name= qui ne sont pas dans la norme… Wikimedia renvoie aussi du profile="https://www.mediawiki.org/wiki/Specs/SVG/1.0.0" (pareil ça semble en dehors de tout standard).

D’abord j’attaque le sujet la fleur au fusil en me disant que ça va passer crème, je fais un joli tableau qui résume l’état initial :

                              img/<uri>   img/updated/<uri>   img/err/<uri>   blocked
total                           25565 -21       634               160            5

no created_at                      23 -23         0                 0            0
created_at                       2857 -3          0                 5            1
created_at+type                   222             0                 0            0
total not in cache               3104 -26         0                 0            0

created_at+type+checksum(+etag) 22463 +5        634               155            4

files in cache                  22778 +5

Donc on a officiellement 25 565 images, mais 23 sont mal créées (état théoriquement impossible hors race condition), 222 sont incomplètes (état théoriquement impossible race condition), 22 463 sont attendues en cache et on a 22 778 fichiers dans le cache. Ça part mal. Je nettoie en premier le plus facile (on voit le delta +/- de mes corrections). Et on arrive à une situation où une image sur sept présente alors un souci et il faut gérer un grand volume de corrections à faire.

Parmi les soucis on trouve des types de contenus inattendus (image/PNG ou image/JPEG avec majuscules, image, des images binaires annoncées avec un charset, des types invalides comme image/jpg au lieu de image/jpeg, etc), des erreurs de notre lectorat (mauvais lien, mauvais copier-coller, lien vers une page web au lieu d’une image), mais aussi des espaces insécables et autres blancs inopportuns, des guillemets convertis, des doubles scheme (http://https:// ou http://file://).

Après cela se cache une autre catégorie encore plus pénible : les images que l’on a en cache, mais qui ne sont plus utiles au site : par exemple celles qui étaient dans des contenus ou commentaires supprimés (notamment le spam), celles qui étaient dans des commentaires ou contenus réédités depuis, etc.

Un problème connu est devenu vite pénible : on n’a pas d’association entre les images externes et les contenus/commentaires concernés. Donc il faut d’abord extraire la liste de toutes les déclarations d’images externes des 12 tables SQL où l’on peut trouver des images et des avatars, sous forme HTML ou Markdown.

Ensuite il faut sortir toutes les entrées dans redis et regarder si on les retrouve en clair ou converties en hexadécimal dans l’extraction SQL.

Et par sécurité on fera une double vérification pour celles détectées en erreur, en relançant une recherche en base (attention à la casse dans la recherche texte).

Au final, on peut supprimer des milliers d’entrées redis et de fichiers dans le cache.

Et un jour l’audit dit :

Connection 127.0.0.1:6379 0
2024/10/19 12:11:21 Sanity check mode only
2024/10/19 12:11:37 Files in cache: 17926
2024/10/19 12:11:39 Total img keys in redis: 18374
OK

Ça aura pris un mois et demi (l’audit a été fusionné le 8 septembre 2024), certes pas en continu, mais ça a été long et guère palpitant de faire ce grand ménage. Et j’ai refait une seconde passe du traitement complet la semaine d’après pour vérifier que tout se passait correctement et que les soucis résiduels après tout ça étaient minimes ou nuls.

Parmi les anecdotes, Web Archive / archive.org a eu sa fuite de comptes utilisateurs et a été indisponible sur la fin (ce qui rendait compliqué la récupération d’images perdues ou leur remplacement par un lien valide par exemple). Et, mentionné dans la rétrospective de la seconde quinzaine de septembre 2024, un compte de spammeur de 2015 supprimé… mieux vaut tard que jamais : détecté parce que comme beaucoup de visiteurs, le spammeur ne fait pas la différence entre un lien vers un document et l’ajout d’une image.

Les problématiques restantes

Il y a la question habituelle de la montée de versions des dépendances (pour nous actuellement contraintes celles du code Ruby on Rails) et du remplacement des composants devenus non-libres (migrer vers valkey plutôt que redis ? Questions à se poser sur l’avenir de nginx ?).

On pourrait aussi ajouter la prise en charge du TLS et d’un certificat X.509 directement dans img plutôt que dans un frontal. Mais ce n’est utile que si on les sépare sur deux serveurs distants, ce qui n’est pas le cas actuellement. Donc même si ça ne paraît pas compliqué à faire, ce n’est pas urgent.

Ensuite une entrée de suivi existe pour séparer le cache des avatars du cache des autres images : les contraintes pour le cache des avatars étant différentes de celui des autres images, le stockage en cache devrait être différent. Cela reste un problème mineur. Le changement doit d’abord être fait côté Ruby on Rails pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier img pour séparer le traitement des requêtes HTTP /img/<adresse_hexa> vers les clés redis img/<adresse> et le cache disque des images par rapport aux requêtes /avatars/<adresse_hexa> vers les clés avatars/<adresse> et le cache des avatars. Il faudra aussi déplacer les avatars stockés dans l’actuel cache des images dans leur propre cache. Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.

Un autre problème concerne la non-association des contenus ou commentaires avec les images externes qu’ils contiennent, ce qui rend l’administration des anciennes images un peu pénible. Le fait que les contenus et commentaires peuvent être réédités ou simplement prévisualisés (donc que des images peuvent être supprimées et d’autres ajoutées) vient compliquer un peu la tâche. Actuellement un ensemble de scripts permettent d’obtenir ces infos et fournissent un contournement, mais ça reste un peu laborieux.

Un cache rafraîchi périodiquement conserve les images pour éviter de surcharger le site d’origine, pas si le site a changé, déplacé ou perdu l’image. La modification pour servir depuis le cache disque en cas d’échec de récupération couvre le cas de la disparition d’une image avec une erreur sur l’adresse, pas celui où le serveur répond une mauvaise image. Il y a donc une autre entrée de suivi images et disparition du web évoquant l’augmentation des soucis sur les images externes avec un cache rafraîchi, en raison des domaines récupérés par des spammeurs et autres pénibles, ou perdus ou utilisés pour du phishing (imageshack.us, après framapic, pix.toilelibre, etc.). Diverses problématiques sont mentionnées comme la perte d’information et donc la diminution de l’intérêt des contenus anciens, la prime aux pénibles du référencement SEO qui pourrissent le net en récupérant les vieux domaines, la modification possible des images publiées. Pour résoudre cela techniquement, ça nécessite de suivre les images et les domaines perdus, et d’intervenir de façon régulière. Ou bien de ne plus rafraîchir le cache (que cela soit jamais, après la publication ou au bout d’un certain temps après la publication). Pour juste éviter la perte d’info, il est possible de remplacer par une image locale récupérée d’une archive du net type archive.org, avec le côté « pénible à faire » et sans garantie que ça soit toujours possible (merci waybackpy).

Enfin une troisième entrée de suivi suggère l'hébergement des images des dépêches (et éventuellement des journaux), idéalement en permettant d’avoir une version modifiée d’une image en changeant sa taille. On peut citer en vrac comme problématiques la responsabilité légale, l’éventuelle volumétrie, l’impossibilité de corriger une image publiée facilement par la personne qui l’a soumise, la centralisation et la perte de référencement pour des tiers, l’éventuelle rétroactivité et le traitement de l’historique, le fait qu’il faut traiter tous les autres contenus/commentaires pouvant accueillir des images, etc. Autre question, faut-il différencier les images passées en modération a priori de celles en modération a posteriori ?

Conclusion ?

Bref sans surprise, il reste des problématiques et du code à faire pour les gérer (c’est rare un composant sans demandes d’évolution ou de correction). Yapuka (mais probablement plus tard, il faut aussi partager le temps avec les autres composants, ou avoir plus de contributions).

img apporte les fonctionnalités que l’on attendait de lui même si on pourrait faire mieux. Plonger dans ce composant s’est avéré assez intéressant et formateur (et nécessaire) : techniquement cela a été l’occasion de faire du Go, du docker et du docker-compose, du redis et du nginx, du hurl et de l’HTTP. Et de comprendre ce que faisait un code écrit par une autre personne, de se poser des questions pour choisir les tests et le contenu de la documentation, de se demander pour quelles raisons tel ou tel choix a été fait, de rendre ce composant plus « contribuable », et de compléter le tout de façon détaillée avec une dépêche. Reste à savoir si j’ai répondu à l’attente d’un article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… et la réponse est à trouver dans les commentaires.

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

• pulkomandy, pour ses dépêches « pour la série sur les 23 ans de Haiku partie 1 : applications, partie 2 : le noyau et partie 3 : documentation, finances et GSOC » ;
• LaurentClaessens, pour sa dépêche « Y a le Frido 2024 qu'est là » ;
• Luc-Skywalker, pour sa dépêche « Recommandations de lecture: RE2020, CSTB, STD, ACV, FDES, INIES, HQE, coup de gueule et FOSS » ;
• raphj, pour son journal « Débugger un problème de performance avec strace » ;
• bobble bubble, pour sa dépêche « Entrevue avec Christophe Grenier, développeur de testdisk et photorec » ;
• Renault, pour sa dépêche « Vous pouvez tester Fedora Linux 41 Beta ! » ;
• Adrien Dorsaz, pour son journal « Installation personnalisée de Debian avec LUKS v2, volumes Btrfs, systemd-boot et Secure Boot ».

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

Les livres 📚 sélectionnés

• Coder efficacement — Bonnes pratiques et erreurs à éviter (en C++) ;
• Unity — De la création à la publication d'un jeu vidéo en 2D ;
• Guide juridique du numérique — Contrats, propriété intellectuelle, données personnelles, e-commerce… ;
• Rust — Développez des programmes robustes et sécurisés ;
• Scratch 3 pour les kids ;
• Méthodes de design UX — 30 méthodes fondamentales pour concevoir des expériences optimales — 3^e édition.

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

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du mois de septembre passé.

• « Formation des plus de 50 ans » par Lol Zimmerli ;
• « Bon anniversaire à mon Linux » par jseb ;
• « Chiffrement : on est vraiment des petits joueurs » par gUI ;
• « Droit à l'oubli ? » par Maderios ;
• « Pourquoi le rêve du bitcoin est fini. » par martoni ;
• «  Installation personnalisée de Debian avec LUKS v2, volumes Btrfs, systemd-boot et Secure Boot » par Adrien Dorsaz ;
• « Ford: Quand les brevets ne sont pas pensés par les informaticiens » par pif17 ;
• « cherche nouveau boulot » par octane ;
• « Débugger un problème de performance avec strace » par raphj ;
• « WireGuard : Au-delà de la configuration de base » par Moonz.

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

• raphj, pour son journal « Fin d’OCSP chez Let’s Encrypt : quid ? » ;
• Yves DEMUR, pour ses dépêches « S.M.A.R.T. badblocks badblocks2 et Sauvegardes (encore !) et restitution » ;
• luifr10, pour sa dépêche « Arrêtons de (dé)tester nos applications web » ;
• zurvan-0, pour son journal « Nouveautés issues du petit monde du FORTH » ;
• jeanas, pour son journal « Mon inquiétude sur les dépendances en Rust » ;
• ChocolatineFlying, pour son journal « hacker sa pompe de relevage ! » ;
• Stefane Fermigier, pour sa dépêche « Linus Torvalds: comment éviter que RISC-V ne reproduise les erreurs du passé? ».

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

Les livres 📚 sélectionnés

• PostGIS – Tous les ingrédients pour concocter un SIG sur de bonnes bases ;
• Scripting Python sous Linux — Développez vos outils système — 2^e édition.

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