KDE Eko ile Season of KDE 2022
Yıllık programları Season of KDE aracılığıyla beni bu muhteşem topluluğun bir parçası olmaya davet ettikleri için KDE takımına müteşekkirim.
Hakkımda
Ben Karanjot Singh. Hindistan’ın Noida kentindeki Jaypee Bilgi Teknolojileri Enstitüsü’nde bilgisayar mühendisliği birinci sınıf öğrencisiyim. 2021’deki Kharagpur Winter of Code (KWoC’21) gibi çeşitli Özgür ve Açık Kaynaklı Yazılım (FOSS) programlarında geliştirici olarak çalıştım. Ancak bu kadar geniş bir topluluğa sahip bir projeye ilk kez katkıda bulunacağım. FOSS, sorun çözme ve süreç verimliliğini artırma konusunda iddialıyım. Yeni teknolojileri keşfetmekten, öğrenmekten ve sosyal açıdan faydalı amaçlar için bir şeyler yapmaktan hoşlanıyorum. Ayrıca FOSS’a katkıda bulunmanın yazılım geliştirmede deneyim kazanmanın en iyi yolu olduğuna inanıyorum.
Neler üzerine çalışacağım
Öncü bir sürdürülebilirlik projesinin parçası olarak KDE Eko, KDE/Özgür Yazılım’ların enerji tüketimini ölçmeyi ve azaltmayı amaçlamaktadır. Bu, Standart Kullanım Senaryoları’nın planlanması ve yazılmasıyla elde edilebilecek kullanıcı davranışına öykünülmesini gerektirir. Kate, K Yaz, Vim, Nano, Emacs, Calligra Sözcükler ve LibreOffice gibi yaygın olarak kullanılan metin düzenleyicilerine odaklanarak çeşitli uygulamalar için Standart Kullanım Senaryoları yazıp bu kullanım senaryolarını kullanılabilir birçok öykünme aracından biriyle hazırlayacağım. SoK’22 zaman çizelgem aşağıdadır:
KDE Eko projesinde çalışma motivasyonum
KDE Eko’nun özkaynak ve enerji açısından verimli Özgür Yazılım’lar geliştirmek için çok iyi bir girişim olduğunu düşünüyorum. Birisi FOSS kullandığında ve yazılımın enerji tüketimi konusunda saydam olduğunu, yazılımı kullanmanın donanımın ömrünü uzatmaya ve sayısallaşmanın çevresel etkisini azaltmaya yardımcı olabileceğini keşfettiğinde bu beni heyecanlandırıyor. Her zaman gelecek nesillere katkıda bulunacak bir şeyin parçası olmak isterim ve KDE Eko bu amaca hizmet ediyor. Ayrıca KDE Eko’nun daha iyi bir yazılım geliştirici olma yolculuğumda bana yardımcı olduğuna inanıyorum.
Şimdiye kadar neler öğrendim
Bu projeye başladığımda üç sorum vardı.
Yazılımın kaynak ve enerji açısından verimli olduğunu nasıl bilebiliriz?
Yazılımın enerji tüketimini nasıl ölçebiliriz?
Peki bu bir fark yaratıyor mu?
Yazılım verimliliği fikri üzerine düşünürken bu sorular herkesin aklına gelebilir.
Yazılımı kullandığınızda gördüğünüz şey yalnızca etkileşimde bulunduğunuz arayüzdür. Telefonunuza ne istediğinizi söylemeniz yeterlidir; ister ekrandaki bilgiler, ister kapınıza teslim edilen bir paket olsun, her şey sanki sihirliymiş gibi görünecektir. Ancak arkasındaki teknolojiler ve altyapı, tüm bu işleri yapan yazılım mühendisleri tarafından belirlenir.
Hayal edin: Yaygın olarak kullanılan yazılımların arkasındaki enerji tüketimini çözümleyip daha saydam hale getirsek ne olur? Kullanıcılar, yazılımlarının ne kadar enerji gerektirdiğini öğrenebilse ve çevre için daha iyi olabilecek uygulamayı seçebilselerdi nasıl olurdu?
KDE Eko](https://invent.kde.org/teams/eco), Özgür ve Açık Kaynaklı Enerji Verimliliği (FEEP) ve FOSS için Blauer Engel (BE4FOSS) projesine teşvikte bulunur ve bu konularla ayrıntılı bir biçimde ilgilenir.
FEEP tarafından belirtildiği gibi, yazılımın tasarımı ve uygulanması, parçası olduğu sistemlerin enerji tüketimi üzerinde önemli bir etkiye sahiptir. Doğru araçlarla enerji tüketimini ölçmek ve azaltmak olanaklıdır. Bu artan verimlilik, gezegenimizin ortak kaynaklarından biri olan enerjinin daha sürdürülebilir kullanımına katkıda bulunuyor.
BE4FOSS, Alman hükümeti tarafından verilen resmi çevre etiketi olan Blauer Engel (BE) eko sertifikasıyla ilgili bilgileri toplayıp yayarak FEEP’i desteklemektedir. KDE Eko web sitesinde belirtildiği üzere, Mavi Melek eko etiketini almak 3 adımda gerçekleşir: (1) Ölçüm, (2) Çözümleme ve (3) Sertifikalandırma.
- ÖLÇÜM KDAB Berlin gibi özel laboratuvarlarda
- ÇÖZÜMLEME OSCAR (R’de Açık Kaynak Yazılım Tüketim Analizi) gibi istatistiksel araçları kullanarak
- SERTİFİKALANDIRMA Blauer Engel kriterlerinin yerine getirildiğine ilişkin raporu göndererek
SoK’22’de çeşitli metin düzenleyicileri için Standart Kullanım Senaryoları hazırlayacağım, böylece kullanım senaryoları Adım 1’de BE eko sertifikasını almak için kullanılabilir.
Şimdiye dek yaptım ve önümüzdeki haftalarda neler yapacağım
Geçtiğimiz üç hafta boyunca, bu araçlardan hangisinin Standart Kullanım Senaryoları’nı uygulamak için en iyi olacağına karar vermek üzere Actiona, xdotool ve GNU Xnee başta olmak üzere çeşitli otomasyon araçlarını sınadım.
Actiona kullanırken, bu bilgilerin KDE Eko’ya katkıda bulunmak isteyen herkes için de yararlı olması amacıyla biraz belgelendirme yazdım.
xdotool’u denediğimde bellek sızıntısıyla ilgili bir sorunla karşılaştım. Valgrind’ı xdotool aramasında çalıştırdığımda, XQueryTree tarafından ayrılan daha fazla bellek kaybı elde ediyordum. Büyük olasılıkla belleğin ayrıldığı ve daha sonra serbest bırakılmayan başka yerler de vardır. Kapsamlı bir denetim yapmadım. Yine de xdotool sistem üzerinde daha fazla denetim sağlıyor ve bazı sorunlar çıkarsa bile bile en yararlı bulduğum araç bu.
GNU Xnee’yi de sınadım; çıktıyı kaydedip ayrı bir dosyada sakladığı için bu bana ilginç geldi. Ayrıca görevleri istediğiniz hızda otomatikleştirmek için kullanılabilecek bir yineleyici sağlıyor.
Sonuç olarak, çoğu metin düzenleyicisinin fare etkinliği yerine klavye işlevlerini kullanması nedeniyle, en azından başlangıçta tüm kullanım senaryolarını xdotool ile hazırlamaya karar verdim ve bu, betiğin farklı sistemlere uyarlanmasını kolaylaştıracaktır. Ancak SoK’22’den sonra Actiona ile de kullanım senaryoları hazırlamayı planlıyorum ki bu araçlar arasındaki farkları öğrenebileyim. İlgili bir not olarak, eski veya daha düşük düzey donanımlarda yanıt verme ve başarımı sınamak için Standart Kullanım Senaryoları’nın yeniden kullanılması konusunda da süren bir konuşma var.
Önümüzdeki haftalarda ayrıca Actiona için bilinen bir sorunu çözmeye çalışacağım. Sorun, Actiona’nın tıklamaların konumunu piksel koordinatlarına göre saklayarak kullanıcı davranışına öykünmesidir; bu da bir betiğin başka bir sisteme aktarılmasını zorlaştırabilir. Örneğin, bu sorun yakın zamanda GCompris için Standart Kullanım Senaryosu hazırlarken ortaya çıktı. Ekranı en düşük ekran çözünürlüğüne getirme ve kodu Actiona betiğinin başına ekleyerek çözümü buldum. Betik farklı bir sistemde çalıştırıldığında, betik oluşturulurken piksellerle eşleşecek şekilde kendiliğinden en düşük çözünürlüğe yeniden boyutlandırılır. Bu sadece bir fikir ve henüz sınanmadı. Sorunu GCompris ekibinin yardımıyla çözmek için bu girişime zaman ayıracağım.
Sürmekte olan Standart Kullanım Senaryoları’nı içeren GitLab deposunu (şu anda Actiona kullanan GCompris) burada bulabilirsiniz.
Topluluk Tanışması (SoK’22)
Proje sırasında özkaynaklar ve rehberlik sağlayarak bana yardım etmeye zaman ayırdığı için akıl hocam Joseph P. De Veaugh-Geiss’e müteşekkirim. Ayrıca 9 Şubat 2022’de Umwelt Kampüsü Birkenfeld’den Prof. Dr. Stefan Naumann, Achim Guldner ve Christopher Stumpf’ın dağıtılmış sistemlerin enerji tüketiminin ölçülmesi ve Blauer Engel ödül kriterlerinin genişletilmesi üzerine bir tartışmaya öncülük ettiği KDE Eko aylık topluluk toplantısına da katıldım. İstemci-sunucu testlerinin yanı sıra mobil uygulamalardaki otomasyon sorunlarını da tartıştığımız ilginç bir toplantıydı. Joseph ayrıca beni Okular’ın enerji tüketimini ölçen Umwelt Kampüsü araştırmacıları, GCompris senaryosu üzerinde çalışan Emmanuel Charruau; ve şu anda yazılımın enerji tüketimi üzerine yüksek lisans tezi için xdotool ile çalışan Nicolas Fella ile tanıştırdı.
Bu güncellemeyi okumaya zaman ayırdığınız için teşekkür ederiz. Standart Kullanım Senaryoları’nı uygularken farklı otomasyon araçlarının artıları ve eksileri ile ilgili olarak burada sunulan fikirleri takip etmek isteyen varsa BE4FOSS deposunda daha fazla tartışabileceğimiz bir GitLab başlığı var.
Ayrıca drquark:kde.org kullanıcı adıyla KDE’nin Matrix örneğinde varım.
Yazı, Karanjot Singh tarafından CC-BY-SA-4.0 lisansı altında katkıda bulunuldu.