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

"Первый выпуск mklinux для одновременного выполнения нескольких экземпляров ядра Linux"	+/–
Сообщение от opennews (??), 26-Авг-26, 11:26
Представлен первый публичный выпуск проекта Multikernel Linux (mklinux-v7.0-mk2), развивающего вариант ядра Linux, дополненный возможностью выполнения нескольких независимых экземпляров ядра на одном физическом компьютере  без использования гипервизора  и виртуализации. Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам и может использоваться для запуска отдельных изолированных системных окружений. Первый выпуск основан на ядре Linux 7.0 и содержит сборочную настройку "CONFIG_MULTIKERNEL", при отключении которой ядро становится полностью аналогично штатному ядру 7.0. Из архитектур CPU пока поддерживается только x86_64... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=66142
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 26-Авг-26, 11:26	–3 +/–
Что-то вроде Xen намечается.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #33

2. Сообщение от Аноним (2), 26-Авг-26, 11:26	–2 +/–
> высокий уровень изоляции Насколько, что насчёт Spectre-like уязвимостей?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #27

3. Сообщение от Xasd7 (?), 26-Авг-26, 11:42	+2 +/–
чёт не ясно.. будто бы это и хужЕе чем контэйнэрная архитектура... так как содеожит лишнии элементы которое ОДНО ядро молгло бы разруливать... и одновремено хужЕе чем гипервизор.. так как суть гипервизора как раз в унификации -- а если гипервизора нет -- то как бы херня какая-то чисто архитектурно
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от Аноним (4), 26-Авг-26, 11:53	+9 +/–
Скорее LPAR
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

6. Сообщение от Мемоним (?), 26-Авг-26, 11:59	+1 +/–
> Каждый экземпляр выполняется на отдельном выделенном ядре CPU Получается изолированных ядер Linux не больше чем ядер процессора? Довольно жесткое ограничение по сравнение с гипервизором.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

7. Сообщение от localhostadmin (ok), 26-Авг-26, 12:00	+2 +/–
> Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам А как тогда достигается изоляция? Что мне мешает на одном экземпляре прочитать данные с другого, просто через /dev/sda?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #15, #25

8. Сообщение от Мемоним (?), 26-Авг-26, 12:08	+/–
Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #11, #13, #62

9. Сообщение от тожемимокрокодил (?), 26-Авг-26, 12:11	+/–
Не очень понятно, это аналог NetBSD-шного RUMP или развитие Siemens-овского Xenomai?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32

10. Сообщение от Sm0ke85 (ok), 26-Авг-26, 12:14	+1 +/–
Мне не очевидна область применения... Какую задачу данная технология решает лучше других... Оно как будто бы во всех задачах имеет существенные минусы... Ну может под какое нить оборудование нужно постарее/новее ядро и я вдруг пременил данного ежа-носорога и далее получил что...? Или использовал вместо виртуалки и что улучшилось, кроме производительности, или хотя бы не ухудшилось...? Кто-нибудь в курсе: зачем Это...?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #22

11. Сообщение от Sm0ke85 (ok), 26-Авг-26, 12:19	+1 +/–
>Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра. Так у тебя файловая система вмонтирована в оба ядра, я так понимаю, как другое ядро тебе запретит ее читать...? Или это просто "куча линуксов" со своей ФС запущенные одновременно? Ну так все равно, если я ломанул один, то я, как бы, могу примонтировать "чужую" ФС в /mnt например и "гулять дальше"...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #19, #52

12. Сообщение от Аноним (2), 26-Авг-26, 12:20	+1 +/–
> зачем Реклама компании https://multikernel.io/products/cloud.html Цитирую - "A per-node annual subscription"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

13. Сообщение от Аноним (23), 26-Авг-26, 12:23	+/–
Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #20

15. Сообщение от похнапоха (?), 26-Авг-26, 12:28	+/–
наверное будет нужен некий VIOS, как в IBM Power, либо нужен некая преднастройка кому какое блочное устройство смапить, как в том же IBM Power.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

16. Сообщение от Аноним (16), 26-Авг-26, 12:34	+2 +/–
Пахнет как вагон проблем с гонкой за ресурсами инстансами ядра, без гипервизора то
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Аноним (17), 26-Авг-26, 13:10	+/–
Не очень понятно, зачем такое может понадобится. Память на каждое ядро придётся выделить заранее (нет возможности балансировать при нагрузке), устройства - тоже (каждому ядру по своей сетевой карте и жесткому диску. Ну или загрузка по сети). Т.е. можно запустить на мощном сервере пару десятков "независимых" машинок, но виртуалки дадут почти тот же эффект.
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от Аноним (-), 26-Авг-26, 13:11	+/–
Эксплуатация одного из ядер даёт почти наверняка доступ ко всем остальным... В гипервизоре получение права исполнения кода от имени ядра открывает путь к эксплуатации гипервизора. Защита многослойная. А тут... Для контейнеров уж лучше gVisor использовать, если виртуализация совсем не подходит.
Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от Мемоним (?), 26-Авг-26, 13:28	+/–
Да, это компания "дружественных" ядер, где каждое ядро забирает себе часть устройств по согласию. Если ломануть одно, то изоляция ломается. Поэтому безопасность тут слабее, чем с гипервизором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

20. Сообщение от Мемоним (?), 26-Авг-26, 13:34	+3 +/–
> Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами. Ядра с разными настройками (тюнинг под нагрузку), ядра разных версий, живая замена ядра (но нужны отдельные инструменты чтобы перенести приложения с ядра на ядро). И изоляция все-таки более строгая, здесь ты не можешь "выйти из контейнера". Еще юзкейс: повышенная надежность, если одно ядро ушло в кернел паник, другие продолжают работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #67, #68

21. Сообщение от Жыжа (?), 26-Авг-26, 13:36	+1 +/–
> Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам > отдельное ядро в каждом изолированном окружении (...) эксплуатация уязвимости в котором не затрагивает другие окружения Звучит как взаимосиключающие параграфы, не?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

22. Сообщение от Аноним (22), 26-Авг-26, 14:07	+/–
Для лайв апдейтов ядра целиком по А/Б схеме. в современном мире где приложения изначально готовятся к постоянной потере аптайма неизвестно зачем это нужно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

23. Сообщение от Аноним (23), 26-Авг-26, 14:14	+1 +/–
От Spectre даже полноценная виртуалка не защищает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #60

24. Сообщение от Аноним (24), 26-Авг-26, 14:29	+/–
Ядро можно на и живой системе без перезагрузки обновлять,так что пока сидишь на одном ядре, на другом майнят, а ты и не замечаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #53

25. Сообщение от Ололош (?), 26-Авг-26, 14:49	+/–
/dev/sda это виртуальный файл, который генерируется при загрузке ядра, тащем-та, на диске его нет, как и /proc и сокеты там всякие
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #46

26. Сообщение от Аноним (26), 26-Авг-26, 15:22	+1 +/–
Чем бы не заниматься, лишь бы не разрабатывать ОС на микроядре. Микроядро + контейнеры в принципе самый безопасный вариант.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #31

27. Сообщение от penetrator (?), 26-Авг-26, 15:36	+3 +/–
нет там никакой изоляции, даже аппаратные возможности не используются.. очень сомнительно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

28. Сообщение от Аноним (28), 26-Авг-26, 15:45	+/–
>Довольно жесткое ограничение производительности будет с гипервизором. Исправил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #59

29. Сообщение от Анонче (?), 26-Авг-26, 15:48	+/–
Нахрен не надо не доработано деньги не тем ушли , ну и представь масштаб катастрофы ии ботяра оплачивается некий новоиспеченный сеньер год опыта и лутает эти деньги, так что пусть всё в хорошем смысле слова нае..ся
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #38

30. Сообщение от Аноним (30), 26-Авг-26, 15:59	+1 +/–
MkLinux (Microkernel Linux) is a discontinued open-source experimental operating system for PowerPC Macintosh computers. It was launched in 1995 as a collaboration between the Open Software Foundation (OSF) and Apple Computer, as a critical pivot in Apple's technical and social history. MkLinux became Apple's first official free and open-source software community project, and the debut of Linux on the first Power Macintosh. MkLinux's key feature is its microkernel architecture. Most Linux distributions have a monolithic kernel, but MkLinux is distinguished by its architecture which adapted the Linux kernel to run as a user-space server hosted on top of the Mach microkernel version 3.0. This "single server" architecture makes the system stable and easier to debug, but the overhead of communicating with the microkernel reduces performance.[1]
Ответить | Правка | Наверх | Cообщить модератору

31. Сообщение от Анонче (?), 26-Авг-26, 15:59	–1 +/–
Все скатилась эти кто лутают они даже не понимают что музыка не их и они не композировали её и разве что актёры выигрывают им даже если они не будут сниматься в кино можно все время брать за использование образа лица и всё такое , фактически актеры могут вообще лежать на печи и изредка судиться что бы взять за образ со студии ну с оговоркой что они в паре десятков фильмов играли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #39

32. Сообщение от Аноним (33), 26-Авг-26, 16:21	+/–
Идеи скорее с DrugonFlyBSD.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

33. Сообщение от Аноним (33), 26-Авг-26, 16:40	+2 +/–
Идея старая и привлекательная. Решает много задач. Если иметь ядро OS которое паралельно, асинхронно может работать на разных ядрах CPU то: 1. Нет необходимости писать гипервизор. Виртуализация это свойство самого ядра. 2. Нет необходимости писать кластер единого системного образа (SSI). Отдельные ядра на разных компах могут взаимодействовать между собой так же как и на одном многоядерном проце. 3. Говорят это облегчает написание ПО для NUMA систем. Фактически это замена NUMA. 4. Говорят такое ядро будет намного безопаснее. Изоляция приложений выполняемых разными ядрами OS на разных ядрах CPU будет как в виртуализации. Здесь надо внимательно смотреть на реализацию SMP и межядерного взаимодействия. Ядра OS исполняемые на разных ядрах CPU между собой взаимодействуют по специальному внутреядерному протоколу. Падение или взлом одного ядра не приведет к падению или взлому других ядер. 5. Говорят такое ядро может быть более быстрым и асинхронным по типу LWKT.  DrugonFlyBSD имеет такое ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #51

34. Сообщение от Аноним (34), 26-Авг-26, 16:42	+2 +/–
Отказались от микроядер, но зато породили вот это
Ответить | Правка | Наверх | Cообщить модератору

35. Сообщение от tkzv (ok), 26-Авг-26, 17:01	+/–
То есть самое нижнее ядро работает гипервизором?
Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Аноним (36), 26-Авг-26, 17:08	+/–
Кто скажет для чего они это сделали?
Ответить | Правка | Наверх | Cообщить модератору

37. Сообщение от Аноним (37), 26-Авг-26, 17:11	+/–
Взлетит если запилить под это runk. Отгрызть у контейнеров нишу не получится, у KVM на хостинге таки да.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

38. Сообщение от Аноним (38), 26-Авг-26, 17:16	+1 +/–
Вы пьяны?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

39. Сообщение от Аноним (38), 26-Авг-26, 17:17	+/–
Или переопохмелились?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #48

46. Сообщение от _ (??), 26-Авг-26, 17:56	–1 +/–
Ну то есть hypervisor всё таки есть? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #64

47. Сообщение от Chromium (ok), 26-Авг-26, 19:04	+/–
Надеюсь, это добьёт Googlebook и Chromebook с их конченными виртуалками
Ответить | Правка | Наверх | Cообщить модератору

48. Сообщение от _ (??), 26-Авг-26, 19:20	+/–
А ты не в курсе последних треЭндов холливуда? А там такое _уже_ ... ту фаст ту фуриос новые выходят и там главная роль у чувака который _уже_ умер, но за чью морду на экране немамонты - заплатят :( Так что быть пьяным - ещё и очень неплохой вариант ... :-\
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #63

49. Сообщение от _ (??), 26-Авг-26, 19:23	+/–
Нет не взлетит. Там в самой идее - дыра. А уж в реализации (если реализуют) ... И ведь надо ещё на руст переписать, кстати! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

50. Сообщение от Аноним (50), 26-Авг-26, 19:25	+/–
Хорошая инициатива. Пусть ещё сделают безшовную миграцию приложений с одного ядра на другое, чтобы апдейты накатывать без ребута.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #66

51. Сообщение от Аноним (51), 26-Авг-26, 19:31	+/–
> 4. Говорят такое ядро будет намного безопаснее. Изоляция приложений выполняемых разными ядрами OS на разных ядрах CPU будет как в виртуализации. Здесь надо внимательно смотреть на реализацию SMP и межядерного взаимодействия. Ядра OS исполняемые на разных ядрах CPU между собой взаимодействуют по специальному внутреядерному протоколу. Падение или взлом одного ядра не приведет к падению или взлому других ядер. осталось такой CPU найти :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #65, #69

52. Сообщение от Аноним (51), 26-Авг-26, 19:33	+/–
куда там до FS, там вероятней L3 кеш общий уже :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

53. Сообщение от Аноним (53), 26-Авг-26, 19:51	+/–
>пока сидишь на одном ядре, на другом майнят, а ты и не замечаешь. Не нужно свои влажные фантазии выплёскивать на впопенет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

54. Сообщение от вах (ok), 26-Авг-26, 20:00	+/–
Все ждут микроядро и контейнеры!
Ответить | Правка | Наверх | Cообщить модератору

57. Сообщение от Аноним (57), 26-Авг-26, 21:10	+/–
Новое - это хорошо забытое старое. Распределённая на несколько ядер операционная система - это не новинка. Есть повод перечитать старые книжки Таненбаума.
Ответить | Правка | Наверх | Cообщить модератору

58. Сообщение от Аноним (65), 26-Авг-26, 21:52	+/–
Анархия какая-то. Как мониторить потребление ресурсов соседом? Пускать второе ядро как часть своего?
Ответить | Правка | Наверх | Cообщить модератору

59. Сообщение от Аноним (65), 26-Авг-26, 22:00	+/–
Что исправил? Человек сказал, что Количество ограничено числом ядер. Гипервизор позволяет создать много больше: Некоторые из них полуспящие и не влияют на производительность остальных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

60. Сообщение от Аноним (65), 26-Авг-26, 22:02	+/–
И здесь не защищает, так как эту функцию ядра будет брать на себя общее нижнее ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

61. Сообщение от Аноним (65), 26-Авг-26, 22:14	+/–
Вероятно, сведется всё к собственному формату изоляции вместо обще-специфицированного через VM. Плюс отсутствие полноценного гипервизора будет неуправляемость. Ну или ранний рудкит хостового ядра будет всё наблюдать...
Ответить | Правка | Наверх | Cообщить модератору

62. Сообщение от Аноним (65), 26-Авг-26, 22:17	+/–
> работают кооперативно и знают где чьё. Привет от Windows 95. Там тоже быда "кооперативная многозадачность" вместо вытесняющей NT технологии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

63. Сообщение от Аноним (65), 26-Авг-26, 22:26	+/–
> треЭндов tray End tree End try End Нехорошее словообразование.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #72

64. Сообщение от Аноним (65), 26-Авг-26, 22:34	+/–
Нет. Скорее /dev/sda = /dev/sdax где x - раздел версии ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #70

65. Сообщение от Аноним (65), 26-Авг-26, 22:40	–1 +/–
Да. Проектировщики ЦПУ были не в курсе новых техзаданий mklinux. )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

66. Сообщение от Аноним (65), 26-Авг-26, 22:56	+/–
А какая версия хостового ядра? Его всё равно надо менять. Так что только back port.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

67. Сообщение от Аноним (65), 26-Авг-26, 23:00	+/–
хостовое ядро тоже имеет версию. "Живая замена ядра" сводится "пускай эти приложения пока поживут на старой версии ядра"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

68. Сообщение от Аноним (65), 26-Авг-26, 23:04	+/–
>здесь ты не можешь "выйти из контейнера". Вы предлагаете софт решение заменить на аппаратное. Перекинут изоляцию на проектировщиков CPU и контроллеров? Они не будут этому рады и были не в курсе, когда проектировали существующие чипы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

69. Сообщение от maximnik0 (?), 27-Авг-26, 01:09	+/–
>осталось такой CPU найти :)) Формально arm и риск-5 с аппаратными контроллерами памяти и атрибутами памяти  таким требованиям отвечает.Правда я читал что сумели прочесть атрибуты на арм на процессоре без контроллера памяти .
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

70. Сообщение от _ (??), 27-Авг-26, 03:28	+/–
Но как Холмс?! (С) Как ты подружишь много ядер на одну железку? А никак! Поэтому и делают наоборот. Настоящую железку - гипервизору, а вм-ам ... sdax :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #71

71. Сообщение от _ (??), 27-Авг-26, 03:29	+/–
Короче - "весёлые картинки"(С) это всё. Расходимся поцоны!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

72. Сообщение от _ (??), 27-Авг-26, 03:31	+/–
ничОнезнаю(С), по нашему - по олбанске - вполне ничАго! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

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

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