L’argumentaire de John Carmack contre la création d’un OS XR personnalisé chez Meta

• John Carmack a exprimé son opposition au développement par Meta d’un OS XR personnalisé
• Il souligne que le développement d’un système d’exploitation maison entraîne une hausse de la complexité et des risques
• Il affirme que l’utilisation de plateformes existantes est plus efficace pour le développement et l’optimisation des ressources
• Carmack recommande une stratégie fondée sur des OS standards afin de permettre une innovation rapide et une meilleure réactivité sur le marché
• Il insiste sur la nécessité d’éviter une division technique et une fragmentation inutiles

---

Les arguments de John Carmack contre un OS XR personnalisé chez Meta

Contexte

• John Carmack est connu pour avoir une opinion défavorable sur l’idée que Meta développe son propre OS XR (réalité étendue)
• Un OS XR désigne le système d’exploitation qui fonctionne sur des appareils de réalité étendue comme l’AR/VR

Résumé des principaux arguments

• Carmack indique que le développement sur des plateformes déjà présentes sur le marché (Android, Windows, etc.) permet d’accélérer davantage la vitesse de développement et l’innovation
• Le développement d’un OS personnalisé s’accompagne de plusieurs problèmes, comme une complexité accrue, un risque de bugs, et une charge de maintenance à long terme
• Si des ressources sont investies dans la création d’une plateforme propriétaire, l’avantage d’utiliser les outils et technologies standardisés de l’écosystème existant est sacrifié
• Pour réagir plus rapidement aux nouvelles technologies et à l’évolution des besoins des utilisateurs, une stratégie consistant à exploiter activement les OS existants est plus efficace
• Un OS personnalisé peut entraîner des problèmes de compatibilité et un coût d’apprentissage aussi bien pour les développeurs que pour les consommateurs

Conclusion

• Carmack préfère, à long terme, une stratégie fondée sur l’utilisation de plateformes existantes plutôt que sur le développement d’un OS XR personnalisé, afin d’éviter la fragmentation des technologies et des services, et de maximiser la scalabilité et l’utilité

[GN⁺]

Commentaires sur Hacker News

• Le problème quand on travaille chez Meta, c’est que si je réussis, j’aide en fait à rendre le monde pire… J’en viens presque à penser que les vrais héros sont ceux qui gaspillent l’argent et l’efficacité<br>Si vous êtes compétent, je vous recommande plutôt de faire carrière ailleurs
  • L’une des meilleures façons pour un ingénieur logiciel de servir l’humanité, c’est d’entrer dans une boîte comme Meta ou TikTok et de faire semblant d’être incompétent le plus longtemps possible
  • Moi, je bloquerai Facebook et les services associés, mais j’utiliserai zstd<br>Le monde n’est pas binaire
  • C’est une vision trop simpliste<br>Quoi qu’on pense de l’activité principale de Meta, l’entreprise emploie aussi beaucoup d’ingénieurs sur divers projets open source et sur de la R&D qui n’a pas grand-chose à voir avec les réseaux sociaux, comme la VR ou les technologies de datacenter<br>Être payé pour travailler sur des sujets de recherche qui nous intéressent, il y a franchement des voies bien pires
  • C’est un avis un peu pessimiste, mais vu les données jusqu’ici, il n’est pas facile à réfuter
  • Mais au fond, ça ne s’applique pas à toutes les grandes entreprises, et même à toutes les sociétés cotées ?<br>Les fondateurs ont peut-être d’autres objectifs au départ, mais avec le temps, le profit devient la seule finalité, et en général on gagne bien plus en se concentrant sur des choses néfastes<br>C’est un problème systémique
• J’ai développé toutes sortes de logiciels bas niveau, des BSP, pratiquement des OS complets, et la vraie raison pour laquelle on ne construit plus son propre OS aujourd’hui, ce sont les fondeurs de silicium<br>Avant, ils fournissaient des spécifications détaillées permettant d’écrire soi-même les pilotes, alors qu’aujourd’hui ils balancent des descriptions floues accompagnées de pilotes Linux médiocres<br>Il y a un peu de paresse, mais surtout une explosion de la complexité<br>Le matériel moderne est tellement complexe que rien que le documenter prend énormément de temps, et écrire soi-même les pilotes en prend encore plus
  • Intel fournit encore une vraie documentation<br>Il existe des docs extrêmement détaillées pour les NIC haut débit, et pour une carte Ethernet e810 100Gb par exemple, on peut effectivement écrire un pilote from scratch uniquement à partir de la fiche technique officielle de 2750 pages<br>Les autres fournisseurs soit (1) ignorent la demande, soit (2) exigent un NDA, soit (3) ne montrent qu’une pseudo-documentation issue de pilotes Linux/FreeBSD de mauvaise qualité<br>Je ne sais pas trop quelle est la situation pour d’autres matériels comme les SSD NVMe
  • J’ai moi aussi essayé récemment d’ajouter la prise en charge d’un bouton de « redémarrage logiciel » dans un OS hobby, et c’était tellement pénible que j’ai fini par abandonner (pour accélérer les redémarrages sur GCP)<br>J’ai lu les consignes de l’OS Dev Wiki, ainsi que le code source de Linux et de FreeBSD, sans aucun progrès<br>C’est une fonction utilisée quand Windows ou Linux redémarrent<br>J’y ai perdu plusieurs jours avant de laisser tomber<br>Les développeurs d’OS sont vraiment faits d’une autre matière, et semblent souvent ne pas subir de pression économique
  • On entend souvent que « le matériel moderne est trop complexe pour être documenté correctement », mais je pense que c’est une excuse<br>Il faut aussi former les nouveaux employés dans l’équipe et gérer les tests, donc plus quelque chose est complexe, plus il faudrait le documenter en détail au départ<br>Autrement dit, les excuses des fondeurs de silicium ne me convainquent pas
  • Si quelqu’un veut sérieusement construire son propre OS aujourd’hui, j’ai l’impression qu’il faut soit avoir un contrôle extrêmement fort sur le matériel, soit embarquer une instance de servant Linux dans l’OS<br>Windows, ce sont des pilotes qui semblent parfois bogués mais qui existent au moins, et Linux, ce sont des pilotes bogués gratuits<br>Si votre OS peut tourner en continu comme client au-dessus d’un hyperviseur Linux, c’est une voie possible ; sinon il faut rapatrier peu à peu dans son propre OS les fonctionnalités de support matériel. À condition d’aller plus vite que Linux n’ajoute de nouvelles dépendances…
  • Pour certains types d’OS, j’ai l’impression qu’on peut récupérer assez facilement la majeure partie du support matériel Linux en utilisant LKL porté (https://github.com/lkl/linux) et en ajoutant seulement des hooks pour l’accès matériel<br>Bien sûr, il faut écrire séparément le code du cœur de plateforme / chipset, mais pour le reste, la plupart des périphériques I/O sont couverts<br>Ça fonctionnerait probablement mieux avec une architecture de type prise en charge des pilotes en mode utilisateur qu’avec un noyau monolithique classique
• Ce que dit John décrit exactement le type de système que j’aimerais vraiment voir exister<br>« Si vous voulez construire un ordinateur vraiment totalement différent, il faut pratiquement une communauté d’ingénieurs moines retirés du monde pour échapper au puits gravitationnel des solutions déjà existantes »<br>Comme expérience de pensée :<br>- choisir un endroit où le coût de la vie mensuel est de 200 dollars<br>- construire une ville agréable à vivre (air pur, nourriture saine, bonnes écoles, etc.) — à un coût supportable même pour le mécénat d’un riche bienfaiteur<br>- fournir en masse des ordinateurs avec très peu de logiciel et presque pas d’internet<br>- essayer d’inventer un mode de calcul entièrement nouveau à partir de zéro<br>La patience est la clé. Ça prendrait des décennies
  • L’idée est vraiment fascinante Je me demande quels endroits pourraient avoir un coût de vie aussi bas Mais ce que je me demande surtout, c’est pourquoi vouloir résoudre tout de suite des problèmes impossibles à réaliser aujourd’hui ? Faut-il commencer par du matériel comme le CPU ? Je me souviens d’un ingénieur passé par Intel qui disait qu’apprendre les ISA modernes, la micro-architecture CPU, les GPU, etc., puis tout recréer intégralement, ce n’est faisable qu’au moment de la retraite si on veut en plus l’avoir réellement pratiqué et expérimenté soi-même
  • Ça fait plus de 10 ans que je développe mon propre OS, et si vous voulez vraiment faire quelque chose de concret, ce n’est pas la bonne voie<br>Bien sûr, c’est amusant, et parfois j’imagine jusqu’où cela pourrait aller si une immense armée de développeurs s’y mettait. (Même si ça ne rapporterait évidemment pas d’argent)
  • Franchement, c’est un concept de SF incroyablement cool
• Chez Meta, il y a beaucoup de gens venus de Microsoft sur les sujets OS, et ces personnes s’intéressaient déjà à la création d’OS à l’origine<br>Mais chez Meta, elles ont été affectées à l’XR, et ont naturellement voulu faire un OS sur mesure
• Après ce que John Carmack a fait chez Meta, j’ai maintenant du mal à le prendre vraiment au sérieux<br>Rien qu’avec SerenityOS, on a vu qu’il était tout à fait possible de faire un système plus utilisable et plus cohérent que Windows ou Linux<br>Une vision claire, de l’élan et de l’engagement sont plus essentiels que recruter des « top engineers » ou produire du « code de haute qualité » — avec ça, le bon code et les talents finissent de toute façon par suivre<br>C’est pour ça que c’était impossible chez Meta, et c’est aussi pour ça que Linux est dans l’état où il est aujourd’hui<br>Le véritable obstacle, ce sont les pilotes. Référence : le problème des trente millions de lignes — blog de caseymuratori.com
• Après la fusion avec Oculus, en y travaillant, XROS était vraiment une source de nuisance et de distraction pour les équipes techniques de base<br>Il y avait déjà des montagnes de problèmes à résoudre dans plusieurs stacks techniques, et l’idée de XROS n’est apparue qu’après l’intégration complète d’Oculus dans FB<br>De mon point de vue, on avait l’impression que certaines équipes (ou personnes) de FB voulaient simplement monter dans le train de la tendance AR/VR<br>Carmack avait totalement raison, et après la réorganisation, son influence a progressivement diminué, au point qu’on a concrètement ressenti les effets négatifs
  • La plupart des membres de l’équipe XROS n’étaient pas issus du siège de FB, mais recrutés dans l’industrie à mi-carrière (majoritairement niveau E5/E6)<br>Les SWE de FB n’avaient pas le bon niveau technique, et il y avait aussi quelques profils issus du bootcamp, mais ils n’ont pas réussi et sont vite partis ailleurs
  • Je suis furieux qu’ils aient détruit la communauté open source Oculus et transformé un projet financé par la communauté en une chaîne Meta de plus pour aspirer des données personnelles<br>J’espère au moins que les fiches de paie étaient bien remplies
• J’ai lu vers 2002~2004, chez Microsoft, un document interne écrit façon hackathon par quelques développeurs OS pour le Think Week de Bill Gates<br>C’était un OS entièrement nouveau construit sur .NET, avec GC et gestion mémoire intégrées, qui démarrait sur divers matériels et proposait plein de fonctionnalités intéressantes<br>Le design assumait clairement une incompatibilité totale avec Windows, et c’est probablement ce qui l’a condamné<br>C’était le travail d’une poignée de spécialistes OS concentrés dessus pendant environ un mois, et c’était vraiment passionnant
  • C’était Singularity ?<br>Description sur Wikipédia<br>Page officielle de Microsoft Research
  • Je pense que c’était plutôt le projet Midori<br>En réalité, c’était un gros projet Microsoft Research avec plus de 100 personnes pendant plusieurs années<br>Article ZDNet sur le projet Midori
• On a entendu dire que John Carmack avait été signalé aux RH par le manager de l’équipe XROS pour « avoir blessé les sentiments de l’équipe »<br>Personnellement, j’ai toujours trouvé ses communications publiques professionnelles et bienveillantes<br>J’ai moi aussi vécu des expériences similaires où les RH sont instrumentalisées, et ce genre de chose refroidit l’ambiance d’une entreprise — à partir du moment où l’on se dit que quelqu’un peut porter plainte aux RH simplement parce qu’il n’aime pas ce qu’on dit, tout le monde commence ensuite à peser énormément ses paroles
  • J’ai continué à suivre les posts internes de Carmack avant son départ, et il était extrêmement strict sur le gaspillage des ressources, pointant chiffres à l’appui les fonctionnalités comme le hand tracking quand elles tombaient souvent en panne<br>Son message était toujours : « Apple a verrouillé le matériel, donc maintenant le logiciel efficace est la clé de l’avenir », et la désinvolture de Meta venait au final des luttes de pouvoir internes
  • Lucovsky insistait pour construire un OS de zéro, sans voir la réalité terrain selon laquelle les équipes produit devaient livrer quelque chose de concret aux clients, et c’est ce qui l’a fait reculer<br>La toxicité qu’il a laissée derrière lui (sans vraiment en mesurer la gravité) a aussi joué<br>Des comportements similaires se sont répétés chez Google, où il a fini là aussi par être poussé vers la sortie, officiellement présenté comme une démission volontaire<br>Référence Twitter 1 Référence Twitter 2
  • John peut être très direct et tranchant en face à face Il peut se montrer excessivement critique sur des sujets auxquels il ne croit pas, et dans ces moments-là il est difficile de lui répondre à cause du rapport de force
  • Chez Meta, l’ambiance interne était un peu étrange à l’époque<br>Le PSC (évaluation de performance) était important, donc quand une figure légendaire comme Carmack qualifiait mon projet de « gaspillage de ressources », cela avait un impact direct sur l’évaluation<br>L’« impact » est un axe majeur chez Facebook pour mesurer à quel point quelque chose est utile à l’entreprise
  • J’ai vu une scène similaire chez Google<br>Un distinguished engineer a d’abord parlé avec douceur, puis très clairement dit à un ingénieur junior que « c’était une mauvaise idée et qu’il fallait arrêter », et les RH sont intervenues Dans ce genre de contexte, il m’est arrivé ensuite de simplement laisser passer un problème, parce que je n’avais plus envie d’y consacrer du temps et des efforts
• J’étais chez Google quand l’équipe Flutter construisait Fuchsia<br>C’étaient des talents vraiment exceptionnels (parmi les meilleurs ingénieurs que j’aie jamais vus), en plus d’être des centaines avec une énorme ampleur Techniquement, c’était extrêmement impressionnant, mais personne n’a jamais été capable de répondre clairement à la question de qui allait réellement l’utiliser S’il s’était agi seulement d’un nouveau noyau visant à remplacer Linux, cela aurait pu se tenir, mais au contraire ils voulaient reconstruire tout l’OS depuis zéro, du kernel jusqu’à l’UI et au window manager Au final, ils n’ont ciblé que des appareils spécialisés avec simple UI comme Home Hub, sans réussir à expliquer pourquoi il fallait à ce point compliquer l’OS par rapport aux produits existants<br>J’ai encore du mal à comprendre comment Fuchsia continue d’exister Et voir Google réduire les ressources des équipes essentielles pendant les restructurations tout en maintenant du monde sur ce genre de projet, c’est encore plus déprimant<br>Je ne comprends vraiment pas pourquoi ils continuent de le garder en vie
  • Si on ne regarde que les résultats à court terme, il est difficile de trouver une justification, mais sur le long terme, développer un nouvel OS reste défendable<br>Google s’intéresse réellement aux investissements de long terme, et un projet n’a pas besoin d’être justifié publiquement à l’extérieur<br>C’est presque la critique elle-même qui paraît étrange. Si ça vous intéresse, participez ; sinon, ignorez-le simplement<br>Créer un nouvel écosystème applicatif n’a jamais été l’objectif principal, et la partie la plus difficile est de devoir réimplémenter tout un ensemble de technologies qu’on considère d’ordinaire comme acquises. C’est dur, mais pas impossible Avoir plus de choix ne peut pas faire de mal — au lieu de tenir un discours contradictoire qui célèbre la diversité sur le marché des navigateurs tout en acceptant un quasi-monopole sur celui des OS, on peut aussi considérer qu’avoir plus d’OS est une bonne chose
  • Je pense que l’idée était de commencer avec certains appareils (Home Hub), d’y accumuler expérience et revenus, puis d’élargir progressivement à partir de là Je doute qu’ils aient commencé en voulant tout remplacer d’un coup
  • J’avais compris Fuchsia comme un nouveau paradigme où plusieurs OS et paquets d’applications tournent entièrement en conteneurs<br>Dans mon imagination, cela dessinait un OS du futur capable aussi de fonctionner sur le web et de tourner sur plusieurs machines à la fois<br>J’espérais aussi la possibilité d’exécuter plusieurs instances sur une même machine, chacune adaptée à un utilisateur différent
  • J’avais l’impression que Fuchsia était en fait pour Google une sorte de projet d’attrition visant à retenir d’excellents ingénieurs kernel pour éviter qu’ils ne partent chez la concurrence
  • Ils ont forcé l’intégration de Fuchsia dans Home Hub, rendant immédiatement la stack existante legacy, puis les délais ont continué à glisser sans aucune conséquence Construire son propre OS avait l’air prestigieux, mais j’ai surtout eu l’impression que tout le projet nuisait au travail des autres équipes
• Aujourd’hui, il est devenu plus simple de contourner le noyau Linux pour accéder directement au matériel, et les CPU avec beaucoup de cœurs sont courants<br>L’idée clé est d’isoler des cœurs pour y affecter des threads, puis de contrôler directement le matériel via des techniques de kernel bypass. Pour la communication entre cœurs, un ring buffer suffit, ce qui permet d’obtenir des performances presque optimales vis-à-vis du matériel tout en conservant les avantages du noyau Linux pour l’administration, la supervision et le débogage
  • Comme lorsqu’on fait un mmap de /dev/mem pour accéder directement à la mémoire physique, le kernel bypass est toujours possible