Thomas Henry Huxley era noto a tutti come "il mastino di Darwin". Quando Charles Darwin diede alle stampe l'opera che avrebbe cambiato per sempre il nostro modo di guardare alla vita e alla storia naturale, fu Huxley a scendere nell'arena, a mordere le caviglie dell'ortodossia scientifica e teologica vittoriana, a difendere quell'idea rivoluzionaria con l'ardore e l'intransigenza di chi non teme il conflitto.
Darwin meditava nella quiete di Down House; Huxley combatteva le battaglie pubbliche sul campo.
E hanno fatto la Storia, perché poi non è mai solo uno a farla.
La quiete ed il chiasso del mondo
Trovarmi qua, in questo contesto — la 2026 OpenAtom Developer Conference di Zhengzhou — mi intimidisce, ma mi dà la responsabilità delle mie idee di "scoiattolo" del software, cresciuto durante e dopo l'esplosione dei microprocessori e degli home computer degli anni Ottanta. Quasi l'equivalente informatico di una nuova esplosione cambriana: la radiazione adattativa di noi piccoli mammiferi all'indomani della scomparsa dei grandi dinosauri (i mainframe).
Le ho viste tutte o quasi: il mio primo "cervello elettronico" — il mio gioiello Sinclair ZX81 con 1 KB di RAM, al cui manuale si deve quasi interamente il mio pessimo inglese — sino all'arrivo dei PC negli uffici e al loro collegamento con le prime reti, fino allo stato attuale.
Il mio lavoro è stato per anni definito "computeraio", ovvero operaio del computer. Non c'era un termine ufficiale: si faceva di tutto, anche lo scavo per far passare il cavo coassiale BNC dell'epoca tra diversi edifici, per non parlare dei buchi sui floppy da 720 KB per trasformarli a 1.44 MB fatti col trapano a colonna dell'officina fabbri.
Per anni ho creato e mantenuto gestionali in DOS con Clipper 5, sino a gestire tutta la nostra modesta organizzazione di circa 300 persone: dalla gestione del personale ai progetti e ai cantieri. La 3Com era nata in America, ma non aveva ancora una sede in Italia, ed intorno al '95 — in un ufficio ancora chiuso al pubblico — con l'unico impiegato presente tracciammo le linee per creare una rete moderna con gli switch ed i doppini telefonici. La rete venne poi realizzata nel 1997. Nel 2000 si ruppe il nostro sistema, un RMS Datapoint; successe esattamente il 29 febbraio: non ci fu nulla da fare e della ditta originale, passata ad altro, nessuno sapeva più metterci mano.
La rete Ethernet però era pronta. Avevo scritto un software che dai file EBCDIC estraeva i dati in ASCII e quindi li convertiva in DBF; lo facevo girare ogni giorno perché era l'unico modo per avere dei report in tempi accettabili.
Quello salvò noi scoiattoli: non perdemmo alcun dato!
Avevamo pure collegato i file in formato DBF ad un engine di esportazione verso Microsoft SQL Server e questo ci diede un ulteriore vantaggio: non avremmo più usato un semplice file server, ma un server di database relazionale.
Riscrivere tutto fu un lavoro pesante. Un giorno con un pugno ammaccai persino l'armadio di ferro del nostro centro di calcolo, ma — colmo dell'ironia, dato che il primo aprile in Italia si fanno gli scherzi — giusto in quel giorno riuscimmo a far ripartire tutto: circa 120 postazioni di lavoro.
Le sessioni di debug e correzione continuarono sino all'autunno inoltrato, ma avevamo scavalcato il fosso.
Google era agli albori. Io avevo già preso ad amare Linux e mi piaceva terribilmente Knoppix di Klaus Knopper: potevi farti la tua versione, installarlo, modificarlo. Era magico rispetto alle installazioni rigide e tediose di Windows!
Gli anni però passano e le cose si evolvono. Presi interesse per i motori di ricerca e Nutch, poi arrivò Facebook, ma soprattutto ho ancora il nitido ricordo del beep beep di ICQ: la messaggistica istantanea che dilagò a quei tempi.
Internet era diversa: si era a tutti gli effetti un'élite.
E le cose cominciarono a cambiare. Gli stessi venditori che prima proponevano soluzioni chiuse, ora proponevano soluzioni su PC standard dicendo "noi della...", rifilandoti però sempre la stessa minestra.
Erano nati JavaScript e PHP; la risposta proprietaria fu VBScript ed ASP: sappiamo tutti com'è andata a finire.
Cominciai a sostituire parte del lavoro dei server con Debian, in particolare con Proxmox v0.7, che andava già come un treno. Usando PHP e JavaScript si andava veloci e si facevano cose egregie: è di quegli anni la tecnologia AJAX, con la quale, costruendo un breve middleware, riuscivo a trasmettere pure i recordset di SQL Server dentro la nostra intranet, evitando i problemi di configurazione delle porte.
Ad un certo punto però le porte si chiusero: si presero gli switch e vollero centralizzare il tutto. Si delegò la gestione informatica all'esterno e si puntò su ASP o, quando andava di lusso, su Java. Intanto nel mondo Mark Zuckerberg
diventava famoso e notavi che Facebook, era allora interamente basata su PHP e derivati. Gli ultimi due o tre anni prima di decidere per il congedo, per aprire le porte ad una presa di rete dovevo dettare il MAC address al telefono ai colleghi del supporto, persino per avviare il boot remoto e ripristinare un sistema su una rete che avevo progettato io stesso.
Non tutti gli animali abitano l'ecosistema allo stesso modo. C'è chi ha la tempra del mastino: fiero, guardiano, pronto al corpo a corpo concettuale per difendere un principio universale.
La natura di noi scoiattoli ed — ahimè — anche l'età mi fecero invece allontanare dal bosco per l'ampia radura del pensionamento. Però non volevo appendere la tastiera al chiodo, ma, come dire: non si fa informatica in astratto, servono gli utenti.
Il bipedismo
Stare nella radura richiede di dover scrutare i pericoli. Ero ancora abbastanza in forze, provai a buttarmi su qualcosa da fare. Cincischiai un po', poi mi venne l'idea di riprendere il discorso interrotto con il boot remoto. Ormai utilizzavo Linux da anni, sia al lavoro che a casa. Ottimizzai il tutto installando direttamente Proxmox sul mio computer domestico e aggiungendovi un desktop manager, con la possibilità di far girare 2 o 3 VM in contemporanea. Non era una fuoriserie o, meglio: dieci anni fa lo era per essere un computer di casa; oggi un i7-6700 @ 3.40GHz con 8 thread e 16 GB di RAM fa sorridere, ma tant'è, è ancora la mia macchina da lavoro.
Mi ero già divertito per anni con remastersys e systemback fino a quando non furono dismessi e smisero di funzionare. Capita la lezione, decisi di provarci da solo. Mi studiai a fondo remastersys, systemback e refracta-snapshot (che poi ho scoperto dall'autore di MX-snapshot, AdrianTM, derivare dal suo lavoro).
Refracta aveva il vantaggio di essere comprensibile per me, era scritto in bash e ed ampiamente commentato. Bash però era ed è croce e delizia, un po' di JavaScript lo conoscevo, all'epoca sembrava modernissimo, e scrissi la prima versione di penguins-eggs usando Node.js e i pacchetti npm, perché l'idea originaria era renderlo il più possibile universale e indipendente dalla singola distro.
Iniziai da Debian, che conoscevo meglio; dopo un anno lo portai su Arch/Manjaro — grazie anche alla fondamentale collaborazione di Stefano Capitani di Manjaro — e una volta fatte due o tre distribuzioni diverse venne "semplice" continuare con Alpine, Fedora e OpenSUSE, fino a capire che il progetto stava diventando troppo grosso per uno sviluppatore singolo, anzi: per un pensionato.
Nel frattempo è arrivata quella per cui molti di voi oggi sono riuniti qui: l'Intelligenza Artificiale. Quella vera, quella che con l'architettura transformer e l'immane lavoro successivo è diventata finalmente pratica. Non come ai tempi in cui diedi l'esame di AI con il mitico e caro professor Eliano Pessa, quando si lavorava senza hardware né modelli maturi sulle prime reti neurali ricorrenti (RNN), che promettevano molto ma mi apparivano lontane da ogni utilità pratica.
Così, non avendo evidentemente niente di meglio da fare il primo di quest'anno, scrissi a SpacemiT con l'idea di portare penguins-eggs sotto RISC-V: in fondo BianbuOS è pur sempre una Debian. Con mia grossa sorpresa, il 2 febbraio mi è stato recapitato un MuseBook K1 nuovo di zecca con processore SpacemiT K1 (non un fulmine di guerra, ma infinitamente meglio e più concreto dell'emulazione software di riscv64).
Il 4 marzo ho avvisato gli sviluppatori di SpacemiT che ce l'avevo fatta: penguins-eggs funzionava su Bianbu e poteva creare un'immagine live del sistema installato.
Non ho potuto creare una classica ISO live x86, perché il K1 (come molte board RISC-V attuali) non fa il boot dallo standard El Torito tramite un BIOS/UEFI convenzionale, ma richiede immagini disco raw/GPT su scheda SD/eMMC con partizioni bootinfo o U-Boot specifici. Sapevo che non aveva ancora un'utilità commerciale immediata, ma la vittoria dello scoiattolo è stata proprio adattare il meccanismo per generare un'immagine live avviabile su quell'hardware ostico.
Non potevo spingermi oltre senza un chip più potente come il K3, ma doveva ancora uscire. Così, verso fine marzo, ho preso il coraggio a due mani. Mi sono detto: prima che qualcun altro analizzi il mio codice con un modello linguistico per riscriverlo, è meglio che ci provi io stesso.
Mi diedi del tempo, ma compresi subito — in una settimana — che la strada era buona: un software frutto di quasi un decennio di stratificazioni in Node.js è stato riscritto dal suo stesso autore in circa un mese, trasformato in Go, in codice nativo, snello e veloce.
La prima versione riscritta con tag v9.6.2 è arrivata l'11 aprile; dal 18 luglio siamo passati alla serie v26.7.x, considerata stabile. Il porting definitivo a RISC-V sul nuovo codice nativo è ancora in fase di rifinitura, ma sono qui in Cina a parlarne, e qualcuno dalla Cina stessa usa già eggs per rimasterizzare sia su x86 che su architettura ARM64.
Non solo: l'appetito vien mangiando, come diciamo in Italia.
Avevo più volte accarezzato l'idea di una GUI che facesse solo l'interfaccia, lasciando al tool CLI i compiti di basso livello. Da poco ho rilasciato penguins-gui, che permette di comandare penguins-eggs e penguins-chef direttamente da ambiente grafico.
Voglio sottolineare però che l'interfaccia grafica è solo un'opzione, e probabilmente non la migliore in molti contesti: con l'avvento dei modelli generativi, la riga di comando è diventata accessibile anche ai comuni mortali che non sono abituati a tenere a mente dozzine di parametri come una seconda lingua, come scoiattoli selvaggi e magari più giovani!
La mia avventura con le distribuzioni cinesi
Ero affascinato dall'eleganza di Deepin e già con la versione Node.js di eggs l'avevo rimasterizzata più volte; poi ho scoperto anche openKylin.
Entrambe, per chi fa il mio mestiere, soffrono di gigantismo: sviluppare un software di rimasterizzazione richiede decine di prove consecutive, e testare continuamente su immagini da 6 GB non è una passeggiata.
Inoltre entrambe mano a mano si modificavano, passando da una compatibilità totale con Debian all'adozione di meccanismi propri. Per riprovarci con la nuova versione di penguins-eggs in Go, ho notato la disponibilità della versione server minimale di openKylin.
Ebbene, non c'è voluto molto: le uniche sfide erano le piccole divergenze rispetto a una Debian standard, ma fatte un po' di prove e sessioni con l'AI sono riuscito a creare immagini funzionanti e installabili. Ho replicato la versione server ridenominandola naked, ho creato una variante personalizzata con desktop Xfce4 grazie al supporto di openKylin per questo ambiente - il mio colibri - e, a questo punto, ho pensato di contattare direttamente il loro team.
Ed eccomi qua. penguins-eggs è rilasciato con licenza MIT: lo considero un po' come un figlio/a ed è ormai adolescente, pronto a viaggiare per il mondo in compagnia di chiunque lo apprezzi.
L'evoluzione applicata al silicio
Per anni, rimasterizzare una distribuzione è stata considerata un'attività futile. Il vezzo di chi voleva dire «ho fatto la mia distro» senza avere alle spalle un repository, un'infrastruttura o una reale visione tecnica: bastavano uno sfondo personalizzato, un tema scuro, un sito web e un forum. E spesso la critica era meritata.
Oggi vi chiedo di ribaltare del tutto questo pregiudizio.
penguins-eggs non è una distribuzione e non è semplicemente un tool di remaster, per quanto sofisticato. Non è un compromesso al ribasso, ma una forma di visione ecologica applicata al software.
Guardare al software libero con una lente puramente ingegneristica è sempre stato riduttivo. Il codice non è una cattedrale immobile scolpita nel marmo una volta per sempre: un sistema operativo puo essere visto come un organismo vivente. E come ogni organismo, è sottoposto costantemente alla pressione selettiva del suo ambiente: chip che nascono e tramontano, librerie che mutano, comunità che si trasformano, etc.
Ma soprattutto, l'ambiente - qualsiasi esso sia -è dominato da una legge immutabile: la scarsità delle risorse. Scarsità di tempo. di memoria, di banda, di cicli di clock, di budget per rinnovare le macchine. Una scarsità che non riguarda solo il vecchio computer in soffitta, ma definisce l'infrastruttura quotidiana di tutti, dalle scuole agli ospedali fino alle più grandi organizzazioni.
L'industria commerciale risponde alla scarsità chiedendo al mondo di buttare via il ferro e comprare nuove risorse.
L’open source artigiano risponde adattando l'organismo.
Chi progetta con l'ambizione di costruire il "sistema perfetto e monolitico" finisce quasi sempre per fare la fine dei grandi organismi iper-specializzati: maestosi, ma fragili al primo mutamento. La vera forza della vita non sta nella stazza, ma nella capacità di riprodursi, adattarsi e trasmettere l'esperienza acquisita.
Un organismo e per estensione un sistema sano dovrebbe possedere, fin dall'inizio, la capacità autonoma di riprodursi: non per generare semplici copie carbone, ma per dare origine a nuove forme. La variazione nasce dall'esperienza viva di chi lo utilizza sul campo: dal desktop che sceglie, dai programmi che installa, dalle necessità che incontra e dalle soluzioni che trova.
Se lasciamo a queste variazioni la libertà di essere racchiuse in un uovo, condivise e distribuite, accade qualcosa di straordinario: alcune si adatteranno meglio di altre a nicchie particolari, occuperanno nuovi spazi, risponderanno a necessità che non avremmo neppure immaginato. Proprio come in natura, non è necessario prevedere in anticipo tutte le forme che potranno nascere: è sufficiente creare le condizioni perché possano farlo.
Ed è da questa intuizione, in qualche modo "darwiniana" che nascono gli strumenti che curo ogni giorno:
-
penguins-eggs: come una membrana protettiva, isola e custodisce il patrimonio genetico del sistema, permettendogli di adattarsi all'ecosistema o di mettersi in salvo altrove quando il clima sul vecchio ferro diventa irrespirabile;
-
penguins-chef: il motore di provisioning basato su ricette dichiarative YAML per personalizzare alimentare il sistema e farlo crescere;
-
penguins-gui: la finestra grafica opzionale per chi preferisce l'interfaccia visuale alla shell;
-
naked: denomino infine in questo modo l'immagine live del sistema operativo preso nella sua forma nuda CLI, senza fronzoli grafici, ma riproduttiva.
-
colibri: è praticamente la mia workstation di sviluppo, con la quale metto a punto e controllo eggs su ogni distribuzione. In sostanza è il ferro del mestiere, continuamente riforgiato.
-
albatros, duck, eagle, sparrow e swallow sono semplicemnte abbozzi che possono essere estesi o presi ad esempio di configurazione base con diversi desktop, rispettivamente: plasma, cinnamon, gnome, mate and lxqt.
L'ambiente dello scoiattolo
Tornando all'inizio Huxley difendeva la teoria; lo scoiattolo, molto più modestamente, mette in pratica la necessità.
Si aggira tra le distribuzioni, sale sui rami di Debian, salta su quelli di Arch, si affaccia su Fedora o sulle nuove terre di Alpine e del silicio ARM64 e RISC-V. Raccoglie una configurazione, sistema un piccolo script, alleggerisce il carico, nasconde una ricetta in una cartella denominata secondo le specifiche XDG, perché sa che prima o poi servirà a qualcuno.
Non pretende di riscrivere le leggi dell'universo. Gli basta sapere che quando nel bosco cambia stagione, quando un computer rischia di essere buttato via o quando una comunità ha bisogno di ritrovare la propria tana senza dover ricominciare tutto da capo, i semi sparsi lungo il cammino sono lì, pronti a germogliare: per offrire a un sistema la possibilità di riprodursi, di cambiare e magari dare origine a qualcosa di nuovo.
Charles Darwin aveva un mastino per amico, capace di ringhiare contro il mondo intero a difesa della grande idea dell'evoluzione.
Col tempo, chissà, forse anche l'agile ostinazione di uno scoiattolo indaffarato gli avrebbe strappato un sorriso.
Almeno lo spero,
un grazie a tutti, sono grato ed onorato per questa collaborazione al team di openkiln.
