Искусство программирования для Unix

20.3. Проблемы в конструкции Unix

Операционная система Plan 9 'очищает' Unix, но добавляет лишь одну новую концепцию (частное пространство имен) к ее основному набору конструктивных идей. Однако есть ли серьезные проблемы в этих базовых идеях? В главе 1 рассматривалось несколько областей, в которых Unix, вероятно, можно считать неудачной. В настоящее время, когда движение в поддержку открытого исходного кода 'передало будущее' конструкции Unix обратно в руки программистов и технических специалистов, эти проблемы близки к разрешению. Ниже проблемы Unix рассматриваются снова, для того чтобы лучше понять, как Unix будет развиваться в будущем.

20.3.1. Unix-файл представляет собой только большой блок байтов

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

В более широком смысле все рассматривается как поток байтов. Даже аппаратные устройства являются потоками байтов. Данная метафора была большим успехом ранней Unix и большим преимуществом в мире, где (например) компилируемые программы не могли осуществлять вывод, который мог бы быть отправлен обратно компилятору. Из данной метафоры выросли каналы и shell- программирование.

Однако метафора байтового потока в Unix настолько существенна, что в Unix имеются проблемы при интеграции программных объектов с операциями, которые не вписываются в байтовый поток или файловый состав операций (создание, открытие, чтение, запись, удаление). Это особенно является проблемой для GUI-объектов, таких как пиктограммы, окна и 'активные' документы. Внутри классической Unix- модели мира единственный способ расширить существующую метафору байтового потока заключается в использовании вызовов ioctl, печально известных как уродливая коллекция лазеек в пространство ядра.

Приверженцы операционных систем семейства Macintosh склонны громогласно критиковать это. Они пропагандируют модель, в которой одно имя файла может иметь как 'ветвь' данных, так и 'ветвь' ресурсов. Ветвь данных соответствует байтовому потоку в Unix, а 'ветвь' ресурсов является семейством пар имя/значение. Приверженцы Unix предпочитают такие подходы, которые делают данные файла самоописательными, так чтобы фактически те же метаданные хранились внутри файла.

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

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

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

Разработчики файловой системы Xerox PARC боролись с данной проблемой в 70-х годах прошлого века. Для конструкции был характерен 'открытый сериализованный' вызов, который возвращал байтовый поток, содержащий как атрибуты, так и содержимое файла. Если вызов применялся к каталогу, то он возвращал сериализацию атрибутов каталога плюс сериализацию всех файлов, хранящихся в нем. Не заметно, чтобы этот подход когда-либо был усовершенствован.

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

20.3.2. Слабая поддержка GUI-интерфейсов в Unix

Опыт Unix доказывает, что использование нескольких метафор в качестве базиса для интегрирующей структуры представляет собой мощную стратегию (обсуждение интегрирующих структур и общего контекста приведено в главе 13). Визуальная метафора 'в сердце' современных GUI-интерфейсов (файлы, представленные пиктограммами и открываемые щелчком мыши, который запускает некоторую программу, предназначенную для обработки и обычно способную создавать и редактировать данные файлы) с момента ее разработки в Xerox PARC в 1970-х годах доказала свою способность успешно и долговременно удерживать пользователей и разработчиков интерфейсов.

Несмотря на значительные недавние усилия, в 2003 году Unix все еще поддерживала эту метафору слабо и неохотно — существовало множество уровней, несколько соглашений и только слабые конструкционные утилиты. Типичная реакция со стороны опытных профессионалов Unix — подозревать, что это отражает более глубокие проблемы с самой GUI-метафорой.

Я думаю, что часть проблемы заключается в том, что мы до сих пор не имеем правильной метафоры. Например, в Macintosh, для того чтобы удалить файл, я перетаскиваю его в корзину, но когда я перетаскиваю его на диск, то файл копируется, кроме того, я не могу перетащить файл на пиктограмму принтера, для того чтобы распечатать его, потому что для этого используется меню. Я мог бы продолжать. Это похоже на файлы в OS/360, до того как появилась Unix с ее простой (но не слишком простой) файловой идеей.

Стив Джонсон.

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

Вероятно, нет. Авторы касались данной проблемы, анализируя, является ли модель представления файлов в виде большого блока байтов адекватной. Для более развитой поддержки GUI-интерфейсов механизм мог бы быть предоставлен файловыми атрибутами в стиле Macintosh. Однако кажется маловероятным, что такой подход полностью разрешит проблему. Объектная модель в Unix не включает в себя верных фундаментальных конструкций. Необходимо определить, какой в действительности была бы строгая интегрирующая структура для GUI интерфейсов. И, что не менее важно, как ее можно интегрировать с существующими структурами Unix. Это сложная проблема, требующая фундаментального