LinuxでGNU coreutilsを置き換えるオプションはありますか？

私は自分のLinuxシステムでGNU Coreutilsの使用を中止することを考えてきましたが、正直なところ、他の多くのGNUコンポーネントとは異なり、（Linuxで）代替手段を考えることはできません。GNU coreutilsにはどのような代替手段がありますか？複数のパッケージが必要ですか？プロジェクトへのリンクは必須です。ディストリビューションパッケージに名前を付けるためのボーナスポイントです。

また、Linuxで動作することがわかっていて、指示を参照できる場合を除き、提案しないでください。私はすぐにカーネルを切り替えることを疑っています./configure; make; make install。確かにCをハッキングするつもりはありません。

警告：ディストリビューションがcoreutilsを使用している場合、それらを削除するとディストリビューションの機能が損なわれる可能性があります。ただし$PATH、ほとんどのスクリプトは絶対パスを使用する必要があるため、これらを最初に配置しても問題はありません。

busybox 組み込みLinuxシステムのお気に入り。

BusyBoxは、多くの一般的なUNIXユーティリティの小さなバージョンを1つの小さな実行可能ファイルに結合します。通常、GNU fileutils、shellutilsなどにあるほとんどのユーティリティの代替品を提供します。BusyBoxのユーティリティは、通常、フル機能のGNUいとこよりもオプションが少なくなっています。ただし、含まれているオプションは期待される機能を提供し、GNUのオプションと非常によく似た動作をします。BusyBoxは、小規模または組み込みシステム向けのかなり完全な環境を提供します。

BusyBoxは、サイズの最適化と限られたリソースを考慮して記述されています。また、非常にモジュール化されているため、コンパイル時にコマンド（または機能）を簡単に追加または除外できます。これにより、組み込みシステムを簡単にカスタマイズできます。動作中のシステムを作成するには、/ devにいくつかのデバイスノード、/ etcにいくつかの構成ファイル、Linuxカーネルを追加するだけです。

ほとんどのcoreutil名をbusyboxバイナリへのリンクにすることができ、それは機能します。実行することもできますbusybox <command>。例：Gentooを使用していて、viまだインストールしていない場合は、実行busybox vi filenameしてviを実行できます。それは

• アーチのLinux - コミュニティ/ busyboxの

• Gentoo Linux - sys-apps / busybox

• Alpine Linux -BusyBoxとuClibcに基づいて、概要を示します

これは古いトピックです。ただし、このソリューションは言及されたことはなく、Googleで「bsd userlandを使用したLinux」で比較的高い評価を得ています。

別の解決策があります：家宝。Archで動作し、AURにパッケージ化されていることは知っています（たとえば、gnu2sysvを見てください）。これにより、Archのcoreutilsパッケージが置き換えられ、家宝に相当するものが提供されます。archのwikiですべてを読むことができます：https : //wiki.archlinux.org/index.php/Base2heirloom

uutilsをチェックしてください。

これは、Rustで記述されたGNU coreutilsのクロスプラットフォーム実装です。MITライセンスです。この回答を書いている時点では、100℅完全ではありません（lsandのようないくつかの重要なものがありませんcp）が、他の多くのものは完了しています。

GNU Coreutilsを取り除くのに苦労すると思いますが、GNUツールのドロップイン置換ではありませんが、同等のBSDツールが常にあります。

通常、誰かが広範に使用され、十分にテストされ、多くのプラットフォームで検証されているものから逃れようとするとき、それは「コード臭」として知られる根本的な問題と「技術的負債」または「コード債務"。GNUアーカイブは長年にわたってかなりの量のコードの借金を積み上げており、コードベースが適切に維持されていない場合、ブレークポイント（レガシーコード、さらには病的なレガシーコード）に達する可能性があります。

通常、これを制御下に保つために、リエンジニアリングとリファクタリングのプロセスを定期的に実行します。したがって、ここで提起されている本当の問題は、coreutilsのリファクタリングバージョンが開発されているかどうかです。もちろん、これには（特別なケースとして）完全な交換の可能性が含まれます-WaylandがXのためにピッチされているように...その開発者の多くはXキャンプから直接出てきます。

私の提案は、実際にコアユーティリティをリファクタリングすることです。誰かがやらなきゃ。そして、coreutilsの置き換えの問題を提起する人-あなたのアイデアはあなたのプロジェクトです。

この目的のために、cscoutなどのリファクタリングエンジン、またはより高度な分析/合成方法（形式的な概念ラティスなど）を適用するあらゆる自動化を利用できます。しかし、詳細な分析は、まだ比較的新しくオープンなアクティブな研究分野であり、人工知能にまで及びます。（ロボットソフトウェアエンジニア。）

ほとんどのユーティリティにはすでにテストスイートが配置されているはずなので、段階的な段階的な変更と自動化された回帰テストのステップで検証を行うことができます。これは非常に高速です（たとえば、1日あたり10回以上のリビジョン更新）。ソフトウェアスイート内のどこかにハードウェアまたは低レベルのソフトウェアの依存関係がある場合、このプロセスが複雑になります。それは複数のプラットフォームでの検証を伴うためです。coreutilsにあることの多くは知りません。ハードウェアまたは低レベルのソフトウェアレイヤーから何らかの分離があるはずです（たとえば、coreutilsがどのタイプを知っているかの数それがオンになっているファイルシステムの最小値、またはより良いゼロでなければなりません。）エミュレーターと仮想マシンは、マルチプラットフォームのテストを行う目的で使用されるため、制限があります。たとえば、Mac OS Xは、エミュレートまたはVMする機能を妨げるように特別に設計されています。

Solaris（svn_140-somethingの時点）もオプションになります。

ディストリビューションを使用している場合、あなたは狂っています。やめて 精神医学の助けを求める。

LFSを使用している場合、ロックオン！楽しむ！

ディストリビューションを作成している場合は、勇敢な先生を称賛します。