Planète Warez

@El-Bbz a dit dans Linus Torvalds réhabilite l'écran bleu de la mort de Windows et explose un mythe : « Une grande partie de ces problèmes ne sont en réalité pas dus à des bugs logiciels... mais à un matériel peu fiable » :

combien peuvent dire qu’ils les ont lus

Je peux le dire, et j’ai ensuite réglé le soucis de la limite des 137g avec l’outil nLite comme un grand. :ahah:

Le Steam Deck, Proton et la lassitude envers Windows des catalyseurs de cette montée en puissance

L’ascension de Linux dans l’univers du gaming n’a jamais été aussi spectaculaire. Le mois de novembre marque un tournant décisif : selon les données de Steam Hardware & Software Survey, la part d’utilisateurs Linux sur Steam a atteint un niveau record, propulsée par une combinaison de facteurs techniques, stratégiques et culturels. Ce qui ressemblait autrefois à un marché de niche se transforme aujourd’hui en un véritable pilier d’adoption pour l’OS libre, à la faveur d’une accélération continue depuis le lancement du Steam Deck et l’amélioration fulgurante des technologies d’émulation et de compatibilité.

La plupart des passionnés de technologie ont déjà entendu parler du Steam Deck, voire en possèdent un, et ont peut-être même installé des distributions Linux basées sur SteamOS telles que Bazzite ou Chimera. La réaction négative, certes modeste mais croissante, contre les exigences matérielles strictes et les mises à niveau forcées de Windows 11 est peut-être devenue évidente dans la dernière enquête Steam Hardware & Software Survey, qui montre un record historique de 3,20 % pour Linux.

Ce chiffre représente une augmentation de 0,15 % en seulement un mois, ce qui est assez impressionnant si l’on considère que pendant des années, l’utilisation de Steam Linux était inférieure ou à peine supérieure à 1 %. Le lancement du Steam Deck en 2022 a naturellement fait grimper ce chiffre, mais la communauté des joueurs semble se rallier aux dérivés de SteamOS, puisque cette famille de systèmes d’exploitation détenait une part de marché de 1,9 % en 2023, de 3,05 % en 2025 et de 3,20 % actuellement. GamingOnLinux a mis à jour son nouveau graphique de distribution dont voici un aperçu ci-dessous.

Bien que la Steam Deck soit un produit valable en soi, il n’est pas difficile d’imaginer que l’essor de Linux s’explique en partie par les manigances de Windows 11, telles que les mises à jour qui endommagent les machines, une expérience utilisateur truffée de notifications et de pop-ups, l’intégration forcée de Copilot et OneDrive et, bien sûr, la mise à niveau forcée depuis Windows 10.

Un pic historique : Linux dépasse un nouveau seuil symbolique

Le rapport mensuel publié via la Steam Hardware & Software Survey donne le ton : la part d’utilisateurs Linux progresse encore et atteint un niveau jamais vu. Cette hausse s’inscrit dans une tendance désormais structurelle. Le Steam Deck, motorisé par SteamOS (une distribution Arch Linux modifiée), constitue aujourd’hui l’un des principaux moteurs d’adoption, et son succès redéfinit la place de Linux dans l’écosystème gaming.

Ce dynamisme se reflète dans deux éléments clés. D’abord, la plateforme semble désormais s’être imposée comme une alternative crédible pour les joueurs en quête d’indépendance face au modèle Windows. Ensuite, la croissance ne dépend plus uniquement des passionnés historiques du libre : elle attire un public nouveau, parfois peu technophile, mais séduit par la simplicité du Steam Deck et la stabilité proposée.

Steam Deck : catalyseur, évangélisateur et laboratoire technologique

Il est impossible de comprendre cette progression sans examiner le rôle central du Steam Deck. Valve a réussi un mouvement que peu anticipaient : faire de Linux non pas un « OS pour power users » mais un environnement préconfiguré, sans friction, où Proton — la couche de compatibilité basée sur Wine — exécute la quasi-totalité des jeux Windows avec un niveau de performance souvent comparable, voire supérieur.

Le Deck agit alors comme une forme d’évangélisation douce. L’utilisateur lambda découvre qu’il joue en réalité sous Linux. Il découvre ensuite qu’il peut basculer en « mode bureau », profiter d’une distribution complète, installer flatpaks, développeurs, IDE, applications professionnelles… Le gaming devient alors la porte d’entrée vers un usage élargi.

Pour l’industrie IT, ce phénomène représente un cas d’école en matière d’adoption technologique : un produit matériel a réussi à embarquer un OS libre au cœur d’un usage de masse.

Steam Machine pour assurer la continuité ?

Près de quatre ans après que la Steam Deck ait révolutionné le monde du jeu portable, Valve s’apprête à commercialiser du matériel fonctionnant sous SteamOS, conçu pour les téléviseurs de salon, voire pour remplacer les PC de bureau dédiés au jeu. Baptisés simplement Steam Machine et Steam Controller, ces deux produits, dont la commercialisation est prévue début 2026, sont « optimisés pour le jeu sur Steam et conçus pour permettre aux joueurs de tirer encore davantage parti de leur bibliothèque Steam », a déclaré Valve dans un communiqué de presse.

La fiche technique de la Steam Machine partagée par Valve mentionne un processeur AMD Zen 4 à six cœurs « semi-personnalisé » cadencé à 4,8 GHz, ainsi qu’un processeur graphique AMD RDNA3 avec 28 unités de calcul. La carte mère comprendra 16 Go de RAM DDR5 et 8 Go supplémentaires de VRAM DDR6 dédiée pour le GPU. Le nouveau matériel sera disponible en deux configurations avec 512 Go ou 2 To de « stockage SSD » non spécifié, mais Valve n’a pas encore communiqué les prix.

Ces puces et ces chiffres suggèrent que la Steam Machine aura à peu près la même puissance qu’un PC de jeu de bureau de milieu de gamme d’il y a quelques années. Mais Valve affirme que sa « Machine » — qu’elle classe comme « plus de 6 fois plus puissante que la Steam Deck » — est suffisamment puissante pour prendre en charge le ray tracing et/ou les jeux en 4K à 60 images par seconde grâce à l’upscaling FSR.

La nouvelle Steam Machine s’éloigne résolument du concept hybride console/PC pour embrasser pleinement son identité de mini-ordinateur surpuissant. Les tests préliminaires et les données publiées indiquent une architecture basée sur un APU de dernière génération, capable de délivrer une puissance brute que la Steam Deck ne peut tout simplement pas approcher. La promesse est ambitieuse : offrir une machine taillée pour du 1440p fluide, voire du 4K raisonnable, le tout dans un châssis compact rappelant les meilleurs mini-PC du marché.

Valve a également revu son approche thermique. L’objectif n’est plus seulement de miniaturiser, mais de garantir un fonctionnement stable en charge prolongée. La firme insiste sur un refroidissement silencieux, un argument que les joueurs de salon attendent depuis longtemps sur un hardware PC. L’idée est simple : offrir l’expérience console sans renoncer à la liberté PC.

<iframe width=“640” height=“390” src=“

D’autres statistiques intéressantes : hardware, répartition des cœurs, cartes graphiques

Du côté matériel, les processeurs AMD poursuivent leur progression constante face à Intel. AMD détient désormais 43,56 % du marché des processeurs pour jeux vidéo, contre 56,44 % pour Team Blue. À l’exception d’un seul mois, la part de marché des processeurs Intel n’a cessé de reculer depuis près d’un an et ne montre aucun signe de ralentissement.

La répartition des cœurs de processeurs est également intéressante. Au cours du seul mois dernier, les processeurs dotés de 8 cœurs physiques ou plus ont enregistré une hausse combinée de 1,18 % (sous Windows, du moins), ce qui signifie que les joueurs achètent ou mettent à niveau leurs machines à un rythme assez rapide, et que les consommateurs optent principalement pour des systèmes AMD.

En ce qui concerne les cartes graphiques pour jeux vidéo, des évolutions surprenantes ont été observées. La RTX 5070 est désormais le GPU Blackwell le plus courant parmi les systèmes étudiés, avec une hausse de 0,33 % pour atteindre 2,12 % du parc total. Cela représente environ autant d’utilisateurs que ceux de la RTX 5060 et de la RTX 5060 Ti réunis, ce qui n’est pas l’évolution à laquelle nous nous attendions compte tenu du rythme apparent d’adoption de la RTX 5060.

La RTX 5060 a augmenté sa part de 0,30 % pour atteindre 1,54 % des systèmes étudiés. Parallèlement, la RTX 5070 Ti a enregistré une augmentation de 0,19 % de sa part pour atteindre 1,09 % du parc, tandis que la RTX 5080 a augmenté de 0,14 % pour atteindre 0,96 %.

La défiance envers Windows 11 nourrit une migration technologique

L’évolution du marché ne peut être lue uniquement à travers Steam et Valve. Une partie de la hausse observée est aussi alimentée par le recul de Windows 11 auprès d’une frange du public PC. L’inflation des exigences matérielles, les contraintes de sécurité, la multiplication des services connectés et l’omniprésence des fonctionnalités basées sur l’IA créent un malaise perceptible.

De nombreux joueurs expérimentés expriment une forme de lassitude face à la direction prise par Microsoft. Linux apparaît alors, pour la première fois, comme une alternative solide, moderne et performante. Ce changement culturel s’inscrit dans une dynamique plus large de recherche d’indépendance numérique et de souveraineté logicielle.

La situation est telle que, tandis Microsoft pousse son écosystème vers une nouvelle ère dominée par l’IA agentique, près de 500 millions d’utilisateurs refusent de migrer vers Windows 11[…

Suite de l’article réservée aux abonnés : developpez.com

Ça me semblerait quand même très gros pour être plus qu’un effet d’annonce, désamorcé ensuite, comme bien d’autres.
Puis c’est pas cohérent avec America First! pour le coup, business avant tout.

En revanche, je pense que TRUMP et son administration pourraient avoir (eu ?) une utilisation bien à eux du Cloud Act dans le cadre du business justement.
https://www.lemagit.fr/definition/CLOUD-Act

Vu que c’est un PC sous Linux dans la boiboite, il doit être possible de brancher clavier et souris.

Dans le monde Linux, on entend parler des serveurs graphiques X11 et Wayland depuis longtemps. Mais de quoi s’agit-il exactement ? À quoi sert un serveur graphique ? Quelles sont les promesses de Wayland et pourquoi la migration prend autant de temps ? Nous vous proposons d’y voir plus clair.

Présentons les deux protagonistes de notre sujet. D’un côté, le X Window System. Sa première version date de 1984, en tant que projet développé au sein du MIT. Il a été essentiellement pensé à une époque où l’on trouvait des serveurs informatiques puissants et des clients légers, d’où son appellation de serveur, qui lui est resté.

On le connait mieux aujourd’hui sous son nom de X11. L’appellation vient de la onzième version de X, sortie en 1987. Ce fut la première révision à être considérée comme stable et pleinement opérationnelle. Et oui, techniquement, on utilise cette onzième version depuis 35 ans. Mais dans la pratique, les évolutions ont été continues.

De l’autre côté, on a Wayland. Beaucoup plus récent, le projet a été lancé en 2008 par Kristian Hogsberg, développeur chez Red Hat. Objectif, proposer un protocole moderne et gagnant sur toute la ligne : plus sécurisé, plus efficace et surtout plus simple. Une base neuve, capable d’exploiter beaucoup mieux le matériel qui avait largement évolué et de se débarrasser des vieilles assises de X11.

Penchons-nous maintenant sur ce qu’est un serveur graphique (ou d’affichage), le rôle que tient ce composant et ses principaux attributs.

Commençons par le commencement. Sur un système de type Unix, dès que vous voyez quelque chose s’afficher à l’écran au sein d’une interface graphique, c’est que le serveur d’affichage est impliqué. Ce composant crucial est chargé de dessiner les fenêtres à l’écran et de gérer toutes les interactions qui s’y rapportent, ainsi que la composition de l’ensemble (assemblage des fenêtres). Il est une interface entre l’utilisateur, l’interface et le matériel lié. Il va d’ailleurs plus loin que le seul aspect graphique, puisqu’il s’occupe également des entrées de la souris et du clavier.

Au départ, l’architecture graphique était monolithique. Le serveur d’affichage devait avoir un accès complet, direct et exclusif à la carte graphique. Dans ce contexte, les pilotes – qui gèrent toute l’exploitation du matériel – étaient placés en espace utilisateur, sans accès direct au noyau. Une approche a priori sécurisée, mais qui s’est progressivement révélée peu efficace dans de nombreux scénarios. Toute la logique critique de l’affichage se retrouvait gérée par un composant unique qui embarquait tous les pilotes nécessaires.

Plusieurs composants sont donc apparus avec le temps pour répartir ce fonctionnement et répondre aux problématiques. D’abord le DRM, ou Direct Rendering Manager. En tant que sous-système du noyau Linux, il gère les accès au GPU. Il tient un rôle d’arbitre : il s’occupe avant tout de distribuer les ressources graphiques aux applications, gère la mémoire ainsi que la sécurité. Grâce à lui, les applications ont pu obtenir un accès direct au GPU (sans passer par X) et l’exploiter, avec une hausse majeure des performances.

Fedora a été la première distribution majeure à passer sur Wayland par défaut

Le KMS, ou Kernel Mode Setting, est un autre sous-système du noyau Linux. C’est à lui que revient la gestion de la résolution de l’écran, sa fréquence de rafraichissement, la profondeur des couleurs, etc. Il a permis de déplacer la logique de la « configuration de mode » de l’espace utilisateurs vers le noyau, avec plusieurs bénéfices importants. C’est grâce au KMS par exemple que la console a pu basculer en haute résolution dès le démarrage de la machine.

DRM et KMS s’utilisent à travers une bibliothèque (libdrm), qui expose des fonctions standardisées (et documentées) aux applications. L’arrivée de ces deux composants a été une étape majeure, avec une séparation nette entre la logique matérielle de bas niveau et celle d’affichage haut niveau, avec notamment tout l’applicatif, y compris le serveur graphique.

Au-dessus de DRM et KMS, on trouve un autre composant, important lui aussi, mais en espace utilisateur cette fois : Mesa. Si vous utilisez Linux, ce nom vous est peut-être familier. C’est une implémentation open source des API graphiques standard de l’industrie, comme OpenGL et Vulkan.

Prenons un exemple pour schématiser le fonctionnement général. Un jeu a des scènes 3D à faire afficher à l’écran. Il est conçu pour Vulkan et décrit donc ces scènes à l’API correspondante. Ces requêtes sont adressées à Mesa, qui s’occupe de traduire ces requêtes de haut niveau en instructions plus bas niveau, compréhensibles par le matériel. Ces instructions sont alors transmises au pilote DRM du noyau, qui les exécute sur le GPU.

Si l’on se replace dans le contexte des jeunes années de X11, il n’était question que d’architecture client-serveur. Dans cette optique, X11 avait d’ailleurs été développé pour le réseau, avec certaines caractéristiques spécifiques. Par exemple, nulle obligation que le serveur X fonctionne sur la machine la plus puissante. Selon les cas, on pouvait faire tourner le serveur X sur un poste léger, et le client X sur un gros serveur.

Ce fonctionnement, ainsi que d’autres aspects tenant à des choix faits il y a plusieurs décennies, ont alimenté la réflexion qui a mené à Wayland. En matière d’efficacité d’abord, ce modèle client-serveur devenait un poids sur les machines plus récentes : le serveur et le client étant situés sur le même ordinateur, tout ce qui touche au réseau est inutile dans de nombreux cas. Les couches de communication et de multiples étapes intermédiaires (notamment codage/décodage) devenaient superflues et se payaient par une latence.

En outre, X11 est un vieux projet, avec une partie héritée dans le code de plus en plus importante. Ses capacités ont été augmentées par d’innombrables ajouts, extensions et patchs en une énorme base plus difficile à entretenir. Un immense patchwork qui a rendu les développements plus complexes au fur et à mesure que les besoins changeaient.

L’ensemble a abouti à un pipeline de traitement peu adapté aux applications et matériels modernes. Il n’a par exemple pas été conçu pour des écrans avec de hautes fréquences de rafraichissement et un rendu sans déchirement (tear-free). Pour ce dernier problème, il a fallu recourir à des solutions spécifiques et complexes, avec une synchronisation verticale forcée, qui a introduit elle-même de nouveaux problèmes dans certaines situations, comme un « bégaiement » de l’image (le fameux stuterring).

Ubuntu 25.10 avec GNOME 49 intègre toujours X11

L’idée qui a mené à Wayland était de proposer un fonctionnement simple, sécurisé et plus efficace. Le tout en partant d’une page blanche.

Le plus gros changement réside dans la conception : le serveur d’affichage, le gestionnaire de fenêtres et le compositeur sont en fait un seul et même processus, le compositeur Wayland. Dans ce modèle, le compositeur gère l’intégralité des opérations liées à l’affichage. Il reçoit ainsi les évènements d’entrées (clavier, souris, tablettes graphiques…), gère les surfaces (fenêtres), assemble l’image finale et communique avec le noyau (via DRM et KMS, toujours là) pour afficher l’ensemble. C’est vers le compositeur Wayland que les applications se tournent pour présenter un objet à l’écran.

La sécurité est un autre changement radical, puisque Wayland impose une isolation stricte entre les clients, et donc les applications. Ces dernières ne peuvent ainsi voir que leurs propres fenêtres. Elles ne peuvent en outre recevoir les évènements d’entrées que si elles ont le focus, c’est-à-dire quand elles sont au premier plan, pour éviter qu’elles espionnent d’autres applications (ce qui vaut aussi pour les enregistreurs de frappe et les logiciels espions). De plus, elles ne peuvent pas décider où placer les fenêtres, c’est Wayland qui le fait.

L’une des grandes promesses de Wayland, c’est son approche moderne du matériel. De nombreuses caractéristiques sont nativement prises en compte. Beaucoup plus à l’aise avec les configurations multi-écrans, il gère mieux les hautes définitions (HiDPI). Il prend nativement en charge la mise à l’échelle fractionnée (125 ou 150 % par exemple), les taux de rafraichissement différents selon les écrans, les écrans tactiles et les gestes multi-touch.

Wayland est une spécification de protocole, pas un logiciel unique comme l’est X11. Il ne s’agit donc pas d’un composant standardisé auquel tous les autres peuvent se référer en tant que tel. C’est encore une différence fondamentale avec X11, puisque la responsabilité de fournir un environnement de bureau complet est déplacée vers chaque compositeur qui implémente cette spécification Wayland.

Si l’on prend les deux environnements de bureau les plus utilisés, GNOME et KDE, cette responsabilité est confiée respectivement à Mutter et KWin. Et c’est ici que les problèmes peuvent commencer, car cette approche engendre une fragmentation. Si vous souhaitez développer une application, il ne suffit pas en effet de dire « elle est compatible Wayland ». Il faut s’assurer qu’elle fonctionne correctement avec Mutter, KWin ou n’importe quel compositeur qui a implémenté Wayland. Or, ces implémentations ne sont pas identiques. Il existe des variations autour des extensions présentes et des subtilités dans la mise en application.

Ce qui nous fait entrer de plain-pied dans la grande question : pourquoi l’adoption de Wayland est-elle aussi lente ?

Dire que la transition de X11 vers Wayland a été complexe relève de l’euphémisme. On savait qu’une rupture aussi radicale dans l’approche n’aurait pas que de joyeuses conséquences. En outre, Wayland a ses propres problèmes, et certaines promesses n’ont qu’en partie été tenues.

Le modèle de sécurité entraine ainsi une grande cassure. L’isolation stricte des clients a des conséquences majeures sur les fonctionnalités, notamment d’accessibilité. Les lecteurs d’écran, à destination des personnes aveugles ou malvoyantes, ne pouvaient plus fonctionner. Il en allait de même avec les outils de partage ou d’enregistrement d’écran (Discord, OBS…), de bureau à distance (VNC, RDP…), les raccourcis clavier globaux ou encore les outils d’automatisation (Autokey…).

Il a donc fallu tout repenser. C’est là qu’entrent en piste deux composants clés : PipeWire pour l’audio et les portails de bureau XDG pour le graphique. Ces derniers sont des API de haut niveau auxquelles les applications s’adressent pour demander certaines actions, comme accéder à l’écran pour le partager. Ils agissent comme des portails sécurisés pour concentrer les demandes. Le traitement lui-même est confié à PipeWire. Celui-ci a été pensé initialement comme le successeur de PulseAudio et de Jack, mais son rôle a été étendu pour gérer les flux vidéo.

Si PipeWire est un framework utilisable en tant que tel, les portails XDG dépendent des environnements. On trouve par exemple xdg-desktop-portal-kde et xdg-desktop-portal-gnome, respectivement pour KDE et GNOME. Il faut donc que les applications fassent appel à ces composants pour faire leurs demandes.

Cette immense cassure explique déjà en bonne partie pourquoi il a fallu des années avant que des fonctions considérées comme élémentaires avec X11 soient disponibles avec Wayland. Embrayons avec un autre facteur-clé de cette lenteur dans la transition : NVIDIA.

Si vous êtes utilisateur de Linux, vous savez peut-être que posséder un GPU NVIDIA peut être synonyme de galère, notamment à cause des pilotes. Pour une expérience complète, notamment avec les jeux, il est presque obligatoire d’utiliser le pilote propriétaire fourni par l’entreprise. Problème, celle-ci avait une vision précise de comment les choses devaient être organisées.

Historiquement, la pile graphique Linux s’est organisée autour d’une API : Generic Buffer Manager, ou GBM. Cette interface est responsable de l’allocation et de la gestion des tampons graphiques en mémoire. NVIDIA ne l’a pas entendu de cette oreille et a tenté de pousser sa propre API, EGLStreams. À l’implémentation des compositeurs Wayland, il fallait ainsi ajouter des chemins de traitement dédiés à NVIDIA. Ce code spécifique a été source de retards et de bugs. Après des années de pression de la communauté, l’entreprise a finalement cédé et implémenté le support de GBM.

Ce n’était pas le seul problème. Un autre conflit existe et n’est toujours pas résolu : la bataille entre les synchronisations implicite et explicite. Historiquement (encore une fois), la synchronisation sous Linux est implicite : le pilote du noyau s’en charge et s’assure qu’une opération de lecture sur un tampon graphique ne se déclenche qu’une fois que l’opération d’écriture précédente est finie. Ce modèle a le gros avantage de simplifier le développement d’applications, mais il peut manquer d’efficacité, car le pilote ne connait pas les « intentions » de l’application. AMD et Intel ont bâti leurs pilotes open source sur ce modèle.

Dans la synchronisation explicite, c’est à l’application ou l’API graphique (comme Vulkan) d’indiquer quand une opération est terminée. La méthode a pour inconvénient de reporter cette charge sur les développeurs d’applications, dont la tâche devient plus complexe. En revanche, le parallélisme et les performances sont meilleurs. NVIDIA a choisi ce modèle pour son pilote open source. La solution n’est apparue qu’au printemps 2024 sous la forme d’un protocole de synchronisation explicite pour Wayland.

Linus Torvalds avait eu en 2012 sa façon bien à lui de dire tout le bien qu’il pensait de NVIDIA avec un

Vous avez peut-être là aussi croisé ce nom : XWayland. Ce composant a vite eu un rôle critique au sein des distributions Linux, car il assure la compatibilité en permettant aux applications X11 de fonctionner sur Wayland. Comment ? En fournissant un serveur X11 complet, qui s’exécute comme un client Wayland.

On comprend vite l’intérêt. Toutes les applications ne sont pas encore prêtes pour Wayland et certaines ne fonctionnent qu’avec X11. Lorsqu’une telle application est lancée, elle se connecte à XWayland, qui traduit les requêtes pour les envoyer au compositeur Wayland.

Il n’est donc pas question d’une simple couche d’émulation temporaire, mais bien d’un composant en soi, devenu la pierre angulaire de toute la stratégie de transition. Elle a cependant des limites, car ce modèle encapsulé peut créer des incompatibilités dans la communication entre les applications X11 et Wayland, sur des opérations très basiques comme le copier-coller ou le glisser-déposer. Ses performances sont moins bonnes, certaines fonctions peuvent être inaccessibles et des problèmes de sécurité spécifiques à X11 sont toujours là.

La transition étant loin d’être terminée, XWayland restera en place encore longtemps. C’est d’ailleurs à cause de son importance cruciale que les grandes décisions actuelles de transition plus complète vers Wayland épargnent XWayland. Par exemple, l’équipe de développement de GNOME a annoncé que la version 49 de l’environnement commencerait à supprimer tout le code lié à X11, mais cette décision ne s’étend pas à XWayland. L’équipe a depuis changé d’avis, se laissant un peu plus de temps pour supprimer ce code.

Notez que de nombreuses distributions utilisent des sessions Wayland par défaut depuis plusieurs années. Certaines permettent cependant un autre type de session depuis l’écran de connexion, dont X11. Avec le retrait du code, cette capacité disparaitra complètement.

Debian 13 permet toujours de choisir une session X11

Aujourd’hui, la transition est irréversible. Depuis l’année dernière notamment, des étapes majeures se sont enchainées, aboutissant aux décisions récentes autour de Wayland et du gommage progressif de X11 dans le code. XWayland va rester en place et assurer la compatibilité des applications n’ayant pas fait encore le voyage. Les raisons peuvent être multiples, comme un manque de moyens face à l’ampleur du travail, ou un abandon partiel ou complet du projet. Qu’il s’agisse de Fedora, Ubuntu ou encore Red Hat, tous ont annoncé des plans pour déprécier X11 plus ou moins rapidement.

X11 est désormais dans un quasi-état de maintenance. Très peu de nouveautés sont ajoutées, car l’essentiel du travail se fait sur Wayland. D’ailleurs, une bonne partie des personnes qui travaillaient sur X11 sont aujourd’hui sur Wayland.

Mais la transition aura été particulièrement longue. L’explication est multifactorielle, comme on l’a vu : NVIDIA a été un élément perturbateur majeur, le modèle de sécurité de Wayland a nécessité la réécriture complète de nombreux éléments et il a fallu du temps pour que des fonctions élémentaires soient de retour. De manière générale, si Wayland n’est pas exempt de défauts, il représente définitivement l’avenir de la pile graphique sur Linux. Et s’il doit durer aussi longtemps que X11, il restera en place plusieurs décennies.

La plupart des gros problèmes liés à Wayland sont aujourd’hui réglés, le dernier gros point à traiter étant la gestion de la synchronisation explicite au sein des compositeurs. Les prochaines années seront consacrées au polissage, à l’accompagnement des applications « récalcitrantes » ou encore à la création de fonctions manquantes, comme une véritable suite d’outils pour l’accessibilité. Il faudra également que les extensions les plus courantes de Wayland continuent leur standardisation afin de gommer les différences entre les environnements de bureau.

Source : next.ink

Sont loin d’être cons les mecs. Ils profitent de l’engouement et de la crédulité des Windowsiens sous win10 voulant passer à Linux :trollface:

En mai dernier, nous prenions en main AnduinOS. Cette distribution sans grande prétention se proposait de reprendre une base Ubuntu et de lui adjoindre un bureau aussi proche que possible de Windows 11. Objectif affiché : faciliter autant que possible les transitions pour les personnes intéressées. Elle a été créée par Anduin Xue, ingénieur chez Microsoft travaillant presque exclusivement sur Linux. Il s’agit en revanche d’un projet personnel, non affilié à l’entreprise.

Une mouture 1.4 du système est sortie le 17 octobre. Malgré le peu d’évolution dans le numéro de version, les changements sont profonds. Ils s’articulent principalement autour de la base technique, qui passe d’Ubuntu 25.04 à 25.10, avec un noyau Linux 6.17 et GNOME 49.

La version ajoute également trois extensions gnome-shell pour élargir la bascule automatique de la couleur d’accentuation dans les applications, un mode « Anduin To Go » pour les installations sur clés USB, ainsi qu’une uniformisation du nom et du logo associé au sein du système. On notera aussi le remplacement de Firefox par sa variante ESR pour éviter le paquet snap associé.

Anduin Xue précise que si la mise à jour est techniquement possible entre AnduinOS 1.3 et 1.4, elle n’est pour l’instant pas recommandée, à cause des profonds changements techniques introduits. Dans son billet d’annonce, il ajoute qu’un script dédié sera fourni dans les deux mois. « Nous nous engageons à n’abandonner aucun utilisateur de la version 1.3 et nous les aiderons finalement à passer à la version 1.4 de manière sûre et fiable. Ce plan devrait être entièrement mis en œuvre d’ici janvier 2026 au plus tard », explique le développeur.

Source : next.ink

@michmich a dit dans Fin de Windows 10 : à Bordeaux, des associations du libre sentent la différence :

mais il me semble qu’il y a des distributions orientées pour les entreprises (qui j’imagine sont un poil trop “canonical” à ton goût)

Oui tu as bien compris 🙂
Mais quand bien même elles seraient orientées entreprise, ça ne changera rien à mon problème.

Achète de la RAM 🙂

En bref:

– Amélioration visuelle et thème automatique : Première version à proposer par défaut les quatre coins arrondis pour les fenêtres et introduit la bascule automatique entre thèmes sombre et clair selon l’heure, avec des fonds d’écran dynamiques et KNightTime pour ajuster la température d’écran.

– Presse-papier et fonctionnalités pratiques : Le presse-papier Klipper permet maintenant de marquer des entrées comme favorites pour les conserver en permanence, avec support de l’encre d’imprimante, bouton mise en veille prolongée sur l’écran de connexion et recherche “floue” dans KRunner.

– Support Wayland et performances : Nouvelles capacités Wayland avec mode picture-in-picture et protocole “pointer warp”, plus les “plans de superposition” qui améliorent les performances des jeux et réduisent la consommation lors de la lecture vidéo.

La nouvelle version de l’environnement Plasma pour les distributions Linux est disponible depuis peu en bêta. L’équipe de développement a décidé de lui donner certaines capacités visuelles qui lui faisaient défaut, dont la bascule automatique des thèmes. Mais on trouve aussi bon nombre d’améliorations dans tous les recoins.

Maintenant que GNOME 49 est disponible en version finale, les regards se tournent vers la prochaine évolution majeure de l’autre grand environnement de la sphère Linux, à savoir KDE Plasma. La bêta de la version 6.5 est disponible depuis quelques jours et plusieurs distributions permettent de la tester.

Précisons néanmoins qu’il n’est pas si aisé d’essayer ces nouveautés, car peu de ces distributions fournissent un environnement Plasma sans modifications. Nous avions porté notre dévolu sur KDE Neon Testing, pour obtenir une expérience inchangée, mais la branche de test affiche toujours Plasma 6.4.5. Contrairement à ce qu’indique l’équipe de KDE dans sa présentation, c’est la branche Unstable qui dispose actuellement de Plasma 6.5.

Plasma 6.5 introduit diverses nouveautés pour l’interface. par exemple, c’est la première version de l’environnement à proposer par défaut les quatre coins arrondis pour les fenêtres, plutôt que seulement deux en haut et deux coins carrés en bas. Ce n’est pas une révolution, mais Plasma se retrouve aligné désormais avec ce que l’on peut voir dans Windows, macOS et la plupart des distributions Linux fournies avec GNOME (quand les applications sont pleinement compatibles GTK4).

Le nouveau Plasma introduit également la bascule automatique entre les thèmes sombre et clair selon l’heure de la journée. Cette fonction, qui existe depuis longtemps dans GNOME et macOS, permet de changer pour un thème sombre à l’heure du coucher du soleil, afin de fournir un environnement moins agressif pour les yeux. Comme les autres systèmes, on peut toutefois paramétrer cette bascule ou la désactiver. À noter également que Plasma 6.5 propose des fonds d’écran adaptés (« dynamiques ») et que l’on peut personnaliser quel fond est utilisé dans un mode spécifique. Le choix du thème apparait aussi dans Paramétrage rapide, à l’ouverture de l’outil Configuration.

L’équipe ajoute avoir procédé à de nombreux petits ajustement un peu partout pour améliorer la lisibilité des textes, réduire les clignotements et ajouter des correspondances visuelles à tout ce qui pourrait déclencher un son.

Plasma 6.5 introduit dans le même temps KNightTime. Comme son nom l’indique, la fonction ajuste automatiquement la température de l’écran selon l’heure de la journée, un comportement désormais classique dans les systèmes d’exploitation. Là encore, ce comportement peut être désactivé.

Les notes de version de Plasma 6.5 contiennent une longue liste d’ajouts plus ou moins notables, mais dont beaucoup s’annoncent pratiques. Exemple simple, mais parlant : la prise en charge du niveau d’encre des cartouches d’imprimante, et la possibilité de recevoir des alertes quand ce niveau devient bas.

On trouve également plusieurs améliorations notables du presse-papier et de l’application qui l’accompagne, Klipper. Plasma 6.5 ajoute ainsi une fonction réclamée depuis longtemps : pouvoir marquer certaines entrées comme favorites afin de les y enregistrer de manière permanente. Qu’importe alors le redémarrage de la machine, on pourra ressortir les éléments régulièrement collés les fois suivantes. Autre fonction, le support de la synchronisation du presse-papiers entre le client et le serveur lors de sessions de bureau à distance.

On continue dans les ajouts pratiques avec l’apparition sur l’écran de connexion d’un nouveau bouton pour déclencher la mise en veille prolongée de l’ordinateur, si le système détecte une configuration compatible. Un ajout semblable à celui des contrôles média de GNOME 49 sur l’écran de connexion, que KDE possédait déjà.

Il est difficile de rassembler les nouveautés de Plasma 6.5, tant elles sont réparties dans de nombreux composants. Par exemple, le widget Sticky Notes est beaucoup plus pratique, grâce à plusieurs améliorations : la couleur déjà utilisée est indiquée dans le menu, la couleur de la note est affichée dans le menu contextuel, l’ensemble est plus lisible en fonction du thème, et la fenêtre popup peut être redimensionnée.

On note aussi l’apparition d’interrupteur dans les paramètres rapides pour des éléments comme le Bluetooth, qui évitent de devoir cliquer sur la catégorie pour activer/désactiver un élément. On continue avec un petit rattrapage sur GNOME dans la gestion des pilotes, puisque la boutique Discover peut maintenant en gérer l’installation si besoin. Les développeurs indiquent que cette modification est utilisée avec succès depuis plus d’un an sur la distribution Solus.

Autre nouveauté très bienvenue, une page de configuration permet de rassembler toutes les permissions données aux applications basées sur des portails. Même si on pense tout de suite aux paquets Flatpak, l’équipe précise que c’est bien pour l’ensemble des portails. Pour une application, on peut ainsi voir les autorisations accordées et les désactiver si besoin. Par exemple, couper l’accès aux notifications, lui retirer sa priorité haute, ne plus lui permettre d’empêcher la mise en veille, bloquer la géolocalisation, etc.

Les recherches dans KRunner deviennent en outre plus pratiques. Le composant supporte en effet désormais la recherche « floue » pour les applications : on peut retrouver ce que l’on cherche non pas en indiquant le nom exact, on peut la décrire avec des termes génériques, qui peuvent même contenir des erreurs (dans une certaine mesure). Cette recherche prend aussi en charge les raccourcis globaux. Si vous cherchez par exemple à effectuer une capture d’écran d’une zone spécifique, il suffit de décrire le résultat à KRunner pour qu’il vous indique le bon raccourci.

Plasma 6.5 contient – inévitablement – des améliorations liées au support de Wayland. L’environnement prend ainsi en charge le mode picture in picture du « nouveau » serveur d’affichage, ainsi que le protocole « pointer warp ». Ce dernier permet à un client (comme une application) de téléporter le curseur de la souris d’un endroit à un autre. L’équipe indique que pour limiter les dérapages, cette faculté ne sera gérée qu’au sein de la fenêtre étant au premier plan.

On continue avec plusieurs nouveautés pour les tablettes. Le nouveau Plasma permet notamment de configurer les molettes, quand la tablette utilisée en contient. Ces molettes sont le plus souvent utilisées pour appliquer un niveau de zoom ou pour modifier la taille du pinceau. De même, leurs versions tactiles sont également prises en charge, comme on les retrouve parfois sur les modèles Wacom. Plasma permet alors d’en modifier le comportement, voire de les désactiver.

Enfin, signalons que Plasma 6.5 introduit les « plans de superposition » pour le traitement graphique. Le procédé évite de calculer notamment ce qui se trouve derrière une fenêtre et donc de ralentir la composition de l’ensemble. Selon l’équipe de développement, cet ajout améliore les performances et la latence pour les jeux en mode fenêtré, tout en réduisant « considérablement » la consommation d’énergie lors de la lecture vidéo. Cette capacité est encore incomplète et ne fonctionne par exemple pas sur les configurations HDR. De plus, on ne peut s’en servir que pour une seule sortie par GPU, donc pas en mode multi-écrans.

La version finale de Plasma 6.5 est attendue pour le 21 octobre. Notez que l’un des grands apports prévus, KDE Initial System Setup (KISS), est finalement reporté à la version 6.6.

– Source :

https://next.ink/201208/kde-plasma-6-5-arrondit-ses-angles-et-sadoucit-la-nuit-venue/

La distribution GLF OS, axée sur le jeu vidéo, est désormais disponible en version finale. Dans ce premier article, nous allons présenter les grandes lignes du système. Dans un deuxième temps, nous ferons une prise en mains de GLF OS et nous pencherons plus généralement sur le jeu vidéo sur Linux.

Mise à jour du 10 septembre :

La version finale de GLF OS vient d’être mise en ligne. Comme nous l’indique Vinceff, à l’origine du projet, cette mouture corrige de nombreux bugs et apporte diverses améliorations, dont des optimisations dans le noyau.

On note également quelques nouveautés, comme l’arrivée d’un alias permettant de voir la dernière mise à jour installée, l’ajout d’un écran de bienvenue pour guider les nouveaux utilisateurs, le support du VRR dans la version GNOME, ou encore l’ajout de plusieurs extensions.

Pour les personnes qui avaient installé la bêta, l’arrivée de la version finale se fera comme n’importe quelle autre mise à jour. Sur le serveur Discord de la distribution, on peut lire qu’un ou deux redémarrages peuvent être nécessaires. Les utilisateurs ayant choisi la variante « rolling » seront basculés sur la branche testing le 17 septembre. À cette date, cette dernière passera automatiquement sur la version N+1 de la distribution. La documentation fournit une méthode pour passer de stable à testing ou inversement sans réinstallation du système.

Les évolutions du système se feront désormais au rythme d’une version par saison. La prochaine arrivera donc dans environ trois mois.

Article originel du 4 juin :

Le jeu vidéo représente souvent une barrière au changement d’environnement. Sur PC, l’immense majorité des titres ne sont disponibles que sous Windows, quelle que soit la boutique utilisée pour y jouer. Il est plus simple de trouver des équivalents Linux pour la plupart des applications que de faire fonctionner ses jeux préférés. Du moins, ce fut le cas pendant longtemps.

La situation a sérieusement commencé à évoluer ces dernières années, sous l’impulsion de Valve particulièrement. Le projet Proton, issu d’un fork de Wine, est désormais au cœur d’une offensive de l’éditeur dans le monde du jeu vidéo. Il est pleinement intégré à Steam OS, que l’on retrouve surtout sur la console portable Steam Deck. Celle-ci ayant connu un grand succès commercial, elle a fait des émules, entrainant une réflexion nouvelle sur la possibilité de jouer sur Linux. GLF OS arrive donc à un tournant intéressant.

Vinceff, très impliqué dans la communauté Linux avec notamment de nombreuses vidéos tutos, est l’initiateur de GLF OS (dépôt GitHub). Comme il nous le raconte, il était utilisateur de Mageia. Il avait basculé sur Linux après une énième mise à jour problématique de Windows 10 et s’était rendu compte que ses jeux principaux fonctionnaient sur la distribution. C’est dans ce contexte qu’il commence à proposer des vidéos.

Rapidement, la chaine YouTube gagne des dizaines d’abonnés. Quand le cap des 250 est franchi, Vinceff décide d’ouvrir un serveur Discord pour favoriser les discussions. Il le nomme simplement Gaming Linux FR et les personnes affluent, aussi bien des « sachants » que d’autres, intéressées par le thème et cherchant des réponses à des problèmes pratiques.

Le Discord, créé pendant la crise sanitaire, compte aujourd’hui plus de 3 300 membres. Aucune distribution n’est privilégiée, la thématique étant l’entraide sur le thème général du jeu sur Linux. L’idée est cependant venue d’une distribution qui serait entièrement tournée vers le jeu, en facilitant la prise en main et en donnant immédiatement accès aux outils courants. Le projet a été nommé GLF OS, GLF étant une simple contraction de Gaming Linux FR.

Le système est aujourd’hui le résultat d’un travail d’équipe, comprenant des contributions de plusieurs dizaines de développeurs, le cœur de l’équipe étant constitué d’une petite vingtaine de personnes. Le projet, lui, est codirigé par Vinceff et Cammi.

Un grand nombre de distributions sont basées sur Debian ou Ubuntu. GLF OS a regardé ailleurs : vers NixOS. Cette distribution Linux ne date pas d’hier, puisque le projet de recherche qui lui a donné naissance date de 2003. Le système a même sa propre fondation depuis 2015.

NixOS est avant tout basée sur le gestionnaire de paquets Nix. Tout se fait par une configuration déclarative : on écrit dans un fichier texte ce que l’on souhaite, et le gestionnaire construit le système à partir de ces informations. C’est autant le cas pour l’installation initiale que pour les mises à jour.

Comme nous l’explique Vinceff, cette approche déclarative est couplée à une gestion transactionnelle des configurations. Les mises à jour sont donc atomiques, ce qui signifie – dans les grandes lignes – que les opérations liées créent une nouvelle image du système, sur laquelle l’utilisateur ne bascule réellement qu’au redémarrage suivant, si aucune erreur n’a été détectée. Ce mécanisme permet une fiabilité généralement plus élevée, car l’image utilisée est en lecture seule. L’atomicité a particulièrement le vent en poupe depuis quelques années, notamment chez Fedora.

NixOS propose toujours deux versions par an, en mai et novembre. La numérotation des versions est la même que pour beaucoup de distributions : l’année suivie du mois. La toute fraiche version 25.05 désigne ainsi la version « mai 2025 ». Le système est disponible en deux branches, stable et unstable. Pour ses objectifs, GLF OS compose avec les deux, comme nous le verrons.

L’installation de GLF OS ne réserve aucune surprise. L’environnement par défaut est GNOME, mais l’installateur permet de changer pour KDE. Pour le reste, on est sur la liste habituelle des questions pour cette étape, avec choix du partitionnement, création du temps, sélection du fuseau horaire, etc.

Il y a quand même une étape importante : le choix de l’édition. Par défaut, « Standard » installe la version complète du système pensée pour le jeu vidéo, qui réclame environ 20 Go d’espace libre. Il s’agit d’une suite complète, avec notamment Firefox en navigateur par défaut et LibreOffice pour la bureautique. On peut également choisir une installation minimale, fournie presque sans aucune application. Deux autres éditions sont proposées. La première, Studio, est orientée vers tout ce qui touche à la création graphique. La seconde est une variation intégrant Da Vinci Resolve (une licence est nécessaire).

L’installation (Standard dans notre cas) est un peu plus longue que pour une distribution ordinaire, NixOS ayant besoin d’un peu plus de temps pour construire le système, à partir des scripts propres à GLF OS. Au redémarrage, le bureau est très classique. Bien qu’il s’agisse d’une base GNOME modifiée, notamment pour avoir un dock affiché en permanence (via Dash to Dock), elle ne choquera pas longtemps une personne venant de n’importe quelle autre distribution GNOME.

L’un des éléments peut-être les plus « étranges », c’est l’absence apparente de gestion des mises à jour. Le système s’en occupe en fait seul et envoie simplement une notification pour indiquer qu’une opération est terminée. Dans ce cas, les changements ne seront pas appliqués tant que GLF OS n’aura pas redémarré. Le redémarrage n’est jamais suggéré.

En outre, l’installation d’applications supplémentaires se fait via Flatpak et passe par Easy Flatpak. L’approche générale de GLF OS se veut résolument moderne : un système atomique et des conteneurs logiciels.

GLF OS étant spécialisée dans le jeu vidéo, la distribution contient plusieurs applications dédiées à cet usage. Déjà, les personnes ayant un PC équipé d’un GPU NVIDIA auront la bonne surprise de constater que ce dernier est détecté et que l’installation des pilotes correspondants est automatique.

Côté logithèque, on retrouve bien sûr Wine et Proton, tous deux disponibles dans leur dernière révision. La distribution propose également trois applications cruciales : Steam évidemment, ainsi que Lutris et Heroic. Les deux dernières sont des clients capables de se connecter à des comptes Steam, Ubisoft, EA, Epic, GOG ou encore Amazon. De là, ils permettent l’accès aux jeux en créant un environnement préconfiguré pour permettre leur lancement grâce à Proton.

Dans cet esprit d’une plateforme pensée pour le jeu vidéo, on trouve tout un ensemble de modifications et d’ajouts. Par exemple, la base du système repose sur la branche stable de NixOS (GNOME, KDE, Wayland, Pipewire, pilotes NVIDIA…), mais tout ce qui nécessite des mises à jour régulières s’appuie sur la branche unstable. C’est le cas pour toutes les applications en lien avec le jeu vidéo comme Steam, Heroic Games Launcher, Lutris, Proton, Mesa et autres.

GLF OS apporte en outre ses propres modifications, dont le kernel qui est une version 6.14 modifiée pour régler certains soucis de compatibilité, notamment avec le Ryzen 9800 X3D d’AMD. L’équipe a également intégré des paquets pour étendre le support des volants de jeu (ThrustMaster, Fanatec et Logitech) et des manettes (Xbox, PlayStation, Switch et 8bitdo).

Nous aurons l’occasion de revenir sur le sujet avec une prise en main concrète et un retour d’expérience sur ce qu’est le jeu vidéo sur Linux aujourd’hui. En attendant, la bêta de GLF OS peut être téléchargée depuis son site officiel.

Source : next.ink

En bref :

– Fini de mentir à votre boss : cette barre de progression pour rsync révèle ENFIN où en sont vos transferts de téraoctets.

– Les admins système cachaient ce secret : comment transformer rsync muet en tableau de bord professionnel avec rsyncy.

– Pendant que vous galérez avec rsync aveugle, cette alternative libre affiche vitesse, ETA et progression en temps réel.

Vous venez de lancer un bon gros rsync en prod pour migrer 3 téraoctets de données et votre boss vous sur-saoule toutes les 10 minutes avec des : “Alors, ça en est où ?” en boucle et vous, en bonne victime, vous répondez “Ça avance chef, ça avance…”.

On peut faire mieux non ? Et oui, avec rsyncy qui vous permet au lieu d’avoir un rsync muet qui vous laisse dans le noir, de profiter d’une vraie barre de progression visuelle. Comme ça, vous voyez le pourcentage d’avancement, la vitesse de transfert, le volume copié, le temps écoulé, l’ETA, le nombre de fichiers traités… Bref, toutes les infos pour répondre factuellement à votre hiérarchie et prendre des décisions éclairées de grand professionnel qui aura bientôt une augmentation de salaire ^^.

L’installation est super simple. Vous avez plusieurs options selon votre setup :

– Et une fois installé, vous pouvez soit lancer rsyncy directement avec les mêmes arguments que rsync :

– Soit piper la sortie de votre rsync habituel vers rsyncy :

Ce qui est top, c’est qu’avec ce paramètre, rsyncy ajoute automatiquement les arguments nécessaires pour avoir le maximum d’informations comme ça y’a plus besoin de vous rappeler des bonnes options.

– La barre de progression affichera quelque chose comme ça :

Et là, vous avez tout… la barre visuelle, le pourcentage, les données transférées, la vitesse actuelle, le temps écoulé et le nombre de fichiers traités. C’est clair, net et précis.

– Pour les environnements où les couleurs posent problème (certains logs, scripts automatisés), vous pouvez les désactiver avec :

Pour les devs qui veulent debugger ou enregistrer leurs transferts rsync, l’auteur recommande d’utiliser “ pipevcr ”, un autre de ses outils qui permet d’enregistrer et rejouer des flux de données. Pratique pour tester rsyncy sans lancer de vrais transferts.

Voilà, comme ça avec rsyncy, vous savez exactement où vous en êtes et vous pouvez estimer si vous allez respecter votre fenêtre de maintenance, prévenir si ça va déborder, ou rassurer tout le monde que tout se passe bien.

– Sources : Laurent-Biagiotti-linkedin

https://github.com/laktak/rsyncy

https://korben.info/rsyncy-barre-progression-visuelle-rsync.html

La nouvelle mouture du noyau Linux est sortie ce dimanche 27 juillet. Une version assez attendue, car contenant de nombreuses améliorations pour le matériel, que l’on parle de support ou de performances. On trouve bon nombre d’apports pour Intel, AMD et NVIDIA notamment.

Chez AMD par exemple, avec d’importants changements dans le pilote et sous-système AMD-SBI, avec à la clé une meilleure surveillance de la puissance et de la température. La Secure Encrypted Virtualization (SEV) est enfin supportée, pour renforcer la sécurité des machines virtuelles chiffrées (sur serveurs utilisant des processeurs AMD). Le nouveau noyau identifie en outre plus facilement les plantages et causes de réinitialisation sur l’ensemble des processeurs Zen.

Côté Intel, on trouve aussi des améliorations pour la sécurité des machines virtuelles, avec le support de l’hôte Trust Domain Extensions (TDX) pour KVM pour renforcer l’isolation. La surveillance du matériel est là aussi renforcée, notamment la température, permettant notamment l’apparition de garde-fous pour l’overclocking.

Le noyau 6.16 introduit également une nouvelle option de compilation X86_NATIVE_CPU. Comme son nom l’indique, elle permet aux personnes compilant elles-mêmes leur noyau de forcer une optimisation sur les capacités spécifiques du processeur utilisé. L’option devrait améliorer les performances sur le matériel récent, pour mieux tirer parti des jeux d’instructions.

Côté GPU, la prise en charge des architectures Blackwell et Hopper de NVIDIA a été ajoutée au pilote « Nouveau ». Les puces Intel reçoivent plusieurs améliorations, dont le support de la fonction Link-Off Between Frames (LOBF) pour les ordinateurs portables, pour économiser l’énergie. Outre des correctifs, le pilote Intel Xe sait maintenant indiquer la vitesse des ventilateurs.

Parmi les autres améliorations, on en trouve beaucoup pour le système de fichiers bcachefs, surtout sur les performances. Cependant, comme le notait It’s FOSS News fin juin, l’avenir de ce support dans le noyau est incertain, Linus Torvalds n’ayant pas apprécié les derniers échanges avec le mainteneur principal du projet. Signalons aussi des améliorations de performances pour Btrfs, le support de l’écriture atomique dans XFS ou encore le support d’Intel QAT dans EROFS.

Comme toujours, l’installation de nouveau noyau dépend de la distribution Linux utilisée. Souvent, sur les systèmes dits classiques, le noyau ne change vraiment qu’avec la version majeure suivante. Sur les distributions de type rolling release, comme Arch Linux et openSUSE Tumbleweed, le noyau devrait être très rapidement proposé, si ce n’est déjà fait. Dans tous les cas, il existe des mécanismes pour forcer l’installation d’un nouveau noyau, mais la manipulation n’est pas recommandée, à moins de savoir ce que vous faites.

Source : next.ink

@Psyckofox a dit dans Koske : quand des images de pandas cachent un malware Linux :

@Violence

J’avais mis en place un plan infaillible mais t’es entrain de me griller 😁

https://planete-warez.net/post/99100

Je t’ai vu mettre ça dans le topic des fragiles @Psyckofox 🤣

Si vous avez toujours voulu fouiller le dark web sans y passer 3 heures à chercher dans le noir, j’ai déniché un outil Python qui fait le boulot pour vous : Darkdump.

Créé par Josh Schiavone, Darkdump est une interface OSINT (Open Source Intelligence) qui permet de mener des investigations sur le deep web. En gros, vous tapez un mot-clé, et l’outil va scraper les sites .onion correspondants pour en extraire des emails, des métadonnées, des mots-clés, des images, des liens vers les réseaux sociaux, et j’en passe.

Darkdump utilise Ahmia.fi (un moteur de recherche pour le dark web) pour trouver les sites .onion pertinents, puis il les scrape quand vous êtes connecté via Tor. Bref, c’est Google pour le dark web, en ligne de commande et avec des super-pouvoirs.

– Pour l’installer, rien de plus simple :

Mais attention, avant de vous lancer, il faut configurer Tor correctement. Sur Linux ou Mac, installez Tor (sudo apt install tor ou brew install tor), puis éditez votre fichier /etc/tor/torrc pour ajouter :

Pour générer le hash du mot de passe, utilisez tor --hash-password "mon_mot_de_passe". Ensuite, démarrez le service Tor et vous êtes prêt à explorer les profondeurs du web.

Ce qui est cool avec Darkdump, c’est sa flexibilité. Vous pouvez l’utiliser de plusieurs façons. Voici quelques exemples données dans la doc officielle :

L’outil peut extraire pas mal de trucs intéressants comme des documents (PDF, DOC, XLS, PPT…), des adresses email, des métadonnées, et même des liens vers des profils de réseaux sociaux. C’est super pour les chercheurs en sécurité ou encore les journalistes d’investigation.

Maintenant, parlons un peu d’Ahmia.fi, le moteur qui fait tourner tout ça. Contrairement à ce qu’on pourrait croire, vous n’avez pas besoin de Tor pour accéder à l’interface d’Ahmia… vous pouvez y aller directement depuis votre navigateur normal. Par contre, pour visiter les sites .onion qu’il trouve, là il vous faudra Tor Browser.

Le moteur de recherche Ahmia

Ce qui est bien avec Ahmia, c’est qu’ils filtrent le contenu illégal comme ça c’est pas le far west total. Ils essaient tant bien que mal de garder ça propre et légal.

En 2025, Ahmia reste donc l’un des moteurs de recherche du dark web les plus fiables, aux côtés de Torch, DuckDuckGo (version Tor), Haystak et Not Evil. Chacun a ses spécificités, mais Ahmia reste le préféré pour sa politique de filtrage du contenu illégal.

Bon, évidemment, je dois faire mon speech de prévention et Josh Schiavone lui-même précise : Il n’est pas responsable de l’utilisation que vous faites de son outil. Ne l’utilisez donc pas pour naviguer sur des sites illégaux selon les lois de votre pays. C’est un outil pour la recherche légitime, l’OSINT, la cybersécurité, pas pour faire n’importe quoi.

D’ailleurs, petite anecdote, la v3 de Darkdump a été mise à jour récemment, et apparemment il y a même des forks qui commencent à apparaître avec des mises à jour complètes. La communauté OSINT est active sur ce projet, ce qui est bon signe pour sa pérennité. Voilà, donc pour ceux qui veulent aller plus loin dans l’OSINT sur le dark web, Darkdump n’est qu’un logiciel parmi d’autres et fait partie d’une boîte à outils plus large qui comprend des trucs comme OnionScan, TorBot, ou encore Dark Web OSINT Tools. Mais pour débuter, c’est vraiment l’un des plus simples et des plus efficaces.

Ça ne transformera pas le dark web en votre terrain de jeu, mais au moins vous verrez où vous mettez les pieds. Et dans un monde où l’information est de plus en plus fragmentée et cachée, c’est pratique, mais souvenez-vous, avec un grand pouvoir vient une grande responsabilité donc utilisez-le à bon escient !

– Sources :

https://github.com/josh0xA/darkdump

https://korben.info/darkdump-outil-osint-fouille-dark-web.html

Trois paquets malveillants ont été déposés sur le dépôt communautaire utilisé par Arch Linux : l’Arch User Repository. Ces paquets installaient en réalité le logiciel malveillant Chaos, un Cheval de Troie capable de donner un accès distant à la machine infectée. Faisons le point.

L’Arch User Repository (AUR) est un dépôt de paquets sur lequel les utilisateurs d’Arch Linux peuvent trouver des applications et paquets en tout genre non disponibles dans les dépôts officiels. En effet, il s’agit d’un dépôt communautaire. Cependant, il repose sur la confiance et la vigilance des utilisateurs, car il n’y a pas de réel processus de validation : n’importe qui peut déposer un paquet.

Et, pour preuve, le 16 juillet dernier, un utilisateur avec le pseudo “danikpapas” a mis en ligne trois paquets sur l’AUR : librewolf-fix-bin, firefox-patch-bin et zen-browser-patched-bin. Ces derniers dissimulaient un script d’installation malveillant.

“Le 16 juillet, vers 20 heures UTC+2, un paquet AUR malveillant a été téléchargé sur le site AUR.”, peut-on lire sur le site d’Arch Linux. Ce paquet n’était pas seul, puisqu’il y a eu deux autres paquets chargés par le même utilisateur.

Deux autres paquets malveillants ont été téléchargés par le même utilisateur quelques heures plus tard. Ces paquets installaient un script provenant du même dépôt GitHub qui a été identifié comme un cheval de Troie d’accès à distance (RAT).

La méthode était simple, mais efficace : le fichier de construction PKGBUILD de chaque paquet contenait une instruction pour cloner un dépôt GitHub (par exemple : https[:]//github.com/danikpapas/zenbrowser-patch.git). Ce qui signifie que le système téléchargeait et exécutait le code du malware durant le processus de construction du paquet. L’utilisation de scripts de construction de paquets, appelés PKGBUILD, est tout à fait normal dans le contexte d’Arch Linux.

Le logiciel malveillant Chaos est un RAT, c’est-à-dire un cheval de Troie d’accès à distance (Remote Access Trojan). Une fois installé sur une machine, il se connecte à un serveur C2 (commande et contrôle), ici localisé à l’adresse 130[.]162.225.47:8080, et attend les ordres des cybercriminels !

L’attaquant dispose alors d’un accès distant sur le système compromis: il peut télécharger et envoyer des fichiers, exécuter des commandes arbitraires ou encore ouvrir un reverse shell. Ceci ouvre la porte à des actions malveillantes, comme le vol d’identifiants ou de données.

La bonne nouvelle, c’est que le nettoyage a été fait suite aux signalements de certains utilisateurs qui ont pris la peine d’analyser les paquets sur VirusTotal :

Pour les utilisateurs qui auraient pu installer l’un de ces paquets, vous devez vérifier votre machine. Recherchez la présence d’un exécutable suspect nommé systemd-initd, potentiellement situé dans le dossier /tmp.

– Source :

https://www.it-connect.fr/arch-linux-trois-paquets-aur-malveillants-destines-a-installer-le-malware-chaos-rat/

@Psyckofox :lol:

Vos serveurs web classiques, les censeurs les trouvent en 3 clics. Même avec un VPN foireux, même caché derrière CloudFlare, même en priant très fort, alors imaginez que vous voulez publier un truc sur le web sans que personne ne puisse remonter jusqu’à vous ? Et bien en fait c’est hyper simple avec torserv qui lance automatiquement votre site comme service caché Tor.

Il s’agit d’un serveur web statique durci qui intègre nativement Tor. Pas de base de données MySQL qui traîne, pas de PHP qui fuite, juste vos fichiers HTML, CSS et JavaScript servis proprement. Le truc génial, c’est la configuration zéro. Vous lancez le binaire et hop, votre site devient accessible via une adresse .onion automatiquement générée.

J’ai découvert torserv après avoir passé 2 heures à galérer avec une config manuelle d’Apache + Tor pour un petit projet perso car configurer un service caché à la main, c’est pas de la tarte. Faut éditer torrc, créer les bons répertoires, gérer les permissions, redémarrer les services… Avec torserv, tout ça disparaît. Vous pointez sur votre dossier web et c’est parti.

Et le pire dans tout ça ? C’est que même après avoir fait votre config manuelle parfaite, vous êtes jamais sûr à 100% de pas avoir laissé trainer une faille. Un header Apache qui balance votre version, un module PHP mal configuré, un log qui enregistre les requêtes… Avec torserv, ces soucis n’existent pas. Le code est minimaliste par design.

Pour comprendre l’intérêt, faut savoir comment fonctionnent les services cachés Tor. Contrairement à un site normal où votre serveur a une IP publique visible, un service .onion reste planqué dans le réseau Tor. Les visiteurs passent alors par plusieurs relais chiffrés, et même eux ne connaissent pas votre vraie localisation.

Mais torserv va plus loin.

Il embarque directement le binaire Tor, donc pas besoin d’installer quoi que ce soit sur votre machine. Et le serveur intégré écrit en Go gère tout : il lance Tor en tâche de fond, génère les clés cryptographiques pour votre .onion, et sert vos fichiers avec les bons headers de sécurité. Tout ça dans un seul exécutable de moins de 20 Mo.

Le petit bonus sympa c’est que torserv ajoute du jitter temporel sur les réponses (50-200ms aléatoires) et du padding sur la taille des fichiers. Ça complique sérieusement l’analyse de trafic pour ceux qui voudraient identifier votre site par ses caractéristiques réseau.

Et les cas d’usage sont nombreux. Vous pouvez par exemple héberger des documents sensibles sans passer par un cloud public. Parfait pour le journalisme d’investigation, l’activisme dans certains pays, ou même pour une entreprise qui veut éviter les fuites via des plateformes externes.

– Mais y’a d’autres trucs cools à faire :

Maintenant, si vous voulez tester, vous devez télécharger le binaire depuis GitHub, vous le lancez dans le dossier contenant vos fichiers web, et torserv génère automatiquement votre adresse .onion. En 5 minutes chrono vous avez un site web invisible.

– Concrètement, ça donne ça :

Et boom, vous avez un truc du genre : http://xxxxxxxxxx.onion qui s’affiche dans votre terminal. Copiez-collez dans Tor Browser et voilà.

Ce qui m’a surpris pendant mes tests, c’est la performance. J’avais des aprioris sur la lenteur du réseau Tor, mais pour du contenu statique, ça reste très correct. Évidemment, on est pas sur de l’hébergement classique, mais pour des documents, des pages simples, ça fait le taf. Et puis l’avantage, c’est que votre bande passante n’est pas plombée puisque le trafic transite par les relais Tor.

Et la sécurité intégré à torserv, ce n’est pas que du marketing. Le serveur limite les requêtes, filtre les tentatives d’exploitation, et expose le minimum de surface d’attaque. Bref, contrairement à Apache ou nginx avec leurs 50 000 modules, torserv fait juste ce qu’il doit faire : servir des fichiers statiques de manière sécurisée. Moins de complexité, moins de failles potentielles.

– Voici ce qu’il propose :

Après vous l’aurez compris, c’est du statique uniquement, donc oubliez WordPress, les formulaires dynamiques ou les API. Si vous avez besoin d’interactivité, faudra regarder ailleurs. Et puis, c’est plutôt récent comme projet, donc ça n’a pas encore la maturité d’un Apache.

– Autres trucs chiants :

Comparé aux autres solutions, torserv a ses avantages. OnionShare c’est bien pour du partage ponctuel, mais c’est GUI only et moins flexible et SecureDrop c’est overkill pour la plupart des usages.

Je trouve donc que Torserv trouve le bon équilibre car il est assez simple pour être utilisé par n’importe qui, et assez sécurisé pour tenir la route face aux menaces courantes. Et pour du professionnel avec de gros besoins, partez plutôt sur une infrastructure dédiée mais pour 90% des cas d’usage (partage de docs, mini-site personnel…etc) c’est exactement ce qu’il vous faut.

Attention quand même, l’anonymat total n’existe pas. Même avec Tor et torserv, vos habitudes de rédaction, vos heures de publication, le style de vos contenus peuvent vous trahir. L’OPSEC (operational security) reste crucial. Et évidemment, côté légalité, respectez les lois de votre pays car Tor c’est pas un permis pour tout faire.

Un dernier conseil, si vous êtes vraiment parano (et vous avez peut-être raison), utilisez l’option --new-key qui génère une nouvelle adresse .onion à chaque lancement. Comme ça, même si quelqu’un trouve votre site, il pourra plus y accéder la prochaine fois. C’est radical mais efficace.

– Sources :

https://github.com/torserv/torserv

https://korben.info/torserv-serveur-web-anonyme-tor-zero-config.html

lol vive Windaube 😉