Gå till innehåll

Season of KDE 2022 med KDE Eko

torsdag, 3 mars 2022 | Karanjot Singh


Jag är mycket tacksam för att KDE-gruppen bjöd in mig att delta i den underbara gemenskapen via deras årliga program Season of KDE.

Om mig

Jag heter Karanjot Singh. Jag är en datorteknikstudent som läser första året av grundutbildningen på Jaypee informationsteknikinstitut i Noida, Indien. Jag har arbetat som utvecklare av diverse program med fri och öppen programvara (FOSS) såsom Kharagpur kodningsvinter 2021 (KWoC’21). Detta är dock första gången jag bidrar till ett projekt i ett så stort samfund. Jag är mycket entusiastisk när det gäller FOSS, problemlösning, och att förbättra processer. Jag tycker om att utforska och lära mig nya teknologier, och bygga saker för socialt användbara ändamål. Jag tror också att bidra till FOSS är bästa sättet att få erfarenhet av programvaruutveckling.

Vad jag kommer att arbeta med

Som en del av ett banbrytande hållbarhetsprojekt, har KDE Eko målet att mäta och dra ner på energiförbrukningen för KDE/Fri programvara. Det kräver att användarbeteende emuleras, vilket kan uppnås genom att planera och skapa skript för vanliga användarscenarier. Jag kommer att skapa skript för vanliga användarscenarier för olika program, med fokus på ofta använda texteditorer som Kate, Kwrite, Vim, Nano, Emacs, Calligra Words och LibreOffice. Jag kommer att bereda användarscenarierna med ett av många tillgängliga emuleringsverktyg. Min SoK’22 tidslinje är nedan:

TIdslinje för KDE 2022 säsong
Figure : TIdslinje för KDE 2022 säsong

Motivationen bakom att arbeta med KDE:s ekoprojekt

Jag tycker att KDE Eko är ett bra initiativ för att utveckla resurs- och energieffektiv fri programvara. När någon använder FOSS och upptäcker att programvaran är transparent när det gäller dess energiförbrukning, och att använda programvaran kan hjälpa till att förlänga maskinvarans livslängd och reducera miljöpåverkan av digitalisering, uppskattar jag det. Jag vill gärna delta i något som bidrar till framtida generationer och KDE Eko uppfyller denna önskan. Jag tror också att KDE Eko hjälper mig på resan mot att bli en bättre programvaruutvecklare.

Vad jag har lärt mig hittills

När jag börjande med projektet hade jag tre frågor.

Hur kan vi veta när programvara är resurs- och energieffektivitet?

Hur kan vi mäta programvarans energiförbrukning?

Och gör det någon skillnad?

Frågorna kan uppstå för vem som helst när man funderar på idén om programvarueffektivitet.

När man använder programvara, är allt man ser gränssnittet som man interagerar med. Tala bara om för din telefon vad du vill så dyker saker och ting magiskt upp, vare sig det är information på skärmen eller ett paket levererat till dörren. Men teknologier och infrastrukturen bakom det bestäms av programvaruingenjörer som gör att allt fungerar.

Användargränssnitt mot komplexa processer
Figure : Användargränssnitt mot komplexa processer

Föreställ dig bara: Vad händer om vi analyserar energiförbrukningen för ofta använd programvara och gjorde den mer transparent? Vad händer om användare kunde ta reda på hur mycket energi deras programvara kräver och kunde välja det program som kan vara bättre för miljön? Det skulle vara suveränt!

Initiativen i KDE Eko projekt för energieffektivitet med fri och öppen källkod (FEEP) och Blauer Engel för FOSS (BE4FOSS) arbetar hårt med problemen.

Som framhålls av FEEP har design och implementering av programvara en betydande inverkan på systemens energiförbrukning. Med rätt verktyg är det möjligt att kvantifiera och reducera energiförbrukning. Den ökade effektiviteten bidrar till en mer hållbar energianvändning, såsom en av vår planets gemensamma resurser.

Tre steg för miljöcertifiering
Figure : Tre steg för miljöcertifiering

BE4FOSS stöder FEEP genom att samla in och sprida information rörande Blauer Engel (BE) miljömärkning, den officiella miljöbeteckningen tilldelad av tyska regeringen. Som nämns på webbplatsen för KDE Eko, erhålls Blauer Engel-beteckningen i tre steg:: (1) Mät, (2) Analysera, (3) Certifiera.

  1. MÄT i dedikerade laboratorier, såsom i KDAB Berlin
  2. ANALYSERA genom att använda statistiska verktyg såsom OSCAR (Open source Software Consumption Analysis in R)
  3. CERTIFIERA genom att skicka in en rapport om hur Blauer Engel kriterierna uppfylls

Under SoK'22 ska jag ta fram vanliga användarscenarier för diverse texteditorer så att användarscenarierna kan användas i Steg 1 för att erhålla BE miljömärkning.

Vad jag har gjort och kommer att göra under kommande veckor

Under de tre senaste veckorna har jag provat diverse automationsverktyg, i synnerhet Actiona, xdotool och GNU Xnee, för att bestämma vilket av verktygen skulle vara bäst för att implementera standardiserade användarscenarier.

Medan jag använda Actiona, skrev jag en viss dokumentation så att informationen också är till nytta för vem som helst som vill bidra till KDE Eko.

Medan jag provade xdotool, stötte jag på ett problem med en minnesläcka. När jag kör Valgrind på xdotool search, får jag mer förlorat minne använt av XQueryTree. Det finns troligen andra ställen där minne används och inte senare frigörs. Jag har inte gjort en uttömmande kontroll. Trots det, ger xdotool bättre kontroll över systemet, och även med en del problem är det verktyget som jag fann mest användbart.

Jag provade också GNU Xnee, som jag tyckte lät intressant eftersom det spelar in utmatningen och lagrar den i en separat fil. Det tillhandahåller också en uppspelningsfunktion som man kan använda för att automatisera uppgifter med vilken hastighet man vill.

Till sist har jag bestämt mig för att skapa alla användarscenarier med xdotool, åtminstone till en början, eftersom de flesta texteditorer använder tangentbordsfunktioner istället för musaktivitet och det gör det enklare att anpassa skriptet till olika system. Dock planerar jag att också skapa användarscenarier med Actiona efter SoK'22, så att jag kan ta reda på skillnaden mellan verktygen. När det gäller en besläktad fråga, pågår också en diskussion om att återanvända vanliga användarscenarier för att prova svarstider och prestanda på äldre eller enklare maskinvara.

Förbereda standardiserade användarscenarier
Figure : Förbereda standardiserade användarscenarier

Under de kommande veckorna kommer jag dessutom att arbeta på att rätta ett känt problem i Actiona. Problemet är att Actiona emulerar användarbeteende genom att lagra positionen för klick baserat på bildpunktskoordinater, vilket kan göra det till en utmaning att överföra ett skript till ett annat system. Exempelvis, uppstod problemet nyligen när ett vanligt användarscenario skapades för GCompris. Jag kom fram till lösningen att ändra storlek på skärmen till minimal skärmupplösning och inkludera koden i början av Actiona-skriptet. Så snart skriptet kör på ett annat system, ändrar det automatiskt till minimal upplösning för att bildpunkterna ska motsvara de som användes när skriptet skapades. Det är bara en idé och jag har inte ännu provat det. Jag kommer att spara tid för detta försök att rätta problemet med hjälp av GCompris-gruppen.

GitLab-arkivet som innehåller pågående standardiserade användningsscenarier (för närvarande GCompris som använder Actiona) finns här.

Lära känna gemenskapen (SoK'22)

Jag är tacksam för att min mentor Joseph P. De Veaugh-Geiss har tagit sig tid att hjälpa mig genom att tillhandahålla resurser och vägledning under projektet. Jag deltog också i KDE Ekos månatliga möte 9 februari 2022, där Prof. Dr Stefan Naumann, Achim Guldner och Christopher Stumpf från Umwelt Campus Birkenfeld ledde en diskussion om att mäta energiförbrukning för distribuerade system och utöka kriterierna för Blauer Engel-certifikatet till dem. Det var ett intressant möte där vi diskuterade problem med automation för mobilapplikationer samt klient-server utprovning. Joseph gav mig också en introduktion till forskarna på Umwelt Campus som mätte energiförbrukningen hos Okular: Emmanuel Charruau, som arbetar med GCompris-skriptet, och Nicolas Fella, som för närvarande arbetar med xdotool för sitt examensarbete om energiförbrukning hos programvara.

Tack för att du har tagit dig tid att läsa den här uppdateringen. Om någon vill följa upp idéerna som presenterats här rörande för- och nackdelarna hos olika automatiseringsverktyg vid implementering av vanliga användarscenarier, finns ett inlägg på GitLab i BE4FOSS-arkivet där vi kan fortsätta diskussionen.

Jag är också tillgänglig på KDE:s Matrix-instans som drquark:kde.org.


Artikel bidragen av med licens CC-BY-SA-4.0.