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

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

Perfil removido
removido

(usa Nenhuma)

Enviado em 03/05/2018 - 00:44h

Fala, linuxers! Bom, é uma pergunta mais engajada na minha curiosidade pessoal mesmo.

Por que a galera rejeita tanto o systemd, especialmente meus colegas slackers? O que tem no systemd que faz dele um inimigo para quem usa slackware, por exemplo? E as dependências? Porque é melhor não ter um gerenciador de dependências em uma distro? Quais as vantagens?

Desde já, obrigado a todos pela atenção!


  


2. MELHOR RESPOSTA

Rodrigo Albuquerque Serafim
raserafim

(usa Slackware)

Enviado em 03/05/2018 - 13:45h

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)


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

thalis
himen3

(usa Arch Linux)

Enviado em 03/05/2018 - 02:27h

Nao posso responder ao todo, mas sei dizer que sem um gerenciador de dependencias dependendo do seu lado pode ser uma coisa ruim, mas pro lado de pessoas que presam em instalar apenas aquilo que quer e uma coisa boa. Porque com um gerenciador de dependencia apos querer desinstalar certo programa, pode ser levado ate o sistema inteiro junto, o que nao acontece sem um gerenciador de dependencia.


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

Cabreuvas
Cabreuvas

(usa Manjaro Linux)

Enviado em 03/05/2018 - 12:21h

O SystemD é odiado por vários motivos, desde a falta de modularidade até os logs binários...

Quanto a um gerenciador que não resolve dependências, é para ter maior controle sobre o sistema. Outra vantagem é poder ter os pacotes na versão que quiser sem dificuldades. Eu particularmente não acho prático e nem vantajoso.


6. Re: Por que esse ódio todo ao sytemd? E as tais dependências?

Alberto Federman Neto.
albfneto

(usa Sabayon)

Enviado em 03/05/2018 - 12:35h

thecarlosfilipe escreveu:

Fala, linuxers! Bom, é uma pergunta mais engajada na minha curiosidade pessoal mesmo.

Por que a galera odeia tanto o systemd, especialmente meus colegas slackers? O que tem no systemd que faz dele um inimigo para quem usa slackware, por exemplo? E as dependências? Porque é melhor não ter um gerenciador de dependências em uma distro? Quais as vantagens?

Desde já, obrigado a todos pela atenção!


Sobre o Systemd, o assunto é muito debatido aqui. Não são só os Slackers. Muita gente não gosta, eu inclusive... Pq ele gerencia tudo, do hardware à rede, montagem dos dispositivos etc.... e é muito sensível a erros....qualquer probleminha, o systemd não dá mais boot, não monta auto o pendrive espetado, não desliga o micro etc...

Não gostamos muito de systemd, pq ele não funciona legal!

Sobre as dependências, há vantagens e desvantagens, em gerenciá-las ou não. De fato, em Slackware, vc instala deps ou não, na maioria das distros as deps instalam automático,

mas por exemplo, nas Distros tipo Gentoo (como a que uso Sabayon), ou vc gerencia automático (aí ele instala as deps) ou menos deps, ou até não instala dep alguma, vai ao gosto do freguês.

Se pode dizer que Gentoo, Portage, gerencia as dependências, se vc quiser, mas se não quiser, não

exemplo:


# emerge -av pacote (vai baixar as dependências, se precisar e de acordo com as USE Flags)
MAS ASSIM:
# emerge -av --nodeps pacote (não baixará dependência alguma)


Assim vc controla as deps, se realmente precisar delas, ou não.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: Sabayon, Gentoo, openSUSE, Mageia e OpenMandriva.


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

Giovanni  M
Giovanni_Menezes

(usa Void Linux)

Enviado em 03/05/2018 - 12:56h

Giovanni_Menezes escreveu:

O maior problema do System-D não é nem a questão se der amigo ou inimigo mas sim estar se tornando dependência obrigatória:

Tradução do Google, apenas alguns trechos:

heodore "Ted" Ts'o, um dos principais desenvolvedores do kernel Linux e um engenheiro do Google, vê o sistema ser potencialmente mais problemático.

Ts'o tem um excelente ponto. O GNOME 3.x alienou os usuários e desenvolvedores . Ele continuou: "Como resultado, muitos usuários tradicionais do GNOME passaram para a Cinnamon, XFCE, KDE, etc. Mas, à medida que o systemd começa a subsumir novas funções, os componentes, como o gerente de rede, só funcionarão em sistemas ou outros componentes que são forçados a ser usado devido a uma rede de dependências interligadas e simplesmente não é possível que esses desktops alternativos continuem a funcionar, porque existe [não] alternativa viável para systemd suportada por mais e mais distribuições ".

http://www.zdnet.com/article/linus-torvalds-and-others-on-linuxs-systemd/

Para simplificar, System-D esta indiretamente se tornando uma dependência obrigatória, sufocando cada vez mais os desenvolvedores de outros Desktops e pacotes que se veem forçados a 2 escolhas, adota-lo ou ter um ardo trabalho de "desemaranhar" as dependências.

Felizmente a comunidade percebeu rapído qual era a jogada e reagiu, mesmo que não seja a maioria, Devuan, Gentoo e Slack, Void entre alguns outras e seus respectivos desenvolvedores estão atuando como "quimioterapia" e contendo o câncer.

Se esperassem um pouco mais para reagir, futuramente seria praticamente inviável sair das garras, reagiram em tempo hábil.



https://www.vivaolinux.com.br/topico/Off-Code-Cafe/Afinal-sistemd-e-amigo-ou-inimigo


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


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

Perfil removido
removido

(usa Nenhuma)

Enviado em 03/05/2018 - 13:57h

Giovanni_Menezes escreveu:

Giovanni_Menezes escreveu:

O maior problema do System-D não é nem a questão se der amigo ou inimigo mas sim estar se tornando dependência obrigatória:

Tradução do Google, apenas alguns trechos:

heodore "Ted" Ts'o, um dos principais desenvolvedores do kernel Linux e um engenheiro do Google, vê o sistema ser potencialmente mais problemático.

Ts'o tem um excelente ponto. O GNOME 3.x alienou os usuários e desenvolvedores . Ele continuou: "Como resultado, muitos usuários tradicionais do GNOME passaram para a Cinnamon, XFCE, KDE, etc. Mas, à medida que o systemd começa a subsumir novas funções, os componentes, como o gerente de rede, só funcionarão em sistemas ou outros componentes que são forçados a ser usado devido a uma rede de dependências interligadas e simplesmente não é possível que esses desktops alternativos continuem a funcionar, porque existe [não] alternativa viável para systemd suportada por mais e mais distribuições ".

http://www.zdnet.com/article/linus-torvalds-and-others-on-linuxs-systemd/

Para simplificar, System-D esta indiretamente se tornando uma dependência obrigatória, sufocando cada vez mais os desenvolvedores de outros Desktops e pacotes que se veem forçados a 2 escolhas, adota-lo ou ter um ardo trabalho de "desemaranhar" as dependências.

Felizmente a comunidade percebeu rapído qual era a jogada e reagiu, mesmo que não seja a maioria, Devuan, Gentoo e Slack, Void entre alguns outras e seus respectivos desenvolvedores estão atuando como "quimioterapia" e contendo o câncer.

Se esperassem um pouco mais para reagir, futuramente seria praticamente inviável sair das garras, reagiram em tempo hábil.



https://www.vivaolinux.com.br/topico/Off-Code-Cafe/Afinal-sistemd-e-amigo-ou-inimigo


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


Gostei do seu ponto de vista. Muito bem colocado. Entendi mais o porquê de tanta polêmica à cerca do tema. Obrigado pela atenção!


"Eu não quero acreditar, eu quero saber." (Carl Sagan)


9. Re: Por que esse ódio todo ao sytemd? E as tais dependências?

Perfil removido
removido

(usa Nenhuma)

Enviado em 03/05/2018 - 14:03h

Bobagem! Frescurites e exigências de usuários que se acham os experientes.
São os mesmos que exigem que distros tenham que ter GNU / Linux na frente do nome, como se o GNU fosse algo "super" importante e dependente do Linux.

https://www.youtube.com/watch?v=dm4NmY17iPw
https://www.youtube.com/watch?v=TRFVq4t2MaQ


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

Perfil removido
removido

(usa Nenhuma)

Enviado em 03/05/2018 - 14:07h

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)


raserafim, ótima reflexão! Gostei demais da sua explicação e me tirou praticamente todas as dúvidas. Eu vou modificar o termo "ódio", pois realmente pareceu muito afirmativo. Obrigado pela paciência em explicar ponto por ponto. Abraço.

"Eu não quero acreditar, eu quero saber." (Carl Sagan)


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

Cabreuvas
Cabreuvas

(usa Manjaro Linux)

Enviado em 03/05/2018 - 14:12h

Rustik escreveu:

Bobagem! Frescurites e exigências de usuários que se acham os experientes.
São os mesmos que exigem que distros tenham que ter GNU / Linux na frente do nome, como se o GNU fosse algo "super" importante e dependente do Linux.


Na verdade eu acho correto usar GNU/Linux, visto que Linux é o kernel, e a maioria das ferramentas comumente utilizadas são do GNU, como a glibc e o coreutils.


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

Perfil removido
removido

(usa Nenhuma)

Enviado em 03/05/2018 - 14:13h

Cabreuvas escreveu:

Rustik escreveu:

Bobagem! Frescurites e exigências de usuários que se acham os experientes.
São os mesmos que exigem que distros tenham que ter GNU / Linux na frente do nome, como se o GNU fosse algo "super" importante e dependente do Linux.


Na verdade eu acho correto usar GNU/Linux, visto que Linux é o kernel, e a maioria das ferramentas comumente utilizadas são do GNU, como a glibc e o coreutils.


GNU parou no tempo, se não fosse o Linux e outras ferramentas herdadas do BSD o Linux já tava no fundo do poço. O projeto GNU só se apoderou do Linux.



01 02 03