اجتماع مطوري I2P - 30 مايو 2006

16:00 <jrandom> 0) مرحبًا 16:00 <jrandom> 1) حالة الشبكة 16:00 <jrandom> 2) تصفية النظراء 16:00 <jrandom> 3) حالة Syndie 16:00 <jrandom> 4) ??? 16:00 <jrandom> 0) مرحبًا 16:00 * jrandom يُلوّح 16:01 <jrandom> تم نشر ملاحظات الحالة الأسبوعية على @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html 16:01 <jrandom> (مبكّرة بساعة حتى [أو متأخرة بضعة أسابيع، إذا أردتم مضايقتي ;]) 16:02 <jrandom> حسنًا، لننتقل مباشرةً إلى 1) حالة الشبكة 16:02 <jrandom> الأمور ليست بالشكل الذي ينبغي أن تكون عليه. إنها أفضل مما كانت عليه أثناء انهيار الازدحام، لكنها ينبغي أن تكون أفضل مما هي عليه الآن 16:03 <jrandom> لا يوجد لدي الكثير لأضيفه حول ذلك، ما لم يكن لدى أي شخص أسئلة/مخاوف بشأن 1)؟ 16:03 <@frosk> أحصل على أيام من اتصال IRC مع .19، لذا لا شكاوى هنا 16:04 <jrandom> جميل 16:04 <jrandom> نعم، هو جيد للبعض، لكنه ليس جيدًا بما يكفي ولا ثابتًا بما يكفي. الإحصاءات في قاعدة البيانات لا تبدو رائعة أيضًا 16:06 <jrandom> حسنًا، هل لدى أحد أي شيء آخر حول 1) حالة الشبكة، أم ننتقل إلى 2) تصفية النظراء؟ 16:07 <jrandom> [أدخل أصوات الحركة هنا] 16:09 <jrandom> كما ذُكر في البريد، خلاصة الأمر هي إعطاء عملية اختيار النظراء لدينا دفعة بسيطة. في البداية، سيكون ذلك محفوفًا ببعض المخاطر، إذ يتيح بعض هجمات التقسيم النشطة، لكن إذا عمل كما آمل، فيمكننا تجنّب ذلك 16:10 <jrandom> (لكن تجنّبه يتطلّب عمليًا قتل جميع هويات router، وهو ما سيؤدي فعليًا إلى إعادة ضبط للشبكة، لذلك أفضّل تجنّب ذلك ما لم يكن مجديًا) 16:11 <bar> إعادة ضبطها مرة واحدة أم بشكل متكرر؟ 16:11 <bar> s/reset/killing 16:11 <jrandom> على الأقل مرة واحدة، وكذلك عند كل تغييرات الإعدادات الجذرية اللاحقة 16:12 <jrandom> (أي وضع بعض المعايير في شهادة هوية router، مما يعني بدوره تغيير تجزئة المُعرِّف، بحيث لا يمكنهم التظاهر بدفع إعداد واحد لبعض الناس وآخرين لآخرين) 16:13 <bar> فهمت 16:14 <jrandom> حسنًا، لا أظن أن لدي شيئًا آخر حول هذا الموضوع حاليًا، ما لم يكن لدى أحد أسئلة/تعليقات/مخاوف؟ 16:15 <jrandom> (نأمل أن يتوفّر بناء خلال يوم أو يومين، وإصدار بعد أن يستقر) 16:17 <jrandom> حسنًا، نمرّ سريعًا على 3).. 16:18 <jrandom> Syndie تتقدّم، وعلى الرغم من أن معركة amd64/amd32/x86/swt/gcj لم تكن جميلة دائمًا، سيكون لدينا بناء جاهز في يونيو 16:19 <jrandom> (لكن لا تزالوا لا تتحدثوا معي عن mingw/gcj ;) 16:19 <jrandom> لا يوجد لدي الكثير لأضيفه هناك في الوقت الحالي، ما لم يكن لدى أحد أسئلة/مخاوف بخصوص إعادة تصميم Syndie؟ 16:21 <@cervantes> كيف يتقدّم دعم mingw/gcj؟ 16:21 <@cervantes> *ينخفض* 16:22 <@cervantes> هل سنحصل على بعض لقطات الشاشة قبل إصدار يونيو؟ :) 16:23 <jrandom> أنا متأكد أنني سأحاول استقطاب بعض المتطوّعين المتحمّسين لاختبارات ما قبل الإصدار ;) 16:23 <tethrar> احسبني معكم ;) 16:23 <jrandom> w3wt 16:24 <jrandom> حسنًا، لننتقل إلى البند الذي أعلم أنكم كنتم تنتظرونه: 4) ??? 16:24 <jrandom> ما الأخبااار؟ 16:24 <green> هل هناك خطة لامتلاك I2P router يعمل «فعليًا» مع Via C7؟ jbigi يقدّم تحسّنًا بنسبة 30% فقط مقارنةً بـ Java الكاملة 16:25 <jrandom> هل ما زالت نسبة 30% مكلفة على المعالج؟ ما الذي يجعله غير «فعلي»؟ 16:25 <jrandom> لكن لا، ليست لدي مهارات الرياضيات أو مهارة assembly لـ C7 لصنع libGMP أفضل لـ C7. 16:25 <green> بالتأكيد مُجهِدة للمعالج مع حمل 100% على المعالج :P 16:26 <jrandom> وصول استهلاك المعالج إلى 100% يوحي بأن المشكلة ليست في jbigi، بل في أن jbigi يُستخدم بكثرة شديدة 16:26 <jrandom> ومن أجل ذلك، نعم، لدينا الكثير في الطريق. 16:26 <jrandom> (مثلاً: تقليل إعادة إنشاء الاتصالات، وتحسين معدلات نجاح بناء tunnel، إلخ) 16:27 <jrandom> ((وألّا تصل طلبات tunnel بأعداد كبيرة إذا لم يكن router قادرًا على التعامل معها)) 16:29 <green> هممم، هذا على جهاز مخصّص بسرعة 100Mb/s لذا ينبغي أن يكون قادرًا 16:30 <jrandom> لا، النطاق الترددي ليس المورد الوحيد المقيّد هنا، فالمعالج واضح أنه كذلك ;) 16:33 <jrandom> حسنًا، هل لدى أحد أي شيء آخر للاجتماع؟ 16:36 <jrandom> *يسعل* 16:37 * jrandom يستعد 16:37 * jrandom *baf*s يُغلِق الاجتماع