Entre le 6 et le 7 mai 2026, le site officiel jdownloader.org a été compromis et a servi pendant un peu plus d'une journée des installeurs piégés à la place des versions légitimes du célèbre gestionnaire de téléchargements.

Concrètement, les liens alternatifs pour Windows et l'installateur shell pour Linux ont été remplacés par un loader qui déploie un RAT (Remote Access Trojan) écrit en Python sur la machine de la victime. Pour ceux qui ne connaissent pas, un RAT donne à l'attaquant un contrôle total à distance de votre PC : exécution de commandes, vol de données, installation d'autres malwares, et tout ce qui peut se faire avec un compte utilisateur compromis.

Bonne nouvelle dans le malheur. Tous les canaux de distribution n'ont pas été touchés. La version macOS est passée à travers, pareil pour les installations via Flatpak, Winget et Snap, ainsi que pour le package JAR principal de JDownloader. Seuls les liens "alternative download" Windows et le script shell Linux du site officiel sont contaminés. Si vous utilisez ces canaux pour vous mettre à jour, c'est sur eux qu'il faut vérifier.

Le problème a d'abord été relevé par un utilisateur Reddit, "PrinceOfNightSky", qui a constaté que les exécutables téléchargés étaient signalés par Microsoft Defender et signés par des éditeurs douteux (Zipline LLC, The Water Team) au lieu de la signature légitime AppWork GmbH.

Une fois alerté, le développeur de JDownloader a confirmé la fuite, mis le site hors ligne, et publié un rapport d'incident détaillé pour permettre l'analyse externe. La porte d'entrée des attaquants ? Une vulnérabilité du CMS du site qui permettait de modifier les listes de contrôle d'accès et le contenu sans authentification. Pas génial.

Le malware Windows fonctionne en deux étages. Un petit programme téléchargé sert de loader, qui récupère et exécute ensuite le vrai payload en se connectant à deux serveurs de commande nommés parkspringshotel[.]com et auraguest[.]lk. Architecture modulaire, ce qui veut dire que l'attaquant peut envoyer le code Python qu'il veut depuis ses serveurs et adapter sa charge en temps réel. Vol de mots de passe, persistance, mouvement latéral sur le réseau local, tout y est possible.

Si vous avez téléchargé JDownloader depuis le site officiel entre le 6 et le 7 mai, faites donc très attention. Réinstallez complètement l'OS et changez tous vos mots de passe. Un RAT donne suffisamment d'accès pour qu'un nettoyage par antivirus seul ne soit pas une garantie suffisante. Pénible mais c'est le seul moyen propre.

Source : Bleeping Computer

Le YouTubeur « Flamethrower » a documenté un projet aussi inutile que satisfaisant : utiliser un hamster comme source d'énergie pour charger son smartphone.

Le principe est simple sur le papier. Vous prenez un hamster, vous le mettez dans une roue, vous reliez la roue à un générateur, et au bout d'une nuit complète d'activité rongeuse, vous obtenez assez de jus pour démarrer la charge d'un téléphone. Pas pour finir la charge, hein. Juste pour la commencer.

Le maker a utilisé un module CJMCU-2557, basé sur la puce TI BQ25770. C'est un composant fait pour récupérer de très petites quantités d'énergie : il accepte des tensions entre 0,1 et 5,1 V (avec un minimum de 0,6 V pour démarrer), un courant max de 0,1 A, et il intègre un supercondensateur pour stocker ce qui rentre.

Le Royaume-Uni a mis en place via l'Online Safety Act un système de vérification d'âge obligatoire sur les plateformes accessibles aux mineurs, avec contrôles biométriques à la clé pour estimer l'âge à partir d'un selfie.

Sur le papier, c'était la grande solution pour empêcher les ados d'accéder à TikTok, Instagram ou aux sites pour adultes. En pratique, c'est l'inverse : les enfants britanniques se passent les méthodes pour passer outre, et les méthodes en question sont parfois franchement drôles.

En fait, selon une étude d'Internet Matters, près de la moitié des enfants britanniques (46 %) considèrent les systèmes de vérification d'âge comme faciles à contourner, et un tiers reconnaissent l'avoir déjà fait.

Les méthodes documentées vont de la classique fausse date de naissance au VPN, mais aussi à des techniques plus créatives : envoyer une vidéo du visage de quelqu'un d'autre, voire d'un personnage de jeu vidéo, et le meilleur : se dessiner une moustache au feutre pour tromper l'estimation d'âge faciale. J'adore.

Côté plateformes, c'est du coup difficile à gérer. L'Online Safety Act prévoit des amendes importantes contre les services qui laisseraient passer ces contournements, mais le régulateur Ofcom rame pour qualifier la responsabilité quand le gosse a triché lui-même avec une astuce que la plateforme n'a pas su détecter.

Internet Matters relève d'ailleurs que les adultes profitent aussi de ces failles, ce qui complique encore le tableau quand un majeur peut piquer la session d'un mineur, ou inversement.

L'autre limite, c'est la captation des données biométriques. Pour vérifier qu'un gosse est bien un gosse, il faut analyser son visage, ce qui veut dire stocker (ou au moins traiter) une image biométrique d'un mineur.

Plusieurs experts ont déjà soulevé le paradoxe : pour protéger les enfants, on les oblige à transmettre leur visage à une plateforme étrangère. Et si la plateforme se fait pirater (spoiler : ça arrive régulièrement), on a une fuite de données très sensibles dans la nature.

Vous l'avez compris, une régulation qui se fait contourner par un coup de feutre sous le nez, c'est probablement le signe qu'il faut revoir la copie.

Source : Independent

Le gouvernement néerlandais a ouvert sa propre instance Forgejo à l'adresse code.overheid.nl, hébergée sur les serveurs de l'État via SSC-ICT (le service informatique mutualisé du gouvernement).

L'idée dans cette démarche, c'est de regrouper tout le code source produit par les administrations sur une plateforme libre et hébergée localement, plutôt que de continuer à dépendre de GitHub (Microsoft) ou de GitLab dont les versions entreprise sont fermées.

Forgejo, c'est un fork de Gitea, lui-même fork de Gogs, et il est complètement libre sous licence GPLv3+. Pas d'édition entreprise propriétaire, pas de fonctionnalités payantes planquées derrière des plans premium.

Du libre pur. C'est exactement ce que cherchent les administrations qui en ont marre de devoir confier leur code à une boîte américaine soumise au CLOUD Act. Les Pays-Bas ont vu la France galérer avec sa souveraineté numérique pendant des années et ont préféré agir vite plutôt que de discuter encore cinq ans.

Plusieurs ministères ont déjà migré : Finances, Affaires étrangères, Agriculture, Intérieur. Côté municipalités, La Haye, Utrecht, Leiden et Arnhem sont aussi de la partie.

Screenshot

Parmi les premiers dépôts publiés, vous avez le code du Conseil électoral néerlandais qui gère les élections, et plusieurs projets de digital workplace de l'Intérieur. Pour l'instant c'est encore en pilote pour récolter les retours développeurs, mais le déploiement s'élargit petit à petit.

Ce qui est intéressant dans la démarche, c'est la cohérence avec ce que les Pays-Bas ont déjà acté : sortie progressive de Microsoft Office au profit d'alternatives ouvertes, exigence de souveraineté sur les données de santé et refus du CLOUD Act sur certains marchés publics.

La migration Forgejo arrive dans cette logique de réduction systématique des dépendances aux géants américains, sans pour autant tomber dans le repli technologique total.

Bref, vous l'avez compris, pendant que d'autres pays publient encore des rapports sur la souveraineté numérique, les Pays-Bas ont juste appuyé sur le bouton.

Source : Itsfoss

Avec iOS 26.5, Apple corrige enfin un manque que tout le monde signalait depuis l'arrivée du RCS sur iPhone : les messages échangés entre un iPhone et un Android n'étaient pas chiffrés.

Côté iPhone-vers-iPhone, les iMessage sont protégés de bout en bout depuis des années. Mais sitôt que la conversation passait par Android, la communication redevenait en clair, comme un bon vieux SMS. Plus pour longtemps.

Apple a travaillé avec la GSMA pour finaliser la version 3.0 de l'Universal Profile RCS, qui intègre le chiffrement de bout en bout en s'appuyant sur le protocole MLS (Messaging Layer Security). MLS, c'est ce qu'Apple, Google, Facebook et d'autres ont construit ensemble pour standardiser le chiffrement des messageries de groupe à l'échelle d'Internet.

Les RCS de l'iPhone vers Google Messages (et inversement) profitent maintenant directement de cette nouveauté, avec un petit cadenas dans la conversation pour vous le signaler.

Quelques contraintes quand même. Pour que le chiffrement marche, l'iPhone devra tourner sous iOS 26.5 ou plus récent, et l'Android doit être sur la dernière version de Google Messages. Surtout, l'opérateur télécom des deux côtés doit supporter cette mouture du RCS, ce qui n'est pas garanti partout dans le monde, et certains MVNO (les opérateurs sans réseau, type Sosh ou RED en France) traînent toujours sur les anciennes versions.

Le déploiement va donc se faire petit à petit. Sur le reste, plusieurs limitations de iMessage entre plateformes persistent : pas de message rappel, pas de réponse à un fil précis, pas de réactions emoji.

iOS 26.5 est en bêta depuis fin mars, en release candidate depuis cette semaine, et la sortie publique est attendue dans les jours qui viennent sans qu'Apple ait encore donné de date officielle. Le chiffrement RCS sera activé par défaut, avec un toggle dans les réglages de Messages pour le couper si vraiment vous voulez (ce qui n'a pas un grand sens, mais bon, vous faites ce que vous voulez de votre vie privée).

Bref, Apple boucle enfin la dernière brèche du RCS multiplateforme, presque deux ans après son intégration initiale.

Source : Ghacks

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

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.

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.

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

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

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.

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.

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

Japan Airlines va confier la manutention des bagages à des robots humanoïdes sur les pistes de l'aéroport Haneda. Le test démarre en mai 2026, dure deux ans, et implique pour commencer deux machines posées au milieu des bagagistes humains.

L'opération est pilotée par JAL Ground Service avec GMO AI & Robotics. Les robots viennent de Chine : un Unitree G1 d'environ 1m30 et un Walker E d'UBTECH.

Le programme est découpé en plusieurs étapes (cartographie du site, simulations en environnement reconstitué, puis tarmac réel), avec à terme l'idée de leur faire transporter les containers de fret, manipuler les leviers de verrouillage et même nettoyer les cabines une fois les avions vides. L'autonomie annoncée est de 2 à 3 heures, avant qu'il ne faille recharger la machine.

Fin de partie pour la riposte graduée. Le Conseil d'État a déclaré illégale, le 30 avril 2026, la phase la plus dure du dispositif anti-piratage Arcom, héritier de la Hadopi.

La décision s'applique immédiatement et décapite le système après 17 ans de chasse aux téléchargeurs sur les réseaux peer-to-peer. La Quadrature du Net, qui pilote le contentieux depuis 2019, a publié dans la foulée un bilan intitulé "Hadopi (2009-2026)".

Concrètement, deux failles ont été retenues. La juridiction a constaté que le décret de 2010 n'oblige nulle part les opérateurs à stocker les adresses IP dans "un compartiment totalement isolé", comme l'avait pourtant exigé la Cour de justice de l'Union européenne en avril 2024.

Et surtout, la troisième étape de la riposte graduée, celle qui transmet votre dossier au procureur après deux avertissements ignorés, ne prévoyait aucune autorisation judiciaire préalable. Du coup, les sanctions pénales, jusqu'à 1 500 euros d'amende et 3 000 euros en cas de récidive, ne peuvent plus être déclenchées.

Les deux premiers étages tiennent quand même encore debout. Si vous récupérez un torrent illégal demain, l'Arcom peut toujours vous envoyer un email d'avertissement, puis une lettre recommandée. Mais l'arme dissuasive, le passage devant le juge, exige désormais qu'un magistrat valide d'abord l'identification de l'abonné, et que les données aient été stockées dans le respect du droit européen.

Côté Arcom, l'institution prépare déjà une bascule sur le blocage de sites pirates et le déréférencement, c'est-à-dire la pression sur les intermédiaires plutôt que sur vous, particuliers.

Pour rappel, Hadopi a été lancée en 2009 sous le gouvernement Sarkozy, puis fusionnée avec le CSA en 2021 pour devenir l'Arcom. Le bilan ? Environ 13 millions d'avertissements envoyés et seulement 500 jugements rendus en 17 ans.

Soit un taux de conversion qui ferait glousser n'importe quel directeur commercial. La Quadrature, qui a mené le contentieux avec FDN et Franciliens.net, parle aujourd'hui d'une "victoire" pour les droits fondamentaux et appelle à ne pas ressusciter le dispositif sous une autre forme.

La Quadrature rappelle que le dispositif a surtout servi à criminaliser le partage culturel non-marchand entre internautes, sans jamais améliorer la rémunération des artistes ni endiguer le piratage à grande échelle.

Le streaming illégal, les plateformes IPTV, les sites de direct download : tout ça a continué à prospérer pendant que l'Autorité s'acharnait sur les utilisateurs de torrents. À côté, l'industrie culturelle a fini par s'adapter avec Spotify, Deezer ou Netflix, sans qu'on ait eu besoin de surveiller les abonnés de manière excessive.

Bref, on aura mis 17 ans à constater que ficher massivement les internautes sans contrôle judiciaire, c'est illégal, mais on s'en est toujours douté.

Source : La Quadrature du Net

45 ans après sa sortie, le code source du tout premier 86-DOS vient d'atterrir sur GitHub . Microsoft a profité de cet anniversaire pour publier les listings d'assembleur originaux, accompagnés de plusieurs versions de PC-DOS 1.00 et de MS-DOS 1.25, sous licence MIT. Tout ceci est dans le dépôt DOS-History/Paterson-Listings, et oui, le tout est compilable.

Ces listings, c'est Tim Paterson en personne qui les avait conservés dans ses tiroirs depuis 1980. À cette époque, il bossait chez Seattle Computer Products, une boîte de matos qui faisait des cartes pour processeurs Intel 8086.

Il avait écrit en quelques mois un OS rudimentaire baptisé 86-DOS pour faire tourner les machines de SCP. Microsoft a fini par racheter le code à SCP pour 75 000 dollars, l'a légèrement retravaillé, et l'a refilé à IBM sous le nom PC-DOS pour équiper le tout premier IBM PC. Ce code-là est le grand-père de Windows.

On parle ici de dix paquets de listings papier (le bon vieux papier à bandes vertes), dont huit ont déjà été transcrits par Yufeng Gao et Rich Cini, deux passionnés de préservation. À l'intérieur : le noyau de 86-DOS 1.00, plusieurs snapshots de développement de PC-DOS 1.00, et des utilitaires comme CHKDSK.

Plus intéressant encore, les listings contiennent les annotations manuscrites de Paterson lui-même, des notes en marge qui montrent les hésitations et les corrections d'un ingénieur en plein travail.

Le code est prêt à être compilé avec l'assembleur SCP d'origine, ce qui veut dire qu'on peut générer des binaires fonctionnels et les faire tourner dans un émulateur comme par exemple PCem ou 86Box. C'est rare en archéologie logicielle d'avoir des snapshots aussi complets, et c'est encore plus rare quand l'auteur original est toujours là pour répondre aux questions. Les originaux papier vont d'ailleurs rejoindre l'Interim Computer Museum, donnés par Paterson lui-même.

Ce n'est pas la première fois que Microsoft ouvre du code un peu ancien. En 2018, ils avaient déjà open-sourcé MS-DOS 1.25 et 2.11. En 2024, c'était MS-DOS 4.0. Mais cette fois on remonte carrément à la racine, à la version SCP avant rachat, avec les fragments de l'évolution vers PC-DOS. Du coup, pour les nostalgiques et les chercheurs en histoire de l'informatique, c'était la pièce manquante.

Petite cerise sur le gâteau : les scans bruts des listings papier sont aussi sur Archive.org, donc même la version "préhistorique" est consultable. Et si vous avez envie de contribuer à la transcription des deux paquets restants, ce projet est ouvert.

Bref, le grand-père de Windows est désormais lisible ligne par ligne, annotations comprises. Pour les fans d'archéologie informatique, c'est carrément chouette.

Source : Hackaday

Si vous avez plusieurs Raspberry Pi qui traînent chez vous, vous connaissez la galère du DHCP. Le routeur leur balance des IP différentes au gré des redémarrages, et impossible de savoir laquelle correspond à votre Pi-hole, votre Home Assistant ou votre média center sans aller fouiller dans l'interface admin du box.

Un développeur du nom de Philipp a sorti une appli Android qui résout ça en repérant automatiquement tous les Pi présents sur le LAN.

L'outil utilise deux méthodes de détection complémentaires. D'abord le MAC OUI, c'est-à-dire les premiers octets de l'adresse MAC qui identifient le constructeur du matériel. Tous les Raspberry Pi partagent une plage d'OUI réservée à la fondation, donc on peut les filtrer même au milieu d'une trentaine d'appareils connectés sur un même réseau.

Ensuite le mDNS, le protocole de découverte multicast qui permet à un Pi de répondre à raspberrypi.local même sans configuration serveur particulière.

L'appli n'est pas qu'un scanner. Elle embarque aussi les pinouts GPIO pour tous les modèles, du Pi 1 au Pi 5 en passant par le Zero et le Pico. Et quelques calculatrices électroniques pour les résistances, la loi d'Ohm et les diviseurs de tension. Du coup ça remplace les marque-pages que vous gardiez sur pinout.xyz et autres sites de référence quand vous bidouillez sur breadboard.

Le code est open source, dispo sur GitHub. Pas de pub. Suffisamment rare pour s'en réjouir, quand on voit les dizaines de scanners réseau sur le Play Store qui vous balancent une bannière toutes les trois secondes ou exigent une autorisation d'accès à votre carnet de contacts pour scanner un sous-réseau privé.

Philipp a clairement développé ça pour son usage personnel avant de le mettre à disposition, et ça se sent dans l'absence de fioritures.

À noter qu'il faut être sur le même sous-réseau Wi-Fi que les Pi pour que le scan fonctionne. Si vous avez segmenté votre réseau IoT, ce qui reste une bonne pratique côté sécurité, il faudra autoriser le multicast entre les VLAN ou faire le scan depuis un appareil branché côté domotique. Sinon le mDNS ne traverse pas et vous ne verrez que les Pi du segment courant.

L'intérêt va au-delà du simple gain de temps. Sur un parc Pi un peu costaud, savoir d'un coup d'oeil lesquels sont actifs permet de repérer rapidement un noeud qui a redémarré sans crier gare ou un conteneur tombé. Et pour ceux qui font du déploiement en série, c'est plus rapide que de scripter un nmap sur tout le /24.

Dans tous les cas c'est cool, un petit utilitaire qui résout un vrai problème quotidien et qui mérite sa place dans la boîte à outils de tout bidouilleur Pi. C'est par ici si ça vous branche .

Source : Hackaday