J'ai jamais fait construire de maison mais je crois savoir que dessiner le plan de sa maison en 3D, ça passe encore par un logiciel assez lourd à installer + une licence, sans oublier l'interface façon Micro Applications de 2003 (qui s'en souvient ??). C'est pourquoi Aymeric Rabot et Wassim Samad ont pris le problème autrement avec Pascal Editor, un éditeur de bâtiments 3D qui tourne simplement dans un onglet de navigateur. Et en plus, c'est gratuit, open source (licence MIT) et surtout sans inscription.

Vous tracez les murs à la souris, puis viennent les zones, les dalles, les plafonds et les toits. Les portes et les fenêtres sont paramétriques, posez-les sur une cloison, la découpe se fait toute seule en géométrie booléenne via three-bvh-csg. Le mobilier s'accroche au sol, au mur ou au plafond selon l'objet ( allez regarder cet exemple ! )

Si vous avez un Mac Apple Silicon et que vous en avez assez de payer des tokens à chaque requête, Rapid-MLX vaut le détour. C'est un moteur d'inférence local maintenu par Raullen Chai, qui tape directement dans les kernels MLX d'Apple, sans repli sur llama.cpp ni couche Metal intermédiaire. Et si le nom vous dit vaguement quelque chose, c'est normal puisque c'est un fork de vLLM-MLX, le serveur de Wayner Barrios dont je vous parlais en mai . Rapid-MLX a juste pris un rythme de publication plus soutenu des deux.

Ce que ça vous donne, c'est donc un serveur HTTP qui parle le même langage que l'API d'OpenAI et celle d'Anthropic. Vos scripts, Cursor, Aider, LangChain ou Claude Code continuent de fonctionner, sauf qu'ils tapent sur votre machine au lieu d'un datacenter.

Donc je vous propose de voir ensemble comment installer ça.

Étape 0 : Vérifier que votre Mac est éligible

Le script d'installation contrôle plusieurs choses avant de lancer quoi que ce soit, et autant les connaître d'avance. Il faut une puce Apple Silicon et il n'y a pas de version Linux ni Windows, ni de support CUDA ou AMD.

Le script d'installation accepte encore macOS 13 Ventura, mais le vrai plancher est macOS 14 Sonoma. La formule Homebrew l'exige, et surtout MLX, la brique Apple sur laquelle tout repose, ne publie de paquets macOS que pour les versions 14, 15 et 26. Sur un Mac resté en Ventura, ça cassera donc à l'installation des dépendances, quel que soit le chemin choisi.

Dernier point à avoir en tête, c'est pensé pour votre machine à vous et pas pour un serveur. Vous n'y trouverez donc ni authentification multi-utilisateurs, ni quotas de requêtes.

Étape 1 : Installer Rapid-MLX

Le plus simple, c'est Homebrew :

brew install rapid-mlx

Si vous gérez déjà vos environnements Python vous-même, les autres chemins existent :

uv tool install rapid-mlx@latest
python3.12 -m pip install rapid-mlx

Il y a aussi un installeur en une ligne (curl -fsSL https://rapidmlx.com/install.sh | bash) qui détecte votre RAM et vous propose un modèle adapté. Il crée un venv isolé dans ~/.rapid-mlx/ et pose le binaire dans ~/.local/bin/. Un curl | bash reste un curl | bash. La formule Homebrew fait exactement le même boulot, donc l'installeur en ligne perd de son intérêt.

L'installation de base pèse dans les 460 Mo et la vision, l'audio et les embeddings sont des extras optionnels, vous les ajouterez seulement si vous en avez l'usage.

Étape 2 : Choisir un modèle qui tient dans votre RAM

C'est là que la plupart des gens se plantent, en chargeant un modèle trop gros et en concluant que "ça rame". Sur Mac, la RAM est unifiée, donc le modèle mange directement dans la mémoire que se partagent le CPU et le GPU.

Les paliers recommandés par le projet :

Le catalogue complet se liste avec la commande rapid-mlx models, et rapid-mlx info <alias> vous donne le profil détaillé d'un modèle. Si vous voulez sortir du catalogue maison, le filtre matériel de Hugging Face que je vous montrais fin juin fait exactement ce tri à votre place.

Pour utiliser un autre modèle que celui par défaut, il suffit de reprendre l'alias affiché par rapid-mlx models et de le passer en argument. Et si vous préférez télécharger les poids à l'avance, sans rien lancer, c'est le boulot de rapid-mlx pull, qui accepte aussi bien un alias du catalogue qu'un identifiant Hugging Face :

rapid-mlx pull qwen3.5-9b-4bit

Le modèle atterrit dans le cache Hugging Face de votre machine, et ensuite rapid-mlx chat qwen3.5-9b-4bit ou rapid-mlx serve qwen3.5-9b-4bit chargeront ce modèle-là. Le pull préalable reste facultatif, chat et serve téléchargent d'eux-mêmes ce qui manque, mais autant rapatrier les gigas tranquillement avant plutôt qu'au moment où vous voulez bosser.

Étape 3 : Vérifier que ça tourne

Avant de bricoler des intégrations, testez en direct :

rapid-mlx chat

Ça part sur qwen3.5-4b-4bit par défaut, télécharge les poids au premier lancement (comptez 2,5 Go) et vous lâche dans une interface (REPL). /help listera les commandes slash, et /exit vous permettra de quitter le chat.

Une subtilité qui évite de mal interpréter ce premier test, c'est que dans le chat, le raisonnement est coupé par défaut, histoire que le modèle ne vous déballe pas sa réflexion à l'écran. En mode serveur par contre c'est l'inverse, et ça change la vitesse ressentie du tout au tout. J'y reviens plus bas.

Étape 4 : Lancer le serveur

Le vrai intérêt, c'est le mode serveur :

rapid-mlx serve qwen3.5-4b-4bit

Vous récupérez un endpoint sur http://localhost:8000. Le test qui confirme que tout est en place :

curl http://localhost:8000/v1/chat/completions \
 -H "Content-Type: application/json" \
 -d '{"model":"default","messages":[{"role":"user","content":"Dis bonjour !!"}]}'

Et côté Python, vous gardez le SDK OpenAI tel quel, seule l'URL de base change :

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
print(client.chat.completions.create(
 model="default",
 messages=[{"role": "user", "content": "Say hello"}],
).choices[0].message.content)

Pointez n'importe quel client compatible OpenAI sur http://localhost:8000/v1 et c'est réglé. Cursor, Aider, LibreChat, Open WebUI, LangChain, tous marchent avec ce seul changement d'URL. Il y a aussi /v1/embeddings pour du RAG local et /v1/responses pour le Codex CLI.

Étape 5 : Brancher Claude Code dessus

C'est le morceau le plus intéressant du lot, et il tient en deux variables d'environnement. Serveur lancé d'un côté, puis dans un autre terminal :

ANTHROPIC_BASE_URL=http://localhost:8000 ANTHROPIC_API_KEY=not-needed claude

Attention quand même, l'URL de base doit être la racine, sans /v1 à la fin. Le SDK Anthropic ajoute /v1/messages tout seul, donc si vous mettez /v1 vous obtenez /v1/v1/messages et ça casse.

Depuis la 0.10.14, l'appel d'outils passe par une grammaire contrainte activée par défaut, donc plus besoin de bidouiller un --tool-call-parser à la main pour que les tool calls soient parsables. Pour du Claude Code sérieux, visez plutôt un gros modèle, la doc officielle recommande par exemple qwen3.6-35b-4bit en exemple.

Quand ça coince

Le réflexe à avoir avant de chercher ailleurs :

rapid-mlx doctor

Les trois pannes les plus courantes sont toujours les mêmes.

Débit décevant côté serveur, c'est le raisonnement : les Qwen 3.5 et 3.6 démarrent en mode réflexion, donc ils pensent à voix haute avant de répondre, et --no-think règle l'affaire.

Plantage mémoire, votre modèle est trop gros pour la RAM disponible, redescendez d'un palier ou prenez une quantification plus agressive. Appels d'outils qui arrivent en texte brut, la récupération automatique gère la plupart des cas, sinon vous forcez le parser correspondant à votre modèle.

Voilà, grâce à ça, votre Mac est maintenant un serveur d'IA super rapide ! Plus de facture au token, et vos prompts ne sortent plus de la pièce.

Merci à Philobois pour le lien !

Si vous avez un Raspberry Pi et que Chromium commence à vous fatiguer, le VRAI Chrome, celui des chads que vous êtes, est enfin dispo en ARM64 !! Enfin, dispo... Si vous savez où chercher, parce que la page de téléchargement de Google vous propose toujours l'installeur amd64, qui ne tournera jamais sur votre machine. C'est Joey Sneddon, d'OMG! Ubuntu, qui a trouvé la combine en bidouillant l'URL depuis son Pi 5.

Avant toute chose, vérifiez que vous êtes bien en 64 bits, parce qu'un système 32 bits refusera le paquet :

dpkg --print-architecture

Si ça répond arm64, le fichier est là , 126 Mo. Il s'installe comme n'importe quel .deb local, en laissant apt gérer les dépendances :

wget https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb
sudo apt install ./google-chrome-stable_current_arm64.deb

Le RPM existe aussi pour les distributions qui préfèrent, en remplaçant la fin du nom par aarch64.rpm.

J'ai ouvert le paquet pour regarder ce qu'il y avait dedans. Son fichier de contrôle annonce google-chrome-stable en version 150.0.7871.186, architecture arm64, un peu plus de 400 Mo une fois installé. Soit exactement la même version que le paquet x86 poussé le même soir. Le même Chrome, à la même révision.

Et le canal stable n'est pas seul. Le dépôt de Google sert aussi la beta (151.0.7922.47), la dev (152.0.7967.2) et la canary (152.0.7974.0) pour les puces ARM, et son fichier Release déclare noir sur blanc les deux architectures. Les quatre canaux ont été publiés dans la même minute que leurs équivalents x86.

Est-ce qu'on se retrouve coincé sur cette version, à re-télécharger le .deb à la main tous les mois ? Non. Le script de post-installation contenu dans le paquet ajoute le dépôt Google en précisant l'architecture, et les cinq paquets y sont indexés en arm64 exactement comme en x86. Les mises à jour ont donc de quoi arriver par apt, comme d'habitude.

Alors pourquoi s'embêter, puisque Chromium tourne sur ARM depuis des années ? Pour deux trucs. D'abord ma synchro du compte Google, qui ramène favoris, mots de passe et extensions. Et ensuite, Widevine, le module DRM, qui est ici un vrai binaire aarch64 et pas une couche de compatibilité comme l'émulateur FEX financé par Valve . Netflix et les autres plateformes à DRM s'ouvriront enfin sur un SBC !!!

Mais avec une nuance à connaître avant de vous réjouir qui est que sous Linux, Widevine reste au niveau "Software Secure". Cela veut dire que sur Netflix, la qualité plafonnera entre 720p et 1080p. De la HD donc et pas de la 4K. Désoléééé !

Google avait promis tout ça en mars, pour le deuxième trimestre et son billet annonçait même une installation via chrome.com/download pour les autres distributions, ce qui est malheureusement le morceau qui manque aujourd'hui.

Cela veut dire aussi que rien ne garantit que ce paquet soit considéré comme étant prêt par ses auteurs donc si votre machine doit rester stable, laissez passer quelques semaines avant de vous y essayer.

Manque plus que quelqu'un chez Google ait le courage d'appuyer sur "publier".

Source

On ne présente plus Linus Torvalds, le père du noyau Linux, aussi connu pour son génie technique que pour un franc-parler. Cette fois, c'est le débat sur l'usage de l'IA dans le développement du noyau qui l'a fait sortir du bois.

Sur la fameuse mailing list où se décide l'avenir de Linux, il a coupé court à la polémique en posant noir sur blanc que son projet n'était pas, et ne serait jamais, un truc anti-IA.

Sa sortie a de quoi rester dans les annales, puisqu'à ceux que ça agace, il conseille de faire ce que l'open source autorise justement, forker le noyau, autrement dit en copier tout le code pour bâtir leur propre version dans leur coin, ou alors juste s'en aller.

Ce qui est étonnant, c'est le revirement, parce qu'il y a deux ans à peine, ce même Torvalds envoyait balader l'IA en la réduisant à du 90 % de hype. Aujourd'hui, il la décrit comme un outil clairement utile dont plus grand monde ne discute vraiment l'intérêt.

Ça ne l'empêche pas de reconnaître les ratés, puisqu'il admet que ces outils peuvent charger un peu plus la barque des mainteneurs et faire remonter des bugs bien embarrassants, mais pour lui la parade tient en deux mots, de meilleurs outils, surtout pas la fuite.

Le passage le plus tranchant arrive quand il refuse de transformer le noyau en champ de bataille idéologique, en rappelant que ça n'a jamais été un projet de justiciers sociaux et que ça ne le sera jamais.

Dans sa communauté, martèle-t-il, on fait de l'open source parce que ça donne de meilleures technos, pas pour des motifs quasi religieux, et les choix se tranchent au mérite technique, jamais par peur d'une nouveauté.

Il n'est d'ailleurs pas seul sur cette ligne, puisque Greg Kroah-Hartman, l'un des mainteneurs les plus haut placés du noyau juste derrière lui, a confirmé de son côté que les rapports de bugs pondus par des IA étaient devenus franchement précieux.

Voir le créateur de Linux balancer un forkez ou barrez-vous à la figure des anti-IA, c'est du Torvalds pur jus, brutal mais au moins parfaitement limpide.

Source : ARS Technica

J'aime bien lire les articles de l'EFF (l'Electronic Frontier Foundation, la Quadrature du Net des américains quoi...) et là ils viennent de publier un truc m'a fait plaisir : un vrai plaidoyer pour la défense du RSS .

Vous connaissez mon avis là dessus et c'est vrai que depuis que Google a signé l'arrêt de mort de cette techno au profit d'algo à la con type Discover , y'a énormément moins de monde qui l'utilise. Et je trouve ça triste.

Alors que les flux RSS, c'est la liberté ! Ça décloisonne le contenu d'un site pour le faire atterrir dans l'appli de votre choix, ça permet d'en extraire des choses, de le faire traiter par exemple par un programme...etc. Et surtout c'est vous qui gérez la façon dont vous voyez le contenu. Vous pouvez le filtrer, l'ordonner comme vous voulez et surtout le lire avec le lecteur de flux de votre choix.

C'est super pratique, et ça permet par exemple de parcourir uniquement les titres des articles, et de ne s'arrêter que sur ceux qui vous intéressent. Moi y'a plein de trucs qui m'intéressent en ce moment et que j'ai envie de partager. Je suis hyper actif et atteint de FOMO, donc ça bombarde. En plus j'ai que ça à foutre de la journée en général, donc bon, désolé ! ^^ Mais heureusement, avec les flux RSS vous pouvez faire une sélection plus fine et éviter de lire des trucs qui ne vous intéressent pas.

Perso, ça fait des années que je fais de la veille, c'est une partie importante de mon boulot. J'ai commencé sur un lecteur de flux tout pourri, puis je suis passé par Netvibes, Google Reader (paix à son âme), puis Feedly et aujourd'hui j'expérimente Inoreader. Le RSS ne m'a jamais quitté et quand les sites n'en proposent pas, je m'arrange toujours avec des scripts ou des outils customs pour m'en faire un que je peux importer dans mon lecteur !

J'aime tellement ça que sur korben.info, que je vous propose des flux RSS complets (qui contiennent tout le contenu). Le premier, /feed , c'est le flux tech que vous connaissez, historique, exactement comme vous l'aimez. Que de la techno, du code, de la sécu, de l'open source.

Et le petit nouveau c'est /feedfull , qui propose les même sujets tech qu'au-dessus + des sujets un peu plus grand public / mainstream. Dernièrement, j'avais envie envie d'ouvrir un peu plus les portes du site et écrire aussi pour ceux qui ne bidouillent pas et qui veulent juste être au courant d'un truc utile ou deux. Et heureusement, Vincent m'aide dans cette nouvelle aventure !

Bref, c'est vous qui choisissez votre flux, je ne vous l'impose pas ! Et c'est la même logique sur la page d'accueil avec ce petit switch dans le header.

"Complet", c'est l'affichage par défaut, vous voyez tout. Et si vous cliquez sur "Techos", hop, le contenu grand public disparaît. Votre choix est mémorisé dans le local storage de votre navigateur, et voilà.

Si vous n'avez pas encore de lecteur RSS, n'importe lequel fera l'affaire, de Feedly cité plus haut à un truc plus moderne comme MrRSS . Vous copiez l'adresse du flux, vous la collez, c'est réglé. Et tant qu'on y est, vous pouvez aussi reprendre la main sur votre actu côté Google avec cette manip.

Bref, deux flux, un switch, et c'est vous qui tenez le barre !

Source

La Steam Machine de Valve vient à peine d'arriver dans les salons que le youtubeur ETA Prime l'a déjà éventrée sur son établi. Et je sais pas vous, mais moi j'ai bien envie de voir ça avant de lâcher les 1039 euros qu'elle va couter. Ce petit cube vient de sortir d'usine avec ses 16 Go de mémoire et un SSD de 512 Go ou 2 To, et la vraie question que tous les geeks se posent c'est ... roulements de tambour ... : Est-ce qu'on peut l'ouvrir et bidouiller dedans ?

ET BIEN OUI ! Et c'est même plus facile que ce que vous pensez !!!

Tout commence donc avec deux vis T8 à l'arrière (qui ne tombent pas, elles restent solidaires du châssis, c'est qualiiii) et quatre autres sous les pieds. La façade avant, elle, tient juste avec des aimants.

Un coup de spudger , on fait coulisser tout le bloc hors de sa coque en plastique, et là vous tombez sur un gros radiateur en aluminium avec ses caloducs en cuivre, une alimentation intégrée, et la carte mère prise en sandwich au milieu. C'est propre et ça permet d'éviter le gros bloc d'alim qui traine sous la TV.

Le slot M.2, les ports USB avant, le lecteur SD, les USB arrière et l'Ethernet sont montés sur des petites cartes filles reliées par des nappes, ce qui rend le tout très modulaire. Ainsi, si le connecteur USB vous lâche dans 2 ans, bah y'a juste qu'à remplacer le module concerné et basta !

Même le Wi-Fi et le Bluetooth, soudés sur la carte d'entrées-sorties avant, se changent en remplaçant ce seul bloc. Notez que le seul élément un peu fermé, c'est le ventilateur car il est custom, dessiné spécifiquement pour la machine, donc oubliez votre rêve de coller un Noctua à la place. Et pour accéder à la RAM, par contre, il faut sortir le ventilateur et son carénage, débrancher les antennes Wi-Fi, puis dégager le radiateur.

Bonne nouvelle aussi, y'aura pas besoin de refaire la pâte thermique puisque la carte mère se soulève d'un bloc pour libérer les deux emplacements SO-DIMM en dessous. Valve n'en utilise qu'un seul d'origine, avec une barrette de 16 Go en DDR5 à 5600 MT/s, en single channel. ETA Prime a viré ça pour deux barrettes Crucial de 32 Go, soit 64 Go au total.

Au reboot, SteamOS Holo lui a par contre affiché 62 Go de mémoire système (?). Et pour le stockage, le SSD d'origine est un format court 2230 , mais il y a la place pour un 2280 classique. Du coup notre Youtubeur y a mis un Kingston Fury Renegade de 4 To, cloné depuis le disque d'usine avec Etcher pour garder ses jeux et son compte.

La barrette SO-DIMM DDR5 d'origine, à côté des Crucial de 32 Go

Côté tripes, le menu système le confirme bien... La bête contient un AMD Custom CPU 1772 en architecture Zen 4, six cœurs et douze threads à 4,86 GHz, accompagné d'un GPU RDNA 3 (un Navi 33, pour les curieux) avec 8 Go de VRAM. Malheureusement (et là, vous allez chialer), ces 8 Go de mémoire vidéo sont soudés et donc non extensibles. Donc même avec 64 Go de RAM système, vous ne gagnerez quasiment rien en jeu, puisque c'est la VRAM qui fait le boulot graphique. C'est couillon...

Le menu système après upgrade : 62 Go de RAM, mais toujours 8 Go de VRAM

Cela signifie que vu les prix de la RAM en ce moment, ça ne vaut pas le coup de l'upgrader sur la Steam Machine. Les 16 Go d'origine suffisent largement pour la plupart des gens (Le prix de la mémoire était justement une des raisons pour lesquelles la Steam Machine coûte plus cher qu'une PS5 Pro, haha).

Pareil pour le SSD, payer un M.2 4 To, c'est se faire mal au portefeuille pour rien alors qu'un disque dur externe USB de 5 To coûte trois fois moins cher. Un peu plus lent au chargement, certes, mais c'est largement suffisant pour stocker votre ludothèque.

Mais je suis quand même content de voir que Valve a sorti une vraie machine ouverte, réparable avec un simple tournevis, là où la concurrence nous soude tout comme des déglingos et interdit le moindre accès.

Merci à ETA Prime pour le démontage en règle !!

Source : la vidéo d'ETA Prime

À tous les nostalgiques de la Nintendo 64 et notamment de Super Mario 64, j'ai un petit truc cool à vous montrer. Tobi Friedly vient de sortir un portage du jeu sur Nintendo DS, et pas n'importe lequel, puisque celui-ci tourne sur la vraie console de 2004, et pas seulement sur la DSi qui embarquait quatre fois plus de mémoire vive. Et comme si ça suffisait pas, il y a même mis un mode deux joueurs.

C'est vrai que le truc qui coince d'habitude, c'est que la DS originale n'a pas assez de RAM pour charger toute la ROM du jeu d'un coup. Tobi a donc contourné le problème en faisant streamer les assets à la demande via NitroFS , le système de fichiers des cartouches DS.

Du coup, au lieu de tout balancer en mémoire d'un bloc, le jeu va piocher les niveaux et les textures au fur et à mesure qu'il en a besoin. C'est grâce à cette méthode ingénieuse qu'il a pu débloquer son portage sur la vraie DS, là où le portage précédent de Hydr8gon restait coincé sur DSi faute de place.

C'est d'ailleurs grâce au boulot de Hydr8gon que Tobi a construit le sien, en le modifiant et en l'adaptant suffisamment pour qu'il tourne sur tous les modèles de DS.

Au passage il a rebouché aussi deux bugs qui traînaient, et maintenant le jeu est finissable à 120 étoiles, et le son fonctionne enfin (avant c'était silence radio). La stabilité générale a aussi pris un bon coup de polish.

Le mode multijoueur, lui, réclame deux DS, chacune avec sa propre copie du jeu. C'est du coop local, parfait pour explorer le château à deux ou juste pour déconner ensemble, entre moustachus, dans un niveau de Mario.

Une équipe issue de l'université de Berkeley vient de publier OpenCAL, une version libre et documentée d'une technique d'impression 3D qui ne ressemble à rien de ce qu'on connaît, et le projet est désormais reproductible chez soi avec des composants qu'on trouve dans le commerce.

Le principe porte un nom un peu barbare, la lithographie axiale calculée (Computed Axial Lithography, ou CAL), mais l'idée derrière est étonnamment simple.

Une imprimante 3D classique à résine fabrique un objet en empilant des centaines de tranches horizontales, l'une après l'autre, comme on poserait des feuilles de papier les unes sur les autres jusqu'à obtenir un volume. C'est lent, et chaque couche laisse une petite marque parfois visible.

La CAL fait l'inverse. Au lieu de découper l'objet en strates, elle projette de la lumière dans un petit récipient de résine liquide qui tourne lentement sur lui-même, et l'image projetée change en permanence selon l'angle de rotation.

Cette technique reprend en fait le fonctionnement d'un scanner médical, mais à l'envers. Un scanner prend une multitude de clichés d'un corps sous tous les angles pour reconstituer une image en volume. Ici, on part de l'objet en 3D et un logiciel calcule toutes les projections à renvoyer dans la résine pendant qu'elle tourne.

Là où la lumière s'accumule suffisamment, la résine durcit. Partout ailleurs, elle reste liquide. Et comme le calcul concentre l'énergie sur l'ensemble du volume en même temps, la pièce entière se solidifie d'un coup, en quelques dizaines de secondes parfois, là où une imprimante normale mettrait de longues minutes voire des heures.

Pas de couches, donc pas de stries, pas de film FEP à changer (cette membrane transparente au fond des bacs à résine qui s'use vite), et aucun de ces cycles d'arrêt et de redémarrage qui ralentissent les machines habituelles.

La technologie n'est pas nouvelle, elle est née vers 2019 d'une collaboration entre Berkeley et le laboratoire de Lawrence Livermore, mais elle restait cantonnée à la recherche, hors de portée du grand public. C'est tout l'intérêt d'OpenCAL.

Le projet propose désormais une documentation tout à fait complète, un dépôt GitHub avec tout le code source, les plans pour monter la machine et même la recette pour mélanger soi-même la résine adaptée. Le logiciel tourne sur un simple Raspberry Pi et la lumière vient d'un vidéoprojecteur grand public, en l'occurence ici un NexiGo Nova Mini.

Le tout est publié sous licence GPL3, libre pour un usage non commercial, recherche et éducation. L'équipe travaillait surtout sur un serveur Discord avant de tout formaliser proprement.

Une réserve quand même, et elle est importante. La résine maison repose sur des produits photochimiques toxiques, et la documentation ne s'en cache pas. Pour ceux qui préfèrent éviter de manipuler ça, un partenariat avec FormLabs propose une résine prête à l'emploi.

Côté qualité, la résolution reste comparable à celle de vieilles imprimantes à résine, rien de spectaculaire. Mais la vitesse, elle, n'a rien à voir.

Bref, voir une technologie de labo digne d'un réplicateur de Star Trek atterrir sur un Raspberry Pi et un projecteur à moins de 200 euros, c'est quand même bien sympa.

Source : Hackaday

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

J'sais pas si vous avez vu, mais sur les Motorola Razr 2026, l'app maison Smart Feed intercepte le lancement de l'application Amazon pour y glisser en soumsoum un petit code d'affiliation. Comme ça, à chaque fois que vous tapez sur l'icône Amazon, votre clic se met à rapporter une commission à un compte tiers. Vous ne payez pas un centime de plus rassurez-vous, c'est le principe de l'affiliation, mais il me semble que c'est pas très réglo de ne pas le dire. En plus je pense que ça va à l'encontre des CGU d'Amazon... Breeeef, y'a rien qui va dans cette histoire.

Le truc se déclenche donc uniquement quand vous ouvrez Amazon le menu des applications, et pas depuis un raccourci sur l'écran d'accueil. A ce moment là, pendant une fraction de seconde, Chrome clignote à l'écran, et votre téléphone passe par un site nommé kira-abboud.com, pour ensuite utiliser un lien qui repart vers l'app Amazon avec le code d'affiliation sramz-kff-008-20 comme si de rien n'était. Comme ça Amazon, pense que vous arrivez de ce lien affilié.

C'est tellement rapide que la plupart des gens ne verront jamais rien....

Sauf que kira-abboud.com renvoie vers une influenceuse mode, @kirasfashionfinds présente sur Instagram, et qui n'a aucun lien apparent avec Motorola. Pire, le code d'affiliation collé à votre session ne correspond même pas à ceux qu'elle a déjà publiés. Et voilà comment on se retrouve avec un téléphone vendu par une grosse marque qui détourne vos clics vers un compte tiers, sans la moindre explication.

Côté technique, les logs réseau pointent vers devicenative.com. C'est une régie qui place de la pub sur les smartphones via un SDK intégré aux launchers Android, avec une intégration Motorola documentée. En clair, le mécanisme qui pourrit votre app Amazon pointe vers un kit publicitaire préinstallé d'usine.

Reste à savoir maintenant si c'est un choix assumé de Motorola ou un SDK pub qui part en vrille, voire un hack... et pour l'instant, personne ne le sait.

Riley Testut et Shane Gill viennent de sortir une bêta d' AltStore Classic (la 2.3b1 ), qui supprime enfin le besoin d'avoir un ordinateur pour sideloader des apps sur iPhone. AltStore, pour ceux qui débarquent, c'est la boutique alternative qui installe des apps qu'Apple ne veut pas sur son store, sans jailbreak et pour l'utiliser jusqu'ici, il fallait garder un Mac ou un PC allumé avec AltServer pour réinstaller vos apps tous les 7 jours.

Mais maintenant, une simple connexion Wi-Fi suffit !!

Pour s'en servir, vous allez dans les réglages d'AltStore Classic et vous renseignez l'URL d'un "serveur anisette" et hop, l'app se mettra à causer directement aux serveurs d'Apple pour signer et rafraîchir vos installations, sans passer par AltServer. Pour l'instant c'est réservé aux AltStore Patrons (les abonnés Patreon), avec un déploiement grand public prévu une fois la bêta stabilisée.

L'anisette, c'est la donnée d'authentification que les serveurs d'Apple exigent pour valider une demande de signature. Avant, AltServer la générait depuis votre ordinateur, d'où l'obligation de l'avoir sous la main. En déportant ça sur un serveur anisette distant, AltStore se débrouille maintenant tout seul depuis le téléphone.

C'est bien pensé ! Du coup le refresh hebdomadaire se fait en silence, et gérer le plafond de 3 apps imposé par Apple devient indolore même si cette limite des 3 apps reste...

SideStore , un fork open source d'AltStore, fait du sideloading sans ordinateur depuis un bon moment, en montant un VPN WireGuard local qui fait croire à l'iPhone qu'un ordi est branché, donc oui c'est vrai, AltStore Classic arrive un peu après la bataille mais avec une approche différente, ce serveur anisette plutôt que le VPN.

Mais ces serveurs anisette, faut bien que quelqu'un les fasse tourner et quand ils tombent, votre sideloading tombe avec.... Les habitués de SideStore connaissent bien la chanson. Vous pouvez bien sûr héberger le vôtre si vous êtes du genre à bidouiller, mais sinon vous dépendrez d'un serveur communautaire... et de sa bonne santé.

Tout cela permet de reprendre un peu la main sur un iPhone qu'Apple a tenu verrouillé à double tour depuis bien trop longtemps. C'est grâce à ça que pas mal de gens peuvent aujourd'hui installer des émulateurs à l'ancienne comme Provenance , ou que la pression a fini par pousser Apple à accepter les émulateurs rétro sur son propre store.

Bref, si vous êtes Patron AltStore et sous iOS 17.4 ou plus, vous pouvez tester dès maintenant. Sinon, encore un peu de patience...

Source

Vous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?

Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.

Allez, petite démonstration récente... Sur le repo no-as-a-service , il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".

Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...

Pourquoi Git laisse passer ça

Git, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.

Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.

Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.

Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)

Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :

# 1. Visualiser un commit cible pour récupérer name + email
git log --format='%an <%ae>' | head -3

# 2. Reconfigurer Git avec une fausse identité
git config --global --replace-all user.name "Linus Torvalds"
git config --global --replace-all user.email "[email protected]"

# 3. Vérifier la config
git config --global --list | grep user

# 4. Faire un commit normal
echo "Hello from Linus" >> README.md
git add README.md
git commit -m "Important kernel fix"

# 5. Pousser sur votre repo
git push origin main

Allez voir le commit sur GitHub. Vous verrez l'avatar de Linus, son nom cliquable qui mène vers son profil, et surtout aucun avertissement. Pas de mot de passe demandé ni de token compromis... non, non, non, c'est juste une config locale modifiée.

Et si quelqu'un fait un fork de votre repo, ou si un mainteneur peu attentif valide un PR sur cette base, l'illusion est complète.

Étape 2 : Repérer un commit douteux

Pour ça, le badge Verified reste l'indicateur le plus utile. À côté du SHA d'un commit, GitHub affiche surtout une étiquette verte "Verified" si le commit est cryptographiquement signé avec une clé GPG ou SSH enregistrée sur le compte de l'auteur. Sinon, y'a rien du tout (par défaut). Attention quand même, l'absence de badge ne veut pas dire qu'un commit est malveillant mais juste qu'on ne peut pas garantir qui l'a écrit.

Par exemple, si vous regardez le commit e6b4218 sur no-as-a-service, vous remarquerez l'absence totale de badge. C'est le signal mais il faut encore savoir le chercher car par défaut, GitHub n'affiche AUCUN avertissement pour les commits non signés. C'est surtout ça le problème...

Étape 3 : Signer vos commits avec SSH

Alors pour vous protéger de ça, ça commence chez vous. Plus simple que GPG, la signature SSH utilise une clé que vous avez probablement déjà. Générez une clé Ed25519 si ce n'est pas fait :

ssh-keygen -t ed25519 -C "[email protected]"

Configurez Git pour signer automatiquement avec cette clé :

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

Dernière étape, ajoutez votre clé publique sur GitHub dans Settings → SSH and GPG keys (1), mais cette fois en sélectionnant le type Signing Key (pas Authentication Key, c'est différent) (2). Vos prochains commits afficheront le badge "Verified" en vert.

Si vous préférez GPG, le principe est identique avec gpg.format gpg et une clé GPG. Pour le détail GPG complet, j'avais déjà couvert le sujet dans le tuto sur Thunderbird et GPG .

Étape 4 : Activer Vigilant Mode

Là, on passe à l'offensive. Vigilant Mode (3) force GitHub à afficher un statut sur tous vos commits. Les signés deviennent "Verified", les non signés deviennent "Unverified" en gros et bien visible. Plus de zone grise comme ça.

Direction même endroit dans Settings → SSH and GPG keys → Vigilant mode → Flag unsigned commits as unverified. Cochez la case. À partir de là, n'importe quel commit que GitHub vous attribue (via votre email vérifié) sans signature sera affiché comme "Unverified", ce qui rend le spoofing beaucoup plus difficile à dissimuler. Petite limite par contre, ça ne protège que votre propre identité et pas celle des contributeurs qui n'ont pas activé le mode.

La position de GitHub (et pourquoi je trouve ça discutable)

GitHub considère ce comportement comme un non-bug. Sur leur page bug bounty, l'usurpation par email Git est explicitement listée comme ineligible. Leur argument c'est que ça ne donne pas accès aux repos ni de privilèges supplémentaires, donc ce n'est pas une faille au sens strict.

Sauf que dans la vraie vie, l'identité affichée influence les décisions. Par exemple, un mainteneur qui voit un PR signé d'un contributeur connu va l'examiner avec moins de paranoïa, un journaliste qui couvre un scandale va citer "le commit de tel développeur" sans vérifier la signature, et combiné à d'autres vecteurs, ça peut devenir redoutable ! Je pense surtout aux attaques supply chain récentes type Shai-Hulud où une fois le code piégé, l'attribution Git aide à le faire passer pour légitime.

Bref, dire "ce n'est pas un bug" parce qu'il faut un autre vecteur derrière, c'est un peu facile, je trouve. Voilà, donc ne comptez pas sur Github pour vous défendre et signez vos commits, activez Vigilant Mode, et apprenez à vos collègues et amis dev à vérifier le badge "Verified" avant de merger quoi que ce soit en venant d'un inconnu... même si c'est ce bon cher Linus qui propose de réécrire le kernel en Rust avec systemd intégré ^^.

Source

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à !

DOOM, Fallout, Theme Hospital, Civilization... il y a sur le web des milliers de jeux DOS jouables directement dans votre navigateur, gratuitement, sans installer quoi que ce soit. Car oui mes amis, l'émulation DOS dans le browser a vraiment mûri, et il existe des dizaines de bons sites qui vous permettent de jouer à tout un tas de jeux disparus. Je vous propose donc une bonne dizaine d'entre eux classés par ordre alphabétique.

Mais avant, faut savoir que tous fonctionnent plus ou moins sur la même base. C'est du DOSBox compilé en WebAssembly pour tourner dans un onglet de votre navigateur et ensuite la différence entre tous ces sites se joue sur leur catalogue, la légalité du contenu qu'ils proposent, et quelques fonctionnalités bien pensées. (Si vous cherchez plutôt à faire tourner des vieux .exe Windows, RetroTick fait ça très bien aussi.)

On commence par Best DOS Games le petit nouveau sorti en 2023 qui compte déjà +900 jeux et 50 000 joueurs. Ce qui le démarque surtout ce sont ses fonctionnalités de sauvegarde cloud et de Hall of Fame communautaire si vous avez un compte. C'est un super site très agréable à utiliser au quotidien notamment grâce à son interface.

Best Old Games , lui, dépasse volontairement le cadre des jeux DOS : SNES, Commodore 64, arcade, ZX Spectrum, Master System... Il est ligne depuis 2004, couvre +600 titres sur 9 plateformes, et tous les jeux sont disponibles en téléchargement ou à jouer directement en ligne. L'angle abandonware est d'ailleurs totalement assumé, par contre, certains titres n'ont pas encore de version jouable en ligne. Ce sera donc uniquement du téléchargement pour cela. Hyper pratique donc si votre nostalgie du gaming ne s'arrête pas à MS-DOS, mais un peu fourre-tout.

DOS Games Archive pousse la philosophie de préservation depuis 1998, avec 1 641 jeux répartis dans 17 catégories. Le site dispose d'un blog et d'un forum toujours très actifs et il propose uniquement du contenu légal (shareware, freeware, domaine public). Le truc bien vu ce sont surtout ces liens directs vers GOG pour les titres dont vous voudriez acheter la version commerciale complète. Par contre, pas de sauvegardes cloud... chaque session repartira de zéro si vous quittez votre partie. Mais c'est la référence pour jouer "proprement".

DOS Zone est de loin le plus complet et le plus moderne du lot. Plus de 2 000 titres MS-DOS, sans pub, avec support mobile et mode hors-ligne. La techno derrière s'appelle js-dos, qui une implémentation DOSBox compilée en WebAssembly. Et tenez vous bien, le site vous propose également un Game Studio pour créer et publier vos propres jeux DOS directement depuis le navigateur. Y a de quoi y passer des heures !!

DOSGames.com c'est le vétéran de la scène ! Ce site est en ligne depuis janvier 1999, bien avant YouTube, Twitter ou Facebook ! Il a été fondé par Darren Hewer qui voulait sauvegarder tous ces titres DOS "devenus difficiles à trouver" à l'époque. Il propose plus de 2 300 jeux shareware et freeware légaux. L'interface a un peu vieilli (comme nous tous ^^) mais 25 ans de fidélité au poste, ça force le respect !

L'Internet Archive n'est pas à proprement parler un site de jeux puisque c'est le projet de préservation numérique le plus ambitieux de la planète. Mais je ne pouvais pas faire l'impasse dessus car leur collection MS-DOS regroupe aussi des milliers de titres jouables directement dans votre navigateur, gratuitement et sans pub. Après, je trouve que l'interface est moins bien taillée pour le gaming que d'autres sites. Par contre pour dénicher un titre introuvable ailleurs, c'est le top !

MyAbandonware c'est un autre site d'abandonware de référence mondiale avec +37 000 jeux couvrant DOS, Windows, Amiga, Mac, Atari et bien d'autres plateformes. Il y a donc beaucoup de titres DOS qui sont jouables directement dans le navigateur, mais le site reste avant tout une encyclopédie du jeu rétro avec des fiches complètes : screenshots, année, éditeur, manuel...etc. Y'a tout !!! Donc c'est super précieux si vous voulez comprendre l'histoire d'un vieux titre en plus de le faire tourner.

PlayDOSGames.com lui est plus modeste et propose 655 jeux réparti dans 18 catégories, avec, s'il vous plait, de la sauvegarde dans le cloud ! Vous commencez une partie ici, et hop, vous la continuez ensuite depuis votre téléphone ou un autre ordi. Créé en 2013, et dispo en 10 langues, ce n'est donc pas le plus gros catalogue, mais c'est le meilleur pour jouer en mode nomade.

RGB Classic Games est aussi plutôt modeste puisqu'il ne propose que 565 titres, mais chaque version de chaque jeu est archivée. Le site est en ligne depuis mars 2005, et couvre aussi BeOS, que OS/2, Win16 et d'autres systèmes d'exploitation plus en marge. La plupart des titres sont à télécharger et pas à jouer en ligne donc si c'est pour passer le temps au taf, dans le navigateur sans install, laissez tomber. Mais pour les puristes qui veulent une release bien précise, c'est là qu'il faut aller !

Et puis on a WePlayDOS qui organise son catalogue par saga : Oregon Trail, Civilization, Zork, DOOM, Warcraft... Je trouve que c'est une idée intelligente pour explorer une franchise plutôt que de chercher un titre précis à chaque fois. Après le catalogue est petit donc si votre jeu n'est pas dans une saga connue, y'a des chances que vous repartiez brocouille (vous l'avez ?). Mais pour de la découverte par série, carrément bien pensé.

Voilà, j'ai fait le tour ! Et si vous préférez avoir les jeux en local plutôt que dans le navigateur, n'oubliez pas que Retro-eXo regroupe plus de 10 000 titres DOS et Windows prêts à tourner également !

Pour ma part, j'ai opté pour dos.zone et Best DOS Games car je trouve que ce sont les plus riches en fonctionnalités. Mais si vous voulez de l'archive sérieuse, DOSGames.com ou DOS Games Archive conviendra mieux ! Et si votre truc c'est le multi-écrans, PlayDOSGames fera très bien le job.

Jouez bien !

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

Vincent en avait parlé il y a peu : Firefox 149 embarque maintenant discrètement adblock-rust , le moteur Adblock de Brave, désactivé par défaut et contrôlé uniquement par deux prefs dans about:config.

A l'origine, je vous avais parlé d'une extension mais après analyse plus approfondie, celle-ci n'est pas vraiment nécessaire. Y'a juste deux valeurs à coller dans about:config et le moteur tourne. Merci donc à François qui m'a indiqué cette méthode directe.

Étape 1 : Activer le moteur

Dans la barre d'adresse, tapez about:config et acceptez l'avertissement. Cherchez la préférence suivante :

privacy.trackingprotection.content.protection.enabled

Passez-la à true. Si elle n'existe pas encore dans votre profil, créez-la : clic droit quelque part dans la liste → Nouveau → Booléen.

Étape 2 : Charger vos listes de filtres

Cherchez ensuite cette seconde préférence :

privacy.trackingprotection.content.protection.test_list_urls

Collez-y la valeur suivante, toutes les URLs séparées par des pipes :

https://easylist.to/easylist/easylist.txt|https://easylist.to/easylist/easyprivacy.txt|https://secure.fanboy.co.nz/fanboy-cookiemonster.txt|https://raw.githubusercontent.com/uBlockOrigin/uAssets/refs/heads/master/filters/annoyances-others.txt|https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_2_Base/filter.txt|https://raw.githubusercontent.com/uBlockOrigin/uAssets/refs/heads/master/filters/filters.txt|https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_3_Spyware/filter.txt|https://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblockplus&showintro=1&mimetype=plaintext

Ça couvre 8 listes : EasyList, EasyPrivacy, Fanboy Cookie Monster, uBO Annoyances (les 4 de base), plus uBO Filters, AdGuard Base, AdGuard Tracking et Peter Lowe. Si vous voulez un profil plus léger, vous pouvez supprimer des URLs avant de coller.

Petite note : le préfixe test_ dans le nom de cette pref indique que la feature est encore expérimentale dans Firefox 149. Les noms peuvent donc changer dans une version future.

Désactiver ETP (optionnel mais recommandé)

La protection contre le pistage intégrée de Firefox (ETP) et adblock-rust filtrent chacun de leur côté. C'est redondant. Pour désactiver ETP, allez dans about:preferences → Confidentialité et sécurité → Protection renforcée contre le pistage → cochez "Personnalisée", puis décochez tout ce que vous voulez confier à adblock-rust.

Limitation actuelle : adblock-rust ne gère pas encore les sélecteurs CSS de masquage d'éléments, les règles ## du style uBlock Origin. Brave les supporte déjà, Firefox devrait suivre. En attendant, quelques pubs que uBO cachait via CSS resteront visibles.

Pour le contexte technique complet sur l'intégration de ce moteur, allez lire l'article de Vincent sur l'arrivée discrète d'adblock-rust dans Firefox 149 . Et si vous voulez un guide général pour bloquer les pubs et trackers sur le web , c'est par là.

Merci à François pour la méthode et la liste de filtres !

Le BME280 et le DHT22, deux capteurs ultra-populaires en domotique, ont une faiblesse cachée dans leur spécifications : ils ne supportent pas la condensation. Les gens de Mellow Labs ont creusé la question sur Hackaday après avoir flingué plusieurs sondes dans une salle de bain, et le coupable est marqué noir sur blanc dans les caractéristiques du produit, « non-condensing humidity »…

Le souci tient en fait à la physique du truc. Quand l'humidité relative dépasse les 100%, l'air saturé en vapeur d'eau rencontre une surface plus froide, et l'eau se condense en gouttelettes.

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 !

Bon, les amis, si vous utilisez Tor Browser pour faire du sérieux, faut que vous sachiez un truc. Le bouton "New Identity", censé vous donner une nouvelle identité vierge à chaque clic... bah il laissait filer, jusqu'à il y a peu de temps, un identifiant stable tant que Firefox tournait.

Deux chercheurs de Fingerprint ont en effet trouvé comment une fonction toute bête du navigateur se transformait en empreinte unique de votre browser, partagée entre tous les sites que vous visitiez.

Il faut donc dès à présent faire la mise à jour vers Firefox 150 ou l'ESR 140.10.0 (la version long-terme utilisée par Tor Browser), ainsi que la dernière version de Tor Browser qui récupère le patch. Si vous voulez en savoir plus, la CVE c'est CVE-2026-6770 , classé comme sévérité modérée par Mozilla.

Le truc marche en vase clos mais traverse les murs.

Mais avant, IndexedDB c'est quoi ?

En gros c'est une mini-base de données que les sites web peuvent créer dans votre navigateur, pour stocker des trucs en local (du cache, des données offline, l'état d'une app web). Chaque site peut y ranger plusieurs bases nommées, et une petite fonction JavaScript indexedDB.databases() permet au site de demander la liste de ses bases.

Rien de foufou sur le papier. Sauf que dans Firefox en navigation privée, le navigateur renomme en coulisse chaque base avec un identifiant aléatoire (UUID), et range tout ça dans une seule grosse table interne. Et le gros problème, c'est que cette table est partagée entre tous les sites ouverts, et pas cloisonnée site par site.

Et là, ça devient croustillant puisque quand un site redemande la liste de ses bases, Firefox la renvoie sans la trier, dans un ordre qui dépend de la structure interne de cette table partagée. Du coup, deux sites totalement différents qui créent chacun seize bases dans le même ordre récupèrent exactement la même suite en retour. Pas l'ordre de création donc mais une permutation bizarre, genre g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k.

Je vous passe les détails mais ça fait dans les 17 000 milliards de combinaisons possibles. Donc largement de quoi distinguer votre navigateur parmi des millions, comme une empreinte digitale qui colle au doigt !

Et ce qui pique vraiment c'est que cet identifiant survit à la fermeture de toutes vos fenêtres privées. Tant que le process Firefox tourne en arrière-plan, l'ID reste. Un site peut donc vous reconnaître après que vous ayez fermé vos onglets privés, rouvert une session pensée comme neuve, et revisité le site. Pour le user, c'est une session fraîche alors que pour le serveur c'est clairement le même navigateur qu'il y a dix minutes.

Côté Tor Browser c'est pire puisque le bouton "New Identity" a pour mission explicite de couper tout lien avec ce que vous faisiez avant. Il ferme les onglets, efface l'historique, vide les cookies, tire de nouveaux circuits Tor. La promesse officielle, c'est "empêcher votre activité future d'être liée à ce qui précède".

Sauf que cette fameuse table interne, elle, ne bouge pas. Le New Identity reset donc tout sauf ce qu'il ignore. C'est comme changer de fringues dans le même ascenseur... en gardant le même parfum. Techniquement vous êtes différent, mais reconnaissable en deux secondes. Bref, c'est assez grave car un site capable d'exploiter la faille peut lier votre session avant-New-Identity à votre session après-New-Identity.

Tant qu'on n'a pas redémarré Firefox complètement, l'ID persiste.

Les chercheurs disent avoir fait une divulgation responsable, directement à Mozilla et au Tor Project avant publication donc c'est nickel, et les deux équipes ont poussé les patches avant de communiquer sur quoi que ce soit. Donc les utilisateurs à jour sont tout simplement protégés contre cette faille précise.

Après si vous êtes du genre parano, pensez à redémarrer complètement votre Tor Browser entre deux sessions vraiment sensibles. Ça coupe le process Firefox, ça vide cette fameuse table, et ça évite ce genre de surprise pour d'autres leaks similaires qu'on n'aurait pas encore trouvés.

A bon entendeur, salut !!

Source