Un développeur a réussi à porter MS-DOS 2.0 sur l'Apple IIe, l'ordinateur personnel d'Apple sorti en 1983. Le projet, baptisé "reboot-camp-83", repose sur une carte d'extension qui embarque un processeur Intel 8088 à 8 MHz.

Le tout communique avec le processeur 6502 de l'Apple II, et le code est en accès libre. Quarante ans de retard, mais le geste est là, et il est plutôt classe.

Un processeur Intel dans un Apple II

Seth Kushniryk vient de publier "reboot-camp-83", un projet open source qui permet de faire tourner des applications MS-DOS 2.0 sur un Apple IIe. Pour que ça fonctionne, il faut une carte d'extension AD8088, fabriquée à l'époque par ALF Products.

Cette carte contient un processeur Intel 8088 qui tourne à 8 MHz et qui se branche sur le bus d'extension de l'Apple II. On se retrouve avec deux processeurs dans la même machine : le 6502 d'Apple et le 8088 d'Intel.

Le Z80 de Zilog, le processeur qui a fait tourner le ZX Spectrum, le Game Boy et des dizaines de micro-ordinateurs des années 80, a été arrêté en juin 2024 après 48 ans de bons et loyaux services.

Un bricoleur a créé le PicoZ80 , une petite carte qui se glisse directement dans le même support et qui émule le processeur original grâce à une puce Raspberry Pi.

48 ans de service, et puis s'en va

Le Zilog Z80 a été lancé en 1976 et il a alimenté une bonne partie de l'histoire de l'informatique personnelle. ZX Spectrum, MSX, Amstrad CPC, Game Boy, calculatrices Texas Instruments : la liste des machines qui ont tourné avec ce processeur 8 bits est longue.

Zilog a annoncé sa fin de vie en avril 2024 et a cessé de prendre des commandes en juin de la même année. Les stocks de Z80 neufs en boîtier DIP-40 commencent donc à se raréfier, et c'est là que le PicoZ80 entre en jeu.

Un Raspberry Pi dans un boîtier DIP-40

Le PicoZ80, développé par le maker eaw, utilise un microcontrôleur RP2350B (la puce du Raspberry Pi Pico 2) monté sur un circuit imprimé au format DIP-40, avec le même brochage que le Z80 original. Un des deux coeurs Cortex-M33 à 150 MHz se charge d'émuler le Z80, pendant que le second gère l'accélération et les périphériques.

Les moteurs PIO du RP2350 prennent en charge les transactions de bus en temps réel, ce qui garantit un timing identique à celui du processeur d'origine. La carte embarque aussi 8 Mo de PSRAM, 16 Mo de flash pour stocker des images ROM, et un coprocesseur ESP32 qui ajoute le WiFi, le Bluetooth et un lecteur de carte SD.

Des machines classiques qui renaissent

Le PicoZ80 peut fonctionner comme un simple Z80 de remplacement, mais il propose aussi des "personas" de machines classiques. Des pilotes existent déjà pour le RC2014, le Sharp MZ-80A et le Sharp MZ-700, et d'autres sont en développement pour l'Amstrad PCW8256.

La carte fait aussi office d'expandeur mémoire, d'hôte USB et d'émulateur de disquette. Vous remplacez un processeur de 48 ans et vous gagnez au passage le WiFi et le stockage sans fil.

Bref, on parle quand même d'un projet qui ressuscite un processeur plus vieux que moi (de 1976) avec une puce à quelques euros. Pour les passionnés de rétro-informatique qui ont un vieux micro au fond du placard, c'est peut-être la meilleure nouvelle de l'année.

Source : Hackaday

« Can it run DOOM ? » Vous connaissez tous la question je pense. En effet, depuis 1993, le FPS d'id Software a tourné sur à peu près tout ce qui contient un processeur, des calculatrices aux écouteurs en passant par des tests de grossesse. Et là, Adam Rice vient de pousser le délire encore plus loin en stockant et en lançant le jeu entier... via des enregistrements DNS.

Oui, ce bon vieux protocole de plus de 40 ans, conçu à la base pour traduire des noms de domaine en adresses IP (RFC 1035, tout ça). En fait, la magie tient dans le fait que les enregistrements TXT n'ont aucune validation de contenu. Du coup, rien n'empêche d'y coller du texte arbitraire... genre un FPS complet converti en texte via base64. En gros, le DNS devient un stockage clé-valeur distribué mondialement et mis en cache un peu partout. Pas mal comme CDN du pauvre !

Le fichier WAD (les niveaux et assets du jeu, 4 Mo) passe à 1,7 Mo après compression, les DLLs du moteur de 4,4 Mo à 1,2 Mo, et le tout est découpé en 1 966 enregistrements TXT sur une seule zone CloudFlare Pro. Un record spécial contient également les métadonnées de réassemblage (nombre de chunks, hash de vérification).

Ensuite, côté joueur, un script PowerShell de 250 lignes résout les 2 000 requêtes, reconstruit le binaire en mémoire et hop, ça tourne. Les données du jeu ne touchent ainsi jamais le disque, puisque tout reste en mémoire. Le tout chargé en 10 à 20 secondes (PowerShell 7 requis) !

Le truc rigolo, c'est que l'auteur ne connaît pas le C#. C'est Claude (oui, encore cette fichue IA, ahaha) qui s'est tapé le portage en modifiant managed-doom, un port C# du moteur original, pour remplacer les lectures fichier par des flux mémoire et virer toutes les dépendances natives au profit d'appels Win32 directs. L'audio a été sacrifié pour réduire le nombre de records mais bon, on va pas chipoter. Après si vous voulez tester, sachez que ça ne fonctionne que sous Windows car ça repose sur PowerShell, donc pas de version Linux pour l'instant.

D'ailleurs, si le concept vous rappelle quelque chose, c'est normal. Planquer des données dans les enregistrements TXT, c'est en fait une technique bien connue en sécu. J'en parlais déjà avec DNSteal pour exfiltrer des fichiers via DNS , ou avec ces malwares carrément stockés dans les records DNS . Adam Rice le dit lui-même, son projet est parti de l'exploration de techniques d'implants (staging de shellcode via TXT records) sauf qu'au lieu de planquer un trojan, il y a planqué ce FPS de +33 ans. C'est quand même plus sympa !

À vrai dire, avant d'en arriver là, il a d'abord fait un proof of concept avec une image de canard (va savoir pourquoi). Encoder la photo en base64, découper en chunks, uploader via l'API CloudFlare, reconstruire de l'autre côté avec un hash identique et ça a marché du premier coup. Par contre pour la vidéo, oubliez, un MP4 de 1 Go ferait 670 000 enregistrements.

Voilà et tout ça pour 20 dollars par mois (le prix de la zone CloudFlare Pro). Donc si DOOM sur des écouteurs vous avait déjà fait sourire, attendez qu'un taré le fasse tourner avec que des paquets ICMP. Bah quoi ??

Bref, le code est dispo sur GitHub et le DNS a clairement pas fini de nous surprendre.

Source

Randal Linden est le développeur qui avait réussi l'exploit de faire tourner DOOM sur la Super Nintendo en 1995. Trente ans plus tard, il s’est associé à Limited Run Games pour ressortir une version améliorée sur cartouche, avec un processeur Raspberry Pi caché à l'intérieur.

Dans un long échange accordé à Kotaku, il revient sur ce projet un peu fou et sur les coulisses techniques du portage.

Reverse-engineerer son propre code, trente ans après

À l'époque, Linden bossait chez Sculptured Software, un studio basé à Salt Lake City. L'idée de départ était assez artisanale : acheter des cartouches Star Fox en magasin, les ouvrir, et remplacer la ROM par de la RAM pour tester les capacités de la puce Super FX. Le prototype a suffisamment impressionné ses supérieurs pour qu'ils aillent le présenter directement à id Software au Texas. Le feu vert a suivi.

La recompilation statique , je vous en avais parlé avec Zelda 64 et Sonic Unleashed. Le principe, en gros c'est qu'au lieu d'émuler bêtement le processeur et la mémoire d'origine, on traduit tout simplement le code assembleur du jeu directement en C natif. Du coup le jeu tourne nativement sur votre machine, sans couche d'émulation.

Et la bonne nouvelle du jour c'est que cette technique vient de parvenir jusqu'à la Game Boy avec GB Recompiled .

Vous filez à cet outil un fichier .gb et il vous sort OKLM un dossier avec du code C, un CMakeLists.txt et tout ce qu'il faut pour le compiler. Vous lancez cmake puis ninja, et votre vieux Pokemon Bleu tourne nativement sur votre PC plutôt que de passer par un émulateur qui simule le processeur Z80 à chaque frame.

Plutôt chouette non ???

Pour réussir ce tour de force, le recompilateur parse les opcodes Z80 de la cartouche, construit un graphe de contrôle de flux et résout les sauts indirects (genre les tables de jump, le truc qui rend la décompilation galère parce que l'adresse de destination dépend de la valeur d'un registre). Le taux de découverte dépasse alors les 98% même sur des RPGs bien touffus... pas mal pour de l'analyse purement statique !

Côté compatibilité, 7 jeux sont pour le moment validés : Tetris, Pokemon Blue, Donkey Kong Land, Kirby's Dream Land, Zelda Link's Awakening, Castlevania et Super Mario Land.

Par contre, attention, tous les jeux ne passent pas encore. Le runtime embarque un rendu PPU scanline , un système audio 4 canaux et les contrôleurs mémoire MBC1, MBC2, MBC3 et MBC5. Et comme tout ça tourne avec SDL2, du coup ça compile tranquillou sur macOS, Linux et Windows sans broncher !

Y'a aussi des outils de vérification assez bien pensés. Par exemple, un mode différentiel lance le binaire recompilé et un interpréteur Z80 côte à côte, puis compare l'exécution cycle par cycle avec une implémentation de référence. Tant que ça colle, le portage est fidèle !

Et y'a aussi un script Python basé sur PyBoy qui génère des traces d'exécution pour repérer les instructions que l'analyse statique aurait loupées. Voilà, ce que je veux vous dire c'est que c'est pas juste un traducteur tout bête. Y'a vraiment tout un pipeline de tests derrière pour assurer le meilleur portage possible.

Si vous avez suivi les autres projets autour de la portable de Nintendo, comme le GB Interceptor qui espionne le bus mémoire avec un adaptateur USB ou le Game Bub et son FPGA Xilinx, GB Recompiled choisit plutôt l'angle purement logiciel. Là où le FPGA reproduit les circuits et l'émulateur simule le CPU, la recompilation traduit le code source. Ce sont 3 philosophies différentes mais qui ont un seul et même objectif : Faire en sorte que ces jeux ne crèvent pas avec leurs cartouches en plastique gris.

Pour tester chez vous, c'est du classique : un petit terminal, un petit git clone, un cmake, un ninja, et vous passez votre fichier .gb au recompilateur.

git clone https://github.com/arcanite24/gb-recompiled.git
cd gb-recompiled
cmake -G Ninja -B build .
ninja -C build

# Générer le code C depuis la ROM
./build/bin/gbrecomp path/to/game.gb -o output/game

# Compiler la nouvelle version en C
cmake -G Ninja -S output/game -B output/game/build
ninja -C output/game/build

# Optionnel: Baisser ou augmenter le niveau d'optimisation
cmake -S output/game -B output/game/build -DGBRECOMP_GENERATED_OPT_LEVEL=2

# Et on lance !
./output/game/build/game

Google n'a jamais sorti d'API publique pour NotebookLM , son outil qui transforme vos documents en podcasts, quiz et autres résumés grâce à l'IA. Pas de SDK, pas de CLI, y'a rien du tout alors on est tous triiiiiste. A peine juste une interface web avec ses boutons moches et ses menus déroulants, mais impossible à scripter ou à intégrer dans le moindre pipeline bash.

Mais un dev bien inspiré a reverse-engineeré les endpoints REST internes et a pondu notebooklm-py, une lib Python de 168 Ko qui fait tout ce que le web UI refuse de faire. Franchement, c'était pas trop tôt ! Vous en avez rêvé, lui l'a fait !

Un pip install notebooklm-py et voilà, vous avez accès à toute la machinerie Notebook LM à savoir : créer des notebooks, injecter des sources (URLs, PDF, vidéos YouTube, fichiers Google Drive, documents Word, images PNG), poser des questions à vos docs, et surtout générer du contenu... podcasts audio en MP3, vidéos explicatives en MP4, quiz, flashcards, slides en PPTX, infographies en PNG, mind maps en JSON.

Carrément dingue ! Et tout ça pilotable depuis votre terminal zsh ou en script Python async.

En fait, le vrai bonus c'est que la lib déverrouille des fonctionnalités que l'interface web ne propose même pas comme télécharger tous vos podcasts d'un coup en batch au lieu de cliquer un par un sur chaque fichier MP3, exporter vos 50 flashcards en JSON structuré au lieu de juste les afficher à l'écran ou encore récupérer vos slides en PPTX éditable plutôt que le PDF figé.

Ce genre de features, on avait fini par accepter que Google s'en fiche mais pourtant, extraire l'arbre complet d'une mind map en JSON pour la balancer dans D3.js ou Mermaid... clairement c'est un truc que Google aurait dû proposer depuis le début !

Côté CLI, c'est propre. Vous vous authentifiez une fois via notebooklm login (ça ouvre Chromium via Playwright pour choper les cookies de session Google), puis vous enchaînez les commandes.

notebooklm create "Ma Recherche" pour créer un notebook vide,

notebooklm source add ./mon-rapport.pdf pour balancer vos fichiers,

notebooklm generate audio "rends ça punchy" --wait pour lancer la génération de podcast,

et notebooklm download audio ./podcast.mp3 pour récupérer le MP3 sur votre disque.

On peut même éditer ses slides individuellement avec des prompts en langage naturel, du genre "ajoute un graphique sur cette slide-là" !

Pour ceux qui veulent brancher ça dans leurs pipelines, y'a comme je le disais l'API Python async complète. Vous pouvez donc monter un petit cron qui ingère vos derniers bookmarks le vendredi soir, et génèrer un résumé audio de 5 minutes, puis balancer le MP3 directement sur votre NAS Synology.

D'ailleurs, si vous avez déjà joué avec des outils pour booster votre productivité avec l'IA , c'est un peu dans la même veine... sauf qu'ici on tape directement dans les tripes des serveurs Google, sans intermédiaire. Ça tourne avec du Python, et y'a même un mode "agent" (un skill en fait) pour brancher ça dans Claude Code ou Codex. Pas mal, hein ?

Le fait que ça gère aussi la recherche web et Drive avec import automatique des résultats dans vos notebooks, c'est top, un peu comme Oboe qui génère des cours complets via IA , mais en version terminal. Et surtout, pas d'abonnement mensuel à payer, c'est votre propre compte Google qui fait tourner la machine.

Bien sûr, ça reste du reverse-engineering d'APIs non-documentées de Google, ce qui fait que les endpoints REST peuvent changer du jour au lendemain et tout péter. Le projet le dit clairement, c'est plutôt taillé pour du prototypage, de la recherche ou des projets perso et SURTOUT PAS pour de la prod sur un serveur Nginx en front avec 10 000 utilisateurs prêts à ruer dans les brancards en cas de panne.

Et puis faut quand même s'authentifier via un vrai compte Google avec Playwright et Chromium, donc pas question de faire tourner ça sur un serveur headless sans un minimum de config.

Bref, tant que Google ne coupe pas ses endpoints, c'est open bar.

Profitez-en !

Un développeur indépendant a porté xemu, l'émulateur Xbox open source , sur Android sous le nom de X1 BOX. L'application était d'abord vendue 8 dollars sur le Play Store, ce qui a provoqué un tollé côté communauté et chez les développeurs du projet original. Une version gratuite est depuis disponible sur GitHub.

X1 BOX : la Xbox de 2001 dans votre poche

Le projet xemu existe depuis plusieurs années sur PC et permet d'émuler la Xbox originale de 2001 avec une bonne précision. Le développeur izzy2lost, déjà connu pour PSX2 (un émulateur PS2 sur Android) et plusieurs portages de jeux N64, a repris le code source pour le faire tourner sur téléphone.

Son application X1 BOX propose une interface Android avec un lanceur de jeux, la récupération automatique des jaquettes, et des commandes tactiles qui disparaissent quand vous branchez une manette Bluetooth. Un assistant de configuration guide l'utilisateur pour pointer vers les fichiers système nécessaires.

Côté matériel, il faut compter sur un appareil costaud : Android 8.0 minimum, un processeur ARM 64 bits avec support Vulkan, et au moins 8 Go de RAM. Un Snapdragon 8 Gen 2 ou plus récent est recommandé pour que ça tourne de façon à peu près jouable. Autant dire que les petits téléphones d'entrée de gamme auront du mal à tenir la route.

8 dollars pour du code gratuit

Le problème est venu du modèle économique. izzy2lost a mis X1 BOX sur le Google Play Store à 8 dollars. Techniquement, vendre un logiciel GPL n'est pas illégal, mais dans la communauté open source, reprendre le travail des autres pour le monétiser sans collaborer, ça n’est pas très chic.

Le développeur principal de xemu a réagi sur les réseaux : « Les arnaqueurs arnaqueront toujours ». Il a aussi confirmé qu'une version officielle Android de xemu arriverait, gratuite. Depuis, izzy2lost a mis le code et l'APK en téléchargement libre sur GitHub.

L'émulation Xbox sur Android, c'est un cap qui vient d'être franchi, et ça fait plaisir. Sauf que la méthode laisse un goût un peu amer. Prendre un projet communautaire maintenu bénévolement, le packager pour Android et le vendre 8 dollars sans prévenir personne, c'est le genre de truc qui crispe à juste titre.

Le code est sous GPL, donc techniquement c'est légal, mais l'éthique, c'est autre chose. En tout cas, la bonne nouvelle c'est que le portage existe et qu'il est gratuit sur GitHub. On attend quand même la version officielle de xemu, qui devrait régler la question une bonne fois pour toutes.

Source : Time Extension

Le ministère des Transports britannique vient de publier un appel d'offres pour trouver un développeur C++ capable de maintenir le NAPAM, le modèle qui prédit la répartition des passagers dans les aéroports du pays. Le programme tourne sur 10 000 lignes de code avec Excel comme interface. Budget prévu : 100 000 livres sur trois ans.

10 000 lignes de C++ et un fichier Excel

Le NAPAM (pour National Aviation Passenger Allocation Model), est le logiciel qui permet au gouvernement britannique de prévoir comment les passagers se répartissent entre les aéroports du pays. Il couvre 29 aéroports britanniques qui gèrent des vols internationaux, plus quatre hubs à l'étranger : Amsterdam, Dubaï, Francfort et Paris.

Le programme tourne dans un environnement .NET en C++ et se nourrit de données via des fichiers Excel. Il effectue des calculs itératifs jusqu'à atteindre certains seuils définis par l'utilisateur, comme la capacité maximale de passagers d'un aéroport donné. Le tout tient en 10 000 lignes de code. Pour un outil qui influence les décisions de politique aérienne du Royaume-Uni, on est sur quelque chose d'assez artisanal.

Un appel d'offres à budget serré

Cet appel d'offres a été lancé pour un contrat de trois ans, avec un budget de 100 000 livres, soit l'équivalent de 120 000 euros. Le poste consiste à fournir un support technique ad hoc aux analystes et économistes de l'équipe Aviation Appraisal and Modelling.

Le modèle existe depuis au moins 2010 et a été mis à jour en 2017, 2022 et 2024. Le précédent contrat de maintenance avait été attribué au cabinet américain Jacobs, qui avait facturé environ 97 000 livres rien que pour les mises à jour de 2020. Le ministère précise quand même que le budget est « non engageant » et qu'il ne garantit ni le volume de travail ni les dépenses.

Un cas d'école du logiciel legacy

Ce genre de situation est un classique dans les administrations : un outil développé il y a quinze ans par un prestataire, maintenu au fil de l'eau par un consultant externe, et dont personne en interne ne maîtrise vraiment le code.

Le NAPAM est quand même utilisé pour orienter les investissements aéroportuaires et les projections de trafic du pays. Si le développeur sous contrat décide de partir à la retraite ou de changer de métier, c'est tout le modèle de prévision qui se retrouve en difficulté.

Et avec 10 000 lignes de C++ legacy plus des macros Excel, on imagine la joie du prochain développeur qui reprendra le dossier.

C'est quand même un peu vertigineux de se dire que les prévisions du trafic aérien d'un pays du G7 dépendent d'un programme en C++ maintenu par un seul prestataire pour 33 000 livres par an.

Avec ce budget, on est à peine sur le tarif d'un développeur junior à mi-temps à Londres. On ne dit pas que le modèle est mauvais, mais la dépendance à une seule personne sur du code legacy avec Excel comme interface, ça fait quand même un peu froid dans le dos.

Source : The Register

Un développeur a créé Galagino, un émulateur open source qui fait tourner Pac-Man, Galaga, Donkey Kong et trois autres classiques de l'arcade sur un simple microcontrôleur ESP32. Le projet est gratuit, le code est sur GitHub, et avec quelques composants et une imprimante 3D vous fabriquez votre propre mini borne pour presque rien.

Six jeux d'arcade sur une puce à quelques euros

Galagino est un projet open source développé par Till Harbaum. Le principe : émuler des jeux d'arcade des années 80 sur un ESP32, cette petite puce à double coeur cadencée à 240 MHz qui coûte une poignée d'euros. Et ça ne rigole pas côté catalogue, puisque six titres sont pris en charge : Galaga, Pac-Man, Donkey Kong, Frogger, Dig Dug et 1942.

L'émulation est complète, avec le son et la vidéo, le tout affiché sur un petit écran TFT de 320 x 240 pixels en 2 à 3 pouces. Pour les contrôles, cinq boutons poussoirs suffisent, ou un joystick si vous préférez. Le Galaga d'origine tournait sur trois processeurs Z80 plus deux puces dédiées aux entrées et au son. Ici, l'ESP32 gère tout seul, et les deux coeurs sont quand même bien sollicités.

March 2026 TIOBE Index stays largely steady, with SQL and R swapping spots, as Paul Jansen explains why the index still relies on search engine hits.

The post TIOBE Index for March 2026: SQL and R Swap Spots as Jansen Defends Search-Based Rankings appeared first on TechRepublic.

Un développeur a créé un langage de programmation dont le code source est composé de M&M's colorés. Six couleurs, six familles d'instructions, et les programmes se compilent sous forme d'images PNG. Le plus rigolo ? On peut même prendre en photo de vrais bonbons posés sur une table pour générer du code exécutable. Le projet, baptisé MnM Lang, cartonne.

Des bonbons à la place du code

L'idée est partie d'un paquet de GEMS (l'équivalent indien des M&M's) ouvert un peu trop fort. Mufeed VH, développeur et auteur du projet, a vu les confiseries former une sorte de flèche sur le sol et s'est dit que ça ferait un bon point de départ pour un langage de programmation. Le résultat s'appelle MnM Lang, un langage dit "ésotérique" où le code source est écrit sous forme de rangées de bonbons.

Six couleurs sont utilisées, chacune correspondant à un type d'instruction : le bleu gère le flux de contrôle (sauts, appels, arrêt), le vert s'occupe des variables et de la pile, le jaune traite les opérations mathématiques, l'orange gère les entrées/sorties, le marron s'occupe des labels et des chaînes de caractères, et le rouge de la logique booléenne et de la manipulation de pile. Le nombre de bonbons dans une rangée détermine l'opcode : six bonbons à la suite, par exemple, ça donne la valeur 5.

Du vrai code dans une image PNG

Dans un premier temps, les programmes sont écrits en ASCII, puis compilés en PNG. Dans l'image, chaque lettre est remplacée par un Sprite de bonbon. Et le truc assez fou, c'est que ça marche aussi dans l'autre sens : on peut prendre une photo de vrais bonbons posés sur un fond blanc, et le décodeur d'image reconstitue le code source à partir des couleurs détectées.

Côté limitations, les images ne sont pas très douées pour stocker du texte. Les chaînes de caractères et les variables initiales passent donc par un fichier JSON séparé qui accompagne le programme.

Malgré cette contrainte, MnM Lang permet d'écrire de vrais programmes : Hello World, FizzBuzz, factorielle. Un terrain de jeu interactif est disponible sur le site du projet, avec un éditeur en ligne, un rendu visuel des bonbons et même un affichage de l'arbre syntaxique.

On a donc là un projet rigolo et coloré, et ça change un peu ! MnM Lang ne va pas remplacer Python ou Swift. Ce genre de truc nous rappelle que la programmation, ce n'est pas qu'un outil de travail et de production, mais ça peut aussi être du fun et de l'amusement, même si le niveau d'ingénierie derrière (compilateur, décodeur d'images, terrain de jeu web) montre que le projet est loin d'être une simple blague. Bref, si vous avez un paquet de M&M's qui traîne et un dimanche après-midi devant vous, vous savez quoi faire.

Source : Hackaday

MinIO, tout le monde ou presque connaît car c'est LE truc quand on veut du stockage objet S3-compatible auto-hébergé sous Linux. Sauf que voilà... la licence AGPL, ça pique pour pas mal de boîtes qui ne veulent pas se retrouver à devoir ouvrir leur code.

Du coup, y'a un nouveau projet qui débarque dans le tiek et qui devrait en intéresser plus d'un. C'est RustFS , codé en Rust (comme le nom le laisse deviner mes petits Sherlock) et 100% compatible S3. En gros, vous prenez votre stack MinIO existante, vous remplacez par ce truc, et en fait tout continue de fonctionner pareil... Vos buckets, vos applis, vos scripts Python, boto3... tout pareil !

docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest

Un dungeon crawler dans l'explorateur de fichiers Windows c'est maintenant une réalité grâce à Directory Dungeon qui transforme votre arborescence de fichiers en donjon, avec monstres, du loot et des combats au tour par tour. Du coup forcément, ça m'a intrigué.

Dans ce jeu, vous ouvrez un dossier C:\DirectoryDungeon sur votre PC et dedans y'a des salles de donjon. Ensuite, pour vous déplacer, vous glissez-déposez votre dossier "Player" dans une nouvelle pièce. Oui du vrai drag-and-drop dans explorer.exe.

Et votre inventaire, c'est un sous-dossier. Vos armes et armures, vous les équipez en les déposant dans le répertoire "Equipment". Et quand vous tombez sur un monstre, le combat se résout automatiquement dans une fenêtre console cmd.exe à côté. Du texte, des chiffres, du tour par tour. C'est old school à mort.

Windows 11 Insider Beta Build 26220.7859 (KB5077223) for 25H2 adds a Microsoft 365 upgrade option in Settings, plus taskbar and File Explorer fixes.

The post New Windows 11 Insider Build Fixes Taskbar, File Explorer Bugs appeared first on TechRepublic.

Recalbox vient de publier la version 10 de sa distribution open-source française dédiée au rétrogaming. Au programme, le support du Raspberry Pi 5 et du Pi 500, l'arrivée sur Steam Deck en version LCD et OLED, de nouvelles émulations dont la Xbox originale et la GameCube, une interface entièrement revue, et du matériel dédié pour les fans de CRT et de bornes d'arcade. Que du bon.

Du Raspberry Pi 5 au Steam Deck

La version 10 de Recalbox élargit donc son catalogue de matériel compatible, et pas qu'un peu. Le Raspberry Pi 5 est désormais pris en charge, y compris dans sa version 2 Go de RAM, tout comme le Raspberry Pi 500. Mais surtout, la distribution débarque sur les consoles portables PC. Le Steam Deck, en version LCD comme OLED, profite d'une intégration qui gère la luminosité et le mode veille directement depuis l'interface. La très bonne Asus ROG Ally et le Lenovo Legion Go débarquent aussi, même si le support reste expérimental pour le moment. On passe quand même d'un projet pensé pour Raspberry Pi à une distribution qui tourne sur une tonne de machines différentes.

Une interface repensée

Côté émulation, la version 10 ajoute la Xbox originale exclusivement sur PC et Steam Deck (sous réserve de puissance suffisante). Sur Raspberry Pi 5, ce sont la GameCube, la Wii, la Nintendo DS et le Sega Model 3 qui font leur entrée. Si ces systèmes tournent de manière fluide dans la majorité des cas (environ 80 %), on atteint ici les limites matérielles du Pi 5 : certains titres très gourmands pourront donc montrer quelques signes de ralentissement.

Du matériel pour les fans de rétro

Pour ceux qui veulent aller plus loin que le logiciel, Recalbox continue de proposer du matériel dédié de qualité. Le RGB DUAL 2 et le RGB JAMMA 2 permettent de brancher des écrans CRT et des bornes d'arcade avec une gestion dynamique des résolutions. Le projet pousse le concept encore plus loin avec le Recalbox Card Reader et ses RecalCards, des cartouches physiques qui lancent un jeu quand on les insère, à l'ancienne. Et si vous cherchez du clé en main, la boutique propose des kits RecalTower préinstallés avec Raspberry Pi 5, et ça on aime.

J'ai toujours un Raspberry Pi avec Recalbox chez moi, et tout ceci me donne bien sûr très envie de tout mettre à jour !

Article invité publié par Vincent Lautier .
Vous pouvez aussi me lire sur mon blog , sur Mac4ever , ou lire tous les tests que je publie ici, comme cette Webcam 4K , ou ce dock Thunderbolt 5 .

Si vous avez grandi dans les années 90 ou 2000 , il y a de fortes chances que vous ayez connu cette époque un peu étrange où le DVD tentait de devenir le centre de divertissement ultime. On achetait nos films en boite, on les collectionnait fièrement sur nos étagères, et on passait parfois pas mal de temps à naviguer dans des menus (souvent en 4/3) avec notre télécommande.

Mais est-ce que vous vous souvenez de ces fameux "jeux" planqués dans les bonus ?

C'était un truc de fou quand on y repense. Certains éditeurs voulaient absolument exploiter le côté "Digital Versatile Disc" et nous pondaient des mini-jeux interactifs. C'était un peu l'équivalent informatique du bouclier de Captain America, ça protégeait l'intérêt du disque en rajoutant une couche de fun (ou de frustration, c'est selon). Un peu comme ces émissions télé des années 80/90 qui nous faisaient rêver de futur interactif.

Dans cette vidéo géniale de la chaîne memoria.exe , on suit une exploration de ces pépites dénichées chez Goodwill. Le concept est de tester des jeux sur des DVD de films que l'on n'a même pas vus, juste pour l'expérience "gaming". Et le moins qu'on puisse dire, c'est que c'est souvent techniquement pété.

Vous utilisiez les flèches de votre télécommande de salon pour déplacer un curseur ou faire des choix. C'était poussif, avec une latence perceptible due aux limites de l' authoring DVD et aux accès mécaniques du lecteur (le fameux bruit de moulin à café au moindre clic), mais on s'en foutait, c'était "interactif" !

Gobliiins, Gobliins 2, Goblins 3... si vous avez connu les point-and-click de Coktel Vision dans les années 90, vous allez kiffer !! Pourquoi ? Hé bien parce que Pierre Gilhodes, le créateur original, vient de lâcher GOBLiiNS6 sur itch.io pour une dizaine de dollars.

On y retrouve Fingus et Winkle, les deux héros de Gobliins 2, partis cette fois à la recherche du Prince Bouffon, fils du roi Angoulafre, dans un monde médiéval en guerre, avec de la magie, et des puzzles complètement tordus à résoudre.

Mais avant, un petit rappel pour les bébés qui me lisent. En fait dans la série des Goblins, le nombre de "i" dans le titre correspond au nombre de personnages jouables. Gobliiins = 3 persos. Gobliins 2 = 2 persos. Goblins 3 = 1 perso. Du coup GOBLiiNS6 avec ses 2 i, c'est donc encore un duo à coordonner intelligemment pour progresser (et oui, je sais compter ^^).

Et c'est pas un fan game ou un énième remake fait à l'arrache, puisque c'est Pierre Gilhodes lui-même qui est aux manettes. Le bonhomme avait déjà sorti GOBLiiiNS5 sur Steam en 2023 (avec 3 i, donc 3 personnages, z'avez capté ??). GOBLiiNS6 c'est donc finalement la suite directe.

Le jeu propose 16 niveaux en 2D au format 16/9, bourrés d'énigmes à résoudre. Chaque personnage gère son propre inventaire, pas de partage entre les deux (Vous allez tellement galérer à vous souvenir qui trimballe quoi ^^) et le système de jeu repose sur la coopération entre les deux compères, car chacun a des capacités différentes pour débloquer les situations.

Le piège et le côté fun de cette série de jeux, c'est donc justement de tester toutes les combinaisons possibles entre les personnages et les objets. Vous utilisez le mauvais perso au mauvais endroit ? Hop, animation comique et retour à la case départ. C'est voulu ! C'est absurde, c'est drôle, et c'est tout l'ADN de la franchise !

C'est un point-and-click qui va certainement vous rappeller l'époque où les jeux d'aventure français tenaient la dragée haute aux LucasArts et Sierra de l'époque. Coktel Vision, c'était quand même Woodruff, Lost in Time, Ween... etc. Quelle époque !!

GOBLiiNS6 est disponible en français et en anglais et vous pourrez le lancer au choix en plein écran ou fenêtré... car oui c'est du Windows pur !! Pas de Mac ni de console pour le moment. Voici une petite vidéo si vous voulez voir à quoi ça ressemble :

Street Fighter II, c'est dans l'esprit de la plupart d'entre nous, 1991, les salles d'arcade qui puent la clope et les pièces de 10 francs qui s'enchaînent... et surtout un écran-titre qui affiche "WORLD WARRIER" au lieu de "WORLD WARRIOR". Ouais, y'avait une coquille dans le titre d'un des jeux de baston les plus légendaires de l'univers et personne ne l'a jamais su !

Magnifique hein ?

Le problème, c'est que sur les bornes d'arcade Capcom CPS1, les graphismes sont gravés dans des puces ROM. Du vrai read-only qu'on grave une bonne fois pour toutes et qu'on ne touche PLUS après. Et en 1991, les puces ROM coûtaient un bras et les délais de production étaient assez dingues... Donc impossible pour Capcom de faire regraver quoi que ce soit même pour une malheureuse lettre.

Nous sommes donc toujours en 1991, à 3 jours de la deadline pour livrer le code ROM (la seule puce encore modifiable à ce stade) et quelqu'un se rend compte du bug.

Horreur malheur ! C'est la panique et tout le monde se met à réfléchir à une solution... Quand soudain, un hack digne des plus belles bidouilles émerge de ces cerveaux endoloris par tant de travail.

Il faut savoir que sur le CPS1, chaque graphisme est découpé en "tiles" c'est à dire des petits carrés de 8×8 pixels. Et le truc important, c'est que chaque tile ne contient pas une lettre entière mais un BOUT de lettre. Le logo "WORLD WARRIOR", c'est en fait une mosaïque de 16 tiles collées les unes aux autres, et chaque carreau contient des fragments des lettres voisines. Impossible donc de toucher à ces carreaux une fois gravés dans la ROM graphique... Mais la table qui dit "colle CE carreau ICI avec CETTE palette de couleurs"... ça, c'était encore modifiable dans la ROM code.

Le hic c'est qu'il fallait composer avec les tiles existantes car pas moyen d'en créer de nouvelles !

Du coup, l'équipe s'est mise à passer au crible les centaines de tiles déjà gravées dans la ROM, une par une, pour trouver des morceaux compatibles avec les bonnes lettres. Et bonne nouvelle... pour certaines tiles, ils ont trouvé des équivalents dans le mot "WORLD" sur l'écran-titre. Et en réarrangeant le puzzle, ils ont réussi à afficher presque tout "WARRIOR" correctement. Presque. Parce que le "i", lui, ressemblait maintenant à un "L" minuscule... il manquait le point mes amis !!

Et c'est là que ça devient du grand art car pour dessiner ce petit point, il leur fallait un carreau avec quasi rien dessus. Ils ont fini par repérer la tile 0x96 dans la ROM... un carré de 8×8 avec UN SEUL pixel allumé dans le coin bas gauche. Ce pixel appartient en fait au mollet de Guile. Ni plus ni moins.

En changeant sa palette (exit la teinte vert kaki, bonjour la couleur du logo), ils l'ont ensuite collé 3 fois au bon endroit pour dessiner le point du "I". Et personne n'a finalement rien capté pendant des DÉCENNIES.

Hé voilà comment, si vous avez joué à Street Fighter II en arcade dans les années 90, vous aviez littéralement un bout de la jambe de Guile planqué dans l'écran-titre sans le savoir. Magnifique non ?

C'est Fabien Sanglard qui a déterré toute cette histoire il y a quelques années, en analysant le code source du CPS1, aidé d'une interview d'Akira Nishitani (un des créateurs du jeu) datant de 1991.

C'est le genre de bidouille qu'on ne fait plus aujourd'hui avec les mises à jour en ligne mais à l'époque, quand la ROM était gravée, c'était FINITO donc fallait se débrouiller avec ce qu'on avait sous la main quand y'avait un souci.

Et si les meilleures techniques de game dev des années 2000 revenaient dans votre navigateur ?

ArcadeGPU, c'est un moteur de jeu complet qui tourne dans le navigateur grâce à WebGPU. C'est une vraie architecture de jeu avec walkmesh, hitbox BSP, moteur de script, pipeline graphique à la PS1 et même la physique Jolt intégrée (un moteur open source utilisé dans certains gros jeux).

Le truc c'est que le dev derrière, un Français qui bosse seul sur le projet, a pris le parti de ressusciter des techniques qu'on utilisait entre 2000 et 2010 dans le développement de jeux. Du walkmesh pour la navigation des personnages, du hitmesh pour les collisions, du draw call only pour le rendu... Des trucs qu'on ne voit quasi plus dans les moteurs modernes, et pourtant c'est redoutablement efficace pour les indés. Bon, après faut quand même être à l'aise avec TypeScript et la stack web, car c'est pas un moteur drag-and-drop à la GameMaker.

Car oui comme tout est en TypeScript, vous codez votre jeu comme une app web classique. Vous modifiez votre fichier main.ts, le jeu se rafraîchit en temps réel sans avoir à tout relancer. Et vous avez toute la pile web en support, du Web Audio API au CSS en passant par les workers async... Quand on compare avec les 45 secondes de build d'un projet Unity moyen, y'a pas photo.

Y'a aussi un paquet de démos jouables directement sur le site du projet et c'est pas des petits exemples bidon avec un cube qui tourne. Vous y trouverez de vrais prototypes de jeux complets, de la 2D rétro au rendu toon 3D avec ombres volumétriques. L'idée c'est de fournir des templates prêts à l'emploi, vous choisissez le gameplay qui vous correspond et vous partez de là (plutôt que de tout repenser from scratch).

D'ailleurs y'a même un jeu en bêta développé avec le moteur, un Sokoban versus, pour voir ce que ça donne en conditions réelles.

Côté compatibilité, ça tourne sur les navigateurs qui gèrent WebGPU (Chrome, Edge, et Firefox en mode expérimental avec le flag dom.webgpu.enabled). Pour Safari et mobile, c'est plus aléatoire pour le moment donc attention si votre cible c'est iOS. Le projet est open source sous licence Apache 2.0, dispo sur SourceForge et ça pèse environ 400 Mo avec toutes les démos.

Et le rendu... C'est du pipeline PSX complet avec ombrage toon, volumes d'ombre, le tout dans le navigateur. Pour les nostalgiques de la première PlayStation, c'est un peu la papillote Révillon version code (oui ça change des madeleines ^^), sauf que là, c'est vous qui créez les jeux.

Voilà, je trouve que cette approche old-school mixée avec la techno web moderne c'est pas bête du tout. Si vous êtes dev indé et que les usines à gaz style Unity ou Unreal vous donnent des boutons, ça vaut peut-être le coup d'aller jeter un oeil. Seul bémol, la doc est encore un peu légère, donc faudra fouiller dans les exemples pour comprendre l'API.

Bref, merci à Slay3r pour le partage et bravo !