KDE Eco 2021 Sprint: dettagli sulla pianificazione comunitaria per il progetto ecologico di KDE

Questo è il seguito dell'annuncio di KDE Eco Sprint pubblicato su The Dot.

L'11 dicembre 2021, KDE Eco ha tenuto il primo di molti sprint pianificati, con 7 persone presenti. Lo sprint originariamente doveva essere un evento in presenza per creare un laboratorio di misurazione della comunità, ma il corona virus aveva altre idee. Tuttavia, la comunità ha messo in campo la sua consueta intraprendenza e invece ci siamo incontrati in linea.

• Annuncio dello sprint di KDE Eco 2021 su KDE News *

In questo lungo commento fornirò una panoramica dettagliata delle principali questioni discusse allo sprint e dei loro risultati; vedere anche le minute per ulteriori dettagli.

Lo sapevi?

Discussioni simili a queste si svolgono mensilmente durante gli incontri della nostra comunità il secondo mercoledì del mese dalle 19:00 alle 20:00 CET/CEST (ora di Berlino).

Creazione di una squadra KDE Eco

KDE Eco è attualmente costituito da tre progetti correlati: (i) Progetto di efficienza energetica (FEEP) gratuito e open source, (ii) Blauer Engel For FOSS (BE4FOSS) e (iii) Blauer Engel Applications. Ogni progetto ha il suo obiettivo particolare: FEEP si occupa della misurazione del consumo energetico del Software Libero, BE4FOSS si concentra sull'organizzazione della comunità e sulla diffusione di informazioni sull'etichetta ecologica Blauer Engel e il deposito delle applicazioni Blauer Engel ospita tutti i documenti relativi alla certificazione di KDE/software libero con il marchio di qualità ecologica. Fino allo sprint i tre depositi per i progetti erano ospitati in vari spazi personali. Ora, tutti e tre i depositi sono disponibili su https://invent.kde.org/teams/eco.

Avere i progetti in una squadra collega più chiaramente questi e possibili progetti futuri. Inoltre, avere uno spazio non personale è più appropriato per i progetti della comunità. Sentiti libero di controllare le attività di ogni progetto nello spazio della squadra!

Teams > KDE Eco

Completamento dell'applicazione Blauer Engel per Okular

Esistono tre applicazioni KDE il cui consumo energetico è già stato misurato: Okular, [KMail](https: //invent.kde.org/teams/eco/feep/-/tree/master/measurements/kmail) e Krita. Di queste tre, le applicazioni Blauer Engel per Okular e KMail sono in preparazione da qualche tempo e un obiettivo era completare l'applicazione di Okular. Siamo orgogliosi di annunciare che, a seguito dello sprint, la domanda di Okular è stata presentata ed è attualmente in fase di revisione per la certificazione. Aspettiamo un riscontro da RAL gGmbH, l'ente aggiudicatore per la Blauer Engel, entro 2-3 mesi. L'invio di KMail seguirà presto.

Durante una revisione di gruppo dell'applicazione Okular, i partecipanti hanno sollevato molti punti interessanti. Un punto, ad esempio, è emerso quando si è discusso dei criteri di trasparenza della Blauer Engel (Sezione 3.1.3.2). Malte Reißig del gruppo di ricerca IASS su «Digitalizzazione e trasformazioni di sostenibilità» ha evidenziato come lo sviluppo aperto possa influenzare positivamente alcuni degli altri requisiti dei criteri di aggiudicazione (vedi questa discussione), come la manutenibilità a lungo termine e l'autonomia dell'utente di un prodotto software. Cioè, gli utenti del Software Libero non solo usano passivamente il software, ma sono incoraggiati e in grado di esprimere desideri per lo sviluppo futuro di applicazioni, e possono partecipare attivamente alla pianificazione di pietre miliari. Inoltre, con lo sviluppo aperto, i messaggi di commit possono essere collegati a problemi o bug specifici segnalati da una comunità di utenti e sviluppatori. Con il Software Libero, un'applicazione non è solo un prodotto finale, ma un processo aperto che riflette i bisogni ei desideri dei suoi utenti e delle loro comunità. Con FOSS, la comunità guida la direzione dello sviluppo!

Icona di Okular

Un altro punto era relativo alla distribuzione del Software Libero e al modo in cui presenta sfide per l'adempimento dei criteri Blauer Engel. Dal momento che il Software Libero generalmente distribuisce il software in modo decentralizzato, per ogni applicazione esistono numerosi canali di rilascio e distribuzione. Si consideri Okular, che è confezionato non solo per Flatpak, ma anche Microsoft Store, per non parlare delle numerose distribuzioni GNU/Linux (ad es. OpenSuse, Debian). Le differenze nell'infrastruttura di pacchettizzazione possono influire sul rispetto dei requisiti Blauer Engel, come la possibilità di essere disinstallato, la modularità, ecc.

Aziende che rilasciano software proprietario, in genere con implementazione centralizzata dei loro prodotti, non avrà questi problemi. Alla luce di ciò, una possibilità discussa dal gruppo è quella di certificare solo il codice sorgente di un programma, rimanendo quindi neutrali rispetto alle differenze nel modo in cui un prodotto software è impacchettato e distribuito. Un'altra possibilità è certificare le versioni specifiche della distribuzione, come quella per Microsoft Store. In effetti, quest'ultimo potrebbe essere utilizzato per scopi di marketing per raggiungere nuovi utenti e portarli nella comunità di KDE -- vedi, ad esempio, questa discussione.

Ci piacerebbe sapere cosa ne pensi. Partecipa alla conversazione sulla nostra lista di distribuzione o la stanza Matrix o tramite il sistema di tracciamento dei problemi nei nostri depositi GitLab!

Scenari di utilizzo standard

Uno Scenario di utilizzo standard (SUS) riflette le funzioni tipiche di un'applicazione, tenendo conto della frequenza di tali funzioni. Gli scenari di utilizzo standard sono fondamentali per misurare il consumo energetico di un software.

Durante la revisione dei registri delle azioni SUS per Okular per la richiesta di Blauer Engel, sono stati evidenziati due punti importanti che miglioreranno l'implementazione di SUS durante la misurazione in laboratorio. Una è stata l'osservazione sulla necessità di documentare non solo le azioni, ma anche gli oggetti delle azioni (ad esempio, quando si utilizza un lettore di pdf, quale pdf viene aperto), poiché ciò può influenzare il consumo di energia. L'altro era che l'inclusione dell'azione inattiva è importante quando si definisce un SUS: l'azione inattiva è realistica e può mostrare che non sta accadendo nulla quando si suppone che nulla debba accadere.

Diversi altri problemi sono stati portati al tavolo virtuale. Nicolas Fella, un ingegnere del software presso KDAB Berlin, ha espresso interesse nel confrontare due client di chat, che ha spostato la conversazione sulla definizione di singoli scenari quando si confrontano due applicazioni con un utilizzo simile. Un singolo SUS limiterà quali funzioni software possono essere provate nel test, ma renderà i risultati delle misurazioni direttamente confrontabili. Inoltre, per i software client-server come i client di chat o di posta elettronica, c'è il problema della componente di rete, che per i test controllati richiederebbe l'impostazione e la misurazione del consumo energetico di un server. L'ex presidente di KDE e.V. e collaboratore di lunga data di KDE Cornelius Schumacher ha sottolineato che per le misurazioni di KMail è stato misurato solo il lavoro di calcolo sulla macchina locale. La misurazione dell'elaborazione non locale nel software client-server è più importante che mai nel mondo di oggi, e questo è attualmente previsto per i criteri di aggiudicazione rivisti di Blauer Engel per il software.

Schermata di benvenuto di KMail

Un altro argomento discusso è stata la definizione astratta delle azioni SUS al fine di automatizzare l'implementazione di scenari di utilizzo con diversi strumenti (Actiona, xdotool, KXmlGui, ecc.). Un punto importante era che diversi strumenti di emulazione fanno cose diverse, il che potrebbe presentare sfide per l'automazione del processo. Ad esempio, non è possibile digitare il testo quando si utilizza KXmlGui per l'emulazione, quindi potrebbe essere ancora necessario qualcosa come xdotool. In una nota correlata, un'altra proposta era quella di strutturare un SUS in modo tale che anche la creazione di un registro delle azioni potesse essere automatizzata. Qualcuno nella comunità vorrebbe aiutare ad affrontare queste sfide?

Inoltre, il gruppo ha discusso come riproporre gli scenari di utilizzo per provare la reattività e le prestazioni generali su hardware meno recente o di fascia bassa. Quali sono le tue idee?

Sapevi che abbiamo in programma di avere una maratona di misurazione per misurare il consumo energetico delle applicazioni FOSS/KDE all'inizio del 2022? Per quali applicazioni vorresti che gli scenari di utilizzo standard fossero preparati? Condividi le tue idee con noi qui o invia il tuo SUS al nostro [deposito GitLab](https://invent.kde. org/teams/eco/be4foss/-/tree/master/standard-usage-scenarios)!

Sistema di riferimento replicabile

Gli scenari di utilizzo standard vengono eseguiti su un sistema di riferimento e un problema importante sollevato è stato come disporre di un sistema di riferimento replicabile. Ci sono diversi livelli di sistema da considerare: hardware (CPU, disco, RAM, ecc.); il sistema operativo e i servizi del sistema operativo come il gestore delle attività in Plasma e le relative configurazioni; e la configurazione dell'applicazione sottoposta ai test, nonché qualsiasi applicazione correlata (ad es. Akonadi per applicazioni PIM). Da un lato è necessario disporre di un ambiente controllato per poter interpretare i risultati; d'altra parte, è auspicabile disporre di misurazioni che riflettano ambienti informatici reali, forse anche rumorosi, al fine di comprendere il consumo energetico del software nel mondo reale. Alla fine, se avere ambienti informatici controllati o naturali dipenderà dall'uso dei dati, e questo sarà diverso per ricercatori, sviluppatori, revisori di etichette ecologiche, aziende, ecc.

Ad esempio, per gli sviluppatori interessati a fare unit test di efficienza energetica o ottenere l'etichetta Blauer Engel, sarà necessario avere ambienti ben definiti. Quindi quali sono i modi convenienti e veloci per portare il sistema in uno stato noto? Sono state discusse tre idee: (i) scattare istantanee di un filesystem (ad es. Snapper), (ii) svuotare la cache di sistema e (iii) sostituire i file di configurazione. Se hai altre idee, faccelo sapere qui!

Per gli ambienti del mondo reale, una proposta, potenzialmente controversa, è quella di registrare le prestazioni dell'hardware e il consumo di energia elettrica, mentre le persone usano i loro personal computer. Qualche volontario?

Uscita dati

Quando si misura il consumo di energia in un laboratorio, in particolare per la certificazione ecologica Blauer Engel, possono essere generati tre tipi di file di dati: (i) un file di registro delle azioni (vedi sopra per quanto riguarda l'automazione di tali file di registro), (ii) i dati relativi alle prestazioni dell'hardware (CPU, RAM, ecc.) e (iii) consumo di energia elettrica. Poiché in alcuni casi i dati di uscita dovranno essere auto-definiti (ad es., logger di marche temporali negli script xdotool), è necessario considerare come dovrebbero apparire i dati prima della misurazione in laboratorio.

Sono state sollevate diverse questioni relative ai dati: l'uscita dei dati dovrebbe essere standardizzata per armonizzare il risultato tra le campagne di misurazione o è sufficiente semplicemente pubblicare i dati raccolti in un formato accessibile (ad esempio, come file .csv come nel deposito FEEP)? Qual è la precisione della marca temporale necessaria (ad esempio, secondi e frazioni di secondo)? Queste domande rimangono aperte per ora, ma il gruppo ha deciso che abbiamo bisogno di una panoramica dei dispositivi/script compatibili con FOSS (ad es. lo script di Achim Guldner per Gude Expert Power Control 1202 Series) e toolkit (ad es. strumenti di analisi statistica come OSCAR, R, Julia, Octave, PSPP, NumPy) utilizzati per misurazioni e analisi, attualmente [in corso](https://invent.kde.org /teams/eco/be4foss/-/blob/master/devices-tools-overview.md).

Dispositivi misuratori di potenza

I criteri Blauer Engel si riferiscono in particolare a due misuratori di potenza (PM): Janitza UMG 604 e Gude Expert Power Control 1202. Questi dispositivi non sono economici. Nel 2020, Volker Krause, collaboratore di lunga data di KDE, ha violato una presa di corrente da 8 EUR e ne ha scritto. Come descritto nel post del blog, queste spine di alimentazione economiche sono in grado di ottenere una frequenza di campionamento fino a 200 ms. Ciò ha portato all'idea di utilizzare misuratori di potenza economici nei laboratori domestici a basso budget. A questo scopo, alla fine sarà utile confrontare i risultati dei misuratori di potenza professionali con quelli economici per verificare le differenze. Qualcuno nella comunità sarebbe interessato a farlo?

Dal commento del blog di Volker Krause: «Misurazione di esempio (intervallo di campionamento di 200 ms, nessun filtro): cursore del mouse spostato tra i campioni 100 e 150, con un picco mentre si passa con il puntatore del mouse su una voce della barra delle applicazioni.»

Un altro modo per misurare il consumo di energia è venuto dal collaboratore di KDE David Hurka, che ha una proposta per sensori di potenza SPI USB per fornire una risoluzione più elevata alternativa ai misuratori di potenza che misurano alla presa a muro.

Problemi aperti per i laboratori di misurazione

Sono state discusse molte altre questioni relative al consumo di energia e alle misurazioni di laboratorio. Sebbene le decisioni finali non siano state prese in tutti i casi, molte di queste questioni aperte saranno importanti da considerare in futuro.

• Idea di uno strumento di marketing per attirare l'attenzione sul consumo energetico del software.
  • Ad esempio, un pulsante «Eco» per l'efficienza energetica/misuratore dell'impronta di carbonio (cfr. impronta di carbonio di viaggio nell'applicazione Itinerary).
  • Nota che una funzionalità simile è già fornita da PowerTop, sebbene rimangano problemi aperti (quando è sicuro abilitare per evitare la perdita di dati, la macchina si blocca?).
• Quando gli svantaggi superano i vantaggi del supporto per hardware meno recente?
  • Invitiamo i ricercatori che lavorano su questo a discutere con la comunità KDE Eco.
• Collaborazione futura:
  • Joint Sprint con progetti correlati (ad es. SoftAWERE)? (Può essere di interesse per il lettore: Max Schulze di SoftAWERE/SDIA presentato all'incontro mensile di KDE Eco nel gennaio 2022, di cui puoi leggere i verbali da [qui](https:/ /invent.kde.org/teams/eco/be4foss/-/blob/master/community-meetups/2022-01-12_community-meetup_protocol.md).)
  • Discuti gli argomenti sopra e altro con altre comunità correlate (Bits & Bäume, [Forum Computer Scientists for Peace and Social Responsibility](https://www.fiff. de /), ecc.)?

Conclusione

Lo sprint in linea è stata una meravigliosa opportunità per riunire la comunità e portare avanti il progetto KDE Eco, soprattutto mentre ci prepariamo per il laboratorio di misurazione della comunità che si terrà al KDAB di Berlino e la prima di molte maratone di misurazione (prevista per l'inizio del 2022) ! Il successo di tali eventi dipende prima di tutto dalla comunità, quindi permetteteci di inviare un sentito ringraziamento a tutti coloro che si sono uniti alla conversazione. Non vediamo l'ora di far crescere la comunità nel 2022! Inoltre, non potremmo fare quello che facciamo senza il supporto di KDE e.V. così come BMU/UBA, che sostengono finanziariamente il progetto BE4FOSS (sebbene solo l'editore sia responsabile del contenuto di questa pubblicazione).

Avviso di finanziamento

Il progetto BE4FOSS è stato finanziato dall'Agenzia federale dell'ambiente e dal Ministero federale per l'ambiente, la conservazione della natura, la sicurezza nucleare e la protezione dei consumatori (BMUV¹). I fondi sono messi a disposizione con delibera del Bundestag tedesco.

L'editore è responsabile per il contenuto di questa pubblicazione.

¹ I loghi ufficiale di BMUV e UBA sono inviati solo su richiesta a: verbaendefoerderung@uba.de

Articolo scritto da Joseph P. De Veaugh-Geiss sotto licenza CC-BY-4.0.