Portare Linux sugli Apple Silicon è stata una maratona di reverse engineering, ma il traguardo del monitoraggio hardware integrato resta lontano. Il driver per lo SMC (System Management Controller) – il componente che dovrebbe fornire ai sistemi operativi le statistiche su batteria, temperature, ventole e consumi – naviga in un guazzabuglio di sensori che cambiano radicalmente da un chip M all’altro. I manutentori del kernel si sono scontrati con nodi Device Tree mancanti e una mappa di periferiche di monitoraggio che, a detta degli stessi sviluppatori, è «un pasticcio» senza uno schema prevedibile.

La conseguenza immediata è che, sul kernel Linux mainline, chi usa un MacBook o un Mac mini con processore M1, M2 o M3 non dispone di dati affidabili sullo stato termico ed energetico del sistema. Per l’utente medio è un fastidio; per chi guarda a questi dispositivi come nodi di inference locale per LLM è una falla seria. I carichi di inference prolungati, tipici di una postazione self-hosted che serve modelli quantizzati a regime continuo, mettono alla prova i limiti termici di qualsiasi silicio. Senza letture accurate delle temperature e dei watt assorbiti, si perde la capacità di capire se il processore sta rallentando per throttling, se la batteria si sta degradando più del previsto o se il sistema è vicino a un arresto d’emergenza.

Un labirinto di sensori, nessuna mappa comune
Il cuore del problema non è tanto la complessità del silicio Apple, quanto l’assenza di una standardizzazione trasversale ai modelli. Su un M1 lo SMC espone una certa batteria di sensori; su un M2 la disposizione cambia, e su un M3 cambia ancora, con indirizzi e bus diversi. Manca un’astrazione firmware unificata che il kernel possa interrogare senza patemi. Il progetto Asahi Linux, che ha fatto da apripista per l’intero ecosistema, ha dovuto ricostruire a mano il dialogo con lo SMC, ma l’upstreaming del codice è arenato su discussioni architetturali: come rappresentare in modo coerente una periferica che non segue alcuna specifica pubblica? Nel frattempo, le patch restano in sospeso e gli utenti sono costretti a kernel custom o a rinunciare del tutto alla telemetria.

Questo pantano non è solo un grattacapo per gli smanettoni. Rivela una tensione strutturale che tocca chiunque stia valutando hardware non x86 per carichi AI on-premise. La maturità dei driver di monitoraggio è un fattore sottovalutato nel calcolo del TCO di una macchina per inference: senza di essa, non si possono implementare politiche di raffreddamento intelligenti, non si pianifica la manutenzione e si rischia di sprecare energia o di accorciare la vita dei componenti. In un confronto con l’ecosistema NVIDIA, dove strumenti come nvidia-smi offrono una finestra granulare su ogni parametro, il vuoto che circonda lo SMC su Linux appare come un freno alla possibilità di usare i SoC Apple in contesti professionali al di fuori di macOS.

Va riconosciuto che la colpa non è dei manutentori del kernel. È Apple a non fornire documentazione e a mescolare le carte a ogni generazione di chip, rendendo il lavoro di chi scrive codice aperto una rincorsa perpetua. Tuttavia, per chi costruisce infrastrutture locali di inference, la lezione è chiara: il fascino dei Neural Engine e dell’efficienza dei processori M-series si scontra con l’assenza di strumenti di telemetria maturi, un costo nascosto che può vanificare i guadagni di performance per watt. Finché la comunità Linux non riuscirà a sciogliere questo nodo, il Mac con Asahi resterà un’ottima macchina da sviluppo, ma un azzardo per chi deve fare affidamento su carichi AI stabili e monitorati. Il vero banco di prova, per l’intero movimento open-source, sarà dimostrare che hardware proprietario e controllo trasparente possono coesistere – altrimenti l’alternativa resta un parco macchine x86 con driver collaudati, anche a costo di rinunciare a qualche milliwatt di efficienza.