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

Реймонд Эрик Стивен

3.1.5. Атрибуты файлов и структуры записи

Unix-файлы не имеют ни структур записи (record structure), ни атрибутов. В некоторых операционных системах файлы имеют связанные структуры записи; операционная система (или ее служебные библиотеки) "знает" о файлах с фиксированной длиной записи или об ограничивающем символе текстовой строки, а также о том, следует ли читать последовательность CR/LF как один логический символ.

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

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

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

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

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

3.1.6. Двоичные форматы файлов

Если в операционной системе применяются двоичные форматы для важных данных (таких как учетные записи пользователей), вполне вероятно, что традиции использования читабельных текстовых форматов для приложений не сформируются. Более подробно о том, почему данный подход является проблемным, будет сказано в главе 5. Здесь достаточно упомянуть о нескольких последствиях.

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

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

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

3.1.7. Предпочтительный стиль пользовательского интерфейса

В главе 11 подробно рассматриваются различия между интерфейсами командной строки (Command-Line Interfaces — CLI) и графическими пользовательскими интерфейсами (Graphical User Interfaces — GUI). Выбор проектировщиком операционной системы одного из этих типов в качестве обычного режима представления влияет на многие аспекты конструкции от планирования процессов и управления памятью до программных интерфейсов приложений (Application Programming Interfaces — API), предоставленных приложениям для использования.

С момента появления первых компьютеров Macintosh понадобилось достаточно много лет, чтобы специалисты убедились в том, что слабые средства GUI-интерфейса в операционной системе являются проблемой. Опыт Unix противоположен: слабые средства CLI-интерфейса представляют собой менее очевидный, но не менее серьезный недостаток.

Если в операционной системе CLI-средства являются слабыми или их вообще нет, то проявляются описанные ниже последствия.

• Никто не будет разрабатывать программы, взаимодействующие друг с другом неожиданным способом, поскольку это будет невозможно. Вывод одной программы невозможно будет использовать в качестве ввода другой.

• Удаленное системное администрирование будет слабым и трудным в использовании, и будет потреблять больше сетевых ресурсов [22] .

• Даже простые неинтерактивные программы будут нести на себе издержки графического интерфейса или замысловатого интерфейса сценариев.

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

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

22

Данная проблема весьма серьезно рассматривалась в корпорации Microsoft в ходе перестройки службы Hotmail. См. [7].

3.1.8. Предполагаемый потребитель

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

К очень важным отличительным факторам относятся клиент и сервер. "Клиент" представляет собой легковесную систему, поддерживающую только одного пользователя. Такая система способна работать на небольших машинах и предназначена для включения в случае необходимости и отключения после завершения пользователем работы. Она не имеет вытесняющей многозадачности, оптимизирована по низкой задержке и выделяет большую часть своих ресурсов для поддержки вычурных пользовательских интерфейсов. "Сервер" — тяжеловесная система, способная работать продолжительное время и оптимизированная по пропускной способности. Для поддержки множества сеансов в такой системе используется полная вытесняющая многозадачность. Первоначально все операционные системы были серверными. Идея клиентской операционной системы возникла только в конце 70-х годов прошлого века с появлением PC, недорогого аппаратного обеспечения невысокой мощности. В клиентских операционных системах основное внимание уделяется визуально привлекательному для пользователя внешнему виду, а не бесперебойной работе 24 часа в сутки 7 дней в неделю.