Mostrando postagens classificadas por relevância para a consulta fuschia. Ordenar por data Mostrar todas as postagens
Mostrando postagens classificadas por relevância para a consulta fuschia. Ordenar por data Mostrar todas as postagens

Fim do Android porque Linux não é seguro e tem vários problemas... Sei, conte-me mais.

Android chegando ao fim
Adeus Android
 Fuschia (pronuncia em inglês Fúishá) é o sistema operacional da empresa Google baseado no micro-kernel Zircon que por sua vez é baseado no micro-kernel Little Kernel e que possui como foco os dispositivos embarcados. O interessante é que o Little Kernel está no boot do Android com o nome de lk e também no seu Trusty TEE. É, o Little Kernel já é presente há mais tempo do que imaginam. Já pensou se os caras entram na mesma briga desnecessária que o GNU por simples questão de nome???... Além do mais, se reclamarem de segurança e baixo desempenho do  Android, pode ser culpa do Little Kernel também (há vários fatores a serem analisados).
Para saber mais sobre micro-kernel, suas vantagens e desvantagens, leia meu artigo sobre os 5 diferentes modelos de kernel bastando clicar aqui. Eu estou sempre atualizando-o com novas informações.
O nome Fuschia é o nome da cor vermelha púrpura viva dada a algumas flores (por que escolheram esse nome, eu não faço ideia). O Fuschia possui suporte as arquiteturas X86 e ARM e seu código está (com exceção dos programas de terceiros) sob as licenças BSD, Apache2/.0, MIT e Zlib.

Talvez seja isso o que leve todos a pensar que o Fuschia substituirá o Android; mesmo suporte a arquiteturas, mesmas licenças do user-space do Android (e mais atraente sendo presente até no seu kernel). Não a tamanha bobeira que ouvi sobre Linux não ser customizável, não ser seguro e ter muitos problemas problemas.
Diagrama do sistema operacional Fuschia
Arquitetura do sistema operacional micro-kernel Fuschia
Depois que assisti o vídeo com tamanha bobeira, eu não exitei em responder ao canal que até hoje não me respondeu:
minha resposta no vídeo em questão
minha resposta no vídeo em questão
Como mencionei no comentário, a Microsoft mesmo adotou Linux exatamente por questão de segurança, confiabilidade e ser pequeno. Cheguei a debater na época do lançamento com pelo menos três vídeos no canal e um artigo no blog e que podem ser conferidos clicando neste texto.

 Então, aqui vai o vídeo onde debato o vídeo em questão:

Aproveitando que estamos falando sobre segurança, há um guia sobre criptografia no Android no site Pixel Privacy que vale a pena ser conferido bastando clicar aqui.
 Mais uma coisa que foi dita é que o Fuschia é um sistema mais robusto. Eu duvido que, se tratando de sistema operacional, muita gente entenda do que se trata robustez (o que na verdade não foge das leis da física e biologia. Geralmente é assim, a tecnologia imita a natureza). Já ouvi muita gente até mesmo pessoas empregarem a palavra robustez para se referir a um sistema pesado (mal sabem eles que é o oposto do que dizem). sistemas como Linux e BSDs são sistemas que já atingirem a robustez em vários aspectos.

Se o Google realmente estivesse pensando em substituir o Android pelo Fuschia por Linux não ser seguro e ter um monte de problemas (esse é o ponto chave da conversa), o Google não teria entrado para os membros Platinum (maior categoria de membros) da Linux Foundation depois da Microsoft, não teria investido $?? Milhões no KaiOS que é uma distribuição Linux baseado no antigo FirefoxOS, não estariam trabalhando no desenvolvimento do LinuxBoot, o toybox não  estaria em contínuo desenvolvimento.


Não acredito que o Fuschia tem como objetivo principal substituir o Android. Por que não especularam isso quando o Google lançou o ChromeOS? Não sabiam que o ChromeOS era Linux também. Mas se o Fuschia vai realmente substituir o Android ou não, isso somente o tempo dirá e prefiro esperar o Google dizer ao invés de ler sites afirmando somente a possibilidade.

O que me intriga não é se irão substituir o Android ou não e sim dizer que Linux não é seguro e tem vários problemas. Tanto que chega a ser contradizente já que por um lado o Google trabalha no desenvolvimento do Fuschia e por outro trabalha no desenvolvimento de outros projetos Linux. Mas eu gostaria até mesmo de dar uma sugestão aos que gostam de ficar especulando a respeito do Linux fingindo entenderem o que estão falando:
Fechem os canais e blogs de vocês. Como vocês podem confiar em ter seus canais e blogs rodando em um sistema que não é seguro e tem um monte de problemas? Fica a dica.

HarmonyOS - O sistema operacional que visa substituir o Android

HarmonyOS - O sistema operacional que visa substituir o Android
HarmonyOS - O sistema operacional que visa substituir o Android

 Martin Děcký, um dos autores do sistema operacional HelenOS e que trabalha para a Huawei em um sistema operacional que pretende ser o substituto completo do Android. Em Junho de 2021, Martin concedeu uma entrevista para o site Checo lupa.cz dando uma visão sobre o sistema operacional HongMeng OS e sua relação com o HarmonyOS.

Martin Děcký, um dos autores do sistema operacional HelenOS e do HongMeng OS.
Martin Děcký, um dos autores do sistema operacional HelenOS e do HongMeng OS.

 HongMeng OS é um sistema operacional com seu próprio microkernel que não tem nada a ver com Linux ou base de código de  qualquer outro sistema e que teve seu inicio de desenvolvimento em 2017. Ele tem várias iterações internas e uma terceira transcrição está sendo trabalhada. Martin começou a trabalhar na certificação de segurança deste sistema e alguns de seus colegas começaram a trabalhar em um hipervisor.
Para mim e para a maioria dos meus colegas, o HelenOS foi um projeto que nos moldou em termos de conhecimento e de orientação geral de nossas carreiras. É uma parte fundamental da minha vida profissional. É por isso que lamento que o HelenOS esteja atualmente em uma fase lenta e estou dedicando muito mais tempo e energia a outros sistemas de microkernel.
 Por volta de 2018, o nome do sistema foi alterado para HarmonyOS para melhor adoção no mercado ocidental e a empresa anunciou publicamente que o objetivo era que o HongMeng OS / HarmonyOS era substituir o Android nos smartphones da empresa e ao mesmo tempo ser utilizado em seus navegadores, roteadores, BTS e muito mais. estranhamente depois a empresa decidiu comunicar o sistema sob o nome HarmonyOS e que não tem nada a ver com o HongMeng OS original. HarmonyOS 1.0 é um sistema construído sob o núcleo LiteOS em tempo real enquanto a versão 2.0 do HarmonyOS 2.0 é basicamente Linux mais parte de código aberto do Android mais add-ons internos da empresa.

LiteOS
LiteOS

 O HongMeng OS ainda está evoluindo e há um plano de que ele será o substituto definitivo para o Android.
"Um sistema operacional multiservidor de microkernel é composto de pequenos componentes isolados, cada um executando em um espaço de endereço separado e assim por diante. Esta é uma arquitetura adequada para verificação formal, certificação ou execução em   situações de segurança  e  missão crítica . A sobrecarga associada à comunicação de componentes isolados anda de mãos dadas com isso. Existem cenários, como um smartphone, em que os componentes são um pouco mais monolíticos. Arquitetura flexível significa ter um mecanismo que pode modificar um sistema de componentes e sua arquitetura de modo que durante a implantação seja possível   juntar componentes do espaço do usuário e movê-los de lá para o kernel e assim por diante."
"Há algum tempo, tem havido um esforço para pelo menos unificar os garfos internos do kernel Linux no projeto HULK, o Huawei Unified Linux Kernel, para que tenhamos uma base de código Linux unificada."
 Então, já que a galera está gostando de especular muito sobre o Fuschia, aqui está mais um sistema operacional que irá concorrer com  o Android.

85% dos smartphones rodam Linux

85% dos smartphones rodam Linux
85% dos smartphones rodam Linux

    Não é nenhuma novidade que Linux já está presente em celulares muito antes do primeiro iPhone surgir no mercado em 2007. O motorola EZX de 2003 já rodava Linux que leva o mesmo nome do aparelho (EZX Linux que aliás era um celular que eu quis muito na ápoca), a OpenMoko também já produzia celulares com Linux (e teve até um cara que construiu um foguete controlado por celular da OpenMoko) e a lista com celulares em que Linux está presente  é bem grande.

Foguete controlado por celular da OpenMoko
Foguete controlado por celular da OpenMoko

    Fora o FirefoxOS que foi descontinuidade pela Mozilla mas foi descontinuado e mesmo assim adotado por outras empresas em outras áreas como é o caso d
o KaiOS que já mencionei no canal (e em 2019 já havia mais de 85mil aparelhos disponíveis), o UbuntuPhone, o Fire OS da amanzon, e até mesmo Linux em BIOS e UEFI muito antes deste artigo clicando aqui e até Linux em relógios muito antes da Apple (a Apple mesmo anda contratando desenvolvedores de Linux).


    Porém, com a chegada do Android, mesmo havendo outros sistemas operacionais concorrentes que também são focados em dispositivos móveis como é o caso do MeeGo no Nokia e até a Microsoft entrando na disputa com o Windows Phone, 
as empresas passaram a dar atenção especial ao Android sendo hoje o maior concorrente direto do iOS.

    Começou de forma minguada e até de futuro de certa forma duvidoso e aos poucos foi crescendo ao ponto que hoje é noticiado pela haydenjames que 85% dos smartphones rodam Linux; mais especificamente o Android que estamos tratando aqui. Se você é um dos que até hoje duvida que o Android é uma distribuição Linux, há uma série de vídeos no meu canal sobre o Android; um deles é exatamente o fato de ser uma distribuição Linux (a diferença entre Android e as distribuições convencionais que utilizamos como Debian, Ubuntu e CentOS é que os programas no user-space do Android estão sob licenças open source como Apache e BSD, mas nunca sob GPL). E sim, o  Android é open source, a questão é que, diferente do iOS que é distribuído direto pela Apple, o Android é distribuído por várias empresas diferentes e por esse motivos vemos tantas versões diferentes.


    Mas voltando a noticia, as informações foram extraídas da International Data Corporation (IDC). que exibe não somente o crescimento de sistemas operacionais como também das marcas, de acordo com países e muito mais. O número real até o momento é de 83.8% e é previsto o número de 84.9% até de 2025.

Crescimento do Android em 2021 segundo a IDC.
Crescimento do Android em 2021 segundo a IDC.

    Como os smartphone são considerados a 4ª geração de computadores (Mainframes foram substituídos por minicomputadores, que foram substituídos pelos microcomputadores que utilizamos e que estão sendo naturalmente substituídos pelos smartphones), é natural que seu uso gerasse um ecossistema gigantesco. Hoje em dia é muito comum ver pessoas preferirem a comodidade de ficarem sentadas ou deitadas com seus smartphones e poderem realizar todas as suas tarefas por ali. 

    Logicamente não é possível substituir os microcomputadores por completo pois não há todas as funções ali porém, o Android ganhou tamanha proporção que facilmente o encontramos sendo utilizado para outros propósitos muito além de smartphones como steraming de TV e jogos (veja o Nvidia Shield), em consoles (ou ao menos partes do Android como é o caso do Nintendo Switch) e até mesmo em telões de supermercados como é o caso da imagem que pode ser vista abaixo.

Android sendo utilizado em telões para exibir produtos e preços em supermercados.
Android sendo utilizado em telões para exibir produtos e preços em supermercados.

    O Android gerou um ecossistema gigantesco e movimenta cada vez mais mercados. Sempre há especulações de que o Fuschia anda sendo desenvolvido para substituir o Android (mesmo que a Google nunca se pronunciou sobre o assunto).  Honestamente eu vejo o Fuschia mais sendo pensando para outros mercados do que em substituir o Android da mesma forma que é muito dificil substituir o Windows nas áreas que possui seu propósito.

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.
APROVEITE O DESCONTÃO DE CELEBRAÇÃO DA INDEPENDÊNCIA DO BRASIL E VENHA APRENDER LINUX DE COMIGO;)

Lançado novo Minicurso de atributos no Linux

Emulador de NES no HelenOS

Já não é de hoje que digo isso), o HelenOS é o sistema operacional micro-kernel que mais gosto.
Já o mencionei em vários vídeos no canal e artigos aqui no blog (basta digitar "toca do tux" +HelenOS no Google que encontrará boa parte)
 e por alguns motivos básicos:
Funcionar bem mesmo dentro das limitações que existem no conceito micro-kernel
Ser uma fonte rica de estudo sobre sistema operacional assim como o Linux
E por receber bem a comunidade Linux

Extraído da própria apresentação do HelenOS
Esse ultimo chega a ser motivo pela qual a equipe do sistema se inspira em várias coisas no Linux para implementarem no no HelenOS. Exemplo disso foi que mencionei no vídeo "A polêmica daemon init systemd" abriram um ticket para implementarem caracteristica do systemd para o controle de suas daemons que é uma das áreas onde sistemas operacionais micro-kernel carecem muito. A equipe do HelenOS já chegou até mesmo a apresentar palestra do LinuxDays de 2013.

Bom, por mais que essa pareça uma noticia um tanto quanto sem graça para muitos, é até interessante e um progresso tratando-se de um sistema operacional micro-kernel onde o seu desenvolvimento é bem mais complexo (isso vale para todos os sistemas operacionais micro-kernel, até mesmo para o Fuschia). Desta vez a equipe do HelenOS apresentou no HelenOS Meeting o port do seu  próprio emulador NES chamado ZX Spectrum.

No vídeo abaixo, apresentam o LaiNES rodando no HelenOS:



A equipe HelenOS começa a ter sua gama de software disponível bem crescente e pretendem torná-los fáceis de encontrar e instalar via um pkg. Há também planos para portar jogos do Linux para o HelenOS como descrevem no próprio site.

JIŘÍ SVOBODA até mesmo escreveu em seu blog um artigo sobre o benchmark que realizou substituindo o AVL tree para melhorar o desempenho do sistema operacional.

 E olhem que coisa interessante. Essa semana a startup BedRock mandou mensagem a toda a equipe do HelenOS procurando engenheiros de micro-kernel para um projeto.

É sempre bom estar esperto para ver o que acontece no futuro, não é? ;)

Se a newlib é tão boa para embarcados, por que não foi adotada pelo Android?

Conheça o Android 9 Pie
Android 9 Pie
 Escrevi ontem a noticia sobre um novo patch para a newlib que irá melhorar seu desempenho significativamente. A newlib foi adquirida pela Red Hat quando esta comprou a cygnus solution. Se buscarmos informações em vários sites, veremos como a newlib é bem mencionada por vários profissionais da área de embarcados.

 Daí, surge a questão:
 "Se newlib é a biblioteca mais indicada por muitos profissionais para embarcados, por que então criaram a Bionic para o Android?"
 A questão é um pouco mais complicada, e para isso temos que entender como a comunidade do Android é regida. A primeira coisa que temos que entender é que há uma política no Android de não haver aplicações sob GPL em seu user space e se houver, você não poderá utilizar o nome Android em seu sistema, vindo a ter que remover o nome Android de todo o sistema operacional que está fornecendo.

 Nesse caso, como quem rege o user space é a biblioteca C e a Bionic está sob clausula 2 da BSD (coisa que a Bionic herdou do freeBSD e do NetBSD uma vez que a Bionic é derivada de porções de bibliotecas dos dois sistemas), acho que fica claro o motivo se cruzarmos os fatos. A ideia por trás disso é evitar problemas futuros com o uso de GPL nas aplicações do Android; problemas que já ocorreram com outros projetos e empresas. Por conta desta politica, a maior parte de suas aplicações em user space estão sob licença Apache e algumas partes sob outras licenças como o próprio kernel que está sob GPL (lembrando, não há problema quanto ao kernel pois ele não atua no user space e sim no kernel space), seu terminal padrão que desde a versão 7 do sistema é o toybox está sob 0BSD e vale mencionar até o microkernel Fuschia roda no processo de boot do Android.

 Há um misto de tecnologias que são utilizadas no desenvolvimento do Android e expliquei neste vídeo aqui:


 E o que isso tudo tem a ver com a newlib? A newlib é uma biblioteca que possui um misto de licenças, sendo uma delas a GPL e com isso, acaba dificultando a adoção da newlib no Android. O que poderia ser feito nesse caso é utilizar as partes que não estejam sob GPL para a criação de algo novo ou até mesmo serem incorporadas a bionic.

 Honestamente eu espero verdade é que a bionic venha a ser substituída pela musl. Agora, se você trabalha em um projeto baseado no Android (uma distribuição baseada no Android) e não se importa quando ao uso do nome, aí tanto faz qual biblioteca e sob qual licença que vai rodar no user space, você só não poderá usar o nome Android. Podem haver outras implicações, mas essa é a maior.

Os 5 diferentes modelos de kernels

kernel-linux
A palavra inglesa kernel (pronuncia-se em inglês kârnl) tem o sentido de semente, grão, núcleo e 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.
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(FreeDOS)

Kernel modular

 (17/04/2022) Kernel modular trata-se do modelo que possui drivers em forma de módulos. Módulos são drivers que localizam-se fora do kernel e que são carregados e descarregados dinamicamente quando necessário. Daí o termo kernel modular.
 
Essa foi a melhor imagem ilustrando o kernel modular que encontrei na internet já que não sou bom para desenhos. Caso você seja e quiser me mandar a sua arte, eu agradeço pela sua contribuição já que esse é um dos meus artigos mais acessados. Fonte: Distributed Networks.

 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, quando 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 possuem vantagens e desvantagens. O kernel monolítico possui a ventagem de proporcionar melhor desempenho e melhor segurança 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 assim recurso do hardware. Isso em um desktop hoje em dia onde possuímos facilmente  abundancia de processadores com muitos núcleos e ao menos 8 Gigabytes de RAM, placas mães monstruosas com barramentos altos  e placas de vídeos boas, pode não parecer incomodo; mas em servidores que permanecem em funcionamento 24/7/365 e atendendo a altas demandas, remover oque não é necessários sempre é uma boa prática a ser mantida.

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
É 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 módulos 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 do comando speedt com o comando file
 Já bibliotecas estáticas são programas que não dependem de nenhuma biblioteca esterna pois as bibliotecas residem no próprio programa (assim como o kernel monolítico).

Exibindo as informações do programa papyrus através dos comandos file e ldd. E 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 é feita 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 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 minimo de recursos possíveis (como o próprio nome sugere). Todos os demais recursos são distribuídos e administrados de forma modular, 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: Não confunda sistema operacional modular com sistema operacional microkernel. O termo modular no microkernel é diferente de modular no kernel monolítico. Modular no kernel monolítico, como já anteriormente mencionado, refere-se a seus drivers fora do kernel e que são carregados quando necessário e descarregados quando não são mais necessários. Modular no microkernel refere-se a suas daemons.

(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 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 e trabalhar com modularizarão, acabaria se tornando mais facil de receber manutenção do que o kernel monolítico.

Exemplo de sistemas operacionais microkernel

  • Minix quase todos nós que conhecemos Linux conhece esse sistema. Ele é voltado a didática, para quem quer conhecer como um sistema operacional funciona realmente. Pode-se dessecá-lo e analisá-lo. Não tenho criticas ao sistema desde que essa é a intenção do sistema. 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.
  • Hurd Na verdade seu nome é GNU Mach, é o microkernel que surgiu na universidade Carnegie Mellon e trata-se do mesmo kernel utilizado pela Apple. O que ocorre no caso do projeto GNU é que o projeto pediu autorização para utilizar tal kernel para construir seu sistema operacional como algo superior ao Unix. Esse já não é o primeiro kernel que o projeto GNU solicitou uso, com o Trix ocorreu a mesma coisa e há intenções de migrarem ou para algum kernel BSD ou para o L4 devido ainda não está pronto e nem há previsão para a sua 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:
Diagrama do sistema operacional Fuschia
  • 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
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 é fato.

 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 e não prático. Dificilmente encontramos um sistema operacional microkernel sendo utilizado em ambiente de produção. Pode ser que encontramos sendo utilizado para propósitos 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, acabou foi se tornando algo EXTREMAMENTE COMPLEXO devido o seu uso de daemons como processos independentes do kernel. 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:


HelenOS é um sistema operacional baseado em um número de processos cooperativos servidor, no entando está faltando meios unificados para controlá-los e monitorá-los.
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.

>   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 ]
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? 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 systems fica disponível imediatamente depois de uma quebra. Não há necessidade de uso do fsck para repará-lo.
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ístoca. 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 erro.
Recurso do systemd para auto-reinicialização de serviços caso ocorra algum erro.

Quebrando o mito sobre o kernel monotelitístico

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 mentira, mas também 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 Linux ser um kernel monolítico, muitos aspéctos de baixo nível do sistema operacional são afetados por daemons. O que é um recurso comum seguindo os princípios do design do Unix que é exatamente o emprego de daemons de processos separados para controlar funções distintas do do sistema operacional.


 A imagem abaixo ilustra como é o real funcionamento do sistema operacional de kernel monolítico; o kernel é dividido em kernel space e user space:

kernel monolítico.
Esquema de funcionamento do sistema operacional monolítico.

 Já o systemd introduziu o conceito de
system layer onde vários desses serviços são administrados pelo system:

systemd system layer
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, ainda existe kernel híbrido que é (digamos) uma junção das duas coisas. A ideia é que se obtenha o desempenho do kernel monolítico e a estabilidade e 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? 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 no livro da Wikipedia
  

Informação nas redes sociais
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
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í :) ]:

 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.
https://en.wikipedia.org/wiki/Exokernel

    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
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.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (9) Andriod (14) android (5) artigo (5) aws (1) bc (16) benchmark (3) BSDs (27) btrfs (30) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (24) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (80) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (86) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (11) DragonflyBSD (20) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (5) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (75) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (20) Funtoo Linux (13) games (90) gerenciadores de pacotes (3) GOG (3) google (8) gpu (3) hardware (101) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (60) leis (1) LFCS (1) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) machine learning (1) matemática (4) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (146) não viva de boatos (9) navegadores (3) NetBSD (7) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) open source (82) OpenBSD (5) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (5) partições (6) pentest (8) pipewire (1) processadores (27) professor Augusto Manzano (11) Programação (60) promoção (1) propagandas com Linux (8) Red Hat (21) redes (3) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (1) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (22) smartphones (3) Software livre e de código aberto (150) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (83) terminal de comandos (11) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (13) zsh (2)