اجتماع مطوري I2P - أبريل 04، 2006

16:21 <jrandom> 0) مرحباً 16:21 <jrandom> 1) حالة الشبكة و 0.6.1.14 16:21 <jrandom> 2) التخطيط لـ Syndie 16:21 <jrandom> 3) تحسينات jbigi المحلية 16:21 <jrandom> 4) ؟؟؟ 16:21 <jrandom> 0) مرحباً 16:21 * jrandom يلوّح 16:21 <jrandom> تم نشر ملاحظات الحالة الأسبوعية على http://dev.i2p.net/pipermail/i2p/2006-April/001275.html 16:21 * Complication يقرأ 16:22 <jrandom> بينما تقرأون ذلك المنشور (المُعدّ بسرعة)، دعونا ننتقل إلى 1) حالة الشبكة 16:23 <@cervantes> (عاد المنتدى) 16:23 <jrandom> هناك بعض المشاكل تؤثر على الاستخدام في 0.6.1.13، وقد تم تعقب معظمها وحلها 16:24 <Complication> لدي هنا، مع بنية CVS «الرابعة»، لاحظت تغييراً في الرسوم البيانية لدي 16:24 <jrandom> لا تزال هناك بعض العثرات يجري اختبارها وإعادة صياغتها، لكن من المفترض أن تصدر نسخة خلال الأيام القليلة المقبلة 16:24 <Complication> بوجه عام، اتجهت الأمور نحو مزيد من الاستقرار وأقل تذبذباً 16:24 <jrandom> يا للمصيبة، لقد نسيت زيادة الرقم إلى ‎-4، أليس كذلك؟ 16:24 <jrandom> (حسناً، ‎-5 ستصدر في وقت لاحق هذا المساء) 16:24 <jrandom> رائع يا Complication 16:25 <Complication> لكن انطباعاتي قد تكون متأثرة أيضاً بـ jbigi، إذ لم أتخذ خطوات لاستبعاد ذلك 16:25 <Complication> الآن، بعد فترة، انخفضت إعادة الإرسال إلى 15% أيضاً 16:28 <jrandom> هممم، أرى أيضاً أن متوسط SSU RTO لدي يقترب من سقف 3 ثوانٍ 16:28 <jrandom> (مع ذلك، إعادة الإرسال لا تزال منخفضة جداً، أقل من 5%) 16:29 * Complication يلقي نظرة ثانية عليه 16:29 <Complication> لنقل إن المتوسط الخام يزيد قليلاً عن 1500 16:29 <Complication> (هنا) 16:30 <+fox> <BrianR___> jrandom: هل هناك «MTU» فعلي لحزم I2P؟ 16:30 <jrandom> آه، حسناً، ربما مع ارتفاع ذلك قليلاً، ستنخفض نسبة إعادة الإرسال 16:30 <Complication> لاحظت أن النظام لدي بدأ بـ MTU أصغر، والآن ارتفع إلى 1350 16:30 <jrandom> BrianR___: نعم، إما 1350 أو 608 (كما هو موضح على http://localhost:7657/peers.js) 16:31 <jrandom> إذا كانت نسبة الفشل مرتفعة جداً عند MTU الأكبر، يعود إلى MTU الأصغر (وإذا كانت منخفضة جداً عند MTU الأصغر، يقفز إلى MTU الأكبر) 16:31 <+fox> <BrianR___> jrandom: هل هذا للحمولة الداخلية أم لحزم IP المرئية؟ 16:31 <+fox> <BrianR___> أي، إذا أردت إرسال كتلة بيانات عبر دفق I2P، فما هو الحجم الأمثل للقطع لتقليل الحمل الإضافي؟ 16:31 <jrandom> هذا يتعلق بحمولة UDP 16:32 <jrandom> التدفقات أعلى بطبقتين 16:32 <jrandom> (هناك تجزئة لـ tunnels، ثم تجزئة على مستوى stream/I2CP) 16:32 <+fox> <BrianR___> نعم... هل هناك حجم مثالي لتقليل التجزئة؟ 16:32 <jrandom> الحجم المثالي للكتلة في تطبيق يستخدم مكتبة streaming (مكتبة برمجية للتدفق) هو «كبير»، حتى تتمكن مكتبة streaming من اختيار الحجم المناسب. 16:33 <jrandom> (المعنى: تجاهل الرجل خلف الستار) 16:33 <+fox> <BrianR___> آه.. ربما ينبغي أن أفكر في الـ pipelining أو شيء من هذا القبيل.. 16:34 <+fox> <BrianR___> أنا أخطط لتطبيق فيه الكثير من حركة الطلب/الاستجابة... 16:34 <jrandom> أنصح حينها بالتجميع (batching) لتقليل كثرة الرسائل 16:34 <Complication> ربما يساعد تركيز الحركة إلى حد ما 16:37 <jrandom> حسناً، أي شيء آخر بخصوص 1) حالة الشبكة، أم ننتقل برقّة إلى 2) التخطيط لـ Syndie 16:38 * jrandom يتمايل 16:39 <jrandom> هذا في الغالب عنصر نائب ونداء لتقديم المقترحات (cfp) - ستكون هناك إعادة هيكلة كبيرة لـ Syndie، سواء في التشغيل أو واجهة المستخدم، فإذا كانت لديك ميزات أساسية أو حالات استخدام ترى أنه ينبغي معالجتها، فتواصل معنا 16:40 <jrandom> (ستتوفر بالطبع مزيد من المعلومات مع تبلور الأمور أكثر) 16:42 <jrandom> هذا كل ما لدي في الوقت الحالي حول ذلك، لذا ننتقل إلى 3) تحسينات jbigi 16:42 <@frosk> وكنت قد افترضت أن «plotting» تشير إلى بعض أمور jrobin في Syndie :) 16:43 <jrandom> ههه 16:43 <jrandom> سيكون من الممتع رسم posts/day و posts/author و new authors/day، إلخ ;) 16:44 <Complication> أوه، نقطة بخصوص Syndie (عذراً، تذكرت للتو) 16:44 <Complication> = نقطة واحدة 16:44 <@frosk> أيّهما تريد، 0 أم 1؟ :) 16:44 <Complication> هل تعتقد أنه يمكن عملياً، أو أنه سهل/صعب، فصل المؤلفين المفضّلين والمؤلفين المدرجين في القائمة السوداء (السبام) إلى قائمتين منفصلتين؟ 16:45 <Complication> على addresses.jsp 16:45 <jrandom> أوه، نعم دون عناء كبير 16:46 <jrandom> هذه فكرة جيدة لإعادة الهيكلة أيضاً، وربما يمكننا إدخالها في بناء 0.6.1.14 16:47 <Complication> لا، الأمر لا يزعجني، فقط تذكرت شيئاً لاحظته وقتها 16:47 <Complication> على أية حال، يصبح jbigi أسرع على Linux/AMD64 عندما تُجمّعه محلياً وتستخدم GMP 4.2 16:48 <jrandom> رائع 16:48 <jrandom> هل قارنت ذلك مع ‎-O3 ‎-m64 على GMP 4.1.2؟ 16:48 <Complication> وأنا أحمق فعلاً لأنني استخدمت خيارات ترجمة خاطئة تماماً :O 16:48 <@cervantes> الرابط ذي الصلة كان http://forum.i2p/viewtopic.php?t=1523&start=30 بالمناسبة 16:48 <jrandom> آه شكراً يا cervantes 16:48 <Complication> jrandom: لم أقارن بعد، لكنني سأفعل 16:49 <Complication> خلال إعادة الإقلاع المجدولة القادمة 16:50 <jrandom> عملية بناء jbigi هي أساساً «قم ببناء GMP، ثم ابنِ jbigi.o، ثم اربط الاثنين معاً»، لذا يمكن إجراء أي نوع من التحسينات على GMP كخطوة أولى 16:50 <@cervantes> لم ألحظ فرقاً كبيراً بين ‎-O3 و ‎-O2 في أي من الاختبارات السابقة التي أجريتها، سواء كان الوضع مختلفاً على x86_64 ... *يهز كتفيه* 16:50 <jrandom> نعم، قد يعتمد أيضاً على إصدار المترجم 16:50 <jrandom> (خصوصاً مع كل مشكلات 3.3/3.4/4.0/4.1) 16:51 <@cervantes> فقط لإعادة ما ذكرته في ذلك النقاش... على الأرجح لن نرى jbigi محسّناً لـ windows64 قريباً 16:51 <+fox> <BrianR___> هل تقوم مكتبة I2P stream بضغط الحمولة؟ 16:52 <Complication> BrianR: نعم 16:52 <@cervantes> ما لم يكن لدى أحدهم M$ VC 2005 مع حزمة SDK لـ 64-بت ويرغب في بذل جهد كبير لجعل gmp تُبنى 16:52 <Complication> على الأقل حسب علمي 16:53 <@cervantes> (كان هناك مشروع لنقل gmp إلى مشروع vc في مكانٍ ما) 16:53 <jrandom> cervantes: حسناً، لدينا واحد /يعمل/ لـ amd64/win، لكنه لا يستفيد بأقصى قدر من العتاد ;) 16:53 <jrandom> (عندما يصل صندوقي الجديد قد أتمكن من تحسين ذلك، لأنه amd64) 16:53 <+fox> <BrianR___> أحاول تحديد ما إذا كان ينبغي أن أستخدم بروتوكولاً ثنائياً لتوفير البِتّات أم أن zlib أو ما شابهه سيضغط بروتوكول ascii بشكل جميل وصغير.. 16:54 <@cervantes> جميل - للأسف لا يبدو أن Mingw64 أو cygwin64 على وشك الظهور قريباً... 16:54 <jrandom> BrianR___: التحسين المبكّر هو أصل كل الشرور، وكل ذلك الكلام... 16:55 <Complication> البروتوكولات القابلة للقراءة البشرية، ولو جزئياً، تكون عموماً أسهل في التنقيح، لكن أظن أن الأمر يعتمد على ما يفعله المرء 16:56 <Complication> (لأن بعض الأشياء مثل التشفير لا تحب أن تكون قابلة للقراءة البشرية، مهما كان الحال :) ) 16:57 <Complication> ولكن إذا كان I2P يتولى التشفير، ويقوم أيضاً بالضغط، فهناك فرصة جيدة بأن الكثير من الأشياء التي تتم فوقه يمكن تنفيذها ببروتوكولات قابلة للقراءة البشرية 16:58 <jrandom> نعم 16:58 <jrandom> حسناً، أي شيء آخر حول 3) أمور jbigi؟ 16:58 <jrandom> إن لم يكن، فلننتقل إلى 4) ؟؟؟ 16:59 <jrandom> هل لدى أي شخص شيء آخر للاجتماع؟ 17:01 <+tethra> أتذكر أنني سمعت مؤخراً عن أدوات تعاون مجهولة الهوية 17:01 <+tethra> هل تود التوسّع في نوعها، وما إذا كانت شبيهة بـ Syndie أم لا؟ 17:02 <@cervantes> IRC و Syndie أداتا تعاون مجهول الهوية :) 17:02 <jrandom> همم، لست متأكداً مما تشير إليه - أو ربما تقصد إعادة الهيكلة المخطط لها فعلياً لـ Syndie؟ :) 17:02 <+tethra> صحيح. 17:02 * tethra ليس متأكداً أيضاً، ولهذا سأل 17:02 <+tethra> كان هناك حديث عنه في المنتديات - أسباب إخفاء الهوية وما إلى ذلك 17:03 <+tethra> سأجد الموضوع لأحصل على الاقتباس 17:03 <jrandom> آه صحيح 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> موضوع حالات الاستخدام 17:03 <+tethra> - منتديات/لوحات/ويكيات مُستضافة بشكل مجهول وقابلة للوصول علناً 17:03 <+tethra> نعم 17:04 <+tethra> هل سيكون هناك مشروع من نوع i2wiki يعتمد على شيء مثل Syndie أم أن الأمر متروك للمستخدمين؟ 17:04 <jrandom> كانت هناك بعض الأفكار الجيدة، وبعض التعقيبات الجيدة 17:05 <jrandom> إمكانية تحرير منشورات Syndie من الميزات المطلوبة كثيراً، ومع ذلك يمكن إنجاز ويكي مع محرر غني 17:05 <jrandom> لكن بالطبع لا شيء يوجد في فراغ - إذا اعتقد أحد أن ذلك ضروري، فعليه أن يقول: «مهلاً، الويكي أساسي، وإليك السبب» 17:06 <jrandom> هناك عدد لا نهائي من التطبيقات التي /يمكن/ بناؤها، لكن بما أننا نسعى لإخفاء هوية قوي وأمان قوي، فلا بد من التريث فيما يتم بناؤه 17:07 <+tethra> صحيح 17:07 <+tethra> مع ذلك، قد يكون من الأفضل أن يتولى الأمورَ الأصعبَ في الحفاظ على الإخفاء والأمان شخصٌ يجيد الحفاظ على الإخفاء والأمان، أليس كذلك؟ 17:08 <jrandom> على الأرجح، رغم أنه لا توجد «زمرة» - يمكن لأي شخص أن يتعلم 17:08 <+tethra> (أشياء أساسية، أساساً. ليس أنني أسمّي أي شيء، لكنّك تفهم المقصود.) 17:08 <+tethra> صحيح 17:09 <+tethra> لكن التعلم على حساب إخفاء هويتك وهويات الآخرين ليس أفضل طريقة للقيام بذلك 17:10 <jrandom> على الجميع أن يبدأ من مكان ما، بالطبع 17:10 <+tethra> (ربما لو أنشأ أحدهم بيئة sandbox تسمح للناس بتشغيل $software وجعل الآخرين يهاجمونه وما إلى ذلك، لكان ذلك جيداً لمن هو جديد/غير متمرس؟) 17:10 <+tethra> نعم 17:14 <jrandom> حسناً، هل لدى أحد غير ذلك شيء للاجتماع؟ 17:15 <jrandom> إن لم يكن 17:15 * jrandom يستعد للاختتام 17:15 <@cervantes> *اهمم* 17:15 * jrandom يتوقف قليلاً 17:16 <jrandom> ما الأخبار يا cerv؟ 17:16 <Complication> رائع، وجدت baf ;P 17:17 <jrandom> تم إيقاف الـ baf ;) 17:17 <@cervantes> أوبس آسف، تابع الـ baffing 17:17 * jrandom يستأنف الاختتام 17:18 * jrandom يقوم بـ *baf* لإغلاق الاجتماع