1 14/10/2026 10 min

Provare GNOME 40 su Ubuntu 20.04 in una macchina virtuale è il modo giusto per capire se il salto vale la pena senza toccare il sistema principale. La scelta della VM conta più della distro guest: se vuoi valutare davvero l’esperienza, devi poter misurare fluidità, integrazione con il display, reattività del mouse, accelerazione grafica e stabilità delle estensioni. Il punto non è “far partire GNOME 40”, ma farlo partire in condizioni abbastanza realistiche da non trarre conclusioni sbagliate.

Ubuntu 20.04 nasce con GNOME 3.36, quindi GNOME 40 non è il desktop nativo di quella release. In pratica hai due strade: usare una distro più recente in VM per confrontare l’esperienza, oppure mantenere Ubuntu 20.04 come base e installare un ambiente GNOME aggiornato tramite repository o PPA. Per una prova pulita, la seconda opzione è spesso la più utile, perché separa il comportamento del desktop dal resto dello stack. Se invece vuoi evitare di alterare il guest, puoi usare un live ISO o una macchina virtuale dedicata a test rapidi.

Perché la VM è il banco prova corretto

GNOME 40 ha cambiato in modo sensibile la navigazione della shell, il workspaces overview e la gestione dei touchpad. Su una VM mal configurata, però, il test viene falsato da problemi banali: driver video generici, RAM insufficiente, compositing non accelerato, integrazione clipboard assente, risoluzione scomoda. Prima di parlare di “desktop pesante” bisogna escludere questi fattori. In altre parole, la VM deve essere abbastanza vicina a un host reale da non introdurre colli di bottiglia artificiali, ma abbastanza isolata da consentire rollback immediato.

La metrica che interessa davvero non è il benchmark sintetico fine a sé stesso, ma la latenza percepita: tempo tra input e risposta dell’interfaccia, fluidità dello switch tra overview e applicazioni, stabilità del rendering a schermo intero, e assenza di tearing o freeze durante il ridimensionamento. Se vuoi un parametro semplice da seguire, osserva la reattività nei primi 60 secondi dopo il login e durante il passaggio da finestra a overview. È lì che emergono i problemi di integrazione.

Scelta dell’hypervisor: VirtualBox, KVM/QEMU o VMware

Per una prova seria, KVM/QEMU con virt-manager è spesso la scelta migliore su Linux host, perché offre un’integrazione più pulita con virgl/Spice e in genere una resa grafica migliore rispetto alla virtualizzazione generica. VirtualBox va bene per test funzionali e per chi ha già un flusso consolidato, ma può mostrare più facilmente limiti sul rendering. VMware funziona bene, soprattutto su host desktop già standardizzati, ma la logica di setup cambia e il valore aggiunto dipende molto dal sistema ospitante.

Se l’obiettivo è capire come GNOME 40 si comporta su Ubuntu 20.04, io partirei da KVM se disponibile. Il motivo è pratico: snapshot facili, rete flessibile, supporto decente al passthrough grafico virtuale e minore attrito nel tornare indietro. Se il tuo host non supporta KVM, VirtualBox resta un’opzione valida, ma va configurata con più attenzione, soprattutto lato video e memoria.

Preparazione della VM: risorse minime sensate

Per evitare di attribuire a GNOME 40 lentezze che in realtà dipendono dalla VM, non scendere sotto certe soglie. Per un test credibile: 2 vCPU sono il minimo, 4 vCPU sono meglio; 4 GB di RAM sono il minimo, 6 o 8 GB se vuoi aprire più applicazioni; disco virtuale da almeno 25 GB; accelerazione grafica attiva se l’hypervisor la supporta. Se fai una prova con 1 vCPU e 2 GB di RAM, stai misurando la sofferenza della macchina, non il desktop.

Su KVM, una configurazione iniziale ragionevole può essere questa:

virt-install \ --name ubuntu2004-gnome40 \ --memory 6144 \ --vcpus 4 \ --disk size=30,bus=virtio \ --cdrom /var/lib/libvirt/boot/ubuntu-20.04.6-desktop-amd64.iso \ --os-variant ubuntu20.04 \ --graphics spice \ --video virtio \ --network network=default \ --console pty,target_type=serial

Quel settaggio non è “universale”, ma è un buon punto di partenza. Se noti artefatti video o rendering instabile, il primo controllo è il tipo di scheda virtuale e la presenza dell’accelerazione. Se invece la VM si avvia ma GNOME è lento nel login, il problema è più spesso lato risorse o servizi del guest che lato compositing.

Installare Ubuntu 20.04 e preparare il sistema prima del desktop

Dopo l’installazione di Ubuntu 20.04, conviene aggiornare tutto il base system prima di toccare il desktop. In una VM appena creata, la sequenza pulita è: aggiornamento pacchetti, verifica kernel, installazione strumenti guest e solo dopo interventi sul desktop environment. Così riduci il rumore diagnostico. Se qualcosa va storto, sai se il problema nasce dal sistema base o dal layer grafico.

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y spice-vdagent qemu-guest-agent open-vm-tools-desktop

Non installare tutto alla cieca su qualunque hypervisor: i pacchetti utility dipendono dalla piattaforma. Su KVM/Spice, `spice-vdagent` è molto utile per clipboard, resize dinamico e integrazione mouse. Su VMware ha senso `open-vm-tools-desktop`. L’idea è la stessa: migliorare l’esperienza nella VM senza alterare il desktop in modo invasivo.

Prima di andare oltre, fai un checkpoint o snapshot della VM. È il rollback più semplice e più efficace. Se poi la sperimentazione con GNOME 40 non ti convince, torni allo stato precedente in pochi secondi. Questo è importante soprattutto se decidi di aggiungere PPA o pacchetti non standard.

Come ottenere GNOME 40 su Ubuntu 20.04

Qui bisogna essere precisi: Ubuntu 20.04 non offre GNOME 40 come percorso ufficiale standard. Per questo motivo, la strada più pulita dipende da quanto vuoi sporcare il sistema. Se ti basta vedere GNOME 40 in azione, una VM con una release più recente è la scelta meno rischiosa. Se invece vuoi restare su 20.04, devi passare da repository terzi o da un aggiornamento del desktop che può impattare dipendenze e stabilità.

Per una prova controllata, il criterio è semplice: prima verifica quali pacchetti sono disponibili nel tuo repository attuale, poi valuta l’eventuale PPA o il backport. Non partire dall’installazione diretta senza sapere cosa stai cambiando. Un controllo minimo è questo:

apt-cache policy gnome-shell
apt-cache policy mutter
apt-cache policy ubuntu-desktop

Se i pacchetti mostrano solo versioni della serie 3.36, è normale. A quel punto hai due opzioni: installare una sessione GNOME più recente da un repository dedicato, oppure usare una VM con Ubuntu 21.04 o successivo per il confronto. In molti casi la seconda opzione è più onesta dal punto di vista tecnico, perché evita di mescolare il test del desktop con la manutenzione di una base LTS non pensata per quel ramo GNOME.

Quando aggiungi un PPA, annota sempre il motivo e tieni pronto il rollback. Un controllo utile prima di procedere è salvare la lista dei pacchetti installati e la configurazione del desktop:

dpkg -l | grep -E 'gnome-shell|mutter|ubuntu-desktop' > /root/pre-gnome40-packages.txt
cp -a /etc/apt/sources.list.d /root/apt-sources-backup

Primo avvio: cosa controllare davvero

Al primo login, non aprire subito dieci applicazioni. Fai invece una sequenza breve e ripetibile: verifica la shell, apri Activities, passa tra workspace, ridimensiona una finestra, testa clipboard, riavvia sessione. Questo ti dà un quadro molto più utile di un’impressione generica. Se il puntatore è scattoso o il menu si apre con ritardo, non hai ancora un ambiente affidabile per lavorare.

Per raccogliere indizi, controlla i log utente e di sessione. I punti più utili sono questi:

journalctl --user -b -p warning..alert
journalctl -b -p warning..alert
cat ~/.local/share/xorg/Xorg.0.log 2>/dev/null

Se la sessione usa Wayland, Xorg potrebbe non essere presente; è normale. In quel caso concentrati su journal e sui messaggi di GNOME Shell. Errori ripetuti di mutter o crash del compositor sono un segnale più forte di qualsiasi impressione visiva. Se invece tutto parte ma l’UI è lenta, guarda prima i driver video virtuali e il consumo CPU del processo `gnome-shell`.

Estensioni, tema e compatibilità: il punto che rompe più spesso

GNOME 40 ha cambiato parecchio la shell, e molte estensioni nate per versioni precedenti non funzionano come ti aspetti. Se stai provando una configurazione che usi già su altre macchine, non dare per scontato che il set di estensioni sia compatibile. In una VM di test, conviene partire con un profilo pulito e aggiungere solo quello che serve davvero.

Un errore comune è giudicare GNOME 40 dopo aver installato estensioni non allineate. Se la shell si comporta male, disabilita tutto e verifica il comportamento base. Da terminale puoi fare un controllo rapido con:

gnome-extensions list
gnome-extensions disable <uuid-estensione>

Se il problema sparisce, il desktop non è il colpevole principale: lo è l’estensione. In quel caso la correzione è selettiva, non globale. Aggiorna l’estensione, sostituiscila o lasciala fuori dalla VM di prova. Se invece il problema resta anche senza estensioni, allora il tema è più probabilmente grafico o legato alla virtualizzazione.

Misurare la differenza tra “funziona” e “si usa bene”

Per evitare giudizi vaghi, prendi due o tre indicatori semplici. Il primo è il tempo di login fino alla comparsa del desktop pronto. Il secondo è la reattività durante il cambio workspace. Il terzo è il carico medio della CPU nei primi minuti di utilizzo. Non serve un laboratorio complesso: basta confrontare prima e dopo ogni modifica importante, per esempio l’attivazione del driver virtuale o l’installazione di un pacchetto GNOME specifico.

Un controllo utile è osservare i processi più pesanti subito dopo il login:

top -o %CPU
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head

Se `gnome-shell` resta alto in CPU per molto tempo, il sospetto va al rendering o a un’estensione difettosa. Se invece il carico sale solo quando muovi finestre o apri overview, può essere normale in VM, ma deve restare entro limiti ragionevoli. Se l’host ha risorse limitate, il collo di bottiglia può essere fuori dal guest: saturazione CPU, swap attiva o storage lento sul sistema ospitante.

Rollback pulito: come tornare indietro senza lasciare residui

Se la prova non ti convince, il rollback deve essere semplice. La via più rapida è ripristinare lo snapshot della VM. Se hai usato un PPA o un repository terzo, rimuovilo prima del restore o subito dopo, in base a come gestisci la snapshot. L’obiettivo è evitare di lasciare il guest in uno stato ambiguo, mezzo aggiornato e mezzo no.

Per la parte pacchetti, puoi verificare cosa è stato installato o aggiornato con:

grep -E 'Install|Upgrade' /var/log/apt/history.log | tail -n 50

Se devi rimuovere un repository esterno, controlla prima i file in `

/etc/apt/sources.list.d/

e verifica quali pacchetti dipendono da quel repository. Non fare purge aggressivi senza sapere cosa stai togliendo. In una VM di test, il rollback migliore resta comunque lo snapshot: è più affidabile di qualsiasi rimozione manuale fatta a posteriori.

Quando conviene fermarsi e usare una distro più nuova

Se il tuo obiettivo è valutare GNOME 40 come desktop quotidiano, Ubuntu 20.04 non è sempre la base giusta per forzare il test. A quel punto conviene usare direttamente una release che lo supporti in modo naturale. Il vantaggio è tecnico, non ideologico: meno pacchetti fuori linea, meno backport, meno possibilità di rompere dipendenze e più tempo speso a osservare il comportamento reale della shell.

Se invece vuoi capire come si comporta un ambiente LTS con un desktop più nuovo, allora il test ha senso proprio perché non è standard. Ma va letto per quello che è: una prova di compatibilità, non un setup da promuovere in produzione senza una validazione più ampia. In contesti desktop aziendali o in postazioni condivise, la compatibilità con estensioni, policy e tool di supporto pesa almeno quanto la piacevolezza visiva.

Checklist finale per un test serio

Se vuoi chiudere il giro senza ambiguità, la sequenza minima è questa:

  1. Creare una VM con risorse adeguate e snapshot iniziale.
  2. Installare Ubuntu 20.04 e aggiornare il base system.
  3. Abilitare gli strumenti guest corretti per l’hypervisor scelto.
  4. Verificare la disponibilità reale di GNOME 40 o decidere se passare a una release più adatta.
  5. Testare sessione, shell, overview, clipboard e ridimensionamento finestre.
  6. Controllare log e carichi se compaiono rallentamenti o crash.
  7. Ripristinare lo snapshot se il test non è soddisfacente.

Il punto finale è questo: una VM ben preparata ti dice molto di più di un’installazione affrettata. GNOME 40 può sembrare leggero o pesante a seconda del contesto, ma in laboratorio devi separare il desktop dall’infrastruttura che lo ospita. Solo così il risultato ha valore tecnico e non resta un’impressione casuale.