KDE Eco 2021 Sprint: Detalhes sobre o planejamento da comunidade para o projeto ecológico do KDE

Este é um acompanhamento do anúncio do KDE Eco Sprint publicado no The Dot.

Em 11 de dezembro de 2021, o KDE Eco realizou o primeiro de muitos Sprints planejados, com a presença de 7 pessoas. O Sprint foi originalmente planejado para ser um evento presencial para montar um laboratório de medição comunitário, mas o Corona tinha outras ideias. Mesmo assim, a comunidade usou sua engenhosidade habitual e nos reunimos online.

Anúncio do KDE Eco 2021 Sprint no KDE News

Nesta publicação longa, fornecerei uma visão geral detalhada dos principais problemas discutidos no Sprint e seus resultados; veja também a ata para mais detalhes.

Você sabia?

Discussões semelhantes a essas ocorrem mensalmente em nossos encontros comunitários, na 2ª quarta-feira de cada mês, das 19h às 20h CET/CEST (horário de Berlim).

Criando uma equipe KDE Eco

Atualmente, o KDE Eco consiste em três projetos relacionados: (i) Projeto de eficiência energética livre e de código aberto (FEEP, sigla em inglês), (ii) Blauer Engel para Software Livre (BE4FOSS) e (iii) Aplicativos Blauer Engel. Cada projeto tem seu próprio foco específico: o FEEP se preocupa em medir o consumo de energia do Software Livre, o BE4FOSS se concentra na organização comunitária e na disseminação de informações sobre o selo ecológico Blauer Engel, e o repositório de Aplicativos Blauer Engel hospeda todos os documentos relacionados à certificação do KDE/Software Livre com o selo ecológico. Até o Sprint, os três repositórios para os projetos estavam hospedados em vários namespaces pessoais. Agora, todos os três repositórios podem ser encontrados em https://invent.kde.org/teams/eco.

Ter os projetos sob a mesma equipe os conecta mais claramente a possíveis projetos futuros. Além disso, ter um namespace não pessoal é mais apropriado para projetos comunitários. Sinta-se à vontade para conferir as atividades de cada projeto no espaço da equipe acima!

Equipes > KDE Eco

Preenchendo o requerimento Blauer Engel para o Okular

Existem três aplicativos do KDE cujo consumo de energia já foi medido: Okular, KMail, e Krita.Destes três, as aplicações Blauer Engel para Okular e KMail estão em preparação há algum tempo, e um dos objetivos era completar o aplicativo do Okular. Temos o orgulho de anunciar que, após o Sprint, a inscrição da Okular foi enviada e está atualmente em análise para certificação. Aguardamos o retorno da RAL gGmbH, a entidade que concede o prêmio Blauer Engel, dentro de 2 a 3 meses. A submissão do KMail será feita em breve.

Durante uma análise em grupo do aplicativo Okular, os participantes levantaram muitos pontos interessantes. Um ponto, por exemplo, surgiu ao discutir os critérios de transparência do Blauer Engel (Seção 3.1.3.2). Malte Reißig, do Grupo de Pesquisa do IASS sobre "Transformações em Digitalização e Sustentabilidade", destacou como o desenvolvimento aberto pode afetar positivamente alguns dos outros requisitos dos critérios do prêmio (veja esta discussão), como a manutenibilidade a longo prazo e a autonomia do usuário de um produto de software. Ou seja, os usuários de Software Livre não apenas usam o software passivamente, mas também são incentivados e capazes de expressar desejos para o desenvolvimento futuro de aplicações, podendo participar ativamente do planejamento de marcos. Além disso, com o desenvolvimento aberto, as mensagens de confirmação podem ser vinculadas a problemas ou bugs específicos relatados por uma comunidade de usuários e desenvolvedores. Com o Software Livre, uma aplicação não é apenas um produto final, mas um processo aberto que reflete as necessidades e desejos de seus usuários e de suas comunidades. Com o Software Livre, a comunidade impulsiona a direção do desenvolvimento!

Ícone do Okular

Outro ponto estava relacionado à distribuição de Software Livre e como ela apresenta desafios para o cumprimento dos critérios de Blauer-Engel. Como o Software Livre normalmente distribui software de forma descentralizada, para qualquer aplicativo, existem inúmeros canais de lançamento e distribuição. Considere o Okular, que é empacotado não apenas para o Flatpak, mas também para a Microsoft Store, sem mencionar inúmeras distribuições GNU/Linux (por exemplo, OpenSuse, Debian). Diferenças na infraestrutura de empacotamento podem afetar o cumprimento dos requisitos da Blauer Engel, como desinstalação, modularidade, etc.

Empresas que lançam software proprietário, normalmente com implantação centralizada de seus produtos, não terão esses problemas. Diante disso, uma possibilidade discutida pelo grupo é certificar apenas o código-fonte de um programa, permanecendo neutro quanto às diferenças na forma como um produto de software é empacotado e distribuído. Outra possibilidade é certificar versões específicas de distribuição, como a da Microsoft Store. De fato, esta última poderia ser usada para fins de marketing para alcançar novos usuários e atraí-los para a comunidade KDE — veja, por exemplo, esta discussão.

Gostaríamos muito de saber o que você pensa. Participe da conversa em nossa lista de discussão ou sala Matrix ou através dos rastreadores de problemas em nossos repositórios do GitLab!

Cenários de uso padrão

Um Cenário de Uso Padrão (SUS, em inglês) reflete as funções típicas de um aplicativo, levando em consideração a frequência dessas funções. Os Cenários de Uso Padrão são essenciais para medir o consumo de energia de um software.

Ao revisar os registros de ações do SUS para o Okular para a aplicação Blauer Engel, foram levantados dois pontos importantes que melhorarão a implementação do SUS em medições em laboratório. Um deles foi a observação sobre a necessidade de documentar não apenas as ações, mas também os objetos das ações (por exemplo, ao usar um leitor de PDF, qual PDF é aberto), pois isso pode influenciar o consumo de energia. O outro ponto foi que incluir ações ociosas é importante ao definir um SUS: ações ociosas são realistas e podem mostrar que nada está acontecendo quando nada deveria estar acontecendo.

Várias outras questões foram trazidas à mesa virtual. Nicolas Fella, engenheiro de software da KDAB Berlin, demonstrou interesse em comparar dois clientes de bate-papo, o que levou a conversa a definir cenários únicos ao comparar dois aplicativos com uso semelhante. Um único SUS limitará quais funções de software podem ser testadas, mas tornará os resultados das medições diretamente comparáveis. Além disso, para software cliente-servidor, como clientes de bate-papo ou e-mail, há a questão do componente de rede, que, para testes controlados, exigiria a configuração e a medição do consumo de energia de um servidor. O ex-KDE e.V., presidente e colaborador de longa data do KDE, Cornelius Schumacher, destacou que, para as medições do KMail, apenas o trabalho computacional na máquina local foi medido. Medir a computação não local em software cliente-servidor é mais relevante do que nunca no mundo atual, e isso está atualmente planejado para os critérios revisados ​​do prêmio Blauer Engel para software.

Tela de boas-vindas do KMail

Outro tópico discutido foi a definição abstrata de ações do SUS para automatizar a implementação de cenários de uso com diferentes ferramentas (Actiona, xdotool, KXmlGui, etc.). Um ponto importante foi que diferentes ferramentas de emulação realizam funções diferentes, o que poderia apresentar desafios à automatização do processo. Por exemplo, não é possível digitar texto ao usar KXmlGui para emulação e, portanto, algo como xdotool ainda pode ser necessário. Em uma nota relacionada, outra proposta foi estruturar um SUS de forma que a criação de um log de ações também possa ser automatizada. Alguém na comunidade gostaria de ajudar a lidar com esses desafios?

Além disso, o grupo discutiu como cenários de uso também poderiam ser reaproveitados para testar a responsividade e o desempenho geral em hardware mais antigo ou de baixo custo. Quais são suas ideias?

Você sabia que estamos planejando uma maratona de medidas para mensurar o consumo de energia de aplicativos FOSS/KDE no início de 2022? Para quais aplicativos você gostaria de ver Cenários de Uso Padrão preparados? Compartilhe suas ideias conosco aqui ou envie seu SUS em nosso repositório GitLab!

Sistema de referência replicável

Cenários de Uso Padrão são executados em um sistema de referência, e uma questão importante levantada foi como ter um sistema de referência replicável. Há várias camadas do sistema a serem consideradas: Hardware (CPU, Disco, RAM, etc.); o SO e os serviços do SO, como o gerenciador de atividades no Plasma, bem como suas configurações; e a configuração do aplicativo testado, bem como quaisquer aplicativos relacionados (por exemplo, Akonadi para aplicativos PIM). Por um lado, é necessário ter um ambiente controlado para poder interpretar os resultados; por outro lado, é desejável ter medições que reflitam ambientes de computação reais, talvez até mesmo ruidosos, para entender o consumo de energia do software no mundo real. No final, a escolha de ambientes de computação controlados ou naturais dependerá da finalidade dos dados, e isso será diferente para pesquisadores, desenvolvedores, auditores de selos ecológicos, empresas, etc.

Por exemplo, para desenvolvedores interessados ​​em realizar testes unitários de eficiência energética ou obter o selo Blauer Engel, será necessário ter ambientes claramente especificados. Então, quais são as maneiras convenientes e rápidas de levar o sistema a um estado conhecido? Três ideias foram discutidas: (i) tirar snapshots de um sistema de arquivos (por exemplo, Snapper), (ii) limpar o cache do sistema e (iii) substituir os arquivos de configuração. Se você tiver outras ideias, compartilhe-as aqui!

Para ambientes do mundo real, uma proposta, potencialmente controversa, é registrar o desempenho do hardware e o consumo de energia elétrica enquanto as pessoas usam seus computadores pessoais. Algum voluntário?

Saída de dados

Ao medir o consumo de energia em um laboratório, em particular para a certificação ecológica da Blauer Engel, três tipos de arquivos de dados podem ser gerados: (i) um arquivo de log de ações (veja acima sobre a automação desses arquivos de log), (ii) dados de desempenho de hardware (CPU, RAM, etc.) e (iii) consumo de energia elétrica. Como, em alguns casos, os dados de saída precisarão ser autodefinidos (por exemplo, registradores de registro de data e hora em scripts xdotool), é necessário considerar como os dados devem ser antes da medição no laboratório.

Várias questões foram levantadas em relação aos dados: a saída de dados deve ser padronizada para harmonizar a saída entre as campanhas de medição ou basta publicar os dados coletados em um formato acessível (por exemplo, como arquivos .csv, como no repositório FEEP)? Qual a exatidão do registro de tempo necessária (por exemplo, segundos vs. frações de segundos)? Essas questões permanecem em aberto por enquanto, mas o grupo decidiu que precisamos de uma visão geral dos dispositivos/scripts compatíveis com FOSS (por exemplo, o script de Achim Guldner para o Gude Expert Power Control Série 1202) e kits de ferramentas (por exemplo, ferramentas de análise estatística como OSCAR, R, Julia, Octave, PSPP, NumPy) usados ​​para medições e análises, que está atualmente em andamento.

Dispositivos de medição de energia

Os critérios Blauer Engel referem-se a dois medidores de potência (MP) em particular: Janitza UMG 604 e Gude Expert Power Control 1202. Esses dispositivos não são baratos. Em 2020, Volker Krause, colaborador de longa data do KDE, hackeou um plugue de energia de 8 euros e escreveu sobre isso. Conforme descrito na postagem do blog, esses plugues de energia baratos conseguem obter uma taxa de amostragem de até 200 ms. Isso levou à ideia de usar medidores de potência baratos em laboratórios domésticos de baixo orçamento. Para esse propósito, eventualmente será útil comparar os resultados de medidores de potência profissionais com os mais baratos para ver como eles se comparam. Alguém na comunidade estaria interessado em fazer isso?

Da Postagem do Blog de Volker Krause: "Exemplo de medição (intervalo de amostragem de 200 ms, sem filtro): cursor do mouse sendo movido entre as amostras 100 e 150, com um pico ao passar o mouse sobre uma entrada da barra de tarefas."

Outra maneira de medir o consumo de energia veio do colaborador do KDE, David Hurka, que tem uma proposta para sensores de energia USB SPI para fornecer uma alternativa de maior resolução aos medidores de energia medidos na tomada.

Questões em aberto para laboratórios de medição

Diversas outras questões relacionadas ao consumo de energia e às medições laboratoriais foram discutidas. Embora decisões finais não tenham sido tomadas em todos os casos, muitas dessas questões em aberto serão importantes para serem consideradas no futuro.

• Ideia de uma ferramenta de marketing para chamar a atenção para o consumo de energia do software.
  • Por exemplo, um botão "Eco" para medidor de eficiência energética/pegada de carbono (veja a pegada de carbono da viagem no aplicativo Itinerary).
  • Observe que uma funcionalidade semelhante já é fornecida pelo PowerTop, embora ainda existam questões em aberto (quando é seguro habilitá-la para evitar perda de dados e travamentos da máquina?).
• Quando as desvantagens superam os benefícios do suporte para hardware mais antigo?
  • Vamos convidar pesquisadores que trabalham nisso para discutir com a comunidade KDE Eco.
• Colaboração futura:
  • Sprint conjunto com projetos relacionados (por exemplo, SoftAWERE)? (Talvez de interesse para o leitor: Max Schulze, da SoftAWERE/SDIA, apresentou-se no encontro mensal do KDE Eco em janeiro de 2022, cuja ata você pode ler [aqui](https://invent.kde.org/teams/eco/be4foss/-/blob/master/community-meetups /2022-01-12_community-meetup_protocol.md).)
  • Discussão dos tópicos acima e muito mais com outras comunidades relacionadas (Bits & Bäume, Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung, etc.)?

Conclusão

O Sprint online foi uma oportunidade maravilhosa para reunir a comunidade e impulsionar o projeto KDE Eco, especialmente enquanto nos preparamos para o laboratório de medição comunitário que será realizado no KDAB Berlin e para o primeiro de muitos eventos de medição (planejados para o início de 2022)! O sucesso de tais eventos depende, antes de tudo, da comunidade, então permitam-nos enviar um sincero agradecimento a todos que participaram da conversa. Estamos ansiosos para fazer a comunidade crescer em 2022! Além disso, não poderíamos fazer o que fazemos sem o apoio do KDE e.V., bem como da BMU/UBA, que apoiam financeiramente o projeto BE4FOSS (embora apenas a editora seja responsável pelo conteúdo desta publicação).

Nota de financiamento

O projeto BE4FOSS foi financiado pela Agência Federal do Meio Ambiente e pelo Ministério Federal do Meio Ambiente, Conservação da Natureza, Segurança Nuclear e Proteção ao Consumidor (BMUV¹). Os recursos são disponibilizados por resolução do Bundestag Alemão.

O editor é responsável pelo conteúdo desta publicação.

¹ Os logotipos oficiais da BMUV e da UBA são enviados somente mediante solicitação para: verbaendefoerderung@uba.de

Artigo contribuído por Joseph P. De Veaugh-Geiss sob a licença CC-BY-4.0.