Reunião de desenvolvedores do I2P - 30 de maio de 2006

16:00 <jrandom> 0) oi 16:00 <jrandom> 1) Status da rede 16:00 <jrandom> 2) Filtragem de pares 16:00 <jrandom> 3) Status do Syndie 16:00 <jrandom> 4) ??? 16:00 <jrandom> 0) oi 16:00 * jrandom acena 16:01 <jrandom> notas semanais de status publicadas em @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html 16:01 <jrandom> (com até uma hora de antecedência [ou algumas semanas de atraso, se quiserem pegar no meu pé ;]) 16:02 <jrandom> ok, vamos pular para 1) Status da rede 16:02 <jrandom> as coisas não estão como deveriam estar. estão melhores do que durante o colapso por congestão, mas deveriam estar melhores do que estão agora 16:03 <jrandom> não tenho muito mais a acrescentar sobre isso, a menos que alguém tenha alguma pergunta/preocupação sobre 1)? 16:03 <@frosk> eu consigo ficar dias conectado no IRC com a .19, então sem reclamações aqui 16:04 <jrandom> legal 16:04 <jrandom> é, está bom para alguns, só não é bom o suficiente nem consistente o suficiente. as estatísticas no db também não estão com uma cara muito boa 16:06 <jrandom> ok, alguém tem mais algo sobre 1) Status da rede, ou vamos passar para 2) Filtragem de pares? 16:07 <jrandom> [insira aqui sons de mudança] 16:09 <jrandom> como mencionado no e-mail, a ideia é dar um impulso à nossa seleção de pares. no começo, será um pouco perigoso, permitindo alguns ataques de particionamento ativos, mas se funcionar como espero, podemos evitá-los 16:10 <jrandom> (mas evitá-lo exige essencialmente matar todas as identidades do router, o que basicamente serviria como um reset da rede; então eu gostaria de evitar isso, a menos que valha a pena) 16:11 <bar> resetá-las uma vez ou repetidamente? 16:11 <bar> s/reset/killing 16:11 <jrandom> pelo menos uma vez, mas também em todas as mudanças drásticas de configuração subsequentes 16:12 <jrandom> (vulgo colocar algum critério no certificado da identidade do router, o que por sua vez significa mudar o hash da identidade, para que não possam fingir enviar uma configuração para algumas pessoas e outra para outras) 16:13 <bar> saquei 16:14 <jrandom> ok, acho que não tenho mais nada sobre esse tópico no momento, a menos que alguém tenha perguntas/comentários/preocupações? 16:15 <jrandom> (com sorte haverá um build nos próximos um ou dois dias, lançamento depois que estabilizar) 16:17 <jrandom> ok, passando pelo 3) rapidamente.. 16:18 <jrandom> o Syndie está avançando e, embora a batalha amd64/amd32/x86/swt/gcj nem sempre tenha sido bonita, teremos um build pronto em junho 16:19 <jrandom> (mas ainda não falem comigo sobre mingw/gcj ;) 16:19 <jrandom> não tenho muito mais a acrescentar por enquanto, a menos que alguém tenha perguntas/preocupações sobre a reformulação do Syndie? 16:21 <@cervantes> como está o suporte a mingw/gcj? 16:21 <@cervantes> *abaixa-se* 16:22 <@cervantes> vamos ter algumas capturas de tela antes do lançamento de junho? :) 16:23 <jrandom> com certeza vou tentar recrutar alguns voluntários empolgados para testes pré-lançamento ;) 16:23 <tethrar> pode me incluir ;) 16:23 <jrandom> w3wt 16:24 <jrandom> ok, vamos passar para o tópico pelo qual sei que vocês estavam esperando: 4) ??? 16:24 <jrandom> wazaaaap? 16:24 <green> Há algum plano para ter um I2P router "de verdade" funcionando com Via C7? jbigi dá apenas 30% a mais do que Java puro 16:25 <jrandom> 30% ainda é muito intensivo em CPU? o que o torna não "de verdade"? 16:25 <jrandom> mas não, eu não tenho a matemática nem a habilidade em asm do C7 para fazer um libGMP melhor para o C7. 16:25 <green> claro que é intensivo em CPU com 100% de carga de CPU :P 16:26 <jrandom> 100% de carga de CPU sugere que o problema não é o jbigi, mas o fato de que o jbigi precisa ser usado demais 16:26 <jrandom> e para isso, sim, temos muitas coisas a caminho. 16:26 <jrandom> (por exemplo, reduzindo os restabelecimentos de conexão, melhorando as taxas de sucesso na construção de tunnel, etc.) 16:27 <jrandom> ((e não receber tantas solicitações de tunnel se o router não for capaz de lidar com elas)) 16:29 <green> humm, isso é com uma máquina dedicada com 100Mb/s, então deveria dar conta 16:30 <jrandom> não, largura de banda não é o único recurso limitado aqui; CPU obviamente é ;) 16:33 <jrandom> ok, mais alguém tem algo para a reunião? 16:36 <jrandom> *cof* 16:37 * jrandom se prepara 16:37 * jrandom *baf* encerra a reunião