Reachy Mini is a kit for a compact, open-source robot designed explicitly for AI experimentation and human interaction. The kit is available from Hugging Face, which is itself a repository and hosting service for machine learning models. Reachy seems to be one of their efforts at branching out from pure software.
Our guess is that some form of Stewart Platform handles the head movement.
Reachy Mini is intended as a development platform, allowing people to make and share models for different behaviors, hence the Hugging Face integration to make that easier. On the inside of the full version is a Raspberry Pi, and we suspect some form of Stewart Platform is responsible for the movement of the head. There’s also a cheaper (299 USD) “lite” version intended for tethered use, and a planned simulator to allow development and testing without access to a physical Reachy at all.

Reachy has a distinctive head and face, so if you’re thinking it looks familiar that’s probably because we first covered Reachy the humanoid robot as a project from Pollen Robotics (Hugging Face acquired Pollen Robotics in April 2025.)

The idea behind the smaller Reachy Mini seems to be to provide a platform to experiment with expressive human communication via cameras and audio, rather than to be the kind of robot that moves around and manipulates objects.

It’s still early in the project, so if you want to know more you can find a bit more information about Reachy Mini at Pollen’s site and you can see Reachy Mini move in a short video, embedded just below.

youtube.com/embed/JvdBJZ-qR18?…

hackaday.com/2025/07/25/reachy…

When you think of a tape recorder, you might think of a cassette tape. However, [Michael Simpson] has an old Star-Lite small reel-to-reel tape machine. It isn’t a repair so much as a rework to make it work better. These cheap machines were never the best, although a $19 tape player back then was a luxury.

Part of the problem is that the design of the tape player wasn’t all that good to begin with. The motor runs off two C cells in parallel. When these were new in the 1960s, that would have meant conventional carbon-zinc batteries, so the voltage would have varied wildly. Didn’t matter, though, because the drive was directly to the tape reel, so the speed also varied based on how much tape was left on the reel.

The amplifier has four transistors. [Michael] decided to replace the capacitors on the unit. He noticed, too, that the volume control is in line with the microphone when recording, so even though the recording was supposedly in need of repair, it turned out to be simply a case of the volume control being turned down. Pretty impressive for a six-decade-old piece of consumer electronics.

The capacitor change-out was simple enough. Some cleaning and lubing was also in order. Did it help? You’ll have to listen and decide for yourself.

So, no real repair was in the works, but it is an interesting look back at an iconic piece of consumer tech. Tape recorders like this were an early form of social media. No kidding. If you’d rather not buy a tape recorder, you could roll your own.

youtube.com/embed/xhlOx0g2Abg?…

hackaday.com/2025/07/24/not-re…

The switch from analog telephone exchanges to a purely digital network meant a revolution in just about any way imaginable. Gone were the bulky physical switches and associated system limitations. In the UK this change happened in the early 1980s, with what the Post Office Telecommunications (later British Telecom) and associated companies called System X. Along with the system’s rollout, promotional videos like this 1983 one were meant to educate the public and likely any investors on what a smashing idea the whole system was.

Although for the average person in the UK the introduction of the new digital telephone network probably didn’t mean a major change beyond a few new features like group calls, the same wasn’t true for the network operator whose exchanges and networks got much smaller and more efficient, as explained in the video. To this day System X remains the backbone of the telephone network in the UK.

To get an idea of the immense scale of the old analog system, this 1982 video (also embedded below) shows the system as it existed before System X began to replace it. The latter part of the video provides significant detail of System X and its implementation at the time, although when this video was produced much of the system was still being developed.

Thanks to [James Bowman] for the tip.

youtube.com/embed/xy_6DL4haJA?…

youtube.com/embed/Ni5NMlMOxG4?…

hackaday.com/2025/07/24/when-t…

Remember the 80286? It was the sequel to the 8086, the chip that started it all, and it powered a great number of machines in the early years of the personal computing revolution. It might not be as relevant today, but regardless, [Daniel Balsom] has now released a comprehensive test suite for the ancient chip. (via The Register)

The complete battery of tests are available on Github, and were produced using a Harris N80C286-12 from 1986. “The real mode test suite contains 326 instruction forms, containing nearly 1.5 million instruction executions with over 32 million cycle states captured,” Daniel explains. “This is fewer tests than the previous 8088 test suite, but test coverage is better overall due to improved instruction generation methods.” For now, the tests focus on the 286 running in real mode. There are no “unreal” or protected mode tests, but [Daniel] aims to deliver the in the future.

[Daniel] uses the tests with the ArduinoX86, a platform that uses the microcontroller to control and test old-school CPUs. The tests aid with development of emulators like [Daniel’s] own MartyPC, by verifying the CPU’s behavior in a cycle-accurate way.

We’ve explored some secrets of the 286 before, too. If you’ve been doing your own digging into Intel’s old processors, or anyone else’s for that matter, don’t hesitate to notify the tipsline.

[Thanks to Stephen Walters for the tip!]

hackaday.com/2025/07/24/compre…

L’azienda di sicurezza cloud Wiz ha identificato una vulnerabilità critica in NVIDIA Container Toolkit, identificata come CVE-2025-23266 e con un punteggio CVSS di 9.0. La vulnerabilità, denominata NVIDIAScape, potrebbe rappresentare una seria minaccia per i servizi cloud che utilizzano l’intelligenza artificiale e la containerizzazione basata su GPU.

Il bug riguarda tutte le versioni di NVIDIA Container Toolkit fino alla 1.17.7 inclusa, nonché NVIDIA GPU Operator fino alla versione 25.3.0. La vulnerabilità è già stata risolta rispettivamente nelle nuove versioni 1.17.8 e 25.3.1.

Il problema è legato all’utilizzo dei cosiddetti hook OCI, progettati per inizializzare i container. Uno di questi hook, “createContainer“, viene utilizzato con una configurazione errata, che consente a un aggressore di caricare una libreria dannosa all’avvio del container.

Il problema è che gli hook vengono eseguiti con privilegi elevati e nel contesto del file system del contenitore, consentendo all’attaccante di iniettare codice con il minimo sforzo. I ricercatori di Wiz hanno sottolineato che l’attacco può essere eseguito con sole tre righe nel Dockerfile, che impostano la variabile LD_PRELOAD e caricano la libreria dannosa. Di conseguenza, l’attaccante può non solo uscire dal contenitore, ma anche prendere il controllo del sistema host.

Ciò che è particolarmente allarmante è che la vulnerabilità interessa circa il 37% degli ambienti cloud che utilizzano l’intelligenza artificiale. Ciò significa che un singolo contenitore compromesso può essere utilizzato per accedere a dati e modelli di altri client ospitati sugli stessi server fisici. L’attacco potrebbe quindi portare a furti di proprietà intellettuale, interruzioni del flusso di lavoro e diniego di servizio.

Wiz aveva già segnalato due problemi simili nel toolkit di NVIDIA, CVE-2024-0132 e CVE-2025-23359 , entrambi con possibilità di acquisizione completa del sistema. La nuova vulnerabilità ha dimostrato ancora una volta quanto sia debole il meccanismo di isolamento nei container. Secondo il team, l’utilizzo esclusivo dei container come misura di sicurezza è inaccettabile: sono necessarie barriere aggiuntive come la virtualizzazione, soprattutto nelle infrastrutture multi-tenant.

La situazione di NVIDIAScape solleva interrogativi urgenti sulla resilienza delle infrastrutture moderne agli attacchi, dove vettori di hacking noti e legacy potrebbero essere più efficaci di ipotetiche minacce basate sull’intelligenza artificiale. Le problematiche a livello di componenti di base, come i container hook, dimostrano che l’attenzione ai dettagli e gli aggiornamenti regolari rimangono elementi chiave della difesa.

L'articolo L’isolamento dei container è a rischio. Solo 3 righe di codice per violare gli ambienti AI di NVIDIA proviene da il blog della sicurezza informatica.

😍😍😍

youtu.be/18QQWa5MEcs?si=tFj9-s…

#marvel #Fantastic4