Máy chủ build của F-Droid không thể build ứng dụng Android mới do CPU quá cũ
(news.ycombinator.com)- Máy chủ build của F-Droid đang rơi vào tình trạng không thể build các ứng dụng Android mới do sử dụng CPU đời cũ
- Không hỗ trợ được các tập lệnh nâng cao mà các ứng dụng di động hiện đại trên ARM, x86-64 yêu cầu
- Cần nâng cấp và thay thế máy chủ, nhưng bị giới hạn bởi chi phí và hạ tầng
- Các nhà phát triển bày tỏ lo ngại về tính bền vững và mức độ cập nhật công nghệ của F-Droid
- Hiện đang thảo luận các phương án như build dựa trên đám mây và quyên góp tài nguyên máy chủ
Tổng quan
- F-Droid là một kho ứng dụng không chính thức dành cho các ứng dụng Android mã nguồn mở, hoạt động theo mô hình tự build trực tiếp từ mã nguồn rồi phân phối ứng dụng
- Gần đây, máy chủ build không còn hỗ trợ các tập lệnh CPU mà các ứng dụng Android hiện đại yêu cầu, khiến một số ứng dụng không thể tiếp tục được cung cấp bản build
Giới hạn kỹ thuật của máy chủ build
- Các lệnh ARM và x86-64 mới cần cho việc build ứng dụng không được CPU cũ hỗ trợ
- Vì hạn chế này, xuất hiện vấn đề không thể cung cấp các tệp build cho những ứng dụng hiện đại đã được tối ưu hiệu năng hoặc sử dụng các thư viện mới nhất
- Các ngôn ngữ hiện đại như Python, Kotlin và các công cụ build mới như Gradle cũng thường yêu cầu môi trường CPU mới hơn
Lo ngại và thảo luận trong cộng đồng
- Các nhà phát triển và người dùng bày tỏ lo ngại về sự suy giảm chất lượng ứng dụng liên tục và các báo cáo build thất bại của F-Droid
- Hạ tầng cần được nâng cấp, nhưng nổi bật lên các vấn đề về giới hạn tài chính và thiếu nhân lực quản trị máy chủ
Tìm kiếm phương án thay thế và giải pháp
- Nhiều phương án đang được thảo luận như vận hành máy chủ build trong môi trường đám mây hoặc cộng đồng quyên góp tài nguyên máy chủ
- Nhóm F-Droid cho biết họ quyết tâm giải quyết vấn đề bằng cách tìm kiếm hỗ trợ bên ngoài và phần cứng mới
Kết luận
- Giá trị của F-Droid và ý nghĩa của việc hỗ trợ hệ sinh thái mã nguồn mở vẫn rất lớn
- Tuy vậy, những nỗ lực về đổi mới hạ tầng và bảo trì phù hợp với xu hướng ứng dụng hiện đại là điều bắt buộc
1 bình luận
Ý kiến trên Hacker News
Điều này có nghĩa là máy chủ của họ thực sự rất cũ, ở mức còn không hỗ trợ x86-64-v2, gần như gợi nhớ tới những máy chủ thời Intel Core 2 Duo
Hãy xem bài viết tổng hợp về mức vi kiến trúc x86-64-v2 của Red Hat Enterprise Linux 9
Nếu chuyển sang CPU Epyc dòng tiêu dùng thì hiệu năng máy chủ có lẽ sẽ nhanh hơn rất nhiều
Tôi định kêu gọi quyên góp, nhưng hóa ra họ vẫn còn $80,000
Xét ngân sách hằng năm là $17,000, ngay cả khi mua một máy chủ Epyc dòng tiêu dùng matx Zen4 hoặc Zen5 hiện đại với giá 2~3 nghìn đô thì vẫn nằm trong ngân sách
Nếu thực sự có nhiều máy chủ đã quá cũ, thì một máy chủ Zen5 có thể thay thế được vài máy, đồng thời tiết kiệm điện và không gian hơn rất nhiều
Cũng tham khảo tình trạng ngân sách của F-Droid
Có vẻ các khoản quyên góp qua Librapay vẫn chưa được tính vào
Liên kết quyên góp Librapay
Yêu cầu tối thiểu chỉ là "Pentium và Celeron" nên chúng tôi nghĩ là đủ
Nhưng thực tế một trong các dịch vụ đã dùng những lệnh chỉ được hỗ trợ trên CPU v3 hoặc v4 nên đã ngừng hoạt động
Sau khi đổi thiết lập CPU được expose thì nó chạy bình thường
Vì vậy cũng có thể bản thân máy chủ thật ra vẫn đủ năng lực, nhưng bị cấu hình sai, hoặc binary yêu cầu cấu hình cao hơn mức công bố, hoặc là một vấn đề khác
Lệnh cmpxchg16b không phải là instruction quá mới, và hiện nay được xem là yêu cầu bắt buộc
So với thời gian và công sức mà các tình nguyện viên bỏ ra để duy trì hệ thống, £80,000 thực sự là số tiền rất nhỏ
Tôi có nghe rằng hạ tầng cần được hiện đại hóa, nhưng đó là hạng mục đòi hỏi đầu tư lớn
Nếu quỹ dồi dào hơn, có lẽ họ đã có thể đầu tư tự tin hơn
Ngoài việc nâng cấp máy chủ, vẫn còn nhiều bài toán khác cần giải quyết
Tình hình hiện tại khá đáng lo
Tôi nghĩ F-Droid là cửa hàng ứng dụng Android lớn nhất ngoài Google ở thời điểm này, nên lại càng cần thiết hơn
Tôi tò mò không biết có kế hoạch nào để giải quyết vấn đề này hay không, F-Droid sẽ nâng cấp máy chủ vào lúc nào, hoặc liệu Google có khả năng rút lại yêu cầu bắt buộc này không (trường hợp cuối cùng thì tôi nghĩ là khó)
Vấn đề đó đã được sửa trong Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9
Bản ghi ticket thực tế vẫn còn
Cá nhân tôi nghĩ nó còn không vào nổi top 10
Tôi thắc mắc tại sao họ không build lại aapt2 cho đúng mục tiêu
Có thể lấy được source
Vị trí source của aapt2
Có rất nhiều binary trong đó, và khi tôi thử build lại vài binary từ source, hệ thống build rối tung đến mức tôi bỏ cuộc ngay
Cách đó còn có thể tự động thích ứng với các bản cập nhật binary về sau mà không phải vá lại từng binary mới phát sinh
Chia sẻ bài viết Wikipedia về Streaming SIMD Extensions(SSSE3)
Ngay cả máy desktop cũ của tôi cũng hỗ trợ tập lệnh này, và tôi đã dùng nó gần 10 năm
Vậy mà vẫn gây ngạc nhiên khi trong source code lại không có cả đường dự phòng không dùng assembly
Khả năng cao là trình biên dịch đã được chỉ định build cho x86_64-v2
RHEL 9 cũng build với tùy chọn kiểu này, còn RHEL 10 thì nâng lên x86_64-v3 và có thêm hỗ trợ AVX
Liên kết Wikipedia AMD 10h
Trên thực tế không có phần cứng phù hợp để test việc này, chỉ toàn là thiết bị cũ và chậm
Tôi không hoàn toàn hiểu
gradle và aapt2 đều là mã nguồn mở, và giống như buildroot hay openwrt, nếu tự biên dịch để tạo toolchain thì sẽ cho kết quả dễ dự đoán hơn
f-droid cũng vậy, nếu tự build toàn bộ toolchain từ source thì sẽ không cần dùng các binary gradle hay aapt2 có instruction không được hỗ trợ
Trong số đó có cả native binary, và không có metadata về cách từng thư viện được build như kiểu buildroot hay các bản phân phối Linux
Thêm nữa, quy trình build của mỗi thư viện trong hệ sinh thái gradle lại khác nhau (không được tiêu chuẩn hóa), nên việc tái dựng toàn bộ trực tiếp từ source là công việc khá phiền phức và khó khăn
Cũng có ý kiến cho rằng Google đã sửa vấn đề này ở upstream rồi
Xem liên kết issue
Không thể chắc nó sẽ được giải quyết nhanh đến đâu, nhưng thread issue này vẫn tạo cảm giác yên tâm phần nào dù không có bằng chứng trực tiếp rằng nó đã được sửa
Trong thread ở liên kết trên, người ta đã hiểu nhầm việc sửa lỗi chính tả ("mas fixed"→"was fixed") thành việc issue lần này đã được giải quyết
Cái đã được sửa là một issue tương tự từ vài năm trước
Xem Google issue tracker
Xét việc sse4.1 là tập lệnh được đưa vào từ năm 2011, thật khó hiểu khi những máy chủ cũ như vậy vẫn còn đang hoạt động
CPU hiện đại có thể xử lý cùng công việc đó chỉ với một phần nhỏ điện năng tiêu thụ, nên về mặt kinh tế tôi cũng không hiểu tại sao lại tiếp tục dùng phần cứng cũ
Có ai biết số lượng hay cấu hình của các máy chủ build không
Dù giảm một nửa thì cũng chỉ bằng 10% giá một máy mới, tức phải mất 10 năm mới hoàn vốn
Hơn nữa nâng cấp là chi tiêu vốn, còn tiền điện là chi phí vận hành
Nguồn dữ liệu giá điện ở Mỹ
Bulldozer có thêm nhiều tập lệnh như AVX, FMA..., nhưng Opteron cũ trong nhiều trường hợp lại nhanh hơn Bulldozer, nên cho tới khi Epyc ra mắt (giữa 2017) vẫn không có nhiều động lực để nâng cấp
Lý do nhiều package chuyển sang yêu cầu sse4.1 trở lên là vì trên CPU cũ, chi phí phụ như rẽ nhánh điều kiện khi xử lý song song SIMD là khá cao
PC đời 2000 từng đủ dùng cho các tác vụ thông thường như duyệt web, nhưng theo thời gian, phần mềm bắt đầu yêu cầu các tập lệnh mới nên dần trở nên vô dụng
Ngay cả Firefox cuối cùng cũng bắt đầu yêu cầu tập lệnh mới, và tôi đã từng phải bỏ đi một chiếc desktop vẫn hoạt động bình thường chỉ vì vậy
Nhưng bo mạch KGPE-D16 vẫn có thể gắn CPU hỗ trợ SSE4.2, nên tôi cũng không rõ nguyên nhân chính xác là gì
Khi nhắc tới binary aapt2 mới của Google (AGP 8.12.0), tôi thấy khá bất ngờ vì F-Droid là dự án cực kỳ chú trọng việc bảo vệ và cô lập môi trường build, vậy mà lại dùng binary upstream thay vì build từ source ngay từ đầu
Muốn tạo ứng dụng Android thì về cơ bản vẫn phải phụ thuộc vào các binary không tự do do Google cung cấp
Xem bài viết trên diễn đàn liên quan
Tổng hợp các liên kết tham khảo
F-Droid admin issue
Issue của ứng dụng Catima
Issue của MBCompass
Một thành viên đã nói như sau: "Như vẫn luôn xảy ra ở F-Droid, tiếng nói của chúng tôi luôn bị phớt lờ. Nếu chúng tôi có hy vọng rằng việc thảo luận giải pháp có thể cải thiện F-Droid, thì chúng tôi đã không phải bỏ ra ngần ấy thời gian và năng lượng rồi cuối cùng thất vọng rời đi"
Ý kiến cho rằng máy chủ F-Droid thực sự đã quá cũ
Thậm chí giả lập x86_64 trên một kiến trúc hoàn toàn khác còn có thể cho hiệu năng tốt hơn
Thậm chí không cần viện dẫn lập luận kiểu OSS cũng đủ thấy vậy
Nếu không quá quan tâm tới firmware đóng, thì vẫn có nhiều lựa chọn máy chủ x86 hiện đại rẻ hơn
Nhờ văn hóa đại chúng mà tôi lập tức nghĩ tới mấy câu kiểu "máy chủ này già tới mức từng ngồi cùng bàn mẫu giáo với Benjamin Franklin"