Esprint de 2021 de KDE Eco: Detalls de la planificació de la Comunitat per al projecte ecològic de KDE
Aquest é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 això, la comunitat va desplegar la seva habitual capacitat de recursos, i ens reunirem en línia.
Anunci de l'esprint de 2021 de KDE Eco a les notícies de KDE
En aquest 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 aquests es produeixen 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 consisteix 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 refereix a mesurar el consum d'energia de 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 dipòsits dels projectes es van allotjar en diversos espais de noms personals. Ara, els tres dipòsits es poden trobar a https://invent.kde.org/teams/eco.
Tenir els projectes sota un equip enllaça amb major claredat aquests i els possibles projectes futurs. A més, tenir 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 l'Okular
Hi ha tres aplicacions KDE el consum d'energia del qual ja s'ha mesurat:Okular,KMail, i Krita. D'aquests tres, les aplicacions Blauer Engel per a l'Okular i el KMail han estat 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 de l'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 del KMail seguirà aviat.
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 aquest 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 reflecteix les necessitats i desitjos dels seus usuaris i les seves comunitats. Amb el FOSS, la comunitat impulsa la direcció del desenvolupament!
Icona de l'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 distribueix programari de manera descentralitzada, per a qualsevol aplicació hi ha nombrosos canals de llançament i distribució. Considereu l'Okular, que 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 aquests problemes. A la vista d'això, 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, aquest últim es podria utilitzar per a propòsits de màrqueting per a arribar a nous usuaris i portar-los a la comunitat KDE. Vegeu, per exemple, aquest debat.
Ens encantaria saber què en penseu. Uniu-vos a la conversa a la nostra llista de correu o a la sala de Matrix o a través del seguidor d'incidències del nostre dipòsit de GitLab!
Escenaris d'ús estàndard
Un Standard Usage Scenario (SUS, en català Escenari d'ús estàndard) reflecteix les funcions típiques d'una aplicació, tenint en compte la freqüència d'aquestes 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 l'Okular per a l'aplicació Blauer Engel, es van destacar dos punts importants que milloraran la implementació del SUS quan es mesura al 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 això pot influir en el consum d'energia. L'altra és que incloure una acció inactiva és important en definir un SUS: l'acció inactiva és realista i pot mostrar que no està passant res quan no hi ha res que suposadament estigui passant.
Es van portar altres temes diversos a la taula virtual. Nicolas Fella, un enginyer de programari al KDAB 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 siguin directament comparables. D'altra banda, per a programari client-servidor com un xat o clients de correu electrònic, existeix 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 del 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 això està previst actualment per als criteris de la concessió Blauer Engel revisats per al programari.
Pantalla de benvinguda del 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, que 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 aquests 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 tenir 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 aquí o envieu el vostre SUS al nostre repositori 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 tenir un sistema de referència reproduïble. Hi ha diverses capes de sistema a considerar: maquinari (CPU, disc, RAM, etc.); el SO i els serveis del SO com el gestor d'activitats en el Plasma, així com les seves 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 tenir un entorn controlat per a poder interpretar els resultats; d'altra banda, és desitjable disposar de mesures que reflecteixin entorns informàtics reals, fins i tot sorollosos, per a comprendre el consum d'energia en el món real de 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 això difereix per als investigadors, els desenvolupadors, els auditors de l'etiqueta ecològica, les empreses, etc.
Per exemple, per als desenvolupadors interessats a realitzar proves unitàries d'eficiència energètica o a obtenir el segell Blauer Engel, serà necessari tenir 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 aquí!
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?
Sortida 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'aquests fitxers de registres), (ii) dades de rendiment de maquinari (CPU, RAM, etc.), i (iii) ús d'energia elèctrica. Com que en alguns casos les dades de sortida 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 al laboratori.
S'han plantejat diverses qüestions relacionades amb les dades: S'ha d'estandarditzar la sortida de dades per a harmonitzar la sortida a través de campanyes de mesurament, o és simplement suficient per a publicar les dades recollides 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)? Aquestes preguntes segueixen 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 és en curs.
Dispositius de mesura d'electricitat
Els criteris de Blauer Engel es refereixen a dos comptadors elèctrics (PM, Power Meter) en particular: Janitza UMG 604 i Gude Expert Power Control 1202. Aquests 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, aquests endolls elèctrics de baix cost poden obtenir una taxa de mostreig de fins a 200 ms. Això va portar a la idea d'usar comptadors elèctrics barats en laboratoris domèstics de baix pressupost. Per a aquest 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 això?
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 sobre d'una entrada de la barra de tasques.»
Una altra manera de mesurar el consum elèctric va venir del col·laborador de KDE David Hurka, que 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'aquestes 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).
- Tingueu en compte que hi ha una funcionalitat similar proporcionada pel 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 treballin en això 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, que podeu llegir a les actes d'aquí).
- Voleu debatre sobre aquests 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 Berlín i la primera de moltes maratons de mesura (planificat per a principis de 2022)! L'èxit d'aquests 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 creixi 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'aquesta publicació).
Anunci de finançament
El projecte BE4FOSS ha estat finançat per l'Agència Federal del Medi Ambient i el Ministeri Federal de Medi Ambient, Conservació de la Naturalesa, Seguretat Nuclear i Protecció del Consumidor (BMUV1). Els fons estan disponibles per una resolució del Bundestag alemany.
L'editor és el responsable del contingut d'aquesta publicació.
1 Els logotips oficials de BMUV i UBA només s'envien sol·licitant-ho a: verbaendefoerderung@uba.de