プログラムがコンパイルされた形式で配布されないのはなぜですか？

しかし、彼らは次のような指示を与えます

cd downloaded_program
./configure
make install

これにより、必要なELFと、おそらくいくつかの.soファイルが作成されます。

Windowsアプリのように、それらをダウンロード用のzipファイルに入れてみませんか？ユーザーがコンパイルする必要がある理由はありますか？

要因を分析しましょう...

分析：

プラットフォームに依存する依存性：開発者がアプリケーションのいくつかのアーキテクチャ固有のバリアントを作成および保守する環境では、いくつかの問題が発生します。

• 異なるバリアントには異なるソースコードが必要です-異なるUNIXベースのオペレーティングシステムは、異なるタスクを使用して同じタスクを実装できます（たとえば、strchr（3）とindex（3））。同様に、バリアントごとに異なるヘッダーファイルを含める必要がある場合があります（たとえば、string.hとstring.h）。

• バリアントごとに異なるビルド手順が必要です—異なるプラットフォームのビルド手順は異なります。違いには、コンパイラの場所、コンパイラオプション、ライブラリなどの詳細が含まれる場合があります。

• 異なるバリアントのビルドは個別に保持する必要があります—単一のソースツリーがあるため、あるアーキテクチャのオブジェクトモジュールと実行可能ファイルが他のアーキテクチャのオブジェクトモジュールと実行可能ファイルと混同されないように注意する必要があります。たとえば、リンクエディタは、SunOS–4用に構築されたオブジェクトモジュールを使用してIRIX–5実行可能ファイルを作成しようとしてはなりません。

• すべてのオペレーティングシステムには独自のリンク管理スキームがあり、必要に応じてELF（実行可能およびリンク形式）ファイルを準備する必要があります。

• コンパイラーは一連の命令であるビルドを生成します。異なるアーキテクチャーは異なる命令セットを意味します（命令セットアーキテクチャーの比較）。そのため、コンパイラの出力はアーキテクチャごとに異なります（例：x86、x86-64、ARM、ARM64、IBM Power ISA、PowerPC、Motorolaの6800、MOS T 6502 など）

セキュリティ：

• バイナリをダウンロードする場合、それが言っていることを行うかどうかはわかりませんが、ソースコードを監査して、システムで自己コンパイルされたバイナリを使用することができます。これにもかかわらず、ユーザーTechmagはコメントで良い点を指摘しました。コードを監査するには、コードを評価する知識と有能なコーダーが必要であり、安全性の保証ではありません。

市場：このセクションには多くの要因がありますが、私はそれを再開しようとします：

• すべての企業がすべてのプラットフォームに到達することを目指しているわけではありません。市場とプラットフォームの人気、そして何を売りたいかによって異なります。

• フリーソフトウェアは、ソフトウェアを可能な限り広く利用できるようにするという精神を持っていますが、ソフトウェアがすべてのプラットフォーム向けに設計されていることを意味するものではなく、それをサポートするコミュニティに依存します。

結論：

すべてのソフトウェアがすべてのプラットフォーム用に設計されているわけではありません。すべてのアーキテクチャとプラットフォームにバイナリを提供するということは、すべてのプラットフォームでコンパイル、テスト、および保守することを意味します。これは作業が多すぎるだけでなく、ユーザーが独自のプラットフォームでコンパイルすれば回避できる場合があります。また、ユーザーは自分が実行していることを認識します。

* nixとその他のさまざまなプラットフォームとソフトウェア環境が存在するため、ソフトウェアを実行できる可能性があり、アプリケーション（またはアプリケーションで使用するライブラリ）を構築できるのは、 「良い」ソフトウェア項目と同様に、これらのコンポーネントの多くの組み合わせ。もちろん、GPLなどのライセンスではソースコードが利用可能である必要があります。そのため、ソフトウェアが正常に動作しない場合でも、通常は可能です（ただし、何が間違っているのか、どのように修正するのかを理解するのは難しいかもしれません）または、作成者が存在しない/存在しない/存在しない場合でも、潜入して修正する第三者。

ソフトウェアをソースコードとして配布することで、ソフトウェアが主張することを実行し、代わりに、または同様に厄介なことを実行していないことを独立して検証することもできます。

まず、あなたの質問は欠陥のある前提に基づいています。プログラムはコンパイルされた形式で配布されます！

Ubuntuにソフトウェアをインストールする通常の方法は、他のほとんどのLinuxディストリビューション、およびより一般的にはほとんどのUnixバリアントのように、パッケージをインストールすることです。Ubuntuでは、ソフトウェアセンターまたは他のパッケージマネージャーを開き、利用可能なソフトウェアを参照します。インストールするパッケージを選択すると、バイナリ（パッケージにプログラムが含まれている場合）がダウンロードされ、マシンにインストールされます。

デフォルトでは、パッケージマネージャーはディストリビューションメンテナーによって作成されたパッケージを提供します。サードパーティのパッケージソースも見つけることができます。Ubuntuは、サードパーティがパッケージを提供するための標準化された方法としてPPAを提供しています。

著者からソフトウェアをコンパイルされた形式でダウンロードすることは最後の手段です。ソフトウェアがパッケージ化されるほど人気が​​ない場合、またはパッケージ化されていない最新バージョンが絶対に必要な場合にのみ、それを行う必要があります。ほとんどの人はこれを行う必要はありません。

ソフトウェアがディストリビューション用にパッケージ化されていない場合、バイナリ形式ではなくソース形式で配布されることがよくあります。これがLinuxの世界で頻繁に発生する主な理由は2つありますが、Windowsの世界ではほとんどありません。1つの理由は、Linuxでのオープンソースプログラムの割合がはるかに高いことです。明らかに、プログラムのソースコードが利用できない場合、配布の唯一の形式はバイナリです。もう1つの理由は、Linuxの世界がはるかに多様化していることです。互換性のないライブラリバージョンのセットごとに異なるバイナリが必要です。これは、多くの場合、各ディストリビューションのバージョンごとに異なるバイナリを意味します。Windowsは、各パッケージの作成者が使用するライブラリをプログラムとともに配布することでこれを「解決」します（その結果、コンピューターは各ライブラリの多くのコピーを、それを使用するプログラムごとに1つ保存します。バグがライブラリで修正された場合、それを使用する各プログラムは更新プログラムを出荷する必要があります）、オペレーティングシステムの新しいバージョンを3年ごとにリリースするだけです。Unixには、はるかに多様性があり、バグ修正の習慣がはるかに多く、配布ごとに異なるバイナリを構築することでライブラリ配布の問題を解決します。

Linuxは、複数の特定のCPUプラットフォームで実行されます。ELFファイル（またはその他の種類の生の実行可能ファイル）を配布した場合、Linuxの一部のバージョンではソフトウェアを実行できない可能性があります。ソフトウェアをできるだけ広く利用できるようにするため、ソースコードを使用することをお勧めします。たとえば、LinuxはSparc、Intel、AMD、ARM、およびその他の種類のプロセッサで実行されます。

たとえば、ELFファイルが特にIntelプロセッサをターゲットにしている場合、他のタイプのハードウェアではソフトウェアを実行できませんでした。ELFはプラットフォームに依存しませんが、ホストするコードはプラットフォームのマシンコードに準拠する必要があります。同様のパッケージ（たとえば、異なるプロセッサをサポートする場合の_386および_586パッケージ）があるディストリビューションの数に気付くはずです。正しい操作を行うには、正しいELFファイルをインストールする必要があります。

同様に、異なる割り込みやリンカーなどを使用するカスタムLinuxバージョンを構築することにした場合でも、コードをコンパイルするにはソースコードが必要です。ソースコードにプラットフォーム固有のビルド手順がなくても、各プラットフォームは異なり、異なるシステムからELFを実行することはできません。

ソースとして配布される最初の理由は、確かにプラットフォームの多様性です。Linuxコミュニティは、その理由と、新しい、部分的に政治的な理由の両方で、その方法論を継続しています。

Windowsなどとは異なり、Linuxは歴史的にABI（アプリケーションバイナリインターフェース）を長期間にわたって安定させることを決して気にしませんでした。重要。

商用オペレーティングシステムは、革新について非常に規律を保つことにより、長期的なアプリケーションの互換性を実現します。新しい機能/ソフトウェアインターフェイスは常に古いものに追加して追加する必要があります。2つのことを維持する必要があり、リリース後に何かを変更する価格は非常に高くする必要があります。または、計画されたアプリケーションの陳腐化の事実を、OS用のソフトウェアを書いている人と一緒に受け入れることができます（これはMSではなく、別のOSベンダーを暗示しています）。

（特定のLinuxディストリビューションの外で）バイナリのみの形で配布されるソフトウェアの長期安定プラットフォームを実現することは、Linuxコミュニティの一部の要素によっても望ましくないと考えられます。両方のプラットフォームの説得力のないユーザーとして、私はそれが良いことでも悪いことでもありません。それはそうです。

多くの場合（少なくとも* nixの世界では）、ソースコードはソフトウェアの最も移植性の高いバージョンです。ソースがあると、共有ソフトウェアがサポートされる可能性のあるすべてのプラットフォームで動作することが保証されます（多くの場合、単にPOSIX準拠を意味します）。バイナリのリリースは、それらのバイナリがリリースされているプラ​​ットフォーム（ソフトウェアとハ​​ードウェアの両方）との互換性のみを保証します。

Windowsでは、バイナリはソフトウェアを共有するための最も便利で移植性の高い形式であることを考慮してください。ソースのコンパイルは通常のWindowsソフトウェア配布モデルの一部ではないため、Microsoftは長年にわたって、OSの複数のバージョン間でバイナリが機能するように努めてきました。http：//www.joelonsoftware.com/articles/APIWar.html

ほとんどのLinuxソフトウェアはフリーソフトウェアです。バイナリではなく、コンパイル手順を使用してソースコードを配布することにより、コンパイルする前にソースコードを確認したり編集したりすることができます。この方法で、プログラムが実際に何をするか、そしてそれが有害ではないことを非常に確信できます。

私が個人的にプログラムの実行可能ファイルを取得するのが好きではない主な理由は、ソースコードが実際に何をしているのかを最初にチェックするのが好きだからです（主に他人のコードを見て楽しむだけです）悪意のあるコードのソースコードもチェックします。

多くの回答は、ほとんどの場合、ソフトウェアはコンパイルされた形式で配布されると言っています。この仮定に同意します。それでも、ソフトウェアをそのソースで配布する方が、コンパイルされた形式で配布するよりも優れている場合があります。

私はそれが本当かどうかはわかりませんが、インターネットの初めには、ネットワーク帯域幅が悪いため、コンパイルされた形式よりもソースによってソフトウェアを配布する方が速い場合があると思います。コードソースはプレーンテキストであるため、多くの場合、コンパイルされた形式のソフトウェアよりも小さくなります。そのため、ユーザーがコンパイルできるのであれば、コードソースを使用してソフトウェアを配布することは、ソフトウェアを共有するためのより良い方法のようです。

多くの異なるプラットフォームで実行される多くのUNIXシステムがあるという事実とは別に、Windowsソフトウェアがこのディストリビューションモーダルから直面する問題を考慮してください。 ）。

心配するのはPCだけですが、32ビットと64ビットの2つのアーキテクチャがまだあります。お気づきのように、Windowsソフトウェアの大部分は64ビットを無視し、32ビットソフトウェアのみを出荷します。64ビットシステムを使用している場合、最適ではないソフトウェアが残ります。次に、ライブラリがあります。あるソフトウェアベンダーは、適切なライブラリが既にインストールされていない場合、プログラムを実行しようとすると奇妙なエラーが発生することを望んでいないため、プログラムにライブラリを含めるだけです（既にこのライブラリを持っている場合でも、ダウンロードを大きくします）。2番目のプログラムも同じことを行いますが、ライブラリのバージョンが異なります。最良の場合、プログラムBには後方互換性のあるライブラリの新しいバージョンが含まれているため、プログラムBをインストールする場合後プログラムAは動作しますが、逆の順序でインストールすると、古いバージョンのライブラリが残るため、プログラムBは中断します。しばしばしかし、ライブラリベンダーは変更になりません下位互換性は、ライブラリの名前を変更する気にしないので、次の2つのプログラムをインストールするために関係なく最初の1が壊れます、で。これは「dll hell」と呼ばれます。

悲しいことに、これを避けるために、ほとんどのWindowsソフトウェアは、共有ディレクトリではなく独自のプログラムディレクトリですべてのライブラリを配布することに頼っています。そのため、各プログラムには独自のプライベートライブラリがあり、互いに共有することはありません。そもそもDLLのポイントであり、すべての重複ライブラリをダウンロードするためにより多くのRAMとディスク容量と時間を使用することになります。

これが、オープンソースソフトウェアがソース形式で公開されている理由であり、OSベンダーは、依存関係の問題を整理し、実際に必要なプリコンパイル済みバイナリのみをダウンロードするパッケージマネージャーを考え出しました。これは、多くの異なるプラットフォームで実行される多くの異なるUNIXシステムがあるという事実も扱います。