F-Droidのビルドサーバーが旧型CPUのため最新Androidアプリをビルドできない問題
(news.ycombinator.com)- F-Droidのビルドサーバーが旧型CPUのため、最新のAndroidアプリをビルドできない状況が発生
- ARM、x86-64など最新のモバイルアプリで求められる高度な命令セットをサポートできない
- サーバーのアップグレードおよび交換が必要だが、コストやインフラの制約がある
- 開発者たちはF-Droidの持続可能性と技術的な最新性について懸念を表明
- 代替案として、クラウドベースのビルドやサーバー資源の寄付が議論されている
概要
- F-DroidはAndroidオープンソースアプリの非公式ストアで、ソースコードを直接ビルドしてアプリを配布する仕組み
- 最近、ビルドサーバーが最新のAndroidアプリで必要とされるCPU命令セットをサポートできず、一部アプリのビルド提供ができなくなった
ビルドサーバーの技術的限界
- アプリのビルドに必要な新しいARMおよびx86-64命令を旧型CPUがサポートできない
- この制約により、性能最適化された現代的なアプリや最新ライブラリを採用したアプリのビルド成果物を提供できない問題が発生
- PythonやKotlinのような最新言語、Gradleなどの最新ビルドツールも、しばしば新しいCPU環境を要求する
コミュニティ内の懸念と議論
- 開発者と利用者は、F-Droidにおける継続的なアプリ品質の低下やビルド失敗の報告について懸念を表明
- インフラのアップグレードが必要だが、財政的制約とサーバー管理人員の不足が問題として浮上
代替案と解決策の模索
- クラウド環境でビルドサーバーを運用することや、コミュニティによるサーバー資源の寄付など、さまざまな案が議論されている
- F-Droidチームは、外部支援と新しいハードウェアの確保を通じて問題を解決する意向を示した
結論
- F-Droidの価値とオープンソース生態系の支援という意義は依然として高い
- ただし、現代のアプリトレンドに合ったインフラ面の刷新と保守運用の取り組みが不可欠
1件のコメント
Hacker Newsの意見
これは彼らのサーバーが本当にかなり古いことを意味している。x86-64-v2をサポートしていないレベルで、ほぼ Intel Core 2 Duo 時代のサーバーを連想させる
Red Hat Enterprise Linux 9のx86-64-v2マイクロアーキテクチャレベルについて整理した記事を参照
Epyc のコンシューマーCPUに替えれば、サーバー性能はかなり速くなるはず
実際に寄付をしようと思ったが、すでに$80,000残っていた
年間予算が$17,000であることを考えると、2〜3千ドルで最新のZen4またはZen5 mATXコンシューマーEpycサーバーを購入しても予算内に収まる
もし本当に老朽化したサーバーが何台もあるなら、Zen5サーバー1台で数台を置き換えられるし、電力とスペースも大きく節約できるはず
F-Droidの予算状況も参照
Librapay の寄付金はまだ含まれていないようだ
Librapay寄付関連リンク
最低要件は「PentiumとCeleron」だったので十分だと思っていた
ところが実際には、サービスの1つが v3 または v4 CPUでのみサポートされる命令を使っていて停止した
公開CPU設定を変えたら正常に動作した
なので、サーバー自体は実際には十分な性能があるものの設定ミスだったり、あるいはバイナリが明示されているより高い仕様を要求していたり、ほかの問題かもしれない
cmpxchg16b 命令はそこまで新しい命令ではなく、現在では必須仕様と見なされている
ボランティアがシステム維持のために費やす時間と労力を考えれば、£80,000は本当に少ない金額だ
インフラの近代化が必要だとは聞いているが、大きな投資が必要な部分だ
資金にもっと余裕があれば、もっと自信を持って投資できていたはずだと思う
サーバーのアップグレード以外にも解決すべき課題は多い
今の状況はかなり心配だ
F-Droid は現在、Google を除けば最大規模の Android アプリストアなので、なおさら必要だと思う
この問題を解決する計画があるのか、F-Droid がいつサーバーをアップグレードするのか、あるいは Google がこの必須要件を取り下げる可能性があるのか気になる（最後のケースは可能性が低いと思う）
この問題は Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9 で修正された
実際のチケット記録も残っている
個人的にはトップ10にも入らないと思う
なぜ aapt2 をターゲット向けに再ビルドしないのか気になる
ソースは入手できる
aapt2ソースの場所
バイナリが本当に大量に含まれていて、いくつかのバイナリをソースから再ビルドしようとしたが、ビルドシステムがあまりにも壊れていてすぐに諦めた
今後出てくるバイナリごとに毎回パッチを当て直す必要がなく、自動的にバイナリアップデートへ対応できる
Streaming SIMD Extensions(SSSE3)のWikipedia記事を共有
自分の古いデスクトップもこの命令をサポートしていて、10年近く使っていた
それなのにソースコード側でフォールバックパスすら提供していないのは驚きだ
コンパイラが x86_64-v2 を指定してコンパイルした可能性が高い
RHEL 9 もこのオプションでビルドされており、RHEL 10 では x86_64-v3 に上がって AVX もサポートされる
AMD 10hのWikipediaリンク
現実的にこれをテストできるハードウェアがなく、あるのはどれも古くて遅い機器ばかりだ
完全には理解できない
gradle と aapt2 はオープンソースなのだから、buildroot や openwrt のように自前でコンパイルしてツールチェーンを作れば、もっと予測可能な結果になるはずだ
f-droid も同様にツールチェーン全体をソースから直接ビルドすれば、未対応命令を含むバイナリ版 gradle や aapt2 を使う必要はなくなる
その中にはネイティブバイナリを含むものもあり、buildroot や Linux ディストリビューションのように各ライブラリがどうビルドされるかのメタデータがない
さらに gradle エコシステムのライブラリごとにビルド工程がすべて異なり（標準化されていない）、全体を完全にソースから再構成するのはかなり面倒で難しい作業だ
Google が upstream ですでにこの問題を修正したという話もある
issueリンクを参照
どれくらい早く解決するかは断言できないが、issueスレッドは直接修正された証拠がなくても、やや安心材料にはなる
上のリンク先スレッドでは、タイプミス（"mas fixed"→"was fixed"）の訂正を今回のissueが解決したと勘違いしている
解決されたのは数年前の類似した過去の問題だ
Google issue trackerを参照
sse4.1 が 2011 年に導入された命令だと考えると、こんな旧式サーバーがまだ運用されているのは不思議だ
最新CPUなら同じ仕事を消費電力のほんの一部でこなせるはずで、経済的にも古いハードウェアを使い続けるのは理解しにくい
もしかしてビルドサーバーの台数や仕様を知っている人はいるだろうか
半分に減っても新しいコンピュータ価格の10%にしかならず、元を取るまで10年かかる
アップグレードは設備投資だが、電気代は運用費であるという点もある
米国の電気料金の根拠資料
Bulldozer に追加された各種命令（AVX、FMA など）はあるが、既存の Opteron のほうが実際には Bulldozer より速いことも多く、Epyc（2017年半ば）が出るまではアップグレードの動機が薄かった
さまざまなパッケージで sse4.1 以上が適用されるようになる理由は、古いCPUでは条件分岐などSIMD並列処理時のオーバーヘッドが高いためだ
2000年代の古いPCでも普通の作業（Webブラウジングなど）には十分だったが、年月がたつにつれてプログラムが新しい命令を要求するようになり、徐々に使い物にならなくなった
Firefox ですら新しい命令セットを要求するようになり、結局まだ動くデスクトップを捨てざるを得なかった経験がある
ただし KGPE-D16 ボードには SSE4.2 対応CPUも搭載できるので、正確な理由はよく分からない
Google の新しい aapt2 バイナリ（AGP 8.12.0）の話をしつつ、F-Droid はビルド環境の保護・隔離に非常に気を使うプロジェクトなのに、なぜ upstream のバイナリを取得して使い、ソースからビルドしないのか意外だ
Android アプリを作るには、基本的に Google の非自由（Non-free）バイナリに依存することになる
関連フォーラム投稿を参照
参考リンクまとめ
F-Droid admin issue
Catimaアプリ issue
MBCompass issue
あるメンバーはこう述べている: 「F-Droid ではいつもそうだが、私たちの声は常に無視される。解決策を議論して F-Droid を改善できるという希望があったなら、あれほど多くの時間とエネルギーを費やした末に失望して去ることはなかっただろう」
F-Droid のサーバーは本当に老朽化しているという意見だ
まったく別のアーキテクチャで x86_64 をエミュレートしても、むしろ性能向上になるレベルだ
もはや OSS（オープンソース）的な理屈を持ち出す必要すらない
もしクローズドなファームウェアを気にしないなら、もっと安価で最新の x86 サーバーの選択肢も多い
大衆文化のせいで「そのサーバーは古すぎてベンジャミン・フランクリンと幼稚園で同級生だった」みたいな冗談を思い浮かべる