Você já se perguntou por que você se sente cada vez menos confortável utilizando (e comprando!) softwares básicos, como sistemas operacionais, e cada vez mais disposto a gastar boas quantias em inovações tecnológicas? Por qual motivo as pessoas em geral recusam-se a pagar quantias razoáveis por esses softwares, ao passo em que colecionam sempre as últimas novidades em celulares, notebooks, smartphones e afins?

Neste artigo, expandiremos essa questão sob a ótica dos softwares básicos. Apresentaremos um argumento o qual vem ganhando força no meio acadêmico. Aproveitaremos a “deixa” para apresentar a proposta dos criadores do sistema operacional MINIX para “resolver” o paradoxo mediante um fator primordial: confiabilidade.

A Indústria de Softwares Básicos na Contramão do Avanço Tecnológico

A pesquisa teórica em ciências exatas é historicamente reconhecida por seguir metodologias bem definidas e por possuir alto rigor quanto a apresentação de teoremas e suas respectivas provas. Semelhantemente, as ciências experimentais gozam de métodos e procedimentos estatísticos bem estabelecidos para que os resultados obtidos possam ser reproduzidos e validados.

Porém, o que pode ocorrer se uma disciplina complexa – como a programação de computadores – crescer sem limites, restrições ou rigor? A resposta a essa indagação pode estar na observação do desenvolvimento frenético e incoseqüente de programas básicos chamados Sistemas Operacionais (SO‘s). Desde a década de 70, um grande paradoxo está se estabelecendo com a implementação independente de diferentes sistemas. A princípio, a necessidade de prover multiprogramação em ambientes computacionais era maior que a quase inexistente teoria (ver nota 1 ao final do artigo) sobre como desenvover tais sistemas à época. Assim, muitos desses softwares foram utilizados corporativamente sem qualquer senso de padronização e sem nenhuma metodologia de engenharia de software.

Como conseqüência, hoje, em pleno auge da industria tecnológica mundial no qual os componentes eletrônicos produzidos são cada vez mais confiáveis, duráveis e tolerantes a falhas, os sitemas que gerenciam os milhões de computadores presentes em toda a sociedade – desde as grande corporações às mesas de escritório de usuários domésticos – seguem na contramão dessa positiva tendência. Os usuários de computadores nunca estiveram tão desconfiados e insatisfeitos com a qualidade dos sistemas que gerenciam as suas máquinas. Enquanto vírus, trojans e worms assombram o mundo dos computadores conectados em rede, a indústria de software só agora começa a perceber que os erros de projeto acumulados ao longo dos anos no processo de desenvolvimento dos SO‘s podem ser as causas de toda essa confusão e insegurança.

Será que a indústria de software não se dedica o suficiente para prover a qualidade necessária ao consumidor final? Talvez não seja esse o caso. Obviamente, em uma indústria na qual boa parte dos poucos bilionários existentes no planeta dá as suas cartas, os melhores profissionais e engenheiros são recrutados para desenvolver tais sistemas. Mas como explicar o fato de que todo esse caro investimento não é suficiente para que eu, você e os demais usuários de computadores nos sintamos confortáveis para comprar os últimos produtos “de olhos fechados”?

De fato, em ciência da computação, os SO‘s estão entre os objetos de estudo mais complexos e com muitos problemas em aberto ou não satisfatoriamente resolvidos, em especial nas áreas de segurança, gerenciamento de recursos (memória e tempo de processamento) e comunicação interprocesso. Hoje, descobrem-se falhas e brechas em SO‘s à mesma velocidade na qual a Petrobrás “descobre” campos de petróleo ao ver as suas ações desvalorizando.

Felizmente, a engenharia de software é uma disciplina que faz parte de uma ciência madura e desenvolvida, contando com milhares de cientistas competentes capazes de propor soluções para um problema que afeta a todos: a falta de confiabilidade dos sistemas operacionais. Nesse sentido, um grupo de pesquisa na área de sistemas computacionais distribuídos e paralelos da Universidade de Vrije, Holanda, vem trabalhando para tentar curar uma indústria que nunca seguiu os princípios rigorosos das ciências exatas em suas frentes de trabalho. Neste grupo, liderado pelo lendário cientista da computação Andrew S. Tanenbaum (ver nota 2 ao final do artigo), um antigo SO criado no fim da década de 80 como um despretensioso instrumento de ensino vem servindo de laboratório para a experimentação de idéias que, se postas em prática no mercado, podem prover o salto de qualidade necessário para essa vital área tecnológica. É evidente que não se pode esperar que essas mudanças ocorram em curto prazo devido ao fato desse mercado ser praticamente um monopólio imposto pela gigante da indústria, a Microsoft Corporation. Qual a vantagem de migrar todos os sistemas de usuário, dados e aplicativos para os moldes de uma nova arquitetura de SO?

“Nenhuma.”, diria a gigante.

“Confiabilidade, interoperabilidade, segurança. Mas não valeria a pena.”, diria Tanenbaum.

O Sistema MINIX

De fato, a adoção de uma nova arquitetura seria um grande esforço, praticamente impossível de realizar. É por isso, que o sistema MINIX desenvolvido em Vrije é baseado em uma arquitetura bastante conhecida e utilizada em milhares de corporações em todo mundo: a do sistema UNIX. E não é só isso: as recentes versões do MINIX implementam os padrões e as funcionalidades necessárias para prover a interoperabilidade necessária aos usuários de sistemas da família UNIX, Linux e derivados.

O MINIX (acrônimo para MINIMAL UNIX) é um SO baseado em UNIX escrito pelo professor Tanenbaum com o propósito de servir como suporte acadêmico para o estudo dos detalhes internos do sistema UNIX. Desde 1987, o professor Tanenbaum tem trabalhado continuamente no projeto do MINIX, tendo orientado dezenas de alunos de mestrado e doutorado engajados na contínua melhoria do sistema. Como resultado, o MINIX encontra-se em sua terceira versão a qual possui as qualidades necessárias para ser considerado um SO moderno, confiável, seguro e adequado para ambientes de produtividade, sendo ainda suficientemente leve, enxuto e de inteligível.

Os dois primeiros grandes releases, a versão 1.0 em 1987 e a versão 2.0 dez anos depois, foram concebidos, como dito anteriormente, puramente para fins educacionais. Entretanto, a terceira versão, lançada em 2006, busca alcançar um status de um sistema operacional moderno, confiável e robusto com a inclusão de diversas novas ferramentas tais como o sistema de janelas X e muitas outras aplicações UNIX (emacs, gcc, telnet, ftp, dentre outras). Na Figura 1 encontra-se uma breve cronologia com os principais releases do sistema MINIX e suas principais características e melhorias.

Figura 1. Principais marcos na evolução do sistema MINIX.

O MINIX não utiliza layouts de memória avançados, como os utilizados nos SO‘s atuais, sendo, portanto, mais adequado para aplicações que consomem pouca memória, como por exemplo, sistemas embarcados (ver nota 3 ao final do artigo). Mas a grande elegância do MINIX consiste no fato de que o mesmo é um SO nascido e evoluído no meio acadêmico, seguindo a risca as metodologias científicas desenvolvidas em diversas dissertações e teses. Esse fato certamente é o que o torna tão díspare em relação aos outros SO‘s.

Confiabilidade na Visão do MINIX 3

A confiabilidade, reivindicada como principal característica da versão 3, baseia-se na observação de que muitos dos problemas em SO‘s estão relacionados com falhas em softwares conhecidos como drivers, os quais gerenciam o hardware e são geralmente escritos por terceiros. Assim, mecanismos classificados como “self-healing” (ver nota 4 ao final do artigo) foram implementados para prover a recuperação rápida e confiável de falhas desses dispositivos. Sobre a confiabilidade do sistema MINIX, Tanenbaum afirma:

Muitos desses problemas [aqueles decorridos da falta de confiabilidade] são causados por uma falha fundamental de projeto nos sistemas operacionais atuais: a falta de modularidade. O sistema inteiro consiste tipicamente de milhões de linhas de código C/C++ compiladas em um único e massivo programa executável rodando em modo kernel (ver nota 5 ao final do artigo). Um bug em quaisquer um desses milhões de comandos pode causar o mal funcionamento do sistema. Ter todo o código correto é impossível, especialmente quando cerca de 70% dele consiste de drivers de dispositivos, escritos por terceiras partes e fora do controle das pessoas que mantém o sistema operacional.

Com o MINIX 3. nós demonstramos que esse projeto monolítico não é a única possibilidade. O kernel do MINIX 3 consiste em apenas 4000 linhas de código executável, diferente das milhões de linhas encontradas no Windows, Linux, Mac OS X ou FreeBSD. O resto do sistema, incluindo todos os drivers de dispositivos (com exceção do clock driver), é uma coleção de processos pequenos e modulares, cada qual focado em suas próprias funcionalidades e em com quais outros processos ele pode se comunicar.

Andrew S. Tanenbaum

(tradução nossa)

De modo a conseguir esse objetivo, Tanenbaum argumenta que o código rodando o kernel deve ser mínimo, com o servidor de arquivos, o servidor de processos e cada driver de dispositivo rodando como processos separados em modo usuário (ver nota 5 ao final do artigo). Cada driver é cuidadosamente monitorado por uma parte do sistema chamado de “reincarnation server“. Se um driver falha em responder a pings do reincarnation server, ele é descarregado e substituído por uma cópia estável do driver.

O kernel do MINIX 3 foi completamente reescrito para adequar-se a essa nova visão de confiabilidade concebida pelos projetistas do sistema. As semelhanças entre o MINIX 2 e o MINIX 3, segundo os mantenedores do sistema, são, basicamente, o nome de batismo. A grande maioria dos argumentos apresentados que envolvem o fator “confiabilidade” se baseiam na comparação do MINIX com sistemas monolíticos. Uma comparação geral entre sistemas monolíticos e sistemas microkernel pode ser visualizada na figura 2. Os defensores de sistemas monolíticos apontam características tais como performance como possíveis vantagens.

Figura 2. (a) Arquitetura de um sistema microkernel e (b) Arquitetura de um sistema monolítico. Adaptação de Roch (2004).

O MINIX é freqüentemente apontado como um sistema microkernel, devido ao fato de rodar um conjunto reduzido de funcionalidades (essencialmente, gerência de memória e de processos) em modo kernel. Esse fato reduz enormemente a possibilidade de falhas fatais ao sistema, pois, além de obter-se maior controle sobre o código do kernel, o sistema pode recuperar-se facilmente das falhas ocorridas em processos rodando no modo usuário.

Quanto à questão de desempenho, existem evidências suficientes para concluir-se a favor da superioridade dos sistemas monolíticos. Entretanto, diversos estudos existentes apontam para uma equivalência de desempenho entre ambos os sistemas (no caso, comparou-se o desempenho do MINIX com o Linux), sob certas condições especiais, raramente encontradas na prática.

Para maiores detalhes acerca da confiabilidade na visão do MINIX 3, baixe aqui a tradução em protuguês dos argumentos apresentados no site oficial.

Confiabilidade na Visão do Artigo

Independentemente dessa controvérsia (ver nota 6 ao final do artigo), é imprescindível que a indústria de softwares básicos encontre um ponto de equilíbrio no tripé performance-segurança- confiabilidade (Figura 3). Na Figura 3, “confiabilidade” e “segurança” são atributos complementares. Deve-se entender “segurança” como o conjunto de ações tomadas pelo SO para impedir que o sistema sofra modificações ou realize ações não autorizadas e/ou não previstas, antecipando-se as possíveis explorações de falhas. Já por “confiabilidade”, conforme exposto no artigo, entende-se como a habilidade do SO em operar sem (e recuperar-se de) falhas. Note-se, portanto, que, nessa visão, a falta de segurança é apenas um dos aspectos decorrentes da ausência de confiabilidade. Em geral, o aumento de confiabilidade reduz as preocupações com segurança e vice-versa.

Figura 3. Os atributos performance, segurança e confiabilidade são ortogonais.

Seguindo o nosso raciocínio, pode-se ver claramente que “confiabilidade” é um atributo geralmente concebido na fase de projeto de um SO, ou seja, é a habilidade de eliminar a possibilidade de ocorrência de certas falhas, bem como saber contornar as falhas inevitáveis através de um projeto cuidadoso e modular. Já “segurança” é um atributo importante para impedir que as falhas existentes sejam exploradas.

É claramente desejável aumentar a confiabilidade na fase de projeto, para não se ter maiores dores de cabeça no futuro solucionando brechas de segurança. Certamente, privilegiar um dos dois atributos é uma questão estratégica. Projetar um SO sem um projeto cuidadoso implica em um grande custo para implementar segurança posteriormente. Por outro lado, se o foco é mesmo forçar os usuários a atualizarem constantemente os seus SO‘s com patches de segurança liberados de 15 em 15 dias, pode-se relaxar bastante na fase de projeto.

Para a indústria de softwares básicos e de segurança (antivírus, firewalls, antispywares, etc.), talvez seja um bom negócio fazer com que os usuários se sintam vulneráveis e dependentes da ilusão de segurança construída por esses fabricantes. Talvez um bom projeto o qual minimize o número de falhas ANTES do produto ir para as prateleiras não seja tão rentável. Qualquer semelhança com o que ocorre com os sistemas comerciais atualmente em uso é mera coincidência.

Conclusões

Esse artigo apresentou uma visão pessoal do autor. Estamos em constante mudança. A medida que vivenciamos o mundo e colecionamos novas experiências, é natural que nossos “pontos de vista” sejam transladados. Esse é genuinamente o meu pensamento à data de hoje. Aos leitores: elaborem suas próprias conclusões, mas não as tenham como definitivas.

Considerações Finais

Aqui em casa há uma televisão (acho que de 29 polegadas) da outrora dominante SHARP comprada há quinze anos. Esse aparelho nunca deu entrada na assistência técnica e até hoje conserva uma qualidade de imagem e de som perfeitas. Será que é tão difícil para a indústria de software básicos conseguir colocar à venda um produto que dure os mesmos 15 anos daquela TV sem apresentar defeitos e mantendo os usuários satisfeitos por tanto tempo? Talvez o tempo nos surpreenda e nos mostre que as invisíveis correntes elétricas que geram altas tensões, os delicados circuitos eletrônicos, os enigmáticos átomos de fósforo, os complexos decodificadores de sinais analógicos e os inquietantes feixes de elétrons que permeiam todos esses componentes encontrados na já obsoleta tecnologia de raios catódicos sejam bem mais fáceis de projetar, padronizar e gerenciar do que as milhões de linhas de código que compõem uma orquestra por vezes desafinada, chamada de sistema operacional.

Para quem se interessar em conhecer como um SO é implementado (incluindo o código fonte completo e comentado em C), o livro do Tanenbaum contido nas referências abaixo é indispensável. Para quem está envolvido direta ou indiretamente com a área de tecnologia, o livro também é altamente recomendado.

Para os interessados em se arriscarem na implementação de um SO, iremos construir em breve um mini-simulador de um gerenciador de tarefas em C++ (para fins didáticos), utilizando a implementação de threads contida na biblioteca boost e um algoritmo de gerência de processos bastante utilizado nos sistemas em uso.

Para quem se interessar em acompanhar os artigos sobre C++, recomendo fortemente começar por esse primeiro artigo: Dominando C++.

Um abraço a todos, boas reflexões e estudos!

Referências

1. HERDER, J., BOS, H., GRAS, B., HOMBURG, P., TANENBAUM, A. S. modular system programming in MINIX 3. In: USENIX ;login, April 2006, pp. 19-28
2. ROCH, B. Monolithic Kernel vs. Microkernel. In: Ausgewählte Kapitel der Technischen Informatik (AK-TI), SS04, Alemanha, 2004. Disponível em http://www.vmars.tuwien.ac.at/courses/akti12/journal/04ss/article_04ss_Roch.pdf
3. TANENBAUM, A. S, WOODHULL, A. S. The MINIX 3 Operating System. Disponível em http://www.minix3.org/.
4. TANENBAUM , A. S., WOODHULL, A. S. Sistemas operacionais: projeto e implementação. 2ª Ed., Bookman, Porto Alegre, 2000

Notas

1 Os primeiros SO‘s utilizavam o paradigma de processamento em lote (batch) no qual não havia alternância entre programas em execução (tarefas). Com o advento dos sistemas multitarefa, reduziu-se o tempo ocioso do processador ao retirar-se de execução uma tarefa que requisitou uma operação custosa de entrada ou saída de dados, aproveitando-se o tempo até então ocioso para processar outra tarefa. No entanto, essa prática introduziu muita complexidade no que diz respeito ao gerenciamento dessas tarefas.

2 O professor Tanembaum é uma figura bastante conhecida no meio acadêmico, tendo escrito diversos livros clássicos sobre redes de computadores, SO‘s e sistemas distribuídos. Um de seus livro sobre o sistema MINIX inspirou o desenvolvimento do Linux. (veja http://en.wikipedia.org/wiki/Andrew_S._Tanenbaum para maiores detalhes).

3 Veja http://pt.wikipedia.org/wiki/Software_embarcado para maiores detalhes.

4 O termo “self-healing” significa algo como “aquele que é responsável pela sua própria recuperação”.

5 O termo “kernel” significa “núcleo”. O kernel é o coração de um SO, onde se encontram os componentes necessários ao seu funcionamento. O modo kernel é um modo de execução privilegiado em um SO, com acesso irrestrito a muitas instruções que se comunicam diretamente com o hardware da máquina gerenciada. Já no “modo usuário”, os processos possuem restrições quanto ao uso de certas instruções, devendo, em geral, requisitar certas tarefas para o kernel do SO através de chamadas de sistema, o que aumenta o controle sobre os processos de usuário. Para maiores detalhes, acessar http://pt.wikipedia.org/wiki/Kernel.

6 Uma calorosa discussão entre o professor Tanenbaum e o aluno prodígio filandês Linus Torvalds acerca dea questões técnicas envolvendo os SO‘s MINIX e Linux pode ser encontrada em http://www.oreilly.com/catalog/opensources/book/appa.html