Seizoen van KDE 2022 met KDE Eco
I ben erg dankbaar voor het KDE-team voor het mij uitnodigen om deel te nemen aan deze verbazingwekkende gemeenschap via hun jaarlijkse programma Seizoen van KDE.
Info over mijzelf
Ik ben Karanjot Singh. Ik ben een eerstejaars computer science engineering undergraduate van Jaypee Institute of Information Technology, Noida, India. Ik heb gewerkt als een ontwikkelaar met verschillende Vrije en Open-source software (FOSS) programma's zoals Kharagpur Winter of Code in 2021 (KWoC’21). Dit zal echter mijn eerste keer zijn om bij te dragen aan een project met zo'n grote gemeenschap. Ik ben erg gepassioneerd over FOSS, problemen oplossen en procesefficiëntie verbeteren. Ik vind het fijn nieuwe technologieën te ontdekken en dingen bouwen voor sociaal nuttige zaken. Ik geloof ook dat bijdragen aan FOSS de beste manier is om ervaring te vergaren in ontwikkelen van software.
Waar ik aan zal gaan werken
Als onderdeel van een pionierend project voor onderhoudbaarheid, KDE Eco heeft het doel de energieconsumptie van KDE/Vrije software te meten en te omlaag te brengen. Dit vereist het emuleren van gebruikersgedrag, wat bereikt kan worden door het plannen en scripts maken van Standaard gebruiksscenario's. I zal scripts maken voor Standaard gebruiksscenario's voor verschillende toepassingen, met een focus op gewoonlijk gebruikte tekstbewerkers zoals Kate, KWrite, Vim, Nano, Emacs, Calligra Words, and LibreOffice. Ik zal deze gebruiksscenario's met een van de vele beschikbare emulatiehulpmiddelen voorbereiden. Hieronder is mijn SoK’22 tijdlijn:
Motivatie achter het werken aan het KDE Eco Project
Ik denk dat KDE Eco een erg goed initiatief is voor het ontwikkelen van hulpbronnen en energie-efficiënte Vrije software. Wanneer iemand FOSS gebruikt en ontdekt dat de software transparant is over zijn energieconsumptie, dat de software gebruiken kan helpen de leeftijd van hardware te verlengen en de omgevingsinvloed van digitalisatie verminderen, dan windt dat mij op. Ik wil altijd deelnemen aan iets dat bijdraagt aan toekomstige generaties en KDE Eco dienst dat doel. Ik geloof ook dat KDE Eco me helpt op mijn weg naar het worden van een betere ontwikkelaar van software.
Wat ik tot nu toe heb geleerd
Toen ik begon met dit project had ik drie vragen.
Hoe kunnen we weten wanneer software efficient is op hulpbronnen en energie?
Hoe kunnen we de de energieconsumptie van software meten?
En maakt het een verschil?
Deze vragen bedenkt iedereen bij het denken over het idee van efficiency van software.
Wanneer u software gebruikt is wat u ziet alleen het interface waarmee u interactie hebt. Vertel uw telefoon wat u wilt en dingen zullen als magie verschijnen — af dat nu de informatie op het scherm is of een pakket geleverd op uw deurmat. Maar de technologieën en infrastructuur er achter worden bepaald door software engineers die dit alles laten werken.
Bedenk eens: wat als we de energieconsumptie achter algemeen gebruikte software analyseren en het transparanter maken? Wat als gebruikers te weten kunne komen hoeveel energie hun software vereist en de toepassing kiezen die beter zou kunnen zijn voor de omgeving? Dat zou geweldig zijn!!!
De KDE Eco initiatieven Vrije en open-source energie-efficiency project (FEEP) en Blauer Engel For FOSS (BE4FOSS) werken hard aan deze problemen.
Zoals opgemerkt door FEEP heeft het ontwerp en implementatie van software een significante invloed op de energieconsumptie van de systemen waar het onderdeel van is. Met de juiste hulpmiddelen is het mogelijk energieconsumptie te kwantificeren en omlaag te brengen. Deze verhoogde efficiëntie draagt bij aan een meer duurzaam gebruik van energie als een van de gedeelde hulpbronnen van onze planeet.
BE4FOSS ondersteunt FEEP door verzamelen en verspreiden van informatie gerelateerd aan Blauer Engel (BE) eco-certificatie, het officiële omgevingslabel toegekend door de Duitse overheid. Zoals gemeld op de KDE Eco website, gebeurt het krijgen van het Blauer Engel label in 3 stappen: (1) Meten, (2) Analyseren, (3) Certificeren.
- METEN in gespecialiseerde labs, zoals bij KDAB Berlin
- ANALYSEREN met statistische hulpmiddelen zoals OSCAR (Open source Software Consumption Analysis in R)
- CERTIFICEREN door indienen van het rapport over het vervullen van de criteria voor Blauer Engel
In SoK'22, zal ik Standaard gebruiksscenario's voor verschillende tekstbewerkers voorbereiden zodat de gebruiksscenario's gebruikt kunnen worden in Stap 1 voor het verkrijgen van BE eco-certificatie.
Wat ik heb gedaan & zal doen in de komende weken
In de afgelopen drie weken heb ik verschillende automatiseringshulpmiddelen getest, speciaal Actiona, xdotool en GNU Xnee, om te bepalen welke van deze hulpmiddelen het beste zouden zijn voor implementeren van Standaard gebruiksscenario's.
Bij gebruik van Actiona heb ik enige documentatie geschreven zodat deze informatie ook nuttig zal zijn voor iedereen die wil bijdragen aan KDE Eco.
Bij uitproberen van xdotool, kwam ik een probleem tegen met lekken van geheugen. Valgrind uitvoeren bij xdotool zoeken, kreeg ik meer verloren geheugen toegewezen door XQueryTree. Er zijn waarschijnlijk andere plaatsen waar geheugen is toegewezen en niet later weer vrij gegeven. Ik heb geen extensieve controle gedaan. Niettemin geeft xdotool meer controle over het systeem en zelfs met sommige problemen is dit het hulpmiddel dat ik het meest behulpzaam vond.
Ik heb ook GNU Xnee getest, die voor mij interessant lijkt te zijn omdat het de uitvoer opneemt en het opslaat in een apart bestand. Het biedt ook een afspeler die gebruikt kan worden om taken te automatiseren op elke gewenste snelheid.
Tenslotte heb ik besloten alle gebruiksscenario's voor te bereiden met xdotool, tenminste initieel, omdat de meeste tekstbewerkers toetsenbordfuncties gebruiken in plaats van muisactiviteit en dat zal het gemakkelijker maken het script aan verschillende systemen aan te passen. Echter na SoK'22 plan ik ook gebruiksscenario's te maken met Actiona zodat ik de verschillen tussen deze hulpmiddelen kan leren. In een gerelateerde notitie, is er ook een gaande discussie over Standaard gebruiksscenario's een nieuw doel geven voor testen van respons en prestaties op oudere of mindere hardware.
In de komende weken zal ik bovendien werken aan repareren van een probleem dat bekend is voor Actiona. Het probleem is dat Actiona gebruiksgedrag emuleert door het opslaan van de positie van kliks gebaseerd op pixelcoördinaten, die het overbrengen van een script naar een ander systeem uitdagend maakt. Dit probleem, bijvoorbeeld, verrees recent bij voorbereiden van een standaard gebruiksscenario voor GCompris. Ik stelde een oplossing voor met het scherm te veranderen tot een minimum schermresolutie en de code in te voegen aan het begin van het Actiona-script. Wanneer het script draait in een verschillend systeem, wijzigt het automatisch naar de minimale resolutie om overeen te komen met de pixels bij het maken van het script. Dit is gewoon een idee en is nog niet getest. Ik zal tijd vrijmaken voor deze poging om het probleem met de hulp van het GCompris-team te repareren.
De GitLab opslagruimte die voortgang in Standaard gebruiksscenario's bevat (GCompris gebruikt nu Actiona) is te hier te vinden.
Gemeenschapsbinding ( SoK’22 )
I dank mijn mentor Joseph P. De Veaugh-Geiss voor zijn tijd me te helpen door het leveren van hulpbronnen en leiding tijdens het project. Ik ook de KDE Eco maandelijkse bijeenkomst van de gemeenschap bijgewoond op 9 februari 2022, waar Prof. Dr Stefan Naumann, Achim Guldner en Christopher Stumpf van de Umwelt Campus Birkenfeld een discussie leidde over het meten van de energieconsumptie van gedistribueerde systemen en de criteria voor Blauer Engel prijzen naar heeft uitgebreid. Dit was een interessante bijeenkomst waar we problemen bespraken voor automatiseren met mobiele toepassingen evenals client-server testen. Joseph introduceerde me ook bij de Umwelt Campus onderzoekers die de energieconsumptie van Okular meten; Emmanuel Charruau, die werkt met het GCompris script; en Nicolas Fella, die nu werkt met xdotool voor zijn proefschrift over de energieconsumptie van software.
Dank u voor het nemen van de tijd om deze update te lezen. Als iemand opvolging wil geven aan de hier gepresenteerde ideeën met betrekking op de voor- en nadelen van verschillende automatiseringshulpmiddelen bij het implementeren van Standaard gebruiksscenario's, er is een GitLab issue op de BE4FOSS opslagruimte waar we verder kunnen discussiëren.
Ik ben ook beschikbaar op het Matrix-exemplaar van KDE op drquark:kde.org.