Server build F-Droid tak bisa membangun aplikasi Android terbaru karena CPU lama

 (news.ycombinator.com)
1 poin oleh GN⁺ 2025-08-14 | 1 komentar | Bagikan ke WhatsApp
  • Server build F-Droid mengalami situasi di mana tidak dapat membangun aplikasi Android terbaru karena CPU lama
  • Tidak mendukung set instruksi lanjutan yang dibutuhkan aplikasi mobile modern seperti ARM dan x86-64
  • Upgrade dan penggantian server diperlukan, tetapi ada keterbatasan biaya dan infrastruktur
  • Para pengembang menyatakan kekhawatiran tentang keberlanjutan dan kemutakhiran teknis F-Droid
  • Sebagai alternatif, sedang dibahas build berbasis cloud dan donasi sumber daya server

Gambaran umum

  • F-Droid adalah toko tidak resmi untuk aplikasi Android open source, dengan model distribusi aplikasi yang membangun langsung dari kode sumber
  • Baru-baru ini, server build tidak lagi dapat menyediakan build untuk sebagian aplikasi karena tidak mendukung set instruksi CPU yang dibutuhkan oleh aplikasi Android terbaru

Keterbatasan teknis server build

  • Instruksi ARM dan x86-64 baru yang diperlukan untuk membangun aplikasi tidak didukung oleh CPU lama
  • Akibat keterbatasan ini, muncul masalah di mana aplikasi modern yang telah dioptimalkan performanya atau aplikasi yang memakai library terbaru tidak bisa disediakan dalam bentuk file build
  • Bahasa modern seperti Python dan Kotlin serta tool build terbaru seperti Gradle juga sering membutuhkan lingkungan CPU yang lebih baru

Kekhawatiran dan diskusi di komunitas

  • Pengembang dan pengguna menyampaikan kekhawatiran atas penurunan kualitas aplikasi F-Droid yang berkelanjutan serta laporan kegagalan build
  • Upgrade infrastruktur dibutuhkan, tetapi sorotan tertuju pada keterbatasan pendanaan dan kurangnya personel pengelola server

Mencari alternatif dan solusi

  • Berbagai opsi sedang dibahas, seperti menjalankan server build di lingkungan cloud atau donasi sumber daya server dari komunitas
  • Tim F-Droid menyatakan komitmennya untuk menyelesaikan masalah ini melalui dukungan eksternal dan perangkat keras baru

Kesimpulan

  • Nilai F-Droid dan maknanya dalam mendukung ekosistem open source tetap tinggi
  • Namun, upaya pembaruan infrastruktur dan pemeliharaan yang sesuai dengan tren aplikasi modern menjadi hal yang wajib

Bacaan terkait

1 komentar

 
GN⁺ 2025-08-14
Komentar Hacker News

  • Ini berarti server mereka benar-benar sudah sangat tua, sampai pada level yang tidak mendukung x86-64-v2, dan hampir mengingatkan pada server era Intel Core 2 Duo
    Silakan lihat tulisan yang merangkum level mikroarsitektur x86-64-v2 di Red Hat Enterprise Linux 9
    Jika diganti ke CPU konsumen Epyc, performa server sepertinya akan jauh lebih cepat
    Saya sempat ingin berdonasi, tetapi ternyata masih tersisa $80,000
    Mengingat anggaran tahunan mereka $17,000, membeli server konsumen Epyc mATX Zen4 atau Zen5 terbaru seharga $2~3 ribu pun masih masuk anggaran
    Jika memang ada beberapa server yang benar-benar menua, satu server Zen5 bisa menggantikan beberapa mesin sekaligus, sekaligus menghemat listrik dan ruang jauh lebih banyak
    Lihat juga status anggaran F-Droid
    Sepertinya donasi Librapay masih belum dimasukkan
    Tautan donasi Librapay

    • Belum tentu semata-mata karena servernya tua; dari pengalaman kami di platform virtualisasi, setelah VM dari vendor eksternal di-upgrade dan diekspos agar CPU-nya mendukung x86_64v2 + AES, beberapa layanan justru tidak bisa berjalan
      Karena syarat minimumnya hanya "Pentium dan Celeron", kami kira itu sudah cukup
      Ternyata salah satu layanan memakai instruksi yang hanya didukung CPU v3 atau v4, sehingga berhenti bekerja
      Setelah pengaturan CPU yang diekspos diubah, semuanya kembali normal
      Jadi bisa saja servernya sebenarnya cukup mampu, tetapi ada salah konfigurasi, atau binarinya menuntut spesifikasi yang lebih tinggi daripada yang dinyatakan, atau ada masalah lain
    • $2~3 ribu sebenarnya hanya setara harga CPU Threadripper kelas bawah dalam kondisi standar, jadi dengan uang sebanyak itu tidak mungkin membeli satu server Epyc lengkap
    • Mungkin juga servernya diboot dengan Coreboot atau Libreboot
    • Saya juga ragu Linux saat ini masih mendukung perangkat keras setua itu secara resmi
      Instruksi cmpxchg16b bukan instruksi yang terlalu baru, dan sekarang dianggap sebagai persyaratan wajib
    • Walaupun dana yang tersisa tampak tidak sedikit, saya tetap ingin mendorong orang untuk berdonasi
      Dibandingkan waktu dan tenaga para relawan untuk memelihara sistem, £80,000 itu benar-benar jumlah yang kecil
      Saya pernah mendengar bahwa modernisasi infrastruktur memang diperlukan, tetapi itu butuh investasi besar
      Jika dana mereka lebih longgar, mungkin mereka bisa berinvestasi dengan lebih percaya diri
      Selain upgrade server, masih banyak pekerjaan lain yang juga perlu diselesaikan

  • Situasi saat ini terasa cukup mengkhawatirkan
    Saya merasa FDroid makin penting karena saat ini merupakan toko aplikasi Android terbesar di luar Google
    Saya penasaran apakah ada rencana untuk menyelesaikan masalah ini, kapan kira-kira FDroid akan meng-upgrade server, atau apakah Google mungkin menarik kembali persyaratan wajib ini (meski kemungkinan terakhir tampaknya kecil)

    • Mengingat FDroid adalah proyek komunitas yang dijalankan relawan, kekhawatiran itu bisa dimengerti, tetapi terutama karena negara-negara UE sedang bergerak ke perangkat lunak open source, saya berharap proyek seperti F-Droid mendapat dukungan pendanaan publik
    • Jika f-droid memang penting, maka berdonasi langsung untuk pembelian build server yang lebih baru juga perlu dilakukan
    • Soal kemungkinan Google mencabut persyaratan ini, masalah serupa juga pernah terjadi pada 2021, saat Gradle Plugin 4.1.0 mewajibkan instruksi SSSE3 sehingga memicu isu
      Masalah itu diperbaiki di Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9
      Ada juga catatan tiketnya
    • Saya ragu dengan klaim bahwa FDroid adalah toko Android terbesar di luar Google
      Menurut saya pribadi, mungkin bahkan tidak masuk 10 besar
    • Setelah mendengar penjelasan seperti "tool build Google tidak bisa dibangun dari source, dan keluar sebagai biner yang dioptimalkan secara terpisah", saya tidak setuju bahwa kesimpulannya otomatis harus upgrade server

  • Saya penasaran kenapa aapt2 tidak dibangun ulang agar cocok dengan targetnya
    Source-nya tersedia
    Lokasi source aapt2

    • Saya ingin bertanya apakah Anda pernah benar-benar membangun AOSP
      Di dalamnya ada sangat banyak biner, dan ketika saya mencoba membangun ulang beberapa biner dari source, sistem build-nya begitu rusak sampai saya langsung menyerah
    • Menggunakan emulasi CPU QEMU di Docker jauh lebih mudah dipelihara daripada mengompilasi ulang aapt2 satu per satu
      Dengan begitu, pembaruan biner di masa depan bisa ditangani otomatis tanpa perlu menambal tiap biner yang baru muncul

  • Saya membagikan dokumen wiki Streaming SIMD Extensions (SSSE3)
    Desktop lama saya pun mendukung instruksi ini, dan saya memakainya hampir 10 tahun
    Karena itu cukup mengejutkan bahwa dari source code-nya pun tidak disediakan jalur fallback non-assembly

    • Menanggapi pertanyaan "aneh juga tidak ada fallback bahkan di assembly", kemungkinan besar masalahnya bukan kode assembly yang ditulis manual
      Kemungkinan besar kompiler dipakai dengan target x86_64-v2
      RHEL 9 juga dibangun dengan opsi semacam itu, dan di RHEL 10 targetnya naik ke x86_64-v3 sehingga AVX juga ikut didukung
    • Setelah melihat isunya, builder tampaknya memakai keluarga Opteron G3 (K10)
      Tautan wiki AMD 10h
    • Masalah tidak adanya jalur fallback lebih karena kurangnya perangkat keras untuk pengujian
      Secara realistis, hampir tidak ada perangkat keras untuk menguji ini selain mesin tua dan lambat
    • Kalau ada yang menyumbangkan desktop lama, FDroid mungkin akan senang menerimanya

  • Saya tidak sepenuhnya paham
    Gradle dan aapt2 itu open source, dan menurut saya hasilnya akan lebih bisa diprediksi jika toolchain dibangun sendiri seperti di buildroot atau openwrt
    Dengan begitu, f-droid juga bisa membangun seluruh toolchain langsung dari source dan tidak perlu memakai biner gradle atau aapt2 yang mengandung instruksi yang tidak didukung

    • Pada praktiknya, mereka masih terpaksa memakai biner SDK yang disediakan Google
    • Saya pikir pendekatan itu masuk akal, tetapi gradle sendiri mengunduh dependensi seperti pustaka Java prebuilt untuk dipakai
      Sebagian di antaranya bahkan mencakup biner native, dan tidak ada metadata tentang bagaimana tiap pustaka itu dibangun seperti pada buildroot atau distribusi Linux
      Selain itu, proses build untuk pustaka di ekosistem gradle sangat beragam dan tidak terstandarisasi, sehingga membangun ulang semuanya langsung dari source akan menjadi pekerjaan yang sangat merepotkan dan sulit

  • Ada juga yang mengatakan Google sudah memperbaiki masalah ini di upstream
    Lihat tautan isu ini
    Memang tidak bisa yakin seberapa cepat akan terselesaikan, tetapi thread isu itu agak menenangkan meskipun tidak memberi bukti langsung bahwa masalah ini benar-benar sudah diperbaiki

    • Sebenarnya itu masih belum diperbaiki
      Di thread pada tautan tersebut, ada kebingungan karena koreksi typo ("mas fixed"→"was fixed") disalahartikan sebagai tanda bahwa isu kali ini sudah selesai
      Yang sebenarnya sudah selesai adalah isu lama yang mirip dari beberapa tahun lalu
      Lihat Google Issue Tracker
    • Sampai sekarang pun akar masalah ini masih belum cukup dikenal oleh para pengembang

  • Mengingat sse4.1 adalah instruksi yang diperkenalkan pada 2011, agak aneh kalau server setua ini masih beroperasi
    CPU modern seharusnya bisa mengerjakan pekerjaan yang sama dengan konsumsi daya yang jauh lebih kecil, jadi secara ekonomi pun sulit dipahami kenapa perangkat keras tua seperti itu tetap dipakai
    Saya penasaran apakah ada yang tahu jumlah atau spesifikasi build server mereka

    • Menanggapi pendapat bahwa memakai CPU modern berarti pekerjaan yang sama bisa dilakukan hanya dengan sebagian kecil biaya listrik sehingga upgrade harus segera dilakukan: dari total 8.760 jam per tahun, bahkan jika CPU kelas 500W berjalan penuh sepanjang tahun, biaya listriknya hanya sekitar $550
      Kalau pun konsumsi itu dipotong setengah, penghematannya tetap hanya sekitar 10% dari harga komputer baru, jadi butuh 10 tahun untuk balik modal
      Upgrade adalah belanja modal, sedangkan biaya listrik adalah biaya operasional
      Data pendukung tarif listrik AS
    • sse4.1 pertama kali diperkenalkan pada Intel Penryn pada November 2007, dan AMD baru mendukungnya di Bulldozer (pertengahan 2011)
      Bulldozer memang menambahkan berbagai instruksi seperti AVX dan FMA, tetapi Opteron lama sering kali justru lebih cepat daripada Bulldozer, sehingga sebelum Epyc hadir (pertengahan 2017) insentif upgrade memang kecil
      Alasan banyak paket mulai menargetkan sse4.1 ke atas adalah karena pada CPU lama, overhead untuk hal-hal seperti percabangan kondisional dalam pemrosesan paralel SIMD cukup tinggi
    • Jawaban sebenarnya mungkin adalah "karena masih bisa memakai board AMD dual-socket tanpa open firmware dan tanpa ME/PSP seperti KGPE-D16"
    • Saya tidak terlalu paham sisi server, tetapi perangkat keras tua memang masih sering terlihat di desktop
      PC lama dari era 2000-an dulu masih cukup untuk pekerjaan ringan seperti browsing web, tetapi seiring waktu program mulai menuntut instruksi baru dan perlahan-lahan menjadi tidak berguna lagi
      Bahkan Firefox pun mulai membutuhkan set instruksi baru, dan saya akhirnya harus membuang desktop yang sebenarnya masih berfungsi baik
    • Saya kira alasan memakai CPU lama adalah demi firmware bebas seperti Canoeboot atau GNU Boot
      Namun board KGPE-D16 sebenarnya juga bisa dipasangi CPU yang mendukung SSE4.2, jadi saya sendiri tidak tahu alasan pastinya

  • Saat membahas biner aapt2 baru dari Google (AGP 8.12.0), terasa aneh bahwa F-Droid sangat menekankan perlindungan dan isolasi lingkungan build, tetapi justru mengambil biner upstream alih-alih membangunnya dari source

    • Terkait itu, sampai relatif baru-baru ini pun belum ada build perangkat lunak bebas untuk Android SDK yang tersedia dalam keadaan mutakhir
      Untuk membuat aplikasi Android, pada dasarnya orang tetap bergantung pada biner non-free milik Google
      Lihat postingan forum terkait

  • Ringkasan tautan referensi
    F-Droid admin issue
    Catima app issue
    MBCompass issue

    • Melihat thread Catima, kesan yang tertinggal sangat kuat bahwa bekerja dengan komunitas FDroid itu sangat sulit
      Salah satu anggotanya berkata: "Seperti biasa di F-Droid, suara kami selalu diabaikan. Kalau saja ada harapan bahwa dengan membahas solusi kami bisa memperbaiki F-Droid, saya tidak akan sampai menghabiskan begitu banyak waktu dan energi lalu pergi dengan rasa frustrasi"

  • Ada pendapat bahwa server F-Droid memang benar-benar sudah usang
    Sampai-sampai performanya mungkin justru akan meningkat walau x86_64 diemulasikan dari arsitektur yang sama sekali berbeda
    Bahkan rasanya tidak perlu sampai membawa argumen OSS untuk menjelaskannya
    Jika tidak terlalu peduli pada firmware tertutup, ada banyak opsi server x86 yang lebih murah sekaligus lebih modern

    • Setiap kali mendengar kalimat "servernya benar-benar tua", entah kenapa saya justru menunggu lelucon
      Gara-gara budaya populer, saya langsung teringat candaan seperti "server itu sudah sangat tua sampai pernah jadi teman sebangku TK Benjamin Franklin"