Flatpakの未来

• Flatpak は現在、開発者とユーザーから人気を集めているが、プロジェクト自体の 開発停滞 が問題として浮上している
• 中核開発者の離脱と ボトルネック により、新機能の反映やコードレビューが 遅延 している状況にある
• OCIイメージ対応・権限の細分化・オーディオアクセス制御など、さまざまな 強化機能 が提案されたが、実際の反映は遅々として進んでいない
• プロジェクトの長期的な発展のため、コンテナ技術標準（OCI）の導入 と Rustベースの再実装 案が議論されている
• ポータル改善、ドライバー対応、ネットワークサンドボックス化 など主要課題の解決が、Flatpak成長の鍵となっている

---

Flatpakプロジェクトの概要と現状

• Flatpak は2007年から類似プロジェクトとして始まり、2015年に XDG-App として初公開され、2016年に Flatpak へ改称された経緯を持つ
• コマンドラインツール、ビルドツール、ランタイム構成要素 を提供し、cgroups、namespaces、bind mount、seccomp、Bubblewrap などによってアプリケーション隔離（サンドボックス化）を実現している
• OSTree を基本配布方式とし、最近では OCIイメージ対応 も搭載して Fedora などで活用されている
• Flathub アプリストアの成長やディストリビューションでの採用など成功を収めている一方、プロジェクト内部では 活発な開発の鈍化 を経験している

開発停滞の現状と主な原因

• 保守やセキュリティパッチ水準の活動は続いているが、大規模な新機能 の開発やコードレビューは 長期間停滞 している
• 主要開発者の離脱（Larsson など）によりレビュアーが不足し、新規コントリビューターの流入や大規模変更が難しい環境になっている
• Red Hat などが貢献している Flatpakプリインストール（Preinstall） 機能も、レビュー遅延と担当者離脱により、統合完了まで数か月を要する事例が繰り返されている

OSTree と OCIイメージ対応

• OSTree は Flatpak にうまく適用されたが、非標準的で限定的なツール という問題があり、保守以外では積極的な発展が見られない
• OCI にはコンテナイメージ向けの 幅広いツールエコシステム が存在し、Flatpak 開発チームにとっては、導入により保守負担と重複作業を減らせる効果が期待される
• zstd:chunked のような効率的圧縮フォーマット対応も新規 PR として提案されたが、遅延・未統合 の状態が続いている

権限管理とサンドボックスの細分化

• Flatpak は サンドボックス化 によるシステムアクセス制限に重点を置いており、最新の Flatpak では 権限の細分化（例: --device=input）がサポートされている
• Linux ディストリビューションごとに Flatpak のバージョンが異なるため、新しい権限機能が広く適用されにくい問題 と バージョン互換性 の問題が発生している
• オーディオ権限については PulseAudio 対応の限界により再生と録音の分離が難しく、これは PipeWire などによる改善の必要性が指摘されている
• ネストされたサンドボックス への対応不足により、Web ブラウザーなどで内部的に別のサンドボックスを活用できない

D-Bus とネットワークのサンドボックス化

• Flatpak は D-Bus に直接アクセスせず、xdg-dbus-proxy を通じたフィルタ済み通信方式を使用している
• Wick は フィルタリングポリシーを D-Bus ブローカーへ移し、ポリシーの動的適用と cgroup ベースのアクセス制御 を実現したい考えを示している
• ネットワーク名前空間の実装不足により、localhost ポートが露出 している場合に Flatpak アプリ間で 意図しない通信が可能になる おそれがある（実例: AusweisApp）
• NVIDIA ドライバー は各ランタイムごとに個別提供されており、過剰なネットワークトラフィックと更新の難しさ を引き起こしている。Valve のモデルを参考に、ホスト共有や静的コンパイル案 が模索されている

ポータル（Portal）の活用と改善の必要性

• ポータル は D-Bus ベースの外部リソースアクセス API であり、ファイル、印刷、URL など多様な役割を担う
• Documents ポータルなどはファイル単位では有効だが、GIMP・Blender など高い操作性が求められるアプリでは 細かすぎる権限モデル が制約として働く
• パスワード自動入力、FIDOキー、音声合成などの新API 提案とともに、開発難度の緩和や Rust による再実装 のアイデアが議論されている

Flatpakの未来（Flatpak-next）

• 今後 Flatpak がこれ以上開発されない状況を想定し、OCIエコシステムへの大転換（イメージ、レジストリ、ツール、ポリシーなど幅広い活用）が長期的観点から議論されている
• Rust ベースの再実装など、コンテナエコシステムの一元化 により、管理負担、保守、拡張性の面で利点が見込まれる

質疑応答まとめ

• OCI移行時の既存 Flatpak アプリの扱い についての質問には、Flathub のビルド自動化などにより大きな問題はないと回答している
• OCIレジストリにおけるメタデータ不足の問題 については、非イメージデータ向け標準が整備されつつあるものの、実際の反映には開発と統合が必要とされる
• PipeWire の直接対応 計画については、技術的議論が進行中であり、PipeWire のポリシーベース統合が方向性とされている

結論

• Flatpak は 配布およびサンドボックス標準プラットフォーム として地位を築いたが、レビューと新規開発の停滞、権限・ネットワーク・ドライバー問題、将来の標準移行 など多くの改善課題を抱えている
• OCIベースのコンテナ技術と Rust 活用 は、Flatpak 発展の新たな原動力として浮上する余地がある
• 主なポイントは レビュアー確保、標準化、エコシステム拡張、ユーザー体験改善 などに要約できる

[ndrgrd]

アクセス権を完全に遮断するのではなく、どのディレクトリにアクセスしているのかを明確に示す方式のほうがよいと思います。

Androidはその点では悪くないのですが、こちらは権限のまとめ方が大きすぎて、必要のないレベルの権限まで一緒に許可しなければならないので…

[GN⁺]

Hacker Newsの意見

• Wickの発表で、Flatpakプロジェクトは見た目にはうまく回っているように見えるものの、実際には活発な開発が行われていない状況だと強調されていたという共有。セキュリティ維持と簡単な保守は続いているが、新機能はほとんど追加されていない。多くの機能提案（Merge Request）が上がってもレビューする人がおらず停滞している点は問題だと思う。特にRHEL 10でデスクトップパッケージの提供をやめ、Flathubからのパッケージインストールを推奨するようになったことで、Red Hatの役割はさらに重要になったと判断している。Red HatがFlatpakを本当に代替手段として育てたいなら、もっと多くのリソースを投入してほしい立場。Flatpakはバージョンごとに新しい権限の対応有無が異なるためbackwards compatibilityが必要だというWickの指摘にも共感する。自分がFlathubでゲームを配布した際、オーディオやコントローラーの権限問題、--device=inputの未対応、スピーカーだけ開いてマイクは遮断するといった細かな権限設定ができない現実を実際に経験した
  • Red Hatは当初、FirefoxとThunderbirdをRHEL 10でFlatpak専用として配布しようとしていたが、実際にはGAリリース後にrpmパッケージも提供した事例に言及。Native Messaging未対応、中央ポリシー配布不可、デスクトップ統合の問題など、さまざまな理由が複合的に作用していた
• Flatpakが最初に始まったとき、元の開発者に直接会って設計思想について議論した経験を共有。Flatpakはパッケージ名に権限が紐づき、インスタンスごとの分離ができない構造が問題だと説得しようとしていた。つまり、同じFlatpakアプリを複数インスタンスで起動し、それぞれ異なる権限（例: Documents配下の特定ディレクトリだけ許可）で分離実行できない。この構造はMS、Apple App Store、macOSも同様で、世の中すべてが間違った設計をしていると思う。たとえばLibreOffice文書でRCE（リモートコード実行）が起きても、自分の他の文書へのアクセスは防がれるべきであり、ベンダーがセキュリティに注意しなくてもFlatpakサンドボックスが安全性を提供すべきだと主張
  • こうしたセキュリティ目的の複雑性増加に批判的な見方もある。PCは自分のものなので、インスタンスごとの権限、サンドボックス、ファイル共有制限などは不要で、「すべてはファイル」という伝統的概念を維持したいという意見。例として、ThunderbirdやFirefoxが/tmpディレクトリにアクセスできず、添付ファイルを保存して他のアプリで開くのが極めて不便になるサンドボックス環境への不満が挙げられる。コンピュータの主人は開発者ではなくユーザーであるべきで、こうした過剰なセキュリティは生産性低下につながると考えており、Useless Machineにたとえている
  • Flatpak開発陣もこの問題を理解していた可能性を指摘。Flatpakが技術的に完璧なモデルを採用していたら、むしろアプリ開発者、特にマルチプラットフォーム開発者にとって参入障壁が高すぎて、Flatpak自体が普及しなかっただろうという現実論
  • インスタンスごとの権限モデルは非常に魅力的だが、設定（git config、フォントフォルダなど）については、すべてのインスタンスが同じアクセス権を持てるようオプション化するハイブリッド方式が実用的だと提案
  • OS全体を再設計し、実行中の各インスタンスに個別の権限（capabilities）を与え、ディスククォータ、ロギング、プロキシ、細かな権限分離など多様な機能を支援するのが望ましいと考えている。単なるFlatpakだけの問題ではないと主張
  • QubesOSのようなハイパーバイザーベースのサンドボックスなど、徹底した分離が必要なパワーユーザーやセキュリティ重視ユーザーにはインスタンス単位の分離が良いが、ほとんどの分離作業はアプリ内部で行われるのが直感的なアプローチ。Webブラウザのサンドボックスのように、Flatpakもnested sandbox対応が理想だが現状は未対応。コード署名とサンドボックスの連携、UID名前空間など、かなり複雑な問題も存在する
• 自分はFlatpakの長年の熱心なユーザーだったが、革新的で、すべてのLinuxディストリビューションで最新アプリを簡単に使えるようにしてくれた一方、ここ数年変化がなく徐々に関心が薄れたという経験。今はAURでほとんど足りており、Flatpakの停滞が惜しい
  • Flatpakはユーザーとして簡単だという点以外、特に良い経験がなかった。テーマ、カーソル、ファイルピッカー、パーミッション、Drag&Dropなど統合の問題が多く、機能を使うために追加ツールも必要。UXが悪い以上、サンドボックス化などのセキュリティ上の利点は無意味だと思う。Linuxでバイナリ移植性の問題さえなければFlatpakは不要だったという立場
  • Fedora+GNOME+Flatpakの組み合わせは一時とても革新的だと感じたが、最近またArchに戻った経験。Archのリポジトリはずっと充実し、AURをほとんど使う必要もなくなった
  • 複数パッケージを管理していた経験者にmakedebの使用経験を尋ねつつ、makedebはPKGBUILDベースで移植性が高く、なぜもっと知られていないのか不思議だと述べている
• Drew DeVaultの「ディストリビューションがアプリのパッケージングを担当すべきだ」という主張に100%同意するわけではないが、長年の論考と参考リンクを紹介。コミュニティ（ディストリビューション）がユーザーを代表してパッケージを管理するというモデルが正しいという見方で、Flatpak/Snap/AppImageのようにディストリビューション外でパッケージングするモデルは根本的によくないと主張
  • これに反論して、アプリを直接作る開発者こそパッケージ管理に最も適しているという意見。特にソース非公開ソフトウェアでは、法的に配布・パッケージング権限が独占される。オープンソースであっても、コアチームでない人が勝手にパッケージングへ介入するのは不要なバグ、リリース遅延、新たな問題を生むと考える。速くて最新の更新、パッケージング改変のない純正ソフトウェア提供を望んでいる。Flatpakが役割を持ちすぎているのが問題で、アプリストアモデル自体にも懐疑的。WindowsやmacOSではアプリストアがなくてもバイナリ配布は自由で、最低限のセキュリティはコード署名などOSレベルで提供されると主張。サードパーティのパッケージングシステム主導は不要
  • アプリ開発者が直接配布できるべきであり、Windowsの簡単なインストール体験を例に挙げる。メンテナーがすべてのディストリビューションを支援できる規模を持つのは難しく、これはLinuxデスクトップ発展の足かせだと見る
  • 複数のディストリビューション向けにいちいちパッケージングしなければならない手間のせいで、かえって意義が薄れるという指摘
  • 世の中のソフトウェアをすべてディストリビューションがパッケージングするのは非現実的だという意見
  • ディストリビューションはアプリのパッケージングが下手だという立場から、Flatpak採用が増えてうれしい、開発者が仲介者なしで自分のアプリを簡単に配布できるべきだと考える
• FlatpakがいまだにPulseAudioを使い続けていてPipeWire導入に遅れている点、PulseAudioはスピーカーとマイクの権限を統合しており分離できない、つまりアプリに音声出力権限を与えると自動的にマイクにもアクセス可能になってしまい、セキュリティ上の大きな穴だという指摘に共感
  • Windows/macOSの設計ミスや自由のなさをLinuxユーザーがよく嘲笑するが、こうした本質的な設計問題も認めるべきだという主張。Linuxエコシステムは責任の所在を明確にできないまま問題を放置しがちな傾向があると考えている
• VSCode/CodiumをPythonデバッグ目的でFlatpakとしてインストールしたが、権限や設定の問題でデバッガ設定に長い時間がかかり、結局Snap版を入れたらすべて解決した経験
  • Flatpakは大型アプリ（例: Chrome、Chromium）などデスクトップアプリケーションには向いているが、システムツールには不向きだと思う
  • EmacsのFlatpak版は非効率と挫折しかもたらさなかったという経験
• immutable distroにFlatpak中心で移行して使った際、うまくはまるときは良いが、思いのほか多くの部分が動かず期待外れだった。たとえばGodot向け外部ツールの実行、各種パーミッション調整、Flatpak同士の相互連携問題（例: FirefoxとKeepassDX）、GodotとKritaのFlatpakのクラッシュ、非FlatpakのAppImage/.rpmなど異種環境との混在など、さまざまな不便を経験し、Flatpakのさらなる革新を望むと述べている
• FlatpakではTailscaleのように仮想ネットワークインターフェースを作成するアプリをパッケージングできない構造。macOSはAPIを通じてネットワーク権限を細分化でき、TailscaleもMac App Storeでサンドボックスアプリとして配布可能
  • そのAPIのおかげでTailscaleのmacOS向けサンドボックスアプリ配布が可能である一方、SilverblueやBluefinなどFlatpak依存の「atomic」Linuxディストリビューションでは、この種のソフトウェアを使いにくい状況
  • OBS Studioのように、Flatpakはデスクトップの大型アプリでは意味があるが、システムサービスのように動くTailscaleはFlatpakよりディストリビューション標準パッケージが適していると考える。Arch Linuxでは公式パッケージとして存在する
  • Flatpakではflatpak-spawn、polkit-execなどの迂回策は可能だが、この場合サンドボックス保護はほぼ放棄することになる
  • Linuxの最上位で細かなパーミッションシステムとパッケージングまで一度に解決しようとする試みは複雑すぎる。Flatpakの停滞や開発者の燃え尽きもこのせいかもしれないと疑っている。現代Linuxには根本的な権限体系がないため、完璧なパーミッション設定より先に、当面の課題はソフトウェア配布、パッケージング、更新体制だという現実認識
  • Tailscaleのようなものはsysext（システム拡張）で行くべきで、Flatpakは適していないという意見
• Flatpak配布提案に関連し、JavaベースのKmCasterアプリを開発していてFlatpak移植を求められたが、インストール方法が二つになること、ダウンロード統計管理、サードパーティリポジトリへの信頼、新しいパッケージマネージャの増加、リポジトリ重複など追加負担しか感じなかった。実質的な利点はなかった
  • それでもFlatpakの前向きな面として、immutable distroでの使いやすさ、Javaバージョン管理の必要性解消、Flathubでの検索露出、自動更新などは利点だと述べている
• オープンソースのメンテナーや開発者ではないが、多数のLinuxディストリビューションがみな同じパッケージ管理問題を抱えているのに、力を合わせてFlatpakの改善と普及に集中できないのが理解できないという考え
  • 各ディストリビューションごとにDistributionのあり方自体が異なるため、一つに統一するのは難しく、多様な選択肢こそオープンソースエコシステムの利点だと思う。個人的には伝統的なシステムパッケージマネージャの方が好み
  • この論理ならGNOMEしか存在すべきでないことになってしまうので、コミュニティの多様性、意思決定の多様性が重要だという立場
  • Flatpakは自分にはまったく役に立たない。自分が使わないソフトウェアへの貢献を強いられたくない