Perché verifichiamo ogni volta su otto ambienti Linux

Su Linux non basta dire che qualcosa «funziona».

Anche a parità di Ubuntu, le librerie di sistema e i toolkit cambiano a seconda della versione. Il sistema di visualizzazione si divide tra X11 e Wayland, mentre per l’input coreano si usano ibus o fcitx5. Se si aggiunge anche la modalità di installazione, le combinazioni da verificare aumentano rapidamente.

Il fatto che abbia funzionato sul computer di uno sviluppatore significa che è stata verificata soltanto una delle tante combinazioni.

Per questo ho creato un piccolo laboratorio all’interno del repository. Per ogni ambiente avvio una macchina virtuale reale e ripeto gli stessi controlli. Raccolgo i risultati in un’unica tabella.

Ciò che la tabella verifica è semplice.

L’app si avvia? È possibile inserire testo coreano?

Viviamo in anticipo i primi trenta secondi che l’utente sperimenterà dopo aver installato l’app.

Ho trasformato ogni ambiente in un singolo file

Il laboratorio usa macchine virtuali KVM anziché container. Questo perché con i container è difficile riprodurre correttamente una vera sessione desktop e il demone del metodo di input.

Scarico l’immagine cloud della distribuzione e la preparo con cloud-init. Il disco viene creato come overlay sopra l’immagine originale. Se si verifica un problema, posso eliminarlo e ricominciare.

Ogni ambiente viene dichiarato in un singolo file. Il file contiene la distribuzione, l’immagine, la sessione, il metodo di input e i pacchetti da installare. Se si vuole verificare una nuova combinazione, basta aggiungere un solo file.

Il metodo di immissione cambia a seconda della sessione. Su X11 uso xdotool, mentre su Wayland uso ydotool. Poiché Wayland non dispone di un elenco delle finestre, avvio l’app a schermo intero in un compositor kiosk. In questo modo posso inserire il testo ogni volta nella stessa posizione.

L’app viene compilata una sola volta sull’host. Quindi copio lo stesso binario in tutte le macchine virtuali.

Se la ricompilassi in ogni ambiente, compilatori e librerie differenti si mescolerebbero nei risultati. In caso di errore, diventerebbe difficile individuarne la causa. Soprattutto, il file ricevuto dall’utente e quello controllato dal laboratorio devono essere identici.

La macchina virtuale controlla, l’host registra

All’interno della macchina virtuale verifico tre cose.

Controllo se il binario viene eseguito, se la finestra si apre e se, digitando dkssud, appare 안녕.

Ogni controllo produce una riga JSON. L’host raccoglie i risultati, li salva in un file e li trasforma in una tabella. I risultati misurati restano nel repository per essere confrontati con quelli del controllo successivo.

Il metodo di verifica dell’input coreano cambia a seconda della build. Nella build di sviluppo è possibile controllare immediatamente i caratteri mentre vengono composti. La build destinata alla distribuzione effettiva non dispone di questa funzione. Al suo posto, premo Invio, salvo il file e poi leggo il contenuto scritto sul disco.

Da questo processo ho imparato una cosa. A determinare il metodo di verifica non era la modalità di installazione, ma il tipo di build dell’app.

La prima tabella mi ha rivelato due cose

Su Ubuntu 22.04, l’app compilata con il toolkit di sistema non si apriva. Il motivo era che non riusciva a trovare un simbolo presente soltanto nelle versioni più recenti di libadwaita.

Al contrario, ho anche verificato per la prima volta che, con la combinazione Wayland e ibus, l’input coreano funzionava correttamente.

Sulla base di questi risultati ho deciso di includere lo stesso toolkit in tutte le modalità di installazione. L’attuale tabella di otto righe è una misura di sicurezza che verifica che quella decisione non venga nuovamente compromessa.

C’erano anche problemi visibili soltanto negli ambienti reali. A differenza di Ubuntu Desktop, le immagini cloud non disponevano del modulo di input GTK4 né della modalità di input iniziale. È stato necessario installarli separatamente durante il provisioning.

Il modulo ibus doveva essere compatibile con la versione del demone installata nella distribuzione. Anche il modo di usare gli strumenti di input variava da una distribuzione all’altra. Ho dovuto suddividere gli script di verifica in base all’ambiente.

Per risparmiare la memoria dell’host, eseguo contemporaneamente al massimo due macchine virtuali. Una macchina virtuale viene arrestata non appena ricevo il suo risultato.

Erano tutti problemi difficili da individuare leggendo soltanto il codice. Lo stesso codice produceva risultati diversi a seconda dell’ambiente. Per questo serviva la tabella.

La tabella non promette prestazioni

La tabella registra anche il tempo impiegato per mostrare la prima schermata e l’utilizzo della memoria. Tuttavia, non uso questi dati come indicatori delle prestazioni.

La macchina virtuale disegna lo schermo via software, senza GPU, e la misurazione viene effettuata una sola volta subito dopo l’avvio. I valori possono cambiare a ogni esecuzione. I criteri prestazionali vengono stabiliti usando la mediana di tre misurazioni effettuate su un host dotato di una vera GPU.

In questa tabella bisogna guardare i segni di spunta, non i millisecondi.

Gli ambienti che non ho potuto verificare restano vuoti. Fedora e Debian, le vere sessioni GNOME e le finestre di dialogo dei portali, come quella per la selezione dei file, non sono ancora presenti nella tabella.

Non riempio le caselle non verificate dicendo che «probabilmente funzioneranno».

Non possiamo decidere quale ambiente sceglierà l’utente. Quello che possiamo fare è entrare per primi in quell’ambiente e provare ad avviare l’app.