Будь-які варіанти замінити GNU coreutils в Linux?

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

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

попередження: якщо ваш дистрибутив використовує coreutils, їх видалення може порушити спосіб функціонування вашого дистрибутива. Однак якщо їх не буде першим у вашому, $PATHне слід порушувати справи, оскільки більшість сценаріїв повинні використовувати абсолютні шляхи.

busybox улюблений із вбудованих систем Linux.

BusyBox поєднує крихітні версії багатьох поширених утиліт UNIX в єдиний невеликий виконуваний файл. Він надає заміни для більшості утиліт, які ви зазвичай знаходите у файлових файлах GNU, оболонках і т. Д. Утиліти в BusyBox зазвичай мають менше варіантів, ніж їх повнофункціональні двоюрідні брати GNU; проте включені варіанти забезпечують очікувану функціональність і ведуть себе дуже схоже на своїх колег з GNU. BusyBox забезпечує досить повне середовище для будь-якої невеликої або вбудованої системи.

BusyBox написаний з оптимізацією розміру та обмеженими ресурсами. Він також надзвичайно модульний, тому ви можете легко включати або виключати команди (або функції) під час компіляції. Це полегшує налаштування вбудованих систем. Щоб створити робочу систему, просто додайте кілька вузлів пристрою в / dev, кілька файлів конфігурації в / etc і ядро ​​Linux.

Ви можете майже зробити будь-яке ім'я coreutil посиланням на бінарний файл зайнятої, і воно буде працювати. Ви також можете бігти, busybox <command>і це спрацює. Приклад: якщо ви перебуваєте в Gentoo і ще не встановили свій vi, ви можете запуститись busybox vi filenameі будете in vi. Його

• Arch Linux - спільнота / зайнятий

• Gentoo Linux - sys-apps / busybox

• Alpine Linux - на основі BusyBox та uClibc, ось огляд

Це старша тема, я усвідомлюю. Однак про це рішення ніколи не згадувалося, і в Google виходить порівняно високо для "Linux з bsd userland".

Є ще одне рішення: реліквія. Я знаю, що він працює на Arch, і він упакований в AUR (наприклад, подивіться на gnu2sysv). Це замінить основний пакет Arch і забезпечить еквіваленти спадкоємців. Про все це ви можете прочитати на вікі арки: https://wiki.archlinux.org/index.php/Base2heirloom

Перевірте утиліти .

Це крос-платформна реалізація основних програм GNU, написана в Rust. Це ліцензія MIT. На момент написання цієї відповіді вона не є 100℅ повною (відсутні деякі важливі, такі як lsі cp), але багато інших зроблено.

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

Зазвичай, коли хтось просить піти від чогось, що широко використовується, добре перевіреного, перевіреного на багатьох платформах, це зовнішнє вираження основної проблеми, відомої як "запах коду" та неконтрольоване накопичення "технічного боргу" або "коду" борг ». Архів GNU накопичив протягом багатьох років досить велику кількість боргу за кодом, і коли кодова база не підтримується належним чином, вона може досягти точки розриву (застарілий код і навіть хворобливий спадковий код).

Зазвичай можна проводити процес реінжинірингу та рефакторингу з інтервалом, щоб тримати це під контролем. Отже, справжнє питання, яке тут задається, полягає в тому, чи була розроблена реконструйована версія coreutils. Звичайно, це включає можливість прямої заміни (як особливий випадок) - так само, як Вейленд розбирається на X ... багато його розробників виходять прямо з табору X.

Моя пропозиція полягає в тому, щоб насправді зайнятись та рефакторировать основні програми. Хтось повинен це зробити. І хто поставить питання про заміну coreutils - ваша ідея, ваш проект.

З цією метою скористайтеся будь-якою автоматикою, яку ви можете знайти: двигуни рефакторингу, як-от cscout, або будь-що, що застосовує більш досконалі методи аналізу / синтезу (наприклад, формальні решітки концепції). Але глибокий аналіз все ще є відносно новим і відкритим напрямком активних досліджень - і переходить у штучний інтелект. (Інженер-програмний робот.)

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

Solaris (станом на svn_140-щось) також був би варіантом.

Якщо ви використовуєте дистрибутив, ви божевільні. Зупиніться зараз. Зверніться до психіатричної допомоги.

Якщо ви використовуєте LFS , запускайте! Веселіться!

Якщо ви створюєте дистрибутив, я аплодую вашому хороброму пану.