Ну, Вам, как знатоку-гуглеводу, виднее -

https://www.xenproject.org/developers/teams/mirage-os.html

Mirage is an exokernel

(C)

#iResist (C)

Ну да, а NT - гибридное ядро.

#iResist

#KeepOn

Я про NT ни слова не говорил - сами утверждаете, сами и опровергайте -

https://ru.wikipedia.org/wiki/Бритва_Хитченса

А то, что OS/2 (есть ещё до сих пор такая самая надежная на сегодняшний день OS, ArcaOS называется) - гибридное, скажу.

Хотя в русской типа википедии сказано, что якобы «модульное».

---

Байка, хотя и вполне реальная -

https://www.anekdot.ru/id/442754/

https://bellamar.livejournal.com/405456.html

Смотрители кладбища, ага.

Ну да, а NT - гибридное ядро.

Я про NT ни слова не говорил

Зато ты много говоришь о «гибридных ядрах».

Ну, про Minix в каждом Intel уже сказали. А еще - Barrelfish, FreeRTOS, Integrity, QNX, Redox, ThreadX. И Fuchsia, да.

так победило ведь микроядро minix, верно? :)

К переходу с Шин9х на NT тоже скептически относишься?

Мне вот интересно — если микроядро взлетит, закроют ли вендоры драйверы?

Символы экспортированные из ядра линукс явно помечены можно ли их использовать из закрытого кода, или нет (EXPORT_SYMBOL_GPL или EXPORT_SYMBOL). В микроядре тоже можно так сделать, ведь это оно передает сообщения между сервисами, оно может проверять лицензии. Все будет зависеть от желания разработчика, архитектура не ограничивает.

А сейчас что открывают?

Символы экспортированные из ядра линукс явно помечены можно ли их использовать из закрытого кода, или нет (EXPORT_SYMBOL_GPL или EXPORT_SYMBOL). В микроядре тоже можно так сделать, ведь это оно передает сообщения между сервисами, оно может проверять лицензии. Все будет зависеть от желания разработчика, архитектура не ограничивает.

Не получится. Когда ты используешь ядерное API в своем коде, это считается derived work — потому что, грубо говоря, ты пользуешься ядром как библиотекой. Но если твой код работает независимо от ядра через IPC, то GPL не считает это за derived work и не требует открытия сырцов.

В качестве примера — в ядре есть подсистема FUSE, позволяющая писать файловые системы в Userspace. Никаких лицензионных ограничений на этот интерфейс нет и быть не может.

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

А сейчас что открывают?

Ну а ты зайди в drivers/ да посмотри.

Тот же Hurd пилят уже сколько лет, а воз и ныне там.

Проблемы Hurd не связаны напрямую с микроядром, а являются следствием безалаберной организации. Десять раз туда-сюда-обратно перекатывались с одного микроядра на другое, в итоге остались с интерфейсом межпроцессной коммуникации 20-летней давности, намертво ржавыми гвоздями приколоченным к 32 битам, замена которого фактически означает переписывание всего с нуля.

Вот это прямо в GPL так написано, что нужно напрямую/ненапрямую? Выходит, если я делаю jmp на чужой код, то это «derived work», а если syscall, то пофигу? А если я делаю jmp туда где уже до меня написали syscall? А если ядро будет каждому сервису отображать странички где уже написаны команды syscall и параметры, а сервис туда делает jmp, это ли не тоже самое что просто прилинковать монолит?

В лицензии разве есть технические детали? Если нет, то все получится, просто так договорились, значит можно и иначе договориться.

Вот это прямо в GPL так написано, что нужно напрямую/ненапрямую?

Да. Более того, там различаются понятия статической и динамической линковки (правда уже в LGPL).

Выходит, если я делаю jmp на чужой код, то это «derived work», а если syscall, то пофигу?

Системный вызов это программный интерфейс взаимодействия, он не лицензируется. А вот чужая либа ещё как.

А если я делаю jmp туда где уже до меня написали syscall?

Чо?

А если ядро будет каждому сервису отображать странички где уже написаны команды syscall и параметры, а сервис туда делает jmp, это ли не тоже самое что просто прилинковать монолит?

Интерфейсы программы (системные вызовы) не лицензируются. А код лицензируется. Чувствуешь разницу?

Интерфейсы программы (системные вызовы) не лицензируются. А код лицензируется.

Так понятнее. Еще вопрос, может ли ядро (или еще кто-то) требовать от драйвера указывать лицензию, и может ли драйвер лгать (не нарушая закона)?

Так понятнее. Еще вопрос, может ли ядро (или еще кто-то) требовать от драйвера указывать лицензию, и может ли драйвер лгать (не нарушая закона)?

В теории не может, но это как суд решит. Требовать права не имеют, но если лицензия не указана, это вообще public domain.

Хотя гоню, если лицензия не указана, то автор просто сохраняет все права на работу.

Когда ты используешь ядерное API в своем коде, это считается derived work — потому что, грубо говоря, ты пользуешься ядром как библиотекой. Но если твой код работает независимо от ядра через IPC, то GPL не считает это за derived work и не требует открытия сырцов.

Всё это большой вопрос, не проверенный в суде. Модуль NVIDIA использует ядро как библиотеку и пока законен. А при определении, является derived ли work, неважно, вызываются интерфейсы через инструкцию call или передачу сообщений.

Более того, там различаются понятия статической и динамической линковки (правда уже в LGPL).

Тоже не совсем так. Линковка играет роль только потому, что у пользователя должна быть возможность заменить LGPL-код, не затрагивая приложения. Каким видом линковки это достигается - неважно.

Всё это большой вопрос, не проверенный в суде. Модуль NVIDIA использует ядро как библиотеку и пока законен.

В ядре есть долгий срач на тему, считается ли блоб, который самодостаточен внутри, но зовет API ядра для минимального взаимодействия с ядром derivative work. Линус склонен считать, что нет, но вот GPL2 говорит совершенно об обратном.

А конкретно с модулем NVIDIA история интересная — они его не распространяют в собранном виде, и лицензии не нарушают в том числе и по этой причине.

А при определении, является derived ли work, неважно, вызываются интерфейсы через инструкцию call или передачу сообщений.

Насколько я знаю, практика такая, что если ты дергаешь чей-то код — то там есть о чем говорить, а вот если ты пинаешь софтинку через API, то ни о каком derivative work говорить не приходится. Иначе бы мы тут всех уже засудили за recvmmsg() в проприетарных JAVA аплетах. Если у тебя есть примеры обратного, было бы интересно почитать.

А конкретно с модулем NVIDIA история интересная — они его не распространяют в собранном виде

AFAIK, в несобранном виде там только интерфейс с ядром. Манипуляции собственно железом - двоичный код.

Насколько я знаю, практика такая, что если ты дергаешь чей-то код — то там есть о чем говорить, а вот если ты пинаешь софтинку через API, то ни о каком derivative work говорить не приходится.

В случае ядра ты написал «Но GPL2 говорит совершенно об обратном».

Если у тебя есть примеры обратного, было бы интересно почитать.

У меня нет примеров обратного, но когда-то я читал разъяснения GPL технарям. Так вот, весь этот техноспик вроде «динамической линковки», «API» и «передачи сообщений» - это шелуха. А суть в том, является ли произведение достаточно независимым, т.е. имеет ли оно ценность в отрыве от GPL-кода. И, я должен сказать, приличный линуксовый драйвер такой ценности не имеет.

В случае ядра ты написал «Но GPL2 говорит совершенно об обратном».

API в не в смысле код, а в смысле socket API какой-нибудь.

У меня нет примеров обратного, но когда-то я читал разъяснения GPL технарям. Так вот, вся эта техноспик вроде «динамической линковки», «API» и «передачи сообщений» - это шелуха. А суть в том, является ли произведение достаточно независимым, т.е. имеет ли оно ценность в отрыве от GPL-кода. И, я должен сказать, приличный линуксовый драйвер такой ценности не имеет.

Вот тут у Линуса и компании большие разногласия. Я могу сказать, что я лично работал с драйверами для FC адаптеров, которые были написаны и для венды, и для лялеха, а различался там исключительно оберточный код. В итоге драйвер имел ценность, отдельную от GPL кода, потому что очень неплохо работал и под вендой.

В случае ядра ты написал «Но GPL2 говорит совершенно об обратном».

API в не в смысле код, а в смысле socket API какой-нибудь.

Я имел в виду вот эту фразу:

kirk_johnson> блоб, который самодостаточен внутри, но зовет API ядра

Никогда не слышал о призывании API ядра через socket API.

Вот тут у Линуса и компании большие разногласия

Ядро, на самом деле, не под GPL2 - оно под GPL2+разрешение на бинарные модули. И юридически это отдельная лицензия.

Я могу сказать, что я лично работал с драйверами для FC адаптеров, которые были написаны и для венды, и для лялеха, а различался там исключительно оберточный код. В итоге драйвер имел ценность, отдельную от GPL кода, потому что очень неплохо работал и под вендой.

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

Никогда не слышал о призывании API ядра через socket API.

syscall — тоже API ядра. Или FUSE какой-нибудь. Просто термин знатно перегружен :)

Ядро, на самом деле, не под GPL2 - оно под GPL2+разрешение на бинарные модули. И юридически это отдельная лицензия.

Вот тут я бы очень хотел увидеть пруфы.

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

Ммм... ну как сказать — работал он хорошо, и для работы ему действительно хватало маленькой обертки сверху. Это, безусловно затрудняло дебаг, но никак не мешало драйверу работать.

Зато ты

Аргументация

https://www.youtube.com/watch?v=pFOBQQ6XcTM (С)

просто потрясает

Аргументация «сам дурак»(С) просто потрясает -

«Фигурное цитирование» (ц) банально до скуки.

Никогда не слышал о призывании API ядра через socket API.

syscall — тоже API ядра.

Под «API ядра» обычно подразумевается API, который ядро предоставляет модулям (stable API nonsense, ага). Сисколлы называют userspace API. Вот в случае микроядра это может быть один и тот же API (прикольно писать драйвер на POSIX).

Ядро, на самом деле, не под GPL2 - оно под GPL2+разрешение на бинарные модули. И юридически это отдельная лицензия.

Вот тут я бы очень хотел увидеть пруфы.

Пруфы тебе может дать только специально обученный юрист. Я за давностью лет не помню ссылки на статью, но про модифицированные лицензии - это не только мое мнение: https://opensource.stackexchange.com/a/6968, https://opensource.org/faq#variant-licenses, https://wiki.creativecommons.org/wiki/Modifying_the_CC_licenses

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

если придумают новую архитектуру памяти, то микроядро может и взлететь. А так - всё упирается в кеши, контроллер и прочую железячнину. Монолит и то в это упирается.

тоесть на сегодняшний день

для распространенных архитектур х86 и arm эффективнее монолит, а не микроядро?

Модуль NVIDIA использует ядро как библиотеку и пока законен.

Этот модуль ядра является прослойкой между непосредственно драйвером и ядром. Распространяется он в исходниках, и поэтому при установке он собирается и считается, что пользователь сам его собрал. Формально вроде бы всё чисто, но вроде никто и не пытался судиться.

Зачем же об этом думать, если можно знать? :)

Последние 15 лет понятие «микроядро» было извращено. Скажем так - микроядро имеет смысл если система построена на основе синхронных взаимодействий между процессами.

Касательно перспективности - всё уже давно придумано, улучшить нельзя, можно только ухудшить. Я говорю о L4-X2 - микроядре, которое опередило своё время.

насчет этого я читал твои посты и твой сай т. не понял я только одного, зачем процессор делать под микроядро. Нишевое решение, не факт что нужное.

Чтобы проверить некоторые идеи. Переключение контекста всё же дорогая операция, поэтому она просится быть реализованной аппаратно.

получается адоптация под существующие платформы дороже чем реализовать аппаратно?

На существующих платформах нет спроса на микроядра. QNX и VxWorks вполне покрывают все ниши.

тоесть Хамелеон и например Minix3 только для узкоспециализированных задач?

Это скорее концептуальные вещи. Чтобы довести их для практического применения, в них надо вложить десятки или даже сотни тысяч человеко-часов. Во всяком случае это справедливо для Хамелеона, насчёт Minix не скажу - не слежу за проектом. Слышал лишь что Интел использует Minix где-то в недрах Intel Management Engine.

тоесть, чтоб довести до продакшена Хамелеон (для использования на основых архитектурах), как ОС общего назначения, требуется очень много времени и затрат?

Конечно. Так это нужно для любого продукта, если ниша занята.

никаких чудес не показывала с её Фотоно (если не ошибаюсь - тоже сгинул), с точки зрения вендо-юзера.

Последние слова, видимо, ключевые: QNX, вроде бы, и не предназначалась для того, за что её могут оценить вендоюзеры. Хотя один мой коллега реально фанатеет.

Жду, когда допилят Hurd. Тогда можно будет сравнить с линуксом в более-менее одинаковых условиях.

Не нужно понимать, что это такое, чтобы заметить, что пилить микроядра горазд каждый, а вот переходить на них - нет.

А вот для того, чтобы понять, что не в скорости разработки дело, походу надо.

As to the whole «hybrid kernel» thing - it's just marketing. It's «oh, those microkernels had good PR, how can we try to get good PR for our working kernel? Oh, I know, let's use a cool name and try to imply that it has all the PR advantages that that other system has»
 — Torvalds

Это лет десять назад можно было «сравнить HURD с линуксом в более-менее одинаковых условиях». Не рекомендую ждать, разрыв-то увеличивается.

Я просто у приятеля увидел тот QNX, на излёте 90х, да посмотрел что там и как, вернее он там пару прожек запустил, меня скорость не впечатлила. Т.е. кроме фидо ничего не было, а инфу о qnx вообще из журнала прочитал, я ничего не понял. Вернее я ожидал от RT_OS какой-то реактивности, а оно там мне кино а-ля ПК под Шиндовс показует... тююю шо за надувательство? :-)))

Ну собсно и всё. (Если чо, нинада набигать и рассказывать про гарантированные наномикросекунды реакции на прерывания, это я читал позже или в то же время).

Если чо, нинада набигать и рассказывать про гарантированные наномикросекунды реакции на прерывания, это я читал позже или в то же время

Ну так в этом и суть — достоинство этой ОС не в скорости, а в гарантированном времени отклика. Я не то, что «набигаю», просто это действительно ОС для специфических хотелок, большинству пользователей винды или дефолтного линукса не очень интересных...

Ну вот так и происходит становление пользователей. Если на то время у меня ПК был год-два, и до этого я там не в зуб ногой.
Но освоившись и наметив ориентиры, сразу же критическое мышление включилось :-)