Temporada KDE 2022 con KDE Eco
Estoy muy agradecido al equipo de KDE por invitarme a formar parte de esta increíble comunidad a través de su programa anual Season of KDE.
Sobre mí
Soy Karanjot Singh, un estudiante de primer año de ingeniería informática del Jaypee Institute of Information Technology, Noida, India.He trabajado como desarrollador en varios programas de software libre y de código abierto (FOSS) como Kharagpur Winter of Code en 2021 (KWoC'21). Sin embargo, esta será la primera vez que contribuya a un proyecto con una comunidad tan grande. Me apasiona el software libre, la resolución de problemas y la mejora de la la eficiencia de los procesos. Me gusta explorar y aprender nuevas tecnologías y construir cosas para causas socialmente útiles. También creo que contribuir al software libre es la mejor manera de ganar experiencia en el desarrollo de software.
En lo qué estaré trabajando
Como parte de un proyecto pionero de sostenibilidad, KDE Eco tiene como objetivo medir y reducir el consumo de energía de KDE/Software Libre. Para ello es necesario emular el comportamiento de los usuarios, lo que puede lograrse planificando y programando escenarios de uso estándar. Prepararé escenarios de uso estándar para varias aplicaciones, centrándome en editores de texto de uso común como Kate, KWrite, Vim, Nano, Emacs, Calligra Words, y LibreOffice. Prepararé estos escenarios de uso con una de las muchas herramientas de emulación disponibles. A continuación, mi cronología del SoK'22:
Motivación para trabajar en el proyecto KDE Eco
Creo que KDE Eco es una muy buena iniciativa para el desarrollo de Software Libre eficiente en recursos y energía. Cuando alguien utiliza software libre y descubre que el software es transparente en cuanto a su consumo de energía, que el uso del software puede ayudar a prolongar la vida útil del hardware y a reducir el impacto medioambiental de la digitalización, eso me entusiasma. Siempre quiero formar parte de algo que contribuya a las generaciones futuras y KDE Eco cumple ese propósito. También creo que KDE Eco me ayuda en mi camino para convertirme en un mejor desarrollador de software.
Lo que he aprendido hasta ahora
Cuando empecé con este proyecto, tenía tres preguntas.
¿Cómo podemos saber si el software es eficiente en cuanto a recursos y energía?
¿Cómo podemos medir el consumo de energía de los programas informáticos?
¿Y, hace alguna diferencia?
Estas preguntas pueden venir a la mente de cualquiera al pensar en la idea de eficiencia del software.
Cuando usas un software, lo que ves es sólo la interfaz con la que estás interactuando. Basta con decirle a tu teléfono lo que quieres y las cosas aparecerán por arte de magia, ya sea la información que aparece en la pantalla o un paquete entregado en la puerta de tu casa. Pero las tecnologías y la infraestructura que hay detrás las determinan los ingenieros de software que hacen que todo esto funcione.
Imagínate: ¿Y si analizáramos el consumo de energía de los programas informáticos de uso común y lo hiciéramos más transparente? ¿Y si los usuarios pudieran saber cuánta energía requiere su software y pudieran elegir la aplicación que fuera mejor para el medio ambiente? ¡Sería genial!
Las iniciativas KDE Eco Proyecto de Eficiencia Energética de código abierto (FEEP) y Blauer Engel For FOSS (BE4FOSS) están trabajando intensamente en estos temas.
Como se señala en FEEP, el diseño y la implementación del software tiene un impacto significativo en el consumo de energía de los sistemas de los que forma parte. Con las herramientas adecuadas, es posible cuantificar y reducir el consumo de energía. Esta mayor eficiencia contribuye a un uso más sostenible de la energía como uno de los recursos compartidos de nuestro planeta.
BE4FOSS apoya a la FEEP recogiendo y difundiendo información relacionada con la ecocertificación Blauer Engel (BE), la ecoetiqueta oficial otorgada por el gobierno alemán. Como se indica en el sitio web de KDE Eco, la obtención de la etiqueta Blauer Engel se produce en 3 pasos: (1) Medir, (2) Analizar, (3) Certificar.
- MEDIR en laboratorios especializados, como el de KDAB Berlín
- ANALIZAR utilizando herramientas estadísticas, como OSCAR (Open source Software Consumption Analysis in R)
- CERTIFICAR mediante la presentación del informe sobre el cumplimiento de los criterios Blauer Engel
En SoK'22, prepararé escenarios de uso estándar para varios editores de texto de modo que los escenarios de uso puedan utilizarse en el Paso 1 para obtener la eco-certificación BE.
Lo que he hecho y estaré haciendo en las próximas semanas
Durante las últimas tres semanas, he probado varias herramientas de automatización, en particular Actiona, xdotool, y GNU Xnee, para decidir cuál de de estas herramientas sería la mejor para implementar los escenarios de uso estándar.
Mientras usaba Actiona, escribí algo de documentación para que esta información también sea beneficiosa para cualquiera que quiera contribuir a KDE Eco.
Mientras probaba xdotool, me encontré con un problema de pérdida de memoria. Ejecutando Valgrind en la búsqueda de xdotool obtengo más pérdidas de memoria asignada por XQueryTree. Probablemente hay otros lugares donde la memoria se asigna y no se libera después. No he hecho una comprobación exhaustiva, sin embargo, xdotool da más control sobre el sistema e incluso con algunos problemas, esta es la herramienta que encontré más útil.
También probé GNU Xnee, que me pareció interesante, ya que registra la salida y la almacena en un archivo separado. Además, proporciona un reproductor que se puede utilizar para automatizar las tareas a cualquier velocidad que uno quiera.
Al final, he decidido preparar todos los escenarios de uso con xdotool, al menos inicialmente, ya que la mayoría de los editores de texto utilizan funciones del teclado en lugar de la actividad del ratón y esto facilitará la adaptación del script a diferentes sistemas. Sin embargo, después de SoK'22 planeo preparar escenarios de uso con Actiona para aprender las diferencias entre estas herramientas. También hay una discusión en curso sobre reutilización de los escenarios de uso estándar para probar la capacidad de respuesta y el rendimiento en hardware hardware de gama baja.
En las próximas semanas, trabajaré adicionalmente en arreglar un problema que es conocido para Actiona. El problema es que emula el comportamiento del usuario al almacenar la posición de los clics en base a coordenadas de píxeles, o que puede hacer transferir un script a otro sistema. Por ejemplo, este problema surgió recientemente al preparar un escenario de uso estándar para GCompris. Se me ocurrió la solución de cambiar el tamaño de la pantalla a una resolución mínima e incluir el código al principio del script de Actiona. Cada vez que el script se ejecuta en un sistema diferente, se redimensiona automáticamente a la resolución mínima para que coincida con los píxeles mientras se hace el script. Esto es sólo una idea y aún no está probado. Reservaré tiempo para intentar arreglar el problema con la ayuda de el equipo de GCompris.
El repositorio de GitLab que contiene los escenarios de uso estándar en curso (actualmente GCompris usando Actiona) se puede encontrar aquí.
Relaciones con la comunidad ( SoK'22 )
Agradezco a mi mentor Joseph P. De Veaugh-Geiss por dedicar su tiempo a ayudarme proporcionándome recursos y orientación durante el proyecto. También asistí al encuentro mensual de la comunidad KDE Eco el 9 de febrero de 2022, donde el Prof. Dr. Stefan Naumann, Achim Guldner y Christopher Stumpf del Umwelt Campus Birkenfeld dirigieron un debate sobre la medición del consumo de energía de los sistemas distribuidos y la ampliación de los criterios Blauer Engel a ellos. Fue una reunión interesante en la que se discutieron los problemas de automatización de las aplicaciones móviles, así como las pruebas cliente-servidor. Joseph también me presentó a los investigadores de Umwelt Campus que midieron el consumo de energía de Okular; Emmanuel Charruau, que trabaja con el script GCompris; y Nicolas Fella, que trabaja actualmente con xdotool para su tesis de master sobre el consumo energético del software.
Gracias por tomarse el tiempo de leer esta actualización. Si alguien quiere hacer un seguimiento de las ideas presentadas aquí con respecto a los pros y los contras de diferentes herramientas de automatización cuando se implementan escenarios de uso estándar, hay un GitLab issue en el repositorio de BE4FOSS donde podemos discutir más.
También estoy disponible en la instancia Matrix de KDE en drquark:kde.org.