In questo articolo Indice dei contenuti 3 sezioni
Valve sta trasformando il client di Steam per Linux in un’applicazione nativa a 64 bit e allo stesso tempo cambia il modo in cui il programma si appoggia a librerie e dipendenze del sistema operativo. È un intervento che tocca la compatibilità con le distribuzioni Linux, la manutenzione dei pacchetti e la necessità di conservare componenti software ormai considerati legacy.
Disponibile dal 2013, il client di Steam per Linux è rimasto legato per oltre 13 anni all’architettura a 32 bit, anche se i processori x8664 sono lo standard da parecchio tempo.
Perché servivano ancora le librerie a 32 bit
Per capire la portata della novità bisogna separare l’architettura del sistema da quella delle applicazioni. Una distribuzione Linux a 64 bit riesce a far girare programmi compilati per x86 a 32 bit a patto che abbia le librerie giuste e che il kernel ne mantenga il supporto. Steam ha sfruttato a lungo questa possibilità e così su un computer con processore AMD o Intel a 64 bit poteva richiedere librerie i386 o i686, diverse dalle equivalenti x8664.
Su Ubuntu o Debian l’installazione poteva richiedere l’attivazione del supporto multiarch, cioè il meccanismo che permette a pacchetti di architetture diverse di convivere nello stesso sistema. Su Debian e derivate basta un comando dpkg per aggiungere l’architettura i386, poi APT si occupa di installare le dipendenze richieste.
Mantenere le librerie a 32 bit ha però un costo. Significa distribuire pacchetti in più, verificarne la compatibilità, seguire gli aggiornamenti di sicurezza e assicurarsi che il caricatore dinamico trovi le versioni corrette dei componenti condivisi. Per chi sviluppa le distribuzioni una dipendenza del genere è anche un freno alla semplificazione dei repository.
Un eseguibile nativo e il nuovo container Steam Runtime
Il cambiamento principale riguarda il programma vero e proprio. Valve ha aggiornato il binario del client portandolo da x86 a 32 bit a x8664. Un binario di questo tipo usa il formato ELF adeguato e di solito richiede l’interprete dinamico a 64 bit al posto del caricatore delle applicazioni i386. Le librerie dentro lo stesso processo devono avere un’architettura compatibile e non si può collegare direttamente una libreria condivisa a 32 bit a un normale processo a 64 bit. Sparisce così una dipendenza strutturale che accompagnava Steam da anni, mentre il processo nativo può contare su uno spazio di indirizzamento virtuale più ampio e sulle caratteristiche dell’ABI x8664.
Questo non vuol dire avere giochi più veloci. Le prestazioni dipendono soprattutto dall’eseguibile del titolo, dal motore grafico, dai driver, dalle API usate e dall’hardware. La novità riguarda innanzitutto il client che gestisce libreria, negozio, download e avvio dei giochi.
La seconda novità promette effetti più interessanti nel lungo periodo. Il client ora gira all’interno di un container Steam Runtime, lo stesso modello già usato per rendere più prevedibile il comportamento dei videogiochi Linux su distribuzioni diverse. Storicamente Steam si è affidato a un insieme di librerie chiamato Steam Runtime 1, noto con il nome in codice scout. Con l’ambiente containerizzato la base di librerie diventa più controllata grazie a funzionalità native del kernel come i namespace, che presentano ai processi un filesystem e un ambiente di esecuzione più uniformi. Il container usa comunque il kernel del sistema ospitante e deve dialogare con dispositivi, driver grafici, server audio e altri servizi, quindi non garantisce automaticamente un isolamento di sicurezza paragonabile a quello di una macchina virtuale dedicata.
Cosa cambia per Ubuntu, Fedora e Arch Linux
Distribuire software proprietario su Linux è sempre stato complicato per via della varietà di librerie e aggiornamenti. Ubuntu, Fedora, Arch Linux e openSUSE seguono politiche diverse nella gestione di pacchetti, dipendenze e versioni presenti nei repository. Un programma complesso come Steam deve fare i conti con librerie grafiche e servizi che evolvono a velocità differenti, e un aggiornamento può portare incompatibilità ABI, cambiare percorsi o sostituire funzioni su cui l’applicazione contava.
La nuova impostazione punta proprio a ridurre questa variabilità. Spostando più dipendenze dentro la runtime Valve può collaudare il client su un insieme di componenti più controllato, senza rincorrere ogni modifica introdotta dalle singole distribuzioni. Il vantaggio si fa sentire soprattutto sulle rolling release come Arch Linux, dove gli aggiornamenti arrivano di continuo, ma anche sui sistemi più conservativi o che limitano i pacchetti multilib.
Per considerare chiusa la transizione dai 32 ai 64 bit bisognerà attendere che il nuovo client maturi e arrivi sul canale stabile, oltre a una revisione documentata dei requisiti sulle librerie multilib. Intanto, per la prima volta dopo molti anni, il programma principale non è più il motivo tecnico che obbliga a conservare un’intera architettura software del passato.
Fonte: TecnoAndroid