Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к сбою при сборке livecd-rootfs"	+/–
Сообщение от opennews (ok), 04-Июл-26, 11:46
Разработчики Ubuntu вернули вариант утилиты cp из набора GNU Coreutils после выявления несовместимости в реализации cp из состава Rust Coreutils, из-за которой стал завершаться ошибкой скрипт для сборки Live-образов (livecd-rootfs)... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65842
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+3 +/–
Сообщение от soarin (ok), 04-Июл-26, 11:46
Не понял. В первом сервис паке 26.04.1 уже будет? Или это уже только в 26.10 и далее?
Ответить | Правка | Наверх | Cообщить модератору

	90. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от Аноним (90), 05-Июл-26, 00:55
	В 26.04 поставляется именно из GNU, не Rust. В недавнем обновлении решили перейти на Rust. Возникла проблема и снова откатили на GNU. Так понятно? На 26.04 этот баг не влияет
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от нах. (?), 05-Июл-26, 08:41
	> В 26.04 поставляется именно из GNU, не Rust. нетЪ В 26.04 в пакете хрустоутиля _заменены_ (временно) три самых кривых (по совместительству наиболее используемых) бинарника обратно на гнутые. Вероятно, собиратель пакета что-то заподозрил еще тогда. А теперь кто-то свыше велел перестать вставлять палки в колеса прогрессу, мол уже совсем еще готово. А оно... вот... опять... А целиком гнутый пакет вы, неумеющие читать, даже поставить не сможете, хотя он формально и есть. но вы продолжайте писать кляузы местному начальству что вас обижяють и неуважяють, вместо того чтобы хотя бы получать знания.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Аноним (152), 06-Июл-26, 13:42
	эх сколько ещё мы будем обсуждать события которые даже не стоят упоминания в новости только потому что разработчики убунту имеют непонятную многим модель тестирования?
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
	Сообщение от нах. (?), 06-Июл-26, 18:21
	> эх сколько ещё мы будем обсуждать события которые даже не стоят упоминания > в новости только потому что разработчики убунту имеют непонятную многим модель > тестирования? не, ну а как такое оттестировать кроме как на живых людях? вот... потестировали... еще уже почти окончательно но еще немного не готово, оказывается. вот целесообразность всей затеи - только промо нескучного йезычка. Кому-то там ну очень хочется хотя бы так его пропихнуть, за неимением ни одной реальной победы.
	Ответить | Правка | Наверх | Cообщить модератору

2. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–8 +/–
Сообщение от Аноним (2), 04-Июл-26, 11:47
> Опция "-L" предписывает разыменовывать символические ссылки, в то время как составная опция "-a", заменяемая на "-dR --preserve=all", содержит опцию "-d", запрещающую разыменование символических ссылок. > -afL Но виноват все равно Rust, ога.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+30 +/–
	Сообщение от Omnomno (?), 04-Июл-26, 12:01
	Нет, очевидно же, что виноваты С/C++.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+6 +/–
	Сообщение от Аноним (136), 05-Июл-26, 21:02
	А как так получилось, что на расте невозможно написать ту логику, которая была написана на Си?
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–4 +/–
	Сообщение от Олег (??), 06-Июл-26, 08:33
	Неожиданно поведение одной и той же логики на разных яп разное. Прям открыта Америка... Непонимание у вас, что кроме громких слов "одна и та же" оказывается миллиард нюансов
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+3 +/–
	Сообщение от nnam (?), 06-Июл-26, 15:16
	то есть растописцам мешает миллиард нюансов. ок.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от _ (??), 06-Июл-26, 21:06
	> Неожиданно поведение одной и той же логики на разных яп разное. Whooot? In ruZZd 1 && 1 is false? PS: for children - no, Rust understand the logic the same way, but ruZZd writers ... 8-D
	Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

	153. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (152), 06-Июл-26, 13:49
	потому что логика по которой писались гну корутилсы это просто набор исторически сложившихся костылей многие из которых родились в результате случайных событий и никак по сути не задокуметированы. всякий кто захочет повторить обречён ещё не раз столкнуться с тем что реальное поведение сложных сочетаний функций совсем не такое как можно было бы интуитивно ожидать а обложить обширными тестами все эти комбинации и задокументировать задача со звёздочкой практически лишённая смысла. к этому добавляется вторая проблема: изначально у расткорутилсов не стояло идеи строго повторять костыли гнукорутилсов(проект в целом был пруф оф концепт а не продакшен реди инплейс реплэйсмент но вот).
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	160. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–3 +/–
	Сообщение от Аноним (160), 06-Июл-26, 17:09
	Написать не проблема. Проблема в том, что вся эта хитросплетенная логика нигде толком не задокументирована, и местами совсем не очевидна, потому что во многом так получилось случайно. И при переписывании на ЛЮБОМ языке с нуля будут все те же проблемы с совместимостью.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	9. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+3 +/–
	Сообщение от aname (ok), 04-Июл-26, 12:21
	Они начинают догадываться
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	12. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+18 +/–
	Сообщение от tkzv (ok), 04-Июл-26, 12:44
	Нет, виноваты те, кто на нём пишет, не удосужившись изучить поведение исходной утилиты и не сделав тесты.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	23. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
	Сообщение от Прохожий (??), 04-Июл-26, 13:41
	Подозреваю, что если бы такие тесты были бы у исходной утилиты, проблема бы не возникла.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+6 +/–
	Сообщение от EuPhobos (ok), 05-Июл-26, 09:19
	У исходной утилиты как раз всё нормально, она справляется с заведомо конфликтующими ключами (виноват пользователь) и решает в верную сторону по контексту. А подражатели это не учли. В чём проблема? И вердикт верный: "подражающий cp недостаточно подражает". Вроде об этом и написано в новости.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от Tron is Whistling (?), 05-Июл-26, 09:21
	Подозреваю, что если вместо написания исходной утилиты занимались бы написанием тестов, как ныне модно - утилита бы вообще не возникла.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	124. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (124), 05-Июл-26, 11:57
	А какие проблеиы у исходной утилиты?
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	128. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от tkzv (ok), 05-Июл-26, 13:20
	> Подозреваю, что если бы такие тесты были бы у исходной утилиты, проблема > бы не возникла. Да. Но если их нет, это означает больше работы для тех, кто взялся повторить её поведение.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	138. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (138), 05-Июл-26, 22:26
	В очередной раз их тыкнули носом как нагадившего котёнка, что те тесты - не тесты на совместимость, а тесты нужные конкретным разработчикам. В том, в чем они уверены - они тестами не обкладывают. Но разработчики утилит rust по ним считают совместимость. Это обман на этапе постановки задачи.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	71. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
	Сообщение от Аноним (71), 04-Июл-26, 22:36
	> Нет, виноваты те, кто на нём пишет, не удосужившись изучить поведение исходной > утилиты и не сделав тесты. Я тебя расстрою, но бубунтоиды на нем не пишут. И тестировать поведение при указании двух взаимоисключающих опций ... попахивает маразмом. Кстати, скорее всего "ошибка" у бубунтойдов будет с любым другим cp. Ну просто потому что там может и так быть: -a    Archive mode.  Same as -RpP.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	78. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от anonymous (??), 04-Июл-26, 23:20
	Я тебя тоже расстрою: не понять что нужно отключить только одну опцию в составной (как это делается известно десятилетия), вместо написания всех ключей кроме ненужного - попахивает умственной отсталостью. Таки рукожопы из бубунты не знают элементарного, не умеют писать тесты, но думают что знают руст и считают себя поэтому офигенно крутыми.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от Аноним (71), 05-Июл-26, 00:42
	> Я тебя тоже расстрою: не понять что нужно отключить только одну опцию > в составной (как это делается известно десятилетия), Умные слова, уверенный вид (о том, что опции в скриптах лучше указывать явно и пара доп. слов там вообще не проблема, тактично умолчим), совсем как Клод &Co 😀 Не расстроил, но посмешил. Молодец. Но вот я тебя еще раз расстрою: Создай симлинк foo на файл и сделай cp -PL foo и cp -LP foo и удивись. Просто переводчик/автор одной из новостей откуда это спер^Wкоммунижженно (мне лень копать) ляпнул про "удаление конфликтного флага". Угу, аж десять раз. То-то L там на последнем месте в опции. Да-да, никакого "отключения" или проверки конфликтов, просто "кто последний, тот и папка". Вот ТАК было всегда, знатоки вы мои опеннетные 😉
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Смузихеб забывший пароль (?), 05-Июл-26, 06:30
	по поводу последней фразы примерно так и есть кстати на мелкого надо платить алименты но, стОит после этого счастливой обладательнице мелкого оф. выйти замуж за жругого, как вдруг ответственность за уже существующего мелкого переходит на нового "мужа" с перспективой по итогу развода платить на него алименты и освободив предыдущего "жениха" Так что тут действительно кто последний - тот и "папка"
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от Проходил мимо (?), 06-Июл-26, 07:36
	Вообще-то за то, как именно обрабатываются флаги, отвечает исключительно программист. Можно написать так, что будет иметь значение место расположения флага ("кто последний, тот и папка" или "кто первый, тот и папка") а можно так, что не будет. Это никак не зависит от языка, это исключительно реализация алгоритма.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	155. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (152), 06-Июл-26, 13:53
	а в других гнутых утилитах отключают всю, а в других так и вовсе при таком с ошибкой падают явно заставляя пользователя определиться какие флаги и ключи он всётаки хочет.. не догадаться о том в каком случае какое поведение правильное попахивает отсутствием либастрал и приговаривает к ссзб.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	81. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (81), 04-Июл-26, 23:34
	Это вы ещё CSS не видели.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	110. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Аноним (110), 05-Июл-26, 09:18
	> И тестировать поведение при указании двух взаимоисключающих опций ... попахивает маразмом. Вообще это стандартный кейс - поведение ПО в нештатном запуске. Ожидать, правда, _обычно_ нужно минимум доп. сообщение с предупреждением, а лучше - сообщение об ошибке. У дедов свой путь, но тестируемый все равно
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	127. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от tkzv (ok), 05-Июл-26, 13:18
	> тестировать поведение при указании двух взаимоисключающих опций Любой тестировщик обязательно проверяет такие вещи :) Если программа позволяет задать взаимоисключающие условия, необходимо определить поведение в таком случае и документировать его. Авторы обеих cp это не сделали. Видимо, решили, что "лучшая документация — исходники" :) Что хуже, авторы нового cp безосновательно решили, что их способ решения этого противоречия — единственно возможный. Сразу вспоминается Поттеринг.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	37. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Аноним (37), 04-Июл-26, 16:01
	Если в GNU coreutils обнаружат проблему в cp, вызванную выделением буфера некорректного размера, будет ли "виноват всё равно C"?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	99. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–5 +/–
	Сообщение от Смузихеб забывший пароль (?), 05-Июл-26, 06:24
	"Ошибка возникала из-за иного поведения при обработке конфликтующих между собой опций "-L" и "-a". Опция "-L"... " Бл, вот за что обожаю линь и бздю. Гора похожего и совершенно несовместимого ПО даже в плане мать-их-примитивныых-флагов-консольного-вызова Неясно, как это вообще появляется, причём, официально. За подобную "работу" даже новичка на подработку( или студента на бесплатную стажировку ) не взяли бы по итого тестового задания в лице неспособности хотя бы норм распрарсить параметры Но оно есть По расту.. а часто ли в новостях в качестве осн инфы на первый абзац или несколько говорится именно о расте ? Он не виноват но просто не решает проблем. Логические ошибки, которые допускаются сколь-нибудь опытными разработчиками едва ли решаются боровами и типизацией
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	143. Скрыто модератором	+1 +/–
	Сообщение от Аноним (143), 06-Июл-26, 02:53
	Виноваты адепты церкви Раста, которые решил переписать проверенный десятилетиями код на своем модном язычке.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	144. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+4 +/–
	Сообщение от Sm0ke85 (ok), 06-Июл-26, 07:18
	>Но виноват все равно Rust, ога. Конечно ржавый, ибо внушил бездарям, что они теперь безопасно могут писать рабочий код...
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	156. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
	Сообщение от Аноним (152), 06-Июл-26, 13:57
	код рабочий и безопасный. то что гнутый ср вобще позволял своим пользователям мешать несовместимые флаги и недокументированым образом их разрешал это в целом тоже не проблема языка си а проблема низкой культуры разработки в проектах корутилс.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Sm0ke85 (ok), 10-Июл-26, 07:16
	>код рабочий и безопасный. В теме же написано - не работает код... >гнутый ср вобще позволял своим пользователям мешать несовместимые флаги и недокументированым образом их разрешал И это правильно, ибо все не документируешь, а если кто-то что-то начал применять, то это уже "не баг, а фича"... Ох уж это поколение с узким мышлением)))) >это в целом тоже не проблема языка си а проблема низкой культуры разработки в проектах корутилс. У Си вообще считай особых проблем нет, а та самая "культура разработки" - не более чем миф, т.к. важно в итоге: решил/не решил проблему/проблемы, а остальное обусловлено уже внешними факторами (время, желание, лень, амбиции, привычки и т.п.) Зы также прошу не впадать в крайности, т.к. я не призываю хардкодить на каждом шагу, но хардкод вполне имеет место быть в местечковых сиюминутных проектиках, которые не подразумевают долгое существование и какое-либо развитие...
	Ответить | Правка | Наверх | Cообщить модератору

3. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+6 +/–
Сообщение от Аноним (3), 04-Июл-26, 11:48
С разбором аргументов вообще беда, у всех, кто не гетопт из позикса. Но тут, видимо, навайбкодили.
Ответить | Правка | Наверх | Cообщить модератору

	32. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
	Сообщение от Аноним (32), 04-Июл-26, 15:04
	ИИ такую ошибку совершить гораздо сложнее накосячили как всегда люди.
	Ответить | Правка | Наверх | Cообщить модератору

	140. Скрыто модератором	+/–
	Сообщение от Аноним (138), 05-Июл-26, 22:31
	> ИИ такую ошибку совершить гораздо сложнее накосячили как всегда люди. Вот как раз такие она сама наплодит, чуть где отход от генеральной линии - пиши пропало.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Sm0ke85 (ok), 06-Июл-26, 07:19
	>ИИ такую ошибку совершить гораздо сложнее накосячили как всегда люди. Как раз такие ошибки ИИ чаще всего и делает, потому что не умеет в контекст...
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	109. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (109), 05-Июл-26, 09:14
	getopt из позикса сломан в андроиде. В posix getopt нету длинных опций, но их можно симулировать если прописать по-моему '-:' в форматной строке, что одновременно разрешает и терминировать обработку флагов через отдельно стоящее '--', и указывать флаг '-' с слитными опциями, что в итоге выглядит как '--foo=bar'. Ведроиды захерачили свою реализацию так, что оно всегда воспринимает слитное '--*' как "неизвестную опцию", т.е. оно это просто даже заматчить неможет, хотя если открыть posix и почитать как работает getopt и в каком порядке всё вызывается, то вот эта моя находка с '-:' корректна и должна работать.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	117. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Я (??), 05-Июл-26, 09:41
	Есть куча библиотек, намного более функциональных и удобных, чем getopt.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	119. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (3), 05-Июл-26, 09:49
	Функциональных и удобных для кого? Потом пользователь не знает, как аргументы программе оформлять. И каждое обновление всё разваливается (привет 7z).
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Я (??), 05-Июл-26, 11:31
	везде есть --help, базовые возможности по передаче аргументов плюс-минус одинаковые у всех
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (3), 05-Июл-26, 11:41
	Даже короткие аргументы без пробелов не везде, о чём ты? Где-то длинные можно указывать только после коротких. Особенно, если это скрипты на перле -- они легко сделают rm -rf из-за неправильно распознанные аргументов. Только вчера что-то окологнушное использовал, так там --help ошибка (но показывает -h всё равно), а ведь, казалось бы, у гнушного софта такой проблемы быть не должно никак.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Я (??), 05-Июл-26, 16:00
	Ну слушай, аргументы кому как удобно, тот так и передаёт своим программам. Много вариантов. Единого стандарта нет. Почти всегда есть документация, --help, -h, -? и т.п. getopt() старая и нефункциональная по сравнению с более новыми аналогами. Сейчас её использовать банально неэффективно для новых разработок.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от tkzv (ok), 05-Июл-26, 13:22
	> везде есть --help, базовые возможности по передаче аргументов плюс-минус одинаковые у всех Во всех утилитах GNU целенаправленно убрали опцию -h, оставив только --help. Больше до этого никто не додумался.
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	164. Скрыто модератором	+2 +/–
	Сообщение от _ (??), 07-Июл-26, 03:20
	> везде есть --help, базовые возможности по передаче аргументов плюс-минус одинаковые у всех Ага :) Давай линк на свой гитхупчик, покажи что твои скрипты динамически парсят выхлоп --help от утилок и делают выводу чего там нетакусики опять поменяли ... :) А шо, нет токого? А шо? Тыж тут так умничал :))))
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

6. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+3 +/–
Сообщение от Тот_Самый_Анонимус_ (?), 04-Июл-26, 12:06
Команда должна не запускаться с конфликтными флагами. А то, что описано — какой-то костыль.
Ответить | Правка | Наверх | Cообщить модератору

	7. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от Shura (??), 04-Июл-26, 12:13
	Поддерживаю. Лучше упасть на старте, чем потом ловить вот такие непонятки в результатах
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+5 +/–
	Сообщение от Имя (?), 04-Июл-26, 13:40
	Все понятки. Первая опция чтобы меньше писать, вторая отменить один из флагов первой. Если ни разу флагами не пользовался то конечно не понятно. Так можно и на вилку грешить что она в розетку не втыкается пока не повернуть ножки напротив дырок. Непонятливая вилка.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от Аноним (85), 05-Июл-26, 00:37
	> Первая опция чтобы меньше писать, вторая отменить один из флагов первой. Unix-way, говорили они. KISS, говорили они. "Явное лучше неявного", говорили они. Мало того, что юзают однобуквенные сокращения вместо полных названий опций, делая write-only г*портянки. Но этого мазохистам показалось мало! Нужно было пойти еще дальше и сделать: * Конфликтующие опции * Опции, добавляющие другие опции * Опции, молча отменяющие предыдущие опции Казалось бы, это буквально эталонное бинго в плане юниксовой дурки, но все равно вот тут на Опеннете находятся персонажи, которые эту дичь на полном серьезе защищают, да еще и со снобизмом "фууу, да вы просто не осилили!". > Если ни разу флагами не пользовался то конечно не понятно. Пользовались, да только не блоатварным GNUтым крепом. Вот этой всей дичи типа -a даже в POSIX нет.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (86), 05-Июл-26, 00:42
	> Все понятки Да что ты говоришь! Я на деньги готов поспорить, что если тебе (и 99% других башпортянщиков) сунуть вот этот условный "cp -adrL", то не глядя в маны черта с два ты поймёшь, что оно делает.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	113. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (109), 05-Июл-26, 09:19
	У вас у всех тут какая-то олимпиада специальная с тем, кто меньше всего в man почитает, что флаги делают? Это вполне логичное поведение флагов, потому что они так блэт и называются - слева направо их переключаешь по очереди в указанные положения и спишь спокойно. Тот, кто придумал, что флаги можно пихнуть хоть в конец строки после имён файлов, явно курил обои, и а все остальные кто эту традицию возвёл в абсолют и даже понятия не имеют что такое '--' явно попросили у него отсыпать.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (85), 05-Июл-26, 16:48
	>> сунуть вот этот условный "cp -adrL", то не глядя в маны черта с два ты поймёшь, что оно делает. > У вас у всех тут какая-то олимпиада специальная с тем, кто меньше всего в man почитает, что флаги делают? Не, друг, специальная олимпиада - это писать вот эти сопли типа "adrL" и потом самому же лезть в маны КАЖДЫЙ РАЗ, когда нужно понять, что делает твоя собственная башпортянка. Но да, да, я знаю: местные юниксоиды - особенные, и 100500 однобуквенных флажков и их неявное взаимодействие друг с другом запоминают с первого раза и на всю жизнь.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (152), 06-Июл-26, 14:00
	там даже глядя в маны не поймёшь, там надо в код  смотреть и\или тестами выявлять поведение
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	107. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
	Сообщение от Shura (??), 05-Июл-26, 08:42
	> Все понятки. Первая опция чтобы меньше писать, вторая отменить один из флагов > первой. Если ни разу флагами не пользовался то конечно не понятно. > Так можно и на вилку грешить что она в розетку не > втыкается пока не повернуть ножки напротив дырок. Непонятливая вилка. Вот как раз пример с вилкой очень удач ый. Если ты её нормальо не воткнул - она прсто не работает. А тут ситуация, когда ты её воткнул, но получил неожиданный результат
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	8. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+3 +/–
	Сообщение от Hety (??), 04-Июл-26, 12:17
	У cat, например, при конфликте флагов одни имеют приоритет над другими и отключают их, если конфликтуют
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	20. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–3 +/–
	Сообщение от User (??), 04-Июл-26, 13:34
	Дай угадаю: поведение, скажем так, неявное и "исторически сложившееся", да?
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Имя (?), 04-Июл-26, 13:42
	А последовательность букв не важна? адватйе ипсать кка ппоало.
	Ответить | Правка | Наверх | Cообщить модератору

	88. Скрыто модератором	–2 +/–
	Сообщение от Аноним (85), 05-Июл-26, 00:44
	А давай ты не будешь сыпать глупыми аналогиями.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (71), 04-Июл-26, 22:42
	> У cat, например, при конфликте флагов одни имеют приоритет над другими и > отключают их, если конфликтуют Только вот котом испортить кучу файлов "не тем флагом"  конечно можно, но это нужно сильно постараться и вообще залезть на шкаф. В отличие от.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	149. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Тот_Самый_Анонимус_ (?), 06-Июл-26, 10:30
	Как будто это что-то хорошее. Не должно быть приоритетов. Не хватало при написании команд держать в уме приоритеты флагов.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	11. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+3 +/–
	Сообщение от pashev.ru (?), 04-Июл-26, 12:22
	a и L не конфликтуют, конфликтуют d и L, а так как d неявная, то явная L имеет приоритет и должна отменять неявную d.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	17. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–4 +/–
	Сообщение от Вася Пупкин (?), 04-Июл-26, 13:19
	Значит исходно дизайн гoвнa. Вместо таких плясок, из-за которых надо ещё вводить приоритеты, лучше заставить явно их указать и падать при конфликте с понятной ошибкой на ранней стадии.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от pashev.ru (?), 04-Июл-26, 13:24
	Приоритет тут только один и он натуральный: явное лучше неявного.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–5 +/–
	Сообщение от Тот_Самый_Анонимус_ (?), 04-Июл-26, 16:12
	Не должно быть такого. Всё должно быть интуитивно, если это возможно. В данном случае это возможно, просто авторы не продумали нормальную работу.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	89. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Аноним (89), 05-Июл-26, 00:49
	> Не должно быть такого. Всё должно быть интуитивно, если это возможно. Чел, ты правда думаешь, что люди, придумавшие вот эти все "xfcv" и "-adrL", заботились о какой-либо интуитивности?
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Аноним (109), 05-Июл-26, 09:24
	«Наша бедная нийронка не может натренироваться на этих ваших xvfgysLPdss, потому что мы не шмогли запрограммировать ей открытие манулов. Пожалуйста, делайте флаги полноценными английскими предложениями, чтобы оно лучше паттерматчило и мы могли скамить лохов на презентациях того как наш Т9 "умеет" "пользоваться" консолькой.»
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от User (??), 05-Июл-26, 11:23
	Ну, вообще - для семейства ос, гордящейся традициями работы с командной строкой у *nix совершенно изумительно отвратительный cli. С одной стороны оно и понятно - legacy, низкоскоростные терминалы с экономией букАвок, отсутствие инженерной культуры проектирования cli-интерфейсов и т.д. А с другой - пользоваться этим не то, чтобы "невозможно", но скажем так - очень и очень неприятно. Стокгольмский синдром выручает, но не полностью.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	134. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (85), 05-Июл-26, 18:43
	> Ну, вообще - для семейства ос, гордящейся традициями работы с командной строкой А кроме командной строки у этого семейства ОС других интерфейсов и не было.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от _ (??), 07-Июл-26, 03:31
	> Ну, вообще - для семейства ос, гордящейся традициями работы с командной строкой у *nix совершенно изумительно отвратительный cli. Читай описание демократии от У. Черчилля :) Или показывай где луДше. А то ... > С одной стороны оно и понятно - legacy, низкоскоростные терминалы с экономией букАвок[...] А то ... ведь M$ PowerShell на 40 лет позже появился и таких проблем _изначально_ не имел , ну и мсявки наваяли ... но нороТ(С) не заценил, тут же начали alias-ы делать на их OpenObjectSerialPropertiesGetTheФУКoff :-))))) Чойтатак?! А ведь сейчас снова идёт волна популярности CLI ... но _ни_один_ университет не копает на предмет - а как оно со стороны науки быть то должно? А было бы не плохо выяснить и влить в стандарт! ... Да только кому это сейчас надо?! За исследования по заднеприводности вон - гранты дают, а за это то ... ос-с-с-с-спЫдЯ!(С) :-(
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	170. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от User (??), 07-Июл-26, 19:58
	Мы сейчас про (интерактивный) shell или cli конкретных утилит? Если второе - то вот например kubectl прям _кратно_ лучше примерно всего из old-style unix'а, не? Если про неинтерактивный shell - то powershell прям _радикально_ лучше. Какой-нибудь fish лучше, но so-so. ipython или другие попытки сделать из япву "тоже shell" скорее не удались. Интерактивный shell... ну, предметно ориентированные CLI интерфейсы уже достаточно хороши (тот же pgcli, например) - общего назначения... zsh те же ийацы, вид в профиль, powershell да - "нивзлетел" (Хотя тут может и тяжкое legacy в unix-мире - в офффтопике я лично вполне себе терминалкаю) - но тут скорее в AI с его работой с "естественным языком" смотреть надо. Как ни изгаляйся а в перспективе удобней окажется фиксированный набор команд + freestyle speech для сколько-нибудь нестандартных задач
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (152), 06-Июл-26, 14:01
	для них это было интуитивно..
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	165. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от _ (??), 07-Июл-26, 03:21
	> Команда должна не запускаться с конфликтными флагами. А то, что описано — какой-то костыль. Я лично - ЗА! НО! Стандарта на это нет ... ну и ... :(
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

25. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
Сообщение от Аноним (25), 04-Июл-26, 13:48
Прежде, чем программировать вместе с модным ИИ, нужно научиться программировать самостоятельно. Парсер параметров для вас сложный? Тренируйтесь писать парсер параметров, хоть десять лет - мир подождёт. Господь вам строки дал и буква 'L' расправилась с буквой 'a'. А элементарные битовые флаги в энуме и, условно, 'opts &= ~OPT_d' что-то на небезопасном, да.
Ответить | Правка | Наверх | Cообщить модератору

	28. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (25), 04-Июл-26, 13:54
	И rust тут совершенно непричем. Просто до него эти разработчики находились в тени.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (71), 04-Июл-26, 23:03
	> Прежде, чем программировать вместе с модным ИИ, нужно научиться программировать самостоятельно. Ну, некоторые вообще читать уже не умеют, но советы по погроммизму давать и с умным видом комментировать - это всегда пожалуйста! 🙂
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

30. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
Сообщение от Аноним (30), 04-Июл-26, 14:07
они сунулись в кореутилс показать что могут. огребли будь здоров. заодно все поняли что кореутилс не такие уж и простые как всем кажется)) писано теми кто свою значимость умеет застолбить. так ведь ещё и микрсофт свою версию этих утилов делать начала) ох)
Ответить | Правка | Наверх | Cообщить модератору

	48. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
	Сообщение от пох.. (?), 04-Июл-26, 16:41
	Да простые они, простые... Просто ЭТИ нешмагли даже вот в такое простое.
	Ответить | Правка | Наверх | Cообщить модератору

31. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+5 +/–
Сообщение от Ivan_83 (ok), 04-Июл-26, 14:17
> после выявления несовместимости в реализации > из-за выявленных уязвимостей были возвращены утилиты cp У писавшего крыша уехала на новояз: называть баги совместимости уязвимостями.
Ответить | Правка | Наверх | Cообщить модератору

	79. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (79), 04-Июл-26, 23:25
	Там же специально ссылка поставлена https://www.opennet.ru/65278 114 уязвимостей выявили перед релизом Ubuntu 26.04, из-за этого утилиты откатили до GNU, а потом опять вернули Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Ivan_83 (ok), 04-Июл-26, 23:57
	Писать надо нормально потому что, а сейчас написано по п....лохому, так же в РФ пишут все законы - максимально неоднозначно.
	Ответить | Правка | Наверх | Cообщить модератору

33. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+4 +/–
Сообщение от Аноним (33), 04-Июл-26, 15:06
>Проблема возникла из-за вызова в сборочном скрипте утилиты cp с опциями "-afL", которые нормально обрабатывались в GNU Coreutils, но в Rust Coreutils привели к возвращению ошибки "cp: -r not specified; omitting directory <dir-name>" Напомните, какие цели у проекта? Полностью повторить поведение coreutils? Если у них до сих пор проблемы с флагами, то uutils будут готовы примерно никогда.
Ответить | Правка | Наверх | Cообщить модератору

36. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+6 +/–
Сообщение от sunjob (ok), 04-Июл-26, 15:50
что ни новость прораст... то какой-то цирк
Ответить | Правка | Наверх | Cообщить модератору

	45. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от OpenEcho (?), 04-Июл-26, 16:36
	> что ни новость прораст... то какой-то цирк Нормальный юнашевский максимализм... Всегда так было, - прыгнуть на что то трендовое, гордится, инвестировать свое время, потом бум, новый тренд, и жаль за потраченную энергию... и пошла жара ака холивары... Раст концептуально хорош и давно нужен, но вот то, что они сделали с семантикой языка, реально большая ИМХО глупость. Зачем была эта экономия на символах? Я понимаю когда мы экономили на 2-х килобайтах ППЗУ и 4кб РАМ, но зачем сейчас делать язык который больше похож на регулярки - не понятно...
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–2 +/–
	Сообщение от aname (ok), 04-Июл-26, 17:07
	>> что ни новость прораст... то какой-то цирк > Нормальный юнашевский максимализм... Всегда так было, - прыгнуть на что то трендовое, > гордится, инвестировать свое время, потом бум, новый тренд, и жаль за > потраченную энергию... и пошла жара ака холивары... > Раст концептуально хорош и давно нужен, но вот то, что они сделали > с семантикой языка, реально большая ИМХО глупость. Зачем была эта экономия > на символах? Я понимаю когда мы экономили на 2-х килобайтах ППЗУ > и 4кб РАМ, но зачем сейчас делать язык который больше похож > на регулярки - не понятно... А нужен ли раст, когда человечество, к моменту более- менее выползания раста на свет божий, уже создало куда более универсальные инструменты улучшения разработки- это вопрос с ответом, который более склоняется не в пользу раста. В 90-10ые раст был бы неплох, а сейчас оно опаздывает. И гонку проигрывает. Ибо вложения в универсальные инструменты разработки куда больше, чем вложения в конкретный язык.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от OpenEcho (?), 05-Июл-26, 06:15
	> А нужен ли раст, когда человечество, к моменту более- менее выползания раста на свет божий, уже создало куда более универсальные инструменты улучшения разработки- это вопрос с ответом, который более склоняется не в пользу раста. Что именно вы называете более универсальными инструментами? ИИ? Но он тоже изпользует готовые инструменты и раст один из них. > В 90-10ые раст был бы неплох, а сейчас оно опаздывает. И гонку проигрывает Гонку с кем/чем? По большому счету у раста только С/С++ реальный компетитор.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–2 +/–
	Сообщение от Вася Пупкин (?), 05-Июл-26, 05:19
	Приведите примеры неудачного синтаксиса. И что за экономия на двух символах?
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	101. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
	Сообщение от OpenEcho (?), 05-Июл-26, 07:11
	> Приведите примеры неудачного синтаксиса. Послушайте, я не хочу вступать в очередной холивар, а вы прекрасно знаете "хакерскую" лаконичность языка, но в то же время не стесняющегося мусорить код лайвтайм анотациями и мета командами #![feature(... #![allow( Накидать банальные дабл-линк листы, графы, родитель/ребенок ноды превращаются в микс спецсимволов Rc<RefCell<T>> Язык идеально подходит для ИИ чтоб он не напортачил, но вот сопровождать написанное кем-то и уловить смысл среди safe патернов раст, значительно сложней чем в других языках. Про накидать что то быстро чтоб попробовать идею на расте - это отдельная комедия...
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–4 +/–
	Сообщение от Аноним (131), 05-Июл-26, 15:14
	> #![feature(... > #![allow( Тут ты зря, это всё очень няшно сделано, сравни с C'шными __attribute__, чтобы понять. Или вспомни C'шные #pragma. В расте же все эти вещи заложены исходно, а не прикручены изолентой позже, и в едином синтаксисе с макросами, чтобы не плодить синтаксисов. Ну например, ты говоришь о том, чтобы "попробовать что-то быстро", одна из проблем, с которой я в таких случаях сталкиваюсь, у меня появляются вещи в коде, которые я не использую. Функции и типы. И раст начинает заваливать меня варнингами об этом. #[allow(unused)] и #![allow(unused)] позволяют мне справляться с этим так, как я считаю нужным. Просто выключить эти варнинги везде, или только для избранной функции. > Накидать банальные дабл-линк листы, графы, родитель/ребенок ноды превращаются в микс спецсимволов Rc<RefCell<T>> Если твой код тонет в Rc<RefCell<...>>, то ты делаешь что-то не так. Скорее всего, ты пытаешься применить дабл-линк списки там, где что-нибудь ещё будет лучше. Но возможно и альтернативное объяснение: ты пытаешься на растовых примитивах создать то, что требует unsafe. Я не очень представляю себе как double-link списки могут быть использованы в расте. Вот если отвлечься от их реализации, и представить себе внешний API, как их использовать? Как API может гарантировать, что две разные ссылки на элементы внутри списка не ссылаются на один и тот же элемент? Рантайм проверки типа как RefCell делает -- это конечно хорошо, но это рантайм проверки, которые мало того что увеличивают расход памяти и добавляют ветвлений, так ещё и твой код будет падать на этих проверках. Это я к тому, что если в твоей задаче нужны двусвязные списки, то тебе следует остановиться и подумать как ты их будешь использовать, и как твои алгоритмы будут гарантировать, что у тебя не будет двух mut ссылок одновременно. Когда ты поймёшь это, ты сможешь сформулировать инварианты, которые твоя реализация структуры данных будет выдерживать, и опираясь на которые держать растовые гарантии, и ты сможешь написать внешний API к этой реализации, который позволит ей выдерживать инварианты. А когда ты сделал это, то всё что остаётся -- это написать реализацию, и вот там, скорее всего, Rc и RefCell будут лишними. Что тебе там нужно -- это raw-указатели и unsafe. Но... глядя на это: > Про накидать что то быстро чтоб попробовать идею на расте - это отдельная комедия... Это твоя фраза намекает на то, что у тебя опыта недостаточно, чтобы прикасаться к unsafe. На расте очень легко накидать что-от быстро, чтобы попробовать идею. Не так круто как в python'е: в пайтоне больше всяких интересных пакетов на любой случай, которые существенно облегчают жизнь, но и тем не менее в расте есть этих пакетов. Другое дело, что может быть сложно выбрать, не все эти покеты ориентированы на простоту использования, часто они начинают уделять очень много внимания тому, чтобы минимизировать аллокации, и когда это происходит может потребоваться время на то, чтобы понять как крейт жонглирует лайфтаймами, и как лучше писать код в таких условиях: это реально может вынуждать тебя принимать какие-то архитектурные решения, которые будут несовместимы с "быстро попробовать идею". Это значит, что тебе надо выбирая крейты выбирать те, которые оптимизируют в пользу простоты использования, вероятно выполняя лишних аллокаций и копирований объектов для этого. Но опять же, если у тебя нет опыта такого выбора, то да конечно: когда ты первый час "быстро попробовать идею" тратишь на выбор крейта, то это как угодно но не быстро. Второго рода проблемы, которые могут возникнуть, возникают потому, что ты начиная накидывать что-то быстро, незаметно для себя накидываешь архитектурных решений, которые довольно быстро начинают путаться у тебя под ногами. С опытом ты учишься замечать все архитектурные решения, которые ты принимаешь, и ты учишься распознавать ситуации, когда эти архитектурные решения могут укусить позже. Например, когда можно не запариваясь писать код с &'a в типах возвращаемых значений, а когда лучше на всякий случай вставить дополнительных .clone(). (Кстати LLMы, когда ты просишь их нагенерить кода, клонируют налево и направо, они будут делать всё что угодно, лишь бы не связываться с лайфтаймами, что наводит на размышления о том, какого же убого качества был тот раст код на котором LLMы обучались, но с другой стороны, это реально очень простой способ избежать осложнений позже). А сверху добавляется то, что надо просто _знать_ как по-быстрому попробовать ту или иную задачу. Надо ли начать попытку с cargo add anyhow? Или проще будет утопить код в unwrap'ах? Надо ли визуализировать данные в png, при помощи equi, или генерировать .dot и оставлять визуализацию внешним утилитам? Это решения с которых ты начинаешь, и если ты ошибаешься в них, ты можешь потратить часы на то, чтобы одолеть неожиданно накинувшиеся на тебя сложности. Эти сложности надо _предвидедеть_, или "быстро" превратится в целый день убитый в бесконечные рефакторы.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+3 +/–
	Сообщение от Анонимный татарин (?), 05-Июл-26, 20:22
	Какой-то просто невероятно прекрасный манифест профана Чел, __attribute__((...)) - это гнушный синтаксис, стандартный - [[...]] Пассаж про великие архитектуры связных списков, требующих трех созвонов и утверждений аж от архитектора - пушка, да и все остальное под стать. Раст - прекрасная липкая лента для миллионов современнейших и расвитейших программеров, сливок общества
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–6 +/–
	Сообщение от Аноним (139), 05-Июл-26, 22:29
	> Пассаж про великие архитектуры связных списков, требующих трех созвонов и утверждений аж от архитектора - пушка, да и все остальное под стать. Ты, я смотрю ваще не понимаешь о чём речь. Но зачем тогда рот разеваешь?
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Проходил мимо (?), 06-Июл-26, 07:58
	Хрень вы написали про двусвязанные списки. Нечему там падать. И АПИ такого списка совершенно не обязан выпячивать внутреннюю реализацию наружу. Чем хорош двусвязанный список? Возможностью удаления текущего элемента с минимальными накладными расходами и возможностью добавления элементов в начало и конец списка с минимальными накладными расходами и за постоянное время. Есть много задач, где подобное поведение хранилища будет востребовано и они никак не зависят от языка реализации. Например, на основе двухсвязанного списка прекрасно реализуется очередь с возможностью поиска и удаления элементов.
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	161. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–2 +/–
	Сообщение от Аноним (161), 06-Июл-26, 17:44
	> Хрень вы написали про двусвязанные списки. Нечему там падать. И АПИ такого списка совершенно не обязан выпячивать внутреннюю реализацию наружу. Давайте разберём эту хрень? > Чем хорош двусвязанный список? Возможностью удаления текущего элемента с минимальными накладными расходами Что требует изменения двух соседних элементов. То есть где-то под капотом двусвязного списка создаются два мутабельных указателя: один на предыдущий элемент, другой на следующий. Согласно правилам раста два таких указателя не могут существовать одновременно: каждый из нх позволяет создать мутабельную ссылку на удаляемый элемент, а это зашквар. Ок, давайте попробуем спрятать это под API. Пускай реализация работает с raw указателями и unsafe'ом, обходя ограничения раста, но API-то можно создать вменяемый? Во-первых, я отмечу, мы пришли к тому о чём я говорю: двусвязный список надо реализовывать на unsafe'ах, а не на Rc<RefCell<...>>, и тогда действительно не на чем падать, потому что нет нужды дёргать RefCell::get_mut(), и потом тем или иным способом анрапить её. Открываются просторы для совершения незаметных ошибок работы с памятью, но контролируемых падений уже не будет. Во-вторых, я не думаю что двусвязный список в стиле struct Elem<T> { next: *struct Elem, prev: *struct Elem, payload: *T } -- это что-то заслуживающее внимания. Слишком много указателей, слишком раздробленная структура, слишком много кеш-промахов. На современном железе потребуется список в тысячи элементов и доля удачи для того, чтобы он был бы быстрее динамического массива. Список с принудительной связью снижает остроту проблем с кешом, и может быть ему будет достаточно сотен элементов и доли удачи, чтобы оказаться быстрее динамического массива? Но список с принудительной связью ваще интересная вещь в рамках раста, потому что ссылка на элемент борровит и элемент, и всю структуру. Это с одной стороны детали внутренней реализацией, но это детали того уровня которые будут настойчиво просачиваться через все API, под которыми это можно попытаться спрятать. Например, как насчёт алгоритма, который хочет иметь мутабельные ссылки на два разных элемента. Давайте разберём пример? Например, мы можем заворачивать ссылку на элемент в обёртку, которая позволяет работать с ним как с элементом, но не позволяет модифицировать структуру списка. Но это не значит, что API сможет легко возвращать ссылки на два разных элемента, потому что реализации списка надо будет сначала проверить, будут ли эти элементы разными. И, допустим, я выполняю поиск по списку нахожу один интересный мне элемент, потом выполняю второй поиск и нахожу второй элемент, а потом выполняю какого-то рода транзакцию меняя оба одновременно. Как реализация списка может убедиться, что в результате второго поиска был найдет элемент на который нет мутабельных ссылок снаружи списка? Первый поиск вернул такую мутабельную ссылку, была ли она уже дропнута или нет? Упс, мы приходим к тому, что нам нужен либо RefCell, либо наколенная реализация его, для того чтобы отслеживать живые мутабельные ссылки на элементы. А это значит, что поиск может завершиться неудачей не потому, что искомого элемента нет, а потому что кто-то держит мутабельную ссылку на него. Generic API к двусвязным спискам превратится в кошмар, в хрестоматийный пример оверинжиниринга с текущими абстракциями и абстракциями борющимися с утечками, которые тоже текут и поэтому есть ещё абстракции, которые предотвращают утечки из абстракций борющихся с утечками. Ситуация ещё осложняется тем, что "просто двусвязный список" это часто недостаточно хорошо, когда нужен двусвязный список. Как насчёт циклического двусвязного списка? Циклического с заголовком? Хороший generic API должен поддерживать все эти модификации, а это значит что оверинжиниринга там будет столько, что ни один разумный разработчик не подойдёт к этой реализации на пушечный выстрел. Это не значит, что нельзя выпилить ограниченную реализацию двусвязных списков, для специального случая, которая будет предоставлять API которого достаточно для этого случая, но недостаточно, чтобы в общем случае реализовать все преимущества двусвязного списка перед массивом. Но общая реализация двусвязных списков, тем более в расте -- это идиотская затея. > Например, на основе двухсвязанного списка прекрасно реализуется очередь с возможностью поиска и удаления элементов. Такая очередь часто требует дополнительных особенностей. Типа чтобы добавление элементов происходило бы атомарно без блокировок, потому что в неё пишет множество потоков, а разгребает эту очередь один поток. Или наоборот, туда пишет один поток, а множество тредов-воркеров разгребают. Но такого рода вещи выпиливают по месту, с острой заточкой под то, что именно надо. В принципе, если отдаётся предпочтение двусвязному списку перед массивом, значит речь идёт о какой-то задаче критической по скорости, а это значит, что использовать generic реализации -- стрелять себе в ногу. Как ты их потом будешь оптимизировать, выкидывая из них ненужные в твоём случае примитивы синхронизации?
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (151), 06-Июл-26, 13:37
	Было // Устоявшийся метод написания библиотеки pub fn print_value<T: std::fmt::Display>(value: T) {     println!("{}", value); } Стало // Новый «красивый» синтаксис pub fn print_value(value: impl std::fmt::Display) {     println!("{}", value); } Можно было использовать: print_value(42); или print_value::<i32>(42); второй вариант удобен для гарантии. Стало только: print_value(42); второй вариант - ошибка синтаксиса.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

38. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+2 +/–
Сообщение от Аноним (38), 04-Июл-26, 16:01
Вроде уже и понимают, что больно с этим растовелосипедом. Но нет, никак не наиграются..
Ответить | Правка | Наверх | Cообщить модератору

	82. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–2 +/–
	Сообщение от Аноним (81), 04-Июл-26, 23:55
	Как можно иметь такие проблемы с логикой, даже когда есть готовый продукт....
	Ответить | Правка | Наверх | Cообщить модератору

40. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–3 +/–
Сообщение от Аноним (37), 04-Июл-26, 16:06
uutils, конечно, сфейлились, но справедливым было бы пнуть и сборочные скрипты убунты, которые решили поиграться с симлинками. Зачем? Это ж просто костыль для администраторов, когда нормально сделать невозможно. Используйте нормальные файлы и каталоги, и проблем знать не будете.
Ответить | Правка | Наверх | Cообщить модератору

	50. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+4 +/–
	Сообщение от Ivan_83 (ok), 04-Июл-26, 16:51
	Симлинк - очень удобный инструмент, игнорирование его = отрезание нужного и востребованного функционала сильно облегчающего жизнь. Даже на венде есть симлинки (уже лет 25+ как), хотя и нет нормальных инструментов для их использования.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–8 +/–
	Сообщение от Аноним (37), 04-Июл-26, 20:58
	> Симлинк - очень удобный инструмент Да. Для администраторов. Когда нужно что-то подкостылить. Когда на костылях базируется архитектура решения, получаем соответствующий результат.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Ivan_83 (ok), 04-Июл-26, 23:58
	У вас странное отношение к симлинкам, по мне вполне удобный инструмент для определённых задач, в тч  исключения дубликатов и лишнего копирования.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (92), 05-Июл-26, 02:53
	Настолько удобный, что простой подсчёт занимаемого места превращается в акробатический этюд. А уж сколько обходов изоляции было с ними сделано, а сколько ещё будет...
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (109), 05-Июл-26, 09:31
	fstat буквально возвращает тип файла и размер в одной и той же структуре. Для вас проверить ещё одно поле - это акробатический этюд? Или вам нужно АТОМАРНО проверить размер ВСЕХ файлов сразу? Для проверки свободного места можно чекать статистику файловой системы через statvfs, если чё.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (92), 05-Июл-26, 10:52
	Ссылками легко можно устроить циклы в фс. Подсчитать с учётом этого уже не так просто.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (142), 06-Июл-26, 02:13
	Нельзя ли "для исключения дубликатов" просто не созадвать эти дубликаты? Можно пример того, зачем это нужно, кроме костылей совместимости типа /bin/sh -> /usr/bin/bash ?
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	167. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от _ (??), 07-Июл-26, 03:45
	А ты не видишь разницу в поведении если запущено как 'sh' и как 'bash' 8-o Ну я даже не знаю чего тогда из не-матерного сказать про и зачем тогда ты тут умничаешь?... Даже в скриптах есть тема посмотреть как тебя запустили ($0) и соответственно отработать. Как по мне - удобно. Но если механизм не понятен ... для карапузов видимо - магия :)
	Ответить | Правка | Наверх | Cообщить модератору

53. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
Сообщение от openssh_user (ok), 04-Июл-26, 17:48
Обязательно надо было это тащить сразу в прод?
Ответить | Правка | Наверх | Cообщить модератору

93. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
Сообщение от cheburnator9000 (ok), 05-Июл-26, 03:51
В GNOME File-Roller есть такая дичь https://github.com/GNOME/file-roller/blob/master/src/fr-comm... которая там с 2004 года https://github.com/GNOME/file-roller/blame/master/src/fr-com... Если на системе нет libarchive, то file roller переходит на использование консольного tar. И если создать обычный файл (не симлинк), имя которого будет содержать строку -> или link to, то tar при выводе просто выведет его имя как есть. Это минимум чревато кривыми данными в списке файлов в GUI. https://github.com/GNOME/file-roller/blob/master/src/fr-comm... Тут file roller берет кривое имя файла и передаст при распаковке выборочных файлов в tar это же кривое имя. А это уже потенциально приведет к повреждению данных, а возможно и сторонних данных в каталоге пользователя, либо он ничего не распакует и напишет ошибку. Проверять мне лень, на эту фигню я наткнулся в 2022 году, и уже не помню к чему оно приводило. Создать архив, где лежат файлы и каталоги с " -> " и/или " link to " посередине имени в которых также содержатся другие файлы и каталоги, софтварно используя tar, GUI, или написав код упаковки на python, etc. Также проблема есть и в lxqt-archiver https://github.com/lxqt/lxqt-archiver/blob/master/src/core/f...
Ответить | Правка | Наверх | Cообщить модератору

	94. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–2 +/–
	Сообщение от cheburnator9000 (ok), 05-Июл-26, 03:54
	Почему это возможно и почему это до сих пор происходит? Да потому что GNU tar это дермище мамонта до которого никому нет дела, при этом он постоянно используется в многомиллардных корпорациях. Обойти лимиты дизайна консольного выхлопа tar можно было по идее добавив --quoting-style=shell-always в команды tar.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Аноним (3), 05-Июл-26, 08:11
	Это ты ещё ark не видел. Почему ты думаешь, что проблема в tar? Он вон и с файлами с $'\n' и с файлами с $'\r' и с файлами с $'$' и с файлами с $'!' в имени работает. А вот гуёвая шляпа постоянно сыпется. Вот ты топишь за libarchive, а, меж тем, это стрёмная кривая дрянь, продуцирующая грязные кривые файлы. С кучей багов. И этого нельзя сказать о tar.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	105. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
	Сообщение от Аноним (105), 05-Июл-26, 08:38
	У тебя дипсик полетел? Я не топил за libarchive. Речь о проблеме парсинга выхлопа tar cli. А проблема кроется в устаревшем дизайне выхлопа tar в консоль.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
	Сообщение от Аноним (3), 05-Июл-26, 08:48
	Я тебе больше скажу, то, что программы в system() пихают не санитиризированные имена, тоже не проблема tar. Не умеешь работать с шеллом -- не берись. И уж точно файлам из интернета доверять нельзя. К tar претензий тут быть не может. Вот где проблемный неудобный выхлоп, так это у архиваторов типа unrar/7z. Я знаю, потому что накидал скрипт выставлять mtime по времени последнего файла в архиве.
	Ответить | Правка | Наверх | Cообщить модератору

97. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
Сообщение от Аноним (97), 05-Июл-26, 06:08
А сколько сбоев может быть при сборке Gentoo вы себе не представляете. Столько новостей будет тогда. Просто неисчислимый поток новостей как у Васи, Пети сглючила очередная утилита, представляете, да? Вам ведь это должно быть интересно?
Ответить | Правка | Наверх | Cообщить модератору

103. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
Сообщение от Аноним (103), 05-Июл-26, 07:51
Короче, неостляторы решили вернуть глючные GNU coreutils, чтобы не нужно было исправлять глючные скрипты. Отличное решение проблемы.
Ответить | Правка | Наверх | Cообщить модератору

	125. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (124), 05-Июл-26, 12:11
	Это с чего это они глючные? Я понимаю, глючные бы были если зависали, падали, но этого не происходит. А то, как опции себя ведут, тут кто первый встал, того и тапки. Такое решение принято гораздо раньше появления uutils-rs. И если это поломать, то взвоют тысячи других дистрибутивов, где правильным считается именно такое поведение.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Володька Драйвер (?), 07-Июл-26, 11:46
	Ага, просить разыменовывать символические ссылки, и в тоже время запрещающую разыменование символических ссылок в одной комманде это точно не баг - это UB =)
	Ответить | Правка | Наверх | Cообщить модератору

111. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+1 +/–
Сообщение от Tron is Whistling (?), 05-Июл-26, 09:18
Кмк это уже фанатизм, для сколь-либо серьёзного дистра неприемлемо.
Ответить | Правка | Наверх | Cообщить модератору

130. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
Сообщение от Аноним (130), 05-Июл-26, 13:44
Превосходно. Может быть в процессе всего этого будет разработан тестовый набор для coreutils, который позволит проверять совместимость реализаций? Может быть наконец дистры прекратят полагаться на окружение, про которое никто не может сказать, как оно работает, и никто не может проверить, работает ли оно? Может мы наконец получим спецификацию на linux-окружение, соответствие которой будет гарантировать, что существующие скрипты будут работать?
Ответить | Правка | Наверх | Cообщить модератору

137. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
Сообщение от Аноним (137), 05-Июл-26, 22:00
Ошибка явно с неконсистентностью флагов. Если флаги конфликтуют, это 100% ошибка - пусть вместо "коротких" флагов пишут полный набор. Опенсорс такой опенсорс...
Ответить | Правка | Наверх | Cообщить модератору

141. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
Сообщение от Аноним (141), 06-Июл-26, 01:09
Так кто у нас нынче тестовый полигон-то?
Ответить | Правка | Наверх | Cообщить модератору

150. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
Сообщение от ptr (ok), 06-Июл-26, 11:03
Переписать что-то на Rust можно и, возможно, даже нужно, чтобы снизить количество уязвимостей и ошибок, возникающих при некорректной работе с памятью. Но это только вершина айсберга, так как логических некорректностей в свеженаписанном коде, обычно, не меньше, чем некорректностей при работе с памятью. Поэтому, для того, чтобы добиться такого же уровня надёжности, как у утилит, активно использующихся, поддерживающихся и исправляемых не один десяток лет, нужны в любом случае годы! И на хрена по факту сырую бету, если даже не альфу пихать в LTS релиз - для меня загадочно. Разве что, чтобы оставить на Ubuntu только энтузиастов тестировщиков новых фич, как в Fedora, чтобы те, кому нужна стабильность, ушли на тот же Debian. Есть другие предположения?
Ответить | Правка | Наверх | Cообщить модератору

	154. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+3 +/–
	Сообщение от Аноним (151), 06-Июл-26, 13:53
	Уже ушли. Достаточно было перехода на snap. Теперь там только те - кому на все положить, и если что заново систему быстро поставят. А данные - да .... с ними.
	Ответить | Правка | Наверх | Cообщить модератору

168. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	–1 +/–
Сообщение от Володька Драйвер (?), 07-Июл-26, 11:38
Чёт я не понял, почему вообще cp не крякает когда взаимоисключающие параметры? оО Тут не uutils нужно править под поведение gnu utils, а в последних исправлять баг.
Ответить | Правка | Наверх | Cообщить модератору

171. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
Сообщение от MihaNix (ok), 08-Июл-26, 06:23
Из статьи ничего не ясно. Они удаляют и добавляют утилиты из-за какого-то неисправного скрипта? Понял, что некоторые опции конфликтуют и обрабатываются по-разному. Может, стоит просто переписать скрипты правильно, не трогая утилиты?
Ответить | Правка | Наверх | Cообщить модератору

	172. "Возвращение в Ubuntu утилиты cp из Rust Coreutils привело к ..."	+/–
	Сообщение от Аноним (172), 08-Июл-26, 06:58
	> Из статьи ничего не ясно. > Они удаляют и добавляют утилиты из-за какого-то неисправного скрипта? Да. > Понял, что некоторые опции конфликтуют и обрабатываются по-разному. Может, стоит просто  переписать скрипты правильно, не трогая утилиты? К сожалению всё гораздо сложнее. В секто-подобных сообществах, типа линукса, очень развит дuдodroch. Т.е даже если диды писавшие эти утилиты после бухла и марок в 70х науевертили какую-то чушь, то их писание священно и на него надо неистово... Сопровождая это аргументами "у нас тут скриптов, как овна за баней, неужели их надо исправлять? а может оставить? оно конечно овно, но дидовое!" А так да, тут прямо положили болт и на KISS, и на "явное лучше неявного".
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема