Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :Le 25/10/2016 15:48, JKB a écrit :Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :Le 20/10/2016 14:54, Nicolas George a écrit :Michel Talon , dans le message <5808b7c4$0$7125$ fr>,
a écrit :Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.A partir du
moment où un certain nombre de logiciels d'usage courant (exe mple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donât have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of sup port
time, they decided it is much easier to just require systemd/login d.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire t out ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirect e, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatiqu e si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seu l. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça co mplètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab dâaille urs
désoler mais la plupart du temps ont préfère attendre l a version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
Le Tue, 25 Oct 2016 16:37:14 +0200,
remy <remy@fctpas.fr> écrivait :
Le 25/10/2016 15:48, JKB a écrit :
Le Tue, 25 Oct 2016 15:28:58 +0200,
remy <remy@fctpas.fr> écrivait :
Le 20/10/2016 14:54, Nicolas George a écrit :
Michel Talon , dans le message <5808b7c4$0$7125$426a34cc@news.free. fr>,
a écrit :
Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exe mple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donât have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of sup port
time, they decided it is much easier to just require systemd/login d.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire t out ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirect e, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatiqu e si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seu l. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça co mplètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab dâaille urs
désoler mais la plupart du temps ont préfère attendre l a version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :Le 25/10/2016 15:48, JKB a écrit :Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :Le 20/10/2016 14:54, Nicolas George a écrit :Michel Talon , dans le message <5808b7c4$0$7125$ fr>,
a écrit :Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.A partir du
moment où un certain nombre de logiciels d'usage courant (exe mple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donât have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of sup port
time, they decided it is much easier to just require systemd/login d.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire t out ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirect e, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatiqu e si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seu l. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça co mplètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab dâaille urs
désoler mais la plupart du temps ont préfère attendre l a version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
Le 25/10/2016 16:48, JKB a écrit :Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :Le 25/10/2016 15:48, JKB a écrit :Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :Le 20/10/2016 14:54, Nicolas George a écrit :Michel Talon , dans le message <5808b7c4$0$7125$,
a écrit :Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Le 25/10/2016 16:48, JKB a écrit :
Le Tue, 25 Oct 2016 16:37:14 +0200,
remy <remy@fctpas.fr> écrivait :
Le 25/10/2016 15:48, JKB a écrit :
Le Tue, 25 Oct 2016 15:28:58 +0200,
remy <remy@fctpas.fr> écrivait :
Le 20/10/2016 14:54, Nicolas George a écrit :
Michel Talon , dans le message <5808b7c4$0$7125$426a34cc@news.free.fr>,
a écrit :
Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Le 25/10/2016 16:48, JKB a écrit :Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :Le 25/10/2016 15:48, JKB a écrit :Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :Le 20/10/2016 14:54, Nicolas George a écrit :Michel Talon , dans le message <5808b7c4$0$7125$,
a écrit :Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Le Tue, 25 Oct 2016 16:58:16 +0200,
remy écrivait :Le 25/10/2016 16:48, JKB a écrit :Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :Le 25/10/2016 15:48, JKB a écrit :Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :Le 20/10/2016 14:54, Nicolas George a écrit :Michel Talon , dans le message <5808b7c4$0$7125$ e.fr>,
a écrit :Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.A partir du
moment où un certain nombre de logiciels d'usage courant (e xemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donâ t have time to
develop missing functionality in OpenRC 3) supporting non-system d +
systemd at the same time likely resulting in bugs and a lot of s upport
time, they decided it is much easier to just require systemd/log ind.
This also get the features that systemd and logind offer and avo id any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indire cte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automati que si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout s eul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corrig er
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab dâail leurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Relis-moi bien attentivement. Je ne te répondrai pas avant que ai es
lu et compris.
Au fait, le chiffrement, ça en est où ?
JKB
Le Tue, 25 Oct 2016 16:58:16 +0200,
remy <remy@fctpas.fr> écrivait :
Le 25/10/2016 16:48, JKB a écrit :
Le Tue, 25 Oct 2016 16:37:14 +0200,
remy <remy@fctpas.fr> écrivait :
Le 25/10/2016 15:48, JKB a écrit :
Le Tue, 25 Oct 2016 15:28:58 +0200,
remy <remy@fctpas.fr> écrivait :
Le 20/10/2016 14:54, Nicolas George a écrit :
Michel Talon , dans le message <5808b7c4$0$7125$426a34cc@news.fre e.fr>,
a écrit :
Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (e xemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donâ t have time to
develop missing functionality in OpenRC 3) supporting non-system d +
systemd at the same time likely resulting in bugs and a lot of s upport
time, they decided it is much easier to just require systemd/log ind.
This also get the features that systemd and logind offer and avo id any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indire cte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automati que si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout s eul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corrig er
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab dâail leurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Relis-moi bien attentivement. Je ne te répondrai pas avant que ai es
lu et compris.
Au fait, le chiffrement, ça en est où ?
JKB
Le Tue, 25 Oct 2016 16:58:16 +0200,
remy écrivait :Le 25/10/2016 16:48, JKB a écrit :Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :Le 25/10/2016 15:48, JKB a écrit :Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :Le 20/10/2016 14:54, Nicolas George a écrit :Michel Talon , dans le message <5808b7c4$0$7125$ e.fr>,
a écrit :Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.A partir du
moment où un certain nombre de logiciels d'usage courant (e xemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donâ t have time to
develop missing functionality in OpenRC 3) supporting non-system d +
systemd at the same time likely resulting in bugs and a lot of s upport
time, they decided it is much easier to just require systemd/log ind.
This also get the features that systemd and logind offer and avo id any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indire cte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automati que si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout s eul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corrig er
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab dâail leurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Relis-moi bien attentivement. Je ne te répondrai pas avant que ai es
lu et compris.
Au fait, le chiffrement, ça en est où ?
JKB
Le 25/10/2016 17:04, JKB a écrit :Le Tue, 25 Oct 2016 16:58:16 +0200,
remy écrivait :Le 25/10/2016 16:48, JKB a écrit :Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :Le 25/10/2016 15:48, JKB a écrit :Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :Le 20/10/2016 14:54, Nicolas George a écrit :Michel Talon , dans le message <5808b7c4$0$7125$,
a écrit :Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Relis-moi bien attentivement. Je ne te répondrai pas avant que aies
lu et compris.
Au fait, le chiffrement, ça en est où ?
il faut que je mette en musique ma relation voir
http://remyaumeunier.chez-alice.fr/pdf/cryptoasymetrique.pdf
et je recherche une éventuelle antériorité si elle existe
j'ai pas trouver grand chose voir carrément rien
sinon j'avais un truc mais j'ai pas réussie a le simplifier assez pour
que cela soit compris cetait a partir des equations diophantine et de
l’unicité de la parti décimal des racine ieme dans tout les cas ses pas
très grave
Le 25/10/2016 17:04, JKB a écrit :
Le Tue, 25 Oct 2016 16:58:16 +0200,
remy <remy@fctpas.fr> écrivait :
Le 25/10/2016 16:48, JKB a écrit :
Le Tue, 25 Oct 2016 16:37:14 +0200,
remy <remy@fctpas.fr> écrivait :
Le 25/10/2016 15:48, JKB a écrit :
Le Tue, 25 Oct 2016 15:28:58 +0200,
remy <remy@fctpas.fr> écrivait :
Le 20/10/2016 14:54, Nicolas George a écrit :
Michel Talon , dans le message <5808b7c4$0$7125$426a34cc@news.free.fr>,
a écrit :
Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Relis-moi bien attentivement. Je ne te répondrai pas avant que aies
lu et compris.
Au fait, le chiffrement, ça en est où ?
il faut que je mette en musique ma relation voir
http://remyaumeunier.chez-alice.fr/pdf/cryptoasymetrique.pdf
et je recherche une éventuelle antériorité si elle existe
j'ai pas trouver grand chose voir carrément rien
sinon j'avais un truc mais j'ai pas réussie a le simplifier assez pour
que cela soit compris cetait a partir des equations diophantine et de
l’unicité de la parti décimal des racine ieme dans tout les cas ses pas
très grave
Le 25/10/2016 17:04, JKB a écrit :Le Tue, 25 Oct 2016 16:58:16 +0200,
remy écrivait :Le 25/10/2016 16:48, JKB a écrit :Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :Le 25/10/2016 15:48, JKB a écrit :Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :Le 20/10/2016 14:54, Nicolas George a écrit :Michel Talon , dans le message <5808b7c4$0$7125$,
a écrit :Pourtant l'objection de la pieuvre est absolument évidente.
En effet, la mauvaise foi est absolument évidente.A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).
Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.
tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe
Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière
Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
tu ne comprend pas quoi dans " bouzin pas stable mais indispensable"
remy
Relis-moi bien attentivement. Je ne te répondrai pas avant que aies
lu et compris.
Au fait, le chiffrement, ça en est où ?
il faut que je mette en musique ma relation voir
http://remyaumeunier.chez-alice.fr/pdf/cryptoasymetrique.pdf
et je recherche une éventuelle antériorité si elle existe
j'ai pas trouver grand chose voir carrément rien
sinon j'avais un truc mais j'ai pas réussie a le simplifier assez pour
que cela soit compris cetait a partir des equations diophantine et de
l’unicité de la parti décimal des racine ieme dans tout les cas ses pas
très grave
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
On 2016-10-25, JKB wrote:Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
On 2016-10-25, JKB <jkb@koenigsberg.invalid> wrote:
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
On 2016-10-25, JKB wrote:Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
Je sais bien. Mais je répondais à rémy en me mettant à son niveau,
hein...
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
Je sais bien. Mais je répondais à rémy en me mettant à son niveau,
hein...
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
Je sais bien. Mais je répondais à rémy en me mettant à son niveau,
hein...
Doug713705 , dans le message <numt0o$rog$, a
écrit :Ça s'appelle créer le besoin.
Tu peux préciser ta pensée ? Tu n'es pas en train de suggérer que les
différentes distributions ont transformé leurs scripts d'init en spaghettis
exprès pour paver la voie pour systemd, par hasard ?
Doug713705 , dans le message <numt0o$rog$1@golgoth99.redatomik.org>, a
écrit :
Ça s'appelle créer le besoin.
Tu peux préciser ta pensée ? Tu n'es pas en train de suggérer que les
différentes distributions ont transformé leurs scripts d'init en spaghettis
exprès pour paver la voie pour systemd, par hasard ?
Doug713705 , dans le message <numt0o$rog$, a
écrit :Ça s'appelle créer le besoin.
Tu peux préciser ta pensée ? Tu n'es pas en train de suggérer que les
différentes distributions ont transformé leurs scripts d'init en spaghettis
exprès pour paver la voie pour systemd, par hasard ?
C'est très exactement ce que je suis en train d'exprimer, c'est évidement
un troll mais l'exemple proposé par Kevin Denis est une démonstration
parfaite de l'abrutissement total de certains dev et aujourd'hui on
vient dire "init est trop complexe et peu fiable, il faut autre chose".
Allo, les gars, c'est *VOUS* qui avez mis la grouille partout dans un
truc qui se voulait simple.
Il y a un moment où il faut savoir se regarder dans la glace est se dire
qu'on s'est trompé. Ça n'a pas l'air évident pour tout le monde...
286 lignes de codes (hors scripts externes) pour démarrer Apache, c'est
juste du grand n'importe quoi qui ne peut *pas* être justifié. C'est
juste de la merde, il n'y a pas d'autre mot possible.
C'est très exactement ce que je suis en train d'exprimer, c'est évidement
un troll mais l'exemple proposé par Kevin Denis est une démonstration
parfaite de l'abrutissement total de certains dev et aujourd'hui on
vient dire "init est trop complexe et peu fiable, il faut autre chose".
Allo, les gars, c'est *VOUS* qui avez mis la grouille partout dans un
truc qui se voulait simple.
Il y a un moment où il faut savoir se regarder dans la glace est se dire
qu'on s'est trompé. Ça n'a pas l'air évident pour tout le monde...
286 lignes de codes (hors scripts externes) pour démarrer Apache, c'est
juste du grand n'importe quoi qui ne peut *pas* être justifié. C'est
juste de la merde, il n'y a pas d'autre mot possible.
C'est très exactement ce que je suis en train d'exprimer, c'est évidement
un troll mais l'exemple proposé par Kevin Denis est une démonstration
parfaite de l'abrutissement total de certains dev et aujourd'hui on
vient dire "init est trop complexe et peu fiable, il faut autre chose".
Allo, les gars, c'est *VOUS* qui avez mis la grouille partout dans un
truc qui se voulait simple.
Il y a un moment où il faut savoir se regarder dans la glace est se dire
qu'on s'est trompé. Ça n'a pas l'air évident pour tout le monde...
286 lignes de codes (hors scripts externes) pour démarrer Apache, c'est
juste du grand n'importe quoi qui ne peut *pas* être justifié. C'est
juste de la merde, il n'y a pas d'autre mot possible.
On 2016-10-25, JKB wrote:Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça c omplètement
idiot. La solution est de trouver pourquoi il explose et de corrige r
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
Je sais bien. Mais je répondais à rémy en me mettant à son niveau,
hein...
Justement, on pourrait expliquer à Rémy que lorsque systemd m onitore des
process de démons et les relance lorsqu'ils plantent, cela va prov oquer
indéniablement une diminution de la qualité des programmes so us Linux
(puisque ça se relance tout seul, pourquoi les faire stables), mai s que
lorsqu'un système de monitoring (type Nagios) relance un process a près
avoir levé une alerte, envoyé un email et un sms à un ad ministrateur
système, il s'agit alors d'assurer une continuité du service tout en
prévenant les personnes concernées de prendre action afin que le
problème ne se représente pas.
Monitorer avec cron est une stupidité, mais un poil moins qu'avec
systemd, parce qu'un daemon peut planter à l'occasion sans que
l'administrateur ai la possibilité d'y changer quoi que ce soit (c as non
reproductible, code proprio ...), cron apporte alors une réactivit é que
Nagios n'a pas et peut rendre service si on reste dans un contexte
d'exception et non de règle.
Rémy, t'as compris ?
On 2016-10-25, JKB <jkb@koenigsberg.invalid> wrote:
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça c omplètement
idiot. La solution est de trouver pourquoi il explose et de corrige r
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
Je sais bien. Mais je répondais à rémy en me mettant à son niveau,
hein...
Justement, on pourrait expliquer à Rémy que lorsque systemd m onitore des
process de démons et les relance lorsqu'ils plantent, cela va prov oquer
indéniablement une diminution de la qualité des programmes so us Linux
(puisque ça se relance tout seul, pourquoi les faire stables), mai s que
lorsqu'un système de monitoring (type Nagios) relance un process a près
avoir levé une alerte, envoyé un email et un sms à un ad ministrateur
système, il s'agit alors d'assurer une continuité du service tout en
prévenant les personnes concernées de prendre action afin que le
problème ne se représente pas.
Monitorer avec cron est une stupidité, mais un poil moins qu'avec
systemd, parce qu'un daemon peut planter à l'occasion sans que
l'administrateur ai la possibilité d'y changer quoi que ce soit (c as non
reproductible, code proprio ...), cron apporte alors une réactivit é que
Nagios n'a pas et peut rendre service si on reste dans un contexte
d'exception et non de règle.
Rémy, t'as compris ?
On 2016-10-25, JKB wrote:Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça c omplètement
idiot. La solution est de trouver pourquoi il explose et de corrige r
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
Oui, enfin il y a des systèmes de monitoring aussi.
Je sais bien. Mais je répondais à rémy en me mettant à son niveau,
hein...
Justement, on pourrait expliquer à Rémy que lorsque systemd m onitore des
process de démons et les relance lorsqu'ils plantent, cela va prov oquer
indéniablement une diminution de la qualité des programmes so us Linux
(puisque ça se relance tout seul, pourquoi les faire stables), mai s que
lorsqu'un système de monitoring (type Nagios) relance un process a près
avoir levé une alerte, envoyé un email et un sms à un ad ministrateur
système, il s'agit alors d'assurer une continuité du service tout en
prévenant les personnes concernées de prendre action afin que le
problème ne se représente pas.
Monitorer avec cron est une stupidité, mais un poil moins qu'avec
systemd, parce qu'un daemon peut planter à l'occasion sans que
l'administrateur ai la possibilité d'y changer quoi que ce soit (c as non
reproductible, code proprio ...), cron apporte alors une réactivit é que
Nagios n'a pas et peut rendre service si on reste dans un contexte
d'exception et non de règle.
Rémy, t'as compris ?
