PC-BSDチームが直面した、最終的にPBIを廃棄してポートに戻ることになった、具体的な技術的/組織的理由の詳細は何ですか?
コンパイルとパッキングが難しいためでしたか?彼らが作成したハードリンクの問題が原因でしたか?または、依存関係を収集して一緒にコンパイルするための作業量のためですか?
ソフトウェアを作成する同じチーム(たとえば GNUCash )が、コンパイラーに関して* NIXを残している間に、Windows用の自己完結型バージョンを提供するために時間と労力を費やす理由を知りたいだけです。 /インストーラ。
ポートとライブラリが優れている理由については質問していません(簡単なセキュリティアップグレードなど)。また、パッケージとWindowsの好みや意見についても質問していません。単に、PBIの廃棄につながった技術的な理由だけです。 PBI(0install、NixOS)のルートが技術的に実現可能でない、または広く採用されていない理由を具体的に尋ねています。
PC-BSDでPBIファイル形式が廃止された理由は実際には3つあります。
PBI形式は、FreeBSDのパッケージ形式を提供するために作成されました(以前は「実際の」パッケージシステムは存在しませんでしたpkg-portsコレクションのみ)。
pkgが最終的にFreeBSD自体(9.2/10.0?)内で開発/実装されると、より多くの人々が貢献するため、競合するフォーマットを維持する理由はほとんどありませんでした。二次パッケージ形式よりも「公式」FreeBSDパッケージを修正すること。
PBIファイル形式は、PC-BSDでのユーザーの問題の最大の原因でした。
PC-BSDユーザーのほとんどは、以前のLinuxユーザーであり、自己完結型/制限付きのアプリケーションスコープの概念を理解していなかったため、アプリ「A」がアプリ「B」を検出/起動できなかった場合(「A」がで実行されていたため)制限されたコンテナ)アプリケーション/システムで障害が発生したと想定しました。これは、さまざまなLinuxベースのアプリケーションすべてがシステムとの統合に向けて着実に移行していた(スタンドアロンアプリケーションの概念から離れた)時期でもあったため、制限された環境内で機能しないアプリケーションが増えていきました。 PBIからpkgに切り替えることを決定した時点では、制限のあるPBIコンテナー内で正常にパッケージ化/実行できるアプリはFreeBSD上に約200しかありませんでしたが、標準化されたpkgFreeBSD上のすべての23000+パッケージに即座にアクセスできるシステム。これにより、開発者のオーバーヘッドも削減されました。これは、FreeBSDコミュニティ全体で、(2人の)PC-BSD開発者がすべてのバージョンを別々に維持しようとするのではなく、アプリケーションをテスト/修正するためです。
技術的な問題
一般的なコンテナシステムとこれが課す制限/制限の他に、ファイル形式全体を廃棄するのに役立つ技術的なバグがいくつかありました。
読み込み時間
PBIの開始には約30〜45秒かかりましたが、pkgには約2秒かかりました。これは主に、コンテナを初期化し、コンテナ内にライブラリをロードするためです。
アプリケーションのコンパイル
PBIは、通常とは異なるランタイムプレフィックスを使用してコンパイルする必要がありました(どのアプリが想定されています)が、多くの場合、アプリ自体がハードでした-アプリが実際に正しく構築/機能するのを妨げるコード化されたパス/設定。これはまた、アプリのビルドで問題が発生したときに、異なるビルド設定を使用していたため、アプリ開発者やFreeBSDポーターからサポートを受けることができなかったことも意味します。
開発者のメンテナンス
先に触れたように、PBIシステムは非常にメンテナンスが多かった。ビルドシステムは、アプリをビルドするときに(ランタイムプレフィックスの変更のために)常に奇妙な障害に遭遇していましたが、アプリdidをビルドするときは、開発者が手動でロード/テストして、実際に起動したことを確認し(組み込みパスの問題をキャッチ)、アプリケーションのメタ情報も更新/維持する必要がありました(この追加情報は現在も保持しています)。 -ただし、pkgシステムへの追加情報オーバーレイとして扱います)。つまり、2人が維持するのは大変な作業だっただけでなく、ほとんどのLinuxアプリが設計されたように基本システム環境に統合されていなかったため、結局のところ、アプリ自体はほとんど機能しませんでした。
PBIファイル形式はPC-BSDから削除されましたが、アプリケーションの区分化に専念していることに注意してください。代わりに、既存のFreeBSDサブシステム(jailsフレームワークなど)を使用して、信頼性の高い/安全なランタイムコンテナーを確保することに重点を置いていますが、ユーザーがインストールする「標準」アプリケーションは、他のOSと同じように正常に/確実に機能します。