Как уже сообщал, завтра поздно вечером пройдет первая онлайн-планерка участников проекта. На ней и состоится официальный старт проекта. Предполагается еженедельный режим подобных точек синхронизации общения участников. В остальном работа будет вестись преимущественно в асинхронном режиме.

В преддверии старта можно уже озвучить состав техсовета, на который упадет вся организационно-техническая нагрузка самых тяжелых первых недель проекта. В алфавитном порядке:
1. Руслан Богатырев (Москва)
2. Илья Ермаков (Орел)
3. Владимир Лось (Харьков)
4. Борис Рюмшин (Орел)

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

Прием желающих будет вестись на протяжении всего времени ведения проекта. В последующем предполагается устанавливать срок (ориентировочно 2 месяца), после которого кандидат, приславший заявку на участие и "поварившийся" в проекте, будет по решению техсовета получать все привилегии участника (в т.ч. в отношении доступа к внутренним материалам проекта).

Ответ на »сообщение 1689« (Руслан Богатырев)
___________________________

В Европейском центре программирования (europrog.ru, europrog.org) будет выделен специальный раздел, посвященный данному проекту.

Забыл сказать: поскольку важную роль в проекте будут играть Оберон-технологии, то развернутая информация по ним будет доступна на Oberon2005.ru (после его отстыковки от europrog.ru) и на OberonCore.ru. Подъездные пути существенно подправим.

Ответ на »сообщение 1686« (Aleg Azarousky)
___________________________

Какой язык предполагается в качестве базового (для системных сообщений и т.п.) - английский или русский?

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

На уровне базовых языков при создании системы текстовые сообщения, скорее всего, не будут использоваться как строковые константы. Только опосредованно, через обращение к служебным внешним таблицам (через числовые идентификаторы).

Совет: как человек, на практике сталкивавшийся с проблемами интернационализации и связанными, предостерег бы вас от использования кодировок типа Windows 1251, KOI8-R и т.п. в документации, исходных текстах программ да и везде.

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

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

P.S. В 2003-2004 гг. в бытность работы в EPAM Systems (http://www.epam-group.ru) руководил разработкой технологии интернационализации и локализации программных систем в соответствии с требованиями LISA (http://www.lisa.org/) для ведения крупных зарубежных проектов на европейских и азиатских языках.

Ответ на »сообщение 1687« (Николай)
___________________________

Но любопытно все-таки.
Был бы благодарен, если бы Вы дали ссылку на основополагающий материал, характеризующий замысел в целом. Если такового еще нет, то придется подождать.

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


В принципе предполагается следующая схема отчуждения информации в публичный доступ.

В Европейском центре программирования (europrog.ru, europrog.org) будет выделен специальный раздел, посвященный данному проекту. Будет это сделано в ближайшее время, не дожидаясь перенесенного на осень ввода нового дизайна. Там будут публиковаться результаты исследований (включая различные обзоры по ОС и железу). В дополнение к этому там же будет представлена дополнительная литература (книги, препринты, статьи, документация и др.), проясняющая разные аспекты реализации -- в рамках Открытой электронной библиотеки.

На OberonCore.ru, который будет центром формирования сообщества для данного проекта, планируется выделение специализированных форумов со свободным доступом всем желающим. Там можно будет вести дискуссии по направлениям работ в рамках данного проекта непосредственно с участниками проекта, специализирующимися на тех или иных направлениях.

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

Ответ на »сообщение 1686« (Aleg Azarousky)
___________________________

Ответ на »сообщение 1685« (Руслан Богатырев)
___________________________
Какой язык предполагается в качестве базового (для системных сообщений и т.п.) - английский или русский?

Совет: как человек, на практике сталкивавшийся с проблемами интернационализации и связанными, предостерег бы вас от использования кодировок типа Windows 1251, KOI8-R и т.п.

http://consumer.nm.ru/kod.htm

Ответ на »сообщение 1683« (Руслан Богатырев)
___________________________
Руслан, спасибо за терпеливое объяснение!
Только я это с трудом перевариваю и то частично. Если начну обучаться в форуме, то могу сильно увести в сторону.

Но любопытно все-таки.
Был бы благодарен, если бы Вы дали ссылку на основополагающий материал, характеризующий замысел в целом. Если такового еще нет, то придется подождать.

Ответ на »сообщение 1685« (Руслан Богатырев)
___________________________
Какой язык предполагается в качестве базового (для системных сообщений и т.п.) - английский или русский?

Совет: как человек, на практике сталкивавшийся с проблемами интернационализации и связанными, предостерег бы вас от использования кодировок типа Windows 1251, KOI8-R и т.п. в документации, исходных текстах программ да и везде. Лучше всего для сохранения и передачи текстовой информации использовать UTF-8, а для обработки - UCS-2/UTF-16. UTF-8 - компактен и нет проблем с порядком следования байтов, UCS-2 - очень быстрый при обработке (копировании, поиске в текстах и т.п.). UTF-16 - только если собираетесь поддерживать древние китайские иероглифы (а оно надо? :) ).

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

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

Ответ на »сообщение 1683« (Руслан Богатырев)
___________________________

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

Некоторые предварительные комментарии по этому см. »сообщение 1625«

Ответ на »сообщение 1681« (Николай)
___________________________

Если я правильно понял, то можно говорить о таких слоях программного обеспечения:

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

== Специализация работ
1. Ядро
* Микроядро (аттоядро)
* Безопасность (защита)
* Диспетчеризация

2. Сервисный уровень
* Управление памятью
* Файловая система
* Управление устройствами
* Сетевые средства

3. Прикладной уровень
* Операционная платформа
* Пользовательский интерфейс
* Прикладные каркасы


== Организационная структура
1. Сектор изучения перспективных ОС и процессорных архитектур
2. Сектор архитектурно-конструкторских решений
3. Сектор разработки инструментальных средств
4. Сектор разработки ядра
5. Сектор разработки сервисного уровня
6. Сектор разработки прикладного уровня
7. Сектор информационного обеспечения

Один исследовательский сектор (1), один проектный (2), четыре производственных (3-6), один вспомогательный (7).


== Математический фундамент

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

Из Вашего резюме я вывожу, что теоритически и практически доказано, что можно отдельно строить и оптимизировать слой 2, т.е. ядро, не заботясь о том, какими будут сервисы. Оптимизация взаимодействия сервисов с фиксированным ядром - уже другая задача, но, видимо, уже тут будут решаться вопросы специфики функциональных программ.

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

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

Думаю, можно озвучить и еще одну важную идею, которая так или иначе проглядывалась в проектах ETH Zurich, а здесь получит несколько иное развитие. Система поддержки языков (ран-тайм) будет теснейшим образом интегрирована с ядром. Принципиальная разница состоит в том, что у нас будет не моноязыковая система, а мультиязыковая, при этом число привилегированных языков будет лимитировано (пока видится 3 базовых и один уровня супермодулей). Ран-тайм будет разрабатываться под наиболее эффективное взаимодействие этого базиса ортогональных языков, покрывающих основные парадигмы. Соответственно в ран-тайм просочится и поддержка примитивов формальных моделей (мат.фундамент). Если понадобится расширять номенклатуру языков, то новые языки пойдут уже на общих основаниях и без тех привилегий, которые имеют базовые.

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

В идеале в отдаленном будущем при получении хороших результатов НИОКР вполне разумно будет ставить вопрос о разработке наиболее оптимального отечественного железа под такую схему. Но это дело не сегодняшнего дня.

То, что здесь представил, следует рассматривать лишь как информацию к размышлению. И как предмет для обсуждения. Это не есть принятое решение.