Reunión de desarrolladores de I2P - 01 de agosto de 2006

16:02 <jrandom> bueno, vamos a poner esto en marcha 16:03 <jrandom> hola, las notas previas a la reunión están publicadas en http://dev.i2p.net/pipermail/i2p/2006-August/001304.html 16:03 <jrandom> en lugar de que yo básicamente vuelva a leer ese mensaje aquí para ustedes, saltemos a nuestra sección estándar de ??? - 16:04 <jrandom> ¿Alguien tiene algo que quiera plantear y discutir? 16:04 <@cervantes> eerm 16:04 * cervantes se apresura a leer la publicación 16:05 <+Complication> Con respecto al estado de la red, todo bien por aquí... 16:05 <+Complication> Pero una pregunta (en realidad retransmitida desde el foro) sobre el transporte NTCP, 16:06 <+Complication> es decir, ¿parece probable que activarlo pueda causar a alguien problemas de carga de CPU (estaban en XP)? 16:06 <@cervantes> Tengo que decir que de hecho he visto un menor uso de CPU desde que me pasé :) 16:07 <jrandom> bueno, no puedes *desactivarlo* (a menos que hayas estado leyendo el código fuente y conozcas el conjuro mágico ;) 16:07 <+Complication> La persona que habló de este problema (no es fácil reproducirlo, y aquí no hay gran uso de CPU) mencionó que su experiencia de alto uso de CPU parecía correlacionarse con NTCP 16:07 <jrandom> así que supongo que se refieren a no aceptar conexiones ntcp entrantes 16:07 <+polecat> NTCP hace que mi router ponga la CPU al 100% de inmediato, y lo repetí dos veces antes de tener que alterar manualmente el archivo de configuración para volver a tener un router funcionando. 16:07 <jrandom> (mientras se siguen usando conexiones ntcp salientes) 16:07 <+Complication> (por aquí solo está un poquito por encima de los niveles habituales, y eso probablemente se deba a que estamos bombeando *muchos* más datos) 16:08 <+Complication> ( http://forum.i2p/viewtopic.php?t=1815 ) 16:08 <jrandom> cuando estableces una conexión ntcp, haces un cálculo criptográfico pesado (o tres) 16:08 <jrandom> si estás aceptando conexiones ntcp entrantes, puedes recibir muchos intentos entrantes a la vez, ya que hay cientos de routers i2p por ahí 16:09 <jrandom> polecat: eso no fue culpa de ntcp, fue culpa de un servidor ntp defectuoso en el pool de ntp 16:09 <+polecat> Sí. Así que, por lo visto, no puedo manejar eso yo mismo. 16:09 <jrandom> (gracias a cervantes por localizar ese servidor ntp y conseguir que la gente del pool les hiciera un !thwap :) 16:10 <jrandom> ((y a Complication por hacer que evitemos a esos locos bastardos en el futuro :)) 16:10 <@cervantes> je, creo que sus watchdogs del servidor solo funcionan entre semana ;-) 16:10 <+Complication> Bueno, la evitación actual es bastante limitada 16:10 <@cervantes> http://www.pool.ntp.org/scores/216.52.237.153 16:11 <+Complication> Espero terminar codificando algo más paranoico eventualmente 16:11 <+polecat> Oh, ¿así que habilitar NTCP ya no pondrá la CPU al 100%? 16:11 <jrandom> (nunca lo hizo, polecat, fue una coincidencia ;) 16:12 <+Complication> "clock" ¿en qué sentido exactamente? 16:12 <jrandom> (mira el enlace de cervantes) 16:12 * polecat le suelta un golpe en la cabeza a Complication. 16:12 <@cervantes> ¿qué fumas, polecat? 16:12 <+Complication> :P 16:12 <+polecat> Eh, quiero decir, que se robó todos los ciclos de reloj. :) 16:13 <+Complication> Si saltó 30 segundos hacia adelante o hacia atrás, podría haber perdido muchísimas sesiones y recurrido a todo tipo de cripto muy, muy pesada 16:13 <+Complication> Creo que eso podría robar muchos ciclos de CPU 16:13 <+Complication> De hecho, quizá la persona en el foro vio lo mismo y lo correlacionó mal? Habrá que preguntarle... 16:13 <jrandom> ah... bueno, ráfagas de conexiones ntcp entrantes válidas causarán picos de CPU, mientras que ntcp solo-saliente solo intentará hablar con un número limitado de nuevos pares ntcp a la vez 16:14 <jrandom> no hay nada de malo en no habilitar ntcp entrante. 16:15 <@cervantes> Complication: el servidor se corrigió a mitad del lunes, así que podría valer la pena ver si han tenido problemas desde entonces 16:15 <jrandom> bien, ¿alguien más tiene algo que quiera discutir? 16:16 <+Complication> cervantes: en efecto, podría valer la pena probar 16:16 <@cervantes> He recibido informes de que algunas personas todavía pierden leases (entradas 'lease' del leaseSet) periódicamente... ¿es un problema conocido? 16:16 <+void> ¿En qué medida difiere la implementación de ntcp de ssu? 16:17 <+polecat> ¿Cómo sabemos si perdemos leases? 16:18 <jrandom> void: hay una sobrecarga de andwidth por mensaje ligeramente mayor en ntcp (aunque quizá compensada por la implementación de transmisión fiable probablemente más eficiente del SO) 16:18 <+Complication> polecat: tunnels.jsp mostrará que no hay tunnels para un tunnel pool en particular (p. ej., "shared clients") 16:18 <jrandom> cervantes: sí, nuestras tasas de éxito de construcción de tunnel aún no están donde deberían 16:18 <+void> polecat: la consola del router lo dice 16:18 <+Complication> Y como dice void, la barra lateral izquierda de la consola lo indicará 16:19 <+polecat> Recibo mucho esos mensajes de "No leases"... eso es a lo que te refieres, ¿no? 16:19 <@cervantes> sí 16:20 <+polecat> Eso es lo que normalmente mata mi conexión de IRC. ¡Pensé que era normal! 16:21 * jrandom se estremece 16:24 <+tethra> lol ;) 16:25 <jrandom> bien, ¿alguien tiene algo más para la reunión? 16:25 <@cervantes> jrandom: ¿has hecho algún progreso con syndie últimamente o has estado con las manos llenas con ntcp/corrección de bugs/búsqueda de ISP/andar en bici? 16:27 <+tethra> ¿Alguna novedad sobre feedspace, o simplemente voy a su eepsite? 16:28 <jrandom> cuando la red en vivo se fue al carajo aparté syndie. pero con la red volviendo a encarrilarse, syndie ha estado reclamando mi tiempo, y espero tener un pequeño sistema de cli pronto (con GUIs enfocadas después de eso, basadas en la retroalimentación de los usuarios) 16:28 <jrandom> (la gui de swt implementada está en bastante buen estado, pero probablemente sea mejor empezar con la cli para ajustar expectativas) 16:29 * jrandom no ha oído ninguna novedad sobre feedspace 16:29 <@cervantes> genial 16:29 <jrandom> frosk: ¿alguna noticia? :) 16:29 <+polecat> Me alegra que estés trabajando en syndie de nuevo. La nueva suena bastante prometedora. ¿Alguna idea sobre ACL para cosas como borrar blogs de un nodo, o realizar tareas administrativas independientes de la cuenta? 16:30 <@cervantes> <jrandom> DELETE FROM messages WHERE postedOn <NOW()-14*24*60*60; 16:31 <jrandom> los archivos locales probablemente seguirán siendo esencialmente confiables (ya que si puedes acceder a la base de datos del archivo local, puedes cambiar el archivo como quieras) 16:32 <jrandom> sin embargo, para blogs compartidos, sí, hay todo un conjunto de estructuras de cripto para autenticar y/o autorizar publicaciones y cambios 16:33 <jrandom> (pero también habrá una forma de que la gente vea publicaciones "no autorizadas", aunque quedarán bastante aparte) 16:33 <+polecat> Estoy seguro de que una vez que alguien inunde los sindicados con miles de entradas de blog gigantes, se perfeccionará la técnica para borrar físicamente publicaciones. 16:34 <+tethra> jeje 16:35 <jrandom> el borrado físico es trivial, la cuestión es qué publicaciones aceptar desde un principio ;) 16:36 <jrandom> (no tengo interés en convertir syndie en una plataforma de distribución de películas, etc) 16:36 <+polecat> Uno no puede estar seguro de lo que está aceptando hasta que se haya aceptado una muestra. Me imagino algo como permitir solo una lista blanca de blogs y permitir IDs nuevas de prueba antes de añadirlas, borrando al instante cuando haya traición de spam. 16:36 <jrandom> sí 16:37 <+polecat> Me interesa más su aplicación para coludir flujos de conversación juntos: ¡podríamos hacer un BBS sin servidor central, solo una etiqueta en común! 16:37 <jrandom> (permitir manualmente nuevas IDs, hacer kickban manualmente a IDs que inunden, etc.) 16:37 <jrandom> incluso hay soporte inherente para eso en la cripto, polecat :) 16:37 <+polecat> Posiblemente un moderador firmando mensajes aprobados para el BBS, y la gente recopilando esas listas de aprobación desde el blog del moderador. 16:38 <+polecat> Oh, excelente. 16:38 <@frosk> jrandom: he estado trabajando en cosas de gui últimamente, pero ha sido difícil compaginarlo con empezar un trabajo nuevo :( 16:39 * cervantes contacta a Recursos Humanos para lograr que despidan a frosk 16:40 <jrandom> ah, genial, con suerte una vez que syndie esté ahí empujando una sindicación http chapucera te volveremos a tentar ;) 16:40 <@frosk> al menos mi jefe sigue el desarrollo de i2p ahora :) 16:40 * jrandom saluda al jefe de frosk 16:40 <@frosk> oh sí, sigo decidido (¡maldita sea!) :) 16:40 <jrandom> (le da a frosk más tiempo libre, ¡lo necesitamos!) 16:41 <@cervantes> con suerte no leerá sobre cómo has estado publicando información clasificada de la empresa en tu blog de syndie 16:41 <bar> gui es buena, nos gusta la gui. estás perdonado. 16:41 <+Complication> Jeje :) 16:41 <@frosk> es raro entrar en su oficina y pillarlo leyendo syndie :) 16:41 <jrandom> jaja, genial 16:42 <+polecat> Felicidades, frosk, incluso si te despiden con vergüenza e infamia, al menos le mostraste a una persona más lo genial que puede ser syndie. 16:43 <@frosk> jeje, sí 16:43 <+tethra> jaja 16:44 <@frosk> la gui (en swt) es/será un banco de pruebas para todo lo de feedspace, para ponerlo en marcha 16:44 <jrandom> r0x0r 16:45 <+void> jrandom: ¿quizá deberías publicar en ambos sitios (cross-post) todo lo que va a las listas de correo también en syndie? 16:45 <jrandom> deberíamos integrarlo totalmente con la gui swt de syndie (el paradigma básico es un navegador, aunque no se muestran páginas html en las pestañas) 16:46 <+polecat> Eso estaría bien. Ya no logro recibir la lista de correo. 16:46 <jrandom> void: sería bastante fácil para alguien escribir un pequeño script de shell para conectar (pipe) procmail con la CLI de syndie 16:46 <@cervantes> ¿estas guis elegantes de swt están integradas en las aplicaciones? ¿o son tops (interfaces front-end) para ejecutables de cli o usan tcp, etc., etc. 16:46 <@frosk> eso tiene sentido 16:46 <jrandom> (si no recuerdo mal, hay una entrada en mi blog de hace un tiempo explicando cómo usar la cli de syndie para insertar publicaciones) 16:47 <+polecat> Actualmente se pueden hacer feeds RSS para alimentar syndie, aunque todavía es un poco chapucero. 16:47 <jrandom> cervantes: jdbc en los manejadores de eventos, en línea con jni y llamadas msvc, por supuesto ;) 16:47 * jrandom se agacha 16:48 <+polecat> ¿Microsoft Visual Classes? 16:49 <@cervantes> jrandom: entonces, cualquier cosa que pueda hablar SQL puede administrar syndie 16:49 <jrandom> (desde la perspectiva de syndie, toda la funcionalidad está básicamente implementada en muchos pequeñitos programas de cli que solo actualizan la base de datos jdbc, y hay una ui swt para navegar por la bd) 16:51 <+polecat> Y dado que la base de datos tiene dos interfaces, JDBC y SQL, un cliente que se comunique por cualquiera de esos protocolos puede fastidiar syndie. 16:51 <jrandom> cervantes: bueno, sí y no: hay una buena parte de la base de datos que está cifrada, así que no todos los campos son legibles 16:51 <+void> ¿la interfaz web actual seguirá ahí? 16:51 <jrandom> (jdbc == sql) 16:51 <jrandom> void: no 16:51 <+polecat> Pensé que habías dicho que JDBC no era un protocolo estúpido legible por humanos? 16:51 <+Complication> jdbc == interfaz de base de datos de java, quizá un poco similar a odbc 16:51 <jrandom> ((jdbc ~= sql)) 16:51 <+Complication> Algo sobre lo que hablas SQL 16:52 <+void> jrandom: ¿qué pasará con syndie.i2p/syndiemedia.i2p.net? 16:52 <+polecat> Oh. Bueno, nunca me gustó SQL de todos modos, para que conste. 16:52 <@cervantes> jrandom: entonces es mejor crear un top para syndieTools (tm) que intentar chupar los datos tú mismo 16:53 <jrandom> void: el tiempo lo dirá. probablemente 1) sirvan como el sitio web/eepsite de syndie, 2) sirvan como un archivo público de publicaciones con el que sindicar y, eventualmente, cuando se escriba una interfaz web, 3) sirvan una interfaz web 16:53 <+polecat> ¿Por qué no enviar bytecode como consultas a la base de datos, en lugar de arcaicas sentencias COBOL? 16:53 <jrandom> sí, cervantes 16:53 <jrandom> !lart polecat 16:54 <+void> jejeje 16:54 <+polecat> Ah, mi debilidad secreta. 16:54 <@cervantes> * te quedan 6 larts en tu inventario, hay una puerta al norte y un polecat inconsciente en el suelo 16:54 <jrandom> cervantes: esa en realidad es la app de cli #3 (extraer publicaciones individuales, que viene después de la app #2, listar publicaciones individuales (después de la #1, crear publicaciones individuales, y después de la #0, gestionar nyms))) 16:54 <jrandom> lol 16:54 <+tethra> jaja 16:55 <+Complication> propuesta de funcionalidad: en lugar de bytecode, ¿por qué no enviar agentes en vivo de $agency como consultas a la base de datos? ;P 16:56 <+Complication> Sería mucho más fácil de validar por seguridad :P 16:56 <@cervantes> jrandom: entendido 16:56 <+tethra> ¿actúan como palomas mensajeras con el clima adecuado, Complication? 16:56 <+Complication> tethra: solo si logras empujarlos a través de la pila TCP intactos :P 16:56 <+polecat> Sí, ¡consultas a la base de datos sobre CPP! 16:57 <+Complication> Me imagino que arrugarse en TCP podría corromperlos 16:58 <+Complication> (perdón, realmente debería mantener las bromas en #i2p-chat, pero a veces no puedo evitarlo) 16:58 * cervantes siente que un baff se aproxima pronto 16:58 <+Complication> ¿consultas a la base de datos como shellcode? 16:59 <jrandom> bien, ¿alguien tiene algo más para la reunión? 16:59 <+polecat> http://www.blug.linux.no/rfc1149/ <- podríamos hacer tunnel de i2p sobre esto, en serio. 16:59 * Complication preferiría quedarse con SQL 17:00 <+void> jrandom: ¿otros lenguajes además de java tienen bibliotecas para bases de datos hsqldb? 17:01 <+Complication> Parece probable que Oo sí, ya que parecen usarlo 17:01 <+void> me parece que es un "no" 17:01 <+void> oh, hmm 17:01 <@cervantes> openoffice lo usa, así que supongo que sí 17:01 <+Complication> Pero no estoy seguro de en qué está escrito OpenOffice 17:01 <jrandom> que yo sepa, no. pero alguien podría ejecutar syndie contra otra base de datos jdbc (mysql, oracle, etc) 17:01 <jrandom> oo usa java 17:02 <+void> ¿para qué exactamente usa openoffice esta base de datos? 17:02 <+Complication> Pero parece usarla solo parcialmente 17:02 <jrandom> void: para la generación de pdf y para su aplicación de base de datos tipo access 17:02 <jrandom> (entre otras cosas) 17:02 <+Complication> Dado que recomienda un JRE externo 17:02 <+void> vale 17:03 <+void> pero es un dolor de cabeza escribir sql portable 17:03 <+Complication> si uno no usa triggers ni procedimientos almacenados, no debería ser un gran dolor 17:04 <jrandom> eh, no es tan malo, y es fácil de externalizar 17:04 <+void> especialmente cuando apuntas a oracle ;) 17:05 <jrandom> en realidad, hsqldb soporta pl/sql ;) 17:06 <bar> ¿hay otros planes para esta base de datos, como para estadísticas, perfiles de pares, netdb..? 17:06 <jrandom> no, esto es solo para syndie 17:06 <bar> ok 17:07 <jrandom> (aunque cuando enviemos el código de hsqldb, podremos usarlo en i2p "gratis") 17:07 <@cervantes> ya que syndie no es una aplicación de I2P, solo una aplicación que puede ejecutarse sobre I2P, ¿correcto? 17:07 <jrandom> sí, cervantes, no hay dependencia de i2p 17:07 <+Complication> Es bueno mantener Syndie portable, ya que podría tener otros transportes además de I2P 17:07 <bar> exacto 17:08 <+Complication> Sin embargo, supongo que no sería difícil ejecutar muchas instancias de hsqldb en la misma máquina 17:08 <+Complication> Así que si otras apps lo necesitaran, parece que podrían simplemente usarlo 17:08 <jrandom> trivial, y de costo 0 si solo usas la base de datos in-jvm 17:08 <+Complication> (usar su propia instancia, preferiblemente) 17:10 <+void> ¿no hay driver jdbc para sqlite? 17:11 <jrandom> no sé, nunca lo he usado 17:11 <+void> ah, parece que hay *algo* 17:13 <jrandom> bien, ¿algo más para la reunión? 17:13 <jrandom> si no... 17:13 * jrandom dinws up 17:13 * jrandom da un paso atrás 17:13 * jrandom se prepara 17:13 * jrandom *baf* cierra la reunión