16 Mar 2024
C’è una storia il cui racconto ho sempre rimandato.
Io sono sempre stato un fedelissimo utente di Feedly, fino a qualche tempo fa, talmente fedele da mantenerne il supporto dentro Newsflash per un bel po’ di tempo. La farò breve: Feedly come azienda a un certo punto ha deciso che degli utenti se ne sarebbe sbattuta abbastanza i cosiddetti, e contestualmente alla scadenza del developer token di Newsflash (quello associato al “nostro” App ID) ha provveduto a spiegarci in maniera assolutamente certosina che avrebbe considerato l’emissione di un nuovo token solo a fronte del fatto che il team di Newsflash (nella persona di Jan Lukas) avesse realizzato un client in grado di usare le loro feature di intelligenza artificiale.
Siccome a lui di fare questa cosa non andava, a me meno che meno, alla fine io con mio sommo scorno non ho più potuto mantenere l’integrazione con Feedly, e lui è stato costretto a togliere il supporto al servizio di sincronizzazione perché, in the end, con il nostro token scaduto aveva smesso di funzionare.
Questo è, diciamo, il prologo di questa storia.
In un secondo momento sono diventato un utente abbastanza affezionato di Inoreader, di cui ho anche pagato una subscription. Pochi spicci in pratica, ma erano comunque i miei spicci, e finalmente credevo di aver trovato un feed reader decente in grado di farmi riprendere l’affezione per i feed RSS come mezzo d’informazione: questo è stato vero in parte. Se con il telefono avevo un mezzo perfetto per fare questo, ovvero NetNewsWire, un’app per iOS che si integra perfettamente con Inoreader, dall’altra parte sul mio computer sono sempre stato condannato a dover abbandonare Newsflash (il mio client RSS preferito, a cui ho anche contribuito!) perché a meno di avere un access token dedicato la quota riservata all’access token “ufficiale” di Newsflash era esigua e costantemente cannibalizzata. Il vero problema è che Inoreader per un accesso API decente, dedicato, e comunque soggetto a rate limiting e quote piuttosto stringenti chiede un prezzo che è il triplo di una subscription normale.
Per quanto ci abbia pensato, comunque non ho mai trovato la voglia di strisciare la carta di credito per questo. Di tutte le cose per cui adoro farmi rubare i soldi, l’accesso API in toto a una piattaforma è qualcosa che credo rientri comunque nei diritti di qualsiasi utente. Una questione di principio, se vogliamo. Fatto sta che l’altro giorno, non ricordo titillato in quale maniera, in call con Gianguido e Simone, ho iniziato a urlare frasi sconnesse sul tema e dopo un po’ il buon Gianguido ha pensato bene di erudirmi sullo stile dell’apone della Cheerios: “Ma tu Miniflux l’hai mai provato? Perché sembra esattamente quello che vuoi tu - ed è self hosted”.
Ovviamente la mia risposta è stata sull’onda del “se prima avevi la mia curiosità ora hai la mia attenzione”, e ho cominciato a investigare.
E quindi adesso vi spiego perché Miniflux è il feed reader migliore del mondo.
Innanzi tutto ha un’interfaccia web minimalissima. E quando dico minimale intendo davvero minimale, no notifiche, no toast, no cazzate, solo tu e il testo. Penso che il tutto siano solo template statici, che per un’app del genere assolvono il compito perfettamente.
Poi: installarla è una scemenza. L’applicazione specie dalla v2 in poi è un solo binario, è scritta in Go, si prende tutta la configurazione da variabili d’ambiente eccellentemente documentate. Abbisogna solo del classico Postgres d’appoggio per i dati. Io con cinque bicchieri di vino in corpo all’una di notte l’ho deployata su un cluster Kubernetes a occhi chiusi.
Terzo: siete troppo pigri per installarla da voi? Non avete un server su cui ospitare questa fantastica applicazione? Per 15 dollari l’autore vi crea un account sulla sua hosted instance. Fantastico.
La lista delle integrazioni è enorme: su NetNewsWire basta selezionare FreshRSS e mi pare che vada anche abilitato un layer di compatibilità API nelle impostazioni, e siamo a cavallo. Newsflash la supporta nativamente. Reeder sono sicuro che la supporti tramite il layer di Fever API. C’è la disponibilità dell’integrazione con Pocket e con letteralmente qualsiasi altra cosa ci venga in mente.
Un vero gioiello.
Da meno di 24 ore sono tornato ad appropriarmi dei miei feed RSS e devo dire che sono felicissimo, perché applicazioni come Miniflux mi fanno credere che un’informatica fuori dalle logiche di Internet vista solo come un’enorme vetrina sia ancora possibile.
31 Dec 2023
Ho pensato per almeno un’ora, con la musica ininterrotta nelle orecchie e nella testa, a come iniziare questo post. Alla fine ho deciso che come sempre scriverò di getto e chissene. Eccoci quindi al solito ricapitolo di fine anno, un’abitudine che non vorrei mai perdere e che mi dà un bel senso di chiusura in coda a 365 giorni.
Siccome però mi accorgo che già sto lanciando parole a caso, raccolgo le mie carabattole del 31 Dicembre e provo ad elencare un po’ quello che ha caratterizzato questo 2023.
Ho scritto troppo poco
Prima di tutto una delle cose che non ho apprezzato del 2023: ho scritto troppo poco su questo blog, e me ne dispiaccio, perché tendo sempre un po’ a bistrattare questo angolino di web che è casa mia, principalmente perché dedico tempo ad altro. La mia psicologa dice che non mi dovrei fare colpe rispetto a come decido di spendere il mio tempo, ma alla fine un po’ di dispiacere per non dedicare abbastanza tempo a questo spazio e abbastanza spazio a questo tempo rimane.
Nel 2024 sicuramente voglio fare un po’ meglio, prendendo come metrica semplicemente il numero di post di quest’anno e migliorarlo di qualche punto percentuale. Visto il numero di partenza penso che non sarà molto difficile.
Lavoro
Ma andiamo a esplorare le categorie dell’oroscopo! Lavoro: sicuramente uno dei motivi che mi ha portato a togliere quel po’ di tempo che dedicavo di più alla scrittura in generale e al blog nello specifico. Ad Aprile il mio team ha rilasciato Trento 2.0, e da quel punto del ciclo di vita del progetto il ritmo è sicuramente aumentato a causa della maturità e dell’adozione leggermente maggiore del prodotto. Questo ha significato per tutti noi che eravamo coinvolti un po’ di ricalibrazione: sicuramente avere a che fare con le situazioni a cui siamo stati messi davanti non è stato semplice.
La cosa bellissima però è che nonostante le sfide molto complesse che abbiamo affrontato, siamo qui per raccontarlo. E l’abbiamo raccontato più che bene: tra la metà e la fine di Ottobre io e Carmine abbiamo girato un po’ di meetup e conferenze per presentare quello di cui siamo più fieri a varie platee. L’accoglienza è stata clamorosamente buona, cosa di cui sono veramente veramente felice.
Amore
Un’altra categoria dell’oroscopo: il piano amoroso. Io e Agnese siamo ancora una coppia (e che coppia!). Visto quanto è stato impegnativo e intenso quest’anno specie sotto certi aspetti (come il lavoro, appunto) considero il fatto che non mi abbia mandato a fanc a cogliere le margherite come un grandissimo traguardo.
Dice ma perché lo scrivi qua e ce lo racconti a tutti? È una storia lunga, ma sostanzialmente tanto tempo fa mi sono ripromesso di non dare nulla per scontato. E trovo che non ci sia modo migliore di evitare di dare per scontato qualcosa, che appuntarlo negli highlight di fine anno :-)
A parte questo, il più grande traguardo sul piano affettivo relativo al 2023 è l’essere riusciti a organizzare una maratona natalizia di cibo quasi non-stop, a casa nostra, il 24 e il 25 di Dicembre. A fine post vedrete le nostre facce leggermente più stanche per questo motivo. :-D
Salute
Mi sono rotto una mano verso fine anno. Ho trattato più diffusamente sul mio profilo Mastodon inglese la cosa, con tanto di foto del tutore che ho portato per un mese intero. Diciamo che la grossa morale che mi sono portato a casa da questo evento è che mollare pugni in giro quando si è frustrati potrebbe rivelarsi davvero una cattiva idea.
D’altra parte dicono che apprezzi di più le cose quando le perdi, e sicuramente perdere l’uso quasi totale della mano destra per più di trenta giorni è stato un bel modo per rimettere in prospettiva un sacco di roba.
Piano personale: una grande preparazione per una grande messa a terra
In generale il 2023 è stato un anno in cui ho sentito una grandissima molla caricarsi, per tantissimi versi. Io e Agnese abbiamo cominciato a studiare il giapponese un po’ per scherzo, arrivando a parlarlo a piccolissime dosi anche dentro casa, e abbiamo guardato una fracca senza fine di anime. E abbiamo prenotato un viaggio in Giappone per (appunto) il 2024. Non so se il quantitativo inusitato di anime in TV e manga sul comodino sia causa o conseguenza del viaggio, né se lo siano tutte le ore spese su Duolingo e col dizionario in mano.
C’è stata da parte di tutti e due una pianificazione profonda di un sacco di piccoli progettini che avverranno nel corso dell’anno, si spera. Per questo io mi auguro per me e per chiunque legga questo post che il 2024 sia un anno di possente messa a terra di tutto quello che è stato rifinito nel 2023. Che finalmente ciò che non è stato espresso trovi la sua via d’uscita. Che ogni intento si trasformi in risultato, più o meno buono che sia, non fa differenza.
L’importante è che alla fine ci si trovi tutti insieme, rilassati, a fare casino col bicchiere in mano.
ありがとう!
23 Dec 2023
Un po’ di aggiornamenti di Natale, stringati non per mancanza d’entusiasmo ma perché sono leggermente sonnolento in questi giorni di ripresa natalizia. Volevo scrivere un resoconto dettagliato a caldo del RustLab 2023, a cui sono stato, ma nel frattempo mi sono anche rotto una mano, quindi principalmente diciamo che l’ultimo mese è stato dedicato al non fare altre cazzate (non più del necessario) e riprendermi.
Nonostante questo, finalmente la mano è tornata operativa e io con lei. Yay! Giusto in tempo per questo break natalizio in cui mi sto prendendo un po’ di tempo per delle pulizie:
- La CI e la CD di questo blog finalmente non usano più un workflow accroccato dal sottoscritto ma fanno leva principalmente sul “nuovo modo” di fare i deployment di GitHub Pages. Sostanzialmente fai la build, crei uno zippone con l’artefatto, e spari tutto su. La differenza col metodo di prima è che adesso tutta la parte di “sparare” e la parte dello “zippone” sono astratte da un paio di bellissime action pronto-cassa.
- Talisman, un progettino che ho iniziato l’anno scorso per vedere se riuscivo a scrivere un ricettario usando l’event sourcing, è più o meno pronto per essere usato in alpha. Ovviamente non ho scritto una riga di documentazione, ma dato il punto a cui è il progetto forse dovrei.
- Sto approfittando anche per delle pulizie di Natale su Trento, specialmente sul repository della dashboard. Lo diciamo sempre coi colleghi e alla fine non lo facciamo mai, ma prima o poi dovremmo organizzare degli stream su Twitch in cui lo sviluppiamo.
- Ho iniziato a pensare a una suite di test per Pacnews ma ho bisogno di digerire le varie idee che mi sono venute in mente.
Dovrebbe esserci tutto. Direi che il prossimo post sarà quello dell’ultimo dell’anno, come al solito. ;-)
29 Sep 2023
Finalmente dopo un sacco di tempo sono riuscito a mettere insieme una serie di coincidenze astrali una dietro l’altra. Non la farò molto lunga: porterò una serie di talk dedicati al progetto che sto seguendo ormai da un bel po’ di tempo, SUSE Trento, presso platee (e relative manifestazioni) che mi stanno particolarmente a cuore:
- RomaJS, 18 ottobre: “React… to what exactly?” - ovvero come ho trasformato il mio team, pieno (più o meno) di irriducibili del kernel hacking in una brigata di frontend engineer affezionatissimi a React;
- Linux Day Roma 2023, 28 ottobre: “SUSE Trento Compliance Engine under the hood” - ovvero un excursus sul motore di check di Trento, quali sono le premesse da cui siamo partiti per svilupparlo e come abbiamo applicato il paradigma di sviluppo di un gioco di ruolo online multiplayer per farlo nascere.
Se girate intorno a Roma in quei giorni segnatevi una delle due date, perché di sicuro durante quest’anno io e il mio team abbiamo bestemmi ci siamo divertiti tantissimo, e vorrei riuscire a trasmettervi questa senzazione di persona :-D
03 Jun 2023
Ieri notte ho letto nel mio feed reader la notizia che Red Hat non manterrà più nessun pacchetto RPM relativo alla suite d’ufficio LibreOffice, per via di una riorganizzazione delle risorse e di una ottimizzazione che allocherà praticamente tutto lo staff disponibile a implementare un sacco di “goodies” dentro lo stack grafico del sistema operativo, tra cui il supporto all’HDR e ovviamente (ma non troppo) chiudere il gap tra Wayland e X.
Devo ammettere che sono stato parecchio stupito dal non aver letto troppi pareri negativi rispetto a questa decisione: di stracci ne sono volati pochi nelle scorse ore, e stamattina sono stato anche sorpreso da un post di Jorge Castro che fa una riflessione piuttosto accurata su questa decisione in particolare e tutto l’ecosistema che ne è a supporto.
Coincidenza delle coincidenze, tutto questo sta accadendo nemmeno una settimana dopo che ho cominciato a sperimentare a casa con un laptop d’avanzo che avevo e openSUSE MicroOS. Ovviamente questa congiunzione astrale mi ha stimolato un paio di riflessioni.
Flatpak, our lord and savior
La triade leggendaria delle soluzioni per installare applicazioni “grafiche” containerizzate (e impacchettate staticamente) su Linux è composta da Flatpak, Snap e AppImage. Onestamente Flatpak è l’unico che mi abbia dato una user experience decente, è supportato estremamente bene da SUSE, e se uno non vuole esplorare quello che c’è sotto il cofano si integra con GNOME e KDE come un cittadino di prima classe.
Sul laptop aziendale ho praticamente qualsiasi applicazione grafica installata tramite Flatpak, e devo dire che anche come sviluppatore non mi ci sono trovato male: quando si è trattato di distribuire NewsFlash è stata una scelta che ha pagato tantissimo perché praticamente una volta fatto il bump della versione e costruito l’artefatto si ha un pacchetto che funziona su qualsiasi distribuzione. In caso di richieste di supporto, a meno di build da AUR per gli utenti Arch Linux, più o meno sai che cosa sta succedendo sotto al cofano. Sono sempre stato un grande fan del packaging per le distro, ma questo per gli sviluppatori è semplicemente… come dovrebbero funzionare le cose.
MicroOS, immutabilità e tutto il resto
Flatpak è solo uno degli ingredienti del futuro(tm) dei sistemi operativi: il suo degno compare è un sistema di base come MicroOS, che ho provato questa settimana, cogliendo l’occasione per testare la nuovissima openSUSE Aeon. Attraverso un layer immutabile che fa da base system e le applicazioni eseguite attraverso OStree (ossia Flatpak) si raggiunge un estremo grado di isolamento tra quello che c’è “sotto” e quello che c’è “sopra”.
Se per le applicazioni grafiche abbiamo Flatpak in user mode che ci consente di installare questi “pacchettoni” con i programmi all’interno, esattamente come avviene ad esempio su MacOS (avete mai provato ad aprire un file .app?), per la nostra developer toolchain e qualsiasi tool da riga di comando di cui abbiamo bisogno possiamo utilizzare distrobox, uno strumento che non mi ero mai filato fino all’altro ieri e del quale una volta presa un po’ la mano non penso che riuscirò mai più a fare a meno. È facile da usare, e il livello di granularità che permette è infinito: possiamo avere un solo container con tutto quello di cui abbiamo bisogno, oppure separare il nostro tooling progetto per progetto e avere decine di container, ognuno ritagliato appositamente per quello che ci serve. Ogni ambiente, che monta trasparentemente la nostra home, è a un distrobox enter
di distanza.
In questo modo MicroOS diventa un affidabilissimo base system di quartiere, che semplicemente a ogni aggiornamento si “spacchetta” dove gli compete, lavorando in completo isolamento rispetto ai workload che ci girano su.
Inutile dire che questa compartimentalizzazione estrema fa sì che i malfunzionamenti introdotti da package “meno supportati di altri” siano minimi. Sicuramente questo tipo di outage non ha più effetto sul sistema operativo in sé, ma solo, magari, nello specifico di un container di podman (di cui distrobox fa uso) o qualche Flatpak ballerino.
Solo un dettaglio implementativo, ovvero il futuro dei sistemi operativi
Il 22 dicembre del 2011 è uscito su ZDNet “Why the Operating System is becoming irrelevant”, un articolo che metteva a nudo come l’open source permettesse un’omogeneizzazione della disponibilità di software tra sistema e sistema. Allo stesso modo sul blog di Flameeyes nel 2017 è stato trattato come le differenze tra distro e distro si stessero assottigliando sempre di più.
Nel cloud è già così: ormai il base system di un container è niente più che un FROM
dentro un Dockerfile o qualcosa di simile. Niente più che un dettaglio implementativo che assume importanza solo se lo si guarda da estremamente vicino, senza prendere in considerazione che un artefatto è la somma delle parti che lo compongono. Sul desktop stiamo arrivando allo stesso tipo di paradigma: un filesystem immutabile alla base di tutto è davvero così importante se poi le applicazioni che vengono eseguite sono tutte, nessuna esclusa, containerizzate e statiche?
Ha davvero così tanta importanza che io utilizzi una o l’altra distro se poi le “scatole” che ci stanno sopra non hanno nulla a che fare con il sistema di base?
A questo punto il sistema operativo perde la rilevanza che aveva e ne assume piuttosto una tutta nuova: le scelte tecnologiche vengono analizzate sotto l’unica lente della stabilità, in pratica. Il ruolo tutto nuovo del sistema operativo ad oggi e per il futuro è essere una roccia senza nessun tipo di crepa nei confronti dei workload containerizzati.
Vedremo nei prossimi anni come andrà a finire. Sono molto curioso.
Per ora ho solo l’enorme tarlo in testa di sostituire il sistema operativo che ho sulla mia workstation con MicroOS.