Bref récapitulatif
Présents: ailouros, anti, bar, cervantes, Complication, frosk, jmg, jrandom, modulus, polecat, reliver, Sonium, tethra
Journal de réunion
15:15 <jrandom> 0) salut 15:15 <jrandom> 1) État du réseau / 0.6.1.5 15:15 <jrandom> 2) Mises à jour de Syndie 15:15 <jrandom> 3) I2Phex 15:15 <jrandom> 4) I2P-Rufus 15:15 <jrandom> 5) Outil de suivi des bugs 15:15 <jrandom> 6) Clés dynamiques 15:15 <jrandom> 7) ??? 15:15 <jrandom> 0) salut 15:15 * jrandom fait signe de la main 15:16 <jrandom> notes d'état hebdomadaires publiées sur @ http://dev.i2p.net/pipermail/i2p/2005-November/001210.html 15:17 <+bar> yalla! *tire quelques coups en l'air* 15:17 * jrandom se baisse et se met à couvert, et enchaîne sur 1) État du réseau / 0.6.1.5 15:18 <jrandom> comme mentionné dans le mail, il y a eu beaucoup de progrès, et il devrait y avoir une nouvelle version plus tard ce soir 15:18 * jrandom aurait publié plus tôt, mais j'ai dormi tard et je ne voulais pas que tout le monde mette à jour /pendant/ la réunion :) 15:20 <jrandom> quelqu'un a des questions/commentaires/préoccupations à propos de 1) état du réseau / 0.6.1.5 ? 15:20 <+fox> <ailouros> est-ce que « merci de continuer ce bon travail » est un commentaire acceptable ? 15:20 <jrandom> :) merci 15:22 <jrandom> Je suis plutôt content de la stabilité ces derniers temps. Avec un peu de chance, la prochaine version améliorera le débit au-delà de 4–8 Ko/s/par flux. J'ai fait pas mal de tests en local, mais il faut voir ce que ça donne dans la nature 15:22 <tethra> je seconde le commentaire d'ailouros et, en plus, je propose un toast : 15:22 <jrandom> nous avons aussi reçu d'autres retours positifs d'utilisateurs sur des connexions commutées (dial-up) 15:22 <tethra> à jrandom, et à i2p! woot! 15:22 <tethra> <3 15:23 <jrandom> w3wt. ok, s'il n'y a rien d'autre, passons à 2) Mises à jour de Syndie 15:24 <jrandom> beaucoup de progrès sur ce front, mais il vaudra peut-être mieux en discuter après la sortie, quand les gens pourront l'essayer eux-mêmes 15:25 <jrandom> avec un peu de chance, les infos sur @ http://syndiemedia.i2p.net/about.html (le premier lien) expliquent pourquoi ça vaut la peine de l'essayer :) 15:25 <+fox> <ailouros> allez, d'abord tu ne le publies pas, puis tu dis « essayez d'abord »... c'est juste pour nous faire saliver ! :D 15:25 <jrandom> :) 15:26 <jrandom> ok ok, passons directement à 3) I2Phex, comme ça vous pourrez poster vos impressions sur Syndie dans Syndie lui-même après la mise à niveau ;) 15:27 <jrandom> il y aura une annonce pour I2Phex 0.1.1.36 plus tard ce soir 15:28 <jrandom> le seul changement est la correction du pop-up agaçant « Please insert a disk » 15:28 <tethra> ça veut dire que je peux retirer le disque du lecteur sans qu'il me hurle dessus, alors ? ;) 15:28 <jrandom> heh oui 15:28 <tethra> :D 15:30 <jrandom> ok, s'il n'y a rien de plus sur 3) I2Phex, passons à 4) I2P-Rufus 15:30 <tethra> quels sont les plans pour i2phex, tant qu'on y est ? 15:30 <jrandom> ah 15:30 <jrandom> il y a une liste de demandes de fonctionnalités postées sur le forum 15:31 <jrandom> je n'ai rien entendu de redzara au sujet de la fusion du code avec Phex, mais Gregor travaille toujours à abstraire la partie réseau pour que l'on puisse rester synchronisés plus facilement 15:32 <jrandom> en général, l'appli semble fonctionnelle, mais le support de gwebcache serait Vraiment Bien, pour qu'I2Phex fonctionne dès l'installation sans avoir besoin de récupérer des fichiers ou des clés 15:32 <jrandom> je ne connais personne qui travaille à (ré)intégrer le support gwebcache dans I2Phex, mais si quelqu'un connaît Java, ce serait Vraiment Utile 15:33 <tethra> cool. 15:33 <+fox> <reliver> peut-être _007pig ? 15:33 <+fox> <ailouros> désolé de demander, mais le réseau gnutella n'est-il pas celui qui s'est noyé sous son propre flood il y a quelque temps ? 15:33 <tethra> les nouveaux ont tendance à être un peu confus au début 15:33 <+fox> <reliver> tu n'as pas donné suite à son offre d'aide, hier, jrandom 15:33 <jrandom> _007pig regardait du côté du travail de traduction, mais toute aide serait bienvenue. Phex lui-même a le support gwebcache, mais sirup l'a désactivé 15:34 <jrandom> ailouros: gnutella existe toujours, mais oui, ce n'est pas idéal. 15:34 <tethra> quelqu'un envisage de changer le protocole utilisé par i2phex pour autre chose ? 15:35 <jrandom> j'hésite à exiger que les gens travaillent sur des projets précis, donc je préfère suggérer quelques domaines différents à explorer 15:35 <jrandom> tethra: personne à ma connaissance 15:35 <+fox> <ailouros> eh bien, je crois que je préfèrerais voir Localhost (modification d'azureus) sur i2p alors 15:36 <tethra> bittorrent n'est-il pas plus pénible que gnutella ? 15:36 <tethra> en termes de seed et tout ça 15:36 <jrandom> ailouros: tout ce que les gens implémentent et maintiennent est bon :) 15:36 <+fox> <ailouros> je ne sais pas, je n'ai pas utilisé gnutella depuis... 6 ans je crois 15:37 <anti> c'est sûrement plus efficace et un meilleur test de la vraie scalabilité ? 15:37 <+fox> <ailouros> oui c'est un bon critère :D 15:37 <jrandom> i2phex marche plutôt bien, j'ai transféré beaucoup de données avec et trouvé du contenu sympa 15:37 <@cervantes> (pr0n poney) 15:37 <+fox> <ailouros> lol 15:37 <tethra> hahah 15:37 <jrandom> il y a peut-être de meilleures façons de faire, mais quelque chose qui fonctionne vaut mieux que quelque chose qui n'existe pas 15:37 <tethra> cervantes++ 15:37 <tethra> ;) 15:38 <tethra> on n'a jamais dit plus vrai. 15:39 <anti> bon point 15:39 <@cervantes> oups... jr s'est vexé et est parti dîner tôt 15:39 <@cervantes> (désolé) 15:39 <anti> non, il est probablement en train de chercher ce pr0n poney (mythique). ;) 15:40 <jrandom> *tousse* ;) 15:40 <tethra> lol 15:40 <tethra> heheh ;) 15:40 <jrandom> ok, s'il n'y a rien d'autre sur le 3), passons au 4) I2P-Rufus 15:40 <+fox> <reliver> je veux du pr0n poney volant :-) 15:40 <jrandom> Rawn / defnax : quelque chose à ajouter à ce qui a été posté sur le forum ? 15:41 <@cervantes> on dirait que de bons progrès sont en cours 15:41 <jrandom> ouais 15:45 <jrandom> ok, s'il n'y a rien là-dessus, passons à 5) outil de suivi des bugs 15:45 <jrandom> le forum est un peu lourd pour gérer les bugs et les demandes de fonctionnalités, et bugzilla est un peu une bête... 15:46 <@frosk> il n'y a pas déjà un bugzilla quelque part ? 15:46 <jrandom> j'ai posté quelques exigences générales, et cervantes a proposé une solution viable 15:46 <jrandom> non, le bugzilla était sur l'ancien hébergeur (@johnscompanies) avant qu'on migre chez sago 15:46 <+fox> <ailouros> et NNTP ? mieux que les forums, généralement avec fils de discussion... 15:46 <+fox> <reliver> étrange que bugzilla soit si limité, vu l'immense communauté open source qui l'utilise ... 15:46 <+fox> <ailouros> comment* 15:46 <@frosk> ah ok 15:47 <jrandom> nntp a du potentiel, mais utiliser Syndie présente quelques avantages par rapport à ça (filtrage simple par tag) : http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004& 15:48 <jrandom> mais nntp a l'avantage d'avoir des décennies de tests en conditions réelles 15:48 <+fox> <ailouros> un lecteur NNTP filtre par mot-clé (les tags entre []) ? :D 15:49 <@modulus> peut-être pas tant de tests ces derniers temps ? 15:49 <+fox> <reliver> y compris spam et flames ... 15:49 <jrandom> on voudrait quelque chose accessible via le web toutefois, puisque la plupart des gens n'utilisent pas de lecteurs nntp 15:49 <+fox> <ailouros> je dis que Thunderbird est bien dans ce sens, et tu peux partager enigmail entre i2mail et i2nntp 15:49 <@modulus> peut-être un lecteur nntp accessible par le web ? 15:49 <+fox> <reliver> les passerelles sont courantes 15:49 <jrandom> hmm modulus ? 15:50 <@modulus> eh bien, usenet n'est plus tellement utilisé je pense 15:50 <jrandom> oui, donc il nous faudrait un serveur nntp et une passerelle avec support du filtrage 15:50 <@frosk> j'aime bien l'idée de cervantes quand même 15:50 <+fox> <ailouros> (et je dis aussi que si les gens n'utilisent pas de lecteurs NNTP, c'est parce que les forums sont tellement plus jolis et tellement plus lourds) 15:50 <@modulus> hmm, passerelle avec support du filtrage ? de quoi parlez-vous, ça aiderait de savoir. :-) 15:51 <@modulus> à mon avis les forums c'est nul, je déteste ces putains de forums, c'est inutilisable ;-( 15:51 <+fox> <ailouros> LOL je suppose qu'il veut l'accès depuis l'InterNEt 15:51 <+fox> * ailouros est d'accord avec modulus 15:51 <@frosk> modulus : tellement vrai 15:51 <jrandom> heh modulus ;) on discute de http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003& 15:51 <+fox> <ailouros> aieee l'URI longue d'un mégaoctet 15:52 <@modulus> ce que j'adore avec les URLs de Syndie, c'est à quel point elles sont mémorables et simples à taper 15:52 <jrandom> j'aime toujours http://syndiemedia.i2p.net:8000/threads.jsp?post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004& 15:52 <jrandom> heh 15:52 <jrandom> bon, allez sur http://syndiemedia.i2p.net/threads.jsp puis cliquez sur le lien « Issue tracking software » :) 15:53 <@frosk> signalement de bugs directement depuis ta console de router 15:53 <@modulus> hmm, suivi de bugs. 15:53 <jrandom> utiliser Syndie nous donnerait 1) intégration avec l'environnement de chaque utilisateur I2P 2) filtrage trivial 3) fils de discussion 4) gestion du spam (via ignorer/favoris) 5) faire chauffer Syndie :) 15:54 <+fox> <reliver> ça a l'air super :-) 15:54 <+fox> <ailouros> ça l'est 15:54 <jrandom> aye c'est une très bonne fonctionnalité, frosk... on pourrait même avoir des formulaires HTML spécialisés pour poster vers /syndie/post.jsp 15:54 <+fox> <ailouros> et au fait, il n'était pas question de baser Syndie sur NNTP ? :D :D :D 15:54 <@modulus> hmm, et les outils de bugs Debian ? ils sont bien je trouve, le mailbug 15:54 <anti-> on ne peut pas critiquer ce qui marche déjà ! 15:55 <@cervantes> je pense que vous devriez le faire uniquement dans une optique de démo technique 15:55 <jrandom> utiliser NNTP pour distribuer les billets Syndie, oui. pour l'instant on utilise juste une syndication ad hoc, mais d'autres améliorations seraient les bienvenues 15:56 <@cervantes> pas de meilleure façon de démontrer Syndie qu'avec des cas d'usage réels 15:56 <jrandom> c'est assez vrai 15:56 <jrandom> ok, on peut peut-être prévoir de sortir ça dans la version 0.6.1.6 15:56 <+fox> <reliver> ce que je n'aime pas avec les forums, c'est que la barrière à l'entrée est faible 15:57 <+fox> <reliver> donc il y a plein de distractions qui les encombrent. 15:57 <@modulus> je ne sais pas, ce truc Syndie... je n'aime pas trop pour l'instant, mais je m'y ferai peut-être. 15:57 <+fox> <reliver> et on ne peut travailler avec que en ligne 15:57 <jrandom> modulus : as-tu lu le billet lié depuis http://syndiemedia.i2p.net/about.html ? 15:57 <@modulus> reliver : une forte barrière à l'entrée est mauvaise pour les rapports de bug cependant, les gens te rendent déjà un grand service en prenant la peine de signaler en un sens. 15:57 <+fox> <ailouros> ce n'est pas une faible barrière à l'entrée : la bande passante, par exemple. Ils ont un niveau de bruit élevé, donc tu peux utiliser [font=54]HELLO WORLD![/font] et embêter un grand nombre de personnes en un rien de temps 15:57 <jrandom> d'accord modulus 15:58 <+fox> <ailouros> ah oui et il faut effectivement être en ligne 15:58 <jrandom> heh ailouros, c'est quelque chose qu'on doit gérer dans Syndie de toute façon :) 15:58 <@modulus> hmm, probablement pas, jr, laisse-moi vérifier 15:58 <+fox> <ailouros> eh bien, avec Syndie tu peux mettre les utilisateurs en liste noire et tu es pratiquement tranquille 15:58 <jrandom> eh bien, avec Syndie tu peux créer tes rapports de bug hors ligne, puis les syndiquer vers une archive distante plus tard quand tu l'es :) 15:58 <jrandom> exactement, ailouros, en un clic dans la nouvelle version aussi 15:59 <+fox> <ailouros> avec les forums, soit tu espères qu'un admin vienne les tuer, soit tu les gardes 15:59 <anti-> c'est plus uucp que nntp :) 15:59 <@modulus> hmm, quel billet en particulier est lié depuis là ? 15:59 <jrandom> lol *exactement* anti 15:59 <jrandom> modulus : le premier lien « dans Syndie lui-même » 15:59 * cervantes aime l'option « tuer » 16:00 <@modulus> bah, uucp == nntp pour tous les usages pratiques :-) 16:00 <jrandom> anti- : c'est justement l'idée — au fur et à mesure que les gens construisent des mécanismes de transport nouveaux et meilleurs (uucp, nntp, usenetdht, etc.), le contenu peut circuler sans couture 16:00 <+fox> <ailouros> tout ça me rappelle plan9 16:01 <+fox> <reliver> i2p est peut-être spécial, mais d'habitude les systèmes de signalement de bugs sont utilisés comme des pare-feu contre les utilisateurs ... 16:01 <jrandom> utilisés comme des pare-feu contre les utilisateurs ? 16:01 <+fox> <reliver> i2p est peut-être spécial, mais d'habitude les systèmes de signalement de bugs sont utilisés comme des pare-feu contre les utilisateurs ... 16:01 <+fox> <reliver> oui. 16:01 <jrandom> je veux que ce soit vraiment, vraiment facile pour les gens de signaler des bugs 16:01 <+fox> <reliver> mozilla, thunderbird, ubuntu ne sont que des exemples 16:02 <+fox> <reliver> ok, super :-) 16:02 <jrandom> mozilla/etc ont cet « agent de feedback » intégré pour soumettre automatiquement des rapports de bug 16:02 <+fox> <reliver> ils ne lisent pas ces rapports de bug 16:02 <jrandom> heh 16:02 <@modulus> hmm, cette intro est ok, le seul problème c'est que je n'aime pas du tout l'interface, je préfère faire les choses de type mail via la métaphore des dossiers plutôt que la méthode web-avec-plein-de-liens-partout 16:02 <@modulus> mais ce n'est que moi 16:02 <jrandom> modulus : peut-être que l'export RSS servirait mieux tes besoins alors ? 16:02 <+fox> <ailouros> je suis d'accord avec modulus (quelqu'un l'avait deviné ? :D ) 16:02 <@cervantes> devoir utiliser pastebin pour montrer des erreurs de console en rebute certains 16:03 <jrandom> ou on peut intégrer susimail, comme l'a suggéré cervantes, pour envoyer des rapports 16:03 <jrandom> (ou pour poster dans Syndie) 16:03 <@modulus> c'est possible, jrandom, je vais regarder. il me faut peut-être un convertisseur RSS-vers-NNTP ou RSS-vers-POP?/IMAP, je vais y réfléchir. 16:05 <@cervantes> modulus : je serai curieux de savoir ce que tu penses de la nouvelle interface i2ptunnel pour la prochaine version d'i2p 16:05 <@cervantes> si c'est mieux ou pire pour toi en termes d'ergonomie 16:05 <@cervantes> (mais je suppose que d'habitude tu édites juste les fichiers de config ?) 16:07 <jrandom> ouh oui merde, j'ai oublié tellement de choses dans les notes d'état... 16:08 <+fox> <ailouros> alors dépêchons-nous et passons au point suivant en ligne... c'était le point C, non ? 16:08 * jrandom pense que ça déchire vraiment, mais on aura plus de retours quand les gens l'auront essayé 16:08 <@modulus> cervantes : curieux dans le sens « tu vas te suicider avec un petit couteau dans le cul comme meilleure alternative à son utilisation » ou au contraire ? :-) 16:08 <jrandom> oui, passons au 6), quelqu'un a des idées sur la proposition de Clés dynamiques ? 16:09 <@modulus> cervantes : en fait j'utilise généralement l'interface, même si maintenant je sais que les fichiers de config sont éditables ... :-) 16:09 <+fox> <ailouros> oui, je suis assez sûr que ça fera exploser le nombre de routers supposés connus 16:09 <@cervantes> *zut* :) 16:10 <@modulus> cette clé dynamique, c'est l'idée que les routers reçoivent une nouvelle clé quand ils ont une nouvelle IP, c'est ça ? 16:10 <@cervantes> modulus : juste pour savoir si ça vaut même la peine de s'embêter avec les conneries WAI 16:10 <jrandom> heh c'est vrai, ailouros 16:10 <@cervantes> bref... je m'égare 16:10 <jrandom> exact modulus 16:11 <@modulus> eh bien, ce n'est peut-être pas mauvais que les pairs connus soient en fait des suppositions, plus encore qu'aujourd'hui. 16:11 <+Complication> Eh bien, la seule chose qui me vient à l'esprit à propos des Clés dynamiques... on ne devrait pas changer de clé inutilement (sinon ça fout en l'air le suivi de la performance/fiabilité). 16:11 <+Complication> Mais quand l'IP change (assez rare ?), ça ne ferait peut-être pas de mal. 16:11 <jrandom> exact, Complication. ce n'est pas quelque chose qu'on voudrait par défaut. la plupart des gens ne le voudront *pas* 16:12 <anti-> je ne suis pas sûr de l'impact positif des propositions. 16:12 <jrandom> ça n'offrira pas beaucoup d'amélioration pour l'anonymat non plus, et aucune amélioration contre un adversaire puissant, mais ça pourrait aider contre des adversaires faibles 16:12 <+fox> <ailouros> ça ne révélerait pas aussi quelles nœuds ont une IP fixe et lesquels ne l'ont pas ? 16:13 * cervantes a la même clé depuis près de 2 ans :) 16:13 <+polecat> Eh bien au moins je peux venir ici. 16:13 <jrandom> ailouros : ce ne serait pas utilisé par la plupart des gens. seule une toute petite minorité voudrait l'utiliser 16:13 <+fox> <ailouros> donc, en gros, plus de churn (rotation des pairs) pour un peu de protection contre des adversaires faibles ? 16:13 <jrandom> c'est ça, ailouros 16:13 <+fox> <ailouros> oh ok 16:14 <+fox> <ailouros> y a-t-il un moyen de mesurer l'impact sur les performances de cette fonctionnalité une fois dans la nature ? 16:14 <@modulus> ça aiderait, je pense, contre une attaque d'intersection nœud-destination ? 16:14 <+polecat> Je me demande toujours pourquoi je bascule entre OK et OK(NAT), déroutant... 16:14 <jrandom> modulus : seulement contre un adversaire faible 16:14 <+fox> <ailouros> polecat ne t'inquiète pas, je bascule entre 15 h d'uptime et 0 h d'uptime :| 16:14 <jrandom> ailouros : pas sûr, bien que stats.i2p suggère qu'on peut gérer le churn 16:15 <jrandom> polecat : hmm, ça veut dire qu'il y a probablement un peu de filtrage en cours 16:15 <@modulus> à mon avis l'attaque d'intersection nœud-destination est l'attaque la plus sérieuse et probablement faisable pour le moment ? en dehors du fait que nous sommes trop peu, je veux dire. 16:15 <@modulus> donc je pense que tout ce qui aide dans ce sens est probablement une bonne idée 16:16 <+polecat> Je peux envoyer des paquets UDP à travers mon router sur ce port, pas de problème depuis des shells distants. Aucune idée, peut-être qu'i2p détecte le NAT et pense à tort qu'il n'est pas redirigé. 16:16 <+fox> <ailouros> je suis d'accord pour la « bonne idée » tant que le churn ne cause pas une forte dégradation des performances 16:16 <anti-> quand le réseau sera plus grand, il y aura de toute façon plein de churn... 16:17 <anti-> *souligne l'attaque DoS évidente qui consiste à changer constamment de clés toutes les quelques minutes 16:17 <anti-> quel impact cela aurait-il ? 16:17 <+fox> <ailouros> DoS contre qui ? :D 16:18 <jrandom> eh, les nouveaux pairs vont dans le niveau « not failing » par défaut, et ne montent dans les niveaux « high capacity » ou « fast » qu'après avoir été là un moment 16:18 <jrandom> donc ça ne fera pas de DoS sur la sélection des pairs 16:18 <anti-> avec un adversaire relativement fort... ça créerait énormément de nœuds apparemment morts/churn de netDb ? 16:18 <+Complication> anti : plus personne ne considérerait ce nœud comme fiable 16:18 <+polecat> anti- : Nous avons une shitlist pour une raison. 16:19 <anti-> *satisfait 16:19 <jrandom> eh bien, les entrées netDb sont supprimées si le pair est injoignable 16:20 <anti-> alors les mêmes problèmes de performance soulevés à propos des clés dynamiques s'appliqueraient ? si les performances ne seraient pas trop impactées par une telle attaque, elles ne seraient pas affectées de manière notable par les clés dynamiques non plus... n'est-ce pas ? 16:20 <+polecat> la confiance incrémentale aide vraiment à gérer les traîtres à déclenchement tardif, pensais-je. 16:20 <+fox> <ailouros> c'est quoi un « traître à déclenchement tardif » ? 16:20 <+polecat> Faire de plus en plus confiance aux gens tant qu'ils continuent à te bénéficier, mais jamais au point qu'ils puissent reprendre plus que ce qu'ils ont donné... 16:20 <anti-> rester des âges, puis tourner Judas. 16:21 <jrandom> oui, les pairs sont rapidement retirés du niveau « fast » s'ils se comportent mal 16:21 <+Complication> je verrais plutôt quelqu'un qui se comporte comme « attendre 300 tunnels participants, puis crasher » 16:21 <+polecat> Oh, j'invente des expressions tout le temps. Oui, une trahison à la Judas, où tu aides sincèrement quelqu'un, puis tu le trahis en espérant encaisser à la dernière minute. 16:21 <anti-> oh non, les tunnels sont cassés *rebuild* 16:21 <jrandom> les pairs promus au niveau « fast » pendant le temps où ils sont retirés devraient alors suffire 16:21 <+fox> * ailouros s'amuse avec ces références bibliques incorrectes :D 16:22 <jmg> en parlant de haute capacité, wow j'obtiens entre 400k et 600K en continu pour le router aujourd'hui. (mais peut-être que tous ces réglages zero hops que j'utilise aident) 16:22 <jrandom> 600 Ko/s?! 16:22 <+polecat> Avec un peu de chance, pendant le temps nécessaire pour atteindre 300 tunnels participants, on t'aura fait transférer assez de données pour que ce ne soit pas grave si tu crashes. 16:22 <jmg> oui 16:22 <+fox> <ailouros> O_O à quoi es-tu connecté ? 16:22 <+Complication> Une telle bande passante, c'est nouveau pour moi :) 16:22 <jrandom> zut, c'est assez rapide pour commencer à heurter nos filtres de Bloom 16:22 <anti-> ailouros : question impolie aux chercheurs en anonymat ;) 16:23 <+polecat> Ça doit être 600 Ko/mn ou ph. 16:23 <+fox> <ailouros> désolé anti- :D mais c'est lui qui a parlé le premier 16:23 <+polecat> puh ! 16:23 <jrandom> j'adorerais récupérer quelques stats de ta page oldstats.jsp. mais content d'entendre que ça tient la charge :) 16:23 <anti-> un jour j'essaierai depuis i2... 16:23 <jrandom> hehe 16:24 <+fox> <ailouros> ça a l'air cool, I2P sur I2 16:24 <jmg> jrandom : je garde des graphes, je vais surveiller de plus près, mais oui je peux confirmer 600 kB/s soutenus pendant 2 minutes, il y a environ 5 minutes 16:24 <+polecat> Quelqu'un a essayé de traverser le pare-feu d'un router D-Link ? Je n'ai absolument aucun succès et mon ami oublie toujours de rediriger le port. 16:24 <jrandom> bien, jmg 16:24 <anti-> polecat : est-ce qu'on fait déjà du hole punching UDP ? j'ai perdu le fil 16:25 <jrandom> anti- : oui, on le fait, sauf pour les NAT symétriques 16:25 <jrandom> polecat : si ton ami a son numéro de modèle, il y a quelques sites en ligne qui indiquent le type de NAT 16:26 <anti-> concernant la trahison tardive... ça pourrait poser problème avec un adversaire puissant ? 16:26 <jmg> jrandom : bien sûr, bittorrent est connu pour violenter cette connexion à 4 Mo/s soutenus, mais j'ai un peu levé le pied là-dessus dernièrement 16:26 <anti-> 24000 nœuds, donc tu en as un qui crashe toutes les 10 secondes environ ? 16:26 <+polecat> NAT symétrique, par opposition à full cone ? 16:26 <jrandom> bien, jmg 16:26 <jrandom> hmm anti- ? 16:26 <jrandom> polecat : ou restricted cone 16:27 <+polecat> Wow, il peut même faire du restricted cone, c'est impressionnant.. 16:27 <anti-> je ne pense pas que la trahison tardive aurait un effet significatif à moins d'être appliquée à une échelle incroyablement massive, auquel cas d'autres attaques auraient plus d'impact ? 16:28 <jrandom> oui, ça ne m'inquiète pas trop, anti-... ça coûterait trop cher, et on peut de toute façon router autour des pannes, donc les dégâts seraient minimes 16:28 <+Complication> La trahison tardive suppose de beaucoup contribuer (afin que d'autres machines se reposent sur la tienne). 16:28 <+fox> <ailouros> échelle incroyablement massive = tu es toutes les netries sur presque tous les routers des autres ? 16:28 <anti-> c'est exactement ce que les anti-p2p font maintenant, mais nous avons des anti-anti-p2p maintenant... 16:29 <+fox> <ailouros> non attends, les anti-p2p envoient de la merde au lieu de bonnes données 16:29 <+fox> <ailouros> ce n'est pas pareil 16:29 <anti-> c'est juste une façon plus rapide de finir en shitlist, donc tu ne serais jamais bien classé. 16:29 <anti-> ça ne marcherait pas du tout contre i2p, je pense. 16:29 <@cervantes> jmg : j'ai déjà eu 4–5 Mo/s via des torrents, mais jamais rien comme 600k sur I2P... tu as aussi du matériel costaud ? 16:29 <+polecat> Je pensais plutôt indépendamment d'i2p à proprement parler. Mon gouvernement fait beaucoup de trahison tardive, même s'ils essaient de garder ça classifié. 16:29 <anti-> mais on leur ferait probablement saigner leur bande passante à sec d'abord ! 16:29 <jrandom> anti- : s'ils sont fiables pendant des jours, ils ne peuvent attaquer qu'une fois pendant moins de 10 minutes 16:30 <jrandom> exactement, anti- :) 16:30 <+polecat> Ou dans le contexte de la banque en ligne. 16:30 <jmg> est-ce que quelqu'un a des instructions simples pour configurer la bibliothèque Native BigInteger pour amd64 ? sinon je me débrouillerai 16:30 <jrandom> heh polecat 16:30 <jrandom> jmg : c'est intégré dans jbigi.jar, mais ça devrait se compiler sur amd64 maintenant 16:30 <jrandom> quoi qu'il en soit, je suppose que ça veut dire qu'on en est maintenant à 6.1) ??? 16:31 <jrandom> quelqu'un a autre chose à soulever ? :) 16:31 <anti-> il te faudrait 20000 machines ou quelque chose comme ça, avec un calendrier de crash tournant, et je pense que les résultats seraient décevants ; tu finirais par contribuer bien plus au réseau que ce que tu lui aurais pris ! 16:31 <jrandom> c'est l'espoir, anti- 16:31 <+fox> <ailouros> eh bien, au pire les gens doivent reseed 16:31 <jmg> oh merci 16:31 <+polecat> processeur 64 bits, 4 Mbit d'upload, on dirait que quelqu'un a de la chance, le salaud. 16:32 <anti-> ou faire tourner une machine normale à la fac... 16:32 <+fox> * ailouros regarde la liste de matériel de sa fac et fronce les sourcils 16:32 <anti-> une fac qui n'achète pas dell ;) 16:33 <+fox> <ailouros> je crois qu'on a quelques dell... d'il y a 5 ans si je me souviens bien 16:33 <+fox> <Sonium> je pense que c'est mauvais : 16:33 <+fox> <Sonium> jvm 1 | java.lang.OutOfMemoryError 16:33 <+fox> <Sonium> jvm 1 | java.lang.OutOfMemoryError 16:33 <+fox> <Sonium> jvm 1 | java.lang.OutOfMemoryError 16:33 <@cervantes> polecat : 4 mégaoctets ;-) 16:33 <jrandom> Sonium : oui, une fois qu'il a un OOM, il mourra vite 16:34 <+fox> <Sonium> et ça aussi : 16:34 <+fox> <Sonium> jvm 1 | 21:21:44.484 CRIT [ Establisher] sport.udp.EstablishmentManager: Err 16:34 <+fox> <Sonium> ou dans l'establisher 16:34 <jrandom> (les OOM suivants peuvent être ignorés sans risque) 16:34 <jrandom> une fois qu'il a un seul OOM, tu peux ignorer toutes les erreurs suivantes 16:34 <+fox> <ailouros> oui mais tu ne devrais pas avoir le premier OOM :D 16:34 <jmg> polecat : la latence ici sur la station spatiale russe est phénoménale par contre.. 16:34 <jrandom> vrai, ailouros 16:35 <+fox> <ailouros> oh, au fait... mon router se fait watchdogger assez souvent 16:35 <jrandom> hrm, forte utilisation CPU ? 16:35 <+fox> <ailouros> je suppose que c'est juste mon installation malchanceuse ? 16:35 <+fox> <ailouros> pas que je sache, la machine est plutôt peu chargée 16:36 <+fox> <ailouros> mais je suppose que c'est ce à quoi je dois m'attendre d'une JVM buguée sur une couche d'émulation linux un peu buggée 16:36 <jrandom> quelle JVM utilises-tu, et quel OS ? 16:36 <+fox> <Sonium> moi ? 16:36 <+fox> <ailouros> Sun's Java(tm) 2 Standard Edition, JRE 5.0 Update 5 on NetBSD/i386 2.0.2 16:37 <jrandom> ahhh oui, je n'ai fait aucun test sur nbsd. fbsd est ok, mais je n'ai pas d'expérience avec nbsd 16:38 <jrandom> ça vaudrait peut-être la peine d'essayer gcj, on pourra peut-être creuser ça après la réunion 16:38 <+fox> <ailouros> ça marche plutôt bien, mais le vrai fun avec ça c'est que parfois (selon quel bit il a basculé en se levant du lit — euh en redémarrant) les fichiers netbsd sont créés avec la permission 540 :D 16:38 <+fox> <Sonium> il y a vraiment un truc qui craint ici 16:38 <+fox> <Sonium> jvm 1 | # Internal Error (53414645504F494E540E4350500175), pid=3500, tid=345 16:38 <+fox> <Sonium> 6 16:39 <+fox> <ailouros> désolé les fichiers netDb sont créés en 540 16:39 <+fox> <Sonium> je pense que je réinstallerai ça plus tard 16:39 <jrandom> Sonium : quel OS utilises-tu ? la JVM a l'air de déconner 16:39 <+fox> <Sonium> winxp 16:39 <jrandom> oui, si tu es en 1.5.0_5, ça vaut peut-être le coup d'essayer 1.4.2_09 16:39 <anti-> je ne pense pas que ce soit le problème d'i2p... 16:40 <jrandom> (1.4.2 a été plus stable pour moi, nécessitant moins de ressources) 16:40 <jrandom> et i2p n'utilise aucune particularité de la 1.5, et nous n'avons pas besoin des améliorations GUI de la 1.5 16:40 <+fox> <Sonium> ce qui est curieux, c'est que ça ne s'est jamais produit avant 16:40 <+polecat> Tu ne peux pas utiliser azureus si tu n'as pas la 1.5 toutefois, meh. 16:40 <+fox> <ailouros> et bien sûr j'utilise *BIEN* azureus :| 16:41 <+fox> <ailouros> mais ce n'est pas un vrai problème... pas trop, je pense... 16:41 <+fox> <ailouros> à moins que ces messages à propos de bob qui est quatrième soient pertinents 16:41 <jrandom> non, on peut les ignorer sans risque 16:41 <anti-> (suis-je le seul que ça agace qu'utorrent et bitcomet ne soient pas open ?) 16:42 <+polecat> :o Maudit sois-tu, bob ! 16:42 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 16:42 <anti-> des muffins ? 16:42 * cervantes peut recommander ibm java 1.4.2 si vous cherchez une meilleure gestion des ressources 16:42 <+polecat> anti- : essaie mlnet. caml -> le langage le plus bizarre du monde, mais ça marche bien. 16:42 <+fox> <ailouros> caml, c'est cool 16:42 <+fox> <ailouros> (si tu peux le lire :D ) 16:42 <@frosk> hé, ne démontes pas caml 16:43 <anti-> prolog mérite une mention là-dedans, tout comme brainf**k et consorts 16:43 <+polecat> caml a une doc horrible. Il m'a fallu une demi-heure pour comprendre que ! est habituellement (parfois) un opérateur de déréférencement. 16:43 <@frosk> je suis payé pour écrire de l'ocaml :) 16:43 <+polecat> jrandom : je ne savais pas que je m'étais incrusté dans une réunion, désolé. 16:44 <jrandom> pas de souci, on se rattrape de nos réunions courtes ;) 16:44 * jrandom se prépare 16:44 * jrandom *baf* clôt la réunion