Comments 40
Майки - красавцы) Вместо того, чтобы бросить силы на устранение причин появления этого экрана, они отдают ресурсы на рисование) То одним цветом покрасят, то другим) То надписи изменят :)
Ну, причины уже давно за пределами их контроля, время когда винда падала сама по себе прошло. Падают драйверы от сторонних производителей. Тут только на микроядро переходить, но это наверняка очень сильно ударит по производительности.
Микроядро реально не спасает в случае серьёзных сбоев: если упало что-то критически важное, то просто взять и перезапустить его нельзя, ведь причиной падения вполне могут стать кривые данные этого самого критически важного -- а их инициализировать заново, опять-таки, нельзя, поскольку они критически важны для работы системы (скажем, очереди запросов ввода-вывода, списки процессов и потоков и т.п. вещи). В реальности микроядерных систем, как это понималось изначально, вероятно, не существует. У той же QNX от изначальной идеи микроядра остался лишь вынос драйверов в отдельные процессы; все остальные функции традиционного ядра ОС (управление процессами, потоками, памятью, синхронизация и т.д. и т.п.) де-факто находятся в одном адресном пространстве и не защищены друг от друга. Но вынос драйверов или их частей возможен и в Винде; более того, часть драйверов и работает сейчас в пространстве пользователя. Скажем, бОльшая часть кода, относящегося к ГПУ, уже не часть ядра, и сбои в нём приводят лишь к падению определённых приложений (игрушка, например, вылетит), а не всей системы в целом.
У той же QNX от изначальной идеи микроядра остался лишь вынос драйверов в отдельные процессы
Но ведь для защиты от кривых драйверов ровно это и требуется?
Скажем, бОльшая часть кода, относящегося к ГПУ, уже не часть ядра, и сбои в нём приводят лишь к падению определённых приложений (игрушка, например, вылетит), а не всей системы в целом.
Если честно, то лучше бы вылетала вся система. Потому что от работающей системы мало толку когда недовылетевшая полноэкранная игрушка вызывает перезагрузку графической подсистемы в вечном цикле, не давая даже открыть диспетчер задач.
macOS с микроядром вроде бы как не уступала по производительности Windows на одинаковом железе.
Что-то не верится в микроядерную макось, и Википедия со мной согласна. Есть у вас какие-нибудь источники?
МакОсь, насколько знаю, -- не микроядерная. Насколько помню, Mach там хотя и типа является микроядром, но вся реальная работа по обслуживанию обращений прикладных программ к системе выполняет подпиленное ядро от FreeBSD -- только оформленное как задача под управлением Mach, а не как собственно ядро. Т.е. формально можно заявить о микроядерности, но фактически реальное ядро -- это один большой модуль, а не куча изолированных друг от друга мелких задач. Т.е. полная профанация самой идеи микроядерности.
И, кстати говоря, то, что система А превосходит систему Б по производительности, не говорит о том, что базовые концепции системы А лучше концепций системы Б -- очень немаловажную роль играет качество реализации обеих систем. И относится это, естественно, не только к макоси и винде, а вообще ко всему.
Архитектура macOS (точнее, OS X, как она называлась во времена реализации на Intel) в целом описана здесь. Как видно, драйверы находятся снаружи микроядра Mach, и это то, о чём шла речь. Каждый драйвер при этом является отдельным динамически загружаемым модулем. Хотя адресное пространство kernel space общее у всего ядра XNU/Darwin (в отличие от изначального Mach вне Apple), но Вы ж понимаете, что само по себе адресное пространство не говорит о принадлежности к ядру или микроядру. У нашей любимой OS/360 адресное пространство вообще было одно на всех, что не говорит о том, что пользовательские задачи там были частью ядра.
И я отвечал именно на реплику о производительности. А о том, чьи там базовые концепции лучше или хуже, можно говорить отдельно, если сначала договориться о критериях.
Люди, которые пишут о том, что macOS не микроядерная, имеют в виду, что в изначальном Mach модули "макроядра" обменивались сообщениями только через микроядро, а в macOS имеют общее адресное пространство, что позволяет им передавать данные непосредственно друг другу, не инкапсулируя их в сообщения Mach. Я думаю, Вы согласитесь, что само по себе это на самом деле не принципиально для рассуждений о микроядре.
Можно сказать, что ранний Mach был экстремально микроядерным, представляя голую концепцию со всеми присущими ей плюсами и минусами, а в macOS микроядерная архитектура была оптимизирована до приемлемого к практическому использованию компромиссного вида.
Я думаю, Вы согласитесь, что само по себе это на самом деле не принципиально для рассуждений о микроядре
Не соглашусь. Дело не в едином адресном пространстве как таковом, а в отсутствии защиты областей, логически принадлежащих разным, скажем так, подсистемам (в упомянутой OS/360 отдельные пользовательские разделы и, тем более, области системы были защищены с помощью ключей, о чём Вы прекрасно знаете, поэтому общее адресное пространство не создавало проблем со взаимным вмешательством -- точней, не создавало бы, если бы не определённые дыры в самой ОС, но это уже вторично). Если, скажем, управление процессами, управление потоками, управление памятью и управление вводом-выводом (без учёта драйверов) реально не защищены от взаимного вмешательства -- всё, это не микроядерная ОС. Вынос драйверов в отдельные защищённые адресные пространства микроядерной её не делает -- изначальная идея была именно в полной изоляции каждой подсистемы от всех других и об их общении исключительно через микроядро. Ну а сейчас и Винду временами микроядерной называют.
В общем, в моей терминологии (опирающейся на изначальную идею, без учёта последующей "инфляции терминологии") реальных практически используемых микроядерных систем не существует. Так что изначальная Mach -- да, таки микроядерная, но практически бесполезная из-за диких накладных расходов, связанных с многократными переключениями контекста и переходами между режимами пользователя и ядра, почему от этой концепции на практике и отказались. А термин, наверное, тащат с рекламными целями: типа, наше православное эппловское микроядро -- это надёжно, в отличие от монолита в этой вашей безблагодатной винде или еретическом линухе (хотя реально тоже монолит делают) :)
Если же отвлечься от конкретно макоси и прочая, то, думается, с приемлемыми накладными расходами микроядро можно было бы реализовать за счёт использования сегментации IA-32 или механизма адресных пространств ESA/370/390/z/Architecture, где очень многие вещи делаются на уровне железа, без необходимости программного вмешательства. Но сама идея мне представляется мертворождённой: она не может обеспечить подлинную надёжность, ведь падение, скажем, подсистемы управления потоками не позволяет просто загрузить её заново с диска и запустить: при падении могут быть похерены критически важные данные (или, скорее, само падение произошло из-за того, что они уже были похерены из-за какой-либо ошибки в коде), а соответственно, и надёжный перезапуск без полной перезагрузки системы не представляется возможным. Даже падение драйвера не всегда позволяет разумным образом его перезапустить (скажем, нельзя "принимать на веру" находящиеся в очередях запросы ввода-вывода и прочие управляющие данные, касающиеся этого драйвера). В общем, для упрощения отладки -- вещь полезная (легче ловить выходы за границы логически доступной памяти), для реального повышения надёжности -- в общем случае бесполезная (хотя и полезная в определённых конкретных случаях: скажем, держать компилятор шейдеров внутри драйвера видюхи, выполняемого в режиме ядра -- ну, такое себе решение).
На мой взгляд, Вы переоцениваете значение защиты памяти процессов ОС для микроядерной архитектуры. Если посмотреть хотя бы на Википедию в качестве сборника популярных мнений, то в русском разделе защита памяти даже не упоминается в числе преимуществ микроядра, а в английском - упоминается как необязательная характеристика. Микроядерная архитектура имеет все достоинства модульности независимо от того, обеспечиваются в ней раздельные адресные пространства для процессов ядра или нет. Кроме того, в macOS архитектура ядра построена на строго объектных принципах, и логическая защита процессов друг от друга обеспечивается инкапсуляцией. Довольно непросто на уровне объектной модели языка программирования высокого уровня случайно влезть в чужой объект. Думаю, что если мы засчитываем ключи защиты страниц (на которые каналам S/360 было наплевать) в качестве допустимого средства, то и объектная инкапсуляция будет не хуже.
В общем, это всё вопрос терминологии, но, как Вы верно заметили, микроядерных ОС в Вашем понимании фактически не существует, что дезавуирует сам термин в такой его трактовке.
Если посмотреть хотя бы на Википедию в качестве сборника популярных мнений, то в русском разделе защита памяти даже не упоминается в числе преимуществ микроядра, а в английском - упоминается как необязательная характеристика.
В том-то и дело, что от изначальной трактовки идеи отошли. Против модульных систем я, понятное дело, ничего не имею, но микроядерными их не считаю как раз потому, что они не имеют никаких принципиальных отличий с точки зрения надёжности работы, организации внутренних связей и т.д. и т.п. по сравнению с абсолютно монолитными.
Довольно непросто на уровне объектной модели языка программирования высокого уровня случайно влезть в чужой объект.
Кривые указатели никто не отменял, а без манипуляции ими действительно низкоуровневые вещи не сделаешь.
на которые каналам S/360 было наплевать
А вот тут Вы запамятовали: защита памяти ключами действует на каналы точно так же, как и на процессор, так что, если программа канала выполняется с ненулевым ключом (он указывается в CAW в момент запуска канальной программы), то залезть в чужую память не сможет.
что дезавуирует сам термин в такой его трактовке
Скорей, подтверждает мертворождённость самой изначальной идеи микроядерной ОС.
Вроде ключи в CAW появились только в S/370?
Скриншот из первой версии Принципов работы Системы 360, A22-6821-0.
Возможно, Вы спутали с тем, что сама защита ключами, как и интервальный таймер, в Системе 360 была необязательной (хотя де-факто присутствовала во всех "настоящих" моделях, кроме 30 и, может, 40 -- но и там была возможной, просто за отдельную плату).
BSoD в предварительных сборках Windows Vista
Нет, это ошибка загрузчика.
Но на нём будет указан код ошибки и проблемный системный драйвер. Это должно помочь IT-администраторам — им не нужно будет извлекать дампы памяти с компьютеров
Эти данные всегда были указаны, дампы памяти нужны для более подробного анализа сбоя.
Кто хочет проститься с BSOD по-настоящему:
в командной строке от имени администратора введем команду TASKKILL /IM svchost.exe /F
:)
Есть более лучшее предложение - кастомизировать экран смерти с возможностью выставить обои, например, "Безмятежность".
Your device ran into a problem and needs to restart.
Гораздо прикольнее было бы оформить BSOD вот так:
Ну, это нацелено лишь на СНГ. А мой вариант известен везде (собственно, он от "них" к нам и пришёл) и, самое главное, находится в стиле предлагаемого (цитату из которого я и привёл как референс).
Ну, мне Ваш вариант неизвестен вообще и я так и не понял, в чём его суть :)
Значит, у вас просто нет желания узнать это, ведь гуглёж "мем directed by..." выдаёт исчерпывающую информацию в первых рядах выдачи, даже электронный болван поисковика толкует всё предельно понятно.
И похоронную музыку из колонок.
Так я и не понял, чем им синий цвет не угодил)
В это же время Linux:
Куда мир катится.. :)
А что не так-то (кроме качества вашей картинки)?
«Синий экран смерти» — всё: Windows избавляется от BSoD спустя почти 40 лет