Debian y Ubuntu: por qué se separaron y qué cambia

Por qué Debian y Ubuntu se separaron

Debian y Ubuntu se separaron en 2004 por el calendario, no por el código. Debian publica una versión estable cuando su equipo de publicación considera que está lista. Ubuntu prometió una nueva versión cada seis meses, en una fecha fijada de antemano. Por eso toma una copia de la rama de desarrollo de Debian, la congela, corrige lo que está roto y la publica.

Veintidós años después, ambos proyectos siguen compartiendo el formato de paquetes y las herramientas que lo administran. Además, la mayor parte del trabajo de empaquetado que hay detrás se hace una sola vez. Lo que no comparten es un calendario, un contrato de soporte ni una misma opinión sobre lo que debe incluir una instalación predeterminada. Esta es la distinción útil al elegir un sistema operativo para un servidor, porque separa las diferencias cosméticas de las que pueden costarle una tarde.

De dónde surgió Ubuntu

Ian Murdock fundó el proyecto Debian el 16 de agosto de 1993. En 2004, Debian era la distribución gestionada por voluntarios más grande que existía, pero avanzaba lentamente. Debian 3.0 "woody" se publicó el 19 de julio de 2002, y su sucesora, Debian 3.1 "sarge", no llegó hasta el 6 de junio de 2005. Pasaron casi tres años entre dos versiones estables. Durante ese intervalo, cualquiera que quisiera software actualizado en un servidor Debian no tenía una respuesta compatible y respaldada por la propia Debian.

En abril de 2004, Mark Shuttleworth invitó a aproximadamente una docena de desarrolladores de Debian a su piso de Londres para planificar un sistema basado en Debian con un calendario fijo, y fundó Canonical Ltd para contratarlos. La primera versión, Ubuntu 4.10 "Warty Warthog", llegó seis meses después, el 20 de octubre de 2004. El número de versión indica la fecha de publicación: 4.10 significa octubre de 2004 y 26.04 significa abril de 2026.

Ubuntu nunca fue un fork en el sentido habitual. Un fork copia una base de código una vez y después se separa del proyecto original. Ubuntu vuelve a copiar Debian en cada ciclo. Los paquetes se obtienen de Debian unstable, la rama de actualización continua que Debian denomina sid, y esa copia se actualiza automáticamente durante las primeras semanas de cada ciclo de Ubuntu. Después del bloqueo de importaciones, un desarrollador de Ubuntu debe incorporar manualmente cada paquete posterior y justificarlo conforme a las reglas del bloqueo. El árbol familiar más amplio de las distribuciones Linux contiene muchos forks reales. Este no es uno de ellos. Es un proyecto derivado permanente.

Lo que ambos proyectos siguen compartiendo

La parte compartida es mucho mayor que la parte diferente. Ambos usan el formato de paquetes .deb, con dpkg por debajo y apt por encima, y ambos siguen la Política de Debian para determinar dónde se instalan los archivos y cómo declaran sus dependencias. La documentación oficial para desarrolladores de Ubuntu estima que aproximadamente cuatro de cada cinco paquetes fuente se copian de Debian sin ninguna modificación. Un mantenedor que corrige un error en Debian también lo corrige para los usuarios de Ubuntu, normalmente sin que ninguna de las dos partes lo advierta.

Cuando Ubuntu modifica un paquete, la cadena de versión lo indica. El 1.2.3-4 de Debian se convierte en 1.2.3-4ubuntu1, y ese sufijo marca el cambio local, que ambos proyectos denominan delta. Ubuntu publica el delta completo de cada paquete que modifica y envía los parches al sistema de seguimiento de paquetes de Debian. Así, un mantenedor de Debian puede ver qué hizo el proyecto derivado y aplicarlo si lo considera conveniente.

Desde 2005 se debate si eso es suficiente. Conviene exponer el argumento con claridad en lugar de tomar partido. Desde la perspectiva de Debian, la queja se refiere a dónde recae el esfuerzo: Canonical paga a personas para trabajar en el proyecto derivado, mientras este reúne a los usuarios y concentra la atención. Enviar una corrección al proyecto original supone trabajo adicional que nadie está obligado a realizar. Desde la perspectiva de Ubuntu, un plazo de seis meses no encaja con un proyecto que no tiene plazos. Por eso, esperar a Debian no siempre es una opción. Ambas afirmaciones son ciertas. Ninguna ha impedido que los paquetes sigan pasando de un proyecto al otro.

Publicar cuando esté listo, no según una fecha del calendario

La fecha de publicación de Debian es un resultado, no una promesa. Debian 12 "bookworm" se publicó el 10 de junio de 2023 y Debian 13 "trixie" el 9 de agosto de 2025, con una diferencia aproximada de dos años, pero nada garantiza que el próximo intervalo sea igual. La rama testing actual se llama "forky" y no tiene fecha de publicación, porque Debian no anuncia ninguna hasta que el número de fallos críticos para la publicación indica que puede hacerlo.

La fecha de Ubuntu es la promesa. Se publica una versión cada seis meses y, cada cuatro versiones, la de abril de un año par es una versión LTS (soporte a largo plazo). Ubuntu 26.04 LTS "Resolute Raccoon" se publicó el 23 de abril de 2026, según lo previsto. Las versiones intermedias son versiones provisionales y sólo reciben actualizaciones durante nueve meses. Por eso no conviene instalarlas en un servidor que preferiría no reconstruir dos veces al año. La elección entre Ubuntu LTS y las versiones provisionales en un servidor se reduce a esos nueve meses.

La cadencia establece el calendario de actualizaciones, y esta es la consecuencia más práctica de la diferencia. En Ubuntu LTS sabe con años de antelación que la próxima actualización en el mismo sistema llegará en abril de un año par. Por tanto, la actualización de Ubuntu 24.04 a 26.04 se podía planificar antes de que existiera 26.04. En Debian debe vigilar los anuncios de congelación y programar el trabajo cuando la versión se publique realmente.

Qué cambió con LTS

Ubuntu 6.06 LTS "Dapper Drake" se publicó el 1 de junio de 2006 y fue la primera versión LTS. Antes de ella, Ubuntu era un sistema de evolución rápida que se sustituía dos veces al año. Esto no es una base adecuada para un servidor de producción empresarial. LTS introdujo un cambio importante: estableció una fecha de finalización del soporte en el futuro, lo bastante lejana para poder planificar en torno a ella. Este cambio convirtió a Ubuntu en la distribución de servidores predeterminada. La cadencia de seis meses la alimenta, porque cada versión LTS se crea a partir del trabajo ya probado en las versiones intermedias anteriores.

Debian llegó al mismo punto desde la dirección contraria. Su versión estable ya avanzaba lentamente. Además, el proyecto Debian LTS prolonga el periodo de soporte de cada versión después de que el equipo de seguridad de Debian deja de mantenerla.

Quién ofrece soporte y durante cuánto tiempo

[
  {
    "label": "Debian stable",
    "support_duration": 3
  },
  {
    "label": "Debian LTS",
    "support_duration": 5
  },
  {
    "label": "Debian ELTS, paid",
    "support_duration": 10
  },
  {
    "label": "Ubuntu LTS",
    "support_duration": 5
  },
  {
    "label": "Ubuntu Pro ESM",
    "support_duration": 10
  },
  {
    "label": "Ubuntu Pro plus Legacy",
    "support_duration": 15
  }
]

El equipo de seguridad de Debian cubre una versión estable durante 3 años. Después, el equipo Debian LTS, que Debian describe como un grupo de voluntarios y empresas, no como sus equipos oficiales de seguridad y versiones, la mantiene hasta 5 años. La transferencia se refleja en las fechas actuales: bookworm entró en LTS el 11 de junio de 2026 y está cubierta hasta el 30 de junio de 2028, mientras que bullseye finaliza su periodo LTS el 31 de agosto de 2026. Después de esa fecha, Freexian ofrece Extended LTS, o ELTS, hasta 10 años, y sólo para el subconjunto de paquetes que realmente utilizan sus clientes de pago.

Una versión Ubuntu LTS recibe 5 años de mantenimiento de seguridad estándar por parte de Canonical. Una suscripción a Ubuntu Pro amplía ese periodo a 10 años mediante ESM (mantenimiento de seguridad ampliado), tanto para main como para universe, y el complemento Legacy lo amplía hasta 15. En agosto de 2026, Ubuntu Pro es gratuito para uso personal en un máximo de cinco máquinas. Por tanto, en un único VPS, la cifra de diez años es real sin necesidad de una orden de compra. Pro también incluye el servicio livepatch, que es la opción compatible para aplicar parches al kernel en ejecución en un VPS sin reiniciar por cada actualización de seguridad del kernel.

La estructura que hay detrás de esas cifras es más importante que las cifras en sí. Con Ubuntu, se contrata el soporte a la misma empresa que desarrolla la distribución. En Debian no existe una empresa de ese tipo. Por eso, el soporte de pago procede de un tercero como Freexian, del proveedor de hosting o del propio equipo.

Sistemas de inicio y la votación que puso fin al debate

La divergencia técnica más marcada fue el sistema de inicio: el primer proceso que inicia el kernel y el supervisor de todos los servicios posteriores. Ubuntu 6.10 "Edgy Eft", publicado el 26 de octubre de 2006, incluía Upstart, desarrollado en Canonical. Debian mantuvo sysvinit durante años mientras continuaba el debate. El Comité Técnico de Debian resolvió la cuestión mediante una votación que concluyó el 11 de febrero de 2014. El voto de desempate de la presidencia decidió adoptar systemd para Debian 8.

Ubuntu siguió esa decisión pocos días después. La publicación de Shuttleworth sobre la decisión, titulada "Losing graciously", explicó claramente el motivo: Ubuntu forma parte de la familia Debian, por lo que adoptaría el resultado. Ubuntu 15.04 incluyó systemd de forma predeterminada el 23 de abril de 2015. Debian 8 "jessie" hizo lo mismo el 26 de abril de 2015, tres días después.

Por eso la mayoría de los tutoriales sobre servicios se pueden aplicar a ambas distribuciones sin modificaciones. Los archivos de unidad, systemctl y journalctl se comportan igual en las dos. Debian 13 incluye systemd 257 y Ubuntu 26.04 LTS incluye systemd 259. Por tanto, la diferencia entre ellas en este aspecto es el número de versión, no el diseño.

Snap y la parte que no se puede trasladar

Ubuntu 16.04 LTS introdujo los paquetes snap en 2016, y 18.04 fue la primera versión que distribuyó algunas aplicaciones predeterminadas como snaps. Un snap es un paquete autónomo que incluye su propia copia de las dependencias. Así, un proyecto upstream puede publicar una versión nueva para todas las versiones compatibles de Ubuntu a la vez, en lugar de esperar a que el archivo de paquetes se actualice.

La razón por la que ninguna otra distribución importante adoptó snaps de forma predeterminada no es el formato. El cliente snapd se comunica con un único almacén operado por Canonical, y el servidor de ese almacén no es de código abierto. Por tanto, una distribución que adopta snaps delega parte de la distribución de su software a otro proveedor. Debian no lo hizo y no instala snapd de forma predeterminada.

Aquí es donde las instrucciones del proyecto upstream dejan de funcionar sin indicarlo claramente. Certbot es el ejemplo más claro: su propia documentación recomienda instalarlo desde un snap y advierte que los paquetes de las distribuciones «tienden a quedar obsoletos rápidamente en distribuciones de tipo LTS». Si sigue esa página en Ubuntu, funciona. Si la sigue en un servidor Debian estándar, el primer paso no tiene nada que pueda ejecutarlo. Nuestra guía de Certbot para Nginx en Ubuntu 24.04 usa por ese motivo el paquete de la distribución.

Kernels, firmware y la cuestión del software no libre

El Contrato Social de Debian y las DFSG (directrices de Debian sobre software libre) definen qué puede incluirse en main. Todo lo demás pasa a contrib y non-free. Durante la mayor parte de la historia de Debian, esto incluía los blobs de firmware binario que el hardware de red y almacenamiento convencional necesita antes de funcionar. Después de una Resolución General aprobada en 2022, Debian 12 añadió un área de archivo independiente llamada non-free-firmware. Desde entonces, las imágenes oficiales del instalador incluyen ese firmware.

Ubuntu tomó la decisión contraria desde el primer día. Su archivo se divide en main y restricted, componentes respaldados por Canonical que incluyen controladores propietarios, además de universe y multiverse, que mantiene la comunidad. En un VPS, el efecto es pequeño porque el hardware virtual apenas necesita firmware. En hardware dedicado, puede determinar si una tarjeta de red se activa o no.

Los kernels también divergen en este aspecto. En agosto de 2026, Ubuntu 26.04 LTS incluye Linux 7.0 y Debian 13 incluye Linux 6.12. Ubuntu también actualiza el kernel dentro de una misma LTS mediante sus pilas de habilitación de hardware, mientras que Debian mantiene una misma serie de kernel durante todo el ciclo de una versión stable y ofrece versiones más nuevas mediante backports. Una versión más nueva ofrece mejor compatibilidad con dispositivos virtio y sistemas de archivos recientes. Una versión más antigua mantiene en diciembre el mismo comportamiento que se probó en enero.

Qué falla al seguir instrucciones de la otra distribución

La mayoría de las veces, una guía escrita para una distribución funciona en la otra. Los fallos suelen concentrarse en algunos puntos conocidos.

• Los repositorios apt de terceros se publican por distribución y por nombre de versión. Un proveedor que admite noble y jammy puede no publicar nada para trixie, y el fallo parece un problema de red en lugar de una decisión de compatibilidad.
• Las PPA de Launchpad se compilan sólo para determinadas series de Ubuntu. Añadir una a Debian descarga binarios enlazados con las versiones de las bibliotecas de Ubuntu. Esto puede funcionar por casualidad o incorporar gran parte del entorno de ejecución de Ubuntu al sistema.
• Todo lo que presupone snapd, una suscripción a Ubuntu Pro o livepatch de Canonical no tiene un paso equivalente en Debian. Por tanto, esas secciones de la guía deben sustituirse, no adaptarse.
• Las imágenes predeterminadas difieren en el usuario con el que se inicia sesión. Las imágenes de Ubuntu suelen proporcionar un usuario ubuntu con sudo y sin contraseña de root. Las imágenes de Debian suelen proporcionar un usuario debian, y las imágenes de los proveedores varían. Compruebe cuál usa antes de cambiar cualquier configuración de SSH.

Cuando un repositorio no tiene una suite para su versión, apt lo indica de forma específica:

E: The repository 'https://download.example.com/linux/debian forky Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Ese mensaje significa que el proveedor nunca publicó paquetes para su nombre de versión. El mirror no está averiado y volver a intentarlo no lo solucionará. El proveedor admite su versión o no la admite.

Entonces, ¿cuál debería elegir?

Elija Ubuntu LTS si quiere una fecha de actualización que pueda anotar en el calendario con años de antelación y un proveedor al que pueda contratar soporte. Elija Debian stable si quiere una instalación predeterminada más pequeña, sin una única empresa en la cadena, y una base que cambie con la suficiente lentitud para resultar predecible.

El resto se puede trasladar. Ambos usan apt, siguen Debian Policy y ejecutan las mismas aplicaciones con el mismo formato de paquetes, por lo que las habilidades adquiridas sirven en ambos. Si viene de Red Hat o Fedora, las equivalencias de comandos entre dnf y apt permiten hacer la conversión en ambas direcciones. Si está comparando estas dos opciones con las demás imágenes disponibles durante el despliegue, nuestra guía para elegir un sistema operativo para su VPS las compara con el resto de la lista.

FAQ

¿Ubuntu es una bifurcación de Debian?

No. Una bifurcación copia una base de código una vez y la mantiene por separado a partir de ese momento. Ubuntu vuelve a importar paquetes desde Debian unstable al inicio de cada ciclo de seis meses, y la documentación para desarrolladores de Ubuntu sitúa en aproximadamente cuatro de cada cinco la proporción de paquetes fuente copiados sin modificaciones. Ubuntu es un proyecto derivado permanente de Debian. Por eso los conocimientos sobre el empaquetado de Debian se transfieren a Ubuntu sin cambios y una corrección realizada en Debian suele llegar a los usuarios de Ubuntu sin trabajo adicional.

¿Los tutoriales de Ubuntu funcionan en Debian?

Por lo general, sí, y las excepciones son predecibles. Ambos usan apt, ambos usan systemd y ambos siguen Debian Policy, por lo que la gestión de paquetes y servicios es equivalente. Lo que falla es todo lo relacionado con la infraestructura de Canonical: pasos de instalación basados en snap, PPA de Launchpad, comandos de Ubuntu Pro y repositorios apt de terceros que sólo publican paquetes para los nombres de código de Ubuntu. Cuando un repositorio no tiene una suite para su versión, apt informa de que «does not have a Release file». Esto significa que el proveedor nunca compiló paquetes para su nombre de código.

¿Cuánto duran las actualizaciones de seguridad de Debian y Ubuntu?

Una versión Ubuntu LTS recibe 5 años de mantenimiento de seguridad estándar por parte de Canonical, 10 con una suscripción a Ubuntu Pro y hasta 15 con el complemento Legacy. Una versión estable de Debian recibe 3 años por parte del equipo de seguridad de Debian y 5 años si se incluye el periodo LTS posterior. El Extended LTS de pago de Freexian alcanza 10 años, pero sólo para los paquetes que soliciten sus clientes.

¿Cuál es mejor para un servidor: Debian o Ubuntu?

Ninguno es mejor en general. La diferencia real está en el calendario y el soporte. Ubuntu LTS es adecuado para un servidor en el que la fecha de actualización debe ser predecible y el soporte debe poder contratarse con un único proveedor. Debian stable es adecuado para un servidor en el que una instalación predeterminada más pequeña y un ritmo de cambios más lento son más importantes que un calendario fijo. Ambos ejecutan el mismo software con el mismo formato de paquetes, por lo que la elección no limita lo que puede alojar.