Dietlibc está de volta com novo lançamento? SIM! :D

dietlibc 0.34

 Esta é uma noticia um pouco tardia, mas depois de um bom tempo, Felix von Leitner que é o criador da dietlibc e de muitos outros programas, parece estar de volta a ativa. No final do ano passado, Felix lançou novas versões das bibliotecas dietlibc e da libowfat.

CURSO DE SHELL SCRIPT DO MATEUS MÜLLER

 dietlibc é uma biblioteca do Linux otimizada para tamanho que pode ser utilizada criar  binários pequenos estaticamente lincados para as arquiteturas alpha, arm, ia64, mips, mipsel, ppc, parisc, s390, sparc e x86. Já a libowfat é uma reimplementação da biblioteca libdjb que fornece interfaces de Daniel Bernstein ( com algumas extensões).

 A ultima versão da dietlibc havia sido lançada em 2013 e da libowfat em 2016 (o que não é tão tarde). No final do ano passado, Felix lançou a versão 0.34 de ambas as bibliotecas.

 Estas bibliotecas, mesmo que antigas, em versão beta e terem ficado um bom tempo sem atualização (nesse ultimo caso, me refiro a dietlibc) são muito importantes devido aos seus recursos estando ainda disponíveis em vários repositórios de muitas distribuições e até mesmo sendo utilizada em programas atuais. Confiram o vídeo abaixo sobre a ditelibc e vejam como tal biblioteca é interessante:

Houveram muitas mudanças e melhorias nessa nova versão da dietlibc como a adição de novos recursos, de seguraça, correções de bugs:

Mudanças na dietlibc 0.34

 Já na libowfat foram poucas e mais simples de relatar aqui como remoção de warnings do OpenBSD por informarem não ser mais necessário, moveram os headers para <libowfat/> no install, correção no fix fmt_ip6 feita por Erwin Hoffmann, adição de suporte a MSG_ZEROCOPY [somente utilizado para buffers menores que 8k (>8k)], uso de writev em buffer_put para uma leve melhoria no perf, adição da experimental da API iom para multithreaded I/O multiplexing (em io.h)

Mudanças da libowfat retirado na integra daqui

 Eu decidi baixar a nova versão e testar a dietlibc compilando novamente o embutils assim como já havia feito no vídeo "Dando uma olhada no embutils" que é um pacote com conjunto de comandos que já utilizamos diariamente como ls, cp, dd e muito mais. Esse pode ser um substituto para o core utils do GNU apresentando tamanhos muito enxutos mesmo linkados estaticamente (conforme a dietlibc promete ser). O comando ls do embutils por exemplo tem 20k linkado estaticamente enquanto que o ls do core utils tem 128k linkado dinamicamente. Simplesmente surpreendente.

 Caso queira saber como compilei o embutils utilizando a dietlibc, confira o vídeo abaixo:

 Durante o processo de compilação houve alguns warnings, mas nada assustador.

 Testei o dd do embutils (que é um comando do GNU que eu gosto muito e podemos dizer que no Linux tem) gerando um arquivo vazio e depois criando mais swap com o mkswap do toybox (lembrando que mkswap não é um comando do GNU, e sim do próprio Linux fazendo parte do pacote Util-Linux mantido por karel Zak da Red Hat, mas quis testar o mkswap do toybox também).

comando dd no embutils compilado com a dietlibc 0.34

mkswap do toybox

Baixe, teste, experimente e faça uso de ambas a bibliotecas. Aproveite para conhecer os outros projetos do Felix (inclusive seu init system, o minit) bastando clicar aqui

Uma ótima leitura também é se há a possibilidade de deixar o kernel Linux menor se usarmos a dietlibc ao invés da glibc?

 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 

Bug no terminal de comandos Bash e comparação entre os pacotes de coleções de comandos

 Bom, fiz os vídeos onde demos uma olhada no toybox, Respondemos a comentários interessantes, demos uma olhada no embutils e no 9base. Depois disso me lembrei que no artigo "Android, uma boa alternativa ao Windows no desktop" que escrevi há mais ou menos dois anos atrás e que percebi um bug no Bash. A questão é que na época eu conferia a quanto tempo o android estava em funcionamento tanto pela configuração do sistema operacional quanto pelo comando uptime.

 Fiz uso na época de alguns terminais (que não me lembro o nome) e um deles era o terminal Bash para o Android. O Bash retornava valor errado de horas em execução pelo comando uptime, não combinava com o relógio do android e nem com dos outros terminais que estavam sendo utilizados. Foi aí que passei a me preocupar se todo resultado obtivermos no terminal são verídicos ou não, e por isso adotei a estratégia de conferir os resultados em dois ou mais terminais de tempos em tempos somente para me certificar.

Consegui recuperar as imagens da época que fiz a analise e aqui estão algumas mostrando a quanto tempo o sistema está em funcionamento tanto pelo sistema de estado do próprio android quanto pelo bash fazendo uso do comando uptime:


Reparem nas duas primeiras imagens que o android já estava no em funcionamento hà mais de 252 horas (10 dias e meio) enquanto que o bash informa que o sistema está em funcionamento a somente 8 dias e 3 horas.


Reparem agora nesta duas que o android consta mais de 254 horas (e está correto de acordo com o relógio exibido no canto superior direito sendo o total de 10 dias e 14 horas) enquanto que o bash permanece 8 dias e 4:36.


Tudo bem, foram no mesmo dia, então esperei mais um tempo e agora o android consta mais de 273 horas (totalizando de 11 dias e 9 horas e meia) enquanto que o Bash permanece 8 dias e 23:05. Nesta ultima imagem, conferam a data e hora com o comando date que e o bash retornou 21:10 sendo que a hora real era 18:10).

Eu não sou o único que já reparou isso, esta imagem abaixo é de um membro do grupo Linux aprendendo  no Telegram onde relata que a partição /dev/sda4 pelo gparted está em NTFS enquanto que no Bash consta FAT16 a mesma partição. Porém o Windows também reconhece como NTFS:

Confiram o o sistema de arquivos no partição /dev/sda4 fornecida pelo Gparted e pelo Bash. Esta imagem é na distribuição Kali Linux

Esta ultima imagem é outra situação que aconteceu durante o processo de escrever este artigo. Eu utilizei o comando du (disk used) para conferir o tamanho final do binário do toybox após compilá-lo e o bash me retornou que o toybox tinha apenas 56k; repeti a operação e obtive o mesmo resultado. Depois utilizei o comando o du do próprio toybox que tenho instalado na minha máquina, para através dele também conferir o resultado final do tamanho do novo binário que compilei e o resultado foi que o comando du do toybox me retornou que seu tamanho final era de 328k (e não 56k como exibindo pelo du do coreutils...) Quando dos dois então estão certos? Após isso, para desencargo de consciência, resolvi mais uma vez utilizar o comando du do próprio bash que me retornou o valor de 328k e não 56k como ele havia me retornado das duas primeiras vezes... Bem conflitante. Não?

O comando du utilizado no bash (pacote coreutils) consta que o arquivo toybox é do tamanho de 56k, depois o mesmo comando no toybox e depois o mesmo comando no bash novamente

Esta não é a primeira vez que situação assim acontece e considero até mesmo um alerta para a adoção de outros terminais como Zsh e Fish como terminal de comandos principal. Este é um bug de longa data que volta e meia acabo vendo.

Neste artigo resolvi comparar os pacotes coreutils do GNU, o embutils, o 9base e o toybox para certificar se estes entregam os mesmos resultados ou se retornam valores diferentes, tamanho final do binário, licença e muito mais.

Deu trabalho calcular o tamanho final do 9base uma vez que os comandos ficam todos dispersos estando cada um em seu próprio diretório (diretório = pasta para caso você que esteja lendo seja usuário novo no Linux) e cada diretório não contem unicamente o próprio comando (diferente do embutils que concentra todos os comandos em um único diretório quando compilados). Então criei um diretório, copiei somente os binários para dentro dele e assim calculei o tamanho final dos comandos do 9base.

Diretórios do 9base onde concentram os comandos sepadaramente. Clique na imagem para aumentar o tamanho.

O diretório bin-x86_64 é aonde o embutils concentra todos os comanos após a compilação. Clique na imagem para aumentar o tamanho.

As comparações aqui são feitas entre as licenças utilizadas, se são linkados dinamica ou estaticamente, o tamanho final dos binários, a descrição da saída da opção --help dos comandos para obter informações precisas de como utilizá-los e por fim o resultado das saídas dos comandos.

Utilizamos aqui os comandos df e du -s para verificar se os resultados coincidem; o único comando que não utilizamos no 9base foi o df, pois o 9base não possui tal comando. Os testes (básicos) aqui realizados usando comandos como du, foram feitos em diretórios como meu próprio home. No meu home mesmo por exemplo, enquanto o 9base retornou o resultado 12111218d (12113235d com a opção -sh... tipo... hein?), todos os outros retornaram o resultado 12244176 (12G com a opção -sh).

Clique na imagem para aumentar o tamanho.

Os resultados pode ser conferidos logo abaixo:

Clique na imagem para aumentar o tamanho e conferir o resultado dos pacotes.

Há quem vá dizer que não acha justo incluir o Bash nessa história; não seria então incluir o toybox também. Ou vai haver quem diga que não é justo incluir o toybox nesta comparação; a questão é que o toybox concentra todos os comandos dentro de si, e não dispersos. Fora que ele fez parte da série, dando uma olhada ;)

Vale Lembrar também que o tamanho final dos arquivos pode variar por filesystem conforme descreve no artigo Benchmark de filesystems.

De todos, o que menos me agradou foi literalmente o 9base. Não adianta o 9base estar sob a licença MIT (que é uma licença que vem tendo sua adição cada vez mais crescente) mas gerar binários exageradamente enormes, ter fracas descrições com a opção --help e ainda apresentar resultados duvidosos e de difícil leitura (digitem o comando ls do 9base e confiram que desastre).

Porém, também não adianta o embutils ser tão pequeno (apesar que isso é muito bom :), tão exulto (admirável demais isso) e ter as mesmas fracas descrições na opção --help que o 9base... (apesar que possuem manpages para os dois, essas descrições se tornam problemas fáceis de serem solucionados) e também adotar a GPL mesmo que seja a versão 2. Poderia ao menos ter adotado a MPL. Ao menos seu resultado não é duvidoso.

Também não adianta o coreutils ter boas descrições com a opção --help mas ter binários grandes (o coreutils não fica longe do 9base se consideráramos que o coreutils ser dinamicamente lincado) e adotar a GPLv3 (versão totalmente conflitante com ao GPLv2 e GPLv2+). Fora seus resultados poderem ser bem duvidosos.

O que apresentou melhores resultados foi o realmente o toybox podendo reunir as melhores características de cada um:

• Licença flexível para uma época onde a GPL se torna fragmentável
• tamanho final do binário bem enxuto (melhor que o próprio embutils)
• Pensado na segurança, estabilidade e desempenho
• Boa descrição de informações (de forma mais alinhada que do próprio Bash+coreutils)
• Resultado da saída do comando confiável

Uma pena ainda não ser possível utilizar o toybox como terminal de comandos padrão como no caso do Android, mas espero que não demore muito a se tornar uma opção para as distribuições que utilizamos (em especial o Alpine Linux), o que é algo que a comunidade toybox trabalha para que aconteça. Porque, ficar digitando o comando toybox toda vez que quero usar um comando é desagastante. Na verdade ainda não abandono (de forma alguma) o Zsh e está espero que venha a se tornar o terminal de comandos padrão nas distribuições.

Já perceberam que não coloquei o coreutils como vilão da história como muitos ACHAM que eu odeio GNU. Porque a paixão excessiva por parte dos amantes do Gnu em suas cabeças é tão grande que isso não permite que eles vejam que estou fazendo analise técnica. Porém também não estou escrevendo este artigo para desmoralizar o 9base. Somente não o adotaria hoje por não atender nenhuma das expectativas em um conjunto de comandos. Quando adotarem um terminal, pesem na balança se o que obtemos é real ou não. pretendo ainda fazer uma análise ainda um pouquinho maior sobre esse comandos. Vamos ver o que teremos de resposta ;)

E o estudo não para por aqui. Depois de quase concluído este artigo, descobri novas coisas que gerarão outro estudo. Até o próximo artigo.

Agradeço ao Hilton Vasconcelos pela imagem fornecida do Kali Linux mostrando a partição /dev/sda4 no Gparted e no bash.

• Benchmark de filesystems
• Android - uma alternativa aos desktops
• A queda da GPL

É possível deixar o kernel Linux menor se usarmos a diet libc ao invés da glibc?

Talvez depois do vídeo sobre o embutils tenha surgido a seguinte duvida: Se compilar programas utilizando a diet libc torna os programas menores, será então que é possível compilar o meu kernel utilizando a diet libc e torná-lo também menor?

A diet libc é uma biblioteca C que focada na otimização de tamanho dos programas (mesmo sendo utilizada estaticamente).

Tenho dois vídeos sobre a diet libc, um contando sua história e o ultimo sobre o embutils, uma vez que a diet libc é uma dependência do embutils. No primeiro vídeo também explico suas características e acredito que é uma grande solução:

Na FAQ (Frequently Ask Questions) do próprio projeto diet libc descreve o seguinte:

Q: Por que ela não é compatível com a glibc? Eu achei que a interface fosse um padrão?
A: sim, a interface é, mas um monte de detalhes estão faltando. Por exemplo, a diet libc utiliza um layout de "struct stat" diferente da glibc. Nós utilizamos uma do kernel, glibc utiliza uma própria e linka translation code (código de tradução). Essa é a parte da razão porque a glibc é tão grande e tão feia. Se tivéssemos suporte a tudo isso, terminaríamos inchados quanto a glibc.

A glibc sempre teve esse grande defeito de gerar binários grandes demais e a equipe do projeto GNU nunca se importou com isso. O raciocínio apresentado por eles é basicamente o seguinte: "Com a quantidade crescente do poder do hardware, porque devemos nos preocupar com isso?"
E esse é até mesmo um erro cometido pela comunidade GNU. O projeto GNU e BSDs são muito bom no quesito recursos, porém não no resultado final de binários quando o quesito é tamanho. Tanto que antes de diet libc já havia surgido a uClibC para que pudessem estender Linux ao uso de embarcado (uma vez que é quase impossível utiliza glibc em embarcados).

Mais uma coisa que deve ser escolarecida sobre a diet libc é que já dizerem que a esta biblioteca originou do FreeBSD e foi portado para Linux. Na verdade não, essa biblioteca também é própria do Linux como descrito na mesma FAQ:

Porgunta: Pode portar a diet libc para FreeBSD/Solaris/Windows, por favor?
Resposta: Não.

Resposta grosseira; não? Mas no próprio site da diet libc consta em sua descrição que ela pode ser utilizada para criar para Linux binários pequenos lincados estaticamente nas arquiteturas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc e x86_64.

Bom, eu já postei um artigo complementar no blog Diolinux que vale a pena conferir, pois faço um complemento ao vídeo abaixo e até mesmo mostro o mesmo comando uname que mostra em sua saída o termo "GNU/Linux" assim como no toybox:

Bom, puderam ver como os binários ficam pequenos mesmo tendo biblioteca estaticamente linkada. Surge então a pergunta após ficarmos impressionados com isso. Isso significa que é possível compilar meu kernel Linux com a diet libc ou outra biblioteca do Linux e obter como resultado um kernel menor? Na FAQ mesmo menciona que utilizam um layout do kernel; logo significa que é possível?

A resposta: NÃO!
POR QUE? :(

Bora responder a pergunta. Como descrito na própria FAQ da diet libc:

Pergunta: Devo compilar meu kernel com a diet libc?
Resposta: O kernel não é lincado a nenhuma libc. De fato, a libc é a interface do user space para o kernel. Então, a não ser que você esteja falando sobre o "user mode linux" (que é uma versão especial do kernel que ocorre ser um programa user space), você não consegue lincar o kernel a diet libc.  Lincar o user space Linux com a diet libc deve ser possível em teoria, mas eu não acho que alguém já tentou de verdade.

Explicando melhor a função das bibliotecas C pode ser lido também na FAQ da Musl que descreve o seguinte:

Passe o cursos do mouse para ler a tradução do texto

Então sempre tenhamos em mente, a biblioteca é para os programas que utilizamos no user space, não para o kernel. O kernel é independente da biblioteca. Linux é um kernel que cresceu e evoluiu para mais do que um kernel tendo bibliotecas, comandos, terminais, init systems e muito mais. Exemplos de bibliotecas do Linux além da diet libc temos a Bionic do Android, a musl, a UclibC, a  newlib e klibc.

• Artigo no blo Diolinux
• FAQ da diet libc 
• FAQ da musl

Lançado toybox 0.8.10

 No dia 30 de Julho, foi lançada a versão 0.8.10 do terminal de comandos Toybox, depois de uma espera de mais de seis meses desde o lançamento da ultima versão. Acredito que foi devido as apresentações que andaram fazendo sobre o j-core no Japão (e que eu particularmente estou ansioso por isso). Bom, foi adicionado o novo comando shuf, e o Elliott adicionou o comando i2ctransfer. Foi concluído as limpesas no comando dd e saiu do diretório pendente. Fazendo a minha observação sobre o comando dd, eu testei e acabei gostando muito pois, honestamente, conheço outras implementações do comando dd e o do GNU é o que mais me agrada devido as suas opções como status (opções em comandos é algo que me agrada muito). Veja abaixo uma comparação entre o dd do embutils e do toybox.

Comando dd do terminal toybox

Comando dd do pacote embutils

NOVAS OPÇÕES DE COMANDOS JÁ EXISTENTES

 Também foi adicionado ao comando dd suporte a POSIX 1x2x3 (com detecção overflow). O comando tar recebeu novas opções como -s, --ignore-case, --wildcards, --anchored, --wildcards-match-slash, --one-file-system. O comando ls recebeu a opção --block-size e melhoria na opção --sort, o comando cpio recebeu as opções -R que permite definir  user/group de todos os arquivos e a opção -L segue symlinks; o comando gzip recebeu a opção -t para realizar teste de integridade de arquivos, find recebeu a opção -readable,  a opção -DFR do comando cut (que é um dos melhores cut que eu já utilizei) agora possui --longopts aliases (como sugerido pela lista do coreutils). o comando oneit agora auto-detecta console a partir do sysfs, o comando i2cget recebeu suporte a next address para melhorar a bus limit (além de Jarno Mäkipää ter ensinado o comando i2cget a fazer leitura sem passar um byte de comando) e o lspci recebei a opção -x (referente a hex dump do espaço de configuração do pci). Também foi ensinado ao comando blkid a reconhecer imagens ISO.

O toysh

 Se tem algo que todos andam esperando com ansiedade é o toysh (também englobam os comandos sh e bash. Sim, o toybox possui o comando bash) pois tendo um terminal de comandos compatível com  scripts de outros terminais, você acaba possuindo um terminal de comandos que torna o seu sistema operacional independente e possível de ser executado como terminal de comandos padrão. Eu reportei alguns bugs durante a versão 0.8.6 mesmo sabendo que o comando toysh, sh e bash ainda estavam como pendentes.

 E o trabalho tem sido bem intenso sobre este comando até mesmo por parte do Google. Agora, vamos verificar o estado do toysh. Nas notas de lançamento, Rob Landley descreveu:

"Análise de opção de linha de comando para no primeiro argumento nonoption, todos os segmentos canalizados agora estão implicitamente subshelled então os tempos de vida variáveis correspondem aos do bash e loops não precisem sair antes de prosseguir para o próximo (ala "while true; do echo hello; done | while read i; do echo $i; done" pendurado em toda a saída de um pipe). Várias mudanças para o processamento de HERE document* (expansões variáveis podem causar continuações de linha em um HERE document, etc), e melhor manipulação de continuação de linha em geral, adicionado set -u, corrigido retorno de códigos if/while, conectado ao builtin "local", corrigido um bug de passagem de escape relatado por Mingliang Hu, suporte a redirecionamentos não delimitados (ala cat<file sem espaços), corrigido ${X::} sem argumentos."

 Ainda não realizei os mesmos testes, mas em breve pretendo. Houveram também, como sempre, muitas correções de bugs, limpezas, portabilidade, melhorias no build, implementações de recursos na biblioteca do toybox, melhorias na Test suite e na documentação. Os comandos do diretório pending também receberam melhorias como como o git, correções de bugs nos comandos init e login, suporte a risc-v no comando strace, correção na opção :w e -s do vi (além de terem o ensinado a respeito de backspace e melhoria em lidar com arquivos vazios) e várias limpesas no tcpsvd.

 O mkroot (que é a distribuição voltada somente para teste de implementação do toybox, mas que o Google demonstra interesse nessa distribuição para outros projetos) recebeu várias melhorias

*HERE document, também podendo ser abreviado para heredoc e outras formas, consiste na sintax << e here string em <<<.

• Todas as novidades do toybox 0.8.10 podem ser conferidas clicando aqui.
• Mais sobre o toybox pode ser conferido tanto aqui no blog quando no meu canal
• Mais sobre o processador J-core pode ser conferido clicando aqui.

Quer aprender Linux de verdade? Então confira o meu curso de migração para Linux clicando aqui 

PAGORA TAMBÉM DISPONÍVEL NA PLATAFORMA WORKOVER

Quer aprender Linux de verdade? Então confira o meu curso de migração para Linux clicando aqui 

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

Advanced Copy: Adicionando barras de progresso aos comandos cp e mv

 Essa é uma opção que eu realmente sempre senti falta que existisse em comandos como cp, mv, rsync e rm. A opção -v (ou --verbose) não necessariamente atende tal expectativa já que o terminal fica estático enquanto não conclui a cópia. Desta forma não sabemos o que realmente está acontecendo (o que fazer? abrir outro terminal e digitar watch du no arquivo e ficar acompanhando o progresso?)

 O comando dd já incorpora algo muito interessante que é a opção status seguido de progress e assim sabemos o que realmente está acontecendo. Então seria muito interessante se incorporassem algo parecido a tais comandos.

 Foi pensando nisso que Mischievous Meerkat (também conhecido como jarun) escreveu há cinco anos atrás o patch advcpmv (abreviação de Advanced Copy para os comandos cp e mv). O patch advcpmv permite adicionar a opção -g aos dois comandos e assim acompanhar o progresso do seu trabalho.

 Cinco meses atrás Jarun portou seu patch para o GCC 10 e há uma semana lançou a versão 0.8-8.32. Para utilizar o patch advcpmv, basta seguir as instruções (que basicamente consiste em baixar o coreutils, baixar o advcpmv e adicioná-lo ao coreutils com o comando patch -p1 -i advcpmv-0.8-8.32.patch). Depois é só configurar, compilar e instalar.

 Honestamente, na minha opinião, esse é o trabalho que deveria ser realizado pelo projeto GNU ao invés de gastarem tanta energia com retoricas de liberdade ou ameaçando processar empresas e projetos.  Na verdade essa é uma opção que deveria ser uma saída padrão (nem precisando digitar a opção -g). Espero poder ver no futuro esse mesmo patch no toybox e no embutils.

Mais sobre o toybox

Mais sobre o embutils

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

 E NÃO DEIXE DE CONFERIR TAMBÉM O MINICURSO DE ATRIBUTOS NO LINUX

V coreutils: Um coreutils escrito na linguagem V

 No ano passado eu escrevi o artigo uutils: Um coreutils escrito na linguagem Rust. Neste artigo eu mencionei que existia outro coreutils escrito na linguagem V (The V Programming Language (vlang.io). V é uma linguagem de propósito geral que foi projetada para ser simples e fácil de manter,  para oferecer bastante poder e poder ser utilizada em quase todos os campos como sistemas operacionais, web, jogos, interface gráfica, dispositivos móveis, ciência, embarcados e muito mais. Existe até mesmo um sistema operacional chamado Vinix escrito na linguagem V e que já roda Bash, GCC e V.

Vinix: Um sistema operacional escrito na linguagem V

 V é similar a linguagem Go contendo melhorias que podem ser conferidas aqui e também influenciada por Oberon, Rust, Swift, Kotlin e Python. Vale lembrar que a linguagem V ainda está em versão beta (versão 0.4.4 no exato momento que escrevo este artigo) e o autor afirma que não haverá muitas mudanças, apenas melhorias.

Hot code reloading em V. altere as coisas instantaneamente sem recompilar.

 Agora vamos a o que nos interessa que é o coreutils escrito na linguagem V. o V coreutils visa ser uma versão do coreutils mais próximo possível das especificação POSIX e  com muitas extensões GNU (nisso o GNU é muito bom: extensões. apesar que a maior parte delas não foi desenvolvida pelo projeto GNU). A equipe procura desenvolver a implementação de cada comando mas que não seja 100% de paridade, especialmente peculiaridades e efeitos colaterais não intencionais. O V coreutils está sob a licença MIT.

 Eu resolvi compilar e testar os comandos do V coreutils e uma boa parte deles estão prontos; um total de 56 de 109 comandos. O processo de compilação é simples; primeiro baixe o V coreutils utilizando o comando:

git clone https://github.com/vlang/coreutils.git

 Ou baixe o pacote .zip. Com o compilador V instalado em sua máquina, digite o comando

v run build.vsh

 O processo de compilação leva pouco mais de 6 segundos para concluir (sim, muito rápido).

Tempo do processo de compilação do V coreutils

 A principio aqui ocorre um problema. Assim como ocorre com o Rust coreutils, achei o tamanho dos binários exageradamente enorme. O resulta do processo de compilação é um diretório bin de 60MB e facilmente cada binário ocupando 1MB mesmo linkados dinamicamente... O que é um exagero se levarmos em conta que cada binário deveria ter apenas bytes...

 Porém, eu consegui a informação com o Alexey, autor da V lang, para tentar executar o comando v -prod -skip-unused file.v. Unindo essa informação com a que eu encontrei dentro do arquivo Makefile, eu encontrei a solução de otimização dos binários executando:

v run build.vsh -prod -skip-unused

 O processo de otimização dos binários leva bem mais tempo para concluir (desta vez ~2.30 minutos para a conclusão) porém gerou binários bem menores, alguns tendo tendo 100K - 200K; alguns ainda continuaram grandes, mas OK. O diretório bin no final ficou com 11MB (quase seis vezes menor do que o anterior). O comando cp por exemplo, que anteriormente ocupava 1MB (1008K), passou a ocupar 200K ao ser otimizado. Ainda os considero grandes, mas já é um ganho enorme.

V coretutils tempo de compilação de binários otimizados

Resultado do tamanho dos binários após utilizar as opções de otimização.

BUGS E REPORT

 Erros ainda serão visíveis. Temos que levar em conta que se trata de um programa que ainda está em sua versão 0.01, sendo desenvolvido em uma linguagem que ainda em versão beta e que faz uso de certa forma do compilador TinyCC que ficou parado por um longo tempo.

 Então se trata de um baita desafio pela frente. Por exemplo, o comando mkdir já passou na maioria dos testes manuais, mas um bug é fácil de reproduzir. Quando se cria um diretório com a opção -m e definindo as permissões que deseja (644 neste exemplo para fins de testes), ao listar o diretório criado você descobre que diretório foi criado com as permissões de escrita para o proprietário (w sendo que selecionamos leitura e escrita), leitura para outros e stick bit sendo que não selecionamos a opção de stick bit. Este é um bug que vou reportar mas também preciso descobrir se esse é um comportamento que o projeto já havia planejado

 O comando cp, ao tentar copiar um diretório para outro não existente, cria um arquivo vazio.

CONCLUSÃO

 Como já mencionei outras vezes, não existe GNU/Linux uma vez que nem todas as ferramentas que utilizamos nas distribuição são do GNU (alias, elas são a minoria) e as do GNU são substituíveis. Esse já não é o primeiro pacote de comandos que eu apresento aqui, facilmente podemos contar alguns como o embutils, o 9base, o ubase, o Rust Coreutils, o V coreutils, o FreeBSDcoreutils o ChimeraCoreutils e podemos utilizar também busybox ou o toybox e ainda mais outros podem existir.

 SEJA LIVRE DE IDEOLOGIAS INUTEIS.

O coreutils na linguagem V pode ser baixado aqui

Mais sobre o coreutils pode ser conferido aqui

Toca do Tux: A queda da GPL?

 

Quer aprender Linux de verdade? Então confira o meu curso de migração para Linux clicando aqui 

PAGORA TAMBÉM DISPONÍVEL NA PLATAFORMA WORKOVER

Quer aprender Linux de verdade? Então confira o meu curso de migração para Linux clicando aqui 

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