`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

В дебрях каталогов, или Какой будет файловая система будущего

0 
 

Что важнее: предмет или его название? А как вы относитесь к утверждению "как вы судно назовете, так оно и поплывет"? Ответ кажется очевидным, но не стоит торопиться с выводами. Если оставить мистические соображения колдунам, то выходит, что имя не имеет большого значения в жизни. Впрочем, иногда эта невинная последовательность символов, ярлык по сути, становится критически важным элементом.
My name is...

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

В течение двух десятилетий мы привыкали структурировать собранную информацию согласно правилам именования каталогов и файлов. Пользователи ПК давно научились втискивать все сведения о документе в заветные 8 символов, избегать использования "непечатных" знаков, сравнивать каталоги, искать по шаблону. Но, даже не вдаваясь в частности, можно смело сказать, что большинство нынешних файловых систем никуда не годятся. Критерием служит тот факт, что разработчики буквально каждого приложения вынуждены изобретать свой, оригинальный способ упорядочения информации. По мнению же Ганса Райзера (Hans Reiser), появление дополнительного слоя над файловой системой ОС однозначно свидетельствует о неудачной ее конструкции. Причина -- в пассивности нового поколения программистов. Как писал Ганс, однажды ему пришлось стать свидетелем перепалки между сотрудниками одной софтверной корпорации -- разработчиками приложений и разработчиками файловой системы. Последние аргументировали нежелание усовершенствовать убогий плод труда своего в крайне циничной форме. Они заявили, что винчестеры нынче дешевые, требуемая от них поддержка малых объектов на самом деле не имеет большого значения, да и формат диска не менялся уже 10 лет, поэтому в данный момент никто не собирается его перерабатывать.

Может, кто-то и согласен с таким видением проблемы, но только не Райзер -- основатель компании NameSys, идеолог знаменитой ReiserFS (где FS -- сокращение от File System), www.namesys.com/content_table.html. "Полезность подсистемы увеличивается пропорционально количеству других подсистем, с которыми она может взаимодействовать", -- гласит "Системная научная гипотеза # 1" Ганса Райзера.

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


Высекать, а не лепить

Ганс Райзер не только ропщет, но и предлагает решение проблемы в своей статье "Future Vision". Новая система именования, призванная освободить нас от "гнета" Unix-подобной файловой системы, является неким гибридом традиционного иерархического подхода и методики ключевых слов. Склонность Райзера к сложным структурам выдают некоторые предложения в его статье, иногда состоящие более чем из 60 слов. Впрочем, архитектуру своего проекта он старается сохранять максимально простой. Девиз разработки -- "система имен должна отражать, а не формировать структуру", а цель -- объединить в едином адресном пространстве все виды данных, сделать их более доступными как для пользователя, так и для приложений. Очевидную привлекательность идеи подчеркивает то, что знания, по определению, являются плодом ассоциаций, логических связей между понятиями. Введя же однородное пространство имен, мы привнесем в разрозненную массу файлов некоторый смысл.

В основу своей концепции Райзер положил ключевые слова. Получается нечто вроде длинного имени файла, построенного по определенным семантическим правилам, но не являющегося, конечно, единственным способом идентификации объекта. Ключевые слова представляют собой неупорядоченный набор терминов, характеризующих содержимое объекта. Пример жизнеспособности такой методики дают нам поисковые службы в Internet, отлично справляющиеся с гетерогенной средой WWW. Райзер приводит и конкретный пример с воображаемыми системами REGRES и ANARCHY. Первая способна принять 15 ключевых слов, вторая -- только 10. Но если REGRES требует, чтобы каждое из них было на "своем месте", т. е. относилось к определенной графе, то ANARCHY хранит все ключевые слова вместе. Так вот, во втором случае, несмотря на меньшее количество поисковых терминов, вероятность найти документ с помощью набора произвольных ключевых слов на порядок выше.

Доказывая преимущество своего подхода, Райзер не отказывается и от некоторых элементов иерархии. Определенную дисциплину привносят операции группировки и упорядочения. Группа -- это набор ключевых слов, представляющих множество взаимосвязанных терминов. Вот хороший пример группирования, подтверждающий необходимость определенного упорядочения: "[обезьяна теория Дарвина банан дерево лазить живет Африка]". Искомый документ появится в результатах после запроса как "[обезьяна теория банан дерево лазить]", так и "[Африка Дарвина]". Поэтому, если речь идет о роли обезьяны в теории Дарвина, более корректно было бы связать вместе такие понятия: "[[теория --> Дарвина] обезьяна [лазить --> дерево] [живет --> Африка]]".

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

Объекты в иерархии выполняют еще одну роль, которая заключается в том, что каталоги-фильтры и каталоги-модули предоставляют услуги обработки информации. Вообще излюбленный прием Райзера -- проведение параллелей между парой связанных терминов и вызовом функции в языке программирования (первое ключевое слово является именем функции, а второе -- передаваемым ей аргументом). Например, документ, "отправленный" в каталог "[архивация]", будет автоматически упакован встроенным (plug-in) в систему модулем. Программные фильтры также помогут приложениям найти "общий язык", даже если их внутренние форматы хранения данных существенно различаются. И наконец, поиск в иерархической структуре, хотя и сложен, но эффективен, а поддержка подобного "архаизма" позволит сохранить совместимость с традиционными файловыми системами, что чрезвычайно важно.


Мелочи решают все

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

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

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

В 1984 и 1985 гг. две группы исследователей (J. M. Smith, D. C. Smith и Potter, Walter, Robert P. Trueblood) опубликовали материалы, являющиеся основой того, что сегодня называют гиперсемантической системой (hypersemantic system). В ней каждое понятие "раскладывается" в набор полей-элементов, характеризующих главные его составляющие. Получается нечто вроде универсальной лингвистической "системы координат". Звучит заманчиво, но пока никто еще не сумел определить полный набор координат для такого пространства. Вышеупомянутые ученые попробовали использовать вариант разложения:

"является" (is-a)
"имеет свойство" (has-property)
"представляет собой" (is-an-instance-of)
"принадлежит множеству" (is-a-member-of)

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

И все же некоторые специалисты свято верят в реальность конструирования общей системы отсчета. Среди них Рич Килмер (Rich Kilmer), основатель компании Roku Technologies, занимавшийся разработкой системы менеджмента гетерогенного контента Roku Platform. Информация в систему поступает из различных источников, упорядочивается, классифицируется, а затем избирательно рассылается клиентам в зависимости от типа приемного терминала и опций подписки. Компания разорилась, однако идеи ее живут. Килмер предлагает в качестве координат набор полей:

"Кто" (люди, организации и т. д.)
"Что" (документы, Web-страницы, файлы)
"Когда" (календарные элементы)
"Где" (адресные книги, избранные ссылки)
"Почему" (действия, проекты, задачи, цели)
"Как" (ресурсы, оборудование, ПО, интерфейсы и т. д.)

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


У них есть Plan

Да еще какой! Гениально простой и оригинальный Plan под номером 9. И предложили его еще в 1992 г. исследователи из Bell Labs. Работая над этой операционной системой, они воплотили в жизнь лозунг: "Мы говорим -- операционная система, подразумеваем -- файловая система, говорим -- файловая система...".

Разработка Bell Labs не исчерпывает темы единого пространства имен, но демонстрирует потенциальные возможности, которые раскроются перед нами в "конце пути". Была реализована лишь вторая часть концепции, изложенной Райзером, а именно -- файловая система как единая среда коммуникаций. Основная идея заключается в использовании стандартных файловых структур для реализации программных интерфейсов. Аналогичные механизмы существовали даже в DOS, где некоторые устройства (модем, принтер, клавиатура) представлены в системе стандартными файлами (COM:, PRN:, CON:).

Идеологи Bell Labs пошли значительно дальше -- любые сервисы, любые устройства, подключенные к системе, являются обычными каталогами и файлами, например /dev/mouse, /dev/screen, /dev/cons. Каждый запущенный процесс тоже не более чем каталог (/proc/new), наполненный файлами-объектами, символизирующими различные его аспекты. Так, доступ к виртуальной памяти процесса осуществляется посредством записи и чтения из файла /proc/new/mem, а завершить его можно выполнением операции write "kill' в файл управляющего интерфейса /proc/new/ctl. Более того, при запуске каждый процесс получает в свое распоряжение все устройства и сервисы операционной системы. Делается это путем копирования в главный каталог процесса файловой структуры соответствующей службы. К примеру, оконная система, называющаяся 81/2 , в Plan 9 представлена каталогом /dev/cons, поэтому после инициализации поддержки оконной графики для процесса new будет создан каталог /proc/new/dev/cons.

Простая в общем-то концепция дает много интересных и неожиданных эффектов. Локальные особенности нивелируются глобальными правилами. Любая программа-сценарий, запущенная в любой среде, независимо от архитектуры конкретной машины, может быть уверена, что доступ к оконному интерфейсу располагается в /dev/cons, к мышке -- в /dev/mouse, а состояние виртуальной памяти отражает файл mem. Еще проще оказывается менеджмент нескольких версий инструментальных библиотек. Процесс, столь мучительный для пользователей Windows, реализуется одной командой -- bind, позволяющей заменить отдельную ветвь дерева каталогов на другую.

Столь же легок доступ и к удаленным ресурсам. Если сетевой компьютер поддерживает протокол запросов к файлам 9P (кстати, очень простой -- всего 17 команд), то другая система под управлением Plan 9 сумеет не только напрямую поработать с его винчестером или принтером, но и воспользоваться его стеком сетевых протоколов. Любой ресурс, представленный в виде иерархической структуры каталогов в формате этой ОС, присоединяется к файловой системе вашего компьютера командой import. Например, команда "import URAN /proc' позволит манипулировать процессами на удаленной машине URAN, запускать там новые приложения, обмениваться с ними данными и даже контролировать содержимое их виртуальной памяти. А так как сетевой интерфейс также является файлом, то и подключиться к нему можно командой "import URAN /net', а затем уже работать с файлами конкретных протоколов (например, "/net/tcp', "/net/udp/') так, словно они расположены в локальной системе.

Plan 9 -- своеобразный манифест, призванный доказать на практике справедливость основной идеи авторов этой уникальной ОС. Высказана она была в статье "The Hideous Name", смысл ее ясен и очевиден: различная семантика -- это не повод для использования различного синтаксиса. По их мнению, фрагментирование пространства имен не оправдывается специфическими требованиями приложений. Однако, к сожалению, созданная операционная система не может служить подлинным образцом реализации концепции единого пространства имен. Многие вещи не удалось довести до логического конца. Так, операции создания процесса и управления разделенными (shared) фрагментами памяти основываются исключительно на вызовах системных процедур. В иерархическое пространство имен не вписались и разнообразные сетевые схемы адресации.

Впрочем, помимо Bell Labs, существуют и другие коллективы, которые, действуя различными способами и преследуя различные цели, смогли приблизиться к заветной мечте Ганса Райзера. Удивителен пример OS/400 -- коммерческой системы-долгожителя. Ее пользователям есть чем гордиться: их операционная система -- одна из немногих обладательниц практически завершенного унифицированного пространства имен.

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

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

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT