La postura de John Carmack en contra de que Meta construya un XR OS personalizado

• John Carmack expresó su postura en contra del desarrollo de un XR OS personalizado por parte de Meta
• Enfatizó que desarrollar un sistema operativo propio conduce a mayor complejidad y riesgo
• Sostuvo que aprovechar plataformas existentes es más efectivo para la eficiencia de desarrollo y el uso óptimo de recursos
• Carmack recomendó una estrategia basada en sistemas operativos estándar para lograr innovación rápida y capacidad de respuesta en el mercado
• Destacó la necesidad de evitar una división técnica y fragmentación innecesarias

---

Argumentos de John Carmack contra un XR OS personalizado de Meta

Contexto

• Se sabe que John Carmack tiene una postura negativa respecto a la posibilidad de que Meta desarrolle por su cuenta un XR OS (realidad extendida) personalizado
• XR OS se refiere al sistema operativo que funciona en dispositivos de realidad extendida como AR/VR

Resumen de los principales argumentos

• Carmack mencionó que, si se desarrolla sobre plataformas ya existentes en el mercado (Android, Windows, etc.), la velocidad de desarrollo y la innovación pueden acelerarse aún más
• El desarrollo de un OS personalizado conlleva varios problemas, como mayor complejidad, riesgo de aparición de bugs y carga de mantenimiento a largo plazo
• Si se invierten recursos en construir una plataforma propia, se sacrifica la ventaja de aprovechar herramientas y tecnologías estandarizadas del ecosistema existente
• Para responder con mayor rapidez a las nuevas tecnologías y a los cambios en las demandas de los usuarios, resulta efectiva una estrategia que aproveche activamente los sistemas operativos existentes
• Un OS personalizado puede generar problemas de compatibilidad y costos de aprendizaje tanto para desarrolladores como para consumidores

Conclusión

• Carmack prefiere una estrategia de aprovechar plataformas existentes antes que desarrollar un XR OS personalizado, para evitar a largo plazo la fragmentación de la tecnología y los servicios, y maximizar la escalabilidad y utilidad

[GN⁺]

Comentarios en Hacker News

• El problema de trabajar en Meta es que, si logro buenos resultados, en realidad estoy ayudando a empeorar el mundo… Me hace pensar que los verdaderos héroes son quienes desperdician dinero y eficiencia<br>Si tienes talento, recomiendo hacer carrera en otro lado
  • Una de las mejores formas en que un ingeniero de software puede servir a la humanidad es entrar a una empresa como Meta o TikTok y fingir incompetencia el mayor tiempo posible
  • Yo voy a bloquear Facebook y servicios relacionados, pero seguiré usando zstd<br>El mundo no funciona en blanco y negro
  • Esa es una visión demasiado simplista<br>Más allá de lo que pienses del negocio principal de Meta, la empresa emplea a muchos ingenieros en diversos proyectos de código abierto y en I+D como VR y tecnología de centros de datos, que no tienen mucho que ver con redes sociales<br>Creo que hay caminos peores que recibir un sueldo por investigar en áreas que te interesan
  • Es una opinión algo pesimista, pero con los datos que hemos visto hasta ahora no es fácil refutarla
  • Pero en realidad, ¿no aplica eso a todas las grandes empresas, e incluso a todas las compañías que cotizan en bolsa?<br>Puede que los fundadores hayan tenido otros objetivos al principio, pero con el tiempo al final todo se reduce a las ganancias, y por lo general las ganancias aumentan mucho más cuando te enfocas en hacer cosas malas<br>Es un problema sistémico
• He hecho bastante software de bajo nivel, BSP y casi sistemas operativos completos, y la verdadera razón por la que hoy no se hacen OS desde cero son los vendors de silicio<br>Antes te daban especificaciones detalladas para que pudieras escribir drivers por tu cuenta, pero ahora te avientan descripciones ambiguas y drivers de Linux de mala calidad<br>Hay algo de flojera, pero también es porque la complejidad ha aumentado<br>El hardware moderno es tan complejo que documentarlo completo ya toma muchísimo tiempo, y escribir tus propios drivers toma aún más
  • Intel todavía entrega documentación decente<br>Hay documentación muy detallada disponible para NICs de alta velocidad, y en el caso de la tarjeta Ethernet e810 de 100Gb, por ejemplo, se puede escribir un driver desde cero usando solo el datasheet oficial de 2750 páginas<br>Otros vendors (1) te ignoran, (2) te exigen un NDA o (3) solo te muestran documentación mediocre de drivers de Linux/FreeBSD<br>No sé bien cómo esté la situación con otro hardware como los SSD NVMe
  • Yo también hace poco intenté dar soporte a un botón de "reinicio por software" en un OS de hobby y fue tan difícil que terminé rindiéndome (quería acelerar los reinicios en GCP)<br>Leí toda la guía de OS Dev Wiki, además del código fuente de Linux y FreeBSD, y no avancé nada<br>Es una función que usan tanto Windows como Linux al reiniciar<br>Perdí varios días y al final lo dejé<br>Los desarrolladores de OS realmente están hechos de otra materia, y por lo general parece que no tienen presión económica
  • Mucha gente dice “el hardware moderno es tan complejo que es difícil documentarlo”, pero yo creo que es puro pretexto<br>También tienes que entrenar gente nueva en el equipo y gestionar las pruebas, así que si algo es complejo, deberías documentarlo con más detalle, no menos<br>O sea, las excusas de los vendors de silicio no me convencen
  • Si hoy realmente quieres hacer un OS serio desde cero, me parece que solo hay dos caminos: tener un control muy fuerte sobre el hardware, o incluir una instancia de Linux sirviente dentro del OS<br>Windows tiene drivers que parecen bugs pero al menos los tiene, y Linux tiene drivers gratis llenos de bugs<br>Si no te molesta que tu OS corra como invitado sobre un hipervisor de Linux, ese puede ser el camino; si no, no queda otra que ir trasladando poco a poco las funciones de soporte de hardware a tu propio OS. Eso sí, tienes que avanzar más rápido de lo que Linux crea nuevas dependencias…
  • Para cierto tipo de OS, creo que sería fácil reutilizar gran parte del soporte de hardware de Linux usando LKL portado (https://github.com/lkl/linux) y agregando solo hooks para acceso al hardware<br>Claro, el código para la plataforma/chipset base habría que escribirlo aparte, pero el resto de dispositivos de I/O quedaría casi todo cubierto<br>Probablemente funcionaría mejor con un estilo que soporte drivers en modo usuario que con un kernel monolítico típico
• Lo que dice John describe exactamente el tipo de sistema que me gustaría que alguien realmente construyera<br>“Si quieres hacer una computadora completamente distinta, para escapar del pozo gravitacional de las soluciones ya existentes prácticamente necesitas una orden monástica de ingenieros ermitaños”<br>Como experimento mental:<br>- Elegir un lugar donde el costo de vida mensual sea de 200 dólares<br>- Crear un pueblo agradable para vivir (aire limpio, comida sana, buenas escuelas, etc.) — lo bastante barato como para que incluso un millonario lo pueda patrocinar sin problema<br>- Llenarlo de computadoras con poco o nada de software e internet<br>- Intentar crear desde cero una forma totalmente nueva de computación<br>La clave es la paciencia. Tomaría décadas
  • La idea me parece fascinante Me da curiosidad qué lugares podrían tener un costo de vida así de bajo Pero lo que de verdad me pregunto es por qué intentar resolver de inmediato problemas que hoy son inviables. ¿Habría que empezar desde hardware como el CPU? Recuerdo algo que dijo un ingeniero ex-Intel: para aprender y rehacer por completo ISA modernas, microarquitectura de CPU, GPU y todo lo demás, con experiencia real y errores incluidos, apenas te alcanzaría la vida profesional y quizá lo logres ya al jubilarte
  • Llevo más de 10 años haciendo mi propio OS, y si de verdad quieres lograr algo concreto, no es una buena idea meterte en eso<br>Claro que es divertido, y a veces imagino hasta dónde podría llegar si algún día se sumara un ejército enorme de desarrolladores. (Aunque claro, no daría dinero)
  • Honestamente, esto suena como un concepto de ciencia ficción increíblemente bueno
• En Meta hay bastante gente llegada de Microsoft para temas de sistemas operativos, y a esas personas originalmente les interesaba crear OS<br>Pero en Meta las pusieron a trabajar en XR, así que naturalmente querían hacer un OS personalizado
• Por lo que John Carmack hizo en Meta, ahora me cuesta tomarlo totalmente en serio<br>Solo con ver SerenityOS, ya quedó claro que sí era posible construir un sistema más usable y coherente que Windows o Linux<br>Una visión clara, empuje y compromiso son más importantes que contratar “ingenieros top” o tener “código de alta calidad” — si tienes eso, el buen código y el talento terminan llegando solos<br>Esa es la razón por la que eso era imposible en Meta, y también por la que Linux está como está ahora<br>El obstáculo real al final son los drivers. Referencia: el problema de las treinta millones de líneas — blog de caseymuratori.com
• Trabajé después de la adquisición de Oculus, y XROS era realmente una molestia y una distracción para los equipos técnicos centrales<br>Ya había una montaña de problemas por resolver en varias capas del stack, y la idea de XROS apareció después de que Oculus quedara completamente integrada en FB<br>Desde mi punto de vista, parecía que algunos equipos (o individuos) de FB querían subirse a la tendencia de AR/VR<br>Carmack tenía toda la razón, y después de la reorganización se sentía directamente cómo su influencia iba disminuyendo y eso tenía efectos negativos
  • La mayor parte del equipo de XROS no venía de la sede central de FB, sino que fue contratada desde la industria como personal con experiencia (principalmente nivel E5/E6)<br>Los SWE de FB no daban el perfil técnico; también hubo algunos egresados de bootcamp, pero no funcionaron y pronto se fueron a otra parte
  • Me da rabia cómo destruyeron la comunidad open source de Oculus, y cómo convirtieron otro proyecto financiado por la comunidad en una cadena más de Meta para recolectar datos personales<br>Aun así, espero que al menos les hayan pagado muy bien
• Entre 2002 y 2004, más o menos, en Microsoft leí un paper interno que algunos desarrolladores de OS habían escrito como si fuera un hackatón para la Think Week de Bill Gates<br>Era un sistema operativo completamente nuevo sobre una base .NET, con GC y gestión de memoria implementados directamente, podía arrancar en varios tipos de hardware y tenía funciones interesantes<br>Estaba diseñado con compatibilidad cero con Windows, y probablemente esa fue la razón de su fracaso<br>Fue un trabajo que unos cuantos expertos en OS hicieron concentrándose durante como un mes, y era realmente fascinante
  • ¿Era Singularity?<br>Explicación en Wikipedia<br>Página oficial de Microsoft Research
  • Creo que era el proyecto Midori<br>En realidad fue un gran proyecto de Microsoft Research con más de 100 personas durante varios años<br>Artículo de ZDNet sobre el proyecto Midori
• Se comentó que John Carmack fue reportado a HR por el gerente del equipo XROS por “hacer sentir mal” a miembros del equipo<br>La verdad, en la comunicación pública de Carmack siempre me ha parecido profesional y amable<br>Yo también he vivido experiencias similares de HR usada como arma, y ese tipo de cosas enfrían mucho el ambiente en una empresa — una vez que piensas que alguien puede denunciarte a HR solo porque no le gustó lo que dijiste, a partir de ahí todo el mundo empieza a cuidar muchísimo lo que dice
  • Seguí sus publicaciones internas antes de que renunciara, y era extremadamente estricto con el desperdicio de recursos; si el seguimiento de manos fallaba con frecuencia, lo señalaba con métricas en mano<br>Su mensaje siempre iba en la línea de que “Apple ya ganó el hardware, así que ahora el software eficiente es la clave del futuro”, y el despilfarro de Meta al final se debía a luchas internas de poder dentro de la organización
  • Lucovsky insistía en hacer un OS desde cero y no veía la realidad de que los equipos de producto tenían que entregar algo real a los clientes, por eso terminó desplazado<br>También influyó la toxicidad que dejó (aunque él mismo no parecía entender su gravedad)<br>Comportamientos parecidos se repitieron en Google, donde al final también lo fueron apartando, y oficialmente quedó como si hubiera renunciado por voluntad propia<br>Referencia en Twitter 1 Referencia en Twitter 2
  • En persona, John puede ser bastante directo y filoso<br>Puede ser excesivamente crítico con cosas en las que no cree, y en esas situaciones, por la diferencia de poder, resulta difícil llevarle la contraria
  • Meta en ese tiempo tenía un ambiente interno algo raro<br>Como el PSC (evaluación de desempeño) importaba mucho, si una figura legendaria como Carmack calificaba mi proyecto como “desperdicio de recursos”, eso pegaba directo en tu evaluación<br>“Impacto” es un eje clave en Facebook para medir qué tan útil es algo para la empresa
  • Vi algo parecido en Google<br>Un distinguished engineer primero le dijo con suavidad a un ingeniero junior, y luego de forma tajante, que “era una mala idea y debía dejarla”, y HR terminó interviniendo<br>En situaciones así, a veces simplemente dejé pasar el problema porque ya no quería invertir más tiempo ni esfuerzo
• Estuve en Google cuando el equipo de Flutter estaba haciendo Fuchsia<br>Era gente realmente brillante (de los mejores ingenieros que he visto), eran cientos de personas y el proyecto era grande<br>Técnicamente era excelente, pero desde el principio nadie podía responder claramente quién iba a usarlo

Si el objetivo hubiera sido solo hacer un kernel nuevo para reemplazar Linux, habría tenido sentido, pero en cambio intentaron construir todo el sistema operativo desde cero, desde el kernel hasta la UI y el window manager<br>Al final solo apuntaron a dispositivos especiales con pura UI, como Home Hub, y ni siquiera ahí lograron explicar por qué valía la pena cambiar el OS de forma tan compleja respecto a los productos existentes<br>Todavía me parece absurdamente difícil de entender que Fuchsia siga vivo Me deprime más ver que Google hizo recortes de recursos a equipos esenciales durante la reestructuración, pero aun así dejó gente en proyectos como este<br>De verdad no entiendo por qué lo siguen manteniendo

• Si solo miras resultados de corto plazo, es difícil encontrarle defensa, pero pensando a largo plazo sí tiene sentido desarrollar un nuevo OS<br>Google realmente se interesa por las inversiones de largo plazo, y el proyecto no necesita justificar su existencia hacia afuera<br>Criticarlo con tanta insistencia me parece más raro que participar si te interesa o simplemente ignorarlo si no<br>Nunca se buscó crear un nuevo ecosistema de aplicaciones, y lo más difícil era implementar toda esa enorme cantidad de tecnología que normalmente damos por sentada. Es difícil, pero no imposible<br>No tiene nada de malo tener más opciones — en vez de la lógica contradictoria de decir que la diversidad importa en el mercado de navegadores pero que el monopolio está bien en el mercado de OS, sería mejor tener más sistemas operativos distintos
• Supongo que la idea era empezar con algunos dispositivos (Home Hub), acumular experiencia e ingresos ahí y luego expandirse poco a poco<br>No creo que hayan arrancado con la idea de reemplazarlo todo de golpe
• Yo entendía Fuchsia más bien como un nuevo paradigma en el que varios OS y paquetes de apps correrían completamente en contenedores<br>En mi imaginación, apuntaba a un OS del futuro que también pudiera correr en la web y en varias máquinas al mismo tiempo<br>También esperaba un esquema donde varias instancias corrieran en la misma máquina para adaptarse a distintos usuarios
• Siempre sentí que Fuchsia era una especie de proyecto de desgaste para que Google retuviera a sus ingenieros de kernel más talentosos y no se fueran a la competencia
• Forzaron el uso de Fuchsia en Home Hub, con lo que el stack anterior quedó inmediatamente legado, y después siguieron acumulándose retrasos sin resultados reales<br>Hacer un OS propio se veía cool, pero sentí que todo el proyecto terminó afectando negativamente el trabajo del resto de los equipos
• Hoy es más fácil saltarse el kernel de Linux y acceder al hardware directamente, y además los CPU con muchos núcleos ya son comunes<br>La clave es aislar núcleos y asignarles hilos, controlar directamente el hardware con técnicas de kernel bypass y usar ring buffers para la comunicación entre núcleos; así obtienes un rendimiento casi optimizado al nivel del hardware y al mismo tiempo aprovechas las ventajas del kernel de Linux para administración, monitoreo y depuración
  • Igual que cuando haces mmap de /dev/mem para acceder directamente a memoria física, siempre es posible hacer kernel bypass