Sprint KDE Eco 2021: Detalles de la planificación comunitaria del proyecto ecológico de KDE

Esto es una continuación del anuncio de KDE Eco Sprint publicado en The Dot.

El 11 de diciembre de 2021, KDE Eco celebró el primero de muchos Sprints planificados, con la asistencia de 7 personas. El Sprint originalmente estaba destinado a ser un evento en persona para establecer un laboratorio de medición comunitario, pero el COVID tenía otras ideas. Sin embargo, la comunidad desplegó su ingenio habitual y, en cambio, nos reunimos en línea.

Anuncio de KDE Eco 2021 Sprint en las noticias de KDE

En esta publicación de formato largo, proporcionaré una descripción detallada de los principales problemas discutidos en el Sprint y sus resultados; ver también las actas para más detalles.

¿Sabías que...?

Discusiones similares a estas ocurren mensualmente en nuestras reuniones comunitarias el segundo miércoles del mes de 19 a 20 horas CET/CEST (hora de Berlín).

Creando un equipo KDE Eco

KDE Eco consta actualmente de tres proyectos relacionados: (i) Proyecto de eficiencia energética de código abierto y libre (FEEP), (ii) Blauer Engel para FOSS (BE4FOSS) y (iii) Certificaciones Blauer Engel. Cada proyecto tiene supropio enfoque particular: FEEP se preocupa por medir el consumo de energía del Software Libre, BE4FOSS se enfoca en la organización comunitaria y la difusión de información sobre la ecoetiqueta Blauer Engel, y el repositorio de solicitudes de Blauer Engel alberga todos los documentos relacionados con la certificación de KDE/Software Libre con la ecoetiqueta. Hasta el Sprint, los tres repositorios estaban alojados en varios espacios de nombres personales. Ahora, los tres se pueden encontrar en https://invent.kde.org/teams/eco.

Tener los proyectos bajo un solo equipo vincula más claramente estos y posibles proyectos futuros. Además, tener un espacio de nombres no personal es más apropiado para proyectos comunitarios. ¡No dude en consultar las actividades de cada proyecto en el espacio del equipo anterior!

Equipos > KDE Eco

Completando la solicitud de Blauer Engel para Okular

Hay tres aplicaciones de KDE cuyo consumo de energía ya se ha medido: Okular, KMail, y Krita. De estas tres, las certificaciones de Blauer Engel para Okular y KMail han estado en preparación durante algún tiempo, y uno de los objetivos era completar la certificación de Okular. Nos enorgullece anunciar que, después del Sprint, se envió la solicitud de Okular y actualmente se encuentra bajo revisión para la certificación. Esperamos comentarios de RAL gGmbH,el organismo que otorga el Blauer Engel, dentro de 2 a 3 meses. El envío de KMail le seguirá pronto.

Durante una revisión grupal de la aplicación Okular, los participantes plantearon muchos temas interesantes. Uno, por ejemplo, surgió al discutir los criterios de transparencia del Blauer Engel (Sección 3.1.3.2). Malte Reißig del Grupo de investigación de IASS sobre "Transformaciones de la digitalización y la sostenibilidad" destacó cómo el desarrollo abierto puede afectar positivamente algunos de los otros requisitos de los criterios de adjudicación (ver esta discusión), como la capacidad de mantenimiento a largo plazo y la autonomía del usuario de un producto de software. Es decir, los usuarios de Software Libre no sólo utilizan pasivamente el software, sino que se animan y pueden expresar sus deseos para el desarrollo futuro de las aplicaciones, y pueden participar activamente en la planificación de hitos. Además, con el desarrollo abierto, los commits se pueden vincular a problemas o errores específicos informados por una comunidad de usuarios y desarrolladores. Con el Software Libre, una aplicación no es solo un producto final, sino un proceso abierto que refleja las necesidades y deseos de sus usuarios y sus comunidades. ¡Con FOSS, la comunidad impulsa la dirección del desarrollo!

Icono de Okular

Otro tema estaba relacionado con la distribución del Software Libre y cómo éste presenta desafíos para el cumplimiento de los criterios de Blauer Engel. Dado que el software libre suele distribuir el software de forma descentralizada, para cualquier aplicación hay numerosos canales de distribución. Considere Okular, que está empaquetado no sólo para Flatpak, sino también también en la Tienda de Microsoft, por no hablar de numerosas distros GNU/Linux (por ejemplo openSUSE, Debian). Las diferencias en la infraestructura de la paquetería pueden afectar al cumplimiento de los requisitos de Blauer Engel, como la desinstalabilidad, la modularidad, etc.

Las empresas que lanzan software propietario, por lo general con despliegue centralizado de sus productos, no tendrán estos problemas. A la luz de esto, una posibilidad que el grupo discutió es certificar solo el código fuente de un programa, permaneciendo neutral acerca de las diferencias en cómo un producto de software es empaquetado y distribuido. Otra posibilidad es certificar lanzamientos específicos de distribución, como el de la tienda Microsoft Store. De hecho, este último podría utilizarse con fines de marketing para llegar a nuevos usuarios y atraerlos a la comunidad de KDE; consulte, por ejemplo, [esta discusión] (https://invent.kde.org/teams/eco/blue-angel-application/-/issues/56).

Nos encantaría saber lo que piensa. ¡Únase a la conversación en nuestra lista de correo, sala de Matrix o a través de la web de reporte de bugs en nuestros repositorios de GitLab!

Escenarios de uso estándar

Un escenario de uso estándar (SUS) refleja las funciones típicas de una aplicación, teniendo en cuenta la frecuencia de esas funciones. Los escenarios de uso estándar son fundamentales para medir el consumo de energía de un software.

Al revisar los registros de acciones del SUS de Okular para la aplicación Blauer Engel, surgieron dos puntos importantes que mejorarán la aplicación del SUS cuando se realicen mediciones en el laboratorio. Uno de ellos fue la observación de la necesidad de documentar no sólo las acciones, sino también los objetos de las acciones (por ejemplo, cuando se utiliza un lector de pdf, qué pdf se abre), ya que esto puede influir en el consumo de energía. El otro fue, que la inclusión de la inactividad es importante a la hora de definir un SUS: la acción de reposo es realista y puede mostrar que no está ocurriendo nada cuando se supone que no está ocurriendo nada.

Varios otros temas fueron llevados a la mesa virtual. Nicolas Fella, ingeniero de software de KDAB Berlín, expresó interés en comparar dos clientes de chat, lo que derivo la conversación a definir escenarios únicos para comparar dos aplicaciones con un uso similar. Un solo SUS limitará qué funciones de software se pueden probar, pero hará que los resultados de las mediciones sean directamente comparables. Además, para el software cliente-servidor, como los clientes de chat o correo electrónico, existe el problema del componente de red, que para las pruebas controladas requeriría configurar y medir el consumo de energía de un servidor. Cornelius Schumacher, antiguo presidente de KDE e.V. y colaborador de KDE desde hace mucho tiempo, señaló que para las mediciones de KMail solo se midió el trabajo informático en la máquina local. La medición de la computación no local en el software cliente-servidor es más relevante que nunca en el mundo de hoy, y esto está actualmente planificado para los criterios revisados para otorgar Blauer Engel para software.

Iamgen de bienvenida de KMail

Otro tema discutido fue la definición de acciones SUS de manera abstracta para automatizar la implementación de escenarios de uso con diferentes herramientas (Actiona, xdotool, KXmlGui, etc.). Un punto importante fue que las diferentes herramientas de emulación hacen cosas diferentes, lo que podría presentar desafíos para la automatización del proceso. Por ejemplo, no se puede escribir texto cuando se usa KXmlGui para la emulación y, por lo tanto, es posible que aún se necesite algo como xdotool. En una nota relacionada, otra propuesta fue estructurar un SUS de tal manera que también se pueda automatizar la creación de un registro de acciones. ¿Alguien en la comunidad quiere ayudar a enfrentar estos desafíos?

Además, el grupo discutió cómo los escenarios de uso también podrían reutilizarse para probar la capacidad de respuesta y el rendimiento general en hardware antiguo o de gama baja. ¿Cuáles son sus ideas?

¿Sabía que planeamos realizar un maratón de medidas para medir el consumo de energía de las aplicaciones FOSS/KDE a principios de 2022? ¿Para qué aplicaciones le gustaría ver escenarios de uso estándar preparados? ¡Comparta sus ideas con nosotros aquí o envíe su SUS a nuestro repositorio de GitLab!

Sistema de referencia replicable

Los escenarios de uso estándar se ejecutan en un sistema de referencia, y un tema importante que se planteó fue cómo tener un sistema de referencia replicable. Hay varias capas del sistema a considerar: Hardware (CPU, disco, RAM, etc.); el sistema operativo sus servicios, como por ejemplo el administrador de actividades en Plasma, así como sus configuraciones; y la configuración de la aplicación probada, así como cualquier aplicación relacionada (por ejemplo, Akonadi para aplicaciones PIM). Por un lado, es necesario tener un ambiente controlado para poder interpretar los resultados; por otro lado, es deseable tener mediciones que reflejen entornos informáticos reales, quizás incluso ruidosos, para comprender el consumo de energía del software en el mundo real. Al final, tener entornos informáticos controlados o naturales dependerá de para qué se vayan a utilizar los datos, y esto será diferente para investigadores, desarrolladores, auditores de ecoetiquetas, empresas, etc.

Por ejemplo, para los desarrolladores interesados en realizar pruebas unitarias de eficiencia energética u obtener el sello Blauer Engel, será necesario contar con entornos claramente especificados. Entonces, ¿cuáles son las formas convenientes y rápidas de llevar el sistema a un estado conocido? Se discutieron tres ideas: (i) tomar instantáneas de un sistema de archivos (por ejemplo, Snapper), (ii) borrar el caché del sistema y (iii) reemplazar los archivos de configuración. Si tienes otras ideas, ¡cuéntenoslas aquí!

Para entornos del mundo real, una propuesta, potencialmente controvertida, es registrar el rendimiento del hardware y el uso de energía eléctrica mientras las personas usan sus computadoras personales. ¿Algun voluntario?

Salida de datos

Al medir el consumo de energía en un laboratorio, en particular para la ecocertificación de Blauer Engel, se pueden generar tres tipos de archivos de datos: (i) un archivo de registro de acciones (ver más arriba sobre la automatización de dichos archivos de registro), (ii) datos de rendimiento del hardware (CPU, RAM, etc.), y (iii) uso de energía eléctrica. Dado que en algunos casos los datos de salida deberán autodefinirse (p. ej., registros de marca de tiempo en scripts xdotool), es necesario considerar cómo deberían ser los datos antes de medirlos en el laboratorio.

Se plantearon varias cuestiones relacionadas con los datos: ¿Debería estandarizarse la producción de datos para armonizar la producción en todas las campañas de medición, o es suficiente simplemente publicar los datos recopilados en un formato accesible (por ejemplo, como archivos .csv, como en el repositorio FEEP)? ¿Qué exactitud de marca de tiempo se necesita (por ejemplo, segundos frente a fracciones de segundo)? Estas preguntas permanecen abiertas por ahora, pero el grupo decidió que necesitamos una descripción general de los dispositivos/scripts compatibles con FOSS (p. ej., el script de Achim Guldner para Gude Expert Power Control 1202 Series) y kits de herramientas (p. ej., herramientas de análisis estadístico como OSCAR, R , Julia, Octave, PSPP, NumPy) utilizado para mediciones y análisis, que actualmente está en desarrollo.

Dispositivos de medición de energía

Los criterios de Blauer Engel se refieren a dos medidores de potencia (PM) en particular: Janitza UMG 604 y Gude Expert Power Control 1202. Estos dispositivos no son baratos. En 2020, el antiguo colaborador de KDE, Volker Krause, hackeó un enchufe de 8 EUR y escribió sobre ello. Como se comenta en la publicación del blog, estos enchufes económicos pueden obtener una frecuencia de muestreo de hasta 200 ms. Esto condujo a la idea de utilizar medidores de potencia económicos en laboratorios domésticos de bajo presupuesto. Para este propósito, eventualmente será útil comparar los resultados de los medidores de potencia profesionales con los económicos para ver cómo se comportan. ¿Alguien en la comunidad estaría interesado en hacer esto?

Del áritculo del blog de Volker Krause: "Ejemplo de medición (muestra de 200 ms intervalo, sin filtro): el cursor del mouse se mueve entre las muestras 100 y 150, con un pico mientras se desplaza sobre una entrada de la barra de tareas".

Otra forma de medir el consumo de energía vino del colaborador de KDE, David Hurka, quien tiene una propuesta de sensores de potencia USB SPI para proporcionar una alternativa de mayor resolución a los medidores de potencia que miden en la toma de corriente.

Cuestiones abiertas para los laboratorios de medición

Se discutieron varios otros temas relacionados con el consumo de energía y las mediciones de laboratorio. Aunque no se tomaron decisiones finales en todos los casos, será importante considerar muchos de estos temas abiertos en el futuro.

• Idea de una herramienta de marketing amigable para llamar la atención sobre el consumo de energía del software.
  • Por ejemplo, un botón 'Eco' para la eficiencia energética/medidor de huella de carbono (véase la huella de carbono de viaje en la aplicación Itinerario).
  • Nótese que una funcionalidad similar ya es proporcionada por PowerTop, aunque quedan cuestiones abiertas (¿cuándo es seguro habilitarla para evitar la pérdida de datos, cuelgues de la máquina?.
• ¿Cuándo los inconvenientes superan las ventajas de la compatibilidad con el hardware antiguo?
  • Invitemos a los investigadores que trabajan en esto a discutir con la comunidad de KDE Eco.
• Colaboración futura:
  • ¿Sprint conjunto con proyectos relacionados (por ejemplo, SoftAWERE)? (Quizás sea de su interés lo que Max Schulze de SoftAWERE/SDIA presentó en la reunión mensual de KDE Eco en enero de 2022, cuyas actas puede leer [aquí]](https://invent.kde.org/teams/eco/be4foss/-/blob/master/community-meetups/2022-01-12_community-meetup_protocol.md).)
  • ¿Discutir los temas anteriores y más con otras comunidades relacionadas (Bits & Bäume, Foro Informáticos por la Paz y la Responsabilidad Social, etc.)?

Conclusión

El Sprint en línea fue una oportunidad maravillosa para unir a la comunidad y hacer avanzar el proyecto KDE Eco, especialmente mientras nos preparamos para el laboratorio de medición de la comunidad que se llevará a cabo en KDAB Berlín y el primero de muchos maratones de medición (planeados para principios de 2022)! El éxito de este tipo de eventos depende ante todo de la comunidad, así que permítanos enviar un sincero agradecimiento a todos los que se unieron a la conversación. ¡Esperamos hacer que la comunidad crezca en 2022! Además, no podríamos hacer lo que hacemos sin el apoyo de KDE e.V. así como de BMU/UBA, quienes apoyan financieramente el proyecto BE4FOSS (aunque solo el editor es responsable del contenido de esta publicación).

Aviso de financiación

El proyecto BE4FOSS fue financiado por la Agencia Federal de Medio Ambiente y el Ministerio Federal de Medio Ambiente, Protección de la Naturaleza, Seguridad Nuclear y Protección al Consumidor (BMUV¹). Los fondos se facilitan mediante una resolución del Parlamento Federal Alemán.

El editor es responsable del contenido de esta publicación.

¹ Los logos oficiales BMUV y UBA se envían solo por solicitud: verbaendefoerderung@uba.de

Artículo escrito por Joseph P. De Veaugh-Geiss bajo las condiciones de la licencia CC-BY-4.0.