Comparativa NixOS vs Ubuntu 2026: gestión declarativa de paquetes para sysadmins Linux

Por qué la gestión de paquetes importa más en 2026 que hace cinco años

Hace una década la pregunta para un sysadmin era práctica: apt-get install nginx y listo. Hoy esa misma orden esconde decisiones que antes no existían. Si actualizas glibc en Ubuntu 26.04 LTS sin querer, puedes romper media flota. Si tu configuration.nix evalúa, en NixOS 26.05 sabes exactamente qué versión del paquete y de cada dependencia quedó activa, y tienes rollback a la generación anterior en un reinicio.

La gestión de paquetes dejó de ser instalar software para ser definir estado. Esa diferencia es el corazón de la comparativa: Ubuntu sigue siendo una distro imperativa disfrazada de moderna, mientras NixOS apuesta por un modelo declarativo funcional desde el primer boot. Para un sysadmin con cinco servidores, esa brecha es anécdota; para uno con cincuenta, o con varios entornos reproducibles (dev/staging/prod), es la diferencia entre dormir tranquilo y tener un fin de semana de tres días arreglando una actualización de OpenSSL.

Tabla comparativa lado a lado

Dimensión	Ubuntu 26.04 LTS Resolute Raccoon	NixOS 26.05 Yarara
Modelo de paquetes	Imperativo + APT/Dpkg (.deb)	Funcional puro + Nix store (/nix/store)
Configuración del sistema	Archivos en /etc + stateful	Declarativa (configuration.nix / flake.nix)
Rollback a estado anterior	Limitado (snapshots LVM, Timeshift, btrfs)	Por diseño, cada generación es booteable
Atomicidad de upgrades	No garantizada (puede romper a la mitad)	Sí: nixos-rebuild switch aplica o no aplica
Reproducibilidad entre máquinas	Manual (Ansible, scripts)	Copia la config y la evaluación es determinista
Kernel	Linux 7.0 (GNOME 50, Wayland-only)	Linux 6.18 (configurable por generación)
Soporte LTS	Hasta 15 años (servidor standard), 5 desktop	7 meses por release estable; canal unstable permanente
Tamaño base instalación mínima	~3.2 GB (server ISO)	~1.4 GB (minimal ISO sin GUI)
Curva de aprendizaje para sysadmin Debian/Ubuntu	Cero, se siente igual que 22.04/24.04	Alta: sintaxis Nix, modelo funcional, store inmutable
Compatibilidad FHS	Sí, 100% FHS estándar	No: binarios viven en /nix/store/<hash>-<name>
Paquetes disponibles	~60 000 en repos universe + multiverse	~120 000 en nixpkgs (más grande que Debian)
Default userland	uutils (Rust coreutils), sudo-rs, GNOME 50	GNU coreutils, systemd stage 1, GNOME 49/Plasma 6
Post-quantum crypto por default	Sí, TLS/SSH PQ desde la 26.04	Depende de la app; OpenSSL upstream

Qué cambió en cada proyecto en 2025-2026

Antes de comparar filosofías, conviene ver qué hay en el plato ahora mismo. Ubuntu 26.04 LTS Resolute Raccoon salió el 23 de abril de 2026 como el undécimo LTS de la historia, alineado en la fecha más repetida de Canonical: 9.04, 15.04 y 20.04 también salieron un 23 de abril. Lo grande: kernel Linux 7.0, GNOME 50 sin sesión X11 (solo Wayland con XWayland para apps legacy), reemplazo total de coreutils GNU por la implementación en Rust uutils, y TPM-backed full disk encryption estable en lugar de experimental. El detalle más comentado por la comunidad LATAM es la integración nativa de ROCm y CUDA en repos, sin instalar drivers de NVIDIA a mano. La cita de Canonical: “es una declaración de intenciones para el próximo LTS de 2026”, ironía incluida porque el LTS ya es este.

NixOS 26.05 Yarara salió el 30 de mayo de 2026, manteniendo el ciclo de seis meses. Los números: 2 842 contribuidores, 59 703 commits desde 25.11, 20 442 paquetes nuevos, 10 547 módulos y opciones de configuración. La novedad más relevante para sysadmins es systemd stage 1 como initrd por default, lo que acerca a NixOS al modelo de arranque de Fedora y Ubuntu; el initrd scriptado de toda la vida queda deprecado y se va a eliminar en 26.11. La versión 25.11 Xantusia quedó deprecada y dejará de recibir parches de seguridad el 30 de junio de 2026. La próxima release, 26.11 Zokor, se espera para noviembre de 2026.

El problema real: por qué el modelo imperativo se rompe al escalar

El flujo Ubuntu clásico es: actualizas un paquete, apt lo marca, postinst scripts corren, libs quedan en /usr/lib/x86_64-linux-gnu/ con un nombre fijo, y si quieres la versión anterior, sólo te queda tu backup o el reposio snapshots. Si ese paquete era libc6 y rompiste un binario enlazado dinámicamente, tienes dos opciones: pin en APT y rezar, o downgrade manual tocando /var/lib/dpkg/status. Ninguna escala.

Las herramientas que la industria inventó para tapar este hueco son evidence de que el modelo base no resuelve el problema. Mosh, etckeeper, unattended-upgrades,apticron,apticron-ng,apt-listbugs,apticron,timeshift,btrfs-assistant,snapshots LVM automáticos. Todas son capas adicionales sobre un sistema que no sabe qué versión de qué cosa está corriendo. Un dpkg --get-selections te dice qué está instalado, pero no te dice por qué ni te permite revertir limpiamente si esa versión de hace seis meses se rompió hoy.

NixOS resuelve el problema raíz. Cada archivo del sistema vive en /nix/store/<hash>-<name>-<version> donde el hash es un SHA-256 del input completo: fuentes, flags de compilación, dependencias. Si el hash cambió, es otro archivo. Si quieres la versión anterior, está en el store porque nunca se borra (a menos que uses nix-collect-garbage). Y como todo cuelga de configuration.nix, esa respuesta al por qué es el archivo mismo.

Cómo se gestiona un paquete en cada uno

Ver el contraste en comandos concretos es la forma más rápida de entender la diferencia. Instalar nginx en ambos sistemas:

# Ubuntu 26.04 LTS — imperativo
sudo apt update
sudo apt install nginx
systemctl status nginx
nginx -v
# → nginx/1.28.0 (Ubuntu 26.04)
# Configuración en /etc/nginx/nginx.conf
# Si quieres revertir: apt remove nginx && apt purge nginx
# Si rompiste algo: reza o restaura desde backup

La versión Ubuntu es directa porque apt es lo que todo sysadmin Debian conoce. Lo instalas, lo configuras en /etc, lo arrancas con systemd. El problema aparece cuando haces apt upgrade tres meses después y nginx se actualiza solo a 1.28.2 porque el LTS lo permite, y tu reverse proxy con config custom queda en estado raro.

# NixOS 26.05 — declarativo
# Primero declaras qué quieres en /etc/nixos/configuration.nix:
#   services.nginx.enable = true;
#   services.nginx.virtualHosts."ejemplo.com" = {
#     listen = [ { port = 443; ssl = true; } ];
#     root = "/var/www/ejemplo";
#   };
# Después aplicás:
sudo nixos-rebuild switch
# → genera /nix/store/abc123-nginx-1.28.0/
# → symlink en /run/current-system/
# → activa la unit systemd que apunta a ese path
# El config vive en /etc/nixos/, versionable con git

La diferencia operativa es grande. En Ubuntu, el estado del sistema es la suma de dpkg + archivos en /etc + bases de datos systemd. Si pierdes el inventario, pierdes el sistema. En NixOS, el estado del sistema es exactamente configuration.nix más un lockfile (flake.lock si usas flakes). Con eso puedes reproducir el mismo servidor en otra máquina en minutos.

Rollback: el feature que justifica todo

El rollback es donde NixOS gana por nocaut técnico. Si después de nixos-rebuild switch algo se rompe, tienes dos opciones inmediatas: reiniciar y elegir la generación anterior en GRUB, o ejecutar nixos-rebuild switch --rollback sin reiniciar. La generación anterior sigue booteable porque nix nunca borró los binarios, solo dejó de apuntar a ellos.

En Ubuntu el equivalente requiere infraestructura externa. La opción histórica es LVM snapshots antes de do-release-upgrade, con riesgo de olvidar uno. La opción moderna es btrfs con timeshift, pero requiere que / esté en btrfs (no es el default de la ISO de Ubuntu). Con ext4 clásico, simplemente no tienes rollback: la actualización es best-effort y si falla, te toca recovery mode y rezar.

Para un sysadmin que actualiza un cluster de 30 servidores Ubuntu, el costo real no es el comando; es la orquestación del rollback. Ansible puede ayudar pero el estado a nivel de paquete sigue siendo opaco.

Cuándo Ubuntu sigue siendo la elección correcta

La elección no es absoluta. Ubuntu 26.04 LTS es la mejor decisión para:

• Servidores en producción que ya están en LTS 22.04 o 24.04 y necesitan un upgrade predecible con 12-15 años de soporte. El ciclo de Ubuntu es el más predecible de toda la industria.
• Workloads con dependencias binarias pesadas que asumen FHS: Oracle, algunas bases de datos propietarias, y software que hace dlopen() de /usr/lib directo sin chequear paths. NixOS pone todo en /nix/store y eso rompe binarios que asumen paths absolutos.
• Equipos de sysadmins con perfil Debian/Ubuntu, donde la curva de aprendizaje de Nix es una semana de capacitación mínima y errores de producción caros. No subestimes esto: una config mal hecha en NixOS puede impedir que el sistema bootee.
• Compliance regulatorio que exige un sistema con soporte comercial directo. Canonical ofrece Ubuntu Pro, Landscape, y contratos de soporte que no tienen equivalente en NixOS.
• Cloud instances: las AMIs oficiales de Canonical en AWS, Azure, GCP y DigitalOcean están afinadas y validadas. NixOS tiene AMIs de comunidad pero no oficiales en todos los clouds.

La ventaja de Ubuntu no es técnica, es operativa. Es lo que tu equipo ya sabe, con el soporte que tu jefe puede defender ante auditoría, sobre el sistema que tu monitoring ya entiende.

Cuándo NixOS brilla (y vale la curva de aprendizaje)

NixOS 26.05 es la mejor decisión para:

• Homelabs y setups de dev/staging/prod donde necesitas reproducir el mismo sistema en 5-50 máquinas. La config se versiona en git y se aplica igual en cada una. Podes tener un branch prod-stable y otro dev-experimental sin riesgos cruzados.
• Servers donde un rollback atómico es requisito de diseño. Sistemas de punto de venta, infraestructura de CI, o cualquier cosa donde un upgrade que rompe no puede quedarse así hasta el lunes.
• Equipos de developers que necesitan entornos reproducibles. nix develop te da un shell con exactamente las versiones de Python, Node y libs que el proyecto requiere, sin contaminar el sistema. Cambias de proyecto y el shell se reconstituye con otras versiones, sin conflictos.
• Workloads inmutables estilo containers pero bare metal. En vez de Docker, puedes correr una app como un servicio Nix aislado, con su propio subset de paquetes y dependencias, y la garantía de que dos deploys idénticos producen binarios idénticos.
• Edge devices y appliances que deben ser reproducibles entre flotas. Con nixpkgs tienes 120 000 paquetes, más que Debian, y la reproducibilidad se mantiene en ARM, RISC-V y x86_64 con la misma config.

La advertencia honesta: NixOS tiene una curva de aprendizaje real. La sintaxis Nix no es Haskell pero tampoco es bash. La evaluación funcional pilla a todos al principio. Y el debugging de errores de configuration.nix requiere entender qué se está evaluando, no solo qué comando falló. Si tu equipo no tiene tiempo de invertir dos semanas en ramp-up, Ubuntu LTS es la decisión sensata.

Cómo migrar un servidor Ubuntu a NixOS (si decides que vale la pena)

No es trivial. No hay un conversor automático de dpkg a Nix. El flujo realista es: levantar un NixOS nuevo con la config que quieres, migrar los datos a mano, validar en paralelo durante dos semanas, y sólo entonces cortar DNS. El proceso en pasos:

# 1. Instala NixOS 26.05 desde minimal ISO
curl -O https://channels.nixos.org/nixos-26.05/latest-nixos-minimal-x86_64-linux.iso
# Verifica SHA-256 contra el publicado en nixos.org
# 2. Configura el sistema en /etc/nixos/configuration.nix
# Importante: services.openssh.enable = true para no perder acceso
# 3. habilita flakes (recomendado para reproducibilidad)
# Editá /etc/nixos/configuration.nix:
#   nix.settings.experimental-features = [ "nix-command" "flakes" ];
# 4. Primer build
sudo nixos-rebuild switch
# 5. Versioná la config en git desde el día uno
cd /etc/nixos
sudo git init
sudo git add .
sudo git commit -m "Initial NixOS 26.05 config"
# Pushea a tu repo privado (GitLab, Gitea, GitHub)

La parte difícil es traducir los paquetes que instalaste con apt install a sus equivalentes en nixpkgs. El proyecto nix-collect-garbage no aplica porque el problema es de modelado, no de storage. La forma práctica es correr dpkg --get-selections | grep -v deinstall en el Ubuntu viejo, mapear cada nombre a su paquete nixpkgs (la mayoría tienen el mismo nombre), y declarar todo en environment.systemPackages. Servicios como nginx, postgresql, redis: cada uno tiene su módulo en NixOS que se habilita con una línea. El resto es config.

Para los secretos, usa sops-nix con age o el módulo agenix, que integran con tu KMS o con un keyring local cifrado. Nunca los pongas en configuration.nix plano: el archivo es legible por todos los procesos que evalúan la config.

Troubleshooting común en ambos mundos

Ubuntu 26.04 troubleshooting frecuente:

# Ver qué paquete provee un archivo
dpkg -S /usr/bin/curl
# Ver por qué un paquete se instaló
apt rdepends --installed nginx
# Limpiar paquetes huérfanos
sudo apt autoremove --purge
# Si un upgrade quedó a medias
sudo dpkg --configure -a
sudo apt install -f
# Forzar versión específica de un paquete
sudo apt install nginx=1.28.0-1ubuntu1
# O pinear en /etc/apt/preferences.d/

NixOS 26.05 troubleshooting frecuente:

# Ver qué generación está activa
nixos-rebuild list-generations
# Buscar un paquete en nixpkgs
nix search nixpkgs postgresql15
# Ver diferencias entre generación actual y la anterior
nix store --query --references /run/current-system
# Rollback inmediato
sudo nixos-rebuild switch --rollback
# Limpiar generaciones viejas (CUIDADO)
sudo nix-collect-garbage --delete-older-than 30d
# Probar config sin aplicar (build sin switch)
sudo nixos-rebuild build
# O probar sin tocar el boot
sudo nixos-rebuild test

La diferencia operativa es clara: en Ubuntu, troubleshooting es buscar logs, revisar dpkg, rezar. En NixOS, el rollback es el primer recurso, no el último. Cuando algo se rompe, vuelves a la generación anterior y después debugueás con tiempo. La presión operativa es radicalmente menor.

Cuándo NO hacerlo

Evita NixOS si:

• Tu software de monitoreo asume paths FHS estándar. Algunas herramientas de APM esperan /usr/bin/python3 o /usr/lib/libssl.so; en NixOS tienes /run/current-system/sw/bin/python3 y /nix/store/.... Configura explícitamente o cámbialo.
• Tu equipo no tiene al menos una persona con dos semanas de tiempo para aprender Nix. La sintaxis es nueva y los errores son crípticos al principio.
• Necesitas soporte comercial directo con SLA. No existe “NixOS Pro” en el sentido de Canonical. La Fundación NixOS existe pero no ofrece contratos.
• Tienes workloads que dependen de binarios pre-compilados con paths absolutos hardcoded. Algunos software propietarios solo funcionan en FHS; NixOS no es FHS por diseño.

Evita Ubuntu si:

• Necesitas reproducibilidad bit-perfect entre máquinas. APT no lo garantiza; dos instalaciones de Ubuntu 26.04 el mismo día pueden terminar con versiones de parches de kernel distintos si no usas un sistema de gestión de configuración encima.
• Quieres rollback atómico sin configurar btrfs o LVM. El default Ubuntu en ext4 no te da nada.
• Tu equipo rota mucho y necesitas un sistema que se describa solo en un archivo. La configuration.nix de NixOS es la documentación; en Ubuntu tienes que escribir Ansible, Puppet, o similar para tener lo mismo.

Veredicto honesto

Si eres sysadmin de un homelab o tienes un setup donde valoras la reproducibilidad y la posibilidad de rollback barato, NixOS 26.05 es la mejor inversión de tiempo que puedes hacer. La curva de aprendizaje es real pero se paga sola en cuanto tienes tres servidores que quieres mantener idénticos.

Si tienes un fleet de Ubuntu 24.04 en producción, migrar a 26.04 LTS es la decisión correcta. Saltar a NixOS en producción sin haberlo usado en homelab durante seis meses es receta para un domingo largo. La promesa declarativa es real, pero requiere que alguien en el equipo la entienda de verdad antes de ponerla en algo que factura.

La mejor decisión para 2026, en orden de seguridad: quédate en Ubuntu 24.04 LTS si ya está en producción y funcionando. Si vas a montar algo nuevo y tienes tiempo, prueba NixOS 26.05 en un homelab o VM primero, y si tu equipo se adapta, úsalo para el próximo deploy. Si necesitas LTS de verdad, Ubuntu 26.04 LTS Resolute Raccoon es el camino más predecible y soportado.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux