みなさん、こんにちは
今日は、純粋に機能的なパッケージマネージャーである
Nixについてお話します。
今度
は純粋に機能
するスクエアホイールを使用して別の自転車を作成するのはなぜですか？
既存のソリューション：
- パッケージの更新に対応できない（更新すると古いパッケージが削除される可能性があるため、これらのパッケージに依存するすべてのプログラムを削除するか、システムの一貫性のない状態に耐える必要があります）
- 個々のパッケージのすべての依存関係を考慮しないでください（これを行うことはできません）
- 彼らは、コンピューターで利用可能なカーネルのバージョン、ライブラリ、パッケージの正確な組み合わせを知らず、知ることができません
- それぞれが単一のパッケージ命名ポリシーを持つ集中リポジトリに焦点を当てています-その結果、これらのリポジトリのパッケージは、同じ基盤技術（RPM、DEB）が使用されている場合でも、しばしば互換性がありません
その結果、祖国の奉仕に昼夜を徹して行うボランティアに多くの労力が費やされます。 :)
この問題を解決するには？ ユトレヒト大学の人々は非常に簡単だと述べました。純粋に関数型言語の式評価値と同じ方法でパッケージを処理してください！ どのように、読者は再び尋ねますか？
このようなもの：
- パッケージは、引数がすべてパッケージの依存関係（つまり、他のパッケージ）である純関数を計算した結果です
- パッケージは、システムにインストールされると変更されません（副作用なし）
上記の2つの文は、
Nixがディスク上のファイルを変更せず、新しいファイルを作成するだけであることを意味します。
「どう？ 私はたった2 GBのドライブしか持っていません！」-おそらく読者はこのようなものを訪れました。 :)実際には、他のパッケージがそれらに依存していない場合、一部のパッケージは安全に削除できるということです。 これは、現代のプログラミング言語のガベージコレクションに非常に似ています。
他のパッケージマネージャーに対する
Nixの最も顕著な利点をリストします。
- 同じパッケージの複数のバージョンを同時に含めることはかなり可能です（たとえば、2つのアプリケーションが同じライブラリの2つのバージョンを必要とする場合に便利です）
更新または削除操作は、他のパッケージによって使用されるファイルを上書きしたり削除したりしないため、他のアプリケーションを損傷することはできません。 - 単一のパッケージのすべての依存関係が監視されます-開発者のマシンで獲得したパッケージは、ユーザーのマシンでも動作します
- 更新操作の原子性と更新をロールバックする機能（更新中にソケットからプラグを抜いたとしても、システムはこれに悩まされません-もちろん、これは明らかな理由で行われるべきではありません）
- ソースコードまたはコンパイルされたバイナリを含むパッケージの透過的なサポート（パッケージが既にコンパイルされた形式で利用可能な場合、 Nixは自動的にコンパイルフェーズをスキップする場合があります）
- バイナリパッチ（利用可能なバイナリを自動的にダウンロードすることに加えて、Nixは2つのバイナリの違いをダウンロードできます）
この楽観的なメモで、私たちはレビュアーを締めくくります。
更新：フォーマット
更新：集合ブログに移動