forum.opennet.ru - "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-разрядных систем ARM" (51)

"В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-разрядных систем ARM"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-разрядных систем ARM"	+/–
Сообщение от opennews (ok), 27-Апр-26, 23:10
В состав ядра Linux 7.1, релиз которого ожидается в середине июня, приняты изменения, добавляющие возможность использования режима реального времени (PREEMPT_RT) на 32-разрядных процессорах ARM. Ранее поддержка PREEMPT_RT была обеспечена для архитектур x86 и x86-64, ARM64, RISC-V и LoongArch... Подробнее: https://www.opennet.me/opennews/art.shtml?num=65302
Ответить \| Правка \| Cообщить модератору

Оглавление

А реалтайм вообще возможен в системе, где устройство может стать bus master ом и, Страдивариус (ok), 23:10 , 27-Апр-26, (1) +2

этого на arm32 нет и да - qos и приоритеты для мастеров настраиваются, Ы (?), 00:14 , 28-Апр-26, (3) +3
SMI можно отключить переключить на SCI , warlock (??), 00:25 , 28-Апр-26, (4)

На обычном писюке нельзя , Страдивариус (ok), 20:50 , 28-Апр-26, (29) +1

Что есть обычный писюк Вот например у отечественной ОС Нейтрино опция задок, warlock (??), 21:22 , 29-Апр-26, (47)

И какие чипсеты амудэ поддерживаются для этого Вот прям ВСЕ Это имхо очень вря, Аноним (-), 21:57 , 29-Апр-26, (48)

Вот ХЗ Может и не все С другой стороны переключатель SMI на SCI в любом ACPI е, warlock (??), 00:41 , 01-Май-26, (53)

Как вы интересно QNX Neutrino назвали , Doom (??), 10:04 , 30-Апр-26, (49)

QNX Neutrino и КПДА Нейтрино 8212 это разные ОС, хотя и родственные , warlock (??), 00:31 , 01-Май-26, (52)

Даже в этом моем STM32 микроконтроллер, надеюсь достаточно реалтаймно уже - е, Аноним (-), 01:59 , 28-Апр-26, (5) +6

Дело не в этом, а в том, что линь сам по себе слишком жирная штука чтобы быть с , Смузихлеб забывший пароль (?), 08:37 , 28-Апр-26, (16) +1

Поэтому для реального времени можно рассматривать только голое железо - baremeta, Сусанин (?), 18:36 , 28-Апр-26, (28)
Даже в обычном STM32 можно в ряде случаев заказать суммарные потоки данных по ши, Аноним (-), 21:21 , 28-Апр-26, (33)

Родной, а ты текст новости читал кроме заголовка Написано же тебе, что якобы эт, Страдивариус (ok), 20:52 , 28-Апр-26, (30)

Родной, я эту новость - написал Так что ты феерично поумничал - прямо на автора, Аноним (-), 21:51 , 28-Апр-26, (36)

Не поможет в общем случае Один девайс полез мастерить другой девайс, а в этот м, Страдивариус (ok), 20:56 , 28-Апр-26, (32)

Что - ква В общем случае проц как ядро вообще не обязан встать на паузу от этог, Аноним (-), 21:55 , 28-Апр-26, (37)

SMI, как бы, и QNX у помешать может , Аноним (23), 10:38 , 28-Апр-26, (23)

Может, поэтому что одной ОСью риал-тайм нельзя гарантировать - это комплекс аппа, Страдивариус (ok), 20:54 , 28-Апр-26, (31)

С той или иной степенью условности и допущений Ну скажем если у вас системная ф, Аноним (-), 22:47 , 28-Апр-26, (38)

А патчи на видеопамять не принимают от валва , Аноним (2), 23:29 , 27-Апр-26, (2) –2
Но 32-бита на x86 всё равно дропнут В отличиии от 32-битных альтернативных архи, Аноним (6), 02:12 , 28-Апр-26, (6)

Так 32-битные АРМы ещё явно много где используются, а быдло с атомами тольо и мо, Аноним (19), 09:55 , 28-Апр-26, (19) –3

Вы не много хотите от byd 322 a скота, в переводе на русский Предназначение , Аноним (43), 11:20 , 29-Апр-26, (43) –1

Лучше бы миррорс кернел орг починили, уже 6 дней как никаких обновлений по всем , Аноним (7), 02:15 , 28-Апр-26, (7) +2

Не всем https mirrors edge kernel org archlinux 27 Apr - вчера, а вот Debian , Аноним (8), 03:06 , 28-Апр-26, (8)

Теперь ясно, что случилось у них https social kernel org notice B3FpxSKAReX7S2, Аноним (8), 03:09 , 28-Апр-26, (9)

Цитата Should we start occasionally breaking mirrors kernel org so that people , Аноним (8), 03:14 , 28-Апр-26, (10)

Ясно Но что тогда использовать, может Apple MacOs или Windows 11 Эти давно под, Аноним (11), 07:17 , 28-Апр-26, (11)

Стоп, что Откуда такая информация , Аноним (13), 08:27 , 28-Апр-26, (13)

Зашёл браузером по адресу репозитория на дебиан орг, на https, меня редиректнуло, Аноним (17), 09:05 , 28-Апр-26, (17)

В дебиане пакеты не подписываются ключом мейнтейнера Подсовывай, какой хочешь, , Аноним (18), 09:42 , 28-Апр-26, (18)

радости тебе с этой подписи, если вместо пакета твой апт получит от твоего прова, Аноним (20), 10:09 , 28-Апр-26, (20)

Повод сменить провайдера , Аноним (18), 10:18 , 28-Апр-26, (22)

Даже если шарик сменить, взяв с собою только своих единомышленников, проблемы в , Аноним (24), 14:43 , 28-Апр-26, (24)
Не на что менять В тех е нях только один опсос, которого нагнули по разнарядке, Аноним (20), 21:38 , 28-Апр-26, (34)

Ну он и с TLS от тебя получит - ресет соединения или что там у главжандарма в тр, Аноним (-), 22:59 , 28-Апр-26, (39)

Вы бы хоть Интернет по теме почитали, там всё давно расписано, это очевидные вещ, Аноним (25), 15:00 , 28-Апр-26, (25)

Другим дистрибутивам не мешает А дистрибутиву, в котором будут голосовать до пр, Аноним (18), 15:22 , 28-Апр-26, (26)

Да, да, знаем То что Сноуден принёс - это тоже была конспирологическая теория , Аноним (27), 16:34 , 28-Апр-26, (27)

А вы не в браузере смотрите, а перехватите запросы apt, например через mitmproxy, Аноним (35), 21:39 , 28-Апр-26, (35)

А смысл Даже если они не делают это в конкретный момент для апта, то что они де, Аноним (40), 01:33 , 29-Апр-26, (40)

Т е тейк намеренно создающий условия для взлома aptа спецслужбами ложный Кста, Аноним (42), 06:53 , 29-Апр-26, (42)

curl -v https security debian org debian-security Host security debian org 44, Аноним (43), 11:29 , 29-Апр-26, (44)

curl -v https security debian org debian-security Внимание на последний символ, Аноним (45), 13:30 , 29-Апр-26, (45)
Кстати Ваш миррорс кернел починили , Аноним (46), 15:57 , 29-Апр-26, (46)
Спасибо за инфу Но по-хорошему ответы должны быть эквивалентны , Аноним (51), 15:50 , 30-Апр-26, (51)

А что теперь клоны редхат использовать , Аноним (14), 08:35 , 28-Апр-26, (14)

Кажись обновилось , Аноним (41), 04:07 , 29-Апр-26, (41)

Весьма хорошая новость , кукпоп (?), 07:38 , 28-Апр-26, (12)
В 7 2 armel из ядра вытрут , Аноним (50), 13:41 , 30-Апр-26, (50)

Сообщения [Сортировка по времени | RSS]

1. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +2 +/–

Сообщение от Страдивариус (ok), 27-Апр-26, 23:10

А реалтайм вообще возможен в системе, где устройство может стать bus master'ом и захватить шину на столько (а-ля PCI)? Или где в самый нужный и ответственный момент случается SMI и все такие: "Ой, пацаны, у нас тут минус первое кольцо, расходимся."

Ответить | Правка | Наверх | Cообщить модератору

3. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +3 +/–

Сообщение от Ы (?), 28-Апр-26, 00:14

этого на arm32 нет и да - qos и приоритеты для мастеров настраиваются

Ответить | Правка | Наверх | Cообщить модератору

4. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от warlock (??), 28-Апр-26, 00:25

SMI можно отключить (переключить на SCI).

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

29. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +1 +/–

Сообщение от Страдивариус (ok), 28-Апр-26, 20:50

> SMI можно отключить (переключить на SCI).
На обычном писюке нельзя.

Ответить | Правка | Наверх | Cообщить модератору

47. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от warlock (??), 29-Апр-26, 21:22

> На обычном писюке нельзя.
Что есть "обычный писюк"? Вот например у отечественной ОС "Нейтрино" опция задокументирована:
> Опции:
> -a
> Явное указание отключить использование SMI для систем на базе чипсетов AMD.
На базе чипсетов AMD — это "обычный писюк" или "необычный"?

Ответить | Правка | Наверх | Cообщить модератору

48. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (-), 29-Апр-26, 21:57

> На базе чипсетов AMD — это "обычный писюк" или "необычный"?
И какие чипсеты амудэ поддерживаются для этого? Вот прям ВСЕ? Это имхо очень врядли.

Ответить | Правка | Наверх | Cообщить модератору

53. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от warlock (??), 01-Май-26, 00:41

> И какие чипсеты амудэ поддерживаются для этого? Вот прям ВСЕ? Это имхо
> очень врядли.
Вот ХЗ. Может и не все. С другой стороны переключатель SMI на SCI в любом ACPI есть. Разве его не достаточно?

Ответить | Правка | Наверх | Cообщить модератору

49. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Doom (??), 30-Апр-26, 10:04

>отечественной ОС “Нейтрино”
Как вы интересно QNX Neutrino назвали:)

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

52. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от warlock (??), 01-Май-26, 00:31

> Как вы интересно QNX Neutrino назвали:)
QNX Neutrino и КПДА Нейтрино — это разные ОС, хотя и родственные.

Ответить | Правка | Наверх | Cообщить модератору

5. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +6 +/–

Сообщение от Аноним (-), 28-Апр-26, 01:59

>  А реалтайм вообще возможен в системе, где устройство может стать bus master'ом
Даже в этом моем STM32 (микроконтроллер, надеюсь достаточно реалтаймно уже?) - его DMA - может стать bus master и захватить шину... но, правда, ненадолго - round robin с процессорным ядром при клещах все же будет.
Однако жестким использованием DMA можно заметно нагнуть все даже на мк. Реалтайм дизайн системы - многофакторная штука, bus mastering (и вообще contention и рубка за ресурсы) лишь 1 из кучи аспектов.
Сам по себе "сферический bus mastering в вакууме" - не обязывает те или иные процессорные ядра вставать колом и перестать реагировать на события. А у более актуального PCIe линки так то peer to peer и что вы там захватывать собрались? Свой линк? И кому от этого плохо кроме вас самих?
> и захватить шину на столько (а-ля PCI)? Или где в самый нужный и ответственный
> момент случается SMI и все такие: "Ой, пацаны, у нас тут минус первое
> кольцо, расходимся."
"И тут я проснулся и заметил что это ARM у которого нет никакиз SMI# и ring -1" :D. И да, это повод предпочесть ARM непонятной хрени с ring -1 и мутноблобом обрабатывающим это, ибо лично отвечать за хзкакой блоб делающий хзчто раздавая оружающим гарантии свойств системы на основе хзчего - нафиг надо!

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

16. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +1 +/–

Сообщение от Смузихлеб забывший пароль (?), 28-Апр-26, 08:37

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

Ответить | Правка | Наверх | Cообщить модератору

28. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Сусанин (?), 28-Апр-26, 18:36

Поэтому для реального времени можно рассматривать только голое железо - baremetal, да и то, даже в этом случае ещё надо постараться получить реальное время.

Ответить | Правка | Наверх | Cообщить модератору

33. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (-), 28-Апр-26, 21:21

>  Дело не в этом, а в том, что линь сам по себе слишком жирная штука
Даже в обычном STM32 можно в ряде случаев заказать суммарные потоки данных по шинам + DMA больше, чем шина технически вообще могла обеспечить - и получить довольно интересные факапы.
Так что стопроцентные гарантии вам в этом мире вообще никто и никогда не дает. А там где это важно - должен быть какой-то plan B. Уповать на непогрешимость 1 юнита там где его отказ критичен - вообще моветон.
> чтобы быть с этим хоть в чём-то уверенным. Помимо того что туда требуется затащить
> гору сторонних пакетов которые вообще ничего не гарантируют.
1) Гарантии обеспечивают те кто делал интеграцию. Они првоеряют что все работает как надо, оценивают worst case, подгоняют все проблемные места, тюнят систему и проч.
2) Произвольно взятые пакеты вообще не имеют влияния на DMA, шедулинг процессов и проч. Просто потому что юзермод совсем никак не контролирует этот аспект.
3) Это никак не мешает "вот этому демону" работающему с гарантиями шедулинга что "на интервале X получит не менее Y времени CPU" обработать вон ту ситуацию. Ессно его придется написать самому. И максимально аккуратно. Абы какая программа в этой роли ессно может подвести, и придется обыграть множество системных аспектов.
4) Никто не запрещает 2-уровневый дизайн системы и подпор наиболее критичных вещей вторым уровнем защиты с МК и возможно подстраховкой оного жесткой логикой. Т.е. Linux вовсе не обязан overcurrent сам рюхать, МК может все отключить до него, а если он облажается то хардварная защита. Но линуху неплохо бы быть в курсе о проблеме за обозримое время и среагировать на это за предсказуемое время. А не через полчаса.
А суммарно - не боги горшки обжигают. И если кто ссытся с мелкого 32 бит апликушного ARM, ему вообще реалтайм в более-менее крупных системах не светит совсем.
> Это примерно как трактору с прицепом куда навалены брёвна, приделать руль
> как у гоночного авто и всерьёз называть это "гоночная тачка"
Вы такие умные, что у вас поезда в результате до сих пор бы ходили наверное с электромеханическими сигналами. Но вроде AFAIK даже РЖД какие-то более продвинутые системы деплоит уже. И да, не вижу проблем если плк и сервера будут с линухом - кого еще для нормальной сетевой конективити ставить?

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

30. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Страдивариус (ok), 28-Апр-26, 20:52

> "И тут я проснулся и заметил что это ARM у которого нет
> никакиз SMI# и ring -1" :D. И да, это повод предпочесть
> ARM непонятной хрени с ring -1 и мутноблобом обрабатывающим это, ибо
> лично отвечать за хзкакой блоб делающий хзчто раздавая оружающим гарантии свойств
> системы на основе хзчего - нафиг надо!
Родной, а ты текст новости читал кроме заголовка? Написано же тебе, что якобы это уже есть для x86 и x86_64. Я про арм ничего не спрашиваю, а спрашиваю про то, как на этом дерьме оно может работать?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

36. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (-), 28-Апр-26, 21:51

> Родной, а ты текст новости читал кроме заголовка? Написано же тебе, что
> якобы это уже есть для x86 и x86_64. Я про арм
> ничего не спрашиваю, а спрашиваю про то, как на этом дерьме
> оно может работать?
Родной, я эту новость - написал. Так что ты феерично поумничал - прямо на автора новости. И да, мой пойнт в том что на произвольно взятом писюке с хзчей мутноблоб BIOS/EFI - с хз каким SMM# Handler - ну попробуй дать гарантии его поведения. И с какого бы потолка ты данные о worst case его поведения возьмешь?
Однако если взять 2 из 3 и подстраховать каким МК попроще - даже это сможет полететь в космос как бортовой компьютер, ни много ни мало. Элон маск проверил. В общем у реалтайма и требований к нему - много ипостасей.
ARM просто сильно проще и там нет вот этого ring -1 с абы каким обработчиком в который по SMI# вышибает - безусловно, немаскируемо, и единственное что ос может вообще сделать - это констатировать что "X времени украл обработчик SMI#" - уже ПОСТФАКТУМ, что немного поздняк для гарантий. Вот этот элемент дизайна x86 как кархитектуры - крайне неудачен для RTOS, особенно - на наобум взятом компе с абы какой некооперативной системной фирмварью. Если у вас там coreboot какой и обработчик SMI# лично ваш - это совсем другой коленкор уже. Только врядли у вас ТАКОЕ есть. Сильно продвинутые типа элонмаска на такое могут и подраспереться если им надо станет.

Ответить | Правка | Наверх | Cообщить модератору

32. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Страдивариус (ok), 28-Апр-26, 20:56

> Сам по себе "сферический bus mastering в вакууме" - не обязывает те
> или иные процессорные ядра вставать колом и перестать реагировать на события.
> А у более актуального PCIe линки так то peer to peer
> и что вы там захватывать собрались? Свой линк? И кому от
> этого плохо кроме вас самих?
Не поможет в общем случае. Один девайс полез мастерить другой девайс, а в этот момент CPU решил помастерить первый - и ква.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

37. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (-), 28-Апр-26, 21:55

> Не поможет в общем случае. Один девайс полез мастерить другой девайс, а
> в этот момент CPU решил помастерить первый - и ква.
Что - ква? В общем случае проц как ядро вообще не обязан встать на паузу от этого и тем более до состояния когда он не может контекст переключить и заняться чем-то иным. Не говоря о том что ядер нынче более 1.
А мастеринг кто кого и как - iommu нынче есть так то даже у ARM нынче, ага. Даже у 32-битных есть которые не сильно ископаемые. Там вообще эта активность будет - то что хост позволит вообще.

Ответить | Правка | Наверх | Cообщить модератору

23. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (23), 28-Апр-26, 10:38

SMI, как бы, и QNX'у помешать может.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

31. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Страдивариус (ok), 28-Апр-26, 20:54

> SMI, как бы, и QNX'у помешать может.
Может, поэтому что одной ОСью риал-тайм нельзя гарантировать - это комплекс аппаратных и софтварных мер. Но как они на x86 могут вообще про риал-тайм говорить?

Ответить | Правка | Наверх | Cообщить модератору

38. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (-), 28-Апр-26, 22:47

>> SMI, как бы, и QNX'у помешать может.
> Может, поэтому что одной ОСью риал-тайм нельзя гарантировать - это комплекс аппаратных
> и софтварных мер. Но как они на x86 могут вообще про
> риал-тайм говорить?
С той или иной степенью условности и допущений. Ну скажем если у вас системная фирмварь это coreboot какой - там вы можете и быть в курсе что SMI# обработчик сделает. А наобум взятый писюшник - ессно такой себе реалтайм, на свою бошку. Ибо откуда вы знаете насколько и когда его фирмваре руль отберет? :)

Ответить | Правка | Наверх | Cообщить модератору

2. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." –2 +/–

Сообщение от Аноним (2), 27-Апр-26, 23:29

А патчи на видеопамять не принимают от валва?

Ответить | Правка | Наверх | Cообщить модератору

6. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (6), 28-Апр-26, 02:12

Но 32-бита на x86 всё равно дропнут. В отличиии от 32-битных альтернативных архитектур, у быдла на руках слишком много 32-битных селеронов и атомов, конкурируют с современным DRMнутым хламом.

Ответить | Правка | Наверх | Cообщить модератору

19. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." –3 +/–

Сообщение от Аноним (19), 28-Апр-26, 09:55

Так 32-битные АРМы ещё явно много где используются, а быдло с атомами тольо и может кричать "дай, давй".

Ответить | Правка | Наверх | Cообщить модератору

43. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." –1 +/–

Сообщение от Аноним (43), 29-Апр-26, 11:20

Вы не много хотите от bydła (скота, в переводе на русский)? Предназначение скота - пойти на котлету.

Ответить | Правка | Наверх | Cообщить модератору

7. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +2 +/–

Сообщение от Аноним (7), 28-Апр-26, 02:15

Лучше бы миррорс кернел орг починили, уже 6 дней как никаких обновлений по всем дистрам. apt даже пометил его как протухший, ибо срок жизни TUF-канарейки стёк.

Ответить | Правка | Наверх | Cообщить модератору

8. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (8), 28-Апр-26, 03:06

Не всем https://mirrors.edge.kernel.org/archlinux/ 27 Apr - вчера, а вот Debian да, протухший

Ответить | Правка | Наверх | Cообщить модератору

9. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (8), 28-Апр-26, 03:09

Теперь ясно, что случилось у них https://social.kernel.org/notice/B3FpxSKAReX7S2ePfE

Ответить | Правка | Наверх | Cообщить модератору

10. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (8), 28-Апр-26, 03:14

Цитата:
"Should we start occasionally breaking mirrors.kernel.org so that people identify and fix these dependencies? Maybe. But I'm slightly terrified of unintended consequences that may impact real people's lives."
В общем не используйте mirrors.kernel.org на продакшене

Ответить | Правка | Наверх | Cообщить модератору

11. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (11), 28-Апр-26, 07:17

>В общем не используйте скурвившийся Debian, намеренно создающий условия для взлома aptа спецслужбами путём редиректа с https на http и не фиксингга архитектуры самого апта с in-band signalling и сокетами
Ясно. Но что тогда использовать, может Apple MacOs или Windows 11? Эти давно подписали допуск к гостайне, и х специалисты сами тебе бэкдор зальют. Кстати, в прошлом году произошёл случай, нескольким менеджерам ИИ-отделов из корпораций из кремниевой долины присвоили звание полковников и привели к воинской присяге. Знаешь, мне кажется, что это далеко не первый случай, просто ИИ - горячая тема, этим можно понтоваться "вот наши военные всерьёз модернизируют нашу армию с помощью ИИ". А аналогичные присвоения званий тем, кто отвечает за помощь в шпионаже - о них широкую публику и не извещают.

Ответить | Правка | Наверх | Cообщить модератору

13. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (13), 28-Апр-26, 08:27

> редиректа с https на http
Стоп, что? Откуда такая информация?

Ответить | Правка | Наверх | Cообщить модератору

17. "-" +/–

Сообщение от Аноним (17), 28-Апр-26, 09:05

Зашёл браузером по адресу репозитория на дебиан орг, на https, меня редиректнуло на http.
Не я один такой. В интернете даже обсуждали, что в apt нет защиты от такого редиректа, хотя должна быть, городили сами на уровне файрвола, но это неправильно.

Ответить | Правка | Наверх | Cообщить модератору

18. "-" +/–

Сообщение от Аноним (18), 28-Апр-26, 09:42

В дебиане пакеты не подписываются ключом мейнтейнера? Подсовывай, какой хочешь, и апт радостно сжуёт?

Ответить | Правка | Наверх | Cообщить модератору

20. "-" +/–

Сообщение от Аноним (20), 28-Апр-26, 10:09

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

Ответить | Правка | Наверх | Cообщить модератору

22. "-" +/–

Сообщение от Аноним (18), 28-Апр-26, 10:18

Повод сменить провайдера.

Ответить | Правка | Наверх | Cообщить модератору

24. "-" +/–

Сообщение от Аноним (24), 28-Апр-26, 14:43

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

Ответить | Правка | Наверх | Cообщить модератору

34. "-" +/–

Сообщение от Аноним (20), 28-Апр-26, 21:38

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

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

39. "-" +/–

Сообщение от Аноним (-), 28-Апр-26, 22:59

> радости тебе с этой подписи, если вместо пакета твой апт получит от
> твоего провайдера 302 редирект на рекламную страницу.
Ну он и с TLS от тебя получит - ресет соединения или что там у главжандарма в тренде, если это не медвежьиуслуги.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

25. "-" +/–

Сообщение от Аноним (25), 28-Апр-26, 15:00

Вы бы хоть Интернет по теме почитали, там всё давно расписано, это очевидные вещи. Для вас видимо неочевидные, поэтому расскажу. Вот именно пакеты - не подписываются. Да и дело в другом, нам в Дебиане одну и ту же байку рассказывают год за годом "метаданные подписаны, палёный пакет не подсунут". И раз ра разом одна и та же уязвимность, инъекция в in-band signalling апта, дающая тем или иным образм RCE, в последнем публично известном случае - да, взяли и через http подменили сигнал aptа о том, что хеш пакета сходится. И каждый раз отмечалось, что если бы был TLS - то только владелец зеркала мог бы проводить такую атаку, а не кто попало на проводе. Разумеется выпиливать in-band signalling не будут, как и вводить TLS.
Почему? Очень просто, если они эти бэкдоры закроют, от них потребуют более активное участие в той активности, которая уголовно наказуема в правовом государстве, это в том, где работники Celebrite в тюрьме бы сидели на несколько пожизненных по сумме, вместе с Hacking Team и прочими уголовниками, но в мафиозном государстве - избирательное правоприменение, разведка и прочие полицаи, и их контракторы и союзники - по факту имунны. А вовлечённость в эту активность - это уже другое количество тайн этих уголовников, и другой уровень взаимодействия с их ОПГ. Есть такая пословица, популярная в определённых кругах - "меньше знаешь - дольше живёшь". Зачем проекту Дебиан вовлекаться в это дерьмо больше, чем минимально приходится, если можно создать условия, по сути бэкдор, который позволить определённым службам заниматься их криминальной деятельностью, при этом проект Дебиан в неё не посвещая, и Дебиан в случае чего может утверждать "мы тут ни при чём, в apt просто очередное CVE"?

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

26. "-" +/–

Сообщение от Аноним (18), 28-Апр-26, 15:22

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

Ответить | Правка | Наверх | Cообщить модератору

27. "-" +/–

Сообщение от Аноним (27), 28-Апр-26, 16:34

Да, да, знаем. То что Сноуден принёс - это тоже была "конспирологическая теория".

Ответить | Правка | Наверх | Cообщить модератору

35. "-" +/–

Сообщение от Аноним (35), 28-Апр-26, 21:39

А вы не в браузере смотрите, а перехватите запросы apt, например через mitmproxy.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

40. "-" +/–

Сообщение от Аноним (40), 29-Апр-26, 01:33

А смысл? Даже если они не делают это в конкретный момент для апта, то что они делают это для браузера, и что в апте нет встроенного https-only режима, и что апт вообще ходит по редиректам - это всё не в пользу Дебиана. Доверия к их репозиториям нет. То есть я пока-что не очень верю, что они стали бы подставлять малварь сами, но сравнительно отрицаемыми способами помочь "Родине" - у меня нет сомнений, что прогнутся.

Ответить | Правка | Наверх | Cообщить модератору

42. "-" +/–

Сообщение от Аноним (42), 29-Апр-26, 06:53

> не делают это
Т.е. тейк "намеренно создающий условия для взлома aptа спецслужбами" ложный?
Кстати, меня не перебрасывает на http ни в браузере (Firefox), ни в curl.

Ответить | Правка | Наверх | Cообщить модератору

44. "-" +/–

Сообщение от Аноним (43), 29-Апр-26, 11:29

curl -v https://security.debian.org/debian-security
* Host security.debian.org:443 was resolved.
* IPv6: (none)
* IPv4: 151.101.66.132, 151.101.194.132, 151.101.130.132, 151.101.2.132
*   Trying 151.101.66.132:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519MLKEM768 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=security-cdn1.debian.org
*   start date: Apr 22 00:50:45 2026 GMT
*   expire date: Jul 21 00:50:44 2026 GMT
*   issuer: C=US; O=Let's Encrypt; CN=R13
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "security.debian.org" matches cert's "security.debian.org"
* OpenSSL verify result: 0
* SSL certificate verified via OpenSSL.
* Established connection to security.debian.org (151.101.66.132 port 443) from **.**.**.** port 36738
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://security.debian.org/debian-security
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: security.debian.org]
* [HTTP/2] [1] [:path: /debian-security]
* [HTTP/2] [1] [user-agent: curl/8.20.0-rc3]
* [HTTP/2] [1] [accept: */*]
> GET /debian-security HTTP/2
> Host: security.debian.org
> User-Agent: curl/8.20.0-rc3
> Accept: */*
> TE: gzip
> Connection: TE
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 301
< server: Apache
< x-content-type-options: nosniff
< x-frame-options: sameorigin
< referrer-policy: no-referrer
< x-xss-protection: 1
< permissions-policy: interest-cohort=()
< location: http://security.debian.org/debian-security/
< cache-control: max-age=120
< expires: Wed, ** Apr 2026 **:**:** GMT
< content-type: text/html; charset=iso-8859-1
< accept-ranges: bytes
< date: Wed, ** Apr 2026 **:**:** GMT
< via: 1.1 varnish
< age: 52
< x-served-by: cache-fra-eddf8230224-FRA
< x-cache: HIT
< x-cache-hits: 1
< x-timer: S**********.******,VS0,VE1
< content-length: 360
<
(зацензурировано форумом, но тут было сообщение о редиректе текстом)
* Connection #0 to host security.debian.org:443 left intact

Вот так не перебрасывает, да? Такая у них "security", видимо "natio-anal". А в браузере - есть HTTPS-only режим. Его отключать НЕ НАДО, его надо - ВКЛЮЧАТЬ.

Ответить | Правка | Наверх | Cообщить модератору

45. "-" +/–

Сообщение от Аноним (45), 29-Апр-26, 13:30

curl -v https://security.debian.org/debian-security/
Внимание на последний символ
Сразу же ответ меняется на 200.

Ответить | Правка | Наверх | Cообщить модератору

46. "-" +/–

Сообщение от Аноним (46), 29-Апр-26, 15:57

Кстати. Ваш миррорс кернел починили.

Ответить | Правка | Наверх | Cообщить модератору

51. "-" +/–

Сообщение от Аноним (51), 30-Апр-26, 15:50

Спасибо за инфу. Но по-хорошему ответы должны быть эквивалентны.

Ответить | Правка | Наверх | Cообщить модератору

14. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (14), 28-Апр-26, 08:35

А что теперь клоны редхат использовать?

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

41. "-" +/–

Сообщение от Аноним (41), 29-Апр-26, 04:07

Кажись обновилось.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

12. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от кукпоп (?), 28-Апр-26, 07:38

Весьма хорошая новость.

Ответить | Правка | Наверх | Cообщить модератору

50. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..." +/–

Сообщение от Аноним (50), 30-Апр-26, 13:41

В 7.2 armel из ядра вытрут?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+2 +/–
Сообщение от Страдивариус (ok), 27-Апр-26, 23:10
А реалтайм вообще возможен в системе, где устройство может стать bus master'ом и захватить шину на столько (а-ля PCI)? Или где в самый нужный и ответственный момент случается SMI и все такие: "Ой, пацаны, у нас тут минус первое кольцо, расходимся."
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+3 +/–
	Сообщение от Ы (?), 28-Апр-26, 00:14
	этого на arm32 нет и да - qos и приоритеты для мастеров настраиваются
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от warlock (??), 28-Апр-26, 00:25
	SMI можно отключить (переключить на SCI).
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	29. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+1 +/–
	Сообщение от Страдивариус (ok), 28-Апр-26, 20:50
	> SMI можно отключить (переключить на SCI). На обычном писюке нельзя.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от warlock (??), 29-Апр-26, 21:22
	> На обычном писюке нельзя. Что есть "обычный писюк"? Вот например у отечественной ОС "Нейтрино" опция задокументирована: > Опции: > -a > Явное указание отключить использование SMI для систем на базе чипсетов AMD. На базе чипсетов AMD — это "обычный писюк" или "необычный"?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (-), 29-Апр-26, 21:57
	> На базе чипсетов AMD — это "обычный писюк" или "необычный"? И какие чипсеты амудэ поддерживаются для этого? Вот прям ВСЕ? Это имхо очень врядли.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от warlock (??), 01-Май-26, 00:41
	> И какие чипсеты амудэ поддерживаются для этого? Вот прям ВСЕ? Это имхо > очень врядли. Вот ХЗ. Может и не все. С другой стороны переключатель SMI на SCI в любом ACPI есть. Разве его не достаточно?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Doom (??), 30-Апр-26, 10:04
	>отечественной ОС “Нейтрино” Как вы интересно QNX Neutrino назвали:)
	Ответить \| Правка \| К родителю #47 \| Наверх \| Cообщить модератору


	52. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от warlock (??), 01-Май-26, 00:31
	> Как вы интересно QNX Neutrino назвали:) QNX Neutrino и КПДА Нейтрино — это разные ОС, хотя и родственные.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+6 +/–
	Сообщение от Аноним (-), 28-Апр-26, 01:59
	> А реалтайм вообще возможен в системе, где устройство может стать bus master'ом Даже в этом моем STM32 (микроконтроллер, надеюсь достаточно реалтаймно уже?) - его DMA - может стать bus master и захватить шину... но, правда, ненадолго - round robin с процессорным ядром при клещах все же будет. Однако жестким использованием DMA можно заметно нагнуть все даже на мк. Реалтайм дизайн системы - многофакторная штука, bus mastering (и вообще contention и рубка за ресурсы) лишь 1 из кучи аспектов. Сам по себе "сферический bus mastering в вакууме" - не обязывает те или иные процессорные ядра вставать колом и перестать реагировать на события. А у более актуального PCIe линки так то peer to peer и что вы там захватывать собрались? Свой линк? И кому от этого плохо кроме вас самих? > и захватить шину на столько (а-ля PCI)? Или где в самый нужный и ответственный > момент случается SMI и все такие: "Ой, пацаны, у нас тут минус первое > кольцо, расходимся." "И тут я проснулся и заметил что это ARM у которого нет никакиз SMI# и ring -1" :D. И да, это повод предпочесть ARM непонятной хрени с ring -1 и мутноблобом обрабатывающим это, ибо лично отвечать за хзкакой блоб делающий хзчто раздавая оружающим гарантии свойств системы на основе хзчего - нафиг надо!
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	16. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+1 +/–
	Сообщение от Смузихлеб забывший пароль (?), 28-Апр-26, 08:37
	Дело не в этом, а в том, что линь сам по себе слишком жирная штука чтобы быть с этим хоть в чём-то уверенным. Помимо того что туда требуется затащить гору сторонних пакетов которые вообще ничего не гарантируют. Это примерно как трактору с прицепом куда навалены брёвна, приделать руль как у гоночного авто и всерьёз называть это "гоночная тачка" Даже куда более компактная РТОСь вроде ФриРТОС - и то, вызывает много вопросов по своей РТОСности, т.к в действительности не может ничего гарантировать и иные события там рандомно могут обрабатываться куда дольше чем ожидалось. А более продвинутая её версия - СейфРТОС уже распространяется не бесплатно, ещё и без исходников
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Сусанин (?), 28-Апр-26, 18:36
	Поэтому для реального времени можно рассматривать только голое железо - baremetal, да и то, даже в этом случае ещё надо постараться получить реальное время.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (-), 28-Апр-26, 21:21
	> Дело не в этом, а в том, что линь сам по себе слишком жирная штука Даже в обычном STM32 можно в ряде случаев заказать суммарные потоки данных по шинам + DMA больше, чем шина технически вообще могла обеспечить - и получить довольно интересные факапы. Так что стопроцентные гарантии вам в этом мире вообще никто и никогда не дает. А там где это важно - должен быть какой-то plan B. Уповать на непогрешимость 1 юнита там где его отказ критичен - вообще моветон. > чтобы быть с этим хоть в чём-то уверенным. Помимо того что туда требуется затащить > гору сторонних пакетов которые вообще ничего не гарантируют. 1) Гарантии обеспечивают те кто делал интеграцию. Они првоеряют что все работает как надо, оценивают worst case, подгоняют все проблемные места, тюнят систему и проч. 2) Произвольно взятые пакеты вообще не имеют влияния на DMA, шедулинг процессов и проч. Просто потому что юзермод совсем никак не контролирует этот аспект. 3) Это никак не мешает "вот этому демону" работающему с гарантиями шедулинга что "на интервале X получит не менее Y времени CPU" обработать вон ту ситуацию. Ессно его придется написать самому. И максимально аккуратно. Абы какая программа в этой роли ессно может подвести, и придется обыграть множество системных аспектов. 4) Никто не запрещает 2-уровневый дизайн системы и подпор наиболее критичных вещей вторым уровнем защиты с МК и возможно подстраховкой оного жесткой логикой. Т.е. Linux вовсе не обязан overcurrent сам рюхать, МК может все отключить до него, а если он облажается то хардварная защита. Но линуху неплохо бы быть в курсе о проблеме за обозримое время и среагировать на это за предсказуемое время. А не через полчаса. А суммарно - не боги горшки обжигают. И если кто ссытся с мелкого 32 бит апликушного ARM, ему вообще реалтайм в более-менее крупных системах не светит совсем. > Это примерно как трактору с прицепом куда навалены брёвна, приделать руль > как у гоночного авто и всерьёз называть это "гоночная тачка" Вы такие умные, что у вас поезда в результате до сих пор бы ходили наверное с электромеханическими сигналами. Но вроде AFAIK даже РЖД какие-то более продвинутые системы деплоит уже. И да, не вижу проблем если плк и сервера будут с линухом - кого еще для нормальной сетевой конективити ставить?
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	30. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Страдивариус (ok), 28-Апр-26, 20:52
	> "И тут я проснулся и заметил что это ARM у которого нет > никакиз SMI# и ring -1" :D. И да, это повод предпочесть > ARM непонятной хрени с ring -1 и мутноблобом обрабатывающим это, ибо > лично отвечать за хзкакой блоб делающий хзчто раздавая оружающим гарантии свойств > системы на основе хзчего - нафиг надо! Родной, а ты текст новости читал кроме заголовка? Написано же тебе, что якобы это уже есть для x86 и x86_64. Я про арм ничего не спрашиваю, а спрашиваю про то, как на этом дерьме оно может работать?
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	36. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (-), 28-Апр-26, 21:51
	> Родной, а ты текст новости читал кроме заголовка? Написано же тебе, что > якобы это уже есть для x86 и x86_64. Я про арм > ничего не спрашиваю, а спрашиваю про то, как на этом дерьме > оно может работать? Родной, я эту новость - написал. Так что ты феерично поумничал - прямо на автора новости. И да, мой пойнт в том что на произвольно взятом писюке с хзчей мутноблоб BIOS/EFI - с хз каким SMM# Handler - ну попробуй дать гарантии его поведения. И с какого бы потолка ты данные о worst case его поведения возьмешь? Однако если взять 2 из 3 и подстраховать каким МК попроще - даже это сможет полететь в космос как бортовой компьютер, ни много ни мало. Элон маск проверил. В общем у реалтайма и требований к нему - много ипостасей. ARM просто сильно проще и там нет вот этого ring -1 с абы каким обработчиком в который по SMI# вышибает - безусловно, немаскируемо, и единственное что ос может вообще сделать - это констатировать что "X времени украл обработчик SMI#" - уже ПОСТФАКТУМ, что немного поздняк для гарантий. Вот этот элемент дизайна x86 как кархитектуры - крайне неудачен для RTOS, особенно - на наобум взятом компе с абы какой некооперативной системной фирмварью. Если у вас там coreboot какой и обработчик SMI# лично ваш - это совсем другой коленкор уже. Только врядли у вас ТАКОЕ есть. Сильно продвинутые типа элонмаска на такое могут и подраспереться если им надо станет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Страдивариус (ok), 28-Апр-26, 20:56
	> Сам по себе "сферический bus mastering в вакууме" - не обязывает те > или иные процессорные ядра вставать колом и перестать реагировать на события. > А у более актуального PCIe линки так то peer to peer > и что вы там захватывать собрались? Свой линк? И кому от > этого плохо кроме вас самих? Не поможет в общем случае. Один девайс полез мастерить другой девайс, а в этот момент CPU решил помастерить первый - и ква.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	37. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (-), 28-Апр-26, 21:55
	> Не поможет в общем случае. Один девайс полез мастерить другой девайс, а > в этот момент CPU решил помастерить первый - и ква. Что - ква? В общем случае проц как ядро вообще не обязан встать на паузу от этого и тем более до состояния когда он не может контекст переключить и заняться чем-то иным. Не говоря о том что ядер нынче более 1. А мастеринг кто кого и как - iommu нынче есть так то даже у ARM нынче, ага. Даже у 32-битных есть которые не сильно ископаемые. Там вообще эта активность будет - то что хост позволит вообще.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (23), 28-Апр-26, 10:38
	SMI, как бы, и QNX'у помешать может.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	31. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Страдивариус (ok), 28-Апр-26, 20:54
	> SMI, как бы, и QNX'у помешать может. Может, поэтому что одной ОСью риал-тайм нельзя гарантировать - это комплекс аппаратных и софтварных мер. Но как они на x86 могут вообще про риал-тайм говорить?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (-), 28-Апр-26, 22:47
	>> SMI, как бы, и QNX'у помешать может. > Может, поэтому что одной ОСью риал-тайм нельзя гарантировать - это комплекс аппаратных > и софтварных мер. Но как они на x86 могут вообще про > риал-тайм говорить? С той или иной степенью условности и допущений. Ну скажем если у вас системная фирмварь это coreboot какой - там вы можете и быть в курсе что SMI# обработчик сделает. А наобум взятый писюшник - ессно такой себе реалтайм, на свою бошку. Ибо откуда вы знаете насколько и когда его фирмваре руль отберет? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	–2 +/–
Сообщение от Аноним (2), 27-Апр-26, 23:29
А патчи на видеопамять не принимают от валва?
Ответить \| Правка \| Наверх \| Cообщить модератору

6. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
Сообщение от Аноним (6), 28-Апр-26, 02:12
Но 32-бита на x86 всё равно дропнут. В отличиии от 32-битных альтернативных архитектур, у быдла на руках слишком много 32-битных селеронов и атомов, конкурируют с современным DRMнутым хламом.
Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	–3 +/–
	Сообщение от Аноним (19), 28-Апр-26, 09:55
	Так 32-битные АРМы ещё явно много где используются, а быдло с атомами тольо и может кричать "дай, давй".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	–1 +/–
	Сообщение от Аноним (43), 29-Апр-26, 11:20
	Вы не много хотите от bydła (скота, в переводе на русский)? Предназначение скота - пойти на котлету.
	Ответить \| Правка \| Наверх \| Cообщить модератору

7. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+2 +/–
Сообщение от Аноним (7), 28-Апр-26, 02:15
Лучше бы миррорс кернел орг починили, уже 6 дней как никаких обновлений по всем дистрам. apt даже пометил его как протухший, ибо срок жизни TUF-канарейки стёк.
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (8), 28-Апр-26, 03:06
	Не всем https://mirrors.edge.kernel.org/archlinux/ 27 Apr - вчера, а вот Debian да, протухший
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (8), 28-Апр-26, 03:09
	Теперь ясно, что случилось у них https://social.kernel.org/notice/B3FpxSKAReX7S2ePfE
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (8), 28-Апр-26, 03:14
	Цитата: "Should we start occasionally breaking mirrors.kernel.org so that people identify and fix these dependencies? Maybe. But I'm slightly terrified of unintended consequences that may impact real people's lives." В общем не используйте mirrors.kernel.org на продакшене
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (11), 28-Апр-26, 07:17
	>В общем не используйте скурвившийся Debian, намеренно создающий условия для взлома aptа спецслужбами путём редиректа с https на http и не фиксингга архитектуры самого апта с in-band signalling и сокетами Ясно. Но что тогда использовать, может Apple MacOs или Windows 11? Эти давно подписали допуск к гостайне, и х специалисты сами тебе бэкдор зальют. Кстати, в прошлом году произошёл случай, нескольким менеджерам ИИ-отделов из корпораций из кремниевой долины присвоили звание полковников и привели к воинской присяге. Знаешь, мне кажется, что это далеко не первый случай, просто ИИ - горячая тема, этим можно понтоваться "вот наши военные всерьёз модернизируют нашу армию с помощью ИИ". А аналогичные присвоения званий тем, кто отвечает за помощь в шпионаже - о них широкую публику и не извещают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-..."	+/–
	Сообщение от Аноним (13), 28-Апр-26, 08:27
	> редиректа с https на http Стоп, что? Откуда такая информация?
	Ответить \| Правка \| Наверх \| Cообщить модератору