Не мучая читателя загадками, сразу сообщим — речь пойдет
о "еще одной ОС". Но… лето, жара и утомительные подробности организации
такого сложного комплекса программ, как ОС, не слишком хорошо совместимы.
Конечно, минимального перечня необходимых технических сведений нам не избежать.
И все-таки попробуем разрушить стереотип "представления" операционной
системы и сконцентрироваться на вещах весьма далеких от техники, но исключительно
важных. Важных хотя бы потому, что кризис системного программного обеспечения
— явление практически очевидное и, что не менее очевидно, затрагивающее в первую
очередь "третьи" страны, фактически не имеющие ни собственной масштабной
индустрии разработки (предложения), ни сформированного рынка потребления ПО.
Ситуация
Рассказ о "еще одной ОС" в отрыве от контекста, характеризующего современную
ситуацию, сложившуюся с системным ПО по тем или иным причинам (обсуждения которых
мы даже не будем касаться), превращается просто в весьма специфический набор
сведений. И, что главное, — вне поля зрения остается ответ на жизненно важный
для национальной информационной инфраструктуры (которую, уважаемые читатели,
все мы и составляем) вопрос: "А почему, собственно, столь специализированный
класс ПО так важен?".
Намеки на ответ на этот вопрос можно найти, например, в ставшей уже канонической
статье Р.Пайка (талантливого программиста и системного архитектора, одного из
ведущих разработчиков ОС Plan 9, исследователя легендарной Bell Labs), посвященной
кризису системного ПО. Эта статья вскрывает симптомы, подтверждающие сам факт
существования кризиса. Резкое сокращение количества финансируемых проектов,
направленных на создание концепций, архитектур и даже комплексов требований
к новым операционным системам, неожиданный спад интереса к инструментальным
средствам — вот только два главных симптома, выявленных Р. Пайком. И действительно,
в период "дорогих и несовершенных вычислений", когда, казалось бы,
недоступность техники и информации выступали сдерживающим фактором, и новые
операционные системы, и языки программирования, и сложные инструментальные системы
возникали с астрономической скоростью. С не менее астрономической скоростью
они и исчезали, но… Технология объектно-ориентированного проектирования и
программирования была фактически предопределена языками Simula 67 (обратите
внимание на цифру — это год!) и Smalltalc. А техника (аппаратные и программные
средства) растровой и векторной графики, разнообразные СУБД, теория и практика
мультипроцессорной обработки, архитектура файловых систем и ОС — это даже не
претендующий на обзорный характер перечень "заготовок", оставленных
в наследие компьютерной наукой фактически 30—40-летней давности. Впрочем, здесь
особых доказательств и не требуется: сегодня появление нового более или менее
пригодного к массовому использованию языка программирования — событие (вспомним
истории Java и C#), основные инструменты разработчиков — языки C и Pascal —
не блещут разнообразием ни реализаций, ни модернизаций, множество массово используемых
операционных систем фактически сократилось до двух, идеи интерактивного взаимодействия
человека и компьютера шатко балансируют между почему-то считающимися ортогональными
концепциями CLI (Command Line Interface — интерфейс командной строки) и GUI.
Приведенные факты — не выдумка, и с ними трудно не согласиться, да и не заметить
их тоже непросто. Но вот почему это плохо, и плохо именно для "третьих"
стран (хотя и не только для "третьих") — вопрос куда более интересный
и настолько важный, что ему следует посвятить отдельный раздел.
Привычки и… последствия
 |
| Способность GUI AtheOS к изменению вида интерфейсов (темы) не является врожденной, но уже реализована |
Культура потребления программ — несомненно существующее,
но никем и никак не определенное понятие. Крайне непродолжительный (по меркам
истории человеческого общества) период существования доступных (массовых) компьютеров
и программ пока сформировал единственную концепцию, которая неформально (но
массово) именуется "доступной беспроблемной универсальностью и интуитивностью"
(ДБУИ). Но программы — не только продукт для конечных потребителей, они жизненно
важны и для создателей новых программных продуктов, положение которых в странах
с неразвитой информационной инфраструктурой оставляет желать лучшего. Учитывая
этот очевидный факт, столь привлекательная на первый взгляд "доступная
беспроблемная универсальность и интуитивность" может превратиться в опасное
рыночное оружие. Давайте на секунду задумаемся…
Доступность программ — это, несомненно, замечательно. Как несомненно и то,
что наличие обширного спектра доступных импортных программ на рынках "третьих"
стран вынуждает национальных производителей ПО вступать в конкурентную борьбу
за свой собственный рынок. Столь модный сегодня универсальный характер программ
серьезно усложняет условия этой борьбы: универсальность — одновременно и мощное
рекламное оружие, способствующее лучшему сбыту товара (простая логика: "больше
функций — лучше"), и радикальное средство "усложнения жизни"
конкурентам, ведь универсальность и сложность — синонимы. Интуитивность —
термин весьма сомнительный (в конце концов, интуиция — не врожденная способность
человека, она формируется десятилетиями), но под его сомнительностью подразумевается
высокий уровень затрат не столько на достижение удобств, сколько на формирование
привычек и поддержание "привычности среды" (автор понимает, что эти
термины слишком "скользкие", но все же надеется на взаимопонимание
со стороны читателя). И наконец, "четвертый элемент" — беспроблемность.
Это тоже далеко не дешевое удовольствие, тем более при условии наращивания универсальности.
Ведь достижение беспроблемности требует очень высоких затрат на высокоуровневое
проектирование, процесс производства, тестирование, экспертные оценки…
А теперь давайте попробуем сопоставить очевидный факт кризиса в области системного
и инструментального ПО с приведенными соображениями. Само сопоставление и (достаточно
очевидные) выводы автор оставляет читателю, даже не пытаясь навязать свою точку
зрения. В контексте же статьи нас волнуют ответы на следующие вопросы:
- Велики ли шансы национального производителя ПО страны
с неразвитой информационной инфраструктурой в конкурентной борьбе за внутренний
рынок ДБУИ ПО? - Какие признаки негативного ответа на вопрос # 1 могут
свидетельствовать о правильности всех наших предположений, сколь бы неприятны
они не были?
Здесь следует начать… с возможных ответов на второй вопрос
— попытаться решить задачу "методом от обратного". В инженерии вообще,
и в программной инженерии в частности, есть надежно работающая примета поражения
в конкурентной борьбе. А именно, постановка задач и концентрация сил в области
уникальных разработок, наименования которых иначе как с приставкой "сверх"
не употребляются. Правило это известно специалистам по теории технических систем,
и упоминания о нем можно найти в не часто встречающихся монографиях, посвященных
этой тематике (например, в замечательной книге В. Хубки "Теория технических
систем"), а многие примеры "глобальных инженерных поражений"
стали уже каноническими. Так, Германия в конце Второй мировой войны, бесповоротно
проиграв Великое Инженерное Соревнование (техника ее противников в конце концов
оказалась и эффективнее, и технологичнее, и удобнее, и надежнее) лихорадочно
пыталась создать именно "сверхоружие" — конструкторам ставились сверхзадачи,
на решение которых отвлекались существенные ресурсы. В ходе этих "инженерных
конвульсий" появлялись настоящие шедевры (чего только стоят уникальные
германские экспериментальные подводные лодки, работающие на перекиси водорода
и достигавшие скорости современных атомоходов), но шедевры ни в войне, ни в
конкурентной борьбе "погоды" не делают…
И вот, наконец, дополняющий все эти рассуждения короткий перечень фактов —
Япония в свое время ставила сверхзадачи перед своими конструкторами (проект
"ЭВМ VI поколения"), тратила астрономические суммы на реализацию "технологического
чуда", но вовремя избежала неизбежного поражения, переориентировавшись
на решение куда более реальных задач — массовое производство малоразрядных
микропроцессоров и контроллеров, микросхем средней степени интеграции, бытовой
аппаратуры. Вспомним недавний бум с обещанным группой Бабаяна (Россия) сверхпроцессором
и вспомним фон, на котором развивалось это действо — отток громадных средств
с рынка СНГ, затрачиваемых на "совсем приземленные", но так необходимые
процессоры с невзрачными характеристиками — от 8- до 32-битовых. Это еще один
хороший пример, впрочем, как и традиционное несоответствие в решении сверхзадач
в авиастроении (сверхистребители, сверхтранспортные самолеты) и массовые закупки
"обычных аэробусов" для пассажирских авиалиний. И наконец, последний,
непосредственно относящийся к теме нашего обсуждения пример — история ОС Unix,
разработчики которой, как ни странно, никогда не ставили перед собой никаких
сверхзадач, но их детище — типичная "серенькая" по всем параметрам
(производительность, надежность, сложность…) система пережила сотни уникальных
сверхпрограмм и по сей день не имеет достойных противников в инструментальной
области.
"Момент истины" в этой статье наступил. Или почти наступил. Остался
последний штрих, завершающий картину и, увы, противоречащий выводам, сделанным
Р. Пайком в его работе (впрочем, это противоречие отражает принципиальное различие
в объекте рассмотрения — Пайка беспокоила ситуация с "системным ПО вообще"
и в академической науке в частности, нас же, по очевидным причинам, больше интересует
состояние наших рынка и жизни). Итак, невзирая на авторитеты национальным информационным
инфраструктурам сегодня нужны не уникальные проекты суперкомпьютеров и процессоров,
а добротные системные разработки-"середнячки", максимально утилизирующие
массовые доступные ресурсы мирового рынка компонентов и технологий, одновременно
сравнительно несложные, не требующие больших затрат ни на процесс создания,
ни на эксплуатацию, ни на массовое переобучение. Только при соблюдении такого
условия национальный производитель ПО способен хоть в какой-то мере начать отвоевывать
почти безвозвратно потерянный собственный рынок.
И, как оказывается, такая потребность существует не только на территории СНГ,
но и в странах куда более благополучных. Впрочем, знакомьтесь: добротная скандинавская
"серенькая системная разработка"…
AtheOS
 |
| Пересечение технологий — броузер для AtheOS наследует исходные тексты аналогичной разработки (Konqueror) из проекта KDE |
Сразу хочу оговориться — несмотря на принципиальную работоспособность,
ОС, существующая на сегодняшний день в рабочей версии 0.3.4, неподготовленному
пользователю радости не принесет. Но пока это и не важно, а вот принципиальную
работоспособность системы подтверждает факт почти 40-дневной работы без перезагрузок
(uptime) сайта, который
реализован с помощью http-сервера Apache, работающего на двухпроцессорной машине
под управлением ОС AtheOS. Уже из двух этих фактов можно сделать очень важные
выводы: устанавливать свободно распространяемую ОС AtheOS просто для того, чтобы
с ней "поиграться" нецелесообразно, зато для разработчиков эта платформа
вполне пригодна и достаточно надежна. Ну и, наконец, упомянутый факт использования
Apache — самого популярного и работающего практически во всех POSIX-совместимых
(POSIX — стандарт интерфейсов и инструментальных средств мобильной операционной
системы) ОС, подсказывает, что свойством POSIX-совместимости AtheOS также обладает,
что, несомненно, является привлекательным фактором для разработчиков.
AtheOS — операционная система относительно несложная. Хотя бы потому, что автором
архитектуры ОС, ядра, графической подсистемы и системных библиотек является…
один (!) человек. Курт Скауен (Kurt Skauen), создатель всего этого множества
программ — рядовой сотрудник крупного норвежского информационного проекта Funcom,
посвящал своему детищу свободное время без всякого стороннего финансирования
и тем самым косвенно нанес тяжелый удар по принятому в странах "третьего
мира" заблуждению, что без мощного финансирования ничего путного сделать
нельзя. Как оказывается, очень даже можно. AtheOS — система более чем неплохая
как по идеологии, так и по очень многим аспектам реализации. Но давайте по порядку.
Начнем с… цифр и эмоций. Исходные тексты ядра AtheOS содержат всего около
24 KB ассемблерных машинно-зависимых текстов, при этом "привязанность"
текущей реализации ОС к единственно поддерживаемой архитектуре x86 — минимальна.
40 файлов с исходными текстами ядра совершенно не пугают, а сами программы написаны
исключительно культурно, и, если так можно выразиться, вдребезги разбивают миф
о низких качествах языка C. Еще 10 файлов вполне приемлемого для понимания размера
реализуют ключевой элемент любой полноценной ОС — виртуальную файловую систему,
позволяющую использовать в одном сеансе работы сразу несколько накопителей (томов)
с разными файловыми системами и представляющую все это разнообразие единой иерархией
каталогов (директорий). Компактность ядра, естественно, ни в коей мере не определяет
"микроминиатюрность" всей ОС "в сборе" — дистрибутив последней
версии составляет почти 150 MB. Правда, и назвать его "голой ОС" язык
не поворачивается — система полностью пригодна к использованию в качестве рабочей
станции программиста.
Архитектурно AtheOS представляет собой очень удачную реализацию "бархатной"
революции, настолько "бархатной", что ее революционность ни к чему,
кроме удобств, не приводит. Не попадающая в класс "микроядерных" AtheOS
построена на модульном ядре — до такой степени модульном, что это уже почти
настоящее микроядро: по крайней мере, модули-серверы-драйверы можно загружать
и активировать на лету без необходимости перезагрузки ОС. Самое главное отличие
в упомянутом "почти" от микроядерных архитектур — исполнение этих,
не попадающих ни в какую классификацию, модулей в виртуальном адресном пространстве
ядра ОС (в "чистых" микроядерных архитектурах сервисные серверы —
аналоги модулей AtheOS — исполняются в виртуальном адресном пространстве непривилегированных
пользовательских процессов). Такой архитектурный нюанс весьма действенно повлиял
не только на производительность — AtheOS сохраняет высокие показатели быстродействия
при работе с большими данными, свойственные системам с монолитным ядром, и одновременно
обладает гибкостью, присущей микроядерным системам. В последних из-за необходимости
преодоления "барьера" между виртуальными адресными пространствами
(привилегированным и пользовательским) разработчики вынуждены реализовывать
"общение" между сервисными серверами и ядром с помощью достаточно
высокоуровневых протоколов обмена сообщениями фиксированного размера, что не
слишком хорошо сказывается на производительности при работе с данными характерного
для "настольных" приложений размера.
Вторая особенность архитектуры AtheOS — преобладание легковесной потоковой
модели над моделью "тяжелых" процессов. Потоки, исполняемые в одном
адресном пространстве, требуют намного меньше ресурсов при инициализации, чем
процессы, исполняемые в разных адресных пространствах — это каноническое правило
обеспечивает более высокую производительность потоковых ОС, особенно при работе
их на мультипроцессорных архитектурах. И здесь автор AtheOS приготовил небольшой
сюрприз — полноценное поточное ядро, что, без лишних технических нюансов, означает
одно — на SMP-машинах AtheOS исключительно эффективно использует возможности
аппаратуры.
Третья особенность касается организации графической подсистемы AtheOS. Она одновременно
наследует лучшие свойства классической X Window (клиент-серверная организация,
"общение" с помощью высокоуровневого протокола) и устраняет некоторые
недостатки (проявляющиеся "при массово-настольном" использовании X
Window) последней за счет очень высокого уровня обмена. В общем, пресловутая
проблема сегментации GUI, за которую ругают ОС Unix, AtheOS не грозит. С другой
же стороны, графический интерфейс AtheOS далеко не убог, и система поддерживает
массу полезных, с пользовательской точки зрения, особенностей — виртуальные
экраны с индивидуальными настройками (вплоть до разрешения), возможности переопределения
вида элементов интерфейса (темы) и т. д.
Четвертая особенность — основная файловая система (ФС). Впрочем, представлять
ее не надо — основанная на идеях книги "Practical Filesystem Design",
написанной Домиником Джиамполо (Dominic Giampolo) — автором заслуженно знаменитой
ФС ОС BeOS, ФС AtheOS также 64-разрядная, очень быстрая и надежная благодаря
журналированию транзакций (последнее означает гарантированную возможность продолжения
любой дисковой операции, прерванной, например, сбоем питания, с момента его
наступления).
Такой короткий обзорный перечень наводит на мысль о слишком большом сходстве
AtheOS и BeOS. Самого Курта Скауена неоднократно "обличали" чуть ли
не в попытке создания клона BeOS, но все подозрения были и остаются необоснованными.
В отличие от разработчиков революционного объектно-ориентированного ядра BeOS,
Скауен не стал творить революций — и замечательно. И, что главное, практические
результаты отказа от сверхзадачи подтверждают все наши прежние допущения и рассуждения:
в отличие от BeOS, поддерживающей не более 1 GB ОЗУ и не допускающей существование
более 192 потоков в одной задаче, AtheOS и в два раза увеличивает доступный
объем физической памяти, и почти в 80 (!) раз — количество потоков в задаче.
Ну а хорошие идеи (ФС) — это уже дело вкуса, пристрастий и инженерного "чутья".
Вот такой результат от попытки сделать "серенькую ОС".
С пользовательской точки зрения AtheOS очень похожа на гибрид GUI ОС Amiga с
целым букетом возможностей CLI ОС Unix. При этом никакого текстового режима
система не поддерживает (его реализации в ней просто не существует), все элементы
GUI крайне рациональны и функциональны, а классическое сочетание командного
интерпретатора bash (Baurne Again SHell) и графического эмулятора терминала
ни в чем не ограничивают профессиональных пользователей Unix и ни к чему не
обязывают "пришельцев в AtheOS" с "настольных" платформ.
Правда, и тех, и других порадует общесистемная сквозная поддержка ttf-шрифтов
и Unicode.
P. S.
История AtheOS и ее разработчика примечательна, но не исключительна. Курт Скауен,
несомненно, талантливый программист, очень работоспособный и целеустремленный
человек, но, что главное, он действительно яркий инженер. Хотя бы потому, что
поставленная им перед самим собой задача на удивление рациональна, а достигнутый
за пять лет результат — образцовый во всех отношениях. Он не добивался ни революционной
новизны, ни суперпоказателей, не объявлял священной войны кому-либо, и вообще,
он не делал ничего "сверх-". И он не просто создал Очень Хорошую и
Нужную Систему, но и подсказал перспективный путь, позволяющий разрешить массу
противоречий, о которых мы столько говорили и которые все равно остаются актуальными.
