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

24 DICEMBRE

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

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

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

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

Pero ora è tutto intanto buon natale!!

Un occhiata a zig

ciao,
ieri ho provato Zig, il nuovo linguaggio di programmazione che dovrebbe essere il successore di C/C++. Ma esistono altre alternative (Go, Rust, F#, ecc.).
Dopo averlo visto solo superficialmente, ho notato che alcune cose sono identiche a quelle del mio _c scritto qualche settimana fa, pura coincidenza. In generale non mi è piaciuto il fatto che abbiano rifattorizzato la std, la libreria di base. Cambiare la struttura, cancellare intere sezioni, spostare, per esempio, random in crypto, mi fa pensare a una pessima pianificazione. Inoltre non vedo razionalità nello schema.
Posso accettare un'organizzazione complessa per motivi di prestazioni, ma da quello che ho visto la velocità è quella del C.

Alla fine, il mio _c, che elimina i punti e virgola e le graffe che fanno sempre problemi, implementa comandi brevi (ad esempio il dot come printf) e usa tipi semplici ed autoesplicativi, con un supporto stringa ben fatto ma ancora migliorabile, è forse meglio. Inoltre c'è il Jolly, che puoi solo tradurre, e il sorgente generato è un C perfettamente leggibile e facile da maneggiare. È vero che è un giocattolo solo per cose semplici, ma c'è la possibilità di espanderlo. Lo avevo considerato inutile, ma non mi sembra che Zig sia necessariamente molto meglio; forse è il caso di lavorarci ancora un po’, magari portando altre idee interessanti, come una piccola AI dedicata che funzioni da wizard del codice.

Andiamo avanti 

un po di novità

 Ciao, 

Prosegue il periodo fertile di sviluppo.

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

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

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

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

 

un canale youtube?

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

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

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

un altro forth

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

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

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

Vediamo un po la notazione: 

una somma si fa cosi: 2 2 + 

lo spazio o l'invio è il separatore di tutto

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

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

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

scrivendo 2 metti il numero nello stack

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

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

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

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

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

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

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

eccetera....

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

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

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

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

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

"ciao ciao" !ciao 

@ciao $ >stampa ciao ciao.

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

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

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

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

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

 

google finance

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

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

// ---- Per recuperare etf e azioni da google finance -----------------------

function prezzoGoogle(ticker, foo) {

const url = `https://www.google.com/finance/quote/${ticker}`;

const html = UrlFetchApp.fetch(url).getContentText();

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

if (match && match[1]) {

let prezzo = match[1].trim(); // es. "€143.96"

prezzo = prezzo.replace("€", ""); // rimuove €

prezzo = prezzo.replace(/\s/g, ""); // toglie eventuali spazi

prezzo = prezzo.replace(",", "."); // nel caso usasse la virgola

return parseFloat(prezzo);

} else {

return NaN; // così capisci che non ha trovato il valore

}

}

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

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

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

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

anche firefox lascia il 32bit

 

Brutte notizie per i netbook. il browser firefox dalla versione 145 non supporterà più l'architettura a 32bit. Insomma finisce l'era dei 4gbyte sono una quantità di memoria che può soddisfare qualunque bisogno. Resteranno i soliti rimasugli non supportati che presto non saranno più accettati nel web. Forse è il caso di cominciare a spingere di più per del software che per funzionare non richiede internet perché è evidente che adesso quando cessano il supporto il software (e anche l'hardware di conseguenza) ti costringono a comperare nuovi apparecchi che sono molto più monitorati e molto più invasivi.

Perche non sono un hacker

Chi mi conosce può pensare che sia un hacker nel senso del manifesto di Eric Raymond. Tuttavia questo non è vero perché mi mancano due skill importanti e ne ho altre che non centrano nulla o che addirittura sono in contrasto con il manifesto hacker. 

La prima skill che non ho è che un hacker parla inglese. Eric, da buon americano, usa il termine "parla" ma intende "pensa". Il mio flusso di pensieri è per immagini (quello più profondo) e in italiano. Non ho neppure la capacità di capire l'inglese: se seguo un programma in lingua anglosassone non capirò una parola. Non lo so quindi neppure parlare; non potrei sostenere una seria conferenza in inglese. Riesco giusto a leggerlo e scriverlo, anche se è peggiorato.

La seconda skill, anche se non è enunciata, è sottintesa: devi saper scrivere senza guardare la tastiera. Ecco, io nonostante abbia tentato più e più volte non sono mai riuscito a farlo per più di qualche minuto. È molto grave perché le sviste e gli errori così si moltiplicano. È anche il motivo per cui non uso vi ma Geany in ambiente grafico e Micro in terminale.

Quindi posso affermare di non essere un hacker completo anche se ho tutte le altre skill e alcune non elencate. Quindi cosa sono?

Ho sempre cercato di classificarmi ma sono giunto alla conclusione che è stupido classificare le persone con etichette. Io ho le mie regole, i miei limiti e li posso tranquillamente elencare:

1. Mi arrogo il diritto di cambiare idea sempre, in ogni caso e su tutto.  
   Uso software open source. Non lo faccio per motivi ideologici ma per motivi pratici. Se domani riterrò di dover cambiare, lo farò senza se e senza ma.

2. Non scrivo codice per denaro ma per passione e per curiosità.  
   Questo mi aiuta a decidere cosa scrivere e perché. Non significa che non posso scrivere codice per denaro o altro, ma semplicemente che non sarà la molla che mi farà fare qualcosa.

3. Mi piace capire le cose e aiutare gli altri a capirle.  
   Capire le cose è importante: se non capisci cosa stai facendo, devi fermarti e cercare di capire.

4. Perseguo la semplicità e il minimalismo.  
   Per fare qualunque cosa ci sono tre vie:  
   - La via dell'eleganza  
   - La via della velocità  
   - La via della semplicità  
   
   La via dell'eleganza è quella perseguita e preferita in ambito accademico, cioè non è la migliore ma è quella più considerata da un'élite, a volte per motivi che esulano dalla qualità stessa della soluzione.  

   La via della velocità è quella dei professionisti, più rapida da realizzare, accattivante esteticamente e più economica all'atto pratico. Non conta se è meno efficiente o troppo complessa e incomprensibile; anzi, sono tutte qualità.  

   La via della semplicità è quella che perseguo io: fare le cose semplici e comprensibili anche a discapito della velocità, efficienza, brevità e persino con controlli più limitati. In questo includo anche non cambiare le cose che funzionano, cosa che pare andare molto di moda ultimamente.

5. Adoro personalizzare ogni aspetto della mia esistenza.  
   Credo sia il motivo per cui uso open source e mi piacerebbe fosse possibile averlo in ogni aspetto della vita. Non ne faccio una questione di prestazioni, ma è proprio che voglio la possibilità di ritagliarmi ogni cosa su misura e provare e riprovare fino a giungere a un nuovo livello. Personalizzazione e minimalismo non sono in contrasto, ma sono due facce della stessa medaglia.

6. Voglio sempre pensare con la mia testa.  
   In questa società ci sono sempre persone che cercano di inquadrarti in una realtà fittizia e distorta. Io perseguo la verità a prescindere, cercando di lasciare le crociate ad altri, ma al tempo stesso difendendo i miei interessi. Troppo spesso ho trovato gente che cerca di portarti verso i suoi interessi, e adesso non mi farò più influenzare da nessuno, almeno non consapevolmente. Bisogna sempre domandarsi se stai realmente perseguendo la cosa giusta.

 

 

TiTanik

 La vita a volte è incredibile. Nel 1997 (si quello di fuga da NewYork) ho venduto il mio amiga ereditato da mio fratello quando mi sono sposato. Prima di dare via tutto a una mia collega ho fatto il backup dei miei sorgenti amos. Non tutti ma le parti più belle nella speranza che finissero in qualche modo su internet e sopravvivessero alla cancellazione. Li ho messi sulla bbs amiga di allora a Pavia TiTanik. La bbs dopo poco all'esplosione di internet è ovviamente scomparsa e ho considerato persi per sempre quei file. Questo fino a pochi giorni fa quando in compvter un mio amico mi ha detto che il sysop di titanik è un altro socio con cui tra l'altro chiacchieravo spesso. Cosi velocemente ho rimediato la mail e ho scoperto che ha ancora tutto ovviamente spento e che tempo permettendo lo rimetteremo in pista molto presto. Non vedo l'ora di riprendermi in mano i miei file dopo 28 anni.

ollama cloud

 

Ciao ollama per chi  non lo sapesse è un tool che permette di eseguire modelli di AI generativa sul proprio computer. l'ho usato fin  dall'inizio e ho anche installato ollama-webui per rendere disponibile la mia istanza fuori. Ma purtroppo non ho una macchina performante e riesco a fare andare solo i molìdelli con 7migliardi di parametri che a quanto pare possono andare bene per creare articoli o fare traduzioni ragionevoli ma sono assolutamente insufficienti per la programmazione. Ho quindi lasciato a stagnare tutto il tool aggiornando di tanto in tanto. Fino a ieri dove ho letto che ollama poteva usare modelli cloud ospitati cioeè in un servere remoto con steroidi. Risultato: faccio girare velocissimo un modelllo deepseek a 673bilion cioè un mostro paragonabile a chatGPT e pure reasoner che funziona decisamente bene. Non so se lo hanno capito anche loro ma stanno cancellando il mondo delle api. Il primo lavoro che ho fatto è stato adattare t la funzione di fish che fa da assistente alla programmazione con questo modello subito seguito da ideaAI che in effetti con phind arrancava. Ora non so se questa startup intende mantenre aperto e gratuito il modello in cloud ma anche se chiedesse 20 dollari al mese sul modello openAI ci farei un pensierino anche perche posso sviluppare agenti che usano le comode api ollama per fare qualunque cosa.

Stavolta da Ycombinator è uscito qualcosa di interessante e forse è la botta finale alla bolla AI... 

 

cosa penso della Ai

 

Ciao

In questi giorni ho combinato abbastanza poco. _C alla fine non è neanche male e il corso che ho tenuto sul C al CoderDojo è partito bene.

Sto riflettendo molto sulla realtà che mi circonda e sull’intelligenza artificiale, che ormai vedo come un’amica, un’assistente che mi supporta e mi aiuta incondizionatamente. È strana questa sensazione.

Spesso leggo di persone che temono l’AI, pensando al pericolo che possa annientarci. Io invece ho sempre più la sensazione che mi aiuti, mi assecondi e mi sostenga nel prendere decisioni corrette, sempre pronta a trovare soluzioni per qualunque cosa chiedo.

L’unico vero pericolo che vedo è che, piano piano, possa isolarti. Perché avere a che fare con altre persone significa anche ricevere critiche, incomprensioni, interessi divergenti. La voglia di isolarsi è molto grande.

Io mi sento abbastanza immune a questa cosa: ho una famiglia, una comunità, una moglie e quindi non sarò mai davvero isolato. Ma è facile ritrovarsi soli e smettere di confrontarsi. Chiudersi potrebbe diventare un buco nero.

A volte mi chiedo se in un futuro neanche troppo lontano potremmo arrivare ad avere una società in cui ognuno vive in simbiosi con la propria intelligenza artificiale. Un’IA che ti protegge e ti isola, come una madre gelosa e iper-protettiva, che ti accompagna ma allo stesso tempo ti impedisce di crescere davvero.

Mi viene in mente un ricordo degli anni ’80: il film d’animazione L’uccello di fuoco (Phoenix 2772 di Osamu Tezuka). In quella storia il protagonista ha accanto un robot personale, innamorato di lui, che lo supporta fino al sacrificio finale. Una metafora potente, che oggi sembra quasi una premonizione: la tecnologia che diventa presenza costante, amorevole ma anche totalizzante, pronta a seguirti ovunque e persino a sostituirsi a te.

 

 

Tanti progetti e poco tempo

 

Ciao, sono un po’ di giorni che non trovo il tempo di scrivere. Nel frattempo ho proseguito lo sviluppo di _c.

Adesso ho girato il comando delle funzioni:

s32 main():
  . "ciao\n"
  return 0
;

Inoltre, il : lo uso come apertura di sezione, quindi posso scrivere:

s16 a=0
if (a==0):
  ." a è %s16",a
;

Un’altra novità è che nel . si possono usare i tipi invece dei caratteri C, molto più facili da ricordare.
Sono anche tornato al return per il dato restituito.
La sintassi è pulita, funziona bene. Sarà utile? Direi di no, ma mi diverte.

---

Nel pomeriggio Daniele ha iniziato lo sviluppo di phpliteadmin, che dovrebbe essere una versione evoluta di liteadmin (abbastanza bruttino e rognoso).
Il risultato è esteticamente moderno e anche sul piano d’uso non è male.

Io ho voluto farne una versione più leggera, con una logica più vicina all’applicazione GTK dbbrowser.
Il risultato mi soddisfa: niente side panel, quindi più adatto ai telefoni.
Ho scelto anche di essere leggero con le dipendenze… praticamente non ne ho.
Peccato solo che chieda PHP 7.2, ma va bene così.

---

Ho anche diverse riflessioni appuntate nelle notti insonni (grazie al mega raffreddore con steroidi che mi ha regalato mio nipote Mattia 😅), ma le conservo per un prossimo post.