Season of KDE 2022 con KDE Eco
Sono molto grato alla squadra di KDE per avermi invitato a far parte di questa incredibile comunità attraverso il loro programma annuale Season of KDE.
Presentazione
Sono Karanjot Singh. Sono uno studente al primo anno di ingegneria informatica presso il Jaypee Institute of Information Technology, Noida, India. Ho lavorato come sviluppatore con vari programmi FOSS (Free and Open-Source Software) come Kharagpur Winter of Code nel 2021 (KWoC'21). Tuttavia, questa sarà la prima volta che contribuisco a un progetto con una comunità così grande. Sono molto appassionato di FOSS, della risoluzione dei problemi e del miglioramento dell'efficienza dei processi. Mi piace esplorare e apprendere nuove tecnologie e costruire cose per cause socialmente utili. Credo inoltre che contribuire a FOSS sia il modo migliore per acquisire esperienza nello sviluppo di software.
Su cosa lavorerò
Come parte di un progetto pionieristico di sostenibilità, KDE Eco ha l'obiettivo di misurare e ridurre il consumo energetico di KDE del software libero in genere. Ciò richiede l'emulazione del comportamento dell'utente, che può essere ottenuto pianificando e creando script di scenari di utilizzo standard. Creerò scenari di utilizzo standard per varie applicazioni, con particolare attenzione agli editor di testo di uso comune come Kate, [KWrite](https://apps.kde .org/kwrite/), Vim, Nano, [Emacs](https://www. .gnu.org/software/emacs/), Calligra Words e LibreOffice. Preparerò questi scenari di utilizzo con uno dei tanti [strumenti di emulazione] disponibili (https://invent.kde.org/teams/eco/feep/-/blob/master/tools/presentation_Visual_Workflow_Automation_Tools/Visual_Workflow_Automation_Tools.pdf). Di seguito è riportato la mia linea temporale del SoK'22:
Motivazione alla base del lavoro sul progetto KDE Eco
Penso che KDE Eco sia un'ottima iniziativa per lo sviluppo di software libero efficiente in termini di risorse ed energia. Quando qualcuno utilizza FOSS e scopre che il software è trasparente rispetto al suo consumo di energia, che l'utilizzo del software può aiutare a prolungare la durata dell'hardware e ridurre l'impatto ambientale della digitalizzazione, è molto stimolante. Voglio sempre far parte di qualcosa che contribuisca alle generazioni future e KDE Eco serve a questo scopo. Credo anche che KDE Eco mi aiuti nel mio viaggio per diventare uno sviluppatore di software migliore.
Quello che ho imparato finora
Quando ho iniziato con questo progetto, avevo tre domande.
Come possiamo sapere quando il software è efficiente in termini di risorse ed energia?
Come possiamo misurare il consumo di energia del software?
E fa la differenza?
Queste domande possono venire in mente a chiunque quando si pensa all'idea di efficienza del software.
Quando usi un software, ciò che vedi è solo l'interfaccia con cui stai interagendo. Basta dire al tuo telefono cosa vuoi e le cose appariranno magicamente, che si tratti delle informazioni sullo schermo o di un pacco consegnato a casa tua. Ma le tecnologie e l'infrastruttura alla base sono determinate dagli ingegneri del software che fanno funzionare tutto questo.
Immagina: e se analizzassimo il consumo di energia alla base del software di uso comune e lo rendessimo più trasparente? E se gli utenti potessero sapere quanta energia richiede il loro software e potessero scegliere l'applicazione che potrebbe essere migliore per l'ambiente? Questo sarebbe fantastico!!!
Le iniziative KDE Eco Progetto di efficienza energetica per software libero e open source (FEEP) e Blauer Engel For FOSS (BE4FOSS) stanno lavorando sodo su questi problemi.
Come notato da FEEP, la progettazione e l'implementazione del software ha un impatto significativo sul consumo energetico dei sistemi di cui fa parte. Con gli strumenti giusti è possibile quantificare e ridurre i consumi energetici. Questa maggiore efficienza contribuisce a un uso più sostenibile dell'energia come una delle risorse condivise del nostro pianeta.
BE4FOSS sostiene FEEP raccogliendo e diffondendo informazioni relative alla certificazione ecologica Blauer Engel (BE), il marchio ambientale ufficiale assegnato dal governo tedesco. Come affermato nel sito web di KDE Eco, l'ottenimento della certificazione Blauer Engel avviene in 3 fasi: (1) Misura, (2) Analizza, (3) Certifica.
- MISURA in laboratori dedicati, come al KDAB di Berlino
- ANALIZZA utilizzando strumenti statistici come OSCAR (Open source Software Consumption Analysis in R)
- CERTIFICA inviando la relazione sul rispetto dei criteri Blauer Engel
In SoK'22, preparerò scenari di utilizzo standard per vari editor di testo in modo che gli scenari di utilizzo possano essere utilizzati nel passaggio 1 per ottenere la certificazione ambientale BE.
Cosa ho fatto e farò nelle prossime settimane
Nelle ultime tre settimane, ho testato vari strumenti di automazione, in particolare Actiona, xdotool e GNU Xnee, per decidere quale di questi strumenti sarebbe stato il migliore per implementare gli scenari di utilizzo standard.
Durante l'utilizzo di Actiona, ho scritto della documentazione in modo che queste informazioni siano utili anche a chiunque voglia contribuire a KDE Eco.
Durante il test di xdotool, ho riscontrato un problema di memory leak. Eseguendo Valgrind su xdotool search, ottengo più memoria persa allocata da XQueryTree. Probabilmente ci sono altri posti in cui la memoria viene allocata e non viene liberata in seguito. Non ho fatto un controllo approfondito. Tuttavia, xdotool offre un maggiore controllo sul sistema e anche con alcuni problemi, questo è lo strumento che ho trovato più utile.
Ho testato anche GNU Xnee, cosa che mi è sembrata interessante in quanto registra l'uscita e la memorizza in un file separato. Inoltre, fornisce un riproduttore che è possibile utilizzare per automatizzare le attività a qualsiasi velocità si desideri.
Alla fine, ho deciso di preparare tutti gli scenari di utilizzo con xdotool, almeno inizialmente, poiché la maggior parte degli editor di testo utilizza le funzioni della tastiera anziché l'attività del mouse e questo renderà più semplice adattare lo script a diversi sistemi. Tuttavia, dopo SoK'22 ho intenzione di preparare scenari di utilizzo anche con Actiona in modo da poter apprendere le differenze tra questi strumenti. In una nota correlata, è in corso anche una discussione sul riutilizzo degli scenari di utilizzo standard per verificare la reattività e le prestazioni su hardware più datato o di fascia bassa.
Nelle prossime settimane lavorerò inoltre per risolvere un problema noto per Actiona. Il problema è che Actiona emula il comportamento dell'utente memorizzando la posizione dei clic in base alle coordinate dei pixel, il che può rendere difficile il trasferimento di uno script su un altro sistema. Ad esempio, questo problema è sorto di recente durante la preparazione di uno scenario di utilizzo standard per GCompris. Ho trovato una soluzione per ridimensionare lo schermo a una risoluzione minima dello schermo e includere il codice all'inizio dello script di Actiona. Ogni volta che lo script viene eseguito in un sistema diverso, viene ridimensionato automaticamente alla risoluzione minima in modo che corrisponda ai pixel durante la creazione dello script. Questa è solo un'idea e non è ancora stata sottoposta a test. Dedicherò del tempo per questo tentativo di risolvere il problema con l'aiuto del team di GCompris.
Il deposito GitLab contenente gli scenari di utilizzo standard in corso (attualmente GCompris che utilizza Actiona) può essere trovato qui .
Legame comunitario (SoK'22)
Sono grato al mio mentore Joseph P. De Veaugh-Geiss per aver dedicato del tempo ad aiutarmi fornendomi risorse e guida durante il progetto. Ho anche partecipato all'incontro mensile della comunità di KDE Eco il [9 febbraio 2022](https://invent.kde.org/teams/eco/be4foss/-/blob/master/community-meetups/2022-02-09_community-meetup_protocol. md), dove il Prof. Dr. Stefan Naumann, Achim Guldner e Christopher Stumpf di Umwelt Campus Birkenfeld conducono una discussione sulla misurazione del consumo di energia dei sistemi e l'estensione ad essi i criteri di aggiudicazione Blauer Engel. Questo è stato un incontro interessante in cui abbiamo discusso dei problemi per l'automazione con le applicazioni mobili e dei test client-server. Joseph mi ha anche presentato i ricercatori dell'Umwelt Campus che hanno misurato il consumo di energia di Okular; Emmanuel Charruau, che sta lavorando con lo script di GCompris; e Nicolas Fella, che sta attualmente lavorando con xdotool per la sua tesi di laurea sul consumo energetico del software.
Grazie per aver dedicato del tempo a leggere questo aggiornamento. Se qualcuno vuole dare seguito alle idee presentate qui riguardo ai pro e ai contro dei diversi strumenti di automazione durante l'implementazione di scenari di utilizzo standard, c'è un [issue GitLab](https://invent.kde.org/teams/eco/be4foss /-/issues/32) nel deposito BE4FOSS dove possiamo discutere ulteriormente.
Sono disponibile anche sull'istanza Matrix di KDE su drquark:kde.org.