Autoblog de korben.info

- Contient des liens affiliés Amazon -

Alors ça n'est pas le premier test de câble avec écran que je vous propose, j'ai déjà testé des modèles "no name" plus ou moins efficaces.

Depuis trois semaines, un nouveau câble USB-C me dit exactement combien de watts avalent mon MacBook, ma liseuse ou la manette de la console, et cette fois c'est un peu plu ssérieux, puisque ça vient de la marque réputée UGREEN qu'on vous teste régulièrement par ici. Le UGREEN loge donc un minuscule écran LCD directement dans le connecteur, et cet écran affiche la puissance qui circule pour de vrai, pas celle que promet le chargeur.

Trois semaines après son acquisition, je regarde encore les chiffres défiler, et c'est bien pratique.

Ce qui est intéressant, c'est qu'on découvre très vite que la moitié des chargeurs, souvent des "no name" là aussi, de la maison, racontent n'importe quoi. Le bloc qui traîne sur la table de nuit depuis des années sort péniblement ses 10 W quand le téléphone en accepterait le double, et le port USB du moniteur du bureau, lui, n'alimente presque rien. J'ai mis deux chargeurs à la poubelle dès la première semaine, en toute connaissance de cause cette fois.

UGREEN annonce 240 W au maximum, soit le plafond de la norme USB Power Delivery 3.1 avec ses 48 volts sous 5 ampères, une puissance qu'aucun de mes appareils n'approche puisqu'un MacBook Pro 16 pouces réclame 140 W dans le pire des cas. La puce E-Mark cachée dans le connecteur négocie de toute façon la tension avec l'appareil avant de laisser passer quoi que ce soit, donc aucun risque de griller votre téléphone avec cette réserve de puissance.

La gaine en nylon tressé et les connecteurs en aluminium ont passé trois semaines dans mon sac sans marquer, et le câble s'emmêle assez peu, ce qui relève du petit miracle dans mon bordel.

Ce câble ne transporte que du courant, il ne vous servira donc pas pour la data, il faut le savoir. Mais si vous le brancher à votre bloc chargeur, il fera parfaitement son job, et c'est ce qu'on lui demande.

Avant de commander, regardez aussi bien la longueur, parce qu'il existe en plusieurs tailles. UGREEN vend du 1 mètre autour de 13 euros , du 2 mètres vers 15 euros, la version testée ici, et du 3 mètres qui rend service à ceux qui rechargent depuis le canapé, plus des lots de deux câbles pour équiper bureau et maison d'un coup, pour 20 euros à peu près .

Voilà, c'est clairement très pratique, je vous recommander d'en garder un branché quelque part dans votre boîte à câbles !

C'est dispo par ici sur Amazon, en promo et dans plein de tailles !

En février, je vous ai présenté Reticulum , une pile réseau chiffrée de Mark Qvist qui n'a besoin ni de TCP/IP ni d'Internet. Et cette fois, on va aller un peu plus loin en passant à la pratique avec NomadNet, un programme du même auteur qui permet de servir des pages et des fichiers par-dessus Reticulum.

À la fin de ce tuto, vous aurez alors une page d'accueil et quelques fichiers à télécharger, diffusés par votre propre nœud.

Pour ce tuto, je me suis aidé de VMs et de la doc que vous pouvez consulter ici .

Installer NomadNet

NomadNet est tout simplement un paquet Python qui va chercher Reticulum pour l'installer. Il suffit d'invoquer pip comme ceci :

pip install nomadnet

Sur les Debian et Ubuntu récentes, qui bloquent pip, vous pouvez utiliser pipx à la place comme ceci :

pipx install nomadnet
pipx install rns

Et voilà, vous devriez normalement vous retrouver avec NomadNet 1.5.0 et rns 1.6.0.

NomadNet 1.5.0 installé par pipx

Le paquet rns apporte rnstatus et les autres utilitaires de Reticulum 1.6.0

Le second paquet n'est pas obligatoire certes, mais il apporte des utilitaires de Reticulum plutôt cools et pratiques comme rnstatus, qui affiche l'état de vos interfaces.

Lancez ensuite nomadnet une première fois. Le programme s'ouvrira alors sur son guide, dans le terminal, et créera au passage 2 fichiers de configuration : ~/.reticulum/config pour la pile réseau et ~/.nomadnetwork/config pour NomadNet.

Le premier lancement, sur le guide

Ce guide recommande un terminal d'au moins 135 colonnes sur 32 lignes, donc agrandissez un peu la fenêtre si vous voyez que c'est moche et si vous voyez des petits carrés à la place des lettres de l'alphabet, c'est que vous devez installer les Nerd Fonts . Ou vous en passer en changer dans la section [textui] dans le fichier ~/.nomadnetwork/config, le paramètre glyphs = nerdfont par :

glyphs = unicode

Relancez ensuite NomadNet pour que le changement prenne effet.

Côté réseau, la config par défaut n'active qu'une seule interface : l'AutoInterface. Elle permet de découvrir les autres nœuds Reticulum par IPv6 en lien local et transporte les paquets en UDP, sans routeur ni DHCP. Mais elle ne parle qu'aux pairs Reticulum de votre réseau local. Donc si un pare-feu tourne sur la machine et bloque ce trafic, faudra lui ouvrir les ports UDP 29716 et 42671, sinon personne ne vous trouvera et ça c'est triste... snif.

Entre mes deux machines virtuelles, ça a marché sans toucher à rien, puisque le pare-feu ufw est désactivé par défaut dans Ubuntu.

Activer le nœud

Par défaut, NomadNet est un simple client de messagerie. Pour qu'il serve des pages web, ouvrez ~/.nomadnetwork/config, cherchez la section [node] et passez enable_node à yes.

[node]
enable_node = yes
node_name = Mon site
disable_propagation = yes

Le node_name est le nom que votre nœud diffuse à tout le réseau donc je compte sur vous pour choisir un truc cool. Quant à disable_propagation, il sert à faire un nœud qui ne sert que des pages, sans stocker ni relayer les messages chiffrés des autres utilisateurs. En version 1.5.0 c'est déjà le réglage par défaut, donc pas de stress. Relancez ensuite NomadNet, ou faites-le tourner sans interface avec la commande : nomadnet --daemon.

La section [node] de la config, nœud activé

Chez moi, une fois le nœud activé, un onglet My Node est alors apparu dans l'interface, avec l'explorateur des pages et des fichiers, ainsi qu'un éditeur de langage micron (j'y viens après) et un aperçu en direct, soit de quoi se passer de nano.

Sans Nerd Font, des carrés remplacent les icônes de l'onglet My Node

La page provisoire d'un nœud encore vide et la fenêtre de saisie d'adresse, dans une version antérieure de NomadNet

Écrire la page et poser les fichiers

Tant que vous n'avez rien déposé, le nœud sert une page d'accueil générée automatiquement. Comme je vous le disais, les pages s'écrivent en micron, un petit langage de balisage de NomadNet, et vont dans ~/.nomadnetwork/storage/pages. Créez donc d'abord un fichier index.mu, puisque c'est la page servie par défaut à quiconque se connectera à votre noeud.

Les fichiers à partager vont ensuite dans le dossier ~/.nomadnetwork/storage/files, et pour qu'un visiteur puisse en télécharger un, il faudra un lien vers ce même fichier dans une de vos pages.

Voici une page minimale, assemblée à partir des exemples du guide :

>Bienvenue sur mon nœud
Quelques fichiers à récupérer :

`[Le PDF du jour`:/file/document.pdf]

La page index.mu et le PDF posés dans le stockage du nœud

À l'essai, ce lien fonctionne, mais il s'affiche chez le visiteur du texte ordinaire tout moche, alors pour qu'il ressorte un peu mieux, je vous invite à l'entourer d'une couleur et d'un petit soulignement avec ces codes : F79d` et _ pour ouvrir, ``_ et ``f` pour refermer :

`F79d`_`[Le PDF du jour`:/file/document.pdf]`_`f

Notre page vue depuis la seconde machine : le lien ne se distingue pas du texte ordinaire

Avec ses balises de couleur, le lien sort en bleu souligné

L'éditeur micron de l'onglet My Node et son aperçu en direct

L'adresse :/file/document.pdf pointe donc vers un fichier local, posé dans storage/files mais attention par contre, NomadNet ne dressera la liste de ces deux dossiers qu'au démarrage, puisque page_refresh_interval et file_refresh_interval sont à 0 par défaut. Donc après chaque ajout, soit vous redémarrez votre noeud, soit vous donnez à ces deux réglages un intervalle en minutes pour que ça s'auto-refresh tous les X.

Ainsi, une page déjà existante que l'on modifie s'affichera aussitôt chez le visiteur dans sa nouvelle version pour peu qu'il refresh, par contre, une page ajoutée par la suite sera en "Request failed" tant que le nœud n'a pas redémarré.

L'adresse complète d'une page se compose donc d'un hash de destination du nœud, qui fait 32 caractères hexadécimaux, suivi de :/page/index.mu. Dans l'onglet Network de NomadNet, Ctrl+U ouvre la boîte de saisie d'URL, et le programme se charge de trouver le nœud et de s'y connecter. Depuis une autre machine du même réseau local, c'est là aussi que votre page devrait s'afficher.

Notre nœud "Mon site" dans le flux d'annonces du voisin

Maintenant le plus simple pour la trouver, c'est encore de passer par le flux d'annonces de l'onglet Network, où votre nœud apparaît sous son nom, puis de cliquer dessus et de choisir Connect. Et si vous passez par Ctrl+U, chez moi la boîte de dialogue est arrivée préremplie avec l'adresse de la page en cours, qu'il a donc fallu effacer avant de taper la mienne, avec l'adresse du nœud lue sur sa fiche, à la ligne Addr.

La boîte de saisie d'URL avec l'adresse complète de la page

Reste le téléchargement, et là, sur mon Ubuntu en français, ça a coincé car NomadNet enregistre par défaut dans ~/Downloads, un dossier qui n'existe pas chez moi puisqu'il s'appelle Téléchargements. Et donc chez moi le transfert est resté figé sur "Receiving response 100%", sans un message à l'écran. L'erreur n'apparaissait que dans ~/.nomadnetwork/logfile. Donc si ce dossier n'existe pas chez vous non plus, corrigez ça sur la machine du visiteur, à la ligne downloads_path de la section [client] de ~/.nomadnetwork/config :

downloads_path = ~/Téléchargements

Le dossier de téléchargement corrigé dans la config de NomadNet

Chez moi, après un redémarrage de NomadNet, le PDF est arrivé ensuite en une fraction de seconde, avec une empreinte SHA-256 identique à celle de l'original.

Le PDF enregistré, 13,12 Ko, identique à l'original

Le forum rns.recipes ouvert dans le navigateur intégré de NomadNet, son adresse de page en haut

Sortir du réseau local

Maintenant pour être joignable depuis l'extérieur, il faut en général ajouter une interface dans ~/.reticulum/config, sous [interfaces], à moins qu'un autre système de votre réseau local, configuré en passerelle, ne le fasse déjà pour vous. Pour passer par Internet, la forme que donne la doc est celle-ci, où target_host et target_port sont ceux d'un point d'entrée que vous aurez choisi :

[[TCP Client Interface]]
 type = TCPClientInterface
 enabled = yes
 target_host = 127.0.0.1
 target_port = 4242

Le projet ne fournit plus d'adresse toute faite, puisque son testnet public a été fermé donc la doc renvoie vers deux annuaires communautaires, directory.rns.recipes et rmap.world, et conseille de mettre en place plusieurs connexions plutôt qu'une seule. Sachez aussi que si Reticulum chiffre ses échanges par défaut, TCP lui ne chiffre rien. Cela veut dire que l'adresse IP des deux bouts est visible pour qui inspecte la connexion, et il peut aussi en déduire que vous faites tourner Reticulum. Donc si vous voulez masquer réellement ces adresses, faudra mettre en place une interface I2P au prix d'un démon i2pd à faire tourner à côté (une fois encore tout est dans la doc).

Dans l'annuaire directory.rns.recipes on a 71 points d'entrée TCP, dont 40 sont actuellement en ligne, chacun avec pour chacun son bloc de configuration prêt à copier. J'ai ajouté RMAP et SWISS RNS sur la machine du visiteur, relancé NomadNet, et une minute plus tard, une dizaine de nœuds figuraient déjà dans la liste, le mien compris :

[[RMAP]]
 type = TCPClientInterface
 enabled = yes
 target_host = rmap.world
 target_port = 4242

[[SWISS RNS]]
 type = TCPClientInterface
 enabled = yes
 target_host = swiss-rns.cl0ud.ch
 target_port = 4242

Dix nœuds listés une minute après l'ajout des deux points d'entrée, le mien compris, les noms des autres étant floutés

rnstatus avec l'AutoInterface et les deux interfaces TCP actives

Je n'ai fait ce test que dans ce sens, le visiteur voit des nœuds d'Internet, mais je n'ai pas vérifié qu'un inconnu pouvait atteindre notre nœud, puisque seule la machine du visiteur avait ces deux interfaces.

Ce que votre nœud montre

Une fois en ligne, le nœud s'annonce au démarrage puis toutes les 360 minutes, et cette annonce diffuse son nom en clair. Et d'après le code de NomadNet (Node.py), le nœud réutilise l'identité principale du programme, celle qui sert aussi à votre messagerie, donc n'importe qui peut relier votre site à votre adresse de messagerie.

Et ça se voit, puisque chez le visiteur, la fiche de votre nœud affiche une ligne Oprtr qui n'est autre que votre adresse de messagerie LXMF , en clair.

La fiche du nœud chez le visiteur, avec l'adresse de messagerie de l'opérateur en face d'Oprtr

Les pages et fichiers que vous déposez sont publics, sauf si vous posez à côté un fichier du même nom suivi de .allowed, qui liste les identités autorisées. Et surtout, hors Windows, un fichier exécutable placé dans pages est lancé comme un programme quand un visiteur autorisé le demande, puisque c'est comme ça que NomadNet génère ses pages dynamiques. Donc vérifiez les droits de ce que vous y copiez.

Reste la question de la maturité car pour le moment Reticulum n'a fait l'objet d'aucun audit de sécurité externe, NomadNet est en bêta, y'a eu quelques failles de sécu corrigées depuis et les dépôts GitHub ne sont plus que des miroirs figés.

Ajoutez à ça la licence maison, la Reticulum License, qui interdit tout usage dans un système conçu pour nuire aux humains et toute utilisation dans la création d'une IA ou de ses données d'entraînement. Bref, les défenseurs d'Omarchy repasseront , loool. Voilà, donc pour un petit site entre voisins ou entre amis, c'est jouable mais pour quelque chose de sensible, je vous conseille d'attendre un audit et surtout de bien lire la doc.

Source : NomadNet sur GitHub

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

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

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

Quelle Xubuntu ?

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

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

Préparer le terrain

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

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

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

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

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

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

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

Lancer l'installeur

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

python3 installer.py

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

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

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

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

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

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

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

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

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

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

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

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

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

Fermez ensuite votre session et rouvrez-la.

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

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

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

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

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

Notre Xubuntu 26.04 en Windows 95, menu Start ouvert

Finir à la main

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Revenir en arrière

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

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

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

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

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

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

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

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

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

Youpi !

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

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

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

Source : GitHub

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

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

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

Je ne sais pas si vous connaissez David Catuhe, mais c'est le créateur de Babylon.js, un moteur de rendu 3D pour le Web qu'il pilote depuis chez Microsoft, et accessoirement une vieille connaissance. Ça faisait un bail qu'on ne s'était pas parlé alors quand il m'a écrit pour me présenter son jeu, avec en bonus une clé pour tester la version complète encore en bêta, j'ai sauté dessus. Donc voilà, vous êtes prévenus, c'est le test d'un copain... mais un test qui je l'espère sera honnête.

Ce jeu, c'est CottageCore , un jeu de construction cosy où vous construisez librement votre village dans une clairière avant de pouvoir ensuite le regarder prendre vie. Les villageoises s'installent, vous leur choisissez un métier parmi une quinzaine, les animaux y vivent leur meilleure vie et les saisons défilent jusqu'à l'hiver. Ça se joue en mode Créatif, sans aucune limite, ou en mode "Dieu de la clairière", où cette fois accueillir du monde coûte du mana.