Une nouvelle faille repérée sur le système d’exploitation fait craindre le pire.

Chicago95 ça va vous plaire surtout si vous êtes du genre nostalgique sous Linux ! Car c'est un thème complet pour le bureau XFCE qui transforme un Xubuntu en Windows 95 avec le thème des fenêtres, les icônes, les curseurs, les sons, le menu Démarrer avec son bandeau vertical, et même une invite MS-DOS dans le terminal. C'est TROP BEAU !!! Et en plus ça s'installe facilement au clickodrome.

Le menu Démarrer façon Windows 95 de Chicago95, avec son bandeau vertical et ses dossiers jaunes

J'ai donc installé une VM Xubuntu 26.04 à jour (un Ubuntu Server ARM64 auquel j'ai ajouté le paquet xubuntu-desktop) pour tenter de le convertir au look Microsoft qu'on aime tant.

Quelle Xubuntu ?

Niveau prérequis, c'est écrit dans la doc qu'il faut GTK 3.22 ou 3.24 et XFCE 4.12, 4.14 ou 4.16. Sauf que Xubuntu 24.04 tourne en XFCE 4.18, et Xubuntu 26.04 en XFCE 4.20. Donc la question se pose : Est-ce que ça va fonctionner sur ma Xubuntu 26.04 ???

Et bien d'après les retours des utilisateurs sur github ça devrait fonctionner pour l'essentiel maintenant il y aura quand même quelques petites retouches d'icônes et de css à faire donc voilà si vous voulez vraiment pas être embêté il faudra peut-être passer sur une version un peu plus ancienne de XFCE compatible avec cette installe ou alors attendre une mise à jour de Chicago95.

Préparer le terrain

Côté paquets, il vous faudra xfce4-panel-profiles, gtk2-engines-pixbuf pour les applications GTK2, et un compositeur de fenêtres. Récupérez ensuite le dépôt depuis GitHub.

Sur une Xubuntu 26.04 fraîchement installée, xfce4-panel-profiles et gtk2-engines-pixbuf sont déjà là, et le compositeur de XFCE est activé d'office. Pour le dépôt, pas besoin de git, l'archive ZIP de la branche master suffit, et elle se décompresse justement dans un dossier Chicago95-master :

wget https://github.com/grassmunk/Chicago95/archive/refs/heads/master.zip -O Chicago95-master.zip
unzip Chicago95-master.zip
cd Chicago95-master

Avant de lancer quoi que ce soit, sauvegardez bien sûr votre tableau de bord, car l'installeur charge le sien par-dessus sans garder l'ancien. Voici la commande pour faire ce backup :

xfce4-panel-profiles save ~/panneau-avant-chicago95.tar.bz2

Notez aussi à la main vos réglages actuels (thème, icônes, curseurs, thème et police des fenêtres, ombres, notifications, sons, icônes du bureau et fond d'écran) puisque l'installeur les remplace sans en garder la trace. Et si vous avez un dossier ~/.config/xfce4/labwc, copiez-le de côté, car il en réécrit rc.xml et environment sans sauvegarde.

Voilà, si vous vous engagez dans cette voie avec Chicago 95, sachez qu'il n'y a pas de désinstallateur pour revenir en arrière. Donc c'est à vous de prendre vos précautions avant, sinon si ça ne vous plaît pas, tant pis pour vous.

Lancer l'installeur

C'est un assistant graphique codé en Python 3 avec GTK 3, donc depuis le dossier Chicago95-master, la commande qui en découle c'est :

python3 installer.py

Elle fonctionne telle quelle sur la 26.04, où le module GTK de Python est installé d'office. L'installeur s'ouvre en plein écran, sur un fond bleu tramé façon programme d'installation de 1995. Vous allez voir, c'est bluffant, on se retrouve comme à l'époque !

L'installeur de Chicago95 au lancement, sur notre Xubuntu 26.04

L'installeur de Chicago95 à l'étape des composants, avec thème GTK, icônes, curseurs, fond, sons et polices cochés

Le premier écran liste les composants, tous cochés par défaut : thème GTK, icônes, curseurs, fond, sons et polices. Et le second propose les personnalisations, à savoir l'animation de Thunar, les couleurs du terminal et l'invite bash, cochées elles aussi, l'invite zsh qui ne l'est pas, et le tableau de bord. Cette dernière case reste grisée si xfce4-panel-profiles n'est pas installé.

Les six composants, tous cochés par défaut, avec leur poids

Les personnalisations, l'invite zsh étant la seule décochée

Voici ce qu'il va installer, tout ça dans votre dossier personnel. Le thème part dans ~/.themes, les icônes et les curseurs dans ~/.icons, les sons dans ~/.local/share/sounds et le contenu du dossier Fonts dans ~/.fonts. Il active ensuite le tout par xfconf et tente de remplacer votre fond d'écran par un aplat bleu canard #008080 que j'aime tellement !!

Sauf qu'il écrit ce réglage pour un écran baptisé monitorVirtual1 en dur, alors que XFCE 4.20 nomme l'écran d'après sa sortie vidéo. Donc chez moi, le fond n'a pas bougé, et l'installeur n'a rien affiché.

Côté terminal, il copie le jeu de couleurs Chicago95.theme dans ~/.local/share/xfce4/terminal/colorschemes, remplace terminalrc après l'avoir copié en backup.terminalrc.chicago95 s'il existait, et ajoute l'invite MS-DOS à la fin de votre ~/.bashrc. La copie de ce dernier, backup.bashrc.chicago95, atterrit alors dans ~/.config/xfce4/terminal/ et pas dans votre dossier racine.

Enfin, il glisse un bloc @import dans ~/.config/gtk-4.0/gtk.css (sauvegardé en backup.gtk.css.chicago95), modifie la config de labwc évoquée plus haut, et charge son profil de tableau de bord.

Juste avant, à la fin de la copie, le tableau de bord de XFCE affiche une fenêtre d'erreur, car le profil de tableau de bord de Chicago95 réclame le greffon "statusnotifier", c'est-à-dire un paquet qu'Ubuntu a retiré dès la 23.04 et dont la zone de notification standard, déjà présente dans le profil, a repris le rôle.

Cliquez donc sur Supprimer. L'installeur ouvre aussi tout seul un fichier post_install.txt dans Mousepad, avec les étapes qu'il n'a pas pu réaliser.

Fin de l'installation sous XFCE 4.20 : le greffon statusnotifier manque, et post_install.txt s'ouvre tout seul

Fermez ensuite votre session et rouvrez-la.

Pour le fond d'écran, faites-le à la main, avec un clic droit sur le bureau puis Paramètres du bureau. Dans l'onglet Arrière-plan, mettez le Style sur Aucun, puis cliquez sur la pastille de la première couleur, sur le + des couleurs personnalisées, et saisissez #008080 dans le champ de saisie.

Et là, petit piège : la liste Couleur affiche déjà "Couleur unie", mais chez moi le bureau restait noir tant que je n'y avais pas touché. Je l'ai passée sur "Dégradé horizontal" puis remise sur "Couleur unie", et ce bleu canard que certains qualifieraient de "vert canard" (les fous !) est apparu comme par magie.

Le fond bleu canard réglé à la main, style Aucun et couleur unie #008080

Le terminal habillé en invite MS-DOS, à côté d'une calculatrice aux boutons gris façon 1995

Voici ma Xubuntu 26.04 au terme de tout ça, avec le bon fond et Helvetica en place, menu Start ouvert pour que vous voyiez comme Linux peut être enfin BEAU !! lol

Notre Xubuntu 26.04 en Windows 95, menu Start ouvert

Finir à la main

Non, pas comme dans votre salon de massage parisien. En fait, si un réglage n'a pas pris, faut aller dans le gestionnaire de paramètres, Apparence, choisir Chicago95 comme style, puis Chicago95 ou Chicago95-tux comme icônes.

Dans le Gestionnaire de fenêtres, choisissez Chicago95 et une police de titre Sans Bold en 8 points. Dans Notifications, Chicago95 avec une opacité de 100 %. Et dans Souris et pavé tactile, prenez par exemple Chicago95 Standard Cursors, ou la version au sablier animé.

Sur mon essai, l'installeur avait déjà tout réglé dans ces fenêtres, sauf la police par défaut, restée en Noto Sans :

Chicago95 sélectionné dans la fenêtre Apparence de XFCE

Hé oui, pour la police, attention, la vraie MS Sans Serif n'est pas fournie. Mais la doc explique comment récupérer sserife.fon et micross.ttf sur un Windows et convertir le premier avec FontForge. À défaut, elle propose une Helvetica bitmap incluse, mais certains systèmes bloquent les polices bitmap, et la doc fait alors toucher à la config système avec :

sudo mv /etc/fonts/conf.d/70-no-bitmaps.conf /etc/fonts/conf.d/70-no-bitmaps.conf.bak

Sauf que sur Xubuntu 26.04, et sur la 24.04 aussi d'après la liste des fichiers du paquet fontconfig-config, ce fichier s'appelle 70-no-bitmaps-except-emoji.conf. Pour cela, le fichier INSTALL.md donne donc une variante qui fonctionne :

sudo mv /etc/fonts/conf.d/70-no-bitmaps-except-emoji.conf /etc/fonts/conf.d/70-no-bitmaps-except-emoji.conf.bak

La première commande de la doc échoue sur Xubuntu 26.04 : le fichier porte un autre nom

Chez moi, la commande fc-list a ainsi trouvé la Helvetica de Chicago95, alors qu'elle n'en trouvait aucune avant. Choisissez-la ensuite dans l'onglet Polices de la fenêtre Apparence, en taille 8, avec un lissage "Important".

Avec le bon nom de fichier, la Helvetica bitmap apparaît dans fc-list

Avant de choisir cette police, notez celle qui est en place (chez moi, Noto Sans), sa taille et son lissage : la liste des réglages à noter plus haut ne les cite pas, et sans eux vous ne saurez pas quoi remettre en revenant en arrière.

Pour les sons, la doc demande d'installer SoX et canberra avec cette ligne :

sudo apt-get install gnome-session-canberra sox libcanberra-gtk3-module libcanberra-gtk-module

Sauf que le dernier paquet, libcanberra-gtk-module, existe encore dans les dépôts de la 24.04 mais plus dans ceux de la 26.04. Sur cette dernière, apt refuse alors toute la ligne et n'installe rien du tout, donc retirez-le, et les trois autres passent sans broncher :

sudo apt-get install gnome-session-canberra sox libcanberra-gtk3-module

La ligne des sons de la doc, refusée en bloc par apt sur la 26.04

Vous trouverez tous ces tweaks dans le fichier post_install.txt du projet Chicago95.

Revenir en arrière

Comme il n'y a pas de désinstalleur, tout se défait à la main. Rechargez d'abord votre tableau de bord :

xfce4-panel-profiles load ~/panneau-avant-chicago95.tar.bz2

Le tableau de bord d'origine rechargé, la barre Xubuntu revient en haut

Remettez ensuite un par un les réglages que vous avez notés : thème, icônes, curseurs, thème, police et ombres des fenêtres, notifications, sons, icônes du bureau et fond d'écran. Recopiez aussi votre dossier labwc si vous l'aviez mis de côté. Puis retirez le bloc GTK4 avec la commande de la doc, car sinon chaque application GTK4 lancée affichera une erreur d'import une fois le thème supprimé :

sed -i '/>>> Chicago95 GTK4 BEGIN/,/<<< Chicago95 GTK4 END/d' ~/.config/gtk-4.0/gtk.css

Remettez aussi la police par défaut, sa taille et le lissage dans la fenêtre Apparence avant de supprimer les polices de Chicago95 de ~/.fonts, puisque ce tuto les change plus haut.

Restaurez enfin votre .bashrc et votre terminalrc depuis leurs copies backup.*.chicago95 de ~/.config/xfce4/terminal/, à condition de n'avoir lancé l'installeur qu'une fois, puisqu'un second passage écrase ces copies avec des fichiers déjà modifiés.

Puis supprimez le dossier Chicago95 de ~/.themes et de ~/.local/share/sounds, ainsi que les dossiers d'icônes et de curseurs Chicago95 de ~/.icons, les polices copiées dans ~/.fonts et Chicago95.theme dans le dossier colorschemes du terminal. Si vous avez renommé 70-no-bitmaps-except-emoji.conf, redonnez-lui également son petit nom.

Sur une Xubuntu neuve, vous ne trouverez d'ailleurs pas de backup.terminalrc.chicago95, puisqu'il n'y avait pas de terminalrc à sauvegarder, et il suffit de supprimer celui de Chicago95. Sur ma VM, ce ménage m'a remis un bureau identique à celui de départ, et le .bashrc restauré était celui d'origine, au caractère près.

Youpi !

Le bureau Xubuntu de départ, une fois tout défait à la main

Avouez que c'est quand même moins joli que Windows 95 comme style, non ?

Bref, amusez-vous bien avec votre bureau de 1995, mais gardez vos sauvegardes sous la main...

Source : GitHub

Trois actualités à retenir cette semaine dans le cyberespace, un modèle d’OpenAI qui corrige un autre modèle en retouchant directement ses paramètres, un projet open source majeur dépassé par le nombre de bugs que l’IA lui signale, et OpenAI qui affirme avoir industrialisé la recherche de failles dans le noyau Linux.

Si vous jouez sous Linux avec une carte ou une puce Intel Arc, alors forcément XeSS tourne chez vous dans Proton. Pour rappel, XeSS c'est la techno d'Intel qui fait tourner le jeu dans une définition plus basse. Ça reconstruit l'image à la définition de votre écran grâce à l'IA, et avec sa frame generation, ça invente carrément des images intermédiaires pour gonfler le nombre d'images par seconde. Mais sous Linux, ça le fait en empruntant la voie de secours DP4a, et pas sur les unités XMX du GPU, qui sont des cœurs matriciels prévus justement pour ça. Et ça c'est sacrément dommage car XeSS a été taillée POUR ces XMX, sauf que sous Proton, elle ne trouve pas de pilote Intel pour répondre à ses questions et se rabat donc sur sa version générique. Snif.

Cette version générique tourne ainsi sur n'importe quelle carte graphique récente mais via l'instruction DP4a des unités de calcul classiques. Résultat, les XMX se tournent les pouces et surtout, la frame generation reste bloquée en x2, soit une seule image générée par image calculée, alors que sous Windows, une Arc peut monter jusqu'au x4 ! C'est couillon non ?

Heureusement, le projet communautaire xess-xmx-linux change la donne puisqu'il permet de faire tourner la vraie XeSS d'Intel, super résolution et frame generation incluses sur les XMX dans les jeux Proton.

Pour y arriver, ce projet ne touche ni à Proton ni à vkd3d-proton mais glisse dans vos préfixes une DLL qui se fait passer pour le pilote Intel, igdext64.dll (le "shim"). Ensuite, un pilote Mesa ANV patché compile à la volée les kernels de XeSS avec le compilateur d'Intel. C'est hyper expérimental vous vous en doutez mais ça évolue très vite.

La fiche du dépôt sur GitHub, qui annonce XeSS sur XMX pour les Arc Xe-HPG, Xe2 et Xe3 (image : GitHub)

Avant de vous lancer, mesurez quand même vos attentes qui je le sais, sont grandes ^^. Sur le GPU Arc B390 de l'auteur, Cyberpunk 2077 gagne 28 % au benchmark intégré, avec 61,3 images par seconde, face à Mesa 26.1.2 en DP4a. Comment expliquer ce "saut" sachant que les XMX ne font qu'environ 5 % de mieux que DP4a. En fait, cela provient de Jay, le nouveau compilateur de Mesa 26.3, celui-là même que Mesa utilise par défaut sur Xe2 et Xe3.

Ce que le projet dont je vous parle aujourd'hui apporte vraiment, c'est surtout de la génération de frame de XeSS en x3 et x4 sur XMX (sans l'extension d'Intel, elle plafonne à x2), et Cyberpunk 2077 monte ainsi à 117 images par seconde en x3 dans le même test.

Et quand la frame generation est active, il ajoute un mode faible latence qui empêche les images de faire la queue devant le GPU comme vous à la caisse d'Auchan. Sur Wuthering Waves, à fréquence d'images égale, la latence passe également de 69 à 35 ms quand le jeu est limité par le GPU, comparé à la même frame generation sans ce mode.

Bref, encore une fois, c'est à prendre avec des pincettes car tout ça a été mesuré sur une seule machine, avec un seul passage par jeu, et la qualité d'image n'a pas encore été évaluée...

Avant de commencer

Il vous faut un GPU Intel avec des unités XMX, sur le pilote noyau xe ou i915. Ça couvre les Xe3 (Panther Lake, l'auteur développe également sur l'Arc B390 d'une ONEXPLAYER 3 sous SteamOS), les Xe2 et les Xe-HPG. Lunar Lake et Arrow Lake-H sont également détectés mais pas encore testés (si y'a des volontaires, hein...). Et Meteor Lake est totalement hors jeu puisque son GPU Xe-LPG n'a pas d'unités XMX.

Voilà... Et côté système, les pilotes livrés sont compilés sous Arch et exigent la glibc 2.38 et libwayland-client 1.24 au minimum. L'auteur a vérifié cependant qu'ils se chargaient bien sur SteamOS, Arch, openSUSE Tumbleweed, Void Linux, Fedora 43 et Ubuntu 25.10, mais hors SteamOS, c'est uniquement le chargement qui a été testé en conteneur, et pas dans des vrais jeux sur du vrai matos. Quant à Debian 13 et Ubuntu 24.04, ils n'ont pas cette version de libwayland-client et obligent donc à recompiler le pilote sur la machine (je ne couvre pas cette étape ici).

Il vous faudra aussi le client Steam natif, car la version Flatpak n'est pas supportée, ainsi qu'un Proton récent et des jeux en DirectX 12. Le script d'installation a aussi besoin de curl, ar (paquet binutils), tar, zstd et python3, plus unzip ou python3 pour récupérer le SDK XeSS.

Voilà, je pense que j'ai fait le tour des pré-requis.

Par contre, gaffe aux jeux en ligne car dans un jeu avec un anti-triche, cette DLL pourrait se faire spotter et vous pourriez être considéré comme un de ces affreux tricheurs et vous faire bannir...

On installe !

Téléchargez l'archive de la dernière release depuis la page Releases du dépôt, et décompressez-la dans un dossier où elle restera, car pour la déplacer ensuite, il faudra d'abord lancer uninstall.sh. Depuis ce dossier, une seule commande à lancer :

./install.sh

Le script téléchargera alors le compilateur d'Intel (environ 95 Mo), les bibliothèques du SDK XeSS (77 Mo) et les fichiers FidelityFX d'AMD (87 Mo), puis il faudra redémarrer ou fermer et rouvrir la session.

Ensuite, chaque jeu lancé depuis Steam passera par le pilote patché, sans option de lancement. C'est aussi simple que ça ! Notez bien que ça touche toute votre session puisque le pilote patché devient LE pilote Vulkan Intel 64 bits qui s'applique à tous les jeux.

Sachez aussi que si votre Steam a été installé via le APT de Debian ou d'Ubuntu, il se trouve dans ~/.steam/debian-installation, et il ne sera pas trouvé par le programme d'install. Ça devrait être corrigé dans une future release mais en attendant, l'auteur conseille de lancer la commande install comme ceci :

STEAM_DIR="$HOME/.steam/debian-installation" ./install.sh

Enfin, pour n'activer le projet que sur certains jeux, il est possible d'installer ça jeu par jeu. En gros, vous lancez enable.sh avec l'identifiant Steam du jeu, puis vous mettez le chemin de xmx-launch.sh devant %command% dans ses options de lancement et voilà...

XMX_APPID=<steam app id> ./enable.sh
/path/to/package/xmx-launch.sh %command%

En jeu

Maintenant, dans le jeu, choisissez bien XeSS, et sa frame generation si elle est proposée, sur le rendu DirectX 12. Comme le premier lancement compile les kernels XeSS du jeu, ça prendra une à deux minutes mais une seule fois, donc pas de panique si ça semble figé !! Ensuite ça ira plus vite.

Et le reste se configure par les options de lancement de Steam (Propriétés, Général), devant %command%. Sachez également qu'un jeu dont la version de XeSS est plus ancienne que la 2.0.2.68 ne verra pas le GPU Intel, et rebasculera en DP4a. Il ne pourra donc pas proposer de frame generation XeSS. C'est le cas de Cyberpunk 2077, et le paramètre XESS=latest lui permettra quand même d'utiliser les bibliothèques du SDK d'Intel juste le temps de la partie, puis remettra les originales en place dès que vous quitterez le jeu. Ça permet à Steam de retrouver le jeu tel qu'il a été installé.

XESS=latest %command%
XESS_FG=4 %command%

XESS_FG, lui, force le multiplicateur de la frame generation, x3 ou x4, même quand le menu du jeu ne propose que du x2 comme dans Cyberpunk. Pour cela, la frame generation doit rester activée dans le jeu. Vous pouvez aussi, si vous êtes très très chaud, tenter le x5 à x8 mais là on est dans l'hyper expérimental car au-delà de ce qu'Intel supporte. Gardez donc un limiteur d'images, celui du jeu ou de gamescope , sinon les images générées arriveront à l'écran de façon très très irrégulière. Et ça on ne veut pas car vomir c'est pas cool !

Ah et oubliez le plein écran exclusif, car XeSS-FG le refusera. Le jeu ne pourra donc tourner qu'en version fenêtrée sans bordure.

Comment vérifier que ça passe bien par les XMX ?

Les images par seconde ne prouvent rien ici, puisqu'une bonne partie du gain vient de Mesa 26.3 et pas des XMX donc le signe le plus simple, c'est d'aller dans un des menus qui propose la frame generation et de voir si y'a du x3 ou x4 proposé car XeSS dans sa version générique plafonne uniquement à x2. L'inverse, en revanche, ne prouve rien, puisque certains jeux comme Cyberpunk ne proposent, comme je vous le disais, uniquement du x2 même sur XMX.

Et pour en avoir VRAIMENT le cœur net, ajoutez XESS_LOG=1 devant %command%. Le préfixe du jeu, dans ~/.local/share/Steam/steamapps/compatdata//pfx/drive_c/ (ou dans le dossier steamapps de la bibliothèque, pour un jeu sur un autre disque) reçoit alors un fichier igdext_trace.log qui liste le GPU détecté, chaque appel à l'extension et chaque kernel. Si y'a pas de fichier du tout créé, ça veut dire que le shim n'a pas été chargé et que c'est XESS=dp4a qui a fait tourner le même jeu sans les XMX.

Et si ça casse

Franchement, y'a des chances hein ! Mais si c'est le cas, suffit de relancer install.sh. Si un jeu se comporte mal uniquement avec Mesa 26.3 (qui est encore une release candidate), mettre MESA=26.1 avant %command% le renverra sur le pilote Mesa 26.1.2 du même paquet. Et si les XMX ont disparu après une mise à jour de SteamOS, sachez que l'utilitaire ~/.cache/xess-xmx/driver-status vous dira si les pilotes patchés se chargent encore, et le script tools/rebuild-driver.sh en reconstruira un tout frais tout beau pour votre nouvelle version de Mesa.

Et puis si vous voulez simplement revenir en arrière, et abandonner la luuuuttte finale , y'a toujours ./uninstall.sh qui lancé depuis le dossier du paquet annulera tout ce que l'installation a fait ! Ouf !

Source : PC Gamer

OpenAI vient de lancer GPT-6 Cyber, une nouvelle intelligence artificielle spécialisée dans la cybersécurité. Le modèle d'IA a déjà débusqué des centaines de failles dans Linux et Firefox. Jugée trop dangereuse pour le grand public, l’IA est réservée à des experts triés sur le volet.

OpenAI vient de lancer GPT-6 Cyber, une nouvelle IA spécialisée en cybersécurité. Elle a déjà généré des centaines de correctifs pour Linux.

 [Lire la suite]

---

 [Lire la suite]

---

Le 27 octobre, la Frontier Red Team d’Anthropic a publié cinq chaînes d’attaque produites par un modèle d’IA interne, visant Chrome, Safari, Android (Pixel 9), Windows et Linux. Les éditeurs ont corrigé les failles, dont 62 pour Google, et Anthropic ouvre aux entreprises certains de ses modèles d’analyse de code.

 [Lire la suite]

---

 [Lire la suite]

---

C’est officiel, Fortnite arrive sur Linux. L’éditeur de jeux vidéo a annoncé travailler à renforcer la protection de son système anti-triche, Easy Anti-Cheat sous Linux, afin de permettre au jeu de fonctionner sur ce système d’exploitation.

En Europe, on fait de moins en moins le parallèle entre open source et réduction des coûts.

Cette tendance s’est dessinée au gré des sondages annuels de la Fondation Linux. En tout cas de la restitution qu’elle en fait depuis 2022 pour le périmètre européen, sous forme de rapports d’une quarantaine de pages.

Nous en avons proposé une brève analyse centrée sur l’utilisation de l’open source. En miroir, il y a l’aspect contribution, que nous traitons ici.

Les contributions à l’open source, de moins en moins motivées par le développement de carrière

De 2022 à 2024, la Fondation Linux s’est arrêtée, dans ses synthèses, sur ce qui motivait les sondés à contribuer à des projets open source sur leur temps personnel.

En 2022, ils furent 78 % à déclarer que l’apprentissage et le développement personnel avaient une grande ou une très grande influence. 64 % avaient cité l’attrait du travail entre pairs. 62 %, leur responsabilité morale envers la communauté en tant qu’utilisateurs. 57 %, le moyen de combler un besoin technologique non satisfait. 48 %, les opportunités de carrière.

Le taux de mention de l’item « opportunités de carrière » a reculé en 2023 (44 %), puis en 2024 (42 %). Il est resté moins cité que l’apprentissage / développement personnel (62 %, puis 74 %), la satisfaction d’un besoin technologique (51 %, puis 55 %), la responsabilité morale (47 %, puis 53 %) et le travail avec les pairs (44 %, puis 59 %).

Des contributions inner source en premier lieu

En 2022, la pratique la plus courante de contribution à l’open source était la remontée de problèmes (ouverture d’issues). 63 % des organisations s’y adonnaient. 48 % contribuaient au code ; 38 %, à la doc ; 18 %, à d’autres assets. Elles étaient 35 % à contribuer plus indirectement en participant à des discussions sur Reddit, Stack Overflow, etc.

Cette année-là, 46 % des répondants affirmaient que leur organisation encourageait « ouvertement » les contributions. 35 % évoquaient l’absence de politique claire. Principales motivations : améliorer la qualité de leur parc de logiciels open source (85 %), remplir l’obligation morale vis-à-vis de la communauté (74 %), accroître l’attractivité de l’organisation (72 %) et améliorer la sécurité (70 %). Parmi les répondants qui passaient au moins quelques heures par mois à contribuer à des projets, 54 % le faisaient en inner source ; 43 %, sur des projets externes créés, adoptés ou sponsorisés par leur employeur ; 33 %, sur d’autres projets externes.

En 2023, le taux de contribution au code était passé à 54 %. Le taux de participation sur Reddit & C^ie avait augmenté plus sensiblement, à 46 %. Les contributions à la documentation étaient restées stables (38 %).
Le taux de contribution avait crû aussi bien pour l’inner source (59 %) que pour les projets externes (49 % pour ceux créés, adoptés ou sponsorisés par l’employeur ; 47 % pour les autres).

Un quart des organisations sous-traitent des contributions amont

En 2025, la Fondation Linux avait examiné le niveau d’implication sur 4 échelons. Il en était ressorti :

• 14 % d’organisations « très actives » (maintenance de dépendances-clés ou contribution régulière à leur code)
• 28 % de participation « modérée » (contributions occasionnelles au code, à la doc et au signalement de bugs)
• 20 % de contributions « limitées » (remontées de problèmes et discussions, essentiellement)
• 23 % d’organisations « passives » (pas de contributions)

Cette année, la synthèse du rapport State of Open Source in Europe ne présente pas tant le degré d’implication que la forme qu’elle prend. 59 % des organisations contribuent à des dépôts en amont. 26 % délèguent cette tâche à du personnel externe. 37 % s’impliquent dans la gouvernance des projets. 48 % maintiennent des forks en interne.

ROI, licences et propriété intellectuelle, principaux obstacles aux contributions

Au fil des ans, les questions de licences / propriété intellectuelle et le manque de clarté sur le ROI se sont affirmés comme les principaux freins aux contributions à l’open source. La Fondation Linux a en tout cas fini par ne plus mentionner que ces aspects dans ses synthèses (2025 et 2026).

Freins	2022	2023	2024	2025	2026
Manque de clarté sur le ROI	49 %	31 %		28 %	33 %
Crainte de fuite de propriété intellectuelle	43 %	36 %		24 %	40 %
Absence de politique claire et/ou de ressources associées	41 %	30 %
Questions juridiques / licences	40 %	36 %	14 %	31 %	42 %
Contraintes technologiques	34 %	25 %
Manque de temps			73 %
Difficulté à comprendre les règles de contribution des projets			33 %
Crainte de rejet des contributions ou de retours négatifs			31 %
Manque de compensations pour les contributions			26 %
Feed-back inadéquat des mainteneurs			26 %
Problèmes de communication (dont barrière de la langue)			7 %

En 2024, plus de la moitié des répondants (51 %) disaient ne pas savoir si la réglementation influençait la participation de leur organisation à l’open source.

Deux ans plus tard, ils sont nettement plus nombreux à déclarer un impact sur la gestion des dépendances. Pour 20 % d’entre eux, le changement est net. Pour 26 %, il est modéré ; pour 17 %, mineur. 23 % n’en perçoivent pas.

Les sondés réclament d’abord du temps

Quant à ce qui accroîtrait les contributions, qu’on les interroge sous le prisme de leur organisation (2022 et 2023) ou bien dans une perspective globale (2025), les sondés privilégient toujours l’option « donner plus de temps aux employés ».

En 2022, suivaient le financement de projets (62 %), la sensibilisation à la proposition de valeur (61 %), la mise en open source de produits ou outils internes (55 %), la mise en place de politiques plus claires pour les employés (54 %) et l’implication dans l’élaboration de politiques au niveau industriel ou gouvernemental (44 %).

En 2023, les priorités avaient changé… mais la question aussi (qu’est-ce que améliorerait la « soutenabilité » des projets). Derrière l’allocation de davantage de temps aux employés (63 %), il y avait :

• Accepter la responsabilité de contribuer en retour (54 %)
• Sponsoriser des projets axés sur l’interopérabilité (46 %)
• Donner des incitations financières pour les contributions à des projets qui ont un intérêt pour l’organisation (40 %)

Invités en 2025 à sélectionner jusqu’à trois options, les sondés avaient placé, derrière l’allocation de temps aux employés (42 %), la sensibilisation à la proposition de valeur (28 %). Puis le financement de projets (27 %), la définition de politiques plus claires (24 %) et la publication de produits ou d’outils internes (22 %).

Illustration © pexels – Shutterstock

The post En Europe, une approche de moins en moins « carriériste » de l’open source appeared first on Silicon.fr.

Qu’on s’en tienne au parc logiciel ou qu’on élargisse à l’exploitation informatique voire au budget global de fonctionnement des entreprises, l’open source est de moins en moins vu comme un levier de réduction des coûts.

La Fondation Linux ne l’affirme pas, mais les données communiquées au fil des ans dans son rapport State of Open Source in Europe le suggèrent.

Jusque-là, elle en a publié 5 éditions (2022-2026), à partir des éléments recueillis dans le cadre de son sondage World of Open Source. Nous n’en reprenons pas les résultats « bruts », mais les synthèses – d’une quarantaine de pages en moyenne. Une vision partielle, donc, surtout que certains sujets tendent à en chasser d’autres. Pour autant, des tendances se dégagent…

La réduction des coûts, de moins en moins mentionnée…

En 2022, lorsqu’on leur avait demandé pourquoi il fallait accroître l’usage de l’open source, 64 % des sondés avaient sélectionné l’option « réduire les coûts logiciels ». Ils avaient été à peu peu aussi nombreux à choisir les items « améliorer la productivité » (65 %), « améliorer la sécurité » (63 %) et « accroître l’attractivité des organisations » (63 %).

Pour 2023 et 2024, la Fondation Linux avait légèrement changé l’angle de la question. Elle avait demandé aux sondés les aspects sur lesquels l’open source bénéficiait le plus aux secteurs économiques.

En 2023, les deux éléments les plus cités furent la productivité (59 %) et l’innovation (58 %). La réduction des coûts de fonctionnement n’était arrivée qu’au troisième rang (57 %). La réduction des coûts de développement produit (51 %) était au niveau des standards industriels et de l’interopérabilité (52 %) et de la collaboration (51 %). Suivaient transparence (48 %), partage des données (33 %), conformité (31 %) et gestion du risque (29 %).

En 2024, l’option « standards industriels et de l’interopérabilité » avait largement été la plus citée (66 %), devant l’innovation (58 %) et la productivité (55 %). Ils ne furent plus que 51 % à mentionner la réduction des coûts de fonctionnement (et 54 %, la réduction des coûts de développement produit). Pour le reste, pas de grande variation (transparence : 53 % ; collaboration : 47 % ; partage des données : 27 %, etc.).

En 2025, nouveau changement d’angle, tout du moins dans la synthèse. Les sondés devaient sélectionner les bénéfices pour le secteur d’activité. Ils furent moins de la moitié (48 % en l’occurrence) à choisir les coûts de fonctionnement. Contre 49 % la transparence et 58 % l’innovation, entre autres.

… quel que soit l’angle de questionnement

La tendance est similaire, quoique moins marquée, si on oriente la question sur la fréquence à laquelle l’open source procure des bénéfices.

En 2023, ils furent 82 % à déclarer que l’open source abaissait « souvent » ou « toujours » les coûts logiciels. C’était l’item le plus cité, devant l’augmentation de la productivité (79 %), la réduction du lock-in (77 %), l’amélioration de la qualité logicielle (76 %), etc. Ils furent, en parallèle, 64 % à répondre « toujours » ou « souvent » concernant la baisse des coûts d’exploitation informatique.

En 2024, il n’y avait plus d’option « toujours ». Les coûts logiciels avaient à nouveau réuni la plus forte proportion de « souvent » (66 %), mais à égalité avec la productivité (66 %) et juste devant le lock-in (65 %). La réduction des coûts d’exploitation IT (47 %) avait glissé, entre autres, derrière l’amélioration de la sécurité (51 %).

En 2025, ils furent encore moins à juger que l’open source procurait souvent des bénéfices en matière de réduction des coûts logiciels : 58 %. Ils furent davantage à citer la productivité (63 %) et la réduction du lock-in (62 %). Recul aussi, même si moins prononcé, pour la réduction des coûts d’exploitation IT : 45 %, dans les mêmes eaux que « accroître l’attractivité de l’organisation » et « accélérer la mise sur le marché » (44 %).

Rapport coûts-bénéfices : une perception devenue moins positive

À deux reprises, la Fondation Linux a évoqué la perception du rapport coûts-bénéfices.

En 2023, 77 % des sondés avaient jugé que ce rapport était en faveur des bénéfices. Il l’était même « largement » pour 40 % de l’échantillon. Seuls 5 % avaient estimé que l’open source engendrait plus de coûts.

En 2025, ils ne furent plus que 55 % à déclarer davantage de bénéfices que de coûts. À l’inverse, 12 % constataient plus de coûts que de bénéfices (5 % en constataient même « largement » plus).

Ces deux mêmes années, la Fondation Linux a listé dans sa synthèse les technologies open source les plus utilisées au sein des organisations pour lesquelles travaillaient les sondés. En voici un récapitulatif :

Technologies open source	Taux d’utilisation 2023	Taux d’utilisation 2025
Systèmes d’exploitation	73 % (Linux)	64 %
Cloud / conteneurs	65 %	55 %
DevOps & CI/CD	60 %	52 %
Bases de données & data management	57 %	53 %
DevOps / GitOps / DevSecOps	56 %	51 %
Développement web et applicatif	54 %	54 %
Kubernetes	47 %
Cybersécurité	42 %	36 %
Analytics & data science	41 %	33 %
IA / ML	34 %	41 %
IoT & embarqué	29 %	19 %
Stockage	29 %	26 %
Réseau	23 %	20 %
Edge	22 %	13 %
Open hardware	14 %	5 %
Blockchain	12 %	6 %
AR / VR	9 %	10 %
Données et modèles ouverts		22 %

La sécurité, désormais en tête des facteurs limitants

Pour ce qui est des facteurs limitant l’usage de l’open source, la perception s’avère beaucoup plus stable au fil des ans.

En 2022, la Fondation Linux avait fait le distinguo entre les métiers de l’IT et les autres populations. Chez les premiers, licences et propriété intellectuelle étaient le frein le plus cité (28 %). Suivaient :

• Manque de compréhension de la proposition de valeur non technologique (27 %)
• Absence de politique ou de ressources pour la soutenir (25 %)
• Réglementations et autres restrictions formelles (18 %)

Les autres populations avaient mentionné principalement l’absence de politique ou de ressources pour la soutenir (49 %). Puis :

• Manque de compréhension de la proposition de valeur non technologique (46 %)
• Licences / propriété intellectuelle (44 %)
• Réglementations et autres restrictions formelles (33 %)

En 2025 et 2026, plus de distinction entre « l’IT et les autres » dans la synthèse du rapport State of Open Source in Europe. Mais au final, relativement peu d’évolution dans la hiérarchie des freins perçus.

En 2025, la Fondation Linux s’en était tenue à trois freins : manque de support technique (40 %), licences / propriété intellectuelle (35 %) et manque de compréhension de la valeur non technologique (34 %). Cette année, elle a élargi la sélection :

Irritant	Taux de mention
Sécurité	39 %
Licences	36 %
Support technique	35 %
Manque de leadership	34 %
Manque de compréhension (de la valeur)	34 %
Absence de politique ou de formation	34 %
Qualité	31 %
Réglementation	28 %
Identité ou affiliation des mainteneurs de projets	26 %

Comprendre la valeur non technologique

À trois reprises, la Fondation Linux a mis en avant ce que les sondés considéraient comme les principaux leviers pour accroître l’usage de l’open source.

En 2022 et 2023, il leur avait été demandé de se prononcer au niveau global. En 2025, au niveau de leur organisation – ce qui peut expliquer les taux de mention plus bas. Les intitulés de certaines options ont changé d’un sondage à l’autre ; auquel cas nous en donnons une formulation la plus « harmonisée » possible.

Levier	2022	2023	2025
Assistance juridique / conformité / sécurité	51 %	56 %	26 %
Amélioration de la politique open source ou des ressources associées	51 %	60 %	22 %
Présence d’un OSPO ou d’un leadership visible	45 %	58 %	34 % (leadership 19 % (OSPO)
Outils automatisés	44 %	52 %	16 %
Compréhension de la valeur non technologique	40 %	53 %	30 %
Amélioration des pratiques de développement sécurisé		55 %	21 %
Utilisation de SBOM		49 %	17 %

Le codage par IA, coup de boost pour l’open source

Il y a des données au sujet du niveau d’encouragement à utiliser l’open source, mais elles sont assez « anciennes ». Les voici tout de même.

En 2022, 57 % des sondés avaient déclaré que leur organisation encourageait « ouvertement » à utiliser l’open source. 22 %, qu’elle le faisait « sous conditions ». 1 %, qu’elle ne le permettait pas. 17 %, qu’il n’y avait pas de politique claire.

La répartition des réponses avait peu évolué en 2023 : 53 % d’« ouvertement », 12 % de « sous conditions », 1 % de « non » et 9 % de « pas clair ». Mais c’était essentiellement lié à l’intégration d’un choix supplémentaire : « Chaque équipe de développement décide ». 24 % des sondés l’avaient sélectionné.

Cette année, la Fondation Linux glisse une stat sur le codage assisté par IA. 48 % des sondés affirment que cela a accru leur utilisation de bibliothèques et de frameworks open source (15 %, « nettement plus »). 47 % déclarent que cet usage est resté stable. 5 %, qu’il a reculé (1 %, « nettement »).

Illustration générée par IA

The post Open source et réduction des coûts : l’Europe fait de moins en moins le parallèle appeared first on Silicon.fr.

Si vous avez lu mon article sur QBZ , le client Qobuz open source qui permettait d'écouter sa musique en "bit-perfect" sous Linux, hé bien oubliez-le. En effet, Qobuz a demandé à son développeur d'arrêter le projet, et ce dernier n'a pas eu d'autre choix que d'obéir. Bref, le dépôt est fermé et il n'y aura plus de mise à jour.

C'est sacrément dommage je trouve...

Après la raison, comme expliquée ici par le support de Qobuz, c'est que cette application plaçait Qobuz en position "non conforme" vis-à-vis des ayants droit notamment parce que les lectures ne sont pas comptabilisées côté Qobuz, ce qui laisserait les artistes sans rémunération.

Perso, j'aime bien Qobuz et je trouve qu'ils font du super boulot, mais ils ont sacrément manqués de stratégie sur ce coup là !

Je ne sais pas si techniquement ça aurait été jouable, mais à leur place, j'aurais demandé au dev de QBZ d'intégrer mes API de mesure (en plus de lui filer un petit chèque) sans pour autant rendre proprio le code. Ou au pire, je l'aurais embauché pour faire un vrai client Linux officiel avant de laisser mourir ce projet libre, ce qui leur aurait éviter de prendre un risque avec leur image auprès de la communauté du libre.

Bref, 1/ ils se privent d'un super client Linux 2/ ils perdent un dev qui a quand même taffé durant des années bénévolement pour leurs services 3/ j'imagine qu'ils vont également perdre des abonnés payants sous Linux. 4/ Et ils prennent le risque de voir débarquer des forks de rebelles moins conciliants avec leurs services.

De mon point de vue ce n'était pas une décision très réfléchie, même si c'est vrai, ils ont été pro et courtois avec le dev de QBZ (traduction : ils ne lui ont pas mis un procès au cul).

Dommage.

Switch, Wii U, 3DS, PS2, GameCube : la scène homebrew PS5 transforme la console de Sony en machine à tout faire. Et ce n’est que le début.

Ventoy , je vous en ai déjà parlé à de multiples reprises et vous connaissez ça mieux que moi ! C'est cet outil open source qui transforme une clé USB en clé bootable sur laquelle vous glissez vos ISO comme de simples fichiers, sans avoir à reformater à chaque fois. Et ça c'est super pratique puisque comme ça, au démarrage de votre ordi, vous avez un menu qui vous laisse choisir sur quoi démarrer... Windows 10 ? Windows 11 ? Un Linux ? Mais il lui manquait tout de même quelque chose ! Pouvoir lancer SteamOS !

Et c'est chose faite depuis aujourd'hui puisque Ventoy vient de se voir ajouter du support, encore expérimental certes, des images de récupération de SteamOS, c'est à dire celles que Valve propose sur son site d'assistance de Steam afin de réinstaller la console.

Le souci avec SteamOS venait de l'image elle-même, qui n'est pas une ISO mais un fichier .img contenant un disque GPT brut, et que Ventoy ne parvenait pas à démarrer convenablement. Mais c'était sans compter sur matte-schwartz, un des contributeurs au projet qui a proposé un correctif en juillet, sur lequel le développeur de Ventoy a ensuite apporté ses propres optimisations avant de l'intégrer définitivement dans le projet.

Par contre, "cuidado con el ISO" car Valve distribue cette image compressée, en .img.bz2 ou en .img.zip, et Ventoy ne lit PAS le .img.bz2. Donc vous devrez d'abord décompresser ce truc .img (avec bunzip2 pour le .bz2, par exemple), puis la copier sur la clé avec le reste.

L'autre gros morceau de cette nouvelle version de Ventoy concerne Linux. Maintenant, quand vous booterez une distrib live direct depuis votre clé USB, la partition qui contient vos ISO sera accessible directement depuis la barre latérale du gestionnaire de fichiers. Et ça c'est cool !

Cette partition Ventoy porte aussi désormais un nom stable, /dev/mapper/VentoyPart, et les icônes de disque en double qui encombraient la barre latérale de certaines distributions ont totalement disparu ! Et si la vôtre n'est pas dans la liste et vous répond "device busy", ne stressez pas, suffit juste de monter /dev/mapper/VentoyPart à la mano.

Et s'il n'existe pas, lancez ces deux commandes puis réessayez :

sudo udevadm trigger
sudo udevadm settle

Voilà et pour le reste des news, cette 1.1.18 corrige le démarrage de la bêta de Fedora 45, la vérification de version du Secure Boot qui échouait avec Windows et WinPE, ainsi que la persistance qui lâchait de temps en temps sous Ubuntu Desktop. Et CloneZilla peut maintenant monter la partition des ISO lui aussi.

Si ça vous chauffe de mettre à jour, récupérez la version sur la page GitHub de la release , puis passez par la mise à jour plutôt que par une nouvelle installation, comme ça vos ISO resteront alors en place.

Source : Neowin

Le P.T. de Kojima, ce "playable teaser" de Silent Hills que Konami a retiré du PlayStation Store en 2015, a maintenant un portage natif pour Windows et Linux et c'est signé Lorean Xavier.

Pour ceux qui ne connaissent pas ce jeu, P.T. est sorti gratuitement sur PS4 en août 2014, sous le nom d'un studio qui n'existait pas, 7780s Studio. On y parcourt un couloir en L qui tourne en boucle, en marchant et en zoomant, pendant que Lisa, un fantôme, nous traque. Et si elle nous attrape, eh bien la boucle infernale recommence encore et encore... Et bien sûr, ce maudit couloir change à chaque tour réussi !

Ensuite, une fois la dernière énigme résolue, on avait droit à un trailer annonçant Silent Hills, réalisé par Hideo Kojima et Guillermo del Toro avec Norman Reedus dans le rôle principal. Le vrai jeu a ensuite été malheureusement annulé, et P.T. n'a survécu depuis uniquement sur les PS4 qui l'avaient conservé ou via l'émulation.

RNDS-Stream , c'est une appli homebrew incroyable pour la Nintendo DSi (sortie en 2008 quand même... ça date de fou !) qui affiche en live n'importe quel jeu depuis votre PC Linux. Le PC capture la fenêtre du jeu et l'envoie en MJPEG sur le réseau local, puis la console décode ce flux vidéo, et le clavier et la souris du PC sont pilotés à distance via ydotool .

Si ça vous intéresse, la vidéo ci-dessous montre le projet en action (vers les 4 min 48) avec côté console, le décodage du MJPEG passant par RubyNDS , qui est le framework Ruby que l'auteur s'est monté pour programmer la DSi. Et avec les bons réglages de GStreamer, ça peut grimper à 20 images par seconde avec saut d'images, ou plus modestement de 10 à 15 images par seconde en résolution max sur la DSi. Le serveur de son côté, repère tout seul votre bibliothèque Steam et vos instances Prism Launcher pour vous permettre de lancer les jeux de votre choix.