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

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

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• La communauté francophone
  • L’association
  • La documentation
• Comment se procurer Fedora Linux 41 ?

Expérience utilisateur

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gestion du matériel

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

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

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

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

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

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

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

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

Internationalisation

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

Administration système

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

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

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

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

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

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

# update-crypto-policies --set FEDORA40

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

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

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

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

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

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

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

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

Développement

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Projet Fedora

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

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

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

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

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

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

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

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

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

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

La communauté francophone

L’association

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

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

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

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

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

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

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

La documentation

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

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

La synchronisation du travail se passe sur le forum.

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

Comment se procurer Fedora Linux 41 ?

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

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

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

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

La Cour des comptes a ouvert, jusqu'au 4 octobre 2024, une plateforme de consultation afin de permettre à celles et ceux qui le souhaitent de proposer des thèmes nouveaux sur lesquels l'institution pourrait exercer sa mission de contrôle de l'action publique.

La Cour des comptes considère, dans un récent rapport de juillet 2024 sur le pilotage de la transformation numérique de l'État, qu'« une véritable stratégie numérique avec des objectifs et jalons ne peut faire l’économie d’une consolidation, actuellement inexistante, des dépenses numériques de l’État et de leur projection. ».

L'April a donc soumis une proposition sur la plateforme de consultation sur « L'évaluation des dépenses logicielles de l'État et des administrations centrales ».

Plus la proposition sera soutenue et commentée, plus elle aura de chance d'être reprise. Nous invitons donc toute personne soucieuse d'une meilleure prise en compte du logiciel libre par la puissance publique à soutenir, voire à commenter, la contribution de l'April.

La proposition est disponible ici sur la plateforme. Ainsi que dans cette actu de relais de l'April, où elle est davantage mise en forme que ne le permet la plateforme.

Le consortium Unicode a annoncé la sortie de la version 16.0.0 de sa norme d’encodage des caractères le 10 septembre 2024. En bref, cette version voit le nombre de caractères passer de 149 813 à 154 998, soit 5 185 caractères supplémentaires. Elle ajoute sept nouvelles écritures, de nouveaux fichiers de données et quatre normes techniques Unicode sont versionnées pour être synchrones avec la norme Unicode. Elle remplace toutes les autres versions, la précédente datant de 2022.

Quelques-uns de ces changements sont détaillés ci-après, et, évidemment, tout figure dans les notes de version (en).

Sommaire

• Afrique
  • Les hiéroglyphes égyptiens, le principal ajout en nombre de caractères
  • L’alphabet Garay
• Asie
  • Les écritures de langues indiennes
  • Japon
• Albanie
• Émoji et héritage informatique
• Synchronisation
• Montée en version vers Unicode 16
• Fin

Afrique

Les hiéroglyphes égyptiens, le principal ajout en nombre de caractères

On se souvient peut-être des réactions des égyptologues, lors de l’introduction des hiéroglyphes égyptiens dans le standard Unicode en 2009. Il ne contenait que les sept-cent signes de base répertoriés par l’égyptologue britannique Alan H. Gardiner (1879 – 1963). Le gros reproche était le faible nombre de hiéroglyphes retenus : on en connaît plus de 6 000. Unicode 16 a rajouté 3 995 caractères aux 1 654 existants déjà dans le standard. Ce qui porte à 5 649 le nombre de hiéroglyphes égyptiens du catalogue Unicode

Les hiéroglyphes égyptiens occupent les blocs Unicode 13460 à 1355F.

L’alphabet Garay

L’alphabet Garay fait son entrée dans les blocs Unicode 10D40 à 10D8F.

Cet alphabet a été créé en 1961 par El Hadji Assane Faye, qui fut, entre autres, président du mouvement des enseignants en langues africaines. L’objectif étant de retranscrire « les caractéristiques sociolinguistiques africaines ». L’alphabet Garay comporte vingt-cinq consonnes et quatorze voyelles. Il est notamment utilisé pour le wolof, langue nationale du Sénégal, de la Mauritanie et de la Gambie. Il s’écrit de droite à gauche.

Asie

Les écritures de langues indiennes

Cinq écritures sont ajoutées à cette version d’Unicode. Les quatre premiers alphabets sont récents :

• Gurung Khema ou Khema est l’une des écritures utilisées pour retranscrire le Gurung (en), une langue parlée dans le Népal, il s’écrit de gauche à droite et occupe les blocs Unicode 16100 à 1613F,
• Kirat Rai (en), qui s’écrit de gauche à droite, est utilisé pour écrire le Bantawa, une langue parlée dans l’est de l’Himalaya et l’est du Népal, les blocs Unicode 16D40 à 16D7F lui sont réservés,
• Ol Onal a été inventé entre 1981 et 1992 (en) par Mahendra Nath Sardar pour transcrire la langue Bhumij, une langue parlée par quelques populations de l’ouest du Bengale et des états indiens Jharkhand, Odisha et Assam. Elle s’écrit de gauche à droite et on la retrouvera dans les blocs Unicode 1E5D0 à 1E5FF,
• Sunuwar (en), une écriture qui a été développée en 1942 par Krishna Bahadur Jentich (1926 - 1991) pour écrire la langue éponyme parlée dans le Sikkim, un État du nord de l’Inde, et au Népal, s’écrit de gauche à droite et figure dans les blocs Unicode 11BC0 à 11BFF,
• Tulu-Tigalari ou Tilagari est une écriture plus ancienne. L’alphabet a été conçu à partir de l’alphabet Grantha, une écriture du sud de l’Inde, depuis le XI^e siècle. Utilisé au départ pour le sanscrit, le Tilagari (en) sera aussi l’écriture du Tulu, une langue du sud-ouest de l’Inde à partir du XV^e siècle. Il s’écrit de gauche à droite et occupe les blocs Unicode 11380 à 113FF.

Japon

La base de données des caractères japonais « Moji Jōhō Kiban » (文字情報基盤) a été ajoutée comme source de référence (en) aux 36 000 idéogrammes unifiés CJC (chinois, japonais, coréen). Ce qui se reflète dans les tableaux de codes de pratiquement tous les blocs d’idéogrammes unifiés CJC par des glyphes représentatifs supplémentaires dans la colonne « J ».

Albanie

L’alphabet Todhri (en) a été inventé par Todhri Haxhifilipi (1811 - 1869) pour écrire en langue albanaise. Composée de cinquante-deux caractères, il s’écrit de gauche à droite et semble dériver de l’écriture cursive romaine.

Les blocs Unicode 105C0 à 105FF lui sont réservés.

Émoji et héritage informatique

Sept nouveaux émojis font leur entrée :

• une tête avec des valises sous les yeux (face with bags under eyes), 1FAE9,
• une empreinte digitale (fingerprint), 1FAC6,
• un arbre sans feuille (leafless tree), 1FABE,
• un radis (root végétable), 1FADC,
• une harpe (harp), 1FA89,
• une pelle (shovel), 1FA8F,
• une éclaboussure (splatter), 1FADF.

À cela s’ajoutent sept-cent symboles (en) d’environnements informatiques, blocs Unicode 1CC00 à 1CEBF (Symbols for Legacy Computing Supplement).

Synchronisation

Plusieurs spécifications Unicode importantes ont été mises à jour. Notamment les quatre standards UTS #10, UTS #39, UTS #46, et UTS #51. Ils sont maintenant versionnés de façon synchronisée avec le standard Unicode, leurs fichiers de données couvrant les mêmes répertoires. Ils ont tous été mis à jour en version 16.

Spécification	Champ d’application	Fichiers de données
UTS #10, Unicode Collation Algorithm (en)	Tri du texte Unicode	UCA data (en)
UTS #39, Unicode Security Mechanisms (en)	Réduction de l’usurpation d’identité en Unicode	Security data (en)
UTS #46, Unicode IDNA Compatibility Processing (en)	Traitement des URL non-ASCII URLs	IDNA data (en) et IDNA 2008 derived data (en)
UTS #51, Unicode Emoji (en	Émoji et leur comportement	Emoji data (en)

Ces modifications sont susceptibles de nécessiter des changements dans les implémentations. Les sections migrations et modifications des standards UTS #10 (en), UTS #39, (en), UTS #46 (en) et UTS #51 (en) indiquent comment y procéder.

Montée en version vers Unicode 16

Quels impacts pour cette montée en version, outre les modifications apportées par l’ajout de nouveaux caractères et de nouveaux systèmes d’écriture ? Ils semblent plutôt mineurs, le changement le plus notable concerne sans doute celui de l’accès aux spécifications Unicode :

• les spécifications de base ont été complètement remaniées pour Unicode 16.0 et, converties en HTML, elles sont déployées dans un sous-site autonome,
• plusieurs des caractères ajoutés peuvent avoir quelques implications sur certaines optimisations de la normalisation; cela ne modifie pas l’algorithme de normalisation, mais il peut y avoir des conséquences sur la dérivation et l’utilisation des propriétés Quick_Check pour l’optimisation de la détection des formes de normalisation, voir UAX #15 (en),
• des modifications ont été apportées sur les sauts de lignes apportées au guillemet simple gauche, U+2018 ‘ et aux guillemets directionnels similaires dans les contextes spécifiques d’Asie de l’Est afin de corriger les sauts de ligne en chinois simplifié et mieux coller aux spécifications au comportement de l’ICU (International Components for Unicode, bibliothèque logicielle, à ne pas confondre avec la fédération internationale des cheerleaders), voir UAX #14 (en),
• quelques changements ont été apportés à la spécification afin de mieux s’aligner sur les pratiques courantes et simplifier les éléments transitoires qui ne sont plus nécessaires.

Fin

On laissera le mot de la fin à St00e9phane Bortzmeyer¹ au sujet d’un site (de 2023) codé avec les pieds et une faible connaissance d’Unicode :

Si tu n’es pas assez fort pour lire les points de code Unicode, c’est que tu ne t’appliques pas assez de discipline.

J’en profite pour le remercier d’avoir fait passer l’information sur la sortie d’Unicode 16 sur Mastodon, sinon je l’aurais complètement ratée.

🎉 Il y a plus de deux décennies, j’ai lancé mon tout premier Linux-Meetup à Montréal en mai 2003. Depuis, chaque premier mardi du mois, nous avons tenu 252 rencontres sans interruption, rassemblant des passionnés du monde Linux.

🚀 Le samedi 21 septembre 2024, nous fêterons 21 ans de partage autour de Linux et des logiciels libres au Québec ! Cet événement coïncide avec la Journée internationale des logiciels libres (SoftwareFreedomDay), offrant une visibilité mondiale inégalée. Ce sera l’occasion de célébrer cette communauté qui s’est agrandie au fil des années et de marquer cette étape importante dans l’histoire du logiciel libre.

📈 Chaque année, notre événement annuel devient de plus en plus grand grâce à l’appui de nos commanditaires. Avec une participation record de 150 passionnés l’an dernier et le soutien de 23 commanditaires visionnaires.

🌐 L’événement se tiendra en présentiel à l’école de technologie supérieure (ÉTS), à l’université et en virtuelle sur BigBlueButton, permettant à la communauté Linux francophone de participer d’où qu’elle soit.

💼 Si votre entreprise utilise Linux ou soutient les logiciels libres, c’est une occasion unique de promouvoir vos solutions et vos services auprès d’une audience ciblée et engagée. Rejoignez-nous comme commanditaire et bénéficiez d’une visibilité accrue au sein de la communauté. Contactez-moi rapidement pour discuter de votre participation !

🚩 Pour les plus aventureux, la cinquième édition de notre chasse au trésor informatique (CTF : CaptureTheFlag) sera de retour avec des défis inédits, conçus par Dominique Derrier et Pascal Gad. Cet événement interactif mettra vos compétences Linux à l’épreuve et promet des moments captivants pour les participants.

🗣️ Au programme : des présentations passionnantes des experts Linux, le CTF et des opportunités d’échanges avec la communauté, et bien plus encore.

🎟️ Ne manquez pas cette opportunité unique de vous inscrire et de découvrir l’agenda complet à https://www.rencontres-linux.quebec/event/21-ans-de-linux-meetup-au-quebec-1/

Passbolt est un gestionnaire de mots de passe libre, sous licence AGPLv3, conçu pour l’utilisation en équipe et la collaboration. La version 4.9.0 de passbolt, baptisée B.Y.O.B, vient de sortir. Elle introduit une fonctionnalité très attendue par la communauté : la recherche par dossiers, ainsi que des améliorations majeures de performances.

Nouveautés de la version 4.9.0

Localisation des dossiers dans la grille

Affichage de l’emplacement des ressources : la grille affiche désormais l’emplacement des ressources dans les dossiers, facilitant leur identification et gestion.

Recherche par nom de dossier : les ressources peuvent être trouvées plus facilement grâce à une recherche utilisant maintenant les noms des dossiers.

Améliorations des performances

Gains de performances jusqu’à 50% : la navigation est désormais plus rapide, même pour les instances avec des grands nombres de mots de passe stockés.

Suspension des utilisateurs LDAP

Nouvelle option de suspension : les administrateurs peuvent désormais suspendre des utilisateurs sans supprimer leurs données, ajoutant une couche de sécurité et de contrôle supplémentaire.

En savoir plus sur la version 4.9.0

Pour plus de détails, consultez-les notes de version (en) et n’hésitez pas à nous faire part de vos retours.

Ben oui, ce sujet m’intéresse car je suis motivé par la préservation de ce que je considère comme précieux dans les données que je crée ou récupère sur mon PC. En tant que bidouilleur j’ai moi aussi créé un outil pour cela. Il correspond à mon besoin et j'en suis satisfait. Voici mon cheminement.

J’ai fait une recherche sur LinuxFR.org avec le mot sauvegarde et j’ai trouvé des articles et des réactions toutes très intéressantes. Les besoins, les solutions, les mises en œuvre sont très variées. Chacun choisit ou crée selon son ressenti et finit par être satisfait de ce qu’il fait. Chacun partage son expérience, en espérant qu’elle profitera à d’autres. À mon tour.

Le meilleur outil de sauvegarde est celui qu’on utilise et en lequel on a confiance.

Je te propose un jeu : demande à un utilisateur de PC, smartphone… si la destruction inopinée de son appareil entraînerait des pertes de fichiers irrémédiables qui pourraient l’affecter (photos familiales, documents…). Demande ensuite s’il fait des copies et/ou des sauvegardes. Pour beaucoup, tu seras catalogué comme vilain geek alarmiste. Il y a du travail de prise de conscience !

Sommaire

• Notion de sauvegarde
• Que demande-t-on à un outil de sauvegarde ?
• Un script shell écrit sur un coin de table (au début)
• Scripts bash tzsauv
• Subtilités et pièges
• Conclusion

Notion de sauvegarde

Une analyse très courte de la fonction sauvegarde serait « ranger quelque part des données qui permettront de restituer ce que je considère comme précieux ».
Les mots clés sont « ranger » « quelque part » « données » « restituer » « précieux ».
On a deux verbes « ranger » « restituer », deux localisations de données « quelque part » « ce qui est précieux », et une notion de filtrage dans le mot « précieux ».

Un autre point de vue serait de dire qu’une information précieuse doit résider en deux endroits, pour que la défaillance de l’un puisse être compensée par l’autre. Une des conséquences consiste à doubler les archivages : la libération des espaces précieux par la suppression de données inactives doit être précédée de l’archivage des données à supprimer vers deux supports distincts. Une autre conséquence est d’utiliser un média spécifique pour recevoir les sauvegardes (autre que celui où sont les données à sauver).

La défaillance peut être de plusieurs origines : matérielle, corruption du média, utilisateur qui efface/écrase…

Que demande-t-on à un outil de sauvegarde ?

Si je rédigeais un cahier des charges pour un outil de sauvegarde, je ferais les listes suivantes. Je suis dans mon contexte de PC isolé, ayant accès éventuellement à un petit serveur sur le réseau local.

Fonctionnalités de base :

• sauver juste ce qui a été modifié depuis la sauvegarde précédente => opération rapide,
• compression des fichiers archives => prend peu de place sur l’espace de sauvegarde,
• facile à lancer et rapide en exécution => sera lancé souvent => sécurisation accrue,
• filtrage => possibilité de conserver dans les espaces sauvés des fichiers qui n’encombreront pas les sauvegardes,
• robuste => confiance.

Fonctionnalités nécessaires :

• vérification de l’intégrité des fichiers archives engendrés,
• restitution facile malgré le grand nombre de fichiers archives à exploiter,
• restitution qui permette de régénérer (ailleurs) l’espace sauvegardé dans le même état que ce qu’il était au moment d’une des opérations de sauvegarde (accès aux états antérieurs),
• recherche/extraction de fichiers dans le grand nombre de fichiers archives obtenus,
• traçage pour vérifier le bon déroulement des opérations.

On peut ajouter aussi :

• algorithme ouvert et source fourni,
• qui s’accommode de tous types de support de stockage,
• qui utilise des formats standard,
• qui a toutes ses fonctionnalités accessibles en ligne de commande.

Le dernier point permettra d’utiliser l’outil comme une commande classique. On pourra le lancer dans un script bash qui adaptera l’usage au besoin spécifique du moment (ajout de montage/démontage du média de sauvegarde, rsync réseau des fichiers générés…). C’est une commodité qui me manque quand je suis coincé dans l’usage d’un outil cliquodrome.

Un script shell écrit sur un coin de table (au début)

J’ai rencontré le shell lors de mon premier contact avec Unix, en 1987. Au début j’ai eu le sentiment de régresser par rapport à la syntaxe COM des Vax/VMS. Depuis, j’ai appris à apprécier le bash, bien plus commode que ses ancêtres sh csh. Une des philosophies du shell est de combiner des commandes simples et robustes pour en faire une réponse à un besoin. Par exemple ls | wc -l renvoie le nombre de fichiers/répertoires du répertoire courant. Toutefois, il y a des cas sournois où le résultat est faux, on verra plus loin ce que je qualifie de pièges.

Avec les pipelines, les redirections, les variables, les traitements de chaînes de caractères, et tout le reste, on peut construire à l’infini des séquences d’opérations qui s’appuient sur des commandes simples à lancer mais puissantes (genre outil de compression, outil de parcours d’une arborescence de fichiers…). Beaucoup des fonctionnalités du système GNU sont construites comme cela. Un bidouilleur système ne peut pas ignorer le bash. En plus, emacs permet un accès très commode aux man. Je n’ai jamais eu de projet ou de besoin qui me pousse à maîtriser Perl ou Python. Je pense qu’ils sont encore plus puissants que bash.

Comme j’aime bien bidouiller, à la fin du 20^e siècle j’avais dans l’idée de faire un outil de sauvegarde basique qui s’appuie sur un pipeline : une commande find qui sélectionne les fichiers modifiés, tar pour les copier et gzip pour compresser. J’ai fait divers essais. En 2021, je m’y suis mis sérieusement et j’ai découvert beaucoup de subtilités du bash.

Un des problèmes des sauvegardes incrémentales est de deviner si un fichier doit être sauvé, sans avoir à comparer son contenu avec la version sauvée dernièrement (ça coûte trop cher). Il faut se baser sur les paramètres du système de fichiers. Il faut bien choisir ces paramètres (on surveille leur changement), au risque de rater certains fichiers ou alors d’en sélectionner trop. Je me suis arrêté sur la date de modification du statut et le numéro d'inode.

Scripts bash tzsauv

Je pense être arrivé au bout des spécifications avec l’outil tzsauv que j’ai écrit en bash. Il est disponible sur mon site.
Je m’en sers quotidiennement. Selon les jours, j’envoie les fichiers archives sur le 2ᵉ disque ou sur clé USB. Je fais aussi un miroir du répertoire disque des fichiers archives vers GoogleDrive (ceinture et bretelles). Je fais aussi une sauvegarde à longue périodicité (six mois) sur une clé USB dédiée (double ceinture).

Les opérations principales utilisent les commandes standard find sed tar zstd md5sum, le bash sert à enchaîner tout ça et sert aux dialogues. Pour installer, il suffit de copier deux scripts sur le média de sauvegarde (SauverTZ_ProjXY_01.bash tzsauv.bash, total 96k, ajouter éventuellement l’aide Alire.txt), et modifier quelques paramètres dans l’un des scripts (le script lanceur SauverTZ_*.bash). Le lancement peut se faire en ligne de commande ou via l’explorateur de fichiers par Clic-Droit/Actions/LancerDansKonsole.

L’interprétation du bash prend des ressources, mais je pense qu’elles sont négligeables par rapport à celles prises par les E/S et les commandes standard citées ci-dessus. Le compresseur zstd semble être très performant, en temps et en taux de compression. De plus, il est multithread, ce qui lui permet de tirer avantage des processeurs actuels qui gagnent en puissance en augmentant le nombre de cœurs. Le paramétrage de tzsauv permet de choisir parmi plusieurs formats d’archives.

Pour la sauvegarde vers le 2^e disque, j’ai copié sur le Bureau le lanceur de Konsole, puis j’ai renommé la copie et dans ses Propriétés/Application j’ai modifié l’argument (-e ./SauverTZ_ProjXY_01.bash) et le dossier de travail. Du coup, avec juste un double-clic je lance la sauvegarde en mode interactif (-> question « … TOTALE o/n/q ? »). Elle est pas belle la vie ?

Subtilités et pièges

Je fais régulièrement des petits programmes bash pour explorer des détails de fonctionnement soit du bash, soit des commandes. Les man ont beau être détaillés, ils ne peuvent pas tout dire. Pour un bug de tar je suis allé jusqu’à consulter le source C, le corriger par plaisir et vérifier que c’était OK. La remontée du bug n’a pas abouti (personne n’utilise l’option -u de tar ! C’est de la tétrapilectomie, je suis xyloglotte mais pas encore alopécique).

Si tu lances sous bash ls | wc -l puis touch -- 'a'$'\n''b' puis de nouveau ls | wc -l, le nombre renvoyé aura augmenté de deux alors que tu n’as ajouté qu’un seul fichier. C’est normal car le nom du fichier ajouté tient sur deux lignes ! Solution : ls -q | wc -l ou ls --zero | tr '\n\0' '\0\n' | wc -l. Pour voir le résultat de ls -q envoyé à wc -l via le pipeline, entrer ls -q | cat.

Les deux seuls caractères interdits dans les noms de fichiers/répertoires *unix* sont « / » et « \0 » (à méditer).

Je t’invite à créer sous bash un fichier piège par echo "abcd" > $' xyza\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC ', à le sauver avec ton outil, puis à le restituer. Tu verras si ça passe et si le nombre de fichiers est correct. Pour le détruire rm -i *xyza* devrait convenir.
Essaye aussi avec un sous-répertoire mkdir $' xyzp\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC '. Mets-y un fichier, puis fais une sauvegarde totale, modifie le fichier et fais une incrémentale. Ensuite fais un essai de restitution. Joue aussi à modifier le nom du répertoire parent du sous-répertoire piège.
Pour jouer avec ces choses dangereuses, je te conseille de faire une zone à part, ne fais pas courir de risque à ta production. Sur ma Mageia9.2-official, le navigateur Dolphin n’arrive pas à détruire le répertoire piège. Je passe par la ligne de commande.

J’ai rencontré tout plein de pièges et j’en ai imaginé d’autres : un fichier de nom -f, un répertoire de nom -, comment détruire le fichier ? Comment faire un cd vers le répertoire ?
Solutions : rm -f -- -f et cd -- -/ et si le nom du répertoire est dans la variable var cd -- "${var%/}/" (prévoir le cas où var="/").
J’ai découvert que zstd en mode filtre lancé par tar, se met en erreur s’il existe un sous-répertoire de nom - dans le répertoire courant (c’est très particulier, en effet). L’examen des sources de tar et de zstd m’a confirmé le problème, la solution m’a parue simple (inverser l’ordre de deux tests dans le source de zstd) mais la remontée de bug n’a pas abouti. Ce n’est pas grave, je sais maintenant qu’il ne faut pas utiliser tar ... --zstd ..., et je mets plutôt zstd -c[d] dans un pipeline.

J’en raconte un maximum dans le fichier notes01.bash. Toute cette expérience me permet de créer des scripts bash robustes.

Conclusion

Ton outil de sauvegarde est le meilleur, car il te convient.
Fais-toi une idée claire

• de tous tes espaces contenant des fichiers précieux à tes yeux,
• de tous tes espaces de sauvegarde,
• des mécanismes de sauvegarde et de restitution.

Cela participe à la confiance.

N’oublie pas de faire de temps en temps un contrôle d’intégrité des archives et un exercice de restitution. C’est un peu de travail, juste pour vérifier qu’une mise à jour, ou une donnée inhabituelle, ou autre chose, n’a pas mis en défaut la capacité à restituer comme tu l’entends.

Si la restitution est rendue impossible, c’est comme si tu n’avais jamais sauvegardé !

La confiance, en informatique ça se surveille du coin de l’œil
L’informatique est une science exacte pour la machine, pas pour l’homme ; il compense par l’humilité et l’empirisme

Sailfish OS est un système d'exploitation basé sur le noyau Linux et développé par la société finlandaise Jolla. Il vise surtout le marché des appareils mobiles (smartphones, tablettes).

Dans la suite de la dépêche, vous découvrirez les dernières nouvelles concernant Jolla et Sailfish OS.

Sommaire

• Introduction
• Nouveautés depuis Sailfish OS 4.4
  • Version 4.5 - Struven Ketju
  • Version 4.6 - Sauna
  • Nouveaux modèles pris en charge
• Contributions communautaires
• Les applications natives
• Nouveau modèle économique pour Sailfish OS
• Jolla et le logiciel libre
• Restructuration
• Conclusion

Introduction

Après une période turbulente, Jolla est enfin prête à attaquer cette nouvelle année sereinement. En attendant les répercussions de cette nouvelle ère, petit tour d'horizon des dernières nouveautés dans Sailfish OS depuis la dépêche d'octobre 2022 et des annonces survenues lors du Jolla Love Day 2.

Basée sur la distribution GNU/Linux MeeGo, initialement développée par Nokia et Intel, Sailfish a le principal avantage de fournir une couche supplémentaire nommée AppSupport basée sur Android AOSP. AppSupport s'exécute dans un container LXC et permet d'installer des applications Android, compensant ainsi l'absence de certaines applications ou services natifs. Cela positionne Sailfish comme une réelle alternative à Android, sans pour autant être handicapé par le peu d'applications natives.

Pour la petite histoire, en 2011, Nokia opère un choix stratégique consistant à passer à Windows Phone pour tous ses modèles. Cela a abouti au démantèlement de la division en charge de MeeGo et du Nokia N9, qui était aussi à l'origine du Nokia N900 sous Maemo.
En raison de ces turbulences, plusieurs employés décident de fonder Jolla afin de continuer le développement de MeeGo et de concevoir leur propre matériel. En 2013, leur premier modèle — le Jolla 1 — est dévoilé et sera maintenu jusqu'en septembre 2020.

Par la suite, la société Jolla a développé une tablette mais pour diverses raisons, notamment de fabrication, sa commercialisation a dû être arrêtée et seule une partie des commandes a été livrée. Enfin, il y a eu une nouvelle tentative pour un second smartphone dédié aux développeurs dont nous parlerons dans la suite de cette dépêche.

C'est après cet échec, que Jolla a décidé de se concentrer sur le système d'exploitation en s'appuyant entre autres sur le programme «Sony Open Devices». La première version du programme Sailfish X est publiée en 2017 pour le Xperia X.

Il y a eu par la suite le Xperia XA2 (32bits), toujours maintenu, puis le Xperia 10 II et enfin le 10 III (64bits).

Nouveautés depuis Sailfish OS 4.4

Chaque nouvelle version apporte sa grosse nouveauté. L'occasion aussi de stabiliser l'OS et mettre à niveau les différentes dépendances. Toutes les modifications sont listées dans les notes de version de chaque mise à jour.

Version 4.5 - Struven Ketju

Cette mise à jour sortie le 09 février 2023 est nommée en l'honneur de l'arc géodésique de Struve.

Elle apporte la mise à niveau d'Android vers la version 11, tout comme diverses contributions pour stabiliser et améliorer l'expérience utilisateur tant au niveau d'Android qu'au niveau de Sailfish OS.
Dans les principales améliorations, notons :

• une meilleure intégration d'Android au sein de Sailfish OS ;
• une connectivité (Wi-Fi, réseau mobile) plus stable ;
• une amélioration lorsque l'utilisateur active le Bluetooth et cherche de nouveaux appareils ;
• ou encore la possibilité d'utiliser une phrase de passe. Précisions de taille, cela sert à déchiffrer la partition, déverrouiller le système ou encore à obtenir les droits root lorsque c'est nécessaire.

Cette mise à jour est aussi l'occasion d'ouvrir l'accès à plusieurs API. Comme aux bibliothèques QtLocation, BluezQt ou encore Sailfish.media. Cette dernière permettant d'intégrer le lecteur audio dans une application. Voir la liste de toutes les nouvelles API dans la note de version struven ketju 4.5.0-16 pour l'énumération complète.

Autre nouveauté apportée, cette fois-ci par dcaliste : en plus de la vue « à la semaine » l'application calendrier offre une vue « au mois » ainsi qu'une autre vue « au jour ». dcaliste en a aussi profité pour améliorer la synchronisation avec les divers comptes en lignes.

Dernier point, l'ajout d'une option native arrêtant la charge pour réduire l'impact sur la batterie.

Au fil de l'année, plusieurs mises à jour mineures ont été déployées afin de corriger divers bugs introduit par la 4.5.0.16.
La 4.5.0.19 publiée le 23 mars 2023 apporte la gestion de CLAT à ConnMan, permettant d'utiliser les données mobiles sur les réseaux IPv6.

En mars 2024 est publiée une mise à jour mineure modifiant les conditions générales d'utilisation. Ceci afin de marquer le changement de propriétaire et donc le renouveau de Sailfish.

Version 4.6 - Sauna

À l'occasion du Jolla Love Day 2, la version 4.6.0.11 a été publiée pour les utilisateurs aguerris ayant activé le mode « Early Access ». La version définitive sera rendue publique lorsque les bugs découverts durant la seconde phase de test seront corrigés.

Parmi les principales nouveautés, l'apport de la 5G pour le Sony Xperia X10 III. Le précédent modèle, en l'occurrence le X10 II en étant dépourvu, il n'y a pour l'instant qu'un seul appareil compatible. Précision de taille, l'apport de la 5G est intimement lié au matériel malgré l'adaptation de ConnMann et oFono pour gérer la 5G.

Autre changement de taille, le partage de connexion par Bluetooth est désormais implémenté.

À nouveau, calendrier est l'une des principales applications à recevoir une nouvelle fonctionnalité l'améliorant grandement avec la possibilité de rechercher des événements.

Le 06 juin, la version 4.6.0.13 a été déployée aux abonnés « Early Access » et corrige certains bugs introduits précédemment.

Nouveaux modèles pris en charge

De nombreuses rumeurs mentionnaient la prise en compte de nouveaux appareils. En suivant divers dépôt Github, il a été possible de déduire quel était le futur appareil Sony géré par Jolla. Le 18 avril, la lettre d'information met enfin un terme aux diverses spéculations et confirme le portage de Sailfish sur les Sony X10 IV et Sony X10 V. D'autres portages toutefois non-officiels sont en cours de développement, comme pour le Fairphone 5.

Suite au Jolla Love Day 2, un nouvel appareil officiel limité à 1 000 unités est annoncé. À savoir le Jolla Community Phone aussi nommé Jolla C2 et développé en collaboration avec le constructeur turc Reeder.

Pour rappel, le premier appareil dédié à la communauté était le Jolla C. Ce modèle a été développé sur la base du Intex Aquafish du constructeur indien Intex Technologies. D'ailleurs il était relativement facile, pour ceux et celles qui n'avaient pu obtenir le Jolla C de convertir l'Intex Aquafish en Jolla C. Il en reste encore des traces dans le forum. Le Jolla C et l'IntexAquafish « as a Jolla C » sont encore maintenus, mais la version 4.6 sera la dernière mise à jour. Le Jolla C étant sorti en 2016, et l'Intex Aquafish quelques mois plus tard, nous pouvons considérer que c'est une bonne durée de maintenance et équivalente à celle du Jolla 1.

Contributions communautaires

Sailfish OS n'est certes pas entièrement libre, cela n'empêche pas d'avoir une communauté d'utilisateurs active contribuant aux parties libres de la distribution. Ce faisant, Sailfish OS fait ainsi partie des solutions alternatives aux deux autres grands systèmes du marché que sont iOS et Android.

Historiquement, pour le navigateur natif, Sailfish OS a toujours utilisé Gecko comme moteur de rendu, en utilisant l'adaptation Qt (QtMozEmbed) pour ce dernier. Maintenir cette adaptation pour un logiciel tel que Gecko est une tâche ardue et chronophage, raison pour laquelle Sailfish Browser utilise encore la version ESR 78. Un ancien employé de Jolla, flypig, a pris en main la mise à niveau du moteur de rendu à la version Gecko 91.
Ce travail titanesque est entièrement documenté dans un journal. La lecture en vaut d'ailleurs la chandelle !

En ce qui concerne oFono, un autre contributeur de Sailfish, piggz, a entrepris de gommer les divergences avec la version maintenue par Jolla. piggz est également connu pour ses portages, principalement sur le PinePhone. Suite à l'initiative de flypig de documenter son projet, l'avancement de son projet est documenté dans un journal.

La nouvelle n'a pas encore eu d'énormes répercussions, mais une équipe d'utilisateurs a entrepris de porter Flutter sur Sailfish OS. Pour l'instant, seule une application est disponible.

Les plus téméraires d'entre vous pourront également installer le gestionnaire de paquets nix sur SailfishOS. Le développeur qui s'est lancé dans cette aventure a eu droit à un bel entretien dans le Community News de décembre 2023.

Entre le 26 et 30 septembre 2024 se tiendra le second Hackathon organisé par la communauté d'utilisateur. L'événement étant en cours d'organisation les informations suivront prochainement.

Les applications natives

Il est évident que la liste des applications natives est moins fournie que les OS concurrents dominant le marché. Pour autant, l'essentiel est disponible ! Chaque 2 semaines lors du « Community News », les dernières applications actualisées sont mis en évidence dans cette lettre de diffusion. Par exemple — et outre le calendrier déjà évoqué — voici de manière non exhaustive quelques applications tierces natives :

• Pure Maps : associée avec OSMScoutServer, offre un système de navigation hors-ligne performant. Certes, il n'y a pas toutes les informations que l'on peut trouver dans les applications concurrentes, mais son usage reste très confortable ;
• Barcode, anciennement Codereader, un lecteur de codes-barres et de codes QR. Disponible dans Openrepos et Chum. Parfait pour récupérer les codes QR des timbres postes en lettre suivie. A noter également que l'auteur de Barcode a publié une application pour utiliser une Yubikey disponible dans Chum.
• Paketti : une application de suivi de courrier et de colis ;
• Chum : magasin d'applications fonctionnant dans les mêmes principes que F-Droid. Il est possible d'installer aisément via https://chumrpm.netlify.app/. Voir aussi cet article de blog du Nico's blog au sujet de Chum ;
• ownKeepass : application capable d'emporter avec vous votre fichier .kdbx Application et offre toutes les fonctions basiques présentes dans KeepassX. Malheureusement le développement d'ownKeepass s'est arrêté, ce qui n'empêche pas qu'un jour le développement soit repris par quelqu'un d'autre :

• SeaPrint : pour imprimer sur une imprimante réseau des images et des PDF via le protocole IPP. SeaPrint est développé par attah ;
• Mentionnons gPodder qui vient de sortir en version 4.16 pour les podcasts ;
• Une liste complète des applications est accessible sur les sites suivants :
  • https://openrepos.net/
  • https://sailfishos-chum.github.io/

Si l'utilisateur ne trouve pas son bonheur, grâce au Android AppSupport il sera toujours possible d'installer Fdroid et Aurora Store. A noter aussi que microG peut également être installé assez facilement, notamment pour permettre l'usage de certaines applications bancaires.

Ainsi, le magasin d'applications fourni par Jolla permet de trouver le magasin F-droid ou encore Aptoide. C'est depuis F-droid qu'il sera possible d'installer Aurora Store.

Rappelons que parmi les limitations, le Bluetooth n'est opérationnel que pour le son dans les applications Android. A ce jour, seuls certains modèles de montres assez spécifiques sont capables de communiquer avec le smartphone grâce à l'application native Amazfish développé par piggz, toutes les autres montres ne pouvant pas se connecter en Bluetooth au smartphone en raison de cette limitation du Bluetooth.
Pour en savoir plus, vous pourrez lire cet article du Nico's blog. Il en est exactement de même pour le NFC. Implémenter une interface entre Android et Sailfish requiert malheureusement énormément de ressources, mais nous pourrions espérer qu'un jour cela finisse par arriver. Principalement depuis que l'industrie automobile s'intéresse à la prise en charge d'Android.

Nouveau modèle économique pour Sailfish OS

Suite à l'échec de la tablette Jolla et du modèle « commerce entre entreprises et particuliers », une politique de licence régionale a été mise en place dès 2017 avec un partenariat dans plusieurs pays. Cela s'est concrétisé avec l'Intex Aquafish en Inde, qui a servi de base pour le Jolla C. En Amérique Latine, un accord de licence a été signé avec l'entreprise bolivienne Jala sous la marque Accione et enfin avec Rostelcom en Russie, certainement lors de son entrée au capital de Jolla.

Pour des raisons douanières et administratives, Jolla ne commercialisait ses licences qu'au sein de l'Union européenne ainsi que dans l'Association européenne de libre-échange (AELE). Suite au « Brexit », la commercialisation avec la Grande-Bretagne n'a repris qu'en 2021.

Lors du Jolla Love Day 2, un nouveau modèle économique a été présenté. Les appareils apparus avant les Sony X10 IV et Sony X10 V sont livrés avec une licence perpétuelle. Les nouveaux modèles eux sont utilisables avec un abonnement mensuel, voire annuel. La documentation sur les licences sera mise à jour lors de la commercialisation des licences pour les X10 IV, V et Jolla C2. Quelle que soit la licence payante (perpétuelle pour X10 II et X10 III ou à abonnement pour le X10 IV et X10 V et aussi le J2), les services fournis demeurent les mêmes :

• Les mises à jour logiciel OTA ;
• L'accès au support client tant que l'appareil est garanti ;
• La possibilité d'installer les extensions suivantes :
  • Android AppSupport ;
  • Support Microsoft Exchange ;
  • Saisie prédictive.

Petite particularité du Jolla Community 2, l'abonnement valide une année est inclus dans le prix d'achat.

En dehors du Jolla Community 2, où Sailfish OS est flashé par défaut, tous les autres modèles nécessitent d'être manipulé par l'utilisateur pour changer l'OS. Les instructions en anglais sont fournies pour tous les modèles et rédigées pour être exécutées depuis Linux, Mac OS ou encore Windows.

Jolla et le logiciel libre

Jolla a toujours été ouvert à l'idée de libérer les sources, il est dommage que depuis 2013 certaines parties comme le compositeur Lipstick restent encore propriétaires. Un bref instant, une vague de projets a été libéré. Malheureusement, cela a été de courte durée. Cela n'empêche pas que Jolla reste un contributeur au logiciel libre et qu'il a libéré les sources de certaines applications comme le navigateur ou encore le lecteur de document. La grosse partie du backend est lui libre. Avec un changement radical dans leur modèle économique, les choses pourraient changer.

Récemment, quelques nouvelles bibliothèques ont été développées avec une licence open-source, comme une exportation vers le QML de l'interface MPRIS.

Autre point intéressant à noter, Jolla a grandement contribué à l'essor de Linux sur les téléphones portables avec le développement du projet libhybris.

Voici une liste non exhaustive des projets auxquels Jolla contribue ou a libéré les sources :

• amber-web-authorization qui permet de faire de l’authentification OAuth en QML ;
• sailfish-secrets qui est un projet ambitieux, permettant de chiffrer / déchiffrer depuis le QML en choisissant son backend (principalement OpenSSL, mais aussi GnuPG), mais qui permet aussi de stocker des informations chiffrées sur le téléphone, un peu comme un kwallet ;
• messagingframework, hérité de l’ère Nokia et hébergé par le projet Qt. C’est un quadriciel de gestion des courriels ;
• KCalendarCore, un « framework » KDE pour la gestion du calendrier.

Et bien sûr tout l’héritage de MeeGo, directement maintenu par Jolla, également utilisé par d’autres projets comme LuneOS ou encore AsteroidOS :

• tous les bindings QML ;
• les bibliothèques d’intégrations, comme la gestion de l’historique des communications ou la gestion de la synchronisation ;
• la gestion des capteurs ;
• la gestion du clavier virtuel.

Notons aussi que Jolla participe régulièrement à FOSDEM. Si vous souhaitez lire à ce sujet : https://www.ncartron.org/jolla-and-sailfish-os-at-fosdem-23.html

Restructuration

Cette restructuration s'est opérée dans le cadre du droit finlandais. L'objectif était notamment de restructurer le capital et faire sortir l'actionnaire russe Rostelcom. Pour ce faire, et comme vraisemblablement les négociations amiables n'ont pas dû aboutir, les dirigeants de Jolla ont demandé à la justice de placer l'entreprise dans le cadre d'une procédure que nous pourrions comparer en droit français à la procédure de sauvegarde.

Cette procédure a fini par aboutir et — selon notre compréhension — cela s'est traduit par la création d'une nouvelle entité : l'entreprise Jollyboys Ltd.

Jollyboys a repris ainsi tous les actifs de Jolla, y compris la marque, les noms de domaines et bien entendu Sailfish OS.
Nous comprenons, selon les planches qui furent publiées pendant le Jolla Love Day 2, que les entreprises Jolla/Jollyboys Ltd et Seafarix ont été rachetées par le personnel dirigeant de l'entreprise Jolla.
Chaque technologie est séparée dans une structure juridique différente :

• Seafarix pour ce qui concerne l'automobile ;
• Jollyboys pour Sailfish OS ;
• VenhoAI pour les produits relatifs à l'IA.

La réorganisation de l'entreprise Jolla a suscité l'objet de beaucoup de discussions sur le forum.
Nous comprenons également que la marque Jolla et le nom de domaine jolla.com sont la propriété de la société Jollyboys.

Conclusion

Lors du Jolla Love Day 2, une feuille de route pour la version 5 a été dévoilée.
Une séparation de Sailfish est planifiée avec une partie nommée Sailfish Core et dévouée à l'embarqué et une autre conçue pour les téléphones portables, tablettes et autres appareils.

À voir ce que donnera le nouveau modèle de financement, mais il est réjouissant de voir du changement. L'année prochaine nous confirmera si cette nouvelle voie est la bonne. Le développement logiciel étant coûteux, offrir la possibilité d'y contribuer financièrement en tant qu'utilisateur donne plus de garantie de survie et de développement.

Si vous souhaitez suivre Sailfish, des comptes rendu des réunions de la communauté organisés par Jolla sont également accessibles. Il existe un blog officiel et une lettre de diffusion qui parait toutes les deux semaines et dont le numéro du 6 juin est précisément consacré à la 4.6 - Sauna.

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

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

• Opale pour la formation
• Dokiel pour la documentation
• Optim pour les présentations génériques
• Topaze pour les études de cas
• …

Merci d’avoir fait de ces Rencontres 2024 un événement inoubliable !

Et merci surtout à l’Université Toulouse Capitole et à l’équipe d’organisation sur place emmenée par Élodie, Thérèse, Ségolène, Éléonore, Dominique, …

Quelques chiffres :

• ⚙️ 12 ateliers (qui ont réunit 162 participant⋅e⋅s).
• 👥 132 inscrit⋅e⋅s.
• 💬 207 personnes sur l’espace d’échange Mattermost.
• 🎬 13 sessions en direct, de 36 conférences.
• 🌐 des participant⋅e⋅s sur place de 6 pays différents.
• 🧵 2 ateliers continus « libre-service » (découverte et Parcours/Platine).

Les enregistrements des conférences, ainsi que les photos, seront bientôt en ligne sur le site de Rencontres 2024 dans la page de chaque intervention. Suivez nos réseaux sociaux pour savoir quand les ressources seront mises en ligne.

🖥️ Pas de mini-webinaire en juin

On ne peut pas organiser des Rencontres Scenari ET aussi un mini-webinaire ! :)
De plus, il faut digérer la quantité d’information et toutes les perspectives que ces Rencontres nous ont ouvertes.
On se retrouvera donc en juillet pour le prochain mini-webinaire.

Il y a à peu près un mois, MyScenari a été mis à jour en version 6.2.4.
Comme d’habitude avec MyScenari, les modèles documentaires ont tous été mis à jour dans leur dernière version.
Si tu utilises MyScenari via le client lourd, il te faudra mettre à jour l’application.

Un passage de tes ateliers à la dernière version de chaque modèle est conseillé :
1. rends-toi dans les propriétés de l’atelier 
2. choisis la version la plus récente du modèle
3. exécute la migration proposée
4. et voilà !

Une nouvelle version de l’extension « Export exercices Moodle » pour Opale 5 a été déposée sur la plateforme des contributions communautaires.
D’autres extensions sont présentes sur la plateforme. Sers-toi !

Une nouvelle version corrective de Topaze est disponible : Topaze 5.0.1 basé sur la technologie Scenari 6.2.

Cette version apporte quelques corrections dont :

• Une correction dans les étapes de quiz à cumul de score.
• Une meilleure prise en compte des enchaînements des étapes de quiz dans la publication PDF et l’écran de contrôle du .case.

Topaze est disponible dans cinq langues : français, anglais, portugais, italien, arabe !
C’est la première version disponible en arabe. Grand merci à la communauté qui a travaillé sur la traduction, emmenée par Mohammadine Chakht.

✨ Le savais-tu ?
Si tu réalises un habillage avec le mode formulaire de ScenariStyler, et que tu as besoin de modifier des choses que le mode formulaire ne permet pas, tu peux facilement passer au mode guidé sans perdre tes modifications.
Pour cela il faut cliquer sur le menu de trois points dans l’entête de la zone d’édition > convertir > habillage guidé.

Attention, selon les habillages, il peut y avoir des actions supplémentaires à faire. Plus de détails sur cette vidéo tutoriel.

🦋 Scenari présent dans…

• Université Toulouse Capitole a envoyé une note de presse annonçant la tenue des Rencontres Scenari.
• Le réseau #BlueHats a annoncé les Rencontres dans sa gazette.
• Le bimensuel régional « La Vie Économique du Sud-Ouest » a publié un article sur les Rencontres Scenari.

Il y a un nouveau venu parmi les logiciels de supervision : Argos Panoptès !

Loin de la complexité des Nagios, Centreon, Icinga et autres mastodontes qui font le café, Argos Panoptès (on l’appellera Argos dans la suite de ce texte) ne surveille que des sites web, ce qui lui permet d’être bien plus simple et léger.

Argos a été développé par Alexis Métaireau pour Framasoft dans le cadre de Framaspace (du Nextcloud fourni gracieusement par Framasoft aux associations et collectifs militants).
Framasoft a fait appel à un prestataire, faute de temps disponible pour développer nous-même l’outil.

Sommaire

• Le nom
• Le cahier des charges
• Le code
• Le fonctionnement en production
• Le futur
• One more thing

Pourquoi cet outil ? Lorsque l'on prévoit de créer plein d’espace Nextcloud, il semble pertinent de les surveiller.
Et comme Framasoft prévoit de déployer jusqu’à 10 000 espaces, il fallait quelque chose qui tienne la route… ce que le Shinken de l’association ne permettait pas : trop de sondes à exécuter, trop peu de temps pour le faire et on se retrouve avec des coups de sondes pas assez fréquents, laissant les sites avec des problèmes avec de trop longs délais de détection.

Sans compter que Shinken est en Python 2, qui est obsolète depuis déjà bien longtemps.

Le passage à une nouvelle solution de supervision complète (nous lorgnons sur Icinga) étant trop chronophage pour le temps que nous avons à lui consacrer pour l’instant, nous avons préféré partir sur une solution de surveillance de sites web, suivant l’adage UNIX « un logiciel qui fait une seule chose, mais qui la fait bien ».

Mais enfin, y a déjà des outils pour ça !

Bien sûr ! Nous avons testé statping-ng et Uptime Kuma mais avec nos très nombreux sites à surveiller, cela les mettait à genoux… ou alors c’est le navigateur qui ne tenait pas : ces deux solutions affichent sur la page d’accueil l’état de tous les sites à surveiller, et avec un historique de leur état en plus. Lorsque l'on veut surveiller des centaines de sites avec au moins trois coups de sondes chacun (un pour vérifier que le site HTTP redirige bien vers la version sécurisée, un pour vérifier que la version sécurisée répond bien, et un pour vérifier l’expiration du certificat du site), ça fait énormément d’appels AJAX au serveur quand on consulte le site et soit c’est le serveur qui a du mal, soit c’est le navigateur qui peine.

Ainsi est née l’idée du développement d’une solution qui remplisse notre cahier des charges

Le nom

Argos Panoptès fait référence au géant aux cent yeux de l’antiquité grecque, « Panoptès » signifiant « celui qui voit tout ».

Le cahier des charges

Il était simple mais toutefois complet, rédigé par votre serviteur (étant adminSys et développant aussi, j’avais mon idée sur ce que je voulais déployer et ce que j’aurais voulu coder moi-même) :

• un langage simple, qui peut attirer du monde pour les contributions : Python ;
• un langage moderne : la cible était Python 3.11, à savoir la version de Debian Bookworm ;
• le support d’une base de donnée robuste : PostgreSQL ;
• une architecture agents / serveur, permettant d’ajouter des agents pour les coups de sondes au fur et à mesure de l’augmentation des besoins. Ceci pour éviter le goulot d’étranglement constaté sur Shinken (l’ajout de plus d’agents Shinken n’étant pas possible puisque Python2) ;
• une configuration simple et automatisable : l’infrastructure de Framasoft étant gérée via Salt, de même que la configuration des sondes de Shinken, il était vital de pouvoir créer la configuration des sites à surveiller de façon programmatique. Le YAML fut choisi pour cela ainsi que pour sa simplicité de lecture par un humain ;
• divers moyens de notifications, courriel et Gotify a minima.

Le code

Le code d’Argos est sur la forge logicielle de Framasoft : https://framagit.org/framasoft/framaspace/argos/.

Une suite de tests est exécutée en intégration continue, ainsi que du linting, ce qui permet d’éviter autant que possible les régressions et de maintenir un style de code uniforme.

Pour les dépendances, rien d’exotique (et c’est tant mieux !) :

• Click pour l'interface en ligne de commande ;
• FastAPI est le cadriciel qui nous permet d'exposer l'API HTTP ;
• HTTPX est utilisé pour émettre des requêtes asynchrones dans les agents ;
• Jinja gère la mise en page ;
• Pydantic est utile pour s'assurer que les données correspondent à nos attentes ;
• SQLAlchemy est l'ORM que nous utilisons pour nous connecter à notre base de données et lancer des requêtes ;
• Alembic est utilisé pour les migrations de bases de données ;
• Tenacity un petit utilitaire pour réessayer une fonction en cas d'erreur ;
• Uvicorn est l'outil utilisé pour faire tourner notre serveur ;
• Gunicorn est le serveur WSGI HTTP recommandé pour la production.

Pour aider les potentiels contributeurs, une partie du site officiel est dédiée au développement.

L’API d’Argos est auto-documentée : en installant Argos, vous aurez des pages de documentation aux formats Swagger et Redoc.

Le fonctionnement en production

Si Argos a été annoncé sur le Framablog mi-mai 2024, cela faisait déjà plusieurs mois que la version de développement était en production.

Le moins qu’on puisse dire, c’est qu’Argos tient ses promesses ! Il est rapide… très rapide !

Lors du dernier démarrage à vide d’une version de développement, Argos a lancé ses 2145 tests configurés à une vitesse impressionnante : il ne lui a fallu qu’une minute et 15 secondes pour tous les effectuer.

L’API présentant un point permettant de connaître le nombre de sondes dans chaque état (les classiques ok, warning, critical et unknown), nous avons ajouté une sonde à notre Shinken pour intégrer les résultats d’Argos dans celui-ci.

En effet, avoir un outil dédié, c’est sympa, mais si ça fait une page web de plus à consulter, c’est enquiquinant. La centralisation de la supervision au sein de Shinken permet de contourner ce problème.

Le futur

Depuis la première version et une version de micro-changements, la majeure partie des modifications s’est concentrée sur l’amélioration de la documentation, ainsi que sur la simplification de la configuration et de l’installation.

Quelques nouvelles fonctionnalités seront de la partie, réduisant quelques frictions rencontrées depuis la mise en production de la dernière version.

Les contributions sont les bienvenues (peut-être quelqu’un intégrera-t-il les notifications via Apprise ?) 😉

One more thing

Framasoft est actuellement en pleine campagne de collecte de fonds dans le cadre de la démarche de soin de nos services en ligne « Dorlotons Dégooglisons » (mais ça, vous le saviez peut-être déjà).

Merci de nous soutenir si vous le pouvez ! 🙂

La 11ᵉ édition de Kernel Recipes aura lieu du 23 au 25 septembre 2024, à la Fondation Biermans Lapôtre, à Paris.

Nous entamons la deuxième décennie de la conférence, avec toujours autant de plaisir à organiser et réunir orateurs et participants pour trois jours de convivialité et d’échanges.

Notre parrain cette année est Arnaldo CARVALHO DE MELO (acme), contributeur au noyau. Il nous a accompagné d’une main de chef sur la préparation de l’agenda 2024.

Encore une très belle affiche qui nous l’espérons vous plaira, dans la salle, lors du live stream ou des vidéos en ligne plus tard : Maira CANAL, Himadri SPANDYA, Jose MARCHESI, Anel ORAZGALIYEVA, David VERNET, Steven ROSTEDT, Andrea RIGHI, Greg KH, Neeraj UPADHYAY, Paul MCKENNEY, Andrii NAKRYIKO, Pavel BEGUNKOV, Jens AXBOE, Breno LEITAO, Vlastimil BABKA, Arnaldo CARVALHO DE MELO, Sebastian ANDRZEJ, Derek BARBOSA, Guilherme AMADIO…

Également présents, Frank TIZZONI pour saisir au vol de manière impitoyable les participants et les orateurs et Anisse ASTIER qui proposera à nouveau son excellent live blog.

Enfin un immense merci aux sponsors qui nous supportent à nouveau cette année et rendent possible cette conférence : la fondation eBPF, ARM, AMD, Collabora, Meta, Haproxy, Jumptrading, Criteo engineering, Igalia, Cyberzen

La gestion du son et des images sera proposée par Uweti.

Le festival Pas Sage En Seine (société, internet, liberté) a eu du 31 mai au 2 juin 2024. Les vidéos ont été publiées (annonce des vidéos April).

L'April a publié treize transcriptions au mois de mai 2024, ce qui correspond à dix heures et trois minutes d’enregistrements audio ou de vidéos.

La « conférence pour l'éthique et la diversité dans la tech avec des crêpes et du cœur » MiXiT a eu lieu en avril. Les vidéos ont été publiées (une sélection par Frédéric Couchet).

L'OW2con 2024 a eu lieu les 11 et 12 juin 2024. Les vidéos ne sont pas encore disponibles (voir celles de 2023). Mise à jour : les vidéos 2024 sont désormais disponibles

210ème émission « Libre à vous ! » de l’April. Podcast et programme :

• Sujet principal : « Au cœur de l’April ». Échange avec Vincent Calame et Isabella Vanni autour du choix des musiques libres et à propos de la nouvelle base de données pour les référencer. Discussion avec Julie Chaumard, membre de l’équipe « Libre à vous ! », et notamment de la régie. Discussion avec Laurent Costy, autour de la tribune « Techsoup : instrument d’influence des big tech américaines ». Et un échange avec Françoise Conil, nouvelle membre élue du conseil d’administration de l’April.
• La chronique « Pépite Libre » de Jean-Christophe Becquet sur la base adresses : « 35 000 BAL pour répondre à une question essentielle : où suis-je et où vais-je ? »
• « Transformer le numérique », troisième conférence du triptyque de Louis Derrac » : une chronique de Marie-Odile Morandi lue par Laure-Élise Deniel

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

La prochaine émission sera diffusée mardi 18 juin à 15h30, nous vous donnons rendez-vous « Au café libre », pour discuter des actualités autour du logiciel libre.

La conférence OW2con a récompensé trois projets de la communauté OW2 :

• catégorie communauté (Community Award) : Mercator, pour la cartographie du système d’information
• catégorie performance sur le marché (Market Award) : WIdaaS, pour la gestion d’identité et d’accès
• catégorie technologie (Technology Award) : Centreon, pour la supervision

Mercator

Le prix OW2con'24 Best Project Community Award est remis à MERCATOR. Cette application web procure une cartographie du système d'information et suit les recommandations de l’ANSSI précisées dans son "Guide de la cartographie du système d'information". L’application permet une approche globale de la gestion des risques, autorisant une protection et une défense complètes ainsi qu’une résilience du système d'information. La cartographie du S.I. est un outil essentiel à sa maîtrise. Elle constitue une obligation pour les Opérateurs d'Importance Vitale (OIV) et les opérateurs de services essentiels (OSE).

WIdaaS

Le prix OW2con'24 Best Project Market Award revient à W'IdaaS (Worteks IDentity as a Service, l’identité comme service par Worteks), un logiciel de gestion d’identités et d’accès, en mode Cloud, accessible via des interfaces Web et piloté par des API REST. Ce programme s’appuie sur le projet OW2 FusionIAM, et gère l’authentification multi-facteurs (2FA/MFA). Ses fonctionnalités et son modèle économique correspondent aux attentes actuelles du marché des entreprises et des collectivités territoriales.

Centreon

Centreon est une plateforme de supervision ouverte, extensible et facile à intégrer, pour superviser de bout en bout des infrastructures d’entreprise. La solution est interopérable avec ITSM (information technology service management, voir ITIL), les outils d’observabilité, d’analyse de données, d’orchestration et d’automatisation.

Le mot d’OW2

(NdM: deux dépêches ont été proposées et fusionnées)

“Cette année, l’association OW2 est ravie de récompenser trois logiciels open source pouvant aider les entreprises à protéger l’ensemble de leur patrimoine numérique et à conserver la maîtrise de leurs infrastructures en interne, en périphérie et dans le cloud. Centreon, W’IDaaS et Mercator méritent leur prix pour leur ouverture aux solutions tierces, leurs fonctionnalités, leur ergonomie et leur modèle économique,” déclare le CEO d'OW2 Pierre-Yves Gibello.

Les prix OW2con’24 Best Project Awards distinguent des réalisations exemplaires. Ils apportent aux membres d’OW2, aux chefs de projet et à leurs équipes une distinction communautaire et des opportunités de visibilité sur le marché.

Le logiciel gratuit et illimité de généalogie Ancestris vient de sortie en version 12. Il est placé sous licence GPL.

La v12 en quelques chiffres : plus de 1700 commits, trois ans de développement, et elle fonctionne sur tous les systèmes d’exploitation qui permettent d’installer Java de la version 8 à la version 22.

Nouveautés, évolutions, corrections et traductions sont détaillées en seconde partie de dépêche.

Nouveautés

• Gestion du GEDCOM 7 (complet pour l’éditeur GEDCOM et l’éditeur Cygnus).
• Affiche toutes les entités (même les entités non conformes) dans l’explorateur de GEDCOM et dans l’éditeur GEDCOM.
• Nouvelle traduction en hongrois
• Enregistrer sous : copie exacte ou partielle
• Possibilité de choisir l’inhumation à la place de la date de décès pour les affichages.
• Ajout d’une option pour zoomer l’ensemble de l’application.
• Choix du répertoire de sauvegarde
• Imports spécifiques pour : Elie, Aldfaer, RootsMagic, Ancestry.com, Brother's Keeper
• Ajout d’un gestionnaire de média
• Ajout d'un convertisseur de GEDCOM
• Refonte du module de recherche de doublons
• Réécriture du rapport calendrier
• Réécriture du rapport narratif
• Réécriture du rapport circulaire 10 générations avec sortie SVG.
• Ajout d’un rapport de ligne de vie individuel.
• Ajout d’un tri des entités à la sauvegarde et la possibilité de trier les propriétés d’une entité par date.
• Possibilité de créer un nouveau GEDCOM directement à partir des entités affichées dans une vue (Arbre, Graphe, time-line, Carte, Recherche, Groupes de famille)
• Réécriture du module de groupes familiaux avec nouvelles fonctionnalités (marquage, regroupements…)
• Ajout d’une possibilité d’ignorer les vérifications automatiques.
• Nouveau calcul de consanguinité et détection de boucles.
• Ajout d’une liste de dépôts d’archives par défaut.
• Export pour Genealogieonline.nl

Évolutions et corrections

• Ajout d’un symbole pour les divorces dans l’arbre graphique
• Améliorations de Cygnus
• Améliorations d’Ariès
• Amélioration de l’éditeur GEDCOM
• Améliorations du module d’ancêtres communs
• Ouverture d’un nouveau fichier provenant d’Ancestris sur le SOSA 1
• Ajout par défaut du tag FILE des entités médias dans la table des entités
• Conserve l’ordre de tri dans les écrans de recherche d’Ariès
• Recherche sans accents
• Correction du tutoriel de présentation s’il y a plusieurs écrans.
• Ajout de la recherche par époux dans la recherche avancée
• Ajout du marquage par chromosome X
• Amélioration de l’exploitation des liens des médias dans les éditeurs.
• Amélioration de l’import Geneanet, geneatique et Heredis
• Améliorations de l’export Livre Web
• Améliorations de l’export Site Web
• Tri sur les dates dans la table des entités
• Ajout de séparateurs pour la gestion des marque-pages
• Améliorations et corrections de la carte géographique
• Ajout de filtres dans la vue graphe
• Permet de choisir une date de changement dans l’explorateur pour ne voir que les modifications postérieures.
• Améliorations du rapport d’arbre graphique multi-génération
• Améliore l’ouverture de fichier pour détecter et expliquer au mieux les problèmes rencontrés.
• Améliorations de l’export Geneanet
• Ajout d’un bouton de remise aux valeurs par défaut pour les réglages de la table des entités.
• Affichage de la première page des pdf à la place d’une image neutre.
• Conservation des options d’enregistrement d’un fichier d’une fois à l’autre.
• Ajout de l’impression de la vue en cours dans le menu « Outils ».
• Affiche les images de type JFIF
• Amélioration de la vue graphe sur les écrans à large résolution
• Possibilité de marquer les individus à partir de toutes les vues.
• Améliorations du module Relevé
• Ajout d’une préférence de durée maximale d’attente pour la vérification des liens internet
• Ajout d’icônes pour distinguer l’ajout d’une numérotation de l’affichage du Sosa 1.
• Correction de l’affichage en langue différente des rapports par rapport à l’interface.
• Utilisation des options des rapports avant de les lancer à partir du menu contextuel.
• Ajout d’un écran d’assistant pour la comparaison de généalogies.
• Possibilité de choisir le nombre de génération d’ascendants et de descendants séparément dans l’arbre dynamique.
• Ajout d’un nouveau template GedArt.
• Ajout d’un dégradé par date dans la carte géographique
• Ajout d’un paramètre pour limiter la longueur d’un champ dans un calque.
• Ajout d’un menu avec les derniers fichiers ouverts
• Ajout de la possibilité de souligner des champs dans les calques.
• Amélioration de la gestion des almanachs.

Mise à jour de traduction

• Allemand
• Anglais
• Castillan
• Catalan
• Danois
• Français
• Grec
• Hongrois
• Italien
• Néerlandais
• Polonais
• Portugais
• Tchèque
• Turc

Merci à tous les traducteurs pour leur travail constant, si important pour l’ensemble de la communauté.

Pour conclure, merci à toute la communauté par vos remarques, vos demandes, vos remontées d’anomalies, vous permettez de faire vivre et embellir ce logiciel.
On compte sur vous dans la suite pour nous créer du buzz, des tutoriels, des idées et de l’enthousiasme.

Cloonix est un outil d’aide à la construction de réseau virtuel. Il est basé sur Open vSwitch pour l’émulation du réseau constitué de switchs et LANs virtuels, sur crun et les namespaces pour la gestion de conteneurs et sur KVM pour ce qui concerne l’émulation des machines complètes.
Cloonix peut être considéré comme un hyperviseur qui permet de lancer des scénarios de démonstration impliquant des réseaux connectant de nombreuses machines virtuelles ou conteneurs. Ce logiciel open source permet d’automatiser et de rejouer des scénarios complets.

FRR est le logiciel open source qui permet de transformer une machine Linux en l’équivalent d’un routeur professionnel, ce logiciel implémente tous les protocoles de routage classique.

Podman est exactement comme Docker, un gestionnaire de conteneur.

Le but de cette dépêche est de présenter une démonstration qui tourne dans un podman et qui met en œuvre un réseau d’une soixantaine de conteneurs et qui peut être lancé en tant qu’utilisateur simple sans les droits root.

Il y a le lien « demo » qui montre une vidéo un peu accélérée de cette démonstration qui démarre les machines, les configure et les met en réseau. On peut ensuite y voir la convergence du protocole OSPF.

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

Exemples

TuxRun propose une interface en ligne de commande simple pour exécuter un noyau dans QEMU. TuxRun se charge de fournir un environnement suffisant pour démarrer le noyau avec QEMU.

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image

TuxRun va alors télécharger le noyau et un système de fichier compatible avec ARM64 puis lancer qemu-system-arm64 avec les bons arguments et afficher les logs du boot.

La ligne de commande de qemu générée par TuxRun est la suivante :

/usr/bin/qemu-system-aarch64 \
    -cpu max,pauth-impdef=on \
    -machine virt,virtualization=on,gic-version=3,mte=on \
    -nographic -nic none -m 4G -monitor none -no-reboot -smp 2 \
    -kernel /.../Image \
    -append "console=ttyAMA0,115200 rootwait root=/dev/vda debug verbose console_msg_format=syslog systemd.log_level=warning earlycon" \
    -drive file=/.../rootfs.ext4,if=none,format=raw,id=hd0 \
    -device virtio-blk-device,drive=hd0

Il est également possible de lancer une suite de tests directement depuis la ligne de commande :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke

Les résultats de la suite de test seront analysés par TuxRun et la valeur de retour de TuxRun sera 0 uniquement si la suite de tests passe intégralement. Ceci permet d’utiliser TuxRun pour valider qu’une suite de tests donnée fonctionne toujours correctement sur un nouveau noyau.

Architectures

QEMU

Grâce à QEMU, TuxRun supporte de nombreuses architectures:
- ARM: v5/v7/v7be/64/64be
- Intel/AMD: i386/x86_64
- MIPS: 32/32el/64/64el
- PPC: 32/64/64le
- RISCV: 32/64
- sh4, sparc64, …

La liste complète est disponible dans la documentation.

FVP

Il est également possible d’utiliser FVP, le simulateur de ARM pour simuler un processeur ARMv9. FVP est un simulateur bien plus précis que QEMU au prix d’un temps d’exécution bien supérieur.

FVP permettant de configurer et simuler de nombreux composants du processeur, TuxRun propose une configuration permettant de démarrer et tester Linux dans un temps raisonnable.

tuxrun --device fvp-aemva \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke \
       --image tuxrun:fvp

ARM ne permettant pas (pour le moment) de redistribuer les binaires FVP, il faut construire localement le container tuxrun:fvp.

Système de fichiers

Par défaut, TuxRun télécharge et utilise un système de fichier compatible avec l’architecture cible. TuxRun fournit donc 20 systèmes de fichiers différents, un pour chaque architecture disponible.

Ces systèmes de fichiers sont basés sur buildroot et comportent les outils nécessaires pour faire tourner la majorité des suites de tests supportés par TuxRun. La liste complète est disponible dans la documentation.

Il est également possible d’utiliser un autre système de fichiers :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/Image \
       --rootfs https://example.com/rootfs.ext4.zst

Runtimes

TuxRun télécharge et utilise un container que nous maintenons. Ce container inclut l’ensemble des binaires nécessaires ainsi que QEMU. Par défaut, TuxRun utilise toujours la dernière version du container disponible.

Il est cependant possible de spécifier une version particulière afin de reproduire plus facilement une erreur. Les nouvelles versions de QEMU introduisent quelques fois des régressions dans les suites de tests. Il est alors nécessaire d’utiliser exactement la même image pour reproduire le problème.

Reproduire un test

TuxRun est utilisé, via tuxsuite notre service de compilation et de test dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir la ligne de commande TuxRun pointant sur les artefacts utilisés pour pouvoir reproduire le problème.

Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. TuxRun simplifie ainsi énormément la reproduction du test.

Un exemple parmi tant d’autres : selftests: sigaltstack: sas…

Installation

TuxRun étant un programme Python, il est possible de l’installer depuis pypi :

python3 -m pip install tuxrun

Nous fournissons également un paquet Debian, et un rpm.

TuxMake et Tuxrun

Dans un prochain article, je vous montrerai comment combiner TuxMake et TuxRun pour automatiquement trouver le commit responsable de la régression dans le noyau.

La version 4.5.0 de Passbolt, baptisée « Summer is Ending », vient de sortir. Elle introduit des fonctionnalités clés et des améliorations pour optimiser la gestion des mots de passe et de leurs cycles de vie de manière sécurisée et collaborative.

Pour mémoire, Passbolt est un gestionnaire de mots de passe Opensource, sous licence AGPL, qui se veut orienté «équipe», avec notamment des possibilités de partage de mot de passe à des personnes ou des groupes.

Nouvelles fonctionnalités

Gestion de l’expiration des mots de passe

Cette nouvelle fonctionnalité permet la gestion et le traçage des mots de passes expirés.
Un mot de passe partagé, ayant été consommé par un utilisateur, expire automatiquement quand l’accès de cet utilisateur a été révoqué. Vous pouvez en savoir plus sur l’article de blog dédié à ce sujet (en).

Support du Russe

Suite à une contribution communautaire, passbolt est maintenant disponible en langue Russe, ce qui amène le total des langues supportées à 14. Un énorme merci à notre communauté pour ses contributions de plus en plus fréquentes.

Intégration de Microsoft 365 et Outlook dans les paramètres SMTP

Enfin, les paramètres SMTP ont été améliorés afin de permettre un meilleur support de Microsoft 365 et de Outlook.

En savoir plus sur la version 4.5.0

Pour en savoir plus et mettre à jour vers passbolt 4.5.0, consultez les notes de version (en).

L'initiative Libre en Fête de l'April revient pour la 23ème année consécutive : pour accompagner l'arrivée du printemps, des événements de découverte du logiciel libre et de la culture libre en général seront proposés partout en France autour du 20 mars 2024, dans une dynamique conviviale et festive.

Le Libre en Fête

À l’occasion du Libre en Fête, tous les groupes d’utilisateurs et utilisatrices de logiciels libres (GULL), les espaces publics numériques (EPN), les bibliothèques et médiathèques, les clubs informatiques, les fablabs et hackerspaces, et toute autre organisation ayant à cœur la promotion du logiciel libre et de la culture libre en général sont invitées à organiser des évènements à destination du grand public. Le site du Libre en Fête donne toutes les informations nécessaires pour participer à l’initiative.

Organiser un événement

Les événements organisés dans le cadre du Libre en Fête peuvent prendre de multiples formes : conférence de découverte, atelier d’initiation - à un logiciel libre, à un service en ligne libre ou à un projet collaboratif dérivé des principes du Logiciel Libre comme Wikipédia ou OpenStreetMap -, fête d’installation, exposition de panneaux sur le logiciel libre comme l'Expolibre, diffusion de vidéos ou films sur le logiciel libre, mise à disposition de postes informatiques sous logiciel libre, de jeux vidéos libres, etc. Bien sûr, il est possible de proposer plusieurs activités au sein d’une même journée de découverte. Et si vous prévoyez un fond musical, pensez à diffuser des titres sous licence libre - vous pouvez regarder du côté de la playlist de l’émission de radio de l’April Libre à vous !.

La coopération entre différentes organisations au niveau local est vivement encouragée. Les groupes d’utilisateurs et utilisatrices de Logiciels Libres (GULL) peuvent notamment être sollicités en raison de leurs connaissances et de leur expertise en matière de Logiciel Libre. D’autres structures peuvent mettre à disposition d’autres ressources telles que les locaux, le matériel informatique et multimédia, voire des compétences en communication et/ou animation. Ainsi, le Libre en Fête, c’est aussi l’occasion de nouer de nouveaux partenariats et/ou de renforcer des liens existants. Des liens utiles pour la recherche de partenaires sont disponibles sur le site de l’initiative.

N’hésitez pas à utiliser et personnaliser les visuels (logos, bannières, affiche…) disponibles sur le site du Libre en Fête pour votre communication.

Référencer son événement

Le référencement d’un événement dans le cadre du Libre en Fête se déroule au travers du site de l’Agenda du Libre, en ajoutant le mot-clé libre-en-fete-2024 (sans accent) lors de sa soumission. Votre événement apparaîtra alors automatiquement sur le site du Libre en Fête.

Proposer un événement pour le Libre en Fête 2024

Liste de discussion et contact

Une liste de diffusion a été mise en place pour que les organisations participant à l’initiative puissent échanger leurs expériences et idées. L’inscription à cette liste est libre.

Pour toute question sur le Libre en Fête, vous pouvez contacter l’équipe de coordination.

Faites circuler cette annonce, merci !

Cent quatre-vingt-seizième émission « Libre à vous ! » de l’April. Podcast et programme :
- sujet principal : Parcours libriste avec Anca Luca (XWiki, Open Food Facts) ;
- chronique de Jean-Christophe Becquet, vice-président de l’April, sur « Markdown & vous » ;
- chronique de Gee sur « Mickey dans le domaine public ».

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

Depuis 2006, le LibreGraphicsMeeting réuni une fois par an divers équipes et utilisateurs avancés des logiciels de créations graphiques. Nous parlons ici de Gimp, Krita, Inkscape, Scribus pour les équipes les plus régulières mais d’autres projets viennent régulièrement contribuer au groupe ou se faire connaître, présenter des projets moins visibles, plus ciblés voire des bibliothèques d’outils. Le but de ces rencontres est multiple : permettre aux contributeurs de se retrouver une fois l’an pour définir des objectifs annuels, définir des stratégies interlogicielles afin de favoriser l’interopérabilité comme cela a pu être le cas avec la création de format comme le OpenRaster…

Les effets du LibreGraphicsMeeting ont été importants dans le workflow de la création graphique mais cela n’est pas fini car le domaine évolue beaucoup en termes de besoin mais aussi en termes d’application avec de nouvelles pratiques et de nouvelles priorités.

2024 signe le retour du LibreGraphicsMeeting en présentiel, ce qui était l’objectif initial. Il se déroulera à Rennes du 9 au 12 mai dans les locaux d’Activdesign et sera organisé cette année par l’Association francophone des graphistes libres (AFGRAL) en remplacement du Grafik Labor avant de reprendre éventuellement sa mobilité internationale.

S’agissant d’une édition de reprise, l’objectif est de pouvoir faire un point sur les évolutions et nouveautés de ces dernières années par des conférences, et de permettre les rencontres lors d’atelier ou réunions de travail. Si vous souhaitez participer au LGM, n’hésitez pas à proposer une conférence avant le 2 février 2024, après quoi le comité de programmation se réunira.