Comparativa de Distribuciones Linux 2026: Guía Definitiva para Sysadmins Hispanohablantes

Llevo dos años manteniendo una spreadsheet con los pros y contras de cada distribución para distintos casos de uso: workstations de devs, servidores de base de datos, appliances de red, edge computing, kioskos. Cada vez que un cliente me preguntaba “¿qué distro pongo para X?” abría el spreadsheet, lo actualizaba, y mandaba una respuesta de 30 minutos. Esta guía es la versión pública de ese spreadsheet, con el criterio que uso y los benchmarks reales que importan: tiempos de actualización, soporte a largo plazo, performance de I/O, footprint de memoria, y la disponibilidad real de paquetes en los repos oficiales.

Si tienes que elegir una distro para algo serio en 2026, esta guía te ahorra 6 meses de probar y equivocarte.

---

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

Hace una década la pregunta era simple: ¿Debian estable o Ubuntu LTS? Hoy esa decisión esconde variables 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. Si despliegas Fedora Silverblue 43 en un fleet de kioskos, cada equipo arranca el mismo OSTree bit-por-bit.

El espacio de distribuciones Linux en 2026 es más diverso que nunca. Debian 13 compite con LTS en capas de release. Ubuntu 26.04 LTS Resolute Raccoon redefine qué esperar de un LTS de Canonical. Fedora 43 y 44 consolidan DNF 5 y la familia Atomic. RHEL 10 cambió el ciclo de soporte a diez años. Arch sigue siendo la frontera rolling. openSUSE Leap 16 adoptó SUSE ALP como base. NixOS 26.05 sigue siendo el único competidor serio del modelo declarativo funcional. Elegir mal significa pagar la diferencia en horas de operación durante los próximos cinco años.

Esta guía es para sysadmins que administran entre uno y doscientos servidores o nodos edge y necesitan decidir con datos cuál distribución sirve para qué escenario. Es una comparativa lado a lado con comandos reales, datos verificados contra fuentes primarias, y la honestidad de admitir cuándo cada distro es la elección equivocada.

Tabla comparativa lado a lado

Dimensión	Debian 13 Trixie	Ubuntu 26.04 LTS	Fedora 43/44	RHEL 10	Arch Linux	openSUSE Leap 16	NixOS 26.05
Modelo de release	Fijo (point releases)	Fijo (LTS 5/10/15 años)	Fijo (cada 6 meses)	Fijo (10 años soporte)	Rolling	Fijo (24 meses)	Fijo (cada 6 meses)
Paquetería base	.deb + APT + dpkg	.deb + APT + dpkg + snap	.rpm + DNF 5 + RPM 6	.rpm + DNF + RPM	.pkg.tar.zst + pacman	.rpm + zypper	Nix store + flake
Kernel	6.12 LTS	7.0 (GNOME 50)	6.16 / 6.17 según versión	6.12 (10.0), 6.16 (10.1)	Siempre el último estable	6.12 LTS base	Configurable por generación
Soporte de seguridad	~3 años LTS + ~2 años extra	5 desktop / 10 servidor / 15 Pro	13 meses por release	10 años (Full + Maintenance)	Continuo (rolling)	24 meses	6 meses por release estable
Atomicidad de upgrades	No garantizada (best-effort)	Limitada (LVM snapshots, btrfs opcional)	Sí (Atomic Desktops + CoreOS)	Limitada (rpm-ostree opcional)	No (parcial por paquete)	Limitada (btrfs snapshots)	Sí (cada generación booteable)
Rollback completo	No nativo (requiere snapshot externo)	Limitado (btrfs/LVM)	Sí en Atomic, no en Workstation	Limitado (rpm-ostree)	No nativo	Limitado (snapper)	Por diseño (GRUB + nixos-rebuild)
Soporte comercial	No directo (solo terceros)	Sí (Ubuntu Pro, Landscape)	No (comunidad)	Sí (Red Hat directo + partners)	No	Limitado (SUSE para empresa)	No (Determinate Systems ofrece flakes)
Curva de aprendizaje	Baja si vienes de Ubuntu	Cero para Debian/Ubuntu	Media (DNF 5 reciente)	Media (subscription-manager)	Alta (manual, hay que saber)	Media-alta (zypper + YaST)	Alta (sintaxis Nix, modelo funcional)
Tamaño ISO servidor	~750 MB (netinst)	~2.8 GB (server ISO)	~2.0 GB (Server)	~4.5 GB (boot + 8 GB DVD)	~900 MB (netinst)	~1.2 GB (DVD)	~1.4 GB (minimal)
Compatibilidad FHS	100%	100%	100%	100%	100%	100%	No (binarios en /nix/store)
Post-quantum crypto	Parcial (paquetes individuales)	Sí (TLS/SSH PQ por default)	Parcial (OpenSSL upstream)	Sí (kernel + OpenSSL)	Parcial (paquetes individuales)	Parcial	Depende de la app
Inmunidad release	No (inmutable)	No	Sí (variantes Atomic)	No (Workstation/Server)	No	No	Sí (Nix store inmutable)

La tabla es un mapa rápido. Las decisiones reales dependen del caso de uso, no de la cantidad de checks en la columna. Las siguientes secciones desgranan los proyectos y dónde cada uno brilla o falla.

Qué cambió en cada proyecto en 2025-2026

Antes de comparar filosofías, conviene ver qué hay en el plato ahora mismo. Esta sección resume los movimientos reales de cada proyecto en los últimos doce meses, verificados contra notas de release oficiales.

Debian 13 Trixie se publicó el 9 de agosto de 2025 como la nueva stable tras casi dos años en testing. El cambio más visible: kernel 6.12 LTS en lugar de 6.1 que traía Bookworm, repositorio non-free-firmware consolidado para evitar la fragmentación con non-free, main y contrib. La release 13.7 salió el 12 de septiembre de 2026 sumando parches de seguridad y soporte acumulado de hardware nuevo. El ciclo Debian sigue siendo predecible: dos años en testing, dos años como stable soportada, dos años en LTS, y alrededor de cinco años de soporte total.

Ubuntu 26.04 LTS Resolute Raccoon salió el 23 de abril de 2026 como el undécimo LTS de la historia. Lo grande: kernel Linux 7.0, GNOME 50 sin X11 (solo Wayland con XWayland para apps legacy), reemplazo total de coreutils GNU por la implementación en Rust uutils, TPM-backed full disk encryption estable, y soporte de Livepatch para servidores ARM. La promesa de Canonical: 5 años desktop, 10 años servidor, 15 años con Ubuntu Pro.

Fedora 43 salió el 28 de octubre de 2025 consolidando DNF 5 como reemplazo maduro de DNF 4, RPM 6 con foco en seguridad y firma, y Anaconda rediseñado. Fedora 44 llegó el 28 de abril de 2026 reforzando los Atomic Desktops (KDE Kinoite, GNOME Atomic, Budgie) y mejorando Fedora CoreOS para clusters Kubernetes. Fedora sigue siendo el conejillo de indias de Red Hat: lo que aterriza en Fedora hoy aparece en RHEL mañana con 18-24 meses de estabilización.

RHEL 10 se anunció el 20 de mayo de 2025 en Red Hat Summit con kernel 6.12, y 10.1 en noviembre del mismo año subió a kernel 6.16. Lo notable: soporte total de 10 años hasta 2035 (Full Support hasta 2030, Maintenance Support hasta 2035), arquitectura Image Mode para despliegues inmutables estilo CoreOS pero con la base RHEL, y Podman 5 con compose support nativo. Para empresas con compliance estricto, RHEL sigue siendo el camino más simple porque el vendedor firma los SLAs.

Arch Linux sigue siendo rolling release con ISO actualizada mensualmente. Lo nuevo en 2025-2026: el repo extra consolidado, mkinitcpio 42 con hook systemd-cryptsetup TPM2 oficial, y la guía oficial actualizada para reflejar el flujo moderno con archinstall. Arch no compite con Debian o Ubuntu; ocupa el nicho de quien quiere el último kernel, los últimos drivers, y está dispuesto a leer la wiki cuando algo se rompe.

openSUSE Leap 16 salió en octubre de 2025 basado en SUSE Linux Framework One (antes ALP). El cambio radical: en lugar de heredar de SUSE Linux Enterprise, Leap ahora consume el mismo código base ALP que SUSE Linux Enterprise Server 16. Soporte comunitario de 24 meses, el más largo entre distros de comunidad.

NixOS 26.05 Yarara salió el 30 de mayo de 2026 con 85 módulos nuevos, 1.547 opciones de configuración nuevas. El más relevante para sysadmins sigue siendo systemd stage 1 como initrd por default, lo que acerca NixOS al modelo de arranque de Fedora y Ubuntu. 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 modelo de paquetes y la atomicidad: por qué el imperativo se rompe al escalar

El flujo Debian/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 solo 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.

El flujo Fedora/RHEL clásico sigue la misma idea con RPM: dnf update reemplaza el paquete en /usr/lib64/, los state del sistema son la suma de RPM + archivos en /etc + bases de datos systemd. Si pierdes el inventario, pierdes el sistema. Las herramientas que la industria inventó para tapar este hueco son evidencia de que el modelo base no lo resuelve: mosh, etckeeper, unattended-upgrades, apticron, timeshift, btrfs-assistant, snapshots LVM automáticos.

Las distribuciones que rompieron este patrón son tres: NixOS con su Nix store funcional, Fedora con la familia Atomic (CoreOS, Kinoite, BUDGIE) usando OSTree, y openSUSE con btrfs + snapper integrado en Leap 16. Cada una resuelve el problema desde un ángulo diferente, y las tres son válidas para casos diferentes.

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, la respuesta al por qué de cada pieza del sistema es el archivo mismo.

Fedora Atomic resuelve el problema desde el lado del despliegue. Cada sistema arranca desde una imagen base firmada, versionada y reproducible. Un cambio defectuoso se revierte con rpm-ostree rollback y un reinicio. La diferencia con NixOS es filosófica: NixOS hace declarativo el estado, Atomic hace reproducible la imagen. Ambos logran rollback, ambos versionan, pero el modelo mental es distinto. Para un sysadmin que viene de Fedora Server clásico, Atomic se siente más natural que Nix.

Caso de uso: servidor en producción

Para un servidor que va a facturar durante los próximos cinco a diez años, la decisión se reduce a tres variables: ciclo de soporte, estabilidad de paquetes, y disponibilidad de soporte comercial.

Ubuntu 26.04 LTS es la elección obvia si necesitas 10-15 años de soporte, soporte comercial opcional con Ubuntu Pro, y la familiaridad del ecosistema Debian. La LTS de Canonical es la distro de servidor con más preguntas resueltas en Stack Overflow, más scripts de monitoreo ya escritos, y más experiencia acumulada en la industria. El costo: pagas la decisión a Canonical en flexibilidad. Si quieres algo que no esté en repos universe, vas a pelear.

Debian 13 Trixie es la elección obvia si quieres estabilidad de paquetes sin pagar a nadie. El ciclo de release de Debian es predecible: dos años en testing, dos años stable soportada, dos años en LTS. Para un homelab o un servidor personal, Debian te da el mismo software que Ubuntu LTS pero con tres a seis meses más de retraso, lo que en práctica significa menos bugs introducidos por prisas de release. Para producción crítica donde pagas por disponibilidad, Ubuntu Pro o RHEL paga contra tu riesgo.

RHEL 10 es la elección correcta si tienes compliance estricto (PCI-DSS, HIPAA, FedRAMP), necesitas un SLA firmado por el vendedor, o tu auditor te pide un sistema con vendedor responsable. RHEL 10 viene con 10 años de soporte, modo Image para despliegues inmutables, y acceso al catálogo certificado de Red Hat. El costo: pagar si las sabes por suscripción, y aceptar que algunas cosas demoran más que en Fedora upstream porque Red Hat valida antes de publicar.

Fedora Server 43/44 rara vez es la elección correcta para producción de largo plazo porque su ciclo de 13 meses es demasiado corto. Fedora Server brilla en homelab, en infraestructura descartable (CI runners, builds de containers), o en stage donde quieres ver qué viene en RHEL mañana. Para producción real, RHEL paga el costo del soporte, Fedora Server paga el costo de la reinstalación cada año.

Caso de uso: workstation del sysadmin

Para el escritorio donde trabajas ocho horas al día, las prioridades son distintas: lo último en drivers, el kernel más reciente, y un desktop que no se rompa a mitad de una demo. Aquí Fedora y Arch lideran, Ubuntu sigue siendo el más conservador, y openSUSE tiene un nicho real con Plasma.

Fedora Workstation 43/44 es la elección técnica por defecto si quieres GNOME o KDE modernos, drivers actualizados al día, y la certeza de que cualquier cosa que tu laptop necesite (WiFi nuevo, GPU última generación, fingerprint reader) ya está en el kernel 6.16/6.17 que trae Fedora. La paquetería es RPM con DNF 5; si vienes de Debian, hay que reaprender el flujo. Una vez aprendido, DNF es más rápido que APT en resolución de dependencias, y el repositorio RPM Fusion añade lo que Fedora deja fuera por filosofía.

Arch Linux es la elección correcta si quieres entender cada pieza de tu sistema y estás dispuesto a leer la wiki cuando algo se rompe. Arch no te esconde nada: cada decisión la tomas tú, cada paquete lo instalas tú, cada upgrade lo haces tú. La ventaja: tu sistema es exactamente lo que tú quieres que sea, sin capas de magia Canonical o Red Hat por encima. La desventaja: cuando un paquete rompe a otros, la responsabilidad es tuya.

Ubuntu 26.04 LTS Desktop es la elección correcta si tu laptop es vieja o tu hardware es conservador (Lenovo ThinkPad, Dell Latitude, HP ProBook), quieres que todo funcione desde el primer boot, y puedes esperar 6-12 meses para tener el último driver propietario. Ubuntu Desktop sigue siendo la distribución con mejor soporte out-of-the-box para hardware empresarial, lo que la hace ideal para sysadmins que cargan la laptop entre cliente y oficina.

openSUSE Leap 16 con Plasma 6 es la elección correcta si vienes de KDE 4 o 5 y no quieres abandonar el desktop. openSUSE tiene la mejor integración de YaST (su herramienta de configuración histórica) con Plasma, y Leap 16 hereda de SUSE Linux Framework One lo que le da estabilidad de servidor al desktop.

Caso de uso: homelab + reproducibilidad

Si tienes un homelab con cinco a cincuenta nodos, o quieres reproducir el mismo sistema en varias máquinas, la decisión cambia. Aquí NixOS brilla por diseño, y Fedora Atomic es la alternativa pragmática.

NixOS 26.05 es la mejor inversión de tiempo que puedes hacer si valoras la reproducibilidad. El flujo realista: declaras tu configuration.nix una vez, lo versionas en git, y lo aplicas en cada máquina con nixos-rebuild switch --flake .#hostname. El mismo archivo produce el mismo sistema bit-por-bit en una laptop, un servidor x86_64 y un Raspberry Pi. Para sysadmins con tiempo de invertir dos a cuatro semanas aprendiendo Nix, el retorno es enorme en cuanto tienes tres o más hosts.

Fedora CoreOS / Fedora Silverblue / Fedora Kinoite es la alternativa pragmática si quieres reproducibilidad sin aprender Nix. Cada host arranca desde una imagen firmada, versionada y reproducible. Provisionas con Ignition (en CoreOS) o con un Ansible que aplica sobre la imagen. La limitación es que el modelo mental es de despliegue de imagen, no de declaración funcional: dos instalaciones en la misma fecha pueden terminar con parches de kernel distintos si Fedora publica un update entre el boot de la primera y la segunda.

Caso de uso: clouds y containers

Para correr en AWS, GCP, Azure o DigitalOcean, la decisión suele ya estar tomada: usas la AMI/cloud image oficial del vendor. Ubuntu LTS, RHEL, Debian, Fedora, openSUSE y Rocky/Alma tienen imágenes oficiales firmadas en todos los clouds serios. La elección entre ellas depende más del equipo y el soporte que del cloud en sí.

Ubuntu LTS cloud images son las más afinadas por Canonical: kernel optimizado para el cloud, cloud-init preconfigurado, repos restringidos a lo que necesitas. Para una startup que va a mover cargas de un cloud a otro, Ubuntu LTS cloud es el camino más predecible.

Fedora CoreOS está optimizado para correr Kubernetes y containers con Ignition como provisionador. Si tu fleet son nodos K8s, CoreOS te da auto-update con rollback, ignition reproducible, y la garantía de que cada nodo arranca idéntico. Red Hat usa CoreOS como base de OpenShift, así que el camino a producción es directo.

RHEL 10 con Image Mode es la elección correcta si ya tienes RHEL en producción y quieres extender a un cluster containerizado. La integración con Podman 5 y la familia Image Mode te permite declarar imágenes con Containerfile y promoverlas entre dev/stage/prod sin reescribir.

Cómo elegir — flujo de decisión

Si todo lo anterior te abrumó, este es el flujo de decisión mínimo que cubre el 90% de los casos. Aplícalo en orden:

1. ¿Necesitas soporte comercial con SLA firmado? Sí, RHEL 10 o Ubuntu Pro. No, sigue.
2. ¿Necesitas más de 5 años de soporte sin pagar? Sí, Ubuntu 26.04 LTS (10 servidor) o Debian 13 + plan de migración a 14. No, sigue.
3. ¿Tu equipo ya viene de Debian/Ubuntu y no quiere reaprender? Sí, Debian 13 o Ubuntu 26.04 LTS. No, sigue.
4. ¿Necesitas el último kernel y drivers de paquetes en cada release? Sí, Arch o Fedora. No, sigue.
5. ¿Tienes cinco o más hosts donde quieres el mismo sistema? Sí, NixOS o Fedora Atomic. No, sigue.
6. ¿Tu hardware es conservador y necesita máximo tiempo sin driver nuevo? Sí, Debian 13 o Ubuntu 26.04 LTS. No, sigue.

Cuando el flujo te da más de una opción, la decisión final suele ser política del equipo: si todos saben RHEL, quédate con RHEL aunque Ubuntu sea técnicamente equivalente. La mejor distribución es la que tu equipo sabe operar.

Setup rápido para los finalistas

Una vez elegida la distribución, este es el camino de instalación mínimo para llegar a un servidor funcional. Los comandos son reales y verificados contra la documentación oficial de cada proyecto.

Debian 13 Trixie — netinst

# Descarga ISO netinst (solo arranca, baja el resto desde repos)
wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.0.0-amd64-netinst.iso
# Verifica SHA-256 contra el publicado en debian.org/CD/http-ftp/
sha256sum debian-13.0.0-amd64-netinst.iso
# Crea USB booteable (Linux)
dd if=debian-13.0.0-amd64-netinst.iso of=/dev/sdX bs=4M status=progress oflag=sync
# Boot, selecciona "Install", hostname, particionado LVM + ext4, y SSH server
sudo apt update && sudo apt upgrade -y
sudo apt install -y sudo vim htop curl wget git
# Agregar usuario al grupo sudo
sudo usermod -aG sudo tuusuario

El install es directo: DHCP, hostname, particionado automático (o manual con LVM si vas a producción), mirror (usa deb.debian.org por default). Lo único que cambia Debian 13 vs Bookworm: el instalificador detecta non-free-firmware automáticamente y carga lo requerido para tu WiFi/GPU sin pedir confirmación.

Ubuntu 26.04 LTS — server ISO

# Descarga server ISO
wget https://releases.ubuntu.com/26.04/ubuntu-26.04-live-server-amd64.iso
# USB booteable (Linux)
dd if=ubuntu-26.04-live-server-amd64.iso of=/dev/sdX bs=4M status=progress oflag=sync
# Boot, subiquity te pregunta:
#   - Storage: LVM + ext4 (recomendado para producción)
#   - Profile: server (sin snap de escritorio)
#   - Featured snaps: deja solo el default
# Después del primer boot
sudo apt update && sudo apt upgrade -y
sudo snap install --classic lxd   # opcional para LXC
sudo pro attach --attach  # solo si tienes Ubuntu Pro

Ubuntu Pro agrega 5 años más de soporte y acceso a esm-apps y esm-infra (paquetes que solo están en Pro). Si tienes máquinas en producción crítica, Pro paga el costo.

Fedora 43 Server — netinst

# Descarga Fedora Server netinst
wget https://download.fedoraproject.org/pub/fedora/linux/releases/43/Server/x86_64/iso/Fedora-Server-netinst-x86_64-43-1.4.iso
# USB booteable
dd if=Fedora-Server-netinst-x86_64-43-1.4.iso of=/dev/sdX bs=4M status=progress oflag=sync
# Boot, Anaconda te pregunta destino de instalación
# Después:
sudo dnf install -y vim htop curl wget git
sudo systemctl set-default multi-user.target  # asegurar que no inicia GUI

Fedora 43 trae DNF 5 por default. La migración de scripts de DNF 4 a 5 es trivial: dnf install sigue funcionando igual, los --enablerepo cambian a --repo, y dnf autoremove reemplaza a yum autoremove.

RHEL 10 — boot ISO

# Descarga boot ISO desde el portal de Red Hat (requiere login)
# O usa el DVD ISO si tienes espacio
# Boot, Anaconda:
#   - Subscription: pega tu activation key
#   - Destino: particionado LVM o automático
# Después:
sudo subscription-manager register --username=tu_usuario --password=tu_pass
sudo subscription-manager attach --auto
sudo dnf install -y vim htop curl wget git
sudo systemctl set-default multi-user.target

Si no tienes suscripción RHEL, usa Rocky Linux 10 o AlmaLinux 10, los clones binarios 1:1. Rocky Linux 10 Red Quartz salió el 14 de junio de 2025 y es mantenido por la comunidad.

Arch Linux — netinst con archinstall

# Descarga ISO
wget https://geo.mirror.pkgbuild.com/iso/latest/archlinux-x86_64.iso
# USB booteable
dd if=archlinux-x86_64.iso of=/dev/sdX bs=4M status=progress oflag=sync
# Boot, en el primer prompt:
archinstall
#   - Mirror: cualquiera cerca (default OK)
#   - Locale: es_ES.UTF-8 (o el que necesites)
#   - Disk: particionado automático o manual
#   - Bootloader: systemd-boot o GRUB
#   - Profile: minimal (sin GUI), o desktop si la necesitas
# archinstall hace el resto, instala GRUB/systemd-boot, configura red
sudo pacman -Syu   # primer upgrade tras instalar

Archinstall reemplaza el método manual histórico. Si vienes de Arch manual, sigue funcionando; archinstall es la opción recomendada para nuevos usuarios. La wiki oficial sigue siendo tu referencia cuando algo se rompe.

NixOS 26.05 — minimal ISO

# Descarga ISO minimal
wget https://channels.nixos.org/nixos-26.05/latest-nixos-minimal-x86_64-linux.iso
# USB booteable
dd if=latest-nixos-minimal-x86_64-linux.iso of=/dev/sdX bs=4M status=progress oflag=sync
# Boot, login root sin password
# Particionado manual si no quieres el automático
sudo fdisk /dev/sda   # o parted
sudo mkfs.ext4 -L nixos /dev/sda1
sudo mount /dev/sda1 /mnt
sudo nixos-generate-config --root /mnt
sudo nix-channel --add https://nixos.org/channels/nixos-26.05
sudo nix-channel --update
# Editá /mnt/etc/nixos/configuration.nix:
#   services.openssh.enable = true;
#   networking.hostName = "mi-servidor";
sudo nixos-install
sudo reboot

La parte difícil es traducir los paquetes que quieres a sus equivalentes en nixpkgs. El mapeo es 1:1 para la mayoría (nginx, postgresql, redis) y la wiki oficial tiene un buscador de paquetes en search.nixos.org.

Troubleshooting común

Después del setup, los problemas frecuentes son predecibles. Estos comandos cubren el 90% de los casos que vas a encontrar en producción.

Debian/Ubuntu 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
sudo apt install nginx=1.28.0-1ubuntu1
# Pinear en /etc/apt/preferences.d/
# Ver logs de postinst fallido
sudo cat /var/log/apt/term.log | tail -50

Fedora/RHEL troubleshooting frecuente

# Ver qué paquete provee un archivo
rpm -qf /usr/bin/curl
# Ver por qué un paquete se instaló
dnf repoquery --installed --whatrequires nginx
# Limpiar paquetes huérfanos
sudo dnf autoremove
# Si un upgrade quedó a medias
sudo dnf distro-sync
# Forzar versión específica
sudo dnf install nginx-1.28.0-1.fc43
# Ver logs
sudo cat /var/log/dnf.log | tail -50

Arch troubleshooting frecuente

# Ver qué paquete provee un archivo
pacman -Qo /usr/bin/curl
# Ver por qué un paquete se instaló (dependencias)
pacman -Qi nginx | grep "Required By"
# Si un upgrade falló por firma GPG
sudo pacman-key --refresh-keys
sudo pacman -Sy archlinux-keyring && sudo pacman -Su
# Limpiar caché de paquetes
sudo paccache -r   # conserva últimas 3 versiones
# Forzar downgrade
sudo pacman -U /var/cache/pacman/pkg/nginx-1.27-victima.pkg.tar.zst

NixOS troubleshooting frecuente

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

Cuándo NO migrar

Evita migrar solo porque la nueva distribución tiene features llamativos. Las migraciones cuestan tiempo, riesgos y horas de operación. Estas son las situaciones donde quedarse donde estás es la decisión correcta:

• Tu software de monitoreo asume paths FHS estándar. Algunas herramientas de APM esperan /usr/bin/python3 o /usr/lib/libssl.so. NixOS vive en /nix/store, y eso rompe binarios que asumen paths absolutos. Configura explícitamente o cámbialo.
• Tu equipo no tiene al menos dos semanas para aprender una distro nueva. Saltar a NixOS o Arch sin rampa de aprendizaje es receta para un domingo largo de troubleshooting. La sintaxis Nix no es Haskell pero tampoco es bash. Si no tienes tiempo de invertir, quédate con lo que sabes.
• Necesitas soporte comercial directo con SLA firmado. No existe “NixOS Pro” ni “Arch Pro”. Si tu CTO necesita un SLA para pasar auditoría, la respuesta es RHEL o Ubuntu Pro, no Debian o NixOS.
• Tienes workloads que dependen de binarios pre-compilados con paths hardcoded. Oracle, algunas bases de datos propietarias, y software que hace dlopen() de /usr/lib directo asumen FHS. NixOS no es FHS por diseño, Atomic cambia paths, y la respuesta es quedarte en Ubuntu LTS o Debian.
• Tu hardware es muy viejo o muy nuevo. Si tu servidor tiene quince años, Debian o CentOS Stream 9 mantienen mejor el soporte. Si tu hardware es del último trimestre, Fedora o Arch te dan el driver antes. Ubuntu LTS va siempre atrás del kernel upstream por 6-12 meses.

Veredicto honesto

Si eres sysadmin de un homelab o tienes un setup donde valoras la reproducibilidad, 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. Atomic Fedora es el segundo lugar si quieres reproducibilidad sin aprender Nix.

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

Si tu requisito es compliance estricto y soporte comercial, RHEL 10 (o Alma/Rocky 10 si el presupuesto es dinero) es el camino más predecible. Ubuntu Pro compite si tu equipo ya sabe Ubuntu. Las distros de comunidad (Debian, Fedora, openSUSE, Arch, NixOS) tienen soporte comercial a través de terceros, no del fabricante, y eso cambia la conversación con auditores.

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, y planifica la actualización a 26.04 LTS para Q3-Q4 2026. Si vas a montar algo nuevo y tienes tiempo, prueba NixOS 26.05 o Fedora Atomic 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. Si necesitas compliance, RHEL 10 con su ciclo de 10 años.

Lo que nunca falla: la distribución correcta es la que tu equipo sabe operar y la que tiene comunidad activa para responder cuando algo se rompe a las tres de la mañana. Las modas pasan, los años de soporte corren, y la mejor distro es la que documenta tu decisión para el sysadmin que viene detrás.

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