KDE Eco 2021 Sprint: podrobnosti o načrtovanju skupnosti za ekološki projekt KDE

Ponedeljek, 7. februar 2022 | Joseph P. De Veaugh-Geiss

To je nadaljevanje obvestila o KDE Eco Sprint, objavljenega na The Dot.

11. decembra 2021 je KDE Eco izvedel prvi od mnogih načrtovanih sprintov, katerega se je udeležilo 7 ljudi. Sprint je bil prvotno mišljen kot osebni dogodek za vzpostavitev skupnostnega merilnega laboratorija, vendar je imela Corona druge zamisli. Kljub temu je skupnost uporabila svojo običajno iznajdljivost in namesto tega smo se srečali na spletu.

Objava KDE Eco 2021 Sprint v novicah KDE

V tem obsežnem prispevku bom podal podroben pregled glavnih vprašanj, o katerih se razpravlja na Sprintu, in njihovih rezultatov; glejte tudi zapisnik za dodatne podrobnosti.

Ali ste vedeli?

Podobne razprave se odvijajo mesečno na srečanjih naše skupnosti vsako 2. sredo v mesecu od 19. do 20. ure po srednjeevropskem času (Berlin).

Ustvarjanje ekipe KDE Eco

KDE Eco trenutno sestavljajo trije povezani projekti: (i) brezplačen in odprtokodni projekt energetske učinkovitosti (FEEP), (ii) Blauer Engel za FOSS (BE4FOSS) in (iii) aplikacije Blauer Engel. Vsak projekt ima svoj poseben poudarek: FEEP se ukvarja z merjenjem porabe energije brezplačne programske opreme, BE4FOSS je osredotočen na organizacijo skupnosti in širjenje informacij o ekološki nalepki Blauer Engel, v skladišču aplikacij Blauer Engel pa so vsi dokumenti, povezani s certificiranjem KDE/brezplačnega programja z znakom za okolje. Do Sprinta so trije repozitoriji za projekte gostovali v različnih osebnih imenskih prostorih. Zdaj lahko vse tri repozitorije najdete na https://invent.kde.org/teams/eco.

Če so projekti pod eno ekipo, to bolj jasno povezuje te in morebitne prihodnje projekte. Poleg tega je neosebni imenski prostor bolj primeren za projekte skupnosti. Vabljeni, da si oglejte dejavnosti vsakega projekta v zgornjem ekipnem prostoru!

Ekipe > KDE Eco

Dokončanje aplikacije Blauer Engel za Okular

Obstajajo tri aplikacije KDE, katerih poraba energije je bila že izmerjena: Okular, [KMail](https: //invent.kde.org/teams/eco/feep/-/tree/master/measurements/kmail) in [Krita](https://invent.kde.org/teams/eco/feep/-/tree/ master/meritve/krita). Od teh treh sta aplikaciji Blauer Engel za Okular in KMail v pripravi že nekaj časa, en cilj pa je bil dokončati Okularjevo aplikacijo. S ponosom sporočamo, da je bila po Sprintu prijava Okularja oddana in je trenutno v pregledu za pridobitev certifikata. Pričakujemo povratne informacije od RAL gGmbH, organa, ki podeljuje znake Blauer Engel, v 2-3 mesecih. KMail-ova oddaja bo sledila kmalu.

Med skupinskim pregledom aplikacije Okular so udeleženci izpostavili veliko zanimivih točk. Ena točka se je na primer pojavila pri razpravi o merilih preglednosti Blauer Engel (razdelek 3.1.3.2). Malte Reißig iz raziskovalne skupine IASS na temo »Digitalizacija in trajnostne transformacije« je poudaril, kako lahko odprt razvoj pozitivno vpliva na nekatere druge zahteve meril za dodelitev (glej to razpravo), kot sta dolgoročna vzdržljivost in avtonomija uporabnikov programskega izdelka. To pomeni, da uporabniki brezplačne programske opreme ne samo pasivno uporabljajo programsko opremo, ampak jih spodbujajo in lahko izrazijo želje za prihodnji razvoj aplikacij ter lahko aktivno sodelujejo pri načrtovanju mejnikov. Poleg tega se pri odprtem razvoju lahko sporočila o spremembah programske kode povežejo s posebnimi težavami ali napakami, o katerih poroča skupnost uporabnikov in razvijalcev. Z brezplačno programsko opremo aplikacija ni le končni izdelek, temveč odprt proces, ki odraža potrebe in želje svojih uporabnikov in njihovih skupnosti. S programjem FOSS skupnost usmerja razvoj!

Ikona Okular

Druga točka je bila povezana z distribucijo brezplačne programske opreme in tem, kako to predstavlja izzive za izpolnjevanje meril Blauer Engel. Ker prosto programje običajno distribuira programsko opremo na decentraliziran način, obstajajo za vsako aplikacijo številni kanali za izdajo in distribucijo. Razmislite o Okularju, ki ni pakiran samo za Flatpak, ampak tudi za Microsoft Store, da ne omenjamo številnih distribucij GNU/Linux (npr. [OpenSuse](https://software.opensuse.org /package/okular), Debian). Razlike v infrastrukturi izdelave paketov lahko vplivajo na izpolnjevanje zahtev Blauer Engel, kot so možnost odstranitve, modularnost itn.

Podjetja, ki izdajajo lastniško programsko opremo, običajno s centralizirano uvedbo svojih izdelkov, ne bodo imela teh težav. Glede na to je ena od možnosti, o kateri je razpravljala skupina, certificiranje samo izvorne kode programa, tako bi ostajali nevtralni glede razlik v tem, kako je programski izdelek pakiran in distribuiran. Druga možnost je certificiranje izdaj, specifičnih za distribucijo, npr. za Microsoft Store. Pravzaprav bi slednje lahko uporabili za namene trženja, da bi dosegli nove uporabnike in jih pripeljali v skupnost KDE – glej npr. to razpravo.

Radi bi izvedeli, kaj mislite. Pridružite se pogovoru na našem poštnem seznamu, [sobi Matrix](https://webchat.kde.org/# /room/#energy-efficiency:kde.org) ali prek sledilnikov težav v naših skladiščih GitLab!

Scenariji standardne uporabe

Scenarij standardne uporabe (SUS) odraža tipične funkcije aplikacije, pri čemer se upošteva pogostost teh funkcij. Standardni scenariji uporabe so osrednjega pomena za merjenje porabe energije za določeno programsko opremo.

Pri pregledovanju dnevnikov delovanja SUS za Okular za aplikacijo Blauer Engel, sta bili izpostavljeni dve pomembni točki, ki bosta izboljšali izvajanje SUS pri merjenju v laboratoriju. Prvo je opažanje, da je treba dokumentirati ne le dejanja, ampak tudi objekte dejanj (npr. pri uporabi pdf-bralnika, kateri pdf se odpre), saj lahko to vpliva na porabo energije. Druga je bila, da je vključitev nedejavnega dejanja pomembna pri definiranju SUS: dejanje mirovanja je realistično in lahko pokaže, da se nič ne dogaja, ko se naj ne bi nič dogajalo.

Na virtualnem omizju je bilo izpostavljenih več drugih vprašanj. Nicolas Fella, programski inženir pri KDAB Berlin, je izrazil zanimanje za primerjavo dveh odjemalcev za klepet, kar je pogovor preusmerilo na opredelitev posameznih scenarijev pri primerjavi dveh aplikacij s podobno uporabo. En sam SUS bo omejil, katere funkcije programske opreme je mogoče testirati, vendar bo omogočil neposredno primerljivost rezultatov meritev. Poleg tega pri programski opremi odjemalec-strežnik, kot so odjemalci za klepet ali e-pošto, obstaja vprašanje omrežne komponente, ki bi za nadzorovano testiranje zahtevala nastavitev in merjenje porabe energije strežnika. Nekdanji predsednik KDE e.V. in dolgoletni sodelavec KDE Cornelius Schumacher je poudaril, da je bilo za [meritve KMail](https://invent.kde.org/teams/eco/ blue-angel-application/-/tree/master/applications/kmail) izmerjeno le računalniško delo na krajevnem računalniku. Merjenje oddaljenega računanja v programski opremi odjemalec-strežnik je v današnjem svetu pomembnejše kot kdaj koli prej, to pa je trenutno načrtovano za revidirana merila za podeljevanje znaka Blauer Engel za programsko opremo.

Pozdravni zaslon KMail

Druga tema, o kateri smo razpravljali, je bilo abstraktno definiranje dejanj SUS, da bi avtomatizirali izvajanje scenarijev uporabe z različnimi orodji (Actiona, xdotool, KXmlGui itn.). Pomembna točka je bila, da različna orodja za emulacijo počnejo različne stvari, kar bi lahko predstavljalo izzive za avtomatizacijo procesa. Primer: pri uporabi KXmlGui za emulacijo ni mogoče vnašati besedila, zato bo morda še vedno potrebno nekaj, kot je xdotool. V zvezi s tem je bil še en predlog, da se SUS strukturira tako, da se lahko avtomatizira tudi ustvarjanje dnevnika dejanj. Bi kdo v skupnosti rad pomagal pri soočanju s temi izzivi?

Poleg tega je skupina razpravljala o tem, kako bi lahko scenarije uporabe preoblikovali tudi za preizkušanje odzivnosti in splošne zmogljivosti na starejši ali poceni strojni opremi. Kakšne so vaše zamisli?

Ali ste vedeli, da načrtujemo merjenje porabe energije aplikacij FOSS/KDE v začetku leta 2022? Za katere aplikacije bi radi videli pripravljene standardne scenarije uporabe? Delite svoje ideje z nami tukaj ali pošljite svoje SUS v naše [skladišče GitLab](https://invent.kde. org/teams/eco/be4foss/-/tree/master/standard-usage-scenarios)!

Ponovljiv referenčni sistem

Standardni scenariji uporabe (SUS, angl. za Standard Usage Scenarios) se izvajajo na referenčnem sistemu, pomembno vprašanje pa je bilo, kako imeti ponovljiv referenčni sistem. Upoštevati je treba več sistemskih slojev: strojna oprema (CPE, Disk, Ram itd.); storitve OS in OS, kot je upravitelj dejavnosti v Plasmi, ter njihove prilagoditve; in prilagoditev testirane aplikacije ter vseh povezanih aplikacij (npr. Akonadi za aplikacije PIM). Po eni strani je treba imeti nadzorovano okolje, da lahko interpretiramo rezultate; po drugi strani pa je zaželeno imeti meritve, ki odražajo dejanska, morda celo šuma polna računalniška okolja, da bi razumeli realno porabo energije programske opreme. Na koncu bo odvisno od tega, ali bomo imeli nadzorovano ali naravno računalniško okolje, odvisno od tega, za kaj se bodo podatki uporabljali, to pa se bo razlikovalo glede na raziskovalce, razvijalce, presojevalce ustreznosti za eko-znak, podjetja itn.

Primer: za razvijalce, ki jih zanima testiranje energetske učinkovitosti ali pridobitev znaka Blauer Engel, bodo potrebna jasno določena okolja. Kateri so torej priročni in hitri načini za spravljanje sistema v znano stanje? Razpravljali so o treh idejah: (i) izdelava posnetkov datotečnega sistema (npr. Snapper), (ii) brisanje sistemskega predpomnilnika in (iii) zamenjava prilagoditvenih datotek. Če imate druge ideje, nam jih sporočite semkaj!

Za okolja resničnega sveta je predlog, ki je potencialno sporen, beleženje zmogljivosti strojne opreme in porabe električne energije, medtem ko ljudje uporabljajo svoje osebne računalnike. Kakšen prostovoljec?

Izhodni podatki

Pri merjenju porabe energije v laboratoriju, zlasti za ekološko potrjevanje Modri angel, se lahko ustvarijo tri vrste podatkovnih datotek: (i) datoteka dnevnika dejanj (glej zgoraj o avtomatizaciji takšnih dnevniških datotek), (ii) podatki o zmogljivosti strojne opreme (CPE, RAM itn.) in (iii) poraba električne energije. Ker bodo v nekaterih primerih morali biti izhodni podatki samodefinirani (npr. zapisovalniki časovnih žigov v skriptih xdotool), je treba pred merjenjem v laboratoriju razmisliti, kako naj bi podatki izgledali.

V zvezi s podatki je bilo izpostavljenih več vprašanj: ali je treba izhodne podatke standardizirati za uskladitev rezultatov v meritvenih kampanjah ali je dovolj preprosto objaviti zbrane podatke v dostopni obliki (na primer kot datoteke .csv, kot je v skladišču FEEP)? Kakšna natančnost časovnega žiga je potrebna (npr. sekunde v primerjavi z deli sekund)? Ta vprašanja za zdaj ostajajo odprta, vendar se je skupina odločila, da potrebujemo pregled naprav/skriptov, združljivih s FOSS (npr. skript Achima Guldnerja za serijo Gude Expert Power Control 1202) in komplete orodij (npr. orodja za statistično analizo, kot so OSCAR, R, Julia, Octave , PSPP, NumPy), ki se uporabljajo za meritve in analize, ki so trenutno v teku.

Naprave za merjenje porabe

Kriteriji Blauer Engel se nanašajo predvsem na dva merilnika moči (PM): Janitza UMG 604 in Gude Expert Power Control 1202. Te naprave niso poceni. Leta 2020 je dolgoletni sodelavec KDE Volker Krause priredil napajalni vtič za 8 EUR in pisal o tem. Kot je opisano v objavi v blogu, lahko ti poceni napajalni vtiči dosežejo hitrost vzorčenja do 200 ms. To je privedlo do ideje o uporabi poceni števcev električne energije v nizkoproračunskih domačih laboratorijih. V ta namen bo sčasoma koristno primerjati rezultate profesionalnih merilnikov moči s proračunskimi, da bi videli, kako se primerjajo. Je kdo v skupnosti zainteresiran za to?

Iz objave v spletnem dnevniku Volkerja Krausea: »Primer meritve (interval vzorca 200 ms, brez filtra): premikanje kazalca miške med vzorci 100 in 150, z vrhom, ko lebdite nad vnosom opravilne vrstice.«

Drug način za merjenje porabe energije je prišel od sodelavca KDE Davida Hurka, ki ima predlog za senzorje moči USB SPI kot višje-ločljivostne alternative merilnikom moči, ki merijo na stenski vtičnici.

Odprta vprašanja za merilne laboratorije

Razpravljali so o več drugih vprašanjih, povezanih s porabo energije in laboratorijskimi meritvami. Čeprav dokončne odločitve niso bile sprejete v vsakem primeru, bo o veliko teh odprtih vprašanih pomembno razmisliti v prihodnje.

• Ideja o trženju prijaznem orodju za opozarjanje na porabo energije programske opreme.
  • Primer: gumb »Eko« za merilnik energetske učinkovitosti/ogljičnega odtisa (prim. potovalni ogljični odtis v aplikaciji Itinerary).
  • Upoštevajte, da podobno funkcionalnost že ponuja PowerTop, čeprav ostajajo še nerešene težave (kdaj ga je varno omogočiti, da preprečite izgubo podatkov, zamrznitev računalnika?).
• Kdaj pomanjkljivosti odtehtajo prednosti podpore za starejšo strojno opremo?
  • Povabimo raziskovalce, ki se ukvarjajo s tem, da razpravljajo s skupnostjo KDE Eco.
• Prihodnje sodelovanje:
  • Skupni Sprint s sorodnimi projekti (npr. SoftAWERE)? (Morda zanimivo za bralca: Max Schulze iz SoftAWERE/SDIA, ki je bil predstavljen na mesečnem srečanju KDE Eco januarja 2022, ki si ga lahko preberete iz zapisnika [tukaj](https:/ /invent.kde.org/teams/eco/be4foss/-/blob/master/community-meetups/2022-01-12_community-meetup_protocol.md).)
  • Se želite pogovoriti o zgornjih temah in drugem z drugimi sorodnimi skupnostmi (Bits & Bäume, [Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung](https://www.fiff.de /) itn.)?

Zaključek

Spletni Sprint je bil čudovita priložnost, da združimo skupnost in premaknemo projekt KDE Eco naprej, še posebej, ko se pripravljamo na merilni laboratorij skupnosti, ki bo potekal v KDAB Berlin, in prvo od mnogih meritev (načrtovano za začetek leta 2022)! Uspeh tovrstnih dogodkov je v prvi vrsti odvisen od skupnosti, zato dovolite, da se vsem, ki ste se pridružili pogovoru, iskreno zahvalimo. Veselimo se rasti skupnosti v letu 2022! Poleg tega tega, kar počnemo, ne bi mogli narediti brez podpore KDE e.V. kot tudi BMU/UBA, ki finančno podpirata projekt BE4FOSS (čeprav je za vsebino te publikacije odgovoren samo založnik).

Obvestilo o financiranju

Projekt BE4Foss je financirala nemška Zvezna agencija za okolje in Zvezno ministrstvo za okolje, ohranjanje narave, jedrsko varnost in varstvo potrošnikov (BMUV¹). Sredstva so na voljo z resolucijo nemškega Bundestaga.

Založnik je odgovoren za vsebino te publikacije.

¹ Uradne logotipe BMUV in UBA pošiljamo samo na zahtevo s prošnjo na: verbaendefoerderung@uba.de