> По моему нескромному мнению системный софт просто не должен падать. Он при этом имеет потенциал терять данные или ронять систему. Даже если ядро останется живое - это еще не значит что периферия будет в состоянии нормально взаимодействовать с пользователем. Наиболее очевидный фокус - баг в драйвере GPU. Я пару раз видел и на монолите как отпадало само взаимодействие драйвер - железка. Само ядро при этом живое, а толку - нуль. А вы предлагаете такое еще и более часто встречать? Э нет, фатальное падение драйверов при удобном случае - отличный стимул писать их качественно и руками специалистов.Э нет, не греби все под одну гребенку и забудь про код без ошибок. Есть важные железки и функционал, а есть не очень, где и данные потерять не жалко. Видел давно как некоторое время мучались с подвисающим драйвером USB на среваке. Разделить все по разным сервакам было нельзя (наверное не было оборудования да и виртуальные сервера нормально на том железе не запустишь) и на одном линукс-серваке крутились корпоративный жаббер, почтовик и обслуживание нескольких USBшных вин-модемов, через которые клиенты подключались. И усб-модемы стабильно через какое-то время начинали по одному зависать, просто не поднимали трубку. Клиенты, естественно, недовольны. Начальник админа шпыняет чтобы он что-то сделал, а админ так просто "что-то сделать" не может - как я понял, на команды модемы не реагируют, а при попытке тупо выдернуть усб-шнурок и воткнуть его заново, равно как и выгрузить/загрузить соответствующий модуль ядра - тупо кернел паник. Т.е. только перезагрузка сервака спасала. А жаббер и почтовик на этом серваке тоже "ну очень важны". И админ мучался, оттягивал перезагрузку до последнего (пока хоть один рабочий модем оставался), а потом все-таки перегружал сервер (что вызывало большой шухер и оборванные телефоны). А было бы ядро не монолитное, а микроядерное, типа QNX, то наверное можно было бы просто тупо перезапустить сервис-драйвер работы с усб. Да, конечно, все работающие с усб программы получат ошибку, но их тоже можно перезапустить, зато все остальное работает - т.е. в данном конкретном случае ядро бы никуда не упало, сервер не перегрузился, жаббер и почтовик как работали так и продолжали бы работать, все модемы бы тоже заработали. Причем, наверное даже сработало простое передергивание усб-шнурка при кривом драйвере (которое в линухе на том железе выдавало кернел паник) - драйвер бы вызвал ошибку, система его перезагрузила и модем после втыкания шнурка начал работать со свежезапущенным процессом драйвера.
То же самое можно расписать и для обычной десктоп-системы. Вот представь - простой пользователь работает в офисном пакете. И одновременно слушает музыку. Уже не сохранялся давно. И тут серьезно глюканул некачественный драйвер звуковухи. В монолитном ядре - кернел-паник и потерянные данные. В микроядерном - просто убитый или перезапущенный процесс драйвера звуковухи, все остальное продолжает работать - т.е. в худшем случае пользователь останется без звука до перезагрузки компа, но система остается полностью работоспособной (кроме звука, если его не удалось восстановить простым перезапуском драйвера).
Т.е. важно различать важную периферию и не важную на конкретном железе решающем конкретные задачи. Желательно, чтобы пользователь системы мог рулить тем, какие подсистемы важны (и при сбое в них надо срочно останавливать всю систему), а какие второстепенные (при сбое можно просто перезапустить драйвер и заново проинициализировать железо). Т.е. на каком-то серваке наиболее важны дисковые подсистемы и сеть (при их сбое - остановка сервера), а видеодрайвер неважен, да и усб при зависоне можно передернуть, а какой-то сервер наоборот занимается тем, что выполняет сложные расчеты на видеокартах и сбой в драйвере видюхи для него критичен.
