Ultimamente mi è capitato che mi chiedessero: "Ma tu perché utilizzi macOS invece di un altro sistema operativo? Tu, sviluppatore, come mai scegli Mac invece che, ad esempio, un portatile con Linux che da certi punti di vista dovrebbe essere, come dire, la piattaforma di sviluppo per eccellenza? O, dice qualcun altro, come mai non utilizzi Windows invece che Mac?
". Questa seconda istanza la capisco di meno, perché Windows, ora vedremo, non ha secondo me nessuna delle caratteristiche desiderabili di un sistema di sviluppo, però la domanda comunque rimane appropriata, interessante. O meglio, questa è la classica questione sulla quale si può fondare uno dei video più noiosi di sempre.
Sarebbe stupidissimo e noioso se io ne facessi una questione di preferenza. Invece, se noi partiamo dalla storia che, grazie alla mia veneranda età, mi ha visto, diciamo, tra gli utenti dei primi sistemi operativi e attraverso la mia storia personale risaliamo ai gradini del tempo per vedere quali sono state le evoluzioni, quali ogni volta le scelte possibili, io credo che riusciremo a dipingere nel corso di questo video un quadro diverso, più informativo e che colloca la mia scelta in prospettiva. I primi sistemi operativi che ho visto in vita mia sono stati quelli degli home computer, ovvero quelle poche routine che ci sono nel Commodore 64, nello Spectrum e in altre macchine simili, che servivano giusto per caricare il software dalla cassetta o dal drive.
Perché la verità è che, a parte questo, c'era ben poco di sistema operativo in quelle macchine. La maggior parte della ROM era utilizzata per il BASIC, quindi per l'implementazione del BASIC di quelle macchine. Si potrebbe dire, da certi punti di vista, che il BASIC era il sistema operativo di quelle macchine e non è una forzatura così estrema come può sembrare a primo acchito.
D'altra parte, anche i compiti di quel layer minuscolo di sistema operativo che esisteva in quelle macchine erano chiamati tramite il BASIC. Cioè, io digitavo 'LOAD' per caricare il programma, eccetera, eccetera. In BASIC, routine di I/O si occupavano di visualizzare a schermo i messaggi e cose del genere, o il concetto di stream, molto avanzato, dello ZX Spectrum.
Ma poi gli utilizzi principali di tutto ciò quali erano? Quelli del BASIC. Ora, a fronte di questo minimalismo così estremo di questi sistemi operativi, c'era però la grande reattività di queste macchine: lente, ma che apparivano più veloci dei computer odierni, perché proprio per la mancanza di layer di astrazione era possibile comandare direttamente l'hardware.
Non c'erano latenze, non c'erano swap, non c'erano dischi da cui continuamente si caricavano e si scaricavano cose. Erano lentissime, ovviamente, le operazioni di caricamento dei software, ma erano comunque predicibili: sapevi che stavi caricando un programma e quindi aspettavi quel tempo, e poi il sistema era di nuovo reattivo. Uscendo da questa fase, arrivò in massa l'MS-DOS.
Quello era un sistema operativo vero, nel senso che quando tu lo carichi, interagisci principalmente direttamente con il sistema operativo. Ha una sua shell, puoi digitare comandi che sono solo quelli del sistema operativo. E questi sistemi operativi erano profondamente orientati al disco.
Avevano senso, erano stati necessari dopo la fase degli 8 bit per il fatto che c'erano supporti di memorizzazione di massa collegati al computer che avevano una loro complessità, che necessitavano di un'articolazione in cartelle, in diversi tipi di file eseguibili che dovevano essere quindi dal sistema operativo caricati in memoria e terminati, e tutte queste cose qua. Questa cosa, ovviamente, per gli utilizzatori degli home computer è stata un cambio di paradigma, perché si è passati a qualcosa di reale. Eppure, diciamoci la verità, comunque questi sistemi operativi basilari, primordiali come l'MS-DOS (che comunque ha delle origini nobili, perché prende delle idee da Unix), a pensarci bene altro non erano che dei minuscoli layer anch'essi, con cui l'utente interagiva solo in due casi: quando doveva caricare un programma o quando doveva fare delle operazioni sui file, muoverli da una parte all'altra, formattare un disco.
Il sistema operativo a cui siamo abituati noi oggi è un oggetto diverso. È un oggetto che continua a essere presente, tangibile, di continuo, durante l'utilizzo della macchina. Fa parte anche della, come dire, dell'interfaccia, del modo in cui si presentano a noi le applicazioni, del modo in cui il multitasking è gestito.
Fa parte del sistema operativo. E io direi che il primo sistema operativo di questo tipo, cioè quello che costituisce non solo un layer per caricare i programmi e per fare operazioni sul disco, ma un sistema operativo che costituisce l'interfaccia principale tra l'utente e il computer, il primo che ho utilizzato è stato Windows 95. Ora, è facile fare la battuta ignorantella su quanto Windows 95 fosse una merda e cose di questo tipo.
La verità è che per i tempi era un salto enorme, ed era un sistema operativo con delle idee piuttosto importanti messe nelle mani della maggior parte degli utenti di computer a quel tempo. Vi ricordo, ad esempio, che Windows 95 aveva un multitasking preemptive. Che prima di allora un multitasking, diciamo, vero, non cooperativo, ma in cui c'è il time sharing e il sistema operativo alloca un pezzettino di CPU a questo processo, un pezzettino all'altro, un pezzettino all'altro, noi lo avevamo visto solo con AmigaOS.
Ma siccome l'Amiga era basato sul processore 68000, non c'era alcuna separazione nello spazio di indirizzo dei processi, quindi un processo, appena si comportava male e scriveva nello spazio di un altro o nello spazio del kernel, la macchina andava in crash: le famose "Guru Meditation" o "Freed" varie, e così via. Quindi l'Amiga era sicuramente molto evoluto per il suo tempo, ma sarebbe difficile oggi dire che comunque quel tipo di multitasking, con quei limiti di stabilità, potesse essere considerato, diciamo, alla stregua di Windows 95. Diciamoci la verità, Windows 95 era profondamente evoluto rispetto alle versioni iniziali di AmigaOS.
Aveva uno stack TCP/IP nativo, quindi si poteva collegare ad internet, aveva un certo grado di protezione della memoria perché eseguito nella modalità protetta del processore 386. Le applicazioni a 32 bit avevano un loro spazio di indirizzi. Purtroppo, le applicazioni a 16 bit, per motivi di compatibilità, condividevano lo spazio di indirizzamento, il che voleva dire che se un'applicazione a 16 bit andava in crash, si tirava dietro tutte quelle altre a 16 bit, e a volte si tirava dietro anche il kernel.
C'era anche il problema che le chiamate di sistema, anche dei processi a 32 bit che giravano in modalità protetta, non c'era separazione tra kernel space e user space. Le chiamate di sistema venivano eseguite nella stessa modalità, non in un compartimento separato. Anche i driver spesso venivano eseguiti al livello di esecuzione più alto, senza alcun limite a ciò che potessero fare, ai danni che potessero fare, ai freeze che potevano poi causare al sistema.
Però, comunque, era un sistema operativo multitasking preemptive con protezione della memoria, e lì era la prima volta che la gente davvero utilizzava il multitasking sul serio, sia perché c'erano i processi di sistema, e anche il semplice TCP/IP costituiva un motivo fondamentale per avere dentro il computer dei processi che svolgevano varie funzioni. Magari, che ne so, scaricavi un file, nel mentre aprivi il client delle email e scrivevi un'email, e questo effettivamente è utilizzare a tutti gli effetti un sistema operativo multitasking. Poi c'erano grandi limiti di memoria ai tempi.
Io vi ricordo anche che, nonostante Windows 95, tra le altre cose, implementava un file di swap dove le pagine dei processi che venivano utilizzati poco potevano essere registrate per liberare la memoria ad altri processi più attivi, siccome c'era una differenza abissale tra la velocità della RAM e la velocità del disco, questo sistema finiva per funzionare male. C'erano tempi di esecuzione a volte lentissimi, il sistema si piantava, sentivi la testina del disco andare avanti e indietro, però fatto sta che Windows 95 è stata una rivoluzione ed è stato il primo sistema operativo multitasking serio con un'interfaccia grafica a finestre che le masse hanno utilizzato. Da quel momento in poi, per avere davvero di meglio.
. . ovviamente esistevano anche le workstation Unix.
Solaris e tante altre, con degli Unix con interfaccia grafica, multitasking più evoluto e tutte queste belle cose qua. Però l'informatica di massa non si poteva permettere il ricorso a quei sistemi, per cui noi, diciamo, parliamo delle cose che la maggior parte delle persone potevano effettivamente utilizzare. Il salto dopo Windows 95 è stato Windows NT: una protezione dei processi molto più seria, un'architettura molto più seria e una stabilità neanche paragonabile a quella di Windows 95.
Ma Windows NT era un sistema operativo pensato, diciamo così, per le aziende, per il lavoro. Ma il kernel NT poi ha trovato spazio nella versione di Windows XP, che era a tutti gli effetti il kernel NT, però pensato per rimpiazzare Windows 95 e le successive versioni, Windows 98 eccetera, che sono seguite. Quindi lì c'è stato veramente un salto fondamentale rispetto a quello che avevamo prima.
Tuttavia, io tra il '96 e il '97 avevo iniziato a utilizzare Linux perché, per varie vicissitudini, mi ero avvicinato prima ad internet utilizzando Windows, poi mi era arrivata tra le mani una distribuzione Slackware che avevo installato sul computer in modalità multiboot, e avevo capito che la mia strada era quella. Io a quei tempi frequentavo architettura, ma avevo già la passione per l'informatica e compilavo kernel dalla mattina alla sera, imparavo a programmare in C proprio in quel momento, in quegli anni. E insomma, era chiaro che quella macchina per me era la macchina per fare sviluppo, per fare hacking, per occuparmi di sicurezza informatica, perché aveva di default un compilatore in C, un debugger, gli editor e un sistema Unix.
Avevo un sistema Unix sotto le mie mani. Cosa volevo? Cosa avrei potuto chiedere di più?
Non c'era paragone dal mio punto di vista, anche se magari Windows a quei tempi aveva sicuramente dei punti di forza rispetto a Linux dal punto di vista del desktop, perché Windows XP era un sistema operativo ormai maturo, aveva un botto di roba, quindi aveva sicuramente dei vantaggi rispetto a Linux, ma poi Linux avrebbe, diciamo, in parte recuperato e così via. Ma non c'era neanche paragone per quello che potevi fare se eri uno smanettone, con i sorgenti del kernel in mano. Quindi in realtà la mia storia da programmatore di sistema, e così via, parte proprio da lì.
Parte nel '96, parte con Linux, e con Linux continuo a stare per 12 anni. 12 anni in cui ho cambiato via via diverse distribuzioni, in cui spesso mi sono scritto addirittura i miei driver quando è stato necessario, ho partecipato a progetti, ho configurato un miliardo di cazzate. Ora, parentesi: di tutte quelle cose che io ho imparato configurando di qua e configurando di là, una volta che io conosco, per esempio, le idee principali del TCP/IP, dopo qualche mese che inizio a configurare Linux, quando il sistema di configurazione cambia del tutto e io devo configurare gli stessi IP, le stesse maschere, gli stessi routing, quindi tutti gli stessi concetti su file diversi, la conoscenza sul TCP/IP a me rimane, ma la conoscenza quella, diciamo, di 'come si configura un particolare sistema' non serve a niente.
La puoi prendere e buttare nel cesso, non serve a niente perché non era conoscenza vera. Stavi imparando come qualcuno aveva pensato che una cosa si dovesse fare. E allora, mentre ci promettevano che Linux sarebbe stato il futuro anche nel desktop, e mentre invece non c'era nessuno che controllava le idee di progetto di Linux, io ero là.
In quei 12 anni, ogni volta che facevamo un upgrade si spaccava qualcosa. Bene, aggiustare, cercare file di configurazione. .
. Cos'è che hanno cambiato? Ma perché hanno rotto tutto senza motivo?
Compravo una nuova webcam, una nuova stampante: il delirio. Perché non va, come si fa, come non si fa, qual è il problema, e così via. 12 anni di questa cosa.
Solo che all'inizio c'era tanto da imparare, ma man mano che andavo avanti avevo sempre meno da imparare e sempre più da perdere. Inoltre, era sempre difficile comprare l'hardware migliore, perché l'hardware non era progettato per Linux. Ora ci sono alcune linee di portatili esplicitamente pensate per Linux, penso ad esempio a Dell, e anche altri progetti, anche i ThinkPad, altri progetti poi più specifici e così via.
Però allora perlopiù, diciamo, dovevi lottare contro il fatto che poi magari non c'era il driver, allora compravi la macchina anche in prospettiva del supporto software che tu ne potessi ricevere. Non funzionava bene ovviamente l'ibernazione, quindi la batteria durava poco. In generale, tutta la gestione dell'energia era abbastanza scarsa e a un certo punto io mi sono rotto le scatole e ho iniziato a pensare: "Chi è che me lo fa fare?
". Cioè, se io ho 8 ore in cui posso produrre delle cose che mi sembrano interessanti. .
. (Scusate, mi ha fermato un mio amico che non vedevo da molti anni e mi ha raccontato di alcuni miei amici di Gela che non vedevo da molti più anni ancora, forse da 30 anni. ) Stavo dicendo, insomma, la mia idea è quella di massimizzare quello che io faccio come output creativo, lavorativo, qualsiasi cosa io ritenga sia utile.
Non voglio fare la babysitter del computer. E dopo molti anni, dopo molti anni, sopiti gli entusiasmi della compilazione del kernel di quando avevo 17-18 anni e smanettavo dalla mattina alla sera, volevo programmare. Tra l'altro, questa faccenda qua del culmine dell'esperienza di Linux, e quindi poi di me che sono passato a macOS, è accaduta prima che io iniziassi a programmare Redis.
Quindi Redis è stato programmato all'inizio su un sistema Mac, perché il fatto è che, ora ci arriviamo, quando tu decidi che non vuoi utilizzare più Linux, cos'è che puoi utilizzare se non Mac? Perché Mac è allo stesso tempo uno Unix, così come lo è Linux, ma senza tutte quelle rotture di palle e, allo stesso tempo, con l'hardware migliore che puoi trovare. Ora, da questo punto di vista, bisogna necessariamente rimarcare un concetto.
Mentre quando tu compri un iPhone, stai comprando un hardware molto costoso per quello che è il valore d'uso che tu ricevi, quando tu compri uno di questi nuovi MacBook Air, che è uscito da poco con l'M4, e lo paghi quanto un iPhone perché costa, non lo so, 1200-1300 euro, una cosa del genere, stai comprando il miglior hardware che quei soldi possono comprare. Perché la Apple è un'azienda molto grande e, così come a volte le aziende che fanno pasta vendono la stessa pasta a diversi prezzi con diversi marchi per diverse fasce di mercato perché hanno comunque una marginalità alta in tutti i casi, e quindi è conveniente fare un discorso di questo tipo, allo stesso modo la Apple ragiona in una determinata modalità quando vende computer, in un'altra modalità quando vende telefoni, perché il computer è meno uno status symbol del telefono. Molte persone semplicemente, se un MacBook Air invece di 1300 costasse 4.
000, non lo comprerebbero; se costasse 3000 euro, e così via. Alla fin fine si rivolgerebbero ad altri sistemi, eccetera. Per cui il valore che tu ricevi è molto diverso in questi due casi.
E mentre io sono abbastanza d'accordo che magari un iPhone può essere una scelta poco conveniente dal punto di vista di ciò che ricevi per quanti euro spendi, diverso è il discorso che accade col MacBook. E in più ti becchi un sistema operativo, tutti gli aggiornamenti del caso per parecchi anni, hai uno Unix e hai un computer che funziona. Ma questo ancora, questa diciamo è stata l'introduzione finora, ma ancora non chiarisce.
. . e infatti devo allungare perché ero arrivato a casa.
. . non chiarisce davvero alcune cose.
Allora, quindi abbiamo detto: se tu fai programmazione di sistema in Unix, ma anche se scrivi programmi desktop, comunque il Gold Standard è il Mac. Quindi in tutti i casi in cui tu sei uno sviluppatore, se scrivi programmi di sistema, li scrivi per Mac con differenze minime. Ovviamente ti serve una macchina Linux per testare su scala; tutti i test reali di Redis sono fatti su Linux, ma lo sviluppo può andare avanti su macOS senza problemi.
Io i vector search li ho implementati totalmente su macOS e poi ho fatto un minimo di cambiamenti delle feature macro che dovevo abilitare per le chiamate di sistema, quattro cazzate, e su Linux funzionava e funziona tutto. Per altre cose che sono più dipendenti dalle chiamate di sistema, si fanno tanti test in Linux, ma tu puoi benissimo fare lo sviluppo su Mac. Quindi in realtà, per meglio capire questa dinamica, uno dovrebbe farsi una domanda: "Io col computer cosa ci faccio?
". E io ci faccio sostanzialmente tre cose. Ci programmo, e ci programmo in ambiente POSIX, che è l'API standardizzata di Unix, quindi scrivo software di sistema per ambienti Unix.
Ci programmo poi a più alto livello con vari linguaggi di scripting. Faccio programmazione embedded con MicroPython o in C per l'RP2040, quindi tutti gli SDK che voglio ce li ho. Faccio queste cose qua.
Poi, sono un utilizzatore di software desktop a vario titolo. Il che significa che io utilizzo Scrivener per scrivere i miei libri, utilizzo il browser che voglio, che sia il più aggiornato e che funzioni il meglio possibile, utilizzo il client, che ne so, per Twitter, utilizzo DaVinci Resolve per fare il mio editing video. Cioè, tutta quella che è la sfera dei software desktop ad alto livello è una cosa che io faccio spesso col computer, e da questo punto di vista il Mac ha tutti i software che Linux non ha.
Perché non ci sono i numeri per giustificare il porting di molti software su Linux, perché Linux ha una storia mortale di rompere le API col passato e quindi forza chi scrivesse un software per Linux a continue modifiche, casini di installazione, gestione di pacchetti da una distribuzione all'altra e così via, perché Linux in realtà è una famiglia di sistemi operativi, non è un sistema operativo. E poi, come terza cosa, io che ci faccio con questo computer? Ci eseguo dei modelli di reti neurali grandi, per cui ho bisogno di un sacco di memoria o VRAM.
E questa memoria, nel caso del Mac, è condivisa, perché la GPU e la CPU hanno la memoria unificata e quindi se io compro un Mac come quello che ho comprato, che ha 128 GB di RAM, questa memoria sarà vista sia dalla mia GPU (che vabbè, non è veloce come una GPU high-end Nvidia e compagnia, ma è accettabile) sia dalla CPU. Io ci faccio girare i modelli degli LLM grossi in locale per vedere come vanno. Ci faccio il training di modelli abbastanza grossi in tempi ragionevoli, per quello che è possibile, ma io faccio il training di modelli di 50 milioni, 100 milioni, 300, 400 milioni di parametri, a volte con successo, lasciando il computer a volte acceso per 3 giorni, ma si riesce.
Quindi queste sono le tre declinazioni con le quali io utilizzo il computer: non ci gioco. In queste tre declinazioni, cioè l'utilizzo casuale da desktop come utente qualsiasi in cui utilizzo programmi, l'utilizzo da sviluppatore e l'utilizzo per l'intelligenza artificiale, sia per inferenza che per machine learning, in tutti questi tre casi il Mac rappresenta il meglio attualmente disponibile, nonostante quanto abbiano sabotato il sistema prendendo gli sviluppatori del progetto Mac e allocandoli ad altre piattaforme che vendono di più, tipo l'iPhone o l'Apple Watch. E da questo ovviamente c'è stata una perdita di qualità della piattaforma Mac, ma ancora, con tutte le cazzate che ha, rimane un sistema migliore secondo me degli altri.
In più, tutto ciò con hardware eccellente, con un servizio clienti abbastanza buono. Per tale motivo, io davvero non vedo cos'altro dovrei usare.
