C'était deja different. Un script d'init debian ne fonctionne pas sur une red hat. Sur une debian on utilise update-rc.d pour activer / désactiver un service au boot, alors que sur red hat il faut utiliser chkconfig. Et c'est encore different sur les autres distros et autres Unix.
Ca c'est de la surface, hein. Car update-rc.d ou chkconfig ne font rien d'autre que créer un lien au bon endroit. C'est juste une grosse surcouche à "ln -s"
Avec systemd au contraire, pour toutes les distributions l'utilisant ca fonctionne de la meme facon,
D'un autre côté, /etc/inittab fonctionne de la même façon sur toutes les distros.
avec les memes commandes. Et un fichier d'init systemd fonctionnera partout, il n'y qu'eventuellement le chemin du binaire ou d'un fichier de config passé en argument qu'il faut modifier si ils ne sont pas installés à l'endroit habituel.
Donc il n'y a pas deux distros qui fonctionneront pareil, merci d'avoir joué.
Maintenant, beaucoup de projets fournissent directement le fichier unit pour systemd avec les sources.
Le 21-10-2012, abc abc <abc@abc.abc> a écrit :
C'était deja different. Un script d'init debian ne fonctionne pas sur
une red hat. Sur une debian on utilise update-rc.d pour activer /
désactiver un service au boot, alors que sur red hat il faut utiliser
chkconfig. Et c'est encore different sur les autres distros et autres
Unix.
Ca c'est de la surface, hein. Car update-rc.d ou chkconfig ne font
rien d'autre que créer un lien au bon endroit. C'est juste une grosse
surcouche à "ln -s"
Avec systemd au contraire, pour toutes les distributions l'utilisant
ca fonctionne de la meme facon,
D'un autre côté, /etc/inittab fonctionne de la même façon sur toutes les
distros.
avec les memes commandes. Et un fichier
d'init systemd fonctionnera partout, il n'y qu'eventuellement le chemin
du binaire ou d'un fichier de config passé en argument qu'il faut
modifier si ils ne sont pas installés à l'endroit habituel.
Donc il n'y a pas deux distros qui fonctionneront pareil, merci
d'avoir joué.
Maintenant, beaucoup de projets fournissent directement le fichier unit
pour systemd avec les sources.
C'était deja different. Un script d'init debian ne fonctionne pas sur une red hat. Sur une debian on utilise update-rc.d pour activer / désactiver un service au boot, alors que sur red hat il faut utiliser chkconfig. Et c'est encore different sur les autres distros et autres Unix.
Ca c'est de la surface, hein. Car update-rc.d ou chkconfig ne font rien d'autre que créer un lien au bon endroit. C'est juste une grosse surcouche à "ln -s"
Avec systemd au contraire, pour toutes les distributions l'utilisant ca fonctionne de la meme facon,
D'un autre côté, /etc/inittab fonctionne de la même façon sur toutes les distros.
avec les memes commandes. Et un fichier d'init systemd fonctionnera partout, il n'y qu'eventuellement le chemin du binaire ou d'un fichier de config passé en argument qu'il faut modifier si ils ne sont pas installés à l'endroit habituel.
Donc il n'y a pas deux distros qui fonctionneront pareil, merci d'avoir joué.
Maintenant, beaucoup de projets fournissent directement le fichier unit pour systemd avec les sources.
JKB
Le 22 Oct 2012 07:45:00 GMT, Kevin Denis écrivait :
Le 21-10-2012, abc abc a écrit :
C'était deja different. Un script d'init debian ne fonctionne pas sur une red hat. Sur une debian on utilise update-rc.d pour activer / désactiver un service au boot, alors que sur red hat il faut utiliser chkconfig. Et c'est encore different sur les autres distros et autres Unix.
Ca c'est de la surface, hein. Car update-rc.d ou chkconfig ne font rien d'autre que créer un lien au bon endroit. C'est juste une grosse surcouche à "ln -s"
Euh... Non. Pas lorsque le init fonctionne en mode 'makefile'. Là, le lien créé n'a aucun rapport avec l'ordre de démarrage.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 22 Oct 2012 07:45:00 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait :
Le 21-10-2012, abc abc <abc@abc.abc> a écrit :
C'était deja different. Un script d'init debian ne fonctionne pas sur
une red hat. Sur une debian on utilise update-rc.d pour activer /
désactiver un service au boot, alors que sur red hat il faut utiliser
chkconfig. Et c'est encore different sur les autres distros et autres
Unix.
Ca c'est de la surface, hein. Car update-rc.d ou chkconfig ne font
rien d'autre que créer un lien au bon endroit. C'est juste une grosse
surcouche à "ln -s"
Euh... Non. Pas lorsque le init fonctionne en mode 'makefile'. Là,
le lien créé n'a aucun rapport avec l'ordre de démarrage.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 22 Oct 2012 07:45:00 GMT, Kevin Denis écrivait :
Le 21-10-2012, abc abc a écrit :
C'était deja different. Un script d'init debian ne fonctionne pas sur une red hat. Sur une debian on utilise update-rc.d pour activer / désactiver un service au boot, alors que sur red hat il faut utiliser chkconfig. Et c'est encore different sur les autres distros et autres Unix.
Ca c'est de la surface, hein. Car update-rc.d ou chkconfig ne font rien d'autre que créer un lien au bon endroit. C'est juste une grosse surcouche à "ln -s"
Euh... Non. Pas lorsque le init fonctionne en mode 'makefile'. Là, le lien créé n'a aucun rapport avec l'ordre de démarrage.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Kevin Denis
Le 21-10-2012, Emmanuel Florac a écrit :
Et upstart? et le truc de solaris dont le nom m'échappe présentement? Et le truc de Mac OS X?
launchd pour mac OSX. Il cumule init, cron et inetd. Il réagit à des événements, qu'ils soient temporels (cron), qu'ils viennent du réseau (inetd) ou particulier (le boot et l'extinction). -- Kevin
Le 21-10-2012, Emmanuel Florac <eflorac@imaginet.fr> a écrit :
Et upstart? et le truc de solaris dont le nom m'échappe présentement? Et
le truc de Mac OS X?
launchd pour mac OSX. Il cumule init, cron et inetd. Il réagit à des
événements, qu'ils soient temporels (cron), qu'ils viennent du
réseau (inetd) ou particulier (le boot et l'extinction).
--
Kevin
Et upstart? et le truc de solaris dont le nom m'échappe présentement? Et le truc de Mac OS X?
launchd pour mac OSX. Il cumule init, cron et inetd. Il réagit à des événements, qu'ils soient temporels (cron), qu'ils viennent du réseau (inetd) ou particulier (le boot et l'extinction). -- Kevin
Tonton Th
On 10/21/2012 11:47 PM, abc abc wrote:
L'inconvenient c'est que ca change les habitudes.
Avec systemd au contraire, pour toutes les distributions l'utilisant ca fonctionne de la meme facon, avec les memes commandes.
http://xkcd.com/927/
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 10/21/2012 11:47 PM, abc abc wrote:
L'inconvenient c'est que ca change les habitudes.
Avec systemd au contraire, pour toutes les distributions l'utilisant
ca fonctionne de la meme facon, avec les memes commandes.
http://xkcd.com/927/
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Avec systemd au contraire, pour toutes les distributions l'utilisant ca fonctionne de la meme facon, avec les memes commandes.
http://xkcd.com/927/
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Patrick Lamaizière
Doug713705 :
C'était deja different. Un script d'init debian ne fonctionne pas sur une red hat. Sur une debian on utilise update-rc.d pour activer / désactiver un service au boot, alors que sur red hat il faut utiliser chkconfig. Et c'est encore different sur les autres distros et autres Unix.
Que des bouses qui ne facilitent en rien la maintenance.
Ben c'est du linux hein, c'est pas fait pour faciliter la maintenance.
...
Maintenant, beaucoup de projets fournissent directement le fichier unit pour systemd avec les sources.
Super et si ma distrib n'utilise pas systemd, le projet tournera t-il encore longtemps sur mon OS ?
Vu le bordel entre distrib, j'ai du mal à croire à un fichier unit générique. Mais je peux me gourrer.
Doug713705 :
C'était deja different. Un script d'init debian ne fonctionne pas sur
une red hat. Sur une debian on utilise update-rc.d pour activer /
désactiver un service au boot, alors que sur red hat il faut utiliser
chkconfig. Et c'est encore different sur les autres distros et autres
Unix.
Que des bouses qui ne facilitent en rien la maintenance.
Ben c'est du linux hein, c'est pas fait pour faciliter la maintenance.
...
Maintenant, beaucoup de projets fournissent directement le fichier unit
pour systemd avec les sources.
Super et si ma distrib n'utilise pas systemd, le projet tournera t-il
encore longtemps sur mon OS ?
Vu le bordel entre distrib, j'ai du mal à croire à un fichier unit
générique. Mais je peux me gourrer.
C'était deja different. Un script d'init debian ne fonctionne pas sur une red hat. Sur une debian on utilise update-rc.d pour activer / désactiver un service au boot, alors que sur red hat il faut utiliser chkconfig. Et c'est encore different sur les autres distros et autres Unix.
Que des bouses qui ne facilitent en rien la maintenance.
Ben c'est du linux hein, c'est pas fait pour faciliter la maintenance.
...
Maintenant, beaucoup de projets fournissent directement le fichier unit pour systemd avec les sources.
Super et si ma distrib n'utilise pas systemd, le projet tournera t-il encore longtemps sur mon OS ?
Vu le bordel entre distrib, j'ai du mal à croire à un fichier unit générique. Mais je peux me gourrer.
Patrick Lamaizière
Tonton Th :
On 10/21/2012 11:47 PM, abc abc wrote:
L'inconvenient c'est que ca change les habitudes.
Avec systemd au contraire, pour toutes les distributions l'utilisant ca fonctionne de la meme facon, avec les memes commandes.
http://xkcd.com/927/
Rhaaaa encore ! On devrait créer un point xkcd...
Tonton Th :
On 10/21/2012 11:47 PM, abc abc wrote:
L'inconvenient c'est que ca change les habitudes.
Avec systemd au contraire, pour toutes les distributions l'utilisant
ca fonctionne de la meme facon, avec les memes commandes.
Maintenant, beaucoup de projets fournissent directement le fichier unit pour systemd avec les sources.
Super et si ma distrib n'utilise pas systemd, le projet tournera t-il encore longtemps sur mon OS ?
Vu le bordel entre distrib, j'ai du mal à croire à un fichier unit générique. Mais je peux me gourrer.
Ben si. Par exemple dovecot : http://hg.dovecot.org/dovecot-2.2/file/6c850258002f/dovecot.service.in
Tonton Th
On 10/22/2012 07:05 PM, Patrick Lamaizière wrote:
Avec systemd au contraire, pour toutes les distributions l'utilisant ca fonctionne de la meme facon, avec les memes commandes.
http://xkcd.com/927/
Rhaaaa encore ! On devrait créer un point xkcd...
Ou alors, on crée un tag [927] pour ce cas particulier, qui n'est pas si particulier que ça, en fait, vu qu'il se retrouve dans un grand nombre d'aspect de la vraie vie, tous domaines confondus.
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 10/22/2012 07:05 PM, Patrick Lamaizière wrote:
Avec systemd au contraire, pour toutes les distributions l'utilisant
ca fonctionne de la meme facon, avec les memes commandes.
http://xkcd.com/927/
Rhaaaa encore ! On devrait créer un point xkcd...
Ou alors, on crée un tag [927] pour ce cas particulier, qui n'est
pas si particulier que ça, en fait, vu qu'il se retrouve dans un
grand nombre d'aspect de la vraie vie, tous domaines confondus.
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Avec systemd au contraire, pour toutes les distributions l'utilisant ca fonctionne de la meme facon, avec les memes commandes.
http://xkcd.com/927/
Rhaaaa encore ! On devrait créer un point xkcd...
Ou alors, on crée un tag [927] pour ce cas particulier, qui n'est pas si particulier que ça, en fait, vu qu'il se retrouve dans un grand nombre d'aspect de la vraie vie, tous domaines confondus.
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Patrick Lamaizière
abc abc :
Vu le bordel entre distrib, j'ai du mal à croire à un fichier unit générique. Mais je peux me gourrer.
Ben si. Par exemple dovecot : http://hg.dovecot.org/dovecot-2.2/file/6c850258002f/dovecot.service.in
Ah ouais. C'est tellement générique que le daemon derrière systemd *doit* fermer les sockets si systemd les ouvrent et pas lui.
"systemd: If a socket is enabled in systemd but not in Dovecot config, close it." http://hg.dovecot.org/dovecot-2.1/rev/4a3bf567da54
