Temporada do KDE 2022 (SOK22, sigla em inglês) com KDE Eco
Sou muito grato à equipe do KDE por me convidar para fazer parte desta comunidade incrível por meio de seu programa anual Temporada do KDE.
Sobre mim
Eu sou Karanjot Singh. Sou calouro de Engenharia da Computação no Instituto Jaypee de Tecnologia da Informação, em Noida, Índia. Trabalhei como desenvolvedor em diversos programas de Software Livre e de Código Aberto (FOSS), como o Kharagpur Winter of Code em 2021 (KWoC'21). No entanto, esta será minha primeira vez contribuindo para um projeto com uma comunidade tão grande. Sou muito apaixonado por FOSS, por resolver problemas e melhorar a eficiência de processos. Gosto de explorar e aprender novas tecnologias e construir coisas para causas socialmente úteis. Também acredito que contribuir com FOSS é a melhor maneira de adquirir experiência em desenvolvimento de software.
No que estarei trabalhando
Como parte de um projeto pioneiro de sustentabilidade, o KDE Eco tem como objetivo medir e reduzir o consumo de energia do KDE/Software Livre. Isso requer a emulação do comportamento do usuário, o que pode ser alcançado por meio do planejamento e da criação de Cenários de Uso Padrão. Criarei cenários de uso padrão para diversos aplicativos, com foco em editores de texto comumente usados, como Kate, KWrite, Vim, Nano, Emacs, Calligra Words e LibreOffice. Prepararei esses cenários de uso com uma das muitas ferramentas de emulação. Abaixo está meu cronograma do SoK'22:
Motivação por trás do trabalho no Projeto KDE Eco
Acredito que o KDE Eco seja uma iniciativa muito boa para o desenvolvimento de Software Livre com baixo consumo de recursos e energia. Quando alguém usa Software Livre e descobre que o software é transparente sobre seu consumo de energia, que usá-lo pode ajudar a prolongar a vida útil do hardware e reduzir o impacto ambiental da digitalização, isso me empolga. Sempre quero fazer parte de algo que contribua para as gerações futuras, e o KDE Eco atende a esse propósito. Também acredito que o KDE Eco me auxilia na minha jornada para me tornar um desenvolvedor de software melhor.
O que aprendi até agora
Quando comecei este projeto, eu tinha três perguntas.
Como podemos saber quando o software é eficiente em termos de recursos e energia?
Como podemos medir o consumo de energia do software?
E isso faz alguma diferença?
Essas perguntas podem surgir na mente de qualquer pessoa ao pensar na ideia de eficiência de software.
Ao usar um software, o que você vê é apenas a interface com a qual está interagindo. Basta dizer ao seu telefone o que você quer e as coisas aparecerão magicamente — seja a informação na tela ou um pacote entregue à sua porta. Mas as tecnologias e a infraestrutura por trás disso são determinadas por engenheiros de software que fazem tudo isso funcionar.
Imagine só: e se analisássemos o consumo de energia dos softwares mais usados e o tornássemos mais transparente? E se os usuários pudessem saber quanta energia seu software requer e pudessem escolher o aplicativo que seria melhor para o meio ambiente? Isso seria ótimo!!!
As iniciativas do KDE Eco, o Projeto de Eficiência Energética de código aberto e livre (FEEP) e o Blauer Engel para FOSS (BE4FOSS), estão trabalhando arduamente nessas questões.
Conforme observado pela FEEP, o design e a implementação de software têm um impacto significativo no consumo de energia dos sistemas dos quais faz parte. Com as ferramentas certas, é possível quantificar e reduzir o consumo de energia. Esse aumento de eficiência contribui para um uso mais sustentável da energia como um dos recursos compartilhados do nosso planeta.
O BE4FOSS apoia a FEEP coletando e divulgando informações relacionadas à certificação ecológica Blauer Engel (BE), o selo ambiental oficial concedido pelo governo alemão. Conforme indicado no site KDE Eco, a obtenção do selo Blauer Engel ocorre em 3 etapas: (1) Medir, (2) Analisar, (3) Certificar.
- MEDIR em laboratórios dedicados, como o KDAB Berlin
- ANALISAR usando ferramentas estatísticas como OSCAR (Análise de Consumo de Software de Código Aberto em R)
- CERTIFICAR mediante a apresentação do relatório sobre o cumprimento dos critérios Blauer Engel
No SoK'22, prepararei Cenários de Uso Padrão para vários editores de texto, para que os cenários de uso possam ser utilizados na Etapa 1 para obter a certificação ecológica BE.
O que fiz e farei nas próximas semanas
Nas últimas três semanas, testei várias ferramentas de automação, em particular Actiona, xdotool e GNU Xnee, para decidir qual dessas ferramentas seria a melhor para implementar Cenários de Uso Padrão.
Ao usar o Actiona, escrevi alguma documentação para que esta informação também seja benéfica para qualquer pessoa que queira contribuir para o KDE Eco.
Ao testar o xdotool, me deparei com um problema de vazamento de memória. Executando o Valgrind na busca do xdotool, obtenho mais memória perdida alocada pelo XQueryTree. Provavelmente existem outros lugares onde a memória é alocada e não é liberada posteriormente. Não fiz uma verificação completa. Mesmo assim, o xdotool oferece mais controle sobre o sistema e, mesmo com alguns problemas, esta é a ferramenta que achei mais útil.
Também testei o GNU Xnee, que me pareceu interessante, pois grava a saída e a armazena em um arquivo separado. Além disso, ele fornece um reprodutor que pode ser usado para automatizar tarefas na velocidade desejada.
No final, decidi preparar todos os cenários de uso com o xdotool, pelo menos inicialmente, já que a maioria dos editores de texto usa funções de teclado em vez da atividade do mouse, o que facilitará a adaptação do script a diferentes sistemas. No entanto, após o SoK'22, pretendo preparar cenários de uso com o Actiona também para que eu possa aprender as diferenças entre essas ferramentas. Em uma nota relacionada, também há uma discussão em andamento sobre reutilizar Cenários de Uso Padrão para testar a responsividade e o desempenho em hardware mais antigo ou de baixo custo.
Nas próximas semanas, também estarei trabalhando na correção de um problema conhecido no Actiona. O problema é que o Actiona emula o comportamento do usuário armazenando a posição dos cliques com base em coordenadas de pixel, o que pode dificultar a transferência de um script para outro sistema. Por exemplo, esse problema surgiu recentemente ao preparar um Cenário de Uso Padrão para o GCompris. Encontrei uma solução que consistia em redimensionar a tela para uma resolução mínima e incluir o código no início do script do Actiona. Sempre que o script é executado em um sistema diferente, ele é redimensionado automaticamente para a resolução mínima para corresponder aos pixels durante a criação do script. Isso é apenas uma ideia e ainda não foi testado. Reservarei um tempo para essa tentativa de corrigir o problema com a ajuda da equipe do GCompris.
O repositório GitLab contendo os Cenários de Uso Padrão em andamento (atualmente GCompris usando Actiona) pode ser encontrado aqui.
Vínculo comunitário (SoK’22)
Agradeço ao meu mentor Joseph P. De Veaugh-Geiss por dedicar seu tempo para me ajudar fornecendo recursos e orientação durante o projeto. Também participei do encontro mensal da comunidade KDE Eco em 9 de fevereiro de 2022, onde o Prof. Dr. Stefan Naumann, Achim Guldner e Christopher Stumpf do Umwelt Campus Birkenfeld lideraram uma discussão sobre a medição de consumo de energia de sistemas distribuídos e extensão dos critérios do prêmio Blauer Engel. Esta foi uma reunião interessante, onde discutimos problemas de automação com aplicativos móveis, bem como testes cliente-servidor. Joseph também me apresentou aos pesquisadores do Umwelt Campus, que mediram o consumo de energia do Okular (https://okular.kde.org); Emmanuel Charruau, que está trabalhando com o script GCompris; e Nicolas Fella, que atualmente trabalha com o xdotool em sua dissertação de mestrado sobre o consumo de energia de software.
Obrigado por reservar um tempo para ler esta atualização. Se alguém quiser acompanhar as ideias apresentadas aqui sobre os prós e contras de diferentes ferramentas de automação ao implementar Cenários de Uso Padrão, há um problema no GitLab no repositório BE4FOSS onde podemos discutir mais a fundo.
Também estou disponível na instância Matrix do KDE em drquark:kde.org.
Artigo contribuído por Karanjot Singh sob a licença CC-BY-SA-4.0.