Il desktop GEM di Digital Research, uno dei primi ambienti grafici per PC MS-DOS, è tornato su Linux in una forma sorprendentemente concreta. Lo sviluppatore sloveno Tomaž Štih ha presentato GEM for Linux, un port dell'ambiente desktop dell'Atari ST: le applicazioni condividono un display server capace di scrivere direttamente sul framebuffer del kernel o di mostrare il desktop in una finestra tramite Rasta, un emulatore framebuffer basato su SDL2. Il progetto, spiega Štih su LinkedIn, deriva da OpenGEM e FreeGEM ed è stato reso sicuro, ottimizzato, stabilizzato e compatibile a livello sorgente con il GEM dell'Atari ST.

La lunga derivazione del codice

La notizia ha radici profonde. GEM era tra le prime GUI di successo per i PC compatibili MS-DOS, e in Europa arrivò su macchine come l'Amstrad PC1512 e PC1640. Nel 1985 Apple minacciò Digital Research per la somiglianza con l'interfaccia Macintosh. DR accettò di modificare la versione PC: rimosse le icone dei drive sul desktop, le finestre sovrapposte e altre caratteristiche. La versione Atari non subì quegli interventi, e fu la base di un percorso diverso. Quando Caldera liberò i sorgenti nel 1999, la comunità FreeGEM iniziò a ripristinare le funzioni tagliate e ad aggiungerne altre, come le curve di Bézier dal runtime GEM/4 e i pulsanti 3D dal runtime GEM/5.

Non è il primo progetto FOSS a beneficiare di FreeGEM. EmuTOS è un sistema operativo e una GUI completamente open source per l'hardware Atari originale. Atari TOS combinava GEMDOS, derivato dalla tecnicia Digital Research, con una versione modificata di GEM. Gran parte del codice DR è disponibile online, ma non tutto è open source in senso stretto; FreeGEM e la distribuzione OpenGEM lo sono. Le ambizioni multitasking di DR, come X/GEM per FlexOS, non sono rimaste sepolte: FreeMiNT ha trasformato il GEM dell'Atari ST in un ambiente multitasking, mentre MagiC ha avuto anche una versione per Macintosh con CPU 68K. Il codice di MagiC è stato poi reso pubblico e lo sviluppo continua.

Minimalismo architetturale e controllo del runtime

GEM for Linux non è un tentativo di rendere Wayland obsoleto, né un semplice omaggio alla nostalgia. È un esempio di ambiente grafico che riduce gli strati intermedi: il display server può parlare direttamente con il framebuffer, senza passare da compositor complessi o servizi cloud. Per chi gestisce macchine locali o deployment self-hosted, questo rovescia la logica prevalente degli stack moderni, dove ogni livello di astrazione aggiunge flessibilità ma anche dipendenze e superfici da controllare. Qui la compatibilità con l'Atari ST e la derivazione da FreeGEM sono parte del valore: contano la prevedibilità e la possibilità di verificare il codice.

La dichiarazione di Štih sul vibe coding aggiunge un tassello. Alla domanda se il progetto fosse stato generato con il vibe coding, ha risposto di no: nella sua esperienza quel metodo tende a produrre codice gonfio e un'architettura scadente. Ha spiegato di usare l'AI con un approccio architecture-driven: prima definisce l'architettura, implementa la prima iterazione, poi rifattorizza e ripete. Per lui l'AI resta una sviluppatrice junior, e la responsabilità finale su architettura e qualità resta umana. Nel caso di GEM for Linux, dove pulizia del runtime e compatibilità sono obiettivi espliciti, la differenza si vede.

Per chi valuta deployment on-premise, i trade-off tra controllo e complessità sono analizzati anche su /llm-onpremise. GEM for Linux non è un framework per LLM, ma tocca un punto strutturale: la riscoperta di software locale, leggero e verificabile non è solo archeologia informatica. È un promemoria che il controllo dell'ambiente di esecuzione può essere una scelta architetturale, non un limite. Non sostituirà Wayland, ma riapre una finestra su un modo diverso di pensare il software.