'Sprint' do KDE Eco 2021: Detalhe sobre o Planeamento da Comunidade para o Projecto Ecológico do KDE

Este é um seguimento ao anúncio do 'Sprint' do KDE Eco publicado no The Dot.

A 11 de Dezembro de 2021, o KDE Eco realizou o primeiro de muitos 'Sprints' planeados, com 7 pessoas a assistir. O 'Sprint' foi originalmente pensado como um evento presencial para definir um laboratório de medições da comunidade, mas o Corona tinha outros planos. Contudo, a comunidade ofereceu a sua capacidade de gerar recursos e encontrámo-nos 'online' em alternativa.

Anúncio do Sprint do KDE Eco 2021 nas Notícias do KDE

Nesta publicação longa, será dada uma visão geral detalhada das questões principais discutidas no Sprint e os seus resultados; veja também as actas para saber mais detalhes.

Sabia que?

Outras discussões semelhantes a estas ocorrem mensalmente nas nossas reuniões da comunidade na 2a Quarta-Feira do mês, das 19h-20h CET/CEST (Hora de Berlim).

Criar uma equipa do KDE Eco

O KDE Eco consiste neste momento em três projectos relacionados: (i) Free and open source Energy Efficiency Project (FEEP), (ii) Blauer Engel For FOSS (BE4FOSS) e (iii) Candidaturas para o Blauer Engel. Cada projecto tem o seu foco em particular: o FEEP preocupa-se com a medição do consumo de energia do 'Software' Livre, o BE4FOSS foca-se na organização da comunidade e na difusão de informação sobre a certificação ecológica Blauer Engel, e o repositório de Candidaturas do Blauer Engel aloja todos os documentos relacionados com a certificação de 'Software' Livre/KDE com o emblema associado. Até ao 'Sprint', os três repositórios dos projectos estavam alojados em vários espaços de nomes pessoais. Agora, todos os três repositórios podem ser encontrados em https://invent.kde.org/teams/eco.

Ter os projectos debaixo de uma mesma equipa liga-os de forma mais clara com outros projectos futuros. Para além disso, ter um espaço de nomes não pessoal é mais apropriado para projectos comunitários. Sinta-se à vontade para ver as actividades de cada projecto no espaço da equipa acima!

Equipas > KDE Eco

Finalizar a candidatura ao Blauer Engel do Okular

Existem três aplicações do KDE cujo consumo de energia já foi medido: o Okular, o KMail e o Krita. Destas três, as candidaturas para Blauer Engel do Okular e do KMail têm estado em preparação durante algum tempo, e um dos objectivos era terminar a candidatura do Okular. Estamos orgulhosos em anunciar que, a seguir ao 'Sprint', a candidatura do Okular foi submetida e está de momento em revisão para a certificação. Esperamos uma reacção da RAL gGmbH, o conselho de certificação da Blauer Engel, dentro de 2-3 meses. A submissão do KMail seguir-se-á em breve.

Durante uma revisão em grupo da aplicação Okular, os participantes levantaram muitos pontos interessantes. Um ponto, por exemplo, veio com a discussão dos critérios de transparência da Blauer Engel na (Secção 3.1.3.2). Malte Reißig, do Grupo de Investigação do IASS em "Digitalização e Transformações de Sustentabilidade" realçou como o desenvolvimento aberto poderá afectar de forma positiva alguns dos outros requisitos dos critérios de certificação (veja esta discussão), como a capacidade de manutenção a longo prazo e a autonomia do utilizador de um produto de 'software'. Isto é, os utilizadores de 'Software' Livre não usam apenas de forma passiva as aplicações, mas são encorajados e têm a possibilidade de formular pedidos para o desenvolvimento futuro das aplicações, podendo participar de forma activa no planeamento das etapas e marcos. Para além disso, com um desenvolvimento aberto, as mensagens de modificações podem ser associadas a problemas ou erros específicos relatados por uma comunidade de utilizadores e programadores. Com o 'Software' Livre, uma aplicação não é apensa um produto final, mas um processo aberto que reflecte as necessidades e desejos dos seus utilizadores e das suas comunidades. Com o FOSS, a comunidade conduz a direcção do desenvolvimento!

Ícone do Okular

Outro ponto foi relacionado com a distribuição do 'Software' Livre e como apresenta alguns desafios para o cumprimento dos critérios do Blauer Engel. Dado que o 'Software Livre distribui normalmente o 'software' de forma descentralizada, para qualquer aplicação existem inúmeros canais de distribuição e lançamento. Pense no Okular, para o qual existem pacotes não só para o Flatpak, como também na Loja da Microsoft, para não falar das diversas distribuições de GNU/Linux (p.ex., OpenSuse, Debian). As diferenças na infra-estrutura de pacotes poderá afectar o cumprimento dos requisitos do Blauer Engel, como a capacidade de desinstalação, modularidade, etc.

As empresas que lançam 'software' proprietário, tipicamente com uma instalação centralizada dos seus produtos, não terá estes problemas. À vista deste ponto, uma possibilidade que o grupo discutiu seria só certificar o código-fonte de um programa, mantendo-se assim neutro sobre as diferenças como é disponibilizado e distribuído um pacote de 'software'. Outra possibilidade é certificar versões específicas das distribuições, como acontece na Loja da Microsoft. De facto, o último caso pode ser usado para fins de 'marketing' para atingir novos utilizadores e trazê-los para a comunidade do KDE -- veja p.ex. esta discussão.

Gostaríamos de saber o que pensa sobre isto. Junte-se por favor à discussão na nossa lista de correio ou sala do Matrix ou através dos sistemas de registo de erros nos nossos repositórios do GitLab!

Cenários-Padrão de Utilização

Um Cenário-Padrão de Utilização (SUS - Standard Usage Scenario) reflecte as funções típicas de uma aplicação, com a frequência dessas funções tida em conta. Estes cenários são centrais para medir o consumo de energia de um bloco de 'software'.

Ao rever os registos de acção do SUS para o Okular e a sua candidatura à Blauer Engel, dois pontos importantes foram levantados que irão melhorar a implementação dos SUS's nas medições em laboratório. Um foi a observação sobre a necessidade não só de documentar as acções mas também os objectos das acções (p.ex., ao usar um leitor de PDF, qual o ficheiro PDF que é aberto), dado que isso pode influenciar o consumo de energia. O outro foi que incluir a acção de inactividade é importante ao definir um SUS: a acção de inactividade também é realista e poderá mostrar que nada acontece quando nada é suposto estar a acontecer.

Outras questões diversas foram levantadas nesta mesa virtual. Nicolas Fella, um engenheiro de 'software' no KDAB Berlin, expressou interesse na comparação de dois clientes de conversação, o que desviou a conversa para a definição de cenários individuais ao comparar duas aplicações com utilizações similares. Um SUS único iria limitar quais as funções do 'software' que poderiam ser testadas, mas faria com que os resultados das medições pudessem ser directamente comparáveis. Para além disso, para aplicações cliente-servidor, como um cliente de mensagens instantâneas ou de e-mail, existe a questão do componente de rede, que em testes controlados iria obrigar à configuração e medição do consumo de energia de um servidor. O antigo presidente da KDE e.V. e colaborador de longa data no KDE Cornelius Schumacher apontou que, para as medições do KMail só o trabalho de computação na máquina local era medido. A medição de computações não locais em aplicações cliente-servidor é mais relevante que nunca no mundo de hoje, e isto está de momento planeado para os critérios de certificação Blauer Engel revistos para o 'software'.

Ecrã de Boas-Vindas do KMail

Outro tópico discutido foi a definição das acções dos SUS's em abstracto, para poder automatizar a implementação de cenários de utilização com diferentes ferramentas (Actiona, xdotool, KXmlGui, etc.). um ponto importante foi que as ferramentas de emulação diferentes fazem coisas diferentes, o que poderá apresentar alguns desafios na automatização do processo. Por exemplo, uma pessoa não pode escrever texto ao usar o KXmlGui para a emulação e, como tal, será necessário à mesma algo como o xdotool. Numa nota relacionada, outra proposta foi estruturar um SUS de tal forma que a criação de um registo da acção possa também ser automatizado. Será que existe alguém na comunidade que gostasse de ajudar a resolver estes desafios?

Para além disso, o grupo discutiu como os cenários de utilização poderiam ser também adaptados para a conformidade aos testes e à performance geral nos computadores antigos ou de gama baixa. Quais são as suas ideias?

Sabia que estamos a pensar fazer uma maratona de medições para aferir o consumo de energia das aplicações FOSS/KDE no início de 2022? Quais as aplicações para as quais gostaria de ver Cenários-Padrão de Utilização serem preparadas? Partilhe as suas ideias connosco aqui ou submeta o seu SUS no nosso repositório de GitLab!

Sistema de referência replicável

Os Cenários-Padrão de Utilização são executados num sistema de referência e um problema importante enunciado foi como ter um sistema de referência replicável. Existem várias camadas de sistema a considerar: Hardware (CPU, Disco, RAM, etc.); o SO e os serviços do SO, como o gestor de actividades do Plasma, assim como as suas configurações próprias, ou a configuração das aplicações testadas ou de outras aplicações (p.ex., do Akonadi para as aplicações PIM). Por um lado, é necessário ter um ambiente controlado para poder interpretar os resultados; por outro, é desejável ter medições que reflictam os ambientes actuais, até mesmo com ruído computacional para compreender o consumo de energia do 'software' no mundo real. No fim, se deseja ter ambientes de computação naturais ou controlados irá depender para que serão usados os dados, e isto poderá diferir para investigadores, programadores, auditores de certificação, empresas, etc.

Por exemplo, para os programadores interessados em efectuar testes unitários de eficiência energética ou obter o emblema da Blauer Engel, será necessário ter ambientes claramente definidos. Por isso, quais serão as formas convenientes e rápidas de repor o sistema num estado conhecido? Foram discutidas três ideias: (i) salvaguardar imagens estáticas de um sistema de ficheiros (p.ex., Snapper), (ii) limpar a 'cache' do sistema e (iii) substituir os ficheiros de configuração. Se tiver outras ideias, deixe-nos saber mais sobre elas aqui!

Para os ambientes do mundo real, uma proposta, potencialmente controversa é registar a performance do 'hardware' e o consumo de energia eléctrica enquanto as pessoas utilizam os seus computadores pessoais. Existem voluntários?

Resultados dos dados

Ao medir o consumo de energia num laboratório, em particular para a certificação ecológica Blauer Engel, poderão ser gerados três tipos de ficheiros de dados: (i) um ficheiro de registo das acções (veja a automatização acima desses ficheiros), (ii) os dados de performance do 'hardware' (CPU, RAM, etc.) e (iii) a utilização de energia eléctrica. Dado que em alguns casos os dados dos resultados terão de ser definidos automaticamente (p.ex., registos das datas/horas nos programas do 'xdotool'), é necessário considerar o formato dos dados antes da medição no laboratório.

Foram levantadas algumas questões relacionadas com os dados: Se os dados resultantes deverão ser padronizados para harmonizar os resultados entre campanhas de medição ou se basta simplesmente publicar os dados recolhidos num formato acessível (por exemplo, como ficheiros .csv como os do repositório do FEEP)? Qual a precisão da data/hora que será necessária (p.ex., segundos ou fracções de segundos)? Estas dúvidas continuam em aberto por agora, mas o grupo decidiu que iremos precisar de uma visão geral dos dispositivos/programas compatíveis com FOSS (p.ex., o programa de Achim Guldner para o Gude Expert Power Control 1202 Series), assim como as ferramentas (p.ex., ferramentas de análise estatística como o OSCAR, R, Julia, Octave, PSPP, NumPy) usadas para as medições e análises, o que está actualmente em curso.

Dispositivos de medição de energia

Os critérios da Blauer Engel referem dois medidores de potência (PM) em particular: o Janitza UMG 604 e o Gude Expert Power Control 1202. Estes dispositivos não são baratos. Em 2020, o colaborador do KDE de longa data Volker Krause modificou uma tomada de energia de 8 euros e escreveu sobre o assuntod. Como foi descrito na publicação do 'blog', estas tomadas baratas são capazes de extrair com uma taxa de amostragem até 200ms. Isto levou à ideia de usar medidores de potência baratos em laboratórios com pouco orçamento. Para esse fim, será eventualmente útil comparar os resultados dos medidores de potência profissionais com os mais baratos, para ver se são comparáveis. Será que alguém está interessado em fazer isso mesmo?

Da [Publicação no 'Blog'] de Volker Krause (https://volkerkrause.eu/2020/10/17/kde-cheap-power-measurement-tools.html): "Medida de exemplo (intervalo de amostragem de 200ms, sem filtro): o cursor do rato a mover-se entre as amostras 100 e 150, com um pico ao passar o cursor sobre um item da barra de tarefas."

Outra forma de medir o consumo de energia veio do colaborador do KDE David Hurka, que tem uma proposta para os sensores de energia SPI por USB para oferecer uma alternativa de maior resolução para a medição com os d medidores de energia numa tomada de parede.

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

Foram discutidas outras questões diversas relacionadas com o consumo de energia e as medições em laboratório. Ainda que não tenham sido tomadas decisões para todos os casos, muitas destas questões em aberto serão importantes para considerar seguir em frente.

• A ideia de uma ferramenta amigável para o 'marketing' chamar a atenção para o consumo de energia pelo 'software'.
  • Por exemplo, um botão 'Eco' para a a medição da eficiência de energia/pegada de carbono (p.ex., pegada de carbono de uma viagem na aplicação de Itinerários).
  • Lembre-se que uma funcionalidade semelhante já é oferecida pelo PowerTop, ainda que algumas das questões continuem em aberto (quando for seguro activar par evitar a perda de dados e bloqueios da máquina?).
• Quando é que as desvantagens se sobrepõem aos benefícios do suporte para 'hardware' mais antigo?
  • Vamos convidar os investigadores que trabalham nisto para discutir com a comunidade do KDE Eco.
• Colaboração futura:
  • Sprint Conjunto com os projectos relacionados (p.ex., SoftAWERE)? (Talvez de interesse para o leitor: o Max Schulze da SoftAWERE/SDIA fez uma apresentação na reunião mensal do KDE Eco em Janeiro de 2022; poderá ler as actas aqui.)
  • Discussão dos tópicos acima e mais outros com outras comunidades relacionadas (Bits & Bäume, Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung, etc.)?

Conclusão

O Sprint 'noline' foi uma oportunidade maravilhosa para reunir toda a comunidade e avançar com o projecto KDE Eco, especialmente enquanto era preparado o laboratório de medições da comunidade, o qual ficará alojados na KDAB em Berlim, e a primeira maratona de medições (planeadas para o início de 2022)! O sucesso destes eventos depende em primeiro lugar da comunidade, por isso permitam-nos que enderecemos um grande obrigado a todos os que se juntaram à conversação. Temos vontade de tornar a comunidade ainda maior em 202! Para além disso, não poderíamos fazer o que fazemos sem o suporte da KDE e.V., assim como da BMU/UBA, que forneceu algum suporte financeiro para o projecto BE4FOSS (ainda que só o publicador seja responsável pelo conteúdo desta publicação).

Aviso de Financiamento

O projecto BE4FOSS foi financiado pela Agência Ambiental Federal e pelo Ministro Federal do Ambiente, da Conservação da Natureza, da Segurança Nuclear e Protecção ao Consumidor (BMUV¹). Os fundos são disponibilizados pelo Governo Alemão.

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

¹ Os logótipos oficiais do BMUV e do UBA só são enviados via pedido para: verbaendefoerderung@uba.de

O artigo foi contribuído por Joseph P. De Veaugh-Geiss segundo os termos da licença CC-BY-4.0.