Je trouve que systemd c'est justement une personne qui a voulu ré-écrire une partie du système justement où on accumulait du code dans tous les sens pour un service pas si fiable (les scripts de /etc/init.d était quand même vraiment lourd et lents pour la plupart, sans quasiment aucune unification).
La lourdeur et la lenteur ne sont pas forcément les points les plus importants. Je ne dis pas qu'il fallait garder les scripts d'inits comme ils étaient, par contre la façon de faire de systemd n'est pas non plus la bonne façon de faire.
Les scripts d'init avaient pour gros avantage d'être modifiables et personnalisables à l'envie, de ne pas enfermer les admins dans un moule rigide (ou t'es obligé de te tordre le cerveau dès que tu n'es pas dans un cas prévu), et de pouvoir corriger les bugs du système de démarrage sans avoir à recompiler et attendre une livraison de nouvelle version.
Le fait que les scripts soient des scripts permettait en outre si on le voulait d'étudier facilement ce qu'ils faisaient en les modifiants, sans avoir à passer par des phases de compilation assez lourdes (bien entendu, je parle de faire ça dans un environnement de test, pas sur de la prod ...).
A contrario, systemd est un truc plutôt "boite noire" qui peut effectivement permettre de gagner du temps lorsque l'on rentre dans le moule (90% des cas), mais qui fait perdre bien plus de temps pour gérer les 10% de cas non prévus par le bouzin (et manque de bol pour moi, c mon job de gérer ces cas de figure).
Je ne nie pas que systemd apporte un certain nombre d'avantages (par exemple la possibilité de monitorer un process et de le relancer s'il se vautre tout seul), mais il apporte un gros lot d'inconvénients, notamment une perte de souplesse par rapport à init ou upstart.
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 2.
La lourdeur et la lenteur ne sont pas forcément les points les plus importants. Je ne dis pas qu'il fallait garder les scripts d'inits comme ils étaient, par contre la façon de faire de systemd n'est pas non plus la bonne façon de faire.
Les scripts d'init avaient pour gros avantage d'être modifiables et personnalisables à l'envie, de ne pas enfermer les admins dans un moule rigide (ou t'es obligé de te tordre le cerveau dès que tu n'es pas dans un cas prévu), et de pouvoir corriger les bugs du système de démarrage sans avoir à recompiler et attendre une livraison de nouvelle version.
Le fait que les scripts soient des scripts permettait en outre si on le voulait d'étudier facilement ce qu'ils faisaient en les modifiants, sans avoir à passer par des phases de compilation assez lourdes (bien entendu, je parle de faire ça dans un environnement de test, pas sur de la prod ...).
A contrario, systemd est un truc plutôt "boite noire" qui peut effectivement permettre de gagner du temps lorsque l'on rentre dans le moule (90% des cas), mais qui fait perdre bien plus de temps pour gérer les 10% de cas non prévus par le bouzin (et manque de bol pour moi, c mon job de gérer ces cas de figure).
Je ne nie pas que systemd apporte un certain nombre d'avantages (par exemple la possibilité de monitorer un process et de le relancer s'il se vautre tout seul), mais il apporte un gros lot d'inconvénients, notamment une perte de souplesse par rapport à init ou upstart.