Por que essa rejeição toda ao systemd? E as tais dependências? [RESOLVIDO]

Giovanni_Menezes escreveu:



Pelo visto, você caiu de paraquedas ontem no gnu/linux

Quem te disse que eu já não fui lá falar ? você sabe o que ele faz com os comentários que desmascara ele ?
Você sabe que a maioria dos pacotes que ele papagaia como não gnu, como uns do que você citou neste tópico ESTÃO CHEIO DE DEPENDÊNCIAS GNU, ? não precisa acredita em mim, vá no site do projeto deles e vá compilar os pacotes e veja as dependências com seus próprios olhos, você esta pagando mico aqui e nem sabe!

E de onde o senhor tirou que outro IDIOMA é argumento???, você sabe quem é bruce peres sabe quantas abobrinhas em inglês esse sujeito já falou ?

E para acabar de falar sobre as pataquada desse tratante, vai ai a passada de linguiça que ele tomo do Rodrigo Baltar.






--------------------------------------------------------------------------
Somente o Software Livre lhe garante as 4 liberdades.
Open Source =/= Free Software.
https://encurtador.com.br/CGNU5
http://www.anahuac.eu/contrarrevolucao-osi/

***Diga NÃO ao consumo desenfreado de memoria ram das interfaces gráficas***
http://webm.land/media/nzgR.webm

Thitos escreveu:



"Passada de linguiça" primeira vez que ouvi esse termo, muito bom kkkkkkkkkkkkkkkkkk

Ao criador do tópico, é isso o que já foi dito, Systemd não é uma excelência no que se propõe a fazer, é complicado de se entender em termos de estrutura e código, o seu principal desenvolvedor não era muito amigo da comunidade por não aceitar opiniões contrárias, o Systemd já foi acusado inclusive de possuir algumas falhas de segurança propositais ou não, que facilitava uma provável espionagem.

Mas o pior de tudo é ter sido enfiado goela abaixo dos usuários. Além dele fazer tudo por vc (não tão eficiente) e complicar para vc entender o que ele está fazendo (não ser simples) ele foi algo imposto, sem a sua liberdade de escolha e ninguém até hj sabe exatamente o pq ele acabou sendo adotado pela maioria, mesmo com muitos protestos.

Vide o Devuan que foi criado pq alguns devs do Debian não aceitaram os rumos da distro e a adoção do Systemd pelo Debian foi um deles. O Gentoo se não me engano te da a liberdade de escolher usar Systemd ou outro init e acredito que isso é o que deveria ser, mas entendo que tbm demandaria mais trabalho dos devs das distros.

O Rustik tbm não gosto do termo GNU/Linux, por isso sempre vou chamar de Linux, mas não tira o mérito de tudo o que projeto GNU fez. Mesmo hj tendo outras alternativas ao GNU, a maioria das distros ainda o usa pq os projetos alternativos não se encaixam para todos. Uso Void Musl aqui e ainda possui limitações ao Glibc para determinado uso, mesmo sentindo que o notebook ficou mais "leve", quem dirá Alpine.

Então, não entra nessa de levantar uma bandeira sobre GNU ou NÃO GNU, pq é desnecessário e se vc for fazer isso realmente, aconselho parar de usar KDE Neon e ir começar direto com Alpine, escolhendo a dedo cada programa instalado. Pesquise sobre o Uruk aqui no fórum e vai ver o que era um sistema sem nada proprietário e com o mínimo de GNU. Ele levava essa parada bem a sério.

"Failure is an option here. If things are note failing, you are not innovating enough" - Elon Musk 

Rustik escreveu:

raserafim escreveu:

o termo "ódio" talvez não seja o melhor a se utilizar...


- Quanto ao SystemD:

vai contra a dois dos princípios mais caros ao slackware: a filosofia KISS e a filosofia UNIX.

enquanto que o sistema de inicialização do slackware (sysvinit) é todo ele composto por simples scripts em modo texto, no entanto, o systemd se tornou um sistema de inicialização grande, complexo, expansivo, que se utiliza de binários e que extrapola, em muito, as funções entendidas típicas e essenciais de um init.

se tornou tão expansivo a ponto de interfaces gráficas e, às vezes, até mesmo aplicativos, lhe terem como dependência.

dois exemplos ilustrativos:

- os logs em toda a história dos sistemas GNU/Linux sempre foram armazenados em arquivos texto puro: de modo a ser possível analisá-los em qualquer situação. no systemd os logs são armazenados em arquivos binários, em que é preciso aplicativos próprios e específicos para lê-los.

- os daemons e comandos executados na inicialização, e o seu ordenamento, no slackware é tudo configurado em um arquivo de texto puro: podendo assim ser alterado em qualquer editor de texto; enquanto que no systemd essas informações, fundamentalmente, encontram-se em binários, que apenas é possível configurá-las por meio de um sistema de comandos próprios.


- Quanto às Dependências:

um dos principais fundamentos para a não utilização de um gerenciador de dependências é que este tipo de gerenciador coloca uma complexidade a mais no sistema: de certa forma, acrescenta uma camada intermediária.

no caso do slackware, por princípio, a adição de camadas intermediárias devem ser evitadas o máximo possível: a ideia geral é procurar sempre colocar o usuário no acesso direto às configurações fundamentais do sistema.

uma outra razão importante é que as dependências indispensáveis ao funcionamento de uma aplicação, por vezes, podem ser relativas.

é importante observar que não se trata aqui da distinção comum em muitas distribuições entre "dependências obrigatórias" e "dependências recomendadas". trata-se apenas do que se entende por "dependências obrigatórias".

por exemplo, um determinado pacote pode ter a dependência do pulseaudio porque foi compilado habilitando a flag que faz esse aplicativo utilizar seus recursos. no entanto, essa flag poderia ser desabilitada, fazendo com que o aplicativo se adeque aos recursos simples do alsa e, assim, dispense a dependência do pulseaudio.

vide o caso recente do slackware: para possibilitar que seus usuários possam escolher entre pulseaudio e alsa, esta distribuiçao mantém alguns arquivos que possuem duas versões (uma para pulseaudio e outra para alsa)

essa mesma lógica de definir as reais dependências em tempo de compilação, logo, existe em várias outras situações. um caso ilustrativo é o do libreoffice: muitas bibliotecas são definidas em tempo de compilação se serão incorporadas em forma de recursos ou não. (veja: https://slackbuilds.org/repository/14.2/office/LibreOffice/)

ou seja, em síntese, apenas com o usuário tendo contato direto com processo de compilação é que se torna possível definir quais dependências esse usuário quer realmente utilizar ou não.

utilizar um gerenciador de pacotes é entregar essas decisões para a equipe que compilou ou que preparou os scripts de compilação.

uma vez que o slackware preza pelo controle do usuário e os aplicativos que não estão no repositório oficial tem a recomendação de serem instalados a partir do código-fonte (valendo-se de slackbuilds), então, faz algum sentido essa distribuição não fornecer suporte a um gerenciador de dependências.

no entanto, não utilizar um gerenciador de pacotes traz uma série de trabalho, dificuldades e, talvez, até de limitações.

uma das principais limitações é a extrema dificuldade para se manter um sistema mínimo e enxuto -- uma vez que cada instalação de pacotes demandará a instalação de várias dependências.

para contornar de alguma maneira essas dificuldades, o slackware fornece um sistema mínimo de outro tipo: não é um mínimo super enxuto; mas é um mínimo para subsidiar as principais bibliotecas que costumam ser demandadas. (observe que bibliotecas não significa aplicativos -- só para dar um exemplo, no slackware não há qualquer suíte de escritório: como o libreoffice).

interessante observar o caso do Salix: para viabilizar um sistema realmente mínimo e enxuto esta distribuição implementou o gerenciador de dependências -- o que faz com que seja frequentemente referenciada como um "slackware para leigos" (embora realmente essa distribuição possua um instalador mais fácil e algumas telas de configuração que não existem no slackware, entretanto, em minha avaliação, entendo que a sua particularidade mesmo é possibilitar um slackware realmente mínimo)

Tio_do_Toldo escreveu:



Se o nosso colega "poligrota" deixasse de ficar se autoafirmando em fóruns de internet e fosse estudar um pouco, perceberia que o GNU é muito mais do que os softwares em si que ele oferece. É uma filosofia. Um princípio. Uma escolha.

Desde que determinado software seja software livre, está valendo. Fod*-se se foi criado pelo projeto GNU ou não. Ele faz parte da "família". Sendo tecnicamente superior aos softwares GNU, melhor ainda. Estamos evoluindo. Todo mundo ganha.

O que importa e deve ser conservado é a FILOSOFIA GNU, e não os softwares em si. As coisas evoluem.

Rustik escreveu:

...
Quanto ao GNU, eu sou contra tudo, tudo relacionado a ele, não apenas os softwares. A filosofia por trás também sou contra, pois eu não gosto de filosofias, gosto de prática. Filosofia só serve pra deixar a pessoa presa na ignorância.
Também já disse que sou contra a GPL, tenho asco dela. Altamente limitante. E eu sou totalmente contra esse onda de conservadorismo que os slackers tanto amam e disseminam.

zezaocapoeira escreveu:



Salve mano.

Já leu https://www.vivaolinux.com.br/quemsomos/ .
...
Todo o conteúdo do site é distribuído sob os termos da licença pública GNU General Public License v3 .
...

Você está participando de um fórum que usa a GNU General Public License v3.

Você está sendo incoerente , pois usa algo com a licença GNU General Public License v3 para se expressar.

Não use "argumentos sem base" como muleta para suas explanações, pois as mesmas não se sustentam e está se comportando como hater/fanboy .

OBS:

Reflita o VOL realmente serve você ? ( pois afirmou ser contra GNU General Public License e mesmo assim usa as ferramentas do mesmo.)

Antes de usar/cadastrar em algo leia as licenças que o mesmo usa.


Obrigado pela atenção, salve!!!

removido escreveu:



Vcs estão corretos quanto a isso, não posso ficar num lugar onde é um covil de cobras, que é o fórum de vcs que defendem o GNU e sua filosofia com unhas e dentes, eu sou contra filosofias.
Mas não se preocupem, eu saio... Mas vcs ainda tem tempo de acordar e largar esse GNU. Ele com a GPL não serve de nada e só atrasa mais a evolução do Linux.
É que nem o Android que é dependente da Google e tem os blobs inclusos, não seria melhor sem? Pois é, fica a reflexão.