Alessio Biancalana Grab The Blaster di Alessio Biancalana

openSUSE.Asia 2024: quando Linux e il ramen si fondono

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:

Tokyo Day

La sera si arrivava a delle visioni uscite direttamente da un romanzo di Gibson:

Tokyo Night

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.

どうもありがとうございます!

Una foto di gruppo, Thinkpad aperto e si esce a comandare

Cauldron devlog, settimana #10

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.

Cauldron alla sua undicesima settimana

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.

masto.cazzo.lol

Oltre a esortare Marco a continuare il suo post sul perché è diventato manager, complice il mio periodo di crisi mistica sul mio futuro lavorativo1, 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.it2 alla nuova istanza.

  1. nel senso che ultimamente è una cosa a cui penso spesso. Forse ne dovrei scrivere approfonditamente, ma il succo è: se pensi di poter avere un buon impatto su chi ti sta intorno e pensi che il tuo traguardo sopra ogni cosa sia far stare bene chi lavora con te, dovresti dunque considerare il management? 

  2. ragazzi, sono stati anni bellissimi. Grazie di aver dato una casa al mio “self” italiano sul fediverso. Vi voglio bene. 

Il ruolo delle distribuzioni Linux nel 2024

Questo weekend sono stato a un matrimonio. Nonostante la bellezza stupenda della genuinità di un gruppo di amici che si riunisce per far festa1, 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ù.

  1. Perché di questo si è trattato, più che di un vero e proprio banchetto nuziale, nonostante l’ottimo catering. A tratti una cerimonia, a tratti un piccolissimo rave party. Ancora i miei migliori auguri a Marco e Guan Xing. 

Cauldron dev log, settimana #8

Da metà Luglio più o meno sto scrivendo un client Pocket per Linux che ho iniziato per un paio di motivi principali:

  • Mi serviva, essendo io un utente del servizio, e mi dava enormemente fastidio che l’unico client decente fosse quello ufficiale per macOS;
  • Non avevo mai sviluppato un’applicazione con la GUI che non fosse una webapp, e mi sembrava il momento storico adatto per cimentarmi con questa sfida.

Avendo maturato una precisa consapevolezza di quale è lo stato dell’arte sullo sviluppo in Rust e GTK, e dovendo il talk che farò a openSUSE Asia poggiare su un esempio reale, mi ci sto dedicando da più di due mesi settimanalmente.

Oggi sono riuscito a implementare la dark mode senza particolari barbatrucchi:

Cauldron dark mode :-)

In realtà la cosa peggiore finora, oltre far visualizzare la webview per renderizzare il contenuto degli articoli, è stata riuscire a iniettare del CSS dentro la webview stessa. L’approccio che ho scelto è subottimale ma funzionale: scorrendo le callback messe a disposizione dalla struttura dati della webview ho visto che c’era una connect_resource_load_started, che viene eseguita a ogni carimento (appunto) di una risorsa remota. In questo modo avendo accesso all’istanza della webview da un punto strategico è possibile innestare nel meccanismo “reattivo” di Relm4, che ho scelto come libreria che orchestra gli update all’interfaccia, del codice che provvede a impostare nel content manager della vista stessa il foglio di stile necessario per il rendering corretto.

Questo era necessario prima di tutto perché altrimenti detto senza mezzi termini la UI faceva schifo, pena e pietà; ho però rubato un paio di trucchetti dal codice di NewsFlash in merito e ho scoperto che reagendo a un paio di classi CSS apposite è possibile anche supportare la dark mode di GNOME senza nessuno sforzo.

A parte quello di scrivere quelle due righe di CSS in più, chiaramente.

Oltre questo ho implementato un paio di cose stupide ma che fanno sembrare l’applicazione un po’ più vera e meno un giocattolo:

  • La UI adesso reagisce in maniera appropriata quando un articolo viene archiviato, togliendolo dalla lista degli articoli disponibili e tornando allo stato iniziale;
  • C’è una piccola call to action che fa da empty state quando nessun articolo è selezionato. Pensavo fosse una scemenza, invece mi piace un sacco il feeling :)

Cauldron "empty state"

Sto togliendo piano piano tutta la rumenta grossa a livello di codice che ci può essere a livello di debito e di UX. Non sono ancora soddisfatto del testing, ma ci sono due cose che mi preme fare prima di subito:

  • La submission su FlatHub
  • Scrivere un README decente, con screenshot e quel poco di documentazione che fa la differenza tra un progetto amatoriale e uno, invece, serio.

Oltre questo, vorrei chiedere gentilmente un logo al design team di GNOME perché le mie abilità con Inkscape sono al livello di una scimmia ubriaca.

Member of

Previous Random Next