por Reinstalamos Linux en otro ordenador y empezamos a recordar qué paquetes teníamos, qué servicio habíamos configurado y qué archivo tocamos para que funcionase. NixOS y Guix proponen guardar buena parte de esas decisiones en una configuración que podamos leer, versionar y volver a utilizar.
Lo interesante no es que prometan un sistema imposible de romper. Es cambiar una colección de pasos manuales por una descripción más explícita del entorno. Eso ayuda a reconstruirlo y a volver a ciertas configuraciones anteriores, pero no convierte nuestros documentos o bases de datos en copias de seguridad automáticas.
Nix y Guix no son exactamente lo mismo que NixOS y Guix System
Nix es un gestor de paquetes que también podemos utilizar en otros sistemas compatibles. NixOS es una distribución que lo emplea para construir y gestionar el sistema, incluidos paquetes, servicios y parte de su configuración.
Con Guix ocurre algo parecido. Podemos utilizar el gestor de paquetes sobre otra distribución GNU/Linux o instalar Guix System como sistema operativo. El segundo caso incluye decisiones sobre el arranque, los servicios y el conjunto del sistema que no se aplican simplemente por instalar el gestor.
Por ejemplo, añadir un entorno de desarrollo con Guix sobre Debian no transforma Debian en Guix System. Y utilizar Nix para conseguir una herramienta no implica que toda la configuración del ordenador esté descrita en NixOS.
Es una diferencia importante para empezar. Podemos querer controlar mejor las dependencias de un proyecto sin tener que cambiar primero la distribución con la que trabajamos.
Declarativo, inmutable y reproducible no son sinónimos
Una configuración declarativa expresa lo que queremos tener. En lugar de guardar únicamente una lista de comandos ejecutados, describimos paquetes y opciones para que el sistema construya esa configuración.
La inmutabilidad de los paquetes almacenados evita modificarlos como si fueran una carpeta cualquiera de programas. Nix utiliza /nix/store y Guix /gnu/store. En esas rutas pueden coexistir distintas versiones y conjuntos de dependencias. Eso no significa que todo el disco, nuestra carpeta personal o cada dato de un servicio sean de sólo lectura.
La reproducibilidad intenta que podamos reconstruir un entorno conocido a partir de sus entradas. Para ello no basta con conservar un archivo que diga «instalar Git» si la colección de paquetes que lo interpreta cambia con el tiempo. También importan sus revisiones, las dependencias y la disponibilidad de los recursos necesarios.
Son ideas relacionadas, pero no equivalentes. Podemos gestionar paquetes de forma declarativa sin tener una copia de nuestros archivos. Y poder seleccionar una configuración anterior no garantiza que una aplicación antigua entienda datos modificados por una nueva.
Cómo se expresa una configuración en NixOS
En NixOS trabajamos con módulos escritos en el lenguaje Nix. El archivo configuration.nix de una instalación habitual reúne o importa la configuración del equipo. El manual oficial explica cómo modificarla y construir una nueva generación.
Como ejemplo, dentro de una configuración existente podemos tener una selección de paquetes como ésta:
{ pkgs, ... }:
{
environment.systemPackages = [
pkgs.git
pkgs.htop
];
}
Es un módulo parcial, no un archivo suficiente para instalar cualquier ordenador. No sustituimos con él la configuración generada para el hardware, el sistema de archivos o el arranque. Si ya existe environment.systemPackages en ese mismo archivo, añadimos los paquetes a su lista en lugar de duplicar la definición.
En una instalación NixOS ya preparada, podemos construir la configuración sin activarla con:
sudo nixos-rebuild build
La construcción puede descargar o compilar paquetes y necesita espacio. Que termine correctamente no demuestra que hayamos probado el hardware ni el funcionamiento de cada servicio.
Cuando hemos revisado los cambios y queremos activarlos, el procedimiento habitual es:
sudo nixos-rebuild switch
Este segundo paso sí modifica el sistema en ejecución. No conviene utilizarlo sobre un servidor al que sólo accedemos remotamente sin revisar antes qué servicios, usuarios o conectividad cambia la configuración.
Cómo encaja Guix y su uso de Scheme
Guix utiliza Guile Scheme para sus definiciones. El manual de Guix distingue el gestor de paquetes de Guix System y explica su orientación al software libre. En Guix System, esa elección también influye en el kernel Linux-libre y en la compatibilidad con hardware que dependa de firmware no libre.
Por eso no lo elegiría sin comprobar primero el equipo. La cuestión no es sólo si prefiero Scheme a Nix, sino qué controladores necesito y si encajan con la distribución que quiero utilizar.
Para declarar un conjunto pequeño de herramientas podemos guardar un manifest.scm:
(specifications->manifest
(list "git" "htop"))
Con Guix ya instalado, podemos solicitar un entorno con esos paquetes:
guix shell --manifest=manifest.scm
Ese manifiesto describe paquetes de un entorno, no la configuración completa de Guix System. Al salir de la shell terminamos esa sesión, pero los paquetes descargados pueden seguir ocupando espacio en el almacén. Tampoco es un aislamiento de seguridad por defecto. La documentación de guix shell diferencia el entorno normal de sus opciones de aislamiento.
Para registrar qué colección de paquetes estamos utilizando podemos consultar:
guix describe
guix describe -f channels
La información de canales y revisiones permite describir el origen del entorno con más precisión que una lista de nombres. Si queremos repetirlo en otro equipo, conservamos también esa información y las instrucciones del proyecto.
Qué revierte una generación y qué no
Supongamos que actualizamos un servicio y su nueva versión modifica los datos que guarda. Volver a una generación anterior puede recuperar el programa y su configuración, pero no implica deshacer esa modificación de los datos.
Esto también afecta a archivos personales, bases de datos y configuraciones que una aplicación escribe en nuestra carpeta. El rollback del sistema no es una máquina del tiempo para todo el disco. Antes de cambios importantes necesitamos una copia que podamos restaurar.
En NixOS, el procedimiento de recuperación incluye arrancar generaciones anteriores que sigan disponibles y volver a la configuración anterior desde el sistema en ejecución:
sudo nixos-rebuild switch --rollback
En Guix System consultamos primero las generaciones y podemos seleccionar la anterior:
guix system list-generations
sudo guix system roll-back
Hay una diferencia práctica: el manual de guix system indica que, para utilizar efectivamente esa generación tras el rollback del sistema, hay que reiniciar. No debemos confundirlo con revertir sólo el perfil de paquetes de un usuario.
En los dos casos necesitamos conservar la generación a la que queremos volver. Si hemos eliminado generaciones antiguas y recogido sus paquetes, no podemos asumir que siguen disponibles para un arranque inmediato.
Cuál elegir y cómo empezar sin complicarlo todo
NixOS encaja si queremos describir la configuración del ordenador con sus módulos y dedicar tiempo a aprender esa forma de administrar Linux. Guix System resulta especialmente interesante si queremos una distribución centrada en software libre y nos encaja su ecosistema de Scheme y sus decisiones de hardware.
Si lo que buscamos es un entorno de proyecto, podemos empezar por el gestor de paquetes sobre un sistema compatible, sin migrar de golpe todo el escritorio. Aun así, requiere instalación y mantenimiento, no es simplemente descomprimir una aplicación portátil.
Para aprender sobre el sistema completo, empezaría en una máquina virtual con una instalación propia de cada distribución. No utilizaría una guía de instalación de Ubuntu para copiar su particionado en NixOS o Guix. Las imágenes y las instrucciones oficiales de cada proyecto son el punto de partida.
Un primer objetivo razonable sería instalar unas herramientas, guardar la configuración, introducir un cambio sencillo y comprobar cómo volver a la generación anterior. Después prepararíamos y restauraríamos una copia de un archivo personal por separado. Si entendemos por qué son dos operaciones distintas, ya tenemos clara una de las partes más importantes de estos sistemas.
