Questo è il testo dell'intervento che tenni GNU/Linux Day 2023 a Signa. <https://www.firenze.linux.it/2023/09/linux-day-2023/>
Il testo integrale dell'intervento, così come le diapositive e il loro codice ROFF, è rilasciato con la licenza CC BY-SA 4.0 di Creative Commons. <https://creativecommons.org/licenses/by-sa/4.0/legalcode.it>
Per ulteriori informazioni sul GNU/Linux Day, la manifestazione italiana dedicata a GNU/Linux, al software libero, alla cultura aperta e alla condivisione, rimando al sito ufficiale dell'evento. <https://www.linuxday.it/>
Partendo dal presupposto che il software proprietario è un'ingiustizia e che i videogiochi liberi come Minetest [1] sono una manna dal cielo, quali sono le implicazioni, ma soprattutto le possibilità, di giocare a un gioco per Windows su GNU/Linux?
Prima un paio di considerazioni...
Il software proprietario è un'ingiustizia: sarebbe fantastico esaminare com'è fatto un videogioco e modificarlo per imparare, o semplicemente per il gusto di farlo e poi condividere la versione modificata con un amico, per divertirsi assieme. Tutto ciò con un gioco proprietario non è possibile. C'è chi modifica giochi proprietari, realizzando le cosiddette mod, però c'è un limite a quello che si può modificare di un programma senza possederne il codice sorgente. Inoltre, dal punto di vista legale, coi giochi proprietari non esiste nessuna tutela per chi vuole smanettare creativamente, anzi spesso gli autori delle mod sono perseguiti dagli autori del videogioco modificato.
A coloro che considerano i videogiochi una forma d'arte e che perciò ritengono sacrilego alterare la visione originale dell'artista, voglio dire due cose. Modificare un videogioco e ridistribuirlo non impedisce di fruire della prima versione. Non stiamo dipingendo sulla stessa tela del pittore, ma su un'altra. Non si tratta neanche di plagio, ma di arricchimento.
Se proprio non riuscite a digerire una società dove c'è meno enfasi sull'autore e viene data maggiore importanza al processo artistico per tutti, potreste pubblicare soltanto il codice del motore del gioco e non i dati. Ovvero, liberate la parte logica del programma che fa funzionare il gioco, di solito si tratta dell'eseguibile; in modo che tutti possano capire come funziona il sistema di animazioni, come fate a disegnare una schermata o a riprodurre una musica, però le animazioni, i disegni, e la musica non saranno liberamente modificabili dagli altri. È meglio un gioco interamente libero, però un motore libero è un buon inizio per il cambiamento.
Un gioco proprietario per GNU/Linux non è intrinsecamente meglio di uno altrettanto proprietario per Windows, solo perché gira su un sistema libero. Addirittura un purista asserirebbe che è peggio, poiché inquina il sistema che è libero. Di sicuro un gioco proprietario per GNU/Linux è peggio di un gioco libero per Windows, in quanto il gioco libero per Windows invita a scoprire i vantaggi della libertà su un sistema proprietario, mettendo in discussione la logica di Microsoft e proponendo un modello equo. Invece, dall'altra parte, il gioco proprietario su GNU/Linux non fa altro che diminuire la libertà di chi usa quel sistema, che di base sarebbe libero.
Non condivido l'entusiasmo nei confronti dell'azienda Valve, che investe su Linux semplicemente per creare un suo sistema, per competere con quelli di Nintendo o Sony, non perché abbia a cuore i concetti di libertà informatica di chi ha abbandonato il modello proprietario. Nel 2003 Valve aprì Steam [2], un negozio digitale dove comprare videogiochi con dei sistemi di restrizione (DRM). Nel 2013 Valve scelse GNU/Linux [3] per farne il sistema operativo dei suoi computer e della sua console portatile. Ciò ha ridestato l'interesse commerciale dei giochi per GNU/Linux, facendo aumentare il numero dei titoli proprietari per questo sistema. Se vi interessa solo giocare ai videogiochi col computer, questa è una buona notizia [4]. Tuttavia, se vi interessasse solo giocare ai videogiochi, dubito che sul computer installereste GNU/Linux.
Bene, abbiamo capito: i giochi proprietari sono brutti! E un'ingiustizia! Mettiamo però che ci vogliate giocare lo stesso, nonostante ne riconosciate gli aspetti negativi. Alla fine la vita è una questione di equilibri e una partitella ogni tanto a un videogioco proprietario non può erodere i vostri valori, se ci credete davvero. Da qui la domanda: qual è il modo di fare questa partita che più va nella direzione del software libero e soprattutto che contribuisce maggiormente allo sviluppo di questa cultura? Non comprate da Steam, meglio scaricare. GOG.com [5] vende giochi senza sistemi di restrizione. Lo stesso itch.io [6]. Trovate un negozio o uno sviluppatore che venda videogiochi senza sistemi di restrizione. Niente DRM!
Se volete giocare a un gioco per Windows su GNU/Linux, dovete installare una macchina virtuale? Dovete tenere un computer o un disco apposta con Windows, regalando così soldi e una fetta di mercato a Microsoft, per un solo gioco? No! Vi presento Wine.
Wine non è un emulatore (Wine Is Not an Emulator
), è un programma il cui sviluppo è iniziato nel 1993 per far funzionare i programmi di Windows 3.1 su Linux [7]. Da allora si è evoluto ed è in grado di far girare i programmi di ogni versione di Windows.
Wine esegue il programma desiderato e converte in tempo reale le chiamate alle API di Windows in chiamate POSIX [8]. Ciò significa che Wine può girare su tutti i sistemi POSIX come GNU/Linux, Mac e i BSD. In soldoni: Wine è come un amico che vi ascolta quando siete ubriachi. Voi ubriachi siete l'equivalente di un programma per Windows. Immaginate di star dicendo «Per favore, aprimi una finestra e disegnaci dentro il menù in alto e un'immagine di uno gnu». Wine non fa altro che ascoltarvi, ma anziché assecondare le richieste da ubriaco e aprire una finestra di Windows, compie l'azione per GNU/Linux, disegnando una finestra di X11 con dentro uno gnu. Pura magia! E tanta fatica di gente che si è sbattuta per riscrivere le chiamate di Windows in equivalenti.
Su Debian vi basta un bel `apt install wine
`. Se avete un po' di esperienza con GNU/Linux, vi consiglio d'installarlo seguendo la guida sul sito di Wine [9] per avere la versione più recente.
Dopo avere installato Wine, basta cliccare su un programma per Windows e vedere se parte. Altrimenti dal terminale digitare `wine
` e il percorso del programma per Windows. Wine riesce a far funzionare tanti programmi, ma non tutti. Lo sviluppo di Wine è continuo per tenere conto dei cambiamenti di Windows. Non vi potete aspettare che ogni cosa funzioni. Gli sviluppatori di Wine hanno meno risorse di Microsoft e, ciononostante alcuni giochi funzionano meglio con Wine, soprattutto quelli vecchi che piacciono a me. Non temete, sul sito di Wine trovate una lista delle compatibilità [10].
Wine può essere usato per tutti i programmi di Windows.
Se foste un'azienda o un professionista interessato a cambiare sistema operativo, a favore di uno che rispetti la vostra libertà e quella degli altri, potreste sfruttare Wine nel periodo di transizione per migrare i dati dai vecchi programmi per Windows a quelli nuovi per GNU/Linux, senza dover installare Windows e senza comprare una licenza da Microsoft! Wine è un programma importante [11] che dimostra la flessibilità del software libero, sebbene presenti degli aspetti controversi.
La critica più grande che viene mossa verso Wine è che nasce e serve per utilizzare software proprietario. La sua esistenza deriva da motivi pratici, economici e di comodità, piuttosto che ideologici. Wine non aumenta la libertà informatica di chi lo usa, a meno che non si consideri il vantaggio di non dipendere da Windows, che non è trascurabile, visto che Windows è un sistema operativo che spia i suoi utenti e che adotta svariate pratiche quantomeno discutibili [12]. Di per sé Wine non contribuisce alla costruzione di un ecosistema informatico libero. Tuttavia si potrebbe sostenere che fornisce un supporto a tale scopo, permettendo di studiare programmi esistenti su un altro sistema operativo, affinché vengano riscritti liberi e per sistemi liberi. Un altro punto a suo favore è la flessibilità che esso permette, soprattutto nei casi in cui ancora non esiste un programma di software libero per svolgere un determinato compito, o non viene ritenuto all'altezza. D'altro canto si potrebbe criticare quest'enfasi sulla funzionalità, che rischia di distogliere l'attenzione sul problema principale, ovvero la libertà e non la mera qualità dei programmi. Un programma proprietario per Windows può essere di buona qualità. Accontentarsi di farlo girare con Wine non risolve l'ingiustizia di non avere accesso al codice sorgente. In sintesi, il miglior uso che si può fare di Wine è come toppa, o al massimo come compromesso. Non dev'essere assolutamente visto come una soluzione a lungo termine. La soluzione c'è ed è pubblicare il codice sorgente con una licenza libera. Un altro scopo positivo è quello di preservare giochi vecchi, che sulle versioni correnti di Windows funzionano male o non funzionano proprio, se si crede che tali opere siano degne di essere preservate e che ci sia del valore nel continuare a giocare a un videogioco di svariati anni fa. È pure un modo per rispettare l'ambiente, dato che i videogiochi vecchi consumano meno e che oggi vengono sprecate troppe energie per titoli mediocri ed eccessivamente costosi, quando potremmo riscoprire un sacco di gemme dimenticate, risparmiare soldi ed essere felici.
Per disegnare la grafica, spesso i giochi di Windows spesso si appoggiano alle API Direct3D di Microsoft. Quando Wine riceve chiamate alle Direct3D, le converte in chiamate OpenGL. OpenGL [13] è un'API multipiattaforma per accedere alla potenza di calcolo delle schede video, indipendentemente dal sistema operativo per cui state scrivendo il programma. OpenGL funziona bene, però dal 2016 esiste l'API Vulkan [14] che ha lo stesso obiettivo di OpenGL, è sviluppata dagli autori di OpenGL e, per merito di alcune differenze strutturali che non spiegherò, riesce a ottenere prestazioni migliori in molti casi. La differenza lampante tra OpenGL e Vulkan è che, nella stessa scena, Vulkan diminuisce il carico sul processore spostandolo sulla scheda grafica, fornendo così agli sviluppatori maggiore potenza di calcolo. In breve, Vulkan permette di sfruttare di più la scheda grafica rispetto a OpenGL, liberando il processore per altri compiti. Quindi i giochi girano meglio. Wine ancora non sfrutta Vulkan. Ci stanno lavorando, ma sono agli inizi. DXVK è un progetto scollegato da Wine che permette di trasformare le chiamate alle Direct3D 9, 10 e 11 in chiamate Vulkan. Installando DXVK nella cartella di Wine, potrete ottenere delle prestazioni migliori sui giochi che si appoggiano alle Direct3D 9, 10 e 11, nel mentre il progetto Wine mette a punto l'interfaccia con Vulkan, come alternativa a quella attuale con OpenGL. DXVK è una toppa per una parte in lavorazione di Wine, che è a sua volta una toppa.
Installare DXVK è leggermente più complicato d'installare Wine, però non è obbligatorio per usare Wine. Si tratta di un in più per far andare meglio i programmi che si appoggiano alle Direct3D 9, 10 e 11. Scaricate DXVK da GitHub [15] o compilate il codice sorgente [16]. Più persone dovrebbero compilare il codice sorgente: non bisogna temere il codice sorgente, la rivoluzione del software libero passa attraverso la compilazione indipendente del codice sorgente!
Se la cartella di Wine, o in gergo prefisso, è a 32 bit, copiate tutti i file DLL nella cartella x32 di DXVK nella cartella di Wine, sotto drive_c/windows/system32. Di solito il prefisso si trova in $HOME/.wine
.
$ export WINEPREFIX=$HOME/.wine
$ cp x32/*.dll $WINEPREFIX/drive_c/windows/system32
Se la cartella di Wine, o in gergo prefisso, è a 64 bit, copiate tutti i file DLL nella cartella x64 di DXVK nella cartella di Wine, sotto drive_c/windows/system32. Dopodiché copiate tutti i file DLL nella cartella x32 di DXVK nella cartella di Wine, sotto drive_c/windows/syswow64. Di solito il prefisso di Wine si trova in $HOME/.wine
.
$ export WINEPREFIX=$HOME/.wine
$ cp x64/*.dll $WINEPREFIX/drive_c/windows/system32
$ cp x32/*.dll $WINEPREFIX/drive_c/windows/syswow64
Per sapere se il prefisso di Wine è a 32 o a 64 bit, basta controllare se, all'interno del prefisso, esiste la cartella drive_c/windows/syswow64. Se c'è, quello è un prefisso di Wine a 64, altrimenti è a 32 bit.
Adesso dobbiamo dire a Wine che, quando cerca le librerie contenute nei file DLL che abbiamo copiato, non deve eseguire le sue funzioni di traduzione, ma quelle contenute nelle DLL di DXVK. Eseguiamo Wine con la variabile di ambiente WINEDLLOVERRIDES
valorizzata nel seguente modo: d3d9,d3d11,d3d10core,dxgi=n
.
$ WINEDLLOVERRIDES="d3d9,d3d11,d3d10core,dxgi=n" wine nome_programma
La n
di native (nativo) indica che quelle librerie non devono essere tradotte da Wine, ma caricate dal prefisso come file DLL. La b
di builtin (integrato) indicherebbe il contrario. Potremmo specificare una precedenza, separando i caratteri con una virgola. n,b
indicherebbe che Wine deve prima provare a caricare la libreria dai file DLL all'interno del prefisso e, solo se fallisce, può provare a tradurre quella libreria con le sue funzioni interne.
Il comando di prima non salva niente nella configurazione di Wine, esegue e basta un programma con Wine, sfruttando le DLL di DXVK, contrariamente a quello che sarebbe il comportamento di base. Perciò ogni volta dev'essere digitato per intero, per usufruire di DXVK. Le alternative sono farsi un alias o un comando che valorizzi prima la variabile di ambiente WINEDLLOVERRIDES
e poi chiami Wine, oppure esportare la variabile di ambiente nella linea di comando da cui lanciamo Wine; oppure più semplicemente usare winecfg (Wine Configuration Editor) [17] per salvare le impostazioni delle DLL. winecfg può salvare le impostazioni in generale o per un eseguibile specifico. Mettiamo che vogliate le DLL di DXVK solo per alcuni giochi. Dal pannello Applications (applicazioni) scegliete se cambiare le impostazioni per tutti i programmi, selezionando Default Settings (impostazioni di base) o per un programma in particolare. Potete aggiungere un programma cliccando su Add application... (aggiungi applicazione).
Dopodiché spostatevi sul pannello Libraries (librerie), scrivete o cercate la libreria da scavalcare, rispettivamente nel campo New override for library: (nuova eccezione di libreria) o nella lista sotto Existing overrides: (eccezioni esistenti). Se la DLL non è presente nella lista, scrivete il nome della DLL e premete Add (aggiungi), poi selezionatela dalla lista e col tasto Edit (modifica) scegliete la preferenza, nel nostro caso native. Premete Ok per salvare.
Se il gioco è d'inizio 2000, probabilmente utilizza Direct3D 8. In quel caso c'è D8VK [18], un progetto derivato da DXVK che fa la stessa cosa di DXVK, ma per Direct3D 8. Sia l'installazione che la configurazione sono identiche a DXVK, con l'unica differenza del nome della DLL, che in questo caso è d3d8.
Se il gioco risale a prima del 2000 e sfrutta DirectX precedenti alla 8 o Glide, le cose si semplificano o si complicano. Per i giochi che usano le versioni precedenti a DirectX 8, Wine da solo va più che bene: si tratta di giochi semplici e il vantaggio di usare Vulkan al posto di OpenGL è minimo, soprattutto considerata la potenza dei computer odierni. Per quanto riguarda Glide, al momento non esistono librerie di conversione libere e attualmente sviluppate, che io sappia. Le opzioni che conosco sono nGlide [19] e dgVoodoo2 [20], però non essendo software libero non ne parlerò. Inoltre il loro caso d'uso può dirsi specifico rispetto all'obiettivo di questo intervento.
Prima di concludere voglio mostrarvi Lutris [21], un'interfaccia grafica scritta in Python e GTK per gestire Wine, DXVK ed eventualmente dgVoodoo2, oltre che per semplificare il più possibile il processo di giocare ai videogiochi su GNU/Linux, emulatori e interpreti inclusi. Sul sito di Lutris trovate come installare e configurare tantissimi giochi, automaticamente.
Ho iniziato a usare Wine insieme a Lutris, nel 2019, quando passai a GNU/Linux. Poi, curioso di scoprire come funzionasse tutto ciò, ho scalato al contrario la pila dei software che rendono possibile giocare ai giochi Windows su GNU/Linux. Adesso Lutris lo uso di rado, preferendo la linea di comando per semplicità. Per correttezza devo dire che, nonostante Lutris sia software libero, permette d'installare software proprietario, oltre ai giochi, come per esempio dgVoodoo2. Ho la sensazione che questo progetto sia più interessato a far funzionare i giochi, piuttosto che alla libertà del software, visto pure il loro utilizzo di Discord. Questa è la mia opinione e sensazione a pelle, senza conoscere nessuno degli sviluppatori. Prendetele per quello che valgono, ricordando che sono un integralista GNUslamico.
Secondo il sito di Wine [22], la versione Mac di The Sims 3 è basata su Wine ed è uno dei motivi per cui The Sims 3 funziona bene con Wine.
Il progetto DXVK è nato dall'esigenza del suo sviluppatore, Philip Rebohle, di giocare a Nier: Automata su GNU/Linux [23][24].
L'autore di D8VK, Jeffrey Ellison, ha invitato gli sviluppatori di DXVK a includere il suo codice nel progetto [25], affinché DXVK traduca anche Direct3D 8 in Vulkan. La proposta è stata accettata, ma l'unione ancora non è terminata. Nel prossimo futuro non sarà più necessario installare D8VK a parte: basterà avere DXVK per tradurre le chiamate alle Direct3D 8, 9, 10 e 11 in Vulkan.
Il codice dell'API Glide fu pubblicato nel 2003 [26]. Quindi non c'è nessun ostacolo di tipo tecnico che impedisca a un programmatore di buona volontà di scrivere una libreria libera di conversione da Glide a Vulkan.
Wine è un gran bel pezzo di programma! Al di là delle critiche sulla sua filosofia, è interessante e istruttivo capire come funziona. DXVK e D8VK sono dei progetti utili, che in futuro non serviranno, quando gli sviluppatori di Wine finiranno d'implementare l'interfaccia con Vulkan. Per il momento rappresentano in un più, per i curiosi e gli smanettoni, desiderosi di migliorare le prestazioni, già più che buone. Ricordatevi sempre che Wine traduce in tempo reale le API di Windows in chiamate POSIX. Bisogna provare rispetto per un'impresa del genere! Come dicono su Internet «Linux gamers don't wine» (i giocatori su Linux non si lamentano e non usano Wine).
1 Minetest: open source voxel game engine <https://www.minetest.net/>
2 Steam <https://store.steampowered.com/>
3 Gabe Newell: "Linux and open source are the future of gaming" <https://www.pcgamer.com/gabe-newell-linux-and-open-source-are-the-future-of-gaming/>
4 Videogiochi proprietari con DRM per GNU/Linux: un bene o un male? <https://www.gnu.org/philosophy/nonfree-games.it.html>
5 GOG.com <https://www.gog.com/>
6 itch.io <https://itch.io/>
7 Wine History <https://wiki.winehq.org/Wine_History>
8 POSIX su Wikipedia <https://it.wikipedia.org/wiki/POSIX>
9 Download Wine <https://wiki.winehq.org/Download>
10 Wine Application Database <https://appdb.winehq.org/>
11 Importance Of Wine <https://wiki.winehq.org/Importance_Of_Wine>
12 Il software di Microsoft è malware <https://www.gnu.org/proprietary/malware-microsoft.it.html>
13 OpenGL <https://www.opengl.org/>
14 Vulkan <https://vulkan.org/>
15 DXVK releases <https://github.com/doitsujin/dxvk/releases>
16 DXVK build instructions <https://github.com/doitsujin/dxvk#build-instructions>
17 winecfg <https://wiki.winehq.org/Winecfg>
18 D8VK <https://github.com/AlpyneDreams/d8vk>
19 nGlide <http://www.zeus-software.com/downloads/nglide>
20 dgVoodoo2 <http://dege.freeweb.hu/dgVoodoo2/>
21 Lutris <https://lutris.net/>
22 Wine AppDB The Sims 3 <https://appdb.winehq.org/objectManager.php?sClass=version&iId=16664>
23 An interview with the developer of DXVK <https://www.gamingonlinux.com/2018/09/an-interview-with-the-developer-of-dxvk-part-of-what-makes-valves-steam-play-tick/>
24 DXVK initial release <https://github.com/doitsujin/dxvk/releases/tag/v0.20>
25 Implement Direct3D 8 Frontend <https://github.com/doitsujin/dxvk/pull/3411>
26 Glide for 3dfx hardware <https://sourceforge.net/projects/glide/>