Discussion :

[Stéphane le calme]

Arnd Bergmann : aucun produit moderne ne justifie encore le recours au 32 bits.
pour le responsable général de la compatibilité architecturale dans le noyau Linux, le temps est venu de parler de sa suppression

Pendant des décennies, le 32 bits a incarné la norme dans l’univers informatique. Le noyau Linux, né au début des années 1990 sur des processeurs 386, a grandi en même temps que l’architecture IA-32 et ses dérivés. Pendant longtemps, l’idée même de porter Linux sur une machine 64 bits paraissait exotique, réservée aux stations de travail haut de gamme ou aux serveurs.

Mais l’évolution de la micro-informatique a radicalement changé la donne. Dès le milieu des années 2000, l’adoption massive du 64 bits par les processeurs x86-64 d’AMD puis d’Intel a déplacé le centre de gravité du développement. Aujourd’hui, le 32 bits vit dans une sorte de crépuscule, toléré pour des raisons de compatibilité ou de niches industrielles, mais de plus en plus perçu comme un poids mort.

Le 32 bits a longtemps été le socle de l’informatique moderne. Lorsque Linus Torvalds publiait les premières versions de son noyau en 1991, il ciblait naturellement les processeurs Intel 386, architecture reine du moment. Pendant plus d’une décennie, l’écosystème Linux s’est bâti sur cette base, accompagnant l’essor des PC de bureau, des serveurs et plus tard des systèmes embarqués. Mais trois décennies plus tard, le constat est sans appel : le 32 bits est devenu un héritage encombrant, coûteux à maintenir et de plus en plus marginalisé par l’essor massif du 64 bits.

Arnd Bergmann, mainteneur de la compatibilité architecturale dans le noyau Linux, a récemment exposé cette réalité sans détour lors de l’Open Source Summit Europe 2025 : aucun produit moderne ne justifie encore le recours au 32 bits. La seule raison de le garder en vie est de continuer à supporter du matériel ancien ou des logiciels figés.

Une obsolescence évidente mais pas uniforme

Dans le domaine du poste de travail et des serveurs, la question est réglée depuis longtemps. Les systèmes Unix avaient migré vers le 64 bits dès les années 1990, suivis par Linux au début des années 2000. Même les téléphones et tablettes ont franchi le pas il y a déjà une dizaine d’années. Dans ces univers, maintenir du 32 bits est un anachronisme.

Mais le monde Linux ne se limite pas aux machines de bureau. Dans l’embarqué, la situation est plus nuancée. Près de 90 % de ces systèmes reposent encore sur des processeurs ARM, et une large proportion d’entre eux tournent toujours sur ARMv7, une architecture 32 bits. Ce n’est que récemment que le nombre de cartes ARMv8 (64 bits) supportées dans le noyau a dépassé celui des cartes ARMv7. D’autres architectures 32 bits persistent encore, comme OpenRISC, Xtensa, ou SPARC/Leon, mais elles sont systématiquement remplacées par RISC-V dans les nouveaux projets.

Le coût caché du maintien

Si la communauté Linux envisage sérieusement de tourner la page du 32 bits, ce n’est pas seulement pour des raisons idéologiques. C’est avant tout une question de coûts et de complexité. Chaque évolution du noyau (qu’il s’agisse de sécurité, de gestion mémoire ou de virtualisation) doit tenir compte des contraintes du 32 bits.

Le point le plus douloureux concerne la gestion de la mémoire. Les systèmes 32 bits ne peuvent adresser que 4 Go de RAM, et au-delà de 800 Mo, le noyau doit recourir à des mécanismes complexes appelés « high memory ». Or, ce code est devenu un véritable casse-tête pour les développeurs, introduisant bogues et dettes techniques. Des solutions alternatives, comme le modèle « densemem » ou l’utilisation de zram pour exploiter de la mémoire au-delà des limites natives, sont à l’étude, mais rien ne compense réellement l’élégance et la puissance d’un noyau 64 bits.

Des échéances déjà posées

Certaines dates sont déjà dans le viseur. Le support de la mémoire haute devrait être abandonné d’ici 2027, et celui des processeurs sans unité de gestion mémoire (nommu), comme certains Cortex-M, devrait suivre vers 2028. En revanche, ARMv7 bénéficiera encore d’un sursis d’au moins dix ans, car de nouvelles cartes embarquées continuent d’être produites avec ces processeurs.

Mais tout le reste disparaîtra plus rapidement. Les processeurs i486, par exemple, ne sont plus vraiment utilisables dans les noyaux récents et ne subsistent que par inertie. Les vieilles générations d’ARM, comme les ARMv4 ou certains ARMv6, compliquent inutilement le code et devraient être supprimées.

Le spectre de l’an 2038

À cette équation s’ajoute un problème bien connu : le bogue de l’an 2038. Les systèmes 32 bits représentent le talon d’Achille de ce bogue lié au débordement de la variable time_t. Si le noyau et les bibliothèques C principales (glibc, musl) ont été corrigés, des milliers de logiciels tiers ne le sont toujours pas. Selon Arnd Bergmann, la moitié des applications utilisant futex() sont encore incapables de gérer correctement le temps après 2038. Dans ces conditions, il estime qu’aucun système 32 bits de bureau ne survivra à cette échéance.

Une transition inévitable

Un membre du public a demandé comment les développeurs savent si un processeur est toujours utilisé ou non. Bergmann a reconnu que cela pouvait être une question difficile. Pour la prise en charge x86, il a consulté de nombreuses anciennes pages web afin de dresser une liste des systèmes existants, puis a montré que chacun de ces systèmes était déjà défectueux dans les noyaux actuels pour d'autres raisons ; l'absence de plaintes indiquait qu'il n'y avait pas d'utilisateurs. Pour les autres, il est nécessaire de fouiller dans l'historique Git, de voir quels types de modifications sont apportées et de demander aux développeurs qui ont travaillé sur le code ; ce sont eux qui savent qui utilise cette prise en charge.

Quoiqu'il en soit, la trajectoire est claire : le 32 bits dans Linux entre dans sa phase terminale. Il continuera d’exister pour des niches industrielles, des produits embarqués à longue durée de vie ou pour quelques passionnés d’informatique rétro, mais son avenir est limité. La philosophie qui guide la communauté kernel est pragmatique : maintenir ce qui est encore utilisé, isoler le code pour ne pas freiner les évolutions majeures, et supprimer dès que possible ce qui n’a plus d’usagers réels.

Il ne s’agit pas d’un deuil, mais plutôt de la fin naturelle d’un cycle. Le 32 bits a permis à Linux de naître, de croître et de conquérir des pans entiers de l’industrie. Son retrait progressif signe la maturité d’un écosystème désormais tourné vers l’avenir, dominé par le 64 bits et porté par l’essor du RISC-V.

Sources : Open Source Summit, LWN

Et vous ?

Les systèmes embarqués basés sur ARMv7 ou d’autres 32 bits justifient-ils encore à eux seuls le maintien du support dans le noyau principal ?

Ne serait-il pas plus efficace que les industriels embarqués gèrent eux-mêmes des noyaux spécialisés, plutôt que d’imposer ce poids à l’ensemble de la communauté ?

À partir de quel seuil d’utilisateurs ou de matériel en circulation une architecture peut-elle être considérée comme « officiellement morte » dans Linux ?

Le maintien du 32 bits ralentit-il réellement l’évolution du noyau Linux ou bien son impact est-il marginal face aux autres dettes techniques ?

Faut-il isoler le code 32 bits dans des branches spécifiques, à l’image de ce qui se fait pour certaines architectures exotiques, plutôt que de le maintenir dans le tronc principal ?

L’abandon du support mémoire haute (high memory) en 2027 sera-t-il une libération pour les développeurs, ou au contraire une perte pour certaines niches encore dépendantes ?

[RenarddeFeu]

C'est une légende urbaine persistante l'histoire des processeurs 32bits qui ne peuvent gérer que 4Go de RAM.

D'une part, le noyau Linux a une fonctionnalité PAE qui une fois activée étend la limite à 64Go (la limite de 4Go par processus persiste néanmoins). D'autre-part, cela est un choix de conception de la part des développeurs et non une impossibilité matérielle. Du temps des processeurs 8bits et 16bits, le bus d'adresses était généralement plus large que le bus de données.

[Christophe]

aucun produit moderne ne justifie encore le recours au 32 bits.

C'est vrai. Le prob se situe plutôt sur les anciens produits couteux. Un CPU 64 bits peut faire fonctionner un logiciel 32 bits (sauf si l'OS ne le permet pas). Le prob va plutôt se situer au niveau des pilotes. Si le logiciels utilise des équipements spécifiques sans pilotes 64 bits, le logiciel sera inutilisable.
En VM, on peut faire fonctionner un OS complet 32 bits sur un CPU 64 bits. La problématique étant obsolescence des OS, Wndows 10 étant le dernier Windows fourni en 32 bits, et sur Linux les versions à jour 32 bits disparaissent également.

Ce ne sera plus possible pour les CPU Intel le jour ou ils enlèveront la rétrocompatibilité. J'ai vu un article ici-même évoquant qu'Intel y songeait.

[OuftiBoy]

Dans le domaine l'embarqué, pour des produits à fort volume de vente, l'utilisation de µContrôleurs 8-bits reste indispensable. Si un "choix" permet d'économiser 5 ou 10 cents d'€, cela fait au final une très grande différence, pouvant se compter en millier ou en dizaine/centaines de milliers d'€ au final.

Si on peut se permettre sur un PC d'ajouter 8Go pour mieux supporter et ne pas faire ramer le PC, c'est un argument qui s'entend, mais c'est un autre monde.

[floyer]

@RenarddeFeu :
L'exemple du processeur 8bits est mauvais, car sur un Z80 par exemple, on pouvait coupler des registres (BC, DE, HL) pour travailler avec des registres 16bits (quitte à ce que le microcode fasse 2 aller-retours dans l'ALU pour travailler sur 16bits).
Le cas du 8086 (16 bits, mais 20 bits d'adressage) est particulier... faire une arithmétique des pointeurs est tout sauf pratique (avec les registre de segments), mais possible.
L'architecture des 80386 et 80486 est limitée à 4Go (ce n'est pas une légende). Il faut le Pentium pour aller au delà.