Sezon na KDE 2022 z KDE Eco

Jestem bardzo wdzięczny zespołowi KDE za zaproszenie mnie do bycia częścią tej niesamowitej społeczności poprzez ich coroczny program Sezon KDE.

O mnie

Nazywam się Karanjot Singh. Jestem absolwentem pierwszego roku informatyki w Jaypee Instytut technologii informacyjnych, Noida, Indie. Pracowałem jako programista w różnych programach wolnego i otwartego oprogramowania (FOSS), takich jak Kharagpur Winter of Code in 2021 (KWoC'21). Będzie to jednak mój pierwszy raz, gdy będę uczestniczył w projekcie z tak dużąspołecznością. Jestem wielkim pasjonatem FOSS, rozwiązywania problemów i poprawy wydajności procesów. Lubię odkrywać i uczyć się nowych technologii oraz tworzyć rzeczy do celów społecznie użytecznych. Wierzę również, że wkład w FOSS jest najlepszym sposobem na zdobycie doświadczenia w tworzeniu oprogramowania.

Nad czym będę pracować

Jako część pionierskiego projektu zrównoważonego rozwoju, [KDE Eco] (https://eco.kde.org/) ma na celu mierzenie i zmniejszanie zużycia energii przez KDE/Wolne Oprogramowanie. Wymaga to naśladowania zachowań użytkowników, co można osiągnąć przez planowanie i tworzenie scenariuszy standardowego użytkowania. Będę tworzył skrypt standardowych scenariuszy użytkowania dla różnych aplikacji, ze szczególnym uwzględnieniem powszechnie używanych edytorów tekstu, takich jak [Kate] (https://apps.kde.org/kate/), KWrite, [Vim] (https://www.vim.org/), Nano, [Emacs] (https://www.gnu.org/software/emacs/), [Calligra Words] (https://apps.kde.org/calligrawords/) i [LibreOffice] (https://www.libreoffice.org/). Przygotuję te scenariusze użycia za pomocą jednego z wielu dostępnych [narzędzi do emulacji] (https://invent.kde.org/teams/eco/feep/-/blob/master/tools/presentation_ Visual_Workflow_Automation_Tools Visual_Workflow_Automation_Tools.pdf). Poniżej znajduje się moja Oś czasu SoK'22:

Motywacja do pracy nad projektem KDE Eco

Myślę, że KDE Eco jest bardzo dobrą inicjatywą dla rozwoju Wolnego oprogramowania oszczędzającego zasoby i energię. Kiedy ktoś używa FOSS i odkrywa, że oprogramowanie jest przejrzyste w kwestii zużycia energii, oraz że używanie oprogramowania może pomóc przedłużyć żywotność sprzętu i zmniejszyć wpływ cyfryzacji na środowisko, to mnie to ekscytuje. Zawsze chcę być częścią czegoś, co przyczynia się do dobra przyszłych pokoleń i KDE Eco służy temu celowi. Wierzę również, że KDE Eco pomaga mi w mojej podróży, by stać się lepszym programistą.

Czego nauczyłem się do tej pory

Kiedy zaczynałem pracę nad tym projektem, miałem trzy pytania.

Skąd możemy wiedzieć, czy oprogramowanie jest efektywne pod względem wykorzystania zasobów i energii?

Jak możemy zmierzyć zużycie energii przez oprogramowanie?

Czy to coś zmienia?

Te pytania mogą pojawić się w głowie każdego, kto myśli o idei wydajności oprogramowania.

Gdy korzystasz z oprogramowania, widzisz tylko interfejs, z którym z którym wchodzisz w interakcję. Wystarczy powiedzieć telefonowi, czego się chce, a wszystko pojawi się w magiczny sposób - czy to informacje na ekranie,czy też paczka dostarczona do drzwi. Ale o technologiach i infrastrukturze, które za tym stoją, decydują inżynierowie oprogramowania, którzy sprawiają, że to wszystko działa.

Wyobraźmy sobie: Co by się stało, gdybyśmy przeanalizowali zużycie energii przez powszechnie powszechnie używane oprogramowanie i uczynili je bardziej przejrzystym? Co by się stało, gdyby użytkownicy mogli dowiedzieć się, ile energii ile energii zużywa ich oprogramowanie i mogliby wybrać aplikację, która jest lepsza dla środowiska? To byłoby wspaniałe!!!

Inicjatywy KDE Eco Wolnego i otwartego projektu efektywności energetycznej (FEEP) oraz Blauer Engel dla FOSS ([BE4FOSS] (https://invent.kde.org/teams/eco/be4foss)) ciężko pracują nad tymi zagadnieniami.

Jak zauważono w FEEP, projektowanie i wdrażanie oprogramowania ma znaczący wpływ na zużycie energii przez systemy, których jest częścią. Dzięki odpowiednim narzędziom możliwe jest określenie ilościowe i obniżenie zużycia energii. Ta zwiększona wydajność przyczynia się do bardziej zrównoważonego wykorzystania energii jako jednego ze wspólnych zasobów naszej planety.

BE4FOSS wspiera FEEP poprzez zbieranie i rozpowszechnianie informacji związanych z certyfikacji ekologicznej Niebieski Anioł (BE), oficjalnego znaku środowiskowego przyznawanego przez rząd niemiecki. Jak stwierdzono na stronie KDE Eko, uzyskanie etykiety Niebieski Anioł odbywa się w trzech etapach: (1) Pomiar, (2) Analiza, (3) Certyfikacja.

1. POMIAR w specjalnych laboratoriach, np. w KDAB w Berlinie.
2. ANALIZA przy użyciu narzędzi statystycznych, takich jak OSCAR (Open source Software Consumption Analysis in R).
3. CERTYFIKACJA poprzez złożenie raportu o spełnieniu kryteriów Blauer Engel

W SoK'22 będę przygotowywał Standardowe scenariusze użytkowania dla różnych edytorów tekstu, tak aby te scenariusze użycia mogły być wykorzystane w pierwszym kroku do uzyskania certyfikatu ekologicznego BE eko-certyfikatu.

Co już zrobiłem & co będę robił w najbliższych tygodniach

Przez ostatnie trzy tygodnie testowałem różne narzędzia do automatyzacji, w szczególności a w szczególności Actiona, xdotool i GNU Xnee, aby zdecydować, które z nich najlepiej z tych narzędzi będzie najlepsze do implementacji Scenariuszy standardowego użytkowania .

Podczas używania Actiona, napisałem trochę dokumentacji, aby informacje te były przydatne dla każdego, kto chce wnieść swój wkład do KDE Eco.

Podczas wypróbowywania xdotool, natknąłem się na problem z wyciekiem pamięci. Uruchamiając Valgrind na xdotool search, otrzymuję więcej straconej pamięci przydzielonej przez XQueryTree. Prawdopodobnie są też inne miejsca, w których pamięć jest przydzielana i nie jest potem zwalniana. Nie nie przeprowadziłem dokładnego sprawdzenia. Niemniej xdotool daje większą kontrolę nad systemem i nawet przy pewnych problemach jest to narzędzie, które uważam za najbardziej pomocne.

Przetestowałem też program GNU Xnee, który wydał mi się interesujące, ponieważ zapisuje dane wyjściowe i przechowuje je w osobnym pliku. Ponadto udostępnia on odtwarzacz, którego można użyć do automatyzacji zadań z dowolną szybkością.

W końcu zdecydowałem się przygotować wszystkie scenariusze użycia za pomocą xdotool, przynajmniej na początku, ponieważ większość edytorów tekstu wykorzystuje funkcje klawiatury, a nie myszy, co ułatwia dostosowanie skryptu do różnych systemów. Jednak po zakończeniu SoK'22 planuję przygotować scenariusze użycia także z Actiona, aby poznać różnice między tymi narzędziami. W związku z tym toczy się też dyskusja na temat [zmiany przeznaczenia Scenariuszy standardowego użytkowania] (https://invent.kde.org/teams/eco/be4foss/-/issues/31) do testowania reaktywności i wydajności na starszym sprzęcie lub sprzęcie z niższej półki.

W najbliższych tygodniach będę dodatkowo pracował nad usunięciem problemu, który jest znany z Actiona. Problem polega na tym, że Actiona emuluje zachowanie użytkownika poprzez przechowywanie pozycji kliknięć w oparciu o współrzędne pikseli, co może sprawić, że przenoszenie skryptu do innego systemu może stanowić wyzwanie. Na przykład, ten problem pojawił się ostatnio podczas przygotowywania Standardowego scenariusza użytkowania dla [GCompris] (https://apps.kde.org/gcompris/). Wymyśliłem rozwiązanie polegające na zmianie rozmiaru ekranu do minimalnej rozdzielczości i umieszczeniu kodu na początku skryptu Actiona. Za każdym razem, gdy skrypt jest uruchamiany w innym systemie, automatycznie zmienia rozmiar na minimalną rozdzielczość, aby dopasować piksele podczas tworzenia skryptu. Jest to tylko pomysł, który nie został jeszcze przetestowany. Zostawię sobie trochę czasu na tę próbę rozwiązania problemu z pomocą zespołu GCompris

Repozytorium GitLab zawierające Standardowe scenariusze użytkowania w toku (obecnie GCompris używa Actiona) można znaleźć [tutaj] (https://invent.kde.org/teams/eco/be4foss/-/tree/master/standard-usage-scenarios).

Zawiązywanie społeczności ( SoK'22 )

Jestem wdzięczny mojemu opiekunowi Josephowi P. De Veaugh-Geissowi za to, że poświęcił czas, by mi pomóc, zapewniając zasoby i wskazówki podczas realizacji projektu. Uczestniczyłem również w comiesięcznym spotkaniu społeczności KDE Eco w dniu [9 lutego 2022] (https://invent.kde.org/teams/eco/be4foss/-/blob/master/community-meetups/2022-02-09_community-meetup_protocol.md), gdzie prof. dr Stefan Naumann, Achim Guldner i Christopher Stumpf z [Umwelt Campus Birkenfeld] (https://www.umwelt-campus.de/forschung/projekte/green-software- engineering/home) prowadzą [dyskusję](https://invent.kde.org/teams/eco/be4foss/-/blob/master/community- meetups/2022-02-09_community-meetup_umwelt-campus-presentation.pdf) na temat pomiaru zużycia energii przez systemy rozproszone i rozszerzenie na nie kryteriów przyznawania nagrody Blauer Engel. To było interesujące spotkanie, na którym omawialiśmy problemy automatyzacji aplikacji mobilnych oraz testowanie klient-serwer. Joseph zapoznał mnie również z naukowcami z Umwelt Campus którzy mierzyli [zużycie energii] (https://invent.kde.org/teams/eco/feep/-/tree/master/measurements/okular) Okular; Emmanuela Charruau, który pracuje z skryptem GCompris; oraz Nicolasem Fella, który obecnie pracuje z xdotool w ramach swojej pracy magisterskiej na temat zużycia energii przez oprogramowanie.

Dziękujemy za poświęcenie czasu na przeczytanie tej aktualizacji. Jeśli ktoś chce kontynuować temat przedstawionych tu pomysłów dotyczących zalet i wad różnych narzędzi automatyzacji podczas wdrażania Scenariuszy standardowego użytkowania, istnieje [Sprawa GitLab] (https://invent.kde.org/teams/eco/be4foss/-/issues/32) w repozytorium BE4FOSS, gdzie możemy przedyskutować dalsze kwestie.

Jestem także dostępny na Matrix KDE pod adresem drquark:kde.org.

Artykuł stworzony przez Karanjot Singh na licencji CC-BY-SA-4.0.