Posté par Kaane .
En réponse au journal udev forké.
Évalué à 2.
Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins…
On passe sur la logique tarabiscotté (il est faux de dire que A a besoin de B pour fonctionner avec C vu que A a été créé à cause de D)
Ensuite tu penses sincèrement que toutes les options de apachectl seront codées dans un init un jour, notamment les options des modules compilés statiquement dans apache ? Parce que apachectl fait ça aussi.
T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null
Clairement, si systemd devient le standard, apache laisse tomber windows, Mac et *BSD.
Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services
CF mon autre post dans l'autre thread pour cette question, systemd est aveugle et sourd sans DBus. (ce qui ne l'empêche pas de lancer des services d'accord, mais pour le contrôle on repassera)
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 2.
Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins…
On passe sur la logique tarabiscotté (il est faux de dire que A a besoin de B pour fonctionner avec C vu que A a été créé à cause de D)
Ensuite tu penses sincèrement que toutes les options de apachectl seront codées dans un init un jour, notamment les options des modules compilés statiquement dans apache ? Parce que apachectl fait ça aussi.
T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null
Clairement, si systemd devient le standard, apache laisse tomber windows, Mac et *BSD.
Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services
CF mon autre post dans l'autre thread pour cette question, systemd est aveugle et sourd sans DBus. (ce qui ne l'empêche pas de lancer des services d'accord, mais pour le contrôle on repassera)