Tanenbaum: Por que os computadores não funcionam sem parar?
“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”.
Ganha um micropanetone quem adivinhar o sistema operacional baseado em microkernel que o professor recomenda como estável, confiável e disponível! :)”
Enviado por Pablo Hess (phessΘlinuxmagazine·com·br) – referência (linuxmagazine.uol.com.br).
• Publicado por Augusto Campos em
2008-12-12
@brlinuxblog
Feed RSS
Minix? Ganhei o panetone? :D
Mas o que ele diz parece ser real: quanto menos código e tarefas delegadas á um kernel, menor a chance do computador parar.
A idéia de um microkernel é justamente essa, ele ser somente uma base para a interoperabilidade dos serviços que rodam em cima dele; se algum deles der um crash, o kernel não vai junto.
Note que serviços nesse sentido são sistemas de arquivo, drivers de dispositivos, talvez até o scheduler. Muito do que se pensa que vai num kernel normal, não vai num microkernel.
A idéia é ótima, só não conseguiram fazer um kernel desses com a performance e features de um maior.
O mundo acadêmico é muito diferente do mundo real.
Nem tudo que se diz na teoria é possível na prática!
Esse Minix é um fanfarrão.
Hurd ?
ganhei ? :P
No mais prefiro ficar com o linux mesmo…
Em tempo, spunkiie, no dia que o hurd ficar pronto e usável os computadores nem utilizarão o kernel como conhecemos…
Se microkernel fosse tão bom assim, o MacOS nunca travaria!
Bla bla bla bla micro-kernel bla bla bla bla monolítico bla bla bla bla.
Bla bla bla bla bla orientação a objeto bla bla bla bla bla programação procedural bla bla bla bla.
Linux está em super-computadores, celulares, desktops, servidores, roteadores, access points, notebooks, consoles de video game, video games portáteis, hand-helds, e certamente outras coisas que esqueci.
Puxa, nada confiável, né?
Tanenbaum é troll.
“O mundo acadêmico é muito diferente do mundo real.”
Isso não tem nada a ver com mundo acadêmico ou mundo real (mesmo porque, são o mesmo), isto tem a ver com o fato de se desconsiderar a complexidade de implementação de um kernel assim e a velocidade que ele vai atingir. Ingenuidade achar que o mundo acadêmico desconhece tais problemas, ou que ele os ignora.
E não se sabe se é impossível na prática: sabe-se só que não conhecemos. A ciência funciona assim, com a visão dos cientisticas. Se assim não fosse, não utilizariamos computadores ou internet, afinal, no começo, o “mundo acadêmico” também “não condizia” com o “mundo real”.
Concordo plenamente com o Miguel.
A ciência funciona assim, com a visão dos cientisticas
Por isso que as academias estão tão longe do mundo real, quantos acadêmicos trabalham em empresas e testam suas idéias absurdas.
Conheço inúmeros gênios que foram negados de fazer um Mestrado porque trabalhavam, como se uma empresa não pudesse ensinar nada aos cientistas. Ou seja, ou o nerd vive no mundo da teoria ou no da prática, é impossível viver nos dois ao mesmo tempo.
Por isso que as academias estão tão longe do mundo real, quantos acadêmicos trabalham em empresas e testam suas idéias absurdas. Era uma pergunta, faltou a pontuação “?”
Eu sei que meu Mac OS X roda sob um microkernel Mach… E vocês, seus bregas de Linux?
O Tanembaum tem lá seus méritos, e eu concordo com boa parte do que ele fala, mas ele faz algumas afirmações sem nenhum embasamento científico. Vamos ao caso da frase: “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.”. Para invalidar esta afirmação, basta dizer que o SO mais utilizado no mundo se chama Windows.
Quanto aos acadêmicos, procure no Google por Google e vc verá se existem acadêmicos que também trabalham no “mundo real”.
A maioria dos “acadêmicos” acaba seguindo o mesmo sentido: seguem bem na academia até seguirem confiantes suficientemente para implementar suas idéias surreais.
Tá aí o QNX pra dizer que microkernel pode sim ser rápido.
Eu prefiro meu S.O. todo dia eu acordo e reescrevo ele do zero, e fica o dia todo sem travar, a noite eu apago e no outro dia reescrevo ele bem melhor.
“mas ele faz algumas afirmações sem nenhum embasamento científico.”
Hahahahaha, isso ai foi massa. Um usuario normal(não lhe desmerecendo =D)falando que o cientista não tem base cientifica. Voce pensou no que ele falou ou leu?
Ninguem le nada antes de comentar…
//*Penso, logo comento. *//
Sinceramente, num mundo ideal ele estaria completamente certo. Seriam computadores bem mais confiáveis, e simplesmente funcionariam.
Agora, na prática, como trocar toda a tecnologia já desenvolvidos em cima de kernels monolíticos? Seriam incalculáveis os gastos com dinheiro e tempo. Mais fácil apertar o reset.
Tanenbaum não está errado, queremos sim confiabilidade acima de tudo…
Mas, posso atestar com conhecimento de causa, que a confiabilidade, como ele atesta, só se consegue realmente tendo controle sobre todo o produto.
Celulares, televisores e outros funcionam bem porque são sistemas que iniciam e acabam no integrador.
O Mac OS X, por exemplo, funciona bem porque roda em hardware certificado pela Apple. Coloca o Mac OS X pra rodar em qualquer hardware capenga por aí que ele começa a travar tanto quanto qualquer outro.
O querido Tanen ;) se esquece que na verdade está delegando ao software todos os problemas que ocorrem com computadores, quando muitas vezes o hardware é que gera os problemas. E isso não tem como evitar sendo comercialmente competitivo.
Meu Macbook tem uptime de meses sem que eu reinicie o mesmo – com Mac OS X ou com Linux. Já tive outras máquinas rodando Linux que tinham também um uptime grande, desktop com quase 6 meses sem reiniciar.
Mesmo fazendo com que o kernel “nunca” trave, se ele for lidar com usuário final, tem que explicar que às vezes o ambiente de janela trava e um ctrl+alt+backspace fecha apenas o ambiente de janelas, resolvendo o problema do travamento. Mas aí voltando a visão do usuário final: De que adiantou o kernel não travar? O cara perdeu todas as janelas com documentos não salvos e não é isso que se quer oferecer.
O kernel per sí não resolve problema nenhum pra usuário final e tem que oferecer o melhor desempenho possível, porque ninguém quer comprar uma ferrari pra andar na velocidade de uma carroça.
Olá suxsys,
Talvez eu tenha me expressado mal.
O que quis dizer é que em momento algum ele citou algum estudo que comprove o que ele disse. A isso eu chamo de afirmação sem embasamento científico.
Eu concordo muito que, arquiteturalmente falando, sistemas ukernel são mais seguros. E como leitor assíduo do Prof. Tanembaum, gostaria muito de ver citações como essa. Vou te dar um exemplo: no artigo “Can we make operating systems reliable and secure” de maio de 2006, ele afirma na sessão de paravirtualização que foram feitas medidas e que o overhead encontrado era de 3% a 8%, mas ele não cita o estudo que concluiu isso.
Abraços!
Mundo “Real” vs Acadêmico?
Acho que tem muita gente confundindo mundo “Real” com mundo Comercial.
O mundo Real não é o empresarial.
Não confundam mais Real com Comercial.
Ao contrário da doutrinação feita pelas empresas, o Mundo Real vai muito além, é muito mais amplo que apenas comércio.
O sistema XPTO não é melhor ou pior de acordo com sua aceitação no mercado.
Então parem de usar “mercado” como se fosse um argumento válido.
“Por isso que as academias estão tão longe do mundo real, quantos acadêmicos trabalham em empresas e testam suas idéias absurdas.”
A pesquisa gerada pelas academias, _normalmente_, é pesquisa básica, não é pesquisa aplicada. A intenção final não é aplicar isso no mercado de trabalho, e sim dar base para que o mercado e a própria academia (algumas vezes) utilize o conhecimento gerado de forma aplicada à problemas relevantes. Por isso as idéias “absurdas” dos cientistias não são utilizadas no mundo comercial (conforme bem-lembrado pelo Screwball).
O princípio de que micro-kernels são menos propícios a travar é relevante. Tão relevante que se faz pesquisas em cima disso: o intuito da pesquisa não é definitivamente provar que eles funcionam. As pesquisas… pesquisam sobre o problema: parte-se do princípio de que o argumento supra-citado é correto e tentam corrigir outros problemas que tal arquitetura proporciona. Por isso é pesquisa, e não produto. Se, atualmente, no mundo comercial a solução não é aceita, não pode-se dizer que o mundo acadêmico diverge do mundo real. Mesmo porque, quando um produto não é aceito no mundo comercial, é por um motivo simples: imediatismo. Empresas precisam de imediatismo para sobreviver, de soluções imediatas.
http://www.scielo.br/scielo.php?pid=S0103-40141991000300015&script=sci_arttext
“Conheço inúmeros gênios que foram negados de fazer um Mestrado porque trabalhavam, como se uma empresa não pudesse ensinar nada aos cientistas. Ou seja, ou o nerd vive no mundo da teoria ou no da prática, é impossível viver nos dois ao mesmo tempo.”
O problema não é que ojerizam o trabalho: o problema é que quem não trabalha, tem mais tempo para se dedicar ao mestrado. Por que eu vou arriscar com um cara que trabalha e vai ter 2 horas livres por dia par afazer o mestrado se eu posso pegar aquele recém-formado que tem todo o tmepo do mundo para satisfazer meus desejos?
Não é só possível viver nos dois mundos, como é necessário: a prática é a implementação da teoria. Estranha-me alguém que provavelmente trabalha com computação me dizer isso… Ainda mais na computação, que é produto de ciência pura.
Coitado do mestre (ultrapassado).
Quando ele disse colocar em processos da área de usuário, parei de ler, isso me fez lembrar do X11, que faz com que drivers rodem na área de usuário, onde ficam ainda mais sujeitos a falhas.
No mais isso não resolve o problema do kernel, só piora, mesmo sabendo que o kernel poderá ficar na ativa, os drivers na área de usuário é igual a bomba relógio, ou ao OS controlar todos os dispositivos do computador.
Eu tenho uma proposta: separar as partes.
- Tudo que fosse relativo a Hardware (drivers) seria colocado em uma HAL;
- Itens que possuem baixa integração com o SO (ex. FileSystems) seriam tratados como módulos de baixa prioridade. Estes módulos poderiam, inclusive, serem compilados para LLVM (com um loader no kernel);
- O Kernel passaria a ter o restante, ou seja, gerenciamento de processos, de memória, de recursos de Hardware (não drivers), etc. e falaria com as demais partes via interfaces.
Poderia permanecer monolítico, mas seria muito menor. Quanto ao problema dos drivers não-GPL, a truculência do kernel em barrá-los migraria para a HAL.
Isto não é nenhum absurdo. É mais ou menos como funcionam as VMs como VBox ou VMWare. Pra mim o kernel do Linux deveria ser uma VM (talvez algo baseado no LGuest).
Ei, isto poderia ser a tão esperada versão 2.8 ou 3.0 do Linux!!!
Acho que microkernels são bons para clusters!
Estranha-me alguém que provavelmente trabalha com computação me dizer isso… Ainda mais na computação, que é produto de ciência pura.
Estranha-me os “cientistas” negarem um cérebro lotado de conhecimento empírico porque o mesmo tem 8 horas a menos que uma pessoa totalmente crua com conhecimentos duvidosos.
Acho que tem muita gente confundindo mundo “Real” com mundo Comercial.
O mundo Real não é o empresarial.
As empresas resolvem problemas reais de outras empresas e não hipotéticos. E não estou falando de comércio mas de empresas que vendem serviços.
A IBM consegue nos EUA ter pesquisadores no seu quadro de funcionários, e os mesmos resolvem problemas de outras empresas e aplicam esse conhecimento empírico nas suas pesquisas, diferentemente no Brasil quando um trabalhador da IBM tenta um Mestrado ele é rejeitado pelos czares das instituições atrasadas da burguesia USPiniana.
eje, o Linux tem caminhado pra algo parecido doq voce almeja, perceba q muitas partes do kernel ja trabalham em processos separados, diferentemente de antigamente.
A lógica do Sr. Tanenbaum é a seguinte: software contêm bugs. Para evitar que um bug no software derrube o sistema todo, faz-se um kernel mínimo, e delega-se tudo o que é não essencial (ou central) a processos externos (serviços), assim um bug em um serviço não derruba o sistema por inteiro.
Na teoria, uma grande diferença na confiabilidade. Na prática, o que muda? Ainda mais para sistemas de usuário final? Você só está jogando bugs para outras áreas, no maior estilo “covering my ass”, e não está resolvendo o problema do software, que é exatamente o fato dele TER bugs. O usuário quer que aquilo funcione com exatidão, ele não está nem aí se travou o sistema todo ou não, se não conseguir fazer o essencial: getting things done.
“Estranha-me os “cientistas” negarem um cérebro lotado de conhecimento empírico porque o mesmo tem 8 horas a menos que uma pessoa totalmente crua com conhecimentos duvidosos.”
Cara, isso não faz sentido nenhum…
“As empresas resolvem problemas reais de outras empresas e não hipotéticos. E não estou falando de comércio mas de empresas que vendem serviços.”
Pelo jeito você não leu nada do que eu disse sobre pesquisa básica e pesquisa aplicada. Aliás, pela sua resposta, vocẽ não leu nada do que eu disse sobre qualquer coisa.
“A IBM consegue nos EUA ter pesquisadores no seu quadro de funcionários, e os mesmos resolvem problemas de outras empresas e aplicam esse conhecimento empírico nas suas pesquisas, diferentemente no Brasil quando um trabalhador da IBM tenta um Mestrado ele é rejeitado pelos czares das instituições atrasadas da burguesia USPiniana.”
Isto me parece mais ressentimento do que um argumento. Tanto é que a USP frequentemente faz parceirias e permite que a IBM (e outra empresas, como uol, ms, motorola, google, etc) chame alunos de lá para estágios e empregos. Conheço várias pessoas de lá que trabalham e fazem mestrado ou que já trabalharam e largaram o trabalho para fazer o mestrado. O critério de seleção é razoavelmente claro; e o fato de alguém ser funcionário da IBM não é nada excepcional, é só um pontinho no currículo. Isto não impressiona orientador nenhum (mesmo porque, boa parte de seus egressos vão para lá), mas daí concluir que o mundo acadêmico ojeriza o mercado de trabalho (e conseqüentemente o mundo real, através de uma lógica petrefiolística), é um declive escorregadio enorme.
Você está super-estimando um emprego de alguém em detrimento do conhecimento de seus “adversários”. Não é assim não. Trabalhar na IBM, obviamente, é uma conquista e uma oportunidade única de se aprender várias coisas, mas não é o santo graal da informática. Mesmo porque, o conhecimento adquirido lá nem sempre é útil para a pesquisa básica.
Como eu disse: não é que pesquisa básica seja incondizente com o mundo comercial. Pesquisa básica é a pesquisa que vai gerar conhecimento para que as indústrias gerem pesquisa aplicada. É assim que as coisas andam, na maioria das vezes. Só ver a história: quantas vezes um produto foi inventado à partir de conhecimento tosco e puro?
Finalmente uma discussão decente sobre algo decente… pena que poucos tenha noção do que um microkernel realmente é, ou saibam o que tem acontecido na área de desenvolvimento de SO.
“A idéia é ótima, só não conseguiram fazer um kernel desses com a performance e features de um maior.”
O teu comentário é uma prova do que acabei de falar. OKL4 e L4::Pistachio rodam Linux paravirtualizado com perda de performance muito pequena (e em alguns microbenchmarks com uma performance melhor).
Pesquisem sobre microkernels (ignorando as aberrações genéticas (como Mach e Hurd, duas porcarias mal planejadas)) e vocês vão ver que existe um futuro muito promissor nessa área.
Há muitos comentários e poucos sensatos. Uma frase do próprio Linus, não para o Tanenbaum (que é excelente), mas para a maioria dos que aqui comentaram: “Talk less. Code more.”
“Na teoria, uma grande diferença na confiabilidade. Na prática, o que muda? Ainda mais para sistemas de usuário final? Você só está jogando bugs para outras áreas, no maior estilo “covering my ass”, e não está resolvendo o problema do software, que é exatamente o fato dele TER bugs. O usuário quer que aquilo funcione com exatidão, ele não está nem aí se travou o sistema todo ou não, se não conseguir fazer o essencial: getting things done.”
EEEEEEeeeeeeeee…. ERRADO!
vamos supor que o sr. Henrique tem um celular… e ele roda Linux com aplcações gráficas legais e tal… e ele recebe uma ligação, e enquanto ele fala no telefone, alguma aplicação tenta acessar um USB ou algo que depende de uma syscall e dá kernel panic. O indivíduo em questão perdeu sua ligação. Todos esperamos que nao tenha sido algo muito importante.
Agora vejamos outro caso. O sr. Henrique tem um celular, e ele roda um microkernel (OKL4, por exemplo) rodando Linux paravitualizado para suas aplicações graficas bonitinhas, e toda a pilha GSM roda em outra área protegida, fora do Linux, em cima do microkernel. Ele recebe uma ligação. Enquanto ele fala no telefone, a aplicação gráfica resolve fazer algo, e pá! Linux kernel panic! O Linux morreu, mas não afetou a ligação. Assim que o sr. Henrique recebe a notícia de que ele foi aceito para uma vaga de emprego que ele queria, ele percebe que a interface grafica não está funcionando direito (isso se algum módulo de tratamento de erro já nao reiniciou o linux) e reinicia o celular.
Percebeu a diferença ou precisa desenhar?