Вступ: про що це все?

У підручнику наведено короткий огляд шкоди навколишньому середовищу, якого може завдати програмне забезпечення, та того, як екомітка Blue Angel — офіційна мітка захисту навколишнього середовища уряду Німеччини — надає у ваше розпорядження інструменти виміру дизайну програмного забезпечення для сталого розвитку.

«Blue Angel» присуджується низці продуктів і послуг, від побутових мийних засобів до дрібної побутової техніки та будівельних виробів. У 2020 році Німецьке агентство з охорони навколишнього середовища розширило критерії нагородження, включивши до них програмні продукти. Це була перша у світі екологічна сертифікація, яка поєднала прозорість та автономію користувача – два стовпи вільного програмного забезпечення з відкритим вихідним кодом (FOSS) – зі сталим розвитком.

На цьому етапі ви можете поставити питання: як взагалі співвідносяться сталий розвиток та програмне забезпечення? Як щось таке, здавалося б, несуттєве, як програмне забезпечення, може мати вплив на навколишнє середовище? У цьому підручнику ми докладніше розглянемо деякі способи, якими програмне забезпечення сприяє кліматичній кризі, та як може допомогти дотримання критеріїв екологічної сертифікації програмного забезпечення «Blue Angel».

Книгу поділено та три частини:

• Частина I: Вплив програмного забезпечення на навколишнє середовища
• Частина II: Екосертифікація програмного забезпечення для робочих станцій
• Частина III: Виконання критерії нагородження Blue Angel

У той час як у Частині I досліджується чому, а в Частині II — що таке екосертифікації програмного забезпечення, у Частині III обговорюємо як, пояснюючи, що вам потрібно знати, щоб виміряти споживання енергії вашим програмним забезпеченням та подати заявку на екомаркування «Blue Angel». Зокрема, у цьому розділі ми надаємо покрокове керівництво щодо виконання азбуки критеріїв нагородження: (A) Ефективність використання ресурсів та енергії, (B) Потенційний термін служби обладнання та (C) Автономність користувача.

Частина I: Вплив програмного забезпечення на навколишнє середовища

У 2021 році Асоціація обчислювальної техніки (ACM), найстаріше науково-освітнє обчислювальне товариство у світі, опублікувала звіт Ради з технологічної політики під назвою «Обчислювальна техніка та зміна клімату». Серед інших висновків, у звіті досліджується експоненційне зростання споживання енергії та ресурсів штучним інтелектом, а також пристроями, з'єднаними з інтернетом, як у виробництві, так і у користуванні. Оцінки звіту вражають. Тільки у 2021 році, за оцінками, сектор інформаційно-комунікаційних технологій (ІКТ) давав від 1,8 до 3,9% світових викидів вуглецю. Для порівняння, це на рівні світової авіаційної промисловості, яка, за оцінками, дала 2,5% усіх викидів. У звіті висловлено попередження, що якщо нічого не змінити, до 2050 року викиди вуглецю, пов'язані з сектором ІКТ, зростуть до понад 30% усіх викидів у світі.

У своїх висновках автори визнають невід'ємну суперечність цифровізації: цифрові технології «можуть допомогти пом'якшити зміну клімату», але вони «спочатку повинні перестати сприяти цьому» (с. 1). ІКТ революціонізували те, як ми живемо, і їх часто хвалять за те, що вони привносять зручність та ефективність у наше повсякденне життя. Компанії використовували цифрові технології для ефективного розподілу всіляких споживчих товарів та дематеріалізації товарів повсякденного вжитку. Такі транспортні засоби, як автомобілі, скутери та велосипеди, легко доступні для оренди через програми для смартфонів, що усуває необхідність для людей володіти ними, щоб користуватися ними. Широке поширення можливостей потокового відео означає, що не потрібно виготовляти або транспортувати DVD- та Blu-ray диски для перегляду фільму, а спалювати паливо, щоб доїхати до пункту прокату, щоб придбати один із них у суботу ввечері, – це вже минуле. Електронні книги замінили цілі книжкові полиці. Через глобальну пандемію SARS-CoV-2, яка прискорює інтеграцію цифрових технологій у всі аспекти повсякденного життя, відеоконференції замінюють заходи, які колись (майже) виключно проводилися особисто, включаючи офісні зустрічі, міжнародні академічні конференції, місцеві фортепіанні концерти та навіть перші побачення… і все це тепер можливо, не виходячи з дому за допомогою пристрою, з'єднаного з інтернетом.

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

Але чи насправді все це актуальне?

Інтернет та пристрої, які ми використовуємо для встановлення з ним з'єднання, потребують інфраструктури — реального, фізичного обладнання, яке потребує енергії та споживає ресурси. Часто не враховується вплив на навколишнє середовище, наприклад, заводів, які виробляють ці пристрої, або інфраструктури, що охоплює континенти та забезпечує глобальний зв'язок. Все це вимагає енергії для щоденного використання. Більше того, обладнання, яке більше не використовується, або потрапляє до центрів утилізації для переробки після закінчення терміну служби (що вимагає ще більше енергії), або як електронні відходи, які є токсичними як для людей, так і для навколишнього середовища. Потім виробляються та транспортуються нові пристрої, в багатьох випадках без потреби.

«Ще рідше цінується той факт, що ключем до підвищення енергоефективності та захисту природних ресурсів є не апаратне забезпечення, а, перш за все, програмне забезпечення». — Критерії премії «Blue Angel»: [Ресурсо- та енергоефективні програмні продукти] (https://produktinfo.blauer-engel.de/uploads/criteriafile/en/DE-UZ%20215-202001-en-Criteria-V2.pdf) (с. 5)

У цій ширшій картині може бути недооцінена критична роль програмного забезпечення у завданні шкоди навколишньому середовищу. Дійсно, у багатьох випадках саме програмне забезпечення визначає споживання енергії та термін служби цифрової інфраструктури. У цьому підручнику докладно розглянуто деякі способи, якими цифрові технології сприяють завданню шкоди навколишньому середовищу та кліматичній кризі. Слід зазначити, що цей підручник не є антитехнологічним – безсумнівно, цифровізація покращила життя величезної кількості людей незліченними способами. Але екологічний вплив цифрових технологій вимагає від нас глибше задуматися про те, як ми їх використовуємо та як ми можемо використовувати їх ефективніше. І гарна новина полягає в тому, що завдяки розробці програмного забезпечення розробники можуть мати негайний та значний вплив на багато питань, що обговорюються тут.

Протягом усього тексту, і особливо в наступних розділах, екомаркування «Blue Angel» для програмного забезпечення для настільних комп’ютерів слугуватиме орієнтиром для розробки програмного забезпечення для сталого розвитку. Але що взагалі означає «Blue Angel»?

Екомаркування «Blue Angel» (нім. Blauer Engel Umweltzeichen) – це офіційне екологічне маркування уряду Німеччини. У 2020 році Німецьке агентство з охорони навколишнього середовища (нім. Umweltbundesamt або UBA) опублікувало критерії нагородження для сертифікації програмних продуктів для настільних комп’ютерів, що стало першою у світі екологічною сертифікацією, яка пов’язує прозорість та автономію користувача зі сталим розвитком. Безкоштовне програмне забезпечення з відкритим кодом, або FOSS, має тут реальну перевагу. Сподіваємося, що до кінця цього підручника ви краще зрозумієте, як це зробити.

Але для того, щоб ефективно вирішити проблему, ми повинні спочатку визначити, у чому полягає проблема. Тож давайте спочатку зрозуміємо, що мають на увазі під цифровим вуглецевим слідом і як у цьому задіяне програмне забезпечення, яке ми використовуємо щодня.

Матеріальні наслідки цифрових технологій

Цифрові технології часто (і помилково) вважають несуттєвими у цьому плані. Коли ми надсилаємо електронний лист або вивантажуємо дані в хмару, легко уявити, як наші передачі зникають у небутті. Але існує цілком реальний, дуже матеріальний аспект оцифрування, який охоплює не лише наші фізичні пристрої, такі як смартфони та ноутбуки, але й переробні заводи для видобутих металів, необхідні для їхньої роботи, контейнеровози, що перевозять обладнання для масового виробництва, а також кабелі та центри обробки даних, які з'єднують їх з глобальними мережами. Звіт за 2018 рік [«Lean ICT: Towards Digital Sobriety»] (https://theshiftproject.org/wp-content/uploads/2019/03/Lean-ICT-Report_The-Shift-Project_2019.pdf) описує цю проблему так:

[М]атеріальний наслідок цифрових технологій значною мірою недооцінюється їхніми користувачами, враховуючи мініатюризацію обладнання та «невидимість» використовуваної інфраструктури. Це явище посилюється широкою доступністю послуг у «Хмарі», що робить фізичну реальність використання ще більш непомітною та призводить до недооцінки прямого впливу цифрових технологій на навколишнє середовище. (с. 10)

Як пожартував автор однієї зі статей у New York Times: «Люди думають, що дані знаходяться в хмарі, але це не так. Вони знаходяться в океані», маючи на увазі підводні комунікаційні кабелі, що охоплюють усю земну кулю. Щоб донести відчутну реальність «хмари» до землі та під океаном, нам потрібно змінити нашу перспективу на приховану інфраструктуру, яка забезпечує основу нашого цифрового життя. Мережі передачі даних можуть бути значною мірою під водою, але викиди вуглецю матимуть жахливі наслідки для всього природного середовища. На COP27 у листопаді 2022 року Генеральний секретар Організації Об'єднаних Націй Антоніу Гутерреш підкреслив критичність моменту, коли заявив: «Ми йдемо по шосе до кліматичного пекла, тримаючи ногу на педалі газу».

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

Що в секторі ІКТ сприяє підвищенню рівня CO₂ в атмосфері?

Між 2012 і 2018 роками потреба в енергії для штучного інтелекту (ШІ) зросла в 300 000 разів, і наразі вона подвоюється кожні кілька місяців. За оцінками, навчання однієї моделі ШІ (наприклад, тої, що використовуються в машинному перекладі або моделюванні мови) може вимагати енергії, еквівалентної перельотам з Нью-Йорка до Сан-Франциско туди й назад… 300 разів (це близько 626 000 фунтів CO₂)! Технологія блокчейн також є сумнозвісним фактором, що сприяє стрімкому зростанню споживання енергії, зокрема, системам підтвердження роботи, таким як Bitcoin, яка, як повідомляє Harvard Business Review, потребує стільки ж енергії, скільки цілі країни, такі як Швеція чи Малайзія.

Водночас ми використовуємо більше цифрових пристроїв, ніж будь-коли раніше. Кількість пристроїв, з'єднаних із інтернетом, зокрема ноутбуки та смартфони, а також смарт-телевізори, домашні асистенти та інші пристрої інтернету речей, стрімко зростає, і очікується, що вона перевищить 75 мільярдів до 2025 року. Це приблизно 10 пристроїв на кожну людину на землі (хоча глобальний розподіл цих пристроїв далеко не рівномірний). У світі швидко зросла популярність смартфонів, як і потреба в ресурсах, необхідних для виробництва нових та все більш потужних пристроїв. Виробництво цих пристроїв, включаючи видобуток рідкоземельних металів, необхідних для їхньої роботи, їхнього транспортування, використання та остаточна утилізація, споживають значну кількість енергії.

Однак тут важливо підкреслити, що споживання енергії — це не те саме, що викиди вуглецю. Викиди вуглецю залежать від конкретного поєднання палива, що використовується для виробництва електроенергії, яке називають [міксом виробництва електроенергії або енергії] (https://www.planete-energies.com/en/medias/close/what-power-generation-mix). Наприклад, для [енергопостачання Європейського Союзу] (https://www.bpb.de/nachschlagen/zahlen-und-fakten/europa/75140/themengrafik-energiemix-nach-staaten) у 2016 році мікс виробництва електроенергії включав 32,9% нафти, 23,9% газу, 14,9% вугілля, 13,7% ядерної енергії та 14,5% відновлюваних джерел енергії. Пісня енергетичної кризи 2022 року енергетичний баланс в ЄС змінився — у деяких випадках на кращу довгострокову перспективу, у деяких — на гіршу короткострокову перспективу. Відносні викиди вуглецю залежатимуть від цього балансу: наприклад, споживання енергії зі 100% вуглецево-нейтральних джерел не призводить до прямих викидів CO₂.

Відносна шкода — Або, коли менше це не більше

Оцифрування часто асоціюється з «дематеріалізацією»: друк концертних чи туристичних квитків на папері більше не є необхідним, оскільки їх можна завантажити та подати на смартфоні; фотографії не збираються в переповнених коробках з-під взуття, а на невеликому планшеті чи жорсткому диску; тисячі фільмів і телесеріалів транслюються на ноутбуках, що робить колекції фільмів пережитком минулого. У багатьох випадках для всього вищезазначеного — і багато-багато іншого — використовується один пристрій, смартфон.

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

Хоча цифрові пристрої можуть зменшити деякі форми відходів, оцінка справжнього впливу цифрових технологій на навколишнє середовище вимагає врахування всього життєвого циклу виробу. Це включає витрати на виробництво та транспортування цифрових пристроїв (до магазину та назад, а також на сміттєзвалище) або витрати на усунення шкоди, завданої електронними відходами, для навколишнього середовища. Це особливо актуально, якщо врахувати сукупний вуглецевий слід наших цифрових технологій, оскільки в деяких випадках виробництво пристроїв разом з їх транспортуванням та обробкою після закінчення терміну служби призводять до більших викидів парникових газів, ніж використання пристроїв протягом весь термін їхньої експлуатації. Щоб проілюструвати це, розглянемо [Звіт про екологічну відповідальність Apple] за 2019 рік (https://www.apple.com/environment/pdf/Apple_Environmental_Responsibility_Report_2019.pdf), у якому оцінюється, що Apple внесла 25,2 мільйона метричних тонн CO₂ у 2018 році (с. 9). Більша частина цього — аж вісімдесят відсотків (!!!) — стосується виробництва (74%), транспортування (5%) та обробки після закінчення терміну служби (<1%). Лише 19% стосуються від фактичного використання пристроїв.

Тож коли ж витрати на виробництво цифрового пристрою, який замінить усі ці аналогові речі, стануть виправданими? Книга “Smarte Grüne Welt” (англійською: Smart Green World) авторів Стеффена Ланге та Тільмана Сантаріуса (2018) досліджує складність врахування відносної шкоди для навколишнього середовища під час спроби відповісти на такі питання. Розглянемо цей уривок, у якому автори досліджують вплив друку паперових книг на навколишнє середовище порівняно з виробництвом електронних книг (стор. 29–31; переклад з німецької):

Виробництво електронних пристроїв, очевидно, є більш енергоємним та ресурсоємним процесом, ніж друк однієї книги. Наприклад, на виробництво електронної книги, яка зазвичай вагою менше 200 грамів, витрачається близько 15 кілограмів різних матеріалів (особливо невідновлюваних металів та рідкісноземельних елементів), 300 літрів води та 170 кілограмів парникового газу вуглекислого газу. Однак вирішальними є не лише кількість вхідних та вихідних матеріалів, а й їхній вплив на навколишнє середовище. Між електронними книгами та книгами існують великі відмінності, особливо в токсичності матеріалів та виробничих процесів. Це правда, що паперова промисловість у багатьох країнах (досі) має дуже негативний вплив на навколишнє середовище, наприклад, коли хлор або кислоти отруюють місцеві води. Однак вплив електронної промисловості на навколишнє середовище іноді є руйнівним: електронні книги та інші ІТ-продукти містять бромовані антипірени, фталати, берилій та численні інші хімічні речовини, які є серйозно шкідливими для здоров'я та навколишнього середовища. Не кажучи вже про соціальні наслідки, такі як часом жалюгідні умови праці, за яких кобальт, паладій, тантал та інші ресурси цифрових пристроїв спочатку видобуваються у країнах-диктатурах, таких як Республіка Конго або в інших країнах глобального Півдня, а потім утилізуються там після закінчення терміну служби як екологічно шкідливі електронні відходи.

Незважаючи на все це, електронна книга може бути кращою за паперову книгу. Зрештою, це залежить від двох факторів: скільки книг прочитано на електронній читалці протягом її терміну служби? І скільки людей спільно використовують аналогову книгу? Щоб високі екологічні витрати на виробництво електронної книги окупилися з екологічної точки зору, на ній необхідно прочитати певну кількість книг. Це відбувається після 30-60 книг – залежно від товщини книги та залежно від екологічного показника. Якщо ви прочитаєте менше цієї кількості книг на електронній читалці, краще обрати паперову форму. Якщо ви перевищите цей показник, кожна інша книга на електронній читалці буде екологічно кращою за свою аналогову. Крім того, вирішальне значення має те, як використовуються об'єкти […]: Якщо припустити, що хтось купує книгу і не дозволяє нікому іншому її переглядати, то файл на електронній читалці приблизно в п'ять разів енергоефективніший, ніж книга. Однак ця перевага зникає, коли кілька людей спільно використовують книгу.

Отже, чи призводить заміна фізичних об'єктів цифровими технологіями до зменшення впливу на навколишнє середовище? Що ж, це залежить від обставин. Наприклад, якщо ви купите електронну книгу, чи прочитаєте ви 30–60 книг, перш ніж викинете її? Опитування Gallup показало, що у 2021 році 57% американців читали менше 5 книг на рік, а 15% читали від 6 до 10 книг. Це означає, що для понад двох третин населення США електронна книга мала б використовуватися протягом п'яти-десяти років, щоб бути більш екологічним вибором. Але скільки споживачів переходять на наступний, блискучий новий пристрій задовго до цього часу?

Варто також запитати, чи підтримуватиме компанія пристрій протягом того часу, який знадобиться, щоб він був менш шкідливим вибором. Наприкінці 2022 року список електронних книг, що зняті з виробництва у Вікіпедії містив сімдесят один пристрій. Згідно зі списком, середній термін служби, тобто від року випуску до кінця року, становив 1,5 роки — значно менше, ніж мінімальний п'ятирічний період використання, не кажучи вже про десятиліття! Скільки з цих електронних книг все ще працювали, але опинилися на сміттєзвалищі через припинення підтримки програмного забезпечення? Таке старіння обладнання є важливим фактором шкоди для навколишнього середовища, чи то у вигляді електронних відходів, чи то викидів вуглецю, пов'язаних з виробництвом пристрою. Як пишуть Ланге та Сантаріус: «є сумніви, чи всі електронні книги, що продаються, перш ніж вони зламаються або стануть технічно застарілими, використовуються в середньому настільки інтенсивно, щоб досягти загальної екологічної користі» (с. 31; переклад з німецької).

«Цунамі електронного сміття»

«Людина з електричних та електронних відходів» – це велетень заввишки сім метрів. Свою назву вона отримала від директиви 2003 року про відходи електричного та електронного обладнання (WEEE), яка встановлює цілі щодо збору, переробки та відновлення електронних відходів у ЄС,¹ статуя виготовлена ​​з 3,3 метричних тонн електровідходів, або середньої кількості електронних відходів, яку один мешканець Британії створює за життя.

Електронні відходи вважаються «потоком відходів у світі, що зростає найшвидше», причому у 2016 році було утворено 44,7 мільйона метричних тонн, що еквівалентно 4500 Ейфелевим вежам, що, якщо їх скласти разом, у 17 разів вище за гору Еверест. У 2018 році було повідомлено про приблизно 50 мільйонів метричних тонн електронних відходів, що спонукало ООН назвати це «цунамі електронних відходів, що розгортається по всьому світу». Цифри продовжують зростати: у 2021 році у світі було утворено приблизно 57 мільйонів метричних тонн електронних відходів. Менше 20 відсотків з них збирається та переробляється, і хоча вони становлять лише 2% сміття на звалищах, вони є причиною майже 70% токсичних відходів, які там перебувають.

Вплив електронних відходів на навколишнє середовище величезний. Компоненти електронного брухту, зокрема процесори, містять потенційно шкідливі матеріали, такі як свинець, кадмій, берилій або бромовані вогнезахисні речовини. Утилізація електронних відходів після закінчення терміну служби також може становити значний ризик для здоров'я працівників та їхніх громад. Збирачі сміття ризикують своїм здоров’ям заради викинутих дорогоцінних металів у ноутбуках і смартфонах «з додаванням свинцю, ртуті або інших токсичних речовин». Процес демонтажу та утилізації електронних відходів призвів до низки негативних наслідків для навколишнього середовища в країнах, що розвиваються. Рідкі та атмосферні викиди потрапляють у водойми, ґрунтові води, ґрунт і повітря, а отже, також у наземних і морських тварин, у сільськогосподарські культури, які споживають як тварини, так і люди, та у питну воду. Це забруднення є вирішальним аспектом шкоди цифрових технологій.

Погляд на програмне забезпечення

У чому причина всіх цих електронних відходів, і чому цифрові пристрої, які все ще працюють, опиняються на звалищах? Програмна інженерія відіграє важливу, але часто непомітну роль у формуванні наших моделей цифрового споживання. Виробники регулярно заохочують споживачів купувати нові пристрої, часто без потреби; насправді вони можуть навіть нав'язувати це через розробку програмного забезпечення. Через ліцензійні обмеження на використання програмного забезпечення та залежність від постачальників кінцеві користувачі мало що можуть з цим вдіяти. Коротше кажучи, це значною мірою економічні, а не технологічні причини, чому працездатне обладнання стає електронними відходами.

Блокування програмного забезпечення та запрограмоване застарівання призводять до непридатності обладнання для використання. Занедбане програмне забезпечення, випущене із закритою ліцензією, може в кращому випадку зробити користувачів вразливими до вірусів та іншого шкідливого програмного забезпечення, а в гіршому випадку просто перестати працювати без жодної альтернативи. Базова інфраструктура, на яку люди можуть покладатися для запуску програми, така як сервери ліцензій на програмне забезпечення, що використовуються для контролю доступу постачальниками програмного забезпечення, може вийти з ладу, іноді назавжди. Користувачі можуть не мати змоги продовжувати використовувати «застаріле» обладнання, навіть якби хотіли.

Надмірне розширення функцій та інші форми роздуття програмного забезпечення можуть зробити менш потужне обладнання застарілим, навіть якщо клієнти ніколи не просили про додаткові можливості або, можливо, хотіли б їх позбутися, якби мали таку можливість. Врахуйте наступне:

«Потужність обчислювальних систем подвоюється приблизно кожні два роки з 1970 року. Це означає, що функції обробляються вдвічі швидше, і тому для виконання тих самих функцій потрібно менше енергії. Подібне покращення ефективності не можна спостерігати в галузі програмного забезпечення. […] Наявність дедалі потужнішого обладнання призвела до того, що програмне забезпечення стає дедалі більш роздутим від версії до версії, так що потрібно більше ресурсів лише для мінімального або навіть нульового покращення функціональності». — Критерії надання нагороди «Blue Angel»: Ресурсо- та енергоефективні програмні продукти (с. 5)

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

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

Дані дослідження включають порівняння двох текстових процесорів: Текстовий процесор 1 визначено як програму з відкритим вихідним кодом, тоді як Текстовий процесор 2 визначено як пропрієтарне програмне забезпечення. Обидві комп'ютерні програми виконували однакову послідовність команд за допомогою стандартного сценарію використання (SUS), що відповідає «найбільш репрезентативному використанню відповідного програмного забезпечення протягом визначеного періоду часу» (с. 23). Ми повернемося до сценаріїв використання в інструкціях у ЧАСТИНІ III цього підручника. Наразі важливо зазначити величезну різницю у споживанні енергії. Запуск Текстового процесора 2 споживав у 4 рази більше енергії порівняно з Текстовим процесором 1 — знову ж таки, і це неможливо переоцінити, для виконання того самого завдання!

Якщо уважніше розглянути споживання енергії двома текстовими процесорами з часом, то також стає зрозуміло, як ці дві програми поводяться зовсім по-різному… і, можливо, всупереч очікуванням. Розглянемо графік нижче, на якому показано споживання енергії під час виконання послідовності команд сценарію використання. Приблизно на позначці 440 секунд скрипт вимагає від обох текстових процесорів збереження документа, а потім припиняє виклик подальших дій. Як бачите, текстовий процесор 1 переходить у режим очікування (як і можна було очікувати). Натомість текстовий процесор 2 продовжує працювати, споживаючи енергію, навіть після завершення скрипту.

Варто запитати, для чого потрібні додаткові дії від 440 до 600 секунд: чи необхідні дії текстового процесора 2 для функціональності програмного забезпечення? Чи збирає та передає текстовий процесор дані користувачів? Якщо так, то чи мають користувачі спосіб відмовитися від цих видів аналітики? Дійсно, автономія користувача, така як можливість вимкнення небажаного використання даних, може суттєво вплинути на енергетичний профіль програмного продукту. Інтелектуальний аналіз даних, відстеження третіх сторін, персоналізовані алгоритми максимізації залученості та реклама є значними факторами споживання енергії. Збір та аналіз даних користувачів і навчання алгоритмів на них вимагають обчислювальної потужності та інфраструктури.

Дослідники в ЄС оцінили екологічні витрати від відстеження та реклами, від якої користувачі не можуть відмовитися, що називається «небажаним використанням даних» у звіті за 2021 рік «Вуглецевий слід небажаного використання даних смартфонами: аналіз для ЄС». Вуглецевий слід цього смартфона, що відстежує, — від 3 до 8 мільйонів метричних тонн на рік лише в ЄС — «дорівнює вуглецевому сліду від 370 до 950 тисяч громадян ЄС» (у найгіршому випадку це приблизно річний слід міста, такого як Турин чи Лісабон). У звіті зазначається, що близько 60% європейських користувачів смартфонів повідомляють, що вони відмовилися б від відстеження та блокували б рекламу, коли це можливо. Це надзвичайно багато енергії, адже більшість користувачів цього взагалі не хочуть!

«Вірно якраз протилежне» — парадокс Джевонса

Підвищення ефективності програмного забезпечення саме по собі не обов'язково призводить до зменшення впливу на навколишнє середовище. Наприклад, «ефект відскоку» (також відомий як «ефект повернення») описує, як підвищення ефективності може призвести до змін у використанні, які зменшують або навіть зводять нанівець початкові здобутки.

Уявіть, що зміна програмного забезпечення призводить до покращення енергоефективності на 5%. Однак, через збільшення заощадження енергії, ви можете зрештою використовувати програмне забезпечення частіше, що призведе до меншого загального заощадження енергії. Припустимо, що через збільшення використання загального споживання енергії програмним забезпеченням падає лише на 1%. У цьому випадку ефект відскоку становить 80% ((5-1)/5): іншими словами, початкове підвищення ефективності зменшилося на 80%, практично зводячи нанівець будь-яке заощадження від покращень!

Якщо ефект відскоку перевищує 100%, що означає, що використовується більше енергії, ніж раніше, це називається парадоксом Джевонса або «зворотним вогнем». Ця концепція походить від англійського економіста Вільяма Стенлі Джевонса, який у 1865 році визнав, що технологічні вдосконалення у використанні вугілля фактично збільшили споживання вугілля в усіх галузях промисловості. Джевонс дійшов висновку, що:

«Це помилка — вважати, що ощадливе використання палива еквівалентне зменшенню його споживання. Правда полягає в протилежному». [виокремлено автором]

Практичне тлумачення цього парадоксу полягає в тому, що підвищення ефективності має поєднуватися з практикою заощадження, щоб мати значний ефект, інакше людина споживатиме більше, ніж раніше. У звіті ACM на початку цього розділу висловлюється аналогічна думка: «Ефективність, що забезпечується обчислювальною технікою, має поєднуватися зі скороченням попиту на енергію для зменшення викидів вуглецю в секторі ІКТ» (с. 1). Іншими словами, як розробка програмного забезпечення, ТАК І поведінка користувачів є вирішальними елементами, які слід враховувати в боротьбі зі шкодою для навколишнього середовища, спричиненою програмним забезпеченням.

Чи варте усе це зусиль?

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

Тут ми можемо врахувати кілька речей. Перший – це відкидання помилкового твердження «Не так погано, як», також відомої як «Апеляція до гірших проблем». Загальний аргумент такий: внесок програмного забезпечення у глобальні викиди CO₂ може бути не таким поганим, як в іншій галузі, і тому на ньому не варто зосереджуватися. Неправильність цього аргументу полягає в тому, що хоча інша галузь може бути гіршою, це не заперечує того факту, що програмна інженерія відповідальна за заподіяння серйозної шкоди навколишньому середовищу. Більше того, помилка «Не так погано, як» передбачає хибний вибір між вирішенням однієї проблеми або іншої, тоді як насправді екологічно чистий дизайн програмного забезпечення – це лише один елемент більшої складанки.

Не будьмо подібними до Білого Капелюха XKCD і не порівнюватимемо проблему з гіршими для виправдання бездіяльності!

По-друге, зосередження лише на вирішенні «найбільшої проблеми» не обов’язково є найефективнішою стратегією. Також важливо зважити ймовірність успіху під час вирішення проблеми, а також час і ресурси, необхідні для цього. Безкоштовне програмне забезпечення з відкритим початковим кодом, зосереджуючись на автономії та прозорості для користувачів, надає унікальні можливості для користувачів, спільнот та організацій безпосередньо вирішувати взаємопов’язані соціальні та екологічні проблеми. Вільне програмне забезпечення з відкритим кодом можна адаптувати, оновлювати та підтримувати з меншими витратами та без залежності від постачальників чи штучних обмежень.

По-третє, сподіваємося, що вже зрозуміло, що програмне забезпечення дійсно має значний вплив на споживання енергії та утворення відходів, що має наслідки для навколишнього середовища. Більше того, якщо розглядати це в масштабі, мінімальні зміни в дизайні програмного забезпечення можуть призвести до заощадження, порівняного з річним споживанням енергії цілими містами. Це твердження ґрунтується на прикладі продукт-інженера SAP Детлефа Томса, який наводить приблизні розрахунки (04:20–06:10) для переходу від скорочення витрачання ресурсів процесора на одну секунду, що еквівалентно заощадженню приблизно 10 ват-секунд, до економії 95 тисяч мегават-годин просто шляхом масштабування. Ця економія порівнянна з річним споживанням енергії понад 30 тисячами домогосподарств з двох осіб.

Як зазначає Детлеф Томс у відео: «Часто саме досить керований набір рішень призводить до значних відмінностей у споживанні енергії».

Зрештою, щоб робити заяви про відносну шкоду, необхідно спочатку мати оцінки фактичного впливу. Оскільки дослідження в галузі споживання енергії та ресурсів програмним забезпеченням ще досить нові, ми часто не маємо даних для того, щоб робити заяви на основі даних. За допомогою цього підручника та екомаркування Blue Angel як орієнтира, KDE сподівається допомогти змінити це.

Зміна нашого програмного забезпечення може здатися невеликим жестом у вирішенні такої складної проблеми, як зміна клімату. Також очевидно, що простої зміни наших індивідуальних моделей споживання може бути недостатньо (гірше те, що докази свідчать про те, що основні учасники глобальних викидів парникових газів, такі як ExxonMobile, прийняли риторику індивідуальної відповідальності споживачів, щоб відвернутися від власної ролі в кризі). Це правда: майбутнє з нульовими викидами вимагатиме фундаментальних змін у тому, як ми живемо, і цю відповідальність не можна керувати на індивідуальному рівні. Але подумайте, що колись зазначила антрополог Маргарет Мід:

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

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

Зауваження щодо джерел

Деякі матеріали у цьому розділі безпосередньо засновано на тексті з двох статей Вікіпедії: (i) “Директива про відходи електричного та електронного обладнання” та (ii) “Електронні відходи”. Обидва тексти опубліковані за дотримання умов ліцензування Creative Commons Attribution-Share-Alike License 3.0.

Частина II: Екосертифікація програмного забезпечення для робочих станцій

Що спільного між будівельними виробами, туалетним папером та програмним забезпеченням?

Кожен із них може бути екосертифікований екологічним знаком «Blue Angel» – офіційним екологічним знаком уряду Німеччини!

Екомаркування «Blue Angel» присуджується низці продуктів і послуг, від паперової продукції та будівельних матеріалів до принтерів, і воно засвідчує, що продукт відповідає переліку суворих вимог щодо екологічності протягом усього життєвого циклу продукту. У 2020 році Німецьке агентство з охорони навколишнього середовища розширило критерії нагородження, включивши до них програмні продукти, що стало першою екологічною сертифікацією, яка пов’язує прозорість та автономію користувача зі сталим розвитком.

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

У цьому розділі наведено широкий огляд програми «Blue Angel» та абетку критеріїв нагородження для програмного забезпечення для настільних комп’ютерів. Також показано, як виконання критеріїв нагородження може зменшити шкоду для навколишнього середовища. Зокрема, ми детально розглянемо вимоги до автономії користувача, що випливають з критеріїв нагородження «Blue Angel», до яких ми повернемося в ЧАСТИНІ III. Але спочатку короткий вступ до програми «Blue Angel» та ініціативи KDE Eco.

«Blue Angel» для програмного забезпечення для робочих станцій

Запроваджений у 1978 році, «Blue Angel» – це перше у світі екологічне маркування та офіційне екологічне маркування, присвоєне урядом Німеччини. Маркування адмініструється Федеральним міністерством навколишнього середовища, охорони природи, ядерної безпеки та захисту прав споживачів Німеччини (нім.: Bundesministerium für Umwelt, Naturschutz, nukleare Sicherheit und Verbraucherschutz або BMUV). Екомаркування «Blue Angel» також є членом Глобальної мережі екологічного маркування (GEN), міжнародної мережі екологічних маркувань типу I, яка на момент написання статті налічує 37 членів майже з 60 країн.

«Blue Angel» не була першим екомаркуванням Типу I для програмного забезпечення — Гонконзька зелена рада, яка також є членом Глобальної мережі екомаркування, опублікувала критерії для зеленого ІТ-програмного забезпечення у 2010 році. Але критерії екомаркування «Blue Angel» є першими, які визначають процес вимірювання енергоспоживання програмним забезпеченням та вказують способи, якими незалежність користувача зменшує шкоду для навколишнього середовища.

У вас може виникнути питання: Що таке екологічне маркування типу I? Для цього екологічного маркування враховується весь життєвий цикл продукту. Крім того, відповідність критеріям нагородження оцінюється третьою стороною. (Відповідність екологічному маркуванню типу II, для порівняння, є самодекларованою та не потребує жодного стороннього аудиту.)

Екологічне маркування «Blue Angel» було надано близько 100 групам товарів та послуг у різних секторах, включаючи паперову та будівельну продукцію, меблі, одяг, мийні та засоби для миття, послуги з прибирання, побутову хімію, упаковку, транспортні засоби, енергетику та опалення, а також побутові електроприлади. Станом на 2022 рік, завдяки екологічній сертифікації програми для читання файлів PDF та універсального засобу читання документів Okular від KDE, цей список також включає програмне забезпечення для робочих станцій.

Критерії сертифікації прозоро розробляються Німецькою агенцією з охорони навколишнього середовища. Процес включає Журі екологічного маркування, орган, що складається з постачальників, а також організацій громадянського суспільства та дослідницьких установ. Незалежний сторонній аудитор RAL gGmbH оцінює відповідність критеріям та присуджує знак. Важливо, що «Blue Angel» не засвідчує, що продукт повністю нешкідливий. Натомість, сертифіковані продукти представляють собою «менше зло» щодо шкоди для навколишнього середовища – це можна підсумувати девізом «якомога менше, стільки, скільки необхідно». Замість порівняння різних продуктів, екомаркування «Blue Angel» вказує на те, що продукт відповідає переліку вимог для певної категорії.

Абетка критеріїв надання

Критерії надання нагороди «Blue Angel» для [«Ресурсо- та енергоефективних програмних продуктів»] (https://www.blauer-engel.de/en/products/electric-devices/resources-and-energy-efficient-software-products) були опубліковані у січні 2020 року. Існує дві основні цілі «Blue Angel» для програмного забезпечення: (i) нагороджувати програмне забезпечення з нижчими вимогами до продуктивності, щоб «можливий довший термін служби […] апаратного забезпечення»; та (ii) відзначати продукти, які «виділяються завдяки високому рівню прозорості та надають користувачам більшу свободу у використанні програмного забезпечення» (с. 6). Для досягнення цієї мети існують три основні категорії, які тут називаються абеткою критеріїв нагородження: (A) Ресурсо- та енергоефективність, (B) Потенційний термін служби апаратного забезпечення, (C) Автономія користувача.

Критерії категорії (А) вимагають вимірювання та звітності про споживання енергії програмним продуктом, а також зазначають, що споживання енергії програмою не може збільшитися більш ніж на 10% з моменту її сертифікації. Дані про споживання енергії вимірюються за допомогою зовнішнього вимірювача потужності та враховують іншу інформацію про продуктивність обладнання, таку як використання процесора або мережевий обмін даними, під час роботи програмного забезпечення у репрезентативний спосіб. Ми повернемося до цього у ЧАСТИНІ III.

Критерії категорії (B) гарантують, що програмне забезпечення має достатньо низькі вимоги до продуктивності для роботи на старішому, менш потужному обладнанні віком щонайменше п'ять років. Відповідність передбачає декларацію зворотної сумісності з детальною інформацією про обладнання, на якому працює програмне забезпечення, та необхідний програмний стек.

Нарешті, критерії категорії (C) гарантують, що користувачі мають вплив на споживання енергії та використання свого програмного забезпечення зі заощадженням енергії. Існує вісім категорій критеріїв автономності.

1. Формати даних – Сумісність, що надає користувачам вибір

   Формати даних не повинні використовуватися постачальниками для прив’язки користувачів до використання певної комп’ютерної програми, а також не повинні нав'язувати обтяжливі витрати на перехід. Широко сумісні формати даних запобігають тому, щоб користувачі застрягли на програмі, яка споживає багато енергії, коли ефективніша програма може досягти тих самих результатів з меншими вимогами до обладнання. Користувачі повинні мати можливість легко змінювати програми і при цьому отримувати доступ до всіх своїх даних.

2. Прозорість – Усування залежності користувача для тривалого користування

   Прозорість програмного коду та інтерфейсів додатків означає усунення будь-яких залежностей від конкретної компанії чи організації. Це також означає усунення обмежень на короткострокове та довгострокове використання програмного забезпечення, а отже, і апаратного забезпечення. Коли розробники вирішують припинити підтримку свого програмного забезпечення, вони повинні продовжувати надавати оновлення безпеки (див. нижче) або робити початковий код загальнодоступним, щоб треті сторони могли продовжувати надавати підтримку програмного забезпечення. Крім того, розширення функціональності програмного забезпечення не повинно обмежуватися обмежувальними або недокументованими програмними інтерфейсами (API).

3. Неперервна підтримка – Оновлення захисту для запобігання появі електронних відходів

   Залежність від постачальників щодо необхідних оновлень не повинна призводити до занедбаних програмних продуктів, які неможливо використовувати без серйозних недоліків для користувачів, таких як вразливості до шкідливого програмного забезпечення. Оновлення безпеки повинні надаватися протягом п'яти років після припинення розробки програмного забезпечення. Крім того, оновлення безпеки повинні бути відокремлені від оновлень функцій, щоб користувачі не були змушені використовувати небажані функції, наприклад, функціональне перевантаження та інші форми надмірного використання програмного забезпечення. Таке покинуте програмне забезпечення та роздуття програмного забезпечення роблять обладнання непридатним для використання та створюють непотрібні електронні відходи.

4. Можливість вилучення – Вилучення небажаного програмного забезпечення для збільшення ефективності

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

5. Можливість автономної роботи — щоб уникнути залежностей та зменшити споживання енергії

   Використання програмного забезпечення має бути можливим без встановлення з'єднання з інтернетом, хіба що, звичайно, з'єднання з мережею необхідне для передбачуваної функціональності програмного забезпечення. Сервери ліцензій та інші форми контролю доступу обмежують використання програми способами, які є непотрібними для передбачуваної функціональності програмного забезпечення. Коли сервер виходить з ладу або відбувається збій в Інтернеті, такий контроль доступу запобігає використанню програмного забезпечення, [можливо, назавжди] (https://en.wikipedia.org/wiki/Abandonware#Implications). Крім того, такі залежності вимагають мережевого трафіку і, таким чином, споживають енергію понад ту, що потрібна для передбачуваного призначення програмного забезпечення.

6. Модулярність – Для зменшення вимог до пам'яті та енергоспоживання

   Users should be able to install only what they need. Non-essential functions increase memory and energy demands, making the software less efficient and perhaps unable to run on older hardware. People should have the ability to limit the range of software functions to those that they either want or require.

7. Freedom From Advertising — Opting-Out To Reduce Energy Consumption

   Unwanted data use in the European Union alone is roughly equivalent to the annual energy consumption of a city like Lisbon or Turin; see PART I. Allowing users to opt out of ads reduces energy and resource demands on end-user devices and on the servers running the ads. Opting out also decreases data volume transmitted and thus reduces the energy consumption for network traffic.

8. Documentation — To Support Resource-Conserving, Continuous Use Of Software … And Therefore Hardware

   Documentation is a prerequisite for the long-term viability of a software product. Documentation must also demonstrate the software’s capacity for conserving resources. By documenting the criteria listed above, users can continue using software—and thus, hardware—in a sustainable way, while developers can maintain the software without dependencies or restrictions imposed by vendors.

Software design that complies with the award criteria is less likely to suffer from various forms of inefficiencies. This in turn can help mitigate the problem of e-waste: with software that doesn’t drive early hardware obsolescence, fewer devices need to be produced and shipped, which means fewer valuable metals that need to be mined and processed, which in turn results in a reduction of water and soil pollution. By ensuring user autonomy, developers can ensure that their software reduces environmental harm in more ways than one—whether by keeping devices in use for longer, or by reducing the software’s use of energy and resources while in use.

With its focus on transparency in resource and energy-efficiency, hardware operating life, and user autonomy, the Blue Angel award criteria for software provides a comprehensive framework to begin a discussion around software sustainability. In FOSS communities, we often take user autonomy and transparency and their benefits for granted. Although being Free & Open Source Software is not a requirement to obtain the Blue Angel ecolabel, it is in this category that FOSS really shines. In so many ways, we are already at the forefront of sustainable software design!

Okular, The First Eco-Certified Computer Program

In 2022 Okular, KDE’s popular multi-platform PDF reader and universal document viewer, was the first software product to be officially recognized for sustainable software design as reflected in the Blue Angel award criteria. Okular is also the first eco-certified computer program within the Global Ecolabelling Network.

Okular is just one software product maintained by KDE, a world-wide community of software engineers, artists, writers, translators, and creators who are committed to Free Software development. KDE maintains numerous FOSS products, including the Plasma desktop environment; the design app for painters and graphic artists, Krita; the GCompris suite of educational activities for children; Kdenlive, a professional video-editing software product; and of course Okular, a document viewer for PDFs, comics, scientific and academic papers, and technical drawings.

With KDE’s long-standing mission and guiding vision since its founding in 1996, as well as the talent and capabilities of its community members, KDE is a pioneer in championing sustainable software. In 2021 KDE started KDE Eco, a project with the goal of putting KDE and Free Software at the forefront of sustainable software design. Sustainability is not new for Free & Open Source Software (FOSS)—the four freedoms have always made Free Software sustainable software. But now, the two pillars of FOSS—transparency and user autonomy—have wider recognition for their impacts on sustainability, and were incorporated into the sustainability criteria set by the German Environment Agency through the Blue Angel ecolabel.

With the first ever eco-certified software product, the KDE community celebrated the achievement together with the wider Free Software community, as well as with the computer science department at Umwelt Campus Birkenfeld, where researchers measured the resource and energy-consumption of Okular and other KDE software.

Критерії нагородження «Блакитний ангел» точно збігаються цінностями KDE та ширшого руху FOSS. Усі ці критерії точно відповідають цінностям KDE та цінностям ширшого руху FOSS. У межах вільного програмного забезпечення із відкритим кодом гарантовано прозорість та контроль з боку користувачів, а не продавців або надавачів послуг із супроводу програмного забезпечення. Це надає змогу користувачам визначати потрібні їм параметри програмного забезпечення та, чим часто нехтують, параметри обладнання. Наприклад, користувачі можуть знизити енергоспоживання програм без втрати функціональних можливостей, встановивши лише потрібні їм компоненти, не більше і не менше; та уникнути реклами та аналізу даних, які запускають непотрібні фонові процеси, споживаючи зайві ресурси. Що стосується розробників FOSS, то вони, типово, продовжують супровід обладнання, яке промислові гіганти вважають застарілим, надаючи користувачам сучасне і безпечне програмне забезпечення для пристроїв, які за інших умов було б утилізовано як застарілі, і які б просто вирушили на смітник. Якщо коротко, наслідком свободи і прозорості для користувача, які гарантовано ліцензуванням вільного програмного забезпечення, є те, що користувач і спільноти можуть впливати на фактори, які визначають споживання ресурсів їхнім програмним забезпеченням!

Released under the GPLv2+ license, Okular is FOSS and therefore already fulfilling many of the user autonomy criteria necessary to obtain the Blue Angel seal of approval. Further work was carried out to make Okular fully compliant with the award criteria by documenting user autonomy features, providing transparency in energy and resource consumption, and supporting the potential extension of the hardware operating life of devices.

Okular lets you check digital signatures and sign documents yourself, as well as include annotated text and comments directly embedded into the document. Okular works on Linux, Windows, Android, and Plasma Mobile, and it is available to download for all GNU/Linux distributions, as a standalone package from Flathub and the Snap Store, through the KDE F-Droid release repository for Android, as well as from the Microsoft Store. The source code is also readily available at Okular’s GitLab repository for all to use, study, share, improve, and most of all, enjoy.

KDE і спільнота вільного програмного забезпечення щиро вдячні розробникам Okular за створення дружнього до середовища програмного забезпечення для усіх нас!

In PART III of this handbook, we will look at the steps you need to complete to join us in having your Free Software project also recognized for its sustainable software design. First, though, what exactly are the benefits of obtaining the Blue Angel?

Benefits Of Blue Angel

Steffi Lemke, Federal Minister for the Environment, Nature Conservation, Nuclear Safety and Consumer Protection (BMUV), has said this about the reputation of the Blue Angel:

An increasing number of people focus on durability and environmental friendliness when purchasing products. This is precisely what the Blue Angel stands for. The ecolabel has been a guarantee of high standards for the protection for our environment and health for 40 years in an independent and credible way.

Indeed, in their 40^th anniversary info-booklet “Blue Angel – 40 years. Good for me. Good for the environment”, the German Environment Agency (UBA) explored the history, present, and future of the ecolabel. In the booklet, they identify some of the general criteria they consider when eco-certifying a product, such as:

• reduced emissions of harmful substances in the ground, air, water and indoors;
• sustainable production of resources;
• longevity, ability to repair and recycle the product; and
• efficient use, e.g. products which save energy.

As you reach the end of this section, we hope it is clear how compliance with the Blue Angel award criteria for desktop software promotes the above environmental benefits, among others.

Environmental labels can be an instrument to move markets in the direction of sustainable products. As the Blue Angel website states: “The aim of the environmental label is to provide private customers, large institutional consumers and public institutions with reliable guidance for environmentally conscious purchasing.”

So what does the market say?

A survey from the info-booklet found that 92% of Germans recognize the ecolabel, and for 37% the label influences their purchasing choices. The ecolabel is recognizable outside of Germany, too! Up to 15% of Blue Angel recipients are outside of Germany. One reason for this is that unlike some other ecolabels, the Blue Angel puts no requirements on where a product can be marketed. Moreover, the Blue Angel seal is considered a mark of high quality internationally, and the award criteria are viewed as an indicator of direction of the EU market—and they are even sometimes used as a guideline for optimizing products.

Receiving the Blue Angel seal can raise your product’s profile not only among individuals, but also among large organizations. Green Public Procurement (GPP) initiatives, which “seek to promote the public procurement of goods, services, and works with a reduced environmental impact throughout their life-cycle” (European Commission), influence purchasing choices both in the public and private sector. Eco-certifying your software product with the Blue Angel demonstrates a commitment to long-term digital sustainability, and it gives your product visibility both in Germany and abroad.

Зауваження щодо джерел

Some material in this section is based directly on text from two Wikipedia articles: (i) “Blue Angel (certification)” and (ii) “Software bloat”. Both texts are released under the Creative Commons Attribution-Share-Alike License 3.0. Some material in this section is also based directly on the KDE Eco blog post “First Ever Eco-Certified Computer Program: KDE’s Popular PDF Reader Okular”, which is released under the Creative Commons Attribution-ShareAlike 4.0 International License.

Частина III: Виконання критерії нагородження Blue Angel

The three main categories of the Blue Angel award criteria for desktop software are:

• (A) Resource & Energy Efficiency
• (B) Potential Hardware Operating Life
• (C) User Autonomy

In this section we’ll provide a hands-on guide to fulfilling each set of criteria. There are numerous benefits of meeting the basic award criteria. By making the energy consumption of your software transparent and complying with the hardware operating life and user autonomy criteria, you get the benefits of:

• Eco-Certification: Apply for the Blue Angel ecolabel to demonstrate to users, companies, and governmental organizations that your software is designed sustainably.
• Data-Driven Development: Locate inefficiencies in terms of energy and hardware consumption, and make data-driven decisions for your software development.
• Sustainable Design: For the long-term sustainable use of software, and thus hardware, take the user autonomy criteria into consideration when planning your software design.
• End-User Information: Highlight to your users the ways your software is already sustainably designed by using the Blue Angel criteria as a benchmark.

(A) How To Measure Your Software

The laboratory setup consists of a power meter, a computer to aggregate and evaluate the power meter output, and a desktop computer for the system under test where user behavior is emulated. The setup described here follows the specifications from the “Blue Angel Basic Award Criteria for Resource and Energy-Efficient Software Products”.

Terminology comes in part from Kern et al. (2018): “Sustainable software products — Towards assessment criteria for resource and energy efficiency”.

See also the following resources from the Umwelt Campus Birkenfeld:

• Seiwert & Zaczyk (2021): “Projektbericht: Ressourceneffiziente Softwaresysteme am Beispiel von KDE-Software” (німецькою)
• Mai (2021): “Vergleichende Analyse und Bewertung von Betriebssystemen hinsichtlich ihrer Energieeffizienz” (німецькою)
• “Підручник з OSCAR” (німецькою)

Огляд параметрів лабораторії

The laboratory setup requires 1 power meter and at least 2 computers:

• Вимірювання потужності

  One of the devices recommended by the Blue Angel is the Gude Expert Power Control 1202 Series (manual). It provides outlets for powering the computer and measures the current during operation. The device can be controlled and read via cabled Ethernet. There is a web-based user interface, a REST API, and the device supports various protocols such as SNMP or syslog.

• Computer 1: Data Aggregator & Evaluator

  The computer will be used for collecting and evaluating results from the power meter.

  A Python script to read out the data from the Gude Expert Power Control 1202 Series is available at the FEEP repository.

  It is recommended to monitor progress live with the second computer in order to ensure everything is proceeding smoothly. This can be done with KDE’s Labplot, for instance; read more here.

  Other power meters may require non-Free software, e.g., Janitza’s GridVis Power Grid Monitoring Software.

• Computer 2: System Under Test

  The reference system is the hardware used to measure the energy consumption of the “system under test”, or SUT. The SUT includes the operating system and software installed for (i) testing the software product, (ii) emulating the standard usage scenario² and (iii) collecting the hardware performance results.

Note the following:

• For GNU/Linux systems, the Blue Angel criteria (Section 1.1) require one of several Fujitsu computers as the reference system.
• For emulating activity in the standard usage scenario, Free Software task automation tools such as xdotool, KDE Eco Tester (in progress), or Actiona (GPLv3) can be used.
• For collecting hardware performance data (e.g., processor and RAM utilization, hard disk activity, network traffic), the Free Software tool Collectl (GPLv2/Artistic License) is available.
• It’s also possible to repurpose cheap switchable power plugs as measurement devices; see Section “Alternative: Gosund SP111 Setup” for set up instructions.

System Under Test (SUT)

For instance, the Fujitsu Esprimo P920 Desktop-PC proGreen selection (Intel Core i5-4570 3,6GHz, 4GB RAM, 500GB HDD) is one of the recommended reference systems; see Appendix D in the award criteria for other recommended Fujitsu systems.

On the reference system you need to set up the SUT, i.e., the system on which you will test the software. The SUT must reduce unrelated energy consumption and have a standardized configuration. Recommended is the following:

• Overwrite the entire hard drive of the machine with a standardized OS.
• Deactivate all possible background processes (automatic updates, backups, indexing, etc.).
• Install the necessary software, i.e., the application to be measured as well as the user emulation (e.g., xdotool) and hardware performance data (e.g., Collectl) software.
• When running the usage scenario scripts, the cache should be cleared between runs and any new files deleted before starting the next measurement.

Preparing The Standard Usage Scenario (SUS)

Preparing the SUS requires the following:

• Identifying tasks users typically carry out when using the application under consideration.
• Identifying functionalities which require high energy demand or high resource utilization.
• Based on the above, scheduling a flow chart of individual actions and emulating these actions with a task automation tool.
• Scheduling a wait-period of 60 seconds before starting the measurement is recommended.
• Running the SUS for at least 5 minutes.

An automation tool is needed to run the usage scenarios so as not to require human intervention. In this way the script can be run repeatedly in a well-defined manner to provide accurate measurements.

Example tasks and functions tested in the SUS for KDE’s email client KMail include searching for an email, writing a reply or forwarding the email, saving an attachment, deleting a folder in the mail client, etc. See the Actiona scripts used to test Krita and Okular for further examples.

Important: If the emulation tool uses pixel coordinates to store the position of the automated clicks (e.g., Actiona) and, moreover, the screen resolution of the computer used in preparation differs from that of the laboratory computer, all pixel coordinates will have to be reset for the laboratory environment.

Додаткові інструменти імітації

Beyond xdotool, KDE Eco Tester (in progress), or Actiona, there are other candidates for tools which might meet the requirements. See a list from KDE Contributor David Hurka in the presentation “Visual Workflow Automation Tools”. Most of the tools use X11-specific features, and thus do not work on Wayland systems. There are a few possible approaches here:

• Selenium Webdriver using AT-SPI (currently in testing for Season of KDE 2023)
• The XDG RemoteDesktop portal
• Various Wayland protocols (support varies between compositors):
  • https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-virtual-pointer-unstable-v1.xml
  • https://api.kde.org/frameworks/kwayland/html/classKWayland_1_1Client_1_1FakeInput.html
• libinput user devices

Measurement Process

The measurement process is defined in Appendix A of the Basic Award Criteria. It requires recording and logging energy data and performance indicators with a granularity of 1-second so that they can be processed and average values can be calculated.

Some general comments:

• Times between the PM and DAE must be synchronized.
• When using Collectl to collect performance load, ensure it is running in the console of the SUT; also, check that the required CSV file is correctly generated before testing.
• Since each run of the usage scenarios results in changes to the standard operating system, clearing the cache between runs is recommended.
• All runs (Baseline, Idle Mode, Standard Usage Scenario) must be for the same length of time, based on the time needed to run the usage scenario script.
• On the DAE you may want to confirm that the desired power outlet is read out correctly before and/or during testing (e.g., with a live graph using LabPlot).

During the energy measurements, Collectl is used to record a set of performance indicators: processor utilisation, RAM utilisation, hard disk activity, and network traffic. Use the following command to obtain this hardware performance data:

$ collectl -s cdmn -i1 -P --sep 59 -f ~/<FILENAME>.csv

Параметри є такими:

• -s cdmn

  collect CPU, Disk, memory, and network data

• -i1

  sampling interval of 1 second

• -P

  output in plot format (separated data which consists of a header with one line per sampling interval)

• --sep 59

  semicolon separator

• -f </PATH/TO/FILE>.csv

  save file at specified path

Measuring Baseline, Idle Mode, And Standard Usage Scenarios

• Baseline Scenario: Operating System (OS)

  To establish the baseline, a scenario is measured in which the OS is running but no actions are taken.

• Idle Mode Scenario: OS + Application While Idle

  To establish the energy consumption and hardware performance data of the application while idle, a scenario is measured in which the application under consideration is opened but no action is taken.

  Important: the baseline and idle mode must be run for the same time needed to carry out the standard usage scenario. Since the power consumption for the baseline and idle scenario is relatively uniform, 10 repetitions for each is considered sufficient to obtain a representative sample (Seiwert & Zaczyk 2021).

• Standard Usage Scenario: OS + Application In Use

  To measure the energy consumption and hardware performance data of the application in use, the standard usage scenario should be run; see SUS preparation notes above. The measurement of the standard usage scenario should be repeated 30 times, which will take several hours to complete. The higher number of repetitions is necessary to obtain a representative sample as the energy consumption and performance data may vary across measurements.

Monitoring Output With Labplot

You can use KDE’s LabPlot to monitor the output live as data is coming in. To do this:

• Redirect the power meter output to a CSV file.
• In LabPlot, import the CSV file by selecting File > Add New > Live Data Source…
• Under “Filter”, select the Custom option. Under “Data Format”, define the separator value used (e.g., comma, semi-colon, space).
• You can check that the output is correct under the “Preview” tab.
• If everything looks good, click OK.
• Finally, right-click on the data frame window and selecting Plot Data > xy-Curve.

Analysis Of The Results With OSCAR

Once you have results, the Umwelt Campus Birkenfeld provides a useful tool for generating reports called OSCAR (Open source Software Consumption Analysis in R):

• Source Code
• Running instance

See also the OSCAR Manual with detailed instructions, including additional screenshots on how to use OSCAR.

Файли CSV

Analysis with OSCAR requires uploading the following files to the OSCAR website:

• (i) a log file of actions taken,
• (ii) the energy consumption data, and
• (iii) the hardware performance data.

All files should be CSV files. Some preprocessing of the raw data may be necessary (e.g., performance data measured by Collectl; see below).

Important: OSCAR is very particular about data frame formats, including column names and cell values. The tables here provide examples which are confirmed to work. If you are having issues generating a report from your CSV files, make sure CSV files are as similar as possible to those shown here.

If you just want to test OSCAR, you can download data for Okular in this ZIP file. The data are confirmed to successfully generate a report using OSCAR v0.190404. The report which was generated can also be downloaded at the FEEP repository.

Log File Of Actions

The log file of actions should have the following format. Note the columns are separated by a semi-colon. Also, columns have no names (i.e., there is no header in the CSV file). Note that the start and end of each iteration must be labelled with ‘startTestrun’ and ‘stopTestrun’ in the second column, whereas the actions can be listed with any name.

An example log file of actions for measuring KDE’s text and code editor Kate. The (i) date and time as well as (ii) start and stop times and (iii) actions are listed in three columns.

Дані щодо споживання енергії

The energy consumption data has the following format: the first column is the row number, the second column is the date and time in one-second increments, and the third column is the measurement output in Watts. Note that the following is confirmed to work with OSCAR: (i) the second and third column names as written below (i.e., “Zeit” and “Wert 1-avg[W]”), (ii) the date-time as a character string with the date and time separated by a comma, and (iii) no string delimiter used in the CSV file.

When using the Gude Power Meter with the Python script available at the FEEP repository, the timestamp will be recorded in nanoseconds in Epoch time. For instance, below is an example of the raw output for 7 rows from the Gude Power Meter output using the Python script. The first column shows the timestamp. The second column is the readout from the power meter in Watts.

The raw data can be preprocessed in R: Nanoseconds in Epoch time can be converted to date-time with the command as.POSIXct(<NANOSECONDS>/1000000, origin = '1970-01-01', tz = 'Europe/Berlin'). For example, the nanoseconds in row 1 from the raw output is “2022-08-27 16:52:03 CEST” after conversion.

For use with OSCAR, this date-time should then be converted to a character string with the date as DD.MM.YY followed by a comma. All of this can be achieved with one command (this operation can be vectorized over the entire column in the data frame); replace the YYYY-MM-DD date with the date of your measurements:

stringr::str_replace(as.character(as.POSIXct(1661611923019071/1000000, origin = '1970-01-01', tz = 'Europe/Berlin')), '2022-08-27', '27.08.22,')

The output in Watts should be averaged per second. The same data above is shown below after processing with R; note the 7 values above are averaged per second, resulting in two rows.

To save the CSV file with a semi-colon separator, the first column with row names starting at the number 1, and no string delimiter, use the following R command:

write.csv2(<DATAFRAME>, file = <PATH/TO/FILE.csv>, row.names = TRUE, quote = FALSE)

The result should look something like the following:

Performance Data (Raw)

When using Collectl for hardware performance data, it is necessary to do the following before uploading the data to OSCAR.³

• Remove all information above the header row.
• Remove all # characters from the file.
• In the first column, no separator value should come between the data-time (otherwise, the date and time will be interpreted as two separate columns).
• The date should also have a character inserted between YYYYMMDD, e.g., MM.DD.YYYY as above. Whatever character is used must be specified in OSCAR.
• Column names can be anything you want as they will be specified within OSCAR.
• The file must be saved in CSV format.

Moreover, the hardware performance output from Collectl includes many columns that are not necessary for analysis. The only measurements that need to be specified are the following columns:

• [CPU]Totl = Processor
• [MEM]Used = Main memory - used kilobytes
• [NET]RxKBTot = Network - Kilobytes received/s
• [NET]TxKBTot = Network - Kilobytes transmitted/s
• [DSK]ReadKBTot = Disk - Kilobytes read/s
• [DSK]WriteKBTot = Disk - kilobytes written/s.

Below is an example of the preprocessed results from Collectl measuring the performance data for Kate. The timestamp increases in one-second increments.

Uploading Data

Once the above CSV files are ready, you can run the analysis using OSCAR, which will generate a summary report you can use either for eco-certification or for your own data-driven purposes. In the OSCAR interface, note the following:

• The interface language is currently German only; see below for translations.
• The duration of the measurements in seconds must be specified.
• A semicolon separator is used.
• The correct formatting of the time stamp must be specified for each of the uploaded files, e.g.,%Y-%m-%d %H:%M:%OS.

Step 1: Obtain Measurement Data

The landing page of the website (below) states that the first step is obtaining measurement data (German: Erfassung Messdaten). If you are at this point in the process, you should have already measured your software and prepared the CSV files.

All examples here are based on the Okular data in this ZIP file.

Step 2: Upload Measurement Data

Once you have the CSV files for the baseline, idle mode, and standard usage scenario measurements ready, click on (2) Upload Messdaten > Upload.

The measurement data (German: Messdaten) include the log file of actions (German: Aktionen), energy consumption (German: Elektrische Leistung), and hardware performance data (German: Hardware-Auslastung).

• Under Messungen, upload either the idle mode or standard usage scenario measurement data.

  For Art der Messung (‘Type of Measurement’) in the lower right of the UX, select Leerlauf (‘Idle Mode’) or Nutzungsszenario (‘Usage Scenario’) depending on which report you wish to generate.

• Under Baselines upload the baseline measurement data.

• Indicate the duration of the measurement scenarios in seconds (German: Dauer der Einzelmessungen (s)).

Note that the baseline measurements are always uploaded along with either the idle mode or standard usage scenario measurements.

See below for what a completed upload for the Nutzungsszenario looks like.

Timestamps    Once the data has been uploaded, you will need to tell OSCAR how to read the data.

Let’s start with the timestamp format (German: Formatierung Zeitstempel). This is one aspect of the process which can cause problems if not done correctly. This is done under (2) Upload Messdaten > Formatierung Zeitstempel.

Consider the Okular data:

• For the log file of actions, the datetime is encoded as YYYY-MM-DD HH:MM:SS (e.g., "2022-10-04 12:32:43.656" in “okularActions.csv”).

  In OSCAR, this is specified as "%Y-%m-%d %H:%M:%OS" (see screenshot below). OSCAR will take care of the fractional seconds.

• For the energy consumption data, the datetime is encoded as DD.MM.YY, HH:MM:SS (e.g., "04.10.22, 12:32:43" in “okular_baseline_eletrLeistung.csv”). Note the period in the date and the comma seperating date from time, as well as only having two digits for the year.

  In OSCAR this is specified as "%d.%m.%y, %H:%M:%OS" (see screenshot below), in which the lowercase “%y” indicates a year with two digits.

• For the hardware performance data, the datetime is encoded as DD.MM.YYYY HH:MM:SS (e.g., "04.10.2022 12:31:43" in “baseline_hardware_formatiert.csv”). Note the period in the date and the four-digit year.

  In OSCAR, this is specified as: "%d.%m.%Y %H:%M:%OS" (see screenshot below), in which the uppercase “%Y” indicates a year with four digits.

Measurement Data    After the timestamps have been correctly specified, let’s explore the format of the measurement data (German: Formatierung Messdaten) in OSCAR.

First, take a look at the log file of actions (German: Aktionen). This is done under (2) Upload Messdaten > Formatierung Messdaten > Aktionen.

Here you need to indicate for the uploaded CSV file the separator (German: Trennzeichen), the string delimiter (German: Textqualifizierer), and the decimal separator (German: Dezimaltrennzeichen).

For the Okular data, this is defined as a semi-colon separator, double quotation string delimiter, and a period or full-stop decimal separator (see screenshot below).

Additionally, you will need to specify the following:

• whether the first line contains headings (German: Erste Zeile enthält Überschriften);
• the number of lines to skip (German: Anzahl zu überspringender Zeilen); and
• the character encoding (German: Zeichensatz (Encoding)).

For the Okular data, this is defined as follows in the following screenshot: “first line contains headings” is unchecked, 0 lines are skipped, and character encoding is utf-8.

When everything is defined correctly, a preview of the spreadsheet will be shown.

Second, take a look at the energy consumption measurements (German: Elektrische Leistung). This is done under (2) Upload Messdaten > Formatierung Messdaten > Elektrische Leistung.

The required input is the same as for the log file of actions, seen in the following screenshot.

For the Okular data here, this is a semi-colon separator, double quotation string delimiter, and character encoding utf-8. However, now a comma is specified for the decimal separator and a checkmark indicates that the first line contains headings. Finally, the 1st line is skipped.

When everything is defined correctly, a preview of the spreadsheet will be shown.

Finally, take a look at the hardware performance data (German: Hardware-Auslastung). This is done under (2) Upload Messdaten > Formatierung Messdaten > Hardware-Auslastung.

The required input is the same. The input in this example is a semi-colon separator, a double quotation string delimiter, a period (a.k.a. full stop) decimal separator. There is a checkmark that the first line contains headings, 0 lines are skipped, and the character encoding is utf-8.

However, now there is the additional requirement of specifying the columns (German: Spalten).

For the columns specification, the following need to be identified; select NA for unused columns, e.g., “Auslastung Auslagerungsdatei” here.

• Zeitstempel: Datetime (i.e., ‘Date-Time’)
• CPU-Auslastung: CPU (i.e., ‘X.CPU.Totl’)
• RAM-Auslastung: RAM (i.e., ‘X.MEM.Used’)
• Über Netzwerk gesendet: Network transmitted (i.e., ‘X.NET.TxKBTot’)
• Über Netzwerk empfangen: Network received (i.e., ‘X.NET.RxKBTot’)
• Von Festplatte gelesen: Disk read (i.e., ‘X.DSK.ReadKBTot’)
• Auf Festplatte geschrieben: Disk written (i.e., ‘X.DSK.WriteKBTot’)
• Auslastung Auslagerungsdatei: Swap (here, ‘N/A’)

Переклади

Here is an overview of some of the German terminology used in OSCAR and the English translations:

• Messungen: Measurements (e.g., Idle Mode or SUS)
• Aktionen: Actions (i.e., log file of actions taken)
• Elektrische Leistung: ‘Electrical power’ (i.e., energy consumption measurements)
• Hardware-Auslastung: ‘Hardware load’ (i.e., hardware performance measurements)
• Dauer der Einzelmessungen (s): ‘Duration of the individual measurements (s)’ (i.e., specify how long each iteration was in seconds)
• Art der Messung: ‘Type of measurement’
  • Leerlauf: ‘Idle’ (i.e., Idle mode)
  • Nutzungsszenario: ‘Usage scenario’ (i.e., SUS)
• Formatierung Messdaten: ‘Formatting measurement data’
• Formatierung Zeitstempel: ‘Formatting timestamp’
• Trennzeichen ‘Separator’
• Textqualifizierer: ‘String delimiter’
• Dezimaltrennzeichen: ‘Decimal separator’
• Erste Zeile enthält Überschriften: ‘First line contains headings’
• Anzahl zu überspringender Zeilen: ‘Number of lines to skip’
• Zeichensatz (Encoding): ‘Character set (encoding)’
• Spalten: Columns
  • Zeitstempel: ‘Datetime’
  • CPU-Auslastung: ‘CPU utilization’
  • RAM-Auslastung: ‘RAM utilization’
  • Über Netzwerk gesendet: ‘Sent via network’
  • Über Netzwerk empfangen: ‘Received via network’
  • Von Festplatte gelesen: ‘Read from disk’
  • Auf Festplatte geschrieben: ‘Written to disk’
  • Auslastung Auslagerungsdatei: ‘Swap file utlization’

Step 3: Generating The Reports (Idle, SUS)

After completing the above, the report can be generated and downloaded. You will need to do this process twice, once for (i) the idle mode and (ii) standard usage scenario measurements, resulting in two documents.

For Blue Angel eco-certification, the two reports will be submitted for evaluation by RAL.

For examples of the above for Okular, see KDE’s Blue Angel Applications repository:

• OSCAR Report: Idle Mode
• OSCAR Report: SUS

Preparing The Documentation For Blue Angel

For Blue Angel eco-certification, it is necessary to complete several forms alongside the two reports from OSCAR.

Information that needs to be included in the forms is as follows:

• Details about the software (name, version) and measurement process (when and where measurements were made, etc.).
• Technical details about the power meter (instrument, sampling frequency, length of scenario, sample size).
• Technical details about the reference system (year, model, processor, cores, etc.).
• Software stack used for the measurements (xdotool, Collectl, etc.).
• Minimum system requirements (processor architecture, local working memory, etc.).
• Energy consumption results found in the OSCAR reports or equivalent.
• Hardware utilization results, which includes the following (for IDLE use the idle mode measurements, and for SUS use the standard usage scenario measurements):

  • Full Load: “For processing power, the full load is 100%, for working memory the sum of the installed RAM capacities, for network bandwidth the maximum transmission speed, etc.” (Blue Angel award criteria: p. 23).

  • Base Load: Average load for the reference system in Baseline measurements.

  • Idle/SUS Load: Average load for the reference system for IDLE/SUS measurements.

    From the above measurements, the following calculations are made for hardware utilization (for IDLE use the idle mode measurements, and for SUS use the standard usage scenario measurements):

    • Net Load: IDLE/SUS Load - Base Load
    • Allocation Factor: Net Load/(Full Load - Base Load)
    • Effective Load: Net Load + Allocation Factor * Base Load
    • Hardware Utilization (SUS only): Effective Load * Time (seconds)

For Blue Angel eco-certification, the above information will be added to two documents called “Annex 1” and “Annex 2”.

For examples of the above for Okular, see KDE’s Blue Angel Applications repository:

• Annex 1
• Annex 2

Alternative: Gosund SP111 Setup

Want to get started with the process of measuring your software, but short on cash or gear? Want to give the process a try without setting up a dedicated lab? Try this hack converting an inexpensive power plug to a power meter, courtesy of Volker Krause, who also documented the process provided here. You can read more at the following posts from Volker’s blog:

• “Cheap Electric Power Measurement”
• “KDE Eco Sprint July 2022”

Below is a guide to setting up a Gosund SP111 power plug already flashed with Tasmota firmware in 10 steps.

Although the data from the inexpensive power meter will likely not be accepted by the Blue Angel for eco-certification, it is nonetheless possible to obtain preliminary data using this tool.

• (0) Prerequisite

  It is necessary to have the power plug already flashed with a sufficiently new Tasmota version.

• (1) Firmware Reset

  If the device had previously been connected to another Wifi network, it might need a full reset before being able to connect to a new one.

  If the device did open a WiFi access point named “tasmota-XXXXX” this is not needed, continue directly to (2).

  Press the button for 40 seconds.

  The device will restart and you should be able to continue at (2).

• (2) WiFi Setup

  The device opens a WiFi access point named “tasmota-XXXXX”—connect to that.

  Open http://192.168.4.1 in a browser.

  The device will ask you for the WiFi name and password to connect to after entering those. The device will reconnect to that WiFi and disable its access point.

  While doing that it should show you its new address in the browser—make a note of it.

  In case that did not happen, check your WiFi router for the address of the device.

• (3) Tasmota Setup

  Open the address from step (2) in a browser.

  You should see the Tasmota web UI (a big “ON/OFF” text and a bunch of blue and one red button).

  Click “Configuration”.

  Click “Configure Other”.

  Copy

       {"NAME":"Gosund SP111 2","GPIO":
       [56,0,57,0,132,134,0,0,131,17,0,21,0],"FLAG":0,
       "BASE":18}
  

  into the template input field.

  Tick the “Activate” checkbox.

  Натисніть «Зберегти».

  The device will restart; connect to it again.

  The UI should now also contain text fields showing electrical properties, and the “Toggle” button should now actually work.

• (4) Калібрування

  Open the address from step (2) in a browser.

  Connect a purely resistive load with a known wattage, such as a conventional light bulb (not a LED or energy-saving bulb).

  Switch on power by clicking “Toggle” if needed.

  Verify that the “Power Factor” value is shown as 1 (or very close to 1); if it is lower, the current load is not suited for calibration.

  Click “Console”.

  Enter the following commands one at a time and press enter:

     AmpRes 3  
     VoltRes 3  
     EnergyRes 3  
     WattRes 3  
     FreqRes 3  
     SetOption21 1
     VoltageSet 230
  

  Enter the command PowerSet XXX with XXX replaced by the wattage specified for the test load (e.g., “40” for a 40W light bulb).

  Click “Main Menu”.

  The main page now should show correct power readings with several decimals precision.

• (5) MQTT Broker Setup

  At present, the only known way to achieve high-frequency automatic readouts is by polling over MQTT. This is not ideal and needs additional setup, unfortunately.

  If you happen to have a MQTT Broker around already, skip to step (6); otherwise, you need to set one up. The below scenario assumes Mosquitto is packaged for your GNU/Linux distribution (and therefore does not configure any security), so only do this in your own trusted network and switch it off when not needed.

  • install the mosquitto package

  • add a file /etc/mosquitto/conf.d/listen.conf with the following content:

     listener 1883  
     allow_anonymous true
    

  • start Mosquitto using systemctl start mosquitto.service

• (6) MQTT Tasmota Setup

  Connect to the Tasmota device using a web browser, and open the MQTT configuration page via Configuration > Configure MQTT.

  Enter the IP address of the MQTT broker into the “Host” field.

  Note down the value shown right of the “Topic” label in parentheses (typically something like “tasmota_xxxxxx”). This will be needed later on to address the device via MQTT. You can also change the default value to something easier to remember, but this has to be unique if you have multiple devices.

  Натисніть «Зберегти».

  The device will restart and once it is back you should see output in its Console prefixed with “MQT”.

• (7) Verifying MQTT Communication

  This assumes you have the Mosquitto client tools installed, which are usually available as distribution packages.

  You need two terminals to verify that MQTT communication works as intended.

  • In terminal 1, run mosquitto_sub -t 'stat/<topic>/STATUS10'
  • In terminal 2, run mosquitto_pub -t 'cmnd/<topic>/STATUS' -m '10'

  Replace <topic> with the value noted down in step (6).

  Everytime you run the second command, you should see a set of values printed in the first terminal.

• (8) Continuous Power Measurements

  See these scripts.

• (9) Switching WiFi Networks

  For security reasons, once connected to a WiFi network, Tasmota will not let you get back to step (2) by default without hard resetting the device (40-second button press). However, a hard reset also removes all settings and the calibration. If you need to move to a different network, there are less drastic options available, but these changes can only be made inside the network you originally connected to:

  Under Configuration > Configure WiFi, you can add details for a second WiFi access point. Those will be tried alternatingly with the first configuration by default. This does not compromise security, but requires you to know the details for the network you want to connect to.

  You can configure Tasmota to open an access point as in step (2) by default for a minute or so after boot, and then try to connect to the known configurations. This makes booting slower in known networks, and opens the potential for hijacking the device, but it can be convenient when switching to unknown networks. This mode can be enabled in the Console by the command WifiConfig 2, and disabled by the command WifiConfig 4.

  For Tasmota version 11 the 40-second button press reset can leave the device in a non-booting state, whereas resetting from the Console using Reset 1 doesn’t have that problem, but has to be done before disconnecting from the known WiFi as well.

• (10) Recovering Non-Booting Devices

  First and foremost: DO NOT CONNECT THE DEVICE TO MAIN POWER! That would be life-threatening. The entire flashing process is solely powered from 3.3V supplied by the serial adapter. Do not do any of this without having read this getting started guide.

  With Tasmota 11, you can end up in a non-booting state by merely resetting the device using the 40-second button press. This does not permanently damage the device, and it can be fixed with reflashing via a serial adapter.

  The basic process is described in the above guide. The PCB layout of the Gosund SP 111 can be seen here.

  In order for this to work, you need to connect GPIO0 (second pin on bottom left in the above image) to GND before powering up (i.e., before connecting with USB). The device LEDs (red and blue) are a useful indicator of whether you ended up in the right boot mode: the red LED should be on, and not flashing quickly, and the blue and red LED should not be on together. Once in that state, the connection can be removed (e.g., if you just hold a jumper cable to the pin) and it will remain in the right mode until a reboot.

  Again: DO NOT CONNECT THE DEVICE TO MAIN POWER as this is life-threatening.

(Б) Експлуатаційний ресурс обладнання

The criteria in category (B) ensure that the software has low-enough performance requirements to run on older, less powerful hardware at least five years old.

Many FOSS applications run on hardware much older than 5 years. In fact, members of the KDE community have noted that KDE’s desktop environment Plasma runs on hardware from even 2005!

This category is relatively easily to fulfill for the Blue Angel application. Compliance entails a declaration of backward compatibility, including details about the hardware on which the software runs and the required software stack. To demonstrate compliance, document the following information in two documents called “Annex 1” and “Annex 2”:

• Reference System Year — e.g., 2015
• Model — e.g., Fujitsu Esprimo 920
• Processor — e.g., Intel Core i5-4570
• Cores — e.g., 4
• Clock Speed — e.g., 3,6 GHz
• RAM — e.g., 4 GB
• Hard Disk (SSD/HDD) — e.g., 500 GB
• Graphics Card — e.g., Intel Ivybridge Desktop
• Network — e.g., Realtek Ethernet
• Cache — e.g., 6144 KB
• Mainboard — e.g., Fujitsu D3171-A1
• Operating System — e.g., Ubuntu 18.04

Again, examples for Okular can be found at the following links:

• Annex 1
• Annex 2

(C) User Autonomy

As discussed in PART II, the Blue Angel user autonomy criteria cover eight general areas:

1. Формати даних
2. Прозорість
3. Неперервна підтримка
4. Неможливість вилучення
5. Offline Capability
6. Modularity
7. Freedom From Advertising
8. Документація

Many FOSS projects may take for granted that Free Software respects user autonomy and in some cases information from the above list is missing from websites, manuals, wikis, etc. This may include documentation about support for open standards, uninstallability, continuity of support, and so on.

Documenting this information is important, both for fulfilling the Blue Angel award criteria and for giving users information about long-term sustainable use of their software and hardware.

This is not an exhaustive presentation for each of the above categories of the Blue Angel criteria. Rather, this guide focuses on aspects of the criteria which KDE/FOSS projects can easily document and provide (which is already most of the work). For the full criteria, see Section 3.1.3 in the basic award criteria.

2.1 Формати даних

The main information to include in documentation:

• Which (open) data formats are supported—with links to specifications, e.g., PDF?
• Also of interest: Are there examples of other software products that process these data formats?

For an example of the online documentation of supported data formats for Okular, visit the Okular website.

An example of documentation for the Blue Angel can be found in Annex 4.

2.2 Transparency Of The Software Product

When missing, provide links to documentation of the API, source code, and software license. For example, for KMail:

• KDE PIM API documentation
• Source code
• License

An example of documentation for the Blue Angel can be found in Annex 5.

2.3 Неперервна підтримка

Details about continuity of support to document include:

• Information about how long the software has been supported for (with links to release announcements).
• Release schedule and details (e.g., who maintains the software).
• Statement that updates are free of charge.
• Declaration on how the free and open source software license enables continuous support indefinitely.
• Information about whether and how functional and security updates may be installed separately.

An example of Okular’s continuity of support documentation for the Blue Angel can be found in Section 3.1.3.3 of Annex 6.

2.4 Неможливість вилучення

How are users able to completely uninstall the software? Relevant details might include:

• Uninstallation instructions that depend on how the software was installed (source code or binary).
• Examples of uninstallation instructions (source code or package managers, with relevant links to documentation).
• Information about whether user-generated data is also removed when uninstalling a program.

An example of Okular’s uninstallability documentation for the Blue Angel can be found in Section 3.1.3.4 of Annex 6.

2.5 Offline Capability

Does the software require external connections such as a license server in order to run? If not, and no network connection is needed as the software can be used offline, this should be documented.

An example of Okular’s offline capability documentation for the Blue Angel can be found in Section 3.1.3.5 of Annex 6.

2.6 Modularity

Information to document includes:

• What aspects of the software are modular and can be deactivated during installation?
• Can the software manuals or translations be installed separately?
• Are any modules which are unrelated to the core functionality included with installation, such as tracking modules or cloud integration? If not, document it!

An example of Okular’s modularity documentation for the Blue Angel can be found in Section 3.1.3.6 of Annex 6.

2.7 Freedom From Advertising

If the software does not display advertising, make this explicit in manuals and wikis and declare it in the Blue Angel application document.

2.8 Документація

This includes the following:

• General process for installing/uninstalling the software? This may include generic instructions or tutorials for a specific desktop environment or package manager.
• Data import/export process?
• What can users do to reduce the use of resources (e.g., configuration options for improving performance)?
• Does the software have any resource-intensive functionality not necessary for the core functionality? If not, great. Let’s tell the users!
• Licensing terms related to further development of the software products, with links to source code and license?
• Who supports the development of the software?
• Does the software collect any personal data? Is is compliant with existing data protection laws? If yes, document it!
• What is the privacy policy? Is there telemetry? If yes, how does the software handle data security, data collection, and data transmission? Also, are there ads or tracking embedded in the software? If not, excellent—now make sure to spread the word!

An example of Okular’s product documentation for Blue Angel certification can be found in Section 3.1.3.8 of Annex 6.

Submitting To RAL

For examples of all of the above documentation, see KDE’s Blue Angel Applications repository.

Once you have all of the documentation prepared, you need to submit it for review to RAL gGmbH (if you recall, RAL is the authorized body that assesses compliance with the award criteria). The portal for submitting Blue Angel applications can be found here (https://portal.ral-umwelt.de/).

If you need help with the online interface, RAL provides documentation.

Example Submission Documents

Below are examples of Blue Angel documentation for Okular.

• Annex 1: Form
• Annex 2: Spreadsheet
• Annex 3: OSCAR Report For Idle Mode
• Annex 3: OSCAR Report For SUS
• Annex 4: Data Formats
• Annex 5: Open Standards
• Annex 6: Product Information
• Annex 7: Data format for passing on the product information about resource and energy efficiency

Notable Sustainable Software Initiatives

There are many initiatives working on tooling for measuring the energy consumption of software. We would like to mention five in particular who have been collaborating with the KDE Eco initiative:

• The Green Software Engineering work group at the Environmental Campus Birkenfeld (German: Umwelt Campus Birkenfeld)

  Since 2008, the Green Software Engineering work group have been working on research projects with a focus on sustainable software. Their research provides the foundation of the work here, and their team developed tools such as OSCAR and have measured various KDE applications, including Okular.

• Öko-Institut e.V.

  The Öko-Institut is one of Europe’s leading independent research and consultancy organizations working for a sustainable future. The Sustainable Products & Material Flows research group is working on various measurement methodologies. In this blog post (in German) researchers present a self-measurement technique using a simple Python script.

• Green Coding Berlin

  Green Coding Berlin is focused on research into the energy consumption of software and its infrastructure, creating open source measurement tools, and building a community and ecosystem around green software.

• The SoftAWERE project from the Sustainable Digital Infrastructure Alliance

  The SoftAWERE steering group oversees and sets the direction for the development of tools and labels for energy-efficient software applications.

• Green Web Foundation

  The Green Web Foundation tracks and accelerates the transition to a fossil-free internet.

Про нас

Автори

KDE Eco tooling and documentation are provided by community members who have volunteered to contribute to this project for the benefit of all. Primary contributors include (listed in alphabetical order by first name): Arne Tarara, Cornelius Schumacher, Emmanuel Charruau, Karanjot Singh, Nicolas Fella, and Volker Krause. Thank you—your contributions make this handbook possible.

The text of this version of the handbook was written and/or compiled from the above documentation by Joseph P. De Veaugh-Geiss. Olea Morris edited the text. Lana Lutz and Arwin Neil Baichoo made the book and website design as well as the images therein beautiful. Paul Brown made significant improvements to the Okular blog post adapted for “Okular, The First Eco-Certified Computer Program” in Part II. Wikipedia was a source for several texts which were included here in modified form. Thank you to the community of Wikipedia writers and editors for making such a wonderful resource for all of us. See the end of each section for additional information about sources.

Подяки

Thank you to the many contributors to the KDE Eco initiative in general (listed in alphabetical order by first name): Achim Guldner, Adriaan de Groot, Aleix Pol, Alexander Semke, André Pönitz, Björn Balazs, Carl Schwan, Chris Adams, Christopher Stumpf, David Hurka, Fabian, Felix Behrens, Franziska Mai, Harald Sitter, Jens Gröger, Johnny Jazeix, Jonathan Esk-Riddell, Kira Obergöker, Lydia Pintscher, Marina Köhn, Mathias Bornschein, Max Schulze, Phu Nguyen, Sami Shalayel, Stefan Naumann, Sven Köhler, and Tobias Fella. Your contributions are greatly appreciated.

People who are interested in contributing to KDE Eco are encouraged to join the mailing list or Matrix room. Contributors are also invited to join one of the KDE Eco sprints and in-person or online meetups. Learn more at out website.

The KDE Eco initiative has benefitted from many informative discussions that took place at the following conferences and workshops: Akademy 2022, Linux App Summit 2022, FOSDEM 2023, rC3: NOWHERE 2021, SFSCon 2021/2022, Grazer Linuxtage 2022, Qt World Summit 2022, QtDevCon 2022, Fedora Nest 2022, Green Coding Berlin meetups, Sustainable Digital Infrastructure Alliance hackathon, EnviroInfo 2022, and Bits & Bäume 2022. Thank you!

Ліцензування

Unless indicated otherwise, all contents released under the Creative Commons Attribution-ShareAlike 4.0 International (CC-BY-SA-4.0) license. For more information about documentation licensing at KDE, see KDE’s licensing policy.

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

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

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