اجتماع مطوري I2P - 20 ديسمبر 2005

15:20 <jrandom> 0) مرحباً 15:20 <jrandom> 1) حالة الشبكة 15:20 <jrandom> 2) تحديثات I2PSnark 15:20 <jrandom> 3) واجهة مدونة Syndie 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) مرحباً 15:20 * jrandom يلوّح 15:20 <jrandom> نُشرت ملاحظات الحالة الأسبوعية على http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> حسناً، لنبدأ بـ 1) حالة الشبكة 15:22 <jrandom> ليس لدي الكثير لأضيفه عما ورد في ملاحظات الحالة. 15:22 <+Complication> لولا حالات OOM (نفاد الذاكرة) العرضية، لجرّأت ووصفتها بالجيدة 15:22 <jrandom> اختبارات التحميل تبدو واعدة جداً، ما يوحي بأن لدينا مساحة كبيرة لتحسين الأداء 15:23 <+Complication> وأظن أن حالات OOM 15:23 <jrandom> هه، هل هي OOMs مرتبطة بـ i2psnark؟ أم من قبل ذلك؟ 15:23 <+Complication> تُسهم في عدم الاستقرار، عندما تقوم مثيلات i2p-bt أو i2psnark أو i2p-rufus بـ... أشياء. 15:24 <zzz> نظريتي أن ازدياد حركة torrent يؤثر إلى حدٍ ما على موثوقية IRC 15:24 <+Complication> (ربما لا ينبغي أن أصف غرابة SAM بأنها OOM، إذ لم أتفحّصها عن كثب، لكنها بالتأكيد أحد العوامل) 15:24 <jrandom> همم، لستُ متأكداً، إذ إن حالة irc كانت مشابهة لما قبل آخر تحديثات snark 15:25 <+Complication> النطاق الترددي كان ثابتاً، وخصوصاً tunnels ثابتة أيضاً... لكن هناك انهيارات بين حين وآخر 15:26 <zzz> على أي حال أنا متفائل بأن إصلاحات بناء tunnel القادمة في 0.6.1.8 ستحسّن تجربة الناس مع IRC 15:26 <+Complication> لأسباب معروفة، والتي نأمل أن تزول حين يحين وقتها :) 15:26 <jrandom> أجل، أظن ذلك أيضاً يا zzz، لذا على الأرجح سيكون لدينا إصدار خلال يوم أو نحو ذلك 15:26 <+legion> حسناً قد يكون irc حساساً أكثر مما ينبغي، ربما استخدام شيء مثل jabber يكون أفضل؟ 15:26 <zzz> خصوصاً لمن لديهم أجهزة أبطأ و/أو اتصالات أبطأ 15:27 <jrandom> jabber لن يغيّر الأمور 15:27 <+Complication> خصوصاً مع تكرار tunnel عند 2 15:28 <+bar> أقول إن irc مؤشّر خراء ممتاز لمعرفة "طقس" الشبكة 15:28 <+legion> نعم، تهب نسمة صغيرة ويتعطّل irc 15:28 <+bar> بالضبط :) 15:28 <+Complication> لاحظتُ أنه بعد إصلاح القائمة السوداء، "Recent" يميل دائماً لتجاوز "Known" 15:29 <+Complication> هل هذا لأن "Known" لا تتضمن الأقران الموضوعين في القائمة السوداء، بينما "Recent" تتضمنهم؟ 15:29 <jrandom> أجل، irc يعطي رؤية جيدة للأمور، إذ يُظهر تبايناً كبيراً بين المستخدمين المختلفين (مثلاً dreamtheaterfan يواجه مشاكل دائماً، إلخ) 15:30 <jrandom> همم، هذا منطقي يا Complication 15:30 <+Complication> (لستُ متأكداً إن كان الأمر كذلك، مجرد تخمين) 15:30 <jrandom> (إذ تُسقِط netDb الأقران في القائمة السوداء، لكن لا تُزال ملفاتهم الشخصية) 15:32 <+Complication> إذن تبدو المؤشرات على ما يرام (أردت أن أسأل فقط تحسّباً) 15:33 <jrandom> حسناً، أي شيء آخر حول 1) حالة الشبكة؟ 15:33 <jrandom> إن لم يكن، فلننتقل إلى 2) تحديثات I2PSnark 15:33 <tealc_> ما نوع التحديثات المتاحة؟ 15:34 <jrandom> اطّلع على http://dev.i2p.net/pipermail/i2p/2005-December/001240.html لقائمة مختصرة ;) 15:34 <jrandom> باختصار، أصبح بإمكان I2PSnark التعامل مع عدة torrents دفعة واحدة عبر وجهة I2P واحدة، وله واجهة ويب، ومُدمج في الـ router console 15:35 <tealc_> أشغّل أحدث إصدارات cvs وi2psnark يسبب الكثير من أخطاء heap للذاكرة أو ما شابه 15:35 <+Complication> …كما يتعامل أيضاً مع torrents المُنشأة بواسطة Azureus ذات meta-tags الغريبة. 15:35 <+Complication> والتي كان يتعثر عندها سابقاً. 15:35 <jrandom> آه، نعم، لا تزال هناك أمور أعمل على تنقيحها هناك يا tealc_ 15:35 <jrandom> (كما ذُكر في ملاحظات الحالة الأسبوعية ;) 15:35 <jrandom> صحيح يا Complication 15:36 <jrandom> أوه، أيضاً، قام فريق Azureus بإصلاح عطل في الـ tracker (متعقب) لديهم كان يمنع I2PSnark من استخدامه 15:36 <jrandom> (لذا من يشغّلون azureus trackers قبل B16 ينبغي أن يُحدّثوا في أقرب فرصة) 15:37 <+bar> أودّ أن تكون هناك إمكانية لتعطيل التشغيل التلقائي لـ i2psnark بسهولة (لحالات انخفاض عرض النطاق الترددي، إلخ.) 15:38 <jrandom> يجب أن يكون من السهل إضافتها 15:38 <+bar> يبدو رائعاً 15:39 <jrandom> حسناً، أي شيء آخر حول 2) تحديثات I2PSnark؟ 15:40 <jrandom> إن لم يكن، فلننتقل إلى 3) واجهة مدونة Syndie 15:40 <zzz> إبهامان مرفوعان لـ i2psnark الجديد - عمل ممتاز 15:41 <jrandom> شكراً، mjw قام بالعمل الشاق، مما جعل snark سهل التوسعة جداً 15:41 <jrandom> حسناً، كما ذُكر في ملاحظات الحالة، لدى syndie الآن واجهة مدونة جديدة 15:42 <jrandom> أظن أنها ستقدّم توازناً بين القوائم البيضاء والقوائم السوداء، للتعامل مع مشكلات الرسائل المزعجة المتنوعة التي يواجهها الناس 15:43 <jrandom> سنطرح ذلك في الإصدار القادم، بحيث تتمكنون من الخوض فيه خلال يوم أو يومين 15:43 <+legion> هل ستصبح الرسائل المزعجة مشكلة كبيرة قريباً؟ 15:44 <+Complication> legion: كما تفضّل أحدهم وأثبت، يمكن أن يحدث ذلك 15:44 <jrandom> لا، القوائم السوداء تتكفّل بالمؤلفين الذين يغرّقون، والقوائم البيضاء تتكفّل بالمرسِلين المزعجين الذين ينشئون الكثير من المؤلفين 15:44 <dust> (إخفاء الهوية يُظهر أسوأ ما لدى بعض الناس) 15:44 <jrandom> (لذا فالإزعاج ليس مشكلة) 15:45 <+Complication> (مع أنني أعتقد أن الرجل كان يعيد توليد المفاتيح لتفادي الإدراج الدائم في القائمة السوداء، وهو ما يُبطّئ الأمور فعلاً إلى حدٍ ما.) 15:45 <+Complication> لكنه ليس إبطاءً كبيراً، لذا أتفق تماماً على أن القوائم البيضاء جيدة أيضاً. :) 15:46 <+bar> ربما تكون هناك إمكانية لحل hashcash في المستقبل، إذا لزم الأمر 15:46 <jrandom> إذا لزم الأمر، لكن لا أرى سبباً لذلك 15:46 <+bar> أتفق، حالياً، لا أرى ذلك أيضاً 15:46 <+Complication> bar: مثل "لا تُعرض إلا إذا تكلّفوا عناء حساب بعض الأرقام"؟ 15:47 <+bar> نعم، شيء من هذا القبيل 15:47 <+Complication> يبدو ممكناً، حتى لو كان على الأرجح غير ضروري. 15:47 <+bar> على الأرجح كذلك. 15:47 <jrandom> إذا كانت مجموعة من المزعجين تغرق بالمحتوى عبر الكثير من المؤلفين الجدد طوال الوقت، فلا يزال بالإمكان أن يُخبر الناسُ بعضهم بعضاً عن المؤلفين الجدد بنشر إشاراتهم المرجعية وإحالات المدونة في مدوناتهم الخاصة 15:47 <+Complication> أو بالأحرى، نأمل ألّا يكون ضرورياً. 15:48 <+Complication> قد يكون من الجيد النظر في ما إذا كان يمكن لـ Syndie استيعاب مثل هذه الوظيفة، إذا دعت الحاجة يوماً ما. 15:49 <jrandom> أجل، يمكن ذلك، عبر رؤوس في تدوينة المدونة أو في معلوماتها الوصفية الخاصة 15:49 <jrandom> أعني، metadata (تبّاً لك يا BT!) 15:51 <jrandom> حسناً، إن لم يكن هناك شيء آخر حول 3) Syndie، فلننتقل إلى 4) ??? 15:51 <jrandom> هل لدى أيٍّ منكم أي شيء آخر يود طرحه للاجتماع؟ 15:51 <+legion> نعم، أمران 15:52 <+legion> أولاً clunk 15:52 <jrandom> رائع، نعم clunk يبدو مثيراً 15:52 <+legion> كما ذكرتُ اليوم سابقاً في i2p-chat، أعمل على جعله يُجمّع باستخدام cygwin و/أو mingw. 15:53 <+legion> حتى الآن العميل وحده معطّل، والباقي بما فيه الخادم يُجمَّع ويبدو أنه يعمل 15:53 <jrandom> جميل 15:54 <tealc_> قد يتبيّن أن i2p عقدة حقيقية لبرنامج المراقبة غير المحدود لجورج بوش. أراكم في معسكرات الموت، أحضروا أوراق اللعب يا جماعة 15:54 <+legion> أحاول ليس فقط تتبّع سبب تعطل العميل، بل أيضاً إصلاحه. حالياً أنا عالق. 15:56 <+legion> الشيء الآخر الذي أردت مناقشته: هل يمكن تضمين tunnel افتراضي إلى خادم jabber لدي في التحديث القادم؟ فقط لتسهيل الأمور على مَن يريد تجربة jabber. 15:57 <tethra> 20:34:37 <jrandom> إذا كانت مجموعة من المزعجين تغرق بالمحتوى عبر الكثير من المؤلفين الجدد طوال الوقت، فلا يزال بالإمكان أن يُخبر الناسُ بعضهم بعضاً عن المؤلفين الجدد بنشر إشاراتهم المرجعية وإحالات المدونة في مدوناتهم الخاصة <--- ربما شيء على غرار طريقة polecat في دمج الثقة قد يلعب دوراً هنا؟ (أي لحظر المزعجين -وأيضاً- ترقية المؤلفين المشهورين.) 15:57 <tethra> </$0.02> 15:58 <+polecat> سيكون ذلك مثالاً بدائياً عن فكرة شبكة الثقة لدي، مع معيارية نقل ثقة بنسبة 100%، نعم. 15:58 <jrandom> legion: همم، إضافة إعداد معطّل أمر سهل بما يكفي للمستخدمين الجدد، لكن تردّدي يتعلق بتصفية البروتوكول (وما الذي تسرّبه أيٌّ من العملاء من معلومات). ما خبرتك مع العملاء المختلفين؟ 15:59 <jrandom> أجل، هناك مجال كبير لدمج مقاييس الثقة في syndie 16:01 <+legion> حسناً، على حد علمي jeti لا يُسرّب، باستثناء نقل الملفات لديه، وهو معطّل على أي حال في إعدادات الخادم لدي. ربما النسخة القادمة من jeti ستصحّح ذلك. بخلاف ذلك لا أعرف عن بقية العملاء. 16:02 <+legion> ما أعرفه يقيناً هو أن groupchat متين بغض النظر عن العملاء؛ إنما التواصل خارج groupchat هو ما قد يُسرّبه بعض العملاء، مع أنني لست متأكداً. 16:03 <jrandom> همم، التسريب ليس قيمة منطقية ثنائية فعلاً، المسألة هي ما /المعلومات/ التي يُسرّبها العملاء، لا ما إذا كانوا يُسرّبون أي معلومات أم لا 16:04 <+legion> صحيح، كنتُ أعني بالطبع أي معلومات حرجة مثل عناوين IP، ومع ذلك فعلى العملاء الجيدين إن هم سرّبوا تلك المعلومات أن يبلغوا عنها كـ 127.0.0.1 أو localhost فقط 16:06 <+legion> لذا أوصي باستخدام العملاء المعروفين الذين لا يُسرّبون، مثل jeti. 16:07 <zzz> هل يمكنك إضافة عمود "تم التحقق: لا يُسرّب" إلى مخطط العملاء لديك؟ 16:07 <jrandom> سيكون مفيداً لو تستطيع توثيق ما الذي يُسرّبه jeti وما الذي لا يُسرّبه (على غرار ما جمعه postman لـ smtp وpop proxy (proxy وكيل)) 16:08 <+legion> وفقاً لمطوّر jeti فإنه لا يُسرّب أي شيء قد يهدد إخفاء هوية المرء. هذا مؤكد بلا شك. وقد راجعتُ شيفرته أيضاً ولم أجد ما يجعلني أظن غير ذلك. 16:09 <jrandom> كون المطوّر قال ذلك قد يكون مؤكداً، لكن ما يفهمه المطوّر عن إخفاء الهوية مسألة أخرى ;) 16:09 <+legion> نعم zzz يمكنني إضافة عمود آخر كهذا 16:09 <jrandom> لا أشك في احتمال أن jeti يتصرف بشكل سليم، لكن نحتاج لمعرفة ما الذي يعنيه ذلك 16:10 <zzz> يبدو أن عدم التسريب لا يمكن التحقق منه إلا عبر تتبّع البروتوكول 16:10 <zzz> وليس بالنظر إلى الشيفرة أو سؤال المطوّر 16:12 <jrandom> حسناً، هل لدى أحد أي شيء آخر للاجتماع؟ 16:12 <+bar> تذكير فقط عدم نسيان amd64 jbigi 16:13 <+bar> (لكن أراهن أنه على قائمة مهامك) 16:13 <jrandom> أجل :) 16:13 <jrandom> (win amd64، أي أن linux amd64 يعمل بالفعل) 16:13 <jrandom> لكن، إن لم يكن هناك شيء آخر... 16:14 * jrandom يختتم 16:14 <+bar> نعم، win amd64. 16:14 * jrandom يغلق الاجتماع بـ *baf*