09:09 < grenoya> feth: malheureusement, comme toutes les machines générant (et datant) des données ne basculent pas en même temps, on est obligé de gérer avec la dernière méthode : on coupe tout, on picole et on ralume les instrument quand on a cuvé :D
09:19 < feth> grenoya: pourquoi ne passez-vous pas en TAI ?
09:19 < feth> vu que UTC ne veut pas se décider à utiliser une mesure intelligente
09:20 < grenoya> feth: passer les OS en TAI ? c'est possible ?
09:24 < feth> grenoya: faut que ça soit supporté par les logiciels malheureusement, en l'état
09:24 < alain_afpy> WARNING !!! YAKAFOKON DETECTED !!!!
09:24 < feth> parce que les patches sur TAI ne semblent pas avoir été acceptés
09:25 < feth> au temps pour moi
09:25 < feth> grenoya: Since Linux kernel version 3.10, the function clock_gettime() now accept CLOCK_TAI.
09:27 < feth> grenoya: ça nécessite un paramètre au boot de linux : tai_offset (sinon, 0)
09:36 < grenoya> le truc c'est qu'il faudrait que tous les projets basculent en même temps (certaines machines servent à tous les projets français) c'est pas impossible, mais assez monstrueux à faire
09:36 < alain_afpy> WARNING !!! YAKAFOKON DETECTED !!!!
09:36 < grenoya> et d'un point de vue force de proposition, je ne suis qu'une crotte d'accarien...
09:37 < grenoya> glyg est pas resté assez longtemps pour que je lui dise que j'ai rien vu passer sur afpy-cd...
09:39 < haypo> feth: est-ce que TAI est le temps sans les secondes intercallaires ? il me semble que tous les serveurs Google utilisent ce temps
09:40 < feth> haypo: il y a plusieurs temps sans secondes intercalaires
09:40 < feth> haypo: et les serveurs google font une bidouille digne d'un centrage de contenu en HTML 4
09:40 < feth> ils étalent la seconde intercalaire
09:40 < feth> c'est la pire idée, du coup ils l'ont choisie
09:42 < haypo> feth: pourquoi la pire ?
09:44 < grenoya> haypo: car toutes les dates sont fausses sur une plage de 6 ou 9h (je sais plus)
09:48 < haypo> grenoya: que veux-tu dire par "fausse" ?
09:49 < grenoya> erronées, inexactes...
09:54 < feth> haypo: ben je sais pas, tes tests de performances, tes mesures physiques, tes datations d'observations astronomiques, ils valent quoi, quand les secondes ne durent pas une seconde ?
09:54 < haypo> feth: tout est question de l'horloge utilisée
09:54 < grenoya> surtout quand tu cherche à être précis à la ms ou la ns...
09:54 < haypo> feth: j'utilise une horloge qui utilise des _secondes_ comme unité
09:55 < feth> haypo: et bien ce que fait google c'est de changer la durée de _tes_ fameuses secondes
09:55 < haypo> feth: time.perf_counter() notamment, cette horloge ne devrait pas être impactée par NTP qui ralentit ou accélère CLOCK_REALTIME
09:55 < feth> tu veux dire que ça se base pas sur l'horloge de la machine ?
09:55 < haypo> feth: de mémoire, sous Linux, perf_counter() est CLOCK_MONOTONIC, sous Windows c'est GetTickCount()
09:56 < haypo> feth: il existe plusieurs horloges dans une seule machine
09:56 < haypo> bon, maintenant j'ai un doute, CLOCK_MONOTONIC peut être ralentit/accéléré par NTP pour que le temps utilise de vraies secondes
09:56 < haypo> je ne sais pas si ça veut dire que les "secondes Google" peuvent être plus longues/courtes que les secondes SI :-)
09:57 < haypo> il existe CLOCK_MONOTONIC_RAW qui ne doit pas être utilisé, et n'est pas affecté par NTP
09:57 < haypo> dans ma mémoire sélective, CLOCK_MONOTONIC est plus fiable que CLOCK_MONOTONIC_RAW, grâce aux ajustements NTP justement
09:57 < feth> Franchement, je vois juste pas du tout pourquoi on a besoin que le décalage entre UTC et le temps local soit un multiple de 3600 secondes
10:06 < grenoya> glyg: salut, j'ai rien vu passer sur afpy-cd hier soir (non pas que j'ai des compétences LDAP pour aider, hein :) )
10:08 < feth> grenoya: glyg: je viens d'approuver le passage de ce message sur la ML
10:09 < grenoya> mici, qu'on oublie pas :)
10:11 < glyg> feth: grenoya: merci !
14:21 < jpcw> bon ben en attendant de patcher afpy_membres
14:21 < jpcw> jj'ai redémarré me slpad et afpy membres
14:21 < jpcw> on avait juste quelques connections tcp qui restent en close_wait
15:00 < feth> jpcw: tu veux dire que ça marche ?
15:00 < feth> et que je devrais écrire au lanceur d'alerte ?
15:12 < jpcw> je ne sais pas, mais je me dis qu'a défaut de fonctionner mieux, ça ne doit pas fonctionner moins bien
15:30 < grenoya> jpcw: oulà malheureux, on sait jamais jusqu'où ça peut fonctionner mal :)
16:32 < jpcw> grenoya: oui, oui mais moi je ne fait pas partie des coaches qui t'expliquent avant de le jouer, comment tu vas perdre le match
16:33 < feth> ça me rappelle une conversation d'hier sur le rugby (j'avais rien pigé)
16:33 < jpcw> bref la méthode Coué, l'effet placebo toussa c'est bien !
16:34 < feth> jpcw: ok, tu vois le dernier mail dans afpy-cd ? tu fais répondre à tous, "OK C BON THXBYE"
16:34 < jpcw> déjà j'ai essayé de réparer
16:34 < jpcw> j'ai réussi à me connecter
16:35 < jpcw> et tu vois le mail que tu m'as montré
16:35 < jpcw> tu fais reply,
16:35 < feth> "vas y tente là"
16:35 < jpcw> thanks pour le retour
16:35 < jpcw> et essayes voir si c'est toujours cassé
16:35 < jpcw> merci toussa
16:37 < feth> j'ai failli écrire "Le président PO Feth"
16:37 < feth> c'est ce que tu mets quand tu as une délégation de signature
16:38 < jpcw> feth: tu veux un accès root sur le nouveau serveur ?
16:38 < jpcw> pour migrer afpy-membres plus vite ?
16:38 < jpcw> ça c'est une délégation, une vraie
16:39 < feth> je peux dénoncer des membres afpy qui parlent LDAP et OID courament dans leur travail
16:46 < jpcw> feth: bah c'est surtout qu'il faut regarder ce que fait le code
16:46 < jpcw> cette semaine j'ai pour objectif de migrer le planet
16:53 < jpcw> Nous sommes actuellement en cours de rénovation (plutôt vers la
16:53 < jpcw> fin) de notre infrastructure
16:53 < feth> je parlais de ce mail-là
16:53 < jpcw> tu es rentré chef de projet dans une SSII ?
16:54 < feth> Je me suis bien amusé à écrire ça :)
17:13 < feth> jpcw: ça fonctionne, donc
17:18 < feth> Je suis surpris que son mail soit pas arrivé sur afpy-cd. Mais bon bref, il y avait une remarque sur le mot de passe en clair et une question sur le stockage du pass en base
17:21 < grenoya> feth: sisi c'est arrivé sur afpy-cd pour moi
17:22 < grenoya> sur le mot de passe en clair je suis d'accord avec le monsieur depuis e début (mais je me suis tue car je sais pas aider là dessus /o\)
17:22 < jpcw> grenoya: de quel mot de passe en clair ?
17:22 < jpcw> sur le ldap c'est chiffré ama
17:24 < feth> grenoya: sans doute parce que je suis en cc: explicite
17:26 < grenoya> jpcw: on reçoit le mdp en clair dans le mail de confirmation de la création de compte (ou celui du changement de mdp...)
17:27 < jpcw> c'est pas glop du tout ça