Boicote ao Sistemd (http://boycottsystemd.org)

Estou trabalhando com CentOS7 sem problemas. Incrível como ficou simples algumas coisas.
Lembrando que hoje as provas da Red Hat são baseadas no RH7 e conhecimento em systemd é essencial.

kkkkkkkkkkkk

O systemd não simplificou as coisas, ele escondeu as coisas, por isso usá-lo (usá-lo) parece ser mais fácil, mas quero ver alguém querer modificá-lo (o sysvinit só faz o que qualquer sistema de gerenciamento deve [ou deveria] fazer: carregar o meu sistema e ponto, sem mais).

E desde quando eu só consegui remover usuários pelo system-config-users? e seu ficar sem interface gráfica, é mais fácil eu usar o userdel ou ter que instalar um novo ambiente do zero, pra poder rodar o tal aplicativo?

Ainda não eles estão subindo os pacotes para o endereço https://github.com/devuan.

Não entendi sua colocação. O userdel não foi deprecado. Está ativo e funcional.

# which userdel

/sbin/userdel 

# ls -l /sbin/userdel

-rwxr-x---. 1 root root 80320 Jun 9 2014 /sbin/userdel 

Eu não falei que foi deprecado, eu disse que ele simplesmente não funcionou quando precisei dele, e que foi a primeira vez que presenciei isso e que isso aconteceu por causa do systemd (as mensagens de erro estavam diretamente relacionados à ele) -- meu primeiro post da página 2 conta isso aos detalhes;

--------------------------


Só gostaria de relembrar que eu voltei neste tópico apenas para comentar sobre algo ruim que aconteceu comigo por causa do systemd, sem a intenção de causas discussões e afins; o que todas estas pessoas que não gostam do systemd tentam falar/avisar não é sobre o seu modo de funcionar ou como foi projetado/construído, mas sim, que ele faz muito mais do que um sistema de gerenciamento deveria fazer (ele controla todo o seu sistema, e não dá opções de substituí-lo).

Uma das regras da filosofia Unix de que os programas devem ser escritos para fazer apenas uma coisa, mas que façam esta coisa direito; o systemd claramente não segue isso. Vou parar por aqui e ficar só "assistindo", e arranjar um tempo num futuro próximo pra começar a aprender os BSDs e migrar pra eles (que de fato são fiéis ao Unix, enquanto a grande maioria das distros Linux hoje estão longe de serem);

Entendi. Grandes empresas só iram começar a utilizar a partir do Red Hat Enterprise 7.1.

Bom dia a todos,
Estava a algum tempo sem acessar a VOL, sendo assim em deparei com esse tópico e vou emitir a minha opinião:

O systemd, até onde eu vi veio com a ideia de implantar o paralelismo(iniciar serviços em paralelo, aproveitando melhor os processadores multi núcleo) na inicialização do sistema e com isso acelerar o boot, até aí tudo bem, a parte do paralelismo é necessária e já deveria ter sido implantada a muuuito tempo atrás, mas o grande problema disso tudo é que não se contentaram em restringi-lo a fazer simplesmente o seu papel que é iniciar os processos no boot e depois mata-los ao desligar/reiniciar o sistema. O systemd é usado para controlar tudo, inclusive alguns comandos como os de reboot, hibernação ..... é aí onde está o erro, esse monte de coisas em um programa só, ligado a forma "porca" como isso foi feito, leva essa série de erros. Eu inclusive no arch já passei e continuo passando muita raiva com o systemd, direto ferra algum serviço, alguma coisa não inicia ....

No fim das contas o systemd tem mais prejuízos do que vantagens.

Agora o que leva grande parte das distros a utiliza-lo é simplesmente a questão do paralelismo, não dá com os processadores que temos hoje, para continuar iniciando e tratando os processos e programas em linha( a ideia de que só se inicia um processo depois que o outro terminar de iniciar), e mesmo em processadores um pouco mais antigos é possível implantar o paralelismo simulado( escalonamento), o X da questão para as distros que adotaram o systemd não é achar que ele seja bom é simplesmente o fato de que não tem outro funcionando que faça o que elas precisam.

E eu acho que o paralelismo seja necessário, porém o systemd apesar de ser o único atualmente funcionando com essa funcionalidade não é nem de longe o que precisamos, é muito instável. É preciso desenvolver uma coisa mais organizada e bem feita.

# Global OpenRC configuration settings

# Set to "YES" if you want the rc system to try and start services
# in parallel for a slight speed improvement. When running in parallel we
# prefix the service output with its name as the output will get
# jumbled up.
# WARNING: whilst we have improved parallel, it can still potentially lock
# the boot process. Don't file bugs about this unless you can supply
# patches that fix it without breaking other things!
#rc_parallel="NO"

"O Debian conseguiu: paralelizou o sysvinit. Em sua versão mais recente, a 6.0 squeeze, o sysvinit do Debian usa um utilitário chamado insserv que ordena a sequência de inicialização dos serviços pelo sysv-rc, script que lê e executa os scripts propriamente ditos."

https://www.ibm.com/developerworks/community/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/compar...

Todos os sistemas init tem alguma forma de paralelismo. O último a implementar isso foi o SysVinit e já tem algum tempo.

Tem gente precisando estudar mais antes de dar palpite.

Interassante. Eu até sabia que upstart tinha paralelismo implantado, apenas não me recordei no momento do post, agora quanto ao sisvinit e ao openrc não sabia, bom saber, obrigado pela informação.

O fato é: por algum motivo, a maioria das distros está implantando o systemd, o que não quer dizer que ele é bom. Aliás como já falei no post anterior o mesmo já me acarretou inúmeras dores de cabeça.

O que ocorre muito entre os desenvolvedores no mundo GNU/Linux é uma questão simplesmente de ego, cada um tem o ego maior que o outro e nunca chegam em um concenso, é isso que faz surgir 4 ou até mais, sistemas de init diferentes, cada um faz do jeito que bem entende, e no fim das contas cada 1 é bom em um aspecto, mas nenhum é de fato completo.

O que precisa haver é um concenso pelo menos em 3 aspectos gerais nas distros GNU/Linux ou logo logo a situação vai ficar insustentável. São eles:

1) Adotar um sistema de init padrão;
2) Adotar um pacote padrão;
3) Adotar um servidor gráfico padrão;

Concordo plenamente!

O lance do ego é complicado, vejo que ocorre até mesmo aqui nesse e em outros fóruns...

ianclever e ru4n:

Da minha parte, nada a ver com ego, pois outra coisa que acontece aqui e em outros fóruns é gente falando de coisas que não sabe.

ianclever, tu reconhecestes que não sabias, essa é a atitude certa, eu faria o mesmo.

E quanto ao consenso, concordo contigo, mas isso é uma coisa praticamente impossível.
É equivalente à se chegar ao consenso de que uma distribuição é a melhor de todas.

Veja essa briga entre o Linus e o Lennart, se eles que são eles não se entendem, o que sobra para nós?

Isso faz parte do ser humano, é assim que o ser humano progride, cada um tendo a liberdade de dar a sua opinião e cada um reconhecendo quando está errado.

Em relação aos sistemas init, na minha opinião todos são bons, um irá evoluir e fará com que os outros evoluam para acompanhar. Essa é a filosofia Open Source. É assim que o software livre progride.