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ées. 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.