Busybox X Coreutils

removido
(usa Nenhuma)

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

Me pergunto se é util fazer uma separação, pois acredito que o um sh posix sirva para interação. (principalmente se fizer uso de um biblioteca como "editline")


Aparentemente é para possuir uma base melhor, os padrões em C possuem qualidade bem questionavel. Mas acredito que, ao menos de forma geral, seja conveniente que este padrão exista.


Emacs é quase um SO. Eu, infelizmente, estou acostumado com editores de texto graficos (atom, sublime), por que gosto que a pasta seja mostrada em "arvore" e da interação do mouse. (frescuras que fazem falta).
* Existe o NeoVIM que parece possuir um codigo mais limpo.


Acredito que tais ferramentas sejam uteis em conjunto com um wm simples e leve (ao contrario de um KDE, GNOME, etc...)
1- posso estar enganado, mas esse wmutils não é usado para manipulação de janelas (e sendo este o caso necessitaria do uso de um wm)
3- esse "meh" por ser baseado no "feh" não possui capacidade de colocar um background no desktop?

removido
(usa Nenhuma)

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

Sim, mas tomemos o dash X bash como exemplo.
O dash não suporta o estilo emacs do bash (e.g ctrl + l = clear, ctrl + a, histórico), apenas interpreta comandos. Consegue ser menor que o ash.
Já o bash nós conhecemos muito bem. Algumas qualidades dele fazem falta. O mksh, pelos meus testes, é tão eficiente quanto, mas muito menor.


Também não vejo problemas, é muito portável e limpo.


Emacs é meu SO e Linux o driver.


Desde que migrei para o Linux não uso editores gráficos. Gosto do vim.


Já dei uma testada, mas como não sou nenhum expert no vim, não senti diferenças. Parece que é o mesmo caso mutt X neomutt.



Também, mas eu mantenho um X só com o wmutils, xdotool, sxhkd (esqueci de citar) e bgs.


Parcialmente certo. Ele manipula janelas e o cursor do mouse (wmp). O z3bra, um dos principais criadores, fez vários scripts para o mesmo. Bem, consigo fazer tudo com ele: mover/redimensionar janelas/cursor, matar/ocutar janelas,
obter informações sobre as janelas, deixá-las em fullscreen, coners, etc.


Não. Ele não é um fork.
O melhor do meh é que ele não abre a imagem em fullscreen, por padrão. O bgs é mínimo, vale a pena modularizar isso.

Ah, o sxhkd é especialmente útil. Não sei como poderia viver sem tê-lo. O nome diz tudo: Simple X Hotkey Daemon.

Mais informações sobre:
wmutils: https://github.com/wmutils/ | http://blog.z3bra.org/2015/01/you-are-the-wm.html
meh: https://www.johnhawthorn.com/meh/
sxhkd: https://github.com/baskerville/sxhkd

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 - 17:17h

Ah, não considerei interação desse tipo. Sendo este o caso acredito que para interação seja melhor o mksh, ao invez de escrever dois (sendo que um já é bem chato, por ser necessario seguir um monte de especificações)


xDD Emacs é um otimo SO, só o falta um editor de textos decente.


Segundo eles possuem um codigo 30% menor, é possui suporte para plugins em Lua.


Diria que possui boa compatibilidade? não sei se o ICCM é necessariamente implementado no wm ou respeitado pelo app. (ou ambos) Alias o resultado disso seria o equivalente a um "stack wm", certo?


Havia assumido isso por causa do "It is similar to feh, but faster and simpler.".

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 17:32h

É uma boa ideia.


O keybind do Emacs é legal, só falta uma boa implementação.


Não sinto falta de plugins, só uso o undotree. Mas conferirei.


Sim, se adequa bem a qualquer ambiente.

Não entendi muito bem, mas ele só requer dois pacotes: libxcb e xcb-utils

Toda a 'configuração' do wmutils é feita pelo sxhkd (ou seja, por um arquivo de texto). Pode ser stack, tilling e até dinâmico.


É, mas eu considero o meh muito melhor que o feh.

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 - 17:37h

Voltando ao tópico original, os softwares mais interessantes para a userland, até agora, são:

- busybox ---> o mais completo e compatível com o coreutils
- toybox ---> busybox mais simples ainda, muito utilizado no Android
- sbase e ubase ---> as menores e mais eficientes implementações até agora
- utilchess ---> incompleto, mas promissor

Mais alguma sugestão/correção?

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 - 18:33h

@mithrandir citarei alguns outros:
heirloom - implementação tradicional das ferramentas unix.[0]
noXCUse- ferramentas unix produzidas pelo autor da musl.[1]
elkscmd- a base de um projeto para rodar linux em embarcados.[2]
embutils- ferramentas unix para embarcados. [3]

[0]:http://heirloom.sourceforge.net
[1]:http://git.musl-libc.org/cgit/noxcuse/tree/
[2]:https://github.com/jbruchon/elks/tree/master/elkscmd
[3]:https://www.fefe.de/embutils/
* boa parte destes citados não são mantidos e/ou atualizados a um tempo consideravel.

removido
(usa Nenhuma)

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

Muito obrigado pelos links, Katsuke. Estarei olhando-os.
É bom que os projetos ainda estejam na ativa, mas verificarei melhor mais tarde.
Um detalhe: o elkscmd conseguiu fazer um bc sem macros e autogen! Milagre.

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. 

Freud_Tux
(usa Outra)

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

[quote]mithrandir escreveu:

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.

Se você ler na história do projeto Gnu, vai ver que a finalidade era fazer o eterno S.O do Stallman sair do papel (que ainda não saiu até hoje), ou seja, era um projeto inacabado. O Linux era um conjunto também incompleto. A "fusão" dos dois possibilitou o surgimento do Linux, logo, o termo Gnu/Linux é válido, pois um acabou ajudando outro. Basta ir nos sites dos dois projetos e verá.

Sobre o resto, bem, com o tempo novos programas são escritos para agilizar a coisa toda. O SysVInit deixou de ser único, e hoje temos o OpenRC e outros. Superar as ferramentas do GNU seria uma tentativa de reinventar a roda, o que podem fazer é melhorar elas, como foi feito com o SysVInit (ao surgirem melhorias como OPenRC). Mas o Gnu/Linux nunca seria o que é se não fosse pelas ferramentas do GNU e sua licença, lembre-se disso!

T+


-------------------------------------------------------------------------------------------------------------------------------------------------
Noob: "[...]Sou muito noob ainda usando o terminal, então preciso de ajuda "mastigada", pra operá-lo."
zhushazang: "Sou velho e meus dentes desgastados. Estude linux www.guiafoca.org";

removido
(usa Nenhuma)

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

Não entendo essa língua

removido
(usa Nenhuma)

Enviado em 21/10/2017 - 23:02h

Sim, é verdade, mas quero fazer algumas ressalvas.
No começo, com certeza absoluta, o Linux era dependente do projeto GNU. Hoje, felizmente, não é mais. Veja, existem bibliotecas C criadas especialmente para o Linux [0], shells otimizados [1], bibliotecas [2], ferramentas [3], compiladores. Hoje, graças ao crescimento do projeto, podemos dizer que é 100% possível utilizar um sistema baseado no kernel Linux, livre (não num sentido pejorativo, claro) do GNU. Todavia, a maioria esmagadora das distribuições se baseiam nos softwares do projeto GNU. Debian, Fedora, Trisquel, Parabola, Hyperbola, Arch, Ubuntu sim são distros GNU/Linux; estão intimamente ligadas a ele.
Mas existem excessões. A mais clara que posso citar, sem titubear, é a Alpine Linux. Ela simplesmente não é GNU/Linux: os componentes, licenças, bootloader, filosofia, libc, tls/ssl; nada é GNU. Vale o mesmo para o Gentoo: por ser absurdamente flexível, é muito ingênuo chamá-lo de Gentoo GNU/Linux, pois ele pode utilizar outras ferramentas, livre do GNU.

Agora, quero fazer um esclarecimento: NÃO tenho absolutamente nada contra o projeto GNU. Sério, compactuo com a filosofia da FSF mais do que desgosto da GlibC/CoreUtils. A filosofia, para mim, é muito maior do que o software produzido pelo GNU. Como meu amigo pekman sempre diz: "GNU é primordialmente, um movimento pela liberdade do usuário, o restante é código". Concordo com ele. Os artigos da FSF, o Guide Line para certificação de uma distro 100% Livre, a Cultura Livre, a anti censura, a luta pelo Kernel Linux totalmente Livre, o repúdio pelo termo "Open Source", a filosofia: tudo isso me fascina. Então, mais uma vez: não odeio o projeto GNU.

[0] https://en.wikipedia.org/wiki/Klibc
[1] https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/
[2] https://www.kernel.org/pub/software/libs/
[3] https://www.kernel.org/pub/software/utils/ | https://www.kernel.org/pub/linux/utils/util-linux/


Bem, meia verdade. O OpenRC utiliza o Sysvinit como back-end.

Ainda bem que temos os que sempre querem reinventar a roda: já imaginou se o Stallman aceitasse passivamente o abuso feito com os usuários no Laboratório do MIT?

Entendo, mas algumas coisas não mudam. Como conciliar o s6 com o systemd? Simples: não dá. O design do projeto é outro, a filosofia é outra. O próprio criador da uclibc (que era mantenedor da GlibC por anos) disse que tentou melhorar o projeto, mas suas sugestões eram radicalmente negadas. O que fazer nesse caso? Criar uma alternativa é a melhor opção.

Será mesmo? Não estou desmerecendo a valorosa contribuição do projeto GNU, apenas mostrando que há alternativas muito melhores. E o GNU sem o Linux, o que seria hoje? O próprio Torvalds, numa de suas discussões com Tanenbaum, disse que usaria o Hurd, se ele estivesse pronto. A verdade é que o Linux cresceu e não é mais dependente do projeto GNU.

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 22/10/2017 - 19:35h

Estou planejando um teste, em um container bem mínimo, com Alpine Linux, para verificarmos algumas coisas.
Utilizarei o Docker. Versionarei de acordo com o tipo testado.

Softwares que testarei:

sbase e ubase (um complementa o outro);
toybox;
busybox;
coreutils.

Biblioteca padrão C (pelo menos neste teste):
musl libc

Padronização:
Todos devem oferecem as mesmas ferramentas. Ou seja, desconsiderarei as extras, tentando achar um padrão mínimo, que todos possam participar.

Critérios:
- velocidade de execução em pequenos e grandes arquivos;
- tamanho final do binário;
- documentação;
- suporte ao POSIX.

Preciso da ajuda dos senhores para escolher um compilador C que consiga compilá-los sem nenhum problema. Bem, acredito que qualquer um que suporte o POSIX e o standard c99 sirva, mas estou aberto a sugestões.
* também seria interessante testar e comparar o desempenho dos compiladores nesse teste.

Acho que será uma boa experiência.

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 22/10/2017 - 21:00h

Pode passar a config do seu .xinitrc?