पुराने CPU के कारण F-Droid build server नवीनतम Android ऐप्स को build नहीं कर पा रहा

 (news.ycombinator.com)
1 पॉइंट द्वारा GN⁺ 2025-08-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • F-Droid build server पुराने CPU के कारण नवीनतम Android ऐप्स को build नहीं कर पा रहा है
  • यह ARM, x86-64 आदि आधुनिक mobile apps में आवश्यक advanced instruction sets को support नहीं करता
  • server के upgrade और replacement की ज़रूरत है, लेकिन लागत और infrastructure की सीमाएँ मौजूद हैं
  • developers ने F-Droid की sustainability और तकनीकी रूप से up-to-date बने रहने को लेकर चिंता जताई है
  • विकल्प के रूप में cloud-based build और server resources donation पर चर्चा चल रही है

अवलोकन

  • F-Droid Android open source apps के लिए एक अनौपचारिक store है, जो source code को सीधे build करके apps वितरित करता है
  • हाल ही में build server नवीनतम Android apps द्वारा आवश्यक CPU instruction sets को support नहीं कर पा रहा, इसलिए अब कुछ apps के builds उपलब्ध कराना संभव नहीं रहा

build server की तकनीकी सीमाएँ

  • app build के लिए आवश्यक नए ARM और x86-64 instructions पुराने CPU support नहीं करते
  • इस सीमा के कारण performance optimization वाले आधुनिक apps या नवीनतम libraries का उपयोग करने वाले apps के build files उपलब्ध कराने में समस्या हो रही है
  • Python, Kotlin जैसी आधुनिक भाषाएँ और Gradle जैसे नवीनतम build tools भी अक्सर नए CPU environment की माँग करते हैं

समुदाय के भीतर चिंताएँ और चर्चा

  • developers और users ने F-Droid में लगातार app quality गिरने और build failure reports को लेकर चिंता जताई है
  • infrastructure upgrade की ज़रूरत है, लेकिन वित्तीय सीमाएँ और server management staff की कमी जैसे मुद्दे सामने आए हैं

विकल्प और समाधान की तलाश

  • cloud environment में build server चलाने या community स्तर पर server resources donation जैसे कई विकल्पों पर चर्चा हो रही है
  • F-Droid टीम ने बाहरी समर्थन और नए hardware की मदद से इस समस्या को हल करने की इच्छा जताई है

निष्कर्ष

  • F-Droid का महत्व और open source ecosystem support में उसकी भूमिका अब भी बहुत बड़ी है
  • लेकिन आधुनिक app trends के अनुरूप infrastructure innovation और maintenance के प्रयास अनिवार्य हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-14
Hacker News टिप्पणियाँ

  • इसका मतलब है कि उनके सर्वर सच में बहुत पुराने हैं, इतने कि x86-64-v2 भी सपोर्ट नहीं करते; इससे लगभग Intel Core 2 Duo दौर के सर्वरों की याद आती है
    Red Hat Enterprise Linux 9 के x86-64-v2 माइक्रोआर्किटेक्चर लेवल पर एक व्यवस्थित लेख देखा जा सकता है
    अगर इन्हें Epyc consumer CPU से बदला जाए तो सर्वर परफॉर्मेंस काफी तेज हो जाएगी
    मैंने वास्तव में दान की अपील करने का सोचा था, लेकिन वहाँ पहले से ही $80,000 बचे हुए थे
    सालाना बजट $17,000 होने को देखते हुए, $2~3 हज़ार में एक आधुनिक Zen4 या Zen5 matx consumer Epyc सर्वर खरीदा जाए तो भी वह बजट के भीतर रहेगा
    अगर सच में कई पुराने सर्वर हैं, तो एक Zen5 सर्वर से उनमें से कई को बदला जा सकता है, और बिजली व जगह दोनों की अच्छी बचत होगी
    F-Droid की बजट स्थिति भी देखी जा सकती है
    लगता है Librapay दान अभी इसमें शामिल नहीं है
    Librapay दान लिंक

    • ज़रूरी नहीं कि सिर्फ सर्वर ही पुराने हों; हमारे virtualization platform के अनुभव में, एक बाहरी vendor के VM को upgrade करने के बाद CPU में x86_64v2 + AES सपोर्ट एक्सपोज़ किया गया था, फिर भी कुछ services चल नहीं पाईं
      न्यूनतम आवश्यकता "Pentium और Celeron" बताई गई थी, इसलिए हमने सोचा कि यह पर्याप्त होगा
      लेकिन असल में services में से एक v3 या v4 CPU पर ही उपलब्ध instruction इस्तेमाल कर रही थी, इसलिए वह रुक गई
      exposed CPU setting बदलते ही वह सामान्य रूप से चलने लगी
      इसलिए संभव है कि सर्वर खुद पर्याप्त सक्षम हों, लेकिन configuration की गलती हो; या binary घोषित स्पेसिफिकेशन से ऊँची requirement मांग रही हो; या कोई और issue हो
    • $2~3 हज़ार में वास्तव में सिर्फ निचले स्तर के Threadripper boxed CPU की कीमत आती है; इस पैसे में पूरा Epyc सर्वर खरीदना मुश्किल होगा
    • यह भी हो सकता है कि सर्वर Coreboot या Libreboot से boot हो रहे हों
    • मुझे यह भी संदेह है कि इस समय Linux आधिकारिक रूप से इतने पुराने hardware को अब भी सपोर्ट कर रहा है या नहीं
      cmpxchg16b instruction इतना भी पुराना नहीं है, और अब इसे लगभग अनिवार्य requirement माना जाता है
    • भले ही बची हुई रकम कम लगे, फिर भी मैं दान करने की सलाह दूँगा
      volunteers जो समय और मेहनत सिस्टम को बनाए रखने में लगाते हैं, उसके मुकाबले £80,000 सच में बहुत कम रकम है
      सुना है कि infrastructure modernization की ज़रूरत है, लेकिन यह बड़े निवेश का मामला है
      अगर फंडिंग थोड़ी अधिक आरामदायक होती, तो शायद वे अधिक आत्मविश्वास से निवेश कर पाते
      सर्वर upgrade के अलावा भी कई समस्याएँ हैं जिन्हें हल करना है

  • मौजूदा स्थिति काफी चिंताजनक लगती है
    F-Droid अभी Google को छोड़कर सबसे बड़े Android app stores में से एक है, इसलिए यह और भी ज़रूरी लगता है
    जानना चाहूँगा कि क्या इस समस्या को हल करने की कोई योजना है, F-Droid सर्वर कब upgrade करेगा, या क्या Google इस अनिवार्य requirement को वापस ले सकता है (आख़िरी संभावना मुझे कम लगती है)

    • यह समझ में आता है कि लोग चिंतित हैं, लेकिन यह देखते हुए कि F-Droid volunteers द्वारा चलाया जाने वाला community project है, खासकर जब EU देश open source software की ओर बढ़ रहे हैं, तो अच्छा होगा अगर F-Droid जैसे projects को सार्वजनिक फंडिंग मिले
    • अगर f-droid महत्वपूर्ण है, तो नया build server खरीदने के लिए सीधे दान करना भी ज़रूरी है
    • Google के requirement वापस लेने की संभावना पर, 2021 में भी ऐसा ही issue था; उस समय Gradle Plugin 4.1.0 को SSSE3 instruction की ज़रूरत थी, जिससे समस्या हुई थी
      वह issue Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9 में ठीक किया गया था
      उसका असली ticket record भी मौजूद है
    • मुझे इस दावे पर संदेह है कि FDroid, Google को छोड़कर सबसे बड़ा Android store है
      व्यक्तिगत रूप से मुझे नहीं लगता कि वह top 10 में भी होगा
    • "Google build tools source build के लिए नहीं हैं; वे अलग optimization के साथ binary के रूप में जारी किए गए हैं" — यह सुनकर मैं इस निष्कर्ष से सहमत नहीं हूँ कि इसलिए सर्वर upgrade करना ही सही रास्ता है

  • समझ नहीं आता कि aapt2 को target के मुताबिक फिर से build क्यों नहीं किया जाता
    source उपलब्ध है
    aapt2 source location

    • पूछना चाहूँगा कि क्या आपने कभी वास्तव में AOSP build किया है
      इसमें बहुत बड़ी संख्या में binaries शामिल होती हैं, और मैंने कुछ binaries को source से दोबारा build करने की कोशिश की थी, लेकिन build system इतना बुरी तरह टूटा हुआ था कि मैंने तुरंत छोड़ दिया
    • Docker में QEMU CPU emulation इस्तेमाल करना, हर बार aapt2 को दोबारा compile करने की तुलना में maintenance के लिहाज़ से कहीं आसान है
      आगे आने वाली हर binary के लिए अलग patch नहीं लगाना पड़ेगा, और binary updates अपने-आप संभाली जा सकेंगी

  • Streaming SIMD Extensions(SSSE3) wiki लेख साझा कर रहा हूँ
    मेरा पुराना desktop भी इस instruction को सपोर्ट करता था, और मैंने उसे लगभग 10 साल इस्तेमाल किया था
    फिर भी यह हैरानी की बात है कि source code में backup path के रूप में भी assembly नहीं दी गई

    • "assembly में भी backup path नहीं है, यह अजीब है" — इस पर मेरा अनुमान है कि यह handwritten assembly code की समस्या नहीं होगी
      अधिक संभावना है कि compiler ने x86_64-v2 target करके compile किया हो
      RHEL 9 भी इसी तरह के option के साथ build किया गया था, और RHEL 10 में यह x86_64-v3 तक बढ़ रहा है, जिससे AVX भी सपोर्ट होगा
    • issue देखने पर लगता है कि builder Opteron G3 (K10) family का है
      AMD 10h wiki link
    • backup path न देने की समस्या शायद test hardware की कमी की वजह से है
      व्यवहारिक रूप से इसे test करने लायक hardware उपलब्ध नहीं है; जो है वह सब बहुत पुराना और धीमा है
    • अगर कोई पुराना desktop donate करे, तो FDroid शायद खुश होगा

  • मैं इसे पूरी तरह नहीं समझ पा रहा
    gradle और aapt2 open source हैं, और buildroot या openwrt की तरह अगर toolchain खुद compile किया जाए तो नतीजे ज़्यादा predictable होंगे
    f-droid भी अगर पूरा toolchain source से खुद build करे, तो unsupported instructions वाली binary gradle या aapt2 पर निर्भर रहने की ज़रूरत नहीं पड़ेगी

    • व्यवहार में अब भी Google द्वारा दिए गए SDK binaries का इस्तेमाल करना पड़ता है
    • मुझे यह तरीका उचित लगता है, लेकिन gradle खुद prebuilt Java libraries जैसी dependencies download करके इस्तेमाल करता है
      इनमें कुछ native binaries भी होती हैं, और buildroot या Linux distributions की तरह यह metadata नहीं होता कि हर library कैसे build की गई
      इसके अलावा gradle ecosystem की हर library का build process अलग-अलग होता है (यानी standardized नहीं), इसलिए पूरे stack को source से दोबारा बनाना काफी झंझटभरा और कठिन काम है

  • कुछ लोग कह रहे हैं कि Google ने upstream में यह समस्या पहले ही ठीक कर दी है
    issue link देखें
    यह कितनी जल्दी हल होगा, कहना मुश्किल है, लेकिन issue thread कुछ हद तक भरोसा देता है, भले ही प्रत्यक्ष प्रमाण न हो कि यह सचमुच fix हो चुका है

    • वास्तव में यह अभी fix नहीं हुआ है
      ऊपर लिंक किए गए thread में टाइपो सुधार ("mas fixed"→"was fixed") को गलती से इस issue के समाधान के रूप में समझ लिया गया
      जो fix हुआ था, वह कई साल पहले का मिलता-जुलता पुराना issue था
      Google issue tracker देखें
    • अब तक भी यह मूल समस्या developers के बीच ज़्यादा जानी-पहचानी नहीं है

  • अगर sse4.1 को 2011 में आई instruction मानें, तो यह हैरानी की बात है कि ऐसे पुराने सर्वर अब भी चल रहे हैं
    आधुनिक CPU वही काम बहुत कम बिजली में कर सकते हैं, इसलिए आर्थिक रूप से भी इतना पुराना hardware चलाते रहना समझ से परे है
    क्या किसी को build servers की संख्या या specs के बारे में जानकारी है

    • इस राय के जवाब में कि नए CPU वही काम बहुत कम बिजली में कर सकते हैं इसलिए जल्दी upgrade करना चाहिए: साल के 8,760 घंटों में अगर 500W का CPU पूरे साल full load पर भी चले, तो बिजली का बिल लगभग $550 होगा
      उसे आधा कर देने पर भी वह नई मशीन की कीमत का सिर्फ 10% होगा, यानी लागत वसूलने में 10 साल लगेंगे
      upgrade एक capital expenditure है, जबकि बिजली का बिल operating cost है
      अमेरिकी बिजली दरों का संदर्भ
    • sse4.1 को Intel Penryn ने पहली बार नवंबर 2007 में पेश किया था, और AMD ने इसे Bulldozer (2011 के मध्य) तक सपोर्ट नहीं किया
      Bulldozer में AVX, FMA जैसी कई नई instructions थीं, लेकिन कई मामलों में पुराने Opteron वास्तव में Bulldozer से तेज़ थे; इसलिए Epyc (2017 के मध्य) आने तक upgrade का आकर्षण कम था
      कई packages में sse4.1 या उससे ऊपर की ज़रूरत पड़ने का एक कारण यह भी है कि बहुत पुराने CPU पर conditional branching आदि के साथ SIMD parallelism का overhead काफ़ी अधिक होता है
    • असली जवाब यह हो सकता है कि "open firmware और ME/PSP के बिना dual-socket AMD boards (जैसे KGPE-D16) इस्तेमाल किए जा सकते हैं"
    • सर्वर के बारे में तो ज़्यादा नहीं जानता, लेकिन desktop दुनिया में पुराना hardware वाकई अक्सर दिख जाता है
      2000 के दशक के पुराने PC सामान्य कामों (जैसे web browsing) के लिए लंबे समय तक पर्याप्त थे, लेकिन समय के साथ programs ने नई instructions माँगनी शुरू कर दीं, और वे धीरे-धीरे बेकार होते गए
      यहाँ तक कि Firefox ने भी नया instruction set माँगना शुरू कर दिया, और अंत में मुझे ठीक-ठाक चल रहे desktop को छोड़ना पड़ा
    • मुझे लगता है कि पुराने CPU इस्तेमाल करने की वजह Canoeboot, GNU Boot जैसे free firmware हो सकते हैं
      लेकिन KGPE-D16 board में SSE4.2 सपोर्ट करने वाले CPU भी लगाए जा सकते हैं, इसलिए असली वजह क्या है, यह स्पष्ट नहीं है

  • Google के नए aapt2 binary (AGP 8.12.0) की बात करते हुए, यह थोड़ा अजीब लगता है कि F-Droid build environment की सुरक्षा और isolation पर इतना ध्यान देता है, लेकिन फिर भी upstream binaries उठा कर इस्तेमाल करता है, source से build नहीं करता

    • इस संदर्भ में, अपेक्षाकृत हाल तक भी Android SDK के free software builds का कोई up-to-date संस्करण उपलब्ध नहीं था
      Android apps बनाने के लिए मूल रूप से Google के non-free binaries पर निर्भर रहना पड़ता है
      संबंधित forum post देखें

  • संदर्भ के लिए links की सूची
    F-Droid admin issue
    Catima app issue
    MBCompass issue

    • Catima thread पढ़ने पर यह मजबूत impression बनता है कि FDroid community के साथ काम करना काफ़ी मुश्किल है
      एक member ने कहा: "F-Droid में हमेशा की तरह, हमारी आवाज़ें हमेशा नज़रअंदाज़ की जाती हैं। अगर उम्मीद होती कि समाधान पर चर्चा करके F-Droid को बेहतर बनाया जा सकता है, तो हम इतना समय और ऊर्जा लगाने के बाद निराश होकर छोड़कर नहीं जाते।"

  • राय यह है कि F-Droid सर्वर सच में बहुत पुराने हैं
    यहाँ तक कि किसी पूरी तरह अलग architecture पर x86_64 emulate करने पर भी शायद performance बेहतर मिल जाए
    इस पर open source तर्क लाने की भी ज़रूरत नहीं है
    अगर closed firmware की चिंता न हो, तो इससे सस्ते और आधुनिक x86 server options भी बहुत हैं

    • "सर्वर सच में बहुत पुराने हैं" सुनते ही न जाने क्यों मज़ाक की उम्मीद होने लगती है
      pop culture की वजह से "सर्वर इतने पुराने हैं कि वे Benjamin Franklin के kindergarten benchmate थे" जैसा चुटकुला याद आता है