|
2.5, Аноним (5), 17:01, 20/09/2025 [^] [^^] [^^^] [ответить]
| –3 +/– |
Везде, где нужно запускать больше одного ядра параллельно. Для локалхоста, очевидно, не нужно.
| |
|
|
4.21, Аноним (21), 17:56, 20/09/2025 [^] [^^] [^^^] [ответить]
| +10 +/– |
Позволить?!
Если хостеры на этом смогут *продавать* больше виртуалок т.е. больше заработать денег на том же железе, то им это нужно.
| |
|
5.41, trashwind23 (ok), 19:43, 20/09/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
По описанию в новости не похоже что тостеры смогут больше. Тут прибивание кернелей к ядрам цпу, а хостерам оверсел в основном деньги приносит.
| |
|
6.82, Аноним (-), 10:09, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> По описанию в новости не похоже что тостеры смогут больше. Тут прибивание
> кернелей к ядрам цпу, а хостерам оверсел в основном деньги приносит.
Ну вообще-то даже вещи типа KVM - в ядре линя - делают довольно много чего для перехвата всяких привилегированных операций и кастомной обработки. Просто сбагрить кернелу для выполнения было бы быстрее. Но вызывает вопросы по части уровня изоляции.
Т.е. если 1 мультикернел профачится - может это отлиться другому мультикернелу или основному кернелу из той схемы? В виртуалке то - как максимум процесс виртуалки будет прибит и на этом факап и закончится. А там?
| |
|
|
4.22, Аноним (22), 18:12, 20/09/2025 [^] [^^] [^^^] [ответить]
| +6 +/– |
Если своей фантазии не хватает, в новости можно пройти по ссылкам и почитать и чем мотивировались авторы, и сравнение с виртуалками, и даже предполагаемые юзкейсы.
| |
|
3.17, Аноним (17), 17:47, 20/09/2025 [^] [^^] [^^^] [ответить]
| +7 +/– |
> Везде, где нужно запускать больше одного ядра параллельно. Для локалхоста, очевидно, не
> нужно.
Эээ, у меня локалхост, а мне вот нужно. Вы, батенька путаете понятие локалхост и локалхост хомяка-нормиса, которому там только фурей смотреть и арч обновлять. И нет, неочевидно!
| |
|
4.24, Аноним (22), 18:14, 20/09/2025 [^] [^^] [^^^] [ответить]
| –5 +/– |
Я как раз ничего не путаю, в отличие от тебя. То, что ты дома по вечерам косплеишь сисадмина не добавляет нужности твоему локалхосту.
| |
|
|
2.56, двухядерный (?), 21:29, 20/09/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Core One Duo & Core Two Duo.
На первом ядре запущено ядро с опеннетом в lynx. На втором вторые герои.
И получилась какая-то линукс-тавтология, ля.
| |
2.87, shardddin (?), 12:09, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
По идее, при параллельном выполнении другим ядро с маленькой задержкой - можно дойти до точки паники первого ядра и обойти ошибку - с продолжением работы... Во втором случае - запустить деятельность обновленного ядра после обновления - бесшовно и без перезагрузок... Видится хорошим делом!
| |
|
3.93, sage (??), 15:36, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Паника скорее от драйверов прилетит, значит или там баг или железо отвалилось.
Судя по диаграммам, драйверы железа останутся в общем Kernel. И когда оно запаникует, умрёт вся система.
| |
|
|
1.4, Аноним (4), 16:55, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
Надо развернуть сравнение "Attack Surface" с VM, сдаётся мне, фуфло они втирают. "Kernel Customization" тоже, в виртуалке любое ядро можно запускать
| |
|
2.62, penetrator (?), 22:08, 20/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
100% фуфло
Одновременное выполнение нескольких ядер осуществляется без виртуализации - так за счет чего тогда изоляция? если аппаратные ресурсы для этого не используются? чем это лучше крэп-контейнеров?
VM - performance overhead - High
бред сивой кабылы, я тестил VMWare на AMD CPU, производительность под VM была ниже всего на 1-2%, когда тот же кубер сжирает до 30% и никого это не волнует
есть конечно проблемы с оверсейлингом и с ущербной дисковой подсистемой у VPS, обычно IO даже у гиперскелейров на уровня дешманских провайдеров, но это проблема самих продаванов, да и в принципе авторы явно не про IO пишут, а про CPU
| |
|
3.84, Анонисссм (?), 11:22, 21/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
>когда тот же кубер сжирает до 30% и никого это не волнует
меня волнует ) поэтому его у меня нет
| |
3.94, Аноним (94), 15:40, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Одновременное выполнение нескольких ядер осуществляется без виртуализации - так за счет чего тогда изоляция?
Того что сущности ядра (процессы, IPC) вообще не пересекаются, например?
Найти дырень чтобы из одного процесса в другой пролезть станет так же сложно как с виртуалками, только без накладных расходов.
| |
|
4.109, penetrator (?), 22:27, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
не станет также сложно, у тебя сугубо программное разделение, это же все равно что сбежать их сандбокса
все фишки CPU для виртуализации ты не используешь, в том числе например новомодный SEV в Epyc
| |
|
3.97, Аноним (22), 16:47, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> тот же кубер сжирает до 30%
До 30% чего именно? А то у меня этих кубов пара десятков в проде и я почему-то 30% оверхед не наблюдаю нигде. Не поделишься настройками? Хочу попугать коллег на хэллоуин.
> проблемы с оверсейлингом
Что такое «оверсейлинг»? Это что-то морское? Чрезмерное хождение под парусами?
| |
|
4.99, QrKot (?), 17:28, 21/09/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да он курьер в docker-for-windows крутит. Оно и логично: кубер на линухе, запущенной в виртуалке, которая крутится в hyperV, запущенном из Windows For Home Users. Ну да, там пипец оверхед...
| |
|
5.104, Аноним (22), 21:44, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Я раньше так и делал, только с той разницей, что на Windows 11 Pro. Я оверхед не замерял, но он там достаточно небольшой, чтобы его игнорировать, и уж точно не 30%. Вот уж что-что, а в виртуалке Линукс весьма эффективно работает, а тут ещё Майкрософт постарался чтобы под HyperV нативные интерфейсы можно было использовать. Даже в случае Docker for Windows и KinD или minikube, не видел тридцатипроцентного оверхеда, но видел уже достаточный чтобы его заметить. Теряюсь в догадках.
| |
|
4.110, penetrator (?), 22:39, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
погугли. сеть + CPU, там количество веб запросов тестировалось
> Что такое «оверсейлинг»? Это что-то морское? Чрезмерное хождение под парусами?
это overselling, чего докулопался, ты ж понял какой термин на английском имелся ввиду
| |
|
3.98, QrKot (?), 17:23, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Курьер съедает 30% чего? Словарного запаса? Свободного времени?
Что такого cgroup'ы с namespace'ами съедают?
| |
|
2.68, Аноним (68), 00:21, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Attack Surface
Они на ровных щах утверждают, что если убрать гипервизор и вкрутить ядро гостя сразу, то поверхность атаки уменьшится?
| |
|
3.100, Аноним (-), 18:05, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
>> Attack Surface
> Они на ровных щах утверждают, что если убрать гипервизор и вкрутить ядро
> гостя сразу, то поверхность атаки уменьшится?
По логике вещей - да, из поверхности атаки выпадает как минимум гипервизор :)
| |
|
4.120, pofigist (?), 09:21, 22/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Это из серии "для лучшей безопасности уберем из сети фаервол, чтоб уменьшить поверхность отаки"🤣
| |
|
|
2.73, SKZ (?), 06:03, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
"Золяция идеть" там, разве что, за счёт разных таблиц трансляции на разных процессорах.
| |
|
1.6, 08497 (?), 17:09, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Отличное изобретение для хакиров. Все уязвимости одного кернела умножаем ни количество запущенных кернелов. А если еще на каждом кернеле запустить еще по несколько виртуалок, в каждой по несколько кернелов, ну вы поняли, да?
| |
|
2.19, мамины какиры самые забавные (?), 17:51, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Отличное изобретение для хакиров. Все уязвимости одного кернела умножаем ни количество
> запущенных кернелов. А если еще на каждом кернеле запустить еще по
> несколько виртуалок, в каждой по несколько кернелов, ну вы поняли, да?
Чисто гипотетически, в вакууме, но к этим всем ядрам ваш вакуумный какир должен ещё пробраться и как-то понять, что соседнее ядро это соседнее ядро в пачке мультиядер, как-то сдетектить каким уязвимостям оно подвержено и т.п.
Но по факту чем оно отличается от необходимости щупать подсеть с несколькими машинами на предмет наличия уязвимостей в каждой, например?
Сдаётся мне, вы на очень толстый глобус пытаетесь натянуть очень тощую и ни разу не эластичную сову.
| |
|
3.36, 08497 (?), 19:22, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Чисто гипотетически, в вакууме, но к этим всем ядрам ваш вакуумный какир должен ещё пробраться и как-то понять, что соседнее ядро это соседнее ядро в пачке мультиядер, как-то сдетектить каким уязвимостям оно подвержено и т.п.
ls /proc/multikernel
> Но по факту чем оно отличается от необходимости щупать подсеть с несколькими машинами на предмет наличия уязвимостей в каждой, например?
Зачем. На целевой машине уже несколько подконтрольных кернелов. Если парнишка попал на целевую машину, то не из воздуха же, с большой вероятностью это шлюз. Ядро (да не одно) у него под контролем, сеть соответственно тоже.
> Сдаётся мне, вы на очень толстый глобус пытаетесь натянуть очень тощую и ни разу не эластичную сову.
И получается, что сова не такая и тощая, да и глобус не толст.
| |
3.47, Хорошо смеёцца TOT (?), 19:59, 20/09/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Хз, как оно в вакууме, а в зэ Ядре вон - интерфейс мультиядра. "Для мониторинга и отладки". Ага.
Доступ к железу прямой. И у ядер-сыновей и Ядра-Отца. А у нас тут миллион "спекулятивных" уязвимостей в процессорах и чипах памяти. Удобно.
Сеть изолировать легко. У сети - периметр. Сторожа на концах протоколов.
А тут, понимаю, дЫрект-аксэс-саксэсс к железу, на котором стоит сторожка.
А потом, когда доступ наспекулировали, на нескольких ядрах можно ещё долго прятаться: переживая сканирования, обновления и перезагрузки. Ведь, не будут же "экономисты" из-за нас все ядра останавливать и допрашивать..
Ну хз, конечно. Но если из виртуалок убегают и гипервизоры ломают, тот тут.. Ну зато сэкономия. А ещё сэкономнее - в розетку не включать. Люди, берегите планету!
| |
|
|
1.7, Аноним (7), 17:09, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
Не понимаю что здесь нового. Разные ядра linux и так выполняются в разных VM.
| |
|
2.38, 1 (??), 19:34, 20/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Эта схема для kvm.
В случае с xen или vmware hypervisor будет над hardware.
| |
|
3.52, morphe (?), 20:15, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> vmware
Если речь о vmware workstation и прочем консьюмерском - то над kernel, если о чём-то другом - хотел бы услышать о чём
HyperV вот как и Xen - под ядром, да
| |
|
4.61, Аноним (61), 21:53, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
>> если о чём-то другом - хотел бы услышать о чём
Вы про ESXi не слышали?.. Оо
| |
|
5.63, morphe (?), 22:37, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Вы про ESXi не слышали?.. Оо
Я почему-то думал что под него только штуки для менеджмента от vmware есть (VSphere), я думал сам ESXi не от них, спасибо
| |
|
|
3.66, Мемоним (?), 23:05, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Эта схема для kvm.
> В случае с xen или vmware hypervisor будет над hardware.
Тут по-моему неважно что код KVM реализуется как часть ядра. Важно что он предоставляет низкоуровневый сервис верхнему слою (остальному ядру).
| |
|
|
1.9, Аноним (7), 17:12, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Производительность при использовании Multikernel оценивается как близкая к производительности выполнения на отдельном оборудовании.
Ну так паравиртуализация тоже близка по производительности к нативной.
| |
|
2.95, sage (??), 15:43, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Это пока процесс работает. Когда переключение контекста происходит - всё замирает на большее время.
| |
|
1.12, Аноним (7), 17:24, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Гипервизор не зря ел свой "хлеб". Это гибкость, функциональность, контроль, безопасность. Обработчик SMP будет "обрастать ракушками" по мере плавания и будет тем же гипервизором.
| |
|
2.20, Еще один Аноним (?), 17:52, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ну дак это классическая (Н. Винера) кибернетическая система (хоть и виртуальная), состоящей из управляющего (в данном случае гипервизор) и управляемого (сама ВМ) элемента. Мне кажется, что если покопаться детально в этом Multikernel, может тоже выясниться, что там тоже есть разделение на управляющую и управляемую подсистемы.
| |
|
3.40, 1 (??), 19:42, 20/09/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Сложность управляющей системы не может быть меньше управляемый.
| |
|
4.67, r1 (?), 23:46, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Наоборот! Она должна быть меньше- иначе не случится собственно управления. Получится просто еще одна надстройка над управляемым объектом.
| |
|
|
2.80, Аноним (-), 10:05, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Гипервизор не зря ел свой "хлеб". Это гибкость, функциональность,
> контроль, безопасность. Обработчик SMP будет "обрастать ракушками"
> по мере плавания и будет тем же гипервизором.
Или не будет - не настолько крутая и полная абстракция - может заскипать некоторые вещи.
| |
|
1.14, Аноним (14), 17:28, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Скрестили ужа с ежом, получилось непонятно что. С процессорами еще можно отдаленно понять как они между ядрами расшариваются. А память как делить? А ввод-вывод? Без гипервизора, ага
| |
|
2.15, Аноним (14), 17:30, 20/09/2025 [^] [^^] [^^^] [ответить]
| +3 +/– |
Напоминает добровольную мультизадачность под досом. Все хорошо пока хорошо
| |
2.16, Аноним (16), 17:42, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
На уровне ведра этим можно рулить (если патчи сделать), это не проблема. Непонятно только, почему они утверждают будто изоляция на уровне ядер дает меньшую поверхность атаки, чем виртуализация. Ну и в целом юзкейсы неясны. Виртуализация нужна для эмуляции оборудования, а контейнеризация для простой и быстрой доставки приложений. Какие профиты дает мультикернел непонятно.
| |
|
3.31, Аноним (31), 18:42, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
При атаке на гипервизор у малвари права ring -2, а так только ring 0.
| |
|
4.34, Аноним (34), 19:16, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Минус 2 - это относительно ring 0 гостя, для хоста это - ring 0 если сам гипервизор (аппаратно-виртуализованный, если эмуляция - то вообще всё в ring 2), а эмулируемые устройства, за исключением нескольких virtio-устройств вообще в ring 2 живут. При этом атаковать сам гипервизор на порядки сложнее из-за того что у него поверхность атаки меньше (в основном это эмулируемые устройства), а код KVM-гипервизора шарится многими продуктами и весьма отлажен и оттестирован.
| |
|
5.39, Аноним (31), 19:41, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
-2 это smm, гипервизор это -1
и vmware к примеру того, да и xen
| |
|
|
7.81, Аноним (31), 10:07, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Это возможности системы по ограничению прав кода. Фантазиями это было, пока не пошло массово на практике.
| |
|
8.83, Аноним (83), 10:51, 21/09/2025 [^] [^^] [^^^] [ответить] | +1 +/– | Ни в одной официальной документации эти режимы не перечисленны как минусовые кол... текст свёрнут, показать | |
|
9.86, Аноним (31), 11:49, 21/09/2025 [^] [^^] [^^^] [ответить] | +/– | Там вообще какие-то подробности есть Это всё под NDA, пользователь таких детале... текст свёрнут, показать | |
|
|
|
12.127, SKZ (?), 12:52, 22/09/2025 [^] [^^] [^^^] [ответить] | +/– | Обычно эти сказки рассказывают те, кто ни одного NDA не видел в жизни, не говоря... текст свёрнут, показать | |
|
|
|
|
|
7.101, Аноним (-), 18:08, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Скажем прямо, что минусовые уровни вообще чистые фантазии.
А SMM mode тогда - какой ring получается? Учитывая что он более привилегированный чем ring0 вплоть до того что может в любой момент выставить код ring0, тот никак не может это предотвратить и может как максимум постфактум узнать - что SMM handler его оказывается выпер с проца на эн наносекунд. Что делает x86 не очень подходящими для реалтайм применений системами. Потому что worst case обработчика SMM в проприетарном бинарном фирмваре - неизвестная величина.
| |
|
|
|
|
|
2.23, пох. (?), 18:13, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ну так и делить - тебе половина, и мине одна вторая.
В принципе, для этого и в обычном ведре почти все есть.
Диски очевидно привязаны к экземпляру. Консоль достанется кому-то одному.
Про "эффективность" при таком разделении топором, понятно, можно забыть.
| |
2.43, 1 (??), 19:47, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ещё немного ещё чутьчуть и интел сделает в процах аналог ldom.
| |
2.118, Аноним (-), 09:07, 22/09/2025 [^] [^^] [^^^] [ответить] | +/– | DragonFlyBSD так с самого начала и работает На каждом ядре CPU можно запускать ... большой текст свёрнут, показать | |
|
1.25, Аноним (25), 18:21, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Наконец будет нормальное 3d ускорение в гостевой системе без virgl/virtio и sriov?
| |
1.26, Аноним (34), 18:27, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
>Multikernel преподносится как новая архитектура изоляции, занимающая нишу между виртуализацией при помощи гипервизора и контейнерной изоляцией на базе общего ядра
Не понятно, зачем. Главная претензия к контейнерам - из них можно достать до главного ядра, ломануть его, а как его ломанули - так машина взломана по полной. Для решения этой проблемы используют гипервизоры. Ядру выделяется виртуальная машина, оно в ней полностью крутится, а из виртуальной машины до хоста - гипервизор с очень ограниченной поверхностью атаки. Тут же предлагают выполнять дочерние ядра поверх хостового без всякого гипервизора, то есть ничего не меняется с точки зрения взлома контейнеров: ломаем дочернее ядро, и сразу же ломаем хостовое, PROFIT.
| |
|
2.37, Аноним (37), 19:23, 20/09/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Забыл ещё вывод подвести: предложенная система будет жрать память как полноценная виртуалка, иметь оверхед, сравнимый с виртуалкой, а безопасность предлагать на уровне контейнера. На сайте один маркетинговый буллшит, snake oil какой-то.
| |
|
1.28, Аноним (34), 18:33, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Кстати, дочерние ядра прямо в юзерспейсных процессах, а под ними - своя ФС, свои контейнеры ... можно запускать было очень давно, с начала нулевых в ядре опция его собирать так, чтобы оно работало как обычная линуксовая программа. Только единственный профит - это просто упрощение разработки самого ядра линукс и дров к нему, чтобы с виртуалками не париться. Кому для изоляции - тем полноценная виртуалка. Кому не нужны такие требования к изоляции - тем и контейнеры и песочницы сойдут.
| |
|
|
3.102, Аноним (-), 18:10, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Как опция в конфиге выглядит?
man "user mode linux" грубо говоря. Идея проста как топор: ядро пашет в юзермоде и реализует свои сисколы - сбагриванием сисколов себе подобному уровнем ниже. Но вот по оверхеду это все же не совсем бесплатно.
| |
|
|
|
2.45, 1 (??), 19:55, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Скорее невозбранно сперли, но недоперли и отдали впопенсорс.
| |
|
1.46, Аноним (46), 19:57, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Мне кажется, или что-то походжее уже было в Cooperative Linux? Там, правда, ядро запускали в винде
| |
|
2.70, Аноним (-), 02:53, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
CoLinux - это модифицированный User-Mode Linux т.е. запуск ядра как приложения пользователем в его окружении от сюда и название. Сабж вроде как модифицирует процесс загрузки ядра и вместо одного ядра, запускает несколько ядер. Пользователь никаких приложений не запускает, он дает команду утилите которая взаимодействует с ядром.
| |
2.92, maximnik0 (?), 15:29, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
>Мне кажется, или что-то походжее уже было в Cooperative Linux?
Да, был похожий проект.Специально падченное ядро - ещё без полноценной аппаратной виртулизации В ALT linux стоит поискать - там была какая то метка у той серии ядер.Если нужно поищу в рассылке - народ для серверов использовал- но глюки иногда были страшные, как выяснилось изоляция оказалось слабая из за особенности сегментной памяти.Спустя 2 года вышел xen а потом и остальные подтянулись проект загнулся: кое что в виде подачей потом ушло на контейнеры и KVM.
| |
|
1.51, Аноним (51), 20:14, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Multikernel IPI
А почему ipi?
Ч̶т̶о̶б̶ы̶ ̶н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ api бы не пропустили т.к. stable is a nonsense, а так прокатит.
| |
1.64, Аноним (64), 22:52, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Вот так ядро Линукс получит микроядерную архитектуру! Размножат обкусанный монолит и посадят по ядру на каждую подсистему.
| |
|
|
3.78, Песнь скрипучих дроздов (?), 09:19, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
но к тому всё идёт, но а сейчас это больше напоминает ядерный ну или ядрёный флатпак.
а так со временем выделят по ядру на каждую подсистему(конечно же для повышения безопасности) а чтобы всем этим управлять напишут "небольшой набор низкоуровневых примитивов/механизмов/сервисов", ну и чем это будет не микроядро, правда через Ж, но всё же
| |
|
2.105, Аноним (105), 21:47, 21/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да просто Линус боится потерять контроль над разработкай ядра, иначе своё ЧСВ несможет больше реализовывать.
Микроядерная архитектура это прогресс для свободного ПО.
| |
|
1.71, Аноним (-), 03:07, 21/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
На данном этапе не пригодно к использованию: бэкэнд есть (патчи ядра), а самой утилиты-менеджера и документации нет, даже в репозитории разработчика. Разработчик на хайпе, пиарится: звезды зарабатывает, последователей, донаты, контракты. Какое-то время придется подождать пока он не настытит свое ЧСВ и не откроет утилиту-менеджер или пока другие не разработают.
| |
1.91, Roman Dyaba (ok), 15:02, 21/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Это фигне больше 25-и лет ! Старо как мир.
Заводим микроядро и vm к нему, контролируем его через сеть, заводим любую целевую систему.
https://vk.com/qnx_rtos
Почитайте так же документацию netbsd и freebsd, и даже opennet, всё подробно описано.
| |
|
2.103, Аноним (-), 18:13, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Почитайте так же документацию netbsd и freebsd, и даже opennet, всё подробно описано.
Зачем тратить время на Linux - я понимаю. А зачем на вон тех - не особо. С этого никаких денег не получишь. Особенно на нормальных условиях и без ужасного головняка, как в этом QNX.
Linux так то нынче - тоже уже RTOS, патчи RT Linux все ж дожали в майнлайн.
| |
|
3.107, Аноним (22), 21:51, 21/09/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Linux так то нынче - тоже уже RTOS, патчи RT Linux все ж дожали в майнлайн.
Сейчас тебе расскажут, что там неправильный RTOS, на котором нельзя сделать станок, вращающий ядерную электростанцию со скоростью медицинского оборудования, и поэтому он совершенно непригоден для хостинга высоконагруженного форума орнитологов-любителей.
| |
3.115, bOOster (ok), 07:27, 22/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Разумный системный администратор применяет все что есть под рукой если решение подходит лучше.
Ну а оголтелые с отсутствием/недостатком компетенций застревают в чем-то одном - "не понимают".
Непониматоры/неосиляторы такие.
| |
|
|
1.106, Аноним (22), 21:48, 21/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ну что, кто там без солярисовых зон страдал?
Прежде чем строчить «это не то, в солярисе было…» — да, это не то. Да, в солярисе было. Именно что было. А это есть (или возможно будет — как угодно) на Линуксе, который тоже есть сейчас.
| |
|
2.113, нах. (?), 23:37, 21/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
В солярисе было нормально сделано. А тут - очередной монстр д-ра Франкенштейна.
| |
|
1.114, bOOster (ok), 07:19, 22/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Эта возможность опоздала лет на 20. Когда компьютерное железо стоило дорого. На текущий момент абсолютно ненужная и потенциально проблемная возможность.
| |
|
2.124, пох. (?), 11:43, 22/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Если ты из своего подвала не видел - компьютерное железо сейчас стоит ОЧЕНЬ дорого. Гораздо дороже твоего пнятри.
И его мощность избыточна для твоего хомяка (ему и пня три хватило бы, если бы конденсаторы не взорвались).
Поэтому отнять и поделить - вполне рациональная затея. Но все портит реализация - тут соглашусь с тобой, что это вот - абсолютное ненужно.
| |
|
1.117, Аноним12345 (?), 08:36, 22/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
дак а железо-то - я имею ввиду периферию в виде памяти, видеокарт - все равно одно, и будет к ним очередь, как ни крути
| |
|