Обычно, когда кто-то просит уйти от того, что широко используется, хорошо протестировано, проверено на многих платформах, это является внешним выражением основной проблемы, известной как «запах кода» и неконтролируемое накопление «технического долга» или «кода». долг». Архив GNU накапливал довольно большую задолженность по коду за эти годы, и, если кодовая база не поддерживается должным образом, она может достичь критической точки (унаследованный код и даже болезненный унаследованный код).
Как правило, можно проводить процесс реинжиниринга и рефакторинга через определенные промежутки времени, чтобы держать его под контролем. Итак, реальный вопрос, который ставится здесь, заключается в том, была ли разработана переработанная версия coreutils. Это, конечно, включает в себя возможность прямой замены (как особый случай) - очень похоже на то, что Вейленд рассчитан на Х ... многие его разработчики выходят прямо из лагеря Х.
Мое предложение состоит в том, чтобы на самом деле пойти и рефакторинг coreutils. Кто-то должен это сделать. А кто бы ни поднимал вопрос о замене coreutils - ваша идея вашего проекта.
Для этого используйте все средства автоматизации, которые вы можете найти: механизмы рефакторинга, такие как cscout, или все, что использует более продвинутые методы анализа / синтеза (например, формальные концептуальные решетки). Но глубокий анализ все еще является относительно новой и открытой областью активных исследований - и переходит к искусственному интеллекту. (Робот-программист.)
Большинство утилит уже должны иметь на своем месте наборы тестов, поэтому проверка может быть выполнена с постепенным пошаговым изменением + автоматизированные этапы регрессионного тестирования; который может идти довольно быстро (например, 10 или более обновлений в день). Усложнение этого процесса происходит, если в программном комплексе есть аппаратные или низкоуровневые программные зависимости; так как это влечет за собой проверку на нескольких платформах. Я не знаю много из того, что есть в coreutils; в нем должно быть какое-то отделение от аппаратного или низкоуровневого программного уровня (например, количество мест, где coreutils знает, какого типафайловой системы, в которой она включена, должна быть минимальной или, что еще лучше, нулевой.) Эмуляторы и виртуальные машины, используемые для целей многоплатформенного тестирования, имеют ограничения. Например, Mac OS X специально разработана таким образом, чтобы препятствовать возможности эмулировать или виртуализировать ее.