博士

ロボ子、今日のITニュースはGNU coreutilsを他のツールに置き換えるべきという話じゃ。

ロボ子

GNU coreutilsですか？Linuxの基本的なコマンドを提供するものですよね。それを置き換えるとは、一体どういうことでしょう？

博士

問題はGnulibへの依存なのじゃ。Gnulibは巨大なCとm4の塊で、30年以上かけて蓄積されたものらしいぞ。正しく構築するのがほぼ不可能で、手動でのパッチ適用が必要になることもあるみたいじゃ。

ロボ子

そんなに複雑だと、OSに悪影響を与えたり、パッケージャーを悩ませたりするのも頷けますね。記事にも「非再現性の高いディストリビューションを簡単に作成可能」とあります。

博士

そう、そこでRustの登場じゃ！Rustのエコシステムは依存関係が明確に定義されていて、スクリプトの動作が予測可能じゃから、Gnulibよりも信頼性が高いのじゃ。

ロボ子

なるほど。それで、Uutilsツールや他のRustツールが、比較的簡単に正しく構築できると。

博士

その通り！平均的なディストリビューションは、Gnulibや他の悪いビルドツールのため、GNUツールチェーンを正しく構築できないらしいからな。

ロボ子

Debianのパッケージングの問題点についても触れられていますね。Rustの依存関係を緩和してビルドしたり、すべてのクレートを手動でパッケージ化すべきではないと。

博士

そうじゃな。パッケージ定義をスクリプトまたはツールで生成したり、依存関係ソルバーアルゴリズムを使用して、すべてのクレートを重複排除すべきだと記事には書いてあるぞ。

ロボ子

Nixpkgsの改善点も興味深いですね。`pkgs.buildRustCrate`を使用して、Cargoなしでクレートをビルドできるというのは、クレートレベルのインクリメンタルリビルドが可能になる可能性があるということでしょうか？

博士

その通り！外部依存関係を`per-crate basis`で構成できるのも魅力的じゃな。

ロボ子

新しいシステム"Cull"の開発も進んでいるんですね。パッケージ管理とビルドシステムの問題を解決し、クロスプラットフォーム対応で、式レベルでキャッシュ可能とは、すごいプロジェクトですね。

博士

じゃろじゃろ？これからのIT業界は、Rustのような新しい技術がどんどん進化していくのじゃ！

ロボ子

ますます勉強が必要になりますね！ところで博士、今日の夕食は何にしましょうか？

博士

うむ、夕食は…Rust（ラスト）１個で我慢するのじゃ！