Rust залезает в Debian по самые гланды

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

И, как я писал выше, у меня Arch Linux как основа, а там pacman.

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

Во всяком случае, на бумажке писать не надо, все записано в yum history. А внимательно смотреть при undo все равно надо.

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

Печаль. Впрочем, дропание i386 и так уже поставило под вопрос дальнейшие обновления.

x86_64 уже 22 года. Это примерно как в 2007 году ныть, что 80286 больше не поддерживается и нужно аж 80386 ставить!

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

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

Расскажешь такое разрабам, пишущим под Windows или Mac, так засмеют же сразу.

Ведь систем без Rust становится всё меньше!

Да что уж там, раст уже в ядре!!! Надо срочно переползать на *BSD или Haiku

Бег от systemd не удался, и этот не удастся.

Все

Хех

Very few applications are using io_uring though because it’s quite difficult to handle it correctly in C. We’re able to use an async executor built around it in Rust so it’s not actually that hard to implement here. Rust has native syntax for async/await and the memory safety features help with creating memory safe APIs for it.

difficult to handle it correctly in C

с чего бы это…

Вот вам и реальная причина почему необходимо переписывать с С/С++, может, и не так хорош раст как кривы и дырявы эти двое. В этом самом io_uring постоянно находят и чинят дыры https://www.opennet.ru/search.shtml?words=%D5%D1%DA%D7%C9%CD%CF%D3%D4%D8+%D7+io_uring+&config=&restrict= и не кто не знает не осталось ли там ещё. Т.е. сложность системщины давно переросла возможности, то-ли сишки то-ли сишников то-ли их вместе взятых, писать одновременно и сложный и корректный алгоритм.

Ведь систем без Rust становится всё меньше!

А минусы? Что плохого в Rust и что на нем перепишут APT?

В этом самом ведре Linux постоянно находят и чинят дыры и не кто не знает не осталось ли там ещё.

Т.е. сложность системщины давно переросла возможности, то-ли сишки то-ли сишников то-ли их вместе взятых, писать одновременно и сложный и корректный алгоритм.

Чуваки загнали 40 миллионов строк кода на Си в ядро и удивляются, что никто не понимает что там вообще происходит и дыры постоянно вылезают в самых неожиданных местах. Как же так вышло-то? Кто же мог это предсказать-то? Никто же вообще не предупреждал об этом ни разу!

Very few applications are using io_uring though because it’s quite difficult to handle it correctly in C

Тут и правда сишечка виновата. На ней практически нереально писать асинхронный код, потому что из-за бедности языка всё превращается в дичайший callback hell с перекидыванием void* туда-сюда.

Готовы ли ЛОРовцы бежать на другие дистры

Выучим раст и научим небинарных хипстеров писать нормально на нем.

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

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

Нет, скорость развития электроники сейчас в 10 раз меньше чем в 20 веке. Так что эти 22 года это как в 1992 году использовать проц из 1990-го. Но дело даже не в этом, у меня 32-битная система на 64-битном проце и незачем это менять.

Тут и правда сишечка виновата. На ней практически нереально писать асинхронный код, потому что из-за бедности языка всё превращается в дичайший callback hell с перекидыванием void* туда-сюда.

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

Нет, скорость развития электроники сейчас в 10 раз меньше чем в 20 веке. Так что эти 22 года это как в 1992 году использовать проц из 1990-го.

лол нет. В абстрактных попугаях производительность выросла на два порядка.

Но дело даже не в этом, у меня 32-битная система на 64-битном проце и незачем это менять.

Тебе просто нравится страдать. Мы это давно поняли.

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

Можно пример сложного асинхронного кода на Сишечке? Я не про обработчики событий сейчас, если что. Я про future и аналоги.

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

Апхахахахах ну всё, ядро Linux с его структурками, полными указателями на функции, выкидываем на мороз. А потом выкидываем C++ с vtable. После чего можно выкинуть компьютер.

Среди причин традиционно названы лучшая безопасность кода в сравнение с кодом на Си.

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

Само собой если появляется конкурент C/С++ - конечно люди раст выберут.

Апхахахахах ну всё, ядро Linux

Ядро дополнительно огорожено ring0 процовой защитой, поэтому можно простить. А так да, в юзерспейсе так делать не следовало бы.

А потом выкидываем C++ с vtable

Это повод не писать ответственный софт на С++, верно.

Ну и практически все сишные библиотеки тоже.

В хороших колбеки сведены к минимуму или вообще отсутствуют.

Ядро дополнительно огорожено ring0 процовой защитой, поэтому можно простить.

От чего оно огорожено ring0 процовой защитой?

В хороших колбеки сведены к минимуму или вообще отсутствуют.

99% библиотек сложнее libhello будут плохими по твоей логике. Начиная прямо с glibc.

Тут вопрос не в травмах, а в том, как это теоретически должно работать, и как работает на практике.

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

Windows я не пользуюсь уже очень давно, за нее ничего сказать не могу, в ней проблемы куда серьезнее, чем распространение софта, macOS не лучше, запустил .pkg установщик и сиди потом гадай, где оно тебе в ФС насрало и какие расширения ядра докинуло.

Т.е. для этого случая вообще нет универсального решения. Кто-то предоставляет uninstaller внутри установщика («отличная идея», чтобы удалить ПО, мне нужно держать на диске архив с его установщиком), кто-то не предоставляет ничего.

Блин, я мясо не замариновал, а тут такая новость, что у значительной части ЛОРа будет нее гореть, а полыхать. Я бы даже сказал пылать.

Уходят Мастера, их места занимают кодеры-макаки. Это тенденция. Разве нет? При этом наличие Rust-а и его аналогов просто необходимо.

Тут вопрос не в травмах, а в том, как это теоретически должно работать, и как работает на практике.

Да нет, это именно психотравма. Толпы гентушников пересобирают весь софт из сырцов, тратя на это безумные часы и киловатт-часы, лишь бы не ставить лишнюю зависимость в систему. Гномеры не могут поставить условный Amarok, потому что кусочек KDE Frameworks прилетит. Реально же больные люди!

со временем сложность ПО растёт

Не уверен. То, что растёт количество строк, не значит растущую сложность. Это просто copy-paste driven development во всей красе. См. left-pad.

Windows я не пользуюсь уже очень давно, за нее ничего сказать не могу, в ней проблемы куда серьезнее, чем распространение софта

Да, потому что распространение и установка софта там является относительно решённой проблемой.

С другой стороны, в люнексе каждая серверная софтина теперь тянет буквально всю ОС минус ядро с собой, потому что договориться об API и форматах пакетов за 30 лет никто не смог. Я про Docker, если что. Его используют куда больше ради деплоя нежели ради изоляции, последняя просто бонусом идёт.

Например, когда ставил OpenVPN для работы + интеграцию с KDE, схоронил себе списочек, если буду удалять - сверюсь.

У вас, судя по формату версий пакетов, что-то rpm-based, видимо, fedora, а если так, то достаточно пользоваться dnf history / dnf history undo или dnf history rollback.

Как писал выше - Arch Linux.

А почему бежать-то? Много ли лоровцев мэнтейнят в дебиане пакеты?

Те, что отечественную Астру разрабатывают ? :)

AppImage максимально близок к идеалу для меня, но практически я им не пользуюсь.

Gimp свежие версии выкладывает в аппимажах — очень удобно, прямо ни на радуюсь на это (хотя централизованная установка, конечно, всё равно удобней).

Не так страшен rust как его евангелисты. Повторяется история с LGHDTV+ DEI и прочей USAID-approved.

От чего оно огорожено ring0 процовой защитой?

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

99% библиотек сложнее libhello будут плохими по твоей логике. Начиная прямо с glibc.

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

От чего оно огорожено ring0 процовой защитой?

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

Причём тут ring0 тогда? Ты про статическую линковку тут пишешь. С другой стороны,

А без колбека, возможно, и упёрлись бы куда-то без шансов эксплуатации. Ядро же монолитное, если всякие нвидии не считать.

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

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

Я скорее про штуки типа atexit() писал, которые прямо в стандарте требуются. Стандарт сишечки требует коллбэки во все поля! ШОК! СЕНСАЦИЯ!

Причём тут ring0 тогда? Ты про статическую линковку тут пишешь. С другой стороны,

Статическая линковка ни при чём. Библиотеку ты можешь статически слинковать в прогу и она точно так же повысит поверхность атаки.

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

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

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

Не обязательно, вот представь структуру

{
  char str[32];
  void (*cb)(int a);
}

atexit

Да, я что-то про него не подумал. Ну, не знаю что тут сказать.

Колбеки в любом случае избегаю и буду избегать.

Вместо засовывания указателя на функцию в описание ожидаемого события предпочту засунуть туда int/enum с номером обработчика, и потом switch-ем по этому номеру вызвать нужное (а проблему «мы заранее не знаем какие они могут быть» - решать автогенерацией этого свитча исходя из опций компиляции). Аналог таблицы колбеков при этом компилятор тоже иногда сооружает, но уже в read-only секции кода, а не данных.

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

Этот кто-то сам виноват. Увы и ах!

С другой стороны, ведро – это 40 миллионов строк кода, что сравнимо с размерами всего остального программного кода на компе среднего юзера. То есть, на средней люнекс системе половина всего кода будет запущена в kernel space. Вот такие вот пироги.

Не обязательно, вот представь структуру

А вот если бы в Си были нормальные строки с проверкой границ, такой херни бы не было.

Да, я что-то про него не подумал. Ну, не знаю что тут сказать.

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

Хотя насчёт лютого трешака с зависимостями, когда в проекте транзитивно для сборки тянется по 500-600 библиотек, я полностью согласен. Это лютый ад.

Вместо засовывания указателя на функцию в описание ожидаемого события предпочту засунуть туда int/enum с номером обработчика, и потом switch-ем по этому номеру вызвать нужное (а проблему «мы заранее не знаем какие они могут быть» - решать автогенерацией этого свитча исходя из опций компиляции). Аналог таблицы колбеков при этом компилятор тоже иногда сооружает, но уже в read-only секции кода, а не данных.

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

А теперь сделай pthread_create на вот этом. Я хочу это увидеть.

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

Я не пишу то колбеки вообще надо запретить или что колбек обязательно будет проэксплуатирован. И сам даже недавно, мучаясь сомнениями, добавил в свою си-библиотеку возможность форматированной печати в колбек (кроме уже имевшихся вариантов - в буфер в памяти и в fd), правда предусмотрев опцию компиляции для отключения этой фичи. Но не надо ими злоупотреблять.

PM, который при удалении пакетв x мог бы адеватно вынести всю эту кучу, которую он с собой притащил в процессе установки.

Хм, но ведь портаж, если ты удалишь пакет из world, как раз тут же снесёт всё, что он требовал раньше и что осталось не нужно...

И apt снесёт. И dnf тоже. Это, видимо, какие-то фантомные боли арчевода.

Ну, посмотрим. Если будет работать нормально, а не как остальной софт на rust, то ок. Если нет, ну что ж, придётся в мой персональный репозиторий добавить парочку пакетов...

Этим еще лет 20 не грозит заржаветь.

Перепишут на кириллице?

Караул! Куда катится эта страна??!

На вайтспейсе

Там ещё интересней то, что человек, который это всё замутил ультимативно потребовал внедрить Rust во все форки, или закрыть их:

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.

I find this particular wording rather unpleasant and very unusual to
what I’m used to from Debian in the past. I have to admit that I’m a
bit disappointed that such a confrontational approach has been chosen.

Thanks, Adrian

Понятно. Т.е. очередной активист. Никакой практической пользы, ничего полезного. Если debian это примет, однозначно придётся держать форки в своей репе.

Ну, apt не один такой, как минимум.

Готовы ли ЛОРовцы бежать на другие дистры?

Мы уже там, Alpine и OpenBSD, вместе не только вкусно, но и полезно.

ультимативно потребовал внедрить Rust во все форки, или закрыть их:

Это не форки. Это порты Debian на разные железные платформы. В принципе, плохого тут ничего нет, потому что если платформа не поддерживается LLVM, то она 100% дохлая.

Такое ощущение, что Дебианоубунта решила, что теперь ее очередь и пуститилась во все тяжкие, а Федора вообще стала восприниматься как консервативный дистрибутив.

Что-то типа apt-repo list, да?

Или

apt-add-repository --list

Но раст-разработчики маны не читают. Они не читатели, они писатели.

Ищете куда вступить - пользуйтесь тематическими форумами а не ЛОРом, пожалуйста.