Центр информации по операционным системам: Страница для печати

Интервью с разработчиками UzhOS

Роман Химов, Среда, 11 Май 2005, 15:26

Интервью брал Роман Химов, на вопросы отвечали Сергей Семанин (главный
архитектор проекта) и Александр aka Kretos (администратор и главный дизайнер проекта).

 

РХ: Какие проблемы вы видите в современных ОС, зачем нужна новая ОС?
 
СС: Есть желание сделать российскую ОС, которая, с одной стороны, сможет
поднять престиж России на рынке ОС, предоставив пользователям
возможности, которых современные ОС не предоставляют, и которая,
с другой стороны, будет доступна практически всем слоям потребителей,
как по цене, так и по эксплуатационны качествам.
 
АK: Прежде чем начать агитационную деятельность по написанию УжОСа, я
много думал над нужностью этого проекта. На тот момент я не видел
операционной системы, которая бы меня устраивала. Тем не менее я хотел
использовать на своем ПК идеальную с моей точки зрения ОС. А идеальная
ОС по лично моим представлениям должна быть как по
количеству и качеству предоставляемых сервисов, так и по оформлению. Я
видел красиво оформленные графические оболочки, но роскошных не видел.
Надо это исправить

РХ: Какие проблемы призвана решить ваша ОС?
 
СС:Я опасаюсь, что обсуждение достоинств и недостатков существующих ОС
может "вылиться" в отдельную огромную статью, поэтому ограничусь тем,
что скажу, что UzhOS объединит в себе достоинства существующих ОС,
вобрав в себя лучшие решения, и будет свободна от их недостатков.
Объектная идеология и модульная архитектура ОС UzhOS сделает ее гибко
конфигурируемой- от встроенных микросистем для промышленных
контроллеров, до "", конфигурируемой достраиваемой и
развиваемой "на ".
 

РХ: Вы читали статью Эммануэля Марти "<a
href=http://www.osrc.info/content.php?article.77>Почему вам больше не стоит
писать собственное я</a>"? Почему вы решили писать свое ядро?
 
СС: Я прочитал эту статью. У меня сложилось мнение, что ее писал человек,
который сначала мечтал утешить свои амбиции, написав свое ядро ради
самого ядра, но вскоре, осознав в глубине души, что он - бездарность,
теперь пытается внушить эту мысль остальным: "не стоит даже пытаться,
вы все равно не напишете ничего лучше того, что уже ".
 
АK: Добавить нечего
 

РХ:
Я постараюсь пояснить, почему я это спрашиваю. Мне кажется, что одной из
частых ошибок разработчиков ОС является желание охватить все и
переустроить все, что только можно - от диспетчера процессора до
драйвера мышки и от реализации графической подсистемы до кнопки в
почтовом клиенте. Не страдает ли тем же UzhOS?
 
СС:
Все исходит из принципа необходимости и достаточности. Ядро должно
удовлетворять требованиям, предъявленным к ОС. Во-первых, ни одно из
существующих ядер не обеспечивает совместного существования в системе
задач жесткого и мягкого времени, следовательно, необходимы свежие
решения. Они подробно, но коряво изложены в
"<a href=http://uzhos.h12.ru/?m=art>Концепциях...</a>". 
 

РХ: Итак, вы все же начали работать над ОС от ядра. Что интересного хочет
предложить команда разработчиков UzhOS в своем ядре?
 
СС: Ну, а от чего же еще можно создавать ОС?

Ключевые решения (описаны в статье
"<a href=http://uzhos.h12.ru/?m=art>Концепции </a>" на
<a href=http://www.uzhos.tk>www.uzhos.tk</a>):
<ol>
<li>микроядро построено на принципах, делающих возможным одновременное
существование в одной ОС задач жесткого и мягкого реального времени;</li>
<li>объектная идеология и модульная архитектура ядра, делающая
конфигурировани ОС очень гибким, а архитектуру ОС - легко
достраиваемой и расширяемой, причем, в т.ч. - динамически.</li>
<li>механизм динамического связывания объектов, встроенный в систему, и
позволяющий создавать распределенную операционную среду;</li>
<li>развитая концепция виртуальных терминалов, предоставляющая, кроме
удаленных графических консолей, новую технологию World Wide Web, не
использующую HTTP, а целиком использующую концепцию удаленного
связывания объектов.</li>
</ol>
Здесь попробую рассказать вкратце: 

<ol>
<li>требование совместимости с NT вынуждает решить проблему с NT DPC,
приводящим в пиковых ситуациях к задержкам переключения процессора до
30-40 мс. Принято решение эмулировать NT DPC на уровне потока ядра с
приоритетом реального времени, а задачи "" реального времени
выполнять на приоритетах выше NT DPC, т.е. в отдельной группе приоритетов
жесткого реального времени, а сами NT DPC разбить на группы и
обеспечить их относительное выполнение с вытеснением (к сожалению,
больше в этом плане пока рассказать не могу - секрет

).</li>
<li>планируется поддержка linux на уровне подсистемы, поэтому
диапазон приоритетов ОС должен перекрывать диапазон приоритетов
linux.</li>
<li>предусматриваетя возможность динамического встраивания новых
классов объектов на уровне микроядра.</li>
</ol>
Исходя из вышесказанного простое заимствование решений из существующих
ядер меня не устраивает. Краткие характеристики ядра UzhOS с
комментариями:
<ol>
<li>диапазон приоритетов - 256, с 4 группами приоритетов:
<ul>
<li>приоритеты "" реального времени (64 + 32 специальных);</li>
<li>приоритеты "мя" реального времени (100);</li>
<li>динамические приоритеты (52);</li>
<li>ленивые приоритеты (8);</li>
</ul>
</li>
<li>новая концепция потока как контекста, в котором с вытеснением могут
выполняться до 16 уровней задач;</li>
<li>особая концепция отложенных обработок прерывания, способных
выполняться в контексте потока ядра с вытеснением (2 группы по 16 уровней);</li>
<li>особый алгоритм диспетчера объектов ядра (расширенная концепция
планировщика),позволяющий динамически встраивать в микроядро новые
классы объектов.</li>
<li>классы объектов микроядра, и всех остальных уровней, подчиняются
идее "каждый класс объектов может быть сигнальным, т.е. объявляющим
какие-либо события. Любой синхронный исполняемый объект может
блокироваться в ожидании события от любых одиночных или групп ".
Эта идея будет дополнена свойством "асинхронные объекты, ожидающие
события, планируются на ".</li>
</ol>
: в качестве прототипа диспетчера прерываний был взят
диспетчер прерываний NT, концепция приоритетной обработки прерываний
полностью переработана. В качестве прототипа диспетчера объектов взяты
планировщик NT и нижний уровень менеджера объектов NT (как идея).
Алгоритм динамического планирования, как идея, также заимствован из NT
(планировщики *nix (в т.ч. linux) настолько слабы, что заимствовать оттуда
что-либо, хотя бы, как идею, не представилось возможным). Идея 5)
также заимствована из NT, т.к. ничего подобного по красоте и гибкости
я не встретил ни в одной другой архитектуре.
 
А что же заимствовано из *nix? ну, пожалуй, семафоры и пайпы. первые
стали популярными благодаря *nix, вторые - это изобретение unix.
 
Так, меня, кажется, понесло, закругляюсь

Все ядро UzhOS сверху донизу пронизано идеей модульности,
динамического конфигурировани и динамического добавления новых
классов объектов. Кроме того, на уровне конечных подсистем все классы
объектов предоставляют виртуальные методы, тем самым позволяя
"" на них механизмы удаленного доступа по принципу DCOM-CORBA.
 

РХ: Вы упоминали то, что собираете в UzhOS лучшее из существующих ОС, как вы
пришли к такой структуре? 
 
СС: Как я написал выше, необходимы свежие решения. К предложенной
архитектуре я пришел раньше, в период работы в области АСУТП,
связанной с жестким реальным временем, распределенным управлением
объектами, сетевыми решениями. Со временем некоторые решения
"". А когда встретил на сайте <a href=http://www.uzhos.tk>www.uzhos.tk</a>
предложение создать российскую ОС, я вышел со своим предложением.
 

РХ: Вы часто упоминаете, что одним из идейных вдохновителей концепции ядра
UzhOS стало ядро NT, основанное, в свою очередь, на достижениях VMS. Вы
планируете использовать для своего ядра какие-либо части, разработанные
в других проектах, как то <a href=http://www.reactos.org/>ReactOS</a> или
<a href=http://www.openvms.org/>OpenVMS</a>?
 
СС:
К сожалению, даже при всем моем желании "" что-нибудь из
ReactOS на этапе разработки микроядра мне это не удастся, т.к. у
меня принципиально иное микроядро. Но, если говорить о прямом
копировании решений, это всегда приводит к плохим пародиям на
существующие ОС. Очень наглядный пример тому - это как раз ReactOS,
которая в своем стремлении к полной двоичной совместимости (на уровне
структур ядра) и стала смешной пародией на NT, да и к тому же, в
основном, с плохо написанным кодом. Хотя некоторые отдельные решения
в ReactOS мне понравились. Например, механизм реализации виртуальных
методов классов микроядра в ReactOS лучше, чем в NT (как механизм).
 
Но с другой стороны, реализацию каких-то отдельных утилит или
процедур я не считаю зазорным подсмотреть, чтобы потом сделать по-своему, тем
более, если в заголовке модуля написано "програма написана в надежде,
что она кому-нибудь может пригодиться"

А что-то заимствовать из
кода VMS я не вижу смысла, т.к. все ее решения я знаю давно и хорошо,
и смогу их реализовать, не заглядывая в код (это, впрочем, касается и многих
других ОС). К тому же, это, все-таки, уже прошлое...
 
К счастью, реализовать совместимость с NT легко, т.к. в основном,
ее классы инкапсулированыи не требуют полной совместимости на уровне
структур. Но и в иных случаях, например, при реализации POSIX, можно
создать прослойку, изолирующую структуры POSIX от ядра UzhOS.
 

РХ: Планируете ли вы совместимость вашей ОС с приложениями под
существующие системы и как вы собираетесь ее реализовывать?
 
СС: Ядро ОС построено на принципах многослойности: API микроядра является
инструментом для создания подсистем ядра и драйверов режима ядра, API
"исполняющего уровня" позволяет создавать конечные подсистемы, в т.ч.
win32, posix, и любые другие конечные операционные среды. Причем все
эти среды могут существовать одновременно в различных сеансах.
Например, один пользователь в своей пользовательско сессии может
создать несколько сеансов: win32, Linux, SunOS и т.п.
 

РХ: Следует ли из этого то, что у UzhOS не будет своей исполняющей среды и
она будет целиком и полностью опираться на описанные существующие?
 
СС:
Я увлекся иллюстрацией гибкости ядра на примере конечных подсистем, и
забыл сказать про родную подсистему

Конечно, она будет, т.к. только
она может позволить использовать ВСЕ свойства ОС

Причем, желающие
смогут использовать родной API совместно с одним из "".
 

РХ: А что насчет драйверов?
 
СС: API микроядра и "исполняющего уровня" предоставляют достаточно мощный
арсенал механизмов, позволяющий реализовать любую систему
ввода-вывода, в т.ч. NT и Linux, как подсистемы, и, как следствие,
позволит использовать в ОС UzhOS готовые драйверы NT (и Linux). 
Ну, разумеется, впоследствии мы предоставим "" драйверы

РХ: Какие возможности даст ваша ОС "из " потребителю?
 
СС: Ну, попробую по пунктам:
<ol>
<li>Многоплановые desktops, от текстовых консолей, до 2D-3D desktops;</li>

<li>Возможность полноценной удаленной работы в консольном и оконном
режимах (правда, это далеко не новинка

);</li>

<li>Легко и просто, "одним движением ", создавать многомашинные
кластеры. Причем предполагается включение в кластеры ""
систем при наличии установленного на них ПО для связывания с UzhOS;</li>

<li>Распределенные файловые системы, невзирая на ОС и "" файловые
системы, с учетом вышесказанного;</li>

<li>Новая технология World Wide Web, построенная на динамическом
связывании объектов и без участия HTTP и всего связанного с ним
"джентльменского", который на низкоскоростныхсоединениях
работает в несколько раз быстреее. И сайты в этой технологии
(стандартные компоненты) можно строить мышкой;</li>

<li>Неописуемый комфорт для разработчиков целевых систем "под клю",
особенно встроенных микросистем: Весь технологическийцикл
разработки и отладки целевой системы - в студии разработки, "не
вставая с ", без применения кросс-отладчиков, с последующим
"" отлаженной системы в target контроллер.</li>
</ol>
Пожалуй, этот список можно продолжить...

РХ: Как огранизована работа вашей команды?
 
СС: Работа нашей команды организована ужасно!

АK: По синергетическом(самоорганизовывющемуся) принципу

То бишь
кряхтит и ладно

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

РХ: А сколько человек сейчас в команде?
 
СС: Записано 10, вместе с дизайнерами - больше. Активно работают пока
далеко не все.
 
АK: Есть несколько человек, которых планируется привлечь в ближайшее
время. Команда продолжает формироваться, требуются талантливые
программисты.
 

РХ: Какие инструменты вы используете?
 
СС: В качестве среды компиляции мы используем MinGW. Ведь не покупать же у
Микрософта кроскомпиляторы для всех платформ?! Да, он и не продаст!

В качестве среды разработки мы используем MS Visual studio custom projects,
построенные на makefiles.
 

РХ: Почему была выбрана закрытая модель разработки?
 
СС: По двум причинам:
<ol>
<li>не делать оригинальные решения достоянием общественности, в т.ч.
конкурентов;</li>
<li>есть надежда хоть что-нибудь заработать

</li>
</ol>

РХ: Считаете ли вы, что закрытая разработка в свободное время возможна,
или UzhOS планирует перейти в статус коммерческого проекта?
 
СС: А если невозможна, то почему???
 
АK: Закрытая разработка в свободное время возможна, но конца её
дождутся наши внуки. Чтобы дело шло быстрее, нужно этому делу уделять
как можно больше времени, а это возможно только при переводе проекта
на коммерческую основу и привлечении инвестиций в разработку.
 

РХ: То есть переход в коммерческий проект планируется?
 
АK:
Переход в коммерческий проект планировался уже давно, а сейчас он
уже осуществляется. Уже ведется расчет финансовых показателей,
необходимых денежных затрат на создание и реализацию ОС. Инвестор
планирует начать денежные вливания в проект к середине лета 2005 года
поскольку считает проект очень перспективным. Я тоже так считаю

РХ: На какой стадии сейчас находится проект, когда можно будет увидеть
первые публичные альфа-версии?
 
СС: Сейчас "" микроядро, уже работают потоки и объекты
синхронизации, сейчас трудимся над таймером. Работа пока продвигается
медленно, из-за сильной загруженности на основной работе, но в
ближайшее время расчитываем форсировать работу.
 
Alpha-версию увидим в обозримом будущем...
 
РХ: Спасибо, и удачи вам!

это контент от Центр информации по операционным системам
( http://www.osrc.info/plugins/content/content.php?content.95 )