John Carmacks Einwände gegen den Aufbau eines eigenen XR-OS bei Meta

 (twitter.com/ID_AA_Carmack)
1 Punkte von GN⁺ 2025-08-30 | 1 Kommentare | Auf WhatsApp teilen
  • John Carmack hat sich gegen Metas Entwicklung eines eigenen XR-OS ausgesprochen
  • Er betont, dass die Entwicklung eines eigenen Betriebssystems zu mehr Komplexität und höheren Risiken führt
  • Die Nutzung bestehender Plattformen sei effektiver für Entwicklungseffizienz und den optimalen Einsatz von Ressourcen
  • Carmack empfiehlt für schnelle Innovationen und eine zügige Reaktion auf den Markt eine Strategie auf Basis standardisierter Betriebssysteme
  • Er unterstreicht die Notwendigkeit, unnötige technische Spaltung und Fragmentierung zu vermeiden

John Carmacks Argumente gegen ein eigenes XR-OS von Meta

Hintergrund

  • John Carmack ist dafür bekannt, Metas Plan zur Entwicklung eines eigenen XR-OS (Extended Reality) kritisch zu sehen
  • XR-OS bezeichnet ein Betriebssystem für Extended-Reality-Geräte wie AR/VR

Zusammenfassung der Hauptargumente

  • Carmack weist darauf hin, dass die Entwicklung auf bereits am Markt etablierten Plattformen wie Android oder Windows Entwicklungsgeschwindigkeit und Innovation weiter beschleunigen kann
  • Die Entwicklung eines eigenen OS bringt mehrere Probleme mit sich, darunter höhere Komplexität, ein größeres Risiko für Bugs und langfristigen Wartungsaufwand
  • Werden Ressourcen in den Aufbau einer eigenen Plattform gesteckt, gehen die Vorteile der Nutzung standardisierter Werkzeuge und Technologien bestehender Ökosysteme verloren
  • Um auf neue Technologien und veränderte Nutzeranforderungen schneller reagieren zu können, sei eine Strategie mit konsequenter Nutzung bestehender Betriebssysteme effektiver
  • Ein eigenes XR-OS kann sowohl für Entwickler als auch für Verbraucher Kompatibilitätsprobleme und Lernaufwand verursachen

Fazit

  • Carmack bevorzugt langfristig die Strategie, bestehende Plattformen zu nutzen statt ein eigenes XR-OS zu entwickeln, um Fragmentierung zu verhindern und Skalierbarkeit sowie Nutzbarkeit zu maximieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-30
Hacker-News-Kommentare
  • Das Problem daran, bei Meta zu arbeiten, ist, dass ich, wenn ich gute Arbeit leiste, am Ende nur dabei helfe, die Welt noch schlechter zu machen … die wahren Helden sind eher die Leute, die Geld und Effizienz verschwenden<br>Wenn man etwas draufhat, sollte man seine Karriere lieber woanders aufbauen
    • Eine der besten Arten, wie Softwareingenieure der Menschheit dienen können, ist, bei Firmen wie Meta oder TikTok anzuheuern und so lange wie möglich so zu tun, als wären sie inkompetent
    • Ich werde Facebook und verwandte Dienste blockieren und trotzdem zstd benutzen<br>Die Welt ist nicht schwarz-weiß
    • Das ist eine viel zu simple Sichtweise<br>Unabhängig davon, wie man über Metas Kerngeschäft denkt, beschäftigt die Firma viele Ingenieure für verschiedenste Open-Source-Projekte sowie für Forschung und Entwicklung, die mit Social Media nur wenig zu tun haben, etwa VR oder Datacenter-Technologien<br>Es gibt wohl auch schlimmere Wege, dafür bezahlt zu werden, in seinem Interessengebiet zu forschen
    • Das ist zwar eine ziemlich zynische Sicht, aber die bisherigen Daten machen es nicht leicht, ihr zu widersprechen
    • Aber trifft das nicht eigentlich auf alle Großkonzerne zu, sogar auf alle börsennotierten Unternehmen?<br>Die Gründer hatten anfangs vielleicht andere Ziele, aber mit der Zeit bleibt am Ende doch nur der Profit übrig, und der steigt meist umso stärker, je mehr man sich auf schädliche Dinge konzentriert<br>Das ist ein systemisches Problem
  • Ich habe verschiedenste Low-Level-Software, BSPs und fast ganze Betriebssysteme gebaut, und der eigentliche Grund, warum man heute kein OS mehr selbst baut, sind die Silicon-Vendoren<br>Früher bekam man detaillierte Spezifikationen und konnte seine Treiber selbst schreiben, heute bekommt man nur vage Beschreibungen und irgendeinen minderwertigen Linux-Treiber hingeworfen<br>Teilweise ist das Faulheit, aber vor allem ist die Komplexität massiv gestiegen<br>Moderne Hardware ist so komplex, dass allein ihre vollständige Dokumentation lange dauert, und eigene Treiber zu schreiben dauert noch länger
    • Intel liefert immer noch ordentliche Dokumentation<br>Für High-Speed-NICs gibt es sehr detaillierte öffentliche Unterlagen, und für Karten wie die e810-100Gb-Ethernet-Karte kann man tatsächlich allein mit dem offiziellen 2750-seitigen Datenblatt einen Treiber von Grund auf schreiben<br>Andere Vendoren (1) ignorieren einen, (2) verlangen ein NDA oder (3) zeigen nur schlechte Linux-/FreeBSD-Treiber als Dokumentation<br>Wie die Lage bei anderer Hardware wie NVMe-SSDs ist, weiß ich nicht genau
    • Ich habe kürzlich auch versucht, in meinem Hobby-OS Unterstützung für einen „Soft Reboot“-Button einzubauen, und es war so unerquicklich, dass ich aufgegeben habe (um Reboots in GCP zu beschleunigen)<br>Ich habe die Anleitungen im OS Dev Wiki sowie den Linux- und FreeBSD-Quellcode durchforstet, kam aber überhaupt nicht voran<br>Das ist die Funktion, die Windows oder Linux beim Neustart benutzt<br>Nach ein paar verschwendeten Tagen habe ich es aufgegeben<br>OS-Entwickler sind wirklich anders gestrickt und scheinen meist keinen wirtschaftlichen Druck zu haben
    • Dieses „Moderne Hardware ist zu komplex, um sie sauber zu dokumentieren“ hört man ständig, aber ich halte das für eine Ausrede<br>Neue Mitarbeiter im Team müssen eingearbeitet werden, Tests müssen organisiert werden — wenn etwas komplex ist, müsste es eigentlich noch gründlicher dokumentiert werden<br>Darum überzeugt mich die Ausrede der Silicon-Vendoren nicht
    • Wenn man heute ernsthaft ein eigenes OS bauen will, muss man entweder die Hardware sehr stark kontrollieren oder eine servant Linux-Instanz ins OS einbetten<br>Windows hat Treiber, die sich wie Bugs anfühlen, und Linux bietet kostenlose Bug-Treiber<br>Wenn es okay ist, dass das OS als Client auf einem Linux-Hypervisor weiterläuft, kann man diesen Weg gehen; wenn nicht, bleibt nur, Hardware-Support Stück für Stück ins eigene OS zu übernehmen. Das muss allerdings schneller gehen, als neue Linux-Abhängigkeiten entstehen …
    • Für bestimmte Arten von Betriebssystemen dürfte es ziemlich einfach sein, den Linux-Hardware-Support über portiertes LKL(https://github.com/lkl/linux) mitzunehmen und nur Hooks für den Hardwarezugriff hinzuzufügen<br>Natürlich müsste man Code für die Core-Plattform bzw. den Chipsatz separat schreiben, aber die übrigen I/O-Geräte wären damit fast vollständig abgedeckt<br>Mit einem Stil, der User-Mode-Treiber unterstützt, dürfte das besser funktionieren als bei einem typischen monolithischen Kernel
  • Was John sagt, beschreibt genau das System, das ich mir tatsächlich von jemandem gebaut wünsche<br>„Wenn man einen wirklich völlig anderen Computer bauen will, braucht man praktisch einen abgeschiedenen Orden von Mönchsingenieuren, um dem Gravitationsschacht bereits existierender Lösungen zu entkommen“<br>Als Gedankenexperiment:<br>- Einen Ort finden, an dem die Lebenshaltungskosten 200 Dollar im Monat betragen<br>- Ein lebenswertes Dorf schaffen (saubere Luft, gesundes Essen, gute Schulen usw.) — günstig genug, dass ein reicher Sponsor es problemlos finanzieren könnte<br>- Unmengen an Computern bereitstellen, aber fast ohne Software und Internet<br>- Eine völlig neue Art des Computings von Grund auf entwickeln<br>Geduld ist der Schlüssel. Das würde Jahrzehnte dauern
    • Die Idee ist wirklich faszinierend<br>Ich frage mich, welche Orte überhaupt so niedrige Lebenshaltungskosten hätten<br>Was ich aber ernsthaft wissen will: Warum sollte man ausgerechnet jetzt versuchen, ein Problem zu lösen, das sich nicht sofort realisieren lässt? Müsste man nicht bei Hardware wie CPUs anfangen? Ich erinnere mich an eine Bemerkung eines früheren Intel-Ingenieurs — wenn man moderne ISAs, CPU-uArchs und GPUs komplett lernen und dann von Grund auf neu bauen will, schafft man das mit echter Praxiserfahrung und all den Irrwegen wohl erst kurz vor der Rente
    • Ich baue seit über zehn Jahren mein eigenes OS, und wenn man wirklich etwas erreichen will, ist das kein sinnvoller Weg Natürlich macht es Spaß, und manchmal stelle ich mir vor, wie weit es wachsen könnte, wenn sich irgendwann eine gewaltige Entwicklerarmee darauf stürzen würde. (Geld würde es natürlich keins einbringen)
    • Ehrlich gesagt klingt das nach einem extrem coolen SF-Konzept
  • Bei Meta gibt es im OS-Bereich viele Leute, die von Microsoft gekommen sind, und die wollten ursprünglich immer Betriebssysteme bauen<br>Bei Meta landeten sie dann aber in XR-Projekten und wollten natürlich ein Custom-OS bauen
  • Wegen dem, was John Carmack bei Meta gemacht hat, fällt es mir inzwischen schwer, ihn noch wirklich ernst zu nehmen<br>Schon SerenityOS hat gezeigt, dass es absolut möglich ist, ein System zu bauen, das benutzbarer und konsistenter ist als Windows oder Linux<br>Eine klare Vision, Durchsetzungskraft und Hingabe sind wichtiger als „Top-Ingenieure“ einzustellen oder „hochwertigen Code“ zu haben — wenn man das mitbringt, folgen gute Leute und guter Code ohnehin<br>Deshalb ist so etwas bei Meta unmöglich, und deshalb sieht Linux heute so aus, wie es aussieht<br>Das eigentliche Hindernis sind am Ende die Treiber. Siehe auch: das Thirty-Million-line-Problem — Blog von caseymuratori.com
  • Nach der Oculus-Übernahme war XROS für die zentralen Technikteams wirklich lästig und ablenkend<br>In diversen Tech-Stacks gab es ohnehin schon Berge ungelöster Probleme, und die Idee von XROS kam erst auf, nachdem Oculus vollständig in FB integriert war<br>Für mich wirkte es so, als hätten ein paar Teams (oder Einzelpersonen) bei FB beim ARVR-Trend mitmischen wollen<br>Carmack hatte vollkommen recht, und nach der Reorg wurde sein Einfluss immer kleiner, was ich am eigenen Leib als negativ gespürt habe
    • Der Großteil des XROS-Teams wurde nicht aus dem FB-Stamm rekrutiert, sondern als erfahrene Leute aus der Branche geholt (meist auf E5-/E6-Level) FB-SWEs passten technisch nicht dazu, einige kamen aus Bootcamps, schafften es nicht und wechselten bald wieder weg
    • Ich bin wütend darüber, wie die Oculus-Open-Source-Community ruiniert wurde und ein von der Community finanziertes Projekt in eine weitere Meta-Kette verwandelt wurde, um persönliche Daten abzugreifen<br>Ich hoffe trotzdem, dass wenigstens die Gehaltsschecks üppig waren
  • Ich habe etwa 2002 bis 2004 bei Microsoft ein internes Paper gelesen, das einige OS-Entwickler wie bei einem Hackathon für Bill Gates’ Think Week geschrieben hatten<br>Es war ein völlig neues Betriebssystem auf Basis von .NET, mit eigener GC und eigenem Memory Management, es bootete auf verschiedener Hardware und hatte viele interessante Funktionen<br>Es war explizit auf null Kompatibilität mit Windows ausgelegt, und vermutlich war genau das der Grund für sein Scheitern<br>Ein paar OS-Experten hatten etwa einen Monat lang fokussiert daran gearbeitet, und es war wirklich spannend
  • Es hieß, John Carmack sei vom Manager des XROS-Teams bei HR gemeldet worden, weil er „die Gefühle der Teammitglieder verletze“<br>Ich selbst habe Carmacks öffentliche Kommunikation immer als professionell und freundlich wahrgenommen<br>Ich habe etwas Ähnliches mit einer als Waffe eingesetzten HR erlebt, und so etwas erzeugt ein Klima der Einschüchterung — sobald man denkt, dass einen jemand bei HR melden kann, nur weil ihm etwas nicht gefällt, wird jeder danach extrem vorsichtig mit seinen Aussagen
    • Ich habe Carmacks interne Posts bis zu seinem Abgang verfolgt; er war extrem streng, was Ressourcenverschwendung anging, und wenn Hand-Tracking häufig kaputt war, hat er das mit Zahlen belegt klar angesprochen<br>Seine Botschaft war immer: „Apple kontrolliert die Hardware, also ist effiziente Software jetzt der Schlüssel zur Zukunft“, und Metas Ineffizienz sei letztlich Folge interner Machtkämpfe
    • Lucovsky bestand darauf, ein OS direkt von Grund auf neu zu bauen, und verlor dabei die Realität aus dem Blick, dass Produktteams tatsächlich etwas an Kunden ausliefern mussten; deshalb wurde er verdrängt<br>Auch die toxische Wirkung, die er hinterließ (deren Ausmaß ihm offenbar nicht bewusst war), spielte eine Rolle Ähnliches wiederholte sich später bei Google; auch dort wurde er letztlich verdrängt, offiziell hieß es dann, er sei freiwillig zurückgetreten

Twitter-Verweis 1 Twitter-Verweis 2

  • John kann im direkten persönlichen Umgang ziemlich unverblümt und scharf sein<br>Bei Dingen, von denen er nicht überzeugt ist, kann er übermäßig kritisch werden, und dann ist es wegen des Machtgefälles schwer, ihm zu widersprechen
  • Die interne Stimmung bei Meta war damals etwas merkwürdig<br>PSC (Leistungsbeurteilung) war wichtig, und wenn eine legendäre Figur wie Carmack mein Projekt als „Ressourcenverschwendung“ bezeichnete, traf das meine Bewertung direkt<br>„Impact“ ist bei Facebook eine wichtige Achse dafür, wie nützlich etwas für das Unternehmen ist
  • Ähnliches habe ich auch bei Google gesehen<br>Ein Distinguished Engineer sagte einem Junior-Ingenieur erst sanft und dann sehr deutlich, dass dessen Idee schlecht sei und er sie aufgeben solle, woraufhin HR eingeschaltet wurde<br>In so einer Umgebung habe ich Probleme manchmal einfach durchgewunken, weil ich keine Zeit und Energie mehr hineinstecken wollte
  • Ich war bei Google, als das Flutter-Team an Fuchsia gearbeitet hat<br>Das waren wirklich außergewöhnlich gute Leute (die besten Ingenieure, die ich je gesehen habe), und es waren Hunderte, also ein riesiges Projekt<br>Technisch war es beeindruckend, aber niemand konnte von Anfang an klar beantworten, wer das eigentlich benutzen würde<br>Wenn nur der Kernel neu gebaut und Linux ersetzt werden sollte, wäre das nachvollziehbar gewesen, aber stattdessen wollte man beim Betriebssystem jede Schicht vom Kernel über die UI bis zum Window Manager von Grund auf neu bauen<br>Am Ende zielte es nur auf spezielle Geräte mit UI wie den Home Hub, und selbst dafür konnte niemand überzeugend erklären, warum man das OS gegenüber bestehenden Produkten überhaupt so komplex umbauen musste<br>Dass Fuchsia immer noch weiterläuft, erscheint mir bis heute fast absurd unverständlich<br>Noch deprimierender ist, dass Google in Umstrukturierungen essenziellen Teams Ressourcen gekürzt hat, während für so ein Projekt weiter Leute übrig waren<br>Ich verstehe wirklich nicht, warum man das am Leben hält
    • Wenn man nur auf kurzfristige Ergebnisse schaut, ist das schwer zu rechtfertigen, aber langfristig ist die Entwicklung eines neuen OS durchaus sinnvoll<br>Google interessiert sich tatsächlich für langfristige Investitionen, und ein Projekt muss seinen Nutzen nicht unbedingt nach außen hin rechtfertigen<br>Die Kritiker wirken eher seltsam. Wer mitmachen will, macht mit, und wer nicht, ignoriert es eben<br>Ein neues Application-Ökosystem aufzubauen war von Anfang an nicht das Ziel; das Schwierigste ist vielmehr, all die Technologien selbst umzusetzen, die man sonst als selbstverständlich hinnimmt. Schwer, aber nicht unmöglich<br>Mehr Auswahl kann nichts Schlechtes sein — statt der widersprüchlichen Logik, dass Vielfalt im Browsermarkt wichtig sei, aber ein Monopol im OS-Markt okay, wären mehr unterschiedliche Betriebssysteme doch etwas Gutes
    • Einige Geräte (Home Hub) dienten wohl nur als Einstiegspunkt; dort wollte man Erfahrung und Einnahmen sammeln und dann schrittweise expandieren Ich glaube nicht, dass der Plan war, alles auf einmal zu ersetzen
    • Ich hatte Fuchsia eigentlich als ein neues Paradigma verstanden, in dem mehrere Betriebssysteme und App-Pakete vollständig containerisiert laufen In meiner Vorstellung war das ein Zukunfts-OS, das auch im Web laufen und über mehrere Maschinen verteilt gemeinsam arbeiten könnte Ich hatte auch erwartet, mehrere Instanzen auf derselben Maschine laufen zu lassen und jeweils auf verschiedene Nutzer zuzuschneiden
    • Für mich wirkte Fuchsia wie ein Zermürbungsprojekt, mit dem Google erstklassige Kernel-Ingenieure davon abhalten wollte, zur Konkurrenz zu gehen
    • Man hat Fuchsia auf dem Home Hub gewaltsam durchgedrückt, wodurch der bestehende Stack sofort Legacy war, und danach gab es trotz ständig verzögerter Zeitpläne keinerlei greifbares Ergebnis<br>Ein eigenes OS zu bauen wirkte zwar cool, aber insgesamt hatte das Projekt eher negative Auswirkungen auf die Arbeit der anderen Teams
  • Heutzutage ist es einfacher geworden, den Linux-Kernel zu umgehen und direkt auf Hardware zuzugreifen, und CPUs mit vielen Kernen sind alltäglich<br>Der Kernpunkt ist, Kerne zu isolieren und Threads zuzuweisen und die Hardware dann mit Kernel-Bypass-Techniken direkt zu steuern. Die Kommunikation zwischen den Kernen läuft über Ringbuffer; damit bekommt man nahezu hardwareoptimierte Leistung und kann zugleich die Vorteile des Linux-Kernels bei Verwaltung, Monitoring und Debugging nutzen
    • So wie man mit mmap auf /dev/mem physischen Speicher direkt ansprechen kann, ist Kernel-Bypass jederzeit möglich