Reunião de Desenvolvedores do I2P - 06 de dezembro de 2005

15:26 <jrandom> 0) oi 15:26 <jrandom> 1) 0.6.1.7 e estado da rede 15:26 <jrandom> 2) Falhas experimentais de tunnel 15:26 <jrandom> 3) SSU e NATs 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) oi 15:26 * jrandom acena 15:26 <jrandom> notas semanais de status publicadas em http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 15:26 * ailouros leu as notas 15:27 * jrandom está atrasado, então vou dar um momento pra vocês lerem :) 15:29 <jrandom> ok, podemos começar com 1) 0.6.1.7 e estado da rede 15:29 <@cervantes> *cof* 15:29 <jrandom> Não tenho muito mais a acrescentar além do que está no e-mail sobre este ponto. Alguém tem mais comentários/perguntas/ideias? 15:30 <Pseudonym> parece que fazer otimização de desempenho antes de mudar o algoritmo de criação de tunnel pode ser o inverso do ideal 15:30 <gott> Estou recebendo muitos "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " 15:30 <@modulus> o lag de tunnel está bem menor, não sei se vocês fizeram mudanças ou se meu ISP ficou melhor de repente. 15:30 <gott> do Gerenciador Web do I2PTunnel 15:31 <jrandom> gott: isso sugere requisições HTTP ruins, ou coisas que o eepproxy não conseguiu entender 15:31 <jrandom> modulus: legal, temos feito muita coisa para tentar melhorar 15:31 <jrandom> Pseudonym: bem, até agora a criação de tunnel não tem sido nosso gargalo - o gargalo estava em coisas de nível mais alto 15:32 <jrandom> por outro lado, as melhorias das últimas revisões expuseram alguns problemas lá embaixo 15:32 <Pseudonym> ah, então a otimização tem sido relacionada a outras partes do código? 15:32 <Pseudonym> legal 15:33 <jrandom> sim, no nível do SSU, assim como no nível da operação de tunnel. a criação de tunnel não é uma operação sensível a desempenho [exceto quando é ;] 15:34 <jrandom> Estou fazendo alguns testes de carga na rede ao vivo, coletando algumas estatísticas de carga não anônimas de diferentes peers para tentar afunilar mais 15:34 <ailouros> Pergunto-me por que às vezes vejo mais tunnels do que os configurados para um destino (ex.: eeProxy, inbound 7 tunnels 4 outbound) 15:34 <jrandom> então, nos próximos dias, quando vocês virem o router 7xgV transferindo muitos dados, bem, não liguem ;) 15:35 <jrandom> ailouros: quando a criação de tunnel demora, ele cria extras, por via das dúvidas. 15:35 <jrandom> zzz descreve alguns dos problemas estranhos nessa frente também, e há um patch sendo trabalhado para melhorar um pouco as coisas 15:35 <ailouros> Entendo... mas então por que todos expiram ao mesmo tempo? 15:35 <@cervantes> jrandom: por curiosidade, quando você começou esses testes? 15:35 <jrandom> cervantes: alguns dias atrás 15:36 <@cervantes> ah legal, então _não_ é isso ;-) 15:36 <jrandom> não sei, ailouros, depende de algumas condições. mas há algumas... *cof* esquisitices no código de criação de tunnel, com o qual venho evitando mexer já que está sendo reescrito para a 0.6.2 15:38 <ailouros> Entendo. Achei que fosse uma questão de política... Eu preferiria ver os tunnels expirarem em tempos diferentes, a menos que haja um bom motivo para não 15:38 <ailouros> isto é, as criações de tunnel são defasadas 15:39 <jrandom> sim, haverá uma melhor aleatoriedade para a 0.6.2, e o patch do zzz adiciona alguma aleatoriedade para a revisão atual também 15:40 <+Complication> Pergunto-me por que uma instância, de resto normal, do i2phex... decidiria recalcular o hash dos arquivos a cada vez que eu o inicio? 15:40 <jrandom> não faço ideia 15:40 <+Complication> Configuração corrompida parece a causa mais provável até agora, mas ainda não apaguei minha config. 15:40 <jrandom> talvez carimbos de tempo defasados? 15:42 <+Complication> Não, eles parecem corretos também 15:42 * jrandom não sabe. nunca olhou para essa parte do código do phex 15:42 <jrandom> er, code 15:42 <+Complication> Vou ver se apagar arquivos antigos de configuração ajuda 15:42 <jrandom> legal 15:43 <jrandom> ok, mais algo em 1) Estado da rede / 0.6.1.7? 15:43 <jrandom> se não, indo para 2) Falhas experimentais de tunnel 15:44 <jrandom> já tocamos um pouco nisso, e há mais nas notas e em zzz.i2p 15:44 <jrandom> zzz: você tem algo que queira acrescentar/levantar? 15:46 <jrandom> se não, vamos para 3) SSU e NATs 15:46 <jrandom> bar: algo que queira acrescentar? 15:46 <+bar> não, não tenho nada além do que está no e-mail 15:47 <jrandom> legal, sim, ainda preciso responder alguns detalhes - acho que nossa retransmissão já vai cuidar de algumas das questões que você levantou 15:48 <jrandom> o truque vai ser detectar qual situação está ocorrendo, para podermos automatizar o procedimento correto (ou informar ao usuário que ele está ferrado) 15:48 <+bar> tudo a seu tempo, sem pressa 15:49 <+bar> sim, eu sugeri uma configuração manual do usuário para contornar esse problema por enquanto, talvez não seja possível, mas podemos discutir depois 15:50 <jrandom> sim, substituições manuais ajudam, mas minha experiência com revisões anteriores do i2p foi que todo mundo (*todo mundo*) estragou tudo ;) então a automação é preferível 15:50 <jrandom> (todo mundo incluindo eu mesmo ;) 15:52 <+bar> concordo 15:52 <ailouros> lol se eu também fiz isso, então havia algo errado com a documentação, pois eu a segui passo a passo :D 15:53 <+bar> enquanto isso, vou gastar algum tempo estudando os testes de peers 15:53 <jrandom> legal, obrigado, bar! 15:54 <+bar> (talvez eu possa gerar algum spam inútil sobre isso também :) 15:54 <jrandom> :) 15:55 <jrandom> ok, se não há mais nada em 3), vamos para 4) Syndie 15:56 <jrandom> houve muito progresso nessa frente recentemente, com reformulações bastante substanciais da UI desde que a 0.6.1.7 saiu 15:57 <jrandom> há também uma nova instalação/build standalone, embora, como todos nós temos i2p instalado, não precisamos de uma separada 15:57 <ailouros> Acho que o layout da 6.1.7 é mais difícil de usar do que o da 6.1.6 15:58 <jrandom> hmm, você está rodando o syndie em modo single-user? e/ou está usando o build mais recente do CVS ou o build oficial 0.6.1.7? 15:58 <ailouros> oficial 0.6.1.7, single-user 15:58 <jrandom> você é um dos proponentes da interface estilo blog, em oposição à navegação encadeada (threaded)? 15:58 <ailouros> Não sou, embora eu não saiba bem qual é a estilo blog 15:58 <ailouros> pessoalmente eu preferiria uma navegação encadeada (threaded) 15:59 <ailouros> (e também alguma codificação por cores das mensagens novas na visualização de threads) 15:59 <+Complication> CVS relativamente recente, single-user 15:59 <+Complication> Encontrei uma pequena estranheza (que acho que pode não ser intencional) 15:59 <jrandom> ah, houve muito progresso nessa frente no CVS, ailouros 15:59 <ailouros> ótimo :) 16:00 <jrandom> temos também uma nova exibição encadeada (threaded), usando a sugestão do cervantes de percorrer totalmente apenas um ramo, em vez de todos os ramos 16:00 <@cervantes> essas mudanças foram publicadas em syndiemedia.i2p.net? 16:00 <+bla> Seria uma boa ideia mostrar alguns exemplos padrão para o campo location em http://localhost:7657/syndie/syndicate.jsp ? 16:00 <jrandom> syndiemedia.i2p.net é o head do CVS, sim 16:00 <+Complication> Quando você abriu uma thread e está lendo seus posts... e então decide aplicar um filtro para o qual nenhum post corresponde (por exemplo, abrir a thread "Syndie threading", aplicar o filtro "i2p.i2phex")... 16:00 <jrandom> sim, talvez, bla. instalações novas terão os três padrões lá, mas exemplos seriam bons 16:01 <@cervantes> (a árvore da thread atual precisa abrir totalmente também, no entanto) 16:01 <+Complication> ...parece deixar os posts atuais exibidos, como se estivessem correspondendo ou algo assim... 16:01 <+Complication> Embora eu certamente tenha clicado no botão "Go". 16:01 <@cervantes> Complication: sim, achei isso confuso também 16:02 <jrandom> hmm Complication, a ideia geral era permitir que você navegasse enquanto ainda olha um post, mas talvez fosse melhor remover os posts que estão sendo exibidos 16:02 <jrandom> cervantes: ah, sim, expandir até a folha seria bom e deve ser trivial de fazer 16:02 <+Complication> Acabei de notar e, como chamou a atenção, achei que deveria mencionar 16:02 <@cervantes> (ou tornar mais óbvio que não há correspondências) 16:03 <jrandom> bem, a navegação da thread diz *no matches* :) 16:03 <ailouros> talvez ele esteja procurando um isqueiro 16:03 <jrandom> !thwap 16:03 <@cervantes> (ou tornar ainda mais óbvio que não há correspondências) 16:03 <jrandom> <blink>No matches</blink> 16:03 <+Complication> Opa :) 16:04 <tethra> parece que seu !thwap acertou o spaetz__ em vez disso, jr! 16:04 <+Complication> Certo, às vezes o navegador de threads *parece mesmo* estar bem longe :) 16:04 <jrandom> sim, estamos experimentando com algum CSS para flutuar isso na lateral, como opção 16:05 <@cervantes> com suporte a skins você poderia ter a thread em cima, embaixo, esquerda, direita etc 16:05 <@cervantes> ah, como o jr disse 16:05 <+Complication> O link "Threads" leva até lá bem rápido, porém 16:05 <+Complication> ...se estiver dentro da janela de visualização. 16:06 <+Complication> E quem está acostumado a navegar pelo teclado pode naturalmente pressionar "End" 16:06 <jrandom> claro, essas coisas são realmente simples de modificar (como dá para ver pelas mudanças rápidas no CVS :), então se alguém tiver sugestões (ou mockups - html / png / etc), por favor, publiquem quando quiserem 16:07 <jrandom> Espero que teremos uma página principal de visão geral tipo blog nos próximos dias no CVS 16:08 <jrandom> ok, há muitas outras coisas acontecendo com o syndie, então passe em http://localhost:7657/syndie/ para mais informações :) 16:08 <jrandom> alguém tem mais algo para levantar sobre isso, ou vamos para 5) ??? 16:09 <zzz> oi, acabei de entrar. sobre o 2), estou procurando testadores para meu patch. 16:10 <zzz> Meus resultados são melhorias no atraso de jobs e na confiabilidade, e redução nos travamentos do router. Então espero que outros experimentem. 16:10 <ailouros> isso parece bom o suficiente. o que eu tenho que fazer? 16:11 <jrandom> oi, zzz, ok, legal, vou espancar um pouco por aqui também. tem muitos componentes diferentes, então pode valer a pena dividir em partes, mas parece bom e está a caminho da 0.6.1.8 16:11 <ailouros> (o uptime médio é de cerca de 10h aqui :( 16:11 <zzz> Se você tem o código-fonte e o ant, é só aplicar o patch - ou eu posso colocar um i2pupdate.zip se você quiser 16:12 <zzz> jrandom, vou trabalhar em separar isso 16:12 <ailouros> Vou preferir o update, obrigado 16:13 <zzz> ailouros, vou colocar em zzz.i2p dentro de uma hora - obrigado 16:13 <jrandom> zzz: eu não me preocuparia com isso a menos que você tenha tempo livre... eu posso ler o diff :) 16:13 <ailouros> obrigado 16:14 <zzz> jrandom, OK. Há algumas coisas diversas que podem ser facilmente retiradas por mim ou por você. 16:16 <ailouros> Acho que estamos em 5) ??? agora? 16:16 <zzz> jrandom outro tópico eram Router OOMs (Out Of Memory — falta de memória) com i2phex e possíveis problemas com SAM 16:16 <jrandom> sim, ailouros 16:16 <jrandom> ah sim, zzz, seria ótimo rastrear o que está acontecendo com o SAM 16:17 <ailouros> j346, você teve a chance de ver meu app? 16:17 <jrandom> Seria ÓTIMO se alguém pudesse assumir a manutenção da SAM bridge, pois eu não tenho feito nenhum trabalho substancial nela, e o human não aparece faz um tempo. 16:19 <jrandom> ainda não, ailouros, infelizmente. eu estava um pouco inseguro sobre como funciona, então preciso ler o código-fonte primeiro 16:20 <ailouros> sinta-se à vontade para perguntar 16:20 <ailouros> (e boa sorte na jornada pelo fonte, é uma boa definição para a palavra "bagunça") 16:20 <jrandom> hehe 16:21 <zzz> correção: minha experiência tem sido OOMs ao usar i2p-bt, não i2phex. Acontece depois de cerca de 24 horas ao rodar um i2p-bt e em poucas horas ao rodar dois i2p-bt 16:22 <+Complication> O meu aconteceu após alguns testes de estresse tarde da noite. 16:22 <+Complication> (durante os quais, diga-se, vi médias de 5 minutos de 50 KB/s) 16:22 <bar_> você poderia me lembrar o que é/faz seu app, ailouros? minha memória é boa, mas curta... 16:22 <+Complication> De entrada, isto é. 16:22 <+Complication> A saída estava limitada a 35 KB/s 16:22 <@cervantes> Complication: nunca ouvi chamarem de teste de estresse de madrugada antes... 16:22 <jrandom> legal, Complication 16:23 <+Complication> cervantes: bem, pode-se *chamar* de mega-leeching semi-diário então :P 16:23 <ailouros> bar_: é uma prova de conceito funcional de um app de compartilhamento de arquivos distribuído que compartilha blocos comuns entre arquivos diferentes (como sugerido por polecat) 16:23 <bar_> ah, certo, obrigado, ailouros 16:24 <tethra> cervantes: heheheh ;) 16:24 <ailouros> de nada (se alguém quiser pegar o fonte, está em C/C++) 16:25 <+polecat> ailouros: Cuidado, a chance de dois blocos binários serem iguais é suficientemente rara, estou falando mais de teoria pura que seria pouco útil na prática. 16:25 <ailouros> polecat, concordo. Meu melhor palpite é que isso é útil quando você obtém diferentes versões dos mesmos arquivos 16:25 <ailouros> tipo, um filme que tem um bloco corrompido 16:25 <+polecat> Você poderia transferir blocos de zeros a velocidades relâmpago! ("O próximo bloco é de zeros" "ah, eu já tenho isso" "o próximo bloco é de zeros" "ah, eu já tenho isso") 16:26 <ailouros> ou um arquivo com outros arquivos zip 16:26 <jrandom> ou, por exemplo, tags ID3 modificadas, etc. 16:26 <ailouros> exatamente 16:26 <+polecat> Verdade. Mas uma maneira fácil de "consertar" um filme com um bloco corrompido é mandar o bittorrent baixar por cima. A maioria dos clientes vai preservar os blocos cujos hashes são iguais e sobrescrever os que são diferentes. 16:26 <jrandom> porém, arquivos de arquivos provavelmente não funcionarão, já que teriam que quebrar nas fronteiras de arquivo 16:27 <ailouros> j636, é por isso que quero implementar a ideia do LBFS de dividir em marcas de dados, e não em tamanhos fixos de bloco 16:27 <@cervantes> a comunidade DC usava esse método, compartilhando distribuições de arquivos em rarsets 16:27 <+polecat> O que poderia ser útil é fazer um algoritmo geral de correção de erros binários e implementá-lo em grande escala. Todos os blocos poderiam ser "corrigidos" uns nos outros, e você só teria que transmitir os dados de correção, que podem ser menores do que transmitir o próprio bloco. 16:29 <@cervantes> e então as buscas são baseadas em hashes Tiger dessas partes RAR 16:29 <+Complication> Boa ideia... mas parece difícil :) 16:29 <+polecat> Mas apenas um equivalente hash-por-hash... você nunca encontraria dois blocos iguais! 16:29 <ailouros> cervantes, o que é um "rarset"? :D (exceto um "arquivo RAR", claro) 16:29 <+polecat> A menos que ambos os lados já tivessem o arquivo, sendo que um deles está corrompido. 16:29 <ailouros> polecat, hã? 16:29 <@cervantes> ailouros: um arquivo RAR dividido, com arquivos de paridade se necessário 16:30 <ailouros> cervantes: Não entendo a vantagem de fazer isso 16:31 <@cervantes> o principal benefício era adicionar download pseudo multi-fonte ao DC 16:32 <ailouros> bem, isso faz parte do mecanismo de compartilhamento de blocos entre arquivos, não é? 16:34 <ailouros> polecat: sobre o bittorrent sobrescrevendo arquivos danificados, o que ele não te dá é quando você tenta obter múltiplas versões ao mesmo tempo 16:35 <@cervantes> seu cliente só casa/baixa partes válidas; se você tiver arquivos de paridade, também pode recuperar partes danificadas 16:35 <ailouros> com o meu sistema não há partes danificadas (os arquivos só são montados quando os blocos que o compõem são baixados e verificados novamente) 16:36 <@cervantes> coisas que o bittorrent faz por padrão, exceto que você não pode pesquisar especificamente por partes individuais 16:36 <+polecat> Múltiplas versões não devem ter um único bit em comum... por isso são tão estúpidas. Algum sujeito decide re-encodar o filme em formato selo postal e dá o mesmo nome. 16:37 <+polecat> Ou outro sujeito pega dados aleatórios e dá o nome do arquivo que você quer baixar. 16:37 <ailouros> lol isso é verdade 16:37 <@cervantes> exatamente, e lançamentos em rarset são imunes a isso... 16:37 <ailouros> mas lembre-se de que arquivos de outras redes (emule, kazaa, etc.) frequentemente vêm corrompidos 16:38 <+polecat> lançamentos em rarset não são imunes... 16:38 <+polecat> Você ainda tem que descobrir qual rarset é o correto. 16:38 <ailouros> cervantes, como rarsets são imunes a um idiota publicando lixo aleatório? 16:38 <@cervantes> (desde que você tenha uma fonte confiável) 16:39 <@cervantes> porque um grupo de release publica hashes/informações de distribuição 16:39 <ailouros> hahaha isso é fácil :D 16:39 <@cervantes> e coisas são marcadas como nuked se forem de baixa qualidade, o pessoal remove dos compartilhamentos 16:40 <ailouros> cervantes, isso meu brinquedo já faz 16:40 <@cervantes> legal 16:40 <ailouros> você pega o descritor do arquivo de uma fonte confiável, você faz multiget do arquivo e pronto 16:41 <@cervantes> parece bom ;-) 16:41 <ailouros> você não consegue pesquisar por arquivos, mas pode navegar pelo diretório compartilhado de cada usuário, então você pode usar um web crawler e cachear os resultados 16:42 <ailouros> embora eu possa adicionar uma função de busca no futuro, se for necessário 16:44 <ailouros> Acredito que meu brinquedo, devidamente desenvolvido em um app, pode oferecer o cache e a resiliência que o pessoal do freenet tenta oferecer 16:44 <ailouros> isto é, distribuição e cache de conteúdo estático 16:45 <ailouros> você lê meu blog, faz cache e oferece para outras pessoas quando elas quiserem. você não faz nada mais além de deixar o conteúdo lá 16:45 <ailouros> não gostou do conteúdo? apague e pronto 16:45 <jrandom> hmm, então você o vê como um backing store que poderia ser usado para o syndie? 16:46 <ailouros> ele PODE ser usado como um backing store 16:46 <ailouros> como está agora, você poderia até usá-lo no lugar do Jetty, nas instalações padrão do i2p 16:46 <jrandom> ex.: anexos / links para [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (bem, com algumas pequenas mudanças :D ) 16:46 <jrandom> heh 16:47 <jrandom> ok, sim, eu definitivamente não entendo como o clunk funciona... quer postar sobre isso no syndie, ou colocar um eepsite? :) 16:47 <ailouros> os hashes de arquivo são baixados no pedido do arquivo, e esses hashes são automaticamente baixados até virar o arquivo completo 16:48 <jrandom> certo, mas "down"loaded é uma questão de de onde para onde, etc. uma descrição geral da arquitetura da rede seria útil 16:48 <ailouros> Vou escrever uma documentação decente primeiro, depois publico em algum lugar 16:48 <jrandom> r0x0r, valeu 16:48 <ailouros> baixado de onde quer que você tenha obtido o hash 16:48 <ailouros> mais todo mundo que estiver compartilhando esses blocos 16:49 <ailouros> pense no Go!Zilla e no Download Accelerator :) 16:49 <jrandom> Acho que você não entendeu o quanto estou confuso 16:49 <ailouros> mas transparente e dentro do i2p 16:49 <ailouros> lol acho que sim :D 16:50 <jrandom> uma explicação muito, muito básica do tipo "você roda um cliente clunk, baixa de um servidor clunk, obtém info sobre peers clunk", etc 16:50 <jrandom> eu uso um navegador web para consultar um cliente clunk? ou servidor? ou peer? 16:51 <jrandom> (é o quanto estou perdido) 16:51 <ailouros> refazer do 0 :) 16:51 <ailouros> você usa seu navegador web 16:51 <ailouros> você se conecta ao seu cliente 16:51 <ailouros> você navega pelo dir dos outros com o seu navegador 16:51 <ailouros> você seleciona quais arquivos baixar com seu navegador 16:51 <ailouros> seu cliente faz o trabalho sujo 16:52 <ailouros> você recebe o arquivo baixado de volta 16:52 <ailouros> assim fica melhor? :) 16:52 <jrandom> ok, ótimo, obrigado - então o "navegar no dir do outro" é feito pelo seu cliente consultando o cliente deles e respondendo com uma representação HTML disso 16:52 <ailouros> exatamente 16:52 <jrandom> (ou puxado de algum servidor/superpeer/etc) 16:53 <jrandom> show 16:53 <ailouros> todo o trabalho sujo (encontrar duplicatas, multidownloads e por aí vai) é feito pelo seu cliente (local) de forma transparente 16:54 <ailouros> o que você vê é, basicamente, uma árvore de diretórios e alguns arquivos que pode baixar 16:54 <jrandom> legal 16:55 <ailouros> para publicar seus dados você fornece seu endereço público (p2p) 16:55 <ailouros> e para compartilhar arquivos você os copia (ou faz symlink) para o diretório pub/ (ou algum subdir). É simples assim 16:57 * jrandom vai fuçar mais no fonte e aguarda mais informações :) 16:57 <jrandom> ok, mais alguém tem algo para a reunião? 16:57 <bar_> hmm.. qual é a diferença entre publicar e compartilhar, se posso perguntar? publicar envia (push) os dados para algum datastore? 16:58 <ailouros> bar_: compartilhar é disponibilizar os blocos para download. publicar é deixar o mundo saber o que você compartilha 16:58 <ailouros> publicar é um subconjunto de compartilhar 16:58 <bar_> aha, entendi, obrigado 16:58 <ailouros> por exemplo, se você tem metade de um arquivo, você o compartilha mas não publica 16:59 <jrandom> como as pessoas saberiam que poderiam obter esses blocos de você então? 16:59 <ailouros> e você tem controle total sobre quais arquivos publica (diferente do emule, onde todo arquivo baixado é publicado) 16:59 <ailouros> porque cada cliente envia periodicamente informações para a rede sobre quais blocos ele tem para oferecer 17:00 <jrandom> show 17:00 <ailouros> envia para a rede, como em servidor (como é agora) ou DHT (futuro) 17:00 <jrandom> então é mnet-esco, com um rastreador de blocos 17:00 <ailouros> err mnet-esco? 17:01 <jrandom> similar a como o mnet (mnetproject.org) funciona 17:01 * ailouros está lendo mnetproject.org 17:02 <ailouros> bem, você tem apenas seus espaços pessoais, sem espaços compartilhados 17:02 <ailouros> e você não dá PUSH nos blocos por aí 17:02 <jrandom> sim, não é exatamente como o mnet, mas é semelhante estruturalmente 17:03 <jrandom> é como o mnet onde todo mundo está quebrado demais para ter alguém hospedando seus dados ;) 17:03 <ailouros> sim 17:03 <ailouros> :D 17:03 <jrandom> ok, mais alguém tem mais algo para levantar? 17:04 <jrandom> se não... 17:04 * jrandom se apronta 17:04 * jrandom *baf*a a reunião encerrada