| Организационные моменты
Прошло чуть больше месяца с начала старта проекта создания новой ОС с названием "e;Роса"e;. Это время прошло в бурных и, надеюсь, плодотворных дискуссиях, посвящённых следующим вопросам:
1. Цели проекта и пути их достижения
2. Требования к ОС
3. Процессорные архитектуры
4. Языки и межъязыковое взаимодействие
5. Внутренняя информационная инфраструктура
Выявились разные подходы к ключевым аспектам, которые непосредственно связаны с проектом. Несмотря на расхождения во взглядах, попробую резюмировать работу и заодно — очертить более конкретные контуры будущей ОС.
Создавая новую ОС, мы начинаем с двух "e;миров"e;, которые видятся наиболее оптимальными отправными точками: с UNIX ("e;прагматики"e;) и Оберонов ("e;романтики"e;). Собственно и команду формируем преимущественно из этих миров. Оба мира интересны тем, что там концентрируются идеи и люди, в большей степени исходящие из понятий инженерной продуманности и технологического совершенства, а не из ориентации исключительно на потреб рынка (хотя куда без него).
В команду пришли очень компетентные специалисты, которые имеют свои идеи и которые намерены их в том или ином виде воплотить в проекте. Сейчас мы находимся в режиме поиска основы совместной работы, ограничиваясь пока формой внутренних дискуссий.
Подходы к обсуждению направлены на выявление контуров будущей ОС (постепенное "e;протаивание"e;). При этом видны как прагматические, приземлённые взгляды (тяготеющие к известным подходам и решениям), так и романтические, "e;витающие в облаках"e; (ставящие под сомнение существующие подходы). Сейчас (как минимум, ближайший год, до начала проектирования) в нашем проекте время романтиков (прагматики в оппозиции, потом, после принятия решений, будет всё наоборот). Мы на стадии исследований, ревизии существующего мирового хозяйства ОС, ведения конкурентной разведки. Поэтому лучше подвергать сомнению устои системного программирования, нежели сразу вставать на ту или иную сторону. Лучше намечать контуры, оставляя место вариациям, но выделяя приоритеты. Собственно, объединение в проекте сил по UNIX и Оберонам рассматривалось и с этой точки зрения. Прагматики должны регулярно опускать на землю "e;зарвавшихся"e; романтиков. Но без романтиков заниматься этим проектом почти бессмысленно. Как и без прагматиков. В отношении проекта уже очерчиваются контуры "e;спринтеров"e; и "e;стайеров"e;, специалистов в конкретных дисциплинах и "e;многоборцев"e;. Желательно не растерять плюсы тех и других.
Надо сказать, что идеи Open Source Initiative и "e;базарная модель"e; Эрика Реймонда наложили свой отпечаток на восприятие методов коллективной работы над открытым программным обеспечением. Как выясняется, это достаточно сильный стереотип. Желание начать кодировать и строить проект сразу вокруг единой базы исходников сталкивается с непривычными, новыми взглядами (инициативы Open Research Programming) на ведение проектов подобного масштаба силами географически распределённых специалистов, которые работают "e;за идею"e;. Как уже отмечал, ключевой недостаток для создания ОС — свобода распределённого программирования для сложных систем подобного масштаба может давать эффект лишь при наличии уже кем-то сделанного базиса. Напомню то, о чем ранее писал в своих заметках. Организационно-технологический аспект в устах Эрика Реймонда в “Соборе и базаре” (1997) выливается в несколько пунктов. Главным из них он называет децентрализованный характер разработки при наличии у всех участников свободного доступа к исходным текстам. Пресловутый “базар”. При этом отмечает зону эффективности “базарной” модели разработки. Это наличие “печки”, от которой и вокруг которой все танцуют: “Абсолютно ясно, что никто в одиночку не может с нуля создать программу, опираясь на “базарную” модель. Один человек вполне в состоянии тестировать, отлаживать и совершенствовать программу, придерживаясь такого подхода, но будет крайне сложно начать реализацию проекта в “базарном” режиме. Так не делал Линус. Так не делал и я. Для зарождения сообщества разработчиков требуется работоспособный и готовый к тестированию продукт”.
Пока нет основы, базиса, "e;базарная модель"e;, в которой участвуют многие разработчики с разными взглядами на проектирование и реализацию, ведёт к хаотическому программированию, в котором получение качественной, технологически хорошо сбаланированной системы – дело случая. Если не делается, разумеется, по кальке с готового.
Следовательно, если создаётся нечто новое, такой базис нужно сформировать. Как это сделать? Видятся следующие этапы:
1. Подготовка основных документов, определяющих цели и рамки проекта, – манифест новой ОС.
2. Определение путей достижения целей проекта (стратегическое планирование).
3. Формирование исследовательских и производственных подразделений.
4. Тактическое планирование и управление работами в рамках соответствующих подразделений.
5. Проектирование и реализация базиса.
По завершению этих этапов (которые и определяют НИОКР, специфичные для Open Research Programming) можно будет переходить к работе по созданию (производству) ОС либо в рамках, традиционных для Open Source Initiative ("e;базарная модель"e;), либо в корпоративном стиле ("e;соборная модель"e;).
То, что мы сначала по сути строим свой исследовательский центр (имея в виду модель Open Research Programming), который готовит в том числе подъездные пути для интенсивных консультаций с внешним миром (и не только на основе "e;низкоуровневых"e; сообщений в форумах), несколько отличает нас от других команд. Лучше сначала думать, обсуждать, советоваться, опять думать, находить лучшие решения, а только потом делать. Тем более в такой сфере, где конкурировать даже технологически (не то что рыночно) очень непросто.
Чтобы получить хороший результат, надо постараться продумать и правильно выстроить процесс его получения. Собственно говоря, мы сейчас в организационном плане и выстраиваем свою открытую исследовательскую лабораторию, заточенную исключительно под проект "e;Роса"e;. А не пытаемся с места в карьер, да еще сломя голову бросаться кого-то догонять.
Одной из важных задач ближайших недель является подготовка пакета базовых документов, которые должны вобрать в себя манифест новой ОС (включая требования к ней), а также правила и рекомендации по ведению работ в рамках проекта. Несмотря на то что первый год запланирован на формирование команды и ведение исследований, предшествующих проектированию, вполне вероятно, что черновое проектирование ОС и экспериментальную реализацию отдельных компонентов мы сможем начать уже этой осенью.
Технологические вопросы
Оставим теперь в стороне организационные вопросы и разберём некоторые технологические. На мой взгляд, в проекте "e;Роса"e; лоб в лоб сталкиваются казалось бы противоречивые требования старого и нового: желание сделать систему, которая была бы совместима с известными ОС (уход от изоляционизма) и которая построена в то же время иначе, на иных основах, с учётом анализа причин современного кризиса в создании сложных программных систем и, в частности, операционных систем.
Можно ли совместить несовместимое? Можно, и тому есть примеры. Сначала о том, как совместить, а потом уже о примерах (на закуску).
Контуры новой ОС вырисовываются в сопоставлении трёх миров: хорошо зарекомендовавшего себя UNIX (в центре нашего внимания QNX и MINIX 3, а также пост-UNIX в лице Plan 9), революционного экспериментального Оберона (Oberon System, BlackBox, Bluebottle) и модного исследовательского Singularity.
Singularity – это попытка Microsoft Research использовать идеи Оберона в несколько ином ракурсе. Нельзя сказать, что Обероны они не упоминают в своих работах, но при этом старательно размазывают реальный источник и суть заимствования.
Небольшая справка. Виртовские проекты Lilith/Modula-2 и Ceres/Oberon были во многом стимулированы американскими проектами Xerox Alto (Mesa) и Cedar. Причём даже не заочно-теоретически, ибо проф. Вирт ездил в Xerox PARC и имел прямые контакты с исследователями этой знаменитой лаборатории. Поэтому в отношении виртовских вещей (включая и Bluebottle Юрга Гуткнехта) корректней говорить не как о чём-то принципиально новом, а как о более чётко расставленных акцентах (чисто инженерные решения) на в общем-то известных до этого вещах. Т.е. компактная сбалансированность, сочетаемость идей и механизмов. Целью Вирта в его проектах было показать, как можно добиться совершенства путем разумного упрощения железа и софта. Возможно, здесь к месту будут слова Антуана де Сент-Экзюпери: "e;Совершенство достигается не тогда, когда уже нечего прибавить, а когда уже ничего нельзя отнять"e;. На сайте EuroProg выложено немало редких материалов по проектам Alto/Mesa и Cedar, а также Lilith/Modula-2 и Ceres/Oberon.
Относительно Singularity. Надо понимать, что это — один из исследовательских проектов Microsoft Research. Он заслуживает внимания, причем повышенного, но не того "e;придыхания"e;, которое мне встречалось в некоторых форумах. Магия имени Microsoft играет с людьми злую шутку. Немногие представляют себе внутреннее устройство Microsoft Research и специфику их работы. В проекте ETH Bluebottle, насколько мне известно, было занято около 3-4 человек. В проекте Singularity — на порядок больше. Считается, что это крупнейший исследовательский проект в стенах Microsoft Research, в который вовлечены специалисты из разных исследовательских подразделений. Он был инициирован производственными подразделениями Microsoft: Microsoft Core Operating System Division (COSD) и Microsoft security team. Прицел: на рынок встроенных ОС (embedded OS) и серверных ОС. Масштаб: порядка 300 тыс. строк. В качестве образца-прототипа они (точнее, лидер проекта — Galen Hunt) называют... разумеется, Xerox Cedar (а не Oberon и не Bluebottle). Декларируемая ими сверхзадача: показать, как можно писать компактную конкурентноспособную ОС с нуля, используя возможности обеспечения надёжности за счёт языка реализации высокого уровня (Sing#) и языкового инструментария (Bartok).
Для информации: впервые в публичном доступе Bluebottle появилась 1 января 2003 г. Проект Singularity (как это неоднократно отмечалось в различных интервью 2005 г.) стартовал в 2003 г. Тогда как первый программный документ Singularity Design Motivation (своего рода манифест проекта) появился в декабре 2004 г.
Если говорить о возможности концентрации интеллектуального потенциала, то в случае "e;Росы"e; в количественном выражении он в перспективе будет сопоставим с Singularity team в Microsoft Research (возможно, даже выше). Но количество не всегда переходит в качество, поэтому придется попотеть, чтобы работа внутри команды была продуктивной. Да и гандикап в пять лет будет давать о себе знать, но у нас есть преимущество — мы детально видим перед собой их "e;грабли"e; (и вполне неплохо разбираемся в том, что они называют своими ориентирами). Они опираются на тройку: SIP — CBC — MBP; software-isolated processes, contract-based channels и manifest-based programs. Уже сейчас можно сказать, что наши решения будут отличаться. И даже не в деталях.
Мы будем создавать нечто новое, технологически новое (иначе проект теряет смысл), но при этом постараемся сделать так, чтобы не оказаться в изоляционизме (в том числе и технологическом), как это произошло с Оберонами.
Теперь несколько скучных теоретических моментов.
В упомянутой тройке UNIX-Oberon-Singularity последние два подхода к ОС опираются на надежность языка реализации высокого уровня. В UNIX же повсюду присутствует низкоуровневость: язык Си, процессы, файлы. В системе Oberon эти ключевые вещи представлены на более высоком уровне абстракции: язык Оберон, модули, документы (даже приложение – это документ).
Как показывает опыт, чем проще система (язык), тем выше её стабильность во времени (меньше "e;период полураспада"e;). UNIX и Oberon — примеры простых по архитектуре систем, выполненных на простых языках программирования. Первой уже насчитывается почти 4 десятка лет, второй – почти 2 десятка. И это очень важный фактор, который мы учитываем.
ОС и язык программирования – очень близкие вещи, в пределе — сливающиеся. С незапамятных времен язык (его реализация, система программирования) нередко подменял собой ОС (можно даже для красного словца вспомнить Бейсик, хотя он тут не первопроходец). Т.е. в определённом смысле можно считать язык (его реализацию) и ОС разными гранями одного и того же. Это важный момент.
Исполняющая система языка (run-time system) вместе со стандартными библиотеками может плавать поверх ОС, а может плавать поверх голого железа. В этом случае неизбежно приходят к мысли об особой роли такого языка, даже об (абсолютной) моноязыковости. Между железом и языком (ОС) может лежать демпфирующий абстрактный слой, унифицирующий оборудование (виртуальная машина просто как пример). В этом случае вполне можно говорить об относительной моноязыковости, поскольку этот слой вполне в силах взять на себя заботу о сосуществовании разных моноязыковых миров (как взаимодействующих, так и просто мирно сосуществующих в изоляции). Собственно Вирт и его команда отстаивают идею моноязыковости, когда язык фактически растворяется в своей ОС (но при этом может плавать поверх чужой).
Итак, ОС и язык программирования (точнее, его реализация — система программирования) в пределе могут считаться одной и той же сущностью. Будем считать это некоей гипотезой и посмотрим, что она может нам дать для понимания.
В самом деле, любая ОС является программной системой (как и система программирования). Она имеет дело с унифицированным управлением задачами и распределением ресурсов (чем занимаются многие системы программирования). У языка программирования (его реализации) есть ядро — исполняющая система (run-time system). В этом смысле ОС и язык близки (для простоты изложения буду иногда приравнивать язык к его реализации; надеюсь, из контекста будет понятно, что в действительности подразумевается).
ОС работает не только сама по себе, но и обеспечивает взаимодействие с ней двух основных сущностей (людей и программ). Про третью сущность — внешнее оборудование — на время забудем, приравнивая её к программам (драйверам).
Взаимодействие с ОС обусловлено разными языковыми слоями ОС:
программный (API, процедурный интерфейс системных вызовов),
командный (CLI, command language interface),
пользовательский (UI, реализуемый обычно через GUI).
Первые два относительно легко поддаются чёткому и однозначному описанию. С третьим – напряжёнка. "e;Плавает"e; и весьма неоднозначно отражается в документации. Собственно, исходя из этого можно делать UNIX-подобную ОС в любой комбинации этих языковых слоёв (например, реализовать только командный или программный).
Если мы взглянем на язык (систему программирования), то увидим, что аналогом командного интерфейса ОС для языка программирования является сам язык, а пользовательского — интерфейс инструментальной среды (IDE). Программный же интерфейс для языка обычно требуется, если обеспечивается API-интеграция с другим языком (когда язык является "e;сервером"e;, которого вызывает язык-клиент).
Пойдём дальше. Взглянем на две интересующие нас ОС, которые точно можно считать разными по архитектуре: UNIX и Oberon System.
В первой ОС главной единицей исполнения является процесс. Во второй – модуль (далее под этим словом подразумевается модуль в понимании модульного программирования, точнее, языков Modula-2 и Oberon). Процесс в UNIX – это не языковое понятие. У него нет конкретного отображения на языковую сущность (это и хорошо, и плохо). Модуль же имеет однозначный аналог в языке (Обероне) – сущность с тем же названием "e;модуль"e; (из-за чего нередко происходит терминологическая путаница – о языковом модуле идет речь или об исполняемом). Это также и хорошо, и плохо.
Модели Вирта оказалось достаточно, чтобы гармонично соединить язык и ОС. Т.е. представить ОС как "e;обычную"e; программную систему, реализованную на данном языке, причем оставаясь в рамках языка. Модуль в системе Oberon – это почти процесс в UNIX. Почему "e;почти"e;? Потому что он не является изолированной сущностью, работающей только в своём адресном пространстве, а связан и взаимодействует с другими сущностями –- другими (загруженными и исполняемыми) модулями.
Основу основ любой ОС составляют средства мультипрограммирования (multiprogramming, multitasking), т.е. средства диспетчеризации (планирования) процессов (задач). Думаю, стоит даже считать UNIX'ом любую ОС, которая использует именно UNIX-механизм мультипрограммирования (вне зависимости от реализации языкового слоя – программного, командного, пользовательского).
Вспомним классику: монитор Хансена-Хоара. Это и есть специальный модуль в понимании модульного программирования (вынесенный на уровень языка), который обеспечивает основу мультипрограммирования. Собственно говоря, начиная с языка Modula (мониторы, модули устройств), Вирт уделял внимание, прежде всего, этому аспекту – сведению мультипрограммирования (т.е. задач ОС) к уровню языка программирования. В Modula и Modula-2 были эксперименты с сопрограммами (заимствованными из Симулы). В Обероне была уже несколько иная модель, но сохранившая идею совмещения понятий языка с понятиями ОС.
Виртуальная машина ОС и виртуальная машина ЯП (языка программирования) — понятия близкие, хотя и разные. Обе отвечают за абстрагирование от нижележащего исполняемого слоя (будь то оборудование, другая виртуальная машина или иное ПО). Предполагается, что конструкция виртуальной машины напоминает конструкцию реального оборудования (в частности, процессора), т.е. снаружи это выглядит как чёрный ящик с интерфейсом в виде набора команд (инструкций) и правил их использования. Если для исполнения языка программирования на разных процессорных архитектурах совсем не обязательно иметь виртуальную машину (работы М.Франца 1994 г. по динамической кодогенерации на основе семантического словаря – лишь один из альтернативных вариантов решения), то несложно сделать вывод о том, что и ОС совсем не обязательно реализовывать через виртуальную машину (с сохранением и приумножением всех достоинств абстрагирования).
Отсюда также следует, что взгляды на то, что есть ядро ОС, что есть микроядро, экзоядро и т.д. (гранулировать можно по-разному), могут быть пересмотрены с учётом усиления возможностей контроля сложности ОС средствами языка высокого уровня.
В конечном итоге ОС — это программная система. И она должна подчиняться законам конструирования программных систем. Можно, конечно, считать архитектуру ОС наиважнейшей и игнорировать конкретный язык реализации. Но можно и не игнорировать. Второе направление (наличие языкового контроля) представляет особый интерес (не забывая, разумеется об архитектуре ОС).
UNIX и Oberon – два полюса, две крайности. Дело за "e;малым"e; — тщательно и критически переработать накопленную информацию (а также раздобыть уточняющую) и попробовать найти новое решение. Желательно (для преемственности и гарантии практичности), чтобы оно позволяло понятным образом трансформироваться в предельные сущности — процессы UNIX и модули Оберона.
Практические контуры
Теперь к от теоретических рассуждений к практическим контурам новой ОС. К совмещению несовместимого.
Новая ОС может быть сделана дуальной. Иными словами, у неё снаружи могут быть доступны два мира – высокоуровневый (обероноподобный) и низкоуровневый (UNIX). Они сосуществуют друг с другом исходя из простого принципа – надёжный модуль (safe), использующий хотя бы один ненадёжный модуль (unsafe) считается ненадёжным.
В новой ОС осуществляется отход от моноязыковости. Выделяются два вида языков: привилегированные (пост-Оберон, Haskell, Python) и непривилегированные — Си и Java. Привилегированные языки тесно связаны своими исполняющими системами и обеспечивают гармоничную работу с ОС на уровне её высокоуровневых концепций. Непривилегированные работают в традиционном режиме и обеспечивают обогащение новой ОС унаследованным ПО из мира UNIX (GNU и др.) и мира Java (включая инструментарий Eclipse). Для переноса программного обеспечения из UNIX полноценным образом реализуется операционная платформа POSIX.
Таким образом, не вдаваясь в детали внутренней реализации ядра и других компонентов ОС (как и на каких языках), можно уже говорить о том, что её дуальность позволит решить проблему совместимости несовместимого. При этом сохраняются два этажа абстракций: низкоуровневый (от UNIX) и высокоуровневый (родной для новой системы).
Стоит упомянуть и о служебной для ОС ("e;бортовой"e;) СУБД. Файл как базовая сущность ОС (и UNIX, в первую очередь) стал создавать всё большие проблемы. Я не говорю о том, чтобы отказаться от этого понятия вовсе, но для многих вещей имеет смысл подниматься по абстрагированию выше — над файлами (сохраняя их для низкоуровневых задач). Служебная СУБД новой ОС — это один из шагов (не единственный). Разрабатывать придётся самим. Но для неё могут быть заданы вполне приемлемые ограничения (специфика), которые позволят значительно сократить объём работ, чем если бы это было при создании полноценной промышленной универсальной СУБД.
Esmertec
В заключение этой заметки расскажу одну малоизвестную историю, имеющую отношение к эффективности применения принципа дуальности не только в технологическом, но и в маркетинговом смысле.
В 1993 г. три друга, три товарища, учившиеся аспирантуре в швейцарском ETH, основали компанию Oberon microsystems. Их звали Cuno Pfister, Clemens Szyperski (ныне в Microsoft Research), Beat Heeb. В 1994 г. они сделали первый вариант BlackBox. Хотелось создать своими руками хорошую среду, чтоб и Оберон заиграл и народ полюбовался, как здорово работают идеи Вирта и Гуткнехта.
И все бы ничего, но тут как гром среди ясного неба грянула Java. Что делать? Срочно была предпринята коллективная ревизия Оберона — "e;наш ответ Чемберлену"e;. Собрали военный совет, тут добавили, там подправили — вот оно, что-то вышло. Новоиспечённому языку дали (из рыночных, как они говорили, соображений) имя Компонентный Паскаль (Component Pascal). Было это в 1997 г. Вирта позвали в крёстные отцы. Что делать — согласился, надо же поддержать молодёжь.
[Пишу по памяти — весной 1998 г. готовил публикацию по Компонентному Паскалю в ComputerWeek-Moscow и связался с Куно Пфистером. Тот живо откликнулся и прислал материал, который и пошёл в печать. В то время у них уже была своя ОС реального времени для встроенных систем с именем Portos.]
В 1999 г. от Oberon microsystems отпочковалась компания Esmertec. Создавали её уже четыре "e;танкиста"e; — Daniel Diez, Beat Heeb, Hansruedi Heeb и Peter Eichenberger. Во многом развитию нового направления способствовал потенциал той самой Portos. Эта ОС поддерживала два языка — Компонентный Паскаль (спец. версию для задач реального времени) и Java. Ядро реального времени делалось, разумеется, не на Java. Ну а инструментарий для кросс-разработки (на базе BlackBox) нарекли именем Denia — курортное местечко в Испании, на Коста-Бланка. Portos не нужна была ни виртуальная машина, ни интерпретатор кода, ни JIT-компилятор. Использовались идеи М.Франца.
Попытки продвинуть Змей-Горыныча о двух головах (CP/Java) заметным успехом не увенчались. Очень уж мешалось название "e;Компонентный"e; да ещё "e;Паскаль"e; в сфере микромира. Java — это класс, Java — это сила! Правильно. Сделали ставку на раскрученную вещь, зная, что уж она у них работать будет, как часы. Portos переименовали и стёрли с карты мира (чтоб никто и не вспоминал). Теперь "e;героя Дюма"e; звали Jbed — "e;ложе для Java"e;. Брат Пфистера — Бернд подсуетился насчёт инвестиций, основал свой фонд, начал накачивать денег. К делу подключили связи по Европе — Франция, Германия, Швейцария. Идея народ вдохновила — ещё бы, Sun ещё там только на бумаге чертила красивые диаграммы, расставляла столбики с надписью "e;Java Micro Edition — руками не трогать"e;, а они взяли и рванули. На святое замахнулись, на самое ядрёное ядро. Кто помнит, Java ведь с этой идеи начиналась, захвата микромира — "e;мы им там всем покажем кузькину мать!"e;.
К началу 2007 г. количество устройств, в которых используется Jbed, достигло 100 млн. штук. Стали мировым лидером в области J2ME. Верховодил в компании француз Alain Blancquart. Кстати, ушёл в никому не известную Esmertec из Borland Europe, где занимал высший пост. Стала сколачиваться нехилая команда, пошли люди из IBM Europe, а теперь — стоит глянуть на топ-менеджмент и совет директоров: что ни персона, то ого-го!
Michel Bon — 8 лет возглавлял France Telecom
Ulrich Schumacher — бывший президент Siemens Semiconductor Group
Jean-Pascal Aubert – бывший вице-президент Bull
Michel Kuntz – бывший вице-президент Alcatel
Sylvie Vollet – бывший топ-менеджер Apple Computer Europe
Chase Bailey — бывший главный технолог в Cisco
Jean-Luc Gianduzzo – 12 лет проработал в топ-менеджменте Hewlett-Packard, затем занимался развитием новых технологий в Cisco Systems Europe.
А Бернд Пфистер выбивал и выбивал денюжку. Европейские инвесторы просто помешались на этой компании. Золото, золото! Про Обероны забудьте. Нет у них такого слова. На чём работает Jbed — ни за что не скажут — военная тайна. А тем, кому нужна особая эффективность в микромире, – есть скрытый шлюз Компонентного Паскаля. Как говорится, обращайтесь, господа — сделаем на заказ.
История имеет ещё то продолжение, что в определённых моментах мы близки к подходам Esmertec. Они давно уже многие вещи засекретили, изъяли из публичного обращения, оставив на поверхности одну Java и обозначив компактный Smalltalk, но те, кто следили за их ростом, этими вещами обладают и спокойно могут додумать то, что и как там сделано (на уровне архитектуры и подходов). Считайте, что в технологическом (а не рыночном) понимании мы будем своеобразными конкурентами Esmertec. Но делать будем иначе, зная их плюсы и минусы. К тому же наша задача – перенацеливаемая ОС. Не только встроенные системы (реального времени), хотя они – в первую очередь.
|
