KDE Eko 2021 spurt: Information om gemenskapens planering för KDE:s ekologiska projekt

måndag, 7 februari 2022 | Joseph P. De Veaugh-Geiss

Det här är en uppföljning av kungörelsen om KDE Eko spurt inskickad till Dot.

Den 11:e december 2021 höll KDE Eko den första av många planerade spurter, men sju deltagare. Spurten var ursprungligen avsedd att vara ett evenemang med personer på plats för att skapa ett gemenskapslabb, men Corona hade andra idéer. Trots det visade gemenskapen sin vanliga rådighet, och vi träffades på nätet istället.

Tillkännagivande av KDE Eko 2021 spurt på KDE:s nyheter

I den här utökade artikeln ger jag en detaljerad översikt av huvudpunkterna som diskuterades på spurten och deras resultat. Se också protokollet för ytterligare information.

Visste du?

Liknande diskussioner inträffar varje månad på våra gemenskapsmöten den andra onsdagen i månaden från kl. 19 - 20 CET/CEST (svensk tid).

Skapa en KDE Eko-grupp

KDE Eko består för närvarande av tre relaterade projekt: (i) Projekt för energieffektivitet med fri och öppen källkod (FEEP), (ii) Blauer Engel för FOSS (BE4FOSS) och (iii) Blauer Engel-program. Varje projekt har sitt eget speciella fokus: FEEP ägnar sig åt att mäta energiförbrukningen för fri programvara, BE4FOSS fokuserar på gemenskapens organisation och att sprida information om Blauer Engel miljömärket, och Blauer Engel programarkivet hanterar alla nödvändiga dokument för att certifiera KDE/Fri programvara enligt miljömärket. Till spurten lagrades de tre projektarkiven med diverse personliga namnrymder. Nu finns alla tre arkiven på https://invent.kde.org/teams/eco.

Att ha projekten i en grupp länkar dessa och eventuella framtida projekt tydligare. Dessutom är det lämpligare att inte ha personliga namnrymder för gemensamma projekt. Ta gärna en titt på aktiviteterna i varje projekt i grupputrymmet ovan.

Grupper > KDE Eko

Slutföra Blauer Engel-ansökningen för Okular

Det finns tre KDE-program vars energiförbrukning redan har uppmätts: Okular, Kmail och Krita. Av dessa tre, har förberedelse av ansökningarna till Blauer Engel för Okular och Kmail pågått en tid, och ett mål var att slutföra ansökningen för Okular. Vi är stolta över att kunna tillkännage att Okulars ansökan har skickats in efter spurten, och håller för närvarade på att granskas för certifiering. Vi förväntar oss kommentarer från RAL gGmbH, utfärdande organisation för Blauer Engel, inom 2 - 3 månader. Ansökan för Kmail följer snart.

Under en granskning av programmet Okular av gruppen, tog deltagarna upp många intressanta punkter. En punkt, dök exempelvis upp när transparenskriterierna hos Blauer Engel diskuterades (Avsnitt 3.1.3.2). Malte Reißig från forskningsgruppen IASS om "Digitaliserings- och hållbarhetsomvandlingar", belyste hur öppen utveckling kan påverka vissa övriga krav i certifieringskriterierna positivt (se följande diskussion), såsom en programvaruprodukts långtidsunderhåll och användarautonomi. Det vill säga, användare av fri programvara använder inte bara passivt programvara, utan de uppmuntras att och kan uttrycka önskemål om framtida utveckling av program, och kan aktivt delta i planeringen av milstolpar. Dessutom, med öppen utveckling kan incheckningsmeddelanden länkas till specifika problem eller fel som rapporteras av en användar- och utvecklargemenskap. Med fri programvara är ett program inte bara en slutprodukt, utan en öppen process som reflekterar behoven och önskemålen hos dess användare och deras gemenskaper. Med fri och öppen programvara driver gemenskapen utvecklingsriktningen!

Okulars ikon

En annan punkt hörde ihop med distributionen av fri programvara och hur den leder till utmaningar när det gäller att uppfylla kriterierna i Blauer Engel. Eftersom fri programvara typiskt distribueras på ett decentraliserat sätt, finns det ett flertal utgivnings- och distributionskanaler för ett visst program. Betrakta Okular, som inte bara är paketerade för Flatpak, utan också Microsoft Store, för att inte nämna ett otal GNU/Linux-distributioner (t.ex. OpenSuse, Debian). Skillnader i paketeringsinfrastrukturen kan påverka hur kraven i Blauer Engel, såsom avinstallerbarhet, modularitet, etc., uppfylls.

Företag som ger ut sluten programvara, oftast med centraliserad spridning av produkterna, har inte dessa problem. I ljuset av detta, är en möjlighet som gruppen diskuterade att bara certifiera ett programs källkod, och därigenom förbli neutral när det gäller skillnader i hur en programvaruprodukt paketeras och distribueras. En annan möjlighet är att certifiera distributionsspecifika utgåvor, såsom den för Microsoft Store. I själva verket skulle det senare kunna användas i marknadsföringssyfte för att nå nya användare och leda dem in i KDE-gemenskapen: se t.ex. följande diskussion.

Vi skulle gärna vilja veta vad du tycker. Gå med i konversationen på vår e-postlista eller Matrix-rum, eller via problemuppföljningen i våra GitLab-arkiv.

Vanliga användarscenarier

Ett Vanligt användarscenario (VAS) reflekterar de typiska funktionerna hos ett program, med hänsyn tagen till hur frekventa funktionerna är. Vanliga användarscenarier är centrala för att mäta energiförbrukningen för en viss programvara.

Vid granskning av VAS åtgärdsloggarna för Okulars ansökan till Blauer Engel, framgick två viktiga punkter som kan förbättra implementeringen av VAS vid mätningar i labbet. En var observationen om behovet av att inte bara dokumentera åtgärder utan också målet för åtgärder (t.ex. när en PDF-läsare används, vilken PDF som öppnas), eftersom det kan påverkar energianvändningen. Den andra var att det är viktigt att inkludera viloåtgärder när vanliga användarscenarier definieras: viloåtgärder är både realistiska och kan visa att ingenting händer när det är meningen att ingenting ska hända.

Flera andra problem lades fram på det virtuella bordet. Nicolas Fella, en programvaruingenjör på KDAB Berlin, uttryckte intresse av att jämföra två chattprogram, vilket ledde konversationen till att definiera enstaka scenarier vid jämförelse av två program med liknande användning. Ett enstaka VAS begränsar vilka programfunktioner som kan testas, men det gör resultaten från mätningarna direkt jämförbara. Dessutom, för klient-server programvara såsom ett chatt- eller e-postprogram, finns problemet med nätverkskomponenten, vilket skulle kräva att ställa in och mäta en servers energiförbrukning för kontrollerad testning. Tidigare KDE e.V. president and mångårig bidragsgivare till KDE, Cornelius Schumacher påpekade att för mätningarna av Kmail mättes bara beräkningsarbetet på den lokala datorn. Att mäta icke-lokala beräkningar i klient-server programvara är mer relevant än någonsin i dagsläget, och det planeras för närvarande i de reviderade programvarukriterierna för Blauer Engel certifikatet.

Välkomstskärmen i Kmail

Ett annat ämne som diskuterades var att definiera åtgärderna i vanliga användarkriterier abstrakt, för att kunna automatisera implementeringen av användarscenarier med olika verktyg (Actiona, xdotool, KXmlGui, etc.). En viktig punkt är att olika emuleringsverktyg gör olika saker, vilket kan leda till utmaningar vid automatisering av processen. Man kan exempelvis inte skriva in text när KXmlGui används för emulering, och därmed kan någonting i stil med xdotool ändå behövas. På liknande sätt, var ett annat förslag att strukturera ett VAS på ett sådant sätt att skapa en åtgärdslogg också kan automatiseras. Skulle någon i gemenskapen vilja hjälpa till att ta itu med dessa utmaningar?

Dessutom diskuterade gruppen hur användarscenarier också kan återanvändas för att mäta svarstider och allmän prestanda på maskinvara som är äldre eller har lägre prestanda. Har du några idéer?

Visste du att vi planerar att ha ett mät-maraton för att mäta energiförbrukningen hos FOSS/KDE-program tidigt under 2022? Vilka program skulle du vilja se vanliga användningsscenarier förberedda för? Dela med dig av dina idéer till hos här eller checka in din VAS i vårt GitLab-arkiv.

Replikerbart referenssystem

Vanliga användarscenarier körs på ett referenssystem, och en viktig punkt som togs upp var hur man kan få ett replikerbart referenssystem. Det finns flera systemlager att ta hänsyn till: maskinvara (processor, disk, minne, etc.), operativsystemet och operativsystemtjänsterna såsom aktivitetshanteraren i Plasma, samt deras inställningar, och det testade programmets inställning samt eventuella relaterade program (t.ex. Akonadi för personliga informationshanteringsprogram). Å ena sidan är det nödvändigt att ha en kontrollerad miljö för att kunna tolka resultaten, å andra sidan är det önskvärt att ha mätningar som reflekterar verkliga, kanske till och med störiga, datormiljöer, för att förstå programvarans verkliga energiförbrukning. I slutändan, om vi har kontrollerade eller naturliga beräkningsmiljöer beror på vad data ska användas till, och det skiljer sig för forskare, utvecklare, miljömärkningsgranskare, företag, etc.

Exempelvis för utvecklare som är intresserade av att utföra energieffektiva enhetstester eller erhålla Blauer Engel-certifikatet, är det nödvändigt att ha tydligt specificerade miljöer. Så vad är bekväma och snabba sätt att få systemet till ett känt tillstånd? Tre idéer diskuterades: (i) ta en ögonblicksbikld av filsystemet (t.ex. Snapper), (ii) tömma systemcachen, och (iii) ersätta inställningsfiler. Om du har andra idéer, låt oss få veta det här.

För verkliga miljöer, är ett (möjligtvis kontroversiellt) förslag att logga maskinvarans prestanda och elektriska effektanvändning medan folk använder sina persondatorer. Några frivilliga?

Datautskrift

Vid mätning av energiförbrukning i ett labb, i synnerhet för Blauer Engel miljömärkning, kan tre typer av datafiler genereras: (i) en loggfil med åtgärder (se ovan rörande automatisering av sådana loggfiler), (ii) prestandainformation för maskinvara (processor, minne, etc.), och (iii) användning av elektrisk kraft. Eftersom utdata i vissa fall måste vara självdefinierad (t.ex., tidsstämplad loggning i xdotool-skript), är det nödvändigt att överväga hur data ska se ut innan mätningar i labbet.

Flera problem lyftes fram avseende data: Ska utdata vara standardiserat för att harmonisera data över flera mätomgångar, eller är det nog att helt enkelt publicera data samlat i ett tillgängligt format (exempelvis som .csv-filer som in FEEP-arkivet)? Vilken noggrannhet krävs för tidsstämplar (t.ex. sekunder eller bråkdelar av sekunder)? Frågorna förblir obesvarade för närvarande, men gruppen bestämde att vi behöver en översikt av FOSS-kompatibla enheter/skript (t.ex. Achim Guldners skript för Gude Expert Power Control 1202-serien) och verktygslådor (t.ex. statistiska analysverktyg såsom OSCAR, R, Julia, Octave, PSPP, NumPy) använda för mätningar och analys, som för närvarande är under arbete.

Effektmätare

Kriterierna i Blauer Engel hänvisar till till två effektmätare (EM), i synnerhet: Janitza UMG 604 och Gude Expert Power Control 1202. Apparaterna är inte billiga. Under 2020, bröt sig den mångårige bidragsgivaren till KDE, Volker Krause, in i en 80-kronors strömkontakt och skrev om det. Som beskrivs i bloggartikeln, kan dessa billiga strömkontakter uppnå en samplingsfrekvens på upp till 200 ms. Det gav idén att använda billiga effektmätare i hemmalabb med låg budget. För detta ändamål blir det till sist användbart att jämföra resultaten från professionella effektmätare med budgetmätare för att se hur de stämmer överens. Skulle någon i gemenskapen vara intresserad av att göra det?

Från Volker Krauses bloggartikel: "Exempelmätning (200 ms samplingsintervall, inget filter): muspekaren flyttas mellan sampling 100 och 150, med en topp när den hålls över en post på aktivitetsraden."

Ett annat sätt att mäta energiförbrukning kom från KDE:s bidragsgivare David Hurka, som har ett förslag på en USB SPI-effektsensor för att erbjuda ett alternativ med högre upplösning än effektmätare som mäter vid vägguttaget.

Öppna frågor gällande mätlabb

Flera andra frågor relaterade till energiförbrukning och labbmätningar diskuterades. Även om slutliga beslut inte togs i alla fall, blir många av de öppna frågorna viktiga att ta hänsyn till i framtiden.

• En idé om ett marknadsvänligt verktyg för att fästa uppmärksamheten på energiförbrukningen hos programvara.
  • Exempelvis en 'Eko'-knapp för mätning av energieffektivitet och koldioxidavtryck (jfr koldioxidavtryck i reseplaneringsprogram).
  • Observera att liknande funktioner redan tillhandahålls av PowerTop, även om det finns kvarvarande problem (när är det säkert att aktivera för att undvika dataförlust, datorn hänger sig?).
• När överväger nackdelarna över fördelarna vid stöd av äldre maskinvara?
  • Låt oss bjuda in forskare som arbetar med det för att diskutera med KDE Eko-gruppen.
• Framtida samarbete:
  • Gemensam spurt med relaterade projekt (t.ex. SoftAWERE)? (Kanske av intresse för läsaren: Max Schulze från SoftAWERE/SDIA gjorde en presentation på KDE Ekos månatliga möte i januari 2022, och du kan läsa protokollet från det här.)
  • Diskutera ovanstående ämnen med andra relaterade organisationer (Bits & Bäume, Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung, etc.)?

Avslutning

Nätspurten var ett underbart tillfälle att samla gemenskapen och föra KDE Eko-projektet framåt, i synnerhet då vi förbereder oss för gemenskapens mätlabb som kommer att hållas på KDAB Berlin och det första av många mät-maratonloppet (planerat för tidigt under 2022). Hur lyckade sådana evenemang är beror i första hand på gemenskapen, så låt oss skicka ett varmt tack till alla som deltog i konversationen. Vi ser fram emot att få gemenskapen att växa under 2022. Dessutom skulle vi inte kunna göra det vi gör utan stöd från KDE e.V. samt BMU/UBA, som stöder BE4FOSS-projektet ekonomiskt (även om utgivaren är ensamt ansvarig för innehållet i denna publikation).

Finansieringsanmärkning

Projektet BE4FOSS grundades av det federala miljödepartementet och det federala ministeriet för miljö, naturvård, kärnkraftssäkerhet och konsumentskydd (BMUV¹). Medel tillhandahålls genom beslut av den Tyska Förbundsdagen.

Utgivaren är ansvarig för innehållet i den här publikationen.

1 Officiella logotyper för BMUV och UBA skickas bara på begäran hos: verbaendefoerderung@uba.de