I2P Geliştirici Toplantısı - 1 Ağustos 2006

16:02 <jrandom> tamam, bunu başlatalım bari 16:03 <jrandom> merhaba, toplantı öncesi notları şuraya koydum: http://dev.i2p.net/pipermail/i2p/2006-August/001304.html 16:03 <jrandom> o mesajı burada size tekrar okumam yerine, doğrudan standart ??? bölümümüze atlayalım - 16:04 <jrandom> gündeme getirip tartışmak istediğiniz bir şey var mı? 16:04 <@cervantes> ııı 16:04 * cervantes gönderiyi okumak için aceleyle koşturur 16:05 <+Complication> Ağ durumuyla ilgili olarak, burada her şey yolunda... 16:05 <+Complication> Ama NTCP taşıması hakkında bir soru (aslında forumdan aktarıyorum), 16:06 <+Complication> yani, bunu etkinleştirmenin birilerinde CPU yükü sorunlarına yol açması olası mı gibi geliyor (XP kullanıyorlardı)? 16:06 <@cervantes> Şunu söylemeliyim ki, geçiş yaptığım beri aslında daha düşük CPU kullanımı görüyorum :) 16:07 <jrandom> şey, onu *devre dışı bırakamazsınız* (kaynak kodu okuyup sihirli sözleri bilmiyorsanız ;) 16:07 <+Complication> Bu sorundan bahseden kişi (kolay tekrar edemiyor ve burada büyük CPU kullanımı yok) yüksek CPU kullanımının NTCP ile ilişkili göründüğünü söyledi 16:07 <jrandom> yani, sanırım gelen NTCP bağlantılarını kabul etmemekten bahsediyorlar 16:07 <+polecat> NTCP benim router'ımın CPU'yu anında sonuna kadar zorlamasına neden oluyor ve çalışır bir router elde etmek için yapılandırma dosyasını elle değiştirmek zorunda kalmadan önce bunu iki kez tekrarladım. 16:07 <jrandom> (giden NTCP bağlantılarını kullanmaya devam ederken) 16:07 <+Complication> (burada normal seviyelerin yalnızca biraz üstünde ve muhtemelen çok daha fazla veri aktardığım için) 16:08 <+Complication> ( http://forum.i2p/viewtopic.php?t=1815 ) 16:08 <jrandom> bir NTCP bağlantısı kurduğunuzda, ağır bir kripto hesaplaması (ya da üç) yaparsınız 16:08 <jrandom> gelen NTCP bağlantılarını kabul ediyorsanız, dışarıda yüzlerce i2p router olduğu için bir anda çok sayıda gelen deneme alabilirsiniz 16:09 <jrandom> polecat: bu NTCP'nin suçu değildi, ntp havuzundaki bozuk bir ntp sunucusunun suçuydu 16:09 <+polecat> Evet. Demek ki bunu kendim halledemiyorum, görünüşe göre. 16:09 <jrandom> (o ntp sunucusunu bulup havuzdakilere onları !thwap ettirdiği için cervantes'e teşekkürler :) 16:10 <jrandom> ((ve gelecekte o çılgın heriflerden kaçınmamızı sağladığı için Complication'a da :)) 16:10 <@cervantes> heh sanırım sunucu bekçileri sadece hafta içi çalışıyor ;-) 16:10 <+Complication> Şu anki kaçınma oldukça sınırlı 16:10 <@cervantes> http://www.pool.ntp.org/scores/216.52.237.153 16:11 <+Complication> Eninde sonunda daha paranoyak bir şey kodlamayı umuyorum 16:11 <+polecat> Aa, yani NTCP'yi etkinleştirmek artık CPU'yu sonuna kadar zorlamayacak mı? 16:11 <jrandom> (hiç yapmadı polecat, tesadüftü ;) 16:12 <+Complication> "clock" hangi anlamda? 16:12 <jrandom> (cervantes'in bağlantısına bak) 16:12 * polecat Complication'ın kafasına bir tane 'clock' çakar. 16:12 <@cervantes> ne içiyorsun polecat 16:12 <+Complication> :P 16:12 <+polecat> Şey, yani, tüm saat çevrimlerini çaldı demek istiyorum. :) 16:13 <+Complication> 30 saniye ileriye ya da geriye sıçradıysa, pek çok oturumu kaybetmiş ve her türlü ağır, çok ağır kriptoya başvurmuş olabilir 16:13 <+Complication> Bence bu bir sürü CPU çevrimi çalabilir 16:13 <+Complication> Aslında belki forumdaki kişi de aynısını gördü ve yanlış ilişkilendirdi? Sormak lazım... 16:13 <jrandom> ah.. yani, geçerli gelen NTCP bağlantılarındaki patlamalar CPU patlamalarına yol açar, oysa sadece giden NTCP aynı anda yalnızca belirli sayıda yeni NTCP eşle konuşmaya çalışır 16:14 <jrandom> gelen NTCP'yi etkinleştirmemekte yanlış bir şey yok. 16:15 <@cervantes> Complication: sunucu pazartesi ortasında düzeltilmişti, o zamandan beri sorun yaşayıp yaşamadıklarına bakmaya değer olabilir 16:15 <jrandom> tamam, başka tartışmak istediği bir şeyi olan var mı? 16:16 <+Complication> cervantes: evet, denemeye değer olabilir 16:16 <@cervantes> Bazı kişilerin hâlâ periyodik olarak lease kaybettiğine dair bildirimler aldım... bu bilinen bir sorun mu? 16:16 <+void> NTCP uygulaması SSU'dan ne kadar farklı? 16:17 <+polecat> Lease kaybedip kaybetmediğimizi nasıl anlarız? 16:18 <jrandom> void: NTCP'de mesaj başına biraz daha yüksek bant genişliği ek yükü var (ancak muhtemelen işletim sisteminin muhtemelen daha verimli güvenilir aktarım uygulamasıyla dengelenir) 16:18 <+Complication> polecat: tunnels.jsp belirli bir tunnel havuzu için hiçbir tunnel göstermeyecektir (ör. "shared clients") 16:18 <jrandom> cervantes: evet, tunnel oluşturma başarı oranlarımız hâlâ olması gereken yerde değil 16:18 <+void> polecat: router konsolu öyle der 16:18 <+Complication> Ve void'in dediği gibi, konsolun sol kenar çubuğu bunu gösterecek 16:19 <+polecat> Bu "No leases" mesajlarını çok alıyorum... kastettiğin bu, değil mi? 16:19 <@cervantes> evet 16:20 <+polecat> Genelde IRC bağlantımı öldüren bu oluyor. Normal sanıyordum! 16:21 * jrandom irkilir 16:24 <+tethra> lol ;) 16:25 <jrandom> tamam, toplantı için başka bir şey var mı? 16:25 <@cervantes> jrandom: son zamanlarda Syndie üzerinde ilerleme kaydettin mi yoksa ntcp/hata düzeltme/ISP avcılığı/bisiklet sürme ile mi meşguldün? 16:27 <+tethra> feedspace hakkında bir haber var mı, yoksa doğrudan onların eepsite'ına mı gitmeliyim? 16:28 <jrandom> canlı ağ boka sardığında Syndie'yi bir kenara ittim. Ama ağ yeniden rayına oturmaya başlayınca Syndie zamanımı tekrar almaya başladı ve yakında küçük bir CLI sistemi çıkaracağımı umuyorum (ardından kullanıcı geri bildirimlerine göre odaklı GUI'ler gelecek) 16:28 <jrandom> (uygulanmış SWT GUI oldukça iyi durumda, ancak beklentileri ayarlamak için muhtemelen CLI ile başlamak en iyisi) 16:29 * jrandom feedspace hakkında bir haber duymadı 16:29 <@cervantes> güzel 16:29 <jrandom> frosk: bir gelişme var mı? :) 16:29 <+polecat> Syndie üzerinde tekrar çalışmana sevindim. Yeni sürüm oldukça umut verici görünüyor. Bir düğümden blog silme veya yönetimsel hesap-bağımsız görevler gibi şeyler için ACL (Access Control List - erişim kontrol listesi) hakkında düşüncelerin var mı? 16:30 <@cervantes> <jrandom> DELETE FROM messages WHERE postedOn <NOW()-14*24*60*60; 16:31 <jrandom> yerel arşivler muhtemelen esasen güvenilir kalacak (çünkü yerel arşiv veritabanına erişebiliyorsanız, dosyayı istediğiniz gibi değiştirebilirsiniz) 16:32 <jrandom> ancak paylaşılan bloglar için, gönderileri ve değişiklikleri kimlik doğrulamak ve/veya yetkilendirmek üzere mevcut olan bir dizi kripto yapısı var 16:33 <jrandom> (ama insanların 'yetkisiz' gönderileri de görmesinin bir yolu olacak, ancak bunlar oldukça kenarda kalacak) 16:33 <+polecat> Biri syndicate'leri binlerce dev blog gönderisiyle doldurduğunda, gönderileri fiziksel olarak silme tekniğinin mükemmelleşeceğine eminim. 16:34 <+tethra> heheh 16:35 <jrandom> fiziksel silme önemsiz, esas soru ilk etapta hangi gönderileri kabul edeceğimiz ;) 16:36 <jrandom> (Syndie'yi bir film dağıtım platformuna vs. dönüştürmek gibi bir ilgim yok) 16:36 <+polecat> Kabul ettiği şeyden, bir örnek kabul edilene kadar emin olunamaz. Yalnızca beyaz listedeki bloglara izin vermek ve yeni kimlikleri eklemeden önce deneme esasına göre kabul etmek, spam ihanetinde anında silmek gibi bir şey hayal ediyorum. 16:36 <jrandom> evet 16:37 <+polecat> Ben, sohbet akışlarını bir araya getirme uygulamasına daha çok ilgi duyuyorum: ortak bir etiketten başka merkezi sunucusu olmayan bir BBS yapabiliriz! 16:37 <jrandom> (yeni kimliklere elle izin verme, flood yapan kimlikleri elle kick-ban etme, vs.) 16:37 <jrandom> hatta kriptoda bunun için doğuştan destek bile var polecat :) 16:37 <+polecat> Muhtemelen bir moderatörün BBS için onaylanan mesajları imzalaması ve insanların bu onay listelerini moderatörün blogundan toplaması. 16:38 <+polecat> Oo mükemmel. 16:38 <@frosk> jrandom: son zamanlarda GUI işleri üzerinde çalışıyorum, ama yeni bir işe başlamakla birleştirmek zor oldu :( 16:39 * cervantes frosk'un kovulması için İnsan Kaynakları ile iletişime geçer 16:40 <jrandom> ah süper, umarım Syndie ortalıkta yamalı HTTP syndication yapmaya başlayınca seni buna tekrar heveslendiririz ;) 16:40 <@frosk> en azından patronum artık i2p geliştirmesini takip ediyor :) 16:40 * jrandom frosk'un patronuna el sallar 16:40 <@frosk> oh evet, hâlâ kararlıyım (kahretsin!) :) 16:40 <jrandom> (frosk'a daha fazla izin verir, ona ihtiyacımız var!) 16:41 <@cervantes> umarım Syndie bloguna gizli şirket bilgileri gönderdiğini okumaz 16:41 <bar> GUI iyidir, GUI severiz. Affedildin. 16:41 <+Complication> Hehe :) 16:41 <@frosk> ofisine girip onu Syndie okurken yakalamak tuhaf :) 16:41 <jrandom> hah harika 16:42 <+polecat> Tebrikler frosk, utanç ve rezillikle kovulsan bile en azından bir kişiye daha Syndie'nin ne kadar havalı olabileceğini gösterdin. 16:43 <@frosk> hehe evet 16:43 <+tethra> haha 16:44 <@frosk> GUI (SWT içinde) feedspace ile ilgili her şey için bir test yatağıdır/olacaktır, onu başlatmak için 16:44 <jrandom> r0x0r 16:45 <+void> jrandom: belki posta listelerine giden her şeyi Syndie'ye de çapraz gönderim yapmalısın? 16:45 <jrandom> bunu tamamen Syndie SWT GUI ile birleştirmeliyiz (temel paradigma bir tarayıcı, ancak sekmelerde HTML sayfaları görüntülemiyor) 16:46 <+polecat> Güzel olurdu. Artık posta listesini alamıyor gibiyim. 16:46 <jrandom> void: birinin procmail'i Syndie CLI'ına yönlendirmek için küçük bir shell script yazması oldukça kolay olur 16:46 <@cervantes> bu süslü SWT GUI'ler uygulamalara mı bağlı? yoksa CLI yürütülebilirleri için üst arabirimler (top) mi, yoksa TCP kullanıyorlar mı vs. vs. 16:46 <@frosk> mantıklı 16:46 <jrandom> (yanlış hatırlamıyorsam bir süre önce blogumda Syndie CLI kullanarak nasıl gönderi eklenileceğini açıklayan bir yazı var) 16:47 <+polecat> Şu anda Syndie'ye beslemek üzere RSS akışları oluşturulabiliyor, gerçi hâlâ biraz hantal. 16:47 <jrandom> cervantes: olay işleyicilerinde JDBC, elbette JNI ve MSVC çağrılarıyla satır içi ;) 16:47 * jrandom eğilir 16:48 <+polecat> Microsoft Visual Classes? 16:49 <@cervantes> jrandom: o zaman SQL konuşabilen herhangi bir şey Syndie'yi yönetebilir 16:49 <jrandom> (Syndie'nin açısından bakıldığında, işlevlerin tümü temelde JDBC veritabanını güncelleyen bir sürü küçük CLI uygulamasında uygulanmıştır ve veritabanında gezinmek için bir SWT UI var) 16:51 <+polecat> Ve veritabanının iki arabirimi olduğuna göre, JDBC ve SQL, bu iki protokolden biriyle iletişim kuran bir istemci Syndie'yi karıştırabilir. 16:51 <jrandom> cervantes: hem evet hem hayır - veritabanının iyi bir kısmı şifreli, dolayısıyla tüm alanlar okunabilir değil 16:51 <+void> mevcut web arayüzü hâlâ orada olacak mı? 16:51 <jrandom> (jdbc == sql) 16:51 <jrandom> void: hayır 16:51 <+polecat> JDBC'nin aptal bir insan tarafından okunabilir protokol olmadığını söylemiştin sanıyordum? 16:51 <+Complication> jdbc == java database interface, belki biraz odbc'ye benzer 16:51 <jrandom> ((jdbc ~= sql)) 16:51 <+Complication> Üzerinden SQL konuştuğun bir şey 16:52 <+void> jrandom: syndie.i2p/syndiemedia.i2p.net'e ne olacak? 16:52 <+polecat> Ah. Neyse, kayıt için söyleyeyim, zaten SQL'i hiç sevmedim. 16:52 <@cervantes> jrandom: yani veriyi kendin sömürmeye çalışmaktansa syndieTools (tm) için bir üst (top) oluşturmak en iyisi 16:53 <jrandom> void: zaman gösterecek. muhtemelen 1) Syndie'nin web sitesi/eepsite'ı olarak hizmet edecekler, 2) syndication yapılacak gönderilerin genel bir arşivi olarak hizmet edecekler ve nihayetinde bir web arayüzü yazıldığında 3) bir web arayüzü sunacaklar 16:53 <+polecat> Neden ilkel COBOL ifadeleri yerine veritabanı sorguları olarak bayt kodu göndermiyoruz? 16:53 <jrandom> evet cervantes 16:53 <jrandom> !lart polecat 16:54 <+void> hehehe 16:54 <+polecat> Ah, gizli zayıflığım. 16:54 <@cervantes> * envanterinde 6 lart kaldı, kuzeyde bir kapı ve yerde baygın bir polecat var 16:54 <jrandom> cervantes: bu aslında CLI uygulaması #3 (tekil gönderileri çıkarma, ki bu #2 uygulamasından sonra gelir, tekil gönderileri listeleme ( #1'den sonra, tekil gönderiler oluşturma ve #0'dan sonra, takma adları (nyms) yönetme))) 16:54 <jrandom> lol 16:54 <+tethra> haha 16:55 <+Complication> özellik önerisi: bayt kod yerine neden canlı $agency ajanlarını veritabanı sorguları olarak göndermiyoruz? ;P 16:56 <+Complication> Güvenlik açısından doğrulaması çok daha kolay olur :P 16:56 <@cervantes> jrandom: anladım 16:56 <+tethra> doğru iklimde posta güvercinleri gibi davranırlar mı, Complication? 16:56 <+Complication> tethra: yalnızca onları TCP yığını boyunca sağlam bir şekilde itebilmeyi başarırsan :P 16:56 <+polecat> Evet, CPP üzerinden veritabanı sorguları! 16:57 <+Complication> TCP'de buruşmalarının onları bozabileceğini hayal ediyorum 16:58 <+Complication> (üzgünüm, şakaları gerçekten #i2p-chat'te tutmalı, ama bazen kendimi tutamıyorum) 16:58 * cervantes yakında bir baff'ın yaklaştığını hisseder 16:58 <+Complication> veritabanı sorguları shellcode olarak mı? 16:59 <jrandom> tamam, toplantı için başka bir şey var mı? 16:59 <+polecat> http://www.blug.linux.no/rfc1149/ <- bunun üzerinden gerçekten i2p'yi tunnel edebiliriz. 16:59 * Complication SQL ile kalmayı tercih eder 17:00 <+void> jrandom: java dışındaki diğer dillerin hsqldb veritabanları için kitaplıkları var mı? 17:01 <+Complication> Görünüşe göre kullanıyor oldukları için OO'nun olması muhtemel görünüyor 17:01 <+void> bana "hayır" gibi görünüyor 17:01 <+void> oh, hmm 17:01 <@cervantes> openoffice kullanıyor, bu yüzden öyle olduğunu varsayarım 17:01 <+Complication> Ama OpenOffice'in hangi dille yazıldığından emin değilim 17:01 <jrandom> bildiğim kadarıyla yok. ama biri Syndie'yi başka bir JDBC veritabanına (mysql, oracle, vb.) karşı çalıştırabilir 17:01 <jrandom> oo java kullanıyor 17:02 <+void> openoffice bu veritabanını tam olarak ne için kullanıyor? 17:02 <+Complication> Ama yalnızca kısmen kullanıyor gibi görünüyor 17:02 <jrandom> void: pdf üretimi ve Access benzeri veritabanı uygulamaları için 17:02 <jrandom> (başka şeylerin yanı sıra) 17:02 <+Complication> Harici bir JRE önermesini göz önüne alırsak 17:02 <+void> tamam 17:03 <+void> taşınabilir SQL yazmak ise tam bir baş belası 17:03 <+Complication> tetikleyiciler veya saklı yordamlar yapılmazsa, çok da büyük bir dert olmamalı gerçi 17:04 <jrandom> eh, o kadar da kötü değil ve dışsallaştırması kolay 17:04 <+void> özellikle hedef Oracle olunca ;) 17:05 <jrandom> aslında hsqldb pl/sql'i destekliyor ;) 17:06 <bar> bu veritabanı için istatistikler, eş profilleri, netdb.. gibi başka planlar var mı? 17:06 <jrandom> hayır, bu yalnızca Syndie için 17:06 <bar> tamam 17:07 <jrandom> (hsqldb kodunu dağıttığımızda, i2p içinde 'bedavaya' kullanabiliriz gerçi) 17:07 <@cervantes> Syndie bir I2P uygulaması değil, yalnızca I2P üzerinden çalışabilen bir uygulama, doğru mu? 17:07 <jrandom> evet cervantes, i2p'ye bağımlılık yok 17:07 <+Complication> Syndie'yi taşınabilir tutmak iyi, çünkü I2P dışında başka taşıma yöntemleri de olabilir 17:07 <bar> doğru 17:08 <+Complication> Ancak, aynı makinede birçok hsqldb örneğini çalıştırmanın zor olmadığını düşünüyorum 17:08 <+Complication> Yani diğer uygulamalar buna ihtiyaç duyarsa, sanki kullanabilirler gibi görünüyor 17:08 <jrandom> çok basit ve yalnızca JVM içi veritabanını kullanırsanız maliyeti 0 17:08 <+Complication> (tercihen kendi örneklerini kullansınlar) 17:10 <+void> sqlite için jdbc sürücüsü yok mu? 17:11 <jrandom> bilmiyorum, hiç kullanmadım 17:11 <+void> ah, bir *şey* var gibi görünüyor 17:13 <jrandom> tamam, toplantı için başka bir şey? 17:13 <jrandom> yoksa... 17:13 * jrandom dinws up 17:13 * jrandom geri çekilir 17:13 * jrandom hız alır 17:13 * jrandom toplantıyı *baf*'layarak kapatır