Спринт KDE Eco 2021: подробиці щодо планування спільнотою екологічного проєкту KDE

Понеділок, 7 лютого 2022 | Joseph P. De Veaugh-Geiss

Це гілка оголошення про спринт KDE Eco, розміщеного на Dot.

11 грудня 2021 року KDE Eco відбувся перший із багатьох запланованих спринтів, у якому взяли участь 7 учасників. Від початку, спринт планувався як особиста зустріч для започаткування лабораторії вимірювання спільноти, але епідемія коронавірусу внесла свої корективи. Втім, спільнота розгорнула свої звичні ресурси, і зустріч було проведено в інтернеті.

Оголошення про спринт KDE Eco 2021 на KDE News

У цьому довгому дописі ми надамо докладний огляд основних обговорених на спринті питань та результатів обговорення; див. також протокол, щоб дізнатися більше.

Чи знаєте ви це?

Обговорення, подібні до цього, відбуваються щомісяця на зустрічах спільноти кожної другої середи місяця з 19:00 до 20:00 за центральноєвропейським часом (за Берліном).

Створення команди KDE Eco

На сьогодні, KDE Eco складається з трьох пов'язаних проєктів: (i) Free and open source Energy Efficiency Project (FEEP), (ii) Blauer Engel For FOSS (BE4FOSS) і (iii) програм Blauer Engel. У кожному з проєктів акцент зроблено на окремому моменті: FEEP пов'язано із вимірюванням споживання енергії вільним програмним забезпеченням, акцент у BE4FOSS зроблено на організації спільноти та поширенні інформації щодо екомітки Blauer Engel, а сховище програм Blauer Engel містить усі документи, які пов'язано із сертифікацією KDE та вільного програмного забезпечення екоміткою. До спринту ці три сховища для проєктів зберігалися в окремих просторах назв. Тепер же, усі три сховища поєднано в https://invent.kde.org/teams/eco.

Поєднання проєктів в одній команді ясніше пов'язує поточні і можливі майбутні проєкти. Більше того, спільний простір назв краще пасує до проєктів спільноти. Ознайомлюйтеся із діяльністю кожного з проєктів в єдиному просторі команди!

Команди > KDE Eco

Подання запиту щодо надання Blauer Engel для Okular

Виміряно споживання енергії для трьох програм KDE: Okular, KMail та Krita. Серед цих трьох, подання на мітку Blauer Engel для Okular і KMail перебувають певний час у стані приготування. Метою номер один є завершення подання для Okular. Ми раді повідомити, що після спринту, Okular подано на сертифікацію, зараз подання перебуває на стадії рецензування. Ми сподіваємося на відгук від RAL gGmbH, основної організації сертифікації Blauer Engel, протягом 2-3 місяців. Невдовзі буде подано і документи щодо KMail.

Під час рецензування групою подання для Okular учасниками було подано багато цікавих зауважень. Одне із зауважень, наприклад, виникло під час обговорення критеріїв прозорості Blauer Engel (Section 3.1.3.2). Мальте Райсіґ (Malte Reißig) з IASS Research Group у роботі «Digitalisation and Sustainability Transformations» вказав, як відкрита розробка може позитивно вплинути на деякі інші вимоги та критерії присвоєння мітки (див. це обговорення), зокрема тривалість супроводу та автономію користувачів програмного продукту. Тобто, користувачі вільного програмного забезпечення не лише пасивно використовують програмне забезпечення, але мають стимули і можуть висловлюють побажання щодо майбутнього розвитку програм, а також можуть активно брати участь у плануванні етапів розвитку. Більше того, при відкритій розробці повідомлення про внески можна пов'язати із певними проблемами та вадами, про які повідомляє спільнота користувачів та розробників. Якщо програмне забезпечення є вільним, програма є не лише продуктом, але відкритим процесом, який відбиває потреби і побажання його користувачів та спільнот. У вільному програмному забезпеченні спільнота визначає напрямок розробки!

Піктограма Okular

Іншу проблему пов'язано із поширенням вільного програмного забезпечення та тим, як це ускладнює виконання критеріїв Blauer Engel. Оскільки вільне програмне забезпечення поширюється у децентралізований спосіб — будь-яка програма має численні випуски та канали поширення. Розгляньмо Okular, який поширюється не лише у форматі пакунків Flatpak, але і у Microsoft Store, не беручи до уваги численні дистрибутиви GNU/Linux (наприклад, OpenSuse, Debian). Відмінності в інфраструктурі пакування можуть впливати на виконання вимог Blauer Engel, зокрема можливості вилучення, модульності тощо.

Компанії, які випускають закрите програмне забезпечення, типово поширюють свої продукти централізовано і не мають таких проблем. Беручи це до уваги, однією із можливостей, яку обговорювали у групі, є сертифікація лише початкового коду програм, а отже, виключення проблем із різницею у способах пакування та поширення продуктів. Ще однією можливістю є сертифікація специфічних для дистрибутивів випусків, зокрема випусків з Microsoft Store. Фактично, останній варіант пізніше може бути використано для маркетингу і доступу до нових користувачів та залучення їх до спільноти KDE — див., наприклад, це обговорення.

Нам цікаві ваші думки. Будь ласка, долучайтеся до спілкування у наших списках листування або кімнаті Matrix або у системі стеження за вадами наших сховищ GitLab!

Стандартні сценарії користування

Стандартний сценарій користування (SUS) відбиває типові функціональні можливості програми із врахуванням частоти використання цих функціональних можливостей. Стандартні сценарії користування є центральною позицією для вимірювання споживання енергії частиною програмного забезпечення.

При перегляді журналу дій SUS для Okular з метою подання даних для мітки Blauer Engel, було піднято два важливих питання, які удосконалять реалізацію SUS при вимірюванні у лабораторії. Першим є спостереження у документуванні не лише дій, але і об'єктів дій (наприклад, якщо використовують програму для читання pdf, документа pdf, який відкрито), оскільки це може вплинути на споживання енергії. Іншим є те, що включення бездіяльності важливе при визначенні SUS: вивчення бездіяльності є реалістичним сценарієм і може продемонструвати те, що нічого не відбувається, коли нічого не повинно відбуватися.

До віртуальної таблиці додано декілька інших проблем. Ніколас Фелла (Nicolas Fella), інженер-програміст у берлінському KDAB, висловив зацікавленість у порівнянні двох клієнтських програм для спілкування, що перевело обговорення на визначення єдиних сценаріїв при порівнянні двох програм із подібним використанням. Єдиний SUS обмежить функціональні можливості програмного забезпечення можна перевірити, але це зробить результати вимірювання безпосередньо порівнювати. Більше того, для клієнт-серверного програмного забезпечення, зокрема клієнтів спілкування або електронної пошти, маємо проблему із мережевим компонентом, який слід налаштувати для контрольованого тестування, а також вимірювання споживання енергії сервером. Колишній президент KDE e.V. та давній учасник розробки KDE Корнеліус Шумахер зазначив, що для вимірювань для KMail було виміряно лише обчислювальну роботу локального комп'ютера. Вимірювання нелокальних обчислень у клієнт-серверному програмному забезпеченні є важливішим, ніж будь-коли, у сучасному світі, і це заплановано зробити у модифікованих критеріях щодо програмного забезпечення для Blauer Engel.

Вікно вітання KMail

Ще одним з обговорених питань було абстрактне визначення дій SUS з метою автоматизації реалізації сценаріїв користування із різними інструментами (Actiona, xdotool, KXmlGui тощо). Важливим є те, що різні інструменти емуляції виконують різні речі, що робить проблемним автоматизацію процесу. Наприклад, якщо для емуляції використано KXmlGui, не можна вводити текст, а отже, може знадобитися щось подібне до xdotool. Якщо вже йдеться про це, іншою пропозицією була структуризація SUS у такий спосіб, щоб створення журналу дій також було автоматизовано. Чи не бажає хтось зі спільноти кинути виклик цим проблемам?

Крім того, групою обговорено те, як сценарії користування можна повторно використати для тестування чутливості та загальної швидкодії на застарілому та малопотужному обладнанні. Маєте гадку?

Чи знали ви, що ми плануємо сеанс вимірювання для вимірювання споживання енергії програмами із вільним відкритим кодом та програмами KDE на початку 2022 року? Які програми ви б хотіли бачити готовими до стандартного сценарію користування? Поділіться вашими ідеями з нами тут або надішліть ваші стандартні сценарії користування до нашого сховища GitLab!

Відтворювана еталонна система

Стандартні сценарії користування запускаються на еталонній системі, і важливим питанням є створення відтворюваної еталонної системи. Слід брати до уваги декілька шарів системи: обладнання (процесор, диск, оперативна пам'ять тощо); операційна система та служби операційної системи, зокрема засіб керування простором дій у Плазмі, а також налаштування системи і служб; а також налаштування програми для перевірки та усіх пов'язаних із нею програм (наприклад, Akonadi для програм з керування особистими даними). З одного боку, необхідно мати контрольоване середовище, щоб мати змогу інтерпретувати результати; з іншого боку, бажано мати результати, які відповідатимуть справжньому, можливо, навіть з невеликими відхиленнями, обчислювальному середовищами, щоб зрозуміти справжнє споживання енергії програмним забезпеченням. Зрештою, те, яке обчислювальне середовище буде використано, контрольоване чи природне, буде використано, залежить від призначення даних, а воно буде різним для дослідників, розробників, аудиторів екомітки, компаній тощо.

Наприклад, розробникам, які зацікавлені у перевірці енергоефективності тестування модулів або отриманні мітки Blauer Engel, необхідно мати явним чином визначені середовища. Отже, яким буде зручний і швидкий спосіб перевести систему у визначений стан? Було обговорено три ідеї: (i) створення знімків файлової системи (наприклад, Snapper), (ii) чищення кешу системи і (iii) заміна файлів налаштувань. Якщо у вас є інші ідеї, дайте нам знати тут!

Для реальних середовищ однією з пропозицій, потенційно спірною, було записування швидкодії обладнання та споживання електричної енергії під час користування особистим комп'ютером. Є охочі?

Виведення даних

При вимірюванні споживання енергії у лабораторії, зокрема для екосертифікації Blauer Engel, можна створити три типи файлів даних: (i) файл журналу дій (див. вище про повторну автоматизацію таких файлів журналу), (ii) дані швидкодії обладнання (процесор, оперативна пам'ять тощо) і (iii) споживання електричної енергії. Оскільки у певних випадках виведені дані мають бути самодостатніми (наприклад, засоби запису часових позначок у скриптах xdotool), важливо брати до уваги те, як мають виглядати дані до вимірювань у лабораторії.

Із даними пов'язано декілька проблем: має бути виведення даних стандартизовано для гармонізації виведеного між серіями вимірювань чи достатньо просто оприлюднити зібрані дані у доступному форматі (наприклад, файлів .csv, зокрема файлів у сховищі FEEP)? Наскільки точними мають бути часові позначки (наприклад, достатньо секунд чи потрібні частки секунди)? Поки ці питання лишаються відкритим, але група вирішила, що нам потрібен огляд сумісних із вільним відкритим програмним забезпеченням пристроїв та скриптів (наприклад, скрипту Акіма Ґулднера для Gude Expert Power Control 1202 Series) та наборів інструментів (наприклад, інструментів статистичного аналізу, зокрема OSCAR, R, Julia, Octave, PSPP, NumPy), які використовують для вимірювання та аналізу. Зараз це завдання виконується.

Пристрої вимірювання потужності

Критерії Blauer Engel, зокрема, посилаються на два засоби вимірювання споживання енергії: Janitza UMG 604 та Gude Expert Power Control 1202. Це недешеві пристрої. У 2020 році давній учасник розробки KDE Фолькер Краузе (Volker Krause) створив вимірювач за 8 євро і написав про нього. Як описано у дописі у блозі, дешеві вимірювачі можуть отримувати дані із періодом 200 мс. Таким чином, виникла ідея використання недорогих вимірювачів у низькобюджетних домашніх лабораторіях. Отже, було б корисним порівняти результати вимірювання професійними засобами та бюджетними. Чи не міг би хтось зі спільноти за це узятися?

З допису у блозі Фолькера Краузе: «Приклад вимірювання (інтервал між вимірюваннями 200 мс, без фільтрування): вказівник миші пересувається між зразками 100 і 150 із піком при наведенні на запис панелі задач.»

Ще один спосіб вимірювання споживання енергії було запропоновано учасником розробки KDE Давідом Гуркою (David Hurka). Він запропонував датчики потужності SPI USB, які є альтернативою вимірювачам потужності із високою роздільністю, які працюють на розетці.

Невирішені проблеми із вимірювальними лабораторіями

Було обговорено декілька інших проблем, які пов'язано зі споживанням енергії та лабораторними вимірюваннями. Хоча остаточні рішення для усіх випадків не було прийнято, багато з невирішених проблем є важливими для подальшого поступу проєкту.

• Ідея зручного для ринку інструмента для привернення уваги до споживання енергії програмним забезпеченням.
  • Наприклад, кнопка «Eco» для вимірювача енергоефективності та вуглецевого сліду (порівняйте із вуглецевим слідом подорожі у програмі Itinerary).
  • Зауважте, що подібні функціональні можливості вже надаються PowerTop, хоча лишаються певні проблеми (коли програму безпечно вмикати і уникати втрати даних і підвисання системи?).
• Коли недоліки переважають переваги від підтримки застарілого обладнання?
  • Варто запросити дослідників, які працюють над цим питанням для обговорення зі спільнотою KDE.
• Майбутня співпраця:
  • Спільний спринт із пов'язаними проєктами (наприклад, SoftAWERE)? (Можливо, цікаве для читача: Макс Шульце (Max Schulze) з SoftAWERE/SDIA зробив доповідь на щомісячній зустрічі KDE Eco у січні 2022 року, з якою ви можете ознайомитися у протоколі тут.)
  • Обговорити згадані вище та інші теми із іншими пов'язаними спільнотами (Bits & Bäume, Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung тощо)?

Висновки

Інтернет-спринт був чудовою нагодою об'єднати спільноту і просунути проєкт KDE далі, особливо тоді, коли ми готуємо вимірювальну лабораторію спільноти, яка працюватиме у берлінській KDAB, і перший із багатьох виміроатлонів (плануємо на початок 2022 року)! Успіх таких зустрічей передусім залежить від спільноти, тому маємо найщиріше подякувати тим, хто долучився до спілкування. Ми сподіваємося на зростання спільноти у 2022 році! Крім того, ми не змогли б зробити того, що зробили, без підтримки KDE e.V., а також BMU/UBA, яке фінансово підтримало проєкт BE4FOSS (хоча за вміст цієї публікації відповідає лише видавець).

Зауваження щодо фінансування

Проєкт BE4FOSS було профінансовано Федеральною Агенцією з навколишнього середовища та Федеральним міністерством навколишнього середовища, збереження природи, ядерної безпеки та захисту споживачів (BMUV¹). Доступ до фінансування було затверджено Бундестагом ФРН.

За вміст цієї публікації відповідає її видавець.

1 Офіційні логотипи BMUV і UBA надсилаються лише за запитом за адресою verbaendefoerderung@uba.de