Ho comprato un portatile nuovo, ovvero come ho configurato Arch Linux sul mio Thinkpad X1 Extreme

Il mio MacBook 13 ormai anche per i compiti più banali risultava un po’ lento e bolso, quindi avevo iniziato ad accarezzare da tempo l’idea di cambiare non solo portatile, ma anche direttamente sistema operativo. Visto che l’esperienza del ritorno a Linux è stata più che proficua (e non ho nemmeno raccontato tutto quello che c’è stato nel frattempo) ormai Mac OS era lontanissimo dall’uso anche più banale che potessi fare di un computer¹, quindi ho deciso di fare una scelta altrettando costosa (forse?) ma diametralmente opposta rispetto a quello che i Mac sono adesso, almeno fino a quest’ultima generazione.

Dato che avevo avuto un Thinkpad T14 aziendale con cui mi ero trovato da dio, e dato che SUSE mi ha equipaggiato con una workstation serie P che sta veramente facendo il suo, mi sono voluto concedere un altro Thinkpad per allargare la collezione, per soddisfare il mio ego nerdico e semplicemente perché ne volevo uno personale che non pesasse tantissimo.

Facendo qualche compromesso ho trovato su eBay un Thinkpad X1 Extreme di prima generazione, messo all’asta in maniera praticamente fallimentare, tant’è che me lo sono portato a casa per niente, soprattutto considerati i 64GB di RAM che si porta in pancia. Il consiglio di prendere un usato in buono stato su eBay l’ho mutuato da un video di Riccardo Palombo, che ringrazio per la dritta indiretta.

Il setup è veramente impressionante, 64 giga di RAM a parte (che comunque mi serviranno ere geologiche per saturare, nonché svariate macchine virtuali), lo schermo 4K è una goduria, così come tutto il comparto costruttivo della macchina e la CPU a 4GHz e 3, purtroppo Intel. Il trackpad, venendo da anni di Macbook, non è niente di che ma almeno supporta lo scrolling col doppio dito e due differenti tipi di click (destro e sinistro); per tutto il resto in realtà se giochiamo un po’ con la configurazione del sistema operativo possiamo fare anche di meglio.

Dico così perché in realtà rispetto al mio post di tantissimo tempo fa (ormai) sono passato ad una configurazione con i3 come window manager sul mio fisso. Questo permette tantissima flessibilità, specie per gli utenti più smaliziati. Workspace programmabili, shortcut per ogni gusto, il tiling che - devo dire - per un ossessivo compulsivo è “never go back”. E infatti.

Purtroppo i3 però litiga un po’ con i display ad alta risoluzione, quindi con qualche pacca in più sono riuscito ad approntare un setup con Sway come gestore di finestre e Wayland come server grafico. Il motivo è che in questo modo non ho bisogno di configurare il fattore di scaling per le applicazioni, ma ci pensa direttamente Sway configurando il fractional scaling direttamente a livello di server grafico.

Il risultato

Alla fine della fiera il risultato di un paio di giorni di deep dive (tra cui la lettura di pezzi di codice di Sway, poi leggerete perché) è il seguente:

• Sistema operativo: Arch Linux (ancora una volta con systemd-boot come bootloader)
• Login manager: SDDM
• Window manager: Sway
• Statusbar: Waybar
• Terminale: Kitty
• Demone per le notifiche: Mako
• Hotkey daemon aggiuntivo: Hawck

Bestemmie varie ed eventuali, ma soprattutto sonore

Due cose mi stanno facendo impazzire di questo laptop:

• Nel mio viaggio ho incontrato un bug di Sway: il resume dalla sospensione ha qualche imperfezione per cui si incastra il riconoscimento degli input, che si traduce in un più pratico “niente tastiera”. Mi sono promesso di aprire una issue direttamente sul repo di Sway, ma per il momento mi sono scritto una unit systemd che post-sleep fa il restart del demone per gli hotkey che sto usando. Siccome Hawck poi cattura tutti i metodi di input a un livello molto basso, funziona. Non funziona sempre sempre, ma quanto basta per non farmi uscire di testa e per rientrare nei miei criteri di affidabilità.
• La tastiera ha veramente qualcosa che non va, nel senso che performa molto bene ma il precedente proprietario ha pensato bene di farci qualche rituale satanico per cui ha ricoperto i tasti con dei, boh, sovratasti?² Fatto sta che la retroilluminazione perde la metà dell’efficacia per via delle nuove lettere che si vanno a sovrapporre a quelle trasparenti soffocando la luce. Probabilmente cambierò la tastiera presto, anche perché mi sembra che la spacebar faccia un po’ fatica.

Escluse queste due piccolezze, in realtà questo è davvero il laptop migliore che abbia mai avuto, sufficientemente bello da poterlo portare in giro come un pezzo d’orgoglio nerd e sufficientemente robusto in termini di specifiche da poterci lavorare dappertutto senza dovermi preoccupare di niente. La batteria non è particolarmente durevole, ma non mi aspettavo altro da un laptop costruito per le performance scevre da qualsiasi compromesso.

E devo dire che, per ora, questo Thinkpad mantiene ogni promessa.

SUSE Week #2

Devo dire che nemmeno io mi aspettavo una reazione del genere da me stesso, ma a due settimane e spicci dalla mia assunzione in SUSE mi sento come uno scolaretto delle medie che esce con quelli del liceo - e devo ammettere che ho non poca difficoltà a commentare questi primi giorni senza scadere nel “sono due settimane e tutto va bene” da una parte, e nel “ommioddio mi hanno regalato un sogno” dall’altra. :-D

Recinti per dinosauri

Non so se è vero gergo informatico, ma da piccolo lessi un bellissimo thriller di Jeffery Deaver intitolato Profondo Blu, in cui ricorreva l’espressione “recinto per dinosauri” che stava a identificare grosse sale piene di mainframe e di server. Questa cosa mi è rimasta impressa a fuoco nel cervello fino a oggi, e devo dire che pur lavorando in larga parte con il cloud o comunque in SSH e quindi non vedendo tanta di questa infrastruttura fisica di persona, lavorare a contatto con dei cluster SAP dà molto l’idea di quel tipo di computing.

Un cluster SAP ha dei requisiti hardware immensi, specialmente in termini di memoria, e se c’è qualcosa di più assurdo e alieno del leggere la documentazione di SAP è sicuramente leggere la nostra documentazione su come far scalare orizzontalmente e verticalmente le istanze. Sarà bizzarro e retrogrado, ma è un mondo nuovo e mi eccita. Sono fatto così.

The real job

In larga parte il mio lavoro consiste nel contribuire a Trento, che è una web application deputata a essere un pannello di controllo omnicomprensivo di nuova generazione per gli operatori SAP. È una sfida diversa da tutte quelle che ho incontrato sinora, innanzi tutto perché non è un software as a service e quindi ha problematiche leggermente diverse, dato che non valgono tutte le solite premesse quando si parla di temi come l’observability (principalmente perché l’infrastruttura dove viene deployato il prodotto non è la tua, quindi non sai niente di cosa ci sia dall’altra parte).

Il progetto è fresco e pieno di sfide, oltre che open source, quindi se avete qualcosa da dirci chiaramente qualsiasi pull request è benvenuta!

Pezzi di storia

Chiaramente per una persona come me, costantemente affascinata dalla storia dell’open source, entrare in un’azienda che ha l’open source nel DNA è un’esperienza estremamente particolare. A tutto ciò aggiungiamoci anche che sono entrato proprio a ridosso del ventinovesimo compleanno di SUSE, e la frittata è fatta :-)

In vari luoghi come Slack o le mailing list interne (di cui alcune piene di nomi giganti dell’open e di contenuti da infarto) hanno cominciato a piovere pezzi di storia come le prime mail dove veniva menzionata la distribuzione che annoverava tra le sue principali caratteristiche il supporto alla traduzione tedesca in tutto il sistema, oppure foto delle varie torte commemorative tra cui quella del venticinquennale a forma di server, che potete vedere in copertina.

Insomma, chiaramente so di sembrare un idiota che si piscia addosso per cose come queste, ma devo dire che è la prima volta che mi capita di essere così dentro uno dei pilastri di Linux per lavoro.

Questo anche per dire che chiaramente di aggiornamenti del genere ve ne beccherete altri, mi dispiace :-D

Hello, SUSE!

Quando ero piccolo mi capitava spesso che mi chiedessero che mestiere volessi fare da grande, banalmente perché è una domanda che si fa ai bambini. Non penso che valga la pena di riportare su queste pagine la tracotanza smodata delle mie ambizioni di cinquenne, ma in questi giorni ho ripensato a un’altra occasione di questo tipo molto più recente. Avevo all’incirca sedici anni, e stavo parlando con mio padre in maniera più concreta di quali fossero le mie inclinazioni: mi ricordo che proprio qualche ora prima avevo finito di aggiornare una pagina wiki di qualche software che stavo usando, e gli dissi “guarda papà, se fosse possibile io vorrei lavorare con queste aziende che fanno tutta ‘sta roba di Linux”.

Fast-forward a quasi quindici anni dopo: vedo che SUSE sta aprendo una carrellata di posizioni in Europa piuttosto interessanti, specialmente una in linea con le mie abilità attuali, e mi candido più per gioco che per altro.

Ho iniziato a fare i colloqui senza una reale aspettativa, sapevo che il clima del team e del portfolio erano buoni, avevo un amico che era stato assunto da poco in una posizione simile¹, quindi non posso dire di essermi candidato col più vivo dei sentimenti. Il mio morale era a dire il vero piuttosto basso, per tutta una serie di motivi.

Quello che poi è successo però è che ho avuto una chiamata di primo contatto, poi altre call per i colloqui veri e propri, e ogni passo aggiungeva un po’ di fregola e di emozione perché mi sembrava un po’ impossibile. Ad oggi, invece, posso dirlo fieramente.

Il primo settembre ho iniziato il mio viaggio con SUSE come Senior Software Engineer, Web Development, ed è una grossissima emozione per me che in questi giorni mi sento come un bambino in un negozio di caramelle. Probabilmente è stupido da parte mia, me ne rendo conto, ma avendo utilizzato Linux per metà della mia vita e avendone sempre appoggiato soprattutto gli aspetti filosofici chiaramente non posso negare che tutto questo per me abbia un peso enorme.

Avendo già scritto cinque pallosi paragrafi su quanto sia felice di tutto questo, l’unica cosa che posso dire è che non vedo l’ora di “have a lot of fun” :-)

Recensione: Domain Modeling Made Functional, di Scott Wlaschin

Ed eccoci qui con una nuova recensione: in questo periodo oltre a ripassare le basi ho deciso di rendere leggermente più formale la mia preparazione in termini di functional programming, specialmente nei termini di quella zona grigia che è il punto di contatto tra il mondo accademico, come viene tradotta una dimostrazione in codice (che è davvero dove un linguaggio fortemente espressivo dà il suo meglio) e il mondo del business, in particolare delle applicazioni web, dove questi principi di design possono aiutare a far crescere una codebase nella maniera più pulita possibile - soprattutto guardando al codice attraverso la lente del tempo.

Domain Modeling Made Functional viene in nostro soccorso proprio per assisterci durante alcune scelte all’inizio di un nuovo progetto, dotandoci di un po’ di disciplina, insegnandoci un po’ di Domain-Driven Design, e mostrandoci senza troppi giri di parole come il DDD viene espresso al suo meglio attraverso la programmazione funzionale.

Grossomodo il discorso viene portato avanti attraverso vari punti, primo tra cui il type system di un linguaggio funzionale. Nel libro viene usato F#, personalmente ho trovato che tantissimi esempi si adattassero al modo che il manuale e il compilatore di Rust consigliano di trattare il codice, specialmente nella gestione dei side-effect (usando i Result). Dalla descrizione del type system viene poi srotolata un po’ di roba utile, come il fatto di usare le firme delle funzioni non tanto come rete di sicurezza a compile-time quanto come una buona documentazione mantenuta in tempo reale di come funziona il dominio.

A quel punto, avendo un dominio descritto in maniera type-driven e le cui funzioni utilizzano una raccolta di tipi ben definita, si passa ai side effect: validazione, parsing, gestione degli errori attraverso il imodello two-track¹, chiamata di API esterne, persistenza.

Tutto questo senza minimamente menzionare² monadi, funtori, applicativi, o altra roba arcana che il lettore non avrebbe nemmeno la forza di approfondire; il vero valore di questo volume è tenere un approccio estremamente semplice, abbandonando i concetti accademici fuori dalla porta e concentrandosi esclusivamente sui benefici di un approccio di questo tipo, risultando in questo modo un super-pregevole distillato di buonissime pratiche che scorre estremamente veloce nella lettura e soprattutto nell’apprendimento.

Un grazie speciale va a Emanuele De Cupis, che me l’ha consigliato.

Se lo volete comprare, questa è la pagina del libro sulla Pragmatic Bookshelf: non c’è modo migliore di spendere i vostri soldi, e potete stare sicuri del fatto che sia un consiglio sincero perché non ci rimedio una lira :-)

Kubernetes production-ready in piccolo: deployare un mini-cluster K3s

Qualche settimana fa mi ha amabilmente scritto il cloud provider presso cui è ospitato il cluster Kubernetes di produzione di AllaCarta informandomi del fatto che la beta del loro servizio Kubernetes managed (che ho provato ~a scrocco~ in anticipo fornendo dei preziosi feedback) sta giungendo a una fine. Dopo attimi di panico, mi sono appuntato tre strade possibili da vagliare:

• Rimanere col provider attuale, pagando, continuando a usare Kubernetes. Non ho tuttavia voglia di diventare povero, per quanto i loro costi siano molto più prevedibili di qualsiasi piattaforma cloud “mainstream”. In fin dei conti, davvero impraticabile. Dato che AllaCarta è gratis a oggi, devo tagliare tutti i costi il più possibile. :-D;
• Migrare a un metodo di deployment più tradizionale riutilizzando i playbook Ansible scritti in precedenza;
• Deployare un cluster Kubernetes per conto mio e provare a riapplicare tutta la configurazione del mio cluster di prod.

Marcata come non fattibile la prima alternativa, ho passato una settimanella a cercare di far fare briscola ai miei playbook Ansible con le nuove macchine di staging che avevo deployato, ma ce n’era sempre una tra versioni che non andavano più bene e altro. L’altra sera, così, in preda a un raptus, ho deciso di provare davvero a vedere se deployare un cluster K3s mononodo di test fosse una cosa proibitiva a livello di sforzo e know-how richiesto.

Ho scoperto che invece basta loggarsi su una macchina appena deployata e dare questo comando:

$ curl -sfL https://get.k3s.io | sh -

In questo modo, il nostro terminale sputerà un po’ di informazioni e in pochissimo tempo avremo davvero un master node Kubernetes perfettamente funzionante a cui connetterci. K3s non è esattamente una distribuzione che include tutto quello che le distribuzioni canoniche di Kubernetes si portano dietro, ma valutando i miei bisogni ho deciso che potevo fare a meno di quelle che per me sono caratteristiche marginali.

Per connetterci al cluster da fuori abbiamo bisogno di un kubeconfig, che possiamo trovare in questo modo. Con questo comando otterremo qualcosa del genere:

$ cat /etc/rancher/k3s/k3s.yaml
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJlRENDQVIyZ0F3SUJBZ0lCQURBS0JnZ3Foa2pPUFFRREFqQWpNU0V3SHUREQmhyTTNNdGMyVnkKZG1WeUxXTmhRREUyTVRrNU1EWXdNRFF3SGhjTk1qRXdOVEF4TWpFMU16STBXaGNOTXpFd05ESTVNakUxTXpJMApXakFqTVNFd0h3WURWUVFEREJock0zTXRjMlZ5ZG1WeUxXTmhRREUyTVRrNU1EWXdNRFF3V1RBVEJnY3Foa2pPClBRSUJCZ2dxaGtqT1BRTUJCd05DQUFSRzNUY0FCVE9hTFRaT1piUG51QlFEbGNtMTAxMEw5VDF3SVR0TUR5TWIKR0s0YitHTG8xenVOQXRETE1uNjhIWlI5UTRYbFJySzJuVWJnVG1ucUhlb2JvMEl3UURBT0JnTlZIUThCQWY4RQpCQU1DQXFRd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZEJnTlZIUTRFRmdRVXZ6QlU3bUtTRUF3NFQ5RDJuOWNNCm9FQkRzVlF3Q2dZSUtvWkl6ajBFQXdJRFNRQXdSZ0lVjZzLzN6RmhkTUsxNFpENU5tRGc5ZG9zdUViOXYKaVFsdU93UHp5bmNDQWlFQWxWK2FYWCtnTENZR3dzTXJBNU1yaWkrSGl3T1hlYVJMWUIvWFAvQVR2Mm89Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://127.0.0.1:6443
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJrRENDQVRlZ0F3SUJBZ0lJZm9FNytndXpLS0V3Q2dZSUtvWkl6ajBFQXdJd0l6RWhNQjhHQTFVRUF3d1kKYXpOekxXTnNhV1Z1ZEMxallVQXhOakU1T1RBMk1EQTBNQjRYRFRJeE1EVXdNVEl4TlRNeU5Gb1hEVEl5TURVdwpNVEl4TlRNeU5Gb3dNREVYTUJVR0ExVUVDaE1PYzNmRHVnRPbTFoYzNSbGNuTXhGVEFUQmdOVkJBTVRESE41CmMzUmxiVHBoWkcxcGJqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJFMnI3ZXp0dmFnZkRhdnMKd2VhL01WclhiV3RXb0ZGc2FRaVlVTXZxMDNiZlNzdXFHWEYyTUlpRzZ1UG1uOEZwNnRMcG9vQzVQWGp4Zmo3RgpNRUxKM2FpalNEQkdNQTRHQTFVZER3RUIvd1FFQXdJRm9EQVRCZ05WSFNVRUREQUtCZ2dyQmdFRkJRY0RBakFmCkJnTlZIU010RBV2dCVFA4VDJNNHhOVmlHTlBPT0ZKOG12c1ovUjJnakFLQmdncWhrak9QUVFEQWdOSEFEQkUKQWlCd2dubFl0MUczdGtuR1NQOEViNm5UMHU5MFQvRWZJZnZNWkR2aVBtZTY0QUlnT2M0UjM0aGJqRE1xejlzbgpHY2oyTDdIcFNad1Z2Z3lXd0xhdGFzQjR6Y1k9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJkekNDQVIyZ0F3SUJBZ0lCQURBS0JnZ3Foa2pPUFFRREFqQWpNU0V3SHdZRFZRUUREQmhyTTNNdFkyeHAKWlc1MExXTmhRREUyTVRrNU1EWXdNRFF3SGhjTk1qRXdOVEF4TWpFMU16STBXaGNOTXpFd05ESTVNakUxTXpJMApXakFqTVNFd0h3WURWUVFEREJock0zTXRZMnhwWlc1MExXTmhRREUyTVRrNU1EWXdNRFF3V1RBVEJnY3Foa2pPClBRSUJCZ2dxaGtqT1BRTUJCd05DQUFTSnFaOSsyNkViZ1hVUTllRlIrWFc1eGw3OEptcGdYbHZSVzZQU2M2Q0IKUTNmRk95dkFFRkhGQ1FleGwxbS9GUkluVjVWL1pmZFN6R2pvS3ZpODMzZFRvMEl3UURBT0JnTlZIUThCQWY4RQpCQU1DQXFRd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZEJnTlZIUTRFRmdRVXovRTlqT01UVlloalR6amhTZkpyCjdHZjBkb0l3Q2dZSUtvWkl6ajBFQXdJRFNBQXdSUUlnZjh5SUdFa3JzcFhINWNTL1pmMVlEUlB5ZXJBQ01SdmwKVFNxUXBRSzJSNVlDSVFDeE10S0Y4R2xzYVRZc1AxK0xRUlFyNUZtSXVvcE81RVJjM2VXYmp3YlJGQT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    client-key-data: LS0tLS1CRUdJTiBFQyBQUklWQVRFIEtFWS0tLS0tCk1IY0NBUUVFSUs5Snkraks3SW02Wm5xUm91Z1Jsa3NsaVFjbENzQlk0NWdTZTFOaEZPWXNvQW9HQ0NxR1NNNDkKQXdFSG9VUURRZ0FFVGF2dDdPMjlxQjhOcSt6QjVyOHhXdGRtyVGR0OUt5Nm9aY1hZdwppSWJxNCthZndXbnEwdW1pZ0xrOWVQRitQc1V3UXNuZHFBPT0KLS0tLS1FTkQgRUMgUFJJVkFURSBLRVktLS0tLQo=

Come possiamo vedere, alla voce riguardante l’indirizzo del server abbiamo un affascinante 127.0.0.1 che dobbiamo sostituire con l’IP pubblico della macchina che abbiamo deployato, o con l’IP privato se stiamo dietro una bella VPN. Fatto questo, il file è effettivamente un kubeconfig valido che possiamo salvare e utilizzare facendolo digerire al nostro kubectl. Ci sono vari modi per farlo che spero conosciate; non ho intenzione di ammorbarvi in questa sede spiegandovi quale è il mio preferito.

Dopo qualche secondo, con un kubectl get all dovremmo poter vedere le risorse dentro il nostro cluster mononodo appena deployato, che giustamente saranno prossime allo zero. Prima di iniziare a deployarci delle applicazioni sopra potremmo guardare se è il caso di attaccare al nostro master node qualche worker node in modo da consentire al nostro sistema un po’ di respiro se lo vogliamo far andare a regime.

È necessario innanzi tutto scoprire quale è il token per connetterci al nostro master node:

$ sudo cat /var/lib/rancher/k3s/server/node-token
K10361c7ecce9548dc6b5d1fc32e69b42eeb6e8d00d5e097923d83b9b4604277a9d::server:c44ecc6b22fdd6d7d08ea321798150f8

Dopodiché possiamo tranquillamente deployare un’altra istanza su un’altra macchina informandola di questo token e dell’URL del master node in modo che ci si vada a connettere:

$ export k3s_master_url="https://k3s-master:6443"
$ export k3s_token="K10361c7ecce9548dc6b5d1fc32e69b42eeb6e8d00d5e097923d83b9b4604277a9d::server:c44ecc6b22fdd6d7d08ea321798150f8"
$ curl -sfL https://get.k3s.io | K3S_URL=${k3s_master_url} K3S_TOKEN=${k3s_token} sh -

Con un kubectl cluster-info dovremmo vedere che il nostro nodo nuovo di pacca ha fatto il suo lavoro. A questo punto possiamo iniziare a giocarci, scrivendo la configurazione di cui abbiamo bisogno nei nostro file YAML e applicandola con kubectl apply -f. Questo procedimento usa K3s e un hosting a basso costo, ma con un po’ di fine tuning (soprattutto andando a parare su un hosting più affidabile per le macchine) possiamo deployare i nostri nodi in questa maniera anche in produzione¹. Personalmente ancora non ho trovato feature mancanti dentro K3s per progetti piccoli che mi facciano dire “no, K3s non va bene anche per applicazioni di media portata”; per quanto riguarda AllaCarta, soprattutto, questo setup e un po’ di hardening hanno decisamente salvato la giornata e mi hanno permesso di non rinunciare a un modo di lavorare molto più reattivo a cui ormai mi ero piuttosto assuefatto.