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.