Sortie de Debian 13 « Trixie »

 (debian.org)
2 points par GN⁺ 2025-08-10 | 4 commentaires | Partager sur WhatsApp
  • Après environ 2 ans, 1 mois et 30 jours de développement, le projet Debian a présenté la nouvelle version stable Debian 13 « Trixie »
  • Debian prend désormais en charge par défaut plusieurs environnements de bureau dont GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0 et Xfce 4.20
  • Plus de 14,100 nouveaux paquets ont été ajoutés, pour un total de 69,830 paquets, tandis que 8,840 paquets ont été retirés pour vétusté
  • 44,326 paquets ont été mis à jour et une vaste refonte de la base de code a été réalisée ; la taille disque totale atteint 403GB et le volume total de code atteint 1,4 milliard de lignes
  • Architectures prises en charge : amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
    • Le support officiel de riscv64 est introduit pour la première fois
    • La prise en charge d’i386 est arrêtée : aucun noyau officiel ni outil d’installation n’est fourni, et son usage reste limité sur les CPU 64 bits
    • L’architecture armel est en dernier support dans cette version
  • En dehors d’i386, une ABI time_t 64 bits est appliquée, ce qui permet de gérer les dates après 2038

  • Logiciels et outils de développement

    • Plus de 63 % des paquets sont mis à jour
    • Principaux logiciels et outils de développement : 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, etc.
    • Convient à de nombreux usages, notamment l’architecture, les serveurs, les postes de travail, les clusters, les bases de données, les serveurs web et de stockage
    • Le processus d’assurance qualité a été renforcé, notamment avec les tests d’installation et de mise à niveau automatisés

  • Prise en charge du cloud et de l’installation live

    • Des images sont proposées pour les services cloud, notamment Amazon EC2, Microsoft Azure, OpenStack, PlainVM et NoCloud
    • Les images cloud intègrent l’automatisation cloud-init et une optimisation du noyau/bootloader pour un démarrage plus rapide des instances
    • Les images live sont proposées pour amd64 et arm64, sous forme de DVD, USB et démarrage réseau
    • Les images live permettent de choisir parmi plusieurs environnements de bureau et offrent aussi une image standard sans interface graphique
    • L’installation est possible via Calamares et l’installateur Debian standard, avec différentes méthodes, y compris le support de HTTP Boot

À lire aussi

4 commentaires

 
zihado 2025-08-12

Pour les personnes qui traînaient sur le canal Debian sur IRC, j'espère que vous allez bien. À l'époque de Debian Potato, je suis passé pas mal de temps sur IRC... haha.
 
jungmin1237 2025-08-12

Le tag Docker est déjà sorti.
https://hub.docker.com/layers/library/…
 
dongjinahn 2025-08-12

J’ai également quitté Ubuntu sur un VPS de 512 Mo de RAM à 2,5 $/mois pour Debian, et j’aime bien. Puisque je suis passé d’Ubuntu, c’est donc logique que ce soit familier, et ça utilise moins de mémoire.
 
GN⁺ 2025-08-10
Opinions de Hacker News

  • Je rédige ce commentaire sur un système Debian, que j'utilise au quotidien, et j'en suis vraiment satisfait. Après qu'Ubuntu se soit beaucoup dégradé, j'ai basculé vers Debian 6 et je n'ai jamais regretté ce choix. Ce que j'aime chez Debian, c'est l'équilibre entre idéologie et pragmatisme : elle vise par défaut le logiciel libre, mais permet aussi d'installer facilement des logiciels ou firmwares non-free si nécessaire. J'aime aussi ses guidelines de paquets, dpkg, et sa documentation très solide (la documentation d'Arch reste la meilleure). Le fait d'avoir des flux de paquets stable/testing, pour choisir entre la stabilité des versions plus anciennes et des versions plus récentes presque stables, est également très bien. Surtout, tant que je ne me trompe pas, je n'ai jamais eu une seule panne causée par un défaut propre à Debian. Quand il y a eu des soucis graves de démarrage ou des problèmes, c'était toujours lié à l'ajout d'un dépôt tiers ou à une mauvaise manipulation de configuration de ma part.

    • Je partage que Debian est excellente, mais il n'est pas si évident de garantir que, tant qu'on ne se trompe pas, rien ne casse. En particulier, sur Debian stable, avec les nombreux patches du noyau, j'ai rencontré plusieurs crashs difficiles à déboguer dus à des problèmes lors des backports dans le sous-système DRM qui évolue très vite. Le numéro de version du noyau reste officiellement identique pendant toute la période de publication, mais en pratique, utiliser des noyaux plus récents en continu (comme les HWE d'Ubuntu) réduit ce stress de patchs. C'est pourquoi je mets Debian en VM et Ubuntu en bare metal. Je n'ai pas encore essayé le kernel du repo debian-backports.

  • J'ai aussi beaucoup galéré avec les problèmes de mise à niveau sur Ubuntu Server, donc je l'ai laissé tomber. Je gère plus de 75 VPS ; et à chaque maintenance, j'ai souvent eu peur de tomber sur un cas où il ne boote plus. Cette récupération d'incident prenait 1 à 2 heures de plus par VPS. Depuis que je suis passé à Debian, autour de la 8.x en 2015, c'est bien plus stable. Sauf si je bidouille mal quelque chose, je n'ai jamais vu de casse.

  • Je suis curieux de savoir où exactement Ubuntu a autant décliné selon vous.

  • Le seul défaut de Debian à mes yeux, c'est qu'elle essaie d'exécuter un nouveau service serveur immédiatement après installation. La plupart des réglages par défaut sont sûrs, mais voir un service démarrer avant de l'avoir configuré m'inquiète un peu. J'apprécie aussi l'approche de Red Hat, qui attend que l'utilisateur le démarre explicitement.

  • Debian est la base de mon fonctionnement serveur. Je garde mes serveurs sur Old Stable, et je teste les nouvelles fonctionnalités de release dans un système temporaire. J'ai appris nftables sur Bookworm, et testé labwc sur Trixie. labwc permet une configuration de type Openbox tout en supportant Wayland.

  • Merci aux bénévoles de la communauté Debian. Debian et les innombrables projets qui en dépendent existent grâce à vous, et beaucoup de personnes et d'entreprises en tirent profit. Pour ma part, cette sortie de Trixie me rend particulièrement heureux. Mon side project ntfy est entré dans Trixie en tant que paquet. J'ai seulement appris ça en fin de cycle de release quand le mainteneur Debian de ntfy a posé une question de licence : dans le paquet Debian, l'app web a disparu et certaines fonctionnalités ont été retirées via patch. J'ai ajouté des build tags pour désactiver facilement Stripe, Firebase et WebPush, donc j'espère qu'il y aura moins de patchs à la prochaine release Debian. Vu du côté du mainteneur amont, il est frustrant qu'il n'y ait pas une explication claire sur pourquoi l'app web a disparu. Je comprends que ce choix soit volontaire, mais je ne sais pas bien comment réintégrer cela dans la prochaine release. Si quelqu'un fait apt install ntfy et que l'app web ne fonctionne pas, beaucoup d'utilisateurs risquent d'être déçus. Conseils ou guide bienvenus. Le source code est aussi consultable.

    • Le mainteneur du paquet a ajouté des précisions dans ce bug. L'application web est basée sur Node.js, et ces paquets Node.js n'existent pas dans Debian. Selon la philosophie Debian, il est déconseillé d'inclure directement les dépendances dans la source du paquet. Pour ce faire, il fautrait aussi fabriquer et maintenir eux-mêmes les paquets dépendants, ce qui semble avoir été trop lourd.

    • Le build d'un paquet npm chez Debian doit impérativement pouvoir être buildable. Il faut donc soit remplacer les dépendances npm par des paquets Debian dans un package.json Debian-specific, soit les porter, soit fournir des paquets séparés. C'est potentiellement une quantité de travail énorme quand le lockfile est gros. Le mainteneur a probablement trouvé cette charge trop importante. En logique Debian, il serait plus naturel d'offrir un paquet séparé comme ntfy-web.

    • Merci à ntfy, je m'en sers tous les jours pour recevoir les notifications d'événement de mon nœud Meshtastic à la maison.

    • J'utilise réellement ntfy au quotidien.

    • Pour résoudre les soucis de dépendances, la distribution via une image de container peut être une meilleure voie.

  • Debian est la base stable de ma vie de computing libre. Son influence est énorme via le vote de Condorcet, le consensus procédural, la prise de décision basée sur des principes. L'impact de ce projet et de cette culture sur le monde est immense et impossible à quantifier. Félicitations avec beaucoup d'affection.

  • Le support standard d'i386 prend enfin fin (pas de kernel ni d'installateur récent, usage recommandé uniquement avec un CPU 64 bits, pas de mise à jour recommandée sur du matériel purement 32 bits). Le fait qu'un support i386 ait duré jusqu'en août 2025 est énorme. J'étais encore sur Debian 10 Buster avec du hardware basé Pentium 3 (EOL en juin 2024). C'était appréciable de pouvoir l'utiliser si longtemps sur du vieux matériel. Si vous voulez un OS récent sur i386, OpenBSD est peut-être une option à considérer.

    • Je pensais avoir laissé le Pentium 3 derrière moi vers 2007, mais on peut aujourd'hui trouver un PC cent fois plus puissant pour 1 $.

    • Si i386 bascule côté infrastructure Debian ports (ex. m68k), j'espère qu'il pourra être utilisé expérimentalement encore sur Debian 14 ou 15.

    • Je crois qu'old stable bénéficie d'environ un an de support additionnel. C'est-à-dire que la fin totale n'est pas au-delà de 2025.

    • Là, il s'agit du support Debian. Au niveau du kernel Linux, le support des CPU 32 bits continue au-delà du Pentium original (certains chipsets clones exclus), en pratique.

    • Vous confondez le "386" avec le 32 bits ? D'habitude le 32 bits courant est le 686, et le 386 est de l'âge des années 1980.

  • sysvinit reste utilisable. Je l'ai déjà testé sur serveur/desktop. Face à des problèmes de dépendances de certains paquets, on peut éviter ça avec l'ordre de suppression+installation simultanées ci-dessous. Selon le bug Debian concerné, la clé est de retirer systemd-sysv et systemd avec un "-" ajouté. Avec cette méthode, le build sysvinit fait via debootstrap est quasiment identique à celui de Bookworm (desktop inclus). Comme en usage Bookworm ou buster, dans apt preferences, gardez uniquement libsystemd0 et bloquez les autres paquets systemd avec priority -1.

    • Je me demande vraiment si sysvinit fonctionne correctement sur Debian 13, c'est-à-dire si on peut faire tourner un serveur avec sysvinit en retirant systemd.

    • Merci pour le partage, j'ai au moins l'intention d'essayer dans des conteneurs LXC.

    • Je me demande pourquoi on irait jusque-là.

  • Je sais qu'il peut être difficile de trouver les images .torrent x86-64, donc voici des liens
    Minimal : netinstall ISO
    Full : DVD ISO

    • La plupart des utilisateurs n'ont pas besoin de l'image DVD (full). Pour l'installation, l'image netinstall minimale est largement suffisante.

  • Voici les 7 architectures officiellement prises en charge par trixie :

    • amd64(PC 64-bit)
    • arm64
    • armel(ARM EABI)
    • armhf(ARMv7 EABI hard-float)
    • ppc64el(PowerPC 64-bit little-endian)
    • riscv64(64-bit little-endian RISC-V)
    • s390x(IBM System z)
      Le matériel RISC-V exploitable reste limité, mais c'est agréable de le voir enfin reconnu comme plateforme de premier plan. Aujourd'hui je me demande où PowerPC et System z sont vraiment déployés, en dehors de amd64/arm64/riscv64.

    • Power et z restent des business à plusieurs milliards de dollars. Les deux architectures sont largement utilisées dans la finance et les banques. IBM est encore fier de z, mais Power donne plutôt l'impression d'être maintenue en survie. Power est une excellente architecture et un excellent système dans l'absolu.

    • Les mainframes sont taillés pour des usages où un seul serveur doit être opérationnel sans interruption pendant des décennies. Même les composants, y compris processeur et mémoire, sont hot-swappables, et il existe un monitoring/diagnostic matériel continu en dehors des services de l'OS. Quand un problème matériel est détecté, une alerte part automatiquement au propriétaire et à IBM. IBM soutient Linux comme OS de premier rang sur mainframe depuis le début des années 2000. Pour nous, développeurs, s390x est la dernière grande architecture big-endian restante (SPARC existe encore, mais en pratique en mode maintenance, Oracle ne s'en préoccupe plus qu'avec Solaris), ce qui est utile pour chasser les bugs d'endian. Les seules architectures 32 bits restantes sont maintenant armel et armhf, et ce release est la dernière à supporter armel (référence). L'arrêt du support 32 bits officiel semble donc imminent.

    • IBM met pas mal d'efforts pour que ces deux architectures continuent de bien fonctionner sur les distributions principales. C'est donc davantage dû au soutien d'IBM qu'à une conservation naturelle de l'écosystème, contrairement aux autres architectures.

  • Si le problème qui vous inquiète concerne la gestion des noms NIC avec systemd, consultez les notes de release (lien). La commande udevadm permet de voir à l'avance comment les noms d'interface peuvent changer après upgrade. La liste restante hors bond/lo peut être vérifiée via le one-liner ci-dessous. En pratique, je n'ai pas encore vu de changement réel de nom dû à la mise à niveau, donc je ne suis pas certain que cette méthode permette vraiment d'anticiper le changement.

    • Je pense que c'est probablement le dernier gros changement de nomenclature d'interface. L'appellation enoX doit rester stable, car le BIOS (tables ACPI, etc.) indique à quelle porte correspond quel ID. La forme ensX est basée sur l'emplacement PCIe, mais un slot PCIe peut faire apparaître plusieurs NIC selon l'arborescence PCIe, ce qui complique les choses. systemd a déjà modifié la logique d'interface plusieurs fois pour gérer ces cas limites. Il y a déjà eu collision à cause de la lecture indirecte du numéro de slot PCIe, et ça a été corrigé dans systemd 257.

    • J'aimerais aussi savoir si les noms d'interface peuvent changer quand Predictable Network Interface Names de systemd était déjà désactivé avant la montée.

  • J'utilise Debian depuis Slink, j'ai encore apt-get ... à taper et ça continue de bien fonctionner. En un peu plus de 25 ans, il y a eu des problèmes plus ou moins gros lors des mises à niveau, mais le temps et l'effort associés étaient vraiment minimes comparé aux autres Linux ou logiciels propriétaires. Si j'avais un seul regret, ce serait de ne pas avoir davantage contribué à la communauté. Le plus grand atout de Debian, à mon avis, c'est d'obliger l'utilisateur à comprendre au moins en partie le fonctionnement du système pour l'utiliser. Je pense que c'est ainsi qu'elle respecte bien sa philosophie : "aussi simple que possible, sans être excessivement simpliste".

  • Un avantage typique de Debian, c'est de passer d'une stable à la suivante en moins de 15 minutes. Sur mon premier système, la migration a été complétée en moins de 10 minutes, téléchargement des paquets et redémarrage compris. Ce n'était pas une machine puissante, et le réseau était un mini PC à 50 Mbps.