| |
| 2.33, Аноним (33), 16:40, 26/08/2026 [^] [^^] [^^^] [ответить] | +4 +/– | Идея старая и привлекательная Решает много задач Если иметь ядро OS которое па... большой текст свёрнут, показать | | |
| |
| 3.51, Аноним (51), 19:31, 26/08/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> 4. Говорят такое ядро будет намного безопаснее. Изоляция приложений выполняемых разными ядрами OS на разных ядрах CPU будет как в виртуализации. Здесь надо внимательно смотреть на реализацию SMP и межядерного взаимодействия. Ядра OS исполняемые на разных ядрах CPU между собой взаимодействуют по специальному внутреядерному протоколу. Падение или взлом одного ядра не приведет к падению или взлому других ядер.
осталось такой CPU найти :))
| | |
| |
| 4.65, Аноним (65), 22:40, 26/08/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да. Проектировщики ЦПУ были не в курсе новых техзаданий mklinux. )
| | |
| 4.69, maximnik0 (?), 01:09, 27/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>осталось такой CPU найти :))
Формально arm и риск-5 с аппаратными контроллерами памяти и атрибутами памяти таким требованиям отвечает.Правда я читал что сумели прочесть атрибуты на арм на процессоре без контроллера памяти .
| | |
|
|
|
| 1.2, Аноним (2), 11:26, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> высокий уровень изоляции
Насколько, что насчёт Spectre-like уязвимостей?
| | |
| |
| |
| 3.60, Аноним (65), 22:02, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
И здесь не защищает, так как эту функцию ядра будет брать на себя общее нижнее ядро.
| | |
|
| 2.27, penetrator (?), 15:36, 26/08/2026 [^] [^^] [^^^] [ответить]
| +3 +/– |
нет там никакой изоляции, даже аппаратные возможности не используются.. очень сомнительно
| | |
|
| 1.3, Xasd7 (?), 11:42, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
чёт не ясно..
будто бы это и хужЕе чем контэйнэрная архитектура... так как содеожит лишнии элементы которое ОДНО ядро молгло бы разруливать...
и одновремено хужЕе чем гипервизор.. так как суть гипервизора как раз в унификации -- а если гипервизора нет -- то как бы херня какая-то чисто архитектурно
| | |
| 1.6, Мемоним (?), 11:59, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Каждый экземпляр выполняется на отдельном выделенном ядре CPU
Получается изолированных ядер Linux не больше чем ядер процессора? Довольно жесткое ограничение по сравнение с гипервизором.
| | |
| |
| 2.28, Аноним (28), 15:45, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>Довольно жесткое ограничение производительности будет с гипервизором.
Исправил.
| | |
| |
| 3.59, Аноним (65), 22:00, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
Что исправил? Человек сказал, что Количество ограничено числом ядер. Гипервизор позволяет создать много больше: Некоторые из них полуспящие и не влияют на производительность остальных.
| | |
|
|
| 1.7, localhostadmin (ok), 12:00, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 > Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам
А как тогда достигается изоляция? Что мне мешает на одном экземпляре прочитать данные с другого, просто через /dev/sda?
| | |
| |
| 2.8, Мемоним (?), 12:08, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра.
| | |
| |
| 3.11, Sm0ke85 (ok), 12:19, 26/08/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра.
Так у тебя файловая система вмонтирована в оба ядра, я так понимаю, как другое ядро тебе запретит ее читать...?
Или это просто "куча линуксов" со своей ФС запущенные одновременно? Ну так все равно, если я ломанул один, то я, как бы, могу примонтировать "чужую" ФС в /mnt например и "гулять дальше"...
| | |
| |
| 4.19, Мемоним (?), 13:28, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Да, это компания "дружественных" ядер, где каждое ядро забирает себе часть устройств по согласию. Если ломануть одно, то изоляция ломается. Поэтому безопасность тут слабее, чем с гипервизором.
| | |
|
| 3.13, Аноним (23), 12:23, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами.
| | |
| |
| 4.20, Мемоним (?), 13:34, 26/08/2026 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами.
Ядра с разными настройками (тюнинг под нагрузку), ядра разных версий, живая замена ядра (но нужны отдельные инструменты чтобы перенести приложения с ядра на ядро). И изоляция все-таки более строгая, здесь ты не можешь "выйти из контейнера". Еще юзкейс: повышенная надежность, если одно ядро ушло в кернел паник, другие продолжают работать.
| | |
| |
| 5.67, Аноним (65), 23:00, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
хостовое ядро тоже имеет версию. "Живая замена ядра" сводится "пускай эти приложения пока поживут на старой версии ядра"
| | |
| 5.68, Аноним (65), 23:04, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>здесь ты не можешь "выйти из контейнера".
Вы предлагаете софт решение заменить на аппаратное. Перекинут изоляцию на проектировщиков CPU и контроллеров? Они не будут этому рады и были не в курсе, когда проектировали существующие чипы.
| | |
|
|
| 3.62, Аноним (65), 22:17, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> работают кооперативно и знают где чьё.
Привет от Windows 95. Там тоже быда "кооперативная многозадачность" вместо вытесняющей NT технологии.
| | |
|
| 2.15, похнапоха (?), 12:28, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
наверное будет нужен некий VIOS, как в IBM Power, либо нужен некая преднастройка кому какое блочное устройство смапить, как в том же IBM Power.
| | |
| 2.25, Ололош (?), 14:49, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
/dev/sda это виртуальный файл, который генерируется при загрузке ядра, тащем-та, на диске его нет, как и /proc и сокеты там всякие
| | |
| |
| |
| |
| 5.70, _ (??), 03:28, 27/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Но как Холмс?! (С)
Как ты подружишь много ядер на одну железку? А никак!
Поэтому и делают наоборот. Настоящую железку - гипервизору, а вм-ам ... sdax :-)
| | |
| |
| 6.71, _ (??), 03:29, 27/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
Короче - "весёлые картинки"(С) это всё. Расходимся поцоны!
| | |
|
|
|
|
|
| 1.10, Sm0ke85 (ok), 12:14, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Мне не очевидна область применения... Какую задачу данная технология решает лучше других... Оно как будто бы во всех задачах имеет существенные минусы... Ну может под какое нить оборудование нужно постарее/новее ядро и я вдруг пременил данного ежа-носорога и далее получил что...? Или использовал вместо виртуалки и что улучшилось, кроме производительности, или хотя бы не ухудшилось...?
Кто-нибудь в курсе: зачем Это...?
| | |
| |
| 2.22, Аноним (22), 14:07, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Для лайв апдейтов ядра целиком по А/Б схеме.
в современном мире где приложения изначально готовятся к постоянной потере аптайма неизвестно зачем это нужно
| | |
|
| 1.16, Аноним (16), 12:34, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Пахнет как вагон проблем с гонкой за ресурсами инстансами ядра, без гипервизора то
| | |
| 1.17, Аноним (17), 13:10, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Не очень понятно, зачем такое может понадобится. Память на каждое ядро придётся выделить заранее (нет возможности балансировать при нагрузке), устройства - тоже (каждому ядру по своей сетевой карте и жесткому диску. Ну или загрузка по сети).
Т.е. можно запустить на мощном сервере пару десятков "независимых" машинок, но виртуалки дадут почти тот же эффект.
| | |
| 1.18, Аноним (-), 13:11, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Эксплуатация одного из ядер даёт почти наверняка доступ ко всем остальным...
В гипервизоре получение права исполнения кода от имени ядра открывает путь к эксплуатации гипервизора. Защита многослойная. А тут... Для контейнеров уж лучше gVisor использовать, если виртуализация совсем не подходит.
| | |
| 1.21, Жыжа (?), 13:36, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам
> отдельное ядро в каждом изолированном окружении (...) эксплуатация уязвимости в котором не затрагивает другие окружения
Звучит как взаимосиключающие параграфы, не?
| | |
| |
| 2.24, Аноним (24), 14:29, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ядро можно на и живой системе без перезагрузки обновлять,так что пока сидишь на одном ядре, на другом майнят, а ты и не замечаешь.
| | |
|
| 1.26, Аноним (26), 15:22, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Чем бы не заниматься, лишь бы не разрабатывать ОС на микроядре. Микроядро + контейнеры в принципе самый безопасный вариант.
| | |
| 1.30, Аноним (30), 15:59, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ] | +1 +/– | MkLinux Microkernel Linux is a discontinued open-source experimental operating... большой текст свёрнут, показать | | |
| |
| 2.80, Ык (?), 11:21, 27/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
Да, у менятоже вопрос такой. Теперь в линкусе кроме ядер на cpu есть еще верхнее и нижнее ядро?
| | |
|
| 1.37, Аноним (37), 17:11, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Взлетит если запилить под это runk. Отгрызть у контейнеров нишу не получится, у KVM на хостинге таки да.
| | |
| |
| 2.49, _ (??), 19:23, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
Нет не взлетит.
Там в самой идее - дыра. А уж в реализации (если реализуют) ...
И ведь надо ещё на руст переписать, кстати! :)
| | |
|
| 1.50, Аноним (50), 19:25, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хорошая инициатива. Пусть ещё сделают безшовную миграцию приложений с одного ядра на другое, чтобы апдейты накатывать без ребута.
| | |
| |
| 2.66, Аноним (65), 22:56, 26/08/2026 [^] [^^] [^^^] [ответить]
| +/– |
А какая версия хостового ядра? Его всё равно надо менять. Так что только back port.
| | |
|
| 1.57, Аноним (57), 21:10, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Новое - это хорошо забытое старое.
Распределённая на несколько ядер операционная система - это не новинка. Есть повод перечитать старые книжки Таненбаума.
| | |
| 1.58, Аноним (65), 21:52, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Анархия какая-то. Как мониторить потребление ресурсов соседом? Пускать второе ядро как часть своего?
| | |
| 1.61, Аноним (65), 22:14, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вероятно, сведется всё к собственному формату изоляции вместо обще-специфицированного через VM. Плюс отсутствие полноценного гипервизора будет неуправляемость. Ну или ранний рудкит хостового ядра будет всё наблюдать...
| | |
|
