Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Hier — 5 mai 2026Korben

10 sites pour jouer aux jeux DOS dans votre navigateur gratuitement

Par : Korben ✨
5 mai 2026 à 13:44

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 !

Il démonte une caméra gimbal de drone Shahed-136 récupéré en Ukraine

5 mai 2026 à 12:11

Un chercheur du nom de Michel a mis la main sur une caméra de surveillance issue d'un drone Shahed-136 abattu en Ukraine, et il en a fait un démontage très complet.

Le Shahed-136, ce drone iranien que la Russie a adopté massivement et qu'elle modifie au fil des mois avec des charges utiles supplémentaires, embarque ici une caméra thermique pour les missions de nuit, montée sur un gimbal motorisé, le tout dans un boîtier qui tient dans la main.

Ce qui frappe quand on regarde l'intérieur, c'est l'origine des pièces. Vous avez deux cartes basées sur un FPGA Artix-7, plus un SoC Hi3519 qui s'occupe du flux vidéo. Le Hi3519, c'est un composant chinois qu'on trouve sans peine sur AliExpress et qui équipe une bonne partie des caméras IP grand public.

Ajoutez à ça une carte d'alimentation commerciale, une carte relais classique, un télémètre, et vous avez un assemblage qui ressemble plus à un projet maker qu'à du matériel militaire.

Côté gimbal, le constat est encore plus parlant : la majorité des composants sont occidentaux. Les marquages laser ont été soigneusement grattés ou poncés pour effacer la traçabilité, mais les pièces restent identifiables au format.

C'est cohérent avec ce qu'on voit depuis le début du conflit, avec ces drones russes bourrés de puces Texas Instruments, Analog Devices, STMicroelectronics ou Infineon censées ne jamais finir dans une arme.

Ce qui est fou dans cette histoire, c'est le contraste avec les missiles russes plus haut de gamme, où les ingénieurs partent de circuits sur mesure et de composants militarisés. Ici c'est plus simple. Du dev board reconverti et du off-the-shelf, sans doute parce que produire un Shahed à 50 000 dollars la pièce ça oblige à raboter partout, et que personne ne va concevoir une carte custom pour un drone qui se crashe par définition.

Source : Hackaday

Un slider caméra à trois axes bricolé avec des pièces d'imprimante 3D

5 mai 2026 à 11:25

Un slider caméra, c'est ce rail motorisé sur lequel on pose un appareil photo ou une caméra pour qu'elle glisse latéralement pendant la prise de vue, et obtenir ce travelling propre qu'on voit dans les pubs ou les vidéos YouTube un peu soignées.

CNCDan , lui, a voulu pousser le concept un cran plus loin avec un système à trois axes (haut/bas, gauche/droite, et une rotation), pour filmer ses propres projets. Et il l'a construit avec ce qu'il avait sous la main : un stock de pièces d'imprimante 3D.

Pourquoi ça marche bien comme base ? Les imprimantes 3D sont conçues autour de composants modulaires et standardisés (profilés aluminium extrudés, courroies, moteurs pas-à-pas, électronique), le genre de pièces taillées pour bouger une tête d'impression de quelques kilos avec précision. C'est exactement ce qu'on demande à un slider, sauf qu'à la place de l'extrudeur on met une caméra.

La logique tient debout. Mais CNCDan a vite découvert que ses moteurs n'étaient pas assez puissants pour bouger une caméra de 1,4 kg sans saccades, ce qui l'a obligé à revoir les rapports de réduction (le gearing) pour leur donner plus de couple.

Sauf que voilà, en touchant aux moteurs il a déréglé tout le reste. Cotes qui ne tombent plus juste, jeux qui apparaissent, plateforme qui ne tient plus en place. Du coup il a dû reprendre une grosse partie de la mécanique : nouvelle plaque de support découpée dans de l'acier (l'alu n'était pas assez rigide pour cette charge), nouveaux roulements montés à la presse, et un système de quick release pour fixer la caméra rapidement.

Et même comme ça, le mouvement n'était toujours pas fluide. Plusieurs semaines de réécriture du code de pilotage des moteurs ont été nécessaires pour obtenir une glisse vraiment propre.

Le résultat final tient la route. Le slider fonctionne sur une carte ESP32 et se pilote en Wi-Fi via une interface web ouverte depuis un autre ordi. 

CNCDan a aussi prévu que sa plateforme puisse accueillir d'autres caméras, y compris des smartphones, et il a publié les fichiers du projet sur GitHub si vous voulez reproduire la chose.

Lui-même reconnaît que ce n'était clairement pas la voie la plus simple pour avoir un slider, mais que ça lui a marché parce qu'il avait les pièces et les outils déjà chez lui.

Bref, du vrai DIY audacieux. Pas la solution la plus rapide, mais quand on a déjà l'atelier, c'est une chouette approche.

AlmaLinux 10.2 Beta réintroduit le support 32-bit, à contre-courant

5 mai 2026 à 09:17

La distribution AlmaLinux a publié sa version 10.2 Beta nommée "Lavender Lion", et elle fait un truc que la plupart des distros récentes refusent de faire : remettre du support 32-bit dans le système. 

Pas un retour total, on s'entend, mais des packages userspace i686 pour faire tourner du logiciel ancien, des pipelines de CI un peu datées et des conteneurs qui dépendent encore de bibliothèques 32-bit. Pas d'ISO d'install i686, ça reste enterré pour de bon. Mais bon, vos vieux binaires repartent sur un x86_64 propre.

C'est intéressant parce que Red Hat a clairement tranché de l'autre côté avec RHEL. Plus de support 32-bit, plus de x86-64-v2 sur la version 10, c'est marche ou crève. AlmaLinux, qui se positionne comme rebuild compatible RHEL, prend un chemin un peu différent en disant : on garde la compat mais on rajoute des trucs qui rendent la vie plus simple aux entreprises avec du legacy à maintenir. Y'en a beaucoup.

Côté nouveautés plus classiques, vous récupérez Python 3.14, PostgreSQL 18, MariaDB 11.8, Ruby 4.0 et PHP 8.4 dans les packages, plus SDL3, libkrun et le tooling FIDO Device Onboard. La beta intègre aussi déjà le patch pour la vulnérabilité Copy Fail (CVE-2026-31431), ce qui veut dire que les équipes d'AlmaLinux suivent vraiment de près les correctifs amont, sans attendre la stable pour les pousser.

Le truc à retenir, c'est qu'AlmaLinux est en train de devenir le RHEL "raisonnable" pour les boîtes qui ont du parc informatique vieillissant. 

Pendant que Red Hat optimise pour ses futurs gros clients cloud, AlmaLinux ramasse tous les autres : ceux qui ont encore une appli métier en 32-bit, ceux dont les serveurs ne valident pas x86-64-v3, ceux qui veulent juste que ça marche sans réécrire la moitié de leur stack.

Bref, choisir AlmaLinux plutôt que RHEL ressemble de plus en plus à une décision pragmatique.

Source : Phoronix

Korben - Toujours là 22 ans plus tard, et c'est grâce à vous

Par : Korben ✨
5 mai 2026 à 09:07

Salut les amis,

Aujourd'hui, c'est un jour un peu spécial pour moi, puisque c'est l'anniversaire de mon site web ! Alors je tenais à célébrer ça avec vous parce que les années filent à la vitesse de l'éclair et qu'on ne fête jamais assez les choses.

Et il s'en est passé des choses en 22 ans quand même. J'ai démarré ça comme un site perso, et qui, parce que les gens aiment bien ranger les trucs dans des cases, est devenu un "blog", puis un "média", et qui sait ce que ce sera demain...

Mais pour moi, c'est toujours mon petit bout de moi sur le web et l'objectif est toujours le même : Partager les trucs qui m'intéressent pour vous donner de quoi bidouiller à la maison ou au boulot. Toujours pas de ligne éditoriale claire, parfois de l'actu, parfois des tutos, parfois des reviews de logiciels, parfois des trucs plus perso... Peu importe tant que ça me plait.

Sachez qu'en 2025, j'ai publié environ 1300 articles sur ce site. C'est beaucoup mais moins qu'en 2011 et 2012 où j'étais à +1400 par an. Et en 2008, aïe aïe, record du monde avec +1600 articles dans l'année. C'était une époque où j'avais du temps et surtout où il se passait pas mal de choses au niveau tech. Envie de tout tester, de toucher à tout, et de tout vous raconter ! Comme aujourd'hui finalement !

Et en 2026, malgré quelques moustiques qui tentent de me faire dérailler, ça va être encore plus riche puisque j'ai délégué une partie de "l'actu fraiche" à mon ami Vincent qui fait un boulot top ! L'objectif est de me libérer un peu de temps pour à la fois mettre un point final aux combats actuels dans lesquels mon site se trouve depuis 6 mois (et dont je ne peux malheureusement pas vous parler mais ça viendra) et également avoir plus de temps pour la bidouille et les Patreons qui me soutiennent ! Je leur suis tellement reconnaissant !

Depuis 2004, tout a évolué c'est vrai. Le paysage tech a changé, les sujets d'intérêts des uns et des autres ont évolué (je l'espère pour vous ^^), et moi-même je m'intéresse à de nouvelles thématiques. En 2004 c'était comment optimiser eMule, comment installer Ubuntu et des astuces de base de registres Windows... En 2026, c'est plutôt comment faire tourner ses propres IA en locale, comment auto-héberger tel ou tel truc, ou encore comment se mettre en sécurité suite à la découverte de telle ou telle faille de sécurité...etc.

Et je sais qu'il y en a parmi vous qui sont là depuis le tout début. Vous m'avez vu changer 2 fois de CMS, je-sais-plus-combien de fois de design, plusieurs fois d'hébergeur, passer de la bannière pub omniprésente à un site sans aucune pub programmatique...etc. Vous vous reconnaitrez et cet anniversaire, c'est autant le vôtre que le mien !

Je continue aussi à vous en proposer pour tous les goûts... Des articles vulgarisés pour les débutants, des tutos plus complexes pour les gens + confirmés, et des choses qui peuvent parfois intéresser 15 000 personnes ou n'en intéresser que 4 ou 5... Peu importe. Ma boussole ce sont les retours que vous me faites par mail ou via le Patreon, et le seul filtre que je m'impose est "Est ce que ça m'intéresse ?". Parce qu'il n'y a rien de plus chiant que d'écrire sur un sujet qui ne m'intéresse pas. C'est pour ça que je ne traite pas de TOUTE l'actu tech qui passe... Je "cherry pick" comme on dit, que ce qui me plait et basta.

Et ça semble plutôt fonctionner puisque l'audience est au rendez-vous. Vous êtes en effet depuis le début de l'année entre 1,5 et 2 millions à passer ici chaque mois.

Je mets ça sur le compte de la refonte technique du site qui est + rapide, + agréable à lire (mode sombre, mode dys, etc.), sans bannière pub ni cookies publicitaires mais aussi sur l'augmentation du nombre d'articles grâce à Vincent et grâce à mes problèmes actuels qui m'empêchent de dormir et qui font que je me réfugie dans le boulot. Et il y a aussi l'arrivée des LLM qui m'ont permis de gagner du temps sur la recherche d'information, sur ma propre compréhension de certains sujets, sur des aspects plus pratiques comme la relecture, la validation des infos, la saisie des méta données, les images et j'en passe...

Grâce à ça, je fais moins d'impasses, je dis moins de conneries, je peux rentrer plus dans certains détails qui autrefois m'auraient échappé...etc. Je suis plus dans une recherche de qualité et de consistance dans mes articles que de productivité (j'sais pas si je battrai mon record de 2008 ^^). Et évidemment, ça a un impact... Des articles plus fouillés et moins fouillis, un meilleur référencement naturel et surtout, des lecteurs qui reviennent parce qu'ils découvrent des trucs.

Bien sûr, tout n'est pas parfait et ça ne le sera jamais mais je pense que j'ai trouvé un bon équilibre avec ces nouveaux outils.

Maintenant les bases restent les mêmes qu'en 2004... Un site ouvert, avec un flux RSS complet, sans paywall, sans article réservé aux abonnés, sans newsletter premium. Tout est ici, pour tout le monde, gratuit, indexable, citable. Le Patreon existe en parallèle pour celles et ceux qui veulent un peu plus (et surtout pour me soutenir directement, ce qui me touche énormément), mais 100% de ce qui est publié sur korben.info est accessible librement. C'était une évidence en 2004, et c'est resté un choix en 2026.

Je sais que le site ne plaît pas à tout le monde et c'est OK. 22 ans à publier presque tous les jours, forcément ça intrigue, ça énerve, ça incite même parfois à m'inventer une vie ou des anecdotes à mon sujet. Mais bon, c'est le revers de la médaille et si tout le monde était d'accord avec moi, ce serait pas drôle. Donc tant pis pour ceux que j'irrite, et merci à ceux qui me lisent encore... y compris en cachette ^^.

Après j'ai pas de grand plan pour la suite. Pas de roadmap, pas de pivot, pas de levée de fonds, pas de série documentaire sur ma vie. Juste l'envie de continuer à faire ce que je fais depuis 22 ans : Chercher des trucs qui m'intéressent, les tester, les comprendre et vous les raconter. Et même s'il ne se passe pas une journée où je ne me pose pas la question de tout arrêter, et bien je continue parce que j'adore ça.

Merci d'être là !

Edge - Les mots de passe en clair en mémoire, by design

Par : Korben ✨
5 mai 2026 à 09:06

Si vous utilisez le gestionnaire de mots de passe intégré à Microsoft Edge, et que vous le trouvez cool, hé bien accrochez-vous les amis, car Tom Jøran Sønstebyseter Rønning, chercheur norvégien en cybersécurité, vient de publier sur GitHub un PoC qui dump TOUS vos credentials en clair directement depuis la mémoire du processus du navigateur ! Et de ce que j'ai compris, Microsoft a l'air d'assumer ça tranquillou...

Et n'allez pas croire qu'activer "l'Authentification avant remplissage automatique" dans Edge règle le souci... Ça ne change absolument RIEN au problème, parce que les credentials sont chargés en clair en RAM dès l'ouverture du navigateur. Cette option bloque uniquement l'interface, et pas la mémoire. La seule vraie parade, c'est donc de basculer carrément vers un gestionnaire de mots de passe comme Bitwarden, KeePassXC, ou Mistikee car tant qu'ils restent verrouillés, ils ne chargent rien en mémoire.

Le PoC, baptisé EdgeSavedPasswordsDumper, tient en un seul fichier C#. Tom a choisi .NET Framework 3.5 plutôt qu'une version récente, parce que AMSI, l'Antimalware Scan Interface qui inspecte en temps réel le code .NET sous Windows, a une couverture vraiment réduite sur la 3.5 par rapport aux versions modernes. Du coup, le binaire passe plus facilement sous les radars des EDR et antivirus.

Maintenant, le truc, c'est que ce sujet n'est pas nouveau. En effet, en juin 2022, Zeev Ben Porat de chez CyberArk publiait déjà un papier détaillant exactement la même méthode appliquée à Chromium en général (et dont Edge découle...). Il utilisait les APIs Windows OpenProcess et ReadProcessMemory pour lire la mémoire privée des processus du navigateur et y récupérer URLs, logins, mots de passe et même cookies de session. Et à l'époque, Microsoft et Google avaient répondu en gros pareil, à savoir que c'était hors du "threat model", donc que c'était pas la peine de corriger.

Sauf que 4 ans plus tard, Tom Rønning n'arrivait pas à reproduire le dump sur Chrome avec la même méthode. En effet, le navigateur de Google semble charger ses credentials de façon plus granulaire (lazy loading, déchiffrement au besoin) plutôt que tout exposer en RAM dès l'ouverture. Alors que Edge, lui, n'a pas évolué et charge encore TOUS les credentials en clair dès le démarrage du navigateur, qu'on en ait besoin ou pas, et surtout les garde en mémoire tant que le processus parent tourne. Et c'est cette différence-là que Tom met en lumière avec son outil.

Après concernant la dangerosité de ce problème, faut que je nuance un peu tout ça car pour viser sa propre session Edge, l'attaquant n'a pas besoin d'être admin (un malware tournant sous votre compte y arrivera). Par contre, pour aller lire la mémoire des AUTRES utilisateurs sur la même machine, là, il faut les droits administrateur.

Et c'est surtout ce scénario que Tom met en avant dans son README. Il y parle d'un terminal server où plusieurs utilisateurs seraient connectés simultanément via RDP, et sur lequel un admin compromis pourrait dumper les mots de passe de tous les autres avec leur Edge ouvert, y compris les sessions déconnectées tant que le processus parent tourne. C'est assez spécifique quand même mais pas impossible évidemment...

Microsoft, contacté par Tom avant publication, a bien sûr répondu que le comportement était "by design"... Leur doc Edge enterprise explique même noir sur blanc que les attaques physiquement locales et les malwares sont hors du modèle de menace et qu'aucun navigateur n'est armé pour résister à un attaquant déjà infiltré dans le compte utilisateur.

C'est cohérent c'est vrai... Mais ça occulte un truc qui reste très "gênant" comme disent les ados. C'est que leur implémentation expose une surface d'attaque plus large que leurs concurrents basés sur le MÊME moteur Chromium. C'est pas normal....

Et côté communauté, ça n'a pas trainé non plus, puisque Whitecat18 sur GitHub a déjà sorti un portage Rust du PoC. C'est intéressant car Rust offre encore moins de surface AMSI que .NET 3.5 et se compile comme un binaire natif sans aucune dépendance. Donc pour un attaquant, c'est un upgrade de furtivité significatif... Et pour un défenseur, c'est surtout une raison de plus de pousser vos utilisateurs vers des vrais gestionnaires de mots de passe.

Concernant la divulgation responsable , Tom Rønning a fait les choses dans les règles : signalement à Microsoft, attente de la réponse officielle, présentation publique le 29 avril 2026 à BigBiteOfTech (l'évènement Palo Alto Networks Norway), puis publication du PoC.

Voilà... Microsoft persiste, Edge reste as-is (lumière !), et la sécurité de vos mots de passe est officiellement votre problème. Donc si vous utilisez Edge, je pense que ça vaut clairement le coup de migrer vers un gestionnaire externe... vous verrez, c'est pas la mer à boire.

Source

ffmpeg-over-ip - Le transcodage GPU distant pour Jellyfin

Par : Korben ✨
4 mai 2026 à 16:15

Jellyfin sans GPU, c'est la croix et la bannière dès que quelqu'un lance un film en 4K. Mais c'était sans compter sur ffmpeg-over-ip qui est capable de transformer un serveur équipé d'un GPU en endpoint de transcoding distant, accessible via un simple binaire qui se fait passer pour ffmpeg. Y'a pas de passthrough GPU, ni besoin de vous lancer dans la config de point de montage réseau exotique.

Le principe c'est que le client reçoit les commandes ffmpeg de Jellyfin (ou Emby), les sérialise et les envoie ensuite via TCP (port 5050) vers un serveur qui lui dispose d'un bon GPU. Et côté Jellyfin, rien ne change puisque le binaire répond exactement comme ffmpeg le ferait (et je vous rassure, y'a un peu d'authentification pour éviter de vous faire squatter votre serveur de transcoding à l'insu de votre plein gré).

Alors imaginons un peu dans quelle situation ça peut être utile... Par exemple, vous pourriez avoir un NUC ou mini-PC tout neuf qui fait tourner Jellyfin dans Docker, et à côté une vieille tour avec une GTX qui traîne dans un coin pour le transcodage. L'avantage c'est que plusieurs clients peuvent ainsi partager le même serveur GPU en parallèle, donc ffmpeg-over-ip peut valoir le coup si vous avez du matériel qui dort dans un coin.

L'outil est signé Anees Iqbal (steelbrain) et voici comment l'installer (pensez à vérifier le contenu du .sh avant) :

curl -fsSL https://ffmpeg-over-ip.com/install-client.sh | sh

Windows a aussi droit à son équivalent PowerShell si vous voulez.

Pour brancher ça sur Jellyfin ensuite, c'est direction Dashboard → Playback → chemin ffmpeg → et faites pointer vers ffmpeg-over-ip-client. Notez que ffprobe doit aussi être redirigé car Jellyfin l'appelle séparément pour les métadonnées. Vous pouvez faire un lien symbolique pour être tranquille :

ln -s ffmpeg-over-ip-client ffprobe

Et ensuite, pour vérifier, cette commande : ./ffmpeg-over-ip-client -version devrait vous retourner les infos de l'instance ffmpeg distante. Si ça répond, c'est que c'est bon !

Notez que la config permet de passer par des variables d'environnement du genre FFMPEG_OVER_IP_CLIENT_ADDRESS pour l'adresse du serveur, FFMPEG_OVER_IP_CLIENT_AUTH_SECRET pour la clé HMAC. Et pour tout ce qui est paramètres avancés, disons que les remappings de filtres complexes qu'on peut faire avec ffmpeg nécessitent encore un fichier .jsonc à créer et paramétrer.

Côté serveur, les accélérations supportées sont : NVENC (NVIDIA), QSV (Intel), VAAPI (Linux), AMF (AMD), VideoToolbox (macOS). Et comme c'est basé sur jellyfin-ffmpeg, du coup y'a toutes les accélérations habituelles sans avoir à recompiler.

Par contre, attention si le serveur GPU tombe, y'aura aucun fallback automatique vers le CPU local. Et si votre réseau interne est en 100Mbps et que vous transcodez du 4K HEVC, le goulot d'étranglement sera le transit réseau, pas le GPU. Donc optez pour un réseau en gigabit minimum dans ce cas.

Bref, c'est simple, propre, et très bien pensé par exemple pour les setups Docker qui n'ont pas d'accès direct au matériel.

À partir d’avant-hierKorben

Un robot qui construit des maisons en argile

Par : Korben ✨
4 mai 2026 à 15:26

Vous connaissez ICON, qui imprime des maisons en béton avec ses grosses machines ? Hé bien Terran Robotics fait en fait pareil, mais avec de la terre, ou plutôt avec l'argile extraite directement du terrain. Du coup ça revient carrément moins cher.

Leur techno consiste en un robot suspendu par des câbles entre quatre tourelles dressées aux coins du chantier qui crache de l'argile. Zach Dwiel (CEO, ex-Intel) et Danny Weddle (CDO, architecte) ont développé ce système depuis 2019 et leur premier chantier est actuellement en cours.

D'abord la pince robotisée ramasse l'argile sur place. Ensuite elle la dépose couche par couche sur les murs en construction. Un outil de compactage tasse chaque dépôt, et des caméras couplées à du machine learning évaluent la qualité de la paroi en continu.

Le matériau c'est ce qu'on appelle de l'adobe . Rien à voir avec Photoshop, hein... De l'adobe c'est un mélange entre de l'argile, de la terre, de l'eau et de la paille. L'avantage c'est que tout est sourcé directement sur le terrain.

Bon, ça suppose que la terre soit suffisamment argileuse, ce qui n'est pas garanti partout, mais dans la plupart des cas ça passe. D'après l'un des inventeurs : "C'est le matériau le moins cher pour construire. Notre but c'est le logement abordable." L'adobe offre en prime une bonne inertie thermique et régule naturellement l'humidité et le son.

Source : Terran Robotics

Par contre, je vais rien leur dire mais de ce que je connais au BTP, c'est quand même pas l'idée du siècle de construire SUR un terrain argileux à cause du gonflement et de la rétractation de l'argile en période de pluie / sécheresse... Breeeef, j'suis pas sûr que j'opterai pour ça moi... Après si l'argile est récupérée plus loin, pourquoi pas...

Quoi qu'il en soit, la première maison sort au Texas, sur le campus Proto-Town, un terrain de 485 hectares près de Lockhart financé par Josh Kushner, Bill Ackman et Fred Ehrsam (co-fondateur de Coinbase).

Ce 1er chantier a 2 murs en adobe et 2 en bois seulement pour tester... Mais la prochaine maison sera réalisée 100% en terre et ils visent la construction de 20 maisons cette année. La portabilité c'est l'argument fort de cette techno car au lieu de déplacer un gros engin qui mobilise une logistique complète, tout tient dans un petit camion. Ainsi, un opérateur peut gérer plusieurs chantiers simultanément.

Comparé à de l'impression 3D béton à la ICON, le fait d'utiliser directement ce qui se trouve sur le terrain, c'est moins de capital de départ, moins de matière transportée, et surtout c'est déployable n'importe où. C'est le principe des robots à câbles parallèles (CDPR) appliqué au bâtiment... dans l'esprit des projets robotiques open source mais à l'échelle d'une maison entière !

Bref, construire avec de l'argile je trouve ça chouette car c'est quand même une méthode qui a fait ses preuves et que l'humain emploie depuis des millénaires. Mais construire sur de l'argile, j'suis moins fan. Quoi qu'il en soit, c'est une chouette invention je trouve !

Source : KXAN / Terran Robotics / Proto-Town

Zxc, une bibliothèque de compression 2× plus rapide que LZ4

Par : Korben ✨
4 mai 2026 à 13:56

Deux fois plus rapide que LZ4 en décompression ?? Ah bon c'est possible ? Évidemment, quand Bertrand Lebonnois a publié zxc sur GitHub , et m'a envoyé un email pour me prévenir, j'ai été jeter un œil, surtout aux benchmarks.

Eh bien après analyse, c'est bien réel !

La philosophie de zxc est assez tranchée vous allez voir. Il s'agit d'une lib WORM (Write-Once, Read-Many) qui permet de compresser une fois lentement, à la compilation ou en CI, et ensuite de décompresser comme vous voulez des millions de fois sur les appareils de vos utilisateurs à la vitesse de l'éclair. Avec zxc, on accepte que la compression soit lente et complexe (pour trouver le bitstream parfait), afin que la décompression soit méga rapide et simple pour le processeur. C'est aussi simple que ça.

Le revers de la médaille, c'est que si vous voulez de la compression à la volée ou du streaming temps réel, ce n'est clairement pas adapté. Par contre, si vous produisez des assets une fois et qu'ensuite, vous les servez des milliers de fois, alors vous êtes exactement dans la cible.

En pratique, sur macOS M2 avec un corpus de test standard, zxc dépasse les ~12 000 Mo/s en décompression, contre ~5 600 Mo/s pour LZ4 --fast dans le même test. L'écart reste également hyper solide ailleurs : 1,8× sur ARM serveur (Google Axion) et 2× sur x86_64 (AMD).

Et l'API proposée par zxc ne s'arrête pas à un compresseur basique. En effet, un mode "seekable" permet d'accéder à n'importe quelle position d'une archive sans scanner le fichier depuis le début. Par exemple, vous packagez vos assets de jeux vidéo dans une seule archive zxc, et quand le joueur charge une texture précise, vous lisez directement le bon bloc, et pas tout le fichier.

Côté installation, c'est simple : brew install zxc sur macOS, apt install zxc sous Debian ou Ubuntu, pip install zxc-compress, npm install zxc, cargo add zxc-compress ou vcpkg install zxc sous Windows.

Des bindings officiels existent aussi pour Rust, Python, Node.js, Go et WASM et la communauté a aussi ajouté Nim et Free Pascal de son côté. Et comme c'est codé en C, y'a aucune dépendance lourde.

Sache que pour assoir la crédibilité du projet, zxc a été intégré dans lzbench et TurboBench, les deux outils de référence permettant de comparer les algos de compression. Et le paquet est déjà dispo dans les versions testing et unstable de Debian, ce qui veut dire que les mainteneurs ont validé le truc !

Bref, si vous gérez de la compression d'assets ou de firmwares dans votre pipeline, ça vaut le coup d'y jeter un oeil.

Merci à Bertrand pour l'info et chapeau pour le boulot !

ReactOS, le clone open source de Windows, simplifie son installation

4 mai 2026 à 13:11

Trois décennies que ReactOS essaie de devenir un clone open source de Windows, et le projet vient de mettre en place deux changements assez gros pour mériter un coup d'œil.

La 0.4.16 est entrée en phase finale cette semaine, avec des release candidates qui devraient suivre dans la foulée, et elle apporte une image d'installation unifiée plus un nouveau storage stack ATA. Deux gros morceaux qui devraient simplifier la vie de ceux qui veulent tester le truc sur de vraies machines.

Premier changement, fini les deux ISOs séparées. Avant, il fallait choisir entre l'image live (pour tester sans installer) et l'image d'installation. Maintenant tout est dans une seule image. Voilà.

Du coup, vous pouvez booter en live, voir si ça marche sur votre machine, et lancer l'installation directement depuis là si ça vous convient. Au passage, le vieil installeur en mode texte façon Windows 2000 risque d'être bientôt mis à la retraite au profit d'un parcours plus moderne.

Le deuxième changement est plus technique mais peut-être plus important. Le projet a remplacé son driver de stockage UniATA, qui datait de pas mal d'années, par un nouveau storage stack PnP-aware compatible NT6+.

Concrètement, ça veut dire un meilleur support des contrôleurs ATA et AHCI modernes, et donc une meilleure compatibilité avec le matos réel qu'on trouve dans les PC de 2026. C'était l'un des plus gros problèmes pour faire tourner ReactOS sur du hardware physique plutôt qu'en machine virtuelle.

ReactOS reste avant tout un projet pour les passionnés. La compatibilité avec les applications Windows modernes est encore très partielle, et quasi tout ce qui dépend de DirectX récent ou des frameworks .NET de dernière génération va planter.

Mais pour faire tourner un vieux logiciel pro orphelin, un jeu Win98 ou XP, ou simplement explorer comment fonctionne un OS de type Windows en open source, c'est tout indiqué.

Pour rappel, ReactOS n'est pas une distribution Linux qui imite Windows, c'est une réimplémentation complète et indépendante qui vise la compatibilité binaire avec les drivers et applications Windows NT.

L'objectif est de pouvoir lancer un .exe Windows directement, sans Wine ni couche d'émulation. Le projet est sur les rails depuis 1996, et même si ça avance lentement, chaque release apporte son lot d'améliorations concrètes.

Bref, si vous aviez ReactOS dans un coin de votre tête comme curiosité, la 0.4.16 sera sans doute le bon moment pour le retester sur une vieille machine.

Source : Hackaday

Photographier les vraies couleurs en stockant tout le spectre était déjà possible en... 1891

4 mai 2026 à 12:01

Hackaday vient de remettre en lumière (c'est le cas de le dire) une technique de photo couleur quasi oubliée et complètement folle : les plaques Lippmann. Au lieu de découper la lumière en trois canaux RGB comme un capteur moderne, elles enregistrent le spectre complet, longueur d'onde par longueur d'onde.

Le résultat est tellement précis qu'un spectromètre peut le relire sans problème. 

Le truc tient à un montage tout simple. Vous prenez une plaque de verre recouverte d'un gel photographique chargé en cristaux de halogénure d'argent extrêmement fins, et vous collez un miroir contre l'arrière.

Quand la lumière de la scène frappe la plaque puis se réfléchit sur le miroir, elle interfère avec elle-même et crée des ondes stationnaires. Ces ondes laissent dans le gel un motif d'argent métallique avec un espacement qui dépend directement de la longueur d'onde.

Du coup, après développement, la plaque ne contient pas une image RGB classique. C'est un empilement de réseaux de diffraction microscopiques, chacun calé sur sa propre longueur d'onde.

Quand vous éclairez le tout en lumière blanche, chaque réseau renvoie pile la couleur d'origine, sans approximation. Pour la première fois en 1891, Gabriel Lippmann avait littéralement enregistré la couleur "telle quelle", ce qui lui avait valu un prix Nobel de physique en 1908.

Le souci, c'est que la technique avait quasiment tous les défauts possibles côté usage. L'image n'apparaît correctement que sous un angle de vision très limité, l'exposition demandait des minutes voire des heures, les couleurs ressortaient parfois ternes selon l'éclairage, et il était impossible de tirer des copies.

Bref, intransportable, une photo unique, et compliqué à montrer. Forcément, ça n'a jamais décollé pour le grand public.

Reste que le principe lui-même n'est pas mort, il a juste muté en holographie. C'est exactement la même logique d'enregistrement par interférence d'ondes, sauf qu'on capture aussi la phase et pas seulement l'intensité spectrale.

Et à l'heure où les capteurs hyperspectraux deviennent abordables pour les bidouilleurs, l'idée de revisiter Lippmann avec du gel moderne et un éclairage cohérent commence à avoir du sens.

Source : Hackaday

RTK - Le proxy Rust qui vous fait économiser jusqu'à 90% de tokens

Par : Korben ✨
4 mai 2026 à 11:52

Si vous utilisez Claude Code au quotidien, vous connaissez ce goût de sang qui vous monte dans la bouche lorsque, sans prévenir, cette putain de limite de quota imposée par Anthropic vous explose à la gueule ! Et le pire c'est que vous n'avez pas l'impression d'avoir fait grand chose.

En réalité, la vraie raison c'est surtout le "bruit" de toutes vos sorties shell. Un git log, un cargo test, un npm build... votre agent IA ingère tout ça comme du petit lait alors qu'il n'a besoin que d'une fraction pour comprendre ce qui se passe.

Breeef, c'est pas ouf quoi.

Heureusement pour vous RTK (Rust Token Killer) vient régler en partie ce problème. RTK c'est développé par un Français et c'est un proxy CLI en Rust qui s'intercale entre votre shell et votre agent IA, intercepte les commandes courantes et compresse leur sortie avant qu'elle n'atterrisse dans le contexte de votre agent.

Comme ça plutôt que de massacrer vos prompts ou de changer vos habitudes (et dieu sait que vous avez horreur de changer d'habitudes..lol), il attaque le bruit à la source grâce à 4 stratégies de compression : un filtrage du boilerplate, un regroupement des lignes similaires, une troncature intelligente et de la déduplication des répétitions.

Et tout ça s'intègre merveilleusement bien via un hook pour Claude Code, GitHub Copilot, Cursor, Gemini CLI, Windsurf, Cline, Codex... soit une bonne dizaine d'outils supportés !

Ainsi, votre git status devient rtk git status sans changer quoi que ce soit à vos habitudes... RTK fait tout le filtrage dans votre dos, ce qui est parfait ! C'est un outil qu'on installe et qu'on oublie.

Par exemple un git diff passe de 12 000 tokens à 960, soit 92% d'économie, un npm test tombe de 6 000 à 600 tokens et une session de refactoring sur 12 fichiers passe de 74 700 à 6 960 tokens d'après les benchmarks. En pratique, les utilisateurs constatent des économies autour de 70% sur l'ensemble d'une journée de boulot, ce qui représente plusieurs millions de tokens par semaine pour ceux qui bossent avec des agents IA à plein régime.

Moi ça fait plusieurs mois que je le teste et voici mes stats. Ça donne quand même 81,5 % d'économie de tokens !!

L'installation se fait en une commande : brew install rtk sur macOS, ou un script curl pour les autres plateformes, ou cargo install --git https://github.com/rtk-ai/rtk si vous préférez compiler ça vous-même.

Avec la commande rtk gain vous verrez un tableau comme ci-dessus avec les statistiques par commande, et rtk gain --history donnera l'historique détaillé. Y'a plus de 100 commandes couvertes, de git aux runners de tests en passant par AWS CLI, kubectl et docker. Par contre, ça marche pas super bien si vos sorties de commandes sont déjà très courtes. Ça ne fera pas de miracle mais pour des diffs volumineux ou de suites de tests qui crachent 3 000 lignes à chaque fois, c'est tip top !

Si vous utilisez des agents en mode autonome où une boucle tourne sans intervention, c'est même encore plus pertinent car chaque itération accumule du bruit de façon cumulative, et du coup le contexte se remplit de trucs inutiles à vitesse grand V. Moins de bruit grâce à RTK, c'est donc une économie de tokens mais c'est également un meilleur signal pour votre agent.

RTK est dispo en open source sur GitHub sous licence Apache 2.0.

OAuth2 Proxy - L'authentification OIDC en reverse proxy

Par : Korben ✨
4 mai 2026 à 11:32

Vous avez un service qui tourne sur le port 8080, mais aucune authentification native dessus et vous voulez ajouter OAuth2 sans avoir à toucher au code ? Vous êtes vraiment exigeant dans la vie !

Mais comme vos désirs sont des ordres, je vous présente oauth2-proxy dont c'est EXACTEMENT le boulot !

Le principe avec cet outil c'est qu'il se glisse entre l'utilisateur et votre application. Ainsi, si la personne n'est pas connectée, elle est alors redirigée vers son provider OAuth2 ou OIDC. Et une fois le token validé, popopop, la requête repart vers son point d'origine avec les infos utilisateur dans les headers HTTP. Et voilà comme votre app reçoit le nom, l'email, et les groupes associés à l'utilisateur ! Plus besoin de gérer l'auth dans votre code c'est que du bonheur !

Et la liste des providers supportés par oauth2-proxy est longue : Google (c'est celui par défaut), GitHub, GitLab, Microsoft Entra ID, Keycloak, Gitea / Forgejo, NextCloud, DigitalOcean, LinkedIn, Bitbucket, Cisco Duo... et un bon vieux client OIDC générique pour tout ce qui expose un accès standardisé. Comme ça si votre SSO interne parle OIDC, vous êtes déjà couvert !

Côté déploiement, c'est un simple binaire en Go et c'est également disponible en image Docker sur quay.io/oauth2-proxy/oauth2-proxy, pour AMD64, ARM64, ARMv6/v7, et quelques architectures plus exotiques du genre ppc64le, s390x pour les bandeurs de mainframes ^^.

Ensuite, l'outil peut fonctionner de 2 façons : Soit en proxy autonome devant votre service, ou en middleware intégré dans un reverse proxy existant comme nginx via le mécanisme auth_request. Dans ce second mode, oauth2-proxy ne fait en réalité que vérifier la session et répondre du code 202 ou 401. C'est nginx qui gère le routage et le proxy lui se contente d'authentifier les gens.

Et voilà, si vous cherchez à minimiser la surface d'attaque, c'est la config à privilégier. Tout est là : github.com/oauth2-proxy/oauth2-proxy , avec la doc complète. Et si vous cherchez quelque chose de plus intégré, avec tunnel et gestion des tunnels VPN en prime, il y a aussi Pangolin dont je vous ai parlé. Et pour du plus simple en contexte Docker, TinyAuth fera également très bien le taf.

Merci à Mathieu Passenaud pour le lien !

Agent Safehouse - Un garde-fou pour vos agents IA sur macOS

Par : Korben ✨
4 mai 2026 à 11:13

Comme vous le savez, les LLMs sont assez probabilistes de par leur nature. C'est leur force mais également leur principal problème de sécurité car si votre agent IA a une probabilité de 1% de faire une grosse connerie des enfers par session, sur 100 sessions vous montez à environ 63% de chances qu'il en arrive au moins une.

Heureusement, Agent Safehouse vous permet d'encapsuler votre agent préféré dans un profil sandbox macOS au niveau du kernel afin de réduire drastiquement la surface d'attaque sur votre système de fichiers.

Le principe de base, c'est le deny-default. Tout est refusé par défaut puis des autorisations sont ensuite ouvertes au compte-gouttes : lecture/écriture dans le répertoire du projet, accès lecture seule aux toolchains installés, et les exceptions système nécessaires au fonctionnement (runtimes, homebrew, réseau).

Par défaut, les clés privées SSH et les fichiers de credentials AWS ne sont pas lisibles donc si l'agent essaie d'accéder à ~/.ssh, il se prend une erreur "operation not permitted". C'est une couche de durcissement mais pas une barrière de sécurité absolue puisque le réseau, lui, reste ouvert par défaut, et des variables d'environnement peuvent encore exposer vos credentials. Mais pour tout ce qui est erreurs accidentelles et autres hallucinations destructrices en mode Claude a fumé la moquette, ça permet de leur couper la chique.

Cela repose sur le mécanisme sandbox-exec , l'outil natif macOS qu'Apple a fini par marquer "deprecated" sans vraiment le retirer. Agent Safehouse s'en sert tout simplement comme fondation et y ajoute de la configuration par profil et les intégrations agents par dessus.

Sandbox-exec est en effet le seul mécanisme natif macOS qui s'applique en wrapper arbitraire depuis la ligne de commande, sans avoir besoin de se taper un setup préalable comme on pourrait le faire avec Docker ou une VM.

Et c'est surtout plus léger et plus pratique pour un usage au quotidien donc si vous faites tourner Claude Code ou Codex plusieurs heures par jour, ça peut servir, au moins pour votre tranquillité d'esprit.

L'installation se fait via Homebrew comme ceci :

brew install eugene1g/safehouse/agent-safehouse

Ou via un script curl si vous évitez Homebrew. Ensuite, vous remplacez votre appel habituel par safehouse [agent] [options]. Donc pour Claude Code ça donnerait ceci :

safehouse claude --dangerously-skip-permissions

Les functions shell (bash, zsh, fish) peuvent encapsuler ça automatiquement pour que votre agent soit sandbox par défaut à chaque appel et il est toujours possible de contourner cela via un simple command claude si besoin.

La liste des agents supportés est Claude Code, Codex, OpenCode, Amp, Copilot CLI, Gemini CLI, Aider, Goose, Cursor Agent, Cline, Kilo Code et d'autres.

Après c'est macOS uniquement pour l'instant, et surtout sandbox-exec étant techniquement plus maintenu par Apple, il pourrait très bien disparaître dans une future version de macOS. Donc faudra vivre avec ce risque ^^.

Si vous faites tourner des agents locaux et que l'idée d'un agent qui décide de miner de la crypto ou d'effacer votre répertoire home vous stresse de ouf, ça vaut le coup d'essayer. C'est dispo sur GitHub .

Un iPod Nano transformé en workstation triple écran

4 mai 2026 à 10:23

Sur sa chaîne YouTube "Will It Work?", un bidouilleur a réussi à brancher trois moniteurs sur un iPod Nano de sixième génération. Oui, vous avez bien lu, l'iPod cliquable carré qui faisait 4 cm de côté en 2010, et qui n'avait à l'origine aucune sortie vidéo digne de ce nom. Le résultat est un setup absurde mais qui tient debout, et c'est franchement délicieux à regarder.

La clé magique pour que ça fonctionne, c'est un ancien Apple iPad Keyboard Dock 30 broches, l'un des rares accessoires de l'époque qui acceptait de relayer le signal vidéo composite généré par l'iPod. Le clavier en lui-même est inutile parce que l'OS du Nano ne sait pas quoi en faire, mais le dock sert de support physique et de relais électrique. De là, un câble 30 broches vers composite ressort vers les écrans.

Pour les écrans justement, le bidouilleur a sorti trois Sharp Aquos à dalle plate du début des années 2000, branchés en chaîne via leurs entrées composites. Du coup, chaque télé reçoit le même signal, mais visuellement on a bien l'impression d'avoir trois moniteurs distincts qui crachent l'image du Nano. C'est parfaitement inutile, donc très satisfaisant.

Côté son, le Nano alimente un splitter TRRS 4 pôles qui sépare le signal pour brancher en parallèle un micro Maono de bureau et une paire d'Apple Pro Speakers, ces fameuses enceintes transparentes du Power Mac G4. Le rendu fait vraiment penser à une station de podcast pro, sauf que tout sort d'un appareil qui pèse moins qu'une carte de crédit.

Le plus improbable, c'est que l'auteur a réussi à faire tourner du "vrai multitâche" sur le Nano, en lançant un diaporama photo sur les trois écrans pendant qu'une playlist tourne en fond. C'est techniquement la limite des capacités d'un iPod Nano de 2010, mais en pratique ça suffit largement à donner l'illusion d'un poste de travail complet quand on regarde la photo en plan large.

On est là dans la longue tradition des hacks autour des vieux iPods, où la communauté continue de creuser ce que la puce sous le capot peut vraiment faire. Le Nano 6G en particulier a déjà été modifié pour faire tourner des firmwares custom, des jeux, ou même Doom, et ce genre de détournement vidéo est une nouvelle pierre improbable à l'édifice.

Ce genre de bidouille rappelle bien pourquoi le détournement d'objets Apple est devenu un sport en soi.

Source : Hackaday

Coincés durant +5 heures sur Age of Empires 2

Par : Korben ✨
4 mai 2026 à 09:00

Hier soir Lilian, fidèle lecteur de Korben m'a envoyé une vidéo incroyable qui retrace 5h de combat sur Age of Empires 2 résumées en 34 minutes par TheGreatReview.

Faut savoir que je suis fan d'Age of Empires depuis le premier épisode de 1997 . AoE 1, 2, Mythology, AoE 3... j'ai laissé un nombre indécent d'heures sur ces titres, donc forcément, voir ces longues heures de matchs condensées en chouette récit, ça ravive de vieux souvenirs !

Lors de cette partie, 2 joueurs avec un très très bon niveau s'affrontent ainsi durant des heures, quasiment sans ressources, en mettant au point toutes sortes de stratégies pour faire capituler leur adversaire. De l'AoE2 raconté à la voix posée, avec beaucoup de stratégie, d'imagination et surtout de patience ! Mais je ne vais pas vous en dire plus pour ne pas vous spoiler.

Gardez-vous ça pour la pause déj', ça ne dure que 34 minutes et franchement ça vaut le coup !

Encore merci à Lilian pour le partage !

BrowserQuest - Le MMO HTML5 de Mozilla est de retour

Par : Korben ✨
3 mai 2026 à 16:21

BrowserQuest est de retour les amis ! Hé ouais, el famoso MMO HTML5 que Little Workshop avait pondu pour Mozilla en 2012 vient de ressurgir sur threej.in , alors que Mozilla avait officiellement archivé le repo GitHub en janvier 2024.

En allant sur ce lien, vous choisissez le nom de votre personnage, et hop, vous vous retrouvez comme y'a plus de 10 ans, dans un monde 2D en pixel art prêt à vous taper avec des rats et des squelettes direct dans le navigateur.

Petit rappel pour les endormis du fond à côté du radiateur, quand BrowserQuest est sorti en mars 2012, c'était un événement !! Mozilla voulait avec ce jeu, montrer au monde entier que le navigateur pouvait faire tourner un MMO temps réel sans Flash, sans aucun plugin, mais juste avec du HTML5 et des WebSockets. Le studio parisien Little Workshop (les frères Guillaume et Franck Lecollinet) avait alors livré une démo incroyable qui ressemblait à un Zelda 16 bits, avec des quêtes, de l'équipement, un chat intégré et même du combat coopératif. Comme je suis viiieux de fous, je vous en avais même parlé à l'époque .

Car techniquement, c'était du sérieux... Canvas pour le rendu 2D, Web Workers pour charger la map sans freezer la page, localStorage pour sauvegarder votre perso, CSS3 Media Queries pour s'adapter au mobile, et surtout WebSockets pour la communication bi-directionnelle avec le serveur Node.js.

Du coup le jeu pouvait encaisser des CENTAINES de joueurs simultanés, avec un pic réel enregistré à plus de 1 900 connexions en même temps. C'est ouf ! Faut dire que 2 ans plus tôt, Quake 2 tournait déjà en HTML5 et on commençait alors tous à comprendre que notre navigateur allait devenir une véritable plateforme gaming.

Sauf que voilà, Mozilla n'a jamais vraiment maintenu BrowserQuest après le buzz initial. Le serveur officiel browserquest.mozilla.org a fini par mourir, le repo GitHub a basculé en mode DEPRECATED, et en janvier 2024, la fondation a appuyé sur le bouton "Archive" pour de bon. Fin du game ! Sniiiif...

Sauf que le code est sous licence MPL 2.0 et le contenu en CC-BY-SA 3.0 donc en gros, n'importe qui peut reprendre le bousin, le réhéberger et le relancer !

Hé bien c'est exactement ce que threej.in a fait et ça fonctionne parfaitement, y compris l'aspect multijoueur. L'écran de crédit affiche même encore "Made for Mozilla by Little Workshop" comme si rien n'avait bougé.

Perso, je trouve ça cool qu'un projet open source archivé aussi culte puisse continuer à vivre grâce à un inconnu qui a pris la peine de le remettre en ligne. C'est aussi à ça que servent les licences libres finalement... prolonger la vie des programmes au-delà de la motivation de leurs créateurs. Chouette hein ?

À l'époque, encaisser 1900 joueurs en simultané sur un backend Node.js relevait de la prouesse technique, alors qu'aujourd'hui, tout semble beaucoup plus facile puisqu'on trouve des dizaines de jeux .io et autres qui tournent dans un onglet de browser sans que ça nous fasse lever un sourcil. La techno derrière BrowserQuest est devenue tellement banale qu'on a tous oublié à quel point elle était impressionnante à l'époque !

Bref, c'est gratuit, c'est dans le navigateur, et ça tient toujours debout !

À découvrir ici !

Ce jeu Steam flingue votre SSD en silence

3 mai 2026 à 12:02

108 Go par heure. C'est ce que Windrose, le RPG de pirates en Early Access publié par Kraken Express le 14 avril dernier, écrivait silencieusement sur les SSD des joueurs, sans aucune mention dans les notes de mise à jour. Avec déjà 1,5 million de copies vendues et un pic à 69 000 joueurs simultanés, ça commence à faire un sacré paquet de SSD potentiellement bien fatigués.

Le bug a été repéré par Pixel Operative et confirmé par TechSpot puis Tom's Hardware. En jeu, des pics d'écriture grimpaient jusqu'à 30 Mo/s en continu, même quand le personnage se baladait tranquillement dans son camp de base sans rien faire de spécial.

Sur un SSD grand public type TLC avec une endurance affichée autour de 600 TBW, on parle de plusieurs jours de jeu intensif suffisant pour grignoter une bonne part de la durée de vie nominale.

Le problème vient en fait de la façon dont Kraken Express gère la sauvegarde des progressions. Le studio a choisi RocksDB, une base de données clé-valeur très utilisée côté serveur, et en a empilé trois instances en parallèle, chacune avec un cache mémoire ridiculement petit. Du coup, dès que le cache déborde, tout est balancé sur le disque en boucle permanente, sans aucune logique d'optimisation. Pas terrible.

Kraken Express a réagi vite avec le patch 0.10.0.4 déployé le 30 avril. Selon Pixel Operative qui a refait ses mesures après mise à jour, l'utilisation disque baisse de 60 à 75%. C'est nettement mieux, mais ça reste très loin des standards d'un jeu propre. Et surtout, ça ne change strictement rien pour les joueurs qui ont écrit plusieurs téraoctets de données pendant les deux semaines précédant le correctif.

Côté communication, le studio a reconnu le souci mais sans trop s'étendre sur les conséquences possibles pour le matériel. Pas un mot sur une éventuelle aide aux joueurs qui auraient des SSD très entamés. Et impossible de savoir combien de joueurs sont concernés, vu que l'usure d'un SSD ne se voit qu'au moment où il commence à lâcher.

Bref, un Early Access ça reste un Early Access, mais bousiller le hardware des joueurs sans même les prévenir, c'est pas génial.

Source : Techspot

Un C-3PO grandeur nature transformé en assistant vocal qui répond pour de vrai

3 mai 2026 à 10:20

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 assez classique.

Le truc rigolo, c'est la couche par-dessus. L'auteur a ajouté un prompt système qui force le LLM à répondre comme C-3PO le ferait : un peu anxieux, très formel, avec ce ton un brin pompeux qu'on connaît tous. Du coup, quand vous lui demandez bêtement la météo, vous pouvez vous prendre une réponse genre "Oh dear, je crains que les conditions atmosphériques ne soient guère favorables à un déplacement humain". Très C-3PO.

Pour la voix, le projet utilise un modèle synthétique entraîné sur les dialogues d'Anthony Daniels, l'acteur original. Le son passe ensuite par une chaîne d'effets audio qui ajoute la résonance métallique et le léger souffle qu'on entend dans les films. Le résultat n'est pas parfait, mais ça reste franchement bluffant pour un projet bricolé à la maison.

Tout le code est dispo en open source, ce qui veut dire que vous pouvez théoriquement le reproduire chez vous, à condition d'avoir une réplique C-3PO sous la main. Ce qui n'est pas le plus simple. Pour les budgets plus modestes, l'auteur précise que le pipeline tourne aussi très bien dans une simple enceinte connectée custom, le côté droïde doré n'étant pas indispensable au fonctionnement.

Le seul vrai bémol, c'est la latence. Entre le moment où vous parlez et la réponse vocale, comptez quelques secondes, ce qui casse un peu l'illusion d'avoir affaire à un assistant réactif. Mais bon, le vrai C-3PO du film mettait aussi trois plombes à comprendre les ordres, donc on peut presque considérer ça comme un détail de fidélité au personnage.

Source : Hackaday

❌
❌