Linux on Melabit

Addio dc, benvenuta luka: una nuova calcolatrice RPN da Terminale

Sat, 09 Aug 2025 06:00:00 +0000

La Notazione Polacca Inversa (o RPN, dall’inglese Reverse Polish Notation) è un modo per eseguire operazioni matematiche senza usare le parentesi. Negli anni ‘70-80 l’RPN fu resa popolare da Hewlett-Packatd (HP), che l’utilizzò in tutte le sue calcolatrici scientifiche e finanziarie.

Con le calcolatrici della rivale Texas-Instruments, che usavano le parentesi, era facile perdere il conto di quante parentesi si erano aperte o chiuse, cosa che costringeva spesso a reinserire l’intera espressione dal principio. Chi usava una calcolatrice RPN non aveva questi problemi, anche se doveva superare un piccolo scoglio iniziale per abituarsi alla nuova notazione.

Oggi le calcolatrici fisiche sono poco usate, e quasi tutti preferiscono utilizzare un’app sul telefono o sul computer. Ma c’è ancora qualche nerd impenitente che non si arrende all’interfaccia grafica e si ostina ad usare il Terminale. Perché? Ad esempio, perché è molto più facile inserire numeri e operazioni complicate con la tastiera, che premere i tasti di vetro di una calcolatrice virtuale.

Premessa

Se avete fretta e non volete sobbarcarvi la lettura di questo lungo articolo, troverete tutte le informazioni che vi servono in questo post, sintetico ma come sempre brillante, su Quickloox, uno dei blog di riferimento per chi è appassionato del mondo Apple.

– Immagine generata da Google Gemini.

Un po’ di storia

La Polonia ci ha dato Niccolò Copernico, Fryderyk Chopin, Joseph Conrad, Marie Curie, Arthur Rubinstein, Stanislaw Lem. Ma ci ha dato anche Jan Lukasiewicz, un logico matematico (e filosofo) che cent’anni fa inventò una notazione matematica che non faceva uso di parentesi.

In questa notazione polacca tutti i simboli di operazione ( \( + \), \( - \), \( \times \), \( / \) ) precedono i numeri a cui si applicano. Lo stesso vale più in generale per le funzioni matematiche, come \( \sqrt{} \), \( \sin \), \( \cos \), \( \exp \) (dette operatori) e i numeri o le variabili (dette operandi) su cui agiscono.

Ad esempio, una operazione come \( 3 + 4 \), in notazione polacca viene scritta \( + \ 3 \ 4 \), mentre \( (5 + 2) \times (5 - 2) \) diventa \( \times + 5 \ 2 - 5 \ 2 \).

Per molti anni questa è rimasta solo una idea un po’ bislacca, perché il vantaggio di non usare le parentesi non sembrava compensare a sufficienza la notazione inusuale e più difficile da leggere.

Poi alla fine degli anni ‘50, John McCarthy rispolverò la notazione polacca (o prefissa) per il LISP, uno dei linguaggi di programmazione più influenti di tutti i tempi,¹ sviluppato con l’obiettivo di essere applicato allo sviluppo di programmi nell’ambito della nascente intelligenza artificiale.

La notazione prefissa, infatti, non solo semplificava notevolmente la scrittura dell’interprete LISP, ma permetteva anche di rappresentare allo stesso modo sia il codice che i dati, una cosa utilissima per un linguaggio finalizzato a rendere in computer intelligente. Ma meglio non divagare troppo.

Notazione polacca inversa

Ma la vera svolta avviene invertendo l’ordine fra operandi ed operatori, cioè scrivendo prima i numeri e poi le operazioni da eseguire, per cui \( 3 + 4 \) diventa \( 3 \ 4 \ + \) e \( (5 + 2) \times (5 - 2) \) diventa \( \ 5 \ 2 + 5 \ 2 - \times \).

Questa notazione polacca inversa (RPN) viene scoperta e riscoperta per almeno tre volte in vent’anni, ma diventò popolare solo all’inizio degli anni ‘60 quando Friedrich Bauer, inventore del concetto di stack e uno degli sviluppatori dell’ALGOL, e Edsger Dijkstra, famoso per la soluzione del “problema del cammino minimo” e per mile altre cose, ripresero in mano il concetto, perché permetteva di ridurre l’accesso alla memoria, che nei computer dell’epoca era scarsa e lenta, e di eseguire tutte le operazioni in un’area di memoria bene definita (lo stack) e per questo più facile da manipolare.

I vantaggi dell’RPN per eseguire i calcoli matematici erano così evidenti che HP la utilizzò in praticamente tutte le sue calcolatrici scientifiche e finanziarie, almeno fino all’inizio degli anni ‘90. Solo con lo sviluppo di memorie più capienti e di display molto più grandi divenne possibile visualizzare e modificare facilmente l’intera operazione impostata – e non più solo l’ultimo numero inserito – rendendo così meno necessario l’uso dell’RPN.

Una calcolatrice nel Terminale

Chi vuole usare una calcolatrice tradizionale nel Terminale di macOS o di Linux ha una scelta pressoché obbligata: bc, il basic calculator, presente in UNIX dal 1975, 50 anni filati. La versione attuale, disponibile su Linux e macOS, è stata completamente riscritta, ma quella originale era solo una interfaccia per dc (desk calculator), una delle più antiche utility presenti in UNIX e più vecchia persino del C.

E dc era… una calcolatrice RPN. Una scelta che confermava l’intuizione di HP: la notazione RPN era più efficiente e più semplice da implementare, e quindi ideale anche per i computer dalle risorse limitate degli anni ’70.²

Oggi l’RPN non è più una scelta quasi obbligata dalle limitazioni hardware, ma direi una scelta motivata soprattutto dalla pigrizia. Perché, una volta che si è spesa una mezz’oretta per imparare ad usarla, si scopre che è davvero molto più comodo eseguire i calcoli con questa notazione piuttosto che con quella tradizionale.

E poi forse c’è anche un certo gusto per andare controcorrente: in un mondo in cui tutti si uniformano ai dettami degli influencer (veri o presunti) sui social, usare una calcolatrice RPN diventa un modo per distinguersi, per sentirsi fuori dal coro, quasi una dichiarazione di indipendenza intellettuale.

dc è ancora presente in Linux e macOS e può essere tranquillamente usata dal Terminale, ma è una bella fatica, i suoi cinquant’anni si sentono (e si vedono) tutti. I risultati delle operazioni non si vedono, a meno di non stamparli sullo schermo con p. Nemmeno lo stack si vede, a meno di non chiederlo esplicitamente con f. I numeri negativi si indicano con l’underscore _ e non con il normale -, per cui \( - 4 \) si scrive \( \_4 \). E così via.

Ma da oggi c’è dc2 o meglio, luka.

La calcolatrice RPN del XXI secolo

E sì, perché da qualche settimana abbiamo a disposizione una nuova calcolatrice RPN per il Terminale di macOS di Linux, chiamata inizialmente dc2, in omaggio alla veneranda calcolatrice ormai ultracinquantenne.

Però dc2 sapeva troppo di una riscrittura dell’originale, mentre questo è un progetto completamente nuovo, scritto da zero in C. Meritava quindi un nome tutto suo, luka, in omaggio a Jan Lukasiewicz, l’inventore della notazione polacca (si veda il riquadro qui sopra).

Rispetto a dc, luka è davvero di un’altro secolo, e si vede appena si inizia a provarla. È interattiva, mostra in ogni momento il contenuto dello stack, ha la storia delle operazioni eseguite, le variabili, un help sintetico ma completo in linea, una pagina di manuale cristallina (ce ne fossero tante altre così!).

E poi luka è fatta in Italia. In tempi in cui si esalta l’identità nazionale per i motivi più futili, è bello vedere qualcosa che merita davvero di essere valorizzato.

Il programma in questo momento ha un piccolo bug legato alla visualizzazione dell’history, ma l’autore macina il codice molto più velocemente di quanto io macini le parole, per cui è più che probabile che il bug sarà corretto al più presto (vacanze permettendo).

Evoluzione del codice

Lo sviluppo di dc2/luka è stato rapidissimo. Dietro al progetto c’è Davide Mastromatteo, noto fra i suoi amici di penna come @mastro35 e autore dell’ottimo blog The Python Corner.

In pochi giorni Davide è passato dalla versione 0.1.0, perfettamente funzionale ma con una interfaccia utente ancora acerba,

alla versione 0.2.0, con una vista dello stack molto più chiara, la possibilità di usare gradi e radianti e di cambiare il formato di rappresentazione dei numeri, nonché con un help più compatto.

La versione 0.3.0 ha introdotto l’history delle operazioni eseguite e un help ancora rivisto,

mentre la versione 0.4.0, che è coincisa con il cambio di nome del programma, ci ha portato le variabili e parecchi nuovi comandi da tastiera, come si può vedere nelle prime immagini di questo articolo.

Usare luka

Installare luka sul Mac o su Linux è un attimo, almeno per chi usa homebrew (e chi non lo usa dovrebbe iniziare a farlo subito)

brew install mastro35/homebrew-mastro35/luka

Altrimenti basta scaricare l’ultima release del codice sorgente, scompattarla ed eseguire

make clean && make

dal Terminale, ovviamente dopo essersi spostati nella directory che contiene il codice sorgente.³

Inutile dire che chi ha installato make e un compilatore C su Windows, potrà compilare luka anche su questo sistema operativo.

Dimenticavo: presto arriveranno i pacchetti per Linux, in formato deb e rpn e, chissà, magari anche aur. E forse anche un installatore per Windows.

Sull’uso vero e proprio della calcolatrice c’è poco da dire. Chi conosce già l’RPN si troverà a suo agio, e ci metterà pochissimo ad usare luka al meglio. Chi non conosce l’RPN magari avrà voglia di provarla, per toccare con mano quanto sia più comodo eseguire un calcolo appena appena complicato con una calcolatrice RPN piuttosto che con una normale calcolatrice algebrica.

Di guide all’RPN ce ne sono a iosa, purtroppo sono tutte orientate a spiegarne l’uso con una calcolatrice fisica, come le ormai mitiche HP vintage, oppure con le emulazioni grafiche per Android o iOS.⁴

Rispetto a queste guide ci sono alcune differenze da considerare. La principale è che, non avendo i tasti fisici, luka (ma anche dc) richiede che si prema ogni volta ENTER per inserire un numero o una funzione. Anche alcuni nomi di funzioni sono diversi, così come i comandi per gestire lo stack o per salvare e recuperare le variabili. Ad esempio luka usa store e load per le variabili, mentre le calcolatrici fisiche o emulate usano dei tasti denominati in genere STO e RCL (ma se l’autore legge questo articolo forse cambierà idea 😂). Ma, a parte questi dettagli, la logica di fondo non cambia.

Da parte mia, ho provato in tutti i modi a far andare luka in crash, e non ci sono mai riuscito. Ho provato a fargli calcolare il fattoriale di numeri assurdamente grandi o piccoli, a dividere per zero, ad eseguire il famigerato \( 0 / 0 \) e poi a calcolare il reciproco del risultato. Ma niente, imperturbabile mi ha sempre dato il risultato esatto. Insomma, la qualità c’è.

Conclusioni

Provare luka non costa niente. Si installa (e disinstalla) in pochi secondi, funziona su macOS, Linux e, per chi vuole, anche su Windows. I risultati che produce sono esatti (e questa è la cosa che conta di più). Lo sviluppatore è bravo ed aperto ai suggerimenti. Insomma, è uno strumento ideale per chi vuole eseguire dei calcoli dal Terminale.

Certo, è uno strumento di nicchia, destinato a pochi utenti sofisticati che apprezzano la notazione RPN e non hanno paura del Terminale. Ma proprio per questo ha un fascino tutto suo.

E poi, vuoi mettere la bellezza di vedere un programma che evolve davanti ai nostri occhi, magari partecipando allo sviluppo con suggerimenti o critiche?

Ed uno dei pochi linguaggi di programmazione, assieme a FORTRAN e COBOL, ad essere ancora vivo e vegeto. ↩︎
Non a caso, uno dei linguaggi di programmazione più efficienti in assoluto è il FORTH, che si basa sullo stack e sull’uso dell’RPN. ↩︎
Come, non avete nemmeno make? Allora correte ad installare homebrew! ↩︎
Per quest’ultimo consiglio senza riserve PCalc Lite o meglio ancora la versione full Pcalc, che costa quanto un panino e una minerale al bar. In alternativa WP 34s, che riesce a compattare tutto in una sola schermata, oppure i41CX, perfetta per chi a suo tempo sognava di averla. ↩︎

Da melabit a melabit: Jekyll e l'hosting

Tue, 18 Mar 2025 06:00:00 +0000

– Fonte: Scott Rodgerson su Unsplash.

Come promesso (o minacciato?) nell’ultimo articolo, quest’ultimo post è dedicato ad esplorare le opzioni disponibili per l’hosting di un sito web basato su Jekyll (o su qualsiasi altro generatore di siti statici) destinato ad ospitare il nostro blog personale (come quello che state leggendo), oppure il sito web di uno studio professionale o di una piccola azienda.

Tutto sommato potrei cavarmela in due righe, invitandovi a rileggere quello che avevo scritto 6-7 anni fa (qui e qui) ma sono passati tanti anni e una bella rinfrescata è d’obbligo.

Per chi volesse leggere le altre puntate dedicate alla mia transizione da Wordpress a Jekyll, ecco la lista completa degli articoli pubblicati:

Premessa

Non sono uno sviluppatore professionista, non so molto di sviluppo web e mi considero solo un dilettante per quanto riguarda la gestione di server e di reti.

Le considerazioni riportate qui sotto, quindi, sono solo delle riflessioni personali frutto di anni di esperienza e di sperimentazione nella gestione di sistemi di calcolo più o meno complessi e di servizi web ancora attivi o ormai defunti (più di uno, purtroppo). Mi auguro che le righe che seguono possano essere utili a chi sta valutando delle soluzioni simili, ma chi cerca delle soluzioni professionali deve rivolgersi a chi ne sa di più.

Perché non conviene usare un Mac

Come accennavo la volta scorsa, trovo poco sensato usare un Mac per ospitare un server web destinato a un sito basato su Jekyll (o, più in generale, per qualsiasi sito web, sia esso statico o dinamico).

La ragione è semplice: per gestire un sito con traffico moderato, un Mac è una soluzione eccessiva, un vero spreco di risorse (gli anglosassoni direbbero che è overkill, un termine che trovo particolarmente azzeccato).¹

Discorso diverso per la fase di sviluppo (io stesso ho usato un Mac per quella): avere a disposizione un sistema UNIX con una interfaccia grafica ben curata, degli editor potenti ma facili da usare, degli strumenti che semplificano la scrittura del codice e la ricerca degli errori sono vantaggi che non hanno prezzo.

E se ho un vecchio Mac che non uso più? Perché non destinarlo a gestire il mio sito?

Un vecchio Mac è ancora perfetto per scrivere, gestire la posta elettronica, navigare sul web, fare videoconferenze, comporre musica, imparare a programmare e molto altro. Ancora meglio se gli installiamo una versione recente di macOS con Open Core Legacy Patcher.

Ma usare un vecchio computer come server, da tenere acceso tutto il giorno, tutti i giorni? Non so, io non lo farei, non mi sembra una scelta affidabile. E comunque, anche volendo provarci, si ricadrebbe nel discorso più generale della prossima sezione.

Perché non conviene fare da sé

Al posto del Mac potremmo voler usare un PC, magari uno di quei gioiellini un po’ datati simili al Mac Mini che si trovano a poco più di 100 euro e che possono ancora dire la loro, come il Lenovo M95q o l’HP 800 G3. Oppure un Raspberry Pi 5 che, purtroppo, non è più conveniente come una volta, almeno se vogliamo usarlo come un semplice computer.

Come dicevo anni fa, una volta installatoci su Linux, questi minicomputer diventano perfetti “per imparare a gestire un server web e il sistema Linux associato oppure per fare delle prove con diversi CMS o generatori di siti statici prima di scegliere quello che vogliamo usare per il nostro sito”.

Non c’è nemmeno bisogno di collegarli ad una tastiera e ad un monitor, perché si può fare davvero tutto dal Terminale tramite collegamento ssh o, per chi preferisce la classica interfaccia grafica, accedendo al sistema con Chrome Remote Desktop o con uno dei tanti servizi di accesso remoto che ormai conosciamo tutti molto bene.

Ma possiamo usare questi minicomputer per gestire un sito “vero”, che deve essere attivo 24 ore su 24 e 7 giorni su 7?

Secondo me no.

Un sito web richiede la disponibilità di un indirizzo IP fisso pubblico e solo Fastweb lo offre gratuitamente, ma a certe condizioni. Gli altri provider non sanno nemmeno cosa sia, oppure bisogna sottoscrivere dei contratti specifici, che naturalmente sono più costosi dei normali contratti “home” e “business”.

Lo so, ci sono i servizi di DNS dinamico. Ma gli anni ‘90 sono passati da un pezzo, e oggi non affiderei mai i miei servizi web ad un servizio ballerino, con tempi imprevedibili di aggiornamento dell’IP. Tanto più che, se si vuole un minimo di affidabilità, si deve scucire qualcosa. E a quel punto, ne vale la pena?

Un altro problema sono le interruzioni improvvise di connessione a internet o di elettricità, magari a causa di lavori per strada, oppure perché il collega di studio o il partner ha deciso di accendere contemporaneamente tutti i condizionatori, o di usare lavatrice, forno e phon insieme.

Certo, esistono gli UPS, ma se siamo fuori ufficio o casa, dopo un po’ anche l’UPS si scarica e il nostro server si spegne.

E infine, non dimentichiamolo mai, c’è la questione della sicurezza, gli attacchi inevitabili e continui dei tanti sfaccendati che non hanno di meglio da fare nella vita. A meno di non essere già degli esperti in tema di sicurezza, siamo davvero disposti ad impelagarci in prima persona in cose che vanno ben al di là delle nostre competenze?

Cosa conviene fare da sé

Volendo fare da sé, l’opzione migliore è senza dubbio usare una macchina virtuale su uno degli innumerevoli servizi cloud, da UpCloud a Digital Ocean, oppure Heroku o Linode (ora Akamai Cloud), senza dimenticare naturalmente i grossi player come Amazon AWS e Google Cloud (ok, fra questi ci sarebbe anche Microsoft Azure). Se in questo momento non vi fidate a comprare americano, qui c’è una lista di provider cloud europei.

Una macchina virtuale sul cloud costa poco e non ha nessuno dei difetti elencati finora, a parte la questione della sicurezza, che però è gestita almeno in parte dallo stesso fornitore del servizio.

Ancora più sicuro, e pure a costo zero, è usare servizi come GitHub Pages che, ogni volta che si aggiorna un repository collegato basato su Jekyll, rigenera il sito e lo e pubblica automaticamente su github.io. La documentazione relativa è molto dettagliata, per cui è inutile che io aggiunga altro.

Cosa ho fatto io

Io sono un utente come tanti, e la soluzione che ho adottato può essere un buon esempio di come gestire in modo efficiente e relativamente economico (cosa che non guasta mai) l’hosting di un sito web, senza compromessi sulla qualità del servizio.

Questo sito è ospitato su Shock Hosting, un servizio di hosting che uso da anni e con un servizio di supporto eccezionale. In realtà in tanti anni ho avuto pochissimi problemi e sempre banali, ad esempio per una fattura pagata per sbaglio due volte, ma ogni volta la risposta del supporto non poteva essere più veloce.

Il piano base “Low Shock” da 2.99 dollari al mese offre spazio su disco e trasferimento di dati illimitati, e non impone limitazioni artificiose di velocità (tutte cosa che pochi concorrenti offrono). Questo piano è più che sufficiente per un sito statico, ma anche per un sito basato su Wordpress o altri CMS (o dico per esperienza diretta). I piani superiori sono identici a quello base, ma permettono di ospitare più domini, e passare da un piano all’altro richiede solo l’apertura di un ticket e una breve attesa.

Anche il nome del dominio è gestito da Shock Hosting e costa 12 dollari all’anno (un dollaro al mese), che è il costo normale di un dominio .com.

Naturalmente, Shock Hosting è solo uno degli infiniti servizi di hosting disponibili, anche se, per quanto riguarda il rapporto qualità/prezzo, mi sembra difficile trovare di meglio. In ogni caso, prima di scegliere vi consiglio di stare molto attenti alle condizioni di uso, perché la maggior parte dei provider pone dei limiti più o meno stringenti allo spazio su disco o alla quantità di dati trasferiti. Oppure alcuni offrono prezzi molto convenienti per il primo anno o i primi mesi, ma poi li aumentano in modo consistente. Se, prima di impegnarvi, riuscite anche a verificare come funziona il supporto è un bel vantaggio.

Altrimenti preferite un servizio che vi permette di pagare ogni mese o ogni trimestre, in modo da avere la possibilità di testare con calma il servizio e di verificare se risponde alle vostre esigenze. In seguito, potrete sempre decidere di pagare ad intervalli più lunghi.

Evitate invece come la peste i servizi che offrono sconti enormi se vi impegnate per due, tre o più anni, o per… l’eternità. Su internet non c’è niente di eterno, anzi sono proprio i servizi eterni quelli che muoiono più rapidamente. E se dovesse sucecdere avrete perso tutto quello che avete anticipato, altro che risparmio!

Il solo servizio di hosting non è sufficiente per melabit.com/posts/it, perché non permette di eseguire comma per gestire i commenti. La cosa più semplice da fare sarebbe stata passare ad usare un server virtuale, sempre su Shock Hosting, ma non mi piacciono le cose semplici. E poi il servizio di hosting offre dei vantaggi che non volevo perdere: si occupa della gestione del server web e della sicurezza del sito, esegue i backup, rinnova il certificato SSL, fornisce statistiche e molto altro. Tutte cose che valgono molto di più dei pochi euro al mese richiesti.

Proprio mentre pensavo a cosa fare, mi è capitato sotto gli occhi questo post, e ho deciso di assaggiare la cucina tedesca, acquistando un server virtuale da Hetzner. Per far girare comma è più che sufficiente l’offerta base CX22, che con meno di 5 euro al mese mi offre una macchina equivalente a quella base di Shock Hosting, che però costa il doppio. E la potenza della macchina virtuale è tale che posso tranquillamente generare il sito su questa macchina virtuale, trasferendo poi il risultato su Shock Hosting con rsync.

Quando ho scelto Hetzner, la guerra commerciale in atto fra USA ed Europa era solo nelle menti degli dei, ma con il senno di poi è stata una decisione azzeccata. Se un giorno perdessi l’accesso al mio servizio di hosting statunitense, oppure se il costo diventasse proibitivo per un europeo, ci metterei molto poco a trasferire tutto in lidi più sicuri. E ciao ciao USA.

Facciamo due conti

Ho scritto che secondo me non vale la pena fare da sé, usando un Mac o un PC per gestire il proprio sito. Ma dal punto di vista economico, potrebbe valerne la pena?

Cominciamo calcolando quanto spendo al mese per melabit.com/posts/it. Per l’hosting se ne vanno 3 euro, per il server virtuale 5 euro. Totale 8 euro al mese, che in un anno fanno 96 euro. A questo andrebbe aggiunto il costo del dominio, ma quello va pagato in ogni caso, quindi lo lascio fuori.

Mettiamo ora che io sia testardo e voglia usare a tutti i costi un mini PC o un Raspberry Pi per gestire il mio sito. Diciamo che per il computer nudo e crudo se ne vanno 100-120 euro, a cui va aggiunto un disco SSD decente e una quantità di RAM adeguata, che fanno almeno altri 60-100 euro (per il Raspberry Pi la RAM è quella è non può essere cambiata, ma al suo posto dobbiamo prevedere di acquistare case, alimentatore, dissipatore praticamente obbligatorio e scheda per disco SSD NVMe, che fanno almeno 100 euro in tutto).² Poi ci vuole un UPS, e sono altri 100 euro.

Il totale fa circa 300 euro (più o meno 30-40 euro), praticamente lo stesso di quello che spendo io in tre anni. Ma non è affatto detto che il mini PC o, peggio, il Raspberry Pi riesca a reggere tre anni di uso ininterrotto, per cui magari oggi si rompe la ventola, domani l’alimentatore, il disco comincia a fare le bizze, le batterie dell’UPS si esauriscono. Insomma, anche economicamente non è che convenga più di tanto.

Meglio, molto meglio il cloud.

In teoria, si potrebbe dedicare un intero Mac ad un sito che riceve un numero molto elevato di visite. Ma in questo caso servono soluzioni professionali, non è possibile fare da sé. ↩︎
Ma riuscire a rimanere vicino al limite inferiore di 160 euro mi pare davvero difficile. ↩︎

Da melabit a melabit: gestire i commenti con Jekyll

Wed, 05 Mar 2025 06:00:00 +0000

Come dicevo la volta scorsa, Jekyll non ha un sistema di commenti integrato, ma i suoi temi permettono spesso di gestire i commenti collegandosi a servizi di terze parti, come Disqus e simili.

Il problema di questi servizi è che possono smettere di funzionare da un giorno all’altro (vedi il caso di Muut, che non ha più nemmeno un sito web), oppure hanno regole opache di utilizzo e di raccolta dei dati dell’utente.

Un altro problema niente affatto trascurabile è che la maggior parte di questi servizi richiedono all’utente di registrarsi prima di commentare. La registrazione è utile per filtrare i commenti inopportuni o lo spam, ma è anche una barriera per il lettore casuale del post che voglia dire la sua.

C’è poi la questione del costo. Alcuni servizi di gestione di commenti sono a pagamento e non sono nemmeno economici, vedi il caso di Hyvor Talk che costa 12 euro al mese. Prezzo più che accettabile per un sito professionale o per una piccola azienda che voglia interagire con i suoi utenti – tanto più che spesso questi servizi gestiscono anche l’invio di newsletter e materiale pubblicitario vario – ma decisamente fuori scala per un blog fatto in casa come questo.

Alla ricerca del sistema ideale

Il mio interesse verso le questioni relative ai commenti è nato un anno fa quando, dopo la chiusura improvvisa di Muut, ho osservato l’enorme lavoro svolto dietro le quinte da Mimmo, MacMomo e Paoloo, per recuperare da Muut tutti i commenti di Quickloox – uno dei blog imprescindibili per chi si interessa di Apple, Mac e dintorni – per poi convertirli nel formato del nuovo motore dei commenti e reinserirli in bell’ordine nel blog.¹

Pochi mesi dopo ho messo in cantiere il passaggio da Wordpress Jekyll, e quello dei commenti era uno dei problemi principali da risolvere. Su Wordpress il problema non si pone, i commenti sono integrati e vengono salvati nel database del sito insieme al testo dei post. Ma quando si usa un sito statico, come quello generato da Jekyll, bisogna implementare qualche meccanismo per innestarvi sopra i commenti, che per la loro stessa natura sono degli oggetti dinamici.

Con il senno di poi, avrei potuto seguire i consigli di Mimmo e scegliere Comma fin dal primo momento. Ma arrivavo da Wordpress e l’idea di usare un database mi sembrava la più naturale.

E allora ho provato Cusdis, Commento, Commento++, Remark42, Zooment, tutti sistemi di commenti basati su un database.¹ Ho seguito passo passo le istruzioni, ho usato Docker, ho usato una macchina virtuale sul cloud con Linux, ho provato servizi che dovrebbero fare tutto da soli come Railway o Vercel. Niente da fare, ci fosse stato un sistema di commenti che funzionava come si deve!²

Esclusi a priori tutti i sistemi che si appoggiano a GitHub, come Giscus, Staticman o utterances, perfetti per gli sviluppatori che hanno già di sicuro un account, ma poco pratici per il lettore occasionale costretto a crearne un altro inutile, ne restava solo uno. Ovviamente Comma.

Al lavoro su Comma

E Comma è stato. Comma è scritto in Go e viene distribuito solo in formato sorgente. Per compilarlo serve quindi un compilatore per il linguaggio Go. Sul Mac il compilatore si installa scaricando il package preconfezionato e seguendo le istruzioni, oppure tramite il solito Homebrew,

$ brew install golang

Analogamente, su Linux Go si installa scaricando un file compresso ed estraendolo nella directory usr/local, oppure tramite i comandi del package manager della propria distribuzione,

$ sudo apt install golang
$ sudo dnf install golang
$ sudo pacman -S go

a seconda che usiamo Debian/Ubuntu, Fedora/CentOS, Arch, o uno degli infiniti derivati.

Una volta installato Go, compilare Comma è questione di un attimo,

$ git clone https://github.com/Dieterbe/comma.git
$ cd comma/src
$ go build

dove l’ultimo comando serve per controllare che il programma venga compilato correttamente. Se è tutto a posto, si può eseguire

$ go install .

che in un solo colpo compila il sorgente ed installa l’eseguibile comma in ~/go/bin/ (come al solito la ~ rappresenta la Home dell’account che stiamo usando).

Io prima di clonare il repository di Comma ho fatto un fork nel mio account personale, ma solo perché volevo cambiare qualcosetta nel codice.

La prima cosa che ho fatto è stata quella di cambiare l’estensione dei file dei commenti, da .cmt a .xml (linee 67 e 105 del mio file comment.go). I commenti sono infatti dei file XML, e non c’era ragione di usare una estensione non standard. In più, questa modifica permette di aprirli più facilmente con un editor di testo, che li formatta automaticamente in modo leggibile. Una piccola comodità, molto utile durante la fase di sviluppo. Sempre per aumentare la leggibilità, ho anche aggiunto 4 spazi prima di ogni tag XML (linea 71-73 di comment.go).

Infine, ho rimosso l’obbligo di inserire l’indirizzo email di chi scrive il commento (linee 94-96 di main.go). Volevo infatti un sito privo di qualunque forma di tracciamento degli utenti, evitando tanti grattacapi con la GPDR.³ In teoria, ciò può presentare qualche rischio a livello di sicurezza, ma davvero pensiamo che chi vuole fare dei danni inserisca la sua vera email?

Per quanto riguarda il frontend, cioè come l’utente vede il suo nuovo commento e la lista dei commenti precedenti, qui ho trasportato su Jekyll la gran parte del codice originale dell’autore di Comma, aggiungendo il supporto a Markdown e ripulendo il commento dal codice potenzialmente malevolo inserito nel testo. Per queste due ultime funzionalità ho tratto molta ispirazione dal codice scritto da Mimmo, MacMomo e Paoloo per Quickloox.

In quanto alle icone associate a ciascun commentatore, ho preferito farle generare da Jdenticon, forse perché le sue strutture geometriche simmetriche si adattano meglio alla mia personalità.

L’aspetto finale dei commenti mi pare piuttosto gradevole e ben integrato con il resto del sito, e anche la localizzazione funziona bene, anche in dettagli minimi come la riga sottile più in evidenza sotto “Aggiungi un commento”, che cambia a seconda che la scritta sia in italiano o in inglese.

Tutto il codice del frontend è in _includes/custom/comma-comments.html. Già che c’ero, ho aggiunto alla pagina dei post (_layouts/post.html), una piccola funzione in JavaScript che permette di tornare con un click in testa al post. A me serviva in fase di sviluppo, ma credo che possa essere utile anche a chi legge l’articolo, per cui l’ho lasciata nel codice finale.

Mettere tutto insieme

Una volta pronto sia il sistema di commenti che il codice per visualizzarli sul sito, bisogna far funzionare tutto assieme. Per prima cosa dobbiamo creare una cartella dove salvare tutti i commenti,

$ cd
$ mkdir ~/comments

poi attivare Comma a mano,

$ ~/go/bin/comma ~/comments localhost:5888

istruendolo a mettersi in attesa dei nuovi commenti sulla porta 5888 del computer locale localhost, salvandoli nella cartella ~/comments. Infine, dobbiamo aggiungere in _config.yml una riga che connetta Jekyll al server dei commenti,

#--- Comma comments ---
commentserver: http://localhost:5888

e tutto dovrebbe funzionare al primo colpo. Se invece di un computer fisico stiamo usando una macchina virtuale sul cloud, al posto di localhost dovremo usare il reverse DNS name della macchina (si veda l’articolo precedente), ma i dettagli di come si fa dipendono dal servizio usato, per cui non posso essere più preciso.

In un sito reale le cose diventano un po’ più complesse, ad esempio perché bisogna utilizzare il protocollo sicuro https: al posto del semplice http:, e questo richiede di configurare per bene il server web. Ma anche in questo caso i dettagli dipendono dal server web utilizzato, dalla configurazione dei servizi installati e così via, per cui è impossibile dire di più senza scrivere un intero manuale d’uso.

Quello che posso dire, invece, è che un sito vero richiede che Comma parta automaticamente, esattamente come succede al server web che gestisce il sito.

Assumendo che il sito giri su un server Linux (nel prossimo articolo spiegherò perché non ha molto senso usare un Mac come server web) e che Comma sia stato installato dall’utente webuser, per far partire Comma automaticamente ad ogni riavvio del sistema operativo (ma anche quando per qualche motivo il programma viene interrotto), dobbiamo eseguire

$ cd /etc/systemd/system
$ sudo touch comma.service

creando il file di configurazione comma.service vuoto, per poi inserire in questo file le righe seguenti,

[Unit]
Description=comma backend server
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/home/webuser/go/bin/comma /home/webuser/comments :5888
Restart=always
RestartSec=1
User=webuser
Group=webuser

[Install]
WantedBy=graphical.target

ricordandosi di sostituire a webuser il nome dell’utente che ha installato Comma. A questo punto,

$ sudo systemctl enable comma

attiva il meccanismo di avvio automatico che ci permetterà, da ora in poi, di dimenticarci (o quasi) dell’esistenza di Comma. Per interagire manualmente con il servizio si usano i comandi,

$ sudo systemctl status comma
$ sudo systemctl stop comma
$ sudo systemctl start comma

che servono rispettivamente ad interrogare lo stato del servizio, oppure a fermare e a riavviare a mano Comma. Sono comandi molto utili in fase di debugging, ma possono servire a volte anche in produzione, per cui è bene sapere che esistono.

Conclusioni

Avevo pensato di concludere qui questo viaggio nella descrizione tecnica del nuovo sito, ma mentre scrivevo questo articolo mi sono accorto che qualche parola sull’hosting potrebbe essere utile. E proprio questo sarà l’argomento della prossima puntata.

E nemmeno un database piccolo come SQLite! Tutti questi sistemi di commenti usano pesi massimi come MariaDB o PosgreSQL. ↩︎ ↩︎
Se fossi cattivo potrei pensare che le istruzioni fossero sbagliate apposta per spingermi ad usare le loro soluzioni cloud a pagamento. Ma io sono buono. ↩︎
Non ho niente contro la GPDR, anzi la trovo una normativa utilissima, almeno in teoria. Nella pratica, però, fa poco per tutelare davvero la privacy degli utenti, riducendosi nei fatti in un poco utile appesantimento burocratico. ↩︎

Da melabit a melabit: sviluppare un sito in Jekyll

Sat, 01 Mar 2025 06:00:00 +0000

Dopo la prima parte dedicata all’installazione e alla configurazione iniziale di Jekyll, con questa seconda parte di note commentate si entra nel vivo dello sviluppo di un sito in Jekyll a partire da un tema già pronto. Sviluppare da zero un tema per Jekyll, invece, va molto oltre le mie competenze, ma del resto chi è in grado di farlo non ha bisogno di leggere queste notarelle.

Cosa vogliamo?

Per prima cosa dobbiamo avere una idea chiara di come dovrebbe essere il sito dal punto di vista grafico e quali funzioni deve supportare. Vogliamo un blog personale con un semplice elenco di post? Vogliamo un sito più elaborato stile rivista? Vogliamo un sito vetrina per presentare la nostra attività o un progetto specifico? Vogliamo un sito fotografico o di documentazione?

Una volta chiarite le “specifiche” del sito, facciamo un giro su questo sito di temi per Jekyll, oppure su questo, o su questo, o infine su questo (non posso distinguerli per nome, perché si chiamano tutti Jekyll Themes). I più pazienti potranno scorrerli uno ad uno, gli altri preferiranno selezionate la tipologia di sito che gli interessa e guardare solo quei temi. In ogni caso, è bene prendere nota di quelli che ci piacciono di più e provate i siti demo, quando ci sono. È bene essere aperti, magari troviamo un tema interessante che esce fuori dalle specifiche, meglio segnarsi anche quello.¹

Come è fatto un tema

A questo punto non resta che provare. Per evitare di essere generico, descriverò l’installazione del tema Mundana che, guarda caso, è quello che ho usato per melabit.com/posts/it.

Ma, proprio come Mundana, la maggior parte dei temi non gem-based di Jekyll si installa clonando il suo repository su GitHub oppure scaricando un file compresso (nel qual caso, tutto la parte qui sotto relativa a git può essere saltata a piè pari). In entrambi i casi, ciò che installiamo è sia il tema che il sito vero e proprio, perché in Jekyll non c’è una separazione netta fra grafica e contenuti.

La prima cosa da fare è installare git sul computer. Su macOS è installato di default, ma è sempre una versione un po’ datata, e comunque come dicevo la volta scorsa, è sempre meglio separare i tool di sistema da quelli che usate per lo sviluppo. Del resto, con Homebrew ci vogliono pochi secondi, basta eseguire

$ brew install git

e avremo l’ultima (o quasi) versione di git installata sul Mac.

Con Linux non è molto diverso, ma questa volta dovremo usare l’installatore dei pacchetti per la distribuzione in uso, per cui eseguiamo uno dei comandi qui sotto

$ sudo apt install git
$ sudo dnf install git
$ sudo pacman -S git

a seconda che usiamo Debian/Ubuntu, Fedora/CentOS, Arch, o uno degli infiniti derivati.

Come dicevo, l’installazione di Mundana avviene clonando il suo repository,

$ git clone https://github.com/wowthemesnet/mundana-theme-jekyll.git
Cloning into 'mundana-theme-jekyll'...
remote: Enumerating objects: 324, done.
remote: Total 324 (delta 0), reused 0 (delta 0), pack-reused 324 (from 1)
Receiving objects: 100% (324/324), 4.12 MiB | 24.52 MiB/s, done.
Resolving deltas: 100% (116/116), done.

oppure scaricando ed espandendo il file zip del progetto.

Gli sviluppatori suggeriscono di fare il prima un fork sul nostro account GitHub e poi di clonare da lì. Secondo me ha senso se vogliamo contribuire al codice, altrimenti mi sembra un passaggio inutile. E comunque, chi sa cos’è un fork non ha bisogno di altre istruzioni.

Una volta finita l’installazione, possiamo spostarci nella directory di Mundana e curiosare un po’ in giro (per maggior chiarezza, tutti i nomi delle directory finiscono con uno /).

$ cd  mundana-theme-jekyll
% ls -nhp
total 72
-rw-r--r--   1 501  20   398B Feb 12T19:58:00 404.html
-rw-r--r--   1 501  20   510B Feb 12T19:58:00 Gemfile
-rw-r--r--   1 501  20   1.7K Feb 12T19:58:00 Gemfile.lock
-rw-r--r--   1 501  20   2.0K Feb 12T19:58:00 README.md
-rw-r--r--   1 501  20   1.7K Feb 12T19:58:00 _config.yml
drwxr-xr-x  11 501  20   352B Feb 12T19:58:00 _includes/
drwxr-xr-x   6 501  20   192B Feb 12T19:58:00 _layouts/
drwxr-xr-x  11 501  20   352B Feb 12T19:58:00 _pages/
drwxr-xr-x  20 501  20   640B Feb 12T19:58:00 _posts/
drwxr-xr-x   5 501  20   160B Feb 12T19:58:00 assets/
-rw-r--r--   1 501  20   149B Feb 12T19:58:00 docker-compose.yml
-rw-r--r--   1 501  20   9.2K Feb 12T19:58:00 index.html

La directory di Mundana contiene due file di servizio di RubyGems, Gemfile e Gemfile.lock, oltre al file docker-compose.yml che serve solo se usiamo Jekyll all’interno di un container Docker (cosa che qui non interessa). Tutto il resto fa capo a Jekyll.

Le pagine statiche del sito vanno messe nella cartella _pages, mentre tutti i contenuti dinamici, cioè quelli che vengono modificati di frequente come i post di un blog, vanno in _posts. Il contenuto delle pagine statiche e dei post può essere scritto indifferentemente sia in html che in Markdown.

La cartella _layouts contiene i file che generano le parti principali del sito, come le pagine statiche e quelle dei post o la barra laterale, mentre la cartella _includes contiene delle porzioni di codice che possono essere incluse nelle diverse pagine, più o meno come se fossero delle funzioni di libreria.

Queste quattro cartelle, che iniziano tutte con un underscore _, vengono elaborate dal motore di Jekyll, che le usa per costruire le pagine html vere e proprie del sito statico.

L’ultima cartella assets, invece, è dedicata ai contenuti del sito che non vengono elaborati dal motore di Jekyll, come i file css che specificano tutti i dettagli dell’aspetto grafico del sito, i file JavaScript necessari per svolgere certe funzioni che richiedono interattività,² e tutte le immagini del sito. Quando Jekyll genera un sito questa cartella viene copiata così com’è e il sistema crea automaticamente i link ai vari file.

Infine, il file _config.yml contiene tutti i parametri di configurazione del sito, fra cui il nome e la descrizione del sito, il link al logo o alla favicon, i plugin necessari per generare il sito, i parametri di paginazione, o l’elenco dei file e delle cartelle di servizio che non devono essere elaborati da Jekyll. Il file _config.yml può diventare piuttosto lungo e complesso, qui sotto per semplicità faccio vedere solo una piccola parte del file _config.yml di default di Mundana.

# Site
name: 'Mundana'
description: 'Mundana is a free Jekyll theme for awesome people like you, Medium like.'
logo: 'assets/images/logo.png'
favicon: 'assets/images/favicon.ico'
baseurl: '/mundana-theme-jekyll'

[...]

# Plugins
plugins: 
  - jekyll-feed
  - jekyll-sitemap
  - jekyll-paginate
  - jekyll-seo-tag
  
[...]

# Paginate
paginate: 10

# Exclude metadata and development time dependencies (like Grunt plugins)
exclude: [README.markdown, package.json, grunt.js, Gruntfile.js, Gruntfile.coffee, node_modules]

Già che ci siamo, semplifichiamoci il lavoro futuro con una piccola modifica al file _config.yml, sostituendo la riga baseurl: '/mundana-theme-jekyll' con baseurl: ''.

Dimenticavo, anche i plugin (e le relative dipendenze) sono anch’essi delle gemme di Ruby e non sono installati di default, per cui ci tocca farlo con

$ rm Gemfile.lock

che serve per evitare di avere conflitti quando Ruby ci propone di installare plugin più recenti di quelli riportati nel file Gemfile.lock. Subito dopo,

$ bundle install
[...]
Fetching gem metadata from https://rubygems.org/............
Resolving dependencies...
Fetching jekyll-paginate 1.1.0
Installing jekyll-paginate 1.1.0
Fetching jekyll-sitemap 1.4.0
Installing jekyll-sitemap 1.4.0
Bundle complete! 4 Gemfile dependencies, 39 gems now installed.
Bundled gems are installed into `[...]/.gems`

che installa i plugin veri e propri (e rigenera automaticamente il file Gemfile.lock con le versioni appena installate dei vari plugin).

Mettiamo di nuovo Jekyll alla prova

A questo punto non ci rimane che mettere di nuovo Jekyll alla prova, ma questa volta con il tema che abbiamo installato.

$ bundle exec jekyll serve --host=0.0.0.0

Il sito verrà rigenerato rapidamente e potrà essere visto all’URL http://localhost:4000 della nostra macchina reale, oppure all’URL della macchina virtuale o del server cloud che stiamo usando, sempre utilizzando la porta 4000 (per i server cloud l’URL ha una etichetta del tipo reverse DNS name o simili).

Rispetto ai semplici temi gem-based visti nell’articolo precedente Mundana è chiaramente un’altra cosa.

Qui la struttura del sito è molto più efficace: in cima vengono mostrati gli ultimi quattro post con le relative immagini, al centro spicca in grande evidenza un post con uno sfondo contrastante (ad esempio l’ultimo pubblicato) e, più in basso, tutti gli altri post sono disposti in ordine cronologico inverso. A fianco, una barra laterale ospita i post che desideriamo mettere in risalto.

Ora basterebbe sostituire i post preconfezionati di Mundana con i propri, aggiungere le immagini, fare due o tre modifiche al file _config.yml e in pochi minuti si avrebbe il sito pronto da mettere online, con tutti i post già organizzati in tante pagine belle ordinate (come si può vedere qui).

Il tema di default non basta

Un tema ben fatto è molto comodo e, come abbiamo appena visto, permette di andare online rapidamente e con pochissimo sforzo. Ma non è detto che così com’è riesca a soddisfare le esigenze di tutti.

Io ad esempio volevo realizzare un sito multilingua in italiano e in inglese, una funzionalità che Mundana non supporta di default.

Inoltre volevo che la Home del sito mostrasse un riassunto degli ultimi post con le miniature delle immagini di testa, ma senza che queste apparissero nelle pagine dei singoli post. Mundana gestisce correttamente la prima richiesta, ma non la seconda.

Un altro problema riguarda la paginazione: quella di default è bella, ma mostra un’unica striscia orizzontale di link a tutte le pagine generate. Quando queste sono troppe, la striscia si allarga a dismisura, finendo per sovrapporsi ad altri elementi grafici della pagina o per uscire dai margini del browser.

Infine, Mundana supporta di default il sistema di commenti Disqus, ma io preferivo una soluzione gestita in casa, evitando di appoggiarmi a servizi di terze parti che possono cambiare le regole di utilizzo o, peggio, cessare di esistere da un giorno all’altro.

Al lavoro!

Premetto che tutto il codice del tema modificato è disponibile su GitHub, all’URL https://github.com/sabinomaggi/mundana-theme-jekyll-multilang.

Paginazione

Cominciamo dalla paginazione. A partire dalla versione 3 di Jekyll (ora siamo alla 4.4.1), la paginazione è gestita dal plugin jekyll-paginate-v2. In Mundana, il codice di paginazione è integrato nel file index.html ed è molto semplice, tanto da dare problemi quando il numero di pagine del sito cresce.

Io ho spostato la paginazione in _includes/custom/paginator.html,³ facendo in modo che i link puntassero solo ad una parte delle pagine disponibili: quelle immediatamente intorno alla pagina corrente, la prima e l’ultima pagine e una pagina intermedia calcolata in base alla distanza della pagina corrente dalla prima (o dall’ultima). In questo modo la paginazione funziona correttamente anche in finestre molto strette o sui dispositivi mobili.

Sul codice c’è poco da dire: partendo dalla pagina corrente vengono determinati tutti gli altri elementi della paginazione, generando dinamicamente il codice HTML di ciascun link. Tutta la logica del codice è in Liquid, che è il linguaggio di templating usato da Jekyll. La sintassi di Liquid è un po’ astrusa e obbliga a fare qualche giochetto con le variabili, ma l’importante è che alla fine tutto funzioni.

Secondo me, la parte più interessante del codice è la prima riga, che serve per cambiare dinamicamente le stringhe di testo in base alla lingua in uso. Ma questo ci porta alla prossima sezione.

Supporto multilingue

Jekyll può gestire i siti multilingua tramite il plugin jekyll-polyglot, che però non comunica bene con il plugin di paginazione jekyll-paginate-v2,⁴ per cui mi serviva un’altra soluzione.

Polyglot è facilissimo da usare, basta aggiungere il plugin sotto la voce relativa nel file di configurazione _config.yml e definire due nuove variabili con tutte le lingue che ci interessano.

[...]

# Plugins
plugins: 
  [...]
  - jekyll-polyglot

[...]

# Polyglot
languages: [en, it, de, fr]
default_lang: en

A questo punto basta definire la lingua di ciascun post, aggiungendo nel suo front matter la variabile lang: (ad esempio, lang: en o lang: it) e il gioco è fatto.

Il front matter di Jekyll è un blocco di metadati in formato YAML inserito all'inizio di un file Markdown (.md) o HTML (.html).

Il front matter è racchiuso tra tre trattini (---) e serve a fornire informazioni su quella pagina o post, come il titolo, la lingua, il layout, e per personalizzare il comportamento delle pagine. Ad esempio:

---
title: "Benvenuto"
layout: default
permalink: /it/
lang: it
---

Quando Jekyll elabora il sito, utilizza il front matter per:

definire il template utilizzare per la visualizzazione del sito (layout: default).
personalizzare l’URL associato alla pagina (permalink: /it/).
impostare delle variabili specifiche per quel file, da usare nei layout e nei temi (lang: it). Se una data pagina o post contiene nel front matter la variabile lang:it, Polyglot potrà utilizzare questa variabile per applicare contenuti o stili specifici per la versione italiana del sito.

L’idea quindi era quella di emulare a mano il comportamento di polyglot. La prima cosa che ho fatto è stata definire nel file _config.yml due variabili analoghe a quelle usate da Polyglot,

#--- Custom localization variables ---
# Polyglot does not work well with Paginate-v2
# define these two variables instead
locales: [en, it]
default_locale: en

e aggiungere nel front matter di ciascuna pagina o post una variabile che in analogia con le variabili definite in _config.yml_ può essere locale: en oppure locale: it.

Per semplificare la gestione delle due lingue ho creato, all’interno della cartella principale _posts, due sottocartelle en e it dove inserire i post nelle rispettive lingue (in questo modo, aggiungere con sed la variabile locale giusta è una questione di pochi secondi).

Fatto questo, ho sfruttato una caratteristica specifica di Jekyll che, quando trova un file che nel nome contiene un indicatore di lingua, lo considera un’altra versione del file originale (senza indicatore), con sue variabili specifiche definite nel front matter.

In altri termini, se ho un file index.html che contiene tutto il codice necessario per costruire la pagina Home del sito e poi creo un secondo file index_it.html vuoto, ad eccezione del front matter in cui è definita la variabile locale: it, questo file index_it.html erediterà tutto il contenuto di index.html ma utilizzerà il valore della variabile locale per adattare la pagina alla lingua italiana. Questo meccanismo è spiegato molto bene in qualche pagina che ho consultato, ma purtroppo non trovo più i link relativi.

Ultimo mattoncino: quando si usa la paginazione, la variabile locale: it deve essere definita all’interno della variabile pagination: del front matter,

pagination:
    enabled: true
    locale: it

per cui tutto il codice usato per determinare in modo dinamico la lingua in cui è scritta una data pagina deve controllare sempre sia il contenuto della variabile page.locale che di page.pagination.locale,

Ovviamente bisogna adattare alla lingua anche tutte le stringhe di testo presenti nel sito. Per questo, c’è il file _data/translations.yml che contiene le traduzioni in inglese e in italiano di tutte le stringhe utilizzate.

Inutile dire che mettere a punto correttamente il meccanismo di localizzazione è stata la cosa che ha richiesto più tempo nel corso dello sviluppo di melabit.com/posts/it. Il modo in cui è stato fatto, però, consente di aggiungere una nuova lingua in pochi minuti: basta modificare la variabile locales in _config.yml, aggiungere un’altra cartella in _posts e un’altra bandierina in assets/images. Quasi quasi viene voglia di provare… 😂

Miniature e commenti

Superato lo scoglio della localizzazione, togliere la miniatura dell’immagine di testa dalla pagina dei post è stato uno scherzo. È bastato trovare le righe di codice coinvolte e commentarle e il gioco è fatto.

I commenti invece sono stati tutta un’altra storia, perfino più complicata di quella della localizzazione. E proprio ai commenti sarà destinato il prossimo articolo.

Ad esempio, proprio mentre scrivevo questo articolo, ho messo gli occhi su questo tema che non si adatta alla mia idea originale di sito, ma che forse avrebbe potuto fare lo stesso al caso mio (ma ormai non cambio). ↩︎
Jekyll è un generatore di siti statico, ma ormai anche un sito statico richiede un certo livello di dinamicità per gestire al meglio cose come le ricerche, come i commenti, e così via. ↩︎
Tutto il nuovo codice da includere l’ho messo nella cartella custom per distinguerlo, anche fisicamente, da quello originale del tema. ↩︎
Dato che diversi post di 4-5 anni fa riportano di aver usato senza problemi sia jekyll-polyglot che jekyll-paginate-v2, questo potrebbe essere un problema specifico di Mundana. Oppure è una incompatibilità venuta fuori nelle ultime versioni di Jekyll o dei due plugin. ↩︎

Da melabit a melabit: Jekyll, installazione e configurazione di base

Tue, 11 Feb 2025 06:00:00 +0000

Questo articolo non vuole essere una guida dettagliata alla installazione e configurazione di Jekyll; per quello ci sono le ottime guide riportate più sotto.¹

L’articolo è invece una raccolta commentata delle note che ho preso mentre sviluppavo melabit.com/posts/it, e sono il risultato di giorni e giorni di prove ed errori, di cambi di direzione, di letture alla ricerca del comando giusto. A me le note servivano per ricordare quello che avevo fatto e come avevo risolto i problemi che si presentavano di volta in volta. A voi potrebbero essere utili per fare tutto più in fretta e senza intoppi.

Installazione di Jekyll

Per fare delle prove con Jekyll non c’è niente di meglio che usare una macchina virtuale, magari con una versione server di Linux che carica poco il sistema principale. Una buona alternativa è un server cloud virtuale, anche economico, come UpCloud, Google Compute Engine, Amazon EC2 o similari. Per lavorare sul serio, invece, è molto più comodo e veloce usare una macchina reale, tanto più che seguendo queste istruzioni il rischio di fare danni è nullo o quasi. Io per fortuna avevo a disposizione un vecchio Mac, che mi ha permesso di provare e riprovare sapendo che, in caso di problemi, avrei potuto resettarlo facilmente.

La guida migliore per l’installazione di Jekyll è senza dubbio quella ufficiale, con istruzioni specifiche per i sistemi operativi più diffusi.

La guida per macOS è fatta bene, ma l’installazione richiede Homebrew e un buon numero di passaggi da eseguire con attenzione. Su Linux l’installazione è molto più facile, mentre su Windows la cosa migliora da fare è installare il Windows Subsystem for Linux (WSL) e poi lavorare di fatto in un ambiente Linux.²

Un dettaglio importante che manca nelle istruzioni per macOS – ma che invece è presente in quelle per Ubuntu, FreeBSD e gli altri Linux – è che, prima di eseguire il comando finale gem install jekyll (ma volendo anche prima di iniziare ad installare Jekyll), è bene aggiungere queste righe al file ~/.bashrc o ~/.zshrc (a seconda della shell usata),

#--- Install Ruby gems in the user account, e.g. in ~/.gems ---
export GEM_HOME="$HOME/.gems"
export PATH="$HOME/.gems/bin:$PATH"
#--- end ---

ed eseguire source ~/.bashrc o source ~/.zshrc per attivare le nuove variabili di ambiente (io sono rozzo e mi limito a chiudere il Terminale e a riaprirlo subito dopo).

A cosa servono quelle righe? Ad istruire il gestore dei pacchetti di Ruby, RubyGems, ad installare tutte le sue gemme,³ fra cui c’è anche Jekyll, nell’account dell’utente invece che a livello di sistema. Una cosa buona e giusta per separare l’installazione nativa di Ruby all’interno del sistema operativo da tutto ciò che installiamo noi, permettendoci di correggere gli (inevitabili) errori senza correre il rischio di intaccare le funzioni di base del sistema operativo.

A questo punto, è possibile eseguire l’installazione vera e propria di Jekyll,

$ gem install jekyll

seguita subito dopo da un’altra gemma molto utile, Bundler,

$ gem install bundler

che inspiegabilmente è stata completamente dimenticata nelle istruzioni per macOS .

Per istruire anche bundler ad installare tutto nell’account dell’utente, bisogna eseguire

$ bundle config set --local path $GEM_HOME

Infine, se stiamo usando una macchina virtuale o un server cloud e il nostro sistema operativo principale è macOS, possiamo installare anche questa gemma,

$ gem install rmate

che ci permetterà di usare TextMate, che secondo me è nel complesso il miglior editor per macOS che ci sia in circolazione, per editare i file su cui si deve mettere le mani, invece di dover usare nano, vim o emacs direttamente sulla macchina virtuale/cloud (che, avendo installata una versione server di Linux, non ha una interfaccia grafica).⁴

Il primo sito in Jekyll

Alla fine del processo di installazione di Jekyll, tutte le guide suggeriscono di creare un nuovo sito con

$ jekyll new my-new-blog
Running bundle install in [...]/my-new-blog... 
  Bundler: Resolving dependencies...
  Bundler: Bundle complete! 7 Gemfile dependencies, 30 gems now installed.
  Bundler: Use `bundle info [gemname]` to see where a bundled gem is installed.
New jekyll site installed in [...]/my-new-blog.

che crea una nuova cartella my-new-blog nella cartella corrente (i puntini fra parentesi quadre indicano la parte di percorso che dipende dal sistema operativo). Spostandosi nella nuova cartella e attivando il web server integrato in Jekyll,

$ cd  my-new-blog
$ bundle exec jekyll serve --host=0.0.0.0

potremo vedere il nostro nuovo sito all’URL http://localhost:4000 se stiamo usando una macchina reale. Se invece stiamo usando una macchina virtuale o un server cloud, dovremo puntare il browser all’URL pubblico fornitoci dalla macchina virtuale (o server cloud), utilizzando sempre la porta 4000.

Niente da dire, questa procedura è utile per verificare che tutto funzioni, e poi Minima, il tema di default, è davvero molto pulito ed elegante. Se Minima vi basta, potete chiuderla qui, sarà sufficiente dare un titolo al sito e aggiungere i contenuti e potrete partire immediatamente con il vostro nuovo blog in Jekyll.

Ma questa procedura ci dà anche una idea molto pallida di cosa si possa fare davvero con Jekyll. Perché, e questo è un limite non da poco, le funzioni di Jekyll sono strettamente integrate con i suoi temi grafici.

Jekyll e i temi grafici

Minima è un esempio di tema gem-based, installato al di fuori della cartella del sito e che, proprio per il fatto di separare nettamente i contenuti del sito dal suo aspetto grafico, può essere in teoria facilmente sostituito con un altro tema a gemma, come quello mostrato qui sotto.

Ma i temi di questo tipo sono pochi, in genere sono piuttosto minimali e, per la loro stessa natura, è più laborioso modificarli o aggiungere nuove funzioni. E quel che è peggio, spesso sono fatti per versioni ormai obsolete di Jekyll e non funzionano nelle ultime versioni.⁵

La stragrande maggioranza dei temi per Jekyll arriva invece in un formato che integra in un’unica cartella sia i contenuti che la grafica. Una cosa molto comoda quando si trova il tema giusto, ma che rende molto più complicato cambiare tema a posteriori.

Installare la maggioranza dei temi per Jekyll significa di fatto installare tutto il sito che lo contiene, dandosi poi da fare per sostituire i post e le immagini preconfezionate con i nostri post e con le nostre immagini. Di conseguenza, è preferibile prima scegliere un tema che ci piaccia e che supporti almeno una parte di quello che ci aspettiamo dal sito, e solo dopo iniziare ad estenderne le funzioni nel modo desiderato.

Ma questo sarà l’argomento della prossima puntata.

E se Jekyll non ci piace più?

Allora dobbiamo disinstallare tutto. Il modo moderno per farlo è usare questo comando,

$ gem uninstall --all --ignore-dependencies --executables --verbose

oppure, per chi ama la compattezza,

$ gem uninstall -aIxV

dove lo switch --all segnala di disinstallare tutte le gemme, mentre --ignore-dependencies permette di evitare di bloccare il processo di disinstallazione quando si disinstalla una gemma richiesta da un’altra gemma. Il terzo switch --executable serve per disinstallare gli eseguibili senza richiedere ogni volta una conferma. Infine --verbose è utile per farci spiegare per filo e per segno quello che sta succedendo.

Se avete seguito il consiglio iniziale di installare tutto nell’account utente non vi serviranno i privilegi di amministratore. Altrimenti avrete fatto male e per punizione dovrete anteporre sudo al comando di installazione.

Una volta disinstallate tutte le gemme, si potrebbe anche disinstallare ruby e i pacchetti accessori, usando Homebrew per macOS oppure il gestore dei specifico per la distribuzione Linux usata. Ma con i grandi dischi attuali, vale la pena darsi tanto da fare solo per risparmiare qualche decina di MB?

Alla prossima

L’articolo è già troppo lungo ed è meglio chiuderlo qui. Il prossimo articolo servirà per entrare nel vivo dello sviluppo di un sito con Jekyll. A presto!

A causa dell’abbondanza di documentazione, con Jekyll il vero problema è riuscire a distinguere le guide davvero utili da quelle che fanno solo perdere tempo. ↩︎
Da ora in poi non menzionerò più Windows, perché tutte le istruzioni necessarie a chi usa quel sistema operativo saranno identiche a quelle per Linux. ↩︎
Una gemma è un programma o una libreria scritta in Ruby che contiene al suo interno tutto ciò che serve per eseguirla, o per sviluppare nuovi programmi che ne sfruttano le funzioni. Le gemme vengono installate tramite il gestore dei pacchetti standard, RubyGems, il cui comando gem permette di eseguire tutti i processi di installazione, aggiornamento e disinstallazione delle varie gemme. ↩︎
Naturalmente il problema non si pone per chi è già un maestro di vim o emacs. ↩︎
E quando dico “spesso” non esagero. ↩︎

Windows? No grazie!

Wed, 24 Jul 2024 06:00:00 +0000

– Fonte: Paulius Dragunas su Unsplash.

Ogni tanto mi chiedo, piuttosto oziosamente per la verità, perché non installo mai Windows sui miei computer. Alla fine, la maggior parte delle applicazioni che uso ogni giorno è multipiattaforma, quindi gira indifferentemente sui tre principali sistemi operativi attuali (per chi fosse appena tornato da Marte, sono Linux, macOS e Windows, in ordine rigorosamente alfabetico).

E poi, oggi Windows supporta anche Linux, per cui la mia fame di Terminale e di Unix potrebbe essere soddisfatta anche su quel sistema operativo.

Poi leggo questo articolo su PCWorld, 7 ways Windows 11 collects your data – and how to opt out, cioè I sette modi diversi con cui Windows 11 raccoglie i tuoi dati, e come dire di no, e mi dico grazie, sto bene così.

Cinque ragioni

Mon, 25 Sep 2023 06:00:00 +0000

– Fonte: Pinterest.

Il blog è stato fermo per quasi due mesi, purtroppo è stata una estate pieni di impicci casalinghi e di lavoro, e solo ora riesco ad avere il tempo per mettermi di nuovo alla tastiera a scrivere. Nel frattempo però non ho smesso di buttare giù le idee per i nuovi post, come questo qui sotto che, anche se arriva in ritardo, non ha perso la sua attualità. Di conseguenza, buona lettura!

L’Oscar per l’articolo più inutile dell’estate va a Thomas Rau, che ad agosto pubblica su PCWorld le Cinque ragioni convincenti per comprare un portatile con Windows invece di un MacBook. Traducendo letteralmente, queste sarebbero:

Un’ampia gamma di software per i portatili Windows;
Un’ampia scelta di modelli diversi;
I portatili Windows sono più economici;
I portatili Windows sono più facili da aggiornare e riparare;
Con un portatili Windows sono necessari meno adattatori, o addirittura nessuno.

Il motivo numero 1 poteva essere vero venti e più anni fa, ai tempi di Mac OS 9, quando il Mac rappresentava davvero una piattaforma di nicchia per amatori affezionati. Ma oggi?

Oggi la maggior parte del software è multipiattaforma o gira direttamente sul web, le uniche categorie di software nella quale Windows domina incontrastato sono le utility di manutenzione del sistema e gli strumenti di sicurezza (anti-virus, anti-malware, anti-phishing, anti-tutto).

Bella soddisfazione! Quando devo usare un computer con Windows passo un sacco di tempo con loro, per sistemare qualcosa che non va nel sistema, quando uso macOS o Linux penso a lavorare e basta.¹

Per quanto riguarda i motivi numero 2 e 3 è vero, ci sono in giro un sacco di portatili con Windows di tutte le fogge e per tutte le tasche. Ma questo significa che ci sono anche un sacco di fregature, perché i portatili economici durano in genere lo spazio di un mattino, o poco più, e quelli di qualità… già, sono costosi, perché non ci sono scorciatoie, la qualità, quella vera, non è gratis.

E se devo spendere 1.500 o 2.000 euro per un portatile con Windows, dovendo pure accettare tutti i grattacapi che mi darà il sistema operativo, beh mi tengo stretto il mio MacBook Air o Pro e dormo più tranquillo.

Il motivo numero 4 è l’unico che abbia un senso, almeno secondo me, perché purtroppo è vero che più passa il tempo e più i MacBook diventano difficili da aggiornare o da riparare.

Ci sono dei motivi tecnici, perché se un processore come l’M1/M2 degli ultimi MacBook contiene in un unico blocco anche il processore grafico e la RAM, e se per tenere dietro alla velocità mostruosa del processore bisogna integrare sulla scheda madre anche i componenti della memoria di massa (l’SSD per capirci), c’è davvero poco da aggiornare, a meno di non avere competenze tecniche molto superiori alla media.

E poi ci sono dei motivi pratici, come il desiderio della maggior parte di utenti di avere dei MacBook sempre più sottili e leggeri e con una batteria che dura all’infinito, cosa che implica la necessità di rimuovere tutto ciò che non è indispensabile o che riduce le dimensioni della batteria, primi fra tutti i meccanismi che permettono di accedere facilmente all’interno del portatile.

Non a caso anche i portatili con Windows stanno seguendo la stessa china, sempre più sottili, sempre più leggeri, e di conseguenza sempre più chiusi.² È una questione di fisica, piaccia o no non ci si può fare niente.

E veniamo infine al motivo numero 5. Qui non so se ridere o se piangere, perché di cavi, cavetti e adattatori siamo pieni e non sarà certo un adattatore in più o in meno a fare la differenza.

E poi, non sono proprio i produttori di portatili Windows ad ostinarsi ad usare i connettori a barilotto, quelli a forma di cilindro con un foro nel mezzo di mille fogge e dimensioni diverse, invece di adottare un connettore di alimentazione standard come l’USB-C dei MacBook più recenti?

Per la cronaca, in parallelo all’articolo di Thomas Rau Macworld ha pubblicato le Cinque ragioni per comprare un MacBook invece di un portatile Windows. Sarò di parte, ma le trovo ben più convincenti.

Al più sul Mac faccio ogni tanto una scansione manuale con Malwarebytes, così tanto per non perdere l’abitudine. ↩︎
Ma con una durata della batteria che non può minimamente competere con quella dei MacBook. Se Intel e AMD non riusciranno a produrre in tempi brevi processori più efficienti dal punti di vista energetico, è prevedibile che anche i portatili Windows adotteranno sempre più i processori ARM, che sono gli unici in grado di garantire allo stesso tempo prestazioni elevate e consumi ridotti. ↩︎

Tempo al tempo

Fri, 04 Aug 2023 06:00:00 +0000

– Fonte: Johan Desaeyere su Unsplash.

Finalmente anche l’orologio di Windows 11 potrà mostrare i secondi, una innovazione che, dopo essere stata “lungamente testata dagli utenti della versione Insider di Windows”, approda ora al grande pubblico.

Non è una novità, perché Microsoft ha già provato questa grandiosa innovazione in qualche beta di Windows vent’anni fa, senza mai distribuirla al grande pubblico, semplicemente perché

le prestazioni di Windows peggioravano notevolmente quando gli utenti [decidevano] di mostrare i secondi sull’orologio [posto nella barra delle applicazioni].

Ohibò, una delle prime cose che faccio dopo una nuova installazione di macOS (e prima di Mac OS X/OS X) è proprio quella di mostrare i secondi nell’orologio della barra dei menu, e non mi sono mai accorto di alcun rallentamento, anche in macchine d’epoca con pochissima RAM. Faccio lo stesso anche con i vari Linux che mi capita di usare, a anche lì non ho mai notato alcun decadimento di prestazioni.

Come è mai possibile, allora, che Windows sia scritto così male che solo ora riesce ad aggiornare in tempo reale pochi pixel del desktop senza impattare pesantemente sulle prestazioni del PC?

E poi, se questo è davvero lo stato reale di Windows di 10-20 anni fa, come potevano quelli di Microsoft presentare Windows Vista o Windows 8.x – due sistemi operativi che basavano gran parte del loro (presunto) appeal sull’aggiornamento in tempo reale dei widget e delle tile (cioè in pratica sull’aggiornamento di porzioni dell’area del desktop ben più grosse dell’orologio situato nella barra delle applicazioni) – senza prevedere di essere presi a pernacchie?

Come controllare lo spazio occupato sul Mac con il Terminale

Wed, 03 May 2023 06:00:00 +0000

Il Terminale di macOS è l’applicazione installata di default su tutte le versioni di macOS per accedere alla shell, l’interfaccia a linea di comando del sistema operativo. La maggior parte dei comandi della shell è identica in tutti i sistema operativi basati su UNIX, che oggi sono principalmente Linux e macOS. Una cosa che ci permette di usare gli stessi comandi su questi due sistemi operativi, così come sulle varie incarnazioni disponibili di BSD Unix e perfino su Windows, almeno dopo aver installato il Windows Subsystem for Linux.

Del Terminale di macOS ho scritto parecchie volte su questo blog. Riguardando i vecchi post ho ritrovato questa introduzione all’uso del Terminale e ai suoi comandi principali che mi pare ancora attuale, a parte il fatto che nel frattempo la shell di default di macOS è diventata zsh al posto di bash. Ma questo cambiamento dovrebbe essere quasi trasparente per l’utente finale, dato che zsh è una versione estesa e compatibile quasi al 100% di bash (le principali differenze fra le due shell sono elencate qui e, in termini più tecnici, anche qui).

Oggi però voglio andare oltre i soliti, un po’ noiosi, comandi di base e proporre un comando poco conosciuto ma che può fare comodo nella gestione giornaliera del Mac.

Una premessa: tanti utenti del Mac sono spaventati dal Terminale, magari vorrebbero usarlo ma temono di far danni. Non è il caso di questo comando, che al massimo può produrre delle lunghe liste di file, ma non può in nessun modo danneggiare il sistema (in ogni caso, per danneggiare un sistema operativo come macOS bisogna usare il Terminale in modo davvero scriteriato).

Altra premessa: per non rendere l’esposizione troppo pesante suppongo che chi legge sappia cos’è una shell o qual è la cartella Home (o Inizio) di un utente. Chi ha bisogno di un ripasso, può trovare qui una breve spiegazione dei concetti principali relativi a macOS e al Terminale.

Quanto spazio occupano i miei file?

Questa è una preoccupazione ricorrente in chi ha un disco di capacità ridotta (i 256 GB di spazio sui modelli base di MacBook Air/Pro e Mini sono davvero troppo pochi), oppure un disco grande ma ormai pieno di file.

Il comando base per sapere quanto spazio occupano i file presenti sul Mac è du (ovvero disk usage), che riporta la dimensione (in blocchi) della cartella corrente e di tutte le cartelle contenute al suo interno.

Ad esempio, se voglio vedere quanto spazio occupano i sorgenti in Markdown di tutti i post di questo blog, mi sposto con cd nella cartella ~/Documents/Articoli\ Mac/Blog/posts del mio Mac (zsh riporta il nome della cartella corrente immediatamente prima del simbolo del prompt %) ed eseguo du, ottenendo

dove il . indica per convenzione la cartella corrente, che a sua volta contiene la cartella TODO dove, come è facilmente immaginabile, conservo i post in lavorazione. La dimensione totale occupata dai miei post è di 7080 blocchi, di cui 160 blocchi sono utilizzati da TODO.

Comandi e interruttori

Usare du così com’è ha poco senso, perché la dimensione in blocchi può essere significativa per un esperto di hardware ma non è facilmente comprensibile per la maggior parte degli utenti, abituati a ragionare in termini di kilobyte, megabyte e gigabyte.¹

Meglio quindi aggiungere a du lo switch --si, con il quale du riporta le dimensioni delle cartelle in kB, MB o GB, scegliendo l’unità migliore in base alle dimensioni di ciascuna cartella. Con --si, 1 kB equivale a 1000 byte, 1 MB a 1000 kB e così via, proprio come fa il Finder. Se vogliamo che le dimensioni siano espresse utilizzando i tradizionali multipli di 1024 dobbiamo utilizzare lo switch -h al posto di --si, ma sul Mac non ha molto senso.

Se eseguo il comando du --si nella cartella ~/Documents/Articoli\ Mac/Blog/posts ora ottengo,

da cui si nota che i quasi 450 file Markdown contenuti in questa cartella occupano appena 3.6 MB e potrebbero stare tranquillamente in 3 floppy disk (eh sì, usare un formato testo per scrivere documenti è sempre molto efficiente).

I comandi del Terminale includono spesso uno o più _switch_, cioè delle opzioni che modificano il comportamento del comando per adattarlo alle necessità dell'utente. Gli switch sono indicati da un trattino seguito da una lettera e, a volte, da un parametro che può essere un numero o una stringa. Ad esempio, il comando `ls -a` mostrerà anche i file nascosti, mentre il comando `shutdown -r now` riavvierà immediatamente il computer. Nel caso in cui si debbano utilizzare più di uno switch, è possibile definirli singolarmente, come ad esempio in `ls -a -l`, oppure inserirli tutti insieme dopo il trattino, come in `ls -al`. Gli switch più complessi possono essere indicati anche da due trattini seguiti da una stringa e dagli eventuali parametri, come lo switch `--si` appena visto.

Altri switch utili del comando du sono:

-a: calcola lo spazio occupato non solo dalle cartelle ma anche dai file contenuti al loro interno.

Ad esempio, se provo ad eseguire du a partire dalla mia Home ottengo una lista di più di 60.000 cartelle, ma se uso du -a la lista cresce fino a comprendere quasi mezzo milione di file e cartelle (del comando collegato wc ho già scritto un bel po’ di tempo fa, qui serve a contare il numero di righe riportate da du).
-d seguito da un numero: definisce il livello di visualizzazione delle cartelle tramite il numero associato allo switch. Ad esempio, -d 1 mostrerà solo le cartelle di primo livello, cioè quelle contenute nella cartella di partenza, mentre -d 2 mostrerà anche le cartelle contenute all’interno delle cartelle di primo livello, e così via.

Se provo ad eseguire du -d 1 nella mia Home ottengo,

da cui si capisce immediatamente che le cartelle che occupano più spazio sono Music e Library (c’è da dire che la mia Home è molto più grande, perché la maggior parte dei file si trova su un disco esterno collegato alla Home tramite dei collegamenti simbolici, ma questa è un’altra storia). Se avessi bisogno di fare spazio sul disco saprei subito dove concentrarmi, invece di perdere tempo ad esaminare minuziosamente tutte le cartelle elencate di default da du.
-t seguito da un numero: definisce la dimensione minima che deve avere una cartella per essere visualizzata. Non è comodissimo, perché la dimensione va specificata in byte, però permette di filtrare rapidamente le cartelle più grandi, come in questo caso in cui ho scelto di visualizzare solo le cartelle più grandi di 1 MB (ovvero 1000000 byte).
-I seguito dal percorso di una cartella fra virgolette: permette di escludere la cartella specificata dal conteggio dello spazio occupato. È possibile usare una espressione regolare per escludere più cartelle in un solo colpo.

Ad esempio, -I "Library", esclude la sola cartella Library, oppure -I "D*" esclude tutte le cartelle che iniziano con il punto o infine, come è mostrato qui sotto, -I ".[a-z]" che esclude dalla visualizzazione tutte le cartelle il cui nome inizia con il punto seguito da una lettera maiuscola o minuscola (sono le cosiddette cartelle nascoste che contengono i file di configurazione di certe applicazioni e che in genere non sono molto grandi).
-k, -m, -g: forzano du a riportare tutte le dimensioni rispettivamente in kB, MB o GB. Analogamente ad -h, le dimensioni sono espresse in multipli di 1024. Se sulla stessa riga di comando si inserisce più di uno switch dimensionale, -g, -h, -k, -m e --si, viene utilizzato solo l’ultimo specificato.

Questi switch servono soprattutto quando si vogliono ordinare le directory in base alle dimensioni, inviando l’output di du al comando sort -n -r, come nell’esempio qui sotto (dato che con questi switch 1 GB corrisponde a 1024 MB, i valori riportati qui sotto sono leggermente diversi rispetto a quelli dell’immagine precedente che usa --si, e quindi i multipli di 1000).

Ma ne vale la pena?

Ma perché usare du quando abbiamo a disposizione il Finder? Prima di tutto perché il Terminale è molto più efficiente, con il Finder possiamo esaminare una sola cartella alla volta, il Terminale invece ci permette di analizzare lo stato un gran numero di cartelle tutte insieme, spostandosi molto più velocemente fra una cartella e l’altra rispetto a quanto sia possibile fare con il Finder.

Un altro vantaggio non da poco è la possibilità di salvare su un file l’output del comando du, in modo da poterlo esaminare con calma in un editor di testo, o magari perché vogliamo tenere traccia dello stato delle cartelle nel corso del tempo. Ad esempio potrei salvare nel file du.txt sul Desktop l’elenco completo delle cartelle contenute in Home,

per poi esaminarlo con calma con TextMate o BBEdit, oppure direttamente nel Terminale a colpi di awk, grep e sed e di espressioni regolari (ma questo richiederebbe almeno un articolo a sé stante).

Infine, abbiamo appena scoperto che il Finder non è molto affidabile quando si tratta di calcolare lo spazio occupato in un disco formattato in APFS, per cui meglio sentire un’altra campana. In questo caso specifico, il Finder mi dice che la mia Home occupa 130.7 GB

mentre secondo du sono solo 128 GB. Non è una grande differenza, però c’è da chiedersi chi ha ragione.

Se queste considerazioni non bastano a convincervi, nel prossimo post troverete delle soluzioni alternative utili a visualizzare rapidamente lo spazio occupato sul vostro disco. A presto!

Inoltre, il numero di blocchi riportati da du varia a seconda del sistema operativo e della configurazione del file system, rendendo ancora più difficile la comprensione della dimensione effettiva dei file. ↩︎

Ventoy, il boot manager per i geek curiosi - Installazione e uso

Mon, 14 Nov 2022 06:00:00 +0000

Come dicevo nella prima parte, Ventoy è un programma open source che fa una cosa sola, ma la fa molto bene: avviare le immagini in formato iso contenute nella chiavetta USB (o nel disco SSD esterno) su cui è installato.

E allora, dopo avervi incuriosito (spero!), vediamo come si installa e si usa Ventoy.

Tutte le descrizioni che seguono si basano su una installazione di Ventoy in una macchina virtuale di Parallels Desktop (da 32 GB, per essere precisi). Ho usato questo sistema perché è più facile fare degli screenshot decenti, ma posso garantire che tutto quello che dirò può essere replicato al 100% su una chiavetta USB reale.

Installazione di Ventoy

Per installare Ventoy, la prima cosa da fare è copiare l’immagine iso della versione più recente sulla chiavetta USB. A questo scopo, consiglio di usare balenaEtcher che funziona molto bene e gira perfettamente sulla triade Linux/macOS/Windows. In alternativa si possono usare UNetbootin o Rufus, ma quest’ultimo gira solo su Windows.

Usare balenaEtcher è facilissimo, basta lanciare il programma e seguire la procedura guidata, selezionando nella prima schermata la chiavetta USB da utilizzare,¹ e nella seconda l’immagine iso di Ventoy. L’unica cosa su cui stare davvero attenti è la scelta della chiavetta. Per fortuna balenaEtcher non ci fa sovrascrivere il disco da cui abbiamo effettuato l’avvio del sistema operativo ma, se oltre alla chiavetta USB abbiamo altri dischi esterni, è meglio prendersi qualche momento e controllare con cura di aver scelto il disco giusto.

Una volta completata la copia dell’immagine iso di Ventoy, bisogna riavviare il PC dalla chiavetta USB per installare e configurare il programma. I dettagli su come avviare il computer da una unità USB cambiano da PC a PC, ma in genere si usa un tasto speciale (quasi sempre F2, F12 oppure DELETE) per accedere al BIOS o all’UEFI e selezionare la chiavetta USB come disco di avvio principale, oppure un’altro tasto (in genere ESC o F10, ma ogni produttore di PC e di schede madri ha le sue idee) per far comparire un menu da cui scegliere il disco di avvio.

Per pigrizia ho sempre usato Ventoy su dei normali PC e non ho mai provato ad usarlo su un Mac Intel, ma non c’è motivo perché non funzioni. In questo caso, bisogna solo ricordarsi di avviare il Mac premendo il tasto ALT (⌥), scegliendo come disco di avvio la chiavetta USB su cui è installato Ventoy.

Ventoy usa di default il cinese come lingua dell’interfaccia. È una cosa piuttosto strana visto che è un programma destinato chiaramente ad un pubblico internazionale, ma è così.

Per fortuna è molto facile passare ad una lingua per noi più comprensibile, come l’italiano o l’inglese. Quando posso, io preferisco usare l’inglese, perché le traduzioni spesso stravolgono il significato di certi termini,

ma per chi vuole è disponibile anche l’interfaccia nella nostra lingua.

Arrivati a questo punto, si tratta di cliccare su Device e scegliere il dispositivo su cui installare Ventoy, che chiaramente deve essere la chiavetta USB. Se sbagliate la scelta del dispositivo correte il rischio di danneggiare qualche altro disco del vostro computer, per cui fate molta attenzione alla dimensione del dispositivo in GB, che deve corrispondere a quella della vostra chiavetta.

Se per qualche motivo non trovate la chiavetta USB fra i dispositivi elencati, cliccate sulla voce di menu Opzioni e selezionate “Visualizza tutti i dispositivi”. Ora la chiavetta dovrebbe comparire senza problemi.

Bisogna ora premete il tasto Install per installare Ventoy sulla chiavetta. Comparirà, e per ben due volte!, un messaggio che ci avvisa che la chiavetta sarà formattata, distruggendone tutto il contenuto. Ma il contenuto della chiavetta è stato già cancellato quando abbiamo copiato l’iso con balenaEtcher, per cui mi pare un avviso inutile.

Bastano pochi secondi e la chiavetta USB è pronta per essere usata.

Il processo di installazione crea due partizioni sulla chiavetta USB: una prima partizione, denominata VentoyLiveCD, contenente il programma vero e proprio, che viene eseguito automaticamente avviando il PC dalla chiavetta (in realtà, come dice lo stesso nome, più che un programma si tratta di una mini distribuzione live di Linux), e un’altra partizione, Ventoy, che occupa il resto della chiavetta e che conterrà le immagini iso dei sistemi operativi.

Copia delle immagini `iso` sulla chiavetta

A questo punto bisogna spegnere il computer, togliere la chiavetta USB e riavviare il sistema operativo principale, perché prima di andare avanti con Ventoy bisogna copiare sulla chiavetta le immagini in formato iso (ma anche in altri formati) che vogliamo provare.

La chiavetta continua ad apparire al sistema operativo come una comunissima unità USB, con l’unica differenza che ora, inserendola di nuovo in una porta del computer, compariranno due dischi esterni diversi, uno corrispondente alla partizione che contiene i file del programma e l’altro da usare per le immagini iso. Distinguerli è facilissimo, il disco che ci interessa si chiama solo Ventoy ed è in questo momento completamente vuoto. L’altro disco, VentoyLiveCD, invece, non va mai toccato, anzi è preferibile espellerlo ogni volta che si copiano delle nuove iso sulla chiavetta (su macOS e Linux è sempre possibile espellere una sola partizione, non sono sicuro al 100% che si possa fare la stessa cosa con Windows).

Dopo aver copiato sul disco Ventoy le iso che ci interessano, bisogna riavviare di nuovo il computer, scegliendo questa volta la chiavetta USB come disco di avvio. Comparirà un menu con la lista delle iso presenti sulla chiavetta, più o meno come nell’immagine qui sotto.²

Uso pratico di Ventoy

Fra tutte le immagini in formato iso presenti sulla mia chiavetta, scelgo di avviare Elementary OS, che è una delle distribuzioni di Linux più curate dal punto di vista grafico e che non a caso è fortemente ispirata ai canoni visivi di macOS. Per farlo mi basta selezionare, come si vede nella immagine precedente, la distribuzione con i tasti freccia e premere Invio. Comparirà una prima schermata che mi permette di scegliere se provare o installare Elementary OS, oppure se accedere alle opzioni avanzate.

Se non faccio nulla, dopo alcuni secondi di attesa inizierà il classico processo di avvio di Linux, con il mare di scritte che scorrono velocemente sullo schermo,

alla fine del quale comparirà una prima schermata di configurazione di base di Elementary OS, dove potremo scegliere la lingua e la tastiera. Io, come al solito, scelgo l’Inglese/USA, ma con tastiera italiana.

Immediatamente dopo Elementary OS mi chiederà se voglio installare o solo provare il sistema operativo.

Io scelgo di provarlo, e poco dopo compare il desktop in tutta la sua gloria. Niente però mi impedisce di usare Ventoy per installare, invece che solo provare, Elementary OS (o una qualunque delle altre iso contenute sulla chiavetta) sul disco rigido del computer.

Una volta finita la prova, posso semplicemente spegnere il sistema operativo live, annullando tutte le modifiche al sistema e tornando di nuovo alla schermata iniziale di Ventoy.

Quanto detto vale per qualunque altra distribuzione di Linux supportata da Ventoy (cioè quasi tutte, o almeno quasi tutte quelle degne di essere usate), come si può vedere nelle schermate qui sotto riservate a BunsenLabs Linux, un’altra distribuzione di Linux che mi piace molto,

e che (ma qui divago un po’) ha la particolarità dei menu che compaiono alla pressione del tasto destro del mouse in corrispondenza della posizione del puntatore; una funzione ormai desueta (dovrebbe essere stata introdotta in NeXTSTEP, il sistema operativo progenitore di Mac OS X e macOS) ma che, una volta fatta l’abitudine, si dimostra una vera comodità.

Il discorso fatto finora può essere ripetuto pari pari tutte le altre distribuzioni di Linux supportate da Ventoy, non solo per quelle di nicchia come quelle mostrate finora, ma anche per le distribuzioni più conosciute, come è senza dubbio Ubuntu. Le immagini che seguono mostrano la sequenza di avvio della live di Ubuntu dalla chiavetta di Ventoy, partendo dal menu di avvio di Grub, per arrivare alla scelta se provare o installare Ubuntu e fino all’immagine del Desktop.

Ma quanto detto vale anche per sistemi operativi meno diffusi come FreeBSD, uno dei tanti derivati da BSD Unix, a dimostrazione dell’estrema flessibilità di Ventoy.

E Windows?

Chiaramente possiamo usare la chiavetta di Ventoy anche per installare Windows, anzi probabilmente è proprio questo lo scenario di uso più comune. Come già notato nella prima parte, in questo caso il vantaggio principale è poter avere a disposizione, in un’unica unità USB, le iso di tutte le versioni di Windows che ci potrebbero servire, potendo scegliere con comodità di volta in volta quale installare.

Inutile dire che potremo solo installare Windows, non provarlo live come si può fare con tante distribuzioni di Linux. Ma non si può avere tutto nella vita.

Gli altri strumenti integrati in Ventoy

Guardando con attenzione la schermata iniziale di Ventoy si nota la presenza di alcune opzioni attivabili con i tasti funzione della tastiera del PC, oltre alla schermata di aiuto che si richiama con il tasto h.

La prima opzione, che si richiama con F1, non ho mai avuto bisogno di usarla e non so bene se e quanto sia efficace (ma l’utilità di F1 è spiegato bene qui). F2 invece permette di elencare le iso salvate sulla chiavetta, mentre F3 cambia la modalità di visualizzazione dell’elenco di iso.

Molto più interessante è F4, con cui è possibile eseguire una scansione del disco locale alla ricerca di installazioni di Windows o Linux, che Ventoy cercherà di avviare con i suoi strumenti integrati (ed è proprio qui che Ventoy si comporta come un boot manager generico, particolarmente utile quando per qualche motivo Windows, o magari anche Linux, si rifiuta di partire).

Con il tasto F5, infine, si accede al menu Tools, che permette di configurare il programma cambiando la tastiera, la risoluzione dello schermo, il tema e così via. Non sono cose fondamentali per uno strumento come Ventoy, però ogni tanto possono servire, quindi è comodo che ci siano.

Conclusioni

In questo articolo ho cercato di descrivere dettagliatamente come usare Ventoy. L’ho fatto in modo molto puntiglioso, lo ammetto, perché programmi di questo tipo, se usati in modo sbagliato, possono fare gravi danni al computer. Si pensi a cosa può succedere se si sceglie il disco sbagliato al momento dell’installazione di Ventoy sulla chiavetta.

Ma c’è anche un altro motivo: utility di questo tipo non sono quasi mai di uso intuitivo e richiedono la lettura attenta della documentazione per essere usate al meglio (io stesso, la prima volta, ci ho messo un po’ a capire il meccanismo di installazione e di uso di Ventoy, e chiaramente non mi aveva sfiorato l’idea di leggere prima il manuale!). Un articolo come questo può rivelarsi una introduzione sufficiente all’uso di Ventoy per i normali scenari di uso, riservando la documentazione ufficiale alla soluzione dei casi particolari.

Ancora una cosa…

Prima di finire, segnalo che in rete si può trovare uno strumento integrato di diagnostica e riparazione del sistema operativo basato su Ventoy, che contiene anche una versione portatile di Windows 10 (ringrazio l’amico MailMaster C per il link). Lo strumento si chiama MediCat USB e in teoria potrebbe essere utile per riparare una installazione di Windows non più funzionante.

Diciamo però che non mi convince: il sito è realizzato in modo dilettantesco, la documentazione è assente, non c’è uno straccio di prova che i tool integrati siano quelli originali e non siano invece infettati da malware di vario tipo (mai sentito parlare di hash?). Di conseguenza, io non mi fiderei a usarlo e preferirei costruirmi uno strumento analogo in casa, scaricando le varie utility dalle fonti originali. A tempo perso potrei cercare di costruire una lista di ciò che può essere utile, spiegando come si può integrare il tutto attraverso Ventoy, ma temo che non avverrà a breve.

In ogni caso sono convinto che, in caso di malfunzionamenti sufficientemente gravi, sia meglio reinstallare Windows da zero piuttosto che provare a riparare una installazione che non funziona. Questo approccio permette tante volte di risparmiare tempo, riparare una installazione di Windows è in molti casi una impresa disperata, con il vantaggio aggiuntivo di partire di nuovo da un sistema fresco, con meno aggiornamenti da una versione all’altra di Windows, meno driver che magari non servono più, meno programmi che si avviano da soli, tutte cose che con Windows non guastano mai.

Resta il problema di come recuperare i documenti e tutti i file vari contenuti nelle cartelle dell’utente (o degli utenti) del PC. Ma per questo compito è molto più veloce, e soprattutto affidabile, usare Linux piuttosto che Windows.

L’ho fatto più volte per amici e colleghi, in alcuni casi mi trovavo di fronte a persone terrorizzate di perdere tutti i loro dati, e tutto è sempre finito bene. Una buona distribuzione live di Linux – consiglio in questo caso Ubuntu che è in grado di riconoscere in modo molto completo l’hardware del PC – avviata tramite una chiavetta preparata ad hoc o, meglio ancora, usando Ventoy, può permettere di accedere facilmente al disco del PC e di copiare in tutta tranquillità i dati utente su un disco esterno o su un NAS. Fatto questo, reinstallare Windows da zero e ritrasferire i dati utente dal disco esterno al PC, consente di tornare operativi in poco tempo e senza troppi patemi d’animo.

Si può anche usare anche un disco SSD esterno, guadagnando parecchio in velocità di avvio, ma da ora in poi non lo ripeterò più. ↩︎
Le directory .fseventsd e .Spotlight-V100 sono create automaticamente da macOS e sono normalmente invisibili nel Finder. Qui non servono e possono tranquillamente essere cancellate. ↩︎

Ventoy, il boot manager per i geek curiosi - Introduzione

Tue, 08 Nov 2022 06:00:00 +0000

Ventoy è senza dubbio un software di nicchia, buono soprattutto per i tecnici e i geek curiosi di esplorare il funzionamento dei sistemi operativi. Non serve a tanti, ma se serve diventa subito indispensabile.

Cos’è Ventoy?

Ventoy è un software open source con cui si può creare una chiavetta USB da cui eseguire gli installatori dei principali sistemi operativi a partire dalle loro immagini in formato iso (ma anche da quelle in formati meno comuni, come wim, img o vhd). Sono supportate tutte le versioni di Windows dalla 7 in poi, così come un gran numero di distribuzioni di Linux e di derivati di BSD Unix, ChromeOS e perfino i principali virtualizzatori bare-metal.¹

In pratica, se vogliamo installare un sistema operativo su un PC, invece di trasferirne l’immagine iso su una chiavetta dedicata, usando strumenti come balenaEtcher o UNetbootin (entrambi multipiattaforma) o eventualmente Rufus (solo per Windows), possiamo copiare direttamente l’immagine iso sulla chiavetta USB dove abbiamo installato Ventoy (i dettagli li troverete la prossima volta), avviare il computer da questa chiavetta e lanciare l’installatore direttamente da lì.

Cosa cambia? Niente se lo facciamo una sola volta, parecchio se dobbiamo lavorare su più macchine, se vogliamo provare le nuove distribuzioni di Linux o di BSD o, in generale, se ci piace giocare con queste cose.

Perché, a differenza del metodo tradizionale, una chiavetta abbastanza grande può contenere anche decine di file iso diversi, da lanciare a seconda della necessità o dell’estro del momento. Inutile dire che al posto di una chiavetta potremmo anche usare un disco SSD esterno, anche da soli 128 GB, guadagnando parecchio nella velocità di avvio delle varie iso.

Sia che usiate una chiavetta o un disco SSD esterno, è sempre conveniente astenersi dai modelli di marche sconosciute o poco affidabili. È vero che per questo uso specifico l'affidabilità non è fondamentale, però è altrettanto vero che, se si guasta la chiavetta, bisogna ripetere da zero tutto il processo di installazione/configurazione di Ventoy e, soprattutto, la copia delle iso. È una bella perdita di tempo, per cui è meglio non rischiare solo per risparmiare qualche euro.[^2]

Immagini dell’installatore di Windows 10, eseguito da una chiavetta USB con installato Ventoy.

Ventoy può naturalmente essere usato per installare Windows, ma diventa ancora più utile con le distribuzioni di Linux o di BSD, i cui installatori ormai eseguono quasi sempre una versione Live del sistema operativo, con la quale è possibile provare le funzioni della distribuzione senza rischiare di far danni, sicuri che tutte le modifiche saranno cancellate al riavvio.

In questo caso, il vantaggio principale di Ventoy risiede nel fatto che si può usare una sola chiavetta per eseguire tutte le distribuzioni Live che vogliamo, senza dover riavviare ogni volta il sistema operativo principale solo per creare una chiavetta USB ad hoc con la nuova distribuzione da provare. Una volta trovato ciò che ci aggrada, si può anche decidere di installarlo permanentemente sul computer sempre utilizzando Ventoy.

Esempi di distribuzioni Live di Linux eseguite tramite Ventoy.

Non c’è bisogno di dire che Ventoy è uno strumento fondamentale per chi fa assistenza tecnica e si trova a dover installare (o reinstallare) di continuo le varie versioni di Windows sui computer dei clienti, o che deve recuperare i dati da un computer che non si avvia più o che è infestato da virus e malware vario. Con una sola chiavetta può avere a disposizione tutte le iso di cui ha bisogno, scegliendo di volta in volta lo strumento migliore da utilizzare in quel caso specifico.

Boot manager

Chi ha qualche capello bianco avrà riconosciuto in Ventoy il meccanismo di funzionamento di un boot manager.

I boot manager hanno avuto il loro periodo di massima popolarità fra la fine degli anni '90 e i primi anni 2000, quando era diventato normale per tanti utenti installare sul proprio PC una distribuzione di Linux (e spesso più di una) in parallelo all'onnipresente Windows. Le versioni di Windows di quegli anni non permettevano di avviare altri sistemi operativi oltre a sé stessi, per cui era necessario usare dei boot manager di terze parti per riuscire ad usare indifferentemente Linux o Windows sulla stessa macchina. Io, ad esempio, usavo GAG, che era molto flessibile e avviava praticamente tutto.
Oggi la situazione è cambiata: la riduzione del costo dei computer associata alla disponibilità di processori potenti e di memorie di massa a stato solido velocissime ha reso molto più pratico dedicare ogni PC ad un solo scopo, oppure virtualizzare più sistemi operativi su una singola macchina, evitando così i noiosissimi riavvii da un sistema operativo all'altro.
Ma questo non significa che i boot manager di terze parti oggi siano caduti in disuso, anzi. Fra questi, il più noto è di sicuro GNU GRUB, usato praticamente da tutte le distribuzioni di Linux (ma GRUB è anche in grado di avviare qualunque altro sistema operativo installato sul computer). Poi ci sono Clover e OpenCore, ampiamente utilizzati nel mondo Hackintosh per avviare macOS installato su un semplice PC. Chi usa Windows e vuole una maggiore flessibilità può utilizzare EasyBCD al posto dello strumento di avvio nativo, che definire limitato è poco.

E non si sbaglia, Ventoy si dimostra utilissimo anche in questo campo, perché la stessa chiavetta dove è installato Ventoy permette di avviare un computer su cui Windows (o Linux) si rifiuta di partire, eseguendo una ricerca a basso livello dei sistemi operativi installati sul disco, come si può vedere nell’immagine qui sotto. Con Linux succede di rado (e comunque GRUB riesce quasi sempre a metterci una pezza), ma per chi usa Windows è una manna dal cielo.²

Ventoy può anche essere usato per avviare un sistema operativo che si rifiuta di partire.

Alternative a Ventoy?

L’unica alternativa a Ventoy che io conosca è questo disco SSD esterno, con aggiunto un piccolo schermo e una tastiera con cui scegliere l’iso da avviare. Un bell’oggettino, non c’è che dire, che proprio per la sua stessa esistenza dimostra quanto sia sentita l’esigenza di avviare con facilità le iso di svariati sistemi operativi. Purtroppo il prezzo non proprio popolare (almeno rispetto a quello che fa e alla capacità del disco) lo rende adatto solo a chi si occupa professionalmente di assistenza tecnica.

Per usare Ventoy, invece, non è necessario essere dei professionisti o avere il budget di un professionista. Se volete provare facilmente più di una distribuzione di Linux o se siete l’amico che tutti chiamano quando hanno un guaio al computer, Ventoy diventa subito uno strumento praticamente indispensabile.

Come introduzione a Ventoy può bastare. Nella seconda parte i dettagli dell’installazione e dell’uso di questo strumento. A presto!

Argomento molto interessante di per sé, che spero di riuscire a trattare qui prima o poi. ↩︎
C’è gente che si convince che il computer sia da buttare solo perché Windows non si avvia. E non esagero affatto. ↩︎

Corsi e ricorsi

Sun, 16 May 2021 12:00:00 +0000

Pensieri oziosi della domenica.

Nel 1984 il Macintosh stupì il mondo con la sua interfaccia grafica, che permetteva di interagire con il computer tramite il mouse, i menu e le icone sullo schermo, invece di dover inserire laboriosamente i comandi arcani del DOS tramite la tastiera.

Oggi però la vera potenza del computer è tornata ad esprimersi tramite il Terminale, con cui si possono fare tantissime cose ed in modo così efficiente che, al confronto, l’interfaccia grafica sembra un reperto del passato.

E dato che il Terminale è presente nativamente solo in Linux e macOS, anche Microsoft, per non perdere completamente il mondo degli sviluppatori e degli utenti più avanzati, dopo aver scopiazzato a piene mani l’interfaccia grafica del Macintosh nel suo Windows, ha ripetuto l’opera inserendo in Windows 10 uno strumento che emula un ambiente Linux completo.

– Fonte: National Climatic Data Center.

Dalla fine degli anni ‘70 e per tutti gli anni ‘80 il mondo del computing era diviso in rigorosamente in due: da un lato i computer seri, grossi mainframe nascosti in stanze condizionate e gestiti da sacerdoti in camice bianco, a cui solo pochi fortunati potevano accedere collegandosi in remoto tramite un videoterminale stupido; dall’altro i personal computer, oggetti costosi e fortemente limitati ma che permettevano a tutti di usare un computer in casa o in ufficio. In pochi anni i personal computer sono cresciuti e hanno soppiantato i mainframe, rimasti solo in qualche azienda o centro di ricerca avanzato.

Oggi che i personal computer sono ultrapotenti e alla portata di tutti, stanno diventando centrali i servizi cloud come Amazon Web Services (AWS) o Google Cloud e Microsoft Azure, che permettono di usare dei sistemi di calcolo potenti e adattabili alle necessità del momento senza doversi sobbarcare dell’acquisto e della gestione di computer fisici.

Magari fra qualche anno il modo normale di usare un computer sarà quello di collegarsi in remoto ad un sistema cloud tramite un semplice portatile o tablet. E il cerchio si chiuderà un’altra volta.

Mac OS X, vent'anni e non sentirli

Wed, 24 Mar 2021 18:00:00 +0000

– macOS Screenshot Library, Mac OS X 10.2 Jaguar.

Ricordo ancora benissimo lo stupore che provai la prima volta che vidi Mac OS X in un negozio di Torino. Era il 2003, era appena uscito Jaguar (la prima versione davvero usabile di Mac OS X), e l’interfaccia grafica del Mac che vedevo nella vetrina del negozio era davvero stupefacente. Anche i computer erano belli, in particolare l’iMac G4 e l’iBook G3 bianco, ma quello che li rendeva davvero straordinari era il fatto che accoppiassero così bene la potenza del motore Unix ad una interfaccia grafica da urlo.

All’epoca usavo solo Linux, alcuni anni prima mi ero interstardito a dimostrare che si poteva usare un sistema operativo basato su Unix per il lavoro di tutti i giorni e c’ero riuscito benissimo. Office l’avevo sostituito con Open Office, per navigare usavo Mozilla (il browser derivato da Netscape che poi diventerà Firefox), per la posta c’era Thunderbird (che uso ancora oggi), e per il lavoro vero e proprio avevo una scelta più che abbondante di software open source adatti alle mie necessità.

Da un giorno all’altro decisi di cambiare di nuovo e di tornare al Mac, che avevo abbandonato durante tutta la crisi degli anni ‘90, e non me ne sono mai pentito. Da allora ho avuto l’iBook G3 e G4, il primissimo iMac G5, il PowerBook G4 Titanium, vari iMac e MacBook Intel, ma il fascino di quella prima vetrina non lo dimenticherò mai.

Oggi sono esattamente vent’anni dalla presentazione di Mac OS X 10.0, Cheetah (ovvero Ghepardo), il sistema operativo che, dopo la presentazione del Macintosh nel 1984, avrebbe rivoluzionato per la seconda volta il modo in cui interagiamo con il computer. In vent’anni Mac OS X ne ha fatta di strada e, da sistema operativo di nicchia per pochi utenti un po’ fissati, è diventato un vero e proprio ecosistema con il quale si può usare indifferentemente (o quasi) il computer, il tablet, il telefono, il tablet e persino l’orologio. Ora siamo all’inizio di una nuova rivoluzione che renderà ancora più integrati i vari elementi di questo ecosistema, e sarà bello viverla in diretta.

Ma intanto, grazie Apple per questi bellissimi vent’anni!

Il CNR è anche questo: un po' di codice

Tue, 01 Dec 2020 06:00:00 +0000

XKCD, Good code.

Per concludere nel miglior modo possibile questa serie di articoli (qui la prima e la seconda parte), cosa ci può essere di meglio di un po’ di codice?

Estrarre il testo da un file PDF

Cominciamo dallo script in R, pdf2csv.R, che estrae il testo da un file PDF, (che in questo caso specifico ho usato per estrarre i dati dalla domanda di partecipazione ad un concorso precedente). Qui sotto trovate l’immagine dello script, realizzata con Carbon (perché così è molto più bello), su GitHub c’è il sorgente vero e proprio, per chi voglia provare ad usarlo.

Per eseguire lo script è necessario aver installato sul proprio computer, non importa se è un Mac o un PC con Linux o Windows, l’ambiente R (in questo momento è disponibile la versione 4.0.3), meglio ancora se accompagnato da RStudio Desktop, che è di gran lunga il migliore sistema integrato di sviluppo (IDE) che abbia mai usato, oltre che uno strumento efficacissimo per affacciarsi all’uso di R.

Il codice è molto semplificato, ho tolto tutto ciò che non è strettamente necessario a far funzionare lo script. La chiave di tutto è la libreria pdftools per R. Di librerie per estrarre dati dai file PDF ne ho provate moltissime, sia per R che per Python, ma pdftools le batte tutte per potenza, semplicità e velocità. Ci sono dei tool che convertono un PDF in testo al ritmo di una pagina al minuto, pdftools riesce a convertire (molto bene, peraltro) un file di 400 pagine come questo in appena 5-6 secondi. C’è altro da aggiungere?

Lo script può essere utilizzato dalla linea di comando (per capirci, dal Terminale), lasciandolo esattamente com’è ed eseguendo il comando pdf2csv.R seguito dal nome dal file da convertire (se il nome del file contiene degli spazi va scritto fra virgolette),

	./pdf2csv.R file-da-convertire.pdf

che produrrà due file .csv contenenti il testo estratto dal file PDF. Il primo, con lo stesso nome del file di partenza, ha le righe numerate e cerca di riprodurre per quanto è possibile il layout del file originale. Nel secondo, salvato con il suffisso -clean, mancano i numeri di linea e vengono rimossi tutti gli spazi in eccesso, rendendolo più adatto ad una analisi automatica, in particolare quando il testo si estende per tutta la pagina (il primo file, invece, è molto più utile quando il testo è organizzato in colonne).

Prima di usare per la prima volta pdf2csv.R bisogna renderlo eseguibile tramite il comando chmod (ne ho già scritto diffusamente qui).

	chmod u+x pdf2csv.R

In alternativa si può lanciare lo script tramite il comando Rscript installato con R, senza che sia necessario renderlo eseguibile.

	Rscript ./pdf2csv.R file-da-convertire.pdf

È preferibile che il file PDF da convertire si trovi nella stessa cartella di pdf2csv.R. In caso contrario il testo estratto viene comunque salvato nella cartella dove si trova la script (ve l’avevo detto che lo script era molto semplificato!).

Per eseguire pdf2csv.R all’interno di RStudio bisogna commentare la linea 12 (basta aggiungere un # all’inizio della riga) e attivare la riga 14 o 15 (ma solo da una delle due) togliendo il # iniziale. Se si attiva la riga 14, si deve anche modificare la stringa file-da-convertire.pdf, sostituendola con il nome del file da convertire. Se invece si attiva la riga numero 15, al momento dell’esecuzione dello script comparirà una finestra grafica da cui selezionare il file PDF desiderato.

Nel repository su GitHub di questo articolo ho inserito dei file PDF di complessità crescente con cui fare qualche prova, fra cui un documento di quasi 1000 pagine (un vecchio manuale di riferimento del formato PDF, potevo scegliere qualcosa di diverso?), che può essere utile per valutare la velocità di conversione dello script. Non è necessario farlo a mano, il tempo di esecuzione di un qualunque programma o script si può misurare in modo preciso dal Terminale anteponendo il comando di sistema time, come mostrato qui sotto.¹

	time ./pdf2csv.R PDFReference.pdf

Come piccola chicca finale, ho aggiunto al repository su GitHub un file PDF contenente del testo (apparentemente) nascosto, provate a convertirlo e vi accorgerete di quanto sia banale recuperare il testo completo.

Generare automaticamente dei documenti con AWK

Tirar fuori il testo contenuto in un file PDF è quasi sempre solo il primo passo del lavoro, perché quello che vogliamo veramente è filtrare il contenuto del documento mantenendo solo le informazioni che ci interessano. Nel caso specifico, io avevo bisogno di selezionare dalla domanda di concorso precedente solo i dati relativi ad una specifica tipologia di attività (ad esempio tutti gli articoli scientifici pubblicati), salvandoli in un file ad hoc. E, già che c’ero, volevo anche costruire una tabella LaTeX per ciascun articolo. Una cosa abbastanza facile da fare con AWK.

Di AWK ho già parlato tempo fa e non mi ripeterò, dirò solo che è un linguaggio ideale per analizzare un file di testo una riga alla volta, verificando se si presentano determinate condizioni ed eseguendo le operazioni programmate corrispondenti.

Nonostante i suoi tanti pregi, AWK ha una limitazione piuttosto seria: per come è strutturato, AWK deve per forza di cose esaminare tutto il file senza poter tornare indietro, e quindi è piuttosto difficile fargli eseguire delle operazioni basate su condizioni multiple complesse. È molto meglio (quando è possibile) scrivere più script AWK, da eseguire in sequenza sullo stesso file di partenza o sull’output generato dallo script precedente, piuttosto che cercare di combattere con le limitazioni del linguaggio, complicando a dismisura il codice.

In una prima versione di questo articolo avevo pensato di utilizzare un breve estratto della mia domanda di concorso precedente per descrivere il funzionamento degli script in AWK. Ma mentre scrivevo mi sono accorto che il discorso sarebbe stato così specifico da essere quasi inutile. Ho preferito quindi preparare un piccolo file PDF tratto dagli ultimi post pubblicati su Melabit, con l’intestazione in YAML² di ciascun post seguita dalla prima frase del testo in Markdown e, quando c’è, dal link all’immagine iniziale. L’ho scelto perché la struttura di questo file assomiglia moltissimo a quella della mia domanda di concorso ma, allo stesso tempo, può essere uno schema di partenza applicabile a casi più generali.

Questo file PDF può essere considerato come la stampa di un piccolo _database_ di informazioni correlate, dove ogni post è un _record_, suddiviso a sua volta nei vari _campi_, rappresentati dalle righe di intestazione e dalla frase di testo.

Il file PDF si chiama Melabit ultimi post.pdf e, come gli altri file PDF, è disponibile nel repository su GitHub di questo articolo. Se lo aprite con Anteprima, noterete subito che ci sono delle righe vuote che separano chiaramente un post (nel linguaggio dei database, un record) dall’altro. Ma convertendo il file in testo,

	./pdf2csv.R "Melabit ultimi post.pdf"

(le virgolette sono necessarie perché il nome del file contiene degli spazi), le righe vuote scompaiono e le uniche interruzioni presenti nei due file CSV prodotti dallo script di conversione corrispondono al cambio pagina. Non so se questo sia un baco o una caratteristica voluta di pdftools, ma sta di fatto che è una particolarità con la quale dobbiamo fare i conti se vogliamo analizzare il testo con AWK.

Sembra una sciocchezza, ma senza le giuste interruzioni non è immediato riconoscere la fine di un record prima di iniziare ad esaminare quello successivo, in modo da chiudere correttamente la tabella LaTeX corrispondente al record appena esaminato e ad aprire quella relativa al record successivo. Inoltre, mentre in questo caso specifico la struttura del file PDF è volutamente molto semplice e ripetibile, nella maggior parte dei casi reali il documento da cui estrarre i dati può contenere informazioni strutturate in modi diversi, i campi da analizzare possono essere distribuiti in modo irregolare o mancare del tutto e ci possono essere incongruenze nella loro denominazione. Gestire tutti i casi possibili con un unico script lo renderebbe rapidamente troppo complesso.

Molto meglio affrontare il problema un pezzetto alla volta, utilizzando uno script specifico per ciascun tipo di informazione da estrarre (io ho avuto bisogno di 6 script AWK per eseguire tutto il lavoro di esportazione dei dati, o meglio quasi tutto il lavoro, perché per i casi meno frequenti ho preferito il buon vecchio copia-incolla manuale). In fondo è la stessa logica di Unix, che mette a disposizione un gran numero di strumenti semplici che messi insieme, come tanti mattoncini Lego, riescono a fare cose incredibili.

Un primo script, addblanklines.awk, può servire per inserire nel file CSV di partenza una riga vuota prima di ogni record (una cosa piuttosto semplice da fare in questo caso, dato che ogni post inizia sempre con la stringa “layout: post”). Lo script, appena quindici linee di codice, lo trovate “in bella” nell’immagine qui sotto (ma anche in questo caso il sorgente è su GitHub).

Bastano solo due linee di codice, la #4 e la #9, per aggiungere le righe vuote al posto giusto. Ma già che ci siamo, è conveniente dare anche una ripulita al file CSV togliendo le righe inutili, come quelle che contengono il numero di pagina o la stringa --- che segna l’inizio e la fine dell’intestazione in YAML (linee #5 e #12). Eseguendo lo script sul file CSV originale, si ottiene un nuovo file CSV con i vari record ben separati uno dall’altro.

	./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv

Fatto questo, il passo successivo è semplice. Basta scansionare il file CSV appena generato, file-con-righe-vuote.csv, in cerca della stringa target layout: post e, ogni volta che se ne trova una, generare una nuova tabella LaTeX riempiendola con i dati tratti dalle voci (o più propriamente campi) successive. Il codice del secondo script, cvs2table.awk, è visibile nell’immagine qui sotto (mentre il sorgente è sempre su GitHub).

Lo script è relativamente lungo, sono più di 80 linee di codice, compresi commenti e righe vuote, ma una gran parte serve per implementare la funzione (linee #3-25) che riarrangia le informazioni presenti su più linee consecutive del file CSV in modo che vengano stampate su un’unica riga, e per generare la struttura di base del documento LaTeX (linee #35-42 e #83).

Tolte queste, il resto del codice è semplice, si tratta più che altro di scrivere le stringe giuste al momento giusto e di tenere conto dei casi in cui le informazioni si estendono su più linee consecutive (come succede ad esempio alle linee #61-62 e #66-73). Non entrerò nei dettagli di come funziona lo script, questo non è un corso di AWK (né tantomeno di R), basterà per ora dire che è scritto in modo da essere facilmente adattato a gestire esigenze analoghe. Per usarlo, si deve eseguire lo script usando come file di input file-con-righe-vuote.csv e salvando il risultato dell’elaborazione in un file LaTeX, che qui sotto ho chiamato (con la mia solita scarsa fantasia) lista-articoli.tex.

	./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Mettere tutto insieme

Proviamo allora ad eseguire tutti insieme gli script presentati in questo articolo, in modo da ottenere il risultato finale desiderato. Dobbiamo prima di tutto convertire il file PDF in CSV con

	./pdf2csv.R "Melabit ultimi post.pdf"

che genera automaticamente il file “Melabit ultimi post-clean.csv”. Fatto questo, si eseguono in sequenza i due script AWK, salvando l’output del primo in un file intermedio.

	./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv
	./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Il risultato finale è un file LaTeX ben ordinato con una tabella per ogni articolo, come quello mostrato nella figura qui sotto la cui regolarità, messa in evidenza dai colori delle parole chiave, fa pensare ad uno spartito musicale.

Ma ha senso creare un file intermedio solo per trasferire l’output del primo script al secondo? Molto meglio usare il meccanismo di piping tipico in Unix, con il quale si può trasferire automaticamente il risultato dell’esecuzione di un comando all’ingresso di quello successivo, collegandoli con il carattere | (pipe)?³ Con il piping, i due comandi AWK precedenti possono essere eseguiti uno dopo l’altro in questo modo,

	./addblanklines.awk "Melabit ultimi post-clean.csv" | ./cvs2table.awk > lista-articoli.tex

evitando l’uso di un file intermedio. In questo caso non fa molta differenza, ma quando si devono trattare file molto grossi, il piping è molto più efficiente (con i velocissimi dischi SSD odierni non ce ne accorgiamo più, ma ai tempi dei dischi meccanici la scrittura di grossi file sul disco era un vero collo di bottiglia) e, cosa che non guasta mai, evita di intasare il disco rigido con un gran numero di file inutili.

E poi il piping è un meccanismo intrinsecamente elegante, che non a caso è stato adottato anche in alcuni linguaggi di programmazione odierni, come si può vedere nello script R mostrato nella prima parte di questo articolo (linee #24-25 e #35-37), dove il simbolo | usato in Unix è sostituito dalla strana combinazione di caratteri %>%, piuttosto fastidiosa da scrivere con una tastiera italiana (io almeno sbaglio sempre qualcosa).

Conclusioni

Chi ha l’occhio allenato si accorgerà facilmente che il file LaTeX risultante contiene alcuni errori piuttosto evidenti. Li ho lasciati apposta non solo per non complicare ulteriormente il codice, ma anche per mostrare quanto sia complicato il lavoro di estrazione automatica dei dati da file strutturati in modo non perfettamente regolare. Non è certo un caso che in questo campo ci sia una grossa attività di ricerca che prova a superare gli ostacoli e a rendere il tutto il più semplice e il più efficiente possibile.

Il comando time è presente di default nei sistemi operativi Unix come Linux e macOS. Su Windows time non esiste, ma si possono usare degli strumenti equivalenti. ↩︎
YAML è un linguaggio di markup particolarmente adatto per definire dei file di configurazione e, in generale, per rappresentare informazioni strutturate in modo semplice e leggibile, molto più facile da usare di strumenti più noti come XML e JSON. ↩︎
Il piping è uno dei meccanismi principali che rendono Unix una specie di Lego informatico. ↩︎

SSD o dischi meccanici? Perché non tutti e due? (prima parte)

Wed, 05 Aug 2020 06:00:00 +0000

– Foto di Laura Ockel su Unsplash.

Ci hanno messo qualche anno di troppo, ma ormai i dischi SSD sono diventati le normali unità di avvio dei computer moderni, complice il calo di prezzi degli ultimi anni. Solo Apple si ostina ad offrire dei lenti dischi meccanici da appena 5400 giri al minuto sui suoi iMac più economici, ma probabilmente smetterà (finalmente!) di farlo alla prossima iterazione del modello, che dovrebbe arrivare molto presto (infatti l’iMac è stato aggiornato proprio ieri).

Purtroppo gli SSD sono ancora piuttosto cari, in questo momento un SSD da 1 TB di buona qualità costa fra i 100 e i 200 euro, mentre l’equivalente meccanico si trova a 40-50 euro e con 100 euro si può acquistare un modello dignitoso da 3-4 TB. Meglio non parlare dei prezzi da rapina praticati da Apple, che pretende 625 euro per installare un disco SSD da 1 TB al posto dell’obsoleto Fusion Drive su un nuovo iMac (e definire obsoleto il Fusion Drive è ancora troppo poco), o che sui portatili (ma da ieri anche sugli iMac) ci chiede la bellezza di 500 euro per montare un SSD da 1 TB al posto di quello minimale da 250 GB.

Quando acquistiamo un nuovo computer abbiamo quindi il problema di scegliere se pagare a caro prezzo un disco SSD molto capiente, che magari non verrà mai utilizzato completamente, oppure risparmiare scegliendo un modello da 500 GB – 1 TB che però, complice la solita legge di Murphy, diventerà troppo stretto dopo pochi mesi di utilizzo.

Due dischi al posto di uno

Il problema è aggravato dal fatto che nella maggior parte dei Mac, così come in quasi tutti i PC portatili più performanti, è molto difficile, se non impossibile, aggiornare i componenti interni dopo l’acquisto.¹ Una valutazione sbagliata al momento dell’ordine rischia quindi di rendere rapidamente obsoleto il prodotto acquistato. Un vero spreco, visto che un buon computer moderno può rispondere per parecchi anni in modo più che adeguato alle necessità della stragrande maggioranza degli utenti.

Per fortuna si può avere facilmente il meglio dei due mondi, un veloce disco SSD destinato al sistema operativo e ai programmi, accoppiato ad un disco meccanico (HDD) molto più capiente dove conservare tutti i propri documenti (comprendendo con questo termine sia i documenti da ufficio veri e propri – testi, fogli elettronici, presentazioni, email – sia i file multimediali, gli ebook, il codice sorgente dei programmi che sviluppiamo, e in generale tutto ciò che elaboriamo tramite il computer).²

Fare così ha un altro grosso vantaggio: in caso di guai possiamo reinstallare facilmente da zero sia il sistema operativo che le applicazioni senza correre il rischio di cancellare i documenti, che di fatto costituiscono la parte più preziosa di un computer.

Separare i dati dalle applicazioni è una pratica normale in Linux, la maggior parte delle distribuzioni consente di farlo in fase di installazione (ma in genere bisogna usare una modalità avanzata di installazione) e non è troppo difficile farlo anche in un secondo momento. Anche Windows prevede un meccanismo per farlo, è piuttosto rozzo e funziona meglio al momento dell’installazione di Windows su un nuovo PC, quando il disco rigido è ancora vuoto, ma sappiamo tutti che da Windows non si può pretendere più di tanto.

Anche macOS consente di muovere la cartella Inizio (o Home) di un utente su un altro disco (o su un’altra partizione), ma bisogna dire che è un metodo tenuto molto ben nascosto, e la stessa Apple sconsiglia di utilizzarlo (si veda l’immagine qui sotto).

– Immagine tratta dall’articolo Modificare il nome dell’account utente macOS e della cartella Inizio, pubblicato sul sito di supporto Apple.

Chi volesse provare lo stesso, deve andare nelle Preferenze di Sistema, selezionare Utenti e Gruppi, cliccare sul simbolo del lucchetto e inserire la password dell’amministratore del Mac, poi scegliere l’account da modificare, fare click con il tasto destro del mouse, selezionare Opzioni avanzate e infine modificare la cartella Inizio, facendo in modo che punti ad una cartella sul disco meccanico.

Ma perché complicarsi la vita quando esiste un meccanismo intrinseco a macOS che permette di fare più o meno la stessa cosa senza correre alcun rischio? E che funziona allo stesso modo su qualunque sistema operativo, da macOS a Linux e a tutte le infinite varianti di sistemi operativi basati su Unix, e ormai perfino in Windows? E che ha pure il grosso vantaggio di non modificare la posizione di certe cartelle e di certi file che il sistema operativo si aspetta di trovare in posizioni ben definite, in modo che possa continuare a funzionare perfettamente anche se per qualche motivo non riesce a trovare il secondo disco meccanico.

Collegamenti simbolici

Il meccanismo in questione è costituito dai collegamenti simbolici (o soft link), di cui ho parlato nell’articolo dedicato a Dropbox di qualche giorno fa e molto più diffusamente qui.

Con un uso accorto dei soft link possiamo fare in modo che le cartelle presenti sul disco rigido meccanico sembrino appartenere a tutti gli effetti al disco SSD (senza però consumare spazio prezioso sull’unità a stato solido) e solo un osservatore attento può accorgersi della differenza.

I dettagli di come si può fare li ho già descritti in un articolo di parecchi anni fa e nel frattempo non è cambiato nulla, per cui non è il caso di ripetersi. Mi limito solo a mostrare l’immagine della Home di uno dei miei Mac di casa, dove si può vedere che in macOS i soft link vengono rappresentati da una freccetta sovrapposta alla normale icona del file o, come in questo caso, della cartella. Una rappresentazione visiva efficace, che rende bene l’idea che il file o la cartella in questione punti da qualche altra parte, in questo caso particolare alle cartelle presenti fisicamente sul disco rigido meccanico Data HD (lo so, la fantasia a volte mi fa difetto).

Uso questo metodo da anni su tutti i miei Mac e non ho mai avuto problemi. Anzi, con il tempo mi sono accorto che il disco meccanico è in grado di gestire senza rallentamenti particolari tutti i miei documenti, anche quelli su cui lavoro ogni giorno, cosa che mi ha consentito di separare ancora di più (e meglio) i miei dati dalle applicazioni.

Bene, per ora può bastare. La seconda parte dell’articolo sarà dedicata a descrivere alcuni possibili scenari pratici, con le relative scelte hardware. A presto!

Gli unici modelli facilmente aggiornabili rimasti in circolazione sono i normali PC desktop e, per quanto riguarda il mondo Apple, i nuovi Mac Pro (che però sono rivolti ad un pubblico professionale per il quale il costo di un SSD è trascurabile rispetto al valore dell’intera macchina). ↩︎
Ci possono essere casi particolari in cui è più conveniente tenere i documenti sul disco SSD principale, penso soprattutto ai file multimediali in corso di elaborazione, ma una volta finito il lavoro niente impedisce di archiviarli sul disco meccanico. ↩︎

La falsa sicurezza delle app VPN per Android (e non solo)

Wed, 22 May 2019 06:00:00 +0000

– Fonte: Bernard Hermant su Unsplash.

Fino a pochi anni fa le reti private virtuali (VPN, Virtual Private Network) erano un prodotto di nicchia, riservato prevalentemente a chi era spesso fuori dall’ufficio per lavoro e aveva bisogno di connettersi in modo sicuro alla rete aziendale dal bar o dall’hotel di turno, oppure a chi viveva in paesi a rischio censura e voleva esprimere il suo pensiero senza poter essere rintracciato o più semplicemente desiderava accedere liberamente ai siti web oscurati dal proprio governo.

Poi, proprio all’inizio dell’amministrazione Trump, il Congresso degli Stati Uniti ha deciso di consentire ai fornitori di servizi di accesso alla rete (ISP, Internet Service Provider), gli equivalenti dei nostri Fastweb, Infostrada o Vodafone, di rivendere a chiunque e senza dover richiedere alcuna autorizzazione, i dati di navigazione dei propri utenti. Un business che vale 80 miliardi di dollari di sola pubblicità online.

In questi dati c’è di tutto, fra cui moltissime informazioni strettamente private: la storia della navigazione su internet con l’elenco di tutti i siti visitati, le ricerche effettuate, il contenuto delle email, informazioni mediche e finanziarie, indirizzi, date di nascita, numeri di telefono, e persino i dettagli della posizione geografica dell’utente nel corso della giornata. Di conseguenza l’uso delle VPN è letteralmente esploso.

Purtroppo non è affatto detto che una rete VPN aumenti la sicurezza delle proprie comunicazioni online. Anzi può essere persino peggio, una VPN può dare un falso senso di sicurezza che invita ad abbassare la guardia, con conseguenze potenzialmente catastrofiche (in particolare per coloro che hanno la sfortuna di vivere in paesi governati dal dittatorello di turno).

Lo dimostra una ricerca pubblicata nel 2016, immediatamente prima della deregolamentazione decisa dal Congresso USA. Per motivi pratici la ricerca è focalizzata sulle sole app VPN (gratuite) per Android e trascura completamente il mondo iOS e tutte le applicazioni analoghe per i sistemi operativi desktop, Windows e macOS e Linux. Ma pur con tutti i suoi limiti, i risultati della ricerca danno un quadro piuttosto chiaro di quanto sia critica la situazione in questo settore, e allargando ulteriormente il campo di analisi la situazione non potrebbe che peggiorare.

Qui sotto ho riassunto brevemente i risultati della ricerca, nel corso della quale i ricercatori hanno analizzato ben 283 app VPN disponibili gratuitamente sul Play Store di Google all’inizio dell’analisi (settembre 2015). Chi desidera approfondire può scaricare liberamente dai siti istituzionali degli autori sia l’articolo completo che le slide della conferenza nella quale è stato presentato il lavoro.

Bisogna notare che, anche se tutte le app analizzate sono gratuite, più della metà richiede il pagamento di un importo mensile per l’uso effettivo della rete VPN, una cosa assolutamente normale visti i costi associati alla gestione di una infrastruttura di rete.

Reti peer-to-peer: un gran numero di app VPN non utilizza una infrastruttura di rete costruita ad hoc ma si basa sui nodi di accesso messi a disposizione dagli altri utenti (spesso in cambio di sconti), formando quindi una rete peer-to-peer molto più economica da gestire ma che non garantisce assolutamente la trasparenza e la sicurezza necessarie.

Modello gratuito: mettere su una rete VPN ha dei costi significativi e quindi in questo caso specifico il modello free non può funzionare; per poter proporre delle VPN gratuite o a basso costo le aziende utilizzano spesso una serie di trucchi poco accettabili, con i quali portano gli utenti inconsapevoli sui siti dei partner pubblicitari oppure utilizzano codice JavaScript più o meno oscuro per iniettare gli annunci pubblicitari direttamente nel flusso dei dati. La pubblicità in sé può anche essere innocua, ma mettere le mani nel flusso dei dati trasmessi sulla connessione VPN può portare ad abusi molto più seri e pericolosi per chi utilizza la rete in questione.

Malware: più di un terzo delle app VPN era infestato da qualche forma di malware: non solo il quasi inoffensivo adware (pubblicità non richiesta) ma spesso anche da veri e propri spyware (programmi che spiano l’attività online dell’utente) o trojan (programmi installati di nascosto che possono eseguire operazioni dannose sul sistema).

Crittografia: non è affatto detto che il traffico di rete che transita attraverso queste app VPN sia crittografato e quindi risulti illeggibile agli ISP o alle agenzie governative un po’ troppo curiose; e anche quando lo è, può succedere che errori di implementazione o di configurazione delle app mostrino in chiaro gli accessi ai server DNS (quelli che traducono i nomi dei siti web negli indirizzi numerici comprensibili ai computer), rivelando così l’attività effettuata in rete dagli utenti, una cosa che in certi paesi può essere più che sufficiente per finire in carcere.

Certificati: alcune app VPN riescono perfino ad installare i propri certificati digitali al posto di quelli ufficiali del dispositivo Android (certificati root), rendendo del tutto inefficace la cifratura dei dati in transito sul dispositivo, perché chi dispone del certificato digitale dispone anche delle chiavi con cui decodificare tutto quello che passa attraverso la rete VPN.

Consapevolezza del rischio: solo l'1% delle recensioni sul Play Store solleva dei dubbi sull’attività potenzialmente fraudolenta svolta dalle app VPN; l’utente medio di questi prodotti non ha le capacità tecniche per accorgersi dei rischi che corre quando usa un’app di questo tipo e purtroppo il sistema operativo sottostante fa ben poco per aiutarlo.

Insomma, nonostante i limiti già ricordati, questa ricerca dimostra in modo inoppugnabile che le app VPN per Android (ma non solo) danno solo un falso senso di sicurezza, che le rende inutili e perfino controproducenti. Dubito fortemente che si otterrebbero risultati diversi analizzando le app analoghe per gli altri sistemi operativi mobili o desktop. E dubito altrettanto fortemente (se non di più) che dal 2016 ad oggi la situazione sia migliorata.

Perché?

Primo, perché tutti i sistemi operativi attuali fanno pochissimo per aiutare l’utente a valutare correttamente i rischi connessi a certe attività di rete. Far comparire di continuo avvisi e richieste di autorizzazione di tutti i tipi non è sufficiente, se non si spiega in modo corretto e comprensibile quello che succede. E in ogni caso, troppe richieste inutili non fanno altro che affogare ciò che è veramente importante in un rumore di fondo indistinto, da cui l’utente medio esce cliccando automaticamente, senza nemmeno leggere. Facile quindi infilare delle app più o meno malevole negli store online dei vari sistemi operativi, in particolare di quelli più diffusi, Android per il mobile e Windows per il desktop. Apple per fortuna riesce a controllare meglio di altri gli store di macOS e di iOS, ma possiamo essere sicuri che ci riesca al 100%?

Secondo, perché in questo campo il modello free non funziona a priori. Gestire una infrastruttura di una rete ha dei costi che devono essere ripagati in qualche modo, lecito (attraverso gli acquisti in-app e gli abbonamenti mensili) o illecito. E comunque non è nemmeno detto che una rete VPN a pagamento (anche di costo rilevante) assicuri un livello di sicurezza decente. Poter spiare una connessione considerata sicura può assicurare tanti di quei benefici, sia a livello economico (ad esempio, conoscere le attività e i progetti di certe aziende) che politico (primo fra tutti riuscire a individuare gli oppositori politici), che è meglio non fidarsi.

Che fare?

RIP Linux Journal

Fri, 15 Dec 2017 18:00:00 +0000

– Fonte: Linux Journal.

La notizia è di pochi giorni fa, non ci sono più soldi e Linux Journal ha dovuto cessare le pubblicazioni. L’ennesima rivista che muore perché non riesce più a reggere la concorrenza del web. Ha resistito più di BYTE e di Dr. Dobb’s, sarà solo una piccola soddisfazione ma è sempre meglio di niente.

Linux Journal è stata per tanti anni la migliore rivista dedicata a Linux e al mondo del free software, nessuna rivista concorrente è mai riuscita ad ergersi al suo livello.¹

Purtroppo anche per Linux Journal a un certo punto è arrivata la crisi: la pervasività di internet, la disponibilità pressoché immediata sul web di notizie e di informazioni tecniche, spesso anche di livello eccellente, ha reso sempre più irrilevanti le riviste tradizionali. Che senso aveva comprare Linux Journal per (ri)leggere cose che avevi già visto due mesi prima sul web?

Nemmeno l’abolizione della versione cartacea della rivista ed il passaggio ad una diffusione solo elettronica sono riuscite a invertire la parabola discendente, anzi forse l’hanno persino accentuata. Parecchi lettori insoddisfatti sono scappati via, la diminuzione degli introiti ha avuto conseguenze negative sulla qualità dei contenuti allontanando ancora di più i lettori affezionati, che conservavano religiosamente le copie di carta dei tempi belli (anche io sono stato a lungo fra questi).

Ma i ricordi e la storia sono importanti e, nonostante la disaffezione, ho voluto subito comprare l’archivio completo della rivista (in html), con gli articoli pubblicati dal primo numero del 1994 all’ultimo di novembre di quest’anno. Un paio di anni fa infatti, a causa di una perdita d’acqua, ho perso tutti i vecchi numeri tenuti incautamente in uno scatolone in cantina, e anche se non sono esattamente un appassionato della lettura su congegni elettronici, la versione elettronica della rivista è sempre meglio che niente. Del resto costa meno di 11 euro, un vero affare, anzi praticamente un furto.

Riuscire ad acquistare l’archivio di Linux Journal però non è facile, ad ulteriore dimostrazione del decadimento degli ultimi tempi. Sulla home page non si trova nessun link, con Google sono arrivato a questa pagina, dalla quale però non si riesce ad inserire l’ordine nel carrello. Invece questo link funziona perfettamente, ma ci ho messo dei giorni per accorgermene.

Se è difficile comprare regolarmente ciò che resta di Linux Journal, è facilissimo invece arrivare ad una pagina non protetta del sito della rivista che contiene tutti i numeri disponibili in formato elettronico (che in teoria sono ancora in vendita), prima solo in pdf e poi anche in epub e mobi. Ho comprato regolarmente l’archivio ufficiale e quindi non mi sento in colpa a scaricarli (ma penso che l’amministratore del sito farebbe meglio a cambiare mestiere).

Per chi ha più scrupoli di me, segnalo che tutti i numeri usciti in pdf di Linux Journal (cioè quelli pubblicati a partire da aprile 2005) sono già stati archiviati anche su Archive.org, dove chiunque può leggerli o scaricarli in modo del tutto legale.

Il contenuto della rivista in formato html è accessibile anche dal sito di Linux Journal, ma come al solito non c’è nessun link che permetta di arrivarci dalla pagina principale (e probabilmente nemmeno dalle altre). Lo storico primo numero si trova a questo link, https://www.linuxjournal.com/issue/1, per accedere agli altri basta cambiare opportunamente il numero alla fine dell’URL (l’ultimo numero disponibile è il 206 di giugno 2011). In questo caso l’amministratore del sito non ha colpe, era normale per Linux Journal rendere liberamente accessibili i numeri della rivista dopo alcuni mesi dalla pubblicazione. Probabilmente hanno smesso di farlo quando hanno lanciato l’edizione digitale migliorata della rivista. Provatela ed avrete una sorpresa.

R.I.P., Linux Journal, che gli elettroni ti siano lievi.

A parte Linux Gazette, che però più che una rivista era una fanzine per il web pubblicata da volontari appassionati di Linux (l’archivio funzionante di tutti i numeri di LG si trova qui). ↩︎

Nostalgia di sfondo

Thu, 13 Jul 2017 06:00:00 +0000

Era il 2002, Jaguar era uscito da poco, e io dopo tanti anni decisi di tornare al Mac. Da anni usavo a tempo pieno Linux, ma la grafica spettacolare di OS X unita al cuore che batteva Unix erano troppo allettanti per farsele sfuggire.

Una delle cose che mi piacevano di più di Jaguar era lo sfondo del desktop. Semplicemente spettacolare, niente a che vedere con quello che si vedeva su Linux, un sistema operativo tecnicamente ineccebile ma di aspetto grafico miserrimo.¹

Gli sfondi installati di default diventavano sempre più belli ad ogni nuova versione di OS X, i miei preferiti sono stati senza dubbio quelli di Tiger e di Snow Leopard. Per chi è nostalgico, tutti (tutti!) gli sfondi originali di OS X (e macOS) si possono trovare qui.

Purtroppo i Mac Retina attuali, con la loro super risoluzione, non rendono giustizia a questi capolavori grafici. Ringraziamo quindi caldamente (è proprio il caso di dirlo, di questi tempi) 512Pixels per averne fatto una versione 5K di ottima qualità. I nostalgici saranno contenti.

Oggi Linux è migliorato parecchio anche da questo punto di vista. ↩︎

Linux per tutti i giorni

Mon, 20 Mar 2017 06:00:00 +0000

Qualche giorno fa una bella domanda di andy69 su QuickLook mi ha stimolato ad elencare quelle che, secondo me, sono le distribuzioni di Linux più adatte per la vita di tutti i giorni.

L’argomento mi interessa parecchio e ho pensato di riprenderlo e di estenderlo un po’ in questo articolo.

Tante distribuzioni, troppe distribuzioni

Le distribuzioni di Linux sono troppe. E sono quasi tutte inutili, semplici rimasticature delle distribuzioni maggiori.

Ho cercato su Distrowatch le distribuzioni che contengono una qualunque versione di bash (se manca bash che distribuzione è?) e sono venute fuori ben 759 distribuzioni diverse, di cui solo ben 266 attive. Con tar (idem) i risultati sono simili: ci sono 751 distribuzioni che lo contengono, di cui 263 sono attive.¹

Di queste alcune sono iper-specializzate, vedi Fermi Linux, sviluppata al FermiLab, il concorrente USA del CERN. Oppure GParted Live e Clonezilla, che servono a partizionare o produrre immagini complete di backup del disco rigido, e openmediavault, una distribuzione specifica per i sistemi NAS.

Ma il mondo ha veramente bisogno di Linux Mangaka, Korora Project, wattOS, o di Voyager Live?

Del resto uno dei problemi della mancata affermazione di Linux sul Desktop è proprio la eccessiva frammentazione della piattaforma:² gli utenti sono confusi e non sanno che distribuzione scegliere, per gli sviluppatori è ancora peggio perché già supportare solo le distribuzioni maggiori è un grattacapo non da poco.

E allora facciamo un po’ di spazio e vediamo quali sono le migliori distribuzioni di Linux, intendendo con questa espressione le distribuzioni veramente utili, adatte all’utente che voglia usare Linux al posto di Windows o di (non si sa mai!) macOS/OS X per il suo lavoro di tutti i giorni, ma che sappia poco o nulla di sviluppo del software o di amministrazione dei sistemi operativi.

Quali distribuzioni?

Cercare di stabilire quali siano le migliori distribuzioni di Linux significa scatenare una guerra di religione peggiore della grande guerra fra Commodoriani e Sinclairisti, durata per gran parte degli anni ‘80.

Però, anche se non è il caso di parlare di distribuzioni migliori o peggiori in assoluto (dipende moltissimo dall’uso finale, un desktop ha richieste ben diverse da quelle di un server o di un NAS ), si può provare ad elencare quelle più adatte per essere usate ogni giorno dagli utenti che vogliano lavorare con Linux e non pasticciare continuamente con il sistema.

Tutte opinioni personali, sia ben chiaro, decine di altri articoli su carta e su web presentano le cose in modo ben diverso.

Debian

Dal mio punto di vista non c’è storia, la distribuzione Linux che preferisco in assoluto è Debian. Uso Debian dal 1997, l’ho installata per la prima volta sul mio Compaq 386 portatile caricando pazientemente decine di floppy disk e aggiustando a mano le modeline dello schermo.

Debian ha parecchie asprezze iniziali e un po’ di fissazioni sul software installato di default. Ma una volta attivata la sezione non-free, che consente fra l’altro di installare i driver specifici per la propria scheda grafica (avere una scheda grafica di qualità ed usarla con i driver generici è una vera assurdità) e dopo essersi documentati un po’ in rete sugli aspetti più ostici, gli aspetti positivi di Debian vengono fuori alla grande.

Su tutti la facilità di installazione del software: per questo non c’è sistema migliore di Debian, nemmeno l’App Store arriva allo stesso livello di comodità d’uso.

Anzi, il concetto stesso di App Store centralizzato è stato inventato proprio da Debian: tutti i pacchetti software (package) accettati nella distribuzione sono disponibili negli archivi (repository) ufficiali, non c’è bisogno di andarli a cercare qui a là per la rete come succede purtroppo con RedHat e derivate (vedi sotto). Tanto per dare una idea, in questo momento in Debian ci sono oltre 40.000 package disponibili, che soddisfano praticamente tutte le necessità degli utenti.³

Una volta selezionato un package per l’installazione, il sistema di gestione dei pacchetti apt è in grado di selezionare ed installare automaticamente tutte le dipendenze, cioè i pacchetti e le librerie da cui il package selezionato dipende.

Ormai anche in Linux si sta affermando un metodo diverso di distribuzione del software, con il quale tutte le librerie e i file accessori vengono inglobate nel pacchetto principale (bundle), lo stesso meccanismo che esiste da sempre in Mac OS X (e prima in NeXTSTEP). Ma vent’anni fa lo spazio sugli hard-disk non era abbondante come oggi ed il meccanismo messo a punto da Debian riusciva a trovare un buon equilibrio fra lo spazio occupato sul disco rigido e la facilità d’uso. Non è certo un caso che alla fine quasi tutte le distribuzioni concorrenti l’abbiano adottato.

Linux Mint

Il difetto principale di Debian è anche il suo pregio (per chi lo apprezza): bisogna configurare quasi da zero il proprio sistema, scegliendo in fase di installazione cosa farà la macchina e di conseguenza la base software da installare (che si può estendere facilmente in seguito). Anche l’aspetto grafico va definito praticamente a mano, scegliendo il tema grafico, lo sfondo, le icone, fra le migliaia e migliaia di opzioni disponibili.

Tutto ciò è molto flessibile per chi sa come muoversi, ma contribuisce anche a disorientare l’utente alle prime armi.

Linux Mint è un buon compromesso: base derivata da Debian (e perfettamente compatibile con la distribuzione principale), ma tema grafico ben definito e piuttosto accattivante, anche per chi è abituato al Mac. Non chiedetemi però la differenza fra le versioni “Cinnammon” e “MATE” di Mint, perché non me la ricordo mai. La versione “Xfce” va bene per chi vuole ridurre il peso del sistema grafico sul proprio computer, mentre la “KDE” va bene per chi vuol farsi male da solo.

Ubuntu

Ubuntu è una derivazione di Debian, che in pochi anni è diventata la distribuzione più diffusa di Linux.

All’inizio era una vera bomba, l’ho usata e consigliata parecchio, mi sono perfino registrato per ricevere i CD/DVD delle nuove release che distribuivo a chiunque mi capitasse a tiro (parliamo di tempi in cui scaricare un intero CD o peggio un DVD dalla rete era una impresa preclusa a chi aveva solo una connessione via modem alla rete).

Poi Ubuntu è cresciuta, forse troppo ed ha perso il suo smalto. Aggiornare Ubuntu da una release all’altra è una impresa quasi impossibile (o almeno, è una impresa che porta un sacco di grattacapi) e anche il fatto di promettere da anni innovazioni strepitose che poi non si concretizzano mai (leggi Wayland prima e Mir poi, i server grafici che avrebbero dovuto rimpiazzare il venerando X, attesi dal lontano 2010 e non ancora diventati realmente usabili, o Ubuntu Phone che ha fatto più o meno la fine del corrispettivo Microsoft).

openSUSE

A parte Debian, l’altra distribuzione che mi è sempre piaciuta è SuSE Linux o meglio, come si chiama oggi la versione desktop, openSUSE. Una distribuzione tedesca, precisa e rigorosa come chi l’ha sviluppata, la prima che ha sviluppato uno strumento integrato di configurazione e di gestione di tutto il sistema operativo. Anche l’installatore qualche anno fa era avanti anni luce rispetto alle altre distribuzioni.

Non la uso, se non occasionalmente, da parecchio perché ha qualche problema con Parallels, che è ormai lo strumento principale con cui uso Linux oggi (vediamo se con la beta di quest’anno si riesce a migliorarne il supporto).

Potrebbe essere interessante provarla con la versione Lite di Parallels, che viene distribuita gratuitamente da qualche giorno sull’App Store.⁴

RedHat, Fedora, CentOS?

Non voglio parlare qui di RedHat e derivate, come Fedora e CentOS. Non mi sono mai piaciute e quindi non le uso. Ci ho provato ogni tanto con RedHat, ma ho sempre lasciato perdere.

Uso ogni tanto su un server una versione specifica di CentOS, richiesta dal software scientifico professionale (e piuttosto costoso) che ci gira sopra. E ogni volta che lo faccio mi chiedo come si faccia ad avere la pazienza di andare a cercare per ogni dove i pacchetti software che servono. Forse è colpa mia che non so gestire al meglio questo tipo di distribuzioni.

Pixel

Se avete un vecchio computer a cui dare nuova vita, Pixel è la distribuzione che fa per voi. Pixel è una distribuzione sviluppata originariamente per il Raspberry Pi – il microcomputer a bassissimo costo tanto popolare fra chi vuole riuscire a mettere le mani dentro un computer e fargli fare le cose più impensate e impensabili – ed è stato poi portato ai computer con processore Intel.

Pixel gira molto bene sui Raspberry Pi più recenti, e a maggior ragione può andare a pennello per il vecchio portatile buttato in cantina a prendere polvere, che è a priori molto più potente di un qualunque Raspberry Pi.

Un discorso analogo vale per Elementary OS, per il quale esiste un progetto dedicato specificatamente ad installarlo sul Mac, in parallelo a macOS/OS X. Interessante questo racconto dell’esperienza di un utente Mac, deluso dalle ultime novità hardware prodotte da Apple.

FreBSD

FreeBSD non è Linux, ma rappresenta la base UNIX originale su cui si fonda macOS/OS X. Di conseguenza può essere un’ottima alternativa a Linux per chi usa il Mac. In pratica, le differenze fra FreeBSD e Linux sono minime (o quasi) e spesso comprensibili solo a chi è particolarmente competente di sistemi operativi e sviluppo del software. Lo stesso vale per i tanti derivati di FreeBSD, fra cui non si possono non menzionare NetBSD, che gira praticamente ovunque o OpenBSD, particolarmente focalizzato sulla sicurezza).

Stabile o instabile?

Nessun dubbio su questo: chi vuole iniziare ad usare Linux deve scegliere la versione stabile di Debian (o di qualunque altra distribuzione), lasciando le versioni di test o peggio quelle instabili (chiamate sempre e non a caso “sid” su Debian)⁵ per il futuro, quando si avrà più esperienza e pratica con Linux. È meno divertente ma di sicuro è molto più conveniente.

Per uno sviluppatore anche sid può andare bene come distribuzione da usare tutti i giorni, e spesso è più stabile di tanti altri sistemi operativi, ma il solo fatto di dover aggiornare decine e decine di pacchetti ogni giorno non è di certo una cosa adatta all’utente normale, che voglia usare il proprio computer per lavorare e non per giocare con il sistema (cosa peraltro bellissima per chi lo sa fare).

Conclusioni

Linux può essere una bella esperienza anche per un utente Apple. Si può installare senza troppi problemi sul proprio Mac, in parallelo a macOS/OS X. Si può installare in una macchina virtuale gestita da VirtualBox (gratuito) oppure da Parallels o VMWare Fusion (a pagamento, ma c’è anche la versione Lite di parallels citata prima), senza toccare nulla sul Mac. O si può usare per far rivivere un vecchio Mac lasciato in un angolo, persino un modello con processore PPC su cui può girare al massimo Leopard.

E non c’è niente di meglio per far rivivere un vecchio Netbook, macchine popolarissime dieci anni fa, nate con Linux ma uccise dalla Microsoft dell’era Ballmer, che pretendeva di farci girare Windows pur con limitazioni hardware tanto stringenti quanto assurde.

Sarei proprio curioso di sapere quali distribuzioni non contengono bash o tar e perché. ↩︎
Il discorso vale più o meno negli stessi termini anche per Android. ↩︎
Come se non bastasse, ci sono ulteriori repository non ufficiali, che soddisfano necessità più specifiche e che possono essere aggiunti facilmente alla lista dei repository standard. ↩︎
Purtroppo con Parallels (ma anche con VMware se è per questo), il vero scoglio non è tanto installare la distribuzione quanto installare i tool di supporto specifici dell’emulatore, che servono a migliorare l’interazione fra il Mac e la macchina virtuale. ↩︎
I nomi delle distribuzioni Debian sono tratti tutti da Toy Story (film straordinario); Sid è il ragazzino cattivo che distrugge i giocattoli per il puro piacere di farlo. ↩︎

Divertirsi con il terminale

Sun, 12 Feb 2017 06:05:00 +0000

Siete dei fanatici della linea di comando? Volete mettere alla prova la vostra conoscenza del terminale – l’interfaccia a linea di comando di Linux o di macOS/OS X – e della shell bash?

Se avete risposto ‘si’ ad entrambe le domande, fatevi un giretto su Commandline Challenge e mettete alla prova le vostre capacità, risolvendo le sfide proposte.

Alcune possibili soluzioni sono molto più involute ed intricate di quanto sarebbe normale, ma dimostrano allo stesso tempo una maestria con i comandi della shell che rasenta l’arte.

Post Scriptum. Non prendetevela con me se la vostra produttività crolla vertiginosamente dopo aver letto questo post!

Command line fun

Sun, 12 Feb 2017 06:00:00 +0000

Are you a fan of the command line? Do you wish to test your knowledge of the terminal – the command line interface of Linux or macOS/OS X – and of the bash shell?

If you answered ‘yes’ to the questions above, head your browser to Commandline Challenge and test your skills trying to solve the challenges proposed there.

Some of the possible solutions are much more convoluted than normal, but they also show a technical mastery that resembles art.

Disclaimer. It is not my fault if your productivity sinks after reading this post!

Windows apre a Linux: gli ex nemici diventano amici?

Thu, 14 Apr 2016 06:00:00 +0000

La recente mossa di Microsoft di integrare in Windows 10 il supporto alle applicazioni Linux ha stupito più di un commentatore. Per anni, ai tempi del dominio incontrastato di Windows, Linux era il male assoluto, il sistema operativo che andava contro i principi ispiratori del fondatore Bill Gates, e del suo epigono, Steve Ballmer. Anzi, Microsoft ha fatto per anni di tutto per scoraggiare, e perfino per impedire, l’installazione di Linux al posto o in parallelo al suo sistema operativo

Ma i tempi cambiano, Windows non è più la piattaforma dominante, il mobile e il cloud le stanno assestando colpi potentissimi, se Android e iOS non l’hanno ancora soppiantato in termini numerici lo hanno fatto di sicuro – cosa ancora più preoccupante – in termini di interesse degli sviluppatori.

Ma cosa significa in pratica integrare Linux in Windows? I particolari della mossa di Microsoft sono ancora troppo scarsi e frammentari per poter rispondere in modo dettagliato alla domanda. L’articolo più completo e affidabile che ho letto finora sull’argomento è stato pubblicato su ArsTecnica (e poteva essere diversamente?) qualche giorno fa. Ecco un riassunto delle principali informazioni tratte dall’articolo, insieme a qualche considerazione personale.

Windows Subsystem for Linux

Il prossimo aggiornamento di Windows 10 previsto per l’estate conterrà il cosiddetto Windows Subsystem for Linux (WSL), un insieme di nuovi componenti di base di Windows in grado di eseguire le applicazioni fondamentali di Linux (e del mondo Unix in generale): sicuramente la shell bash e i relativi strumenti di sistema sed, awk, diff, grep, probabilmente make per la compilazione intelligente delle applicazionie, gdb per il debug e git per il controllo di versione, i compilatori e gli interpreti dei principali linguaggi di programmazione, con le relative librerie. Tutta roba da sviluppatori, tutta roba che si usa dalla linea di comando. Niente applicazioni grafiche per l’utente finale, WSL non contiene X11, il software che gestisce le applicazioni grafiche in Linux e Unix.

L’infrastruttura e i componenti di base sono stati sviluppati da Microsoft, mentre le applicazioni Linux verranno fornite da Canonical, l’azienda che sviluppa Ubuntu, la distribuzione più popolare di Linux. Tali applicazioni sono esattamente le stesse che girano su Ubuntu, senza bisogno di ricompilazioni o di adattamenti particolari per Windows.

Le applicazioni fondamentali fornite da Canonical verranno installate tramite un tipico programma di installazione per Windows. Ci sarà la possibilità di aggiungere ulteriori applicazioni tramite i comandi apt-get e dpkg, usati da Ubuntu (e da tutte le distribuzioni Linux derivate da Debian) per l’installazione del software dalla linea di comando.

Windows come piattaforma di sviluppo

Con questa mossa Microsoft riconosce di non essere più la principale piattaforma di sviluppo del software, come era diciamo fino a una decina di anni fa. Ormai lo sviluppo vero si è spostato sul web (non si contano le applicazioni, anche di ottima qualità, che girano direttamente in un browser) e sui dispositivi mobili. Due campi in cui la Microsoft è quasi irrilevante, da un lato perché le applicazioni web sono independenti dal sistema operativo sottostante, dall’altro per il sostanziale fallimento dell’idea di unificare sistemi fissi e mobili in un ibrido mal fatto e mal venduto.

Inoltre, i programmatori e i sistemisti che escono dalle università americane crescono in un ambiente dominato da Linux (e Unix), sono abituati ad usare gli strumenti di sviluppo di questo ambiente e si trovano a mal partito con quelli tipici di Windows.

Gli stessi programmatori/sistemisti sono abituati da anni ad usare i prodotti Apple, magari sono partiti da iOS per approdare a OS X, con il suo cuore Unix già pronto e ben configurato, senza le complicazioni associate a Linux e alle sue infinite distribuzioni differenti e senza (almeno finora!) i pericoli di sicurezza e i fastidi di gestione del sistema tipici di un PC con Windows. Nemmeno il costo è un vero problema perché, c’è poco da fare, un computer con caratteristiche analoghe a quelle dei sistemi Apple ha costi comparabili e una qualità media decisamente minore.

Per cercare di contrastare questo stato di cose, la Microsoft ha anche deciso di integrare gratuitamente Xamarin (un tipico strumento di sviluppo orientato al mondo mobile) in Visual Studio. Accoppiata alla disponibilità di un emulatore Android di qualità e al supporto sempre maggiore allo sviluppo per Android, dimostra in modo palese come Microsoft stia cercando di rendere Windows la piattaforma preferita dagli sviluppatori Android (e forse anche iOS), provando a recuperare il tempo e le posizioni perdute.

Virtualizzazione

Francamente sono stupito dalla banalità dell’approccio Microsoft all’integrazione di Linux in Windows, e dalla risonanza che ha avuto. In fondo il WSL di Windows 10 non è altro che un emulatore, o meglio un virtualizzatore, niente di particolarmente nuovo o sofisticato.¹ Lo dice fra le righe la stessa Microsoft: come è tipico di un emulatore/virtualizzatore, bash e tutte le applicazioni Linux sono isolate e non possono comunicare con le applicazioni per Windows: non si può lanciare una applicazione per Windows da bash o al contrario eseguire bash dal terminale standard di Windows (l’orrido, quasi inusabile cmd) o dal più performante PowerShell.

La Microsoft ha già fatto qualcosa di molto simile ai tempi di Windows 7. Le edizioni professionali di Windows 7 dispongono infatti della cosiddetta modalità Windows XP, utilizzando la quale è possibile far girare le applicazioni per Windows XP non compatibili in una macchina virtuale separata all’interno di Windows 7. La macchina virtuale è preconfigurata dalla Microsoft, per cui l’utente non si accorge (o quasi) della sua esistenza.

Per di più su Windows esiste da anni il progetto Cygwin che fa praticamente la stessa cosa dell’accoppiata WSL/Ubuntu. Anzi parecchio di più, dato che funziona su una qualunque versione di Windows da XP in poi e permette di usare non solo le applicazioni da linea di comando ma anche quelle grafiche.

È vero che le applicazioni provenienti da Linux devono essere adattate per poter essere compilate e per girare sotto Cygwin, ma lo stesso succede anche per Ubuntu, dove chi prepara i pacchetti binari di installazione di ciascuna applicazione deve preoccuparsi di adattare il codice sorgente originale in modo che sia compatibile con le librerie e il resto del software presente nella distribuzione, ripetendo il processo ad ogni aggiornamento del codice sorgente e della distribuzione. Un lavoro non banale, soprattutto per le applicazioni più complesse.

E poi, dai, siamo seri, vedere nelle foto della presentazione di WSL i dischi C:, D:, E:, F: tipici di Windows, o meglio reperti archeologici del DOS, essere tradotti nel sistema Linux all’interno di Windows in /mnt/c/, /mnt/d/ e così via, da quel senso di déjà vu ammuffito che fa stringere il cuore.

Un emulatore simula il funzionamento completo di una macchina che può avere componenti hardware completamente diversi da quelli del sistema ospite su cui gira l’emulatore (si pensi ad esempio all’emulatore di un Apple II su un PC o su un Mac). Un virtualizzatore invece fa girare un altro sistema operativo utilizzando direttamente l’hardware del sistema ospite. ↩︎

Swift open source

Tue, 09 Jun 2015 06:00:00 +0000

Per motivi familiari oggi non ho potuto seguire il WWDC, e in questo momento (poco prima di mezzanotte) il keynote non è ancora dsponibile sul sito di Apple.

Sono però riuscito a scorrere gli highlight del keynote e mi ha colpito immediatamente leggere che, fra qualche mese, Swift diventerà open source e sarà disponibile non più solo per OS X e iOS, ma anche per Linux.

È un segno dei tempi, l’open source è un fenomeno straordinario con il quale anche Apple deve fare i conti.

Ma significa anche che Apple si è finalmente decisa a diffondere Swift in un ambito più ampio, cercando di farlo adottare anche dagli sviluppatori non strettamente legati alla sua piattaforma.

Una bella notizia. Per quanto mi riguarda è un forte stimolo a iniziare a giocherellare con Swift. Speriamo che Apple renda disponibili ulteriori dettagli al più presto.

Automatizzare il Mac dal Terminale - Ancora Launchd

Tue, 28 Apr 2015 06:00:00 +0000

A volte bisogna saper ammettere i propri errori. Questa è una di quelle volte.

Nel mio post su launchd di qualche mese fa non avevo nascosto il mio scetticismo per una soluzione molto lontana dai canoni di Unix e troppo complicata per essere usata al posto di cron, il programma che nei sistemi operativi derivati da Unix è incaricato di eseguire periodicamente dei comandi o degli interi script in modo automatico.

Leggendo però questo post su MacStories, mi sono reso conto dell’esistenza di una ulteriore opzione di launchd, QueueDirectories, che permette di di tenere sotto controllo una (o più) directory del Mac e di eseguire automaticamente un comando ogni qualvolta si aggiunge un file alla directory osservata.¹ Oltre a questa esiste una opzione più generale, WatchPaths, che permette di tenere sotto controllo uno o più file (o directory) ed eseguire un comando quando uno di questi file (o directory) viene modificato.

Con queste due nuove (almeno per me!) opzioni si può estendere notevolmente il campo di applicazione di launchd, facendogli eseguire un comando o uno script non solo in modo periodico (in sostituzione di cron), ma anche al verificarsi di un evento come l’aggiunta di un file ad una directory o la modifica di un determinato file.

Launchd, l’osservatore

Riprendiamo quindi il file plist di configurazione del post precedente e vediamo cosa possiamo fare se aggiungiamo l’opzione QueueDirectories.

Il punto di partenza è sempre lo stesso: vogliamo eseguire automaticamente lo script ~/bin/makeblog e rigenerare automaticamente il blog “Pazzi per la mela”.

Questa volta però vogliamo rigenerare il blog non ad un’ora ben definita ed immutabile, ma solo quando inseriamo un nuovo post nella directory ~/Dropbox/blog/.

In questo caso usare Dropbox (o un qualunque servizio analogo, Box, Copy, Google Drive, o perfino OneDrive di Microsoft) è particolarmente utile, perché permette di aggiungere il post anche lontano dal Mac, magari dopo averlo preparato sull’iPad o sull’iPhone.

Il file plist di configurazione del post precedente diventa

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>it.pazziperlamela.makeblog</string>
	
	<key>Program</key>
	<string>/Users/utente/bin/makeblog</string>
	
	<key>QueueDirectories</key>
	<array>
    	<string>/Users/utente/Dropbox/blog/</string>
	</array>
	
	<key>StandardOutPath</key>
	<string>/Users/utente/Documenti/makeblog.log</string>
	
	<key>StandardErrorPath</key>
	<string>/Users/utente/Documenti/makeblog.err</string>

	<key>RunAtLoad</key>
	<false/>
</dict>
</plist>

Per attivarlo, come abbiamo già visto, basta salvarlo nella directory ~/Library/LaunchAgents/ del proprio account (dove il simbolo ~ indica la cartella Inizio o home dell’utente che sta usando il Mac) con il nome it.pazziperlamela.makeblog.plist (il nome del file deve essere uguale a quello senza estensione utilizzato alla riga 6 del file plist), ed eseguirlo una prima volta dal Terminale con il comando

$ launchctl load it.pazziperlamela.makeblog.plist

Ai successivi riavvii sarà il sistema operativo ad eseguire periodicamente lo script.

Conclusioni

Devo ammettere che le opzioni QueueDirectories e WatchPaths rendono launchd molto più interessante di quanto mi sia mai reso conto, permettendo di eseguire dei comandi di sistema o degli interi script in modo asincrono, al verificarsi di eventi particolari come la scrittura o la modifica di un file in una directory.

Intendiamoci, le mie riserve sulla complessità di launchd rimangono intatte. Inoltre continua a non piacermi il fatto che sia uno strumento confinato al solo OS X, con poche prospettive di diffusione al di fuori del mondo Apple fra i sistemi operativi derivati da Unix, come Linux e BSD.

Però pragmaticamente mi rendo conto che in certe circostanze launchd può rivelarsi uno strumento utilissimo e senza eguali. Basta solo usarlo con moderazione.

Qualcosa di simile alle cosiddette “Folder Actions”, introdotte già da parecchi anni in OS X senza troppo successo, che istruivano il sistema operativo a tenere sotto controllo una directory e ad eseguire dei comandi AppleScript o Automator ogni volta che un file veniva aggiunto o rimosso da quella directory, oppure quando quest’ultima veniva aperta, chiusa o spostata. ↩︎

Tante parole

Thu, 08 Jan 2015 06:00:00 +0000

Ogni volta che scrivo un post per questo blog mi sforzo di esporre l’argomento trattato nel modo più chiaro possibile e di presupporre che chi legge non sappia nulla, o quasi, dell’argomento trattato. L’aspetto negativo di questo atteggiamento è che mi obbliga a ripetere continuamente il significato di alcuni termini fondamentali, correndo il rischio di far perdere il filo del discorso a chi conosce già il significato di questi concetti e appesantendo il tono generale del post.

Per semplificare le cose ho quindi deciso di raccogliere le definizioni che mi vengono via via in mente in una pagina apposita, Le parole per dirlo, accessibile direttamente dal menu principale del blog.

La lista di definizioni inserite finora è piuttosto breve e segue un ordine vagamente logico. Magari con il tempo ci sarà bisogno di dare una struttura più ordinata alla lista.

Spero che non mancheranno i suggerimenti sui nuovi termini da inserire e le correzioni a quelli esistenti.

Linux on Melabit

Addio dc, benvenuta luka: una nuova calcolatrice RPN da Terminale

Premessa

Un po’ di storia

Notazione polacca inversa

Una calcolatrice nel Terminale

La calcolatrice RPN del XXI secolo

Evoluzione del codice

Usare luka

Conclusioni

Da melabit a melabit: Jekyll e l'hosting

Premessa

Perché non conviene usare un Mac

Perché non conviene fare da sé

Cosa conviene fare da sé

Cosa ho fatto io

Facciamo due conti

Da melabit a melabit: gestire i commenti con Jekyll

Alla ricerca del sistema ideale

Al lavoro su Comma

Mettere tutto insieme

Conclusioni

Da melabit a melabit: sviluppare un sito in Jekyll

Cosa vogliamo?

Come è fatto un tema

Mettiamo di nuovo Jekyll alla prova

Il tema di default non basta

Al lavoro!

Paginazione

Supporto multilingue

Miniature e commenti

Da melabit a melabit: Jekyll, installazione e configurazione di base

Installazione di Jekyll

Il primo sito in Jekyll

Jekyll e i temi grafici

E se Jekyll non ci piace più?

Alla prossima

Windows? No grazie!

Cinque ragioni

Tempo al tempo

Come controllare lo spazio occupato sul Mac con il Terminale

Quanto spazio occupano i miei file?

Comandi e interruttori

Ma ne vale la pena?

Ventoy, il boot manager per i geek curiosi - Installazione e uso

Installazione di Ventoy

Copia delle immagini iso sulla chiavetta

Uso pratico di Ventoy

E Windows?

Gli altri strumenti integrati in Ventoy

Conclusioni

Ancora una cosa…

Ventoy, il boot manager per i geek curiosi - Introduzione

Cos’è Ventoy?

Boot manager

Alternative a Ventoy?

Corsi e ricorsi

Mac OS X, vent'anni e non sentirli

Il CNR è anche questo: un po' di codice

Estrarre il testo da un file PDF

Generare automaticamente dei documenti con AWK

Mettere tutto insieme

Conclusioni

SSD o dischi meccanici? Perché non tutti e due? (prima parte)

Due dischi al posto di uno

Collegamenti simbolici

La falsa sicurezza delle app VPN per Android (e non solo)

RIP Linux Journal

Nostalgia di sfondo

Linux per tutti i giorni

Tante distribuzioni, troppe distribuzioni

Quali distribuzioni?

Debian

Linux Mint

Ubuntu

openSUSE

RedHat, Fedora, CentOS?

Pixel

FreBSD

Stabile o instabile?

Copia delle immagini `iso` sulla chiavetta