После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.18. Среди наиболее заметных изменений: dm-pcache для дискового кэширования в энергонезависимой памяти (PMEM), удаление Bcachefs, online-режим проверки XFS, драйверы Binder (Android IPC) и Tyr (GPU Mali) на Rust, возможность создания USB-драйверов на Rust, оптимизация кэширования в аллокаторе памяти SLUB, адресация пространств имён по файловым дескрипторам, ускорение работы подкачки (swap), верификация BPF-программ по цифровой подписи, виртуализация Intel CET в KVM, сетевой протокол PSP (гибрид TLS и IPsec), поддержка IP-расширения AccECN, оптимизация UDP-стека...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64346
>оптимизация размещения структур данных в памятиRust так не может ведь? Или может? на С это запросто
Надо праздновать релиз свежего ядра, а не спорить кто что может! Накатим!
Ближайшие 20 лет из-за активного переписывания кода толку от линукса не будет. По сути Линус сделал откат в 90-е гг, когда было непонятно, что за инструмент лепится.
Ага, откат. В 90х прям по всюду SMT, KVM, Namespaces, TCP, NFT ....
Да можно просто накатывать, независимот от релизов ядра.
В команде ядра видимо так кто-то делает, и ему зелёные приказали Rust внедрить.
> на С это запростоНа си это надо делать вручную, потому что структуры в памяти лежат в таком же порядке как в коде описаны, а Rust это по дефолту сам оптимизирует для лучшего layout
> На си это надо делать вручнуюСказки-то не рассказывай. С тех пор как лэйаут стал влиять на производительность С делает это автоматом.
Добавить паддинг для выравнивания ≠ оптимизация.
>> На си это надо делать вручную
> Сказки-то не рассказывай. С тех пор как лэйаут стал влиять на производительность
> С делает это автоматом.C только выравнивание добавляет, и твоя задача как программиста сделать так, чтобы после добавления выравнивания структура не выросла слишком сильно, иногда такое надо делать по разному для разных архитектур, и отличие почти всегда только в порядке полей
Предположим
bool b
uint32_t b
bool c
uint32_t dЗаймёт 16 байт, потому что после каждого bool оно добавит 3 байта для выравнивания полей b, d до границ в 4 байта требуемых uint32_t, а
uint32_t a
uint32_t b
bool c
bool dВсего 10, потому что a, b уже выровнены
Rust тоже добавляет выравнивание, однако оптимальный порядок полей определяет сам.
В каких-то очень больших структурах конечно в теории этот порядок может быть не лучшим для кеша, однако это редкость, и в большинстве случаев Rust делает всё правильно.
>однако оптимальный порядок полей определяет самХорошо же в языках без ABI и с одной единственной реализацией
зато какой прекрасный С
сделать упакованную структуру, да пожалуйста. в гцц есть __attribute((packed)).
только это в gcc, для msvc что-то другое. да и в gcc под виндой не работает.
вот такой прекрасный С. куча несовсестимых реализаций, да еще со своими тараканами в зависимости от платформы.
> сделать упакованную структуру, да пожалуйста. в гцц есть __attribute((packed)).Оправдываете свой ник? Ибо не в курсе что это устаревший синтаксис, на замену которого таки сделали стандартный, для навеса атрибутов. Правда, в си сие дошло только к C23. И по моему packed там так и нет в стандартных атрибутах.
> только это в gcc, для msvc что-то другое. да и в gcc под виндой не работает.
Те кто хотел C - msvc не юзали. Ибо этот кусок крапа даже C99 нормально не может. На него сишники и позабивали в ответ. И в целом всем довольно похрен что там у MSVC <-> C.
А линухкернел MSVC билдит примерно 0 человек, так что важность этой проблемы в этом контекста...
> вот такой прекрасный С. куча несовсестимых реализаций, да еще со своими
> тараканами в зависимости от платформы.У Rust своих тараканов хватает. Главный из которых - скачайтеночнушку и какое либо отсутствие намека на стандарты вообще.
> Оправдываете свой ник? Ибо не в курсе что это устаревший синтаксис, на замену которого таки сделали стандартный, для навеса атрибутов.И когда он появился?
> Правда, в си сие дошло только к C23. И по моему packed там так и нет в стандартных атрибутах.
Напомните пожалуйста, а ядро у нас уже С23?
Или всё-таки С11?
Речь же про раст, си и ядро.> Те кто хотел C - msvc не юзали. Ибо этот кусок крапа даже C99 нормально не может.
А кто может)?
GCC не умеет в Floating-point environment.
Даже CGG С23 куча вещей partial support.
Это просто "стандарт" такой хороший, что его можно не реализовывать полностью.
Но СИшникам не впервой помои кушать, и так сойдет.> У Rust своих тараканов хватает. Главный из которых - скачайтеночнушку
Ну так не качайте. Просто фиксируйте edition.
> и какое либо отсутствие намека на стандарты вообще.
Типичное вранье.
Есть RFC - чем тебе не стандартизация? Вон весь интернет на рфцшках сделан и ничего работает.
А во вторых есть Ferrocene Language Specification.
Если говорить о выравнивании, то #pragma pack(n)/#pragma pack(push,N)/#pragma pack(pop) поддерживаются и в MSVC и в GCC.
В GCC, на самом деле, как минимум с версии 4.3, а на самом деле, вполне себе упоминается и в документации к 2.95.3.
И да. Выравнивать структуры смысла нет. Хочешь передавать наружу - пакуй в буфер.
> И да. Выравнивать структуры смысла нет. Хочешь передавать наружу - пакуй в
> буфер.Нюансик в том что упаковка-распаковка - ресурсы жрет! И все тормозит. Для полутора пакетов в час - пофигу. Теперь сделаем это 1.5 M PPS. Все еще пофигу? Не? :)
> И когда он появился?В плюсах довольно давно, C++11 чтоли. В си формально дотумкало - в C23. Поздравляю, цать лет спустя комитет слоупоков смог хотя-бы это.
И до них даже доперло сделать наконец нечто типа [[fallthrough]]. До того... для статических анализеров конечно и так коментили // fallthrhough, но то что сие обязано работать ниоткуда не следовало.
> Напомните пожалуйста, а ядро у нас уже С23? Или всё-таки С11?
До него та благодать, увы, не дошла. Ибо придется круто бампнуть требования к компилеру. Так что да. Легаси нестандарт костыли в руки.
>> Те кто хотел C - msvc не юзали. Ибо этот кусок крапа даже C99 нормально не может.
> А кто может)? GCC не умеет в Floating-point environment.
> Даже CGG С23 куча вещей partial support.И тем не менее, GCC и Clang делают VS в вопросах си начиная с 99 настолько что вот буквально все знакомые алгоритмисты возлюбили опенсорс. Даже в винде. Не то чтобы они рьяные фанаты, но студия на C просто забила болт. А программить как будто даже не 1999 ... что-то народу не зашло.
> Это просто "стандарт" такой хороший, что его можно не реализовывать полностью.
> Но СИшникам не впервой помои кушать, и так сойдет.У Rust - вообще никакого нет, так, для сравнения. И вон там выкатили предложение для линуха требовать "rust версии версии не новее debian stable". Прикольный референс конечно, но... :))
>> У Rust своих тараканов хватает. Главный из которых - скачайтеночнушку
> Ну так не качайте. Просто фиксируйте edition.Ага вон там предлагают зафиксировать ... эээ ... что? Версию раста "как в debian stable"? Т.е. видимо edition настолько профачены - что ими вообще пользоваться не хотят, коли аж вот так.
> Есть RFC - чем тебе не стандартизация?
И кто стандартизирующая организация? Полторы корпы и их хипстеры? У них типичная отмазка - скачайте ночнушку. И она и есть по факту референс.
> Вон весь интернет на рфцшках сделан и ничего работает.
IETF так то - посолиднее standards body чем та куча безблагодатных хипстеров с скачем ночнушек и фактически стандартом она и является.
Еще меня прикалывает что хруст билдится только предыдущей версией. Это вообще просто топ. А альтернативных реализаций что-то по тем "офигенным стандартам" не больно то и дофига.
> А во вторых есть Ferrocene Language Specification.
Ну это все же - специфичная штука, я так понимаю там автомотивщики, чтоли, попытались немного вправить голимым хипстерам мозги. Но получилось как-то пока не очень.
> Те кто хотел C - msvc не юзали.тогда не недо петь про множество компиляторов.
потому как оказываетися есть только 1 настоящий>Ибо этот кусок крапа даже C99 нормально не может
может С17
>А линухкернел MSVC билдит примерно 0 человек, так что важность этой проблемы в этом контекста...
контекст тут такой, что сишники постоянно хвастаются что есть куча компиляторов.
только вот как оказывается, если немного поскребти, то все они какие-то не такие 🤷♂️
> контекст тут такой, что сишники постоянно хвастаются что есть куча компиляторов.
> только вот как оказывается, если немного поскребти, то все они какие-то не такиеЕстественно они разные. Начиная проект выбирают целевую архитектуры и компиляторы под них.
И пишут на общем подмножестве в редких случаях обкладываясь ifdef'ами для реализации минимальной части.
И по другому быть не может.
> msvcЗакрытое ненужно. И, считай, M$ его давно дропнули в пользу clang или Rust, он уже толком современный стандарт C++ не поддерживает.
Размер второй структуры не 10, а 12, так как выравнивание никуда не ушло
❯ cat test.c#include <stdint.h>
#include <stdbool.h>
#include <stdio.h>
struct one {
uint32_t a;
uint32_t b;
bool c;
bool d;
};struct two {
uint32_t a;
bool c;
uint32_t b;
bool d;
};struct __attribute__((packed)) three {
uint32_t a;
bool c;
uint32_t b;
bool d;
};
int main (void) {
printf("one size: %lu\n", sizeof(struct one));
printf("two size: %lu\n", sizeof(struct two));
printf("three size: %lu\n", sizeof(struct three));
}
❯ gcc test.c -O3
❯ ./a.out
one size: 12
two size: 16
three size: 10
> Размер второй структуры не 10, а 12, так как выравнивание никуда не ушлоПрикольно как ALL меряется - implementation defined behavior'ом. При том что его никто никому не гарантировал и он не обязан быть мировой константой.
Вот в случае packed еще на что-то можно уповать. Только он почему-то не в стандарте за столько лет...
> struct __attribute__((packed)) threeИ эти люди что-то там бухтят про перегруженность синтаксиса в других ЯП.
> Размер второй структуры не 10, а 12, так как выравнивание никуда не
> ушлоАй, ну да, sizeof(T) должен делиться на alignof(T) без остатка же
Но это не совсем выравнивание, тут нечего выравнивать, это padding самой структуры
В Rust:
struct One {
a: u32,
b: u32,
c: bool,
d: bool,
}#[repr(C)]
struct OneC {
a: u32,
b: u32,
c: bool,
d: bool,
}#[repr(packed)]
struct OnePacked {
a: u32,
b: u32,
c: bool,
d: bool,
}struct Two {
a: u32,
c: bool,
b: u32,
d: bool,
}#[repr(C)]
struct TwoC {
a: u32,
c: bool,
b: u32,
d: bool,
}#[repr(packed)]
struct TwoPacked {
a: u32,
c: bool,
b: u32,
d: bool,
}fn main() {
println!("One size: {}", size_of::<One>());
println!("OneC size: {}", size_of::<OneC>());
println!("OnePacked size: {}", size_of::<OnePacked>());println!("Two size: {}", size_of::<Two>());
println!("TwoC size: {}", size_of::<TwoC>());
println!("TwoPacked size: {}", size_of::<TwoPacked>());
}
One size: 12
OneC size: 12
OnePacked size: 10
Two size: 12
TwoC size: 16
TwoPacked size: 10
> В Rust:
>
> struct One {
> a: u32,
> b: u32,
> c: bool,
> d: bool,
> }....
>Вау. У сишников было 2 способа это делать. В Rust решили что это не круто - и сделали три :D
Их гораздо больше, чем три: https://doc.rust-lang.org/nomicon/other-reprs.html
> Их гораздо больше, чем три: https://doc.rust-lang.org/nomicon/other-reprs.htmlГлять... я не сомневался в талантах хипстоты, конечно, но чтоб настолько...
неправда, во втором случае будет 12 байтпосле bool добавится 2 байта паддинга
> неправда, во втором случае будет 12 байт
> после bool добавится 2 байта паддингаДа, тупанул, sizeof(T) должен делиться на alignof(T) без остатка же.
> uint32_t a
> uint32_t b
> bool c
> bool d
> Всего 10, потому что a, b уже выровненыТы не расте случайно пишешь?
В этом и проблема - для СИСТЕМНОГО ПО категорически нельзя допускать любых "сам оптимизирует", ибо если завтра добавят модуль на Си с другим лэйаутом (как в коде), растовая "оптимизация" сразу же фэйлит.
Поддерживаю. Самооптимизации вполне себе могут медленно работать, наблюдал такое.
В раст эта оптимизация включается/выключается прямо из кода с помощью директив. Причем для одних структур ее можно включить, а для других выключить.
ты сейчас описал С, как если бы он был с уродским синтаксисом и одним компилятором с проприетарной лицензией
Два чая этому господину
у С уродский синтаксис.
а то что у С много компидяторов, так и С единого нет.
куча кода которая компилируется только одним компиляторм.
маленькие дети пристрастились к ллм-ботам: вроде и слова, но смысла в них ноль, просто белый шум
> у С уродский синтаксис.Смотря с чем сравнивать. По сравнению с Rust C не такой уж и плохой - те приблизились к реализации Brainfuck 2.0 намного ближе, догнав а может и перегнав C++ по количеству странных закорючек. Так что на этом фоне C пожалуй довольно милый.
> у С уродский синтаксис.Rust перещеголял не только его - но и C++ даже по левым закорючкам.
> а то что у С много компидяторов, так и С единого нет.
А у Rust вообще - скачайтеночнушку.
> куча кода которая компилируется только одним компиляторм.В Rust вообще с альтернативными компиляторами - душновато, на минуточку. А в C все же GCC и CLANG есть. Их таки - два.
> ты сейчас описал С, как если бы он был с уродским синтаксисом и одним компилятором с проприетарной лицензиейАдепты Си/Си++ поют про открытость, но как только попросишь у них ссылку на "открытый" стандарт - сразу сливаются.
Слив очередного эксперта через три, два, один...
открытый != бесплатныйвам, собственности корпораций, не понять
www.dii.uchile.cl /~daespino/files/Iso_C_1999_definition.pdfчитай, наслаждайся.
C99 из-под полы? ЛОЛ.
Я наслаждаюсь тем, как вы позоритесь.
> C99 из-под полы? ЛОЛ.Ну скачай последний драфт вместо него - это 100% легально а отличий примерно 0.
> Я наслаждаюсь тем, как вы позоритесь.
А вон те даже и позориться не могут - скачивать нечего...
> Ну скачай последний драфт вместо негоЧерновик оставили в сортире, чтоб подтираться, а они зачем‑то его читают.
Особенный склад ума...
> В этом и проблема - для СИСТЕМНОГО ПО категорически нельзя допускать любых
> "сам оптимизирует", ибо если завтра добавят модуль на Си с другим
> лэйаутом (как в коде), растовая "оптимизация" сразу же фэйлит.Если структуру нужно шарить с C - то её можно явно пометить #[repr(C)], и тогда её layout будет совпадать между Rust и C
Что однако не мешает использовать в Rust коде свои, оптимизированные структуры
>Что однако не мешает использовать в Rust коде свои, оптимизированные структурыТочно не мешает? А если у тебя в системе уже установлена библиотека собранная одной версией раста и ты хочешь запустить собранную другой версией компилятора программу, у которой она в зависимостях. Ничего не сломается? А алгоритм вычисления оптимального порядка полей точно стабильный?
А если библиотека собрана другим СИ компилятором?
То как оно себя поведет?
Нормально поведёт, ABI-то у си стандартизирован.
> Нормально поведёт, ABI-то у си стандартизирован.АБИ то да, а вот поведение компиляфтора на одном и том же коде - нет.
Т.е ты просто сменил компилятор, а либа вместо одного поведения делает что-то неожиданное.
>а либа вместо одного поведения делает что-то неожиданноеЧто например? Оттранслирует свой код в раст и перекомпилируется в рантайме?
Ты против коммерции? Для ознакомления скачивай с интернета хоть все драфты всех стандартов. Другое дело что для бизнеса такое не подходит им надо официальную бумажку. Вот для них официальные бумажки (файлики) и продаются. Комитет зарабатывает на свое существование.
> АБИ то да, а вот поведение компиляфтора на одном и том же коде - нет.Все что видно наружу компилер ОБЯЗАН генерить conformant вооооооон тому ABI которое запрошено. И только так. Что оно там внутри делает - всем пофиг. Но наружу - должно быть так. И да, ABI в сях переживают смену версий компилера и их произвольную смесь - иначе на кой бы черт это надо было?!
> Если структуру нужно шарить с C - то её можно явно пометить #[repr(C)],
> и тогда её layout будет совпадать между Rust и CА, простите, "межмодульные" ABI на вот именно Rust как предлагается делать?
Допустим у меня есть бутлоадер или фирмварь. И есть ядро или main app которые оно запускает. Как из main app вызвать функцию boot loader/firmware с предсказуемым ABI, в допущении что это разные куски которые ребилдядся и апдейтятся независимо - и поэтмоу ABI вызова должно совпадать? Что, писать что это - сишный лэйаут, потому что "системщики" на этот глубоко системный аспект вообще поклали и вместо этого - "автоматически сделает збс" именно там где это как раз смерти подобно? :)
Вообще, Си, и не только он, могут оптимизировать структуры.
Но это не всегда уместно, когда то они должны располагаться в памяти жестко.
Поля тоже можно перетасовать, но подобное еще менее вероятно что понадобится.Допустим, перетасовало поля структуры "для лучшего layout"...
А а куда, кроме как в мусорную корзину, можно передать такую структуру, неизвестного формата, не соответствующую ни исходнику, ни документации? :)
А в OS большинство структур передаются из компонента в компонент, или на сторону пользователя.
> Допустим, перетасовало поля структуры "для лучшего layout"...
> А а куда, кроме как в мусорную корзину, можно передать такую структуру,
> неизвестного формата, не соответствующую ни исходнику, ни документации? :)
> А в OS большинство структур передаются из компонента в компонент, или на
> сторону пользователя.Если тебе важен layout для передачи кому-то ещё - укажи это явно, #[repr(C)], и тогда layout структуры в Rust будет совпадать с аналогичным описанием на языке C.
Однако это совсем не важно для внутренних структур, и структур которые шарятся только с Rust кодом
> Если тебе важен layout для передачи кому-то ещё - укажи это явно, #[repr(C)],И тут хипстики-хрустики не смогли шагу ступить без дидов - которые сделали ЭТО намного менее тупо. Даже при всех своих shortcomings.
И как там насчет гарантий safety такого кода при анализе?
> И как там насчет гарантий safety такого кода при анализе?А как расположение структуры в памяти влияет на анализ?
Не тупи.
>> не важно для внутренних структур,Когда не важно, то проблем нет, и делать можно как угодно
Но, большинство структур в ядре и важны, и требуют взаимодействия.
>> структур которые шарятся только с Rust кодомА вот здесь грабли,даже если код только на Rust ваять.
Когда собираете что то сложнее helloword, большое, и не пересобираете все целиком, то начнутся проблемы. В общем, фича только для очень локальных данных.
> Однако это совсем не важно для внутренних структур, и структур которые шарятся
> только с Rust кодомА если у меня допустим бутлоадер и основной фирмвар, и они собраны разными версиями в разное время - там не будет случайно бада-бум из-за не совпадений даже если оба и на Rust?
Просто видите ли бутлоадер перешивают только в крайних случаях дабы уменьшить риск кирпича, а фирмвар - чаще. Но видимо о таких моментах "системщики" не в курсе. А вот диды почему-то догадались...
> А если у меня допустим бутлоадер и основной фирмвар, и они собраны
> разными версиями в разное время - там не будет случайно бада-бум
> из-за не совпадений даже если оба и на Rust?Если тебе надо чтобы структуры совпадали между пакетами собранными разными версиями компилятора - помечай их repr(C), всё ж просто
Тебе же в любом случае нужно как-то стабилизировать подобные интерфейсы, даже в сях ты не сможешь так просто поле добавить/удалить в структуру что используется с обеих сторон
> Если тебе надо чтобы структуры совпадали между пакетами собранными разными версиями
> компилятора - помечай их repr(C), всё ж простоА, ну то-есть без "кала" от дидов сами по себе хипстеры вообще ни шагу. Потому что именно сами нагамнякали шляпу где такое - вообще никак, и пришлось идти к дидам на поклон за мудростью. У Rust вообще какие-то модели памяти и ABI - существуют?
> Тебе же в любом случае нужно как-то стабилизировать подобные интерфейсы, даже в
> сях ты не сможешь так просто поле добавить/удалить в структуру что
> используется с обеих сторон1) Ну вообще, при остром желании, это можно и сделать на самом деле.
2) Но лучше не надо. Жизнь намного проще если ABI в пределах лайфтайма системы фиксирован.И вон то понимаю не только я но и транснациональные корпы размером с RHBM. Знаешь что они сделают с работником за слом ABI? Он потом даже полы в макдаке мыть не сможет.
> У Rust вообще какие-то модели памяти и ABI - существуют?Своего стабильного ABI нет, зачем оно. Сишное выполняет две функции - взаимодействие с си, и стабильное аби если надо где-то ещё.
Смысла превращать все структуры в публичное апи нет, а значит и стабильное ABI для этого не надо.
А преимущества у нестабильного ABI есть, и хорошие, компилятор способен не только оптимально ужать их, но и там есть некоторые специфичные оптимизации для atomic для некоторых архитектур и прочего.
Ну и не стоит забывать что в Rust есть генерики, которые генерируют много внутренних мономорфизированных структур, к которым точно никто прикасаться не будет, и им подобные оптимизации особо полезны. В плюсах для такого жуткие костыли применяют.
> структуры в памяти лежат в таком же порядке как в коде описаныДавно не правда. Даже в паскале есть reordered.
> Давно не правда. Даже в паскале есть reordered.В паскале структуры логические, для программиста, а в сях по стандарту "физические", для того чтобы можно было описать память ровно так как её видит устройство
И стандартного способа автоматически переупорядочить поля там нет, есть только расширения компилятора, которые мало где используют
> логические, для программиста, а в сях по стандарту "физические"Начались сказки от "специалистов"...
> в сях по стандарту "физические", для того чтобы можно
> было описать память ровно так как её видит устройствоУпаси господь! По стандарту, если устройство там что-то там видит, то программист имеет право смотреть на это только побайтово через char*, а не через структуру. Иначе он нарушит TBAA или время жизни объекта* или в рамках стандарта не получит достаточных гарантий по layout'у. Alignas добавили через 20 лет после выхода C89.
А если всё же - то это вопреки стандарту, а не по.
Сам комитет акценты так расставляет:
"many properties of bit-fields are implementation dependent anyway"
и "The layout of structures is determined only to a limited extent"* Вон, по сишному стандарту malloc делает магию, которую запрещено повторять вручную в рамках стандарта. А в плюсах malloc создавал UB до C++20. https://stackoverflow.com/q/63379066
"Физические" в кавычках потому что оно такое только для абстрактной машины си и железа 30летней давности. Факт в том что порядок полей в коде по стандарту должен соответствовать порядку полей в памяти. Понятное дело что всякие randstruct и прочие расширения существуют, но подобные расширения как обычно со стандартом несовместимы (Абстрактная машина сей до сих пор однопоточная, или таки что-то уже успели с этим сделать?)Короче настолько же физическое как и UB при переполнении потому что числа в си не two's complement.
> * Вон, по сишному стандарту malloc делает магию, которую запрещено повторять вручную
> в рамках стандарта. А в плюсах malloc создавал UB до C++20.
> https://stackoverflow.com/q/63379066Это прикол такой? Или вы всех за идиотов считаете, которые ссыль не кликнут? Там ни 1 акцептованого ответа нет.
Тише, эджи бой.Автор вопроса усомнился в описании крупного бага в стандарте и получил два заплюсованных ответа, опровергающих сомнения.
Одобрить может только автор вопроса и только один ответ - ты не разобрался, как SO работает. Но автор не обязан и не появлялся в комментариях. Надо специально пинать, чтобы так не пропадали.
Предложение пережило 7 версий и было принято в C++20. Есть пошло оно из багтрекера стандарта в 2016, где был core defect, признающий "status quo that malloc alone is not sufficient to create an object" - был нужен placement new даже для plain-old типов.
Баг заткнули криво, но ожидаемо - чем меньше у программиста контроля, тем крепче мифическая "power of scalar type-based alias analysis".
Предложение началось с "I'm not suggesting that malloc should magically create objects" (P0593R0).
Но уже в R1 автора поправили, что malloc всегда был магией.
> Упаси господь! По стандарту, если устройство там что-то там видит, то программист
> имеет право смотреть на это только побайтово через char*, а не
> через структуру.Это кто тебе сказал? Расскажи это такому гранду как ARM в такой мелочи как CMSIS.
И спеки ты тоже не читал, иначе знал бы что char вообще не обязан быть байтом.
> Иначе он нарушит TBAA или время жизни объекта*
Какое еще нахрен время жизни объекта? Типы данных сами по себе ортогональны времени жизни и способам аллокации, если горе-системщику такое не рассказали. Зато надуть щеки с умным видом - пожалуйста. Сразу видно крутого профи.
> А если всё же - то это вопреки стандарту, а не по.
Таки, да, иногда - за стандарт приходится выезжать. То ли дело вон те господа где выезжать не за что, чисто технически.
> и "The layout of structures is determined only to a limited extent"
А у вон тех он вообще никак не determined, компилер может что угодно, PROBLEM SOLVED! Или нет? А, вот вам полдюжины лэйаутов еще. Сейчас посмотрим как вы там безопасТно прострелите себе пятку. Предварительно смазав место входа стрелы спиртом, чтоб зараза не попала.
> * Вон, по сишному стандарту malloc делает магию, которую запрещено повторять вручную
> в рамках стандарта. А в плюсах malloc создавал UB до C++20.
> https://stackoverflow.com/q/63379066Круто - запастить ссыль на какой-то левак, без единого принятого решения. Просто топ экспертизы опеннета.
> спеки ты тоже не читал
> иначе знал бы что char вообще не обязан быть байтом.
> Просто топ экспертизы опеннета....
"Character - a single byte representing..."
Лучше скажи, зачем ты отвечаешь, не читая соседний комментарий, там уже были ответы. И что получится, если в "Аноним (249)" две цифры переставить?..
>> По стандарту, если устройство...
> Расскажи это такому гранду как ARM ... Таки, да, иногда - за стандарт приходится выезжать....
Да просто пишите вы уже на языке каком хотите, а не топите за него, троллота.
Пофиг о чем речь ц или раст.
Ваша проблема в том, что вы концентрируетесь на вопросах, а надо на ответах.
>Из ядра удалён код файловой системы BcachefsГлючная ^W эспериментальная ФС по дефолту теперь насквозь редхатовская btrfs. Её не выкинут. Даже если разработчик будет хоть сам чёрт во плоти.
Редхат-то как раз, вроде бы, ее уже выкинул.
> удаление BcachefsКто знает, подскажите, где теперь патчи брать？Можно ли использовать ветку от Кена?
Там же надо dkms модуль подтягивать и самому накатывать. Ядро вроде патчить не надо, не?
Кто-то реально использует такие глубокие демки в проде?
Или так много времени возиться с этим?
https://bcachefs.org/
Сайт крутых.
17 становится LTS же?
12+6=17?
так, а какого фига proxmox на 17 переехал?
Ориентироваться в стабильных версиях ядра на основе использования версии ядра сторонним проектом - это очень креативно.
Как правило, последний релиз за год становится lts. Итого это будет 6.18, до конца года 6.19 никак не зарелизят.Почему проксмокс переехал на 6.17 - им виднее, в дебиане на данный момент либо 6.12 как стабильный, либо 6.17 как бэкпорт/тестинг. 6.18 станет лтс и попадет в бэкпорт, на него переехать с 6.17 менее проблемно, чем с 6.12.
В Debian 13 потом и 6.19 попадет в бэкпорт, и 6.20, ...
Скорее всего, финальным в trixie-backports будет 7.x.Оно так работает, просто потому что пока testing не заморожен и пока в него принимают новые версии пакетов, они будут перекочевывать и в backports stable.
Де-факто ядро в testing фризят в декабре года, который предшествует релизу, даже, если stable не заморожен (следующий LTS уже 100% не попадет, а откатывать linux-image-* - глупая затея).
Помню тут пару дней назад в комментах радостно рассказывали, что раст уже забросили в ядре, мейнтейнеры ушли и прочее.
Не имеет значения, когда именно ржу выбросят. Просто сам факт мёртворождённого изычка не даёт ему никаких шансов. Как только гугля решит оптимизировать дармоедов, ВНЕЗАПНО окажется, что "раст оказался непригоден" и далее шлейф обещаний что завтра будет лучше, чем вчера, но деньги, про_с_раные на ржу, никто уже не вернёт.
Вот это уровень копиума.
"Этот драйвер не имел стратегического значения"
Ну так пока они про все свое в ядре так говорят.У них пока все "тактическое". Тестируют, короче.
Разрешить добавлять драйвера на расте жест доброй воли со стороны С разработчиков.
С разморозкой!
Си разработчиков не спрашивают, а информируют по факту.
Несогласных уходят.
> Си разработчиков не спрашивают, а информируют по факту.Ну так норм.
В проекте уже есть Великодушный Диктатор.
Он благодушно спрашивает "как лучше сделать", а получает в ответ хамство (публикацию частной переписки) и некоструктивное "No rust code in kernel/dma, please".> Несогласных уходят.
А ты бы терпел сотрудника который нарушает субординацию?
Торвальдс вроде человеческим языком (и почти без ругательств) пояснил, что
"... никто не заставляет мэйнтейнеров изучать язык Rust, использовать код на Rust или принимать во внимание наличие в ядре кода на Rust.
Но подобные сопровождающие не могут и влиять на то, как развивается Rust в ядре, например, не могут вмешиваться в организацию внешнего взаимодействия Rust-кода с кодом их подсистемы."https://lore.kernel.org/lkml/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_.../
Т.е он разграничил зоны ответственности и указал зарвавшимся вахтерам где их место.
Вы тролль. Там не нарушение субординации, нарушила субординацию именно корпоративная подстилка, эскалировавшая до Торвальдса через головы его лейтенантов.
> Вы тролль."Аргументировано" и бездоказательно, впрочем я не удивлен.
> Там не нарушение субординации, нарушила субординацию именно корпоративная подстилка, эскалировавшая до Торвальдса через головы его лейтенантов.
Если мейнтенер борзеет, если он начинает лезть в то, где прав у него нету, а именно в "где будет использоваться раст код" то это как раз нарушение субординации и вахтерсво.
На что ему указали.Жаль у него хватило мозгов уйти самому.
> если он начинает лезть в то, где прав у него нетуА вот знания и опыт работы с новыми "плюшками" уже был. Когда те, кто внедрял плюшки, тормозили работы. На что он, справедливо, и указывал.
> А вот знания и опыт работы с новыми "плюшками" уже был.У него был какой-то опыт программрования на расте.
Но единичный личныйопыт мало что значит.
Может он просто был неосилятором.> Когда те, кто внедрял плюшки, тормозили работы.
Звучит как "вы зачем дорогу на ремонт перекрыли??? я сейчас в пробке стою!"
> На что он, справедливо, и указывал.
Указывать он имеет полное право.
А вот блокировать патчи - нет.Вот что писал Торвальдс:
You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it.
But "ignore the Rust side" automatically also means that you don't have any *say* on the Rust side.
Т.е если тебе не нравится раст, то не принимай в свой код! Но при этом не раззевай варешку на чужой.So let me be very clear: if you as a maintainer feel that you control
who or what can use your code, YOU ARE WRONG.
В общем превышение полномочий и (само)выкидывание из ядра.https://lore.kernel.org/lkml/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_.../
> У него был какой-то опыт программрования на расте.У него был опыт, когда разработчики rust тормозили принятие патчей.
То есть из-за них система за которую он отвечал к релизу была с проблемами.
> В NTFS3 добавленаЭтот тот что от Paragon? Кто владеет вопросом, подскажите, что происходит с этим драйвером. Есть ещё NTFSPLUS если не ошибаюсь
Да, от Paragon. У меня работает, не ловил корраптов, но репорты от других пользователей были. Второй вариант ntfs-3g через FUSE, сильно медленнее.
Кривое оно, до сих пор. Из-под линукса лучше ничего не записывать на ntfs.
Не монтирует /dev/sdb1. В прошлом декабре монтировало. Терплю ntfs-3g. Тормоз и память жрёт.
Ржавеет по-тихоньку.А что для конечного пользователям может пригодиться?
Возможно драйвера?
> драйвера Nova для GPU NVIDIA.
> драйвер TyrДумаю без них для "конечного пользователя" будет весьма грустно.
> реализация Binder, написанная на языке Rust.
А это сотни миллионов пользователей.
> без них для "конечного пользователя" будет весьма грустноЧитаем: "Драйвер пока не готов"
> Читаем: "Драйвер пока не готов"А ядро уже готово))?
Чего они всё новые и новые версии выпускают.Биндер написали и этот напишут.
Биндер не писали, а переписывали.
> Биндер не писали, а переписывали.Так если дрова для gpu напишут, а не перепишут, то вы первые ныть будете что нет поддержки старого мусора)))
Вы как-то определитесь что вам нужно, а потом уже набрасывайте.
вот если на расте что-нибудь напишут, а не перепишут, тогда и поговорим
п-ф-ф-ф-ф
типа на С что-то написли, а не переписали с асемблера или с фортрана какого
да тот же gcc написали на паскале и только потом перерисали 🤡🤡🤡
> типа на С что-то написли, а не переписали с асемблера или с фортрана какогоСИ был создан для ПЕРЕПИСЫВАНИЯ юникса с ассемблера.
> да тот же gcc написали на паскале и только потом перерисали
Дополню что паскаль был "волосатым".
Незнаю что это значит, но после крайних каминаутов столлмана даже боюсь уточнять
> СИ был создан для ПЕРЕПИСЫВАНИЯ юникса с ассемблера.Вот только
1. переписывая на Си - делали общий код для разных архитектур.
2. переписывая на rust - делают свой код под каждую архитектуру.Концептуально: rust - это шаг назад.
Во-первых, не на паскале, а на Pastel'е
Во-вторых, когда Столлман понял, что получившийся компилятор жрет мегабайты стека, он написал его с нуля сразу на Си.
> Биндер не писали, а переписывали.Так если дрова для gpu напишут, а не перепишут, то вы первые ныть будете что нет поддержки старого мусора)))
Вы как-то определитесь что вам нужно, а потом уже набрасывайте.
> Биндер не писали, а переписывали.И? Это как то меняет факт, что овняный и бажный код на дыряшке заменили на новый код на хрусте?
Который не только архитектурно лучше, но даже занимает меньше строк.ps когда то давно, UNIX переписывали, именно ПЕРЕПИСЫВАЛИ, с ассемблера на СИ.
Инетересно, тогда такие же де---ы тоже куракекали "не написали, а переписали" ?
ядро уже почти 25 лет как готово... если бы не было готово, ты бы просто не смог читать опеннет - весь этот ваш интернет на этом "не готово" работает
> ядро уже почти 25 лет как готово...Так зачем новые версии выпускают?
Им делать нечего?> если бы не было готово, ты бы просто не смог читать опеннет - весь этот ваш интернет на этом "не готово" работает
А... точно! До 91 года интернетов не было! Люди общались черезголубиную почту!
Вот как Торвальдс ядро сделал, так сразу появился!
Представьте себе, когда новые железки появляются, для них нужны новые дрова;)
Ну ты новость-то почитай и сам прикнь сколько там про новые дрова, сколько про новые функции, сколько про оптимизации. Работа над ядром будет закончена не раньше, чем будет закончена эпоха информационных технологий. А до тех пор оно будет меняться вне зависимости от нытья балласта.
> Возможно драйвера?
> > драйвера Nova для GPU NVIDIA.
> > драйвер Tyr
> Думаю без них для "конечного пользователя" будет весьма грустно.невидия и Mali на линуксе это само по себе смешно, даже без растоскама
для конечного, а не конченого
Проясните плз про boot_display, с целью повышения уровня образованности. Не понятно, в каком формате его указывать?
Там в начале патча есть описание. Сложно прочитать пару строк?
>> Добавлена поддержка ARM-плат, SoC и устройств:а где RISC-V ? (((
Зачем оно вам? Там все равно без блоблов не взлетит.
блобов бояться - в лес не ходить.
а сейчас нет, скажем, ноутов на полностью (кроме вафли и блютуза, изолированных от цпу) свободном софте?
RISC-V не взлетел; останется навсегда академической разработкой для исследователей (типа как OpenBSD).
> RISC-V не взлетел; останется навсегда академической разработкой для
> исследователей (типа как OpenBSD).Надо рассказать это Nvidia с ее триллионами и прочим Western Digital которые процы делают - поболее чем вы живете, чего доброго. Да и AMD вроде в видяхи их встроил. А что у них общего? Используют RISCV!
А у imagination RISCV настолько не взлетел что они MIPS свернули в пользу RISCV, с чем выпиливание MIPS из дистров и связано. Зато RISCV как раз - запиливают на ура.
кажный может себе позворить риска - на алике ESP за 100 рублей :)
> кажный может себе позворить риска - на алике ESP за 100 рублей :)Да так то CH32V в разы дешевле. Стоит буквально 10 центов на минималках. Но не что вы, RISCV не победил, его нет, это скам. Правда те миллионы юнитов не в курсе и просто захватывают мир.
Да что MIPS, что RISC-V - всё одно Давид Паттерсон.
ага. а 25% сожрали... чиста случайно...
> а где RISC-V ? (((В смысле? Там только недавно поддержку чего-то нового от SiFive запилили.
а обещали SpacemiT X60
пошли работу над ошибками делать
Ядро - это в принципе независимый проект, в нём не может быть "возможность писать на раст", как и "возможность похапэшных вставок" - это просто глупо и узконаправлено. Либо ты можешь писать для ядра (Си, Ди, ассемблер), либо ты идёшь в сад писать опердни - в ядре тебе делать нечего.
> Либо ты можешь писать для ядра (Си, Ди, ассемблер),Ога, на Ди, на с++)))
Ты просто пишешь для ядра на расте, а те кому не нравится, спорят с Торвальдсом и потом или закрывают варешку, или идут в сад писать опердни - в ядре таким делать нечего.
> Ядро - это в принципе независимый проектДа, ты прав! Принципиально не зависит от тебя и твоих хотелок.
> PSP (гибрид TLS и IPsec)А это как?
> В состав принята реализация механизма межпроцессного взаимодействия Binder, написанная на языке Rust. Binder используется в Android для организации взаимодействия между процессами и удалённого вызова методов (один процесс Android может вызвать метод или функцию в другом процессе Android, используя Binder для идентификации, вызова и передачи аргументов между процессами). Код Binder был переписан на языке Rust в рамках инициативы Google по усилению защищённости Android.Собака лает, караван идёт.
Самокритичненько
он имел ввиду, что маркетологи раста там что-то где-то кричат, но инженерам на это до лампочки
Мда... Дно дна. То что должно работать в пространстве пользователя в ядро запихнули.
Грабить корован уже можно? Есть чем поживиться?
Где то во второй декаде декабря Фряха 15 зарелизится,вот это полезная новость. Тут же сплошной бета тест. Версия 6.12-6.14 максимум в серьезных дистрах и те для фанатиков не различающмх что такое хорошо и плохо.
Какой второй декаде? Релиз завтра.
Серьезно?Норм,а то помню читал вроде как 21 декабря.
21 декабря это уже как бы третья декада.
Буду знать.
> Фряха 15 зарелизится,вот это полезная новость.Как у тебя в одном предложении сочитаются "фряха" и "полезность"?!
ФРЯ это бесполезная поделка нудность которой можно оценить по ее распространености.
Просто это не для тебя. Вам вот - 6.18 вывалилили.
как минимум иметь альтернативу линуксу с его назревающим вендор-локом на раст - полезносам лично свалю туда, если для сборки ядра понадобится llvm
А то что для сборки фри нужен llvm тебя не смущает? Или это юмор которого я не понял?
Перед ответом лучше проверить ник. Тогда все станет ясно.
Во FreeBSD llvm/clang - это системный компилятор на amd64
> Где то во второй декаде декабря Фряха 15 зарелизится,вот это полезная новость.Что в этой шляпе полезного то? LTS нету, бинарные пакеты на вторых ролях, так что на серваки для просто эксплуатации без заморочек ставить - мазохизм. А по другому эксплуатировать компьютерные системы уже никто и не хочет - их слишком дофига развелось чтоб над каждым локалхостом танцевать.
Каждый и танцует,мне нравится. Пакеты и для 13 фряхи есть,а она 4 года как вышла.
> Каждый и танцует,мне нравится. Пакеты и для 13 фряхи есть,а она 4
> года как вышла.Вышла и оперативно чинят вулны в пакетах - две большие разницы. Какая-нибудь убунта даст жесточайший мастеркласс фряхе по сроку поддержки. Да даже Debian даст, хоть и на минмалках.
>> Началась работа по реорганизации излишне раздутой структуры "page", используемой для управления страницами оперативной памяти. Добавлен тип 'memdesc_flags_t"Как-то противоречиво звучит
Кто разбирается в BPF? Оно заметно замедляет работу ядра?
scx_bpfland поставь, да проверю. Спойлер: ОС станет более отзывчивой.
Не, я понял, что BPF - крутая штука, но рассуждая по дилетански: вот есть ядро, работает, тут в него влезает ещё один процесс (или даже не один), что-то дополнительно анализирует и по итогу что-то дополнительно делает, тут ещё проверка подписи, а если ещё и в пространство пользователя "нырнёт" и не раз... Ещё и отдельный механизм, позволяющий всё это.
Ресурсы, ресурсы, ресурсы, которые всегда ограничены.P.S. Планировщик дефолтный, ибо не считаю, что у меня достаточно понимания, чтобы выбрать другой. Хотя его и достаточно, чтобы знать, что можно добиться профита в конкретных условиях.
В ядре тоже треды есть, почему ты думаешь, что оно все синхронно работает? Конечно, ресурсы ограничены твоим ЦП. Но я не видел никаких репортов про снижение перформанса.Крайне рекомендую попробовать любой планировщик на BPF, разница видна почти в любой нагрузке.
> В ядре тоже треды естьВот именно, а тут ещё.
> почему ты думаешь, что оно все синхронно работает?
Не думал, но CPU не резиновый и кто-то встанет в очередь, а тут ещё один тред.
> Но я не видел никаких репортов про снижение перформанса.
Спасибо, пару раз ради любопытства гуглил - многовато мусора в выдаче, ничего в целом внятного.
> Крайне рекомендую попробовать любой планировщик на BPF
Попадвшиеся сравнения планировщиков не сказать, что исчерпывающие, перспективы невнятные, поэтому ещё несколько лет назад решил не лезть в эту тему без нужды.
P.S. Кто-то меня минусанул, молодой, видимо, горячий, или лентяй - не хочет нести свет просвещения :))
> В ksmbd (работающий на уровне ядра SMB-сервер) добавлен параметр для ограничения максимального числа соединений с одного IP-адреса. smbdirect, smbclient и smbserver переведены на использование типовых структур ядра.Всегда было интересно, а вот это вот вообще зачем в ядре? Почему именно SMB, а не SSH, например?..
Выглядит как идеальный вектор атаки.
nfs тоже в ядре, это тебе не интересно почему ?!
вопрос был про вечно дырявую самбу, причём местами - на уровне спецификации протокола.
что nfs дырявый, что самба
https://www.cve.org/CVERecord/SearchResults?query=NFSв локалке мне это не мешает
Чтобы rootfs грузить по сети? Очень удобно для экспериментов.
скорость работы, там прирост процентов в 30 по производительности
> прирост процентов в 30Это быстро исправят переписыванием на раст.
Почитал уже. RDMA выглядит как *совсем* плохая идея.
> Почитал уже. RDMA выглядит как *совсем* плохая идея.Абсолютно. Но если у тебя весь ДЦ забит _твоими_ серверами и более ничем - пуркуа б да не па?
А потом кто-то заказывает внутренний пентест... в лучшем случае.
И что? Проход в дейта-центры давно уже строго по биометрии. Нарушитель, конечно, сможет вмешаться в тренировку моделей. И посидеть за это в тюрячке. Пентестер ... ну так пентестер с доступом к железу в дейтацентре - это далеко не модель угроз для нарушителя. Если есть физическийи доступ к железу, то можно это железо с флешки загрузить и поставить крипту майнить.
> И что? Проход в дейта-центры давно уже строго по биометрии. Нарушитель, конечно, сможет вмешаться в тренировку моделей.Это если не тот нарушитель. А если тот, что надо. Тогда ничего не будет. И результаты никак не проверить. Имея результат - никак не понять, вмешивался ли, кто либо.
С обычным кодом все совсем не так.
> Но если у тебя весь ДЦ забит _твоими_ серверами и более ничемВ природе так не бывает. Но никто не мешает разрулить это на уровне сети, что все успешно и делают. А так, NVMEoF на замену уже сделали.
> В природе так не бывает.Надо рассказать это гуглу и мордокниге, сразу после дачи лекции Безосу из амазона...
> Всегда было интересно, а вот это вот вообще зачем в ядре?для производительности, очевидно
> Выглядит как идеальный вектор атаки.
так вам не нужно — не используйте, пока модуль не загружен никакого «вектора атаки» нет
> В состав принята реализация Binder, написанная на языке Rust.
> Продолжена интеграция компонентов драйвера Nova для GPU NVIDIA.
> В состав ядра принят драйвер Tyr, написанный на языке RustХехе, а ведь неплохо получается))
Ждем набега хейтерочков с завываниями "пачиму растаманы не сделают свое ядро! зачим вы портите НАШ линyкc?!" Так вот, он нифига не ваш))
Лучше начинайте рассказывать про то, что язык мертворожденный, что драйвера экспериментальные, что это опциональная зависимость, что вот-вот и его удалят из ядра (на удаляют почему-то Bcachefs).
Я обожаю слушать такой копиум! Это как про вейланд, только еще веселее))
> В выпуске 6.18 обновлён код чистки blob-ов в драйверах Nova-Core, Intel XE, TI PRUeth, Lantiq GSWIP, Marvell WiFi-Ex. Выполнена чистка имён blob-ов в dts-файлах (devicetree) для ARM-чипов Qualcomm, Mediatek и TI ARM64. Нейтрализована загрузка blob-ов в новых драйверах FourSemi fs2104/5s, TI TAS2783 и Qualcomm GENI.Офигеть...
А оно хоть как-то запускается после такого?
Или "нам главное чистота крови", а работает или нет - это значения не имеет?
Как-то же они в интернет запостили это, должно быть что-то да работает.
Нет, конечно. Оно и не для запуска делается...
А продемонстрировать делом, что никакой линиукс не свободный, ибо на деле завист от блобов. Чтобы когда кто-то начнёт вякать про то, что линукс - СПО - предложить ему продемонстрировать работающий сабж на своём ПК.
> А продемонстрировать делом, что никакой линиукс не свободный, ибо на деле завист
> от блобов. Чтобы когда кто-то начнёт вякать про то, что линукс
> - СПО - предложить ему продемонстрировать работающий сабж на своём ПК.1) Перфекционизм это прекрасно, но где ваши решения лучше? Таки постепенно двигаться к цели, поднимаясь по лестнице работает лучше чем одним прыжком заскочить в окно пятого этажа.
2) У лично меня есть blob-free системы на ARM. Им доверия куда больше чем x86 мути, так то. Поэтому на них вынесены самые критичные вещи.
>включена поддержка SR-IOV
> Добавлен параметр ядра "boot_display" для выбора устройства вывода для отображения процесса загрузки на системах с несколькими GPU.хорошо!
но лучше бы это в uefi можно было выбирать везде
фолс аларм!
это никакой не параметр, а просто информация
позор!
> фолс аларм!
> это никакой не параметр, а просто информацияОткуда таеие лезут? В многих EFI и BIOS есть выбор init gpu 1st или как там его называют. Линух даже подхватывает сие.
> позор!
Облажался - обтекай.
> В состав принята реализация механизма межпроцессного взаимодействия Binder, написанная на языке Rust. Binder используется в Android для организации взаимодействия между процессами и удалённого вызова методов (один процесс Android может вызвать метод или функцию в другом процессе Android, используя Binder для идентификации, вызова и передачи аргументов между процессами). Код Binder был переписан на языке Rust в рамках инициативы Google по усилению защищённости Android.Вот это очень плохо на самом деле. Не потому что раст а потому что та еще дыра. Кому интересно погуглите к чему привело появление CreateRemoteThread в винде.
> Вот это очень плохо на самом деле. Не потому что раст а потому что та еще дыра. Кому интересно погуглите к чему привело появление CreateRemoteThread в винде.Хм, так биндер ЕМНИП в вндроиде с самого начала, где-то с 2007-2008 года.
Да и кроме него в ведре хватает дыр, не думаю что он сильно повлияет на общую статистику.
> Вот это очень плохо на самом деле. Не потому что раст а потому что та еще дыра.
> Кому интересно погуглите к чему привело появление CreateRemoteThread в винде.Он и до этого там был - просто на сях. В десктопных дистро не включен как правило - ибо ничем кроме андроида Binder IPC не используется. Так что binder нужен по сути только гуглу.
> Так что binder нужен по сути только гуглу.И еще всего лишь 3.9 млрд. пользователей андроида.
Мелочь такая, то ли дело десктопный линукс!
> И еще всего лишь 3.9 млрд. пользователей андроида.
> Мелочь такая, то ли дело десктопный линукс!В этой шляпе еще более 9000 всяких бэкдоров, телеметрий, улучшений качств обслуживания и проч. Чан г@вна какашкой не испортишь.
И так то - секурити в ведре выше среднего. Потому что программы там, извиинте, откровенно проститутские по своему поведению. И без закрутки гаек там вообще был бы полный капец.
И для waydroid ещё, конечно.
ну запуск андроид софта не только гуглу нужен. Особенно если десктопный андроид будут активно развивать и будет больше софта.
Но binder это не create remote thread, а более низкоуровневый аналог dbus.
В xe поддержка VAAPI поломана
Сейчас Линус возьмётся за это, он собрал себе новый комп с B580:
https://videocardz.com/newz/linus-torvalds-picks-intel-arc-b...
> В xe поддержка VAAPI поломанаИнтел такой интел. Сломал поддержку своего апи в своих видяхах :). Норм дополнение к процам горящим за полгода вышло.
> В NTFS3 добавлена поддержка ioctl FS_IOC_GETFSLABEL и FS_IOC_SETFSLABEL для чтения и установки меток разделов.NTFS3 могут выкинуть, так как у меня на компе с /dev/sdb1 он не работает.
> Минимальная версия компилятора Clang, которым может быть собрано ядро, повышена до инструментария LLVM 15. В Debian 12 и Ubuntu 22.04 поставляется LLVM 14.Вот пошла гонка за версиями. С растом будет еще хуже.
> Ubuntu 22.04Ей как бы уже три года.
Если вы на нее собираетесь ставить НОВЕЙШЕЕ ядро, то почему бы шланг не обновить? Или вообще обновиться до следующей LTS? В 24.04 по умолчанию clang 18 и можно обновиться до 19.А если вы НЕ можете обновиться до 24.04 по внешним причинам, то как вы ядро собрались обновлять?))
> Debian 12
А на этот тухляк вообще смотреть нет смысла.
> А если вы НЕ можете обновиться до 24.04 по внешним причинам, то как вы ядро собрались обновлять?))Там snap. Он на ведро не влияет от слова совсем.
> Минимальная версия компилятора Clang, которым может быть собрано ядро, повышена до инструментария LLVM 15.Ну так славно!
При переходе с 14 на 15 версию было куча исправлений и улучшений.
releases.llvm.org/15.0.0/docs/ReleaseNotes.html#changes-to-the-c-api> В Debian 12 и Ubuntu 22.04 поставляется LLVM 14.
Дебиан это просто тухлятина, ему можно.
В бубунте можно использовать старое ядро.
Нужно новое? Используйте 24.04 LTS (там 18)> Вот пошла гонка за версиями.
А это плохо?
Зачем брать во внимание луддитов которые хотят сидет нанекрософте?> С растом будет еще хуже.
Но пока - лучше)
Где C++ и Rust там всегда конские размеры исходников и долгая компиляция.А Rust надо выкидывать из ядра. Пусть пилят свой Redox и к нам не лезут.
> Где C++ и Rust там всегда конские размеры исходников и долгая компиляция.Бред. Уже опровергали и не раз.
> А Rust надо выкидывать из ядра. Пусть пилят свой Redox и к нам не лезут.
А вы это кто?
Разработчики из kernel team?
Создатели ядра?
Может корпы, которые весь банкет оплачивают?Нет? Вот тогда закройте хлеборезку.
Забавно слушать как кучка 6omжей из сообщества™ что-то так потявкивает.
Что-то не нравится - кнопочка форк воооон там. Берите пример с латиносов и пилите свое обезржавленное ядро.
Чтобы это было не так, придётся приложить определённые усилия, и, скажем прямо, это будут уже не c++ и rust. Исходники конечно ерунда, вот генерируемый файлы не ерунда -- именно они замедляют компиляцию, потом их линковка только часами.
Своодное Сообщество создано GNU/Linux. На их плечах всё держится. Корпорасты примазались - они не основа.
Без корпорастов линукс так и остался бы хобби-проектом. Эти ваши корпорасты 90% кода линукса написали. Вся инфраструктура линукса на плечах корпорастов держится, даже десктопная его часть. Именно поэтому с десптоком хуже чем с серверной частью, это не приоритет корпов. Сообщество не справляется.
>Бред. Уже опровергали и не раз.На базаре бабки опровергали...??? Смотри на факты, весь "переписанный" ржавый софт на сегодня свидетельствует о твоей неправоте....
Над бтрфс действительно хорошо поработали, производительность теперь не хуже чем у ext4, даже если активно виртуалка работает.
>безопасностьне "безопасность", а TEE-DRM-копирастия.
Безопасно как в смирительной рубакше.
> Код Bcachefs может быть возвращён в состав ядра после того как Кент Оверстрит на деле докажет возможность корректного взаимодействия с другими разработчиками ядра и способность следовать устоявшимся правилам разработки.Как Кент это покажет если они с ним больше не взаимодействуют?
Но он может сам вернуться.
> Как Кент это покажет если они с ним больше не взаимодействуют?Если СОВСЕМ не взаимодействовать - девелоп ФС станет заметно менее комфортным делом. Ибо не получится подкрутить апи под то что удобно вон там.
Такая опция - есть. Но требует не вести себя как полный отбитый м...к и понимать что вы не центр вселенной и есть интересы и аргументы 100500 других людей!
>возможность создания USB-драйверов на RustЭто что, драйвер на расте?
Кое что получше. Это возможность создавать драйвер на расте.
Чувак, драйвер для создания другого драйвера? До такого могли только растаманы додуматься.
>В MD RAID реализован новый тип битовых карт - llbitmap (lockless bitmap)Оно в существующих уже MD RAID заработает? или только в новых? или как то мигрировать нужно?
> включена поддержка SR-IOV PFАгонь, 2 года ждал пока запилят, наконец то случилось.