Главная » 2016 » Июнь » 20 » RB31. Публичный старт проекта "Роса"
13:13
RB31. Публичный старт проекта "Роса"
Предпосылки проекта "e;Роса"e; сформулированы в моей статье "e;Нужна ли России своя операционная система?"e; (июнь 2007 г.) С авторским вариантом в формате Adobe PDF можно познакомиться здесь - http://www.europrog.ru/rb/ros.pdf. Публикация прошла в журнале "e;Мир ПК"e;: №7/2007 и №8/2007. Заметки по началу проекта:RB22. О проекте создания отечественной перспективной ОС RB23. О языках реализации в проекте новой ОС RB25. Новая европейская ОС RB26. Дуальность и другие контуры "e;Росы"e; RB27. Пути восхождения к новой ОС RB28. Закон Гордона Мура и закон Дэвида Мэя Другие заметки, задающие контекст проекта: http://rbogatyrev.livejournal.com/2007/05/28/ ------ Мы постепенно подходим к завершению подготовительного этапа предпроектных исследований, который предшествовал официальному публичному старту проекта, намеченному на конец ноября. И переходим из разряда группы энтузиастов в несколько иной статус, который постепенно будет набирать свой вес. Та небольшая начальная команда (инициативная группа), которая сейчас сформирована (примерно 20 человек из России, Украины, Беларуси, Узбекистана), занималась эти несколько месяцев (с июля по ноябрь) прокладыванием лыжни по целине. В начале декабря, когда завершится важная часть предпроектных исследований, мы приступаем к набору двух групп - исследовательской и проектной. Это научно-исследовательское и проектно-конструкторское подразделения. Макетированием ОС (включая пробное проектирование отдельных элементов ОС) будет заниматься проектная группа. Правила будут опубликованы на официальном сайте проекта, который ориентировочно откроется в декабре 2007 г. Решение о включении в проект (в том или ином статусе) будут принимать руководители групп совместно с техсоветом. Поскольку неоднократно всплывает этот момент, хочу особо отметить: если у кого-то остались вопросы в отношении того, почему ОС "e;Роса"e; называется отечественной, скажу - основным рабочим языком проекта (который будет определять очень многое) является русский язык. Что касается национальности и вероисповедания участников, то это интересует в самую последнюю очередь. В нашем проекте будут задействованы участники из самых разных стран, но основу в силу ограничения рабочего языка проекта будут составлять страны бывшего Советского Союза. При этом мы планируем в перспективе формировать на её основе европейскую ОС (как в свете поддержки европейских языков, так и в свете расширения зоны её применения за пределы России). Проект "e;Роса"e; не занимается ни воссозданием UNIX, ни воссозданием Оберона. Он направлен на разработку отечественной операционной системы нового поколения с возможностью реорганизации её в европейскую ОС. Это будет перенацеливаемая (на разные ниши), безопасная, надёжная, компактная ОС, с эффективной поддержкой параллелизма, проектируемая в рамках открытого исследовательского программирования и при этом уходящая от технологического изоляционизма, свойственного академическим работам. Должен отметить, что с самого начала, как и ожидалось, мы столкнулись с активным неприятием нашего проекта. Такова жизнь. Есть люди, которые хотят заниматься созданием нового, понимают, сколь огромная работа предстоит и открыто её делают. Есть и те, кому это не нравится. Это не нравится некоторым апологетам UNIX и Linux, это не нравится некоторым апологетам Оберонов. Нормальная и понятная ситуация. С другой стороны, проект никоим образом не направлен на дискредитацию других проектов. Пусть каждый занимается своим делом. Видятся два варианта: 1) создаётся новое; 2) развивается старое. Государство движется по пути линуксоизации. Как говорится, флаг в руки. Мы же осознанно идём первым путем, при этом минимизируем свои риски (опираемся на хорошо проверенные временем решения, включая позабытые), в том числе и предусматриваем возможность появления подобных конкурирующих проектов (новой отечественной ОС с нуля) с сильной государственной поддержкой. Это кардинальным образом не повлияет на наши планы, просто сместит акценты и изменит масштаб работ. Создание отечественной ОС - не просто чисто технологическая задача. Речь идёт о социальных, культурных и экономических последствиях. Они особенно значимы, поскольку именно такая масштабная задача, которая ведётся в открытом режиме, способна сплотить разрозненные научные и инженерные коллективы, индивидуалов, стать мощным импульсом к развитию новой отрасли экономики - программной индустрии. В этом контексте проект "e;Роса"e; не ограничивается созданием ОС (точнее, семейства ОС), а затрагивает соответствующие стратегические цели. == Стратегические цели проекта 1. Достижение технологической независимости страны в отношении инфраструктурного программного обеспечения (ОС, базовый системный инструментарий, прикладные каркасы). 2. Создание национальной информационно-технологической инфраструктуры подготовки кадров и взаимовыгодного сотрудничества отечественных коллективов программистов (в широком смысле - страны бывшего Советского Союза). == Тактические цели проекта 1. Создание, развитие и предоставление в свободный и неограниченный общественный доступ современной перенацеливаемой ОС нового поколения (семейство ОС "e;Роса"e;). 2. Разработка открытой развиваемой инструментальной метасистемы, близкой к концепции лексикона программирования (развитие идей академика А.П.Ершова). 3. Практическое воплощение новой модели организации распределённого сообщества специалистов (открытое исследовательское программирование, Open Research Programming). Подходы к реализации проекта Итак, имеем три составных части проекта: 1. Целостный системный подход (операционная система как сложная программная система, метасистемное программирование). 2. Адекватный инструментарий (лексикон программирования: методология, языки спецификации и реализации). 3. Процесс открытой исследовательской разработки (Open Research Programming). Некоторые пояснения. При создании сложной программной системы требуется выделить значимые аспекты сложности, соответствующие критерии/метрики, принятую политику контроля сложности. Операционная система нового поколения должна быть многоцелевой (разные ниши). Это подразумевает наличие средств статического и динамического перенацеливания/адаптации ОС (под спектр задач, аппаратные платформы). Должна быть обеспечена технологическая независимость (от сторонних производителей) процессов разработки и последующего развития ОС. Это предусматривает наличие собственных систем программирования (независимость от изменений языка, независимость от сторонней реализации языка). Новая методология ориентируется на поддержку метасистемного и асинхронного программирования. Предусматривается целостная интеграция спецификаций (деклараций) и конкретизаций (программ) с контролем их рассинхронизации. Основу работы составляют три взаимодополняющих формы программирования (синтезирующее, сборочное, конкретизирующее - по А.П.Ершову), охватываемые лексиконом программирования - см. "e;Предварительные соображения о лексиконе программирования"e; (1983). Основные (привилегированные) языки формируют ортогональную систему (взаимодополняющий минимум языков, покрывающих ведущие парадигмы/подходы программирования). Ортогональные языки образуют два уровня - базис (собственное микроядро инструментария) и надстройку (минимум наиболее популярных языков). Что касается многоядерности и многопроцессорности, хотел бы подтвердить то, что они фигурируют как важные в манифесте проекта. Здесь стоит сослаться на ранее озвученные моменты (которые в том или ином виде входят в манифест): "e;Мы имеем чёткое представление о том, что новые процессорные архитектуры не могут эффективно использоваться существующими ОС (не только Windows и Linux). Это глубинные проблемы научно-технологического характера"e;. Некоторые комментарии. 1. С появлением новых процессоров мультиядерной архитектуры проблемы параллельного программирования (которые решаются с той или иной эффективностью для тех или иных классов задач в течение последних 4 десятилетий) стали проявляться с ещё большей силой. В виду того, что мультиядерность (multicore) ничего принципиально нового в теоретическом плане не представляет, но создает дополнительную специфику (ограничения) на решение задач распараллеливания. 2. Эффективное распараллеливание (в общем смысле) - неразрешимая задача. Её можно решать с той или иной степенью приближения для тех или иных классов задач при тех или иных ограничениях архитектуры и физических параметрах её представления. Понимание этого привело (не сегодня и даже не вчера) специалистов к мысли, что автоматическое распараллеливание без знания специфики языка программирования и конкретной задачи большей частью недостаточно эффективно. Нужны рекомендации (хинтовка) верхнего уровня. Это может обеспечить только программист (в широком смысле, не просто программист-кодер). Только после этого можно говорить об автоматическом распараллеливании (хотя хинтовка нужна и глубже - в нижних языковых слоях). В силу того, какие у него для этого есть инструменты - язык, специальные библиотеки, примитивы ОС и т.п. 3. К распараллеливанию можно подходить с двух сторон: со стороны синхронного параллелизма (в последовательном потоке управления выделяются параллельные ветви) и асинхронного параллелизма (нет последовательного потока, есть причинно-следственная связь, которая служит основой для распараллеливания). Оба подхода могут взаимно моделировать друг друга. Первый - является магистральным в этой проблематике. Второй - более перспективный. Достаточно познакомиться поглубже с работами В.Е.Котова и советским проектом МАРС (модульные асинхронные развиваемые системы). Наш проект я рассматриваю как естественное продолжение тех работ, но на ином уровне понимания, на новом ветке эволюции. 4. Технологическая проблема современных ОС (Windows, Linux, Mac OS X и др.) в отношении эффективного использования мультиядерных архитектур проистекает из-за отсутствия достаточно адекватной хинтовки со стороны программиста. Контурный портрет новой ОС Если говорить о контурном портрете, то можно выделить три главных момента: 1. Технологическое совершенство (метасистемное программирование, асинхронность, надёжность/безопасность, математический фундамент). 2. Контроль сложности (ортогональная система языков, микроядерность языкового базиса, инварианты, трансформации спецификаций). 3. Врождённое эволюционирование (перенацеливаемость, адаптивность, безболезненная расширяемость, вариативность). Чтобы минимизировать риски и получить универсальные решения, мы делаем ставку на перенацеливаемую ОС, то есть на такой полуфабрикат, который может быть в приемлемый срок при наличии адекватных ресурсов настроен и отмасштабирован на нужную нишу. Фактически Оберон-системы определяют новый перспективный класс ОС: Custom OS (настраиваемая ОС, сращиваемая с базовым приложением). Она занимается всё теми же задачами любой ОС: распределение ресурсов и управление процессами, при этом может работать поверх другой ОС (виртуализация приложений). Оберон-системы определяют ещё один класс ОС: Developer's OS. Это особый мир для разработчика, который позволяет ему получить максимально удобную инструментальную среду (не просто IDE или среду программирования), которая является и операционной средой для всех приложений этого мира. Чтобы делать перенацеливаемую ОС, надо с чего-то начать. Выбрать несколько ниш (прикладные, системные), на которые и будет в первую очередь нацеливаться новая ОС. По мере конкретизации проектных решений можно одновременно переходить к продумыванию возможностей перенацеливания построенных решений на другие ниши. В сфере ОС мы идём от двух полюсов - UNIX и Оберонов. UNIX - это хорошо известный готовый фундамент годами отшлифованных решений, который можно применять в тактическом плане. Что касается много менее известных Оберонов, давайте посмотрим, на что ориентировались Oberon System и Bluebottle. Oberon System создавалась как система для программистов. Свой собственный мир. Самодостаточный. Удобство технологического процесса применительно к языку Оберон. Т.е. это ОС класса Developer's OS с ограничением на количество базовых языков - система принципиально моноязыковая. Побочным следствием (ответвлением) Oberon System стала возможность использования её в качестве "e;браузер-машины"e;. Т.е. в ней были зачатки Web OS. В середине 1990-х (когда решения Oberon System в этом направлении соответствовали рыночной ситуации развития) можно было говорить о конкурентноспособности. В нынешней ситуации отставание заметное (не идейное, а конкретных реализаций). Центральной в системе Оберон является концепция активных документов (вместо низкоуровневой ориентации на файлы). Ввод-вывод программ можно унифицировать через единое представление - через документ. В активный документ можно встраивать всё что угодно (аплеты и сам этот термин впервые появились в системе Oberon в начале 1990-х годов). В системе Oberon документ становится единой, ключевой сущностью для пользовательского интерфейса. Более того, приложение воспринимается как документ. Любые элементы документа (включая даже заголовки окон) могут интерпретироваться на лету (их нужно просто выделить и нажать "e;кнопку"e;, если только не предусмотреть принудительное блокирование таких операций). Ведь их универсальный интепретатор (система Oberon) всегда под рукой. В свете нынешнего противостояния Microsoft-Google актуальным становится новый взгляд на пользовательский интерфейс, новые механизмы его поддержки (что мы, разумеется, учитываем в рамках создания "e;Росы"e;). Он должен быть всепроникающим. Потому-то и неизбежен интерес к позабытым решениям, которые были построены два десятка лет назад (когда люди основательнее думали и обстоятельнее работали). Впрочем, в Microsoft Research сейчас несколько групп вплотную заняты подобной проблематикой. В одной из них (в Кембриджской лаборатории, в Англии) работает один из участников проекта Oberon Ральф Соммерер - ученик Никлауса Вирта. Он также входит в состав Microsoft Live Labs. Напомню, что система Oberon создавалась под влиянием идей той самой системы Cedar (Xerox Palo Alto Research Center, 1978-1986), которую теперь представляют как прообраз нынешней Microsoft Singularity. Причем разработка основы Oberon System заняла... 5 человеколет (два профессора ETH Zurich - Никлаус Вирт и Юрг Гуткнехт, 1985-1988). Теперь взглянем на Bluebottle (детище команды проф. Гуткнехта). В этой системе уже сделана попытка уйти от моноязыковости (за счёт поддержки Java). Но сама система в меньшей степени Developer's OS (хотя внутри хранит старый облик системы Oberon) и больше заточена на пользователя, которому нужны эффективные средства обработки мультимедиа-информации. Потому и сделан акцент на производительность для подобных задач (с учётом мультипроцессорности). Потому и налажены контакты с коммерческими структурами (Япония, Китай), за счёт которых и осуществляется развитие и продвижение проекта. Некоторые характеристики. Ядро Bluebottle (Aos) занимает 7 тыс. 210 строк исходных текстов на Active Oberon (около 50 Кбайт объектного кода). Файловая система, сетевые средства, сервисы и пользовательский интерфейс добавляют еще 15 тыс. 560 строк (140 Кбайт). Для сравнения: ядро BSD 4.4 занимает 58 тыс. 289 строк на Си (за вычетом файловой системы, сетевых протоколов, драйверов устройств и др., которые добавляют еще 143 тыс. 962 строки исходного текста). Ядро Linux 2.4 занимает около 420 тыс. строк (исключая файловую систему, драйверы и др, которые добавляют еще около 2,4 миллиона строк). В Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux. Это связано с сокращением накладных расходов в том числе за счет уменьшения дескрипторов. По классификации я бы отнёс Bluebottle к классу Custom OS, когда можно к готовому ядру и базовому системному каркасу достыковать необходимый технологический сервис и получать в итоге заточенную под задачи специализированную ОС (BlackBox - ещё один пример подобного применения, только здесь ОС спрятана, а инструментарий поставлен во главу угла). Нетрудно заметить, что вариант Custom OS есть ни что иное как перенацеливаемость полуфабриката. BlackBox реализует схему виртуализации приложений, когда распределение локальных ресурсов и управление локальными процессами (действующими в рамках единого адресного пространства) находится в ведении самой прикладной системы (её ран-тайма). Из подобных подходов можно отметить средства компании GreenBorder, недавно тихо поглощенной Google. Её средства обеспечивают поддержку безопасных контейнеров, внутри которых можно запускать браузеры, видео- и аудио-плееры. Рекомендуемые источники по ETH Bluebottle: Официальная страница проекта Bluebottle. Ярослав Романщенко. Установка и настройка Bluebottle. Реализация Bluebottle поверх Windows: ETH WinAos System (Bluebottle for Windows). H.Eberle, J.Gutknecht. Architectural Support for Online Multimedia Services (1999). P.Muller. The Active Object System Design and Multiprocessor Implementation (2002). P.Reali. Using Oberon's Active Objects for Language Interoperability and Compilation (2003). T.Frey. Bluebottle: A Thread-safe Multimedia and GUI Framework for Active Oberon (2005). "e;Бутылка без джинна (Oberon и нелетние мысли)"e; (Компьютерное обозрение, 23.07.2002). Несколько слов о Microsoft Singularity, которую мы рассматриваем как нашего технологического конкурента. По многим причинам. Одна из них - идеологическая близость (надёжность ОС зависит от языка). Во главу угла в Singularity ставят (по крайней мере, декларируют) надёжность и безопасность (reliability, safety, security). Что вкратце предлагает Singularity? Основной их тезис: можно с нуля построить новую ОС, которая во главу угла ставит надёжность/безопасность, а не производительность. При этом её производительность оказывается даже выше, чем у известных ОС. Главная идея - герметизация всего по возможности. В основе Singularity лежит триада: SIP-CBC-MBP. Объектное пространство (SIP, software-isolated processes), регламентированные каналы (CBC, contract-based channels), декларированные программы ("e;таможенная декларация"e;, MBP, manifest-based programs). Быстродействие системы достигается за счёт исполнения большой части кода в режиме ядра (SIP является аналогом пропускной системы, предъявил пропуск - на территории можешь действовать как свой). В этом плане явные параллели с Oberon System и Bluebottle (аналогично, с их американскими прототипами - Xerox Mesa и Xerox Cedar). Понятие адресного пространства вытесняется (но не заменяется!) понятием объектного пространства. При этом для организации объектного пространства не требуется аппаратной защиты памяти. Внутри объектного пространства можно порождать активности (потоки/нити, threads). При этом герметичность обеспечивается жёстким требованием: нельзя разным объектным пространствам иметь ссылки на чужое внутреннее содержимое, т.е. можно обмениваться ссылками только на объекты, хранящиеся в общей памяти (Exchange Heap). Всё взаимодействие строится через каналы. Они и определяют унифицированный механизм обмена. Что важно: каждое объектное пространство может иметь свой менеджер памяти (сборщик мусора) и свою исполняющую систему (ран-тайм). Это важное отличие от Оберонов. При оценке Singularity уже явно сформировался неверный стереотип. SIP не отрицает комбинированные варианты использования адресного пространства. Помимо SIP есть и HIP (hardware-isolated processes, процессы в понимании UNIX, с аппаратной защитой памяти). Это задаёт гибридные схемы. Что ценно в Singularity - система явно заточена под сетевую среду: унификация общения между объектными пространствами позволяет осуществлять это как вблизи (в рамках одного мультиядерного процессора), так и вдали - между аппаратными кластерами и удалёнными компьютерами. Ахиллесовой пятой является расширяемость - здесь у Singularity больше вопросов, чем ответов. Неудобство описания каналов вполне разрешимо - достаточно (как и в реальной жизни) иметь типовые контракты, которые просто конкретизировать (т.е. не делать всегда с нуля). Отталкиваясь от Модула/Оберон-направления и анализируя Singularity (а также две интересные в этом плане европейские ОС - английскую RMoX (Raw-Metal occam Experiment, на основе Occam-pi) и немецкую JX (на основе Java), мы ориентируемся на одно из главных их достижений - локализация сущностей (модули-отсеки) и безопасность работы с памятью, обеспечиваемая средствами языка. Это позволяет прийти к понятию особых safe-активностей, которые могут взаимодействовать в рамках единого адресного пространства без лишних накладных расходов. Очевидно, что появляются надёжные (safe) и ненадёжные (unsafe) зоны. Те и другие могут быть проверены (вручную, верификацией, тестами и т.п.), после чего могут переходить в разряд проверенных (trusted). Эти механизмы напрямую связаны с вопросами информационной безопасности. Хорошо известно, что полноценное её обеспечение (для trusted OS) требует проработки на самом нижнем уровне (вплоть до микроядра). Попытки поверх ненадёжной схемы навесить потом прибамбасы защищённости - это в корне неверный подход. Дыры закрыть не удастся. Несмотря на исследовательский характер работ Microsoft Singularity её ориентируют (заявляют о нишах) в отношении серверного направления (Server OS). Рекомендуемые источники по Microsoft Singularity: Официальная страница проекта Singularity (Microsoft Research). "e;Проект Singularity: обзор"e; (RSDN, 02.03.2006). "e;Возвращение микроядерных операционных систем"e; (Открытые системы, 5/2006). "e;Надёжные и защищённые операционные системы?"e; (Открытые системы, 6/2006). "e;ОС Singularity, или Когда надежность становится требованием"e; (Компьютерное обозрение, 26.01.2007). Олег Михайлик. Singularity. Что получается: исходя из наших ближних ориентиров (Oberon System, Bluebottle, Singularity) вырисовываются три ниши -- Developer's OS, Web OS и Server OS. Важно обратить внимание на следующее обстоятельство. Подход к ОС у нас не лобовой, а "e;окольный"e; (высокотехнологичный): 1. Методология. ОС - сложная программная система, для распределённой коллективной разработки которой надо применять соответствующую методологию (методологию надо сначала разработать, а потом реализовать её инструментальный фундамент). 2. Языки. Языковой базис (структура и конкретные языки) играет ключевую роль в разработке и контроле сложности. 3. Формальные модели. Компактность, надёжность и адаптируемость ОС может быть достигнута за счёт применения формальных моделей (конечные автоматы, сети Петри, нейронные сети). Эта триада "e;методология-языки-формализмы"e; критична для реализации новой ОС. Её надо будет делать (можно и в параллель с макетированием). Но раз она будет, имеет смысл учитывать её наличие как автоматически получаемое дополнительное потребительское качество новой ОС. Если удастся реализовать намеченную программу, то мы автоматически получаем основу для Developer's OS и Custom OS. Тем не менее, здесь не стоит наступать на грабли Oberon System, когда система для разработчика потом эволюционирует (анархично) в сторону конечного пользователя - это приводит к очень конечному числу таких конечных пользователей. Но стоит понимать, что Developer's OS - скорее системная ниша. В качестве потребительского (прикладного) ориентира интерес для нас представляет Web OS. Мы её рассматриваем не в узком смысле (как это делает Google). Т.е. не только удалённых сервисов и минимального слоя поддержки на стороне клиента (тонкий клиент). Google исходит из доминирования Microsoft на клиенте. Мы же можем набраться наглости и исходить из нашего клиента (полностью), как это делает и сама Microsoft. Соответственно будет и наш сервер (в понимании задач Web OS, т.е. связка с Server OS). Клиентский вариант Web OS может быть как максимально усушенным (до уровня ОС в мобильном телефоне), так и полноценно развит - на массовых ПК (и далее). Серверный вариант для Web OS может быть конкретизацией серверной ОС. Идея использования Web OS в качестве отправной прикладной ниши имеет заметную привлекательность - это горячая зона развития технологий. Тут ещё не устаканились требования и стереотипы, что даёт нам возможность творить на своё усмотрение. Сюда могут охотно пойти нужные нам кадры. При этом здесь требуется много меньше работы, нежели для повторения функционала традиционной клиентской ОС. Кроме того, именно в этой области играет наш козырь (продуманная безопасность, опирающаяся на языковую защиту, на принципы герметичности), который является весьма привлекательным фактором в потребительском отношении. Распараллеливание (на мультиядерной процессорной архитектуре) здесь может быть выполнено относительно грубо, прикидочно. Нет таких требований, как к той же серверной ОС. Вот там адаптивный тюнинг параллелизма, включая нейронные сети, будет очень кстати. "e;Роса"e; (в ряде своих конкретизаций) по всей видимости не будет сильно отступать от общемировой тенденции использования гипервизоров (hypervisors), мониторов виртуальных машин - единого центра управления виртуальными машинами для разных ОС. Это означает потенциальную возможность одновременной работы "e;Росы"e; с несколькими внешними/гостевыми ОС (семейств Windows, Linux, Mac OS X). А также будет обеспечивать подъездные пути для того, чтобы сама "e;Роса"e; могла запускаться в известных гипервизорах (напр., под английским Xen). Первые впечатления Теперь о некоторых наблюдениях по итогам предпроектных работ. Довольно неожиданным для меня эффектом нашей работы стало сразу рельефно проявившее себя отличие используемой нами модели открытого исследовательского программирования (Open Research Programming) от традиционной модели программирования c открытыми исходными текстами (Open Source). В первом надо сначала много думать, сохранять по возможности максимальную вариативность с выделением магистральных решений и лишь потом делать (при уточнении всех требований и ограничений разработки). Во втором предпочитают сразу "e;прыгать"e;. Это влияет не только на микроклимат в команде (далеко не все готовы окунуться в принципиально иную среду работы), но и на подход к выбору проектных решений. Т.е. то, ради чего модель Open Research Programming и задумывалась (взвешенный, обоснованный выбор проектных решений), стремятся подменить традиционной спешкой с передачей функции принятия решений сразу конкретным исполнителям. К чему это ведёт? В исследованиях важно осознавать недостатки уже существующих и применяемых подходов, проводить тщательный анализ, на основе которого и вырабатывать новые. Эти новые требуют терпеливого ухода и заботы (иначе они просто никогда не вырастут). Это особая форма кредитования доверия к идеям. Важно найти необычные, неординарные подходы и постепенно, шаг за шагом пытаться довести их до "e;товарного уровня"e;, до уровня конкуренции с существующими (даже просто продумыванием и отчуждаемым изложением всех деталей). Только тогда можно приниматься за полноценную активную критику. Если с порога отметаются идеи, а взамен, не изучив и не проработав толком новые, предлагается опираться на известные (метод "e;реклея"e; - резать и клеить) - это не исследования; это разработка. И, к большому сожалению, вроде бы столь элементарная вещь с большим трудом доходит до осознания теми, кто интересуется проектом или в нём участвует. Значит, надо больше и детальнее разъяснять. Это потребует много больших затрат времени и сил, но иначе стену непонимания вряд ли удастся ликвидировать. Как руководитель проекта я стараюсь консолидировать разные взгляды и точки зрения, сохраняя вариативность в ожидании убедительной аргументации и результатов исследований. Тем не менее, форма блога (этих заметок) позволяет высказывать личную точку зрения, которую не нужно воспринимать как нечто официально утверждённое и принятое к исполнению. Речь идет о контурах для исследований. Ближайшие планы Для реализации проекта нами выбрана соответствующая организационная форма: образование нового юридического лица (новой компании). Одним из важных партнёров проекта отечественной операционной системы "e;Роса"e; будет известное патентное бюро "e;Романовы и Партнёры"e;, которое берёт на себя все вопросы, связанные с охраной промышленной и интеллектуальной собственности, включая ведение патентного поиска. О планах работ на ближайшее время: 1. Первое публичное представление проекта: 30 ноября 2007 г. (семинар по системному программированию в Московском авиационном институте, МАИ). 2. Образование новой компании (центр управления проектом): начало декабря 2007 г. 3. Открытие трёх сайтов (сайта новой ОС, сайта новой компании, нового сайта Европейского центра программирования): декабрь 2007 - январь 2008. 4. Начало формирования исследовательской и проектной групп: декабрь 2007- февраль 2008. 5. Подбор научных консультантов и технических экспертов: декабрь 2007 - март 2008. Среди консультантов и экспертов, уже давших предварительное согласие на участие в проекте, - ведущие специалисты из научно-исследовательских институтов (по линии РАН), представители профессорско-преподавательского состава вузов России, специалисты ряда отечественных ИТ-компаний. В качестве образца-ориентира для ведения проекта подобного масштаба и направленности, а также формирования технологических решений выбран советский проект МАРС (Модульные асинхронные развиваемые системы, 1985-1988; ВЦ АН СССР, ВЦ СО АН СССР, Институт кибернетики Эстонии), проводившийся ВНТК "e;СТАРТ"e;. Цели и основные положения проекта "e;Роса"e; будут отражены в готовящемся манифесте проекта, который станет основной декларацией намерений. Принятие манифеста является обязательным условием участия в нашем проекте.
Просмотров: 389 | Добавил: AdnrNick | Рейтинг: 0.0/0
Всего комментариев: 0
avatar