KDE Eco 2021 Sprint: Details over de planning van de gemeenschap voor het Ecologische Project van KDE

Dit is de opvolging van de KDE Eco Sprint aankondiging gepost op The Dot.

Op 11 december 2021 hield KDE Eco de eerst van vele geplande Sprints, met 7 aanwezige personen. De Sprint was oorspronkelijk bedoeld om een in-persoon bijeenkomst te zijn om een meetlaboratorium van de gemeenschap op te zetten, maar Corona had andere ideeën. Niettemin, gebruikte de gemeenschap zijn gebruikelijke vindingrijkheid en in plaats daarvan hebben we elkaar online ontmoet.

KDE Eco 2021 Sprint aankondiging op KDE News

In deze langevormpost zal ik een gedetailleerd overzicht geven van de besproken hoofdzaken op de Sprint en hun resultaten; zie ook het verslag voor verdere details.

Wist u dat?

Discussies zoals deze vinden maandelijks plaats in onze samenkomsten van de gemeenschap op de tweede woensdag van de maand van 19u-20u CET/CEST (Berlijnse tijd).

Een KDE Eco team creëren

KDE Eco bestaat nu uit drie gerelateerde projecten: (i) Free and open source Energy Efficiency Project (FEEP), (ii) Blauer Engel For FOSS (BE4FOSS) en (iii) Blauer Engel Applications. Elk project heeft zijn eigen specifieke focus: FEEP houdt zich bezig met het meten van de energieconsumptie van Free Software, BE4FOSS is gefocust op organiseren van een gemeenschap en informatie verspreiden over het Blauer Engel eco-label en de opslagruimte Blauer Engel toepassingen host alle documenten gerelateerd aan certificering van KDE/Free Software met het eco-label. Tot de Sprint waren de drie opslagruimten voor de projecten gehost op verschillende persoonlijke naamruimten. Nu zijn alle drie opslagruimten te vinden op https://invent.kde.org/teams/eco.

De projecten onder een team te hebben koppelt deze en mogelijk toekomstige projecten aan elkaar. Verder is het hebben van een niet-persoonlijke naamruimte meer gepast voor projecten van gemeenschappen. Voel u vrij om de activiteiten van elk project op de bovenstaande teamruimte te bekijken!

Teams > KDE Eco

De toepassing Blauer Engel voor Okular voltooien

Er zijn drie KDE toepassingen waarvan de energieconsumptie al is gemeten: Okular, KMail en Krita. Van deze drie zijn al enige tijd de Blauer Engel toepassingen voor Okular en KMail in voorbereiding en een doel was om de toepassing Okular te voltooien. We zijn er trots op om dat aan te kondigen, na de Sprint, dat de toepassing van Okular is ingediend en nu beoordeeld wordt voor certificatie. We verwachten terugkoppeling van RAL gGmbH, het lichaam dat de Blauer Engel toekent, binnen 2-3 maanden. Het indienen van KMail zal spoedig volgen.

Tijdens een groepsbeoordeling van de toepassing Okular, hebben deelnemers vele interessante punten ingebracht. Een punt, bijvoorbeeld, kwam op bij het bespreken van transparantiecriteria van de Blauer Engel (Section 3.1.3.2). Malte Reißig van de IASS Research Group on "Digitalisation and Sustainability Transformations" verhelderde hoe open ontwikkeling een positief effect heeft op enige van de andere vereisten van de toekenningscriteria (zie deze discussie), zoals de lange-termijn onderhoudbaarheid en gebruikersautonomie van een softwareproduct. Dat wil zeggen, gebruikers van Vrije Software gebruiken niet alleen software passief, maar ze worden aangemoedigd en in staat om hun wensen te uiten voor de toekomstige ontwikkeling van toepassingen en kunnen actief meedoen in de planning van mijlpalen. Bovendien, met open ontwikkeling, commitberichten kunnen gekoppeld worden aan specifieke problemen of bugs gerapporteerd door een gemeenschap van gebruikers en ontwikkelaars. Met Vrije Software is een toepassing niet alleen een eindproduct, maar een open proces de benodigdheden en wensen weergeeft van zijn gebruikers en hun gemeenschappen. Met FOSS drijft de gemeenschap de richting van de ontwikkeling!

Okular pictogram

Een ander punt was gerelateerd aan de distributie van Vrije Software en hoe het uitdagingen presenteert voor het vervullen van de Blauer Engel criteria. Omdat Vrije Software software typisch op een gedecentraliseerde manier wordt gedistribueerd, voor elk aparte toepassing zijn er vele uitgave- en distributiekanalen. Neem Okular, die een pakket niet alleen voor Flatpak heeft, maar ook Microsoft Store, om niet ook talrijke GNU/Linux distributies te noemen (bijv., OpenSuse, Debian). Verschillen in pakketteninfrastructuur kan het vervullen van de Blauer Engel vereisten beïnvloeden, zoals niet te installeren, modulariteit, etc.

Bedrijven doe software met eigendomsrechten uitgeven, typisch met gecentraliseerd gebruik van hun producten, zullen deze problemen niet hebben. In het licht hiervan, sprak de groep een mogelijkheid om alleen de broncode van een programma te certificeren, waarbij men neutraal blijft over verschillen in hoe een softwareproduct verpakt en gedistribueerd wordt. Een andere mogelijkheid is het certificeren van distributie-specifieke uitgaven, zoals die voor de Microsoft Store. In feite kan deze laatste gebruikt worden voor marketingdoelen om nieuwe gebruikers te bereiken en ze inbrengen in de KDE gemeenschap -- zie, bijv., deze discussie.

We zouden graag willen weten wat u denkt. Doe mee met de conversatie op onze e-maillijst of Matrix room of via de problemenvolger op onze GitLab opslagruimten!

Standaard scenario's voor gebruik

Een Standard scenario's voor gebruik (SUS) reflecteert de typische functies van een toepassing, met rekening houden met de frequentie van gebruik van deze functies. Standard scenario's voor gebruik staan centraal in het meten van de energieconsumptie van een stukje software.

Bij bekijken van de SUS-actielogs voor Okular voor de toepassing Blauer Engel, zijn twee belangrijke punten gemaakt die implementatie van SUS bij meten in het lab om het te verbeteren. Eén was de observatie over de noodzaak om niet alleen acties te documenten maar ook het objecten van acties (bijv., wanneer een pdf-lezer wordt gebruikt, welke pdf er geopend wordt), omdat dit de energieconsumptie kan beïnvloeden. De ander was dat meenemen van nul-actie belangrijk is bij definiëren van een SUS: nul-actie is zowel realistisch en kan tonen dat er niets gebeurt wanneer er niets veronderstelt wordt te gebeuren.

Verschillende andere zaken zijn op de virtuele tafel gelegd. Nicolas Fella, een software engineer bij KDAB Berlijn, toonde interesse in het vergelijken van twee chat-clients, wat de conversatie liet verschuiven naar het definiëren van enkelvoudige scenario's bij vergelijken van twee toepassingen met gelijk gebruik. Een enkele SUS zal welke te testen softwarefunctie beperken, maar het zal resultaten uit de metingen direct vergelijkbaar maken. Bovendien is er, voor client-server-software zoals een chat of e-mailclients, de zaak van de netwerkcomponent zijn, die voor gecontroleerd testen een setup vereist voor het meten van de energieconsumptie van een server. Voormalige president van KDE e.V. en al lang bijdrager aan KDE Cornelius Schumacher wees er op dat voor de KMail metingen alleen het rekenwerk op de lokale machine was gemeten. Meten van niet-lokale computing in client-server software is relevanter dan ooit in de hedendaagse wereld en dit wordt nu gepland voor de herziene Blauer Engel prijscriteria voor software.

Welkomstscherm van KMail

Een ander besproken onderwerp was het abstract definiëren van SUS-acties om de implementatie van gebruiksscenario's te automatiseren met verschillende hulpmiddelen (Actiona, xdotool, KXmlGui, etc.). Een belangrijk punt was dat verschillende hulpmiddelen voor emulatie verschillende dingen doen, die uitdagingen presenteren om het proces te automatiseren. Bijvoorbeeld, men kan geen tekst typen bij gebruik van KXmlGui voor emulatie en dus zoiets als xdotool is misschien nog steeds nodig. Op een gerelateerde opmerking, was een ander voorstel een SUS zo te structureren dat aanmaken van een actielog ook geautomatiseerd kan worden. Zou iemand in de gemeenschap het leuk vinden om deze uitdagingen aan te gaan?

Verder discussieerde de groep over hoe gebruiksscenario's opnieuw van een doel voorzien worden voor het testen van hoe de respons is en algemene prestaties op oudere of minder presterende hardware. Wat zijn uw ideeën?

Weet u dat we are plannen hebben om meet-athon te houden om de energieconsumptie van FOSS/KDE toepassingen te meten in begin 2022? Voor welke toepassingen zou u Standard Usage Scenarios voorbereid willen zien? Deel uw ideeën met ons hier of dien uw SUS in op onze GitLab opslagruimte!

Herhaalbaar referentiesysteem

Standard Usage Scenarios (SUSes) worden gedraaid op een referentie systeem en een belangrijke opgebrachte zaak was hoe een te repliceren referentiesysteem te maken. Er zijn verschillende systeemlagen te overwegen: Hardware (CPU, Disk, Ram, etc.); het OS en OS services zoals de activiteitsbeheerder in Plasma evenals hun configuraties; en de configuratie van de te testen toepassing evenals elke gerelateerde toepassingen (bijv., Akonadi voor PIM toepassingen). Aan de ene kant, is het noodzakelijk om een gecontroleerde omgeving te hebben om in staat te zijn de resultaten te interpreteren; aan de andere kant, is het wenselijk om metingen te hebben die actuele, misschien zelfs computeromgevingen met veel ruis te hebben om te begrijpen wat de energieconsumptie van software is in de echte wereld. Tenslotte zal het hebben van een gecontroleerde of natuurlijke computeromgeving afhangen van waarvoor de gegevens gebruikt zullen worden en dit zal verschillen voor onderzoekers, ontwikkelaars, eco-label auditors, bedrijven, etc.

Bijvoorbeeld, voor ontwikkelaars geïnteresseerd in doen van testen van energie-efficiency van eenheden of het zegel van de Blauer Engel, zal het noodzakelijk zijn om helder gespecificeerd omgevingen te hebben. Dus wat zijn gemakkelijke en snelle manieren om het systeem in een bekende status te brengen? Drie ideeën zijn besproken: (i) nemen van momentopnamen van een bestandssysteem (bijv., Snapper), (ii) wissen van de systeemcache en (iii) vervangen van configuratiebestanden. Als u andere ideeën hebt laat deze hier aan ons weten!

Voor echte omgevingen, is een voorstel, potentieel controversieel, om hardwareprestaties en elektrische energiegebruik te loggen terwijl mensen hun persoonlijke computers gebruiken. Zijn er vrijwilligers?

Gegevensuitvoer

Bij meten van energieconsumptie in een lab, speciaal voor Blauer Engel eco-certificatie, kunnen drie typen gegevensbestanden gegeneerd worden: (i) een logbestand van acties (zie bovenstaand met betrekking tot automatisering van zulke logbestanden), (ii) hardwareprestatiegegevens (CPU, RAM, etc.) en (iii) elektrische energiegebruik. Omdat in sommige gevallen de uitvoergegevens zelfdefinierend zullen moeten zijn (bijv., tijdstempelloggers in xdotool scripts), is het nodig om te bekijken welke gegevens er uit zouden moeten zien zoals voor de meting in het lab.

er zijn een aantal zaken opgekomen gerelateerd aan de gegevens: Zou uitvoer van gegevens gestandaardiseerd moeten zijn om uitvoer over meetcampagnes te harmoniseren of is het voldoende eenvoudig om de verzamelde in een toegankelijk formaat te publiceren (bijvoorbeeld, als .csv-bestanden zoals in de FEEP opslagruimte)? Hoe exact met het tijdstempel zijn (biv., seconden vs. onderdelen van seconden)? Deze vragen bleven op dit moment open, maar de groep besloot dat we een overzicht van de FOSS-compatibele apparaten/scripts nodig hebben (bijv., Achim Guldner's script voor Gude Expert Power Control 1202 Series) en gereedschapskits (bijv., statistische analyse middelen zoals OSCAR, R, Julia, Octave, PSPP, NumPy) gebruikt voor metingen en analyses, die nu in ontwikkeling zijn.

Apparaten voor energiegebruik

De Blauer Engel criteria verwijzen naar twee energiemeters (PM) speciaal: Janitza UMG 604 en Gude Expert Power Control 1202. Deze apparaten zijn niet goedkoop. In 2020, KDE-bijdrager Volker Krause heeft een 8 EUR energieplug gehackt schreef er over. Zoals beschreven in de blogpost, zijn deze goedkope energiepluggen in staat om een samplesnelheid tot 200ms te halen. Dit leidde tot het idee om goedkope energiemeters in thuislabs met een laag budget te gebruiken. Voor dit doel, zal het eventueel nuttig zijn de resultaten van professionele energiemeters te vergelijken met goedkope om te zien hoe vergelijkbaar ze zijn. Zou iemand in de gemeenschap geïnteresseerd zijn om dit te doen?

Uit de Blogpost van Volker Krause: "voorbeeldmeting (200ms sample-interval, geen filter): muiscursor verplaatst tussen samples 100 en 150, met een piek bij zweven boven een taakbalkitem."

Een andere manier om energieconsumptie te meten kwam van de bijdrager aan KDE David Hurka, die een voorstel voor USB SPI energiesensors heeft om alternatief met een hogere resolutie voor energiemeters heeft die bij het stopcontact meet.

Open problemen voor meetlaboratoria

Verschillende andere zaken zijn besproken gerelateerd aan energieconsumptie en metingen in het laboratorium. Hoewel er geen uiteindelijke beslissingen in elke geval zijn gemaakt, veel van deze open zaken zullen belangrijk zijn om mee verder te gaan.

• Idee voor een marketingvriendelijk hulpmiddel om aandacht te trekken naar de energieconsumptie van software.
  • Bijvoorbeeld, een knop 'Eco' voor energie-efficiency/carbon voetprintmeter (cf. carbonvoetprint voor reizen in toepassing Itinerary).
  • Merk op dat een soortgelijke functionaliteit al geleverd wordt door PowerTop, hoewel open problemen blijven (wanneer is het veilig om in te schakelen om verlies van gegevens te vermijden, machine bevriest?).
• Wanneer wegen de bezwaren van onderhoud van oudere hardware zwaarder dan de voordelen?
  • Laten we onderzoekers, die hieraan werken, uitnodigen om dit te bediscussiëren met de KDE Eco gemeenschap.
• Toekomstige samenwerking:
  • Doe mee met Sprint met gerelateerde projecten (bijv., SoftAWERE)? (Misschien interessant voor de lezer: Max Schulze van SoftAWERE/SDIA presenteerde op de maandelijkse bijeenkomst van KDE Eco in januari 2022, waarvan u het verslag hier kunt lezen.)
  • Bespreek de bovenstaande onderwerpen en meer met andere gerelateerde gemeenschappen (Bits & Bäume, Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung, etc.)?

Conclusie

De online Sprint was een prachtige gelegenheid om de gemeenschap bij elkaar te brengen en het KDE Eco project vooruit te brengen, speciaal toen ons voorbereiden op het meetlab van de gemeenschap dat gehouden zal bij KDAB Berlin en de eerste van vele "measure-athons" zal zijn (gepland voor begin 2022)! Het succes van zulke bijeenkomsten hangt eerst en vooral af van de gemeenschap, sta ons dus toe om een hartelijk gevoeld dank u naar iedereen te sturen die mee deed in de conversatie. We kijken uit naar het laten groeien van de gemeenschap in 2022! Bovendien kunnen we niet doen wat we doen zonder de ondersteuning van KDE e.V. evenals BMU/UBA, die het BE4FOSS project financieel ondersteunt (hoewel alleen de uitgever verantwoordelijk is voor de inhoud van deze publicatie).

Financieringsopmerking

Het project BE4FOSS kreeg fondsen van de Federale Omgevingsagency en het Federale Ministerie voor de omgeving, Natuurbeheer, Nucleaire veiligheid en Consumentenbescherming (BMUV¹). De fondsen zijn beschikbaar gesteld door een resolutie van de Duitse Bondsdag.

De uitgever is verantwoordelijk voor de inhoud van deze publicatie.

1 Officiële BMUV en UBA-logo's worden alleen verzonden op een verzoek aan: verbaendefoerderung@uba.de

Artikel bijgedragen door Joseph P. De Veaugh-Geiss onder de licentie CC-BY-4.0.