Arduino on Melabit

Antigravity: l'LLM lo fa meglio

Mon, 16 Mar 2026 18:00:00 +0000

Nelle ultime settimane ho scritto delle mie esperienze con Antigravity, o meglio con gli agenti (più o meno) intelligenti integrati in questo editor. I risultati sono stati contrastanti: a volte gli agenti si sono dimostrati molto efficaci, alleviando con precisione alcuni compiti complessi o ripetitivi, in altri casi non hanno combinato niente di buono facendo solo perdere una montagna di tempo.

Programmare male con l’LLM

Fra tutti gli impieghi più o meno utili degli LLM, uno dei più controversi è l’idea che chiunque possa usare un LLM per programmare, anche quando di programmazione non se ne sa una cippa. È il cosidetto vibe coding, un concetto che si può riassumere così: “vedo cose, dico cose, copio e incollo cose, e nella maggior parte dei casi funziona”. Non è una citazione da Nanni Moretti, lo dice Andrej Karpathy, uno dei fondatori di OpenAI.

Ora, mettendo da parte le tante questioni relative alla sicurezza, alla manutenibilità di codice prodotto senza sapere bene cosa fa, alla deriva verso la media che implica che la qualità del codice prodotto dall’IA tenderà inevitabilmente a crollare, basta sperimentare un po’ in prima persona, anche con progetti semplici, per accorgersi che l’idea del coding per tutti non funziona, e che se vuoi ottenere qualcosa di buono dall’IA devi sapere bene cosa vuoi e come lo vuoi.

Ci ho provato io stesso a fare vibe coding: ho chiesto a Gemini di scrivere un driver per una videocamera Arducam, spiegandogli solo le cose indispensabili a aspettando che facesse tutto da solo.¹

Questo approccio però non ha funzionato. Ci sono volute ore ed ore di lavoro, di errori, di risposte inconcludenti, di correzioni e di consigli per raggiungere un risultato accettabile.

E questo solo perché a un certo punto ho buttato alle ortiche l’idea di far fare tutto a Gemini e gli ho dato dei consigli su come procedere. Senza quelli sarebbe stato solo un sacco di tempo buttato via inutilmente.

Anche Mimmo ha provato, in modo del tutto indipendente da me, a far scrivere a Lumo un programma in Micropython per gestire la mia Arducam Mini 5MP Plus con il Pico. E anche Lumo, che è senza dubbio uno dei migliori chatbot in circolazione, non ce l’ha fatta da solo.

– Immagine generata da Google Gemini.

Programmare meglio con lo stesso LLM

Tutto questo però non significa che un LLM non possa essere prezioso quando si programma, basta solo usarlo come si deve. Bisogna spiegargli per filo e per segno cosa deve fare, mettergli a disposizione tutto il materiale che gli serve per lavorare, e piazzargli dei paletti entro cui deve muoversi.

In poche parole, bisogna trattarlo come un tesista o una stagista, con poca esperienza ma tanta voglia di imparare.

Sono bastati infatti due prompt scritti con criterio, il primo che definiva la struttura delle directory del progetto e istruiva l’agente ad usare fin dall’inizio git per il controllo di versione del codice e uv per installare i pacchetti Python che gli sarebbero potuti servire,

Prompt

Start a new project and name it project13-pico-camera5mp-reprise.

Read the AGENTS.md file that defines your basic behaviour.

Create a new directory with this name and initialize an empty git repository using git init Use uv for managing Python packages. All the code must stay in the code directory, with no subdirectories within it. This project does not need a data directory and the output directory must be renamed as images.

e il secondo che conteneva tutto quello che mi è venuto in mente per aiutarlo a lavorare,

Prompt

I have a Rasperry Pi Pico 2W connected to a Arducam 5MP Plus OV5642 Mini Module Camera Shield (https://www.arducam.com/arducam-5mp-plus-spi-cam-arduino-ov5642.html).

I have connected the camera to the Pico using the standard layout found in the documentation:

Camera	CS	MOSI	MISO	SCK	GND	VCC	SDA	SCL
Pico	GP5	GP3	GP4	GP2	GND	3V3	GP8	GP9

The main documentation for the camera can be found at these links:

The code to drive this camera with the Pico is written in C (i.e., for Arduino) and CircuitPython, and can be found here: https://github.com/ArduCAM/PICO_SPI_CAM. You can download all the files you need from this repository. In particular, the files for CircuitPython are in the Python directory:

Arducam.py, which contains the functions to drive the camera,
OV5642_reg.py which, as far as I have understood, defines the resolutions allowed when taking pictures, and
boot.py , but I don’t know what it does. In the same directory there is also the script ArduCAM_Mini_5MP_Plus_VideoStreaming.py which sends the video captured by the camera to a Windows application and that is of no use here.

Please write a basic CircuitPython script that uses the functions defined in Arducam.py to test that the camera works and can take photos.

per permettere a Gemini 3 Flash di generare rapidamente uno script in CircuitPython che gira direttamente sul Pico e che fa tutto quello che gli è stato chiesto.

In verità, la primissima versione dello script non funzionava, ma è bastato a Gemini modificare una sola riga del driver Arducam.py fornito dal produttore per mettere tutto a posto (ha tolto uno zero al valore della frequenza).²

– La linea evidenziata in azzurro indica l’unica modifica effettuata da Gemini al file Arducam.py; a sinistra il file originale, a destra quello modificato da Gemini.

Tutti gli altri file forniti dal produttore sono rimasti intatti.

Alla prova dei fatti, il driver del produttore funzionava benissimo con il Pico e Gemini si è limitato ad imparare ad usarlo per scrivere lo script che cattura l’immagine direttamente dal microcontroller (una cosa che con un po’ di pazienza avrei potuto fare anch’io).

Guidare l’LLM o lasciarlo fare da solo?

La differenza rispetto al vibe coding della volta scorsa è abissale.

In quel caso Gemini aveva lavorato furiosamente per ore, combinando dei tali casini da costringermi a riavviare per ben due volte il Mac. E nel frattempo si era convinto (e mi aveva convinto) che il driver Arducam.py fosse incompatibile con Il Pico e l’aveva riscritto da zero, buttando via una libreria essenziale per interloquire con la videocamera (quella indicata dalla freccia rossa),

– Modifiche alle prime righe del file Arducam.py; a sinistra il file originale, a destra come appare lo stesso file dopo le modifiche di Gemini. La freccia indica una libreria importante che viene rimossa di peso da Gemini.

e togliendo senza nessun motivo, e senza nemmeno un guadagno reale in termini di efficienza o di funzionalità (anzi!), la maggior parte delle funzioni definite nello stesso file (si noti nell’immagine qui sotto la differenza nella lunghezza del codice originale, a sinistra, rispetto a quello modificato, a destra).

– Modifiche al file Arducam.py. I rettangoli rossi mettono in evidenza la differenza fra il numero di righe del codice originale (a sinistra) e di quello modificato da Gemini (a destra).

E non contento di tutto ciò, aveva pure stravolto il file OV5642_reg.py contenente i dati di configurazione della videocamera, adducendo dei presunti problemi di memoria. Problemi che evidentemente non esistevano, visto che in questo secondo esperimento tutto è filato liscio usando il file originale del produttore.

– Modifiche al file OV5642_reg.py, contenente i dati di configurazione della videocamera. La configurazione originale (a sinistra) è stata totalmente stravolta da Gemini (a destra).

E Arduino?

Arrivato a questo punto era inevitabile che chiedessi a Gemini di generare anche il driver per Arduino, usando le stesse informazioni che gli avevo già fornito per CircuitPython.

Questa volta Gemini ha penato di più, ma soprattutto perché gli avevo imposto di effettuare solo delle modifiche minime alle librerie originali Arducam. Un vincolo che questa volta era impossibile da soddisfare, perché queste librerie non supportano nativamente il Raspberry Pi Pico.

Risposta

Researching Arducam Library Compatibility I’ve thoroughly inspected both the original ArduCAM library and the Arducam_mini library. Neither version contains native support for the RP2040/RP2350 (Pico) architecture. Specifically, both libraries are missing the necessary definitions for regtype, regsize, cbi, and sbi for this platform, which is the root cause of the compilation errors.

Una volta allentato questo vincolo le cose sono filate lisce e in poco tempo anche il driver modificato ad hoc per il Pico ed il relativo programma di acquisizione delle immagini erano pronti.

Gratis o a pagamento?

C’è chi sostiene che i modelli a pagamento sono molto meglio di quelli gratuiti. Di conseguenza, i miei problemi con il vibe coding sarebbero scomparsi se avessi pagato per usare Gemini o Claude.

Non è proprio così. Nel corso delle prove ho usato prevalentemente la versione gratuita di Gemini, proprio per verificare cosa succedeva all’utente non professionale che voleva provare a giocare un po’ con questi strumenti. Ma quando finivano i token sono passato alla versione a pagamento di Gemini fornita dall’università, e non ho mai notato differenze significative. Su Claude non posso dire niente, perché dover pagare 200 dollari al mese per usarlo in modo serio non ha senso per chi, come il sottoscritto, non è un programmatore professionista.

Ho notato però che Claude Opus e Claude Sonnet si sono sempre dimostrati molto più bravi di Gemini a risolvere i problemi che si presentavano nel corso dello sviluppo del codice. Ma poiché li ho utilizzati sempre a lavoro inoltrato, potrebbero solo essere stati facilitati da quello che Gemini aveva già fatto.

Conclusioni

È inutile dire che sia questo esperimento che quello precedente non hanno nulla di scientifico. Per essere tale, dovrei almeno utilizzare tipi diversi di microcontroller e di moduli collegati, stabilire un set di prompt ben definito e misurare in qualche modo come cambia la risposta dell’agente di turno al variare delle condizioni sperimentali.

Ma nonostante questo, l’esperimento ha un pregio: è riproducibile. Chiunque, con una spesa ridotta, può provare a ripeterlo usando lo stesso hardware e gli stessi prompt, in modo do verificare di persona se quello che ho trovato io è corretto o no.³

Una cosa che gli apostoli del vibe coding da decine di milioni di letture evitano sempre accuratamente di proporre. I loro articoli sono pieni di certezze e di previsioni roboanti, ma mancano sempre di fornire il sia pur minimo appiglio che permetta di verificare i loro claim.

Nessuno, oggi, può ancora negare che gli LLM possano essere di grande aiuto durante la programmazione, ma è difficile credere che riescano davvero a farlo senza nessun intervento umano. E questo almeno finché gli apostoli di cui sopra non si degneranno di fornirci dati chiari e ripetibili a supporto delle loro affermazioni.

Pur sapendo qualcosa di programmazione, non avevo la minima idea di come si potesse sviluppare un driver e non avevo nessuna voglia di passare dei giorni a studiare come si fa. ↩︎
Tecnicamente questo file è una libreria di funzioni, ma i microcontroller non hanno un sistema operativo e quindi queste funzioni accedono direttamente all’hardware, proprio come fanno i driver che controllano i componenti di un computer. Di conseguenza, in questo caso i termini libreria e driver sono interscambiabili. ↩︎
Dico spesa ridotta ma ormai la penuria di componenti elettronici ha fatto impazzire i prezzi del Pico e ancor di più della Arducam Mini 5MP Plus. Quest’ultima, dai 40 euro di pochi mesi fa ora si trova su Amazon o AliExpress a più del triplo. Per fortuna alcuni rivenditori mantengono (almeno per ora) dei prezzi più onesti. ↩︎

Effetto Dory

Mon, 09 Mar 2026 18:00:00 +0000

Lo so che gli LLM hanno poca memoria, ma non avrei mai immaginato di doverne subire così in fretta le conseguenze.

– Immagine generata da Google Gemini.

Nota per il lettore. Questo articolo è un complemento di quello precedente, Antigravity: un driver scritto dall’IA e andrebbe letto dopo il primo. Ma ecco un breve riassunto per i più pigri.

Non sapendo come fare a scrivere un driver per una videocamera SPI collegata ad un Raspberry Pi Pico, ho chiesto aiuto a Gemini 3 Flash, lavorando interamente dentro Antigravity. Dopo parecchie ore di lavoro, l’agente è riuscito a scrivere un programma funzionante in Arduino. A questo punto ho fatto un errore fatale, chiedendogli ancora di più, ma senza prendere delle precauzioni.

Premessa

Il codice funzionante generato con tanta fatica da Gemini 3 Flash prevedeva che il Pico facesse da interfaccia fra il mio Mac Mini e la videocamera SPI.¹ Sul Mac, uno script in Python comandava la cattura di una immagine, mentre l’acquisizione vera e propria veniva eseguita dal Pico tramite un programma per Arduino (uno sketch, nel gergo della piattaforma), che è fondamentalmente codice C/C++ adattato all’uso con i microcontrollori.

Comandare tutto da computer va benissimo per le prime prove, ma è molto scomodo quando si prevede di usare un dispositivo di questo genere per delle attività sul campo.

Catture automatiche

Allora ho chiesto a Gemini di modificare il codice in modo da effettuare automaticamente la cattura dell’immagine ogni N minuti oppure premendo un pulsante, inviando poi l’immagine ad un computer tramite Wi-Fi.²

Prompt

[...] However, this means that I need to use a Pico for the capture and another computer, even a Raspberry Pi Zero for commanding the capture process. Would it be possible to do everything on the Pico, eg press a button and perform the capture or via a timed process (defined in the .ino file itself) every N minutes (but there should be a mechanism that sends the images to a computer connected by WiFi, avoiding to fill the pico storage space).

Gemini si mette subito al lavoro, sempre continuando ad usare Arduino. Dovrebbe essere un programma molto semplice da realizzare ma, per quanto Gemini ci provi, non funziona mai. Dopo molti tentativi infruttuosi mi scoccio e gli chiedo di ritornare all’ultima versione funzionante del programma.

Tornare sui propri passi

E qui Gemini sbatte contro un muro imprevisto perché, nonostante la mia guida e i miei continui suggerimenti, non c’è assolutamente verso di riuscirci.

Stupidamente non avevo pensato di tenere traccia delle varie versioni del codice man mano che veniva generato, e questa è solo ed esclusivamente colpa mia.

Ma d’altre parte, pur essendo ben consapevole che i modelli linguistici di grandi dimensioni (LLM, Large Language Model) mentre lavorano hanno una memoria che sembra quella della pesciolina Dory, non avrei mai immaginato che questi sistemi ultrasofisticati non fossero neanche in grado di ricostruire a posteriori ciò che hanno fatto, pur avendo a disposizione decine e decine di file implementation_plan.md, task.md e walkthrough.md, che descrivono per filo e per segno tutti i passaggi precedenti (li ho contati, solo per questo progetto Antigravity ha generato più di 250 file diversi).

Tornare sui propri passi è una cosa che invece strumenti come git e i suoi predecessori, tutti privi di una qualunque forma di intelligenza che non sia quella dei suoi creatori, sono in grado di fare benissimo da più di cinquant’anni. Magari chi sviluppa questi agenti tanto intelligenti potrebbe farci un pensierino, no?

Epilogo

Alla fine, testardamente e basandomi sulle mie note,³ sono riuscito a far ripetere a Gemini tutto quello che aveva già fatto. Ci ha messo delle ore, ha ripetuto pari pari tutti gli errori della volta precedente, ma alla fine il codice ricostruito funziona di nuovo correttamente.

Già che c’ero, gli ho fatto rifare tutto anche per CircuitPython, e anche questo port ha richiesto molte altre ore di lavoro e di errori. E, prima di arrivarci, Gemini ha creato dei problemi talmente gravi che macOS ha dovuto disabilitare la comunicazione delle porte USB con il Pico, costringendomi a riavviare per un paio di volte il Mac.

Inutile dire che questa volta gli ho fatto tenere traccia di ogni passaggio con git e ho messo pure tutto il codice su GitHub, non si sa mai.

Uno dei prossimi passi sarà (spero) MicroPython, ma questa è ancora un’altra storia.

Perché Arduino fa tanta fatica, pur se è una piattaforma di sviluppo per microcontroller molto più matura di MicroPython e CircuitPython? Perché, per il modello di videocamera che ho scelto, Arducam non supporta il Raspberry Pi Pico ma solo i Raspberry Pi classici (quelli con il sistema operativo, per intenderci, come il Rasperry Pi 4, 5 e lo Zero), nonché tutti i microcontroller Arduino e ESP286. ↩︎
Lo so che l’inglese non è un gran che, è più un flusso di pensieri che un discorso organico. Ma ci sono dettagli che mi vengono in mente mentre scrivo, e preferisco buttarli giù così alla bell’e meglio piuttosto che perdere il filo delle idee. ↩︎
Non ripeterò mai abbastanza quanto sia importante tenere delle note scritte di quello che si fa. All’inizio sembra solo una perdita di tempo, mentre invece è il modo migliore per evitare di perderlo in futuro. ↩︎

Antigravity: un driver scritto dall'IA

Wed, 04 Mar 2026 18:00:00 +0000

Fra tutti i modelli di Raspberry Pi e di Arduino con cui al momento passo la giornata, il mio preferito è senza dubbio il Raspberry Pi Pico, un microcontrollore piccolo ma potente, in grado di essere programmato non solo in C/C++ tramite l’IDE di Arduino, ma anche in MicroPython e CircuitPython, due versioni diverse (e concorrenti) di Python specifiche per i microcontrollori.

A differenza degli altri modelli di Raspberry Pi, il Pico non dispone di una connessione dedicata alla videocamera, ma può utilizzare quelle con interfaccia SPI,¹ come ad esempio la Arducam Mini 5MP Plus.

In teoria non dovrebbe essere un lavoro difficile. Dopo aver dato una occhiata alla documentazione ufficiale, si tratta solo di collegare la videocamera al Pico, scaricare il driver e i programmi di test dal repository GitHub del produttore, copiarli sul Pico dopo aver installato la versione di Python supportata, e infine provare a scattare qualche foto.

Non avrei potuto sbagliarmi di più.

Ci vuole un driver

Gli unici due programmi di di test disponibili, uno per Arduino e l’altro per CircuitPython, prevedevano di utilizzare Windows per visualizzare il video prodotto dalla videocamera, una cosa insolita dato che la stragrande maggioranza di chi lavora con questi dispositivi usa Linux o macOS. CircuitPython, poi, è meno diffuso di MicroPython, e io avrei preferito usare quest’ultimo per compatibilità con gli altri componenti già collegati al Pico.

Con un po’ di pazienza, e avendo a disposizione un programma che insegna ad usare le funzioni principali per gestire il dispositivo, si può provare a tradurre il codice CircuitPython in MicroPython (e viceversa),² ma in questo caso non c’era nulla del genere a disposizione.

Altra guide trovate sul web sembravano promettenti, ma alla prova dei fatti non funzionavano. L’unica opzione rimasta era quella di bypassare i tool ufficiali e di scriversi da solo un driver per la videocamera.

Una parola!

Io so come scrivere il codice per risolvere una equazione differenziale o per analizzare dei dati di misura. Me la cavo anche con la programmazione di microcontrollori ed affini per catturare i dati dei sensori collegati. Ma qui si tratta di ben altro. Si tratta di studiare nei dettagli come funziona a basso livello la comunicazione fra il Pico e la videocamera. Un lavoro da ingegneri specializzati, che scrivono i driver che poi permettono a noi umani di eseguire operazioni complesso come scattare una foto con poche righe di codice Python.

E allora perché non mettere al lavoro uno degli agenti integrati in Antigravity per fargli fare quello che io non sono capace di fare?

Non sarei stato obbligato ad usare Antigravity, anche Claude Code, Google Gemini, Deepseek o uno degli altri mille LLM che abbiamo a disposizione avrebbe potuto tranquillamente lavorarci su. Ma, come ho già scritto, usare uno degli agenti integrati in Antigravity permette di lavorare direttamente nell’editor e di accedere al sistema operativo sottostante, una vantaggio enorme quando si deve provare e riprovare mille volte il codice prodotto.

L’IA al lavoro

Quando si leggono tanti articoli entusiastici sul vibe coding, ovvero sullo sviluppo del software eseguito dall’intelligenza artificiale senza nessun intervento o quasi da parte del programmatore umano, sembra tutto facile (tanto per citarne qualcuno, questo articolo che ha avuto milionate di letture oppure questo senza dimenticare il tweet che ha iniziato tutto).³ In sostanza, scrivi due-tre righe chiedendo all’LLM o all’agente di turno di fare questo o quello, te ne vai a pranzo o a fare una passeggiata e quando torni è tutto pronto.⁴

Proviamo per una volta a fare lo stesso con Gemini, dandogli solo le informazioni essenziali e verificando cosa riesce a fare davvero. In questo caso queste informazioni si riducono al link alla pagina web della videocamera e a una tabella che descrive come sono collegati i pin della videocamera al Pico (sono più di tre righe, lo so, ma io sono prolisso).

Prompt

I have a Rasperry Pi Pico 2W connected to a Arducam 5MP Plus OV5642 Mini Module Camera Shield (https://www.arducam.com/arducam-5mp-plus-spi-cam-arduino-ov5642.html). I have connected the camera to the Pico using the standard layout found in the documentation:

Camera	CS	MOSI	MISO	SCK	GND	VCC	SDA	SCL
Pico	GP5	GP3	GP4	GP2	GND	3V3	GP8	GP9

Please write a basic Micropython code to test that everything is right and that the camera can take photos

Gemini ci lavora su furiosamente, tira fuori codice MicroPython che non funziona, si ingegna a correggerlo in base ai miei suggerimenti e finisce sempre per fare nuovi errori (dico sempre Gemini per semplicità, ma sono passato anche a Gemini 3.1 Pro, Claude Opus 4.6 e Claude Sonnet 4.6 via via che finivano i token).

A un certo punto, non sapendo più che pesci prendere, Gemini ipotizza anche che ci sia un problema hardware, come un collegamento sbagliato o una videocamera difettosa (ma interrogando i singoli pin della videocamera è facile verificare che tutto funziona correttamente).

Dopo ore ed ore di lavoro e dato che con MicroPython non riesce a combinare niente di buono, gli chiedo di passare ad Arduino, che è una piattaforma software più matura. Ci vogliono altre ore di lavoro ma alla fine, testardamente, ce la fa, e quella qui sotto è la prima immagine in assoluto scattata con il codice Arduino generato da Gemini (l’immagine originale era al contrario e io mi sono limitato a ruotarla di 180°).

Va detto che subito dopo faccio un errore gravissimo che mi, anzi ci, costringe a rifare tutto da capo. Ma questo è argomento di un’altra storia.

Epilogo

Una volta generato un programma funzionante in Arduino, chiedo a Gemini di rifare tutto per CircuitPython. Anche questo port richiede parecchie ore di lavoro, inframmezzate da un paio di riavvi forzati del Mac che, dopo qualche bug di troppo, è stato obbligato a disabilitare la comunicazione fra le porte USB e il Pico.

In teoria dovrei ripetere il ciclo per la terza volta con MicroPython. Ma l’idea di perdere chissà quanto altro tempo a guardare Gemini che lavora mi fa venire i brividi e lascio perdere, almeno per ora.

Conclusioni

Non so cosa usano quelli che scrivono gli infiniti articoli che proclamano che chiunque, anche se non sa un tubo di programmazione, può farsi scrivere dall’IA in poco tempo un programma perfettamente funzionante.

Anche se di programmazione ne so qualcosa, a me è successo solo per gli esperimenti più semplici descritti nei due articoli precedenti. E men che meno è successo in questo caso. Va detto, però, che sono in buona compagnia.

– Immagine generata da Google Gemini.

È vero, seguendo alla lettera i dettami del vibe coding, qui non ho scritto nemmeno una riga di codice e ho fatto eseguire a Gemini perfino i comandi di Terminale che potrei scrivere ad occhi chiusi. Ma è altrettanto vero che se non avessi dialogato di continuo con l’agente, se non lo avessi guidato passo passo, se non avessi corretto i suoi tanti tanti errori, a volte davvero banali, Gemini non sarebbe andato da nessuna parte.

E ci sono volute molte ore di lavoro ininterrotto, fin troppe ore secondo me, per ottenere qualcosa di utilizzabile.

Altro che programmazione rapida ed intuitiva. Altro che codice basato sulle buone vibrazioni stile anni ‘60. Altro che programmazione for dummies!⁵

Se non ti rimbocchi le maniche e non ti dai da fare in prima persona con il codice, anche quello prodotto da un agente più o meno intelligente, non vai da nessuna parte. Sarebbe bello essere smentito.

L’interfaccia SPI (Serial Peripheral Interface) è una interfaccia di comunicazione seriale, molto utilizzata per collegare un microcontrollore (master) ad uno o più dispositivi periferici (slave) in modo veloce ed affidabile. ↩︎
Mentre scrivevo l’articolo ho trovato questo video, che spiega come mescolare nello stesso script codice MicroPython e CircuitPython. Se funzionasse anche in casi più complicati di accendere e spegnere un LED sarebbe davvero una svolta. ↩︎
Sarà un caso che sono sempre post lunghissimi ma senza mai uno straccio di prova, un prompt, qualche brano di codice, dei link a supporto delle tante affermazioni non verificate e non verificabili? ↩︎
Mai nessuno, da vero nerd, dice che va a fare un po’ di sesso. ↩︎
Dal titolo di una famosa serie di guide introduttive agli argomenti più svariati, che spaziavano da come usare il DOS a come giocare a scacchi. ↩︎

Babbo Natale in ritardo

Fri, 15 Mar 2024 06:00:00 +0000

Babbo Natale è arrivato un po’ in ritardo quest’anno, però mi ha portato un bel po’ di Raspberry e Arduino, con accessori in quantità. Tutto pagato da un Ministero, che è sempre una bella soddisfazione.

Ora ho il Mac Studio, ho i Raspberry, ho gli Arduino, ho tutti i sensori che mi servono; non ho più scuse, devo mettermi a lavorare sul serio!

Golf a rischio

Sun, 21 Aug 2016 06:00:00 +0000

È un periodaccio per la Volkswagen. Prima il dieselgate, lo scandalo delle emissioni truccate dei motori diesel, esploso un anno fa negli USA e che costerà all’azienda di Wolfsburg almeno 15 miliardi (!) di dollari di multe e rimborsi ai consumatori statunitensi (ma non a quelli europei, la Commissione Europea come al solito, forte con i deboli ma debolissima con i forti ha deciso di non perseguire la Volkswagen).

Poi la pubblicazione dell’esistenza di una falla nel sistema di accensione, che consente di mettere in moto da remoto le auto del gruppo costruite a partire dal 1995 anche se non si dispone del telecomando con chip RFID che in teoria dovrebbe proteggere l’auto dalle attenzioni dei malintenzionati.

Ora la scoperta di una grave vulnerabilità del sistema di sblocco della serratura. Un semplice congegno elettronico da 40 dollari, costruito utilizzando il diffusissimo micro-controller Arduino, permette di clonare il telecomando ed aprire a distanza la serratura delle Volkswagen, Audi, Seat, Skoda, costruite negli ultimi quindici anni. Fanno circa 100 milioni di auto a rischio.

La Volkswager ha fatto di tutto per evitare che questi problemi venissero resi pubblici, arrivando persino a perseguire legalmente i ricercatori che hanno scoperto le falle nei sui sistemi di sicurezza. Meglio nascondere la testa sotto la sabbia che tutelare i clienti cercando di risolvere il problema.

Intanto i veri cattivi probabilmente usano già queste tecniche per rubare le auto di alto livello del gruppo. Oppure per rubare oggetti di valore senza lasciare tracce. Ci sono i video che lo dimostrano: la polizia non ci si raccapezza, le assicurazioni non pagano, i danneggiati vengono considerati dei truffatori in cerca di un finto risarcimento.

Soluzioni? Una sola, proposta dagli stessi ricercatori che hanno scoperto le falle di sicurezza: usare la serratura meccanica. Come facevo a fine anni settanta con la 500 (quella vera) di mia madre.