Przejdź to treści

KDE Eco 2021 Sprint: Szczegóły dotyczące planowania społecznościowego dla projektu ekologicznego KDE

Poniedziałek, 7 Luty 2022 | Joseph P. De Veaugh-Geiss


Jest to kontynuacja ogłoszenia [KDE Eco Sprint] opublikowanego na stronie The Dot](https://dot.kde.org/2021/12/24/2021-kde-eco-sprint).

11 grudnia 2021 roku w KDE Eco odbył się pierwszy z wielu zaplanowanych biegów, w którym wzięło udział 7 osób. Bieg miał być początkowo wydarzeniem na żywo, mającym na celu utworzenie laboratorium pomiarowego społeczności, ale Korona miała inne pomysły. Mimo to społeczność wykazała się jak zwykle pomysłowością i zamiast tego spotkaliśmy się online.

KDE Eco 2021 Sprint na kanale aktualności KDE

Ogłoszenie KDE Eco 2021 Sprint na kanale aktualności KDE

W tym długim wpisie przedstawię szczegółowy przegląd głównych zagadnień omawianych podczas Biegu i ich rezultatów; zob. też raport, aby dowiedzieć się więcej.

Wiedziałeś(aś) o tym?

Dyskusje podobne do tej odbywają się co miesiąc na spotkaniach naszej społeczności co drugą środę miesiąca w godzinach 19-20 CET/CEST (czasu berlińskiego).

Przyłącz się! Spotkajmy się tam.

Zakładanie zespołu KDE Eco

KDE Eco składa się obecnie z trzech powiązanych projektów: (i) Free and open source Energy Efficiency Project (FEEP), (ii) Blauer Engel dla FOSS (BE4FOSS), oraz (iii) Blauer Engel Applications. Każdy projekt ma swój szczególny cel: FEEP zajmuje się pomiarem zużycia energii przez wolne oprogramowanie, BE4FOSS skupia się na organizowaniu społeczności i rozpowszechnianiu informacji o eko znaku Blauer Engel, a repozytorium aplikacji Blauer Engel przechowuje wszystkie dokumenty związane z certyfikacją eko znaku KDE/wolnego oprogramowanie. Do czasu biegu te trzy repozytoria dla projektów znajdowały się w różnych osobistych przestrzeniach nazw. Teraz wszystkie trzy repozytoria można znaleźć pod adresem https://invent.kde.org/teams/eco.

Umieszczenie projektów w jednym zespole w sposób bardziej przejrzysty łączy te i ewentualne przyszłe projekty. Co więcej, nieosobista przestrzeń nazw jest bardziej odpowiednia dla projektów społecznościowych. Zapraszamy do zapoznania się z działaniami każdego projektu na powyższej stronie zespołu!

Zespoły KDE Eco

Zespoły > KDE Eco

Uzupełnianie aplikacji Blauer Engel dla Okulara

Istnieją trzy aplikacje KDE, których zużycie energii zostało już zmierzone: Okular, KMail, oraz Krita. Spośród tych trzech aplikacji, aplikacje Blauer Engel dla Okulara i KMaila są w przygotowaniu od jakiegoś czasu, a jednym z celów było ukończenie aplikacji dla Okulara. Mamy zaszczyt ogłosić, że po zakończeniu biegu, aplikacja Okular została złożona i jest obecnie sprawdzana pod kątem certyfikacji. Oczekujemy na informację zwrotną od [RAL gGmbH] (https://www.ral-umwelt.de/en/ral-environment/), instytucji przyznającej nagrody dla Blauer Engel, w ciągu 2-3 miesięcy. Wkrótce zostanie złożony wniosek dla KMail.

Podczas grupowego przeglądu aplikacji Okular uczestnicy poruszyli wiele interesujących kwestii. Jedna z nich pojawiła się na przykład podczas dyskusji na temat kryteriów przejrzystości Blauer Engel ([Sekcja 3.1.3.2] (https://produktinfo.blauer-engel.de/uploads/criteriafile/en/DE-UZ%20215-202001-en-Criteria-2020-02-13.pdf)). Malte Reißig z IASS Grupa badawcza “[Cyfryzacja i zrównoważona transformacja] (https://www.iass-potsdam.de/en/research-group/digitalisation-sustainability)" podkreśliła, że otwarty rozwój może pozytywnie wpłynąć na niektóre z pozostałych kryteriów przyznawania nagród (zobacz [tę dyskusję] (https://invent.kde.org/teams/eco/blue-angel-application/-/issues/57)), takie jak możliwość długoterminowego utrzymania i autonomia użytkownika oprogramowania. Oznacza to, że użytkownicy wolnego oprogramowania nie tylko biernie korzystają z oprogramowania, ale są zachęcani i mają możliwość wyrażania życzeń na temat przyszłego rozwoju aplikacji, a także mogą aktywnie uczestniczyć w planowaniu kamieni milowych. Co więcej, przy otwartym rozwoju, wiadomości zatwierdzające mogą być powiązane z konkretnymi problemami lub błędami zgłaszanymi przez społeczność użytkowników i programistów. W przypadku wolnego oprogramowania aplikacja nie jest tylko produktem końcowym, ale ale otwartym procesem odzwierciedlającym potrzeby i życzenia użytkowników orazich społeczności. W przypadku FOSS, społeczność wyznacza kierunek rozwoju!

Ikona Okulara

Ikona Okulara

Kolejna kwestia dotyczyła dystrybucji wolnego oprogramowania i tego, jakie stanowi ono wyzwanie dla spełnienia kryteriów Blauer Engel. Gdyż Wolne oprogramowanie zazwyczaj rozprowadza oprogramowanie w sposób zdecentralizowany, dla każdej aplikacji istnieje wiele kanałów wydawniczych i dystrybucyjnych. Weźmy pod uwagę program Okular, który jest pakowany nie tylko do Flatpaka, ale także do Microsoft Store, nie wspominając o licznych dystrybucjach GNU/Linux (np. [OpenSuse] (https://software.opensuse.org/package/okular), Debian). Różnice w infrastrukturze pakowania mogą mieć wpływ na spełnienie wymagań Blauer Engel, takich jak możliwość odinstalowania, modułowość itp.

Firmy wydające oprogramowanie własnościowe, które zazwyczaj wdrażają swoje produkty w sposób scentralizowany, nie będą miały takich problemów. W związku z tym jedną z możliwości, nad którą dyskutowała grupa, jest certyfikowanie tylko kodu źródłowego programu, co pozwala zachować neutralność wobec różnic w sposobie pakowania i dystrybucji oprogramowania. Inną możliwością jest certyfikowanie wydań specyficznych dla danej dystrybucji, takich jak te dla Microsoft Store. To ostatnie mogłoby być wykorzystane w celach marketingowych, by dotrzeć do nowych użytkowników i przyciągnąć ich do społeczności KDE - patrz np. [ta dyskusja] (https://invent.kde.org/teams/eco/blue-angel-application/-/issues/56).

Chętnie dowiemy się, co o tym sądzisz. Dołącz do dyskusji na naszej liście mailingowej lub pokoju Matrix albo poprzez [zgłaszanie problemów](https://invent.kde.org/groups/teams eco/-/issues) w naszych repozytoriach GitLab!

Standardowe scenariusze użytkowania

Standardowy scenariusz użytkowania (SSU) odzwierciedla typowe funkcje aplikacji, z uwzględnieniem częstotliwości ich wykonywania. Scenariusze standardowego użytkowania mają kluczowe znaczenie dla pomiaru zużycia energii przez oprogramowanie.

Podczas przeglądania dzienników działań SSU dla Okulara w aplikacji Blauer Engel zwrócono uwagę na dwie ważne kwestie, które usprawnią wdrażanie SSU podczas pomiarów w laboratorium. Jedną z nich było spostrzeżenie o potrzebie dokumentowania nie tylko działań, ale także obiektów działań (np. podczas korzystania z czytnika pdf, który plik pdf jest otwierany), ponieważ może to mieć wpływ na zużycie energii. Drugim spostrzeżeniem było to, że uwzględnienie bezczynności jest ważne przy definiowaniu SSU: bezczynność jest zarówno realistyczna, jak i może pokazać, że nic się nie dzieje, gdy nie powinno się nic dziać.

Przy wirtualnym stole poruszono kilka innych kwestii. Nicolas Fella, inżynier oprogramowania z KDAB Berlin, wyraził zainteresowanie porównaniem dwóch klientów czatu, co przeniosło rozmowę na zdefiniowanie pojedynczych scenariuszy przy porównywaniu dwóch aplikacji o podobnym zastosowaniu. Pojedynczy SSU ograniczy, które funkcje oprogramowania mogą być testowane, ale dzięki temu wyniki pomiarów będą bezpośrednio porównywalne. Co więcej, w przypadku oprogramowania typu klient-serwer, takiego jak klient czatu czy poczty elektronicznej, pojawia się kwestia komponentu sieciowego, co w przypadku kontrolowanych testów wymagałoby ustawienia i zmierzenia zużycia energii przez serwer. Były przewodniczący KDE i wieloletni współpracownik KDE Cornelius Schumacher zwrócił uwagę, że w [pomiarach KMail] (https://invent.kde.org/teams/eco/blue-angel-application/-/tree/master/applications/kmail) mierzono tylko pracę obliczeniową na komputerze lokalnym. Pomiar obliczeń nielokalnych w oprogramowaniu typu klient-serwer jest w dzisiejszym świecie ważniejszy niż kiedykolwiek wcześniej i jest on obecnie planowany w ramach zrewidowanych kryteriów przyznawania nagrody Blauer Engel dla oprogramowania.

Ekran powitalny KMail

Ekran powitalny KMail

Innym omawianym tematem było abstrakcyjne zdefiniowanie działań SSU w celu zautomatyzowania implementacji scenariuszy użytkowania za pomocą różnych narzędzi (Actiona, xdotool, KXmlGui itp.). Ważną kwestią było to, że różne narzędzia do emulacji robią różne rzeczy, co może stanowić wyzwanie dla automatyzacji procesu. Na przykład, gdy do emulacji używa się KXmlGui, nie można wpisywać tekstu, a zatem może być potrzebne coś takiego jak xdotool. Inna propozycja dotyczyła struktury SSU w taki sposób, aby tworzenie dziennika działań również mogło być zautomatyzowane. Czy ktoś ze społeczności chciałby pomóc w rozwiązaniu tych problemów?

Ponadto grupa dyskutowała o tym, w jaki sposób scenariusze użytkowania mogą być wykorzystane do testowania szybkości reakcji i ogólnej wydajności na starszym sprzęcie lub sprzęcie niskiej klasy. Jakie są [wasze pomysły] (https://invent.kde.org/teams/eco/be4foss/-/issues/31)?

Czy wiesz, że planujemy zorganizować maraton pomiarów, aby zmierzyć zużycie energii zużycia energii przez aplikacje FOSS/KDE na początku 2022 roku? Dla jakich aplikacji chcesz zobaczyć przygotowane Standardowe scenariusze użytkowania? Podziel się swoimi pomysłami z nami [tutaj] (https://invent.kde.org/teams/eco/be4foss/-/issues/28) lub prześlij swój SSU do naszego [repozytorium GitLaba] (https://invent.kde.org/teams/eco/be4foss/-/tree/master/standard-usage-scenarios)!

Powtarzalny układ odniesienia

Scenariusze standardowego użytkowania są uruchamiane w systemie referencyjnym, pojawił się istotny problem: jak stworzyć powtarzalny system referencyjny? Należy wziąć pod uwagę kilka warstw systemu: Sprzęt (procesor, dysk, pamięć RAM itp.); system operacyjny i usługi systemu operacyjnego, takie jak menedżer aktywności w systemie Plasma, a także ich konfiguracje; konfiguracja testowanej aplikacji oraz wszystkich powiązanych (np. Akonadi dla aplikacji PIM). Z jednej strony konieczne jest posiadanie kontrolowanego środowiska, aby móc interpretować wyniki, z drugiej strony pożądane jest posiadanie pomiarów odzwierciedlających rzeczywiste, być może nawet hałaśliwe środowiska obliczeniowe w celu zrozumienia rzeczywistego zużycia energii przez oprogramowanie. Ostatecznie to, czy chcemy mieć kontrolowane czy naturalne środowiska komputerowe, będzie zależeć od tego, do czego dane mają być wykorzystane, a to będzie różne dla: naukowców, programistów, audytorów eko znaków, firm itd.

Na przykład programiści zainteresowani przeprowadzeniem testów jednostkowych efektywności energetycznej lub uzyskaniem znaku Blauer Engel będą musieli posiadać jasno określone środowiska. Jakie są zatem wygodne i szybkie sposoby na doprowadzenie systemu do znanego stanu? Omówiono trzy pomysły: (i) wykonywanie migawek systemu plików (np,Snapper), (ii) wyczyszczenie pamięci podręcznej systemu oraz (iii) zastąpienie plików konfiguracyjnych. Jeśli masz inne pomysły, daj nam o nich znać [tutaj] (https://invent.kde.org/teams/eco/feep/-/issues/3)!.

Dla środowisk rzeczywistych jedną z propozycji, potencjalnie kontrowersyjną, jest rejestrowanie wydajności sprzętu i zużycia energii elektrycznej w czasie, gdy ludzie używają swoich komputerów osobistych. Są chętni?

Dane wyjściowe

Podczas pomiaru zużycia energii w laboratorium, w szczególności na potrzeby certyfikacji ekologicznej Blauer Engel, mogą być generowane trzy rodzaje plików danych: (i) plik dziennika działań (patrz wyżej odnośnie automatyzacji takich plików dziennika), (ii) dane dotyczące wydajności sprzętu (CPU, RAM itp.) oraz (iii) zużycie energii elektrycznej. Ponieważ w niektórych przypadkach dane wyjściowe będą musiały być samodzielnie zdefiniowane (np. rejestratory znaczników czasu w skryptach xdotool), przed przystąpieniem do pomiarów w laboratorium należy zastanowić się, jak te dane powinny wyglądać.

Poruszono kilka kwestii związanych z danymi: Czy dane wyjściowe powinny być standaryzowane, aby zharmonizować dane wyjściowe z różnych kampanii pomiarowych, czy też czy wystarczy po prostu opublikować zebrane dane w dostępnym formacie (np. na przykład jako pliki .csv, takie jak w repozytorium [FEEP repozytorium] (https://invent.kde.org/teams/eco/feep/-/tree/master/measurements))? Jaka dokładność znaczników czasu jest wymagana (np. sekundy czy ułamki sekund)? Pytania te pozostają na razie otwarte, ale grupa zdecydowała, że potrzebujemy przeglądu urządzeń/skryptów zgodnych z FOSS-em(np. skrypt Achima Guldnera Achima Guldnera dla Gude Expert Power Control serii 1202) i zestawów narzędzi (np. narzędzi do analizy statystycznej takich jak: OSCAR, R, Julia, Octave, PSPP, NumPy) używanych do pomiarów i analizy, która jest obecnie [w toku] (https://invent.kde.org/teams/eco/be4foss/-/blob/master/devices- tools-overview.md).

Urządzenia do pomiaru mocy

Kryteria Blauer Engel odnoszą się w szczególności do dwóch mierników mocy (PM): Janitza UMG 604 i Gude Expert Power Control 1202. Urządzenia te nie są tanie. W 2020 roku długoletni współpracownik KDE Volker Krause zhakował wtyczkę zasilającą za 8 euro i [napisał o tym] (https://volkerkrause.eu/2020/10/17/kde-cheap-power-measurement-tools.html). Jak opisano we wpisie na blogu, te niedrogie wtyczki są w stanie uzyskać częstotliwość próbkowania do 200ms. W ten sposób powstał pomysł wykorzystania niedrogich mierników mocy w niskobudżetowych laboratoriach domowych. W tym celu warto porównać wyniki z profesjonalnych mierników mocy z tymi budżetowymi, aby zobaczyć, jak wypadają w porównaniu. Czy ktoś ze społeczności byłby zainteresowany wykonaniem takiego pomiaru?

Przykładowy pomiar

Z [wpisu bloga] Volkera Krause (https://volkerkrause.eu/2020/10/17/kde-cheap-power-measurement-tools.html): “Przykładowy pomiar (interwał próbkowania 200 ms, bez filtra): kursor myszy przesuwany między próbkami 100 i 150, ze szczytem podczas najechania na wpis na pasku zadań”.

Inny sposób mierzenia zużycia energii pochodzi od współpracownika KDE, David Hurka, który ma [propozycję czujników zasilania USB SPI] (https://invent.kde.org/davidhurka/usb-spi-power-sensors), aby zapewnić alternatywę o wyższej rozdzielczości dla mierników energii mierzących w gniazdku ściennym.

Otwarte zagadnienia dla laboratoriów pomiarowych

Omówiono też kilka innych kwestii związanych ze zużyciem energii i pomiarami laboratoryjnymi. Choć nie we wszystkich przypadkach podjęto ostateczne decyzje, wiele z tych otwartych kwestii będzie ważnych do rozważenia w przyszłości.

  • Pomysł na przyjazne marketingowo narzędzie do zwracania uwagi na zużycie energii zużycia energii przez oprogramowanie.

    • Na przykład przycisk “Eko” do pomiaru efektywności energetycznej lub śladu węglowego (por. ślad węglowy podróży w aplikacji Itinerary).
    • Zauważ, że podobna funkcjonalność jest już zapewniona przez [PowerTop] (https://github.com/fenrus75/powertop), choć pozostają otwarte kwestie (kiedy można bezpiecznie włączyć tę funkcję, aby uniknąć utraty danych, zamrożeń maszyny?).
  • Kiedy wady przeważają nad korzyściami wynikającymi z obsługi starszego sprzętu?

    • Zaprośmy naukowców, którzy nad tym pracują, do dyskusji ze społecznością KDE Eco.
  • Przyszła współpraca:

Wniosek

Bieg online był wspaniałą okazją do zjednoczenia społeczności i popchnięcia projektu KDE Eco naprzód, zwłaszcza że przygotowujemy się do Społecznościowego laboratorium pomiarowego, które odbędzie się w KDAB w Berlinie, oraz do pierwszego z wielu pomiaro-tonów (planowanych na początek 2022 roku)! Sukces takich wydarzeń zależy przede wszystkim od społeczności, więc pozwólcie nam przesłać serdeczne podziękowania dla wszystkich, którzy przyłączyli się do rozmowy. Z niecierpliwością czekamy na rozwój społeczności w 2022 roku! Co więcej, nie moglibyśmy robić tego, co robimy bez wsparcia KDE e.V., jak również BMU/[UBA] (https://www.umweltbundesamt.de/en), którzy finansowo wspierają finansowo projekt BE4FOSS (chociaż tylko wydawca jest odpowiedzialny za za treść tej publikacji).

Zawiadomienie o finansowaniu

Projekt BE4FOSS został sfinansowany przez Federalną Agencję Ochrony Środowiska oraz Federalne Ministerstwo Środowiska, Ochrony Przyrody, Bezpieczeństwa Nuklearnego i Ochrony Konsumentów. (BMUV1). Środki te zostały udostępnione na mocy uchwały niemieckiego Bundestagu.

BMUV logo UBA logo

Za treść tej publikacji odpowiada wydawca.

1 Oficjalne loga BMUV i UBA są wysyłane tylko na żądanie pod adresem: verbaendefoerderung@uba.de


Artykuł stworzony przez na licencji CC-BY-4.0.