Busybox X Coreutils

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 12:27h

Camaradas do Viva o Linux, tudo bem?

Venho por meio deste iniciar uma discussão acerca dos softwares utilizados na formação da 'userland' nos nossos SO.

Bem, como é sabido, uma boa parcela dos softwares utilizados nas distribuições baseadas no kernel Linux são do projeto GNU. Algumas pessoas classificam o SO como GNU/Linux, justificando que tais distros não seriam utilizáveis sem o projeto GNU.Tenho uma opinião contrária e pretendo mostrar o por quê tal ideia é equivocada: apesar do projeto GNU ser admirável em sua filosofia, a software distribuído por ele não é tão bom.

Comecemos pela userland, como já foi introduzido.

Atualmente, a maioria esmagadora das distros utilizam o coreutils [0] para tal função. Essa é a definição oficial do projeto: " The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system.". Observando-a, podemos concluir que, como o nome sugere, o coreutils tem a intenção de prover ferramentas básicas para o funcionamento do sistema operacional GNU.

Aparentemente, o trabalho é feito com maestria: tal pacote é quase universal nos SO baseados no kernel Linux. Entretanto, existem alguns projetos que fazem um trabalho semelhante (senão igual).

A maior e mais famosa alternativa é o Busybox [1]: "BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system".

Interessante, não? Como você leu, o Busybox é um projeto que combina, em um único binário, as ferramentas mais básicas e populares do UNIX e GNU coreutils (sim, o fileutils e shellutils estão "embutidos" no coreutils [2]). Entretanto, diferentemente do coreutils, o Busybox tem em mente duas metas: prover um ambiente completo para sistemas UNIX-like e funcionar em lugares com 'poucos recursos'. Mas, será que ele está preparado isso? Bem, podemos dizer que sim. Existem projetos que o adotam como userland. O mais famoso e bem sucedido em Desktops/Servidores é o Alpine Linux. Toda a userland de tal é construída somente com o Busybox.

Dada a introdução, observemos algumas diferenças entre os dois projetos:

Busybox

- um único binário multi-call por padrão;
- configuração feita a partir de um menu em dialog;
- otimizado para 'o tamanho';
- compatível com as 'opções longas' características do projeto GNU;
- inclui diversos softwares de outros projetos (debian, runit, selinux, util-linux, e2fsprogs, sysklod);
- dependências básicas: libc e sh POSIX, GNU Make e um compilador C (não achei referências a outros compiladores, mas funciona do tcc e gcc);
- saídas pouco verbosas
- construção da userland a partir de links simbólicos (e.g busybox ln -s /bin/busybox ln );
- não oferece man pages muito grandes e explicativas;
- extremamente pequeno (o pacote busybox-static do Alpine, com quase tudo 'ativado', tem aproximadamente 936KB);

Coreutils

- pode ser construído como um único binário ou em arquivos separados (ver configure);
- configuração feita a partir do script "configure" (opções, basicamente);
- compatível com 'opções curtas e longas';
- 'código original';
- dependências básicas: libc e sh POSIX, GNU Make e um compilador C (mesmo caso do busybox, testei com o gcc);
- saídas muito verbosas
- construção da userland a partir de binários separados e/ou links simbólicos;
- manpages gigantes e cheias de exemplos;
- extremamente grande (todas as aplicações, compiladas 'por padrão' e estaticamente linkadas, somam quase 45MB);

Bem, essas foram algumas das diferenças que eu encontrei utilizando os dois softwares como userland. Atualmente utilizo o Busybox como userland e estou muito satisfeito.
Ficaria extremamente grato se os senhores falassem o que acham dos dois projetos, qual é o mais rentável, pontos relevantes, etc.
Qualquer erro, por favor, corrija-me.

[0] https://www.gnu.org/software/coreutils/coreutils.html
[1] https://busybox.net/about.html
[2] https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Fileutils-shellutils-and-textutils

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 13:26h

1- O bom de um binario unico é que evita a repetição de codigo, resultando em um tamanho final ridiculamente menor.
4- Adicionar compatibilidade fora dos posix (que já tem coisa desnecessaria), ajuda a nascer scripts não portaveis.
Eu adicionaria o seguinte:
- Codigo de dificil leitura, entendimento e manutenção.


Coreutils é o exemplo perfeito de como não programar, codigo ilegivel, inchado e de dificil a impossivel manutenção. (deixarei comparações no final)


Acredito que o Busybox seja infinitamente melhor que o Coreutils.

Tomarei a liberdade de adicionar outros projetos:
Sbase:
- compila tanto para binario unico quanto separados;
- configuração feita no config.mk (arquivo de texto);
- codigo portavel, limpo, legivel;
- compatível, em boa parte, com os argumentos definidos pelo posix-2016 (opções curtas);
- dependências básicas: libc, make e um compilador C com compatibilidade c99;
- erros que apontam qual chamada falhou, facilitando a manutenção.
- caso compilado em binario unico, construção da userland a partir de links simbólicos (e.g ln -s sbase ln);
- manpages simples;
- extremamente pequeno (o sbase compilado de forma estatica com o "ellcc" possui 431K);

UtilChest: (aproveitar a oportunidade para divulgar o meu projeto : ) )
- incompleto
- segundo o coverity sem bugs (os apontados pelo mesmo são falsos positivos);
- compila tanto para binario unico quanto separados;
- compilação feita no config.mk (arquivo de texto);
- codigo portavel, limpo e legivel;
- bem compatível com o padrão posix (opções curtas);
- dependências básicas: libc, make e um compilador C com compatibilidade c99;
- erros apontam a chamada que falhou, usando os erros definidos em "errno" (sempre que possivel);
- caso compilado em binario unico, construção da userland a partir de links simbólicos (e.g ln -s utilchest ln);
- falta manpages no momento;
- extremamente pequeno (o utilchest compilado de forma estatica com o "ellcc" possui 77K);

E adicionarei algumas comparações:
CoreUtils ls: 5300 linhas (https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c)
BusyBox ls: 1250 linhas (https://git.busybox.net/busybox/tree/coreutils/ls.c?h=1_27_stable)
Sbase ls: 486 linhas (https://git.suckless.org/sbase/tree/ls.c)
*sbase ls: da realloc ao invez de usar uma lista linkada, e falta as flags para organizar o output.
UtilChest ls: 767 linhas (https://github.com/eltanin-os/utilchest/blob/master/src/ls.c)

sbase: https://git.suckless.org/sbase
utilchest: https://github.com/eltanin-os/utilchest

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 13:50h

Sim, também notei isso. Não sou programador profissional, muito menos sei muito de C, mas só a repetição desnecessária de headers já gera uma boa quantidade de bits.


Com certeza. O pessoal do projeto GNU quase sempre considera que o bash é o shell padrão em todos os *nix. Mas não sabia que o Busybox não utilizava shell script POSIX no projeto. Tem algum exemplo?


Bem, nunca fiz nenhum hacking no código fonte do busybox, mas vi algumas críticas sobre. Contudo, continuo com o mesmo por dispor de maior compatibilidade com o GNU CoreUtils.



Sim! Uma coisa que eu nunca entendi nos softwares GNU é o por que do m4, bizon, atool, automake, etc. Na minha visão, é muito mais simples e fácil configurar o programa com um simples arquivo de texto. O suckless faz isso muito bem, todos vem com um config.mk, a configuração é extremamente fácil.


Idem.


Tenho o sbase e atualmente estou testando substituir algumas utilidades do busybox pelo sbase e ubase.
Adoro as manpages e saídas de 'erro' do sbase/ubase. Esse método de construção de software é muito mais eficiente do que enfiar um monte de macros. Tal biblioteca não existe no seu sistema? Simples, instale-a, o compilador te mostra o erro.
Só fico com um pé atrás porque o projeto anda meio parado.


Parabéns pela iniciativa.


Boa! Tem tudo para dar certo. Estarei conferindo.


Tinha observado isso, mas esqueci não colocar no post principal. É ridículo a comparação. Por que raios o CoreUtils usa tantas linhas? Dá para comentar o ls.c do busybox 30 vezes. Como consequência, os binários saem enormes. Uma pequena comparação:

 

$ du -h src/gnu/coreutils/bin/ls src/suckless/sbase/bin/ls 

628.0K  src/gnu/coreutils/bin/ls

24.0K   src/suckless/sbase/bin/ls

 

Incrível, não?
Estaticamente, gcc, musl.

Muitos que vivem merecem a morte. E alguns que morrem merecem viver. 

Você pode dar-lhes a vida? 

Então não seja tão ávido para julgar e condenar alguém a morte. 

Pois mesmo os muitos sábios não conseguem ver os dois lados. 

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 14:35h

Os headers em C foram mal planejados, e criaram um padrão ruim, embora isso geralmente seja amenizado pelo compilador. A maior vantagem é o corte de repetição de codigo interno (geralmente melhor feito se o software for produzido com isso em mente).


É ruim manter o bash como shell padrão. O BusyBox internamente faz pouco uso de shell, e, até onde sei, compativel com o posix. O que quero dizer, é que suportando argumentos não posix incentiva/facilita o nascimento de scripts não portaveis.


Estando acostumado, ou possuindo scripts que dependam desta compatibilidade, é uma boa alternativa.


Com um pouco de trabalho você consegue manter um unico makefile e um arquivo de configuração. Mas para softwares insanos deve ser dificil atingir tal objetivo (ou o GNU se orgulha com inchaço mesmo)


Realmente, entupir as coisas de macro dificulta e muito a leitura. Ao menos considerando somente o sbase e ubase, são softwares que não precisão de atualização constante (diria que estão bem utilizaveis agora)


Obrigado, estou criando-o para usar na distro que pretendo criar.


só o ls do gnu é mais pesado que o sbase completo (quando compilado em binario unico).
GNU = GNU's Not Usable

http://aiju.de/b/style [veja a parte GNOME Programmer xD ]

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 14:58h

Certo. Pesquisarei sobre, entendo quase nada de compiladores.


Ah, sim, com certeza. Até hoje não consigo entender o por que de um {-v -V --version --help -h -H} . Porra, só um serve. Na configuração do busybox, você pode escolher suportar ou não tais besteiras.


Grande parte dos 'shell scripts' feitos aqui no VoL, por exemplo, são em bash. Ora, isso não é sh, é bash. Fora que alguns são sh POSIX, mas usam na shebang o /bin/bash. Caramba, o bash demora quase 5x mais na execução do script, não faz sentido escrever Bourne Again Shell Scripts e exigí-los em outra máquina. Eu mesmo não uso bash, só o ash do Busybox (que por sinal é um ótimo shell).


Realmente não entendo. Primeiramente, a enorme maioria dos softwares do projeto GNU faz leitura de arquivos durante a execução. Entendo que isso é necessário para alguns softwares (gerenciadores de pacotes, por exemplo), mas não para outros. Você é programador, sabe que esse malabarismo adiciona complexidade ao código. Uma vez compilado, reconfiguração só com recompilação.


Reconciderarei. Talvez faça uma mistureba louca aqui. Vejamos.


Percebi pelo nome. Ainda falta muita coisa, mas a sua atitude é nobre.
Já escolheu o init system padrão da distro? Já ouviu falar do s6 [0]? Nunca vi nenhuma distro por padrão com ele. É extremamente interessante e simples, vale a pena conferir.

[0] https://skarnet.org/software/s6


Realmente. Não consigo entender como conseguem fazer isso.


GNOME é um trem a parte, nunca vi algo tão ruim/mal planejado. Parece o systemd: depende de softwares cruciais para funcionar (GlibC) e é totalmente monolítico.

Muitos que vivem merecem a morte. E alguns que morrem merecem viver. 

Você pode dar-lhes a vida? 

Então não seja tão ávido para julgar e condenar alguém a morte. 

Pois mesmo os muitos sábios não conseguem ver os dois lados. 

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 15:10h

E Plan9 [0]? Revivido não há muito tempo, promete uma boa coleção de softwares, tanto para *nixs, tanto para o próprio SO[1]. Testei a userland e shell deles (rc) e também gostei. A instalação toda é feita por um script e nem o GNU Make eles utilizam: mk é o construtor de softwares do projeto. O suckless também fez uma versão resumida do plan9 (9base) [2].
Já testaram?


[0] https://9p.io/plan9/
[1] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
[2] https://git.suckless.org/9base/tree/

Muitos que vivem merecem a morte. E alguns que morrem merecem viver. 

Você pode dar-lhes a vida? 

Então não seja tão ávido para julgar e condenar alguém a morte. 

Pois mesmo os muitos sábios não conseguem ver os dois lados. 

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 15:26h

É, fazer script para BASH não gera resultados muito bons, felizmente muitas distros fazem uso de algum ash.


Até da para fazer de uma forma "simples", mas em muitos casos é mais seguro, simples e pratico configurar antes de compilar.


Eu diria que a este ponto falta construir só um build system (tipo ports ou algo do tipo), para começar o projeto. (inclusive estou proximo disso) Nesse ponto inicial mantendo substitutos temporarios para as ferramentas que faltam. Estou considerando seriamente também fazer um fork do LibAGAR para criar um sistema grafico decente.


Sim, eu já planejava fazer uso do s6, pois achei o mesmo interessante.
* Obarun (arch) faz uso do s6 como init padrão.


Realmente. Não consigo entender como conseguem fazer isso.


Ironicamente é o que vira padrão.


Eu diria que os mais aproveitaveis do mesmo são o "rc" e "mk", que inclusive considero BEM melhor que o gnu make.

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 15:36h

Sim, inclusive o Debian e Ubuntu [0].



Muito interessante. Fará um /bin/sh para o utilchest?


O s6 requer a execline. Fará os scripts de boot/supervisão com ela ou shell script mesmo?


Conferirei.


É, infelizmente.


Gostei de todos os softwares do 9plan, inclusive o sam (editor de texto). A sintaxe do mk é mais limpa que o GNU Make e o tamanho/simplicidade também.
Ainda não fiz um teste comparando os dois, mas arranjarei um tempo.

[0]https://wiki.ubuntu.com/DashAsBinSh

Muitos que vivem merecem a morte. E alguns que morrem merecem viver. 

Você pode dar-lhes a vida? 

Então não seja tão ávido para julgar e condenar alguém a morte. 

Pois mesmo os muitos sábios não conseguem ver os dois lados. 

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 15:39h

O execline [0], como disse acima, também é uma boa alternativa ao sh POSIX. Ainda não tive a chance de testar, mas o skarnet (autor) tece várias críticas ao tão clássico e costumeiro shell [1].

Já testaram ('ram'... só tem katsuke aqui)?

[0] https://www.skarnet.org/software/execline/
[1] https://www.skarnet.org/software/execline/dieshdiedie.html

Muitos que vivem merecem a morte. E alguns que morrem merecem viver. 

Você pode dar-lhes a vida? 

Então não seja tão ávido para julgar e condenar alguém a morte. 

Pois mesmo os muitos sábios não conseguem ver os dois lados. 

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 15:55h

Sim, minha intenção é que o utilchest seja uma userland bem completa.


Tenho a intenção de usar o execline, por uma questão de consistência.


Havia me esquecido do sam, é muito bacana também. (embora seja meio dramatico se acostumar com outro editor de textos)


So havia lido sobre o mesmo no site do criador, mas nunca cheguei a utiliza-lo (aparentemente não existe tantas pessoas que testam coisas diferentes, ao menos neste forum)

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 16:04h

Criará dois tipos? Um dash-like para sh POSIX e outro 'interativo'?


É, aparentemente o skarnet fez tudo bem amarrado (não que o s6 seja monolítico).


Testei pouco, mas já testei outro do projeto suckless: sandy. Estava testando o emacs (128MB, Jesus). O emacs faz um monte de coisa, mas não faz nenhuma muito bem. Testei o sandy por ser emacs-like e ser bem simples. Infelizmente (ou felizmente), não consigo largar o vim.


É, infelizmente.

Muitos que vivem merecem a morte. E alguns que morrem merecem viver. 

Você pode dar-lhes a vida? 

Então não seja tão ávido para julgar e condenar alguém a morte. 

Pois mesmo os muitos sábios não conseguem ver os dois lados. 

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 16:10h

Falando em userland, que tal um 'coreutils-like' para o X?
Bem, o X ainda é mandatório em muitos sistemas, precisa-se de boas ferramentas para ele.
Conheço algumas:
- wmutils: muitas pequenas e eficientes ferramentas para o X, dá para utilizá-lo como WM;
- xsel: área de transferência;
- slock: o protetor de tela mais simples que conheço;
- meh: visualizador de imagens extremamente rápido e simples;
- bgs: o menor background setter que já encontrei (< 250 linhas), só usa a imlib2;
- dmenu: menu dinâmico para o X;
- 9menu e thingmenu menu para o X, 'fluxbox-like';

Muitos que vivem merecem a morte. E alguns que morrem merecem viver. 

Você pode dar-lhes a vida? 

Então não seja tão ávido para julgar e condenar alguém a morte. 

Pois mesmo os muitos sábios não conseguem ver os dois lados.