Linux? - Page 231

Bravo !

#systemd# quoi

Non Connart Poettering, as usual.

Heu oui le mec a l'air d'être un vrai con là quand même ? La seule chose qui me rassure c'est les 40 downvotes qui suivent, mais ça doit vraiment être un bonheur de bosser avec des gens comme ça

Comme le dit Godzil, c'est Poettering, il s'est toujours comporté comme ça ; c'était pareil avant systemd, quand il s'occupait de pulseaudio. D'ailleurs Torvalds avant fini par l'engueuler publiquement sur une mailing list, parce qu'il en avait marre que Poettering refuse de reconnaître et de corriger les bugs dans son code.

PA qu'il a silencieusement abandonné, laissant la merde sous le tapis et laisser les autres se demerde a nettoyer tout ca. Combien de temps avant que SystemD subisse le meme sort?

Pourquoi malgré tous ces problèmes c'est quand même systemd qui a fait son entrée dans les distributions majeures ?

J'ai l'impression que c'était malheureusement plus une décision politique que technique, et le fait que Poettering bosse pour Red Hat ne doit pas y être étranger.

GNOME est le principal responsable, KDE n'as pas aidé non plus en imposant l'utilisaiton de certains bouts de systemd. Et systemd etant un machin completemetn indécoupable, c'est soit tout soit rien

Les 40 downvotes ne vont rien changer en tout cas (du moins tant que Lennart maintient le projet – dans le cas de PulseAudio, certaines des décisions de Lennart ont été reconsidérés par les nouveaux mainteneurs). Une fois qu'il a tranché son avis, nul au monde ne pourra lui faire changer d'avis.

Ca en fait un mauvais mainteneur communautaire.

c'est clair

hum

grx@grx ~ $ cat /etc/debian_version 
jessie/sid
(en fait c'est mint 17.3)
grx@grx ~$ sudo -s
Password:
grx ~ # useradd -M 0day
grx ~ # passwd 0day
Enter new UNIX password: plop
Retype new UNIX password: plop
passwd: password updated successfully
grx recipes # exit
grx@grx ~ $ su 0day
Password: plop
0day@grx /home/grx $ whoami
0day
0day@grx /home/grx $ id
uid=1001(0day) gid=1001(0day) groups=1001(0day)
0day@grx /home/grx $ exit
grx@grx ~ $ sudo userdel 0day

Zeph (./6907) :
Pourquoi malgré tous ces problèmes c'est quand même systemd qui a fait son entrée dans les distributions majeures ?

parce que malgré tous ces problèmes, systemd amène beaucoup de gros avantages

Pour faire lancer un démon avec le bon vieil init de Debian, il faut :

* avoir un programme qui fasse correctement le double fork pour bien passer en démon, avec la gestion du pid qui s'impose (et par exemple, en java, ça requiert de faire un peu de C ^^)
* écrire un script bash de plusieurs centaines de lignes en recopiant un exemple,
* écrire la partie « status » à la main (ça peut être pénible, d'ailleurs)
* écrire la partie qui va relancer ton process si tu ne peux pas utiliser le script de base
* avoir un script différent pour chaque distribution
* espérer que les démons dont dépend le tien soient bien lancés (genre le réseau), plus besoin de mettre des sleep comme on peut le voir régulièrement

Avec systemd :

* au lieu de ce script de plusieurs centaines de lignes, tu écris un fichier de conf de 10 lignes maximum
* ton programme n'a plus besoin de forker
* systemd s'occupera de le garder fonctionnel en permanence, de le tuer, de stocker son pid, de stocker stderr et stdout, …
* un seul fichier de conf pour toutes les distributions basées sur systemd !!!
* les dépendances aux autres démons sont prises en compte
* tu peux lancer ton démon seulement à la première connexion sur son socket
* tu peux limiter les ressources (% processeur/ram/disque/…) utilisées par ton démon via les cgroups

Bref, ça apporte beaucoup de choses et ça simplifie énormément la vie, notamment pour les mainteneurs de distribs qui n'ont plus à réécrire les scripts d'init eux-mêmes.
Pour les développeurs, ça simplifie également beaucoup la vie ; suffit d'avoir voulu faire un démon proprement pour l'apprécier

Après, pour les admin sys, il faut réapprendre beaucoup de choses, donc forcément, tout le monde n'apprécie pas.

OK merci pour les détails

J'ai l'impression que ça apporte beaucoup de choses positives par rapport à un système vieillissant, peut-être même un peu trop... dans un OS où le maitre mot est la modularité et où chaque composant n'a qu'un seul rôle pour pouvoir être interchangé avec un programme équivalent, ça ne fait pas un peu trop de tâches qui deviennent la responsabilité du seul systemd ? Ou bien derrière ce nom se cachent en fait plusieurs composants modulaires également ?

* un seul fichier de conf pour toutes les distributions basées sur systemd !!!

Bravo, tu joue bien le jeu de redhat.

Un process externe n'a PAS a décider de comment doit être configuré une autre application...

Sinon 100 lignes il ne faudriat pas exagerer je n'ai jamais vu d'init script aussi complexe sans raison, la majorité dépassent rarement les 10-15 lignes (et encore avec un set de script tel que OpenRC on peux faire avec beaucoup moins)

Zeph (./6915) :
ça ne fait pas un peu trop de tâches qui deviennent la responsabilité du seul systemd

C'est exactement l'une des critiques récurrentes de systemd : ça devient une usine à gaz qui gère plein de trucs (et de façon assez opaque, semble-t-il).

Oui c'est opaque, et ce soft partique les takeover aggressifs comme avec udev par exemple.

Qu'est-ce qu'un INIT a a foutre a gerer les entrée dans /dev ?
(ha oui au passage, systemd nest PAS embedded friendly at all, vu que c'est tout ou rien)

Godzil (./6916) :

* un seul fichier de conf pour toutes les distributions basées sur systemd !!!

Bravo, tu joue bien le jeu de redhat.

Un process externe n'a PAS a décider de comment doit être configuré une autre application...

Le jeu de Red Hat, c'est-à-dire ?

Le fichier de conf' n'est pas pour configurer l'application, mais configure systemd pour lui dire comment doit être lancée l'application. Du coup, je ne comprends pas trop ce que tu veux dire

Sinon 100 lignes il ne faudriat pas exagerer je n'ai jamais vu d'init script aussi complexe sans raison, la majorité dépassent rarement les 10-15 lignes (et encore avec un set de script tel que OpenRC on peux faire avec beaucoup moins)

Sur une Debian 6 neuve, la taille moyenne est de 108 lignes sur 46 fichiers d'init ^^

Zeph (./6915) :
OK merci pour les détails

J'ai l'impression que ça apporte beaucoup de choses positives par rapport à un système vieillissant, peut-être même un peu trop... dans un OS où le maitre mot est la modularité et où chaque composant n'a qu'un seule rôle pour pouvoir être interchangé avec un programme équivalent, ça ne fait pas un peu trop de tâches qui deviennent la responsabilité du seul systemd ? Ou bien derrière ce nom se cachent en fait plusieurs composants modulaires également ?

Bah il n'y a pas une seule réponse, ça dépendra de chacun. Il est certain qu'une fois systemd utilisé, tu ne peux pas le remplacer facilement par autre chose.
D'un autre côté, je ne pense pas que le fait de pouvoir changer n'importe quel composant vaille vraiment la peine de perdre les avantages de systemd ; à la base on pouvait aussi changer « facilement » le noyau pour passer à autre chose, et c'est beaucoup moins vrai (parce que Linux apporte plein de choses qui ne sont pas supportées par les *BSD). Mais en pratique, c'est rarissime de prendre un autre noyau et c'est plus intéressant d'utiliser à fond les avantages de Linux plutôt que de s'en passer juste pour le plaisir d'être compatible *BSD.

Après, si les gens veulent autre chose que systemd, qu'ils fassent le boulot ; c'est dur de demander aux mainteneurs et aux développeurs de supporter des systèmes d'init qui leurs demandent nettement plus de boulot.

Et OpenRC n'est pas du tout parfait, par exemple, pour utiliser LUKS avec OpenRC, tu dois convertir /etc/crypttab en une configuration OpenRC, parce qu'il est incapable de lire le vrai fichier.

pour moi le problème de systemd est aussi qu'il gère trop de choses. une compromission de ce truc serait grave.

squalyl (./6921) :
pour moi le problème de systemd est aussi qu'il gère trop de choses. une compromission de ce truc serait grave.

comment ça ? chaque sujet est traité par un binaire différent

SystemD dans toute sa splendeur:

https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html

https://github.com/systemd/systemd/issues/5755#issuecomment-310932048

http://lkml.iu.edu//hypermail/linux/kernel/1408.1/02496.html (mauvais copier coller celui la en parle, mais n'est pas centré sur SD)

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

et plein d'autre truc mais ca me semble deja pas mal

Et merci a squalyl pour cette super source d'information: https://twitter.com/systemdsucks

Edit: Oh et Poettering refuse toujours de voir la gestion des noms d'utilisateur comme une faille, malgres l'assignation d'un CVE ( CVE-2017-1000082 )

la meilleure ca serait que les distro commencent a VIRER systemd.

`

squalyl (./6924) :
la meilleure ca serait que les distro commencent a VIRER systemd.

La solution est simple : il suffit de trouver une meilleure solution pour les mainteneurs de distrib ^^

Tu veux parler d'une solution de maintenance des mainteneurs de distrib ?

sudo make me a sandwich
sudo systemctl sandwich give

Méfie-toi : avec systemd, ce serait :
"tiens voilà ton sandwich au beurre de cacahuète"
"mais j'avais demandé un sandwich jambon-fromage, je suis allergique au beurre de cacahuète"
"NOTABUG, CLOSED"

Non, plutôt:
# sudo systemctl sandwich cacahuètes give
[ OK ] Voilà votre sandwich au caca!