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

removido
(usa Nenhuma)

Enviado em 12/12/2014 - 10:41h

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.

removido
(usa Nenhuma)

Enviado em 12/12/2014 - 11:00h

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?

removido
(usa Nenhuma)

Enviado em 12/12/2014 - 11:10h

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

removido
(usa Nenhuma)

Enviado em 12/12/2014 - 11:13h

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 

removido
(usa Nenhuma)

Enviado em 12/12/2014 - 11:21h

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

removido
(usa Nenhuma)

Enviado em 12/12/2014 - 11:34h

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

ianclever
(usa Arch Linux)

Enviado em 12/12/2014 - 11:56h

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.

removido
(usa Nenhuma)

Enviado em 12/12/2014 - 13:00h

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

buckminster
(usa Debian)

Enviado em 12/12/2014 - 13:15h

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

ianclever
(usa Arch Linux)

Enviado em 12/12/2014 - 19:36h

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;

removido
(usa Nenhuma)

Enviado em 12/12/2014 - 19:44h

Concordo plenamente!

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

buckminster
(usa Debian)

Enviado em 12/12/2014 - 20:11h

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.