El kernel Linux por sí solo no sirve para gran cosa en el día a día. Es el núcleo del sistema operativo —gestiona la memoria, los procesos, el hardware— pero no incluye un editor de texto, un gestor de paquetes, ni siquiera un intérprete de comandos. Para tener algo usable hay que añadir cientos de piezas encima. Una distribución (o distro) es exactamente eso: alguien tomó el kernel, lo combinó con las herramientas GNU (el compilador, la shell, los comandos básicos como ls o cp), un gestor de paquetes para instalar y actualizar software, una configuración por defecto razonable, y tomó miles de decisiones de diseño —qué sistema de inicio usar, qué versiones de las bibliotecas incluir, cómo estructurar los directorios de configuración— y lo empaquetó todo junto con un nombre y un propósito claro.
Por eso existen cientos de distribuciones: cada una representa un conjunto diferente de decisiones. Debian elige estabilidad y tiempo de prueba de los paquetes por encima de tener la versión más reciente. Fedora apuesta por incluir software nuevo y sirve como campo de pruebas para Red Hat Enterprise Linux. Arch te da el sistema casi vacío y asumes tú todas las decisiones de configuración. Una distribución orientada a servidores tomará decisiones distintas sobre qué demonios arrancar por defecto que una orientada al escritorio. Ninguna es incorrecta; responden a filosofías y públicos objetivo distintos.
Lo que sí importa entender es que el conocimiento es mayoritariamente transferible. Los conceptos de permisos de ficheros, la jerarquía de directorios, el funcionamiento de los procesos, las señales, la red: todo eso viene del kernel y de los estándares POSIX, y funciona igual en todas partes. Lo que cambia entre familias es sobre todo el gestor de paquetes (apt en Debian, dnf en Fedora/RHEL, pacman en Arch), la ubicación de algunos ficheros de configuración, y los hábitos de cada comunidad. Aprende bien una familia y el resto es cuestión de semanas de adaptación, no de meses.
También cambia mucho el contexto de uso. Linux en el escritorio implica gestionar entornos gráficos, controladores de tarjeta de vídeo, y la integración con hardware de consumo. En servidores, la prioridad es la estabilidad a largo plazo, la seguridad y el acceso remoto por SSH. En contenedores (Docker, Podman) ni siquiera hay un kernel propio: el contenedor comparte el kernel del host y solo lleva las herramientas de usuario, así que la “distribución” se reduce a un sistema de ficheros mínimo. En sistemas embebidos —routers, cámaras, electrodomésticos— el kernel está compilado específicamente para el hardware, sin margen para paquetes extra.
Cuando algo falla o algo funciona diferente de lo que esperabas, lo primero que ayuda saber es en qué familia estás y en qué contexto se ejecuta el sistema.
# Averigua en qué distribución estás exactamente cat /etc/os-release # Muestra la versión del kernel que está corriendo ahora mismo uname -r # En Debian y su familia, el gestor de paquetes es apt. # Esto muestra cuántos paquetes tienes instalados actualmente. dpkg --get-selections | wc -l # El sistema de inicio en Debian moderno es systemd. # Este comando confirma que el PID 1 (el primer proceso) es systemd. ps -p 1 -o comm=
El fichero /etc/os-release es el estándar moderno para identificar una distribución desde scripts o herramientas de automatización; sustituyó a métodos anteriores como buscar /etc/debian_version o /etc/redhat-release a mano. uname -r te dice el kernel, que en Debian Bookworm será algo del estilo 6.1.0-21-amd64 —el 6.1 es la versión upstream de Linus Torvalds, el resto es la numeración interna de Debian. La diferencia entre esos dos números ya te explica algo sobre la filosofía de la distro: Debian no toma la última versión del kernel disponible, toma una versión estable y le aplica parches de seguridad durante años.
El conteo de dpkg --get-selections suele sorprender: una instalación de escritorio de Debian puede tener fácilmente 1.500 paquetes instalados, pero una imagen mínima para contenedor puede funcionar con menos de 100. Eso ilustra bien la diferencia entre contextos: no es la misma distribución para todos los usos, aunque lleven el mismo nombre.
Que ps -p 1 devuelva systemd no es un detalle menor. El proceso con PID 1 es el padre de todos los demás procesos del sistema y determina cómo arranca, cómo se gestionan los servicios y cómo se apaga la máquina. Históricamente ese proceso era SysV init o Upstart; en Debian se migró a systemd en Jessie (2015). Dentro de un contenedor sin systemd, ese PID 1 suele ser directamente el proceso de tu aplicación, lo que tiene implicaciones importantes para cómo se manejan las señales —pero eso es territorio para más adelante.
N° 3