سبرنت كيدي إيكو 2021: تفاصيل حول التخطيط المجتمعي لمشروع كيدي البيئي

هذا متابعة لإعلان كيدي إيكو سبرنت المنشور على The Dot.

في 11 ديسمبر 2021، أقام كيدي إيكو أول سبرنت مخطط له من بين العديد، بحضور 7 أشخاص. كان الهدف مبدئي من السبرنت أن يكون حدثًا حضوريًا لإنشاء مختبر قياس مجتمعي، لكن كورونا أفسد الخطط. ومع ذلك، نشر المجتمع حيلته المعتادة، واجتمعنا عبر الإنترنت بدلاً من ذلك.

إعلان كيدي إيكو سبرنت 2021 على أخبار كيدي

في هذا المنشور المطول، سأقدم نظرة عامة مفصلة عن القضايا الرئيسية التي نوقشت في السبرنت ونتائجها؛ اطلع أيضًا على محضر الاجتماع لمزيد من التفاصيل.

أعلمت؟

مناقشات مثل هذه تحدث شهريًا في اجتماعاتنا المجتمعية في ثاني أربعاء من الشهر من الساعة 19:00 إلى 20:00 بتوقيت وسط أوروبا (توقيت برلين).

إنشاء فريق كيدي إيكو

يتألف كيدي إيكو حاليًا من ثلاثة مشاريع متصلة: (i) مشروع كفاءة الطاقة الحرة والمفتوحة المصدر (FEEP)، (ii) Blauer Engel For FOSS (BE4FOSS)، و (iii) تطبيقات Blauer Engel. لكل مشروع تركيزه الخاص: يتعلق FEEP بقياس استهلاك الطاقة للبرمجيات الحرة، ويركز BE4FOSS على التنظيم المجتمعي ونشر المعلومات حول لصيقة Blauer Engel البيئية، ويستضيف مستودع تطبيقات Blauer Engel جميع الوثائق المتعلقة بتصديق كيدي/البرمجيات الحرة باللصيقة البيئية. حتى السبرنت، كانت المستودعات الثلاثة للمشاريع مستضافة في مساحات اسم شخصية مختلفة. الآن، يمكن العثور على المستودعات الثلاثة في https://invent.kde.org/teams/eco.

إن وضع المشاريع تحت فريق واحد يربطها بشكل أوضح مع المشاريع المستقبلية المحتملة. علاوة على ذلك، إن وجود مساحة اسم غير شخصية هو أكثر ملاءمة للمشاريع المجتمعية. لا تتردد في الاطلاع على أنشطة كل مشروع في مساحة الفريق المذكورة أعلاه!

الفرق > كيدي إيكو

إكمال طلب Blauer Engel لتطبيق أوكلار

هناك ثلاثة تطبيقات كيدي قيست استهلاكها للطاقة بالفعل: أوكلار، بريدك، و كريتا. من بين هذه الثلاثة، طلبات Blauer Engel لتطبيقي أوكلار و بريدك في إعداد منذ بعض الوقت، وكان أحد الأهداف هو إكمال طلب أوكلار. نفخر أن نعلن أنه بعد السبرنت، رُفع طلب أوكلار وهو حاليًا قيد المراجعة للتصديق. نتوقع ردًا من RAL gGmbH، الهيئة المانحة لجائزة Blauer Engel، في غضون 2-3 أشهر. سيتبع تقديم بريدك قريبًا.

خلال مراجعة جماعية لطلب أوكلار، أثار المشاركون العديد من النقاط المثيرة للاهتمام. على سبيل المثال، ظهرت نقطة عند مناقشة معايير الشفافية لـ Blauer Engel (القسم 3.1.3.2). أبرز Malte Reißig من مجموعة أبحاث IASS حول «الرقمنة وتحولات الاستدامة» كيف أن التطوير المفتوح قد يؤثر إيجابًا على بعض المتطلبات الأخرى لمعايير الجائزة (انظر هذه المناقشة)، مثل سهولة الصيانة طويلة الأمد واستقلالية المستخدم لمنتج برمجي. بمعنى أن مستخدمي البرمجيات الحرة لا يستخدمون البرمجيات بشكل سلبي فقط، بل يشجعون ويستطيعون التعبير عن رغباتهم للتطوير المستقبلي للتطبيقات، ويمكن أن يشاركوا بنشاط في تخطيط المعالم. علاوة على ذلك، مع التطوير المفتوح، يمكن ربط رسائل الالتزام بقضايا أو علل محددة يبلغ عنها مجتمع من المستخدمين والمطورين. في البرمجيات الحرة، التطبيق ليس مجرد منتج نهائي، بل عملية مفتوحة تعكس احتياجات ورغبات مستخدميها ومجتمعاتهم. مع FOSS، المجتمع يقود اتجاه التطوير!

أيقونة أوكلار

نقطة أخرى تتعلق بتوزيع البرمجيات الحرة وكيف تشكل تحديات لتحقيق معايير Blauer Engel. نظرًا لأن البرمجيات الحرة توزع البرامج بشكل غير مركزي عادة، يوجد العديد من قنوات الإصدار والتوزيع لأي تطبيق واحد. اعتبر أوكلار، الذي يُحزَّم ليس فقط لـ Flatpak، بل أيضًا لـ Microsoft Store، ناهيك عن العديد من توزيعات جنو/لينكس (مثل OpenSuse، Debian). يمكن أن تؤثر الاختلافات في بنية التغليف التحتية على تحقيق متطلبات Blauer Engel، مثل عدم قابلية إلغاء التثبيت، والنمطية، إلخ.

الشركات التي تصدر برمجيات احتكارية، والتي عادة ما توزع منتجاتها بشكل مركزي، لن تواجه هذه المشكلات. في ضوء ذلك، إحدى الإمكانيات التي ناقشها الفريق هي تصديق شفرة المصدر لبرنامج فقط، وبذلك يبقى الحياد بخصوص الاختلافات في كيفية تغليف المنتج البرمجي وتوزيعه. إمكانية أخرى هي تصديق إصدارات خاصة بالتوزيع، مثل تلك الخاصة بـ Microsoft Store. في الواقع، يمكن استخدام الأخيرة لأغراض التسويق للوصول إلى مستخدمين جدد وجلبهم إلى مجتمع كيدي - انظر، على سبيل المثال، هذه المناقشة.

نود أن نعرف رأيك. الرجاء الانضمام إلى المحادثة على قائمتنا البريدية أو غرفة Matrix أو عبر متتبعات القضايا في مستودعات GitLab الخاصة بنا!

سيناريوهات الاستخدام القياسية

يعكس سيناريو الاستخدام القياسي (SUS) الوظائف النموذجية لتطبيق، مع الأخذ في الاعتبار تكرار تلك الوظائف. سيناريوهات الاستخدام القياسية هي أساسية لقياس استهلاك الطاقة لقطعة من البرمجيات.

عند مراجعة سجلات إجراءات سيناريوهات الاستخدام القياسية لـ أوكلار لتطبيق Blauer Engel، أُثيرت نقطتان مهمتان من شأنهما تحسين تنفيذ سيناريوهات الاستخدام القياسية عند القياس في المختبر. الأولى هي الملاحظة حول الحاجة إلى توثيق ليس فقط الإجراءات، بل وأيضًا كائنات الإجراءات (على سبيل المثال، عند استخدام قارئ بي دي اف، ما هو ملف بي دي اف المفتوح)، لأن هذا ممكن أن يؤثر على استهلاك الطاقة. الأخرى هي أن إدراج إجراءات الخمول أمر مهم عند تحديد سيناريو الاستخدام القياسي: إجراء الخمول واقعي وممكن أن يُظهر أنه لا شيء يحدث عندما لا يُفترض أن يحدث شيء.

طرحت عدة قضايا أخرى على الطاولة الافتراضية. عبر Nicolas Fella، مهندس برمجيات في KDAB Berlin، عن اهتمامه بمقارنة عميلي دردشة، مما حول المحادثة إلى تحديد سيناريوهات مفردة عند مقارنة تطبيقين باستخدام مماثل. سيقيد SUS مفرد وظائف البرنامج التي يمكن اختبارها، لكنه سيجعل نتائج القياسات قابلة للمقارنة مباشرة. علاوة على ذلك، بالنسبة لبرمجيات العميل-الخادم مثل عملاء الدردشة أو البريد الإلكتروني، هناك قضية مكون الشبكة، والتي تتطلب لاختبار محكم إعداد وقياس استهلاك الطاقة للخادم. أشار Cornelius Schumacher، الرئيس السابق لـ KDE e.V. والمساهم القديم في كيدي، إلى أنه لـ قياسات بريدك قيس العمل الحاسوبي على الجهاز المحلي فقط. قياس الحوسبة غير المحلية في برمجيات العميل-الخادم أكثر أهمية من أي وقت مضى في عالم اليوم، وهذا مخطط له حاليًا في معايير جائزة Blauer Engel المنقحة للبرمجيات.

شاشة ترحيب بريدك

موضوع آخر نوقش هو تحديد إجراءات سيناريوهات الاستخدام القياسية بشكل مجرد من أجل أتمتة تطبيق سيناريوهات الاستخدام باستخدام أدوات مختلفة (Actiona، xdotool، KXmlGui، وما إلى ذلك). كانت نقطة مهمة هي أن أدوات المحاكاة المختلفة تؤدي أشياء مختلفة، والتي ممكن أن تشكل تحديات لأتمتة العملية. على سبيل المثال، لا يمكن كتابة نص عند استخدام KXmlGui للمحاكاة، وبالتالي قد يظل شيء مثل xdotool مطلوبًا. في سياق ذي صلة، كان هناك اقتراح آخر يقضي بهيكلة سيناريو الاستخدام القياسي بطريقة ممكنة من أتمتة إنشاء سجل للإجراءات. هل يود أي شخص في المجتمع المساعدة في معالجة هذه التحديات؟

علاوة على ذلك، ناقش الفريق كيف يمكن إعادة توجيه سيناريوهات الاستخدام لاختبار الاستجابة والأداء العام على الأجهزة القديمة أو المنخفضة الجودة. ما هي أفكارك؟

أعلمت أننا نخطط لإجراء ماراثون قياس لاستهلاك الطاقة لتطبيقات FOSS/كيدي في أوائل عام 2022؟ ما هي التطبيقات التي تود أن ترى سيناريوهات استخدام قياسية تعد لها؟ شارك أفكارك معنا هنا أو قدم SUS الخاص بك في مستودع GitLab!

نظام مرجعي قابل للتكرار

سيناريوهات الاستخدام القياسية يشغل على نظام مرجعي، وإحدى القضايا المهمة التي طرحت هي كيفية الحصول على نظام مرجعي قابل للتكرار. هناك عدة طبقات نظام يجب النظر فيها: العتاد (وحدة المعالجة المركزية، القرص، ذاكرة الوصول العشوائي، إلخ)؛ نظام التشغيل وخدمات نظام التشغيل مثل مدير الأنشطة في بلازما بالإضافة إلى اضبطاتها؛ و اضبط التطبيق قيد الاختبار بالإضافة إلى أي تطبيقات ذات صلة (مثل Akonadi لتطبيقات PIM). من ناحية، من الضروري الحصول على بيئة محكمة لأجل تفسير النتائج؛ من ناحية أخرى، من المرغوب فيه الحصول على قياسات تعكس بيئات حاسوب فعلية، وربما صاخبة، لـ أجل فهم استهلاك الطاقة الحقيقي للبرمجيات. في النهاية، ما إذا كان ينبغي الحصول على بيئات حاسوب محكمة أو طبيعية سيعتمد على ما ستستخدم له البيانات، وهذا سيختلف للباحثين، المطورين، مدققي اللصائق البيئية، الشركات، إلخ.

على سبيل المثال، للمطورين المهتمين بإجراء اختبارات وحدات كفاءة الطاقة أو الكسب ختم Blauer Engel، سيكون من الضروري الحصول على بيئات محددة بوضوح. إذن، ما هي الطرق المريحة والسريعة لـ أجل إعادة النظام إلى حالة معروفة؟ نوقشت ثلاث أفكار: (i) التقاط لقطات لنظام ملفات (مثل Snapper)، (ii) مسح خبيئة النظام، و (iii) استبدال ملفات الاضبط. إذا كانت لديك أفكار أخرى، فأخبرنا بها هنا!

بالنسبة للبيئات الواقعية، أحد الاقتراحات، وربما يثير الجدل، هو تسجيل أداء العتاد واستخدام الطاقة الكهربائية بينما يستخدم الناس حواسيبهم الشخصية. هل من متطوعين؟

مخرجات البيانات

عند قياس استهلاك الطاقة في مختبر، وخاصة لتصديق Blauer Engel البيئي، قد تتولد ثلاثة أنواع من ملفات البيانات: (i) ملف سجل للإجراءات (انظر أعلاه بخصوص أتمتة مثل هذه الملفات)، (ii) بيانات أداء العتاد (وحدة المعالجة المركزية، ذاكرة الوصول العشوائي، إلخ)، و (iii) استخدام الطاقة الكهربائية. نظرًا لأنه في بعض الحالات ستحتاج بيانات المخرجات إلى أن تعرّف ذاتيًا (مثل مسجلات الطابع الزمني في سكربتات xdotool)، من الضروري النظر في شكل البيانات قبل القياس في المختبر.

أثيرت عدة قضايا متعلقة بالبيانات: هل يجب توحيد مخرجات البيانات لـ أجل مواءمة المخرجات عبر حملات القياس، أم يكفي نشر البيانات المجمعة بتنسيق متاح (على سبيل المثال، كملفات .csv كما في مستودع FEEP)؟ ما هي دقة الطابع الزمني المطلوبة (مثل، ثواني مقابل أجزاء من الثانية)؟ هذه الأسئلة لا تزال مفتوحة في الوقت الحالي، لكن الفريق قرر أننا بحاجة إلى نظرة عامة على الأجهزة/السكربتات المتوافقة مع FOSS (مثل سكربت Achim Guldner لـ Gude Expert Power Control 1202 Series) ومجموعات الأدوات (مثل أدوات التحليل الإحصائي مثل OSCAR، R، Julia، Octave، PSPP، NumPy) المستخدمة للقياسات والتحليل، وهو حاليا قيد الإنجاز.

أجهزة قياس الطاقة

تشير معايير Blauer Engel إلى جهازي قياس طاقة (PM) على وجه الخصوص: Janitza UMG 604 و Gude Expert Power Control 1202. هذه الأجهزة ليست رخيصة. في عام 2020، اخترق مساهم كيدي القديم Volker Krause قابس طاقة بقيمة 8 يورو و كتب عنه. كما هو موضح في المنشور، هذه القوابس غير المكلفة تستطيع الحصول على معدل أخذ عينات يصل إلى 200 مللي ثانية. قاد هذا إلى فكرة استخدام أجهزة قياس طاقة غير مكلفة في مختبرات منزلية بميزانية منخفضة. لهذا الغرض، سيكون من المفيد في النهاية مقارنة النتائج من أجهزة قياس الطاقة الاحترافية بأجهزة الميزانية لمعرفة كيفية مقارنتها. هل سيكون أي شخص في المجتمع مهتمًا بالقيام بذلك؟

من منشور مدونة Volker Krause: «مثال قياس (فترة أخذ عينات 200 مللي ثانية، بدون مرشح): يحرك مؤشر الماوس بين العينات 100 و 150، مع ذروة أثناء التحويم فوق إدخال شريط المهام.»

طريقة أخرى لقياس استهلاك الطاقة أتت من مساهم كيدي David Hurka، الذي لديه اقتراح لحساسات طاقة USB SPI لتوفير بديل بدقة أعلى لأجهزة قياس الطاقة التي تقيس عند مأخذ الحائط.

قضايا مفتوحة لمختبرات القياس

نوقشت عدة قضايا أخرى متعلقة باستهلاك الطاقة وقياسات المختبر. على الرغم من أن القرارات النهائية لم تتخذ في كل حالة، فإن العديد من هذه القضايا المفتوحة ستكون مهمة للنظر فيها للمستقبل.

• فكرة أداة صديقة للتسويق لـ أجل لفت الانتباه إلى استهلاك الطاقة للبرمجيات.
  • على سبيل المثال، زر 'Eco' لمقياس كفاءة الطاقة/البصمة الكربونية (قارن بالبصمة الكربونية للسفر في تطبيق Itinerary).
  • لاحظ أن وظيفة مماثلة يوفرها بالفعل PowerTop، على الرغم من بقاء قضايا مفتوحة (متى يكون من الآمن التمكين لـ أجل تجنب فقدان البيانات، وتجمد الجهاز؟).
• متى تفوق العيوب الفوائد لـ أجل دعم العتاد الأقدم؟
  • دعنا ندعو الباحثين العاملين على هذا لـ أجل المناقشة مع مجتمع كيدي إيكو.
• التعاون المستقبلي:
  • سبرنت مشترك مع المشاريع ذات الصلة (مثل SoftAWERE)؟ (ربما يثير اهتمام القارئ: قدم Max Schulze من SoftAWERE/SDIA في اجتماع كيدي إيكو الشهري في يناير 2022، والذي يمكنك قراءة محضر اجتماعه من هنا.)
  • مناقشة المواضيع المذكورة أعلاه والمزيد مع المجتمعات الأخرى ذات الصلة (Bits & Bäume، Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung، إلخ)؟

خلاصة

كان السبرنت عبر الإنترنت فرصة رائعة لـ أجل جمع المجتمع وتحريك مشروع كيدي إيكو إلى الأمام، خاصة ونحن نستعد لمختبر القياس المجتمعي الذي سيعقد في KDAB Berlin وأول ماراثون قياس من بين العديد (مخطط له في أوائل عام 2022)! يعتمد نجاح مثل هذه الأحداث أولاً وقبل كل شيء على المجتمع، لذا اسمحوا لنا أن نبعث شكرًا صادقًا لكل من انضم إلى المحادثة. نتطلع إلى نمو المجتمع في عام 2022! علاوة على ذلك، لم يكن بإمكاننا فعل ما نفعله بدون دعم KDE e.V. وكذلك BMU/UBA، اللذان يدعمان مشروع BE4FOSS ماليًا (على الرغم من أن الناشر هو المسؤول الوحيد عن محتوى هذا المنشور).

إشعار التمويل

مُوِّل مشروع BE4FOSS من قبل الوكالة الاتحادية للبيئة والوزارة الاتحادية للبيئة وحماية الطبيعة والسلامة النووية وحماية المستهلك (BMUV¹). الأموال تتاح بقرار من البوندستاغ الألماني.

الناشر مسؤول عن محتوى هذا المنشور.

¹ شعارات BMUV و UBA الرسمية ترسل بالطلب فقط على: verbaendefoerderung@uba.de

المقالة مساهمة من Joseph P. De Veaugh-Geiss تحت ترخيص CC-BY-4.0.