KDE Eco 2021 Sprint: Podrobnosti o komunitnom planovani ekologickeho projektu KDE

Toto je nadvaznost na oznamenie KDE Eco Sprintu zverejnene na The Dot.

Dna 11. decembra 2021 uskutocnilo KDE Eco prvy z mnohych planovanych Sprintov so 7 ucastnikmi. Sprint mal byt povodne osobnym podujatim na zriadenie komunitneho meracieho laboratoria, ale koronavirus mal ine plany. Komunita vsak prejavila svoju obvyklu vynaliezavost a stretli sme sa online.

Oznamenie KDE Eco 2021 Sprint na KDE News

V tomto podrobnom prispevku poskytnem detailny prehlad hlavnych tem diskutovanych na Sprinte a ich vysledkov; podrobnosti najdete aj v zapisnici.

Vedeli ste?

Podobne diskusie prebiehaju mesacne na nasich komunitnych stretnutiach kazdu 2. stredu v mesiaci od 19:00 do 20:00 CET/CEST (berlinsky cas).

Vytvorenie timu KDE Eco

KDE Eco sa v sucasnosti sklada z troch suvisiacich projektov: (i) Free and open source Energy Efficiency Project (FEEP), (ii) Blauer Engel For FOSS (BE4FOSS) a (iii) Blauer Engel Applications. Kazdy projekt ma svoj vlastny zamer: FEEP sa zaobera meranim spotreby energie slobodneho softveru, BE4FOSS sa zameriava na organizaciu komunity a sirenie informacii o ekoznacke Blauer Engel a repozitar Blauer Engel Applications obsahuje vsetky dokumenty suvisiace s certifikaciou KDE/slobodneho softveru ekoznackou. Do Sprintu boli tri repozitare projektov umiestnene v roznych osobnych mennych priestoroch. Teraz sa vsetky tri repozitare nachadzaju na https://invent.kde.org/teams/eco.

Umiestnenie projektov pod jeden tim jasnejsie prepaja tieto a pripadne buduce projekty. Navyse, neosobny menny priestor je vhodnejsi pre komunitne projekty. Nevahajte a pozrite si aktivity kazdeho projektu v uvedenom timovom priestore!

Timy > KDE Eco

Dokoncenie ziadosti o Blauer Engel pre Okular

Existuju tri aplikacie KDE, ktorych spotreba energie uz bola merana: Okular, KMail a Krita. Z nich ziadosti o Blauer Engel pre Okular a KMail boli v priprave uz nejaky cas a jednym z cielov bolo dokoncit ziadost pre Okular. S hrdostou oznamujeme, ze po Sprinte bola ziadost Okularu podana a momentalne sa preskumava na certifikaciu. Ocakavame spatnu vazbu od RAL gGmbH, certifikacneho organu pre Blauer Engel, do 2-3 mesiacov. Podanie KMail bude nasledovat coskoro.

Pocas skupinoveho preskumania ziadosti Okularu ucastnici vzniesli mnohe zaujimave body. Jeden bod napriklad vznikol pri diskusii o kriteriach transparentnosti Blauer Engel (Oddiel 3.1.3.2). Malte Reissig z vyskumnej skupiny IASS poukkazal na to, ako moze otvoreny vyvoj pozitivne ovplyvnit niektore z dalsich poziadaviek kriterii pre udelenie (pozri tuto diskusiu), ako su dlhodoba udrzatelnost a autonomia pouzivatelov softveroveho produktu. To znamena, ze pouzivatelia slobodneho softveru nielen pasivne softver pouzivaju, ale su povzbudzovani a schopni vyjadrit priania pre buduci vyvoj aplikacii a mozu sa aktivne podielat na planovani milnikov. S FOSS komunita urcuje smer vyvoja!

Ikona Okular

Dalsi bod suvisel s distribuciou slobodneho softveru a vyzvami, ktore predstavuje pre splnenie kriterii Blauer Engel. Kedze slobodny softver zvycajne distribuuje softver decentralizovanym sposobom, pre akukolovek jednu aplikaciu existuje mnozstvo vydani a distribucnych kanalov. Zvazte Okular, ktory je balikovany nielen pre Flatpak, ale aj Microsoft Store, nehovoriac o pocetnych GNU/Linux distribuciach (napr. OpenSuse, Debian). Rozdiely v balikovacej infrastrukture mozu ovplyvnit splnenie poziadaviek Blauer Engel, ako su odinstalovatelnost, modularita atd.

Spolocnosti vydavajuce proprietarny softver, zvycajne s centralizovanym nasadenim svojich produktov, tieto problemy nemaju. V tomto kontexte jedna z moznosti, o ktorej skupina diskutovala, je certifikacia iba zdrojoveho kodu programu, cim sa zostane neutralny voci rozdielom v tom, ako je softverovy produkt balikovany a distribuovany. Dalsou moznostou je certifikacia distribucne specifickych vydani, napriklad pre Microsoft Store. V skutocnosti by sa to mohlo pouzit na marketingove ucely na oslovenie novych pouzivatelov a ich zaclenenie do komunity KDE -- pozri napr. tuto diskusiu.

Radi by sme vedeli, co si myslite. Pridajte sa do konverzacie na nasom mailing liste alebo v Matrix miestnosti alebo cez sledovace problemov v nasich GitLab repozitaroch!

Standardne scenare pouzivania

Standardny scenar pouzivania (SUS) odzrkadluje typicke funkcie aplikacie, pricom sa zohladnuje frekvencia tychto funkcii. Standardne scenare pouzivania su klucove pre meranie spotreby energie softveru.

Pri preskumani zaznamov akcii SUS pre Okular pre ziadost o Blauer Engel boli vznesene dva dolezite body, ktore zlepsia implementaciu SUS pri merani v laboratoriu. Jednym bolo pozorovanie o potrebe dokumentovat nielen akcie, ale aj objekty akcii (napr. pri pouzivani citacky PDF, ktore PDF sa otvara), pretoze to moze ovplyvnit spotrebu energie. Druhym bolo, ze zahrnutie necinnosti je dolezite pri definovani SUS: necinnost je realisticka a moze ukazat, ze sa nic nedeje, ked sa nic nema diat.

Na virtualnom stretnuti boli vznesene aj dalsie otazky. Nicolas Fella, softverovy inzinier v KDAB Berlin, vyjadril zaujem o porovnanie dvoch chatovacich klientov, co presunulo konverzaciu k definovaniu jednotlivych scenarov pri porovnavani dvoch aplikacii s podobnym pouzivanim. Jednotlivy SUS obmedzi, ktore softverove funkcie mozno testovat, ale vysledky merani budu priamo porovnatelne. Pre klient-server softver, ako su chatove alebo e-mailove klienty, je tu navyse otazka sietovej zlozky, ktora by pre kontrolovane testovanie vyzadovala zriadenie a meranie spotreby energie servera. Byvaly prezident KDE e.V. a dlhorocny prispievatel do KDE Cornelius Schumacher poukazal na to, ze pri meraniach KMail sa merala iba vypoctova praca na lokalnom pocitaci. Meranie nelokalnych vypoctov v klient-server softveri je dnes relevantnejsie nez kedykolvek predtym.

Uvitacia obrazovka KMail

Dalsou diskutovanou temou bolo definovanie akcii SUS abstraktne s cielom automatizovat implementaciu scenarov pouzivania roznymi nastrojmi (Actiona, xdotool, KXmlGui atd.). Dolezitym bodom bolo, ze rozne emulacne nastroje robia rozne veci, co moze predstavovat vyzvy pre automatizaciu procesu. Napriklad pri pouziti KXmlGui na emulaciu nie je mozne pisat text, a preto moze byt stale potrebny nastroj ako xdotool. Chcel by niekto z komunity pomoct riesit tieto vyzvy?

Skupina dalej diskutovala o tom, ako by sa scenare pouzivania mohli tiez preucelovat na testovanie odozvy a vseobecneho vykonu na starsom alebo menej vykonnom hardveri. Ake su vase napady?

Vedeli ste, ze planujeme meracie maratony na meranie spotreby energie FOSS/KDE aplikacii na zaciatku roka 2022? Pre ktore aplikacie by ste chceli vidiet pripravene standardne scenare pouzivania? Podelte sa o svoje napady s nami tu alebo poslite svoj SUS do nasho GitLab repozitara!

Replikovatelny referencny system

Standardne scenare pouzivania sa spustaju na referencnom systeme a dolezitou otazkou bolo, ako mat replikovatelny referencny system. Existuje niekolko systemovych vrstiev na zvazenie: Hardver (CPU, disk, RAM atd.); OS a sluzby OS, ako spravca aktivit v Plasme; a konfiguracia testovanej aplikacie a pripadnych suvisiacich aplikacii (napr. Akonadi pre PIM aplikacie). Na jednej strane je nevyhnutne mat kontrolovane prostredie; na druhej strane je ziaduce mat merania, ktore odrazaju skutocne vypoctove prostredia. Nakoniec, ci mat kontrolovane alebo prirodzene vypoctove prostredia bude zavisiet od toho, na co sa udaje maju pouzit.

Napriklad pre vyvojarov, ktori maju zaujem o jednotkove testy energetickej efektivnosti alebo ziskanie pecate Blauer Engel, bude nevyhnutne mat jasne specifikovane prostredia. Ake su pohodlne a rychle sposoby, ako dostat system do znameho stavu? Diskutovalo sa o troch napadoch: (i) vytvaranie snimok suboroveho systemu (napr. Snapper), (ii) vymazanie vyrovnavacej pamate systemu a (iii) nahradenie konfiguracnych suborov. Ak mate dalsie napady, dajte nam vediet tu!

Pre realne prostredia bol jeden navrh, potencialne kontroverzny, zaznamenavat vykon hardveru a spotrebu elektrickej energie, kym ludia pouzivaju svoje osobne pocitace. Nejaki dobrovolnici?

Vystup udajov

Pri merani spotreby energie v laboratoriu, najma pre ekocertifikaciu Blauer Engel, sa mozu generovat tri typy datovych suborov: (i) zaznam akcii, (ii) udaje o vykone hardveru (CPU, RAM atd.) a (iii) spotreba elektrickej energie. Kedze v niektorych pripadoch bude vystup udajov treba definovat samostatne, je potrebne zvazit, ako by mali udaje vyzerat pred meranim v laboratoriu.

V suvislosti s udajmi bolo vznesenych niekolko otazok: Mali by sa vystupne udaje standardizovat na harmonizaciu vystupu napriec meracimi kampanami, alebo staci jednoducho zverejnit zozbierane udaje v pristupnom formate (napriklad ako subory .csv, ako v repozitari FEEP)? Aka presnost casovych znaciek je potrebna (napr. sekundy vs. zlomky sekund)? Tieto otazky zatial zostavaju otvorene.

Zariadenia na meranie spotreby

Kriteria Blauer Engel odkazuju na dva merace spotreby (PM) konkretne: Janitza UMG 604 a Gude Expert Power Control 1202. Tieto zariadenia nie su lacne. V roku 2020 dlhorocny prispievatel KDE Volker Krause hackol 8-eurovy napajaci konektor a napisal o tom. To viedlo k myslienke pouzivania lacnych meracov spotreby v nizkorozpoctovych domacich laboratoriach. Mal by niekto z komunity zaujem porovnat vysledky?

Z blogoveho prispevku Volkera Krauseho: "Priklad merania (200 ms vzorkovaci interval, bez filtra): pohyb kurzora mysi medzi vzorkami 100 a 150, s pikom pri prechode nad polozkou panela uloh."

Dalsi sposob merania spotreby energie prisiel od prispievatela KDE Davida Hurku, ktory ma navrh na USB SPI senzory spotreby na poskytnutie alternativy s vyssim rozlisenim.

Otvorene otazky pre meracie laboratoria

Diskutovalo sa o niekolkych dalsich otazkach suvisiacich so spotrebou energie a meranim v laboratoriu. Hoci sa v kazdom pripade neprijali konecne rozhodnutia, mnohe z tychto otvorenych otazok bude dolezite zvazit v buducnosti.

• Napad na marketingovo privetivy nastroj na upozornenie na spotrebu energie softveru.
  • Napriklad tlacidlo 'Eco' na meranie energetickej efektivnosti/uhlikovej stopy (porov. uhlikova stopa cestovania v aplikacii Itinerary).
  • Upozornujeme, ze podobnu funkciu uz poskytuje PowerTop, hoci zostavaju otvorene otazky (kedy je bezpecne ho povolit, aby sa predislo strate udajov, zamrznutiu pocitaca?).
• Kedy nevyhody prevazuju nad vyhodami podpory starsieho hardveru?
  • Pozvime vyskumnikov pracujucich na tejto teme, aby diskutovali s komunitou KDE Eco.
• Buduca spolupraca:
  • Spolocny Sprint s pribuznymi projektmi (napr. SoftAWERE)?
  • Diskutovat o vyssie uvedenych temach a dalsich s inymi pribuznymi komunitami (Bits & Baeume, Forum InformatikerInnen fuer Frieden und gesellschaftliche Verantwortung atd.)?

Zaver

Online Sprint bol skvelou prilezitostou spojit komunitu a posunut projekt KDE Eco vpred. Uspech takychto podujati zavisi predovsetkym od komunity, takze nam dovolte poslat uprimne podakovanie vsetkym, ktori sa zapojili do konverzacie. Tesime sa na rast komunity v roku 2022!

Oznamenie o financovani

Projekt BE4FOSS bol financovany Spolkovym uradom pre zivotne prostredie a Spolkovym ministerstvom pre zivotne prostredie, ochranu prirody, jadrovu bezpecnost a ochranu spotrebitelov (BMUV¹). Financne prostriedky su poskytovane na zaklade rozhodnutia Nemeckeho spolkoveho snemu.

Za obsah tejto publikacie je zodpovedny vydavatel.

¹ Oficialne loga BMUV a UBA sa zasielaju iba na poziadanie na: verbaendefoerderung@uba.de

Article contributed by Joseph P. De Veaugh-Geiss under the CC-BY-4.0 license.