Analisando 6 diferentes implementações do comando sed

Analisando e comparando seis diferentes implementações do comando sed

 Em abriu deste ano eu escrevi o artigo minised: Um sed melhor do que o sed. sed é um comando que como seu próprio nome sugere (Stream EDitor), serve para editar/alterar as informações que são exibidas em sua tela (observação que deve ser feita é que arquivos acessados através do sed não são modificados, apenas a forma como as informações são exibidas; a não ser que as informações exibidas sejam redirecionadas ao arquivo de origem). sed Foi um dos primeiros comandos desenvolvidos para o Unix para processamento de dados e, conforme o e-mail de lançamento do kernel Linux 0.02 "intitulado Códigos livres de kernel parecido com minix para AT-386" no grupo comp.os.minix, é descrito que sed também foi um dos primeiros comandos a ser utilizado pelo Linux:

"Ainda está na versão 0.02 (+1 (muito pequeno) patch já), mas executei com sucesso bash/gcc/gnu-make/gnu-sed/compress nele."

 O gnu-sed é a implementação utilizada na maioria das distribuições Linux porém, como existem diferentes implementações do mesmo comando (assim como existem diferentes implementações de todos os comandos e de todas as ferramentas), eu resolvi analisar e comparar ao menos seis delas apresentando aqui neste artigo os resultados de cada uma.

 Eu analisei o gnu-sed 4.8 disponível no Fedora 35 (sed-4.8-8.fc35.x86_64); o minised 1.16 já apresentado aqui no blog; o Busybox_SED que apesar de ter originado do gnu-sed, já não possui uma unica linha de código do do gnu-sed; logo não tendo mais nenhuma relação um com o outro (para entender melhor sobre esse caso, leia o meu artigo "O Paradoxo do Navio de Teseu no mundo open source" clicando aqui); as versões do toybox 0.8.6 e 0.8.7; o 9base sed (de origem do plan9 e depois portado para outros sistemas operacionais) e por fim o sbase sed de origem do Unix e portado para outros Unixes (incluindo Linux na lista de outros Unix) que não possui versão específica. Neste artigo eu irei avaliar as implementações por:

• Licença
• Tamanho do binário
• Recursos disponíveis
• descrição de ajuda
• Desempenho
• bugs

 Para os testes eu utilizei o terminal de comandos zsh por proporcionar melhores informações (inclusive uso de CPU por padrão) e devido o Bash por vezes já ter apresentado bugs que não podem nos garantir confiabilidade nos resultados (leia mais sobre os bugs que encontrei no bash clicando aqui). Em conjunto eu utilizei o comando time.

Diferença de exibição de resultados do comando time entre os terminais de comando bash e zsh.

 Fiz uso dos materiais públicos aurelio, the mouseless Dev que possui até mesmo um mapa mental muito interessante, o manual gnu-sed e os próprios arquivos de testes disponibilizados pelos próprios comandos.

Mapa mental do comando sed do site The Mouseless Dev

 Ao final de cada teste, eu irei classificar uma ou mais implementações como vencedores e na conclusão do artigo eu irei classificar da primeira a terceira colocação a partir da que proporcionar a maior quantidade de vantagens. Agora vamos partir para o arrebento.

LICENÇAS

 Neste primeiro tópico eu analiso quais as licenças adotadas por cada implementação levando em conta que cada licença proporciona vantagens e desvantagens. Parece um assunto irrelevante, mas trata-se de algo que pode afetar fortemente todo o mercado, todo um ecossistema e automaticamente você (se hoje o busybox estivesse sob GPLv3, provavelmente você nem teria um roteador em sua casa).

Licenças adotadas por cada implementação do comando

 Enquanto o gnu-sed está sob GPLv3+, o busybox-sed manteve-se sob GPLv2 mesmo tendo originado-se do gnu-sed (como pode ser lido no artigo O Paradoxo do Navio de Teseu no mundo open source) e é mantido pelo FFC.

Passe o cursos sobre a imagem para ler a tradução (texto original, basta clicar aqui)

 O sbase e o 9base estão sob MIT (9base sob MIT/X Consortium License); o minised foi disponibilizado sob GPL a partir da versão 1.13 e passou a ser disponibilizado sob BSD-like a partir da versão 1.14 em diante com o consentimento de Eric Raymond. O toybox está sob a clausula zero BSD (0-BSD) criada por Rob Landley que na verdade trata-se de uma Domínio Publico apenas sob o nome de BSD (com a aprovação dos próprios membros dos BSDs).

 VENCEDOR: Com exceção da GPL (que possui tendência natural a declínio), todos as demais licenças são muito boas. O busybox_SED ainda pode levar alguma vantagem com a GPLv2 por não ser incompatível com o kernel Linux e ser menos negativamente impactante que a GPLv3.

TAMANHO DOS BINÁRIOS

 Tenha em mente que, quanto menor o binário, melhor é em todos os sentidos (segurança, desempenho, modularidade e portabilidade). Códigos menores se tornam mais fáceis de manter e serem atualizados.

Passe o cursor sobre a imagem para ler a tradução

 Como mencionado no site do projeto embutils (que infelizmente não entrou para nossa lista), o userland dos Unix geralmente é composto de comandos dos BSDs e do projeto gnu. Na época que surgiram, as técnicas de desenvolvimento eram diferentes; os projetos focavam somente em recurso, mas não na otimização do tamanho.

Passe o cursor sobre a imagem para ler a tradução

 No episódio 06 do Linux Link Radio Rob Landley menciona que na época em que era mantenedor do BusyBox curiosamente descobriu que foram  escritas 833 linhas de código apenas para implementar o comando cat... E parece que não mudou muita coisa já que o gnu cat hoje ele possui 805 linhas... Outra coisa bem curiosa relatada por Rob é que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k.... Desenvolvedores de embarcados são declaradamente inimigos mortais da glibc.

 Para dispositivos como embarcados e até mesmo para o processo de boot, binários grandes são simplesmente inviáveis e parece não fazer sentido, mas mesmo em ambientes como desktop, servidores e até supercomputadores binários menores também são extremamente importantes pois assim o sistema consegue melhor desempenho em seus processos, é carregado mais rápido pela  cache L2, deixa o buffer mais livre.

 Há ressalvas a serem consideradas durante as avaliações como sua ligação se dinâmica ou estática, quais bibliotecas foram utilizadas, qual compilador e com quais flags e assim por diante. As ressalvas foram feitas em asteriscos (*).

Tamanho de cada implementação do comandos sed.

*Relembrando aqui que menor significa melhor

**Eu compilei o minised estaticamente a dietlibc.

***Consta no site do busybox que o busybox_SED possui 89K; porém, após baixar, seu tamanho final é de 92K (também likado estaticamente. Baixe aqui para conferir).

**** Eu compilei o sed do toybox dinamicamente para que pudéssemos saber o seu real tamanho.

 VENCEDOR: Neste caso eu deixo três colocados. O toybox sed em primeiro com apenas 36k; o minised em segundo com apenas 44k, e o sbase sed em terceiro com 56K.

Comparação de tamanhos entre minised linkado estaticamente e toybox sed linkado dinamicamente

 Você deve estar se perguntando se não seria injusto sendo que o toybox foi ligado dinamicamente enquanto quer o minised estaticamente. E a resposta é que o minised, mesmo ligado dinamicamente, é maior do que toybox sed. Confiram os resultados na imagem abaixo.

Comparação de tamanhos entre minised linkado tanto dinamicamente quanto estaticamente

 Além do mais, eu testei as versões binárias do toybox já disponibilizadas pelo próprio projeto que são linkadas estaticamente, e os comandos estão incorporados ao terminal (sendo um deles o sed). Mesmo contendo 231 comandos incorporados a si, o toybox  0.8.7 possui apenas 716K.

Reparem a quantidade de comandos dentro do toybox 0.8.7 em apenas 716k (sendo um deles, o comando sed que está selecionado nesta imagem).

RECURSOS

 É agora que constataremos se o tamanho dos binários fazem jus à quantidade de recursos. Reforçando o que foi dito no tópico anterior, quanto menor o binário, melhor é porém, não vai adiantar muito o binário ser pequeno e enxuto se não conter os recursos necessários para a sua adoção.

 Além do mais, esse é um ponto extremamente importante pois uma regra histórica que não falha é que, mesmo que um programa contenha certos bugs, mas possui os recursos que as pessoas querem (ou precisam), elas aceitam conviver com tais bugs. Tudo uma questão de prós e contras; além do que os bugs podem ser corrigidos ao longo do tempo (ou não, vai saber a complexidade).

 Podemos dizer que neste tópico o gnu-sed dispensa explicações pois um ponto forte das ferramentas do gnu (não por total mérito seu) mas que é mal divulgado pelo próprio projeto é exatamente a parte de recursos possuindo até mesmo extensões próprias. OK para o gnu-sed.

 No arquivo BUG do minised é descrito "Focarão nas conformidades POSIX e pequeno tamanho - extensões do GNU sed provavelmente não serão aceitas". O minised possui um diretório chamado tests que após compilá-lo, podemos executar o script run, conforme descrito em seu arquivo Makefile (cd tests; ./run ../minised) ou bastando executar o comando make check que se encarregará de fazer esse trabalho (realizando o total de 68 testes). Um dos testes falha (especificamente o empty-lhs), mas como descrito no próprio resultado, essa falha é intencional.

Testes disponibilizados pelo próprio minised

 O toybox também disponibiliza seus próprios arquivos de teste também dentro do diretório tests. No total, ele realiza 91 testes com o toybox sed.

Teste disponibilizados pelo próprio toybox

 O toybox sed possui uma lista dentro do seu próprio código fonte com algumas pequenas pendências a serem ajustados como "fazer y// lidar com delimitadores unicode, lidar com retorno de erro a partir do emit(), error_msg/exit consistentemente", "Qual a coisa certa a se fazer com -i quando escrever as falhas? Skip ou next?". Eu considero uma lista baixa; lógico que prefiro ver estas questões sanadas, mas são consideráveis.

O Busybox sed também possui uma pequena lista comentada em seu código fonte de apenas três de pequenos detalhes a serem acertados. 

 Eu não encontrei algumas pendências tanto no sbase quanto no 9base e não foram ruim nos testes.

 VENCEDOR: Empate geral. Em todos os testes que eu realizei, todas as implementações conseguiram processar com sucesso.

DESCRIÇÃO DE AJUDA

 Descrições de ajuda (--help e manpages) assim como as licenças, parecem ser irrelevantes, porém pense no seguinte cenário; você está administrando o seu sistema, precisa consultar uma opção e sabe que tal comando não possui opção de ajuda. Até aí, tudo bem, basta consultar a manpage... Certo?...

 A resposta é... depende de qual distribuição estamos falando. Distribuições como Alpine Linux ou Porteus não possuem manpages por padrão. E se de repente você não possui acesso a internet? O que você faz?...

Por que eu não tenho man pages ou cadê o comando 'man'?

 Do que adiante um programa conter todos os recursos necessários sendo que não vem com as informações de como utilizá-los? Seria o mesmo que uma TV não acompanhar manual de instruções. Alias, eu já vi empresas adotarem uma certa distribuição devido a facilidade em encontrar informações e soluções de problemas. Então, por mais que pareça algo irrelevante, descrições de ajuda é algo extremamente importante.

 E aqui vamos nós para a nossa analise. O minised, apesar de possuir uma boa manpage, não possui a opção --help por padrão. Eu acredito que poderia possuir ao menos uma leve descrição assim no sbase e no 9base. Ou melhor, assim como o busybox_SED; enxuta e explicativa.

Descrição de ajuda do minised e do sbase sed

Me lembra muito a descrição no Solaris

descrição de ajuda do busybox sed

 O gnu-sed e o toybox sed são os que melhores implementam tais descrições. Aqui eu postei apenas uma porção de toda a descrição de ambos.

Descrição de ajuda do gnu-sed

Descrição de ajuda do toybox sed

[27/11/2023] Estranhamente na versão 0.8.10 do toybox, a opção --help ficou bem limitada assim como da implementação do sbase e do Solaris. Porém, como já mostrado tanto aqui no blog quanto no canal, o toybox possui a opção help seguido do comando. Então, digitando toybox help sed, o comando sed do toybox oferece opções muito mais completa.

opção help do terminal de comandos toybox

VENCEDOR: Empate entre o toybox sed e o gnu-sed

POSSÍVEIS BUGS

 Já que falamos de recursos, agora vamos tratar de... bugs. O que é uma parte um pouco complicada de se tratar já que difícil constatar a real quantidade de bugs de um programa. Como todos sabem, há relatos de bugs que só foram encontrados mais uma década após sua existência. O bug estava lá mas só foi detectado dois de tanto tempo.

 Então, o que podemos fazer aqui é relatar os que já estão reportados em bug reports, procurar por informações em man pages, comentários dentro dos códigos, informações nos arquivos README e BUGS ou... da forma mais árdua, testando mesmo assim como já mostrei alguns que reportei e podem ser conferidos no meu canal clicando aqui. O que alias não é o meu interesse.

 Por exemplo, no arquivo BUGS do minised é descrito como não havendo a necessidade de regressão até o momento; porém, como puderam acompanhar no inicio, vale ressaltar que sua base de código é bem pequena (o que é muito vantajoso). Apesar disso, eu encontrei apenas dois comentários de FIXME nos códigos sedcomp.c e sedexec.c (/* FIXME: scan for the brace end */ e /* FIXME: lastep becomes start */).

 O mesmo ocorre no toybox sed (tendo sua base de código ainda menor que do minised). A primeira versão do sed no toybox surgiu na versão 0.5.1 (em Novembro de 2014). De lá para cá, poucos bugs foram encontrados (total de 11 bugs encontrados e corrigidos desde então. Um deles pode ser conferido clicando aqui) e poucos deles eram críticos. O minised teve 12 correções desde a versão 1.3 que podem ser lidos em seu README.

 E que comece o choro e ranger de dentes. O gnu-sed é o que mais podemos encontrar bugs. Em seu próprio git (clicando aqui) ou podem ser conferidos no Debian Bugs clicando aqui apresentam uma lista de bugs conhecidos.

 Já o Busybox_SED possui apenas duas informações de FIXME em seu código mas é possível consultar bugs em seu próprio bug reports clicando aqui.

 No código do sbase sed existem 20 comentários com o dizer FIXME. Estes comentários descrevem correcções que ainda são necessárias. Foi difícil encontrar algo relacionado ao 9base sed, há sim correções ocorrendo e podem ser conferidas no próprio git do plan9port (clicando aqui), mas não é uma lista fácil de encontrar (muito menos especificamente de seu sed).

 VENCEDOR:  Com excessão do gnu-sed, todos os demais apresentaram baixa quantidade de bugs.

DESEMPENHO

 E por fim, a parte que a galera vai para delírio: benchmarks... Parece que a galera pira com essa palavra. Aqui eu considerei analisar tanto o uso de CPU quanto o tempo para a concluir as operações. E obtivemos os seguintes resultados:

 Estranhamente tanto o gnu-sed, o sbase sed, o 9base sed e o busybox_SED se comportam da mesma forma. eles sempre se mantêm na margem de 86-89% de uso de CPU, nunca a menos nem a mais do que isso. Mas não devemos analisar unicamente o uso de CPU pois, de certo forma, isso pode significar tanto algo bom quanto algo ruim; tudo vai depender muito da situação.

 Reparem um exemplo disso na imagem abaixo onde fiz uma analise entre o minised e o gnu-sed sendo eles separados pela faixa azul. Enquanto o gnu-sed manteve o uso de 89% de CPU, o minised desta vez fez uso de 106%. Apesar do uso de CPU do minised ter sido mais alto, o mimised concluiu sua operação em 120ms enquanto que o gnu-sed concluiu a mesma operação em 284ms.

Comparação de uso de CPU e tempo de conclusão entre minised e gnu-sed

 Para que o gnu-sed, sbase sed, 9base sed e o busybox_SED consigam concluir as operações no mesmo tempo que o minised, seria necessário que utilizassem entre 136,17% a 161,87% a mais de CPU além dos 89% já utilizado. O que totalizaria entre 225,17% a 250,87% de uso de CPU.

 VENCEDOR: Empate entre o minised (utilizando entre 61% - 76% de CPU porém, com menor tempo de execução) e toybox sed (utilizando entre 50% - 76% de CPU, algumas vezes atingindo 88%). Os demais ficam entre 86% a 89% de uso de CPU e o mesmo tempo de execução.

CONCLUSÃO

 O primeiro lugar fica para o toybox sed com 6 pontos. O minised em segundo com 5 pontos perdendo apenas na descrição de ajuda apesar que possui uma boa manpage. Então poderíamos declarar empate entre os dois já que o minised possui desempenho melhor do que o toybox sed.

 O segundo lugar ficaria empatado entre o busybox_SED com quatro ponto (tamanho, recursos, descrição de ajuda e poucos bugs) e o sbase sed (licença, tamanho, recursos e poucos bugs). O 9base sed teve três pontos (licença, recursos e bugs) e o gnu-sed apenas dois pontos (recursos e descrição de ajuda).

Conclusão da analise das implementações do sed

Existem outras implementações ou comandos semelhantes como é o caso do comando sd , mas não nos interessa para este artigo.

sd é um comando que pode substituir find, sed e awk.

Adquira também o Definitive Guide to sed: Tutorial and Reference

Leia também o artigo "Bug no terminal de comandos Bash e comparação entre os pacotes de coleções de comandos"

minised: Um sed melhor do que o sed

Sed do Aurélio

página oficinal do sed do GNU

Manual sed do GNU (vale muito a pena a leitura).

Código fonte do minised hospedado na exactcode.com

Busybox sed

QUER APRENDER 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

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

O dia em que o pinguim adquire asas e cauda de um dragão de ferro.

 Desde que eu utilizo Linux, os asciduos usuários de Linux sempre utilizaram o argumento de Linux é somente o kernel enquanto que as ferramentas são do projeto GNU. Este argumento, além de fraco e inutil, deixa as pessoas confusas quanto ao Linux, desvirtua as pessoas do verdadeiro conhecimento tecnico e afasta-as de conhecer novas ferramentas que poderia ser muito mais uteis. Existem Muitas ferramentas que podem substituir as do projeto GNU tanto em empresas quanto no uso comum em seu dia a dia. conheça aqui algumas delas.

 Anos atrás (especificamente em 2010) li a noticia de ser possível compilar o Linux com o Clang. Eu, com a minha paixão pelos ideais de software era grande, discordei de tudo o que foi dito (paixão é fogo e nos cega). Alguns dias (ou semanas) depois, publicaram um benchmark entre algumas versões do GCC, do Clang, do ICC da Intel e do ovo de dragão (Dragon Egg). Passado algum tempo, tive a curiosidade de pesquisar sobre o Clang e acabei gostando do que descobri a respeito do compilador. Foi bom saber que haviam outras opções para compilar o Linux além do GCC; como em tudo o que há no Linux são outras opções (GUIs, editores de texto, navegadores, terminais de comando, comandos e tudo mais, a regra vale também para compiladores, bibliotecas e tudo mais). 

 Esse é o tipo de liberdade que gosto; a liberdade de escolher o que quero e o que vou utilizar; a liberdade se estende a muito mais do que as citadas pela GPL e não ficar preso ou limitado à uma única opção. Seria a mesma liberdade que tenho de ir ao mercado e poder escolher se quero presunto de uma marca ou de outra (a lei da concorrência existe para isso, assegurar o nosso direito como consumidor e desta forma, as empresas busquem conquistar seus clientes com a melhoria continua de seus produtos ou serviços).

 Como mencionei, eu até era extremo defensor de software livre e de código aberto (ainda defendo a adoção de ferramentas open source, mas não da forma que eu abordava anteriormente acreditando que software proprietário representam ameaças à humanidade), recebia newsletters da FSF por e-mail, porém, tomei antipatia quando Richard Stallman ficou cantando vitória sobre a morte de Steve Jobs. Mas ainda assim, continuei com os ideais de software livre e de código aberto.

 Certa vez participei de um podcast onde um dos convidados que não vou mencionar o nome (e por favor, não me perguntem quem é, pois não irei responder; citação de nome é difamação) era defensor de software livre. Até aí tudo bem, eu também era; o problema é que o cara não queria participar simplesmente pelo fato do software que iria ser utilizado para gravar não era (totalmente) livre; isso rendeu alguns comentários. Depois começou a ficar difícil interagir com ele, pois tudo para ele era somente software livre sem ouvir o que o outro lado tinha a dizer. Percebi que eles pregam a liberdade mas se tornam escravos de  tais ideais, se tornam flexíveis.

 Gosto de software livre e de código aberto, não deixei de usar as ferramentas do projeto GNU (e talvez não deixa de usar tão cedo), mas da comunidade eu passo longe (a não ser que venham me encher a paciência kkkk).

 Alguns dias atrás, um amigo conversou comigo sobre chamar o sistema de GNU/Linux ou simplesmente de GNU, e não somente de Linux (como assim?). Beleza; o assunto encerrado depois de longo debate entre nós. Coincidência ou não, um ou dois dias depois um seguidor do meu canal comentou a mesma coisa no meu vídeo "Linux (dando nome a criança):

 O nome correto é Linux e não de GNU/Linux (e muito menos somente de GNU. GNU seria horrível). Primeiro porque Linux é um nome proprietário (uma propriedade intelectual de Lius Torvalds que pode lhe autorizar utilzar seu nome ou não); segundo, não há somente ferramentas GNU presentes no sistema operacional Linux (isso sim é uma verdadeira falácia e desinformação); terceiro, as ferramentas GNU são substituíveis e quarto, ambos são projetos distintos com propósito e propostas diferentes. Essa guerra por reconhecimento de nome do sistema operacional é na verdade relacionada a ego e não ao argumento meritocracia. Mesmo que discordem de mim, eu afirmo:

O GNU só é um projeto bem sucedido e amplamente utilizado graças a sua adoção pelo Linux (mesmo o GNU sendo mais velho). Duvido que o Gnu seria amplamente conhecido se não fosse o Linux.

 Se considerarmos chama-lo de GNU/linux ou somente de GNU, então deveríamos considerar todos os outros projetos que utilizamos no Linux e que não fazem parte do GNU e que compoem o sistema operacional.

 Quando se fala de GNU, as pessoas só lembram do stallman; não nos lembramos de pessoas como Brian fox que foi o autor do Bash, do GNU Makeinfo, do GNU Info, do GNU Finger, thereadline e history libraries além de ter sido o mantenedor do GNU Emacs por um tempo (e há quem acredite que o Stallman que é o cara). Alias, em torno de 80% das pessoas nem sabem destas coisas e acabam dando créditos ao Stallman.

Brian Fox, autor do GNU Bash

 Muitos não se lembram de Mark Adler, que foi um os criadores do Gzip (e que inclusive é um dos responsáveis pela missão espacial para Marte).

Mark Adler, um dos autores do Gzip e um dos responsáveis pela missão de exploração ao planeta Marte.

 Muitos não se lembram de pessoas valiosas como essa. Já quando falamos de linux, o caso é o contrario disso; quem já esteve em um evento como a Linuxcon sabe que isso é bem diferente.

 Existem muitas ferramentas do GNU que são utilizadas no Linux, e disso todos nós já sabemos. Ferramentas como: GCC, make, Glibc, Bash, Coreutils, Emacs, Gzip e etc. A questão é que tais ferramentas são passíveis de substitução; é aí aonde a liberdade entra em cena.

 Então, para esclarecer esse assunto, selecionei aqui algumas dentre as muitas ferramentas que são possíveis utilizar no lugar das mencionadas do GNU. Não estou fazendo isso com a intenção de discussão, apenas procurando ajudar vocês a ampliarem seus conhecimentos e abrir os seus olhos para a gama de software de qualidade que o mundo proporciona.

LLVM

 LLVM (Low Level Virtual Machine) é uma coleção de compiladores modulares e reutilizáveis que foi iniciado como um projeto de pesquisa na universidade de Illinois. Está sob licença open Source UIUC no estilo BSD. que mencionam que pretendem mantê-lo permanentemente aberto.O Clang, compilador que mencionei no inicio deste artigo, que é uma alternativa ao GCC, faz parte do LLVM. A palavra Clang (pronuncia-se cléng) é uma onomatopeia em inglês do som emitido pelo metal. O Clang possui as características de compilação mais rápida, menor uso de memória e melhores ferramentas de diagnósticos como no modelo apresentado abaixo:

Comparação das ferramentas de analise de log do GCC e do Clang.

Há muitos recursos e atributos interessantes no LLVM/Clang para os desenvolvedores e pessoas que integram sistema podem tirar vantagem quando desenvolver ou implantar seus próprios projetos. Um outro recurso interessante mencionado no site do Funtoo Linux, é a sua capacidade de compilação de programas Leiam o artigo em http://www.funtoo.org/Clang ou leia na imagem abaixo:

Passe o cursor para ler a tradução.

 O FreeBSD foi o primeiro sistema operacional da família BSD a construir todo o seu Kernel com o CLANG (algo que ele se beneficiou já que a Apple foi a primeira a investir no LLVM) se livrando do antigo GCC que utilizavam (mesmo esse ainda baseada na GPLv2). O Debian já adota o clang, o Fedora também passou a adotar o LLVM/Clang, o Open Mandriva é quase 100% compilado com o LLVM, o Android e o OSX são 100% compilados com o LLVM/Clang.

 Existe o projeto da Linux Foundation que visa construir o kernel Linux totalmente utilizando o Clang. Foi de onde eu retirei a imagem do Tux com as asas e cauda de ferro. Um site realizou um benchmark entre os compiladores Intel C++, GNU C++ e LLVM Clang.

 Existem muitas empresas trabalhando e investindo recursos nesse projeto. Até mesmo a Microsoft está investido recursos financeiros no LLVM, pois irá basear o seu futuro .Net no LLVM.

Acompanhe a lista de empresas e projetos que utilizam o LLVM

 Na verdade, até aonde se sabe, existem quatro compiladores que são capazes de construir o kernel Linux sendo eles o GCC (que na verdade é o EGSC), o TinyCC do criador do ffmpeg, o ICC da Intel e o LLVM/Clang. Nos vídeos abaixo você pode conhecer melhor sobre os compiladores.

MUSL

 Musl (pronuncia-se mâssl) uma biblioteca C desenvolvida do zero. O site do Musl mostra um gráfico comparativo entre as bibliotecas C. A empresa OpenWall faz referência a biblioteca Musl por oferecer suporte nativo ao pacote TCB.

 Existe a distribuição Alpine Linux que faz uso dessa biblioteca ao invés da Glibc e do Busybox ao invés do Bash. Para quem não sabe o que é o Busybox, ele é conhecido como o canivete Suíço do Linux embarcado. É um conjunto de comandos dentro de um único executável. É o Busybox que fica dentro o initrd para o kernel utilizar no momento do boot. Foi originalmente desenvolvido por Bruce Perens que já foi presidente do projeto Debian assumindo o lugar de Ian Murdock.

Comandos do toybox 0.8.6

Lista de comandos no Busybox

Terminais de comandos (11/02/2022)

 Existem vários terminais de comandos disponíveis para Linux cada um tendo suas particularidades. Alguns deles o Zsh (que muito recomendo inclusive no meu curso e já até entrevistei o criador do Oh-My-Zsh), o Fish shell que galera gosta muito (e com razão), o Ksh (Kornshell), o csh (C shell), o tcsh, o Bourne Shell mantido por Jörg Schilling e o toybox que tem bastante conteúdo por aqui.

Pacotes de comandos (15/04/2022)

 Aproveitando que falamos de terminais de comandos, existem também pacotes com comandos complementares como no caso o CoreUtils do GNU que, semelhantes a esse são o embutils criado por Felix von Leitner (criador da dietlibc que eu acho incrível); o 9base de origem do plan9 e portado para outros sistemas operacionais; o sbase que é uma coleção de comandos herdados dos Unix e portados para 5 Unix diferentes e o ubase que já é específico para Linux seguindo  mesmo espirito do Util-Linux e está sob licença MIT e X; o ubase pode ser compilado com o GCC, LLVM ou TCC e é altamente recomendado compilar com a musl.

 Até mesmo os comandos do toybox que podem ser compilados separadamente. Porém, estes pacotes não fornecem apenas um conjunto básico de comandos não sendo o suficiente para ter um sistema operacional em funcionamento. Como exemplo, o coreutils não fornece comandos para formatar partições, configurar rede, gerenciar processos, drivers, serviços e muito mais (o argumento apresentado para tentar chamar o Linux de GNU/Linux é simplesmente muito superficial e utilizado pela equipe do GNU e da FSF para se promover). Estes comandos são fornecidos por outros pacotes sendo muitos deles do próprio Linux e alguns deles criados pelo próprio Linus Torvalds e outros com sua participação:

 Alguns destes pacotes podem ser conferidos clicando aqui: http://www.tocadotux.com.br/2018/02/mais-um-pacote-nao-gnu-procps-ng.html, http://www.tocadotux.com.br/2018/02/mais-um-pacote-nao-gnu-procps-ng.html.

XZ

 Tukaani, era uma distribuição derivada do Slackware (que merecia ter sido mencionada no meu vídeo sobre o Slackware devido a sua ótima contribuição) e que deu origem a alguns projetos. A distribuição não existe mais, mas as ferramentas que eram parte integrante da distribuição estão em pleno desenvolvimento.

 Em suas primeiras versões chamava-se de LZMA, é um compressor que nasceu na distribuição. O XZ hoje é utilizado fortemente pelo kernel desde de Dezembro de 2.013 e pelo Funtoo desde 2.008 (como mencionei no meu artigo parabenizando a equipe do Funtoo). O XZ apresenta melhor compressão do que o Gzip mesmo em compressões com o Gzip utilizando a opção "-9". Na verdade o XZ apresenta melhor compressão até mesmo que o Bzip2.

Star (11/02/2022)

 Eu conheci esse comando depois da live com o Luiz Anotnio do projeto Pindomara Copacabana. Start é uma versão do comando tar (dentro das conformidades POSIX 1003.1) com o maior desempenho que existe. Também de autoria de Jörg Schilling e mantido hoje por schilytools depois da morte de Jörg Schilling em Outubro de 2021 (este complemento é uma homenagem a Jörg Schilling). A Sintax do comando star pode ser conferido aqui na página do Fedora. Todos os projetos de Jeorg Schily podem ser conferidos aqui.

O comando star e suas opções de des/compactação.

utilizando o star para descompactar arquivos. Apenas um exemplo de uso uma vez que um arquivo muito pequeno (apenas 4KB).

CMake

Cmake é uma ferramenta build system cross-platform. Como postado do Diolinux no artigo sobre Linux ser o ambiente mais utilizado em C e C++, é possível ver que o CMake é mais utilizada do que o GNU Make.

Dentre os casos de sucesso do CMake podemos ver o Netflix, o KDE, o game Second Life, sistemas de robóticas, o MySQL entre outros. Um coisa que considero a equipe do CMake é a sua humildade.

Scons

 Falando de CMake, eu não poderia deixar de citar o Scons, que também é uma ferramenta de construção. Escrita em Python, o Scons visa ser um substituto para o tradicional make e que possui funcionalidade integrada semelhando ao autoconf/automake.
 Muitos já elogiaram o Scons; pessoas como Eric S. Raymond, authr de "A Catedral e o Bazaar", Timothee Besset da id Software onde menciona que o Linux build system do Doom3 utiliza o Scons e que é show. Essa já é a segunda vez que ouço que o Scons é utilizado em compilação de alguma coisa relacionada a jogos. Gosto de considerar a parte da avaliação envolvendo jogos devido sua dificuldade de programação que envolve inteligencia artificial, simulação de física, renderização e etc.

MK

O mk surgiu no sistema operacional Plan9 como um simples substituto para o make, mas que provê várias extensões, flexível e execução em paralelo. É possível compilar o mk também para Linux, BSDs (Free/Net/OpenBSD e Darwin), Solaris, HP UX e OSF1.

Smake e Makefiles de autoria de Jörg Schilling (11/02/2022)

 Smake é focado em alta portabilidade já que GNU Make não está disponível para todas as plataforma que o Smake (Linux, Windows (até MSDOS), MacOSX (e versões anteriores), Solaris, SSPM, PPC, HPUX, AIX), gnu make não permite realizar debugging no Makefile.

O comando smake e suas opções de des/compactação.

 O Smake possui também seu Makefiles que permitem montar uma source tree via NFS e simultaneamente compilar (e reutilizar) para todas as plataformas. Além do Cmake, do Scon, do MK e do Smake temos também o Ninja Buil e o Samurai é compatível com o Ninja Build (e até mesmo um concorrente direto).

Exemplo de uso do smake

Ninja Build, Samurais e Meson Build System

 Ninja Build foi criado por um desenvolvedor do Google o Google Chrome mas hoje é utilizado para construir partes do Android, do LLVM e pode ser utilizado em muitos projetos devido ao backend Ninja do CMake.

 O samurai é uma ferramenta de build compatível com o ninja escrito em C99 com foco em simplicidade, velocidade e portabilidade. O Meson® é um projeto que visa criar a melhor proxima geração de build system.

Man

 Apesar de muito conhecido, incluí o Man nessa história por que o GNU possui o seu próprio, o comando info. Detesto o info; hora ele é útil, a maior parte do tempo não.

QT 

É um framework muito conhecido por ser utilizado no desenvolver o KDE a interface do Netflix, do Android e muito mais. Menciono essa pois acho mais poderosa do que a GTK (apesar que nem o GTK, o Gim e nem o GNOME são projetos do GNU mesmo eles proclamando que são).

Existem muitos outros projetos que são possíveis substituir os do GNU como:

• Interfaces gráficas: KDE, Enlightenment, XFCE, LXDE, LXQT, RazorQT, Unity, Cinnamon, Mate, Window Maker, BlackBox, FluxBox. Quis mencionar aqui forks o e unity também (mesmo sabendo que ele é do Ubuntu).
• Shells: Tcsh, Zsh, o rc do Plan9 (que nessa brincadeira, podemos mencionar também o es), o elvsih que é um shell escrito na linguagem Go, o BusyBox que é utilizado pela distribuição Alpine Linux ao invés do Bash.
• Coreutils pode ser substituído pelos já mencionados o BusyBox (que alias, são mais utilizados que o Coreutils), o embutils, o 9base portado do sistema operaciona Plan9, o sbase do Unix original portado para outros unix que nesta lista inclui Linux. Vou incluir aqui o Uitil-Linux e o ubase pois, algo que os usuários de Linux precisam (e devem) saber é que, ao contrários do que todos imaginam, o Coreutils não fornece todos os comandos que utilizamos no sistema operacional, apenas uma pequena fatia deles, os comandos basicos para o usuário. Já os comandos para administrações do sistema operacional são fornecidos por outros pacotes.
• O Emacs é facilmente substituído pelo Vim, pelo Neovim, pelo OpenVi, pelo Neatvi, pelo Nextvi, pelo Joe e pelo vis que é um editor de texto parecido com o vi baseado nas expressões regulares do Plan 9. Existe um artigo de Oliver Webb ensinando a migrar do Neovim para o vis. Até no toybox terá sua própria implementação de vi. A quantidade de recursos de cada um é o que deve ser levado em consideração e isso para cada solução apresentada neste artigo. Alias, na verdade o Emacs não é um editor de texto do GNU. Como leitura, sugiro a leitura do meu artigo A verdadeira face de Richard Stallman.

 É perceptível que projetos fora do GNU ou até forks são em certos aspectos mais eficientes em seus propósitos. Não estou aqui difamando o projeto GNU, mas a mesma mensagem que deixo aos usuários de Windows envio também às comunidades de software livre de código aberto: Não devemos ficar presos unicamente à ideias ou paixões. O mundo é muito mais amplo do que possamos imaginar e podemos usufruir de tudo isso dando chance a outros projetos também. Adaptar ou morrer é um fato.

 Se uma ferramenta surge para bem e vindo a substituir a já existente, ela deve ser bem recebida. Isso é algo que acontece constantemente no Linux. Essas ferramentas vem para a melhoria das nossas próprias vidas. O que vejo é muita rivalidade inútil ao invés de foco na coisa mais importante, que é a melhoria contínua.

 Lembrem-se não somente do GNU, e sim de todos os projetos de open source que compoem o Linux (está muito longe de ter somente ferramentas do GNU presentes no sistema operacional). Lembrem-se de todas as licenças que também proporcionam e possibilitam a liberdade (GPL não é única. Existem em torno de 800 licenças). Lembrem-se de todas as pessoas que contribuem para esses projetos; graças a elas é que os projetos tem crescido e evoluído. E o mais importante unindo aos três itens mencionados, lembrem-se de serem livres (liberdade vai além da GPL, FSF e GNU).

• Todos os projetos de Jörg Schilling podem ser conferidos aqui.
• http://git.linuxfoundation.org/llvm-setup.git/
• https://events.linuxfoundation.org/sites/events/files/slides/2014-LCNA-LLVMLinux.pdf
• http://clang.llvm.org/features.html#libraryarch
• http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain.pdf
• http://llvm.org/devmtg/2013-11/slides/
• http://www.funtoo.org/Clang
• https://www.wiki.kernel.org/
• https://www.phoronix.com/scan.php?page=news_item&px=MTc3MDI
• http://br-linux.org/2014/01/llvmlinux-clang-esta-proximo-de-poder-compilar-o-kernel-linux-sem-modificacoes.html
• http://choosealicense.com/licenses/

MAS TAMBÉM NÃO DEIXE DE CONFERIR O MEU CURSO DE MIGRAÇÃO PARA LINUX E TORNE-SE UM VERDADEIRO PROFISSIONAL.