1 06/05/2026 10 min

Installare MATE su Ubuntu 20.04 in WSL ha senso solo se ti serve un ambiente grafico Linux completo per test, tool legacy o sessioni occasionali. Non è la stessa esperienza di un desktop installato su una macchina Linux reale: in WSL il kernel è condiviso con Windows, l’avvio è pensato per processi testuali e la parte grafica richiede un server X esterno oppure una soluzione alternativa già pronta. Se parti con questa aspettativa, eviti il classico errore di voler trasformare WSL in una workstation tradizionale.

Il punto chiave è questo: WSL 1 e WSL 2 non gestiscono un display server Linux in modo “desktop” come farebbe una distro installata su hardware nativo. MATE è un ambiente desktop completo, quindi ha bisogno di componenti che in WSL non arrivano da soli: X11, un window manager, sessione grafica, font, temi e spesso anche un backend audio se vuoi qualcosa di più del semplice rendering delle finestre. Il risultato finale è utilizzabile, ma va progettato come una composizione di pezzi, non come un’installazione monolitica.

Scelta architetturale: X server esterno, non “desktop completo” dentro WSL

Su Ubuntu 20.04 in WSL la strada più stabile è questa: installi MATE nel guest Linux, ma fai uscire la GUI verso un server X su Windows. In pratica, Linux fornisce applicazioni, librerie e sessione grafica; Windows ospita il display. È una soluzione molto più prevedibile di tentare VNC o di forzare un login manager completo dentro WSL, perché riduce i punti di rottura e ti lascia debug chiaro: se la finestra non appare, il problema è quasi sempre X server, variabile DISPLAY, librerie grafiche o avvio della sessione.

Se stai usando Windows 11 con WSLg, il quadro cambia: alcune app Linux possono apparire senza server X manuale. Però MATE come desktop intero resta un caso meno lineare rispetto a una singola app GUI. Su Windows 10 o su configurazioni senza WSLg conviene dare per scontato un X server esterno, per esempio VcXsrv o X410. Qui sotto imposto la procedura in modo compatibile con il caso più comune: Ubuntu 20.04 su WSL 2 e X server su Windows.

Prerequisiti minimi e verifica della base WSL

Prima di installare pacchetti grafici, verifica che la distribuzione sia davvero Ubuntu 20.04 e che tu stia usando WSL 2. WSL 1 può funzionare per alcune applicazioni, ma con GUI e rete locale il comportamento di WSL 2 è in genere più prevedibile.

Dal lato Windows, apri PowerShell e controlla lo stato delle distro:

wsl -l -v

Ti aspetti qualcosa come:

NAME            STATE           VERSION
Ubuntu-20.04    Running         2

Se la versione è 1, puoi comunque procedere con cautela, ma se hai margine operativo conviene convertire la distro:

wsl --set-version Ubuntu-20.04 2

Questa operazione non è distruttiva per i dati, ma va considerata un change controllato: il blast radius è la singola distro. Se qualcosa va storto, il rollback è il ritorno a WSL 1 con lo stesso comando e versione appropriata, oppure il ripristino da esportazione se hai già una copia.

Installare i pacchetti necessari su Ubuntu 20.04

Dentro Ubuntu aggiorna l’indice e installa un set minimale per una sessione MATE funzionante. Non serve tirarsi dietro il mondo intero: meglio partire con il minimo indispensabile e aggiungere solo se mancano componenti specifici.

sudo apt update
sudo apt install -y mate-desktop-environment-core mate-terminal dbus-x11 x11-apps

Se vuoi un ambiente più completo, puoi estendere con il meta-pacchetto MATE classico:

sudo apt install -y mate-desktop-environment

Il pacchetto dbus-x11 è importante perché molte sessioni grafiche si aspettano un bus D-Bus attivo in un contesto desktop. Senza quello, MATE può aprirsi a metà, restare con schermata vuota o fallire in avvio con errori poco leggibili. x11-apps ti serve soprattutto per test rapidi, ad esempio xclock o xeyes, utili per separare il problema “MATE non parte” dal problema “X server non riceve finestre”.

Configurare il display: la parte che fa davvero la differenza

Il passaggio critico è pubblicare il display verso Windows. Se usi un X server come VcXsrv, devi far partire il server sul lato Windows e poi esportare la variabile DISPLAY nella shell WSL. Nella pratica, il display da usare è spesso l’IP del gateway della rete WSL oppure, in alcuni setup, l’indirizzo del host Windows raggiungibile dalla distro. Il sintomo più comune di errore qui è semplice: i processi partono, ma non compare nessuna finestra.

Dal lato Linux, prova una configurazione temporanea nella shell corrente:

export DISPLAY=$(grep nameserver /etc/resolv.conf | awk '{print $2}'):0
export LIBGL_ALWAYS_INDIRECT=1

La prima riga prende l’IP del nameserver dalla configurazione di rete generata da WSL, che spesso coincide con il gateway utile per raggiungere Windows. La seconda forza il rendering OpenGL indiretto, spesso utile in ambienti X forwarding e in alcune combinazioni con driver grafici. Non è una bacchetta magica, ma evita un numero di errori banali nelle prime prove.

Verifica subito con un’app X piccola, non con MATE intero:

xclock

Se xclock apre una finestra, la strada grafica di base funziona. Se non parte, non ha senso insistere con MATE: il problema è il trasporto grafico, non il desktop environment.

Avviare una sessione MATE senza display manager

In WSL non conviene inseguire un display manager classico come farebbe una macchina desktop Linux. lightdm o simili possono funzionare in casi particolari, ma aumentano la complessità e introducono un servizio in più da tenere in piedi. La soluzione più pulita è avviare direttamente la sessione MATE con dbus-run-session o con mate-session se l’ambiente è già pronto.

dbus-run-session mate-session

Se vuoi un test meno impegnativo, apri prima un terminale MATE:

mate-terminal

Se il terminale si apre, il windowing di base è funzionante. Se parte ma non riceve focus o mostra caratteri mancanti, il problema spesso è lato font, locale o integrazione con il server X, non il desktop in sé.

Rendere persistente la configurazione

Se ogni volta devi esportare DISPLAY a mano, il setup diventa fragile. La soluzione pratica è aggiungere la logica al profilo della shell, ma senza sporcare eccessivamente il file globale. In genere conviene usare ~/.bashrc o uno script dedicato, ad esempio ~/.wsl-gui.sh, richiamato solo nelle sessioni in cui vuoi il desktop.

# ~/.wsl-gui.sh
export DISPLAY=$(grep nameserver /etc/resolv.conf | awk '{print $2}'):0
export LIBGL_ALWAYS_INDIRECT=1
export XDG_RUNTIME_DIR=/tmp/runtime-$USER
mkdir -p "$XDG_RUNTIME_DIR"
chmod 700 "$XDG_RUNTIME_DIR"

Questo snippet non è un requisito assoluto, ma risolve due problemi frequenti: variabili d’ambiente mancanti e runtime directory non presente. La XDG_RUNTIME_DIR è utile perché alcune applicazioni grafiche e componenti desktop si aspettano un contesto coerente per socket e sessione. In WSL, soprattutto se lanci GUI da una shell appena aperta, questa parte può fare la differenza tra una sessione che si avvia e una che si ferma senza messaggi chiari.

Se vuoi essere più ordinato, crea un alias per il lancio:

echo 'alias start-mate="source ~/.wsl-gui.sh && dbus-run-session mate-session"' >> ~/.bashrc
source ~/.bashrc

Problemi tipici e come leggerli senza perdere tempo

Il primo errore logico è credere che MATE “non funzioni” quando in realtà manca solo il display. Se ottieni messaggi tipo cannot open display, stai lavorando sul layer sbagliato: non è un bug di MATE, è un problema di connessione verso X server. In quel caso la verifica minima è sempre la stessa: xclock o xeyes dal lato WSL e controllo del firewall/consenso sul lato Windows.

Il secondo errore è il bus D-Bus. Se la sessione parte ma alcune componenti non si caricano, controlla l’avvio con dbus-run-session. Un desktop moderno senza bus è come un sistema con metà servizi disattivati: magari vedi una finestra, ma i menu, le notifiche o il pannello possono comportarsi in modo anomalo.

Il terzo errore è il mismatch tra WSL 2 e l’accesso alla rete. A volte il display raggiungibile oggi non è quello di domani, soprattutto dopo restart di Windows o aggiornamenti del subsystem. Se la variabile DISPLAY è statica e dipende da un IP che cambia, ti conviene renderla dinamica o usare una soluzione che non richieda l’instradamento manuale ogni volta.

Verifiche utili quando la sessione resta nera o si chiude subito

Quando la finestra non arriva o si chiude immediatamente, non partire dall’idea che il desktop sia corrotto. Fai questa sequenza minima:

  1. Controlla che il server X su Windows sia in esecuzione e accetti connessioni.
  2. Verifica echo $DISPLAY e che punti all’host giusto.
  3. Prova xclock o xterm per isolare il problema.
  4. Lancia dbus-run-session mate-session da una shell pulita.
  5. Se fallisce ancora, guarda l’output immediato e gli ultimi messaggi della sessione, non log generici a caso.

Se vuoi un controllo più mirato, cerca nel journal utente o nei log della sessione, quando presenti. In WSL la disponibilità dei log dipende molto da come hai avviato la sessione e da quali componenti hai installato. Non dare per scontato di avere un /var/log/Xorg.0.log come su una distro desktop completa: spesso lì non c’è nulla di utile, perché il display server non è locale a Linux.

Prestazioni e limiti reali: cosa aspettarsi e cosa no

Su WSL il collo di bottiglia non è quasi mai la CPU pura; più spesso sono latenza grafica, integrazione finestra e round-trip tra subsystem Linux e host Windows. Questo significa che MATE può sembrare meno fluido di quanto ti aspetti, specialmente se apri più app grafiche insieme o se il server X è configurato in modo conservativo. La metrica sensata da osservare non è “è bello come un desktop nativo”, ma qualcosa di più concreto: tempo di apertura finestra, reattività del pannello e assenza di crash della sessione.

Se noti lentezza, verifica prima l’overhead del rendering e poi le risorse di WSL. Un host con poca RAM o con disco lento può rendere l’esperienza molto meno gradevole, anche se il setup è corretto. In quel caso il miglioramento più efficace non è cambiare desktop environment, ma ridurre il numero di app grafiche attive, evitare compositing pesante e tenere il sistema pulito da servizi inutili.

Quando ha senso usare MATE in WSL e quando no

Ha senso se devi usare tool Linux con GUI in modo saltuario, se lavori su ambienti di test o se vuoi un desktop leggero per applicazioni specifiche. Ha meno senso se cerchi una workstation Linux completa, con login manager, integrazione audio/video perfetta e comportamento identico a una installazione fisica. In quel caso conviene una VM vera o un’installazione Linux dedicata.

Un buon criterio pratico è questo: se il tuo obiettivo è aprire alcune finestre Linux da Windows, WSL con MATE può stare in piedi. Se invece vuoi vivere dentro MATE tutto il giorno, il subsystem è il posto sbagliato. Non è una bocciatura tecnica, è solo il confine corretto del modello operativo.

Procedura sintetica consigliata

Se vuoi una traccia rapida e ripetibile, questa è la sequenza che userei io in un ambiente pulito:

  1. Verifica che la distro sia in WSL 2 con wsl -l -v.
  2. Installa un server X su Windows e avvialo.
  3. In Ubuntu installa mate-desktop-environment-core, dbus-x11 e x11-apps.
  4. Esporta DISPLAY in modo dinamico.
  5. Testa con xclock.
  6. Avvia dbus-run-session mate-session.
  7. Solo se necessario, aggiungi componenti MATE extra o aggiustamenti di runtime.

Questa sequenza tiene basso il raggio d’azione delle modifiche e ti dà un punto di fallimento chiaro per ogni layer: subsystem, rete verso Windows, X server, sessione D-Bus, desktop MATE. È il modo più rapido per non trasformare una semplice GUI in una diagnosi infinita.

Assunzione operativa: Ubuntu 20.04 è già installato in WSL 2 e hai accesso amministrativo nella distro; il server X viene eseguito su Windows con policy locali che ne consentono l’uso in LAN loopback o sul canale previsto dal software scelto.