Sprint 2021 de KDE Eco : les détails sur le planning de la communauté pour le projet écologique de KDE.

Lundi, 7 Février 2022 | Joseph P. De Veaugh-Geiss

Ceci est le suivi de l'annonce du Sprint de KDE Eco publiée sur « The Dot ».

Le 11 décembre 2021, KDE Eco a tenu le premier de nombreux Sprints prévus, avec 7 personnes présentes. personnes présentes. Le Sprint devait à l'origine, être un évènement en présentiel pour mettre en place un laboratoire de mesure communautaire. Mais, le Corona virus avait d'autres idées. Néanmoins, la communauté a déployé sa débrouillardise habituelle et nous nous sommes rencontrés en ligne à la place.

Annonce du Sprint « KDE Eco 2021 » sur KDE News

Dans ce message en format long, je fournirai un aperçu détaillé des principaux problèmes discutés lors du Sprint et de leurs résultats. Veuillez consulter également le compte-rendu pour plus de détails.

Le saviez-vous ?

Des discussions similaires à celles-ci ont lieu chaque mois lors de nos rencontres communautaires le deuxième mercredi du mois de 19h à 20h CET / CEST (Heure de Berlin).

Création d'une équipe pour KDE Eco

KDE Eco se compose actuellement de trois projets connexes : (i) Projet d'efficacité énergétique libre et « Open source « FEEP » (Free and open source Energy Efficiency Project), (ii) la certification « Blauer Engel » pour les logiciels libres « BE4FOSS(Blauer Engel for Free and Open Source Software), et (iii) les applications « Blauer Engel ». Chaque projet possède son propre objectif particulier : le projet « FEEP » s'intéresse à la mesure de la consommation d'énergie des logiciels libres, le projet « BE4FOSS » se concentre sur l'organisation de la communauté et la diffusion d'informations sur l'éco-label « Blauer Engel » et le dépôt « Applications de Blauer Engel » héberge tous les documents liés à la certification de KDE / logiciels libres avec l'éco-label. Jusqu'au Sprint, les trois dépôts des projets étaient hébergés dans différents espaces de noms personnels. Maintenant, les trois dépôts sont regroupés sur le site https://invent.kde.org/teams/eco.

Le regroupement de projets au sein d'une seule et même équipe permet d'établir des liens plus clairs entre eux et avec d'éventuels futurs projets. De plus, la définition d'un espace de nom non personnel est plus approprié pour les projets communautaires. N'hésitez pas à consulter les activités de chaque projet dans l'espace des équipes ci-dessus !

Équipes / KDE Eco

Remplissage de la demande pour l'éco-label « Blauer Engel » pour Okular

Il existe trois applications KDE dont la consommation d'énergie a déjà été mesurée : Okular, KMail et Krita. Parmi ces trois applications, les certifications avec l'éco-label « Blauer Engel » pour Okular et KMail sont en préparation depuis un certain temps. Un des objectifs était de mener à terme la certification de Okular. Nous sommes fiers d'annoncer que, suite au Sprint, la demande de certification d'Okular a été déposée et est actuellement en cours d'examen pour certification. Nous attendons un retour dans les prochains 2 à 3 mois de RAL gGmbH, l'organisme décernant l'éco-label « Blauer Engel ». La demande de certification pour KMail suivra bientôt.

Lors d'une revue collective de l'application Okular, les participants ont soulevé de nombreux points intéressants. Un point, par exemple, est apparu lors de la discussion sur les critères de transparence de l'éco-label « Blauer Engel » (Section 3.1.3.2). Malte Reißig, du groupe de recherche de IASS sur "la numérisation et les transformations durables", a souligné comment le développement libre peut avoir un effet positif sur certaines des autres exigences concernant les critères d'attribution (Consulter cette discussion), tels que la maintenabilité à long terme et l'autonomie des utilisateurs d'un produit logiciel. En d'autres termes, les utilisateurs de logiciels libres ne se contentent pas d'utiliser passivement les logiciels. En effet, ils sont encouragés et capables d'exprimer des souhaits pour le développement futur des applications et peuvent participer activement à la planification des étapes importantes. De plus, avec les logiciels libres, les messages de validation peuvent être associés à des problèmes ou des bogues spécifiques signalés par une communauté d'utilisateurs et de développeurs. Avec les logiciels libres, une application n'est pas seulement un produit final, mais un processus ouvert reflétant les besoins et les souhaits de ses utilisateurs et de leurs communautés. Avec les logiciels libres, c'est la communauté qui détermine la direction des développements !

Icône d'Okular

Un autre point concernait la distribution des logiciels libres et la manière dont elle présente des défis pour le respect des critères de l'éco-label « Blauer Engel ». Puisque les logiciels libres sont généralement distribués de manière décentralisée, il existe, pour chaque application, de nombreux canaux de publication et de distribution. Prenons l'exemple de Okular, empaqueté, non seulement pour Flatpak, mais aussi pour Microsoft Store, sans oublier de nombreuses distributions GNU / Linux (par exemple, OpenSuse, Debian). Les différences dans l'infrastructure de mise en paquets peuvent avoir une incidence sur le respect des exigences de l'éco-label « Blauer Engel », telles que la désinstallation, la modularité, etc.

Les entreprises publiant des logiciels propriétaires, dont le déploiement est généralement centralisé, n'auront pas ces problèmes. Dans ce contexte, une possibilité discutée par le groupe est de certifier uniquement le code source d'un programme, ce qui permet de rester neutre par rapport aux différences de mise en paquets et de distribution d'un produit logiciel. Une autre possibilité est de certifier des versions spécifiques à une distribution, comme celle du « Microsoft Store ». En fait, cette dernière pourrait être utilisée à des fins de marketing pour atteindre de nouveaux utilisateurs et les amener dans la communauté KDE -- Consultez par exemple cette discussion.

Nous aimerions savoir ce que vous pensez. Veuillez rejoindre la conversation sur notre liste de diffusion ou sur notre salle Matrix ou via les suiveurs de problèmes sur nos dépôts GitLab !

Scénarios d'usage standard

Un Scénario d'utilisation standard (SUS) reflète les fonctions classiques d'une application en prenant en compte la fréquence de ces fonctions. Les scénarios d'utilisation standard sont essentiels pour mesurer la consommation d'énergie d'un logiciel.

Lors de l'examen des journaux d'actions « SUS » de Okular pour la certification « Blauer Engel », deux points importants ont été relevés qui permettront l'amélioration de la mise en œuvre du « SUS » lors des mesures en laboratoire. L'un de ces points concerne la nécessité de documenter non seulement les actions mais aussi les objets des actions (Comme par exemple, lors de l'utilisation d'un lecteur de fichier « pdf », quel fichier « pdf » est ouvert), car cela peut influencer la consommation d'énergie. L'autre point confirme que l'intégration d'une action inactive est importante lors de la définition d'un « SUS » : l'action inactive est à la fois réaliste et peut confirmer que rien ne se passe lorsque rien n'est supposé se passer.

Plusieurs autres questions ont été posées durant la table virtuelle. Nicolas Fella, ingénieur logiciel chez KDAB Berlin, a exprimé son intérêt pour la comparaison de deux clients de chat, ce qui a déplacé la conversation vers la définition de scénarios simples pour la comparaison de deux applications ayant une utilisation similaire. Un seul « SUS » limitera les fonctions logicielles pouvant être testées, mais il rendra les résultats des mesures directement comparables. De plus, pour les logiciels client-serveur tels que les clients de chat ou de messagerie, il y a le problème de la composante réseau, qui, pour des tests contrôlés, nécessiterait de mettre en place et de mesurer la consommation d'énergie d'un serveur. L'ancien président de KDE e.V. et contributeur de longue date de KDE Cornelius Schumacher a souligné que pour les mesures de KMail, seule la charge de calcul sur la machine locale a été mesurée. La mesure de la charge de calcul non local dans les logiciels client-serveur est plus pertinent que jamais dans le monde d'aujourd'hui. Ceci est actuellement prévu pour les critères révisés du prix « Blauer Engel » pour les logiciels.

Écran de bienvenue de KMail

Un autre sujet abordé était la définition abstraite des actions « SUS » afin d'automatiser la mise en œuvre de scénarios d'utilisation avec différents outils (Actiona, xdotool, KXmlGui, etc.). Un point important était que différents outils d'émulation réalisent différentes choses, ce qui pourrait présenter des défis pour l'automatisation du processus. Par exemple, on ne peut pas saisir du texte en utilisant KXmlGui pour l'émulation, et donc, quelque chose comme xdotool peut être nécessaire. Dans le même ordre d'idées, une autre proposition consistait à structurer un « SUS » de manière à ce que la création d'un journal d'actions puisse également être automatisée. Est-ce qu'une personne de la communauté souhaite-t-elle contribuer à relever ces défis ?

En outre, le groupe a discuté de la façon dont les scénarios d'utilisation pourraient également être réutilisés pour tester la réactivité et les performances générales sur du matériel ancien ou bas de gamme. Quelles sont vos idées ?

Saviez-vous que nous prévoyons d'organiser un marathon de mesure de la consommation d'énergie pour les applications « FOSS » de KDE au début de 2022 ? Pour quelles applications aimeriez-vous que des scénarios d'utilisation standard soient préparés ? Partagez vos idées avec nous ici ou soumettez votre « SUS » sur notre dépôt GitLab !

Système de référence réplicable

Les scénarios d'utilisation standard sont lancés sur un système de référence. Une question importante soulevée était de savoir comment avoir un système de référence reproductible. Il y a plusieurs couches dans le système à prendre en compte : le matériel (processeur, disque, mémoire vive, etc.), le système d'exploitation et les services du système d'exploitation tels que le gestionnaire d'activités dans Plasma, ainsi que leurs configurations, et la configuration de l'application testée ainsi que toute application connexe (Par exemple, Akonadi pour les applications « PIM »). D'une part, il est nécessaire de disposer d'un environnement contrôlé afin de pouvoir interpréter les résultats. D'autre part, il est souhaitable de disposer de mesures reflétant des environnements informatiques réels, peut-être même bruyants, afin de comprendre la consommation énergétique réelle des logiciels. En fin de compte, l'utilisation d'environnements informatiques soit contrôlés soit naturels dépendra de l'usage que l'on veut faire des données. Cela sera différent pour les chercheurs, les développeurs, les auditeurs de labels écologiques, les entreprises, etc.

Par exemple, pour les développeurs désireux d'effectuer des tests unitaires d'efficacité énergétique ou d'obtenir l'éco-label « Blauer Engel », il serait nécessaire de disposer d'environnements clairement spécifiés. Ainsi, quels sont donc les moyens pratiques et rapides d'amener le système dans un état connu ? Trois idées ont été discutées : (i) prendre des instantanés d'un système de fichiers (par exemple, Snapper), (ii) vider le cache du système et (iii) remplacer les fichiers de configuration. Si vous avez d'autres idées, faites-les nous connaître ici !

Pour les environnements réels, une proposition, potentiellement controversée, est de consigner les performances du matériel et l'utilisation de l'électricité pendant que les personnes utilisent leurs ordinateurs personnels. Des bénévoles ?

Sortie de données

Lors de la mesure de la consommation d'énergie dans un laboratoire, notamment pour l'éco-certification « Blauer Engel », trois types de fichiers de données peuvent être générés : (i) un fichier de journal pour les actions (Voir ci-dessus concernant l'automatisation de ces fichiers de journaux), (ii) des données de performance du matériel (Processeur, mémoire, etc.) et (iii) sur l'usage des données de puissance électrique. Puisque dans certains cas, les données de sortie devront être auto-définies (Par exemple, les enregistreurs d'horodatage dans les scripts « xdotool »). Il est nécessaire de réfléchir au format des données avant de les mesurer en laboratoire.

Plusieurs questions ont été soulevées concernant les données : les données en sortie doivent elles être normalisées afin d'harmoniser les résultats entre les campagnes de mesure ou suffit-il simplement de publier les données collectées dans un format accessible (Par exemple, sous forme de fichiers au format « .csv » comme sur le dépôt du projet « FEEP ») ? Quelle est la précision nécessaire pour l'horodatage (Par exemple, secondes ou fractions de secondes) ? Ces questions restent ouvertes pour l'instant, mais le groupe a décidé que nous avions besoin d'une vue d'ensemble des périphériques / scripts compatibles avec les logiciels libres (par exemple, le script de Guldner pour le wattmètre « Gude Expert Power Control 1202 Series » et des boîtes à outils (Par exemple, les outils d'analyse statistique tels que OSCAR, R, Julia, Octave, PSPP, NumPy) utilisés pour les mesures et l'analyse, ce qui est actuellement en cours.

Périphériques de mesure de puissance

Les critères du certificat « Blauer Engel » font référence à deux wattmètres (PM) en particulier : « Janitza UMG 604 » et « Gude Expert Power Control 1202 ». Ces appareils sont plutôt onéreux. En 2020, Volker Krause, contributeur de longue date de KDE, a piraté une prise de courant à 8 Euros et a écrit à ce sujet (https://volkerkrause.eu/2020/10/17/kde-cheap-power-measurement-tools.html). Comme décrit dans le billet de blog, ces prises d'alimentation bon marché sont capables d'obtenir un taux d'échantillonnage allant jusqu'à 200 ms. Cela a donné l'idée d'utiliser des wattmètres bon marché dans des laboratoires domestiques à petit budget. À cette fin, il sera éventuellement utile de comparer les résultats des wattmètres professionnels avec ceux des wattmètres bon marché pour voir comment leurs divergences. Une personne dans la communauté serait-elle intéressée à faire cela ?

*Extrait du [message du blog] de Volker Krause (https://volkerkrause.eu/2020/10/17/kde-cheap-power-measurement-tools.html) : « Exemple de mesure (Intervalle d'échantillonnage de 200 ms, aucun filtre) : déplacement du pointeur de souris entre les échantillons 100 et 150, avec un pic lors du survol d'une entrée de la barre des tâches.

Une autre façon de mesurer la consommation d'énergie nous vient du contributeur de KDE, David Hurka, qui a proposé une proposition de capteurs d'énergie « USB SPI » pour fournir une alternative à plus haute résolution que les wattmètres mesurant l'énergie à la prise murale.

Problèmes ouverts pour les laboratoires de mesure

Plusieurs autres problèmes ont été abordés, liés à la consommation d'énergie et aux mesures en laboratoire. Bien que des décisions finales n'aient pas été prises dans tous les cas, plusieurs de ces points ouverts seront importants à prendre en compte pour aller de l'avant.

• Idée d'un outil convivial de marketing pour attirer l'attention sur la consommation d'énergie des logiciels.
  • Par exemple, un bouton « Eco » pour le compteur d'efficacité énergétique / empreinte carbone (Voir l'empreinte carbone des voyages dans l'application Itinerary).
  • Veuillez noter qu'une fonctionnalité similaire est déjà fournie par PowerTop, bien que des problèmes subsistent (quand est-il sûr d'activer pour éviter la perte de données, des gels de vos ordinateurs ?).
• Quand les inconvénients l'emportent-ils sur les avantages de la prise en charge de matériel plus ancien ?
  • Invitons les chercheurs travaillant sur ce sujet à discuter avec la communauté de KDE Eco.
• Collaboration future :
  • Le Sprint conjoint avec des projets connexes (Par exemple, SoftAWERE) ? (Peut-être d'un intérêt pour le lecteur : Max Schulze de SoftAWERE / SDIA a fait une présentation à la réunion mensuelle de KDE Eco en Janvier 2022. Vous pouvez en lire les comptes-rendus ici).
  • Discutez les sujets ci-dessus et plus encore avec d'autres communautés associées (Bits & Bäume, Forum « InformatikerInnen für Frieden und gesellschaftliche Verantwortung », etc.) ?

Conclusion

Le sprint en ligne a été une merveilleuse occasion de rassembler la communauté et de faire avancer le projet KDE Eco, surtout au moment où nous préparions le laboratoire de mesure communautaire qui se tiendra au KDAB de Berlin et le premier des nombreux marathons de mesures (prévus pour début 2022) ! Le succès de tels évènements dépend avant tout de la communauté, alors, permettez-nous d'envoyer un sincère merci à toutes les personnes ayant rejoint la conversation. Nous sommes impatients de faire grandir la communauté en 2022 ! De plus, nous ne pourrions pas faire ce que nous faisons sans le soutien de KDE e.V. ainsi que de BMU / UBA, qui soutiennent financièrement le projet « BE4FOSS » (bien que seul l'éditeur soit responsable du contenu de cette publication).

Modalités pour le financement

Le projet « BE4FOSS » a été financé par l'Agence fédérale pour l'environnement et le ministère fédéral de l'environnement, de la protection de la nature, de la sécurité nucléaire et de la protection des consommateurs (BMUV¹). Les fonds sont mis à disposition par une résolution par le Bundestag, le parlement allemand.

L'éditeur est responsable du contenu de cette publication.

1 Les logos officiels de « BMU » et « UBA » ne sont envoyés que sur demande au courriel « verbaendefoerderung@uba.de ».