LINUX.ORG.RU

uutils 0.2.0 и 0.2.2, вариант GNU Coreutils на языке Rust

 , , , ,

uutils 0.2.0 и 0.2.2, вариант GNU Coreutils на языке Rust

2

6

6 сентября опубликован выпуск 0.2.0 проекта uutils coreutils (Rust Coreutils), развивающего аналог пакета GNU Coreutils, написанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, среди прочего способной работать на платформах Windows, Redox и Fuchsia.

Rust Coreutils применяется в дистрибутивах AerynOS (Serpent OS) и Apertis, а также будет задействован по умолчанию в осеннем выпуске Ubuntu 25.10. В отличие от GNU Coreutils реализация на Rust распространяется под пермиссивной лицензией MIT, вместо копилефт-лицензии GPL. Дополнительно той же командой разработчиков развиваются написанные на Rust аналоги наборов утилит util-linux, diffutils, findutils и procps, а также программ sed и login.

В новой версии Rust Coreutils:

  • Пакет признан полностью готовым для рабочего применения в Ubuntu. Устранены все проблемы, мешавшие переходу Ubuntu по умолчанию на Rust Coreutils.

  • Добавлена поддержка локализации и интернационализации. Введена в строй инфрастурктура для поддержания переводов сообщений на разные языки. Учтены параметры локали при форматировании вывода и начат перевод на разные языки сообщений об ошибках. Для поддержки многоязычности задействована система локализации Fluent, развиваемая Mozilla и используемая в Firefox.

  • Добавлена поддержка Unicode. Символы Unicode, в том числе emoji, теперь могут применяться при обработке содержимого и параметров, например, в качестве разделителей полей: echo "🍔🍟🥤" | cut -d"🍟" -f1.

  • Проведена оптимизация производительности утилит tr, sort и cat. Производительность утилиты tr повышена в 15 раз - ранее данная утилита была медленнее GNU tr в 9.8 раз, а теперь быстрее в 1.58 раза.

  • Улучшена совместимость с эталонным тестовым набором GNU Coreutils, при прохождении которого успешно выполнено 538 тестов (в прошлой версии 522), 52 (65) теста завершилось неудачей, а 27 (31) тест был пропущен.

  • Улучшена совместимость с GNU Coreutils для утилит date, du, fmt, ls и sort.

  • Расширены возможности, устранены проблемы и добавлены недостающие опции для утилит basenc, basename, cat, chmod, chown, cksum, cp, split, date, dd, du, echo, env, expr, factor, fold, hashsum, head, install, ln, logname, ls, mkdir, mkfifo, mktemp, more, mv, nice, nl, od, pr, printf, pwd, realpath, rm, shred, sort, stat, stdbuf, stty, sync, tail, tee, timeout, touch, tr, uname, unexpand, uptime, users и who.

Версия 0.2.2 содержит исправления критических ошибок. Эти исправления обеспечивают безопасное распространение и развёртывание на разных платформах. Разработчики также улучшили производительность base64, сделав её в 1.56 раза быстрее, чем в версии GNU.

>>> Подробности на opennet



Проверено: dataman ()
Последнее исправление: hobbit (всего исправлений: 6)
Ответ на: комментарий от monk

Это пока не захочется, чтобы стдлиба была очень быстрой и очень гибкой.

Конкретно с весны там работы в сторону бесцветного асинка, посмотрим что получится с сетевым стеком. Насчет гибкости — можно пример, в чем гибкости не хватает в нынешнем виде?

sarumeister
()
Ответ на: комментарий от sarumeister

Насчет гибкости — можно пример, в чем гибкости не хватает в нынешнем виде?

Вот нынешний: https://github.com/ziglang/zig/blob/master/lib/std/mem.zig#L238

А вот сишный: https://elixir.bootlin.com/glibc/glibc-2.42.9000/source/string/memcpy.c

https://elixir.bootlin.com/glibc/glibc-2.42.9000/source/sysdeps/generic/memcopy.h

https://elixir.bootlin.com/glibc/glibc-2.42.9000/source/sysdeps/mach/pagecopy.h

monk ★★★★★
()
Ответ на: комментарий от monk

А вот сишный

Уже второй комментарий со ссылками. Эти ссылки мне к чему? Насколько я вижу, они мой поинт только подтверждают.

sarumeister
()
Ответ на: комментарий от sarumeister

В стд копирование побайтовое. В глибс по страницам и словам, причём с дополнительной адаптацией под конкретные процессоры.

monk ★★★★★
()
Ответ на: комментарий от monk

В стд копирование побайтовое. В глибс по страницам и словам, причём с дополнительной адаптацией под конкретные процессоры.

То есть «deprecated» строчкой выше ты не увидел?

Встроенная функция @«memmove» делает все в лучшем виде, причем с дополнительной адаптацией под конкретные процессоры, под WASI и EFI.

sarumeister
()
Последнее исправление: sarumeister (всего исправлений: 1)
Ответ на: комментарий от monk

Здесь уже добавили оптимизацию под пару процессоров, поэтому выглядит не так красиво.

Если бы в неймспейсе не увидел «simd», то и не подумал бы, что это SIMD во все поля. Исходники они вот же. Открываешь std/simd.zig, там и все типы процессоров, и опять красивые интринсики, замечательные даже.

Она вызывает функцию из glibc.

Огромное заблуждение.

Зиг не линкуется с сишным рантаймом. @«memmove» & Co — интринсики из LLVM. Я бы показал на годболте, но там все мои -O ReleaseSmall приводят к одному и тому же «тут нечего делать» ret.

sarumeister
()
Ответ на: комментарий от sarumeister

@«memmove» & Co — интринсики из LLVM.

А они не из glibc? LLVM свои изобрели?

monk ★★★★★
()
Ответ на: комментарий от sarumeister

Если бы в неймспейсе не увидел «simd», то и не подумал бы, что это SIMD во все поля. Исходники они вот же.

Я в том смысле, что из четырёх красивых строчек (их видно в конце) функция уже выросла до шестидесяти. И это только под один процессор.

monk ★★★★★
()
Ответ на: комментарий от monk

Я в том смысле, что из четырёх красивых строчек (их видно в конце) функция уже выросла до шестидесяти. И это только под один процессор.

То есть std/simd.zig с его списком процессоров ты не посмотрел.

А они не из glibc? LLVM свои изобрели?

Я не знаю, что человек должен сделать такого, чтобы его программа на зиге заимела зависимость от libc.

sarumeister
()
Ответ на: комментарий от sarumeister

Я не знаю, что человек должен сделать такого, чтобы его программа на зиге заимела зависимость от libc.

Как насчёт функций, завязанных на nsswitch.conf?

wandrien ★★★
()
Ответ на: комментарий от sarumeister

То есть std/simd.zig с его списком процессоров ты не посмотрел.

В комментарии к коду указано, что For Intel Nehalem (2009) and AMD Bulldozer (2012) or later. Для других архитектур нужен другой код.

То есть std/simd.zig с его списком процессоров ты не посмотрел.

https://github.com/ziglang/zig/blob/master/lib/std/simd.zig#L305 и где он?

monk ★★★★★
()
Ответ на: комментарий от wandrien

Как насчёт функций, завязанных на nsswitch.conf?

Надо явно указать linkSystemLibrary(«c»);

sarumeister
()
Ответ на: комментарий от monk

В комментарии к коду указано, что For Intel Nehalem (2009) and AMD Bulldozer (2012) or later. Для других архитектур нужен другой код.

В комментарии указано, что для этих (и более ранних) невыровненный по SIMD доступ будет работать медленнее. Следующим предложением написано, что авторы этим фактом сами не заморачиваются и нам не советуют.

Перед комментарием есть кусок

if (std.simd.suggestVectorLength(T)) |block_len| { ... }

В suggestVectorLength() список процессоров.

sarumeister
()
Ответ на: комментарий от sarumeister

В suggestVectorLength() список процессоров.

Это зависимость длины вектора от типа процессора.

Следующим предложением написано, что авторы этим фактом сами не заморачиваются и нам не советуют.

Если Rust станет распространён, заморочатся. Пока, понятно, что хотя бы на одном процессоре нормально сделать.

monk ★★★★★
()
Ответ на: комментарий от monk

Если Rust станет распространён, заморочатся. Пока, понятно, что хотя бы на одном процессоре нормально сделать.

В реакциях не хватает «голые спекуляции» и «чистая демагогия».

sarumeister
()
Ответ на: комментарий от sarumeister

Ну в самом деле. Какова сейчас производительность Zig по отношений к C/glibc, например, на Apple M1?

monk ★★★★★
()
Ответ на: комментарий от monk

Если Rust станет распространён

Читать «Если Zig станет распространён»

monk ★★★★★
()
Ответ на: комментарий от sarumeister

Странное измерение. Реализовать алгоритм на Си медленнее раста и хаскеля — это надо очень постараться. Что надо сделать с программой на фортране, чтобы она работала медленнее реализации на сишарпе и лиспе, вообще непонятно…

monk ★★★★★
()
Ответ на: комментарий от monk

Походил по ссылкам, нашел страничку со свежими прогонами. Там у Си-реализации результат на 20% лучше, чем у зига и раста.

https://plummerssoftwarellc.github.io/PrimeView/report?id=7734&hi=False&hf=False&hp=False&fi=&fp=mt&fa=&ff=&fb=&tp=False&sc=ps&sd=True

sarumeister
()
Ответ на: комментарий от sarumeister

Но здесь не про стандартную библиотеку. Ладно, пока этот спор всё равно не актуален.

monk ★★★★★
()
Ответ на: комментарий от sena

Если год расчетов стоит $30M, а ускорив в полтора раза и потратив что-то на разработку тот же расчет будет $26, то 4 миллиона можно будет инвестировать на более параллельный алгоритм.

Но можно и ничего не делать.

VIT
()
Ответ на: комментарий от VIT

Мы здесь про стандартные утилиты говорим вообще-то, а не про частный случай какой-то. Если ты ускоришь решение задачи сортировки в полтора раза на 16 ядрах, но при этом замедлишь однопоточную версию и в десятки раз усложнишь код, то такое точно не надо в стандартной утилите сорт.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Ответ на: комментарий от sena

Ты пытаешься совместить инженерную проблему с управлением. Лучше, когда инженеры - инженерят, а управленцы - управляют и принимают решение, что «лучше» для проекта.

VIT
()

По какой-то причине это не попало в новость:

https://www.phoronix.com/news/Ubuntu-Rust-Coreutils-Perf

A bug report opened last week is cksum being up to 17x slower than GNU for some large files. A test case was provided for the cksum utility being so slow.

There was also a bug report raised for Rust Coreutils’ sort command not finishing the sort process for large one line files.

Готово для прода, отправляйте!

PPP328 ★★★★★
()
Ответ на: комментарий от VIT

Ты пытаешься совместить инженерную проблему с управлением. Лучше, когда инженеры - инженерят, а управленцы - управляют и принимают решение, что «лучше» для проекта.

Не надо грязи!

Речь о том что приведённые данные без загрузки CPU не полны и решить что лучше по ним не выйдет. У уж кто там будет принимать решения - пусть разбираются сами.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 4)
Ответ на: комментарий от LongLiveUbuntu

Там ещё лучше, если открыть ПРы и ишуи:

https://github.com/uutils/coreutils/issues/8644 - date падает в панику при «+%:»

https://github.com/uutils/coreutils/pull/8496 - force в cp не работает, если файл занят

https://github.com/uutils/coreutils/issues/7876 - chroot просто рандомно валится, пытаясь установить путь в /

PPP328 ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Удивительным образом именно этот яп собирает вокруг себя именно таких личностей, которые (за месяц до релиза) ведут такую беседу с багрепортером:

– На файлах где есть длинные строки sort зависает
– А в реальной жизни это случается?
– Ну вот же, гну-сорт отрабатывает за меньше секунды, эта реализация виснет
– Может будете реальные проблемы искать?

Ну или вот:

– В регэкспах точка ищет один байт, а не символ
– Так и должно быть. Мы используем школьную поделку вместо парсера регэкспов, автор сказал что никогда не добавит локале-специфичные вещи

PPP328 ★★★★★
()
Последнее исправление: PPP328 (всего исправлений: 1)
Ответ на: комментарий от PPP328

Справедливости ради, по первой ссылке проблема всё же признаётся, хотя как-то нехотя, сквозь зубы. Но такие люди есть всегда и везде, в любой командной разработке каждый сталкивался с подобными ситуациями: коллега наговнокодил, но менять не хочет, потому что «в 99% случаев работает жи!».

По второй ссылке, проблема в библиотеке, написанной на правоверном C.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

Спасибо за блестящую демонстрацию изложенных тезисов 🤣

wandrien ★★★
()
Ответ на: комментарий от PPP328

Растожуи в комментах на ЛОРе: РЯЯЯЯЯЯЯ, тесты говно, правоверный Раст позволяет писать верный код без тестов!!!

Тем временем в реальной жизни:

An issue found by our fuzzer: if the incorrect format string %: is passed to strtime::format(), the function panics instead of returning an Err.

wandrien ★★★
()
Ответ на: комментарий от PPP328

Звиздец. Я думал то, что описано в «Король Матеуш Первый» - это сказка, а оказывается дети всё-таки приходят иногда к власти. Может всё-таки не будут это включать в дистрибутив? Марк же не идиот.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Тут не дети, а наоборот. На вершине масонской пирамиды сидят 90-летние пни в полнейшем маразме. Сделать с этим ничего нельзя, потому что на замену такие же. Доигрались с медициной этой вашей.

bread
()
Ответ на: комментарий от Chiffchaff

По второй ссылке, проблема в библиотеке, написанной на правоверном C.

Их жидомасоны под угрозой кастрации заставили ее использовать? И потом, в новости написано, что i10n и i18n полностью завершены. Вранье, получается? Раз регэкспы не могут в хрюникод ни в одной утилите

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

Понятия не имею. Несмотря на то, что мне теоретически нравится Rust, я понятия не имею, зачем на нём переписывать coreutils, тем более, опуская настолько важные вещи.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

мне теоретически нравится Rust

Мне «теоретически» много что «нравится»...

А практически я не готов изменить свои многолетним привычкам... ;P ;))

Somebody ★★★
()
Ответ на: комментарий от Chiffchaff

я понятия не имею, зачем на нём переписывать coreutils

Чтобы под соусом «безопасности» поменять лицензию. Чтобы серьезные дяди могли не раскрывать исходники в андроид-приставках, военщине и всём остальном ОЕМ

PPP328 ★★★★★
()
Ответ на: комментарий от unC0Rr

Серьёзные дяди всегда могли взять утилиты из бсд.

Из БДСМ??..

Somebody ★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.