Linus Torvalds réhabilite l'écran bleu de la mort de Windows et explose un mythe
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 »
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.
Rendez-vous à 9:37
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 pure.
Sur le refroidissement, par exemple, il refuse catégoriquement le watercooling, non par dogmatisme esthétique, mais par souci de fiabilité. L’eau qui fuit dans un rack, les pompes qui gorgent ou vieillissent mal, les fluides qui « verdissent » dans les tuyaux : pour lui, ce sont autant de sources de panne supplémentaires. Il préfère un gros radiateur à air, des ventilateurs lents, un souffle constant qu’il décrit presque comme un ronronnement de chat.
Sur l’alimentation, même logique. Une PSU largement dimensionnée, très efficace, dont le ventilateur ne tourne presque jamais, compte davantage à ses yeux que n’importe quelle barre RGB. Elle réduit le bruit, améliore la stabilité électrique et diminue le risque d’erreurs transitoires qui peuvent, là encore, se traduire par des comportements étranges.
Et sur l’overclocking, la critique est implicite. Du point de vue de quelqu’un qui compile le kernel en boucle et valide des patches dont dépend l’industrie entière, chercher la limite absolue de la fréquence CPU au détriment de la stabilité relève de l’hérésie.
Ce que cela implique pour les professionnels IT
Pour un public de professionnels, le message est presque brutal, mais salutaire. Quand une flotte de machines Windows est perçue comme « instable », la première question ne devrait pas être « que fait Microsoft ? », mais « sur quoi tourne réellement notre parc ? ».
Utilise-t-on de la RAM grand public sans ECC pour des workloads critiques ? Les alimentations sont-elles dimensionnées correctement ou tirent-elles en permanence à 80–90 % de leur capacité nominale ? L’overclocking est-il toléré, voire encouragé, sur des postes qui exécutent des outils de production, de build, de test ?
La remarque de Torvalds agit comme un rappel à l’ordre architectural. Si l’on veut évaluer honnêtement la qualité d’un OS, il faut le faire sur une base matérielle qui n’est pas déjà en train de trahir l’ensemble de la pile logicielle.
Et, accessoirement, cela invite aussi à repositionner le BSOD dans le discours interne IT. Dans bien des cas, il ne signale pas « Windows nous a lâchés », mais « cette machine ne respecte plus les conditions minimales pour exécuter quoi que ce soit de fiable ».
Le regard d’un homme qui vit à l’interface hardware / software
Ce qui rend ce passage particulièrement intéressant, c’est qu’il est cohérent avec toute la trajectoire de Torvalds telle qu’il la rappelle dans la vidéo. Il explique qu’il a toujours travaillé « près du matériel », sans être un concepteur de circuits au sens strict, mais en trouvant son terrain de jeu à l’interface entre le hardware et le logiciel.
Linux lui-même est né de ce besoin : il lui fallait un système pour parler proprement au matériel qu’il avait sous la main. Si un autre OS avait fait le job, il n’aurait pas réinventé la roue. De la même manière, dans son quotidien, il n’a pas besoin d’une machine “de démonstration”, mais d’un outil dont il peut garantir que les comportements qu’il observe reflètent le code, pas les caprices du silicium.
Son plaidoyer pour l’ECC, ses réserves sur le watercooling, son respect implicite pour le BSOD comme mécanisme de protection plutôt que comme icône de honte, viennent tous de cette culture-là. C’est la vision d’un développeur système qui sait que la frontière entre « bug logiciel » et « hardware pourri » est beaucoup plus poreuse que ce que l’on veut bien admettre au niveau marketing.
Sources : vidéo dans le texte, Dell Technologies
Et vous ?
Quelle lecture faites-vous des propos de Torvalds ? Partagez-vous son point de vue ? Dans quelle mesure ?
Répondre avec citation
Partager