“Aquele que empunhar este martelo, se for digno, possuirá o poder do DragonflyBSD”.
Durante o vídeo sobre FreeBSD ser melhor que Linux, surgiu a pergunta se o HAMMER 2 é um sistema de arquivos melhor que o ZFS, o Btrfse o Ext4. Respondendo a essa pergunta, decidi elaborar um vídeo que assistirão aqui mesmo neste artigo.
"O HAMMER filesystem, padrão do DragonFly BSD, é o sistema de arquivos mais poderoso e mais confiável disponível em qualquer sistema operacional. Ele pode lidar com arquivos acima de um exabyte (ou 104876 tebibytes) e pode automaticamente se recuperar sem a necessidade da execução do fsck."
Apesar de um sistema de arquivos realmente muito bom, desenvolvido e implementado em um perídio de tempo muito curto e com tamanha quantidade de recursos interessantes, eu honestamente não teria tamanha ousadia em dizer o mais poderoso e mais confiável. Apesar disso, não posso deixar de dizer que, sim, é muito poderoso e muito confiável.
Trata-se de casos das empresas HIFX IT and Media Services PVT.LTD, Virtual Training Company e IPLOTZ que fazem uso do DragonflyBSD como servidor de arquivos Samba para realizar os backups de seus snapshots. Nesse link é possível conferir o cenário das empresas, o planejamento, a implantação e o resultado final que é o print abaixo:
Resultado da implantação do servidor de Backup em tempo real para cliente Microsoft Windows, Linux, Bsd e Mac Os X.
OK, mostrado o máximo de qualidade e de sucesso do HAMMER /2, agora vamos ao cerne da questão. Para isso, elaborei um vídeo com informações interessantes. Confiram aí:
Agradeço ao Anderson Rincon por ter revisado o texto deste artigo.
No dia 10 de Janeiro foi lançado o DragonFlyBSD 6.2.1. A versão 6.2.0 acabou passando batido pela própria equipe do projeto e não teve seu lançamento; mas a versão 6.2.1 traz suporte a hardware para hypervisorstipo-2 com NVMM, um driver amdgpu, habilidade experimental para montar remotamente volumes HAMMER2 e outras mudanças que podem ser conferidas aqui.
E por que depois de tanto tempo que eu resolvi escrever este artigo sobre o seu lançamento? É que o projeto foi convidado para apresentar o sistema operacional no evento SEMI-Bug que está previsto para o dia 19 de Abril.
A verdade é que não há melhor ou pior! Cada um é bom nas áreas em que se especializaram ou que atuam (nada impedindo-os que cada um as ampliem). Recentemente postaram em um grupo em uma rede social tal pergunta, então peguei exatamente este título escrito na rede social e resolvi fazer uma analise sobre os BSDs para poder responder sobre o assunto, pois não somos xiitas ao ponto de não utilizar e/ou testar outros sistemas operacionais (mas talvez não seja um assunto que eu queira mais abordar. Quero focar mais em Linux desde que já expliquei sobre esse assunto anteriormente no artigo sobre as diferenças entre os dois sistemas que traduzi do distrowatch). Alias, uma das qualidades que Linux proporciona aos seus usuários é o amplo conhecimento (mais uma das liberdades que existem dentro do mundo Linux e que muitos exploram pouco): Outras arquiteturas, que dentro do próprio kernel é possível notar quantas arquiteturas são suportadas (e tem gente ainda achando que Linux só é para servidores ou que só exista x86...), outros filesystems (por que para técnico em Windows é assim, tudo para eles é partição: Partição FAT, partição NTFS... Conhecimento proporcional = 0; por que partições e filesystems são coisas totalmente diferentes), outros sistemas operacionais, outras licenças.
Arquiteturas dentro do kernel Linux
Filesystem no kernel Linux.
Não vou narrar aqui a história do BSD, por que já a abordei inesperadamente no vídeo "Não viva de boatos"; aconselho a dar uma olhadinha logo abaixo:
Mas uma coisa que vale a pena mencionar é que BSD é o nome dos sistemas derivados desta família, da licença e do próprio layout criado para o BSD. Layout B
Já que teve gente quem criticasse a imagem que aqui utilizei do Porteus Linux para mostrar o Layout BSD (que no Layout SystemV é diferente, utilizando /etc/init.d/serviço) fazendo a afirmação de que eu mencionei que o runlevels do BSDs vão de 0-6 (o que não afirmei em momento algum) então estou postando hoje (lembrando, este artigo foi publicado no dia 26/02/2015 e estou inserido este parágrafo no dia 03/03/2015 ) o manual do Arch Linux que eu já havia postado no vídeo "Não viva de boatos" logo acima, pois assim como o Slackware, essa é outra distribuição que utiliza esse layout para controlar seus serviços. Caso queiram, verifiquem na página 4 para entenderem a diferença entre os dois padrões.
De opinião própria, o que cada um oferece de melhor seria que o Linux é muito interessante na parte de multi-processamento (invejável), desempenho (invejável também) e virtualização. Enquanto os BSDs são muito bons em Firewall (o firewall do Linux, no caso o Netfilter, também é muito bom, porém os BSDs possuem o firewall mais poderoso do mundo o Package Filter).
Assim como no mundo Linux, que possui quatro distribuições como principais (apesar que o Arch anda ganhando muita notoriedade): Slackware (forte no aprendizado de Linux bem na essência. Nesse aspecto o LFS também merece esse crédito), Debian (focado na segurança e estabilidade), Redhat (ótimo em soluções empresariais) e Gentoo (forte em otimização de desempenho); os BSDs também possuem quatro principais e cada uma delas voltada á um foco principal. Todas as demais (digamos assim) distribuições BSDs derivam dessas quatro:
Beastie
FreeBSD: focada em robustez e eficiência tanto para ambientes tanto de servidores quanto para desktop (hoje portado para várias arquiteturas). Seu lema é "The power to serve" (O poder para servir"). Seu mascote é um demônio chamado Beastie. Esse é o BSD mais utilizado entre todos os outros.
NetBSD: Focada em rodar no maior número de plataformas possíveis tornando-o o OS mais portável do planeta; tanto que seu lema é “Of course it runs NetBSD”(É claro que roda NetBSD!). Roda em tudo essa bagaça.
OpenBSD: focado primariamente em segurança e nos tópicos relacionados (forte integração de segurança, criptografia a um nível TOP LEVEL. Esse é o sistema operacional mais seguro do mundo). Seu mascote é um peixe que mais parece... com... um baiacu.
DragonFlyBSD Com muitos conceitos inspirados do AmigaOS (que, alias, Mathhew Dillon é conhecido por criar o compilador C DICE no Amiga) e com recursos similares ao do Linux, é focado em proporcionar uma infraestrutura SMP compatível que seja fácil de entender, manter e de desenvolver. Esse foi o que mais utilizei, Então, vou basear a minha experiência nele. Gravei a imagem iso em um pendrive com um simples comando dd conforme descreve no meu manual Caixa de Ferramentas do Unix, criptografa tudo no momento da instalação (dispositivo, filesystem, home... até cansa na hora de bootar e ter que ficar digitando senha, mas garante ótima segurança), utiliza os filesystems UFS ou HAMMER (H.A.M.M.E.R foi desenvolvido pelo próprio Matt Dillon para suportar HDs de 4 teras ou até storages acima de um exabyte e tem uma pancada de recursos), vem no caso como o FreeBSD (sem interface gráfica). Bom, gostei dele até demais. Uma coisa que Matt Dillon merece crédito foi o fato de ter descoberto bug no processador da AMD onde foi até convocado pela própria AMD para ajudar na correção de tal erro.
Cada um desses quatro surgiram de alguma forma como fork: o FreeBSD e o NetBSD como fork do 386BSD iniciado como patchkit em 1993; depois o OpenBSD como fork do NetBSD em 1995 devido intrigas internas entre os desenvolvedores; e depois o DragonFlyBSD como fork do FreeBSD em 2003 quando o desenvolvedor do FreeBSD, Matt Dillon entrou em desacordo com ao comunidade do FreeBSD ao propôr melhorias na parte de clustering no kernel entre outras coisas. Alias, essa é uma coisa que não concordo quando foi dito em outro artigo que traduzi sobre a definição Unix-Like onde afirmaram que os BSDs são clones do UNIX.
Principais distribuições BSD
Os BSDs estão sob a licença chamada... BSD em que reza mais ou menos o seguinte: "Do whatever the hell you want with the code, just give us credit for writing it" (Faça seja o que for que quiser fazer com o código, dê-nos apenas crédito por escrevê-lo). Caso queiram saber mais sobre a diferença entre as licenças, sugiro a leitura do artigo "Definição sobre software livre".
Todos os BSDs se preocupam com segurança (apesar que cada um tem um nível diferente do outro). Muitos desenvolvedores trabalham em mais de um sistema.
Diferença de segurança entre OpenBSD e FreeBSD
Os BSDs possuem uma família de grande também (alguns descontinuados, outros forks e assim segue) que podem ser acompanhados no wikipedia.
Moral da história, é que eu acho que os dois sistemas devem sempre andar em harmonia e não ficar com diferenças que geram intrigas (não gosto dessas brigas que não levam a nada). Acho que ambos os sistemas deveriam ser mais unidos; ambos cresceriam até mais rápido ao meu ver.
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.
(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.
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
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.
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.
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.
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.
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:
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).
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:
![> MINIX é um sistema baseado no microkernel. [excluído, mas não ao ponto de perder o diálogo] LINUX é um sistema no estílo monolitico. Se esse fosse o único critério para "benevolência" de um kernel, você estária certo. O que você não menciona é que o minis 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. [Sim, eu sei que há multithreading hacks para o minix, mas elas são hacks, e bruce evans me conta que há muitas race conditions ]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6if058iVn-pB1Pq391p1FyhK8FcXL4i2-jnOGjtHewGdc755htGBBSbt_z5JEgFBZ35ehDE8xWOteq41CHeqZdnXnQ7fthmQXK7rt2eTV6gs_xxPlwC6RnNxtJYmLYt4LUn5TTjJBzEk/s1600/multithread+filesystem.PNG "> MINIX é um sistema baseado no microkernel. [excluído, mas não ao ponto de perder o diálogo] LINUX é um sistema no estílo monolitico. RESPOSTA DE LLINUX: Se esse fosse o único critério para \"benevolência\" de um kernel, você estária certo. O que você não menciona é que o minis 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. [Sim, eu sei que há multithreading hacks para o minix, mas elas são hacks, e bruce evans me conta que há muitas race conditions ]")
