現在のバージョンの Windows で動作する実行可能ファイルを作成した場合、その実行可能ファイルはおそらく新しいバージョンの Windows でも何年も動作します。Microsoft はこれを確実にするために非常に努力しています。
Linux では、使用しているソフトウェアのソース コードがあることが期待されているため、ソースの互換性が維持されている限り、バイナリ互換性が失われても問題ありません。このため、ディストリビューションは古いライブラリ バージョンを段階的に廃止し、以前は動作していたものを定期的に破壊することになります。
Linux をゲーム プラットフォームとして使用している人にとっては、ゲームはバイナリ形式でのみ配布される傾向があるため、これは問題です。Linux の移植版が壊れると評判が悪くなりますが、すべての人が移植版を更新することを期待するよりも、この問題を全体的に解決する方が生産的であるように思います。
必ずしも古いバージョンをすべて保持するのではなく、少なくとも古い soname を保持して、リリース n で動作するバイナリがリリース n+1 でも動作するように、バイナリ互換性を維持しようとしているディストリビューションはありますか?
私が見つけた中で最も近いものは、Steam を通じて配布されるプログラムでのみ利用可能なバイナリ互換性レイヤーである Valve の「Steam Runtime」です。
答え1
基本的には次のようになります:バイナリ互換性を維持しながら新しい機能を導入することはできないこれらはほとんどの面で互いに直接相反するからです。大きな新機能を導入すると、最終的にはしなければならないABI を変更する (通常は API の変更直後)。これで、バージョン管理されたシンボル (たとえば Glibc など) を使用できるようになりましたが、これによりライブラリのサイズが大きくなり (バイナリをメモリにロードするときにパフォーマンスが低下する可能性もあります)、開発者はそれを一般的なライブラリに保持したくないでしょう (レガシー コードには、修正する気のないバグが含まれています)。
配布側でこの問題を回避する一般的な方法は 2 つあります。
バージョンを変更しないでください。これは、RedHat や SUSE (アルファベット順) などのエンタープライズ グレードのディストリビューション、および他のいくつかのディストリビューション (Debian、Slackware、Ubunty LTS、およびおそらくそれらのクローン) では一般的です。
ライブラリのさまざまなバージョンを同時にインストールできるようにします。
アプリケーション ディストリビューターでは、これは Windows と同じ方法で処理されます。つまり、必要なものをすべてディストリビューション パッケージに詰め込みます。はい、これは Windows でよく行われる方法です。これは、一般的な Windows システムが、同じ機能を持つ Linux よりも通常数倍のディスク領域を必要とする理由の 1 つでもあります。アプリケーションは、アプリケーション間で非常に小さな部分のみを共有し、どこかに独自のコピーを持っています。これは、すべての GTK/Qt アプリケーションに独自の GTK/Qt スタックが付属していると考えることができます。これにはいくつかの利点がありますが、欠点もたくさんあります。たとえば、セキュリティの観点から見ると、Technicolor TMでは悪夢です。バイナリが静的にリンクされている場合は、FullHD でも悪夢です。