L'Agenda du Libre

Nous en avions parlé en mars dans l’article « AMD mise tout sur RADV » : Maintenant qu’AMD a remplacé son pilote graphique AMDVLK sous Linux par le pilote RADV de chez Mesa, il est techniquement possible de faire de même sous Windows, unifiant les solutions graphiques sur un pilote libre quel que soit le système…

RADV est le pilote graphique libre fournissant la prise en charge de l’accélération 3D via Vulkan sous Linux. Il est développé communautairement chez Mesa.

Et cette fois-ci, c’est Valve qui mise tout sur RADV : l’éditeur de la plate-forme de jeu vidéo Steam finance des travaux explorant la faisabilité de RADV sous Windows !

L’automne arrive, mettons nos cartes graphiques AMD bien au chaud auprès de nos pilotes libres…

Cette dépêche est aussi l’occasion de détailler l’implication de Valve dans Mesa ainsi que la présence grandissante de Mesa dans le marché des pilotes graphiques, qui s’étend désormais bien au-delà de Linux !

• lien nᵒ 1 : Cracking Windows Open: Porting RADV to WIN32 — Collabora
• lien nᵒ 2 : Valve Sponsors Work Bringing Open-Source RADV Driver To Windows — Phoronix
• lien nᵒ 3 : AMD mise tout sur RADV  — LinuxFr.org
• lien nᵒ 4 : La pile graphique d’AMD sous Linux est désormais complètement libre — LinuxFr.org

Sommaire

• Vulkan, la solution graphique multiplateforme
• RADV, le pilote Vulkan libre pour carte AMD de chez Mesa
  • RADV, le pilote qui s’impatientait d’AMD
  • RADV, le pilote qui a déjà remplacé AMDVLK sous Linux
• RADV à l’attaque de Windows
  • L’expérimentation de Faith Ekstrand
  • La confirmation de Louis-Francis Ratté-Boulianne
  • Une alternative à Dozen
• L’implication de Valve dans RADV et Mesa
• Mesa part conquérir le monde
  • Et pour OpenGL sous Windows ?
  • Et DirectX 12 dans tout ça ?
  • Tout ce qui tourne sur RADV
  • Et pour Vulkan sur macOS ?
  • Et pour Intel et Nvidia sous Linux et Windows ?
  • Mesa prend le contrôle des pilotes Vulkan

Pour simplifier la rédaction et la lecture, cette dépêche fait le choix éditorial d’appeler « pilote graphique » un pilote qui implémente des interfaces de programmation graphique (Vulkan, DirectX, OpenGL, etc.), et pas seulement un pilote impliqué dans le pilotage d’une carte graphique. Ainsi l’expression « pilote graphique » est utilisée pour être distinguée du « pilote noyau » (ou KMD, Kernel Mode Driver) qui s’interface directement avec le matériel mais ne fournit pas d’interface de programmation graphique comme Vulkan et les autres.

Vulkan, la solution graphique multiplateforme

Vulkan est une API graphique multiplateforme utilisée pour accélérer des applications graphiques comme des jeux vidéo, les effets de composition de votre bureau, des applications de rendu 3D comme Blender, ou encore pour accélérer le calcul (Vulkan compute peut faire tourner des moteurs de LLM sur votre machine, par exemple).

RADV, le pilote Vulkan libre pour carte AMD de chez Mesa

À l’origine, le pilote Vulkan maison de chez AMD était AMDVLK, il était utilisé sous Linux et sous Windows. Initialement propriétaire, la version Linux avait été ensuite libérée.

Mais si vous utilisez Vulkan sous Linux, vous utilisez RADV, pas AMDVLK. Que s’est-il donc passé ?

RADV, le pilote qui s’impatientait d’AMD

En 2016, s’impatientant de cette libération promise qui ne venait pas encore, David Airlie — contributeur à Mesa — avait initié avec Bas Nieuwenhuizen le projet RADV, un compétiteur pour AMDVLK. Phoronix décrivait la situation ainsi en 2016 :

Plusieurs mois avant même la publication officielle de la spécification Vulkan, AMD avait annoncé qu’ils lanceraient dans un premier temps un pilote Linux Vulkan à code source fermé, qui serait ensuite ouvert. Plus de six mois se sont écoulés depuis la sortie de Vulkan 1.0, mais ce pilote Linux Vulkan n'a toujours pas été libéré, et AMD n'a pas non plus indiqué quand cette mise à disposition du code pourrait effectivement avoir lieu.

En l'absence de pilote Radeon Vulkan open source, David Airlie et Bas Nieuwenhuizen ont entrepris de développer leur propre pilote Radeon Vulkan « communautaire », au moins à titre de solution provisoire et éventuellement pour faire pression sur AMD afin qu’ils publient leur pilote Vulkan officiel. Bas Nieuwenhuizen est un contributeur indépendant, tandis que David Airlie est le responsable du sous-système DRM et un développeur chez Red Hat qui participe depuis longtemps aux efforts de développement de pilotes Linux AMD/ATI open source.
-- https://www.phoronix.com/review/radeon-vulkan-radv (30/08/2016)

David avait écrit à l’époque sur son blog :

J'attendais qu'un pilote open source fasse son apparition quand je me suis rendu compte que je ferais mieux de le développer moi-même. Après en avoir discuté avec Bas, nous avons décidé de voir jusqu'où nous pouvions aller.
-- https://airlied.livejournal.com/81460.html (20/07/2016)

RADV vient de souffler sa 10^ème bougie, et RADV a remplacé AMDVLK sous Linux et s’attaque désormais à Windows…

RADV, le pilote qui a déjà remplacé AMDVLK sous Linux

Comme rapporté dans la précédente dépêche « La pile graphique d’AMD sous Linux est désormais complètement libre », AMD avait annoncé le 21 mai 2025 que la version 25.10.1 de la suite Radeon Software for Linux serait la dernière à livrer des composants logiciels propriétaires. À l’époque AMD avait dit que « le pilote Vulkan de Mesa », (et donc, RADV) « sera officiellement pris en charge », et qu’ils abandonnaient les « pilotes OpenGL et Vulkan propriétaires ». On pouvait alors se demander ce qui adviendrait d’AMDVLK, si « le pilote propriétaire » devait s’entendre au sens de « le pilote à code fermé », ou dans le sens de « le pilote de chez AMD ».

L’histoire a montré que RADV a totalement remplacé AMDVLK sous Linux.

RADV à l’attaque de Windows

Grâce au travail préliminaire de Collabora et aux investissements de Valve pour poursuivre ces efforts, RADV pourrait bientôt être disponible sous Windows…

L’expérimentation de Faith Ekstrand

En juillet 2024 Faith Ekstrand avait proposé une requête de fusion à Mesa pour porter le pilote RADV sous Windows. Faith est un développeur de chez Collabora.

Quelques mois plus tard en octobre 2024 Faith Ekstrand avait présenté l’avancement de son travail lors de sa conférence « A little Windows with your Mesa » [pdf] lors de l’XDC (X.Org Developer's Conference). Une démonstration technique montrant une démo Vulkan tourner sous Windows 11 avec RADV avait été présentée.

Il s’agissait donc de faire fonctionner RADV sur WDDM (Windows Driver Display Model) au lieu du DRM (Direct Rendering Manager) de Linux.

Ce n’était qu’une démonstration, le code n’a jamais été fusionné dans Mesa, et la discussion n’avait pas bougé depuis. Cela prouvait pourtant que oui, cela était tout à fait faisable, et que si AMD le souhaitait, il leur suffisait de contracter avec Collabora.

La confirmation de Louis-Francis Ratté-Boulianne

C’est ce que vient de faire… non pas AMD, mais Valve, l’éditeur de la plate-forme de jeu vidéo Steam.

Comme le rapporte Phoronix :

Valve finance des ingénieurs de Collabora pour mener des travaux exploratoires préliminaires visant à porter le pilote open source Radeon Vulkan « RADV » sous Microsoft Windows.
-- https://www.phoronix.com/news/Valve-Sponsors-RADV-Windows (29/07/2026)

Le développeur Louis-Francis Ratté-Boulianne a rendu public ces travaux préliminaires dans un article sur le blog de Collabora intitulé « Cracking Windows Open: Porting RADV to WIN32 », Ouvrir une brèche vers Windows : porter RADV sur WIN32.

Louis-Francis précise que cette nouvelle expérimentation est fondée sur le travail déjà réalisé par Faith en 2024. Le projet est désormais à un niveau d’avancement élevé : le jeu Counter-Strike 2 (distribué, édité et développé par Valve) tourne déjà !

Une alternative à Dozen

Dozen (aussi connu comme VulkanOn12 chez Microsoft) est un pilote Mesa implémentant Vulkan sur DX12 (DirectX 12). Il est donc déjà possible d’utiliser un pilote libre Vulkan sous Windows, mais il est moins avancé que RADV, et il requiert le pilote propriétaire DX12 de la carte graphique, donc ici le pilote d’AMD. RADV s’interface directement avec le pilote noyau AMD sans intermédiaire graphique, permettant de bénéficier de tous les avantages de RADV déjà disponible sous Linux, dès lors que ce pilote Windows implémente des interfaces compatibles, sans dépendre des interfaces DX12 (contrôlées par Microsoft) ou du niveau d’implémentation du pilote DX12 d’AMD.

Le niveau de libération de la pile Vulkan sur AMD sous Windows peut donc être comparé ainsi :

L’implication de Valve dans RADV et Mesa

David Airlie et Bas Nieuwenhuizen ne sont pas les seules personnes ayant travaillé ou travaillant sur RADV, Samuel Pitoiset en est aussi un développeur incontournable. Samuel Pitoiset a été embauché par Valve en 2015 et est membre de la « Valve Linux driver team ». Samuel était en 2024 et en 2025 le plus gros contributeur Mesa (7.87% des commits de l’année en 2024, 6.78% en 2025).

Samuel participe aussi au développement d’ACO (Amd COmpiler), le compilateur de shader (code qui s’exécute sur la carte graphique. Principalement développé par Daniel Schürmann, le compilateur ACO a remplacé LLVM dans RADV (pilote Vulkan), et petit-à-petit, a aussi remplacé LLVM dans RadeonSI (pilote OpenGL) et dans RustiCL (pilote OpenCL). Daniel a été recruté par Valve en 2019.

Valve est un contributeur majeur de Mesa, finançant le travail de très nombreux développeurs. Il est difficile de suivre la carrière de chacun mais voici rassemblées quelques informations glanées ici ou là :

La liste est très certainement incomplète, car d’autres personnes comme Louis-Francis Ratté-Boulianne peuvent travailler sur des missions de Valve sans travailler directement pour Valve. Ces personnes travaillent pour d’autres entités intermédiaires comme Collabora ou Igalia et les relations et le détail des missions ne sont pas forcément publiques ou faciles à trouver.

Dans cette table, la période documentée tente de retranscrire les périodes de contrat. Par exemple il est connu que Charlie Turner a travaillé pour Valve sur la CI (Intégration Continue) de Mesa en 2022 et nous savons aussi qu’il travaillait déjà sur ce même projet en 2021 sans qu’il soit évident si c’était déjà à la demande de Valve ou non.

Igalia et Collabora sont des sous-traitants et intégrateurs spécialisés dans le développement de solutions libres (pas seulement graphiques).

Mesa part conquérir le monde

Si un même pilote Vulkan peut fonctionner à la fois sur Linux et Windows, d’autres pilotes pour d’autres API ou d’autres matériels peuvent-ils suivre le même chemin ?

Et pour OpenGL sous Windows ?

Il est déjà possible d’utiliser une solution Mesa pour OpenGL sous Windows, grâce au pilote GLON12 développé par Microsoft chez Mesa. GLON12 convertit à la volée les appels OpenGL vers la solution propriétaire DirectX 12, et l’on peut déjà tester cette solution grâce à pal100 qui empaquette ces pilotes pour Windows. Cela dit, c’est fragile. La rédaction a testé, et les versions actuelles ont des bugs d’affichage assez sérieux (au moins avec le pilote propriétaire AMD sous-jacent), il faut remonter à 2024 pour avoir un rendu correct.

Il existe aussi chez Mesa le pilote Zink traduisant les appels OpenGL vers Vulkan, et donc jusqu’à maintenant, vers AMDVLK sous Windows. Mais si RADV devenait une solution sérieuse sous Windows, alors Mesa pourrait fournir OpenGL sous Windows en prenant en charge toute la pile d’exécution depuis OpenGL, s’arrêtant seulement à la limite du pilote noyau Windows, sans aucun logiciel intermédiaire tiers.

Et DirectX 12 dans tout ça ?

Là encore, RADV sous Windows permettrait aussi d’utiliser une solution libre pour DirectX ! Il existe plusieurs pilotes DirectX écrits pour convertir les appels Direct3D vers Vulkan initialement développés pour être exécutés dans Wine ou Proton sous Linux. Ces pilotes DirectX sont donc déjà écrits pour tourner dans un environnement Windows. Bien qu’ils soient moins testés sur un véritable Windows que dans un environnement Wine, ils existent. RADV serait la dernière brique pour court-circuiter entièrement les pilotes propriétaires graphiques sous Windows.

La couche la plus basse, le pilote noyau AMD, resterait propriétaire.

Tout ce qui tourne sur RADV

Voici ce qui est déjà faisable sous Linux, et ce qui serait bientôt réalisable sous Windows :

Pour OpenGL et OpenCL utiliser Zink sur RADV n’est pas la solution recommandée sous Linux (mieux vaut utiliser RadeonSI et RustiCL), mais techniquement ça marche, c’est pourquoi on sait que ça pourrait aussi marcher sous Windows.

Donc grâce à Zink, Mesa pourrait fournir OpenGL sur les systèmes qui auraient RADV mais pas RadeonSI. De même pour OpenCL.

Voici un tableau plus général des opportunités que propose ou pourrait proposer l’écosystème libre (si RADV sur Windows devient viable) :

Et pour Vulkan sur macOS ?

Valve est d’abord une plate-forme de vente de jeux vidéo. Ce qui leur importe le plus, c’est que vous puissiez leur acheter des jeux (développés par eux ou par n’importe qui). À ce titre, il importe à Valve que le maximum de jeux fonctionne sur votre machine, quelle que soit votre machine. Valve peut donc, si nécessaire, décider de fournir à ses utilisateurs ses propres pilotes, distribués avec Steam.

En participant au développement de RADV sous Linux et Windows, Valve se donne le pouvoir de contrôler la qualité de la pile logicielle d’exécution des jeux qu’ils vendent, jusqu’au pilote graphique inclus.

Pour macOS, la solution n’est pas à voir du côté de RADV (les derniers macs n’ont plus de cartes graphiques AMD de toute façon), mais du côté de MolktenVK et KosmicKrisp, des pilotes libres convertissant les appels Vulkan vers l’API Metal de macOS.

Sur macOS Vulkan est déjà disponible grâce à MoltenVK, une implémentation propriétaire traduisant Vulkan pour l’API Metal de macOS. Valve a investi dans MoltenVK. Cela permet par exemple à Valve de faire tourner leur jeu Dota2 sur macOS et pouvoir continuer à le vendre aux utilisateurs de macOS sans se soucier de l’obsolétisation d’OpenGL sur macOS par Apple. Valve avait poussé à ce que MoltenVK soit libéré, ce qui fut fait en 2018 grâce à un travail conjoint de Valve, de The Brenwill Workshop (la société à l’origine de MoltenVK), LunarG et Khronos. LunarG est un autre sous-traitant spécialisé dans les solutions graphiques et Vulkan libres. Khronos est le consortium à but non lucratif définissant le standard Vulkan. Le code source de MoltenVK est hébergé par Khronos directement.

KosmicKrisp est lui un pilote Mesa qui fait de même (convertir Vulkan vers Metal) mais de façon intimement spécialisée pour les puces AGX que l’on trouve dans les ordinateurs Apple M1, M2, etc. (aussi appelé « Apple Silicon »).

Et pour Intel et Nvidia sous Linux et Windows ?

Pour les utilisateurs Linux utilisant une carte Intel ou Nvidia, il y a déjà chez Mesa le pilote Vulkan officiel ANV développé par Intel, et le pilote expérimental NVK pour Nvidia. Il y a des connexions : Faith Ekstrand avait initié NVK chez Collabora et Collabora est connu pour travailler avec Valve… RADV pour AMD avait été initié en réutilisant du code d’ANV d’Intel… Tout cet écosystème est tissé de liens profonds que ce soit en termes de relations personnelles ou de mutualisation de code.

Pour les utilisateurs Windows utilisant une carte Intel ou Nvidia, rien n’est à l’horizon du côté de chez Mesa, excepté Dozen. Il faut donc utiliser les pilotes graphiques propriétaires de chez Intel et Nvidia (que ce soit le pilote Vulkan propriétaire directement, ou le pilote DX12 propriétaire comme sous-couche à Dozen). La situation est donc pour le moment la même qu’avec AMD sous Windows jusqu’à ce que RADV devienne utilisable pour le grand public.

Mesa prend le contrôle des pilotes Vulkan

Si on se concentre uniquement sur l’API Vulkan, voici ce que pourrait proposer l’écosystème libre dans un futur proche :

C’est une très bonne nouvelle. Vulkan avait été conçue pour devenir « l’API graphique universelle », sauf qu’au final le marché était resté très divisé : DX12 sur Windows, Metal sur macOS, Vulkan ailleurs (et ne parlons même pas des consoles…). La présence de Vulkan sous Windows dépendant entièrement du bon-vouloir des fabricants de carte graphiques, et ni Apple ni les fabricants de carte graphiques n’ont jamais développé un pilote Vulkan pour macOS…

Pour un distributeur de jeu vidéo comme Valve c’est excellent : ça signifie que si nécessaire, le jeu peut être distribué avec RADV sur Windows et Linux pour les utilisateurs de cartes graphiques AMD, et MoltenVK ou KosmicKrisp sur macOS afin de fournir une expérience Vulkan finement contrôlée, et autres combinaisons sus-mentionnées. Cela permet de contrôler et donc d’assurer au maximum la compatibilité d’un jeu.

Pour les développeurs et éditeurs de jeu, le bénéfice est le même. Si nécessaire, il devient possible d’indiquer au distributeur un pilote libre à intégrer avec le jeu.

Pour le joueur, il peut utiliser lui-même une autre option s’il la préfère ou en a besoin.

Ainsi, que ce soit avec des solutions propriétaires ou libre, Vulkan est déjà disponible quasiment partout, et le devient désormais encore plus souvent sous forme de pilote libre, grâce à Khronos et Mesa.

• Dis Mesa, tu veux faire quoi cette nuit ?
• La même chose que chaque nuit, Vulkan, tenter de conquérir le MONDE !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Compte-rendu du conseil d'administration du 25 août

283e émission Libre à vous ! de l'April en direct sur radio Cause Commune 93.1 FM et DAB+ en Île-de-France, et sur le site web de la radio, mardi 8 septembre 2026 de 15 h 30 à 17 h. Le podcast de l'émission et les podcasts par sujets traités sont disponibles dès que possible, quelques jours après l'émission en général.

Au programme :

• sujet principal : le Parcours libriste de Gee, administrateur de l'April, membre de Framasoft, docteur en informatique, auteur-dessinateur sous licence libre et chroniqueur pour Libre à vous!, entre autres casquettes.
• la chronique Que libérer d’autre que du logiciel avec Antanak
• La première édition d'une nouvelle chronique Numérique, libertés et droits humains, proposée par Maryse Artiguelong, coresponsable du groupe de travail « Libertés et technologies de l’information et de la communication » pour la Ligue des Droits Humains.
• quoi de Libre ? Actualités et annonces concernant l'April et le monde du Libre

Nous contacter pour poser une question :

• nous contacter par courriel
• sur le salon web dédié à l'émission (mais nous n'y sommes pas forcément tout le temps)
• sur le salon IRC de l'April (accès par webchat)
• Vous pouvez nous laisser un message sur le répondeur de la radio en appelant le 09 72 51 55 46

Intervenir pendant le direct (mardi 8 septembre 2026 de 15 h 30 à 17 h 00) :

• connectez-vous sur le salon web #libreavous

Écouter le direct mardi 8 septembre 2026 de 15 h 30 à 17 h 00   S'abonner au podcast S'abonner à la lettre d'actus

Les ambitions de l'émission Libre à vous !

La radio Cause commune a commencé à émettre fin 2017 sur la bande FM en région parisienne (93.1) et sur Internet. Sur le site de la radio on lit : « Radio associative et citoyenne, les missions de Cause Commune sont de fédérer toutes les initiatives autour du partage et de l’échange de savoirs, de cultures et de techniques ».

Nous avons alors proposé de tenir une émission April intitulée Libre à vous ! — l'émission pour comprendre et agir avec l'April — d'explications et d'échanges concernant les dossiers politiques et juridiques que l'association traite et les actions qu'elle mène. Une partie de l'émission est également consacrée aux actualités et actions de type sensibilisation. L'émission Libre à vous ! est principalement animée par l'équipe salariée de l'April mais aussi par des membres bénévoles de l'association et des personnes invitées. Donner à chacun et chacune, de manière simple et accessible, les clefs pour comprendre les enjeux mais aussi proposer des moyens d'action, tel est l'objectif de cette émission hebdomadaire, qui est diffusée en direct chaque mardi du mois de 15 h 30 à 17 h.

Les archives de l'émission

Écouter les émissions précédentes

Une nouvelle édition de la Fête des Possibles, portée par le Collectif pour une Transition Citoyenne, aura lieu partout en France et en Belgique du 11 septembre au 11 octobre 2026. Objectif de la manifestation ? Faire connaître les initiatives locales et les solutions concrètes qui contribuent à construire un avenir plus durable et solidaire. Des centaines de rendez-vous - dont plusieurs autour du Logiciel Libre - ont déjà été proposés, et d'autres se rajouteront en cours de route. Il y en a sans doute aussi près de chez vous !

L'April est ravie d'être partenaire de l'édition 2026 de la Fête des Possibles !

Face aux urgences écologiques et sociales, les solutions ne sont pas des utopies, elles existent déjà et se construisent sur nos territoires. Pendant un mois, du 11 septembre au 11 octobre, des centaines d'alternatives citoyennes ouvrent leurs portes partout en France et en Belgique. Que ce soit pour découvrir le fonctionnement d'une AMAP, participer à un chantier participatif, ou simplement partager un repas convivial, la Fête des Possibles est le rendez-vous idéal pour passer à l'action. Et grâce aux dizaines d'événements proposés par les organisations locales de promotion du logiciel libre, de nouveaux publics pourront découvrir une informatique qui les respecte !

Proposer des rendez-vous autour du Logiciel Libre

Il est encore temps d'inscrire vos événements autour du Logiciel Libre sur le site de la Fête des Possibles, et ainsi profiter du coup de projecteur offert par cette initiative ! Tous les formats d’événement sont possibles (portes ouvertes, conférence, atelier, soirée projection/débat, etc.) : l’essentiel est de créer les conditions de rencontre avec les personnes, de leur montrer ce que vous faites, et de les inviter à agir à leur tour.

Important : pensez à inscrire vos événements également sur le site de l'Agenda du Libre, avec le mot-clé fete-des-possibles-2026. Cela permettra à l'April, partenaire de la Fête des Possibles, de mettre en valeur la contribution des organisations locales de promotion du Logiciel Libre à l'initiative.

Retrouvez tous les rendez-vous sur le site de la Fête des Possibles

La Une vidéo d'annonce de la Fête des Possibles 2026 est disponible.

Un espace de travail partagé le temps d'une soirée, réservé aux personnes actives dans le libre en Île-de-France

Les choses faites et le reste à faire !

La constante _ALLOWED_FORWARDED_HOST définit quels hôtes http peuvent légitimement figurer dans la variable serveur HTTP_X_FORWARDED_HOST lorsqu'elle est différente de HTTP_HOST.
Ref :
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Host
- https://search.spip.net/git.spip.net/spip/ecrire/-/blob/bootstrap/proxy.php

Cette constante définit le nombre de caractères minimum que les forums postés doivent avoir pour être acceptés.
Par défaut, elle vaut 10.
Voir aussi : _FORUM_LONGUEUR_MAXI.

Cette constante définit combien de caractère les forums déposés doivent avoir au maximum pour être acceptés.
Par défaut, elle vaut 8000.
Vous pouvez la redéfinir dans votre fichier d'options.
Voir aussi : _FORUM_LONGUEUR_MINI.

Infini signe la lettre ouverte de soutien à Autistici/Inventati, hébergeur désigné comme « terroriste » par l'administration Trump.
Nous publions donc ici la lettre traduite par les CHATONS :
En défense d'Autistici/Inventati et du droit de créer des moyens de communication résistants
Le 26 août 2026, les États-Unis ont classifié le collectif numérique italien Autistici/Inventati comme « Specially Designated Global Terrorist » (Terroristes internationaux) et l'ont ajouté à la liste (…)

Nous serons samedi 5 et dimanche 6 septembre, place du vieux marché aux chevaux devant le café citoyen avec nos amis du collectif Chtinux. Ce sera aussi l'occasion de nous rencontrer de discuter de logiciels libres, de la fin du support de Windows 10 (plus qu'un mois !), de la campagne Demailnagement... et de nos projets en cours ! Au plaisir de vous y trouver ou retrouver.

Bonjour à toustes,

PHP 7.3 a atteint sa fin de vie il y a déjà plusieurs années (décembre 2020). Les dernières mises à jour de sécurité ont été effectuées en décembre 2021.

Nous comprenons que le passage de PHP 7.3 à une version plus récente puisse demander du travail, c'est pourquoi nous avons choisi de vous laissez la possibilité de l'utiliser jusqu'à ce jour. Il est cependant nécessaire d'aller de l'avant et d'arrêter la maintenance de versions obsolètes, celles-ci ne recevant plus la moindre mise à jour de sécurité.

Nous avons donc décidé de fermer le support pour la version 7.3 le 1er février 2027. Au-delà de cette date, tous les sites utilisant encore PHP 7.3 seront automatiquement passés à PHP 8.4 (avec possibilité de redescendre jusqu'à 8.1 s'il y a un problème).

Dans la plupart des cas, la mise à jour peut être faite facilement (il suffit de nous demander de faire le changement!), mais il serait possible qu'il y ait des problèmes spécifiques à régler pour que votre site web soit compatible. Dans ce cas là nous pourrons revenir en arrière et discuter de pistes de solutions. Si vous ne savez pas quelle version de PHP votre/vos sites utilisent, n'hésitez pas à nous demander de vérifier!

Notez aussi que si vous avez encore des sites web en php8.1, nous vous encourageons fortement à les mettre à jour à php8.4. Php8.1 ne recoit plus de mises à jour de sécurité non plus. Nous ne sommes pas encore en train de planifier la fermeture de cette version, mais ça va venir, donc mieux vaut faire le changement le plus vite possible! La mise à jour va améliorer la sécurité et la performance de votre site web.

Nous prévoyons rendre php8.5 disponible à l'automne, mais nous vous encourageons à ne pas attendre avant de faire une mise à jour! Vous pourrez facilement passer de 8.4 à 8.5 à ce moment là.

Solidairement, L'équipe infrastructure Réseau Koumbit

France, September 3rd, 2026

Nexedi is working on an AI Software Factory for SlapOS. Nexedi is using AI agents to automate the creation and testing of new SlapOS Software. Nexedi hopes that AI agent technology will facilitate creating new Software Releases for SlapOS for its customers and help people to add their own projects. It should also help save time on the consuming task of developing and maintaining Software Releases. It has also been used to help fix and add features to existing software releases.

Thanks to the existing documentation on SlapOS and AI agent development we released a first version of SlapOS Agent Skill Marketplace  . With Claude Code it can be installed as such:

They are now referenced in the generic available AGENTS.md and you can also ask your agent to install them.

These skills are a work in progress but already allow to easily add and develop a new software release thanks to the tool they provide and the large set of already existing cases.

So far we recommend using sub agents to do the work and adjustments as there might be errors in the build and dealing with those errors may consume a lot of context not relevant to the core agent driving the build.

For this blog post I repeated the practice and required the development of a stateless OCR service using Claude Code with a pro subscription with the Opus Model. The agent picked Tika. 

The agent easily come to a first working step without much input from the developer. It can be noted that the agent had to wait 3 hours for the compilation of the software to complete, thanks to the agent the developer doesn't need to monitor compilation. Here we did not continue the work on Tika as it was only an experience. 

And we can now do these experiences at a much lower cost. Compared to the work it required before, this is much simpler and a good example for AI Agent use as it can use the documentation of the proper software and examples of software using the same approach in the repository of SlapOS.

This was an example on adding a simple software release. AI Agents are being used already in SlapOS by Nexedi Team to test new software release easily and is now facing like other teams a pressure on reviewing more merge request:

• oMailGw log analytics tool is being added using ChatGPT5.4 via Github copilot for about $0.4 of Github credit: 9950642e
• litellm software release
• OpenWebUI
• OpenClaw

The current Marketplace provides a decent harness to start working but unlike other software released by Nexedi there are no automatic tests as of now to check that the skills systematically provide the proper result for each model available. Nexedi team is also experimenting with more advanced work to automate the production of Software Releases via orchestration:

Thanks to these tools it is becoming easier to work with SlapOS. Feel free to give it a try:

• SlapOS Documentation
• SlapOS Repository
• SlapOS Agent Skill Marketplace

Arch Linux est une distribution très connue pour être une bonne base permettant de créer son propre système Linux personnalisé de fond en comble. La possibilité d’y ajouter des logiciels libres peu connus du grand public via l' AUR est l’une des grandes forces d’Arch Linux.

J’ai donc une vision personnelle assez précise du bureau Linux idéal, et je souhaite la partager ici en vous présentant un projet sur lequel je travaille depuis un peu moins d’un an, presque non-stop. Ma propre distribution Linux : SlyOS, un système d'exploitation libre distribué sous licence GPLv3.

• lien nᵒ 1 : Le site Web officiel de SlyOS
• lien nᵒ 2 : La configuration archiso de SlyOS

Par exemple, voici quelques logiciels disponibles dans l'AUR : DeaDBeeF, Cine, Warehouse, Carburetor, …

Arch Linux est aussi une distribution valorisée par son choix presque illimité d'environnements de bureau. En effet, on peut prendre l'exemple de mon expérience personnelle sur ce point.

J’ai tout d'abord commencé par découvrir GNOME. Son interface m’a immédiatement convaincu et il reste aujourd’hui l’un de mes environnements de bureau préférés. La principale réserve que j’ai à son sujet concerne sa dépendance trop marquée à plusieurs composants de systemd (j’expliquerai plus tard dans la dépêche ce qui me tracasse vraiment à ce sujet).

J’ai ensuite essayé plusieurs environnements de bureau moins répandus, notamment Pantheon. Je reste particulièrement attaché à son interface, mais j’ai fini par l’abandonner en raison de bugs que j’ai rencontrés avec le compositeur Gala, ainsi que des difficultés liées à la transition de X11 vers Wayland. Cette transition a notamment retiré Plank, que j’appréciais beaucoup, sans vraiment lui apporter de remplaçant…

Ou encore moins connu : herbstluftwm que j'aimais beaucoup mais que j'ai fini par abandonner aussi à cause du manque d'outils de personnalisation sur X11 pour un gestionnaire de fenêtre si minimal.

J'ai aussi testé plein d'autres gestionnaires de fenêtre et de d'environnements de bureau tels que Cinnamon, Xfce, Hyprland, Fluxbox, LXQt, MATE, Sway, IceWM…

Avec le temps, j'ai façonné quelques opinions sur les différentes options que nous propose la communauté. Par exemple, cela peut en affecter certains, mais j’essaie d’éviter Qt au maximum et de privilégier GTK. Ma position concerne principalement le modèle économique de Qt : je ne reproche pas à un projet libre de chercher à se financer, mais Qt repose notamment sur les revenus provenant de logiciels propriétaires et de licences commerciales (proposant des offres payantes sur son site web). Je préfère donc soutenir des projets qui privilégient d’autres modèles, comme les dons, à l’image de ce qui existe autour de GTK. Ma position peut paraître controversée, notamment parce que l’écosystème Linux dépend lui aussi largement de grandes entreprises (comme Google, ou même Microsoft qui détient GitHub). Je ne prétends donc pas pouvoir éviter toute dépendance de ce type, mais j’essaie, autant que possible, de privilégier des logiciels et des projets capables de subsister sans être directement financés par le logiciel propriétaire.

De même, je n’aime pas vraiment systemd car c'est de plus en plus un programme qui obtient le monopole, avec une étendue de fonctionnalités et une complexité qui s'éloignent du principe KISS. Surtout que récemment, systemd a été au cœur de débats controversés, notamment à travers une proposition de vérification de l’âge intégrée directement à celui-ci. Le problème n’est pas uniquement l’existence de ce champ optionnel (birthDate), mais le fait que systemd puisse devenir un point central pour intégrer ce type de mécanisme à l’avenir. C'est pourquoi je préfère limiter les composants centraux aux fonctions dont le système a réellement besoin.

Cette problématique de vérification d'âge ne se limite d'ailleurs pas à systemd : le plus gros problème actuel est aussi xdg-desktop-portal. Mais il est à l'heure actuelle compliqué de changer cela, puisque xdg-desktop-portal est une dépendance presque cruciale dans Arch Linux. Un paquet alternatif contenant un patch pourrait être envisageable dans le dépôt de SlyOS via notamment l'alternative de xdg-desktop-portal Ageless Linux, mais je n'ai pas vraiment le temps d'accomplir cela pour l'instant.

J'ai dû parfois remettre en question certaines de mes opinions comme ma préférence à X11. Cela a par exemple opéré quand j'ai découvert niri et la stabilité et fluidité de Wayland nettement supérieure à X11.

SlyOS est basé sur Arch Linux et construit à l’aide d’archiso. Le projet a commencé comme une expérience personnelle pour en apprendre davantage sur Linux. Je me suis rendu compte par la suite qu’il y avait un réel intérêt à proposer ma vision du bureau Linux parfait, car je ne l’avais étrangement vue nulle part ailleurs (par défaut dans un système d'exploitation).

Je sais que les concepts revendiqués par une distribution peuvent paraître flous ou consensuels (moderne, léger, simple à utiliser, intuitive, personnalisable, performant, stable, respectant le principe KISS), mais dans SlyOS, chacun de ces principes correspond à des choix concrets et justifiés qui permettent à SlyOS d'être une distribution :

• Moderne : SlyOS propose niri, un gestionnaire de fenêtres entièrement basé sur Wayland, relativement récent, qui a déjà fait ses preuves (notamment par sa popularité en croissance exponentielle) et qui bénéficie d’un développement actif.

• Légère : la version minimale de SlyOS contient moins de 700 paquets, tandis que la version complète en contient moins de 850. Les ISO sont nettement plus légères que celles de nombreuses distributions x86_64, réduisant les composants susceptibles de poser problème, sans pour autant supprimer les fonctionnalités essentielles.

• Simple d’utilisation et intuitive : SlyOS propose un programme d’accueil dès le live ou après l'installation, présentant les raccourcis principaux. Le système peut être utilisé sans ligne de commande grâce à Pamac. Le bureau minimal et l'accès aux paramètres permettent à un débutant de prendre le système en main rapidement.

• Performante et stable : SlyOS utilise le noyau linux-cachyos-lts pour un bon compromis performances/stabilité. La consommation de RAM au démarrage est très basse grâce à un nombre limité de services en arrière-plan grâce à l'esprit minimaliste de SlyOS.

• Personnalisable : SlyOS s’appuie sur des outils Wayland comme Ironbar, Wofi, Hyprlock ou Vibepanel. Ils offrent un environnement complet tout en laissant une grande liberté de modification (ils peuvent être désinstallés et remplacés). Le choix de niri facilite également cette personnalisation profonde puisque largement reconnu dans le domaine du "Rice".

• Respectueuse de la vie privée : remplacer systemd par OpenRC est une première marche vers une meilleure protection de la vie privée dans un système Linux. De plus, SlyOS contient LibreWolf, un navigateur axé sur la vie privée bloquant le pistage, ainsi que les extensions uBlock Origin (bloqueur de pubs et traqueurs efficace) et Decentraleyes (empêche le suivi par les CDN en servant les ressources localement). Il intègre aussi le DNS Mullvad Base qui chiffre vos requêtes DNS pour empêcher les écoutes et les fuites de données vers votre FAI.

• Suivre le principe KISS en évitant systemd (plus d'informations ici) : SlyOS utilise OpenRC, un système d'initialisation qui suit une approche plus modulaire et plus proche du principe KISS que systemd, régulièrement critiqué pour son poids et sa complexité. Ce choix permet d'éviter de renforcer la position dominante de systemd tout en limitant les risques de dérive (comme l'intégration d'un champ birthDate).

À ses débuts, la distribution ne respectait pas entièrement tous ces critères. Elle utilisait GNOME / MATE, avec systemd ainsi que le noyau linux-cachyos-lts.

La distribution ressemblait à ceci à ses débuts, dans sa version 0.1 « Dxtrus » (pour "dexterous" en anglais) :

Depuis, le projet a considérablement évolué et est progressivement devenu un système plus complet et abouti, illustrant concrètement la direction prise par SlyOS. La version 0.2 « Invativ » (pour "innovative" en anglais) utilise désormais :

• niri comme gestionnaire de fenêtres
• OpenRC comme système d’initialisation
• ReGreet, une interface de connexion en GTK4 écrite en Rust pour greetd
• Le noyau linux-cachyos-lts
• Plymouth pour afficher un écran graphique lors du démarrage et de l’arrêt du système

Voici à quoi ressemble la distribution depuis :

La distribution inclut également un centre de contrôle appelé Thymbr, qui permet de configurer de nombreux aspects du système depuis une interface centralisée. Cela rend SlyOS bien plus intuitif et simple d’utilisation, bien que le caractère intuitif se juge surtout à l'utilisation.

Le site web du projet est disponible ici

Je vous conseille d’y jeter un coup d’œil. Le site propose une version française et fournit des explications plus approfondies sur le projet, notamment à travers les principes présentés sur la page d’accueil ainsi que la FAQ, accessible dans la catégorie « Aide ». Le meilleur moyen de se faire une opinion reste de tester SlyOS, par exemple dans une machine virtuelle.

La configuration archiso est disponible sur Codeberg : https://codeberg.org/Minaucro/SlyOS

Je travaille à rendre SlyOS pratique, optimisé, simple et performant, selon ma propre vision d’un système d’exploitation Linux destiné aux ordinateurs de bureau. Le projet est encore en développement, mais il est déjà suffisamment mature pour être testé et utilisé au quotidien.

Merci d’avoir pris le temps de me lire.

SlyOS a été créé par Minaucro (slyos@minaucro.fr).

Commentaires : voir le flux Atom ouvrir dans le navigateur

September brings a balance of trytond internals and business-module refinements. The server now retries queued tasks that were dropped because a worker died, enforces request timeouts for the whole request, and exposes routes so RPC endpoints can be registered declaratively. On the user side, European VAT numbers are now validated in the background, stock periods close themselves, and the IBAN editor formats the number as it is typed-in. All of this builds on our last LTS release 8.0.

For an in depth overview of all the Tryton issues please take a look at our issue tracker or see the issues and merge requests filtered by label.

Changes for the User

Accounting, Invoicing and Payments

The automatic VIES check replaces the previous wizard for European VAT numbers. A background task validates new and modified EU VAT identifiers and refreshes them once the configured validity period has expired. The validity of the identifier is also checked when posting an invoice, so a stale or invalid VAT number is caught before the invoice is sent. The last validation-state and validation-date is displayed in the identifier view.

The party required setting can no longer be changed on an account that already has account moves. This avoids mixing moves with and without a party on the same account, which used to confuse later reports.

The redundant prefix is dropped from the statement and payment journals actions. So the menus for accounting, statements and payments no longer repeat the “statement” or “payment” word.

The IBAN of a bank account on a party is now formatted with spaces between groups of four characters on changing the field. This makes it easier to check the number was entered correctly.

The version of the Stripe API used by the payment gateway is updated to the latest one.

Stock, Production and Shipments

Stock periods can now be created and closed automatically by two scheduled tasks, automating the manual steps at the start and end of each period.

On a stock move that is linked to a shipment but opened outside the shipment form, the from and to locations are now read-only. This prevents the location domain inherited from the shipment from being bypassed. The domain is also enforced on stock moves, so each move matches at least one of the shipment’s two move fields: incoming moves or inventory moves.

User Interface

In the SAO client, tabs now scroll horizontally when they overflow the tab list. The scrolling is smooth for a nicer effect when adding a new tab.

New Releases

We released bug fixes for the currently maintained long term support series 8.0, 7.8, and 7.0.

Changes for Implementers and Developers

A mixin can now be added to the Database and TableHandler from the configuration. This is used by the gis module to register PostGIS as a backend mixin.

The Pool now exposes routes, so RPC endpoints can be registered declaratively using a Router.

The trytond request timeout is now enforced for the whole request, not just for individual queries. A threading timer injects an exception into the running thread when the timeout expires.

Queued tasks that were dequeued but never finished, because the worker was killed, are now retried by a scheduled task. The retry uses the finished_at timestamp and the task lock to know which tasks are still outstanding.

Initial draft powered by Minimax-M3. Curated and finalised by human hands.

1 post - 1 participant

Read full topic