RB42. Национальная программная платформа

Предыдущая заметка:

5 марта депутат Государственной Думы РФ, член Комитета по информационной политике, информационным технологиям и связи, председатель подкомитета по технологическому развитию Илья Пономарёв, по поручению участников круглого стола «Национальная безопасность информационных технологий», направил Обращение Президенту РФ Д.А.Медведеву.

Полный текст Обращения:


Блоги:

Форумы:

Видео:

Публикации:



Ответы на вопросы агентства "Комментарии.ру"
Руслан Богатырёв
независимый эксперт,
участник Круглого стола "Национальная безопасность информационных технологий"


— Как Вы в целом оцениваете подготовленное Обращение? Какие предложения представителей отрасти ИКТ Вы считаете наиболее интересными?

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

У нас, как только дело доходит до ИКТ, очень много говорят о важности информации и технических средств её передачи и обработки, говорят об информационных ресурсах и коммуникациях. Но о самом фундаменте, о программной отрасли — практически ничего. А это ведь и есть конденсатор интеллектуального потенциала, способный существенно влиять на экономику нашей страны и на значительное расширение её экспортных возможностей.

Речь ведь не просто о национальной безопасности и технологической независимости. Речь по сути идёт о возможности заложить фундамент для того, чтобы Россия смогла заполучить сильный катализатор, локомотив своего экономического развития — мощную программную отрасль, которая в состоянии в стратегической перспективе снять колоссальную зависимость страны от экспорта своих природных ресурсов. И поднять на новый уровень в контексте построения информационного общества 21 века ценность ресурсов иного рода — научно-инженерного интеллектуального потенциала России.

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


— Какой, на Ваш взгляд, может быть реакция властей на Обращение представителей отрасли ИКТ? Считаете ли Вы, что именно высокие технологии при условии активной позиции государства могут стать катализатором экономического развития? Возможно ли достичь полной технологической независимости России?

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

Полная технологическая независимость — это из разряда научной фантастики. Мы слишком много упустили за последние годы. И теперь нам надо уже не догонять, а двигаться наперерез. У нас есть сильный козырь — надо устранять избыточную сложность, которую в угоду своим бизнес-интересам нагородили зарубежные компании и от которой им отказаться очень сложно.

Операционная система, по моему мнению, сегодня не является узким местом. Узким местом является доминирование в России экосистемы, привязанной к монополисту с гигантской рыночной долей на нашем рынке — к корпорации Microsoft. Выход — развивать при поддержке государства альтернативные экосистемы вокруг активно развиваемых в мире ОС (в частности, по линии UNIX), а также формировать экосистемы, минимизирующие привязку к конкретной ОС. Т.е. переходить к технологическим платформам, находящимся под контролем государства. В этом один из наиболее продуктивных путей обеспечения технологической независимости.


— Какие конкретные предложения, на Ваш взгляд, стоит внести в документ о создании Национальной программной платформы? К каким последствиям может привести принятие на государственном уровне национальных и отраслевых открытых стандартов? Как это отразится на разработчиках свободного и проприетарного ПО, на всей ИТ-отрасли?

— Требуется уже сейчас приступать к подготовке концепции Национальной программной платформы (НПП). Тут есть опасность свести её к размытому набору программного обеспечения, привязанного к конкретной экосистеме (что GNU/Linux, что Windows). Есть и другая опасность — превратить в аморфную операционную среду, составленную из различных ОС.

На мой взгляд, НПП должна включать в себя базирующиеся на отраслевых и национальных стандартах унифицированные совокупности:
1) операционных платформ и соответствующих ОС;
2) инструментальных платформ и соответствующих средств разработки;
3) прикладных платформ и соответствующих прикладных систем;
4) интеграционных платформ и соответствующего ПО;
5) коммуникационных платформ и соответствующего ПО.

НПП должна предусматривать наличие:
1) корпуса регламентирующих стандартов, спецификаций, норм и правил;
2) реестра проектно-технической документации;
3) единого национального программного репозитория;
4) национального фонда алгоритмов и программ;
5) органов государственной сертификации.

Стандартизация и сертификация — это те мощные инструменты, которые есть в руках государства, чтобы навести порядок. Фиксируя на уровне национальной стандартизации и унификации значимый для нас базовый набор стандартов и спецификаций (не только открытых), мы и создаём "технологическое правовое поле" в нынешнем хаосе. Регулируя процесс, гарантом которого выступает государство. Оно вправе на своей территории создавать и регулировать конкурентную среду.

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

Нам нужно думать о том, как обеспечить плавную миграцию ключевых приложений из доминирующей Windows в новую операционную среду, под которую и должна быть выстроена НПП. Она должна решать триединую задачу — обеспечить работу приложений, ориентированных на (1) Windows, (2) UNIX (включая GNU/Linux) и (3) новую перспективную отечественную ОС. Решать разными путями. В том числе и путём абстрагирования от ОС.

Нужны влиятельные общественные центры, в развитие которых вкладывались бы заинтересованные лица и организации по линии бизнеса, науки, образования. И с которыми государство могло бы работать напрямую. Нужно создавать сильные центры компетенции. Пока что у нас больше наблюдается феодальная раздробленность. Нужно объединяться не на базе ненависти к Microsoft и не на базе любви к Linux. Это, извините за резкость, больше напоминает фанатизм. И потому многих отталкивает. Требуется выходить на уровень выше — на уровень технологически независимых решений, отвязанных и от Windows, и от Linux. Вне зависимости от того, делаются они в проприетарной модели или в модели СПО.


— Как Вы оцениваете производящееся в России ПО? Насколько оно конкурентоспособно на внутреннем и на внешнем рынках? Возможно ли создание национальной программной платформы без помощи государства?

— В России ПО производится не только для внутреннего рынка. Основные производственные мощности и лучшие разработчики сосредоточены в лидерах экспортного ПО, в компаниях, входящих в профессиональную ассоциацию "Руссофт". Уровень разработок и контроль качества там очень высокий. Но не надо забывать, что на территории России немало наших высококвалифицированных кадров работает в зарубежных компаниях и на зарубежный рынок. Ещё большее число — за пределами страны. Если государство сможет найти разумные и эффективные стимулы, чтобы обратить весь этот потенциал на пользу России — результат может быть впечатляющим.

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

RB41. Диалоги. Как создать в России национальную операционную систему?

Предыдущая заметка:

Заметки по теме:

Предыстория вопроса:

  • Предпосылки к всестороннему изучению данной проблематики были сформулированы в моей статье "Нужна ли России своя операционная система?" (июнь 2007 г.) С авторским вариантом в формате Adobe PDF можно познакомиться здесь — http://www.europrog.ru/rb/ros.pdf. Публикация прошла в журнале "Мир ПК": №7/2007 и №8/2007

  • Один из конкретных подходов к НИОКР в сфере отечественных ОС был сформулирован в RB34 (03.12.2007) "Роса": перенацеливаемая отечественная ОС нового поколения. В настоящее время проект, продолжающийся на базе конструкторской группы компании "Метасистемы" (г.Орёл), переведён в закрытый режим и получил название "Орлея".




— Что такое операционная система?
— Странный вопрос. Трудно найти человека, который бы не понимал, что это.

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

— Словами и делами?
— Верно. Так и с компьютером. Внешний интерфейс ОС заменяет нам всё остальное. Зафиксируем интерфейс, сменим сам "организм", пересадив другие "органы" и никаких внешних отличий не будет. Если, разумеется, нам удастся скопировать и всё поведение предыдущего организма.

— Но это для пользователей. А как для программистов?
— Для них аналогично — требуется знать чисто внешние признаки ОС помимо пользовательского интерфейса: системные вызовы, протоколы взаимодействия, форматы данных. То, что называется операционной платформой. Зафиксируем платформу, подменив содержимое конкретной ОС — и никаких отличий для программиста фактически не будет.

— Ну если так, то почему такой сложной видится задача создания новых ОС? Повторил пользовательский интерфейс, реализовал операционную платформу — и всё. Новый организм готов.
— В теории всё так, а на практике дело осложняется многими факторами. И самый главный из них в том, что ни интерфейс, ни операционная платформа не могут быть зафиксированы на продолжительный период. А если и могут, то их владельцы в любой момент во имя конкурентной борьбы могут предать их забвению и провозгласить свой новый порядок. Ну а если интерфейс и платформа принадлежат конкретной компании, то тут ещё возникает проблема нарушения интеллектуальной собственности. И, значит, желающих поиграть в такие игры ждут в перспективе судебные тяжбы и серьёзные финансовые издержки.

— Но я знаю, например, одну систему, которая почти в точности копирует операционную платформу Windows. И что же: она вне закона?
— Всё зависит от того, как на это будет смотреть хозяин оригинала. Зависит целиком от его доброй воли. Но сегодня воля одна, завтра — другая. Кстати, уверены ли вы в том, что наличие несанкционированных копий иного плана — пиратских версий той или иной ОС — обязательно наносит ущерб бизнесу владельца оригинала? А не наоборот? Ведь потребителя желательно сначала заинтересовать продуктом, выработать потребность в его использовании, а затем, когда он подсел основательно на иглу, можно невзначай напомнить, что неплохо бы и заплатить. Так и с клонами коммерческих интерфейсов и коммерческих операционных платформ. Впрочем, в этом есть определённая польза: можно, например, их рассматривать как тренажёр, как полигон для экспериментов, особенно если доступны исходные тексты и если владельцы оригинала этому не препятствуют.

— Хорошо. Но как же быть с новой ОС. Разве нет выхода?
— Есть. Делать, например, всё своё. И интерфейс, и платформу.

— Легко сказать. А сколько на это нужно времени, финансов, людей?
— Всё зависит от постановки задачи, состава требований и реальных возможностей её решения. Создать экспериментальную ОС, позволяющую выполнять базовые штатные функции и создавать новые приложения, можно за сравнительно короткий срок и весьма скромным коллективом. Приведу несколько примеров. Экспериментальную ОС масштаба ETH A2/Bluebottle можно создать за 3-4 года силами 3-5 человек: трудозатраты 9-20 человеколет. Трудозатраты на Oberon System (базовую часть) составили 5 человеколет (1985-1987), при этом создавали два профессора (Никлаус Вирт и Юрг Гуткнехт) и развивали несколько аспирантов, совмещая со своей преподавательской и исследовательской деятельностью в ETH Zurich. Другая система — Microsoft Singularity создаётся с 2003 г. силами 50 сотрудников Microsoft Research (разные подразделения), совмещающих эту работу с другими работами. Можно вспомнить и более комплексный 3-летний советский проект МАРС (Модульные асинхронные развиваемые системы, 1985-1988; ВЦ АН СССР, ВЦ СО АН СССР, Институт кибернетики Эстонии), проводившийся ВНТК "Старт". МАРС — это НИОКР с получением макета системы и проектной документацией для передачи в производство. В проекте было задействовано около 100 человек (преимущественно научно-исследовательские организации по линии АН СССР с подключением ряда промышленных предприятий). В проекте поддерживалась централизация по управлению (с Центром управления в Новосибирске, ВЦ СО АН СССР). Кадры не изымали из существующей организационной структуры: перераспределяли нагрузку и гибко переподчиняли по проектному участию. Не было необходимости в географической централизации. В МАРС фундамент составляли: 32-разрядный процессор Кронос (прототип — 16-разрядный швейцарский Lilith), транспьютерная архитектура (прототип — транспьютеры английской компании Inmos), операционная система Excelsior (прототип — UNIX, язык реализации — Modula-2), параллелизм — языки БАРС и ПОЛЯР (примитивы языка Occam фирмы Inmos) и формализм управляющих сетей (прототип — сети Петри).

— Боюсь, это будет просто макет, игрушка.
— Не совсем так. Это будет нормальная ОС. Другое дело, что она будет необычной и для пользователей, и для программистов. И вряд ли сможет в одночасье решить проблему с исполнением унаследованных приложений. А чтобы наращивать её мышечную массу, создавать под неё новые приложения, нужен стимул для сторонних программистов. Вот с этим точно проблема может быть большой. Причём именно она и может похоронить новое детище. Сколь бы замечательно оно ни было продумано и реализовано.

— Значит, такие системы в наше время господства монополий обречены?
— Ну почему же обречены? Они могут отлично себя чувствовать там, где как раз наследование старого противопоказано, если вообще такое старое там есть. Например, в новых компьютерных устройствах, в специальных сферах деятельности, где важен не столько функционал, сколько качество его реализации, надёжность, безопасность и т.п.

— Это понятно. Но меня больше заботит то, может ли такая ОС стать массовой и универсальной? Ведь она наверняка будет отличаться от привычного. И для пользователей, и для программистов. Кто же будет на такой ОС работать?
— Хороший вопрос. Получается вроде как заколдованный круг. Создать-то можно. И получше устаревших. Но потом придётся выбросить или ограничиться узкой нишей, потому как для массовой аудитории ключевым фактором служит консерватизм — привычка, опыт работы с традиционными приложениями. Это серьёзная проблема. И крупные компании, которые держат под своим контролем нынешний рынок ОС, вынуждены считаться с ней. Причём дело доходит до печальных курьёзов — некоторые компании открыто заявляют, что ошибка, к которой привык пользователь, должна сохраняться в новых системах. Так-то. Ошибка, к которой пользователь привык, становится особенностью, штатной спецификой и её уже трогать нельзя, чтобы не потерять клиентов!

— Потрясающе! Значит, с каждой новой версией ОС ошибки плодятся, накапливаются. И весь этот хлам с годами только растёт в объёмах?
— Если смотреть на нынешние системы, то вы правы. Хотя тут многое зависит от самой компании-владельца, от её политики. Но если она — лидер рынка, то резкие телодвижения и эксперименты с ОС на живых клиентах ей противопоказаны. Отстающим проще. Им нечего терять.

— Да, но ведь так не может же продолжаться вечно?
— Время от времени лидеры рынка встряхивают своих пользователей и весь рынок. Впрочем, это ещё одна тенденция нашего времени — даже если у пользователя нет потребности менять старую ОС и старый компьютер, его вынуждают это делать — новые технологические и коммерческие условия, диктуемые владельцем ОС, превращают пользователей старых систем в изгоев. При этом новое совсем не обязательно лучше старого — ни по качеству, ни по надёжности, ни по функционалу. Таковы законы рынка. Производство останавливать нельзя. Значит, надо искусственно стимулировать потребление. Заставлять покупать то, что просто не нужно. В этом, кстати, и кроется одна из фундаментальных причин нынешнего глобального кризиса.

— Вернёмся к нашим баранам. Допустим, у нас есть новая экспериментальная ОС. Оригинальная. Как ей стать массовой?
— Очень просто и одновременно сложно: либо она должна стать популярной в массах сама по себе, либо у неё должен быть очень влиятельный хозяин, способный за неё постоять перед монополистами рынка.

— И кто же может быть таким влиятельным хозяином? Интересно…
— Например, государство. Уж на своей-то территории оно вправе устанавливать собственные правила и законы. Значит, у него на руках все козыри.

— Но это же протекционизм, давление на рынок, удушение бизнеса!
— Давайте не будем лукавить. Каждая страна занимается государственным регулированием в тех или иных объёмах, в той или иной сфере. Она вправе сама для себя решать, где требуется срочное вмешательство и где хотя бы на какой-то период желательно поставить заградительные барьеры. Она вправе создавать и регулировать конкурентную среду.

— Государственная ОС? Возможный вариант, но я скептически отношусь к нему: разворуют и сделают никуда не годную вещь.
— Ну если опасения только в этом, то есть относительно безопасный путь: начать пилотный проект с ограниченным финансированием, посмотреть на результаты испытаний, заключения государственной комиссии. Если результаты впечатляющие или просто обнадёживающие — тогда можно принимать решение о придании ОС нового статуса и запуске её в производство. Впрочем, если вы знакомы с историей нашей аэрокосмической отрасли, там именно так и поступали. Была налаженная инфраструктура научно-исследовательских институтов и конструкторских бюро. И надо же — ведь были и по инерции остаёмся здесь мировыми лидерами.

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

— Допустим. Но мне больше по душе путь новой ОС через популярность в массах.
— Очень долгий и тернистый путь. Да что там далеко ходить. Возьмите тот же Linux. Как вы думаете, сколько крупных западных компаний раскручивало Linux с середины 1990-х годов, сколько было вложено финансов, людских ресурсов? А результат по рыночной доле спустя 15 лет более чем скромный. И это при том, что финансовая нагрузка на потребителя в отношении ОС фактически нулевая. Когда есть ярко выраженный монополист, требуются дополнительные усилия для изменения ситуации. Если бы дело касалось только бизнеса... Но операционная система в наши дни — это ключевой инфраструктурный продукт, на который завязана экономика и общественная жизнь всей страны. Так что если государство всё же понимает, что ситуацию менять нужно — её надо менять. Не откладывая в долгий ящик.

— А если мне государственная ОС не понравится? Почему я должен на ней работать?
— Если не нравится — не работайте. Покупайте или доставайте другие, как делаете сегодня. В чём проблема? Правда, если вы работаете в государственной организации, то, боюсь, здесь придётся считаться с мнением и волей своего работодателя — государства.

— Подождите. Но сколько может понадобиться времени на пилотные проекты, на запуск в производство, на переход на новую ОС? Это же очень долго.
— На пилотные проекты примерно 3-5 лет. На производство — примерно столько же. В общем, лет на 7-10 закладываться надо. Это нормальный цикл для создания массовых ОС.

— А что делать остальным эти 10 лет. Ждать?
— Почему же? Можно уже сегодня начинать готовиться к переходу на новые ОС и при этом оставаться на платформе существующих.

— Не понял. Поясните…
— Через 3-5 лет после начала работ определится архитектура и вся новая операционная платформа. Наверняка появится под неё базовый инструментарий. Значит, программисты уже потенциально могут иметь к этому доступ.

— Но вы же сказали — сейчас…
— Новая массовая ОС должна будет решать каким-то образом болезненную проблему совместимости. И видимо не только путем виртуализации ОС. Значит, потребуется в ней поддерживать базовые спецификации на вызовы, протоколы, форматы, принятые в ИТ-отрасли. Но эти спецификации в нынешних условиях весьма размазаны и по составу, и по гарантии поддержки. Потому первым делом надо определиться с перечнем таких спецификаций. Базовым набором. Международные стандарты — хорошая отправная точка. Только важно, чтобы им был придан соответствующий вес внутри страны. Не рекомендательный, а обязательный характер поддержки.

— Но ведь есть не только международные стандарты. Большая часть программного обеспечения базируется на внутрикорпоративных стандартах. А компания может по своему усмотрению их менять. В любое время. Как же можно к ним привязываться? Вон ICQ чуть ли не каждую неделю меняет свой протокол из-за борьбы с конкурентами. Как же быть?
— В этом случае надо использовать возможности государства. Оно вправе предъявлять требования к продукции, продаваемой и распространяемой на его территории. По маркировке, по документации, по поставке драйверов, по иным параметрам… Возможности зафиксировать на длительный период на своей территории те или иные спецификации — вполне посильная задача. К тому же она развяжет руки разработчикам и прикладных систем. Они смогут опираться на "узаконенные" спецификации. Для развития отечественной программной отрасли даже безотносительно новой ОС это огромное подспорье.

— Как скучно: стандарты, спецификации…
— Тут выбор невелик: либо оставлять нынешний хаос с двумя ярко выраженными полюсами развития (Windows-Linux), либо пытаться в нём навести хоть какой-то порядок, заодно помогая тому же неокрепшему Linux хоть немного встать на ноги в нашей стране. За Linux сегодня в России не стоит ни авторитетная общественная организация, ни государство. Дистрибутивов множество. Каждый тянет лямку совместимости в свою сторону. Это не дело. Надо унифицировать. Иначе риски даже для тех, кто готов подумать о переходе на альтернативу, слишком велики. И запредельный монополизм Microsoft на нашем рынке будет сохраняться со всеми вытекающими.

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

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

— А как же Windows? На него фактически завязана вся экономика страны. Люди не будут поддерживать Linux. Хотя бы потому, что это им не выгодно. Они привыкли к Windows. Деньги за него платятся по большей части не из их кармана. К тому же, раз вложения сделаны, просто так выбрасывать всё на ветер — не по-хозяйски.
— А зачем выбрасывать? Давайте попробуем посмотреть на проблему иначе: наверное для ряда задач имеет смысл обеспечивать дуальность: поддержку и Windows, и Linux. Так? Тогда надо искать пути унификации. В первую очередь — по линии приложений. Формировать демпфирующие программные слои, которые можно будет относительно легко перекоммутировать на целевую ОС. Причём со временем и на новые перспективные ОС. Стимулировать этот процесс может опять-таки государство — соответствующими требованиями к новым системам для государственного сектора.

— А можно какой-нибудь пример подобной унификации?
— Возьмите проект San Francisco корпорации IBM. Создавались крупные строительные блоки для бизнес-приложений в Java 2 Enterprise Edition (свыше 1000 модулей), которые потом вылились в весьма развитую интегрирующую платформу IBM WebSphere. Теперь она ещё и тесно связана с открытой расширяемой инструментальной платформой Eclipse. Другой пример — интегрирующая бизнес-платформа SAP NetWeaver. Малоизвестен тот факт, что в её разработке ведущую роль сыграла формально американская, а по сути белорусско-российская компания EPAM Systems, лидер среди компаний всей Восточной Европы. Наши разработчики с 2002 г. бок о бок работали над SAP NetWeaver с коллегами из команд SAP в Вальдорфе (Германия), Пало-Альто (США) и Бангалоре (Индия). И накопили свыше 1 млн. часов опыта работы с этой платформой, включая разработку и внедрение на её основе корпоративных бизнес-решений.

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

— Подождите, получается, что можно избежать государственного лоббирования Linux, что Windows и его приложения могут в таких условиях в нашей стране дальше успешно развиваться?
— Разумеется. Просто государство может регламентировать те условия, в которых могут создаваться приложения для разных ОС, не только для национальной. Оно способно сформулировать и законодательно закрепить условия конкуренции и развития. Что вполне разумно.

— Может ли национальная ОС дать нам конкурентное преимущество при экспорте нашего ПО?
— Непростой вопрос. Сама по себе — вряд ли. Если она в тактическом отношении опирается на существующие ОС, то для западной аудитории не совсем понятно, в чём для них выигрыш. Им нужно минимизировать свои риски. А для них чужая национальная ОС без очевидного выигрыша в производительности — лишние риски. Делать же ПО для Windows и Linux в отдельности — и так делаем. Скажу больше — нашим признанным лидерам экспортной разработки ПО национальная ОС для продвижения на Запад особо и не нужна. Разве что как один из крупных правительственных заказов. В остальных случаях нетрудно предсказать их прохладное к этому отношение, возможно даже стойкое неприятие самой идеи.

— Получается, что для улучшения экспорта ПО национальная ОС ничего не даёт?
— Не совсем так. Если будет ОС, которая в стратегической перспективе принципиально отлична от существующих и которая может иметь экспортное исполнение с определённой спецификой по поддержке национальных языков, требований к информационной безопасности и т.п. — интерес возникнуть может. Но, скорее, не в отношении самой ОС, а комплексных решений на её основе. В то же время унификация прикладных платформ — это совсем неплохо. И если с подобными решениями мы сможем выходить на зарубежный рынок — вполне вероятно, что успех будет. Но стоит понимать: выигрыш внутри страны может быть на порядки выше. И я не уверен, что нам так надо биться здесь за увеличение экспортной выручки. Будут в новых условиях расти достойные кадры, появятся более сильные, чем у западных конкурентов инструменты, сможет национальная ОС играть роль эффективной платформы для кросс-разработки под разные ОС — и эта задача роста экспорта ПО попутно решится. Говоря о национальной ОС, не стоит забывать о таком только нарождающемся классе ОС, как интернет-ОС (WebOS). Это особое направление, и здесь можно создать очень неплохие заделы с прицелом на серьёзные экспортные решения.

— А почему вы всё время используете прилагательное "национальный"? Как-то это на оголтелый патриотизм смахивает…
— Неужели? Вас не смущает, что в США именно это прилагательное используется в отношении большинства ведущих государственных учреждений? Полагаю, вы также знаете, что в соответствии с нашим законодательством с июля 2003 г. у нас действуют именно национальные стандарты, а не государственные. Впрочем, для меня это синонимы.

— А как назвать все те стандарты и спецификации, которые помогут снять зависимость и от зарубежных ОС, и вообще от специфики ОС?
— Это не только совокупность операционных платформ. Здесь задействованы и прикладные платформы для отраслевых применений. Да и не только они. Можно назвать и Национальной операционной инфраструктурой, и Национальной программной платформой — кому как нравится. Впрочем, не в названии дело.

— Интересно. И всё-таки: если в кармане у нас есть почти беспроигрышное решение по унификации Windows и Linux, то каковы шансы создавать параллельно своё, оригинальное?
— Я бы говорил не об унификации Windows и Linux, а, скорее, об унификации Windows и UNIX. Причём на "законодательной базе" Национальной программной платформы. В мире UNIX помимо Linux есть не менее интересные, зрелые и продуманные системы (QNX, FreeBSD, Solaris и др.), и не только коммерческие. Но вопрос был про отечественные оригинальные разработки в области ОС... Есть перспективные наработки в Новосибирске (Excelsior), Орле ("Орлея", ранее "Роса"), Москве (Phantom). Это лишь несколько примеров.

— Это всё независимые разработчики?
— Не совсем так. На мой взгляд, в подобных делах требуется объединять потенциал академической науки по линии РАН, университетов, способных активно помочь в создании макетов, и профессиональных разработчиков, имеющих богатый опыт работы в ИТ-индустрии. Впрочем, многое будет зависеть от научной основы, грамотности архитекторов и глубины проработки своего инструментария. Это и есть ключ к решению столь грандиозной научно-инженерной задачи. Важно и то, что перспективные ОС должны создаваться в тесном контакте с разработчиками отечественной элементной базы, прежде всего, это касается процессоров семейства "Эльбрус".

— Но какова в стране ситуация с кадрами? Деньги найти, наверное, можно, а вот людей?
— Я бы выделил три основных стадии: НИОКР, проектирование и производство. В отношении НИОКР и в какой-то степени проектирования у нас есть потенциал по линии РАН, сферы высшего образования и амбициозных небольших компаний, тесно работающих с родственными вузами. Что касается производства, то тут, на мой взгляд, стоит подумать и о подключении наиболее сильных кадров, которые сконцентрировались в наших лидерах экспортной разработки ПО. Тех, что входят в профессиональную ассоциацию "Руссофт".

Заметки по теме:

RB40. Никлаус Вирт. Большое турне по России

Предыдущая заметка:

15 февраля 2009 г. знаменитому швейцарскому профессору Никлаусу Вирту исполнилось 75 лет. Его юбилею посвящена эта заметка с воспоминаниями о визите Вирта в Россию в 2005 г.



Никлаус Вирт (Niklaus Wirth), автор языков Паскаль (1970), Modula-2 (1979) и Оберон (1988), знаменитый профессор Высшей Политехнической школы ETH из Цюриха, где учились Альберт Эйнштейн и Джон фон Нейман, в рамках Большого турне по России (11 сентября — 7 октября 2005 г.) собрал бурю оваций. Профессор Вирт выступил с лекциями в крупнейших университетских центрах страны: Москве, С.-Петербурге, Нижнем Новгороде, Екатеринбурге, Новосибирске, Томске.

Главной целью столь продолжительного визита проф. Вирта в Россию, прошедшего в год 35-летия Паскаля и приуроченного к празднованию 250-летия МГУ им. М.В.Ломоносова и 150-летия швейцарского ETH, — представление широкой общественности проблем развития информатики и ИТ-индустрии, популяризация идей систематизации программирования, а также налаживание более тесных контактов ETH с ведущими университетскими центрами России. В известной группе БРИК наиболее перспективных стран для мировой ИТ-индустрии (Бразилия, Россия, Индия и Китай) Никлаус Вирт выделяет Россию. Именно Россия, хранящая традиции и самобытность Паскаль-культуры, имеющая глубокие корни блестящих достижений научных школ — математики, физики и инженерного дела — ныне остаётся едва ли не единственным оазисом неремесленного программирования.

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

В С.-Петербурге Никлаусу Вирту была торжественно вручена мантия Почётного доктора СПбГУ ИТМО — университета, который стремительно ворвался в число вузов-лидеров, готовящих высококвалифицированные кадры для отечественной ИТ-индустрии. Одним из самых ярких и незабываемых событий Большого турне по городам России стала историческая лекция проф. Вирта в знаменитой Большой аудитории Политехнического музея (Москва, 21 сентября 2005 г.), где выступали Нильс Бор и Норберт Винер, а также весь цвет отечественной науки — лауреаты Нобелевской премии П.Л.Капица, И.Е.Тамм, Н.Г.Басов, академики С.И.Вавилов, О.Ю.Шмидт, И.И.Артоболевский и многие другие выдающиеся отечественные учёные.

В знак уважения к высочайшему инженерному искусству России Никлаус Вирт преподнёс в дар Политехническому музею свой уникальный компьютер Lilith ("Лилит"), первый европейский персональный компьютер, созданный в ETH в 1980 г. и почти на 10 лет опередивший разработки ведущих компьютерных компаний мира. Во всём мире сохранились лишь единичные экземпляры. Тем более весом тот факт, что проф. Вирт подарил старейшему российскому инженерному музею свой личный компьютер. Такой чести не удостаивалась ни одна другая страна мира. За разработку Lilith и за создание языка Паскаль, на котором воспитано не одно поколение программистов, Никлаус Вирт в 1984 г. был представлен к высшей профессиональной награде — премии Алана Тьюринга (Turing Award). В компьютерном мире она считается эквивалентом Нобелевской премии. Одновременно с Lilith Институт систем информатики им.А.П.Ершова Сибирского отделения Российской академии наук преподнёс в дар Политехническому музею 32-разрядную рабочую станцию "Кронос", ориентированную на язык Modula-2, созданную в Советском Союзе учениками и последователями академика А.П.Ершова и являющуюся дальнейшим развитием 16-разрядного компьютера Lilith.

Лекция проф. Вирта в Политехническом музее в Москве в отличие от выступлений в других аудиториях была посвящена жемчужине его творчества — языку Оберон (1988), который на долгие годы был предан забвению в угоду рыночным интересам крупнейших компаний мира, заимствовавших без какого-либо упоминания идеи проекта Oberon и во многом обесценивших их. Важнейшим лейтмотивом выступлений Вирта была жёсткая критика нынешней практики преподавания компьютерных наук и технологий. Насильственное превращение университетов в ремесленные училища — печальные реалии современного мира. "Такой стиль академической жизни нередко противоречит внутренним убеждениям индивидуума, но навязывается давлением извне превратить храмы учёности в хорошо разрекламированные источники доходов, и этот стиль граничит с проституцией", — отмечал проф. Вирт. По мнению швейцарского учёного, именно университеты должны быть лидерами в области компьютерных наук и информационных технологий, а не идти на поводу у индустрии, ставящей коммерческие интересы превыше всего. "Посмотрим правде в глаза: разве большинство учреждений образования не оказалось заложниками горстки компаний, чья профессиональная цель состоит в повышении доходов — идёт ли речь о производителях оборудования, программного обеспечения или об издательствах?" — столь беспощадная критика в устах великого учёного и педагога заставляет всерьёз задуматься о том, что же на самом деле в мире и у нас в стране творится с формированием интеллектуальной элиты 21 века.

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

Большое турне Вирта, в подготовке которого важнейшую роль сыграл его ближайший сподвижник профессор Юрг Гуткнехт (Juerg Gutknecht), проходил по городам C.-Петербург — Ярославль — Москва — Суздаль — Нижний Новгород — Екатеринбург — Новосибирск — Томск — Москва, где Ярославль и Суздаль были промежуточной остановкой в рамках знакомства Вирта с культурой великой России. В каждом городе проходило по 2-3 рабочих встречи с лучшими программистами страны и ведущими представителями профессорско-преподавательского корпуса, где обсуждались проблемы обучения компьютерным наукам и технологиям наших школьников и студентов, будущих учёных и инженеров, перспективы сотрудничества между Швейцарией и Россией в рамках международного научно-образовательного проекта "Информатика-21".

Немного сухой статистики. На лекциях Вирта, посвящённых языку Оберон и анализу инноваций в компьютерных науках за последние 40 лет, побывало в общей сложности около 5 тыс. человек. Число тех, кто не смог попасть на выступления мировой знаменитости, но был в курсе деталей этого визита через друзей, знакомых, Интернет приблизительно в 5 раз выше аудитории слушателей его лекций. После выхода статей в ведущих изданиях страны аудитория Большого турне Вирта увеличилась ещё примерно в 100 раз и составила около 2,5 млн. человек. За время своего турне Никлаус Вирт на поездах и автомашинах преодолел 4594 км, не считая поездок в пригороды С.-Петербурга и Москвы, а также тысячекилометровые авиаперелёты. Для освещения Большого турне Вирта был открыт специальный событийный сайт Oberon2005.ru, на котором за время турне было зарегистрировано около 100 тыс. запросов.

А теперь некоторые субъективные наблюдения. Эдакий портрет мэтра без галстука.

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

С Никлаусом Виртом заочно я знаком достаточно давно. Изредка удавалось переписываться. Помимо его первой знаменитой лекции в МГУ в 1990 г. дважды были мимолётные встречи — в 1996 г. в Новосибирске, при вручении ему звания Почетного доктора Новосибирского университета (то заслуга столь рано от нас ушедшего Игоря Васильевича Поттосина), и несколькими днями позже в Москве, на квартире у Д.М.Сагателяна, бывшего в ту пору организатором и вдохновителем Рабочей группы по языку Modula-2 в СССР и России. (Сейчас Дмитрий Михайлович живёт и работает в США. Вирт очень хотел пригласить его на лекцию в Политехнический, но увы...).

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

С восторгом, буквально затаив дыхание, Вирт слушал акапельное духовное пение в Церкви Ризоположения в Кремле (нам повезло, попали в точности к началу; исполнение в самом деле было неповторимым). Четырьмя днями позже слушали не менее потрясающее духовное пение в Суздале. Выставку сокровищ "Кунсткамеры Габсбургов", которую привезли в Кремль и открыли за несколько дней до нашего посещения, смотреть не захотел. Вот ещё, на это тратить драгоценное время — он приехал в Россию, и здесь его интересовали только наша история и культура, которые он впитывал каждой своей клеточкой.

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

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

Несмотря на свой почтенный возраст Вирт оказался очень выносливым человеком (в плане выпавшей на него гигантской нагрузки, а ведь мы с Ф.В.Ткачёвым из Института ядерных исследований РАН постоянно сменялись — и то падали с ног от усталости). Лишь в один из дней (19 сентября) он выглядел крайне утомлённым. То был день открытия в МГУ 1-й Международной конференции по ИТ-образованию. Помимо своего доклада Вирт потом несколько часов допоздна провёл на круглом столе в МГУ, где не одна сотня студентов из тех, что сидели в аудитории факультета ВМиК и стояли в проходах, добивала его многочисленными вопросами. Его друг, Алексей Недоря, в гости к которому в Ярославль Вирт совершил немыслимый тысячекилометровый вояж по дороге из С.-Петербурга в Москву и где отведал баньки и русских блинов, помог увезти знаменитого профессора в гостиницу, а то его просто бы растерзали на "тысячу маленьких медвежат".

Генеральный план Большого турне по России Вирт разрабатывал лично. Честно говоря, меня поразило, сколь много внимания он при планировании уделял всевозможным нюансам. А ведь задача увязать интересы, сроки и ресурсы всех тех, кто помогал в организации визита, была очень непростой. Спонтанно возникшая в конце августа идея исторической лекции в Политехническом была доведена до реализации в невероятно сжатые сроки. Не обошлось, конечно, без досадных накладок, но результат стоил наших усилий. Вирт сумел за несколько дней подготовить специально для этого события очень важное и интересное выступление.

В Политехническом музее, уже после завершения лекции и продолжительной пресс-конференции, Вирт сделал запись в книге почётных гостей музея и отправился на экскурсию. Особенно его поразила одна демонстрация. Он от души аплодировал виртуозу, который показал мастерство солирования на терменвоксе, удивительном изобретении Льва Сергеевича Термена, создавшего в России в 1919-1920 гг. первый в истории электронный музыкальный инструмент. Звук на нём возникает не от касания, а только от движений рук исполнителя в пространстве перед специальными антеннами. При этом со стороны кажется, что звук возникает из ниоткуда. Вирт попробовал что-то подыграть себе сам, но смутился от не очень-то мелодичных звуков, выходивших из-под его неискушённых рук.

Больше всего Вирт хотел попасть в музей ВВС России в подмосковном Монино. Те, кто знает его юношеское увлечение авиамоделизмом, проект OLGA и преклонение перед совершенством аэрокосмических разработок, легко поймут, почему в донельзя загруженной программе были выделены почти два полных дня (22 и 23 сентября) для посещения второго по величине в мире авиационного музея под открытым небом и для запуска беспилотных самолетов в Егорьевске. В Монино Вирт не просто слушал интереснейшие рассказы импровизированного гида — действующего лётчика, руководителя местного аэроклуба, — он уточнял, почему не шли в серию те или иные перспективные разработки, опережавшие время, несколько раз переспрашивал о конкретных примерах конкуренции в этой области между Советским Союзом и США. Было видно, что тема противостояния имперским амбициям Америки его весьма и весьма волновала. На обратном пути, уже после мимолётного визита в редакцию журнала "Мир ПК", Вирт обратился ко мне с вопросом: почему многие в России смотрят на Америку снизу вверх? Что я мог ему ответить? Печально, но мы пожинаем горькие плоды безвременья последних двух десятилетий.

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

Думаю, ему, да и не только ему, хотелось бы, чтобы тот визит в Россию не прошёл бесследно и помог бы многим в нашей стране осознать, какой богатейший пласт компьютерной культуры был от нас и от остального мира скрыт все эти годы. Как было бы здорово, если бы мы, подобно той служащей отеля, смогли понять, что же хотел Вирт донести до нас, отважившись на склоне лет на такой смелый и рискованный шаг — на Большое турне по необъятной России.


Материалы к Большому турне проф. Вирта (2005)

RB39. Национальная ОС — цель или средство?

Предыдущая заметка:

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

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

А потому всеобщий скепсис подталкивает к простому, дешёвому, лобовому решению – перелицевать GNU/Linux — одну из самых распространённых в мире свободных ОС. И навесить на неё красочный ярлык "национальная операционная система". Причём государство, судя по развитию событий последних лет, даже не готово взять на себя ответственность за её развитие и внедрение.

Что это кардинально может изменить в нынешней безрадостной ситуации? Чуть-чуть потеснить американского монополиста – корпорацию Microsoft, снизив её долю на нашем рынке операционных систем с 95% на пару-тройку процентных пунктов? Возможно. Облегчить своими преференциями выбор гражданам и организациям одного конкретного дистрибутива GNU/Linux из общей массы в 500 с лишним систем? Наверняка. Создаст ли это новый рынок, способный привлечь значимые силы науки и бизнеса? Увы, маловероятно. Быть может, мы сможем, наконец, облегчённо вздохнуть и избавимся от рисков технологической зависимости от США в тех кровеносных артериях страны, которые и определяет всепроникающая универсальная операционная система? Очень бы хотелось надеяться. Но… развитие ядра Linux определяет не Россия и даже не единичные российские разработчики — в людском и финансовом плане это находится под контролем трёх крупнейших американских компаний — IBM, Novell, RedHat. Не для того они вкладывали в это миллиарды долларов, чтобы за здорово живёшь отдать кому-то контроль над тем, что приносит немалую прибыль. Даст ли это мощный импульс подрастающему поколению в России испытать гордость за свою страну и выбрать себе славную профессию программиста? Точно, нет. Не надо быть специалистом, чтобы понять сомнительную ценность подобной "национализации" в глазах пытливой молодёжи. Так неужели оставлять всё как есть и полагаться на то, что ситуация вдруг сама собой изменится. Тоже сценарий. Вот только мы по нему живём уже почти четверть века, и света в конце тоннеля как-то всё не видать.

Есть ли другие пути? Есть. Причем не косметические и не революционные. А "постепеновские", эволюционные, позволяющие обеспечить баланс интересов противоборствующих сторон. Причём в интересах России.

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

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

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

Применительно к названным проблемам наиболее рельефно прорисовываются следующие три взаимосвязанные цели:

  1. Национальная безопасность ИКТ.
  2. Технологическая независимость страны.
  3. Возрождение национальной программной индустрии.

На первых двух нет смысла детально останавливаться. Их всесторонне обсуждали. А вот третью стоит рассмотреть подробнее.

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

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

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

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

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

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

Давайте разберёмся в том, что же мы хотим сделать. Абсолютно новую ОС, архитектурно и технологически отличающуюся от нынешних популярных систем? Безусловно, этим надо заниматься и рассматривать как стратегическую перспективу, запуская в этом направлении новые пилотные проекты. Тем более, что обнадёживающие заделы в этой области у нас есть. Но готовы ли мы сегодня к штурму этой вершины? Трудно сказать. Что же делать? Ни системы семейства Windows, ни Mac OS (по понятным причинам принадлежности американским компаниям) в качестве национальной ОС выступать не могут. Значит, если результат нужен сегодня, поневоле приходится рассчитывать только на мир свободного ПО, где доминирует UNIX-культура. А там воронка популярности автоматически приводит к GNU/Linux.

И вот тут очень важно не наломать дров. Операционная система во многом определяет ту операционную среду, которая создаётся в той или иной сфере профессиональной деятельности. Она определяется набором устоявшихся программных продуктов и систем, накопленными лучшими практиками, спецификой обработки информации, интерфейсом и функционалом, к которому привыкли миллионы и миллионы специалистов. По сути это специализированная ОС, работающая поверх универсальной ОС. В нашей стране при запредельном доминировании Microsoft ломать через колено в одночасье такую схему при жутком дефиците аналогов в GNU/Linux означает одно — дискредитировать своё решение и убедить пользователей в том, что полноценной альтернативы Windows нет.

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

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

Попробую пояснить идею на простом примере. Предположим, что у нас есть большой парк оборудования, который подключается к сети через вилки с двумя штырьками большого диаметра (аналог приложений для Windows). И приличный парк оборудования, рассчитанный на вилки с двумя штырьками малого диаметра (аналог приложений для GNU/Linux). Чтобы решить проблему нестыковки розеток, можно создать новый вариант  розетки и вилки — три штырька среднего диаметра — и обеспечить переходники под новые розетки. Зато если это делается в масштабах страны и под контролем государства, то нет проблем выпускать своё оборудование, рассчитанное на эту новую унифицированную розетку. А затраты на переходники можно возложить на производителей оборудования, которым интересен рынок и которые вполне готовы пойти на столь незначительные издержки.

Иными словами, можно создавать национальную ОС со своими требованиями к разъёмам, к механизмам сопряжения, но при этом осознавая, что её можно в кратчайший срок конкретизировать, скоммутировать с реальными ОС. Оставляя возможности для дальнейшего развития собственных ОС. Для этого и надо создавать своё "законодательство", свои разъёмы, иначе мы просто станем заложниками одной конкретной системы и пойдём по тупиковому пути клонирования семейства IBM/360-370 по линии ЕС ЭВМ с гарантией нарастания технологического отставания.

К чему сведётся фиксация разъёмов: к выработке базовых спецификаций ОС (системные вызовы, протоколы, форматы данных), которые и определяют в совокупности операционную платформу. Другими словами, достаточно спроектировать и стандартизировать на государственном уровне программные спецификации, под которые можно обеспечить поддержку как со стороны GNU/Linux и Windows, так и совершенно новых, перспективных ОС. Как же вырабатывать подобные спецификации? Один путь — пытаться унифицировать универсальные ОС на нижнем уровне. Примеры: унификация свыше 500 дистрибутивов GNU/Linux ныне ведётся в рамках LSB (Linux Standard Base). Унификация вообще UNIX-систем осуществляется через спецификации POSIX.

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

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

Фактически национальную ОС можно строить от спецификаций по модульному принципу: "законодательная" фиксация интерфейсов сопряжения и альтернативные модули реализации этих интерфейсов. Это автоматически снимает напряжённость противостояния ОС и языков программирования, обеспечивая разумную основу конкурентной борьбы лучших решений. Арбитраж может быть возложен на национальные органы сертификации, которые должны отслеживать несоответствие продукции требованиям технических регламентов, и сам внутренний рынок, который будет выбирать для себя лучшие, надёжные, эффективные варианты соответствующих модулей.

Из этого следует, что имеет смысл во главу угла поставить стандартизацию, связанную с национальной ОС и её приложениями. С тем, чтобы на уровне государства контролировать и развивать интерфейсы сопряжения и форматы представления. С минимальной привязкой к конкретной ОС. Это большая задача, но риски минимизируются за счёт того, что под такое "законодательство" всегда можно будет подводить конкретную реализацию из существующих. Включая как Windows, так и разные дистрибутивы GNU/Linux, BSD, QNX и т.п. Стандартизация "разъёмов", "каркасов" и "пластов" даст мощный импульс развитию. К тому же она позволит и тем, кто планирует разработку своих ОС, инструментов и прикладных систем, выстраивать подъездные пути к развиваемой операционной инфраструктуре. Значит, можно сосредоточиться на создании спецификаций для национальных операционных и прикладных платформ. Конкретизация которых под требования национальной ОС может быть проведена в достаточно короткий срок.

Теперь к вопросу о том, из чего строить. Очевидно, что наибольший задел имеется в сфере ПО с открытым кодом вообще и свободного ПО, в частности. В то же время, нам не стоит забывать, что само по себе наличие исходных текстов — это далеко не гарантия контроля и технологической независимости. При большом объёме, некачественной реализации и отсутствии исходных спецификаций это может быть сродни технологическому мусору. Простая аналогия. Если есть техническое устройство, у которого открыты только разъёмы (закрытый, проприетарный код), — это даёт гарантию целостности заложенного в него функционала, но в обмен на потерю внешнего контроля за развитием этого устройства. Если мы вскрываем устройство (открытый код) и видим его внутренности, это помогает разобраться в специфике работы, но всё ещё не дает возможности получить полный контроль. Для этого нужны проектные спецификации (техническая документация) в совокупности с эталонной реализацией (открытым кодом). Вот по этому пути и надо идти.

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

Фактически то, что мы называем национальной или государственной ОС в контексте всего вышеизложенного, является более крупным образованием — национальной операционной инфраструктурой. И если проводить некие параллели со знаменитой амбициозной американской программой середины 1990-х годов бывшего вице-президента США Альберта Гора — Национальной информационной инфраструктурой (NII, National Information Infrastructure) — то нетрудно заметить, что здесь нет той размытости решений, которая в конечном итоге в США привела к тихому сползанию громкой инициативы в декларирование высоких целей и банальный делёж федерального бюджета.

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

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

Приведу для конкретики всего два примера по линии Российской академии наук (РАН). Из двух областей, в которых ещё сохранены традиции нашего мирового лидерства: (1) вычислительная математика и (2) инструментальные системы; где особенно высока наукоёмкость.

Так, Институт вычислительной математики и математической геофизики Сибирского отделения РАН, на базе которого был создан Сибирский суперкомпьютерный центр, прорабатывает проект создания комплекса математических библиотек нового поколения с высокой точностью вычислений, который опирается на уникальные разработке российских математиков. В конце прошлого года этот институт инициировал работы по созданию Фонда алгоритмов и программ СО РАН.

Другой пример. Институт систем информатики им. А.П.Ершова СО РАН обладает уникальным опытом создания компиляторов, инструментальных систем и ОС специального назначения, прежде всего, для бортового программного обеспечения российских спутников и уже выступал с предложением провести научно-исследовательский проект, нацеленный на практическую разработку операционной системы следующего поколения и создание в России соответствующего центра компетенции на базе научно-образовательной инфраструктуры новосибирского Академгородка. В качестве отправной точки этот коллектив намерен использовать результаты работ, проводившихся в 1980-х годах в рамках ВНТК «Старт». Тогда, по заказу ГКНТ СССР была создана оригинальная и независимая операционная система Excelsior с UNIX-подобным интерфейсом вместе с полнофункциональной средой разработки ПО для оригинальной 32-разрядной отечественной процессорной архитектуры. Работа была высоко оценена рядом отечественных и зарубежных специалистов, в частности, знаменитым швейцарским профессором Никлаусом Виртом (ETH Zurich).

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

Америка в компьютерной сфере давно уже подмяла науку под бизнес. Причём хоронила её методично. Ныне Европа в области программирования хоть и робко, но всё же начинает пересматривать свою почти рабскую зависимость от Штатов. И моё глубокое убеждение, которое вынес из многолетнего личного общения с лучшими европейскими учёными, — без потенциала России и стран бывшего Советского Союза самостоятельно из нынешней ямы Европе не выбраться.

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

RB38. Отечественная или государственная ОС?

Предыдущая заметка:


Тема отечественной ОС с завидной регулярностью всплывает на поверхность и становится предметом жарких дискуссий: от "народных" интернет-форумов до самых высоких государственных инстанций, включая Госдуму.

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

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

В настоящее время на мировом рынке персональных компьютеров наиболее ярко выделяются три семейства операционных систем:
1. Windows (Microsoft, США)
2. Mac OS (Apple Inc., США)
3. GNU/Linux

Первые два – коммерческие, неклонируемые. "Порт приписки" их авторов и владельцев сомнений не вызывает – США. С последним семейством не всё так очевидно. Есть ядро (Linux), есть обвязка (преимущественно, на базе GNU). Обвязка является предметом клонирования, творческих изысканий огромного количества компаний. Одних только дистрибутивов GNU/Linux в мире ныне насчитывается свыше 5 сотен. С ядром ситуация более определённая: в его развитии львиная доля вложений финансовых и людских идет со стороны тройки компаний: IBM, Novell, RedHat. Все они имеют тот же "порт приписки" – США. Это объективно. И игнорировать подобный факт неразумно.

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

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

Какой же вывод напрашивается? Однополярность мира крайне опасна. И в сфере ОС также. Нужны разные полюса со своими механизмами сдержек и противовесов, позволяющие соблюсти баланс интересов и снизить риски. Самый очевидный путь минимизации рисков здесь, при формировании государственных ОС, – перелицовка и "национализация" наиболее распространённых ОС. Windows и Mac OS для подобного мало подходят, поскольку привязаны к конкретным компаниям (конкретной стране) и просто в силу этого риски снизить никак не могут. Остаются разве что ОС из сферы свободного ПО, прежде всего, GNU/Linux. По этому пути наименьшего сопротивления движение в разных странах (разумеется, отличных от США) и ведётся. Это позволяет частично решить задачу, но лишь частично. Если двигатель (ядро) контролируется и развивается не владельцем ОС, то угроза зависимости по-прежнему сохраняется.

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

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

Как же быть, чтобы минимизировать риски? Двигаться по пути многополярного мира ОС, опираясь на технологии их сосуществования (в т.ч. механизм гипервизоров). "Национализировать", адаптировать проверенные временем свободные ОС, прежде всего, GNU/Linux. Но при этом не плыть по течению, а осознанно следовать принципам модуляризации – вычленению значимых блоков-модулей, которые при согласованном интерфейсе сопряжений могут допускать альтернативные реализации разных разработчиков. Создать основу для подпитки решений со стороны новых, экспериментальных ОС.

Можно и нужно в обвязке Linux формировать на основе открытых международных стандартов собственную государственную операционную инфраструктуру, собственную операционную среду, со своими API-интерфейсами, которая позволила бы:
1) взять под полный контроль на долгосрочную перспективу развитие государственной ОС;
2) стимулировать развитие рынка инструментальных и прикладных программных продуктов (в особенности, для госсектора, науки и образования);
3) унифицировать интерфейсы, уйти от опасной дефрагментации Linux-дистрибутивов;
4) за счет модуляризации создать предпосылки для постепенной замены модулей ОС на более эффективные, разработанные сторонними разработчиками и прошедшие соответствующий госконтроль;
5) обеспечить операционное сосуществование различных ОС на одном компьютере.

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

В своих "Заветных мыслях" (1905) Д.И.Менделеев писал: "Хотя истина, конечно, одна, но пути к ней не намечаются ныне ни звёздами, ни столбами, двигаться же по пути достижения истины необходимо, чтобы не быть насильно увлечённым неизбежно надвигающимися историческими переменами и сознанием ускорить предстоящую эволюцию. Двигаться же можно или в одиночку, или сплотясь группами, ища в разных направлениях, так как идти всей массой сразу, гуртом, как стадо, лишь в одну сторону, можно только под влиянием бессознательного убеждения, причём мало вероятности попасть на верную дорогу, и многое в истории показывает, что такое стадное движение нередко ведёт к гибели".

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

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

RB37. Роса и НИП

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

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

В результате проект, как и вся наша группа, выведены из-под НИПа. Мы не сможем в дальнейшем использовать товарный знак "Роса". Работы в течение этого времени не прекращались, но во избежание ненужных проблем вести их были вынуждены в закрытом режиме и весьма небольшой группой.

С сентября мы возвращаемся к публичной деятельности и переходим к новым, более безопасным формам развития проекта. Проектирование новой ОС будет осуществлять конструкторская группа компании "Метасистемы", руководство которой (Борис Рюмшин, Илья Ермаков) с самых первых дней находится в ядре группы и вносит наиболее существенный вклад в его развитие. Руководство проектом возглавит Борис Рюмшин. Информационное сопровождение будут осуществлять сайты OberonCore.ru и EuroProg.ru. Те функции, которые первоначально планировалось возложить на сайт НИПа, во многом отойдут Европейскому центру программирования (EuroProg.ru), на реорганизацию которого я и переключаюсь.

Контакты по проекту новой ОС необходимо вести через этот адрес: girs-orel@oberoncore.ru.

RB36. Singularity и Microsoft TechFest 2008

Предыдущая заметка:
  • RB35 (21.02.2008) Об Учителе. Памяти И.В.Поттосина
  • Оглавление

    4 марта на ежегодном фестивале TechFest 2008, который проводит Microsoft Research на территории кампуса Microsoft в Редмонде, были представлены перспективные разработки исследовательского подразделения корпорации. Среди них можно выделить реконфигурируемую аппаратную платформу BEE3 (Berkeley Emulation Engine) и макет экспериментальной операционной системы Singularity.

    Оба проекта роднит то, что лежащие в основе их идеи вышли из знаменитой исследовательской лаборатории Xerox PARC (проекты Alto и Cedar). Оба являются испытательными полигонами программных и аппаратных решений для формирования и исследования различных компьютерных архитектур.

    Лидер проекта BEE Чарльз Теккер (Charles Thacker) был главным конструктором Xerox Alto и одним из основателей DEC Systems Research Center — ведущего исследовательского центра корпорации Digital, куда в начале 1980-х ушли многие исследователи из Xerox PARC. В DEC SRC он возглавлял разработку многопроцессорной рабочей станции Firefly (эскпериментальные языки Modula-2+ и Modula-3) и прототипа процессора DEC Alpha.

    Главный конструктор ОС Singularity Гален Хант (Galen C. Hunt) принадлежит другому поколению и имеет совсем иную школу. Начинал с языка Си и принимал участие на ранней стадии разработки ядра Linux (драйвер консоли для Linux 0.11). Участвовал в реализации компилятора Objective-C из набора GCC (GNU Compiler Collection). Во время обучения в университете Рочестера (США) как талантливый студент привлекался к работе в Microsoft Research. Затем работал в производственных подразделениях Microsoft. В 2003 г. вслед за выпуском ETH Zurich первого публичного релиза Bluebottle (преемницы ОС Oberon) возглавил работу коллектива примерно из 50 сотрудников Microsoft Research над экспериментальной ОС Singularity, где предпринята попытка совместить идеи Xerox Cedar (проекта-вдохновителя ОС Oberon) и Microsoft .NET.

    Помимо представления своих перспективных разработок Microsoft сделала доступными исходные тексты первого публичного релиза экспериментальной ОС Singularity (Singularity Research Development Kit 1.1, RDK) для некоммерческого использования: http://www.codeplex.com/singularity (60 Мбайт).

    В чем цель ведения концепт-проекта Singularity и подобной публичности? С технологической точки зрения — показать, как можно писать компактную конкурентноспособную ОС с нуля, используя возможности обеспечения надёжности за счёт языка реализации высокого уровня (Sing#) и языкового инструментария (Bartok). Но, по всей видимости, основная (политическая) цель — "застолбить" весьма перспективное направление, на которое уже покусились различные европейские группы. Это превентивный удар. И пусть теперь общественность гадает — пойдут ли данные проработки в дело или же станут очередным отвлекающим маневром Microsoft.

    Дополнительная информация:

  • RB09. Оберон и предыстория Bluebottle
  • RB10. От Oberon к Bluebottle
  • RB26. Дуальность и другие контуры “Росы"
  • RB27. Пути восхождения к новой ОС
  • RB31. Публичный старт проекта "Роса"


    Видеоматериалы по ОС Singularity (Microsoft Channel 9):

  • A Research OS Written In C#
  • Singularity Revisited
  • Singularity III: Revenge of the SIP
  • Singularity IV: Return of the UI

    RB35. Об Учителе. Памяти И.В.Поттосина






    Предыдущие заметки:
  • RB34 (03.12.2007) “Роса”: перенацеливаемая отечественная ОС нового поколения
  • RB33 (27.11.2007) Лебединая песнь Digital
  • RB32 (22.11.2007) Ортогональная система языков в проекте "Роса"
  • RB31 (22.11.2007) Публичный старт проекта "Роса"
  • Оглавление


    Памяти Игоря Васильевича Поттосина
    К 75-летию со дня рождения

    В нашей жизни, увы, редко можно встретить людей такой высочайшей нравственной культуры, глубокой образованности, беззаветного служения своему делу и своей стране. Редко можно встретить настоящего русского интеллигента.

    Игорь Васильевич всегда старался оставаться в тени. Был блестящим организатором науки, правой рукой Андрея Петровича Ершова, при этом мудро и обстоятельно делал своё дело, не гонясь за званиями, наградами, научным и общественным признанием. После смерти Ершова (1988) Игорь Васильевич взвалил на себя нелёгкую ношу продолжения духа и традиций сибирской школы программирования. Стал директором Института систем информатики им. Ершова (ИСИ СО РАН) — преемника знаменитого Отдела программирования ВЦ СО АН СССР, который они с Ершовым и формировали в конце 1950-х годов.

    Впервые мне довелось познакомиться с Игорем Васильевичем в студенческие годы, когда учился на 4-м курсе Московского авиационного института (МАИ). В мае 1986 г. на базе ВЦ СО АН СССР проводился семинар «Язык программирования Модула-2 и инструментальные средства на его основе» (PDF). Поттосин, во многом разделявший взгляды Никлауса Вирта на продуманность и лаконичность выражения идей, давно положил глаз на новое творение маэстро языков программирования. В дальнейшем именно этот язык стал одним из любимых у Поттосина. Два ученика Игоря Васильевича — Дмитрий Кузнецов и Алексей Недоря — стали программистским ядром проекта Кронос: 32-разрядного отечественного персонального компьютера, ориентированного на Модулу-2. Он зародился в 1984 г. в одной из комнат общежития Новосибирского университета (НГУ). Тот проект дал жизнь и новой отечественной операционной системе Excelsior (внешне напоминает UNIX System V, реализована на Модуле-2), и настоящей фабрике по производству высококачественных компиляторов, которая теперь находится в ведении новосибирской компании Excelsior, где собралось немало кроносоведов и кроносолюбов, продолжающих славные традиции романтических 1980-х.

    Именно Модула-2 стала для меня той путеводной звездой, которая и привела к Поттосину. В 1983 г. в Московском Доме книги, что на Новом Арбате, мне посчастливилось приобрести серебристую книгу на английском языке. То был бестселлер проф. Вирта Programming in Modula-2. И программирование, и технический английский я начинал осваивать именно по этой книге. Затем в поисках доступных трансляторов и библиотек постепенно вышел на отечественную Рабочую группу по Модуле-2 (детище Дмитрия Михайловича Сагателяна из Института общей физики АН СССР). А через неё и попал в Новосибирск.

    Следующая встреча с Игорем Васильевичем произошла также в новосибирском Академгородке два года спустя (1988). Я представлял на Всесоюзной научной конференции «Методы трансляции и конструирования программ» тему направления, которое стало моей дипломной работой — «Методология разработки сложных программных систем», где обобщался опыт работы с Адой и Модулой-2 применительно к использованию мультипроцессных систем, опирающихся на верификацию формальных моделей (сети Петри). Честно говоря, было удивительно наблюдать отеческое внимание такого мэтра по отношению к рядовому дипломнику из Москвы. Он знакомил с Академгородком, ВЦ СО АН СССР, библиотекой Ершова.

    На фоне бесконечной московской суеты здесь был совсем иной мир. Это трудно передать словами. Просто другая планета. Библиотека произвела сильное впечатление, хотя в те дни уже не было того информационного голода, который во многом с 1960-х годов пытался компенсировать А. П. Ершов, привозя из каждой зарубежной поездки журналы, книги, препринты, оттиски статей, документацию — всё, что можно было собрать и увезти. Библиотека Ершова, для работы в которой, как я потом узнал, специалисты приезжали с разных концов страны, была уникальным многотысячным собранием, во многом определявшим высокий уровень развития отечественных школ программирования. И хотя с начала 1980-х на протяжении многих лет я буквально дневал и ночевал в ГПНТБ (Государственная научно-техническая библиотека СССР в Москве), библиотека Ершова заметно выделялась своим фондом, качеством комплектации.

    В 1989 г. Игорь Васильевич занялся подготовкой сборника «Язык Модула-2. Его реализация и использование» (PDF, 18 Мбайт), в который отобрал две работы, написанные мной и моими коллегами по научно-исследовательской работе в МАИ. С его подачи я заинтересовался Модулой-3, после чего вышел на прямые контакты с Биллом Калсовым (Bill Kalsow) и его коллегами в DEC Systems Research Center, поскольку тогда мы начали в МАИ работать над переносом компилятора Модула-3 в MS-DOS с реализацией его на Модуле-2. Затем наступил чёрный период безвременья (1991–1994 гг.), когда научные контакты было трудно поддерживать. Ниточки рвались одна за другой. Нужно было попросту выживать.

    В 1994 г. на базе Международного инженерного университета, пообещавшего финансирование по линии UNESCO и UNIDO, я затеял издание научно-популярного альманаха «Технология программирования» (см. сокращённую PDF-версию; с.1-7, 171-200; 30 Мбайт). Его концепция — стать своеобразным аналогом Scientific American в сфере программирования. Ежеквартальное 200-полосное издание с компакт-диском, где основное внимание уделялось фундаментальным, мировоззренческим вопросам с выделением конкретики в специальные приложения — журналы в журнале. Первый номер увидел свет в мае 1995 г. (за несколько дней до официального анонса Java). Подобного издания не было не только у нас в стране, но и в мире. Предварительные консультации показали, что и наши, и зарубежные учёные очень хорошо восприняли идею и согласились её поддержать. Было очевидно, что противостоять конъюнктуре и развивать это направление в печатном органе можно только при определённой финансовой его независимости. В противном случае всё опять сведётся к бесконечному размусоливанию нюансов API-вызовов, а также рассмотрению костылей популярных языков и систем программирования.

    Игорь Васильевич одним из первых крайне заинтересовался как самой идеей, так и её воплощением. Между нами активизировалась переписка (благо тогда уже электронная почта была вполне доступна). Он прислал мне для публикации обзорный материал «Российские исследования по языкам программирования и трансляции» (PDF). Но в те дни нашим планам не суждено было сбыться. Даже несмотря на то, что финансирование прекратилось не начавшись, мы в последующие годы обсуждали разные моменты, касающиеся идеи журнала и той позитивной атмосферы, которую он может вокруг себя создать. Игорь Васильевич был убеждён — подобное издание в печатном виде у нас будет тяжело пробить, нужны другие ходы. И хотя мы оба тяготели к бумажной форме издания, перспективы виделись именно в Интернете. Но ни аудитория, ни сама Web-среда не были к этому готовы. Пришлось идею отложить до лучших времён.

    С 1996 г. я стал обозревателем, а потом и научным редактором ComputerWeek-Moscow. То был ведущий компьютерный еженедельник страны. Довелось вновь приехать в Новосибирск и встретиться с Игорем Васильевичем — во время визита в Новосибирск Никлауса Вирта (1996) и на Международной конференции памяти А. П. Ершова (PSI). Он приехал встречать в аэропорт Толмачево, а потом мы долго бродили по Акадегородку, где он сдержанно улыбался моим восторгам в отношении IDL и с горечью говорил о непростой ситуации в Академгородке — страну покидали талантливые люди и в воздухе витала атмосфера безысходного запустения. Во время нашей последней встречи в Академгородке он подарил мне редкое издание «А. П. Ершов. Избранные труды», в создании которого и сыграл ведущую роль. Игорь Васильевич был духовно очень сильным человеком, потрясающим оптимистом, но я убеждён, что его внезапный уход из жизни во многом связан именно с той гнетущей атмосферой тотального разрушения культуры, науки и образования, которая окутала всю страну.

    В середине 1997 г. Микаэль Франц, ученик Вирта, позвал к себе в Калифорнию (University of California, Irvine), защищаться и ковать славу мобильного кода. Но ехать в Штаты желания не было. Научная карьера не интересовала, а заниматься любимым делом можно было и дома.

    Осенью 1997 г. Игорь Васильевич переслал мне очень интересное письмо Никлауса Вирта, которое во многом повлияло на мое мировосприятие. Но сначала поясню ситуацию. В июньском номере журнала IEEE Computer (1997) вышла необычная статья под названием «The Feel of Java». Это, кстати, ведущее издание профессиональной ассоциации IEEE Computer Society. Приведу цитату.

    Java — это настоящий язык-трудяга. Это не результат чьей-то диссертации, это язык для работы. Java покажется очень знакомым самым разным программистам, поскольку мы предпочитаем делать проверенные вещи. <...> Итак, что же такое Java? Java ощущаешь как игривый и гибкий язык. Вы можете создавать с его помощью такие вещи, которые сами являются гибкими. Java ощущаешь как детерминированный язык. Если вам хочется, чтобы он что-то сделал, просто попросите его об этом. В нём не видится ничего опасного: вы можете спокойно попробовать что-то сделать, и если окажетесь неправы, то быстро получите сообщение об ошибке. Java ощущаешь как очень богатый язык. Мы постарались снабдить его большой библиотекой классов. Поэтому не откладывайте дело в долгий ящик, а садитесь за компьютер и пишите свой код.

    Не складывается ли впечатление, что перед нами выдержка из рекламного объявления? А ведь эти слова принадлежат Джеймсу Гослингу, не только автору Java, но и человеку, который защитил диссертацию в известном университете Карнеги-Меллон, связанную с проектом Andrew Windows System, и который в те годы стал вице-президентом компании Sun Microsystems.

    «Представьте себе, — не в силах сдержать возмущение, комментирует приведённую цитату Вирт, — что эти слова были написаны в 1960-е годы, и замените слово «Java» на слово «Алгол». Автора сочли бы человеком психически ненормальным, слова его большей частью чужды науке и не имеют с ней ничего общего. Сегодня никто даже не возмущается, нет никакой реакции от «научного» сообщества. Как же низко могла пасть «информатика»? И это делается с молчаливого одобрения такой уважаемой организации, как IEEE Computer Society?» В итоге на свет появилась статья «Java: гадание на кофейной гуще» (PDF, 1998).

    Сам по себе чей-то научный авторитет (каковым обладал Вирт) не был для Поттосина безусловным критерием истины. Помнится, он довольно горячо выражал своё несогласие с позицией знаменитого Петера Наура по роли интуции в программировании. «Интуиция в разработке программного обеспечения» (PDF, 1985). (Эту статью я готовил для второго номера «Технологии программирования».) По его аргументации и убеждённости было видно, что он глубоко прорабатывал данный вопрос.

    Запомнились встречи с Поттосиным в Москве в конце 1990-х. Игорь Васильевич по обыкновению приглашал в гостиницы, где останавливался проездом или по московским делам. Обсуждали различные темы, даже не имеющие отношения к программированию, но в разговорах рано или поздно речь заходила о научно-популярном издании для программистов. Он был удивительно целеустремлённый человек, который с невероятной мягкостью и деликатностью настойчиво продвигал важные вещи. «Мне нравится эта идея», — не раз говорил он. И было ясно, что он имел в виду — «не вздумайте её хоронить»!

    Большое турне Вирта осенью 2005 г., в организации которого мне довелось участвовать с подачи проф. Юрга Гуткнехта (ETH Zurich) и Д. М. Сагателяна, вдохнуло новую жизнь в старый замысел. Но очень остро высветило и тот гигантский разрыв между спросом и предложением — «промывкой мозгов» молодого поколения и действительно фундаментальными вещами, лежащими вне сиюминутной конъюнктуры.

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

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

    Искренне рад, что дело, когда-то поддержанное Игорем Васильевичем, которого я счёл бы за честь называть своим Учителем, не только возрождается, но и благодаря неоценимой помощи друзей и единомышленников начинает понемногу обретать реальные контуры. А что может быть лучшей памятью Учителю?

    Руслан Богатырёв
    Москва
    21.02.2008

    RB34. “Роса”: перенацеливаемая отечественная ОС нового поколения

    Заметки по началу проекта:
  • RB22. О проекте создания отечественной перспективной ОС
  • RB23. О языках реализации в проекте новой ОС
  • RB25. Новая европейская ОС
  • RB26. Дуальность и другие контуры "Росы"
  • RB27. Пути восхождения к новой ОС
  • RB28. Закон Гордона Мура и закон Дэвида Мэя
  • RB31. Публичный старт проекта "Роса"
  • RB32. Ортогональная система языков в проекте "Роса"
  • Оглавление


    30 ноября в Московском авиационном институте (МАИ) в рамках Открытого семинара по ИТ состоялось публичное представление проекта новой отечественной ОС "Роса".


    Выдержки из доклада:

    Сегодня нередко можно слышать голоса: зачем нам своя операционная система (ОС), когда есть другие? Боимся козней тлетворного Запада?

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

    <...>

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

    В России и странах ближнего зарубежья несмотря на разрушение отечественной научно-инженерной школы и соответствующей инфраструктуры, связывающей промышленность, науку и образование, сохранились островки интеллектуального потенциала. Однако самоустранение государства от решения важнейших задач собственного жизнеобеспечения привело к тому, что бизнес стал определяющим, именно под него выстраиваются образование и наука. Вузы вынужденно превращаются в подобие профтехучилищ. Научные институты становятся придатками бизнеса. С каждым годом усиливается тенденция экспорта из страны ее интеллектуального потенциала: в виде кадров, формирования центров разработки крупных зарубежных ИТ-компаний, роста объемов заказного экспортного программирования.

    Но бизнес - это не промышленность. Цель бизнеса - извлечение максимальной прибыли, контроль и расширение рыночной доли. Цель промышленности (отечественной) - развитие собственной страны! Это разные, во многом противоречивые вещи.

    В угоду бизнесу гробятся перспективные направления (если они не приносят осязаемую выгоду сегодня и сейчас). Бизнес в компьютерной сфере пожирает сам себя: вспомним NeXT, вспомним блестящий проект DEC Alpha AXP и корпорацию Digital, вспомним IBM OS/2 и VisualAge Smalltalk. Почему происходит самопожирание бизнеса? Давайте зададимся вопросом: что во главу угла ставят крупные компании? Правильно: сохранение и усиление своего влияния на рынке. Что и даёт необходимую прибыль. А для этого технологическое совершенство не только не полезно, а даже вредно, ибо может подорвать завоёванные позиции.

    <...>

    Отечественная электронная промышленность лежит в руинах. Программная промышленность еще только зарождается… Ее попросту нет. При этом именно программное обеспечение в будущем будет определять темпы роста электронной промышленности. А не наоборот.

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

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

    <...>

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

    <...>

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

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

    <...>

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

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

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

    RB33. Лебединая песнь Digital

    Лебединая песнь Digital.
    Опыт ведения проекта DEC Alpha AXP

    15 лет назад в специализированном журнале Digital Technical Journal корпорации DEC вышла статья Питера Конклина, главного конструктора Alpha AXP – одного из крупнейших проектов в ИТ-индустрии. Эта статья попала мне в руки в конце 1994 г. (благодаря сотрудничеству МАИ и DEC по созданию центра компетенции). В 1995 г. решил её издать в альманахе "Технология программирования" (первом отечественном периодическом 200-страничном издании с CD-диском, посвящённом программированию). При подготовке к старту проекта новой ОС в середине 2006 г. я обратил внимание на эту статью и нашёл там немало полезного в плане организации работ в будущем проекте новой отечественной ОС. Наряду с проектом МАРС и IBM AS/400 (рассказы о которых ещё впереди) он был взят на вооружение. Настало время познакомить с этими материалами и широкие круги общественности.

    Биографическая справка. Питер Конклин (Peter Conklin). В 1963 г. закончил Гарвардский университет (Harvard University) с дипломом математика. В корпорации Digital (DEC) с 1969 г. Был первым инженером по программному обеспечению в рамках проекта VMS. Входил в состав группы VAX A вместе с Уильямом Стрекером (William Strecker, архитектор VAX), Гордоном Беллом (Gordon Bell, архитектор PDP-11) и Дэйвом Катлером (Dave Cutler, будущий архитектор Windows NT и Windows 2000). Руководил группой, занимавшейся разработкой архитектуры VAX, принимал активное участие в проработке ключевых аспектов архитектуры и набора программных средств для VAX/VMS. В ранге директора возглавлял Центр разработки систем Alpha AXP (Alpha AXP Systems Development).


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

    Peter Conklin "Enrollment Management, Managing the Alpha AXP Program" // Digital Technical Journal, 1992, Vol.4, No.4.
    Питер Конклин "Стратегия вовлечения: руководство программой Alpha AXP" // Технология программирования, 01/1995. (Перевод Александра Китаева)


    Питер Конклин пишет:
    ==>
    Программа по разработке систем Alpha AXP была наиболее масштабной в истории корпорации Digital и одной из крупнейших в компьютерной индустрии в целом. В ходе работы над проектом Центр управления программы Alpha (Alpha AXP Program Office) разработал модель, обеспечивающую необходимый инструментарий для управления программой. Может показаться, что руководители программы начали с разработки инструментов, а уж затем в чистом виде применили их на практике. На самом же деле в основе этих подходов лежит многолетний опыт и созданные экспертами методики управления; мы тоже изучали и применяли эти уроки по мере работы над программой. Разумеется, такие показатели, как своевременное выполнение заданий и высокое качество особенно важны при выполнении масштабных программ. Тем не менее, Digital успешно применяла наши методы управления и в сравнительно небольших проектах... Опыт автора говорит о том, что нашу модель управления можно применять в проектах практически любого масштаба. <…>

    Программа Alpha AXP корпорации Digital охватывала проектирование микропроцессорного набора мирового уровня, новой архитектуры, основанной на 64-разрядной системе, множества систем аппаратного обеспечения (от персональных компьютеров до мэйнфреймов), большого числа операционных систем и сотен видов программных продуктов, работающих под управлением этих систем. Разработка продуктов первого поколения длилась несколько лет, и в пик работ в проекте участвовало свыше 2 тыс. инженеров – специалистов в области аппаратного и программного обеспечения, а также системной инженерии. Корпорация Digital осуществляла общее руководство программой через Центр управления (Program Office), где было занято 8 специалистов.

    В работах по программе Alpha AXP на предприятиях Digital, разбросанных по всему миру, участвовало свыше 22 групп инженеров по программному обеспечению и 10 групп инженеров по аппаратным средствам. Последние включали группу по разработке полупроводниковых систем и по одной группе на каждую из платформ систем аппаратного обеспечения. В разработках программного обеспечения участвовали 4 группы по операционным системам, а также группы по разработке средств миграции, сетевых систем, компиляторов, баз данных, сред интеграции и приложений. Число инженеров-разработчиков в некоторых группах доходило до 150 – и это не считая персонала поддержки. Многие из них также заключали контракты с поставщиками как внутри Digital, так и вне ее.

    Организация столь масштабной и сложной программы связана не только с техническими, но и с управленческими проблемами. Поэтому Центр управления рассмотрел и отверг ряд традиционных организационных подходов. В соответствии с классической организационной моделью создается иерархическая или линейная организация, содержащая всех главных исполнителей. Когда речь идет о большой программе, этот подход имеет тот недостаток, что для создания организации требуется слишком много времени. Формирование рабочих групп и установление операционных процедур занимает больше времени, чем позволяет рыночное окно и имеющаяся технология. Итог – грандиозные планы, и ... выполнение проекта на несколько лет позже, чем запланировано. К тому же по окончании работ по программе "временные" организации надо опять реорганизовывать и приводить "в исходное состояние" <...> Один из альтернативных подходов состоит в том, что создаются небольшие, работающие на свой страх и риск группы специалистов, перед которыми ставится задача любой ценой добиться поставленных целей. Так можно работать в рамках небольших проектов, т.н. skunk works. Кстати говоря, именно по этой схеме проводилась первоначальная работа по проектированию программы Alpha. Но когда такой подход применяется в крупных программах, специалисты часто "перегорают", не укладываясь в поставленные перед ними сжатые сроки. А это вызывает бурную реакцию руководства, которое набирает новых людей и продолжает ту же линию – и с теми же результатами.

    Центр формировал программу Alpha AXP как совокупность проектных бригад, которые остаются внутри существующих линейных организаций. Так, каждый проект по разработке программного и аппаратного обеспечения реализовывался внутри своей функциональной группы (полупроводниковые средства, серверы, OpenVMS, UNIX, компиляторы, базы данных, разработка процессоров, сети и т.д.). Работу отдельных проектных бригад координировал Центр управления программой. Такая схема обеспечивала ей гибкость в случае реорганизации функциональных групп.

    Модель управления через вовлечение. Эта модель в программе Alpha состоит из четырех стадий:
    1) уяснение (vision) - вовлечение (enrollment)
    2) обязательства (commitment) – делегирование (delegation)
    3) контроль (inspection) – поддержка (support)
    4) признание (acknowledgement) – изучение (learning).

    Модель в такой форме была разработана автором статьи (главным конструктором Alpha AXP Питером Конклином – прим. Р.Б.). Некоторые элементы ее были предложены на семинарах по управлению или позаимствованы из рекомендаций консультантов. Конкретные формы, применяемые на стадиях уяснения, обязательств и признания возникли в ходе работы по программе Alpha. Стадия "контроль – поддержка" разрабатывалась автором в течение многих лет руководства проектами и ведения надзора. Две концепции являются ключевыми для реализации этой модели в крупных программах. Во-первых, уже упоминавшийся Центр управления. Он обеспечивает необходимую связь, единое понимание концепции программы и структуру контроля, позволяя в то же время специалистам и ресурсам оставаться в их "родных" организациях. Более того, Центр обеспечивает согласованность действий на всем пространстве программы и соблюдение каждой участвующей в работе группой взятых на себя обязательств. Важно подчеркнуть, что небольшой Центр управления программой Alpha, состоящий из менеджеров по различным группам продуктов и по операциям, не имел никакой формальной власти (даже в области распределения средств), поэтому его влияние осуществлялось лишь с помощью методичного вовлечения и делегирования, обозначенных в модели управления. Вторая ключевая концепция – это концепция "переломов" (cusp) в ходе проекта, что означает критическое событие, стимулирующее перемены. <...>

    Уяснение – вовлечение. Стадия уяснения участниками программы ее общей концепции использовалась Центром для того чтобы представить цели программы как общее дело всех соответствующих рабочих групп. Так, уяснение может состоять в осознании коммерческих целей руководства и потребностей клиентов. Для починенных проектов уяснение может включать цели более общего проекта. В любом случае, вовлечение происходит только тогда, когда цели поставлены в понятном для аудитории (проектной бригады) контексте. Центр управления добивается наилучших результатов тогда, когда он выражает концепцию программы языком и понятиями той группы, которая в данный момент вовлекается. Уяснение должно быть достаточно широким, чтобы включать в себя все требуемые обязательства и конечные результаты.

    Обязательства – делегирование. Разрабатывая планы, менеджер проекта делегирует задачи подгруппам и получает от них конкретные обязательства, касающие содержания работы и сроков ее выполнения. Поскольку эти обязательства даются в контексте более широкой концепции – программы в целом, участники подпроекта получают вполне достаточную мотивацию для их выполнения. Ключевым элементом в процессе делегирования является явная спецификация результатов с тем, чтобы они были измеримы и идентифицируемы и имелся бы конкретный ответственный. <...>

    Контроль – поддержка. Менеджер проекта полагается на принятые обязательства и постоянно контролирует состояние дел в проекте для обеспечения соблюдения графика<...> Как только возникает опасность невыполнения взятых обязательств, менеджер проекта объявляет о том, что в работе по проекту наступил "перелом". Термин "перелом" (cusp), позаимствованный у Гляйка (J.Gleick "CHAOS: Making a New Science", 1987), означает потенциальные поворотные пункты или имеющие решающее значение события в ходе работы над проектом. (Для их обозначения часто используются другие слова: gotchas, неудачи, кризисы, поворотные пункты, срывы проекта и "призывы к действию". При работе над программой наши менеджеры использовали и эти термины. Но для наших целей мы принимаем термин "перелом" как эмоционально нейтральный. Суть в том, чтобы на любой стадии проекта применялся такой термин, который как бы открывает возможности действовать иначе, продвигать проект вперед.) В момент перелома все готовы принять перемены, поскольку это приближает достижение общих целей программы. <...>

    Признание – изучение. На каждой стадии проекта Центр управления программой выражает – как в личных контактах, так и публично – признательность участникам, добившимся заметных успехов. И каждый раз в таких случаях руководство программы неоднократно задает вопрос: какие уроки были извлечены и как менеджеры и команда могут в следующий раз добиться еще более высоких результатов. Для достижения более высоких результатов группы часто проходят методическую подготовку.

    Применение модели. Когда Центр управления приступил к ведению полномасштабной программы, мы начали формализовывать эту методологию. По ходу развития событий мы постоянно учились. Нам удалось найти несколько учебников, полезных в деле эффективной организации столь масштабной программы. Но значительную часть своего инструментария Центр управления разработал "на месте", набираясь опыта по ходу развития проекта<...> Большинство менеджеров проекта следовали модели управления через вовлечение, руководствуясь интуицией (опытом) или чьим-то примером. В нескольких случаях они официально проходили подготовку по управлению проектами такого уровня сложности в сторонних организациях. В зависимости от масштаба проекта или подпроекта менеджеры применяли данную модель с большей или меньшей степенью строгости. Так, в крупных проектах и в рамках программы в целом применялись официальные собрания, посвященные контролю работ. Менеджеры подчиненных проектов могли сами выбирать форму контроля – официальную или неофициальную. А чтобы в сфере управления не появлялось неприятных сюрпризов, руководство программы следило за организацией контроля в каждой группе.

    Как указывалось выше, переломы – это решающие события в ходе развития проекта, или кризисы. Цель традиционного управления проектом состоит в том, чтобы избежать таких кризисов с помощью жесткого планирования. Центр управления программой принял противоположный подход: мы стремились вникнуть в суть критических событий и использовать эти переломы для наращивания темпов работы над проектом<...> Каждый раз, когда проект приближался к очередному перелому, Центр управления быстро принимал меры к тому, чтобы проект продолжал двигаться в нужном направлении. Иными словами, план был нужен руководителям не для "галочки". Его главные пункты и другие события использовались как средство управления скоростью проекта, который следовало неустанно направлять в сторону намеченной цели. Часто мы сами создавали ситуацию перелома для ускорения необходимых перемен (например, провоцируя кризис в соблюдении графика). <...> Когда руководители научились конструктивно использовать переломы проекта, Центр управления приступил к активному провоцированию новых переломов. В итоге создавался "эффект бумеранга", скорость выполнения работ и темп выполнения программы повышались. <...> По мере того как руководство признавало все новые и новые достижения, темп реализации программы возрастал от очень низкого до среднего и, наконец, она, образно говоря, переключалась на высокую передачу. <...>

    Программа Alpha AXP выросла из компьютерных исследований, точнее – из исследований по технологиям и преимуществам различных RISC-архитектур, а также из передовых разработок в области создания компиляторов, проектирования СБИС и производства полупроводниковых систем. В 1988 г. руководство корпорации Digital поставило перед инженерным департаментом задачу разработать систему, которая бы удовлетворяла потребность клиентов в плане первоклассных эксплуатационных характеристик во всех вычислительных средах корпорации Digital. Инженерный департамент из представителей разных подразделений сформировал рабочую группу, которая разработала необходимую системную архитектуру и проектную документацию. <...> Руководство Digital одобрило программу Alpha AXP в октябре 1988 г. К концу 1989 г. Digital завершила упомянутые разработки, а также работу с документацией по архитектуре и предварительному проектированию. В ходе широкой проверки в январе 1990 г. высшее руководство потребовало, чтобы работы по программе были ускорены и завершены в пределах "рыночного окна" для новой технологии. <...>

    Когда программа Alpha AXP была одобрена, Центр управления начал проводить ежеквартальные обзорные собрания. На этих форумах группы докладывали о планах и о ходе работы для широкой аудитории, состоящей из специалистов разного профилей. Сначала эта аудитория состояла из групп инженеров, производственных и сервисных групп. По мере того как программа набирала темпы, в работу включились другие специалисты – по маркетингу и сбыту; они тоже начали сообщать о ходе своей работы. Эти форумы помогли установить доверие и упрочить принцип вовлечения. Они также помогли Центру выявлять проблемные участки до назревания кризиса. Мы добились понимания всеми участниками программы важности массового выпуска продукции в 1992 г.

    После того как ключевые менеджеры проектов усвоили общую концепцию программы, нам предстояло сделать следующий шаг – создать рабочий план и обеспечить обязательство каждой группы выполнить свою задачу в установленные сроки. <...> Необходимость одновременной разработки многочисленных аппаратных и программных систем осложняла задачу координации. Центр управления решал эту проблему комплексной координации по двум направлениям: в плане технического менеджмента и менеджмента проекта. По техническому направлению Центр сформировал команду технических руководителей из основных инженерных групп, известную как EJST (EVAX Joint Systems Team; EVAX – первоначальное название программы Alpha AXP – прим. Р.Б.). <...> Эта группа на еженедельных заседаниях вырабатывала директивы по вопросам технического проектирования и стратегическим вопросам, касающимся сразу нескольких групп. Поскольку в компетенцию этой группы входило решение проблем и обеспечение выполнения решений, EJST превратилась в орган, куда работники представляли технические проблемы для их разрешения.

    В области управления проектами менеджер программы сформировал команду менеджеров проектов. Каждый член этой команды был уполномочен соответствующей группой инженерной разработки брать обязательства и отвечать за их выполнение. Эта команда была известна как ASPM (Alpha AXP System Project Managers). Масштабность генеральной задачи и сложность понимания всех деталей взаимозависимостей в ходе работы привели к тому, что менеджерам проекта сам проект, как правило, представлялся невероятно сложным. Поэтому на уровне программы проблема состояла в том, чтобы создать генеральный общий план Alpha AXP. Но этот план создавался значительно медленнее, чем мы ожидали. Неспособность администраторов создать генеральный план привела к возникновению кризиса доверия. Менеджеры проектов грозили мятежом (или уходом в другие проекты). Технические руководители разрабатывали все более масштабную проектную документацию. Менеджеры групп инженерной разработки заявили, что Центр управления программой стоит на пороге кризиса. Нам нужно было создать рабочий план для всей программы, из которого следовало бы, в каком порядке каждый подпроект должен представить результаты своего труда (выполнить свою задачу).

    Как координировать работу, не имея плана? Менеджер программы Alpha AXP постоянно требовал от отдельных групп предоставления их планов. От чего зависит ваша работа? Какое время она займет? Какие средства вам потребуются? Каковы основные этапы или параметры вашей работы? Постоянным ответом было: "Не знаю – мне же неизвестно, что делают остальные и когда они закончат свою часть". К этому времени мы уже создали состоящую из опытных менеджеров проектов многофункциональную команду ASPM, в которой было представлено большинство групп разработчиков. И эта команда не имела возможности составить планы работы подразделений, поскольку у нее не было генерального плана.

    Выбор стратегии. Для разработки общих параметров плана программы Alpha AXP менеджеры инженерных групп разработки собрались на заседание, которое длилось целый день. Сначала они установили коммерческие цели и исследовали различные технические ограничения. Критерием для включения в план того или иного компонента был ответ на вопрос: "Имеет ли она решающее значение для достижения коммерческого успеха программы Alpha AXP"? Такая постановка обеспечила серьезный подход к содержанию генерального плана, причем решение о включении или невключении того или иного компонента оставалось за ответственной группой разработки. Затем эта группа определяла организационные аспекты такого рабочего плана. Члены группы рассматривали коммерческие, технологические и организационные аспекты для определения приоритетов и порядка работы. Мы дали этой группе статус Совета директоров по разработке систем Alpha AXP (ASBOD – Alpha AXP System Board of Directors; в результате общая структура управления проектом Alpha AXP включала в себя Центр управления проектом, группу технических директоров EJST, группу менеджеров проектов ASPM и все инженерные группы, находящиеся под контролем ASBOD – прим. Р.Б.).

    Представление плана. Когда были установлены важнейшие приоритеты и ограничения программы, менеджер программы Alpha AXP приступил к составлению генерального плана. Чтобы дать возможность каждой группе видеть свое место в общей работе, он решил ограничить генеральный план одной страницей текста. Он определил содержание плана в рамках интенсивного периода, в ходе которого просил участников описать свои посылки и задачи и показать, как вписывается в общий план вклад каждой из участвующих групп. Одностраничный формат плана заставил команду управленцев (группу управления) отбирать в него лишь самое важное и позволил участникам увидеть свои участки работы, не перегруженные конкретными сложностями работы данной группы. Далее, на обзорных совещаниях всем участникам было легко видеть картину в одном и том же свете, в котором результаты можно видеть, обсуждать и приходить к общему согласию относительно стоящих проблем. Когда группа управления составила план, он был рекомендован менеджерами проектов (ASPM) и одобрен менеджерами группы инженерных разработок (ASBOD). Теперь члены группы знали, что их цели не будут меняться без явно указанных причин. К тому же другие могут начать составлять свои планы на основе согласованного набора предпосылок. Возникшая в результате страница текста стала точкой отсчета для установления и усиления постоянства целей. Мы назвали ее "соломенная лошадка" – Straw Horse Plan. <...> Позднее мы повысили ранг этого плана, назвав его "оловянной лошадкой" (Tin Horse) и подчеркивая тем самым повысившуюся надежность лежащих в его основе планов и обязательств. Мы пришли к согласию относительно генерального плана размером в одну страницу, исходя из которого бригады (teams) могли создавать собственные планы. <...>

    Еще в начале 1980-х годов один из вице-президентов нашей корпорации любил повторять: "Не полагайтесь на обещанию. Результат определяют проверки". <...> В прошлом проверки, проводимые линейным руководством, как правило, вели к тому, что подчиненные утаивали недостатки до тех пор, пока те не превращались в трудноразрешимые проблемы. У нас же менеджер программы, действующий в рамках концепции Центра управления, не был наделен административной властью, и ежемесячные оперативные проверки проходили в открытой и доброжелательной атмосфере. Отчитывались ответственные менеджеры проектов, представлявшие каждую группу разработчиков. При этом Центр призывал всех участников сообщать о своих трудностях и проблемах до того, как ситуация выйдет из-под контроля. И здесь мы использовали документы одностраничного формата. В верхней части такого документа в простой, наглядной форме представлялся ход решения важнейших задач, позволяющий легко проследить повторяющиеся задержки по срокам. Упор делался на событиях критического пути, завершенных в прошлом месяце и тех, что предстояли в следующем месяце. В нижней части документа перечислялись как решенные, так и новые задачи с четким указанием ответственного и срока выполнения. <...>

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

    После уяснения общей концепции программы и составления планов мы все оказались во власти эйфории. Но вскоре на смену ей пришло отчаяние, вызванное пониманием огромной сложности предстоящей работы. Главной проблемой в тот момент было сдвинуть программу с мертовй точки. Модель управления через вовлечение подразумевает тесную связь между наращиванием темпов (стадия признания -- изучения) и стадией контроля. Иными словами, события, установленные в ходе проверки, помогли нам раскручивать маховик всей программы. Центр управления активизировал усилия по разъяснению ее общей концепции, и когда исполнители все активнее стали браться за дело, у них уже не было времени предаваться унынию перед лицом предстоящей работы. Размах нашей программы был поистине колоссальным, и неудивительно, что у многих участников стали опускаться руки. По коридорам пошли разговоры о том, что всю работу не переделаешь, что график будет постоянно срываться и всем придется работать сверхурочно. Этот синдром типичен для любого крупного проекта, особенно если его участники вынуждены брать на себя обязательства, связанные с серьезным риском. В этих условиях руководство программы приняло решение информировать участников даже о небольших успехах. Широко распространяя соответствующие сообщения по сети электронной почты корпорации Digital, мы начали вселять уверенность в своих людей. Этой уверенностью заражались другие группы, и они тоже добивались успеха. Словно волна прокатилась по всем подразделениям, участвовавшим в программе: все новые группы приходили к выводу, что предстоящая работа им под силу; и вот уже каждый коллектив стремится к тому, чтобы его достижения получили огласку. Программа стала набирать обороты.

    Центр управления программой убедился в том, что простая благодарность, выраженная в форме публичного признанияи достижений участников проекта, высоко оценивается ими и может служить серьезным стимулирующим фактором. Этот вывод противоречит установке традиционной теории управления, согласно которой мотивировать людей к труду следует с помощью частых денежных вознаграждений. Спору нет, от премии никто не откажется, но все же самый мощный стимул для профессионала – благодарность за хорошую и нужную работу. Надо отметить, что курс на признание заслуг принес еще один положительный эффект – увереннее стали чувствовать себя менеджеры проектов. <...>

    На дальнейших этапах реализации программы Alpha AXP Центр управления программой развернул активную работу с другими фирмами и покупателями. Поэтому мы все время знали, что думают о нашей программе другие. <...>

    Все рабочие группы программы Alpha AXP уделяли первостепенное внимание качеству своей работы. Менеджеры неоднократно убеждались в справедливости афоризма Фила Кросби -- "качество бесплатно" (P.Crosby "Quality Is Free: The Art of Making Quality Certain", 1979). Анализ работы различных групп неизменно свидетельствовал: там, где с самого начала качеству уделяют неослабное внимание, задание выполняется в срок или даже досрочно. Однако, руководство программы обратило внимание на то, что мы не занимаемся проверкой работы по повышению качества на уровне систем, а ведь клиента интересует лишь качество конечного продукта. И вот, когда различные проекты начали выстраиваться в единую систему, Центр управления создал независимую группу контроля качества уже на уровне всей программы. <...>

    Результаты и уроки. Несмотря на многочисленные трудности корпорация Digital с точностью до месяца (речь идет о сроках серийных поставок) выдержала общий график работ. Система Alpha AXP соответствует проектным рабочим характеристикам при отличном качестве конечных продуктов. Совет директоров Digital утвердил бизнес-план программы Alpha AXP в полном объеме и выделил средства, необходимые для коммерческой реализации семейства машин Alpha AXP. <...>

    Полностью себя оправдали и концепция Центра управления, и связанная с ней модель управления через вовлечение. <...> Надежным инструментом повышения эффективности работы оказалось творческое использование переломов в ходе проекта. С помощью введения общего графика работ и дисциплины, поддерживаемой регулярными проверками, мы добились того, что график стал своеобразным инструментом утверждения разделяемой всеми концепции программы. Между тем, обычно график воспринимается как некое дополнительное бремя. В результате большинство групп вовремя справилось с весьма масштабными заданиями. А несколько групп, решавших чрезвычайно сложные задачи, перекрыли график. <...> Разумеется, один из важных уроков состоял в том, что перед собой надо ставить четкие задачи и не отступать от них, но в то же время постоянно учиться и корректировать подробные планы. Ключевую роль в поддержании единства целей играет их компактное изложение на одной странице текста и общий план программы.

    Что нужно было сделать по-другому. Если смотреть с позиций дня сегодняшнего, следовало бы изменить наш подход к программе в двух отношениях. Во-первых, было бы полезно познакомить руководителей проектов с методологией управления в большем объеме и на более ранней стадии. Дело в том, что несколько проектов были завершены со значительным опозданием, и это создало ненужные осложнения для других групп. Центру управления следовало бы быстрее и энергичнее пропагандировать методологию Ляфлера (R.LaFleur "A Seminar in Project Management", 1990). Мы же не начинали эту работу, пока не убеждались, что группа осознала ее необходимость. Некоторым группам, в том числе группе разработки OpenVMS для Alpha AXP, методологию излагали на ранних этапах их деятельности. Но другие группы так и не усвоили эту дисциплину (ни тогда, ни теперь).

    Во-вторых, Центр должен был шире практиковать проверки состояния дел в отдельных проектах. Некоторые группы слишком долго готовили графики и планы, которые Центр управления был в состоянии понять. <...>

    Программа Alpha AXP – самое сложное предприятие такого рода в истории корпорации Digital – была реализована в срок и с высоким качеством. Для организации коллективной работы, без чего было бы невозможно совершение этого прорыва, Центр управления программы применял жесткую методологию управления.

    <==

    Важно отметить тех, чей вклад был во многом определяющим в этом масштабном проекте. Гордон Белл (Gordon Bell) занимался проработкой архитектуры. Кен Ольсен (Ken Olsen) настойчиво продвигал идею одностраничных планов. Джеф Калб (Jeff Kalb) ввёл принцип состязательности. Боб Сапник (Bob Supnik) проработал идею создания и принципы работы Центра управления программой.

    Проект DEC Alpha AXP (1988-1992). Лебединая песня некогда могущественной корпорации DEC (Digital Equipment Corp.), которая в 1970-1990-х годах была главным конкурентом IBM в области разработки компьютерных систем. Цель – создание единой 64-разрядной платформы нового поколения для всего спектра систем: от микро- до суперкомпьютеров и сопутствующей инфраструктуры (соответствующие ОС, инструментальные средства и др.). Поддержка собственных ОС OpenVMS, Tru64 UNIX (ранее -- DEC OSF/1 AXP, Digital UNIX ), а также Linux, BSD-семейство UNIX, Windows NT. Проект ставил целью осуществить постепенный переход с CISC-архитектуры VAX на RISC-архитектуру Alpha AXP (ранее -- EVAX). Проект был реализован в рекордно короткие сроки. К концу 2000 г. в мире было продано свыше 500 тыс. систем на базе процессоров Alpha. В середине 2003 г. (через 5 лет после исчезновения Digital) фактически снятый с производства процессор Alpha был основой самых производительных суперкомпьютеров!

    Предпосылки к началу проекта Alpha AXP были заложены в ходе работ над PRISM (Parallel Reduced Instruction Set Machine, 1985-1989) – 32-разрядным экспериментальным RISC-процессором корпорации Digital c операционной системой Emerald и программируемым микрокодом Epicode (прообразом Alpha PALcode – уровнем абстрагирования от аппаратуры). Проект PRISM был во многом инициирован в стенах DEC энтузиастом RISC-архитектуры Дэвидом Катлером (проект CASCADE, 1984), будущим главным конструктором Microsoft Windows NT и Windows 2000. Главный конструктор PRISM Рик Витек (Rich Witek) первоначально закладывал в проект 64-разрядную архитектуру.

    Первые экземпляры процессора Alpha AXP были продемонстрированы в феврале 1991 г. и произвели огромное впечатление на руководство Apple. Джон Скулли (John Scully), тогда возглавлявший Apple, пригласил на званный обед основателя и президента DEC Keна Ольсена (Kenneth Olsen), чтобы сделать предложение о стратегическом партнерстве – использовать Alpha AXP в новых моделях компьютеров Apple. Ольсен отклонил предложение. Как впоследствии вспоминал Уильям Деммер (William R. Demmer), бывший вице-президент Digital, отвечавший за бизнес Alpha AXP и VAX, "Кен не хотел, чтобы будущее корпорации зависело от Alpha". Через несколько месяцев Apple заключила альянс с IBM и Motorola по использованию процессоров PowerPC в качестве основных движков своих компьютеров. Через год Ольсен ушел с поста президента. Еще одним ударом по Digital был уход в 1991 г. из компании легендарного Гордона Белла (Gordon Bell), архитектора PDP-4, PDP-5, PDP-6, PDP-11, VAX-11, Alpha AXP. С 1991 по 1995 гг. Белл совмещал работу в своей новой компании с должностью советника в Microsoft, а после 1995 г. стал штатным сотрудником Microsoft Research и полностью отдал себя исследованиям.

    Через 7 лет после упомянутой выше встречи руководства двух компаний Digital была похоронена компанией Compaq, сумевший в рекордно короткий срок при участии Intel и Microsoft уничтожить все следы некогда существовавшей могущественной корпорации. А потом и сама Compaq сдалась на милость победителю в лице HP.

    Дополнительная информация

  • Richard Sites "Alpha AXP Architecture" // Communications of the ACM, February 1993.
  • Richard Sites, Anton Chernoff, Matthew Kirk, Maurice Marks, Scott Robinson "Binary Translation" // Communications of the ACM, February 1993.
  • Nancy Kronenberg, Thomas Benson, Wayne Cardoza, Ravindran Jagannathan, Benjamin Thomas "Porting OpenVMS from VAX to Alpha AXP" // Communications of the ACM, February 1993.
  • Matt Reilly "Designing an Alpha Microprocessor" // IEEE Computer, July 1999.
  • М.Рэйли "Как рождается микропроцессор Alpha" // Открытые системы, #07-08/1999.
  • Л.Черняк "Памяти Digital Equipment Corporation (1957 — 1998)" // Открытые системы, #03/2002.
  • Л.Черняк "От VAX до Alpha" // Computerworld Россия, #08/2005.
  • Дж. Виджаян "Digital открывает перед процессорами Alpha новые перспективы" // Computerworld Россия, #02/1997.
  • Д. де Во "Нелегкие времена Digital" // Computerworld Россия, #12/1997.
  • Р.Богатырев "Даст ли Oberon новый импульс развитию платформы Digital Alpha" // СomputerWeek-Moscow, #40/1997.
  • Р.Богатырев "Compaq и Digital: шок сменяется прозрением" // СomputerWeekly, #05/1998.
  • Р.Богатырев "Эволюция UNIX" // СomputerWeekly, #05/1998.
  • Д.Грей, Л.Род "Alpha на двоих. Compaq передает Intel секреты своего процессора" // Computerworld Россия, #25/2001.
  • Д.Грей "Технологии Alpha на службе у Intel" // Computerworld Россия, #33/2001.
  • Дж.Николаи "Будущее расставание с Alpha" // Computerworld Россия, #48/2002.
  • М.Кузьминский "За явным преимуществом. Alpha 21164 и 21264" // Computerworld Россия, #29/1997.
  • М.Кузьминский "Микроархитектура DEC Alpha 21264" // Открытые системы, #01/1998.
  • М.Кузьминский "Вперед под флагом параллелизма. Микропроцессоры Alpha 21364" // Computerworld Россия, #32/1999.
  • М.Кузьминский "Многонитевая архитектура микропроцессоров. Compaq Alpha 21464, Intel Xeon MP и Itanium Processor Family" // Открытые системы, #01/2002.
  • М.Кузьминский "RISC сдается, но не умирает. СMP, SMT, EPIC — три перспективных подхода к развитию архитектур высокопроизводительных микропроцессоров" // Computerworld Россия, #06/2002.
  • Ю.Долбнев "Операционная система Digital Unix" // Открытые системы, #03/1997.
  • С.Брик, К.Вахрамеев "OpenVMS сегодня и завтра" // Открытые системы #05-06/2000.
  • Л.Левин "Itanium — третья платформа OpenVMS" // PC Week, #41/2007.
  • Л.Черняк "От VAX до лезвий. Операционной системе OpenVMS исполнилось 30 лет, но ее ресурс далеко не исчерпан" // Computerworld Россия, #40/2007.