Reunião de Desenvolvedores do I2P - 01 de agosto de 2006

16:02 <jrandom> ok, vamos colocar isso para andar 16:03 <jrandom> oi, notas pré-reunião publicadas em http://dev.i2p.net/pipermail/i2p/2006-August/001304.html 16:03 <jrandom> em vez de eu basicamente reler aquela mensagem para vocês aqui, vamos pular para nossa seção padrão ??? - 16:04 <jrandom> alguém tem algo que queira levantar e discutir? 16:04 <@cervantes> eerm 16:04 * cervantes corre para ler o post 16:05 <+Complication> Quanto ao status da rede, tudo bem por aqui... 16:05 <+Complication> Mas uma pergunta (na verdade repassando do fórum) sobre o transporte NTCP, 16:06 <+Complication> parece provável que ativá-lo possa causar a alguém problemas de carga de CPU (eles estavam no XP)? 16:06 <@cervantes> Tenho que dizer que na verdade venho vendo menor uso de CPU desde que mudei :) 16:07 <jrandom> bem, você não pode *desativá-lo* (a menos que tenha lido o código-fonte e saiba o encantamento mágico ;) 16:07 <+Complication> A pessoa que falou desse problema (não é fácil reproduzir, e aqui não há grande uso de CPU) mencionou que a experiência de alto uso de CPU parecia ter correlação com NTCP 16:07 <jrandom> então, presumo que queriam dizer não aceitar conexões ntcp de entrada 16:07 <+polecat> NTCP faz meu router imediatamente 'clockar' a CPU, e repeti isso duas vezes antes de precisar alterar manualmente o arquivo de configuração para ter um router funcionando de novo. 16:07 <jrandom> (enquanto ainda usa conexões ntcp de saída) 16:07 <+Complication> (aqui está só um tiquinho acima dos níveis usuais, e provavelmente porque está bombeando *bem* mais dados) 16:08 <+Complication> ( http://forum.i2p/viewtopic.php?t=1815 ) 16:08 <jrandom> quando você estabelece uma conexão ntcp, você faz um cálculo criptográfico pesado (ou três) 16:08 <jrandom> se você estiver aceitando conexões ntcp de entrada, pode receber muitas tentativas de entrada de uma vez, já que há centenas de routers I2P por aí 16:09 <jrandom> polecat: isso não foi culpa do ntcp, foi culpa de um servidor NTP ruim no pool de NTP 16:09 <+polecat> Sim. Então eu não consigo lidar com isso sozinho, ao que parece. 16:09 <jrandom> (obrigado ao cervantes por rastrear aquele servidor NTP e fazer o pessoal do pool dar um !thwap neles :) 16:10 <jrandom> ((e ao Complication por fazer com que evitemos aqueles malucos no futuro :)) 16:10 <@cervantes> heh acho que os watchdogs do servidor deles só funcionam em dias úteis ;-) 16:10 <+Complication> Bem, a evasão atual é bem limitada 16:10 <@cervantes> http://www.pool.ntp.org/scores/216.52.237.153 16:11 <+Complication> Espero eventualmente codificar algo mais paranoico 16:11 <+polecat> Ah, então habilitar NTCP não vai mais 'clockar' a CPU? 16:11 <jrandom> (nunca fez isso, polecat, foi coincidência ;) 16:12 <+Complication> "clock" em que sentido exatamente? 16:12 <jrandom> (veja o link do cervantes) 16:12 * polecat acerta o Complication na cabeça. 16:12 <@cervantes> o que você tá fumando, polecat 16:12 <+Complication> :P 16:12 <+polecat> Er, quero dizer, roubou todos os ciclos de clock. :) 16:13 <+Complication> Se ele pulou 30 segundos para frente ou para trás, pode ter perdido muitas, muitas sessões e recorrido a todo tipo de criptografia pesada, pesada 16:13 <+Complication> Acho que isso poderia roubar muitos ciclos de CPU 16:13 <+Complication> De fato, talvez a pessoa no fórum tenha visto a mesma coisa e correlacionado errado? Temos que perguntar... 16:13 <jrandom> ah.. bem, rajadas de conexões ntcp válidas de entrada vão causar rajadas de CPU, enquanto ntcp somente de saída vai tentar falar com apenas tantos novos peers ntcp por vez 16:14 <jrandom> não há nada de errado em não habilitar ntcp de entrada. 16:15 <@cervantes> Complication: o servidor foi corrigido no meio da segunda-feira, então pode valer ver se tiveram problemas desde então 16:15 <jrandom> ok, mais alguém tem algo que queira discutir? 16:16 <+Complication> cervantes: de fato, pode valer tentar 16:16 <@cervantes> Recebi relatos de algumas pessoas ainda perdendo leases periodicamente... isso é um problema conhecido? 16:16 <+void> o quanto a implementação de ntcp difere de ssu? 16:17 <+polecat> Como sabemos se perdemos leases? 16:18 <jrandom> void: há uma sobrecarga por mensagem de largura de banda um pouco maior no ntcp (embora talvez compensada pela implementação de transmissão confiável provavelmente mais eficiente do SO) 16:18 <+Complication> polecat: o tunnels.jsp vai mostrar nenhum tunnel para um determinado pool de tunnel (por exemplo, "shared clients") 16:18 <jrandom> cervantes: sim, nossas taxas de sucesso na construção de tunnel ainda não estão onde precisam estar 16:18 <+void> polecat: o console do router diz isso 16:18 <+Complication> E como o void disse, a barra lateral esquerda do console vai indicar isso 16:19 <+polecat> Eu recebo bastante aquelas mensagens "No leases"... é disso que você está falando, né? 16:19 <@cervantes> sim 16:20 <+polecat> Isso geralmente é o que mata minha conexão de IRC. Achava que era normal! 16:21 * jrandom se encolhe 16:24 <+tethra> lol ;) 16:25 <jrandom> ok, alguém tem mais algo para a reunião? 16:25 <@cervantes> jrandom: você fez algum progresso no syndie ultimamente ou ficou com as mãos cheias com ntcp/correção de bugs/caça a ISP/pedalada ? 16:27 <+tethra> alguma novidade sobre feedspace, ou devo simplesmente ir ao eepsite deles? 16:28 <jrandom> quando a rede ao vivo foi pro ralo eu deixei o syndie de lado. mas com a rede voltando aos trilhos, o syndie vem retomando meu tempo, e espero ter um pequeno sistema de cli em breve (com guis focadas vindo depois disso, com base no feedback dos usuários) 16:28 <jrandom> (a swt gui implementada está em forma bem boa, mas provavelmente é melhor começar com a cli para ajustar expectativas) 16:29 * jrandom não ouviu nenhuma novidade sobre feedspace 16:29 <@cervantes> legal 16:29 <jrandom> frosk: alguma novidade? :) 16:29 <+polecat> Fico feliz que você esteja trabalhando no syndie de novo. A nova versão parece bem promissora. Any thoughts on ACL for stuff such as deleting blogs from a node, or doing administrative account-independant tasks? 16:30 <@cervantes> <jrandom> DELETE FROM messages WHERE postedOn <NOW()-14*24*60*60; 16:31 <jrandom> arquivos locais provavelmente continuarão essencialmente confiáveis (já que, se você pode acessar o banco de dados do arquivo local, pode alterar o arquivo como quiser) 16:32 <jrandom> porém, para blogs compartilhados, sim, há todo um conjunto de estruturas criptográficas para autenticar e/ou autorizar postagens e alterações 16:33 <jrandom> (mas também haverá uma forma de as pessoas verem postagens 'não autorizadas', porém elas ficarão bem à margem) 16:33 <+polecat> Tenho certeza de que, assim que alguém inundar as sindicações com milhares de posts gigantes de blog, a técnica para excluir fisicamente posts será aperfeiçoada. 16:34 <+tethra> heheh 16:35 <jrandom> exclusão física é trivial, a questão é quais posts aceitar em primeiro lugar ;) 16:36 <jrandom> (não tenho interesse em transformar o syndie em uma plataforma de distribuição de filmes, etc) 16:36 <+polecat> Não se pode ter certeza do que se está aceitando até que uma amostra tenha sido aceita. Imagino algo como permitir apenas uma whitelist de blogs e permitir novos IDs em caráter experimental antes de adicioná-los, apagando instantaneamente no caso de traição por spam. 16:36 <jrandom> sim 16:37 <+polecat> Estou mais interessado na aplicação para juntar fluxos de conversa: poderíamos fazer um BBS sem servidor central, apenas uma tag em comum! 16:37 <jrandom> (permitindo novos ids manualmente, dando kickban manualmente em ids que floodam, etc) 16:37 <jrandom> há até suporte inerente para isso na cripto, polecat :) 16:37 <+polecat> Possivelmente um moderador assinando as mensagens aprovadas para o BBS, e as pessoas coletando essas listas de aprovação no blog do moderador. 16:38 <+polecat> Ooh excelente. 16:38 <@frosk> jrandom: tenho trabalhado em coisas de gui ultimamente, mas tem sido difícil combinar com o início de um emprego novo :( 16:39 * cervantes contata o RH para fazer o frosk ser demitido 16:40 <jrandom> ah legal, com sorte quando o syndie estiver por aí empurrando uma sindicação http improvisada vamos te tentar nisso de novo ;) 16:40 <@frosk> pelo menos meu chefe acompanha o desenvolvimento do i2p agora :) 16:40 * jrandom acena para o chefe do frosk 16:40 <@frosk> ah sim, ainda estou determinado (droga!) :) 16:40 <jrandom> (dá mais tempo livre para o frosk, precisamos dele!) 16:41 <@cervantes> com sorte ele não vai ler sobre como você tem postado informações confidenciais da empresa no seu blog do syndie 16:41 <bar> gui é bom, gostamos de gui. você está perdoado. 16:41 <+Complication> Hehe :) 16:41 <@frosk> é esquisito entrar no escritório dele e pegar ele lendo syndie :) 16:41 <jrandom> hah fantástico 16:42 <+polecat> Parabéns, frosk, mesmo que você seja demitido com vergonha e infâmia, pelo menos você mostrou para mais uma pessoa como o syndie pode ser legal. 16:43 <@frosk> hehe é 16:43 <+tethra> haha 16:44 <@frosk> a gui (em swt) é/será um testbed para tudo do feedspace, para dar o pontapé inicial 16:44 <jrandom> r0x0r 16:45 <+void> jrandom: talvez você devesse cross-postar tudo que vai para as listas de e-mail no syndie também? 16:45 <jrandom> deveríamos totalmente integrá-lo com a swt gui do syndie (o paradigma básico é um navegador, embora não exibindo páginas html nas abas) 16:46 <+polecat> Seria legal. Eu não consigo mais receber a lista de e-mails. 16:46 <jrandom> void: seria bem fácil alguém escrever um pequeno shell script para fazer pipe do procmail para a CLI do syndie 16:46 <@cervantes> essas swt gui chiques estão ligadas aos aplicativos? ou são tops para executáveis de cli ou usam tcp etc etc 16:46 <@frosk> faz sentido 16:46 <jrandom> (se não me engano há um post no meu blog um tempo atrás explicando como usar a cli do syndie para inserir posts) 16:47 <+polecat> Atualmente dá para fazer feeds RSS para alimentar o syndie, embora ainda seja meio gambiarra. 16:47 <jrandom> cervantes: jdbc nos manipuladores de eventos, inline com chamadas jni e msvc, claro ;) 16:47 * jrandom se abaixa 16:48 <+polecat> Microsoft Visual Classes? 16:49 <@cervantes> jrandom: então qualquer coisa que fale SQL pode administrar o syndie então 16:49 <jrandom> (do ponto de vista do syndie, toda a funcionalidade é basicamente implementada em vários pequenos apps de cli que apenas atualizam o banco de dados jdbc, e há uma swt ui para navegar pelo db) 16:51 <+polecat> E como o banco de dados tem duas interfaces, JDBC e SQL, um cliente que se comunique por qualquer um dos protocolos pode bagunçar o syndie. 16:51 <jrandom> cervantes: bem, sim e não - há uma boa parte do banco de dados que é criptografada, então nem todos os campos são legíveis 16:51 <+void> a interface web atual ainda vai estar lá? 16:51 <jrandom> (jdbc == sql) 16:51 <jrandom> void: não 16:51 <+polecat> Achei que você tinha dito que JDBC não era um protocolo legível por humanos estúpidos? 16:51 <+Complication> jdbc == java database interface, talvez um pouco similar ao odbc 16:51 <jrandom> ((jdbc ~= sql)) 16:51 <+Complication> Algo sobre o qual você fala SQL 16:52 <+void> jrandom: o que vai acontecer com syndie.i2p/syndiemedia.i2p.net? 16:52 <+polecat> Ah. Bom, nunca gostei de SQL mesmo, para constar. 16:52 <@cervantes> jrandom: então é melhor criar um top para syndieTools (tm) do que tentar sugar os dados você mesmo 16:53 <jrandom> void: o tempo dirá. provavelmente eles 1) vão servir como o website/eepsite do syndie, 2) servir como um arquivo público de posts para sindicar, e eventualmente, quando uma interface web for escrita, 3) oferecer uma interface web 16:53 <+polecat> Por que não enviar bytecode como consultas de banco de dados, em vez de declarações COBOL arcaicas? 16:53 <jrandom> sim, cervantes 16:53 <jrandom> !lart polecat 16:54 <+void> hehehe 16:54 <+polecat> Ah, minha fraqueza secreta. 16:54 <@cervantes> * você tem 6 larts restantes no seu inventário, há uma porta ao norte e um polecat inconsciente no chão 16:54 <jrandom> cervantes: isso na verdade é o app de cli nº 3 (extrair posts individuais, que vem depois do app nº 2, listar posts individuais (depois do nº 1, criar posts individuais, e depois do nº 0, gerenciar nyms))) 16:54 <jrandom> lol 16:54 <+tethra> haha 16:55 <+Complication> proposta de feature: em vez de bytecode, por que não enviar agentes vivos da $agency como consultas de banco de dados? ;P 16:56 <+Complication> Seria bem mais fácil validar a segurança :P 16:56 <@cervantes> jrandom: entendido 16:56 <+tethra> eles agem como pombos-correio no clima certo, Complication? 16:56 <+Complication> tethra: só se você conseguir empurrá-los intactos pela pilha TCP :P 16:56 <+polecat> Sim, consultas de banco de dados sobre CPP! 16:57 <+Complication> Imagino que ficarem amassados no TCP possa corrompê-los 16:58 <+Complication> (desculpem, eu devia realmente manter as piadas no #i2p-chat, mas às vezes não dá) 16:58 * cervantes sente que um baff se aproxima 16:58 <+Complication> consultas de banco de dados como shellcode? 16:59 <jrandom> ok, alguém tem mais algo para a reunião? 16:59 <+polecat> http://www.blug.linux.no/rfc1149/ <- poderíamos fazer tunnel de i2p sobre isso, sério. 16:59 * Complication prefere ficar com SQL 17:00 <+void> jrandom: outras linguagens além de java têm bibliotecas para bancos de dados hsqldb? 17:01 <+Complication> Oo provavelmente tem, já que eles parecem usar isso 17:01 <+void> pra mim parece que é "não" 17:01 <+void> oh, hmm 17:01 <@cervantes> o openoffice usa, então eu diria que sim 17:01 <+Complication> Mas não tenho certeza em que o OpenOffice é escrito 17:01 <jrandom> não que eu saiba. mas alguém poderia rodar o syndie contra outro banco de dados jdbc (mysql, oracle, etc) 17:01 <jrandom> oo usa java 17:02 <+void> exatamente para que o openoffice usa esse banco de dados? 17:02 <+Complication> Mas parece usá-lo apenas parcialmente 17:02 <jrandom> void: para geração de PDF e para o aplicativo de banco de dados semelhante ao Access deles 17:02 <jrandom> (entre outras coisas) 17:02 <+Complication> Dado que ele recomenda um JRE externo 17:02 <+void> ok 17:03 <+void> é um pé no saco escrever SQL portátil, porém 17:03 <+Complication> se não se usa triggers ou stored procedures, não deveria ser um grande problema, porém 17:04 <jrandom> eh, não é tão ruim assim, e é fácil de externalizar 17:04 <+void> especialmente quando se mira oracle ;) 17:05 <jrandom> na verdade, hsqldb suporta pl/sql ;) 17:06 <bar> há outros planos para esse banco de dados, como para estatísticas, perfis de pares, netdb..? 17:06 <jrandom> não, isto é só para o syndie 17:06 <bar> ok 17:07 <jrandom> (embora, quando entregarmos o código do hsqldb, possamos usá-lo no i2p 'de graça') 17:07 <@cervantes> já que syndie não é um aplicativo I2P, apenas um aplicativo que pode rodar sobre I2P, correto? 17:07 <jrandom> sim, cervantes, não há dependência do i2p 17:07 <+Complication> Bom manter o Syndie portátil, já que ele pode ter outros transportes além de I2P 17:07 <bar> certo 17:08 <+Complication> Por outro lado, imagino que não seria difícil rodar muitas instâncias de hsqldb na mesma máquina 17:08 <+Complication> Então, se outros apps precisassem, parece que poderiam simplesmente usá-lo 17:08 <jrandom> trivial, e custo zero se você simplesmente usar o banco de dados in-jvm 17:08 <+Complication> (usar a própria instância, de preferência) 17:10 <+void> não há driver jdbc para sqlite? 17:11 <jrandom> não sei, nunca usei 17:11 <+void> ah, parece que existe *algo* 17:13 <jrandom> ok, mais alguma coisa para a reunião? 17:13 <jrandom> se não... 17:13 * jrandom se apronta 17:13 * jrandom dá um passo para trás 17:13 * jrandom arma o golpe 17:13 * jrandom *baf*s a reunião encerrada