Dal CAD agli agenti AI: una settimana di esperimenti

 

7–14 ottobre 2026

Questa settimana ho lavorato su parecchie cose, forse anche troppe. Ma guardandole tutte insieme mi accorgo che seguono un filo abbastanza preciso: sto cercando di rendere l'intelligenza artificiale sempre più utilizzabile nei miei programmi e nel mio ambiente Linux.

Non soltanto per scrivere codice, ma anche per disegnare, gestire applicazioni e automatizzare piccoli lavori quotidiani.

Su GitHub sono comparsi nuovi progetti, mentre altri hanno ricevuto modifiche importanti. Il protagonista della settimana è stato certamente AIcad, ma c'è anche un piccolo server che potrebbe diventare particolarmente utile.

AIcad: disegnare oggetti 3D parlando con un'intelligenza artificiale

Era un'idea che avevo da tempo: realizzare un CAD nel quale, invece di utilizzare esclusivamente mouse e menu, fosse possibile descrivere quello che si vuole ottenere.

Per esempio: «Disegna un cubo di 100 millimetri, aggiungi un cilindro e pratica un foro passante».

L'11 ottobre è comparsa su GitHub la prima versione funzionante di DeepCAD, successivamente ribattezzato AIcad.

Il programma utilizza HTML5, JavaScript e Three.js. Il modello tridimensionale viene visualizzato direttamente nel browser e l'intelligenza artificiale traduce le richieste in operazioni geometriche.

Nei giorni successivi ho lavorato su parecchi aspetti: sottrazioni fra solidi, fori modificabili, rotazioni, gruppi di oggetti, estrusioni, profili e deformazioni.

Sono arrivate anche la memoria della conversazione, la modifica delle proprietà degli oggetti e l'esportazione STL.

Una caratteristica interessante è che il modello AI non genera codice da eseguire liberamente: restituisce comandi strutturati che vengono controllati prima di modificare la geometria.

Il progetto è pensato anche come possibile risorsa didattica per CoderDojo. Non vuole sostituire un CAD meccanico professionale, ma permettere di sperimentare geometria, programmazione e intelligenza artificiale.

Il programma inizialmente prevedeva PHP, ma si è evoluto in un'applicazione completamente eseguibile nel browser, collegabile a un servizio AI configurabile.

Repository: AIcad

Applicazione: Prova AIcad

Un gateway AI sul Raspberry Pi

Un altro lavoro interessante nasce da una domanda: posso utilizzare il mio account ChatGPT anche attraverso piccoli programmi che scrivo personalmente?

L'idea è realizzare un servizio molto semplice, installato su un Raspberry Pi, che esponga una piccola API utilizzabile dalle applicazioni della rete locale.

Il 14 ottobre è nato il repository oai-gateway.

Il programma è scritto in Python e prevede l'autenticazione tramite OAuth, un endpoint per conoscere i modelli disponibili e uno per inviare richieste.

Ho voluto mantenerlo essenziale. Il server viene avviato e fermato quando serve, senza trasformarlo in un servizio permanentemente esposto su Internet.

La documentazione prevede infatti l'utilizzo esclusivamente sulla rete privata, con autenticazione locale e senza apertura di porte sul router.

L'obiettivo è avere un componente riutilizzabile: oggi può servire ad AIcad, domani potrebbe essere utilizzato da altri programmi.

Naturalmente l'utilizzo effettivo dipende dai permessi concessi al proprio account e dai limiti del servizio. Non è una maniera per aggirare le API commerciali.

Repository: oai-gateway

ChatGPT sta diventando il mio agente personale

Parallelamente sto cambiando il modo in cui utilizzo ChatGPT.

Da qualche tempo non lo considero più soltanto uno strumento al quale fare domande. Lo sto utilizzando sempre più come un agente operativo, capace di interagire con applicazioni e servizi esterni.

In particolare sto sperimentando l'integrazione con l'ecosistema Google: documenti, fogli elettronici, posta elettronica e calendario.

Preferisco non entrare nei dettagli delle operazioni personali, ma la differenza è evidente: invece di chiedere istruzioni per svolgere un lavoro, posso chiedere direttamente all'assistente di occuparsene.

Naturalmente controllo i risultati, soprattutto quando vengono modificati dati importanti.

Questa evoluzione mi ha portato anche a ridimensionare l'utilizzo di Hermes.

Ho rimosso Hermes e PicoClaw dal computer principale, mantenendo Hermes soltanto sul Raspberry Pi rakgateway, dove continua a essere collegato a Telegram.

È una scelta pratica: sto concentrando una parte crescente delle attività operative su ChatGPT, lasciando agli agenti locali compiti più specifici.

Linux Mint, zram e kernel 7.3

Non poteva mancare qualche esperimento sul sistema operativo.

Sono tornato a lavorare su zram, il meccanismo che permette di utilizzare memoria compressa come dispositivo di swap.

L'obiettivo è migliorare la gestione della memoria e mantenere il desktop reattivo anche quando vengono eseguiti diversi programmi contemporaneamente.

Ho continuato inoltre gli esperimenti di compilazione e configurazione del kernel Linux 7.3, cercando di adattarlo alla mia macchina.

È un lavoro che si inserisce nella stessa filosofia di mint-cachyfy: ottenere un sistema Linux Mint efficiente senza rinunciare alla sua semplicità.

Per ora preferisco non riportare miglioramenti numerici: non ho raccolto risultati comparativi sufficientemente documentati per attribuire vantaggi precisi alle modifiche.

La curiosità rimane quella di sempre: capire quanto contino davvero le ottimizzazioni rispetto alle impostazioni standard.

Repository: mint-cachyfy

Ho anche ripreso in mano il vecchio EeePC 700, che continua a funzionare con Debian Bookworm e i3. Il sistema è utilizzabile, ma trovare un browser moderno sufficientemente leggero è diventato complicato. Un piccolo promemoria di quanto rapidamente il Web stia diventando pesante per l'hardware più vecchio.

Microduck diventa protagonista di un videogioco

Il 9 ottobre è nato un progetto decisamente diverso: The Microduck Game Show.

L'idea è riprendere l'atmosfera di The Killing Game Show, un vecchio gioco per Amiga, sostituendo il protagonista con un piccolo robot ispirato a Microduck.

Il risultato è un platform giocabile direttamente nel browser.

Ci sono otto arene differenti, nemici, piattaforme, chiavi da raccogliere e un livello di acido che sale progressivamente costringendo il giocatore a muoversi.

Durante la giornata ho lavorato sulla struttura dei livelli, sulle regole di gioco, sulla gestione dell'energia e sulla grafica del protagonista.

È un piccolo omaggio ai videogiochi degli anni Novanta, realizzato con strumenti moderni.

Repository: The Microduck Game Show

Gioco: Gioca a Microduck

Continuo anche a seguire con interesse i progetti di robotica personale come Nori A3 e Microduck. Le loro caratteristiche dichiarate sono interessanti, ma distinguo sempre le promesse dei produttori dalle capacità effettivamente verificate.

MiniMax Video TUI: generare video dal terminale

Un altro progetto che ha ricevuto un aggiornamento il 14 ottobre è minimax-video-tui.

Si tratta di una piccola applicazione da terminale che permette di generare video utilizzando i modelli MiniMax disponibili attraverso OpenRouter.

Il programma consulta il catalogo dei modelli, permette di scegliere risoluzione e durata e mostra una stima del costo prima di avviare la generazione.

L'ultimo aggiornamento ha aggiunto nuove opzioni video e la possibilità di utilizzare immagini locali come punto di partenza.

Mi interessa soprattutto poter utilizzare questi servizi senza dipendere ogni volta da una complessa interfaccia Web.

Repository: minimax-video-tui

Tech News Daily: pubblicare ogni mattina

Continua anche il lavoro sulla mia rassegna tecnologica quotidiana.

Dal giorno 8 al 14 ottobre risultano su GitHub nuove edizioni giornaliere di Tech News Daily.

Il progetto raccoglie notizie tecnologiche, produce una pagina HTML e mantiene un archivio delle edizioni precedenti.

Non tutto ha funzionato immediatamente. Ho dovuto intervenire più volte sul meccanismo di pubblicazione, soprattutto per mantenere sincronizzati l'archivio e la pagina principale.

Il 14 ottobre ho aggiunto anche una navigazione che permette di raggiungere le cinque edizioni precedenti direttamente dalla home page.

L'obiettivo rimane avere una rassegna aggiornata automaticamente, senza dover intervenire manualmente ogni mattina.

Repository: tech-news

Gli altri esperimenti: ai-bar, za.py e RepoRoulette

Restano attivi, anche se questa settimana non sono stati i protagonisti dei nuovi commit, altri esperimenti.

ai-bar continua a rappresentare il mio tentativo di integrare maggiormente l'intelligenza artificiale nell'ambiente desktop. Ho adottato una struttura che separa il progetto generale dalle personalizzazioni e utilizza AGENTS.md per guidare gli agenti che modificano il codice.

za.py, attraverso freellmApi, rimane invece un esperimento per consentire a un modello linguistico di interagire con il sistema operativo attraverso operazioni controllate.

C'è poi RepoRoulette, il piccolo sito che presenta repository GitHub casuali, uno dopo l'altro, con un'interfaccia ispirata alla vecchia Chatroulette.

L'idea è semplicemente scoprire software che non avrei mai pensato di cercare.

Sito: RepoRoulette

Nel frattempo ho anche iniziato a ragionare su come documentare meglio il lavoro svolto dagli agenti. Quando utilizzo strumenti e modelli differenti sullo stesso progetto, diventa utile avere un diario delle modifiche che registri non soltanto cosa è cambiato, ma anche quale agente ha effettuato l'intervento.

Il Raspberry cambia mestiere

Un altro piccolo cambiamento riguarda rakgateway.

Ho definitivamente chiuso il vecchio progetto LoRa-One e rimosso la relativa scheda radio.

Il Raspberry Pi oggi svolge compiti differenti: è un nodo Tor, ospita il sito dei Cantinari e mantiene in funzione Hermes collegato a Telegram.

Mi piace l'idea di continuare a utilizzare queste piccole macchine anche quando il progetto originale è terminato.

Conclusioni

Guardando i commit della settimana, il lavoro più consistente è stato sicuramente quello su AIcad, seguito dal nuovo gateway AI e dal videogioco Microduck.

Le modifiche sono state concentrate direttamente nei repository, senza nuove pull request o issue pubbliche emerse dalle verifiche effettuate.

Ma il cambiamento più importante è forse un altro.

Per anni ho scritto programmi per svolgere determinate operazioni. Poi ho iniziato a utilizzare modelli AI per aiutarmi a scriverli.

Adesso sto provando a costruire programmi che possano essere utilizzati direttamente da un'intelligenza artificiale.

Non so ancora dove porterà questo percorso, ma mi sembra una direzione interessante.

E, soprattutto, continuo a divertirmi.

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.

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.

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.

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.

 

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.

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.

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.

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.

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.

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.

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à

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:

Caratteristica	Valore
Categoria	L7e
Posti	4
Lunghezza	3450 mm
Larghezza	1500 mm
Velocità massima	90 km/h
Motore	15 kW
Batteria	11 kWh
Autonomia	circa 120 km
Massa a vuoto	circa 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.

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