Flatpakはsystemdに依存する予定
(osnews.com)- Flatpak はこれまで「すべてのディストリビューション向けにアプリをビルドできる」ことを強みとして掲げてきたが、次のメジャーバージョンでは systemd 依存 が生じる可能性が高まっている
- Flatpak Next または Flatpak 2.0 は、既存の 1.x にある 数十年越しの設計 上の限界を乗り越えるための、再実装に近い取り組みであり、まだ計画段階にある
- 新サービス systemd-appd は、アプリ識別子と権限を保存し、他のコンポーネントがそれを参照できるようにし、下位サンドボックス化を可能にする中核的な役割を担う
- 非 systemd ディストリビューション向けには elogind のような独立デーモン実装の余地もあったが、論争が大きくなった後は、開発者の配慮の意思が弱まったように見える
- systemd 依存が厳格化すると、Void、Guix、Alpine のようなディストリビューションで Flatpak の利用が難しくなり、ディストリビューション中立性 も弱まる可能性がある
Flatpakのディストリビューション中立性が変わる可能性
- Flatpak のウェブサイトは最初の利点として “Build for every distro: create one app and distribute it to the entire Linux desktop market.” を掲げており、サポート対象ディストリビューション一覧には Void Linux、Guix、Alpine のような systemd ではない init システムを使うディストリビューションも含まれている
- 現在の Flatpak は、ユーザーがどの init システムを使っているかを気にしないが、次のメジャーバージョンでは systemd 依存 が生じる可能性が高い
- この変更が実際に導入されれば、systemd を使わないディストリビューションで Flatpak を引き続き提供できるかどうかが重要な争点になる
Flatpak Nextと再設計の方向性
- Arian Vovk と Sebastian Wick は Linux App Summit で Flatpak の将来を扱う 発表 を行った
- 現在の Flatpak バージョンも引き続き改善される予定だが、数十年越しの設計 の限界を回避することは次第に難しくなっている
- Flatpak Next または Flatpak 2.0 と呼ばれる取り組みは、Flatpak 1.x 以降に蓄積された経験を反映した、事実上の再実装に近い
- 新しい設計は、Flatpak 初期設計以降に定着した現代的な技術やアイデアを活用する方向で計画されている
- 発表内容はまだ計画段階であり、コードは1行も書かれていないため、今後数年の作業の中で結果が大きく変わる可能性がある
systemd-appdと権限管理の移行
- Flatpak の開発方針における中核的な変化は、権限管理 を Flatpak の内部ではなくサービス層へ移すことにある
- 新サービス systemd-appd は、アプリケーションに識別子を付与し、権限を保存し、システム内の他のコンポーネントがこのデータを参照できるようにする
- この構造は複数の機能を可能にし、とくに 下位サンドボックス化(subsandboxing) が重要な機能として挙げられている
- 現在の計画では、この機能を現行の Flatpak バージョンに導入することになっており、その結果 Flatpak に systemd 依存が生じることになる
非 systemd ディストリビューション向けの余地
- Vovk の説明 によると、systemd を使わないディストリビューションやユーザーにも「非常に配慮」しようとする意図があった
- 想定可能なモデルは、systemd-logind が独立デーモンの elogind として分離され、別の init システムを使うディストリビューションでも systemd-logind に依存するデスクトップ環境を利用できるようになった方式に近い
- Flatpak 開発者も、systemd-appd について同様の独立デーモン実装が可能になるよう、現実的な余地をできる限り残そうとしていたようだ
- このアプローチが維持されていれば、Flatpak は systemd を使わないディストリビューションでも引き続き提供できた可能性がある
論争の拡大と開発者対応の変化
- Void や Alpine のようなディストリビューションのユーザーは、Flatpak が systemd に強く依存した場合、自分たちのシステムで動作しなくなるかもしれないという懸念を示した
- Flatpak 開発に技術的には関与していない人物に質問が集中し、その回答が 役に立たなかったり、侮辱的 だったり、扇動的 だったりすることがあった
- その人物が Flatpak 開発に関わっていると誤解する人が増え、真剣で友好的な質問と、反 systemd 的な激しい反応が入り混じって状況が悪化した
- その結果、Flatpak 開発者は、systemd を使わないディストリビューションやユーザーに配慮するために時間を使いたくないという 反応 を示すようになった
- この流れが続けば、systemd 依存はさらに厳格化し、systemd-appd の機能を複製する独立デーモン実装も、当初の想定よりはるかに難しくなる可能性がある
予想される結果と意味
- 現在の状況では、今後数年のうちに Flatpak が systemd 依存性 を持つ可能性が高い
- systemd を使わないディストリビューションで systemd-appd の機能を代替する独立デーモンを作れるようにするための配慮が、省かれる可能性もある
- そうなれば Flatpak は、もはやすべてのディストリビューションを対象に1つのアプリを配布できるという ディストリビューション中立性 を掲げにくくなる
- Flatpak は、ユーザーがどの init システムを使っていても実際の需要があるツールであるため、この変化は Linux デスクトップアプリケーションの配布範囲に直接的な影響を与える
1件のコメント
Lobste.rs の意見
なぜそこまで systemd を嫌うのか理解できない。個人的には、扱いやすい API と合理的な 依存関係・競合管理 を通じて有用な機能を提供していると思う。
systemd を嫌う側は、「Unix らしくない」「中央集権的だ」「systemd-journald のファイル形式がプレーンテキストではない」といった曖昧な理由しか挙げないことが多い。
反対するなら、具体的な理由と解決策、そしてなぜ他の init システムのほうが優れているのかを示してほしい。そうすれば rc スクリプトがどれほどひどく雑然としたハックなのか説明できる
Linux の哲学は、少なくとも私にとっては根本的に選択の自由に関わるものであり、Flatpak が特定の init システムを要求するなら、望む結果を得るためにユーザーがシステムを構成するときの選択肢が減ってしまう
コンテナイメージにもっと簡単に入れられるべきだし、ユーザー systemd がシステムインスタンスへの読み取り API アクセスを持ち、少なくとも
AfterやRequiresのようなものでユニットを予約できるようであってほしい。それでも、HAL の廃止以降 Linux に起きた最高の出来事だと思っているし、Lennart にプロジェクトへの感謝を伝えて握手したこともある
この「反対派」が実質的に主張しているのは、解決策そのものが存在してはならない という立場に近い。Linux の HOA のように振る舞い、実際に堅牢で使えて競争力のあるシステムが独占的 OS を押しのけうる進歩を妨げる反動的な政治に近いと思う
upstartでも特に不満はなかっただろう。だがノート PC では求めるものが違う。自分の個人環境をどう動かしたいかについて考えがあり、一般的な Linux ユーザーが望まないような便利機能も欲しいし、明示的に要求していないことは起きてほしくない。「動くようにする手間」よりも「動かないようにする手間」のほうがずっと嫌いだ。
NixOS を systemd のせいで離れることになった核心は、広がり続けるスコープと押しつけがましいデフォルト にあった。電源管理とログイン処理が統合され、ふたを閉じると必ずスリープするような挙動を毎回修正しなければならず、linger の許可範囲の変更は POSIX が要求する
nohupとscreenを壊し、より厳格な VT 管理は「一度ログインして複数の Xorg インスタンスを実行する」ことや「VT を奪う」ことを systemd 流に再設計するよう強いた。結局、最小 init の
sinitとサービス監視なしのほうがよいと判断し、シェルのブートスクリプトを自分で書いて、一部のシステム機能はシェルで、一部は Common Lisp で実装している。ノート PC 上の PostgreSQL のようなものは、一度起動したらそのまま動き続け、止まれば気づけるし、再起動で十分なら単純だし、十分でないならサービス監視機構でも助けにならない。信頼が壊れた事例としては、HDD 上で journald がコールドキャッシュ状態のログを表示するのに数分待っても出力されなかったこと、https://github.com/systemd/systemd/issues/2913 を実際に踏んだこと、
nohupを壊すことにためらいがなかった点がある。開発過程でも、https://github.com/systemd/systemd/issues/437 に見られる「良いデフォルトを提供するが、デフォルトが悪くてもディストリビューションが直せばよい」と感じられる態度や、安定 API の約束に消極的な http://lists.freedesktop.org/archives/systemd-devel/… のような姿勢が信頼を損ねた。
とはいえ、こうした不満は古いものだ。systemd がある問題を解決しながら別の問題を作り、そのどちらも自分がもともと抱えていた問題ではないと分かった後、ノート PC ではブート用シェルスクリプトへ移行した。今では現状維持コストが低すぎて、systemd をもう一度試す理由がない。VPS では Debian の慣れた範囲の中で systemd を使っている
この件が Flatpak 開発者ではない人による 誤情報 から始まり、感情的な反応を呼び起こし、元のスレッドが進む間にさらに強い表現が積み重なって、Flatpak プロジェクトと開発者の評判に人々が群がる状況になったのがもどかしい。
その結果、実際の Flatpak 開発者たちが感情的に傷つき、怒れる集団と距離を置きたがるようになったとしても驚きはない。
みんな落ち着いて、この件をこれ以上大きくしないでほしい。疑念や懸念があるなら実際のメンテナーと話し、中間点を探りたいという支持を示し、これはコミュニティ全体を代表するものではない特定の個人による孤立した出来事だと示すべきだ。
systemd に依存するという話も確定事項ではなくアイデアだったように、メンテナーがより多様なプロジェクト支援を再考する可能性もまだ閉ざされていないと思う
systemd で動かないシステムも引き続きサポートできる程度には、みんなうまくやっていけるといい。Flatpak や他の コンテナ方式 は、対象プラットフォーム向けに簡単にはビルドできないパッケージをユーザーが実行する助けになるし、特定のソフトウェアが必要なときに、そのようなシステム上で Flatpak を動かせるとよい。
コンテナも似た役割を果たすが、十分に変わった構成で x11docker のようなものをきちんと動かすのは、うんざりするほど厄介だ
ノートPCでVoidを使っているが、作業効率が良く、ドキュメントもしっかりしている。開発者たちがこれまで積み上げてきたすべての仕事に感謝しているし、Flatpakの変更があまり大きな負担にならないことを願う
「これが現代のLinuxで、あるのはsystemdだけだ」
Linuxコミュニティは共同体というよりWeWorkに近い、ということを鮮明に思い出させる。周囲の誰もがRed Hatの存在に依存する給料を受け取っている一方で、誰かがGNU readlineを無償でハックしているような構図だ
この段階で断定的に「依存するようになる」と言うにはまだ早すぎるし、かなり憶測的に見える
タイトルのほうが本文よりずっと断定的なのは興味深い。多くのコメントが明らかにタイトルだけに反応しており、幸い全部ではないが、こういう現象はインターネットでは今に始まったことではない
最近はlobste.rsでも、人々がタイトルや長いコメント中の一文だけに反応するのをよく見かけるので心配になる。たいてい、自分が最初に思いついた、しばしば攻撃的な解釈以外の可能性をほとんど認めない
記事を読むと、Flatpak 2.0をめぐる議論でも似たことが起きていたようだ。他のinitシステム向けの余地を入れようとしていたようだが、その周辺の議論が急速に敵対的になり、事実上断念したように見える
代替initシステムを使っている立場としては本当にうんざりする。ノートPCの1台をAlpine Linuxで動かしていて、glibcでしか動かないソフトウェアを実行するためにFlatpakを使ってきた。この変更はその環境から離れるきっかけになるだろう
systemdが嫌いなわけではない。Gentooのシステムはすべてsystemdベースだ。ただ、systemdが自由・オープンソースソフトウェアをGNU/Linuxにますます依存させていくやり方は気に入らない
これは間違いなく良いことだ
systemdは安定していてよく定義されたAPIを持つデーモン群で構成されているのだから、Flatpakが依存することになるsystemdのどの部分であっても、誰かが労力をかければ最初からきれいに再実装できるはずだ
可能な限り最善の結果だ。断片化は減り、特殊な要求を持つ人々には再実装のための安定した目標ができる
systemdのAPIはmanページで曖昧に定義されていることが多く、systemd側も別実装を想定していないため、双方向に安定しているわけでもバージョン管理されているわけでもない
notifyソケットAPIに関しては、むしろ一方向にしか安定していない。vsock対応の追加によって、libsystemdに依存せずに実装されたデーモンは事実上壊れてしまった。この破壊があまり知られていないのは、vsockが主に仮想化境界をまたぐsystemd間通信に使われていたからだ。まともに設計されていれば、その境界でのみ使う拡張になっていたはずだ
「デーモン群」と言っても、実際にはほとんどlogindとsystemdであり、この2つがAPI表面全体を露出しているので、組み合わせ可能性は限られている。いくつかのDBusインターフェース、今ではvarlink、そして単一のライブラリを通じてそれを行っている
systemdを置き換えるには、丸ごと置き換えたうえで内部モデルをsystemd式APIとして露出するよう苦労して合わせるか、まずsystemdのAPI設計上の選択をほどいて、プラグ可能なバックエンドを提供する中間層を作るしかない
この問題にはもう何年も取り組んでいる。systemdの設計原則の多くは妥当だと思うが、現在の設計は大半の人には不要な複雑さを手前に押し出している。よりモジュール化され、置き換え可能な設計は可能であり、切り離し可能な単純なインターフェース設計も比較的簡単に思いつくか、既存のものを再利用できる
しかし問題は、systemd APIに依存することを選んだソフトウェアだ。それを他のものと動かすには、libsystemd全体に縛られた機能サポートを切り離すパッチをupstreamに入れるか、新しい個別APIのサポートを追加する必要があるが、前者は成功したことがなく、後者はリリース前の少数派APIを保守する負担のため受け入れられにくい
あるいは、ソフトウェアが使うAPIだけを実装することもできる。たとえば、ほとんどのAPIを実装しないlogin1 DBusサービスを使うやり方だ。しかしそうすると、APIの他の部分を置き換えようとする別の実装と衝突し、元のクリーンなAPI、logind/systemd DBus API、varlink向けAPIという3つの変種を実装しなければならなくなる
長期的には、systemdやlogindのAPI全体を実装し、裏側では分離されたAPIに接続するルーターが解決策になるかもしれない。ただし現在の設計には極端な重複とsystemd特有の前提が埋め込まれているため、まともに作るのは非常に複雑だ
意図的だったのかは分からないが、systemd開発者たちの発言を見る限り、少なくとも意識して配慮された問題ではなかった。複雑な中間層を作るか、systemdを書き直さずにsystemd代替を作るのは非常に難しく、アプリケーションが分離された断片として提供可能なAPIの一部にしか依存していない場合でさえ、systemdの一部分だけをきれいに置き換えることは事実上難しい
Red HatがLinuxエコシステムに対してあまりに大きな支配力を持つようになる構図は気に入らない
それでも、Red Hatが自由ソフトウェアを受け入れている点は、その影響力への懸念をある程度和らげてくれる。ここ数年で買収してきた技術を見ると、以前はupstreamがなかったものについても、自ら自由・オープンソースのupstreamを作った例がある。特にDogtag PKIと389 Directory Serverが思い浮かぶ
全体としては、エコシステムにとって概ね悪くなく、損なったものより発展させたもののほうが多かったと思う
この論争に直接関わるものは何もないが、Linuxシステムで増え続ける不要な複雑さと抽象化に対する不安を和らげるものはここにはない
Linuxは急速にOS界のJavaになりつつある。本当に悲しいことだ