ハクソク

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

フラットパックの未来

368日前原文(lwn.net)

概要

  • Flatpakは多くの指標で成功しているが、 開発の停滞 が懸念事項。
  • 主要開発者の離脱 やレビュー不足が、機能追加や改善の障壁となっている。
  • OSTree/OCI対応、権限管理、サンドボックス など、未解決の技術課題が山積。
  • D-Bus通信やネットワーク分離 にも改善の余地があり、セキュリティ面で課題が残る。
  • 新規貢献者の参入促進・体制強化 が、今後の発展に不可欠。

Flatpakプロジェクトの現状と課題

Flatpakの成功と普及状況

  • Flatpak は、Linuxアプリケーション配布フォーマットとして 開発者・ユーザー双方から高い支持 を得ていることを確認。
  • Flathub でのアプリ公開数増加や、 Fedora など主要ディストリビューションでの採用拡大を確認。
  • Alexander Larsson による初期開発、および GNOME/Red Hat メンバーの継続的な関与を確認。

開発停滞の背景

  • 主要開発者の離脱 （例：Larsson）により、 レビュー・マージの遅延 が顕著となっていることを確認。
  • 新規コントリビューター が参加しにくい状況（フィードバック・レビュー待ちが数ヶ月単位）を問題視すること。
  • 保守・セキュリティ対応 は継続する一方で、 大規模な機能追加・刷新 は進行していないことを認識。

OSTreeとOCIの現状

  • OSTree は一定の成功を収めているが、 ツール類の限定 や 開発停滞 が課題であることを確認。
  • OCIイメージ はツールエコシステムが充実しており、 zstd:chunked圧縮 などの新機能も登場しているが、 Flatpak側での統合が進まず、レビュー待ちが続いていることを指摘。

権限管理とサンドボックスの課題

  • アプリケーション権限の細分化 （例：--device=input）や 後方互換性 確保の難しさを挙げること。
  • PipeWire による音声出力のみの権限付与など、 PulseAudio依存からの脱却 が求められていることを確認。
  • ネストサンドボックス の未対応や、 ユーザー名前空間の制限 が時代遅れとなっていることを指摘。
  • Bubblewrapのネスト利用不可 や、 サブサンドボックスAPIの制約 についても課題認識すること。

D-Busプロキシとネットワーク分離

  • xdg-dbus-proxy によるD-Bus通信の制御が現状だが、 cgroupsベースの動的ポリシー 実現に向けた構想（busdプロトタイプ開発計画）を紹介。
  • Flatpakアプリ間のD-Bus通信不可、 ネットワークネームスペースの脆弱性 （例：localhostサービスの全アプリ共有）を問題視すること。
  • AusweisAppの事例 など、 セキュリティ上の懸念 を具体例で指摘。
  • ネットワーク専門家の不足 が、ネットワーク分離機能の進展を妨げている現状を説明。

NVIDIAドライバ対応の負担

  • 複数バージョンのNVIDIAドライバビルド によるユーザーのネットワーク負担増大や、 ゲームFlatpakの継続的アップデート の必要性を指摘。

今後の展望と提案

  • 開発体制の強化 ：新規貢献者が参加しやすい環境整備、 レビュー体制の改善 を最優先課題として提案。
  • 技術的課題の解決 ：OCIサポート統合、権限モデルの後方互換性、サンドボックスの柔軟性向上、 ネットワーク分離の強化 などを推進すること。
  • セキュリティとユーザビリティの両立 ：D-Busやネットワークを含む アプリ間通信の安全性 向上を目指すこと。
  • コミュニティの活性化 ： Flathub やLinuxディストリビューションと連携し、Flatpakプロジェクト全体の発展を促進すること。

まとめ

  • Flatpak はLinuxアプリ配布の主流となりつつあるが、 開発停滞や技術的課題 が今後の成長の障壁となっていることを確認。
  • 持続的な開発・体制強化 と 技術的負債の解消 が、今後の安定運用と普及拡大の鍵であることを提案。

Hackerたちの意見

パーミッションの問題は本当に深刻だよね。Tailscaleや仮想インターフェースを作成するものをFlatpakとしてパッケージ化することはまだできないし、そのためのパーミッションがないんだ。macOSにはインターフェースを追加したりルートを変更するためのパーミッションを要求するAPIがあるのに。

└

そのAPIのおかげで、TailscaleはMacOSではサンドボックスアプリとしてMac App Storeを通じて配布されているんだ。[1] Flatpakの制限は、SilverblueやBluefinのような「アトミック」Linuxディストリビューションで特定のソフトウェアを使うのを難しくしているんだ。これらは読み取り専用のベースシステムを提供して、ユーザーがFlatpakを通じてソフトウェアを取得することを期待しているから。[1] https://tailscale.com/kb/1016/install-mac

└

Tailscaleはフラットパックじゃなくて、システム拡張にすべきじゃないかな。

└

たとえ可能でも、Tailscaleをフラットパックでインストールする気はあまりないな。フラットパックは、システムを汚さずに大きな、もしかしたらクソみたいなデスクトップアプリをインストールするための手段だと思ってる。OBSスタジオはその完璧な例だよ - いいアプリだけど、QTを使ってるのはこれだけで、フラットパックのおかげでQTライブラリをシステムにインストールしなくて済んでる。Tailscaleはシステムサービスみたいなもので、ディストロパッケージの方が好ましいな（ちなみにArch LinuxのリポジトリにはTailscaleが含まれてるよ）。

└

フラットパックのユーザーってわけじゃないけど、Linuxの上にある権限システムはすごい取り組みだと思う。パッケージングと権限のレトロフィットを同時に解決するのは、飲み込むには大きすぎるクッキーのように感じる。権限システムが勢いを失わせて、こういう燃え尽き症候群を引き起こしたのかはわからないけど、すごく複雑に見える。俺にとって、Linuxには細かい現代的な権限システムがないし、パッケージマネージャーがそれを解決してくれるとは期待してない。今でもプロプライエタリソフトウェアを使ってるのは、そうせざるを得ないから。理想的な状況かって言われたら、そうじゃない。でも、完璧な権限を待つよりは、配布システムを持ってベンダーをチェックする方がいいと思う（それは今やってることだし）。配布、パッケージング、アップデートが今一番必要だと思う。

└

Tailscaleや仮想インターフェースを作るものをFlatpakとしてパッケージ化するのはまだ不可能なんだ。許可がないからね。可能ではあるけど理想的ではない。アプリケーションはflatpak-spawnを使ってサンドボックスから出て、polkit-execでユーザーにルート権限を求めることができるけど、ほとんどすべてのサンドボックス機能を取り除くことになる。

Wickは、Flatpakプロジェクトは素晴らしいように見えるけど、深く見てみると「もう積極的に開発されていないことに気づく」と話し始めたんだ。コードベースを維持したりセキュリティの問題を修正する人たちはいるけど、「大きな変更はもう本当に起こっていない」と言ってたよ。新機能のためのマージリクエストがたくさんあるけど、誰もそれをレビューする責任を感じていないみたいで、それはちょっと問題だよね。Red Hatはここでもっと頑張るべきだと思う。特にRHEL 10でデスクトップパッケージの多くを維持するのをやめて、「私たちからではなくFlathubからパッケージを取得して」とユーザーにアドバイスしているのに（https://docs.redhat.com/en/documentation/red_hat_enterprise_... を見て、Flathubを検索してみて）。もしこれがRed Hatのデスクトップソフトウェアに対する態度なら、Flatpakを実行可能な代替手段にするためのリソースを提供すべきだよ。> ユーザーのLinuxディストリビューションは、--device=inputをサポートしていない古いバージョンのFlatpakを提供しているかもしれないし、Flatpak開発者が使いたいと思っている新機能が使えないかもしれない。Wickは、アプリケーションが新しいパーミッションをデフォルトで使える方法が必要だけど、古いバージョンのFlatpakが使われているシステムでは古いパーミッションモデルにフォールバックする必要があると言ってた。彼がそれを問題として挙げてくれて嬉しいよ。私はFlathubで音声とコントローラーのサポートがあるゲームを維持しているんだけど、限られたパーミッションの粒度のせいで、そのゲームは任意のデバイスアクセスを必要とするものとして表示されているんだ（--device=inputは新しすぎて、Flathubのメンテナがまだパッケージに許可していない）。それに、デバイスのマイクにアクセスできることも必要なんだけど（音声パーミッションはスピーカーだけでなくマイクにもアクセスできる）。Flatpakがパーミッションの後方互換性を追加してくれることを願ってるよ。

└

Red Hatはその一部を引っ込めたみたいだね。FirefoxとThunderbirdはRHEL 10用にFlatpak専用になる予定だったけど、結局GA用のrpmが出荷されたみたい。Native Messagingの欠如や、ポリシーを中央で展開する能力がないこと、デスクトップエコシステムの他の部分との統合が壊れていることなど、さまざまな原因があったみたい。

いいまとめだね。私はLinux初心者で、これを知らなかったよ: > FlatpakはホストシステムがPipeWireを使っていてもPulseAudioを使っている。これが問題なのは、PulseAudioがスピーカーとマイクへのアクセスを一緒に束ねているから—両方にアクセスできるか、どちらもできないかで、片方だけは無理なんだ。だから、アプリケーションが音を再生するためのアクセスを持っていると、同時に音声をキャプチャするアクセスも持っている。これはかなり大きな穴だね。

└

時々、LinuxユーザーがWindowsやMacのデザインミスや「自由」の欠如を嘲笑しているのを見かけるけど、こういうこともあるよね。もちろん、Linuxは便利に再定義されて、誰も責任を持たず、すべての問題で指を指し合っているけど、こういうデザインの欠陥を認めることはしないんだ。

これは私にとっても近い話だよ。FlatpakはLinuxでデスクトップアプリを配布する最良の方法だと思う。アプリ開発者、パッケージャー、ユーザーとしてそう言えるよ。かつては10個近くのパッケージを維持していたこともあった。次に何をするのか、どんな魔法のような機能を導入するのか、数ヶ月間楽しみに待っていたんだ。フォーラムで他のユーザーがアプリをパッケージ化するのを手伝ったり、Flathubの提出をレビューしたり（毎回同じ問題だったから）、PRがどうなっているかをチェックし始めたりしてた。静寂。数ヶ月が数年に変わり、さらに年が経つにつれて、私はFlatpakとの関わりを徐々に失っていった。今はほとんどのことにAURを使っているけど（Archね）、この状況が明らかにされるのを聞いてとても悲しいよ。Flatpakは本当に革命的だったんだ。現代のアプリとスムーズな配布をすべてのデスクトップに持ち込んだ—LTSでもローリングリリースでも。でも、数年前に始まった時から本当に何も変わっていないんだ。

└

同じ気持ちだよ。数年前はFedora + GNOME + フラットパックが魔法の組み合わせだったけど、今はそうでもないね。俺もArchに戻ったけど、パッケージリポジトリが増えてる感じがする。AURもあるけど、必要なものがほとんどないのには驚いてる。

└

フラットパックを使った経験はほとんど良くなかったな、インストールの簡単さを除いて。システムとちゃんと統合されることがほとんどない。テーマが間違ってる、カーソルが間違ってる、ファイルピッカーが間違ってる、権限の問題、ドラッグ＆ドロップの問題。アプリのインストール後に権限を広げるための追加ツールが必要になることが多いから、機能が動かないことがある（Discordのグローバルプッシュトークはいつも楽しいよ、特にWaylandのとき）。UXが悪くなるなら、サンドボックスなんてどうでもいい。Linuxでバイナリのポータビリティがそんなにひどくなければ、フラットパックなんて必要ないのに、今の状況だよね。

└

質問なんだけど、多くのパッケージを維持していたから: > 大半はAURに戻ってきたよ。じゃあ、makedebを第二のチャンネルとして試してみた？ https://www.makedeb.org/ これはPKGBUILDsを使うから、翻訳も簡単だよ。パッケージャーを助けるためにかなり良い位置にあると思うんだけど、なんであまり知られてないのか不思議だね。

数年前、私はキー入力やマウスクリックを表示するためのオンスクリーンディスプレイ（OSD）をJavaで書いたんだ[1]。誰かがフラットパックが役立つと思ったみたいで[2]、私はその意味がわからなかった。つまり、(a) 2つのインストールプロセスを維持すること; (b) 2つのソースからダウンロード統計を集計すること; (c) サードパーティのシステムにパッケージインデックスを維持させることを信頼すること[3]; (d) すでにパッケージマネージャーがあるシステムにさらに別のパッケージマネージャーを追加すること; (e) もう一つのリポジトリでリポジトリを膨らませること、ってことだ。数年後、今でも欠点しか見えていないよ。[1]: https://gitlab.com/DaveJarvis/KmCaster [2]: https://github.com/flathub/com.whitemagicsoftware.kmcaster [3]: https://flathub.org/apps/search?q=kmcaster - おっと！

└

利点は、- 不変のディストリビューションでの簡単な使用 - ユーザーが正しいバージョンのJavaをインストールしているか確認する必要がない - 特定のディストリビューションのリポジトリがなくても自動更新がある ってところかな。Flathubで検索すれば見つかるだろうし。

最近、フラットパックベースのイミュータブルディストロに切り替えたんだけど、うまくいくときは最高なんだよね。でも、いろんな便利な機能が動かなくて、なんか自分のコンピュータが本来の素晴らしいツールじゃないみたいに感じちゃう。例えば： - Godotのために外部ツールを動かすために、WINEを使ったディストロボックスを走らせたり、いろいろな権限や手間をかけなきゃいけなかった - FirefoxのフラットパックはKeepassDXのフラットパックと連携できないから諦めた - GodotとKritaのフラットパックは妙に不安定で、Windowsよりもクラッシュすることが多い（たぶんGnomeのせいかも） - AppImagesや.rpmみたいな非フラットパックツールはちょっとダサい感じがする フラットパックでもっとクールなものを見たいから、今の状態を見てるとちょっと残念だね。

Pythonプロジェクトのために使えるデバッガーを持つために、VSCode/Codiumをインストールするためにフラットパックを入れたんだけど、デバッガーを動かそうとVSCode/Codiumをいじってたら、フラットパックが問題かもしれないって気づいた。いろんなフラットパックの権限を試すのにかなりの時間を使ったけど、これが時間の無駄だってわかった。スナップから同じパッケージをインストールしたら、全部うまくいったよ。

└

EmacsのFlatpakは、どこにも行かない長くて苦痛な道だね。

└

Flatpakは、システムツールよりもアプリケーションに対してはるかに良いよ。例えば、Chrom{e,ium}みたいに、サンドボックスのおかげでね。

新しいデザインを真剣に考える人がいたら、こんなエピソードを聞いてほしい：数年前、フラットパックが新しいプロジェクトだった頃、元の開発者たちに会ったことがあるんだ。特定の基本的な部分を変更するように説得しようとしたけど、失敗した。元のデザインでは、インストールされたフラットパックには名前があって、その権限はその名前に結びついていて、そのフラットパックを実行すると割り当てられた権限がある。もしVSCodeのフラットパックを自分のUIDでインストールして、Documentsディレクトリへのアクセスを許可したら、VSCodeは自分としてDocumentsにアクセスできる。これが間違ったデザインだと主張したんだ。自分としてVSCodeをインストールしたら、インストールされたコピーがあって、それはほとんど意味がないべきだと思う。VSCodeを実行するなら、その実行インスタンスには何らかのID（おそらく一時的なもの）があって、そのインスタンスには権限のセットがあるべきだ。~/project_aにアクセスするVSCodeを実行したいなら、別のインスタンスで~/project_bにアクセスするのも簡単にできるべきで、同時に実行してもお互いのデータにアクセスできないようにすべきだ。もし2つのTailscaleを実行したいなら、それもできるべきだし、一時的なFirefoxインスタンスを立ち上げたいなら、それもできるべきだ。何年経っても、俺はまだ自分が正しかったと思ってる。フラットパックはこれを間違ってるし、MSやAppleのアプリストアも間違ってるし、Mac OSも（非常に非常に）間違ってる。もっと良くするチャンスはたくさんあるよ。（これはバグの軽減の観点から重要だよ：RCEを達成するLibreOffice文書は、他の文書にアクセスできるべきじゃない。ベンダーが全く気にしないという観点からも重要だよ：VSCodeは基本的にセキュリティがないし、フラットパック内のVSCodeはフラットパックのおかげである程度の本当のセキュリティを持つべきだ。）

└

ちょっとOTだけど、Androidでもこういうアプリのポータビリティが欲しいなと思ってた。数年前にXiaomiみたいなOEMが注目して、OSにいくつかの人気アプリ（WhatsAppとか）の「複製」機能を組み込んだみたいだけど。

└

そうだね、特定のプログラムのインスタンスにセットされた権限を持たせる方がいいと思う。ただ、これが唯一の問題じゃないと思うよ。これを望んでいたのは自分だけじゃないし。多くの理由から、オペレーティングシステム全体を再設計する必要があると思う（前により良い設計について言及したけど）、そうすれば実行中のプログラムの特定のインスタンスに能力を引数として与えることができるようになる（他の能力を通じてもいいけど、最初のものは引数として与えられるべきだね）、そしてこれらの能力には制限された権限を持たせたり、アクセスをログに記録したり、プロキシを通したり、ディスククォータを設定したりすることができるようになる。

└

この部分を誤解してるかもしれないけど、インスタンスにアクセスを与えるための一時的なアクセスを提供するのがxdg-portalの役割じゃないの？

└

バーチャルボックスのスナップショットみたいな感じ？だったら、そのスナップショットをブランチ、マージ、ロールバックしたくなるよね。

└

これはQubesのTemplateVMとAppVMの違いみたいなものだね。

└

その通りだけど、実際には君のアプローチと彼らのアプローチを組み合わせたハイブリッドを作りたいと思うんじゃないかな？ドキュメントに関しては、君のアプローチが通常は望ましいと思う。便利な「最近使ったドキュメント」メニューとかのオプションがあってもいいかも。でも、環境に関することについては、後でたくさんの権限のプロンプトなしで、すべてのインスタンスに同じアクセスを許可するオプションが欲しいな。例えば、私のgit設定、フォントフォルダ、コードスニペットライブラリとかね。

└

これは、アプリの異なるインスタンス間で厳密な隔離を求めるパワーユーザーには良いと思うけど（QubesOSタイプのアプローチももっと見てみたい）、この種の作業のほとんどはアプリ自体の中で優先されるべきだと思う。ネストされたサンドボックスを使ってね。そうすれば、バリアはユーザーがアプリの通常の動作に基づいて期待する場所に正確にあることになる。もちろん、すべてをつなぐコードに脆弱性が爆発的に増えない限りだけど。ウェブブラウザはすでにタブ間の分離を達成するためにさまざまなサンドボックス技術を使ってる。一部の技術はFlatpak内でも機能するけど、Flatpakによって壊されるものもある：> 理想的には、Flatpakは単にネストされた名前空間とネストされたサンドボックスをサポートするべきだけど、現在はそうなってない。Flatpakはseccompを使って、サンドボックス内のアプリがユーザー名前空間に直接アクセスするのを防いでる。一部はFlatpakによって置き換えられていて、APIを使いたいアプリ開発者向けに：> 現在Flatpakが行っているのは、アプリが呼び出してさらに制限された別のFlatpakインスタンスを生成できるようなサイドサンドボックスを持つことだ。幸いなことに、WickはUID名前空間について楽観的なようで、FirefoxとChromeがこれを修正するのを妨げている主な要因だ：> Wickは、ユーザー名前空間は現在、十分にテストされていて広く使われているインターフェースだと感じている。彼は、もはやユーザー名前空間に対する良い反論はあまりないと思っている。インスタンス化されたFlatpakの話に戻ると、アプリストアやプラットフォームが一般的に求めているのは、サンドボックスに結びついた完全なブートからユーザースペースへのコード署名セットアップの長期的な希望だと思う。各アプリケーションのアイデンティティは同じままであるべき（パワーユーザーによって特別にオーバーライドされない限り）で、偽のアプリケーションが既存のアプリケーションの機密の暗号化ファイルを採用できないようにするためだ。ここでの一つの解決策は、分離されたインスタンスをアプリケーションのアイデンティティ内にネストさせることかもしれないけど、かなり複雑になってきてるね。しかも、まだ暗号化や機能するセキュアブート＋機密コンピューティングの実装もないから、今のところこの面ではFlathubによって確認された逆ドメイン名表記と、これらのフォルダを分けるためのファイルシステムアクセスのサンドボックスしかないんだ。

└

愚痴が続くよ。セキュリティの名の下にある複雑さの塔が本当に嫌いなんだ。PCは汎用デバイスで、俺のものなんだ。インスタンスごとに許可を持つ必要はないし、他のアプリケーションとファイルを共有できないサンドボックスもいらない。俺のPCから「すべてはファイル」という概念が消えてほしくない。俺のPCは単一ウィンドウデバイスじゃないし、インターネットに向けたサーバーも運営してない。脅威をモデル化して、使いやすさに応じてセキュリティを調整してほしい。これには理由があるんだ: UbuntuのThunderbirdとFirefoxは今、/tmpディレクトリにアクセスできなくて、代わりに変な場所に自分のディレクトリを持ってる。Thunderbirdで添付ファイルを保存して他のプログラムで開くという簡単なことをしたいのに、/tmpにできなくて、どこかの永続ストレージに置かなきゃいけない。でも、サンドボックスのせいでさらに悪化してる。Thunderbirdはサンドボックス化されているから、他のインストールされたアプリケーションを提案する手段も持っていない。コンピュータが俺のものでなくなって、使いやすさよりもセキュリティが常に重要だと思っているアーキテクチャの宇宙飛行士たちの遊び場になっちゃう。そういう人たちには、地球上で最も安全なデバイスでいじってもらいたいね [1] そうすれば、物事を進めようとしている人たちに干渉しないだろうから。 [1] https://en.wikipedia.org/wiki/Useless_machine

└

ソフトウェアパッケージがどうあるべきかについて君が正しいかもしれないけど（俺も同意する傾向がある）、Flatpakがこのモデルを強制するべきかどうかは全く別の問題だよ。俺の知る限り、dnf/yumやaptのような古いパッケージシステムは、Flatpakが許可していることを許可している。もしかしたら、開発者たちは良いパッケージシステムであることに集中したかっただけで、パッケージシステムの権限モデルを変えることには興味がなかったのかもしれない。それは合理的だと思う？

└

君が正しいかもしれないね。Flatpakの開発者たちも君が正しいと信じていた可能性すらある。そして、それが正しい決定でなかったかもしれない。Flatpakのような製品に関しては、技術的に正しい選択が何かを超えた多くの考慮事項があるからね。例えば、君のコメントだけを基にすると、ほぼすべての他のOSはFlatpakと同じようにやっている。だから、Flatpakの開発者たちが君が提案したように技術的に正しい方法でやっていたら、特にマルチプラットフォームのアプリ開発者にとっては負担が大きすぎて、そもそもFlatpakを使わなかったかもしれないね。

自分はオープンソースのメンテナーでも開発者でもないけど、たくさんのディストリビューションがあって、みんな同じパッケージ管理の問題を抱えてるのに、Flatpakを改善して普及を目指す方向に力を合わせられないのはおかしいと思う。

└

たぶん、多くの「ディストリビューション」が存在する理由の一つは、みんなが「同じように配布」する気がしないからだと思うよ :-)。多様性はいいことだ。initシステム、ディストリビューション、コンポジタ、ウィンドウマネージャーなどを選ぶ「一つのディストリビューション」は欲しくない。選択肢が欲しい。パッケージを配布することに関しては、個人的にはシステムパッケージマネージャーが好き。flatpakにはあまり興味がないかな。

└

フラットパックが役に立つなんて考えてる人は多くないよ。例えば、私には全く役に立たない。使ってないものに手を貸してくれってどうして期待するの？

└

その理屈だと、GNOMEだけが存在を許されるってことになるね。いらないよ。権力を持ってる人たちは、コミュニティの大部分が反対するような決定をすることが多いから。

彼に100%同意するわけじゃないけど、Drew DeVaultがこのトピックについて考え深いことを言ってるのはいつも興味深いね：https://news.ycombinator.com/item?id=32936114 https://drewdevault.com/2021/09/27/Let-distros-do-their-job.... 基本的に、彼はディストリビューション外でのアプリケーション配布（flatpakやsnap、appimageみたいな）は悪いモデルだと言ってる。正しいモデルは、ディストリビューションが何年も使ってきたもの：ディストリビューションのパッケージマネージャーを通じてソフトウェアを取得し、そのソフトウェアはディストリビューションのために働く人たちによってパッケージされる。彼が言うには、「ソフトウェアのディストリビューションはしばしばボランティアによって運営され、ユーザーの利益を代表している；ある意味で、ユーザーの連合みたいなものだ。」もちろん、実際にはflatpakやsnap、appimageはディストリビューションのパッケージほど100%うまく動くことはないっていうのも問題だね。

└

問題は、今はN個のディストリビューション用にパッケージを作らなきゃいけないってことだね。そして、ディストリビューションを運営している人たちがそれに時間をかけたくないかもしれないから、自分でやらなきゃいけない。

└

フラットパックがもっと普及してるのが嬉しいね。アプリの配布はディストリビューションから移行する必要があると思う。だって、あいつら下手くそだから。彼らのせいじゃないけどね。開発者は中間業者なしでアプリを配布できる選択肢があってもいいと思う。

└

それには同意できないな。個人的には、アプリケーションのパッケージを作るのに最適な人たちは、そのソフトウェアの元々の開発者だと思う。もしそのソフトウェアがプロプライエタリなら、法的にそれを行えるのはそのパーティだけだからね。ソースコードへのアクセスが必要だし、ソフトウェアの再配布には許可が必要だから。だから、君が言ってるモデルはオープンソースのパッケージにしか通用しないと思う。たとえアプリが100%オープンソースでも、コア開発チームに関係ない誰かがそのアプリについてあれこれ考え直すのは良くないと思う。無駄な問題が増えるだけだから。開発者が新しいソフトウェアをリリースしてから、第三者が勝手に必要だと思う調整をする間に無駄な遅延が生じたり、自分たちのバグや新しい問題を追加したりすることになる。だから、例えばFirefoxはMozillaからtarボール形式で直接インストールすることにしてるんだ。開発者がパッチを承認するとすぐに自動で更新されるからね。これはセキュリティや安定性の理由でよく起こることなんだ。リリースされたパッチはすぐに欲しいから。外部の配布メンテナがやることは冗長だと思う。Mozillaが自分たちのソフトウェアに関する問題について最も理解していると信じてる。プロプライエタリなものに関しては、最低限の手間で動いてくれればいい。フラットパックはやりすぎてると思う。アプリストアを模倣しようとしてるけど、アプリストアはあまり好きじゃない。彼らはゲートキーパーみたいなもんだから。WindowsやAppleの開発者はどうしてるかって？自分たちのウェブサイトにバイナリを置いて、ダウンロードしてインストールして、あとは動くだけだよ。ダウンロードしたアプリはアプリストア経由のアプリと同じ権利を持ってる。アプリストアはアプリを再パッケージするわけじゃなくて、ただ配布してるだけなんだ。追加のサービス、オプションのエクストラだよ。セキュリティを提供するための基本的なものはOSとアプリケーションパッケージに組み込まれてる。WindowsやMacが提供するいくつかのメカニズムがセキュリティを確保してる。バイナリは署名されてるし、OSには必要なものに対する権限モデルがある（画面共有、特定のディレクトリへのアクセス、ウェブカメラの使用など）。これが正しいモデルだと思う。Linuxでも同じように機能するはずだよ。第三者が配布やパッケージの管理をする必要はないはず。

└

アプリケーションの開発者は、自分のアプリをパッケージ化して配布できるべきだと思う。Windowsでカジュアルユーザーがアプリをダウンロードしてインストールするのがどれだけ簡単か見てみてよ。メンテナはスケールしないし、彼らに依存するのはデスクトップLinuxを後退させるだけだよ。

└

そのソフトウェアは、ディストリビューションのために働いている人たちによってパッケージ化されているんだ。世界中のすべてのソフトウェアをパッケージ化できると期待するのは全く無理だよ。