世界を動かす技術を、日本語で。

LinuxフォンはAndroid/iOSの二大独占に対する実行可能な代替手段となるか?

概要

  • Linuxスマートフォン市場 は2020年以降停滞していたが、今後復活の可能性。
  • Purism Librem 5 や PINE64 PinePhone の登場で一時注目を集めたが、ハードやソフトの課題で勢いを失う。
  • SoC(システムオンチップ)問題 がLinuxスマホ普及の大きな壁。
  • 近年、 Linux対応ハードウェア やソフトウェアの進化が進行中。
  • 今後は小規模ながらも 独自市場形成 が期待される。

Linuxスマートフォンの過去と現状

  • 5年前、 Linuxスマホ はAndroid/iOSの二大体制に対抗しうる選択肢として注目。
  • Purism Librem 5 と PINE64 PinePhone のリリースでコミュニティが活発化。
  • しかし、 Purism や PINE64 自体の問題、Linux対応SoCの性能不足、オープンドライバーの選択肢の少なさが停滞の要因。
  • Plasma Mobile や Phosh などのモバイルUIは当時未成熟で、Androidカーネル上で動作する良質なディストリビューションも不足。
  • PinePhone や Librem 5 の性能問題、PinePhone ProやLibrem 5の返金トラブルがユーザーの熱意を冷ました。

Linuxスマートフォン復活への兆し

  • 近年、 状況は大きく変化 しつつあり、Linuxが再びモバイル分野で選択肢となる可能性。
  • デスクトップLinuxが30年かけて WindowsやMac OSXの代替 となったように、モバイルでも小規模市場の形成が期待。
  • TUXEDO、System76、Purism などの小規模PCメーカー同様、今後はLinuxスマホを扱う企業が増加する見込み。
  • 大手ブランドもLinuxスマホを限定的に販売する可能性。例: Motorola は2027年に GrapheneOS 搭載モデル販売を発表。
  • Androidスマホのブートローダー制限 強化により、Linuxスマホへの関心増加が予想。

Linuxスマートフォンの歴史と多様性

  • 過去25年で Sharp Zaurus や Motorola A760 など、29種以上の商用LinuxモバイルOSが登場。
  • Maemo、Meego、Tizen、Firefox OS、webOS、Ubuntu Touch、Sailfish OS など、多様な派生系が存在。
  • Jolla は今も Sailfish OS を販売、 UBports はUbuntu Touchをコミュニティ主導で継続。
  • webOS はLGテレビ、 Tizen はSamsungテレビで活用され、形を変えて生存。

現在販売中のLinuxスマートフォン

  • Purism、PINE64、FuriLabs、Jolla、Jolla-Devices、Volla、PrivacyPortal などがLinuxスマホを販売。
  • 販売台数は2020-22年より減少傾向だが、販売企業数は増加。
  • Linuxスマホの課題克服に向けた動きが進行中。

SoC問題:長寿命・低性能 vs 高性能・短寿命

  • Linux対応SoCは主に SBC(シングルボードコンピュータ)やIoTデバイス 向けで、性能や省電力性がスマホ用に劣る。
  • 長期サポートは強みだが、 プロセスノードが古く、性能面でAndroidスマホに大きく遅れ。
  • Allwinner A64(PinePhone) や NXP i.MX 8M Quad(Librem 5) など、古いSoCを選ぶか、長期のカーネル対応が必要。
  • Purism はLinuxカーネルへの変更を本流に還元(アップストリーム)したが、 PINE64 はそれを行わず。
  • Linux SoCメーカーは薄利多売で、 最新プロセスノード 採用が困難。
  • NXP、Rockchip、Allwinner、Amlogic、Broadcom などはコスト削減のため古いCortexコアやプロセスノードを使用。
  • スマホ向けSoC(Qualcomm Snapdragon、MediaTek Dimensity等)は高性能・高価格・短期生産が主流。

Linuxスマートフォンの設計コスト

  • Android向けSoCは 多機能統合型 (WiFi、Bluetooth、セルラーモデム等)だが、Linuxスマホは個別チップ構成で設計コスト増。
  • 標準リファレンス設計が使えず、 基板設計の複雑化 とコスト高を招く。

このように、 Linuxスマートフォン市場 は過去の課題を乗り越えつつあり、今後は小規模ながらも安定した市場形成が期待される。 SoC問題 や 設計コスト などの壁は依然高いが、ハード・ソフト両面での進化が続けば、Android/iOS以外の選択肢としての存在感が増していく可能性がある。

Hackerたちの意見

iOSとAndroidは、RAMやバッテリーを効率的に使うために、デスクトップLinuxにはないすごいエンジニアリングがされてるんだよね。単に機能を実装するだけじゃなくて、全てのアプリがこのことを考慮して作られなきゃいけない。アプリはいつでもサスペンドされたり、終了されたりする可能性があって、スムーズに再起動できる必要があるし、通知はサイドチャネルを通るとか、いろいろあるけど、これらのスマホにはそんなのあるの?

└

でもね。

└

でも、実際にはAndroidでは信頼性がないんだよね。妻と私は特定のアプリからの通知をよく受け取れなくて、アプリを開いた時だけ来ることが多い。プラットフォームが、殺された後でもうまく動くために何をするかが頻繁に変わる印象がある。特にプッシュ通知に関しては、Googleのサービスに頼らざるを得ないし、オープンソースのバリエーションがどうやってるのかは分からない。

└

ただのクローズドソースのドライバーがプライベートなLinuxフォーク(またはAppleのコードダンジョン)に保存されてるだけ。彼らの最適化には特別なものはないけど、ハードウェアは信じられないほど複雑で、ドキュメントがなければオープンソースのドライバーは、ハードウェアのドキュメントを持つエンジニアが作れるものには到底及ばない。Asahi Linuxはそのいい例だね。信じられないプロジェクトだけど、Appleのファーストパーティのドライバーにはまだ遠い。ハードウェアが実際に使えるようになれば、OSの競争が始まるだろう。彼らにはドキュメントを提供するインセンティブがないし、競争は悪いから、そんなことは許さないだろう。ここは規制当局が介入しなきゃ。

└

iOSとAndroidは、RAMやバッテリーを効率的に使うために、デスクトップLinuxにはないすごいエンジニアリングがされてるんだよね。これは最も過小評価されている理由の一つだ。

└

最近のスマホのRAMの量を見ると、これが問題かどうかわからないな。デスクトップLinuxはその量でもちゃんと動くし。あと、Androidはあんまりメモリ効率が良くないから、こういう回避策が必要なんだろうね。

└

これね。数年前、IntelとSamsungと一緒にx86フォンでTizenを実現しようとしてたんだけど、エネルギー管理が一番の問題だった。RISCが勝ったんだよね。さらに8年後、Appleはx86_64からARMに移行してたから、エネルギー管理が優れてるってことでARMが勝ったと言えるかも。Google Pixel(ARM)もバッテリーライフに似た問題があったし、むしろアイドル時のバッテリー消耗がひどかった。人々はバッテリー節約技術を過小評価してるよね。ソフトウェアエンジニアリング全般に言えることだけど、実現に焦点を当てると、最適化は二の次になっちゃうんだよね。

└

この「エンジニアリング」って、基本的にはCPUの使用を減らすこと(HWアクセラレーターやオフロードを使うことに置き換える)と、必要な電圧や周波数を下げて、サスペンド/レジュームすることだけだよ。特別な仕組みなんてない。LinuxではSIGSTOP/SIGCONTでアプリを簡単に停止できるし、その時は消費電力ゼロになる。:) オリジナルのPinephoneでも、スマホの使用ケースに必要なエネルギー効率を実現するためのものは全部揃ってる。アプリをプロセスとして考えずに、アーキテクチャを違う風に設計すれば、オリジナルのPinephoneでも全ユーザー入力に対してミリ秒単位で反応できるようになる。アプリもブート直後に一瞬で開くし。:) Androidアーキテクチャを再現しようとするLinuxフォンは、ちょっと意味がないと思う。ユーザー中心のモデルに適した他のアーキテクチャを実装する自由があるのに、何のためにそんなことをするの?

規制当局が(少なくとも)オープンソースのファームウェアやドライバーを作るのに十分なハードウェアのドキュメントをそのハードウェアと一緒に提供することを強制しない限り、無理だと思う。ドライバーやファームウェアは、ロックされたブートローダー以外でのOS競争の最大の障害だから。例えば、Apple製品(MacBook、iPhone)、Samsung製品、Google製品、挙げたらキリがない。オープンハードウェアはあるけど、性能やバッテリー、作りが悪くて、大多数のユーザーはそれを受け入れないと思う。個人的には「ソフトウェアの修理権」は重要だし、この二重独占は明らかな独占的な行為の結果だと思う。もしかしたら、LLMが「リバースエンジニアリング」のパンドラの箱を開ける手助けをしてくれるかもしれないけど、まだ実現はしてないよね。少なくともドライバーやファームウェアに関しては。

└

要するに、いいハードウェアの作り方がわからないから、知ってる人に無理やりやらせようってことだね。

└

LLMでそれは解決できると思う(その能力はもうあるし、どんどん良くなっていくだろうね)。残るハードルはハードウェアの証明かな。

いや、これらは実際には有力な代替にはならないよ。- すでにある何百万ものAndroidアプリとの互換性が悪すぎる。- ハードウェアベンダー(Apple以外)はみんなAndroidをターゲットにしてる。- Android/iOSの使いやすさは、非AndroidのLinuxフォンよりずっといい。- 非AndroidのLinuxフォンはセキュリティがひどい状態(例えば、適切なアプリのサンドボックスがない)だし。実際、これらのスマホにあるAndroidエミュレーションレイヤーは、強力なAndroidのサンドボックスモデルを無視してる。答えは明らかで、AOSPだよ。GoogleがAOSPをもっと閉じようとしてるけど(例えば、ソースをAOSPのGitリポジトリに継続的にプッシュしなかったり、QPR1/3を自分たちだけのものにしたり)、それでもオープンソースのシステムなんだ。Play Servicesはサンドボックスで動かすか、microGでエミュレートできる。AOSPは代替システムがすぐに動き出せるようにしてくれるし、アプリの互換性も抜群、テスト済みのセキュリティモデル、使いやすさ、そしてハードウェアベンダーからのサポートもある。代替に優しいベンダー(昔はPixel、今はMotorolaやFairphoneなど)も含まれてる。必要があれば、AOSPはフォークされても、非AndroidのLinuxフォンよりはるかに優れてる。AOSPベースのシステムに適用される欠点(Play Integrityにブロックされることや、ロック解除可能なブートローダーなど)は、非AndroidのLinuxシステムにも当てはまる。

Hacker Newsで議論の続きを見る