Asahi Linux, la distribuzione Linux pensata per Apple Silicon ha perso una delle sue menti più brillanti ma soprattutto ha perso il capo del progetto, il fondatore. Hector Martin ha deciso di abbandonare tutto per una serie di motivazioni che racconta in una lunga lettera che vale la pena di leggere e che abbiamo tradotto.

Alla fine degli anni 2000, sono stato un contributor di primo piano nella scena homebrew della Wii. All’epoca, lavoravo a software (oggi la gente li chiama “jailbreak”) che consentiva agli utenti di eseguire app non ufficiali sulla Nintendo Wii. Ero molto appassionato del mio lavoro e del team di cui facevo parte (Team Twiizers, in seguito fail0verflow). Nonostante questo, alla fine mi sono preso un esaurimento nervoso soprattutto a causa dell’alta percentuale di utenti che si sentivano in diritto di pretendere tutto. La maggior parte delle persone che usavano il nostro software voleva solo giocare a titoli piratati (cosa che noi non supportavamo, non approvavamo né abilitavamo direttamente). Continuavamo a giocare al gatto e al topo con il produttore per mantenere la piattaforma aperta, solo per vedere i nostri sforzi sfruttati principalmente da utenti interessati a rubare il lavoro altrui, pretendendolo anche a gran voce. Dopo un po’, questa situazione è diventata logorante. Con l’uscita di console più recenti, ho deciso di concentrarmi su port di Linux per puro divertimento, senza cercare di costruire una comunità o di lavorare su jailbreak o exploit, che sarebbero poi diventati strumenti usati dai pirati.

Quando Apple ha rilasciato l’M1 ho capito che farci girare Linux sarebbe stato il mio progetto dei sogni. Le sfide tecniche erano simili a quelle dei miei progetti homebrew sulle console (in realtà, ancora più grandi), ma questa volta la piattaforma era già aperta: non c’era bisogno di un jailbreak, né di utenti pretenziosi interessati a piratare software. Inoltre, far girare Linux su un M1 era molto più significativo che farlo su una PS4.

Ho avviato il progetto Asahi Linux e ho ricevuto un’enorme quantità di sostegno e donazioni. Incredibilmente, dopo pochi giorni dal mio appello avevo già il supporto necessario per dare vita al progetto, così mi sono messo all’opera. I primi due anni sono stati straordinari: siamo passati dal nulla a offrire una delle esperienze Linux più fluide in circolazione su un portatile. Certo, c’erano (e ci sono) ancora alcune componenti hardware non supportate, ma l’esperienza complessiva era paragonabile o persino superiore a quella su molti laptop x86. E abbiamo costruito tutto da zero, senza alcun supporto o documentazione ufficiale. Era un’impresa impossibile, qualcosa che non si era mai visto prima, e ce l’abbiamo fatta.

Sfortunatamente, col tempo le cose sono diventate meno divertenti. Prima di tutto, ci sono stati problemi con l’upstream del codice nel kernel Linux, di cui ho già parlato a lungo altrove e che non ripeterò qui. Basti dire che ritrovarsi nella posizione di dover integrare il proprio codice in quasi ogni sottosistema di Linux, toccando driver di ogni tipo e parte del codice comune, è un’esperienza incredibilmente frustrante.

Qui è necessario un intervento perché non tutti conoscono le logiche di Linux: “upstream” significa far integrare le proprie modifiche nel repository ufficiale del kernel Linux, in modo che diventino parte della versione principale. Il kernel Linux è suddiviso in tanti sottosistemi (grafica, rete, filesystem, gestione energetica, ecc.), ognuno con i propri manutentori e regole di revisione. Doversi rapportare con tutti può essere lungo e complicato, e Martin con Asahi non è riuscito a fare in modo che molte delle modifiche da lui fatte finissero direttamente nel kernel ufficiale.

Poi sono arrivati gli utenti “pretenziosi”. Questa volta non si trattava di rubare giochi, ma di funzionalità: «Quando arriva il supporto Thunderbolt?», «Asahi è inutile per me finché non posso usare i monitor su USB-C», «La durata della batteria fa schifo rispetto a macOS» (nessuno si è mai lamentato facendo il confronto con i laptop x86…), «Non posso nemmeno controllare la temperatura della CPU» (sì, mi è stata davvero fatta questa lamentela). Per molto tempo, anche dopo aver rilasciato una versione stabile, la gente continuava a sostenere che Asahi Linux e in particolare Fedora Asahi Remix fossero “alpha”, “instabili” e “non adatti all’uso quotidiano” (nonostante migliaia di utenti, me compreso, li usassero ogni giorno e persino come server).

Non importava quanto facessimo, né quanti traguardi apparentemente impossibili raggiungessimo: la gente voleva sempre di più. Nel frattempo, le donazioni e i contributi economici sono calati lentamente, fin dall’avvio del progetto. Non abbastanza da distruggere subito il mio sogno di lavorare a tempo pieno su Asahi, ma sufficienti a farmi dubitare che tutto ciò fosse davvero apprezzato. Il picco di donazioni mensili c’è stato soltanto nel primo o secondo mese. Sembrava che più risultati ottenessimo, meno sostegno ricevevamo.

Sapevo che il rischio di burnout fosse reale e ho cercato di gestirlo limitando il tempo dedicato ad alcune aree, come l’invio del codice al kernel upstream. Questa strategia ha funzionato abbastanza bene ed era quasi sostenibile in quel periodo.

Poi è arrivato il 2024. L’anno passato è stato incredibilmente turbolento per me, per motivi personali su cui non entrerò nel dettaglio. Basti dire che ho viaggiato per gran parte dell’anno, dovendo anche gestire diverse persone moleste e stalker che hanno perseguitato e attaccato me e la mia famiglia (e continuano a farlo).

Nel 2024 sono comunque riuscito a compiere qualche progresso, ma mi sono ritrovato in una posizione molto vulnerabile. Non ero riuscito a portare avanti Asahi tanto quanto avrei voluto, e gli utenti non smettevano di chiedere nuove funzionalità e supporto per più modelli.

Abbiamo rilasciato driver Vulkan conformi e un intero stack di emulazione per giochi e app x86-64, ma eravamo ancora bloccati senza DP Alt Mode (una funzionalità che richiede un lavoro di reverse engineering, debug e modifiche profonde al kernel; e che, se implementata in modo corretto e robusto, necessiterebbe di un grande refactoring di alcuni sottosistemi del kernel, o persino l’introduzione di un sottosistema completamente nuovo).

DP Alt Mode è quello che viene chiamato DisplayPort Alternate Mode, e serve a veicolare il segnale video DisplayPort attraverso la porta USB-C. Implementarlo richiede la comprensione e la modifica delle parti più profonde del kernel.

All’inizio di quest’anno ho lentamente ripreso il lavoro, sentendomi molto stressato e in colpa per aver fatto così poco nell’anno precedente. Il supporto completo a DP Alt Mode era ancora lontano, ma speravamo di rilasciare una versione limitata, funzionante solo su una specifica porta Type-C per ogni modello di Mac, entro il primo o il secondo mese dell’anno. Sven aveva fatto qualche progresso nel codice PHY a dicembre, così l’ho ripreso e, alla fine, sono riuscito a mettere insieme tre driver quel tanto che bastava per farli funzionare in modo abbastanza affidabile. Anche se non era la soluzione migliore, era il massimo che potessi fare senza dover affrontare un’altra lunga discussione con la comunità del kernel.

Il PHY code è quello che riguarda lo strato fisico (Physical Layer) delle comunicazioni, fondamentale per il funzionamento della USB-C/Thunderbolt.

I problemi che Rust for Linux ha incontrato per sopravvivere come progetto nel kernel upstream sono ben documentati, quindi non li ripeterò in dettaglio. Basti dire che considero la gestione di Linus riguardo l’integrazione di Rust in Linux un grande fallimento di leadership. Un progetto di queste dimensioni avrebbe bisogno di un sostegno significativo da parte degli attori principali, mentre il suo approccio sembra sia stato “aspettiamo e vediamo”. Nel frattempo, vari manutentori di sottosistemi a valle di Linus hanno fatto di tutto per ostacolare il progetto, arrivando a insulti verbali inaccettabili e danneggiando il morale, senza conseguenze. Un importante manutentore di Rust for Linux si è già dimesso qualche mese fa.

Qui è necessario raccontare quello che è successo: nei mesi scorsi la community dei mantainer del kernel di Linux ha passato settimane di fuoco perché c’è stato un acceso scontro tra coloro che vogliono portare Rust come linguaggio all’interno del Kernel contro i mantainer storici che vogliono tenere invece il C. Il progetto Rust for Linux, nato negli scorsi anni, è nato proprio per introdurre il linguaggio di programmazione Rust nel kernel Linux, inizialmente in parallelo al C, perché Rust è molto più efficace nel prevenire errori di memoria e buffer overflow.

Linus Torvalds, invece di prendere una posizione netta, si è limitato a dire che per ora si poteva attendere e questo mentre alcuni maintainer di sottosistemi hanno iniziato a ostacolare l’integrazione di Rust.

Come sapete, per me questa questione è molto personale, perché con Asahi abbiamo puntato su Rust for Linux. Non solo per divertimento (o per la sicurezza nella gestione della memoria), ma perché Rust è la ragione principale per cui il nostro driver GPU è stato sviluppato così velocemente. Ora abbiamo altri due driver in Rust nel nostro downstream tree e un terzo in fase di riscrittura dal C a Rust, perché Rust è semplicemente molto più adatto alle sfide uniche che affrontiamo, e il driver in C sta diventando ingestibile. È lo stesso motivo per cui anche il nuovo driver Nova per le GPU Nvidia è scritto in Rust. Non sorprende che i linguaggi di programmazione moderni siano più adatti a scrivere driver per hardware moderno, più complesso e con sfide inedite. Qualcuno potrebbe chiedersi perché non lasciamo che la questione di Rust si risolva da sola nel tempo, magari in diversi anni, e non ci limitiamo a mantenere tutto nel nostro downstream fino ad allora. Una ragione è che questa situazione sta danneggiando il morale degli sviluppatori già adesso. Un’altra ragione è che il nostro driver GPU per Apple è di per sé una prova importante dell’idoneità di Rust for Linux (è stato il primo grande driver scritto da zero in Rust e ha portato con sé molto sviluppo nelle astrazioni Rust per il kernel). Se non puntassimo all’upstream, ciò verrebbe interpretato come una mancanza di interesse, danneggiando le possibilità di sopravvivenza di Rust for Linux. Ma c’è dell’altro.

In realtà, il modello di sviluppo del kernel Linux è (forse paradossalmente) progettato per favorire l’upstream e penalizzare i fork downstream. Sebbene sia possibile ignorare l’upstream e mantenere un hard fork, non è una soluzione sostenibile a lungo termine (è così che finiscono i kernel Android dei produttori, che dopo due anni muoiono). L’albero downstream di Asahi Linux viene continuamente rebasato sull’ultimo kernel upstream, e ciò significa che ogni patch aggiuntiva che portiamo a valle incrementa il nostro carico di manutenzione, talvolta in modo notevole. Ma c’è dell’altro: la policy di Kernel/Mesa stabilisce che il supporto upstream di Mesa per un driver GPU non possa essere unito e abilitato finché la parte corrispondente nel kernel non è pronta per l’integrazione. Questo ci costringe a distribuire anche un fork di Mesa agli utenti. Sebbene il nostro driver GPU sia al 99% upstream in Mesa, esso è intenzionalmente disabilitato e non possiamo inviare la modifica per abilitarlo finché la parte del kernel non viene accettata. In pratica, questo significa che gli utenti non possono avere l’accelerazione GPU insieme alle tecnologie di container (come Docker/Podman, o Waydroid), perché le immagini standard dei container includono le build upstream di Mesa, incompatibili con il nostro driver. Abbiamo un workaround parziale per Flatpak, ma tutti gli altri sistemi di container non hanno soluzioni. A causa di questi fattori, le difficoltà di upstreamare nel kernel Linux stanno danneggiando i nostri utenti downstream già ora.

Abbiamo lasciato questa parte della lettera anche se non è semplice da capire, ma non è comunque fondamentale per capire la questione.

Non sono il tipo che lascia correre le ingiustizie quando le vede, quindi, quando un altro manutentore di lunga data ha abusato della sua posizione per ostacolare R4L (Rust for Linux) e bloccare i progressi di upstream, sono intervenuto. E la risposta (ampiamente discussa) è stata la goccia che ha fatto traboccare il vaso. Mi sono dimesso dal mio ruolo di manutentore upstream per il supporto Apple ARM, perché non voglio più avere a che fare con quella community. Più avanti, in quello stesso thread, un altro manutentore importante ha dichiarato, senza alcuna ironia: «Noi siamo la ‘thin blue line’», e a nessuno è importato, confermandomi ulteriormente che non voglio averci più nulla a che fare. È la stessa persona che in precedenza aveva spinto un manutentore di Rust for Linux a dimettersi.

“We are the ‘thin blue line’” è un riferimento spesso associato alle forze di polizia che creano uno sbarramento, e una risposta simile ha fatto capire a Martin che i mantainer del kernel avrebbero tenuto un atteggiamento di chiusura e protezione reciproca.

Ma la cosa va ben oltre l’episodio pubblico. Nei giorni successivi ho scoperto che alcuni membri del kernel e di altri progetti Linux correlati hanno giocato un doppio gioco con me, fingendo di sostenere me e Asahi Linux mentre in segreto nutrivano risentimento e lo alimentavano a porte chiuse. Tutto questo è accaduto senza che nessuno mi inviasse un’email privata o mi avvertisse in altro modo di ciò che stava succedendo. Ho saputo che una di queste persone, che ricopre una posizione di rilievo in più progetti con cui Asahi Linux deve interagire per sopravvivere, si è schierata e continua a schierarsi con individui che mi hanno abusato e molestato in prima persona. A quanto pare, si sono diffuse anche falsità, come l’idea che io sia assunto da qualcuno per lavorare su Asahi (non lo sono: non abbiamo alcuna sponsorizzazione aziendale, a parte bunny.net che ci fornisce crediti CDN gratuiti per l’hosting).

Capisco che a qualcuno possano non essere piaciuti i miei post su Mastodon. Sì, a volte posso essere ruvido, e me ne assumo la responsabilità. Ma tutto questo non è accettabile. Non posso lavorare con persone che formano cricche dietro le quinte e mentono sulle loro intenzioni. Non posso lavorare con chi dà la colpa a chi denuncia, anziché a chi è veramente tossico nella comunità. Non posso lavorare con chi detesta i commenti pubblici e sostiene che le cose si risolvano meglio in privato, anche se in privato non sembra mai cambiare nulla. Non posso lavorare con chi condanna chi denuncia comportamenti scorretti sui social davanti a migliaia di follower, mentre loro stessi aggrediscono le persone sui social e sulle mailing list con migliaia di iscritti. Non posso lavorare con chi, ricoprendo ruoli di alto livello, usa un linguaggio politicamente carico e discriminatorio in pubblico senza conseguenze. Non posso lavorare con chi afferma che il problema sono io e che tutto vada a meraviglia, mentre sostenitori e manutentori importanti si dimettono e continuo a ricevere messaggi da persone che dichiarano di non voler nemmeno sfiorare il kernel Linux.

Quando Apple ha rilasciato l’M1, Linus Torvalds sperava che potesse far girare Linux ma non si aspettava che accadesse davvero. Noi ci siamo riusciti, e Linux 5.19 è stato rilasciato da un MacBook Air M2 con Asahi Linux in esecuzione. Speravo che il suo entusiasmo si traducesse in un sostegno concreto per la nostra comunità e in un aiuto sulle difficoltà di upstream. Purtroppo, non è accaduto. Nel novembre 2023 gli ho inviato un invito a discutere delle sfide della contribuzione e della manutenzione del kernel, per capire come avremmo potuto migliorare la situazione. Non ho mai ricevuto risposta.

Nel 2011, Con Kolivas abbandonò la comunità del kernel Linux. Anestesista di professione, era probabilmente l’ultimo grande hacker amatoriale del kernel. Da allora, se possibile, le cose sono persino peggiorate. Oggi è praticamente impossibile sopravvivere come manutentore o collaboratore di più sottosistemi del kernel Linux se non si è pagati da un’azienda. Linux è nato come progetto hobbistico, ma ha davvero perso le sue radici amatoriali.

Quando ho iniziato Asahi Linux, gli ho lasciato occupare gran parte della mia vita. Ho rinunciato a molti dei miei hobby (del resto, questo era il mio hobby dei sogni) e ho lavorato al progetto ben oltre un normale tempo pieno. All’epoca era divertente, ma ora non lo è più. Ho un M3 Pro ancora nella scatola e non l’ho neanche acceso. Sono terrorizzato dall’idea di iniziare il lavoro di porting. Non mi sembra che ne valga più la pena.

Mi manca avere del tempo libero in cui possa rilassarmi senza preoccuparmi delle funzionalità che non abbiamo ancora rilasciato. Mi manca fare musica. Mi mancano le jam session. Mi manca uscire a cena con amici e familiari senza pensare a quanto codice non abbiamo ancora inviato all’upstream. Mi manca sedermi a giocare o guardare un film senza sentirmi in colpa.

Mi dimetto con effetto immediato dal mio ruolo di lead del progetto Asahi Linux. Il progetto continuerà senza di me e sto collaborando con il resto del team per trasferire le responsabilità e le credenziali amministrative. Metterò in pausa il mio Patreon personale, e invito chi mi sosteneva a sostenere invece Asahi Linux su OpenCollective (GitHub Sponsors non mi consente di mettere in pausa i pagamenti in modo unilaterale, ma i miei sponsor saranno informati di questa modifica in modo che possano cancellare manualmente il sostegno).

Voglio ringraziare tutto il team di Asahi Linux, senza il quale da solo non sarei mai arrivato da nessuna parte. Sapete chi siete. Esprimo anche la mia più profonda gratitudine a tutti i miei sponsor su Patreon e GitHub, che hanno reso il progetto concretamente realizzabile fin dal principio.

Martin è sicuro che il progetto continuerà anche senza di lui. Non sarà facile.