Setkání vývojářů I2P - 1. srpna 2006

16:02 <jrandom> ok, můžeme to rovnou rozjet 16:03 <jrandom> ahoj, předběžné poznámky před schůzkou jsou na http://dev.i2p.net/pipermail/i2p/2006-August/001304.html 16:03 <jrandom> abych to tady nemusel v podstatě celé předčítat, přeskočme rovnou k naší standardní ??? části - 16:04 <jrandom> má někdo něco, co chce otevřít a probrat? 16:04 <@cervantes> ehm 16:04 * cervantes se rychle vrhá na čtení příspěvku 16:05 <+Complication> Co se týče stavu sítě, tady je všechno v pořádku... 16:05 <+Complication> Ale jedna otázka (přeposílám z fóra) ohledně NTCP transportu, 16:06 <+Complication> totiž zda je pravděpodobné, že jeho zapnutí může někomu způsobit problémy se zatížením CPU (byli na XP)? 16:06 <@cervantes> Musím říct, že po přechodu naopak vidím nižší využití CPU :) 16:07 <jrandom> no, vypnout ho nemůžete (leda že byste četli zdrojový kód a znali kouzelné zaklínadlo ;) 16:07 <+Complication> Dotyčný zmínil, že jeho zkušenost s vysokým využitím CPU zdánlivě korelovala s NTCP 16:07 <jrandom> takže předpokládám, že tím myslí nepřijímání příchozích ntcp spojení 16:07 <+polecat> NTCP způsobí, že můj router okamžitě vytočí CPU na maximum, a stalo se mi to dvakrát, než jsem musel ručně upravit konfigurační soubor, abych zase rozběhl router. 16:07 <jrandom> (při současném používání odchozích ntcp spojení) 16:07 <+Complication> (tady je to jen nepatrně víc než obvykle, což bude nejspíš tím, že pumpuju *mnohem* víc dat) 16:08 <+Complication> ( http://forum.i2p/viewtopic.php?t=1815 ) 16:08 <jrandom> když navazujete ntcp spojení, děláte náročný kryptografický výpočet (nebo tři) 16:08 <jrandom> pokud přijímáte příchozí ntcp spojení, můžete dostat spoustu pokusů najednou, protože tam venku jsou stovky I2P routerů 16:09 <jrandom> polecat: to nebyla chyba ntcp, ale špatného NTP serveru v NTP poolu 16:09 <+polecat> Ano. Takže to zjevně sám neovlivním. 16:09 <jrandom> (díky cervantesovi za dohledání toho NTP serveru a přimění lidí z poolu, aby je !thwap 'nuli :) 16:10 <jrandom> ((a Complication za to, že zařídil, abychom se těmhle šílencům do budoucna vyhnuli :)) 16:10 <@cervantes> heh myslím, že jejich serverové watchdogy fungují jen ve všední dny ;-) 16:10 <+Complication> No, současný mechanismus vyhýbání je dost omezený 16:10 <@cervantes> http://www.pool.ntp.org/scores/216.52.237.153 16:11 <+Complication> Doufám, že časem naprogramuju něco paranoidnějšího 16:11 <+polecat> Aha, takže zapnutí NTCP už nebude vytáčet CPU na doraz? 16:11 <jrandom> (ono to nikdy nedělalo, polecat, byla to náhoda ;) 16:12 <+Complication> „clock“ v jakém přesném smyslu? 16:12 <jrandom> (viz odkaz od cervantese) 16:12 * polecat vrazí Complicationovi pohlavek. 16:12 <@cervantes> co to hulíš, polecate 16:12 <+Complication> :P 16:12 <+polecat> Ehm, myslím, že sežral všechny taktovací cykly. :) 16:13 <+Complication> Pokud hodiny skočily o 30 sekund dopředu nebo dozadu, mohlo to ztratit spoustu relací a sáhnout ke všemožné velmi, velmi náročné kryptografii 16:13 <+Complication> To by podle mě mohlo sebrat spoustu CPU cyklů 16:13 <+Complication> Možná ten člověk na fóru viděl totéž a špatně si to spojil s NTCP? Musím se zeptat... 16:13 <jrandom> aha.. no, nárazové vlny validních příchozích ntcp spojení způsobí špičky CPU, zatímco outbound-only ntcp se najednou pokusí mluvit jen s omezeným počtem nových ntcp peerů 16:14 <jrandom> není nic špatného na tom nepovolovat příchozí ntcp. 16:15 <@cervantes> Complication: server byl opraven v pondělí uprostřed dne, takže by stálo za to zjistit, jestli od té doby měli problémy 16:15 <jrandom> ok, má ještě někdo něco k probrání? 16:16 <+Complication> cervantes: jasně, stálo by to za zkoušku 16:16 <@cervantes> Dostal jsem hlášení, že některým lidem se pořád periodicky ztrácejí leases (záznamy o dostupnosti tunelů v leaseSetu)... je to známý problém? 16:16 <+void> jak moc se implementace ntcp liší od ssu? 16:17 <+polecat> Jak poznáme, že přicházíme o leases? 16:18 <jrandom> void: v ntcp je o něco vyšší režie na zprávu co do šířky pásma (i když to může vyvážit pravděpodobně efektivnější implementace spolehlivého přenosu v OS) 16:18 <+Complication> polecat: na tunnels.jsp neuvidíš žádné tunnel pro konkrétní tunnel pool (např. „shared clients“) 16:18 <jrandom> cervantes: jo, naše úspěšnost stavby tunnel pořád není tam, kde by měla být 16:18 <+void> polecat: router console to říká 16:18 <+Complication> A jak říká void, levý postranní panel konzole to také ukáže 16:19 <+polecat> Dostávám ty zprávy „No leases“ docela často... to máš na mysli, že? 16:19 <@cervantes> jj 16:20 <+polecat> To mi obvykle zabije moje IRC spojení. Myslel jsem, že je to normální! 16:21 * jrandom se otřese 16:24 <+tethra> lol ;) 16:25 <jrandom> ok, má někdo ještě něco k tomuhle meetingu? 16:25 <@cervantes> jrandom: udělal jsi poslední dobou nějaký pokrok na syndie, nebo jsi měl plné ruce práce s ntcp/bugfixingem/sháněním ISP/kolařením ? 16:27 <+tethra> nějaké novinky o feedspace, nebo mám prostě jít na jejich eepsite? 16:28 <jrandom> když se živá síť podělala, odsunul jsem syndie stranou. ale jak se síť zase vrací do normálu, syndie si zpátky bere můj čas a doufám, že brzy vydám malý CLI systém (a poté přijdou cílená GUI, podle zpětné vazby uživatelů) 16:28 <jrandom> (implementované SWT GUI je v docela dobrém stavu, ale asi bude lepší začít s CLI, aby se srovnala očekávání) 16:29 * jrandom nemá žádné novinky o feedspace 16:29 <@cervantes> super 16:29 <jrandom> frosk: nějaké zprávy? :) 16:29 <+polecat> Jsem rád, že znovu pracuješ na syndie. Nová verze zní slibně. Nějaké nápady na ACL pro věci jako mazání blogů z uzlu nebo provádění administrativních úloh nezávislých na účtu? 16:30 <@cervantes> <jrandom> DELETE FROM messages WHERE postedOn <NOW()-14*24*60*60; 16:31 <jrandom> lokální archivy pravděpodobně zůstanou v zásadě důvěryhodné (protože když se dostaneš k lokální databázi archivu, můžeš ten soubor měnit, jak chceš) 16:32 <jrandom> ale u sdílených blogů je k dispozici celá sada kryptografických struktur pro autentizaci a/nebo autorizaci příspěvků a změn 16:33 <jrandom> (ale bude i způsob, jak zobrazit „unauthorized“ příspěvky, jen budou hodně mimo hlavní proud) 16:33 <+polecat> Jsem si jistý, že jakmile někdo zaplaví syndikáty tisíci obřích blogpostů, technika fyzického mazání příspěvků se zdokonalí. 16:34 <+tethra> heheh 16:35 <jrandom> fyzické smazání je triviální, otázka je, jaké příspěvky přijímat už na začátku ;) 16:36 <jrandom> (nemám zájem dělat ze syndie platformu pro distribuci filmů apod.) 16:36 <+polecat> Člověk si nemůže být jistý, co přijímá, dokud nepřijme vzorek. Představuju si něco jako povolovat jen whitelist blogů a nové ID přijímat zkušebně, než je přidáte natrvalo, s okamžitým smazáním při spamové zradě. 16:36 <jrandom> jo 16:37 <+polecat> Více mě zajímá použití pro pospojování vláken konverzací: mohli bychom udělat BBS bez centrálního serveru, jen se společným tagem! 16:37 <jrandom> (ručně povolovat nová ID, ručně kickbanovat ID, která floodí, atd.) 16:37 <jrandom> na to je dokonce inherentní podpora v kryptu, polecate :) 16:37 <+polecat> Možná moderátor podepisující schválené zprávy pro BBS a lidé by si stahovali seznamy schválení z moderátorova blogu. 16:38 <+polecat> Ó, skvělé. 16:38 <@frosk> jrandom: poslední dobou dělám na GUI věcech, ale těžko se to kombinuje s nástupem do nové práce :( 16:39 * cervantes kontaktuje HR, aby froska vyhodili 16:40 <jrandom> ah super, doufejme, že až syndie začne tlačit zbastlenou HTTP syndikaci, zase tě to k tomu naláká ;) 16:40 <@frosk> aspoň můj šéf teď sleduje vývoj i2p :) 16:40 * jrandom mává šéfovi froska 16:40 <@frosk> jo, pořád jsem odhodlaný (sakra!) :) 16:40 <jrandom> (dejme froskovi víc volna, potřebujeme ho!) 16:41 <@cervantes> snad si nepřečte, jak jsi dával utajované firemní informace na svůj syndie blog 16:41 <bar> GUI je dobré, máme rádi GUI. Jsi omilostněn. 16:41 <+Complication> Hehe :) 16:41 <@frosk> je zvláštní přijít do jeho kanceláře a načapat ho, jak čte syndie :) 16:41 <jrandom> hah parádní 16:42 <+polecat> Gratuluju, frosku, i kdybys byl potupně vyhozen, aspoň jsi ukázal dalšímu člověku, jak může být syndie cool. 16:43 <@frosk> hehe jo 16:43 <+tethra> haha 16:44 <@frosk> GUI (v SWT) je/bude testbed pro všechny věci kolem feedspace, aby se to nakoplo 16:44 <jrandom> r0x0r 16:45 <+void> jrandom: možná bys měl crosspostovat všechno, co jde na mailing listy, i do syndie? 16:45 <jrandom> to bychom měli úplně sloučit se syndie SWT GUI (základní paradigma je prohlížeč, i když v tabech nezobrazuje HTML stránky) 16:46 <+polecat> To by bylo fajn. Zdá se, že mi už mailing list nechodí. 16:46 <jrandom> void: pro někoho by bylo celkem snadné napsat malý shell skript, který napojí procmail do syndie CLI 16:46 <@cervantes> jsou tahle fajnová SWT GUI napojená přímo do aplikací? nebo jsou to nadstavby pro CLI spustitelné, případně používají TCP atd. atd. 16:46 <@frosk> to dává smysl 16:46 <jrandom> (jestli si dobře pamatuju, mám někde starší post na blogu, který vysvětluje, jak použít syndie CLI k vkládání příspěvků) 16:47 <+polecat> Aktuálně lze dělat RSS feedy a krmit jimi syndie, i když je to zatím takové neohrabané. 16:47 <jrandom> cervantes: JDBC v event handlerech, inline s JNI a MSVC callouty, samozřejmě ;) 16:47 * jrandom uhýbá 16:48 <+polecat> Microsoft Visual Classes? 16:49 <@cervantes> jrandom: takže cokoliv, co umí mluvit SQL, může spravovat syndie? 16:49 <jrandom> (z pohledu syndie je veškerá funkcionalita v zásadě implementovaná v mnoha malých CLI aplikacích, které jen aktualizují JDBC databázi, a je k tomu SWT UI na procházení DB) 16:51 <+polecat> A protože databáze má dvě rozhraní, JDBC a SQL, klient komunikující v kterémkoli protokolu může se syndie zamávat. 16:51 <jrandom> cervantes: ano i ne – velká část databáze je šifrovaná, takže ne všechna pole jsou čitelná 16:51 <+void> zůstane tam současné webové rozhraní? 16:51 <jrandom> (jdbc == sql) 16:51 <jrandom> void: ne 16:51 <+polecat> Myslel jsem, že jsi říkal, že JDBC není blbý člověkem čitelný protokol? 16:51 <+Complication> jdbc == java database interface, možná trochu podobné odbc 16:51 <jrandom> ((jdbc ~= sql)) 16:51 <+Complication> Něco, přes co mluvíš SQL 16:52 <+void> jrandom: co bude se syndie.i2p/syndiemedia.i2p.net? 16:52 <+polecat> Aha. No, SQL jsem stejně nikdy neměl rád, jen pro pořádek. 16:52 <@cervantes> jrandom: takže je lepší vytvořit nadstavbu pro syndieTools (tm), než se snažit sosat data sám 16:53 <jrandom> void: čas ukáže. pravděpodobně budou 1) sloužit jako web/eepsite pro syndie, 2) sloužit jako veřejný archiv příspěvků pro syndikaci a časem, až bude napsané webové rozhraní, 3) poskytovat webové rozhraní 16:53 <+polecat> Proč neposílat jako databázové dotazy rovnou bytecode místo archaických příkazů v COBOLu? 16:53 <jrandom> jo, cervantes 16:53 <jrandom> !lart polecat 16:54 <+void> hehehe 16:54 <+polecat> Ach, moje tajná slabost. 16:54 <@cervantes> * ve svém inventáři máš ještě 6 lartů, na severu jsou dveře a na podlaze leží v bezvědomí polecat 16:54 <jrandom> cervantes: to je vlastně CLI app #3 (extrahování jednotlivých příspěvků, což přichází po app #2, vypisování jednotlivých příspěvků (po #1, vytváření jednotlivých příspěvků, a po #0, správa nymů))) 16:54 <jrandom> lol 16:54 <+tethra> haha 16:55 <+Complication> návrh feature: místo bytecode proč neposílat jako databázové dotazy živé agenty $agency? ;P 16:56 <+Complication> Bylo by mnohem snazší validovat jejich bezpečnost :P 16:56 <@cervantes> jrandom: jasné 16:56 <+tethra> fungují za správného klimatu jako poštovní holubi, Complication? 16:56 <+Complication> tethra: jen když je zvládneš protlačit přes TCP stack neporušené :P 16:56 <+polecat> Ano, databázové dotazy přes C++! 16:57 <+Complication> Představuju si, že když se v TCP pomačkají, mohlo by je to poškodit 16:58 <+Complication> (sorry, vtipy bychom měli nechávat na #i2p-chat, ale někdy si prostě nemůžu pomoct) 16:58 * cervantes cítí, že se blíží baff 16:58 <+Complication> databázové dotazy jako shellcode? 16:59 <jrandom> ok, má někdo ještě něco k meetingu? 16:59 <+polecat> http://www.blug.linux.no/rfc1149/ <- přes tohle bychom fakt mohli tunnel i2p. 16:59 * Complication by raději zůstal u SQL 17:00 <+void> jrandom: mají jiné jazyky než Java knihovny pro databáze hsqldb? 17:01 <+Complication> Oo by asi mělo, když to zjevně používají 17:01 <+void> mně to vypadá spíš na „ne“ 17:01 <+void> oh, hmm 17:01 <@cervantes> OpenOffice to používá, takže bych hádal, že ano 17:01 <+Complication> Ale nejsem si jistý, v čem je OpenOffice napsaný 17:01 <jrandom> o ničem nevím. ale lze provozovat syndie proti jiné JDBC databázi (mysql, oracle, atd.) 17:01 <jrandom> OO používá Javu 17:02 <+void> k čemu přesně používá OpenOffice tuhle databázi? 17:02 <+Complication> Ale zdá se, že ji používá jen částečně 17:02 <jrandom> void: pro generování PDF a pro jejich databázovou aplikaci podobnou Accessu 17:02 <jrandom> (mimo jiné) 17:02 <+Complication> Soudě podle toho, že doporučují externí JRE 17:02 <+void> ok 17:03 <+void> psát přenositelný SQL je ale pěkná otrava 17:03 <+Complication> pokud se nepoužívají triggery nebo uložené procedury, neměla by to být taková bolest 17:04 <jrandom> eh, není to tak zlé a dá se to snadno vyčlenit 17:04 <+void> zvlášť když míříte na Oracle ;) 17:05 <jrandom> vlastně, hsqldb podporuje pl/sql ;) 17:06 <bar> jsou s touhle databází ještě jiné plány, třeba pro statistiky, profily peerů, netdb..? 17:06 <jrandom> ne, tohle je jen pro syndie 17:06 <bar> ok 17:07 <jrandom> (i když jakmile dodáme kód hsqldb, můžeme ho v i2p použít „zadarmo“) 17:07 <@cervantes> protože syndie není I2P aplikace, jen aplikace, která může běžet přes I2P, správně? 17:07 <jrandom> jo, cervantes, není žádná závislost na i2p 17:07 <+Complication> Je dobré udržet Syndie přenositelnou, protože může mít i jiné transporty než I2P 17:07 <bar> přesně 17:08 <+Complication> Nicméně předpokládám, že nebude těžké spouštět více instancí hsqldb na stejném stroji 17:08 <+Complication> Takže pokud by to potřebovaly jiné aplikace, zřejmě by to prostě mohly použít 17:08 <jrandom> triviální a s nulovými náklady, pokud použijete in-JVM databázi 17:08 <+Complication> (ideálně by měly mít vlastní instanci) 17:10 <+void> není pro sqlite jdbc driver? 17:11 <jrandom> nevím, nikdy jsem ho nepoužil 17:11 <+void> aha, vypadá to, že *něco* je 17:13 <jrandom> ok, ještě něco k meetingu? 17:13 <jrandom> pokud ne... 17:13 * jrandom dinws up 17:13 * jrandom ustoupí 17:13 * jrandom se rozmachuje 17:13 * jrandom *baf* uzavírá meeting