En même temps Apache c'est un service applicatif, on a pas forcément les mêmes demandes qu'avec un système d'init.
il y a un patchwork de fichier de conf (répondant à 90% des besoins) et des modules (les 10%)
Tu as pas du souvent utiliser apache. Les modules de apache couvrent les besoins de base. tu as des fichiers de conf spécifiques pour les modules.
En fait comme quasiment partout, sauf un truc horrible à coup de scripts uniquement.
Euh non pas comme "quasiment partout". Certains serveurs applicatifs couvrent leurs besoins sans avoir rajouter modules et plugins dont certains avec des fichiers de conf différents.
Et qu'est ce que ça a d'horrible d'avoir des fichiers de confs et des modules (les scripts) ?
Ah oui, rien. Sauf que c'est cohérent :
Des scripts shell pour le démarrage avec init/upstart.
Des modules compilés spécifique pour apache avec l'API apache pour apache.
Des fichiers de confs spécifiques aux "modules" (pour l'init les scripts, pour apache, les .so) dans les deux cas.
Sauf que poru systemd, ce n'est pas cohérent : on refuse les scripts shell pour le démarrages des services, mais finalement on les veux bien son a besoin de rajouter des commandes à executer avant, etc…
Bref, pas cohérent du tout.
Et encore une fois, rien ne t'empèchera de configurer pour lancer ton script "comme avant" sans toucher une ligne de C. C'est du FUD.
Je vois pas bien en quoi je fait peur à qui que ce soit.
Faut juste pas venir nous expliquer que systemd est super "normalisé" itou, et en même temps avoir besoin de passer soit par de gros hack (non cohérent avec le principe du système), soit de changer tous le systèmes en, excusant du peu, devoir recompiler l'init.
En une ligne comme en cents : le shell script c'est facile a modifier et à gérer, et c'est proche du système. D'où son intérêt dans l'utilisation de l'initialisation.
Et faire un système batard ne sert qu'a complexifier inutilement les choses.
[^] # Re: Choix
Posté par briaeros007 . En réponse au journal Traduction : le sophisme systemd -- Leszek Urbanski, tgr, monolight.cc. Évalué à 2.
En même temps Apache c'est un service applicatif, on a pas forcément les mêmes demandes qu'avec un système d'init.
Tu as pas du souvent utiliser apache. Les modules de apache couvrent les besoins de base. tu as des fichiers de conf spécifiques pour les modules.
Euh non pas comme "quasiment partout". Certains serveurs applicatifs couvrent leurs besoins sans avoir rajouter modules et plugins dont certains avec des fichiers de conf différents.
Et qu'est ce que ça a d'horrible d'avoir des fichiers de confs et des modules (les scripts) ?
Ah oui, rien. Sauf que c'est cohérent :
Des scripts shell pour le démarrage avec init/upstart.
Des modules compilés spécifique pour apache avec l'API apache pour apache.
Des fichiers de confs spécifiques aux "modules" (pour l'init les scripts, pour apache, les .so) dans les deux cas.
Sauf que poru systemd, ce n'est pas cohérent : on refuse les scripts shell pour le démarrages des services, mais finalement on les veux bien son a besoin de rajouter des commandes à executer avant, etc…
Bref, pas cohérent du tout.
Je vois pas bien en quoi je fait peur à qui que ce soit.
Faut juste pas venir nous expliquer que systemd est super "normalisé" itou, et en même temps avoir besoin de passer soit par de gros hack (non cohérent avec le principe du système), soit de changer tous le systèmes en, excusant du peu, devoir recompiler l'init.
En une ligne comme en cents : le shell script c'est facile a modifier et à gérer, et c'est proche du système. D'où son intérêt dans l'utilisation de l'initialisation.
Et faire un système batard ne sert qu'a complexifier inutilement les choses.