A briga entre o
criador do Minix e czar dos sistemas Operacionais Andrew S. Tanenbaum e Linus
Torvalds é lendária no mundo dos sistemas operacionais. Antes do Linux havia o
Minix. Torvalds criou sua primeira versão do Linux em 1991 sobre o sistema do
professor Tanenbaum. Agora, o sr. Tanenbaum concordou em escrever um editorial
para a Linux Magazine. Sua opinião não mudou ao longo dos anos: o Linux (e o
Windows) “não são confiáveis”.
Por Andrew S. Tanenbaum
Os usuários de computadores estão mudando. Há dez
anos, a maioria dos usuários de computadores eram pessoas ou profissionais
jovens com amplo conhecimento técnico. Quando algo saía errado – o que ocorria
com freqüência –, eles sabiam consertá-las. A maioria deles consegue consertar
computadores tão bem quanto um nerd de computador padrão sabe consertar seu
carro. O que eles querem mais do que qualquer outra coisa é que o computador
funcione o tempo todo, sem interrupções ou falhas.
Muitos usuários comparam automaticamente seus computadores a
suas televisões. Ambos estão repletos de componentes eletrônicos mágicos e
possuem telas grandes. A maioria dos usuários tem um modelo implícito de uma televisão:
(1) você compra a TV; (2) você a liga na tomada; (3) ela funciona perfeitamente
sem qualquer falha durante os próximos dez anos. Eles esperam isso do
computador e, quando não é o que obtêm, ficam frustrados. Quando os
especialistas em computadores lhes dizem: “Se Deus quisesse que os computadores
funcionassem o tempo todo, Ele não teria inventado o botão de RESET”, eles não
se convencem.
Por falta de uma melhor definição de disponibilidade,
adotemos a seguinte: um dispositivo é dito disponível (isto é, podemos dispor
dele) se 99% dos usuários jamais experimenta qualquer falha durante todo o
período em que o possuem. Por essa definição, virtualmente nenhum computador é
disponível, enquanto a maioria das TVs, iPods, câmeras digitais etc. são. Usuários
técnicos de computador estão dispostos a perdoar um computador que trave uma ou
duas vezes por ano; usuários comuns, não.
Usuários domésticos não são os únicos incomodados com a baixa
disponibilidade dos computadores. Até mesmo em ambientes altamente técnicos, a
baixa disponibilidade dos computadores é um problema. Empresas como Google e
Amazon, com centenas de milhares de servidores, experimentam várias falhas todo
dia. Elas aprenderam a conviver com isso, mas prefeririam sistemas que
simplesmente funcionassem sem parar. Infelizmente, os softwares atuais falham
nesse aspecto.
O problema básico é que softwares contêm bugs, e quanto mais
software, mais bugs. Vários estudos já mostraram que o número de bugs por mil
linhas de código (KLoC) varia de um a dez em grandes sistemas de produção. Um
software muito bem escrito talvez tenha dois bugs por KLoC ao longo do tempo,
mas não menos. Um sistema operacional com, digamos, 4 milhões de linhas de
código, portanto, deve ter pelo menos 8 mil bugs. Nem todos são fatais, mas
alguns serão. Um estudo da Universidade Stanford mostrou que drivers de
dispositivos – que compõem até 70% da base de código de um sistema operacional
típico – possuem taxas de bugs 3x a 7x mais altas que o resto do sistema.
Drivers de dispositivos têm taxas mais altas porque (1) são mais complicados e
(2) são menos inspecionados. Enquanto muitas pessoas estudam o escalonador,
poucas verificam os drivers de impressoras.
A solução: kernels menores
A solução para esse problema é retirar código do kernel, no
qual o dano pode ser máximo, e colocá-lo em processos do espaço do usuário,
onde bugs não conseguem causar falhas de sistema. É assim que o MINIX 3 é
projetado. O sistema MINIX atual é o (segundo) sucessor do MINIX original, que
foi lançado originalmente em 1987 como sistema operacional educativo, mas desde
então foi radicalmente revisado para se tornar um sistema altamente disponível
e auto-recuperável. Segue uma breve descrição da arquitetura do MINIX; há mais
informações em www.minix3.org.
O MINIX 3 é projetado para rodar o mínimo de código possível
no modo do kernel, em que bugs podem facilmente ser fatais. Em vez de 3-4
milhões de linhas de código no kernel, o MINIX 3 tem aproximadamente 5.000
linhas de código no kernel. Às vezes, kernels desse tamanho são chamados de
microkernels. Eles lidam com gerenciamento de processos no baixo nível,
escalonamento, interrupções e o relógio, e fornecem alguns serviços de baixo
nível para componentes do espaço do usuário.
A maior parte do sistema operacional roda como uma coleção de
drivers de dispositivos e servidores, cada um rodando como processo comum do
espaço do usuário com privilégios restritos. Nenhum desses drives e servidores
roda como superusuário ou equivalente. Eles não conseguem nem acessar
dispositivos de I/O ou o hardware MMU diretamente; precisam usar serviços do
kernel para ler e escrever no hardware. A camada de processos rodando
diretamente no modo de usuário acima do kernel consiste em drivers de
dispositivos, com o driver de disco, o de Ethernet e todos os outros rodando
como processos separados protegidos pelo hardware MMU, para não conseguirem
executar qualquer instrução privilegiada e nem lerem ou escreverem em locais de
memória além dos seus próprios.
Acima da camada de drivers vem a de servidores, com um
servidor de arquivos, um servidor de processos e outros. Os servidores fazem
uso dos drivers assim como de serviço do kernel. Por exemplo, para ler um
arquivo, um processo do usuário envia uma mensagem ao servidor de arquivos, que
então envia uma mensagem para o driver de disco para buscar os blocos
necessários. Quando o sistema de arquivos os tem em seu cache, ele chama o
kernel para movê-los para o espaço de endereços do usuário.
Além desses servidores, há um outro servidor chamado
“servidor de reencarnação”. Ele é o pai de todos os processos de drivers e
servidores e monitora seu comportamento. Se ele descobrir um processo que não
esteja respondendo a pings, ele inicia uma nova cópia a partir do disco (exceto
pelo driver do disco, que fica oculto na RAM). O sistema foi projetado para que
muitos (mas não todos) os drivers e servidores críticos sejam automaticamente
substituídos enquanto o sistema funciona, sem perturbar os processos de usuário
em execução e sem nem notificar o usuário. Dessa forma, o sistema é auto
recuperável.
Para testar se essas idéias funcionam na prática, conduzimos
os seguintes experimentos. Iniciamos um processo de injeção de falhas que
sobrescreveu 100 instruções de máquina no binário do driver Ethernet em
execução para ver o que ocorreria caso um deles fosse executado. Se nada
acontecesse em poucos segundos, outras 100 eram injetadas e assim por diante.
No total, injetamos 800.000 falhas em cada um dos três diferentes drivers
Ethernet e causamos 18.000 travamentos do driver. Em todos os casos, o driver
foi automaticamente substituído pelo servidor de reincarnação. Apesar de
injetar 2,4 milhões de falhas no sistema, o servidor não parou uma vez sequer.
Nem é preciso dizer que se ocorrer um erro fatal num driver do Windows ou do
Linux rodando no kernel, todo o sistema operacional travará imediatamente.
Existe alguma desvantagem nessa técnica? Sim. Há uma redução
de desempenho. Não a medimos extensivamente, mas o grupo de pesquisa em
Karlsruhe, Alemanha, que desenvolveu seu próprio microkernel (o L4) e depois rodou o Linux como um de
seus processos de usuário, conseguiu uma perda de desempenho de apenas 5%.
Acreditamos que se dedicarmos um pouco de atenção a esse típico, também
conseguiremos reduzir a perda para a faixa entre 5 e 10%. Desempenho não é uma
prioridade para nós, já que a maioria dos usuários que lêem email ou navegam
pelo Facebook não são limitados pelo desempenho da CPU. O que eles querem, no
entanto, é um sistema que simplesmente funcione o tempo todo.
Se microkernels são tão disponíveis, por que ninguém os usa?
Na verdade, usam, sim. Provavelmente você roda vários deles.
Seu telefone celular, por exemplo, é um computador pequeno, mas comum em todos
os outros aspectos, e há uma boa chance de ele rodar o L4 ou o Symbian, outro
microkernel. O roteador de alta performance da Cisco também usa um microkernel.
Nos mercados militar e aeroespacial, em que disponibilidade é fundamental, o
Green Hills Integrity, outro microkernel, é amplamente usado. O PikeOS e o QNX
também são microkernels amplamente usados em sistemas industriais e embarcados.
Em outras palavras, quando é realmente importante que o sistema “simplesmente
funcione o tempo todo”, as pessoas usam microkernels. Para mais informações
sobre esse tópico, veja www.cs.vu.nl/~ast/reliable-os/.
Concluindo, é nossa crença, baseada em várias conversas com
usuários não técnicos, que o que eles mais desejam é um sistema que funcione
perfeitamente todo o tempo. Eles têm uma baixa tolerância a sistemas pouco
confiáveis, mas atualmente não têm escolha. Acreditamos que sistemas baseados
em microkernels podem nos levar a sistemas mais disponíveis.
O Debate entre Linus Torvalds e Andy Tanembaum
Outro lado da moeda, é ver o debate entre Linus Torvalds e Andy Tanembaum.
https://pt.wikipedia.org/wiki/Debate_entre_Tanenbaum_e_Torvalds
Créditos:
http://www.linuxmagazine.com.br/lm/materia/tanenbaum_por_que_os_computadores_nao_funcionam_sem_parar
https://pt.wikipedia.org/wiki/Debate_entre_Tanenbaum_e_Torvalds
Outro lado da moeda, é ver o debate entre Linus Torvalds e Andy Tanembaum.
https://pt.wikipedia.org/wiki/Debate_entre_Tanenbaum_e_Torvalds
Créditos:
http://www.linuxmagazine.com.br/lm/materia/tanenbaum_por_que_os_computadores_nao_funcionam_sem_parar
https://pt.wikipedia.org/wiki/Debate_entre_Tanenbaum_e_Torvalds
Mais uma vez, após um ano de trabalho, a equipe responsável pelo Citsmart obteve sucesso e alcançou um número expressivo de certificações junto à certificadora ITIL, Pink Elephant.
