2026-10-07

Una settimana tra agenti AI, Linux e piccoli esperimenti

 


Questa settimana è stata meno concentrata su un singolo progetto e molto più su una serie di esperimenti che, messi insieme, stanno cambiando abbastanza il mio modo di usare il computer. Il filo conduttore è sempre lo stesso: Linux, intelligenza artificiale e automazione, ma con un passaggio sempre più evidente dall'AI che risponde alle domande all'AI che fa effettivamente delle cose.

ChatGPT comincia a diventare un agente

La novità forse più interessante non è un programma che ho scritto, ma il modo in cui sto usando ChatGPT.

Negli ultimi giorni ho iniziato a sfruttarlo sempre più come un vero assistente operativo, collegandolo anche ad alcuni servizi dell'ecosistema Google. Senza entrare nei dettagli delle mie cose personali, significa poter lavorare con Drive, Fogli, posta e calendario direttamente dalla conversazione.

La differenza rispetto al normale chatbot è notevole: non gli chiedo soltanto come fare qualcosa, ma in alcuni casi gli chiedo direttamente di farla.

È ancora un esperimento e ci sono naturalmente limiti e operazioni per le quali preferisco mantenere il controllo manuale, ma è probabilmente uno degli utilizzi dell'AI che in questo momento trovo più interessanti.

Questo ha anche ridimensionato un po' il ruolo di Hermes. L'avevo sperimentato parecchio come assistente personale, ma l'ho rimosso dal PC principale insieme a PicoClaw. Hermes continua a vivere sul vecchio Raspberry rakgateway, collegato a Telegram, mentre sul desktop sto spostando una parte maggiore del lavoro verso ChatGPT come agente più generale.

Lo stesso Raspberry ha ormai una vita completamente diversa da quella per cui era nato: ho chiuso il nodo LoRa-One e tolto la scheda LoRa. rakgateway oggi fa soprattutto da nodo Tor — ospitando anche il sito dei Cantinari — e da piccolo server per Hermes.

Linux Mint: zram e kernel 7.3

Sul fronte Linux sono tornato a fare quello che faccio periodicamente da anni: cercare di capire quanto si possa spremere ancora dal sistema senza trasformarlo in qualcosa di fragile.

Questa volta ho lavorato soprattutto su zram, provando configurazioni diverse per capire come gestire meglio memoria e swap compressa e rendere il desktop più reattivo quando il carico aumenta.

In parallelo sono arrivati gli esperimenti con il kernel Linux 7.3. Ho lavorato sulla compilazione e sulla messa a punto del kernel per la mia macchina, cercando un compromesso sensato tra ottimizzazione e mantenibilità.

Non mi interessa ottenere un numero spettacolare in un benchmark: l'obiettivo continua a essere quello alla base del mio progetto mint-cachyfy, cioè vedere quanto ci si possa avvicinare alla reattività delle distribuzioni Linux più aggressive mantenendo però Linux Mint come sistema quotidiano.

Sono esperimenti, quindi per ora niente proclami: zram, scheduler, kernel e parametri vari vanno provati nell'uso reale prima di decidere se una modifica abbia veramente senso.

Codice, agenti e documentazione

Un'altra riflessione della settimana riguarda il modo in cui sto programmando.

Uso ormai diversi agenti: ChatGPT, Codex e, in alcuni casi, DeepSeek attraverso gli strumenti che mi sono costruito. Il problema comincia paradossalmente a essere ricordarsi chi ha fatto cosa.

Da qui l'idea di mantenere una sorta di diario delle modifiche, utilizzabile anche dagli agenti stessi. Potrebbe diventare un modo semplice per documentare automaticamente il lavoro fatto sui progetti, indicando anche quale modello o agente è stato utilizzato.

È una piccola cosa, ma credo possa diventare importante: quando un agente modifica decine di file in pochi minuti, la documentazione non è più un optional.

Resta valida anche l'organizzazione sperimentata con ai-bar: una base generica sul branch main, una parte personale separata e un AGENTS.md che spiega agli agenti come intervenire senza distruggere la struttura del progetto. ai-bar su GitHub

Nello stesso filone continua l'uso di freellmApi con za.py, con l'idea di permettere a un modello di interagire con il sistema operativo attraverso un livello controllato invece di dargli semplicemente una shell libera.

RepoRoulette: GitHub senza sapere cosa arriverà dopo

Continua anche il piccolo esperimento che avevo iniziato per riscoprire il lato esplorativo di GitHub: RepoRoulette.

L'idea rimane volutamente semplicissima: invece di cercare sempre qualcosa che già conosco, voglio farmi presentare repository casuali, uno dopo l'altro, con una modalità che ricorda un po' la vecchia Chatroulette.

Il sito è qui:

RepoRoulette

È un progetto minuscolo, ma mi piace perché risolve un problema reale: GitHub contiene una quantità enorme di software interessante che normalmente non incontrerei mai.

Piccoli progetti che continuano a muoversi

Anche GitHub continua a essere il mio laboratorio. Fra i repository su cui ho lavorato e che sto continuando a tenere vivi ci sono ai-bar, mint-cachyfy e DroneCommander.

C'è poi image2ascii, un piccolo programma Python che trasforma immagini PNG e JPEG — e opzionalmente SVG — in ASCII art a colori nel terminale usando caratteri Unicode e colori ANSI a 24 bit. Il repository conta attualmente sei commit ed è esattamente il genere di utility piccola e autosufficiente che mi diverte ancora scrivere.

DroneCommander rimane invece uno degli esperimenti più strutturati: simulazione 3D nel browser, Blockly e l'idea di arrivare dal simulatore al controllo di piccoli droni reali. Il progetto è pubblico e continua a essere disponibile con licenza MIT.

Robot personali: continuo a guardarli

Rimangono sullo sfondo anche Nori A3 e Microduck.

Mi interessano non tanto come gadget quanto come segnale di dove potrebbe andare la robotica personale: piccoli robot relativamente accessibili sui quali far girare software proprio e, soprattutto nel caso di progetti aperti, sperimentare senza dipendere completamente dal cloud del produttore.

Nori mi aveva già dato l'impressione di essere qualcosa di concretamente utilizzabile; Microduck mi interessa soprattutto per l'approccio open source. Per ora, però, li considero osservazioni ed esperimenti, non prodotti sui quali abbia tratto conclusioni definitive.

Una settimana un po' diversa

Alla fine il cambiamento più interessante della settimana non è quindi il kernel 7.3, zram o un nuovo repository.

È il modo in cui sto cominciando a mettere insieme tutti questi pezzi.

Per anni ho usato programmi. Poi ho iniziato a scrivere programmi che usavano API e modelli AI. Adesso sto iniziando a usare l'AI come uno strato sopra ai programmi che utilizzo già.

Forse è questa la parte più interessante degli agenti: quando funzionano bene, dopo un po' si smette quasi di pensare all'intelligenza artificiale e si comincia semplicemente a chiederle di fare qualcosa.

Ed è probabilmente proprio lì che volevo arrivare.

Navetta elettrica futuristica con pannelli solari

 


Da qualche tempo sto ragionando su come potrebbe essere un quadriciclo L7e a quattro posti progettato davvero da zero, senza partire dall'idea di ridurre semplicemente un'automobile tradizionale.

Questa volta ho provato a spingere il concetto molto più avanti.

L'idea di base è un veicolo lungo circa 3,70 metri, largo 1,50 e alto circa 1,70, con quattro posti veri ma una struttura estremamente semplice. La parte anteriore e quella posteriore dovrebbero essere quasi identiche, sia dal punto di vista estetico sia da quello costruttivo.

L'immagine che accompagna questo articolo rappresenta una prima interpretazione del concetto.

Ruote grandi, strette e dentro la carrozzeria

Una delle caratteristiche principali sarebbero le ruote.

Le vorrei di diametro piuttosto grande, ma molto strette, completamente comprese nella larghezza della carrozzeria. Non quindi ruote sporgenti da quadriciclo o da buggy, ma veri passaruota integrati nella scocca.

Una ruota grande permette di affrontare meglio buche e irregolarità della strada e, usando pneumatici relativamente stretti, si potrebbero contenere sia la resistenza al rotolamento sia quella aerodinamica.

Ai quattro angoli ci sarebbero altrettanti motori elettrici integrati direttamente nelle ruote.

Questo eliminerebbe quasi completamente la trasmissione tradizionale: niente differenziale, semiassi, albero di trasmissione o motore centrale.

Il pianale potrebbe quindi rimanere praticamente libero.

Una sospensione che funziona come una bilancia

La parte forse più particolare del progetto riguarda le sospensioni.

L'idea è quella di collegare longitudinalmente la sospensione anteriore e quella posteriore di ciascun lato.

Quando una ruota sale, il movimento viene trasferito almeno in parte all'altra estremità.

Il veicolo dovrebbe quindi comportarsi in qualche modo come se fosse appoggiato sopra una grande bilancia.

Non vorrei utilizzare ammortizzatori tradizionali montati verticalmente accanto alle ruote.

Preferirei invece inserire due giunti viscosi direttamente negli attacchi dei bracci delle sospensioni.

Il giunto viscoso opporrebbe una resistenza progressiva alla velocità del movimento, lasciando invece relativamente libero il movimento lento della sospensione.

In teoria questo permetterebbe di ottenere un veicolo morbido sulle irregolarità, ma allo stesso tempo controllato nei movimenti rapidi.

È probabilmente la parte che richiederebbe più sperimentazione su un vero prototipo.

Il baricentro sotto il centro delle ruote

La batteria sarebbe posizionata nel punto più basso possibile del pianale.

Con ruote di grande diametro dovrebbe essere possibile portare il baricentro dell'intero veicolo molto vicino, o addirittura sotto, all'altezza dei mozzi.

Questo potrebbe dare una notevole stabilità anche utilizzando sospensioni relativamente morbide.

La forma alta del veicolo quindi non dovrebbe necessariamente significare un comportamento instabile.

Gran parte della massa sarebbe infatti concentrata molto in basso.

Quattro posti concentrati al centro

Le ruote sarebbero praticamente agli estremi della carrozzeria.

Gli occupanti, invece, starebbero il più possibile al centro.

I due sedili anteriori sarebbero leggermente arretrati rispetto alle ruote anteriori, mentre quelli posteriori sarebbero avanzati rispetto all'asse posteriore.

Questo permetterebbe di concentrare tutti i passeggeri nella zona più confortevole del veicolo e di lasciare alle estremità lo spazio necessario alle sospensioni.

I quattro sedili sarebbero individuali, molto semplici e soprattutto facilmente smontabili.

Mi piacerebbe anche poterli ruotare.

A veicolo fermo i quattro sedili potrebbero quindi essere rivolti uno verso l'altro, trasformando l'abitacolo in una piccola stanza.

Togliendoli completamente il quadriciclo diventerebbe invece una specie di piccolo furgone.

Quattro porte laterali

Rispetto alla prima idea ho scelto una soluzione più tradizionale per l'accesso: quattro porte laterali scorrevoli, due per lato.

La struttura però dovrebbe comunque evitare il classico grande montante centrale.

I principali elementi portanti verticali sarebbero invece in corrispondenza degli attacchi delle sospensioni anteriori e posteriori.

La struttura inferiore contenente la batteria e quella superiore del tetto dovrebbero contribuire fortemente alla rigidità torsionale.

Questo consentirebbe aperture laterali molto ampie e renderebbe particolarmente facile salire a bordo.

Steer-by-wire e quasi nessun pedale

Un'altra scelta radicale sarebbe eliminare il collegamento meccanico fra volante e ruote.

Lo sterzo sarebbe completamente steer-by-wire.

Il volante potrebbe quindi diventare un vero centro di comando.

Acceleratore, selezione della marcia, indicatori di direzione, luci e buona parte delle altre funzioni potrebbero essere controllati direttamente dal volante.

Rimarrebbe però un comando meccanico estremamente semplice: un pedale del freno.

Lo considero utile indipendentemente dalle possibilità offerte dall'elettronica.

Potrebbe essere collegato a un circuito frenante di emergenza e, a veicolo fermo, svolgere anche la funzione di comando del freno di stazionamento.

In condizioni normali gran parte della frenata potrebbe comunque essere effettuata dai quattro motori elettrici tramite recupero di energia.

Un tetto che diventa una piccola centrale solare

Il tetto sarebbe quasi completamente fotovoltaico.

Ma non mi fermerei al normale pannello solare montato sopra l'auto.

Immagino dei pannelli flessibili o molto sottili capaci di estendersi lateralmente quando il veicolo è parcheggiato.

In movimento rimarrebbero ripiegati sul tetto.

Una volta parcheggiata l'auto, potrebbero invece aprirsi formando una superficie fotovoltaica molto più grande.

Non penso naturalmente a un'automobile capace di funzionare esclusivamente con il sole.

Ma un quadriciclo leggero, efficiente e utilizzato soprattutto per brevi percorsi potrebbe recuperare durante una giornata di parcheggio una quantità di energia tutt'altro che trascurabile.

Inoltre i pannelli aperti funzionerebbero anche come parasole.

Un'auto che cerca di essere semplice

La parte che mi interessa maggiormente del progetto non è però una singola soluzione tecnica.

È l'idea di eliminare componenti.

Quattro motori nelle ruote eliminano buona parte della trasmissione.

Lo steer-by-wire elimina il piantone dello sterzo.

Le sospensioni interconnesse permettono di ripensare completamente molle e ammortizzatori.

I sedili removibili eliminano la distinzione rigida fra automobile e piccolo veicolo da trasporto.

Il pianale diventa quasi completamente piatto.

In pratica rimangono una struttura, quattro ruote, quattro motori, una batteria e quattro sedili.

È esattamente il contrario della tendenza attuale a costruire automobili sempre più grandi, pesanti e complesse.

Probabilmente non assomiglierebbe a un'automobile

Ed è forse proprio questo l'aspetto che trovo più interessante.

Se si decide veramente di sfruttare i vantaggi della propulsione elettrica, non c'è una ragione tecnica per continuare a costruire automobili con le proporzioni che derivano dal motore a combustione, dal cambio, dal differenziale e dal piantone dello sterzo.

Questo quadriciclo avrebbe quindi una forma quasi simmetrica, ruote grandi agli angoli, pochissimo sbalzo e una grande cellula centrale destinata alle persone.

Bianco, semplice, con grandi superfici vetrate e con il tetto fotovoltaico.

Non so se un veicolo del genere verrà mai costruito.

Ma sarebbe interessante almeno arrivare a un modello CAD e, prima o poi, a un piccolo prototipo funzionante.

Perché forse il modo migliore per progettare una piccola auto elettrica non è togliere pezzi da un'automobile tradizionale.

È cominciare da un foglio completamente bianco.

2026-10-01

Una settimana di automazioni: FreeLLMAPI, Tech News e GitHub Pages

 


Questa settimana il filo conduttore è stato abbastanza evidente: automatizzare ciò che ormai faccio tutti i giorni con l'AI, cercando però di mantenere gli strumenti semplici e sotto il mio controllo.

Su GitHub l'attività più consistente si è concentrata su tre progetti: fl-codex, menuAI e soprattutto il nuovo tech-news.

fl-codex: Codex passa da FreeLLMAPI

Il 28 settembre è nato fl-codex, un piccolo launcher Bash che permette di utilizzare Codex CLI passando attraverso un server locale FreeLLMAPI.

L'idea è coerente con gli esperimenti che sto facendo da tempo con freellmApi e za.py: avere un livello intermedio che mi consenta di scegliere modelli e provider senza legare ogni strumento a un singolo servizio.

fl-codex imposta temporaneamente la configurazione necessaria, usa per default FreeLLMAPI su 127.0.0.1:3001/v1, può conservare la chiave nel keyring di Linux e lascia passare gli altri argomenti direttamente a Codex. Il repository comprende già documentazione, test e un AGENTS.md.

È un programmino minuscolo, ma rappresenta bene la direzione che mi interessa: gli agenti devono essere intercambiabili e l'infrastruttura deve rimanere mia.

menuAI diventa un po' più pratico

Il 29 settembre ho ripreso anche menuAI.

Il commit della settimana aggiunge la modalità applicazione e nuovi launcher AI. Anche qui niente di gigantesco: è uno di quei piccoli strumenti che nascono perché mi servono personalmente e che poi finiscono su GitHub perché potrebbero essere utili anche a qualcun altro.

Tech News Daily: dal recap delle sei a un sito vero

Il lavoro più grosso della settimana è però tech-news.

Da tempo alle sei del mattino mi faccio preparare un recap delle notizie che mi interessano: AI, Linux, open source, nuovi programmi e sviluppo software. A un certo punto la domanda è diventata inevitabile: perché non pubblicarlo automaticamente?

È nato così Tech News Daily.

Negli ultimi giorni il repository ha ricevuto diversi aggiornamenti con le edizioni giornaliere e il relativo archivio. Il 30 settembre e il 1° ottobre ho lavorato parecchio anche sulla pipeline di pubblicazione.

La parte apparentemente semplice — creare l'HTML del giorno, conservarlo nell'archivio e trasformarlo nella home corrente — si è rivelata più interessante del previsto.

Il connettore GitHub ha infatti bloccato in alcuni casi la scrittura diretta di docs/index.html per i suoi controlli di sicurezza. Il risultato paradossale era avere l'edizione correttamente salvata nell'archivio ma la home ancora ferma al giorno precedente.

L'ultima modifica del 1° ottobre cambia quindi strategia: GitHub Actions prende l'ultimo archivio e lo promuove direttamente a home durante il deploy, senza dover fare un nuovo git push di index.html.

Mi sembra anche una soluzione architetturalmente più pulita: ChatGPT produce il contenuto editoriale, il repository conserva le edizioni e GitHub Pages si occupa della pubblicazione.

Pubblicare direttamente da ChatGPT?

Gli intoppi con GitHub Actions mi hanno portato anche a ragionare su un passo successivo.

Se ChatGPT è già quello che ogni mattina prepara il recap, forse ha poco senso costruire una catena sempre più complicata soltanto per portare quelle informazioni sul sito.

Sto quindi esplorando la possibilità di affidargli direttamente recap e pubblicazione delle sei del mattino.

È uno di quei casi in cui l'automazione comincia quasi per gioco e poi diventa un piccolo sistema editoriale.

RepoRoulette continua

Rimane attivo anche l'altro esperimento nato nelle settimane precedenti: RepoRoulette, la mia specie di Chatroulette dei repository GitHub.

RepoRoulette

L'idea continua a piacermi: invece di vedere sempre i repository più popolari, pescarne casualmente anche di completamente sconosciuti e dare a ciascuno qualche secondo di attenzione.

Dopo i primi esperimenti con cento repository ho ridotto il ritmo: 30 progetti alla volta, tre volte al giorno, alle 7, alle 14 e alle 21. Cento tutti insieme erano semplicemente troppi e finivo per non guardarli davvero.

Telegram ed Hermes

Un'altra conseguenza del recap quotidiano è stata la voglia di riceverlo anche sul mio canale Telegram preferitiAI.

Ho cercato una soluzione che permettesse a ChatGPT di inviarlo direttamente. Ho provato anche un plugin, ma l'ho eliminato perché mi sembrava troppo invasivo.

Per il momento quindi continuo manualmente, mentre Hermes gira sul Raspberry Pi rakgateway ed è collegato a Telegram.

Lo stesso Raspberry, dopo la chiusura definitiva di LoRa-One e la rimozione della scheda LoRa, continua anche a funzionare come nodo Tor che ospita il sito dei Cantinari.

Alla fine la vecchia macchina continua a essere parecchio utile, semplicemente facendo mestieri diversi da quelli per cui l'avevo preparata inizialmente.

AI divide: una riflessione meno tecnica

Questa settimana ho scritto anche una riflessione che va oltre i miei soliti esperimenti.

Sto osservando la corsa dei grandi laboratori americani verso modelli sempre più costosi da sviluppare e utilizzare e mi chiedo dove possa portare economicamente.

La mia preoccupazione è la nascita di un vero AI divide: strumenti estremamente potenti, ma progressivamente accessibili soprattutto a chi può permetterseli.

È una previsione personale, naturalmente, non un fatto acquisito. Ma è anche uno dei motivi per cui continuo a interessarmi a DeepSeek, modelli locali, GGUF, FreeLLMAPI e piccoli agenti: vorrei che almeno una parte di questa tecnologia rimanesse utilizzabile senza dover dipendere necessariamente dalle piattaforme più costose.

E i progetti precedenti?

Questa settimana ai-bar, Nori A3 e Microduck non hanno avuto novità sufficienti da meritare un aggiornamento artificiale.

ai-bar rimane impostato secondo il modello che ho scelto: main generico, branch personale e AGENTS.md per spiegare agli agenti come intervenire senza confondere le due cose. È un metodo che, come dimostra anche il nuovo fl-codex, sto iniziando a riutilizzare.

Nori A3 e Microduck restano invece nel mio radar per la robotica personale, ma preferisco tornarci quando ci sarà qualcosa di concreto da aggiungere.

Meno esperimenti isolati, più pezzi che si collegano

Guardando la settimana nel suo complesso, la cosa interessante non è tanto il numero dei commit.

RepoRoulette scopre progetti. Il recap quotidiano seleziona notizie. Tech News Daily prova a pubblicarle. Hermes collega il Raspberry a Telegram. FreeLLMAPI diventa un livello comune per gli agenti e fl-codex porta dentro anche Codex.

Sono ancora tutti piccoli esperimenti.

Ma stanno cominciando a parlarsi tra loro.

2026-09-30

L'intelligenza artificiale sta diventando un privilegio per ricchi?

 



Più osservo quello che sta succedendo nel mondo dell'intelligenza artificiale, più mi convinco che siamo nel mezzo di una gigantesca operazione economica e industriale, le cui conseguenze potrebbero essere molto diverse da quelle che ci vengono raccontate.

Ho maturato una convinzione: le grandi aziende americane dell'AI, in particolare OpenAI e Anthropic, stanno sostenendo uno sforzo straordinario per conquistare un vantaggio tecnologico significativo sulla concorrenza cinese.

Non so se questa sia una strategia deliberata e coordinata, ma osservando la velocità con cui vengono presentati nuovi modelli, la potenza di calcolo impiegata e le enormi risorse investite, la sensazione è proprio questa.

Il problema è che una corsa del genere costa cifre spaventose. E difficilmente potrà continuare indefinitamente.

Una corsa che brucia capitali

Le cifre cominciano a essere impressionanti.

Secondo quanto riportato da Reuters, Anthropic ha registrato nel 2025 una perdita operativa superiore a 8 miliardi di dollari e ha assunto impegni infrastrutturali futuri per centinaia di miliardi. Le perdite nette sono ancora più elevate, anche se comprendono importanti componenti contabili che non rappresentano uscite immediate di denaro.

Anche OpenAI continua a cercare finanziamenti enormi.

Non stiamo parlando di qualche startup che cerca di raggiungere il pareggio di bilancio. Stiamo parlando di un'industria che richiede investimenti di dimensioni difficili persino da immaginare.

E allora mi pongo una domanda: qual è il vero obiettivo economico di questa accelerazione?

La mia ipotesi è che la quotazione in Borsa rappresenti un passaggio fondamentale. Non necessariamente per estinguere direttamente debiti, ma per ottenere nuovi capitali, valorizzare investimenti già effettuati e trasferire una parte crescente del rischio sui mercati finanziari.

La futura quotazione di queste aziende potrebbe essere il momento nel quale dovranno dimostrare che le valutazioni astronomiche attribuite loro hanno un fondamento economico.

E sarà allora che, temo, molte cose cambieranno.

La fine dell'illusione delle tariffe flat

Oggi possiamo utilizzare strumenti straordinariamente potenti pagando abbonamenti relativamente accessibili.

Ma quanto durerà?

Già adesso le cosiddette tariffe flat sono spesso tali soltanto nel nome. Esistono limiti di utilizzo, quote temporali, priorità differenti e restrizioni sulle funzionalità più costose.

La strada verso una segmentazione sempre più marcata dell'offerta è già visibile.

La mia previsione è che, quando queste aziende saranno costrette a dimostrare una redditività sostenibile, assisteremo a un aumento significativo dei prezzi e a un progressivo ridimensionamento degli abbonamenti a consumo apparentemente illimitato.

L'accesso ai modelli migliori potrebbe diventare un servizio riservato a chi può permettersi di pagare cifre importanti.

E non parlo soltanto di qualche funzionalità aggiuntiva.

Parlo dell'accesso a strumenti capaci di programmare, progettare, fare ricerca, automatizzare attività e moltiplicare enormemente la produttività individuale.

Il problema dell'hardware

C'è poi un altro elemento che mi preoccupa.

A fronte di miglioramenti tecnologici impressionanti, continua a mancare una soluzione hardware realmente economica, accessibile e sufficientemente potente per eseguire localmente i modelli più avanzati.

Naturalmente esistono modelli aperti, sistemi quantizzati e soluzioni che funzionano anche su hardware relativamente modesto. Io stesso considero questa strada fondamentale.

Ma il divario tra ciò che si può eseguire a casa e ciò che richiede enormi infrastrutture rimane considerevole.

Questo significa che, almeno per il momento, chi vuole utilizzare le capacità più avanzate dell'AI deve quasi necessariamente dipendere dai grandi fornitori di servizi.

E la dipendenza tecnologica diventa inevitabilmente anche una dipendenza economica.

Il vero pericolo: l'AI divide

Arriviamo così al punto che considero più inquietante.

Da anni parliamo di digital divide, la separazione tra chi dispone degli strumenti digitali e chi ne rimane escluso.

Ma quello che rischiamo di vedere con l'intelligenza artificiale è qualcosa di molto più profondo.

Un AI divide, una frattura tra chi potrà permettersi di aumentare enormemente le proprie capacità intellettuali e produttive attraverso l'intelligenza artificiale e chi dovrà continuare a competere contando soltanto sulle proprie risorse.

Non sarebbe semplicemente una questione di maggiore comodità.

Chi dispone degli strumenti migliori potrebbe imparare più velocemente, lavorare meglio, costruire imprese, sviluppare prodotti e accumulare ulteriore ricchezza.

Chi ne rimane escluso rischierebbe invece di perdere progressivamente competitività, reddito e autonomia.

E qui si potrebbe innescare un meccanismo terribile: chi è ricco diventa sempre più ricco perché dispone dell'intelligenza artificiale migliore; chi è povero diventa sempre più povero proprio perché non può permettersela.

Un circolo vizioso dal quale potrebbe essere estremamente difficile uscire.

Il futuro meraviglioso raccontato da Elon Musk

Elon Musk parla spesso di un futuro caratterizzato da abbondanza, robot capaci di produrre praticamente qualsiasi cosa e perfino redditi elevati garantiti a tutti grazie all'intelligenza artificiale.

È una visione affascinante.

Ma ogni volta che ascolto queste previsioni mi viene spontanea una domanda.

Tutti, esattamente chi?

Chi possiederà i robot? Chi controllerà i modelli? Chi avrà la proprietà delle infrastrutture e dell'energia necessaria per farle funzionare?

Soprattutto, chi deciderà come distribuire la ricchezza prodotta da queste macchine?

Perché l'aumento della ricchezza complessiva non implica automaticamente una distribuzione equa.

Potremmo ritrovarci in un mondo enormemente più produttivo, ma nel quale i benefici di questa produttività finiscano concentrati nelle mani di una minoranza.

E allora il futuro di prosperità annunciato da Musk potrebbe rivelarsi una realtà soltanto per chi è riuscito a conquistare una posizione privilegiata prima che il sistema si consolidasse.

Per tutti gli altri, il treno potrebbe essere già partito.

E chi resta fuori?

Questa è la parte più cupa del mio ragionamento.

Immagino una società nella quale una minoranza dispone di strumenti tecnologici straordinari, vive in condizioni di benessere crescente e controlla sistemi produttivi sempre più automatizzati.

E una maggioranza che rischia di diventare progressivamente meno necessaria dal punto di vista economico.

Non perché le persone non abbiano valore, ma perché il sistema potrebbe non avere più bisogno del loro lavoro.

In una società incapace di distribuire la ricchezza generata dall'automazione, l'esclusione potrebbe trasformarsi in povertà permanente, marginalità e disperazione.

Quando penso al fentanyl e alle devastazioni sociali provocate dalla crisi degli oppioidi, vedo anche il simbolo estremo di ciò che può accadere quando intere comunità perdono prospettive e speranza.

Non sostengo che questo sia un destino inevitabile. Ma temo un futuro in cui a una parte della popolazione vengano offerte tecnologie miracolose e a un'altra rimangano soltanto gli strumenti per sopportare l'esclusione.

Dove passerà il confine?

Forse questa è la domanda più importante di tutte.

Non sappiamo ancora dove sarà tracciata la linea di separazione.

Tra chi guadagna mille euro al mese e chi ne guadagna cinquemila? Tra chi possiede un'azienda e chi lavora come dipendente? Tra chi vive nei paesi industrializzati e chi vive nel resto del mondo?

Oppure il confine sarà molto più in alto, lasciando dalla parte dei privilegiati soltanto una percentuale minuscola della popolazione mondiale?

Non possiamo ancora saperlo.

Esistono anche possibilità diverse: modelli aperti sempre più efficienti, hardware meno costoso, iniziative pubbliche e nuove forme di distribuzione della ricchezza potrebbero evitare questo scenario.

Ma non credo che accadrà automaticamente.

Continuo a considerare l'intelligenza artificiale una delle più straordinarie conquiste tecnologiche della storia umana. Proprio per questo mi preoccupa tanto l'idea che possa trasformarsi nel più potente strumento di concentrazione della ricchezza mai realizzato.

Il mio timore non è che le macchine diventino più intelligenti degli esseri umani.

È che pochi esseri umani, grazie alle macchine, diventino talmente più potenti degli altri da rendere impossibile recuperare il distacco.

E quando questo accadrà, se accadrà, potrebbe non esserci più nessun treno sul quale salire.

2026-09-25

RepoRoulette, compatibilità Linux e piccoli problemi che diventano progetti

 

Questa settimana l’attività pubblica su GitHub è stata piuttosto tranquilla: nel controllo dei repository di vroby65 non emergono nuovi commit, release, issue o pull request significativi tra il 18 e il 24 settembre. Il lavoro però non è mancato: una parte consistente si è spostata sugli esperimenti, sui servizi web e sui problemi quotidiani che inevitabilmente saltano fuori usando Linux e AI tutti i giorni.

RepoRoulette: una Chatroulette per GitHub

La cosa che mi è piaciuta di più questa settimana è RepoRoulette.

L’idea è nata da una constatazione molto semplice: su GitHub esistono milioni di repository, ma finiamo quasi sempre per vedere quelli già famosi, quelli con molte stelle o quelli che qualche algoritmo ha deciso di mostrarci.

E tutti gli altri?

Ho quindi lavorato a un sito che prova a fare esattamente il contrario: pescare repository pubblici a caso, escludendo soltanto fork e repository vuoti, e presentarli uno dopo l’altro con un meccanismo che ricorda Chatroulette.

All’inizio avevo pensato a una rassegna di 100 repository ogni mattina. Mi sono accorto quasi subito che erano troppi: dopo un po’ si perde concentrazione. Ho quindi ridotto il formato a 30 progetti per volta, tre volte al giorno.

Il sito è qui:

RepoRoulette

La cosa che mi interessa non è trovare necessariamente il “progetto migliore”. È dare per qualche secondo visibilità anche a un repository con zero stelle che altrimenti probabilmente non avrei mai incontrato.

ChatGPT su Linux e il solito problema delle librerie

Un altro esperimento della settimana è stato molto più terra-terra.

Ho provato l’app desktop Linux di ChatGPT, ma su Linux Mint il pacchetto .deb non si installa perché è stato costruito contro una versione di libc più recente di quella disponibile sulla mia Mint.

Da qui una domanda che prima o poi capita a chi usa Linux abbastanza a lungo: posso avere più versioni di libc sulla stessa macchina senza distruggere tutto?

La risposta pratica è che sostituire la glibc di sistema per far funzionare una singola applicazione non è una buona strada. Molto più sensato isolare l’applicazione con un ambiente che contenga le librerie richieste. È uno di quei casi in cui container e ambienti separati non servono per costruire enormi infrastrutture cloud, ma semplicemente per far partire un programma sul proprio desktop.

DeepSeek: relay gratuiti e rischio ban

Ho continuato anche a seguire gli strumenti che ruotano attorno a DeepSeek. Questa settimana ho riguardato in particolare deepseek-free-relay, soprattutto per capire se ci fossero novità e quanto sia concreto il rischio di ban usando soluzioni che fanno da relay verso servizi gratuiti.

Rimane valido il principio che sto cercando di seguire da tempo: distinguere gli esperimenti divertenti dagli strumenti sui quali posso realmente fare affidamento. Per za.py, freellmApi e gli altri piccoli agenti che devono operare sul sistema, un’API stabile e prevedibile vale spesso più di qualche chiamata gratuita ottenuta attraverso un meccanismo fragile.

In parallelo sto anche osservando meglio i costi degli strumenti OpenAI: questa settimana mi sono accorto che l’uso di Work può incidere sulle quote che poi ritrovo disponibili in Codex. È un dettaglio importante quando gli agenti iniziano a diventare strumenti quotidiani anziché semplici esperimenti.

AI Bar: l'idea rimane quella giusta

Questa settimana non ci sono modifiche pubbliche significative a AI Bar su GitHub, ma non è cambiata l’idea di fondo.

Voglio mantenere main come base generica, un branch personale per il mio ambiente e AGENTS.md come istruzioni per permettere agli agenti di lavorare sul progetto senza perdere questa separazione.

È un modello che continua a convincermi: software generico alla base, software personale sopra, con gli agenti che possono occuparsi di una parte crescente dell’adattamento.

Lo stesso ragionamento rimane dietro za.py e freellmApi: non mi interessa soltanto parlare con un modello, mi interessa che un piccolo agente possa fare concretamente qualcosa sul sistema operativo.

n8n resta sul tavolo

Avevo anche deciso di dedicare un pomeriggio a n8n. Non lo considero ancora una scelta di progetto: per ora è qualcosa che sto valutando per capire quanto possa essere utile nell’automazione dei piccoli flussi che oggi gestisco con script, agenti e servizi separati.

Meglio quindi non raccontare conclusioni che ancora non ci sono.

Il Raspberry che ha cambiato mestiere

Vale la pena lasciare scritto anche il riassetto di rakgateway.

Ho chiuso definitivamente LoRa-One e rimosso la scheda LoRa dal Raspberry Pi. La macchina continua però a essere utilizzata: adesso svolge due compiti ben definiti.

È il nodo Tor che ospita il sito dei Cantinari ed è anche il server Hermes collegato a Telegram.

È una semplificazione che mi piace: eliminare una funzione che non uso più senza buttare via una macchina che può continuare tranquillamente a essere utile.

Robot domestici: Nori e Microduck

Continuo a osservare anche Nori A3 e Microduck, ma questa settimana non ho elementi nuovi abbastanza importanti da giustificare aggiornamenti rispetto a quanto avevo già scritto.

Per Nori A3 rimane fondamentale distinguere le capacità dichiarate e mostrate dal produttore dalla mia impressione personale: a me sembra uno dei primi robot di questa fascia che cominciano ad avvicinarsi a qualcosa di concretamente utile, ma sarà l’utilizzo reale a dire quanto quella sensazione sia fondata.

Microduck continua invece a interessarmi per il prezzo accessibile e per la componente software open source. La mia idea che un prodotto del genere possa favorire la nascita di derivati e cloni resta una previsione personale, non un fatto già avvenuto.

Meno commit non significa una settimana vuota

Questa è stata insomma una di quelle settimane nelle quali il contatore dei commit racconta poco.

RepoRoulette è probabilmente l’esperimento più visibile, ma dietro ci sono anche una libc troppo nuova, qualche conto sulle quote degli agenti, DeepSeek da tenere sotto osservazione e un Raspberry che ha definitivamente abbandonato LoRa.

Nel frattempo continuo anche con l’attività fisica iniziata nelle settimane scorse. Mi porta via parecchio tempo al mattino e rimettermi in forma continua a essere faticoso, ma ormai fa parte della nuova organizzazione delle giornate.

Quindi pochi commit, questa volta. Ma decisamente non poco da fare.

 

2026-09-17

Una settimana con pochi commit, ma parecchie cose da sistemare

 
Questa settimana GitHub è rimasto piuttosto tranquillo. Nei progetti principali non ho fatto nuovi commit e, considerando quante cose ho continuato a provare e sistemare, è quasi una notizia.

Non tutte le settimane di lavoro davanti al computer finiscono infatti con del codice pubblicato. A volte servono soprattutto a capire meglio cosa tenere, cosa abbandonare e dove vale ancora la pena perdere — o investire — del tempo.

Linux Mint, XanMod e il tentativo Cachyfy

Ho continuato a lavorare sul mio PC principale, ormai passato a Linux Mint 22.3 “Zena”, e a ragionare sugli esperimenti fatti con `mint-cachyfy`.

L'idea era cercare di ottenere su Mint una parte dei vantaggi prestazionali di CachyOS, mantenendo però il sistema che uso abitualmente. I risultati dei benchmark non sono stati miracolosi: Speedometer 3.1 era circa 15,4 prima degli esperimenti, è sceso a 15,0 con alcune ottimizzazioni ed è tornato intorno a 15,4 con XanMod.

La cosa curiosa è che, numeri alla mano, non sembra essere cambiato quasi niente. Nell'uso quotidiano, però, il sistema con XanMod continua a sembrarmi più reattivo.

E ancora una volta mi ricorda che un benchmark racconta qualcosa, ma non necessariamente tutto.

Rimane inoltre irrisolto il tentativo di ricompilare Firefox: la compilazione si ferma su `gkrust`. Prima o poi ci tornerò.
 

AI Bar: meno modifiche, ma l'idea rimane

Questa settimana non ci sono nuovi commit su [AI Bar](https://github.com/vroby65/ai-bar), ma rimane uno dei progetti su cui sto ragionando di più.

La struttura che ho scelto mi convince sempre di più: un branch `main` abbastanza generico, un branch personale con le mie modifiche e `AGENTS.md` che spiega agli agenti come intervenire senza distruggere questa separazione.

È un sistema che probabilmente riutilizzerò anche altrove.

Un programma open source può avere una base comune, mentre la versione realmente utilizzata da una persona può diventare molto più personale. Con gli agenti AI questa separazione diventa particolarmente interessante, perché una parte delle personalizzazioni può essere fatta direttamente dall'agente seguendo istruzioni precise.

Continuano anche gli esperimenti attorno a `freellmApi` e `za.py`: invece di usare un LLM soltanto per conversare, l'obiettivo rimane avere piccoli agenti capaci di effettuare realmente operazioni sul sistema operativo.
 

DeepSeek cambia ancora

Sul fronte AI la novità della settimana è stata soprattutto DeepSeek V4.1 Flash.

Sto cercando di capire cosa cambia concretamente rispetto a V4 Flash e, soprattutto, cosa comporta per i miei strumenti da riga di comando, `za.py` e `freellmApi`.

È esattamente il problema che comincia a presentarsi usando questi servizi come componenti dei propri programmi: non basta più chiedersi quale sia il modello migliore. Diventano importanti compatibilità delle API, prezzi, routing dei modelli e possibilità di sostituire un modello senza dover riscrivere tutto il software.

Ed è anche uno dei motivi per cui continuo a preferire programmi piccoli e interfacce semplici.

Addio LoRa-One

Questa settimana ho anche deciso di chiudere definitivamente il nodo **LoRa-One**.

Ho rimosso fisicamente la scheda LoRa dal Raspberry Pi `rakgateway`. Era un progetto interessante, ma a un certo punto bisogna anche accettare che non tutto deve rimanere acceso per sempre.

Il Raspberry, comunque, non va in pensione.

`rakgateway` continua a lavorare come nodo Tor, attraverso il quale viene ospitato il sito dei Cantinari, e come server di Hermes, collegato a Telegram.

Meno funzioni, quindi, ma quelle che effettivamente mi servono.

2026-09-10

Una settimana tra compilazioni, agenti e un po' di vita reale

 


Questa settimana il tempo dedicato ai progetti è stato un po' meno del solito, anche perché ho deciso di riprendere seriamente l'attività fisica. Però qualche cosa interessante è comunque successa, e ancora una volta il filo conduttore rimane Linux, piccoli strumenti personali e AI.

Mint Cachyfy: spremere ancora un po' il PC

Il progetto nuovo della settimana è mint-cachyfy.

L'idea è abbastanza semplice: provare a portare su Linux Mint una parte della filosofia di CachyOS, ricompilando alcuni programmi importanti ottimizzati specificamente per la macchina su cui devono girare.

Il repository è nato il 9 settembre e nello stesso giorno ho già aggiunto una gestione più prudente della memoria durante la compilazione e un menu per scegliere cosa compilare. Il motivo della prudenza l'ho scoperto abbastanza rapidamente: il tentativo di compilare Firefox con ottimizzazioni spinte è arrivato fino a gkrust per poi fallire durante la compilazione Rust. Quindi il progetto è ancora decisamente sperimentale, ma proprio per questo è interessante.

AI Bar continua a cambiare

Su AI Bar questa settimana ho lavorato soprattutto sulla possibilità di staccare le finestre grafiche incorporate nella barra e ho eliminato il vecchio launcher a menu. Il 4 settembre ho poi effettuato il merge del branch personale vroby.

Questa separazione tra main e vroby sta diventando sempre più importante per come penso il progetto. main dovrebbe rimanere una base abbastanza generica, mentre il branch personale contiene ciò che serve specificamente a me. AGENTS.md spiega invece agli agenti come modificare e personalizzare il programma senza perdere questa distinzione.

Sto cercando anche di eliminare un'altra piccola seccatura tipica degli agenti: dover continuamente spiegare in quale directory devono lavorare. L'idea è permettere ad AI Bar di ricavare automaticamente il percorso dal terminale o dal file manager attivo.

Zepto Agent impara anche dalla fiducia

È proseguito anche Zepto Agent. Il 7 settembre ho aggiunto la visualizzazione del rating delle proposte e la possibilità di saltare la conferma dopo dieci esecuzioni riuscite dello stesso tipo.

È un dettaglio che però mi interessa parecchio: un agente di sistema non dovrebbe chiedermi eternamente il permesso per fare una cosa che gli ho già autorizzato dieci volte e che ha sempre eseguito correttamente.

È la stessa direzione in cui sto sperimentando con za.py e freellmApi: agenti piccoli, possibilmente economici, che non si limitino a parlare ma possano realmente operare sul sistema.

Un contributo a Codex Security

Questa settimana c'è stata anche un'attività fuori dai miei repository: ho aperto la pull request #823 su Codex Security.

Il lavoro riguarda la sostituzione di extract-zip, coinvolto in vulnerabilità segnalate dalle dipendenze, con yauzl aggiornato, mantenendo i controlli di sicurezza sull'estrazione degli archivi e aggiungendo test specifici. È una PR piuttosto più sostanziosa dei miei soliti piccoli programmi.

Agenti che iniziano ad avere un ambiente

Un'altra cosa che ho guardato questa settimana è Gentle-AI. L'idea mi interessa perché cerca di trasformare Codex, Claude Code, OpenCode e altri agenti da semplici generatori di codice in ambienti di sviluppo configurati, con memoria persistente, skill, workflow e istruzioni.

È curioso perché converge abbastanza con quello che sto facendo in piccolo con AGENTS.md, branch personali e programmi pensati fin dall'inizio per essere modificati dagli agenti.

Robot: tengo d'occhio Nori e Microduck

Continuo poi a seguire Nori A3 e Microduck. Non ci sono questa settimana novità tali da cambiare quanto avevo scritto, ma rimangono due progetti che per motivi diversi considero significativi.

Nori A3 mi interessa perché, almeno nelle capacità mostrate e dichiarate dal produttore, comincia ad assomigliare a qualcosa che potrebbe essere realmente utile in casa. Quanto di questo funzionerà davvero fuori dalle dimostrazioni resta naturalmente da verificare.

Microduck mi interessa invece soprattutto per l'approccio economico e per il software open source. Continuo a pensare che una piattaforma robotica sufficientemente economica e aperta possa generare rapidamente derivati e cloni. È una mia previsione, non qualcosa che sia già avvenuto.

Un saluto a Harvey Deklaine

Questa settimana c'è purtroppo anche una notizia che con il software non c'entra nulla.

Ho saputo della morte di Harvey Deklaine. Per noi era la persona che ci aveva fornito le cartucce Intellivision e quindi rimane legato a un pezzo della nostra storia e della nostra passione per quelle vecchie macchine.

La notizia mi ha colpito parecchio e, francamente, sono ancora abbastanza sconvolto e dispiaciuto. Non ho trovato online fonti affidabili che mi permettano di aggiungere dettagli sulla sua vita, quindi preferisco semplicemente ricordarlo per quello che ha rappresentato per noi.

Ciao Harvey.

E infine devo rimettere in moto anche me stesso

Ho deciso di riprendere seriamente l'attività fisica. Mi porta via parecchie ore al mattino, quindi inevitabilmente rimane meno tempo per programmare e giocare con queste cose.

Sto facendo molta più fatica di quanto avrei voluto a rimettermi in sesto e il caldo di questo settembre non aiuta per niente. Però andando avanti con gli anni diventa sempre più evidente che non posso ottimizzare soltanto Linux: devo cercare di rallentare un po' anche il mio inevitabile declino fisico.

Per questa settimana, quindi, qualche commit in meno e qualche chilometro in più. Mi sembra comunque un compromesso accettabile.

2026-09-08

Un’astronave che trasforma il tempo in movimento

 

Stavo ragionando su un’idea di fantascienza semi-plausibile: invece di costruire il solito motore che produce una spinta, perché non immaginare un dispositivo capace di trasformare in qualche modo l’evoluzione nel tempo in movimento nello spazio?

La relatività ci dà già uno spunto interessante. Energia e quantità di moto sono parti dello stesso quadrimpulso e, quando un oggetto si avvicina alla velocità della luce, il suo tempo proprio rallenta rispetto a quello di un osservatore esterno. Da qui l’idea: un ipotetico motore potrebbe modificare direttamente la geometria locale dello spazio-tempo, “inclinando” parte della componente temporale verso quella spaziale.

La nave non verrebbe quindi spinta. Sarebbe lo spazio-tempo intorno a lei a cambiare, mentre nave ed equipaggio continuerebbero a seguire una geodetica. Da fuori si vedrebbe una fortissima accelerazione; dentro, invece, un accelerometro potrebbe continuare a indicare praticamente zero. Anche la struttura non dovrebbe sopportare le accelerazioni mostruose richieste da un normale viaggio relativistico.

A questo punto anche la forma dell’astronave viene quasi da sola: una sfera.

Al centro si trova il motore cronocinetico, che genera una bolla sferica appena più grande dello scafo. La direzione principale di viaggio coincide con il polo nord. All’equatore quattro piccoli gruppi di motori di assetto, simili come concetto agli RCS del modulo lunare, permettono le manovre quando non viene utilizzata la propulsione principale.

Sempre all’equatore, ma dentro la sfera, ruota un grande anello abitabile. Durante le normali operazioni crea gravità centrifuga e può funzionare anche come stabilizzatore della nave. Le zone polari superiore e inferiore sono invece dedicate agli spazioporti per navette e mezzi di servizio.

Rimane naturalmente il problema più grosso: l’energia.

Creare coppie particella-antiparticella dal vuoto e farle annichilire non produrrebbe energia gratis: per crearle dovremmo prima fornire almeno la stessa energia che recupereremmo. Per restare nel campo della fantascienza “semi-plausibile” possiamo però ipotizzare che il motore riesca a stimolare uno stato del vuoto quantistico e a sfruttarne il rilassamento, mentre la produzione e l’annichilazione delle coppie diventano parte del processo di conversione energetica.

Non è fisica che sappiamo fare, naturalmente. Probabilmente non è nemmeno fisica possibile. Ma mi piace perché porta a un’astronave molto diversa da quelle classiche: niente grandi motori posteriori, niente equipaggio schiacciato dall’accelerazione e nessuna vera “prua”.

È, in sostanza, una bolla di spazio-tempo mobile con un’astronave sferica al suo interno.

E, incidentalmente, il risultato ricorda parecchio la Good Hope di Perry Rhodan. Forse quelle vecchie astronavi sferiche non erano poi una scelta estetica così strana.

2026-09-03

Ai-bar

 

Questa settimana il lavoro su GitHub è stato meno dispersivo del solito e si è concentrato soprattutto attorno a un'idea che ormai sta diventando abbastanza chiara: software piccolo, modificabile dagli agenti e personalizzato per chi lo usa.

AI Bar: il software personale sopra una base comune

Su AI Bar ho continuato a lavorare soprattutto sulla separazione tra il progetto generale e la mia configurazione personale. Nell'ultima settimana GitHub registra, tra le altre cose, il merge del branch vroby e una correzione alla selezione della pagina terminale dopo un reload.

La parte che mi interessa di più, però, non è la singola modifica. Sto cercando di usare main come base abbastanza generica da poter essere utilizzata da altri, mentre tengo le mie personalizzazioni in un branch personale. A questo si aggiunge AGENTS.md, che serve a spiegare agli agenti AI come intervenire sul progetto.

Mi sembra un modello interessante: invece di cercare di costruire un programma che vada bene per tutti, mantenere un nucleo comune e lasciare che ciascuno possa costruirci sopra la propria versione, eventualmente facendola modificare direttamente a un agente.

Continuo anche a sperimentare la sessione AI Bar con Weston al posto di Openbox. Per ora però Wayland mi sembra decisamente meno efficiente del vecchio Xorg per questo tipo di ambiente leggero.

Agenti piccoli per fare cose vere

Lo stesso ragionamento continua con za.py, il piccolo agente che sto usando per eseguire operazioni sul sistema operativo attraverso freellmApi.

L'obiettivo non è costruire l'ennesimo chatbot, ma avere un agente che possa realmente fare qualcosa sulla macchina. Modelli piccoli, API economiche o gratuite e programmi molto semplici possono essere più interessanti, almeno per me, di sistemi enormi che cercano di fare tutto.

In questa direzione è nato anche ds-code. Il 2 settembre ho aggiunto README e AGENTS.md e subito dopo li ho tradotti in inglese. Anche qui torna quindi l'idea di scrivere non soltanto documentazione per gli utenti, ma istruzioni destinate direttamente agli agenti che dovranno lavorare sul codice.

Un registratore di macro

Sempre il 2 settembre è nato macro-recorder. Il repository parte con un commit iniziale seguito dalla traduzione del README in inglese.

È un altro esempio della direzione che sto seguendo: invece di cercare programmi complessi, preferisco sempre più spesso costruire piccoli strumenti che fanno esattamente quello che mi serve.

E intanto arrivano i robot economici

Fuori dal software questa settimana mi hanno incuriosito soprattutto due piccoli robot.

Il primo è Nori A3. Costa 1.688 dollari e ha due bracci, LiDAR, quattro telecamere e un'autonomia dichiarata di 6-8 ore. Il produttore lo mostra impegnato in attività come riordinare, prendere oggetti dal frigorifero, caricare i piatti e aiutare in cucina. Le consegne sono indicate per l'autunno 2026. Queste sono però capacità dichiarate da Nori Robotics e non vanno confuse con un robot domestico già autonomo e pronto all'uso.

La mia impressione è comunque che Nori sia uno dei primi robot economici che cominciano almeno a farmi pensare: questo potrebbe davvero servire a qualcosa.

Poi c'è Microduck. È una piccola papera bipede da 25 cm e circa 800 grammi capace, tra le altre cose, di camminare, rialzarsi, afferrare piccoli oggetti e utilizzare delle ruote. Il software è pubblicato con licenza Apache 2.0 e comprende anche il sistema di controllo; il training delle policy avviene nel progetto collegato microduck_rl.

Qui però devo correggere leggermente quello che avevo scritto qualche giorno fa: è open source il software, non l'hardware. Il prezzo di lancio rimane comunque molto interessante, 399 dollari.

Ed è proprio la combinazione fra prezzo basso e software aperto che secondo me può produrre qualcosa di interessante. Non mi stupirebbe vedere presto progetti derivati, alternative compatibili e magari veri cloni. Questa per ora è una mia previsione, ma l'ecosistema ha già iniziato a muoversi: è comparso ad esempio quackd, un progetto indipendente che prova a mettere un LLM sopra le capacità del Microduck.

Il filo comune

A prima vista AI Bar, za.py, ds-code e una papera robot da 399 dollari sembrano cose completamente diverse.

In realtà per me il filo comune sta diventando abbastanza evidente.

Hardware sempre meno costoso, software open source, modelli AI e agenti capaci di modificare il codice rendono sempre più realistico costruire strumenti pensati per una singola persona invece che per milioni di utenti.

Ed è probabilmente questa la cosa che mi interessa di più in questo momento.


2026-08-27

Settimana di piccoli tool, agenti locali e desktop AI

 

Questa settimana ho lavorato soprattutto su piccoli strumenti che servono direttamente al mio modo di usare Linux e i modelli AI. Niente grandi progetti monolitici: diverse utility semplici, ciascuna pensata per risolvere un problema preciso.

AI Bar

Il lavoro più consistente è stato su AI Bar. Ho aggiunto azioni rapide e launcher configurabili, sistemato il pannello perché non esca dallo schermo e migliorato l'avvio della sessione desktop. Ho anche iniziato a documentare esplicitamente il progetto per gli agenti AI con AGENTS.md, prima in italiano e poi in inglese. Le modifiche sono passate attraverso cinque pull request, dalla #12 alla #16.

La cosa interessante è che AI Bar sta lentamente passando dall'essere una semplice barra con strumenti AI a qualcosa di più vicino a un piccolo ambiente desktop costruito intorno agli agenti.

Zepto Agent

Ho continuato anche il lavoro su Zepto Agent, il mio piccolo agente locale per Linux.

Qui il problema principale era ottenere qualcosa di abbastanza affidabile e veloce anche usando un modello piccolo. Ho migliorato la gestione del JSON prodotto dal modello, aggiunto un secondo tentativo automatico quando l'output non è valido e reso più robusta la gestione dei percorsi.

La modifica più importante però è il nuovo backend llama-cpp-python con modello GGUF Q4_K_M. Nei test indicati nel commit la generazione risulta circa 3,5 volte più veloce sulla CPU e il modello occupa circa 1,1 GB invece di 4,5 GB. Transformers rimane comunque disponibile come fallback.

Un menu minimale

È nato anche menu, un piccolo launcher TUI per le applicazioni desktop scritto in Python. Il repository è stato creato il 23 agosto e nei primi commit ho già aggiunto supporto per il mouse, localizzazione, licenza MIT e le istruzioni AGENTS.md per permettere agli agenti AI di modificarlo senza stravolgerne la filosofia.

È esattamente il genere di software che mi interessa in questo periodo: piccolo, comprensibile e facilmente personalizzabile.

OpenRouter, DeepSeek e Codex

Sono nati altri tre repository molto piccoli.

or-codex è un launcher interattivo per scegliere un modello OpenRouter pee usarlo con Codex. È un progetto Shell creato il 26 agosto.

getdscredit serve invece a controllare il credito residuo delle API DeepSeek. È scritto in Python e gestisce anche l'assenza o il rinnovo della chiave API tramite --renew.

Infine getorcredit fa praticamente la stessa cosa per OpenRouter, con gestione della chiave, test, documentazione e licenza MIT.

Una direzione che comincia a vedersi

Guardando insieme questi lavori si vede abbastanza chiaramente dove sto andando: software molto piccolo, soprattutto Linux, costruito per le mie esigenze e sempre più pensato fin dall'inizio per poter essere modificato insieme agli agenti AI.

Non credo che ogni programma debba diventare enorme e universale. Al contrario, con gli agenti diventa sempre più conveniente avere programmi semplici da adattare alla singola persona.

2026-08-26

Ripartire con l’intelligenza artificiale

 

 

Ciao, oggi mi sono reso conto che non aggiorno Vroby Pages da secoli.

Ho deciso quindi di ripartire, questa volta con l’aiuto dell’AI. Da ora in poi, ogni giovedì ChatGPT mi proporrà un post da pubblicare. Io lo leggerò, farò gli aggiustamenti necessari e magari aggiungerò qualche nota personale, ma il grosso del lavoro lo lascerò a lui.

Ormai uso quotidianamente modelli AI e agenti, sia per scrivere codice sia per fare ricerche. Anche il mio modo di sviluppare sta cambiando: cerco di creare software pensato fin dall’inizio per essere modificato e personalizzato. Sul branch main rimane il progetto originale, mentre su un branch vroby tengo la mia implementazione.

Credo che questa possa diventare una tendenza interessante: se sempre più persone lavoreranno così, il software sarà molto meno “uguale per tutti” e molto più cucito sulle esigenze di ciascuno.

2026-06-12

non saremo noi gli esploratori dell'universo

Scrivo queste poche righe come ricordo di questa serata in cui mi sono reso conto che molte cose che sognavo/speravo per il futuro (non certo il mio, che oramai sono vecchio) non si realizzeranno per il genere umano.

Il primo posto dove questo diventerà evidente è la Luna. Nei prossimi anni arriveranno, infatti, flotte di robot autonomi sulla Luna non solo per esplorare, ma per svolgere compiti di ricerca e, successivamente, minerari.

Mi aspetto produzioni industriali non sulla Luna, ma direttamente in orbita. Questo perché l’assenza di gravità può permettere la realizzazione di manufatti interessanti e crea la possibilità di accedere sempre all’energia del Sole. I metalli, invece, si estrarranno direttamente sulla Luna, verranno mandati in orbita probabilmente con una catapulta magnetica e saranno lavorati in orbita. In questo processo non ci saranno umani, ma solo macchine.

Robot e intelligenza artificiale mettono fine anche all’esplorazione umana dello spazio.
Gli esseri umani sono finiti in questo scenario in cui comandano in maniera sempre più distratta le macchine intelligenti artificiali fino a diventare irrilevanti. Non sarà necessario alle macchine sterminare gli inutili esseri umani ma per loro basterà attendere la naturale estinzioni dell'umanità instupidita e preda di noia e senso di inutilità

2026-06-10

2cv concept

 

Il quadriciclo L7e che vorrei vedere sulle strade europee




Negli ultimi anni il mercato dei veicoli elettrici si è mosso in una direzione precisa: automobili sempre più grandi, pesanti, potenti e costose. Ma se l'obiettivo fosse invece l'efficienza? Se si partisse da ciò che serve davvero per spostare quattro persone in città e nei percorsi quotidiani?

Da questa domanda nasce il concept che presento oggi: un quadriciclo pesante L7e a quattro posti, progettato secondo tre principi fondamentali:

  • semplicità

  • leggerezza

  • basso costo

Un ritorno all'essenziale

L'idea è quella di recuperare la filosofia della Citroën 2CV: eliminare tutto ciò che non è indispensabile e concentrarsi sulla funzione.

L'esterno adotta forme semplici e quasi geometriche:

  • lunghezza di circa 3,45 metri

  • larghezza contenuta in 1,50 metri

  • carrozzeria con pannelli facilmente sostituibili

  • quattro porte vere

  • ampie superfici vetrate

  • ruote di diametro generoso per migliorare comfort ed efficienza

L'aspetto è volutamente minimalista, senza elementi decorativi superflui.

Interni spartani ma intelligenti



L'abitacolo segue la stessa filosofia.

Niente:

  • schermi giganti

  • luci ambientali

  • rivestimenti costosi

  • tunnel centrale

Troviamo invece:

  • volante moderno

  • piccolo quadro strumenti digitale

  • plancia essenziale

  • sedili monoscocca in plastica bianca

  • panca posteriore semplice e leggera

I sedili anteriori non sono reclinabili e non utilizzano imbottiture tradizionali. Sono progettati per essere economici, robusti, facilmente lavabili e soprattutto leggeri.

L'obiettivo è ridurre ogni chilogrammo non necessario.

Perché un L7e?

La categoria L7e rappresenta una delle opportunità più interessanti per la mobilità elettrica europea.

Rispetto a un'automobile tradizionale permette:

  • massa inferiore

  • costi produttivi ridotti

  • consumi estremamente bassi

  • semplicità costruttiva

In pratica si può ottenere un veicolo perfettamente adatto agli spostamenti quotidiani senza dover trasportare una tonnellata e mezzo di batteria e struttura.

Specifiche ipotizzate



Il progetto prevede:

CaratteristicaValore
CategoriaL7e
Posti4
Lunghezza3450 mm
Larghezza1500 mm
Velocità massima90 km/h
Motore15 kW
Batteria11 kWh
Autonomiacirca 120 km
Massa a vuotocirca 560 kg

Con una batteria relativamente piccola si ottengono autonomie più che sufficienti per l'uso urbano e periurbano.

La vera sostenibilità

Spesso si associa la sostenibilità esclusivamente all'alimentazione elettrica. In realtà il parametro più importante è l'efficienza complessiva.

Un veicolo leggero:

  • richiede meno materiali per essere costruito

  • necessita di batterie più piccole

  • consuma meno energia

  • usura meno pneumatici e freni

  • occupa meno spazio nelle città

In altre parole, il veicolo più ecologico non è necessariamente quello con la batteria più grande, ma quello che utilizza meno risorse per svolgere lo stesso lavoro.

Un'alternativa concreta

Questo concept non vuole competere con SUV da oltre due tonnellate o con auto da 300 cavalli.

Vuole invece offrire una risposta semplice a una domanda molto concreta:

quanta automobile serve davvero per trasportare quattro persone a 90 km/h con consumi minimi e costi contenuti?

Forse la risposta non è un'auto sempre più complessa, ma un mezzo leggero, essenziale e razionale come questo piccolo L7e.

La mobilità del futuro potrebbe essere molto più vicina alla semplicità della 2CV che alla complessità delle automobili moderne.

2026-05-26

 Il futuro del coding: da tool specifici a agenti generali


È passato un po’ di tempo dall’ultimo post, e ora è il momento di fare il punto. Codex è ormai il “fido scudiero” che scrive codice, gestisce il PC, ricerca notizie e crea servizi automatici per me.

All’inizio ho realizzato applicazioni a “Babbo morto”, ma poi ho iniziato a scrivere solo ciò che mi veniva chiesto o che mi tornava utile. Scrivere un office o un nuovo linguaggio di programmazione non ha più senso: ci stiamo dirigendo verso codice personale, su misura per le proprie esigenze.

Oltre a Codex, ho adottato CLaude Code, ma lo utilizzo con modelli DeepSeek e il nuovo v4‑flash, che compete con i grandi modelli a una frazione del costo. Con 2 € di API ho coperto due settimane di lavoro. È meno efficiente di Codex con GPT‑5.5 xhigh (il top di OpenAI), ma per molti task è praticamente perfetto.

Ollama sta chiudendo i modelli cloud; senza l’abbonamento (che costa quanto OpenAI) non è più possibile usarli. Lo impiego solo per servizi minimi con IdeaAI t e pochi altri, che a loro volta stanno diminuendo di utilizzo.

L’ultimo step è Hermes, assistente personale alimentato da DeepSeek.

Credo che presto smetteremo di scrivere tool di programmazione per passare ad agenti generici che svolgono le attività al nostro posto. Il v4‑flash gira su macchine quasi “umane”; se tutto procede come previsto, entro il 2028, quando non potrò più usare la mia Raspberry Pi 1B come “carrotcamp”, avrò una macchina capace di fare inferenza locale con un modello di dimensioni simili a quelli più grandi attuali. Con questo passo il cerchio si chiude: Internet tornerà a essere un canale di comunicazione, come era originariamente, anziché una vetrina del sapere umano che invece sarà condensato in un LLM locale

2025-12-24

24 DICEMBRE

Eh sono passati 20 giorni dall'ultimo post. Ho scritto parecchio codice ed è il caso di riassumere (e mi sa che dimenticherò di sicuro qualcosa).

Dopo zig ho scoperto clang e llvm. Ho quindi fatto esperimenti e creato un piccolo compilatore BASIC che genera llvm poi da compilare. La prima versione in Python come con _c e poi una versione successiva in c. Non sono usciti dallo stadio esperimento perché non sono arrivato alla minima stabilità. Ho quindi provato generando codice c poi da compilare e li le cose sono andate meglio. In altri tempi era un ottimo risultato ma adesso con ai e bacon disponibile direi progetto inutile.

Ho quindi fatto ls. Local Storage è un implementazione in ram di un array associativo a chiavi persistenti in php. Non è un database completo ma è un ottimo modo per registrare in modo velocissimo dati con pochi comandi semplici. Le prestazioni mi paiono molto buone e probabilmente nei prossimi giorni lo pubblicherò su github.

Proprio stasera ho scritto un mini script che mi permette di spostare le finestre da uno schermo all'altro senza perdere la dimensione della finestra che succedeva con i comandi di mate. E' scritto in bash e funziona solo con Xorg ma non ho visto difetti.

Pero ora è tutto intanto buon natale!!



2025-12-05

Un occhiata a zig

ciao,
ieri ho provato Zig, il nuovo linguaggio di programmazione che dovrebbe essere il successore di C/C++. Ma esistono altre alternative (Go, Rust, F#, ecc.).
Dopo averlo visto solo superficialmente, ho notato che alcune cose sono identiche a quelle del mio _c scritto qualche settimana fa, pura coincidenza. In generale non mi è piaciuto il fatto che abbiano rifattorizzato la std, la libreria di base. Cambiare la struttura, cancellare intere sezioni, spostare, per esempio, random in crypto, mi fa pensare a una pessima pianificazione. Inoltre non vedo razionalità nello schema.
Posso accettare un'organizzazione complessa per motivi di prestazioni, ma da quello che ho visto la velocità è quella del C.
Alla fine, il mio _c, che elimina i punti e virgola e le graffe che fanno sempre problemi, implementa comandi brevi (ad esempio il dot come printf) e usa tipi semplici ed autoesplicativi, con un supporto stringa ben fatto ma ancora migliorabile, è forse meglio. Inoltre c'è il Jolly, che puoi solo tradurre, e il sorgente generato è un C perfettamente leggibile e facile da maneggiare. È vero che è un giocattolo solo per cose semplici, ma c'è la possibilità di espanderlo. Lo avevo considerato inutile, ma non mi sembra che Zig sia necessariamente molto meglio; forse è il caso di lavorarci ancora un po’, magari portando altre idee interessanti, come una piccola AI dedicata che funzioni da wizard del codice.

Andiamo avanti 

2025-11-29

un po di novità

 Ciao, 

Prosegue il periodo fertile di sviluppo.

Poiché non mi sento un buon scrittore, ho sviluppato un semplice strumento: scrivo il testo, lo fornisco a Ollama GPT‑OSS 20B, che lo rivede e mi restituisce la versione corretta sulla pagina sottostante. La cosa simpatica è che è scritto in bash, semplice, breve ed efficace. E' ancora da migliorare ma andiamo bene. Probabilmente lo migliorerò anche per scrivere in inglese lingua che non so proprio usare.  Un altro programma interessante che sto scrivendo è praticamente un programma ti permette di dettare quello che scrivo.

Anche lui è molto acerbo e continua a commettere errori. Dovrò fondere i due programmi per ottenere un programma che oltre a ricevere la dettatura vocale provvede anche a sistemare gli errori che il text to speech commette di continuo. Poi ho giocato con Suno e ho fatto una musichetta carina. L’idea era di fare una suoneria,ma è uscita una musica da demo e così ho fatto una demo HTML in JavaScript. È incredibile quanto è facile fare ciò che vuoi quando un LLM ti aiuta e ti scrive le parti difficili.  Per l’occasione, ho cambiato la pagina delle demo fatte con **three.js** in demo generiche.

Altra cosa carina e interessante è il gioco di Battaglia navale di gruppo e dopo un po di mazzolate lo considero finito.

Infine una cosa che mi ha dato una grande soddisfazione: finalmente il microfono del portatile nitro v15 e il tasto pilot funzionano anche su linux grazie al nuovo kernel appena installato.

 

2025-11-21

un canale youtube?

 Ciao, sto pensando di fare un canale youtube anche io. Vedo che a parte Antirez che però è molto specifico, Morro che è impostato sul sistema  e non sul codice e altri amici come Claudio Dafra che pero sono piu sul retrocomputing,  la qualita è piuttosto ridotta. L'idea sarebbe fare un canale che punta mostrare il codice in maniera genuina e in cui potrei mostrare i miei programmi da dentro senza filtri e senza scaletta  mostrando errori tecniche e idee. Chiaramente non durante lo sviluppo perche potrebbe essere noioso ma postmortem quando il codice è completo e ricordo ancora bene cosa ho combinato e perché. Il canale c'è gia si chiama verticaldev ma è completamente vuoto. Ho visto che si puo rinominare e lo chiamerei come questo blog vrobypages.

Nei giorni scorsi ho riprovato suno ed è ancora piu spettacolare. Puoi creare music nello tuo stile pressoche perfetta. Nell'ambito tecno trance dubito che ci sia ancora spazio per fare musica senza AI e tempo che oramai sia tutta sviluppata cosi.

Infine una nota che mi ha turbato molto. Con un amico sono andato a Milano e pasando per una via ho visto la chilometrica coda alla mensa dei poveri. Davvero tanta gente decisamente disperata. Stiamo precipitando in un baratro. Io ormai sono anziano ma sono profondamente preoccupato per il futuro distopico che si sta palesando.  


2025-11-18

un altro forth

 Spinto dal corso c di Antirez su youtube in cui sta mostrando come si scrive un interprete forth Ho pensato cosi per provare a scriverne uno a modo mio vale dire esasperando tutto.

Il forth è un antico linguaggio di programmazione anzi è in un certo senso anche un sistema operativo. figlio degli anni 60 è sicuramente parecchio alieno per che usa la notazione polacca inversa. Avevo fatto quanche mese fa una serata in compvter su questo linguaggio e sui insospettabili eredi il cui principale è il c nella maniera originale.

Siccome è molto alieno programmare inquesto linguaggio dico sempre scherzosamente che nel rottame dell'astronave aliena di Roosvelt avevano trova un computer con i transistor al germanio che faceva funzinare il forth.

Vediamo un po la notazione: 

una somma si fa cosi: 2 2 + 

lo spazio o l'invio è il separatore di tutto

il forth usa per tutto un buffer speciale che si chiama stack

La particolarita dello stack è che l'ultimo numero inserito è il primo ad essere estratto.

In realta è un componente previsto direttamente nei processori e solitamente ha i comand push e pop per scrivere leggere in questo buffer

scrivendo 2 metti il numero nello stack

scrivendo un scrivendo un altro 2 lo metti anche lui nello stack 

scrivendo piu invece siccome è un comando questo estrae il 2 dallo stack poi estrae il primo 2 dallo stack li somma e il risuiltato vien messo nello stack.

Questa logica è potente e semplice al tempo stesso: i comandi di base sono:

. (nel caso di Antirez ha usato print) stampa l'ultimo numero inserito nello stack

+ - * / sono  le operazioni matematiche. il risultato è posto nello stack

> <  = operatori di confronto (prendono i 2 numeri li confrontano e se la condizione è vera si mette 1 altrimenti 0)

if else endif preleva dallo stack se è piu di 0 esegue il comando dopo altrimenti cerca else o endif

eccetera....

La versione di forth che ho creato è estrema e minimale. E' scritta in c.

Lo stack non è quello del processore ma un array di int. la matematica va quindi solo a interi. Nel forth di solito la matematica è in virgola fissa.
Il word_exec (le word sono i comandi Forth) fa i confronti di tipo numerico a byte quindi verifica se è un numero altrimenti verifica se è un comando una nuova funzione o una variiabile  se non trova nulla emette un errore i comandi aggintivi e molti comandi lunghi tipo dup swap if else fi sono trasformati in numeri con una sorta di hash ma a 32 bit e confrontati quindi non uso strcmp che è piu ttosto pesante.
Per le variabili uso 2 comandi !nome_varibile che assegna alla  variabile il valore prendendo dallo stack e @nome_variabile che invece copia nello stack il valore.

Le variabili sono un altro array di una  struttura nome ,valore anche qui il nome è cifrato a 32 bit e il valore è un int (quindi su pc a 64 bit). anche qui il findvar è molto veloce perche cerca con il numero cifrato quindi 20X veloce.

Per le stringhe ho usato un array di array di char  ( char strings[64][128])
quanod la word inserita inizia con " exec_word mettette tutto il testo nella prima string vuota fino al successivo " quindi inserisce il numero dell'indice delle stringhe nello stack.

il comando $ preleva dallo stack l'indice string e lo stampa. Questo schema è furbo e permette cose strane tipo:

"ciao ciao" !ciao 

@ciao $ >stampa ciao ciao.

le funzioni in forth si fanno usando : nome_word comandi.... ; e l'ho implementao uguale solo che nel forth originale il comando viene compilato nel nano forth invece viene caricato in una array cosi come è e quando invocato viene semplicemente iniettato come fosse scritto sul momento. Di fatto sono piu macro che funzioni. Semplice veloce funziona bene ma non offre maggior velocita del codice diretto. 

Alla fine è molto limitato ma è un bell'esercizio intelligenza laterale nel cercare soluzioni 

estreme ed efficenti e mentre scrivo ho gia un paio di idee insane da aggiungere.

Dimenticavo di dire che funziona sia come terminale sia passando un file.

volete vederlo nei dettagli? https://gist.github.com/vroby65/082f0ffc98bd846b95ab0bac95312574






 

2025-11-14

google finance

 Ci risiamo, googlefinance la funzione di Google fogli non restituisce più i dati di borsa italiana. Io questa funzione la uso per automatizzare il foglio di calcolo dei miei investimenti. Google a livello di efficienza è sempre peggio. Solo 5 anni fa l'assistenza era impeccabile. Dall'anno scorso invece sono scesi al livello di Facebook con in pratica l'impossibilità di comunicare qualunque problema. E i problemi si moltiplicano.

Siccome non vedo neppure l'idea di riparare il problema pur avendo i dati su google.com/finance ne concludo che l'unico modo è provare la nuova funzione gemini che magari mi mette il dato con la Ai. Ma provando scopro che può solo fare operazioni con i miei dati...... Sia mai che diventa utile. Ok proviamo con gemini il chatbot e mi dice che non si può scrivere una funzione per fare scraping dei dati dal sito. Hummm secondo me questa è censura. Provo con chatGPT ed ecco la funzione semplice ed efficiente:

// ---- Per recuperare etf e azioni da google finance -----------------------
function prezzoGoogle(ticker, foo) {
const url = `https://www.google.com/finance/quote/${ticker}`;
const html = UrlFetchApp.fetch(url).getContentText();

const match = html.match(/<div[^>]*class="YMlKec fxKbKc">([^<]+)</);

if (match && match[1]) {
let prezzo = match[1].trim(); // es. "€143.96"
prezzo = prezzo.replace("€", ""); // rimuove €
prezzo = prezzo.replace(/\s/g, ""); // toglie eventuali spazi
prezzo = prezzo.replace(",", "."); // nel caso usasse la virgola

return parseFloat(prezzo);
} else {
return NaN; // così capisci che non ha trovato il valore
}
}

Che dire gemini ci nasconde questa scomoda (per loro) opportunità. Pero non si aggiorna ma troviamo un trucco: l'idea è avere una cella con =now() che viene passata come parametro. Però Google fogli si accorge del fugno e va in errore. Don't be evil dicevano.... certo certo. Risolvo puntando alla cella dell'anno. Se  la cancello e poi riscrivo tutte le celle collegate si aggiornano e funziona.

Ora cosa dire? Google tratta sempre peggio i suoi utenti sempre più aggressiva con la pubblicità sempre più egoista sempre più indisponibile. Della società superfiga accogliente che usa i profitti per innovare per migliorare il mondo non resta che cenere.

Sto facendo il backup dei dati con cadenza bimestrale e sto pensando di tornare con i miei dati sulla macchina fisica perché qui può succedere da un momento al'altro che anche bigG subisce un bel databreach con tutto quello che ne consegue e che forse i mega licenziamenti avranno si aumentato i profitti nel breve ma con un enorme peggioramento del prodotto e  dell'immagine che avevano.

Chiudo dicendo che secondo me Larry Page e Sergey Bring non avrebbero mai sponsorizzato una squadra di formula uno che con il mondo Google non centra nulla