Steam su Linux diventa a 64 bit: addio alla storica dipendenza i686

Valve sta trasformando il client della sua piattaforma di distribuzione videoludica in un’applicazione nativa a 64 bit, intervenendo contemporaneamente sul modo in cui Steam per Linux utilizza librerie e dipendenze del sistema operativo. Si tratta di una modifica che può incidere sulla compatibilità con le distribuzioni Linux, sulla manutenzione dei pacchetti e sulla necessità di conservare componenti software ormai considerati legacy.

Il client Steam per Linux, disponibile dal 2013, ha mantenuto per oltre 13 anni un legame con l’architettura a 32 bit, nonostante i chip x86-64 rappresentino da tempo lo standard.

Perché Steam per Linux utilizzava ancora componenti a 32 bit

Per comprendere l’importanza della novità bisogna distinguere l’architettura del sistema operativo da quella delle applicazioni. Una distribuzione Linux a 64 bit può eseguire programmi compilati per l’architettura x86 a 32 bit, purché disponga delle librerie appropriate e il kernel mantenga il relativo supporto.

Il client Steam ha sfruttato a lungo tale possibilità. Su un computer con processore AMD o Intel a 64 bit, il programma poteva quindi richiedere librerie i386 o i686, diverse dalle corrispondenti versioni x86-64.

Installare Steam su Ubuntu o Debian poteva comportare l’attivazione del supporto multiarch, il meccanismo che consente a pacchetti di architetture differenti di coesistere nella stessa installazione. Su Debian e sulle distribuzioni derivate, ad esempio, il comando sudo dpkg --add-architecture i386 permette di aggiungere l’architettura necessaria, mentre APT può successivamente installare le dipendenze richieste.

Mantenere librerie a 32 bit significa distribuire ulteriori pacchetti, verificarne la compatibilità, gestire gli aggiornamenti di sicurezza e assicurarsi che il caricatore dinamico riesca a individuare le versioni corrette dei componenti condivisi. Per gli sviluppatori delle distribuzioni, inoltre, una dipendenza come questa costituisce anche un ostacolo alla semplificazione dei repository.

Il nuovo client Steam utilizza finalmente un eseguibile x86-64

La modifica principale il programma Steam vero e proprio: Valve ha aggiornato il binario del client, passando dall’architettura x86 a 32 bit a quella x86-64.

Un binario x86-64 utilizza il formato ELF appropriato e normalmente richiede l’interprete dinamico /lib64/ld-linux-x86-64.so.2, anziché il caricatore delle applicazioni i386. Le librerie all’interno dello stesso processo devono avere un’architettura compatibile: non è possibile collegare direttamente una libreria condivisa ELF a 32 bit a un normale processo ELF a 64 bit.

La novità appena introdotta elimina una dipendenza strutturale che accompagnava Steam da molti anni. Inoltre, un processo nativo a 64 bit può beneficiare di uno spazio di indirizzamento virtuale più ampio e delle caratteristiche dell’ABI x86-64.

Steam a 64 bit non significa giochi intrinsecamente più veloci: le prestazioni di un videogioco dipendono soprattutto dall’eseguibile, dal motore grafico, dai driver, dalle API utilizzate e dalle caratteristiche dell’hardware. La modifica annunciata da Valve riguarda innanzitutto il programma che gestisce libreria, negozio, download e avvio dei giochi.

Steam Runtime: il client entra in un ambiente basato su container

La seconda novità è probabilmente quella destinata ad avere le conseguenze più interessanti nel lungo periodo. Valve introduce l’esecuzione del client all’interno di Steam Runtime container, utilizzando un modello già adottato al fine di rendere più prevedibile il funzionamento dei videogiochi Linux su distribuzioni differenti.

Storicamente, Steam ha utilizzato un insieme di librerie chiamato Steam Runtime 1, conosciuto con il nome in codice scout.

Con il passaggio a un ambiente containerizzato, Steam può contare su una base di librerie maggiormente controllata. Il meccanismo sfrutta funzionalità native del kernel Linux, tra cui i namespace, per presentare ai processi una struttura del filesystem e un ambiente di esecuzione più uniformi.

Il container continua a utilizzare il kernel del sistema ospitante e deve poter interagire con dispositivi, driver grafici, server audio e servizi necessari all’applicazione; non introduce quindi automaticamente un isolamento di sicurezza paragonabile a quello di una VM dedicata.

Perché la novità interessa Ubuntu, Fedora, Arch Linux e le altre distribuzioni

Una delle difficoltà storiche nella distribuzione di software proprietario su Linux riguarda la diversità delle librerie e dei loro aggiornamenti. Ubuntu, Fedora, Arch Linux e openSUSE adottano politiche differenti per la gestione dei pacchetti, delle dipendenze e delle versioni disponibili nei repository.

Un programma complesso come Steam deve confrontarsi anche con librerie grafiche, componenti di sistema e servizi che evolvono a ritmi diversi. Un aggiornamento può introdurre incompatibilità ABI, modificare percorsi oppure sostituire funzionalità sulle quali un’applicazione faceva affidamento.

La nuova soluzione cerca di ridurre proprio questa variabilità: spostando una parte maggiore delle dipendenze all’interno della runtime, Valve può collaudare il client rispetto a un insieme più controllato di componenti software, senza dover inseguire ogni singola modifica introdotta dalle distribuzioni.

Il vantaggio può risultare particolarmente significativo su sistemi rolling release come Arch Linux, dove gli aggiornamenti arrivano continuamente, ma anche sulle distribuzioni che adottano politiche più conservative o limitano la presenza di pacchetti multilib.

Per considerare conclusa la transizione dai 32 ai 64 bit bisognerà attendere la maturazione del nuovo client, la sua diffusione nel canale stabile e soprattutto una revisione documentata dei requisiti relativi alle librerie multilib. Intanto, per la prima volta dopo molti anni, il programma principale non è più il motivo tecnico che impone di conservare un’intera architettura software del passato.