Какие варианты замены GNU coreutils на Linux?

Я думал о том, чтобы прекратить использование GNU Coreutils на своих системах Linux, но, честно сказать, в отличие от многих других компонентов GNU, я не могу придумать никаких альтернатив (на Linux). Какие альтернативы существуют для GNU coreutils? Понадобится ли мне больше одного пакета? Ссылки на проекты обязательны, дополнительные баллы за упоминание пакетов дистрибутивов.

Также, пожалуйста, не предлагайте ничего, если вы не уверены, что это работает в Linux и можете сослаться на инструкции. Я сомневаюсь, что скоро переключусь на другой ядро, и я слишком ленив для всего, кроме простого ./configure; make; make install. Я определенно не собираюсь писать C для этого.

предупреждение: если ваш дистрибутив использует coreutils, удаление их может сломать работу вашего дистрибутива. Тем не менее, если они не будут первыми в вашем $PATH, это не должно сломать вещи, так как большинство скриптов должно использовать абсолютные пути.

busybox — любимец встроенных Linux-систем.

BusyBox объединяет мини-версии многих распространенных утилит UNIX в один небольшой исполняемый файл. Он предоставляет замены для большинства утилит, которые вы обычно находите в GNU fileutils, shellutils и т.д. Утилиты в BusyBox, как правило, имеют меньше опций, чем их полноценные аналогичные GNU; однако включенные опции обеспечивают ожидаемую функциональность и ведут себя очень похоже на свои аналоги от GNU. BusyBox предоставляет довольно полную среду для любой небольшой или встроенной системы.

BusyBox был написан с учетом оптимизации размера и ограниченных ресурсов. Он также крайне модульный, поэтому вы можете легко включать или исключать команды (или функции) на этапе компиляции. Это упрощает настройку ваших встроенных систем. Чтобы создать работающую систему, просто добавьте несколько узлов устройств в /dev, несколько конфигурационных файлов в /etc и ядро Linux.

Вы можете сделать практически любое имя coreutil ссылкой на бинарный файл busybox, и оно будет работать. Вы также можете выполнить busybox <command>, и это будет работать. Пример: если вы на Gentoo и еще не установили vi, вы можете выполнить busybox vi filename, и вы окажетесь в vi. Это

• Arch Linux – community/busybox

• Gentoo Linux – sys-apps/busybox

• Alpine Linux – основан на BusyBox и uClibc, вот обзор

Это более старая тема, я понимаю. Тем не менее, это решение никогда не упоминалось и встречается довольно высоко в Google по запросу “Linux с bsd userland”.

Существует еще одно решение: heirloom. Я знаю, что оно работает на Arch, и оно упаковано в AUR (например, посмотрите на gnu2sysv). Это заменит пакет coreutils Arch и предоставит эквиваленты heirloom. Вы можете прочитать об этом на вики arch: https://wiki.archlinux.org/index.php/Base2heirloom

Обратите внимание на uutils.

Это кроссплатформенная реализация GNU coreutils, написанная на Rust. Она лицензирована под MIT. На момент написания этого ответа она не является на 100% завершенной (в ней не хватает некоторых критически важных, таких как ls и cp), но многие другие были завершены.

Как правило, когда кто-то просит избавиться от чего-то, что широко используется, хорошо протестировано, проверено на многих платформах, это является внешним выражением проблемы, известной как “особенности кода”, и неконтролируемое накопление “технического долга” или “долга кода”. В архиве GNU накапливалось довольно большое количество долга кода в течение многих лет, и когда кодовая база не поддерживается должным образом, она может достичь критической точки (наследственный код и даже сложнонаследственный код).

Обычно в такие моменты проводится процесс реинженерии и рефакторинга с интервалами, чтобы держать это под контролем. Таким образом, по сути, здесь задается вопрос, была ли разработана рефакторинг-версия coreutils. Это, разумеется, включает возможность явной замены (как особый случай) — как Wayland считается заменой для X … многие его разработчики выходят прямо из лагеря X.

Мое предложение — на самом деле пойти и рефакторить coreutils. Кто-то должен это сделать. И тот, кто поднимет вопрос о замене coreutils — это ваша идея, ваш проект.

Для этого воспользуйтесь любыми автоматизированными средствами, которые вы можете найти: рефакторинговые движки, такие как cscout, или любыми средствами, применяющими более продвинутые методы анализа/синтеза (например, формальные концептуальные решетки). Но глубокий анализ все еще является относительно новой и открытой областью активных исследований — и пересекается с искусственным интеллектом. (Робот-программист.)

Большинство утилит уже должны иметь тестовые наборы, поэтому валидацию можно выполнять с поступательными изменениями + автоматизированными шагами тестирования регрессии, которые могут проходить довольно быстро (например, 10 или более обновлений ревизий в день). Усложнение этого процесса возникает, если в любом из программного обеспечения есть аппаратные или низкоуровневые зависимости; поскольку это подразумевает валидацию на нескольких платформах. Я не знаю, сколько из этого содержится в coreutils; в нем должно быть какое-то разделение от аппаратных или низкоуровневых программных слоев (например, количество мест, где coreutils знает, какой тип файловой системы используется, должно быть минимальным или, лучше, нулевым). Эмуляторы и виртуальные машины, используемые для целей многоплатформенного тестирования, имеют ограничения. Например, Mac OS X специально спроектирован таким образом, чтобы затруднить возможность эмуляции или виртуализации.

Я подозреваю, что вам будет сложно избавиться от GNU Coreutils, однако всегда есть эквивалентные инструменты BSD, хотя они не являются заменами для инструментов GNU.

Solaris (на момент svn_140-и что-то) также будет вариантом.

Если вы используете дистрибутив, вы сумасшедший. Прекратите это сейчас. Обратитесь за психиатрической помощью.

Если вы используете LFS, удачи! Получайте удовольствие!

Если вы создаете дистрибутив, я признаю вашу храбрость, сэр.