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<br>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<br>O mundo não é preto no branco
  • Essa é uma visão simplista demais<br>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<br>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?<br>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<br>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<br>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<br>Parte disso é preguiça, mas também é porque a complexidade aumentou<br>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<br>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<br>Outros fornecedores (1) ignoram você, (2) exigem NDA ou (3) mostram apenas a documentação de drivers meia-boca de Linux/FreeBSD<br>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)<br>Li as orientações da OS Dev Wiki e até o código-fonte do Linux e do FreeBSD, mas não avancei nada<br>É um recurso usado tanto no Windows quanto no Linux ao reiniciar<br>Depois de desperdiçar alguns dias, acabei largando de vez<br>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<br>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<br>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<br>O Windows tem drivers que parecem bugs, mas pelo menos eles existem; no Linux, são bugs gratuitos<br>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<br>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<br>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<br>“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”<br>Como experimento mental:<br>- escolher um lugar onde o custo de vida mensal seja de US$ 200<br>- 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<br>- fornecer um monte de computadores com pouco ou nenhum software e quase sem internet<br>- tentar criar uma computação totalmente nova do zero<br>Paciência é o essencial. Levaria décadas
  • Essa ideia é fascinante demais<br>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?<br>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<br>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<br>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<br>O SerenityOS, por si só, já mostrou que é perfeitamente possível criar um sistema mais usável e consistente do que Windows ou Linux<br>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<br>É por isso que isso é impossível na Meta, e é por isso que o Linux está do jeito que está hoje<br>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<br>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<br>Do meu ponto de vista, parecia que algumas equipes (ou pessoas) do FB queriam entrar na onda de AR/VR<br>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)<br>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<br>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<br>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<br>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<br>Página oficial da Microsoft Research

• Acho que era o projeto Midori<br>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<br>Pessoalmente, eu sempre achei a comunicação pública do Carmack profissional e gentil<br>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<br>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<br>A toxicidade que ele deixou (sem perceber a gravidade) também influenciou nisso<br>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<br>Referência no Twitter 1 Referência no Twitter 2
  • O John, pessoalmente, pode ser bem direto e cortante às vezes<br>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<br>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<br>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<br>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<br>Era gente realmente brilhante (alguns dos melhores engenheiros que já vi), eram centenas de pessoas e uma organização grande<br>Do ponto de vista técnico, era excelente, mas desde o começo ninguém conseguia responder claramente quem de fato usaria aquilo<br>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<br>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<br>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<br>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