Искусство программирования для Unix
Шрифт:
Это изменение позволяет отказаться от экономии дискового пространства, а взамен получить более простой и прозрачный код, т.е. изменяется соотношение понижающейся стоимости памяти и стоимости времени программиста. Множество отличий между конструкциями старой школы Unix в 70-х и 80-х годах прошлого века и конструкциями новой школы после 1990 года можно связать с огромным сдвигом в относительной стоимости. В результате этого сдвига в настоящее время все аппаратные ресурсы становятся на несколько порядков дешевле по отношению к времени программиста, чем это было в 1969 году.
Оглядываясь назад, можно установить три специфических технологических изменения, которые повлекли
В главе 2 описана первая из этих перемен: возникновение межсетевого обмена с точки зрения истории культуры. В главе 2 рассказывается, как протокол TCP/IP связал в одно целое исходную культуру Unix и культуру сети ARPANET после 1980 года. В главе 7 материал, описывающий устаревшие методы IPC и сетевые методы, такие как System V STREAMS, указывает на то, как много было заблуждений, оплошностей и тупиковых ветвей, которые захватывали Unix-разработчиков большую часть последующего десятилетия. Было много путаницы, связанной с протоколами [148] , сетевым взаимодействием машин и взаимным обменом данными между процессами на одной машине.
148
В течение нескольких лет казалось, что семиуровневый стандарт ISO может успешно конкурировать с набором протоколов TCP/IP. Он продвигался Европейским комитетом стандартов, напуганным мыслью о заимствовании любой технологии, рожденной в недрах Пентагона. Увы, их негодование превысило остроту их технического зрения. Результат оказался чрезмерно сложным и напрасным. Более подробно эта тема описана в книге [60].
В конце концов, путаница исчезла, когда протокол TCP/IP победил, и BSD-сокеты заново утвердили важнейшую метафору Unix: "Все является потоком байтов". Стало нормой использовать BSD-сокеты как для IPC, так и для сетевого взаимодействия. Более ранние методы в обеих областях почти совершенно вышли из употребления, и программное обеспечение Unix развивалось все более индифферентно относительно того, расположены ли обменивающиеся данными компоненты на одной машине или на разных машинах. Логическим результатом этого было создание World Wide Web в 1990–1991 годах.
Когда в 1984 году через несколько лет после TCP IP появилась растровая графика и пример Macintosh, возникла еще более сложная проблема. Исходные GUI-интерфейсы от Xerox PARK и Apple были замечательными, однако они связывали вместе слишком много уровней системы для того, чтобы Unix программисты чувствовали себя комфортно с такой конструкцией. Немедленным ответом Unix-программистов стал явный принцип отделения политики от механизма. Система X Window была представлена к 1988 году. Они отделили наборы полезных компонентов X от диспетчера дисплея, который выполнял низкоуровневую обработку графики. Благодаря этому была создана архитектура,
Однако это была простая часть проблемы. Сложной ее частью было решение — должна ли вообще Unix иметь унифицированную политику интерфейса, и если да, то какой она должна быть. Несколько различных попыток представить ее посредством частных инструментальных наборов (таких как Motif) провалились. В настоящее время в этой области конкурируют инструментарии GTK и Qt. Несмотря на то, что дебаты по этому вопросу не прекратились, постоянство различных стилей пользовательского интерфейса, рассмотренных в главе 11, впечатляет. Unix-проектирование новой школы сохранило командную строку и справилось с напряжением между подходами GUI и CLI благодаря связыванию большого количества пар CLI-ядро/GUI-интерфейс, которые могут использоваться в обоих стилях.
Как технология, персональный компьютер представил несколько главных проблем проектирования. Процессоры 386-й серии и более поздние версии были достаточно мощными для того, чтобы предоставить системам, разработанным на их основе, соотношение затрат, подобное соотношению, характерному для мини-компьютеров, рабочих станций и серверов, на которых сформировалась операционная система Unix. Истинной трудностью было изменение потенциального рынка для Unix- систем; более низкая общая стоимость аппаратного обеспечения сделала персональные компьютеры привлекательными для чрезвычайно широкой и менее технически искушенной категории пользователей.
Поставщики частных Unix-систем, привыкшие к большей прибыли от продажи более мощных систем опытным покупателям, никогда не интересовались этим рынком. Первые серьезные инициативы по направлению к настольным системам конечных пользователей исходили от сообщества открытого исходного кода и были восприняты в основном по идеологическим причинам. Согласно аналитическим исследованиям рынка, по состоянию на середину 2003 года операционная система Linux заняла около 4-5% этого рынка, что вполне сопоставимо с объемами Apple Macintosh.
Независимо от того покажет ли Linux когда-либо более высокие результаты, ответ Unix-сообщества уже ясен. Об этом уже говорилось в главе 3, при рассмотрении вопроса о заимствовании нескольких технологий (таких как XML) из других систем и натурализации GUI-интерфейсов в Unix-мире. Однако основное внимание все-таки уделяется модульности и четкому коду — созданию инфраструктуры для серьезных высоконадежных вычислений и коммуникаций.
Этот акцент подтверждается историей крупномасштабных проектов, подобных Mozilla и OpenOffice.org, которые стартовали в конце 90-х годов. В обоих указанных случаях наиболее важной темой в отклике сообщества было отнюдь не требование новых функций или соблюдение сроков поставки. Главной идеей в сообществе была неприязнь к гигантским монолитам и общее понимание того, что прежде чем эти большие программы перестанут быть препятствием, их придется облегчить, подвергнуть рефакторингу и разделить на модули.
Вопреки большому числу инноваций, сопутствовавших данным технологиям, отклики на все эти три технологии были консервативными относительно фундаментальных правил Unix-проектирования — модульности, прозрачности, отделения политики от механизма и других качеств, которые рассматривались ранее в настоящей книге. Мудрым решением Unix-программистов было возвращение к первоначальным принципам, т.е. попытке получить больший выигрыш преимущественно из основных абстракций Unix — потоков, пространства имен и процессов, а не из иерархии новых абстракций.