❌

Vue lecture

iKnow - Ce que votre Mac sait de votre famille

Sous macOS, 2 chercheurs nommés Dario Pasquini et Michał Bazyli ont trouvé une variable mystérieuse nommée photosPersonPosteriorProbabilityGivenSaturdayNight qui fait partie des 144 entrées de deux modèles CoreML livrés avec macOS (EntityTagging_Family et EntityTagging_FamilyAndFriends). Ces classificateurs XGBoost indique pour chaque personne la probabilité qu'elle soit de votre famille ou de votre cercle d'amis.

Sur ces 144 variables, 20 portent sur l'identité (même nom, même adresse, membre du Partage familial), 40 sur vos échanges et 84 sur les photos où vous apparaissez ensemble... Le reste étant décliné ensuite par jour, par moment de la journée et par lieu. Et vos échanges avec ces personnes sont transcrits en tant que métadonnées : qui, quand, par quel canal.

Ces scores atterrissent ensuite dans une base à part, entityTagging.db. Dans le dossier ~/Library/IntelligencePlatform, on trouve aussi deux daemons, knowledgeconstructiond et intelligenceplatformd, qui remplissent à eux seuls +50 bases SQLite bien bien stockées en clair .

Dans le graphe lui-même, graph.db, entrent ensuite vos contacts, les visages extraits de l'app Photos, le Calendrier, le Partage familial avec l'âge de chacun des membres, le contact d'urgence de la fiche médicale de Santé, ainsi que les événements et contacts que les suggestions de Siri repèrent dans Mail et Messages. À côté, il y a aussi d'autres petites tables qui conservent un journal des communications (qui, quand, quelle app, dans quel sens, mais sans le contenu) et tous vos déplacements.

Voilà... ça fait beaucoup de données privées collectées par nos appareils Apple qu'on peut maintenant explorer tranquillement grâce à cette méthode d'Alexis Brigoni et un outil que je vous propose d'installer :

Regarder votre propre graphe avec iKnow

Les auteurs du papier de recherche ont publié iKnow , dispo sous licence Apache 2.0 qui est un petit serveur en Python 3, sans dépendance, qui n'écoute que sur 127.0.0.1 et ouvre en lecture seule le graphe, mais aussi Messages, Photos, Calendrier et Contacts.

Pour que ça fonctionne, il faudra que votre terminal ait un accès complet au disque donc pensez bien à l'activer dans les Réglages Système, Confidentialité et sécurité, Accès complet au disque. Ajoutez Terminal (ou iTerm, ou votre éditeur), puis quittez-le complètement et relancez-le, puisque la permission n'est prise en compte qu'au lancement.

Terminal coché dans Accès complet au disque

Relancez ensuite Terminal vous-même et tapez les lignes de commande suivantes :

git clone https://github.com/8rank/iKnow.git
cd iKnow
python3 server.py

Au lancement, le serveur marque ok ou DENY à côté de chaque base. Il affiche ensuite un lien du type http://127.0.0.1:8765/?token=… avec un jeton neuf à chaque lancement. Ouvrez ce lien.

Le serveur démarré : ok partout, sauf Contacts, faute de compte sur cette machine de test

Comme j'étais sur une VM, il n'y avait pas de compte iCloud ni Google configuré, donc il ne m'a pas sorti directement mes contacts, etc. Par contre, j'ai fini par l'installer directement sur ma machine de tous les jours. Là, j'ai bien récupéré les datas.

La page d'accueil d'iKnow, rendue avec des données inventées : aucun nom n'y est réel

Dans la barre latérale d'iKnow, notez qu'il y a un switch qui permet de masquer visuellement les données perso, ce qui m'a permis de faire sereinement mes captures d'écran.

Sur mon ordi, le graphe a été créé initialement le 19 septembre 2024 et compte actuellement 35 953 faits, sur 3 876 entités dont 3 038 personnes et 712 logiciels. La table des scores de parenté indique l'existence de 3 052 personnes et l'outil y compte aussi 214 relations précises sur 27 personnes.

Mon graphe c'est 35 953 faits sur 3 876 entités, dont 78 % de personnes

La table des scores de parenté, avec les noms remplacés par des substituts

La page Who else reads it est peut-être la plus parlante puisque chez moi, 31 vues dérivées sont abonnées à mon graphe personnel. Cela veut dire que d'autres appareils chez moi accèdent à ce graph.

Qui d'autre lit le graphe sur mon Mac : 31 vues abonnées, 9 autres appareils

Apple en sait donc beaucoup plus sur notre identité et nos liens inter-humains que ce qu'on pourrait penser, et iKnow nous permet d'en prendre conscience en nous permettant d'aller fouiller dans tous ces graphs présents sur nos iPhones et nos Mac.

Certes, l'application est un peu complexe parce qu'il y a beaucoup de données, et ce serait rigolo, je trouve, d'en faire quelque chose de beaucoup plus accessible qui finalement listerait un peu qui sont nos VRAIS amis et qui n'est pas notre VRAIE famille puisqu'Apple, apparemment, sait mieux que nous avec qui nous tissons des liens plus ou moins forts.

source

  •  

Revue de presse de l’April pour la semaine 45 de l’année 2026

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

[Next] ECC #14: Faire passer une ville au logiciel libre, avec Nicolas Vivant

✍ Mathilde Saliou, le .

Dans le quatorzième épisode d’Entre la chaise et le clavier, Nicolas Vivant, directeur de la stratégie et de la culture numérique de la ville d’Échirolles, détaille le processus qui a permis de faire passer peu à peu les équipements numériques de la commune d’outils propriétaires vers du logiciel libre, et dans quelle mesure cette évolution infuse jusque dans les interactions avec la population.

[IT SOCIAL] PHP2Shell, une troisième faille touche les versions déjà corrigées

✍ Mourad Krim, le .

Cinq jours après les correctifs de PHP2Shell, la mise à jour ne suffit plus à fermer le risque. Une troisième faille touche les versions corrigées et peut être neutralisée par la configuration, tandis que les mesures de CrowdSec laissent encore à la DSI une fenêtre pour corriger, sans exploitation de masse observée.

  •  

🪶 Les journaux LinuxFr.org les mieux notés d’octobre 2026

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Bannière LinuxFr.org

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du mois d’octobre passé.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Daylight GNU/Linux 5 : un bureau Fluxbox ajouté à Raspberry Pi OS

Daylight GNU/Linux prépare sa version 5, actuellement disponible en version candidate 5.0.0-rc.2. Ce projet libre, développé par Hamdy Abou El Anein en Suisse, propose un environnement Fluxbox et des outils en Rust à installer sur Raspberry Pi OS 64 bits.

L’approche actuelle consiste à conserver le système de base et à lui ajouter des paquets avec APT. Elle se distingue des anciennes images autonomes du projet. Les sources sont disponibles sous licence GPLv3.

Un bureau ou uniquement les outils

L’installation permet de choisir le bureau ou seulement les outils pour une machine sans interface graphique. Le bureau utilise une session X11 séparée, sans remplacer automatiquement la session existante. Le script d’installation propose un mode de planification : sans l’option --yes, il n’installe rien. Il reste recommandé de lire le script et de sauvegarder ses données avant de modifier une installation.

Périmètre de cette version candidate

La cible est Raspberry Pi OS 64 bits compatible avec Debian 12 ou 13, sur architecture ARM64. Le cœur du projet a été exécuté sur Raspberry Pi 4 ; cela ne constitue pas une validation de toutes les cartes, de tous les écrans ou de tous les pilotes. ARM 32 bits n’est pas pris en charge. Cette version candidate ne doit pas être présentée comme une version stable finale.

Une démonstration dans le navigateur

Le site propose aussi une démonstration interactive sans compte. Il s’agit d’un environnement expérimental Alpine Linux/Fluxbox, distinct de l’édition installable sur Raspberry Pi OS. Son démarrage peut prendre quelques minutes et l’expérience vise principalement les ordinateurs. L’image live AMD64 pour PC est également une démonstration, pas une image de carte SD pour Raspberry Pi.

Les retours sur l’installation, la session graphique et la documentation permettront de préciser les limites de compatibilité. Les personnes qui testent peuvent indiquer le modèle de carte, la version du système et les étapes nécessaires pour reproduire un problème dans le dépôt du projet.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Khrys’presso du lundi 9 novembre 2026

Comme chaque lundi, un coup d’œil dans le rétroviseur pour découvrir les informations que vous avez peut-être ratées la semaine dernière.


Tous les liens listés ci-dessous sont a priori accessibles librement. Si ce n’est pas le cas, pensez à activer votre bloqueur de javascript favori ou à passer en “mode lecture” (Firefox) 😉

Brave New World

Spécial IA

Spécial Israël

Spécial femmes dans le monde

  • Unmarried Chinese women are rewriting the marriage script (globalvoices.org)

    Chinese women are challenging marriage pressures and redefining what it means to be single.For years, the word shengnü (剩女), literally translated as “leftover women,” hovered over many of the women whose profiles appeared there.The translation sounds strange in English because the original Chinese carries a sharper meaning. The character sheng (剩) does not simply mean “remaining.” It suggests something left behind, something unused. In everyday contexts, it can describe leftover food — something that has passed its ideal moment and may eventually be discarded.

  • En Afrique du Sud, les hommes sont invités à s’emparer de la question des violences faites aux femmes (rfi.fr)

    L’Afrique du Sud est l’un des pays avec le plus haut taux de féminicides au monde. Récemment, une série de meurtres a fait craindre la présence d’un tueur en série qui visait les femmes. Mais l’enquête patine, et presque aucun de ces meurtres qui a frappé la région de Johannesburg n’’a encore été élucidé.

  • Pourquoi le mont Athos, en Grèce, est-il interdit aux femmes (et aux animaux femelles vertébrés) (slate.fr)
  • États-Unis : motion de défiance contre la direction de l’université Cornell, après des accusations de viols (rfi.fr)

    L’université de Cornell, dans l’État de New York, est toujours dans la tourmente après des accusations de viols en réunion sur une étudiante. Les professeur·es de ce prestigieux établissement états-unien ont voté […] une motion de défiance contre le conseil d’administration. Un vote symbolique mais qui fragilise encore plus la direction de l’université.

  • Midterms 2026 : aux États-Unis, une vague de pionnières emmenée par Deb Haaland (lesnouvellesnews.fr)

    Du Nouveau-Mexique à la Géorgie, des élues accèdent à des fonctions jusque-là jamais occupées par une femme issue de leur communauté. Parmi elles, Deb Haaland, première femme amérindienne élue gouverneure aux États-Unis.La victoire de Deb Haaland au Nouveau-Mexique est l’un des symboles les plus forts de ces élections. En devenant gouverneure du Nouveau-Mexique, cette démocrate de 65 ans est la toute première femme autochtone à prendre la tête d’un État américain.[…]En Géorgie, Keisha Lance Bottoms devient la première femme noire élue gouverneure aux États-Unis. Ancienne maire d’Atlanta, elle remporte une victoire qui met fin à 250 ans d’histoire politique américaine sans femme noire élue à la tête d’un État.[…] Autre percée : l’élection de Peggy Flanagan au Sénat fédéral. Membre de la communauté White Earth Band of Ojibwe et ancienne vice-gouverneure du Minnesota, elle devient la première femme amérindienne à siéger au Sénat des États-Unis.

Spécial France

Spécial femmes en France

Spécial médias et pouvoir

Spécial emmerdeurs irresponsables gérant comme des pieds (et à la néolibérale)

Spécial recul des droits et libertés, violences policières, montée de l’extrême-droite…

Spécial résistances

Spécial outils de résistance

  • AnarBib un logiciel libre de gestion de bibliothèques fait par et pour les bibliothèques anarchistes (anarbib.org)

    Cataloguer un fonds, suivre les emprunts, accueillir des lecteur·rices, coopérer avec d’autres bibliothèques du mouvement : ce sont des gestes simples, qu’aucun outil existant ne respecte vraiment. Les logiciels propriétaires sont chers, surveillent leurs utilisateur·rices et imposent leurs catégories. Les outils libres généralistes sont conçus pour des bibliothèques universitaires ou municipales, pas pour les nôtres.

Spécial MAGAM et cie

Les autres lectures de la semaine

Les BDs/graphiques/photos de la semaine

Les vidéos/podcasts de la semaine

Les trucs chouettes de la semaine

Retrouvez les revues de web précédentes dans la catégorie Libre Veille du Framablog.

Les articles, commentaires et autres images qui composent ces « Khrys’presso » n’engagent que moi (Khrys).

  •  

Écrire à 20 mains en Commun

Le 8 septembre dernier, Framasoft sortait le livre Alternatives et luttes. Cartographier pour coopérer. Issu du projet Des livres en Communs, cet ouvrage a été écrit par un collectif d’auteurs. Dans les lignes qui suivent, nous leur laissons la parole pour témoigner de la collaboration qui a présidé l’écriture des différents chapitres.


Des livres en Communs, est un des nombreux projets de Framasoft. Il accompagne l’écriture de livres en suivant un autre modèle que celui de l’édition classique : des livres sous licence libre, répondant à un appel à projet et dont l’écriture est financée par Framasoft. Quand nous avons lu l’appel 2024 « Artistes, Durabilistes, Solidaristes, Libristes », au sein de Transiscope, ça a fait tilt ! Pour notre collectif, cela faisait sens de raconter 10 ans de coopération entre collectifs et individu·es autour d’un portail cartographique, pour que notre expérience soit compostable par d’autres collectifs militants.

Dans ce billet, nous nous penchons sur l’envers du décor : comment a-t’on écrit un livre à dix claviers ?

Couverture du livre

Au départ, une organisation millimétrée

Tout a commencé par un plan détaillé, qui nous a permis de définir collectivement ce que nous voulions raconter, à grosse maille. Nous avons aussi défini une organisation de la rédaction : une coordination et des binômes ou trinômes de rédacteur·ices par chapitre. La coordination de la rédaction s’est bien vite reposée sur un trio :

  • Florent, coordinateur de Transiscope depuis quatre années et qui avait à la fois une connaissance fine du projet et de ses membres,
  • Florine, enseignante-chercheuse arrivée récemment au sein de Transiscope, qui a apporté hauteur de vue et structuration du propos,
  • Julie, à l’époque facilitatrice d’un groupe de travail dans Transiscope, qui connaissait bien les enjeux politiques autour du numérique et devait coordonner concrètement la rédaction du livre.

Sur la Gare centrale de Transiscope (une plateforme collaborative reposant sur YesWiki), nous avons créé une page qui permettait de suivre le projet et son avancée. Nous avons également beaucoup utilisé notre Framaspace pour travailler de façon collaborative sur les textes.

Tout était bien calé : nous savions à quel public se destinerait ce livre, chacun·e savait ce qu’iels avait à faire ! Julie a donc organisé le travail de chaque groupe de rédacteur·ices, les premiers textes ont été écrits… et ont suscité de la part de notre éditeur Christophe beaucoup de corrections et questions.

Ces premiers textes étaient très différents les uns des autres car parmi les rédacteur·ices, il y avait des habitudes d’écriture hétérogènes. Nous avions dans le groupe de rédacteur·ices des chercheureuses, des militant·es habitué·es à la rédaction d’argumentaire ou de projet, mais aussi des personnes peu à l’aise avec les aspects rédactionnels. Aussi, les premiers textes, qui ont eu une fonction de texte martyre, ont permis de tester comment passer du projet à des textes concrets.

Le besoin et le plaisir d’écrire ensemble

Assez vite, l’organisation initialement prévue a montré ses limites : les rédacteur·ices ont pu se sentir seul·es face à leur clavier et il pouvait nous manquer des éléments factuels pour raconter l’histoire de Transiscope. Heureusement, Transiscope organise deux fois par an deux jours de rencontres, les Transiscothons, à la fois pour les membres de Transiscope et pour les acteur·ices locales. En mars 2025, nous nous sommes retrouvé·es au Transiscothon du Mans et ça a clairement dégrippé le processus d’écriture.

Pendant une journée du Transiscothon, les rédacteur·ices présent·es se sont isolé·es pour écrire. Chacun·e a fait en fonction de ses besoins et a écrit seul·e ou avec d’autres, relu, réécrit en binôme, interviewé une personne pour intégrer ses propos dans le récit… Comme une ruche foisonnante, nous avons avancé ensemble et c’était très satisfaisant.

Le Transiscothon a aussi été un espace où discuter du fond. Il existe par exemple un consensus au sein du collectif comme quoi, « Transiscope, c’est un Commun ». Mais lorsqu’on a demandé à différents membres ce qu’iels mettaient derrière ce terme, les définitions divergeaient. Ainsi, le terme « commun », si important dans Transiscope et collectivement flou, nous a paru intéressant à discuter dans le livre.

Toutes ces discussions et ces bouts de rédaction faits au Mans ont fait bouger le sommaire, puisque un nouvel enchaînement logique commençait à se dessiner. C’était un peu déstabilisant de changer ainsi la structuration définie au départ, mais c’est assez logique que cela bouge avec l’avancée de l’écriture.

À la fin de cette résidence d’écriture improvisée, nous avons décidé de poursuivre ces modalités et de faire des temps synchrones réguliers à distance et une résidence de deux jours à Nantes en juin 2025 dont le but était de finir le texte brut.

La résidence nantaise a été accueillie chez l’un·e d’entre nous. Sur le mur de son salon, nous avons listé avec des post-it tout ce qui était à faire, chapitre par chapitre, et nous nous sommes réparti·es les tâches en fonction des compétences, connaissances et envies de chacun·e. Nous en avons aussi profité pour trancher certains points de désaccord entre nous ou avec notre éditeur. Par exemple, Christophe tiquait régulièrement sur le terme « citoyen » car nous n’avions pas la même définition : nous l’utilisons comme synonyme d’« engagé·e » alors que lui insistait plutôt sur les droits et devoirs liés à la citoyenneté. Nous avons compris le point de vue de Christophe mais avons assumé notre définition, qui correspond par ailleurs à un usage réel et concret.

Cette résidence a été l’occasion aussi de partager des moments conviviaux et sympathiques et de mesurer le chemin parcouru par Transiscope. Et c’était vraiment chouette.

Tenir sur la longueur

Alors que nous nous disions que le plus gros était fait (l’écriture) à l’issue de la résidence de juin 2025, il restait en fait énormément de travail pour que cet agrégat de textes devienne un livre.

Tout d’abord, il nous a fallu, sous le regard de Christophe, retravailler les différents textes : les réorganiser, couper, expliciter, éviter les redites… Et surtout relire, relire et relire encore.

Il nous a fallu aussi finaliser la bibliographie, trouver une préfacière, un postfacier, rédiger une introduction… Tous ces petits trucs qui prennent du temps.

Nos implications individuelles ont bougé en fonction des vies des un·es et des autres : retraite, reconversion, nouvel emploi, éloignement du militantisme… C’est assez représentatif de la dynamique de Transiscope, où malgré la vie qui bouge, on essaye de trouver ensemble comment collectivement continuer à avancer. Par exemple Julie, qui avait repris ses études, avait moins de disponibilité et elle a exprimé le souhait de continuer à participer à la création du livre, mais en s’enlevant la charge mentale d’être l’interlocutrice de Framasoft.

Florent a alors pris le relais et nous avons continué à travailler tous·les trois. Cette période a été difficile pour certain·es d’entre nous : le projet semblait encore loin d’être fini alors que nous avions plein d’autres choses à faire, nous étions fatigué·es… Heureusement que nous étions trois à nous soutenir, nous répartir la charge et à nous relayer. Nous avons réussi à garder suffisamment d’énergie collective pour donner un gros coup de collier pour que le projet se termine.

Et savoir s’arrêter

Quand nous avons eu le premier fichier complet (ou presque) à relire, nous y avons vu plein de défauts. Alors que Christophe nous avait demandé de ne plus intervenir sur le fond, nous n’avons pas pu nous en empêcher pour l’améliorer… Mais nous nous sommes fait taper sur les doigts, à juste titre : à un moment, il faut décider d’une version finale, même imparfaite.

Nous n’avons certainement pas tout raconté. Il a fallu faire des choix et nous avons sûrement des angles morts. Pour autant, le contenu du livre nous parait juste, nous espérons qu’il sera également utile.

Nous avons manqué d’énergie pour avoir un ton complètement unifié sur l’ensemble du livre. Même si nous avons réussi à lisser par la réécriture certains textes, on sent à la lecture plusieurs voix différentes… Et en même temps, ça correspond bien à Transiscope et aux modalités d’écriture !

Enfin, nous nous sommes beaucoup questionné·es sur les points de vue et nous sommes permis·es dans le livre quelques encarts au « je » quand ils ne nous semblaient pas représenter un point de vue collectif. Il aurait été intéressant de faire discuter plus des points de vue divergents, mais là encore, il aurait fallu plus de temps.

Rétrospectivement, nous sommes fier·es du parcours effectué et du livre qui vient de sortir. Cela n’arrive pas si souvent de prendre du temps pour se raconter ! Merci à Framasoft et à Christophe pour Des Livres en Communs, à tous·tes les personnes ayant participé à la création de ce livre et surtout à nos lecteur·ices !

— Le collectif Transiscope

  •  

War.app - Le jeu de conquête où personne n'attend son tour

Bon, c'est vendredi aujourd'hui et vous êtes payé la misère alors on va trop forcer hein et se détendre un peu ! (et allez demander à votre boss une augmentation DE CE PAS !!)

Et pour cela, on va tous se mettre sur War.app , un jeu de conquête au tour par tour, gratuit, auquel on peut jouer directement depuis le navigateur (ou sur Android et iOS). Dans ce jeu, vous déployez des armées sur une carte du monde et vous grignotez petit à petit les territoires de vos adversaires, un peu comme dans le jeu Risk.

D'ailleurs, vous avez peut-être déjà croisé ce jeu avant sous le nom de Warzone...

Ce changement de nom fait suite en fait, à un accord avec Activision, l'éditeur de Call of Duty: Warzone , qui avait déposé ses marques WARZONE en 2020 alors que le jeu existait depuis novembre 2017 mais bon... David, Goliath, l'INPI... vous connaissez. Côté joueurs toutefois, rien d'autre ne change, assure Fizzer, le créateur, qui code son jeu tout seul comme un chef ! Le système de compte pour conserver votre progression et vos parties en cours n'a d'ailleurs pas bougé donc vous devrez tout retrouver.

Par contre, si vous aviez warzone.com dans vos favoris, pensez bien à le remplacer, même si l'adresse redirige encore vers war.app.

Maintenant, une partie, ça ressemble à ça : une carte du monde, un nombre d'armées sur chaque territoire, et tout le monde donne ses ordres en même temps. Du coup, personne ne poireaute pendant que les autres jouent, et comme les parties sont asynchrones, chacun joue son tour quand ça l'arrange.

Une partie solo contre l'ordinateur, au tour 2, avec 5 armées à déployer

Et surtout, il n'y a pas de dés. Hé oui, par défaut, chaque armée qui attaque en tue 0,6 en face, donc le résultat d'un combat se calcule à l'avance. Sur la capture, 5 armées parties d'Islande en tuent 3, de quoi balayer les 2 qui gardent le Groenland. Le créateur d'une partie peut quand même réactiver le hasard s'il y tient.

La fenêtre d'attaque : 5 armées d'Islande vers le Groenland, et "Kills 3" affiché sous le curseur

En solo, vous avez accès à des milliers de niveaux contre l'ordinateur, dont ceux créés par la communauté. Et en multijoueur, une même partie peut réunir jusqu'à 400 joueurs, sur des cartes qui dépassent large les 3 000 territoires.

Bref, ya de quoi vous occuper ce vendredi mais aussi ce week-end mais aussi pendant votre chômage puisque j'imagine que votre boss vient de vous virer pour avoir osé lui demander une augmentation. Désoléééé.

Après, gratuit, ça veut dire AVEC de la pub. Je sais que vous adorez ça !! loool L'abonnement qui la retire c'est 3,99 $ par mois ou 19,99 $ par an donc c'est pas très cher et ça débloque surtout l'usage illimité de l'appli native pour Windows, Mac et Linux. Mais Fizzer assure que ça ne rend pas plus fort dans le jeu, puisqu'il ne vend ni armées ni cartes. Seul vrai bémol pour moi c'est que l'App Store ne propose pour le moment le jeu qu'en anglais (et ici sur Korben.info je suis en multilingue maintenant, vous le saviez ??).

Bref, c'est à essayer directement sur war.app en commençant évidemment par une partie solo pour prendre le coup de main et après, peut-être qu'on ira tous en multi se foutre sur la gueule entre lecteurs de korben.info ! Allez savoir ?

Source : War.app

  •  

Comment activer XeSS et sa génération de frames en x4 dans vos jeux 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

  •  
❌