KDE Eko 2021 Hız Koşusu: KDE’nin Ekolojik Projesi İçin Topluluk Planlamasına İlişkin Ayrıntılar

Pazartesi, 7 Şubat 2022 | Joseph P. De Veaugh–Geiss

Bu, The Dot’ta yayınlanan KDE Eko Hız Koşusu duyurusunun süreği niteliğindedir.

11 Aralık 2021’de KDE Eko, 7 kişinin katılımıyla planlanan birçok hız koşusunun ilkini düzenledi. Hız koşusunun başlangıçta bir topluluk ölçüm laboratuvarı kurmak için yüz yüze bir etkinlik olması amaçlanmıştı; ancak Corona’nın başka fikirleri vardı. Yine de, topluluk her zamanki becerikliliğini kullandı ve bunun yerine çevrimiçi olarak buluştuk.

KDE Haberler’de KDE Eko 2021 Hız Koşusu Duyurusu

Bu uzun gönderide, hız koşusunda konuşulan konuların ayrıntılı bir genel bakışını sağlayacağım; ayrıca daha çok ayrıntı için toplantı [dakikalarına](https://invent.kde.org/teams/eco/be4foss/-/blob/master/community -meetups/2021-12-11_sprint01_protocol.md) da bakabilirsiniz.

Biliyor muydunuz?

Bunlara benzer tartışmalar, her ayın 2. Çarşamba günü 19:00–20:00 CET/CEST (Berlin Saati) saatinde topluluğumuzca gerçekleştirilir.

Bir KDE Eko takımı oluşturma

KDE Eko şu anda birbiriyle ilişkili üç projeden oluşmaktadır: (i) Ücretsiz ve açık kaynaklı Enerji Verimliliği Projesi (FEEP), (ii) FOSS için Blauer Engel (BE4FOSS) ve (iii) Blauer Engel Uygulamaları. Her projenin kendine özel odak noktası vardır: FEEP, Özgür Yazılım’ın enerji tüketimini ölçmekle ilgilenir; BE4FOSS, topluluk organizasyonuna ve Blauer Engel eko etiketi hakkında bilgi yaymaya odaklanır ve Blauer Engel Uygulamaları havuzu, KDE/Özgür Yazılım’ların eko etiket ile sertifikalandırılmasıyla ilgili tüm belgeleri barındırır. Hız koşusuna değin, projeler için üç havuz çeşitli kişisel ad alanlarında barındırılıyordu. Şimdi, üç havuzun tümü https://invent.kde.org/teams/eco adresinde bulunabilir.

Projelerin bir takım altında olması, bunları ve olası gelecekteki projeleri daha açık bir şekilde birbirine bağlar. Ayrıca, kişisel olmayan bir ad alanına sahip olmak, topluluk projeleri için daha uygundur. Yukarıdaki takım alanında her projenin faaliyetlerini kontrol etmekten çekinmeyin!

Takımlar > KDE Eko

Okular için Blauer Engel başvurusunun tamamlanması

Enerji tüketimi halihazırda ölçülen üç KDE uygulaması vardır: Okular, K Posta ve Krita. Bu üç uygulamadan Okular ve K Posta için Blauer Engel başvuruları bir süredir hazırlık aşamasındaydı ve hedeflerimizden biri Okular’ın başvurusunu tamamlamaktı. Hız koşusunun ardından Okular’ın başvurusunun gönderildiğini ve şu anda sertifikasyon için incelenmekte olduğunu duyurmaktan gurur duyuyoruz. Blauer Engel’i ödüllendiren kurum olan RAL gGmbH’den 2–3 ay içinde geri bildirim bekliyoruz. K Posta’nın gönderimi yakında gelecek.

Okular uygulamasının grup incelemesi sırasında katılımcılar birçok ilginç noktayı dile getirdiler. Örneğin Blauer Engel’in saydamlık kriterlerini tartışırken bir nokta ortaya çıktı (Bölüm 3.1.3.2). IASS “Dijitalleşme ve Sürdürülebilirlik Dönüşümleri” araştırma grubundan Malte Reißig, açık geliştirmenin ödül kriterlerinin diğer gerekliliklerinden bazılarını nasıl olumlu yönde etkileyebileceğini vurguladı (bu tartışmaya bakın); örneğin, bir yazılım ürününün uzun vadeli bakımı ve kullanıcı özerkliği gibi. Yani, Özgür Yazılım kullanıcıları yazılımı yalnızca pasif bir şekilde kullanmakla kalmaz, aynı zamanda teşvik edilirler ve uygulamaların gelecekteki gelişimi için dileklerini ifade edebilirler ve dönüm noktalarının planlanmasına etkin olarak katılabilirler. Ayrıca, açık geliştirme ile işleme iletileri, kullanıcılar ve geliştiricilerden oluşan bir topluluk tarafından bildirilen belirli sorunlar veya hatalarla ilişkilendirilebilir. Özgür Yazılım’da, bir uygulama yalnızca bir son ürün değil, aynı zamanda kullanıcılarının ve topluluklarının gereksinimlerini ve isteklerini yansıtan açık bir süreçtir. FOSS ile topluluk gelişimin yönünü belirler!

Okular Simgesi

Diğer bir nokta ise Özgür Yazılım’ın dağıtımı ve Blauer Engel kriterlerinin karşılanması açısından nasıl zorluklar sunduğuyla ilgiliydi. Özgür Yazılım genellikle yazılımı merkezi olmayan bir şekilde dağıttığından, herhangi bir uygulama için çok sayıda yayım ve dağıtım kanalı vardır. Okular’a bakalım; yalnızca Flatpak için değil, aynı zamanda Microsoft Store ve çok sayıda GNU/Linux (örneğin, OpenSuse, Debian) dağıtımları için de paketlenir. Paketleme altyapısındaki farklılıklar, kaldırılabilirlik, modülerlik vb. gibi Blauer Engel gereksinimlerinin karşılanmasını etkileyebilir.

Tipik olarak ürünlerinin merkezi dağıtımıyla özel mülk yazılım yayımlayan şirketlerde bu sorunlar yaşanmaz. Bunun ışığında, grubun tartıştığı olasılıklardan biri, bir programın yalnızca kaynak kodunu onaylamak, dolayısıyla bir yazılım ürününün paketlenme ve dağıtılma şekli konusundaki farklılıklar konusunda tarafsız kalmaktır. Diğer bir olasılık ise Microsoft Store gibi dağıtıma özel sürümlerin sertifikalandırılmasıdır. Aslında ikincisi, yeni kullanıcılara ulaşmak ve onları KDE topluluğuna kazandırmak için pazarlama amacıyla kullanılabilir — örnek olarak bu tartışmaya bakabilirsiniz.

Ne düşündüğünüzü bilmek isteriz. Lütfen posta listemizdeki veya Matrix odamızdaki veya GitLab depolarımızdaki sorun izleyicilerimiz aracılığıyla sohbete katılın!

Standart Kullanım Senaryoları

Standart Kullanım Senaryosu (SUS), bir uygulamanın tipik işlevlerini yansıtır ve bu işlevlerin sıklığı dikkate alınır. Standart Kullanım Senaryoları, bir yazılım parçasının enerji tüketimini ölçmenin merkezinde yer alır.

Blauer Engel uygulaması için Okular’ın SUS eylem günlükleri incelenirken, laboratuvarda ölçüm sırasında SUS’un uygulanmasını geliştirecek iki önemli noktaya dikkat çekildi. Bunlardan biri, enerji tüketimini etkileyebileceği için yalnızca eylemleri değil aynı zamanda eylem nesnelerini de belgeleme ihtiyacına ilişkin gözlemdi (örneğin, PDF’yi açarken kullanılan PDF okuyucu açıldığında). Diğeri ise bir SUS’u tanımlarken boşta kalan eylemi içermenin önemli olduğuydu: Boşta kalan eylem hem gerçekçidir hem de hiçbir şeyin olmaması gerektiğinde hiçbir şeyin olmadığını gösterebilir.

Diğer bazı konular da sanal masaya getirildi. KDAB Berlin’de bir yazılım mühendisi olarak çalışan Nicolas Fella, iki sohbet istemcisini karşılaştırmaya ilgi duyduğunu ifade etti ve bu da benzer kullanıma sahip iki uygulamayı karşılaştırırken konu tekil senaryoları tanımlamaya kaydı. Tek bir SUS, hangi yazılım işlevlerinin sınanabileceğini sınırlar; ancak ölçümlerden elde edilen sonuçların doğrudan karşılaştırılabilir olmasını sağlar. Ayrıca, sohbet veya e-posta istemcileri gibi istemci-sunucu yazılımları için denetimli sınamada, bir sunucunun kurulmasını ve enerji tüketiminin ölçülmesini gerektiren ağ bileşeni sorunu vardır. Eski KDE e.V. başkanı ve uzun süredir KDE’ye katkıda bulunan Cornelius Schumacher, K Posta ölçümleri için yalnızca yerel makinedeki hesaplama işinin ölçüldüğüne dikkat çekti. İstemci-sunucu yazılımında yerel olmayan bilgi işlemin ölçülmesi günümüz dünyasında her zamankinden daha anlamlıdır ve bu, şu anda yazılıma yönelik revize edilmiş Blauer Engel ödül kriterleri için planlanmaktadır.

K Posta Karşılama Ekranı

Tartışılan bir diğer konu, kullanım senaryolarının farklı araçlarla (Actiona, xdotool, KXmlGui, vb.) uygulanmasını otomatikleştirmek amacıyla SUS eylemlerini soyut olarak tanımlamaktı. Önemli bir nokta, farklı öykünme araçlarının farklı şeyler yapmasıydı; bu da sürecin otomatikleştirilmesinde zorluklara neden olabilirdi. Örneğin, öykünme için KXmlGui kullanılırken metin yazılamaz ve bu nedenle xdotool gibi bir şeye hâlâ gereksinim duyulabilir. İlgili bir nottaki başka bir teklif, bir SUS’un, bir eylem günlüğünün oluşturulmasının da otomatikleştirilebileceği şekilde yapılandırılmasıydı. Toplulukta bu zorlukların üstesinden gelmeye yardımcı olmak isteyen herhangi biri var mı?

Ayrıca grup, eski veya düşük kaliteli donanımlarda yanıt verebilirliği ve genel başarımı sınamak için kullanım senaryolarının nasıl yeniden tasarlanabileceğini tartıştı. Sizin fikirleriniz nelerdir?

2022’nin başlarında FOSS/KDE uygulamalarının enerji tüketimini ölçmek için bir ölçüm maratonu düzenlemeyi planladığımızı biliyor muydunuz? Hangi uygulamalara yönelik Standart Kullanım Senaryoları’nın hazırlanmasını istersiniz? Fikirlerinizi burada bizimle paylaşın veya SUS’unuzu GitLab depomuza gönderin!

Kopyalanabilir başvuru sistemi

Standart Kullanım Senaryoları bir başvuru sistemi üzerinde çalıştırılır ve ortaya çıkan önemli bir konu, kopyalanabilir bir başvuru sistemine nasıl sahip olunacağıydı. Dikkate alınması gereken birkaç sistem katmanı vardır: Donanım (CPU, Disk, Bellek, vb.); Plasma’daki etkinlik yöneticisi gibi işletim sistemi ve işletim sistemi hizmetlerinin yanı sıra bunların yapılandırmaları; ve sınanan uygulamanın yapılandırmasının yanı sıra ilgili uygulamalar (örneğin, PIM uygulamaları için Akonadi). Bir yandan sonuçların yorumlanabilmesi için denetimli bir ortamın olması gerekir; diğer yandan, yazılımın gerçek dünyadaki enerji tüketimini anlamak için gerçek, hatta belki de gürültülü bilgi işlem ortamlarını yansıtan ölçümlerin olması arzu edilir. Sonuçta denetimli veya doğal bilgi işlem ortamlarına sahip olunması verinin ne için kullanılacağına bağlı olacaktır ve bu durum araştırmacılar, geliştiriciler, eko etiket denetçileri, şirketler vb. için farklılık gösterecektir.

Örneğin, enerji verimliliği birim sınamaları yapmak veya Blauer Engel mührünü almak isteyen geliştiriciler için açıkça belirlenmiş ortamlara sahip olmak gerekli olacaktır. Peki sistemi bilinen bir duruma getirmenin kullanışlı ve hızlı yolları nelerdir? Üç fikir tartışıldı: (i) Bir dosya sisteminin anlık görüntülerini almak (örneğin, Snapper), (ii) sistem önbelleğini temizlemek ve (iii) yapılandırma dosyalarını başkalarıyla değiştirmek. Başka fikirleriniz varsa buradan bize bildirin!

Gerçek dünya ortamları için tartışmalı olabilecek bir öneri ise insanlar kişisel bilgisayarlarını kullanırken donanım başarımını ve elektrik gücü kullanımını bir günlüğe kaydetmektir. Herhangi bir gönüllü var mı?

Veri çıktısı

Özellikle Blauer Engel eko sertifikasyonu için bir laboratuvarda enerji tüketimini ölçerken, üç tür veri dosyası oluşturulabilir: (i) Eylemlerin bir günlük dosyası (bu tür günlük dosyalarının otomasyonu ile ilgili yukarıya bakın), (ii) donanım başarımı verisi (CPU, Bellek, vb.) ve (iii) elektrik gücü kullanımı. Bazı durumlarda çıktı verisinin kendi kendine tanımlanması gerekeceğinden (örneğin, xdotool betiklerindeki zaman damgası günlükçüleri), laboratuvarda ölçüm yapmadan önce verinin nasıl görünmesi gerektiğini düşünmek gerekir.

Verilerle ilgili çeşitli sorunlar gündeme getirildi: Ölçüm hareketleri arasında çıktıyı uyumlu hale getirmek için veri çıktısı standartlaştırılmalı mı yoksa toplanan verileri erişilebilir bir biçimde (örneğin, FEEP deposundakiler gibi CSV dosyaları olarak) yayımlamak yeterli mi? Hangi zaman damgası doğruluğuna gereksinim var (örneğin, saniye ve kesirli saniye)? Bu sorular şimdilik yanıtsız kalıyor; ancak grup, FOSS uyumlu aygıtlara/betiklere ilişkin bir genel bakışa gereksinimimiz olduğuna karar verdi (örneğin, Gude Expert Power Control 1202 Series için Achim Guldner’in betiği gibi) ve ölçümler ve çözümlemeler için şu anda sürmekte olan kullanılan araç kitleri (örn. OSCAR, R, Julia, Octave, PSPP, NumPy gibi istatistiksel çözümleme araçları).

Güç ölçer araçları

Blauer Engel kriterleri özellikle iki güç ölçeri (GÖ) ifade eder: Janitza UMG 604 ve Gude Expert Power Control 1202. Bu aygıtlar ucuz değildir. 2020’de, uzun süredir KDE’ye katkıda bulunan Volker Krause, 8 avroluk bir elektrik fişinin üzerinde oynadı ve bunun hakkında yazdı. Blog yazısında açıklandığı gibi, bu ucuz elektrik prizleri 200 ms’ye kadar örnekleme hızı elde edebiliyor. Bu, düşük bütçeli ev laboratuvarlarında ucuz güç ölçüm aygıtlarının kullanılması fikrine yol açtı. Bu amaçla, profesyonel güç ölçüm aygıtlarından elde edilen sonuçları ucuz yollu ölçüm aygıtlarıyla karşılaştırmak ve bunların nasıl karşılaştırıldığını görmek faydalı olacaktır. Toplulukta bunu yapmakla ilgilenen biri var mı?

*Volker Krause’nin blog gönderisinden: “Örnek ölçüm (200 ms örnek aralığı, süzgeç yok): Fare imleci, 100 ve 150 örnekleri arasında hareket ettirilirken bir görev çubuğu girdisinin üzerine geldiğinde tepe yapıyor.”

Enerji tüketimini ölçmenin bir başka yolu da, duvar prizinde ölçüm yapan güç ölçerlere göre daha yüksek çözünürlüklü bir alternatif sağlamak üzere USB SPI güç algılayıcıları önerisini sunan KDE katılımcısı David Hurka’dan geldi.

Ölçüm laboratuvarları için bekleyen sorunlar

Enerji tüketimi ve laboratuvar ölçümleriyle ilgili diğer bazı konular da tartışıldı. Her durumda nihai kararlar verilmemiş olsa da, bu açık konuların birçoğunun ileriye dönük olarak değerlendirilmesi önemli olacaktır.

• Yazılımların enerji tüketimine dikkat çekmek için pazarlama dostu bir araç fikri.
  • Örneğin, enerji verimliliği/karbon ayak izi ölçer için bir ’Eko’ düğmesi (bkz. Yol Kılavuzu uygulamasındaki yolculuk karbon ayak izi).
  • Benzer bir işlevselliğin PowerTop tarafından zaten sağlandığını unutmayın; ancak açık sorunlar sürmektedir (veri kaybını veya makinenin donmasını önlemek için etkinleştirmek ne zaman güvenlidir?).
• Eski donanım desteğinin dezavantajları ne zaman yararlarından daha ağır basar?
  • Bu konu üzerinde çalışan araştırmacıları KDE Eko topluluğuyla tartışmaya davet edelim.
• Gelecekteki işbirliği:
  • İlgili projelerle ortak hız koşusu (örneğin, SoftAWERE)? (Okuyucunun ilgisini çekebilir: SoftAWERE/SDIA’den Max Schulze, KDE Eko’nun Ocak 2022’deki aylık toplantısında sunum yaptı; tutanakları buradan okuyabilirsiniz.)
  • Yukarıdaki konuları ve daha fazlasını diğer ilgili topluluklarla tartışın (Bits & Bäume, Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung /), vb.)?

Sonuç

Çevrimiçi hız koşusu, topluluğu bir araya getirmek ve KDE Eko projesini ileriye taşımak için harika bir fırsattı, özellikle de KDAB Berlin’de düzenlenecek olan topluluk ölçüm laboratuvarına ve birçok ölçüm maratonunun ilkine (2022’nin başı için planlandı) hazırlanırken! Bu tür etkinliklerin başarısı her şeyden önce topluluğa bağlıdır, bu nedenle sohbete katılan herkese yürekten teşekkürlerimizi göndermemize izin verin. Topluluğun 2022’de büyümesini sabırsızlıkla bekliyoruz! Üstelik KDE e.V’nin ve BE4FOSS projesini finansal olarak destekleyen BMU/UBA destekleri olmasaydı bunları başaramazdık (ancak bu yayımın içeriğinden yalnızca yayımcı sorumludur) ).

Fonlanma Bildirimi

BE4FOSS projesi Federal Çevre Ajansı ve Federal Çevre, Doğa Koruma, Nükleer Güvenlik ve Tüketicinin Korunması Bakanlığı tarafından finanse edildi (BMUV¹). Fonlar, Alman Federal Meclisinin kararıyla kullanıma sunulur.

Bu yayımın içeriğinden yayımcı sorumludur.

¹ Resmi BMUV ve UBA Logoları, yalnızca şu adrese yapılacak talep üzerine gönderilir: verbaendefoerderung@uba.de