LINUX.ORG.RU

В Debian намерены добавить Rust в число обязательных зависимостей к APT

 , , ,


1

6

Джулиан Андрес Клоде (Julian Andres Klode), основной сопровождающий проект APT, объявил о решении добавить код на языке Rust в пакетный менеджер APT, а также включить в число обязательных зависимостей компилятор Rust, стандартную библиотеку Rust и PGP-инструментарий от проекта Sequoia, написанный на Rust. Изменения намерены реализовать не раньше мая 2026 года, чтобы дать разработчикам портов Debian полгода на реализацию корректной работы инструментария Rust или сворачивание порта.

На Rust планируют реализовать компоненты APT, требующие повышенного внимания с точки зрения безопасности, такие как парсеры форматов deb, ar и tar, а также код для проверки цифровых подписей. Ранее, в состав APT 3.0 уже была добавлена возможность использования написанной на Rust утилиты sqv для проверки цифровых подписей вместо вызова gpgv.

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

Ранее сообщалось, что из-за ошибки в uutils в Ubuntu 25.10 перестала работать автоматическая проверка наличия обновлений.

Оригинал:

Hi all,

I plan to introduce hard Rust dependencies and Rust code into
APT, no earlier than May 2026. This extends at first to the
Rust compiler and standard library, and the Sequoia ecosystem.

In particular, our code to parse .deb, .ar, .tar, and the
HTTP signature verification code would strongly benefit
from memory safe languages and a stronger approach to
unit testing.

If you maintain a port without a working Rust toolchain,
please ensure it has one within the next 6 months, or
sunset the port.

It's important for the project as whole to be able to
move forward and rely on modern tools and technologies
and not be held back by trying to shoehorn modern software
on retro computing devices.

Thank you for your understanding.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

>>> Источник



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

Нет, только профнепригодных. Кучу мусорного софта (например всё что вокруг небраузерного джаваскрипта, всякие го с докерами итд) можно вообще не писать, останется только хороший софт и на нём будут сконцентрированы усилия хороших программистов, без всяких «ой меня компилятор не подкостылил».

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

Rust (как минимум, лично мне) кажется половинчатым решением поставленных проблем. Гораздо интереснее было бы увидеть отдельный язык вроде Dafny или F*, но предназначенный для системного программирования (то есть, в частности, с возможностями рассуждать о владении объектов). Такой язык бы смог, например, статически гарантировать корректность алгоритмов на циклических структурах данных наиболее естественным образом.

Но в Rust, конечно, сейчас влиты колоссальные деньги; да и даже к нему многие привыкают с большим трудом, что‐то более продвинутое внедрить ещё сложнее.

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

Но в Rust, конечно, сейчас влиты колоссальные деньги; да и даже к нему многие привыкают с большим трудом, что‐то более продвинутое внедрить ещё сложнее.

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

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

Sm0ke85
() автор топика

А может кто-то объяснить, нафига apt-у компилятор? Он что-то будет собирать при установке пакетов? Типа как emerge?

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

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

Погоди. Но ведь это ты тут жалуешься на то, что компиляторы тебе код ломают своими оптимизациями при включении -O2 или -O3. Или это другое?

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

Но в Rust, конечно, сейчас влиты колоссальные деньги

А вот тут может быть и ответ. Топ менеджеры, которые сами по себе далеко не всегда технари, хотят видеть отчеты: смотрите, вот какой язык, ну-ка ноги в руки и внедряйте, уплочено ведь. И потом будут красиво распинаться на презентациях, как они внедрили rust/ai и т.п.

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

А вот тут может быть и ответ. Топ менеджеры, которые сами по себе далеко не всегда технари, хотят видеть отчеты: смотрите, вот какой язык, ну-ка ноги в руки и внедряйте, уплочено ведь. И потом будут красиво распинаться на презентациях, как они внедрили rust/ai и т.п.

Так тут же есть обратная сторона: неизбежны баги, нестабильность и прочее, сами разрабы подмечают что запросто пара стабильных выпусков дебина может оказаться нестабильными (это правда похоже не утверждение, а предположение с учетом тенденций) и это только в связи с текущей новостью…

Sm0ke85
() автор топика
Ответ на: комментарий от BerlinFall

Гораздо интереснее было бы увидеть отдельный язык вроде Dafny или F*, но предназначенный для системного программирования

ATS существует, но сишники его не осилят

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

ATS существует, но сишники его не осилят

А с чего его Си-шники должны осваивать, собственно…?

Да и создатель с именем «Хонвэй Си», как бы похоже просто хайпануть решил, судя по имени, это ж похоже вообще местечковая история, без намеков на амбиции…

Sm0ke85
() автор топика
Ответ на: комментарий от Sm0ke85

Так тут же есть обратная сторона: неизбежны баги, нестабильность и прочее

Как пить дать

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

не так уж и давно в расте были классы (на сколько я слышал, просуществовали они около пол года), а потом их вдруг не стало

Ну то есть компетентность в вопросе у вас отрицательная. Классы в Rust существовали ещё до версии 1.0, когда дизайн языка банально ещё не оформился. После версии 1.0 Rust поддерживает обратную совместимость, а для введения ломающих её изменений в язык предусмотрены редакции

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

Ну то есть компетентность в вопросе у вас отрицательная. Классы в Rust существовали ещё до версии 1.0, когда дизайн языка банально ещё не оформился. После версии 1.0 Rust поддерживает обратную совместимость, а для введения ломающих её изменений в язык предусмотрены редакции

Я себя на эксперты в расте не заявлял ни разу, если что… А у Вас видимо и компетенции, и гарантии есть, что к очередной версии не получится как было с питоном, я так понимаю…?

Sm0ke85
() автор топика
Ответ на: комментарий от Nexmean

Насколько мне известно, основной механизм управления памятью в ATS — это линейные типы; то есть примерно то же решение, что и в Rust.

Потом, использование зависимых типов для выражения спецификаций в системном языке выглядит как перебор, потому что они существенно усложняют язык. Реализовать простую зависимую теорию типов на готовом языке с GC не так сложно, конечно, если знаешь, что делаешь; но вот внедрить DTT в системный язык, да так, чтобы она не конфликтовала с линейными типами, индуктивными типами и предикатами, шаблонами (!) и остальными фичами из ATS, уже куда сложнее.

Поэтому мне кажется, что разумнее иметь простой базовый императивный язык, логику Хоара поверх и верификатор для неё. Ну а как обеспечить малое ядро для верификатора при сохранении возможности подключить автоматику уже давно придумали в LCF.

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

BerlinFall
()

Хотят какие-то часте на расте написать - ну почему бы и нет, только зачем компилятор в обязательных зависимостях? Предлагается apt собирать перед каждым запуском?

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

А я давно уже вырос из школьного возраста и по поводу винды не комплексую.

Просто винда уже совсем не та.

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

использование зависимых типов для выражения спецификаций в системном языке выглядит как перебор

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

простой базовый императивный язык

И получим ситуацию как с тестами без настроенного CI – половина из них постоянно сломана.

логику Хоара

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

Nexmean
()
Ответ на: комментарий от Sm0ke85

В моем случае, мне исходя из необходимого софта удобней на той машинке винда (тут без комплексов, строгая необходимость), а вот отсутствие привычной консольки очень коробит(((

Вместе с гитом в систему попадает git bash.

sarumeister
()
Ответ на: комментарий от Sm0ke85

но по сути этот ЯП ничего революционного не представляет

В самом по себе факте, что пиарят не наиболее революционные языки, я проблемы не вижу. Даже наоборот, как правило, по‐настоящему революционные языки обычно имеют строго ограниченную аудиторию, а популярность получают их более консервативные развития. Например, а) оригинальная реализация LISP осталась где‐то в веках, зато Common Lisp и Racket многим известны, б) Standard ML так и остался в академических кругах, зато его прямой родственник OCaml и его очень‐очень дальний родственник Haskell встречаются в индустрии, в) наконец, оригинальный компилятор C до наших дней, наверное, дошёл только по частям как компилятор из 9front со специфическими расширениями, зато gcc и clang и стандарт C99 сейчас буквально в каждом утюге.

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

также напомню о важности стандартизации

Формальности вроде ISO не самоценны, а над reference они вроде работают. Лучше, конечно, иметь формальную спецификацию как Standard ML, но и reference — неплохо, у некоторых и его нет.

BerlinFall
()
Ответ на: комментарий от Nexmean

Я вот смотрю на это все и все таки не могу понять:

Почему каждый пытается создать или найти другой язык на место Си, если можно создать библиотечку и иметь все что Вам требуется но в Си (typedef существует, да все есть собственно, даже классы можно с наследованием прикрутить и это можно будет потом еще под тонну всего компильнуть при этом и компилятор ничего толком не весит/излишне не перегружен)? Почему проблему выхода за границу массива не решить просто на уровне кастомного типа в заголовочнике?

Sm0ke85
() автор топика

объявил о решении добавить код на языке Rust в пакетный менеджер APT

А нельзя ли сначала переписать dpkg на C++?

уже была добавлена возможность использования написанной на Rust утилиты sqv

$ apt info sqv:

Depends: libc6 (>= 2.38), libgcc-s1 (>= 4.2), libgmp10 (>= 2:6.3.0+dfsg), libhogweed6t64, libnettle8t64 (>= 3.9~)

Как-то она не полностью переписана.

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

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

Я не говорил о необходимости покрытия, я говорил о сложности реализации того или иного подхода. Зависимые типы — не самый простой подход.

И получим ситуацию как с тестами без настроенного CI – половина из них постоянно сломана.

Не понимаю, причём тут тесты и CI, когда речь о покрытии формальными доказательствами; вот как в Dafny, например.

Логики Хоара недостаточно, нужна сепарационная логика, а там и линейные типы.

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

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

А это уже неправда: вот посмотрите на ту же Dafny, в которой зависимых типов нет, а возможность доказать невыход за пределы массива — есть.

BerlinFall
()
Ответ на: комментарий от aol

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

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

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

Не понимаю, причём тут тесты и CI, когда речь о покрытии формальными доказательствами; вот как в Dafny, например.

При том, что если программа не проходящая проверку типов будет компилироваться и запускаться, то 90% программистов забьют на эти самые типы, ибо они «лучше знают»

Nexmean
()
Ответ на: комментарий от BerlinFall

В самом по себе факте, что пиарят не наиболее революционные языки

Пиарят обычно то, с чего собрались заработать, тут про «революционность» заблуждаться не стоит (напомню, что google не плохо зарабатывает и многое из того, что он пиарил обернулось сверхприбылями для гугл)

Формальности вроде ISO не самоценны

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

Sm0ke85
() автор топика
Ответ на: комментарий от Sm0ke85

Почему проблему выхода за границу массива не решить просто на уровне кастомного типа в заголовочнике?

Очевидно, потому что система типов C не способна самостоятельно такое выразить. Бывают, конечно, подходы, когда поверх C чего‐нибудь навешивают; вот, например, сразу нагуглился некий C★, наверное, есть умельцы, которые сбоку к C и borrow‐checker прикрутили. Но когда мы прикручиваем нечто сбоку, неизбежна слабая интеграция с исходным языком, что влечёт очевидные проблемы; помимо того, что это зачастую выглядит слегка глуповато, как тот же Liquid Haskell.

BerlinFall
()
Ответ на: комментарий от Nexmean

В вашем недоязычке даже проблему void* ехала через void* не решить, что уж говорить об остальном

ок гугл:

Чтобы решить проблему с void*, вам нужно выполнить явное приведение (кастинг) универсального указателя к нужному типу данных, чтобы с ним можно было работать, например, static_cast в C++. void* сам по себе может указывать на любой тип, но для доступа к данным он должен быть преобразован к конкретному типу. 
Sm0ke85
() автор топика
Ответ на: комментарий от BerlinFall

Даже наоборот, как правило, по‐настоящему революционные языки обычно имеют строго ограниченную аудиторию, а популярность получают их более консервативные развития

В целом утверждение верное, но примеры подобраны такие, что они скорее опровергают его, чем подтверждают. Тут лучше подойдут примеры Scala -> Kotlin и ATS -> Rust.

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

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

BerlinFall
()
Ответ на: комментарий от Nexmean

При том, что если программа не проходящая проверку типов будет компилироваться и запускаться, то 90% программистов забьют на эти самые типы, ибо они «лучше знают»

Ты ж не путай «программиста» и Программиста. То-то я смотрю многие в раст в этот вцепились…

Sm0ke85
() автор топика

«проект мог двигаться вперёд и опираться на современные инструментарии и технологии»

а что в проекте сейчас не работает что ему офигеть как нужны все эти современные костыли?

bernd ★★★★★
()

Rest^WRust in Pieces.

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

ЯП решил «сэволюционировать» в угоду очередному тренду.

Да и переусложненный компилятор многие вещи делает непрозрачными/скрытыми от программиста

Точное описание цпп. Сильно ему помогает наличие стандартов?

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

Очевидно, потому что система типов C не способна самостоятельно такое выразить. Бывают, конечно, подходы, когда поверх C чего‐нибудь навешивают; вот, например, сразу нагуглился некий C★, наверное, есть умельцы, которые сбоку к C и borrow‐checker прикрутили. Но когда мы прикручиваем нечто сбоку, неизбежна слабая интеграция с исходным языком, что влечёт очевидные проблемы; помимо того, что это зачастую выглядит слегка глуповато, как тот же Liquid Haskell.

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

На задуматься: если за тебя решает компилятор, то дальше за тебя будет решать ИИ, т.к. разница собственно будет невелика, соответственно, далее вся эта махина плывет своим путем извлекая прибыли, но без тебя (как программиста)…

Sm0ke85
() автор топика
Ответ на: комментарий от Nexmean

Вот это статическая типизация конечно, жесть

Вообще-то это удобно и позволяет некоторые трюки проделывать при программировании, а ваши расистские восклицания оставляйте при себе, либо аргументируйте…

Sm0ke85
() автор топика
Ответ на: комментарий от Sm0ke85

если за тебя решает компилятор, то дальше за тебя будет решать ИИ

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

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

Да ладно, коробки передач, но ещё ABS и ADAS. Возомнят о себе хер пойми что, поотключают всё это, а потом люди гибнут.

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

Это вы не путайте программиста и «рокзвезду», чьё хрупкое эго способен задеть тайпчекер

И такое бывает, тут по всякому случается))) Однако, я бы предпочел операцию у хирурга, нежели у робота, которому отдаст команду вчерашний ординатор, ибо всяко бывает…

Sm0ke85
() автор топика
Ответ на: комментарий от anatole

линкуются с libc

Какое отношение к этому имеет хотя бы libgmp?

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

На задуматься: если за тебя решает компилятор, то дальше за тебя будет решать ИИ, т.к. разница собственно будет невелика, соответственно, далее вся эта махина плывет своим путем извлекая прибыли, но без тебя (как программиста)…

Всё‐таки есть принципиальная разница между компилятором и LLM. Если даже нет возможности понять работу компилятора во всех деталях (и правда, поди разберись, что там в gcc к чему), есть возможность понять её в целом, хотя бы наиболее существенные части вроде проверки типов и, например, того же borrow‐checker’а. Более того, при должном усердии можно в учебных целях написать собственный компилятор с собственным borrow‐checker’ом, даже если в качестве рабочей машины используется ноутбук из прошлого века. LLM же в настоящее время для нас представляется как чёрный ящик; поэтому пока что никаких шансов понять его нет, а повторить ту или иную LLM можно лишь при наличии колоссального объёма данных и вычислительных ресурсов.

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

Ну и, наконец, компилятор не обязан быть распухшим и монолитным; это распространённая особенность современных компиляторов, но не какое‐то врождённое свойство.

BerlinFall
()
Последнее исправление: BerlinFall (всего исправлений: 2)

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

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