Revisitando a História II: Linux 0.02, 0.03 e o GNU Hurd
Continuando a série de posts sobre os primórdios do Linux, o Slashdot avisa que o KernelTrap publicou a segunda parte do artigo, com comunicados de Linus Torvalds sobre versões iniciais do seu kernel.
O Slashdot selecionou um trecho do anúncio da versão 0.02, lançada por Torvalds menos de 3 semanas após a versão 0.01, onde ele menciona outro kernel de código aberto muito importante conceitualmente. Em tradução livre: "Eu posso (ou quase) ouvir vocês se perguntando: 'por que?'. O Hurd vai sair em um ano (ou dois, ou mês que vem, quem sabe), e eu já tenho o minix. Este é um programa para hackers por um hacker. Eu apreciei fazê-lo, e alguém pode gostar de observá-lo ou mesmo modificá-lo para suas próprias necessidades. Ele ainda é pequeno o suficiente para se entender, usar e modificar, e eu estou na expectativa de qualquer comentário que vocês possam ter."
Saiba mais (kerneltrap.org).
O Slashdot selecionou um trecho do anúncio da versão 0.02, lançada por Torvalds menos de 3 semanas após a versão 0.01, onde ele menciona outro kernel de código aberto muito importante conceitualmente. Em tradução livre: "Eu posso (ou quase) ouvir vocês se perguntando: 'por que?'. O Hurd vai sair em um ano (ou dois, ou mês que vem, quem sabe), e eu já tenho o minix. Este é um programa para hackers por um hacker. Eu apreciei fazê-lo, e alguém pode gostar de observá-lo ou mesmo modificá-lo para suas próprias necessidades. Ele ainda é pequeno o suficiente para se entender, usar e modificar, e eu estou na expectativa de qualquer comentário que vocês possam ter."
Saiba mais (kerneltrap.org).
(postado por Augusto Campos)
Comentários dos leitores
Comentário de hardware
03/08/07 20:25 - usuário registrado #7759
Hurd: Ja se passaram mais de 15 anos e até agora nada do Hurd. Alguem sabe informar em que pé está o desenvolvimento do sistema? E qual a principal diferenca do mesmo comparativamente ao Linux e Windows?
Comentário de Clésio Luiz
03/08/07 21:24 - usuário registrado #13300
As calças do boneco...: ... não estão ao contrário não? Esses bolsos não deveriam estar para trás?
Quem diria que esse pequeno e despretensioso projeto pessoal iria sacudir o mundo heim?
Como diria Raul: "basta ser sincero e desejar profundo, você será capaz de sacudir o mundo, tente outra vez"
--
"... e não sabendo que era impossível, ele foi lá e fez."
Quem diria que esse pequeno e despretensioso projeto pessoal iria sacudir o mundo heim?
Como diria Raul: "basta ser sincero e desejar profundo, você será capaz de sacudir o mundo, tente outra vez"
--
"... e não sabendo que era impossível, ele foi lá e fez."
Comentário de 7933-0 (leandro)
04/08/07 0:10
Linux e Windows são: Linux e Windows são conhecidos como kernels monolíticos, ou seja, executam nativamente o controle do hardware nos domínios do ROOT, não sendo permitido, no caso do linux e dos variantes unix, que usuários comuns façam atividades comuns como montar e acessar sistemas de arquivos, por exemplo, a não ser que o usuário tenha permissões para administrar o sistema.
Já o Hurd não é um kernel; é um conjunto de servidores projetados para rodar no userland do usuário em cima de um microkernel que, neste caso, é o Gnumach. A idéia básica deste conceito é oferecer um "empowerment", ou seja, dar poder para o usuário, permitindo, por exemplo, que ele possa montar e acessar sistemas de arquivos e dispositivos de armazenamento sem privilégios especiais, mas mantendo a segurança de todo o sistema. Isso funciona?
Bem, de modo geral, o Hurd está avançado no seu conceito chave, mas enfrenta uma grande limitação: o microkernel Gnumach não oferece desempenho necessário à dinâmica do Hurd e possui uma limitação muito grande nos drivers de dispositivos, que são derivados do kernel linux 2.x. Por isso foi tentado portar o Hurd para o moderno microkernel L4; só que nesta tentativa houve ainda mais problemas, principalmente no caso do servidor de IPC (Interprocess Comunication), requerendo que se faça grandes modificações na arquitetura do Hurd para torná-lo funcional. E como isso não é nada fácil, justamente porque o conceito de servidores interdependentes rodando no userland é algo ainda não implementado em sistemas operacionais, o projeto Hurd/L4 está praticamente parado há um bom tempo. (Existem outros kernels com conceito semelhante, como o QNX, mas nestes casos existe apenas 1 servidor rodando sobre o microkernel, e não vários servidores, como no Hurd).
A saída então é testar o Hurd com outros microkernels (o Coyotos parece que está em curso) ou reescrever o Gnumach à unha, justamente o que RMS não queria fazer, já que optou por adaptar uma versão do Mach recém liberado como free software em 1989-90 com seu ousado projeto de servidores interdependentes.
Se eu fosse programador, faria de tudo pra ajudar o projeto. Afinal quando ele estiver pronto, finalmente teremos um sistema realmente livre, com características mais avançadas que um sistema variante ao unix possui. Só então poderemos deixar Linus Torvalds com seu incrível ego e seu kernel linux seguirem seus próprios caminhos, já que devido às patentes de software, o linux já é praticamente 'quase-livre'.
Já o Hurd não é um kernel; é um conjunto de servidores projetados para rodar no userland do usuário em cima de um microkernel que, neste caso, é o Gnumach. A idéia básica deste conceito é oferecer um "empowerment", ou seja, dar poder para o usuário, permitindo, por exemplo, que ele possa montar e acessar sistemas de arquivos e dispositivos de armazenamento sem privilégios especiais, mas mantendo a segurança de todo o sistema. Isso funciona?
Bem, de modo geral, o Hurd está avançado no seu conceito chave, mas enfrenta uma grande limitação: o microkernel Gnumach não oferece desempenho necessário à dinâmica do Hurd e possui uma limitação muito grande nos drivers de dispositivos, que são derivados do kernel linux 2.x. Por isso foi tentado portar o Hurd para o moderno microkernel L4; só que nesta tentativa houve ainda mais problemas, principalmente no caso do servidor de IPC (Interprocess Comunication), requerendo que se faça grandes modificações na arquitetura do Hurd para torná-lo funcional. E como isso não é nada fácil, justamente porque o conceito de servidores interdependentes rodando no userland é algo ainda não implementado em sistemas operacionais, o projeto Hurd/L4 está praticamente parado há um bom tempo. (Existem outros kernels com conceito semelhante, como o QNX, mas nestes casos existe apenas 1 servidor rodando sobre o microkernel, e não vários servidores, como no Hurd).
A saída então é testar o Hurd com outros microkernels (o Coyotos parece que está em curso) ou reescrever o Gnumach à unha, justamente o que RMS não queria fazer, já que optou por adaptar uma versão do Mach recém liberado como free software em 1989-90 com seu ousado projeto de servidores interdependentes.
Se eu fosse programador, faria de tudo pra ajudar o projeto. Afinal quando ele estiver pronto, finalmente teremos um sistema realmente livre, com características mais avançadas que um sistema variante ao unix possui. Só então poderemos deixar Linus Torvalds com seu incrível ego e seu kernel linux seguirem seus próprios caminhos, já que devido às patentes de software, o linux já é praticamente 'quase-livre'.
Comentário de Ark
04/08/07 8:27
Hurd: O Stallman fez muita coisa para seu kernel, mas ao invés de colocar no Hurd, colocou no Emacs.
Comentário de Cadu
04/08/07 23:12 - usuário registrado #17
Bah...: Uma das melhores frases sobre o emacs que eu já vi...
Deveria ir para a lista de frases favoritas dos usuários de vi... :)
Deveria ir para a lista de frases favoritas dos usuários de vi... :)
Comentário de Dordetto
05/08/07 20:01
Despretensioso: Só não concordo com o comentário: "pequeno e despretensioso", pequeno Sim, mas Despretensioso não...
Certa vez vi uma declaração do Linus onde ele dizia que Ele sendo um dos melhores programadores do mundo ele resolveu fazer um sistema operacional realmente Bom, melhor do que já existia no mercado!!!! (Despretensioso??? Que nada ele queria dominar o mundo!!!!)
Dordetto
http://www.vertic.com.br/blog
Certa vez vi uma declaração do Linus onde ele dizia que Ele sendo um dos melhores programadores do mundo ele resolveu fazer um sistema operacional realmente Bom, melhor do que já existia no mercado!!!! (Despretensioso??? Que nada ele queria dominar o mundo!!!!)
Dordetto
http://www.vertic.com.br/blog
Comentário de samuelbh
07/08/07 12:16 - usuário registrado #14778
Também acho que os bolsosestão do lado errado: E o pinguim foi feito com uma cabeça de lego branca e um cabelo de mocinha (esse foi o comentário mas inútil que eu já postei...rsrs).
Comentário de Leonardo L. AKA ofranja
19/08/07 23:09 - usuário registrado #557
Microkernels e etc.: Na verdade, se o problema fosse só de permissões (usuário não pode montar/acessar hardware), seria possível resolver isto implementando alguma 'policy' de acesso em system calls como mount, criando um dispositivos especial no /dev, e por aí vai. Alternativas são várias.
O ponto principal é que um kernel monolítico consiste de um só programa 'indivisível' (daí o nome "monolítico"), enquanto os micro-kernels foram desenvolvidos para dividir o SO em "sistema base" (serviços básicos, como MMU e etc), rodando em espaço de kernel, e a funcionalidade auxiliar (drivers de dispositivo), rodando em processos auxiliares.
Os processos auxiliares, por sua vez, utilizariam a mesma interface dos programas userspace tradicionais, e poderiam ser substituídos/reiniciados mais facilmentes, fazendo com que os sistemas se tornassem mais seguros, estáveis, e que pudessem ser reparados enquanto executando. Essa é a idéia base.
O caso do L4 é interessante, porque ele não tem praticamente *nada* executando em espaço de kernel, só algumas abstrações bem básicas, além de ter algumas mudanças importantes, trazendo-o mais para próximo do conceito de micro-kernel. Isso torna ele bem diferente do Mach, que possui uma boa centena de system calls, e algumas questões de desempenho. Na verdade, o L4 é um dos poucos micro-kernels de pesquisa que se consolidou e possui uso prático.
Eu vejo como uma desvantagem para o GNU/Hurd ter deixado o L4 de lado - mas como não conheço o micro-kernel Coyote, torço para que eles tenham algum respaldo técnico muito forte por trás desta decisão. Afinal, de decisões políticas na comunidade do software livre, já temos exemplos demais.
E é isso.
--
??aluatio? [http://evaluated.blogspot.com]
-- Readings and researches about CS.
O ponto principal é que um kernel monolítico consiste de um só programa 'indivisível' (daí o nome "monolítico"), enquanto os micro-kernels foram desenvolvidos para dividir o SO em "sistema base" (serviços básicos, como MMU e etc), rodando em espaço de kernel, e a funcionalidade auxiliar (drivers de dispositivo), rodando em processos auxiliares.
Os processos auxiliares, por sua vez, utilizariam a mesma interface dos programas userspace tradicionais, e poderiam ser substituídos/reiniciados mais facilmentes, fazendo com que os sistemas se tornassem mais seguros, estáveis, e que pudessem ser reparados enquanto executando. Essa é a idéia base.
O caso do L4 é interessante, porque ele não tem praticamente *nada* executando em espaço de kernel, só algumas abstrações bem básicas, além de ter algumas mudanças importantes, trazendo-o mais para próximo do conceito de micro-kernel. Isso torna ele bem diferente do Mach, que possui uma boa centena de system calls, e algumas questões de desempenho. Na verdade, o L4 é um dos poucos micro-kernels de pesquisa que se consolidou e possui uso prático.
Eu vejo como uma desvantagem para o GNU/Hurd ter deixado o L4 de lado - mas como não conheço o micro-kernel Coyote, torço para que eles tenham algum respaldo técnico muito forte por trás desta decisão. Afinal, de decisões políticas na comunidade do software livre, já temos exemplos demais.
E é isso.
--
??aluatio? [http://evaluated.blogspot.com]
-- Readings and researches about CS.