WorkBoy - Le PDA fantôme de la Game Boy
En 1992, Eddie Gil de la boîte anglaise Source R&D et Frank Ballouz de Fabtek s'étaient mis en tête d'une chose : transformer la Game Boy en PDA. La console à pile AA de Nintendo avec son écran vert pissette devait, dans leurs rêves les plus fous, devenir l'agenda électronique des cadres dynamiques. Le projet s'appelait WorkBoy, et il a même été présenté au CES en 1992, puis... plus rien.
Évaporé durant 28 ans.
Jusqu'à ce qu'en 2020, Liam Robertson, le mec derrière DidYouKnowGaming , retrouve un prototype fonctionnel chez Frank Ballouz lui-même. Ballouz l'avait sur son étagère depuis trois décennies. Quand Robertson l'a contacté, il lui a lâché tranquillou : "Oh yeah, j'ai le WorkBoy derrière moi" et après 7 mois de relances, le proto est finalement arrivé dans les mains de Robertson pour être testé en vidéo :
Le WorkBoy, c'est un clavier QWERTY plus gros que la Game Boy elle-même, avec une cartouche dédiée qui se branche dans l'emplacement où d'ordinaire, on met les jeux. Et à l'intérieur du clavier, il y a une horloge, de la mémoire interne (la Game Boy n'en avait pas, c'était LE problème majeur de l'époque), ainsi que tout un OS de bureautique de poche.
Et au menu des fonctionnalités, on avait donc le droit à un calendrier, un répertoire téléphonique, un convertisseur d'unités (parce qu'en 1992 vous saviez jamais quand ce serait le moment de convertir des pieds en mètres en pleine réunion), une calculatrice, et même un traducteur multilingue.
Mais le clou du spectacle, c'est la carte du monde qui jouait... les hymnes nationaux en 8-bit ! Voilà, je crois que là, tout est dit ! Vous cliquez sur la France, et hop vous avez la Marseillaise version Tetris. Vous cliquez sur l'URSS, vous avez l'Internationale en mode bip-bip. C'était fou pour l'époque !!
Eddie Gil avait passé des années à peaufiner ce truc, et Ballouz utilisait son carnet d'adresses Nintendo (il avait été cadre chez Nintendo Of America du temps des bornes d'arcade) pour pousser le projet en interne. Le lancement était alors prévu pour décembre 1992... l'usine était prête et la certification quasi bouclée.
Et puis Nintendo a annoncé qu'ils allaient faire baisser le prix de la Game Boy !! C'était la cata car d'un coup, l'accessoire WorkBoy, à 90 dollars environ, devenait plus cher que la console qu'il était censé compléter !
Ballouz a refait ses calculs, a fait la grimace, et a annulé la production quelques mois avant le CES. Game over pour le projet. Et voilà comment pendant trois décennies, le seul souvenir tangible du projet, c'était quelques photos floues et une marque déposée.
Mais le truc cool suite à cette redécouverte, c'est que Robertson a aussi mis la main sur le code source du WorkBoy via le fameux Nintendo Gigaleak de 2020 (c'était une fuite massive des serveurs Nintendo qui a balancé pelle-mêle des ROMs prototypes, du code source, des trucs internes...).
Un anonyme sur Twitter lui a alors signalé qu'on pouvait choper la ROM en ligne. Robertson était mal à l'aise avec la source car c'était du code volé, mais bon, il a fini par graver le binaire sur une cartouche et réussi à faire tourner le proto.
Et là, surprise : le truc a fonctionné nickel. "C'est plus rapide que mon ancien smartphone", a balancé Robertson. Faut dire qu'en 1992, avoir une UI réactive sur un écran 160×144 pixels en 4 nuances de vert, c'était de l'orfèvrerie. À l'époque, les développeurs savaient optimiser leur code au cycle CPU près, et ça se voyait...
Par contre, le WorkBoy nécessitait obligatoirement le hardware physique pour fonctionner correctement car l'horloge et la mémoire interne sont dans le clavier et pas dans la cartouche. Du coup, l'émulation pure ne suffisait pas. C'est probablement pour ça qu'on n'en avait jamais entendu parler avant que Ballouz daigne sortir le sien du grenier.
Ce WorkBoy disparu était l'incarnation parfaite de cette ère charnière où on cherchait à entasser de la productivité dans tout ce qui avait un microprocesseur. Comme quoi, bien avant le PalmPilot (1996), dans la foulée du Psion 3 (sorti un an plus tôt), Nintendo et ses partenaires avaient donc déjà flairé le truc.
VS Code signe vos commits avec Copilot, même sans Copilot
Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.
En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <copilot@github.com> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.
Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.
Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.
L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...
Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :
"git.addAICoAuthor": "off"
C'est le seul réglage qui marche vraiment, parce que dans la version buguée même chat.disableAIFeatures à true n'arrêtait pas le soucis. Et pour votre historique déjà bien pollué, un git rebase -i ou un git filter-branch permettra de virer les contributeurs parasites dans vos derniers commits. Mais après bonne chance si vos commits sont déjà sur des PR mergées chez d'autres. Là c'est mort...
Ce que les devs reprochent à Microsoft, c'est pas vraiment d'avoir créé l'option (elle existait depuis VS Code 1.110 en opt-in tranquille). Non, le vrai problème c'est surtout ce qu'il y a derrière cette vilaine Pull Request... 2 fichiers touchés, le change de "default", absolument AUCUNE description, une seule review d'approbation toute nulle, et hop, c'est mergé OKLM.
Pour un changement qui touche les messages de commit de plusieurs millions de devs, ça sent quand même la décision unilatérale prise à l'arrache entre 2 portes...
Et puis surtout il y a le bug #313064 qui a fait basculer l'histoire de la simple polémique à la grosse colère communautaire.
En effet, la nouvelle valeur par défaut "all" attribuait à Copilot des complétions qui ne venaient PAS de Copilot. Un dev explique par exemple avoir tapé son code à la main, vérifié son message de commit, supprimé toute suggestion Copilot, écrit le sien à la main... et a finalement retrouvé quand même Co-authored-by: Copilot dans le git log final.
Et comme le mode "je ne veux pas d'IA" n'était pas plus respecté, l'IA s'auto-créditait quand même sur tout et n'importe quoi.
Côté communauté, le ton est monté très vite. Sur le fil GitHub, y'en a un qui écrit que, je cite, "C'est pas une régression, c'est de la fraude. On ne peut pas s'attribuer un travail qu'on n'a pas fait." et un autre dev parle de "vandalisme" pur.
Windows Central a même sorti un titre choc : "This could cost people their jobs", parce que dans les boites en fintech ou sur du code soumis à audit, faire passer du code humain pour de l'IA-assisté peut coller un fail d'audit et faire péter des contrats. Ah bah ouais, j'avoue que je n'y avais pas pensé...
Heureusement, Microsoft a fini par bouger puisque dans VS Code 1.118 , le default est finalement repassé de "all" à "chatAndAgent", déjà moins agressif. Et dans la PR #313931 , dmitrivMS a remis le default à "off" pour la version 1.119, dont le déploiement public commence justement aujourd'hui.
Bien sûr, la Product Manager a fait son mea culpa public, en reconnaissant, je cite que "la manière dont c'était implémenté et déployé n'a pas atteint le niveau de correction attendu", ce qui, dans la langue corporate, veut dire "on est des branleurs, déso, bisous".
Maintenant ce qui revient souvent dans les commentaires, c'est que Claude Code et Codex CLI font la même chose par défaut quand ils committent, sauf que la différence, c'est que ces agents committent quand C'EST EUX qui ont écrit le code, donc le co-author est tout a fait légitime.
VS Code, lui, modifiait des commits écrits à la main par des humains donc c'est pas du tout le même problème. Et pour le coup, sur Codex CLI la mention reste aussi désactivable via une option alors que chez Claude Code même si c'est pareil, l'opt-out n'est pas toujours très respecté d'après les retours que j'ai pu lire.
En tout cas, ce loupé arrive dans un climat déjà tendu puisque Microsoft pousse Copilot dans Windows, dans Notepad, dans Office, et même jusque dans l'écosystème Apple via une extension Xcode , dans tous les coins, et beaucoup de devs commencent à voir chaque nouveauté MS à travers ce prisme. La théorie du "ils gonflent les KPI Copilot pour les boards et les analystes" de plus en plus crédible et comme personne n'aime se sentir transformé en stat marketing, tout le monde commence à se barrer des outils et services Microsoft.
Maintenant, si vous voulez vraiment vous protéger des prochains coups foireux de M$, je vous propose d'abord de basculer sur VSCodium ou Zed , deux éditeurs sans télémétrie ni AI imposée. Et ensuite, déménager vos repos chez Codeberg ou Forgejo en suivant la procédure de migration que je vous donne dans cet article Patreon, comme ça même si Microsoft fait n'importe quoi côté éditeur, votre code n'est plus chez eux côté forge.
À voir maintenant si Microsoft tient ses promesses sur le consentement explicite avant toute mention d'agent IA, ou si on rejouera ce film encore et encore tous les 6 mois sur une autre fonctionnalité.
Chrome installe en douce un modèle IA de 4 Go sur votre disque sans rien demander
Alexander Hanff, consultant, a remonté un truc pas net sur Chrome. La dernière version du navigateur télécharge en arrière-plan un modèle de langage local appelé Gemini Nano, qui pèse environ 4 Go, sans jamais demander la moindre permission à l'utilisateur.
Le fichier s'appelle weights.bin, il atterrit dans un dossier OptGuideOnDeviceModel quelque part dans votre profil Chrome, et il sert ensuite à des fonctions du genre "Help me write" ou détection de fraude.
Hanff a documenté l'opération via les logs système de son macOS. Le 24 avril 2026 vers 16h38, Chrome crée le dossier. Quelques minutes plus tard, il télécharge et décompresse les 4 Go (l'opération prend une quinzaine de minutes), puis il les déplace à l'emplacement final. Tout ça pendant que vous ne touchez rien à votre machine. Si vous supprimez le fichier à la main, il sera réinstallé silencieusement au prochain lancement du navigateur.
Hanff estime entre 100 millions et 1 milliard de machines concernées dans le monde. Multipliez 4 Go par 1 milliard et vous obtenez de quoi remplir une bonne partie d'un datacenter.
L'auteur calcule également l'impact carbone du déploiement, entre 6 000 et 60 000 tonnes de CO2e rien que pour le réseau, sans compter l'empreinte SSD. Pour un fichier que personne ne vous a demandé d'installer.
Sur le plan légal, Hanff parle d'une "violation directe" de l'article 5(3) de la directive ePrivacy européenne, qui interdit de stocker quoi que ce soit sur l'appareil d'un utilisateur sans consentement explicite. Il évoque aussi un manquement RGPD. Si la qualification tient, ça serait une amende salée pour Google, sachant que les Cnil européennes ont déjà sanctionné Meta et Microsoft pour des choses bien moins foireuses.
Pour s'en débarrasser, trois options : aller dans chrome://flags pour désactiver les fonctions IA, passer par les politiques d'entreprise si vous gérez un parc de machines, ou virer Chrome, tout simplement.
Bref, Google qui pousse 4 Go d'IA en silence sur des centaines de millions de machines, c'est un sale moche.
Source : That Privacy Guy
Un passionné a recréé l'Apple Lisa de 1983 dans un FPGA
Voilà un projet qui sort un peu de l'ordinaire. Un développeur a passé huit mois à réimplémenter intégralement l'Apple Lisa, l'ordinateur lancé par Apple en 1983, à l'intérieur d'un FPGA. Le résultat tourne.
Il charge le système d'exploitation Lisa OS et fait fonctionner les logiciels de l'époque comme à la sortie de la machine, sans la moindre puce d'origine. Juste une description matérielle Verilog/VHDL synthétisée sur une carte FPGA moderne.
Pour ceux qui ne suivent pas le rétro-Apple, l'Apple Lisa, c'est l'ancêtre direct du Macintosh. Premier ordinateur grand public d'Apple à intégrer une interface graphique avec souris, prévu pour les pros, mais vendu à un prix faramineux à l'époque (autour de 10 000 dollars de 1983), ce qui l'a tué commercialement avant que le Mac plus accessible vienne reprendre le flambeau l'année suivante.
Aujourd'hui, les Lisa qui marchent encore sont des objets de collection rares, surtout que les disques Twiggy d'origine étaient une catastrophe en termes de fiabilité.
Recréer la machine en FPGA permet de la faire vivoter sans dépendre de pièces qui n'existent plus, et c'est aussi un bel exercice de reverse engineering. Il faut bien bien comprendre le bus, le contrôleur graphique, les puces custom, les timings exacts, et tout retranscrire dans un langage de description matérielle.
Le développeur a documenté chaque sous-système au fil de la construction... On parle là d'un travail de fond qui ferait passer une thèse pour un travail dominical.
Le projet est documenté en vidéo. Le créateur explique chaque étape du portage, les bugs rencontrés (le Lisa avait un système de gestion mémoire inhabituel pour l'époque), et démontre l'ordinateur en train de tourner sur sa carte FPGA finale. Les fichiers du projet (sources Verilog, schémas, images de ROM) sont a priori disponibles pour les amateurs qui veulent reproduire la chose à la maison.
C'est chouette comme projet ! Le rétro-computing à coup de FPGA, c'est probablement la seule façon de garder vivantes des machines comme la Lisa pour les décennies qui viennent.
Source : YouTube
wg-obfuscator - Faire passer WireGuard pour de la visioconf
Si vous faites tourner WireGuard depuis un réseau filtré par DPI (Genre en Russie, Iran, Chine, et autres pays défenseurs de la libertéééé (non)), vous avez sans doute remarqué que les tunnels tombent rapidement. En effet, les signatures des protocoles et notamment du protocole WireGuard sont devenues facilement identifiables. Les filtres modernes de censure sont ainsi capable de les bloquer en quelques secondes. C'est pour ça que wg-obfuscator , sorti par Alexey Cluster (le dev derrière le mod hakchi de la NES Classic Mini dont je vous parlais en 2017), m'a tapé dans l'œil.
Concrètement, c'est un petit proxy en C qui se glisse entre votre WireGuard et le réseau. Vous le lancez aux deux bouts du tunnel, et lui déguise les paquets pour qu'ils ressemblent à du STUN (le protocole utilisé par les outils de visioconf, rarement bloqué) ou à un flux random pas reconnaissable. WireGuard continue ainsi de tourner sans aucune modification...
C'est vraiment bien fichu son truc et surtout, par rapport à AmneziaWG (un célèbre fork de WireGuard souvent cité comme référence en obfuscation), hé bien y'a juste un binaire à rajouter, alors que AmneziaWG, lui, modifie TOUT le protocole. Il faut donc remplacer les client ET le serveur ce qui est bien relou.
Comme wg-obfuscator se contente uniquement de faire le proxy, vous gardez votre setup WireGuard classique et donc ça fonctionnera partout... Sur OpenWrt, MikroTik avec RouterOS 7.4+ sur ARM64/x86_64 via Docker, NixOS, Android, ou un simple Raspberry.
Par contre, l'outil utilise une clé symétrique en texte clair donc c'est pas du chiffrement fort, mais du camouflage.
Côté config, on est sur du fichier INI tout simple :
[main]
source-lport = 13255
target = 10.13.1.100:13255
key = votre_secret
masking = STUN
verbose = 2
Après c'est pas dit dans la doc mais je pense que c'est compatible IPv4 seulement... Donc oubliez l'IPv6 pour le moment. Ensuite il faut les deux extrémités sous votre contrôle, donc oubliez les VPN commerciaux type NordVPN ou ProtonVPN tant qu'ils ne déploient pas wg-obfuscator côté serveur.
Ah et un dernier détail qui vaut le coup d'être noté, c'est le mode two-way avec static-bindings. En fait si vos deux peers ont une IP publique, vous pouvez parfaitement configurer à la main vos mappings NAT pour permettre à chacun d'initier la connexion, sans dépendre d'un serveur central.
Kawaii - La GameCube découpée au scalpel qui tient dans la poche
Mackie Kannard-Smith vient de sortir Kawaii , une GameCube qui tient dans un porte-clés avec une vraie carte mère Nintendo dedans. Pas d'émulation ni de Raspberry Pi déguisé mais juste du silicium d'origine charcuté à mort pour rentrer dans 60 × 60 × 15,8 mm ! Pour vous donner une idée, c'est plus petit qu'une Game Boy Color et c'est le boîtier en alu bleu anodisé qui fait office de dissipateur thermique passif.
Le truc tourne en réalité sur une carte mère de Wii sévèrement modifiée. Mackie a choisi la Wii (sortie en 2006) plutôt que la GameCube d'origine, parce que la Wii partage la même architecture mais avec une finesse de gravure plus récente. Du coup, c'est plus facile à miniaturiser même si pour arriver à ses fins, il a dû appliquer une technique baptisée Omega Trim qui consiste à tronçonner la PCB multicouche au scalpel et à reconnecter chaque piste à la main avec du fil ultra-fin. Pas simple quand on a des gros doigts ^^.
L'encodeur AV est délocalisé, la NAND flash relogée ailleurs, et le processeur est sous-volté dynamiquement via un régulateur custom. Vous chargez alors les jeux sur une carte microSD qui est scellée à l'intérieur !
Alors pour changer de jeu, il n'y a pas d'autre choix que de littéralement désassembler la console. C'est pas top côté pratique mais comme c'est du prototype de l'extrême et pas une console destinée au grand public, je pense que ça passe ^^.
Et là où c'est bien fichu je trouve, c'est avec le dock magnétique composé de pogo-pins, de 4 ports manettes GameCube d'origine, d'un USB-C pour l'alim, et d'une sortie AV analogique. Comme ça vous posez simplement la console sur la base et vous vous retrouvez avec un setup de salon classique.
Côté température, sans ventilo externe, ça chauffe vite par contre. Le boîtier alu fait son boulot, mais y'a quand même des limites physiques qu'on ne peut pas changer... Donc impossible de l'utiliser trop longtemps sans y ajouter un refroidissement actif en plus (genre ventilo ou watercooling).
Après, vous le savez, j'adore ce genre d'exploit et ce n'est d'ailleurs pas le premier mod du genre que je vous présente. Je vous avais déjà parlé du Short Stack de loopj, qui réduisait une Wii au format d'un paquet de cartes. Et devinez quoi, loopj a aussi contribué à Kawaii !
En réalité, cette communauté de tarés du fer à souder se retrouve sur le forum BitBuilt , où ils s'échangent les techniques de découpe extrême depuis des années, alors si vous voulez vous lancer, c'est the place to be !
Les fichiers de conception de la console Kawaii sont publiés sur GitHub , mais Mackie prévient : y'a aucun guide de build, et la réplication est "extrêmement difficile". En clair, c'est pas un mod du dimanche.
Faut une station de soudage à l'air chaud, une loupe binoculaire, des nerfs en acier et une connaissance fine de l'architecture Wii. À vrai dire, c'est sûrement plus simple d'attendre qu'un mod commercial inspiré du projet sorte un jour (coucou la GameCube Mini qui sortira probablement un jour...). Maintenant, si vous voulez voir la bête en action, Macho Nacho Productions a sorti une review de 21 minutes qui fait bien le tour de la machine :
Bref, Kawaii ça sert à rien, c'est techniquement aberrant comme dirait l'autre, et c'est exactement pour ça que c'est classe !
10 sites pour jouer aux jeux DOS dans votre navigateur gratuitement
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
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
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
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