Dave Cutler explique Windows [vidéo]
(youtube.com)- Fort de son parcours allant de RSX-11, VMS et Windows NT jusqu’à Azure et Xbox, Dave Cutler revient sur le contexte de conception de Windows NT et sur la culture de développement chez Microsoft
- Dès le départ, Windows NT visait à être un système d’exploitation portable prenant en charge plusieurs environnements d’exécution, puis le succès de Windows 3.1, vendu à 16 millions d’exemplaires en six mois, a fait de Windows l’environnement central à la place d’OS/2
- Les premières versions de NT géraient plusieurs architectures comme i860, MIPS, x86, Alpha et PowerPC, ainsi que la HAL, le gestionnaire d’objets et la structure noyau/pilotes ; une grande partie de cette architecture centrale subsiste encore dans Windows 11
- VMS visait zéro bug connu au moment de sa sortie, et l’équipe NT entretenait sa cohésion avec le Friday WHIM ; mais NT, Cairo, Longhorn et la réponse de sécurité autour de XP ont été fortement alourdis par les délais, la qualité et la fragmentation de la base de code
- Pour Cutler, corriger les bugs, tester, garantir la qualité et garder la discipline de ne pas ajouter de fonctions inutiles sont les attitudes clés d’une bonne équipe logicielle
Parcours dans les systèmes d’exploitation avant Windows NT
- Après avoir découvert les systèmes temps réel et la simulation informatique chez DuPont, Dave Cutler s’est davantage intéressé à l’ordinateur lui-même qu’aux simples outils de résolution de problèmes
- Sur un projet simulant avec GPSS 3 le procédé de fabrication de formulaires chez Scott Paper, il a été confronté à des erreurs de cartes perforées et à du débogage
- Pour réduire les erreurs, il a écrit un programme Fortran, puis a appris l’assembleur IBM 7044, élargissant ainsi son intérêt pour le fonctionnement interne des machines
- Dans le groupe des systèmes temps réel de DuPont, il a écrit un programme d’analyse automatique des données d’essais de traction Instron
- Le programme d’acquisition fonctionnait en temps réel et lisait les données toutes les 1 milliseconde ou 100 millisecondes
- Il est ensuite réellement entré dans le développement de systèmes d’exploitation en travaillant sur Exec II pour l’Univac 1107
- Chaque jour, il faisait sortir l’opérateur à 17 h puis passait deux heures à exécuter du code expérimental et des tests
- Dans un environnement presque dépourvu de débogueur, il déboguait avec des interrupteurs et l’instruction
halt
L’époque DEC : RSX, VMS, compilateurs, PRISM
- Chez Digital Equipment Corporation, il avait d’abord été embauché pour OS/45, mais a rapidement été affecté à RSX-11C
- Pour Cutler, l’espace d’adressage 16 bits du PDP-11 constituait une contrainte majeure
- RSX-11C était un petit système, qu’il jugeait limité même selon les standards de l’époque
- Le développement de VMS a démarré en s’appuyant sur le matériel VAX et sur une couche d’exécution compatible PDP-11
- Le VAX disposait d’un mode PDP-11, et une couche appelée Application Migration Executive permettait d’exécuter les utilitaires RSX-11M
- Le système de fichiers Files-11 a lui aussi été réimplémenté dans VMS pour préserver la compatibilité
- Au début du développement, les travaux clés comme l’ordonnancement et la gestion mémoire étaient menés sur un émulateur matériel
- VMS utilisait l’auto-hébergement comme moyen d’assurer la qualité
- Une fois Proto 3 suffisamment stable, l’équipe de développement a travaillé directement sur ce système
- Lorsqu’un
bug checksurvenait, plusieurs personnes se rendaient devant la machine, trouvaient la cause avec le débogueur, appliquaient un correctif puis redémarraient
- Il se souvient que VMS est sorti avec « zéro bug connu »
- Cela ne signifiait pas l’absence totale de bugs, mais la volonté de corriger tous ceux qui étaient connus avant la sortie
- Jusqu’au dernier moment, l’équipe a encore corrigé une race condition dans le pilote de disque
- Après VMS, il a aussi travaillé sur le compilateur PL/I, le back-end du compilateur C, la génération de code, l’optimisation et l’allocation de registres
- Le front-end PL/I avait été acheté à une société de Boston, tandis que le back-end a été développé sur VAX
- Une partie du travail de front-end a été réalisée sur Multics au MIT, puis transférée sur bande
- Chez DEC West, il a participé à Velon, un système temps réel, ainsi qu’au projet MicroVAX
- Velon expérimentait des idées comme les pilotes en mode utilisateur, une architecture orientée messages, le multithreading et le multiprocesseur
- Sur MicroVAX 1, Cutler a écrit l’intégralité du microcode
- Le projet PRISM représentait la tentative RISC de DEC, et Cutler a décidé de quitter l’entreprise le lendemain de son annulation
- PRISM comportait des versions 32 bits et 64 bits, et un système logiciel ambitieux nommé Micah était également en cours
- Après l’annulation de PRISM, il a tenté de créer une entreprise de serveurs, avant qu’un contact avec Microsoft ne change la donne
Arrivée chez Microsoft et conception de Windows NT
- Son arrivée chez Microsoft n’était pas acquise même après un échange avec Bill Gates, mais la décision s’est prise rapidement après un petit-déjeuner au Denny’s avec Steve Ballmer
- Cutler considère Ballmer comme la personne clé qui l’a convaincu de rejoindre Microsoft
- Les objectifs initiaux de NT étaient un système d’exploitation portable et la prise en charge de plusieurs environnements d’exécution
- L’environnement cible de l’époque était OS/2, et POSIX figurait aussi parmi les candidats importants
- L’idée de départ consistait à fournir des services de base au cœur du système, puis à faire tourner plusieurs environnements par-dessus
- Si Windows est devenu l’environnement central de NT, c’est grâce au succès de Windows 3.1
- Windows 3.1 s’est vendu à 16 millions d’exemplaires en six mois, et Bill Gates a jugé que l’environnement principal du nouveau système devait être Windows
- Le développement de NT s’est aussi fait sur OS/2, mais l’équipe voulait rapidement s’auto-héberger sur NT lui-même
- Le nom NT signifie « New Technology »
- Il a peut-être existé un lien flou entre le nom de code N10 du i860 et NT, mais pour Cutler, NT signifiait bien New Technology
- Le marketing s’y opposait en estimant qu’un nom comme « nouvelle technologie » pouvait freiner les acheteurs, mais Cutler a imposé NT
- La première version de NT prenait en charge plusieurs architectures CPU
- x86, MIPS R3000/R4000 et Alpha sont cités
- PowerPC est arrivé à l’époque de NT 3.5 ou Daytona, et Cutler jugeait peu convaincants à la fois les builds PowerPC et la compétitivité du matériel
- La HAL de NT dépassait à l’origine le simple rôle de couche d’abstraction matérielle pour se rapprocher d’une couche d’abstraction des fournisseurs
- Elle était au départ séparée dans une DLL afin que les fournisseurs puissent fournir leur propre HAL
- Cutler estime rétrospectivement qu’il aurait mieux valu construire la HAL comme une partie intégrée du système d’exploitation
- Le noyau NT et la HAL contenaient relativement peu d’assembleur
- Certaines opérations très fréquentes nécessitaient de l’assembleur ou des intrinsics pour des raisons de performances
- En x64, le choix a été fait d’utiliser des intrinsics plutôt que de l’assembleur inline
Culture de développement de NT, Cairo, Longhorn, sécurité de XP
- Pour garder une organisation en pleine croissance soudée, l’équipe NT organisait chaque vendredi le WHIM
- WHIM signifiait Weekly Integration Meeting
- Au départ, des managers achetaient bière et chips chez Safeway et organisaient cela dans le laboratoire matériel, puis l’événement a grandi avec un espace plus grand et du catering
- Cutler estime que la description d’un développement NT fondé uniquement sur l’épuisement permanent des équipes ne correspond pas à la réalité, l’objectif étant aussi de créer un moment de détente chaque semaine
- Après NT 3.5, le portage de l’interface de Windows 95 vers NT s’est déroulé en parallèle du projet Cairo
- Tuckwila était maintenu comme une sorte de solution de repli vers NT 4.0 ; dans les builds quotidiens, Tuckwila sortait de façon stable alors que Cairo cassait souvent
- Les fonctions de Cairo ont été progressivement retirées, et Cutler se souvient surtout du logiciel de serveur de fichiers et de Kerberos parmi les éléments finalement portés
- NT 4.0 est resté une version très populaire, et Cutler dit avoir encore rencontré des gens qui l’utilisaient
- Le calendrier de NT 3.1 a pris plus de temps que celui de VMS
- VMS aurait été construit en deux ans par une équipe d’environ 20 personnes particulièrement brillantes
- NT avait davantage à accomplir, et son périmètre s’est élargi avec l’abandon du i860 puis l’ajout de MIPS, x86, Alpha et d’autres architectures
- Dans la séquence Longhorn puis Vista, la séparation de la base de code est devenue un problème majeur
- Après Windows 2000, les bases de code serveur et poste de travail ont divergé ; tandis que l’équipe serveur corrigeait de nombreux problèmes de sécurité, la branche grand public souffrait d’instabilité au build et à l’exécution
- XP a connu un immense succès, mais aussi beaucoup de bugs, et l’explosion des problèmes de sécurité a ensuite mobilisé énormément d’efforts sur leurs corrections
- Le groupe de Cutler a corrigé environ 5 000 bugs de sécurité liés à XP
- L’extension x64 d’AMD a marqué un tournant important chez Microsoft
- AMD proposait une extension 64 bits moins intrusive, capable d’exécuter rapidement les applications 32 bits
- Cutler a décidé de construire un poste de travail 64 bits et un serveur 64 bits à partir de la base de code serveur, sans que ce soit au départ un projet officiellement approuvé par l’entreprise
- À l’arrivée des systèmes AMD, le premier démarrage s’est fait depuis un CD, et le système 64 bits a démarré et fonctionné immédiatement
microsoft.comest passé à des serveurs 64 bits après environ une semaine d’essai, avec une stabilité jugée bien supérieure à celle des systèmes 32 bits
- Longhorn a finalement basculé sur la base de code x64, qui perdure jusqu’à aujourd’hui
Structure interne de Windows et code encore présent aujourd’hui
- Une grande partie des fonctions et structures fondamentales de l’époque NT 3.5 existe encore dans Windows 11
- Le code du noyau, les structures de gestion mémoire, les structures de processus et le gestionnaire d’objets se prolongent encore aujourd’hui
- La part du code d’origine dans l’ensemble diminue avec le temps, mais les structures centrales assurant les mêmes fonctions restent largement présentes
- Cutler cite le gestionnaire d’objets de NT comme l’une des raisons importantes de la qualité de la base de code
- Contrairement à l’approche Unix où « tout est fichier », NT permet d’ajouter de nouveaux objets du système d’exploitation en créant un nouveau descripteur de type d’objet puis en l’intégrant au gestionnaire d’objets
- Les objets peuvent fournir des fonctions comme la synchronisation et le contrôle d’accès
- La table des handles a été réécrite plusieurs fois pour des raisons de performance
- La traduction des handles constituait un vrai problème de performances
- Cutler donne comme exemple son système de travail, où environ 60 processus, plusieurs centaines de threads et 150 000 handles sont ouverts
- L’augmentation de la taille du Gestionnaire des tâches est évoquée comme exemple de gonflement du code
- À l’origine, le Gestionnaire des tâches compilait à 85 KB, contre 4 MB aujourd’hui
- Il affiche désormais bien plus d’informations, comme le CPU, le réseau et le disque, mais Cutler ne considère pas que les fonctionnalités aient augmenté dans les mêmes proportions
- La décision de déplacer les pilotes graphiques du mode utilisateur vers le mode noyau était nécessaire pour les performances, mais s’est accompagnée de fortes douleurs de croissance
- Cutler s’y opposait au départ
- Les modèles de synchronisation diffèrent entre mode utilisateur et mode noyau, ce qui empêchait un simple déplacement de code ; les structures de données 16 bits et certains primitives constituaient aussi un fardeau
- La fiabilité s’est ensuite nettement améliorée, même si les pilotes graphiques des fournisseurs ont longtemps posé de nombreux problèmes
Azure, Xbox, xCloud
- Après l’expédition des systèmes x64, Cutler a été tellement frustré par le problème
fcibqu’il a dit vouloir quitter Microsoft, avant de revenir en novembre 2005 après des congés à la demande de Steve Ballmerfcibsignifie checked-in binary ; les groupes qui validaient des binaires plutôt que le code source rendaient les portages difficiles
- Il a ensuite participé aux débuts du projet Azure
- Ray Ozzie a lancé le projet en constatant l’absence d’infrastructure commune entre plusieurs services cloud
- Azure visait au départ une infrastructure de plateforme pour le déploiement d’applications, le contrôle de configuration, la gestion de versions, le redémarrage, la facturation et un système de fichiers cloud
- Il explique qu’AWS proposait surtout de l’infrastructure, tandis que Microsoft voulait initialement vendre des services de plateforme
- L’hyperviseur initial d’Azure a été construit à partir de la technologie récupérée avec l’acquisition de Connectix
- Connectix disposait des produits Virtual PC et Virtual Server, et le développement de l’hyperviseur n’en était encore qu’à ses débuts
- L’hyperviseur Xbox provient ensuite de l’hyperviseur Red Dog d’Azure
- Xbox fonctionne avec une architecture à trois VM
- Le
host systempossède tous les périphériques et joue le rôle detraffic coppour les communications entre VM - La
presentation VMgère le gestionnaire de fenêtres et le système d’affichage, et reste active en permanence - La
game VMdémarre et s’arrête pour chaque jeu, et le jeu est empaqueté avec l’OS
- Le
- Le fait que le jeu soit empaqueté avec l’OS favorise la rétrocompatibilité
- Les développeurs de jeux empaquettent leur jeu avec l’OS du GDK, et la VM correspondante est lancée à l’exécution
- Cela évite qu’une évolution du système d’exploitation ne casse les anciens jeux
- En revanche, quand il faut introduire une fonctionnalité dans des jeux existants, il faut passer par des contournements comme un universal game OS
- Le pause/resume de Xbox fonctionne via la sauvegarde et la restauration de VM
- Le chargement d’un jeu implique des volumes de données de l’ordre du gigaoctet, ce qui prend du temps
- Le pause/resume consiste à enregistrer l’état de la VM puis à le restaurer plus tard
- Parmi les travaux actuels sont mentionnés une VM Linux et une pile graphique tirant parti du temps d’inactivité des consoles xCloud
- xCloud repose sur des consoles Xbox reconditionnées en racks dans des datacenters et accessibles à distance
- La console étant en single tenant, une seule personne l’utilise à la fois, ce qui crée des périodes d’inactivité
- Dans l’objectif d’exécuter des workloads de machine learning internes à Microsoft durant ces périodes inutilisées, il travaille sur une VM Linux, l’hyperviseur Xbox et la pile graphique
Qualité, organisation des équipes, philosophie de développement
- Cutler applique aussi aux équipes logicielles l’idée selon laquelle « les gens qui réussissent font ce que ceux qui échouent refusent de faire »
- Il critique l’attitude consistant à ne pas tester son code parce qu’on l’a déjà écrit, à partir à 17 h alors que le planning impose encore du travail, ou à ne pas vouloir corriger ses propres bugs
- Il juge essentielle l’attitude consistant à faire soi-même ce qui est nécessaire pour mener un projet au succès
- Il accorde une grande valeur au profil de thinker-doer
- En citant Brooks, il dit que les gens qui réfléchissent sont nombreux, que ceux qui exécutent sont plus rares, et que ceux qui savent faire les deux sont plus rares encore
- Même un architecte doit produire des résultats concrets répondant aux objectifs et aux contraintes
- Il voulait afficher dans un laboratoire de l’University of Washington la phrase : « si on ne l’ajoute pas, il n’y a pas besoin de l’enlever »
- Il s’en sert pour insister sur la discipline consistant à ne pas ajouter de fonctions inutiles
- Dans les premiers environnements de développement, les outils de débogage étaient rudimentaires, ce qui rendait essentielle une démarche visant à réduire les erreurs dès le départ
- Autrefois, il fallait parfois mobiliser jusqu’à des logic analyzers ou des oscilloscopes
- Selon lui, les outils actuels réduisent davantage les petites erreurs, mais la pression sur la qualité n’est plus la même qu’avant
- Il considère que le multitâche est possible, mais que la meilleure productivité vient d’un travail concentré sur une seule tâche
- Les changements de contexte ont un coût en temps
- Il explique toutefois qu’il change de tâche pour aider quelqu’un bloqué sur un problème ou pour corriger un bug
1 commentaires
Avis sur Hacker News
L’intervieweur, Dave Plummer, est lui aussi quelqu’un de vraiment fascinant. J’ai particulièrement aimé ses vidéos de codage rétro, comme https://www.youtube.com/watch?v=JlZe2JwrJqM et https://www.youtube.com/watch?v=b0zxIfJJLAY
Les vidéos sont amusantes, et la musique de fond avec l’éclairage RGB leur donne une ambiance de Noël. Cela m’a aussi montré Microsoft sous un jour complètement différent de l’image à laquelle j’étais habitué : il parle avec chaleur de son travail, de ses collègues et de Microsoft, tout en reconnaissant les bizarreries de Redmond
En revanche, quand on regarde cette chaîne, l’algorithme de YouTube se déclenche d’une manière ou d’une autre et le fil de recommandations se retrouve envahi de vidéos sur le TDAH. C’est sans doute à cause de vidéos liées à l’autisme et au TDAH, mais on pourrait penser que YouTube est assez intelligent pour comprendre que je n’ai regardé que des vidéos de codage et d’histoire de Microsoft
Cela dit, même si je n’aime pas le formuler ainsi, il faut prendre avec de grosses pincettes ce qu’il dit sur les sujets en dehors de Microsoft/Windows. C’est encore plus vrai depuis le commentaire ci-dessous [1]
Le récent forcing pour désactiver les bloqueurs de publicité a aussi été révélateur. Les pubs YouTube sont vraiment ce qu’il y a de pire, au point qu’il est embarrassant d’imaginer que de vraies personnes y réagissent. YouTube semble avoir renoncé même à faire semblant de vouloir offrir une bonne expérience utilisateur
Cela dit, pour voir quelque chose d’aussi excellent que cette interview de Dave Cutler, cela vaut quand même la peine de fouiller un peu dans la boue
Ce n’est pas une blague, et le mot « moitié » est assez exact. Soit quelque chose est cassé, soit YouTube a branché un grand modèle de langage sur son moteur de recommandation
J’ai préféré le voir parler de manière improvisée plutôt que dans une vidéo bien montée
Après cette seule vidéo, mes recommandations se sont remplies d’histoires de cancer, de personnes en fin de vie et de toutes sortes de maladies. Cette vidéo n’avait absolument rien à voir avec le contenu habituel de cette personne, et je n’ai regardé aucune de ces recommandations, mais elles ont continué à affluer
Je n’ai pas encore vu cette vidéo, mais j’ai lu Showstopper[1] il y a quelques années, donc je suis impatient
Ce qui m’a particulièrement marqué, à l’époque où, au début de la vingtaine, je pensais qu’il fallait toujours travailler, c’est le passage disant que Dave prenait systématiquement ses vacances à temps, sans débat
On peut ne pas aimer Microsoft, mais c’était probablement la première fois que je voyais vraiment l’exemple d’une personne extrêmement compétente et qualifiée qui ne se faisait pas broyer 24 heures sur 24
Même l’écrire comme ça me paraît encore étrange, mais c’était une façon de penser héritée d’une culture rurale et du commerce de détail, du genre « plus on souffre, plus on est vertueux »
Aujourd’hui encore, bien se reposer est difficile, et il est facile de remettre ça à plus tard sous prétexte que X ou Y est plus important. Malgré tout, repenser au point de vue de Dave est un bon rappel que se reposer et bien faire X ne sont pas deux options mutuellement exclusives
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
« Souviens-toi du jour du sabbat, pour le sanctifier… Tu travailleras six jours, et tu feras tout ton ouvrage. Mais le septième jour est le sabbat de l’Éternel, ton Dieu… »
https://en.wikipedia.org/wiki/Protestant_work_ethic
https://www.biblegateway.com/passage/?search=Exodus%2020&ver...
Plus les employés « gardent le nez sur la meule » et « se cassent le dos » au travail, plus les profits de l’entreprise augmentent, sans qu’il soit nécessaire de les payer davantage. Quand leur santé est assez détruite pour qu’ils ne puissent plus travailler, il suffit de les remplacer
Désolé si ma réponse écrite tard dans la nuit est abrupte, mais j’imagine que les gens ici le savent déjà intuitivement
Puis j’ai fait un burn-out, et maintenant je considère que se reposer et respecter des journées de 8 heures, sauf véritable urgence, relève non seulement de la responsabilité personnelle, mais aussi de la responsabilité professionnelle. Cela réduit le risque de burn-out, et le burn-out est littéralement mauvais pour tout le monde
J’ai lu qu’à la toute fin du développement de WinNT 3.1, quelqu’un avait créé un économiseur d’écran affichant un écran bleu. C’était peut-être sur Usenet
Je n’avais encore jamais créé d’économiseur d’écran, mais à cause d’un bug dans un driver réseau interne de Microsoft, je pouvais faire planter de manière fiable ma machine de développement WinNT en écran bleu
J’ai donc lu la documentation pour écrire des économiseurs d’écran Windows, noté les valeurs affichées sur mon écran bleu, puis bricolé mon premier et dernier économiseur d’écran Windows
Pour m’amuser, j’ai envoyé un mail au groupe Windows NT pour leur signaler ce que j’avais fait, et quelques semaines plus tard, le groupe de build NT a décidé de faire une blague à Dave Cutler
Ils ont installé mon économiseur d’écran bleu sur un des serveurs de build, ont aussi débranché la souris et le clavier, puis ont attendu
Dave Cutler est venu voir l’état du dernier build NT, a allumé le moniteur et a vu l’écran bleu. Il a bougé la souris, aucune réaction ; il a tapé au clavier, aucune réaction
Et là, l’inattendu s’est produit. Il a tendu la main vers le bouton d’alimentation du serveur de build et l’a redémarré. NOOOOOOOOOOOOOOOOOOOOO
Je n’ai jamais entendu parler des retombées ou des conséquences de cette blague. De grands pouvoirs impliquent de grandes responsabilités
Je l’avais installé moi aussi, et quelques collègues assis autour de moi l’avaient aussi installé
Le CTO était passé tôt le matin pour une réunion et, en voyant ça sur tous les écrans, il a eu un petit moment de panique en pensant à une propagation de virus ou à un bug logiciel
Je recommande aussi ici le livre que quelqu’un avait conseillé il y a quelques semaines, « Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft »
Je suis encore en train de le lire, mais il est vraiment passionnant, et ça me donne envie d’avoir participé à cette histoire. Surtout la partie où ils ont dogfoodé un système d’exploitation entièrement nouveau. C’était juste quelques années avant mon époque
Grâce à ce livre, j’avais l’air de m’y connaître bien plus que ce n’était vraiment le cas, et j’étais beaucoup plus enthousiaste à propos de tout ce domaine que quelques jours auparavant
J’ai reçu une offre, mais finalement je n’ai pas pris le poste
En lien avec ça, il y a aussi ceci : https://blog.codinghorror.com/showstopper/
Ce qui m’a semblé intéressant, c’est que l’hyperviseur Xbox ne vient pas du monde desktop, mais est basé sur Azure, et que les jeux Xbox ne dépendent pas d’un unique système d’exploitation sur la machine : ils sont plutôt packagés avec l’OS, ce qui les rapproche un peu plus de conteneurs.
Dave a aussi dit qu’il travaillait à faire tourner des tâches de machine learning sur des appareils Xbox Cloud Gaming inactifs. Je n’avais jamais pensé qu’il pouvait exister un tel lien architectural entre Azure et Xbox.
Par exemple, l’exécutable d’un jeu est en fait chiffré sur le disque du jeu, et même dumper le véritable binaire en cours d’exécution est presque impossible. La RAM est également chiffrée.
Par ailleurs, l’une des raisons pour lesquelles les TPM modernes ont fini par être intégrés au CPU était d’empêcher les gens de sniffer le bus TPM, comme ils l’avaient fait sur Xbox.
J’ai travaillé dans l’équipe du noyau Windows, et mon anecdote préférée à propos de DC est qu’il détestait tellement l’architecture Itanium qu’il a, de fait, rendu x64 possible.
En travaillant avec AMD, il a pratiquement poussé le projet à lui seul, en continuant à coder depuis son bureau d’angle.
L’idée était que “si l’on regroupe plusieurs instructions, parfois de longueur variable en bits, dans un même mot, et qu’on laisse les auteurs de compilateurs trouver le paquet d’instructions optimal, l’implémentation devient plus simple et peut donc être plus rapide”. Mais si le compilateur ne trouve pas ce paquet optimal, c’est en fait plus lent qu’une conception traditionnelle comme x86.
Quelqu’un de très haut placé chez Intel devait vraiment adorer cette idée. Sur toute l’histoire d’Intel comme grand fabricant de microprocesseurs, ils ont essayé trois fois et échoué trois fois.
À l’époque, AMD64 n’était pas vu comme une bonne idée, car c’était “encore plus de la même chose”. Malgré tout, Dave a bien fait de contribuer à écarter ce fatras qui avait pratiquement tué la révolution RISC.
J’espère qu’un jour, moi aussi, je pourrai produire quelque chose d’aussi impressionnant pendant mon temps libre.
Malheureusement pour Microsoft, ce trophée a été remporté par Linux sur x86-64.
L’un des moments les plus déterminants de ma carrière d’ingénieur logiciel a été, il y a 6 ou 7 ans, de lire le code source NT qui avait fuité en parallèle de Showstopper[1].
Ce qui rendait la fuite de NT particulièrement fascinante, c’est qu’elle incluait tout l’historique des auteurs, ce qui permettait de voir exactement sur quels fichiers Dave Cutler avait travaillé. Le livre détaille aussi des choses comme la manière dont les modules du noyau ont acquis des sections paginables, ce qui est passionnant en soi.
Le livre contient une scène où Cutler arrive et réécrit une certaine routine en assembleur, et dans le code source réel on peut voir exactement de quelle routine il s’agit.
Le code de Cutler était du C vraiment magnifique, et il l’est sûrement encore aujourd’hui. Il a beaucoup influencé ma manière d’écrire du C dans le style NT.
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
Les entretiens d’histoire orale avec David Cutler du Computer History Museum sont également excellents.
Partie 1 : https://youtu.be/29RkHH-psrY
Partie 2 : https://youtu.be/SVgSLud50ss
J’ai vu quelques extraits du nouvel entretien, mais pour l’instant je ne suis pas certain d’y avoir entendu quelque chose de nouveau.
En repensant à ce qu’ont dit les deux Dave, il y a une attention énorme portée au fait de terminer et sortir le produit, mais presque aucune discussion sur la planification à long terme ni sur une véritable stratégie de sécurité
Tout tourne autour de sortir des saucisses du hachoir sous pression commerciale, et de ramener les échecs à un niveau acceptable
Il n’est donc pas surprenant que, dans l’ensemble du secteur, la situation ne s’améliore pas et ne prenne pas la bonne direction. Je pensais qu’on finirait un jour par arriver à une sécurité fondée sur les capabilities, mais j’ai maintenant l’impression que nous resterons à jamais coincés avec son cousin presque sans valeur : les indicateurs d’autorisations d’applications
L’avenir m’inquiète
Il leur suffit d’un bon trimestre, ou de quelques bonnes années, pour justifier une promotion de VP à SVP, puis de SVP à CEO. On ne reproche pas à quelqu’un, et on ne le sanctionne pas, trois ans plus tard, dans son nouveau rôle, pour les choix court-termistes qu’il a faits dans son poste précédent
Cela ne veut pas dire que Cutler est ce genre de dirigeant. Mais il a clairement subi la pression venue d’en haut pour sortir les produits et maintenir le flux de revenus. Comme il le dit au début de l’interview, il déteste vraiment livrer avec des bugs, il est très déçu par la qualité des ingénieurs logiciel du secteur, et il déteste aussi profondément que les responsables de programme/projet traitent tous les bugs comme de rares cas limites. Je suis d’accord sur les trois points
La plupart des bugs que je remonte sont eux aussi traités comme des « cas limites », alors que je tombe dessus tous les jours, et que la base de données contient plusieurs tickets en doublon, ou que mon bug est à nouveau marqué comme doublon d’un signalement antérieur
Après des décennies dans ce secteur, toutes passées dans la Big Tech, je n’ai encore jamais vu une entreprise où, malgré la pression des ingénieurs et des managers de premier niveau pour corriger les bugs avant la sortie et publier plus souvent des mises à jour correctives, on ne finisse pas par céder à ce même type de pression
C’était un argument de vente important, mais il ne parlait pas vraiment à la plupart des utilisateurs. En pratique, beaucoup se demandaient : « pourquoi ai-je besoin de ça ? », et cela donnait l’impression que ce n’était pas un système d’exploitation pour les « utilisateurs ordinaires »
Les notions de sécurité du début des années 1990 — ce qui fait la sécurité, pour qui et à quel point c’est pertinent — ne correspondent pas aux attentes d’aujourd’hui ni à l’état de l’art actuel
Cela peut prendre un certain temps pour bien faire les choses. En attendant, j’espère qu’une alternative régressive, à moitié cuite, fondée sur un runtime unique et renforçant le statu quo, ne l’emportera pas
[0] : https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
C’est peut-être le plus grand produit économique auquel le logiciel a « contribué » : un contrat contraignant du genre « nous prenons votre argent, mais nous ne promettons rien, pigeon ! »
À l’inverse, arriver deuxième sur le marché est sanctionné
J’ai hâte d’écouter tout cela
Quels que soient les sentiments qu’on puisse avoir envers lui ou l’entreprise pour laquelle il travaille, Cutler a été un ingénieur logiciel très influent grâce à son travail sur OpenVMS et Windows NT. Je trouve qu’on parle moins souvent de lui que des gens de Bell Labs, de Stallman, de Linus ou de Stroustrup