ปัญหาเซิร์ฟเวอร์บิลด์ของ F-Droid ไม่สามารถบิลด์แอป Android รุ่นใหม่ได้เนื่องจากใช้ CPU รุ่นเก่า

 (news.ycombinator.com)
1 คะแนน โดย GN⁺ 2025-08-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เซิร์ฟเวอร์บิลด์ของ F-Droid ประสบปัญหาไม่สามารถบิลด์แอป Android รุ่นใหม่ได้เนื่องจากใช้ CPU รุ่นเก่า
  • ไม่รองรับ ชุดคำสั่งขั้นสูง ที่แอปมือถือสมัยใหม่บน ARM, x86-64 และสถาปัตยกรรมอื่น ๆ ต้องการ
  • จำเป็นต้องมีการอัปเกรดและเปลี่ยนเครื่องเซิร์ฟเวอร์ แต่มีข้อจำกัดด้านงบประมาณและโครงสร้างพื้นฐาน
  • นักพัฒนาแสดงความกังวลเกี่ยวกับ ความยั่งยืน และความทันสมัยทางเทคนิคของ F-Droid
  • ขณะนี้มีการหารือถึงทางเลือกอย่าง การบิลด์บนคลาวด์ และการบริจาคทรัพยากรเซิร์ฟเวอร์

ภาพรวม

  • F-Droid เป็นสโตร์อย่างไม่เป็นทางการสำหรับแอป Android แบบโอเพนซอร์ส โดยมีโครงสร้างที่แจกจ่ายแอปผ่านการบิลด์จากซอร์สโค้ดโดยตรง
  • เมื่อไม่นานมานี้ เซิร์ฟเวอร์บิลด์ไม่รองรับชุดคำสั่ง CPU ที่ แอป Android รุ่นใหม่ ต้องใช้ ทำให้ไม่สามารถให้บริการบิลด์ของบางแอปได้อีกต่อไป

ข้อจำกัดทางเทคนิคของเซิร์ฟเวอร์บิลด์

  • คำสั่ง ARM และ x86-64 แบบใหม่ ที่จำเป็นต่อการบิลด์แอปนั้น CPU รุ่นเก่าไม่รองรับ
  • จากข้อจำกัดนี้ ทำให้เกิดปัญหาไม่สามารถจัดเตรียมไฟล์บิลด์สำหรับแอปสมัยใหม่ที่มีการ ปรับแต่งประสิทธิภาพ หรือแอปที่ใช้ไลบรารีรุ่นล่าสุดได้
  • ภาษาอย่าง Python, Kotlin และ เครื่องมือบิลด์สมัยใหม่ เช่น Gradle ก็มักต้องการสภาพแวดล้อม CPU รุ่นใหม่เช่นกัน
โฆษณา

ความกังวลและการถกเถียงในชุมชน

  • นักพัฒนาและผู้ใช้งานแสดงความกังวลต่อ คุณภาพแอปของ F-Droid ที่ลดลงอย่างต่อเนื่อง และรายงานความล้มเหลวในการบิลด์
  • แม้จำเป็นต้องอัปเกรดโครงสร้างพื้นฐาน แต่ก็มีข้อจำกัดด้าน การเงิน และการขาดแคลนบุคลากรสำหรับดูแลเซิร์ฟเวอร์

ทางเลือกและการหาแนวทางแก้ไข

  • มีการหารือถึงหลายแนวทาง เช่น การรันเซิร์ฟเวอร์บิลด์บน คลาวด์ หรือการบริจาคทรัพยากรเซิร์ฟเวอร์ในระดับชุมชน
  • ทีม F-Droid ระบุว่าตั้งใจจะแก้ปัญหาผ่านการได้รับ การสนับสนุนจากภายนอกและฮาร์ดแวร์ใหม่

บทสรุป

  • คุณค่าของ F-Droid และความสำคัญในการ สนับสนุนระบบนิเวศโอเพนซอร์ส ยังคงสูงอยู่
  • อย่างไรก็ตาม ความพยายามด้าน นวัตกรรมโครงสร้างพื้นฐานและการบำรุงรักษา ให้ทันกับเทรนด์แอปสมัยใหม่เป็นสิ่งจำเป็น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-14
ความเห็นจาก Hacker News

  • นั่นหมายความว่าเซิร์ฟเวอร์ของพวกเขาเก่ามากจริง ๆ อยู่ในระดับที่ไม่รองรับ x86-64-v2 และแทบจะทำให้นึกถึงเซิร์ฟเวอร์ยุค Intel Core 2 Duo
    แนะนำให้อ่าน บทความสรุปเกี่ยวกับระดับไมโครสถาปัตยกรรม x86-64-v2 ของ Red Hat Enterprise Linux 9
    ถ้าเปลี่ยนไปใช้ CPU ผู้บริโภคตระกูล Epyc ก็น่าจะทำให้ประสิทธิภาพเซิร์ฟเวอร์ดีขึ้นมาก
    จริง ๆ คิดว่าจะไปขอบริจาค แต่เห็นว่าเหลือเงินอยู่แล้ว $80,000
    เมื่อพิจารณาว่างบประมาณรายปีอยู่ที่ $17,000 ต่อให้ซื้อเซิร์ฟเวอร์ผู้บริโภค Epyc แบบ matx รุ่นใหม่ Zen4 หรือ Zen5 ในราคา $2,000–3,000 ก็ยังอยู่ในงบ
    ถ้ามีเซิร์ฟเวอร์เก่าหลายเครื่องจริง ๆ เซิร์ฟเวอร์ Zen5 เครื่องเดียวก็น่าจะแทนได้หลายเครื่อง และยังประหยัดไฟกับพื้นที่ได้มากกว่าเดิม
    ดู สถานะงบประมาณของ F-Droid เพิ่มเติมได้
    ดูเหมือนว่ายังไม่ได้นับเงินบริจาคจาก Librapay
    ลิงก์บริจาคผ่าน Librapay

    • ไม่จำเป็นเสมอไปว่าเซิร์ฟเวอร์จะเก่า จากประสบการณ์บนแพลตฟอร์ม virtualization ของเรา หลังจากอัปเกรด VM ของผู้ให้บริการภายนอกแล้ว ถึงจะเปิดให้ CPU แสดงการรองรับ x86_64v2 + AES แต่บางบริการก็ยังรันไม่ได้
      เพราะข้อกำหนดขั้นต่ำเขียนไว้ว่าใช้แค่ "Pentium และ Celeron" ก็เลยคิดว่าน่าจะพอ
      แต่ในความเป็นจริงมีบริการหนึ่งใช้คำสั่งที่รองรับเฉพาะบน CPU ระดับ v3 หรือ v4 เลยหยุดทำงาน
      พอเปลี่ยนการตั้งค่า exposed CPU ก็กลับมาทำงานได้ตามปกติ
      เพราะฉะนั้นตัวเซิร์ฟเวอร์เองอาจจะมีสมรรถนะพออยู่แล้ว แต่อาจเป็นการตั้งค่าผิด หรือไบนารีต้องการสเปกสูงกว่าที่ระบุไว้ หรือมีปัญหาอื่นก็ได้
    • $2,000–3,000 จริง ๆ แล้วแทบจะได้แค่ราคา CPU Threadripper รุ่นล่างแบบเปล่า ๆ และคงซื้อเซิร์ฟเวอร์ Epyc ทั้งเครื่องไม่ได้ด้วยเงินเท่านี้
    • เป็นไปได้เหมือนกันว่าเซิร์ฟเวอร์อาจบูตด้วย Coreboot หรือ Libreboot
    • ตอนนี้ก็ยังสงสัยว่า Linux ยังรองรับฮาร์ดแวร์เก่าระดับนี้อย่างเป็นทางการอยู่หรือไม่
      คำสั่ง cmpxchg16b ไม่ใช่อินสตรักชันที่ใหม่มาก และทุกวันนี้ก็ถือเป็นข้อกำหนดพื้นฐานไปแล้ว
    • ถึงจะมีเงินคงเหลือไม่มาก ก็ยังอยากแนะนำให้บริจาคอยู่ดี
      เมื่อเทียบกับเวลาและความพยายามที่อาสาสมัครใช้ไปเพื่อดูแลระบบ £80,000 ถือว่าน้อยมากจริง ๆ
      เคยได้ยินว่าจำเป็นต้อง modernize โครงสร้างพื้นฐาน แต่ก็เป็นส่วนที่ต้องลงทุนก้อนใหญ่
      ถ้ากองทุนมีความคล่องตัวมากกว่านี้ ก็น่าจะกล้าลงทุนได้มากขึ้น
      นอกจากการอัปเกรดเซิร์ฟเวอร์แล้ว ยังมีโจทย์อื่นที่ต้องแก้อีกมาก

  • สถานการณ์ตอนนี้ค่อนข้างน่ากังวล
    คิดว่า FDroid จำเป็นมาก เพราะตอนนี้น่าจะเป็น Android app store ที่ใหญ่ที่สุดรองจาก Google
    เลยสงสัยว่ามีแผนจะแก้ปัญหานี้ไหม FDroid จะอัปเกรดเซิร์ฟเวอร์เมื่อไร หรือ Google มีโอกาสถอนข้อกำหนดบังคับนี้หรือเปล่า (กรณีสุดท้ายน่าจะเป็นไปได้น้อย)

    • เมื่อคำนึงว่า FDroid เป็นโปรเจกต์ชุมชนที่ขับเคลื่อนโดยอาสาสมัคร ก็เข้าใจความกังวลนะ แต่โดยเฉพาะในประเทศ EU ที่กำลังย้ายไปใช้ซอฟต์แวร์โอเพนซอร์ส ก็อยากให้มีเงินทุนภาครัฐสนับสนุนโปรเจกต์อย่าง F-Droid ด้วย
    • ถ้า f-droid สำคัญจริง การบริจาคตรงเพื่อซื้อ build server รุ่นใหม่ก็น่าจะจำเป็น
    • เรื่องโอกาสที่ Google จะถอนข้อกำหนดนั้น ในปี 2021 ก็เคยมีปัญหาคล้ายกัน โดยตอนนั้น Gradle Plugin 4.1.0 ต้องการคำสั่ง SSSE3 จนเกิดปัญหา
      ซึ่งถูกแก้ใน Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9
      และยังมี บันทึก ticket จริง อยู่
    • ยังสงสัยกับคำกล่าวที่ว่า FDroid เป็นสโตร์ Android ที่ใหญ่ที่สุดรองจาก Google
      ส่วนตัวคิดว่าน่าจะไม่ติดแม้แต่ top 10 ด้วยซ้ำ
    • พอได้ยินคำอธิบายว่า "เครื่องมือ build ของ Google ไม่สามารถ build จาก source ได้ และมีการ optimize แยกต่างหากก่อนออกมาเป็นไบนารี" ก็ไม่เห็นด้วยกับข้อสรุปที่ว่าควรอัปเกรดเซิร์ฟเวอร์อย่างเดียว

  • สงสัยว่าทำไมไม่ build aapt2 ใหม่ให้ตรงกับ target
    source หาได้อยู่แล้ว
    ที่อยู่ source ของ aapt2

    • อยากถามว่ามีใครเคย build AOSP จริง ๆ ไหม
      ข้างในมีไบนารีจำนวนมากมาก และเคยพยายามจะ build ไบนารีบางตัวใหม่จาก source แต่ระบบ build พังหนักมากจนยอมแพ้ทันที
    • การใช้ QEMU CPU emulation ใน Docker ดูแลรักษาง่ายกว่าการคอมไพล์ aapt2 ใหม่ทีละตัวมาก
      เพราะจะรองรับการอัปเดตไบนารีในอนาคตได้อัตโนมัติ โดยไม่ต้องมาคอยแพตช์ทีละตัวทุกครั้งที่มีไบนารีใหม่ออกมา

  • ขอแชร์ เอกสารวิกิของ Streaming SIMD Extensions(SSSE3)
    เดสก์ท็อปเก่าของผมก็รองรับคำสั่งนี้ และใช้งานมาเกือบ 10 ปี
    ทั้งอย่างนั้นก็ยังน่าแปลกใจที่ใน source code กลับไม่มีแม้แต่ fallback path แบบ non-assembly ให้เลย

    • สำหรับคำถามว่า "ทำไมถึงไม่มี fallback path แม้แต่แบบ non-assembly" คิดว่าปัญหาน่าจะไม่ใช่เรื่องโค้ด assembly ที่เขียนมือ
      มีโอกาสสูงว่าคอมไพเลอร์ถูกตั้งให้คอมไพล์เป็น x86_64-v2
      RHEL 9 ก็ build ด้วยตัวเลือกแบบนี้ และใน RHEL 10 ก็จะขยับไปเป็น x86_64-v3 พร้อมรองรับ AVX ด้วย
    • ดูจาก issue แล้ว builder น่าจะเป็นตระกูล Opteron G3 (K10)
      ลิงก์วิกิ AMD 10h
    • สาเหตุที่ไม่มี fallback path ก็เพราะขาดฮาร์ดแวร์สำหรับทดสอบ
      ในทางปฏิบัติแทบไม่มีฮาร์ดแวร์ให้ทดสอบเรื่องนี้ มีแต่เครื่องเก่าและช้า
    • ถ้าใครบริจาคเดสก์ท็อปเก่าให้ FDroid ก็น่าจะถูกใจไม่น้อย

  • ยังไม่ค่อยเข้าใจทั้งหมด
    เพราะ gradle กับ aapt2 ก็เป็นโอเพนซอร์ส และถ้าสร้าง toolchain ด้วยการคอมไพล์เองแบบ buildroot หรือ openwrt ก็น่าจะได้ผลลัพธ์ที่คาดเดาได้มากกว่า
    f-droid เองถ้า build toolchain ทั้งชุดจาก source ก็ไม่จำเป็นต้องใช้ไบนารี gradle หรือ aapt2 ที่มีอินสตรักชันที่ไม่รองรับ

    • ในความเป็นจริง ยังเลี่ยงไม่ได้ที่จะต้องใช้ SDK binaries ที่ Google จัดให้
    • คิดว่าวิธีนี้สมเหตุสมผล แต่ gradle เองก็จะดาวน์โหลด dependency อย่าง Java libraries แบบ prebuilt มาใช้ด้วย
      ในจำนวนนั้นก็มีบางตัวที่มี native binary รวมอยู่ และไม่ได้มี metadata ว่าแต่ละไลบรารี build อย่างไรแบบที่ buildroot หรือ Linux distro มี
      อีกทั้งไลบรารีใน ecosystem ของ gradle ก็มีขั้นตอน build ต่างกันไปหมด (ไม่ได้ standardized) ทำให้การประกอบทุกอย่างขึ้นใหม่จาก source ทั้งหมดเป็นงานที่ยุ่งยากและลำบากมาก

  • มีคนบอกด้วยว่า Google แก้ปัญหานี้ใน upstream ไปแล้ว
    ดู ลิงก์ issue
    จะเร็วแค่ไหนยังตอบไม่ได้ แต่ถึงในเธรด issue จะไม่ได้มีหลักฐานตรง ๆ ว่าแก้แล้ว ก็ยังทำให้อุ่นใจขึ้นได้บ้าง

    • จริง ๆ แล้วยังไม่ได้ถูกแก้
      ในเธรดตามลิงก์นั้นเป็นการเข้าใจผิดว่าแก้ไขปัญหานี้แล้ว เพราะมีการแก้คำผิดจาก "mas fixed" เป็น "was fixed"
      ที่ถูกแก้คือปัญหาเก่าที่คล้ายกันเมื่อหลายปีก่อน
      ดู Google issue tracker
    • จนถึงตอนนี้ ปัญหาที่เป็นรากนี้ก็ยังไม่ค่อยเป็นที่รับรู้ในหมู่นักพัฒนา

  • เมื่อคิดว่า sse4.1 เป็นคำสั่งที่เริ่มใช้ตั้งแต่ปี 2011 ก็แปลกใจที่ยังมีเซิร์ฟเวอร์เก่าระดับนี้ทำงานอยู่
    ถ้าเป็น CPU รุ่นใหม่ก็น่าจะทำงานเดิมได้ด้วยการใช้พลังงานเพียงเศษเสี้ยว และในเชิงเศรษฐกิจก็ดูไม่สมเหตุสมผลที่จะใช้ฮาร์ดแวร์เก่าต่อไป
    เลยสงสัยว่ามีใครรู้บ้างไหมว่า build server มีทั้งหมดกี่เครื่องและสเปกเป็นอย่างไร

    • สำหรับความเห็นที่ว่าควรรีบอัปเกรดเพราะ CPU รุ่นใหม่ใช้ค่าไฟน้อยกว่ามากนั้น ใน 8,760 ชั่วโมงต่อปี ต่อให้ CPU ระดับ 500W ทำงานเต็มที่ตลอดทั้งปี ค่าไฟก็อยู่ที่ $550
      ต่อให้ลดลงครึ่งหนึ่งก็ยังเท่ากับแค่ 10% ของราคาเครื่องใหม่ ต้องใช้เวลา 10 ปีกว่าจะคุ้มทุน
      แถมการอัปเกรดเป็นรายจ่ายลงทุน แต่ค่าไฟเป็นค่าใช้จ่ายดำเนินงาน
      ข้อมูลอ้างอิงค่าไฟในสหรัฐฯ
    • sse4.1 ถูกนำมาใช้ครั้งแรกใน Intel Penryn เมื่อเดือนพฤศจิกายน 2007 และ AMD ก็ยังไม่รองรับจนถึง Bulldozer (กลางปี 2011)
      แม้ Bulldozer จะมีคำสั่งเพิ่มหลายอย่าง (AVX, FMA ฯลฯ) แต่ Opteron รุ่นเดิมหลายครั้งก็ยังเร็วกว่า Bulldozer จริง ทำให้ก่อน Epyc จะออก (กลางปี 2017) แรงจูงใจในการอัปเกรดไม่ได้สูงมาก
      เหตุผลที่หลายแพ็กเกจเริ่มขยับไปใช้ sse4.1 ขึ้นไป ก็เพราะบน CPU เก่า overhead ของการประมวลผล SIMD แบบมีเงื่อนไขแตกแขนงนั้นสูง
    • คำตอบจริงอาจเป็นแค่ว่า "เพราะยังใช้บอร์ด AMD แบบ dual-socket ที่เป็น open firmware และไม่มี ME/PSP (เช่น KGPE-D16) ได้"
    • ฝั่งเซิร์ฟเวอร์อาจไม่แน่ใจ แต่ในโลกเดสก์ท็อปยังเห็นฮาร์ดแวร์เก่าถูกใช้อยู่บ่อย
      PC เก่าจากยุค 2000 เคยเพียงพอกับงานทั่วไปอย่างการท่องเว็บ แต่เมื่อเวลาผ่านไปโปรแกรมต่าง ๆ เริ่มต้องการชุดคำสั่งใหม่ ก็เลยค่อย ๆ ใช้งานไม่ได้
      แม้แต่ Firefox เองก็ยังเริ่มต้องการ instruction set ใหม่ จนสุดท้ายต้องทิ้งเดสก์ท็อปที่ยังใช้งานได้ดี
    • คิดว่าเหตุผลที่ยังใช้ CPU เก่าอาจเกี่ยวกับเฟิร์มแวร์เสรีอย่าง Canoeboot หรือ GNU Boot
      แต่บอร์ด KGPE-D16 ก็ใส่ CPU ที่รองรับ SSE4.2 ได้เหมือนกัน เลยไม่แน่ใจว่าเหตุผลจริงคืออะไร

  • พูดถึง aapt2 binary ตัวใหม่ของ Google (AGP 8.12.0) แล้วรู้สึกแปลกใจว่า F-Droid เป็นโปรเจกต์ที่ใส่ใจเรื่องการปกป้องและแยกสภาพแวดล้อม build มาก แต่ทำไมกลับไปใช้ upstream binaries แทนที่จะ build จาก source

    • ในประเด็นนี้ จนกระทั่งไม่นานมานี้ก็ยังไม่มี free software build ของ Android SDK ที่อัปเดตทันสมัย
      การสร้างแอป Android จึงแทบหลีกเลี่ยงไม่ได้ที่จะต้องพึ่งพาไบนารี non-free ของ Google
      ดู โพสต์ในฟอรัมที่เกี่ยวข้อง

  • รวมลิงก์อ้างอิงไว้
    F-Droid admin issue
    issue ของแอป Catima
    issue ของ MBCompass

    • พออ่านเธรดของ Catima แล้ว ให้ความรู้สึกแรงมากว่าการทำงานกับชุมชน FDroid นั้นยากมาก
      มีสมาชิกคนหนึ่งพูดไว้ว่า: "เหมือนที่เป็นกับ F-Droid เสมอมา เสียงของพวกเราถูกเมินเฉยตลอด ถ้ามีความหวังจริงว่าการถกกันเรื่องทางออกจะช่วยปรับปรุง F-Droid ได้ เราคงไม่ต้องทุ่มเวลาและพลังไปมากมายแล้วสุดท้ายหมดกำลังใจจนจากไป"

  • มีความเห็นว่าเซิร์ฟเวอร์ของ F-Droid เก่ามากจริง ๆ
    ถึงขั้นที่แม้จะ emulation x86_64 บนสถาปัตยกรรมคนละแบบ ก็น่าจะยังเร็วกว่า
    แทบไม่จำเป็นต้องหยิบเหตุผลเชิง OSS มาอ้างเลย
    ถ้าไม่กังวลเรื่องเฟิร์มแวร์ปิด ก็ยังมีตัวเลือกเซิร์ฟเวอร์ x86 รุ่นใหม่ที่ถูกกว่าอีกมาก

    • พอได้ยินคำว่า "เซิร์ฟเวอร์เก่ามากจริง ๆ" ก็แอบคาดหวังมุกตลกขึ้นมา
      อิทธิพลจากวัฒนธรรมป๊อปทำให้นึกถึงมุกแนว "เซิร์ฟเวอร์เครื่องนี้เก่าจนเป็นเพื่อนร่วมห้องอนุบาลกับ Benjamin Franklin"