O argumento contrário de John Carmack à construção de um XR OS customizado na Meta

• John Carmack expressou oposição ao desenvolvimento de um XR OS customizado pela Meta
• Ele enfatiza que desenvolver um sistema operacional próprio leva ao aumento da complexidade e dos riscos
• Defende que o uso de plataformas existentes é mais eficaz para a eficiência do desenvolvimento e o uso otimizado de recursos
• Carmack recomenda uma estratégia baseada em sistemas operacionais padrão para inovação rápida e resposta ao mercado
• Ele destaca a necessidade de evitar divisão técnica e fragmentação desnecessárias

---

Argumentos de John Carmack contra o XR OS customizado da Meta

Contexto

• John Carmack é conhecido por ter uma visão negativa sobre a possibilidade de a Meta desenvolver internamente um XR (realidade estendida) OS customizado
• XR OS significa o sistema operacional que roda em dispositivos de realidade estendida, como AR/VR

Resumo dos principais argumentos

• Carmack menciona que, ao desenvolver sobre plataformas já existentes no mercado (Android, Windows etc.), a velocidade de desenvolvimento e a inovação podem ser ainda mais aceleradas
• O desenvolvimento de um OS customizado traz vários problemas, como aumento da complexidade, risco de bugs e carga de manutenção de longo prazo
• Ao investir recursos na construção de uma plataforma própria, sacrifica-se a vantagem de aproveitar ferramentas e tecnologias padronizadas do ecossistema existente
• Para responder de forma mais rápida a novas tecnologias e mudanças nas demandas dos usuários, é eficaz adotar uma estratégia que aproveite ativamente os sistemas operacionais existentes
• Um OS customizado pode gerar problemas de compatibilidade e custo de aprendizado tanto para desenvolvedores quanto para consumidores

Conclusão

• Carmack prefere uma estratégia de uso de plataformas existentes em vez do desenvolvimento de um XR OS customizado, para evitar a fragmentação de tecnologias e serviços no longo prazo e maximizar a escalabilidade e a utilidade

[GN⁺]

Opinião no Hacker News

• O problema de trabalhar na Meta é que, se eu tiver sucesso, na prática estarei ajudando a piorar o mundo… às vezes penso que os verdadeiros heróis são as pessoas que desperdiçam dinheiro e eficiência Se você tem talento, eu recomendaria construir sua carreira em outro lugar
  • Uma das melhores formas de um engenheiro de software servir à humanidade é entrar em empresas como Meta ou TikTok e fingir ser incompetente pelo maior tempo possível
  • Eu vou bloquear o Facebook e serviços relacionados, mas continuar usando zstd O mundo não é preto no branco
  • Essa é uma visão simplista demais Independentemente do que você acha do negócio principal da Meta, a empresa emprega muitos engenheiros para trabalhar em vários projetos open source e também em P&D pouco relacionados a redes sociais, como VR e tecnologias de datacenter Receber para pesquisar algo do seu interesse me parece um caminho melhor do que muitas alternativas
  • É uma opinião meio pessimista, mas olhando os dados até agora não é fácil contestar
  • Mas, na verdade, isso não vale para toda big tech, e até para toda empresa de capital aberto? Os fundadores podem até começar com outros objetivos, mas com o tempo tudo acaba girando em torno do lucro, e normalmente o lucro cresce muito mais quando você se concentra em coisas ruins Isso é um problema sistêmico
• Eu já fiz vários softwares de baixo nível, BSPs e praticamente sistemas operacionais inteiros, e o verdadeiro motivo de hoje em dia não se fazer um OS do zero são os fabricantes de silício Antigamente eles forneciam especificações detalhadas para você escrever seus próprios drivers, mas hoje jogam em cima de você descrições vagas e drivers Linux de baixa qualidade Parte disso é preguiça, mas também é porque a complexidade aumentou O hardware moderno é complexo demais; só documentar tudo já leva muito tempo, e escrever drivers na mão levaria ainda mais
  • A Intel ainda fornece documentação decente Há documentação extremamente detalhada para NICs de alta velocidade e, no caso da placa Ethernet e810 100Gb, por exemplo, dá para escrever um driver do zero só com o datasheet oficial de 2750 páginas Outros fornecedores (1) ignoram você, (2) exigem NDA ou (3) mostram apenas a documentação de drivers meia-boca de Linux/FreeBSD Não sei bem como está a situação para outros hardwares, como SSDs NVMe
  • Eu também tentei recentemente adicionar suporte a um botão de "soft reboot" no meu OS de hobby e foi tão difícil que desisti (eu queria reinicializações mais rápidas no GCP) Li as orientações da OS Dev Wiki e até o código-fonte do Linux e do FreeBSD, mas não avancei nada É um recurso usado tanto no Windows quanto no Linux ao reiniciar Depois de desperdiçar alguns dias, acabei largando de vez Desenvolvedores de OS são realmente de outra categoria, e aparentemente não sofrem muita pressão econômica
  • Muita gente diz que “o hardware moderno é complexo demais para documentar”, mas para mim isso é desculpa Você também precisa treinar novos funcionários na equipe e gerenciar testes, então, se algo é complexo, deveria ser documentado com ainda mais detalhe Ou seja, a desculpa dos fabricantes de silício não convence
  • Se hoje alguém estiver pensando seriamente em fazer um OS do zero, parece que só há dois caminhos: ter um controle extremamente forte sobre o hardware ou incluir uma instância servant de Linux dentro do OS O Windows tem drivers que parecem bugs, mas pelo menos eles existem; no Linux, são bugs gratuitos Se tudo bem para você que seu OS rode como cliente sobre um hipervisor Linux, esse é um caminho possível; caso contrário, a única saída é ir trazendo aos poucos o suporte de hardware para o seu OS. Só que isso precisa avançar mais rápido do que o Linux cria novas dependências…
  • Para certos tipos de OS, acho que daria para aproveitar quase todo o suporte de hardware do Linux usando o LKL portado (https://github.com/lkl/linux) e só acrescentando hooks para acesso ao hardware Claro que o código do núcleo da plataforma/chipset ainda teria de ser escrito separadamente, mas o restante dos dispositivos de I/O ficaria quase todo coberto Isso provavelmente funcionaria melhor em um estilo com suporte a drivers em modo usuário do que em um kernel monolítico tradicional
• O que o John disse descreve exatamente o tipo de sistema que eu gostaria que alguém realmente construísse “Se você quer criar um computador completamente diferente, para escapar do poço gravitacional das soluções já existentes, na prática precisa de uma ordem monástica reclusa de engenheiros” Como experimento mental:
• escolher um lugar onde o custo de vida mensal seja de US$ 200
• construir uma vila boa de se viver (ar limpo, comida saudável, boas escolas etc.) — barata o bastante para até um milionário conseguir patrocinar sem grande esforço
• fornecer um monte de computadores com pouco ou nenhum software e quase sem internet
• tentar criar uma computação totalmente nova do zero Paciência é o essencial. Levaria décadas
  • Essa ideia é fascinante demais Fico curioso sobre que lugares teriam um custo de vida tão baixo assim
  • Mas a minha dúvida sincera é: por que tentar resolver agora um problema que ainda não é viável? Não teria que começar pelo hardware, como CPUs? Lembro de algo que um engenheiro ex-Intel disse certa vez — aprender tudo sobre ISA moderna, microarquitetura de CPU, GPU e então criar tudo do zero de verdade só seria possível perto da aposentadoria, depois de passar pela experiência e pelo sofrimento na prática
  • Já faz mais de 10 anos que tento fazer meu próprio OS e, se você realmente quer realizar alguma coisa concreta, isso não é o que deveria fazer Claro, é divertido e às vezes eu imagino até onde poderia crescer se algum dia uma legião de desenvolvedores incríveis se juntasse. (Embora obviamente não fosse dar dinheiro)
  • Sinceramente, isso parece um conceito de ficção científica incrível
• Na Meta havia muita gente vinda da Microsoft na área de sistema operacional, e essas pessoas originalmente tinham muito interesse em fazer OS Mas na Meta elas foram colocadas no trabalho de XR e, naturalmente, queriam criar um OS customizado
• Depois do que o John Carmack fez na Meta, agora é difícil levá-lo totalmente a sério O SerenityOS, por si só, já mostrou que é perfeitamente possível criar um sistema mais usável e consistente do que Windows ou Linux Visão clara, capacidade de execução e dedicação são mais importantes do que contratar “engenheiros de elite” ou ter “código de alta qualidade” — se isso existir, bom código e bons talentos acabam vindo junto É por isso que isso é impossível na Meta, e é por isso que o Linux está do jeito que está hoje O verdadeiro obstáculo, no fim, são os drivers. Referência: problema das trinta milhões de linhas — blog do caseymuratori.com
• Trabalhando lá depois da aquisição da Oculus, o XROS era realmente uma presença incômoda e dispersiva para as equipes centrais de tecnologia Já havia montanhas de problemas para resolver em várias stacks técnicas, e a ideia de XROS só apareceu depois que a Oculus foi totalmente integrada ao FB Do meu ponto de vista, parecia que algumas equipes (ou pessoas) do FB queriam entrar na onda de AR/VR O Carmack estava completamente certo, e depois da reorganização deu para sentir na prática que sua influência foi diminuindo cada vez mais, com efeitos negativos
  • A maior parte da equipe de XROS não veio da sede do FB, mas foi contratada no mercado como gente experiente (na maioria nível E5/E6) Os SWE do FB não tinham o perfil técnico adequado; havia até alguns vindos de bootcamp, mas eles não deram certo e logo foram para outros lugares
  • Fico revoltado com o jeito como destruíram a comunidade open source da Oculus e transformaram mais um projeto financiado pela comunidade em outra corrente da Meta para coletar dados pessoais Mesmo assim, espero que pelo menos o contracheque tenha sido generoso
• Lá por 2002~2004, na Microsoft, eu li um artigo interno que alguns desenvolvedores de OS escreveram meio em formato de hackathon para a Think Week do Bill Gates Era um sistema operacional totalmente novo baseado em .NET, com GC e gerenciamento de memória implementados por eles mesmos, que dava boot em vários tipos de hardware e tinha vários recursos interessantes O design assumia claramente compatibilidade zero com Windows, e provavelmente foi isso que o condenou

Foi o trabalho de alguns especialistas em OS focados por cerca de um mês, e era realmente fascinante

• Era o Singularity?

Explicação na Wikipedia Página oficial da Microsoft Research

• Acho que era o projeto Midori Na verdade foi um grande projeto da Microsoft Research, com mais de 100 pessoas por vários anos

Artigo da ZDNet sobre o projeto Midori

• Surgiu a história de que John Carmack foi denunciado ao RH pelo gerente da equipe XROS por “ferir os sentimentos” dos membros da equipe Pessoalmente, eu sempre achei a comunicação pública do Carmack profissional e gentil Eu também já vivi experiências parecidas de RH sendo usado como arma, e isso esfria o ambiente da empresa — no momento em que você percebe que alguém pode te denunciar ao RH só porque não gostou do que você disse, todo mundo passa a medir muito as palavras
  • Eu continuei acompanhando as postagens internas do Carmack antes de ele sair, e ele era extremamente rígido com desperdício de recursos; quando recursos como hand tracking falhavam com frequência, ele apontava isso com números Sua mensagem era sempre algo como: “A Apple já garantiu o hardware; agora software eficiente é a chave do futuro”, e o desperdício da Meta acabava sendo fruto de disputas de poder dentro da organização
  • O Lucovsky insistiu em criar um OS do zero e não enxergou a realidade de que as equipes de produto em campo precisavam entregar algo de verdade aos clientes, então acabou sendo escanteado A toxicidade que ele deixou (sem perceber a gravidade) também influenciou nisso Comportamento parecido se repetiu no Google, onde ele também acabou sendo afastado, e oficialmente fecharam a história dizendo que ele havia saído por conta própria Referência no Twitter 1 Referência no Twitter 2
  • O John, pessoalmente, pode ser bem direto e cortante às vezes Ele pode ser crítico demais com coisas nas quais não acredita, e nessas horas o equilíbrio de poder torna difícil contestá-lo
  • Na época, a atmosfera interna da Meta era meio estranha Como o PSC (avaliação de desempenho) era importante, se uma figura lendária como Carmack chamasse meu projeto de “desperdício de recursos”, isso ia direto para a minha avaliação

“Impacto” é um eixo importante no Facebook para medir o quanto algo é útil para a empresa

• Vi algo parecido no Google também Um distinguished engineer disse primeiro de forma suave e depois bem objetivamente a um engenheiro júnior que era uma má ideia e que ele deveria parar, e o RH acabou entrando no meio No meio disso tudo, às vezes eu simplesmente deixei o problema passar porque não queria mais gastar tempo e esforço
• Eu estava no Google quando a equipe do Flutter estava fazendo o Fuchsia Era gente realmente brilhante (alguns dos melhores engenheiros que já vi), eram centenas de pessoas e uma organização grande Do ponto de vista técnico, era excelente, mas desde o começo ninguém conseguia responder claramente quem de fato usaria aquilo Se a meta fosse apenas criar um novo kernel para substituir o Linux existente, tudo bem, mas, ao contrário, eles tentaram fazer o sistema operacional inteiro do zero, do kernel até a UI e o window manager No fim, o alvo ficou restrito a dispositivos específicos com UI, como o Home Hub, e mesmo assim nunca conseguiram justificar por que valia a pena mudar o OS de forma tão complexa em relação aos produtos existentes Ainda hoje acho quase absurdo que o Fuchsia continue existindo

Fica ainda mais deprimente ver o Google fazendo reestruturações, cortando recursos de equipes essenciais e mesmo assim mantendo gente em projetos desse tipo Na verdade, eu realmente não entendo por que isso continua vivo

• Se você olhar só para resultado de curto prazo, é difícil defender, mas no longo prazo desenvolver um novo OS faz sentido

O Google de fato se interessa por investimentos de longo prazo, e o projeto não precisa necessariamente apresentar uma justificativa pública clara Na verdade, achar estranho isso existir é que me parece mais estranho. Se quiser, participe; se não, simplesmente ignore A criação de um novo ecossistema de aplicações nunca foi o objetivo, e a parte mais difícil é implementar toda a enorme quantidade de tecnologia que normalmente tratamos como garantida. É difícil, mas não impossível Não há nada de ruim em ter mais opções — em vez da lógica contraditória de defender diversidade no mercado de navegadores e aceitar monopólio no mercado de OS, mais diversidade de sistemas operacionais é algo positivo

• Acho que a ideia era começar com alguns dispositivos (Home Hub) como ponto de partida e, a partir daí, ganhar experiência/receita e ir expandindo aos poucos

Não me parece que o plano fosse substituir tudo de uma vez

• Eu entendia o Fuchsia como um novo paradigma em que vários OS e pacotes de aplicativos rodam como contêineres completos

Na minha imaginação, era uma visão de OS do futuro que também funcionaria na web e poderia rodar em várias máquinas ao mesmo tempo Eu também esperava algo como rodar várias instâncias na mesma máquina, cada uma adaptada a um usuário diferente

• Eu tinha a impressão de que o Fuchsia era, na prática, um projeto de desgaste para o Google manter excelentes engenheiros de kernel ocupados e longe da concorrência
• Empurraram à força o Fuchsia para o Home Hub, a stack existente virou legado na mesma hora, e depois disso os cronogramas continuaram escorregando sem nenhum resultado concreto

Criar um OS do zero parecia algo legal, mas no fim o projeto inteiro me passou a sensação de só ter atrapalhado o trabalho das outras equipes

• Hoje em dia ficou mais simples contornar o kernel Linux e acessar o hardware diretamente, e CPUs com muitos núcleos são comuns

A chave é isolar núcleos para atribuir threads e usar técnicas de kernel bypass para controlar o hardware diretamente. Se a comunicação entre núcleos for feita com ring buffers, dá para chegar perto de um desempenho otimizado para o hardware e, ao mesmo tempo, aproveitar as vantagens do kernel Linux em gerenciamento, monitoramento e depuração

• Kernel bypass sempre foi possível, como fazer mmap de /dev/mem para acessar memória física diretamente, por exemplo