Linux実行形式とソフトウェア配布パッケージについて


8

Linuxの実行形式とソフトウェア配布パッケージを理解できません。Linux自体には非常に多くの異なるディストリビューションがあり、すべてのソフトウェアパッケージがディストリビューションごとに個別にコンパイルされているようです。どうしてこれなの?一部の「パッケージ」が別のディストリビューションにインストールするように作成されていることを理解していますが、ソフトウェアの実行形式は異なりますか?

また、多くのLinuxユーザーがGUIバージョンよりもコマンドプロンプトバージョンのアプリケーションを好むのはなぜですか?小さなフットプリントの必要性は理解できますが、適切にコーディングされていれば、GUIアプリでも小さなフットプリントを使用できます。

回答:


13

パッケージマネージャーと依存関係

ほとんどのLinuxディストリビューションでは、ソフトウェアのインストールと削除にパッケージマネージャーを使用しています。パッケージマネージャーは、(ほとんどの)ソフトウェアをダウンロードできる中央リポジトリを使用できること、ソフトウェアを1つのまとまりのあるグループとしてインストールできるバンドルに編成できること、主な利点(自動など)を提供します。パッケージをアンインストールできるように、依存関係の処理とパッケージによる変更の追跡。

特定のソフトウェアは、そのソフトウェアに再実装された場合に冗長になる義務を実行するために、特定のライブラリまたは他のプログラムを必要とする場合があります。パッケージは、これらの依存関係の表現を可能にします。

違い:パッケージの形式と戦略

いくつかの異なるパッケージマネージャーが存在します。既存のものは一部の人々のニーズを満たしていないため、それぞれが作成されました。各パッケージマネージャーには、独自の形式のパッケージが必要です。

さらに、ディストリビューションが異なると、含まれるソフトウェアの要件も異なります。ソースコードからマシンの実行可能ファイルにコンパイルされるときに指定されるオプションに応じて、機能が異なる可能性のあるソフトウェアは多数あります。一部のディストリビューションは、完全な機能セットと豊富なエクスペリエンスを提供したい一方で、他のディストリビューションは、可能な限り無駄のないシンプルなエクスペリエンスを提供したいと考えています。また、ディストリビューションは、そのディレクトリ構造を別の方法でフォーマットするか、別の初期化システムを使用することを決定する場合があります。彼らはソフトウェアを異なる方法でバンドルすることを決定するかもしれません:2つの異なるディストリビューションに「dev-utils」と呼ばれるパッケージがあるかもしれませんが、その1つのバージョンにはyacc他の人はしませんが。これらの異なるニーズのため、ディストリビューションは異なる方法でソフトウェアをコンパイルすることを選択します。

これが、パッケージマネージャーに適した形式のパッケージがある場合でも、そのパッケージが別のディストリビューション向けである場合は機能しない可能性があるためです。たとえば、そのパッケージはyaccインストールに依存している可能性があり、「dev-utils」パッケージが必要であることを介してその依存関係を示しましたが、「dev-utils」にはが含まれていませんyacc。今、満たされていない依存関係でインストールされたパッケージがあります。

それは本当に問題ではありません。

Linuxディストリビューションであることの大きな部分は、中央のソフトウェアリポジトリを維持することです。ディストリビューションはあなたのためにこれらすべてを維持します。これにより、ソフトウェアのインストールが非常に簡単になります。通常、パッケージマネージャーを使用して、いくつかのパッケージを検索して選択し、インストールするように指示します。残りはあなたの代わりになります。Windowsソフトウェアのインストールプロセスには、サードパーティのWebサイトでのソフトウェアの検索、適切なダウンロードリンクの検索、ダウンロード、ウイルスチェック、およびインストールプログラムの実行などが含まれます。その全体の混乱はLinuxの標準ではありません。

リポジトリにすべてを含めることはできません

現在、必要なソフトウェアの一部がディストリビューションのリポジトリにない場合があります。ソフトウェアリポジトリによって提供されるパッケージは、ディストリビューションの差別化機能の1つです。ディストリビューションのリポジトリで必要なソフトウェアが見つからない場合、3つの方法が考えられます(実際には、2つの方法に加えて、実際に問題を解決する方法があります)。

コミュニティリポジトリ

多くのディストリビューションには、そのディストリビューションに関係のない人々が管理している非公式のリポジトリがあります。UbuntuはPPAと呼び、FedoraはFedora People Repositoriesと呼びます。Arch Linuxにはサードパーティのリポジトリに特定の名前はありませんが、パッケージの「レシピ」のコレクションであるAURがあります(注:AURは1つだけです)。機能しない場合は簡単にアンインストールできるため、これらのソースのいずれかからパッケージをインストールしてみてください。

ソースからコンパイル

必要なものが含まれている非公式リポジトリが見つからない場合、ソースからのコンパイルは難しくありません。ディストリビューションの開発パッケージをインストールする必要があります。これには、コンパイラー、リンカー、パーサー、およびソフトウェアのコンパイルに通常必要なその他のツールなどの基本的なものが含まれます。次に、プロジェクトのソースコード(ほとんどの場合、.tgzorまたは.tbz(「tarball」と呼ばれます)にパッケージ化されています。それを独自のディレクトリにダウンロードし、それを抽出します(を使用してtar -xf filename.tgz、通常、作成した1つのディレクトリに移動します。そのディレクトリと呼ばれるファイルであってもよいREADMEINSTALL。それらのほとんどが同じことを行うためにあなたを伝える次のいくつかの手順は、コマンドラインで実行されます実行します。。。それが存在する場合は、先に行くと、それを読んでls、呼び出された実行可能ファイルを探しconfigure。存在する場合は、次のように実行し./configureます。場合によっては数分かかることがあります。これは通常、ディストリビューションでどのように設定されているかを把握するためにいくつかのテストを実行し、このソフトウェアのコンパイルに必要なツールがあることを確認します。次のステップはを実行することmakeです。これは実際にソフトウェアをコンパイルします。コンパイルするソフトウェアのサイズに応じて、数分から数時間の時間がかかる可能性があります。それが完了したら、を実行しmake installます。これによりソフトウェアがインストールされます。これには、コンパイルの結果をファイルシステムの適切な場所にコピーすることが含まれます。その後、ソフトウェアは使用可能になります。

これは長いセクションでしたが、「README、。/ configure、make、make install」として要約されています。それは覚えておくべきルーチンです。

別のディストリビューションからパッケージをインストールします(これを行わないでください)

これ代替であるという理由だけでこれをリストしますが、それはほぼ確実にうまく終わらないでしょう。他のディストリビューション用のパッケージをインストールすることは可能であり、そうしたいと思うかもしれません。まあ、しないでください。システムを十分に理解するまでは、それを行わないでください。実際、それが可能であるとしても、それを行う方法を示すコマンドをここに配置するつもりはありません。これが唯一のオプションであると思われるポイントに達した場合は、パッケージマネージャーを使用してパッケージをインストールしないでください。代わりに、パッケージから物を引き出し、システムに手動で配置します。また、必要に応じて元に戻せるように、実行したことについてのメモも含めます。

コマンドラインビット

一部の人々は、それが与える利点のためにコマンドラインを好みます。これらは次の3つに要約できます。

  • 自動化のしやすさ
  • 速度(GUI内のあちこちをクリックするのと比較して)
  • 表現力

これらの最大のものは表現力です。コマンドラインで実行できることで、グラフィカルインターフェイスでは実行できないものがあります。

最後に、コマンドラインの説明は、このような便利なフォーラムで頻繁に提供されます。これは、「ここをクリックすると、そこにある」タイプの指示を与えるよりも正しい情報を伝える方がはるかに簡単だからです。


6

長い答えてすみません。迅速かつ汚いことが必要な場合は、概要を読んでください。

概要

  • 実行形式は同じです。
  • パックされたプログラムが互換性がある場合でも、互換性のないさまざまなパッケージマネージャーがあります。(ファイルのようなインストーラーファイルとしてパッケージを見ることができ.msiます)。
  • 基本的に、異なるディストリビューション/バージョンにはコアライブラリの異なるバージョンがあり、一貫性と安定性の理由から、これらのバージョンに対してアプリケーションを構築する必要があります。(dll hellのLinuxバージョン)。
  • ディストリビューションが異なれば、動作も少し異なり、場合によっては互換性の問題になることがあります。
  • コマンドラインの方が高速で、UNIXコマンドラインはWindowsコマンドラインよりもはるかに優れています。

パッケージマネージャー

まず第一に、パッケージマネージャー。パッケージマネージャーの主な目的は、インストールされたパッケージとそのパッケージを構成するファイルのデータベースを維持することです。

パッケージマネージャーを使用すると、パッケージを簡単にインストールでき、一般的には簡単に削除できます。また、パッケージで、システムの一貫性を維持するためにインストール/削除時に実行する必要があるさまざまなスクリプトを指定することもできます(パッケージをサブシステム関連のデータベースに登録するなど)。

さまざまなパッケージマネージャー

さまざまな長所と短所を持つさまざまなパッケージマネージャーがあります。例としては、rpmとdebianパッケージマネージャー(.debファイル)がありますが、他にもあります。これらのパッケージマネージャーは明らかに異なる形式を必要とするため、互換性がありません。

異なるディストリビューションまたはバージョン

Linuxディストリビューションの大部分はオープンソースであるため、Windowsシステムよりもはるかに多くのコードを再利用できます。アプリケーションは、その機能のさまざまな部分にいくつかのライブラリを使用する場合があります。それらのライブラリー自体も、しばしば同じライブラリーを使用することがあります。

残念ながら、ライブラリは異なるバージョンで存在し、それらのいくつかは互換性がありません(特に、事前にコンパイルされた実行可能ファイルのバイナリ互換性)。Unixシステムでは複数のバージョンがうまく共存できます(その観点からはdllの地獄が少ない)が、ほとんどの場合、1つの実行中のプログラムで2つの異なるバージョンのライブラリを使用するとクラッシュが発生します。

したがって、バイナリディストリビューションは、多くの場合、独自のバージョンをアップグレードして、さまざまなコアパッケージの新しいバージョンに移行します(他のケースでは、大きな更新が必要です)。

他の異なるファイル

ディストリビューションは、特定のファイルの配置方法や構成の管理方法も異なります。そのパッケージに影響を与える可能性のあるパッケージによって異なります。

コマンドライン

Unixは主にワークステーションとサーバーのオペレーティングシステムです。つまり、専門のシステム管理者を念頭に置いて設計されています。自動化はシステム管理ツールボックスの重要な部分であり、シェルスクリプトはそのための手段です。グラフィカルファイルマネージャで、先頭に0〜1000個のファイル名を追加してみてください。

管理者は多くのマシンを管理することが多いため、多くのシステムで同じことを行う必要があります。sshのようなツールを使用すると、多数のシステムでタスクを一度に実行するのが非常に簡単で、コンピューターが仕事をするのを待つだけです。

正確な仕様、自動化、再現性により、コマンドラインの可能性は、管理タスク用のグラフィカルツールよりはるかに優れています。Unixには多数の異なるシェルが用意されており、この競争により、Windowsコマンドプロンプトとほとんど比較できない非常に強力なシェルが作成されました。

マイクロソフトは実際にこれをよく理解しており、コマンドラインの代替としてpowershellを提供しています。また、Windowsサーバーの最新バージョンは主にコマンドラインで管理されています。


3

実行可能形式はすべてのディストリビューションで同じですが、実行可能形式は、適切に動作するために追加の基盤ソフトウェアが必要になる場合があります。Redhatベースのディストリビューションを見ると、インストール製品はrpmであり、特定のソフトウェアのすべての要件が含まれており、要件が満たされない限り、デフォルトではそのソフトウェアはインストールされません。(yumの代わりですrpmまた、一部のRedhatベースのバージョンで使用されています)。定義により、GUIはコマンドプロンプトインターフェイスよりもはるかに大きなフットプリントを持つ必要があります。UNIXの基本的な哲学は、すべてを単純化して、特定のタスクが可能な限り効率的に機能するようにすることです。そのため、別のタスクの入力にチェーンして別のタスクを実行できるように、そのタスクの出力で単一のタスクを実行する非常に多くのユーティリティがあります。


正確には、yumは代替ではなく、rpmよりも上で動作し、より良いインターフェースとリポジトリのような機能を提供します。
rvs '29年

1

ディストリビューションによってインストールの前提条件は異なります。ただし、複数のディストリビューションで動作するRPMまたはDEB(または他のパケット管理システム用の他のパッケージ)があります。Linuxの哲学は、ソースコードをすぐに利用できるようにします。独自のソフトウェアをコンパイルする場合、それはすべてのディストリビューションでほぼ同じルーチンであり、常に.tar.gz使用するアーカイブと同じです。

コンパイルされたRPMは、システムの一部に似ています。スタンドアロンエンティティとしてのアプリケーション自体は、すべてのターゲットで配布およびコンパイルされることを意図しています。

2つ目の質問はまったく異なります。まあ、「多くのLinuxユーザー」はさまざまな理由でCLIアプリケーションを好みます。メモリフットプリントが小さいのは1つの理由にすぎません。SSHを使用する場合、特にサーバーのオフサイトで作業する場合、CLIアプリケーションはより意味があります。多くの場合、これらのサーバーにはグラフィカル環境がインストールされていません。デーモン化されていないプログラムを実行している場合、それらは非常に簡単に中止できます。Ctrl- c、およびプログラムがなくなりました。また、多くのプログラムはコンソールにログを記録するため、デバッグが簡単です。プログラミング時には、ほとんどのコンパイルをコンソールで実行します。これは、コンパイルのデバッグを迅速に行うのに適しています。それか、またはログファイルを読み取ると、コンソールの読み取りが速くなる場合があります。


0

アーチ。 または、全体として開発されたFreeBSD。(RHEL、SLESなどは全体として$ upportedです。)

ラップトップの使用:ミント

使用可能なハッカビリティ:Arch。

サディスティックなハッカビリティ:Genoo。

楽しいハック機能:LFS。

サポート性(サーバー):RHEL、Ubuntu LTS、FreeBSD(Linuxとは異なります)。


回答を編集して、発言しようとしている内容をより明確にし、タイプミスや文法の誤りをいくつか修正したい場合があります。
haziz
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.