OSDev

Предлагаю всем обсудить те критерии, которыми должна обладать ОС и как их достигнуть, вообще результатом данной дискуссии хотелось бы видеть структуру ОС приближенной к идеальной, ее идеологию и принципы функционирования. Сразу оговорюсь, я не программист(но при желании могу разобраться в любой компьютерной теме и стараюсь по мере возможности расширять свой кругозор в этой области), мне интересна эта тема как конечному пользователю и если все-таки из этой темы получится хоть какое то рациональное зерно, то вполне возможно какая то команда программистов возьмется воплатить теорию в жизнь так сказать
Достоинства и недостатки существующих ОС я думаю все присутствующие себе представляют
Итак, я начну по критериям:
1) Максимальная скорость работы ОС
Это должна быть экзоядерная ОС, экзоядро обеспечивает минималистичность ядра, а значит его читаемость и меньшее колличество ошибок, а также легкость их исправления. Конечно микроядро тоже хорошее решение, но по сравнению с экзоядром, у него есть существенный недостаток - скорость работы, а именно при его работе происходит слишком много переключений между режимами процессора, которые занимают сравнительно длительное время. Возможно не во всех архитектурах, но в x86 точно
2) Гибкость
Должна быть возможность эту операционную систему использовать и на обычном домашнем компьютере и на сервере без ограничений, все различия будут лишь в конфигурациях
3) Максимальная переносимость самой ОС и всего ПО под эту ОС написанного
Возможность данную ОС с приемлемой скоростью запустить на любых процессорах в пределах разумного практически без переписывания кода ОС и вообще без переписывания ПО. Т.е. захотел ОС поставил на ПК, захотел на нетбук, а захотел и на смартфон или даже использовать эту ОС на каком нить контроллере. Сфера применения такая же как у Unix и его клонов, но с меньшими затратами в конечном итоге.
Например взять Windows и все ПО, что написано под него чтобы перенести его на например архитектуру отличную от x86 придется переписывать HAL(аппаратнозависимую часть), перекомпилировать сам Windows и перекомпилировать ПО под него. Приходим к тому что Windows закрыт, да даже если бы был открыт - практически все программное обеспечение с закрытыми исходными кодами, все - это тупик. В Linux с этим проще, но опять же чтобы из исходников собрать что то работоспособное необходимы знания и чтения манов. Опять же, а как быть с ПО, у которого закрытые исходники? Опять тупик. В этой же ОС я предлагаю чтобы чтобы и максимально большая часть ОС(за исключением архитектурно(аппаратно)зависимых модулей) и все ПО и по возможности даже драйвера для устройств писались бы только на высокоуровневом языке. Далее эти исходники с высокоуровневого языка со всеми необходимыми ключами компилируется в некий промежуточный язык(байт-код)в котором и распространяется в дистрибьютиве, а далее при установке на конечном ПК, конечным компилятором оптимизируется и компилируется уже в машинный код под конкретную платформу. Причем конечный компилятор уже знает все тонкости того процессора под который он компилирует и какие оптимизации нужно сделать.
Следствие этой максимальной переносимости в том что написанный софт не будет привязан к конкретной аппаратной реализации как сейчас. Мое мнение, если бы Windows сейчас обладал таким свойством, то мы сейчас сидели не на архитектуре x86 которую кстате у Intel за бабки лицензирует AMD, а на какой нить более эффективной
4) Максимальная дружественность к пользователю
Это в основном относится к GUI ОС - вообще об этом можно много говорить, но я пока не буду
5) Открытость
Мое мнение - за OPEN SOURCE будущее и чисто программное обеспечение продаваться не должно, должна продаваться техподдержка для него либо ПО вместе с железом
6) Документированность
Документированность ОС играет очень большую роль в ее распространении. Чем больше, чем подробнее документация и чем на больше языков она переведена тем лучше
7) Стандартизация
Это в основном относится к интерфейсам ОС - об этом можно много говорить, но я пока не буду

Хочу отметить, что это наверное не все критерии, но пока и этих будет достаточно

PS: возможно кому то покажется что я тут несу ахинею, но это скорее по тому что я может быть где то немного неправильно выражаю свои мысли

Имеется ряд ошибок. Например, с чего Вы взяли, что экзоядро -- это идеал? Как по мне, так это вообще весьма сомнительная концепция, которая вряд ли окажется работоспособной на практике. Самая высокая скорость работы достигается с монолитными ядрами (меньше переключений контекста попросту некуда, ну а надёжность зависит в первую очередь от грамотности проектирования и реализации, а не от архитектуры как таковой).

Гибкость не ограничивается "обычным домашним компьютером" и "сервером", тем более что это не обязательно технически разные машины, а просто разные классы задач. Но есть ещё системы реального времени, есть встраиваемые системы (нередко эти два качества объединяются, но вообще-то это разные вещи), есть мобильные системы... У всех у них разные приоритеты к обеспечению, в общем-то, одних и тех же функций. Например, у сервера обычно важна наибольшая производительность (как можно меньше времени должно тратиться на накладные расходы), однако время отклика каждой конкретной прикладной программы не слишком важно (естественно, в разумных пределах), ну а у систем реального времени, напротив, именно малое (и гарантированное!) время реакции является первейшим требованием, ради выполнения которого можно пойти на снижение общей производительности системы.

Переносимость ОС -- это вообще наполовину миф, причём сразу с нескольких концов. Начну с более простого: Винда не менее переносима, чем Линух, и изначально она создавалась под несколько платформ. Так, НТ 4 была выпущена под платформы ИА-32 (х86, если по-народному), ПоверПЦ, МИПС и Альфа. То, что в дальнейшем от поддержки большей части платформ отказались, говорит не об особых трудностях с обеспечением переносимости Винды, а с коммерческой нецелесообразностью. Альфа умерла (безграмотная политика руководства фирмы ДЕК), ПоверПЦ и МИПС оказались, в общем-то, вытесненными во всякие там контроллеры, маршрутизаторы и прочие специализированные железяки (что подтверждается в том числе и переходом Эпла с ПоверПЦ на ИА-32). В общем, это чистый бизнес, а не технологическая проблема.

Ну а вторая часть мифа связана с эффективностью таких систем. Ось, способная работать на любой платформе и при этом быть легко переносимой, будет на каждой из них работать попросту неэффективно: слишком большие различия кроются в аппаратуре, на которой приходится функционировать. Например, у мэйнфреймов IBM и у привычных ПК принципиально разный подход к организации ввода-вывода, и никакими ухищрениями не удастся совместить высокую производительность с общей кодовой базой соответствующих компонентов системы (на мэйнфрейме можно обслуживать запросы ввода-вывода образом, удобным для ПК, но это будет и неэффективно, и через задницу; ну а "правильный" способ для мэйнфреймов для ПК вообще неприемлем в принципе).

Переносимость прикладного ПО -- тоже, по большому счёту, байки. Кажется, что может быть переносимее, чем Жаба -- ведь весь код выполняется на виртуальной машине, ему вообще без разницы, какой там процессор стоит! Но попробуйте запустить программу, созданную для Java EE, на Java ME, или наоборот -- скорей всего, будет полный облом, потому что назначение-то у них соврешенно разное (МЕ -- это всякие могильные телефончики, а ЕЕ -- сервера уровня предприятия). Можно ли Ворд сделать по-настоящему переносимым, чтобы он мог работать и на ПК, и на КПК? Понятное дело, что нет: очень уж большая разница в разрешении экрана требует по-разному организовывать пользовательский интерфейс (т.е. "морда" будет совершенно разной), да и ввод придётся организовывать по-разному (тыкать в нарисованные кнопки палочкой крайне неэффективно, поэтому остро стоит вопрос рукописного ввода, в то время как на ПК есть нормальная клава, и здесь рукописный ввод не так нужен, ну а для умеющих печатать 10 пальцами -- и даром не нужен, поскольку в этом случае печать будет быстрее и легче).

Далее, открытость. Спору нет, лучше, когда система и всё прочее ПО открыты. Однако, как показывает практика, основная масса серьёзных продуктов либо в принципе отсутствует у опенсорсного сообщества, либо откровенно уступает закрытым коммерческим аналогам (сравните ГИМП и Фотошоп: для домашнего пользователя, наверное, разницы никакой -- а может, ГИМП даже лучше, однако для настоящего профессионала ГИМП вообще не подходит: он и близко по функционалу к Фотошопу не лежал; "тяжёлых" САПР, аналогичных Катьке или Юниграфиксу, в открытом виде в принципе не существует, ну и т.д.). Дело тут, конечно, не в открытости как таковой, а в двух других моментах: получение прибыли и модель разработки. Понятное дело, что создание мощного пакета требует больших затрат времени значительного числа высококвалифицированных специалистов, и забесплатно это вряд ли кто будет делать. Кроме того, для успешной и достаточно быстрой реализации крупного проекта нужна хорошая организация самого процесса разработки, документирования и т.д. и т.п. -- в общем, нужна дисциплина, чего у сообщества любителей, пускай даже индивидуально очень квалифицированных, нет в принципе (кстати говоря, по той же причине у открытого ПО практически не бывает действительно хорошей документации: её попросту лень делать, ну а в фирме работаешь за деньги, там и заставить могут). Вот и выходит, что основную массу серьёзных проектов делают коммерческие фирмы, которые, естественно, не стремятся поделиться исходниками с возможными конкурентами. Ну и, кстати говоря, платность и открытость -- это, так сказать, "идеологические", а не технологичские характеристики, и на качества ПО как такового они вообще никакого прямого влияния не оказывают и оказать не могут.

Со стандартизацией тоже имеются существенные проблемы. Многие вещи можно и нужно стандартизировать, но, если всё подогнать под одну гребёнку, уткнёмся в неэффективность, а то и в невозможность реализовать некоторые вещи. Значит, надо проявлять определённую гибкость в этом вопросе.

Я и не утверждаю что это идеал, это архитектура близкая к идеалу по совокупности параметров, недостаток монолитного ядра в его объемности, что соответственно влечет за собой большое поле для ошибок в ядре, а ошибка в ядре(которое выполняется в режиме супервизора) влечет за собой падение всей системы. Мне вот например совсем не улыбает в винде видеть синий экран смерти из-за того что в драйвере видухи возникает ошибка.(Сразу оговорюсь, я знаю что у винды не монолитное ядро, но драйвер видеоадаптера выполняется в режиме ядра), неужели компьютер не может работать без видухи? В ОС на экзоядре или микроядре можно было бы просто перезагрузить драйвер видухи и работать дальше.


Что в ней такого принципиально нереализуемого?

Это понятное дело что разные требования, но за счет модульности экзоядерной ОС а соответственно ее гибкости это можно охватить. QNX к примеру основана на микроядре и это ей не мешает быть системой реального времени, а экзоядро быстрее чем микроядро, где принципиальная невозможность использования экзоядра в ОС реального времени? Я склоняюсь к тому что будут разными чисто библиотечное окружение и возможно конфигурации ядра.

Спасибо за экскурс в историю, я это знал и я рад что вы это тоже знаете :)

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


JAVA это вообще отдельный разговор. Это виртуальная машина которая запускается в среде ОС, а не сама ОС, т.е. здесь подход другой. Используя JIT трансляцию программа JAVA в реальном времени транслируется в машинные коды конкретного процессора при этом нет возможности оптимизировать код под конкретный процессор в реальном времени, а ведь это очень важная часть работы. И к примеру что происходит в JAVA если одна и таже функция в программе вызывается несколько раз? насколько я понимаю она повторно транслируется отжирая процессорное время, а это по суте бесполезная трата ресурсов. К слову говоря Java ME приложение можно запустить и под виндой без всяких проблем, нужна соответствующая виртуальная машина, а ресурсов хватит.

Можно если отделить мух от котлет. А именно, саму программу от интерфейса общения с пользователем. Понятное дело что понадобится адаптированный GUI, но если создать стандарт общения между ядром программы и GUI(с командной строкой в этом плане все на много проще) и в качестве инструментария создать конструктор для GUI, то мы будем иметь следующее: программист пишет ядро программы у которого стандартизирован протокол общения с GUI, может быть он даже наваяет GUI, но даже при закрытых исходниках ядра ПО и отсутствии документации у других пользователей будет возможность по этому стандартизированному протоколу опросить ядро приложения и сделать свой GUI. Такой подход несет в себе и еще одно преимущество, оно заключается в том что программист пишет ядро программы, а дизайнер знающий и умеющий использовать на практике законы юзабилити с помощью инструментария без особых знаний в программировании делает GUI

Ну программе вообще должно быть пофиг откуда поступает инфа, от драйвера клавиатуры или от драйвера рукописной системы ввода или от драйвера виртуальной клавиатуры.

Я вот про что и говорю, что даже в линуксе со всей его открытостью мы не имеем возможности скажем программу написанную под архитектуру x86 перенести на архитектуру IA64 без исходников, даже если она написана на высокоуровневом языке, а промежуточная компиляция под виртуальную платформу, а затем под реальную с различными оптимизациями под нее это позволяет сделать даже без исходников.

Это то и обидно, поэтому я и упомянул про документацию к ОС, поскольку сама ОС это ничто - полуфабрикат, а вот ОС в совокупности с необходимым ПО это СИЛА.
А вообще ладно пускай даже софт будет закрытым при таком подходе это не столь важно, а вот как сподвигнуть производителей комплектующих к открытости своего ПО или хотя бы чтобы они делали доступной полную техническую документацию на аппаратуру которую они производят это вопрос. Хотя в этом плане есть уже подвижки. Я конечно понимаю что написание драйверов это деньги, но ведь дрова без оборудования это ничто. Чего боятся производители аппаратного обеспечения?


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

Тогда не должны продаваться булки в магазине, автомобили и другие товары.

ПО вместе с железом продается - это драйверы.

Будущее за качественым и пропиаренным ПО, а не за OPEN SOURCE. Не стоит навязывать всем одну из бизнес-моделей. Она никак не доказала свои преимущества для всех случаев жизни. У неё есть часть рынка заказного ПО. Этим всё и ограничивается.

Если вы придумаете способ копировать булки и машины с той же лёгкостью как вы копируете файлы у себя на диске, то да.

Надёжность микроядра -- это лапша на уши, точно так же как ненадёжность монолитного. От архитектуры она никоим образом не зависит, а зависит исключительно от тщательности проектирования всей системы (в первую очередь ядра, но не только его) и реализации. Те же проблемы с драйверами видюх вызваны просто их плохим качеством: стремятся выпустить как можно быстрее, впихнуть туда особую поддержку разных игр и т.п. -- вот и получается, что код драйвера разбухает, а качество падает. Но это проблема не того, что он внутриядерный, а того, что он плохо сделан. В то же время вынос всех драйверов за пределы ядра отнюдь не даёт возможность "просто перезагрузить драйвер" -- далеко не во всяком случае можно перезапустить некий компонент системы без последствий. Да, кстати говоря, вот прямо сейчас занимаюсь тестами производительности интеловского шестиядерника, ну и попробовал сначала в качестве видюхи использовать Радеон 4870Х2 -- и получил облом, потому что при попытке прогона тестов в Лайтвэйве (эта такая прога для трёхмерного моделирования и анимации -- конкурент 3ДС Маха и Майи) постоянно падал драйвер видюхи. Никакого БСОДа при этом не происходило, просто из трэя выползал плакат: драйвер видюхи сдох и будет перезапущен. Но какая мне от этого польза, если валится не только драйвер, но и тест? Кончилось тем, что я поставил Радеон 5830 -- с ним драйвер работает нормально, не падает.

Возвращаясь к теме. Проблема Винды или там Линуха не в монолитности ядра (это системы с монолитными ядрами, тут Вы не правы -- просто они модульные, а не "цельносварные", но от этого не перестают быть монолитами), а в плохом качестве проектирования и реализации. В частности, в ядро там набито всё подряд -- поэтому оно такое жирное. С теми же драйверами МС пришла-таки к пониманию, что не надо всё пихать в ядро: теперь часть дров работает в режиме ядра, а часть -- в режиме пользователя. Этот подход мне представляется наиболее правильным, поскольку обеспечивает наибольшую гибкость. Если драйвер нуждается к прямом доступе к аппаратуре (дёргать регистры устройств, обрабатывать прерывания и т.п.), то ему место в ядре, иначе будут либо жуткое падение производительности, либо придётся изрядно заморачиваться с обеспечением прав доступа, либо и то, и другое в одном флаконе. Если же драйверу прямой доступ к железу не нужен (это, например, все УСБ-устройства: к железу там лезут только драйверы самих УСБ-контроллеров, все остальные дрова выполняются над ними; сюда же идут файловые системы и сетевые протоколы -- в отличие от драйверов контроллеров дисков и сети), то его вполне можно оформить задачей пользователя. Правда, чуть пострадает производительность (лишние переключения контекста), но обычно время выполнения собственно операций ввода-вывода многократно превышает потери на такие переключения, а поэтому и нет смысла этот момент оптимизировать.



Не помню, но, когда читал, возникли баальшие сомнения. Надо б перечитать, но сейчас лениво, да и делом занят (тестами вышеуказанными).



Экзоядро пока оставим, поскольку надо его подробно обсуждать, а для этого мне нужно опять перечитать про него. Что же касается того, что микроядерность не мешает быть системой реального времени -- совершенно верно, ведь там требование -- достаточно малое и при этом абсолютно гарантированное время реакции, а это можно обеспечить и в монолите, и в микроядре. Другое дело, что у микроядра теоретически большее время реакции из-за более высоких накладных расходов -- но тут уже в игру вступают такие факторы, как качество проектирования и реализации, и по факту микроядерная QNX оказывается быстрее монолитных Винды и Линуха.

Кстати говоря, я вообще считаю, что "идеальной" (ну, близкой к таковой -- идеал недостижим в принципе) может быть (но не обязательно будет!) именно ОСРВ: из хорошей системы реального времени можно сделать хороший десктоп или сервер, но наоборот -- никогда.



Даже маленькое полнофункциональное ядро -- это десятки тысяч строк. Так что переписать не так уж просто, хотя, конечно, можно. Лично я сторонник как раз такой кроссплатформенности: система должна обеспечивать одинаковый базовый АПИ (и по возможности одинаковые расширения, "завязанные" на аппаратные особенности платформы), но сама по себе -- переписываться под конкретную платформу.



Насчёт трансляции понимаете неверно: трансляция любого кода в жабе выполняется один раз, в дальнейшем выполняется сразу скомпилированный код, поэтому скорость отнюдь не так низка (содержащая циклы жаба-программа обгонит скомпилированную плохим транслятором программу на традиционных компилируемых ЯВУ). Что запустить можно, это понятно, но с ограничениями и не во всех направлениях (с КПК на десктопе -- можно, наоборот -- фигвам, у КПК ресурсов не хватит банально).



Можно. Но в любом случае приходим к тому, что и прикладное ПО не является "автоматически переносимым", а нуждается в серьёзных переделках. Кстати, качественный гуй "просто дизайнер" не сделает, да и "ядром прикладной программы" здесь не обойтись. Кто будет управлять, например, всякими списками и полосами прокрутки, если на них надо влиять из самой программы? А правила этого влияния могут различаться, если есть серьёзные различия в гуе. В общем, всё намного сложней, чем Вам представляется.



Самой программе -- да, но её гуй от этого зависит весьма серьёзно.



Фактически -- приходим к Жабе. Там ведь тоже компиляция исходников в промежуточный байт-код, а потом уже его компиляция по мере надобности (а не интерпретация, как многие думают; по сути, JVM и является этим вторым компилятором плюс библиотекой поддержки) в код конкретного процессора. Можно сделать и компиляцию всего сразу -- т.е. применить технически несколько иной подход, однако идеологически он будет близок к уже имеющимя жабе и дотНЕТу.



Обычно -- конкурентов. Особенно это касается графических процессоров: АМД пока что не в состоянии сделать столь же эффективный процессор, что и Невидия (хотя как чисто числодробилка Радеон 5870 несколько быстрей, чем ГеФорце ГТХ 480, но вот, например, по тесселляции уступает, причём тем больше, чем интенсивнее эта новая фишка используется), вот Невидия и зажимает доку. Кстати говоря, и АМД не делится информацией по последним графпроцессорам.



Потому что Винда -- коммерческая система, там деньги делают, а не самовыражопываются.

Кстати говоря, не надо смешивать открытость и бесплатность. Например, та же QNX открыта, но не бесплатна (для коммерческого использования, естественно). А QIP вроде бы закрытый, но бесплатный, если не ошибаюсь (сам им не пользуюсь).

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

Для булки всё гораздо проще. Её цена формируется исходя из фактической трудоёмкости изготовления булки + прибыль.

Тут речь идет о вероятности наличия ошибок, микроядро маленькое, монолитное ядро большое

Вот я про это и говорю, что я за стабильность системы в целом и я не готов потерять свои данные которые к примеру не касаются видео из-за проблем с драйвером видеокарты

Согласитесь, что плохонаписанный драйвер находящийся за пределами ядра это лучше чем плохонаписанный драйвер, который является частью этого ядра?

Я и не говорю что без последствий, я просто пытаюсь до вас донести мысль о том что эти последствия можно и необходимо минимизировать. Или накроется часть системы и полетит часть данных или накроется полностью вся система, что лучше?

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

[url]http://ru.wikipedia.org/wiki/Ядро_операционной_системы[/url]
Ядро линукса было изначально чисто монолитное, сейчас же в нем есть возможность динамической подгрузки драйверов и будут они работать в нулевом кольце процессора.
Ядро Windows NT изначально было микроядро, но из-за низкой скорости работы системы(переключение контекстов частое) перешли на модульное ядро. Вся соль в том чтобы вынести из нулевого кольца процессора неблагонадежный код, а оставить там только выверенный минималистичный код, который обеспечит работу компьютера в самом минималистичном режиме. И при любой нештатной ситуации компьютер не зависнет, а продолжит функционировать и сможет( в крайнем случае попытается) восстановить сбоившую его часть, как дефибрилятор встроенный в сердце человека.

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

Из двух зол выбирают меньшее, из гибкости и стабильности я выбираю стабильность. Гибкость должна быть не в ущерб стабильности.

Я это в курсе, это не проблема ОС, это проблема самой архитектуры x86 на железном уровне(честно не знаю как обстоят дела в других архитектурах по этому поводу), но мы же говорим про ОС не именно под x86, а про мультиархитектурную ОС. Если говорить именно про архитетктуру x86, то я думаю софтово можно если не обойти, то хотя бы минимизировать этот недостаток.

Опять же это недостаток x86, а не ОС на экзоядре


Могу сказать что экзоядро уже работает и его пока изучают в американском по моему массачусетском университете


Да его нужно обсуждать подробно, хотя там практически и обсуждать то нечего помоему - просто оно очень маленькое и выполняет минимум функций, а вот архитектуру ОС на экзо ядре это можно обсудить

Я полностью с вами согласен, я просто привел пример именно с QNX(микроядро), потому что микроядро из-за большого количества переключений контекста в процессоре - самое медленное по сравнению с модульным, монолитным, экзо и комбинированным ядром, но тем не менее оно обеспечивает скорость необходимую для ОСРВ.

Сложно сравнивать скорость QNX и (Windows или Linux), поскольку эти ОС писались под разные задачи. Но если всетаки сравнить, то экзоядро априори быстрее микроядра, а значит если удалось ускорить микроядро, то и экзоядро тоже можно еще ускорить, точно также как ядра Windows и Linux, НО отличие состоит в том что с микроядром, а тем более с экзоядром это сделать гораздо легче, потому что они меньше.


С этим я полностью согласен, только добавлю что можно пойти дальше и создать универсальную ОС, которая бы в себе сочетала достоинства QNX для ограниченной группы приложений, а для всех остальных приложений достоинства windows(linux)


Почитайте пожалуйста чем занимается экзоядро - оно выполняет минимум функций необходимых для того чтобы работал процессор и оперативная память, а остальное все экзоядро отдает на откуп сторонним программам(экспортирует на непривилегированный уровень)

Здесь мы с вами едины :)


Скажите мне, при трансляции(компиляции) явамашина оптимизирует получившийся код под конкретную платформу, она знает все ее закоулки? Вообще здесь накладывается 2 тормоза друг на друга, это ОС и виртуальная машина, - получается слишком длинная цепочка до аппаратного обеспечения, я за то чтобы ее сократить, вы за или против?

Я это и имел ввиду


Я это прекрасно понимаю, я знаю что все сложнее, но это уже детали разработки протокола и это все выполнимо. Насчет "просто дизайнера", это в любом случае будет не просто дизайнер, в любом случае человеку придется осваивать инструментарий разработки GUI где нужно будет писать/составлять алгоритмы работы GUI, но это будет не сложнее чем работа с GUI в Delphi, я так себе это представляю


Объясните мне разницу в выходящей информации от драйвера клавиатуры(реальной, ирутальной) и от драйвера рукописной системы ввода? И там и там передаются символы


Идеологически да, практически нет. Об этом я написал выше



Но линукс тоже деньги приносит, ему не хватает более жесткой координации



Да я вроде и не смешивал

Непонял можно поподробнее

Как я понял производители не хотят делиться потому что в спецификации железа можно узнать некоторые технические аспекты работы граф. процессора и это поможет конкурентам создать аналог.

Согласен с Groms, что будущее за микро- и экзоядром. ОС должна работать вне зависимости какой из компонентов отказал, если это не ядро. Между прочим как раз после сбоя драйвера видеокарты можно нормально продолжить работу - переинициализировать устройство и скопировать изображения из буфера в видео-память (или если всё пишеться сразу в видео-память обновить все окна). Тогда пользователь заметит лишь замирание изображения на экране или его исчезновение на мгновение (смотря какой сбой). Хотя в определённых случаях устройство не сможет нормально работать до перезагрузки (или вообще сгорит), но тут уже ничем помочь нельзя. Кстати, если драйверам нужен прямой доступ к аппаратуре, то это можно обеспечить и из 3-его кольца. Просто разрешить обращение к нужным портам с помощью карты разрешения ввода-вывода из TSS и тогда скорость будет такая же как и из ring 0. К тому же можно будет отследить, чтобы два процесса не пытались заполучить один и тот же порт. Это позволит избежать конфликты от которых нельзя защититься в ring 0, потому что все имеют доступ ко всем портам. Прерывания правда будут обрабатываться медленее, потому что он них будет уведомляться драйвер через IPC. Однако квант времени можно сделать и покороче. Или даже зависимым от мощности процессора - чем быстрее процессор, тем меньше квант времени. Тогда будет высокое время отклика. Дело в том, что год от года скорость процессоров растёт и если делать скажем такой вот изменяющийся кват времени, то ОС будет работать всё быстрее и быстрее, но никакой процессор никогда не сделает код выполняющийся на нём стабильнее. Скорость важна, но стабильность намного важнее, потому что низкая скорость (при правильной проектировке ядра) это лишь проблема процессоров, которая через некоторое время решиться.

Переносимости с декстопа на КПК вряд ли удасться добиться. Это совершенно разные вещи. И проектировать приложения надо по разному. На декстопе мы можем спокойной выделять сотни мегабайт памяти, если это необходимо, а на КПК надо намного серьёзнее задумываться над объёмом потребляемой памяти (у на в распоряжении несколько десятков мегабайт в лучшем случае), поэтому приложение надо проектировать заново и возможно убрать часть функционала (потому что не хватает ресурсов). Интерфейс тоже надо строить совсем иначе. Хотя я думаю метод ввода не важен. Приложение не должно знать как пользователь ввёл символ - хоть на виртуальной клавиатуре, хоть рукописным вводом - приложение должно получить символ и даже совсем не обязательно должно знать откуда он. Кстати, на малом экране не удобен интерфейс из нескольких перемещаемых по экрану окон, а популярностью пользуется интерефейс из нескольких окон на весь экран. На ПК всё наоборот.

Я вообще думаю, что ядро микро/экзоядро имеет смысл написать на чистом ассемблере, чтобы добиться максимальной производительности (не спорьте - специалист напишет код как минимум не хуже, чем генерт компилятор, а чаще даже лучше). Поскольку объём ядра черезвучайно мал переписывание его под другую архитектуру будет не такой уж и сложной задачей.

Кстати, в Linux тоже стремятся к стандартизации, хотя и не всегда успешно. Например, большинство приложений можно запустить на любом дистрибутиве Linux. При наличии дополнительных библиотек разумеется. А уж если приложение использует лишь системные вызовы, то оно уже 100% переносимо, потому что POSIX у всех линей один и тот же (как и ядро одно и тоже. максимум - в одном дистрибутиве могут исправить ряд ошибок, которые не были исправленны в основной ветке, но для приложение это будет малозаметно).