Tu déformes le journal en disant que "systemd est moins bon que SySVInit", il dit juste qu'une option par défaut ne lui convient pas (la belle affaire).
Tu as mal lut mon propos, ou j'ai mal compris le tient. Je concède que systemd est meilleur que SysVInit pour les mainteneurs d'une distribution. De part les retours que tu peux lire ici même et ailleurs sur internet, systemd est à la fois apprécié et décrié par les sysadmin. De même, systemd est source de nombreux problèmes pour les développeurs et utilisateurs lambda. Il existe des alternatives tout à fait valable à SysVInit, comme minit ou runit.
En quoi c'est le problème de systemd ? Upstart a un système pour rendre compatible avec ce que propose systemd.
C'est le problème de systemd car avant systemd il n'y avait pas à « être compatible avec systemd », et après systemd il faut « être compatible avec systemd ». Ou dit autrement, systemd casse un système qui était stable en redéfinissant le rapport entre les programmes utilisateurs et un système d'init, de force.
Tu peux donner des sources ? Quelles "programmes" ne fonctionnent plus en dehors de systemd ?
GNOME, KDE, tout les programmes qui utilisent udev, avahi et probablement d'autres. Sans compter les multiples bugs (comme pour tmux) qui forcent les développeurs a intégrer un « switch systemd » dans leur code, histoire de bien marquer au fer rouge la communauté.
[^] # Re: Bug ferme chez tmux
Posté par needs . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7. Dernière modification le 05 juin 2016 à 15:23.
Tu as mal lut mon propos, ou j'ai mal compris le tient. Je concède que systemd est meilleur que SysVInit pour les mainteneurs d'une distribution. De part les retours que tu peux lire ici même et ailleurs sur internet, systemd est à la fois apprécié et décrié par les sysadmin. De même, systemd est source de nombreux problèmes pour les développeurs et utilisateurs lambda. Il existe des alternatives tout à fait valable à SysVInit, comme minit ou runit.
C'est le problème de systemd car avant systemd il n'y avait pas à « être compatible avec systemd », et après systemd il faut « être compatible avec systemd ». Ou dit autrement, systemd casse un système qui était stable en redéfinissant le rapport entre les programmes utilisateurs et un système d'init, de force.
GNOME, KDE, tout les programmes qui utilisent udev, avahi et probablement d'autres. Sans compter les multiples bugs (comme pour tmux) qui forcent les développeurs a intégrer un « switch systemd » dans leur code, histoire de bien marquer au fer rouge la communauté.