Комментарии 31
Объясните, что-за комплекс не полноценности у раст разработчиков, что они во всех своих продуктах так часто любят делать приписку о том что оно написано на расте? Мне, как конечному пользователю, разве важен язык на котором была написана замена привычной утилиты? По ощущениям, отвечая на второй вопрос, нет — не важен. Важно чтобы оно работало нормально, не хуже оригинальной версии, с которой я буду переходить.
Мне кажется, в вашем сообщении и кроется ответ. Если не делать пометки, пользователи просто не заметят разницы и не оценят работу разработчиков.
Не знаю как у остальных, но у меня идет обратное движение. Не "о круто! молодцы", а " о! очередной софт на расте... как же всё равно"
Просто вы не ЦА. Это же не вы принимаете решение, на C или на Rust втаскивать sudo в Ubuntu.
Ничего не понял. Причем тут принятие решение и ЦА? Если так подумать, то я как раз таки ЦА, потому что я пользуюсь убунтой, но мне крайне всё равно на каком языке будет написана sudo. Вопрос был именно про маркетинг уровня отечественных брендов типа Ru-some-think. Я за то что бы отечественных продуктов становилось больше, но с нэймингом какая-то беда
Важно чтобы оно работало нормально, не хуже оригинальной версии, с которой я буду переходить.
То, что оно будет работать не хуже это само собой подразумевается, ведь это замена системных утилит. А то, что будет работать лучше (вероятно) - это заключено во фразе "переписано на Rust". По крайней мере стоит ожидать отсутствия ошибок связанных с безопасностью памяти, которые есть в текущем наборе утилит.
Почему тогда не заменить оригинал в gnu utils? Зачем плодить сущности?
оно будет работать не хуже это само собой подразумевается
Почему это? Как минимум, из-за отсутствия стабильного ABI, не говоря уже о стандарте, возможности динамического связывания у Rust весьма ограничены. А это приводит к повышенному потреблению памяти, что уже хуже.
стоит ожидать отсутствия ошибок связанных с безопасностью памяти, которые есть в текущем наборе утилит
Ошибки при работе с памятью тут всё равно возможны, например, в интерфейсе с PAM. Переписать же PAM на Rust пока не представляется возможным опять из-за отсутствия стандартного ABI.
Ну и кроме ошибок при работе с памятью возможны еще логические ошибки, неизбежные при новой реализации алгоритмов уже с ограничениями borrow checking. За последнее время половина CVE su и sudo не была связана с ошибками при работе с памятью. Например, раз и два.
Почему это? Как минимум, из-за отсутствия стабильного ABI, не говоря уже о стандарте
Можно найти причины по которым что-то может пойти не так, но я доверюсь чувакам из Canonical. Я уверен, что они не станут включать инструмент который работает на половину или даже на 99%, переход должен быть бесшовным.
Ошибки при работе с памятью тут всё равно возможны, например, в интерфейсе с PAM.
Ошибки при взаимодействии с третьей стороной по вине третьей стороны не стоит приписывать к софтине, которая взаимодействует с этой стороной.
За последнее время половина CVE su и sudo не была связана с ошибками при работе с памятью
Тут я бы перефразировал: "за последнее время половина ЗАРЕПОЧЕННЫХ CVE не была связана с ошибками при работе с памятью". Не зарепортили сегодня, зарепортят завтра. А с Растом исключается пласт весьма популярных (и часто тривиальных) косяков при работе с памятью.
я доверюсь
Я уверен
Не думал, что Вы тут обсуждаете веру, а не ведете техническую дискуссию
Ошибки при взаимодействии с третьей стороной по вине третьей стороны не стоит приписывать к софтине, которая взаимодействует с этой стороной.
Кто вызывает библиотечные функции с некорректными параметрами - тот и не прав. Хотя бы потому, что эти библиотечные функции физически не имеют возможность проверить все параметры на корректность.
А с Растом исключается пласт весьма популярных (и часто тривиальных) косяков при работе с памятью.
С этим никто не спорит. Но с Rust не исключаются алгоритмические ошибки, которые, как видим, каждая вторая из обнаруженных.
Подводя итог, с главным Вы молча согласились. Из-за отсутствия стандартного ABI, решения на Rust имеют существенный недостаток. И пока этот стабильный ABI не появится, пихать Rust везде и всюду - не лучшая идея.
Конкретно этот язык означает понижение вероятности взлома через эту утилиту. И это особенно это важно для sudo — это самая главная скрепа безопасности в Linux.
Мне кажется это из-за того, что на раст просто переписывают уже существующие утилиты и для избежания возможных коллизий - добавляют суффиксы. Банально чтобы пользователи - не перепутали.
любят делать приписку о том что оно написано на расте?
В данном случае очевидно почему – потому что это не оригинальная утилита, а другая программа от других авторов, просто делающая то же самое.
Я где то читал что у растовиков это в гайде написано от владельцев языка - если проект на расте то должен -rs по канону содержать в той или иной форме. Не помню как документ называется, как PEP 8 в python, но для Rust
Всё с точностью до наоборот.
> Crate names should not use -rs or -rust as a suffix or prefix.
https://rust-lang.github.io/api-guidelines/naming.html
Потому что "sudo" уже занято.
Развивать две абсолютно разные программы (пусть и делающие одно и то же, но с совершенно разной кодовой базой) под одним названием - прямая дорога к путанице (как, например, вы себе представляете в репозитории дистрибутива две утилиты с одинаковым именем - удобно будет?)
А дальше при выборе названия разработчики просто не захотели выпендриваться и ломать голову.
Вообще-то в абсолютном большинстве проектов на раст такой приписки нет. Такой суффикс ставится потому что проект повторяет уже существующий проект, но на другом языке
Есть теория что спецслужбы не просто так заинтересованы пропихивать везде Rust, нужно больше исследований компилятора и софта на нем на новые уязвимости, а не устраивать срачи и религиозные холивары за языки.
Будет весело если в core-utils утилитах найдут уникальные уязвимости которых в старых реализациях не было. OpenBSD коммьюнити уже окрестило модули и драйвера на расте в ядре линукса bloatware, они и так в свое время забоялись systemd и некоторых GNU утилит, что у них свои core утилиты переписанные и ядро без раста. Это не только ОрепВSD касается, но и какой нибудь Parabola Linux и другие non-systemd distro.
Только анализом исходников и реверсом если закрытые блопы, можно действительно узнать реальный умысел, а не теории заговора об финансовой поддержки проектов на Rust, и поддержка миграции с некоторых языков именно на Rust. По теории, многие думают что Линусу фонд раста занес денег для развития его в открытом ядре.
Тоже переписали на rust. Наконец то появился нормально работающий и не грузящий систему клиент в pacman. раньше скачивал с aur, но клиент сильно глючил и грузил систему. Сейчас полет нормальный работает как надо.
Собрал, посмотрел. libsudo_rs.rlib - 5МБ. su - 519КБ, sudo - 867КБ, visudo - 691КБ. Они издеваются? Или Canonical решил распрощаться с дешевыми одноплатниками? Довесок в несколько мегабайт даже для OpenWRT смерти подобен. Я уже молчу о Linux на RP2040 или подобных МК.
libsudo_rs.rlib -- это статическая библиотека. Она не нужна для работы и не предполагается, что она будет на конечных устройствах.
А так, да. Сам собрал в релизе, пострипал, вот это всё. И получилось вот что (Си->Rust):
su: 55K-> 495K
sudo: 288K->810K
visudo: 261K->647K
rlib не используется и считать его не надо, а в остальном обычный sudo так-то тоже около 400КБ весит, не сильно-то и меньше
Canonical планирует в Ubuntu 25.10 перейти на использование по умолчанию утилиты sudo-rs на языке Rust