ملخص سريع
الحضور: bar, c3rvantes, cat-a-puss, cervantes, Complication, jrandom, legion, Pseudonym
سجل الاجتماع
15:25 <jrandom> 0) مرحباً 15:25 <jrandom> 1) حالة الشبكة و 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) مرحباً 15:25 * jrandom يلوّح 15:25 <jrandom> ملاحظات الحالة الأسبوعية منشورة على @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar يناول jrandom baf 15:26 <c3rvantes> ليس بعد! 15:26 * jrandom يستعد 15:26 <jrandom> إمم... 15:26 <jrandom> دعونا نتناول أول بنود جدول الأعمال أولاً :) 1) حالة الشبكة و 0.6.1.6 15:27 <jrandom> تم تحديث الكثير من الأشياء في الإصدارات القليلة الماضية، لكن الشبكة ما تزال تبدو مستقرة إلى حد معقول. 15:28 <jrandom> شهدنا بعض القفزات الكبيرة في مشاركة router على بضعة routers، رغم أن ذلك غير ضار إلى حد كبير 15:28 <+legion> رائع، أتفق أن حالة الشبكة تتحسن. وأيضاً نعم، لماذا لا نتخلى عن tcp في 0.6.1.7 15:28 <jrandom> (أقصد، قفزات في مشاركة tunnel) 15:29 <@cervantes> لستَ تمزح 15:29 <jrandom> لستُ متأكداً يا legion. قد يكون هناك بعض المستخدمين المقيّدين بـ tcp فقط، لكن أذكر أن هناك واحداً أو ربما اثنين فقط 15:29 <+legion> حسناً لاحظتُ مع 0.6.1.5 أن الـ router كان أحياناً يعيد التشغيل من تلقاء نفسه. 15:29 <+Complication> كان يتراوح ضمن حدود معقولة، من 100 إلى 250 tunnel مشاركة 15:29 <jrandom> لا أرى سبباً وجيهاً للاحتفاظ به، ويمكنني أن أذكر بضعة أسباب للتخلّي عنه 15:30 <jrandom> جميل يا Complication 15:30 <jrandom> (هذه الأرقام متوسّطة إلى حد ما بحسب stats.i2p/، لكن تذكّر أن أرقاماً كهذه قد تضر بإخفاء الهوية، لذا لا ينبغي حقاً الإفصاح عنها، وخصوصاً ليس في اجتماعات مُسجَّلة ;) 15:30 <+Complication> جهازي Celeron القديم ما يزال يعيد التشغيل تلقائياً كل نحو 10 ساعات 15:30 <+Complication> وإلا فهو متصل بشكل أفضل من أي وقت مضى 15:30 <Pseudonym> ما الأسباب للتخلّي عنه؟ 15:31 <+Complication> TCP مكلف 15:31 <@cervantes> الـ router لدي منهك تماماً 15:31 <+Complication> من حيث عدد الخيوط لكل اتصال 15:31 <@cervantes> Complication: اضرب ذلك في 10 وستحصل على نطاق الـ router الحالي لدي ;-) 15:31 <+legion> لدي كان يتراوح بين 200-400 tunnel مشاركة، لذا يبدو أفضل من أي وقت مضى. 15:32 <+Complication> cervantes: أوه، مؤلم، مؤلم 15:32 <+Complication> شهدتُ حادثة غريبة تسببت في 2000 tunnel مشاركة، لكن ذلك كان في الصيف 15:32 <jrandom> Pseudonym: الأداء (CPU/الذاكرة، جدولة أفضل بسبب متطلباتنا شبه-الموثوقة)، سهولة الصيانة، وقوائم حظر أكثر فعالية 15:32 <+Complication> قفزة واحدة لم تتكرر. 15:32 <+legion> نعم، مع بعض الإصدارات السابقة كانت هناك مثل هذه القفزات 15:32 <jrandom> Complication: شهدنا> 2000 قفزة tunnel مع هذه المراجعة الأخيرة 15:33 <jrandom> لكن نأمل أن يتكفّل 0.6.1.7 بذلك 15:33 <+legion> حسناً، هذه بعض الأسباب الجيدة للتخلّي عن tcp :) 15:33 <jrandom> لكن، مرة أخرى، القفزات في مشاركة tunnel لا بأس بها، إذ إن معظمها لا يُستَخدم 15:34 <@cervantes> Pseudonym: يبدو أن هناك router أو اثنين فقط ما يزالان يستخدمان tcp على الشبكة 15:34 <jrandom> قد يكون من الجيد أيضاً إسقاط tcp في هذه المراجعة، إذ لا تحتوي تغييرات كبيرة أخرى. بهذه الطريقة يمكننا أن نرى تأثيره بوضوح 15:34 <jrandom> (ويمكن إعادة تمكينه إذا لزم الأمر) 15:35 <Pseudonym> إذا كان هناك routerان فقط يستخدمانه، فلا أظن أن له أثراً كبيراً في كلتا الحالتين 15:35 <Pseudonym> (باستثناء أنه سيكون هناك routerان أقل على الشبكة) 15:35 <@cervantes> عميلان ساخطان 15:35 <jrandom> حسناً، الـ transport يظهر في بعض الحالات الغريبة، وهذا أحد الأسباب التي تجعلني أريد تعطيله :) 15:35 <+Complication> آمل ألا يأخذوه على محمل شخصي 15:36 <+Complication> إنه أمر سيئ فعلاً من بعض مزوّدي الإنترنت أن يحجبوا UDP. 15:36 <+Complication> سيئ، وبلا أي معنى. 15:36 <jrandom> (مثلاً عندما يتعطّل router، يقوم الناس بتمييز SSU transport لديهم كأنه فاشل، وبالتالي يعودون إلى tcp transport) 15:36 * Pseudonym يحب مزوّد الإنترنت لديه. لا قيود 15:37 <+Complication> إذن من دون TCP، سنرى كيف يتعامل UDP وحده مع الأمر؟ 15:37 <+Complication> "من دون عجلات مساعدة" :P 15:37 <+legion> همم، فكيف نتجاوز مثل هذا الحجب السيئ من دون tcp؟ 15:38 <jrandom> بالضبط يا Complication :) 15:38 <jrandom> legion: لا نفعل 15:38 <jrandom> (restricted routes (مسارات مقيّدة)) 15:38 <+Complication> حسناً، أليست هناك تطبيقات مفيدة إلى جانب برامج مشاركة الملفات تستخدم أيضاً رزم UDP أكبر حجماً من رزم DNS؟ 15:39 <+legion> :( لا يبدو جيداً 15:39 <+Complication> بحجم مماثل لأصغر حجم رزمة تستخدمه I2P؟ 15:39 <jrandom> إيه يا legion، ليست مشكلة 15:39 <jrandom> Complication: بروتوكولات البث 15:39 <+Complication> لا يمكن حجب UDP مباشرةً أبداً دون إعاقة DNS. 15:39 <+Complication> لكن يمكن تقييد حجم الرزم. 15:40 <+legion> حسناً، لقد بدا وكأنه قد يكون كذلك 15:40 <+Complication> VoIP؟ 15:40 <jrandom> سيكون الأمر مشكلة لو كان واسع الانتشار — إذا حظّر مجتمع الإنترنت عموماً UDP 15:40 <+Complication> همم، هل يستخدم VoIP رزم كبيرة أم صغيرة؟ 15:40 <jrandom> لكن إن كان الأمر يقتصر على بضعة مزوّدين، فيمكننا معاملتهم كـ restricted routes 15:40 <+Complication> أم تقصد أكثر... بث الفيديو؟ 15:40 <+legion> أظن أنه يستخدم مزيجاً من الاثنين 15:41 <jrandom> كلاهما يا Complication، يعمل RTSP فوق UDP، وreal يعمل فوق RTSP على ما أذكر 15:41 <+Complication> s/p/s 15:42 <+legion> فلننتقل إلى البند التالي؟ 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> ما زلت غير متأكد إن كنا سنسقط tcp في 0.6.1.7، لكن على الأرجح. 15:43 <jrandom> حسناً، هل لدى أحد شيء آخر حول 1)؟ إن لم يكن، فلننتقل إلى 2) Syndie 15:43 <+Complication> أي أن هناك ما لا يقل عن 227 تطبيقاً (بعضها قد يكون قديماً أو تطبيقات شبكة محلية) تستخدم UDP 15:44 <jrandom> بَه، هذه هي intarweb. كل ما تحتاجه هو وصول HTTP عبر وكيل 15:44 <jrandom> لا أملك الكثير لأضيفه إلى 2) بخلاف ما ورد في الرسالة (وما هو على Syndie) 15:44 <+legion> اقتنعت، نعم تخلّصوا منه. :) 15:44 <jrandom> هل لدى أحد أي شيء بخصوص Syndie يريد طرحه؟ 15:45 <+legion> ليس لدي ما أقوله عن 2) أيضاً. 15:45 * Complication يقرأ "كيف يعمل Syndie" 15:46 <+Complication> تأثير صغير في الواجهة يواظب على مفاجأتي. :D 15:46 <+Complication> عندما أوسّع سلسلة رسائل، يفاجئني دائماً أن الرسالة النشطة تتحرك لتصبح في أعلى القائمة. :P 15:47 <+Complication> لكن يمكنكم تجاهل ذلك بأمان على الأرجح. أنا فقط متطلّب جداً ومخلوق اعتاد على نمط معيّن. :P 15:47 <@cervantes> نموذج التشعّب (threading) تتم مناقشته بإسهاب 15:47 <@cervantes> ;-) 15:47 <+Complication> سأعتاد عليه. :) 15:48 <+Complication> cervantes: في Syndie؟ يجب أن أعثر على تلك السلسلة. :) 15:48 <@cervantes> لا يعجبني ذلك أنا أيضاً — لكنه قد يتغيّر حقاً 15:48 <jrandom> نعم، هذا نوعاً ما غريب على ما أظن 15:48 <+legion> نعم 15:48 <@cervantes> "subject: syndie threading" 15:49 <+Complication> وبالمناسبة، إذا كانت الرسالة الموسَّعة في الأسفل تماماً، فسيتعيّن عليها أن تتحرك على أي حال. 15:49 <+Complication> لأنه وإلا فستظل عالقة هناك. 15:50 <jrandom> حسناً، شريط التنقل في الأسفل يَعرض 10 *threads* في كل مرة، وليس 10 رسائل. لذا يمكنه توسيع السلسلة السفلى 15:50 * cervantes يختبر بعض تطبيقات أنماط واجهة المستخدم للتشعّب حالياً 15:51 <jrandom> رائع 15:51 <jrandom> نعم، من المثالي أن نكون قادرين على تبديلها عبر CSS، وإن لم يكن، فجانب الخادم 15:52 <@cervantes> أو بالأحرى "threading navigation styles" 15:53 <@cervantes> همم، اختباراتـي تستخدم قوائم غير مرتّبة متداخلة HTML صِرف بشكل افتراضي 15:53 <@cervantes> يمكنك إضافة ما تشاء من CSS وJavaScript حسب حاجتك أو رغبتك 15:53 <jrandom> أي تقدير زمني لموعد تمكنّا من رؤية بعض النماذج الأولية؟ 15:53 <@cervantes> (غير أنه مجرد إثبات مفهوم، وليس تنفيذ واجهة مستخدم فعلياً) 15:54 <@cervantes> أقوم بمعظم البرمجة أثناء اجتماعات I2P ;-) 15:54 <jrandom> هه 15:54 <@cervantes> ربما ستكون أول عيّنة جاهزة هذا المساء 15:54 * jrandom يجدول اجتماعات يومية 15:54 <jrandom> رائع 15:54 <@cervantes> اللعنة :) 15:55 <jrandom> حسناً، هل لدى أحد أي شيء آخر بشأن 2) Syndie؟ 15:55 <jrandom> إن لم يكن، فلننتقل إلى 3) I2P Rufus 0.0.4 15:56 <jrandom> لا أملك الكثير لأضيفه بخلاف ما ورد في الرسالة — Rawn/defnax، هل أنتم موجودون؟ 15:56 <+legion> فما مدى جودة 0.0.4؟ ما المشاكل الباقية إن وُجدت؟ 15:57 * jrandom ليست لديه أدنى فكرة 15:58 <+legion> ربما يستطيع أحد مستخدميه الإجابة. هل يبدو جيداً ومستقراً؟ 15:58 <jrandom> حسناً، يبدو أن Rawn وdefnax غائبان حالياً. إذا كان لدى أي أحد أسئلة/تعليقات/مخاوف بخصوص I2P Rufus، فليمرّ على المنتدى ويطرحها هناك 15:58 <+legion> تبّاً، أعتقد أننا سنفعل. 15:59 <+legion> ننتقل إلى 4)؟ 15:59 <jrandom> نعم، يبدو كذلك. حسناً، 4) ??? 15:59 <+Complication> لم أجرّب I2P Rufus، للأسف. 16:00 <jrandom> هل لدى أحد أي شيء آخر يريد طرحه؟ 16:00 <jrandom> (هيا، علينا إطالة هذا حتى يتمكن cervantes من القيام بمزيد من العمل!) 16:00 <+legion> نعم، ما نوع الأشياء المثيرة القادمة في الطريق؟ 16:00 <+bar> هل هناك مكان يمكنني أن أقرأ فيه المزيد عن "restricted routes"? 16:00 <+bar> (لقد بحثتُ فعلاً) 16:01 <+legion> ربما يمكننا حتى مناقشة i2phex؟ 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes يضع مؤشّر الماوس فوق زر الإغلاق 16:01 <jrandom> إمم، #future.restricted 16:02 <jrandom> بالإضافة إلى صفحات how_* و todo 16:02 <jrandom> (على الويب) 16:02 <+Complication> هه، يبدو أن I2P قد تخطّت بناءً ما :D 16:02 <+Complication> :D 16:02 <+bar> شكراً 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion: بعض العمل على netDb، تعديلات أداء، restricted routes، تحسينات في البث، تحسينات eepproxy، تحسينات tunnel، إلخ. أشياء كثيرة، لكن لا شيء جاهز بعد 16:03 <+legion> همم، غريب 16:03 <jrandom> أي شيء لطرحه بخصوص i2phex يا legion؟ 16:03 <jrandom> Complication: نعم، مقصود. نسيتُ أن أزيده لـ BUILD = 2 16:03 <+Complication> (ليس لأنه يهم لشيء، فقط كنت أتساءل إن كنتُ قد رأيت هذه الحالة النادرة من قبل :) 16:04 <+legion> جميل، يبدو رائعاً، شكراً! 16:04 <jrandom> أوه، هذا يذكّرني... سيكون رائعاً لو أراد أحدهم الخوض في إعادة تصميم صفحتنا على الويب 16:05 * jrandom لا يريد التفكير في ذلك، لكن لا بد أن يُنجَز عاجلاً أم آجلاً 16:05 <+legion> نعم، هناك 16:05 <+legion> هل يجدر بنا تحديث i2phex في هذه المرحلة إلى أحدث كود phex من CVS؟ 16:06 <+Complication> لستُ متأكداً، لم أسمع من Redzara مؤخراً 16:06 <jrandom> آخر ما أذكره أن redzara كان ينتظر تحديثات gregorz لـ phex 16:06 <jrandom> (حتى نتمكن من تحديث/تمديد نظيف إلى حد معقول) 16:08 <+legion> همم، إذاً لماذا لدينا i2phex؟ 16:08 <+Complication> تحسّباً؟ 16:08 <jrandom> همم؟ 16:08 <jrandom> i2phex هو امتداد لـ phex 16:08 <+legion> يبدو أنهم أرادوا أن يكون هناك phex مع امتداد I2P فقط 16:09 <jrandom> امتداد، أي تعديل لعدد صغير جداً من الأجزاء 16:09 <jrandom> إمم، s/bits/components/. حتى نتمكن من تحديث الكود بسهولة كلما أصلح مطوّرو phex الأمور 16:10 <+legion> إذا كان الأمر كذلك، فلن يتطلب مني جهداً كبيراً لتحديثه إلى أحدث كود CVS، رغم أني أعلم أنه سيتطلب جهداً. 16:10 <jrandom> آخر ما سمعته في المنتدى هو أن الخطة تقضي بأن يكون I2Phex وPhex تطبيقين منفصلين، لكنهما سيشتركان في معظم الكود 16:10 <jrandom> نعم يا legion، سيكون ذلك رائعاً، لكن آخر ما سمعتُ أن Gregor لم يُنهِ التعديلات على Phex بعد 16:11 <jrandom> (وهو ما كان ينتظره redzara) 16:11 <+legion> آه، فهمت 16:11 <jrandom> إذاً، البديل هو إما مساعدة Gregor أو مواصلة تعديل قاعدة كود I2Phex الحالية 16:12 <+legion> حسناً، إذا لم أنتظر وقمتُ فقط بتحديث i2phex بالكود الجديد، فلن تكون هناك حاجة لأن يواصل redzara 16:12 <jrandom> ليس تماماً. 16:12 <jrandom> تحديث I2Phex إلى كود Phex الحالي سيكون رائعاً، نعم 16:13 <jrandom> لكن بمجرد أن يُحدّث مطوّرو Phex كودهم، سنخرج عن التزامن مجدداً 16:13 <+legion> حسناً، سأعمل عليه على الأرجح الليلة أو خلال يومين. 16:13 <jrandom> رائع 16:13 <+legion> لا بأس بذلك. 16:14 <+legion> في الواقع لستُ أسعى لأن يبقى i2phex متزامناً مع كود phex، لكن يبدو أن CVS يحتوي على إصلاحات قد يستفيد منها i2phex بالتأكيد. 16:15 <+legion> كما أنني أهدف فعلاً إلى إزالة أي كود وميزات من phex لا يحتاجها i2phex. 16:15 <jrandom> جيد 16:16 <+legion> أما عن أي ميزات جديدة وإصلاح أي شيء لا يعمل بعد مثل طوابير الرفع... فقد بدأتُ بالفعل بالنظر في جعل webcaches تعمل، لكن ما يزال أمامي الكثير. 16:17 <jrandom> صحيح. نعم، كان لدى phex دعم gwebcache يعمل، لكن sirup عطّله لأنه لم يكن ضرورياً في البداية 16:17 <+legion> أنوي إضافة jeti إلى i2phex في نهاية المطاف. 16:17 <jrandom> جميل 16:18 * jrandom لم يستخدم jeti من قبل، وآمل أن يبقى مكوّناً اختيارياً، لكن دعم مزيد من الأشياء أمر رائع 16:18 <+legion> نعم يمكن أن يكون اختيارياً، وسيتمكن المستخدمون من تنزيل jeti2phex ;) 16:19 <jrandom> تمام 16:19 <+legion> ما يزال هناك الكثير مما يمكننا فعله مع i2phex، رغم أنه يعمل بشكل رائع كما هو. 16:20 <+legion> حتى الآن، إبقاء العميل متصلاً ويعمل 24/7 ممكن وسهل. 16:21 <jrandom> نعم، حققتُ نجاحاً جيداً معه... "النسخ الاحتياطي لتسجيلاتي المرخّصة" 16:21 <+legion> هه :) 16:22 <jrandom> حسناً، هل لدى أحد آخر أي شيء للاجتماع؟ 16:23 * cervantes يدحرج الجونغ الصيني 16:23 <+legion> يبدو أنني أنسى شيئاً... همم 16:24 <+legion> أوه نعم، أي أفكار حول كيفية تقليل مقدار الذاكرة التي يستهلكها i2p وi2phex؟ 16:25 <+Complication> حسناً، طبقة نقل TCP تستهلك قليلاً 16:25 <jrandom> يمكن تشغيل كلاهما في نفس JVM 16:25 <+Complication> إذا ذهب ذلك، فسيوفّر قليلاً 16:26 <@cervantes> أخرج بعض شرائح الذاكرة من جهازك 16:26 <cat-a-puss> هل لدى أحد خبرة مع javolution لنعرف إن كان سيساعد؟ http://javolution.org/ 16:26 <jrandom> (الملف clients.config في مجلد تثبيت i2p يعرّف الصنف الرئيسي والمعاملات لإطلاق العملاء) 16:26 <+legion> فإذا شغّلنا الاثنين في نفس JVM وعندما يُزال tcp، هل يمكننا خفضه إلى أقل من 50MB؟ 16:27 <jrandom> لا فكرة لدي يا legion. يعتمد أيضاً على ما تعنيه بـ 50MB. RSS/VSS/إلخ 16:27 <jrandom> حقاً لا أوصي بتشغيلهما في JVM واحدة، إلا إذا أبقيتهما يعملان طوال الوقت، لأن إيقاف أحدهما سيقتل الآخر 16:27 <@cervantes> legion: تقييد عرض النطاق ووضع حد للمشاركين قد يساعد أيضاً 16:27 <jrandom> نعم، ما قاله cervantes 16:28 <cat-a-puss> يبدو لي أنه إذا عرفنا بالضبط عدد نوع معيّن من الكائنات التي سنستخدمها في النهاية، فسيُساعِد ذلك على منع تخصيص JVM المفرِط 16:28 <+Complication> صحيح، فهي تقوم بتخصيصات مختلفة، والتي لم أستطع حقاً فهمها 16:28 <jrandom> نعم، نقوم ببعض ذلك يا cat-a-puss (انظر net.i2p.util.ByteCache) 16:29 <+Complication> (لكن كما قلت، Java شيء جديد جداً بالنسبة لي) 16:29 <jrandom> اطلعتُ على javolution سابقاً، لكنه يبدو أنه حقّق تقدماً كبيراً. سأُلقي عليه نظرة أخرى 16:30 <cat-a-puss> jrandom: أعرف بعض الأشخاص في عملي يستخدمونه وهم راضون عنه، رغم أنهم لا يهتمون بتخصيص الذاكرة 16:31 <jrandom> حسناً، لن يوفر ذاكرة فعلياً، لكنه سيساعد على تقليل دوران GC 16:31 <+legion> أما أنا شخصياً فلا أهتم كثيراً بتخصيص الذاكرة، لكن كثيرين يفعلون. 16:31 <jrandom> أوه، وهو مرخّص أيضاً تحت BSD 16:31 <cat-a-puss> صحيح 16:31 <jrandom> legion: تخصيص الذاكرة يعني الأداء 16:32 <+legion> آه، إذاً استهلاك الذاكرة 16:33 <+legion> الكثيرون سعداء جداً بـ utorrent بسبب بصمته الصغيرة جداً على الذاكرة. 16:33 <jrandom> آه، نعم. يمكننا ضبطه لاحقاً، لكن بما أن i2p يعمل ضمن أحجام JVM الافتراضية، فلستُ قلقاً كثيراً (إذ لدينا مساحة كبيرة للضبط) 16:34 <jrandom> حسناً، هل لدى أحد أي شيء آخر للاجتماع؟ 16:35 <+legion> لا، أنا بخير... 16:37 * jrandom يستعد 16:37 * jrandom يُغلق الاجتماع بـ *baf*