Feliz 35º aniversário, Linux

Celebrando o 35º aniversário do Linux

 No dia 25 de Agosto de 1991 Linus Torvalds publicou a seguinte mensagem no Newsgroups comp.os.minix intitulada "O que você mais gostaria de ver no minix?" e com o sumário "Uma pequena enquete sobre o meu novo sistema operacional":

" Olá a todos aí fora utilizando minix -

 Estou fazendo um sistema operacional (livre) (apenas um hobby, não vai ser grande ou profissional como o gnu) para clones AT 386(486).  Ele vem se formando desde Abril e está começando a ficar pronto. Eu gostaria de feedback de coisas que as pessoas gostam e não gostam no minix já que meu OS se assemelha a ele de alguma forma (mesmo layout físico do file-system devido a razões práticas entre outras coisas).

 Atualmente eu portei bash(1.08) e gcc(1.40) e as coisas aparentam funcionar. Isso significa que eu terei algo prático dentro de alguns meses e eu gostaria de saber quais recursos a maioria das pessoas querem. Quaisquer sugestões são bem vindas, mas eu não vou prometer que vou implementa-las :-)

                Linus (torvalds@kruuna.helsinki.fi)

 OBS. Sim - ele é livre de qualquer código do minix e possui um  fs multi-threaded. Ele NÃO é portável (utiliza 386 task switching etc) e provavelmente nunca possua suporte a qualquer coisa além de disco rígido AT já que é tudo o que eu tenho :-(."

 Esta foi provavelmente a terceira ou quarta mensagem enviada por Linus e não se tratou do lançamento do Linux já que, em suas próprias palavras, o Linux "está começando a ficar pronto", que "as coisas aparentam funcionar" e que "significa que eu terei algo prático dentro de alguns meses". A segunda evidência pode ser lida no Oral History of Linus Torvalds de 27 de Julho de 2008 para o Computer History Museum na página 15 quando Grady Booch lhe pergunta:

"Houve o anuncio de Agosto em 1991. Esse foi o anuncio ou foi um subsequente?"

 A que Linus lhe responde:

"Eu acho que o anuncio de Agosto foi realmente um pré-anuncio. Esse foi o anuncio no que eu estava trabalhando. Eu não havia realmente feito um lançamento ainda, se eu me lembro corretamente."

 A terceira evidencia está no link da Universidade de Carnegie Mellon (mesma universidade que deu origem ao micro-kernel Mach que é utilizado tanto pela Apple no MacOS X quanto pelo projeto GNU no Hurd, que na verdade se chama GNU Mach) que são textos escritos pelo próprio Linus no dia 31 de Julho de1992. Lá é possível ler Linus explicando porque lançou a versão 0.01:

"Julgando pelo post, o 0.01 ainda não havia sido lançado na verdade, mas estava próximo. Eu imagino que a primeira versão foi lançada em meados de Setembro de 91."

 E a ultima está no próprio https://www.nic.funet.fi, local onde Linux foi disponibilizado pela primeira vez e que  está ativo até os dias de hoje contendo a seguinte mensagem:

"Linux foi disponibilizado pela primeira vez ao mundo a partir daqui no dia 17/09/1991"

 Logicamente não se trata mais do mesmo hardware da época, sendo hoje um muito mais potente possuindo dois processadores de 20 núcleos, 786GB de RAM, mais 80TB de storage NFS da NetApp e 2 conexões de 25Gbit/s (informações disponíveis no rodapé do próprio site).

Linux foi disponibilizado pela primeira vez ao mundo a partir daqui no dia 17/09/1991

 Então, como o aniversário do Linux pode ser comemorado no dia 25 de Agosto já que sua primeira versão (0.01) só foi lançada no dia 17 de Setembro? Pois é, quase um mês após a publicação da mensagem que vocês leram no início deste artigo. Você comemora o nascimento de uma criança antes de ela nascer? Qual o sentido disso?

 OK. Isso significa então que o aniversário do Linux é no dia 17 de Setembro, certo? ERRADO! Neste mesmo link da universidade de Carnegie Mellon, Linus descreve que:

"Os códigos do 0.01 não eram na verdade executáveis: Eles eram apenas um gesto simbólico para arl, que provavelmente tinha começado a perder a esperança de conseguir qualquer coisa. Essa próxima mensagem deve ter sido de apenas algumas semanas antes daquele lançamento."

"Era somente o código fonte para pessoas interessadas em saber como era o Linux" 

"Ele não era nada bonito, não tinha driver para floppy e não conseguia fazer quase nada. Eu não acredito que alguém jamais tenha compilado aquela versão. Mas, a essa altura, eu já estava fisgado e não queria parar até conseguir me livrar do Minix." 

 A versão 0.01 foi apenas uma versão embrionária, uma espécia de ultrassom do Linux. O lançamento oficial do Linux ocorreu no dia 5 de Outubro de 1991 às 05:41:06 GMT na versão 0.02 com a mensagem contendo título "Códigos do kernel livre parecido com o minix para 386-AT":

 "Você anseia os bons tempos do Minix 1.1, quando homens eram homens e escreviam seus próprios device drivers? Você está sem um bom projeto e morrendo para dar os primeiros passos em um OS que você possa modificar para as suas necessidades? Você está achando frustrante quando tudo funciona no minix? Chega de passar a noite em claro para fazer um programa bacana funcionar. Então esta mensagem pode ser para você :-)

 Como eu mencionei um atrás (?), eu estou trabalhando em uma versão livre de um similar ao minix para computadores AT-386. Ele finalmente alcançou o estágio onde está utilizável (embora possa não estar dependendo do que você queira) e eu estou disposto a disponibilizar o código-fonte para uma distribuição mais ampla. Ele ainda está na versão 0.02 (+1 (bem pequeno) patch pronto), mas eu consegui rodar bash/gcc/gnu-make/gnu-sed/compress e etc nele.

 Os códigos fonte para esse projeto meu podem ser encontrados no nic.funet.fi (128.214.6.100) dentro do diretório /pub/OS/Linux. O diretório também possui alguns arquivos README e alguns binários para funcionar sob o linux (bash, update e gcc, o que mais você poderia querer :-). O código completo do kernel é fornecido, já que nenhum código do minix é utilizado. códigos da biblioteca são parcialmente livres, então ela não pode ser distribuída atualmente. O sistema é capaz de compilar "tal como está" e é de conhecimento por funcionar. Heh. Códigos fonte para os binários (bash e gcc) podem ser encontrados no mesmo lugar em /pub/gnu.

 ALERTA! AVISO! NOTA! Esses códigos fonte ainda necessitam do minix-386 para serem compilados (e gcc-1.40, possivelmente 1.37.1, não foi testado), e você precisa do minix para configurá-lo se quiser rodá-lo, então ele não é um standalone ainda para aqueles de vocês ainda sem o minix. Eu estou trabalhando nisso. Você também precisa ser algo como um hacker para configurá-lo (?), então para queles esperando por uma alternativa ao minix-386, por favor me ignorem. Atualmente, ele é destinado para hackers interessados ​​em sistemas operacionais e em máquinas 386, com acesso ao Minix.

 O sistema precisa de um disco rígido compatível com padrão AT (IDE está bom) e EGA/VGA. Se ainda estiverem interessados, por favor ftp os README/RELNOTES, e/ou me enviem e-mail para obter informações adicionais.

 Eu consigo (bem, quase) ouvir vocês se perguntando "por que"?. O Hurd vai ser lançado em um ano (ou dois, ou no mês que vem, quem sabe?), e eu já tenho o minix. Esse é um programa para hackers por um hacker.  Eu me diverti desenvolvendo ele e alguém pode se divertir olhando para ele e até mesmo modificando-o para suas próprias necessidades. Ele ainda é pequeno o suficiente para para entender, utilizar e modificar e eu estou com expectativa de quaisquer comentários que você possa ter.

 Também estou interessado em ouvir qualquer um que tenha escrito quaisquer utilidades ou funções de biblioteca para o minix. Se seus esforços são distribuíveis livremente (sob copyright ou mesmo domínio público), eu gostaria de ouvir você, assim eu consigo adicioná-las ao sistema. Estou utilizando Earl Chews estdio agora mesmo (obrigado pelo bom e funcional sistema Earl), e trabalhos similares serão muito bem vindo. Seus (C)'s serão mantidos intactos é claro. Deixe-me uma linha se você estiver disposto a me deixar utilizar o seu código.

                Linus

 PS. para PHIL NELSON! Não consigo te contatar, e continuar conseguindo "encaminhar erro - strawberry unknown domain" ou algo.

 Resumidamente, o aniversário do Linux é no dia 05 de Outubro pois esta é a verdadeira data do seu lançamento, o lançamento que garantiu funcionamento mínimo para quem quisesse utilizá-lo e que não era garantido na versão 0.01. E a partir da versão 0.12 (que eu já expliquei que foi onde surgiu o suporte a memória virtual e a migração da licença da convenção de Berna do século XVIII para a GPLv2) começaram a surgir as primeiras distribuições Linux:

 Daí para frente, a história do Linux é pura evolução e eu aconselho a assistir as minhas palestras A Evolução do Linux e Linux domina o mundo, mas por que? que podem ser assistidas logo abaixo:

 Para todos os o que chegaram aqui, eu tenho uma surpresa para vocês. Para que possamos juntos comemorar o aniversário do Linux, eu disponibilizei vagas gratuitas do meu curso. É só clicar no link abaixo e aproveitar :) Mas aproveite, porque estas vagas são por tempo limitado (validas somente até o final do mês).

Vaga do meu curso para comemorar o aniversário do Linux

 

Aproveite também para ler o artigo A farsa do termo "Linux é apenas o kernel"

comp.os.minix do Google Groups

https://www.nic.funet.fi/

linux history no www.cs.cmu.edu

Torvalds, Linus Benedict oral history

https://archive.computerhistory.org/resources/access/text/2012/10/102658325-05-01-acc.pdf

The Origins of Linux—Linus Torvalds

 Porém, se você quiser ajudar o canal e o blog, você também pode comprar o meu curso clicando no link abaixo:

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

Feliz aniversário de 30 anos, Linux

    Em março deste ano a Linux Foundatio publicou imagens para celebrar os trinta anos do Linux. Essas informações podem ser lidas clicando aqui.

    30 anos atrás neste mesmo dia, Linus Torvalds publicava sua segunda mensagem sobre o Linux. Em uma entrevista de 2008 ao Museu da Historia do computador, Linus afirma que estava trabalhando na verdade trabalhando inicialmente em um clone do Minix já que as coisas no Minix eram horríveis e ele desenvolvia suas próprias versões das mesmas coisas do Minix (driver de discagem de internet, de HD, de sistema de arquivos e tudo) para seu emulador de terminal, só que verões melhores das mesmas coisas.

 Foi daí que em um determinado momento Linus decidiu desenvolver um kernel para ter o seu clone do Minix porém esse clone do Minix se transformou em um clone do Unix e Linus Torvals dispara esta mensagem no dia 3 de Julho e não deixava claro que estava trabalhando no Linux:

 From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)

  Newsgroups: comp.os.minix

  Subject: Gcc-1.40 and a posix-question

  Message-ID:

  Date: 3 Jul 91 10:00:50 GMT

  Olá netlanders,

  Devido a um projeto que estou trabalhando (no minix), estou interessado na definição do padrão posix. Alguém poderia me indicar um formato (de preferência) legível por máquina das regras de posix mais recentes?

     Sites FTP seriam bons.

 Esta mensagem não deixa bem claro que Linus estava desenvolvendo um clone do Unix e por isso as pessoas demoraram a responder. Então Linus passou a utilizar os manuais POSIX da Sun Microsystems que ele conseguiu na biblioteca da universidade de Helsinki. Até que depois de um tempo as pessoas o enviaram os manuais para trabalhar em seu sistema operacional. Ari Lemke (o verdadeiro autor do nome Linux) leu a mensagem acima e disponibilizou o subdiretório FTP para da universidade para Linus com o nome de Linux (foi a partir daí que o sistema operacional, que iria se chamar Freax, passou a se chamar Linux).

    Então, no dia 25 de Agosto, quando  Linus se sentiu seguro de disponibilizar o seu código fonte, era publicado a mensagem de lançamento do kernel 0.01

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)

Newsgroups: comp.os.minix

Subject: O que vocês mais gostariam de ver do minix?

Summary: pequena enquete para meu novo sistema operacional

Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>

Date: 25 Aug 91 20:57:08 GMT

Organization: University of Helsinki

Olá a todos aí fora utilizando minix –

    Estou fazendo um sistema operacional (livre) (apenas um hobby, ele não vai ser grande e profissional como o GNU) para clones AT 386 (486). Ele está fermentando desde abril e está começando a ficar pronto. Eu gostaria de qualquer feedback sobre coisas que as pessoas gostam/não gostam no minix, já que meu sistema operacional se assemelha um pouco com ele (mesmo layout físico do sistema de arquivos (devido a razões práticas) entre outras coisas). Eu já portei o bash (1.08) e o gcc (1.40), e as coisas parecem funcionar. Isso implica que vou conseguir algo prático em alguns meses e gostaria de saber quais recursos a maioria das pessoas gostaria. Todas as sugestões são bem-vindas, mas não prometo que as implementarei :-)

Linus (torvalds@kruuna.helsinki.fi)

PS. Sim - é livre de qualquer código minix e tem um fs multi-thread. NÃO é portável (usa comutação de tarefas 386, etc.) e provavelmente nunca suportará nada além de discos rígidos AT, já que é tudo o que eu possuo.

    E aqui estamos hoje. Um hobbie que começou em seu quarto como um projeto pessoal e acadêmico  e que evoluiu e se tornou o maior projeto colaborativo da história do mundo.

Se você quiser baixar estas imagens e compartilhá-las, basta clicar neste texto e seja feliz.

 E PARA CELEBRAR OS 30 ANOS DO LINUX, VENHA APRENDER LINUX DE VERDADE COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Dando créditos ao... Minix?

    Tenho certeza que, inconscientemente você esperava ler "dando mais créditos ao GNU" pois isso é o que lemos e ouvimos a vida toda. Há mais de 20 anos, a alegação dos defensores de software livre é que as ferramentas que utilizamos nas distribuições Linux são de autoria do projeto GNU (o que não é necessariamente verdade) e com isso brigam para que o nome GNU seja reconhecido no Linux para assim dar-lhe os "devidos créditos" (parece até mesmo uma briga por paternidade). Essa é uma das brigas mais inúteis que eu já vi; mas graças a essa briga inútil é que outras ferramentas muitos importantes, tão bons quanto as do GNU (e muitas vezes até melhor), não ganharam a notoriedade e adesão que deveriam e mereciam.

    Como ferramentas como o terminal de comandos Zsh não ganharam notoriedade sendo o Zsh um terminal muito melhor que o Bash e apenas um ano mais novo? Como outras bibliotecas como a Dietlibc, musl e newlib também não são mais adotadas podendo tornar os mesmos binários bem menores e bem mais confiáveis? E assim esse questionamento segue para todas as ferramentas do projeto GNU que utilizamos (fora ferramentas dos BSDs, do MIT, Plan9 e até mesmo do próprio Linux que utilizamos das distribuições). E foi por isso que eu criei a série Muito além do GNU.

    Mas algo que pode te surpreender (ou talvez não) é que há um grupo que quer o mesmo reconhecimento, só que para o Minix. O site Cnet publicou em Maio de 2004 um artigo intitulado "Torvalds é realmente o pai do Linux?" que apesar de eu não encontrar o link da fonte no seu artigo, 14 pessoas apresentaram em Washington, D.C um relatório de 92 páginas sugerindo que mais créditos do Linux deveriam ir para o Minix (parecem os fanboys do Batman que fizeram um abaixo assinado no site change.org pedindo ao presidente da Warner que proibisse que o ator Ben Affleck interpretasse  personagem... Eu juro que eu não acreditei nisso quando vi 😂)

    O estudo sugere que Linux Torvads pode ter gradualmente substituído código Minix do Linux, mas Linus afirmou que isso nunca aconteceu e argumentou que ele e outros desenvolvedores do Linux deram os créditos apropriados. O Minix foi simplesmente uma plataforma que Linus Torvalds fez seu trabalho de programação:

"Linux nunca utilizou código do Minix... Nunca demos credito a código de ninguém porque nunca utilizamos código de ninguém, mas o Unix sim forneceu as ideias. Nunca houve qualquer pergunta a respeito do fato de que o Linux foi muito aberto a pegar um monte de boas ideias do Unix."

"Eu estava utilizando o Minix quando eu escrevei o Linux, mas isso é no mesmo sentido de que você está utilizando Windows quando você escreve sua coluna. Seus artigos contem código fonte do Windows porque você utiliza Windows para escrevê-los?"

    A questão de inspirar-se em ideias do Unix é realmente um ponto muito relevante e valido mas que realmente nunca levamos em consideração defendemos cegamente com unhas e dentes projetos como o GNU que perde seu tempo disputando reconhecimento (com o nosso cego consentimento e apoio) ao invés de concentrarem em tornar suas ferramentas melhores. Não somente os Unix mas também outros sistemas operacionais como o Inferno, o Plan9 (Plan9 tem importância muito significativa para os sistemas operacionais) e o MacOS X são fontes de ideias muito importantes para o Linux. Em uma entrevista, Linus mesmo fez essa afirmação:

HY: Você pensa nesses outros sistemas operacionais PC-Unix como rivais, ou mais como celgas? Você olha para eles com frequência para ver o que pode ser incorporado ao Linux, ou eles nunca te incomodam de forma alguma?

Linus: Eu raramente me preocupo com outros sistemas. Eu me concentro totalmente apenas em tornar o Linux o melhor OS que eu puder, e enquanto isso as vezes envolve pegar ideias de outros sistemas, não é exatamente uma grande parte (e quando eu tenho novas e interessantes ideias eu geralmente me volto a sistemas mais radicais como o Plan-9 ou o Inferno, e então eu tento decidir quais dessas ideias são realmente validas).

    Enquanto isso, em uma entrevista ao Department of Computer Science da universidade de Vrije, intitulada "Quem escreveu Linux", Andrew argumenta que "Linus não sentou em um vácuo e de repente digitou o código fonte do Linux.  Ele tinha o meu livro, estava rodando o Minix e indubitavelmente sabia a história (desde que isto está no meu livro). Mas o código era dele"

    Bom, fazendo uma analise nesta frase do professor Andrew Tanenbaum, temos aqui três pontos. O primeiro é a alegação do uso do seu livro como argumento para se autopromover; que então neste caso deve-se também dar créditos ao Solaris. Por que? Vamos investigar na história.

  From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)

  Newsgroups: comp.os.minix

  Subject: Gcc-1.40 and a posix-question

  Message-ID:

  Date: 3 Jul 91 10:00:50 GMT

  Olá netlanders,

  Devido a um projeto que estou trabalhando (no minix), estou interessado na definição do padrão posix. Alguém poderia me indicar um formato (de preferência) legível por máquina das regras de posix mais recentes?

     Sites FTP seriam bons.

    Esta é primeira mensagem enviada por Linus Torvalds e que é familiar entre nós que, devido os manuais POSIX serem caros, ele tentou conseguir uma cópia com alguém para trabalhar no desenvolvimento do Linux. Como ninguém havia respondido durante um bom tempo, então Linus passou a utilizar os manuais POSIX da Sun Microsystems que ele conseguiu na biblioteca da universidade de Helsinki. Sim, Linus utilizou o livro de Andrew para estudar e entender como um sistema operacional funciona internamente, mas Linus utilizou os manuais POSIX do Solaris para tornar Linux um verdadeiro clone do Unix (claro que depois outros manuais POSIX também foram utilizados depois que foram enviados, mas toda a implementação das características POSIX ao Linux começou com os manuais do Solaris).

    Segundo ponto

    Andrew Tanenbaum também não programou Minix no Vácuo (bem óbvio); ele também precisou de um sistema operacional para desenvolver e compilar do Minix, que na ocasião foi o sistema operacional Coherent, o primeiro clone do Unix na história:

"Inicialmente, eu fiz o desenvolvimento de software no meu IBM PC rodando o Coherent da Mark Williams, um clone V7 escrito pela alumni da Universidade de Waterloo. Seu código fonte não era publicamente disponível. Utilizar o Coherent foi inicialmente necessário porque a principio eu não tinha um compilador C."

    Terceiro e ultimo ponto

    Como afirmado pelo próprio Andrew, o código era do Linus. ENTÃO DANE-SE. Algo que eu aprendi ao longo do tempo estudando licenças open source é que você pode revogar direito sim, mas sobre o seu código, não sobre código de terceiros e nem por terceiros utilizarem suas ferramentas (você concordou com isso). Alias, nem é necessário lei para isso, é uma questão de bom senso e de lógica. Já pensou se johann pachelbel tivesse que dar créditos ao fabricante do órgão, do papel, da caneta tinteiro e todos os outros só por ter utilizado seus produtos para compor canon in d major? haja paciência...

    O que eu percebo é que tudo isso não passa de uma tentativa frustrada e fracassada tanto por parte do GNU quanto do Minix de fazer propaganda do seu trabalho em cima de um sistema operacional Linux que teve o seu sucesso inesperado e subestimado por ambos; essa é a forma mais inútil que o Minix  o GNU encontraram para se promover. A forma mais lógica de se dar créditos a uma projeto pode ser lida através da informação extraída do livro OpenLife e exceder a isso é desnecessário:

Um fator final importante foi que Linus não trabalhou sozinho. Ele foi aberto para ideia colocadas adiante por outros, e aberto para colaborações. Além disso, ele baseou seu trabalho em outros previamente feito por outros (minix) e aproveitou-se de ferramentas criadas por outros (bash, e gcc).

https://www.cs.vu.nl/~ast/brown/codecomparison/

http://www.groklaw.net/article.php?story=20090419181306570

https://www.cs.vu.nl/~ast/brown/codecomparison/

https://cacm.acm.org/magazines/2016/3/198874-lessons-learned-from-30-years-of-minix/fulltext

https://www.cnet.com/news/is-torvalds-really-the-father-of-linux/

https://www.openlife.cc/content/download-and-read-open-life-book

 QUER APRENDER A UTILIZAR O BTRFS NO FEDORA, ENTÃO VENHA APRENDER LINUX COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

O que define um Unix?

O que define um Unix?

 Na ultima live que aconteceu ontem, debati a afirmação de que os BSDs e o MacOSX (também chamado OSX) não são Unix... Baseado em nada e em coisa nenhuma. O estranho foi afirmar que o FreeBSD não é por não possuir a Single Unix Specification (também abreviado para SUS) enquanto que MacOSX, mesmo possuindo a SUS, está distante do que o Unix é.... Torna-se totalmente contraditório. Então vamos a o que interessa baseado em pontos históricos e técnicos (e que comece o mimimi).

 Mesmo sendo um clone do Unix, Linux é um verdadeiro Unix (caso queria saber mais sobre clones do Unix, quem forjou esse termo e qual foi o primeiro clone da história, fiz um video alguns anos atrás explicando melhor sobre o assunto).

 Como descrito no próprio site kernel.org, "Linux é desenvolvido de acordo com a API POSIX e a Single UNIX Specification".

 Linux é um clone do sistema operacional Unix, escrito do zero por Linus Torvalds com assistência de um time espontaneamente unido de hackers em torno da Net. Ele visa conformidade com a POSIX e a Single UNIX Specification.

Ele possui todos os recursos você esperaria de um pleno Unix moderno, incluindo multitarefa real, memória virtual, bibliotecas compartilhadas, carregamento em demanda, executáveis copy-on-write compartilhados, gerenciamento de memória adequado, e redes multitarefa incluindo IPv4 e IPv6.

 Também está descrito no artigo diferenças entre Linux e Unix escrito por Phil Estes no site Open Source.com que:

"Por conta dos padrões e conformidades POSIX, programas escritos no Unix podiam ser compilados para um sistema operacional Linux com uma quantidade habitualmente limitada de esforço de port. Shell scripts podiam ser utilizados diretamente no Linux na maioria dos casos. Enquanto algumas ferramentas tinham levemente opções diferentes em flag/command-line entre Unix e Linux, a maioria operavam o mesmo em ambos."

 A principio tratava-se do desenvolvimento de um sistema operacional que deveria parecer-se com o Minix (por isso o e-mail "Um Minix melhor do que o Minix") para substituí-lo no seu uso pessoal diário já que o Minix não fazia tão bem todas as tarefas que as pessoas precisavam. Porém seu novo sistema operacional (que ia se chamar Freax e não Linux*) começou a entrar em uma metamorfose, tonando-se algo muito maior e mais poderoso e foi aí que Linus teve a seguinte ideia:

"Por que não transformar meu sistema operacional em um Unix?"

 Então Linus disparou a seguinte mensagem que todos já conhecem:

  From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)

  Newsgroups: comp.os.minix

  Subject: Gcc-1.40 and a posix-question

  Message-ID:

  Date: 3 Jul 91 10:00:50 GMT

 Olá netlanders,

  Devido a um projeto que estou trabalhando (em minix), estou interessando na definição do padrão posix. Alguém poderia por favor me indicar um formato (preferencialmente) de leitura de máquina das ultimas regras posix? Sites ftp seria legal.

 Depois que lhe enviaram o manuais, Linus trabalhou para implementar todas as características POSIX necessárias (cerca de 98%) para se ter um kernel Unix. É claro que nem todas as características puderam ser implementadas logo em seu lançamento inicial; mas as pessoas já tinham acesso a um Unix. As demais características foram sendo gradativamente implementas em seus próximos lançamentos. Uma exemplo dessas características que ainda não havia sido implementada e que Linus relata em sua biografia foi o init system:

" Okay, tradicionalmente em um real sistema Unix o primeiro programa que você executa é chamado init, mas o init realmente precisa de um monte de infraestrutura para que funcione. Ele é tipo um controlador para o que acontece. Mas quando você realmente não tem algo que funcione, não há sentido ter init. Então ao inves de iniciar o init, a primeira coisa que meu kernel fazia era iniciar o shell. Eu tinha implementado cerca de 25 system calls e, como mencionei, esse foi o primeiro programa real que eu estava tentando executar."

 Tais outros recursos foram sendo adicionados gradativamente ao longo de cada nova versão. E somente para confirmar que seu sistema operacional era um Unix, Linus decidiu compilá-lo utilizando o GCC com a logica de que, já que o compilador seguia tais normas, se conseguisse compilar seu kernel com o GCC, logo ele conseguiu desenvolver um Unix. Foi pelo mesmo motivo que Linus Torvalds decidiu fazer uso também de outras ferramentas do GNU (como Bash e Emacs) e do BSD. Desta forma, as pessoas olhavam para o Linux e enxergavam um Unix.

 Moral da história, estamos tratando de um verdadeiro Unix. O que define um Unix é ele ser um Unix e não possuir um certificado de especificação ou uma opinião.

https://www.opengroup.org/membership/forums/platform/unix
https://www.opengroup.org/openbrand/register/
https://www.opengroup.org/openbrand/register/index2.html
https://www.kernel.org/category/about.html
https://www.kernel.org/linux.html

CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Os 5 diferentes modelos de kernels

A palavra inglesa kernel (pronuncia-se em inglês kârnl e seu plural é kernels) tem o sentido de semente, grão, núcleo entre outros.

 Quando começamos a imergir no mundo Linux, acabamos conhecendo a sua relação histórica com o sistema operacional Minix. Se você conhece a história, sabe que o Linux nasceu na comunidade Minix; os e-mails trocados foram feitos na comp.os.minix; de certa forma, o Linus teve sua inspiração em decepções com o Minix, patches escritos para o Minix (e que nunca foram utilizados no Minix) foram portados para o Linux, e a primeira comunidade Linux foi composta de usuários de Minix.

 E no meio disso tudo, acabamos descobrindo que do kernel Linux é monolítico enquanto que o kernel do Minix é microkernel. Daí surge a pergunta "que raio é isso de kernel monolítico e microkernel?". E pesquisando, acabamos descobrindo que o assunto é mais longo do que imaginamos e vamos então aqui destrinchar o assunto.

 Um sistema operacional é composto de um conjunto de software; cada item construído para um propósito especifico. Dividindo o sistema em partes e sem entrar em detalhes, temos o kernel, drivers, bibliotecas do sistema, ferramentas do sistema e as ferramentes de desenvolvimento. Todas as demais ferramentas que utilizamos no dia a dia são construídas com base nessas. Mas aqui vamos analisar somente o kernel, o núcleo do sistema operacional.

 O kernel possui quatro responsabilidades básicas; gerenciamento de comunicações entre dispositivos e software, gerenciamento de memória, gerenciamento de processador e manipular as chamadas do sistema (e gerencia os recursos do sistema).

Como o kernel atua em seu sistema operacional.

 Dentro do área kernel, não existe um único tipo, podendo ser divido em quatro modelos diferentes que são: Kernel monolítico, microkernel, nanokernel e exokernel. Vamos analisar cada um destes modelos (ou ao menos, alguns deles).

Kernel monolítico

 Também por vezes sendo chamado de monobloco ou kernel estático, é o modelo que a maioria dos seus recursos são executados pelo próprio kernel como demonstrado na imagem abaixo.

Visão geral do kernel monolítico.

 Exemplos de sistemas operacionais kernel monolítico são muitos dos UNIX-like como os BSDs e seus derivados, os Solaris, AIX, HP-UX e o Linux (não vou entrar em detalhes aqui sobre os Unix. Sugiro a leitura dos meus posts sobre os sistemas: Definição UNIX-like, O que ue é Linux: Uma visão geral do sistema operacional Linux, POLÊMICA – Linux ou BSD? Qual o melhor? e Uma opinião nas diferenças entre BSD e Linux (Dando Crédito aonde o Crédito é Devido), o antigo MS-DOS, Windows 9x (incluindo o FreeDOS). O antigo MacOS (nas versões abaixo do 8.6 [possuo uma cópia do Mac OS 8.5. Na época, o Macbook preto usava dispositivo drive de disquete removível para conectar o drive de CD no mesmo local]).

(FreeDOS)

Kernel modular

 (17/04/2022) Trata-se do modelo que possui drivers e outros itens do kernel que se localizam fora do kernel e que podem ser carregados e descarregados de forma modular (daí o termo kernel modular). Vale reforçar que módulos também são drivers, a diferença é que localizam-se fora do kernel. reforço isso pois há um mito no mundo Linux de que driver é um termo do Windows enquanto que no Linux o termo empregado é módulo. Isso não é verdade; o termo é driver é empregado tanto no Linux quanto em qualquer sistema operacional. A diferença é aonde o driver se localiza, se dentro ou fora do kernel.

 

Fonte da imagem: Distributed Networks.

 Essa foi a melhor imagem ilustrando o kernel modular que encontrei na internet já que não sou bom para desenhos. Caso você seja bom desenhista e quiser me mandar a sua arte, eu agradeço pela sua contribuição uma vez que esse é um dos meus artigos mais acessados.

 Muitos afirmam que o kernel Linux é monolítico, e isso não é necessariamente verdade como também não é necessariamente mentira. Até mais ou menos 1995, o kernel Linux era realmente monolítico, até que nessa época introduziram o recurso Loadable Kernel Modules (LKMs) que permite ao Linux a flexibilidade de ser tanto monolítico (drivers dentro do kernel) quanto modular.

Kernel monolítivo vs kernel modular

 Ambos os modelos possuem vantagens e desvantagens. O kernel monolítico possui a vantagem de proporcionar melhor desempenho e melhor segurança ao sistema devido seus recursos e driver residirem dentro do próprio kernel (built-in); porém, esses recursos e drivers estarão sempre em execução mesmo quando não forem necessários consumindo recurso do hardware o tempo todo. Isso em um desktop hoje em dia, onde possuímos facilmente  abundancia de processadores com muitos núcleos, ao menos 8 Gigabytes de RAM, placas mãe com altos barramentos e boas placas de vídeo, pode não parecer incomodo; mas em servidores que permanecem em funcionamento 24/7/365 e atendendo a altas demandas, remover o que não é necessários, sempre é uma boa prática a ser mantida (imagine em ambientes embarcados).

Verificando a quanto tempo o computador com o comando uptime

 O modular, desde que seus módulos são des/carregáveis dinamicamente (LKM: Loadable Kernel Modules), proporciona a vantagem de executar somente o que e quando for necessário. Isso mantem o kernel mais enxuto e faz com que mantenha os recursos computacionais o mais livre possível caso não haja necessidade de utilizá-los. É possível carregar e descarregar os módulos manualmente execução através do comando modprob:

Removendo (descarregando) três módulos do sistema

É possível listar os módulos carregados com o comando lsmod

Verificando informações sobre os módulos ppdev, snd,  e kvm

 A desvantagem dos drivers modulares é que podem apresentar menor desempenho se comparado ao monolítico (mesmo não de forma drástica) devido o kernel ter que requisitar os drivers externamente (estando dentro do kernel, a ação é mais rápida, o óbvio). O segundo ponto considerado desvantagem é a parte de segurança; o modular pode apresentar vulnerabilidade desde que ataques podem (talvez) ser explorados e realizados através de seus módulos. Os módulos podem se tornar alvos passiveis de ataques uma vez estando fora do kernel.

 Algo parecido com o kernel monolítico e o modular e que podemos usar como exemplo para fixar o entendimento são as bibliotecas. Bibliotecas podem ser divididas em dois tipos: Bibliotecas estáticas e dinamicamente.

 Bibliotecas dinâmicas são dependências de um programa que são carregados quando o programa é executado e são utilizadas enquanto o programa estiver em execução ou enquanto outro for a dependência de outro programa.

O comando ldd exibe as dependências (bibliotecas) dos programas. Aqui um exemplo de desepnencia do comando ls

Exibindo as informações e dependências do comando speedt com o comando file e o ldd

 Já bibliotecas estáticas são programas que não dependem de nenhuma biblioteca externa uma vez que as bibliotecas residem no próprio programa (assim como o kernel monolítico).

Exibindo as informações e dependencias do programa papyrus através dos comandos file e ldd. É possível notar que trata-se de um programa estaticamente linkado (bibliotecas residem dentro do próprio programa)

 Determinamos quais recursos serão incluídos no dentro do kernel Linux ou modularizados durante o processo de configuração antes de compilá-lo e instalá-lo.

Informações de escolha do kernel na parte superior do painel de configuração do kernel

Microkernel (micro-núcleo em português) ou Client-Server, ou (também) modular

 O conceito de microkernel surgiu na década de 80 visando substituir o kernel monolítico. Em seu design totalmente diferente do kernel monolítico, o microkernel trabalha com o mínimo de recursos possíveis (como o próprio nome sugere) carregando somente o que é necessário para o funcionamento do sistema operacional. Todos os demais recursos são distribuídos e administrados em forma de serviços totalmente isolados no user space; esses serviços são chamados daemons ou  servidores. Tratam-se de programas que ficam em execução em plano de fundo e cada um sendo responsável por ser administrador de uma única tarefa específica que anteriormente era administrada pelo próprio kernel.

 Nota: o Termo kernel modular também pode ser empregado para o micrkernel porém, para o microkernel, o termo é empregado para suas daemons enquanto que para o Linux é empregado para drivers externos conforme já mencionado.

(visão geral de um microkernel)

 A ideia por trás do seu modelo é proporcionar maior segurança ao sistema operacional. Caso ocorra alguma pane em um dos serviços, todo o resto do sistema operacional permanece intacto não afetando nenhum dos outros serviços. O próprio serviço afetado é restaurado pela Daemon que o administra ou até por outra daemon sem a necessidade de intervenção humana, sem perturbar todos os outros serviços em execução e, principalmente, sem que o usuário perceba.

 A outra vantagem estaria em seu código. Pelo fato desse kernel ser extremamente pequeno e trabalhar com modularizarão, acabaria se tornando mais fácil de receber manutenção do que o kernel monolítico.

Exemplo de sistemas operacionais microkernel

• Minix quase todos nós o conhecemos já que a história do Linux está vinculada a do Minix. O Minix inicialmente era voltado a didática (Linus mesmo afirma na página 87 do Livro “Só por prazer” que Andrew o truncou de propósito, de forma ruim para que estudantes pudessem descobrir os erros por conta própria), mas com o tempo, o professor Andrew Tanenbaum e sua equipe o estenderam para outras áreas.
• Mach kernel: É um microkernel que surgiu na universidade Carnegie Mellon que é utilizado pela Apple como base do MacOSX. Ocorre que se trata do mesmo microkernel utilizado pelo projeto GNU para o desenvolvimento do Hurd que na verdade seu nome é GNU Mach e não hurd; hurd é o nome do seu conjunto de daemons. O projeto GNU pediu autorização para utilizar o Mach kernel para construir seu sistema operacional como algo superior ao Unix. Esse não é o primeiro kernel adotado pelo GNU, já houve no passado uma tentativa de utilizar o kernel do sistema operacional TRIX e há planos de migração ou para algum kernel BSD ou para o L4. O sistema operacional GNU (com microkernel GNU Mach) ainda não está pronto para uso em ambiente de produção e nem há previsão de lançamento de uma versão estável.

• QNX
• Fucshia é um micrkernel que está sendo desenvolvido pelo Google, mas não indicam para qual propósito. Esse microkernel é encontrado no processo de boot do Android e na sua parte de segurança:

• HelenOS Dentre o sistemas operacionais microkernel, este é o que eu mais gosto. Surgiu na universidade da Charles, localizada em Praga, capital da Republica Tcheca (na mesma cidade onde o Evangelista Jan Hus da Dinamarca foi queimado vivo pela igreja católica). Baseado no microkernel SPARTAN escrito por Jakub Jermář, é um sistema operacional POSIX-similar projetado do zero, de código aberto, multiservidores (daemons que separam e isolam tarefas no user space como: Naming service, VFS, file system drivers, Location service, device drivers, network layers, graphics stack layers, etc) e desenvolvido para propósito geral. É utilizado como uma plataforma para aprendizado escolar no curso de sistemas operacionais, como hobby, mas também visam mais duas áreas que pretendem ocupar que seriam criar um sistema operacional totalmente utilizável em algumas tarefas do dia a dia (como servidor, PDA ou desktop) e a outra seria se divertir. Ele não é um UNIX-like como pode ser lido clicando aqui. Eu gosto da ideia da comunidade não ter desavença com a comunidade Linux; tanto é que  estudam Linux para assim implementarem seus recursos (o HelenOS possui Grub, initrd, Ext4 e caracteristicas do systemd e que vale nota de que são todos feitos do zero).

Linux VS HelenOS? NÃO! Linux E HelenOS.

• L4 É um microkernel escrito do zero, foi criado visando a melhoria de desempenho dos sistemas microkernel. Existem alguns sistemas baseados nesse microkernel; até mesmo um port do Linux para a API do L4 µ-kernel, chamado L4Linux. Existem também algumas implementações desse microkernel, o Code Zero (https://github.com/jserv/codezero) foi o primeiro que eu conheci dessa família.
• sel4 é um microkernel da família do L4 que tem como objetivo trabalhar no desempenho do microkernel em paralelo com a segurança. O sel4 utiliza como biblioteca um fork da musl.
• F9 inspirado na família L4.
• MonaOS é um sistema operacional livre que possui micro kernel pequeno (kernel do tamando de 132KB), novo e rápido; escrito em C++. O sistema não é nem POSIX nem um clone Windows. Está sob a licença MIT e roda em processadores Intel IA32.
• mikro-SINA desenvolvido na Alemanha e descontinuado em 2004.
• TUDOS
• Helios que é um experimental inspirado no seL4 e escrito na linguagem Hare. Não confunda o microkernel Helios o com Unix-like Helios da década de 90 ou com o sistema operacional Helios voltado a embarcados (15/01/2024). O Helios está sendo substituído pelo microkenrel experimentaç hermes como descrito pelo autor que ele está remodelando seu microkernel do zero (12/01/2026).
• CHORUS que é um microkernel realtime.

Quer saber mais sobre Microkernel? acesse esse link.

Kernel monolítico X microkernel

 Muito se tem discutido quando o assunto é kernel monolítico vs microkernel. Do lado do microkernel alegam que o modelo monolítico é obsoleto, possui desvantagens de ser vulnerável, não ser portável, seu código fonte pode se tornar enorme e ter menor desempenho. Mas essas afirmações ainda são teorias; na prática, é difícil afirmar que isso e fato. Na verdade é difícil ter um sistema operacional microkernel em ambiente de produção.

 Houve até mesmo uma discussão travada entre Linus e Adrew sobre o assunto. Até o Ken Tompson participou do debate afirmando que é mais fácil implementação do modelo monolítico. Linus concorda que, de um ponto de vista teórico e estético, o microkernel é melhor e  o Linux perde, porém o fato de ser microkernel não é o único critério a se analisar um bom sistema. Foi discutido até mesmo na questão da portabilidade. Particularmente, eu sou mais da ideia de que, se há algo que provoque alguma pane em um dos serviços, que seja corrigido o que está provocando a pane no serviço do que outro serviço o venha a reiniciar.

Problemas e criticas a respeito do microkernel

 O primeiro problema é que esse conceito ainda é apenas teórico. Dificilmente encontramos um sistema operacional microkernel sendo utilizado em ambiente de produção. Pode ser que encontramos sendo utilizado para propósitos bem específicos, porém não para propósito geral como é o caso do Linux, dos BSDs e do Windows.

 O segundo problema é que, ao invés de seu código ter se tonado MUITO MAIS fácil de manter como esperado, acabou foi se tornando algo EXTREMAMENTE COMPLEXO devido o seu uso de daemons como processos independentes. Adicionar um novo recurso ou corrigir um bug em um microkernel torna-se uma tarefa desgastante. É comum por exemplo não saber quando uma daemon se comunicou com a outra e dificilmente conseguem encontrar uma solução para isso....

 Pegando uma ilustração do filme Transformers: A Era da Extinção quando resolvem utilizar o protótipo Galvatron (Megatron) para perseguir os Autobots. Perguntado ao operador se ele controlava a máquina, o operador respondeu: "A maior parte." e durante a perseguição, Galvatron sai de seu controle atacando a população. Basicamente isso ocorre com os sistemas microkernel, as coisas podem sair do nosso controle. Para solucionar esse problema, o sistema operacional HelenOS está implementando várias técnicas do systemd a seu init system:

A adocção de conceitos do systemd pelo HelenOS pode ser lido clicando aqui.

 E aqui surge o terceiro problema. Focaram tanto em seu conceito de processos independentes, isolamento do kernel que a parte de recursos acaba ficando deficiente. Não há como dizer que isso é algo de todos os sistemas operacionais microkernel, o mundo é muito amplo para afirmar isso, mas na época mesmo da flamewar entre Linus e Andrew, Linus destacou esse problema.

Se esse fosse o único critério para "benevolência" de um kernel, você estaria certo. O que você não menciona é que o minix não faz a coisa do micro-kernel muito bem, e possui problemas com multitarefa real (no kernel). Se eu tivesse feito um OS que tivesses problemas com um sistema de arquivos multithreading, eu não seria tão rápido em condenar os outros: De fato, eu faria o possível para que os outros se esquecessem do fiasco.

 Uma critica que tenho a respeito do microkernel é... para que daemon para o sistema arquivos e daemon para memória sendo que tratam de recursos essenciais para manter o sistema operacional em funcionamento o tempo todo? No caso do sistema de arquivos por exemplo, se a intenção é reiniciar seu serviço caso ocorra uma pane, acho muito mais interessante o sistema de arquivos possuir o recurso de self-healing assim como  HAMMER/2 do DragonflyBSD e o ZFS do Solaris (aqui temos dois casos no mundo real provando que isso funciona) ao invés de uma daemon ter que fazer o serviço:

HAMMER file system que fica disponível imediatamente após uma quebra. Não há necessidade de uso do fsck para repará-lo.

 Tratando do tema de reiniciar o serviço no caso de ocorrer alguma pane, esse não é um recurso exclusivo dos sistemas operacionais microkernel. sistemas operacionais de kernel monolítico podem possuir essa característica. O systemd por exemplo, init system exclusiva do Linux, possui tal recurso. Conferindo a imagem abaixo, analisamos o o arquivo unit do serviço de impressão cups (sigla de Common Unix Print System). Em [Service] temos a opção Restart=on-failure. Essa opção realiza exatamente a o mesmo propósito que o microkernel se propõe a fazer....

Recurso do systemd para auto-reinicialização de serviços caso ocorra algum erro.

Quebrando o mito sobre o kernel monolítico

 Aproveitando que abordei sobre unit e init system, vamos retomar a parte como o kernel monolítico funciona. Geralmente é dito pelos defensores do microkernel que o kernel monolítico é que realiza todas as tarefas; isso não é totalmente verdade. Na verdade o kernel monolítico não realiza todas as funções. Como descrito na própria LPI, apesar do sistema operacional Linux ser de kernel monolítico, muitos aspectos de baixo nível do sistema operacional são efetuados por daemons. O que é um recurso comum seguindo os princípios do design do Unix que é exatamente o emprego de processos separados para controlar funções distintas do sistema operacional.

 De acordo com a especificação POSIX, o primeiro programa carregado pelo kernel após o processo de boot é chamado init. O init (ou também conhecido pelos termos init system ou daemon init) sempre recebo o PID de número 1 (um) e é inalterável. Enquanto o kernel é responsável pelo controle de recursos do sistema operacional, o init system é responsável pelo controle de todos os processos (observação: o kernel possui threads e não processos).

Clique aqui e saiba mais sobre init systems

Repare o PID (primeira coluna) do systemd (primeira linha) que é de muitos init systems disponíveis para Linux.

Através do comando pstree é possível visualizar melhor a organização dos processos em árvore e que o init system (realçado de amarelo e em negrito) sempre no topo.

 A imagem abaixo ilustra muito bem como é o real funcionamento do sistema operacional de kernel monolítico; o sistema operacional é dividido entre kernel space e user space e ambos funcionam de forma isoladas um do outro. O kernel space (espaço do kernel) é o espaço reservado unicamente para o kernel; já no user space temos bibliotecas, o init system, módulos (sim, módulos que não estão no kernel são executados isolados no user space) programas:

Esquema de funcionamento do sistema operacional monolítico.

  O systemd introduziu o conceito de system layer onde vários desses serviços são administrados pela camada system agregado maior isolamento:

Esquema de funcionamento do Linux com o systemd

 Alguns anos atrás, quando criei a série A pior história sobre Linux que já ouvi aproveitei para quebrar um mito a respeito do kernel monolítico com mais detalhes:

Sistemas operacionais de kernel hibrido

 Entre o kernel monolítico e o microkernel existe kernel híbrido que é uma junção de recursos dos dois modelos. A ideia é que se obtenha o desempenho do kernel monolítico e a segurança do microkernel. Esse termo foi cunhado por Linus torvalds que tem dito que a questão de kernel híbrido é apenas markting.

 Dentre os sistemas de kernel híbrido, cito os de meu conhecimento:

• Mac OSX: Esse foi o primeiro sistema kernel hibrido que conheci. Seu kernel (Darwin) é uma hibridação do microkernel Mach e do kernel monolítico FreeBSD, 4.4BSD-Lite2 e NetBSD. Antigamente seu kernel era chamado de Xinu (uma hibridação do 4.3BSD com o Mach 2.5) quando a Next, empresa que Steve jobs fundou ao ser demitido da Apple, possuía o sistema NextStep. Quando a Apple estava à beira da falência, decidiu em uma ultima tentativa, inovar comprando a Next (para obter o NextStep, já que o Mac Os stava uma m... Era mais fácil comprar um OS do que escrever outro do zero). Disso surgiu a união do Next com a interface do Mac OS.
• Haiku Esse eu sei que é desenvolvido por antigos desenvolvedores do BeOs, mas a informação real de que ele é um sistema de kernel hibrido foi difícil de encontrar. Só vi treta no site do sistema e desencanei de pesquisar.
• Plan9 Esse é um sistema voltados a pesquisa. Foi desenvolvido por Ken Thompson, criador do Unix e da linguagem C (na época B), Rob Pike, Dave Presotto, and Phil Winterbottom. É um sistema em que cada processo é executado em seu próprio name space mutável.
• DragonflyBSD? NÃO. Esse foi considerado no livro da Wikipedia como o primeiro sistema operacional non-Mach que possui o kernel hibrido. Mas em um post no grupo oficial do sistema em uma rede social, eu encontrei a informação de que na verdade trata-se de kernel monolítico.

Informação no livro da Wikipedia

  

Informação nas redes sociais

 O que me fez pesquisar melhor sobre o sistema e foi então que entrei em contato com Matt Dillon, criador do DragonflyBSD, que me afirmou que o Dragonfly é tão monolítico quando o kernel Linux e o kernel FreeBSD:

Resposta de Matt Dillon

 O que o DragonflyBSD faz é gerar através do seu kernel, um kernel virtual que trata o processo dentro de uma vmspace. Quando o vkernel termina o processo, o kernel real destrói o vmspace com o  seu processo e o vkernel.

 O NTkernel (utilizado no Windows NT, 2000, XP, Vista e Windows 7) é um kernel hibrido. Francamente? Achei muito difícil encontrar as informações deste tipo sobre o Windows. Por fim só consegui alguma informação sobre o kernel NT no web site do ReactOS [se alguém tiver alguma informação, posta aí :) ]:

 Um fato curioso sobre o termo kernel hibrido é que  hoje ele não é aplicado somente a kernels que mesclam os modelos monolítico e microkernel. Em um documento da LPI 201, esse termo passou a ser empregado para kernel monolítico que possui recurso de modularização.

Passe o cursor para ler a tradução do ponto selecionado.

 Existem também o nanokernel que é muito mais simples que o microkernel e o exokernel que, diferente dos sistemas operacionais tradicionais (tanto de kernel monolitico quanto microkernel e kernel hibrido) em que programas e bibliotecas requisitam acesso ao kernel para que possa ter acesso ao hardware, o exokernel concede acesso direto ao hardware para os programas e bibliotecas. A ideia é simples, eliminar camadas para acelerar o melhor aproveitamento de desempenho do hardware.

    Dentre a família de sistemas operacionais exokernel podemos destacar os unikernel (também conhecido como library operating system) que permite gerar imagens tão pequenas (as vezes, imagens de apenas 400k) que hoje está tomando lugar na computação em nuvem como é o caso do OSv. A imagem é gerada para um propósito bem específico e com isso, há melhor aproveitamento de hardware. A ideia é bem simples; os sistemas operacionais que utilizamos atualmente já veem acompanhado com muitos de programas que se tornam desnecessários para certos serviços que realizamos e, mesmo que os eliminamos, os sistemas ainda acabam por ter uma variedade de bibliotecas desnecessárias. A ideia do unikernel é eliminar tudo o que não for desnecessário.

Ilustração do funcionamento do unikernel

 E há ainda mais um modelo fora da nossa lista, que é o sistema operacional multi-kernel. Um exemplo de sistema operacional multikernel é o Barrelfish que é um sistema operacional de pesquisa e foi inicialmente financiado pela Microsoft em 2009. Hoje conta com o apoio de muitas outras empresas.

 Bom, já deu para perceber que a nossa lista se estende a bem mais do que 4 ou 5 modelos kernel, mas apesar do principio básico serem 4, a partir daí começam a se estender a muitos outros modelos. O mundo dos sistemas operacionais são muito abrangentes, mas isso é uma questão de pesquisas a serem realizadas. Incentivo a todos a fazerem isso para aprofundarem seus conhecimentos.

Estou deixando alguns links para poderem acompanhar as comparações entre os sistemas:

• https://en.wikipedia.org/wiki/Comparison_of_operating_system_kernels
• https://en.wikipedia.org/wiki/Comparison_of_open-source_operating_systems
• http://www.brendangregg.com/blog/2015-03-17/linux-performance-analysis-perf-tools.html
• critica do Linus sobre kernel hibrido

Leia também "3 SISTEMAS OPERACIONAIS QUE NÃO SÃO ESCRITOS NA LINGUAGEM C"

Diferentes arquiteturas de processadores

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

E não esqueçam de conferir também o meu mini curso de atributos no Linux