Notes de version 0.9.3 bêta

Date de publication : 21 mai 2026
Version précédente : 0.9 Beta (31 décembre 2024)
Version suivante : 0.9.4 Beta (12 septembre 2026)

Il s’agit de la version la plus importante de l’histoire de Ditana. Presque tous les sous-systèmes ont été modifiés, et l’architecture a été fondamentalement réorganisée autour du principe de la configuration sous forme de données. Cette page présente les points forts ; la liste complète des modifications se trouve dans l’historique Git de ditana-installer et de ditana-config.

Le grand changement : la configuration sous forme de données

Le plus grand changement depuis la 0.9.0 concerne l’architecture. Dans la 0.9.0, les personnalisations de Ditana se trouvaient dans des paquets Arch monolithiques – tout ce que le programme d’installation voulait mettre en place devait être intégré en dur dans un PKGBUILD. Il était donc difficile de combiner la personnalisation du bureau, le choix du navigateur, la sélection du terminal et des dizaines d’autres points d’intervention.

Dans la 0.9.3, tout cela se trouve dans un nouveau dépôt aux versions gérées séparément, ditana-config, sous forme de données structurées en KDL v2. Chaque paramètre, chaque dépendance, chaque script de cycle de vie est déclaratif. Le code du programme d’installation est petit ; la base de connaissances en est le cerveau.

Deux conséquences méritent d’être relevées :

Les améliorations sont publiées sans produire de nouvelle image ISO. Le programme d’installation télécharge la dernière archive de configuration à l’exécution (avec, comme solution de repli, la version fournie avec l’image ISO). Une correction de bogue fusionnée dans ditana-config un lundi parvient aux nouvelles installations le mardi.
Contribuer est considérablement plus facile. La plupart des contributions ne touchent qu’un seul fichier KDL. Le README.md de ditana-config présente le modèle de données en détail.

Quatre bureaux, sur un pied d’égalité

La version 0.9.0 ne fournissait que XFCE. La version 0.9.3 fournit quatre environnements de bureau – XFCE (X11), Wayfire, Niri et COSMIC (tous sous Wayland) – installables séparément ou en parallèle. L’écran de connexion affiche ceux que vous avez installés.

Wayfire et Niri sont parfois écartés comme des environnements incomplets. Ditana s’attaque directement à cette lacune : une configuration soignée de waybar avec des icônes assorties au thème, nwg-launcher et nwgbar pour lancer les applications et gérer l’alimentation, des valeurs par défaut judicieuses pour les quatre – de sorte que les quatre sont des options à part entière, et non des démonstrations technologiques.

lightdm a été remplacé par greetd avec tuigreet, qui s’intègre proprement à uwsm pour la gestion du cycle de vie des sessions sous Wayland.

Installation adaptée au matériel

Deux étapes de détection sont nouvelles ou considérablement étendues :

La détection NVIDIA croise désormais, au moment de l’installation, la liste des identifiants PCI d’open-gpu-kernel-modules et la page NVIDIA consacrée aux anciens GPU, puis recommande l’une de quatre options : nvidia-open-dkms (la nouvelle valeur par défaut pour Turing et les générations suivantes), nvidia-580xx-dkms (Maxwell/Pascal/Volta), nvidia-470xx-dkms (Kepler) ou nouveau. Les choix de noyau incompatibles avec DKMS sont refusés, avec une explication.
La détection des machines virtuelles détermine un certain nombre de choix qui en découlent (replis sur le rendu logiciel, fstrim.timer désactivé).

La détection et l’atténuation des vulnérabilités du processeur – déjà une marque de fabrique de Ditana dans la 0.9.0 – restent inchangées. Consultez la page sur les mesures d’atténuation du processeur pour la justification complète, vulnérabilité par vulnérabilité.

Disposition du clavier de la console, générée avec précision

Une amélioration modeste mais visible : vconsole.conf est désormais généré par ckbcomp à partir de la disposition de clavier X11 choisie par l’utilisateur. L’approche précédente procédait par approximation ; celle-ci est exacte, ce qui compte pendant l’installation (les mots de passe sont saisis dans la console virtuelle Linux) et pour l’utilisation de la console virtuelle après l’installation. Cela répond à une critique formulée dans un commentaire sur la 0.9.0 publié sur DistroWatch.

Durcissement du système – une nouvelle boîte de dialogue

C’est une véritable nouveauté de la 0.9.3. Le programme d’installation de la 0.9.0 couvrait les mesures d’atténuation des vulnérabilités du processeur, mais n’avait pas de boîte de dialogue de durcissement à usage général. La version 0.9.3 ajoute une section System Hardening complète sous Expert Settings, avec des options documentées basées sur sysctl :

Espaces de noms utilisateur non privilégiés désactivés (unprivileged_userns_clone=0) par défaut, avec une explication détaillée du compromis concernant les navigateurs et Flatpak.
ptrace restreint (yama.ptrace_scope=2 par défaut, =0 pour le profil développeur).
Pointeurs du noyau masqués, dmesg restreint, kexec désactivé.
FIFO et fichiers ordinaires protégés dans les répertoires dotés du sticky bit (au-delà de la protection par défaut de Linux pour les liens physiques et symboliques).
Pile réseau durcie (SYN cookies, pas de redirections ICMP, pas de routage par la source, filtrage par chemin inverse).
JIT BPF restreint, assouplissement facultatif de perf_event_paranoid pour les développeurs.
hardened_malloc en option, en variante complète ou allégée, ainsi que mimalloc en option pour les configurations axées sur les performances.

Chaque option est présentée sous forme de liste à cocher avec une documentation complète – y compris les compromis que vous acceptez lorsque vous la cochez ou la décochez.

Prise en charge de Flatpak, intégrée de bout en bout

Les Flatpak peuvent désormais être déclarés dans la configuration aux côtés de arch-packages et aur-packages. L’installation a lieu au premier démarrage via un service dédié, ditana-flatpak-finalize.service (qui bloque l’écran de connexion jusqu’à la fin, pour que l’utilisateur ne soit pas surpris par des installations en cours de session).

Les Flatpak sont préférés aux équivalents disponibles uniquement dans l’AUR lorsqu’ils existent – sauf lorsque le bac à sable d’un Flatpak ne peut pas fonctionner avec le durcissement par défaut de Ditana. Brave Browser en est l’exemple documenté : son Flatpak nécessite unprivileged_userns_clone=1, c’est pourquoi Ditana fournit plutôt brave-bin depuis l’AUR. Les compromis sont détaillés dans la page de bonnes pratiques AUR ou Flatpak.

Associations MIME par défaut dynamiques

Les applications par défaut des types MIME sont désormais calculées à partir des composants installés au lieu d’être codées en dur. Installez LibreOffice → LibreOffice gère .docx. Installez plutôt ONLYOFFICE → ONLYOFFICE s’en charge. Installez Thunar → Thunar ouvre les répertoires. Installez COSMIC Files → COSMIC Files les ouvre. Le tout est composé à partir des déclarations KDL.

Émulateur de terminal, un choix à part entière

Le programme d’installation propose désormais six émulateurs de terminal, avec une matrice de décision établie avec soin : kitty (par défaut, X11+Wayland), foot (Wayland uniquement, léger), Alacritty (GPU, minimaliste), WezTerm (complet, multiplexeur), Ghostty (moderne, nécessite OpenGL 4.3+) et COSMIC Terminal. La norme xdg-terminal-exec est utilisée de manière cohérente. Pour les terminaux Wayland uniquement, kitty est automatiquement installé comme solution de repli pour X11 si XFCE est également sélectionné – sans jonglage manuel.

Assistant AUR : pikaur → paru

pikaur a été remplacé par paru. L’élément déclencheur a été pachub (le navigateur graphique de paquets Arch, épinglé dans le panneau de chaque bureau aux côtés de bazaar pour Flatpak), qui ne prend en charge que yay ou paru. Le choix de paru convenait également mieux aux autres besoins de Ditana.

Gestion des mots de passe

Vous pouvez désormais passer outre la vérification stricte du mot de passe par pwscore pour le compte utilisateur si vous avez une bonne raison de le faire. La vérification reste obligatoire lorsque le chiffrement intégral du disque est activé – dans ce cas, un mot de passe faible réduit activement la sécurité.

Cela répond à plusieurs signalements d’utilisateurs de la 0.9.0 concernant des installations interrompues parce que les utilisateurs ne parvenaient pas à atteindre le minimum pwscore par défaut.

Tickets GitHub fermés

Dix tickets signalés par des utilisateurs de la 0.9.0 sont traités dans la 0.9.3 – corrections de bogues et demandes de fonctionnalités. La liste est disponible dans le gestionnaire de tickets du programme d’installation.

En coulisses

Ansible → Sparrow6. La logique de gestion de configuration qui personnalise des fichiers comme mkinitcpio.conf est passée d’Ansible à Sparrow6, avec des contributions importantes d’Alexey Melezhik. Sparrow6 sert également à tester les configurations automatisées elles-mêmes. La migration supprime une dépendance d’exécution à Python et produit des résultats de test plus lisibles.
Remerciements. Merci à Alexey Melezhik pour le travail sur Sparrow6 et sa collaboration continue. Merci à Thomas Zipproth pour ses tests et ses retours réguliers. Merci à toutes les personnes qui ont ouvert un ticket sur la 0.9.0 – chacun d’eux a été examiné, et la plupart sont désormais fermés.

Un peu d’histoire

Lorsque Ralf Hersel m’a interviewé pour gnulinux.ch début 2025 au sujet de Ditana 0.9.0, il a commencé par dire qu’il avait gagné un pari : il avait prédit qu’une distribution Linux avec IA intégrée sortirait avant la fin de 2024, et la 0.9.0 (31 décembre 2024) est arrivée juste à temps.

Ditana fournit bel et bien le Ditana Assistant, facultatif, qui utilise un modèle Ollama local (ou tout point de terminaison compatible avec OpenAI) pour générer des commandes shell. Il est utile, mais je serais le premier à dire que parler de « distribution IA » est exagéré – l’assistant dispose d’un contexte système limité, et une distribution qui intègre véritablement l’IA est un projet distinct que j’explorerai peut-être plus tard (l’analyse automatisée des journaux étant la piste la plus réaliste). Pour l’instant : c’est un outil pratique, épinglé dans le panneau si vous l’activez.

Mise à niveau depuis la 0.9.0

Il n’y a pas de mise à niveau sur place. L’architecture a trop changé. Une nouvelle installation, en s’appuyant sur un instantané Timeshift / ZFS de votre /home (ou de votre partition de données, quelle qu’elle soit), est la voie prise en charge.

Cette traduction a été réalisée par une machine. Les lecteurs l’améliorent sur Weblate.