Un script bash est plus facile à debug qu'un binaire, de même que n'importe quel langage de script, au fait : il est plus simple d'y debug des erreurs de programmation
Bon, je passe sur le fait qu'il est tout à fait possible d'utiliser des binaires avec sysvinit .. qu'importe.
Je concluerai sur deux points :
- utiliser un truc en dev pour de la prod est typiquement une mauvaise idée.
- je me fiche de savoir que systemd fait des trucs "cool" quand il fonctionne. Ce qui m'intéresse, c'est ce qu'il se passe lorsqu'il ne fonctionne pas. Penser qu'un système fonctionne toujours est un échec intellectuel : les bons systèmes sont les résiliants aux pannes
# Hmm
Posté par haleth . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à -10.
Mouais, y'a aussi des vrais arguments.
Prenons un exemple (et oui, je compare systemd à sysvinit, puisque je compare le nouveau avec l'existant).
Comment debug un daemon ?
- systemd: SYSTEMD_LOG_LEVEL ? Est-ce suffisant et exhaustif ?
- sysvinit : bash -x /etc/init.d/blabla start
Un script bash est plus facile à debug qu'un binaire, de même que n'importe quel langage de script, au fait : il est plus simple d'y debug des erreurs de programmation
Bon, je passe sur le fait qu'il est tout à fait possible d'utiliser des binaires avec sysvinit .. qu'importe.
Je concluerai sur deux points :
- utiliser un truc en dev pour de la prod est typiquement une mauvaise idée.
- je me fiche de savoir que systemd fait des trucs "cool" quand il fonctionne. Ce qui m'intéresse, c'est ce qu'il se passe lorsqu'il ne fonctionne pas. Penser qu'un système fonctionne toujours est un échec intellectuel : les bons systèmes sont les résiliants aux pannes