Назад | Вперед


Пред. заметки, посвящённые новой ОС "Роса", см. Оглавление.

Многие знают закон Гордона Мура (Gordon Moore), одного из основателей корпорации Intel. Этот закон, сформулированный ещё в 1965 г. ("Cramming more components onto integrated circuits", Electronics Magazine, 19 April 1965), гласит, что новые модели микросхем разрабатываются спустя примерно одинаковые периоды (18–24 мес.) после появления своих предшественников, а их ёмкость (число транзисторов) при этом каждый раз возрастает примерно вдвое. Мур говорил не о мощности, не о быстродействии, а о росте сложности процессора. Нередко его закон упрощают, трактуя как двукратный рост быстродействия процессоров каждые два года. Что и в самом деле наблюдается на протяжении последних десятилетий.

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

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

Какую картину мы наблюдаем сегодня? Производительность растёт темпами, заданными законом Мура, а программное обеспечение как было неповоротливым, так им и остаётся. Быть может, здесь есть какая-то закономерность? В своей статье "Оберон как эсперанто программирования" ("Мир ПК-диск", сентябрь 2005) я дал некую оценку распространения закона Мура на объёмы инструментария (систем программирования). Признаюсь, не знал, что в том же сентябре 2005 г. в своей лекции "The Return of Innovation" другую закономерность подметил Дэвид Мэй (David May), архитектор семейства транспьютерных микропроцессоров (группы T2, T4, T8, T900) в знаменитой английской компании Inmos (язык Occam), а ныне — профессор Бристольского университета в Великобритании. Закон Мэя гласит, что эффективность программного обеспечения падает вдвое каждые 18 месяцев, компенсируя закон Мура.

Как отмечает Мэй, в соответствии с законом Мура каждые 18 месяцев удваивается отношение производительности к стоимости. Это позволяет увеличивать отношение функциональности к производительности (при фиксированной стоимости) или уменьшать стоимость при фиксированном отношении функциональности к производительности.

Мэй отмечает, что нынешние программные системы полны ошибок, чересчур велики и сложны для понимания. С этим трудно не согласиться. Беда в том, что такая ситуация устраивает очень многих. Устраивает производителей процессоров (в них нуждаются постоянно, чтобы мощью процессоров гасить непрерывное падение эффективности ПО). Устраивает производителей операционных систем (их задача – привязать к себе пользователей, при сохранении стоимости на новые версии ОС нагрузить до предела новые процессорные мощности, демпфируя их рост). Устраивает производителей инструментария (он усложняется и пухнет, но при этом позволяет лишь держаться на плаву на достигнутой отметке). Такой расклад удобен тем компаниям, которые заинтересованы за счёт избыточной сложности приковывать к себе клиентов и именно на этом строить свой бизнес. Но в этом не заинтересованы потребители (которые и расхлёбывают все прелести ненадёжных тысячеслойных систем), а также те разработчики, которым нужно создавать технологически совершенные системы, чтобы не привязываться к процессу постоянной компенсации старых ошибок путём введения ещё большего числа новых. Но они во многом подневольны и вынуждены использовать то, что диктует рынок. Собственно говоря, ИТ-индустрия и выстроена в такой последовательности воздействия одного на другое. Первичны процессоры, далее идут операционные системы и лишь потом инструментарий. Сегодня уже как-то неловко говорить о том, что в идеале должно быть в точности наоборот. Впрочем некий исторический экскурс в эту проблематику сквозь призму работ швейцарской школы Вирта и отечественного проекта МАРС (Модульные асинхронные развиваемые системы, ВНТК "Старт") лет десять назад я уже давал. См. серию из трёх статей под общим названием "Язык как основа архитектуры":
1. Проект Lilithhttp://www.europrog.ru/paper/lilith.pdf
2. Проект "Кронос" и путь к технологиям XDShttp://www.europrog.ru/paper/kronos.pdf
3. Средства кросс-разработки и технологии XDShttp://www.europrog.ru/paper/xds.pdf

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

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

Думаю, немногие знакомы со статьей профессора Дэвида Парнаса "Старение программного обеспечения" ("Software Aging", 1994). Того самого Парнаса, с работ которого начала 1970-х ведётся отсчёт эры модульного программирования и принципа информационного сокрытия (information hiding). В статье достаточно убедительно показан тот феномен, как программа, будучи вроде бы математической абстракцией (которая должна оставаться справедливой и спустя 200 лет), тем не менее подвержена старению. Причины — она живёт в мире изменений. Старение, по словам Парнаса, может и будет возникать в любом успешном продукте. Это надо знать и, если требуется строить максимально адаптивную систему, закладывать данное знание в проект. Чтобы этого добиться (добавлю от себя), недостаточно только предусматривать возможности возникновения различных классов изменений как на стадии разработки продукта, так и в период его использования и развития. Важно выстраивать фундамент с возможностью расширения/коммутации и минимизацией зависимостей. Модульное программирование (вышедшее из модульного проектирования) как механизм разбиения большого на малое и как средство конкретизации функциональности (с целью последующего обобщения) обладает наибольшей устойчивостью и гибкостью для подобных целей. ОО-проектирование (как механизм обобщения для последующей конкретизации) хорошо себя зарекомендовало в тех областях, где нет белых пятен и где фундамент можно строить надолго. Но таких сфер гораздо меньше, чем мы думаем. Сочетание достоинств этих подходов, а также функционального и сценарного программирования вместо нынешней диктатуры ООП – вот путь, по которому мы планируем идти.

В рамках проекта "Роса" мы подошли к идее создания полноценной собственной методологии разработки сложных программных систем, которая позволила бы вобрать в себя целый комплекс вопросов построения/конструирования систем в условиях промышленного разделения труда с сохранением гибкости и свободы для работы распределённых коллективов, вовлечённых в движение Open Source. Причём идя не по пути усложнения и насыщения возможностями разные интерфейсы, языки и сопутствующий инструментарий, а по пути концептуальной экономии (ортогональность средств), учитывая позитивный и негативный опыт таких подходов, как IBM Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), Dynamic Systems Development Method (DSDM), Scrum, Agile Unified Process (AUP), Cleanroom Software Engineering, Modular Approach to Software Construction Operation and Test (MASCOT), а также ряда других.

Всё это подразумевает формирование своей достаточно универсальной методологии, своего инструментария, своего набора языков, своей операционной платформы. При этом нам потребуется постараться снизить порог вхождения, сделать приемлемой для нынешних разработчиков миграцию в эту методологию, а также обеспечить поддержку параллельного сосуществования хотя бы одной из трех популярных операционных платформ: POSIX (Си), Java Platform (Java), .NET/CLR (C#).

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

Думаю, здесь важно отметить некоторые предпосылки нашего проекта (далее под словом "мы" буду иметь в виду инициативную группу, включающую в себя техсовет проекта и ряд участников):

1. В настоящее время мы видим проблемы доминирования Windows-семейства и противостояния Linux. Проблемы технологические, проблемы социальные, проблемы экономические.

2. Мы имеем чёткое представление о том, что новые процессорные архитектуры не могут эффективно использоваться существующими ОС (не только Windows и Linux). Это глубинные проблемы научно-технологического характера.

3. Мы знаем, что в области работ европейской школы проф. Вирта (ETH Zurich) за три с половиной десятилетия накоплен богатый неиспользованный потенциал. Главная причина: технологический, научный и маркетинговый изоляционизм.

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

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

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

7. Мы понимаем, что приоритет технологического совершенства, создаваемого группой специалистов-единомышленников в условиях свободного творчества, требует принципиально иного подхода к работе — приоритета исследований, что отражено в нашей концепции Open Research Programming.

8. Мы ставим перед собой цель проведения НИОКР до начала производства новой ОС (где и будут формулироваться конкретные бизнес-требования к превращению полуфабриката в продукт).

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

10. В случае невозможности перехода к стадии производства продукта (из-за недостаточного ресурсного обеспечения по завершении НИОКР) мы рассматриваем вариант изготовления из полуфабриката ОС продукта, предназначенного для сферы автоматизации научных исследований в рамках финансирования по линии европейских проектов.

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

Если говорить о направленности ОС и о проработке вариантов для разных ниш (с точки зрения перенацеливания ОС), то можно отметить следующие группы (учитывающие специфику аппаратного обеспечения):
1. Встроенные ОС (Embedded OS)
2. Клиентские ОС (Desktop OS).
3. Серверные ОС (Server OS)
4. Сетевые ОС (Network OS: LAN OS, Web OS)

А также следующие направления (учитывающие специфику целевой аудитории):
1. Инструментальная ОС (Developer's OS)
2. ОС для автоматизации научных исследований (Scientific Research OS)
3. ОС для сферы образования (Education OS)
4. Офисная ОС (Office OS)
5. ОС для домашнего использования (Home OS)
6. ОС для индустрии развлечений (Entertainment OS)

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

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

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

Latest Month

Март 2009
Вс Пн Вт Ср Чт Пт Сб
1234567
891011121314
15161718192021
22232425262728
293031