- Las distribuciones Linux inmutables ofrecen un modelo operativo en el que las actualizaciones se preparan fuera del sistema en ejecución y se aplican en el siguiente arranque, con posibilidad de volver atrás si algo falla.
- A pesar del nombre “inmutable”, varias áreas del sistema todavía pueden cambiar; en la práctica, el punto en común se parece más a actualizaciones transaccionales y rollback.
- NixOS y Guix se centran en configuración declarativa y repositorios de solo lectura, mientras que la familia OSTree, MicroOS y Vanilla OS abordan el tema mediante
/usr, snapshots de btrfs y particiones raíz A/B, respectivamente. - La ventaja es mantener el sistema estable durante cambios de paquetes y poder revertir problemas, pero persisten la necesidad de reiniciar, los conflictos con herramientas de gestión de configuración y la dificultad para rastrear cambios.
- Lo novedoso no son los snapshots en sí, sino aplicar cambios en un entorno no vivo e integrarlos con el bootloader y herramientas de usuario para hacerlos fáciles de manejar.
El alcance real del nombre “inmutable”
- La inmutabilidad originalmente significa un objeto que no cambia, pero al aplicarla a un sistema operativo la definición se vuelve ambigua de inmediato.
- Un LIVE-CD de Linux parece inmutable en el sentido de que siempre arranca con los mismos programas y el medio de disco es de solo lectura, pero durante la ejecución se pueden crear archivos y directorios o instalar paquetes.
- Para llamar hoy a una distribución Linux inmutable, en general se requieren tres condiciones:
- No realizar actualizaciones del sistema directamente sobre el sistema vivo.
- Aplicar los cambios de paquetes en el siguiente arranque.
- Poder hacer rollback a un estado anterior.
- Cada implementación tiene funciones adicionales distintas, pero estas tres condiciones se acercan al mínimo actual de una distribución “inmutable”.
Diferencias por implementación
-
NixOS / Guix
- NixOS y Guix dependen de implementaciones de la misma familia: Nix apareció por primera vez en 2003, y el gestor de paquetes Guix se bifurcó de Nix a inicios de la década de 2010 con el objetivo de ser 100% software libre.
- Ambos sistemas son muy distintos de los sistemas tradicionales tipo Unix y toman la inmutabilidad como principio central.
- Todos los paquetes y archivos compilados se almacenan como entradas únicas en un directorio especial de solo lectura, en el que solo puede escribir el gestor de paquetes.
- El propio sistema operativo es un producto del gestor de paquetes, y el usuario escribe el estado deseado del sistema como configuración declarativa.
- La configuración incluye usuarios, shells, paquetes instalados, servicios en ejecución y sus ajustes, particiones a montar y opciones, entre otros.
- Como los módulos proporcionan valores predeterminados, al crear un usuario no hace falta especificar manualmente UID, GID, shell y directorio home.
- Archivos como
/etc/fstabo/bin/shtambién son de solo lectura, y para cambiarlos hay que pasar por el gestor de paquetes. - Cambiar de configuración es casi como cambiar enlaces simbólicos y puede hacerse de inmediato; al arrancar se puede elegir una configuración anterior para hacer rollback.
- Fuera del directorio especial de almacenamiento,
/home,/etc,/vary otros son modificables; se pueden reemplazar enlaces simbólicos del sistema por otros, pero no modificar la fuente original. - NixOS se considera una buena implementación, pero es tan distinto de los sistemas existentes que, pese a sus ventajas, su adopción es baja.
-
Endless OS
- Endless OS es uno de los primeros sistemas operativos inmutables lanzados para usuarios generales, con el objetivo de ser un sistema robusto usable incluso en países con baja cobertura de internet o de red eléctrica.
- Está basado en Debian, pero implementa la inmutabilidad con OSTree.
- OSTree gestiona la imagen central del sistema y agrega encima capas similares a paquetes; también puede preparar una nueva imagen del sistema para el siguiente arranque.
- Los cambios de paquetes se aplican a una nueva versión del sistema que se usará en el siguiente arranque, y al arrancar se puede volver a la versión anterior.
- Las particiones en general son escribibles, pero
/usr, el área de paquetes gestionada por OSTree, se monta como solo lectura. /etcno tiene rollback.- Las aplicaciones de usuario se instalan con Flatpak, reduciendo la necesidad de reiniciar cada vez que se instala un paquete nuevo.
- Su escritorio GNOME modificado se ve como un menú de smartphone y apunta a una forma familiar para usuarios no técnicos.
- Instalar herramientas de DevOps no es práctico, aunque tampoco es imposible.
-
Fedora Silverblue
- Fedora Silverblue está en la línea sucesora de Project Atomic, que buscaba volver inmutables a Fedora / CentOS / RHEL.
- Usa rpm-OSTree, que aplica cambios de paquetes RPM sobre OSTree.
- El sistema se compone de una única imagen central por release y capas de paquetes agregadas encima.
- Se pueden listar las capas de paquetes instaladas y, al eliminar un paquete, se regenera todo el stack para que no queden residuos tras la eliminación.
- Este proceso de regeneración es muy lento.
- Aunque se instale un paquete, no se aplica al sistema actualmente arrancado, por lo que de forma predeterminada hay que reiniciar; durante el arranque se puede elegir una versión anterior del sistema.
- rpm-OSTree ofrece una función para fusionar temporalmente los cambios del siguiente arranque con el sistema vivo mediante un overlay tmpfs.
- La política de montaje es de solo lectura salvo
/etc,/rooty/var; los directorios home están por defecto en/var/home, lo que puede ir contra las expectativas. - Como rpm-OSTree no gestiona
/etc, no se revierte con rollback. /usr/locales un enlace simbólico a un directorio dentro de/var, lo que facilita inyectar cambios de usuario sin archivos RPM.- Debido a que instalar paquetes es lento y requiere reiniciar, se recomienda usar Flatpak o toolbox.
- toolbox crea contenedores Fedora sin privilegios de root para poder usar bibliotecas o herramientas de desarrollo desde la terminal.
-
OpenSUSE MicroOS / Aeon
- OpenSUSE MicroOS es un spin inmutable de OpenSUSE Tumbleweed, que es rolling-release, y usa una implementación propia.
- Todo el sistema, salvo algunos directorios como
/homey/var, está sobre snapshots de btrfs. - Cuando se necesita un cambio del sistema, el snapshot actual se clona como un snapshot nuevo, y los cambios se aplican a ese snapshot nuevo para usarlo en el siguiente arranque.
- A diferencia de los sistemas basados en OSTree,
/etctambién forma parte del snapshot y puede revertirse. - Es posible usar un shell dentro del snapshot nuevo para cambiar cualquier archivo del sistema de archivos, lo que resulta útil para tareas como inyectar archivos para solucionar problemas de drivers.
- Sin embargo, esos cambios no se rastrean, por lo que es difícil garantizar que el sistema esté en un estado “puro”.
- Los cambios se realizan con el comando
transactional-update, que permite agregar o quitar paquetes, o abrir un shell dentro de un snapshot nuevo para hacer los cambios deseados. - Aunque
/etcestá incluido en el snapshot, siempre es escribible, así que si se modifica/etcen estado vivo y luego se crea un snapshot nuevo, ese cambio se hereda de inmediato. - El enfoque predeterminado consiste en planificar un reinicio diario después de las actualizaciones; al ser rolling-release hay actualizaciones todos los días, y antes de reiniciar no se obtienen los beneficios de los paquetes nuevos.
- El reinicio automático puede desactivarse.
- La función para aplicar cambios al sistema vivo, como en Silverblue, actualmente es experimental y todavía no puede usarse.
- En su lugar, se recomienda usar distrobox para instalar herramientas de usuario mediante contenedores sin privilegios de root de varias distribuciones.
-
Vanilla OS
- Vanilla OS es un sistema nuevo de la familia inmutable, basado en Ubuntu y con planes de migrar pronto a una base Debian.
- La inmutabilidad se implementa con ABroot.
- ABroot utiliza una partición raíz A, una partición raíz B y una partición para datos persistentes como
/homeo/var. - El flujo de arranque y cambios es el siguiente:
- El primer arranque se realiza desde A y A se monta como solo lectura.
- Los cambios del sistema, como paquetes nuevos o modificaciones de archivos en
/etc, se aplican a B; también pueden aplicarse en vivo mediante un overlay tmpfs. - Tras reiniciar, se arranca desde B y, si tiene éxito, ABroot escanea las diferencias entre A y B y aplica los cambios de B en A.
- Cuando no hay cambios nuevos, A y B siempre son idénticas.
- La desventaja es que solo se puede hacer rollback antes de arrancar la nueva versión.
- Una vez que se arranca la nueva versión, los cambios también se aplican a la partición de arranque anterior y ya no se puede hacer rollback.
- Este método es útil principalmente para revertir actualizaciones fallidas o cambios probados en vivo.
- Vanilla OS ofrece el gestor de paquetes apx.
- apx es una herramienta creada por el autor de distrobox y permite a usuarios no root instalar paquetes de varias distribuciones, como Arch Linux, Fedora, Ubuntu y Nix, e integrarlos como si fueran instalaciones locales.
- Vanilla OS, ABroot y apx todavía son jóvenes y tienen partes poco pulidas.
-
Alpine Linux con LBU
- Alpine Linux puede crear una configuración cercana a la inmutabilidad mediante el comando
lbu. - Usa el instalador de Alpine como sistema de arranque básico y crea un tarball de “configuración guardada” que se aplica automáticamente al arrancar.
- En cada arranque se vuelven a extraer los directorios y se reinstalan los paquetes, y todo es completamente escribible en memoria viva.
- Siempre se parte de un estado limpio y se aplican cambios encima; se pueden revertir cambios y empezar de nuevo.
- No cumple por completo la definición de inmutabilidad indicada antes, porque los cambios se aplican sobre el sistema base.
- Como todo el sistema está en memoria y hay que gestionar manualmente qué guardar y restaurar, requiere mucha comprensión y el archivo puede crecer bastante.
- La documentación también es escasa.
- Alpine Linux puede crear una configuración cercana a la inmutabilidad mediante el comando
Ventajas y restricciones operativas
-
Ventajas
- Si surge un problema, se pueden revertir los cambios.
- Las actualizaciones transaccionales ayudan a que el sistema siga ejecutándose correctamente durante cambios de paquetes.
-
Desventajas
- La integración con herramientas de gestión de configuración como Ansible, Salt o Puppet es muy mala.
- Aunque se hayan actualizado para conocer la forma de aplicar cambios de paquetes, si se intenta administrarlos como sistemas comunes, casi siempre se choca con una pared.
- Tener que reiniciar después de los cambios es molesto, aunque NixOS y Guix no requieren reiniciar en cada cambio.
- Los sistemas basados en OSTree no son flexibles.
- Por ejemplo, en una netbook que necesita archivos adicionales en el directorio de ALSA para el sonido, no se pueden agregar sin crear un paquete que distribuya esos archivos.
- El rollback se parece a un rollback a ciegas, por lo que es difícil saber qué cambios tenía cada versión del sistema.
- Programas como Nix/Guix que necesitan directorios en el sistema de archivos raíz, o instalaciones a nivel de todo el sistema de software no empaquetado, pueden ser difíciles.
Hechos y malentendidos sobre los sistemas inmutables
- La inmutabilidad, en sentido estricto, es casi falsa: muchas partes del sistema todavía pueden modificarse.
- Inmutable no significa sin estado (stateless).
- NixOS y Guix rastrean todo el sistema con un gestor de paquetes estable y pueden usar un sistema de control de versiones para las fuentes, por lo que se consideran implementaciones que incorporaron la filosofía correcta desde el principio.
- La inmutabilidad suele asociarse con ventajas de seguridad, pero un atacante que obtiene permisos de root puede manipular el sistema vivo y también tocar la partición
/boot. - Nada impide instalar un backdoor para usarlo en el siguiente arranque.
- La inmutabilidad exige disciplina y mantenimiento.
- Hay que prestar atención al control de versiones.
- Programas adicionales como apx, distrobox o devbox deben actualizarse por separado del sistema.
- NixOS y Guix tienen esta parte integrada.
Qué es realmente nuevo
- Los sistemas operativos inmutables están llamando la atención en la comunidad de sistemas open source, pero bajo la misma palabra se mezclan varias implementaciones y casos de uso.
- El nombre “inmutable” crea ciertas expectativas en los usuarios, pero en realidad se acerca más a actualizaciones transaccionales para sistemas operativos.
- Las actualizaciones transaccionales en sí no son un concepto nuevo.
- Solaris y ZFS permitían elegir snapshots del sistema al arrancar.
- FreeBSD también parece haber implementado una función similar hace unos 10 años.
- Las distribuciones Linux comunes también permiten elegir snapshots al arrancar si usan snapshots de btrfs.
- Lo realmente nuevo es aplicar cambios transaccionales en un entorno que no está vivo, integrarlos con el bootloader y ofrecer herramientas que los usuarios puedan manejar fácilmente.
- Como lectura adicional se recomienda “Immutable” → reprovisionable, anti-hysteresis de Colin Walters.
1 comentarios
Opiniones en Hacker News
Me alegra que Silverblue esté en la lista, pero es una lástima que falte Fedora CoreOS
FCOS es un OS apto para producción, ha avanzado mucho desde la adquisición de CoreOS y parece un buen punto medio que, en comparación con Nix, es más fácil de aprender y de usar, a la vez que mantiene la inmutabilidad
CoreOS Layering, que agregó el equipo de desarrollo de FCOS, es una función potente: si definís el estado del sistema con un Dockerfile, FCOS hace rebase a ese estado, y para aplicar la configuración del servidor solo hace falta reiniciar
Si necesitás una VM para tu próximo proyecto, vale la pena probarlo. También hice Bupy, una herramienta CLI basada en Python que facilita crear archivos Butane localmente en una workstation Linux, y hay un ejemplo de cómo correr Paperless NGX con CoreOS Layering
https://github.com/quickvm/bupy
https://github.com/quickvm/fcos-layer-paperless-ngx
https://coreos.github.io/rpm-ostree/container/
https://github.com/coreos/enhancements/blob/main/os/coreos-l...
https://github.com/coreos/layering-examples
Lo más difícil para mí fue entender cómo usar proyectos así en entornos bare metal. Crear imágenes de VM está genial, pero en la práctica muchas veces querés instalarlo en un disco existente, o instalarlo teniendo un pool ZFS por debajo
Me pregunto qué tan difícil es instalar CoreOS en una Raspberry Pi. Algunas guías de instalación en internet se ven bastante complicadas
Otro eje que siempre queda fuera en estas introducciones a sistemas inmutables es el enfoque basado en imágenes
Estoy trabajando con gente mucho más capaz que yo en https://universal-blue.org/, donde construimos imágenes de contenedores OCI sobre la edición base de Fedora Silverblue y varias ediciones de escritorio
Estas imágenes se pueden iniciar con rpm-ostree o, más precisamente, se puede hacer rebase hacia ellas; es una forma de extender el sistema más robusta que el layering, y permite que cualquiera herede o aproveche fácilmente los mismos cambios. Crear tu propia imagen también es muy sencillo
Parece que VanillaOS y SUSE hacen algo parecido, pero nosotros no somos un proyecto de OS, solo un downstream de Fedora. El soporte oficial de Fedora también está en curso, y aun con lo que ya funciona, por experiencia es una de las formas más sólidas y fáciles de hacer cosas como ofrecer drivers de Nvidia
Las VM arrancaban desde una imagen, y tanto la imagen como los discos de cambios estaban completamente en RAM. Los perfiles de usuario estaban en el disco duro, pero un host de escritorio para 25 personas arrancaba en unos 4 segundos hasta quedar listo para recibir inicios de sesión remotos
Fue el sistema Windows menos doloroso de parchear
Tenía entendido que la instalación base no usa layering, y que el layering solo entra cuando querés instalar paquetes RPM adicionales
También me pregunto si las imágenes se sirven desde GitHub, si GitHub cobra por el tráfico saliente externo, y qué pasa si muchos usuarios intentan descargar la misma imagen
Me interesan más los sistemas preconfigurados que los sistemas inmutables
En esto NixOS y Home Manager se destacan, pero la forma de configurarlos es realmente espantosa. Quiero poner toda la configuración bajo control de código fuente y saber que el estado actual del sistema coincide con esa configuración, y que cualquier otro cambio se borre al reiniciar. También sería bueno que los cambios hechos antes del reinicio se resaltaran
Por mi experiencia limitada con cosas como Silverblue, se puede configurar el sistema base, pero cuando empezás a agregar aplicaciones como Firefox terminás usando Flatpak, y no sé bien cómo declarar toda la instalación de Flatpaks que quiero junto con su configuración
Supongo que debe haber alguna forma de instalar Flatpaks en lote y manejar el resto con dotfiles
https://universal-blue.org/tinker/mindset/#resist-the-urge-t...
https://nixos.wiki/wiki/Impermanence
https://julianhofer.eu/blog/01-silverblue-nix/
Esto ayuda a minimizar la parte de configuración de Nix que coincidís en que es espantosa
El problema que tuve con Flatpak y con el enfoque inmutable en general es que no se puede modificar de formas que el desarrollador no admite.
Por ejemplo, sincronizo mi calendario con decsync y, que yo sepa, es imposible agregar el plugin de decsync al Flatpak de Evolution.
Hasta que estos sistemas inmutables admitan como función de primera clase apilar sistemas de archivos superpuestos personalizados para casos de uso que el desarrollador no puede o no quiere admitir, la gente seguirá usando sistemas mutables.
Algunos paquetes de nixpkgs y la mayoría de los módulos de NixOS y Home Manager exponen muchas opciones para configurar plugins, paquetes adicionales, etc.
Nix también ofrece overlays y overrides para agregar paquetes personalizados o variantes de paquetes existentes, e incluso puede reemplazar partes de un paquete. Si eso no alcanza, también se pueden aplicar parches directamente al código o compilar desde un fork del repositorio upstream.
De hecho, eso es una de las cosas que más me gustan de Nix. Como es fácil decir “al compilar este paquete, reemplaza esta dependencia por mi versión”, termino contribuyendo más seguido al open source.
Fuera de este ámbito, la mayoría del software ya viene con las funciones necesarias incluidas. Por ejemplo, Solidworks nunca me pidió descargar dependencias opcionales, pero FreeCAD me pedía algo literalmente cada 15 minutos cada vez que pasaba al siguiente paso del flujo CAD/CAM/simulación/renderizado.
También vale la pena ver https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
La idea central es que el “20% que usa todo el mundo” nunca es el mismo. En la última década escuché de docenas de empresas que intentaron lanzar procesadores de texto “ligeros” implementando solo el 20% de las funciones, pero la historia de un periodista que, al escribir una reseña, busca la función de conteo de palabras y descubre que está dentro del “80% que nadie usa”, para terminar escribiendo “un programa liviano está bien y el bloat es malo, pero esta maldita cosa no cuenta palabras, así que no sirve”, es tan vieja como la PC.
Me recuerda a cuando hace 10 años todos corrieron hacia NoSQL y enseguida volvieron a inventar esquemas dentro de cada proyecto.
OBS es un ejemplo. En Flathub hay varios plugins de OBS con la forma
com.obsproject.Studio.Plugin.*.Creo que la definición debería ser esta: después de instalar cualquier cantidad de paquetes, si los eliminas en cualquier orden en algún momento futuro, el sistema debería quedar en un estado equivalente a como si nunca se hubieran instalado.
Esta definición excluiría algunas distribuciones, pero creo que esa propiedad es precisamente la parte importante del concepto.
Cuando eliminas un procesador de texto o un editor de texto, ¿quieres que también desaparezcan todos los archivos que escribiste? Si eliminas un navegador, ¿también deberían desaparecer todos los archivos que descargaste? Si no, no hay una forma confiable de distinguir qué archivos creó automáticamente el programa y cuáles creó el usuario con ese programa.
Lo que se creó durante la instalación puede eliminarse fácilmente, pero no todos los cambios posteriores.
También se puede pensar en el caso de cambiar la implementación de DNS y luego cambiar el servidor DNS predeterminado. Al eliminar el provider para volver a la implementación anterior, hay que elegir si también se vuelve al servidor anterior o si se conserva la nueva configuración del servidor. Personalmente, querría cambiar solo el provider y conservar el servidor nuevo.
Los directorios compartidos entre varias máquinas también lo complican. Si
/home/${USER}está montado por NFS o Samba y se usan los mismos archivos en varias estaciones de trabajo, cuando un programa creó archivos en el directorio de configuración XDG y se elimina ese programa en una estación, ¿también habría que borrar esos archivos de todas las máquinas? Un gestor de paquetes de un único sistema no tiene forma de saber si todos los dispositivos deben ser idénticos o si basta con que el directorio home sea el mismo.Vale la pena revisar las estructuras de datos con representación única y las estructuras de datos independientes del historial.
Habría que tener especial cuidado para que los dispositivos de bloques, por ejemplo un SSD, asignen bloques sin depender del historial.
También se podría decir que el conjunto de paquetes forma una retícula, y que sin importar por qué camino llegaste a cualquier subconjunto de paquetes, hay un único estado.
Uso Fedora Silverblue desde su lanzamiento, y esto definitivamente es el futuro.
Creo que todo el mundo debería usar ostree.
Quizás yo use Linux de forma un poco improvisada, pero no tener permisos de escritura en carpetas como
/usro/binme volvía loco más o menos cada dos semanas.Por ejemplo, un script escrito por un usuario de Ubuntu buscaba una biblioteca con nombres y ubicaciones al estilo Ubuntu, y Fedora usa otro nombre para esa biblioteca. En esos casos, mi instinto es crear un enlace simbólico con el nombre de Ubuntu que apunte a la biblioteca administrada por el RPM de Fedora.
Pero en la práctica, para hacerlo funcionar tuve que hacer un fork del script, lograr que compilara localmente, corregirlo para que buscara ambos nombres de biblioteca, correr pruebas locales, enviar un PR al upstream, etc. Algo que normalmente se resolvía con una sola línea en la shell se convirtió en una tarea de 90 minutos.
Leí una respuesta en Quora que estimaba el presupuesto de desarrollo de Windows OS en unos 18 mil millones de dólares en salarios. Si imaginamos que Red Hat invierte 2 mil millones de dólares en Fedora para convertirlo en el Firefox del mundo de los sistemas operativos de escritorio, con solo quitarle un 10% de cuota a Microsoft ya sería enorme.
Llegó hasta aquí con tan pocos recursos sobre miles de paquetes open source. Ese dinero podría usarse para mantener vivos estos proyectos y patrocinarlos durante su desarrollo. Los empleados de Red Hat ya participan en muchos de ellos.
No me quedó claro cómo se llega al punto de “distribuir una distro Debian como snapshots de ostree”.
Me pregunto si esto está diseñado solo para administradores de sistemas profesionales o constructores de sistemas.
No probé Silverblue, pero Nix también se siente como el futuro.
Si es posible, me gustaría empezar a versionar mi sistema actual tal como está. Si eso es demasiado difícil o imposible, algún día pienso mover el servidor a Silverblue. Realmente me gusta la idea de ostree.
Este verano me enganché con Tinycore.
Es un buen complemento para la filosofía de seguridad de “un SO, una función” que está detrás de Qubes, Tails y Whonix, de la que se habló aquí hace unos días.
Como es tan liviano, se puede levantar en segundos una VM para el servidor de correo, otra para la base de datos y otra para el firewall/router.
Tinycore en sí es inmutable, así que basta con poner los “paquetes” y la configuración en un vdisk y marcarlo como de solo lectura. Un script de Virsh se encarga de iniciar y detener el “servicio”, y cada servicio es una instancia de Tinycore.
Es divertido y hasta ahora ha sido sólido, pero todavía no estoy seguro de ponerlo en producción para alguien.
La implementación tiene puntos flojos, y probablemente tampoco tenga patrocinio corporativo que explique por qué la gente no lo conoce.
A diferencia de otras distribuciones Linux inmutables, es robusto y simple.
Vengo usando Fedora Sericea desde que salió. Básicamente es Fedora Silverblue, pero usa Sway-wm en lugar de Gnome-wm.
En la práctica es bastante usable, y tampoco hace falta reiniciar cada vez que se ejecuta
rpm-ostree install.rpm-ostree live-applylo resuelve con un overlay basado en systemd.Todavía no tuve que volver a arrancar Windows. Si esto se mantiene así durante los próximos 6 meses, me pasaré por completo a Linux y borraré la partición de Windows.
Sobre la frase “la inmutabilidad es una mentira y muchas partes del sistema son mutables; simplemente no sé cómo describir esta familia de otra forma, ¿algo transaccional?”, en el caso de Nix suena más centrado en la reproducibilidad.
Parece significar que, si pones el archivo de configuración de Nix en otra computadora, deberías obtener el mismo sistema salvo quizá
/home.Los demás parecen más orientados a ofrecer, con otra implementación, funciones de snapshots y rollback que ya daban las herramientas existentes.
Si significa que no haces upgrades del sistema en vivo, que los cambios de paquetes se aplican en el siguiente arranque y que puedes revertirlos, eso se parece más a transacciones atómicas, como en una base de datos. Aunque tener que apagar el sistema para hacer commit suena un poco excesivo.
Microsoft metió transacciones atómicas en el sistema de archivos hace años, pero las transacciones de sistema de archivos no se usaron mucho.
Sería bueno que el sistema de instalación pudiera confirmar todos los cambios de una vez y, si aparece un problema durante la instalación, volver al estado anterior sin haber confirmado nada. En teoría sería posible con un sistema de archivos transaccional, pero en la práctica parece que habría demasiado estado involucrado que no pertenece al sistema de archivos.
Del lado de servidores está Bottlerocket OS de Amazon.
La idea es usar particiones A/B para las actualizaciones y correr todo lo que no sea el sistema base en contenedores.
Para la configuración personalizada al arrancar se usan boot containers, y para servicios de larga ejecución se usan host-containers, o DaemonSet en Kubernetes.
https://github.com/bottlerocket-os/bottlerocket