Systemd est-il «malveillant»? [fermé]

11

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement les réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 4 ans .

En visitant un forum en ligne qui discute de Debian et Xubuntu, j'ai vu des utilisateurs qui ajoutent cette ligne dans le champ de signature:

... Sans systemd ...

Cette ligne est montrée avec fierté (il me semble).

De Wikipédia :

systemd est une suite de démons, de bibliothèques et d'utilitaires de gestion système conçue comme une plate-forme centrale de gestion et de configuration pour le système d'exploitation informatique Linux.

Cela systemdne semble donc pas être une mauvaise chose, alors pourquoi les gens écrivent-ils avec fierté qu'ils ne l'utilisent pas?

Peut systemdêtre dangereux ou tout simplement mauvais pour vous?

systemd init

— xdola
source

1

Avez-vous lu la partie Adoption et réception de cet article Wikipédia? Il contient des références à plusieurs articles expliquant pourquoi certaines personnes ne l'aiment pas.

— Leiaz

8

Non, ce n'est ni dangereux ni mauvais pour toi. Vous êtes tombé sur une petite bataille des guerres initiales . Je n'entrerai pas dans les détails mais, brièvement, la situation est la suivante.

Linux a utilisé sysvinit pendant la majeure partie de sa durée de vie. C'est ancien et il manque de fonctionnalités et la seule chose à laquelle tout le monde est d'accord, c'est qu'il doit être changé. Cependant, personne ne peut s'entendre sur ce qu'il faudrait changer. Diverses alternatives ont été proposées, notamment - mais sans s'y limiter - les suivantes:

Les deux sont bons à leur manière et mauvais chez les autres. Comme cela arrive souvent dans le monde geek, le choix du système init (l'un de ces deux ou un autre) à adopter est devenu quelque chose de similaire à une guerre de religion.

Donc, vous êtes tombé sur quelqu'un qui n'aime pas systemdet, par conséquent, est fier de ne pas l'utiliser. Il y a plusieurs personnes qui ont l'opinion contraire et pensent que systemdc'est merveilleux et tout le reste horrible. Tout comme il y en a sur tout autre sujet sur les interwebs larges et merveilleux.

Heureusement, les guerres initiales mijotent et ont maintenant dépassé leur apogée. La plupart des distributions Linux ont décidé de passer à systemd. Même Ubuntu de Canonical, bien qu'ils soient la force derrière upstart. Donc, aujourd'hui, systemdc'est en fait le système d'init de choix pour à peu près toutes les distributions majeures sauf Gentoo ( source d' image ):

— terdon
source

6

Avez-vous lu l' article Wikipédia que vous avez lié? Plus précisément, le troisième paragraphe.

La conception de systemd a généré une controverse importante au sein de la communauté des logiciels libres. Les critiques soutiennent que systemd est trop complexe et souffre d'un fluage continu des fonctionnalités, et que son architecture viole les principes de conception des systèmes d'exploitation de type Unix. On craint également qu'il forme un système de dépendances imbriquées, ce qui donne aux responsables de la distribution peu de choix, mais d'adopter systemd car de plus en plus de logiciels d'espace utilisateur dépendent de ses composants.

Il y a aussi une grande section plus bas intitulée " Histoire et controverse ".

— Sparhawk
source

4

Cela dépend de ce que vous considérez comme malveillant. Par exemple. suckless.org le considère malveillant:

http://suckless.org/sucks/systemd

Je n'essaie certainement pas de déclencher une guerre des flammes ici et en fait je l'utilise en tant qu'utilisateur Debian, mais franchement, je suis pour ma part d'accord avec suckless.

MISE À JOUR: Je pense que je devrais expliquer pourquoi je suis d'accord avec suckless. Alors voilà: je pense que c'est beaucoup trop complexe et fournit un contrôle trop «centralisé» sur le système. Les vidages mémoire, les journaux, etc. sont stockés dans la base de données journald. Que faire si mon fs échoue et que la base de données est corrompue - plus de journaux à consulter. Plus de fichiers de base à analyser. Le stockage de fichiers en clair offre naturellement une meilleure résilience aux pannes dans de tels cas. Personnellement, je suis à peu près d'accord avec tous les points de la liste sans succès, mais je laisse la réponse à la question principale à la discrétion de tous.

— Alex
source

4

vous devriez dire pourquoi

— mikeserv

1

@mikeserv: Il y a beaucoup de "parce que" sur la page suckless. :) et sur la page Wikipédia (citée dans la réponse de Sparhawk). Je pense que c'est beaucoup trop complexe et fournit un contrôle trop «centralisé» sur le système. Les vidages mémoire, les journaux, etc. sont stockés sur la base de données. Que faire si mon fs échoue et que la base de données est corrompue - plus de journaux à consulter. Plus de fichiers de base à analyser. Le stockage de fichiers en clair offre naturellement une meilleure résilience aux pannes dans de tels cas. Alors, ouais - POURQUOI?!?

— Alex

les coredumps et les journaux peuvent être écrits dans des journaux et / ou syslog, console, autres, je ne suis pas en désaccord, cela peut être compliqué , mais je ne pense pas que cela se traduit directement par malveillant , et je ne pense pas que cette réponse supporte cette traduction.

— mikeserv

1

@mikeserv: vrai. Cependant, c'est soit journal db, soit un goulot d'étranglement supplémentaire dans la journalisation du système (maintenant la journalisation dépend de journald ET de syslogd). Concernant le point malveillant: comme je l'ai dit, cela dépend de ce que vous considérez comme malveillant. Si un système empêche la résilience aux pannes - c'est en effet malveillant pour moi.

— Alex

1

Cela ne veut pas dire que c'est le cas spécifiquement avec systemd, mais une combinaison de sous-systèmes indépendants peut réellement augmenter la résistance aux pannes . Comparez un noyau monolithique à un noyau de microarchitecture. Ignorons les performances et examinons simplement la résistance aux pannes. Qui est plus résistant aux pannes: une combinaison de composants (potentiellement volumineux), interagissant les uns avec les autres via des interfaces bien définies; ou une énorme masse unique de code où tout est libre de pousser n'importe quoi par accident? Je pense que l'on peut affirmer que fait correctement, le choix de la microarchitecture est plus résistant aux pannes.

— un CVn du

3

Pas aussi malicieux que stupide.

Les concepteurs sont tellement remplis de leur propre vision qu'ils ne parviennent pas à comprendre ce qui rend les systèmes de type POSIX excellents.

"Ceux qui ne comprennent pas Unix sont condamnés à le réinventer, mal."

          Henry Spencer

— racine
source