Daemons, daemons e mais daemons (init).

    No vídeo "O que é daemon init?" eu mencionei que existem várias daemons init (ou init systems) diferentes disponíveis. porém mencionei somente as (digamos) mais populares como o rc (run command) do Unix mais ou menos na versão 10 e que foi herdado pelos BSDs e pelo slackware, o SystemV (ou sysvinit que introduziu o conceito de runlevels que  é uma especificação declarativa de serviço de sistema). O holandês Miquel van Smoorenburg é o autor da versão do sysvinit para Linux. Miquel fez também o primeiro port do Debian para a arquitetura Alpha e tem como símbolo um Tux bebinho de tudo).

Tux de Miguel Van Smoorenburg

O launchd do Mac OS X, o OpenRC originado no Gentoo, o Upstart originado no Ubuntu e o systemd originado no Fedora. O vídeo pode ser conferido logo abaixo:

    Então por que não debater sobre outros init systems diferentes? Vale começar pelo NetBSD que, como mencionei no vídeo, o NetBSD migrou da init BSD para uma versão da SystemV.

    O Solaris possui o SMF (Service Management Facility = Facilidade de Gerenciamento de Serviço que também é uma das inspirações para a criação do systemd). Esse init system faz uso de arquivos XML ao invés de init scripts, é utilizado no IllumOS (já que é um fork do antigo OpenSolaris) e no OpenIndiana que é uma distribuição derivada do IllumOS. Agora, vamos a mais um monte de outros init systems.

Plan9 rc

 Quero começar com rc específico do Plan9 (não confunda com o rc dos BSDs e do Slackware) que é um shell que soluciona o problema de white space que ocorrem em outros shell no padrão POSIX (como o bash). O que acontece é que os scripts de outros shells quebram caso os nomes dos arquivos possuam espaço como no exemplo:

for i in *.jpg; do

cp $i /tmp

done

 Já o plan9 rc lida com esse problema utilizando um recurso chamado Free Carets inserindo o operador ^ automaticamente entre as palavras. O Plan9 rc possui sintax diferente mas um exemplo de como ele soluciona o problema pode ser conferido abaixo:

for (i in *.jpg) {

cp $i images

}

 Outros shells como o fish e o zsh também possuem respostas para esse problema porem o rc faz isso de forma mais simples. O plan9 rc está disponível no plan9port (port do user space do plan9 para os Unix) e existem re-implementações do plan9 rc como a re-implementação independente do Plan 9 rc de 1992 para Unix e também a uma iplementação na linguagem Hare.

Depinit 

    É um init system alternativo que incorpora as ideias da sysVinit, do simpleinit, do daemontools e do make que visa cuidar de processo paralelo (assim como o systemd e o launchd), dependências, roll-back, pipelines, melhorias no signaling e desmontar filesystems no desligamento (assim como o systemd possui recurso parecido). Falando em desmontar no desligamento, no dia 20 de agosto foi adicionado ao Systemd a ferramenta para montar filesystems. O interessante é que o Depinit possui comando parecido com o systemctl do systemd chamado depinctl. O Depinit, está sob licença GPLv2 e ainda está em fase experimental sendo disponível para Linux e FreeBSD. Sua ultima versão foi lançada em maio de 2014 (a versão 0.1.4).

InitNG 

    Tem como objetivo iniciar os processos em paralelo para reduzir o tempo de boot (assim como o systemd e o launchd... Mas já foi dito isso). Algo que foi inspirado no Mac OS X Tiger. Nele tudo é chamado em uma única ferramenta para gerenciar ciclo de vida ao invés de chamar múltiplos scripts que duplicam comportamentos similares. Li a algum tempo atras que a daemon InitNG tornou o Linux mais rápido (notaram como até mesmo a daemon init ou as outras daemons influenciam no desempenho do sistema operacional e não somente um filesystem? O InitNG está sob licença GPLv3 e recebeu uma pequena atualização há dois anos.

Runit 

    É um init Unix Cross-platform com supervisão de serviço operando em três estágios obtidos em /etc/runit. Ela está disponível para Linux, FreeBSD, Mac OS X e Solaris e pode ser facilmente adaptada para outros Unixes. Os direitos autorais são reservados ao desenvolvedor da daemon. Hoje essa daemon é adotada pela distribuição Void Linux e tendo também suporte do Busybox.

 É possível utilizar runit sem substituir o atual init system que estiver utilizando em sua distribuição simplesmente executando o stage 2 do runit como um serviço do seu atual init.

eINIT 

    É uma alternativa a implementação do /sbin/init para Linux e FreeBSD, mas parece que anda em decadência. Apesar disso, é um bom init para dispositivos embarcados e é bem modular. possui runlevels nomeados modes que é descrito em um arquivo XML a parece-se um pouco com a runlevel do Gentoo.

Pardus 

    É a daemon init da distribuição Turka chamada Pardus. É uma versão paga do Linux pelo que me lembro de ter visto anos atrás. É difícil conseguir informações nesse site desde que não possui versão inglesa (parece que os caras não querem mais nenhum outro país por lá rsrs. Essa seria uma boa distribuição para entrar para os "50 lugares onde Linux está rodando e você nem faz ideia), mas essa init trabalha com um subsistema init chamada Mudur que é escrito em python e um sistema de gerenciamento de configuração chamado Çomar.

Epoch 

    É um init system para Linux na versão do kernel 2.6. Foi projetado tendo como foco a facilidade na configuração e a não intromissão, ser pequeno para funcionar tanto em distribuições grandes e minimas. Esse init não possui dependências externas além da biblioteca C, dos pthreads do kernel e sugerido um /bin/sh funcional. Ele possui um sistema de logs para boot, runlevels em ASCII, um único arquivo de configuração conveniente; recursos automáticos como hostname e montagem do sistema de arquivos virtual (como o /proc) e vários outros recursos. Vale a pena conhecer esse init system:

• Epoch no Freshmeat
• Github do Epoch
• FAQ do Epoch

minit

    É uma daemon (ainda em versão beta) feita pelo alemão Felix von Leitner, mesmo criador da dietlibc e do embutils. Além de visar ser minuscula (característica típica do Felix e que faz isso muito bem) também visa corrigir alguns erros cometidos pelos init systems tradicionais no Linux. Se quiser saber mais sobre a diet libc e do embutils, assista o vídeo abaixo:

 Como descrito  no documento de sua palestra na Linux Kongress de 2004 que:

• O processo de boot das típicas distribuições Linux é muito sofrido
• Se um boot script falhar, todo o processo de boot é interrompido
• Se um serviço for interrompido via o comando kill, ele não é automaticamente reiniciado (se tornando um processo zumbi)
• O script de shutdown não sabe qual o PID da daemon (modos de falhas horríveis onde você acidentalmente mata o processo errado)
• E a falta de flexibilidade (iniciar mais um ou um serviço a menos?).

 No minit, cada serviço possui seu próprio diretório dentro de /etc/minit contendo dependências e dentre outros recursos. Dentre os problemas a serem solucionados pelo minit estava o de reduzir o período de downtime (que é também uma das ideias do systemd).

cinit

cinit é um init system com recursos de dependência e suporte a perfil que foi baseado no design no minit. Devido o minit não possuir suporte a dependências reais (o que leva a você não saber se o serviço que você depende foi realmente iniciado) e seu conceito de dependência ser lento, o suíço Nico Schottelius para suprir estas necessidade.

 O cinit possui características semelhantes ao systemd: parallel execution; profile support que além de serem fáceis de criar você ainda pode especificar quais serviços iniciar (o que me lembra o conceito de units do systemd).

sinit (11/05/2022)

 sinit (suckless_init) é um init system baseado no minimal init (clique aqui para conferir) criado por Rich Felker (criador da bliblioteca Musl muito abordada aqui no blog). Foi criado com a intenção de integra-la ao Busybox em um experimento (confira aqui). O sinit está sob a MIT/X Consortium License e existe um manual introdutório ao sinit que pode ser conferido aqui.

dinit

 dinit é desenvolvido por Davin McCall, um ex contribuidor do kernel Linux e do Mesa driver. Assim como cinit e o runit, o dinit foi desenvolvido para ser integrado a outros ao invés de substituí-los (apesar que runit ainda permite substituir outros init systems). dinit é utilizado no Chimera Linux e é uma das várias escolhas do Artix Linux.

jinit

    Também desenvolvida na Alemanha, trabalha utilizando seu próprio filesystem baseado em esquema de serviço e é escrita em C++. Ainda não é muito bem testada.

S6

 s6 é descrito como um pequeno conjunto de programas para UNIX, projetado para permitir supervisão de processos (a.k.a service supervision), na linha do daemontools em conjunto com runit, assim como várias operações em processos e daemons. As ferramentas do s6 são independentes que podem ser utilizadas com ou sem framework e podem ser agrupadas.

 O s6 é o init system padrão da distribuição Glaucus. A skarnet disponibiliza também o s6-linux-utils que faz parte do ecossistema s6 e é utilizada para criar init system baseado no s6 no kernel Linux. É possível também ter um s6-linux-utils multicall.

66

 Foi desenvolvido para a distribuição ObaRun, um fork da distribuição Arch desenvolvida por um anônimo como uma alternativa ao systemd. Na verdade o 66 é um fornecedor de gerenciamento de serviços para o s6 e não um init system em si.

rinit

 Esse é um init e gerenciador de serviços escrito na linguagem Rust por Danilo Spinella, um desenvolvedor italiano da Suse inspirando-se no 66, no s6 (já mencionado anteriormente) e no daemontools mencionado a seguir. Ainda é um trabalho em progresso e o autor descreve que você o utiliza por conta e risco. Inicialmente se chamava tt e era escrito em C++. Possui uma sintaxe muito parecida com a do systemd. Está sob licença GPL3+, o que eu acho uma bela de uma burrice.

tt

 Também desenvolvido por Danilo Spinella o tt é um gerenciador de serviço init também inspirado no 66, s6 e no deamontools, para substituir o systemd mas oferecendo melhor base de código que o 66. A ideia é realmente reescrever o 66 já que este possui muitos bugs difíceis de serem corrigidos. A princípio parece que iria ser escrito na linguagem porém, em seu github vamos que é escrito na linguagem C++.   

daemontools e nosh

As próximas não são init systems. Na verdade se tratam de ferramentas que servem como auxiliares de init systems. A daemontools foi desenvolvida por Dan Bernstein como uma coleção de ferramentas para o gerenciamento de serviços de sistemas operacionais da família Unix (eles iniciam o serviço e o reiniciam caso ele morra. Parecido com o que temos no systemd). Esta ferramenta é fortemente utilizada em conjunto com o runit e o minit. Do daemontools surgiu um derivado chamado daemontools-encore que adiciona várias melhorias e mantendo compatibilidade entre ambos.

 Nesse meio ainda temos o nosh que tem a mesma função que o daemontools. nosh foi desenvolvido originalmente para suprir a falta de opções que os BSDs não possui como as do launchd, systemd e do upstart. A equipe do nosh queria algo mais do que outras daemontools oferecem.

 No meio disso, parece que teremos em breve algo similar no toybox que hoje traz os comandos init e oneit.

 A ultima que eu gostaria de mencionar é a perp (abreviação de "the perpetrator"). Infelizmente, sua ultima versão foi em 2013.

sninit

 sninit é uma pequena implementação para Linux que visa ser um substituto para o systemV sendo mais limpo e mais confiável, fornecendo melhor controle de processos removendo a necessidade de init scripts. Também é menor que o systemd para distribuilções que dependam do comando systemctl. O projeto sinit foi concluído sendo agora a continuidade no minibase.

Procd

 procd é a daemon do OpenWrt sistema operacional Linux que utilizamos em nossos roteadores escrito em C. Ele mantem rastreio de processos iniciados a partir de seus init scripts (via ubus calls), e pode suprimir solicitação de inicialização/reinicialização de serviço redundante quando o ambiente de configuração não for alterado.

Conclusão

 No Linux, tudo é uma questão de escolha. Não quer utilizar uma interface gráfica, você utiliza outra; não quer utilizar um terminal, utiliza outro. O mesmo vale para sistema de arquivos, gerenciadores de pacotes tanto de baixo quanto de alto nível, empacotamentos e todos os tipos de ferramentas, inclusive init systems. Isso é OS VÁRIOS SABORES DE LINUX.

 Existe também por exemplo a Twsinit que é desenvolvido em Assembly, é bem pequena (exige somente coisa de 8k de memória) e ser uma substituição das atuais; a do Fedora chamada FCNewInit e Serel que também foca em acelerar o boot. Bom, acho que está bom o tamanho da lista. Vale mencionar (mais uma vez, assim como mencionado no vídeo "O caso Systemd") que do Systemd surgiu o fork UselessD, mas que não conseguiram atingir o seu objetivo proposto.

    Moral da história é que acelerar o boot, reduzir o shutdown melhorando assim o uptime e solucionar os problemas gerados pelos scripts já é um desejo antigo. A maioria das aqui mencionadas focaram esforços para poder trazer essas soluções. Criticar o systemd então se torna somente uma questão de birra. E no meio de um oceano repleto de init systems, o inútil debate criticando o systemd continua até hoje. Como sempre, os argumentos são os mesmo e os piores imagináveis:

 "ele não é portável", "ele é incompatível com init scripts" (o que não é verdade), "Ain, logs binários", "systemd faz muitas coisas, isso é contra a filosofia", "systemd é uma ameaça ao sistema operacional", "vou contar para a minha mãe"...

 E porque ficar com essas discussões se temos a liberdade de adotar o que quisermos? ISSO É LIBERDADE DE VERDADE. Por que o systemd deveria ser portável se outros init systems já  são? Alias por que criticar o systemd sendo que outros já tentaram implementar os mesmos recursos? Não quer utilizar o systemd? Neste artigo está um catalogo bom para você desfrutar; basta partir para os estudos.

Fico por aqui, espero ter agregado  mais conhecimento. Forte abraço e até a próxima.

 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

Lançado s6 2.7.2.0, s6-portable-utils-2.2.1.2 e s6-linux-utils-2.5.0.0

Você deve estar se perguntando o que é s6 (pronuncia-se ssix) afinal de contas? Como mencionei no ultimo vídeo que existem vários, mas VÁRIOS init systems, s6 é um deles e que inclusive não mencionei no vídeo.

s6 é desenvolvido pela skarnet com o intuito de prover um conjunto independente de diferentes ferramentas para Unixes (tal como Linux) que podem ser utilizada com ou sem framework, e que podem ser agrupadas para atingir funcionalidade poderosa com um monte pequeno de código. Existe a versão específica para Linux chamada s6-linux-init e essa não é a unica ferramenta fornecida pela Skarnet, mas focando no assunto (que é init system), no mesmo vídeo eu menciono mais algumas que estão disponíveis para Linux (e convenhamos, esse Neymar só não é mais feio por falta de espaço)

Essa semana foi lançada a versão 7.2.0 do s6 (que mantes comparatibilidade com a versão 2.7.0.0 da skalibs), a versão 2.2.1.2 do s6-portable-utils e a versão 2.5.0.0 do s6-linux-utils. Honestamente não tenho interesse em debater o que há de novo nos novos lançamento, mas eles podem ser conferidos nos links abaixo:

• https://skarnet.org/software/s6/
• git://git.skarnet.org/s6
• https://skarnet.org/software/s6-portable-utils/
• git://git.skarnet.org/s6-portable-utils
• https://skarnet.org/software/s6-linux-utils/
• git://git.skarnet.org/s6-linux-utils
• O que é daemon init?
• Daemons, daemons e mais daemons (init)
• o que são runlevels?
• Phoronix mente a respeito do systemd possuir um milhão de linhas de código?
• Linux é somente um kernel... Será mesmo?

A tragédia do systemd

systemd comentado por Beno Rice do FreeBSD

 O systemd já causa discórdia entre desenvolvedores, projetos, profissionais e usuários de Linux ( e sem necessidade, diga-se de passagem). Agora, vamos tratar desse init system de acordo com a visão de um desenvolvedor do FreeBSD. E que comecem os rumores.

CURSO DE SHELL SCRIPT DO MATEUS MÜLLER

Foi uma live muito boa onde debatemos a sua origem, de onde foi inspirado, fatos históricos, vantagens e desvantagens e o erro cometido tanto pela comunidade Linux quanto a comunidade FreeBSD.


 Mas essa não é a primeira vez que debato sobre o systemd e init systems tanto no canal e no blog. Confiram também os artigos abaixo:

• O que é daemon init?
• Daemons, daemons e mais daemons init
• O que são runlevels?
• A polemica daemon init systemd
• Thunderbolt, a nova interface de conexão de periféricos do Linux

minibase: Um outro conjunto de pequenas ferramentas para o userspace do Linux

minibase: Um conjunto de pequenas ferramentas para userspace do Linux

 Eu já apresentei vários pacotes com conjuntos de ferramentas diferentes disponíveis para Linux como o embutils de autoria do Felix Von Leitner que desenvolveu a dietlibc e que traz implementações de comandos como os do coreutils, o 9base que se trata de um port do user space do sistema operacional plan9 para os Unix, o sbase que é uma coleção de ferramentas do Unix que são facilmente portáveis para outros Unix, o ubase que é uma coleção de ferramentas similares ao util-linux porém visando ser menor, o rustcoreutils ou uutils que é uma versão de coreutils escrito na linguagem Rust por um ex desenvolvedor do Debian, o moreutils que é  coleção de ferramentas para Unix que ninguém havia pensado em desenvolver (mas que no final das contas eu também não as entendi muito bem) e o vcoreutils que é uma implementação do coreutils escrito na linguagem V além de outras ferramentas como o Busybox e o toybox que englobam vários comandos em um único binário e implementações do coreutils em outras linguagens como o nim coreutils e o golang coreutils. 

 Vejam quantas opções de pacotes existem para Linux além de outros que não possuem relação com o coreutils e possuem funções centralizadas como shadow-utils para criação de usuários de senhas, o procps para gerenciamentos de processos, ip-utils para troubleshooting com comandos como ping, o iproute2 e o net-tools para gerenciamento de redes e muitos mais. Linux não é limitado a ferramentas do GNU como a maioria de nós usuários de Linux costumamos propagar aos quatro ventos. Uma frase dita por Rob Landely que eu a adaptei e costumo adotar com frequência é que:

 "Tudo no Linux é uma questão de alternativas e escolhas. Se você não quiser utilizar o SSH, você pode utilizar o Dropbear. Se não quiser utilizar o Apache, você pode utilizar o NginX e assim por diante".

 O mesmo vale para shell, comandos, bibliotecas, compiladores, interfaces gráfica e tudo o que gira em torno o sistema operacional. É isso o que eu chamo de os vários sabores de Linux que não se trata apenas da próxima distribuição que você pretende adotar e sim de qualquer coisa que você queira utilizar no Linux. E como tudo é uma questão de escolha, o ucraniano Alex Suykov desenvolveu suas próprias ferramentas e as disponibilizou livremente sob o nome de minibase. Alex também é o autor do sninit que abordei também no artigo daemons, daemons e mais daemons init, um pequeno e estático init system para Linux.

Comandos do minibase

 O minibase serve como base de comandos para userspace do Linux para ser utilizado para bootar o sistema operacional, carregar módulos, montar partições, estabelecer conexão e fornecer serviços básicos ao ponto de poder carregar interfaces gráfica com o X ou o Wayland, permitir download de pacotes e muito mais.

 Os executáveis do minibase podem ser construídos com qualquer toolchain que constrói o kernel e são linkados estaticamente (ou seja, não necessitam de dependências externas). Seus binários são muito pequenos tendo entre 10KiB a no máximo 25KiB que o tornam confiáveis e fáceis de debugar. Está  disponível sob a licença GPLv3 (há ressalvas feitas no próprio README) para as arquiteturas x86_64 arm, aarch64, rv64, mips, mips64 e i386.

 O minibase ainda não é declarado como versão 1.0, há muito trabalho a ser feito e o autor pede para não enviarem patches ou commits. Caso queiram reportar bugs ou sugeris novas ideias, enviem solicitações.

Link para o github do minibase

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

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

Linux é somente um kernel!... Será mesmo?

O que mais se debate nas comunidades de software livre é que Linux é somente um kernel. Como mencionei vídeo, ainda afirmam que só com o kernel não fazemos nada e Linux não vive sem GNU mas que GNU vive sem Linux.

Com tanta ferramenta desenvolvida para o Linux, será que isso é realmente verdade?

Sabe o que eu achei mais legal disso tudo? É que quando eu mencionei que Debian GNU/Hurd é um projeto não oficial, brotaram os extremos defensores ultra nacionalistas GNU dizendo que quando afirmo isso eu estou desmerecendo o projeto...
Mas o que é legal mesmo é que sempre afirmaram que Linux é só um kernel, não é desmerecer o Linux... incrível isso! Não?

• De acordo com o artigo "O que é linux?" do site linux.com, um sistema operacional é abrange:
• The Bootloader (Linux tem outros além do GUB)
• The kernel: Linux é o kernel
• Daemons: No artigo "Daemos, daemons e mais daemons init" vocês podem conferir que Linux tem aos montes.
• The Shell: Apesar que Linux não possui uma própria, Bash não é a unica opção. Eu utilizo Zsh, a comunidade EMMI utiliza o fish, existe o Busybox e o Android utiliza o Toybox.
• Graphical Server: Linux tem como o Xorg, o Xfree86, o Wayland e o Mir.
• Desktop Environment: Linux tem aos montes.
• Applications: O que não falta para Linux

Então, afirmar que Linux é somente um kernel, é uma afirmação muito fraca para ficar defendendo ideologias.

Mais uma coisa, se alguém quiser reclamar que estou desmerecendo o GNU/Hurd, aconcelho a ir reclamar com a comunidade Debian, não comigo. Eu relato os fatos:

• https://www.debian.org/ports/hurd/
• https://www.debian.org/ports/hurd/hurd-cd.pt.html

Phoronix mente a respeito do systemd possuir um milhão de linhas de código?

No dia 02/01/2017 o site Phoronix publicou que o systemd VIOLOU o total um milhão de linhas de código. SIM! escreveu VIOLOU (BREACHED) e não OBTEVE ou ALCANÇOU (REACHED). Ok,pode ter sido somente um erro de digitação.

systemd é um init system que foi desenvolvido inicialmente por Lennart para substituir a mais conhecida SystemV e hoje conta com uma boa equipe envolvendo comunidades como Debian, Arch Linux entre outras.

Para saber mais sobre o que é init system, confiram o vídeo abaixo:

Neste artigo descreve a quantidade de commits no git, que foi o ponto mais baixo desde 2012 e no final disponibilizam um link (só que do próprio Phoronix) com mais detalhes de estatísticas de código (apesar de eu gostar do Phoronix, odeio quando os sites fazem isso).

Lennart respondeu comentando em seu perfil pessoal no G+ (OK, eu não vou disponibilizar o perfil do cara porque muitos o atacam) respondendo aos detalhes:

Uh, então Phoronix está sendo Phoronix, e reporta noticia bastante enganosa. Deixe-me colocar rapidamente algumas coisas diretas: antes de tudo, "um milhão de linhas de código" é realmente enganoso, assim como aparentam ser brutas de aquivos gerenciados pelo git. Desde que nós carregamos grande montante de documentações as linhas de código vigentes são muito menores. utilizar uma ferramenta como "sloccount" para contagem de linhas de código revela que o systemd atualmente carrega ~342K linhas de código, das quais 318K são apropriados códigos C. Que na verdade não é tanto assim. Para colocar as coisas em perspectiva, como um exemplo o wpa_supplicant sozinho possui ~451K de linhas de código, das quais ~351K são apropriados código C. Acho que desde que a supostamente enorme arvore do systemd com todos os seus componentes, tais quais resolved, networkd, timesyncd, nspawn, journald, e assim por diante sozinho atinge 75% do tamanho da base de código de você $#$#%$ o subsystem wifi, eu acho que nós estamos bem, você não?
Quero dizer, com certeza, maçãs, laranjas e coisas, mas ainda…
(e sim, mesmo coisas tais quais projetos supostamente "inclinarem-se" como a uclibc pesarem 329K de linhas de código já…)

Viram como transmitir informações reais é uma responsabilidade muito grande? Sempre se questionem e corram atras para certificarem das informações. O link para o artigo está logo abaixo:

• Phoronix: systemd atinge um milhão de linhas de código
• Daemons, Daemons e mais Daemons (init)

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