Reunión de desarrolladores de I2P - 30 de mayo de 2006

16:00 <jrandom> 0) hola 16:00 <jrandom> 1) Estado de la red 16:00 <jrandom> 2) Filtrado de pares 16:00 <jrandom> 3) Estado de Syndie 16:00 <jrandom> 4) ??? 16:00 <jrandom> 0) hola 16:00 * jrandom saluda 16:01 <jrandom> notas semanales de estado publicadas @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html 16:01 <jrandom> (incluso con una hora de antelación [o con unas semanas de retraso, si quieren meterse conmigo ;]) 16:02 <jrandom> ok, vamos a meternos de lleno en 1) Estado de la red 16:02 <jrandom> las cosas no están como deberían. están mejor que durante el colapso por congestión, pero debería estar mejor de lo que está ahora 16:03 <jrandom> no tengo mucho más que añadir sobre eso, a menos que ¿alguien tenga alguna pregunta/preocupación sobre el 1)? 16:03 <@frosk> consigo días de conexión IRC con la .19, así que no me quejo 16:04 <jrandom> bien 16:04 <jrandom> sí, es bueno para algunos, solo que no lo suficientemente bueno ni consistente. Las estadísticas en la base de datos tampoco se ven tan bien 16:06 <jrandom> ok, ¿alguien tiene algo más sobre 1) Estado de la red, o pasamos a 2) Filtrado de pares? 16:07 <jrandom> [insertar sonidos de movimiento aquí] 16:09 <jrandom> como se mencionó en el correo, la idea es darle un empujón a nuestra selección de pares. al principio será un poco peligroso, permitiendo algunos ataques de partición activos, pero si funciona como espero, podremos evitarlos 16:10 <jrandom> (pero evitarlo requiere esencialmente matar todas las identidades de router, lo que serviría básicamente como un restablecimiento de la red, así que me gustaría evitarlo a menos que valga la pena) 16:11 <bar> ¿restablecerlas una vez o repetidamente? 16:11 <bar> s/reset/killing 16:11 <jrandom> al menos una vez, pero también con todos los cambios de configuración drásticos posteriores 16:12 <jrandom> (o sea, poner algunos criterios en el certificado de la identidad del router, lo que a su vez implica cambiar el hash de la identidad, para que no puedan fingir imponer una configuración a unos y otra a otros) 16:13 <bar> entendido 16:14 <jrandom> ok, no creo que tenga nada más sobre ese tema por el momento, a menos que alguien tenga preguntas/comentarios/preocupaciones? 16:15 <jrandom> (con suerte habrá una compilación en uno o dos días; lanzamiento después de que se estabilice) 16:17 <jrandom> ok, pasando brevemente por el 3).. 16:18 <jrandom> Syndie va avanzando, y aunque la batalla amd64/amd32/x86/swt/gcj no siempre ha sido bonita, tendremos una compilación lista en junio 16:19 <jrandom> (pero aún no me hablen de mingw/gcj ;) 16:19 <jrandom> no tengo mucho más que añadir ahí por el momento, a menos que ¿alguien tenga preguntas/preocupaciones respecto a la renovación de Syndie? 16:21 <@cervantes> ¿Cómo va el soporte para mingw/gcj? 16:21 <@cervantes> *se agacha* 16:22 <@cervantes> ¿Tendremos algunas capturas antes del lanzamiento de junio? :) 16:23 <jrandom> seguro que intentaré enganchar a algunos voluntarios entusiastas para las pruebas previas al lanzamiento ;) 16:23 <tethrar> cuenten conmigo ;) 16:23 <jrandom> w3wt 16:24 <jrandom> ok, vamos a pasar al punto que sé que todos ustedes han estado esperando: 4) ??? 16:24 <jrandom> ¿wazaaaap? 16:24 <green> ¿Existe algún plan para tener un I2P router "real" funcionando con Via C7? jbigi da solo un 30% de mejora respecto a Java puro 16:25 <jrandom> ¿Un 30% sigue siendo demasiado intensivo de CPU? ¿Qué hace que no sea "real"? 16:25 <jrandom> pero no, no tengo las habilidades matemáticas ni de ensamblador para C7 como para hacer un libGMP mejor para C7. 16:25 <green> claro que es demasiado intensivo de CPU con un 100% de carga de CPU :P 16:26 <jrandom> una carga de CPU del 100% sugiere que el problema no es jbigi, sino el hecho de que jbigi necesita usarse demasiado 16:26 <jrandom> y para eso, sí, tenemos muchas cosas en camino. 16:26 <jrandom> (p. ej., reduciendo los restablecimientos de conexión, mejorando las tasas de éxito de construcción de tunnel, etc.) 16:27 <jrandom> ((y no recibir tantas solicitudes de tunnel si el router no es capaz de manejarlas)) 16:29 <green> humm, esto es con una máquina dedicada con 100 Mb/s, así que debería poder con ello 16:30 <jrandom> no, el ancho de banda no es el único recurso limitado aquí; obviamente la CPU lo es ;) 16:33 <jrandom> ok, ¿alguien tiene algo más para la reunión? 16:36 <jrandom> *tos* 16:37 * jrandom se prepara 16:37 * jrandom *baf* da por cerrada la reunión