Objetivo: Implementação de um sistema operacional microkernel de arquitetura distribuída
Fase 1 (6-12 meses):
Fase 2 (12-18 meses):
O projeto será opensource e terá um site para documentação
Protótipos já desenvolvidos utilizando a arquitetura proposta:
Este projeto é uma aplicação da nossa missão e tem, antes de tudo, um carácter educacional. Não temos muito material, especialmente em português, sobre esse assunto.
Criar um ambiente para explorar novas ideias, onde seja possível que um único indivíduo entenda o todo, e que, se assim desejar, faça mudanças para atender a sua necessidade.
Essa é a uma das primeiras perguntas que ouço quando falo do projeto.
A resposta é um tanto simples: redução de complexidade e potencialmente de desperdício de energia.
Sistemas operacionais modernos são projetos gigantes e atendem uma variedade enorme de casos de uso.
O objetivo não é fazer um "melhor Linux" ou "melhor Windows", é criar uma alternativa simples para resolver problemas simples.
Criar um sistema operacional que possibilita executarmos tarefas comuns do dia-a-dia, como por exemplo, ler emails, trocar mensagens, navegar na internet utilizando um hardware modesto não é impossível de ser implementado.
Não estou convencido que já esgotamos as possibilidades de design e implementação de software. Nossa área ainda é muito jovem para fazer tal afirmação. Com esse projeto, espero explorar ideias que já foram testadas no passado e quem sabe descobrir novas maneiras de criar software.
Nas próximas seções, detalho mais sobre as motivações e inspirações para esse projeto.
Provavelmente o que vou falar a seguir não seja uma grande novidade para quem trabalha dentro de TI, especialmente na área de desenvolvimento de software. O aumento da complexidade das ferramentas/metodologias na última década é um tanto assustador.
Para pessoas de fora da área (e talvez algumas de dentro) isso é normal, já que os problemas estão cada vez mais complexos, certo?
Não tenho tanta certeza disso. Deixe me formular um pouco melhor essa questão.
Fred Brooks, em seu famoso artigo No Silver Bullet - Essence and Accident in Software Engineering, define esse interessante conceito de complexidade essencial e acidental em desenvolvimento de software.
Em resumo:
Todo problema tem um certo nível de complexidade acidental. Ela se mostra nas ferramentas que utilizamos para a resolução do problema: linguagens de programação, frameworks, organização de tarefas, etc.
A complexidade acidental é inevitável. Ela deve ser mitigada para que o foco seja a complexidade essencial do problema em questão.
É difícil apontar o "culpado" pelo aumento dessa complexidade acidental, mas vou arriscar e listar alguns pontos:
1. Reuso de software
Aprendemos desde cedo que o reuso de software é algo bom e que deve ser uma das metas para que um projeto seja bem sucedido. Infelizmente não é tão simples assim. O reuso indiscrimidado faz com que criemos centenas de dependências e gerir essas dependências aumenta a complexidade acidental.
2. Agilidade ao invés de qualidade
Passamos a valorizar mais a agilidade ao invés da qualidade. Isso também contribui para ponto anterior.
3. Valorização do mercado de TI
Desenvolver software é uma tarefa difícil. Precisa-se de mão de obra especializada e ela é cada vez mais escassa. A dependência em software gerada pelo nosso momento atual acentua ainda mais esse ponto. Porém, há um fator oculto que considero relevante nessa equação. Usamos a complexidade acidental excessiva como justificativa (muitas vezes inconsciente) do alto valor nos serviços de TI. Isso faz com que ela se justifique e até seja de certa forma desejada para que essa valorização continue.
4. Monopólio
Grandes empresas de TI ditam a maiorias das regras e tendências de tecnologias utilizadas na área. Não há muito interesse por parte delas de mudar o status-quo, e com isso a complexidade acidental das nossas ferramentas continua aumentando.
Estamos sim resolvendo problemas mais complexos do que 10-20 anos atrás. Isso não quer dizer que estamos melhores em resolver problemas do que a 10-20 anos atrás. Meu sentimento é o contrário: a cada ano que passa estamos afundando mais nessa complexidade acidental e nossa capacidade de resolução de problemas está indo junto.
Hoje mais e mais pessoas/organizações estão preocupadas com:
Minha visão é que teremos nos próximos ~20 anos um movimento de descentralização bem acelerado, com soluções de TI sendo mais regionalizadas. O modelo atual de monopólio de grandes empresas de TI vai se diluir.
Para acompanhar essa tendência, devemos repensar as ferramentas e metodologias que utilizamos hoje para desenvolver e provêr soluções.
Como inspiração e modelo para a implementação desse projeto, utilizarei o que chamo de "Wirth Philosophy". Niklaus Wirth foi um dos pioneiros na aplicação de técnicas simples e poderosas para resolver problemas dentro da área de TI. Ele é mais conhecido pela criação da linguagem de programação Pascal, mas o seu trabalho mais admirável é a criação da linguagem de programação e sistema operacional de mesmo nome: Oberon.
Make it as simple as possible, but not simpler. (A. Einstein)
Como mencionado anteriormente, Oberon dá nome tanto a uma linguagem de programação quanto ao sistema operacional desenvolvido nela.
Oberon como linguagem de programação tem uma abordagem minimalista na sua construção. Usa poucas porém poderosas abstrações e sua sintaxe pode facilmente ser aprendida em algumas horas.
Dentro dessas abstrações, podemos destacar:
Para mais detalhes, aqui está a definição da linguagem.
Oberon como sistema operacional tem ideias um tanto originais. Usa um sistema de documentos que é pervasivo em todo sistema, fazendo com que qualquer documento possa ser um programa e ou invocar/utilizar outros programas.
Implementa multi-tarefa através de um mecanismo de agendamento/execução de tarefas e também através de troca de mensagens.
A implementação original consiste do compilador e do sistema operacional (escritos na própria linguagem) preservando uma base de código em torno de 10.000 linhas de código.
Erlang é uma linguagem de programação funcional, criada nos anos 80 pela Erikson. Ela acompanha uma máquina virtual (OTP) que é altamente tolerante a falhas e escalável. Usa uma arquitetura distribuída onde podemos criar vários nodos executando aplicações e montar clusters para escalar horizontalmente a resolução de problemas.
A ideia é que cada tarefa possa ser executada em um processo separado e que esses processos troquem mensagens entre si. Esses processos são chamados de atores.
O modelo de atores é um modelo computacional que usa essa entidade chamada ator como bloco principal.
Os atores, em resposta a uma mensagem recebida, podem:
Outra caraterística interessante é que atores de diferentes nodos podem trocar mensagens transparentemente, como se estivesse sendo executados no mesmo nodo.