Ah, la ligne de pêche Maginot commande ! Que ce soit pour gérer ses fichiers, récupérer des commits, lancer une compilation, se connecter à un serveur, redémarrer un service, consulter les logs, voire contrôler la musique, afficher des images, cette interface reste en 2025 exceptionnellement boomer rapide et même parfois confortable.

Sans compter que le terminal est l'endroit où lancer des applications dédiées, pour lire ses mails ou un million d'autres choses.

Bref rappel avant se lancer dans de longues comparaisons

• TTY vient de teletypewriter. Si vous tapez (Xorg comme Wayland) Control + Alt + F3 par exemple, vous vous retrouverez devant une invite de commande.
• pts/pty : quand vous ouvrez un terminal

L'invite de commande pourra bénéficier d'un shell personnalisé. Le bureau permettra l'usage d'un terminal.

Sommaire

• Le jeu de les shells
  • De la préhistoire au Bash
  • ZSH
  • FISH
• Ravissant multiplex, 200 mètres carrés
• Envolez-vous vers un nouveau terminal
  • La console sur le bureau
    • Console (GNOME)
    • Konsole
    • xfce-terminal
    • Terminology
  • Emacs et (Neo)Vim
    • Emacs
    • Vim
  • Les indies
    • Blackbox
    • Ptyxis
    • St
    • Kitty
    • Alacritty
    • Foot
    • Wezterm
    • Ghostty
    • Rio
    • Warp
    • WaveTerm
• 3. Liens

Le jeu de les shells

Le shell est un interpréteur de commande. On peut simplement lancer une commande pour consulter l'état du système (top, ps), déplacer un fichier (mv), … Ou combiner des commandes, écrire des scripts basés sur des conditions et des variables, … Donc comme l'explicite le manuel GNU, un shell unix est la fois un interpréteur de commande et un langage de programmation.

La plupart des distributions utilisent par défaut "Bash", mais il est possible de changer de shell, par exemple interactivement en utilisant la commande chsh ("change shell"), ou en modifiant les paramètres d'un terminal en particulier, ou d'un multiplexeur, ou encore plus globalement en modifiant le shell par défaut d'un user (faites un peu attention dans ce cas — les shells ne sont pas tous compatibles, ne tombez pas !).

Les scripts précisent aussi quel shell invoquer… Si je prends un tuto sur un shell au hasard, voici ce que je vais trouver

#!/bin/bash
# This script will take an animated GIF and delete every other frame
# Accepts two parameters: input file and output file
# Usage: ./<scriptfilename> input.gif output.gif

Attention : ce script référence explicitement /bin . Pas 100% sûr que bash y soit installé. Une solution peut être d'utiliser env.

#!/usr/bin/env bash

Hormis interpréter les commandes tapées, le shell affiche également un prompt invitant à taper une commande. Quelque chose comme cela :

[goat@arch:~]$ 

Pour la partie prompt, certains shells vont autoriser un peu de paramétrage, ou l'on peut même installer des plugins pour enrichir les possibilités, comme avec powerline ou même le liquid prompt présenté ici même par son auteur Dolmden.

On peut aussi trouver un prompt comme starship qui est utilisable avec les différents shells.

De la préhistoire au Bash

Pour l'histoire, le premier shell Unix date de 1971, puis le Bourne Shell (sh), du nom de son auteur, apparait en 1977. Beaucoup de fonctionnalités sont déjà présentes : il est scriptable (on peut définir un script avec des conditions dont la si laide esac, définir des boucles, …), les processus peuvent être contrôlés, il est possible de définir des alias, …

Bourne Shell implémente la norme POSIX que d'autres shells respectent. La licence du Bourne Shell est débatue (avec une certaine vigueur sur Wikipédia!) , en tout cas son code est ici.

KORN shell n'était, au départ, pas open source - le code n'est libéré que dans les années 2000. Korn Shell implémente les fonctionnalités du Bourne Shell mais ajoutera d'autres éléments, comme des raccourcis vi/emacs, ou comme les tableaux

$ typeset -A age
$ age[bob]=42
$ age[alice]=31
$ print ${age[bob]}
42

GNU BASH : /bin/bash

B.A.S.H. = Bourne Again Shell (superbe jeu de mots avec Born Again Shell). Bash implémente la norme POSIX… et un peu plus.

GNU bash connait une première release en 1989. Il reprendra à son compte des fonctionnalités trouvées jusqu'ici dans de précédents shells, y compris Korn Shell. Bash reste le shell interactif par défaut sur de nombreuses distributions. Il fut le shell sous MacOS.

Anecdote - quel est le plus gros programme bash que vous connaissiez ? nb, qui propose de gérer vos notes en mode texte (org, markdown, etc), est principalement composé d'un script .sh de … 26736 lignes. Je vous laisse partager vos trouvailles en commentaire !

DASH : le Debian Almquist shell est renommé ainsi en 1997. Debian l'adopte par défaut pour les scripts, tandis que le shell interactif des utilisateurs reste bash. Ubuntu y passe par défaut sur la 6.10. Dash est léger et performant. Moins de dépendances égal plus de sécurité.

ZSH

ZSH sort en 1990. Toujours compatible avec la norme POSIX, Zsh va améliorer de bien pratiques fonctionnalités d'auto-complétion : appuyez sur <TAB> et Zsh complète pour vous.

Mais bien plus largement, Zsh va atteindre le paroxysme en terme de fonctionnalités. Tout existe dans Zsh.

Zsh est connu pour proposer de très nombreuses possibilités de configuration. Ses plugins se comptent par centaine — y compris plusieurs gestionnaires de plugins… Mais un outil très utilisé pour le configurer sort du lot : Oh my zsh, qui permet de gérer plus de 300 plugins ainsi que de nombreux thèmes.

FISH

Fish pour "Friendly Interactive Shell", date de 2005. C'est un shell non POSIX - certaines fonctionnalités ne seront pas compatibles. Un script bash ne marchera pas forcément.

Ce shell se veut demander peu de configuration - il est prêt à l'emploi. Choix appréciable quand on peut déjà passer tant de temps à configurer d'autres choses (distro, bureaux, nano, terminaux..)  !

Il suffit de l'installer pour avoir

• une coloration syntaxique indiquant quelle commande est valide
• suggestions : en tapant, on obtient des candidats que l'on peut auto-compléter

Fish est également scriptable et se veut proposer un syntaxe plus saine. À vous de tester (mais vous ne codez qu'en Rust, n'est-ce pas ?)

Le gros point de Fish à mon sens, c'est de proposer une configuration par défaut déjà utilisable, comme le fait de se baser sur les pages man ainsi que sur l'historique pour proposer l'auto-complétion. Oubliez les heures passées à configurer - je ne sais pas si Fish a le plus de chevaux dans le moteur, mais avec lui vous êtes déjà prêts à partir.

Petite fonctionnalité sympa, taper fish_config ouvre une page ouaibe. On peut alors prévisualiser les thèmes, personnaliser le prompt, visualiser les fonctions et variables, consulter l'historique et les raccourcis claviers. Fish a un mode vi.

Fish a été réécrit en Rust entre 2022 et 2024.

Ravissant multiplex, 200 mètres carrés

Ok donc nous avons un shell à choisir, y compris le prompt et il faudra le lancer dans un terminal, mais avant ça, si on avait un gestionnaire de fenêtre dans le gestionnaire de fenêtre ? C'est bien comme cela qu'est présenté GNU Screen, qui gère des fenêtres, typiquement de terminaux. C'est un multiplexeur, en français : la possibilité d'ouvrir plusieurs terminaux dans un seul terminal. GNU Screen sait lister les terminaux ouverts, passer de l'un à l'autre, en tuer… Comme souvent, le wiki arch détaille bien notre affaire concernant screen. Mais GNU Screen est un vieux de la vieille, qui date de 1987.

Plus souvent cité de nos jours, Tmux (2007) propose des raccourcis à la Emacs ou à la Vim, un menu graphique, des splits verticaux ou horizontaux.

Il existe d'autres multiplexeurs. On peut citer par ex. Zellij, orienté développeurs, qui affiche une barre de statut, peut afficher les raccourcis claviers…

Envolez-vous vers un nouveau terminal

Le choix d'un terminal pourra définir l'apparence de votre interface, comment vous gérez le multi-fenêtre et/ou multi-onglet, la capacité à rechercher, copier-coller, les raccourcis clavier, peut être même comment accéder aux emplacements, vous connecter en ssh.

Certains terminaux proposent un mode inspiré de Guake (première release 2007), lui même inspiré du terminal dans Quake : le terminal est toujours ouvert et dispo, mais caché et l'appui d'un raccourci clavier le fera apparaître. Le temps de taper trois commandes et le même raccourci le fera disparaître. À voir ce qui se fait encore sous Wayland, je vois par ex. qu'il y a encore une extension GNOME.

La console sur le bureau

Première piste : tout simplement utiliser la terminal qui vient avec son bureau, si l'on en utilise un. Évidemment le premier avantage sera une bonne intégration, mais en pratique ?

Nous verrons aussi plus bas certains terminaux qui sont le terminal par défaut de gestionnaires de fenêtre, mais il s'agit simplement d'un choix par défaut et pas d'une affiliation ni d'une intégration particulière, donc pas de raison de les mentionner ici.

Console (GNOME)

Le terminal par défaut a changé sous GNOME 42 (euh bah oui c'était y'a un moment), pour devenir GNOME Console (anciennement Kings Cross Station d'où kgx — j'ai cherché l’exécutable un moment…). Assez peu de fonctions particulières mais : devient rouge lorsqu'on est connecté en root ou violet en ssh, envoie une notif quand une longue commande se termine, sympa. Un bouton de recherche un peu étonnant peut s'avérer pratique. Clairement la logique est d'afficher peu de boutons, peu de choix, et d'investir sur des options par défaut qui fonctionnent. Je ne vais pas retenir Console pour mon usage mais je trouve qu'effectivement c'est un terminal élégant.

Pour changer le shell de Console, il faudra passer par l'éditeur dconf et modifier l'option org.gnome.Console.shell.

Certaines distributions ont préféré maintenir gnome-terminal, plus complet, mais gnome-terminal est resté Gtk3 (alors que kgx est bien Gtk4).

Petite note sur kgx et gnome-terminal : ces terminaux sont basés sur la libvte dont dépendent d'autres terminaux GTK. Voici quelques exemple cités par une page du wiki gnome :

• Xfce terminal
• ROX terminal
• evilvte
• guake
• sakura
• terminator
• vala-terminal

On pourrait y ajouter Lxterminal (merci à Impromptux).

Konsole

Le choix logique pour le bureau KDE. En termes de fonctionnalités, c'est l'artillerie lourde. Multi-profils, signets, multiplexeur, prévisualisation d'images. Konsole est intégrée dans plusieurs applications KDE.

Pour changer le shell de Konsole, vous pouvez passer par le menu Settings > Configure Konsole > Profiles .

C'est le moment de mentionner Qtermwidget : ce widget fut originellement basé sur Konsole et servit à développer Qterminal.

xfce-terminal

Terminal par défaut du bureau Xfce. Il dépend et hérite de libvte. Il est en Gtk3.

• Permet plusieurs onglets
• Intégration avec un gestionnaire de fichiers (ouverture dans le répertoire courant du terminal)
• Prévention de collage dangereux : quand ça contient un retour chariot, ouvre une popup qui permet d’inspecter et modifier le contenu dangereux.
• Permet d’envoyer un signal au processus en cours
• Permet d’avoir une console rapide à la Guake
• Permet de colorer les onglets manuellement.

Il est possible de changer le shell dans les préférences.

Terminology

Ce terminal sort en 2013, il fait partie du bureau Enlightenment Je pense que c'est le premier terminal à pouvoir afficher des images. Il est possible d'avoir des informations en survolant une URL. Une barre de progression s'affiche durant l’exécution de commandes. Les performances sont au rendez-vous. (Subjectif - serait-ce tout simplement la meilleure appli e17?)

Emacs et (Neo)Vim

Mais plutôt que d'utiliser le terminal intégré à son environnement de bureau, pourquoi ne pas utiliser directement celui intégré à son éditeur de texte? Un bon éditeur de texte en effet a forcément son bon terminal. Même Vim? Et oui. C'est donc une solution de lancer le terminal depuis l'éditeur de texte, par exemple pour reproduire les fonctionnalité d'une IME vivre sa vie entière en mode texte.

Emacs

Démarrons tout de même par Emacs, où la prise en charge du terminal est plus ancienne.

Emacs a… 4 terminaux, pourquoi faire simple. 4 terminaux ? Non pas vraiment : 2 shell et 2 terminaux. Il peut y en avoir plus.
En fait, puisqu'on peut, malgré la rumeur, bel et bien éditer du texte dans emacs, pourquoi ne pas gérer ses commandes au même endroit ? On peut même s'amuser à gérer ses fichiers dans dired, ses processus, finalement un peu tout l'aspect système.

Mastering Emacs le développe mieux que moi mais vous aurez donc plusieurs possibilités sous Emacs :

2 SHELLS

• eshell, le plus emacsien des 2 : un shell 100% implémenté en elisp (!!!). On peut faire beaucoup de emacs dedans , mais tout ne fonctionnera pas. Ne lancez pas journalctl dedans ^^
  
• shell. Même chose, ne lancez pas journalctl…

2 TERMINAUX

• term / ansi-term. Cette fois c'est vraiment un terminal, mais… lent.
• vterm. Ok cette fois c'est vraiment un terminal, et ça utilise une bibliothèque en C derrière, donc ouf un vrai terminal Emacs existe bel et bien. Attention vterm a besoin d'une bibliothèque.

Oui je pense qu'il y a vraiment des utilisateurs du terminal sous Emacs. Et il est possible de trouver de petits benchmarks sur les réseaux comme par exemple reddit.

Vim

Qui a dit que vim n'était pas bloated et ne pouvait pas gérer cela? (À sa défense vim ne gère pas encore l'email.. ) Vim prend en charge le terminal depuis la version 8.1. Pour changer le shell dans vim, ajouter cette commande dans le fichier de config

:set shell=/usr/bin/zsh

Les indies

Pourquoi utiliser le terminal de son bureau, ou de son éditeur de texte, alors que l'on peut utiliser un million d'autres ? Bienvenue dans la jungle. Ne m'en voulez pas si votre petit favori n'est pas listé ici, mais rajoutez sa description en commentaire - il a existé de bien trop nombreux concurrents, et même en se limitant aux projets actifs la liste est bien trop longue. La liste ici pourrait compléter cette dépêche.

Je rappelle que sont listés ici les terminaux qui sont proposés par défaut sous certains gestionnaires de fenêtre, le parti pris étant que dans ce cas il n'y ait pas d'intégration particulière, contrairement par exemple au terminal KDE.

Enfin la liste se veut à moitié lister les terminaux populaires actuels, à moitié lister quelques terminaux plus pour un intérêt historique, mais cette dépêche n'étant pas une thèse cette volonté sera assez peu rigoureuse.

Blackbox

Blackbox terminal n'est pas affilié à GNOME ni un terminal officiel mais est développé avec cet environnement en tête. Il utilise Gtk4.

Ptyxis

Là c'est un cas à part : pour reprendre sans recul le readme.md :

A modern terminal emulator built for the container era.
Seamlessly navigate between your host system and local containers like Podman,
Toolbox, and Distrobox with intelligent detection and a beautiful, responsive
GNOME interface.

L'intérêt est donc d'intégrer les conteneurs de toutes sortes pour y accéder rapidement (et les définir rapidement).

Il semblerait qu'il puisse devenir le terminal par défaut sous Ubuntu (25.10?).

St

La philosophie de st, dont la première release, 0.1, est de 2017, c'est de rester simple et léger - le point que son site discute, c'est le nombre de lignes de codes limité que devrait avoir un terminal. Son auteur serait fainéant ? Ce terminal sous licence MIT/X Consortium s'apparente à mon sens à un reliquat du passé : il tourne sur X et uniquement sur X (oui, oui je sais pour Xwayland). Néanmoins il m'a paru logique de le citer ici.

Kitty

Kitty a une place importante car il a légué quelque chose aux successeurs… Il implémente en effet des extensions venant étendre le protocole historique.

Ce terminal tourne sous Python et requiert OpenGL. Malgré son âge (première release 2017), c'est le choix par défaut pour Hyprland.

Kitty offre une tonne de raccourcis claviers, gère les onglets/fenêtres, peut afficher des images, sait afficher des notifications et bien d'autres choses. En terme de philosophie, il se veut orienté power-user.

Alacritty

Alacritty se veut un terminal simple et est écrit en Rust. Il est sortit en 2017. Alacritty respecte XDG en cherchant en priorité un fichier de config $XDG_CONFIG_HOME/alacritty/alacritty.toml.

C'est le terminal par défaut pour au moins deux gestionnaires de fenêtre Wayland très différents l'un de l'autre : Wayfire et Niri.

• vi mode : appuyez sur control + shift + space et vous passez dans le mode "normal" de vi (par opposition au mode insertion). Les touches au lieu de permettre de taper du texte, permettront alors de se déplacer, sélectionner du texte, le copier…
• ctrl shift o pour afficher des "hint" sur les URL, ce qui permet de les activer en 1 touche
• recherche normal (ctrl shift f ) , recherche vi
• multi fenêtre (spawn new instance)
• theme https://github.com/alacritty/alacritty-theme

Pas d'onglet, pas de split — utiliser un multiplexeur au besoin.

Foot

Ce serait un peu le successeur de St, au sens où il est codé en C et les premières fonctionnalités mises en avant sont la légèreté et la performance, mais en natif Wayland. Pour autant Foot n'est pas avare sur certaines fonctionnalité. Sa première release est de 2019. C'est le terminal par défaut pour Sway, Dwl.

Il faudra le configurer à l'aide d'un fichier texte, et foot respectant XDG, ce sera ici $XDG_CONFIG_HOME/foot/foot.ini. Foot propose pas mal de raccourcis claviers, dont le même Hint mode que Alacritty : taper Ctrl Shift O .

Au cas où il ne serait pas assez léger, Foot propose un mode serveur.

Wezterm

De nouveau un terminal en Rust. Wezterm se veut complet, et cross-platform. Il affiche des images, gère les hyperliens, la connexion en SSH avec un client intégré, fait office de multiplexeur.

Il se configure en Lua.

Ghostty

Ghostty est sous licence MIT. LWN l'a présenté. Il s'agit d'une application récente, début en 2022, v1.0 fin 2024.

Une barre gtk4 permet d'afficher les onglets, d'en créer un nouveau. Sympatique fonction, ghostty +list-keybinds --default montre toutes les options (et un raccourci permet d'éditer le fichier de config). On peut aussi lister les thèmes avec ghostty +list-themes.

Peut afficher des gifs, comme Kitty.

Ghostty se veut un compromis entre la vitesse, les fonctionnalités, l'interface, et cross-platform. Il se veut agréable sans avoir besoin de modifier le paramétrage par défaut. Et il est petit, le paquet Debian par exemple fait 113 Ko.

Vous pouvez changer le shell sous Ghostty :

~/.config/ghostty/config:
command = /usr/local/bin/fish --login --interactive

De plus Ghostty intègre des fonctionnalités "Shell-integration".

Rio

(2022)
https://github.com/raphamorim/rio
vi mode, hyperlinks, images,

Le shell peut être modifié dans la config, plusieurs exemples sont fournis

[shell]
program = "pwsh"
args = ["-l"]

Warp

Alors là on bascule du côté obscur de l'IA !… et du proprio. Warp est d'abord une entreprise, qui a souhaité réimaginer un outil des développeurs - le terminal. Ce terminal, écrit en Rust, ne sera pas open source : https://github.com/warpdotdev/Warp/discussions/400

À la première ouverture, Warp suggère d'ouvrir un compte « pour bénéficier de toutes les fonctionnalités ». Ensuite, on ne se trouve pas directement dans une console mais Warp propose plutôt d'ouvrir / cloner un projet. Un raccourci permet cependant de lancer une session normale…
… Si ce n'est qu'outre des commandes, on peut taper des phrases ! En passant par Claude pour les interpréter… L'IA peut également suggérer des commandes en se basant sur votre historique. Tout ceci peut être désactivé dans les paramètres. Les fonctionnalités IA requièrent une connexion Internet.

J'ai par exemple testé "Install Wave term from the internet". Warp a commencé par vérifier s'il y avait une commande de disponible "yay", mais cette commande n'était pas dispo sur mon système. Il a alors intelligemment testé d'autres gestionnaires de AUR et a trouvé que paru était installé. De là, il a découvert waveterm dans les dépôts AUR et m'a suggéré d'utiliser paru -S waveterm-bin (control+entrée pour valider, et gogogo). Une fois ces folies passées, on revient à une expérience normale où la commande se déroule (pensez à lire les AUR avant d'installer aveuglément !)

Quand vous parcourez un projet, Warp peut indexer ces projets pour améliorer les suggestions.

Au lieu d'utiliser votre clavier pour taper, Warp peut reconnaître votre voix. Outre des commandes ou des phrases, il est possible de commencer par un "/" pour taper une "slash command".

Il y a également des fonctionnalités d'équipe, notamment une fonctionnalité de collaboration en temps réel. Certaines fonctionnalités sont payantes.

Warp propose un certain nombre de fonctionnalités classiques : personnalisation du prompt, apparence, raccourcis claviers, …

L'entreprise fournit un benchmark où Warp s'en sortirait aussi bien que Kitty ou Alacritty sur vtebench

WaveTerm

Waveterm est un peu la réponse open source à Warp (Apache 2.0).

Quand on l'ouvre la première fois, c'est la foire ! à gauche, le panneau invite de commande qui occupe un tiers de l'écran.
Tiers du milieu : en haut la consommation du CPU (hein?). Au milieu, un bout de page internet (hein?). En bas, un explorateur de projet. Tiers à droite : en haut, des raccourcis clavier qui s'affichent. Au milieu, un bout de doc sur Wave. En bas, une invite pour Wave IA. Bien sûr il s'agit d'une démo et il sera possible de personnaliser ce qui est visible au démarrage. Il est également possible lorsqu'on utilise un des "blocs" de le passer en mode "pleine fenêtre" puis le réduire par la suite.

Bon, testons l'invite IA en demandant d'installer… Warp! Il commence par m'expliquer les différentes méthodes d'install en fonction de l'OS (ah ! il n'a pas détecté…). J'explique que j'utilise Arch et il me dit d'utiliser un AUR helper ou de cloner le dépôt du AUR. Mais il ne détecte pas si j'ai paru ou yay ou autre.

On peut utiliser d'autres modules IA. Wave inclut également un explorateur de fichiers.
Les paramètres se gèrent bloc par bloc - on paramètre d'un côté les blocs que l'on souhaite au démarrage, de l'autre pour un bloc donnée, par exemple les préférences.

3. Liens

Norme POSIX sur le shell

https://linuxfr.org/news/gameshell-apprendre-les-rudiments-du-shell-en-s-amusant

Bref cours sur le shell

Cours plus complet sur le Bourne Shell

Revue de fish :

Autre revue de Fish

Nous vous avons entendu. Les dépêches noyaux me manquent aussi. Et entre Google qui veut les attraper tous, sudo qui n’est plus sudo sûr que ça, des pays qui sortent d’Internet, les chats qu’on veut surveiller parce qu’ils ne miaulent pas droit et le rythme de travail pour bien vivre, il est temps de revenir aux fondamentaux.

Alors sans plus attendre, quoi de neuf dans la 6.17 ? D’après Linus Torvalds lui-même, It's not exciting — ce n’est pas intéressant. Ce qui, pour lui, est un gage de qualité. Le noyau Linux 6.17 a été officiellement publié le 28 septembre, après la RC7.

Points marquants de la version

• Des corrections de sécurité et de stabilité dans la pile Bluetooth (beaucoup de bugs de type use-after-free).
• Des corrections pour les pilotes GPU et réseau (beaucoup de petites corrections).
• Prise en charge de patch à la volée (live patching) sur ARM 64 bits.
• Meilleur contrôle sur les atténuations de Spectre/x86.
• Suppression officielle de la gestion des architectures monoprocesseur, (nous y reviendrons).
• Introduction de nouveaux syscalls file_getattr() et file_setattr(), permettant la manipulation directe des attributs d’inodes via l’espace utilisateur.
• Gestion du protocole DualPI2 pour la gestion de congestion TCP.

Sommaire

• Architecture
  • Résumé
  • En détails
• Systèmes de fichiers et stockage
  • Résumé
  • En détails
• Réseau et connectivité
  • Résumé
  • En détails
• Virtualisation
  • Résumé
  • En détails
• Sécurité et cryptographie
  • Résumé
  • En détails
• Changements internes et outils
  • Résumé
  • En détails
• Le bilan en chiffres
• Appel à volontaires

Architecture

Résumé

• Intégration et mise à jour de la prise en charge de nombreux SoC ARM, Intel, AMD et RISC-V, dont :
  • Mediatek MT6572 (Disponible sur l'Orange Pi IoT3G), Exynos2200, NVIDIA Tegra264, BeagleBone Green Eco et OrangePi 4A sur ARM.
  • Nouvelles cartes STM32, Imx6, Radxa Rock 5T, FriendlyElec NanoPi M5, et Raspberry Pi RP1 PCI device.
• Ajout de nouveaux contrôleurs mémoire, avec prise en charge étendue de divers matériels industriels.
• Pilotes GPU : beaucoup de patchs pour amdgpu, i915/xe (options de debug et prise en charge de nouveaux formats colorimétrique).
• Les cartes Realtek 8851BU/8852BU sont désormais prises en compte sur le bus USB.
• Suppression officielle de la gestion des architectures monoprocesseur.

En détails

La suppression de la gestion spécifique des architectures monoprocesseur dans Linux 6.17 concerne toutes les architectures (x86, ARM, RISC-V, MIPS, etc.) où le noyau pouvait jusqu’ici être compilé et exécuté en mode UP (pour Uni Processor), opposé au mode SMP (Symmetric MultiProcessing).

Désormais, même les machines avec un seul cœur ou un seul processeur utiliseront des noyaux compilés avec gestion SMP activée. Cette modernisation simplifie le code de l’ordonnanceur (scheduler) et d’autres sous-systèmes internes du noyau, qui peuvent désormais partir du postulat que le système est au moins SMP, même si physiquement un seul cœur est présent. Cela permet un énorme nettoyage du code spécifique à cette fonctionnalité, et donc, à terme, une meilleure maintenance et une plus grande cohérence.

Néanmoins, l’impact, même très léger et invisible sur beaucoup de systèmes modernes, est réel. Le coût mémoire et processeur (dû à la gestion des locks) va augmenter légèrement, et impactera plus fortement les systèmes embarqués très contraints.

Pour les chiffres (et des explications), les tests effectués sur des systèmes monoprocesseurs avec un noyau SMP ont montré une baisse de performance de 5 %, et une augmentation de 0,3 % de la taille. Ingo Molnar, à l’initiative de ce changement, avait pointé le fait qu’il y avait, dans l’ordonnanceur actuel, 175 #ifdef dépendant de #CONFIG_SMP qui ont pu être nettoyés, et avec, plus de 1000 lignes de code supprimées.

Systèmes de fichiers et stockage

Résumé

• Btrfs : la gestion de large folios est ajoutée (expérimental), tout comme des options étendues pour la défragmentation et la compression intelligente des extents. Les premiers tests de performance montrent un gain de 20 % pour la création de fichiers et diverses améliorations…
• Ext4 : introduction du flag RWF_DONTCACHE permettant la purge automatique des données du cache après écriture, ce qui améliore certains workloads orientés I/O.
• NFS : prise en charge des délégations d’écriture même en mode write-only, accélérant des cas d’usage précis.
• Introduction de nouveaux syscalls file_getattr() et file_setattr(), permettant la manipulation directe des attributs d’inodes via l’espace utilisateur.
• Bcachefs : Les relations entre le développeur de ce système de fichiers (Kent Overstreet) et les autres mainteneurs du noyau se sont largement dégradés. Plusieurs mainteneurs ont fait part de leur refus de travailler à l’avenir avec Kent ce qui a conduit Linus a ne plus accepter les demandes de mises à jour (pull requests). Bcachefs est donc figé dans cette version 6.17 du noyau (et il a été complètement retiré de la future version 6.18). Un module DKMS externe est maintenant disponible pour les utilisateurs voulant continuer à utiliser ce système de fichiers.

En détails

Pour ceux qui s’intéressent aux performances et comparatifs des différents systèmes de fichiers avec le kernel, Phoronix a testé ces FS sur ce noyau 6.17. Pas de comparatif avec les précédents noyaux, mais un comparatif entre les FS.

Le flag RWF_DONTCACHE permet des opérations de lecture ou d’écriture passant par le cache mais où les données lues ou écrites ne sont pas conservées dans ce cache une fois l’opération terminée. Autrement dit, les données ne « polluent » pas le cache mémoire, ce qui est utile pour certains types d’I/O où l’on ne veut pas fatiguer le cache avec des données temporaires ou volumineuses qui ne seront pas réutilisées rapidement. Ce flag est une option pour les appels systèmes preadv2() et pwritev2()

    ret = pwritev2(fd, &iov, 1, 0, RWF_DONTCACHE);

En ce qui concerne les délégations d’écriture, cela permet de réduire les appels réseaux (jusqu’à 90 % dans certains cas d’usages — rapport)

Les syscalls file_getattr() et file_setattr() introduits dans Linux 6.16/6.17 permettent la manipulation directe des attributs d’inode depuis l’espace utilisateur, avec une interface plus simple et plus complète que les méthodes existantes.

Réseau et connectivité

Résumé

• Plusieurs nouveaux flags et options : SO_INQ pour AF_UNIX, extension de la gestion de MSG_MORE pour les paquets TCP volumineux et application plus stricte de la fenêtre TCP.
• Introduction de la prise en charge du protocole de congestion DualPI2 (RFC 9332) pour TCP/IP, notamment sur IPv6.
• Nouveau sysctl force_forwarding sur IPv6 permettant l’activation du mode forwarding.
• Remplacement progressif de la gestion des pages réseau par des descripteurs spécialisés (struct netmem_desc), préparant l’évolution vers les folios.

En détails

Le nouveau sysctl force_forwarding permet de forcer l’activation du forwarding indépendamment d’autres configurations potentiellement conflictuelles. (En particulier sur des profils limitatifs ou locaux)

    sudo sysctl -w net.ipv6.conf.all.force_forwarding=1

Petits rappels sur les folios (aussi utilisés dans ce noyau pour Btrfs). Historiquement, le noyau Linux gère la mémoire en unités appelées « pages » (généralement 4K octets). Un folio est un regroupement logique de pages (souvent pages, comme 16 pages de 4K pour former un folio de 64K). Les folios permettent une gestion mémoire plus efficace, évitent les appels redondants liés aux pages individuelles et optimisent les copies. netmem_desc sert d’abstraction générique pour la mémoire réseau, et utilisant les folios, remplace progressivement le struct page d’origine.

L’algorithme DualPI2 est un exemple d’algorithme de gestion active de file d’attente à double file couplée (AQM) spécifié dans la RFC 9332. Il sert de composant de base AQM au sein du cadre DualQ Coupled AQM conçu pour gérer deux files d’attente : une file « Classique » pour les contrôles de congestion compatibles Reno et une file « L4S » pour les contrôles de congestion Scalables. Vous trouverez plus de détails dans l'article en lien, avec, page 6 un ensemble de tests de performance en ce qui concerne DualPI2.

Virtualisation

Résumé

• Gestion de GSO (Generic Segmentation Offload) sur tunnel UDP dans virtio
• KVM : Unicité des enregistrements irqfd
• vhost-net : Prise en charge de VIRTIO_F_IN_ORDER
• vsock : Introduction de la prise en charge ioctl SIOCINQ
• iommu : Révision complète de la prise en charge des IRQs postées
• vfio/qat : Prise en charge des function virutelle Intel QAT 6xxx

En détails

La prise en charge des GSO permet d’améliorer les performances des machines virtuelles en réduisant la charge CPU liée au traitement des paquets UDP.

L’irqfd (interrupt request fd) a été modifié pour être globalement unique, ce qui améliore la gestion des interruptions virtuelles et évite des collisions ou conflits dans la gestion des événements d’interruption, renforçant la stabilité et sécurité des VM.

VIRTIO_F_IN_ORDER permet de gérer un ordre strict pour les paquets pour les cartes réseaux virtuelles.

vfio, qui expose des périphériques aux machines virtuelles, ajoute la prise en charge des fonctions virtuelles des accélérateurs Intel QAT 6xxx (QuickAssist Technology), améliorant ainsi les capacités de calcul cryptographique et compression dans les environnements virtualisés.

Sécurité et cryptographie

Résumé

• AppArmor peut désormais contrôler l’accès aux sockets AF_UNIX.
• Ajout de nouvelles fonctions pour SHA-1, SHA-256 et SHA-512 dans la bibliothèque crypto.
• Optimisation de CRC32c sur les CPU récents (AVX-512).
• La gestion de la profondeur de pile via GCC/Clang permet désormais l’effacement automatisé de la stack (voir SafeStack pour plus de détails).
• Meilleur contrôle sur les atténuations (mitigations) de Spectre/x86.
• Ajout d’un délai de 5 secondes sur /sys/fs/selinux/user.
• Introduction des types neversaudit dans le contexte SELinux.

En détails

Pour rappel, AF_UNIX est une classe de socket Unix permettant la communication interprocessus. Avant cet ajout, AppArmor ne gérait pas la sécurité avec ce niveau de finesse pour ces sockets. Désormais, il est possible de restreindre dans les profils AppArmor, la communication via ces sockets, entre deux applications.

Phoronix a testé les améliorations sur CRC32C sur différentes architectures récentes, qui sont résumées dans le graphique ci-dessous.

Le noyau 6.17 introduit un meilleur contrôle sur les atténuations Spectre, grâce à un mécanisme appelé Attack Vector Controls (AVC). Le principe est simple, plutôt que d’activer ou désactiver des dizaines de protections individuelles contre les bugs d’exécution spéculative (Spectre, variantes de Meltdown, etc.), il est désormais possible de les piloter par groupes, selon la portée des attaques. Le noyau classe les atténuations en cinq catégories :

• attaques utilisateur-vers-noyau (user-to-kernel)
• attaques utilisateur-vers-utilisateur (user-to-user)
• attaques invité-vers-hôte (guest-to-host)
• attaques invité-vers-invité (guest-to-guest)
• attaques inter-threads (cross-thread)

Avec un seul paramètre de démarrage mitigations=, il devient possible d’exclure une catégorie entière d’attaques (par exemple, désactiver toutes les protections invité-vers-invité si aucune VM non fiable n’est utilisée) et ainsi récupérer des performances.

Example: disable user-to-kernel attack mitigations, keep others at auto defaults
GRUB_CMDLINE_LINUX="... mitigations=auto,no_user_kernel ..."

Cette page liste l’ensemble des vulnérabilités CPU, et est une bonne source d’informations à ce propos.

Changements internes et outils

Résumé

• L'ordonnanceur ajoute le cgroup v2 cpu.max pour gérer de manière plus fine l’utilisation du CPU.
• Ajout de DAMON_STAT pour le monitoring.
• Le montage automatique de tracefs sur /sys/kernel/debug/tracing est devenu obsolète au profit de /sys/kernel/tracing.
• La migration vers des outils plus modernes : l’outil gconfig bascule sur GTK3.
• Toujours plus de Rust avec de nouvelles abstractions pour la gestion du matériel et des propriétés firmware.

En détails

cpu.max est plus précis et global que les précédentes méthodes (utilisant cpu.cfs_quota_us et cpu.cfs_period_us ou cpu.shares), en s’appuyant sur l’extension CFS Bandwidth Control de CFS (Completely Fair Scheduler)

# Limite de 50ms d’utilisation CPU toutes les 100ms (50%)
echo "50000 100000" > /sys/fs/cgroup/cpu.max

DAMON_STAT est un module noyau statique de surveillance de l’espace d’adressage mémoire beaucoup plus léger que les précédentes méthodes

    # Si DAMON_STAT est compilé en module
    $ sudo modprobe damon_stat

    # Activation du monitoring 
    $ echo 1 | sudo tee /sys/kernel/mm/damon/stat/enable

    # lecture des informations
    $ cat /sys/kernel/mm/damon/stat/statistics
    damon_latency_avg: 23 ms
    damon_bandwidth_bytes_per_sec: 5242880
    damon_coldness_percentile_75: 40%

    # Désactivation
    echo 0 | sudo tee /sys/kernel/mm/damon/stat/enable

Le bilan en chiffres

Statistiquement, ce n’est certes pas le noyau le plus calme de la série 6.x, comme nous pouvons le voir sur les graphiques ci-dessous, néanmoins, il reste plutôt tranquille, avec du nettoyage et peu d’ajouts.

Appel à volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

	Mainteneur	Contributeur(s)
Architecture	Aucun
Développeurs	Aucun
Systèmes de fichiers	Aucun	patrick_g
Réseau	Aucun
Virtualisation	Aucun
Sécurité	Aucun
Changements internes	Aucun
Édition générale	Aucun	BAud - vmagnin - orfenor

Un peu de vocabulaire :

• le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
• un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Nous sommes particulièrement à la recherche de mainteneurs pour toutes les parties.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, vous pouvez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

En 2022, le format JPEG-XL (JXL) a fait naitre beaucoup d’espoirs sur Internet : un taux de compression et une qualité très supérieurs à tout ce qui existe dans nos navigateurs web, plus une rétro-compatibilité avec JPEG. Les décodeurs sont arrivés dans Chromium, Firefox et Safari, on était tout excité, et puis… Google supprime le décodeur. Mozilla le cantonne à la version développeurs, derrière une option. Apple le… tiens non, Apple le garde et le porte même sur iOS.
Pendant que ça hurle et tempête Mozilla s’explique : l’implémentation actuelle c’est 100 000 lignes de C++ probablement dangereuses, tandis que du Rust plus compact serait avantageux.
Célébrons la rentrée 2025, les développeurs du labo Google (principal sponsor de JXL) nous proposent de tester une première version habillée de rouille ! Ne déshabillez pas la source trop vite, appréciez les préliminaires lents, c’est une fragile version 0.1.1.

Bénévalibre est un logiciel libre qui a pour objet de faciliter la valorisation du bénévolat dans les associations. Ce projet porté depuis sa naissance officielle en septembre 2019 par le CRAJEP (Comité Régional des Associations de Jeunesse et d'Éducation Populaire) de Bourgogne-Franche-Comté, fête ses 6 ans. Le développement initial a été appuyé financièrement par le Conseil régional de Bourgogne-Franche-Comté et la fondation du Crédit Coopératif. Les années suivantes, le Crajep a choisi d'engager ses fonds propres pour la maintenance mais a aussi chercher des financements pour la formation des associations, avec l'appui du Mouvement Associatif régional. À l'écoute de sa communauté (qui reste encore à développer plus encore), des fonctionnalités ont pu être ajoutées grâce au choix du comité de pilotage et à l'appui de Framasoft ayant exprimé par exemple, le besoin de pouvoir transférer facilement les données d'une instance à une autre. Récemment, dans le cadre de l'appel à commun de France Tiers Lieux, Bénévalibre a obtenu un soutien financier suite à l'intérêt marqué par plusieurs Tiers Lieux.

En 6 ans, Bénévalibre a montré son utilité au delà de la région Bourgogne-France-Comté : le CNAJEP (échelon national des Crajep) et le Mouvement Associatif ont relayé l'initiative sur l'ensemble du territoire. Le nombre croissant d'associations qui s'inscrivent, de bénévoles qui y déclarent leurs actions et le nombre d'actions en augmentation constante, montrent une certaine utilité pour ne pas dire une utilité certaine. On peut noter aussi le déploiement de plusieurs instances au sein de réseaux associatifs au delà de celle mise en place initialement.

Il était donc temps, pour le Crajep de Bourgogne-Franche-Comté, de solliciter CLISS XXI (la SCIC, Société Coopérative d'intérêt collectif qui a développé la version 1), de passer à la version 2 en intégrant les fonctionnalités qui attendaient sagement les financements nécessaires.

Le collectif est donc heureux de vous présenter les améliorations qui ont été apportées à cette nouvelle version V2, mise en production officiellement ce 1er septembre 2025 .

Quelques éléments notables de cette version 2 (V2)

Sur le plan technique, entre autre pour ne citer que cela.

• Affinage de l'interface d'utilisation, l'ajout d'une barre latérale pour la gestion de l'association et son administration et l'ajout d'un thème clair
• Ré-écriture des vues qui amène l'ajout de filtres sur les vues en liste
• Amélioration de l'export avec une unification et amélioration des vues génériques.
• Mise à jour de toutes les dépendances
• …

Une liste plus détaillée des évolutions et des outils libres utilisés est à retrouver dans l'annonce faite sur le forum de Bénévalibre.

Une ouverture souhaitée de la documentation pour favoriser les contributions

Pour permettre à terme à d'autres personnes, notamment sans bagages techniques, de contribuer à la documentation, le contenu qui existait a été "sorti" du logiciel. Elle devient donc désormais commune pour tout le monde sur doc.benevalibre.org.

Pour conclure ce billet…

…parce que Bénévalibre contribue à donner à voir une autre manière de faire société et met en évidence des engagements plus nombreux qu'on se l'imagine généralement, n'hésitez pas à le promouvoir autour de vous.

Jérôme, pour CLISS XXI,
Laurent, pour le copil du CRAJEP de Bourgogne-Franche-Comté

Après une longue absence sur LinuxFr.org, il est temps pour moi de vous annoncer la sortie de la dernière version 8.0 d’AWStats Log Analyzer.
AWStats est un outil de reporting de statistiques sur la fréquentation d'un site web qui s'appuie sur les logs du serveur (donc sans traqueur intégré sur le site, sans cookie, sans service Tiers, etc…)

Le projet a été initié en 2000 et a connu son apogée en 2008 (avec 20 à 30% de part de marché, qui a décliné depuis au profit des outils d'analyses statistiques basés sur la pose de tags JavasScript. Il reste encore utilisé à ce jour par beaucoup d'administrateurs système.

Le package de la v8 peut être téléchargé sur le site du projet AWStats : https://awstats.org

Les changements de cette version sont les suivants:

• Amélioration du CSS
• Mise à jour de robots.pm
• Corrections du bug n° 248
• Mise à jour de la traduction en chinois traditionnel et migration vers UTF-8
• Arbre de tri : Vérification de l'existence de la clé. Ne tient pas compte de sa valeur.
• Autorisation des journaux de traitement en JSON
• Correction de la configuration par défaut de NotPageList
• Ajout d'un rapport sur le temps de requête
• Correction d'un lien incorrect dans la documentation
• Suppression des agents utilisateurs natifs des navigateurs Android et iOS/OSX de robots.pm
• Identification incorrecte de GPTBot en raison d'une erreur dans robots.pm
• Encodage incorrect pour la traduction en ukrainien

Voir le portail officiel sur https://www.awstats.org

ATTENTION: Comme je l'avais annoncé dans le podcast projets-libres sur Matomo et AWstats, ceci est la dernière version que je publierais. La maintenance du projet AWStats s'arrêtant avec cette version 8.0.
Je vais pouvoir me consacrer entièrement à mes 2 autres projets: https://dolibarr.org et https://sellyoursaas.org.
Je ne doute pas que la communauté saura réaliser les forks, bienvenus, au projet si nécessaire.

Si vous désirez basculer sur un projet avec une maintenance plus active, je vous invite à basculer sur Matomo ou d'autres outils également libres…

Cet article fait suite à : “L’architecture d’entreprise dans l’anthropocène : une stratégie numérique soutenable”. Le but de cette suite d’articles est d’essayer d’éclairer l’évolution du domaine métier de l’architecture d’entreprise sous le prisme de l’anthropocène.
En effet, au delà de la question de la soutenabilité, l’un des enjeux importants dans l’anthropocène, et peut-être le plus important, est la résilience de l’organisation.
Certaines entreprises ont déjà lancé des changements profonds avec le support du CEC (Convention des Entreprises pour le Climat) tandis que d’autres se lancent dans un exercice de propective pour définir la direction à suivre. A ce propos, le cabinet “Sinon Virgule” a d’ailleurs produit une excellente étude à la demande de la MACIF, La MAIF et la Caisse des dépôts sur le devenir de leur métier : “Peut-on assurer un monde qui s’effondre ?”.

Sommaire

• Pourquoi le logiciel libre afin d’améliorer sa résilience numérique ?
• C'est Quoi le logiciel libre ?
• Comment développer son usage dans une organisation ?
• Avec quoi ?
• En conclusion

Pourquoi le logiciel libre afin d’améliorer sa résilience numérique ?

La résilience d’un système numérique va bien au delà de la redondance matérielle et logicielle de ses systèmes.
En effet, dans le contexte géo-politique instable actuel, comme nous avons pu le voir pour la guerre en Ukraine avec l’explosion des coûts de l’énergie ou aujourd’hui avec l’augmentation du protectionnisme aux USA entraînant l’augmentation des taxes douanières, cette résilience implique un meilleur contrôle de ses infrastructures, ses technologies et ses données afin de s’assurer une certaine autonomie et indépendance vis à vis de ces évolutions géo-politiques.
Sur ce sujet de l’impact géo-politique, le CIGREF a d’ailleurs écrit une note intéressante très récemment : Géopolitique et stratégie numérique.

Au-delà des contraintes géopolitiques, l’usage du logiciel libre permet de lutter contre l’infobésité des géants de la tech pour soutenir votre stratégie de soutenabilité numérique mais aussi des impacts financiers de l’ajout de technologie comme l’IA générative qui ne vous apporteront peu ou pas de valeur métier mais juste à supporter la croissance des gafam dans le développement d’une technologie qui n’est pas encore mature (voir Gartner hype cycle).

Les raisons de passer aux logiciels libres sont vastes : géopolitique, souveraineté, autonomie numérique, … Et les exemples aussi :

• Le Danemark claque la porte à Microsoft et sa suite pour se tourner vers les logiciels libres,
• Le retour de Donald Trump relance le débat sur la souveraineté numérique,
• Les géants du numériques encore loin de la neutralité carbone,
• Un land allemand abandonne Microsoft au nom de la souveraineté numérique,
• …

C'est Quoi le logiciel libre ?

Le logiciel libre ne se présente plus après plus de 40 ans d’existence. C’est devenu, en entreprise, un commun. Tout le monde s’y est mis même Microsoft qui luttait contre lui au début de son existence.
Regardons néanmoins, quelques grandes dates de l’écosystème du libre depuis les années 1970. Attention ce chronogramme n’est pas exhaustif. Pour avoir une vue complète, je vous invite à vous connecter au portail du logiciel libre sur Wikipédia :

Le logiciel libre s’est développé non grâce à une organisation type entreprise (cathédrale) mais par la coopération entre individus sans contre-partie financière hormis la reconnaissance de ses pairs : La cathédrale et le bazar.
En 40 ans, ce modèle d’intelligence collective a fournit des logiciels d’une telle qualité que ceux-ci sont devenus un standards dans un bon nombre de domaines.

Définition du logiciel libre :

Selon la Free Software Foundation, un logiciel est considéré comme « libre » s’il donne à l’utilisateur quatre libertés fondamentales :

• La liberté d’utiliser le logiciel à n’importe quelle fin
• De l’étudier et de modifier le code source
• De redistribuer des copies du logiciel
• D’améliorer le logiciel et de partager ces améliorations avec la communauté.

L’essence du logiciel libre est donc une question d’éthique et de liberté des utilisateurs. Le logiciel libre tend à renforcer les droits de l’utilisateur.

L’Open Source Initiative (OSI) définit un logiciel open source comme un logiciel dont la licence respecte certains critères, principalement la libre redistribution du logiciel, l’accès au code source, la possibilité de créer des travaux dérivés et l’intégrité du code de l’auteur.

Quelques chiffres aujourd’hui :

Comment développer son usage dans une organisation ?

Fondé en 2014, le groupement TODO propose un cadre pour construire un département dédier à l’open source dans une organisation, nommé OSPO : Open Source Programmme Office. TODO est une communauté de practiciens qui visent à créer les meilleures pratiques et outils pour opérer des OSPO dans les organisations.

Pour les moyennes et grandes organisations, une approche OSPO est intéressante. Un OSPO agit comme le point centralisé des activités open source d'une organisation, coordonnant les politiques d'utilisation, les stratégies de contribution, les procédures de conformité et les initiatives d'engagement communautaire.

Le mindmap proposé par TODO synthétise bien les capacités que l’OSPO peut porter :

Un programme d'opérations peut aider de nombreuses organisations à obtenir de meilleurs résultats grâce à l'open source comme le font déjà :

• les services publics en France ,
• le CERN,
• la commission européenne,
• ou l’OMS.

Avec quoi ?

La liste des logiciels libre est longue, voici quelques bibliothèques répertoriant ceux-ci :

• La plus ancienne, Source forge : https://sourceforge.net/
• Le portail des logiciel libre sur Wikipédia : https://fr.wikipedia.org/wiki/Portail:Logiciels_libres
• Le socle interministériel des logiciels libres : https://code.gouv.fr/sill/list
• Les Logiciels libres des services publics : https://comptoir-du-libre.org/fr/

Pour donner une exemple concret, prenons 2 building blocks qui se retrouvent généralement dans les organisations : le poste de travail et l’ERP ou plutôt le PGI (progiciel de gestion intégré) en français.

Le poste de travail type bureautique avec des logiciels libres :
Les solutions sont nombreuses. On peut s’appuyer sur une solution pré-packagée comme openDesk mais qui nécessite une infrastructure kubernetes pour être exploitée. Une approche plus simple sera privilégiée pour les petites et moyennes organisations.
La suite openDesk, à ne pas confondre avec les meubles de bureau opendesk, a été financé par le Ministére fédéral Allemand de l’intérieur et du territoire afin de réduire la dépendance de l’administration publique des fournisseurs de logiciels propriétaires.
Cette suite comprend le socle de logiciels libres suivants :

• NextCloud pour le partage de fichier
• OpenProject pour la gestion de projet
• XWiki pour le knowledge management
• Cryptpad pour la partie Office
• Nordeck pour le Whiteboard
• OX app suite développée par Open-Xchange pour la partie Email et calendar
• Element pour la Messagerie instantanée
• Jitsy pour la vidéo conférence

Une solution plus légère pourrait se limiter à Cryptpad pour la partie Office et Nextcloud pour la partie workplace. Avec bien sûr un poste de travail tournant sur une distribution gnu-Linux comme Ubuntu avec Mozilla Firefox et Thunderbird en client lourd :

L'ERP avec les logiciels libres :
L’Enterprise Ressource Planning ou PGI, la solution est plus simple et plus complexe à la fois. Plus simple en terme de définition de la solution car une seule application embarquera l’ensemble des fonctionnalités et plus complexe à la fois car ces applications type ERP embarquent beaucoup de fonctionnalités et donc sont complexes à gérer.

L’organisation de grande taille préférera un ERP de type SAP ou Oracle E-busines suite, tandis que pour une petite ou moyenne structure le logiciel libre apporte de nombreuses solutions comme : ERPNext, Triton, Dolibarr, OpenConcerto, ….

Si nous prenons l’exemple de Dolibarr, les fonctionnalités couvertes sont les suivantes :

En conclusion

Dans l’anthropocène le logiciel libre est une excellente voie pour asseoir ou améliorer la résilience de son système d’information dans ce contexte géopolitique incertain et qui ne devrait pas s’améliorer (cf Tellus institute).

Les logiciels libres ne pourront certes pas supplanter toutes les applications de votre patrimoine applicatif mais pour ce qui existe pourquoi ne pas en profiter ? Regardez, même Microsoft est passé de “linux est un cancer” en 2001 à “Nous aimons linux” en 2014.

Les logiciels sont des logiciels d’excellente qualité comme ils l’ont déjà démontré. Le problème est peut être que les logiciels libres souffrent d’une image trop “tech”.

Au delà de cela, il existe aussi des applications métiers qui permettront de libérer une partie de votre SI :

• Pour les entreprises : Guide des logiciels libres pour l'entreprise, de FranceNum le portail de la transition numérique des entreprises,
• Pour les associations : Guide Libre Association, le catalogue de logiciels libres de l’association April,
• Pour les écoles : Liste de logiciels éducatifs, de l’Université Grenoble Alpes.

Haiku est un système d’exploitation pensé pour les ordinateurs de bureau. Il est basé sur BeOS mais propose aujourd’hui une implémentation modernisée, performante, et qui conserve les idées qui rendaient BeOS intéressant: une interface intuitive mais permettant une utilisation avancée, une API unifiée et cohérente, et une priorisation de l’interface graphique par rapport à la ligne de commande pour l’administration du système.

Le projet est actuellement (depuis 2021) en phase de beta test. La plupart des fonctionnalités sont implémentées et l’attention des développeurs se porte sur la correction de bugs, l’amélioration de la stabilité et des performances, et plus généralement, les finitions et petits détails. Une autre part du travail est le suivi de l’évolution de l’environnement technologique: nouveaux pilotes de périphériques, suivi des derniers standards du web, etc.

Les trois derniers mois ont été un peu plus calmes que d’habitude pour Haiku, mais cela est largement compensé par une très forte activité du côté de Haikuports. Cela révèle que le système lui-même devient plus mature et qu’il devient de plus en plus facile de développer ou de porter une application sans tomber sur des problèmes du système qui doivent être corrigés au préalable.

Sommaire

• Applications
  • Tracker
  • Terminal
  • Mail
  • HaikuDepot
  • TextSearch
  • Debug Analyzer
  • Préférences d’apparence
  • Utilisation de IconMenuItem
  • Adaptation aux écrans à très haute réolution
• Outils en ligne de commande
  • Remote Desktop
  • Time
  • pkgman
  • su
  • listarea
  • fdinfo
  • install-wifi-firmwares
• Kits
  • Support kit
  • Interface kit
  • Storage kit
  • Shared kit
• Serveurs
  • app_server
  • input_server
• Pilotes
  • ACPI, gestion d’énergie, système
  • Réseau
  • Interface homme-machine
• Systèmes de fichiers
  • NFS4
  • EXT4
  • RAMFS
  • FAT
• libroot
  • Mise à jour de la libio
  • Correction de multiples problèmes dans les fonctions standard C et les extensions BSD:
  • Intégration des changements de POSIX-2024
  • Améliorations sur la gestion de la mémoire
• Noyau
• Bootloader
• Documentation
  • API (Haiku book)
• Environnement de compilation
• Portage de Haiku sur d’autres CPUs
  • RISC-V

Applications

Tracker

Tracker est le navigateur de fichiers de Haiku. Le code est hérité directement de BeOS (cette partie avait été publiée sous licence libre lors de l’abandon de BeOS par Be) et fait l’objet depuis de nombreuses années d’un gros travail de nettoyage et de modernisation.

Pas de grosses nouveautés ces derniers mois, mais des corrections pour plusieurs régressions suites à du nettoyage effectué précédemment. Par exemple, les icônes des disques montés sont à nouveaux affichés sur le bureau dans les dialogues d’ouverture et d’enregistrement de fichiers. L’annulation du filtrage du contenu d’un dossier en tapant un nom de fichier partiel est correctement annulé si on appuie sur échap.

Enfin, des problèmes de synchronisation de l’icône de la poubelle, qui apparaissait pleine alors qu’elle était vide, ont été corrigés. Ces problèmes étaient déjà présents dans BeOS.

Terminal

Le terminal permet de lancer des applications en ligne de commande.

Un chantier en cours consiste à rendre le terminal utilisable comme un “replicant”, c’est-à-dire de pouvoir l’intégrer dans d’autres applications telles que l’IDE Genio. Cette approche demande de restructurer beaucoup de choses, et pour l’instant, il est plus simple pour les développeurs de Genio de recopier une partie des sources du Terminal dans leur projet et de les intégrer de façon plus statique. Les problèmes sont corrigés petit à petit.

Une autre correction mérite d’être mentionnée: le terminal se plaçait lui-même dans le dossier de travail du shell lancé lors de l’ouverture d’un nouvel onglet. Si ce dossier se trouve dans un disque qu’on essaie par la suite de démonter, le démontage échoue (même si l’application lancée dans le terminal a elle-même changé de dossier entretemps). Désormais le terminal ne modifie pas son dossier actif et ne bloque plus le démontage des disques.

Mail

L’application Mail permet de lire et d’envoyer du courrier électronique. Elle est composée d’un serveur de synchronisation et d’une interface graphique indépendante. Entre les deux, les mails sont stockés sous forme de fichiers augmentés d’attributs étendus, ce qui permet d’utiliser Tracker et les requêtes BFS comme outil principal pour traiter les messages.

Les changements listés ici concernent l’application de lecture et rédaction de messages:

• Correction du comportement du menu « Fermer et marquer comme… » lorsqu’il est appliqué à plusieurs messages.

  • Modifications pour éviter de montrer des informations vides, en double, ou absentes dans les détails des adresses mail (nom d’expéditeur, de destinataire, etc).

HaikuDepot

HaikuDepot est à la fois le gestionnaire de paquets et le magasin d’applications de Haiku. Ce double rôle conduit pour l’instant à une interface qui prête un peu à confusion, et l’interface devrait être repensée pour un fonctionnement plus intuitif. En attendant, quelques petites améliorations ont tout de même été faites pour rendre les problèmes moins gênants.

Lorsqu’une recherche dans la vue « paquets mis en avant » ne donne aucun résultat, il y a affichage d’un lien permettant de poursuivre la recherche dans la liste complète des paquets. En effet, de nombreux utilisateurs se sont plaints de ne pas trouver certains logiciels en effectuant une recherche, sans se rendre compte qu’ils faisaient une recherche dans une liste de quelques dizaines de paquets et pas dans tout ce qui est disponible.

TextSearch

TextSearch est un outil de recherche dans le contenu des fichiers par expressions régulières (une version graphique de grep).

Il reçoit ce trimestre une fonction pour filtrer les fichiers à rechercher, équivalent à l’option grep --include.

Debug Analyzer

Debug Analyzer est un outil de profiling et d’analyse de traces d’exécution.

Correction d’un problème de compilation suite à des changements dans l’API de BObjectList (cet outil n’est pas compilé par défaut, il avait donc été oublié lors du changement d’API au trimestre précédent).

Préférences d’apparence

Dans la configuration des couleurs du système, renommage de la couleur « barre d’état » en « barre de progression ». Le nom « barre d’état » (status bar en anglais) correspond à la classe BStatusBar utilisée par BeOS et Haiku, mais tout le monde appelle ça une barre de progression. On peut au moins éviter la confusion pour les utilisateurs, à défaut de pouvoir le faire pour les développeurs d’applications en renommant la classe elle-même (ce qui causerait des problèmes de compatibilité d’API et d’ABI).

Utilisation de IconMenuItem

Ce changement concerne l’application ShowImage (visualiseur d’images) ainsi que FileTypes (les préférences d’association de types fichiers avec des applications). Ces deux applications utilisent un menu pour sélectionner une application (pour ouvrir une image dans un éditeur, ou pour associer un type de fichier à une application, respectivement).

Les applications pour Haiku utilisant des icônes colorées et facilement identifiables, c’est beaucoup mieux qu’une liste de noms pour s’y retrouver rapidement. Ces deux applications utilisent donc maintenant des IconMenuItem dans ces menus, pour afficher les applications avec leur icône respective.

Adaptation aux écrans à très haute réolution

Un travail en cours sur les applications concerne l’adaptation aux écrans à très haute résolution.

Presque toutes les applications pour Haiku utilisent un système de mise en page dynamique, et toutes les ressources (police de caractères, icônes…) sont vectorielles. Cela permet en théorie d’afficher l’interface avec un niveau de zoom arbitraire. Cependant, une partie du code a été écrit avec des tailles en pixels « en dur » et ne s’adapte pas comme il faudrait (la bonne façon de faire est de se baser par exemple sur la taille de la police de caractères sélectionnée par l’utilisateur).

Ce trimestre, on trouve des évolutions à ce sujet dans plusieurs applications:

• Expander (décompression d’archives)
• SerialConnect (communication par port série)
• Mise à l’échelle de la barre de défilement
• Préférences d’imprimantes
• Mise à l’échelle des icônes

Outils en ligne de commande

Remote Desktop

L’outil de connexion au bureau à distance n’est pas vraiment une application en ligne de commande. Cependant, il nécessite pour l’instant un lancement depuis un terminal avec les bonnes options, et selon les cas, la mise en place d’un tunnel SSH. Une interface grapique plus simple d’uitlisation sera probablement ajoutée plus tard.

• Amélioration du parsing de la ligne de commande et en particulier de l’option pour choisir un port SSH
• Activation de l’option SO_REUSEADDR permettant de plus facilement relancer l’outil s’il plante, sans attendre un timeout de la connexion précédente qui n’a pas été fermée proprement

Time

Le panneau de préférences de date et heure peut être lancé en ligne de commande avec une option spécifique pour forcer une synchronisation NTP. Cette fonctionnalité n’est pas vraiment documentée, à l’origine il s’agit plutôt d’une astuce interne au système. L’application reconnaît maintenant l’option --help standardisée et affiche un message d’aide qui documente cette fonctionnalité.

Il peut être utile de relancer cette commande manuellement si jamais la synchronisation au démarrage n’a pas fonctionné (par exemple si le réseau n’était pas disponible à ce moment-là). En particulier, cela peut être utilisé dans des scripts d’automatisation et pour des machines où l’interface graphique n’est pas facilement accessible (serveurs de build par exemple).

pkgman

pkgman est une commande permettant d’installer, mettre à jour et rechercher des paquets logiciels.

Ajout d’une option --no-refresh pour ne pas retélécharger la base de données des paquets.

Cette base de données contient non seulement les noms des paquets, mais aussi leur description courte et la liste des “provides” (par exemple: commandes et bibliothèques fournies par chaque paquet). pkgman vérifié déjà si une nouvelle version de la base de données est disponible, mais cette dernière peut être mise à jour plusieurs fois par jour par l’intégration continue.

Le nombre de paquets augmentant, la taille de la base de données devient non négligeable (plusieurs méga-octets), ce qui pose problème en particulier pour les utilisateurs et développeurs ne disposant pas d’un accès internet illimité.

su

La commande su est peu utilisée puisque l’utilisateur par défaut a déjà tous les droits. Son implémentation était donc un peu incomplète. Elle peut toutefois être utile pour avoir des utilisateurs supplémentaires restraints, par exemple pour un accès à distance par ssh.

• La commande su ne demande pas de mot de passe si l’utilisateur dispose déjà de l’accès root
• Toutes les commandes liées à la gestion des utilisateurs (su, login…) configurent les groupes actifs lors du changement d’utilisateur

listarea

listarea est une commande de debug permettant de lister les zones mémoire allouées à différentes applications. Elle affiche maintenant le verrouillage et les protections de ces zones (swappable ou non, exécutabele ou non, accessible en écriture ou non).

fdinfo

fdinfo permet d’examiner les descripteurs de fichiers ouverts (un peu comme lsof). Cette commande peut maintenant afficher en plus le dossier courant de chaque application (ce qui aurait été bien utile pour identifier le problème avec le dossier courant du Terminal ci-dessus).

install-wifi-firmwares

Ce script permet d’installer les firmwares pour certaines très anciennes cartes Wifi. Les firmwares publiés à l’époque sont disponibles avec des licenses n’autorisant pas la redistribution ou les modifications de packaging, ce qui empêche l’intégration dans le système de paquets habituel. Le problème a été corrigé depuis longtemps par les fabricants de cartes Wifi, mais les anciens firmwares n’ont jamais été republiés avec des licenses mises à jour.

Le script a été mis à jour pour récupérer certains firmwares depuis un nouveau serveur, l’ancien emplacement utilisé n’étant plus disponible.

Kits

La bibliothèque de fonctions de Haiku est découpée en kits qui regroupent des ensembles de fonctions et de classes par thématique (stockage sur disque, interface graphique…). Dans certains cas il s’agit principalement d’une méthode d’organisation du code source et de la documentation (les kits pouvent être très interdépendants). Certains kits sont toutefois fournis sous forme de bibliothèques séparées.

Support kit

Ce kit contient diverses fonctions utilitaires et basiques du système.

Changement d’API pour la classe BUrl. Dans l’ancienne version de cette classe, il était possible de construire un objet BUrl représentant une URL encodée ou non-encodée (échappement des caractères réservés). Cela rendait trop facile d’oublier d’encoder une URL avant de l’utiliser, ou bien d’encoder plusieurs fois une URL et de se retrouver avec un lien invalide.

La nouvelle API impose d’indiquer dès la création d’un objet BUrl si la chaîne de caractères servant de base est déjà encodée ou non. L’objet BUrl construit représentera toujours une URL déjà encodée, qui peut éventuellement être décodée pour affichage si nécessaire.

Interface kit

Ce kit contient tout ce qui se rapporte à l’interface graphique: fenêtres, vues, contrôles, mise en page…

Retour en arrière sur une modification des raccourcis claviers de BTextView pour naviguer vers les mots suivant et précédent. Les nouveaux raccourcis entrent en conflit avec des raccourcis déjà utilisés par plusieurs applications, et n’apportaient pas grand-chose.

Correction de problèmes de compatibilité dans le format des données stockées par la classe BPicture (il s’agit d’un enregistrement de commandes envoyées au serveur graphique, qui peuvent être rejouées plus tard). Le format des données stockées était différent de celui de BeOS. Certaines applications utilisant un objet BPicture enregistré dans une ressource de l’application, ne s’affichaient pas correctement.

Amélioration de la gestion des sous-menus, en particulier cela corrige un crash si un sous-menu est fermé en utilisant la touche échap.

Remise à plat de tous les calculs accumulés au cours des années pour générer les couleurs de l’interface graphique en fonction des couleurs choisies par l’utilisateur. Chaque morceau de code concernait faisait ses propres calculs pour générer de jolis dégradés, des variantes plus sombres et plus claires, etc. Cela fonctionnait bien avec le thème par défaut, mais pas forcément avec des choix de couleurs qui en sont très éloignés. Le nouveau code est plus simple, plus prédictible, et permet de rassembler ces calculs dans la classe « control look », qui peut être remplacée par un add-on pour fournir une apparence complètement différente.

Cela peut nécessiter d’ajuster un peu les couleurs dans les préférences d’apparence si vous les avez personnalisées.

Storage kit

Ce kit regroupe tout ce qui concerne le stockage de masse et la gestion des fichiers.

Harmonisation de la nouvelle fonction BQuery::SetFlags avec d’autres fonctions similaires, et ajout d’une page de documentation pour cette fonction.

Correction d’un crash lorsqu’on enregistre un type MIME alors que le type parent n’existe pas (par exemple si on enregistre image/gif alors que le type image n’existe pas).

Ajout d’une constante pour identifier les systèmes de fichiers FAT16 parmi la liste des systèmes de fichiers connus.

Shared kit

Le shared kit contient des fonctions expérimentales en cours de développement mais déjà utilisées par plusieurs applications.

Contrairement aux autres kits, il est fourni sous forme d’une bibliothèque statique, ainsi chaque application peut en utiliser une version différente (choisie au moment de la compilation) et il n’y a pas de contraintes pour conserver une stabilité d’API ou d’ABI. Les fonctions développées dans le shared kit peuvent ensuite être migrées vers les autres kits une fois qu’elles sont finalisées.

La classe « color list » (utilisée par exemple dans les préférences d’apparence) accepte maintenant le glisser-déposer de couleurs.

Serveurs

Les serveurs sont des applications lancées au démarrage du système. Ils sont similaires aux services systemd. Ils fournissent des services utiles à l’implémentation de la bibliothèque standard, car tout ne peut pas être fait dans une bibliothèque partagée.

app_server

app_server regroupe le serveur graphique de Haiku (utilisé au travers de l’interface kit) ainsi que la gestion des applications en lien avec l’application kit.

Correction d’un problème d’initialisation de variables indiquant dans quels workspaces (bureaux virtuels) une fenêtre doit être présente. Cela se manifestait par l’apparition de morceaux incomplets de la fenêtre si on change de bureau virtuel pendant son apparition. Le bug existait depuis 15 ans mais n’avait jusque-là pas pu être identifié.

Les curseurs de souris ne sont plus générés en bitmap à la compilation à partir des sources vectorielles. C’est maintenant fait lors de l’initialisation du serveur graphique, ce qui permet d’avoir un plus gros curseur sur les écrans à très haute résolution.

input_server

input_server se charge des périphériques d’entrée utilisateurs (claviers, souris et autres périphériques de saisie et de pointage).

Correction de la keymap espagnole latino-américaine dans laquelle plusieurs combinaisons de touches ne fonctionnaient pas comme sur les autres systèmes.

Pilotes

ACPI, gestion d’énergie, système

Mise à jour de ACPICA pour la prise en charge de ACPI avec la dernière version disponible.

Correction de problèmes dans le pilote poke (permettant l’accès direct à la mémoire pour écrire certains pilotes en espace utilisateur) pour mieux valider les paramètres des ioctl et éviter de pouvoir facilement déclencher un kernel panic suite à une mauvaise utilisation du pilote.

Réseau

Correction d’un problème dans la pile TCP ou les retransmissions de paquets lors de l’établissement de la connexion n’étaient pas faits, si le premier paquet était perdu, la connexion ne s’établissait jamais.

Lorsque IP_HDRINCL est activé (une application demande à envoyer et recevoir elle-même les en-têtes IP des paquets reçus), la pile réseau s’assure tout de même que les en-têtes générés ont bien un checksum valide. Cela permet à traceroute de fonctionner correctement par exemple.

Mise en place de l’infrastructure pour la découverte de MTU deu chemin. Cela permet de déterminer la taille maximale des paquets qu’on peut envoyer vers un serveur, sans que de la fragmentation IP soit mise en jeu en cours de route (ce qui, au mieux dégraderait les performances, au pire empêcherait la connexion de fonctionner correctement):

• Ajout de l’option IP_DONTFRAG pour demander aux routeurs de ne pas redécouper certains paquets,
• Remontée de l’information ICMP FRAGMENTATION_NEEDED pour détecter qu’on a essayé d’envoyer un paquet trop gros.

Cela permet déjà de détecter les problèmes de MTU, mais pas encore de les corriger automatiquement. La suite du code est encore en cours de test.

Remplacement du pilote iprowifi3945 par la version mise à jour disponible dans OpenBSD (pilote “wpi”) à la place de celle de FreeBSD qui est actuellement moins bien maintenue.

Interface homme-machine

Ajout de la tablette Intuos 4 dans le pilote pour les tablettes Wacom, ainsi que du support de la molette présente sur certaines tablettes.

Systèmes de fichiers

NFS4

NFS est un système de fichier en réseau. Une machine serveur se charge réellement du stockage des fichiers, et d’autres machines peuvent monter ce disque et accéder aux fichiers partagés. Plusieurs machines peuvent accéder au même serveur en même temps et modifier les fichiers, ce qui nécessite une attention particulière lors de l’implémentation d’un système de fichier client.

Le travail sur le pilote NFSv4 se poursuit pour le stabiliser et améliorer sa compatibilité avec les serveurs NFS existants.

Correction de problèmes de gestion du cache et de libération anticipée d’inodes`, points sur lesquels NFS est un peu inhabituel par rapport à d’autres systèmes de fichiers puisque des évènements peuvent arriver du serveur NFS concernant un fichier qui a été supprimé localement, par exemple.

Correction d’un problème qui pouvait conduire un fichier nouvellement redimensionné à contenir des données non initialisées au lieu d’octets à 0.

Cela permet de corriger des problèmes détectés par des tests NFSv4 existants pour d’autres systèmes.

EXT4

Le pilote ext4 permet de monter, en lecture et en écriture, les systèmes de fichiers ext2, ext3 et ext4 développés pour Linux.

Implémentation et activation de la fonctionnalité « metadata_csum_seed » qui est activée par défaut pour les systèmes de fichiers nouvellement créés sous Linux.

Corrections dans le « tree splitting » qui n’était pas implémenté correctement, empêchant d’accéder à des dossiers contenant un trop grand nombre de fichiers.

RAMFS

RAMFS est un système de fichiers non persistant, stockant les fichiers uniquement dans la RAM. Il est plus rapide qu’un système de fichier traditionnel.

Correction de crashs lors de la création de gros fichiers et lors du remplacement d’un hardlink par un autre fichier.

FAT

FAT est un système de fichiers développé par Microsoft pour DOS et les anciennes versions de Windows. Il est assez répandu et sert un peu de format d’échange standard en particulier pour les supports de stockage externes (clés USB, cartes SD, disquettes…).

Ajout d’assertions et de vérifications d’intégrité supplémentaires. Le pilote FAT utilisé actuellement provient de FreeBSD, dont les développeurs nous ont assuré qu’il était bien testé et maintenu. Mais, de façon similaire aux pilotes Wifi, on se rend compte que les bases d’utilisateurs de Haiku et de BSD ne sont pas du tout les mêmes, et nous sommes face à beaucoup de systèmes de fichiers FAT corrompus ou inhabituels, ce qui se produit peut-être moins souvent dans les utilisations de FreeBSD sur un serveur par exemple.

libroot

La libroot contient l’équivalent de la libc, libdl, libpthread et libm d’un système UNIX standard, ainsi que des fonctions bas niveau spécifiques à BeOS.

Les extensions GNU et BSD sont déportées dans des bibliothèques séparées (libgnu et libbsd), ce qui permet de respecter au mieux la spécification POSIX sans avoir à utiliser des astuces telles que des « weak symbols ».

Mise à jour de la libio

La bibliothèque standard de Haiku est à l’origine un fork de la glibc, utilisant exactement la même version que BeOS afin de garantir une compatibilité d’ABI optimale avec ce dernier. Cependant, cette version ancienne et obsolète ne répond pas aux besoins des applications modernes.

Petit à petit, des parties de la bibliothèque C sont donc remplacées par des composants venant de FreeBSD, NetBSD, OpenBSD ou plus récemment de musl. Certaines choses sont très bien standardisées et ne posent pas de problèmes, pour d’autres parties, des symboles internes de la bibliothèque sont exposés et parfois exploités par des applications (directement par des développeurs applicatifs pour contourner un bug, ou alors parce que les développeurs de la glibc ont mal isolé les choses et ont exposé des détails internes).

Ce trimestre, la partie libio (gestion des flux d’entrée-sortie) a été mise à jour avec la dernière version de la glibc. Il n’est pas possible d’utiliser une autre bibliothèque C pour cette partie sans casser l’ABI, mais la mise à jour est possible.

Correction de multiples problèmes dans les fonctions standard C et les extensions BSD:

• Ajout d’une vérification de la locale passée à setlocale pour retourner une erreur si la locale demandée est invalide.

• L’ouverture d’un chemin se finissant par un / avec open() échoue si le fichier n’est pas un dossier (par exemple open("/home/user/foo.txt/")).

• Validation du paramètre “how” de la fonction shutdown() et retour d’une erreur si le paramètre n’est pas une valeur connue.

• Les queues d’évènement créées par kqueue ne sont pas conservées lors d’un fork (même comportement que les BSD).

• Un socket sur lequel il n’y a jamais eu d’appel à listen() ou connect() ne doit pas déclencher les erreurs EPIPE ni ENOTCONN.

• La fonction socket() retourne maintenant les bons codes d’erreurs détaillés si elle ne peut pas créer le socket: EPROTOTYPE si le type de protocole est inconnu, EPROTONOSUPPORT s’il est connu mais pas disponible, EAFNOSUPPORT si la famille d’adresse n’est pas disponible. Auparavant, tous ces cas renvoyaient EAFNOSUPPORT.

• Amélioration de la gestion des erreurs dans accept()

• Gestion de cas particuliers pour bind() en UDP

• Ajout de l’option RTLD_GROUP pour dlopen(). Il s’agit d’une extension développée par Solaris qui permet d’avoir plusieurs espaces de noms pour la résolution de symboles lors du chargement de bibliothèques partagées. En particulier, dosemu l’utilise pour fournir aux programmes DOS une bibliothèque C indépendante de celle de l’hôte (fournissant donc des fonctions memcpy, memset… qui entreraient en conflit avec celles de l’hôte). L’implémentation est triviale, car le même comportement était déjà en place pour la gestion des add-ons de BeOS; il n’était simplement pas accessible au travers de l’API POSIX dlopen(). Linux implémente ce flag sous un autre nom, cependant, la documentation de la glibc n’est pas correcte, et FreeBSD a implémenté ce qui est documenté pour la glibc avec le même nom. C’est pourquoi le nom utilisé par Solaris, qui n’est pas ambigu, est utilisé pour l’instant, en espérant que la méprise entre Linux et FreeBSD pourra être corrigée.

• sethostname() retourne une erreur si le hostname proposé est trop long (auparavant il était simplement tronqué).

Intégration des changements de POSIX-2024

La spécification POSIX a été mise à jour en 2024. Cette mise à jour est assez importante grâce à un changement de la méthode de travail de l’Austin Group qui maintient la spéficication. Le groupe de travail a ouvert un bug tracker sur lequel il est possible de remonter des problèmes et de proposer des améliorations (à conditions que ces dernières soient déjà implémentées sous forme d’extensions sur un assez grand nombre de systèmes).

Cela a permis à plus de monde de prendre part à la spécification et de standardiser beaucoup de nouvelles choses. Haiku intègre ces changements petits à petits, parfois par anticipation, parfois parce que l’extension correspondante était déjà disponible, et parfois parce que le portage d’un logiciel le nécessite.

• Ajout de O_CLOFORK, MSG_CMSG_CLOEXEC, et MSG_CMSG_CLOFORK pour fermer des descripteurs de fichiers lors d’un fork (équivalent de O_CLOEXEC qui ferme lors d’un exec, typiquement après un fork). Au passage, ajout dans la libbsd de closefrom() et closerange(), ces deux fonctions permettant de lancer des tests développés pour BSD pour ces nouveaux drapeaux.
• Ajout de fdatasync(), une fonction qui s’assure que le contenu d’un fichier est bien enregistré sur disque et pas seulement dans le cache.

Améliorations sur la gestion de la mémoire

La gestion de la mémoire est un sujet central pour un système POSIX. L’API proposée (malloc, realloc, calloc et free) est à la fois très simple d’utilisation et très générique. Elle a donc tendance à être très sollicitée par les applications, ce qui en fait un composant critique de l’optilisation des performances du système. De plus, les applications sont de plus en plus consommatrices de mémoire et le matériel a tendance à en contenir de plus en plus.

L’allocateur mémoire a été remplacé il y a quelques mois, l’ancien allocateur hoard2 ne permettant pas d’agrandir dynamiquement l’espace alloué à une application. Après plusieurs essais, c’est pour l’instant l’allocateur d’OpenBSD qui a été retenu. En effet, beaucoup d’allocateurs plus modernes supposent un espace d’adressage 64 bit et sont peu économes en termes de réservation d’espace mémoire.

Cependant, même l’allocateur d’OpenBSD montrait ses limites sur les systèmes 32 bit. Son paramétrage a été amélioré, et d’autres modifications ont également été faites pour réduire la fragmentation de l’espace mémoire. Cela corrige des problèmes ou GCC ne parvient pas à allouer assez de mémoire lors de la compilation de très gros fichiers (par exemple lors de la compilation de clang ou de webkit). Il reste recommandé de désactiver l’ASLR (randomization de l’espace d’adressage) dans les cas où on a besoin de beaucoup de mémoire pour une application 32 bits.

Noyau

Le noyau de Haiku est un noyau monolithique tout à fait classique pour un système UNIX. Il permet le chargement dynamique de modules, et fournit une API relativement stable pour ces derniers, ce qui permet de maintenir des pilotes facilement en dehors du dépôt de sources de Haiku.

Correction de problèmes causant le kernel panic « failed to acquire spinlock for a long time » lorsque l’affichage à l’écran des logs du noyau est activé.

Ajout d’assertions supplémentaires dans le code de gestion de la mémoire virtuelle pour essayer de détecter des problèmes au plus tôt et avant de risquer de corrompre des données importantes.

Correction de l’affichage des paramètres des appels systèmes dans strace sur x86.

Correction de problèmes dans la gestion des permissions pour write_stat (modification des informations sur un fichier comme la date de modification) dans le noyau ainsi que dans les systèmes de fichiers RAMFS, BFS et EXT4. Cela corrige des comportements étranges observés lors de l’utilisation de rsync.

Ajout d’un test vérifiant le bon fonctionnement des exceptions remontées par le FPU lors de calculs en virgule flottante (ces exceptions sont un peu difficiles à traiter dans un système multitâche, et en particulier dans Haiku où le code du noyau peut lui-même utiliser le FPU alors que ce n’est pas le cas pour d’autres systèmes).

Correction de problèmes liés au découpage et au redimensionnement des areas (zones de mémoires allouées par les APIs prévues à cet effet de BeOS, ou indirectement par mmap et d’autres fonctions permettant de manipuler l’espace mémoire). Cela corrige des problèmes pour RAMFS ainsi qu’un kernel panic observé lors du lancement de dosemu.

Correction de problèmes avec les areas en lecture seule, qui pouvaient aboutir dans certains cas à une sous-évaluation de la mémoire utilisée, aboutissant à un kernel panic, car il n’y a plus de mémoire disponible à un moment où le noyau ne s’y attend pas. Cela a été mis en évidence en particulier avec l’utilisation mémoire de certains navigateurs web, qui ont tendance à gérer la mémoire directement sans passer par l’allocateur standard du système, pour des raisons de performance.

Remise en route de guarded_heap (un allocateur mémoire qui détecte les dépassements de buffers, au prix d’une consommation mémoire fortement augmentée). Correction de problèmes mis en évidence par cet allocateur dans quelques pilotes.

Dans la structure mcontext/ucontext passée aux fonctions de traitement de signaux, ajout de plusieurs registres manquants (registres de segments, addresse de faute…). Cela est utilisé par le JIT de dosemu et va probablement permettre d’utiliser le JIT dans d’autres applications également. En effet, une approche possible pour le JIT est de déclencher volontairement un signal, afin d’intercepter l’état des registres, éventuellement de le manipuler, puis de reprendre l’exécution là où elle s’était arrêtée.

Ajout de vérification de permissions manquantes dans l’appel système get_extended_team_info.

Correction d’une possible fuite d’un descripteur de fichier dans le VFS.

Bootloader

Mise à 0 de tous les registres non utilisés lors de l’appel de fonctions du BIOS, afin d’aider à investiguer des problèmes avec certains BIOS capricieux.

Amélioration des messages d’erreurs lorsque le bootloader ne parvient pas à charger le fichier ELF du noyau. Le chargeur de fichiers ELF du noyau est volontairement incomplet pour simplifier les choses (après tout, il a besoin seulement de charger le noyau), mais cela pose problème lors de mises à jour de GCC ou lors du portage sur de nouvelles architectures, si l’organisation du fichier ELF du noyau se trouve modifiée.

Correction de problèmes de compilation lorsque des logs de debug optionels sont activés.

Documentation

La documentation de Haiku se découpe principalement en trois parties:

• Un guide de l’utilisateur,
• Une documentation d’API pour les développeurs d’applications,
• Une documentation d’implémentation pour les développeurs du système lui-même.

API (Haiku book)

Documentation de la classe BControl (classe abstraite qui fournit l’API standard de la plupart des contrôles utilisables dans l’interface graphique, les rendant interchangeables dans une certaine mesure).

Documentation de AdoptSystemColors et HasSystemColors pour la classe BButton.

Ajout de documentation pour les extensions à dlfcn.h par rapport à ce qui est déjà spécifié par POSIX.

Environnement de compilation

Haiku est écrit en C++ et utilise jam (un concurrent de make) comme outil principal de compilation. Cet outil a été retenu, car il permet de définir des règles de compilation génériques et réutilisables pour faire toutes sortes de choses. La compilation de Haiku pouvant mettre en jeu trois compilateurs différents (un pour le système hôte, un pour le système Haiku cible, et un troisième pour la couche de compatibilité avec BeOS), la plupart des autres outils ne répondent pas bien aux besoins.

Suppression de règles Jam redondantes. Jam repose sur des règles nommées pour savoir quelles actions sont nécessaires pour générer une cible à partir de sources. Les règles “Application”, “Server”, “Preferences” et “Executable” étaient toutes identiques, elles ont donc toutes été remplacées par “Application” pour simplifier le système de build.

Correction de “warnings” du compilateur pour des variables inutilisées et suppression de code mort (dans le cadre du maintien d’un code propre et lisible, une tâche plus ou moins continue pour suivre l’évolution des bonnes pratiques, la disponibilité de nouveaux outils d’analyse, et absorber la dette technique qui peut s’accumuler au cours d’un projet aussi ancien).

Début de support pour GCC 15: il est ajouté dans la liste des versions du compilateur reconnues pour le système hôte, ce qui permet de compiler Haiku depuis un système Linux très récent. L’intégration en tant que compilateur cible viendra plus tard.

Remplacement de la commande which utilisée dans certains scripts de build par l’équivalent command -v, ce qui évite une dépendance à une commande non standard qui n’est pas forcément installée par défaut partout.

Dans le makefile engine (un template de makefile proposé pour développer facilement des applications pour Haiku), ajout de documentation et d’exemples pour les variables INSTALL_DIR et TARGET_DIR.

Portage de Haiku sur d’autres CPUs

RISC-V

Correction d’un problème dans un script de link qui empêchait le démarrage du noyau.

Mise à jour de paquets utilisés pour compiler le système de base.

Mise en place d’un serveur de compilation de paquets pour RISC-V, ce qui permet de remplir le dépôt de paquets pour cette architecture et d’envisager une version officielle de Haiku pour RISC-V lors de la prochaine version bêta. L’architecture RISC-V s’ajoutera ainsi au x86 (32 et 64 bit) déjà supporté.

Précédemment chez Debian… Le contrat social a été modifié afin de permettre l’inclusion de microprogrammes non libres dès l’installation. « Les médias officiels peuvent inclure des microprogrammes qui autrement ne font pas partie du système pour permettre l’utilisation de Debian avec un matériel qui a besoin de ces microprogrammes ». (cf. épisode 12)

Debian GNU/Linux 13 — nom de code : Trixie — est sortie en version stable le 9 août 2025.

Cette nouvelle version repose sur un noyau Linux 6.12 (LTS) et la bibliothèque C de GNU 2.41 ; GCC 14.2, OpenJDK 21, Emacs 30.1 et VIM 9.1 sont inclus dans la distribution.

En termes d’environnements de bureau, GNOME 48, KDE Plasma 6.3 et Xfce 4.20 sont présents avec LibreOffice 25 et de nombreuses applications comme GnuCash 5.10, GIMP 3.0.4, Inkscape 1.4.

La distribution contient 69 830 paquets dont 14 116 nouveaux. Et pour gérer l’ensemble, APT a été mis à jour (version 3.0.3).

En termes de plateformes : PC 64 bits (amd64), ARM 64 bits (arm64), ARM EABI (armel), ARMv7 (ARM avec unité de calcul flottant, armhf), PowerPC 64 bits petit-boutiste (ppc64el), RISC-V 64 bit petit-boutiste (riscv64), IBM System z (s390x). L’architecture i386 n’est plus prise en charge comme les autres : pas d’installateur et moins de paquets sont disponibles, i386 est désormais destinée uniquement à être utilisée sur les processeurs 64 bits (amd64).

Le thème graphique de Debian 13 s’appelle Ceratopsian en référence à Trixie le triceratops de Toy Story 3.

Pour éviter le [[bug de l’an 2038]], Debian a basculé son horloge en 64 bits.

La précédente version stable (Bookworm) va être maintenue jusqu’en juin 2026, puis jusqu’en juin 2028 par le programme LTS.

Un statut concernant XMPP est détaillé pour les clients, serveurs, bibliothèques et passerelles/transports disponibles avec Trixie.

La licence professionnelle « CoLibre » (Métiers de la communication, conduite de projets et logiciels libres) ouvre sa seconde session de candidature jusqu’au 25 août 2025.

Pour mieux connaître ce parcours de formation, pour y candidater, pour proposer des alternances ou des projets tuteurés, des visios sont organisées pendant l’été.

Elles auront lieu le 24 juillet et le 18 août à 18h.

La licence pro forme en un an au métier de chef·f de projets en communication à l’ICOM (Université Lyon2) pour des personnes ayant acquis un bac+2 quelque qu’il soit.

Pendant une année, la formation organise un parcours varié pour acquérir et affirmer des compétences professionnelles dans les domaines de la communication, de la conduite de projet et les pratiques numériques.

Au fil du parcours, les étudiants et étudiantes vont aussi approfondir au choix une spécialisation : création numérique (PAO, infographie, audio-visuel, multimédia…), organisation (ressources humaines, pratique du changement, didactique, comptabilité…), développement (programmation, développement web, administration système…), événementiel (mercatique, planification, réseaux sociaux, gestion événement…).

Chaque fois que l’on utilise des logiciels ou des applications, elles sont systématiquement libres pour ajouter une connaissance approfondie et choisie du numérique en plus d’une approche éthique et inclusive.

Ce parcours est ouvert à toute personne ayant un bac+2 et elle peut être suivi en alternance, en formation continue ou en parcours classique.

À l’issue de la formation, les étudiantes et étudiants sont diplômés à Bac+3.

Attention la formation est réalisée en présentiel à l’Université Lyon2.