Esprint de 2021 de KDE Eco: Detalls de la planificació de la Comunitat per al projecte ecològic de KDE

Dilluns, 7 de febrer de 2022 | Joseph P. De Veaugh-Geiss

Este és el seguiment de l'anunci de l'esprint de KDE Eco publicat en el Dot.

L'11 de desembre de 2021, KDE Eco va celebrar el primer de molts esprints planificats, amb 7 persones presents. L'esprint va ser originalment un esdeveniment en persona per a establir un laboratori de mesura de la comunitat, però el coronavirus tenia altres idees. No obstant açò, la comunitat va desplegar la seua habitual capacitat de recursos, i ens reunirem en línia.

Anunci de l'esprint de 2021 de KDE Eco en les notícies de KDE

En este article de format llarg proporcionaré una visió detallada dels principals temes debatuts a l'esprint i els seus resultats; vegeu també les actes per a més detalls.

Sabíeu que...?

Els debats similars a estos es produïxen mensualment en les reunions de la comunitat el 2n dimecres del mes des de les 19 fins a les 20 hores CET/CEST (hora de Berlín).

Crear un equip de KDE Eco

Actualment KDE Eco consistix en tres projectes relacionats: (i) Free and open Source Energy Efficiency Project (FEEP), (ii) Blauer Engel For FOSS (BE4FOSS) i (iii) Blauer Engel Applications. Cada projecte té el seu propi enfocament particular: FEEP es referix a mesurar el consum d'energia del programari lliure, BE4FOSS se centra en l'organització de la comunitat i la difusió d'informació sobre l'etiqueta ecològica Blauer Engel, i el repositori Blauer Engel Aplicacions acull tots els documents relacionats amb la certificació de programari KDE/lliure amb l'etiqueta ecològica. Fins a l'esprint els tres repositoris dels projectes es van allotjar en diversos espais de nom personals. Ara, els tres repositoris es troben a https://invent.kde.org/teams/eco.

Tindre els projectes davall un equip enllaça amb major claredat estos i els possibles projectes futurs. A més, tindre un espai de noms no personal és més apropiat per a projectes comunitaris. Preneu-vos la llibertat de revisar les activitats de cada projecte a l'espai anterior de l'equip!

Teams > KDE Eco

Completant l'aplicació Blauer Engel per a Okular

Hi ha tres aplicacions KDE el consum d'energia del qual ja s'ha mesurat:Okular,KMail, i Krita. D'estos tres, les aplicacions Blauer Engel per a Okular i KMail han sigut en preparació durant algun temps, i un dels objectius era completar l'aplicació Okular. Estem orgullosos d'anunciar que, després de l'esprint, s'ha presentat la sol·licitud d'Okular i actualment està en revisió per a la certificació. Esperem informació del RAL gGmbH, l'organisme de certificació pel Blauer Engel, en 2 o 3 mesos. La tramesa de KMail seguirà prompte.

Durant una revisió de grup de l'aplicació Okular, els participants van plantejar molts punts interessants. Un punt, per exemple, es va plantejar quan es debatien els criteris de transparència del Blauer Engel (Secció 3.1.3.2). Malte Reißig del Grup de Recerca de l'IASS sobre «Digitalisation and Sustainability Transformations» va destacar com el desenvolupament obert pot afectar positivament alguns dels altres requisits dels criteris de concessió (vegeu este debat), com ara el manteniment a llarg termini i l'autonomia de l'usuari d'un producte de programari. És a dir, els usuaris de programari lliure no sols utilitzen programari passivament, sinó que són encoratjats i capaços d'expressar desitjos per al futur desenvolupament de les aplicacions, i poden participar activament en la planificació de fites. A més, amb un desenvolupament obert, els missatges de comissió poden estar vinculats a problemes específics o errors reportats per una comunitat d'usuaris i desenvolupadors. Amb el programari lliure, una aplicació no és només un producte final, sinó un procés obert que reflectix les necessitats i desitjos dels seus usuaris i les seues comunitats. Amb el FOSS, la comunitat impulsa la direcció del desenvolupament!

Icona d'Okular

Un altre punt estava relacionat amb la distribució de programari lliure i com presenta reptes per al compliment dels criteris de Blauer Engel. Com que el programari lliure normalment distribuïx programari de manera descentralitzada, per a qualsevol aplicació hi ha nombrosos canals de llançament i distribució. Considereu Okular, el qual està empaquetat no només per a Flatpak, sinó també per a la Microsoft Store, per no esmentar les nombroses distribucions de GNU/Linux (per exemple, OpenOpenSuse, Debian). Les diferències en la infraestructura de paquets poden afectar el compliment dels requisits de Blauer Engel, com ara la desinstal·lació, la modularitat, etc.

Les empreses que publiquen programari propietari, normalment amb el desplegament centralitzat dels seus productes, no tindran estos problemes. En la vista d'açò, una possibilitat que el grup ha debatut és certificar només el codi font d'un programa, per tant, romanen neutrals sobre les diferències en com un producte de programari està empaquetat i distribuït. Una altra possibilitat és certificar llançaments específics de distribució, com el de la Microsoft Store. De fet, este últim es podria utilitzar per a propòsits de màrqueting per a arribar fins a usuaris nous i portar-los a la comunitat KDE. Vegeu, per exemple, este debat.

Ens encantaria saber què en penseu. Uniu-vos a la conversa en la nostra llista de correu o en la sala de Matrix o a través del seguidor d'incidències del nostre repositori de GitLab!

Escenaris d'ús estàndard

Un Standard Usage Scenario (SUS, en català Escenari d'ús estàndard) reflectix les funcions típiques d'una aplicació, tenint en compte la freqüència d'estes funcions. Els escenaris d'ús estàndard són fonamentals per a mesurar el consum d'energia d'una peça de programari.

En revisar els registres d'acció SUS per a Okular per a l'aplicació Blauer Engel, es van destacar dos punts importants que milloraran la implementació del SUS quan es mesura en el laboratori. Una va ser l'observació sobre la necessitat de documentar no només les accions, sinó també els objectes d'accions (per exemple, quan s'utilitza un lector de PDF, quin PDF està obert), ja que açò pot influir en el consum d'energia. L'altra és que incloure una acció inactiva és important quan es definix un SUS: l'acció inactiva és realista i pot mostrar que no està passant res quan no hi ha res que suposadament estiga passant.

Es van portar altres temes diversos a la taula virtual. Nicolas Fella, un enginyer de programari al KDAB de Berlín, va expressar el seu interés a comparar dos clients de xat, que van canviar la conversa per a definir escenaris individuals quan es comparaven dues aplicacions amb un ús similar. Un SUS únic limitarà quines funcions de programari es poden provar, però farà que els resultats de les mesures siguen directament comparables. D'altra banda, per a programari client-servidor com un xat o clients de correu electrònic, existix la qüestió del component de xarxa, que per a proves controlades requeriria la creació i el mesurament del consum d'energia d'un servidor. L'antic president de KDE e.V. i l'antic col·laborador de KDE Cornelius Schumacher varen assenyalar que per a les mesures de KMail només es va mesurar el treball de computació en la màquina local. La mesura de la computació no local en el programari de client-servidor és més rellevant que mai en el món actual, i açò està previst actualment per als criteris de la concessió Blauer Engel revisats per al programari.

Pantalla de benvinguda de KMail

Un altre tema debatut va ser definir les accions SUS de manera abstracta per tal d'automatitzar la implementació d'escenaris d'ús amb diferents eines (Actiona, xdotool, KXmlGui, etc.). Un punt important va ser que les eines diferents d'emulació fan coses diferents, les quals podrien presentar reptes a l'automatització del procés. Per exemple, no es pot escriure text quan s'utilitza KXmlGui per a emular, i per tant encara es pot necessitar alguna cosa com xdotool. En una nota relacionada, una altra proposta era estructurar un SUS de tal manera que la creació d'un registre d'acció també es pot automatitzar. A algú de la comunitat li agradaria ajudar a fer front a estos reptes?

A més, el grup va debatre com els escenaris d'ús també podien ser reformulats per a provar la capacitat de resposta i el rendiment general en maquinari antic o de gamma baixa. Quines són les vostres idees?

Sabíeu que estem planejant tindre una marató per a mesurar el consum d'energia de les aplicacions FOSS/KDE a principis de 2022? Quines aplicacions voleu que es preparin els escenaris d'ús estàndard? Compartiu les vostres idees amb nosaltres ací o envieu el vostre SUS al nostre repositori de GitLab!

Sistema de referència reproduïble

Els escenaris d'ús estàndard s'executen en un sistema de referència, i una qüestió important plantejada va ser com tindre un sistema de referència reproduïble. Hi ha diverses capes de sistema que s'han de considerar: maquinari (CPU, disc, RAM, etc.); el SO i els serveis del SO com el gestor d'activitats en Plasma, així com les seues configuracions; i la configuració de l'aplicació provada, així com qualsevol aplicació relacionada (per exemple, Akonadi per a les aplicacions PIM). D'una banda, és necessari tindre un entorn controlat per a poder interpretar els resultats; d'altra banda, és desitjable disposar de mesures que reflectisquen entorns informàtics reals, fins i tot sorollosos, per a comprendre el consum d'energia en el món real del programari. Al cap i a la fi, si s'han de controlar els entorns de computació natural o si s'han d'utilitzar les dades, i açò diferix per als investigadors, els desenvolupadors, els auditors de l'etiqueta ecològica, les empreses, etc.

Per exemple, per als desenvolupadors interessats en realitzar proves unitàries d'eficiència energètica o a obtindre el segell Blauer Engel, serà necessari tindre entorns clarament especificats. Llavors, quines són les maneres còmodes i ràpides de portar el sistema a un estat conegut? Es van discutir tres idees: (i) prendre instantànies d'un sistema de fitxers (per exemple, Snapper), (ii) netejar la memòria cau del sistema i (iii) reemplaçar els fitxers de configuració. Si teniu altres idees feu-nos saber ací!

Per a entorns del món real, una proposta, potencialment controvertida, és registrar el rendiment del maquinari i l'ús d'energia elèctrica mentre que la gent utilitza els seus ordinadors personals. Cap voluntari?

Eixida de dades

Quan es mesura el consum d'energia en un laboratori, en particular per a l'ecocertificació de Blauer Engel, es poden generar tres tipus de fitxers de dades: (i) un fitxer de registre d'accions (vegeu més amunt pel que fa a l'automatització d'estos fitxers de registre), (ii) dades de rendiment del maquinari (CPU, RAM, etc.), i (iii) ús d'energia elèctrica. Com que en alguns casos les dades d'eixida hauran de ser autodefinides (per exemple, registres de codis de temps en scripts de «xdotool»), cal considerar com haurien de ser les dades abans de mesurar-les en el laboratori.

S'han plantejat diverses qüestions relacionades amb les dades: S'ha d'estandarditzar l'eixida de dades per a harmonitzar l'eixida cap a través de campanyes de mesurament, o és senzillament suficient per a publicar les dades arreplegades en un format accessible (per exemple, com a fitxers .csv com es fa al repositori FEEP)? Quina precisió del codi de temps es necessita (per exemple, segons o fraccions de segons)? Estes preguntes seguixen obertes per ara, però el grup va decidir que necessitem un resum dels dispositius/scripts compatibles amb FOSS (per exemple l'script d'Achim Guldner](https://gitlab.rlp.net/a.guldner/mobiles-messgerat) i els kits d'eines d'anàlisi de Gude Expert Power «Control» 1202 Series) i eines (per exemple, eines d'anàlisi estadística com OSCAR, R, Julia, Octave, PSPP, NumPy) utilitzades per a mesures i anàlisi, que actualment està en curs.

Dispositius de mesura d'electricitat

Els criteris de Blauer Engel es referixen a dos comptadors elèctrics (PM, Power Meter) en particular: Janitza UMG 604 i Gude Expert Power «Control» 1202. Estos dispositius no són barats. En 2020, el col·laborador de KDE Volker Krause va analitzar un endoll de 8 euros i va escriure sobre ell. Tal com es descriu en l'article del blog, estos endolls elèctrics de baix cost poden obtindre una taxa de mostreig de fins a 200 ms. Açò va portar a la idea d'utilitzar comptadors elèctrics barats en laboratoris domèstics de baix pressupost. Per a este fi, finalment serà útil comparar els resultats dels comptadors elèctrics professionals amb els econòmics per a veure com es comparen. Algú de la comunitat estaria interessat en açò?

De l'article del blog de Volker Krause:«"Mesura d'exemple (interval de mostra de 200 ms, sense filtre): el cursor del ratolí es mou en mostres entre 100 i 150, amb un pic mentre es passa per damunt d'una entrada de la barra de tasques.»

Una altra manera de mesurar el consum elèctric va vindre del col·laborador de KDE David Hurka, qui té una proposta per a sensors d'alimentació SPI USB per a proporcionar una alternativa de resolució més alta als comptadors elèctrics que mesuren en la presa de corrent.

Problemes oberts dels laboratoris de mesura

Diversos altres temes es van discutir relacionats amb el consum elèctric i les mesures de laboratori. Encara que en tots els casos no es van prendre decisions definitives, moltes d'estes qüestions obertes seran importants per a considerar en el futur.

• Idea d'una eina favorable a la comercialització per a cridar l'atenció sobre el consum elèctric del programari.
  • Per exemple, un botó «Eco» per a l'eficiència energètica/mètrica de petjada de carboni (conferir la petjada de carboni dels viatges a l'aplicació Itinerary).
  • Cal tindre en compte que hi ha una funcionalitat similar proporcionada per PowerTop, encara que els problemes oberts romanen (quan és segur activar-ho per a evitar la pèrdua de dades, la màquina es congela?).
• Quan superen els inconvenients als beneficis d'acceptar el maquinari més antic?
  • Convidem als investigadors que treballen en açò per a debatre amb la comunitat de KDE Eco.
• Col·laboració futura:
  • Esprint conjunt amb projectes relacionats (per exemple, SoftAWERE)? (Potser és d'interés per al lector: Max Schulze de SoftAWERE/SDIA presentat a la reunió mensual de KDE Eco el gener de 2022, el qual es pot llegir a les actes d'ací).
  • Voleu debatre sobre estos temes i altres amb més comunitats relacionades (Bits & Bäume, Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung, etc.)?

Conclusió

L'esprint en línia va ser una oportunitat perfecta per a unir la comunitat i fer avançar el projecte KDE Eco, especialment quan ens preparem per al laboratori comunitari de mesura que se celebrarà a la KDAB de Berlín i la primera de moltes maratons de mesura (planificada per a principis de 2022)! L'èxit d'estos esdeveniments depén abans de res de la comunitat, així que permeteu-nos donar les gràcies de tot cor a tots els que es van unir a la conversa. Esperem que la comunitat cresca el 2022! A més, no hauríem pogut fer el que fem sense la col·laboració de KDE e.V. així com BMU/UBA, que col·labora financerament amb el projecte BE4FOSS (encara que només l'editor és responsable del contingut d'esta publicació).

Anunci de finançament

El projecte BE4FOSS ha sigut finançat per l'Agència Federal del Medi Ambient i el Ministeri Federal de Medi Ambient, Conservació de la Naturalea, Seguretat Nuclear i Protecció del Consumidor (BMUV¹). Els fons estan disponibles per una resolució del Bundestag alemany.

L'editor és el responsable del contingut d'esta publicació.

¹ Els logotips oficials de BMUV i UBA només s'envien sol·licitant-ho a: verbaendefoerderung@uba.de