Meet the little board that could: [alcor6502]’s tiny USB relay controller, now evolved into a multifunction marvel. Originally built as a simple USB relay to probe the boundaries of JLCPCB’s production chops, it has become a compact utility belt for any hacker’s desk drawer. Not only has [alcor6502] actually built the thing, he even provided intstructions. If you happened to be at Hackaday in Berlin, you now might even own one, as he handed out twenty of them during his visit. If not, read on and build it yourself.

This thing is not just a relay, and that is what makes it special. Depending on a few solder bridges and minimal components, it shape-shifts into six different tools: a fan controller (both 3- and 4-pin!), servo driver, UART interface, and of course, the classic relay. It even swaps out a crystal oscillator for USB self-sync using STM32F042‘s internal RC – no quartz, less cost, same precision. A dual-purpose BOOT0 button lets you flash firmware and toggle outputs, depending on timing. Clever reuse, just like our mothers taught us.

It’s the kind of design that makes you want to tinker again. Fewer parts. More function. And that little smile when it just works. If this kind of clever compactness excites you too, read [alcor6502]’s build log and instructions here.

hackaday.com/2025/04/05/how-a-…

3D scanning is becoming much more accessible, which means it’s more likely that the average hacker will use it to solve problems — possibly odd ones. That being the case, a handy tool to have in one’s repertoire is a way to work with point clouds. We’ll explain why in a moment, but that’s where CloudCompare comes in (GitHub).
Not all point clouds are destined to be 3D models. A project may call for watching for changes in a surface, for example.
CloudCompare is an open source tool with which one can load up and do various operations on point clouds, including generating mesh models from them. Point clouds are what 3D scanners create when an object is scanned, and to become useful, those point clouds are usually post-processed into 3D models (specifically, meshes) like an .obj or .stl file.

We’ve gone into detail in the past about how 3D scanning works, what to expect from it, and taken a hands-on tour of what an all-in-one wireless scanner can do. But what do point clouds have to do with getting the most out of 3D scanning? Well, if one starts to push the boundaries of how and to what purposes 3D scanning can be applied, it sometimes makes more sense to work with point clouds directly instead of the generated meshes, and CloudCompare is an open-source tool for doing exactly that.

For example, one may wish to align and merge two or more different clouds, such as from two different (possibly incomplete) scans. Or, you might want to conduct a deviation analysis of how those different scans have changed. Alternately, if one is into designing wearable items, it can be invaluable to be able to align something to a 3D scan of a body part.

It’s a versatile tool with numerous tutorials, so if you find yourself into 3D scanning but yearning for more flexibility than you can get by working with the mesh models — or want an alternative to modeling-focused software like Blender — maybe it’s time to work with the point clouds directly.

hackaday.com/2025/04/05/if-you…

Usually when we talk about retrocomputing, we want to look at — and in — some old hardware. But [Z→Z] has a different approach: dissecting MacPaint, the Apple drawing program from the 1980s.

While the program looks antiquated by today’s standards, it was pretty hot stuff back in the day. Things we take for granted today were big deals at the time. For example, being able to erase a part of something you drew prompted applause at an early public demo.

We enjoyed the way the program was tested, too. A software “monkey” was made to type keys, move things, and click menus randomly. The teardown continues with a look inside the Pascal and assembly code with interesting algorithms like how the code would fill an area with color.

The program has been called “beautifully organized,” and [Z→Z] examines that assertion. Maybe the brilliance of it has been overstated, but it did work and it did influence many computer graphics programs over the years.

We love digging through old source code. Even old games. If you do your own teardowns, be sure to send us a tip.

hackaday.com/2025/04/05/a-look…

Gli organizzatori hanno affermato di aver ricevuto quasi 250.000 adesioni alle manifestazioni contro le politiche trumpiane sulla gestione dei sussidi della previdenza sociale, i licenziamenti dei dipendenti federali, gli attacchi alle tutele dei consumatori e alle politiche anti-immigrazione e gli attacchi alle persone transgender. Le proteste sono anche contro il coinvolgimento di Elon Musk nel governo federale.

agi.it/estero/news/2025-04-05/…

Quasi due dozzine di aziende che lavorano nel campo dell’informatica quantistica, sono stati selezionati per partecipare alla prima fase dell’ambiziosa Quantum Benchmarking Initiative (QBI) della DARPA. La sfida per i partecipanti è dimostrare la fattibilità dei loro approcci unici per creare un computer quantistico utile e a prova di errore entro i prossimi dieci anni.

Il programma QBI è stato lanciato nel luglio 2024 e mira a ribaltare le previsioni scettiche e ad accelerare lo sviluppo di un computer quantistico realmente pratico. L’obiettivo principale della DARPA è determinare se entro il 2033 sia possibile raggiungere una svolta tale per cui una macchina quantistica possa non solo funzionare, ma anche offrire vantaggi reali che superino i costi di costruzione e di funzionamento.

Secondo Joe Altepeter, responsabile del programma QBI, le aziende sono state selezionate in base all’esame delle loro candidature scritte e delle presentazioni di persona a un team di esperti quantistici statunitensi. “Ora inizia il vero lavoro. La fase A è una maratona di sei mesi durante la quale i partecipanti devono presentare concetti tecnicamente validi che dimostrino che sono effettivamente in grado di portare alla creazione di un computer quantistico scalabile e tollerante ai guasti“, ha osservato.

La selezione comprende attori noti come IBM, HPE e Rigetti, oltre a startup provenienti da Stati Uniti, Canada, Europa e Australia che sviluppano tecnologie basate su un’ampia gamma di tipologie di qubit, dai superconduttori e trappole ioniche ai sistemi fotonici e qubit di spin su silicio. L’elenco include, ad esempio, Alice & Bob da Parigi e Cambridge (qubit cat), IonQ dal Maryland (trappole ioniche), Diraq dall’Australia e dalla California (spin in silicio CMOS) e Xanadu da Toronto (circuiti quantistici fotonici). Sono state nominate in totale 15 aziende; altri tre sono in fase di accordo sulle condizioni di partecipazione.

Coloro che supereranno con successo questa prima fase passeranno a una seconda fase, della durata di un anno, durante la quale la DARPA valuterà attentamente i propri piani scientifici e tecnici, gli approcci di ricerca e la fattibilità degli obiettivi dichiarati. Successivamente inizierà la fase finale C, in cui il team di verifica e convalida indipendente (IV&V) testerà tutto, dagli algoritmi e componenti ai prototipi funzionanti. Allo stesso tempo, come sottolinea la DARPA, il programma non è di natura competitiva: il compito non è quello di scegliere un vincitore, ma di valutare il più accuratamente possibile il potenziale di ciascun approccio al calcolo quantistico.

È interessante notare che QBI è diventato la logica continuazione del progetto pilota US2QC (Underxplored Systems for Utility-Scale Quantum Computing), a cui stanno già lavorando Microsoft e PsiQuantum. Entrambe le aziende sono ora entrate nella fase finale di questo programma, i cui obiettivi sono completamente allineati con la fase finale di QBI.

La DARPA punta sulla tecnologia profonda e non su affermazioni ad alta voce. Come afferma Altepiter, l’agenzia sta creando un team di esperti IV&V composto da specialisti di primo piano e sta utilizzando siti di prova sia federali che regionali per distinguere le tecnologie reali dalle esagerazioni. Tutti questi sforzi mirano a un solo obiettivo: aiutare il governo degli Stati Uniti a comprendere quali sviluppi commerciali ci stanno davvero avvicinando all’era di un computer quantistico pratico e robusto.

L'articolo Basta Chiacchiere! Il DARPA vuole vederci chiaro sui Computer Quantistici. Entro il 2033 il primo? proviene da il blog della sicurezza informatica.

[Antoine Pirrone] and [Grégoire Passault] are making a DIY miniature re-imagining of Disney’s BDX droid design, and while it’s still early, there is definitely a lot of progress to see. Known as the Open Duck Mini v2 and coming in at a little over 40 cm tall, the project is expected to have a total cost of around 400 USD.
The inner workings of Open Duck Mini use a Raspberry Pi Zero 2W, hobby servos, and an absolute-orientation IMU.
Bipedal robots are uncommon, and back in the day they were downright rare. One reason is that the state of controlled falling that makes up a walking gait isn’t exactly a plug-and-play feature.

Walking robots are much more common now, but gait control for legged robots is still a big design hurdle. This goes double for bipeds. That brings us to one of the interesting things about the Open Duck Mini v2: computer simulation of the design is playing a big role in bringing the project into reality.

It’s a work in progress but the repository collects all the design details and resources you could want, including CAD files, code, current bill of materials, and links to a Discord community. Hardware-wise, the main work is being done with very accessible parts: Raspberry Pi Zero 2W, fairly ordinary hobby servos, and an BNO055-based absolute orientation IMU.

So, how far along is the project? Open Duck Mini v2 is already waddling nicely and can remain impressively stable when shoved! (A “testing purposes” shove, anyway. Not a “kid being kinda mean to your robot” shove.)

Check out the videos to see it in action, and if you end up making your own, we want to hear about it, so remember to send us a tip!

hackaday.com/2025/04/05/disney…

We’ve seen a Linux-based operating system made to run on some widely varying pieces of hardware over the years, but [Dimity Grinberg]’s latest project may be one of the most unusual. It’s a PCB with 3 integrated circuits on it which doesn’t seem too interesting at first, but what makes it special is that all three of those chips are in 8-pin SOIC packages. How on earth can Linux run on 8-pin devices? The answer lies as you might expect, in emulation.

Two of the chips are easy to spot, a USB-to-serial chip and an SPI RAM chip. The processor is an STM32G0 series device, which packs a pretty fast ARM Cortex M0+ core. This runs a MIPS emulator that we’ve seen on a previous project, which is ripe for overclocking. At a 148 MHz clock it’s equivalent to a MIPS running at about 1.4 MHz, which is just about usable. Given that the OS in question is a full-featured Debian, it’s not running some special take on Linux for speed, either.

We like some of the hardware hacks needed to get serial, memory, and SD card, onto so few pins. The SD and serial share the same pins, with a filter in place to remove the high-frequency SPI traffic from the low-frequency serial traffic. We’re not entirely sure what use this machine could be put to, but it remains an impressive piece of work.

hackaday.com/2025/04/05/8-pins…

E’ stata pubblicata da Ivanti una vulnerabilità critica, che interessa i suoi prodotti Connect Secure, Pulse Connect Secure, Ivanti Policy Secure e ZTA Gateway monitorata con il codice CVE-2025-22457.

Questo bug di sicurezza è un buffer overflow al quale è stato assegnato un punteggio pari a 9,0 in scala CVSS, ed sfruttato attivamente da metà marzo 2025. Tale bug crea significativi rischi per le organizzazioni che utilizzano queste soluzioni VPN e di accesso alla rete.

Dopo la divulgazione di IVANTI del 3 aprile 2025, Mandiant segnala lo sfruttamento da parte di UNC5221, un presunto gruppo sponsorizzato dallo stato cinese, da metà marzo. UNC5221, noto per aver preso di mira dispositivi edge, ha già sfruttato in precedenza zero-day di Ivanti come CVE-2023-46805.

La vulnerabilità è stata risolta nella versione 22.7R2.6 di Ivanti Connect Secure l’11 febbraio 2025, ed era inizialmente considerata un problema di negazione del servizio a basso rischio a causa del suo set di caratteri limitato (punti e numeri). Anche lo CSIRT dell’Agenzia per la Cybersicurezza Nazionale (ACN) ha emesso un avviso riportando la gravità del bug di sicurezza.

Il difetto deriva da una convalida errata degli input, che consente agli aggressori di eseguire codice arbitrario. I prodotti di IVANTI affetti da questo bug sono i seguenti:

• Ivanti Connect Secure : versioni 22.7R2.5 e precedenti.
• Pulse Connect Secure : versioni 9.1R18.9 e precedenti (fine del supporto a partire dal 31 dicembre 2024).
• Ivanti Policy Secure : versioni 22.7R1.3 e precedenti.
• Gateway ZTA : versioni 22.8R2 e precedenti.

Gli aggressori usano CVE-2025-22457 per distribuire malware come Trailblaze (un dropper in memoria), Brushfire (una backdoor passiva) e la suite Spawn per il furto di credenziali e il movimento laterale. Dopo lo sfruttamento, manomettono i log usando strumenti come SPAWNSLOTH per eludere il rilevamento.

Tuttavia, è probabile che UNC5221 abbia eseguito il reverse engineering della patch, sviluppando un exploit RCE per sistemi non patchati, aumentandone così la gravità.

Ivanti consiglia di monitorare l’Integrity Checker Tool (ICT) per rilevare eventuali segnali di compromissione, come crash del server web. Se rilevati, si consiglia un ripristino delle impostazioni di fabbrica e un aggiornamento alla versione 22.7R2.6. Il blog di Mandiant fornisce ulteriori indicatori di compromissione. Un post su X di

Questo incidente segna la quindicesima apparizione di Ivanti nel catalogo KEV delle vulnerabilità note sfruttate di CISA dal 2024, segnalando sfide sistemiche alla sicurezza dei suoi dispositivi edge.

Il coinvolgimento di UNC5221 sottolinea la posta in gioco geopolitica, poiché gli attori legati alla Cina prendono sempre più di mira le infrastrutture per lo spionaggio. La divulgazione ritardata nonostante la patch di febbraio rivela lacune nella gestione delle vulnerabilità.

L'articolo Emergenza Ivanti: scoperta vulnerabilità critica sfruttata da APT collegati con la Cina proviene da il blog della sicurezza informatica.

Di vulnerabilità con CVSS di gravità 10 se ne vedono pochissime (per fortuna), ma questa volta siamo di fronte ad una gravissima falla di sicurezza che minaccia Apache Parquet.

Si tratta di una vulnerabilità a massima gravità (CVSS v4 10.0) in Apache Parquet classificata come CVE-2025-30065, la quale minaccia seriamente la sicurezza degli ambienti big data, consentendo l’esecuzione di codice da remoto (RCE) su sistemi vulnerabili.

Apache Parquet è un formato di archiviazione dati orientato alle colonne gratuito e open source nell’ecosistema Apache Hadoop. È simile a RCFile e ORC, gli altri formati di file di archiviazione a colonne in Hadoop , ed è compatibile con la maggior parte dei framework di elaborazione dati attorno a Hadoop. Fornisce schemi di compressione e codifica dati efficienti con prestazioni migliorate per gestire dati complessi in blocco.

Cos’è successo

Il problema riguarda tutte le versioni di Apache Parquet fino alla 1.15.0 inclusa. Un malintenzionato può creare un file Parquet appositamente manipolato e, se questo viene importato in un sistema vulnerabile, ottiene la possibilità di:

• Prendere il controllo del sistema target
• Esfiltrare o modificare dati sensibili
• Interrompere servizi
• Distribuire payload malevoli come ransomware

La vulnerabilità è stata scoperta da Keyi Li, ricercatore di Amazon, e divulgata responsabilmente il 1° aprile 2025. Il problema è stato risolto con il rilascio della versione Apache Parquet 1.15.1, che tutti gli utenti sono fortemente invitati ad installare immediatamente.

Perché è una minaccia seria

Parquet è uno standard de facto nel mondo della data engineering e analytics. È utilizzato da colossi come Netflix, Uber, Airbnb e LinkedIn, oltre che in ambienti Hadoop, AWS, Google Cloud, Azure, data lakes, pipeline ETL e sistemi di intelligenza artificiale.

Il formato columnar consente una gestione efficiente di grandi volumi di dati, ma proprio per la sua diffusione, una vulnerabilità in Parquet rappresenta una superficie d’attacco critica per l’intera filiera del dato.

“Schema parsing in the parquet-avro module of Apache Parquet 1.15.0 and previous versions allows bad actors to execute arbitrary code”, si legge nel bollettino di sicurezza pubblicato su Openwall.

Condizioni di sfruttamento

Fortunatamente, l’exploit richiede un’interazione utente: l’importazione di un file Parquet malevolo. Tuttavia, in ambienti dove i file vengono ricevuti da terze parti o fonti esterne (ad esempio in pipeline automatizzate), il rischio diventa molto più concreto.

Secondo Endor Labs, la vulnerabilità potrebbe risalire alla versione 1.8.0 di Parquet, rendendo necessaria una verifica approfondita degli stack in produzione per valutare l’esposizione.

Cosa fare subito

1. Aggiornare Apache Parquet alla versione 1.15.1 il prima possibile.
2. Bloccare l’importazione di file Parquet da fonti non attendibili fino a che l’ambiente non è stato messo in sicurezza.
3. Applicare controlli di validazione sui file Parquet prima del processamento.
4. Monitorare e loggare tutte le attività sui sistemi che trattano file Parquet.
5. Verificare con fornitori e sviluppatori se i propri strumenti o servizi fanno uso di versioni vulnerabili di Parquet.

Conclusione

Anche se non sono ancora stati rilevati exploit attivi, la combinazione di gravità tecnica (CVSS 10.0) e ampia adozione della tecnologia rende CVE-2025-30065 una delle vulnerabilità più critiche del 2025 per l’ambito big data.

L'articolo CVE-2025-30065: la Vulnerabilità Critica RCE di Apache Parquet che Minaccia l’Ecosistema Big Data proviene da il blog della sicurezza informatica.

Negli ultimi anni, il mondo dello sviluppo software ha vissuto una trasformazione radicale, passando dall’esecuzione tradizionale delle applicazioni su server fisici a soluzioni più flessibili e scalabili. Un esempio chiaro di questa evoluzione è il percorso che un’applicazione compie dalla fase di sviluppo fino alla gestione automatizzata con Kubernetes.

Ma prima di andare avanti è meglio dare almeno le definizioni di container e orchestrator, concetti che troveremo più avanti:

• Cos’è un container? Un container è un ambiente isolato che contiene tutto il necessario per eseguire un’applicazione: codice, librerie e dipendenze. Grazie ai container, le applicazioni possono funzionare in qualsiasi sistema senza problemi di compatibilità.
• Cos’è un orchestrator? Un orchestrator, come Kubernetes, è uno strumento che gestisce automaticamente il deployment, il bilanciamento del carico, la scalabilità e il ripristino dei container, garantendo che l’applicazione sia sempre disponibile e performante.

Un po’ di storia: dalle origini dei container a Kubernetes

L’idea di eseguire applicazioni in ambienti isolati risale agli anni ’60 con il concetto di virtualizzazione, ma è negli anni 2000 che i container iniziano a prendere forma. Nel 2000, FreeBSD introduce i “Jails“, un primo tentativo di creare ambienti isolati all’interno di un sistema operativo. Nel 2007, Google sviluppa e introduce il concetto di Process Container, poi cgroups (Control Groups), una tecnologia che permette di limitare e isolare l’uso delle risorse da parte dei processi, e lo integra in Linux.

Nel 2013, Docker Inc. (all’epoca dotCloud) rivoluziona il settore introducendo Docker, una piattaforma open-source che semplifica la creazione, distribuzione ed esecuzione dei container. Grazie alla sua facilità d’uso, Docker diventa rapidamente lo standard de facto per il deployment delle applicazioni. La nascita di Docker ha rivoluzionato non solo la portabilità dei container, ma anche la standardizzazione di questi facendo passi da gigante nell’automatizzare e semplificare il processo di creazione e distribuzione dei container.

Con la crescente diffusione dei container, emerge la necessità di un sistema per gestirli su larga scala. Nel 2014, Google rilascia Kubernetes, un progetto open-source basato su Borg, un orchestratore interno utilizzato per anni nei data center di Google. Kubernetes diventa rapidamente il leader indiscusso nell’orchestrazione dei container, grazie al supporto della Cloud Native Computing Foundation (CNCF).

Il punto di partenza – sviluppo locale

Per cercare di capire cosa sia Kubernetes e qual’è la sua utilità è utile provare a ripercorrere lo sviluppo di una applicazione nel tempo.

Immaginiamo di dover sviluppare una piccola applicazione web, magari con Python e Flask. Il primo passo naturale è scrivere il codice e testarlo sulla propria macchina, installando le librerie necessarie e configurando l’ambiente per farlo funzionare. Finché l’applicazione è utilizzata solo dallo sviluppatore, questo approccio può andare bene.

Tuttavia, emergono rapidamente i primi problemi: cosa succede se dobbiamo eseguire la stessa applicazione su un altro computer? O se dobbiamo distribuirla a più sviluppatori senza conflitti tra librerie diverse? Qui entra in gioco la necessità di un sistema più standardizzato, che permetta anche di automatizzare alcune operazioni.

L’isolamento con Docker

Docker risolve questi problemi fornendo un ambiente isolato in cui l’applicazione può essere eseguita senza dipendere dalla configurazione del sistema operativo sottostante. Creando un’immagine Docker, è possibile impacchettare tutto il necessario (codice, dipendenze, configurazioni) in un unico file eseguibile, che può essere eseguito su diverse macchine. In questo modo, l’applicazione diventa più portatile: può essere avviata con un semplice comando e funzionerà in modo consistente su macchine con configurazioni simili, sia in locale che su server remoti.

Coordinare più servizi con Docker Compose

Molte applicazioni non sono autonome e richiedono l’interazione con altri servizi per funzionare correttamente. Ad esempio, un’applicazione web potrebbe dipendere da un database come PostgreSQL. In questi casi, gestire i singoli container separatamente può diventare complicato. Docker Compose semplifica questo processo, permettendo di definire e avviare più container contemporaneamente con un solo comando, gestendo facilmente le dipendenze tra i vari servizi.

Questo approccio semplifica la gestione di applicazioni composte da più servizi, rendendo lo sviluppo più fluido.

Ma cosa succede quando vogliamo eseguire la nostra applicazione non su un solo server, ma su più macchine, magari per gestire un traffico maggiore?

La scalabilità con Kubernetes

Dopo aver gestito l’ambiente di sviluppo e aver creato il container con Docker, il passo successivo è affrontare la gestione su larga scala, ed è qui che Kubernetes entra in gioco.

Se l’applicazione deve gestire un numero crescente di utenti, un singolo server non basta più , occorre passare a Kubernetes, un sistema di orchestrazione che automatizza la gestione dei container su più macchine.

Con Kubernetes, possiamo:

• Distribuire l’app su più server per garantire disponibilità continua.
• Scalare automaticamente il numero di container in base al carico di lavoro.
• Riavviare automaticamente i container che si bloccano o falliscono.
• Bilanciare il traffico tra le varie istanze dell’applicazione.

Questa flessibilità permette di affrontare qualsiasi esigenza di crescita, senza dover gestire manualmente ogni singolo container.

L’altra faccia della medaglia

Se da un lato Docker e Kubernetes hanno portato grandi vantaggi in termini di flessibilità, scalabilità e gestione delle applicazioni, dall’altro hanno anche ampliato la superficie di attacco e le potenzialità di vulnerabilità. Con l’introduzione di container, orchestratori e infrastrutture distribuite, si sono creati nuovi punti di accesso per attacchi informatici.

Ogni componente aggiunto all’infrastruttura (dal container stesso, ai vari microservizi, fino ai nodi gestiti da Kubernetes) introduce nuove potenziali vulnerabilità. Inoltre, la gestione di più container e il coordinamento tra di essi richiedono la gestione di credenziali, configurazioni di rete e comunicazioni che, se non protette adeguatamente, possono diventare veicoli per attacchi.

Il rischio aumenta ulteriormente con l’adozione di configurazioni errate, la gestione di dati sensibili non adeguatamente criptati e la possibilità di errori di programmazione nei microservizi che, se sfruttati, possono compromettere l’intero sistema. In un ambiente distribuito, un attacco a uno dei singoli componenti può avere ripercussioni su tutta l’infrastruttura, con effetti devastanti.

Conclusione: innovazione e sicurezza vanno di pari passo

L’evoluzione tecnologica portata da Docker, Kubernetes e le architetture distribuite, ha trasformato radicalmente il modo in cui sviluppiamo, distribuiamo e gestiamo le applicazioni. Grazie a queste tecnologie, le organizzazioni possono rispondere in modo più agile alle esigenze di mercato, ottimizzare le risorse e garantire scalabilità continua. Tuttavia, come con ogni innovazione, l’introduzione di queste soluzioni ha anche ampliato la superficie di attacco, portando con sé nuove sfide in termini di sicurezza.

Per sfruttare appieno i vantaggi di queste tecnologie senza incorrere nei rischi associati, è fondamentale che le aziende adottino un approccio di sviluppo sicuro sin dalle prime fasi del ciclo di vita del software. Ciò significa integrare pratiche di sicurezza in ogni fase del processo di sviluppo, dalla scrittura del codice alla gestione dei container e delle configurazioni, passando per la protezione dei dati e delle comunicazioni. La sicurezza non deve più essere vista come un elemento separato, ma come una componente fondamentale e proattiva da incorporare fin dall’inizio nei processi di produzione.

In definitiva, l’automazione e la scalabilità rappresentano il futuro della gestione applicativa, ma solo con una solida base di sviluppo sicuro e una gestione olistica della sicurezza queste innovazioni potranno essere pienamente sfruttate, assicurando al contempo che i benefici della trasformazione digitale non si traducano in vulnerabilità sistemiche.

L'articolo Dal codice alla scalabilità: il viaggio di un’applicazione con Docker e Kubernetes proviene da il blog della sicurezza informatica.

If you flew or drove anything remote controlled until the last few years, chances are very good that you’d be using some faceless corporation’s equipment and radio protocols. But recently, open-source options have taken over the market, at least among the enthusiast core who are into squeezing every last bit of performance out of their gear. So why not take it one step further and roll your own complete system?

Apparently, that’s what [Malcolm Messiter] was thinking when, during the COVID lockdowns, he started his own RC project that he’s calling LockDownRadioControl. The result covers the entire stack, from the protocol to the transmitter and receiver hardware, even to the software that runs it all. The 3D-printed remote sports a Teensy 4.1 and off-the-shelf radio modules on the inside, and premium FrSky hardware on the outside. He’s even got an extensive folder of sound effects that the controller can play to alert you. It’s very complete. Heck, the transmitter even has a game of Pong implemented so that you can keep yourself amused when it’s too rainy to go flying.

Of course, as we alluded to in the beginning, there is a healthy commercial infrastructure and community around other open-source RC projects, namely ExpressLRS and OpenTX, and you can buy gear that runs those software straight out of the box, but it never hurts to have alternatives. And nothing is easier to customize and start hacking on than something you built yourself, so maybe [Malcolm]’s full-stack RC solution is right for you? Either way, it’s certainly impressive for a lockdown project, and evidence of time well spent.

Thanks [Malcolm] for sending that one in!

hackaday.com/2025/04/04/lockdo…

We remember when the transputer first appeared. Everyone “knew” that it was going to take over everything. Of course, it didn’t. But [Oscar Toledo G.] gives us a taste of what life could have been like with a JavaScript emulator for the transputer, you can try in your browser.

If you don’t recall, the transputer was a groundbreaking CPU architecture made for parallel processing. Instead of giant, powerful CPUs, the transputer had many simple CPUs and a way to chain them all together. Sounds great, but didn’t quite make it. However, you can see the transputer’s influence on CPUs even today.

Made to work with occam, the transputer was built from the ground up for concurrent programming. Context switching was cheap, along with simple message passing and hardware scheduling.

The ersatz computer has a lot of messages in Spanish, but you can probably muddle through if you don’t hablar español. We did get the ray tracing example to work, but it was fairly slow.

Want to know more about the CPU? We got you. Of course, these days, you can emulate a transputer with nearly anything and probably outperform the original. What we really want to see is a GPU emulation.

hackaday.com/2025/04/04/the-tr…

[Morten] works very fast. He has already designed, fabbed, populated, and tested a breakout board for the new tiniest microcontroller on the market, and he’s even made a video about it, embedded below.

You might have heard about this new TI ARM Cortex MO micro on these very pages, where we asked you what you’d do with this grain-of-rice-sized chunk of thinking sand. (The number one answer was “sneeze and lose it in the carpet”.)

From the video, it looks like [Morten] would design a breakout board using Kicad 8, populate it, get it blinking, and then use its I2C lines to make a simple digital thermometer demo. In the video, he shows how he worked with the part, from making a custom footprint to spending quite a while nudging it into place before soldering it carefully down.

But he nailed it on the first try, and honestly it doesn’t look nearly as intimidating as we’d feared, mostly because of the two-row layout of the balls. It actually looks easy enough to fan out. Because you can’t inspect the soldering work underneath the chip, he broke out all of the lines to a header to make it quick to check for shorts between those tiny little balls. Smart.

We love to see people trying out the newest hotness. Let us know down in the comments what new parts you’re trying out.

Thanks [Clint] for the tip!

youtube.com/embed/XSAPGh9um_k?…

hackaday.com/2025/04/04/first-…

If you’re on the US East Coast, you should head on over to Wall, NJ and check out the Vintage Computer Festival East. After all, [Brian Kernighan] is going to be there. Yes, that [Brian Kernighan].

Events are actually well underway, and you’ve already missed the first few TRS-80 Color Computer programming workshops, but rest assured that they’re going on all weekend. If you’re from the other side of the retrocomputing fence, namely the C64 side, you’ve also got a lot to look forward to, because the theme this year is “The Sounds of Retro” which means that your favorite chiptune chips will be getting a workout.

[Tom Nardi] went to VCF East last year, so if you’re on the fence, just have a look at his writeup and you’ll probably hop in your car, or like us, wish you could. If when you do end up going, let us know how it was in the comments!

hackaday.com/2025/04/04/vintag…