Une mise à jour récente du noyau Linux a cassé le support de certains adaptateurs Bluetooth MediaTek, ceux qui sont intégrés aux puces Wi-Fi qu'on trouve sur beaucoup de cartes mères modernes.

Le résultat : votre clavier sans fil, votre souris ou votre casque Bluetooth ne se connectent plus après la mise à jour. Pour les utilisateurs Linux, c'est le genre de régression franchement pénible, pour rester poli.

Al Williams raconte sur Hackaday avoir traqué le problème jusqu'à un fichier précis du noyau : btmtk.c, le pilote qui gère les puces Bluetooth MediaTek. Deux lignes de code suffisent à contourner le problème. Sa rustine consiste à remplacer une fonction de gestion d'erreur par une instruction qui marque la sortie comme "non terminée" et continue. C'est pas génial sur le papier, mais ça fait remarcher le matériel le temps qu'un correctif officiel arrive en amont.

Le problème, c'est que ce n'est pas un simple paramètre à changer. Il faut récupérer les sources du noyau, installer la boîte à outils de compilation, patcher la ligne concernée, recompiler juste le module problématique, l'installer dans /lib/modules, et rebooter.

Deux lignes. Pour un développeur Linux, c'est la routine. Pour un utilisateur lambda qui a juste envie que sa souris remarche, c'est franchement relou.

Al teste sa rustine sur OpenSUSE Tumbleweed (une distribution Linux à mises à jour continues), mais la procédure marche aussi sur Debian, Ubuntu et la plupart des autres distros, avec quelques ajustements de chemins. Il insiste : c'est temporaire. Le bug est connu des développeurs du noyau, et le correctif définitif devrait remonter dans les prochaines versions stables.

Le truc un peu naze, c'est que Bluetooth sur Linux a longtemps eu la réputation d'être un cauchemar. La situation s'était nettement améliorée ces dernières années avec BlueZ (la pile Bluetooth officielle de Linux) et le support natif dans la plupart des distros. Voir une régression d'envergure refaire surface en 2026 sur du matériel grand public, ça refait grincer des dents les vieux Linuxiens qui pensaient avoir refermé ce chapitre.

Et puis ça illustre bien le modèle de développement du noyau. Les régressions arrivent parce que le code évolue très vite et que tout le matériel ne peut pas être testé en permanence. Quand ça pète, la communauté patche. Quand le patch est validé, il remonte. C'est lent, mais ça finit toujours par marcher. Le truc, c'est qu'entre les deux, vous restez avec votre clavier Bluetooth en rade .

Si vous êtes touché par le problème, l'article complet d'Al Williams sur Hackaday donne toutes les commandes pas à pas . Le fix est documenté ligne par ligne, ça prend une trentaine de minutes pour quelqu'un qui est très à l'aise avec un terminal.

Source : Hackaday

Si vous venez d'acheter un portable HP équipé d'un Intel Core Ultra Series 3 (nom de code Panther Lake) et que vous y faites tourner Linux, vous allez accueillir cette nouvelle avec une certaine satisfaction. Intel et HP ont enfin poussé le firmware nécessaire à l'activation du fameux Integrated Sensor Hub dans linux-firmware.git, le dépôt officiel utilisé par à peu près toutes les distributions Linux du marché.

Petite mise en contexte quand même... Vous le savez, le firmware, c'est le tout petit logiciel bas niveau qui permet à un composant matériel de fonctionner. Et l'Integrated Sensor Hub (l'ISH pour les intimes), c'est un co-processeur intégré dans les puces Intel récentes.

Son job est de gérer les capteurs du laptop (orientation de l'écran, accéléromètre, gyroscope, capteurs de lumière, etc.) sans déranger les gros cœurs du CPU principal. Ça permet en fait à la machine de capter ce qu'il se passe autour d'elle même quand elle est en veille, sans vider la batterie.

Le problème, c'est que ce petit co-processeur a besoin d'un firmware spécifique pour fonctionner. Et sans ce firmware, l'ISH était muet sur Linux. Résultat : des fonctions comme la rotation automatique de l'écran sur un PC convertible, l'allumage à la détection de présence ou les économies d'énergie liées aux capteurs ne fonctionnent tout simplement pas, ou alors franchement mal.

Le pilote était déjà dans le noyau Linux depuis longtemps. C'est la pièce manquante, le firmware lui-même, qui était à la bourre. Sans lui, il faut bidouiller, copier des fichiers à la main depuis Windows, ou faire une croix sur certaines fonctions. C'est le genre de situation qui fait fuir les utilisateurs vers Windows ou macOS sur du matos neuf.

De la part d'HP, c'est plutôt un bon rattrapage. Le constructeur historique pousse régulièrement des laptops pré-installés avec Linux à destination des développeurs et des entreprises (la gamme ZBook sous Ubuntu, par exemple, qui existe depuis quelques années). Avoir un bon support dès la sortie du carton, ça compte vraiment pour ce public-là, qui ne veut pas passer une heure à chasser les firmwares disparus pour faire marcher son trackpad ou son lecteur d'empreintes.

Intel, de son côté, a fait pas mal d'efforts ces derniers temps pour simplifier sa licence de firmware et accélérer la mise à dispo de ces fichiers binaires pour Linux. On a d'ailleurs vu la même histoire avec le firmware NPU (la puce dédiée à l'intelligence artificielle) qui a été publié juste avant pour Panther Lake.

Bref, pour qui voulait passer à un laptop HP Panther Lake sous Linux dès maintenant, le timing est devenu nettement meilleur.

Source : Phoronix

C'est la Software Freedom Conservancy (SFC), l'ONG américaine qui défend les licences libres, qui a sorti l'affaire. Bambu Lab, l'un des plus gros fabricants d'imprimantes 3D grand public du moment, viole l'AGPLv3 depuis environ quatre ans selon l'organisation. Pas qu'un peu donc.

Pour comprendre l'histoire, il faut savoir que Bambu Studio, le slicer maison de la marque (c'est le logiciel qui transforme un modèle 3D en instructions de découpage pour l'imprimante), est en réalité un dérivé de PrusaSlicer, lui-même basé sur Slic3r.

Les deux sont sous licence AGPLv3, ce qui oblige toute boîte qui distribue un logiciel dérivé à publier son code source dans la même licence. Du coup, Bambu Studio aurait dû suivre les mêmes règles depuis le début.

Sauf que voilà, le SFC pointe deux violations très claires. D'abord, une bibliothèque maison appelée libbambu_networking, qui gère toute la communication entre le slicer et les serveurs cloud de Bambu, n'a jamais vu son code publié. La marque reconnaît même son existence dans son propre README sur GitHub. Pire encore, quand le développeur Paweł Jarczak a sorti une version modifiée d'OrcaSlicer (un fork concurrent, c'est-à-dire une copie communautaire améliorée) qui restaurait certaines fonctions cloud bloquées par Bambu, l'entreprise lui a envoyé une mise en demeure pour faire retirer son projet.

C'est la deuxième violation selon le SFC, parce que l'AGPLv3 interdit explicitement d'ajouter des restrictions supplémentaires à ce que la licence autorise. En clair, Bambu n'a pas le droit d'invoquer ses conditions d'utilisation pour empêcher quelqu'un d'exercer les droits que la licence donne. 

Côté riposte, le SFC a lancé un projet baptisé baltobu. Trois objectifs : refaire la fameuse bibliothèque à partir de zéro par reverse-engineering (démonter le code propriétaire pour le réécrire proprement), maintenir le fork OrcaSlicer de Jarczak, et créer un remplaçant complet de Bambu Studio. Une levée de fonds visant 250 007 dollars, ouverte jusqu'au 17 juillet, a déjà atteint son premier objectif pour financer des employés à ce travail sur le long terme. Si la cagnotte va au bout, de nouveaux employés pourront rejoindre le projet.

Bambu Lab a réagi du bout des lèvres. L'entreprise a publié un message reconnaissant que sa référence à des conditions d'utilisation et à une potentielle mise en demeure ait pu être perçue comme une menace légale, ce qu'elle regrette. Pas de modification réelle de la pratique pour autant. La bibliothèque reste fermée, et les pratiques cloud restent les mêmes.

Bref, une marque grand public qui surfe sur les briques open source sans en respecter les règles, ça finit toujours par se voir.

Source : Itsfoss

Nos confrères de chez Phoronix ont publié un comparatif des performances du tout nouveau Ryzen 9 9950X3D2 d'AMD sous deux systèmes : Windows 11 et Ubuntu 26.04 LTS. Le verdict est sans appel, Linux prend une avance très nette sur Windows sur la majorité des charges de travail testées.

Petit point pour ceux qui décrochent dès qu'on parle de processeur. Le 9950X3D2, c'est une variante Dual Edition du processeur haut de gamme d'AMD pour le grand public. Elle embarque 16 cœurs, 32 threads, et surtout une particularité plutôt rare : une mémoire cache 3D (le V-Cache, une couche de mémoire ultra-rapide empilée physiquement sur la puce) présente sur les deux blocs de cœurs, là où les versions précédentes n'en avaient que sur un seul.

En pratique, les deux moitiés du processeur peuvent piocher dans une grosse réserve de mémoire rapide, ce qui accélère pas mal de calculs gourmands.

Phoronix a fait tourner ses batteries de benchmarks habituelles : compilation de code, encodage vidéo, calcul scientifique, rendu 3D, base de données. Sur la majorité de ces tests, Ubuntu 26.04 arrive devant Windows 11, parfois de quelques pourcents, parfois beaucoup plus selon la charge. Quand on additionne tout, ça donne une moyenne nettement à l'avantage du pingouin.

C'est un constat qui revient quasi à chaque test du genre depuis plusieurs années. Linux fait souvent mieux tourner les processeurs serveur ou les CPU multi-cœurs musclés que Windows, notamment parce que son ordonnanceur (le bout du système qui décide quel programme tourne sur quel cœur et à quel moment) est plus malin avec les architectures complexes.

AMD, avec son design en deux blocs séparés et son cache 3D asymétrique, est typiquement le genre de processeur où ça compte vraiment.

Côté Windows, c'est un peu toujours la même histoire. Microsoft a fait des efforts ces dernières années pour mieux gérer les Ryzen, mais le système traîne encore quelques inefficacités et un fond plus lourd. Pour un gamer pur, ça n'a probablement pas grand impact. Mais pour un développeur, un créateur de contenu ou quelqu'un qui compile son propre code, l'écart commence vraiment à avoir du sens.

On peut d'ailleurs se demander si AMD finira par sortir une version officiellement labellisée Linux. Pour l'instant, rien d'annoncé. Mais bon, qu'un constructeur grand public reconnaisse explicitement que son matos tourne mieux sous Linux serait déjà une petite révolution culturelle.

Source : Phoronix

Orhun Parmaksız, l'un des principaux mainteneurs de Ratatui (une bibliothèque Rust très utilisée pour créer des interfaces texte dans le terminal), vient de sortir un projet qui sort vraiment des clous.

Ça s'appelle Ratty, c'est donc un émulateur de terminal capable d'afficher des objets 3D, des sprites animés et des modèles complets en plein milieu de votre ligne de commande.

Si vous cherchez une alternative à Termius qui ne vous coûte pas une petite couille, je crois que j'ai trouvé ce qu'il vous faut !

C'est vrai qu'il y a quelque chose de carrément agréable à pouvoir ouvrir un navigateur depuis n'importe quelle machine et retrouver tous ses serveurs, fichiers et tunnels au même endroit... Et Termius fait ça très bien, sauf que la fonctionnalité la plus utile, à savoir la synchro entre appareils, c'est payant !

Et c'est ça la raison d'être de Termix qui propose exactement ça mais en open source, en gratos et à héberger vous-même !

Termix, c'est donc une plateforme de gestion de serveurs accessible depuis le navigateur. On y retrouve un terminal SSH complet, de la gestion de fichiers distants, des tunnels SSH inversés, et depuis la v2.0 sortie en mars dernier, le support RDP, VNC et Telnet.

En clair, ça couvre à peu près tout ce dont on a besoin pour piloter une infra depuis un seul endroit. Petit détail à noter quand même, le RDP/VNC/Telnet n'est pas inclus par défaut, donc il faut ajouter un second conteneur guacd au compose. Rien de compliqué, mais à savoir avant de se lancer.

Le terminal SSH supporte jusqu'à 4 panels simultanés comme ça plutôt que de multiplier les sessions, vous regroupez au même endroit. Le gestionnaire de fichier est aussi très sympa avec du drag & drop dans les deux sens, la modification de fichiers distants directement dans le navigateur... Et y'a aussi une gestion des conteneurs Docker intégrée, un Network Graph pour visualiser les connexions entre hôtes, et un système de snippets de commandes pour éviter de retaper les mêmes commandes à longueur de journée.

Ce qui change par rapport aux autres alternatives web, c'est surtout sa dispo sur toutes les plateformes. L'accès web est évidemment central, mais il existe aussi des apps natives pour Windows, Linux, macOS (App Store, DMG ou Homebrew selon vos préférences), iOS/iPadOS et Android.

Tout se synchronise ensuite via le conteneur self-hosted comme ce que permet Termius, à la différence près que vous hébergez vous-même le système.

Côté sécurité et gestion d'équipe, Termix intègre du RBAC, de l'OIDC, du 2FA, et stocke les données dans une SQLite chiffrée.

Pour tester en local, le docker-compose de base ressemble à ça :

services:
 termix:
 image: ghcr.io/lukegus/termix:latest
 ports:
 - "8080:8080"
 volumes:
 - termix-data:/app/data

volumes:
 termix-data:

Plus de 4 000 commits, 5 ans de décompilation acharnée, et selon l'équipe ZeldaRET le plus gros projet de reverse-engineering jamais bouclé sur un jeu Nintendo. Voilà tout ce qu'il a fallu à la team Twilit Realm pour livrer Dusk, leur portage natif de Zelda Twilight Princess sur Windows, macOS, Linux, iOS et même Android.

La sortie officielle a eu lieu samedi dernier, et le projet fait son petit effet dans la communauté retrogaming.

Link traverse les plateformes dans Dusk (capture du site officiel )

Pour faire fonctionner le jeu, vous devez récupérer le binaire Dusk sur GitHub , puis lui fournir votre propre dump du jeu GameCube car la team ne distribue aucun asset de Nintendo pour limiter le risque juridique... Après je vous fais confiance pour en trouver tombé du camion... ^^.

Et hop, en moins de temps qu'il n'en faut pour le dire, vous vous retrouvez à jouer à Twilight Princess sur votre Steam Deck, votre iPhone, votre laptop M3, votre tour Linux ARM64, peu importe... Tout ça sans émulateur Dolphin puisque le code GameCube a été reverse-engineered au niveau machine puis recompilé pour le matériel moderne, ce qui donne un vrai portage natif avec les avantages habituels : framerate déverrouillé, résolutions HD, modding facilité, performances qui dépotent (sous réserve d'un GPU compatible D3D12, Vulkan ou Metal, les vieux iGPU Intel et certains Adreno galèrent encore).

Le moteur du jeu original tournait à 30 refresh par seconde (en anglais on dit "ticks", c'est le nombre de fois où le moteur rafraîchit / recalcule la 3D du jeu) , c'est-à-dire que la simulation du monde se mettait à jour 30 fois par seconde, point final. La team a gardé ce taux à l'identique pour préserver le comportement de simulation proche de l'original, ce qui rassure surtout les speedrunners.

Sauf que maintenant, le rendu visuel, lui, peut tourner à 144 Hz ou plus. Donc entre deux refresh, Dusk calcule où devraient se trouver les objets et interpole leur position pour produire une image fluide. Vous gardez ainsi la mécanique de 2006, mais l'affichage est de 2026, donc c'est spleennnndiiiiide ! C'est une approche comparable à celle de Ship of Harkinian sur Ocarina of Time.

Côté plateformes, c'est pour Windows x86-64, macOS Intel et Apple Silicon, Linux x86-64 et ARM64, iOS via AltStore et Android en APK direct. Pas de version Switch par contre, et n'ayez pas d'espoir car l'équipe a été claire sur le sujet. Pour des raisons techniques (et j'imagine juridiques) ils n'envisagent pas de port natif sur la console actuelle. Les versions Wii et les autres régions GameCube sont également en chantier, mais pour l'instant ce sont les versions GameCube USA et EUR qui sont supportées. Le projet vérifie même le hash SHA-1 de votre dump pour s'assurer qu'il correspond à une version compatible avant de lancer quoi que ce soit.

Link en wolf enchaîné dans le donjon initial (capture du site officiel )

L'ensemble est sous licence CC0, domaine public, zéro restriction, ce qui veut dire que vous pouvez forker, modifier, redistribuer le code sans contrainte. Le projet repose sur la décompilation zeldaret/tp , menée depuis août 2020 par une communauté internationale de speedrunners et de devs reverse-engineers.

C'est le même schéma juridique qui a permis à Zelda 64 Recompilé de prospérer. Les projets évitent de distribuer des assets Nintendo, mais ça ne supprime pas tout risque de notification DMCA puisque la légalité dépend aussi de votre juridiction et de la manière dont le dump a été obtenu (DMCA section 1201 aux US, qui interdit en principe le contournement de protection, donc la prudence reste de mise).

Maintenant, faut pas se voiler la face sur le destinataire d'une lettre recommandée potentielle puisque Nintendo a fait sauter yuzu et son fork Suyu en 2024 avec 2,4 millions de dollars de règlement à la clé, Ryujinx a mis la clé sous la porte en octobre dernier sous pression directe, Garry's Mod a dû purger 20 années de contenu Nintendo de son workshop, et la société attaque actuellement Palworld sur des brevets de gameplay déposés à la va-vite.

Donc même quand un projet respecte le droit à la lettre, la firme japonaise a les moyens de noyer une équipe bénévole sous des frais d'avocats jusqu'à épuisement total. Les ports type Ship of Harkinian tiennent depuis plusieurs années déjà sans procédure, mais rien ne garantit que Dusk passera entre les gouttes. Si vous voulez profiter du jeu sur PC, je vous conseille donc de cloner le repo en local et de mettre le binaire de côté quelque part, on ne sait jamais....

Link récupère un fragment de coeur (capture du site officiel )

Pour l'installation, vous filez sur le repo GitHub, vous chopez le binaire de votre plateforme, vous pointez le launcher vers votre dump GameCube (que vous avez fait vous-même depuis une Wii moddée en suivant le guide du wiki Dolphin, hein...), et c'est parti mon kiki.

Merci à j0j0b4rj0 pour la découverte.

Le truc cool avec un disque de backup, c'est quand vous arrêtez de le sortir du tiroir. Et c'est ce que permet de faire le DATO Ares Q4 (lien affilié) qui se trouve être aimanté et que je peux donc coller direct sur le côté de mon Mac Studio . Je l'ai depuis bientôt un an, et c'est devenu mon disque de Time Machine à résidence.

Il est trop mignon parce qu'il est tout petit, puisqu'il mesure 64 par 64 mm, 12 mm d'épaisseur, et 40 grammes, soit à peine plus gros qu'un bloc de petits Post-it, sauf que dedans y'a 4 To de NVMe en USB4. Les aimants sont prévus pour s'accrocher à un iPhone 15/16/17 Pro façon MagSafe, mais en pratique ils tiennent aussi nickel sur n'importe quelle machine, si vous collez le petit aimant-sticker livré avec.

Après je sais pas si coller un aimant sur un ordinateur c'est le move le plus intelligent que j'ai fait de ma vie mais je l'ai collé y'a 1 an, et ça bouge pas et j'ai aucun souci. Après c'est pas des GROS aimants non plus hein... C'est assez fin et pas très aimanté non plus. Et niveau connectique, c'est livré avec un câble USB-C rikiki de 10 cm.

Côté débits l'USB4 crache du 4000 Mo/s en lecture et 3600 Mo/s en écriture et comme c'est du natif, y'a pas de puce intermédiaire entre le NVMe et le port, donc on est max de ce qu'on peut avoir en vitesse avec ce genre de disque. Par contre, faut un port USB4 ou Thunderbolt 4/5 côté Mac, sinon ça retombe sur de l'USB 3.2 classique. C'est pas dramatique mais ça va 'achement moins vite quand même.

Et comme mon Mac Studio embarque 4 To en interne, c'est pile la taille du DATO que je dédie à ma sauvegarde Time Machine. Le sparsebundle peut donc grossir jusqu'à occuper tout le disque sans que je m'en occupe ! Et comme je ne le remplis jamais à 100%, je suis assez tranquille.

En plus de ce SSD, je fais toujours des backups sur mon NAS Synology avec Carbon Copy Cloner à côté parce que je suis parano et qu'on sait jamais...

Côté chauffe, la surprise est plutôt bonne, il reste froid / tiède même en plein transfert. Alors je suis pas sûr mais je me dis que le boîtier en alu du Mac Studio, joue peut-être un petit rôle de dissipateur thermique mais j'sais pas, peut-être pas... En tout cas, ça chauffe pas quoi.

Ce disque est compatible Mac, PC, Linux, et même iPhone Pro en USB-C comme ça si vous avez besoin de filmer de la 4K ProRes HDR direct sur un SSD plutôt que sur la mémoire interne, c'est possible ! Et il est garanti 5 ans, ce qui est toujours bon à prendre.

Voilà, si ça vous intéresse, le DATO Ares Q4 (lien affilié) est dispo sur Amazon en versions 1 To, 2 To ou 4 To .

Justin Poehnelt, Senior Developer Relations Engineer chez Google, vient de balancer sur Github un outil en ligne de commande (CLI), codé en Rust qui permet de faire un truc trop pratique, à savoir piloter entièrement Workspace depuis le terminal. Ce logiciel nommé GWS est donc capable de gérer Gmail, Drive, Calendar, Sheets et sept autres services Google d'un coup. Et en plus, comme il a été conçu pour les agents IA, donc c'est pas juste pour vous et votre terminal !

Une fois installé via npm, cargo, brew ou un binaire pré-compilé, vous tapez gws auth login pour vous authentifier via OAuth et vous pouvez ensuite attaquer onze services depuis votre shell : Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, Apps Script, Tasks, Workspace Events et Model Armor.

Niveau archi, au lieu de hard-coder chaque commande dans le binaire, gws interroge tout simplement le Discovery Service de Google au démarrage et reconstruit son arbre de commandes à la volée. Du coup quand Google ajoute un endpoint à l'API Sheets, le CLI le voit apparaître tout seul. C'est trop bien parce que ça évite de devoir attendre une release pour utiliser un éventuel nouveau service de Google. Et pour un agent IA qui re-fetch le schéma à chaque run, c'est plutôt une bonne idée.

Donc en plus de démarrer en moins d'une seconde, GWS crache des sorties en JSON structurées, y'a un mode --dry-run qui montre la requête sans l'envoyer, et de l'auto-pagination via --page-all. Et côté commandes utilitaires, vous avez aussi les + qui sont des helpers cousus main tels que gws gmail +send, gws drive +upload, gws calendar +agenda, gws sheets +append, gws gmail +triage et un gws gmail +standup-report qui résume vos mails de la semaine en quelques lignes.

Le repo embarque aussi 40+ skills d'agent prêts à l'emploi du type "résume mes mails non lus" ou "génère mon rapport", une extension Gemini CLI qui s'installe avec gemini extensions install https://github.com/googleworkspace/cli, et le helper +sanitize-response qui fait passer la sortie par Model Armor (le filtre anti-prompt-injection de Google Cloud) pour éviter les réponses bizarres.

En gros, c'est un outil pensé pour faire piloter votre Workspace par Claude, Gemini ou n'importe quel agent. Comme ça vous allez pouvoir écrire un workflow qui lit vos mails non lus, en fait un résumé, le poste dans un Chat et classe tout ça proprement dans Drive... sans avoir à toucher à la souris ni avoir à utiliser votre cerveau léthargique. Elle est pas belle la vie ?

Sauf que. Le projet porte le disclaimer "This is not an officially supported Google product", et un employé Google a confirmé sur le thread Hacker News (presque 1000 points, quand même) que c'est un projet DevRel. Comprendre : pas de SLA, pas de roadmap garantie, pas d'équipe SRE qui veille au grain. Vous savez comment ça finit chez Google avec ce genre de statut !

Bref si vous êtes chaud pour tester, le binaire est dispo ici . Maintenant reste à voir si Google lui donnera un statut officiel ou si GWS s'éteindra discrètement comme tant d'autres projets internes oubliés...

Speedtest.net c'est pratique, sauf que ça a été racheté par Accenture en 2026 et chaque test envoie votre IP, le nom de votre FAI et votre localisation à leurs serveurs...

Alors pourquoi ne pas adopter LibreSpeed , l'alternative open source que vous hébergez chez vous, et qui ne contient aucun tracker ??? L'outil est signé Federico Dossena, ça a été lancé en 2016 et c'est sous licence LGPL v3. Et ce que ça mesure c'est la vitesse du download, de l'upload, le ping, le jitter , et ça relève aussi l'adresse IP et le nom de votre FAI.

Côté déploiement, c'est du classique. Vous déposez les fichiers sur votre serveur, dont speedtest.js et speedtest_worker.js pour le frontend, vous configurez le backend via config.json, et hop c'est lancé. Un simple VPS ou n'importe quelle autre machine sur votre LAN fera l'affaire.

Et comme vous choisissez le serveur de test, y'a pas de saturation par d'autres utilisateurs, pas de route réseau bizarre vers un data center à l'autre bout de l'Europe et surtout, les résultats sont parfaitement reproductibles donc pour les "homelabers" (c'est comme ça qu'on dit ?) ou les équipes réseau, c'est assez chouette.

Il y a aussi le mode multi-serveur pour comparer des endpoints, le partage de résultats via lien unique, et un CLI librespeed avec ses flags --server et --host pour les fans du terminal. Des backends officiels en Go et Rust existent aussi sur le github de librespeed , signe que le projet est sérieux.

Et surtout, les résultats sont fiables, sauf si votre serveur plafonne à 20 Mbit/s et dans ce cas, vous mesurerez sa liaison et pas la vôtre. Ça coule de source, mais je tenais à le préciser quand même...

Voilà, l'interface est moche, en tout cas beaucoup plus que celle de Speed.cloudflare.com , par contre l'essentiel est là. Et surtout, les mesures restent chez vous plutôt que de partir ailleurs.

Bon, maintenant que vous avez vos chaînes IPTV qui tournent via Tunarr ou xTeVe, votre flux XMLTV est super propre. Mais il vous manque un seul truc : Un guide de programme potable.

Hé bien GridTV développé par l'ami JohnnyBeGood est là pour ça !

GridTV c'est une interface web en PHP/JS/CSS qui transforme toute source XMLTV compatible en guide TV façon grille horizontale, avec l'indicateur "maintenant" visible en permanence, une barre de progression du programme en cours, et les émissions passées qui se retrouvent automatiquement grisées. C'est exactement ce à quoi ressemble le guide TV de votre box opérateur, mais en mieux, et pour votre propre contenu !

Pour le déploiement, Docker est le chemin recommandé plutôt que de tout configurer à la main : git clone, cd GridTV, docker compose up -d, et hop, vous ouvrez localhost:8080.

Un assistant de setup vous demandera alors votre source EPG obligatoire et une playlist M3U si notamment vous voulez utiliser le player intégré, et une fois validé, vous retombez directement sur la grille.

Ça se met en place en moins de 5 min mais si vous préférez installer sans Docker, ou plutôt sans la couche conteneur, il y a également sur le Github des exemples de config pour Apache et Nginx dans la doc. Caddy fonctionnera aussi et la doc concernant Traefik, c'est pour le cas où GridTV tourne en Docker mais derrière un reverse proxy.

Côté fonctionnalités, le player HLS s'ouvre en PiP (Picture in Picture) dans un coin en cliquant sur une chaîne et le multi-EPG vous permettra de configurer plusieurs sources avec un petit switch. GridTV propose aussi des rappels de programme via notifications navigateur, 15 minutes avant la diffusion. Mais pour en profiter, l'onglet du browser doit rester ouvert et les notifs autorisées.

Et il y a aussi possibilité de générer un export PDF/PNG du guide sur 24h. C'est pas indispensable mais ça permet pour ceux qui veulent d'imprimer le programme de la soirée.

Chaque visiteur de l'instance peut aussi utiliser / paramétrer ses propres URLs XMLTV/M3U, car rien n'est stocké côté serveur. Hé oui, tout passe par le localStorage du navigateur donc vous pouvez partager votre instance avec autant de monde que vous voulez, ça n'a pas d'impact.

La version Steampunk

Et il y a même des thèmes genre cyberpunk, steampunk, magazine ou le thème par défaut. Et la page de monitoring admin expose également une sonde accessible via un endpoint compatible Uptime Kuma qui renvoie le code HTTP 200 si tout va bien. Sinon, ce sera du code 503. Bref, ça vous connaissez...

Bref, l'outil est jeune mais bien construit et une démo live tourne ici guide.demo.johnnybegood.fr . À suivre donc....

Et si vous cherchez juste des listes de chaînes IPTV gratuites , c'est par là !

Le gouvernement néerlandais a ouvert sa propre instance Forgejo à l'adresse code.overheid.nl, hébergée sur les serveurs de l'État via SSC-ICT (le service informatique mutualisé du gouvernement).

L'idée dans cette démarche, c'est de regrouper tout le code source produit par les administrations sur une plateforme libre et hébergée localement, plutôt que de continuer à dépendre de GitHub (Microsoft) ou de GitLab dont les versions entreprise sont fermées.

Forgejo, c'est un fork de Gitea, lui-même fork de Gogs, et il est complètement libre sous licence GPLv3+. Pas d'édition entreprise propriétaire, pas de fonctionnalités payantes planquées derrière des plans premium.

Du libre pur. C'est exactement ce que cherchent les administrations qui en ont marre de devoir confier leur code à une boîte américaine soumise au CLOUD Act. Les Pays-Bas ont vu la France galérer avec sa souveraineté numérique pendant des années et ont préféré agir vite plutôt que de discuter encore cinq ans.

Plusieurs ministères ont déjà migré : Finances, Affaires étrangères, Agriculture, Intérieur. Côté municipalités, La Haye, Utrecht, Leiden et Arnhem sont aussi de la partie.

Screenshot

Parmi les premiers dépôts publiés, vous avez le code du Conseil électoral néerlandais qui gère les élections, et plusieurs projets de digital workplace de l'Intérieur. Pour l'instant c'est encore en pilote pour récolter les retours développeurs, mais le déploiement s'élargit petit à petit.

Ce qui est intéressant dans la démarche, c'est la cohérence avec ce que les Pays-Bas ont déjà acté : sortie progressive de Microsoft Office au profit d'alternatives ouvertes, exigence de souveraineté sur les données de santé et refus du CLOUD Act sur certains marchés publics.

La migration Forgejo arrive dans cette logique de réduction systématique des dépendances aux géants américains, sans pour autant tomber dans le repli technologique total.

Bref, vous l'avez compris, pendant que d'autres pays publient encore des rapports sur la souveraineté numérique, les Pays-Bas ont juste appuyé sur le bouton.

Source : Itsfoss

Un maker a transformé une réplique grandeur nature de C-3PO en assistant vocal interactif, et le résultat est franchement convaincant. Sa version du droïde papote, répond à vos questions, et tient même une conversation, le tout sans dépendre du moindre cloud une fois en local.

Le truc tient sur un Raspberry Pi 5 planqué dans la coque dorée du droïde. Un micro capte ce que vous racontez, un moteur de speech-to-text le transcrit, et un LLM local s'occupe de comprendre votre question pour formuler une réponse. Jusque là, rien de fou c'est même devenu même assez classique.

Hello les amis, voici ma petite trouvaille du jour, idéale pour ceux qui jouent en ce moment avec des adresses IP : ip66.dev . C'est une base de géolocalisation IP et entièrement libre, livrée au format MMDB (le même que celui de MaxMind) qui permet de remplacer direct un fichier GeoLite2 dans vos libs existantes (Python, Go, Node.js), sans toucher au code.

L'équipe de Cloud 66 maintient cette liste à jour sous licence CC BY 4.0 et tout est utilisable simplement en récupérant le fichier mmdb.

Pour le télécharger :

curl -LO https://downloads.ip66.dev/db/ip66.mmdb

go install github.com/maxmind/mmdbinspect/cmd/mmdbinspect@latest
mmdbinspect -db ip66.mmdb 8.8.8.8

Vous vous souvenez de l'époque où on s'écroulait comme des merdes dans notre canapé après une grosse journée de boulot et où on regardait juste ce que la télé nous balançait ? Pas de choix à faire sur Netflix, ni de recommandation sur l'Apple TV. On zappait juste en mode no-brain jusqu'à ce qu'on tombe sur une connerie qui réveille notre cerveau reptilien.

Eh bah le dev Chris Benincasa a créé Tunarr , un soft open source qui ressuscite ce truc-là en transformant votre Plex ou Jellyfin en chaîne de TV en continue.

Grâce à Tunarr, vous configurez vos chaînes dans une interface web (en glisser-déposer...), le soft émule un tuner HDHomeRun (le standard de la TV réseau aux US), que Plex, Jellyfin ou Emby reconnaissent ensuite comme une vraie source TV. Et voilà comment vous avez maintenant votre propre antenne maison.

Ou alors vous exportez en M3U pour des players IPTV comme Tivimate ou UHF, le tout avec un EPG intégré (c'est le guide des programmes), des bumpers (vous savez ces petites séquences Tchii Tchaaa ou M6 Mhmmmh des chaînes TV), des pubs vintage entre les programmes et même des clips musicaux pour faire authentique.

Bref, du déjà-vu, mais avec votre catalogue d'émissions à vous.

docker run -d -p 8000:8000 -v ./tunarr-data:/config/tunarr chrisbenincasa/tunarr:latest

Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !

KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !

C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.

KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.

Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):

bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"

Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.

Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.

Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.

Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.

Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.

Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !

Le déploiement Docker c'est comme ça :

docker run -d --name kula --pid host --network host
 -v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest

Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.

Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...

Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.

Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !

Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.

Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.

Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.

C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.

Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !

Source

45 ans après sa sortie, le code source du tout premier 86-DOS vient d'atterrir sur GitHub . Microsoft a profité de cet anniversaire pour publier les listings d'assembleur originaux, accompagnés de plusieurs versions de PC-DOS 1.00 et de MS-DOS 1.25, sous licence MIT. Tout ceci est dans le dépôt DOS-History/Paterson-Listings, et oui, le tout est compilable.

Ces listings, c'est Tim Paterson en personne qui les avait conservés dans ses tiroirs depuis 1980. À cette époque, il bossait chez Seattle Computer Products, une boîte de matos qui faisait des cartes pour processeurs Intel 8086.

Il avait écrit en quelques mois un OS rudimentaire baptisé 86-DOS pour faire tourner les machines de SCP. Microsoft a fini par racheter le code à SCP pour 75 000 dollars, l'a légèrement retravaillé, et l'a refilé à IBM sous le nom PC-DOS pour équiper le tout premier IBM PC. Ce code-là est le grand-père de Windows.

On parle ici de dix paquets de listings papier (le bon vieux papier à bandes vertes), dont huit ont déjà été transcrits par Yufeng Gao et Rich Cini, deux passionnés de préservation. À l'intérieur : le noyau de 86-DOS 1.00, plusieurs snapshots de développement de PC-DOS 1.00, et des utilitaires comme CHKDSK.

Plus intéressant encore, les listings contiennent les annotations manuscrites de Paterson lui-même, des notes en marge qui montrent les hésitations et les corrections d'un ingénieur en plein travail.

Le code est prêt à être compilé avec l'assembleur SCP d'origine, ce qui veut dire qu'on peut générer des binaires fonctionnels et les faire tourner dans un émulateur comme par exemple PCem ou 86Box. C'est rare en archéologie logicielle d'avoir des snapshots aussi complets, et c'est encore plus rare quand l'auteur original est toujours là pour répondre aux questions. Les originaux papier vont d'ailleurs rejoindre l'Interim Computer Museum, donnés par Paterson lui-même.

Ce n'est pas la première fois que Microsoft ouvre du code un peu ancien. En 2018, ils avaient déjà open-sourcé MS-DOS 1.25 et 2.11. En 2024, c'était MS-DOS 4.0. Mais cette fois on remonte carrément à la racine, à la version SCP avant rachat, avec les fragments de l'évolution vers PC-DOS. Du coup, pour les nostalgiques et les chercheurs en histoire de l'informatique, c'était la pièce manquante.

Petite cerise sur le gâteau : les scans bruts des listings papier sont aussi sur Archive.org, donc même la version "préhistorique" est consultable. Et si vous avez envie de contribuer à la transcription des deux paquets restants, ce projet est ouvert.

Bref, le grand-père de Windows est désormais lisible ligne par ligne, annotations comprises. Pour les fans d'archéologie informatique, c'est carrément chouette.

Source : Hackaday

Vous bossez sur un Dockerfile et vous avez besoin de la dernière version de nginx. Vous ouvrez GitHub, vous cliquez sur Releases, vous copiez-collez. Et 3 minutes plus tard, rebelote pour curl. Puis pour PHP. Sans parler du fait que dans votre script d'auto-update, vous avez hardcodé une "v3.2.1" qui dort là depuis 2023 parce que personne n'a pris le temps de mettre à jour le fichier.

Lastversion , c'est le petit CLI Python signé Danila Vershinin qui remplace cette corvée par une seule ligne. Vous tapez lastversion apache/incubator-pagespeed-ngx et vous récupérez le numéro de la dernière version.

Le truc marche sur GitHub, GitLab, BitBucket, PyPI, Wikipédia, les flux RSS, les plugins WordPress, Helm charts, Gitea, SourceForge... et même sur des sites qui publient leurs versions comme ils veulent, genre nginx.org.

La beauté du bazar, c'est qu'il comprend les humains, parce que, c'est vrai, les mainteneurs font un peu n'importe quoi avec leurs tags. Ils étiquettent release-1.2.3 au lieu de 1.2.3, ils marquent des release candidates en stable sans le faire exprès, ils changent de format entre v20150121 et v2.0.1 sans prévenir. lastversion détecte toutes ces incohérences et vous renvoie la véritable dernière stable, celle que vous vouliez dès le départ. C'est pénible à gérer à la main quand vous avez vingt dépendances à suivre. Maintenant c'est réglé tout seul avec ce petit bidule.

Et les sources exotiques, c'est tout un délire. lastversion windows vous crache le build Windows en cours, lastversion ios pour iOS, lastversion rocky vous renverra 8.4 et lastversion https://en.wikipedia.org/wiki/Rocky_Linux aussi, parce que le bidule va carrément parser la page Wikipédia pour vous.

Alors certains d'entre vous me diront que ce n'est pas utile au quotidien. Peut-être jusqu'au jour où vous devez scripter une vérif de version d'OS sans dépendre d'un outil système. Par contre, si vous enchaînez cinquante requêtes par heure sur un token GitHub anonyme, faudra pas s'étonner de manger un rate limit dans la tronche.

Côté one-liners qui tuent, y'a déjà de quoi faire.

wget $(lastversion --assets mautic/mautic) télécharge direct la dernière archive.

lastversion --pre Aircoookie/WLED --format assets --filter ESP32.bin -d ESP32.bin récupère le dernier firmware ESP32 WLED.

Pour Nginx, lastversion https://nginx.org --major stable renvoie 1.16.1 pendant que --major mainline renvoie 1.17.9.

Vous voyez l'idée, c'est du pipe-friendly pur jus.

Et le mode install, c'est un autre délire. Vous tapez lastversion install mailspring et hop, il récupère l'AppImage ou le RPM du dépôt, il l'installe, et c'est fini. Attention quand même, sur les dépôts un peu bordéliques il va parfois se vautrer sur le packaging et juste vous balancer le tarball brut. Bon, c'est pas la mort, vous dézippez à la main et vous passez à la suite...

Combiné avec cron, @daily /usr/bin/lastversion install mailspring -y et votre bureau sera toujours à jour sans passer par un store. Pour tous les outils qui ne sont ni dans apt, ni dans un snap, ni dans un flatpak, c'est l'alternative la plus propre à avoir sous la main.

L'install se fait via pip install lastversion sur à peu près tout, ou yum install lastversion après avoir ajouté le repo GetPageSpeed si vous êtes sur CentOS, RHEL, Rocky, Alma, Fedora ou Amazon Linux.

Le projet est publié sous licence BSD-2, codé en Python, et il y a aussi une API utilisable directement (from lastversion import latest) si vous préférez appeler ça dans vos scripts plutôt que de piper dans un subprocess.

Bref, un chouette outil à ranger entre vos redirections bash et votre gestionnaire SSH , catégorie petits trucs qui font gagner 10 minutes par semaine.

Ah, LaTeX...

Si vous avez un jour essayé de poser 3 équations dans un document sérieux, vous voyez le genre de galère que c'est. Le rendu est magnifique, les maths sont propres, mais faut d'abord digérer son langage de markup avant de réussir à imprimer la moindre intégrale. Heureusement, c'est là qu'arrive GNU TeXmacs , un éditeur scientifique libre qui fait pareil mais en WYSIWYG.

Ça tourne sur Linux, macOS et même des OS du passé comme Windows ^^ et ça devrait ravir étudiants en sciences, thésards, chercheurs, enseignants, ou autres curieux qui veulent voir à quoi ressemble un éditeur scientifique vraiment libre. Faut vous imaginer un Google Docs avec un mode maths natif, dans lequel vous tapez directement votre équation comme dans un bon vieux Word avec du gras (c'est bon le gras ^^ !), de l'italique, des fractions, ou encore des racines carrées que vous pouvez faire à la souris ou via des raccourcis clavier. Et le moteur vous sort alors une typographie de niveau publication académique. Comme ça, pas besoin de "recompiler" votre document à chaque correction car tout s'affiche en direct !

Une formule rendue directement dans l'éditeur, sans recompilation

Le truc qu'il faut comprendre, c'est que TeXmacs n'est PAS un frontend graphique pour LaTeX. C'est un moteur de typographie complètement indépendant, qui s'inspire des idées de TeX sans en recycler le code. Vous pouvez donc exporter vers du .tex si un collègue en a besoin, mais ce n'est pas ce qui tourne sous le capot pendant que vous écrivez.

L'autre truc sympa, c'est que TeXmacs sert aussi d'interface pour de nombreux systèmes de calcul formel libres tels que Maxima, Sage, Pari ou Axiom qui peuvent balancer leurs résultats directement dans votre document, formatés proprement. R et Octave sont aussi de la partie pour le côté stats et numérique.

TeXmacs servant d'interface à un système de calcul formel, le résultat tombe déjà formaté

Derrière le projet, y'a Joris van der Hoeven, un mathématicien néerlandais et Directeur de recherche au CNRS. Il bosse sur TeXmacs depuis la fin des années 90, et maintient en parallèle Mathemagix, un système de calcul formel libre qui se marie forcément bien avec. Le projet est sous licence GPL et fait partie du projet GNU . Ce n'est donc pas un truc vibe codé en un weekend just 4 fun !

TeXmacs reste quand même un logiciel de niche. Et gaffe en particulier à l'import depuis LaTeX, qui laissera tomber les fichiers de style custom et ne gèrera qu'un sous-ensemble du langage. L'interface a aussi un côté très années 2000 assumé, et la communauté est plus petite que celle de LaTeX.

Mais peu importe, moi ce qui me plaît dans la démarche, c'est cette indépendance assumée vis à vis de TeX avec un moteur refait à zéro et pas une surcouche contraignant comme LyX. Alors oui forcément, on perd un peu de compatibilité mais ça rend tellement service que c'est pas très grave.

Voili voilou, si vous êtes amateur de maths et de formules ou que vous voulez voir à quoi ressemble un éditeur scientifique vraiment WYSIWYG, ça vaut son petit téléchargement. Puis c'est gratuit alors foncez !