OS 10 BUGS MAIS BIZARROS DE SYSTEMD

Provavelmente foram corrigidos pela época. São tão absurdos, mas tão absurdos que fazem pensar no perigo dese shitware. Privacidade é o de menos aqui. Talvez nem sejam bugs. o.O

10 - Falha em executar su - root
https://bugzilla.redhat.com/show_bug.cgi?id=753882#c29

9 - Systemd usa DNS resolvers do Google por default
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1449001

8 - Systemd falha ao iniciar se /etc/fstab contém sistema de arquivos NFS
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746358

7 - Segfault se não houver cgroups
https://bugs.freedesktop.org/show_bug.cgi?id=74589

6 - Systemd não envia sinal SIGTERM antes de desligar o sistema
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1448259

5 - Como reparar journal corrompido? (RESOLVED NOTABUG)
https://bugs.freedesktop.org/show_bug.cgi?id=64116

4 - Systemd não inicia interfaces de rede até que o usuário não faça login
http://lists.mythtv.org/pipermail/mythtv-users/2016-July/387810.html

3 - Systemd mata processos de usuário em segundo plano durante logout
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394

2 - Systemd monta diretório /etc em modo read-only
https://bugzilla.redhat.com/show_bug.cgi?id=1350450

1 - Systemd pode transformar sua maquina em um tijolo caro (efivars em modo r/w) o.O Se rm -fr / for executado tendo EFI montado com variáveis com permissão de escrita, então a BIOS já era. Um erro de software que pode destruir o hardware. Incrível!
https://github.com/systemd/systemd/issues/2402

e

11 - systemd usa um servidor de tempo Google que não provê formato padronizado:
https://github.com/systemd/systemd/issues/437

Fonte: https://www.linuxito.com/gnu-linux/722-los-10-bugs-mas-bizarros-de-systemd 04/08/2016


EDIT:

Bônus: https://github.com/systemd/systemd/issues/5644 esta falha foi o que faltava a alguns a se decidirem contra SystemD de vez. Poettering sobre o bug: "I am not sure I'd consider this much of a problem."

Dwelling on the past is the mark of a small mind.

listeiro_037,

neste link que tu postou

https://github.com/systemd/systemd/issues/5644

veja que o Poettering, após dizer que não considerava o bug um grande problema e foi contestado pelos outros, bloqueou os comentários.
Acredito que isso reflete o pensamento desse cara autor e desenvolvedor do systemd.

Frases de efeito agora?
Quer dizer que o systemd é o futuro e quem não concorda com ele no todo ou em parte tem a mente pequena?

Meu caro, a ciência progride justamente pelo contraditório, pela conversa, pelo debate franco e aberto e não somente com frases de efeito.

+1

Este pensamento de impor que uma ideia é melhor e todos devem seguí-la é coisa da Inquisição. Infelizmente muitas distros entraram na Inquisição, purgando de vez a escolha dos usuários para favorecer o uso desta porquera.

-----------------------------------''----------------------------------

Larry, The Cow, uses Gentoo GNU/Linux

^__^
(oo)
(__)

"If it moves, compile it."

O problema é: O que fazer sobre? Quem trabalha com servidores como eu sabe que ele não vai ir embora das nossas vidas tão cedo.

Estava refletindo: o principal argumento da implementação do SystemD é uma falácia. Vou resumir informações que obtive e as conclusões:

A alegação é o aumento da velocidade de inicialização. Quanto de aumento de velocidade? Quais as estatísticas que comprovam a eficiência e a eficácia? Quais as métricas adotadas?

Se for contar o uso de Linux para desktop, então o uso de SystemD será para uma fatia miserável. Por acaso esses sistemas terão muitos daemons a serem carregados? Muitos usuários também deixam as máquinas em suspensão ou hibernando. Ninguém fica desligando ou reiniciando a máquina a cada cinco minutos.

Se servidores forem o foco, também vale o questionamento: ficar religando toda hora? Se o próprio kernel estava sendo adaptado para fazer upgrade na memória a quente, isto é, com o sistema estando ligado e em uso, então qual o motivo de reiniciar? Qual a frequência de desligamento e religamento de servidores críticos?

Os servidores possuem serviços separados. Imagino que um servidor HTTP esteja numa máquina separada de um servidor BD. Dá mesmo problemas com tantos daemons, montagem de sistemas de arquivo em rede, SSH, Knockd, controladoras RAID ... o que mais?

Não sei se criar um serviço tão intrometido assim compensa o custo-benefício e os eventuais problemas e prejuízos.

EDIT:

A capacidade computacional está aumentando. Isto também não conta a favor do aumento de velocidade? Máquinas cada vez mais rápidas podem tornar supérflua esta pressuposta inovação.

Eu já notei a 2, 3, 4 e 5... Notei não, me estabaquei com elas...

O systemd é uma anta em poucas palavras, criado por uma toupeira.
Se essa coisa é o futuro do Gnu/Linux, então, viva aos Forks sem esse lixo e a família BSD :D

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

O tenso é ter que aprender essa budega pra LPI -.-

Concordo em gênero, numero e grau com suas afirmações. Diabo de servidor é esse que tem que se preocupar com tempo de boot. Esses trem demora pra k7 mesmo, até realizar todos os POST dos componentes de um servidor de verdade o tempo de boot do SO é irrelevante praticamente.

Não sou, nem de longe, um especialista no assunto e fiquei intrigado com os bugs. Mas, já usei distros com e sem SystemD. Sinceramente, a diferença no boot é, como se diz na física do 2º grau, uma variável que pode ser desprezada. A diferença é bem pequena. Não consegui ver fins práticos nessa justificativa.

Argumentos PRÓ-SystemD:

Encontrei estes links e estou tentando compreender algumas coisas. É justo conhecer a argumentação.

O Blog do próprio LP: http://0pointer.net/blog/projects/the-biggest-myths.html

Um fórum não sei de quê: https://www.phoronix.com/forums/forum/phoronix/general-discussion/44894-new-group-calls-for-boycotti...

Se fosse apenas isso, melhorar o processo de boot, tudo bem. O problema é que ele quer controlar tudo, boot, login, logs, serviços...

Ele deveria fazer a mesma função dos antigos gerenciadores de boot, e pronto.