Como construir um sistema operacional sem se perder

Como construir um sistema operacional sem se perder

O texto é um follow-up de "The Framebuffer People", em que o autor clonou quase todos os sistemas operacionais postados no r/osdev e encontrou majoritariamente reskins de Linux gerados com IA. Após receber perguntas do tipo "ok, mas o que devo construir então?", ele oferece onze regras para desenvolver um OS que realmente ensine algo.

As onze regras

Regra 1 - Rotule o projeto com honestidade. Declare que é um OS de aprendizado. Ninguém ataca projetos claramente etiquetados como brinquedo. Os problemas começam quando um fim de semana de prompts gera uma lista de funcionalidades maior que a intro de Star Wars, com link de doação e a palavra "revolucionário".

Regra 2 - Faça cirurgia num OS real. Em vez de partir de uma pasta vazia, pegue um OS estabelecido, remova um componente (scheduler, alocador, filesystem, pipes) e reconstrua-o com o resto do sistema observando. Um OS real é um revisor hostil que nunca cansa. Quando você é ditador do próprio repo vazio, toda decisão está correta por padrão e você não aprende nada.

Regra 3 - Leia na velocidade do papel. O autor levou cerca de 200 dias para ler FreeBSD Device Drivers de capa a capa. A leitura não é taxa sobre o trabalho; a leitura é o trabalho. A digitação no final é apenas o recibo.

Regra 4 - Compre o ThinkPad antes do domínio. Um ThinkPad usado custa quarenta dólares e encontra bugs que o QEMU é estruturalmente incapaz de mostrar: timing quirks, mentiras de firmware, dispositivos que violam a própria especificação. O OS deve encontrar metal antes de encontrar o público.

Regra 5 - Escreva um driver. O que falta no mundo hobby de OS são drivers. Ninguém os escreve porque todos vivem num framebuffer onde os problemas difíceis já estão resolvidos pelo host. Um driver de NIC real, um controlador USB com EHCI/XHCI de verdade, um chip WiFi - nenhum OS postado no subreddit tem stack de WiFi ou Bluetooth. O primeiro hobbyista que entregar um terá feito algo que os dez mil shells de framebuffer combinados não fizeram.

Regra 6 - Diga "implementado", guarde "inventado". exFAT escrito em Rust ainda é exFAT. Você implementa specs, porta software, adapta drivers. Se um dia realmente inventar algo, a palavra estará disponível porque você não a gastou numa função CRC32.

Regra 7 - Trate IA como um sênior em quem você não confia. Use para explicar diferenças entre PIC e APIC, discutir design de VFS, entender por que seu page fault handler dá double-fault. Mas não digite "make it perfect" e aceite o todo-list resultante. O autor relata um caso em que o GPT-4o afirmou com 100% de certeza que um chip não tinha capacidade USB - o chip tinha - e repetidamente "corrigiu" o banco de dados para estar errado.

Regra 8 - Sem mendigar. Sem Ko-fi, sem Patreon, sem botão de sponsor. A única exceção são projetos de libertação de hardware travado (Asahi Linux, jailbreaks de Switch/PlayStation/tratores), que queimam hardware retail e enfrentam advogados. Aprender a piscar um pixel não precisa de financiamento: QEMU é grátis, o wiki é grátis, o ThinkPad custa quarenta dólares.

Regra 9 - Você pode manter o projeto privado. O autor construiu o GaslightOS em 2024, removendo código do Android até rodar no hardware que possuía (Fairphone 5 e um tablet Samsung). Nunca lançou. Instalar um OS alternativo naqueles dispositivos queima fusíveis permanentemente. A decisão de não publicar também faz parte do desenvolvimento: saber o que seu release realmente faz quando sai das suas mãos.

Regra 10 - Tenha uma equipe que discorde. Se sua equipe sempre concorda com você, você não tem equipe, tem audiência. Uma pessoa que diga que seu design de VFS está errado e explique por quê vale mais que um Discord de mil membros.

Regra 11 - Escolha uma faixa. Em times reais de OS, a pessoa que vive no storage stack não escreve o driver WiFi. Filesystems, network stacks, gráficos, gerenciamento de memória - cada um é uma carreira. Largura é exatamente o que a IA tornou grátis, o que significa que largura agora é inútil como sinal. Profundidade é o que ela não consegue falsificar, então profundidade é todo o jogo restante.

O fluxograma de publicação

Antes de postar seu OS, responda quatro perguntas: o rótulo é honesto? Roda em hardware real (ou diz claramente que é só QEMU)? Tem link de financiamento? Você escreveu o código que diz ter escrito? Os "framebuffer people" falham em três das quatro.