О, первый внятный ответ.> Микроядро породит неизбежные проблемы IPC взаимодействия между процессами, что более медленно
> из-за частой смены уровней привелегий в рамках процессов и сохранения контекста
> вызовов.
Счас что просто переключить окно в иксах - столько всего происходит и такая куча процессов взаимодействует - и ничего.
Так что, пока что думаю, что это просто пугало.
Да и есть примеры успешных микроядер (QNX, VxWorks и т.д.), и даже с иксами.
> Интерфейсы механизма IPC между процессами и микроядром только сложнят код
> и породят ещё больше ошибок.
Кода станет больше. Это да.
Но всё как раз упроститься: есть исходники одного сервиса, другого и т.д. А есть исходники интерфейса, общего для всех.
Как раз так сейчас и живёт юзер-левел: каждая прога - в отдельной дире исходников - никто в обморок не падает, что фаерфокс это одни сырцы, а иксы - другие.
Слышали про "разделяй и властвуй"? - Микроядро о этом. Так что, код станет как раз проще: есть интерфейс, одна сторона реализует, другая использует.
Количество ошибок - может и увеличится (поначалу) - возможно. Но это не вся правда. Ведь в микроядре сырцы ж принадлежат к разному уровню доступа. И критичным будет именно код самого микроядра и пары неотъемлемых сервисов - это несколько десятков тысяч строк (а не неск миллионов, как сейчас). Вылизать десятки тысяч строк несказанно проще, чем неск миллионов. Так что, число КРИТИЧЕСКИХ ошиок будет стремиться к нулю. А некритических - они будут уже некритичны. Что и требовалось.
> При этом не нужно забывать, что
> ядро Linux имеет хорошую модульность и продуманную архитектуру, не смотря на
> монолитность, в угоду простоте и скорости работы.
Речь о безопасности и надёжности сейчас, а не простоте и скорости.
Эта самая "продуманная" архитектура порождает проблемы, как в данном посте. (левый модуль ведёт к локаруту!) Так что, давайте не будем о продуманности...
> проблема в устаревшей технологии программирования ... как бритьё
> с опасным лезвием.
Да, это согласен. Как-то бы ближе к каким-то шаблонам в коде - было бы больше самоконтроля в модулях.
Но это просто понижает вероятность подобных проблем, но не закрывает вопрос.
> Взять Rust.
> ... безопасность заложена концептуально в основу языка, при этом язык по
> настоящему системный, с прямым и безопасным! доступом к памяти, благодаря умным
> runtime указателям и деструкторам, которые подчищают неиспользуемую программно память,
> используя подсчёт ссылок
И заметьте, эти накладные расходы Вы не относите на счёт падения производительности, как то делаете по микроядреному IPC.
Почему?
> На Rust можно безопасно писать любые системные программы - драйверы...
Но как совершенно очевидно, любая безопасность значит доп. проверки, что требует доп. ресурсов, но эти затраты Вы снова не отмечаете. Стереотипы? Дескать где-то кто-то сказал, что "микроядро - это тормозно", а "руст - это круто, стильно, модно". Но нужно же реально оценивать все + и - всех подходов.
> можно даже своё ядро написать
Ну, тут ничего уникального в русте нет. Даже на жабоскрипте в браузере сделали вирт машину, на которой крутится немодифицированный пингвин.
> проект микроядерной ОС Redox на Rust уже есть.
> https://redox-os.org
> https://github.com/redox-os/redox/
Да, интересно. И заметьте: микроядро. Они не боятся тормозов?
