F-Droid derleme sunucusu, eski CPU nedeniyle modern Android uygulamalarını derleyemiyor

 (news.ycombinator.com)
1 puan yazan GN⁺ 2025-08-14 | 1 yorum | WhatsApp'ta paylaş
  • F-Droid derleme sunucusu, eski CPU nedeniyle modern Android uygulamalarını derleyemiyor
  • ARM, x86-64 gibi modern mobil uygulamaların gerektirdiği gelişmiş komut setlerini desteklemiyor
  • Sunucunun yükseltilmesi ve değiştirilmesi gerekiyor, ancak maliyet ve altyapı sınırlamaları var
  • Geliştiriciler, F-Droid'in sürdürülebilirliği ve teknik olarak güncel kalması konusunda endişelerini dile getiriyor
  • Alternatif olarak bulut tabanlı derleme ve sunucu kaynaklarının bağışlanması tartışılıyor

Genel Bakış

  • F-Droid, Android açık kaynak uygulamaları için gayriresmî bir mağaza ve uygulamaları doğrudan kaynak kodundan derleyerek dağıtıyor
  • Son dönemde derleme sunucusu, modern Android uygulamalarının gerektirdiği CPU komut setlerini desteklemediği için bazı uygulamalar artık derlenemiyor

Derleme Sunucusunun Teknik Sınırları

  • Uygulama derlemek için gereken yeni ARM ve x86-64 komutları eski CPU tarafından desteklenmiyor
  • Bu sınırlama nedeniyle performans optimizasyonu yapılmış modern uygulamalar ya da güncel kütüphaneleri kullanan uygulamalar derleme dosyası olarak sunulamıyor
  • Python, Kotlin gibi modern diller ile Gradle gibi güncel derleme araçları da sık sık daha yeni CPU ortamları gerektiriyor

Topluluk İçindeki Endişeler ve Tartışmalar

  • Geliştiriciler ve kullanıcılar, F-Droid'de uygulama kalitesinin sürekli düşmesi ve derleme hatası raporları konusunda endişelerini dile getiriyor
  • Altyapının yükseltilmesi gerekiyor, ancak mali kısıtlar ve sunucu yönetimi için personel eksikliği öne çıkıyor

Alternatifler ve Çözüm Arayışları

  • Bulut ortamında derleme sunucusu çalıştırılması ya da topluluk tarafından sunucu kaynağı bağışlanması gibi çeşitli seçenekler tartışılıyor
  • F-Droid ekibi, dış destek ve yeni donanım sağlayarak sorunu çözme niyetini ortaya koyuyor

Sonuç

  • F-Droid'in değeri ve açık kaynak ekosistemini destekleme önemi hâlâ yüksek
  • Ancak modern uygulama eğilimlerine uygun altyapısal yenilik ve bakım çabaları zorunlu

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-14
Hacker News görüşü

  • Bu, sunucularının gerçekten çok eski olduğu anlamına geliyor; x86-64-v2'yi desteklemeyecek kadar eski, neredeyse Intel Core 2 Duo döneminden kalma sunucuları düşündürüyor.
    Red Hat Enterprise Linux 9'un x86-64-v2 mikro mimari seviyesi hakkında derli toplu yazı incelenebilir.
    Tüketici sınıfı bir Epyc CPU'ya geçilirse sunucu performansının çok daha hızlı olacağını düşünüyorum.
    Aslında bağış yapmayı düşünmüştüm ama kasada zaten $80,000 kalmıştı.
    Yıllık bütçenin $17,000 olduğu düşünülürse, 2-3 bin dolara güncel bir Zen4 veya Zen5 matx tüketici Epyc sunucusu almak yine bütçe içinde kalır.
    Eğer gerçekten birkaç tane yaşlı sunucu varsa, tek bir Zen5 sunucu birkaçını birden değiştirebilir; elektrik ve alan tasarrufu da çok daha iyi olur.
    F-Droid bütçe durumu da görülebilir.
    Görünüşe göre Librapay bağışları buna henüz dahil değil.
    Librapay bağış bağlantısı

    • Sunucuların eski olması şart değil; kendi sanallaştırma platformumuzdaki deneyimde, harici sağlayıcının VM'lerini yükselttikten sonra CPU tarafında x86_64v2 + AES desteği görünür hâle getirilmişti ama bazı servisler yine de çalışmadı.
      Asgari gereksinim "Pentium ve Celeron" olarak görünüyordu, bu yüzden yeterli olduğunu sanmıştık.
      Ama gerçekte servislerden biri yalnızca v3 veya v4 CPU'larda desteklenen komutları kullanıyordu ve bu yüzden çalışmayı bıraktı.
      Görünen CPU ayarını değiştirince normale döndü.
      Yani sunucunun kendisi aslında yeterli olabilir; sorun bir yapılandırma hatası, ikili dosyanın belirtilenden daha yüksek özellik istemesi ya da başka bir mesele de olabilir.
    • $2-3 bin dolar aslında alt seviye bir Threadripper stok CPU'nun fiyatına ancak denk gelir; bu parayla komple bir Epyc sunucusu alınamaz.
    • Belki de sunucu Coreboot ya da Libreboot ile açılıyordur.
    • Linux'un bugün bu kadar eski donanımı resmî olarak hâlâ destekleyip desteklemediğini de merak ediyorum.
      cmpxchg16b o kadar da eski olmayan bir komut ve artık zorunlu özellik gibi görülüyor.
    • Elde fazla para kalmamış olsa bile yine de bağış yapılmasını öneririm.
      Gönüllülerin sistemi ayakta tutmak için harcadığı zaman ve emeğe kıyasla £80,000 gerçekten çok az bir para.
      Altyapının modernizasyon gerektirdiğini duydum ama bu ciddi yatırım isteyen bir alan.
      Fonlar daha rahat olsaydı muhtemelen yatırım yaparken daha özgüvenli davranabilirlerdi.
      Sadece sunucu yükseltmesi dışında da çözülmesi gereken çok iş var.

  • Mevcut durum bence epey endişe verici.
    F-Droid şu anda Google hariç en büyük Android uygulama mağazası olduğu için buna daha da ihtiyaç olduğunu düşünüyorum.
    Bu sorunu çözmek için bir plan olup olmadığını, F-Droid'in sunucuları ne zaman yükselteceğini ya da Google'ın bu zorunlu gereksinimi geri çekme ihtimali olup olmadığını merak ediyorum (sonuncusunun pek olası olmadığını düşünüyorum).

    • F-Droid'in gönüllülerce yürütülen bir topluluk projesi olduğu düşünülürse endişeyi anlıyorum; yine de özellikle AB ülkeleri açık kaynak yazılıma yönelirken, F-Droid gibi projelerin kamu fonu almasını isterdim.
    • F-Droid önemliyse, yeni build sunucuları alınabilmesi için doğrudan bağış yapmak da gerekir.
    • Google'ın gereksinimi geri çekme ihtimali konusunda, 2021'de de benzer bir sorun yaşanmıştı; o dönemde Gradle Plugin 4.1.0, SSSE3 komutlarını gerektiriyordu ve bu yüzden sorun çıkmıştı.
      Bu sorun Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9 sürümünde düzeltilmişti.
      İlgili kayıt da hâlâ duruyor.
    • F-Droid'in Google hariç en büyük Android mağazası olduğu iddiasına şüpheyle yaklaşıyorum.
      Bence ilk 10'a bile giremez.
    • "Google build araçları kaynaktan derlenmiyor, özel optimize edilip ikili olarak dağıtılıyor" açıklamasını duyunca, çözümün kesin olarak sunucuyu yükseltmek olduğu sonucuna katılmıyorum.

  • Neden aapt2 hedefe uygun şekilde yeniden derlenmiyor diye merak ediyorum.
    Kaynak kodu mevcut.
    aapt2 kaynak konumu

    • Gerçekten AOSP derlemeyi denemiş biri var mı diye sormak isterim.
      İçinde inanılmaz fazla ikili dosya var; bazılarını kaynaktan yeniden derlemeye çalıştım ama build sistemi o kadar bozuktu ki hemen vazgeçtim.
    • Docker içinde QEMU CPU emülasyonu kullanmak, aapt2yi tek tek yeniden derlemekten bakım açısından çok daha kolay.
      Böylece ileride çıkan her ikili dosya için yeniden yama yapmak gerekmeden, ikili güncellemeler otomatik olarak karşılanabilir.

  • Streaming SIMD Extensions(SSSE3) wiki sayfası paylaşılmış.
    Benim eski masaüstüm bile bu komutu destekliyordu ve onu yaklaşık 10 yıl kullandım.
    Buna rağmen kaynak kodunda assembly seviyesinde bile bir geri dönüş yolu olmaması şaşırtıcı.

    • "Assembly tarafında da bir fallback yolunun olmaması garip" yorumuna karşılık, muhtemelen sorun elle yazılmış assembly kodu değildir.
      Büyük ihtimalle derleyici x86_64-v2 hedefiyle derleme yaptı.
      RHEL 9 da böyle derlendi; RHEL 10 ise x86_64-v3'e çıkıp AVX desteği de ekliyor.
    • Soruna bakınca build makinesinin Opteron G3 (K10) sınıfı olduğu anlaşılıyor.
      AMD 10h wiki bağlantısı
    • Fallback yolunun olmamasının sebebi test donanımı eksikliği.
      Pratikte bunu test edecek donanım yok; elde olanlar sadece eski ve yavaş makineler.
    • Eski bir masaüstü bağışlasanız F-Droid muhtemelen memnun olur.

  • Tam olarak anlayabilmiş değilim.
    gradle ve aapt2 açık kaynaksa, buildroot veya openwrt benzeri şekilde bunları doğrudan derleyip araç zinciri oluşturmak daha öngörülebilir sonuç vermez mi?
    F-Droid de tüm araç zincirini kaynaktan derlese, desteklenmeyen komutlar içeren ikili gradle veya aapt2 kullanmak zorunda kalmazdı.

    • Pratikte hâlâ Google'ın sağladığı SDK ikili dosyalarını kullanmak zorundalar.
    • Yaklaşım mantıklı görünse de, gradle kendi içinde önceden derlenmiş Java kütüphaneleri gibi bağımlılıkları indirip kullanıyor.
      Bunların bir kısmı yerel ikili dosyalar içeriyor ve buildroot ya da Linux dağıtımları gibi her kütüphanenin nasıl derlendiğine dair bir meta veri yok.
      Ayrıca gradle ekosistemindeki her kütüphanenin build süreci farklı olduğu için (standart değil), her şeyi doğrudan kaynaktan yeniden kurmak oldukça zahmetli ve zorlu bir iş.

  • Google'ın upstream tarafta bu sorunu zaten düzelttiğini söyleyenler de var.
    İlgili issue bağlantısı
    Ne kadar hızlı çözüleceğinden emin değilim ama issue dizisinde doğrudan bir düzeltme kanıtı olmasa da biraz iç rahatlatıyor.

    • Aslında henüz düzeltilmiş değil.
      Yukarıdaki bağlantılı dizide bir yazım düzeltmesi (mas fixed→was fixed) sanki bu sorunun çözüldüğü anlamına geliyormuş gibi yanlış anlaşılmış.
      Çözülen şey, birkaç yıl önceki benzer eski bir sorundu.
      Google issue tracker buna işaret ediyor.
    • Bu kök sorun hâlâ geliştiriciler arasında yeterince bilinmiyor.

  • sse4.1'in 2011'de gelen bir komut olduğunu düşününce, böyle eski sunucuların hâlâ çalışıyor olması tuhaf geliyor.
    Modern CPU'lar aynı işi çok daha az güç tüketerek yapabilir; ekonomik açıdan da bu kadar eski donanımı kullanmaya devam etmek mantıklı görünmüyor.
    Build sunucularının sayısı veya özellikleri hakkında bilgisi olan biri var mı diye merak ediyorum.

    • Modern CPU'larla aynı işin elektrik maliyetinin çok daha düşeceği ve bu yüzden hızlı yükseltme gerektiği yorumuna karşılık, yılda 8,760 saat içinde 500W sınıfı bir CPU tüm yıl tam yükte çalışsa bile elektrik faturası $550 ediyor.
      Bunu yarıya indirmek, yeni bir bilgisayarın fiyatının ancak %10'u kadar eder; yani maliyeti çıkarması 10 yıl sürer.
      Ayrıca yükseltme sermaye gideridir, elektrik ise işletme gideri.
      ABD elektrik fiyatı verisi
    • sse4.1, Intel Penryn ile ilk kez Kasım 2007'de geldi; AMD ise Bulldozer'a kadar (2011 ortası) bunu desteklemedi.
      Bulldozer ile gelen çeşitli komutlar (AVX, FMA vb.) vardı ama eski Opteron'lar pratikte çoğu zaman Bulldozer'dan daha hızlıydı; bu yüzden Epyc çıkana kadar (2017 ortası) yükseltme teşviki zayıftı.
      Çeşitli paketlerde sse4.1 ve üstüne geçilmesinin nedeni, daha eski CPU'larda koşullu dallanma gibi işlemlerde SIMD paralelliğinin ek yükünün yüksek olması.
    • Gerçek cevap, "açık firmware ve ME/PSP'siz çift soket AMD kartlar (örneğin KGPE-D16) kullanılabildiği için" olabilir.
    • Sunucu tarafını çok bilmiyorum ama masaüstü dünyasında gerçekten eski donanımı sık görmek mümkün.
      2000'lerden kalma PC'ler sıradan işler için (web gezintisi gibi) uzun süre yeterliydi, ancak zamanla programlar yeni komut setleri istemeye başladı ve giderek işe yaramaz hâle geldiler.
      Hatta Firefox bile yeni komut seti istemeye başlayınca, sonunda aslında gayet çalışan bir masaüstünü bırakmak zorunda kaldım.
    • Eski CPU kullanılmasının sebebinin Canoeboot, GNU Boot gibi özgür firmware tercihleri olduğunu düşünüyorum.
      Ama KGPE-D16 kartına SSE4.2 destekli CPU da takılabiliyor; dolayısıyla tam nedenin bu olup olmadığından emin değilim.

  • Google'ın yeni aapt2 ikili dosyasından (AGP 8.12.0) söz edilirken, F-Droid'in build ortamını koruma ve yalıtma konusunda aşırı titiz bir proje olmasına rağmen neden hâlâ upstream ikili dosyalarını indirip kullandığı, bunları kaynaktan üretmediği şaşırtıcı bulunmuş.

    • Bununla bağlantılı olarak, nispeten yakın zamana kadar Android SDK'nin güncel özgür yazılım build'leri mevcut değildi.
      Android uygulaması üretmek için temelde Google'ın özgür olmayan ikili dosyalarına bağımlı kalıyorsunuz.
      İlgili forum yazısı buna değiniyor.

  • Referans bağlantılarının özeti
    F-Droid admin issue
    Catima uygulama issue'su
    MBCompass issue'su

    • Catima başlığını okuyunca, F-Droid topluluğuyla çalışmanın çok zor olduğuna dair güçlü bir izlenim kalıyor.
      Bir üye şöyle diyor: "F-Droid'de hep olduğu gibi sesimiz yine duyulmadı. Çözüm yollarını tartışıp F-Droid'i geliştirebileceğimize dair bir umut olsaydı, bu kadar zaman ve enerji harcadıktan sonra hayal kırıklığıyla çekip gitmezdik."

  • F-Droid sunucularının gerçekten antika olduğu görüşü var.
    Hatta tamamen farklı bir mimaride x86_64 emülasyonu yaparak bile performans artışı görülebilecek seviyede olduğu söyleniyor.
    Yani bunu savunmak için açık kaynak ilkelerine dayalı ek bir gerekçe bile gerekmiyor.
    Kapalı firmware konusunda takıntınız yoksa, daha ucuz ve daha güncel x86 sunucu seçenekleri de çok.

    • "Sunucular gerçekten çok eski" denince insan neredeyse bir espri bekliyor.
      Popüler kültür yüzünden akla "sunucular o kadar eski ki Benjamin Franklin'le anaokulunda sıra arkadaşıydı" tarzı şakalar geliyor.