(Mit freundlicher Genehmigung der Wayback Machine http://www.archive.org/)
Kurze Zusammenfassung
Present: duck, FireRabbit, jrand0m, lonelynerd, mids, mihi, MrEcho, protocol, TC, wiht
Sitzungsprotokoll
[22:04] <jrand0m> 0) hi [22:04] <jrand0m> 1) iip [22:04] <jrand0m> 2) 0.2.3 & 0.2.3.1 [22:04] <jrand0m> 3) hi [22:04] <jrand0m> 0) hi [22:04] <jrand0m> willkommen zum ... irgendwievielten Treffen [22:05] <jrand0m> (68? 69?) [22:05] <MrEcho> verdammt, hier ist es 13 Uhr [22:05] <jrand0m> GMT-8? [22:05] <duck> 69 [22:05] <jrand0m> h0t. [22:06] <jrand0m> ok, 1) iip [22:06] *** Signoff: tusko (EOF From client) [22:06] * MrEcho kompiliert für das Treffen einen Kernel [22:06] <jrand0m> iip spielt verrückt. Alles, was ich weiß, ist, dass nop „Server verschiebt“, was auch immer das heißen soll. Ich weiß nicht, wann das fertig ist, usw. [22:06] <jrand0m> hat jemand noch mehr Infos, die er mit der Runde teilen will? [22:06] *** mids (mids@anon.iip) has joined channel #iip-dev [22:06] <MrEcho> keine Info von nop [22:07] <mids> heute Morgen wurde mir gesagt, dass ich Trent wieder starten könne [22:07] <mids> (habe ich gestern Abend bereits getan) [22:07] <jrand0m> krass [22:07] <jrand0m> gracias [22:07] <mids> das deutet darauf hin, dass nop glaubt, dass IIP wieder stabiler ist [22:07] <mids> falls das etwas wert ist... [22:07] <mids> *hust* [22:07] <jrand0m> ok, cool [22:08] <jrand0m> [woot, mein Mitbewohner hat mir gerade ein Glas Wein für das Treffen rübergereicht] [22:08] <MrEcho> lol [22:08] <jrand0m> ok, da nop online ist und nicht zum Treffen kommt, müssen wir den Lynchmob auf später verschieben [22:09] <jrand0m> 2) 0.2.3 & 0.2.3.1 [22:09] <mids> welche konkrete Frage willst du ihm stellen? [22:09] <protocol> wann ist das Treffen [22:09] <jrand0m> konkrete Frage> wann wird er eine offizielle Ankündigung machen, die die vergangenen Probleme beschreibt und wie die zukünftigen angegangen werden? [22:09] <jrand0m> das Treffen ist jetzt [22:10] <jrand0m> (aka, ab wann sollten wir nicht-iip Kommunikationswege in Betracht ziehen) [22:10] <mids> wenn ich eine Antwort bekomme, sag ich Bescheid. [22:10] <jrand0m> danke [22:11] <jrand0m> ok, i2p-Kram. 0.2.3 ist gestern rausgekommen, und während der meiste Kademlia-Code gut läuft, tauchen einige 0.2.2-Bugs auf, ebenso werden andere Bugs untersucht. [22:11] <jrand0m> Ich habe eine Änderung eingecheckt, um für dbStore statt garlics getunnelte Nachrichten zu verwenden, was die Last reduzieren sollte, die tc (u. a.) auf Servern gesehen hat [22:12] <jrand0m> es gibt auch einen neuen persistent sessionKeyManager, der dafür sorgt, dass Neustarts einen router nicht mehr für 15 Minuten komplett b0rken [22:12] <MrEcho> wie sieht es mit den Client-Verbindungszeiten zu routers aus? [22:12] <duck> bisher fühlt es sich so gut/schlecht an wie 0.2.2; außer mein router/tunnels gehen heute Nacht wieder down, dann wäre es schlechter als 0.2.2 [22:13] <jrand0m> MrEcho> das scheint durch das Zusammenspiel zweier Bugs aus 0.2.2 zu kommen, die jetzt stärker auftreten als früher. Diese beiden haben oberste Priorität. [22:13] <MrEcho> ok, cool [22:13] <jrand0m> duck> mein Eindruck ist, dass es schlechter ist als 0.2.2, aus Endnutzer-Sicht. Ich arbeite daran, das zu beheben, ohne Anonymität oder Sicherheit zu opfern. [22:13] <MrEcho> mit diesem verdammten Bug ist es schwer, am DNS zu arbeiten .. ich muss den DNS-Server oft neu starten [22:14] <jrand0m> MrEcho> mit local-only routers konnte ich die Bugs nicht reproduzieren – funktioniert es bei dir mit local-only? [22:15] <MrEcho> nein [22:15] <jrand0m> könntest du mir dafür Debug-Logs senden? [22:15] <MrEcho> schon gelöscht [22:16] <jrand0m> ok, wenn du es nochmal versuchst und es nicht klappt, schick mir bitte Debug-Logs sowohl vom router als auch vom Client, das wäre super. [22:16] <MrEcho> es macht dasselbe wie vorher .. der Client bekommt die Meldung, dass es gesendet wurde .. aber es kommt nie beim anderen Client an [22:16] <MrEcho> beim anderen Client [22:17] <MrEcho> ja .. ich schau, was ich machen kann [22:17] <jrand0m> ok, klingt nach dem i2psessionImpl2-Bug. Ich konnte den lokal nicht reproduzieren, aber sobald er für remote gefixt ist, klappt es hoffentlich auch bei dir [22:17] <jrand0m> gracias [22:17] <jrand0m> auf jeden Fall danke für eure Geduld mit dem Update. Wir machen Fortschritte, auch wenn es sich nach außen nicht so anfühlt [22:18] <protocol> strahle weiter, du verrückter Diamant [22:18] <duck> in Zukunft, also wenn i2p tatsächlich genutzt wird, wie wird sich der Entwicklungs-/Release-Prozess ändern, um zu verhindern, dass kaputte Releases das Netz durcheinanderbringen? [22:19] <jrand0m> sobald 1.0 draußen ist, mache ich Dev & Rollout an eine wahnsinnige Gruppe von Freiwilligen zum Testen für eine Woche; wenn dann alles gut läuft, wird es allgemein veröffentlicht. [22:20] * FireRabbit wird ein verrückter Freiwilliger [22:20] <jrand0m> im Moment muss ich mit kaffe & jetty kämpfen wegen Updates auf i2p.dnsalias.net [22:20] <duck> welche Spezies? [22:20] * MrEcho ist es schon [22:20] *** tusko (~tusko@anon.iip) has joined channel #iip-dev [22:20] <jrand0m> ihr seid alle schon verrückte (und sehr hilfreiche) Volunteers :) [22:20] <FireRabbit> danke! [22:20] <FireRabbit> :) [22:21] *** TC (~TC@anon.iip) has joined channel #iip-dev [22:21] <jrand0m> hey, wenn das nicht tc ist [22:21] * MrEcho verhaut TC .. du bist zu spät [22:21] <TC> hey [22:21] <TC> laufen wir wieder? [22:21] <MrEcho> ja, ich kann heute tippen... [22:22] <jrand0m> iip scheint up zu sein... [22:22] <TC> yay [22:22] <jrand0m> auf jeden Fall hoffe ich, 0.2.3.1 in den nächsten Tagen rauszubringen, sobald die zwei kritischen Bugs gefixt sind (die CPU-Überlastung, die tc gesehen hat, ist bereits behoben) [22:23] *** wiht (anon@anon.iip) has joined channel #iip-dev [22:23] <TC> was war die Ursache? [22:23] <FireRabbit> mir ist erhöhte Festplattenaktivität seit dem Update auf 0.2.3 aufgefallen, aber ich habe noch nicht geprüft, ob das wirklich i2p ist oder nur der Rechner spinnt [22:23] *** Signoff: wiht ((null)) [22:23] <TC> FireRabbit, wie viel Arbeitsspeicher hast du? [22:24] <FireRabbit> der Rechner hat 128, glaube ich [22:24] <FireRabbit> meinst du, es könnte die Auslagerungsdatei sein? [22:24] <jrand0m> die Ursache war, dass 0.2.3 alle dbStore-Nachrichten über garlic-geroutete Nachrichten statt direkt sendet, was entweder ElGamal oder AES+SessionTag verwendet (je nachdem, ob Tags bekannt sind). Der persistentSessionKeyMAnager lässt Tags länger halten, und 0.2.3.1 wird dbStore-Nachrichten stattdessen durch tunnels schicken [22:24] <TC> denn ich habe 512 und i2p hat mir gestern Nacht einen 'out of memory'-Fehler gegeben [22:24] <jrand0m> wirklich? scheiße [22:24] <FireRabbit> oh, interessant [22:25] <MrEcho> wow [22:25] <jrand0m> ja, das ist #3 auf der Liste der Bugs, die noch zu knacken sind (ist aber kein Showstopper für 0.2.3.1) [22:25] <jrand0m> OOMs nutzen nicht alle 512 [22:25] <TC> aber jetzt scheint es gut zu laufen [22:25] <jrand0m> sie nutzen nur, was Java bekommen hat (z. B. 64M) [22:26] <TC> ja [22:26] <duck> Memory: In use: 8187KB [22:26] <jrand0m> word [22:26] <duck> das ist nicht viel! [22:26] <duck> noch [22:26] <MrEcho> Memory: In use: 8908KB Free: 4088KB [22:27] <jrand0m> genau, da wächst etwas, ich hoffe, das bis 0.3 gefunden zu haben [22:27] <jrand0m> cool, frei bedeutet, es hat früher 12,9M benutzt, jetzt nur 8,9 [22:27] <TC> es läuft gerade bei 30 MB Speicher, aber letzte Nacht sprang es (laut Windows) auf '70', ungefähr da ist es gecrasht [22:27] <jrand0m> ja, kaffe macht das bei mir auch, tc [22:28] <jrand0m> ok, auf jeden Fall sollten die Leute die i2p-Mailingliste abonnieren [22:28] * FireRabbit denkt, wenn er heute nach Hause kommt, wird er die meshwork lib neu schreiben, da sie ein paar Probleme hat [22:28] <FireRabbit> seufz [22:28] <jrand0m> ((Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/) [22:28] <jrand0m> d'oh, FireRabbit [22:28] <FireRabbit> das Ding wird nie fertig werden [22:28] <TC> jo, und Speicher ist meistens kein großes Thema [22:28] <jrand0m> heh, kein Projekt läuft so glatt, wie man hofft [22:28] <FireRabbit> nö [22:28] <protocol> jrand0m: die Mailingliste löst den Yahoo!-Spamschutz aus [22:28] <protocol> nur zur Info [22:28] <jrand0m> wirklich, protocol? [22:29] <protocol> ja [22:29] <jrand0m> vielleicht hat das den Spam-Guard ausgelöst, als ich iip-dev in CC gesetzt habe [22:29] * jrand0m wird meinem ISP schreiben [22:29] <jrand0m> (oder vielleicht liegt's an der .dnsalias.net-Sache) [22:30] <protocol> ich habe bisher keine Mailings bekommen und habe meinen Bulk-Mail-Ordner geleert, bevor ich nachsehen konnte [22:30] <duck> oder der jrandom-Nickname [22:30] <jrand0m> lol duck [22:30] <FireRabbit> :) [22:30] <jrand0m> wäre großartig, wenn mein Nick gefiltert würde :) [22:30] <FireRabbit> hehe [22:30] *** wiht (anon@anon.iip) has joined channel #iip-dev [22:30] <jrand0m> wb wiht [22:30] <jrand0m> apropos, ich sollte wohl 3.1) apps einwerfen :) [22:31] <jrand0m> hey MrEcho, wie läuft der Kampf? [22:31] <wiht> jrand0m: Hallo. [22:31] <MrEcho> der Tag, an dem jemand ein Autodetect-Programm für die Linux-Compile-Config schreibt [22:31] <MrEcho> nun, es ist in Arbeit [22:31] <duck> Knoppix benutzt doch so ein Autodetect-Ding, oder? [22:31] <jrand0m> ./configure ; make ; make check ; make install ; reboot [22:31] <duck> </offtopic> [22:31] <MrEcho> ich habe so ziemlich festgelegt, wie ich alles machen will [22:31] <jrand0m> word [22:32] <jrand0m> hast du eine klare Vorstellung, wie i2ptunnel aktualisiert werden könnte, um zu nutzen, was du machst, MrEcho? [22:32] <FireRabbit> ich glaube, Knoppix verwendet hotplug [22:32] <MrEcho> 0.1 wird nicht/evtl. gelockt sein .. weiß noch nicht [22:32] <jrand0m> coo' [22:33] <TC> oh jrand0m, ich habe eine Frage zum CVS [22:33] <jrand0m> que tal? [22:33] <MrEcho> für DNS-Anfragen werde ich einen Server-Port auf Client- und RS-Seite für Namensanfragen haben [22:33] <FireRabbit> ok jrand0m, erleuchte mich: Wenn du zwei Arrays hast, eines, das gerade empfangene Daten speichert, und eines, das als Puffer dient – wie würdest du sie nennen [22:33] <MrEcho> und ich werde eine Lib bauen, die jede App nutzen kann [22:33] <jrand0m> FireRabbit> src, dest [22:34] <FireRabbit> hmmm [22:34] <TC> ich dachte, es wäre gut, wenn ich die Host-Datei direkt ins i2p-basierte CVS einpflegte, damit sie in zukünftige Versionen aufgenommen werden kann [22:34] <jrand0m> definitiv, tc [22:34] <FireRabbit> das ist eine ziemlich große Klasse, ich denke, ich will etwas spezifischer sein als das [22:34] * jrand0m sollte dir einen CVS-Account besorgen [22:34] <TC> ich frage mich nur, wie ich mich verbinde [22:34] <duck> TC: du willst (Link: http://www.tortoisecvs.org/)http://www.tortoisecvs.org/ [22:34] <duck> der einfachste CVS-Client für Windows, den ich kenne [22:35] * MrEcho benutzt die DOS-Version :) [22:35] <mihi> duck: für Windows != Win9x ;) [22:35] * FireRabbit benutzt den CVS-Commandline-Port [22:35] <duck> mihi: ich habe es mit Win9x getestet [22:35] <jrand0m> tc> hast du CVS schon benutzt? oder sorgst du dich um Anonymität? (du solltest im Moment per i2p über CVS gehen können) [22:35] * mihi benutzt entweder WinCVS oder das Cygwin-CVS [22:35] * jrand0m benutzt cvs.exe [22:35] <TC> ok, also nutze ich den Client und richte den Proxy ein? [22:35] <TC> nein, ich habe CVS noch nie benutzt [22:35] <jrand0m> ok, ich führe dich nach dem Treffen durch das Setup [22:36] <TC> klar, danke [22:36] <duck> zum CVS-en durch den tunnel: [22:36] <duck> wären die doppelten Nachrichten nicht ein großes Problem? [22:36] *** Signoff: wiht (Ping timeout) [22:37] <duck> besonders bei Commits [22:37] <jrand0m> ja, duck, aber ich bin auf das Problem nicht gestoßen (CVS-Nachrichten sind typischerweise klein) [22:37] <jrand0m> >64k-Nachrichten (z. B. die Specs .pdf oder .sxw) sollten vorerst über das normale Internet laufen [22:38] <duck> Jabber-Msgs werden auch ziemlich oft dupliziert [22:38] <jrand0m> du hast aber recht, es ist noch keine bombenfeste Lösung für CVS [22:38] <duck> obwohl sie XML sind, sind sie nicht so groß [22:40] <jrand0m> genau, verlorene ACKs sind eine der fiesen Seiten der aktuellen verlorenen i2psessionimpl2-Bugs :/ [22:40] <duck> k [22:41] <duck> (das war ein teilweise verlorenes ACK) [22:41] <jrand0m> (bei einem Netzwerk dieser Größe sollte es nie Resends geben, außer der Peer ist offline) [22:42] <jrand0m> hmm ok, noch anderes i2p-Zeug? [22:42] <mihi> jrand0m: wie wäre es, eine Art Sequenznummer in die i2p-Pakete einzubauen? [22:43] <jrand0m> i2ptunnel-Pakete? [22:43] <mihi> das würde gegen die Verdopplungen helfen. [22:43] <mihi> nein, i2pnp-Pakete [22:43] <mihi> okay, man könnte es auch auf i2ptunnel-Ebene machen. [22:43] <TC> also jrand0m, hast du deine Verbindung zurück, oder bist du noch im Café? [22:43] <mihi> einfach wenn du dieselbe Nummer zweimal bekommst, die zweite ignorieren. [22:44] <jrand0m> die behandeln für das meiste schon doppelte IDs, aber du hast recht, für die verbleibenden Nachrichten wird es in 0.3 ein Update geben [22:44] <jrand0m> genau, derzeit behalten wir eine Historie der letzten 1000 msgIds, um Duplicates zu verwerfen [22:44] <mihi> okay, wenn jemand freiwillig eine gute TCP-Impl für i2p schreibt, wäre das besser ;) [22:44] <jrand0m> ja! :) [22:44] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev [22:45] * jrand0m denkt, es wird ein Bounty für irgendeine [noch zu bestimmende Killer-App/Funktion] geben, wenn 1.0 näher rückt [22:45] <duck> gewinne eine 1-stündige private Chat-Session mit UserX! [22:45] <jrand0m> lol [22:45] <MrEcho> lol [22:46] <jrand0m> ok, noch andere i2p-Dinge, oder iip-Dinge, oder sonst etwas für dieses, das 69. iip-dev-Treffen? [22:46] <jrand0m> (abgesehen von UserX-Pin-up-Girl-Kommentaren) [22:47] <duck> noch andere Apps, die duck inc. laufen lassen sollte? [22:47] <jrand0m> bluebeep! [22:47] <TC> 1. jrand0m, hast du deine Verbindungsprobleme behoben? 2. Was hältst du von meiner neuen eepsite? [22:47] <TC> bluebeep? [22:47] <jrand0m> oh, sorry, tc. Ja, ich habe endlich Netzzugang :) Ich habe deine neue eepsite außer dem Board (das rockt) noch nicht gesehen, aber ich schaue später rein :) [22:48] <duck> TC: mir gefällt das neue Design [22:48] <TC> hmm, ich sollte das Board auch ändern, um die Ladezeit zu verkürzen [22:48] <duck> nur solltest du versuchen, die E-Mail-Funktion im phpboard zu deaktivieren, jetzt gibt es jedes Mal einen Fehler [22:48] <TC> danke, duck [22:48] <jrand0m> Bilder wegzulassen wäre ein Plus [22:49] <TC> gute Idee [22:49] <jrand0m> (bluebeep ist ein alter Wardialer) [22:49] <MrEcho> ja [22:49] <jrand0m> (und ein rundum spaßiges Spielzeug) [22:49] <duck> bitte bedenkt, dass das Durchschnittsalter hier 16 ist [22:50] * MrEcho ist 24 [22:50] * duck duckt sich [22:50] * jrand0m bezweifelt, dass es genug 3‑Jährige gibt, um die Geriatrie unter uns auszugleichen ;) [22:50] *** wiht (anon@anon.iip) has joined channel #iip-dev [22:50] <MrEcho> lol [22:50] * TC hat einmal eine Blackbox gebaut [22:50] <jrand0m> w3wt [22:50] <lonelynerd> ist das Treffen schon vorbei? [22:50] <duck> letzte F: [22:50] *** protocol is now known as proto_afk [22:51] <duck> wie können wir die Kademlia-Stats lesen? [22:51] * jrand0m hat noch nicht !baf'ed, lonelynerd, also frag ruhig :) [22:51] * MrEcho killt PCMCIA-Support im Kernel [22:51] <duck> nur damit wir verstehen, was routerConsole.html ausgibt [22:51] <MrEcho> ich werd langsam sauer [22:51] <jrand0m> ok, die JobQueue-Statistiken meinst du, nehme ich an? [22:52] * duck vermutet, dass das alles wahrscheinlich offensichtlich ist [22:52] <jrand0m> grundsätzlich schaue ich bei den JobQueue-Statistiken, dass die durchschnittliche Ausführungszeit für die Jobs Build garlic message, buld tunnel und handle * message klein ist [22:52] <jrand0m> (das sind die Jobs, die normalerweise am längsten dauern, und wenn die Pending-Seite groß wird, leidet alles) [22:53] <lonelynerd> (eigentlich sollte ich besser zuerst die Logs lesen) [22:53] <duck> verstanden [22:53] <jrand0m> die 0,1–0,6s durchschnittliche Pending-Zeit, die ich gesehen habe, ist richtig mies und eines der großen Ziele, sobald es ans Tuning geht [22:54] <jrand0m> die netDb-Inhalte Liveliness und Reliability sind weitgehend Zufallszahlen, solange sie > 100 sind. last sent successfully bedeutet, wann es zuletzt an 2 oder mehr Peers gesendet wurde [22:54] <jrand0m> (wir senden zufällig erneut, wenn es nicht lokal ist) [22:54] <jrand0m> (aber nicht öfter als einmal alle 5 Minuten) [22:55] <jrand0m> gibt es eine Statistik, die für Leute hilfreich wäre, oder eine andere Visualisierung, die helfen könnte? (wenn es nicht trivial ist, baue ich es vielleicht nicht ein, aber wenn es einfach ist, wahrscheinlich schon) [22:56] <duck> danke [22:57] <jrand0m> noch andere Kommentare / Fragen / Bedenken / Frisbees? [22:59] <jrand0m> in dem Fall [22:59] * jrand0m holt aus [22:59] * jrand0m *baf*t das Treffen als geschlossen