Schůzka vývojářů I2P - 22. února 2005

13:04 <jrandom> 0) ahoj 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) Další kroky 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) ahoj 13:04 * jrandom mává 13:05 <jrandom> týdenní stavové poznámky jsou na http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (jo, jen minutu nebo dvě před schůzkou, tak otestujme vaše rychločtení) 13:05 <+detonate> myslím, že počkám, až to bude trochu míň zabugované, než tam dám Boondock Saints 13:06 <jrandom> proč... to je... to je... to je porušení autorských práv! 13:06 <+detonate> divné nové přírůstky do Azureus beta 13:06 <+detonate> kategorie 13:06 <+detonate> haha 13:06 <+detonate> DHT tracker 13:06 <+detonate> super 13:07 <jrandom> jo, vypadá to fakt cool, ale pojďme probrat body 1 a 2 před 3, co? ;) 13:07 <+detonate> ahoj 13:07 <+detonate> přesně tak 13:07 <jrandom> skočíme do 1) 0.5 13:07 <jrandom> je to, jakože, venku a tak 13:08 <cervantes> hurá! 13:08 <jrandom> později večer bude nová revize s hromadou aktualizací (aktuální CVS head je 0.5-5, -6 je v testování na některých routerech) 13:09 <jrandom> šlo to docela dobře, ale cestou jsme narazili na pár divných bugů. ale c'est la vie 13:09 <frosk> můžu potvrdit, že 0.5-5 se chová o _hodně_ přívětivěji než -4 (která mi často dávala počty participating tunnelů v tisících) 13:09 <bla> jrandom: Opraví verze 0.5.0.1 problém s nemožností najít destinace? 13:09 <jrandom> aha, no, to je ale opravdu jen funkce ostatních lidí, -0 build ve skutečnosti staví stovky tunnelů 13:09 <bla> s/nor/not 13:10 <jrandom> bla: ano, to je bug v netDb 13:10 <bla> jrandom: Skvělé! 13:10 <jrandom> (konkrétně v publikování leaseSet) 13:11 <jrandom> a ano, revize 0.5.0.1 se zbaví toho občasného bugu s mizejícím proxy 13:12 <jrandom> pořád je tam zvláštní memory leak, který jsem zatím nevystopoval a který postihuje některé uživatele 13:12 <bla> Takže celkově se zdá, že kromě těchto bugů si síť 0.5 vede velmi dobře. Hurá! 13:12 <jrandom> pokud vím, ve skutečnosti to zasahuje jen dvě nebo tři instance I2PTunnel 13:12 <Meomia> je to známka pokroku, když jsem od 0.5 přešel z 0 na 130 participating tunnelů? 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia: pff, já měl přes 5000 tunnelů ;) 13:13 <jrandom> ale dm ve skutečnosti pomohl najít bug v kódu exploratory pool, takže budeme stavět tunnely častěji na 'náhodných' peerech 13:14 <jrandom> (hurá) 13:14 <Meomia> ok 13:14 <bla> jrandom: Znamená to také, že teď, na rozdíl od 0.4, se každý peer může někdy stát tvým inbound gateway? 13:14 <jrandom> ano, pro exploratory tunnels 13:15 <jrandom> client tunnels budou používat jen peery ve vrstvě 'fast' 13:15 <bla> bla: Ok. To, že client tunnels používají jen rychlé peery, je dobré: jinak bychom měli problém s anonymitou, o kterém jsme mluvili dřív 13:16 <jrandom> a výkon by jinak stál za houby ;) 13:17 <jrandom> vlastně nás to přivádí k 2) Další kroky 13:18 <jrandom> velká věc, která zbývá pro řadu 0.5, je sada strategií pro řazení a/nebo filtrování peerů používaných v tunnels 13:18 <godmode0> jrandom lze používat NNTP s i2p ? 13:18 <jrandom> godmode0: na i2p jsou dva NNTP servery, ano. koukni na fórum 13:19 <godmode0> jrandom ok testuju 13:19 <godmode0> můžu si postavit i vlastní server? 13:20 <jrandom> godmode0: teď jsme na schůzce, ale ano, můžeš provozovat server 13:20 <godmode0> jrandom ok promiň 13:20 <jrandom> v pohodě 13:20 <jrandom> ty navržené strategie míří v zásadě na zlepšení anonymity, ale je tam pár dalších cílů, které můžeme vyvážit 13:21 <jrandom> možná najdeme způsob, jak do výběru integrovat některé AS cesty, jak navrhoval bla 13:22 <jrandom> to může zlepšit (jurisdikční) anonymitu, a pokud se pokusíme zůstávat v rámci jednoho (nebo dvou) AS, může to zlepšit výkon 13:22 <bla> jrandom: To v zásadě souvisí s článkem autorů Toru: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> jo 13:23 <jrandom> existuje celá řada různých strategií, které mohou lidé použít, a zkoušet nové by mělo být docela snadné 13:24 <jrandom> nebudeme trávit měsíce implementací všeho, co nás napadne, ale poskytneme základy toho, co většina lidí bude potřebovat. kdokoli chce přidat nové, je velmi vítán, aby pomohl je zapojit 13:25 <jrandom> každopádně jakmile budou základy hotové, přesuneme se k zaměření na UDP transport pro 0.6 13:26 <jrandom> to je zhruba vše, co mám k 2) Další kroky, má někdo nějaké komentáře/dotazy/obavy? 13:26 <bla> Kdo byli ti lidi, co se začali znovu dívat na I2P? 13:26 <bla> Zdá se, že jsme o nich poslední dobou moc neslyšeli. 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> sorry 13:27 <jrandom> aha, mule byl nemocný, i když myslím, že detonate dělá pokroky 13:28 <jrandom> detonate: nějaké novinky? 13:29 <jrandom> nebo možná ne ;) 13:30 <jrandom> ok, přejdeme k 3) azneti2p 13:30 <+detonate> sorry 13:30 <+detonate> dělám pokrok 13:30 <+detonate> ještě musím dodělat část znovuskládání (re-assembly) 13:31 <+detonate> co se týče rozdělení dat do paketů a jejich poslání v pořádané podobě, to funguje 13:31 <+detonate> k 3) 13:31 <jrandom> boží 13:31 <godmode0> sorry krok 2) i2p má nějaký problém s útoky? 13:31 <bla> detonate: Super! Můžeš nás všechny průběžně informovat na fóru? 13:32 <+detonate> bla: jasně 13:32 <tracker> K azneti2p se podívej sem: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 vypadá to, že stahování funguje, seedování ne. 13:32 <jrandom> godmode0: různé strategie řazení by měly uživateli umožnit zvolit dopad predecessor útoků 13:33 <microsoft> kdokoli spravuje i2p.net, měl by na stránku přidat víc buzzwordů typu Enterprise Class Solutions. 13:33 <+detonate> někdo by měl ověřit, že ten nový DHT tracker se taky nechová špatně ve vztahu k pluginu pro Azureus 13:33 <tracker> Místní testy to zřejmě potvrzují, s Azureusem umím stahovat, ale ne seedovat. 13:34 <jrandom> hmm ok fajn, díky trackere – vím, že pár věcí aktualizovali a včera večer vydali b34, ale zdá se, že je ještě co dělat, 13:34 <jrandom> detonate: dobrý postřeh 13:35 <tracker> Dobrý postřeh, detonate, mám DHT vypnuté, protože Azureus po pár hodinách zdechne se 100% využitím CPU, když je aktivní. 13:35 * jrandom by rád zopakoval, že plugin azneti2p je pořád poměrně raná beta a důsledky Azureusu pro anonymitu nebyly plně auditovány 13:36 <jrandom> jsem si jist, že jsou rádi, když to lidé testují, ale ti, kdo potřebují anonymitu, by měli být opatrní 13:36 <tracker> Na druhou stranu, i2p-bt funguje fakt dobře. Až na to, že nezavírá tunnels, ale to podle mě (IMHO) není tak zlé. 13:37 <jrandom> aha, to se ti pořád děje, trackere? mně se to nepodařilo reprodukovat 13:37 <jrandom> jsi na revizi 0.1.7, že? 13:37 <tracker> Ano, jsem. 13:38 <jrandom> ok super, pokud se ti to děje pořád, rád bych po schůzce vytěžil tvoje zkušenosti, abychom dohledali příčinu 13:39 <tracker> Možná to souvisí s provozem na XP místo na Linuxu nebo Unixu. Zavření tunnelu funguje s Azureusem, takže hádám, že je to na straně I2P-BT. 13:39 <jrandom> hmm jasně, i2p-bt používá SAM, zatímco Azureus používá přímo i2p SDK 13:40 <tracker> Mimochodem, poslal jsem ti report bugu na fóru. Timestamper padá na posledních CVS buildech I2P. 13:40 <jrandom> ah super, díky, dnes jsem tam ještě nekontroloval své PM 13:41 <jrandom> na -5 nebo -4? nebo dřív? 13:42 <jrandom> aha, -4. ok super 13:42 <jrandom> díky, opravím to pro 0.5.0.1 13:42 <jrandom> ok, má někdo ještě něco k 3) azneti2p? 13:43 <tracker> Děje se to i na -5 13:43 <jrandom> máš explicitně definovaný sntp server, že? 13:44 <tracker> Ano. Ty 2 z naší země. 13:44 <jrandom> právě jsem zkontroloval zdroják a výjimka nastane, když je počet souběžných serverů (default = 3) větší než počet zadaných serverů (nový default má 3) 13:44 <jrandom> ok super, je to triviální oprava na % # servers 13:45 <jrandom> ok, pokud není nic dalšího k azneti2p, posuneme se ke staré dobré 4) ??? 13:46 <jrandom> má ještě někdo něco k projednání na schůzku? 13:46 <tracker> Super. Právě jsem ti na fóru poslal chybové logy z routeru při zavírání i2p-bt. 13:47 <jrandom> 'k super, díky 13:47 <cervantes> nic k zmínění kromě: pěkná práce s rolloutem 0.5, vypadá to, že to bude pecka, jakmile se vyžehlí bugy 13:48 <tracker> Jo, poslední CVS buildy tady fakt jedou dobře. 13:48 <jrandom> díky, s vaší pomocí i pomocí ostatních testerů 0.5-pre jsme dokázali vyčistit spoustu problémů 13:49 <jrandom> výkon byl lepší, než jsem čekal, i když throughput není tak vysoký jako dřív. pořád zbývá hodně co optimalizovat 13:49 <cervantes> zajímavé je, že pre verze byly stabilnější... pro mě, ale tehdy jsem je provozoval na jiném stroji ;-) 13:49 <jrandom> (a tyhle zatracené bugy, aby byla spolehlivost tam, kde má být) 13:50 <jrandom> heh no jo, ale -pre síť byla 5–7 routerů, všechny šíleně spolehlivé na opravdu opravdu rychlých připojeních 13:50 <cervantes> :) 13:51 <cervantes> tak mě pak zapiš na 0.6 pre test :) 13:51 <jrandom> heh 13:51 <tracker> Možná bych se měl zapojit do další pre sítě. Poskytnu velmi nespolehlivé a pomalé připojení ;). 13:51 <jrandom> migrace na 0.6 bude asi ještě jednodušší, doufám, protože budeme moct jen přidat nové adresy routeru do routerInfo (UDP adresy) 13:51 <jrandom> heh word 13:51 <cervantes> můžu dát online svůj 1TB file share... 13:52 <jrandom> určitě budeme potřebovat spoustu pomoci s testováním 0.6, zapojíme celou škálu síťových nastavení 13:52 <hobbs> ssh '~C' command je šikovný 13:52 <laberhorst> bude to zase další nekompatibilní krok? 13:53 <Myo9> Víte někdo, které NNTP servery běží? 13:53 <jrandom> laberhorst: ne, 0.6 bude zpětně kompatibilní 13:53 <jrandom> Myo9: nevím, možná běží a jen jsou kousnuté bugy 0.5-0 13:54 <jrandom> revize 0.5.0.1 by měla opravit spoustu problémů a jakmile vyjde, upgrade bude silně doporučen 13:54 <laberhorst> tak prostě postavit testovací 0.6 a dát ji testerům 13:54 <cervantes> můžeme přimět BT provoz používat jen zastaralé routery... to lidi povzbudí k upgradu ;-) 13:54 <laberhorst> takže zítra velká upgrade párty 13:54 <jrandom> až to bude připravené, bude oznámení na fóru a na listu 13:54 <jrandom> přesně tak, laberhorst 13:54 <jrandom> heh cervantes ;) 13:55 <laberhorst> *těším se, až pro vás budu testovat* 13:55 <jrandom> výkon BT byl na 0.5 docela dobrý, viděl jsem spoustu úspěšných přenosů velkých souborů na trackerech 13:55 <laberhorst> pload rate: 8.85 kB/s 13:55 <jrandom> (a IRC nebylo ovlivněno jako dřív, kromě problémů, které máme s duckovým tunnelem) 13:55 <tracker> Záleží na tom, co nazýváš velké ;) 13:56 <jrandom> tracker: myslím na konkrétní 874MB soubor, který má spoustu úspěšných downloadů ;) 13:56 <jrandom> ale je pravda, že pro některé je to malé 13:56 <laberhorst> prostě staré dobré porno 13:56 <laberhorst> předpokládám ;-) 13:57 <laberhorst> doufejme, že od zítřka se můj router nebude účastnit >3000 tunnelů 13:57 <tracker> Ok, to je velké. 13:57 <laberhorst> nebo pokud ano, síť JE velká 13:57 <jrandom> heh laberhorst 13:58 <jrandom> ok, má ještě někdo něco k dnešní schůzce? 13:58 <laberhorst> mimochodem, je participate in>3000 synonymum pro dobrý spolehlivý router v i2p s rychlým připojením? 13:58 <+detonate> dám Boondock Saints nahoru, až dneska stáhnu House :) 13:59 <+detonate> to bude hezkých 4,1 GB :) 13:59 * laberhorst jen chce poděkovat vývojářům za rychlé zabíjení bugů 13:59 <+detonate> zdá se, že je o to velký zájem 13:59 <laberhorst> oh, jsou tu i nějaké DVD image 13:59 <hobbs> detonate: oo, jasně. House. :) 13:59 <tracker> cervantes, už jsi upgradoval na phpBB 2.0.12 13:59 <laberhorst> ale počkejte, až vyjde 0.5.0.1 13:59 <+detonate> mělo by to dát 0.5.0.1 taky slušný zátěžový test 14:00 <+detonate> jo 14:00 <+detonate> mám to v plánu 14:00 <jrandom> samozřejmě by je měli stahovat jen lidé, kteří už vlastní legální kopie těch souborů. to je jen pro testování 14:00 <jrandom> *kašel* 14:00 <tracker> rofl 14:01 * jrandom poznamenává mpaa.i2p 14:01 <+detonate> heh 14:01 <laberhorst> oh, můžu dělat ISO image z Debianu, Fedory, SUSE, fotek co jsem udělal,... 14:01 <laberhorst> takže spousta legálního materiálu 14:01 <laberhorst> pokud chcete jen testovat, /dev/random je HODNĚ velký 14:01 <Ragnarok> ne vždy 14:02 <laberhorst> mimochodem, na osamělé víkendy: cat /dev/random | grep linux :-) 14:02 <jrandom> heh 14:02 <frosk> /dev/random se pořád vyprazdňuje, preferuji /dev/urandom :) 14:02 <frosk> nebo nový, vylepšený /dev/jrandom 14:02 <jrandom> ne, ten pořád padá s core dumpem 14:03 <jrandom> a potřebuje svůj noční odpočinek 14:03 <Ragnarok> jak nejlépe generovat entropii pro /dev/random? 14:03 <laberhorst> opravdu bychom měli založit fond „get jrandom a few beers“ 14:03 <frosk> říkej tomu odpočinek nebo sběr entropie :) 14:03 <hobbs> Ragnarok: Záleží, co tím přesně myslíš. Pořídit si hardwarový RNG by byl víceméně ten „nejlepší“ způsob :) 14:03 <jrandom> Ragnarok: záleží na tvém OS (a jestli máš hardware ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Vždycky potěší ;) 14:04 <jrandom> ve skutečnosti v některém z těchto buildů přibalíme implementaci Fortuna a budeme muset pohrabat různé zdroje entropie 14:04 <Ragnarok> bez hardware :P 14:04 <susi23> . o O ( myslel(a) jsem, že někdo používající i2p ví, proč by neměl používat /dev/urandom ) 14:05 <cervantes> tracker: bezpečnostní exploity pokryté v 2.0.12 můj mod_rocinante neúmyslně opravuje, takže jsem se zatím nenamáhal upgradovat 14:05 <hobbs> susi23: když je to jen na rošťárny, myslím, že je to v pohodě ;) 14:05 <ant> <Nolar> kdo tady dělá Python port BT? 14:05 <jrandom> Nolar: to by byl duck 14:06 * duck píská 14:06 <ant> <Nolar> duck: proč jste změnili velikost požadovaného bloku na 128k? 14:06 <susi23> . o O ( další navrhne: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> proto k tobě AZ neumí seedovat 14:06 <tracker> cervantes: Ok 14:06 <ant> <Nolar> blokujeme požadavky > 64k 14:06 <laberhorst> sakra, potřebuju víc mp3 14:06 <frosk> susi23: na grepování linuxu během líného večera je /dev/urandom úplně v pohodě :) 14:07 <jrandom> aha, to jste měli vždy? pokud si dobře pamatuju (iirc), i2p-bt už nějakou dobu používá 128k 14:08 <ant> <Nolar> jo, je to tak od začátku :) 14:08 <ant> <Nolar> je nějaký důvod, proč se používá 128? 14:08 <ant> * duck prochází cvs log 14:08 <jrandom> udržuje to zaplněný pipeline, i2p má nějaké zpoždění ;) 14:08 <jrandom> s 32KB je to v podstatě pevná velikost okna 1 14:09 <jrandom> takže každá zpráva blokuje na ACK, zatímco 128KB umožňuje 4 zprávám letět v rámci RTT 14:09 <@duck> správně, maximální povolená velikost slice podle BT specifikace 14:09 <ant> <Nolar> no, jsou dva způsoby, jak to řešit: 1) zvedneme limit na naší straně na 128k, nebo 2) prostě napipelinuješ víc požadavků 14:09 <cervantes> i2pbt je trochu svižnější než bývalo... možná si můžete dovolit to snížit... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> takže místo jednoho 128k požadavku pošli třeba dva 64k 14:10 <hobbs> duck: haha... ta věc obletěla svět. 14:10 <@duck> proč blokujete 128k? 14:11 <cervantes> *brr* europop 14:11 <laberhorst> duck: prosím, zmlkni, NEBO tě sestřelím! 14:11 <tracker> Někdy lituju, že jsem se před lety učil německy... 14:11 <laberhorst> ne europop, fakt ne POP 14:11 * cervantes nařizuje Spojenému království odrazit hranice, než se taková píseň dostane do žebříčků 14:11 <laberhorst> tracker: neřeš, je to v pohodě 14:12 <ant> <duck> teď je to (2^17)-13 14:12 <ant> <Nolar> duck: no, limit tam byl už nějakou dobu, ale jeden dobrý důvod je, že 128K bloky trvá nahrát.....16KB (náš default) umožňuje jemnější řízení požadavků 14:12 <ant> <duck> 13 bajtů je délka bittorrent command 14:12 <ant> <duck> neměl bych problém s (2^16)-13 14:12 <laberhorst> některá hudba je fakt směšná, ale opravdový industrial, bohužel, ne 14:13 <ant> <duck> nebo se vrátit k defaultu? 14:13 <jrandom> snížit to na 64KB se zdá nejjednodušší (je to teď cli parametr?) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> no, moje otázka je, máte pádný důvod držet se 128K bloků, které mi přijdou trochu velké, zvlášť pro i2p 14:14 <ant> <Nolar> místo toho, abyste prostě pipelinovali více menších požadavků? 14:14 <ant> <duck> nemám důvod. 14:14 <tracker> laberhorst: Někdy chytím přes satelit některé německé kanály. Zejména VIVA a ten „Theater Kanal“ jsou fakt příšerné... 14:15 <ant> <Nolar> jeden problém s velkými bloky je, že jakmile tě choke-nu, stejně musím dokončit posílání toho 128k chunku 14:15 <jrandom> nevybavuju si, jestli vanilla bt umí pipeline, ale mělo by to být dost jednoduché (zvlášť když to nedělám já ;) 14:15 <ant> <Nolar> což může chvíli trvat 14:15 <laberhorst> tracker: VIVA je zajímavá jen v „hard rock“ čase, jindy „prosím ignorovat“, a Theater, nevím 14:15 <jrandom> u i2p není 128KB zas tak velké, protože je tam inherentní zpoždění v řádu sekund 14:15 <ant> <Nolar> což může rozhodit chunk/unchoke 14:16 <@duck> jrandom: dává pořád smysl odečítat bittorrent 13bajtový overhead, aby se to vešlo do sam message? 14:16 <jrandom> duck: ne, protože streaming lib to už dál snižuje na 16KB zprávy, takže to prostě dej na 64KB 14:17 <@duck> ok, bude to 2**16 14:17 <jrandom> (a pak tunnels rozbijí těch 16KB zpráv na 996 bajtové fragmenty..) 14:17 <ant> <Nolar> problém se 128k je, že když nahrávám řekněme 12 k/s, zabere mi přes 10 sekund ten blok dokončit 14:18 <cervantes> wow to je skoro tak dlouho jako lag na IRC... 14:18 <jrandom> což je 1–10 RTT (zatímco na normálním netu 10–500) 14:18 <+detonate> já měl v plánu použít 512K bloky 14:18 <ant> <Nolar> můžete taky experimentovat s pipeliningem 16kb bloků 14:18 <jrandom> heh 14:18 <+detonate> takže 64 je preferované? 14:19 <ant> <Nolar> všechny bt klienty afiak používají 16KB bloky 14:19 <ant> <duck> opraveno v CVS; 14:19 <jrandom> boží, díky ducku! (a Nolare!) 14:19 <ant> <duck> očekávejte to ve vydání 0.1.8 spolu s nějakým sam i2cp laděním 14:19 <tracker> laberhorst: Jeho celý název je „ZDF Theater“ nebo tak. A tvrdí, že vysílají vysoce kulturní program. Doufám, že to, co vysílají, není to nejlepší, co může německá kultura nabídnout ;) 14:19 <jrandom> ok, heh, právě jsem si vzpomněl, že jsme pořád na schůzce 14:19 <jrandom> má ještě někdo něco k téhle schůzce? 14:20 <ant> <Nolar> takže když chceme 128k chunk, prostě uděláme 8 simult požadavků 14:20 <susi23> . o O ( a zahodit zbývajících 448 bajtů? ) 14:20 <jrandom> jo jo 14:20 <laberhorst> tracker: oh, to je malý vedlejší kanál... arte nebo 3sat jsou opravdu zajímavější 14:20 <laberhorst> a arte je německo/francouzský :-) 14:20 <ant> <Nolar> pokud uploader umí takový požadavek naplnit, všech 128k by mělo být pushnuto do i2p pipe streamu 14:20 <jrandom> cool 14:21 <cervantes> . o O ( přemýšlí, proč slyší všechno, co si susi myslí ) 14:21 <ant> <Nolar> takže může stát za to experimentovat s 16KB vs 32KB vs 64KB velikostmi bloků 14:21 <jrandom> jo 14:21 <jrandom> dokud je to pipelinované, i2p je to jedno 14:21 <ant> <Nolar> skvělé 14:22 <jrandom> rychlost na 16KB bez pipeline je ale dost špatná, nebo aspoň bývala 14:22 <tracker> laberhorst: Ok, zkusím, jestli v příštích dnech chytím arte... 14:22 <ant> <duck> navrhuju nechat tohle ladění na 0.2 14:22 <ant> <duck> protože bude obsahovat vylepšení bittorrent 3.9.1 14:22 <jrandom> jo, DTSTTCPW 14:22 <susi23> . o O ( oh to je jednoduché... lidi jsou tak předvídatelní... ) 14:23 <ant> <duck> což může kompletně restrukturalizovat síťový kód 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> ok, myslím, že to je pro tuto chvíli vše, lidi by měli za pár hodin zkontrolovat list a web, protože brzy vyjde revize 0.5.0.1 14:24 <ant> <Nolar> jo, chápu, proč by jednotlivé 16kb požadavky byly pomalé 14:24 * jrandom stahuje kladívko 14:24 * jrandom *baf* uzavírá schůzku