Вопросы истории: UNIX, Linux, BSD и другие

Федорчук Алексей Викторович

Далее наступает некоторое затишье, продолжавшееся до 21 декабря 2005. Зато этот день ознаменовался выходом сразу двух версий – X11R6.9 и X11R7.0. Нет, это было не раздвоением личности, а окончательным разрывом со старыми традициями: переходом от Imake – системы автоматизации сборки, унаследованной от XFree86, к Autotools – аналогичной системе, развиваемой в рамках проекта GNU. Что вызвало и переход от монолитной сборки к модульной. В результате чего на одной кодовой базе и были созданы монолитная версия 6.9 и модульная версия 7.0. Во всех последующих релизах Xorg использовалась только система Autotools и, соответственно, все они были модульными.

Традиционно исходные коды XFree86 распространялись в виде нескольких крупных

тарбаллов (в разных версиях – от трёх до семи). Которые при монолитной системе сборки и в бинарном виде собирались как серия крупных пакетов, таких, как Xbin, Xlib, Xxserv и так далее. Разумеется, бинарники можно было собрать и более дробно, и майнтайнеры ряда дистрибутивов, таких, как RedHat и Debian, прибегали к этому со стародавних времён. Но поначалу в Xorg штатно такая возможность не использовалась. Как не применялось «дробное» пакетирование и в дистрибутивах, придерживавшихся соответствия пакетов «авторских» и «дистрибутивных» – а такими на протяжении долгого времени были Slackware, Gentoo и идеологически близкие к ним, не говоря уж об LFS.

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

Впрочем, чтобы, как говорится, почувствовать разницу, достаточно сравнить древа исходных текстов версий X11R6.9 и X11R7.0 на официальном сервере проекта.

Следующая веха в истории Xorg – версия X11R7.3 (X-сервер 1.4), вышедшая в сентябре 2007 года: в ней, среди прочего, получает дальнейшее развитие автоопределение оборудования, в том числе и горячего подключения. Тогда это делалось через HAL (Hardware Abstraction Layer) – и делалось вполне успешно, и, что характерно, в сборках Иксов не только для Linux, но и для BSD-систем. В частности, автор этих строк неоднократно использовал HAL во FreeBSD.

Тем не менее, в версии X11R7.6 (X-сервер 1.8.0, декабрь 2010) в управлении устройствами подсистема HAL была заменена менеджером устройств udev. Что, с одной стороны, привело к определённому прогрессу в этом деле. А с другой, поскольку udev – инструмент, специфический для Linux'а, отгородило последующие версии Xorg от остальных UNIX-подобных систем. Но на этом я поставлю точку: мой рассказ подошёл к своему логическому завершению. И вместе с ним близится и конец Иксов вообще: на горизонте маячат Wayland, с одной стороны, и Mir – с другой. Но это уже дела дней сегодняшних и грядущих.

Глава двадцать третья. Управители окон: извлечения из истории

Предыдущая глава была посвящена истории X Window System и её свободных реализаций, XFree86 и Xorg. Однако ни слова не было сказано об истории того, как эти протоколы, спецификации и реализации претворялись в те самые графические интерфейсы, с которыми непосредственно имеет дело пользователь.

Терминологическое введение

Протоколы, спецификации и реализации претворялись в виде двух классов программ – оконных менеджеров, иногда именуемых также диспетчерами окон (WM – Window Manager), и интегрированных графических рабочих сред (Graphic Deskton Environment), которые называют также средами рабочего стола (DE – Desktop Environment) или, в просторечии, десктопами.

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

же – возможность минимизации, максимизации, сворачивания окон, их перемещения, изменения размера, вызова различных наборов контекстных меню.

По большому счёту от оконного менеджера ничего иного и не требуется. Однако, как мы скоро увидим, со временем развитые представители этого класса обрастали наборами привязанных к ним утилит и приложений, а также собственными средствами настройки и наборами предопределённых тем. Откуда оставался один шаг до интегрированных рабочих сред, то есть десктопов.

Десктопы также включают в себя средства оформления окон и управления ими, то есть оконные менеджеры, собственные (как в KDE и Xfce) или заимствованные (как в GNOME и LXDE). Однако средства собственного конфигурирования, наборы тем и стилей, штатные утилиты и приложения входят в них уже в обязательном порядке. Хотя количество последних может быть различным – от всеохватного в KDE до весьма скромного в Xfce или совсем уж бедного – в LXFE. Важно, что все штатные программы десктопов характеризуются единством интерфейса, настраиваемого собственными конфигураторами среды.

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

Я не берусь рассказать про возникновение и развитие всех оконных менеджеров, когда-либо существовавших на свете – это задача непосильная для одного человека. Поэтому ограничусь только теми представителями семейства, с которыми работал непосредственно, или которые внимательно рассматривал на предмет практического применения.

Предтечи управителей

Практическая работа в X Window System без менеджера окон почти невозможна, или, по крайней мере, очень неэффективна Тому, кому доводилось видеть «голые Иксы», понятно, почему: это просто серое поле с курсором мыши в виде крестика. И никакое щёлканье мышиными кнопками не влечёт за собой ни малейшего результата.

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

Так что можно предполагать, что оконные менеджеры возникли одновременно с первыми реализациями X Windows System, однако память о них затёрлась. И первое о них упоминание обнаруживается только в X10 (конец 1985 года) под именами xwm и xnwm, но сведений о том, что они собой представляли, мне обнаружить не удалось. По косвенным данным можно предполагать, что управлялись они не мышью, а с клавиатуры комбинациями с участием клавиши Meta, и не имели средств конфигурирования.

В том же 1985 году компания DEC разрабатывает оконный менеджер uwm (Ultrix Window Manager). Он предназначался для её собственной реализации UNIX для платформы VAX – Ultrix (в последующем Tru64 UNIX), в которой Иксы не использовались. Однако был быстро портирован на них, и уже в X11R3 стал стандартным средством управления окон. Это был первый оконный менеджер, в котором с помощью файла конфигурации можно было настроить поведение кнопок мыши и привязать к ним меню управления окнами – функции, которые нынче кажутся столь тривиальными, что в гипермодернистских средах типа GNOMEShell и Unity они почти редуцировались.