LINUX.ORG.RU

Ubuntu 26.10 полностью переводит Coreutils на Rust и лицензию MIT после аудита и исправления десятков проблем

 , ,


0

4

В разрабатываемой Ubuntu 26.10 «Stonking Stingray» завершён переход базовых утилит с GNU Coreutils на написанную на Rust и распространяемую по лицензии MIT реализацию uutils/coreutils. В актуальных release notes Ubuntu 26.10 изменение обозначено как «100% Rust coreutils»: последние остававшиеся GNU-версии cp, mv и rm заменены реализациями uutils 17 августа 2026 года, когда в репозиторий Ubuntu вернули Rust-реализацию cp.

Процесс замены начался 12 марта 2025 года, когда Canonical представила план «Carefully But Purposefully Oxidising Ubuntu». Главной причиной называлось повышение безопасности базовых компонентов: Rust позволяет на этапе компиляции исключать целые классы ошибок управления памятью, характерных для C и C++. При этом Canonical подчёркивала зрелость существующих реализаций — GNU Coreutils не объявлялись устаревшими или небезопасными, речь шла о долгосрочной модернизации Ubuntu.

В процессе перехода возникли проблемы не только с не поддерживаемыми параметрами команд, но и c различиями кодов возврата, сообщений об ошибках, работы с правами, символическими ссылками и поведением в пограничных случаях. После внутренней проверки Canonical заказала независимый аудит uutils у Zellic. Как сообщила компания 22 апреля, аудит выявил 113 проблем и привел к публикации 44 уязвимостей CVE.

Наличие memory safety не спасло новую реализацию от логических ошибок. Например, CVE-2026-35338 позволяла обойти защиту chmod --preserve-root из-за неправильной обработки некоторых путей и символических ссылок. Самыми проблемными оказались cp, mv и rm: на 22 апреля 2026 года для них оставались не исправленными 8 критических ошибок, поэтому Canonical сохранила GNU-версии этих команд в Ubuntu 26.04 LTS и перенесла завершение миграции на 26.10.

В процессе исправлялись и многочисленные несовместимости: изменение владельца файла при mv между файловыми системами, проблемы с df и date, отличия поведения cp и другие регрессии. Иногда достаточно было даже другого текста сообщения об ошибке, чтобы сломать существующий тест — одна такая несовместимость cp была зарегистрирована летом.

Показательна история другого участника программы — sudo-rs. 31 августа 2026 года разработчики сообщили о TOCTOU-уязвимости в sudoedit с оценкой CVSS 6.4: при определённой конфигурации гонка позволяла записать файл в другой каталог и потенциально повысить привилегии. 1 сентября Canonical выпустила USN-8708-1 с исправлением. Этот случай хорошо показывает, что Rust защищает от многих ошибок работы с памятью, но не способен автоматически предотвратить логические ошибки.

Работа над uutils продолжается. В выпущенной 17 сентября версии coreutils 0.12.0 разработчики заявили об устранении всех проблем, которым Ubuntu присвоила приоритет, и добавили дополнительные защиты cp, mv и rm.

Переход занял более полутора лет и потребовал независимого аудита, исправления десятков уязвимостей и многочисленных проблем совместимости. Ubuntu 26.10 станет первым выпуском, где стандартный набор Coreutils полностью предоставляется uutils, одновременно демонстрируя и преимущества Rust, и то, что безопасность языка не заменяет зрелость реализации и длительное тестирование.

Исходные коды проекта

>>> Источник

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 5)
Ответ на: комментарий от mister_VA

И обеспечили совместимость со всеми теми скриптами, в которых используются заменённые утилиты, что понаписали конечные пользователи за последние 30 лет.

C чего ты взял что это было в целях проекта?

Хотите безопасности – пишите на Аде.

Мамке своей будешь рассказывать что на ужин хочешь. Программисты без анонимусов как-нибудь определятся на чём им писать :)

или «Едином Лиспе».

А это что за чудо?

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

Ленинград «Дорожная» более уместна.

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

Если бы переписали какой проект, где никак не могут побороть утечки памяти и сегфолты на ровном месте… А переписывать с ошибками утилиты, которым больше лет, чем Линуксу…

Как в этом топике неоднократно уже упоминали, в этом проекте, которому больше лет, чем Линуксу, в апреле этого года пофиксили порчу памяти в таком сложном приложении как pwd.

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

Да, конечно. И агенты справляются с кодом на расте намного лучше, чем с си, яваскриптом или питоном. Потому что компилятор встроен в цепочку обратной связи обеспечения корректности программы. Другое дело, что пока что они не достигли уровня человека в написании программ.

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

И агенты справляются с кодом на расте намного лучше, чем с си, яваскриптом или питоном.

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

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

Другое дело, что пока что они не достигли уровня человека в написании программ.

Они, возможно, и не достигнут. Не в том цель, достичь уровня и качества человека, на мой взгляд. Цель достигнуть нужного уровня и качества дешевле или быстрее, здесь уже варианты кто и как оценивает код.

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

подыграть маркетинговой кампании про «безопасный язык».

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

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

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

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

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

Ну так вот. Если звезды совпали и у вас есть все необходимое, то вполне себе возможно и использовать данный ЯП - почему нет? А вот если этого нет, то вы очень рисковый человек.

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

ой, наверно ты ссылкой ошибся.. да? (случайно перепутал)

ато ни как не могу увидить где там про coreutils :-)

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

не переопределяются-ли в данных библиотеках и фреймворках - стандартные функции. Потому как я лично столкивался с таким не один раз

На расте? Это как вообще?

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

На расте? Это как вообще?

Нет. Вот смотри. У раста есть возможность использования сишных библиотек и фреймворков. Это разумно. Но вот внутри этих самых сишных (или си++) либ, могут идти переопределния. И вот тут у тебя и так засада, а в случии с растом - двойная.

DrRulez ★★★★★
()
Последнее исправление: DrRulez (всего исправлений: 1)

Я надеюсь есть возможность откатиться на нормальные тулзы

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

Всё это наводит на параноидальные мысли о том, что дело было совсем не в Расте. Раст неуиновен.

советская пропаганда опять оказалась права?

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

Он же написал: компилятор встроен в контур обратной связи. Мне вот интересно стало, если на том же питоне иишку задромучать всякими литерами, будет ли качество сопоставимо. и сколько это токенов будет.

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

Но вот внутри этих самых сишных (или си++) либ, могут идти переопределния.

Окей, а как это затрагивает раст?

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

Окей, а как это затрагивает раст?

Это затрагивает не сам раст, а скорость разработки. Ведь разговор и начался с этого. Потому как одно дело, когда там всякие гранты (тут верно вспомнили), а другое дело - коммерческие проекты. Где скорость один из показателей. и если ты не можешь использовать что-то повторно - тебе это придется создавать с 0. А это и время и деньги.

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

Интересный, конечно, вариант дислексии…

Поглядел бы я на тебя, если б ты на Rust писал. Говорят, один мальчик за пол года переписывания Notepad при помощи Rust попал в дурку, так что дислексия - это еще легко отделался…

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

называющие GPL «фашистской»

Мешают серьезным дядям на чужом труде на халяву бабки рубить - истинные фашисты :))

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

Мешают серьезным дядям на чужом труде на халяву бабки рубить - истинные фашисты :))

Да нисколько оно никогда не мешает :) Я тут как-то уже приводил в пример тв lg - он битком набит этим спо под гпл. И да - там перечислены ссылки на использованные проекты (достаточно глубоко в меню). И что дальше? Это как-то помешало «бабки рубить»? А уж в случае библиотек - и подавно. Свой софт - закрыл, под какой угодно лицензией, потом указал ссылки на проекты, или даже просто упомянул (если кому-то приспичет - можно и выслать) и - все.

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

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

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

Так вот, иногда (а может и чаще - я не настолько погружался в вопрос) использовать подобные библиотеки и фреймворки - не представляется возможным.

С одной стороны, сказано правильно, но на мой взгляд вы смешали две вещи, которые смешивать не следует. Как мы все знаем, существует четыре этапа проекта - планирование, выполнение, тестирование, и поддержка. В нашем разговоре речь о первых двух.

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

На этапе исполнения библиотеки и фреймворки «вдруг» не выбираются и не замещаются. Поэтому

Как только вы сталкиваетесь с подобными случаями - время разработки у вас - увеличивается и, как следствие, проект начинает непредсказуемо дорожать.

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

P.S. В тексте выше использованы максимально близкие русские аналоги английским терминам projects and milestones, execution, risk matrix, schedule, budget, FTE, dependencies, mitigation plan, backup plan, alternative analysis, risk owner, milestone owner, risk color map, risk trigger. Я не оперирую русскими терминами в повседневной жизни много лет, поэтому мог написать сумбурно. Надеюсь, суть я всё-таки передал.

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

Я отвечал вот на это сообщение, привожу его здесь целиком

Да, конечно. И агенты справляются с кодом на расте намного лучше, чем с си, яваскриптом или питоном. Потому что компилятор встроен в цепочку обратной связи обеспечения корректности программы. Другое дело, что пока что они не достигли уровня человека в написании программ.

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

Я так не думаю. Поэтому комментировать не стал, а просто опустил. Утверждение не только спорное, а вообще на мой взгляд неверное.

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

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

Говорят, один мальчик за пол года переписывания Notepad при помощи Rust попал в дурку …

Связь, конечно же, задокументирована и сомнению не подлежит. Если это так, «то надо немедленно сообщить об этом президенту США, генеральному секретарю ООН, и начальнику товарно-сырьевой биржи» с просьбой законодательно запретить раст как язык, колечащий здоровье и психику детей.

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

Не, ну погоди. Сравнивая cpp и раст, я легко могу представить ситуацию, когда например забыли освободить память. У меня нет-нет да и забудет закрывающую скобку поставить. Тогда как раст это сразу увидит и скажет: ай-ай-ай. В Питоне, например, эта проблема менее острая, т.к. с памятью он не работает, но для ресурсов, которые надо освобождать, есть конструкция with, которая гарантирует, что всё, что было взято, будет положено на место. Так что в то, что выбор языка имеет значение, я охотно верю.

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

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

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

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

компилятор языка раст встроен в цепочку обратной связи обеспечения корректности программы, а вот компилятор языка си или интерпретаторов яваскрипт и питон по-видимому никак нельзя встроить в цепочку связи.

Дело не в том, что они не встроены, а в том, что компилятор языка программирования с сильной статической типизацией (а в случае раста, ещё и с борроу-чекером) строже проверит код программы и поймает больше проблем ещё на этапе компиляции.

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

А что значит логотип Адептус Механикус с символом Ультрамара внутри?

Символ технодесантников Ультрамарин?

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

строже проверит код программы и поймает больше проблем ещё на этапе компиляции.

Ошибки логические и проектирования никакой компилятор не поймает. И unsafe может творить любую дичь.

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

Ошибки логические и проектирования никакой компилятор не поймает.

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

unsafe может творить любую дичь.

В типичной программе его нет. «Любая дичь» сводится к одному из пяти пунктов:

  • Разыменование сырого указателя
  • Вызов функции с пометкой unsafe
  • Доступ к мутабельной статической переменной
  • Реализация трейта с пометкой unsafe
  • Доступ к полям union
unC0Rr ★★★★★
()
Последнее исправление: unC0Rr (всего исправлений: 1)
Ответ на: комментарий от zabbal

Программисты без анонимусов как-нибудь определятся на чём им писать :)

Нет, не определятся. Всё погрязнет в бесконечных спорах, на чём писать и как.

Нужен вышестоящий авторитет, который скажет: «Это вот так, это вот так!» И за любую попытку сделать не так будет нещадно лупить ослушавшегося программиста кнутом. Только в таком случае будет результат.

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

Но вообще, не понятно, нафига для coreutils раст.

Переписывать и так работающий софт смысла нет. Одно только приходит в голову - «push Rust deep into» (c) AMD

Уплочено, поди.

Если поскрести этих растопереписывателей, всегда грантоедик из-под ржавчины показывает свой вострый нос :)

Rust в софте, типа Мозиллы - оправдан. Там триллион аллокаций, мультитредовость, легко можно нагадить себе в штаны, особенно учитывая СКОЛЬКО там разработчиков.

Но cp, mv, rm, ..ээ… извините.

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

Если сделать ошибочные состояния программы невыразимыми, то поймает.

Да да. Это называется - писать без ошибок (ну, если вы и так знаете про ошибочные состояния программы и делаете их невыразимыми).

«Предлагается новый комбайн по сбору лесных грибов. Вам нужно лишь найти гриб, расчистить площадку вокруг него, а остальное сделает комбайн!»

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

Да да. Это называется - писать без ошибок

Нет, это называется проектировать. Простейший пример: тип NonZero означает 32-битное целое, отличающееся от нуля. Если вдруг нужно поделить на него, можно обойтись без проверки на ноль.

знаете про ошибочные состояния программы и делаете их невыразимыми

Сейчас делаешь их невыразимыми, а потом через пять лет кто-то другой программу срочно патчит ради новых фич, и не ломает старый код, ну не чудо ли!

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

Я б зашёл с другой стороны. Вот, в статически-типизированных языках исключён целый класс ошибок, которые есть в динамически типизированных. До определённой степени проблему можно поправить линтерами, статическими анализаторами и тестами, но это и сложнее, и хуже прямой проверки компилятором. Однако, (при определённых условиях) динамическая типизация ускоряет разработку, так что своя ниша есть и оба типа языков сосуществуют вместе. В случае С vs Rust мы имеем ту же дилемму: обмазаться помогайками или положиться на компилятор. Спрашивается, а чего ради нужно выбрать первый вариант, какое-такое у него скрытое достоинство? Пока что в этом обсуждении внятного ответа я не вижу.

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

динамическая типизация ускоряет разработку

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

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

зато до этапа «запустилось, работает как надо» рукой подать, в отличие от.

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

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

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

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

Вот есть у вас какое-то хранилище обхектов. И вы указатели на них держите в ста местах.

Логично сделать помогайку-рефкаунтер, например. И не мучаться со всем остальным, объясняя компилятору очевидное.

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

Я вообще считаю этот термин крайне спорным.

На чем быстрее спрототипируете парсер какого-нибудь синтаксиса простенького - на Rust или на PHP?

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

А остальное - и так сойдет.

Очень интересно вы слона продаёте.

И не мучаться со всем остальным, объясняя компилятору очевидное.

Так на сишке именно это и происходит. Вы либо портите память, либо руками объясняете компилятору всё то же самое, что rust делает автоматом.

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

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

В Питон давно завезли аннотацию типов. Пиши нормально - нормально будет.

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

И любые попытки сначала всё придумать, а потом исполнить приводят к провалу, либо к таким монстрам, что лучше б провалились.

На это у меня есть ответ.

  1. Потому что требования заранее неизвестны. И часто меняются в процессе.
  2. Программисты обожают всё обобщать и с удовольствием сделают фабрику по производству фабрик.

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

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

Дело не в том, что они не встроены, а в том, что компилятор языка программирования с сильной статической типизацией (а в случае раста, ещё и с борроу-чекером) строже проверит код программы и поймает больше проблем ещё на этапе компиляции.

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

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

«то надо немедленно сообщить об этом президенту США, генеральному секретарю ООН, и начальнику товарно-сырьевой биржи»

И в Спортлото обязательно!

Когда была сказана шутка про президента США и товарно-сырьевую биржу (в фильме Ширли-мырли любимого нашего товарища Меньшова), писать в Спортлото было уже неактуально.

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

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

Конечно, такое сплошь и рядом. Дотошный кодогенератор сгенерирует больше тестов на отлов ошибок памяти, просто будет мерять потребление до нового кода и после. Если кодогенератор не очень дотошный, то оператор всегда может «попросить» специально сгенерировать больше тестов на этот тип ошибок.

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

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

Парсер? На хаскеле. На расте с библиотекой nom немного помедленнее. С пхп страшно представить, как этот парсер придётся отлаживать.

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

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

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

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

Много думал. Это поиграться или есть планы поменять утилс?

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

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