Пристрастие Canonical к ИИ и Rust ни для кого не секрет. Теперь компания софинансирует трёхлетний PhD-проект, в рамках которого будет исследоваться, может ли первый перевести большие кодовые базы на C на второй.

Вице-президент по инженерии Джон Сигер объявил об инвестициях на форуме Ubuntu Discourse. PhD-проект будет проводиться в Исследовательской группе языков программирования Бристольского университета.

Так что не паникуйте. Это не объявление о том, что Canonical выпустит ботов переписывать весь Ubuntu в виде ржавой каши. (Для начала, никто не может позволить себе столько токенов.) Вместо того чтобы тратить деньги на ботов, Canonical заплатит будущему учёному, чтобы тот несколько лет изучал, можно ли заставить эту идею работать. Это приятно. В индустрии, переполненной хайпом, проект должен предоставить доказательства того, может ли такой подход быть полезным.

The Reg FOSS desk брал интервью у Сигера в прошлом году, и он показался нам здравомыслящим и прагматичным, но не лишённым смелости. Под его руководством Ubuntu 25.10 приняла Rust-реализацию sudo, а также полностью отдельные Rust-основанные uutils coreutils. Команда sudo столкнулась с некоторыми проблемами, но они были быстро исправлены.

Однако и uutils, и sudo-rs были уже существующими независимыми проектами. Это написанные человеком замены, предназначенные для воспроизведения функциональности существующих инструментов с использованием совершенно новых кодовых баз. Разумеется, эти разработчики-люди могли изучать исходный код – это одно из преимуществ FOSS, в конце концов – но это новые реализации.

Новый проект будет исследовать, может ли LLM взять программы «состоящие из сотен тысяч строк на C» и разложить их на более мелкие компоненты, прежде чем использовать LLM для переписывания этих компонентов на «безопасном, поведенчески корректном и поддерживаемом Rust».

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

Как выражается Сигер: «Традиционные трансляторы “исходник-в-исходник” могут обрабатывать значительные объёмы кода, но часто слишком буквально сохраняют структуру C. Результат может компилироваться как Rust, но всё ещё сильно полагаться на небезопасные операции, сохранять неудобные идиомы C и требовать значительной ручной работы, прежде чем он станет похож на код, который разработчик Rust захотел бы взять на себя».

Мы предлагаем прочитать пост, прежде чем атаковать идею. В нём изложен относительно подробный и взвешенный план. Одним из похвальных аспектов является признание того, что зрелые кодовые базы содержат знания, которые их программисты никогда сознательно не документировали. Годы исправлений и патчей кодируют реакции на реальные граничные случаи, которые никто не предвидел в начале. Это ключевой аргумент эссе Джоэла Спольски 2000 года: Things You Should Never Do, Part I. Такие знания редко документируются вне самого кода или, если повезёт, нескольких комментариев. Машинный перевод может сохранить часть этого поведения, в то время как чистое переписывание человеком на основе оригинального дизайна может его упустить.

В предложении названы два конкретных инструмента, которые проект намерен изучить: snap-confine и AppArmor. Возможно, мы чрезмерно циничны, но openSUSE 16 заменил AppArmor на SELinux в прошлом году. За пределами семейства Ubuntu корпоративный Linux в значительной степени консолидировался вокруг более сложного SELinux, хотя Debian и несколько меньших дистрибутивов продолжают поддерживать AppArmor. Укреплённая Rust-реализация могла бы принести пользу оставшимся пользователям AppArmor. Snap, конечно, имеет ещё более узкую аудиторию.

Это не сольный проект Canonical. Компания софинансирует его вместе с UK Research and Innovation, государственным органом, спонсируемым Департаментом бизнеса, инноваций, науки и торговли Великобритании. Сигер будет руководить проектом совместно с профессором Мэн Ваном и доктором Кристиной Дэвид из Бристольского университета.

Три года — обычная продолжительность для британской PhD — при условии, что она не затянется, конечно. Не то чтобы кто-то мог поступить на PhD в 1998 году и затем получить из этого два десятилетия комиксов или что-то в этом роде.

The Reg FOSS desk остаётся решительно скептичным в отношении генеративного ИИ за пределами узкой области перевода между человеческими языками. Как таковые, мы серьёзно сомневаемся, что это окажется жизнеспособным. Мы подозреваем, что сложной частью будет не перевод кода, а разложение большой кодовой базы на более мелкие компоненты, которые боты смогут переварить. Задача напоминает давнюю попытку автоматически разделить произвольные алгоритмы на задачи, которые можно распределить по параллельным процессам. Десятилетия исследований дали полезные методы для частных случаев, но общего решения нет. Это может оказаться невычислимой проблемой, как Halting Problem – и, как говорится в той статье, если бы её можно было решить, это привело бы к решениям Busy Beaver function или даже гипотезы Гольдбаха.

Как и в случае с большей частью генеративного ИИ, требуется больше доказательств, и получение их — именно то, чем должен заниматься PhD-исследовательский проект. Мы приветствуем Canonical за вложение реальных денег в этот вопрос и были бы рады, если бы наш скептицизм оказался неверным. Как мы предполагали в 2024 году, автоматический перевод между языками программирования может стать чрезвычайно ценным для повышения надёжности программного обеспечения – не за счёт автоматического исправления проблем, а за счёт выявления ранее неизвестных ошибок. ®

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