Réunion des développeurs I2P - 12 avril 2005

14:05 <jrandom> 0) salut 14:05 <jrandom> 1) Statut du réseau 14:05 <jrandom> 2) Statut de SSU 14:05 <jrandom> 3) Profilage bayésien des pairs 14:05 <jrandom> 4) Statut de Q 14:05 <jrandom> 5) ??? 14:05 <hummingbird> 7) Profit 14:06 <jrandom> zut, j'ai fichu en l'air votre ordre du jour :) 14:06 <jrandom> salut 14:06 <jrandom> notes d'état hebdomadaires publiées /avant/ la réunion à http://dev.i2p.net/pipermail/i2p/2005-April/000683.html 14:06 <gott> jrandom: réessaie 14:06 <+cervantes> peu importe, cette réunion est de toute façon partie du mauvais pied 14:06 <jrandom> *tousse* 14:06 <jrandom> on passe à 1) Statut du réseau 14:07 <jrandom> le gros problème que nous observions avec le netDb a été corrigé et confirmé mort dans la nature 14:07 <jrandom> il reste encore quelques soucis, mais dans l'ensemble ça paraît assez raisonnable 14:08 <frosk> une idée de ce qui cause parfois ces dnfs bizarres ? 14:08 <gott> je confirme; je peux obtenir mon porno illégal à des vitesses record sur i2p maintenant. 14:08 <+cervantes> ça risque d'être difficile à cerner 14:08 <jrandom> j'ai comme l'impression que c'est une confusion liée au limiteur sur la construction des tunnels 14:09 <jrandom> retirer ces limiteurs règlera probablement le problème, mais ça pourrait être pénible pour les utilisateurs avec des CPU lents 14:09 <jrandom> d'un autre côté, on pourrait en faire une option, ou quelqu'un pourrait écrire un code de limitation plus intelligent 14:10 <frosk> je vois 14:10 <+cervantes> le limiteur me semble beaucoup plus proactif que dans les versions précédentes sur mon système 14:10 <jrandom> oui, on retarde la construction de tunnels quand il y en a trop en attente - avant on disait juste « ok, il faut construire X tunnels. construisez-les » 14:10 <+cervantes> ne peut-on pas rendre le seuil paramétrable ? 14:11 <jrandom> oui, on peut 14:11 <gott> jrandom: optionnel 14:11 <gott> afin que les utilisateurs avec des thin i2p servents (nœuds hybrides client/serveur légers) puissent rester productifs 14:12 <jrandom> mon attention est ailleurs pour le moment, donc si quelqu'un veut creuser ça, la méthode clé est TunnelPoolManager.allocateBuilds 14:12 <jrandom> (ou si personne ne s'y met, je pourrai ajouter quelques ajustements quand la prochaine build sortira) 14:13 <+cervantes> ........@ <-- tumbleweed 14:13 <jrandom> :) 14:13 <jrandom> quelqu'un a autre chose pour 1) statut du réseau, ou on passe à 2) SSU ? 14:14 * gott marmonne quelque chose à propos de trop de paroles et trop peu d'actions dans la communauté i2p 14:14 <+cervantes> peut-être qu'à l'avenir on pourra introduire des profils de performance dans la console 14:14 <gott> jrandom en fait trop côté développement. 14:14 <+cervantes> afin que les gens puissent choisir un lot prédéfini d'options de config pour des systèmes haut/moyen/bas de gamme 14:15 <jrandom> oh bonne idée cervantes, il y a beaucoup de place pour des variantes. même si on veut s'auto-optimiser au mieux, il est peut-être plus facile pour des humains de le faire 14:15 <+cervantes> puisqu'ils sont nombreux à utiliser des machines peu puissantes et des connexions modem en ce moment 14:15 <gott> cervantes: oui, excellente idée. 14:15 <+cervantes> Je devrais publier ma liste de choses à faire pour fire2pe... il y a plein de trucs de ce genre dedans ;-) 14:16 <gott> basé principalement sur la vitesse du processeur et du réseau ? 14:16 <jrandom> un site avec une liste de tâches pseudonyme serait bien 14:16 <gott> c'est une bonne idée. 14:16 <+cervantes> eh bien le limiteur de bande passante devrait idéalement gérer la vitesse réseau 14:16 <gott> dans le style Google habituel, avoir un tas de 'thin i2p servents' sur votre LAN. 14:17 <+cervantes> jrandom: ugha.i2p? 14:17 <jrandom> peut-être 14:19 <jrandom> ok, autre chose pour 1) statut du réseau ? 14:19 * jrandom nous fait passer à 2) SSU 14:19 <jrandom> Beaucoup de progrès sur le front UDP (SSU == Secure Semireliable UDP) 14:19 <gott> quelqu'un devrait faire un alias de 'i2pwiki.i2p' vers ça 14:20 <+cervantes> je suppose que ça dépend d'ugha ;-) 14:20 <jrandom> l'aperçu général de ce qui se passe est dans l'e-mail, et beaucoup plus de détails techniques (et une jolie image ;) sont sur mon blog 14:21 <+ant> <godmode0> udp c'est sûr ? 14:21 <+ant> <godmode0> comment :) 14:21 <jrandom> http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html <-- comment 14:22 <+ant> <godmode0> hehe 14:22 <+ant> <godmode0> i2p introuvable bonne ip mon ordinateur 14:22 <jrandom> désolé, si vous n'avez pas i2p installé, changez "dev.i2p" en "dev.i2p.net" 14:22 <+ant> <godmode0> ai installé 14:23 <+ant> <godmode0> mais ça marche pas 14:23 <jrandom> ok, on pourra peut-être déboguer ça après la réunion 14:23 <+ant> <godmode0> oups en réunion encore désolé 14:23 <jrandom> hehe pas de souci 14:25 <jrandom> bref, comme je disais, le plan général de la progression est dans l'e-mail 14:25 <jrandom> des questions/commentaires/inquiétudes concernant SSU ? 14:26 <+Ragnarok> le débit/la latence seront-ils très différents du transport TCP ? 14:27 <jrandom> j'espère que la cause des pics de latence sera traitée, mais je ne fais pas de pronostics particuliers. 14:28 <jrandom> si on peut garder la latence dans le même ordre de grandeur qu'aujourd'hui et se débarrasser des pics, on pourra remonter le débit 14:29 <+Ragnarok> cool 14:29 <gott> y aura-t-il une documentation sur l'implémentation fournie sur i2p.net ? 14:30 <jrandom> une bonne partie de mon temps quand je serai hors ligne pour déménager sera consacrée à écrire des docs à mettre sur le site, oui 14:30 <gott> génial \m/ 14:30 <jrandom> nous avons de bonnes docs d'implémentation au niveau du code pour le core et le router, mais pas encore de bonnes docs d'architecture globale du router 14:31 <jrandom> bref, s'il n'y a rien d'autre sur 2) SSU, glissons vers 3) Profilage bayésien des pairs 14:32 <jrandom> nous avons reçu une brève mise à jour de bla plus tôt ce soir, comme indiqué dans les notes d'état 14:32 <+bla> Je suis toujours là quand même... ;) 14:33 <jrandom> bla est peut-être encore là pour nous donner d'autres réflexions ou répondre aux questions - 14:33 <jrandom> ah, te voilà 14:33 <defnax> jrandom : que penses-tu d'annoncer un Tracker bittorrent i2p, pour la sécurité je pense que ce n'est pas bien ou ?, 14:34 <+bla> La discussion IRC citée par jrandom montre l'idée générale. En résumé : 14:34 <jrandom> defnax: peut-être qu'on pourra en discuter davantage en 5) 14:34 <defnax> ok je peux attendre 14:34 <+bla> L'idée finale est d'utiliser à la fois des informations de temps aller-retour (RTT) obtenues à partir de tests de tunnels explicites, et des informations implicites issues de tests de tunnels côté client, dans un seul cadre d'estimation de la vitesse des nœuds 14:35 <+bla> Pour l'instant, je n'utilise que les informations obtenues des tests de tunnels explicites, car pour ces tests, tous les pairs participants sont connus. 14:36 <+bla> Un cadre de classificateur bayésien naïf sera utilisé pour estimer la vitesse d'un pair, étant donnés les tunnels auxquels il a participé (à n'importe quelle position) et la rapidité de ces tunnels 14:36 <+bla> Afin de comparer à une "vérité terrain", j'ai obtenu des vitesses "réelles" des pairs telles que listées dans les notes d'état 14:37 <+bla> Les résultats sont très préliminaires. Mais http://theland.i2p/estspeed.webp montre la corrélation entre les vitesses réelles et les vitesses déduites en utilisant le cadre bayésien 14:37 <+bla> Voilà. Des questions ou commentaires ? 14:38 <jrandom> commentaire : ça semble prometteur. 14:38 <+ant> <BS314159> il semble que la vitesse totale du tunnel constitue une borne inférieure stricte de la vitesse de chaque pair participant 14:38 <+detonate> commentaire : il semble y avoir quelques valeurs aberrantes 14:38 <+ant> <BS314159> est-ce pris en compte ? 14:39 <jrandom> BS314159: vitesse totale du tunnel ? oh, tu veux dire la connexion réseau du nœud de test ? 14:40 <+bla> BS314159: Cela fournit bien une borne inférieure, oui. Ce n'est pas encore traité, mais ça le sera : le cadre bayésien naïf permet de pondérer différemment les échantillons (mesures de RTT). Des RTT très rapides seront pondérés par un facteur plus grand à l'avenir 14:40 <+ant> <BS314159> je veux dire la bande passante totale d'un tunnel donné 14:40 <+bla> BS: Les résultats montrent des mesures de _latence_, pour l'instant 14:40 <+ant> <BS314159> d'accord. 14:41 <+ant> <BS314159> laisse tomber, alors 14:41 <jrandom> ah, oui, bien sûr. des mesures de débit nécessiteront d'autres modifications pour tester avec des messages de tailles différentes 14:41 <jrandom> d'un autre côté, les tests de tunnels implicites sont pilotés par des messages plus gros (typiquement 4KB, puisque c'est la taille de fragmentation de la bibliothèque de streaming) 14:42 <+bla> detonate: Oui, il y a des valeurs aberrantes. Il y en aura toujours _quelques-unes_ (c'est inhérent à l'estimation et à la modélisation en général). Cependant, la séparation entre clients très lents et très rapides (en mettant un seuil autour de 400 ms) est plutôt correcte 14:42 <+detonate> ok 14:43 <+bla> jrandom: En effet. Une fois que j'aurai ça qui marche (je ne suis pas un mordu de Java...), je testerai aussi avec les messages plus gros 14:43 <+bla> detonate: Maintenant, j'aimerais améliorer la séparation entre pairs rapides et très rapides. 14:43 <jrandom> cool, je vais voir si je peux t'envoyer un TestJob modifié pour ça 14:44 <+bla> Je ferai un rapport quand j'aurai de nouveaux résultats. 14:44 <jrandom> génial 14:45 <jrandom> ok cool, quelqu'un d'autre a quelque chose pour 3) Profilage bayésien des pairs ? 14:46 <jrandom> sinon, on passe à 4) Statut de Q 14:46 <jrandom> Comme mentionné dans l'e-mail, la rumeur veut qu'Aum avance sur une nouvelle interface web 14:47 <jrandom> je n'en sais pas beaucoup, ni les détails d'état sur le reste des mises à jour de Q, mais je suis sûr qu'on en saura plus bientôt 14:48 <jrandom> quelqu'un a quelque chose sur Q à évoquer ? ou on fait de cet item un tir rapide et on passe à 5) ??? 14:49 <jrandom> [considérez que c'est fait] 14:49 <jrandom> ok, quelqu'un a autre chose à aborder pour la réunion ? 14:50 <jrandom> defnax: annoncer un tracker i2p aux gens de la communauté i2p serait super. au monde extérieur, ça pourrait être un peu rude, puisque nous n'en sommes pas encore à 0.6 14:50 <gott> Oui. 14:50 <jrandom> (ou 1.0 ;) 14:50 <gott> J'ai quelques infos à propos des efforts de documentation côté utilisateur. 14:51 <+mancom> pour mémoire : sur mancom.i2p il y a une implémentation C# de l'API client de Q (dans sa première incarnation) 14:51 <jrandom> oh cool, vas-y gott 14:51 <jrandom> ah bien joué mancom 14:51 <gott> J'avais écrit auparavant de la documentation côté utilisateur pour i2p 0.4. 14:52 <jrandom> que j'ai malheureusement rendue obsolète en changeant plein de trucs :( 14:52 <gott> Mais elle est complètement obsolète avec l'i2p actuel. 14:52 <gott> En conséquence, je suis très intéressé pour écrire un ensemble de documentation de facto que l'on pourrait soit (a) livrer avec i2p soit (b) rendre accessible via i2p. 14:53 <jrandom> chouette. des docs à livrer avec i2p (localisées dans la langue de l'utilisateur, etc.) seraient super 14:53 <+cervantes> cool 14:53 <gott> Je ne suggère pas de les livrer avec, mais c'est une option possible, car un utilisateur ne peut pas accéder aux eepsites pour lire le manuel s'il ne sait pas utiliser ou configurer i2p ;-) 14:53 <gott> D'accord. 14:53 <gott> Mais est-ce excessif ? 14:53 <+ant> <BS314159> quel programme respectable vient sans pages de man ? 14:53 <+cervantes> et ça vaut la peine d'attendre la 1.0 ? 14:54 <gott> C'est une autre question. 14:54 <jrandom> comme le développement est assez fluide, il vaudrait peut-être mieux se concentrer sur l'aide contextuelle plutôt que sur un guide utilisateur global 14:54 <gott> BS314159: ce ne sont pas des manpages, car ce sera multiplateforme. Probablement HTML. 14:54 <+cervantes> combien de changements structurels d'ici là 14:54 <jrandom> par exemple, ce serait bien d'avoir une meilleure doc décrivant ce que *signifient* les différentes options de config, leurs implications, etc. 14:55 <gott> D'accord, donc je vais écrire une localisation en anglais et en français d'un manuel pour i2p. 14:55 <+jdot> en fait, on pourrait utiliser l'inproxy pour accéder à la documentation même sans i2p installé. 14:55 <gott> Deux grandes questions : 14:55 <jrandom> ces infos pourraient être maintenues à jour du fait d'être *dans* l'interface elle-même 14:55 <+cervantes> oui, de l'aide contextuelle, ce serait top 14:55 <gott> (1) Intégré ou accessible via manual.i2p ? 14:55 <gott> (2) Pour quelle version ? 14:55 <gott> oui 14:55 <jrandom> gott: je ne suis pas sûr qu'il soit judicieux de faire un guide utilisateur pour l'instant 14:55 <gott> c'est une excellente idée 14:56 <gott> tu veux dire utiliser la fonction de mise à jour automatique pour mettre à jour le manuel utilisateur ? 14:56 <gott> jrandom: d'accord 14:56 <gott> mais alors comment suggères-tu l'aide contextuelle ? 14:56 <jrandom> oh, on peut certainement déployer des mises à jour de la doc via le processus de mise à jour 14:56 <+cervantes> si/quand ce sera le moment de faire un manuel, alors peut-être qu'un manual.war pourra être déposé dans le dossier webapps de l'utilisateur s'il veut un accès local à la doc 14:57 <gott> Je pense à un manuel utilisateur. 14:57 <gott> ou un HOWTO. 14:57 <gott> Je ne vois pas ce que tu entends par aide contextuelle. 14:57 <gott> c'est assez simple. 14:57 <jrandom> gott: par exemple, un ensemble d'infos lisibles par des humains (non-ultrag33ks) expliquant ce que veulent dire les trucs sur /config.jsp. ces infos iraient *sur* /config.jsp, ou sur une page html accessible depuis cette config.jsp 14:58 <jrandom> un manuel utilisateur ou un howto serait super, mais pas avant 1.0 14:59 <jrandom> il y a déjà du travail dans ce sens sur le forum @ http://forum.i2p.net/viewtopic.php?t=385 14:59 <gott> jrandom: oui. 14:59 <gott> eh bien. 14:59 <gott> les infos sur config.jsp sont déjà assez simples 15:00 <jrandom> d'un autre côté, on voit ici tout le temps des questions sur ce que font réellement les limites de bande passante, comment fonctionnent les taux de burst, etc. ce serait bien d'avoir les réponses sur la page, plutôt que d'avoir des gens qui demandent 15:00 <gott> hé 15:00 <jrandom> gott: c'est simple pour toi parce que tu utilises i2p depuis presque deux ans 15:00 <gott> peu importe, 'configtunnels.jsp' pourrait être améliorée. 15:00 <gott> d'accord. 15:00 <+cervantes> simple pour les initiés, peut-être, un n00b serait perdu 15:01 <gott> voici donc une sélection de tâches plus à jour : 15:01 <+cervantes> pas sûr de la meilleure façon de présenter l'aide du point de vue de l'interface 15:01 <gott> (1) Aide contextuelle sur les pages web localisée dans la langue de l'utilisateur. Une variable de configuration peut être définie pour la langue de l'interface, par défaut chargée depuis la variable d'environnement $LANG sous linux 15:02 <gott> Je ne sais pas comment Java détermine la locale par défaut sous Windows. 15:02 <gott> Mais c'est un bon début pour la localisation et la rédaction de documentation. 15:03 <gott> (2) Pour la version 1.0, un HOWTO _accessible_ via i2p 15:03 <gott> Je ne suggère pas d'inclure le HOWTO, car ce serait exagéré. Ce serait bien de garder i2p aussi petit que possible, hein ? 15:03 <jrandom> mec, c'est du HTML. c'est minuscule. même si c'est énorme, HTML compresse *vraiment* bien 15:03 <jrandom> avoir un manuel local serait largement préférable 15:03 <jrandom> d'autant qu'on peut pousser des mises à jour 15:03 * gott hausse les épaules 15:04 <gott> Je suppose. 15:04 <gott> Je trouve ça juste un peu bête. 15:04 <gott> quand on peut juste le télécharger via le web. 15:04 <gott> mais d'un autre côté, si l'utilisateur ne parvient pas à comprendre comment utiliser i2p 15:04 <gott> il ne peut pas. 15:04 <+ant> <Synonymous2> Aum est là, je regardais les specs de QuarterMaster 15:04 <+ant> <Synonymous2> * Pour aider la recherche côté client, tous les éléments de données sont accompagnés 15:04 <+ant> <Synonymous2> d'un schéma de métadonnées simple - jusqu'ici, se composant juste de : 15:04 <+ant> <Synonymous2> - key - nom texte de la clé 15:04 <+jdot> mets-le sur www.i2p.net pour qu'il soit accessible via l'intarweb et i2p. 15:04 <+jdot> et toujours à jour 15:05 <gott> ouais. 15:05 <gott> eh bien, utilisez juste le mécanisme de mise à jour. 15:05 <gott> d'accord. 15:05 <gott> donc, pour finaliser : 15:05 <jrandom> bien sûr, on peut aussi le mettre sur le site web. on peut le spammer partout sur le net si ça aide ;) 15:05 <+ant> <Synonymous2> Je me demande si Aum peut implémenter le datastore de sorte que les métadonnées soient séparées au cas où il voudrait mettre à niveau le système de stockage. Souvenez-vous quand Freenet voulait changer le système de stockage mais était coincé 15:05 <gott> 1 : Interface localisée et aide contextuelle. 15:05 <gott> 2 : HOWTO localisé pour la version 1.0 15:05 <+ant> <Synonymous2> oups c'est la réunion :) 15:05 <gott> Des ajouts ? 15:06 <gott> le HOWTO couvrira beaucoup de fonctionnalités supplémentaires du réseau i2p. 15:06 <gott> où trouver le dernier porno ( je plaisante ) 15:06 <+ant> <BS314159> manpage ! :-) 15:06 <gott> les manpages ne sont pas multiplateformes 15:06 <jrandom> cool, inclure des choses comme Q, i2ptunnel, feedspace, i2p-bt, etc. serait super pour un howto 15:06 <+cervantes> l'installeur pourrait être localisé aussi je suppose... 15:06 <gott> le réseau i2p a une quantité hilarante d'utilisateurs français 15:07 <+Ragnarok> tu devrais clairement écrire la documentation du carnet d'adresses que je n'ai jamais prise le temps d'écrire :) 15:07 <gott> Je suis sûr qu'ils apprécieraient une interface localisée pour ne pas avoir à regarder la dégoûtante langue anglaise 15:07 <+cervantes> hé c'est déjà en grande partie français 15:07 <gott> vrai. 15:07 <gott> de bonnes idées. 15:08 <gott> bon, c'est tout ce que j'avais à dire. 15:08 <jrandom> ok cool, merci gott, belle initiative 15:08 <gott> pour l'instant, je vais commencer par l'aide contextuelle 15:08 <jrandom> Synonymous2: Je ne sais pas ce qu'Aum fait sur ce plan 15:08 <jrandom> classe 15:08 <gott> puis, quand une option de localisation sera ajoutée, les langues localisées 15:08 <+bla> gott: Je _déteste_ l'Anglais ! ;) 15:09 <gott> moi aussi 15:09 <+ant> <Synonymous2> Q, i2ptunnel, feedspace, i2p-bt, etc. seraient super pour un howto, je pense que l'article du wiki devrait être mis à jour pour i2p pour ajouter ça, je vais le faire 15:09 <+cervantes> eh bien vous pouvez blâmer Guillaume le Conquérant pour ça 15:09 <jrandom> heh 15:09 <gott> un wiki c'est bien, mais aussi non-officiel. 15:09 <gott> le manuel a un élément de certification. 15:09 <gott> c'est plus rassurant. 15:10 <+ant> <Synonymous2> si des gens veulent venir regarder ce serait utile aussi, l'article wikipedia de Freenet est aussi bon pour décrire les outils de Freenet. De plus, je vois que la page web de Freenet est publiée sous la GNU FDL, si i2p.net pouvait faire de même (ou domaine public) je pourrais copier des trucs sur wikipedia :)) si vous voulez faire ça 15:10 <+cervantes> sinon on parlerait encore anglo-saxon 15:10 <jrandom> tout ce que je fais sur lequel j'ai des "droits" est implicitement placé dans le domaine public 15:11 <+ant> <Synonymous2> je pensais que c'était le cas, si tu peux mettre ça comme un encart sur la page web ce serait super à ta convenance, les gens sur wikipedia sont maniaques du copyright :> 15:11 <+ant> <Synonymous2> :))) 15:11 <gott> jrandom: toute la localisation que j'écrirai sera dans le domaine public 15:11 <jrandom> d'un autre côté, copier le texte tel quel est, euh, pas très utile, car vos copies seront obsolètes - liez simplement, le web existe pour une raison 15:11 <gott> Je me fiche de n'importe quelles licences. 15:12 <gott> aussi, dernière question : 15:12 <+ant> <Synonymous2> j'allais copier quelques trucs comme le graphique et des images hehe 15:12 <gott> où se trouvent les .jsp du router ? 15:12 <jrandom> gott: http://dev.i2p/cgi-bin/cvsweb.cgi/apps/routerconsole/jsp/ 15:13 <gott> ah 15:13 <gott> donc, en local, elles sont dans un .jar ? 15:13 <jrandom> gott: routerconsole.war 15:13 <jrandom> mais tu ne peux pas vraiment les éditer là, car elles sont précompilées en Java 15:13 * gott hoche la tête 15:13 <gott> Bien sûr. 15:14 <gott> Ceci dit, c'est une gêne. 15:14 <gott> quand la localisation sortira, ça pourrait changer ? 15:14 <jrandom> oui. beaucoup d'options cependant. si tu prépares le HTML que les JSP devraient rendre, on pourra l'intégrer 15:14 <+cervantes> Synonymous: http://www.i2p.net/licenses 15:15 <gott> ainsi vous pouvez avoir des packs de langue 15:15 * gott hoche la tête 15:15 <gott> pour l'instant, c'est juste en dur 15:15 <jrandom> la localisation en Java fonctionne en chargeant des fichiers properties par langue avec les ressources 15:15 <gott> mais plus tard, ce devrait être moins restrictif, je suggère 15:15 <jrandom> oui oui 15:16 <gott> génial. 15:16 <gott> eh bien, j'utiliserai le CVS anonyme alors ;-) 15:16 <jrandom> classe 15:16 <+ant> <BS314159> bla: tes données brutes sont-elles disponibles quelque part ? 15:16 <jrandom> bla vient de se déconnecter, mais on verra pour rendre des données disponibles 15:17 <gott> au fait, quelqu'un fait tourner i2p sur OpenBSD ? 15:17 <+ant> <BS314159> ce serait amusant de laisser les gens essayer leurs propres estimateurs 15:17 <+ant> <BS314159> sister:...23? 15:17 <jrandom> gott: oui, je crois que detonate le fait 15:18 <+ant> <BS314159> ack 15:18 <+ant> <BS314159> cross-post 15:18 <+ant> <BS314159> zut ! 15:18 <gott> est-ce même possible ? quelles sont les limitations de Java concernant OpenBSD et i2p ? 15:18 <gott> d'accord. 15:18 <jrandom> BS314159: oui, il y a de bonnes infos sur la modification de vos estimateurs sur le forum 15:18 <+cervantes> longue réunion 15:18 <gott> si j'ai du temps un jour, je pourrais le faire tourner et préparer un port. 15:18 <gott> mais c'est pour plus tard et quelqu'un le fera probablement avant moi ;-) 15:18 <jrandom> cervantes: consulte les logs, on a déjà dépassé 2 h auparavant ;) 15:19 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 15:20 <jrandom> sinon 15:20 * jrandom se prépare 15:20 * jrandom *baf* clôt la réunion