La question devrait plutôt être : en quoi systemd vous a négativement impacté
Des commandes qui me renvoient « Permission denied » en root grâce à la magie de policykit/consolekit/logind. Ça fait toujours plaisir quand ta machine te dis « va te faire foutre ». C’est pas toi normalement l’ayattolah de « c’est la machine qui doit être au service de l’homme et pas l’inverse » ? :)
Un hard reboot sur un serveur de prod à cause d’un crash du pid 1 (raison inconnue à ce jour) qui a empêché complètement l’utilisation à la fois de systemctl, et, plus « rigolo », journalctl et reboot (c’est pratique de débugger et corriger l’erreur dans ces conditions). Alors je suis d’accord qu’un crash d’un process n’est pas choquant pour un logiciel aussi jeune, par contre le fait qu’un crash rende inopérant des choses aussi fondamentales c’est juste ridicule et assez révélateur des problèmes que les anti-systemd pointent du doigt depuis le début, relativement aux couplages forts de ses composants.
J’ai pas mal poussé pour l’adoption assez rapide (via les backports debian) de systemd en interne grâce à certaines de ses fonctionnalités qui sont extrêmement adaptées à notre workflow (et globalement ça reste positif), mais j’avoue que ces deux points m’ont assez refroidis... Si jamais notre workflow n’avait pas été aussi adapté à systemd, le bilan aurait été extrêmement négatif.
[^] # Re: Fonctionnalités clées.
Posté par Moonz . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 8.
Des commandes qui me renvoient « Permission denied » en root grâce à la magie de policykit/consolekit/logind. Ça fait toujours plaisir quand ta machine te dis « va te faire foutre ». C’est pas toi normalement l’ayattolah de « c’est la machine qui doit être au service de l’homme et pas l’inverse » ? :)
Un hard reboot sur un serveur de prod à cause d’un crash du pid 1 (raison inconnue à ce jour) qui a empêché complètement l’utilisation à la fois de systemctl, et, plus « rigolo », journalctl et reboot (c’est pratique de débugger et corriger l’erreur dans ces conditions). Alors je suis d’accord qu’un crash d’un process n’est pas choquant pour un logiciel aussi jeune, par contre le fait qu’un crash rende inopérant des choses aussi fondamentales c’est juste ridicule et assez révélateur des problèmes que les anti-systemd pointent du doigt depuis le début, relativement aux couplages forts de ses composants.
J’ai pas mal poussé pour l’adoption assez rapide (via les backports debian) de systemd en interne grâce à certaines de ses fonctionnalités qui sont extrêmement adaptées à notre workflow (et globalement ça reste positif), mais j’avoue que ces deux points m’ont assez refroidis... Si jamais notre workflow n’avait pas été aussi adapté à systemd, le bilan aurait été extrêmement négatif.