Cuando instalas Kali Linux para hacer pruebas de seguridad, Proxmox para virtualización, o Raspberry Pi OS en una placa, estás usando Debian. No una versión modificada sin relación, sino un sistema que hereda directamente la infraestructura de paquetes, las políticas de empaquetado y los repositorios de Debian. Entender por qué ocurre esto te da una visión del ecosistema Linux que no obtienes de otra forma.
Debian es una distribución Linux mantenida íntegramente por voluntarios organizados bajo el Proyecto Debian desde 1993. Lo que la distingue técnicamente no es un componente aislado, sino la combinación de varios factores que, juntos, hacen que construir sobre Debian sea más barato y fiable que partir de cero.
Por qué se construye sobre Debian y no sobre otra cosa
El primer factor es APT/dpkg, el sistema de gestión de paquetes. dpkg es la herramienta de bajo nivel que instala, desinstala y registra paquetes .deb. apt es la capa superior que resuelve dependencias, descarga desde repositorios y coordina todo. Este stack lleva décadas de uso en producción real, y eso se nota: los casos límite —dependencias circulares, actualizaciones parciales, paquetes retenidos— están documentados, tienen solución conocida, y el comportamiento es predecible. RPM y su ecosistema son perfectamente válidos, pero APT/dpkg tiene una base de documentación y comportamiento consolidado que es difícil de igualar.
El segundo factor es la Política de Debian (Debian Policy Manual). No es un documento de marketing; es una especificación técnica que define cómo debe comportarse cada paquete: dónde van los binarios, cómo se escriben los scripts de instalación (preinst, postinst, prerm, postrm), cómo se gestionan los ficheros de configuración, qué significa que un paquete sea “esencial”. Cuando una distribución derivada hereda miles de paquetes de Debian, hereda también esa consistencia. Un mantenedor de Kali o de Ubuntu no tiene que especificar cómo debe comportarse nginx al instalarse: ya está definido por la política, y el paquete ya la cumple.
El tercer factor es el tamaño del repositorio. Debian Bookworm tiene más de 60.000 paquetes binarios. Ningún equipo pequeño puede construir ese catálogo desde cero. Cuando una empresa decide crear una distribución especializada —un sistema de virtualización, un entorno de análisis forense, un SO para dispositivos embebidos— lo que necesita es ese catálogo como punto de partida y añadir o modificar lo que necesita para su caso de uso concreto. Partir de Debian les da acceso inmediato a ese repositorio sin coste de mantenimiento propio.
El cuarto factor es el soporte multi-arquitectura. Debian soporta de forma oficial amd64, arm64, armhf, i386, mips64el, ppc64el, s390x, y otras. Raspberry Pi OS puede existir sobre Debian porque Debian ya compila y mantiene paquetes para ARM. Proxmox corre en servidores amd64 porque esa arquitectura está perfectamente soportada. La distribución derivada no tiene que resolver el problema de la compilación cruzada para sus paquetes base: Debian ya lo ha hecho.
El quinto factor, menos visible pero fundamental, es el ciclo de estabilidad. Debian Stable tiene un ciclo de soporte largo con actualizaciones de seguridad garantizadas. Cuando una empresa construye un producto sobre Debian Stable, sabe que el sistema base no va a cambiar de forma disruptiva durante años. Eso es lo que necesitas cuando vendes un appliance o mantienes infraestructura en producción: una base predecible sobre la que puedes comprometerte con tus propios usuarios.
“Basada en Debian” frente a “basada en Ubuntu”
Esta distinción importa y a menudo se confunde. Hay distribuciones que derivan directamente de Debian y hay distribuciones que derivan de Ubuntu, que a su vez deriva de Debian. No es lo mismo.
Ubuntu toma una instantánea de Debian (principalmente unstable y testing), añade sus propios paquetes y herramientas, y publica versiones con su propio ciclo. Las distribuciones basadas en Ubuntu —Linux Mint, Pop!_OS, elementary OS, Zorin— heredan tanto la infraestructura Debian como las modificaciones de Ubuntu: snap, cloud-init, netplan, Upstart (en versiones antiguas), y otros componentes propios de Canonical. Cuando algo falla en esas distros, el problema puede estar en Debian, en Ubuntu, o en la distro final.
Las distribuciones basadas directamente en Debian —Kali, Proxmox VE, Raspberry Pi OS, MX Linux, Devuan, Tails— tienen una cadena de dependencias más corta. Si hay un bug en un paquete base, hay un lugar claro donde buscarlo y donde reportarlo.
La diferencia práctica: si administras servidores con Debian y te contratan para mantener un sistema basado en Proxmox, el conocimiento se transfiere casi directamente. Si el sistema está basado en Ubuntu, hay una capa adicional de diferencias que necesitas conocer.
Un ejemplo concreto: qué hereda un derivado
Vamos a ver qué recibe una distribución cuando decide basarse en Debian Stable. El siguiente bloque muestra cómo inspeccionar la infraestructura que Debian aporta y que cualquier derivado recibe de forma directa:
# Ver la versión de Debian y su nombre en clave cat /etc/debian_version # 12.x — Bookworm # Ver el origen de los paquetes instalados en el sistema # apt-cache policy muestra de qué repositorio viene cada paquete apt-cache policy dpkg # La salida muestra la versión instalada y los candidatos disponibles # con su origen (archive.debian.org, security.debian.org, etc.) # Ver cuántos paquetes hay disponibles en los repositorios configurados apt-cache stats | grep "Paquetes totales" # En una instalación estándar con main+contrib+non-free: >60.000 # Inspeccionar la política de un paquete bien empaquetado # Los scripts de instalación siguen la Debian Policy sin excepción dpkg --status nginx | grep -E "^(Package|Version|Architecture|Maintainer|Depends)" # Ver todas las arquitecturas soportadas en este sistema dpkg --print-architecture # arquitectura nativa dpkg --print-foreign-architectures # arquitecturas adicionales habilitadas # Habilitar arm64 en un sistema amd64 (lo que permite instalar paquetes # de otra arquitectura, técnica usada en desarrollo para embebidos) # sudo dpkg --add-architecture arm64 # sudo apt update # Con esto puedes instalar paquetes :arm64 junto a los :amd64 nativos # Ver los scripts de mantenimiento de un paquete para entender # cómo la Policy garantiza comportamiento consistente dpkg --listfiles openssh-server | grep "^/var\|^/etc" # Verás que los ficheros de configuración están exactamente donde # la Policy indica: /etc/ssh/, los logs en /var/log/, etc. # Consultar el changelog de un paquete — documentación incluida apt changelog openssh-server 2>/dev/null | head -30 # Cada entrada está firmada por el mantenedor y sigue formato estándar
Qué significa cada decisión en ese bloque
apt-cache policy dpkg no es un comando de diagnóstico trivial: muestra la cadena de confianza completa, desde el repositorio firmado con GPG hasta el paquete instalado. Cuando una distribución derivada crea sus propios repositorios, replica exactamente esta infraestructura. La firma GPG de los repositorios de Debian es uno de los mecanismos de seguridad que los derivados heredan automáticamente si no la rompen.
dpkg --print-foreign-architectures revela el soporte multi-arch. En una instalación limpia de Debian amd64 la salida estará vacía, pero la infraestructura para añadir arquitecturas está disponible con un solo comando. Raspberry Pi OS usa exactamente esto: compila paquetes armhf y arm64 con la misma infraestructura que Debian usa para amd64. No hay una versión especial de dpkg para ARM; es el mismo dpkg.
dpkg --listfiles openssh-server demuestra la consistencia que da la Policy. Los ficheros están donde deben estar, sin excepciones. Eso significa que un administrador que sabe dónde busca Debian los ficheros de configuración sabe dónde buscarlos en Kali, en Raspberry Pi OS, y en cualquier derivado que no haya roto esa convención.
apt changelog ilustra algo que se subestima: la documentación de cada cambio en cada paquete es parte del sistema, no un extra opcional. Cuando actualizas openssh-server en producción y algo cambia de comportamiento, el changelog te explica exactamente qué cambió y por qué. Esa cultura de documentación es parte de lo que hace a Debian confiable como base.
La última implicación importante: todo lo que aprendes sobre Debian —cómo funcionan los repositorios, cómo gestionar paquetes, dónde están los ficheros de configuración, cómo leer los logs con journalctl— es conocimiento que se transfiere directamente a la mitad del ecosistema Linux. No es conocimiento de nicho; es el denominador común más amplio que existe en el mundo Linux de servidores y dispositivos embebidos.