Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Hier — 29 juin 2026Flux principal

Un développeur a fait tourner Swift sur un Apple II de 1977

29 juin 2026 à 15:54

Swift, le langage maison qu'Apple a sorti en 2014 pour remplacer le vieillissant Objective-C, vient de débarquer sur une machine qui a quarante-neuf ans de plus que lui. Yeo Kheng Meng, un bidouilleur basé à Singapour, a restauré un Apple II Plus puis s'est demandé jusqu'où il pouvait pousser ce vieux tromblon, ce qui a donné SwiftII, un petit environnement Swift qui tourne aussi bien sur l'Apple II d'origine de 1977 que sur les IIe qui ont suivi.

Le défi donne le vertige quand on connaît la bête. L'Apple II carburait à un processeur 6502 cadencé à 1 MHz avec 4 Ko de mémoire à sa sortie, là où Swift a été pensé pour des machines des milliards de fois plus puissantes, et il a fallu pousser la RAM à 48 Ko pour espérer y faire tenir quoi que ce soit.

Plutôt que de traduire directement le code en instructions 6502, Yeo a repris une idée qu'Apple avait déjà eue en 1979 avec son Apple Pascal, qui consistait à compiler le programme en bytecode, c'est-à-dire un code intermédiaire générique, avant de l'exécuter dans une machine virtuelle, une sorte de processeur simulé en logiciel par-dessus le vrai. Presque un demi-siècle d'écart, et la même astuce pour contourner les limites du 6502.

Le pipeline reste volontairement minimaliste pour grappiller chaque octet, puisque le code source passe dans un analyseur, puis un parser qui crache directement le bytecode sans construire d'arbre intermédiaire, le tout avalé par une petite machine virtuelle à pile largement inspirée du livre Crafting Interpreters de Robert Nystrom.

Forcément, ce Swift-là est une version croupion. Il n'existe qu'un seul type de nombre, l'entier signé sur 16 bits, donc rien au-delà de -32 768 à 32 767, et surtout aucun nombre à virgule vu que le 6502 n'a pas de quoi calculer ça. Les chaînes de caractères sont du pur ASCII, les noms de variables plafonnent à onze caractères, et exit les closures, dictionnaires, gestion d'erreurs et autres async/await.

Côté ce qui marche quand même, on récupère les let et var avec inférence de type, les conditions, les boucles, les fonctions, les optionnels, les tableaux et même l'interpolation de chaînes, de quoi écrire de vrais petits programmes. Le projet embarque d'ailleurs un jeu de motos lumineuses et quelques démos graphiques qui tournent pour de bon sur le matériel d'époque.

La contrainte la plus délicate reste la mémoire, parce qu'une fois ProDOS chargé il ne reste qu'environ 40 000 octets pour votre programme, et comme le 6502 ne sait pas adresser davantage, il faut jongler avec des banques de mémoire commutées comme à la grande époque.

Le tout est écrit en C90, compilé avec cc65, et distribué en neuf images disque différentes selon les machines visées. Détail savoureux, Yeo a bouclé ce chantier en deux mois avec l'aide de Claude Opus 4.8 et de Codex, là où il estime que seul, ça lui aurait coûté deux à trois ans de travail.

Du coup, on a un langage de 2014 qui cause à une puce de 1977 grâce à une recette de 1979. C'est parfaitement inutile, et c'est exactement pour ça que c'est chouette.

Source : Hackaday

À partir d’avant-hierFlux principal

IoToS - Le prof qui a codé un OS de zéro pour ses élèves

Par : Korben ✨
24 juin 2026 à 13:28

Jean-Marc Biechy est prof d'électronique et d'informatique à l'Institution Saint-Jean de Colmar et il vient de m'envoyer un truc qui m'a scotché. Avec ses élèves, il bidouille des projets Arduino, et plutôt que d'empiler des bouts de code à chaque nouveau montage, il a fait un choix un peu fou : écrire son propre système d'exploitation en partant de zéro pour un microcontrôleur.

Ça s'appelle IoToS, pour Internet of Things micro Operating System, et ça transforme un Arduino UNO R4 ou un ESP32/8266 en vrai petit nœud réseau avec un accès en ligne de commande qui ressemble vachement à du bon vieux terminal Linux.

Vous branchez la carte, vous ouvrez un terminal série (ou un Telnet sur le port 23), et là vous tapez des commandes comme ping, tracert, netstat, dir, ip ou dhcp on tout ça directement sur Arduino.

Ce qui est chouette avec son approche c'est qu'elle est pédagogique car un Arduino tout nu, c'est un automate avec un setup() qui s'exécute une fois, une loop() qui tourne en boucle à l'infini, et basta.

Et à l'autre bout du spectre, vous avez de vrais OS temps réel (RTOS), souvent trop gros ou trop austères pour intéresser un élève de Bac Pro. Et entre les deux, y'avait rien qui faisait vraiment le pont entre l'automate et un vrai petit OS avec sa ligne de commande.

Jean-Marc a donc créé ce chaînon manquant en découpant son code exactement comme un OS. Un Boot Firmware avant le setup, un Load Driver qui gère la connexion réseau et l'écran, un Kernel qui n'est autre que la loop(), un CLI dans un fichier shell_Cmdline.h, et des applis par-dessus.

La bestiole embarque donc un serveur web AJAX qui sert des pages HTML depuis une carte MicroSD, un serveur FTP pour balader les fichiers via FileZilla, une synchro NTP et un datalogger CSV horodaté. Le tout sur un noyau coopératif, sans RTOS, le code métier de votre projet étant compilé dans le même firmware.

Et c'est là qu'on mesure le boulot d'orfèvre puisque ce firmware complet tient dans 142 Ko, soit 54% de la flash de l'UNO R4, et il reste près de 19 Ko de RAM libre sur les 32. Caser un shell réseau, un serveur web et du FTP là-dedans sans tout faire planter, c'est pas donné à tout le monde, le mec est doué !

Et avec cette base, ses élèves montent des prises IP commandables au navigateur, une caméra de surveillance sur LilyGo déclenchée par un détecteur de mouvement, une station météo consultable en ligne, une alarme PIR qui envoie un mail, de la gestion de chauffage à distance, ou du pilotage de LED RVB et de projecteurs DMX par Ethernet.

La prise IP sert d'ailleurs de système minimal de référence, et le reste, vous pouvez l'étendre en ajoutant vos propres commandes CLI et vos pages web dans les fichiers .h prévus pour.

Jean-Marc raconte y avoir passé environ 2000 heures de code et de tests, juste pour voir si c'était possible d'en écrire un tout seul. Il est parti de bibliothèques existantes (LittleFS, ping, FTP, dir) qu'il a patiemment fait discuter ensemble... Faut dire que recoder un OS de zéro pour le plaisir d'apprendre , c'est un sport à part entière et malheureusement, trop peu de gens d'y essayent.

Son code source est commenté et distribué librement sous licence GNU LGPL v2.1, donc réutilisable y compris pour un usage commercial. Tout est à télécharger sur le site du projet , avec la doc PDF, les vidéos de démo et la liste complète des commandes.

Si vous avez un Arduino R4 qui prend la poussière, vous savez maintenant quoi en faire ! Bravo Jean-Marc !!

Git 2.55 active Rust par défaut, et la fin du tout-C est déjà programmée

12 juin 2026 à 14:44

Vingt et un ans après sa création par Linus Torvalds, Git amorce pour de bon son changement de langage. La première version de test de Git 2.55, publiée hier, active par défaut le code Rust dans le gestionnaire de versions le plus utilisé au monde, celui qui héberge l'historique d'à peu près tous les projets logiciels de la planète.

Jusqu'ici, il fallait réclamer explicitement le Rust au moment de compiler le logiciel, c'est-à-dire de le fabriquer à partir de son code source, via une option baptisée WITH_RUST ou via le système de build Meson. Git 2.55 inverse la logique : le Rust est désormais supposé présent, et c'est pour s'en passer qu'il faut lever la main, avec une nouvelle option NO_RUST.

Pour situer, Rust est un langage de programmation conçu pour éliminer toute une famille de bugs mémoire, ceux-là mêmes qui font le bonheur des pirates depuis quarante ans. Git, lui, est écrit en C depuis 2005, un langage qui laisse au développeur l'entière responsabilité de ne pas se tirer une balle dans le pied.

Le chantier ne date pas d'hier. L'an dernier, Patrick Steinhardt, un des mainteneurs du projet, proposait d'introduire Rust dans le cœur de Git et d'en faire à terme une dépendance obligatoire pour fabriquer l'outil.

Git 2.52 avait franchi le premier pas fin 2025 en convertissant un petit module, varint.c, chargé de décoder des entiers à taille variable. Du code volontairement modeste : l'idée était de roder la chaîne de compilation, pas de réécrire Git.

Avec la 2.55, le rythme change. L'équipe prépare d'ailleurs le portage de xdiff, le moteur qui calcule les différences entre deux versions d'un fichier, autrement dit le cœur du métier de Git.

Et le calendrier est déjà là : à partir de Git 3.0, Rust sera obligatoire, sans aucune possibilité de le désactiver. Aucune échappatoire. L'option NO_RUST de la 2.55 n'est donc qu'un sursis.

Pour vous, rien ne change : les binaires fournis par votre distribution Linux, par Apple ou par GitHub arrivent déjà compilés. Ce sont les empaqueteurs et les plateformes un peu spéciales qui vont devoir installer la chaîne d'outils Rust.

Sauf que voilà, tout le monde n'a pas un compilateur Rust sous la main. La proposition de Steinhardt avait déclenché de longs débats autour des plateformes exotiques, comme les serveurs NonStop de HPE ou certains vieux Unix, où Rust ne tourne tout simplement pas aujourd'hui. Le projet compte sur les progrès de gccrs, le support Rust en cours d'intégration dans GCC, le compilateur historique du monde libre, pour boucher ces trous avant l'échéance.

Le reste de la version est plus classique, avec des optimisations, des corrections de bugs et de petites améliorations sur différentes sous-commandes, détaillées dans l'annonce de Junio Hamano, le mainteneur en chef du projet.

Voir Git, monument du C, basculer sur Rust par défaut, c'est le signe le plus clair que le vieux langage perd du terrain.

Source : Phoronix

L'IOCCC 2025 couronne le code C le plus illisible du monde

10 juin 2026 à 17:23

Faire tourner Tetris sur un émulateur Game Boy dont le code source tient dans moins de 5 ko de C volontairement incompréhensible, voilà le genre de prouesse que célèbre l'IOCCC, le concours international de code C obfusqué, dont le palmarès 2025 mérite vraiment le détour.

Le principe de ce concours créé en 1984 n'a pas bougé : écrire un programme en C (un des plus vieux langages de programmation encore massivement utilisés) qui fonctionne parfaitement, mais dont le code est si tordu que personne ne comprend comment. L'obfuscation, c'est exactement ça : rendre un code illisible. Ici, on le fait exprès, pour la beauté du geste.

Les règles posent quand même un cadre strict : 4993 octets de code source maximum, du C conforme au standard C11, un Makefile au format GNU (le fichier qui explique comment compiler le programme), et une consigne officielle qui interdit de transformer l'ordinateur des juges en brasier.

Après une pause entamée en 2020, cette 29e édition a battu des records de participation. Les juges ont retenu 23 programmes gagnants, dévoilés lors d'une cérémonie diffusée en direct pendant plus de quatre heures, avec au passage un premier lauréat venu de Taïwan, une grande première pour le concours.

Trois participants signent un triplé, avec trois programmes primés chacun : Yusuke Endoh, Don Yang et Nick Craig-Wood. Ce dernier, qui est aussi l'auteur de rclone (l'outil de synchronisation de fichiers bien connu des bidouilleurs), repart avec le prix du meilleur émulateur réel pour sa Game Boy logicielle réduite à l'os, un programme qui imite la console de Nintendo au point de faire tourner les fichiers des vraies cartouches, Tetris compris, sans le son ni la moindre fioriture.

Yusuke Endoh décroche de son côté le prix du programme "le plus susceptible de choquer", jeu de mots électrique assumé : son code dessine dans le terminal des figures de Lichtenberg, ces arborescences que trace une décharge électrique dans un matériau, uniquement avec des caractères de texte. Le résultat est superbe.

Le reste du palmarès part dans tous les sens. On y trouve une machine virtuelle qui émule un processeur imaginaire à une seule instruction, une carte perforée façon trou noir, un quasi-rogue-like (ces jeux d'exploration de donjons générés aléatoirement) et un quine, ce programme dont la sortie est son propre code source.

Petit détail d'histoire pour finir : obfusquer du code a longtemps servi à distribuer des logiciels propriétaires sur les systèmes UNIX sans en livrer les secrets. C'est devenu depuis un art à part entière.

Tout le palmarès est consultable sur ioccc.org , code source compris. Vous pouvez d'ailleurs récupérer les programmes et les compiler chez vous, histoire de vérifier que ces horreurs fonctionnent vraiment.

Bref, pendant que la planète entière demande à des IA de pondre du code propre, eux s'acharnent à écrire l'inverse à la main. J'adore.

Source : Hackaday

Le compilateur JIT de Python est menacé, et pas pour une raison technique

9 juin 2026 à 15:15

Le conseil de pilotage de Python, l'instance qui tranche les grandes décisions du langage, a demandé le 5 juin la suspension de tout nouveau développement sur son compilateur JIT.

Un JIT (just-in-time), c'est un compilateur à la volée : au lieu d'interpréter votre code ligne par ligne, il traduit les portions les plus sollicitées en instructions machine pendant l'exécution, histoire de gagner en vitesse. Python en a un, expérimental, depuis la version 3.13 sortie début 2024.

Le problème n'est pas le code. Il est dans la procédure.

Ce JIT est arrivé dans la branche principale de CPython, l'implémentation de référence du langage, sans passer par le circuit de décision habituel. Chez Python, toute évolution majeure doit faire l'objet d'un PEP, un document formel que la communauté discute puis valide. Celui qui couvre le JIT, le PEP 744 signé Brandt Bucher et Savannah Ostrowski, n'est qu'informatif et laisse plusieurs questions en suspens : la maintenance future, la compatibilité avec l'outillage existant, les critères de réussite mesurables.

Le conseil l'a reconnu noir sur blanc : il n'a pas été "aussi strict sur le respect du processus qu'un changement de cette ampleur le méritait". Responsabilité partagée, donc.

En pratique, plus aucune nouvelle fonctionnalité JIT ne peut atterrir sur la branche principale tant qu'un PEP en bonne et due forme n'est pas accepté. Les corrections de bugs et de sécurité, elles, continuent. Le conseil laisse une fenêtre de six mois pour soumettre et faire valider ce document. Passé ce délai, faute d'accord, le code du JIT sera purement et simplement retiré.

Le timing est mauvais. Le JIT amélioré était l'une des nouveautés mises en avant de Python 3.15, dont les fonctionnalités sont déjà gelées et dont la sortie est attendue en octobre. Sur du x86-64 sous Linux, il promet un gain de 8 à 9% en moyenne, même s'il reste désactivé par défaut et consomme 10 à 20% de mémoire en plus.

Mark Shannon, un des principaux contributeurs, n'a pas caché son agacement. Pour lui, tout arrêter d'un coup fait perdre l'élan et risque de faire fuir les nouveaux venus, alors il réclame une période de grâce pour avancer pendant que le PEP se construit. Barry Warsaw, lui, a demandé pourquoi le travail ne pourrait pas se poursuivre dans un dépôt séparé le temps des discussions.

La réponse du conseil tient en une idée : mettre le développement en pause évite que le JIT devienne une cible mouvante pendant qu'on débat de son sort.

Du coup, on se retrouve avec une techno qui fonctionne, déjà embarquée dans le langage, suspendue à un document qui n'existe pas encore.

Geler une techno qui marche pour une procédure oubliée, c'est agaçant sur le moment. Mais sur un langage utilisé par des millions de gens, c'est probablement plus prudent.

Source : The Register

Un clone de DOOM en COBOL ça vous dit ?

8 juin 2026 à 18:17

Un développeur connu sous le pseudonyme icitry s'est posé une question que personne de sensé ne formule jamais, peut-on coder un jeu de tir à la première personne en COBOL ? La réponse, contre toute attente, est oui, et le résultat est même tout à fait jouable.

Pour ceux que ce nom laisse de marbre, COBOL, pour Common Business Oriented Language, est un langage né en 1959 qui fait encore tourner aujourd'hui une partie des mainframes chargés de vos virements bancaires et de la paie. C'est l'outil de la gestion et des relevés de compte, à peu près l'inverse de ce qu'on imagine pour un jeu vidéo.

Le moteur du jeu repose sur le raycasting, cette technique qui a propulsé Wolfenstein 3D au début des années 90. Le programme projette une rangée de rayons depuis le point de vue du joueur, regarde où chacun vient percuter un mur, et en déduit colonne par colonne la hauteur à dessiner. De la fausse 3D reconstruite à partir d'un simple plan vu de dessus.

Le vrai casse-tête, c'est que COBOL n'embarque aucune bibliothèque graphique, pas la moindre fonction pour allumer un pixel ou ouvrir une fenêtre. La parade est astucieuse. Le programme calcule lui-même chaque image, en recrache les pixels bruts sur la sortie standard du terminal, puis laisse un petit utilitaire nommé ffplay récupérer ce flux pour l'afficher comme une vidéo animée.

Même esprit de débrouille pour les commandes. Le terminal bascule en mode brut afin d'intercepter chaque touche sans attendre que vous validiez, pendant que le programme lit en continu ce qui arrive sur son entrée standard.

Et le rendu ne se limite pas à trois murs gris qui clignotent. On y trouve des sprites, des ennemis qui se baladent et vous tirent dessus, et même des secteurs de hauteur variable qui rapprochent l'ensemble du DOOM de 1993 plutôt que de son aîné Wolfenstein.

Le code complet est publié sur GitHub sous licence Apache, libre à chacun d'aller en fouiller les coulisses. Un internaute a d'ailleurs relevé que GnuCOBOL, le compilateur libre utilisé ici, sait parfaitement appeler du code écrit en langage C, ce qui ouvrirait l'accès à tout son arsenal de bibliothèques.

Toute la démonstration sert à rappeler que COBOL est Turing-complet, c'est-à-dire capable en théorie de calculer exactement la même chose que n'importe quel langage moderne, et à le prouver sur le terrain le plus hostile qu'on puisse lui opposer.

Bref, c'est rigoureusement inutile, et c'est très exactement pour ça que c'est cool.

Source : Hackaday

Un simple git push suffisait : tout comprendre sur la faille critique qui a exposé des millions de dépôts sur GitHub

29 avril 2026 à 12:36

Des chercheurs en sécurité de Wiz ont découvert une vulnérabilité critique dans l'infrastructure interne de GitHub, permettant à n'importe quel utilisateur authentifié d'exécuter du code arbitraire sur les serveurs de la plateforme, le tout avec une seule commande git.

❌
❌