Опубликован выпуск проекта uutils coreutils 0.6.0 (Rust Coreutils), развивающего аналог пакета GNU Coreutils, написанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, среди прочего способной работать на платформах Windows, Redox и Fuchsia...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64730
>Проведена оптимизация производительности утилит base32, base64, basenc и df.Посмотрел код. Хочешь оптимизаций добавляй unsafe. Чудес не бывает.
Не обязательно. Много где SWAR хватает.
Там много вот такого/// `geteuid()` returns the effective user ID of the calling process.
pub fn geteuid() -> uid_t {
unsafe { libc::geteuid() }
}Оно и понятно, зачем: на границе libc многие коноплятора заканчиваются.
Самофикс: без libc можно обойтись раскладкой аргументом по регистрах и вызовом syscall в asm!-блоке. Закат солнца вручную, да, но оно везде так.
> раскладкой аргументом по регистрах и вызовом syscall в asm!-блоке
> в asm!-блокеКоторый точно также будет unsafe и ты поменяешь шило на мыло.
Какой смысл?
> Который точно также будет unsafeОн не точно так же unsafe. В большинстве мест в Rust unsafe нужен в тех местах, где код может стать unsound если программист не проследит. Но ассемблерные вставки всегда sound. Так что unsafe в этом случае имеет иной смысл и просто синоним "я не боюсь".
> Но ассемблерные вставки всегда soundМммм. Нет. Впрочем, место с asm! будут гораздо пристальнее смотреть, чем лапшу с перекладыванием struct из одного vec в другой.
>Но ассемблерные вставки всегда sound. Так что unsafe в этом случае имеет иной смысл и просто синоним "я не боюсь".Почему rust относится к программисту, как к глупому ребенку? Смотри, здесь ассемблер! Напиши unsafe и будь внимателен!
Идея такова, что этих программистов успешно заменит чатгпт, который натренируют на их коде. И чатпгт глупее ребёнка.
> Почему rust относится к программисту, как к глупому ребенку?Раст относится к программисту как с серьезному человеку и старается ему помочь сделать этот мир лучше. Поэтому говорит "вот предыдущее я проверил, там все ок, а тут я не могу, так что давай ты сам".
Не то что компилятор дыряхи - овно на вход, овно на выход.
"И так сойдет" (с)
> Не то что компилятор дыряхи - овно на вход, овно на выход.
> "И так сойдет" (с)Такой и должен быть системный язык и его компилятор. Ты на ассемблере когда-нить писал без всяких этих проверятелей боровов? Не что там так же?
И, кстати, какое овно на вход? Что передал на вход то и будет. Или у вас в расте бывает иначе?
> Такой и должен быть системный язык и его компилятор. Ты на ассемблере
> когда-нить писал без всяких этих проверятелей боровов? Не что там так же?Писал. А теперь сравни средний размер программы на асме и на сишке.
> Что передал на вход то и будет.
Будет где? В скомпиленом бинарнике у юзверя.
> Или у вас в расте бывает иначе?
Бывает. Компилятор показывает ошибку и даже пишет программеру что он написал фигню.
Ошибка исправляется прям на месте и не попадает к юзверю. Шикарно же!
>Компилятор показывает ошибкуТы не поверишь, но есть написать флаги для проверки кода, то компилятор покажет ошибки.
> Ты не поверишь, но есть написать флаги для проверки кода, то компилятор покажет ошибки.Ты не поверишь, но в ведре однажды решили включить -Werror.
И все развалилось в прямом смысле.
По причине того что криворукие у№№№№ использовали хаки-kakи для костыляния своего кода.
Пришлось это здравое начинание отктывать.Но самое главное нужно "написать флаги".
Чего ленивые разработчики делать не будут.
Пф-ф-ф, а на расте ваще ядра нету.
> Пф-ф-ф, а на расте ваще ядра нету.А это что?
github.com/redox-os/kernelТри с половиной землекопа смогли написать рабочее ядро.
Которое даже запускается на реальном железе.
Всего за 10 лет у них уже есть система с юзерспейсом, графикой и даже запускающимся браузеромСравни это c Хурдом который пилят уже 30+ лет, а он всё еще не умеет в юсб))
На osdev.org куча земелкопов, которые пишут ядра в одиночку на Си и тоже все запускается и работает на реальном железе.
> Почему rust относится к программисту, как к глупому ребенку? Смотри, здесь ассемблер! Напиши unsafe и будь внимателен!Unsafe - это не про внимательность, а про разграничение ответственности. Сишнику этого не понять.
Вы специально так криво форматируете?
Я случайно форматирование.
Какой ужасный синтаксис, где return?
Там же, где и begin/end
В Ada?
> Хочешь оптимизаций добавляй unsafe. Чудес не бываетunsafe никак не связан с оптимизациями. Он лишь отключает запрет на доступ к нескольким небезопасным возможностям (типа разыменовантя сырых указателей) во время компиляции.
Что позволяет применять оптимизации которые иначе компилятор не допускает т.к. не может просчитать их безопасность.Я это тоже заметил в расте, если код у тебя safe то постоянно добавляются накладные расходы, т.к. компилятор много чего просчитать не может.
> если код у тебя safe то постоянно добавляются накладные расходыА пример привести сможете?
Напр. на godbolt с асм выхлопом.
Если этого не знаешь - пример не поможет.
Он тоже не знает, поэтому примера не будет.
> Я это тоже заметил в расте, если код у тебя safe то постоянно добавляются накладные расходы, т.к. компилятор много чего просчитать не может.Safe сам по себе не добавляет накладных расходов, которые unsafe сам по себе магически убирает. Если ты САМ пишешь оптимизацию ручками, то да: ее может понадобиться частично или полностью зюобернуть в unsafe. Но само по себе наличие unsafe не дает каких-то моагических возможностей компилятору для автоматических оптимизаций.
>>Проведена оптимизация производительности утилит base32, base64, basenc и df.
> Посмотрел код. Хочешь оптимизаций добавляй unsafeТы куда-то не туда смотрел. 😄 Вот pull request этой оптимизации, и unsafe в коде даже не упоминается:
> Вот pull request этой оптимизации, и unsafe в коде даже не упоминается:Зато он получил три плюсика и одобрение у всех ему поверившим.
И заодно набросил про невозможность оптимизаций без unsafe.
Молодец!
Смотреть сюда где +https://github.com/uutils/coreutils/commit/3c2f35837296bd4b3...
Строка 561
Смотреть сюда https://github.com/uutils/coreutils/pull/9632/commits "remove unsafe" и 2 и 3 коммит
И сюда https://github.com/uutils/coreutils/pull/9632/commits/dbeacf...TL;DR - Изначально в pull request было unsafe - к моменту его принятия unsafe уже не было.
Ой как нехорошо вышло. 😳 Но это уже и не важно: плюсиков персонаж нахватал и Раст в очередной раз повержен!
> TL;DR - Изначально в pull request было unsafe - к моменту
> его принятия unsafe уже не было.Т.е. таки смогли в оптимизации без unsafe, да?))
> Смотреть сюда где +https://github.com/uutils/coreutils/commit/3c2f35837296bd4b3...
А зачем мне смотреть коммит из пулл реквеста 2025 года, где, к тому же, unsafe убрали буквально в следующем коммите?
https://github.com/uutils/coreutils/pull/9632/changes/dbeacf...
Ну и самое главное: тат самый base_common.rs сейчас не содержит ни одного unsafe:
https://github.com/uutils/coreutils/blob/main/src/uu/base32/...
Поэтому повторяю вопрос: куда ты смотрел?
С такой скоростью разработки к поздней весне достигнут полного паритета по проходжению тестового набора.
К тому времени Убунта 26.04 появится
> К тому времени Убунта 26.04 появитсяБудем надеяться что они всё успеют и утилиты будут поставляться с LTS версией.
Может еще sudo-rs затянут.
Только полный паритет по тестам не значит полного паритета по работе, что уже раз сто обсуждалось.
> С такой скоростью разработки к поздней весне достигнут полного паритета по проходжению тестового набора.Тестовый набор — это конечно прекрасно. Вот только, судя по исходной цели проекта, они вроде как намеревались добиться полностью эквивалентного поведения, а это, позвольте, несколько иная задача, куда более трудозатратная.
где C++, там каждый байт — граната.
где Rust, там каждая строка — петля.
Один рванёт — и нету результата.
Другой удавит, подло, втихаря.
Но Маяковский в другом стиле писал, а ещё ёлью. Ви таки не настоящий!
реинкарнация
> В отличие от GNU Coreutils реализация на Rust распространяется под пермиссивной лицензией MIT, вместо копилефт-лицензии GPL.Настоящая причина создания этого проекта.
Ну наполовину.Ещё главное, что оно на политически верном пд-растишке, за которым стоят всякие ультра-коммунистические фонды с деньгами немецким налогоплательщиков. Это как жывотные метят территорию.
> Настоящая причина создания этого проекта.Так отлична же причина!
Линукс начал очищаться от запретительной GPLv3 в пользу свободных лицензий.
Как тут не порадоваться))А заодно со временем избавится от гнутых версий util-linux, diffutils, findutils, procps, acl, sed и login. Плюс заменит древнюю дыряху на нормальный язык.
Шикарно же! Тот линукс, о котором мечтают все адекватные люди.
Вместо бессмысленных споров о свободе хотела бы заметить, что корпорации стали "любить Open Source" как только они осознали, что это фактически бесплатная рабочая сила.
См. также https://opensource.guide/starting-a-project/ и https://opensource.guide/how-to-contribute/ - инструкции, созданные GitHub (в подвале сайта) - т.е. Microsoft.
> как только они осознали, что это фактически бесплатная рабочая силаТак и есть. Они же не немамонты какие-то чтобы игнорировать такую халяву.
А вот почему эта рабочая сила бесплатная нужно задавать вопросы бороде и его прихлебателям.
Не зря же он писал в своем манифесте "ну будут программисты получать меньше, и чо?"> opensource.guide
Первый раз вижу этот сайт.
Вы бы хотя бы какое-то Open Source Initiative привели в пример, а не вообще непонятно что.А с другой стороны - гитхаб бесплатно предоставил ресурсы и возможности для сотен тысяч открытых проектов. Даже к тем, о которых МС даже не знает.
Не сказать им спасибо - быть крайне неблагодарной мра.. ну вы поняли.
> Open Source InitiativeОни больше по юридической части.
opensource.guide - что-то вроде "почему вам стоит заниматься open-source" ака работать за бесплатно - т.е. фокус на обычных людей.
"крайне неблагодарной" В принципе согласна, только в добрые корпорации "Don't be evil" больше не верю :)
А тут доброта корпораций и не причем. Да, Microsoft предоставляет бесплатную платформу для публикации кода, но и сама с нее имеет выгоду, например обучая свою нейросеть Copilot. То есть если человек не неолуддит-всепропальщик, то это win-win, и для него, и для Microsoft.
> в добрые корпорации "Don't be evil" больше не верю :)Сам слоган "Don't be evil" не декларирует что будут добрыми, а только что не будут злыми.
Можно быть neutral. А еще лучше Chaotic Neutral :)Вы сами что-то придумали про "добрые корпорации", а потом расстраиваетесь когда это оказывается не так.
Microslop обучали ChatGPT OpeyAI на открытых проектах c GitHub 🫢
Linux foundation также хочет продать программистов выкатив open source ai
И вейланд, вейланд!
Не трожь Протокол. Протокол - прогресс и нужная вещь. А это совсем другое.
>Настоящая причина создания этого проекта.Да, так и есть. Простые вещи порой понять очень сложно.
> Достигнут уровень совместимости ... 96.28% (было 87.75%)ага, про date тоже писали, что все пучком, а оказалось не фига, половину опций тупо заглушками реализовали...
> ага, про date тоже писали, что все пучкомТак с date и было "было пучком" на момент написания что "всё пучком".
А почему убунтоводы взяли версию месчной давности - вопрос к убунтоидам.Ну и нужно понимать что это за цифры. Это успешность прохождения тестового набора GNU Coreutils. Если что-то тестом не покрыто, то отличие в имплементации будет даже при 100% прохождении тестов.
> Если что-то тестом не покрыто, то отличие в имплементации будет даже при 100% прохождении тестов.И буквально везде надо акцентировать внимание, что это не тесты на совместимость. Это тесты нужные разработчикам, которые такими тестами проверяют то, в правильной работе чего на разных платформах они не уверены.
То в чём уверены тестами не обкладывают.
После перехода с GNU Coreutils на Rust Coreutils правильно будет называть систему Rust/Linux?
uutils/Linux
Systemd/Linux уже забронировал эту возможность
Как Rust затащит так сразу
Это нужно еще GNU libc убрать
Ну это вообще идеально было бы. Musl не дотягивает пока.
>удалён код, в котором использовалось ключевое слово "unsafe".А зачем тогда было добавлять в _НОВЫЙ_ код, который пишется _С НУЛЯ_ этот unsafe. Если надо было сделать быстрее, то смысл проекта утрачивается. Если изначально люди делали которые без unsafe не осилили...а зачем тогда вообще брались ?
> А зачем тогда было добавлять в _НОВЫЙ_ код, который пишется _С НУЛЯ_ этот unsafe.Потому что не все можно сделать без unsafe. Это понимают все, кто пишет на раст.
Если в лоб переписывали кода с бсд утилити, то там без unsafe скорее всего никак, потому что на дыряхе. А чтобы от него избавиться, нужно напр. менять структуры данных и/или взаимодействие объектов.> Если изначально люди делали которые без unsafe не осилили...а зачем тогда вообще брались
Могли придти другие люди, которые смогли.
Могли эти обучиться и смочь самостоятельно.
Важен же только результат - в коде нет unsafe.
> А чтобы от него избавиться, нужно напр. менять структуры данных и/или взаимодействие объектов.В некоторых случаях нужно будет менять сам Rust, так как без unsafe он не может в принципе реализовывать некоторые алгоритмы и структуры данных.
Таких не существует. Ну вот совсем.https://rust-unofficial.github.io/too-many-lists/ — на внеклассное чтение вьюношам бледным со взором горящим.
> А чтобы от него избавиться, нужно напр. менять структуры данных и/или взаимодействие объектов.Ну дак меняй. Внешний интерфейс только сохрани таким же, а как оно там внутри у тебя сделано и какие у тебя там структуры - всем пофиг.
Что такое дыряха?
> Что такое дыряха?Любой ЯП созданный с целью производить плохой код CVE/RCE и тд.
В данном контексте недоязык под названием СИ.
> Наиболее значительное повышение совместимости отмечено для утилит sort, ls, date, cksum и tail.И это всего лишь базовые тривиальные утилиты.
Осель же наконец теминал! Кода выучишь sed или awk, bash-скрипт - то познаешь Дзен. И эти базовые утилиты превратятся в незаменимых помощников.
>выучишь sed или awk, bash-скрипт - то познаешь ДзенКто то где то не умеет, sed или awk (думаю это 0,01% на планете), и не познал Дзен.
> И это всего лишь базовые тривиальные утилиты.Ох уж эти опеннетные непризнанные гении от п(р)ограммирования. ls на 5(!) с гаком тыщ строк им тривиален 🙄
https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/sr...
tail на 2500 тоже ...
как в прочем и date c вооот-такенным маном и поддеркой RFC/ISO/локалей/часовых поясов (и их сокращений) и т.д и т.п.Как жаль, что гении не пишут код ☹
Интересно, а что с производительностью, по сравнению с GNU Coreutils?
> Интересно, а что с производительностью, по сравнению с GNU Coreutils?Что-то лучше, что-то хуже.
Напр. base64 медленнее на некоторых больших файлах.
А tr была в 9.8x slower, а сейчас в 1.58x faster.
sort: 3.72x faster (regular), 1.46x faster (numeric)
factor - медленнееЖалко нет актуальной таблички по утилитам, но это дофига работы чтобы поддерживать ее в актуальном состоянии.
На каких данных? Как бы не оказалось, что сишный код тоже можно ускорить в 100 раз с минимумом затрат. Просто, какой смысл? Все эти растовские "у нас быстрее" такой идиотизм всегда. Я проверял, плюсы могут гораздо эффективнее работать с файлами -- скажем, с чтением разница не на уровне погрешности. Нужно всего лишь извратиться со стандартной библиотекой немного и с шланговой libcxx хуже работает, чем с гнутой. Зависимость от тулчейна. Только в итоге всё равно видно в основном на быстрых на ssd и гигантских файлах (читающихся целиком в память).
> Как бы не оказалось, что сишный код тоже можно ускорить в 100 раз с минимумом затрат."Я тоже так могу, просто не хочу" (с)
> Нужно всего лишь извратиться со стандартной библиотекой немного
Как же хорошо что нормальные разабы не извращаются :)
> "Я тоже так могу, просто не хочу" (с)Хоть бы читал, что комментируешь. Как и твой подплюсовала. Глаза протрите от жЫра. **Очевидно, там речь об "ускорении" путем подмены данных на более "удобные".**
Наверное, (не/аб/экс/квази)нормальный разраб, свой код на Rust-е так же внимательно вайб-кодишь, полагаясь на волшебную силу Борова и ИИота. А потом появляются такие позорные ошибки, как в прошлой новости об этом замечательном Н3НУЖНО, на ровном месте, в простейших утилитах, на самом бе$опас(TM)ном, рекомендованном Гуглом, M$, АНБ и прочими организаторами массовой слежки.
> сишный код тоже можно ускорить в 100 раз с минимумом затрат. Просто, какой смысл?Действительно.
Оно ж всё равно останется дырявым.
Будешь так же ловить CVEшки и выдавать какирам рут, но быстро-быстро))> Нужно всего лишь извратиться
Как обычно)
Ну так лучше дырявое, но не падающее в сегфолты и паники по кд. Я оценил рипгреп -- подобные косяки у всех растописак, как я посмотрю. Может, когда-нибудь станет юзабельно, не в ближайшие 10 лет.
> Ну так лучше дырявое, но не падающее в сегфолты и паники по кд.Лол, т.е тебе норм что твой комп будет как общественный туалет где-то на трассе М5?
Твое право.> Я оценил рипгреп -- подобные косяки у всех
есть.
Вопрос в последствиях.
> Может, когда-нибудь станет юзабельно, не в ближайшие 10 лет.Вангования от ыкспердов это всегда весело (нет).
Вон уже Linux From Scratch выкидывает дидовые копролиты.
Так что может уже лет через пять оплотом гнутых утилит будет всякая маргинальщина, как сейчас с системд.
>твой комп будетскажем, как часто zgrep исполняет поступившие неизвестно от кого данные
>есть.
>Вопрос в последствиях.вот именно, потеря данных из-за внезапно сфейлившего простынёй grep там, где он не должен фейлить простынёй и вернуть только код возврата, куда неприятнее клоунады с cve, и отдельный вопрос, почему расту внезапно не нравится корректный юникод
>Linux From Scratch
эти вообще циркачи всегда
> комп будет как общественный туалетНет, у меня нету карги и раста.
> дофига работы чтобы поддерживать ее в актуальном состоянииПара промптов и пара скриптов на баше в помощь. Проблема не в количестве работы, а в том что это не нужно. Производительность юниксовых утилит не является важным фактором.
> Пара промптов и пара скриптов на баше в помощь.Это не пара промптов.
Нужно сделать для каждой утилиты набор данных, на которых будет измеряться производительность с разными опциями.
Это если делать нормально.Но согласен что оно не сильно и нужно.
> Жалко нет актуальной таблички по утилитам, но это дофига работы чтобы поддерживать ее в актуальном состоянии.Люк, для этого и существуют пайплайны CI/CD.
Интересно, а что со временем при компиляции из исходных кодов, по сравнению с GNU Coreutils?Интересно, а что с размером бинарников, по сравнению с GNU Coreutils?
Не забывай про сотни гигабайт временных файлов. Ресурс ссд не бесконечный, такие "разработчики" сознательно уничтожают железо конкурентов.
> Не забывай про сотни гигабайт временных файлов. Ресурс ссд не бесконечныйОткрой для себя tmpfs.
> такие "разработчики" сознательно уничтожают железо конкурентов.
Каких конкурентов, что ты бредишь?
> а что со временем при компиляции из исходных кодов, по сравнению с GNU Coreutils?Разумеется дольше, потому что много проверок делаются в компайлтайме.
Но это интересно только гентопрдликам и прочим нетакусям.> Интересно, а что с размером бинарников, по сравнению с GNU Coreutils?
Разумеется больше из-за статической линковки.
Но это маленькая плата за безопасность. А все желающие (пока) могут вернуть старые утилиты.
> Разумеется больше из-за статической линковки.Неа. Скорее где-то больше из-за кривых рук^W сборок:
pkg rquery %sh-%n coreutils rust-coreutils
18.5MiB-coreutils
11.3MiB-rust-coreutilsЗависимости:
pkg_deps_all coreutils | xargs -n1 pkg rquery "%sh-%n"
12.6KiB-indexinfo
2.00MiB-gettext-runtimepkg_deps_all rust-coreutils | xargs -n1 pkg rquery "%sh-%n"
1.02MiB-onigurum
> Интересно, а что с размером бинарников, по сравнению с GNU Coreutils?pkg rquery %sh-%n coreutils rust-coreutils
18.5MiB-coreutils
11.3MiB-rust-coreutils
Так там 1 блоб против раздельных файлов?
> Так там 1 блоб против раздельных файлов?Э-э ... и чо? Тот же busybox/toybox (или бздшный /rescue ) -- тайно переписали на расте или "это другое!"?
Статическая линковка в 1 блоб устраняет довольно много паразитных данных бинарей динамической линковки, только в конечном счёте динамическая линковка выгоднее всегда. Если же статически линковать в раздельные файлы, то пакет получится совсем уж раздутый одними и теми же данными. Когда вызываешь этот блоб тысячу раз в секунду, становится заметно.
> Если же статически линковать в раздельные файлы, то пакет получится совсем уж раздутый
> одними и теми же данными.Там один блоб и симлинки на него. В случае бсдшного /rescue - один блоб с хардлинками. И чей-то мне не очень верится, что будет какая-то ощутимая разница даже при тыще вызовов один раз замапленого в память блоба.
Так без KSM только динамические библиотеки шарят память. При статической линковке ничего не шарится. Загрузка в память имеет значение, если вытеснено из кэша, а так предсказать сложно без профилирования.
Дак на расте ещё не вся функциональность сделана.
Подозреваю, зависимости очень криво тобой посчитаны. Зависимости uutils-coreutils так и вовсе зачем-то пытаются линковаться с гццшной либстд.Вот, к примеру, gnu coreutils (собрано раздельными файлами, не учитывает openssl, gnupg, и всё остальное)
* sys-apps/coreutils-9.9-r12
Total files : 250
Total size : 7.07 MiB
> Подозреваю, зависимости очень криво тобой посчитаны. Зависимости uutils-coreutils так
> и вовсе зачем-то пытаются линковаться с гццшной либстд.Подозревай. На реальность это никак не влияет.
% pkg rquery %dn rust-coreutils
oniguruma
% pkg_deps_all rust-coreutils | xargs -n1 pkg rquery "%sh-%n"
1.02MiB-onigurumapkg_deps_all coreutils | xargs -n1 pkg rquery "%sh-%n"
12.6KiB-indexinfo
2.00MiB-gettext-runtimeПрикол тут в вот этом, маленьком нюансе:
% pkg rquery "reponamme %R-%sh-%n" coreutils rust-coreutils
reponamme FreeBSD-18.5MiB-coreutils
reponamme FreeBSD-11.3MiB-rust-coreutils
Осталось избавится от glibc, gcc и bash.
> glibcc-ward
> gcc
clang
> bash
fish
С опытом к тебе придёт понимание, что это не конкуренты. В целом, польза от альтернатив имеется, только в итоге некоторые опенсорсные проекты корпорации завязывают на эти кривые альтернативы, и вот это уже не айс.
Скажем так. На GNU et al. свет клином не сошелся, а многим пуританские плащи пошивочной фабрики им. пятилетки FSF жмут в плечах.> конкуренты
Иногда даже не нужно ничего спрашивать, и воспитанники культур с zero-sum thinking сами о себе расскажут.
> Обращения к стандартной библиотеке libc заменены на эквивалентные защищённые вызовы, предоставляемые пакетом nix.Чем безопаснее ещё одна прокладка? libc та же, вызовы те же, всё тот же Rust...
Чтобы в исходниках проекта было красиво, без unsafe? Как-то нелепо, учитывая nix и статическую линковку.
For many system APIs, Nix provides a safe alternative to the unsafe APIs exposed by the libc crate. This is done by wrapping the libc functionality with types/abstractions that enforce legal/safe usage.```
// libc api (unsafe, requires handling return code/errno)
pub unsafe extern fn gethostname(name: *mut c_char, len: size_t) -> c_int;// nix api (returns a nix::Result<OsString>)
pub fn gethostname() -> Result<OsString>;
```То есть: libc дает лезвие, острое, заточеное со всех сторон и без ручки. Nix обматывает лезвие армированой изолентой. Не то, чтобы очень удобно, но хоть порезаться шансов меньше.
Склалывается впечатление, что тут просто добавили прокладку, чтобы со взимодействием с libc парился кто-то другой.
В том числе. Пусть ꙮ глаз смотрят в несколько мест. В каждом проекте свои обертки над unsafe API - так себе затея.
То есть, та же история, что и с clap, serde, rand и рядом других.
> Чем безопаснее ещё одна прокладка? libc та же, вызовы те же, всё тот же Rust...Тем что она агрегирует обработку ошибок в одном месте и позволяет не писать велосипеды каждый раз когда нужно вызвать функцию.
Напр. gethostname (github.com/nix-rust/nix/blob/master/src/unistd.rs#L1332)
Создали буфер, сделали unsafe запрос, убедились что результат null-terminated, вернули или его, или ошибку.
И так бы это все пришлось писать в каждом вызове gethostname.Это практически со всеми функциями - возврат нормального Result вместо int, который тупо можно проигрорить.
> среди прочего способной работать на платформах Windows, Redox и FuchsiaОчень нужно (нет).
Раст уже не модно, уже есть более безопасный Lean, пора на нём все переписывать
> Раст уже не модно, уже есть более безопасный Lean, пора на нём все переписыватьЭ... ты это серьезно?
Тут у неосиляторов опилки в голове подгорают от "нипанятных значков" в расте, а ты предлагаешь lean на котором можно писать так
example (x : Nat) : 0 < match x with
| 0 => 1
| n+1 => x + n := by
grindвот так
example (x y : Int) :
27 ≤ 11*x + 13*y → 11*x + 13*y ≤ 45
→ -10 ≤ 7*x - 9*y → 7*x - 9*y > 4 := by
grindИ даже так:
theorem exists_prime_factor :
∀ n, 1 < n → ∃ k, IsPrime k ∧ k ∣ n := by
intro n h1Дыpяшeчнеков просто на куски порвет когда они попытаются это хотя бы осознать.
А если без шуток - то интереная штука.
Человеческая лицензия, современный С++, интеграция с Visual Studio Code.
Прямо-таки уже представляется крупный проект на этом, который пилили неск лет и который заср*н всеми этими способами вперемешку от разных разработчиков и ещё десятком пока неизвестных
Тип, что будет потом заниматься поддержкой этого проекта, с первой же выплаты сможет купить себе персональную ракету и космическую станцию, т.к больше никто и за меньшее за это не возьмётся )
> →Боже мой! Хрюникод хотят добавить и в сорцы программ!
> Раст уже не модно, уже есть более безопасный Lean, пора на нём все переписыватьНу ты б ещё им лисп с окамлом предложил. )
Вот, правильный никс. Мы не выбрасываем старый добрый софт, мы его замещаем, ориентируясь на сохранение совместимости.Вяленому стоило бы поучиться.
Это пока ориентируются, чтобы у дидов скрипты от апдейта убунты не посыпались. Как заменят GNUтый утиль на 100% во всех мейнстримных дистрибутивах, начнут чистить конюшни. Цель у всего этого простая: со временем полностью заменить GNU/GPL рак на свободные корпоугодные лицензии. Разработка софта дешевеет, няньчиться с инфантильным "коммьюнити" становится всё менее выгодно. Корпам в проде от мейнстримных дистрибутивов нужны только kernel, systemd, libc, coreutils, bash, и кое-какая мелочь. Всё остальное там не только не нужно, но даже иногда немножечко мешает.
> няньчиться с инфантильным "коммьюнити"Инфантильное оно только на Опеннете. Ноёт про CUMUnity, глядя на отражение в зеркале, воет про рак, от недостатка ума и образованности, и облизывает корпорации, в отсутвие собственного достоинства.
Embrace extend extinguish. M$ всегда так делают.
Сам факт того как долго пилятся аналоги гнутых утилит(ведь это не файломенеджеры или сапры) красноречиво указывает на переусложнённость и раздутость кода этих самых утилит. GNUды просто взяли и разрушили лёгкий и понятный фундамент системы.
> Сам факт того как долго пилятся аналоги гнутых утилит(ведь это не файломенеджеры
> или сапры) красноречиво указывает на переусложнённость и раздутость кода этих самых
> утилит. GNUды просто взяли и разрушили лёгкий и понятный фундамент системы.Производительность требует жертв. Как и универсальность. Никто не осилил пока даже coreutils переписать. Хотя, казалось бы сотня простеньких программок, такие пишет каждый программист, начиная изучать программирование. Уже лет 50 к ряду.
Опять наделали тестов для галочки, где вне зависимости от результата тест проходится. Там настоящая совместимость +- 50%.