Вход на сайт
Просмотр новости

Найдите то, что Вас интересует

И снова о подвигах растоводов: теперь и в CP
Дата публикации: 03-07-2026 16:38:14



Вот какая новость пришла к нам из комрадов из-за рубежа:
https://www.phoronix.com/news/Rust-Coreutils-cp-Ubuntu-Images
Оказывается, на расте не получилось написать даже полностью совместимый cp, чтобы он не ломал сборку дистра. Даже в busybox есть нормальной работающий cp, а в rust-coreutils нет. Пришлось возвращать на место старый-добрый GNU cp.



 ubuntu, история болезни, история успеха



Основное содержимое страницы с новостью.

Вот это вот совсем непонятно. Выглядит как намеренное внесение отличий.

Я когда-то переписал кусок gentoolkit на perl(изначально оно на python). У меня оно работает на порядок(в прямом смысле, не преувеличение) быстрее на некоторых задачах, но у меня совместимость вплоть до пробелов и цветов в выхлопе. Такие вещи делаются же проще простого.

Ответ на: комментарий от shell-script 03.07.26 19:43:45 MSK

Вот это вот совсем непонятно. Выглядит как намеренное внесение отличий.

Нейроразнообразные во всех смыслах =)

Они зафейли совместимую реализацию опции L у cp. 

-L, --dereference
              always follow symbolic links in SOURCE

praseodim ★★★★★
(03.07.26 20:00:30 MSK)

Но как же СВИТАЯ БИЗАПАСНОСТЬ!? Ведь если что-то пере-писать на расте, то оно сразу же мгновенно станет БИЗАПАСНЫМ, а соблюдение edge-cases и обратная совместимость — это для лохов.

thunar ★★★★★
(03.07.26 20:05:22 MSK)
Последнее исправление: thunar 03.07.26 20:14:55 MSK (всего исправлений: 1)

Почитал каменты, стебутся там =))

This wouldn't have happened if it was written in Rust.

praseodim ★★★★★
(03.07.26 20:06:14 MSK)

Ответ на: комментарий от praseodim 03.07.26 20:00:30 MSK

Да, я сходил по ссылке. И вот это мне как раз непонятно. Как они тестировали свою реализацию, если просмотрели такой очевидный фейл? Или никак, или намеренно.

Ответ на: комментарий от shell-script 03.07.26 20:07:19 MSK

Собственно, с такими фейлами, я бы трижды подумал прежде чем брать rust-coreutils. Кто знает, каких ещё они там безопасных фейлов допустили с таким подходом в других утилитах?

Ответ на: комментарий от shell-script 03.07.26 20:07:19 MSK

Вестимо, и пере-писыванием, и написанием тестов занималась АИ.

thunar ★★★★★
(03.07.26 20:09:42 MSK)
Последнее исправление: thunar 03.07.26 20:10:57 MSK (всего исправлений: 1)

Ответ на: комментарий от thunar 03.07.26 20:09:42 MSK

Да как ты можешь сомневаться в идеальном коде святого ИИ, который буквально вчера уже заменил нас всех? ;)

shell-script ★★★★★
(03.07.26 20:24:29 MSK)
Последнее исправление: shell-script 03.07.26 20:24:40 MSK (всего исправлений: 1)

Ничего, проблемы исправят, причём быстро. А счётчик проверки временем уже давно запущен и количество счастливых юзеров (включая меня) растёт.

Good riddance, GNU.

kaldeon ★★
(03.07.26 20:25:56 MSK)

Ответ на: комментарий от kaldeon 03.07.26 20:25:56 MSK

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

Ответ на: комментарий от shell-script 03.07.26 20:33:34 MSK

Проблемы исправляются быстро, большинство тест-кейсов проходит – значит код пишется хорошо. От единичных ошибок, которые исправляются быстро, никто не застрахован. А как по-другому-то оценить качество кода?

kaldeon ★★
(03.07.26 21:01:39 MSK)
Последнее исправление: kaldeon 03.07.26 21:07:57 MSK (всего исправлений: 3)

Ответ на: комментарий от kaldeon 03.07.26 21:01:39 MSK

От единичных ошибок, которые исправляются быстро, никто не застрахован.

Ошибки ошибкам рознь. То, что описано в топике - это ошибка, после которой этим софтом пользоваться нельзя. Это же coreutils.

А как по-другому-то оценить качество кода?

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

shell-script ★★★★★
(03.07.26 21:09:52 MSK)
Последнее исправление: shell-script 03.07.26 21:10:29 MSK (всего исправлений: 1)

Ответ на: комментарий от shell-script 03.07.26 21:09:52 MSK

Т.е. по-твоему качество кода оценивают тогда, когда базовые функции падают в проде?

Не я начал это делать, а вы. Увидели ошибку и сразу обвиняете в этом качество кода. Я лишь указал, что если следовать этой логике чёрного ящика, то быстрое исправление редких ошибок не даёт никаких поводов усомниться в качестве кода.

По-другому такие детские ошибки … разработчики не могут такое отловить на тестах

Суть ошибки состоит в том, что при решении конфликта флагов -a (который раскрывается в -dpPR) и -L утилита пытается удалить флаг -a, но вместе с ним удаляет не только -dP, но и -pR.

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

пользоваться софтом от этих разработчиков опасно

Жить вообще опасно. Куда примечательнее растущие показатели покрытия тестов и количества пользователей.

kaldeon ★★
(03.07.26 21:54:16 MSK)
Последнее исправление: kaldeon 03.07.26 22:07:04 MSK (всего исправлений: 2)

Они переписывают на rust без тестов как-будто

Ответ на: комментарий от anonymous_sama 03.07.26 21:58:57 MSK

Им нейросеть и код пишет, и тесты. Ну а дальше «нейросетевые тесты проверили нейросетевой код и не нашли нейросетевых ошибок».

Smacker ★★★★★
(03.07.26 22:09:51 MSK) автор топика

Т.е. налицо недокументированное поведение и вендор-лок. Грустно все это.

pasquale ★
(04.07.26 00:32:37 MSK)

Подождите, где-то я это уже видел.. они же уже отказались от rust coreutils в ubuntu и откатились на сишные, или мне приснилось?

ant1
(04.07.26 01:10:06 MSK)

А я думал новость будет про то, что вычисление хэшей изображений для детектирования этого самого на Rust переписали.

shdown ★★
(04.07.26 01:12:45 MSK)

Ответ на: комментарий от kaldeon 03.07.26 21:54:16 MSK

флагов -a (который раскрывается в -dpPR)

пытается удалить флаг -a, но вместе с ним удаляет не только -dP, но и -pR

Ты сам-то понял хоть, что написал?

Ответ на: комментарий от kaldeon 03.07.26 21:54:16 MSK

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

Шарик, ты балбес! Мы говорим про coreutils, в котором очень разное поведение в зависимости от того, с чем работаем. Пробовал удалить файл? А каталог?

Любые операции с обычными файлами, каталогами и симлинками должны покрываться разными тестами - для coreutils это такой очевидный подход, что отсутствие его реализации о многом говорит.

Жить вообще опасно. Куда примечательнее растущие показатели покрытия тестов и количества пользователей.

Раз жить опасно, то зачем вообще вся эта мастурба с переписыванием? Сидели бы на опасной сишечке, на ней хоть всё работает уже.

Bfgeshka ★★★★★
(04.07.26 09:14:36 MSK)

Ответ на: комментарий от shell-script 04.07.26 06:48:49 MSK

Конечно

kaldeon ★★
(04.07.26 09:29:19 MSK)

Ответ на: комментарий от shell-script 03.07.26 20:07:19 MSK

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

Ответ на: комментарий от Bfgeshka 04.07.26 09:14:36 MSK

Мы говорим про coreutils, в котором очень разное поведение в зависимости от того, с чем работаем.

chmod 0644 работает одинаково на файлах и каталогах.

cp -a уже, вероятно, был протестирован отдельно. При тестировании комбинации cp -aL не очевидно, что кроме логики обработки симлинков может ещё что-то случиться. А лишние тесты, где проверяется всё подряд без какого-либо обоснования — тоже плохо, ибо инфляция.

В общем, баг не указывает на проблему в подходе. Обычная человеческая ошибка.

зачем вообще вся эта мастурба с переписыванием?

Причины у всех разные. Для меня лично отказ от GNU и FSF на первом месте.

kaldeon ★★
(04.07.26 09:38:58 MSK)
Последнее исправление: kaldeon 04.07.26 09:44:32 MSK (всего исправлений: 2)

Ответ на: комментарий от anonymous_sama 03.07.26 21:58:57 MSK

А это не только они. Недавно была еще новость - кто то там что то переписал и уронил сервис на несколько часов. Десятки тысяч строк кода и все такое. Несколько часов восстанавливали из бэкапа. Ну такое невозможно, если есть тесты. Просто тестов нет вообще, вот и результат.

Ответ на: комментарий от Smacker 03.07.26 22:09:51 MSK

Тесты так не работают. Они проверяют определенную функциональность. Ты же не будешь переписывать тесты иишкой каждый раз под новый код? Тест он или работает или нет.

Ответ на: комментарий от LightDiver 04.07.26 09:37:24 MSK

Ну, не знаю. Помнится, на работе писал я клиента к нашему внутреннему API по управлению серверами. И в процессе выяснил, что одна ручка возвращает список с дубликатами некоторых строк. Полез в исходники апишки, нашёл нужное место, увидел, что там просто нет метода, который эти дубликаты убирает. Ну забыли разрабы и, видимо, никто до меня к этой ручке не обращался. Ну набросал я этот метод на несколько строк, добавил заслал пулл-реквест. Так разработчики заставили меня к самому методу(повторю несколько очевидных строк) отдельно написать юнит-тесты и переписать тесты к ручке, чтобы добавить туда проверку на отсутсвие дубликатов. В итоге, если по строкам и времени считать, на тесты я потратил больше, чем на самом метод. Зато теперь и я, и разрабы точно знаем, что оно работает и будет работать так, как надо.

И да. Я не программист. А тут люди себя позиционируют как крутых спецов, о безопасности что-то рассказывают...

Ответ на: комментарий от kaldeon 04.07.26 09:38:58 MSK

Для меня лично отказ от GNU и FSF на первом месте.

Ага. Пусть оно кривое, не работает и выдаёт ошибки. Главное, чтобы не GNU и не на сях. Ясно-понятно.

А потом мы удивляемся, почему современный софт всё чаще тормозит и глючит.

Ответ на: комментарий от shell-script 04.07.26 09:44:49 MSK

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

Если соблюдать правила, по идее такие ситуации в принципе не должны возникать.

LightDiver ★★★★★
(04.07.26 10:00:39 MSK)
Последнее исправление: LightDiver 04.07.26 10:01:50 MSK (всего исправлений: 2)

Растоманов поймали на CP!!! Кто бы мог подумать.

Ответ на: комментарий от shell-script 03.07.26 20:33:34 MSK

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

seiken ★★★★★
(04.07.26 10:53:27 MSK)

Ответ на: комментарий от seiken 04.07.26 10:53:27 MSK

Да при чем тут время? Просто прогнать автоматически тесты - на это не нужно много времени. Тесты делают один раз на одну функциональность.

Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score 50)

Схожие новости

#Наименование новостиТональностьИнформативностьДата публикации
1Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к сбою при сборке livecd-rootfs0704-07-2026
2Rust Coreutils cp Ended Up Breaking Ubuntu Image Builds With Latest Incompatibility0703-07-2026
3На kernel.org по ошибке удалили со всех зеркал архивы с кодом ядра0502-07-2026
4Разработчик BcacheFS поехал кукухой?-8302-07-2026
5Непонятно удаление0525-06-2026
6raid 10 отвалился диск0501-07-2026
7Куда бежать с github?-2503-07-2026
8Проект rars подготовил свободную реализацию RAR с поддержкой создания архивов5725-06-2026
9Патрик заговорил5704-07-2026
10Проект rars подготовил свободную реализацию RAR с поддержкой создания архивов5825-06-2026

Классификация: Мнения. Схожих патентов: 0. Схожих новостей: 10. Тональность: -3. Информативность: 6. Источник: www.linux.org.ru.