Linus Torvalds réhabilite l'écran bleu de la mort de Windows et explose un mythe : « Une grande partie de ces problèmes ne sont en réalité pas dus à des bugs logiciels... mais à un matériel peu fiable »

[Raccoon]

Lors d’un long échange vidéo avec Linus Tech Tips, Linus Torvalds a livré l’un de ses commentaires les plus intéressants sur un vieux mème de l’informatique : le « Blue Screen of Death » de Windows. Loin de rire de Microsoft, il explique qu’une part importante des écrans bleus n’a rien à voir avec un mauvais OS… mais avec du matériel peu fiable, de la mémoire sans ECC et des pratiques d’overclocking agressives. Derrière la blague, c’est toute une culture du PC « gaming » et du hardware grand public qui est remise en question.

Fin mars 2025, Microsoft a annoncé en avant-première la refonte de son tristement célèbre « écran bleu de la mort » (Blue Screen of Death en anglais – BSOD) dans Windows 11. Le nouveau design abandonne la couleur bleue traditionnelle et le code QR en faveur d’un écran simplifié qui ressemble beaucoup plus à l’écran noir que vous voyez lorsque Windows effectue une mise à jour.

Microsoft annonçait : « Nous présentons en avant-première une nouvelle interface utilisateur plus rationnelle pour les redémarrages inattendus, qui s’aligne mieux sur les principes de conception de Windows 11 et soutient notre objectif de permettre aux utilisateurs de retrouver leur productivité aussi rapidement que possible. Nous avons simplifié votre expérience tout en préservant les informations techniques à l’écran. »

Lors de la preview, il n’était pas encore certain que le nouveau BSOD resterait un écran noir une fois la version finale de la mise à jour publiée. Il semble désormais que ce nouvel écran noir de la mort soit la nouvelle interface définitive du BSOD.

« Nous rationalisons l’expérience du redémarrage inattendu », a déclaré David Weston, vice-président de Microsoft chargé de la sécurité des entreprises et des systèmes d’exploitation. « Nous ajoutons également la récupération rapide de la machine, un mécanisme de récupération pour les PC qui ne peuvent pas redémarrer avec succès. Ce changement s’inscrit dans le cadre d’un effort continu et plus large visant à réduire les perturbations en cas de redémarrage inattendu ».

Un contexte léger, une remarque lourde de sens

La séquence ne part pourtant pas d’un débat théorique sur les systèmes d’exploitation, mais d’un sujet très concret : la machine Linux « idéale » pour Linus Torvalds. Il discute avec l’équipe de Linus Tech Tips du choix du processeur, de la carte mère, de la mémoire et du refroidissement, avec un leitmotiv constant : il veut une machine fiable, silencieuse, pas nécessairement une machine à la pointe de la technologie mais solide.

C’est dans ce cadre que la question de la mémoire ECC arrive sur la table. Torvalds raconte qu’il avait construit une machine sans ECC, en se disant que de la RAM « raisonnable » suffirait. Elle a bien fonctionné pendant quelques années, jusqu’au moment où il a commencé à voir des « oops » dans le kernel, des segfaults, des comportements aberrants. Comme tout bon mainteneur, sa première réaction a été de suspecter un bug dans Linux. Il passe plusieurs jours à chercher… avant de réaliser que le problème ne venait pas du code, mais du matériel. Sa machine n’était tout simplement plus fiable.

À partir de là, il devient catégorique : pour lui, ne pas avoir d’ECC sur une machine de travail est impensable. Et c’est précisément à ce moment qu’il glisse sa fameuse remarque sur Windows et le Blue Screen of Death.

« Une grande partie des écrans bleus n’étaient pas des bugs logiciels »

Torvalds explique, presque en passant, qu’il est convaincu qu’une part significative de la mauvaise réputation de Windows vient de machines matériellement douteuses. Il le formule de manière très directe : selon lui, beaucoup de blagues sur l’instabilité de Windows et les écrans bleus ne reflètent pas vraiment des bugs de l’OS, mais de la mémoire défectueuse, des alimentations limites, des overclockings instables, bref, une base matérielle sur laquelle aucun système n’est vraiment capable d’être fiable.

Il insiste notamment sur deux facteurs.

D’abord, l’absence d’ECC dans la plupart des PC grand public. Sans correction d’erreurs de bout en bout, la RAM finira par produire des erreurs, ce n’est qu’une question de temps. Parfois au bout de deux ans, parfois plus tard, mais cela finit par se manifester. Dans son propre cas, ces erreurs se traduisaient par des comportements incompréhensibles du noyau, au point de faire douter du code lui-même.

Ensuite, les pratiques d’overclocking dans le monde du gaming. Pour “gratter” quelques pourcents de performances, on pousse CPU, GPU et RAM jusqu’à leur limite, au prix d’une stabilité moindre. Torvalds rappelle que cela introduit une dose d’aléatoire supplémentaire et fragilise l’ensemble de la pile. Quand le système finit par planter, ce n’est pas nécessairement parce que Windows est un mauvais OS, mais parce qu’on lui demande de tenir debout sur du matériel borderline.

Le BSOD comme symptôme, pas comme coupable

Ce renversement de perspective est important. Dans l’imaginaire collectif, le Blue Screen of Death symbolise le mauvais goût, la mauvaise conception, voire l’incompétence de Microsoft. Torvalds adopte une vision beaucoup plus structurelle : l’écran bleu est, dans bien des cas, le symptôme assez honnête d’un environnement d’exécution qui n’est plus digne de confiance.

De ce point de vue, Windows se comporte exactement comme il le faudrait. Quand l’OS détecte que le système est passé dans un état illégal, incohérent ou dangereux, la réponse saine est de s’arrêter brutalement. Continuer à exécuter du code dans un univers où la mémoire ment et où les invariants de base ne tiennent plus relèverait de l’inconscience.

Torvalds ne dit pas que Windows est parfait, ni qu’il n’a jamais eu de bugs de kernel. Mais il remet la responsabilité au bon niveau : si l’OS se retrouve face à une avalanche de corruptions mémoire, l’écran bleu est un mode de défaillance acceptable. Le vrai scandale est que tant de machines grand public soient vendues sans le minimum de garde-fous matériels, tout en étant ensuite utilisées comme étalon de la « fiabilité » de l’OS.

Voici un extrait de cet échange (et l’échange en entier en vidéo) :

Je m’amuse beaucoup trop aujourd’hui. C’est la meilleure journée que j’ai passée au bureau depuis très longtemps. Sérieusement. Choisir une carte mère pour Linux est assez simple. Vous voulez toutes les fonctionnalités habituelles d’une carte mère : un bon refroidissement, une bonne alimentation, toutes les E/S que vous souhaitez, mais bien sûr, vous voulez vous assurer que tous les composants intégrés sont pris en charge par Linux. L’une des choses importantes que nous avons recherchées dans une plateforme pour vous était également la prise en charge de la mémoire ECC.

Pouvez-vous nous expliquer pourquoi c’est si important ?

Je ne comprends pas pourquoi les gens ne demandent pas la prise en charge ECC pour leurs machines, car pouvoir faire confiance à sa machine est la chose la plus importante, et sans ECC, votre mémoire finira par se détériorer. Ce n’est pas une question de « si », mais de « quand ». Cela peut prendre quelques années. Lorsque j’ai assemblé la machine, vous avez apparemment tourné une vidéo. Je n’ai pas pu obtenir l’ECC et j’ai dit que j’allais prendre une RAM raisonnable et ça a bien fonctionné. Ça a bien fonctionné pendant deux ans, puis deux ans ont passé et j’ai commencé à voir des erreurs. J’ai commencé à voir des violations de segmentation. Je fais évidemment cela sur un noyau Linux moderne qui est en cours de développement. Ma première réaction a été : « Oh non, nous avons un bug. » J’ai passé des jours à essayer de comprendre quel était le bug, jusqu’à ce que je réalise que non, ce n’était pas du tout un bug. C’était ma machine qui n’était pas fiable.

Donc pour vous, il ne s’agit pas de savoir si je dois redémarrer mon système parce que mon jeu a planté.

Exactement. Il s’agit plutôt du fait que je travaille sur un logiciel utilisé par des millions de personnes à travers le monde. J’ai besoin de savoir, n’est-ce pas ? Je dois absolument pouvoir faire confiance à ma machine. Et c’est très important. Et je suis convaincu que toutes les blagues sur l’instabilité de Windows et les écrans bleus, enfin, je suppose que ce ne sont plus des écrans bleus, ne sont pas fondées. Une grande partie de ces problèmes ne sont en réalité pas dus à des bugs logiciels. Une grande partie d’entre eux sont dus à un matériel peu fiable. Et dans la communauté des gamers, vous faites aussi de l’overclocking, ce qui ajoute à l’instabilité. Vous trouverez des articles qui expliquent que la mémoire DDR intègre la technologie ECC. Mais non, ce n’est pas le cas. Ce n’est vraiment pas le cas. Certaines puces intègrent la technologie ECC, mais si un problème survient entre la barrette de mémoire et le processeur, vous ne le saurez jamais. Vous avez donc besoin d’une technologie ECC de bout en bout. Je pense en fait que c’est l’une des affirmations marketing les plus scandaleuses de notre époque.

ECC, fiabilité et culture du « bon PC » selon Torvalds

L’autre élément clef de cette séquence, c’est la radicalité avec laquelle Torvalds parle de l’ECC. Là où beaucoup de constructeurs se contentent de slogans marketing du type « DDR avec ECC intégré dans les puces », il démonte ce discours : si la correction d’erreurs ne couvre pas toute la chaîne, du module de mémoire au contrôleur dans le CPU, alors ce n’est pas une vraie protection.

Pour lui, il faut un ECC de bout en bout. Sinon, les corruptions sur le bus, dans les buffers, ou dans certaines parties de la chaîne ne seront jamais détectées. Et c’est à ce moment que les « bugs fantômes » apparaissent : un crash ici, un comportement étrange là, qu’on finit par attribuer aux développeurs ou au système d’exploitation.

Sa règle personnelle est limpide : il ne touche pas à des machines sans ECC. Pour un mainteneur du kernel Linux, cette exigence est un prérequis, pas un luxe. Il a besoin de savoir, en permanence, que si une anomalie apparaît, il peut raisonnablement suspecter le logiciel avant le matériel, au lieu de perdre des jours à chasser un bug imaginaire.

Power supply, refroidissement, overclocking : une vision très « ops »

Tout au long de la vidéo, on voit se dessiner une philosophie matérielle très différente de celle du PC « enthousiaste ». Torvalds se moque des solutions trop exotiques ou trop orientées performance [censored]…

Suite de l’article réservée aux abonnées : developpez.com

[duJambon]

Hum, des machines parfaitement montées sans être overclockées plantaient quand même sous windows et beaucoup moins sous linux, même si le nombre d’applications n’avait rien à voir (surtout les farfelues)…

D’un côté, de bons programmeurs (souvent du libre) et de l’autre le fric rapide, à mon humble avis, le problème est surtout là.

[Violence]

Clairvoyant comme (presque) toujours.

Concernant les écrans bleu, je suis plutôt d’accord avec Linus.
Ils ont d’ailleurs été créés pour des bugs matériels et non logiciels.
Les haters en font une montagne de taupinières pour pas grand chose. Ils sont fatigants les ouins ouins.

[El Bbz]

@Violence a dit dans Linus Torvalds réhabilite l'écran bleu de la mort de Windows et explose un mythe : « Une grande partie de ces problèmes ne sont en réalité pas dus à des bugs logiciels... mais à un matériel peu fiable » :

Ils ont d’ailleurs été créés pour des bugs matériels et non logiciels

Absolument, il faut lire les messages du BSOD tout est marqué…
Mais combien peuvent dire qu’ils les ont lus… Et compris ?

[michmich]

@El-Bbz a dit dans Linus Torvalds réhabilite l'écran bleu de la mort de Windows et explose un mythe : « Une grande partie de ces problèmes ne sont en réalité pas dus à des bugs logiciels... mais à un matériel peu fiable » :

combien peuvent dire qu’ils les ont lus

Je peux le dire, et j’ai ensuite réglé le soucis de la limite des 137g avec l’outil nLite comme un grand.