> это приведет к тому что 99% юзеров просто не смогут заапдейтить bios
> и это будет эквивалентно тому как если бы в плату был запаян mask ROM.> А я как специалист по юзабилити говорю вам:
> 99% юзеров не дотянется до нужной перемычки.
если юзер не в состоянии переставить джампер,
самостоятельно перешить BIOS он тоже не сможет.
для этого нужно ведь переставить порядок загрузки в BIOS Setup,
сделать загрузочную дискету с DOS, положить туда флешер и образ
нового биоса, загрузиться с этой дискеты, запустить перепрошивку,
потом обратно вернуть последовательность загрузки в BIOS Setup.
[...]
>> я говорю сейчас не о качестве драйверов, а той проблеме, что любой
>> кривой драйвер может в любой момент заглючить всю операционную систему,
>> вместе со всеми прикладными приложениями и всеми несохраненными данными пользователя.
> Дык падеж многих из драйверов 1 фиг вызовет потери данных
> которые не были успешно обработаны драйвером.
потеря "данных", которые не успел обработать драйвер сканнера,
звуковой карточки, видеокарточки, принтера и т.п. - это не проблема.
>> если следовать этой логике,
>> тогда и прикладные программы надо вернуть на 0-й уровень привилегий,
> Не совсем так. Приложений много и они глючные.
> Ядра и драйверов не много, они маленькие, стабильные и подконтрольные.
количество подсистем ядра небольшое, они хорошо документированы,
для понимания логики их работы есть вся необходимая информация.
количество драйверов для различных устройств в ядре операционной системы
большое, еще больше их не входит в состав ядра, а поставляются отдельно.
понять алгоритм работы драйвера не имея полной спецификации оборудования -
очень трудно, часто оборудования документировано только частично, иногда -
вообще не документировано. многие драйвера сделаны через reverse engineering.
сейчас драйверов различной периферии уже много, со временем их количество будет
только увеличиваться, этот процесс будет идти по возрастающей, как снежный ком.
соотношение примерно такое:
count(subsystems) / count(drivers) ~= count(drivers) / count(applications)
subsystems - это подсистемы ядра, например, файловые системы, сетевые протоколы и т.п.
drivers - драйвера оборудования, который исполняются в ядре операционной системы.
applications - прикладные программы.
сейчас - ситуация со стабильностью и надежность работы операционной системы
вполне приемлимая. проблемы сейчас в другом - очень мало оборудования поддерживается.
поэтому со временем количество драйверов оборудования для Linux будет только
увеличиваться.
например, постоянное увеличение количества прикладных программ - это очень хорошо,
и никаких проблем с собой не несет. некорректная работа любой прикладной программы
никак не может повлиять на стабильность работы операционной системы и других программ.
постоянное же увеличение количества драйверов - это уже проблема стабильной работы.
если принять среднее количество ошибок в коде драйверов за константу, то при увеличении
количества драйверов, например, в 10 раз - стабильность работы ядра в среднем уменьшится
также в 10 раз. (при условии что все оборудование используется более-менее равномерно).
увеличится количество драйверов в 100 раз - стабильность работы операционной системы
также уменьшится примерно в 100 раз. например, через 10-20 лет для Linux может быть
выпущено в 1000 раз больше драйверов, чем их существует сегодня.
например, на эти грабли майкрософт уже наступила, потому что под Windows существует
гораздо больше драйверов, чем их существует под Linux. и это при этом, что kernel API
стабильно, существует огромное количество литературы, курсов, треннингов, примеров кода,
и т.п. всеравно, причина примено 80% BSOD операционной системы Windows NT/2K/XP/2K3 -
это кривые драйвера, которые исполняются в с привилегиями ядра операционной системы.
по сути, код сторонних, низкоквалифицированных разработчиков
имеет MS Windows NT/2K/XP/2K3, как любая прикладная программа имеет MS DOS.
>> чтобы разработчики стали очень внимательно
>> относиться к качеству и безглючности своего кода. я правильно понимаю?
> А это зависит от системы. В некоторых системах нет разделения кода
> на юзера и систему, ибо нафиг не надо (скажем любой сбой фатален
> и по этому поводу лучше сбросить систему для заведомо нормальной инициализации
> чем работать с возможно засранной памятью и некорректными данными).
> Обычно это небольшие системы где качественное тестирование
> может быть проделано для всего кода а не только небольшого ядра.
системы которые исполняются на микроконтроллерах, например, VxWorks
имеют такой дизайн потому что микроконтроллеры не имеют защиты памяти.
и практически по всем параметрам VxWorks хуже QNX. особенно в тех
случаях, где нужна максимально возможная надежность и устойчивость.
например, маршрутизаторы Cisco серии CRS-1 и 12000 построены
на основе QNX, это между прочим, microkernel-based operating system.
>> полный доступ абсолютно ко всему железу любому драйверу -
>> не нужен для выполнения его узкоспециализированных задач.
> Ага, но только на уровне железа оно как-то не особо то здорово поддержано.
99% персональных компьютеров используют процессоры Intel,
или совместимые с ними по наборам команд. на уровне железа
разграничение доступа к оборудованию поддержано просто отлично.
позволю себе напомнить, что мы говорим о проблеме в контексте
прихода Linux на десктопы, основным сдерживающим фактором здесь
является отсутствие драйверов ко всему этому зоопарку оборудования.
написать быстро, качественно и бесплатно несколько десятков тысяч
драйверов к различному оборудованию, часто без наличия документации
- это практически нереально. пока что это делается не быстро.
если будет быстро - тогда это будет сделано некачественно.
> Да и честно говоря не видел я как-то драйверов
> которые портят жизнь чужой железке, это уж совсем клиника.
у тебя просто нет возможности об этом узнать, потому что падать и глючить
в этом случае будет не тот драйвер, который является причиной сбоев,
а тот драйвер и та железка, которые не являются причиной проблем.
еще одна неприятная ситуация - это когда драйвер просто тупо портит
память ядра операционной системы. и тогда проблемы могут проявиться
любым способом - от внезапного зависания или перезагрузки до разрушения
файловых систем, или нарушения целостности данных любой прикладной программы.
>> лично мне например, не жалко несколько процентов производительности процессора
> Есть подозрение что при большом числе прерываний
> там будут не несколько % процессора.
на десктопе процессор в среднем загружен на 3-5%.
он всеравно проистаивает, а так - мог бы работать обеспечивая дополнительную защиту.
>>для того, чтобы получить более стабильную и защищенную от сбоев операционную систему.
> ...с глюкавыми дровами которые теперь будут писать те же индусы что и остальное.
глючащий драйвер звуковухи, сканера, модема, принтера, или wi-fi адаптера -
это серьезная проблема, если он время от времени будет ронять операционную систему,
и совсем не конец света, если глюки этого драйвера изолированы, и не могут повлиять
на остальные части ОС.
>> преимуществом будет возможность не потерять не сохраненные данные,
>> и большая защищенность и стабильность работы системы.
> Ага.Особенно если накрылся драйвер контроллера диска например =)
различных контроллеров жестких дисков - очень мало.
драйвера для них уже написаны, отлажены и работают.
проблема с другими драйверами - для всего этого зоопарка различной
периферии, которой очень много и к которой сейчас у линукса драйверов нет.
> Да я просто думаю что тормозов добавят, рас3.14..и дровописатели
> станут писать дрова более халтурно
если производитель оборудования пишет драйвера - он является наиболее заинтересованым
лицом, чтобы эти драйвера работали максимально надежно и стабильно. ведь от этого напрямую
зависит возрастание количества продаж и соответственно, увеличение лично его прибыли.
> и в итоге будет веселая картина: система тормозит, дрова грохаются
> не реже апликух, но оно таки не дохнет совсем, имитируя какую-то деятельность.
"система тормозит" на любом медленном процессоре. если процессор имеет 4, 8
или больше ядер затормозить такую операционку дополнительной нагрузкой ядра
даже в 10-15% очень трудно. всеравно на десктопе больше 90% ресурсов CPU
не используются.
>> для возможности найти и устранить причину падения -
>> надо как минимум снять и сохранить дамп памяти.
> А регистры?
и регистры тоже. и состояние стека. это разве не очевидно?
[...]
>> ислючения только подтверждают правило. если раком встал центральный
>> процессор - тогда действительно, операционная система уже мало что
>> может сделать. если этот процессор в компьютере был только один...
> Ядер два, а фигли.
Вы понимаете разницу между терминами "два ядра" и "два процессора"?
>> уровень понимания архитектуры IA32 очевиден. дальше можно не продолжать.
> :) так написано же - ламер. В IA32 я вполне себе он и есть.
это я уже понял... а откуда такая враждебность к Таненбауму и microkernel-based OS ?
ведь в плане надежности, устойчивости работы до QNX большинству ОС еще очень далеко...
PS на всякий случай: "ограничение полномочий доступа драйверов устройств",
и "микроядерная архитектура операционной системы" - это не одно и то же.
PPS у меня сейчас мало свободного времени, чтобы переливать из пустого с порожнее.
и уж меньше всего я хочу тратить свое время на то, чтобы спорить с "ламерами".
