Sezona KDE 2022 z Eko KDE

Zelo sem hvaležen ekipi KDE, ker me je povabila, da sem del te neverjetne skupnosti prek njihovega letnega programa Sezona KDE.

O meni

Sem Karanjot Singh. Sem študent prvega letnika računalništva na Inštitutu za informacijsko tehnologijo Jaypee v Noida (Indija). Kot razvijalec sem delal z različnimi prostimi in odprtokodnimi programi (FOSS), kot so Kharagpur Winter of Code v 2021 (KWoC'21). Vendar bom prvič prispeval k projektu s tako veliko skupnostjo. Zelo sem vnet glede tovrstnega programja, reševanja problemov in izboljšanja učinkovitosti procesov. Uživam v raziskovanju in učenju novih tehnologij in gradnji stvari za družbeno korist. Prav tako menim, da je prispevanje k FOSS najboljši način za pridobivanje izkušenj pri razvoju programske opreme.

Na čem bom delal

V okviru pionirskega projekta trajnosti ima Eko KDE za cilj merjenje in zmanjšanje porabe energije KDE/proste programske opreme. To zahteva posnemanje vedenja uporabnikov, ki ga je mogoče doseči s načrtovanjem in skriptnim scenarijem standardne uporabe. Pripravil bom skripte standardnih scenarijev uporabe za različne aplikacije, s poudarkom na pogosto uporabljenih urejevalnikih besedil, kot so Kate, KWrite, Vim, Nano, Emacs, Calligra Words in LibreOffice. Te scenarije uporabe bom pripravil z enim od številnih razpoložljivih emulacijskih orodij. Spodaj je moja časovnica za SoK'22:

Motivacija za delo na projektu Eko KDE

Mislim, da je Eko KDE zelo dobra pobuda za razvoj virov in energetsko učinkovite brezplačne programske opreme. Ko nekdo uporablja FOSS in odkrije, da je programska oprema pregledna glede porabe energije, da lahko uporaba programske opreme pomaga podaljšati življenjsko dobo strojne opreme in zmanjšati vpliv digitizacije na okolje, me to vznemiri. Vedno želim biti del nečesa, kar prispeva k prihodnjim generacijam in Eko KDE služi temu namenu. Verjamem tudi, da mi Eko KDE pomaga na moji poti, da postanem boljši razvijalec programske opreme.

Kaj sem se doslej naučil

Ko sem začel s tem projektom, sem imel tri vprašanja.

Kako lahko vemo, kdaj je programska oprema učinkovita z viri in energetsko učinkovita?

Kako lahko merimo porabo energije programske opreme?

In ali s tem lahko kaj spremenimo?

Ta vprašanja lahko pridejo v vsakomur na misel, ko razmišljajo o ideji o učinkovitosti programske opreme.

Ko uporabljate programsko opremo, vidite le vmesnik, s katerega ste v interakciji. Svojemu telefonu samo povejte, kaj želite, in stvari se bodo čarobno pojavile – ali so to informacije na zaslonu ali paket, dostavljen na vaš prag. Toda tehnologije in infrastrukturo za njimi določajo inženirji programske opreme, ki poskrbijo, da vse to deluje.

Samo predstavljajte si: Kaj, če bi analizirali porabo energije za običajno uporabljeno programsko opremo in jo naredili preglednejšo? Kaj, če bi lahko uporabniki izvedeli, koliko energije potrebuje njihova programska oprema in bi lahko izbrali aplikacijo, ki bi bila morda boljša za okolje? To bi bilo super!!!

Eko KDE je pobudnik projekta energetske učinkovitosti prostega in odprtokodnega programja (FEEP) ter Blauer Engel za FOSS (BE4FOSS), ki trdo delata na teh vprašanjih.

FEEP opozarja, da oblikovanje in izdelava programske opreme pomembno vplivata na porabo energije sistemov, katere sestavni del so. S pravimi orodji je mogoče količinsko opredeliti in si prizadevati za zmanjšanje porabe energije. Ta povečana učinkovitost prispeva k bolj trajnostni rabi energije kot enega od skupnih virov našega planeta.

BE4FOSS podpira FEEP z zbiranjem in širjenjem informacij, povezanih z ekološkim certificiranjem Blauer Engel (BE), uradno okoljsko oznako, ki jo podeljuje nemška vlada. Kot je navedeno na spletni strani Eko KDE, se pridobitev oznake Blauer Engel izvede v 3 korakih: (1) merjenje, (2) analiza, (3) potrjevanje.

1. MERITVE v za to namenjenih laboratorijih kot je npr. KDAB Berlin
2. ANALIZA uporaba statističnih orodij kot npr. OSCAR (Open source Software Consumption Analysis in R)
3. POTRJEVANJE z vlogo poročila o zagotavljanju kriterijev za Modrega angela

V okviru SoK'22 bom pripravil standardne scenarije uporabe za različne urejevalnike besedila, tako da bodo scenariji uporabe lahko uporabljeni v koraku 1 za pridobitev ekološkega certifikata BE.

Kaj sem naredil in kaj bom počel prihodnje tedne

V zadnjih treh tednih sem preizkušal različna orodja za avtomatizacijo, zlasti Actiona, xdotool in GNU Xnee, da se odločim, katero od teh orodij bi bilo najboljše za izvajanje standardnih scenarijev uporabe.

Ob uporabi Actiona sem spisal nekaj dokumentacije, tako da bodo te informacije koristne tudi za vse, ki želijo prispevati k Eko KDE.

Med preizkusom xdotool sem naletel na težavo z uhajanjem pomnilnika. Izvajanje Valgrind na iskanju xdotool je povzročilo več izgub pomnilnika, dodeljenega XQueryTree. Verjetno obstajajo tudi druga mesta, kjer je pomnilnik dodeljen in se kasneje ne sprosti. Nisem opravil obsežnega preverjanja. Kljub temu xdotool daje več nadzora nad sistemom in čeprav z nekaj težavami je to orodje, ki ga ocenjujem kot najbolj koristnega.

Preizkusil sem tudi GNU Xnee, kar se mi je zdelo zanimivo, saj beleži izhod in ga shrani v ločeno datoteko. Prav tako zagotavlja ponovni predvajalnik (angl. replayer), ki ga lahko uporabite za avtomatizacijo nalog pri poljubni želeni hitrosti.

Na koncu sem se odločil, da pripravim vse scenarije uporabe z xdotool, vsaj na začetku, saj večina urejevalnikov besedila uporablja funkcije tipkovnice in ne dejavnost miške in to bo olajšalo prilagajanje skripta različnim sistemom. Vendar nameravam po SoK'22 pripraviti scenarije uporabe z Actiono, da se bom lahko naučil razlik med tema orodjema. V zvezi s tem je v teku tudi razprava o spreminjanju namena standardnih scenarijev uporabe za preizkušanje odzivnosti in učinkovitosti na starejši ali preprostejši strojni opremi.

V prihodnjih tednih se bom dodatno ukvarjal z odpravljanjem težave, ki je znano za Actiona. Težava je v tem, da Actiona emulira vedenje uporabnikov s shranjevanje položaja klikov na podlagi koordinat slikovnih točk, zaradi česar je prenos skripta v drug sistem zahteven. To vprašanje se je pojavilo nedavno npr. pri pripravi standardnega scenarija uporabe za GCompris. Prišel sem do rešitve spreminjanja velikosti zaslona na minimalno ločljivost zaslona in vključno s kodo na začetku skripta Actiona. Kadar koli se skript zažene na drugem sistemu, samodejno spremeni velikost najmanjše ločljivosti, da se ujema s slikovnimi točkami ob izdelavi skripta. To je samo ideja in še ni preizkušena. Za ta poskus si bom vzel čas za rešitev težave s pomočjo skupine GCompris.

Skladišče GitLab, ki vsebuje standardne scenarije uporabe, ki so v teku (trenutno GCompris z uporabo Actiona) je na voljo tukaj.

Krepitev vezi skupnosti (SoK’22)

Hvaležna sem mentorju Josephu P. De Veaugh-Geissu, ker si je vzel čas, da mi pomaga z zagotavljanjem sredstev in smernic med projektom. Udeležil sem se tudi mesečnega srečanja skupnosti Eko KDE Eco 9. februarja 2022, kjer so prof. Dr. Stefan Naumann, Achim Guldner in Christopher Stumpf iz Umwelt Campus Birkenfeld razpravljali o meritvah porabe energije porazdeljenih sistemov in razširitvi meril za dodelitev naziva Blauer Engel. To je bilo zanimivo srečanje, kjer smo razpravljali o težavah pri avtomatizaciji mobilnih aplikacij, kot tudi preizkušanju odjemalcev-strežnikov. Joseph me je predstavil tudi raziskovalcem kampusa Umwelt, ki so merili porabo energije Okularja, Emmanuelu Charruau, ki sodeluje s scenarijem GCompris, in Nicolasu Felli, ki trenutno sodeluje z xdotool za svojo magistrsko delo o porabi energije programske opreme.

Hvala, da ste si vzeli čas za branje te posodobitve. Če želi kdo spremljati tukaj predstavljene zamisli glede prednosti in slabosti različnih orodij za avtomatizacijo pri izvajanju standardnih scenarijev uporabe, obstaja vprašanje na GitLab-u v skladišču BE4FOSS, kjer lahko nadaljujemo razpravo.

Na voljo sem tudi na KDE-jevem primerku Matrixa na drquark:kde.org.

Članek je prispeval Karanjot Singh z dovoljenjem CC-BY-SA-4.0.