Lanzamiento de Debian 13 "Trixie"

• Tras casi 2 años, 1 mes y 30 días de desarrollo, el proyecto Debian presentó la nueva versión estable Debian 13 "Trixie".
• Debian ofrece soporte predeterminado para múltiples entornos de escritorio como GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0 y Xfce 4.20.
• Se añadieron más de 14,100 paquetes nuevos, con un total de 69,830 paquetes, y se retiraron 8,840 paquetes por obsolescencia.
• Se actualizaron 44,326 paquetes y se hizo una limpieza masiva de la base de código; el uso total de disco es de 403 GB y el número de líneas de código llega a 1.4 mil millones.
• Arquitecturas compatibles: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
  • Se incorporó oficialmente el soporte para riscv64 por primera vez.
  • Se decidió finalizar el soporte de i386: no se proporciona kernel ni herramientas de instalación oficiales y solo funciona de forma limitada en CPU de 64 bits.
  • La arquitectura armel recibe en este lanzamiento su último soporte.
• Se aplica una ABI time_t de 64 bits en todas las arquitecturas excepto i386, lo que también permite manejar fechas después de 2038.

• Software y herramientas de desarrollo

  • Se ofrecen actualizados más del 63 % del total de paquetes.
  • Software y herramientas de desarrollo destacados: Apache 2.4.64, Bash 5.2.37, BIND 9.20, curl/libcurl 8.14.1, Emacs 30.1, GNU Compiler Collection 14.2, GIMP 3.0.4, LibreOffice 25.2, Linux kernel 6.12 LTS, LLVM/Clang 19, Python 3.13, Rustc 1.85, Systemd 257, Vim 9.1, entre otros.
  • Adecuado para una variedad de casos de uso, como arch, servidores, escritorios, clústeres, bases de datos, así como servidores web y de almacenamiento.
  • Se reforzó el proceso de control de calidad con pruebas de instalación y actualización automáticas.

• Soporte de nube e instalación en vivo

  • Proporciona imágenes para servicios en la nube como Amazon EC2, Microsoft Azure, OpenStack, PlainVM y NoCloud.
  • Las imágenes en la nube incluyen automatización con cloud-init y optimización del kernel y el cargador de arranque para iniciar instancias más rápido.
  • Las imágenes live están disponibles para amd64 y arm64 en formato DVD, USB y arranque por red.
  • Las imágenes live permiten probar múltiples entornos de escritorio, y también está disponible una imagen estándar sin GUI.
  • Se puede instalar con Calamares y con el instalador estándar de Debian, además de aprovechar métodos diversos de instalación como HTTP Boot.

[zihado]

No sé si los que estaban en el canal de Debian en IRC estén bien. En la época de Debian Potato me la pasaba bastante en IRC... jajaja.

[jungmin1237]

La etiqueta de Docker también ya salió.
https://hub.docker.com/layers/library/…

[dongjinahn]

También yo usaba Ubuntu en un VPS de 512 MB de RAM por $2.5 al mes, y me pasé a Debian, y me gustó. Como venía de Ubuntu, ya me resultaba familiar, y además usa menos memoria.

[GN⁺]

Opiniones de Hacker News

• Actualmente estoy escribiendo esto en un sistema Debian, y en lo personal estoy muy satisfecho usándolo como sistema de uso diario. Cuando Ubuntu empeoró bastante con respecto a antes, migré a Debian 6 y nunca me he arrepentido. Lo que me gusta de Debian es que está balanceada entre ideales y practicidad: por defecto se enfoca en software libre, pero también deja instalar fácilmente software o firmware non-free cuando hace falta; sus directrices de paquetes, dpkg y la documentación muy sólida también me convencen (aunque la documentación de Arch sigue siendo la mejor). El hecho de tener flujos stable/testing para elegir entre la estabilidad de versiones antiguas y opciones más nuevas casi estables también es muy bueno. Sobre todo, salvo que yo me equivoque, nunca tuve ni una sola vez que el sistema fallara por un defecto de Debian. En ocasiones hubo arranques fallidos o problemas graves, y siempre fue porque agregué un repositorio de terceros o toqué una configuración incorrectamente.

  • Es cierto que Debian es excelente, pero también me cuesta decir que el sistema no se rompe hasta que yo lo rompo. En particular, en Debian stable hay muchas correcciones aplicadas al kernel y me pasó más de una vez que, al hacer backport en el subsistema DRM que cambia rápido, tuve crashes difíciles de depurar. Aunque en teoría la versión de kernel se mantiene igual durante todo el periodo de lanzamiento, en la práctica es menos estresante usar un kernel más reciente (la rama hwe de Ubuntu) de forma continua. Por eso uso Debian en VM y Ubuntu en bare metal. No probé usar el kernel desde el repositorio debian-backports.

  • Yo también dejé de usar Ubuntu Server porque sufría mucho con problemas de upgrades. Administraba más de 75 VPS y, al hacer cada actualización de mantenimiento, tenía miedo de que terminara inhabilitando el arranque; solo la recuperación de ese incidente agregaba 1–2 horas por VPS. Desde que pasé a Debian alrededor de la serie 8.x en 2015, es mucho más estable. No se ha roto, salvo que yo haga algo mal.

  • Me gustaría saber en qué parte sentiste que Ubuntu empeoró tanto.

  • Si hay un defecto de Debian, para mí sería que intenta iniciar un servicio en cuanto instalas software nuevo de servidor. Aunque la configuración por defecto es bastante segura, da un poco de miedo que el servicio se levante antes de que yo lo configure. Red Hat me parece más agradable porque, al instalar, el servicio no arranca hasta que yo lo enciendo manualmente.

  • Debian es la base de la operación de mis servidores. Mantengo los servidores en Old Stable y pruebo las nuevas funciones del release en sistemas temporales. Aprendí nftables en Bookworm y probé labwc en Trixie. labwc permite configuración estilo Openbox mientras soporta Wayland.

• Agradezco mucho a los voluntarios de la comunidad de Debian. Debian y los miles de proyectos basados en Debian existen gracias a todos ustedes. Mucha gente y empresas se benefician de su trabajo. Personalmente, este lanzamiento de Trixie me emociona en especial. Mi proyecto lateral ntfy fue incluido como paquete en Trixie. Solo al final del ciclo me enteré por una consulta de licencia del empaquetador de ntfy de que la app web falta en el paquete de Debian y que se eliminaron algunas funciones mediante parches. También se agregaron build tags para que sea más fácil quitar Stripe, Firebase y WebPush, así que espero que en el próximo release de Debian haya menos parches. Desde la perspectiva de quien mantiene upstream, es una lástima no haber una explicación clara de por qué se removió la app web. Entiendo que se quitó a propósito, pero no queda claro cómo meterla en el próximo release. Si alguien instala apt install ntfy y la app web no funciona, seguramente muchos usuarios se van a decepcionar. Bienvenidos sean consejos o guías. También se puede revisar el código fuente.

  • El mantenedor del paquete añadió una nota relacionada aquí. La app web está basada en nodejs y esos paquetes nodejs de Debian no existen. La filosofía de Debian evita incluir directamente en el paquete la fuente de dependencias. Parece que eso habría sido una carga grande porque también tendrías que crear y mantener los paquetes dependientes.

  • Los builds de paquetes npm en Debian tienen que ser construibles. Así que en un package.json específico de Debian hay que convertir dependencias npm a paquetes Debian, hacer port o proveerlas como paquetes separados. Potencialmente implica mucho trabajo. Si el lockfile es grande, se vuelve bastante laborioso. Supongo que al mantenedor le pareció pesado ese volumen. A la usanza de Debian, parece más natural ofrecer un paquete separado como ntfy-web.

  • Gracias a ntfy. Lo uso diariamente para recibir notificaciones de eventos del nodo Meshtastic en casa.

  • El software de ntfy se usa muy bien.

  • Si quieres resolver bien el tema de dependencias, quizá sea mejor opción distribuirlo como imagen de contenedor.

• Debian es la base estable de mi vida de computación libre. Aprendí mucho de Condorcet, de la gobernanza basada en procedimientos y de la toma de decisiones basada en principios. La influencia que este proyecto y esa cultura han tenido en el mundo es inmensa e inconmensurable. Les mando mis felicitaciones con cariño.

• Respecto a i386, es que finalmente termina el soporte normal (sin kernel reciente o instalador, recomendado para CPUs de 64 bits únicamente, no recomendado para actualizar hardware puramente de 32 bits). Es increíble que el soporte de i386 se haya extendido hasta agosto de 2025. Yo todavía tenía Debian 10 Buster corriendo en hardware basado en Pentium 3 (EOL en junio de 2024). Gracias a que el soporte duró tanto, pude usar ese hardware viejo más tiempo. Si alguien aún quiere un OS moderno en i386, OpenBSD también es una opción.

  • Creía que la última vez que usé Pentium 3 fue alrededor de 2007, pero hoy es una época donde por 1 dólar puedes comprar una PC con 100 veces más rendimiento.

  • Si i386 pasa a la infraestructura de Debian ports (por ejemplo, m68k), espero que se pueda seguir usando en modo experimental en Debian 14 o 15.

  • Recuerdo que old stable tiene alrededor de 1 año extra de soporte, así que no termina por completo en 2025.

  • Esto es sobre soporte en Debian. El kernel de Linux en sí sigue soportando CPUs de 32 bits desde el Pentium original (excepto algunos chipsets clonados).

  • ¿No confundes “386” con 32 bits? Generalmente lo normal para 32 bits es 686, 386 es algo de los 80.

• sysvinit también sigue siendo utilizable. Ya lo he testeado en servidor y desktop. Con el problema de dependencias de ciertos paquetes, puedes evitarlo con un comando que haga eliminación e instalación al mismo tiempo como abajo. Según el bug de Debian, la clave es desinstalar systemd-sysv y systemd con un - delante. Con ese método, la construcción de sysvinit hecha con debootstrap queda casi igual que en bookworm (incluyendo desktop). Igual que con bookworm o buster, en apt preferences se deja solo libsystemd0 y se bloquean los demás paquetes de systemd con priority -1.

  • Me interesa saber si Debian 13 soporta realmente sysvinit de forma correcta, es decir, si se puede operar un servidor con sysvinit sacando systemd.

  • Gracias por compartir la información. Al menos lo voy a probar en contenedores LXC.

  • Me pregunto por qué alguien haría esto.

• Puede ser difícil encontrar la imagen .torrent para x86-64, así que dejo los enlaces ordenados:
  Minimal: netinstall ISO
  Full: DVD ISO

  • La mayoría de usuarios no necesita la imagen DVD (full). La instalación suele ser suficiente solo con la CD minimal netinstall.

• Listado de las 7 arquitecturas soportadas oficialmente en Trixie:

  • amd64 (PC de 64 bits)
  • arm64
  • armel (ARM EABI)
  • armhf (ARMv7 EABI hard-float)
  • ppc64el (PowerPC little-endian de 64 bits)
  • riscv64 (RISC-V little-endian de 64 bits)
  • s390x (IBM System z)
    RISC-V casi no tiene hardware realmente utilizable, pero me alegra que por fin se lo trate como una plataforma de primera clase. Me gustaría saber dónde se usa hoy PowerPC y System z, y dónde se despliegan realmente arquitecturas además de amd64/arm64/riscv64.

  • Power y z siguen siendo negocios de miles de millones de dólares. Ambas arquitecturas se usan bastante en finanzas y bancos. IBM sigue orgullosa de z, pero Power da la sensación de que hoy solo se mantiene, lo cual da pena. Power, como arquitectura y sistema, está hecho muy bien.

  • Los mainframes se enfocan en casos donde un solo servidor debe operar sin interrupción durante décadas. Incluso se puede hacer hot-swap de piezas como CPU o memoria y, aparte de los servicios del sistema operativo, el hardware puede monitorizarse y diagnosticarse continuamente. Si se detecta un problema de hardware, se alerta automáticamente al dueño y a IBM. IBM comenzó a soportar Linux como OS de primera clase en mainframes desde inicios de los 2000. Para los desarrolladores, s390x es la última arquitectura big-endian que queda (aún existe SPARC, pero está prácticamente en modo mantenimiento y solo Oracle lo atiende con Solaris), y además sirve para cazar bugs de endianness. Las únicas arquitecturas de 32 bits que quedan son armel y armhf, y esta release es la última de soporte para armel (referencia). De aquí en más o menos terminará el soporte oficial de 32 bits.

  • IBM está invirtiendo bastante para que estas dos arquitecturas sigan funcionando bien en las distribuciones principales. Por eso, a diferencia de otras arquitecturas, parece que permanecen incluidas por el apoyo directo de IBM en lugar de mantenerse de forma orgánica.

• Si te preocupa el tema de naming de NIC en systemd, revisa las notas de release (enlace). Con el comando udevadm puedes verificar antes del upgrade cómo cambiará el nombre de las interfaces. La lista de las demás interfaces menos bond/lo también se puede checar con un one-liner abajo. En mis pruebas, nunca vi que el nombre de una interfaz cambiara por un upgrade. Así que no estoy seguro de que ese método realmente detecte cambios de nombre por adelantado.

  • Creo que sería el último cambio grande de naming de interfaces. enoX debería mantenerse estable siempre, porque BIOS (tablas ACPI y similares) te dice qué puerto tiene qué ID. ensX depende del slot PCIe, pero según la topología PCIe un slot puede tener varias NIC, así que se complica. systemd ha cambiado la lógica de naming varias veces para manejar estos casos frontera. Alguna vez hubo una colisión por leer indirectamente el número de slot PCIe y eso se corrigió en systemd 257.

  • Me gustaría saber si, incluso habiendo desactivado previamente Predictable Network Interface Names de systemd antes del upgrade, puede cambiarse el nombre de interfaz.

• Empecé con Debian desde Slink. Hoy en día sigo metiendo apt-get ... y aun así, a pesar de todo, sigue funcionando. En más de 25 años de upgrades he tenido problemas grandes y chicos, pero el tiempo y el esfuerzo fueron realmente mínimos comparado con otros Linux o software propietario. Mi único pesar es no haber contribuido más a la comunidad. Creo que la mayor ventaja de Debian es que el usuario debe entender al menos en parte el comportamiento del sistema para usarlo. Por eso creo que mantiene bien su filosofía de "lo más simple posible, pero no más simple que eso".

• Una de las ventajas típicas de Debian es que la actualización de stable a stable toma menos de 15 minutos. Mi primer sistema terminó la migración en menos de 10 minutos, incluyendo descarga de paquetes y reinicio. No era una máquina especialmente potente, y la red era un mini PC de 50 Mbps.