Lançado Unleashed 1.3

illumOS ganha um fork

 Unleashed é um fork do sistema operacional illumOS (e sendo o illumOS um fork do Open Solaris e por sua vez, um derivado do Solaris). O meu primeiro vídeo no canal eu relatei um pouco sobre o Open Solaris já que havia ouvido pessoas dizendo que se tratava de uma distribuição Linux. Caso não saiba o que é um fork, eu tenho um artigo aqui no blog que pode conferir e entender melhor, basta clicar aqui ;)

 Automaticamente o Unleashed herda as características do Open Solaris como o ZFS, o DTrace e o Crossbow e vários outros recursos que podem ser conferidos clicando aqui. Veja aqui meu antigo vídeo sobre o Open Solaris.

 Existem vários em torno de oito distribuições derivadas do illumOS; cada um desses destinado a soluções diferentes como Workstation, servidores, storages e Hypervisor. A lista de distribuições derivadas do illumOS que podem ser conferidas clicando aqui ou visualizando a imagem abaixo.

Distribuições derivadas do illumOS

 Esse fork surgiu pela comunidade acreditar que poderia fazer melhor do que os derivados do illumOS adotando uma postura diferente em relação à compatibilidade e redução de interações de códigos, buscando modernizar o sistema operacional através da remoção de código legado. Com isso, apesar de um descendente do Solaris, o Unleased torna-se binariamente incompatível com o Solaris por removerem um monte de partes (digamos) sujas.

 A comunidade quer adotar um ambiente de compilação diferente já que do illumOS é antigo. Querem que o ./configure seja o suficiente para a maioria dos programas (sem ser necessário ficar especificando flags ou lincar bibliotecas adicionais).
sendo o 

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

 Essa é uma comunidades sendo totalmente Open Source (não pretendem ter binários proprietários e nem blobs no sistema operacional), com uma liderança limpa, um sistema operacional completo, com lançamentos periódicos (um a cada três meses com patches de segurança entre os lançamentos),

https://www.unleashed-os.org/

https://www.unleashed-os.org/why.html

http://lists.31bits.net/archives/devel/2019-April/000052.html

NÃO SE ESQUEÇA DE SE INSCREVER NOCURSO DE SHELL SCRIPT DO MATEUS MÜLLER
Cursos na Udemy

Btrfs: Uma breve comparação com o ZFS

Imagem reaproveitada do meu próprio vídeo "ZFS VS Btrfs №1: Quem vence essa batalha?" (informação adicionada em 31/07/2021)

    Ontem eu publiquei o vídeo de aniversário do Btrfs (que espero terem gostado. Já deixo-os ciente de que a festa ainda não acabou hehehe).

    Quando o ZFS foi iniciado, a perspectiva para o file systems no Solaris também era escura. Logging UFS já estava aproximando do fim fim da linha em termos de tamanho de file system size e desempenho. UFS estava de longe atrás que clientes do Solaris pagaram somas substanciais em dinheiro para a Veritas rodar o VxFS.

    O Solaris precisava de um novo file system, e precisava em breve. Jeff Bonwick decidiu resolver o problema e iniciar o projeto ZFS dentro Sun. Sua metáfora de se organizar era aquela do subsistema da memória virtual:

"Por que o disco não pode ser fácil de administrar e utilizar quando a memória? "

    A estrutura central de dado ondisk era a laje, um naco de dispositivo de disco divididos em blocos do mesmo tamanho, como aquele no alocador de memória do kernel SLAB, que ele também criou.  Ao invés de extents, ZFS utilizaria um block pointer por bloco, mas cada objeto utilizaria um tamanho de bloco diferente. E.g., 512 bytes, ou 128KB dependendo do tamanho do objeto. Endereços de blocos seriam traduzidos através de um tipo de meconismo de memória virtual, assim os blocos poderiam ser realocados sem o conhecimento das camadas mais alta. Todos os dados e metadados do file system seria armazenados em objetos. E todas as mudanças no file system seriam descritas em termos de mudanças para objetos, que seriam escritas em um estilo copyonwrite.

    Em resumo, btrfs organiza tudo no disco dentro de uma btree de extents contendo itess e dados. ZFS organiza tudo no disco dentro de uma árvore de apontadores de bloco, com tamanhos diferentes de bloco dependendo no tamanho do objeto. Btrfs realiza checksums e re-confere os extents; o ZFS realiza checksums e re-confere tamanhos variáveis de blocos. Ambos os file systems escrevem as alterações no disco utilizando CopyonWrite extents ou blocos em uso não são sobre escritos no lugar, eles são sempre copiados em algum outro lugar primeiro.

    Então, enquanto a lista de recurso dos dois file systems parecem bastante similares, as implementações são completamente diferentes. É um pouco de evolução convergente entre marsupiais e mamíferos placentários. Um rato marsupial e um rato placental parecem bem idênticos por fora, mas suas implementações internas são um bocado diferentes!

    Na minha opinião, a arquitetura básica do btrfs é mais adequada do que a do ZFS. Um dos maiores problemas com a abordagem do ZFS "slabs" de blocos de um tamanho particular é fragmentado. Cada objeto pode conter blocos de somente um tamanho, e cada slab pode somente conter blocos de um tamanho. Você pode facilmente acabar com, por exemplo, um arquivo de blocos do tamanho de 64K que precisam crescer um blocos ou mais, mas nenhum bloco to tamanho de 64K estão disponíveis, mesmo que o file system esteja cheio de bem perto de slabs vazios com blocos do tamanho de 512 byte, 4K, 128K e etc. Para solucionar esse problema, nós (os desenvolvedores do ZFS) inventamos meios de criar grandes blocos fora de pequenos blocos ("gang blocks") e outros trabalhos desagradáveis. Em nossa defesa, no tempo que btrees e extents aparentavam fundamentalmente incompatíveis com copyonwrite, e a metáfora da memória virtual metaphor nos serviram bem em muitos outros respeitos.

    Em contraste, os itens em uma abordagem btree são extremamente eficientes e flexíveis em espaço. Desfragmentação é um processo em curso reempacotando os itens eficientemente é parte do caminho do código normal preparando extents para serem escritos no disco. Fazer checksums, reference counting e outros metadados variados em uma base por extent reduz a sobrecarga e torna novos recursos (tal como reverso de mapiamento rápido de um extent tudo que refere-se) possível.

    Agora, para algumas predições pessoais (baseada puramente em informações publicas, eu não tenho nenhum conhecimento de informante). Btrfs será o file system padrão no Linux dentro de dois anos. Btrfs como um projeto não será (e não pode, a esse ponto) ser cancelado pela Oracle. Se todas as propriedades intelectuais estão funcionando (um grande se), ZFS será portado para Linux, mas ele terá menos de um pouco percentual da base instalada do btrfs.

    Verifiquem daqui a dois anos e vejam se eu eu estou certo dessa predições!*

*Este artigo foi escrito em 22 de Julho de 2009

 QUER APRENDER A UTILIZAR LINUX DE VERDADE, ENTÃO VENHA APRENDER COMIGO ;)

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

O estranho caso do ZFS consumir muita CPU

O estranho caso do ZFS consumir muita CPU

 Por mais que muitos pintam a imagem do ZFS como um sistema de arquivos indestrutível, ele também possui suas ventagens e desvantagens (como tudo no mundo, lei natural). Eu já abordei esse assunto em uma série do meu canal chamado ZFS vs Btrfs. Quem vence essa batalha.

Criei uma playlist especial para essa série e você pode conferir clicando aqui.

 E por mais que seus defensores não consigam admitir, o ZFS também possui seus defeitos. Dois deles já foram mencionados aqui sendo o um o seu alto consumo de RAM e o outros o grande problema com de fragmentação.

Um pouco mais pode ser conferido aqui.

 No dia seis de Setembro, Brendan Gregg relatou em seu blog um problema muito estranho que ocorre com o ZFS. Uma equipe de microsserviços o contatou apresentando o caso em que o ZFS estava consumindo sozinho 30% da capacidade de CPU. E por que exatamente a Brendan Gregg? Para quem não o conhece, Brendan Gregg já foi representante senior Solaris na Netflix, engenheiro de kernel, já foi desenvolvedor do Solaris onde ficou conhecido na área de performance concentrando seus esforços na primeira nuvem baseada em container do mundo e no primeiro dispositivo de armazenamento ZFS no mundo.

 Brendan ainda é engenheiro senior de performance na Netflix voltando seus esforços para o Solaris, Linux e FreeBSD e ainda mantem seus trabalhos voltados ao ZFS sendo o desenvolvedor do ZFS L2ARC e de várias outras ferramentas que geraram economia mundial de US$1bilhão (além de suas ferramentas terem dado origem a várias startups). Brendan é também internacionalmente conhecido como expert em performance na área de computação sendo desenvolvedor de várias ferramentas de analise para tal fim, 

Vale a pena conhecer as várias ferramentas de autoria de Brendan Gregg, sua carreira e até mesmo seus livros. 

gwhiz, uma das ferramentas desenvolvidas por Brendan Gregg em perl que eu gosto.

 

 Mas voltando ao caso do ZFS, esse é um caso que Brendan já apresentou em 2017 na kernel recipes e sua primeira ideia foi algum engano que cometeram durante a configuração:

"Eu trabalhei nos componentes internos do ZFS na Sun Microsystems e, a menos que esteja mal configurado, não há como consumir tanta CPU."

 Foi aí que começou toda a surpresa. Brendan começou utilizando uma ferramenta da Netflix de monitoramento e nuvem chamada Atlas e de cara o ZFS estava consumindo 38% de CPU; algo muito incomum nada carga de trabalho na nuvem da Netflix. Depois de outras analises com outras ferramentas como o Vector e supos através disso que o problema estava relacionado a containers. O que para a surpresa de todos é que eles não estava utilizando containers e nem o ZFS...

Ferramenta Vector da Netflix

 Brendan então começou a debugar o sistema com comandos do sistema mesmo como df -h, mount e zfs list e estranhamente e ZFS não estava montado. Brendan então deduziu que containers poderiam ter sido criados anteriormente e destruídos; então Brendan decidiu analisar os arcstats que são contadores do kernel que rastreiam estatísticas do ZFS e o resultado foi que os contadores estavam zerados, o ZFS não estava montado e mesmo assim o ZFS estava consumindo 30% de CPU.

arcstats do ZFS

 Foi aí que Brendan decidiu olha o flame graph do Vector mais de perto e depois verificar no código fonte e no histórico de alterações e encontrou o erro no ARC que tinha como intenção melhorar o desempenho e acabou gerando tamanho problema.

 Brendan abriu a requisição de numero 6531 no GitHub da equipe do Open ZFS em 2017 (ano em que abordou esse assunto) que desde então vem dando atenção especial ao ARC e assim, não teve mais notificações por parte do cliente.

O artigo no blog do Brendan Gregg pode ser conferido aqui

Os livros do Brendan Gregg podem ser adquiridos aqui

Aqui você pode conhecer e adquirir mais livros sobre o ZFS

Mais sobre o ZFS, clique aqui

Mais sobre a Netflix

VENHA APRENDER SOBRE O BTRFS COMIGO :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux e aprendam mais recursos nos sistemas de arquivos 

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

pledge() - uma system call do OpenBSD portada  para Linux

 Alguns dias atrás eu li o artigo From OpenBSD to Linux: How Pledge can Enhance Linux Security no site It's FOSS e como eu tenho um artigo voltado a system calls do Linux (Linx: Mais do que um Unix), decidi escrever esse para integrar ao assunto.

 pledge(), ou simplesmente Pledge, é uma system call do OpenBSD que foi portada para Linux por Justine Tunney. Na verdade esta implementação para Linux foi inspirada no pledge() do OpenBSD porém fazendo uso dos recursos da API do próprio Linux (já descrito no artigo Linux: Mais do que um Unix sobre a própria API do Linux) SECCOMP BPF (já abordado no meu artigo: Linux: Mais do que um Unix) e Landlock LSM (introduzido no kernel Linux 5.13 para reforçar a segurança). Pledge força os processos a serem executados de forma restrita e limitada dentro de um sandbox (algo que é ótimo para a execução de scripts e ferramentas automatizadas).

 Como descrito por Justine em seu site, "Pledge é como se fosse o fruto proibido que todos nós cobiçamos quando o chefe nos diz para utilizar algo como Linux"... pois ..."Linux nunca possuiu uma camada de segurança que meros mortais conseguissem entender"...; ..."Pledge torna a segurança mais compreensível". Bom, neste ponto não há como discordar de Justine visto como todos nós reclamamos como é trabalhoso configurar o SELinux (muitos até reclamam que a vida é muito curta para utilizar o SELinux) ou a diferença enorme de sintaxe entre iptables do Linux e o packet filter que apesar de muito famoso através do FreeBSD, o packet filter é na verdade do OpenBSD e foi portado para o FreeBSD. Até mesmo a sintax do antigo ipfw que o FreeBSD herdou do MacOSX possui sintax muito mais facil.

 Justine mesmo passou por situação como esta ao utilizar o SECCOMP BPF para implementar pledge:

"Houveram poucos desenvolvedores no passado que tentaram isso. Não vou citar nomes pois a maioria destes projetos nunca foram concluídos.  Quando se trata de SECCOMP, os tutoriais online explicam apenas como inserir lista de permissões das system calls em si, então a maioria das pessoas perdem interesse antes de compreender como filtrar argumentos. Os projetos que foram mais longe também tinham equívocos tal como permitir a alteração de setuid/setgid/sticky bits. Então nenhuma das alternativas atuais deveriam ser utilizadas. Acredito que esse esforço nos deixa muito mais próximos de ter pledge() do que nunca."

 Um apelo que faço a todas as comunidades Linux: Parem de perder tempo com bobeiras de ideologias e filosofias! Nós somos técnicos e não filósofos; deixem a filosofia para os filósofos e gastem tal energia elaborando documentações que inclusive, sejam de fácil compreensão. Vejam aí mais um grande exemplo de problema do Linux demorar ter um grande e tão importante recurso pela simples falta de uma boa documentação.

 Apesar disso, muitos esforços tem sido feitos para sanar tais problemas no Linux e torná-lo produtivo como o próprio e odiado (sem razão lógica) systemd que trás padronizações para as distribuições e torna a configuração dos serviços muito mais fácil; o Btrfs que facilita muito trabalhar com gerenciamento de volumes e outros recursos que, em outros sistemas de arquivos, eram serviços bem mais complexos de se trabalhar; o Netfilter que eu agradeço por nos conceder o nftables com sintaxe tão fácil que se aproxima do BSD pf (além de trazer também vários recursos que anteriormente eram difíceis de implementar no iptables).

 O segundo grande motivo que levou Justine portar Pledge para Linux foi devido a baixa adesão ao OpenBSD. Em 2002 a base de usuário de OpenBSD era de apenas 7.000 usuários tendo seu crescimento sempre baixo. O que nos leva a ideia de usuários não somente migrarem mas como também portar suas ferramentas para outro sistema operacional com maior base de usuários, melhor ecossistema e melhor adesão. Isso vem ocorrendo com a base de usuários do Solaris como relata Brendan Gregg em seu artigo Solaris to Linux Migration de 2017 que está ocorrendo migração e também port de ferramentas do Solaris para Linux como o caso do Dtrace:

 Eu venho portando muitas de minhas ferramentas do DTrace para o bpftrace e cubro estas no meu livro BPF Performance Tools: Linux System and Application Observability, as ferramentas que eu tornei publicas e open source aqui. Brendan Gregg

 Bom, e o terceiro motivo que eu ponho aqui é que Justine havia desenvolvido seu Pledge para ser utilizado como uma solução sandbox para o servidor web de sua própria autoria, o redbean. Justine chegou a conclusão que Pledge é tão robusto e útil que poderia reger outros processos; então, Justine teve uma grade ideia: Ao invés de configurar o Pledge diretamente no código fonte do programa como pode ser visto man page do OpenBSD ou no código do comando cat do OpenBSD: 

system call pledge sendo utilizado no código fonte: Medium

Justine desenvolveu um pequeno comando para utilizar o Pledge.

Opções do comando pledge

 Para executar o comando, basta digitar pledge (ou ./pledge caso ainda não houver salvo o comando dentro de um diretório da variável $PATH) seguido do comando desejado. Pldge é intuitivo, o próprio comando pledge indicará quais systemcalls serão necessárias para executar o comando desejado. Veja no exemplo abaixo a terceira coluna indicando quais syscall necessárias para executar o comando ls com o comando pledge:

syscalls necessárias para executar o comando ls

 A principio eu não consegui um bom resultado após adicionar as syscalls indicadas pelo pledge pois, após seguir o passo a passo de duas formas diferentes, o único resultado apresentado foi a mensagem invalid system call (core dump) e o Gnome reportando erros:

Erro apresentado ao executar o comando ls através do Pledge

 Depois, lendo um pouco mais no site da Justine, percebi que havia faltado a syscall rpath dentro das opções selecionadas e assim consegui executar normalmente. Apesar disso, o comando ls com a opção --l ainda apresentou dois erros sendo uma de permissão (talvez seja esse o motivo pois Justice menciona em seu site que é necessário utilizar pledge como root, algo que acabei não fazendo) e outro de syscall que eu não consegui encontrar nas opções (lgetxattr). Mesmo assim, no final das linha foi apresentado o resultado do comando com sucesso:

O comando ls sendo executado com o pledge de forma mais correta

 Agora resta a mim aprender melhor como utilizar o comando pldge. Eu vou continuar estudando e testando para ver como posso aplicar de forma mais clara.

 Bom trabalho feito pela Justine que merece todos os créditos principalmente pelo desenvolvimento da biblioteca libcosmopolitan (que lhe rendeu um premio do Google em 2023; o premio Open Source Peer Bonus que extremamente difícil de conquistar) e muitos outros recursos; alias, Justine é financiada por mais ou menos uma centena de desenvolvedores no GitHub.

 Apesar que Justine informar que só implementou por enquanto coisas descritas na man page do OpenBSD, ainda precisar trabalhar em materiais primários mas que são providos do pledge do kernel do OpenBSD, também precisam de mais feedback da comunidade.

 Andreas Kling adicionou o suporte a pledge() ao SerenityOS sendo o segundo sistema operacional a adotar os mecanismos pledge() e unveil() do OpenBSD. Talvez Linux é o terceiro sistema operacional a realizar esta façanha. Quem sabe no futuro esta system call faça parte até mesmo da API do Linux? Vantagem para todos nós.

Porting OpenBSD pledge() to Linux

GitHub - jart/pledge: OpenBSD APIs ported to Linux userspace using SECCOMP BPF and Landlock LSM

Toca do Tux: Linux: Mais do que um Unix

Mais sobre o OpenBSD aqui no blog

BSD is dying

From OpenBSD to Linux: How Pledge can Enhance Linux Security

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

Dando créditos ao... Minix?

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

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

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

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

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

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

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

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

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

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

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

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

  Newsgroups: comp.os.minix

  Subject: Gcc-1.40 and a posix-question

  Message-ID:

  Date: 3 Jul 91 10:00:50 GMT

  Olá netlanders,

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

     Sites FTP seriam bons.

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

    Segundo ponto

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

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

    Terceiro e ultimo ponto

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

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

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

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

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

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

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

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

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

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

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

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

Kernel Linux ganhará mais desempenho em breve

 Quando o assunto é desempenho, Linux é o melhor sistema operacional. E antes que surjam fanboys me chamando de fanboy, Linux se torna a base de referencia quando algum projeto ou empresa quer ou precisa analisar o real desempenho de outros sistemas operacionais. No History do site de DragonflyBSD é descrito que de uma perspectiva de desempenho, o único competidor real do DragonflyBSD é o Linux. Já no meu artigo 3 sistemas operacionais que não são escritos na linguagem C, o sistema operacional JX que é desenvolvido em Java, analisou o seu desempenho tendo Linux como comparativo. Brendan Gregg, um dos mestres na arte de performance e que escreveu algoritmos que melhoraram o desempenho do Solaris, descreve que, out of the box, Linux é mais rápido.

Comparando o desempenho do JX vs Linux

 AQUI VAI UMA CONSIDERAÇÃO MUITO IMPORTANTE

 A análise relacionada a performance é algo que oscila muito. Brendan Gregg mesmo ressalva que o desempenho de um sistema operacional depende do workload e que essas diferenças podem oscilar entre 5% á 5 vezes mais. Através de análises e configurações, Brendan conseguiu colocar o SmartOS (fork do Solaris) para ter melhor desempenho que o Linux e conseguiu também o mesmo feito ao contrário.

 Em uma análise de jogos por exemplo, por várias vezes no passado eu mencionei que, mesmo que o Windows não possuísse o desempenho e qualidade tão bom quanto a do Linux, seu desempenho em jogos era muito melhor devido o emprego do DirectX. Eu ainda mantenho essa mesma afirmação se compararmos DirectX vs OpenGL. Porém, com o surgimento do Vulkan, esse quadro tem mudado bastante; a diferença de desempenho entre Windows+DirectX vs Linux+vulkan é bem baixa em favor do Windows e depois do surgimento do DXVK (DiretcX to Vulkan) que favorece muito os usuários de Linux rodar jogos do Windows sem a necessidade de ports, muitos dos desenvolvedores já mostraram que é possível rodar os jogos do Windows no Linux com o desempenho bem melhor do que no próprio Windows.

Leia mais sobre Linux rodando jogos do Windows com melhor desempenho clicando aqui.

 Se o DXVK já apresenta melhor desempenho no Linux do que no próprio Windows, a tendencia natural é ser ainda melhor uma vez que a própria Microsoft disponibilizou uma versão de DirectX para Linux e a NVidia também disponibilizou um driver open-source para Linux. A própria Apple melhorou o desempenho do MacOSX Ventura para jogos através do framework MetalFX.

 Esclarecido os detalhes sobre desempenho, agora vamos a o que importa neste artigo. No dia 21 de Junho foi publicado uma série de patches que irão melhorar ainda mais o desempenho do kernel Linux. Esses patches fazem exploram o recurso CC_OPTIMIZE_FOR_PERFORMANCE_O3, ou simplesmente -O3. O -O3 vai estar desntro do arquivo Kconfig ou podendo compilar o kernel Linux com a opção make KCFLAGS=-O3.

 Não necessariamente se trata de um novo recurso, as opções de otimização já estão presentes nos compiladores GCC e LLVM/Clang há algum tempo. Como pode ser conferido nas imagens abaixo, eu já o utilizo na compilação do bc do Gavin Howard; pode ser conferido no GCC digitanto gcc --help=optimizers e na manpage do LLVM/Clang (man 1 clang em Code Generation Options)

Configuração do bc com a opção -O3

gcc --help=optimizers

otimização do código com o clang -O e a opção desejada

 O kernel Linux já utiliza tal recurso, porém a opção -O2 por padrão e no meu artigo Redução do kernel Linux e do filesystem para IoT é apresentado a opção -Os para a otimização de tamanho (optimize for size, uma das opções que podemos escolher). O LLVM ainda apresenta a opção -O4 que é bem parecido com o -O3 e nas duas imagens abaixo eu mostro que compilei o bc com esta opção.

Configurando o bc de Gavin Howard com a opção -O4

-O4 durante o processo de compilação do bc

 Por volta de 2019, já haviam tentado implementar a otimização -O3 no kernel Linux, mas havia sido rejeitado por Linus Torvalds devido o código que havia sido enviado não ser confiável o suficiente. Hoje, depois de passarem por revisão e melhorias, tais patches começam a ser aceitos e apesar de ainda estarem em estágio beta, o site Phoronix realizou um benchmark que mostram serem promissores. Vamos torcer

CONCLUSÃO

 É possível melhorar ainda mais o desempenho em todo o sistema operacional Linux, e não somente em seu kernel. Particularmente, eu tenho uma ideia do desenvolvimento de uma distribuição que tem como um dos princípios melhorar ainda o desempenho de todo o sistema operacional (não com o mesmo argumento de muitas distribuições surgem "essa é uma distribuição estável, segura e com alto desempenho" mas que na prática não oferece nada demais). Essa não seria sua unica característica, mas um de seus princípios. Quem sabe no futuro? Pode ser que até lá alguém já faça isso no meu lugar, pessoas podem acabar tendo a mesma ideia mesmo não sendo expressadas. Se até lá alguém fizer me poupará muito tempo.

QUER APRENDER LINUX E SHELL SCRIPT DE VERDADE? ENTÃO CONFIRA O MEU CURSO DE LINUX CLICANDO AQUI :) 

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

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