💾 Archived View for technicalsuwako.moe › blog › static-linking-better.gmi captured on 2024-08-31 at 12:32:16. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-18)
-=-=-=-=-=-=-
投稿日：2024-07-07
あたしは動的リンクを嫌っているわけではありません。
実際、ソフトウェアを開発中は動的リンクをしています。
この方がテストが簡単だからです。
しかし、製品版に関しては、新しいバージョンやプログラムを世界中の多くの人々に配布する前に、常に静的バイナリを作成します。
この記事を書いたのは、静的リンクを許可するOSが少ないかに気づいた事に困ったからです。
皮肉な事に、これは「自由」の為に行われています。
自由貿易の第0ルールは、他人に何をするかを指示しない事です。
静的リンクを禁止する事で、明らかにこのルールを侵害しています！
非常に驚くべき事に、Linux（musl、時々glibcも）、FreeBSD、OpenBSD、NetBSD、Dragonfly BSD、Windows、及びFreeDOSのみです。
勿論強制動的リンクのOSはmacOSです。
これはAppleが自社の.app形式を使用し、署名し、App Storeに公開する事を強く望んでいる為です。
その他の強制動的リンクのOSは、Illumos、Solaris、Haiku、及びMinixです。
静的リンクを動的リンクよりも優先する理由は多数あります。
動的リンクは、マルクス主義・共産主義・社会主義・ボルシェビキ主義の様な物です：観念的に素晴らしいですが、実際にはいつも大惨事になり、最終的には約束が全て大嘘です。
そして、マルクス主義・共産主義・社会主義・ボルシェビキ主義と同様に、動的リンクにも現実を完全に否定するカルトメンバーがいます。
そうでないとそのイデオロギーが機能しないからです。
動的リンクを避ける理由：
動的リンク支持者に「何故動的リンクが静的リンクよりも優れていると思うのか」（彼らは通常、静的リンクを嫌い）と尋ねると、彼らは常に「セキュリティの為、一回ライブラリを更新すれば全てのバイナリも自動的に更新される」「この方法ではプロプライエタリソフトウェアを配布するのが非常に難しい」「バイナリが小さい」と引用します。
明らかに、これらの静的リンク嫌い者は何を話しているのか全く分かっていません！
あたしは数年にArchとArtix Linuxを使用しましたから、これは全く事実ではない事を簡単に証明出来ます。
多くのバイナリがバージョンを変えずにリビジョン番号だけを変更して更新される理由があります。
これは、動的ライブラリが更新される度に、そのライブラリに依存する全てのバイナリを再コンパイルし、更新された動的ライブラリと一緒にパッケージ更新として渡す必要がある為です。
そうしないと、そのバイナリはそのライブラリに対して再コンパイルされるまで動作しなくなります。
全くのピエロの世界です！
それを静的リンク嫌いに伝えると、Debianでは古いバージョンのライブラリをシステム上に保持し、新しいバージョンだけを追加して、古いバイナリが引き続き機能する様にすると言います。
それでは、動的リンクの利点は何だったのでしょうか？
動的リンクのセキュリティ上の利点が嘘である事を認めているのでしょうか？（笑）
これが素晴らしいですよね？
現実は、一部のOSで静的リンクが禁止されている為、プロプライエタリソフトウェアとフリーソフトウェアの両方のソフトウェア開発者がこれらのOSから離れています。
第一の理由は、動的にリンクされたELFファイルを維持するのが非常に厄介である事です。
第二の理由は、静的リンクが出来ない場合、プロプライエタリソフトウェアが存在しない為、殆どの人がこれらのOSを知る事がなく、その為、フリーソフトウェアの開発者もこれらのOS向けにソフトウェアを作成しないのです。
何故なら、誰も使わない物に時間とエネルギーを無駄にする価値がないからです。
従って、プロプライエタリソフトウェアは一般的に悪い物ですが、ユーザーを獲得する為にはそれらが必要です。
これがプロプライエタリソフトウェアがLinuxに存在する理由です。
動的リンクされたバイナリが通常1MiB以下で、静的リンクされたバイナリがしばしば100MiB以上である事は事実です。
これは、本来バイナリ内に存在していたかもしれない物がシステム全体に分散している為、実際にはこのストレージスペースの違いは非常に最小限です。
1つの静的バイナリが64MiBであるのと、1つの動的バイナリ＋500以上の異なる動的ライブラリが合計64MiBである事を気にする必要があるなら、あたしが見る唯一の違いは、動的バイナリが小さいのではなく、動的バイナリがファイルシステムを散らかしているという事です。
macOSでは、Appleが必要な全てのライブラリを1つのディレクトリにバンドル出来るコンテナ形式を提供します。
macOSはこれをバイナリとして扱い、他の全てのOSは通常のディレクトリとして扱います。
しかし、これは過去の悪い決定の為の応急処置に過ぎず、問題の真の解決策ではありません。
プロプライエタリである程度移植可能なバイナリをリリースする事は出来ますが、動的リンクの他の全ての問題は依然として存在します！
他の回避策には、Docker、Kubernetes、AppImage、Flatpak、Snapがあります。
これらは全て、開発者が動的リンクの強制が大きな災害である事を認識している為に存在します。
しかし、DockerとKubernetesの設定が非常に困難で、全く動作しない事もよくあります。
AppImageは一部のLinuxディストロでしか機能しません。
例えば、CRUXでは機能しません。
FlatpakとSnapは非常に膨れ上がり、コンピュータにとって無駄が多く、実際には解決しようとしている問題よりも更に多くの問題を引き起こします。
「モダンな」開発者は「見て、今はDockerコンテナがあるから、ソフトウェアの配布はもう問題ではない！」と言いたがります。
違う！貴様がやっているのは、この世界を1960年代に戻す事だけです。
ただし、それに多くの余分な手順を追加している為、正確にはそうではありません。
この問題を解決する唯一の方法は、動的リンクを違法とし、静的リンクバイナリのみを持つOSを持つ事です。
少なくとも動的リンクへの圧力が益々強まる限り、GNUプロジェクトやBSDがプロプライエタリソフトウェアへの圧力が強まっていた時代に登場したのと同様に。
実際、既にこのようなLinuxディストリビューションが存在します：
他の解決策には、デフォルトでバイナリを静的にリンクするGoやZigの様なプログラミング言語があります。
但し、CやC++コードと混在させる場合を除きます。
OpenBSDとNetBSDは、デフォルトでほぼ全ての動的及び静的ライブラリを提供するから嬉しいです。
そうして、muslプロジェクトはLinux上で静的リンクを非常に簡単にする非常に軽量なlibc実装を提供しています。
この様な取り組みは財政的に支援されるべきです。
過去数十年で作られた問題を解決する唯一の真の解決策だからです。
又は、あたしのソフトウェアの可能な限り多くの静的リンクバイナリを提供する為の努力に対して、あたしを財政的に支援する事も出来ます！♡
以上