SystemD: le retour de la vengeance - Page 3

En fait, systemd est la version cancéreuse de BusyBox.

OUi mais non busybody a une raison précise d'exister et d'être fait comme il est, et ce pour des contraintes évidentes quand on travail dans l'embarque et le code est plutôt propre est vraiment modulaire (en fait on peu compiler proprement busybox avec une applet par fichier. Et BB n'as pas pour credo de remplacer tout l'existant ni ne cherche à s'imposer ....

Godzil (./62) :
BB n'as pas pour credo de remplacer tout l'existant ni ne cherche à s'imposer ....

C'est bien pour ça que je dis que systemd est une version cancéreuse

Oh ok XD

Enfin SD et BB n'ont aucun code en commun (enfin j'espere...)

Préfèrerais-tu d'avoir 7 fois le même code pour communiquer avec systemd? Je trouve que cette optimisation est parfaitement normale.

Hummmmmmmmmm? donc tu prefere le Kernel?

Godzil (./60) :
Pleins de petits utilitaires independant hein:

Make each program do one thing well. pic.twitter.com/SRc4121FJ7

— mulander (@mulander) July 18, 2017

oué, enfin c'est quand même de mauvaise foi… il y a pas mal de binaires indépendants, mais ça n'empêche pas d'être intelligent et faire des alias pour factoriser le code…

Factoriser quoi?

halt est un simple syscall
poweroff est un simple syscall
reboot est un syscall (mais peux faire un peu plus dans certains cas)
shutdown est compliqué
telinit n'a rien a voir avec avec reboot/shutdown/poweroff
runlevel n'a rien a voir avec tous les autres outils

Donc factoriser quoi?

Godzil (./68) :
halt est un simple syscall

Non, c'est équivalent à shutdown -h now depuis longtemps. (Il faut appeler halt -f pour arrêter immédiatement.) Ça a été changé pour protéger l'utilisateur déjà bien avant systemd.

poweroff est un simple syscall
reboot est un syscall (mais peux faire un peu plus dans certains cas)

Même remarque dans les deux cas.

shutdown est compliqué

C'était compliqué, maintenant, c'est un simple message à envoyer à systemd qui s'occupe du reste, c'est pour ça que systemctl s'en occupe.

telinit n'a rien a voir avec avec reboot/shutdown/poweroff
runlevel n'a rien a voir avec tous les autres outils

Là aussi, systemd s'en occupe, il suffit de parler à systemd, donc systemctl s'en occupe. Et ces commandes ont toujours été du domaine du système init.

Donc factoriser quoi?

La communication avec systemd. Toutes les 6 commandes ne font qu'envoyer des messages à systemd, rien de plus.

haaa la communication avec systemd...

Bien sur et donc le truc est tellement complexe qu'on est obligé de TOUT factoriser dans UN seul outil. oui c'est ca le progres.

La communication passe par D-Bus.

Ha oui dbus...

Systemctl.c: ~8600 lignes de codes

https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c

Sys V Init Shutdown: ~860 lignes de code
http://svn.savannah.gnu.org/viewvc/sysvinit/sysvinit/trunk/src/shutdown.c?view=markup&pathrev=101

halt/powerdown/reboot sont géré par halt: (~320 lignes)
http://svn.savannah.gnu.org/viewvc/sysvinit/sysvinit/trunk/src/halt.c?view=markup&pathrev=101
qui est printipalement force == syscall, sinon on appeil shutdown

init lui est plus gros: ~3000 lignes de code
http://svn.savannah.gnu.org/viewvc/sysvinit/sysvinit/trunk/src/init.c?view=markup&pathrev=101

Mais si on fait le calcul "systemctl" fait ~8600 et ce n'est qu'une PETITE partie de systemd vu que ce n'est pas init.
SysVinit pour les bloc principaux sus cité on a donc: 860 + 3000 + 320 = ~4200 soit moitié moins de code et ici on fait plus au final vu qu'on a un init complet et pas juste un truc pour discuter avec le process init.

Comment dire.

mais il faut aussi compter tous les scripts dans /etc/init.d

Non pas dans cette comparaison.

dbus... si ca plante, tu peux plus éteindre la bécane, ca s'est déja vu.

Tiens on devrais utiliser dbus dans les avions, satellites et voitures pour remplacer les bus CAN et autres bus de transfer de donnée critiques!
Après tout si SD l'utilise cest que c'est fiable et robuste!

Plaisanter avec le software, c'est une chose ; mais encourager les gens comme Poettering à faire du hardware, ça va trop loin ! J'ai pas envie de devoir changer de métier à cause de tes conneries

Le poettruc n'est pas l'auteur de dbus (heureusement dans un sens)

La news du jour (merci Squalyl):

Systemd bug of the week https://t.co/h7QcS61LxY blocked netflix viewers on gnu/linux, underscore in domain names rejected by systemd-resolvd

— Jaromil Rojo (@jaromil) July 24, 2017

Euuuh... qu'est-ce que la resolution DNS fout dans l'init ?

#SystemD

systemd all the things

OBO (./81) :
Euuuh... qu'est-ce que la resolution DNS fout dans l'init ?

Est-ce vraiment le cas ?
systemd recouvre pas mal de choses, dont l'init. Ce n'est pas dit que la résolution DNS en fasse partie

en l'occurrence le pbm est dans systemd-resolv

flanker (./84) :
systemd recouvre pas mal de choses, dont l'init.

Ça ne fait que déplacer la question. Est-ce vraiment une bonne chose d'avoir un projet tentaculaire, surtout quand il est géré comme l'est systemd ?

Non.

Bon.
Alors.
Moi pas geek. Moi parler d'init dans le sens global de "boot" de la machine, bref tout jusqu'au prompt bash/xdm/gdm/trucdm

Zerosquare (./86) :

flanker (./84) :
systemd recouvre pas mal de choses, dont l'init.

Ça ne fait que déplacer la question. Est-ce vraiment une bonne chose d'avoir un projet tentaculaire

L'est-il plus que Windows ou macOS ?
au niveau de la gestion, c'est autre chose

Ta comparaison va dans le sens de ceux qui disent que systemd devrait plutôt s'appeler PoetteringOS

En attendant, c'est contraire à l'esprit UNIX/Linux. Et même chez MS ou Apple, je doute que ce soit les mêmes personnes qui supervisent le boot et la gestion DNS.