Reunión de desarrolladores de I2P - 06 de diciembre de 2005

15:26 <jrandom> 0) hola 15:26 <jrandom> 1) 0.6.1.7 y estado de la red 15:26 <jrandom> 2) Fallos experimentales de tunnel 15:26 <jrandom> 3) SSU y NATs 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) hola 15:26 * jrandom saluda 15:26 <jrandom> notas de estado semanales publicadas en http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 15:26 * ailouros lee las notas 15:27 * jrandom llego tarde, así que les daré un momento para ponerse al día :) 15:29 <jrandom> ok, mejor pasemos a 1) 0.6.1.7 y estado de la red 15:29 <@cervantes> *tos* 15:29 <jrandom> No tengo mucho más que añadir aparte de lo que está en el correo sobre este punto. ¿Alguien tiene más comentarios/preguntas/ideas? 15:30 <Pseudonym> parece que hacer optimización de rendimiento antes de cambiar el algoritmo de creación de tunnel podría ser al revés 15:30 <gott> Estoy recibiendo muchos "No se encontró ningún método HTTP en la solicitud. 15:30 <gott> El software provocó aborto de conexión: error de escritura en el socket 15:30 <gott> " 15:30 <@modulus> el lag del tunnel es mucho menor, no sé si hicisteis cambios o si mi ISP es mejor de repente. 15:30 <gott> desde el I2PTunnel Webmanager 15:31 <jrandom> gott: eso sugiere solicitudes HTTP erróneas, o cosas que el eepproxy no pudo entender 15:31 <jrandom> modulus: genial, hemos estado haciendo muchas cosas para intentar mejorar 15:31 <jrandom> Pseudonym: bueno, hasta ahora la creación de tunnels no ha sido nuestro cuello de botella; el cuello de botella estaba en cosas de un nivel mucho más alto 15:32 <jrandom> por otro lado, las mejoras de las últimas revisiones han expuesto algunos problemas ahí abajo 15:32 <Pseudonym> oh, entonces la optimización ha estado relacionada con otras partes del código? 15:32 <Pseudonym> genial 15:33 <jrandom> sí, a nivel de SSU, así como a nivel de operación de tunnel. la creación de tunnels no es una operación sensible al rendimiento [excepto cuando lo es ;] 15:34 <jrandom> Sin embargo, estoy haciendo pruebas de carga en vivo en la red, recopilando estadísticas de carga no anónimas de distintos pares para intentar acotar más 15:34 <ailouros> Me pregunto por qué a veces veo más tunnels de los configurados para un destino (p. ej., eeProxy, 7 tunnels entrantes, 4 salientes) 15:34 <jrandom> así que, durante los próximos días, cuando vean el router 7xgV transfiriendo muchos datos, bueno, no le hagan caso ;) 15:35 <jrandom> ailouros: cuando la creación de tunnels tarda, construye adicionales, por si acaso. 15:35 <jrandom> zzz describe algunos de los problemas raros en ese frente también, y hay un parche en el que se está trabajando para mejorar un poco las cosas 15:35 <ailouros> Ya veo... pero entonces, ¿por qué caducan todos al mismo tiempo? 15:35 <@cervantes> jrandom: por curiosidad, ¿cuándo empezaste esas pruebas? 15:35 <jrandom> cervantes: hace unos días 15:36 <@cervantes> ah genial, entonces _no_ es eso ;-) 15:36 <jrandom> ni idea, ailouros, depende de algunas condiciones. pero hay algunas... *ejem* rarezas en el código de creación de tunnels, con el que he evitado meter mano ya que se va a reescribir para 0.6.2 15:38 <ailouros> Ya veo. Pensé que era una cuestión de política... Preferiría ver los tunnels morir en distintos momentos salvo que haya una buena razón para no hacerlo 15:38 <ailouros> es decir, que las creaciones de tunnels estén sesgadas 15:39 <jrandom> sí, habrá mejor aleatorización para 0.6.2, y el parche de zzz añade algo de aleatoriedad para la revisión actual también 15:40 <+Complication> Me pregunto por qué una instancia por lo demás cuerda de i2phex... decidiría volver a calcular el hash de los archivos una vez sí y otra no al iniciarla? 15:40 <jrandom> ni idea 15:40 <+Complication> Hasta ahora suena a configuración dañada como causa probable, pero aún no he borrado mi configuración. 15:40 <jrandom> ¿quizá marcas de tiempo sesgadas? 15:42 <+Complication> No, parecen correctas también 15:42 * jrandom no lo sabe. nunca miró esa parte del cód de phex 15:42 <jrandom> er, código 15:42 <+Complication> Veré si borrar archivos de configuración antiguos le hace algún bien 15:42 <jrandom> genial 15:43 <jrandom> ok, ¿algo más sobre 1) Estado de la red / 0.6.1.7? 15:43 <jrandom> si no, pasamos a 2) Fallos experimentales de tunnel 15:44 <jrandom> ya hemos tocado esto un poco, y hay más en las notas y en zzz.i2p 15:44 <jrandom> zzz: ¿tienes algo que quieras añadir/plantear? 15:46 <jrandom> si no, pasemos a 3) SSU y NATs 15:46 <jrandom> bar: ¿algo que quieras añadir? 15:46 <+bar> no, no tengo nada más que añadir aparte de lo que está en el correo 15:47 <jrandom> genial, sí, aún tengo que responder a algunos detalles; creo que nuestra retransmisión ya se encargará de algunos de los problemas que planteas 15:48 <jrandom> el truco va a ser detectar qué situación está en juego, para que podamos automatizar el procedimiento correcto (o informar al usuario de que está jodido) 15:48 <+bar> todo a su debido tiempo, sin prisa 15:49 <+bar> sí, sugerí un ajuste manual del usuario para sortear ese problema por el momento, quizá no sea posible, pero podemos discutirlo después 15:50 <jrandom> sí, las anulaciones manuales ayudarán, pero mi experiencia con revisiones anteriores de i2p fue que todo el mundo (*todo el mundo*) la cagó ;) así que se prefiere la automatización 15:50 <jrandom> (todo el mundo me incluye a mí ;) 15:52 <+bar> de acuerdo 15:52 <ailouros> lol si yo también lo hice, entonces había algo mal con la documentación, ya que la seguí paso a paso :D 15:53 <+bar> mientras tanto, dedicaré algo de tiempo a estudiar las pruebas entre pares 15:53 <jrandom> genial, ¡gracias bar! 15:54 <+bar> (quizá también podría generar algo de spam inútil al respecto :) 15:54 <jrandom> :) 15:55 <jrandom> ok, si no hay nada más sobre el 3), pasemos al 4) Syndie 15:56 <jrandom> ha habido mucho progreso en este frente últimamente, con cambios bastante sustanciales en la UI desde que salió 0.6.1.7 15:57 <jrandom> también hay una nueva instalación/compilación independiente, aunque como todos tenemos i2p instalado, no necesitamos una aparte 15:57 <ailouros> Encuentro que el diseño de la 6.1.7 es más difícil de usar que el de la 6.1.6 15:58 <jrandom> hmm, ¿estás ejecutando syndie en modo de usuario único? y/o ¿estás usando la última compilación de CVS o la compilación oficial 0.6.1.7? 15:58 <ailouros> oficial 0.6.1.7, usuario único 15:58 <jrandom> ¿eres de los partidarios de la interfaz tipo blog, en lugar de la navegación por hilos? 15:58 <ailouros> No lo soy, aunque no sé realmente cuál es la tipo blog 15:58 <ailouros> personalmente preferiría una navegación por hilos 15:59 <ailouros> (y también algún código de colores para los mensajes nuevos en la vista de hilos) 15:59 <+Complication> CVS relativamente reciente, usuario único 15:59 <+Complication> He encontrado una pequeña rareza (que creo podría no ser intencional) 15:59 <jrandom> ah, ha habido mucho progreso en ese frente en CVS, ailouros 15:59 <ailouros> genial :) 16:00 <jrandom> también tenemos una nueva visualización en hilos, usando la sugerencia de cervantes de un recorrido completo de solo una rama, en lugar de todas las ramas 16:00 <@cervantes> ¿se han subido esos cambios a syndiemedia.i2p.net? 16:00 <+bla> ¿Sería buena idea mostrar algunos ejemplos por defecto para la ubicación en http://localhost:7657/syndie/syndicate.jsp ? 16:00 <jrandom> syndiemedia.i2p.net es la cabecera de CVS, sí 16:00 <+Complication> Cuando has abierto un hilo y estás leyendo sus publicaciones... y luego eliges aplicar un filtro con el que no coincide ninguna publicación (p. ej., abrir el hilo "Syndie threading", aplicar el filtro "i2p.i2phex")... 16:00 <jrandom> sí, quizá, bla. las instalaciones nuevas tendrán los tres valores por defecto ahí, pero los ejemplos serían buenos 16:01 <@cervantes> (aunque el árbol del hilo actual también necesita abrirse por completo) 16:01 <+Complication> ...parece dejar las publicaciones actuales mostradas, como si coincidieran o algo así... 16:01 <+Complication> A pesar de que definitivamente hice clic en el botón "Go". 16:01 <@cervantes> Complication: sí, yo también lo encontré confuso 16:02 <jrandom> hmm Complication, la idea general era permitirte navegar mientras sigues viendo una publicación, pero quizá sería mejor quitar las publicaciones que se están mostrando 16:02 <jrandom> cervantes: ah, sí, expandirlo hasta la hoja estaría bien y debería ser trivial de hacer 16:02 <+Complication> Acabo de notarlo y, como destacaba, pensé en comentarlo 16:02 <@cervantes> (o hacerlo más obvio de que no hay coincidencias) 16:03 <jrandom> bueno, la navegación del hilo dice *sin coincidencias* :) 16:03 <ailouros> quizá está buscando un mechero 16:03 <jrandom> !thwap 16:03 <@cervantes> (o hacerlo aún más obvio de que no hay coincidencias) 16:03 <jrandom> <blink>Sin coincidencias</blink> 16:03 <+Complication> Ups :) 16:04 <tethra> ¡parece que tu !thwap le dio a spaetz__ en su lugar, jr! 16:04 <+Complication> Cierto, a veces el navegador de hilos *sí* se siente muy lejos :) 16:04 <jrandom> sí, estamos experimentando con algo de CSS para flotar eso en un lateral, como opción 16:05 <@cervantes> con soporte de temas podrías tener el hilo arriba abajo izquierda derecha, etc 16:05 <@cervantes> ah, como dijo jr 16:05 <+Complication> El enlace "Threads" te lleva allí bastante rápido, eso sí 16:05 <+Complication> ...si está dentro del área visible actualmente. 16:06 <+Complication> Y quienes están acostumbrados a navegar con el teclado naturalmente pueden pulsar "End" 16:06 <jrandom> por supuesto, esto es muy simple de modificar (como pueden ver por los cambios rápidos en CVS :), así que si alguien tiene sugerencias (o maquetas - html / png / etc.), por favor, publíquenlas cuando sea 16:07 <jrandom> Espero que tengamos una página principal de resumen estilo blog en los próximos días en CVS 16:08 <jrandom> ok, hay muchas otras cosas en marcha con syndie, así que pásense por http://localhost:7657/syndie/ para más información :) 16:08 <jrandom> ¿alguien tiene algo más que plantear sobre eso, o pasamos a 5) ??? 16:09 <zzz> hola, acabo de entrar. sobre el 2), estoy buscando probadores para mi parche. 16:10 <zzz> Mis resultados son mejoras en el retardo de tareas (job lag) y la fiabilidad, y reducción de cuelgues del router. Así que espero que otros lo prueben. 16:10 <ailouros> eso suena suficientemente bien. ¿qué tengo que hacer? 16:11 <jrandom> hola zzz, ok genial, yo también lo estaré machacando un poco aquí. tiene muchos componentes distintos, así que podría valer la pena dividirlo en partes, pero se ve bien y va en camino para 0.6.1.8 16:11 <ailouros> (el tiempo de actividad medio es de unas 10 h aquí :( 16:11 <zzz> Si tienes el código fuente y ant, simplemente aplica el parche, o puedo subir un i2pupdate.zip si quieres 16:12 <zzz> jrandom trabajaré en dividirlo 16:12 <ailouros> Me quedo con la actualización, gracias 16:13 <zzz> ailouros lo pondré en zzz.i2p dentro de una hora; gracias 16:13 <jrandom> zzz: no me preocuparía por eso a menos que tengas tiempo libre... puedo leer el diff :) 16:13 <ailouros> gracias 16:14 <zzz> jrandom OK. Hay algunas cosas misceláneas que cualquiera de los dos puede quitar fácilmente. 16:16 <ailouros> ¿Supongo que estamos en 5) ??? ahora? 16:16 <zzz> jrandom otro tema eran OOMs (falta de memoria) del Router con i2phex y posibles problemas de SAM 16:16 <jrandom> sí, ailouros 16:16 <jrandom> ah sí, zzz, sería genial localizar qué pasa con SAM 16:17 <ailouros> j346, ¿tuviste la oportunidad de mirar mi app? 16:17 <jrandom> Lo ideal sería que alguien pudiera subirse al carro y hacerse cargo del mantenimiento del puente SAM, ya que no he hecho ningún trabajo sustancial en él, y human no ha estado por aquí desde hace un tiempo. 16:19 <jrandom> aún no, ailouros, por desgracia. no estaba muy seguro de cómo funcionaba, así que tengo que leer el código fuente primero 16:20 <ailouros> siéntete libre de preguntar 16:20 <ailouros> (y buena suerte en el viaje por el código fuente, es una buena definición de la palabra "lío") 16:20 <jrandom> jeje 16:21 <zzz> corrección: mi experiencia han sido OOMs (falta de memoria) al usar i2p-bt, no i2phex. Ocurre después de unas 24 horas cuando se ejecuta un i2p-bt y en unas pocas horas cuando se ejecutan dos i2p-bt 16:22 <+Complication> El mío ocurrió después de unas pruebas de estrés nocturnas. 16:22 <+Complication> (durante las cuales, dicho sea de paso, vi promedios de 5 minutos de 50 KB/s) 16:22 <bar_> ¿podrías recordarme qué es/hace tu app, ailouros? mi memoria es buena pero corta... 16:22 <+Complication> Entrante, eso es. 16:22 <+Complication> La saliente estaba limitada a 35 KB/s 16:22 <@cervantes> Complication: nunca lo había oído llamar pruebas de estrés nocturnas antes... 16:22 <jrandom> bien, Complication 16:23 <+Complication> cervantes: bueno, entonces se podría llamar mega-leecheo semi-diario :P 16:23 <ailouros> bar_: es una prueba de concepto funcional para una app de compartición de archivos distribuida que comparte bloques comunes entre diferentes archivos (como sugirió polecat) 16:23 <bar_> ah, cierto, gracias ailouros 16:24 <tethra> cervantes: jejeje ;) 16:24 <ailouros> de nada (si alguien quiere obtener el código fuente, está en C/C++) 16:25 <+polecat> ailouros: Ten cuidado, la probabilidad de que dos bloques binarios sean iguales es suficientemente rara; en su mayoría hablo de pura teoría que sería poco útil en la práctica. 16:25 <ailouros> polecat, estoy de acuerdo. Mi mejor suposición es que resulta útil cuando tienes diferentes versiones de los mismos archivos 16:25 <ailouros> por ejemplo, una película que tiene un bloque corrupto 16:25 <+polecat> ¡Podrías transferir bloques de ceros a velocidades de vértigo! ("El siguiente bloque es de ceros" "oh, ese ya lo tengo" "el siguiente bloque es de ceros" "oh, ese ya lo tengo") 16:26 <ailouros> o un archivo de otros archivos zip 16:26 <jrandom> o, por ejemplo, etiquetas ID3 modificadas, etc. 16:26 <ailouros> exacto 16:26 <+polecat> Cierto. Pero una manera fácil de "arreglar" una película con un bloque corrupto es decirle a BitTorrent que descargue encima. La mayoría de los clientes conservarán los bloques cuyos hashes son iguales y sobrescribirán los que son diferentes. 16:26 <jrandom> sin embargo, los archivos contenedores probablemente no funcionarán, ya que tendrían que dividirse en los límites de archivo 16:27 <ailouros> j636, por eso quiero implementar la idea de LBFS de dividir en marcas de datos y no en tamaños de bloque fijos 16:27 <@cervantes> la comunidad de DC usó ese método, compartiendo distribuciones de archivos en rarsets 16:27 <+polecat> Lo que podría ser útil es hacer un algoritmo general de corrección de errores binarios y luego implementarlo a gran escala. Todos los bloques podrían "corregirse" entre sí, y solo tendrías que transmitir los datos de corrección, que podrían ser más pequeños que transmitir el bloque en sí. 16:29 <@cervantes> y entonces las búsquedas se basan en hashes Tiger de esas partes rar 16:29 <+Complication> Buena idea... aunque suena difícil :) 16:29 <+polecat> Pero solo un equivalente hash-por-hash... ¡nunca encontrarías dos bloques iguales! 16:29 <ailouros> cervantes, ¿qué es un "rarset"? :D (Excepto un "archivo RAR", claro) 16:29 <+polecat> A menos que ambos lados ya tuvieran el archivo, uno de ellos corrupto. 16:29 <ailouros> polecat, ¿eh? 16:29 <@cervantes> ailouros: un archivo RAR dividido, con archivos de paridad si es necesario 16:30 <ailouros> cervantes: no entiendo la ventaja de hacer eso 16:31 <@cervantes> su principal beneficio era añadir descarga pseudo-multifuente a DC 16:32 <ailouros> bueno, eso es parte del mecanismo de compartición de bloques entre archivos, ¿no? 16:34 <ailouros> polecat: sobre que bittorrent sobrescriba archivos dañados, lo que no te soluciona es cuando intentas obtener múltiples versiones a la vez 16:35 <@cervantes> tu cliente solo hace match/descarga partes válidas, si tienes archivos de paridad también puedes recuperar partes dañadas 16:35 <ailouros> con mi sistema no hay partes dañadas (los archivos se ensamblan solo cuando los bloques que los componen se descargan y se vuelven a verificar) 16:36 <@cervantes> cosas que bittorrent hace por defecto, salvo que no puedes buscar específicamente partes individuales 16:36 <+polecat> Sin embargo, es poco probable que múltiples versiones tengan un solo bit en común... por eso son tan estúpidas. Algún tipo decide volver a codificar la película en formato sello postal y le da el mismo nombre. 16:37 <+polecat> O algún otro toma datos aleatorios y les pone el nombre del archivo que quieres descargar. 16:37 <ailouros> lol eso es correcto 16:37 <@cervantes> exacto, y los lanzamientos en rarset son inmunes a eso... 16:37 <ailouros> pero ten en cuenta que los archivos de otras redes (emule, kazaa, lo que sea) a menudo vienen corruptos 16:38 <+polecat> los lanzamientos en rarset no son inmunes... 16:38 <+polecat> Aún tienes que averiguar cuál rarset es el correcto. 16:38 <ailouros> cervantes, ¿cómo son inmunes los rarsets a que un idiota publique basura aleatoria? 16:38 <@cervantes> (siempre que tengas una fuente fiable) 16:39 <@cervantes> porque un grupo de releases publica hashes/información de distribución 16:39 <ailouros> jajaja eso es fácil :D 16:39 <@cervantes> y las cosas se marcan como "nuked" si son de mala calidad, la gente las quita de sus compartidos 16:40 <ailouros> cervantes, eso ya lo hace mi juguete 16:40 <@cervantes> genial 16:40 <ailouros> obtienes el descriptor del archivo de una fuente de confianza, haces multiget del archivo en seguida 16:41 <@cervantes> suena bien ;-) 16:41 <ailouros> no puedes buscar archivos, pero puedes navegar por el directorio compartido de cada usuario, así que puedes usar un rastreador web y cachear los resultados 16:42 <ailouros> aunque podría añadir una función de búsqueda en algún momento en el futuro si se considera necesario 16:44 <ailouros> Creo que mi juguete, desarrollado adecuadamente en una app, puede ofrecer el caché y la resiliencia que la gente de freenet intenta ofrecer 16:44 <ailouros> como en distribución y caché de contenido estático 16:45 <ailouros> lees mi blog, lo cacheas y se lo ofreces a otras personas cuando lo quieran. no haces nada más que dejar el contenido ahí 16:45 <ailouros> ¿no te gusta el contenido? bórralo y listo 16:45 <jrandom> hmm, entonces, ¿lo ves como un backing store (almacén de respaldo) que podría usarse para syndie? 16:46 <ailouros> PUEDE usarse como un backing store 16:46 <ailouros> tal como está ahora, incluso podrías usarlo en lugar de Jetty, en instalaciones por defecto de i2p 16:46 <jrandom> p. ej., adjuntos/enlaces a [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (bueno, con un par de cambios menores :D ) 16:46 <jrandom> je 16:47 <jrandom> ok, sí, definitivamente no entiendo cómo funciona clunk... ¿quieres publicar sobre ello en syndie, o montar un eepsite? :) 16:47 <ailouros> los hashes de archivo se descargan al solicitar el archivo, y esos hashes se descargan de forma automágica en el archivo completo 16:48 <jrandom> claro, pero "down"loaded es una cuestión de de dónde a dónde, etc. una descripción general de la arquitectura de red sería útil 16:48 <ailouros> Escribiré primero un doc decente y luego lo publicaré en algún sitio 16:48 <jrandom> r0x0r, gracias 16:48 <ailouros> descargados desde donde sea que obtuviste el hash 16:48 <ailouros> más todos los demás que compartan esos bloques 16:49 <ailouros> piensa en go!zilla y Download Accelerator :) 16:49 <jrandom> Creo que no entiendes cuán confundido estoy 16:49 <ailouros> pero transparente y dentro de i2p 16:49 <ailouros> lol supongo que sí :D 16:50 <jrandom> una explicación muy, muy básica de, por ejemplo, "ejecutas un cliente clunk, descargas de un servidor clunk, obtienes info sobre peers clunk", etc 16:50 <jrandom> ¿Uso un navegador web para consultar a un cliente clunk? ¿o a un servidor? ¿o a un peer? 16:51 <jrandom> (así de perdido estoy) 16:51 <ailouros> rehacer desde 0 :) 16:51 <ailouros> usas tu navegador web 16:51 <ailouros> te conectas a tu cliente 16:51 <ailouros> navegas por el directorio de otros con tu navegador 16:51 <ailouros> seleccionas qué archivos descargar con tu navegador 16:51 <ailouros> tu cliente hace el trabajo sucio 16:52 <ailouros> obtienes el archivo descargado de vuelta 16:52 <ailouros> ¿así mejor? :) 16:52 <jrandom> ok genial, gracias; entonces, el "navegar el directorio de otros" lo hace tu cliente consultando su cliente y respondiendo con una representación HTML del mismo 16:52 <ailouros> exactamente 16:52 <jrandom> (o extraído de algún servidor/superpeer/etc) 16:53 <jrandom> guay 16:53 <ailouros> todo el trabajo sucio (encontrar duplicados, multidescargas y demás) lo hace tu cliente (local) de forma transparente 16:54 <ailouros> lo que ves es, básicamente, un árbol de directorios y algunos archivos que puedes descargar 16:54 <jrandom> genial 16:55 <ailouros> para publicar tus datos das tu dirección pública (P2P) 16:55 <ailouros> y para compartir archivos los copias (o les haces symlink) al directorio pub/ (o algún subdir). Así de fácil 16:57 * jrandom seguirá hurgando en el código fuente y espera más información :) 16:57 <jrandom> ok, ¿alguien más tiene algo para la reunión? 16:57 <bar_> umm... ¿cuál es la diferencia entre publicar y compartir, si puedo preguntar? ¿publicar empuja los datos a algún datastore? 16:58 <ailouros> bar_: compartir es dar los bloques para descargar. publicar es dejar que el mundo sepa lo que compartes 16:58 <ailouros> publicar es un subconjunto de compartir 16:58 <bar_> aja, entendido, gracias 16:58 <ailouros> por ejemplo, si tienes la mitad de un archivo, lo compartes pero no lo publicas 16:59 <jrandom> ¿cómo sabría la gente que podría obtener esos bloques de ti entonces? 16:59 <ailouros> y tienes control total sobre qué archivos publicas (a diferencia de eMule donde cada archivo descargado se publica) 16:59 <ailouros> porque cada cliente envía periódicamente información a la red sobre qué bloques tiene para ofrecer 17:00 <jrandom> guay 17:00 <ailouros> envía a la red, ya sea a un servidor (como ahora) o a un DHT (futuro) 17:00 <jrandom> entonces es mnet-esque, con un tracker de bloques 17:00 <ailouros> err ¿mnet-esque? 17:01 <jrandom> similar a cómo funciona mnet (mnetproject.org) 17:01 * ailouros está leyendo mnetproject.org 17:02 <ailouros> bueno, solo tienes tus espacios personales, no espacios compartidos 17:02 <ailouros> y no empujas bloques por ahí 17:02 <jrandom> sí, no es exactamente lo mismo que mnet, pero es similar estructuralmente 17:03 <jrandom> es como mnet donde todos están demasiado sin pasta para que alguien aloje sus datos ;) 17:03 <ailouros> sip 17:03 <ailouros> :D 17:03 <jrandom> ok, ¿alguien más tiene algo que plantear? 17:04 <jrandom> si no... 17:04 * jrandom se prepara 17:04 * jrandom *baf*s da por cerrada la reunión