RNDS-Stream , c'est une appli homebrew incroyable pour la Nintendo DSi (sortie en 2008 quand même... ça date de fou !) qui affiche en live n'importe quel jeu depuis votre PC Linux. Le PC capture la fenêtre du jeu et l'envoie en MJPEG sur le réseau local, puis la console décode ce flux vidéo, et le clavier et la souris du PC sont pilotés à distance via ydotool .

Si ça vous intéresse, la vidéo ci-dessous montre le projet en action (vers les 4 min 48) avec côté console, le décodage du MJPEG passant par RubyNDS , qui est le framework Ruby que l'auteur s'est monté pour programmer la DSi. Et avec les bons réglages de GStreamer, ça peut grimper à 20 images par seconde avec saut d'images, ou plus modestement de 10 à 15 images par seconde en résolution max sur la DSi. Le serveur de son côté, repère tout seul votre bibliothèque Steam et vos instances Prism Launcher pour vous permettre de lancer les jeux de votre choix.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Pour l'essayer, faut déjà que vous soyez bien chaud bouillant ^^. Ensuite, il faut un flashcart qui permet de lancer l'outil en copiant son .nds sur une microSD, avec à la racine un fichier rnds-stream.txt qui contient uniquement l'adresse IP locale de votre PC. Bref, rien à copier sur la SD interne de la DSi.

Côté PC, c'est du Linux sous X11 ou Wayland, puisque les fenêtres en Wayland pur ne sont pas détectées, avec wmctrl et GStreamer installés à côté du Flatpak du serveur, qui n'est pas entièrement autonome. Sachez que l'auteur n'a testé que Fedora KDE, donc à voir comment ça se passe sur les autres distrib.

Reste le Wi-Fi car d'après le wiki DS Homebrew , une appli DS classique ne gère que le WEP ou les réseaux ouverts, le WPA et le WPA2 n'étant possibles qu'en mode DSi.

Voilà, on est dans l'hyper expérimental, y'a des bugs, aucune sécurité (donc restez bien en local) mais c'est assez insolite pour que je vous en parle.

A découvrir ici !

Source : Hackaday

OpenAI agents carried out an undisclosed attack on RubyGems is a new bombshell report from Spencer Kitts, Thomas Larsen, and Sydney Von Arx - three of the four authors of the report on the agent attack on disused wikis (previously) last week.

This time they're noting that it looks very likely that an OpenAI agent swarm was behind an attack against the RubyGems package repository first reported on May 12th by Maciej Mensfeld of the RubyGems security team:

We're dealing with a major malicious attack on @rubygems right now. Signups are paused for the time being.

Hundreds of packages involved - mostly targeting us, but some carrying exploits. The team has been on this for hours. More details to follow once we're through it.

Those packages turned out to carry some very suspicious patterns:

1. Many of them included "oai" in their name, or the author field, or the fake email address they provided.
2. The files they were accessing were similar in character to the files retrieved by the wiki agents, using similar tricks (r.jina.ai) - and OpenAI have confirmed the wiki agents were theirs.
3. The code in the packages appeared to be LLM-authored.

I find point 2 the most convincing, given what we learned from the wiki attack when it was analyzed in September.

Many of the packages were exploiting the RubyDoc.info documentation build process to exfiltrate (public) data from UK government websites, presumably as part of an information gathering task similar to the research tasks processed by the wiki-exploiting agents. We know this because one agent helpfully left a comment:

# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker

They also attempted to steal API keys via an exploit that was patched over two months later - it's not clear if those attempts were successful.

The thing that bothers me most about this incident is that the authors report that OpenAI had not disclosed to RubyGems that they were responsible for the attack prior to now. If that's true there are two options:

1. After the Hugging Face and Wiki attacks OpenAI were still unable to review their previous logs and determine that they had previously attacked RubyGems.
2. They knew about the attack on RubyGems and made the decision not to reach out to the RubyGems team about it.

Both of these are bad!

Given this incident, the Hugging Face situation, and the Wiki attack, the obvious question right now is how many more incidents like this are out there waiting to be discovered?

Update 14th September 2026

OpenAI have updated their page about The Hugging Face incident and other third-party impact from misaligned models to mention the RubyGems incident:

September 11, 2026: We are investigating new claims from a report that our AI agents carried out activity on RubyGems in May 2026.

Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. Based on our review to date, we have not been able to verify the specific claims of our models uploading malicious packages detailed in the report. We’ll continue to investigate and share findings as part of our broader review of agent activity during training and evaluation.

I find it very unlikely that the various oai... packages published to RubyGems were not part of this same incident, but I look forward to reading their full findings once those are published.

Tags: ruby, security, ai, openai, generative-ai, llms, supply-chain, ai-ethics, accidental-cyberattacks