Qué son las distribuciones inmutables de Linux y qué ventajas ofrecen

En una instalación de Linux de toda la vida, el sistema operativo es un montón de ficheros sueltos que cualquier orden con permisos de administrador puede tocar. Instalas un paquete y algo escribe en /usr; editas un fichero de configuración y queda escrito para siempre; una actualización a medias deja la máquina en un estado que no es ni el de antes ni el de después. Funciona, y lleva funcionando treinta años, pero depende de que nada se tuerza en mitad del camino.

Las distribuciones inmutables le dan la vuelta a eso: el sistema base se monta en solo lectura, las actualizaciones no modifican lo que hay sino que preparan una versión entera aparte, y el cambio ocurre al reiniciar, de golpe o nada. Esta guía explica qué son, qué tres mecanismos distintos se esconden detrás de esa misma palabra y qué distribuciones los usan, contrastado con la documentación de cada proyecto.

---

Qué quiere decir «inmutable», y por qué Fedora prefiere decir «atómico»

«Inmutable» no significa que no puedas cambiar nada: significa que no puedes cambiarlo en caliente y por las bravas. El sistema base va montado en solo lectura, y para modificarlo hay que pasar por una operación que se aplica entera o no se aplica.

De ahí sale la otra palabra que acompaña siempre a esta familia: atómica. Una actualización atómica no tiene estados intermedios. O el sistema arranca con la versión nueva completa, o sigue arrancando con la vieja completa. No existe el «se quedó a medias», que es justamente el escenario que rompe una máquina en una actualización clásica.

Conviene decirlo porque el propio Fedora ha dejado de usar la palabra «inmutable» en su web: a esa familia la llama Atomic Desktops, «los escritorios de Fedora que ya conoces con una capa adicional de seguridad y fiabilidad». Si buscas documentación oficial por «immutable» y no encuentras nada, es por esto.

---

Los tres mecanismos que hay debajo, y no son lo mismo

Bajo la etiqueta común hay tres formas técnicas bastante distintas de conseguir lo mismo. Saber cuál usa tu candidata explica casi todo lo demás: cuánto ocupa, cómo se vuelve atrás y qué pasa cuando quieres instalar algo raro.

• Imagen del sistema. El sistema base es una imagen versionada que se descarga entera. Es lo que hacen rpm-ostree y bootc.
• Instantánea de sistema de ficheros. La actualización se aplica sobre una instantánea de btrfs y solo se arranca en ella si salió bien. Es lo que hace transactional-update.
• Dos raíces, A y B. Hay dos particiones raíz; se actualiza la que no está en uso y se cambia el arranque. Es lo que hace ABRoot, de Vanilla OS.

rpm-ostree se define a sí mismo como «un sistema híbrido de imagen y paquetes»: combina libostree como formato de imagen base y acepta RPM tanto en el cliente como en el servidor. Su propio repositorio avisa de que el foco de desarrollo se ha desplazado a bootc y al ecosistema de dnf5, aunque rpm-ostree sigue muy usado y con soporte.

bootc es la evolución de esa idea y se resume en una línea: «actualizaciones transaccionales del sistema operativo, en el sitio, usando imágenes de contenedor OCI/Docker». La imagen incluye el núcleo de Linux, y el sistema arrancado no corre dentro de un contenedor: systemd sigue siendo el proceso 1 de siempre. Su línea de órdenes y su API están declaradas estables.

transactional-update, el de openSUSE, lo explica con la analogía de una base de datos: solo si todos los cambios se aplican bien el sistema pasa a ese estado nuevo; si algo falla —un guion de posinstalación, quedarse sin espacio— el estado actualizado se descarta y la máquina sigue corriendo lo de antes todo el rato.

ABRoot v2, el de Vanilla OS, va por la tercera vía: «proporciona inmutabilidad y atomicidad completas transaccionando entre dos sistemas de ficheros raíz», con las actualizaciones distribuidas como imágenes OCI.

---

Fedora Silverblue y Kinoite: los Atomic Desktops

Son los dos más conocidos, y son el mismo sistema con distinto escritorio. Fedora Silverblue es el atómico basado en GNOME; Fedora Kinoite, el basado en KDE Plasma. La familia tiene además Sway Atomic, Budgie Atomic y COSMIC Atomic, que son los mismos cimientos con Sway, Budgie y COSMIC encima.

La web de Fedora resume el reparto de tareas sin rodeos: el diseño atómico hace el sistema más estable y menos propenso a fallos, las aplicaciones se instalan por Flatpak con total independencia del sistema base, y las herramientas de línea de órdenes tiran de contenedores con Toolbox. Silverblue sigue el ciclo de publicación estándar de trece meses, igual que Fedora Workstation.

Ese reparto es la clave para entenderlo: el sistema base no se toca, y todo lo que instalas vive fuera de él, en Flatpak o en un contenedor. Si vienes de apt o dnf y quieres ver en qué se diferencian los gestores clásicos de Flatpak, lo contamos en la guía sobre cómo funciona cada gestor de paquetes. Y si lo que no tienes claro es qué escritorio quieres encima, la comparativa de GNOME, KDE, XFCE y Cinnamon vale igual aquí, porque la diferencia entre Silverblue y Kinoite es exactamente esa.

---

openSUSE MicroOS y Aeon: instantáneas de btrfs

openSUSE MicroOS es la rama de openSUSE construida sobre transactional-update. Su filosofía, tal y como la enuncia el propio proyecto, es un sistema que no se altera durante la ejecución y que ejecuta los mismos artefactos de forma consistente en cada arranque.

Su mecanismo aprovecha btrfs con instantáneas, que es una forma muy eficiente en espacio de guardar el historial del sistema de ficheros. Tiene un detalle que lo diferencia de los basados en imagen: todos los ficheros de configuración de /etc forman parte de la instantánea y del rollback. Y como no hace falta ningún formato de paquete nuevo, se siguen usando RPM estándar de openSUSE. Volver atrás consiste en reiniciar en una instantánea anterior de btrfs.

Aeon es el escritorio construido sobre esas mismas tecnologías, y conviene saber una cosa antes de recomendárselo a nadie: su propia web avisa de que sigue en fase de candidata a versión final. Sus actualizaciones diarias se aplican de forma automática mientras trabajas, sin afectar al sistema en marcha hasta que reinicias; trae Distrobox configurado para lanzar contenedores de Tumbleweed y Flatpak listo para instalar desde Flathub.

---

Vanilla OS: dos raíces y una orden para volver atrás

Vanilla OS es el representante del modelo A/B. Su herramienta, ABRoot, mantiene dos particiones raíz y transacciona entre ellas: se actualiza la que no está arrancada y el cambio se hace efectivo al reiniciar.

Lo interesante es cómo resuelve el problema de siempre, el de «¿y si necesito instalar un paquete en el sistema base?»: el gestor de paquetes integrado de ABRoot genera imágenes OCI locales con tus cambios y las aplica encima de la imagen por defecto del sistema. Sus órdenes son tan directas como parecen: abroot upgrade, abroot rollback, abroot rebase para cambiar la imagen OCI de base y abroot status para saber en cuál de las dos raíces estás.

---

NixOS: el caso raro, que no es inmutable sino declarativo

NixOS aparece siempre en estas listas y merece un matiz, porque no hace lo mismo que los anteriores. No monta una raíz en solo lectura ni transacciona entre particiones: describe el sistema entero en un fichero de configuración y lo construye a partir de ahí.

El proyecto se define por tres propiedades: reproducible, porque Nix construye cada paquete aislado de los demás y sin dependencias no declaradas, de modo que si funciona en una máquina funciona en otra; declarativo; y fiable, porque instalar o actualizar un paquete no puede romper otros, permite volver a versiones anteriores y ningún paquete queda en un estado inconsistente durante una actualización. Su colección, Nixpkgs, supera los 140 000 paquetes.

El resultado práctico se parece —puedes volver atrás, el sistema es predecible—, pero el camino es otro: aquí la garantía no viene de que el disco sea de solo lectura, sino de que todo está declarado.

---

SteamOS y Bazzite: la inmutabilidad que quizá ya estás usando

Si tienes una Steam Deck, ya vives en un sistema inmutable. SteamOS monta su sistema en solo lectura, y Valve lo dice con todas las letras en su documentación de soporte: cualquier cosa que instales fuera de Flatpak —con pacman, por ejemplo— puede desaparecer con la siguiente actualización de SteamOS. Para tocar la imagen de solo lectura hay una orden, sudo steamos-readonly disable, y Valve la acompaña de un aviso explícito de no usarla si no sabes lo que estás haciendo.

Bazzite es la otra cara: una distribución pensada para jugar, construida a partir de Fedora Kinoite en su versión con KDE y a partir de Fedora Silverblue en la de GNOME. Es decir, los Atomic Desktops de Fedora con el trabajo de puesta a punto ya hecho. Su modelo de actualización lo explica su web: al ser basada en imagen, después de cada actualización la versión anterior del sistema se conserva en la máquina y puedes seleccionarla en el arranque; las imágenes se guardan noventa días en sus repositorios y se puede saltar a ellas desde el terminal. Y si ya estás en un Atomic Desktop de Fedora, puedes pasarte a Bazzite sin reinstalar, rebasando.

---

Qué ganas de verdad

Puestas en fila, las ventajas de este modelo son cuatro, y ninguna es teórica.

• Una actualización no puede dejarte a medias. Es la propiedad que define a la familia: se aplica entera o no se aplica.
• Volver atrás es reiniciar y elegir. No hay que desinstalar nada ni reconstruir a mano el estado anterior: el anterior sigue ahí.
• El sistema base es siempre el mismo. Como no se toca en caliente, dos máquinas con la misma versión son de verdad la misma máquina, y eso hace que un fallo sea reproducible.
• Lo que instalas no puede romper el sistema. Las aplicaciones viven en Flatpak o en contenedores, fuera de la raíz.

---

Qué pierdes, y a quién le va a molestar

La contrapartida es real y conviene tenerla clara antes de instalar nada.

Lo primero: cualquier receta de internet que empiece por «copia este fichero en /usr» no te va a funcionar tal cual. Hay que traducirla al modelo de la distribución, y eso significa aprender otra forma de hacer las cosas.

Lo segundo: instalar software en el sistema base deja de ser gratis. Se puede —Fedora lo llama superponer paquetes, con rpm-ostree—, pero la documentación de Bazzite recomienda expresamente evitarlo siempre que se pueda, porque los paquetes superpuestos pueden romper actualizaciones futuras hasta que los quites. La vía buena es Flatpak para aplicaciones y un contenedor —Toolbox, Distrobox— para herramientas de terminal.

Lo tercero: muchos cambios solo surten efecto al reiniciar. En una máquina de escritorio es un inconveniente menor; en un servidor al que le pides no caerse, es una decisión que hay que tomar a conciencia.

---

Entonces, ¿te conviene?

Si tu máquina es para trabajar, navegar, ofimática y jugar, y tu idea de administrar el sistema es que no haya que administrarlo, este modelo está hecho para ti: Silverblue o Kinoite si quieres Fedora, Bazzite si además juegas, Aeon si prefieres el mundo openSUSE y aceptas que todavía es candidata a versión final.

Si te ganas la vida cacharreando con el sistema base, compilando controladores o siguiendo recetas que escriben en /usr, vas a pelearte con él. En ese caso hay un camino intermedio razonable: probarlo antes sin tocar tu instalación, arrancando desde un USB live, o dejarlo conviviendo con Windows en un arranque dual hasta tenerlo claro. Y si lo que te frena es no saber dónde va cada cosa, la guía sobre la estructura del sistema de archivos de Linux explica por qué /usr es justo la carpeta que estos sistemas blindan.

---

Te puede interesar

Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.