19 Oct 2024

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 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

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 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ù.

07 Oct 2024

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:

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 :)

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.

21 Sep 2024

Terrò un talk durante openSUSE Asia 2024!

Se dovessi dire quale è l’emozione che ha prevalso di più in queste ultime settimane della mia vita, non ci riuscirei. Sono successe tante cose sia sul versante professionale che personale, ma in particolare di una cosa sono ultra felice: il talk che ho proposto qualche tempo fa per openSUSE Asia 2024 è stato accettato.

Il che significa che quest’anno, dopo essere stato in Giappone per ben tre settimane, mi godrò un’altra bella fetta di tempo a Tokyo per partecipare a openSUSE Asia, che quest’anno si tiene ad Azabudai Hills, con un talk sullo sviluppo di applicazioni per il desktop Linux in Rust con GTK, in particolare con alcune librerie che permettono di scrivere codice dichiarativo semplificando un po’ il flusso di lavoro, come Relm4.

Ho solo venti minuti per parlare di tutto questo quindi dovrò andare veloce e non mi potrò permettere particolari excursus, ma in particolare un aspetto su cui mi vorrei concentrare sarà una comparazione tra l’esperienza che ho sempre avuto sviluppando con tecnologie web e l’esperienza che sto invece avendo con lo sviluppo di un client per Pocket. Ci sono sicuramente tantissime differenze, come i tempi di build, le tecniche di distribuzione, e il fatto di avere UI e logica di business “impacchettati insieme”, ma anche tantissimi punti in comune, specie se si compara una tecnologia come React a una come Relm4, che ne è comunque figlia nell’approccio.

Ne racconterò sicuramente di più dopo la conferenza, per ora il mio pubblico giapponese (!!!) ha la priorità.

Cenni su openSUSE Asia

Già da qualche anno dei colleghi mi avevano incentivato a partecipare a openSUSE Asia, ma non l’avevo mai fatto perché non pensavo di essere abbastanza qualificato. Nell’ultimo anno la situazione è cambiata perché ho cominciato a dare una mano sulla distro, mantenendo il pacchetto di Elixir, portando alcuni pacchetti che erano assenti e soprattutto facendomi una cultura sul funzionamento del progetto attraverso le varie mailing list.

OpenSUSE Asia è un luogo di incontro fisico in Asia appunto per permettere lo scambio di idee di persona dove gli sviluppatori occidentali sono fortemente incoraggiati a partecipare, proprio per non far sentire le persone asiatiche in una sorta di silos, fenomeno che a volte accade in svariati progetti per via del fuso orario. Siccome l’idea mi intrigava, ovviamente mi sono subito messo a scartabellare e approfondire.

Dal blog ufficiale di openSUSE:

The openSUSE Project is excited to announce that openSUSE.Asia Summit 2024 will be held in Tokyo, Japan. The openSUSE.Asia Summit is an annual conference for users and contributors of openSUSE and FLOSS enthusiasts. The former summits received major participation from Indonesia, China, Taiwan, Japan, South Korea, and India.

Since the first openSUSE.Asia Summit was held in Beijing in 2014, the summits have been great opportunities for the online community to gather in person, know each other, and share knowledge and experiences about openSUSE including applications running on it. However, COVID-19 made it difficult for 3 years. One of our goals of this year’s summit is to provide a place for communication. Please note that we will not accept talks by video call this year.

Che altro dire… non vedo l’ora di essere sull’aereo. Ci si vede a Tokyo! :-D

11 Aug 2024

Ungoogling

Marco ha parlato molto male di me perché mi piace The Beekeeper. Voglio solo dire in mia difesa che io adoro qualsiasi puttanata scritta col palese intento degli autori di divertirsi smodatamente, e a me Beekeeper piace per quel motivo lì. Jason Statham, le botte, le cose, non serve che stia a spiegarvelo ulteriormente. Certo, potremmo parlare dell’abuso recente dell’archetipo del sicario micidiale che si è ritirato, ma questo forse è materiale per un’altra volta (e per svariate birre).

Quello che invece merita un approfondimento più minuzioso è una roba che ho avuto l’opportunità di eviscerare con lui privatamente riguardo il mio personale processo di “ungoogling”, che è da un po’ che porto pigramente avanti, avendo capito grazie a due anni di terapia che io sono uno in realtà psicologicamente equipaggiato per affrontare grandi compiti un po’ per volta.

Principalmente l’aspetto che finora ho coperto di più è la mail. Da ormai un po’ di anni, scontento principalmente delle fotocamere montate sugli smartphone Android ho comprato un iPhone¹, e di questo ho cominciato a usare parecchie cose togliendo man mano la roba da Google. Questo post mi serve principalmente, va detto, da checklist.

La componente maggiore del mio ungoogling, come tutti, penso che sia la migrazione da GMail. Su questo, pochissimo da dire ma espandibile a piacere: Fastmail offre un servizio talmente ben ingegnerizzato di suo, con un tool di migrazione che ti aggancia la vecchia casella del tuo vecchio provider per poi aiutarti a fare una migrazione graduale, che è veramente il top del sogno. In particolare, a me la cosa che è stata utile non è stata solamente la funzione di import della mailbox con relativo forwarding, ma il fatto che mi siano rimasti agganciati i calendari condivisi. Grosso plus. Ne ho un paio a cui non posso decisamente rinunciare.

Da un bel po’ di tempo quindi in realtà rispondo a [email protected] come indirizzo email personale², e ci ho piano piano spostato tutte le mie cose. Per il resto:

• Google Maps: sto lentamente cominciando a usare Apple Maps che nel tempo è migliorato parecchio. Non ne ho grande necessità se non come navigatore in macchina, e finora ancora non sono andato dentro a un fiume col cofano;
• YouTube: Non penso che riuscirò mai a eliminarlo. C’è troppa roba. I miei contenuti (semi-privati) però li sto caricando su un’istanza di Peertube neozelandese, sperando che regga per abbastanza anni.
• Google Drive: Per ora imprescindibile, ma vorrei migrare a un’istanza di Nextcloud self-hosted;
• Google Photos: Ho migrato a Amazon Photos perché come Marco posso portare avanti una battaglia etica alla volta. In futuro vorrei passare ad Immich, ma onestamente parlando mi caco addosso dei backup (che dovrei comunque avere).
• Google Calendar: Tutto integrato dentro Fastmail quindi ho migrato pure quello, a parte i calendari condivisi chiaramente. Il sync con un calendario Google che fa da proxy mi sembra alla fine un tradeoff accettabile.
• Google Search: La parte più importante, che stavo per tralasciare per distrazione. Ho una subscription attiva da un bel po’ di mesi a Kagi. Devo dire che nonostante tutto quello che si dice su Google che non è più una search company eccetera eccetera le remore maggiori a parte la mail me le sono fatte proprio per il motore di ricerca. Usavo da parecchio DuckDuckGo, ma ogni tanto andavo comunque a finire su Google e soprattutto non mi piaceva che DuckDuckGo fosse praticamente una skin di Bing Search. Kagi invece pare che non lo sia, offre insieme alla sua subscription una serie di servizi carini, e soprattutto i risultati sono buoni al punto tale che ormai è veramente raro che io non trovi quello che sto cercando.

Detto ciò, detto tutto: mi pare di essere a buon punto. :-D

Volevo infine ricordare che non prendo la stecca né da Fastmail né da Kagi, sono consigli che do perché mi piacciono particolarmente i loro prodotti.