31 Dec 2024
A volte la vita prende delle pieghe inaspettate. Cose a cui hai lavorato sparsamente per tantissimo tempo si uniscono per formare una bella visione d’insieme. È così che per un intricato sistema di specchi e di leve, quando sono stato a Tokyo per openSUSE Asia sono stato contattato per un ruolo che si stava aprendo in SUSE e che sarebbe stato un’ottima opportunità.
Dall’altro lato, domani marcheranno esattamente tre anni e quattro mesi dal mio ingresso su Trento, il progetto di monitoraggio e observability per panorami SAP che SUSE mantiene (e vende) da parecchio tempo. Nonostante sia stato sicuramente in grado di dare la mia impronta al progetto, sicuramente ci sono stati dei punti della mia agenda che non sono stato in grado di portare fino in fondo o sponsorizzare adeguatamente: un marketplace per i check di compliance di terze parti, per esempio, o l’adozione di tecnologie come eBPF per permettere un monitoraggio a un livello più profondo dei workload sul singolo host.
Nonostante la frustrazione per questi piccoli non finiti michelangioleschi non ho comunque rimpianti: è stato un bellissimo progetto, e ho avuto dei compagni di viaggio fenomenali.
Dal primo giorno (anzi, dal secondo) dell’anno nuovo comincerò a lavorare direttamente su SUSE Observability. Ovviamente all’inizio la mia agenda avrà solo due punti: spalare un sacco di rumenta in modo da rendermi conto di dove risiedono le maggiori necessità, e soprattutto ascoltare. Ascoltare un team di ingegneri che mangia pane e observability da parecchi anni, perché sono sicuro che per me sarà una fonte di crescita incredibile.
Mi è uscito un post con quel tono farlocco un po’ da Linkedin, motivo per cui chiedo scusa a chi legge. Non so se traspare l’eccitazione, quindi in caso lo rinnovo: me la sto facendo addosso, un po’ dal terrore di dimostrarmi inadeguato, un po’ dall’entusiasmo.
Forse è meglio che vada a prendere già pala e ramazza.
09 Nov 2024
L’ultima settimana è stata allucinante: di ritorno dalla retreat del mio team a Norimberga, ci siamo imbarcati (io e il buon Jan) per openSUSE.Asia 2024, diretti a Tokyo.
Ho già parlato quest’anno di quanto sia affezionato alla terra nipponica, e tornarci tutto sommato dopo così poco tempo è stato veramente qualcosa di magico: ho percepito la sensazione di essere un habitué, ricordato posti, visitato per la seconda volta angoli di Tokyo che ormai conoscevo come le mie tasche. Questo non mi ha impedito di perdermi a Nakano Broadway e dentro la stazione di Shinjuku, ma penso che la prossima volta avrò ancora meno problemi di orientamento.
Appena arrivati, giusto il tempo di un ramen e di un sonno ristoratore per poi precipitarci negli uffici di SHIFT Inc. dove si è tenuta la conferenza. I nuovi uffici di SHIFT nella Mori JP Tower incarnano davvero il concetto di “office with a view”, devo dire. Se di giorno il panorama era mozzafiato, in questa stagione dove Tokyo sa mostrare il suo lato più nebbioso e autunnale:
La sera si arrivava a delle visioni uscite direttamente da un romanzo di Gibson:
Durante le due giornate di conferenza, i talk sono stati veramente interessanti. Dato l’intreccio con il Cross Distro Developers Camp (XDCC) si andava da verticali su openSUSE a cose più di ampio respiro come il mio talk su Rust e GTK4 per GNOME (ma non solo). Che, tra parentesi, spero sia piaciuto: le domande sono state parecchie e ha dato il via a una bella discussione post-talk, che date le tempistiche non è stata nemmeno ripresa per intero.
Ovviamente gran parte della conferenza è stata presa da talk su Micro OS e su come Micro OS sia un’eccellente piattaforma per workload containerizzati: il mio collega Jan Fooken ha anche parlato di come sia possibile ottenere il “proprio” Micro OS con pattern custom e così via usando solamente le feature messe a disposizione da OBS, da systemd e da mkosi.
Oltre ad esserci fatti una cultura su come funziona transactional-update (il tool per la gestione degli aggiornamenti di Micro OS) e su tutti i concetti implementati da un sistema operativo immutabile, abbiamo avuto chiaramente gli evergreen, ovvero la panoramica sullo stato dell’arte di openSUSE e gli aggiornamenti dalla Geeko Foundation sullo sviluppo di una struttura che permetta al progetto di prosperare. Il talk che ho apprezzato di più dal punto di vista tecnico sicuramente è stato quello di Giovanni Gherdovich su sched-ext, il nuovo meccanismo che permette agli sviluppatori di creare scheduler pluggabili nel kernel ottimizzati per casi d’uso specifici.
Il secondo giorno oltre al talk di Jan è stato il mio turno: come ho scritto sopra ho parlato di come sviluppare un’applicazione per GNOME (ma non solo) usando Rust, GTK, libadwaita e Relm4, una libreria che implementa i pattern reattivi per il rendering della UI che si ispira molto a Elm e React. Dato che più persone hanno allungato il collo in maniera telescopica quando ho mostrato gli esempi basati sia sul codice di esempio che sul codice di Cauldron (e non penso fosse per la dimensione dei font), penso di aver fatto un buon lavoro. Avrei voluto avere più tempo, ma quando ho scritto l’abstract pensavo che il materiale fosse pochino: solo in seguito ho capito che in realtà mi stavo impelagando in qualcosa che somigliava quasi più a un workshop che a un talk vero e proprio.
Onestamente non pensavo che avrei respirato un clima così vibrante di amicizia e community: molto spesso siamo portati a pensare che la community di openSUSE sia tutto sommato molto ristretta e non così viva, invece questa conferenza mi ha dimostrato il contrario. Ho viaggiato attraverso un oceano per scoprire che la distribuzione alla quale nel tempo libero metto qualche pezza qui e là è usata da un bel po’ di gente, nel mio posto preferito del mondo: persone in carne ed ossa a cui spero anche, nel mio piccolo, di aver fatto scoprire qualcosa in più. Un ecosistema che non avevo idea di quanto fosse immenso, a cui spero di aver dato il mio piccolissimo contributo.
どうもありがとうございます!
20 Oct 2024
La settimana scorsa ho saltato il devlog di Cauldron perché ho fatto un casino con l’organizzazione dei tempi anche dato il fermento per un po’ di bisboccia imminente coi colleghi.
Innanzi tutto c’è da dire che cogliendo l’occasione di un paio di viaggi in treno belli pesanti mi sono deciso a iniziare il processo per far avere a Cauldron un’icona, richiedendola al design team di GNOME, i quali ragazzi sono stati gentilissimi: Jakub Steiner ha persino condiviso dei primi bozzetti che sono assolutamente adorabili. Oltre questo mi sono concentrato nel mettere a punto un README che non facesse schifo e che linkasse al contempo al resto dell’ecosistema di GNOME.
Questa settimana invece mi sono dedicato a cose più fattuali e “code-wise” visto che avevo a disposizione un paio di macchine serie (purtroppo il mio amatissimo laptop ha i suoi limiti quando si tratta di questo genere di cose). Innanzi tutto ho finalmente implementato una logica di download più robusta per cui vengono scaricati tutti gli articoli salvati dall’utente, mentre prima me ne perdevo parecchi per strada semplicemente perché non mi andava di stare a litigare con la paginazione.
Mi ci è voluto un po’ ma l’adorabilissimo serde ha fatto il suo.
Su un versante più relativo all’eye-candy, invece, ho fatto in modo che quando vengono caricati gli articoli venga visualizzato un bellissimo spinner al posto del bottone di refresh. All’inizio avevo usato un normalissimo spinner GTK, dopodiché il tutto è diventato un po’ la tana del bianconiglio.
Mi sono accorto infatti che libadwaita espone un suo Spinner, che ovviamente è costruito sullo spinner di GTK ma è molto più facile da impostare (leggasi: ha una API umana). Ha anche un look un po’ più moderno. Purtroppo però è disponibile solo in libadwaita 1.6, che a sua volta è scritta per GNOME 47. Ho quindi colto l’occasione per portare l’applicazione a GNOME 47, principalmente aggiornanto le feature del crate di Relm4 e finalizzando gli smanettamenti che avevo già iniziato sul manifest Flatpak di sviluppo.
Insieme allo spinner ho anche portato la mia prima icona custom, per l’azione di archiving, all’interno dell’app: ho avuto qualche problema a farla andare correttamente con la dark mode, ma una volta data una letta al manuale ho capito il sistema di specchi e leve che usa GNOME per fare il fill in automatico delle icone a seconda che si usi la dark mode o no, e ho risolto.
L’aspetto che ancora non riesco a inquadrare e sul quale ho persino da ridire è il testing. Non sono ancora riuscito a scrivere dei test decenti, e penso che dopo qualche refactor mi sarà più facile. Vorrei testare anche la UI oltre che la logica di business, ma ho capito che con GTK è un bagno di sangue.
19 Oct 2024
Oltre a esortare Marco a continuare il suo post sul perché è diventato manager, complice il mio periodo di crisi mistica sul mio futuro lavorativo, gli sono immensamente grato. Innanzi tutto perché come spiegavo oggi a un altro amico, mi reputo estremamente fortunato ad averlo nella lista di persone a cui posso rompere i coglioni.
Ma, oltre questo, perché è uno che alla fine ha un po’ la mia stessa testa quando si parla di approccio alle cose. Parlavamo da settimane e giravamo intorno al fatto che ci sarebbe piaciuto sperimentare col fediverso e con un’istanza più piccola, dedicata a pochi amici, solo su invito.
Alla fine dopo diecimila pippe mentali e dibattiti fantasmagorici siamo andati a sbattere su Mastodon come software e lui ha aperto mettendoci soldi e voglia masto.cazzo.lol, il cui nome mi ha subito fatto innamorare. Ho contestualmente scoperto che mentre per lui la cosa era piú un esperimento, io stavo già gettando il cuore oltre l’ostacolo alla faccia dell’osservazione non partecipante migrando tutto il mio profilo da livellosegreto.it alla nuova istanza.
13 Oct 2024
Questo weekend sono stato a un matrimonio. Nonostante la bellezza stupenda della genuinità di un gruppo di amici che si riunisce per far festa, una cosa in particolare che mi ha colpito è stato parlare con un altro invitato, anche lui addentro al mondo dell’informatica quanto me: parlando del mio lavoro, della distribuzione Linux su cui ogni tanto metto le mani, ovviamente è scappato il “ah, ma è ancora sviluppata?” di rito.
Questo ancora una volta mi ha portato a chiedermi se abbia senso il concetto di distribuzione Linux, che infatti sta morendo per come era inteso negli anni passati. Ad oggi quello che viene comunemente inteso come distribuzione Linux ha molti meno livelli rispetto a prima:
- Il primo livello di configurazioni di base, rappresentato dalla gerarchia del filesystem, dagli strumenti preinstallati e dalle location predefinite in cui il package manager installa i pacchetti di base;
- Da systemd in su è praticamente tutto standardizzato, e le personalizzazioni sono minime;
- Lo userspace è dominato praticamente in toto, nei sistemi operativi immutabili per esempio, da sistemi di distribuzione come Flatpak o Docker, dove la distribuzione Linux in sé non interviene più nel “distribuire” appunto i programmi utilizzati dall’utente, tantomeno nel personalizzarli con temi o impostazioni diverse da quelle predefinite dai team di sviluppo.
Ne consegue che ormai il ruolo di una distribuzione Linux è quanto più a basso livello possibile: diminuendo le differenze nello userspace e standardizzando i meccanismi di distribuzione delle applicazioni tratti come il supporto alla Full Disk Encryption, la presenza o meno di un determinato modulo del kernel, l’inclusione di programmi per consentire l’osservabilità del sistema (come una suite di programmi eBPF), risultano tutti fattori differenzianti per le distribuzioni Linux.
Distribuzioni che a questo punto possono permettersi di smettere di dedicare forza lavoro al patching delle applicazioni, per preoccuparsi di quello che dovrebbero in realtà fare al meglio: consentire il funzionamento del sistema operativo come un orologio, senza errori.
Il che, personalmente, è la cosa che mi appassiona e interessa di più.
