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:

Aqui mostra que o sistema está de pé hà mais de 252 horas
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?
Eu utilizei o comando du (disk used) no bash contra o binário do toybox para conferir o seu tamanho final ao compilá-lo e o bash me retornou que o toybox tinha apenas 56k. Depois usei o du do proprio toybox que me retornou que seu tamanho final era de 328 e depois usei o comando du novamente no bash que me retornou que o tamanho do toybox era de 328...
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.
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.
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:
comparacao-entres-os-pacotes-de-comandos-coreutils-embutils-9base-e-o-terminal-de-comandos-toybox
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.

É 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:

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:
musl é uma “libc”, uma implementação de funcionalidade de biblioteca padrão descritos na ISO C e nos padrẽos POSIX, mais extensões comuns, destinadas a uso em sistemas baseados em Linux. Onde o kernel (Linux) governa acesso ao hardware, memória, filesystems, e privilégios para acesso desses recursos, a biblioteca C é responsável por fornecer as aplicações reais do userspace das interfaces da função C e para a construção de bufferd stdio de alto nível, gerenciamento de alocação de memória, operações de criação de thread e sincronização e assim por diante utilizando interfaces de baixo nível que o kernel fornece, assim como para a implementação puras rotinas de biblioteca da linguagem C como strstr, snprintf, strtol, exp, sqrt, etc.
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.

Gameplay de FOX n FORESTS 2018

Beleza galera? Saiu mais uma gameplay do game Fox n Forests (e que ainda vou sortear a demo). Sim, o game está demorando para ser lançado; era para ter sido lançado na primavera do ano passado e agora adiaram para a primavera deste ano. Porém adiar lançamento é algo que acontece em outros games também; o que não pode acontecer é deixar de ser lançado, aí o resto está tudo certo.

Fox n Forest é um game tribute aos consoles Mega Drive e Super Nintendo que constituíram a época de ouro dos consoles.

Resolvi fazer uma analise do game para lhes dizer o que estou achando. Confirma então aí a gameplay:



Bom, a principio o que mais gostei foi as cores do game, Fox n Forests é bem rico neste detalhe não deixando o game muito pixelado mesmo sendo fiel aos games de 16 bits da época do Super nintendo e Mega Drive. Acho que este é um aspecto que gostei demais e que mais queria ter visto nestes consoles, pois a Bonus Level entertainmente não limitou o game ao hardware dos consoles da época dos 16 bits.

A qualidade qualidade e audio mantiveram até fiel, mas acho que não precisaria ser tão fiel e apesar que os games de 16 bits (dependendo do game) em certos aspectos tinham até o áudio um pouquinho melhor.

A jogabilidade de Fox n Forests ficou extremamente fiel ao consoles; fizeram um real tributo ao Super Nintendo e ao Megadrive.

agora vamos aguardar para ver :)

Defendendo novos usuários de Fedora

os-quatro-f-do-fedora
Os quatro Fs do Fedora
Hoje falo em defesa dos novos usuários de Fedora que com boa vontade querem aprender a usar a distribuição; pois no final de semana passada aconteceu algo que achei ridículo por parte de um grupo que se denomina os bons de Fedora Linux. O que me irrita é a hipocrisia por parte do grupo em que a única cordialidade que vi por lá é ao receber novos membros do grupo com um "seja bem vindo fulano". Depois disso criticam novos usuários e ainda os apelidando de geração Nutella (acho esse termo um tão quanto pobre) quando perguntam como instalar Virtual box ou Java ou outros programas que eles acabaram criando uma listinha negra que envolvem:
  • Virtualbox
  • Warsaw
  • MySQL
  • Java
  • Flash
São tão espertos que nem sabem que a licença padrão do Virtual Box está sob licença GPL (quer dizer, estão lutando contra si mesmo) e envolve outras parte sob licença como a CDDL (que deriva da MPL e que por sua vez deriva da GPL), Java é parte GPL e parte Java Community process, MySQL é parte GPL e parte comercial. Deveriam estudar mais ao invés ficarem formulando uma listinha negra onde definem quais programas são uma heresia e quem os usam são hereges.  E mesmo software pago, ou simplesmente proprietário ou não aberto, é feito para ser utilizado e não adorado.


Depois dessa palhaçada toda, muitas pessoas saíram de lá e criaram um novo grupo Fedora Brasil, só que sem frescura. Quero ver se esse leva a sério os ideais reais do Fedora (se não a gente dá porrada neles também kkkkk).

Compre na imago brinquedos

Compre na imago brinquedos
Utilize o cupom de desconto TOCADOTUX e ecnomize 5% na sua compra