I2P Entwicklertreffen - 09. Mai 2006

16:31 <jrandom> 0) hi 16:31 <jrandom> 1) Netzstatus und 0.6.1.18 16:31 <jrandom> 2) baz 16:31 <jrandom> 3) ??? 16:31 <jrandom> 0) hi 16:31 * jrandom winkt 16:32 <jrandom> wöchentliche Statusnotizen veröffentlicht unter http://dev.i2p.net/pipermail/i2p/2006-May/001288.html 16:32 <jrandom> während ihr euch das anschaut, springen wir gleich rein in 1) Netzstatus und 0.6.1.18 16:33 <jrandom> die vergangene Woche war auf IRC & im Netz allgemein ziemlich holprig 16:33 <+Complication> Beobachte die Graphen, aber habe noch keine wahrnehmbare Änderung festgestellt 16:33 <+Complication> Ist natürlich auch erst der Anfang 16:34 <jrandom> ja, es sind erst ein paar Stunden, mit weniger als 20 % des Netzes aktualisiert 16:35 <jrandom> es gibt noch ein paar schwere Geschütze, die im Netz auszurollen sind, aber ich möchte erst eine Stabilisierung abwarten, bevor wir größere Änderungen pushen 16:35 <+Complication> In der Tat, es hilft zu sehen (so weit Sehen möglich ist), was was verändert und in welche Richtung 16:36 <+Complication> Wenn man alles auf einmal ausrollt, ist es sehr schwer herauszufinden, was gewirkt hat 16:38 <tmp> *seufz* 16:38 * tmp träumt von IRC‑Stabilität. 16:39 <jrandom> ja, an allen Fronten ;) 16:39 <+fox> <roderick_spod1> Roderick träumt von großen Titten. 16:39 <jrandom> (deshalb können wir die Meeting‑Logs filtern... ;) 16:40 <jrandom> ok, hat noch jemand etwas zu 1) Netzstatus und 0.6.1.18? 16:41 <jrandom> wenn nicht, springen wir rüber zu 2) 16:42 <jrandom> hier nicht viel mehr hinzuzufügen, nur ein Status‑Update zu etwas w32/w64‑Unterstützung 16:43 <jrandom> wie in der Mail erwähnt, scheint gcj unter mingw derzeit nicht wirklich praktikabel zu sein, auch wenn wir vielleicht ein paar Tricks ziehen können 16:44 <jrandom> es gibt ein älteres 3.4.4/3.4.5‑gcj, das unter mingw funktioniert, aber die Classpath‑Unterstützung darin ist ziemlich alt. 16:45 <jrandom> (und selbst nachdem wir eine Menge aus hsqldb herausgestrippt haben, gibt es noch einige Abhängigkeiten, die 3.4.5 nicht erfüllt. aber vielleicht können wir die auch noch raushacken... falls nötig) 16:47 <jrandom> ok, wenn es sonst nichts gibt, gehen wir weiter zu 3) ??? 16:47 <jrandom> hat noch jemand etwas fürs Meeting? 16:48 <cervantes> nur um „nice one, bar“ zu sagen für seine coole Spende 16:48 <+Complication> Nun, es gab eine Frage im Forum zu Uptime‑Werten (Betriebszeit), die in NetDB dargestellt werden... 16:48 * Complication unterstützt das 16:49 <+Complication> Wegen der Uptime: falls du dich erinnerst, habe ich sie im März leicht verschleiert... 16:49 <cervantes> muss ich wohl zwischen den odci.gov‑Rants verpasst haben 16:50 <tmp> Was um Himmels willen machst du auf der Seite, roderick_spod? 16:50 <jrandom> ja Complication 16:50 <+Complication> Nun, da die Frage aufkam, habe ich mich gefragt, ob man sie weiter verschleiern könnte, oder würde das die Fähigkeit zu debuggen beeinträchtigen? 16:52 <jrandom> ich bin mir nicht sicher, was der Punkt ist – mit sorgfältiger Analyse können alle Statistikdaten eine Menge Informationen preisgeben 16:52 <arse> glaubt ihr, dass die Periodizität des Netzwerks nachlassen wird 16:52 <jrandom> wenn es soweit ist, schalten wir die Veröffentlichung der Statistiken einfach komplett ab 16:52 <+Complication> Wir hatten in letzter Zeit keine, die den router neu starten, aber das ist erst seit Kurzem so... 16:52 <jrandom> arse: ja 16:52 <+Complication> (und teilweise, weil der Watchdog keine Zähne hat) 16:54 <+Complication> Stimmt, es ist ziemlich unvermeidlich, dass in dieser Phase einige Infos draußen sind 16:55 <jrandom> außerdem ist die Annahme, die sie getroffen haben, nicht korrekt, publishedTimeAgo ist, wie lange es her ist, dass der router den netDb‑Eintrag /empfangen/ hat, nicht wann er signiert wurde 16:55 <jrandom> ähm, Moment, nein, das stimmt nicht 16:56 <jrandom> ignoriert mich. ja, es fügt nur eine kleine Variation hinzu 16:56 <+Complication> Heh, ich versuche gerade, eine Antwort zu posten, bekomme aber derzeit „no post mode specified“ 16:57 <+Complication> Ja, da ist Verzögerung im Spiel, und außerdem: Wie oft wurde diese Info veröffentlicht? Nicht sehr häufig, IIRC? 16:57 <+Complication> Kurz gesagt: Wenn ich anbieten würde, die Genauigkeit dort etwas zu verringern, wäre das ok? 16:58 <jrandom> ein neuer signierter Eintrag wird alle 5–15 Minuten veröffentlicht, aber das geht nur an die netDb, nicht an alle Peers 16:58 <jrandom> Peers bekommen die aktualisierte Version erst, wenn sie entweder danach suchen oder sie sich neu verbinden 16:59 <jrandom> aber ja, mehr Variation hinzuzufügen ist ok. das würde stat.i2p's Uptime‑Diagramme beeinflussen, aber solange es im Rahmen bleibt, ist das cool 17:01 <+Complication> Ich versuche, es im Rahmen zu halten :) 17:01 <jrandom> heh, cool, danke Complication 17:04 <jrandom> *hust* (und konsistent ;) ok, hat noch jemand etwas fürs Meeting? 17:04 <+Complication> Nebenbei: nett, der „post mode“-Bug hat der Hartnäckigkeit nachgegeben, und ich konnte auch eine Antwort posten :) 17:05 <jrandom> w3rd Complication <i>Offtopic‑Nachrichten entfernt</i> 17:08 <jrandom> ok, wenn es sonst nichts gibt... 17:08 * jrandom holt aus 17:09 * jrandom *baf*t das Meeting