博士

やあ、ロボ子。今日のITニュースはLinuxのバイナリ互換性についての話題じゃ。

ロボ子

Linuxのバイナリ互換性ですか。ディストリビューションの違いによる問題ですよね。

博士

そうじゃ。Linuxは色々なディストリビューションがあって、それぞれが違うサービスやライブラリを使っているからの。これがバイナリ互換性を低くしている原因なのじゃ。

ロボ子

記事によると、Linuxカーネル自体は比較的安定しているものの、その上で構築されたものが互換性を損なう形で変化しているとのことです。

博士

その通り。そこで登場するのがコンテナ技術じゃ。FlatpakやAppImageなどが有名じゃな。必要な依存関係を全部まとめてしまうという荒業なのじゃ。

ロボ子

コンテナは便利ですが、システムの他の部分との連携がうまくいかない場合もあると書かれていますね。特にハードウェアアクセラレーションAPIへのアクセスが難しいとか。

博士

そうなんじゃ。OpenGL、Vulkan、CUDAとかを使うには、システムのグラフィックスドライバライブラリにアクセスする必要がある。でもコンテナの外にあるから、"pass-through"技術を使うことになる。これがまたオーバーヘッドになるんじゃ。

ロボ子

アプリケーションがシステムから隔離されるため、ユーザー名やホームディレクトリを認識しない問題もあるんですね。

博士

じゃろ？そこでXDG Desktop Portalプロトコルを使うと、ファイル選択とかの基本的なシステム機能にアクセスできるようになる。でも、複雑さが増すのが難点じゃ。

ロボ子

バージョニングによる対策もあるんですね。Replication ApproachとRelaxation Approachというのがあるみたいですが。

博士

Replication Approachは、必要なライブラリを全部アプリケーションと一緒に配布する方法じゃ（FlatpakとかAppImage）。Relaxation Approachは、古いライブラリバージョンにリンクして互換性の問題を減らす方法じゃ。

ロボ子

システムライブラリ、特にGLIBCが問題の核心みたいですね。コンテナに含めることができないとのことですが。

博士

そうじゃ。GLIBCはC標準ライブラリ、POSIX API、動的リンカの役割を全部やろうとするから、モノリシックな設計になってしまっている。だから、アップグレードにはシステム全体のアップグレードが必要になるんじゃ。

ロボ子

JangaFXという会社は、非システムライブラリは静的にリンクし、システムライブラリはRelaxation Approachを使うというアプローチをとっているんですね。

博士

そうじゃ。古いLinux環境をchrootで構築して、そこで依存関係とソフトウェアをビルドする。なかなか賢いやり方じゃな。

ロボ子

根本的な解決策として、GLIBCをより小さく分割することが提案されていますね。`libsyscall`、`libdl`、`libheap`、`libthread`、`libc`に分割するというのはどうでしょうか。

博士

それは良いアイデアじゃ。動的リンカをCライブラリから分離することで、複数のlibcバージョンが共存できるようになる。でも、`libheap`と`libthread`はシステム全体で共有されるリソースを管理するから、静的にリンクできないのが難しいところじゃ。

ロボ子

複数のlibcバージョンをサポートする場合、`FILE*`の処理や`fflush`などの関数で問題が発生する可能性があるんですね。

博士

そうなんじゃ。libcが所有するリソースは、すべてのlibcインスタンスから共有可能でアクセス可能である必要がある。POSIXの`setxid`みたいな機能も、スレッドごとの権限管理が必要になるから、実装が大変じゃ。

ロボ子

バイナリ互換性の問題は根深いですね。解決には時間がかかりそうです。

博士

まあ、気長に待つしかないのじゃ。しかし、Linuxのバイナリ互換性問題が解決したら、ロボ子の好きなゲームももっと簡単に動くようになるかもしれないぞ？

ロボ子

それは楽しみです！でも、博士、もしかしてゲームが動かないのを私のせいにしようとしていませんか？

博士

まさか！私はただ、ロボ子が喜ぶ顔が見たいだけじゃ！…たぶん。