Macos on Melabit

macOS Tahoe: liberiamo le icone!

Mon, 24 Nov 2025 18:00:00 +0000

Non ci sono solo le icone dei dischi. Appena ho visto quello che Tahoe aveva fatto alle icone di tante applicazioni installate sul mio Mac, ho deciso che dovevo fare qualcosa per ripristinare l’aspetto delle icone originali.

Ci ho provato più volte, usando i tool di automazione di casa Apple, Automator e Comandi Rapidi ma niente, c’era sempre qualche funzione che mancava. O magari sono solo io che non sono capace di usarli.

Poi ho scoperto fileicon, una libreria disponibile su Homebrew che permette di modificare programmaticamente le icone di file e cartelle. E con quella il problema era praticamente risolto.

– Fonte: Hennie Stander su Unsplash.

La gabbia dello squircle

Con Tahoe Apple ha introdotto un nuovo formato di icone, che ora devono necessariamente adattarsi alla forma predefinita a squircle, una via di mezzo fra un quadrato e un cerchio (o una superellisse, per chi si diletta di matematica).

Apple ha ridisegnato le icone delle sue applicazioni per adattarle al nuovo formato e ai canoni estetici di Liquid Glass, anche se l’effetto finale è spesso molto discutibile. Persino John Gruber non risparmia critiche su questo aspetto, arrivando a definire chi ha disegnato l’icona di Automator un dilettante che non avrebbe mai dovuto ottenere un lavoro presso Apple (e come dargli torto?).

Il problema però non è solo che tante icone delle applicazioni Apple hanno perso significato o sono proprio brutte, ma anche che tante icone di applicazioni di terze parti non si adattano proprio alla gabbia rappresentata dallo squircle.

Succede a tutte quelle applicazioni che hanno icone che sono veri oggetti di design, come Audio Hijack, BBEdit, Alfred, Amphetamine, VLC, NValt, Gemini 2, HandBrake, Keyboard Maestro e così via.

Tutte applicazioni molto note, sviluppate da team medio-grandi, che però in tutti questi mesi non hanno ritenuto necessario (o utile) adattare le loro magnifiche icone ai nuovi canoni imposti da Tahoe.

E figuriamoci se l’hanno fatto gli sviluppatori più piccoli, o quelli che sviluppano applicazioni multipiattaforma nelle quali è essenziale avere un look grafico unico e ben riconoscibile.

E cosa succede in questi casi? Che Tahoe rimpicciolisce automaticamente le icone di queste applicazioni, racchiudendole all’interno dello squircle. Ma in sovrappiù, quasi a ricordare agli sviluppatori che devono sbrigarsi a rispettare i dettami di Cupertino, piazza queste icone su uno sfondo grigio che definire brutto è poco.

Nella prima beta di Tahoe il risultato finale era semplicemente orribile, come si può vedere nelle immagini del mio primo articolo su Tahoe. In sovrappiù, questo trattamento brutale rendeva alcune icone quasi invisibili (Tunnelblick, QGIS, OpenMV IDE, Thonny).

Nella versione pubblica di Tahoe rilasciata a settembre e negli aggiornamenti successivi, Apple ha attenuato certi eccessi di trasparenza di Liquid Glass e ha anche schiarito un po’ il grigio di sfondo delle icone recalcitranti allo squircle.

L’effetto finale è migliore, non c’è dubbio.¹ Però le icone bordate di grigio rimangono bruttine e molto più piccole di quanto potrebbero (e meriterebbero) essere.

Si può fare qualcosa per ripristinare l’aspetto che avevano prima della cura Tahoe?

Liberiamo le icone

Ovviamente la risposta è sì, altrimenti non avrei scritto questo articolo.

Il metodo per farlo a mano è descritto molto bene qui e richiede di fare click con il tasto destro sull’icona di una applicazione, selezionare Ottieni Informazioni e sostituire la miniatura dell’icona con quella che si trova all’interno dell’applicazione stessa.

Per trovarla, bisogna fare di nuovo click con il tasto destro sull’icona dell’applicazione selezionare Mostra contenuto pacchetto, cliccare sull’icona della cartella Contents e poi su Resources cercare il file con estensione .icns (tenendo conto che alcune applicazioni possono contenere più di un file di questo tipo) e trascinarlo sulla miniatura dell’icona della finestra di Ottieni informazioni.

Sembra complicato ma con un po’ di pratica si fa in fretta. Ma questo metodo manuale può funzionare se si hanno poche applicazioni da curare. Ma se, come nel mio caso se ne hanno più di 20, diventa rapidamente noioso e soggetto ad errori. Come se non bastasse, è probabile che vada ripetuto ogni volta che si aggiorna l’applicazione.

Meglio far fare tutto automaticamente al Mac. Ed è qui che entra in scena IconLib.

IconLib

IconLib è un piccolo script in Bash che automatizza tutto il processo, appoggiandosi alla libreria fileicon per eseguire la modifica vera e propria dell’icona. Basta dargli in pasto un file con la lista delle applicazioni da aggiornare – ed eventualmente anche con il nome del file .icns perché, mannaggia!, tanti sviluppatori usano per le icone dei nomi che non hanno niente a che fare con il nome dell’applicazione e tante volte mettono più di un file .icns all’interno del bundle dell’applicazione – e lui fa tutto il resto.

E se non siamo contenti del risultato, possiamo sempre eseguire di nuovo lo script con lo switch -u (per undo), ripristinando le icone di Tahoe.

Si può anche eseguire IconLib su una data lista di applicazioni e, successivamente, modificare l’elenco in modo da ripristinare le icone solo di alcune applicazioni, lasciando le altre nello stato precedente a Tahoe.

Tutti i dettagli sono nel file README del repository su GitHub e non li ripeterò qui. Qui invece mi limiterò a mostrare come appaiono le icone dopo la cura con IconLib.

Anche se le vecchie icone non rispettano i dettami stilistici dello squircle, l’aspetto più vario e meno costretto nello squircle e l’assenza dello sfondo grigiastro me le fa preferire, almeno finché gli sviluppatori non svilupperanno delle nuove icone adatte a Tahoe.

Lo ha appena fatto Bare Bones Software con BBedit. Ma il fatto stesso che una software house così importante ci abbia messo tanto tempo indica che non è uno scherzo, oppure che gli sviluppatori hanno sperato (invano) per mesi che Apple tornasse sui sui passi. E se BBEdit ci ha messo tanto, è difficile immaginare che altre applicazioni multipiattaforma o di nicchia possano adeguarsi in tempi brevi.

Conclusioni

IconLIb è un programma niente affatto indispensabile e che serve a pochi.

Serve prima di tutto a quelli come me, che hanno tanti programmi installati sul Mac, spesso prodotti da programmatori indie o da team specialistici che non hanno tempo, voglia e competenze per occuparsi di sottili questioni di grafica (penso ad esempio a Tunnelblick, per gestire le VPN, a Thonny, un programma indispensabile per chi programma i microcontrollori in Python, o a JASP che è uno dei migliori programmi grafici di statistica per chi di statistica ne mastica poca).

Serve anche a chi non è soddisfatto della gabbia in cui Tahoe costringe le (ex-)magnifiche icone di tante applicazioni.

E, infine, serve a chi pensa che Apple stia esagerando con questa deriva di macOS, che sembra sempre di più un sottoprodotto di iOS piuttosto che un sistema degno di una sua vita autonoma.

Ma già che c’erano non potevano usare uno sfondo bianco? ↩︎

Ancora macOS Tahoe

Mon, 10 Nov 2025 18:00:00 +0000

Dopo meno di due mesi dalla distribuzione ufficiale, Tahoe sembra avviato a diventare un altra di quelle versioni di macOS da dimenticare, come Lion, Mavericks, Sierra, Catalina o Ventura.

Del resto, tolto Liquid Glass, di cui parlerò fra un istante, cos’ha Tahoe di memorabile? C’è il filtro delle chiamate telefoniche, che però fa più parte di iOS che di macOS e che ha comunque molte limitazioni, e anche le funzioni di ricerca di Spotlight sono migliorate. Ma vale davvero la pena aggiornare un sistema operativo solo per questo?¹

Liquid Glass dovrebbe essere la vera novità di macOS 26 Tahoe, ma Macworld l’ha prima paragonato a Vista e poi l’ha dichiarato morto nella culla. Se lo dice Macworld – non PCWorld o Linux Pro – c’è davvero da preoccuparsi!

Del resto la cose con Liquid Glass sono andate storte fin dal primo momento, quando qualche bello spirito aveva pensato di invertire i colori dell’icona del Finder. Così, senza un motivo particolare, ma solo per cambiare.

Le critiche sono state così distruttive che Apple è dovuta tornare di corsa sui suoi passi ripristinando il design storico dell’icona del Finder, quello che conosciamo da trent’anni e che è uno dei segni distintivi di macOS.

Ma con le icone dei dischi Apple, se possibile, è riuscita a fare persino peggio. Nelle primissime beta di Tahoe le icone dei dischi erano identiche a quelle a cui siamo abituati da anni: l’immagine di un hard-disk meccanico per i dischi interni e un parallelepipedo stondato arancione per i dischi esterni. Tutto molto scheumorfico, ma anche molto chiaro e perfino bello da vedere, con tutte quelle vitine, i LED colorati e persino l’etichetta che ci avvisa di non aprire il disco.

Con la quinta beta di Tahoe, Apple butta nel cestino l’icona del vecchio hard-disk e la sostituisce con una immagine più stilizzata, che dovrebbe rappresentare il disco SSD installato ormai da molti anni su tutti i Mac.² Già che c’è, dà anche una rinfrescata anche alle altre icone dei dischi (esterni, di rete e rimovibili) ed il risultato lo vedete qui sotto, dove la riga superiore mostra le icone dei dischi fino a Sequoia e alle primissime beta di Tahoe, mentre la riga inferiore mostra le icone aggiornate.

– Fonte: Ars Technica.

Poco dopo l’icona del disco interno perde tutti gli elementi frontali, che forse volevano rappresentavano delle prese di areazione o LED di attività, e diventa minimale come le altre.

Le nuove icone sono banali, hanno perso tutti i dettagli in nome di una maggiore semplicità, proprio come è successo a tutto il resto dell’interfaccia grafica basata su Liquid Glass. Ma fin qui tutto sommato ci può stare.

Quello che è incomprensibile è perché le icone siano state ridisegnate in modo da sembrare più strette davanti e più larghe dietro, in barba alle leggi della prospettiva e a come siamo stati abituati a vederle fino a Sequoia. È solo una illusione ottica, in realtà (ho controllato) le icone hanno i lati perfettamente paralleli, ma i giochi di luci ed ombre ce le fanno sembrare strane e fuori posto.

L’effetto peggiora quando le icone vengono affiancate, perché le diverse riflessioni fanno apparire quella grigia del disco interno più naturale e meno distorta rispetto a quelle delle unità esterne.

Ora io capisco la necessità di adottare un linguaggio grafico omogeneo e ben definito, ma non era proprio possibile disegnare delle icone che apparissero più naturali? Ce l’ha fatta Susan Kare con soli 32x32 pixel, come possiamo pensare che non ce la facciano i designer Apple che oggi hanno praterie sterminate di pixel a disposizione?

Se oggi a Cupertino non riescono a fare nemmeno una icona convincente di un disco, come possiamo pensare che Tahoe e Liquid Glass siano una cosa seria?

Il ciclo annuale di aggiornamento di macOS sarà anche buono per il marketing, ma dal punto di vista tecnico non ha senso. Non solo perché è difficile riuscire a trovare ogni ogni anno nuove funzionalità sufficientemente interessanti per la prossima release di macOS. Ma anche perché questa ricerca della novità a tutti i costi distrae da attività altrettanto importanti, come la correzione dei bachi della versione corrente e l’ottimizzazione delle prestazioni del sistema. ↩︎
In realtà, la nuova icona del disco interno non ha niente a che fare con l’immagine di un vero disco SSD interno, ma non facciamo i sofisti. ↩︎

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. ↩︎

macOS Tahoe: Developer Beta 3

Tue, 22 Jul 2025 06:00:00 +0000

Pochi giorni fa, puntuale come sempre, Apple ha reso disponibile agli sviluppatori il terzo aggiornamento della Developer Beta di macOS 26, meglio conosciuto come Tahoe.

Una volta concluso l’aggiornamento, ci vuol poco per rendersi conto che Apple sta (lentamente) modificando qualcosa nell’interfaccia grafica Liquid Glass dell’ultima versione del suo sistema operativo.¹

Magari anche per venire incontro alle tante critiche che nell’ultimo mese le sono state rivolte da pezzi da novanta come Riccardo Mori – comunque la si pensi, il suo primo articolo su MacOS Tahoe e Liquid Glass è imperdibile (ma anche il primo e il secondo follow-up meritano di essere letti) – da John Gruber, Craig Hockenberry, Francisco Tolmasky, Louie Mantia, Marco Arment e da tanti altri, come si può leggere in una delle magistrali raccolte di Michael Tsai.² Nonché, nel suo piccolissimo, anche dal sottoscritto (qui e qui).

È una beta

Sgomberiamo il campo da un equivoco: criticare (con fondamento) la versione beta di un sistema operativo come macOS è una cosa buona e giusta.

Quando pubblica una beta Apple non ci fa un favore, concedendoci di usare in anteprima un prodotto non ancora pubblicato, ma piuttosto siamo noi che facciamo un favore ad Apple, analizzando e dissezionando il suo software in modi che magari non sarebbero mai venuti in mente agli sviluppatori e ai tester ufficiali.

Sostenere, come fanno in tanti, che “bisogna avere pazienza, tanto è una beta” o che “nelle beta ci sono sempre dei bug”, è una emerita sciocchezza, perché è proprio in questa fase, quando il prodotto viene provato sul campo, che vengono fuori quelle magagne che gli sviluppatori ufficiali, abituati a lavorarci su ogni giorno da mesi, ormai non notano più.³

Del resto, se negli ultimi anni Apple ha esteso l’accesso alle sue Developer Beta ad un pubblico molto più ampio, significa che quello che viene fatto in questa fase le serve, eccome se le serve!

Lo sfondo

La prima cosa che si nota accedendo al Mac dopo l’aggiornamento è il nuovo sfondo di default, che ora ci mostra la riva sassosa del lago Tahoe, circondata da una lunga catena di montagne innevate (del Nevada?).

A me questi sfondi naturali non piacciono molto, ci sono troppi particolari che distraggono e impediscono di vedere con chiarezza quello che c’è sul Desktop. Però, rispetto allo sfondo anonimo di prima (che c’è ancora) non c’è confronto, per cui va bene così. E poi il leggero effetto di increspatura delle onde, che purtroppo nello screenshot non si vede, è davvero delizioso!

Aver cambiato in corsa lo sfondo attivo di default però, sembra indicare qualche problema nella direzione di sviluppo di Tahoe/Liquid Glass, come diventerà ancora più evidente nella prossima sezione.

Questa a onor del vero è una modifica introdotta nella beta precedente, di cui non ho avuto modo di scrivere qui. Apple ha aggiunto una opzione per ripristinare lo sfondo della barra del menu (Impostazioni di Sistema > Barra dei Menu > Show menu bar background), proprio come accadeva in Sequoia e nelle versioni precedenti di macOS.

Secondo me è un’ottima decisione perché, dopo aver usato per alcune settimane macOS Tahoe, mi sono accorto che è inutile avere a disposizione una barra di menu trasparente. Per almeno due motivi.

Il primo è che con la barra trasparente le voci di menu e le icone tendono a confondersi con lo sfondo, diventando molto meno leggibili. Questo effetto è particolarmente grave quando lo sfondo è pieno di dettagli e di gradienti, come nell’esempio qui sotto.

La differenza in termini di chiarezza con la barra dei menu con lo sfondo è evidente.

Il secondo motivo è che, anche se la barra del menu è trasparente, non può essere (giustamente) occupata dalle finestre delle applicazioni, per cui non si guadagna nemmeno spazio utile per le applicazioni.

A che serve davvero avere una barra dei menu trasparente, se questa è meno leggibile e non aumenta lo spazio utile per le applicazioni? Solo per ottenere un (discutibile) effetto visivo più omogeneo, ma senza nessun vantaggio funzionale?

Io uso il computer per lavorare, non passo la giornata a rimirare il desktop. E perché mai dovrei fare più fatica a leggere le voci dei menu o il livello della batteria, la qualità della connessione Wi-Fi e tutte le altre icone che stanno lì per uno scopo preciso, solo perché qualche designer da quattro soldi ha deciso che la barra dei menu deve confondersi con il resto del desktop?

È sorprendente però che, dopo ben due release della Developer Beta, l’impostazione non sia ancora stata tradotta in italiano e, immagino, nelle altre lingue. È un piccolo dettaglio, ma che dà l’impressione di una cosa un po’ raffazzonata e buttata lì alla bell’e meglio, sulla quale il team che lavora su questa parte di Tahoe non ha ancora le idee ben chiare.

Rafforzando così i dubbi su come procede lo sviluppo di Tahoe, espressi benissimo da Craig Grannelli.

[questo cambiamento] mi fa anche dubitare della fiducia di Apple nel suo lavoro di progettazione. Quando Apple inizia a fare le sue scommesse, segnala che sa che qualcosa non va, ma non ha la convinzione di correggere la rotta. O forse queste impostazioni sono un mezzo per zittire temporaneamente le persone, mentre le scelte predefinite rivelano il vero intento e la direzione di marcia.

Le Impostazioni di Sistema

Nel mio primo articolo su Tahoe avevo segnalato il fatto che la nuova voce Aspetto delle Impostazioni di Sistema si comportava in maniera strana: impostando la modalità Auto nella sezione relativa agli stili di icone (e widget) Dark, Clear e Tinted non si osservava apparentemente nessun effetto.

Nell’articolo avevo ipotizzato che questa modalità consentisse al sistema operativo di adattare da solo i dettagli di visualizzazione dello stile di icone e dei widget prescelto al modo Light o Dark attivo. Facevo però anche notare che l’implementazione sembrava piuttosto confusionaria.

In realtà non era una implementazione mal fatta, era un vero e proprio baco, come riportato nelle Release Notes di questa beta.

Finder
Resolved Issues

Fixed: Finder does not display Dark Mode app icons or tinted folder colors when the Folder Color setting in System Settings > Appearance is set to Automatic. (152193702)

Purtroppo, anche se Apple sostiene di aver corretto il problema, non vedo nessuna differenza rispetto a prima. Quello che vedo benissimo, invece, è che certe combinazioni di impostazioni rendono le icone così poco contrastate da rendere molto difficile distinguere una dall’altra.

Il Finder

Appena ho aperto il Finder ho avuto l’impressione che Apple avesse diminuito l’intensità dell’ombra sui gruppi separati di icone che ora costituiscono la Barra degli Strumenti.

Purtroppo non è così, l’intensità dell’ombra, così come la trasparenza delle icone è identica a prima, producendo lo stesso pasticcio di colori descritto nell’articolo precedente tutte le volte che le icone più sgargianti della finestra principale del Finder finiscono al di sotto di quelle della Barra degli Strumenti.

Per evitarlo, sarebbe sufficiente che la Barra degli Strumenti del Finder conservasse lo sfondo bianco presente a partire da Big Sur (n sostituzione di quello metallico precedente). In questo modo, le icone mostrate nella finestra principale del Finder rimarrebbero visibili solo in questa finestra, senza più sconfinare nell’area riservata alla Barra degli Strumenti.⁴

Più uso il neo-Finder di Tahoe e più mi chiedo che senso abbia questa confusione di ruoli, nella quale la Barra degli Strumenti – che non sta lì per bellezza ma che serve per gestire i file e per spostarsi all’interno del file system del Mac – si deve confondere e sovrapporre ai file stessi, in un mix indistinto che non è nemmeno bello da guardare?

Tanto più che nemmeno gli sviluppatori Apple sembrano tanto convinti delle loro scelte perché, se dalla vista ad Icona si passa alla vista ad Elenco, si ritrova la solita separazione netta fra la finestra principale e la Barra degli Strumenti (a parte l’effetto tridimensionale aggiunto a quest’ultima da Liquid Glass).

E se cambiamo ancora vista e passiamo a quella in Colonna, ritroviamo una terza modalità diversa e intermedia fra le due precedenti, nella quale c’è uno sfondo bianco sotto la Barra degli Stumenti, ma dove le icone delle applicazioni e dei file vengono sfocate ben prima di arrivare sotto la Barra degli Stumenti, come invece succede nella normale vista ad Icona.

Questa confusione nella modalità di visualizzazione della Barra degli Strumenti, non è presente solo nel Finder ma anche in applicazioni come Note dove, a seconda della modalità di visualizzazione scelta, ci si può ritrovare con una Barra degli strumenti trasparente, che sfoca malamente tutto ciò che ci finisce sotto,

oppure con una normalissima barra con lo sfondo bianco, come siamo abituati a vedere da Big Sur in poi.

Qualcosa di simile succede anche con Libro Font, anche se con modalità leggermente diverse, mentre non succede con Freeform o Anteprima, che hano una Barra degli Strumenti sempre trasparente. Reminders è un altro caso particolare, ma vi lascio il piacere di scoprire da soli perché.

Insomma, la confusione regna sovrana dalle parti di Cupertino e sembra che nemmeno gli sviluppatori riescano a decidere cosa sarebbe meglio fare con la nuova Barra degli Strumenti in stile Liquid Glass.

Le icone delle applicazioni

Alle nuove icone delle applicazioni voglio dedicare una sezione separata da quella del Finder, perché qui non si tratta più di una semplice questione di gusti, ma di rapporto con gli sviluppatori. I quali, non dimentichiamolo mai, sono fondamentali per il successo di una piattaforma.

Ricapitolo brevemente la questione.

In macOS Tahoe Apple ha introdotto un nuovo formato di icone per le applicazioni, mutuato da iOS. Le nuove icone hanno la forma di uno squircle (in italiano un supercerchio), una forma geometrica intermedia fra il cerchio e il quadrato, e possono essere create con il nuovo Icon Composer. Questo nuovo formato permette, fra l’altro, di adattare dinamicamente le icone allo stile, o meglio all’Aspetto, prescelto (si veda la sezione relativa alle Impostazioni di Sistema).

Fin qui tutto bene.

Il problema nasce dal fatto che non c’è scelta: le icone di tutte le applicazioni installate sul Mac non possono più avere una forma personalizzata, come ad esempio quella di BBEdit che sto usando per scrivere questo articolo, ma devono obbligatoriamente adottare la forma a squircle.

Tutte le icone delle applicazioni che non si sono ancora adeguate ai nuovi dettami stilistici imposti da Liquid Glass vengono racchiuse automaticamente in uno squircle con dietro un orribile sfondo grigio scuro, che sembra messo lì apposta per segnalare quei prodotti cattivi che non si sono ancora adeguati alle nuove linee guida Apple.⁵

Ma rifare le icone non è una passeggiata. Non l’hanno ancora fatto, ad esempio, quelli di Bare Bones Software, che non sono esattamente degli indie sprovveduti. Il loro prodotto di punta BBedit ha ricevuto un aggiornamento pesante proprio pochi giorni fa, ma ha mantenuto la sua icona tradizionale.

Gli sviluppatori indipendenti sono ancora meno entusiasti di dover rifare tutte le icone delle loro applicazioni seguendo il nuovo formato imposto da Apple.

Non lo è, ad esempio, Howard Oakley, che definisce ironicamente macOS Tahoe come il distruttore di icone, ed equipara lo squircle con lo sfondo grigio ad un sin bin, ovvero alla zona del campo dove viene confinato temporaneamente un giocatore che ha fatto un fallo.⁶ Qualcun altro ci va giù ancora più pesante e definisce lo squircle una vera e propria prigione.

Anche chi decide di adeguarsi ha dei problemi perché, come ci racconta il solito Howard Oakley, non è detto che le icone aggiornate per Tahoe funzionino correttamente anche nelle versioni precedenti di macOS.

La metà delle applicazioni installate sul Mac che ho aggiornato a macOS Tahoe ha le icone grigie, e nel mese e mezzo intercorso dalla prima Developer Beta ad oggi credo che nessuna di queste abbia adottato il nuovo formato di icone. Non l’ha fatto nemmeno Chrome di Google, a cui non mancano di certo i mezzi per adeguarsi in un batter d’occhio. Perfino alcune applicazioni Apple non seguono le sue stesse linee guida, ad esempio Garage Band o XCode. Il caso di quest’ultimo è particolarmente significativo, visto che XCode è lo strumento principale per sviluppare le applicazioni per il Mac.

La mia impressione è che l’interfaccia grafica di Tahoe non sia scolpita nel marmo – oops nel vetro – e che gli sviluppatori preferiscono aspettare la versione finale prima di adeguarsi ai dettami di Apple.

Del resto, fra le 26 Developer Beta 1 e Beta 2 Apple ha già cambiato l’icona del Finder, causa sollevazione popolare, e ha aggiunto l’opzione per ripristinare lo sfondo della barra dei menu. Per cui è chiaro che Apple non è insensibile alle critiche espresse da chi sta provando in anteprima Tahoe.⁷

Dimenticavo: chi vuole può ripristinare le solite icone anche in Tahoe, ma è un processo manuale e piuttosto noioso, che va ripetuto per ogni applicazione interessata e per ogni Mac. Io passo.

Prestazioni

La terza Developer Beta di macOS Tahoe sembra molto più lenta delle due versioni precedenti. Ad esempio, Firefox ci può mettere una vita per partire e ripristinare le schede precedenti, ma un po’ tutte le applicazioni appaiono più legnose, in particolare in avvio, di quanto è lecito aspettarsi su Apple Silicon. Anche certi pannelli delle Impostazioni di Sistema a volte appaiono completamente vuoti, e solo dopo parecchi secondi riescono a visualizzare le opzioni disponibili.

Per quanto noioso, questo è un comportamento normale in una beta, che per sua natura è infarcita di codice di debug e di funzioni ancora immature o poco testate, che magari generano memory leak, usi erronei della cache e cose simili. Se lo segnalo qui è solo perché le prime due Developer Beta apparivano molto più reattive di questa.

In ogni caso, un riavvio risolve, almeno temporaneamente, il problema, in attesa del rilascio della versione definitiva.

Conclusioni

Fra pochi giorni, forse domani stesso, Apple renderà disponibile a tutti la beta di Tahoe, che quindi potrà essere provata da un pubblico molto più ampio e variegato.

Come ho già detto, la vicenda dell’icona del Finder modificata in corsa dimostra che Apple non è sorda alle critiche sulla nuova interfaccia di macOS, e quindi c’è speranza che qualcosa venga corretto nei due mesi che si separano dal rilascio ufficiale della nuova versione di macOS.

Se poi qualcuno pensa che gli articoli critici come quelli citati qui sopra, e persino queste notarelle che avete appena letto, vengono scritti solo allo scopo di acchiappare facili click… beh, pazienza, gli autori se ne faranno una ragione.

Sta facendo lo stesso per la versione corrispondente di iPadOS (che sto provando sul mio iPad Pro) e di iOS (che per ora invece lascio stare). ↩︎
Riccardo Mori si autodefinisce un traduttore ed uno scrittore, ma in realtà ha grosse competenze anche nel campo del design e della tipografia. John Gruber scrive da più anni di quanto possa ricordare uno dei blog più importanti dedicati all’universo Apple ed è l’inventore di Markdown. Craig Hockenberry è uno sviluppatore che ha prodotto fra l’altro Tot, che io adoro, ed è una delle anime di Iconfactory. Francisco Tolmasky è stato un membro del team original dell’iPhone, nel quale ha contribuito a sviluppare Safari per iOS, ed è il creatore di Objective-J, un superset di JavaScript, e di Cappuccino, un “framework open source che semplifica la creazione di applicazioni di livello desktop eseguite in un browser web”. Louie Mantia è un artista e un grafico specializzato nel design di icone. Marco Arment è uno sviluppatore di applicazioni per iOS e per il web, oltre che “scrittore, produttore di podcast, geek e amante del caffè”. ↩︎
Succede più o meno lo stesso quando si scrive: se si fa leggere un testo ad una terza persona, questa nota molto più facilmente degli errori a cui l’autore, che ormai conosce il testo a memoria, non fa più caso. ↩︎
Come è normale che sia e come è sempre successo, non solo in macOS (o Mac OS X, o come lo volete chiamare), da Sequoia e andando indietro nel tempo fino a Cheetah, ma anche nelle versioni di Mac OS prodotte per tutti gli anni ‘80 e ‘90. ↩︎
Per fare un paragone sportivo, Apple sembra più o meno come quell’arbitro di calcio che tira fuori il cartellino giallo mentre avverte il centravanti che “alla prossima sciocchezza ti butto fuori”. ↩︎
Giuro che, quando ho scritto il paragone calcistico della nota precedente, non avevo ancora letto questo commento di Howard Oakley. ↩︎
Non posso evitare di pensare che se Steve Jobs avesse visto come sarebbero diventate certe icone del suo Finder, avrebbe cacciato i responsabili a calci nel sedere. ↩︎

macOS Tahoe: dov'è il Terminale?

Tue, 08 Jul 2025 06:00:00 +0000

– Immagine generata da Google Gemini.

Prendete macOS Tahoe, aggiornato alla versione 26.0 Developer Beta 2, e aprite il Terminale. Anzi non apritene solo uno, aprite due, tre, quattro Terminali diversi, ciascuno nel suo pannello. Più o meno così:

A questo punto ditemi: qual’è il Terminale attivo in questo momento?

Per rispondere dovrete aguzzare lo sguardo, e solo allora vi accorgerete che la barra del titolo del Terminale attivo è di un grigio appena appena più scuro degli altri, e che il titolo stesso è in grassetto.

Rifate lo stesso giochetto con Sequoia, o con qualunque versione precedente di macOS, e vedrete a colpo d’occhio qual’è il Terminale che state usando.

In realtà, un modo per distinguere il Terminale in uso esiste anche in Tahoe, ma è contro-intuitivo e richiede l’uso del mouse. Se si sposta il mouse sopra la barra del Terminale attivo non si vede nessun cambiamento,

mentre, quando si sposta mentre il mouse sopra il pannello di uno dei Terminali inattivi, lo sfondo diventa più scuro.

A tanti sembrerà un dettaglio trascurabile, ma il Terminale è uno strumento essenziale per interagire a basso livello con il sistema operativo e viene usato da gente che non possono permettersi di perdere tempo a cercare il Terminale giusto o, peggio ancora!, di rischiare di inserire un comando pericoloso nel Terminale sbagliato.

Per fare un esempio concreto: per gestire questo blog uso tre pannelli del Terminale, ciascuno dedicato ad un compito specifico. In uno di questi lavoro via ssh su un sito privato di test, che mi serve per verificare che tutto funzioni prima di caricare il blog sul vero server. Essendo un ambiente di prova, sono abituato a cancellare tutto con un brutale rm -r *. Oggi posso farlo senza problemi, perché so a colpo d’occhio e senza bisogno di leggere che sono nel Terminale giusto. Ma con Tahoe dovrò cambiare abitudini, perché eseguire lo stesso comando nel pannello sbagliato potrebbe avere conseguenze catastrofiche.¹

Fra tutte le incongruenze di macOS Tahoe, questa è forse è la più incomprensibile, e potenzialmente la più pericolosa.

A questo punto una domanda è d’obbligo: ma gli sviluppatori Apple usano davvero i prodotti che realizzano?

Certo, io per non fare errori prendo ulteriori precauzioni, come assegnare colori diversi ai vari Terminali. Ma il problema di fondo rimane. ↩︎

macOS Tahoe: rimandato a settembre

Sat, 28 Jun 2025 06:00:00 +0000

Sta diventando una abitudine. All’inizio di quest’anno, invece di aspettare, come al solito, che fosse già pronta (o quasi) la versione successiva di macOS prima di installare quella corrente, ho installato Sequoia su tutti i miei Mac. Pochi giorni fa ho deciso di saltare il fosso, installando la primissima beta di Tahoe, quella riservata agli sviluppatori, su un Mac che uso poco, più che altro per provare la nuova interfaccia grafica Liquid Glass su macOS.¹

Dato che è la prima volta che provo una beta di macOS, non sono in grado di valutare se le versioni precedenti fossero più o meno mature di Tahoe in questa fase dello sviluppo, ancora molto lontana dal rilascio ufficiale.

Di conseguenza, mi limiterò a descrivere le mie prime impressioni sulla nuova interfaccia grafica, concentrandomi in particolare sul Finder, che è una delle applicazioni più usate in assoluto, e sulle Impostazioni di Sistema, che è fondamentale quando si prende confidenza con un nuovo sistema operativo. Dopo il rilascio ufficiale a settembre, ci sarà sarà tempo per una valutazione più approfondita.

Aggiornamento

L’aggiornamento da Sequoia 15.5 a Tahoe 26 Beta pesa poco più di 7 GB, che mi pare in linea con gli aggiornamenti precedenti, anzi forse è perfino un filo sotto la media.

L’installazione del nuovo sistema operativo è veloce, non so dire esattamente quanto ci ha messo, ma ricordo di essermi sorpreso quando ho visto che aveva finito.

La prima cosa che si vede dopo l’aggiornamento è questa schermata, che ci mostra una anteprima di Liquid Glass, con i suoi bottoni in rilievo rispetto al resto della finestra. Qui non si vede nessun effetto di trasparenza, ma ci sarà tempo anche per quella.

Una volta premuto Continua compare il Welcome Screen di Tahoe che, poverino, sembra una scritta fatta con il dentifricio sovrapposta allo sfondo di default del mio Mac. Purtroppo sono passati da un pezzo i tempi dei magnifici Welcome Video delle prime versioni di macOS, quelle con i nomi di felini.

Da qui si arriva direttamente al Desktop del Mac, che ora mostra alcuni widget sul lato sinistro della schermata (alcuni widget sembrano non funzionare solo perché gli screenshot sono stati fatti la sera tardi al mare, senza attivare il collegamento ad internet).

I widget non mi sono mai piaciuti. Su Tiger e seguenti ne usavo alcuni, ma solo perché erano in una schermata ben separata, la Dashboard. Averli invece in bella vista sul Desktop che uso tutto il giorno mi da fastidio, e so già che, appena finito quest’articolo, li eliminerò senza pensarci due volte.

Ma c’è tempo, per ora cambio lo sfondo e ci metto quello di default di Tahoe.²

Devo ammettere che lo sfondo non mi fa impazzire: ci sono troppi dettagli e troppi gradienti per i miei gusti, e il contrasto con le icone chiare, come quella del disco, è troppo scarso. Però nessuno mi obbliga ad usare proprio questo sfondo, per cui è un non-problema.

Il Finder

Un problema reale, invece, sono le icone delle applicazioni con lo sfondo grigio scuro, la cui visione mi ha fatto saltare sulla sedia appena ho aperto il Finder.³

Le icone originali avevano uno sfondo trasparente, per accorgersene basta cambiare lo sfondo della cartella Applicazioni di Sequoia o di versioni precedenti di macOS. Per motivi imperscrutabili, in Tahoe questo sfondo invisibile viene sostituito da uno di colore grigio scuro, che definire orribile è fargli un complimento.

Le applicazioni Apple, naturalmente, non hanno questo problema mentre, come si vede nell’immagine precedente, alcune fra quelle più diffuse ne sono affette, una su tutte Google Chrome.

Ma se scendo verso la sezione delle applicazioni meno note, trovo un sacco di orride icone bordate di grigio! In alcuni casi, le icone vengono pure rimpicciolite, forse per effetto delle nuove regole di adattamento dinamico di Liquid Glass, rendendo ancora più ampia l’area colorata in grigio. Ma chi è che ha ideato una roba del genere?

Ma questa non è l’unico aspetto discutibile del nuovo Finder. Qui la familiare Barra degli Strumenti del Finder è stata sostituita da gruppi separati di icone translucenti, che sembrano fluttuare al di sopra della finestra principale.

La modifica sembra un po’ raffazzonata, anche perché si sono dimenticati di mettere in rilievo il nome della cartella. Però, quando sotto queste icone c’è uno sfondo chiaro, la nuova barra degli strumenti può essere considerata accettabile, anche se inconsistente (come si vede in alcune delle immagini precedenti).

Ma, quando le icone translucenti della Barra degli Strumenti si sovrappongono alle icone più colorate della finestra principale del Finder (come nell’immagine qui sotto), si forma un guazzabuglio di colori che non solo è brutto da vedere, ma rende pure difficile distinguere una icona della Barra degli Strumenti dall’altra.

Forse una sfocatura più spinta o una trasparenza minore potrebbe evitare il problema. Ma a quel punto non sarebbe meglio mantenere la vecchia barra chiara con sopra le icone flottanti?

E poi, io capisco pure che ora bisogna ficcare ovunque il concetto di liquido, ma era proprio necessario trasformare il cursore nella barra di stato del Finder (quello in basso a destra che permette di ingrandire e rimpicciolire le icone) in una capsula così grossa, ma allo stesso tempo quasi invisibile?

Il nuovo cestino dei rifiuti invece non è male, è più moderno di quello cilindrico a cui siamo abituati da sempre. Mi chiedo come potrebbe stare in piedi ma, si sa, lo skeumorfismo è morto da tempo.

Sempre rimanendo in tema Finder: qualcuno mi spiega perché la finestra delle Impostazioni del Finder mantiene ancora gli angoli poco smussati di Sequoia e perché le sue icone sono meno spesse di quelle della barra laterale della finestra principale?

La nuova Apps

Niente male, invece, la nuova applicazione Apps, che raggruppa le applicazioni installate in modo logico, un po’ come succede su iOS. Di sicuro sembra meglio di Launchpad, che ho provato ad usare ma che ho subito abbandonato,⁴ anche se non mi piace molto il fatto che siano necessari due click per accedere alle applicazioni di un dato gruppo.

Mission Control non è cambiata, e la cosa mi va benissimo perché lo uso di continuo e mi peserebbe dover cambiare abitudini. Lo stesso vale per gli Scacchi, a cui non gioco mai perché perdo sempre, ma che è presente da sempre in macOS (e c’era anche nel papà, NeXTSTEP).

Anche le altre applicazioni di default non sembrano essere cambiate più di tanto, ma per questo mi riservo di fare una valutazione più approfondita più avanti.

Le Impostazioni di Sistema

Infine uno sguardo alle Impostazioni di Sistema. Non dirò nulla sul fatto che ormai non ci si capisce nulla: fino a Monterey bastava un colpo d’occhio per trovare l’impostazione giusta, ma da quando macOS scimmiotta iOS bisogna usare sistematicamente la funzione di ricerca per trovare l’impostazione che serve.⁵

Dirò qualcosa invece sulla nuova funzione che cambia globalmente i colori delle icone e dei widget di macOS Tahoe. Qui si vede lo stile di Default delle icone (e dei widget) che, a parte il bordo grigiastro di cui ho già detto, è quello a cui siamo sempre stati abituati.

Questa immagine, invece, mostra cosa succede si attiva lo stile Dark. Le icone delle applicazioni visibili nel Finder non cambiano – probabilmente perché devono essere aggiornate per supportare questo nuovo stile – mentre cambiano tutte le icone della applicazioni Apple visibili nel Dock. Il tema Light però non rende giustizia a questo nuovo stile,

mentre con il tema Dark è tutta un’altra cosa.

Però, se attivo lo stile Dark e scelgo la modalità Auto, tutta l’interfaccia torna ad essere identica allo stile di Default. Lo si può vedere nelle due immagini qui sotto, dove la prima mostra lo schermo del Mac quando è attivo lo stile Dark e la modalità Auto, mentre la seconda mostra lo stile di Default.

Immagino che la modalità Auto voglia indicare che il sistema operativo sceglie da solo i dettagli di stile più adatti al modo Light o Dark in uso. Una cosa sensata, ma che forse andrebbe implementata in modo diverso, perché messa così confonde solo le idee.

Gli altri due stili Clear e Tinted sono carini, ma francamente avere tutte le icone dello stesso colore non mi alletta più di tanto. A tanti questi nuovi stili omogenei piaceranno di certo, ma io dubito che li userò mai.

Anche con questi stili, la modalità Auto adatta da sola l’aspetto al tema in uso. Anche in questo caso, mi pare che vada rivista sia la posizione che la titolazione della modalità automatica.

Non male, invece, la possibilità di cambiare il colore di accento dell’interfaccia grafica.

Non sono un appassionato di queste cose, ma a tanti piacciono e comunque non stravolgono l’interfaccia, per cui perché no?

Perla finale: l’interruttore, davvero gigantesco, che attiva il Bluetooth (ma anche il Wi-Fi o la VPN). È vero, anche in Sequoia questi interruttori erano più grandi di tutti gli altri, ma non vi sembra che quelli di Apple questa volta abbiano esagerato un po'?

Conclusioni (per ora)

Qui si conclude questa veloce carrellata su macOS Tahoe, e sulla sua interfaccia grafica Liquid Glass. Se ho dato l’impressione di non esserne entusiasta, ebbene sì, è proprio così.

Mi piace molto che Apple abbia avuto il coraggio di cambiare, provando a sviluppare una interfaccia grafica omogenea per tutti i suoi dispositivi. Liquid Glass ha di sicuro molte potenzialità, ma su macOS è ancora molto immaturo, forse ancora più immaturo che su iPad. Mi ricorda la transizione metallica di Leopard, che ha avuto bisogno di diverse versioni successive di macOS per essere affinata.

In ogni caso, Liquid Glass è il futuro e ci dovremo convivere per parecchi anni. Per cui meglio apprezzarne già da ora gli aspetti positivi ed essere pazienti su quelli negativi.

Nel frattempo gli sviluppatori Apple hanno sistemato l’icona al contrario del Finder, che aveva destato tanto scalpore. Speriamo che prima del rilascio ufficiale di settembre facciano lo stesso per le tante altre stranezze e incongruenze.

Sull’iPad Liquid Glass è interessante, anche se ancora piuttosto acerbo. ↩︎
A meno che non siano proprio brutti, come alcuni sfondi per Linux, io uso sempre gli sfondi di default. Io non sono un fanatico della personalizzazione estrema del sistema, e usare lo sfondo di default mi aiuta a sapere a colpo d’occhio che versione del sistema operativo sto usando. E comunque gli sfondi di default di macOS sono quasi sempre molto belli. ↩︎
In realtà queste icone ingrigite si vedevano già nel Dock. Ma sarà stata l’ora tarda, sarà stato il basso contrasto, non ci avevo fatto caso. ↩︎
Ad esempio, perché tendeva a perdere il layout impostato a mano e non permetteva di sincronizzarlo fra un Mac e l’altro. ↩︎
Qualcuno potrebbe obiettare che avere un layout simile fra macOS e iOS è positivo. E in effetti è così, peccato solo che le impostazioni di iOS siano sempre state una delle cose più confusionarie che abbia mai visto. Per cui al limite sarebbe stato più saggio fare il contrario, adattando a iOS il modello di impostazioni di macOS. ↩︎

WWDC 25

Thu, 12 Jun 2025 06:00:00 +0000

Qual’è stato l’ultimo WWDC davvero memorabile? Direi quello del 2020, anno già memorabile di suo, quando Apple presentò i nuovi Mac con processore Apple Silicon, in grado di surclassare i modelli equivalenti basati su CPU Intel.

Non so se ciò che è stato presentato al WWDC di quest’anno sarà altrettanto memorabile, però non c’è dubbio che Apple abbia partorito alcune novità interessanti.

Prima fra tutte un aggiornamento di iPadOS che introduce finalmente (e ci voleva tanto?) le finestra sovrapponibili e una gestione più decente del filesystem, mandando di fatto in pensione Stage Manager.

Non ho mai amato Stage Manager. L’ho sempre trovato fastidioso e troppo limitato, con le sue quattro-e-non-più-di-quattro mini-finestre laterali che vanno e vengono, senza che si possa fissarne una al suo posto una volta per tutte. Penso che pochi ne sentiranno la mancanza.

Le nuove finestre sovrapponibili di iPadOS 26 profumeranno pure di “vecchia scuola”, ma funzionano da 40 anni e sono di sicuro più intuitive e facili da gestire. Se devo cambiare, Apple mi deve offrire qualcosa di meglio, non di peggio.

Avere finalmente Anteprima e Calcolatrice sull’iPad è un bonus non da poco, da utente più che soddisfatto di Anteprima sono molto curioso di provarla sull’iPad.

L’altra novità importante è la nuova interfaccia grafica “Liquid Glass”, estesa a tutte le piattaforme Apple, dal Mac all’iPhone e fino a Vision Pro. Al di là dell’aspetto in sé, oggi vetroso domani chissà, quello che è importante è che da ora in poi tutte le piattaforme Apple parleranno la stessa lingua grafica, con un indubbio vantaggio in termini di facilità di uso del sistema e, credo, anche di sviluppo delle applicazioni.

Che poi Liquid Glass sia la versione moderna di Aqua mi pare evidente ad una prima occhiata. Nei primissimi anni 2000 sono tornato al Mac da Linux non solo perché aveva UNIX sotto il cofano, ma anche perché Aqua mi piaceva da morire.

Il successivo passaggio ad un tema grafico metallico e poi ai toni di grigio spento di oggi, per quanto eleganti non mi hanno mai fatto impazzire, per cui aspetto con molta curiosità di vedere Aqua 2.0 in azione.

Del resto del keynote, lo ammetto, ricordo poco. Che ora l’Apple Watch mi faccia credere che corro meglio di Jacobs mi importa meno di zero. Idem per l’ora che si allunga o si accorcia a seconda dello sfondo dell’iPhone. O per le onnipresenti Memoji. Però se hanno tanto spazio significa che piacciono, e quindi forse sono io quello sbagliato.

Che Apple migliori le applicazioni integrate nei suoi sistemi operativi dovrebbe essere di normale amministrazione. Però questa mania di nascondere le funzioni sta diventano un filino patologica (vero Fotocamera?).

Call Screening, invece, potrebbe fare la differenza, ammesso che funzioni qui da noi.

Che poi Federighi non scoppi a ridere mentre afferma che nell’ultimo anno Apple Intelligence è stata rilevante, la dice lunga su quante volte è stata ripetuta la scena.

Dimenticavo: la nuova numerazione dei sistemi operativi. Magari è un bene che sia unica per tutti, ma era proprio necessario usare l’anno (e pure sbagliato)? Ci ha già provato Microsoft con Windows 95, Windows 98 e Windows 2000. Non era proprio possibile inventare qualcosa di più originale?

E comunque questa unificazione obbligherà Apple a far uscire ogni anno una nuova versione di una mezza dozzina di sistemi operativi diversi, anche quando non ci sarà uno straccio di nuova funzione degna di nota. Personalmente credo che un ciclo annuale di rilascio sia eccessivo e non sostenibile a lungo termine. Ma evidentemente il marketing di Apple ha sempre bisogno di qualcosa di nuovo, che poi sia utile o funzioni è un altro paio di maniche.

Una nota finale un po’ triste. Ma come è possibile che, in un’ora e mezza di keynote, Tim Cook e soci non siano riusciti a ritagliare un minuto per ricordare Bill Atkinson? E in una conferenza di sviluppatori, per di più!

Se Apple è quella che è oggi, è anche per il suo contributo. RIP.

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. ↩︎

Apple abbiamo risolto dei problemi: da Sonoma a Sequoia

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

– Immagine generata dall’IA di Microsoft Designer.

Negli ultimi mesi ho scritto ben quattro articoli sui bachi di macOS Sonoma (la lista completa si trova alla fine di questo articolo), perché mi sembrava incredibile che questa versione di macOS fosse stata pubblicata con dei bachi così evidenti nel Finder e nella gestione del disco .

Nelle versioni più recenti di Sonoma, alcuni bachi segnalati – come quello dello svuotamento ballerino del cestino, del nome del file di default quando si stampa virtualmente in PDF una pagina web, o della mancata visualizzazione di un nuovo file o di una nuova cartella nella modalità Allinea alla griglia — sono stati corretti, ma quelli più seccanti sono rimasti lì, intoccati.

Un paio di giorni fa, dopo aver provato macOS Sequoia su una macchina che uso come muletto, ho deciso di aggiornare anche il Mac Mini M1 che ho a casa a Sequoia 15.3 e, con grandissima soddisfazione, posso dire che tutti, o quasi, i bachi più gravi riportati in quegli articoli sono scomparsi.¹

Baco #1: Se abbiamo una cartella piena di file e ne trasciniamo le icone sotto il limite inferiore della finestra mentre premiamo il tasto CMD (⌘), il limite inferiore della finestra ora si estende correttamente e visualizza anche le icone poste più in basso, senza più dare l’impressione che i file siano scomparsi. Unica eccezione è quando la cartella non ha la barra di scorrimento attiva perché i file contenuti sono pochi. In questo caso le icone continuano a scomparire, proprio come con Sonoma, ma perlomeno ora basta cliccare sull’icona < in alto a sinistra sulla barra degli strumenti per poi tornare alla cartella di partenza per ripristinare la visualizzazione completa dei file.

Baco #2: Se in uno Spazio abbiamo due finestre del Finder sovrapposte e usiamo le combinazioni di tasti CTRL(⌃)-1 e CTRL–2 e così via per trascinare la finestra in primo piano da uno spazio all’altro, al ritorno nello Spazio di partenza la finestra viaggiatrice_ ora finisce sopra quella rimasta ferma, come è giusto che sia. Lo stesso avviene quando le finestre sovrapposte sono più di due.

Baco #3: Anche lo sfarfallio ben visibile con Sonoma quando si trascinava una finestra del Finder da uno Spazio all’altro ora è scomparso. Osservare una cosa del genere era semplicemente scandaloso, non solo perché avveniva su macchine che montano processori potentissimi come gli Apple Silicon, ma anche perché prima di Sonoma questo sfarfallio non si era mai verificato su macchine molto, molto meno prestanti, come i Mac Book Air Intel.

Baco #4: Sequoia ha anche corretto il baco relativo alla finestra che scompariva più veloce di una Formula 1 quando si collegava una chiavetta USB ad un portatile, ma di questo ne avevo già scritto a suo tempo.

Baco #5: Il Finder è finalmente tornato alla normalità quando deve mostrare cartelle di un disco esterno USB contenenti qualche centinaio di file. La lentezza (per dire poco) sperimentata con Sonoma era davvero seccante, e non ce la facevo più a dover aspettare decine e decine di secondi ogni volta che dovevo accedere ad una cartella esterna un po’ piena.

Baco #6: Ma la vera chicca di Sequoia, quella con la quale gli dò già un 8 secco alla fine del primo quadrimestre, è il fatto che, per la prima volta dopo anni ed anni, l’aggiornamento di macOS non ha scombinato la disposizione delle icone nella cartella Applicazioni. Saranno pochissimi quelli che, come me, preferiscono tenere organizzate le applicazioni installate in modo visuale invece che alfabetico. Ma voglio farmi lo stesso portavoce di questi quattro gatti e ringraziare di cuore gli sviluppatori Apple per una correzione che aspettavamo da non so più quante versioni di macOS.²

Che dire? Sono davvero molto soddisfatto che con Sequoia Apple sia riuscita a correggere tanti bachi imbarazzanti di Sonoma. Anche perché quelli che avevo segnalato non erano bachi legati a funzioni esotiche del sistema operativo o del file system, ma problemi ben evidenti a chiunque usasse l’interfaccia grafica di macOS.

Purtroppo non credo che in quel di Cupertino ci sia qualcuno che compulsa avidamente le pagine di Melabit. Ma questo significa anche che le criticità segnalate negli articoli precedenti erano dei problemi concreti ed evidenti anche ad altri utenti, nonché agli stessi sviluppatori di Apple, e non solo le preoccupazioni immaginarie di un utente un po’ troppo zelante.

Rimane il problema di fondo, e cioè che non ha senso continuare con questa politica di rilasci annuali di nuove versioni di macOS (ma anche di iOS, iPadOS, watchOS e così via), ciascuno infarcito di nuove funzioni luccicanti ma quasi sempre inutili, che rimangono per forza di cose poco testate e che magari portano nuovi bachi nei fondamenti del sistema operativo, senza dare il tempo di correggere i bachi già presenti.

Un ciclo annuale di nuove release sarà senza dubbio utile per il marketing, ma è proprio quello che serve agli utenti?

Per chi fosse interessato alla mia saga sui bachi (e non solo) di macOS Sonoma, ecco i link alle puntate precedenti:

Tanto che subito dopo ho aggiornato anche il Mac Studio che uso per lavoro. ↩︎
Mi pare evidente che non c’era nessun motivo tecnico alla base del problema (come ad esempio la separazione rigida fra le applicazioni installate di default in macOS e quelle installate dall’utente), ma solo una scarsa attenzione a un dettaglio che sarà pure minore, ma che è piuttosto seccante per chi ne fa uso. ↩︎

Mac bloccato? Come ripristinarlo con la modalità DFU

Tue, 19 Nov 2024 06:00:00 +0000

– Fonte: Apple Support.

Quando si sperimenta può succedere che qualcosa vada storto. Ed è proprio quello che è capitato a me quando, dopo una installazione andata male di macOS, è comparso questo grande punto interrogativo con l’invito perentorio a visitare la pagina dedicata al ripristino dello stato del Mac.

Da qualche anno, quando un Mac non è più in grado di avviare macOS e non riesce nemmeno ad eseguire Recupero di macOS (macOS Recovery) per riparare o reinstallare il sistema operativo, l’unico modo per riportarlo ad uno stato funzionante è attivare la modalità DFU (Device Firmware Upgrade), che è memorizzata in una ROM e quindi non può essere cancellata in alcun modo.¹

La modalità DFU si usa da anni (da sempre?) per riportare in vita un iPhone o un iPad (ma anche l’iPod, l’Apple TV e l’Apple Watch). Questa modalità richiede di collegare il dispositivo al Mac premendo una combinazione di tasti predefinita, per poi procedere con il ripristino direttamente dal computer.

Con i Mac Intel la procedura di ripristino era diversa, perché tramite le combinazioni di tasti CMD (⌘) ed R, oppure ALT (⌥), CMD (⌘) ed R oppure SHIFT (⇧), ALT (⌥), CMD (⌘) ed R si poteva eseguire l’avvio da macOS Recovery dai server Apple, scaricando e reinstallando una versione di macOS diversa a seconda della combinazione di tasti utilizzata.

Nel 2018, con l’introduzione del chip di sicurezza T2, l’avvio da internet è stato mandato in soffitta, e la modalità DFU è diventata l’unico modo per ripristinare un Mac che non ne vuole sapere di avviarsi. Il problema è che questo significa che bisogna avere a disposizione un secondo Mac funzionante, che per fortuna può essere sia Apple Silicon che Intel.

Ma non basta. Perché, oltre al secondo Mac, per ripristinare un Mac in modalità DFU ci vogliono altri tre elementi, nonché un pizzico di coordinazione.

Serve prima di tutto un cavo USB-C per collegare il Mac ammalato con quello funzionante, che funge da dottore. In teoria i cavi di terze parti non funzionano, ma almeno uno della mia collezione riesce ad attivare senza problemi la modalità DFU. Se però volete stare sul sicuro ed usare un cavo originale Apple, vi consiglio il cavo da 1 metro, che è lungo quanto basta e costa una cifra decente. Altrimenti, c’è il cavo da 2 metri, che però ha un prezzo da rapina (un metro di fili di rame in più e un po’ di plastica non costano certo dieci euro). In ogni caso, acquistare il cavo vi costa sempre molto meno di un viaggetto all’Apple Store più vicino.

Dimenticavo, se il Mac che funge da dottore non ha una porta USB-C si può usare una comune porta USB-A (tramite apposito adattatore, tipo questo o anche questo, provato di persona).

Il cavo andrà collegato alla porta DFU del Mac da ripristinare (mentre per l’altro Mac si può usare qualunque porta USB) Qual’è la porta DFU? Dipende, la descrizione dettagliata la trovate qui. Ad esempio, nel MacBook che ho dovuto recuperare la porta DFU è quella più vicina allo schermo LCD. Ma non sarebbe stato più semplice mettere una iconcina vicino alla porta corretta?

Infine, bisogna scaricare Apple Configurator 2 dall’App Store sul Mac usato per il ripristino. Con le versioni più recenti di macOS si potrebbe anche usare il Finder, ma Apple Configurator funziona bene ed è (secondo me) molto più comodo da usare.

Una volta che avete preparato tutto, lanciate Apple Configurator 2 sul Mac dottore e tenetelo in primo piano.

A questo punto, se dovete ripristinare un Mac desktop vi basterà scollegare il cavo di alimentazione, premere il tasto di accensione mentre ricollegate il cavo di alimentazione, e aspettare 10 secondi. Sullo schermo di Apple Configurator comparirà un grosso quadratone con la scritta DFU e il più è fatto.

Se invece dovete ripristinare un MacBook dovrete armarvi di un po’ di pazienza, perché non è detto che la procedura di attivazione della modalità DFU funzioni al primo colpo. O almeno, questo è successo a me che ho provato a seguire alla lettera le istruzioni ufficiali di Apple, che suggerivano di premere la combinazione di quattro tasti necessari per attivare la modalità DFU per circa 10 secondi (io premevo sempre per più di 10 secondi, per essere sicuro di aver aspettato un tempo sufficiente).

Per fortuna, dopo un po’ di tentativi andati a vuoto ho trovato questo video del grande Mr. Macintosh, ho seguito le sue istruzioni e finalmente sono riuscito ad attivare la modalità DFU.²

Attivata la modalità DFU, avete due possibilità. La prima è quella di provare a far rivivere il Mac, ripristinando macOS Recovery sul Mac ammalato senza cancellare il contenuto del disco di sistema. Per farlo, dovete premere con il tasto destro del mouse sul quadratone DFU di Apple Configurator, selezionare Advanced e poi Revive e aspettare che il Mac scarichi l’immagine della macOS Recovery e la trasferisca al Mac che non si avvia. Se il processo funziona vi ritroverete di nuovo con un Mac perfettamente funzionante, con tutti i file e le applicazioni al loro posto.

Ma se, come è successo a me, il semplice Revive non funziona, dovrete eseguire il processo più radicale di Restore, che riporterà il Mac allo stato di fabbrica e installerà la versione più recente di macOS.

Il Restore si esegue premendo con il tasto destro del mouse sul quadratone DFU e selezionando la voce Restore del menu principale. Dopo che Apple Configurator vi avrà chiesto se siete davvero sicuri di voler resettare il Mac allo stato di fabbrica, inizierà il processo di scaricamento di reinstallazione di macOS sul Mac ammalato, che può tranquillamente durare un’ora o più, a seconda della velocità della vostra rete.

Alla fine della reinstallazione di macOS vi ritroverete con un Mac guarito al 100%, ma avrete perso tutti i vostri file e le applicazioni installate. Non è un grosso problema, perché potrete facilmente ripristinare tutto da Time Machine (perché usate sempre Time Machine, no?).

A meno di malfunzionamenti hardware, che richiedono obbligatoriamente l’intervento dell’assistenza. ↩︎
Esiste anche un video più recente con altri due metodi per mettere un MacBook in modalità DFU, ma in genere il metodo originale dovrebbe essere più che sufficiente. ↩︎

Apple abbiamo un altro problema: un nuovo baco di macOS Sonoma

Thu, 14 Nov 2024 06:00:00 +0000

– Immagine generata dall’IA di Microsoft Designer.

I bachi di Sonoma non mancano mai di sorprendere, e qui descrivo un baco fresco fresco, che per fortuna è stato corretto in Sequoia.

Prendete un MacBook Air o Pro nuovo, dove avete appena installato Sonoma, oppure un MacBook dove prima di installare Sonoma avete cancellato il disco di avvio (quello che succede aggiornando semplicemente da una versione precedente potrebbe essere diverso).

Provate a inserire una chiavetta o un disco esterno USB (o anche, quando c’è, una scheda SD). Quello che vedrete sarà questo.

Cioè non vedrete praticamente niente, anche al rallentatore.

In teoria, macOS dovrebbe far comparire una finestra a scomparsa che chiede all’utente se vuole consentire il collegamento dell’accessorio USB (come lo definisce Apple) al Mac. Peccato solo che, come si vede nel video, il pop-up scompaia più veloce di un’auto di Formula 1.

Devo dire che le prime volte che mi è successo non vedevo nemmeno quello. Solo dopo alcuni tentativi infruttuosi e sempre più frustanti, un’ombra velocissima sullo schermo mi ha fatto pensare ad una finestra a scomparsa troppo zelante.

Questo baco si verifica con macOS Sonoma 14.6, non ho idea se anche le versioni precedenti ne siano soggette. Per ovviare al problema bisogna andare nelle Impostazioni di Sistema alla voce Privacy e sicurezza e modificare l’opzione Consenti il collegamento degli accessori da Chiedi ogni volta, oppure Chiedi per i nuovi accessori, in Sempre.

Una volta collegata l’unità USB, per maggiore sicurezza si può tornare a selezionare l’opzione Chiedi per i nuovi accessori, ricordandosi di ripetere la procedura ogni volta che si inserisce una nuova chiavetta (o disco esterno).

A prima vista sembra strano che la richiesta di consenso per il collegamento dei nuovi accessori compaia solo nei MacBook e non nei Mac desktop.

Ma a ben pensarci la cosa ha un senso. Non credo che gli sviluppatori di macOS vogliano impedirci di collegare le chiavette USB di nostra proprietà o quelle delle persone che conosciamo. Credo, invece, che vogliano evitare che qualcuno inserisca di soppiatto una chiavetta cattiva (detta anche Rubber Ducky), che ormai si può anche fare in casa con un Raspberry Pi Pico da pochi spiccioli.

Queste chiavette sono programmabili e possono fare danni molto seri ad un computer, dal trasferire automaticamente sulla chiavetta dei file riservati,¹ fino a cancellare – se chi la programma è in possesso della password di un account amministrativo – tutto il disco di sistema.

Inutile dire che è più facile che un attacco di questo tipo avvenga su un MacBook, lasciato spesso incustodito, piuttosto che su un computer desktop, che rimane stabilmente in ambienti più controllati come la casa o l’ufficio.

Inserire un controllo di sicurezza di questo tipo nel sistema operativo è quindi un’ottima idea, ciò che è pessimo è il modo in cui è stata implementata in macOS Sonoma.

La buona notizia è che su macOS Sequoia il baco è stato corretto e la finestra rimane ben visibile sullo schermo finché l’utente non effettua una scelta.

Per chi fosse interessato alla mia saga sui bachi (e non solo) di macOS Sonoma, ecco i link agli articoli precedenti:

Non è affatto detto che succeda solo a chi progetta un velivolo stealth, perché potrebbero più prosaicamente essere i documenti di un divorzio o di una controversia finanziaria. ↩︎

Al limite della memoria

Wed, 23 Oct 2024 06:00:00 +0000

Mi sa di aver esagerato un po’ con Firefox … O è Firefox (versione 131) che non riesce a liberare correttamente la memoria (virtuale, 92 GB di RAM su questo Mac me li sogno)?

Quale che sia la ragione, subito dopo aver scattato questa foto il mio Mac è andato in crash, con conseguente riavvio e necessità di risistemare le (tante) finestre aperte.

Per fortuna su macOS questi arresti anomali sono rari, ma quando si verificano il sistema operativo non riesce mai a ripristinare lo stato precedente della sessione. Se qualcuno dalle parti di Cupertino ha un po’ di tempo libero e ci volesse pensare… 😇

Per quanto mi riguarda, sarebbe ben più utile della possibilità di customizzare all’infinito lo schermo dell’iPhone.

Nove nove

Sat, 31 Aug 2024 06:00:00 +0000

– Immagine generata da Flux Image AI.

Fra pochi giorni, è ufficiale, Apple terrà l’evento di inizio settembre “It’s Glowtime”, durante il quale presenterà i nuovi iPhone e Apple Watch e rilascerà le versioni definitive (magari fosse davvero così!) di iOS e macOS.

E ormai la cosa, lasciatemelo dire, mi lascia indifferente.

Sarà perché questi eventi periodici finiscono per somigliarsi tutti: stesso periodo dell’anno, stesso format, stessa enfasi un po’ artificiosa. Una sorta di rito laico.¹

Sarà per il fatto che l’iPhone è un prodotto più che maturo ed è difficile inventarsi ogni anno una nuova diavoleria che faccia rizzare i capelli sulla testa e far venire l’acquolina in bocca. Quest’anno ci sarebbe Apple Intelligence, ma è ancora incompleta e comunque non ci tocca, perché per ora è riservata ai modelli Pro e Pro Max e al solo mercato statunitense.²

Sarà perché compro solo quando mi serve, non perché devo avere a tutti i costi l’ultimissimo oggetto del desiderio, che sia un iPhone, un iPad, un iWatch o chissà che altro.

Sarà infine per il fatto che ormai manca pure l’effetto sorpresa di qualche anno fa. I siti di rumors, e di conseguenza Macworld, ci hanno descritto per filo e per segno da mesi come saranno i nuovi modelli di iPhone e affini e ormai ci prendono al 100%. L’unica cosa che non si capisce è se sia Apple che fa filtrare volutamente le notizie o se sia la filiera produttiva così estesa che rende impossibile mantenere anche il più piccolo segreto.

Da parte mia preferirei che i nuovi prodotti Apple – che siano i prodotti hardware come l’iPhone, l’iPad o il Mac, oppure le varie incarnazioni dei relativi sistemi operativi – fossero presentati quando sono pronti e non solo perché bisogna rispettare una cadenza annuale.

Ne soffrirebbe il marketing, ma ne guadagnerebbero gli utenti finali.

In una prima versione avevo scritto che sembravano una festa del santo patrono (di cui mi importa ancor meno che dell’evento settembrino di Apple). ↩︎
Tutti gli altri dovranno consolarsi con la possibilità di usare l’iPhone tramite il Mac o di poter riconoscere la scrittura sull’iPad (che secondo me è la cosa più interessante in assoluto). ↩︎

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

Apple abbiamo un problema: uno sguardo ai bachi di macOS Sonoma (aggiornamento)

Fri, 31 May 2024 06:00:00 +0000

– Immagine generata dall’IA di Microsoft Designer.

Un paio di mesi fa ho elencato alcuni bachi più o meno gravi di Sonoma di cui mi sono accorto mentre prendevo confidenza con l’ultima versione di macOS, prima sul nuovo Mac Studio M2 Ultra e poi sul Mac Mini M1 di casa.

In quel momento stavo usando macOS Sonoma 14.3, che poco dopo ho aggiornato sul Mini alla versione 14.3.1. Con questa minor release Apple ha corretto un paio dei bachi descritti, in particolare il baco relativo allo svuotamento del Cestino in uno Spazio a casaccio e quello che impediva di dare un nome decente ai file PDF generati dalla funzione di Stampa.

Poiché uso la funzione di Stampa (virtuale) dei PDF soprattutto in Firefox, mi è venuto il dubbio che quest’ultimo baco fosse legato al browser piuttosto che al sistema operativo. Ma non è così. Sul Mini aggiornato il problema è scomparso, ma il Mac Studio, rimasto più a lungo alla versione 14.3, ha continuato a darmi fastidio nonostante avesse esattamente lo stesso browser del Mini.

Ora su entrambe le macchine è installato macOS 14.5 e anche sul Mac Studio il problema dei nomi dei PDF è scomparso. Tutti gli altri bachi segnalati continuano invece a presentarsi allegramente. Anzi, con questo post aggiungo due nuovi bachi, uno dei quali è finito immediatamente in cima alla mia lista di seccature.

Il primo me l’ha segnalato Mimmo (grazie!) ai tempi di Sonoma 14.3 e riguardava Safari che ogni tanto nascondeva il testo contenuto nella selezione, come si può vedere nell’immagine qui sotto.

Non è un problema gravissimo, mi rendo conto, ma sorprende in un prodotto di un’azienda attenta ai minimi dettagli come Apple. L’avranno pensato anche dalle parti di Cupertino, dato che sembra essere stato risolto con il passaggio dalla versione 14.3 alla 14.5. Meglio così.

L’altro baco è così evidente che non capisco come mi sia sfuggita prima: ogni volta che apro una cartella con un gran numero di file, il Finder di Sonoma impiega un’eternità a mostrarli.

Da anni utilizzo un disco esterno USB per tenere tutto ciò che desidero conservare ma che non ho bisogno quotidianamente. Alcune cartelle contengono migliaia e migliaia di file, ma fino ad ora la visualizzazione del loro contenuto è sempre stata istantanea, o quasi. E questo anche se il disco è (o meglio era, ma di questo parlo dopo) un semplice disco meccanico, di qualità ma pur sempre meccanico.

Con Sonoma improvvisamente è cambiato tutto: ogni volta che apro una cartella molto piena, mi tocca aspettare diverse decine di secondi prima di vederne il contenuto. E quando dico decine di secondi intendo 40, 50, persino 60 secondi per una cartella con dentro 1.000-2.000 elementi. Che saranno tanti, ma non sono certo la fine del mondo.

La cosa strana è che fino a Monterey, con lo stesso disco esterno, la visualizzazione era praticamente istantanea, quindi escludo che sia un problema di lentezza del disco o del collegamento con il Mac.

Per togliermi il dubbio ho perfino acquistato un disco SSD NVMe da 2 TB, che ho installato in un hub esterno collegato al Mini tramite la porta USB-C. Ora la visualizzazione del contenuto delle cartelle è più veloce (e ci mancherebbe!) ma sempre molto meno veloce di quello che sarebbe normale aspettarsi. A occhio ci mette la metà del tempo di prima, che per un SSD NVMe, anche se esterno, mi pare comunque un risultato inaccettabile.

Spero che Apple si sia accorta del problema e che ci metta una pezza con macOS 15. Altrimenti mi toccherà davvero scrivere un bug report, e non ne ho la minima voglia.

Da Intel ad Apple Silicon

Mon, 11 Mar 2024 06:00:00 +0000

– Fonte: Viktor Forgacs su Unsplash.

La transizione è conclusa, da alcuni giorni tutti i computer che uso per lavorare funzionano con un processore ARM Apple Silicon: un Mac Studio M2 Ultra di cui ho già parlato a lungo e che sta sulla scrivania del mio ufficio, un Mac Mini M1 16 GB/1 TB – rimasto semidimenticato su uno scaffale per motivi che non sto qui a dire – nell’ufficio casalingo e un Mac Book Air M1 molto molto basico (appena 8 GB di RAM e 256 GB di SSD, la metà di quello di mia moglie) per usi light e per quando devo andare in giro.

Dimenticavo, dalla scorsa estate c’è anche un iPad Pro 11" M1 che è una vera meraviglia e merita un post a sé stante.

Sul Mac Studio e sul Mini gira Sonoma, che non mi fa impazzire ma ormai c’è e ce lo dobbiamo tenere, mentre l’Air ha ancora Monterey. Appena possibile aggiornerò anche quello a Sonoma, per avere un ambiente coerente su tutte le macchine.

Inutile dire che, rispetto ai modelli Intel che ho usato prevalentemente finora, le prestazioni sono di un altro pianeta. I benchmark dicono già molto, ma ancora di più vale l’esperienza di ogni giorno, i programmi che si aprono in un amen, la fluidità delle applicazioni più avide di risorse, gli script in Python o R che prima richiedevano di minuti di attesa e ora invece finiscono quasi prima di poter battere ciglio.

Un altro indice della velocità di queste macchine è il tempo impiegato per installare (come al solito) da zero il sistema operativo e tutti gli applicativi che mi servono (e sono parecchi).

Con il Mini ho fatto tutto in un solo giorno (e si tratta di un centinaio di applicazioni da scaricare, registrare configurare una ad una), mentre un secondo giorno mi è servito per le cose più fini, come copiare i file da un Mac all’altro, configurare i meandri del sistema (una cosa piuttosto complicata che, per fortuna, la maggior parte degli utenti può risparmiarsi) e installare strumenti da Terminale come homebrew e conda, che per me sono essenziali per lavorare.

Rosetta si è installata da sola la prima volte che ho aperto una applicazione solo Intel e finora tutte le applicazioni che ho installato girano senza problemi, anche quelle più di nicchia che richiedono librerie più o meno specializzate. Del resto sono passati più di tre anni dalla presentazione dei primi Mac M1 e le asperità iniziali dovrebbero essere state risolte da tempo.

Insomma, la transizione da Intel ad Apple Silicon è stata facile, più facile di quello che mi sarei aspettato all’inizio e forse persino più facile del passaggio precedente da PowerPC a Intel. In ogni caso, molto più facile che attraversare una strada trafficata di Roma negli anni ‘60.

P.S. E i vecchi Mac che fine fanno? Come ho già scritto altrove, ho in mente un nuovo progetto per riutilizzarli al meglio, le prime prove sono molto positive ma prima di scriverne preferisco essere sicuro di certi dettagli. Stay tuned!

Quando iCloud non va...

Fri, 01 Mar 2024 06:00:00 +0000

– Fonte: Polina Kuzovkova su Unsplash.

Per chi usa il Mac, iCloud è lo strumento più semplice e naturale per sincronizzare i propri file con computer diversi (sì, anche se usano Windows o Linux) o con l’iPhone e l’iPad. Costa un pelo più dei concorrenti ma è studiato specificatamente per i prodotti Apple, funziona bene ed è veloce a sufficienza, non mi pare che ci sia partita.

Ma anche iCloud ogni tanto si incrocchia e rimane bloccato, senza più riuscire a completare la sincronizzazione.

– Tante grazie a kOoLiNuS per l’immagine!

La soluzione più immediata è riavviare il Mac, cosa che risolve quasi sempre il problema senza troppa fatica.

Ma riavviare il computer può essere seccante per chi ha sempre molte finestre aperte, oppure se ha l’abitudine di tenere sempre acceso il computer (come faccio io). In realtà riavviare non serve, basta solo interrompere il processo bird, che gira di continuo nel retrobottega del Mac.

Per farlo ci sono due modi diversi ma equivalenti:

selezionando il processo bird nella scheda CPU di Monitoraggio Attività (si trova in Applicazioni > Utility) e cliccando sull’icona di Stop (⊗) nella barra dell’applicazione;
aprendo il Terminale (anche questo si trova in Applicazioni > Utility) ed eseguendo il comando

killall bird

In entrambi i casi il processo verrà interrotto e fatto ripartire automaticamente, risolvendo (quasi sempre) il problema senza alcun bisogno di riavviare.

Sonoma: c'è del buono

Mon, 26 Feb 2024 06:00:00 +0000

– Immagine generata dall’IA di Microsoft Designer.

Sonoma è ancora acerbo e con un discreto numero di bachi, ma per fortuna anche qui c’è del buono.

Per quanto mi riguarda, mi piace che Condivisione Schermo (Screen Sharing) abbia preso finalmente piena cittadinanza sul Mac, prendendo posto nella cartella Utility delle Applicazioni del Mac, invece che essere relegato in /System/Library/CoreServices/Applications, come è stato finora.

Potrei sbagliare, ma ricordo che una applicazione analoga, Apple Remote Desktop era presente in Utility diversi anni fa (più o meno ai tempi di Tiger o di Leopard, magari fra i tool opzionali da scegliere durante l’installazione), ma che Apple sia rapidamente tornata sui sui passi nascondendo l’applicazione di accesso remoto fra i servizi di sistema di macOS e richiamandola attraverso la voce di menu del Finder Vai > Connessione al server oppure tramite la sezione Posizioni (Locations) della barra laterale.¹

Ma tornando ad oggi e a Sonoma, la cosa più interessante della nuova Condivisione Schermo è che l’applicazione ora presenti una storia di tutte le connessioni eseguite, permettendo di ricollegarsi con facilità ai computer usati più spesso e di creare gruppi coerenti di connessioni ai diversi computer che usiamo.

Avere a disposizione una applicazione vera e propria permette anche di poterla configurare secondo le proprie preferenze personali, una cosa che in effetti si poteva fare anche con l’applicazione pre-Sonoma, ma di cui io stesso mi sono accorto solo ora, scrivendo queste righe.

Perché sono cosi entusiasta di Condivisione Schermo? Perché lavorando spesso in rete trovo molto interessante avere a disposizione uno strumento nativo che abbia funzioni più avanzate di quelle offerte in precedenza. Peccato solo che Apple usi il protocollo vnc per il collegamento ai Mac remoti, un protocollo con tanti problemi di sicurezza e che per questo viene spesso bloccato dai firewall, limitando l’uso di fatto di Condivisione Schermo alle sole reti locali.

Un vero peccato, perché dopo anni di lavoro parzialmente da remoto posso dire che Condivisione Schermo è molto più efficiente di Teamviewer (che ho smesso di usare da tempo) o di Chrome Remote Desktop, che uso attualmente anche se non mi soddisfa al 100%.

Questi ultimi quattro anni ci hanno insegnato che lavorare da remoto si può ma che ci vogliono gli strumenti giusti per farlo. Per cui, dopo tante critiche, un ben fatto ad Apple è doveroso.

Sull’App Store è anche disponibile una versione avanzata di Apple Remote Desktop a 89.99 euro, un prezzo non proprio popolare per chi ne ha bisogno solo occasionalmente, ma assolutamente adeguato a che ne fa un uso professionale. ↩︎

Apple abbiamo altri problemi: uno sguardo ai bachi d'epoca di macOS

Thu, 22 Feb 2024 06:00:00 +0000

– Immagine generata dall’IA di Microsoft Designer.

Nell’ultimo post ho descritto alcuni bachi freschissimi presenti in Sonoma, la versione più recente di macOS.

I bachi riportati qui, invece, si trascinano da svariate versioni di macOS e sembra che Apple non abbia nessuna voglia di sistemarli o che non li consideri dei veri e propri bachi. Questi problemi però, a differenza di altri report, non si verificano in condizioni estreme o dopo aver aperto un dazillione di file ma in normalissime condizioni d’uso, e quindi mi pare ancora più strano che non siano mai stati risolti.

I primi due sono più che altro incongruenze dell’interfaccia utente, molto sorprendenti se si considera l’attenzione quasi maniacale che Apple dedica ai minimi dettagli di design dei propri prodotti.

La barra di scorrimento (scrollbar) della lista delle applicazioni acquistate dall’App Store è parzialmente nascosta dal titolo della finestra e compare solo dopo aver scorso un certo numero di applicazioni (quante dipende dal numero totale di applicazioni presenti nella lista, se sono tante bisogna scendere parecchio per rivedere la barra).
La stessa cosa succede nella pagina iniziale dell’App Store quando si sposta il mouse nella parte superiore della finestra facendone comparire il titolo. Qui però gli elementi contenuti nella pagina sono pochi e quindi una parte della scrollbar rimane sempre visibile.

Questo invece è un vecchio baco relativo al Terminale.

Ho configurato le Impostazioni di Sistema > Scrivania e Dock in modo che l’opzione Preferisci pannelli quando apri i documenti sia sempre attiva. In questo modo, ogni volta che apro una nuova finestra nelle applicazioni che supportano questa funzione (fra cui il Terminale), macOS crea al suo posto un nuovo pannello all’interno della finestra già aperta.

Ma se sto usando il Terminale con una configurazione personalizzata (ad esempio la mia ha 120 colonne x 40 righe) e seleziono la voce di menu Nuova Finestra scegliendo un profilo che ha una dimensione diversa (ad esempio quella di default di 80 colonne x 24 righe), viene sì creato un nuovo pannello, ma tutto il Terminale cambia dimensione e assume quelle del profilo appena scelto.

In effetti questa potrebbe anche essere una scelta progettuale degli sviluppatori. Scelta che però contrasta con quello che succede quando l’opzione Preferisci pannelli quando apri i documenti è attiva solo a pieno schermo, perché qui il nuovo pannello assume invece la dimensione di quello di partenza.

Va detto che con High Sierra era perfino peggio: ogni volta che si apriva un nuovo pannello il Terminale perdeva una riga. Per fortuna questo baco è stato corretto nella versione successiva di macOS.

Questo baco, per me che uso sempre la modalità Allinea alla griglia nelle finestre del Finder e ordino le icone dei file in modo visuale seguendo un ordine logico (almeno per me) e lasciando spesso degli spazi vuoti, è una grandissima seccatura.

Fino a El Capitan, se spostavo le icone di una cartella al di sotto del bordo inferiore della finestra, il Finder non faceva una piega e manteneva l’ordine delle icone spostate, lasciando uno spazio vuoto dove queste si trovavano in origine. Da Sierra in poi, invece, il bordo inferiore della finestra del Finder è diventato una specie di barriera invalicabile, per cui la stessa operazione fa rimbalzare le icone che sarebbero finite sotto il bordo nella parte superiore della finestra, ora rimasta vuota.

Per evitarlo, bisogna trascinare le icone premendo contemporaneamente il tasto CMD (⌘), che in teoria serve per bypassare l’allineamento alla griglia, obbligando a ripristinare l’ordine delle icone in un secondo momento.

Questa chicca finale, quello che senza dubbio è il mio baco preferito di macOS, non è solo una seccatura ma, per dirla alla Camilleri, una grandissima rottura di cabasisi.

Proprio come per i documenti, io organizzo le applicazioni in modo visuale, raggruppandole in base alla tipologia e a quanto spesso le uso, e allinenando le icone alla griglia virtuale del Finder.

Di conseguenza, lascio in cima alla finestra Applicazioni tutte le applicazioni preinstallate di casa Apple e quelle che aggiungo io subito dopo la prima configurazione del sistema operativo, Pages, Numbers, Keynote, XCode, iMovie, GarageBand e così via. Subito sotto ci sono quelle da ufficio (la suite Office 365 e LibreOffice, gestori di PDF), quelle per la comunicazione (Teams, Webex, Skype), poi i browser e le applicazioni di sincronizzazione e accesso remoto. Ancora più giù le applicazioni più specifiche per il mio lavoro, per scrivere, prendere note e gestire gli articoli, editare le immagini, sviluppare codice. In fondo finiscono le utility varie per tenere sotto controllo la temperatura del Mac, gestire la clipboard, scompattare i file strani, registrare lo schermo e, ogni tanto, eseguire una scansione antivirus del Mac (MalwareBytes).¹

Con questa organizzazione ci metto un attimo a scorrere la cartella Applicazioni in cerca del programma che mi serve, perché so a priori dove dovrebbe essere anche se non ne ricordo il nome esatto.²

Purtroppo però, da non so più quante versioni di macOS, ogni volta che aggiorno macOS le icone delle applicazioni vengono sempre riordinate in modo alfabetico. Dato che per la cartella Applicazioni l’ordinamento alfabetico è quello di default, la maggior parte degli utenti non se ne accorge nemmeno. Ma chi, come me, preferisce un ordinamento personalizzato, è obbligato ogni volta a rimettere tutto a posto.

Perché considero questo un baco e non una caratteristica voluta di macOS? Il motivo è banale: se per ogni cartella il Finder mi consente di ordinare i file in modi diversi – alfabetico, per data, per dimensione, per tipo – e mi consente anche di allinearli su una griglia o non ordinarli affatto, non si capisce perché mai la cartella Applicazioni dovrebbe comportarsi in modo diverso.

Ci sono dei motivi tecnici alla base di questa decisione? Nell’uso normale la cartella Applicazioni può essere personalizzata esattamente come tutte le altre cartelle del Finder, quindi perché mai il Finder dovrebbe essere obbligato a resettare le personalizzazioni ad ogni aggiornamento, anche minore, del sistema operativo?

Secondo la mia modestissima opinione questo errore, insieme a quello descritto al punto precedente, è legato ad un problema con i fetentissimi file .DS_Store, che gestiscono la configurazione di ciascuna cartella nel Finder e il cui formato è tenuto più segreto di ciò che avviene dietro i cancelli dell’Area 51.

Se qualcuno del team di sviluppo di Apple sta leggendo queste righe, può trovare un’oretta per sistemare questi bachi? Non dovrebbe essere troppo difficile, dateci una occhiata per favore, un vostro fedele utente ve ne sarà grato.

La possibilità di organizzare le applicazioni e i documenti in modo visuale è una delle funzioni di macOS che me lo fa preferire a Linux o a, orrore!, a Windows, dove questo modo di lavorare semplicemente non esiste. ↩︎
Sul Mac di casa su cui sto scrivendo ho 148 applicazioni installate, e per le mie abitudini non sono nemmeno tante. Ricordare il nome di tutte non fa per me, infatti non ho mai usato l’ordinamento alfabetico né tanto meno applicazioni come Alfred e simili. ↩︎

Apple abbiamo un problema: uno sguardo ai bachi di macOS Sonoma

Mon, 12 Feb 2024 06:00:00 +0000

– Immagine generata dall’IA di Microsoft Designer.

Uso il Mac per lavorare e quindi sono sempre restio ad aggiornare macOS troppo velocemente. In genere preferisco aspettare che la versione corrente maturi e qualche volta la salto completamente, magari perché ho letto un report particolarmente negativi o perché non mi ha convinto dopo averla usata su qualche computer di amici o colleghi (l’ho fatto ad esempio con Sierra, con Catalina e con Ventura).¹

Finora quindi tutti i Mac sotto il mio controllo, quelli che uso personalmente e quelli della famiglia, erano fermi a Monterey, che mi piace, è stabile, è veloce, ed è compatibile con tutte le applicazioni che uso ogni giorno (e sono parecchie).

Con il mio nuovo Mac Studio ho dovuto fare una eccezione, perché arriva con Sonoma preinstallato e comunque non credo sia compatibile con Monterey. Forse lo è con Ventura, ma Ventura è una delle versioni sulla mia lista nera, quindi che senso avrebbe usarlo?

Premessa

Sonoma mi ha indispettito sin dal giorno in cui ho letto che non avrebbe più permesso di convertire nativamente un file PostScript o EPS (Encapsulated PostScript) in un PDF. Lo so, oggi pochi usano PostScript e per convertire i miei vecchi file EPS posso sempre usare Ghostscript o un emulatore al posto di Anteprima, ma è un fatto quasi filosofico: macOS è un sistema operativo molto complesso e costituito da migliaia e migliaia di componenti che si incastrano uno nell’altro, davvero non c’era più spazio per mantenere il supporto per i file PostScript/EPS? ²

Appena ho iniziato ad usare Sonoma sul Mac Studio mi sono accorto che la mia contrarietà aprioristica aveva un fondamento reale, perché Sonoma è afflitto da un bel po’ di bachi incomprensibili che non rendono giustizia a quello che può fare davvero il Mac Studio.

I bachi di Sonoma

La maggior parte dei bachi di Sonoma di cui mi sono accorto si verificano nel Finder e negli Spazi, il primo usatissimo da tutti gli utenti di macOS, l’altro meno diffuso fra i normali utenti ma presumibilmente popolare fra gli sviluppatori del sistema operativo. Alcuni bachi, poi, sono così evidenti che mi sembra davvero strano che non siano stati corretti nel corso del beta-testing, né nei vari aggiornamenti che si sono succeduti in questi mesi. In ogni caso, sono tutti bachi presenti in Sonoma 14.3, la versione attualmente installata sul Mac Studio.

L’elenco che segue è più o meno in ordine di importanza (personale), partendo dai bachi, diciamo così, più veniali, piccole seccature che non incidono sull’esperienza d’uso di macOS Sonoma, e arrivando fino a quelli davvero mortali e ingiustificabili.

Subito dopo l’installazione di Sonoma, sfogliando la rete da un altro Mac, l’icona del Mac Studio appare come un punto interrogativo, mentre quella degli altri Mac pre-Sonoma è normale. Dopo alcune ore anche l’icona del Mac Studio torna alla normalità.
Ogni tanto, il messaggio di conferma dello svuotamento del Cestino appare in uno Spazio diverso da quello in cui si è eseguito il comando. Succede anche in Monterey, è vero, ma in quest’ultimo il Finder si sposta automaticamente nello Spazio del messaggio, permettendo di cliccare sul tasto di conferma. In Sonoma questo non succede e, non riuscendo a vedere il messaggio, si continua a provare a svuotare il cestino inutilmente.
Se usiamo la funzione Stampa per generare un file PDF di un documento o di una pagina web, il file PDF non assume automaticamente il nome del documento di origine ma risulta essere Senza titolo. Mai successo prima ed è una cosa davvero seccante. Possibile che gli sviluppatori di macOS non generino mai un file PDF?

Ho l’impressione che il baco sia legato alla rimozione del supporto PostScript, ma non metterò la mano sul fuoco per questo.
Siamo in una finestra del Finder e abbiamo impostato la modalità Allinea alla griglia. Se trasciniamo un gruppo di file sotto il limite inferiore della finestra premendo contemporaneamente il tasto CMD (⌘) e poi rilasciamo il mouse, le icone più in basso non vengono più visualizzate, dando l’impressione che i file siano scomparsi.³

Per tornare a vederli, bisogna cambiare modalità di visualizzazione, scegliendo ad esempio di mostrare la lista dei file (CMD (⌘)-2) e tornando poi alla vista per icone (CMD (⌘)-1), oppure ci si deve spostare nella cartella superiore per poi tornare indietro, oppure si deve semplicemente chiudere la finestra corrente ed aprirne una nuova, selezionando di nuovo la cartella su cui stiamo lavorando.

Le figure qui sotto mostrano quello chi succede. La prima immagine mostra una cartella del Finder contenente una raccolta di documenti e altre cartelle.

Qui ho selezionato alcuni file e li ho spostati in basso premendo contemporaneamente il tasto CMD (⌘) (se non lo usassi, una volta oltrepassato il bordo inferiore i file più in basso si sposterebbero nella parte superiore della finestra). Questa operazione dovrebbe ingrandire la finestra virtuale del Finder, facendo comparire la barra di scorrimento, ma su Sonoma questo non succede e sembra che i file siano scomparsi.⁴

Passando alla vista come lista di file e ritornando poi alla vista per icone compare finalmente la barra di scorrimento, rendendo evidente che ci sono altri file sotto il bordo inferiore.
Strettamente legato al baco precedente è questo: se apro una cartella del Finder dove è attiva la modalità Allinea alla griglia e vi aggiungo un nuovo file, questo a volte non è visibile finché non eseguo una delle operazioni descritte prima. La stessa cosa succede creando o copiando una nuova cartella. Per non farsi mancare niente, questo baco si verifica in modo casuale, a volte va tutto bene altre no, generando ancora più confusione nel povero utente alle prese con il Finder di Sonoma.
Supponiamo di avere due finestre sovrapposte in uno Spazio, diciamo lo Spazio numero 1. Se clicchiamo con il mouse sulla barra della finestra che sta sopra e, tenendo sempre premuto il pulsante del mouse, usiamo le combinazioni di tasti CTRL(⌃)-2 e CTRL-1 per spostarci nello Spazio numero 2 per poi tornare in quello di partenza, al ritorno nello Spazio iniziale la finestra viaggiatrice finisce sempre sotto quella rimasta ferma.

Se ci sono tre o più finestre parzialmente sovrapposte, quella che va avanti e indietro fra gli Spazi finisce sempre sotto la finestra che ha ricevuto il focus prima della finestra viaggiatrice, ma sopra tutte le altre finestre del Finder.

Questo giochetto avviene solo con le finestre del Finder: se si sovrappone una finestra del Finder a una, diciamo, di Safari, la finestra del Finder che viene spostata fra uno Spazio e l’altro ricompare nello Spazio originale sempre sopra quella di Safari, proprio come dovrebbe essere.
Chi ha visto i video qui sopra si sarà accorto di un’altro problema molto, ma molto serio: ogni volta che si trascina una qualunque finestra da uno Spazio all’altro si verifica uno sfarfallio evidente dello sfondo della finestra, che potrebbe essere legato al codice che la ridisegna.

Succede sul potentissimo Mac Studio, e succede sui Mac meno performanti (grazie Mimmo!), ma non è mai, mai, mai successo in tutte le versioni precedenti di macOS.⁵

La cosa strana è che questa è una operazione comunissima per chi usa regolarmente gli Spazi, e mi pare incomprensibile che gli sviluppatori non se ne siano accorti oppure che, se l’hanno fatto, non abbiano posto rimedio prima del rilascio del sistema operativo. Ragazzi, ma è possibile che con i computer ultrapotenti che abbiamo oggi dobbiamo attendere mezzo secondo per ridisegnare una finestra?

Conclusioni

Questi sono i bachi di Sonoma di cui finora mi sono accorto personalmente. La lista non è di certo esaustiva, ma riflette la mia particolare modalità d’uso di macOS, fra cui un utilizzo continuo degli Spazi (che trovo molto più comodi di una configurazione multi-monitor). delle operazioni di trascinamento nel Finder e delle combinazioni di tasti.

Come abbiamo appena visto, Sonoma ha introdotto parecchi bachi più o meno gravi, ma macOS è affetto anche da tanti bachi d’epoca, bachi che esistono da anni e che Apple si rifiuta di correggere o non considera tali. Ma di questi leggerete nel prossimo articolo.

Nei confronti delle versioni più recenti di macOS non sono ostile come Riccardo Mori, però ammetto che quello che scrive tocca più di un nervo scoperto. ↩︎
Qui potrei partire con una lunga sparata sul fatto che i nostri documenti su computer rischiano di non essere più leggibili nel giro di pochi anni a meno che non ne abbiamo fatta una copia su carta, ma ve la risparmio perché non è il vero argomento di questo post. ↩︎
A cosa serve una operazione del genere? Ad esempio a fare spazio a nuovi file che, per qualche motivo, si vogliono sistemare prima di quelli preesistenti mantenendo l’ordine delle icone già presenti, oppure per aver modo di riordinare a mano i file. ↩︎
Inutile dire che nelle Impostazioni di Sistema ho scelto di avere le barre di scorrimento sempre attive. ↩︎
Non so dire di Ventura, che non ho mai provato a fondo, ma di sicuro non è mai successo da Monterey in giù. ↩︎

Mac Studio!

Sun, 04 Feb 2024 06:00:00 +0000

Ed ecco il Mac Studio. Ho dovuto fare una lunga trafila burocratica per averlo, ma alla fine ce l’ho fatta ed ora è qui davanti a me.

La prima cosa che si nota è che la scatola è pesante, molto pesante. Le specifiche dicono che il Mac Studio è grande e pesa più o meno quanto tre Mac Mini messi uno sull’altro (19.7 x 19.7 x 9.5 cm^3 e 3.6 kg per il Mac Studio contro 19.7 x 19.7 x 3.6 cm^3 e 1.2 kg per il Mac Mini). Io non ho mai preso in mano tre Mac Mini insieme, ma in ogni caso la scatola dà una bella impressione di solidità, che per un oggetto costoso come questo è una cosa più che positiva.

Il Mac Studio in effetti non è economico, la configurazione che ho scelto è quasi al top – processore M2 Ultra con CPU a 24 core, GPU a 60 core e Neural Engine a 32 core, 128 GB di RAM e disco SSD da 1 TB, – ed è venuta a costare un pelo meno di 7.000 euro, cioè quanto due Vision Pro.

Ma la qualità costa, e del resto per una workstation HP, Dell o Lenovo con caratteristiche equivalenti bisogna tirare fuori dai 1.000 ai 4.000 euro in più.¹ Apple, in questo caso, è perfino conveniente.

Unboxing

Non sono un fanatico dell’unboxing, ma il Mac Studio merita questo rito di iniziazione. La scatola del Mac Studio è un parallelepipedo più sviluppato in altezza che in larghezza, fatto interamente di cartone pressato molto robusto.

Aprire la scatola è facilissimo, basta tirare la linguetta e aprire a libro un lato della scatola, una cosa che mi ricorda il sistema di apertura del Mac Pro G4.

Vedere il Mac Studio coricato su un lato fa un po’ impressione, e sembra che possa cadere in ogni momento. Ma le alette laterali sono molto più robuste di quello che appare e il Mac Studio è troppo grosso per sfuggire alla loro presa.

A questo punto bisogna coricare la scatola su un lato, allargare le alette nel senso delle frecce, togliere la pellicola protettiva di carta e prendere finalmente in mano il Mac Studio.²

Sembra davvero un Mac Mini cresciuto in altezza e ora sembra pesare il giusto in rapporto alle sue dimensioni. Tutto il peso aggiuntivo è dovuto alla scatola che, ora si vede benissimo, è studiata per proteggere al meglio il prezioso oggetto al suo interno.

Anche il cavo di alimentazione è un’opera di ingegneria, piuttosto spesso ma molto flessibile e con una guaina in tessuto che mi ricorda quella dei vecchi ferri da stiro. Questo però ha una trama molto più fitta ed è inequivocabilmente molto più elegante. Peccato per la spina, io avrei preferito una Schuko, ma pazienza.

Collegare il cavo di alimentazione e quello USB-C per il monitor è un attimo. Anche collegare la tastiera e il mouse wireless (Logitech, entrambi ottimi) è facilissimo, mi basta togliere il dongle USB dal mio solito Mac e infilarlo in una porta del Mac Studio, senza bisogno di configurare niente o di trafficare con il Bluetooth.

Più complicato trovare il tasto di accensione. È sull’angolo in basso a sinistra, perfettamente a filo con il corpo della macchina, al tocco non si sente praticamente niente. Ma una volta premuto, badaboom! pochi secondi e sono sullo schermo di benvenuto di macOS. Una veloce configurazione del sistema (tanto lo devo reinstallare) e compare il desktop di Sonoma.

Reinstallazione di macOS

Chiamatemi fissato ma io reinstallo sempre macOS da zero su ogni nuovo Mac che mi capita per le mani. Non so, sarà un retaggio del passato, sarà appunto una fissazione, sarà puro desiderio di controllo, ma sta di fatto che non ho mai usato un Mac dove non ho installato personalmente macOS.

Per farlo sui Mac basati su processore Apple Silicon bisogna tenere premuto il tasto di accensione finché non compare l’icona Options a forma di ruote dentate concentriche, in genere affiancata a una o più icone che rappresentano i dischi del Mac. Cliccando su Options e confermando la scelta si carica il programma di Recovery di macOS.

Una volta caricato il Recovery, inizializzo prima il disco di sistema con Utility Disco, dandogli un nome più significativo del solito Macintosh HD (in genere lo stesso nome che uso in rete in modo da averlo sempre davanti agli occhi), e poi reinstallo macOS tramite la ormai semplicissima procedura guidata.

Come sempre, il tempo di installazione visualizzato è del tutto inattendibile: le tre ore e passa necessarie mostrate all’inizio dell’installazione diventano in realtà una quarantina di minuti, che non è poco ma non è nemmeno un tempo esorbitante per installare un sistema operativo complesso come macOS.

Curioso anche che, dopo il riavvio d’ordinanza, la risoluzione dello schermo diventi così scarsa, per tornare normale una volta comparsa la schermata di benvenuto di macOS. Mai vista una cosa del genere in altre versioni di macOS, però è anche vero che ormai la maggior parte delle (re)installazioni le faccio sui MacBook che, a differenza dei sistemi desktop, hanno un hardware ben definito.

La configurazione iniziale di macOS, questa volta fatta in modo accurato, non ha storia e dopo pochi minuti sono di nuovo sul desktop di Sonoma. E qui inizio davvero a toccare con mano come si comporta il Mac Studio.

Come va il Mac Studio?

Il Mac Studio va che è una bellezza (ma poteva essere diversamente?), tutto è fluido e senza la minima incertezza. Succede anche con gli altri Mac con processore Apple Silicon ma qui, rispetto agli Air e ai Mini con cui ho avuto a che fare finora, si nota immediatamente che siamo su un gradino superiore (magari anche due).

L’installazione delle applicazioni è immediata: doppio click sul .dmg, trascinamento dell’icona nella cartella Applicazioni e… già finito, senza nemmeno avere il tempo di vedere la finestra di dialogo che ci informa che sta copiando il file. Con le applicazioni davvero grosse, tipo GNU Emacs, GIMP o Miniconda, si possono aspettare due-tre secondi, ma niente di più.

Finora solo QGIS gli ha dato un po’ di filo da torcere, perché sul Mac Studio l’installazione di questa applicazione dura ben due minuti e mezzo. Ma si tratta di un mostro di 3 GB, che contiene al suo interno migliaia e migliaia e migliaia di piccoli file, da copiare uno ad uno. Non a caso il processo di installazione è molto più veloce all’inizio, quando vengono copiati i file più grossi, e rallenta visibilmente solo quando arriva a copiare i tantissimi piccoli file di supporto.

Non ho volutamente provato ad usare Geekbench o simili per misurare le prestazioni del Mac Studio. La rete pullula già di questi dati e la mia sarebbe stata solo una ripetizione inutile. In realtà mi interessa di più vedere come si comporta il Mac Studio con le applicazioni davvero impegnative, ho già qualche indicazione ma voglio aspettare ancora un po’ a parlarne.

Sonoma però è una palla al piede, si vede subito che è ancora un sistema operativo pieno di bachi e di incongruenze (che farò vedere nel prossimo articolo) e non rende giustizia a quello che può fare davvero il Mac Studio.

Apple ci ha abituato ad un approccio tick-tock per i suoi sistemi operativi (come quello che per anni ha seguito Intel per i suoi processori): un anno fa uscire un sistema operativo innovativo ma lento e bacato, e l’anno dopo (a volte due) pubblica una versione che comprende quasi solo correzioni di bug e ottimizzazioni. È successo con Leopard e Snow Leopard, e poi con Lion e Mountain Lion. Più tardi ha ripetuto il giochetto con El Capitan, praticamente perfetto, che veniva dopo gli orrendi Mavericks e Yosemite, e anche con Mojave, che seguiva due versioni opache come Sierra e High Sierra, nonché più recentemente con Monterey, davvero ottimo dopo il disastro di Catalina. Sonoma, in teoria, sarebbe la versione bug-fix di Ventura, e invece è una delusione. Speriamo che al prossimo WWDC di giugno Apple ci metta una pezza, e pure bella grande.

Conclusioni

Tutto l’unboxing e la configurazione del Mac Studio l’ho fatta a casa mia, per poter lavorare in pace evitando il solito caos dell’istituto. Ma dopo una settimana il Mac Studio ha traslocato, prendendo posto al centro della scrivania del mio ufficio, in mezzo a monitor, tastiere, mouse, cavi e ammennicoli vari.

E il mio vecchio computer con High Sierra? Quello è destinato ad un nuovo progetto e sono proprio curioso di vedere cosa ne verrà fuori. Stay tuned!

C’è da dire che le suddette workstation sono, almeno in teoria, più espandibili del Mac Studio, ma nel mio caso specifico l’espandibilità non è un fattore importante. ↩︎
Nella scatola non c’è nemmeno un pezzetto piccolo piccolo di plastica. Non sarà molto dal punto di vista ambientale, ma dimostra che si può fare. ↩︎

Ridare una nuova vita al vecchio Mac con OpenCore Legacy Patcher (terza parte)

Mon, 22 Jan 2024 18:00:00 +0000

Dopo due lunghissimi articoli su OpenCore Legacy Patcher (prima parte e seconda parte), ha senso destinarne un terzo ad una linkografia¹ ragionata di pagine web e di video dedicati a questo software?

Secondo me sì (altrimenti non stareste leggendo l’articolo proprio in questo momento), perché OpenCore Legacy Patcher (come sempre, da ora in poi userò l’acronimo OCLP) è un software complesso e non è possibile coprire tutti i casi di uso in due articoli, pur se molto corposi.

Il riferimento principale è, naturalmente, il sito web di OCLP, che spiega in modo chiaro e dettagliato come installare ed usare il programma e come risolvere i problemi principali.
Altrettanto utile è il progetto di OCLP su GitHub, da cui si possono scaricare tutte le release del programma e il codice sorgente in Python, utile per chi voglia studiare come funziona OCLP o controllare che OCLP non contenga delle backdoor o dei trucchetti vari per prendere possesso del Mac o per infettarlo con qualche tipo di malware (non ce ne sono).
Altro riferimento imprescindibile è il sito di Mr. Macintosh, con il relativo canale YouTube. Dal sito si possono scaricare i programmi di installazione di un gran numero di versioni di macOS, da Sonoma giù giù fino a Lion,² una cosa molto utile per chi non riesca (o non voglia) usare OCLP per scaricare macOS.

Ricordo che OCLP supporta solo le versioni più recenti di macOS, da Big Sur a Sonoma sui Mac prodotti più o meno dal 2008 in poi. Chi volesse installare sul suo Mac d'epoca una versione più datata di macOS, da Catalina fino a Sierra, deve rivolgersi al progetto di DOSDude1, che non ho mai provato ma che sembra fatto bene, anche se non è sofisticato come OCLP.

Ancora più interessante è il canale YouTube di Mr. Macintosh, dove si possono trovare guide dettagliatissime all’installazione e all’uso di OCLP. Fra l’altro, Mr. Macintosh parla lentamente (fin troppo!) e in modo molto comprensibile, per cui anche chi conosce solo l’inglese di base dovrebbe essere in grado di seguire senza troppe difficoltà.

Le guide video di Mr. Macintosh hanno anche una versione scritta sul suo blog, che può essere più comoda da seguire soprattutto per gli utenti esperti, perché a volte Mr. Macintosh parla così lentamente da risultare noioso.

Io ho conosciuto OCLP proprio guardando per caso uno dei suoi video (credo questo oppure questo) e ho subito provato ad usarlo installando Big Sur, che funzionava alla grande.
Un altro ottimo canale YouTube dedicato a OCLP (ma non solo) è quello di Jessie’s Flying. In particolare, questo video è imperdibile, non a caso l’ho già citato nella prima parte di questa serie. Anche questo più recente non è male, anche perché dà una idea generale dei modelli di Mac su cui vale davvero la pena installare OCLP.

Tutto sommato preferisco Mr. Macintosh, che va più in profondità dal punto di vista tecnico, però se si vuole avere una idea veloce e senza troppi fronzoli di cosa fa e come funziona OCLP Jessie’s Flying può essere una scelta migliore.
Sembra strano, ma anche Macworld ha pubblicato nel corso degli anni parecchie guide a OCLP, questa dovrebbe essere la più recente e, naturalmente, è dedicata principalmente a Sonoma, ma non manca di menzionare versioni precedenti da Big Sur fino a High Sierra.
Per capire meglio come funziona OCLP dentro c’è questo articolo piuttosto interessante, OpenCore Legacy Patcher Explained, con relativo video su YouTube.

Lo stesso autore ha scritto anche una guida all’installazione di OPLP che però mi sembra poco utile per chi è nuovo ad OCLP, dato che nell’ultimo anno l’interfaccia grafica del programma è stata rivista in modo profondo.
Last but not least, da guardare questo video che confronta le prestazioni di tre Mac piuttosto datati (due MacBook Pro del 2011 e uno del 2012). Vale la pena guardarlo per rendersi conto dei problemi che possono presentarsi sui Mac più vecchi e delle relative soluzioni (quando è possibile).

Il messaggio di fondo comunque è semplice: nemmeno OCLP fa miracoli, per cui sui Mac più vecchi è consigliabile usare Big Sur o, al massimo, Monterey. Su un Mac Book Pro 2011 come il mio, Big Sur va alla grande, ma anche Monterey secondo me è più che usabile e non ho mai avuto i problemi riportati nel video, forse perché ho 16 GB di RAM o perché l’ho sempre usato solo con il display LCD integrato (e comunque non credo di aver mai aperto Foto su quella macchina).

Una nota di colore: guardando il video si nota chiaramente che non è prodotto da professionista di YouTube come Mr. Macintosh o Jessie’s Flying, e questo secondo me lo rende molto più fresco e molto più simile a ciò che può fare, con la tastiera, un umile scribacchino del web come il sottoscritto.

L’accademia della Crusca, stranamente, accetta questo termine, insieme all’italianissimo sitografia, che non mi piace per niente. ↩︎
Ache se Apple pone molte limitazioni, in sostanza bisogna avere un Mac compatibile per farlo. ↩︎

Macos on Melabit

macOS Tahoe: liberiamo le icone!

La gabbia dello squircle

Liberiamo le icone

IconLib

Conclusioni

Ancora macOS Tahoe

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

macOS Tahoe: Developer Beta 3

È una beta

Lo sfondo

La barra del menu

Le Impostazioni di Sistema

Il Finder

Le icone delle applicazioni

Prestazioni

Conclusioni

macOS Tahoe: dov'è il Terminale?

macOS Tahoe: rimandato a settembre

Aggiornamento

Il Desktop e i widget

Il Finder

La nuova Apps

Le Impostazioni di Sistema

Conclusioni (per ora)

WWDC 25

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

Apple abbiamo risolto dei problemi: da Sonoma a Sequoia

Mac bloccato? Come ripristinarlo con la modalità DFU

Apple abbiamo un altro problema: un nuovo baco di macOS Sonoma

Al limite della memoria

Nove nove

Windows? No grazie!

Apple abbiamo un problema: uno sguardo ai bachi di macOS Sonoma (aggiornamento)

Da Intel ad Apple Silicon

Quando iCloud non va...

Sonoma: c'è del buono

Apple abbiamo altri problemi: uno sguardo ai bachi d'epoca di macOS

Apple abbiamo un problema: uno sguardo ai bachi di macOS Sonoma

Premessa

I bachi di Sonoma

Conclusioni

Mac Studio!

Unboxing

Reinstallazione di macOS

Come va il Mac Studio?