Por qué lo comprobamos siempre en ocho entornos Linux

En Linux, decir que algo «funciona» no es suficiente.

Incluso dentro de Ubuntu, las bibliotecas del sistema y los toolkits cambian según la versión. La forma de mostrar la interfaz se divide entre X11 y Wayland, y para introducir texto en coreano se utiliza ibus o fcitx5. Si añadimos además el método de instalación, las combinaciones que debemos comprobar aumentan rápidamente.

Que se haya ejecutado en el ordenador de un desarrollador significa que solo se ha comprobado una de las innumerables combinaciones posibles.

Por eso creamos un pequeño laboratorio dentro del repositorio. Iniciamos una máquina virtual real para cada entorno y repetimos las mismas pruebas. Reunimos los resultados en una sola tabla.

Lo que comprueba la tabla es sencillo.

¿Se inicia la aplicación? ¿Se puede escribir en coreano?

Nos adelantamos a experimentar los primeros treinta segundos que vivirá el usuario después de instalar la aplicación.

Convertimos cada entorno en un archivo

El laboratorio utiliza máquinas virtuales KVM en lugar de contenedores. Esto se debe a que con contenedores resulta difícil reproducir correctamente una sesión de escritorio real y el demonio del método de entrada.

Descargamos la imagen en la nube de la distribución y la preparamos con cloud-init. Creamos el disco como una superposición sobre la imagen original. Si surge un problema, podemos desecharlo y empezar de nuevo.

Cada entorno se declara en un solo archivo. El archivo contiene la distribución, la imagen, la sesión, el método de entrada y los paquetes que se instalarán. Si queremos comprobar una nueva combinación, basta con añadir un archivo.

El método de entrada varía según la sesión. En X11 usamos xdotool y en Wayland usamos ydotool. Como Wayland no dispone de una lista de ventanas, mostramos la aplicación a pantalla completa en un compositor de quiosco. Así podemos introducir texto siempre en la misma posición.

Compilamos la aplicación una sola vez en el host. Después copiamos el mismo binario sin modificar en todas las máquinas virtuales.

Si volviéramos a compilarlo en cada entorno, distintos compiladores y bibliotecas se mezclarían en los resultados. Cuando algo fallara, sería difícil encontrar la causa. Ante todo, el archivo que recibe el usuario y el que comprueba el laboratorio deben ser el mismo.

La máquina virtual comprueba y el host registra

Dentro de la máquina virtual comprobamos tres cosas.

Comprobamos si el binario se ejecuta, si aparece la ventana y si al escribir dkssud aparece 안녕.

Cada prueba deja una línea de JSON. El host reúne los resultados, los guarda en un archivo y los convierte en una tabla. Los resultados medidos permanecen en el repositorio para compararlos con las pruebas siguientes.

La forma de comprobar la entrada de texto en coreano varía según la compilación. En las compilaciones de desarrollo podemos comprobar directamente los caracteres que se están componiendo. Las compilaciones reales para distribución no tienen esa función. En su lugar, pulsamos Enter, guardamos el archivo y después leemos el contenido escrito en el disco.

Durante este proceso aprendimos una cosa. Lo que determinaba el método de comprobación no era el método de instalación, sino el tipo de compilación de la aplicación.

La primera tabla nos reveló dos cosas

En Ubuntu 22.04, la aplicación compilada con el toolkit del sistema no se abría. Esto se debía a que no podía encontrar un símbolo disponible únicamente en las versiones más recientes de libadwaita.

Por el contrario, también comprobamos por primera vez que, con la combinación de Wayland e ibus, se podía introducir texto en coreano correctamente.

A partir de este resultado decidimos incluir el mismo toolkit en todos los métodos de instalación. La tabla actual de ocho filas es un mecanismo de seguridad que comprueba que esa decisión no vuelva a romperse.

También hubo problemas que solo eran visibles en entornos reales. A diferencia de Ubuntu para escritorio, las imágenes en la nube no incluían el módulo de entrada de GTK4 ni un modo de entrada inicial. Tuvimos que instalarlos por separado durante el proceso de aprovisionamiento.

El módulo de ibus tenía que coincidir con la versión del demonio instalada en la distribución. El modo de utilizar las herramientas de entrada también variaba entre distribuciones. Tuvimos que dividir los scripts de prueba para adaptarlos a cada entorno.

Para ahorrar memoria en el host, ejecutamos como máximo dos máquinas virtuales al mismo tiempo. En cuanto recibimos los resultados de una máquina virtual, la apagamos.

Todos eran problemas difíciles de detectar leyendo únicamente el código. El mismo código producía resultados diferentes según el entorno. Por eso necesitábamos la tabla.

La tabla no promete rendimiento

La tabla también registra el tiempo transcurrido hasta que aparece la primera pantalla y el uso de memoria. Sin embargo, no los utilizamos como indicadores de rendimiento.

La máquina virtual dibuja la pantalla por software, sin GPU, y realiza una única medición justo después de arrancar. Los valores pueden variar en cada ejecución. Los criterios de rendimiento se determinan mediante la mediana de tres mediciones realizadas en un host que sí dispone de una GPU real.

Lo que hay que mirar en esta tabla no son los milisegundos, sino las marcas de verificación.

Los entornos que no hemos podido comprobar se dejan en blanco. Fedora y Debian, una sesión real de GNOME y los cuadros de diálogo de portales, como el selector de archivos, aún no aparecen en la tabla.

No rellenamos las casillas que no hemos comprobado diciendo que «probablemente funcionará».

No podemos decidir qué entorno elegirá el usuario. Lo que sí podemos hacer es entrar primero en ese entorno e intentar iniciar la aplicación.