I2P Geliştirici Toplantısı - 30 Mayıs 2006

16:00 <jrandom> 0) merhaba 16:00 <jrandom> 1) Ağ durumu 16:00 <jrandom> 2) Eş filtreleme 16:00 <jrandom> 3) Syndie durumu 16:00 <jrandom> 4) ??? 16:00 <jrandom> 0) merhaba 16:00 * jrandom el sallar 16:01 <jrandom> haftalık durum notları burada yayınlandı @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html 16:01 <jrandom> (hatta bir saat erken [ya da beni iğnelemek istersen birkaç hafta geç ;]) 16:02 <jrandom> tamam, 1) Ağ durumu'na dalalım 16:02 <jrandom> durumlar olması gerektiği gibi değil. tıkanıklık çöküşü sırasındakinden daha iyi, ama şu ankinden daha iyi olmalı 16:03 <jrandom> yine de buna ekleyecek çok bir şeyim yok, 1) hakkında sorusu/endişesi olan var mı? 16:03 <@frosk> .19 ile günlerce IRC bağlantım sürüyor, o yüzden burada şikayet yok 16:04 <jrandom> güzel 16:04 <jrandom> evet, bazıları için iyi, sadece yeterince iyi ya da yeterince tutarlı değil. veritabanındaki istatistikler de pek iyi görünmüyor 16:06 <jrandom> tamam, 1) Ağ durumu hakkında başka bir şey var mı, yoksa 2)Eş filtreleme'ye geçelim mi? 16:07 <jrandom> [buraya hareket sesleri ekleyin] 16:09 <jrandom> e-postada belirtildiği gibi, işin özü eş seçimimize biraz ivme kazandırmak. ilk başta biraz tehlikeli olacak, bazı aktif bölümlendirme saldırılarına izin verecek, ama umduğum gibi çalışırsa bunlardan kaçınabiliriz 16:10 <jrandom> (ama bundan kaçınmak esasen tüm router kimliklerini öldürmeyi gerektirir ki bu da temelde bir ağ sıfırlaması olur, bu yüzden buna değmeyecekse bundan kaçınmak isterim) 16:11 <bar> bir kez mi sıfırlamak gerek yoksa tekrar tekrar mı? 16:11 <bar> s/reset/killing 16:11 <jrandom> en az bir kez, ayrıca sonraki tüm köklü yapılandırma değişikliklerinde 16:12 <jrandom> (yani router kimliğinin sertifikasına bazı ölçütler koymak; bu da ident hash'ini değiştirmek anlamına gelir, böylece bir ayarı bazı insanlara, başkalarını başkalarına itiyormuş gibi yapamazlar) 16:13 <bar> anladım 16:14 <jrandom> tamam, şu an o konuda başka bir şeyim olduğunu sanmıyorum, sorusu/yorumu/endişesi olan var mı? 16:15 <jrandom> (umarım bir iki gün içinde bir build çıkar, istikrara kavuşunca da yayımlanır) 16:17 <jrandom> tamam, kısaca 3)'e değinelim.. 16:18 <jrandom> Syndie ilerliyor ve amd64/amd32/x86/swt/gcj savaşı her zaman güzel olmasa da, haziranda hazır bir build'imiz olacak 16:19 <jrandom> (ama yine de bana mingw/gcj'den bahsetme ;) 16:19 <jrandom> şimdilik orada ekleyecek pek bir şeyim yok, Syndie yenilemesiyle ilgili sorusu/endişesi olan var mı? 16:21 <@cervantes> mingw/gcj desteği nasıl gidiyor? 16:21 <@cervantes> *eğilir* 16:22 <@cervantes> haziran sürümünden önce biraz ekran görüntüsü alacak mıyız? :) 16:23 <jrandom> eminim bazı hevesli gönüllüleri ön sürüm testine dahil etmeye çalışacağım ;) 16:23 <tethrar> beni de yaz ;) 16:23 <jrandom> w3wt 16:24 <jrandom> tamam, hepinizin beklediğini bildiğim maddeye geçelim: 4) ??? 16:24 <jrandom> n'aber? 16:24 <green> Via C7 ile "gerçek" çalışan bir I2P router için herhangi bir plan var mı? jbigi, tam Java'ya göre yalnızca %30 daha iyi 16:25 <jrandom> %30 hâlâ CPU açısından çok mu yoğun? onu ne "gerçek" yapmıyor? 16:25 <jrandom> ama hayır, C7 için daha iyi bir libGMP yapmak üzere matematik ya da C7 asm becerisine sahip değilim. 16:25 <green> 100% CPU yüküyle elbette çok CPU yoğun :P 16:26 <jrandom> %100 CPU yükü, sorunun jbigi değil, jbigi'nin çok fazla kullanılmak zorunda olması olduğunu düşündürüyor 16:26 <jrandom> ve bunun için, evet, yolda bir sürü şeyimiz var. 16:26 <jrandom> (ör. bağlantı yeniden kurulumlarını azaltmak, tunnel kurulum başarı oranlarını iyileştirmek, vb.) 16:27 <jrandom> ((ve router bunları kaldıramıyorsa bu kadar çok tunnel isteği almamak)) 16:29 <green> hımm, bu 100Mb/s'lik ayrılmış bir makinede, yani kaldırabilmesi gerekir 16:30 <jrandom> hayır, burada kısıtlı olan tek kaynak bant genişliği değil, açıkça CPU da öyle ;) 16:33 <jrandom> tamam, toplantı için başka bir şey var mı? 16:36 <jrandom> *öksürür* 16:37 * jrandom toparlanır 16:37 * jrandom toplantıyı *baf* kapatır