O que aprendi ao criar um sistema operacional

Há muitos anos, quando eu tinha uns 14, 15 anos, abri um tópico no fórum (Clube do Hardware) com um título de uma ambição desproporcional ao meu conhecimento: "Quero criar um sistema operacional".

(E se você quiser uma definição formal do que é um sistema operacional, a Wikipedia explica aqui.)

Eu era um adolescente que mal sabia programar, mas tinha uma ideia fixa na cabeça: um sistema operacional baseado na Web. Na época, isso soava como maluquice — e o tópico rendeu discussões à altura. Mas o tempo é curioso: anos depois, o mundo viu surgir projetos como o Firefox OS, um sistema operacional inteiro construído sobre tecnologias web. A intuição daquele adolescente não era tão maluca assim. Só estava adiantada.

O tópico tomou vida própria. Ao longo dos anos, ele influenciou outras pessoas a criarem seus próprios sistemas operacionais e chegou a inspirar trabalhos acadêmicos. Um dos participantes — também chamado Luciano, conhecido como "Lucky" — levou a ideia mais a sério do que todos nós: criou o seu próprio sistema, o LuckyOS, e o manteve por anos.

Em 2019, ele me mandou um e-mail. A pergunta, em essência, era: "E o seu sistema? Acredito que desistiu... Eu não."

Aquele e-mail ficou ecoando. Eu tinha seguido carreira em desenvolvimento web, desktop e mobile — uma carreira que amo — mas nunca tinha voltado àquela ideia. Até agora.

Este artigo é sobre o brain-os, o sistema operacional educacional que finalmente construí do zero, e sobre tudo o que aprendi no caminho. Mas é também a minha resposta, com mais de 15 anos de atraso: eu também não desisti. Só demorei.

E não se preocupe: você não precisa ser programador para acompanhar. Prometo traduzir cada parte técnica em algo do mundo real.

Primeiro: o que é, afinal, um sistema operacional?

Pense no computador como um prédio comercial gigante. O processador, a memória e o disco são a estrutura: elevadores, energia, salas. O sistema operacional é o síndico: ele decide quem usa o elevador agora, distribui as salas entre as empresas, mantém o registro de onde cada coisa está guardada e impede que um inquilino invada a sala do outro.

Windows, Linux e o sistema do seu celular fazem exatamente isso, o tempo todo, sem que você perceba. Quando você abre dois aplicativos "ao mesmo tempo", é o síndico que fica alternando entre eles tão rápido que parece simultâneo.

Construir um sistema operacional do zero é aceitar o cargo de síndico de um prédio vazio — sem manual de instruções. Foi exatamente essa a parte que me fascinou aos 15 anos. E foi exatamente essa a parte que eu não fazia ideia de como encarar. O adolescente do fórum queria começar pelo telhado: a interface, a experiência, o sonho do sistema web. O que eu não sabia — e levaria mais de uma década para aprender na prática — é que tudo começa muito, muito mais embaixo.

O primeiro desafio: o computador liga sabendo quase nada

Aqui vai algo que teria chocado o adolescente do fórum: quando você aperta o botão de ligar, o computador é praticamente analfabeto. Ele não sabe o que é um arquivo, uma janela, um mouse. A única coisa que ele faz é ler um pedacinho minúsculo do disco — do tamanho de um parágrafo de texto — e executar o que estiver ali.

Esse pedacinho se chama bootloader (algo como "carregador de partida"), e foi a primeira coisa que escrevi no brain-os. O trabalho dele é humilde e essencial: acordar o kernel — o núcleo do sistema operacional, o coração de tudo —, como aquele primeiro funcionário que chega de madrugada, acende as luzes e destranca as portas para os outros entrarem.

A lição do erro silencioso

Nessa fase, aprendi da forma mais dura que em um computador, a memória é um terreno sem cercas. Quando usamos um aplicativo normal, o sistema operacional nos protege: se um programa tenta mexer onde não deve, ele é bloqueado. Mas quem está construindo o sistema não tem essa proteção — porque a proteção ainda não existe.

Em determinado momento, guardei uma informação importante em uma região da memória que parecia livre. Funcionou por semanas. Até que o sistema cresceu e, silenciosamente, passou a ocupar aquele mesmo espaço — apagando meus dados sem nenhum aviso. Nenhuma mensagem de erro. Só valores absurdos aparecendo do nada na tela, sem nenhuma pista da causa.

É como guardar documentos numa sala do prédio que parecia vazia e descobrir, meses depois, que a empresa vizinha expandiu e jogou tudo fora. Ninguém avisa. Você só descobre quando precisa do documento.

Esse tipo de erro silencioso me ensinou mais sobre rigor e cuidado do que qualquer erro barulhento. Hoje, quando meu celular trava ou um programa fecha sozinho, eu olho com outros olhos: sei o tipo de caos que o sistema está segurando ali dentro.

O computador não faz várias coisas ao mesmo tempo — ele finge muito bem

Essa foi a maior revelação do projeto. Sabe quando você ouve música, digita um texto e baixa um arquivo "ao mesmo tempo"? Na maioria dos casos, o processador está fazendo uma única coisa por vez — só que ele troca de tarefa milhares de vezes por segundo.

Eu tive que escrever essa mágica com as próprias mãos, e ela é mais simples (e mais bonita) do que eu imaginava.

A analogia que uso: imagine uma pessoa lendo cinco livros ao mesmo tempo, mas com uma regra — só pode ler um por vez. O truque? Um marca-páginas em cada livro. Ela lê algumas frases de um, marca a página, pula para o outro, lê mais um pouco, marca, e assim por diante. Se fizer isso rápido o suficiente, um observador de fora jura que ela está lendo os cinco simultaneamente.

O trecho de código que faz essa troca no meu sistema — guardar o marca-páginas de uma tarefa e abrir o livro da outra — tem 15 linhas. Quinze linhas sustentam a ilusão de simultaneidade que a gente usa todos os dias. Quando isso funcionou pela primeira vez, com duas tarefas se alternando na tela, foi um dos momentos mais emocionantes do projeto. Pensei no tópico do fórum na mesma hora: era isso que eu queria entender aos 15 anos, sem saber que queria.

E quem manda trocar de livro?

Outro aprendizado que muda a forma de ver o computador: o sistema operacional não fica "rodando" o tempo todo, como imaginei. Ele passa a maior parte do tempo dormindo, esperando ser cutucado.

Quem cutuca é o próprio hardware: o relógio interno da máquina dá um "toque" dezenas de vezes por segundo, o teclado avisa quando uma tecla é pressionada, o disco avisa quando terminou de ler. Esses toques se chamam interrupções — e o nome é literal: elas interrompem o que estiver acontecendo, no meio, sem pedir licença.

É como ser um síndico que só age quando o interfone toca. E o interfone pode tocar a qualquer momento, inclusive no meio de outra tarefa. Aprendi na prática que boa parte dos bugs mais difíceis da computação nasce exatamente aí: duas coisas mexendo no mesmo lugar porque o interfone tocou na hora errada. Tive que criar um mecanismo de "não perturbe" para os momentos delicados — o equivalente a tirar o interfone do gancho por alguns segundos.

Inventando meu próprio jeito de guardar arquivos

Chegou a hora do meu sistema ler arquivos do disco, e eu tinha duas opções: implementar um formato padrão da indústria (semanas de trabalho seguindo especificações enormes) ou inventar o meu próprio. Inventei o meu: o SyFS.

Um "sistema de arquivos" é basicamente o método de organização de uma biblioteca. O disco é uma estante gigante com milhares de espaços numerados. O sistema de arquivos é o caderninho do bibliotecário que diz: "o livro Receitas da Vovó começa na prateleira 66 e ocupa 3 espaços".

O meu caderninho é propositalmente simples: uma página de índice com espaço para 16 arquivos, cada um anotado com nome, posição e tamanho. Só isso. Não dá para criar pastas, não dá para editar arquivos — só ler.

E foi aí que veio uma das lições mais valiosas do projeto, que serve para qualquer área: simplicidade é uma decisão de projeto, não uma limitação. Meu sistema de arquivos não compete com o do Windows — mas eu entendo cada detalhe dele, e ele faz exatamente o que o projeto precisa. Na dúvida entre o completo e o compreensível, o compreensível ensina mais.

O adolescente do fórum jamais aceitaria isso, aliás. Ele queria o sistema completo, revolucionário, de uma vez. O adulto que finalmente construiu o sistema aprendeu que projetos que terminam são feitos de versões simples que funcionam.

O dia em que meu sistema disse "não" a um programa

O momento mais especial do projeto foi quando o brain-os rodou, pela primeira vez, um programa separado do sistema — como quando você abre um aplicativo no seu computador.

Para isso funcionar, precisei implementar a ideia mais importante de toda a segurança da computação: níveis de privilégio. O sistema operacional vive numa espécie de "sala da diretoria", com acesso a tudo. Os programas comuns ficam do lado de fora, sem chave de nada. Se um programa quer algo — mostrar um texto na tela, ler um arquivo — ele não pode fazer por conta própria: precisa pedir ao sistema, por um balcão de atendimento oficial.

Esse pedido tem nome técnico (chamada de sistema), mas a essência é essa: um formulário no balcão. O programa entrega o pedido, o sistema confere, executa e devolve a resposta.

Quando meu primeiro programa apareceu na tela dizendo "Olá! Sou o init" — texto que ele não tinha permissão de escrever sozinho, e que o sistema escreveu por ele após o pedido — eu finalmente senti como funciona a fronteira que protege seu computador todos os dias. É por causa desse balcão que um aplicativo mal-intencionado não sai fuçando seus arquivos livremente: tudo passa pelo síndico.

E, como quase tudo em osdev (o nome da comunidade de desenvolvimento de sistemas operacionais), descobri os detalhes desse mecanismo na ordem clássica: primeiro o sistema travando na minha cara, depois a compreensão do porquê.

A lição que serve para qualquer projeto: reduza o tempo entre tentar e ver o resultado

Nem todo aprendizado foi sobre o computador em si. O mais transferível deles foi sobre processo — e talvez seja a verdadeira resposta para a pergunta "por que aos 15 anos eu não fui adiante, e agora sim?".

Testar um sistema operacional é trabalhoso: compilar, gerar o "disco", ligar uma máquina de testes, olhar o resultado. Se cada tentativa custa meia dúzia de comandos e alguns minutos, você desanima na segunda semana — porque nesse tipo de projeto você erra o tempo todo.

Minha solução foi automatizar tudo: montei um ambiente de desenvolvimento com Docker e VNC em que, ao salvar qualquer alteração no código, o sistema é reconstruído e reiniciado sozinho dentro de um computador simulado, que aparece direto no meu navegador. Eu salvo o arquivo e, um segundo depois, vejo meu sistema operacional ligando de novo com a mudança aplicada.

Esse ciclo curto entre "tentei" e "vi o resultado" foi o que manteve o projeto vivo. E a lição vale para qualquer coisa: quanto mais rápido você enxerga o resultado de uma tentativa, mais tentativas você faz — e mais rápido aprende. Se for começar qualquer projeto difícil, invista primeiro em encurtar esse ciclo.

O que eu levaria para qualquer área

Olhando para trás — para o projeto e para os 15 anos entre o tópico e o código —, os aprendizados que ficaram não são sobre processadores:

• Toda mágica é mecanismo. O "ao mesmo tempo" do computador são 15 linhas trocando marca-páginas. Entender o truque não estraga a mágica — aumenta a admiração.
• Erros silenciosos são os piores. O erro que grita é fácil; o que corrompe em silêncio e só aparece semanas depois é o que ensina a trabalhar com cuidado.
• Comece pela versão simples. Meu sistema de arquivos de 16 arquivos me ensinou mais do que qualquer especificação profissional teria ensinado.
• Ideias plantadas em público criam raízes que você não controla. Um tópico de adolescente num fórum virou sistemas operacionais de outras pessoas, trabalhos acadêmicos, carreiras. Nenhum plano meu previu isso.

Conclusão: algumas ideias não desistem de você

Em 2019, o Lucky me perguntou se eu tinha desistido. A resposta honesta, na época, seria "sim". Mas ideias como essa têm um jeito estranho de hibernar: elas não morrem, ficam esperando você acumular exatamente o que faltava — experiência, ferramentas, maturidade para aceitar a versão simples.

O brain-os não é o sistema operacional web dos meus 15 anos. É melhor: é um sistema que existe. Ele liga, mostra uma tela, aceita comandos, lê arquivos e roda programas — e cada peça dele eu entendo por inteiro.

A tela de boot do brain-os. Cada [ OK ] dessa lista é uma das batalhas contadas neste artigo. Construir um sistema operacional do zero, mesmo pequeno e imperfeito, é um dos exercícios de aprendizado mais poderosos que existem: cada coisa que o seu computador faz deixa de ser mágica e vira mecanismo compreensível. Depois disso, você nunca mais olha igual para a tela de carregamento.

Se você tem uma ideia dessas hibernando — daquelas que pareciam maluquice quando você as contou em voz alta —, fica a lição do fórum: conte mesmo assim. Ela pode inspirar gente que você nunca conheceu. E pode voltar para te buscar quando você estiver pronto.

Quer ver esse sistema rodando? Leva 2 minutos

Você pode testar o brain-os agora, sem instalar nada além do Docker e sem risco nenhum para o seu computador — ele roda dentro de uma máquina simulada e aparece direto no seu navegador. São três passos:

git clone https://github.com/lucianobragaweb/brain-os
cd brain-os
docker compose up

Depois é só abrir http://localhost:6080/vnc.html no navegador e clicar em Connect. Pronto: você vai ver um sistema operacional escrito do zero ligando na sua frente — com direito a shell, comandos e arquivos.

👉 Visite o repositório: github.com/lucianobragaweb/brain-os — explore o código, deixe uma estrela se o projeto te ajudou a enxergar o computador de outro jeito e me conta: qual é a ideia adolescente que ainda está esperando por você?