Previous Entry Share Next Entry
2016-01

про микрокернелы и linux

ну или просто про микрокернелы.

http://blog.darknedgy.net/technology/2016/01/01/0/ вот тут есть чудесный разбор заблуждений на тему микрокернелов, а еще там довольно неплохо проиллюстрировано, как много этих заблуждений посеяно Торвальдсом.

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

This entry was originally posted at http://wizzard.dreamwidth.org/466077.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
mudasobwa March 13th, 2016
Слушай, ну два фрика ведь плохо опровергают успех. Я вот почему-то думаю, что у гугла был ресурс на андроид.

wizzard0 March 13th, 2016
я не уверен, что понял твою мысль, можешь переформулировать?

vissarion March 13th, 2016
Имелось ввиду, что у гугла было полно денег, времени и людей, чтобы андроид сделать по-нормальному.
Писали андроид с нуля (начало разработки - 2005, первый релиз - 2008 год)
Но почему-то они выбрали не микроядро, а линух.

mudasobwa March 13th, 2016
ага

mudasobwa March 13th, 2016
спасибо

mbr March 13th, 2016
Лулз в том, что, оценочно так, большая часть современных андроидофонов работают на микроядре (vxVorks либо развитие L4 у кваллкома), поверх которого работает виртуализированный linux, поверх которого уже стоит андроид.

wizzard0 March 14th, 2016
есть еще андроид внутри xen for ARM, у меня есть такой девайс

mbr March 14th, 2016
Ну там пофигу на чем андроид поднять. Под linux проще и быстрее, вот и все преимущества.

mudasobwa March 13th, 2016
Гугл мог ведь выбрать любую ос, мог нанять индусов написать с нуля, etc.

Есть до хрена последователей Танненбаума.

А живет и процветает не то, что ты и этот фрик
по ссылке предлагаете.

vissarion March 13th, 2016
Более того, был уже готовый, опенсурсный, прекрасный, и надёжный микроядерный симбиан к тому же аж реального времени.
Сказка, ему бы жить, процветать да радоваться.
А вот уже три года как похоронили с позором и кроме плохого про него нечего вспомнить.
Можно, конечно, говорить что это сама ос прекрасная, но это тупорылая нокия c не менее тупорылыми Samsung, Motorola и Sony Ericsson её загубили.

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


Edited at 2016-03-13 10:07 am (UTC)

wizzard0 March 13th, 2016
Симбиан, э, насколько я помню, имел implementation problems. Похожие, кстати, на Хаскелевские.

vissarion March 13th, 2016
Вспомнить другие микроядра без слёз не получается.
GNU Hurd - этот позор начал разрабатываться еще когда был СССР
Minix, хотя он надёжен с 1987 года, никто использовать кроме своего автора за 30 лет не осмелился
QNX - блэкберри разорился немедленно после того как купил QNX

Конечно, это всё случайности и происки монолитно-гибридных врагов, однако осадочек остается.
Микроядрам не хватает хорошей Success Story.

justy_tylor March 13th, 2016
Но Торвальдс сеет ведь не просто так
Ведь если микрокернел рулит
То виден Торвальдса хуяк-хуяк


Edited at 2016-03-13 03:25 am (UTC)

mbr March 13th, 2016
В Эмбеде в основном микроядро (или его вариации) и используется. Для десктопов и серваков - монолит. Потому как на реалтайм пофигу, а проектирование сильно проще. Собственно поэтому линукс стал полноценной системой, а миникс так и не вылез из академических задач.

Ряд заблуждений он действительно посеял, но это чистый маркетинг - кто разбирается в вопросе, просто игнорирует. С другой стороны, в линуксе огромнейшее количество оригинальных архитектурных решений. Я бы не сказал, что это тормозит развитие ОС, скорее наоборот. Некоторые вещи я честно заимствовал для разработки своей ОС - те же SLUB например.

Вот как один из вариантов заблуждений - то что микроядро медленное. Ноги растут, емнип, из MIT наработок. Пацаны запихнули проверку секьюрити при IPC непосредственно в контекст исполнения супервизора. Естественно оно сдохло, разработку свернули.

wizzard0 March 13th, 2016
Ну да, всё так.

vissarion March 13th, 2016
Этот вопрос уже перешел из технологической плоскости в филосовскую.

Идеальная концепция против плохой, но реальной.

Все знают что Haskell - самый лучший язык в мире, но Facebook ($50млрд кэшем) и VK почему-то написаны на PHP.

Все знают (и даже сам Торвальдс) что микроядра лучше, но 99.9% почему-то используют гибрид.

Это из серии "если ты такой умный, то почему ты не богатый"

wizzard0 March 13th, 2016
Не, ну в эмбеде зажило вот. И да, хаскель не лучший язык by any means (например, в нем все еще нет нормального пакетного менеджера, какого-то style guide, с IO вопрос не решен (хотя третья инкарнация в лице free monads дают некоторые надежды) и регулярно появляются breaking changes в stdlib :)

vissarion March 13th, 2016
Какой язык лучший, на ваш взгляд, если не хаскель?
Без ёрничания и шуточек, действительно интересно.
Вот скажут "вот вам анлимитед тайм, анлимитед мани, любая технология, напишите нам Фейсбук (ну или gmail или SAP)". Вы что выберете ?

maxim March 13th, 2016
Я бы свой язык сделал и ОС. Если анлимитед мани, чо.
Ха-ха, да мы и так это делаем!

Edited at 2016-03-13 12:13 pm (UTC)

vissarion March 14th, 2016
С какими принципами был бы язык?
Динамическая типизация или статическая?
Интерпретируемый или компилируемый?
Функциональщина или со стейтами?
Чо как там насчёт потоков?


maxim March 14th, 2016
По всем вопросам ответ — положительный :-)
http://groupoid.co/exe.htm

Edited at 2016-03-14 02:24 pm (UTC)

maxim March 13th, 2016
всмысле нет пакетного менеджера? А cabal и stack — это что?
Брекинг ченджес всегда будут.

Edited at 2016-03-13 12:36 pm (UTC)

nivanych March 13th, 2016
Через N лет, с проникновением в индустрию более других языков, ситуация ещё изменится.

maxim March 13th, 2016
Самое охуенное, что я видел из написанного на С/C++ — это BeOS/Haiku: http://kernel-being.livejournal.com/2226.html
Еще NT Kernel могу читать, BSD хуйню с трудом. Linux днище.
Остальное за пределами квалификации.
А все эмбеддед красивые потому что маленькие.

Edited at 2016-03-13 01:35 pm (UTC)

vissarion March 13th, 2016
Мда, за 6 лет продвинулась с Alpha 2 до Alpha 4.

maxim March 13th, 2016
Там ебанаты одни остались. Аксель и ребята вышли на работы, детей кормить надо! Проект остался в руках у неквалифицированных. Начали пилить менджер пакетов с лейеред файловой системой с зацикливаниями и переписывать все что видят на С++. Минимализм закончился. Наимпортировали Питонов в базовую систему и т.д. Я когда-то ее горячо любил и даже написал был системный Haiku Chat.

Edited at 2016-03-13 02:16 pm (UTC)

ex0_planet March 13th, 2016
Торвальдс? А почему тогда сразу не Кернигана и Ричи во вредители записать? Идеологию (файлы, процессы, пайпы... вот это все) заложили именно они.

Преимущества линукса последние лет 10-15 скорее не технические, а административно-организационные. Вместо того, чтобы иметь в каждой мелкой лавке свое говноядрышко со своими специалистами, никуда больше не пригодными, своими тараканами и мелкими амбициями итд итп, мы имеем хоть как-то унифицированную систему знаний в головах.

wizzard0 March 14th, 2016
Торвальдс пропагандирует worse is better; а K&R про другое совсем.

и да, worse is better местами дает административные преимущества

ex0_planet March 14th, 2016
Да они все в общем-то из одной среды, которая worse is better. Собсно, юникс рождался как раз как worse-is-better вариант мультикса.

ex0_planet March 13th, 2016
Алсо, нельзя ли раскрыть тему про "навредил"? Ну вот не было бы линукса (и BSD тоже бы не было), и что? Мне вот как-то он не представляется всепожирающим монстром, душащим на корню все прорывные разработки — душат скорее сами разработчики, когда сравнивают стоимость написания своего, сколь угодно инновационного, и стоимость взятия готового и дотачивания под задачи.

ПМСМ, отсутствие до недавнего времени нормальной аппаратной виртуализации навредило гораздо сильнее.

wizzard0 March 14th, 2016
> отсутствие до недавнего времени нормальной аппаратной виртуализации

ну х86 кто только не обсырал ;)

ex0_planet March 14th, 2016
А её примерно нигде не было, исключая сантехнику и ибм. Но вообще с процессорами меньше всего проблем, там можно "договориться" и паравиртуализировать все. Вот с периферией беда...

vissarion March 13th, 2016
Мне кажется, вопрос этот важен в другом ключе.
Сейчас популярна волна microservices с теми же идеями.
Типа делать один сервис с методами getCustomers и getOrders это плохо.
Мы всех обманем и сделаем на одном серваке сервис customers с методами get и put и на втором серваке сервис orders с методами get и put. Отлично, всех обанули.
Теперь пришёл новый фичареквест - показать всех кастомеров со всеми их ордерами.
В моноядре мы бы сделали тупой джоин, признались себе что это криво, закрыли тикет и пошли домой.
В микросервисах начинается фигня - получается, что для каждого кастомера возвращаемого в поиске надо дёрнуть другой сервис - ордеров. Дёрнуть не проблема - проблема в том что всё это тормозит, т.к. сервис ордеров находится на другом хосте. Кое-как сделали.
Потом приходит новый фичреквест - что теперь нужно проверять права юзера для каждого запроса и не показывать тех кастомеров, которых не полагается видеть и не показывать те ордера которые не положено.
Фигня в том что securitymanager у нас идёт третьим, отдельным микросервисом который проверяет права пользователя
После этого начинается трэш угар и содомия и проклятия в сторону микроядра, дебажить это становится невозможно, после чего проект закрывается и пишется нормально без выкрутасов и нормально идёт в лайв.

Я сам принимал в этом участие, почувствовал на собственной шкуре лет 7 назад была популярна идея BPEL/wsdl: пишем отдельные сервиса с wsdl интерфейсом а микроядро BPEL ими дирижирует, в сущности то же самое.

В оригинале у Линуса написано так (в Русском переводе):

...Предполaгaется, что вы рaзбивaете проблемы нa тaкие мелкие чaсти, что вся сложность пропaдaет.
Мне это кaзaлось глупым. Дa, кaждaя отдельнaя чaсть получaется простой. Но при этом их взaимодействие стaновится горaздо более сложным, чем при включении рядa сервисов в состaв ядрa, кaк это сделaно в Linux. Предстaвьте себе человеческий мозг. Кaждaя его состaвляющaя простa, но их взaимодействие преврaщaет мозг в очень сложную систему. В этом-то все и дело: целое больше чaстей. Если взять проблему, рaзделить ее пополaм и скaзaть, что кaждaя половинкa вполовину проще, то при этом вы игнорируете сложность интерфейсa между половинкaми. Сторонники микроядрa предлaгaли рaзбить ядро нa пятьдесят незaвисимых чaстей тaк, чтобы кaждaя чaсть былa в пятьдесят рaз проще. Они умaлчивaли о том, что взaимодействие между чaстями окaжется сложнее исходной системы - при том, что и чaсти сaми по себе не будут элементaрными.


Мне кажется, Линус до сих пор прав.

anonim_legion March 13th, 2016
Что-то мне это напоминает.

Стена кода на дельфи в обработчиках нажатий кнопок
vs
У нас было 2 лог-таргета, 75 фабрик, 5 обсерверов, пол-исходников юнит-тестов и целое множество классов всех сортов и расцветок, автомаппер, а также стратегии, фасады, подписчики, куча boilerplate и 2 дюжины сервисов. Не то чтобы это был необходимый запас для энтерпрайз-приложения, но если начал собирать ООП-дурь, становится трудно остановиться. Единственное, что вызывало у меня опасение — это IoC. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем IoC-зомби. Я знал, что рано или поздно мы перейдем и на эту дрянь.

wizzard0 March 14th, 2016
дык.... микросервисы, акторы и микрокернелы сами по себе ничего не решают, это всего лишь один из кирпичиков, к которым нужно еще дохрена всего тащить (ну, как с мультитредингом вместо ускорения singlethread, например)

я всем пиарю блог joe duffy про Midori/Singularity ( http://joeduffyblog.com/ ), там написано как много всего надо втаскивать в скоуп чтобы оно как-то жило

да и вообще тулзы для дебага любой асинхронщины людьми которыми может пользоваться не только Лампорт появились от силы пару лет тому назад, с распространением промисов в браузерах %)

vissarion March 14th, 2016
Почитаем блог, спасибо

maxim March 14th, 2016
Просто микросервисы не для биг даты. Для служебных сервисов BPEL и микросервисы рулят. Фактически все популярные HTTP API в интернете на них построены. Если нужна аналитика и аггрегации — это другими средствами должно решаться. Как минимум должна быть распределенная база данных. Например Riak as a Service. Надо было всех уволить :-)

Edited at 2016-03-14 08:53 am (UTC)

109 March 14th, 2016
> для каждого кастомера возвращаемого в поиске надо дёрнуть другой сервис - ордеров. Дёрнуть не проблема - проблема в том что всё это тормозит

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

  • 1
?

Log in

No account? Create an account