>>> на некоторых интеловских матерях можно убить boot block последовательностью команд
>>> специального вида. Это даже не BIOS, это bb, который во впаянной микросхеме,
>>> а не флэше/кроватке. Кажется, вне зависимости от архитектуры ядра.GM>> этот глюк в материнской плате очень легко устраняется,
GM>> выпуском новой версии PCB, или новой прошивки биоса.
??> Не давать перешить бажный бутблок извините, дебилизм.
...
??> Можно конечно хардварно решить вопрос - перемычку поставить на мамке,
??> запрет записи в бутблок. Только тут еще веселые грабли есть. Льете вы новый биос.
??> А старый бут с ним несовместим. Если флешер его не заапдейтит
??> (а при перемычке он реально не сможет...) - например все может взвиснуть
??> в момент когда бут отдает управление биосу. При этом чексумм валиден
??> и у бута нет причин не запускать биос. В итоге оказывается что приплыли.
??> Система оживляется только на программаторе.
проблема решается очень просто: флешер перед тем, как обновлять биос,
смотрит, удалось ли ему успешно обновить boot block, и только в этом случае
приступает к перепрошивке BIOS. если не получилось - завершается с сообщением про ошибку.
а каким именно способом защита бутблока сделана - перемычкой на материнской плате,
или опцией в биосе - это без разницы.
??> то что есть сегодня - это компромис при котором юзеры не особо интенсивно
??> ломают зубы при апгрейде и биосы не мрут пачками. Нормальный вполне компромисс.
в данном случае - это компромис цена/качество (hardware и software)
а не безопасность/производительность.
GM>> проблема с тем, что любой кривой драйвер может заглючить
GM>> всю систему - не имеет такого легкого и простого решения.
??> Имеет: просто не использовать кривые драйвера.
других драйверов нет.
??> Вы блин еще потребуйте дать вам возможность работать в режиме ядра
??> и чтоб вы систему не могли завалить. Хотя ядро по определению это может.
драйвер - это интерфейс между оборудованием и ядром операционной системы.
ошибке в драйвере совсем не обязательно валить всю операционную систему.
например, ошибки в приложениях не могут повлиять на ядро и другие приложения.
у высококвалифицированных разработчиков ядра Linux хватит ли времени и желания
сделать не кривые драйвера для всего имеющегося в мире спектра оборудования?
наверное нет. они будут заниматься более важными вопросами. а драйвера ко всему
этому зоопарку будут писать разработчики средней и низкой квалификации, допуская
при этом большее количество ошибок в коде драйвера, т.е. в ядре операционной системы.
GM>> если ничего не делать, то при таком же количестве драйверов,
GM>> как во всех Windows вместе взятых - стабильность работы линукса
GM>> как раз и опустится где-то на уровень Windows 95-98.
??> 9х падали отнюдь не из-за кривых драйверов
"стыдно не знать" прогремевший на весь мир случай на чикагской выставке Comdex: стоило
Биллу Гейтсу в ходе демонстрации Windows 98 подключить к компьютеру USB-сканер,
как тут же появился "синий экран смерти". причиной этого был кривой драйвер.
??> Они падали из-за того что кривые ПРИЛОЖЕНИЯ могли попортить память СИСТЕМЫ
??> Что неминуемо вызывало кирдык. Линукс кстати таких вольностям приложениям
??> как правило не позволяет, посему 9х из линукса не выйдет.
и что с того? линукс сейчас позволяет такие вольности драйверам оборудования,
которые написаны сторонними разработчиками. драйвер - это такое специальное
"приложение" которое имеет возможность "попортить память СИСТЕМЫ".
GM>> поэтому желательно уже сейчас начинать задумываться,
GM>> как не превратить Linux в Windows 95.
??> Ага, б**ть,
[...истерика опущена...]
GM>> мелкие баги возможно будут всегда, но архитектура должна стремиться к идеальной.
GM>> операционные же системы - меняются гораздо реже, чем аппаратные платформы.
GM>> первая версия UNIX была сделана в 1969 году. сейчас - уже 2007.
