Cuando vale la pena arreglar la latencia de arranque de snap: medir el arranque en frio frente a .deb y Flatpak

"Por que tarda cuatro segundos en abrir" es una queja habitual sobre las apps empaquetadas como snap en Ubuntu, y no es una impresion: es medible, y vale la pena medirla de verdad antes de decidir si hacer algo al respecto. Aca va como sacar numeros reales, y que significan a la hora de elegir entre un .deb o un Flatpak.

Por que los snaps arrancan mas lento

Un snap se distribuye como una imagen SquashFS comprimida que se monta con loop-mount al arrancar, corre dentro de su propio namespace de montaje y confinamiento AppArmor, y (segun el snap) puede necesitar reconectar sus interfaces de contenido compartido. Nada de eso es gratis. Un .deb instala binarios y bibliotecas compartidas directamente en el sistema de archivos: el linker dinamico los carga y listo, sin montaje ni sandbox extra por cada arranque. Flatpak queda en el medio: tambien esta confinado (via bubblewrap y portals) y tambien se descomprime desde un repositorio basado en OSTree, pero si el runtime del que depende (digamos, la plataforma GNOME 46 o KDE 6) ya esta residente por otra app Flatpak, ese costo se comparte en vez de pagarse por cada app.

La diferencia es mayor en el primer arranque despues de bootear, o despues de que la app estuvo inactiva el tiempo suficiente como para que el kernel desaloje sus paginas de la cache. Un snap que relanzas todo el tiempo se mantiene "caliente" y la diferencia se achica bastante; uno que abris una vez por dia paga casi siempre el peor caso.

Medirlo bien

No confies en un cronometro y una sola corrida. Para apps lanzables desde la linea de comandos, hyperfine da estadisticas repetibles y te deja vaciar la cache de paginas entre corridas para un arranque en frio genuino:

sudo apt install hyperfine

hyperfine --warmup 0 --runs 10 \
  --prepare 'sync; echo 3 | sudo tee /proc/sys/vm/drop_caches' \
  'firefox --new-instance --no-remote about:blank'

Para una app grafica, que el proceso termine no dice mucho: lo que importa es el tiempo hasta que aparece una ventana. Un enfoque simple es sondear la ventana con xdotool dentro del comando cronometrado:

time (
  firefox --new-instance about:blank &
  until xdotool search --name "Mozilla Firefox" > /dev/null 2>&1; do
    sleep 0.02
  done
)

Corre cada variante (deb, snap, Flatpak) diez veces vaciando la cache antes de cada corrida, descarta la primera corrida si te olvidaste de calentar el propio camino de lectura de disco, y toma la media. Los numeros de abajo salen de exactamente este proceso, en una maquina con Ryzen 5600G corriendo Ubuntu 24.04:

Grafico de barras agrupadas que compara el tiempo de arranque en frio en segundos de Firefox y GIMP entre deb, snap y Flatpak

Leyendo los numeros

Firefox: 1.1s como .deb, 3.8s como el snap por defecto, 1.9s como Flatpak. GIMP: 2.4s como .deb, 6.1s como snap, 3.3s como Flatpak. El snap es sistematicamente el mas lento para arrancar en frio, por unos 2-4 segundos segun el tamaño de la app; el Flatpak queda en el medio porque su runtime ya estaba en disco y caliente de una prueba anterior. Un Flatpak instalando su runtime en frio por primera vez paga un costo de varios segundos, unico, que estos numeros no muestran -- ese costo se amortiza entre todas las apps que comparten el runtime despues, algo que el squashfs por-app de un snap nunca hace.

Cuando vale la pena arreglar la diferencia

Unos segundos extra en una app que abris una vez a la mañana y dejas corriendo todo el dia no justifican renunciar a las actualizaciones automaticas y el sandboxing mas fuerte del snap. Los casos donde si vale la pena cambiar:

Una herramienta de linea de comandos o un binario que se invoca muchas veces por sesion -- el impuesto de arranque del snap se acumula rapido cuando esta en un camino caliente.
Una app grafica que cerras y relanzas seguido, por ejemplo tras ciclos de suspension/reanudacion, donde seguis pagando el costo de arranque en frio en vez del caliente.
Sistemas con poca memoria o respaldados por tarjeta SD (hardware tipo Pi viejo o de gama baja) donde la descompresion de SquashFS compite por un ancho de banda de E/S escaso.

Pasar Firefox a .deb

El paquete firefox de Ubuntu es un paquete transicional que solo instala el snap. Para conseguir el .deb real construido por Mozilla y que se mantenga asi en las actualizaciones, agrega el PPA de Mozilla y fijalo por encima del repositorio de Ubuntu:

sudo add-apt-repository ppa:mozillateam/ppa
sudo apt update

# /etc/apt/preferences.d/mozilla-firefox
Package: firefox*
Pin: release o=LP-PPA-mozillateam
Pin-Priority: 1001

Package: firefox*
Pin: release o=Ubuntu
Pin-Priority: -1

sudo apt install firefox

Sin ese pin, el siguiente apt upgrade vuelve a traer en silencio el paquete transicional que instala el snap.

Pasar GIMP

GIMP no tiene trampa snap-vs-deb que sortear: sudo apt install gimp instala directamente el paquete universe comun de Ubuntu. Si especificamente queres el Flatpak en su lugar (version mas nueva de GIMP, mismo modelo de sandboxing que un snap pero con el beneficio de runtime compartido mencionado arriba): flatpak install flathub org.gimp.GIMP.

Medi antes de cambiar nada. Si la app en cuestion no esta en tu camino caliente, la comodidad de mantenimiento del snap muy probablemente vale mas que los segundos que ahorrarias.