Saison de KDE 2022 avec KDE Eco
Je suis très reconnaissant envers l'équipe de KDE pour m'avoir invité à participer à cette incroyable communauté grâce à leur programme annuel Saison de KDE.
À propos de moi
Je m'appelle Karanjot Singh. Je suis étudiant en première année en génie informatique à l'institut des technologies de l'information à Jaypee (Inde). J'ai travaillé en tant que développeur avec divers programmes libres et « Open-source » (FOSS) tels que « Kharagpur Winter of Code » en 2021 (KWoC'21). Cependant, ce sera la première fois que je contribuerai à un projet avec une si grande communauté. Je suis vraiment passionné par les logiciels libres, la résolution de problèmes et l'amélioration de l'efficacité des processus. J'aime explorer et apprendre de nouvelles technologies et construire des choses pour des causes socialement utiles. Je crois aussi que contribuer aux logiciels libres (FOSS) est la meilleure façon d'acquérir de l'expérience dans le développement de logiciels.
Sur quoi vais je travailler
Faisant partie d'un projet de développement durable novateur, KDE Eco a pour objectif de mesurer et de réduire la consommation d'énergie de KDE / des logiciels libres. Cela nécessite de simuler le comportement de l'utilisateur, ce qui peut être réalisé en planifiant et en écrivant des scripts représentatifs des scénarios d'utilisation standard. Je produirai ces scripts de scénarios d'utilisation standard pour diverses applications, en mettant l'accent sur les éditeurs de texte couramment utilisés comme Kate, KWrite, Vim, Nano, Emacs, Calligra Words et LibreOffice. Je préparerai ces scénarios d'utilisation avec l'un des nombreux outils d'émulation disponibles. Voici la chronologie de mon activité pour le SoK-22 :
Motivation derrière le travail sur le projet KDE Eco
Je pense que KDE Eco est une très bonne initiative pour le développement des logiciels libres, économes en énergie et en ressources. Quand quelqu'un utilise un logiciel libre et découvre que le logiciel est transparent quant à sa consommation d'énergie, que l'utilisation du logiciel peut aider à prolonger la durée de vie du matériel et réduire l'impact environnemental de la numérisation, je trouve cela motivant. Je veux toujours faire partie de quelque chose contribuant aux générations futures. KDE Eco participe à cet objectif. Je crois également que KDE Eco m'aide dans ma démarche pour devenir un meilleur développeur de logiciels.
Ce que j'ai appris jusqu'à maintenant
Quand j'ai commencé ce projet, j'avais trois questions.
*Comment pouvons-nous savoir si un logiciel est économe en ressources et en énergie ? *
Comment pouvons nous mesurer la consommation d'énergie d'un logiciel ?
*Et est-ce que ceci fait une différence ? *
Ces questions peuvent venir à l'esprit de n'importe qui, pensant à l'idée de l'efficacité du logiciel.
Lorsque vous utilisez un logiciel, vous ne voyez que l'interface avec laquelle vous interagissez. Dites simplement à votre téléphone ce que vous voulez et les choses apparaîtront comme par magie... qu'il s'agisse d'informations à l'écran ou d'un colis livré à votre porte. Mais les technologies et l'infrastructure derrière le logiciel sont déterminées par les ingénieurs en logiciels qui font tout ce travail.
Imaginez : et si nous analysions la consommation d'énergie derrière les logiciels couramment utilisés et les rendre plus transparent ? Et si les utilisateurs pouvaient apprendre de combien d'énergie leurs logiciels ont besoin et pouvaient choisir l'application la plus bénéfique pour l'environnement ? Ce serait génial !
Les initiatives KDE Eco du projet « Free and Open Source Energy Efficiency Project » ([FEEP]) (https://invent.kde.org/teams/eco/feep)) et l'éco-certification « Blauer Engel » pour les logiciels libres(Free and Open Source Software, « FOSS ») (BE4FOSS) travaillent intensément sur ces questions.
Comme indiqué par le projet FEEP, la conception et la réalisation de logiciels ont un impact significatif sur la consommation d'énergie des systèmes dont ils font partie. Avec les bons outils, il est possible de quantifier et de réduire la consommation d'énergie. Cette efficacité accrue contribue à une utilisation plus durable de l'énergie, l'une des ressources partagées de notre planète.
Le projet « BE4FOSS » soutient le projet « FEEP » en recueillant et en diffusant des informations relatives à l'éco-certification écologique « Blauer Engel » (BE), le label environnemental officiel attribué par le gouvernement allemand. Comme indiqué sur le site Internet de KDE Eco, l'obtention du label « Blauer Engel » se fait en trois étapes : (1) Mesurer, (2) Analyser, (3) Certifier.
- ** MESURER ** dans des laboratoires spécifiques, tels que le laboratoire « KDAB » de Berlin
- ** ANALYSER ** grâce à l'utilisation d'outils de statistiques comme « OSCAR » (« Open source Software Consumption Analysis in R »).
- ** CERTIFIER ** en soumettant le rapport concernant le respect des critères pour l'éco-label « Blauer Engel ».
Dans SoK'22, je vais préparer des scénarios d'utilisation standard pour divers éditeurs de texte, afin que ces scénarios d'utilisation puissent être utilisés à l'étape 1 pour obtenir l'éco-certification « Blauer Engel ».
Ce que j'ai fait & ce que je ferai au cours des prochaines semaines
Depuis trois semaines, j'ai testé différents outils d'automatisation, en particulier « Actiona », « xdotool » et « GNU Xnee », pour décider lequel de ces outils seraient le meilleur pour la mise en œuvre de scénarios d'utilisation standard.
Lors de l'utilisation de « Actiona » , j'ai écrit un peu de documentation afin que cette information soit également utile à toute personne voulant contribuer à KDE Eco.
Lors de l'essai de « xdotool » , j'ai été confronté à un problème de fuite de mémoire. En lançant le logiciel « Valgrind »sur une rechercher avec « xdotool », j'ai découvert plus de mémoire perdue allouée par « XQueryTree ». Il y a probablement d'autres endroits où la mémoire est allouée mais pas libérée ensuite. Je n'ai pas fait une vérification approfondie. Néanmoins, « xdotool » donne plus de contrôle sur le système et même avec certains problèmes, c'est l'outil que j'ai trouvé le plus utile.
J'ai aussi testé « GNU Xnee » , ce qui semblait intéressant pour moi car il enregistre la sortie et l'enregistre dans un fichier séparé. En outre, il fournit un outil de rejeu que l'on peut utiliser pour automatiser les tâches à la vitesse désirée.
En fin de compte, j'ai décidé de préparer tous les scénarios d'utilisation avec « xdotool », au moins initialement. En effet, la plupart des éditeurs de texte utilisent les fonctions du clavier plutôt que l'activité de la souris. Ceci facilitera l'adaptation du script à différents systèmes. Cependant, après SoK'22, je prévois de préparer des scénarios d'utilisation avec « Actiona » afin de pouvoir apprendre les différences entre ces outils. Dans le même ordre d'idées, il y a également une discussion en cours sur une ré-utilisation des scénarios d'utilisation standard pour tester la réactivité et les performances sur du matériel plus ancien ou bas de gamme.
Au cours des prochaines semaines, je travaillerai également à résoudre un problème connu concernant « Actiona ». Le problème est que « Actiona » émule le comportement de l'utilisateur en enregistrant la position des clics en fonction des coordonnées d'un pixel. Ceci peut rendre difficile le transfert d'un script vers un autre test de système. Par exemple, ce problème est survenu récemment lors de la préparation d'un scénario d'utilisation standard pour GCompris. J'ai trouvé une solution pour redimensionner l'écran à une résolution minimale et inclure le code au début du script avec « Actiona ». Chaque fois que le script s'exécute dans un système différent, il paramètre l'écran automatiquement à sa résolution minimale pour faire correspondre les pixels faisant partie du script. Ce n'est qu'une idée et elle n'est pas encore testée. Je vais réserver du temps pour cette tentative de résoudre le problème avec l'aide de l'équipe de GCompris.
Le dépôt « GitLab » contenant les scénarios d'utilisation standard en cours (actuellement GCompris utilisant Actiona) peut être trouvé ici.
Liens communautaires ( SoK'22 )
Je remercie mon mentor Joseph P. De Veaugh-Geiss d'avoir pris le temps de m'aider en fournissant des ressources et des conseils pendant le projet. J'ai également assisté à la réunion communautaire mensuelle de KDE Eco le 9 février 2022, où les professeurs Stefan Naumann, Achim Guldner et Christopher Stumpf proviennent du Campus Umwelt Birkenfeld animaient une discussion sur la mesure de la consommation d'énergie des systèmes distribués et l'extension des critères d'attribution de l'éco-label « Blauer Engel ». Ce fut une réunion intéressante où nous avons discuté des problèmes d'automatisation des applications mobiles ainsi que des tests en environnement client-serveur. Joseph m'a également présenté aux chercheurs du campus Umwelt qui ont mesuré la consommation d'énergie de Okular et à Emmanuel Charruau, qui travaille avec le script pour GCompris et à Nicolas Fella, qui travaille actuellement avec « xdotool » pour sa thèse de maîtrise sur la consommation d'énergie des logiciels.
Merci d'avoir pris le temps de lire cette mise à jour. Si une personne veut faire un suivi sur les idées présentées ici concernant les avantages et les inconvénients de différents outils d'automatisation lors de la mise en œuvre de scénarios d'utilisation standard, il y a un forum « GitLab » sur le dépôt « BE4FOSS » où nous pouvons en discuter en détail.
Je suis aussi joignable sur une instance « Matrix » de KDE à l'adresse « drquark:kde.org ».
Article rédigé par Karanjot Singh sous licence CC-BY-SA-4.0.