Escritorio open source: las ideas para modernizarlo de una vez

Una actualización de paquete rompió mi entorno gráfico a las 23h de un martes, y pasé la noche en una TTY leyendo logs. Quien usa Linux en el escritorio desde hace algunos años probablemente tiene una historia parecida. LWN publicó un texto con ideas para modernizar el escritorio open source, y la pregunta de fondo es justamente esa: ¿cómo hacer un sistema que no se rompa cuando solo querías actualizar el navegador?

Te cuento qué se está discutiendo, por qué importa para quien desarrolla y qué cambia en la práctica.

Qué significa modernizar el escritorio open source

El modelo clásico de distro Linux tiene décadas. Un gestor de paquetes instala todo en un único sistema de archivos compartido. La app, la biblioteca del sistema y el kernel quedan en el mismo saco. Actualizar una cosa puede afectar a otra.

Ese modelo funcionó bien para servidores y para quien sabe arreglar su propio sistema. Para la persona común, e incluso para el dev que solo quiere trabajar, sale caro.

La conversación sobre modernización gira en torno a algunos ejes que ya llevan años en marcha:

• Sistema base inmutable: la raíz del sistema es de solo lectura y se actualiza como una imagen completa. ¿Algo falló? Vuelves a la versión anterior en el arranque.
• Apps aisladas: las aplicaciones corren en sandbox, con permisos explícitos, y vienen en un formato común entre distros, como Flatpak.
• Portales: en lugar de que la app lea el disco entero, le pide al sistema "abre un selector de archivos" y recibe solo lo que el usuario eligió.
• Wayland por defecto: X11 está saliendo de escena. GNOME ya quitó la sesión X11 por defecto y KDE también tiene fecha para dejar de mantenerla.

Nada de esto es nuevo por separado. Fedora Silverblue existe desde 2018. Flathub se volvió la tienda de facto de mucha gente. Lo que cambió es que las piezas por fin parecen listas para ser la forma normal de usar Linux, y no un experimento para entusiastas.

Por qué el modelo antiguo empezó a pesar

El problema central es el acoplamiento. Cuando cada app depende de las bibliotecas que empaquetó la distro, cada distro se vuelve un objetivo distinto. Quien mantiene una app de escritorio necesita probar en Ubuntu, Fedora, Arch, Debian estable y media docena más. En la práctica, nadie prueba, y el usuario descubre el bug.

Un ejemplo que cualquier dev de frontend entiende: imagina que el node_modules de tu proyecto se compartiera con todos los demás proyectos de la máquina. Actualizar React en un proyecto lo actualizaría en todos. Parece absurdo, ¿no? Pues más o menos así trata el escritorio Linux tradicional a las bibliotecas del sistema.

Un sistema que te da miedo actualizar ya está roto, solo que todavía no te avisó.

El segundo peso es la seguridad. En el modelo antiguo, cualquier app que instalas puede leer tu ~/.ssh, tus tokens en ~/.config y el historial del navegador. Después de tantos ataques a la cadena de suministro en paquetes de npm y PyPI, confiar a ciegas en cada binario de la máquina se volvió difícil de defender.

Qué cambia para quien desarrolla apps de escritorio

Si publicas una app para Linux, sea Electron, Tauri o nativa en GTK o Qt, la dirección es clara: empaquetar una vez, correr en cualquier distro, pedir permiso para lo que necesitas.

Un manifiesto Flatpak simple ya muestra el cambio de mentalidad:

app-id: dev.horvatti.MeuApp
runtime: org.freedesktop.Platform
runtime-version: '24.08'
sdk: org.freedesktop.Sdk
command: meu-app
finish-args:
  - --share=network
  - --socket=wayland
  - --socket=fallback-x11
  - --device=dri

Fíjate en finish-args. Declaras lo que la app necesita. Red, sí. Acceso al home entero, no. Si la app necesita abrir un archivo, usa el portal de selección de archivos, y el sistema entrega solo ese archivo.

En la práctica, esto cambia tres cosas en tu código:

1. Las rutas fijas dejan de funcionar. Ese fs.readFileSync(os.homedir() + '/Documentos/config.json') va a fallar dentro del sandbox. Usa el diálogo de archivos del framework, que en las versiones recientes de Electron y Tauri ya pasa por el portal.
2. Wayland deja de ser opcional. La captura de pantalla, los atajos globales y la posición de ventana funcionan de otra manera. Si tu app depende de "capturar la pantalla entera", necesita usar el portal de screencast.
3. La actualización pasa a ser responsabilidad del formato. Publicas en Flathub y la actualización le llega al usuario sin que escribas un auto-updater.

El tercer punto por sí solo ya ahorra trabajo. Quien ya escribió un updater para Electron sabe cuánto duele.

¿Un sistema inmutable sirve para quien programa?

Esta es la objeción que más escucho. "Necesito instalar compilador, base de datos, Docker, una versión específica de Node. Un sistema inmutable me va a bloquear."

La respuesta corta: no bloquea, pero cambia el lugar donde viven las cosas. El sistema base queda intacto y el entorno de desarrollo se va a un contenedor. Herramientas como Toolbx y Distrobox crean un contenedor con la distro que quieras, integrado con tu home y con la terminal.

distrobox create --name dev --image fedora:latest
distrobox enter dev
sudo dnf install postgresql nodejs

Dentro del contenedor haces el desorden que quieras. ¿Se rompió? Lo borras y creas otro en un minuto. El sistema que te da el escritorio sigue funcionando.

Uso una variante de esto desde hace un tiempo y la ganancia real es psicológica: dejé de tener miedo de probar cosas. Eso vale más de lo que parece. El costo existe: hay una curva de aprendizaje, algunas herramientas que tocan el hardware son molestas de configurar y el primer día es algo confuso. Pero ese costo se paga una sola vez.

Lo que todavía está mal resuelto

Sería deshonesto venderlo como una solución lista. Tiene puntos débiles concretos.

Permisos mal declarados. Muchas apps en Flathub piden --filesystem=home porque da menos trabajo que usar portales. Ahí el sandbox se vuelve decoración. El modelo solo protege si los mantenedores hacen su parte, y hoy muchos no la hacen.

Espacio en disco y duplicación. Cada runtime de Flatpak trae sus propias bibliotecas. La deduplicación ayuda, pero en una máquina con SSD pequeño se nota.

Fragmentación de formatos. Flatpak, Snap y AppImage todavía se disputan el espacio. Para quien publica apps, eso significa elegir un bando o mantener tres pipelines. Mi opinión: Flatpak ganó en el escritorio fuera de Ubuntu, y pelear contra eso es perder el tiempo.

Accesibilidad y herramientas antiguas en Wayland. Los lectores de pantalla, la automatización de interfaz y las utilidades que dependían de que X11 dejara a cualquier programa espiar cualquier ventana todavía se están adaptando. Para parte de los usuarios esto no es un detalle, es lo que impide la migración.

Mi opinión sobre el rumbo del escritorio open source

Creo que la dirección es correcta y que tardó. El escritorio Linux pasó años optimizando para el usuario que sabe arreglarlo todo, y ese público nunca fue lo bastante grande para sostener el ecosistema de apps.

El giro que me importa no es técnico, es de responsabilidad. En el modelo nuevo, la distro se encarga del sistema, el dev se encarga de la app y el usuario elige a qué puede acceder cada app. Cada uno en lo suyo. Es el mismo diseño que hizo usable el celular para miles de millones de personas, solo que con código abierto y sin una empresa decidiendo qué puedes instalar.

Si mantienes una app de escritorio, el consejo práctico es simple: empaquétala en Flatpak, deja de asumir acceso al home y pruébala en Wayland antes de que tu usuario la pruebe por ti. Y si usas Linux para trabajar, prueba una distro inmutable con un contenedor de desarrollo. En el peor caso, vuelves al modelo antiguo. En el mejor, nunca más pasas un martes por la noche en una TTY.

Si quieres ver cómo aplico estas ideas en el día a día, échale un vistazo a los proyectos que mantengo.

Una actualización de paquete ya me tuvo una noche entera en una TTY leyendo logs. Y el problema no era el paquete, era el modelo.

En el escritorio Linux tradicional, la app, las bibliotecas y el sistema comparten el mismo espacio. Actualizar una cosa puede romper otra.

La salida que por fin está madurando: sistema base inmutable con rollback, apps aisladas en Flatpak y permisos pedidos a través de portales.

Para quien programa, esto no bloquea nada. El entorno de desarrollo se va a un contenedor con Distrobox, y si se rompe lo borras y creas otro en un minuto.

Si mantienes una app de escritorio: empaquétala en Flatpak, deja de asumir acceso al home y pruébala en Wayland antes de que tu usuario la pruebe por ti.

Un sistema que te da miedo actualizar ya está roto, solo que todavía no te avisó.

Escribí más sobre esto en el blog, el enlace está en los comentarios.

#Linux #OpenSource #Flatpak #DesarrolloDeSoftware #DevExperience