Ubuntu Lost Its Identity. Unity Was It Source Code Ep. 18

Voici l’analyse détaillée de la transcription de la vidéo YouTube, structurée pour un administrateur système.

SYNTHÈSE STRUCTURÉE

Dirty Frag : une vulnérabilité root locale critique

Une nouvelle faille de sécurité, baptisée “Dirty Frag”, a été divulguée publiquement le 7 mai 2026. Elle combine deux CVE (CVE-2026-43284 et CVE-2026-43500) qui permettent à un utilisateur local non privilégié d’obtenir les droits root sur la quasi-totalité des distributions Linux majeures (Ubuntu, Fedora, RHEL, etc.). Le mécanisme exploite deux sous-systèmes du noyau : XFRM/ESP (gestion du trafic IPSec) et RXRPC (utilisé par le système de fichiers distribué AFS). Le problème réside dans la gestion du cache de pages (page cache) : lorsque certains chemins de déchiffrement opèrent sur des tampons qui ne sont pas exclusivement possédés par le noyau, un processus non privilégié peut conserver une référence aux données en clair et obtenir une primitive d’écriture dans le cache de pages. L’intervenant précise : “Dirty Frag extends the same bug class as Dirty Pipe and the recent Copy Fail, but it is more reliable because it does not depend on narrow timing windows.” Contrairement à Copy Fail, cette vulnérabilité fonctionne même si le module ALGIF_AEAD n’est pas présent, rendant la mitigation précédente inefficace.

Mesures d’urgence pour Dirty Frag

Pour les administrateurs système gérant des machines avec des utilisateurs locaux non fiables, l’intervenant recommande deux actions immédiates. Premièrement, appliquer un blacklist des modules concernés via /etc/modprobe.d/ :

blacklist esp4
blacklist esp6
blacklist rxrpc

Ensuite, mettre à jour le noyau dès que la distribution concernée publie le correctif. Le correctif pour la première CVE a atterri dans la branche principale du noyau le 8 mai, tandis que celui pour la seconde était encore en cours de finalisation. L’intervenant insiste sur le fait que la sécurité est un processus, pas un état : “Linux is not secure by definition. Security is a process, not a state.”

GitHub : la fin d’une lune de miel ?

Mitchell Hashimoto, fondateur de HashiCorp et créateur du terminal Ghostty, a publié une longue explication de sa décision de quitter GitHub après 18 ans d’utilisation (il était l’utilisateur numéro 1299). La raison n’est pas idéologique mais pratique : pendant un mois entier, il a tenu un journal personnel où il marquait un “X” chaque jour où une panne de GitHub avait un impact négatif sur son travail. “Almost every single day had an X.” Le déclencheur final a été la panne majeure du 27 avril 2026. L’intervenant analyse ce phénomène comme la conséquence logique de laisser une entreprise (Microsoft) contrôler son infrastructure : “It is simply the logic of capitalism applied to software. You buy the platform, you integrate it into your products, you use it to push your services.”

Financement des mainteneurs open source : le programme Sovereign Tech Standards

L’Agence allemande pour les technologies souveraines (Sovereign Tech Agency) a ouvert les candidatures pour son programme “Sovereign Tech Standards”. L’objectif est de rémunérer jusqu’à 10 mainteneurs de projets open source pour participer aux travaux de normalisation à l’IETF, au W3C et à l’ISO. Il ne s’agit pas d’un simple remboursement de frais de déplacement, mais d’un salaire mensuel fixe compris entre 4 800 et 5 200 euros, avec formation, mentorat et prise en charge des frais de réunion en personne. L’intervenant souligne l’importance de cette initiative : “HTTP, TLS, HTML, CSS, Web Assembly. All of this exists because someone dedicated thousands of hours to writing specifications, negotiating text, building consensus. Paying them is not a luxury. It is systemic hygiene.”

Hyperland 0.48 : la bascule vers Lua et l’API de disposition

La nouvelle version d’Hyperland introduit un changement majeur : le passage à une configuration basée sur Lua. L’ancien format Hyperlang reste supporté pour l’instant, mais la direction est clairement fixée. Avec Lua arrive une API de disposition (layout API) qui permet aux utilisateurs de définir des dispositions de fenêtres personnalisées directement dans la configuration, applicables par espace de travail, par moniteur ou globalement. Ces dispositions fonctionnent comme des dispositions natives d’Hyperland mais restent entièrement sous le contrôle de l’utilisateur. Cette version ajoute également le support des profils ICC par sortie, la gestion des couleurs FP16 par défaut pour les écrans gérés en couleur, des gestes de défilement de pavé tactile améliorés, et de nouvelles options pour déplacer les fenêtres entre les groupes. L’intervenant qualifie Hyperland de “most interesting desktop project in the Linux world over the last 10 years” pour un utilisateur technique travaillant sur un ordinateur portable avec un clavier.

Le conflit génétique entre Void Linux et Hyperland

L’intervenant partage son expérience personnelle de tentative de compilation d’Hyperland sur Void Linux, qui s’est soldée par un échec après avoir dû patcher GCC. Il explique que cette incompatibilité technique n’est pas accidentelle mais “almost genetic”. Void Linux privilégie la stabilité, le minimalisme et ne tire aucune dépendance sans raison sérieuse. Hyperland, à l’inverse, exige des bibliothèques à leur dernière version, avec des dépendances qui croissent à chaque release. L’intervenant résume : “Void is stability, minimalism, no dependency pulled in without a serious reason. Hyperland is libraries at their latest version. Dependencies that grow with every release. An ecosystem that moves fast and waits for no one.”

Unity ressuscité : une preuve de concept sous Wayland

Un contributeur de la communauté Ubuntu, qui travaille également sur le thème Yaru et sur Vanilla OS, a publié une vidéo montrant une expérience personnelle : la reconstruction du shell Unity en utilisant Wayfire comme compositeur Wayland, GTK4 Layer Shell et libadwaita pour les widgets. Le résultat est immédiatement reconnaissable : le lanceur vertical, le panneau supérieur, le dash. L’intervenant précise qu’il ne s’agit ni d’un fork, ni d’un projet officiel, ni d’un dépôt public : “It is code written over a weekend.” Techniquement, Unity n’était pas un environnement de bureau traditionnel mais un plugin pour Compiz, le compositeur X11 que Canonical avait placé au centre de son architecture graphique. La dernière version d’Ubuntu utilisant Compiz avec Unity était la 16.04.

Pourquoi Unity a échoué (et pourquoi il manque)

L’intervenant analyse les raisons de l’échec d’Unity. Le problème principal était que le projet n’était pas prêt : instable, peu performant sur du matériel modeste à cause du poids de Compiz, et surtout mal expliqué. “Canonical presented it as a fait accompli, not as a proposal.” Les critiques étaient réelles : le lanceur latéral gauche fixe (impossible à déplacer ou redimensionner) posait problème sur les écrans non panoramiques. L’intégration de la recherche Amazon dans le dash à partir d’Ubuntu 12.10 était une décision commerciale si mal communiquée qu’elle a endommagé la réputation du projet de manière disproportionnée. Surtout, Unity était le bureau de Canonical, pas celui de la communauté : “open source in its license, but closed in its decisions.” Pourtant, Canonical a abandonné Unity en 2017, précisément au moment où le projet avait atteint une maturité sérieuse.

Le vide laissé par Unity dans le paysage des bureaux Linux

L’intervenant avance une provocation : et si Canonical décidait de parier à nouveau sur Unity maintenant ? Il constate que GNOME continue de sortir des versions en tournant autour du même paradigme,