Introdução: Do ​​que se trata tudo isso?

Este manual oferece uma breve visão geral dos danos ambientais causados ​​por software e de como o selo ecológico Blue Angel — o selo ambiental oficial do governo alemão — fornece uma referência para o design de software sustentável.

O selo Blue Angel é concedido a uma variedade de produtos e serviços, desde produtos de limpeza doméstica a pequenos eletrodomésticos e produtos para construção. Em 2020, a Agência Ambiental Alemã ampliou os critérios de premiação para incluir produtos de software. Foi a primeira certificação ambiental do mundo a vincular transparência e autonomia do usuário — dois pilares do Software Livre e de Código Aberto (FOSS) — à sustentabilidade.

Neste ponto, você pode estar se perguntando: o que a sustentabilidade tem a ver com software? Como algo aparentemente tão imaterial quanto um software pode ter um impacto ambiental? Neste manual, vamos analisar mais de perto algumas das maneiras pelas quais o software contribui para a crise climática e como a conformidade com os critérios do prêmio Blue Angel para certificação ecológica de software pode ajudar.

O livro está dividido em três partes:

• Parte I: Impacto Ambiental do Software
• Parte II: Certificação Ecológica de Software para Desktop
• Parte III: Cumprindo os critérios do prêmio Blue Angel

Enquanto a Parte I explora o porquê e a Parte II o o quê da eco-certificação de software, a Parte III discute o como, explicando o que você precisa saber para medir o consumo de energia do seu software e se candidatar ao selo ecológico Blue Angel. Especificamente, nesta seção, fornecemos um guia passo a passo para atender aos critérios básicos da premiação: (A) Eficiência de Recursos e Energia, (B) Vida Útil Potencial do Hardware e (C) Autonomia do Usuário.

Parte I: Impacto Ambiental do Software

Em 2021, a Association of Computing Machinery (ACM), a mais antiga sociedade científica e educacional de computação do mundo, publicou um relatório do Conselho de Política Tecnológica intitulado “Computação e Mudanças Climáticas”. Entre outras conclusões, o relatório explora o aumento exponencial no consumo de energia e recursos da inteligência artificial, bem como de dispositivos conectados à internet, tanto na produção quanto no uso. As estimativas do relatório são impressionantes. Somente em 2021, estima-se que o setor de Tecnologia da Informação e Comunicação (TIC) contribua com entre 1,8% e 3,9% das emissões globais de carbono. Para se ter uma ideia, isso se equipara à indústria global da aviação, que se estima contribuir com 2,5% de todas as emissões. O relatório alerta que, se nada mudar, até 2050 as emissões de carbono atribuíveis ao setor de TIC aumentarão para mais de 30% de todas as emissões globais.

Em suas conclusões, os autores reconhecem uma contradição inerente à digitalização: a tecnologia digital “pode ajudar a mitigar as mudanças climáticas”, mas “primeiro precisa parar de contribuir para elas” (p. 1). As TIC revolucionaram a forma como vivemos e são frequentemente elogiadas por trazerem conveniência e eficiência ao nosso dia a dia. As empresas têm aproveitado a tecnologia digital para a distribuição eficiente de todos os tipos de bens de consumo e para a desmaterialização de produtos cotidianos. Veículos como carros, scooters e bicicletas estão facilmente disponíveis para aluguel por meio de aplicativos de smartphone, eliminando a necessidade de os indivíduos possuírem esses bens para utilizá-los. A ampla disponibilidade de streaming de vídeo significa que não é mais necessário produzir ou transportar DVDs e discos Blu-ray para assistir a um filme, e gastar combustível para ir até a locadora para buscar um filme no sábado à noite é coisa do passado. Leitores digitais substituíram estantes inteiras de livros. Com a pandemia global de SARS-CoV-2 acelerando a integração da digitalização em todos os aspectos da vida cotidiana, as videoconferências estão substituindo eventos que antes eram (quase) exclusivamente presenciais, incluindo reuniões de escritório, conferências acadêmicas internacionais, recitais de piano locais e até primeiros encontros... tudo isso agora é possível no conforto do próprio lar com um dispositivo conectado à internet.

Apesar de todos os avanços tecnológicos aparentemente terem tornado nossas vidas menos materiais e menos desperdiçadoras, e, portanto, mais convenientes e eficientes, pode parecer que o ritmo acelerado da digitalização traz mais benefícios do que malefícios para a conquista de metas de sustentabilidade.

Mas será mesmo?

A internet e os dispositivos que usamos para nos conectar a ela exigem infraestrutura — hardware físico real que demanda energia e consome recursos. Muitas vezes, os impactos ambientais, por exemplo, das fábricas que produzem esses dispositivos ou da infraestrutura que abrange continentes e possibilita a comunicação global são negligenciados. Tudo isso requer energia em seu uso diário. Além disso, o hardware que não é mais usado acaba em centros de descarte para tratamento de fim de vida útil (o que requer ainda mais energia) ou como lixo eletrônico, que é tóxico tanto para as pessoas quanto para o meio ambiente. Novos dispositivos são então produzidos e transportados, em muitos casos desnecessariamente.

“Um fato ainda mais raramente reconhecido é que a chave para aumentar a eficiência energética e proteger os recursos naturais não reside no hardware, mas sobretudo no software.” — Critérios do Prêmio Blue Angel: Produtos de Software com Uso Eficiente de Recursos e Energia (p. 5)

Dentro desse panorama mais amplo, o papel crucial que o software desempenha na contribuição para os danos ambientais pode ser negligenciado. De fato, em muitos casos, é o software que determina o consumo de energia e a vida útil da infraestrutura digital. Este manual analisará mais de perto algumas das maneiras pelas quais a tecnologia digital está contribuindo para os danos ambientais e para a crise climática. Para sermos claros, este manual não é contra a tecnologia — sem dúvida, a digitalização melhorou a vida de inúmeras maneiras para um grande número de pessoas. Mas os impactos ecológicos da tecnologia digital exigem que reflitamos mais profundamente sobre as maneiras como a utilizamos e como podemos usá-la de forma mais eficiente. E a boa notícia é que, por meio do design de software, os desenvolvedores podem ter uma influência imediata e significativa em muitas das questões discutidas aqui.

Ao longo do texto, e especialmente nas seções posteriores, o selo ecológico Blue Angel para software de desktop servirá como referência para o design de software sustentável. Mas, afinal, o que significa “Blue Angel”?

O selo ecológico Blue Angel (em alemão: Blauer Engel Umweltzeichen) é o selo ambiental oficial do governo alemão. Em 2020, a Agência Alemã do Meio Ambiente (em alemão: Umweltbundesamt, ou UBA) divulgou os critérios para a certificação de softwares para desktop, a primeira certificação ambiental do mundo a vincular transparência e autonomia do usuário à sustentabilidade. O Software Livre e de Código Aberto (FOSS, na sigla em inglês) tem uma vantagem real nesse contexto. Esperamos que, ao final deste manual, você tenha compreendido melhor como isso funciona.

Mas, para resolver um problema de forma eficaz, primeiro precisamos identificá-lo. Portanto, vamos entender o que significa pegada de carbono digital e como o software que usamos diariamente está envolvido.

Pegada material da tecnologia digital

A tecnologia digital é frequentemente (e erroneamente) associada à imaterialidade. Quando enviamos um e-mail ou carregamos dados para a nuvem, é fácil imaginar nossas transmissões desaparecendo no éter. Mas existe um aspecto muito real e muito material na digitalização, que abrange não apenas nossos dispositivos físicos, como smartphones e laptops, mas também as usinas de processamento de metais extraídos necessárias para seu funcionamento, os navios porta-contêineres que transportam hardware produzido em massa e os cabos e data centers que os conectam às redes globais. O relatório de 2018 “Lean ICT: Towards Digital Sobriety” descreve a questão da seguinte forma:

[A] pegada material da tecnologia digital é amplamente subestimada por seus usuários, dada a miniaturização dos equipamentos e a “invisibilidade” das infraestruturas utilizadas. Esse fenômeno é reforçado pela ampla disponibilidade de serviços na “nuvem”, o que torna a realidade física dos usos ainda mais imperceptível e leva à subestimação dos impactos ambientais diretos da tecnologia digital. (p. 10)

Como observou um artigo do New York Times [https://www.nytimes.com/interactive/2019/03/10/technology/internet-cables-oceans.html], “as pessoas pensam que os dados estão na nuvem, mas não estão. Estão no oceano”, referindo-se aos cabos submarinos de comunicação que se estendem pelo globo. Para trazer a realidade tangível da “nuvem” para a Terra e para o fundo do oceano, precisamos mudar nossa perspectiva para a infraestrutura oculta que fornece a base para nossas vidas digitais. As redes de dados podem estar em grande parte submersas, mas as emissões de carbono terão consequências terríveis para todos os ambientes naturais. Na COP27, em novembro de 2022, o Secretário-Geral das Nações Unidas, António Guterres, ressaltou a urgência do momento ao afirmar: “Estamos em uma estrada rumo ao inferno climático com o pé no acelerador”.

A tecnologia digital pode ajudar a mitigar as mudanças climáticas, mas primeiro precisa parar de contribuir para elas.

No setor das TIC, o que está contribuindo para o aumento do CO₂ na atmosfera?

Entre 2012 e 2018, a demanda energética da inteligência artificial (IA) aumentou 300.000 vezes e atualmente dobra a cada poucos meses. Estima-se que o treinamento de um único modelo de IA (como os usados ​​em tradução automática ou modelagem de linguagem) pode exigir energia equivalente a uma viagem de ida e volta de Nova York a São Francisco… 300 vezes (cerca de 626.000 libras de CO₂). A tecnologia blockchain também é notória por contribuir para o aumento explosivo do consumo de energia — especificamente, sistemas de prova de trabalho como o Bitcoin, que, segundo relatórios da Harvard Business Review, requerem tanta energia quanto países inteiros como a Suécia ou a Malásia.

Ao mesmo tempo, usamos mais dispositivos digitais do que nunca. O número de dispositivos conectados à internet, incluindo laptops e smartphones, mas também smart TVs, assistentes domésticos e outros dispositivos IoT, está crescendo rapidamente e espera-se que ultrapasse 75 bilhões até 2025. Isso equivale a cerca de 10 dispositivos para cada pessoa na Terra (embora a distribuição global desses dispositivos esteja longe de ser uniforme). Globalmente, a adoção de smartphones aumentou rapidamente, assim como a demanda por recursos necessários para fabricar dispositivos novos e cada vez mais poderosos. A produção desses dispositivos, incluindo a mineração dos metais de terras raras necessários para seu funcionamento, e seu transporte, uso e descarte final consomem grandes quantidades de energia.

It is crucial to underscore here, however, that energy consumption is not the same as carbon emissions. Carbon emissions depend on the particular mix of fuels used for generating electricity, referred to as the electricity or power generation mix. As an example, for the European Union’s energy supply in 2016, the power generation mix included 32.9% oil, 23.9% gas, 14.9% coal, 13.7% nuclear power, and 14.5% renewables. With the energy crisis of 2022, the energy mix in the EU has changed—in some cases for the better long-term, in some for the worse short-term. Relative carbon emissions will depend on this mix: for example, energy consumption from 100% carbon-neutral sources contribute no direct CO₂ emissions.

Dano Relativo — Ou, Quando Menos Não é Mais

A digitalização é frequentemente associada à “desmaterialização”: imprimir bilhetes de concertos ou de viagens em papel já não é necessário, pois podem ser descarregados e apresentados no smartphone; as fotografias já não são guardadas em caixas de sapatos abarrotadas, mas sim num pequeno tablet ou disco rígido; milhares de filmes e séries de televisão são transmitidos em computadores portáteis, tornando as coleções de filmes uma coisa do passado. Em muitos casos, um único dispositivo, um smartphone, é utilizado para tudo isto — e muito, muito mais.

Cada um desses objetos materiais já foi uma parte importante do nosso dia a dia... mas hoje, eles simplesmente não são mais necessários. Isso deve ser melhor para o planeta, não é?

Embora os dispositivos digitais possam reduzir alguns tipos de resíduos, estimar o verdadeiro impacto ambiental das tecnologias digitais exige contabilizar todo o ciclo de vida de um item. Isso inclui os custos de produção e transporte dos dispositivos digitais (da loja até o aterro sanitário e vice-versa), ou os custos de remediação dos danos ambientais causados ​​pelo lixo eletrônico. Isso é especialmente verdadeiro ao considerarmos a pegada de carbono coletiva de nossas tecnologias digitais, já que, em alguns casos, a produção dos dispositivos, juntamente com seu transporte e descarte, contribui com mais emissões de gases de efeito estufa do que o uso dos dispositivos durante toda a sua vida útil. Para ilustrar isso, considere o Relatório de Responsabilidade Ambiental de 2019 da Apple, que estima que a Apple contribuiu com 25,2 milhões de toneladas métricas de CO₂ em 2018 (p. 9). A maior parte disso — impressionantes oitenta por cento (!!!) — vem da produção (74%), transporte (5%) e tratamento de fim de vida útil (<1%). Apenas 19% vem do uso real dos dispositivos.

Então, quando é que os custos de fabricação de um dispositivo digital para substituir todos esses objetos analógicos valem a pena? O livro “Smarte Grüne Welt” (em inglês: Smart Green World), de Steffen Lange e Tilman Santarius (2018), explora a dificuldade de contabilizar os danos ambientais relativos ao tentar responder a essas perguntas. Considere este trecho, no qual os autores exploram o impacto ambiental da impressão de livros em papel versus a fabricação de leitores eletrônicos (págs. 29–31; traduzido do alemão):

A fabricação de dispositivos eletrônicos é obviamente mais intensiva em energia e recursos do que a impressão de um único livro. Por exemplo, a produção de um leitor eletrônico, geralmente pesando menos de 200 gramas, utiliza cerca de 15 quilos de diferentes materiais (especialmente metais não renováveis ​​e terras raras), 300 litros de água e 170 quilos do gás de efeito estufa dióxido de carbono. No entanto, não são apenas as quantidades de materiais de entrada e saída que são decisivas, mas também seu impacto ambiental. Existem grandes diferenças entre leitores eletrônicos e livros, especialmente na toxicidade dos materiais e nos processos de fabricação. É verdade que a indústria de papel em muitos países (ainda) tem efeitos ambientais muito negativos, por exemplo, quando o cloro ou os ácidos contaminam as águas locais. No entanto, os efeitos ambientais da indústria eletrônica às vezes são devastadores: leitores eletrônicos e outros produtos de TI contêm retardantes de chama bromados, ftalatos, berílio e inúmeras outras substâncias químicas que são extremamente prejudiciais à saúde e ao meio ambiente. Sem mencionar as consequências sociais, como as condições de trabalho por vezes miseráveis ​​em que o cobalto, o paládio, o tântalo e outros recursos dos dispositivos digitais são inicialmente extraídos em ditaduras como a República do Congo ou noutros países do Sul global — e depois descartados no final da sua vida útil como lixo eletrónico prejudicial para o ambiente.

Apesar de tudo isso, o leitor digital pode ser melhor que o livro físico. Isso depende, em última análise, de dois fatores: quantos livros são lidos no leitor digital ao longo de sua vida útil? E quantas pessoas compartilham o livro físico? Para que os altos custos ambientais da produção do leitor digital se justifiquem ecologicamente, é necessário ler um certo número de livros nele. Isso ocorre após 30 a 60 livros — dependendo da espessura do livro e do indicador ambiental. Se você lê menos do que esse número de livros em um leitor digital, é melhor optar pelo formato impresso. Se você ultrapassar esse limite, cada livro lido no leitor digital é ecologicamente melhor do que sua contraparte física. Além disso, a forma como os objetos são usados ​​é crucial [...]: se presumirmos que alguém compra um livro e não o deixa ser visto por mais ninguém, então um arquivo no leitor digital é cerca de cinco vezes mais eficiente em termos de energia do que um livro físico. Essa vantagem, no entanto, desaparece quando várias pessoas compartilham um livro.

Então, substituir objetos físicos por tecnologia digital resulta em um impacto ambiental reduzido? Bem, depende. Por exemplo, se você comprar um leitor de livros digitais, você lerá de 30 a 60 livros antes de descartar o aparelho? Uma pesquisa do Gallup revelou que, em 2021, 57% dos americanos liam menos de 5 livros por ano e 15% liam entre 6 e 10 livros. Isso significa que, para mais de dois terços da população dos EUA, um leitor de livros digitais precisaria ser usado por cinco a dez anos para ser a opção mais ecológica. Mas quantos consumidores trocam para o próximo modelo, mais moderno e brilhante, bem antes disso?

Vale a pena também questionar se um dispositivo continuará recebendo suporte da empresa pelo tempo necessário para se tornar a opção menos prejudicial. No final de 2022, a lista da Wikipédia de leitores de e-books descontinuados incluía 71 dispositivos. De acordo com a lista, a vida útil média, ou seja, do ano de lançamento ao ano de fim de vida útil, era de 1,5 ano — consideravelmente menor do que um período mínimo de uso de cinco anos, quanto mais de uma década! Quantos desses leitores de e-books ainda estavam funcionando, mas acabaram em aterros sanitários devido à falta de suporte de software? Esse tipo de obsolescência programada contribui significativamente para os danos ambientais, seja na forma de lixo eletrônico ou pelas emissões de carbono associadas à produção do dispositivo. Como escrevem Lange e Santarius: “é questionável se todos os leitores eletrônicos vendidos, antes de quebrarem ou se tornarem tecnicamente obsoletos novamente, são usados ​​de forma tão intensiva em média que um benefício ecológico geral seja alcançado” (p. 31; traduzido do alemão).

Um “Tsunami de Lixo Eletrônico”

Com sete metros de altura, o “Homem REEE” é um gigante. Recebendo o nome da diretiva de 2003 sobre Resíduos de Equipamentos Elétricos e Eletrônicos (REEE), que estabelece metas de coleta, reciclagem e recuperação de lixo eletrônico na UE,¹ a estátua é feita de 3,3 toneladas métricas de lixo eletrônico, ou a quantidade média de lixo eletrônico que um indivíduo do Reino Unido produz ao longo da vida.

O lixo eletrônico é considerado o “fluxo de resíduos que cresce mais rapidamente no mundo“, com 44,7 milhões de toneladas métricas geradas em 2016 — o equivalente a 4.500 Torres Eiffel, que, quando empilhadas, são 17 vezes mais altas que o Monte Everest. Em 2018, foram estimadas 50 milhões de toneladas métricas de lixo eletrônico, o que levou a ONU a se referir a um “tsunami de lixo eletrônico se espalhando pelo mundo”. Os números continuam a subir: em 2021, foram geradas estimadas 57 milhões de toneladas métricas de lixo eletrônico em todo o mundo. Menos de 20% dele é coletado e reciclado, e embora represente apenas 2% do lixo em aterros sanitários, contribui com quase 70% dos resíduos tóxicos encontrados lá.

Os impactos ambientais do lixo eletrônico são enormes. Componentes eletrônicos descartados, como CPUs, contêm materiais potencialmente nocivos, como chumbo, cádmio, berílio ou retardantes de chama bromados. O tratamento do lixo eletrônico ao final de sua vida útil também pode envolver risco significativo à saúde dos trabalhadores e de suas comunidades. Catadores arriscam sua saúde pelos metais preciosos descartados em laptops e smartphones “repletos de chumbo, mercúrio ou outras substâncias tóxicas”. O processo de desmontagem e descarte de lixo eletrônico tem levado a uma série de impactos ambientais em países em desenvolvimento. Emissões líquidas e atmosféricas acabam em corpos d'água, águas subterrâneas, solo e ar — e, portanto, também em animais terrestres e marinhos, em plantações consumidas por animais e humanos e na água potável. Essa poluição é um aspecto crucial do dano ambiental da tecnologia digital.

Olhe para o Software

Qual a causa de todo esse lixo eletrônico e por que dispositivos digitais que ainda funcionam acabam em aterros sanitários? A engenharia de software desempenha um papel importante, porém frequentemente invisível, na definição de nossos padrões de consumo digital. Os fabricantes incentivam regularmente os consumidores a comprar novos dispositivos, muitas vezes desnecessariamente. Aliás, podem até mesmo impor isso por meio do design do software. Devido às restrições de licenciamento de uso de software e à dependência de fornecedores, os usuários finais podem fazer pouco a respeito. Em resumo, essas são razões predominantemente econômicas — e não tecnológicas — para que hardware em funcionamento se torne lixo eletrônico.

O bloqueio de software e a obsolescência programada resultam em hardware inutilizável. O abandonware lançado sob uma licença proprietária pode, na melhor das hipóteses, deixar os usuários vulneráveis ​​a vírus e outros malwares e, na pior, simplesmente parar de funcionar, sem qualquer alternativa. A infraestrutura subjacente da qual as pessoas podem depender para executar um aplicativo — como servidores de licença de software usados ​​para controle de acesso por fornecedores de software — pode ficar offline, às vezes permanentemente. Os usuários podem não conseguir continuar usando hardware "desatualizado", mesmo que desejem.

O acúmulo de funcionalidades desnecessárias e outras formas de excesso de software podem tornar obsoletos hardwares menos potentes, mesmo que os clientes nunca tenham solicitado essas funcionalidades extras ou desejassem removê-las se pudessem. Considere o seguinte:

“O poder de processamento dobrou aproximadamente a cada dois anos desde 1970. Isso significa que as funções são processadas duas vezes mais rápido e, portanto, menos energia é necessária para as mesmas funções. Uma melhoria semelhante na eficiência não pode ser observada na área de software. [...] A disponibilidade de hardware cada vez mais poderoso resultou em softwares cada vez mais inchados de versão para versão, de modo que mais recursos são necessários para melhorias mínimas ou até mesmo nenhuma melhoria na funcionalidade.” — Critérios do Prêmio Blue Angel: Produtos de Software com Uso Eficiente de Recursos e Energia (p. 5)

Nesses casos, as dependências de fornecedores e as restrições de usuários atribuíveis ao design e ao licenciamento do software fazem com que dispositivos ainda funcionais sejam descartados, enquanto mais recursos são consumidos para produzir e transportar novos.

Quando não torna o hardware em funcionamento obsoleto, o design de software que requer servidores de licença, sofre com o acúmulo de funcionalidades, etc., e também resulta em maior consumo de energia durante o uso do software. Por exemplo, um estudo publicado pela Agência Ambiental Alemã e um artigo relacionado descobriram que dois aplicativos que fazem a mesma coisa e alcançam o mesmo resultado podem ter perfis de energia drasticamente diferentes.

Os dados do estudo incluem uma comparação de dois programas de processamento de texto: o Processador de Texto 1 é identificado como de código aberto, enquanto o Processador de Texto 2 é identificado como um software proprietário. Ambos os programas executaram a mesma sequência de comandos por meio de um script de Cenário de Uso Padrão (SUS, sigla em inglês), correspondente ao “uso mais representativo do respectivo software durante um período de tempo definido” (p. 23). Retornaremos à criação de scripts de cenário de uso no guia prático da PARTE III deste manual. Por ora, o importante a observar é a enorme diferença no consumo de energia. A execução do Processador de Texto 2 consumiu 4 vezes mais energia em comparação com o Processador de Texto 1 — novamente, e isso não pode ser enfatizado o suficiente, para realizar a mesma tarefa!

Analisando mais detalhadamente o consumo de energia dos dois processadores de texto ao longo do tempo, fica claro como os dois programas se comportam de maneira bastante diferente... e talvez contrária ao que se poderia esperar. Observe o gráfico abaixo, que mostra o consumo de energia durante a execução da sequência de comandos do cenário de uso. Por volta dos 440 segundos, o script solicita que ambos os processadores de texto salvem o documento e, em seguida, para de solicitar outras ações. Como você pode ver, o Processador de Texto 1 fica ocioso (como era de se esperar). Em contrapartida, o Processador de Texto 2 continua funcionando, consumindo energia mesmo após o término do script.

Vale a pena perguntar para que servem as atividades adicionais entre 440 e 600 segundos: as ações do Processador de Texto 2 são necessárias para a funcionalidade do software? O processador de texto está coletando e transmitindo dados do usuário? Em caso afirmativo, os usuários têm uma maneira de optar por não participar desses tipos de análises? De fato, a autonomia do usuário, como a capacidade de desativar o uso indesejado de dados, pode fazer uma grande diferença no perfil energético de um produto de software. Mineração de dados, rastreamento de terceiros, algoritmos personalizados para maximizar o engajamento e publicidade são fatores significativos de consumo de energia. Coletar e analisar dados do usuário e treinar algoritmos com base neles exigem poder computacional e infraestrutura.

Pesquisadores da UE estimaram os custos ambientais do rastreamento e dos anúncios dos quais os usuários não podem optar por não participar, denominados "uso indesejado de dados", no relatório de 2021 sobre a "Pegada de carbono do uso indesejado de dados por smartphones: uma análise para a UE". A pegada de carbono desse rastreamento por smartphone — entre 3 e 8 milhões de toneladas métricas por ano somente na UE — é "equivalente à pegada de carbono de entre 370 e 950 mil cidadãos da UE" (na pior das hipóteses, aproximadamente a pegada anual de uma cidade como Turim ou Lisboa). O relatório destaca que cerca de 60% dos usuários europeus de smartphones afirmam que optariam por não ser rastreados e bloquear anúncios sempre que possível. Isso representa um consumo de energia enorme para algo que a maioria dos usuários não deseja!

“O contrário é que é a verdade”: o paradoxo de Jevons

Aumentos na eficiência do software por si só não se traduzem necessariamente em pegadas ambientais mais leves. Por exemplo, o “efeito rebote” (também conhecido como “efeito de recuperação”) descreve como as melhorias de eficiência podem levar a mudanças no uso que diminuem ou até mesmo anulam os ganhos originais.

Imagine que uma mudança no software resulte em uma melhoria de 5% na eficiência energética. No entanto, devido ao aumento na economia de energia, você pode acabar usando o software com mais frequência, resultando em uma economia de energia menor no geral. Digamos que, devido ao aumento do seu uso, o consumo total de energia do software caia apenas 1%. Nesse caso, o efeito rebote é de 80% ((5-1)/5): em outras palavras, os ganhos de eficiência originais diminuíram em 80%, praticamente anulando qualquer economia obtida com as melhorias!

Se o efeito rebote ultrapassar 100%, ou seja, se acabar sendo usada mais energia do que antes, isso é chamado de Paradoxo de Jevons, ou “efeito bumerangue”. O conceito vem do economista inglês William Stanley Jevons, que em 1865 reconheceu que as melhorias tecnológicas no uso do carvão, na verdade, aumentavam o consumo de carvão em todos os setores. Jevons concluiu que:

“É uma confusão de ideias supor que o uso econômico de combustível seja equivalente à diminuição do consumo. O contrário é que é verdade.” [ênfase adicionada]

Uma interpretação prática desse paradoxo é que os ganhos de eficiência devem ser combinados com práticas de conservação para terem um efeito significativo, caso contrário, o consumo não aumentará. O relatório da ACM mencionado no início desta seção faz uma observação semelhante: “A eficiência proporcionada pela computação deve ser combinada com a redução drástica da demanda de energia para diminuir as emissões de carbono do setor de TIC” (p. 1). Em outras palavras, tanto a engenharia de software quanto o comportamento do usuário são elementos cruciais a serem considerados no combate aos danos ambientais causados ​​pelo software.

Vale a pena tudo isso?

Considerando o panorama geral, os danos ambientais e as emissões globais de gases de efeito estufa causados ​​por softwares podem ser menos significativos em comparação com outros setores. Portanto, parece razoável perguntar: vale a pena focar nos impactos ambientais do software, um problema que pode parecer relativamente pequeno em uma perspectiva mais ampla?

Há alguns pontos que podemos considerar aqui. O primeiro é a rejeição da falácia do "Não tão ruim quanto", também conhecida como "Apelo a problemas piores". O argumento geral é o seguinte: a contribuição do software para as emissões globais de CO₂ pode não ser tão ruim quanto a de outro setor e, portanto, não vale a pena focar nisso. O problema desse argumento é que, embora outro setor possa ser pior, isso não anula o fato de que a engenharia de software é responsável por causar sérios danos ambientais. Além disso, a falácia do "Não tão ruim quanto" sugere uma falsa escolha entre abordar um problema ou outro, quando, na verdade, o design de software ecologicamente correto é apenas uma peça de um quebra-cabeça maior.

Não sejamos como o White Hat do XKCD e apelemos para problemas piores como desculpa para não fazer nada!

Em segundo lugar, concentrar-se apenas em resolver o “maior problema” não é necessariamente a estratégia mais eficaz. Também é importante avaliar a probabilidade de sucesso ao abordar um problema, bem como o tempo e os recursos necessários para fazê-lo. O Software Livre e de Código Aberto (FOSS), com seu foco na autonomia e transparência do usuário, oferece oportunidades únicas para usuários, comunidades e organizações abordarem diretamente questões sociais e ecológicas interligadas. O FOSS pode ser adaptado, atualizado e mantido a um custo menor e sem dependências de fornecedores ou restrições artificiais.

Em terceiro lugar, espera-se que já esteja claro que o software tem impactos significativos no consumo de energia e na produção de resíduos, ambos com consequências para o meio ambiente. Além disso, quando consideradas em grande escala, mudanças mínimas no design do software podem resultar em economias comparáveis ​​ao consumo anual de energia de cidades inteiras. Essa afirmação se baseia em um exemplo do engenheiro de produto da SAP, Detlef Thoms, que fez cálculos aproximados (04:20–06:10) para passar de uma redução de um segundo de CPU, equivalente a uma economia de cerca de 10 watts-segundo, para uma economia de 95 mil megawatts-hora simplesmente aumentando a escala. Essas economias são comparáveis ​​ao consumo anual de energia de mais de 30 mil residências com duas pessoas.

Como afirma Detlef Thoms no vídeo: "Muitas vezes, trata-se de um conjunto de decisões bastante simples que leva a diferenças significativas no consumo de energia".

Finalmente, para fazer afirmações sobre danos relativos, é necessário primeiro ter estimativas sobre os efeitos reais. Como a pesquisa na área de consumo de energia e recursos de software ainda é bastante recente, muitas vezes não temos dados para fazer afirmações baseadas em dados. Com este manual e com o selo ecológico Blue Angel como guia, o KDE espera ajudar a mudar isso.

Mudar nosso software pode parecer um pequeno gesto para lidar com um problema tão complexo quanto a mudança climática. Também é evidente que simplesmente mudar nossos padrões de consumo individuais pode não ser suficiente por si só (pior, evidências sugerem que grandes contribuintes para as emissões globais de gases de efeito estufa — como a ExxonMobile — adotaram uma retórica de responsabilidade individual do consumidor para desviar a atenção de seu próprio papel na crise). É verdade: um futuro com zero emissões exigirá mudanças fundamentais em como vivemos, e essa responsabilidade não pode ser gerenciada em nível individual. Mas considere o que a antropóloga Margaret Mead observou certa vez:

“Nunca duvide que um pequeno grupo de cidadãos conscientes e comprometidos possa mudar o mundo; na verdade, é a única coisa que já o fez.”

A mudança estrutural acontece quando pessoas dedicadas e apaixonadas se organizam para enfrentar problemas sociais urgentes. Com décadas de experiência em unir comunidades globais para trabalhar em prol de objetivos comuns, o Software Livre e de Código Aberto pode ser uma força poderosa no combate ao impacto ambiental da digitalização. Sabemos como nos organizar — agora, é uma questão de transformar planos em prática, objetivos em realidade. Vamos nos unir para combater os danos ambientais causados ​​por softwares. Vamos fomentar uma cultura de sustentabilidade digital em nossas comunidades de software. Vamos construir, juntos, softwares que sejam eficientes em termos de energia e recursos!

Uma nota sobre as fontes

Parte do material desta seção é baseado diretamente em textos de dois artigos da Wikipédia: (i) “Diretiva sobre Resíduos de Equipamentos Elétricos e Eletrônicos” e (ii) “Resíduos eletrônicos”. Ambos os textos estão licenciados sob a Licença Creative Commons de Atribuição Compartilhada 3.0.

Parte II: Certificação Ecológica de Software para Desktop

O que os produtos de construção, o papel higiênico e o software têm em comum?

Cada um deles pode ser certificado ecologicamente pelo selo ambiental Blue Angel, o selo ambiental oficial do governo alemão!

O selo ecológico Blue Angel é concedido a uma variedade de produtos e serviços, desde produtos de papel e materiais de construção até impressoras, e certifica que o produto atende a uma lista de requisitos rigorosos para ser ecologicamente correto ao longo de todo o seu ciclo de vida. Em 2020, a Agência Ambiental Alemã ampliou os critérios de premiação para incluir produtos de software, sendo esta a primeira certificação ambiental a vincular transparência e autonomia do usuário à sustentabilidade.

Especificamente, os critérios de certificação ecológica exigem transparência sobre o consumo de energia do software durante o uso, garantindo também que o software seja capaz de funcionar em hardware mais antigo. Além disso, os critérios incluem uma lista de requisitos relacionados à autonomia do usuário, que podem reduzir o impacto ambiental do software.

Esta seção fornece uma visão geral do Selo Blue Angel e dos princípios básicos dos critérios de premiação para software de desktop. Também demonstra como atender aos critérios de premiação pode reduzir os danos ambientais. Em particular, vamos nos aprofundar aqui nos detalhes sobre os requisitos de autonomia do usuário dos critérios do Selo Blue Angel, que abordaremos na PARTE III. Mas primeiro, uma breve introdução ao Selo Blue Angel e à iniciativa KDE Eco.

O Blue Angel para Software de Desktop

Introduzido em 1978, o Blue Angel é o primeiro selo ecológico mundial e o selo ambiental oficial concedido pelo governo alemão. O selo é administrado pelo Ministério Federal do Meio Ambiente, Conservação da Natureza, Segurança Nuclear e Proteção do Consumidor da Alemanha (em alemão: Bundesministerium für Umwelt, Naturschutz, nukleare Sicherheit und Verbraucherschutz, ou BMUV). O selo ecológico Anjo Azul também é membro da Rede Global de Selos Ecológicos (GEN), uma rede internacional de selos ecológicos do Tipo I que na data desta publicação conta com 37 membros em quase 60 países.

O selo Blue Angel não foi o primeiro selo ecológico Tipo I para software — o Conselho Verde de Hong Kong, também membro da Rede Global de Selos Ecológicos, lançou critérios em 2010 para software de TI Verde. Mas os critérios do selo ecológico Blue Angel são os primeiros a identificar um processo para medir o consumo de energia do software e a especificar maneiras pelas quais a independência do usuário reduz os danos ambientais.

Você pode estar se perguntando: O que é um selo ambiental Tipo I? Para esses selos ecológicos, todo o ciclo de vida do produto é levado em consideração. Além disso, a conformidade com os critérios de premiação é avaliada por uma terceira parte. (A conformidade com os selos ambientais Tipo II, em comparação, é autodeclarada e não exige nenhuma auditoria de terceiros.)

O selo ecológico Blue Angel foi concedido a cerca de 100 grupos de produtos e serviços em diversos setores, incluindo papel e produtos de construção, mobiliário, vestuário, produtos de limpeza, serviços de limpeza, produtos químicos domésticos, embalagens, veículos, energia e aquecimento, e eletrodomésticos. A partir de 2022, com a certificação ecológica do Okular, leitor universal de PDF da KDE, essa lista também inclui softwares para desktop.

Os critérios de certificação são desenvolvidos de forma transparente pela Agência Ambiental Alemã. O processo inclui o Júri do Selo Ambiental, um órgão composto por fornecedores, organizações da sociedade civil e instituições de pesquisa. A auditoria independente RAL gGmbH avalia a conformidade com os critérios e concede o selo. É importante ressaltar que o Blue Angel não certifica que um produto seja completamente inofensivo. Em vez disso, os produtos certificados representam um "mal menor" em relação aos danos ambientais — isso pode ser resumido pelo lema "o mínimo possível, o máximo necessário". Em vez de comparar diferentes produtos, o selo ecológico Blue Angel indica que um produto atende a uma lista de requisitos para uma categoria específica.

Os ABCs dos critérios de premiação

Os critérios de premiação do Blue Angel para “Produtos de Software com Uso Eficiente de Recursos e Energia” foram divulgados em janeiro de 2020. Há dois objetivos principais do Blue Angel para software: (i) premiar softwares com requisitos de desempenho mais baixos, de forma que “uma vida útil mais longa para o hardware seja possível”; e (ii) reconhecer produtos que “se destacam devido ao seu alto nível de transparência e oferecem aos usuários maior liberdade no uso do software” (p. 6). Para atingir esse objetivo, existem três categorias principais, aqui denominadas ABCs dos critérios de premiação: (A) Eficiência de Recursos e Energia, (B) Potencial de Vida Útil do Hardware, (C) Autonomia do Usuário.

Os critérios da categoria (A) exigem que o consumo de energia de um produto de software seja medido e relatado, e estabelecem que o consumo de energia do aplicativo não pode aumentar mais de 10% desde o momento de sua certificação. Os dados de consumo de energia são medidos usando um medidor de energia externo e levam em consideração outras informações de desempenho de hardware, como uso da CPU ou tráfego de rede, enquanto o software é executado de forma representativa. Retornaremos a este assunto na PARTE III.

Os critérios da categoria (B) garantem que o software tenha requisitos de desempenho suficientemente baixos para ser executado em hardware mais antigo e menos potente, com pelo menos cinco anos de uso. A conformidade implica uma declaração de retrocompatibilidade, com detalhes sobre o hardware em que o software é executado e a pilha de software necessária.

Finalmente, os critérios da categoria (C) garantem que os usuários tenham influência sobre o consumo de energia e o uso de recursos eficientes de seus softwares. Existem oito categorias para os critérios de autonomia.

1. Formatos de dados — Interoperabilidade para dar opções aos usuários

   Os fornecedores não devem usar formatos de dados para prender os usuários ao uso de um programa de computador específico, nem devem impor custos onerosos de troca. Formatos de dados interoperáveis impedem que os usuários fiquem presos a um programa que consome muita energia, quando um programa mais eficiente pode alcançar os mesmos resultados com menos exigências de hardware. Os usuários devem poder trocar de programa facilmente e ainda acessar todos os seus dados.

2. Transparência — Removendo dependências do usuário para uso a longo prazo

   Transparência no código do software e nas interfaces de aplicativos significa eliminar qualquer dependência de uma empresa ou organização específica. Significa também remover restrições ao uso do software a curto e longo prazo, e, consequentemente, do hardware. Quando os desenvolvedores decidem encerrar o suporte ao seu software, as atualizações de segurança devem continuar sendo fornecidas (veja abaixo) ou o código-fonte deve ser disponibilizado publicamente para que terceiros possam continuar oferecendo suporte ao software. Além disso, o aprimoramento da funcionalidade do software não deve ser limitado por interfaces de aplicativos (APIs) restritivas ou não documentadas.

3. Continuidade do suporte — Atualizações de segurança para prevenir o lixo eletrônico

   A dependência de fornecedores para atualizações essenciais não deve resultar em produtos de software abandonados que não podem ser usados ​​sem apresentar sérias desvantagens para os usuários, como vulnerabilidades a malware. As atualizações de segurança devem ser fornecidas por até cinco anos após a descontinuação do desenvolvimento do software. Além disso, as atualizações de segurança devem ser separáveis ​​das atualizações de recursos, para que os usuários não sejam coagidos a adotar funcionalidades indesejadas, como o excesso de recursos e outras formas de inchaço. Esses softwares abandonados e inchados tornam o hardware inutilizável e produzem lixo eletrônico desnecessário.

4. Desinstalabilidade — Removendo software indesejado para aumentar a eficiência

   A capacidade de desinstalar completamente softwares desnecessários traz benefícios ecológicos. O excesso de softwares, o acúmulo de funcionalidades e componentes indesejados podem gerar ineficiências, ocupando memória, desperdiçando tempo de processamento, aumentando o uso de disco, consumindo espaço de armazenamento e causando atrasos na inicialização e no desligamento do sistema. Quando um usuário não deseja mais usar um programa de computador, deve ser possível removê-lo completamente do sistema, mantendo todos os dados gerados pelo usuário.

5. Funcionamento offline — Para evitar dependências e diminuir o consumo de energia

   O uso do software deve ser possível sem uma conexão com a internet — a menos, é claro, que uma conexão de rede seja necessária para a funcionalidade pretendida do software. Servidores de licença e outras formas de controle de acesso restringem o uso de um aplicativo de maneiras desnecessárias para a funcionalidade pretendida do software. Quando um servidor fica inativo ou há uma interrupção na internet, esse controle de acesso impede que as pessoas usem seu software, possivelmente de forma permanente. Além disso, essas dependências exigem tráfego de rede e, portanto, consomem energia além da necessária para a finalidade pretendida do software.

6. Modularidade — Para reduzir as necessidades de memória e energia

   Os usuários devem poder instalar apenas o que precisam. Funções não essenciais aumentam a demanda de memória e energia, tornando o software menos eficiente e possivelmente incompatível com hardware mais antigo. As pessoas devem ter a possibilidade de limitar o conjunto de funções do software àquelas que desejam ou necessitam.

7. Liberdade da publicidade — Opção de não participar para reduzir o consumo de energia

   O uso indesejado de dados somente na União Europeia é aproximadamente equivalente ao consumo anual de energia de uma cidade como Lisboa ou Turim; veja a PARTE I. Permitir que os usuários optem por não receber anúncios reduz a demanda de energia e recursos nos dispositivos dos usuários finais e nos servidores que exibem os anúncios. A opção de não receber anúncios também diminui o volume de dados transmitidos e, portanto, reduz o consumo de energia do tráfego de rede.

8. Documentação — Para dar suporte à conservação de recursos e ao uso contínuo de software… e, portanto, de hardware

   A documentação é um pré-requisito para a viabilidade a longo prazo de um produto de software. Ela também deve demonstrar a capacidade do software de conservar recursos. Ao documentar os critérios listados acima, os usuários podem continuar utilizando o software — e, consequentemente, o hardware — de forma sustentável, enquanto os desenvolvedores podem manter o software sem dependências ou restrições impostas pelos fornecedores.

O design de software que atende aos critérios de premiação tem menos probabilidade de sofrer com várias formas de ineficiência. Isso, por sua vez, pode ajudar a mitigar o problema do lixo eletrônico: com softwares que não causam obsolescência precoce de hardware, menos dispositivos precisam ser produzidos e enviados, o que significa menos metais valiosos que precisam ser extraídos e processados, resultando, consequentemente, em uma redução da poluição da água e do solo. Ao garantir a autonomia do usuário, os desenvolvedores podem assegurar que seu software reduza os danos ambientais de diversas maneiras — seja mantendo os dispositivos em uso por mais tempo ou reduzindo o consumo de energia e recursos do software durante o uso.

Com foco na transparência em relação à eficiência de recursos e energia, vida útil do hardware e autonomia do usuário, os critérios do selo Blue Angel para software oferecem uma estrutura abrangente para iniciar uma discussão sobre sustentabilidade de software. Nas comunidades de software livre e de código aberto (FOSS), muitas vezes consideramos a autonomia do usuário, a transparência e seus benefícios como garantidos. Embora ser software livre e de código aberto não seja um requisito para obter o selo ecológico Blue Angel, é nessa categoria que o FOSS realmente se destaca. De muitas maneiras, já estamos na vanguarda do design de software sustentável!

Okular, o primeiro programa de computador com certificação ecológica

Em 2022, o Okular, o popular leitor de PDF multiplataforma e visualizador de documentos universal do KDE, foi o primeiro software a ser oficialmente reconhecido por seu design sustentável, conforme refletido nos critérios do prêmio Blue Angel. O Okular também é o primeiro programa de computador com certificação ecológica da Rede Global de Selos Ecológicos.

O Okular é apenas um dos produtos de software mantidos pela KDE, uma comunidade mundial de engenheiros de software, artistas, escritores, tradutores e criadores comprometidos com o desenvolvimento de Software Livre. A comunidade KDE mantém inúmeros produtos FOSS, incluindo o ambiente de desktop Plasma; o aplicativo de design para pintores e artistas gráficos, Krita; o pacote GCompris de atividades educacionais para crianças; o Kdenlive, um software profissional de edição de vídeo; e, claro, o Okular, um visualizador de documentos para PDFs, quadrinhos, artigos científicos e acadêmicos e desenhos técnicos.

Com a missão e a visão orientadoras de longa data do KDE desde sua fundação em 1996, bem como o talento e as capacidades dos membros de sua comunidade, o KDE é pioneiro na defesa de software sustentável. Em 2021, o KDE lançou o KDE Eco, um projeto com o objetivo de colocar o KDE e o Software Livre na vanguarda do design de software sustentável. A sustentabilidade não é novidade para o Software Livre e de Código Aberto (FOSS) — as quatro liberdades sempre fizeram do Software Livre um software sustentável. Mas agora, os dois pilares do FOSS — transparência e autonomia do usuário — têm um reconhecimento mais amplo por seus impactos na sustentabilidade e foram incorporados aos critérios de sustentabilidade definidos pela Agência Ambiental Alemã por meio do selo ecológico Blue Angel.

Com o primeiro produto de software com certificação ecológica, a comunidade KDE comemorou a conquista juntamente com a ampla comunidade do Software Livre , bem como com o departamento de ciência da computação em Umwelt Campus Birkenfeld, onde pesquisadores mediram o consumo de recursos e energia do Okular e de outros softwares do KDE.

Os critérios do prêmio Blue Angel refletem perfeitamente os valores do KDE e do movimento FOSS em geral. O Software Livre e de Código Aberto garante transparência e entrega o controle aos usuários, em vez de obrigá-los a trabalhar com determinados fornecedores ou provedores de serviços. Isso permite que os usuários decidam o que desejam do software que usam e, por sua vez, tomem decisões sobre o hardware que utilizam também. Os usuários podem reduzir o consumo de energia de seus programas com pouca ou nenhuma perda de funcionalidade, instalando apenas o que precisam, nada mais e nada menos. Eles também podem evitar publicidade invasiva ou opções de mineração de dados que executam processos em segundo plano, consumindo ainda mais recursos no dispositivo e na rede. Quanto aos desenvolvedores de FOSS, eles normalmente continuam a dar suporte a hardware que a indústria estaria ansiosa para tornar obsoleto, fornecendo aos usuários software atualizado e seguro para dispositivos que, de outra forma, poderiam ser descartados como lixo eletrônico e acabar poluindo aterros sanitários.

Lançado sob a licença GPLv2+, o Okular é FOSS e, portanto, já atende a muitos dos critérios de autonomia do usuário necessários para obter o selo de aprovação Blue Angel. Trabalhos adicionais foram realizados para tornar o Okular totalmente compatível com os critérios da premiação, documentando os recursos de autonomia do usuário, fornecendo transparência no consumo de energia e recursos e suportando a possível extensão da vida útil do hardware dos dispositivos.

O Okular permite que você verifique assinaturas digitais e assine documentos você mesmo, além de incluir texto anotado e comentários diretamente incorporados ao documento. O Okular funciona em Linux, Windows, Android e Plasma Mobile, e está disponível para download para todas as distribuições GNU/Linux, como um pacote independente do Flathub e da Snap Store, através do repositório de lançamentos do KDE F-Droid para Android, bem como na Microsoft Store. O código-fonte também está prontamente disponível no repositório GitLab do Okular para que todos possam usar, estudar, compartilhar, aprimorar e, acima de tudo, aproveitar.

O KDE e a comunidade de Software Livre gostariam de enviar um sincero agradecimento aos desenvolvedores do Okular por criarem software ecologicamente correto para todos nós!

Na PARTE III deste manual, veremos os passos que você precisa seguir para que seu projeto de Software Livre também seja reconhecido por seu design de software sustentável. Mas, primeiro, quais são exatamente os benefícios de obter o Selo Blue Angel?

Benefícios do Blue Angel

Steffi Lemke, Ministra Federal do Meio Ambiente, Conservação da Natureza, Segurança Nuclear e Proteção do Consumidor (BMUV), disse o seguinte sobre a reputação do Blue Angel:

Um número crescente de pessoas prioriza a durabilidade e o respeito ao meio ambiente na hora de comprar produtos. É exatamente isso que o selo Blue Angel representa. Há 40 anos, esse selo ecológico garante altos padrões de proteção ao meio ambiente e à saúde, de forma independente e confiável.

De fato, em seu livreto informativo do 40^o aniversário “Blue Angel – 40 anos. Bom para mim. Bom para o meio ambiente”, a Agência Ambiental Alemã (UBA) explorou a história, o presente e o futuro do selo ecológico. No livreto, eles identificam alguns dos critérios gerais que consideram ao certificar um produto ecologicamente, tais como:

• redução das emissões de substâncias nocivas no solo, ar, água e ambientes internos;
• produção sustentável de recursos;
• longevidade, capacidade de reparar e reciclar o produto; e
• uso eficiente, por exemplo, produtos que economizam energia.

Ao chegar ao final desta seção, esperamos que fique claro como a conformidade com os critérios do prêmio Blue Angel para software de desktop promove os benefícios ambientais mencionados acima, entre outros.

Os selos ambientais podem ser um instrumento para direcionar os mercados em direção a produtos sustentáveis. Como afirma o site da Blue Angel: “O objetivo do selo ambiental é fornecer aos consumidores privados, grandes instituições e instituições públicas orientações confiáveis ​​para compras ambientalmente conscientes.”

Então, o que diz o mercado?

Uma pesquisa do info-booklet revelou que 92% dos alemães reconhecem o selo ecológico e, para 37%, o selo influencia suas escolhas de compra. O selo ecológico também é reconhecido fora da Alemanha! Até 15% dos premiados com o selo Blue Angel estão fora da Alemanha. Uma das razões para isso é que, diferentemente de outros selos ecológicos, o Blue Angel não impõe restrições quanto ao local de comercialização do produto. Além disso, o selo Blue Angel é considerado um símbolo de alta qualidade internacionalmente, e os critérios de premiação são vistos como um indicador da direção do mercado da UE — sendo inclusive utilizados, por vezes, como guia para a otimização de produtos.

Receber o selo Blue Angel pode aumentar a visibilidade do seu produto não apenas entre indivíduos, mas também entre grandes organizações. As iniciativas de Compras Públicas Sustentáveis ​​(CPS), que "buscam promover a aquisição pública de bens, serviços e obras com um impacto ambiental reduzido ao longo de seu ciclo de vida" (Comissão Europeia), influenciam as escolhas de compra tanto no setor público quanto no privado. A certificação ecológica do seu software com o selo Blue Angel demonstra um compromisso com a sustentabilidade digital a longo prazo e dá visibilidade ao seu produto tanto na Alemanha quanto no exterior.

Uma nota sobre as fontes

Parte do material desta seção é baseado diretamente em textos de dois artigos da Wikipédia: (i) “Blue Angel (certificação)” e (ii) “Software bloat”. Ambos os textos são publicados sob a licença Creative Commons de Atribuição Compartilhada 3.0. Parte do material desta seção também se baseia diretamente na postagem “Primeiro programa de computador com certificação ecológica: o popular leitor de PDF do KDE, Okular” do blog KDE Eco, que é publicada sob a Licença Internacional Creative Commons de Atribuição Compartilhada 4.0.

Parte III: Cumprindo os critérios do prêmio Blue Angel

As três categorias principais dos critérios do prêmio Blue Angel para software de desktop são:

• (A) Eficiência de recursos e energia
• (B) Vida útil potencial do hardware
• (C) Autonomia do usuário

Nesta seção, forneceremos um guia prático para atender a cada conjunto de critérios. Há inúmeros benefícios em atender aos critérios básicos de premiação. Ao tornar o consumo de energia do seu software transparente e cumprir os critérios de vida útil do hardware e autonomia do usuário, você obtém os seguintes benefícios:

• Certificação Ecológica: Solicite o selo ecológico Blue Angel para demonstrar aos usuários, empresas e organizações governamentais que seu software foi projetado de forma sustentável.
• Desenvolvimento orientado por dados: Identifique ineficiências no consumo de energia e hardware e tome decisões baseadas em dados para o desenvolvimento do seu software.
• Design Sustentável: Para o uso sustentável a longo prazo do software e, consequentemente, do hardware, leve em consideração os critérios de autonomia do usuário ao planejar o design do seu software.
• Informações para o usuário final: Destaque para seus usuários as maneiras pelas quais seu software já foi projetado de forma sustentável, utilizando os critérios do Blue Angel como referência.

(A) Como medir seu software

A configuração do laboratório consiste em um medidor de energia, um computador para agregar e avaliar a saída do medidor de energia e um computador desktop para o sistema em teste, onde o comportamento do usuário é emulado. A configuração descrita aqui segue as especificações dos “Critérios Básicos do Prêmio Blue Angel para Produtos de Software com Uso Eficiente de Recursos e Energia”.

A terminologia provém em parte de Kern et al. (2018): “Produtos de software sustentáveis ​​— Rumo a critérios de avaliação para eficiência de recursos e energia”.

Veja também os seguintes recursos do Umwelt Campus Birkenfeld:

• Seiwert & Zaczyk (2021): “Projektbericht: Ressourceneffiziente Softwaresysteme am Beispiel von KDE-Software” (German only)
• Mai (2021): “Vergleichende Analyse und Bewertung von Betriebssystemen hinsichtlich ihrer Energieeffizienz” (German only)
• “OSCAR Manual” (Somente em alemão)

Visão geral da configuração do laboratório

A configuração do laboratório requer 1 medidor de potência e pelo menos 2 computadores:

• Medidor de Potência

  Um dos dispositivos recomendados pelo Blue Angel é o Gude Expert Power Control Série 1202 (manual). Ele fornece tomadas para alimentar o computador e mede a corrente durante a operação. O dispositivo pode ser controlado e lido via Ethernet cabeada. Há uma interface de usuário baseada na web, uma API REST e o dispositivo suporta vários protocolos, como SNMP ou syslog.

• Computador 1: Agregador e Avaliador de Dados

  O computador será utilizado para coletar e avaliar os resultados do medidor de energia.

  Um script em Python para ler os dados do Gude Expert Power Control Série 1202 está disponível no repositório FEEP.

  É recomendável monitorar o progresso em tempo real com o segundo computador para garantir que tudo esteja ocorrendo sem problemas. Isso pode ser feito com o Labplot do KDE, por exemplo. Leia mais aqui.

  Outros medidores de energia podem exigir software não livre, por exemplo, o Software de Monitoramento de Rede Elétrica GridVis da Janitza.

• Computador 2: Sistema em teste

  O sistema de referência é o hardware usado para medir o consumo de energia do “sistema em teste” (SUT, sigla em inglês). O SUT inclui o sistema operacional e o software instalado para (i) testar o produto de software, (ii) emular o cenário de uso padrão² e (iii) coletar os resultados de desempenho do hardware.

Observe o seguinte:

• Para sistemas GNU/Linux, os critérios Blue Angel (Seção 1.1) exigem um dos vários computadores Fujitsu como sistema de referência.
• Para emular a atividade no cenário de uso padrão, podem ser usadas ferramentas de automação de tarefas de Software Livre, como xdotool, KDE Eco Tester (em desenvolvimento) ou Actiona (GPLv3).
• Para coletar dados de desempenho de hardware (por exemplo, utilização do processador e da RAM, atividade do disco rígido, tráfego de rede), a ferramenta de software livre Collectl (Licença GPLv2/Artística) está disponível.
• Também é possível reutilizar tomadas elétricas comutáveis ​​baratas como dispositivos de medição; veja a seção “Alternativa: Configuração do Gosund SP111” para obter instruções de configuração.

Sistema em teste (SUT, sigla em inglês)

Por exemplo, o computador de mesa Fujitsu Esprimo P920 proGreen selection (Intel Core i5-4570 3,6GHz, 4GB RAM, 500GB HDD) é um dos sistemas de referência recomendados. Consulte o Apêndice D nos critérios de premiação para outros sistemas Fujitsu recomendados.

No sistema de referência, você precisa configurar o SUT, ou seja, o sistema no qual você testará o software. O SUT deve reduzir o consumo de energia desnecessário e ter uma configuração padronizada. Recomenda-se o seguinte:

• Substitua todo o disco rígido da máquina por um sistema operacional padronizado.
• Desative todos os processos em segundo plano (atualizações automáticas, backups, indexação, etc.).
• Instale o software necessário, ou seja, o aplicativo a ser medido, bem como o software de emulação de usuário (por exemplo, xdotool) e o software de dados de desempenho de hardware (por exemplo, Collectl).
• Ao executar os scripts de cenário de uso, o cache deve ser limpo entre as execuções e quaisquer arquivos novos devem ser excluídos antes de iniciar a próxima medição.

Preparando o Cenário de Uso Padrão (SUS, sigla em inglês)

A preparação do SUS requer o seguinte:

• Identificar as tarefas que os usuários normalmente realizam ao usar o aplicativo em questão.
• Identificar funcionalidades que exigem alta demanda de energia ou alta utilização de recursos.
• Com base no exposto, elabore um fluxograma de ações individuais e emule essas ações com uma ferramenta de automação de tarefas.
• Recomenda-se programar um período de espera de 60 segundos antes de iniciar a medição.
• Deixe o SUS funcionando por pelo menos 5 minutos.

É necessária uma ferramenta de automação para executar os cenários de uso sem a necessidade de intervenção humana. Dessa forma, o script pode ser executado repetidamente de maneira bem definida para fornecer medições precisas.

Tarefas e funções de exemplo testadas no SUS para o cliente de e-mail do KDE KMail incluem pesquisar um e-mail, escrever uma resposta ou encaminhar o e-mail, salvar um anexo, excluir uma pasta no cliente de e-mail, etc. Consulte os scripts Actiona usados ​​para testar o Krita e o Okular para obter mais exemplos.

Importante: Se a ferramenta de emulação usar coordenadas de pixel para armazenar a posição dos cliques automatizados (por exemplo, Actiona) e, além disso, a resolução da tela do computador usado na preparação for diferente da do computador do laboratório, todas as coordenadas de pixel terão que ser redefinidas para o ambiente do laboratório.

Mais ferramentas de emulação

Além do xdotool, do KDE Eco Tester (em desenvolvimento) ou do Actiona, existem outras ferramentas candidatas que podem atender aos requisitos. Veja uma lista do colaborador do KDE, David Hurka, na apresentação “Ferramentas de Automação Visual de Fluxo de Trabalho”. A maioria das ferramentas usa recursos específicos do X11 e, portanto, não funciona em sistemas Wayland. Existem algumas abordagens possíveis:

• Selenium Webdriver usando AT-SPI (atualmente em fase de testes para a Temporada do KDE 2023)
• O portal XDG RemoteDesktop
• Diversos protocolos do Wayland (o suporte varia entre compositores):
  • https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-virtual-pointer-unstable-v1.xml
  • https://api.kde.org/frameworks/kwayland/html/classKWayland_1_1Client_1_1FakeInput.html
• dispositivos de usuário do libinput

Processo de medição

O processo de medição está definido no Apêndice A dos Critérios Básicos de Premiação. Ele exige o registro e a anotação de dados de energia e indicadores de desempenho com granularidade de 1 segundo, para que possam ser processados ​​e os valores médios calculados.

Algumas observações gerais:

• Os horários entre PM e DAE devem ser sincronizados.
• Ao usar o Collectl para coletar dados de carga de desempenho, certifique-se de que ele esteja em execução no console do sistema em teste (SUT). Além disso, verifique se o arquivo CSV necessário foi gerado corretamente antes de realizar os testes.
• Como cada execução dos cenários de uso resulta em alterações no sistema operacional padrão, recomenda-se limpar o cache entre as execuções.
• Todas as execuções (Linha de Base, Modo Ocioso, Cenário de Uso Padrão) devem ter a mesma duração, com base no tempo necessário para executar o script do cenário de uso.
• No DAE, talvez seja necessário confirmar se a tomada elétrica desejada está sendo lida corretamente antes e/ou durante o teste (por exemplo, com um gráfico em tempo real usando o LabPlot).

Durante as medições de energia, o Collectl é usado para registrar um conjunto de indicadores de desempenho: utilização do processador, utilização da RAM, atividade do disco rígido e tráfego de rede. Use o seguinte comando para obter esses dados de desempenho de hardware:

$ collectl -s cdmn -i1 -P --sep 59 -f </CAMINHO/PARA/ARQUIVO>.csv

As opções são as seguintes:

• -s cdmn

  coleta dados de CPU, disco, memória e rede

• -i1

  intervalo de amostragem de 1 segundo

• -P

  saída em formato de gráfico (dados separados, consistindo em um cabeçalho com uma linha por intervalo de amostragem)

• --sep 59

  separador de ponto e vírgula

• -f </CAMINHO/PARA/ARQUIVO>.csv

  salvar arquivo no caminho especificado

Medição de cenários de uso de linha de base, modo ocioso e padrão

• Cenário de linha base: Sistema Operacional (SO)

  Para estabelecer a linha de base, é realizado um cenário no qual o sistema operacional está em execução, mas nenhuma ação é tomada.

• Cenário de modo ocioso: SO + Aplicativo em Modo Ocioso

  Para estabelecer os dados de consumo de energia e desempenho de hardware do aplicativo em modo ocioso, é realizado um cenário no qual o aplicativo em questão é aberto, mas nenhuma ação é executada.

  Importante: os modos de linha de base e ocioso devem ser executados pelo mesmo tempo necessário para realizar o cenário de uso padrão. Como o consumo de energia para os cenários de linha de base e ocioso é relativamente uniforme, 10 repetições para cada um são consideradas suficientes para obter uma amostra representativa (Seiwert & Zaczyk 2021).

• Cenário de uso padrão: SO + Aplicativo em uso

  Para medir o consumo de energia e o desempenho do hardware da aplicação em uso, deve-se executar o cenário de uso padrão (SUS). Consulte as notas de preparação do SUS acima. A medição do cenário de uso padrão deve ser repetida 30 vezes, o que levará várias horas para ser concluída. O maior número de repetições é necessário para obter uma amostra representativa, visto que o consumo de energia e os dados de desempenho podem variar entre as medições.

Monitorando a saída com o Labplot

Você pode usar o LabPlot do KDE para monitorar a saída em tempo real à medida que os dados chegam. Para fazer isso:

• Redirecione a saída do medidor de energia para um arquivo CSV.
• No LabPlot, importe o arquivo CSV selecionando Arquivo > Adicionar novo > Fonte de dados em tempo real…
• Em “Filtro”, selecione a opção Personalizado. Em “Formato de dados”, defina o valor do separador a ser usado (por exemplo, vírgula, ponto e vírgula, espaço).
• Você pode verificar se a saída está correta na aba “Visualizar”.
• Se tudo estiver correto, clique em OK.
• Por fim, clique com o botão direito do mouse na janela do quadro de dados e selecione Plotar dados > Curva xy.

Análise dos resultados com o OSCAR

Após obter os resultados, o Umwelt Campus Birkenfeld disponibiliza uma ferramenta útil para gerar relatórios chamada OSCAR (Open source Software Consumption Analysis in R, ou, Software de Código Aberto de Análise de Consumo em R):

• Código fonte
• Instância em execução

Consulte também o Manual do OSCAR, que contém instruções detalhadas, incluindo capturas de tela adicionais sobre como usar o OSCAR.

Arquivos CSV

A análise com o OSCAR requer o envio dos seguintes arquivos para o site do OSCAR:

• (i) um arquivo de registro das ações realizadas,
• (ii) os dados de consumo de energia, e
• (iii) os dados de desempenho do hardware.

Todos os arquivos devem ser arquivos CSV. Algum pré-processamento dos dados brutos pode ser necessário (por exemplo, dados de desempenho medidos pelo Collectl; veja abaixo).

Importante: o OSCAR é muito exigente quanto aos formatos dos data frames, incluindo nomes de colunas e valores de células. As tabelas aqui fornecem exemplos que foram confirmados como funcionais. Se você estiver com problemas para gerar um relatório a partir de seus arquivos CSV, certifique-se de que os arquivos CSV sejam o mais semelhantes possível aos mostrados aqui.

Se você apenas deseja testar o OSCAR, pode baixar os dados para Okular neste arquivo ZIP. Os dados foram confirmados para gerar um relatório com sucesso usando o OSCAR v0.190404. O relatório gerado também pode ser baixado no repositório FEEP.

Arquivo de registro de ações

O arquivo de registro de ações deve ter o seguinte formato. Observe que as colunas são separadas por ponto e vírgula. Além disso, as colunas não têm nomes (ou seja, não há cabeçalho no arquivo CSV). Observe também que o início e o fim de cada iteração devem ser identificados com 'startTestrun' e 'stopTestrun' na segunda coluna, enquanto as ações podem ser listadas com qualquer nome.

Um exemplo de arquivo de registro de ações para medir o Kate, editor de texto e código do KDE. A (i) data e hora, bem como (ii) horários de início e término e (iii) ações são listados em três colunas.

Dados de consumo de energia

Os dados de consumo de energia têm o seguinte formato: a primeira coluna é o número da linha, a segunda coluna é a data e hora em incrementos de um segundo e a terceira coluna é a potência medida em Watts. Observe que o seguinte funciona corretamente com o OSCAR: (i) os nomes da segunda e terceira colunas conforme escritos abaixo (ou seja, “Zeit” e “Wert 1-avg[W]”), (ii) a data e hora como uma string de caracteres com a data e hora separadas por vírgula e (iii) nenhum delimitador de string usado no arquivo CSV.

Ao usar o medidor de potência Gude com o script Python disponível no repositório FEEP, o registro de data e hora será feito em nanossegundos no tempo Epoch. Por exemplo, abaixo está um exemplo da saída bruta de 7 linhas do medidor de potência Gude usando o script Python. A primeira coluna mostra o registro de data e hora. A segunda coluna é a leitura do medidor de potência em Watts.

Os dados brutos podem ser pré-processados ​​em R: Nanossegundos no tempo Epoch podem ser convertidos para data e hora com o comando as.POSIXct(<NANOSEGUNDOS>/1000000, origin = '1970-01-01', tz = 'Europe/Berlin'). Por exemplo, os nanossegundos na linha 1 da saída bruta são “2022-08-27 16:52:03 CEST” após a conversão.

Para usar com o OSCAR, essa data e hora devem ser convertidas em uma string de caracteres com a data no formato DD.MM.AA seguida por uma vírgula. Tudo isso pode ser feito com um único comando (essa operação pode ser vetorizada em toda a coluna do dataframe); substitua a data no formato AAAA-MM-DD pela data das suas medições:

stringr::str_replace(as.character(as.POSIXct(1661611923019071/1000000, origin = '1970-01-01', tz = 'Europe/Berlin')), '2022-08-27', '27.08.22,')

A potência de saída em Watts deve ser calculada como a média por segundo. Os mesmos dados acima são mostrados abaixo após o processamento com R; observe que os 7 valores acima são calculados como a média por segundo, resultando em duas linhas.

Para salvar o arquivo CSV com ponto e vírgula como separador, a primeira coluna com os nomes das linhas começando em 1 e sem delimitador de texto, use o seguinte comando em R:

write.csv2(<DATAFRAME>, file = <CAMINHO/PARA/ARQUIVO.csv>, row.names = TRUE, quote = FALSE)

O resultado deverá ser algo semelhante ao seguinte:

Dados de desempenho (Raw)

Ao usar o Collectl para dados de desempenho de hardware, é necessário fazer o seguinte antes de enviar os dados para o OSCAR.³

• Remova todas as informações acima da linha de cabeçalho.
• Remova todos os caracteres # do arquivo.
• Na primeira coluna, não deve haver nenhum valor separador entre a data e a hora (caso contrário, a data e a hora serão interpretadas como duas colunas separadas).
• A data também deve conter um caractere inserido entre AAAA/MM/DD, por exemplo, MM.DD.AAAA, como acima. Qualquer caractere utilizado deve ser especificado em OSCAR.
• Os nomes das colunas podem ser quaisquer que você desejar, pois serão especificados dentro do OSCAR.
• O arquivo deve ser salvo no formato CSV.

Além disso, os dados de desempenho de hardware gerados pelo Collectl incluem muitas colunas desnecessárias para a análise. As únicas medidas que precisam ser especificadas são as seguintes colunas:

• [CPU]Totl = Processador
• [MEM]Used = Memória principal - kilobytes usados
• [NET]RxKBTot = Rede - Kilobytes recebidos/s
• [NET]TxKBTot = Rede - Kilobytes transmitidos/s
• [DSK]ReadKBTot = Disco - Kilobytes lidos/s
• [DSK]WriteKBTot = Disco - kilobytes escritos/s.

Abaixo, segue um exemplo dos resultados pré-processados ​​do Collectl, que mede os dados de desempenho de Kate. O registro de data e hora aumenta em incrementos de um segundo.

Carregando os dados

Assim que os arquivos CSV acima estiverem prontos, você poderá executar a análise usando o OSCAR, que gerará um relatório resumido que poderá ser usado tanto para certificação ecológica quanto para seus próprios fins baseados em dados. Na interface do OSCAR, observe o seguinte:

• A interface está atualmente disponível apenas em alemão; veja abaixo as traduções.
• A duração das medições em segundos deve ser especificada.
• Utiliza-se o ponto e vírgula como separador.
• O formato correto do carimbo de data/hora deve ser especificado para cada um dos arquivos enviados, por exemplo, %Y-%m-%d %H:%M:%OS.

Etapa 1: Obter dados de medição

A página inicial do site (abaixo) afirma que o primeiro passo é obter dados de medição (em alemão: Erfassung Messdaten). Se você chegou a este ponto do processo, já deve ter medido seu software e preparado os arquivos CSV.

Todos os exemplos aqui apresentados são baseados nos dados do Okular presentes neste arquivo ZIP.

Etapa 2: Carregar os dados de medição

Depois de ter os arquivos CSV para as medições de linha de base, modo ocioso e cenário de uso padrão prontos, clique em (2) Upload Messdaten > Upload.

Os dados de medição (alemão: Messdaten) incluem o arquivo de registro de ações (alemão: Aktionen), consumo de energia (alemão: Elektrische Leistung) e dados de desempenho de hardware (alemão: Hardware-Auslastung).

• Em Messungen, carregue os dados de medição do modo ocioso ou do cenário de uso padrão.

  Para Art der Messung (‘Tipo de Medição’), no canto inferior direito da interface do usuário, selecione Leerlauf (‘Modo Ocioso’) ou Nutzungsszenario (‘Cenário de Uso’), dependendo do relatório que deseja gerar.

• Em Baselines, carregue os dados de medição das linhas de base.

• Indique a duração dos cenários de medição em segundos (alemão: Dauer der Einzelmessungen (s)).

Note que as medições de referência são sempre carregadas juntamente com as medições do modo ocioso ou do cenário de uso padrão.

Veja abaixo como fica um upload completo para o Nutzungsszenario.

Carimbos de data/hora    Depois que os dados forem carregados, você precisará informar ao OSCAR como ler os dados.

Vamos começar com o formato do carimbo de data/hora (em alemão: Formatierung Zeitstempel). Este é um aspecto do processo que pode causar problemas se não for feito corretamente. Isso é feito em (2) Upload Messdaten > Formatierung Zeitstempel.

Considere os dados do Okular:

• Para o arquivo de registro de ações, a data e hora são codificadas como AAAA-MM-DD HH:MM:SS (por exemplo, "2022-10-04 12:32:43.656" em "okularActions.csv").

  No OSCAR, isso é especificado como "%Y-%m-%d %H:%M:%OS" (veja a captura de tela abaixo). O OSCAR cuidará das frações de segundo.

• Para os dados de consumo de energia, a data e hora são codificadas como DD.MM.AA, HH:MM:SS (por exemplo, "04.10.22, 12:32:43" em “okular_baseline_eletrLeistung.csv”). Observe o ponto na data e a vírgula que separa a data da hora, bem como o fato de o ano ter apenas dois dígitos.

  No OSCAR, isso é especificado como "%d.%m.%y, %H:%M:%OS" (veja a captura de tela abaixo), em que o “%y” minúsculo indica um ano com dois dígitos.

• Para os dados de desempenho de hardware, a data e hora são codificadas como DD.MM.AAAA HH:MM:SS (por exemplo, "04.10.2022 12:31:43" em “baseline_hardware_formatiert.csv”). Observe o ponto na data e o ano com quatro dígitos.

  No OSCAR, isso é especificado como: "%d.%m.%Y %H:%M:%OS" (veja a captura de tela abaixo), em que o “%Y” maiúsculo indica um ano com quatro dígitos.

Dados de medição    Após os registros de data e hora terem sido especificados corretamente, vamos explorar o formato dos dados de medição (em alemão: Formatierung Messdaten) no OSCAR.

Primeiro, dê uma olhada no arquivo de log de ações (em alemão: Aktionen). Isso é feito em (2) Upload Messdaten > Formatierung Messdaten > Aktionen.

Aqui você precisa indicar para o arquivo CSV carregado o separador (em alemão: Trennzeichen), o delimitador de string (em alemão: Textqualifizierer) e o separador decimal (em alemão: Dezimaltrennzeichen).

Para os dados Okular, isso é definido como um separador de ponto e vírgula, um delimitador de string de aspas duplas e um ponto final como separador decimal (veja a captura de tela abaixo).

Além disso, você precisará especificar o seguinte:

• se a primeira linha contém títulos (em alemão: Erste Zeile enthält Überschriften);
• o número de linhas a serem ignoradas (em alemão: Anzahl zu überspringender Zeilen); e
• a codificação de caracteres (em alemão: Zeichensatz (Encoding)).

Para os dados Okular, isso é definido da seguinte forma na captura de tela a seguir: a opção “a primeira linha contém cabeçalhos” está desmarcada, 0 linhas são ignoradas e a codificação de caracteres é utf-8.

Quando tudo estiver configurado corretamente, uma pré-visualização da planilha será exibida.

Em segundo lugar, dê uma olhada nas medições de consumo de energia (em alemão: Elektrische Leistung). Isso é feito em (2) Upload Messdaten > Formatierung Messdaten > Elektrische Leistung.

A entrada necessária é a mesma que para o arquivo de registro de ações, conforme mostrado na seguinte captura de tela.

Para os dados Okular aqui apresentados, temos um separador de ponto e vírgula, um delimitador de strings com aspas duplas e a codificação de caracteres utf-8. No entanto, agora uma vírgula foi especificada como separador decimal e uma marca de seleção indica que a primeira linha contém cabeçalhos. Por fim, a primeira linha foi omitida.

Quando tudo estiver configurado corretamente, uma pré-visualização da planilha será exibida.

Finalmente, dê uma olhada nos dados de desempenho do hardware (em alemão: Hardware-Auslastung). Isso é feito em (2) Upload Messdaten > Formatierung Messdaten > Hardware-Auslastung.

A entrada necessária é a mesma. Neste exemplo, a entrada consiste em um ponto e vírgula como separador, aspas duplas como delimitador de string e um ponto (ou seja, um ponto final) como separador decimal. Há uma marca de seleção indicando que a primeira linha contém cabeçalhos, nenhuma linha foi ignorada e a codificação de caracteres é UTF-8.

No entanto, agora existe o requisito adicional de especificar as colunas (em alemão: Spalten).

Para a especificação das colunas, é necessário identificar o seguinte; selecione NA para colunas não utilizadas, por exemplo, “Auslastung Auslagerungsdatei” neste caso.

• Zeitstempel: Data-hora (ou seja, ‘Date-Time’)
• CPU-Auslastung: CPU (ou seja, ‘X.CPU.Totl’)
• RAM-Auslastung: RAM (ou seja, ‘X.MEM.Used’)
• Über Netzwerk gesendet: Rede transmitida (ou seja, ‘X.NET.TxKBTot’)
• Über Netzwerk empfangen: Rede recebida (ou seja, ‘X.NET.RxKBTot’)
• Von Festplatte gelesen: Disco lido (ou seja, ‘X.DSK.ReadKBTot’)
• Auf Festplatte geschrieben: Disco escrito (ou seja, ‘X.DSK.WriteKBTot’)
• Auslastung Auslagerungsdatei: Troca (aqui, ‘N/A’)

Traduções

Segue abaixo uma visão geral de alguns dos termos alemães usados ​​em OSCAR e suas traduções para o português:

• Messungen: Medições (por exemplo, Modo Ocioso ou SUS)
• Aktionen: Ações (ou seja, arquivo de registro das ações realizadas)
• Elektrische Leistung: ‘Energia elétrica’ (ou seja, medições de consumo de energia)
• Hardware-Auslastung: 'Carga de hardware' (ou seja, medições de desempenho de hardware)
• Dauer der Einzelmessungen (s): ‘Duração das medições individuais (s)’ (ou seja, especifica quanto tempo durou cada iteração em segundos)
• Art der Messung: Tipo de medição’
  • Leerlauf: ‘Ocioso’ (ou seja, modo ocioso)
  • Nutzungsszenario: ‘Cenário de uso’ (ou seja, SUS)
• Formatierung Messdaten: ‘Formatação de dados de medição’
• Formatierung Zeitstempel: ‘Formatação do carimbo de data/hora’
• Trennzeichen ‘Separador’
• Textqualifizierer: ‘Delimitador de texto’
• Dezimaltrennzeichen: ‘Separador decimal’
• Erste Zeile enthält Überschriften: ‘Primeira linha contém cabeçalho’
• Anzahl zu überspringender Zeilen: ‘Número de linhas a pular’
• Zeichensatz (Encoding): ‘Conjunto de caracteres (codificação)’
• Spalten: Colunas
  • Zeitstempel: ‘Data-hora’
  • CPU-Auslastung: ‘Uso da CPU’
  • RAM-Auslastung: ‘Uso de RAM’
  • Über Netzwerk gesendet: ‘Enviado via rede’
  • Über Netzwerk empfangen: ‘Recebido via rede’
  • Von Festplatte gelesen: ‘Lido do disco’
  • Auf Festplatte geschrieben: ‘Escrito no disco’
  • Auslastung Auslagerungsdatei: ‘Uso do arquivo de troca’

Etapa 3: Geração dos relatórios (Ocioso, SUS)

Após concluir os passos acima, o relatório poderá ser gerado e baixado. Você precisará realizar esse processo duas vezes, uma para (i) o modo ocioso e (ii) as medições do cenário de uso padrão, resultando em dois documentos.

Para a certificação ecológica Blue Angel, os dois relatórios serão submetidos à avaliação da RAL.

Para exemplos do que foi mencionado acima para o Okular, consulte o repositório Aplicativos Blue Angel do KDE:

• Relatório do OSCAR: Modo Ocioso
• Relatório do OSCAR: SUS

Preparando a documentação para o Blue Angel

Para a certificação ecológica Blue Angel, é necessário preencher diversos formulários, além dos dois relatórios do OSCAR.

As informações que precisam ser incluídas nos formulários são as seguintes:

• Detalhes sobre o software (nome, versão) e o processo de medição (quando e onde as medições foram feitas, etc.).
• Detalhes técnicos sobre o medidor de potência (instrumento, frequência de amostragem, duração do cenário, tamanho da amostra).
• Detalhes técnicos sobre o sistema de referência (ano, modelo, processador, núcleos, etc.).
• Conjunto de softwares utilizados para as medições (xdotool, Collectl, etc).
• Requisitos mínimos do sistema (arquitetura do processador, memória de trabalho local, etc.).
• Os resultados de consumo de energia podem ser encontrados nos relatórios OSCAR ou equivalentes.
• Resultados de utilização de hardware, que incluem o seguinte (para OCIOSO, utilize as medições do modo ocioso e, para SUS, utilize as medições do cenário de uso padrão):

  • Carga Total: “Para poder de processamento, a carga total é de 100%, para memória de trabalho a soma das capacidades de RAM instaladas, para largura de banda de rede a velocidade máxima de transmissão, etc.” (Critérios do prêmio Blue Angel: p. 23).

  • Carga Base: Carga média do sistema de referência nas medições de linha de base.

  • Carga Ocioso/SUS: Carga média do sistema de referência para medições Ocioso/SUS.

    Com base nas medições acima, os seguintes cálculos foram feitos para a utilização do hardware (para o modo ocioso, utilize as medições do modo ocioso e, para o modo de uso padrão, utilize as medições do cenário de uso padrão):

    • Carga Líquida: Carga OCIOSO/SUS Load - Carga Base
    • Fator de Alocação: Carga Líquida/(Carga Total - Carga Base)
    • Carga Efetiva: Carga Líquida + Fator de Alocação * Carga Base
    • Uso do Hardware (somente SUS): Carga efetiva * Tempo (segundos)

Para a certificação ecológica Blue Angel, as informações acima serão adicionadas a dois documentos denominados “Anexo 1” e “Anexo 2”.

Para exemplos do que foi mencionado acima para o Okular, consulte o repositório Aplicativos Blue Angel do KDE:

• Anexo 1
• Anexo 2

Alternativa: Configuração Gosund SP111

Quer começar a medir o consumo de energia do seu software, mas está com pouco dinheiro ou equipamentos? Quer experimentar o processo sem montar um laboratório dedicado? Experimente esta dica de Volker Krause, que converte um adaptador de tomada barato em um medidor de consumo de energia. Ele também documentou o processo aqui. Você pode ler mais nos seguintes posts do blog do Volker:

• “Medição de Potência Elétrica Barata”
• “KDE Eco Sprint de Julho de 2022”

Abaixo está um guia para configurar uma tomada elétrica Gosund SP111 já com firmware Tasmota em 10 etapas.

Embora os dados do medidor de energia barato provavelmente não sejam aceitos pelo Blue Angel para certificação ecológica, ainda é possível obter dados preliminares usando esta ferramenta.

• (0) Pré-requisito

  É necessário que a tomada já esteja atualizada com uma versão suficientemente recente do Tasmota.

• (1) Redefinição de Firmware

  Se o dispositivo já tiver sido conectado a outra rede Wi-Fi, pode ser necessário reiniciá-lo completamente antes de conseguir se conectar a uma nova rede.

  Se o dispositivo abriu um ponto de acesso Wi-Fi chamado “tasmota-XXXXX”, isso não é necessário, continue diretamente para (2).

  Pressione o botão por 40 segundos.

  O dispositivo será reiniciado e você poderá continuar em (2).

• (2) Configuração do WiFi

  O dispositivo abre um ponto de acesso Wi-Fi chamado “tasmota-XXXXX” e conecta-se a ele.

  Abra http://192.168.4.1 em um navegador.

  Após inserir essas informações, o dispositivo solicitará o nome e a senha da rede Wi-Fi para se conectar. Em seguida, o dispositivo se reconectará à rede Wi-Fi e desativará o ponto de acesso.

  Ao fazer isso, o navegador deverá exibir o novo endereço — anote-o.

  Caso isso não aconteça, verifique o endereço do dispositivo no seu roteador Wi-Fi.

• (3) Configuração do Tasmota

  Abra o endereço da etapa (2) em um navegador.

  Você deverá ver a interface web do Tasmota (um grande texto "LIGADO/DESLIGADO", vários botões azuis e um vermelho).

  Clique em ”Configuração”.

  Clique em “Configurar Outro”.

  Copiar

       {"NAME":"Gosund SP111 2","GPIO":
       [56,0,57,0,132,134,0,0,131,17,0,21,0],"FLAG":0,
       "BASE":18}
  

  no campo de entrada de modelo.

  Marque a caixa de seleção “Ativar”.

  Clique em Salvar”.

  O dispositivo será reiniciado; conecte-se a ele novamente.

  A interface do usuário agora também deve conter campos de texto mostrando as propriedades elétricas, e o botão "Alternar" agora deve funcionar corretamente.

• (4) Calibragem

  Abra o endereço da etapa (2) em um navegador.

  Conecte uma carga puramente resistiva com potência conhecida, como uma lâmpada incandescente convencional (não uma lâmpada LED ou economizadora de energia).

  Ligue a alimentação clicando em “Alternar”, se necessário.

  Verifique se o valor do “Fator de Potência” é exibido como 1 (ou muito próximo de 1); se for menor, a carga atual não é adequada para calibragem.

  Clique em “Console”.

  Digite os seguintes comandos um de cada vez e pressione Enter:

     AmpRes 3  
     VoltRes 3  
     EnergyRes 3  
     WattRes 3  
     FreqRes 3  
     SetOption21 1
     VoltageSet 230
  

  Digite o comando PowerSet XXX, substituindo XXX pela potência especificada para a carga de teste (por exemplo, “40” para uma lâmpada de 40W).

  Clique em ”Menu principal”.

  A página principal agora deve exibir leituras de energia corretas com precisão de várias casas decimais.

• (5) Configuração do Broker MQTT

  Atualmente, a única maneira conhecida de obter leituras automáticas de alta frequência é por meio de polling via MQTT. Infelizmente, isso não é o ideal e requer configuração adicional.

  Se você já tiver um broker MQTT, pule para a etapa (6); caso contrário, você precisará configurar um. O cenário abaixo pressupõe que o Mosquitto esteja empacotado para sua distribuição GNU/Linux (e, portanto, não configure nenhuma segurança), então faça isso apenas em sua própria rede confiável e desative-o quando não for necessário.

  • instale o pacote mosquitto

  • adicione um arquivo /etc/mosquitto/conf.d/listen.conf com o seguinte conteúdo:

     listener 1883  
     allow_anonymous true
    

  • inicie o Mosquitto usando systemctl start mosquitto.service

• (6) Configuração do MQTT do Tasmota

  Conecte-se ao dispositivo Tasmota usando um navegador da web e abra a página de configuração MQTT através de Configuração > Configurar MQTT.

  Insira o endereço IP do broker MQTT no campo “Host”.

  Anote o valor exibido à direita do rótulo "Tópico" entre parênteses (normalmente algo como "tasmota_xxxxxx"). Isso será necessário posteriormente para acessar o dispositivo via MQTT. Você também pode alterar o valor padrão para algo mais fácil de lembrar, mas esse valor precisa ser exclusivo se você tiver vários dispositivos.

  Clique em Salvar”.

  O dispositivo será reiniciado e, assim que voltar a funcionar, você deverá ver a saída no console com o prefixo “MQT”.

• (7) Verificando a comunicação MQTT

  Isso pressupõe que você tenha as ferramentas de cliente Mosquitto instaladas, que geralmente estão disponíveis como pacotes de distribuição.

  Você precisa de dois terminais para verificar se a comunicação MQTT está funcionando conforme o esperado.

  • No terminal 1, execute mosquitto_sub -t 'stat/<topico>/STATUS10'
  • No terminal 2, execute mosquitto_pub -t 'cmnd/<topico>/STATUS' -m '10'

  Substitua <topico> com o valor anotado no passo (6).

  Sempre que você executar o segundo comando, deverá ver um conjunto de valores impressos no primeiro terminal.

• (8) Medições contínuas de potência

  Veja estes scripts.

• (9) Alternando redes WiFi

  Por motivos de segurança, após conectar-se a uma rede Wi-Fi, o Tasmota não permitirá que você retorne à etapa (2) por padrão, a menos que reinicie o dispositivo (pressionando o botão por 40 segundos). No entanto, uma reinicialização completa também remove todas as configurações e a calibração. Se você precisar mudar para uma rede diferente, existem opções menos drásticas disponíveis, mas essas alterações só podem ser feitas dentro da rede à qual você se conectou originalmente:

  Em Configuração > Configurar Wi-Fi, você pode adicionar detalhes para um segundo ponto de acesso Wi-Fi. Por padrão, essas configurações serão testadas alternadamente com a primeira. Isso não compromete a segurança, mas exige que você saiba os detalhes da rede à qual deseja se conectar.

  Você pode configurar o Tasmota para abrir um ponto de acesso como no passo (2) por padrão por cerca de um minuto após a inicialização e, em seguida, tentar se conectar às configurações conhecidas. Isso torna a inicialização mais lenta em redes conhecidas e abre a possibilidade de sequestro do dispositivo, mas pode ser conveniente ao alternar para redes desconhecidas. Esse modo pode ser ativado no Console pelo comando WifiConfig 2 e desativado pelo comando WifiConfig 4.

  Na versão 11 do Tasmota, o reset por 40 segundos pressionando o botão pode deixar o dispositivo em um estado que impede a inicialização, enquanto o reset pelo Console usando Reset 1 não apresenta esse problema, mas precisa ser feito antes de desconectar da rede Wi-Fi conhecida.

• (10) Recuperação de dispositivos que não inicializam

  Antes de mais nada: NÃO CONECTE O DISPOSITIVO À TOMADA DE ENERGIA ELÉTRICA! Isso seria fatal. Todo o processo de atualização do firmware é alimentado exclusivamente por 3,3 V fornecidos pelo adaptador serial. Não faça nada disso sem antes ler este guia de primeiros passos.

  Com o Tasmota 11, você pode acabar em um estado de não inicialização simplesmente reiniciando o dispositivo pressionando o botão por 40 segundos. Isso não danifica o dispositivo permanentemente e pode ser corrigido com uma nova reinstalação do firmware através de um adaptador serial.

  O processo básico é descrito no guia acima. O layout da placa de circuito impresso do Gosund SP 111 pode ser visto aqui.

  Para que isso funcione, você precisa conectar o GPIO0 (segundo pino no canto inferior esquerdo da imagem acima) ao GND antes de ligar o dispositivo (ou seja, antes de conectar o USB). Os LEDs do dispositivo (vermelho e azul) são um indicador útil de se você está no modo de inicialização correto: o LED vermelho deve estar aceso e não piscando rapidamente, e os LEDs azul e vermelho não devem estar acesos simultaneamente. Uma vez nesse estado, a conexão pode ser removida (por exemplo, bastando encostar um fio jumper no pino) e o dispositivo permanecerá no modo correto até que seja reiniciado.

  Novamente: NÃO CONECTE O APARELHO À TOMADA DE ENERGIA ELÉTRICA, pois isso pode ser fatal.

(B) Vida de operação do hardware

Os critérios da categoria (B) garantem que o software tenha requisitos de desempenho suficientemente baixos para ser executado em hardware mais antigo e menos potente, com pelo menos cinco anos de idade.

Muitos aplicativos FOSS rodam em hardware com mais de 5 anos. Aliás, membros da comunidade KDE observaram que o ambiente de desktop do KDE, o "Plasma", roda em hardware de 2005!

Esta categoria é relativamente fácil de cumprir para a aplicação Blue Angel. A conformidade implica uma declaração de retrocompatibilidade, incluindo detalhes sobre o hardware em que o software é executado e a pilha de software necessária. Para demonstrar a conformidade, documente as seguintes informações em dois documentos denominados “Anexo 1” e “Anexo 2”:

• Ano do Sistema de Referência — por exemplo, 2015
• Modelo — por exemplo, Fujitsu Esprimo 920
• Processador — por exemplo, Intel Core i5-4570
• Núcleos — por exemplo, 4
• Velocidade de clock — por exemplo, 3,6 GHz
• RAM — por exemplo, 4 GB
• Disco rígido (SSD/HDD) — por exemplo, 500 GB
• Placa gráfica — por exemplo, Intel Ivybridge Desktop
• Rede — por exemplo, Realtek Ethernet
• Cache — por exemplo, 6144 KB
• Placa-mãe — por exemplo, Fujitsu D3171-A1
• Sistema operacional — por exemplo, Ubuntu 18.04

Mais uma vez, exemplos de uso do Okular podem ser encontrados nos seguintes links:

• Anexo 1
• Anexo 2

(C) Autonomia do usuário

Conforme discutido na PARTE II, os critérios de autonomia do usuário do programa Blue Angel abrangem oito áreas gerais:

1. Formatos de dados
2. Transparência
3. Comunidade do suporte
4. Desinstalabilidade
5. Capacidade offline
6. Modularidade
7. Liberdade de publicidade
8. Documentação

Muitos projetos de software livre e de código aberto (FOSS) podem presumir que o Software Livre respeita a autonomia do usuário e, em alguns casos, informações da lista acima estão ausentes de sites, manuais, wikis etc. Isso pode incluir documentação sobre suporte a padrões abertos, desinstalação, continuidade do suporte e assim por diante.

Documentar essas informações é importante, tanto para atender aos critérios do prêmio Blue Angel quanto para fornecer aos usuários informações sobre o uso sustentável a longo prazo de seus softwares e hardwares.

Esta não é uma apresentação exaustiva de cada uma das categorias dos critérios do Blue Angel. Em vez disso, este guia se concentra em aspectos dos critérios que os projetos KDE/FOSS podem facilmente documentar e fornecer (o que já representa a maior parte do trabalho). Para os critérios completos, consulte a Seção 3.1.3 dos critérios básicos de premiação.

2.1 Formatos de dados

As principais informações a serem incluídas na documentação:

• Quais formatos de dados (abertos) são suportados—com links para especificações, por exemplo, PDF?
• Também seria interessante saber: Existem exemplos de outros softwares que processam esses formatos de dados?

Para um exemplo da documentação online dos formatos de dados suportados pelo Okular, visite o site do Okular.

Um exemplo de documentação para o Blue Angel pode ser encontrado no Anexo 4.

2.2 Transparência do Produto de Software

Na ausência dessas informações, forneça links para a documentação da API, o código-fonte e a licença do software. Por exemplo, para o KMail:

• Documentação da API do KDE PIM
• Código fonte
• Licença

Um exemplo de documentação para o Blue Angel pode ser encontrado em Anexo 5.

2.3 Comunidade do suporte

Os detalhes sobre a documentação da continuidade do suporte incluem:

• Informações sobre o período de suporte do software (com links para anúncios de lançamento).
• Cronograma e detalhes de lançamento (por exemplo, quem mantém o software).
• Declaração de que as atualizações são gratuitas.
• Declaração sobre como a licença de software livre e de código aberto permite suporte contínuo por tempo indeterminado.
• Informações sobre se e como as atualizações funcionais e de segurança podem ser instaladas separadamente.

Um exemplo da documentação de suporte contínuo da Okular para o Blue Angel pode ser encontrado na Seção 3.1.3.3 do Anexo 6.

2.4 Desinstalabilidade

Como os usuários podem desinstalar completamente o software? Detalhes relevantes podem incluir:

• As instruções de desinstalação que dependem de como o software foi instalado (código-fonte ou binário).
• Exemplos de instruções de desinstalação (código-fonte ou gerenciadores de pacotes, com links relevantes para a documentação).
• Informações sobre se os dados gerados pelo usuário também são removidos ao desinstalar um programa.

Um exemplo da documentação de desinstalação do Okular para o Blue Angel pode ser encontrado na Seção 3.1.3.4 do Anexo 6.

2.5 Capacidade offline

O software requer conexões externas, como um servidor de licenças, para funcionar? Caso contrário, e se não for necessária conexão de rede, já que o software pode ser usado offline, isso deve ser documentado.

Um exemplo da documentação da capacidade offline do Okular para o Blue Angel pode ser encontrado na Seção 3.1.3.5 do Anexo 6.

2.6 Modularidade

As informações a serem documentadas incluem:

• Quais aspectos do software são modulares e podem ser desativados durante a instalação?
• Os manuais ou traduções do software podem ser instalados separadamente?
• Há algum módulo não relacionado à funcionalidade principal incluído na instalação, como módulos de rastreamento ou integração com a nuvem? Caso contrário, documente isso!

Um exemplo da documentação de modularidade do Okular para o Blue Angel pode ser encontrado na Seção 3.1.3.6 do Anexo 6.

2.7 Liberdade de publicidade

Caso o software não exiba publicidade, deixe isso explícito nos manuais e wikis e declare na documentação de aplicação para o Blue Angel.

2.8 Documentação

Isso inclui o seguinte:

• Qual é o processo geral para instalar/desinstalar o software? Isso pode incluir instruções genéricas ou tutoriais para um ambiente de desktop ou gerenciador de pacotes específico.
• Processo de importação/exportação de dados?
• O que os usuários podem fazer para reduzir o uso de recursos (por exemplo, opções de configuração para melhorar o desempenho)?
• O software possui alguma funcionalidade que consuma muitos recursos e que não seja necessária para a funcionalidade principal? Se não, ótimo. Vamos informar os usuários!
• Quais são os termos de licenciamento relacionados ao desenvolvimento futuro dos produtos de software, com links para o código-fonte e a licença?
• Quem apoia o desenvolvimento do software?
• O software coleta dados pessoais? Está em conformidade com as leis de proteção de dados vigentes? Em caso afirmativo, documente!
• Qual é a política de privacidade? Há telemetria? Se sim, como o software lida com a segurança, coleta e transmissão de dados? Além disso, há anúncios ou rastreamento incorporados ao software? Se não, excelente — agora não se esqueça de compartilhar!

Um exemplo da documentação do produto Okular para certificação Blue Angel pode ser encontrado na Seção 3.1.3.8 do Anexo 6.

Submeter para a RAL

Para exemplos de toda a documentação acima, consulte o repositório de Aplicações Blue Angel do KDE.

Depois de ter toda a documentação preparada, você precisa enviá-la para análise à RAL gGmbH (como você deve se lembrar, a RAL é o órgão autorizado que avalia a conformidade com os critérios de premiação). O portal para envio de candidaturas ao Blue Angel pode ser encontrado aqui (https://portal.ral-umwelt.de/).

Se precisar de ajuda com a interface online, a RAL fornece documentação.

Exemplos de documentos para submissão

Abaixo estão exemplos de documentação do Blue Angel para o Okular.

• Anexo 1: Formulário
• Anexo 2: Planilha
• Anexo 3: Relatório OSCAR para Modo Ocioso
• Anexo 3: Relatório OSCAR para SUS
• Anexo 4: Formatos de Dados
• Anexo 5: Padrões abertos
• Anexo 6: Informações do Produto
• Anexo 7: Formato de dados para transmitir informações sobre o produto referentes à eficiência de recursos e energia

Iniciativas Notáveis ​​de Software Sustentável

Existem muitas iniciativas trabalhando em ferramentas para medir o consumo de energia de software. Gostaríamos de mencionar cinco em particular que têm colaborado com a iniciativa KDE Eco:

• O grupo de trabalho de Engenharia de Software Verde no Campus Ambiental de Birkenfeld (em alemão: Umwelt Campus Birkenfeld)

  Desde 2008, o grupo de trabalho de Engenharia de Software Verde tem se dedicado a projetos de pesquisa com foco em software sustentável. Suas pesquisas fornecem a base para o trabalho aqui apresentado, e sua equipe desenvolveu ferramentas como o OSCAR e realizou avaliações em diversos aplicativos do KDE, incluindo o Okular.

• Öko-Institut e.V.

  O Öko-Institut é uma das principais organizações independentes de pesquisa e consultoria da Europa, trabalhando por um futuro sustentável. O grupo de pesquisa Produtos Sustentáveis ​​e Fluxos de Materiais está trabalhando em diversas metodologias de medição. Nesta postagem de blog (em alemão), pesquisadores apresentam uma técnica de automedição usando um script simples em Python.

• Green Coding Berlin

  A Green Coding Berlin concentra-se na pesquisa sobre o consumo de energia de software e sua infraestrutura, na criação de ferramentas de medição de código aberto e na construção de uma comunidade e ecossistema em torno de software verde.

• O projeto SoftAWERE da Sustainable Digital Infrastructure Alliance

  O grupo diretivo do SoftAWERE supervisiona e define a direção para o desenvolvimento de ferramentas e rótulos para aplicativos de software com eficiência energética.

• Green Web Foundation

  A Green Web Foundation acompanha e acelera a transição para uma internet livre de combustíveis fósseis.

Sobre

Autores

As ferramentas e a documentação do KDE Eco são fornecidas por membros da comunidade que se voluntariaram para contribuir com este projeto em benefício de todos. Os principais colaboradores incluem (listados em ordem alfabética pelo primeiro nome): Arne Tarara, Cornelius Schumacher, Emmanuel Charruau, Karanjot Singh, Nicolas Fella e Volker Krause. Obrigado — suas contribuições tornam este manual possível.

O texto desta versão do manual foi escrito e/ou compilado a partir da documentação acima por Joseph P. De Veaugh-Geiss. Olea Morris editou o texto. Lana Lutz e Arwin Neil Baichoo contribuíram com o design do livro e do site, bem como com as imagens nele contidas. Paul Brown fez melhorias significativas na postagem do blog Okular, adaptada para “Okular, o primeiro programa de computador com certificação ecológica”, na Parte II. A Wikipédia foi uma fonte para diversos textos que foram incluídos aqui em forma modificada. Agradecemos à comunidade de escritores e editores da Wikipédia por criar um recurso tão valioso para todos nós. Consulte o final de cada seção para obter informações adicionais sobre as fontes.

Reconhecimento

Agradecemos aos muitos colaboradores da iniciativa KDE Eco em geral (listados em ordem alfabética pelo primeiro nome): Achim Guldner, Adriaan de Groot, Aleix Pol, Alexander Semke, André Pönitz, Björn Balazs, Carl Schwan, Chris Adams, Christopher Stumpf, David Hurka, Fabian, Felix Behrens, Franziska Mai, Harald Sitter, Jens Gröger, Johnny Jazeix, Jonathan Esk-Riddell, Kira Obergöker, Lydia Pintscher, Marina Köhn, Mathias Bornschein, Max Schulze, Phu Nguyen, Sami Shalayel, Stefan Naumann, Sven Köhler e Tobias Fella. Suas contribuições são muito apreciadas.

Pessoas interessadas em contribuir para o KDE Eco são encorajadas a se inscrever na lista de discussão ou na sala Matrix. Colaboradores também são convidados a participar de um dos sprints do KDE Eco e de encontros presenciais ou online. Saiba mais em nosso site.

A iniciativa KDE Eco se beneficiou de muitas discussões informativas que ocorreram nas seguintes conferências e workshops: Akademy 2022, Linux App Summit 2022, FOSDEM 2023, rC3: NOWHERE 2021, SFSCon 2021/2022, Grazer Linuxtage 2022, Qt World Summit 2022, QtDevCon 2022, Fedora Nest 2022, Green Coding Berlin meetups, Sustainable Digital Infrastructure Alliance hackathon, EnviroInfo 2022 e Bits & Bäume 2022. Obrigado!

Licença

Salvo indicação em contrário, todo o conteúdo é publicado sob a licença Creative Commons de Atribuição Compartilhada 4.0 Internacional (CC-BY-SA-4.0). Para mais informações sobre licenciamento de documentação no KDE, consulte a política de licenciamento do KDE.

Nota de financiamento

O projeto Blauer Engel Für FOSS foi financiado pela Agência Federal Alemã do Meio Ambiente (UBA) e pelo Ministério Federal do Meio Ambiente, Conservação da Natureza, Segurança Nuclear e Proteção do Consumidor (BMUV). Os fundos são disponibilizados por resolução do Bundestag alemão.

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