Précédemment chez Debian… Le contrat social a été modifié afin de permettre l’inclusion de microprogrammes non libres dès l’installation. « Les médias officiels peuvent inclure des microprogrammes qui autrement ne font pas partie du système pour permettre l’utilisation de Debian avec un matériel qui a besoin de ces microprogrammes ». (cf. épisode 12)
Debian GNU/Linux 13 — nom de code : Trixie — est sortie en version stable le 9 août 2025.
Cette nouvelle version repose sur un noyau Linux 6.12 (LTS) et la bibliothèque C de GNU 2.41 ; GCC 14.2, OpenJDK 21, Emacs 30.1 et VIM 9.1 sont inclus dans la distribution.
En termes d’environnements de bureau, GNOME 48, KDE Plasma 6.3 et Xfce 4.20 sont présents avec LibreOffice 25 et de nombreuses applications comme GnuCash 5.10, GIMP 3.0.4, Inkscape 1.4.
La distribution contient 69 830 paquets dont 14 116 nouveaux. Et pour gérer l’ensemble, APT a été mis à jour (version 3.0.3).
En termes de plateformes : PC 64 bits (amd64), ARM 64 bits (arm64), ARM EABI (armel), ARMv7 (ARM avec unité de calcul flottant, armhf), PowerPC 64 bits petit-boutiste (ppc64el), RISC-V 64 bit petit-boutiste (riscv64), IBM System z (s390x). L’architecture i386 n’est plus prise en charge comme les autres : pas d’installateur et moins de paquets sont disponibles, i386 est désormais destinée uniquement à être utilisée sur les processeurs 64 bits (amd64).
Le thème graphique de Debian 13 s’appelle Ceratopsian en référence à Trixie le triceratops de Toy Story 3.
Pour éviter le [[bug de l’an 2038]], Debian a basculé son horloge en 64 bits.
La précédente version stable (Bookworm) va être maintenue jusqu’en juin 2026, puis jusqu’en juin 2028 par le programme LTS.
Un statut concernant XMPP est détaillé pour les clients, serveurs, bibliothèques et passerelles/transports disponibles avec Trixie.
Aller plus loin
- Notes de publication pour Debian 13 (351 clics)
- Debian (140 clics)
- Wiki Debian (91 clics)
# fin du support 32 bits
Posté par impromptux . Évalué à 4 (+4/-0).
Bonjour,
Avez vous une idée de système de remplacement(avec une philosophie similaire) pour PC 32 bits?
[^] # Re: fin du support 32 bits - meme question
Posté par dr191 . Évalué à 6 (+5/-0). Dernière modification le 11 août 2025 à 13:50.
Salut,
Je me pose la meme question:
1/ vérifier que le proc n'est pas compatible amd64. Les procs i386 only ont 20 ans ou plus.
Sinon
2/ Rester en bookworn LTS jusqu'en 2028, puis changer le matériel.
3/ LFS, gentoo, ou archlinux archlinux 32, …
peut etre coté BSD ?
Je ne ferai pas cet effort de migrer, pour ma part.
Je ferai N°2 en attendant de pourvoir changer mes 2 ebox qui servent de backup, dhcp, dns, VPN.
[^] # Re: fin du support 32 bits - meme question
Posté par M . Évalué à 5 (+4/-1).
Il y a aussi l'ELTS
https://wiki.debian.org/LTS/Extended
2033 pour bookworn
Perso j'ai un portable sous bullseye et je ne sais pas trop quoi faire.
A chaque nouvelle release, tout devient plus fat coté disque et mémoire.
Et tout ça pour des trucs qui m’intéresse pas.
Je fait 98% de firefox, un peu de gimp, vi, git, gcc. Les versions actuelles me convienne bien.
Le seul truc c'est les mise à jour de sécu et pour le web, les navigateurs plus supporté.
Et au boulot chaque migration apporte sont lot de mauvaise surprise : de 11 à 12, le suspend est cassé et freeze assez fréquemment. De 12 à 13 systemd m'a fait une blague avec les partition chiffré et j'ai perdu quelques heures à investiguer.
Sous bullseye j'ai encore un an de LTS et 6 ans de ELTS. Il est fort possible que je ne migre pas.
[^] # Re: fin du support 32 bits - meme question
Posté par lym . Évalué à 5 (+4/-0).
Mon fixe passé de 12 à 13 me pose également des pb de suspend, avec assez fréquemment des messages pointant la feature lockdown du kernel (pourtant pas nouvelle) qui semble s'activer dès lors que le secure boot est utilisé… Et qui n'est alors pas désactivable entièrement. Cela semble s'ajouter à d'autres problèmes causés par systemd qui refuse aussi le suspend quand certains applicatifs (réseau en particulier) sont lancés, alors qu'avant c'était possible et n'a jamais posé de pb… Cela reprenait juste son cours au réveil.
Exemple de config lockdown sur un système non secure-boot:
cat /sys/kernel/security/lockdown
[none] integrity confidentiality
On est alors en "none"=lockdown inactif.
Mais sur un système avec secure-boot on sera par défaut à "confidentiality" sans retour en arrière possible et dans ce cadre un swap non chiffré suffit à prévenir le suspend… alors que mon système n'a pas de partition swap, n'en faisant plus sur des machines 100% SSD! A croire que ce cas n'est pas prévu, si toutefois un âne n'a pas décidé que si l'utilisateur ne faisait pas de swap à l'installation on lui créait un fichier destiné à cet usage derrière son dos… A voir, mais ça fait juste hautement chier de chercher des parades à des trucs qu'on évitait sans pb avant.
En secure boot donc, tout au plus peut-on configurer via la kernel-cmdline/grub d'être, au plus permissif, à "integrity" au boot: La désactivation ne sera pas acceptée! Mais de quoi je me mêle? Si un attaquant est déjà root il aura bien plus simple à faire qu'aller lire un swap en clair merde!
Et, niveau config toujours, si sur le runtime qui suit on passe pour test à "confidentiality" via le sysfs ci dessus, effet cliquet: Pas de retour en arrière possible sur le runtime courant, obligé de rebooter.
C'est vraiment une feature assez détestable, comme tout ce qui devient impossible à régler/tester en root. Il y a un moment ou il va falloir que Linux cesse d'évoluer vers des modes prétendument "foolproof" en singeant un android et autres OS qui donnent l'impression qu'on ne possède pus réellement ce qu'on a pourtant acheté.
[^] # Re: fin du support 32 bits - meme question
Posté par MrLapinot (site web personnel) . Évalué à 2 (+0/-0).
Si un attaquant qui compromet ta chaîne de démarrage ne fait pas partie de ton modèle de sécurité, pourquoi ne pas tout simplement désactiver secure boot ?
[^] # Re: fin du support 32 bits - meme question
Posté par rictus (site web personnel) . Évalué à 3 (+2/-0).
Vu ton usage, pourquoi pas openwrt ou alpine linux ?
[^] # Re: fin du support 32 bits
Posté par Indrik . Évalué à 4 (+4/-0).
Par exemple, Mageia Linux 32 bits (pour Intel 586).
https://www.mageia.org/fr/
[^] # Re: fin du support 32 bits
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 11 août 2025 à 21:09.
Mageia 9…
Pour Mageia 10, ce n'est pas encore complètement décidé de ce que j'en ai compris. Mais cela pourrait être conservé comme pour les archis arm, et ce n'est que mon avis :p (sans le soutien de la communauté projet Fedora, ça va être plus compliqué… jdçjdr). Cela fonctionne encore actuellement en Cauldron, suffit de ne pas le désactiver (mais enlever les paquets réclamant du 64 bits ou des instructions SSE non disponibles en 32 bits ou de l'OpenGL trop récent)
Et ce serait bien utile pour mon EeePC 901 dont le CPU n'est que 32 bits :/
[^] # Re: fin du support 32 bits
Posté par dr191 . Évalué à 2 (+1/-0).
Pour la nostalgie:
EeePC 701, qui démarre encore, en principe.
2 ebox B202 qui tournent H24 depuis +15 ans, évoqués plus haut.
[^] # Re: fin du support 32 bits
Posté par C. OB (site web personnel) . Évalué à 4 (+3/-0).
Oh moi j'ai encore des plateforme en x86:
(actuellement ça tourne en Debian 9 et ça va rester comme ça un moment :-) Le media est une CF-CARD dont j'ai des copies…)
[^] # Re: fin du support 32 bits
Posté par Indrik . Évalué à 2 (+2/-0).
Merci pour l'information.
Ce serait dommage si Mageia n'avait plus de version 32 bits, parce qu'elle est une des rares distributions Linux qui est à la fois un Unix classique, à l'ancienne (avec un super-utilisateur "root" présent par défaut, etc), et facile pour les débutants.
[^] # Re: fin du support 32 bits
Posté par lym . Évalué à 1 (+1/-1).
Dans les distro basées sur un compte admin qui est en fait sudoer, le compte root s'active d'un "sudo passwd root". Dès que le compte root à un mdp il est utilisable.
Utilisateur/groupe, tout est en fait déjà là et on ne saurait s'en passer de toutes manières.
Il est même assez conseillé de faire cette activation, surtout si on a fait les choses comme il faut à l'install avec une partition home séparée (voir sur un stockage différent): Le "home" du compte root étant /root il sera accroché à la partition racine et donc fonctionnel pour se tirer d'affaire si la partition home a un problème suite à un arrêt brutal (même si un FS journalisé permet généralement de s'en sortir) ou autre: C'est quand même plus simple quand il s'agit de comprendre/résoudre un pb que de devoir utiliser un live-USB et savoir monter les FS à vérifier niveau intégrité, logs…
[^] # Re: fin du support 32 bits
Posté par Pierre Tramal (site web personnel) . Évalué à 9 (+8/-0).
La plupart des packages restent buildés et disponibles pour i386[1], et ciblant un processeur au moins "686" (donc à partir du Pentium Pro) - ce qui était le cas depuis stretch. Ces packages ont un rôle officiellement limité à du multiarch ou un chroot sur un système amd64. Mais officieusement… ;-)
Ce qui disparaît c'est le support de l'installeur (donc les ISO etc) et les images du noyau. Donc pour l'instant rien n'empêche de faire la mise à jour (même si elle est officiellement déconseillée), et si besoin mettre à jour son noyau en le compilant soi-même, ou installer à partir d'une ancienne version (puis mettre à jour) ou utiliser une méthode alternative comme debootstrap.
[1] : https://ftp.debian.org/debian/dists/trixie/main/ - on notera la présence d'un "binary-i386" mais la disparition de "installer-i386".
[^] # Re: fin du support 32 bits
Posté par floppy . Évalué à 6 (+6/-0).
L'absence de package du noyau est quand même un gros point noir, difficile à comprendre d'ailleurs car l'architecture i686 étant toujours supportée officiellement par Linux, ça parait peu coûteux à maintenir par rapport aux autres packages. Ça ressemble davantage à une décision individuelle du mainteneur Debian des packages linux-kernel qu'à une vraie stratégie de Debian par rapport au 32 bits. Parmi les alternatives à Debian avec un bon support 32 bits, je signale Void Linux, distribution peu connue mais pleine de qualités : bon gestionnaire de paquet (xbps), runit à la place de systemd, rolling release.
[^] # Re: fin du support 32 bits
Posté par BAud (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 12 août 2025 à 13:05.
ah bah tiens, on vient de trouver le fork floppy_linux :D
bin oui,
et les distros dans l'embarqué il en reste plein (sans Debian ça va être plus compliqué :/ reste Gentoo)
moi ce qui me dérange c'est les développeurs qui imposent OpenGL 3.6 et le 64 bits là où ils pourraient (ne pas) gérer l'obsolète pour de meilleures performances.
[^] # Re: fin du support 32 bits
Posté par srb (site web personnel) . Évalué à 3 (+2/-0).
Non, il y a eu une discussion fournie sur une des listes de diffusion pour prendre cette décision ; certains voulant la garder et d'autres non.
De mémoire, les arguments pour l'abandon :
- L'usage des processeurs 32 bits est en baisse constante et ça devrait s'accélérer (cf. statistiques popcon.debian.org).
- Plus aucun fournisseur majeur ne produit du 32 bits depuis plusieurs années. Il existe (au moins) un fournisseur pour de l'embarqué mais il n'y a pas de garanties sur les instructions donc il est possible que ça paraisse fonctionner mais finalement pas en usage réel.
- Supprimer une architecture, c'est s'alléger de la maintenance.
[^] # Re: fin du support 32 bits
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
D'un côté l'architecture i686 n'a que 6000 répondants parmi les participants à popcon, loin derrière amd64 (250000). On rappelle que c'est un opt-in lors de l'installation de Debian, donc le nombre absolu ne veut pas forcément dire grand chose.
D'un autre côté, c'est tout de même la deuxième architecture la plus popualaire (entre amd64 et arm64 qui lui n'a que 2000 répondants).
[^] # Re: fin du support 32 bits
Posté par srb (site web personnel) . Évalué à 2 (+1/-0).
Tout à fait: il faut regarder les ordres de grandeur et les tendances. Certains mainteneurs amont abandonnent la gestion x86_32 alors que Debian doit maintenir la distribution 4 ans (environ 2 ans pour stable et 2 autre années pour oldstable). Ensuite, il y a les projets LTS et ELTS (qui sont financés) qui vont aussi devoir le maintenir sur des années donc ce n'est pas une décision prenant uniquement en compte la capacité à sortir un installeur.
Quelqu'un vient aussi de découvrir l'absence de support officiel. Sa demande sur debian-devel et les réponses redonnent un peu de contexte : https://lists.debian.org/debian-devel/2025/08/msg00124.html
[^] # Re: fin du support 32 bits
Posté par Sytoka Modon (site web personnel) . Évalué à 6 (+4/-0).
Les projets LTS et ELTS ne sont pas financés sur le saint-esprit. Il faut chaque année contribuer et motiver son entité de travail à participer au programme si Debian est utilisé dans l'entité.
L'argent ne vient pas du ciel. Donc hop, un tour chez freexian et une demande de devis. Je rappelle que freexian fonctionne aussi avec des bons de commande et Chorus donc si vous êtes dans la fonction publique, c'est une possibilité de financer du libre.
[^] # Re: fin du support 32 bits
Posté par Vivien (site web personnel) . Évalué à 1 (+1/-0).
Je pense qu'il y a aussi le problème des incompatibilités.
J'ai un vieux PC 32bits (les derniers Pentium dual core 32bits pour PC portable) et j'ai vu que si sous Ubuntu 18.04 tout fonctionnait bien en 32 bits sauf pour les DRM (aucun navigateur ne propose de DRM en 32bits que ce soit Firefox ou Chromium) avec Debian 12 plusieurs applications ne fonctionnent plus en 32 bits :
- Filezilla
- Wine
- Virtualbox
- …
Il y a donc des bugs qui entraînement une expérience dégradée en 32 bits.
[^] # Re: fin du support 32 bits
Posté par Vivien (site web personnel) . Évalué à 2 (+2/-0). Dernière modification le 24 août 2025 à 10:04.
La fin du 32 bits pour les DRM date de 2021 :
```
Google ended Widevine support for 32-bit Linux on May 31, 2021.
And that’s what caused problems for the handful of users who are still rocking an older computers with 32-bit Linux distributions.
When the browser was updated, Widevine support was pulled out. Even though it shows that DRM is still enabled in the browser, the plugin won’t work.
```Source : https://news.itsfoss.com/netflix-issue-32-bit-linux/
[^] # Re: fin du support 32 bits
Posté par dr191 . Évalué à 1 (+0/-0).
Re,
Je n'ai pas compilé un noyau depuis très longtemps.
Il faut partir de kernel.org et adapter à la sauce debian ?
[^] # Re: fin du support 32 bits
Posté par lym . Évalué à 1 (+0/-0).
Je pense qu'il vaut mieux partir des dépots source histoire d'avoir les bonnes versions pour ne pas poser de pb au load de modules tiers, patchs Debian éventuels et la config kernel de base à utiliser au make à modifier (make menuconfig) côté CONFIG_X86_64 et tout ce qui en dépends.
Même si en choisissant bien sa version noyau sur kernel.org et en récupérant le /boot/config-XXX-amd64 d'une machine Debian cela devrait pour l'essentiel fonctionner.
# [hors-sujet] J'ai cassé la note 42
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 6 (+6/-2). Dernière modification le 14 août 2025 à 23:17.
À mon grand désarroi, je me suis retrouvé face à une dépêche sur la sortie d'une nouvelle version de Debian notée 42. Grand dilemme, est-ce que je laisse comme ça, ou je pertinente ?
Bref, voilà, après longue hésitation j'ai pris mon courage à deux mains, mon cœur battait plus vite, puis j'ai cliqué sur "Pertinent", puis je me suis enfui.
Zut, faudra maintenant aller jusqu'à 64 comme prochain nombre rond, en plus ce serait assez approprié point de vue support des architectures dans Trixie ("Trixie" avec deux 'i', facile à retenir). Ou est-ce que Trixie saurait aller jusqu'à 128 ?!
(Y a-t-il déjà eu un graphe montrant la progression d'une note d'une dépêche ou journal LinuxFr, pour voir que ça bloque plus longtemps aux alentours de 32, 42, 64 ?)
Bon sur ce,
-->[][^] # Re: [hors-sujet] J'ai cassé la note 42
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 15 août 2025 à 10:09.
Jamais vu ça et je ne l'ai jamais produit en tout cas. Sur l'année passée (plus précisémment sur la disponibilité des logs web) ou sur les trois derniers mois (plus précisément sur la disponibilité des notes sur les dépêches dans redis), en regardant les dépêches notés au-dessus de 32, ça pourrait se faire. Avec un doute préalable sur la signification statistique car les volumes doivent être faibles.
[^] # Re: [hors-sujet] J'ai cassé la note 42
Posté par Faya . Évalué à 3 (+2/-1). Dernière modification le 15 septembre 2025 à 16:02.
Là on est à 64… Pratique pour une dépêche ou la plupart des commentaires se plaignent de la fin du support 32 bits. Je pertinente mentalement mais ne cliquerai pas.
[EDIT] le temps que je valide mon commentaire on est passé à 65 ! Du coup c'est bon je peux pertinenter…
# Commentaire supprimé
Posté par HatsueFujino . Évalué à -2 (+0/-2). Dernière modification le 21 août 2025 à 08:12.
Ce commentaire a été supprimé par l’équipe de modération.
# Quand faire une mise à jour de distribution
Posté par muchos (site web personnel) . Évalué à 5 (+4/-0).
Merci pour la dépêche !
Quelle est la pratique conseillée pour mettre à jour ma Debian ? Est-ce que j’attends la fin du support long, puis je mets à jour vers la dernière version en cours ? Ou est-ce que c’est préférable de le faire version par version ? Merci d’avance.
Debug the Web together.
[^] # Re: Quand faire une mise à jour de distribution
Posté par BAud (site web personnel) . Évalué à 6 (+5/-1). Dernière modification le 24 août 2025 à 14:03.
nope, c'est généralement une réinstallation qui est préconisée
moui… une mise à jour continue est franchement plus longue pour une montée de version (où en outre pas mal de paquets réputés obsolètes préalablement, deviennent abandonnés). Donc, si tu as plusieurs versions de retard, tu vas au devant de pas mal de déconvenues…
Si tu regardes le passé, ça te donne une idée des ruptures : passage de noyau 2.4 à branche des 2.6.x (ça encore…), gestion UEFI, passage à systemd, abandon du 32 bits maintenant (ce qui n'en fait plus une cible) => pas mal de galères et réduction de ce qui est faisable, outre l'évolution du matériel entre-temps
[^] # Re: Quand faire une mise à jour de distribution
Posté par Benoît Sibaud (site web personnel) . Évalué à 9 (+6/-0).
Ne pas faire la montée de version à chaque version donne plus de boulot ensuite (vu qu'il faut gérer une montée de plusieurs versions). Et petit à petit on commence à avoir des soucis de « vieux logiciels » (entre les postes clients à jour et les serveurs en retard par exemple).
Les mises à jour de sécurité sortent d'abord pour la version stable en cours, donc c'est un peu mieux niveau sécurité d'être en stable.
L'idéal pourrait être de tout réinstaller à chaque fois avec la dernière version (ça dépend si on sait automatiser ou bien gérer le transfert des données de l'ancienne à la nouvelle), mais sinon les mises à jour se font très bien.
J'ai fait les montées de version depuis Debian 12 bookworm vers 13 Trixie pour LinuxFr.org sur 3 serveurs, 1 VM et 2 conteneurs LXC par exemple : les releases notes sont très détaillées, les changements annoncés, ça se fait bien. Parce que la quantité de machines est raisonnable. Si je devais gérer des dizaines/centaines/milliers de machines, je ne passerai pas par les mises à jour, j'automatiserais le déploiement d'installations neuves.
[^] # Re: Quand faire une mise à jour de distribution
Posté par Sytoka Modon (site web personnel) . Évalué à 3 (+1/-0).
Le problème comme tu le dis, ce n'est pas tellement la mise à jour, mais la quantité. Quelques serveurs, 100 serveurs, 1000 serveurs…
Dans toutes les mises à jour, que ce soit installations neuves ou mises à jour, on a par exemples les soucis suivants : changement dans les fichiers de config à faire, changement dans le schéma de la base de donnée qui n'est plus parfaitement compatible avec l'ancienne, changement dans l'interface du service, changement dans les fonctionnalités…
Bref, la quantité prends du temps et ce n'est pas le full-upgrade le plus compliqué de l'affaire.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.