Plan B

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

Все это, собственно, сказано для объяснения следующего утверждения: даже если некоторая разработка заслуженно награждается титулами "красивая", "изящная" и "концептуально стройная", это никоим образом не означает, что все остальное, создаваемое и используемое десятилетиями, не такое "красивое" и "стройное", пора отправлять на свалку истории. Инженерная практика (иными словами -- столкновение совершенного артефакта со столь несовершенными людьми) превращает многие разработки, интеллектуальная изысканность и математически чистая безупречность которых очевидны, в нечто экзотическое и маловостребованное. Именно так было, например, с замечательными аппаратными Lisp-машинами, с близкими к ним FORTH-машинами, с операционными системами Plan 9 и Inferno. Так что, предваряя дальнейший разговор, сразу скажем: Plan B -- операционная система, без сомнения, красивая, изящная и интересная, и хотя бы поэтому она заслуживает внимания. Что, впрочем, вовсе не означает, что завтра ключевые идеи (такие красивые) этой системы станут править миром ОС. Больше того, завтра о них могут и не вспомнить, потому что... (см. второе предложение этого вводного абзаца).

Скажи файлам "нет"!

Операционная система, в которой нет святая святых -- файлов. Это -- действительно, что-то новенькое. Тем более новенькое, если учесть, что на сегодняшний день ОС Plan B существует не как самостоятельная система, а в виде надстройки над... Plan 9. О последней -- экзотической наследнице идей Unix, мы уже некогда говорили ("Компьютерное Обозрение", # 26, 2000). И в том давнишнем разговоре неоднократно упоминали об одной из главных особенностей Plan 9 -- о доведении концепции "файла" в этой ОС до практически главной системообразующей (по сравнению, например, с ОС Unix). И вот кто-то сподобился написать для "идеально-файловой ОС" Plan 9 почти 10 тысяч строк кода только для того, чтобы превратить ее в Plan B -- систему вообще без файлов.

Когда мы обсуждали Plan 9, обойтись без упоминания забавной истории происхождения названия было просто невозможно. И в этом случае, похоже, такая предыстория имеет вполне самостоятельную ценность. Plan B в некотором роде является органичным продолжением (в литературной форме) блестящего культового кича -- фильма "Plan 9" -- это шестая по счету книга дуэта Шэрон Ли и Стива Миллера. Весь сериал состоит из "...пальбы, погонь, эксцентричных диалогов и страстных поцелуев между пальбой и погонями. И еще в ней полно гигантских черепах" (автор позволил себе почти дословный перевод удачного краткого обзора Кристины Шульман). Справедливости ради стоит заметить, что задолго до вышедшей в свет в 1999 г. "Plan B" Ли и Миллера была еще очень сложная (и по-своему мрачно-пророческая) книга "Plan B" одного из самых агрессивных аме-риканских социальных фантастов Честера Хаймеса. Но это слишком серьезная для продолжения традиций Plan 9 вещь. Ну и чтобы расставить все точки над "i", -- существует и третий литературный вариант "Plan B" -- "блогроман" (именно на таком новоязе это звучит), о котором сам автор говорит, что его произведение является писательским экспериментом.

Итак, вернемся к программному варианту Plan B. Основа основ данной системы, отличающая ее от других ОС, -- замена абстракции "файл" на новую абстракцию -- "ящик" (box). По большому счету, название абстракции выбрано в полном соответствии с принятой в семействе ОС Plan традицией. А именно, неудачно. Если исторически-кабинетное значение слова "file" -- папка -- как бы подчеркивает, что объекты-папки могут быть открытыми или закрытыми, из них можно читать информацию и заносить в них данные, то безликий "ящик" ничем особым не выделяется. Хотя бы потому, что интуитивно подразумевает наличие крышки -- т. е. так же, как и файл, может быть открытым или закрытым. И здесь интуиция (и аналогии, найденные с помощью словарей) дают сбой... "ящики" Plan B, в отличие от файлов любой традиционной ОС (даже такой экстравагантной, как Plan 9), не имеют такого фундаментального состояния -- как быть закрытым. "Ящики" всегда открыты. Соответственно, и в перечне базовых системных вызовов ОС Plan B не стоит искать аналоги хорошо известным операциям "Открыть файл" и "Закрыть файл". Более того, новая концепция позволяет создать полноценную сетецентричную ОС (в этом аналогичную Plan 9), ядро которой реализует всего 14 системных вызовов!

Пожалуй, наиболее интересна в "ящиках" Plan B даже не реализация (которой ввиду очевидных причин мы касаться не будем, отметим только, что до Plan B были разработки, ставившие своей целью создание подобных механизмов, -- правда, на уровне библиотек, функционирующих в традиционных ОС; желающие могут обратиться, например, к опыту проекта Khazana, www.cs.utah.edu/khazana/), а мотивация создателей системы, заметивших серьезную проблему в изысканных красотах концептуальной стройности ОС Plan 9 и схожих сетецентричных систем. И, что удивительно, проблему эту раньше не замечали, хотя лежит она на поверхности. Давайте на секунду вернемся к знакомству с Plan 9 и вспомним, что это распределенная ОС, требующая для полноценного развертывания как минимум трех выделенных компьютеров -- файлового сервера, "сервера ресурсов процессора" или сервера приложений (сервер CPU в терминах Plan 9) и, наконец, терминала, обладающего собственной вычислительной мощностью. В идеале, сетецентрическая картина масштабной сети Plan 9 выглядит так: несколько ферм файловых серверов и их разновидности -- серверов периферии (в Plan 9 абсолютно все -- файлы), а также серверов CPU. К этому виртуальному компьютеру подключаются терминалы Plan 9, позволяющие утилизировать возможности всей системы в целом, используя при этом минимум абстракций -- понятия пространства имен и файла, операции открытия--закрытия и чтения--записи файлов. И все было бы красиво, если бы не одно маленькое "но" -- в Plan 9, равно как и в более традиционных системах (например, на основе сетевой файловой NFS), при копировании одного удаленного файла в другой, расположенный на том же сервере, катастрофически неэффективно задействуется полоса пропускания сети -- в этом случае данные файла дважды (!) передаются по сети. А если учесть, что в сетецентричных системах все файлы пользователей размещены исключительно на удаленных серверах, и принять во внимание реалии сегодняшнего дня (как то: рост объемов медиаданных и рабочих файлов сложных программных пакетов), то требования к полосе пропускания сети могут легко оказаться за пределами разумного. До появления общесистемной концепции "ящиков" выходов из сложившейся ситуации было, по сути, два. Первый -- отказаться от идеально сетецентрической архитектуры системы в пользу неизящной, более сложной в реализации, но уверенно работающей в условиях сегодняшнего дня традиционной клиент-серверной архитектуры. И пока с данного пути никто в мире не свернул (если бы это было не так, мы бы все уже работали за терминалами Plan 9). Второй -- отказаться от сложных программных пакетов, мультимедийных данных DVD- и пост-DVD-качества и прочих удовольствий компьютерной эпохи в пользу изящности архитектуры информационной системы. А вот этим путем устремиться в будущее, похоже, никто в мире не собирается. Соответственно, и светлого будущего у простых и элегантных сетецентричных систем тоже особо не наблюдается -- доведенные до вполне работоспособного, практически коммерческого состояния Plan 9 и ее наследница Inferno в массовом компьютинге остаются разве что забавными игрушками для маргиналов. Разработчики Plan B, по-видимому, решили устранить этот главный недостаток радикальным изменением концепции. Впрочем, давайте послушаем самих авторов -- Франциско Баллестероса и иже с ним (Мадридский университет Хуана Карлоса): "Для того чтобы пояснить мотивацию создания новой операционной системы, представим себе, что мы впервые используем наш портативный компьютер в таком окружении, где можно задавать команды типа "Скопировать файл в принтер" (не конкретизируя, в какой именно принтер. -- Прим. автора), -- и пусть система сама определит, есть ли в комнате, где мы находимся, принтер или несколько принтеров, подходит ли формат файла для выдачи на печать, если не подходит -- имеется ли где-то в сети программа конвертации в нужный формат, затем отыскивает эту программу, автоматически производит преобразование файла, передает результат принтеру и, наконец, возвращает на наш компьютер сообщение о готовности распечатанного документа. Сегодня мы располагаем технологиями, позволяющими упрятать все эти операции за одной командой, например: cp /путь/имя_файла /any/printer". В общем, мотивация более чем серьезная, и это действительно что-то новое: естественно, принципиально возможно "нагородить" такой командный интерпретатор и так организовать сервисы в локальной сети, чтобы приведенную команду можно было выполнить на какой-либо традиционной ОС, но это будет, мягко говоря, очень некрасивое решение.

Куда красивее и изящнее создать новую ОС, придерживаясь единого дизайна, в основе которого лежат несколько главных архитектурных правил: все ресурсы в системе представлены "ящиками", адресуемыми с помощью имен (а не дескрипторов), доступ к удаленным и локальным ресурсам осуществляется посредством единого протокола. Теперь можно и уточнить понятие "ящика" -- это характеризующийся именем всегда открытый (готовый к использованию) ресурс, содержащий некоторые данные. Каждый "ящик" имеет тип, может содержать вложенные "ящики" или быть вложенным в другие "ящики", и, наконец, перечень операций с ним предельно краток -- его можно создавать (make), копировать (copy), разделять (share) и выбирать из него вложенные "ящики" (select). Лучше всего это объяснить на следующем элементарном примере -- запуска приложения. Учитывая, что в Plan B все ресурсы -- "ящики", данная процедура несколько отличается от того, к чему мы привыкли в традиционных системах (далее используется более понятный псевдокод, а не реальные команды и пространства имен Plan B):

make  /processes/new_app

      copy /applications/my_app /processes/new_app/appcode

В первой строке примера в "ящике" процессов создается новый "ящик" new_app, т. е. готовятся ресурсы для выполнения нового приложения. Во второй строке бинарный код задачи my_app копируется из "ящика" my_app (который сам находится в "ящике" applications) в "ящик" кода, упрятанный в "ящик" new_app. Естественно, все эти сложности скрываются командным интерпретатором Plan B от пользователя, но и подобный подход в системе всегда допустим.

Типизация "ящиков" означает, что ОС может строго контролировать все операции над ними, а ассоциированная с типом "ящика" система ограничений (constraints) определяет перечень свойств "ящика", которые влияют на (или зависят от) этих операций.

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

Естественно, во всем изяществе концепции "ящиков" есть изъян, в чем-то сходный с неэффективным использованием полосы пропускания сети при операциях с удаленными ресурсами в ОС Plan 9. Раз "ящики" всегда открыты (по аналогии с файлами) и называются именами, то перед каждой операцией с ними требуется выполнение разрешения их имен. А раз в Plan B все ресурсы -- "ящики", следовательно, их в реальной системе будет очень много (это еще мягко сказано). Соответственно, процедура разрешения имен ресурсов может стать (и наверняка станет в реальности) главной проблемой систем Plan B.

И перспективы...

Состояние проекта Plan B на сегодняшний день можно оценивать по посещению сайта b.lsub.org -- если он "откликается", значит, сервер под управлением Plan B работает (за время написания этой статьи, к сожалению, работоспособное состояние сервера не наблюдалось ни разу). Девять тысяч строк С-кода -- надстройка, трансформирующая Plan 9 в Plan B -- можно получить, запросив их у авторов.

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365