Долгое время первым интерфейсом, с которым сталкивался применитель любой POSIX-совместимой ОС, был интерфейс командной строки: именно его он видел после ввода пароля и логина в текстовой консоли. И с ним же последним он расставался, выходя из системы с помощью одной из команд завершения работы. Нынче это обычно не так, вход в систему обычно выполняется в графическом режиме, через какой-нибудь дисплейный менеджер. Однако интерфейс командной строки (Command Line Interface, далее просто CLI) по прежнему остаётся Интерфейсом номер один для многих применителей. Почему его история в этой части книги и должна быть рассмотрена первой.

Конкретные реализации CLI представлены классом программ, именуемых командными интерпретаторами, командными оболочками или просто шеллами (shell – раковина, скорлупа). Большая часть командных оболочек делится, на основе синтаксиса интерпретируемого ими языка, на две группы – sh- и csh-совместимые. На самом деле различия между ними синтаксисом команд не исчерпываются, а лежат глубже – в подходе к обработке командных конструкций, но к истории, которую мы в данный момент обсуждаем, это отношения не имеет.

Появление первого шелла

Первой командной оболочкой для первозданного UNIX'а была программа, которая сначала именовалась, за отсутствием других, просто shell. Она была написана в 1978 году Стефаном Борном, вследствие чего за ней позднее закрепилось имя «шелл Борна» (Bourne shell). Язык её интерпретатора был основан на Algol 68, что определило мощные по тем временам возможности составления сценариев: достаточно сказать, что многие команды, позднее вошедшие в золотой фонд классических UNIX-утилит (породивших, в свою очередь, BSD- и GNU-утилиты), первоначально были реализованы именно как shell-скрипты. Примеры этому можно найти в книге Рассела Сейджа Приёмы профессиональной работы в UNIX, изданной около тридцати лет назад, но в методическом отношении представляющей интерес и по сей день.

Однако, средства интерактивной работы в первозданном шелле Борна были, мягко говоря, не очень хорошо развиты.. В известной таблице сравнения командных оболочек для UNIX, некогда составленной Брайаном Блэкмором (Brian Blackmore), во всех её строках, имеющих какое-либо отношение к интерактивности, можно видеть красноречивое NO . То есть в ней не было почити ничего из того, к чему мы привыкли с младых линуксовых ногтей: ни автодополнения, ни истории команд, ни возможности редактирования командной строки, ни даже возможности изменить вид приглашения.

Да, мы знаем, что потом всё это постепенно и по очереди будет появляться – сначала в шелле Корна (ksh), и в шелле Альмквиста (ash), затем изобильно в bash'е (возрождённом шелле Борна), и, наконец, в zsh, ставящем на сегодняшний день последнюю точку в развитии командных оболочек. Но сейчас-то мы находимся в далёких 70-х годах прошлого века, когда UNIX только вышел из родительских пенат AT&T (см. главу первую) и отправился в (почти) свободное плавание по университетам Америки, Европы и сопредельных стран вроде Австралии. Пришвартовавшись, в частности, и в университете Беркли, штат Калифорния.

Появление C-Shell

В Университете Беркли, как мы помним по главе второй, в это время вовсю разрабатывался собственный вариант UNIX, который позднее получит имя BSD4.4 и ляжет в основу всех свободных операционок берклианского семейства. И один из перворазработчиков BSD, Билл Джой, которому мы обязаны также текстовым редактором vi, уже в 1979 году предложил свою командную оболочку, получившую имя C-shell (или просто csh).

Почему? Если Борн при создании shell'п опирался на язык Алгол, то Джой для языка своего шелла применил синтаксис, сходный с таковым языка Си, исконного для UNIX. Это сделало оболочки sh и csh несовместимыми на уровне сценариев. Но зато в csh было добавлено множество интерактивных возможностей – автодополнение, буфер истории, средства навигации внутри командной строки и её редактирования, настройка вида приглашения, различие схемы настройки интерактивного и неинтерактивного шелла... Короче, всё то, что потом в той или иной мере инкорпорировали shell-совместимые оболочки, включая bash и zsh. И что ныне кажется нам неотъемлемым атрибутом любого шелла – всё это в конечном итоге происходит из csh.

Так что C-shell очень быстро стал непременной принадлежностью разрабатываемой в Брекли BSD-системы. Разработчики же коммерческих UNIX'ов пошли другим путём.

Как возрождался шелл

Как только что было сказано, по своим интерактивным возможностям шелл Борна, с одной стороны, оставлял желать лучшего. Со стороны же другой, перед глазами разработчиков проприетарных UNIX'ов был уже C-Shell, существенно более продвинутый в этом отношении. И потому у них появилась потребность обогатить /bin/sh средствами интерактивной работы.

Результатом воплощения этой потребности стала оболочка Корна (Korne Shell). Она сохранила совместимость с борновским шеллом на уровне синтаксиса, однако привнесла в него как дополнительные возможности интерпретации команд, так и приёмы, направленные на удобство интерактивной работы – образцом последних и послужил C-Shell. В итоге именно ksh лёг в основу стандарта POSIX, которому должны удовлетворять командные оболочки совместимых с ним систем.

Следует заметить, что соответствие этому стандарту – один из критериев отнесения некоей ОС к семейству UNIX или UNIX-подобных. В частности, именно такой стандартизированный шелл должен (был до недавнего времени) вызываться при исполнении общесистемных сценариев инициализации любой POSIX-системы. Сам же по себе POSIX shell – некая мифическая абстракция. Ближе всего ему соответствует ash, принятый в качестве стандартной оболочки пользователя во FreeBSD (под условным именем /bin/sh) и в NetBSD (а также широко используемая во всяких мини-дистрибутивах Linux).

Шеллы и Борна, и Корна не были свободно распространяемыми программами. Поэтому ни тот, ни другой не могли использоваться в таких ОС, как все BSD или Linux, хотя свободная реализация оболочки Корна (pdksh) и была создана. Однако, как и ее прототип, шелл Корна, она, несколько развившись относительно первозданного Bourne shell, обладала интерактивными достижениями, уже далекими от идеала. Столь же слабы они были и в ash. И потому наиболее широкое распространение из всего sh-совместимого семейства получила оболочка bash (что расшифровывается как «ещё одна оболочка Борна», «заново рожденный шелл» и тому подобным образом), разработанная в рамках проекта GNU.

Популярность bash в немалой степени была обусловлена его интерактивными возможностями – он аккумулировал все достижения интерактивной мысли sh- и csh-совместимых оболочек, прибавив к ним немало собственных. И умудрившись при этом сохранить базовую совместимость с POSIX shell. Конечно, многие его собственные особенности (так называемые «bash'измы») выходили за рамки этого стандарта. Однако для соответствия оному был предусмотрен режим совместимости – то есть bash был способен эмулировать стандартный POSIX shell.

Однако главным для популярности bash было то, что эта оболочка оказалась тесно интегрирована с операционной системой Linux: именно bash волею судеб стал одной из первых программ, которые Линус запустил поверх своего новосозданного ядра. И потому идеи bash-скриптинга пронизали Linux до самых его оснований. Ну а для совместимости использовался тот самый режим эмуляции: в Linux файл, запускающий POSIX shell (по стандарту он должен именоваться /bin/sh), являет собой жесткую или символическую ссылку на реальный /bin/bash. Последний же, будучи вызванным таким образом, полностью воспроизводит функционально стандартный POSIX shell (разумеется, путем утраты своих продвинутых функций).

История tcsh

Как уже говорилось, оболочка csh привнесла в шеллы элементы интерактивности. Однако и её возможности в этом отношении были далеки от идеала. Что особенно почувствовалось в начале 90-х годов, когда, с одной стороны, произошло освобождение BSD-систем в лице NetBSD и FreeBSD от тяжёлого наследия проприетарного режима лицензирования. А с другой – началось победное шествие Linux'а с его стандартной оболочкой GNU bash, обходящей древний csh на несколько корпусов.

И тогда разработчики FreeBSD вспомнили об оболочке tcsh, которая, основываясь на синтаксисе C-shell, с давних времён разрабатывалась сначала Кэном Григом в университете Карнеги-Меллона, а затем Полом Плэйсвэем в университете Огайо. Чем она была примечательна? Сейчас увидим.

Изначально tcsh создавалась по образу и подобию командного интерпретатора операционной системы TENEX -- собственно, имя её и означает TENEX csh. А особенностью TENEX -- древней, ещё до-UNIX'овой, операционки (из недр которой, кстати, происходит и знаменитая «собака» в адресах электронной почты) были чрезвычайно длинные команды, да ещё и с избыточными словами «для ясности». С такими командными директивами было бы трудно работать без развитых средств навигации и редактирования командной строки. Каковые и стали отличительными особенностями её командного интерпретатора, получившего имя TENEX C-shell.

Разработчики FreeBSD, взяв за основу TENEX C-shell, адаптировали его для своей операционной системы. В которой он и утвердился в качестве стандартного login shell администратора. В OpenBSD же и DragonFly tcsh изначально стал шеллом по умолчанию «для всех». Применяется он и в таком юзер-ориентированном отпрыске BSD-клана, как PC-BSD. Более того, первое время tcsh выступал шеллом по умолчанию в MacOS X, пока его не наменили на bash.

Однако и поныне имя /bin/csh (как и соовтетствующие ему конфигурационные файлы /root/.cshrc и $HOME/.cshrc) сохранилось в файловой иерархии всех BSD-систем как реликт предшествующей эпохи. Однако теперь оно соответствует не самостоятельной оболочке, а было лишь жесткой ссылкой на тот же tcsh. Поведение же последней по умолчанию абсолютно идентично изначальному C-Shell. Это вызвано не эмуляцией предшественника, как в случае с bash, запускаемых в качестве /bin/sh, а исключительно настройками – точнее, почти полным отсутствием таковых по умолчанию.

Наконец, Z-Shell

Как известно, Z – последняя буква латинского алфавита. И её наличие в имени следующего нашего персонажа, Z-Shell (или просто zsh) призвано символизировать то, что эта оболочка представляет собой последнюю ступень в развитии командных оболочек вообще. Хотя на самом деле происхождение её иное. Она разрабатывалась первоначально, начиная с 1990 года, Паулем Фальстадом (Paul Falstad), в ту пору студентом Принстонского университета. Аспирантом же оного был некто Zhong Shao, логином которого в университетской сети был Zhong. Вот отсюда-то, как гласит легенда, и взялась буква Z. То есть можно предполагать, что, как это часто бывало в истории свободного софта, она появилась тут "для прикола".

Тем не менее, и трактовать её в первом смысле тоже есть основания. Ибо существует мнение (и не только мое), что в zsh нашли свое воплощение все прогрессивные тенденции таких развитых оболочек, как bash и tcsh. И, ознакомившись с его возможностями, с этим трудно не согласиться — в zsh есть все, что было хорошего в тех обеих оболочках, но, если так можно выразиться, в превосходной степени.

Ныне Z-shell развивается в рамках самостоятельного проекта сообществом энтузиастов (Zsh Development Group) при координации Петера Стефенсона (Peter Stephenson), являющегося также автором большей части документации проекта. В отличие от bash, прямого (как, впрочем, и косвенного) отношения к GNU zsh не имеет, и распространяется под собственной лицензией BSD-стиля, а, следовательно, является полностью свободной программой.

Хотя, как было отмечено в предыдущей главе, CLI в полной мере сохраняет своё значение в современных UNIX-подобных системах, жизнь как «обычного пользователя», так и типичного применителя оных протекает в основном в рамках интерфейсов графического режима. А во всех этих операционках в основе его лежит оконная система X (X Window Sysytem), именуемая в народе просто Иксами. Так что настала пора обратиться к её истории.

Вступление

Нынешний Linux в пользовательской своей ипостаси не мыслим без современной инкарнации оконной среды X – Xorg. Немыслим настолько, что начинающие пользователи этой ОС часто ставят между ними знак равенства, не отдавая себе отчёта в том, что, как говорится в народе, X – он и в Африке... Икс. Точнее, един во всех UNIX'ах и UNIX-подобных операционных системах.

В своё время немало было сломано копий о тему: как должна называться операционная система, одна из главных героинь этой книги – Linux или GNU/Linux. И арьергардные бои на этом ристалище возникают временами и по сей день. Автор сих строк немало высказывался на эту тему – в том числе и в главе четвёртой данного саочинения. Так что в рамках темы главы нынешней замечу только: если уж так неймётся прикрутить к имени Linux какой-либо префикс, то с куда большим основанием это может быть префикс X.

Ибо теоретически вполне можно представить дистрибутив этой системы без компонентов, разработанных в рамках проекта GNU – есть и практически близкие к этому реализации, например, Tiny Core Linux. А вот без оконной системы X, менеджеров её окон, интегрированных десктопов и приложений графического режима говорить о каком-то десктопном Linux'е просто нелепо – как сказала поэт-линуксоид Алиса Деева,

Это разговор не в пользу бедных -- В пользу продавцов клавиатур.

И это – первая причина поговорить об истории Иксов. Вторая же – то, что разработчики проекта Wayland действительно обещают сделать Иксы достоянием истории. Которую надо рассказать, пока мы ещё чего-то помним и нас ещё не замочили.

Доисторический период

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

Не буду я рассматривать и детективную проблему – потибрили ли из Пало-Альто идею графического пользовательского интерфейса (по нашему, по бразильскому – GUI, именно этот термин и будет для краткости применяться в дальнейшем). И если потибрили – то кто же сделал это первым. Потому что по сему поводу исчерпывающе высказался лирический герой Венечки Ерофеева в поэме «Москва-Петушки»:

Никто этого не знает, и никогда теперь не узнает. Не знаем же мы вот до сих пор: царь Борис убил царевича Димитрия или же наоборот?

А начну я доисторический период с первых графических интерфейсов UNIX. Которая, как известно, зародилась и долгое время развивалась в качестве чисто текстовой. Настолько чисто, что сама идея прикручивания к ней какого-либо GUI воспринималась как ересь. Но, однако, идея эта была реализована.

Первой на это поприще вступила фирма Sun, о чём говорилось в главе третьей), изначально тесно связав свою SunOS со средствами поддержки GUI собственной разработки. Превым таким GUI'ём была SunView (Sun Visual Integrated Environment for Workstations, первоначально называвшаяся SunTools) – оконная система, возникшая едва ли не одновременно с самой SunOS в первой половине 80-х годов. От всех последующих оконных систем, ориентированных на UNIX, она отличалась тем, что большая её часть поддерживалась ядром. Она включала в себя набор стандартных пользовательских приложений, таких, как текстовый редактор, почтовый клиент, инструменты для настройки. И, наконец, она являлась частью стандартной поставки операционной системы. По-видимому, именно в SunOS впервые была реализована интеграция операционной системы, GUI и пользовательских приложений, получившая дальнейшее развитие не только в мире UNIX, а и в более иных операционках, доживших до наших дней (а имена их читатель и сам ведает).

На смену SunView в середине 80-х годов прошлого века пришла NeWS (Network extensible Window System) – более сложная система, основанная на PostScript. Однако получить широкого распространения она не успела.

Наконец, в конце 80-х годов для SunOS была разработана оконная среда OpenWindows. Сначала она поставлялась как отдельное дополнение, а потом была включена в состав операционной системы. Однако и она не снискала популярности.

Ибо тогда же, в конце 80-х годов начинается смена аппаратной платформы для SunOS: процессоры Motorola 68XXX в серверах и рабочих станциях заменяются на «камни» собственной разработки и производства, RISC-процессоры SPARC. Для которых разрабатывается и новая операционная система, названная Solaris 2. А с её приходом происходит и отказ от всех GUI собственной разработки. Они сменяются ставшими стандартными для UNIX мира оконной системой X и рабочей средой CDE. О последней речь пойдёт в главе про десктопы. А вот к истории первой обратимся сейчас.

Рождение Иксов

Программные средства обеспечения работы в графическом режиме можно условно разделить на две части – ту, что обеспечивает взаимодействие с аппаратурой, и собственно интерфейс с пользователем. Разделение это не строгое – только что я говорил о SunView, в которой эти части были неразрывны. Однако магистраль развития GUI лежала в области разделения этих частей, что наиболее последовательно было реализовано в оконной системе X (X Window System).

Кстати, о названии. Как гласят легенды древности, некогда существовала операционная система V. Поверх неё работала оконная система W, созданная в Стэнфордском университете Полом Асентэ (Paule Asente) и Брайаном Рейдом (Brian Reid). В дальнейшем она была портирована на UNIX, хотя и работала там, как говорят, очень медленно. Поэтому, когда под UNIX была разработана новая оконная система, её просто маркировали следующей буквой латинского алфавита.

Иксы начали разрабатываться в 1984 году сотрудниками MIT Робертом Шейфлером (Robert Sheifler) и Джимом Геттисом (Jim Gettys), к которым скоро присоединился Рон Ньюмен (Ron Newman). Идея разработки заключалась в том, чтобы создать графическую систему, полностью независимую как от аппаратной платформы, так и от операционной системы, даже родительской UNIX, которая бы обеспечивала студентам и преподавателям MIT доступ ко всему тому зоопарку компьютеров, который существовал в стенах этого заведения.

Официальным названием новой системы было – X Window System, причём слово Window появилось в ней более чем за год до его употребления в имени одной графической оболочки для DOS, которую тогда никто не воспринимал всерьёз ввиду непригодности к практическому использованию. И для которой оно стало ни чем иным, как торговой маркой, охраняемой законом.

Тем не менее позже в кругах, далёких от UNIX, некоторое распространение получило словосочетание X Windows. Однако, говоря словами всё того же героя Венечки, «это позорно и преступно». И истинный линуксоид до такого никогда не опустится – и не из-за пиетета перед законами. А вот более краткое X System, несколько жаргонное X11 (почему именно 11 – станет ясно со временем) и, особенно, просто X, не только допустимо, но и широко используется краткости для.

На русский язык официальное название X Window System переводилось столь же официально – Оконная система X. Однако используется оно редко – только в особо торжественных случаях. Ибо практически сразу было вытеснено кратким словом «Иксы» – пусть и жаргонным, но адекватным. Его я использовал в этой книге ранее и буду использовать впредь, поскольку официоз в ней кажется уж совсем неуместным.

Работа над Иксами проводилась ударно-стахановскими темпами. Первая версия новой системы вышла в мае 1984 года, а вышедшая в январе 1985 года версия получила порядковый номер 6. Это привлекло к Иксам внимание фирмы DEC, и Иксы были портированы на её VAX’ы.

Версии Иксов, именовавшиеся X#, сменялись с калейдоскопической быстротой: уже во второй половине 1985 года появляется X9 – первая версия, распространяемая свободно, на условиях так называемой лицензии MIT (до этого институт распространял её за плату). А на рубеже 1985-1986 годов выходит версия X10 – подряд в нескольких вариантах, так называемых реализациях: X10 – декабрь 1985 года, X10R2 – январь и X10R3 – февраль 1986.

Версия X10R3 получает широкое распространение. Кроме VAX, она портируется на машины Hewlett-Packard, рабочие станции Apollo, Sun и ряд других. В связи с этим возникла необходимость сделать её окончательно независимой от аппаратуры, что и было выполнено с привлечением сил DEC в рамках версии X11.

Разработка версии X11 заняла необычно много времени для этого проекта – более полугода: финальный вариант её вышел аж в сентябре 1986 года. Ход работы над ней широко обсуждался в Сети благодаря открытым спискам рассылки. Это был пример первого в истории масштабного проекта, разрабатываемого распределенным коллективом программистов, связанных лишь Интернетом. Таким образом, разработка X11 послужила прообразом современных крупномасштабных проектов FOSS.

Длительность разработки X11, тщательность тестирования и широта обсуждения проекта привели к тому, что эта система стала уникальным для софтверной индустрии долгожителем: номер главной версии с тех пор не менялся ни разу, добавлялись только номера реализаций. С формальной точки зрения те Иксы, с которыми мы имеем дело сейчас (то есть Xorg), также являются представителями ветки X11. Именно поэтому для X Window System широко распространилось сокращённое именование – X11.

Иксы в своей 11-й ипостаси продолжали свое триумфальное шествие по «железным» архитектурам и их операционным системам. Только что я говорил, что ради Иксов Sun прекратила собственные разработки в области графического интерфейса. Та же судьба постигла и все иные графические системы для UNIX – даже имена их ныне забылись. Иксы стали стандартным средством обеспечения работы в графическом режиме всех без исключения UNIX'ов и UNIX-подобных операционок.

Кроме того, Иксы были портированы на VAX/VMS фирмы DEC, OS/2 от IBM и даже, страшно сказать, на Windows. Хотя о последнем факте и не любят говорить вслух.

Проект приобрёл такие масштабы, что для управления им в 1988 году потребовалось создать специальную организацию, названную Консорциум X MIT (MIT X Consortium), которая объединила в своём составе как университетские круги, так и компании, разрабатывающие коммерческие решения. В 1993 году на смену ему пришёл X Consortium, выпустивший в мае 1994 года X11R6, реализацию, просуществовавшую более 10 лет: следующей, X11R7, суждено было появиться только в конце года 2005! И различные минорные её версии (последняя по времени – X11R7.7, появившаяся в июне 2012 года) используются в дистрибутивах Linux и BSD-системах по сей день.

XFree86 и другие

Сама по себе оконная система X версии X11 представляла из себя набор открытых спецификаций (reference implementation), доступных под лицензией MIT, на основе которых предлагалось создавать конкретные реализации – X-сервера с сопутствующими компонентами. Которые уже могли распространяться на любых условиях, в том числе и коммерческих.

Этим предложением не замедлили воспользоваться разработчики программного обеспечения для UNIX-систем. В результате чего появился ряд проприетарных X-серверов, обеспечивавших графический режим в столь же частнособственнических UNIX'ах. Однако наибольшую известность получила свободная реализация Иксовых референсов – XFree86.

Прототип проекта XFree86 зародился в 1991 году в рамках X11R5: соответствующий спецификациям этого релиза X-сервер был разработан Томасом Роэллом (Thomas Roell) и Марком Снайтили (Mark W. Snitily) для 32-битных платформ на процессорах Intel, получив вполне ожидаемое имя X386. Этот сервер распространялся под проприетарной лицензией фирмы SGCS (ныне SGI), сотрудником которой являлись его авторы.

Это, однако, не помешало Дэвиду Векселблату (David Wexelblat), Гленну Лэю (Glenn Lai), Дэвиду Доуэсу (David Dawes) и Джиму Тсилласу (Jim Tsillas) в 1992 году внести в его исходники коррективы столь существенные, что у них были основания выделить их в отдельную версию, названную X386 1.2E .и распространять её уже свободно.

Такое положение создавало определённую путаницу. И потому после обсуждения и обмена мнениями стороны постановили: переименовать новый проект в XFree86. Что по созвучию намекало и его на связь с корнями (X-three-eighty-six), и на характер распространения (X-free-eighty-six), а цифры явным образом указывали также на архитектуру целевых процессоров – x86.

Не пропало и дело исходного проекта: X386 был переименован в Accelerated-X, и Томас Роэлл создал фирму Xi Graphics, которая на протяжении многих лет занималась его продажами, а поддержку осуществляет чуть ли не по сей день. У нас ещё будет повод вспомнить про этот X-сервер.

А пока вернёмся к XFree86. Во вступлении я уже говорил, что своей популярностью среди широких пользовательских масс Linux во многом обязан Иксам – и конкретно именно свободной их реализации. Но, с другой стороны, XFree86 повсеместным своим распространением обязана Linux'у в не меньшей степени. Ибо усилиями Ореста Зборовски (Orest Zborowski) она заработала на Linux'е чуть ли не со дня своего рождения, а именно с апреля 1992 года.

Вообще взаимоотношение XFree86 с Linux'ом на том этапе развития обеих систем в источниках освещено довольно противоречиво. Остаётся не вполне ясным: создавалась ли свободная реализация Иксов уже с прицелом на юную, но активно развиваемую операционку? Или ещё под абстрактный UNIX, а на Linux была Орестом лишь портирована? Прямых ответов на эти вопросы мне найти не удалось.

Так что в эти детали я вдаваться не буду. Тем более в рамках нашей темы сейчас важнее другое: в октябре 1992 года XFree86 была включена в комплект, который можно назвать первым в истории настоящим дистрибутивом Linux. Им стал SLS (Softlanding Linux System), разработанный Питером Мак-Дональдом (см. главу одинадцатую). И с тех пор судьбы XFree86 и Linux'а были неразрывно связаны на протяжении 12 лет, вплоть до событий «Великого раскола», о которых я расскажу в следующих разделах.

Однако Linux не была единственной операционкой, в которой реально использовалась XFree86. В недрах архивов проекта можно обнаружить списки издревле поддерживаемых им ОСей. В их числе мы увидим такие, ныне забытые, имена, как Amoeba (первая попытка Танненбаума построить «настоящую» микроядерную ОС) и BSDi (коммерциализированная сестричка FreeBSD), Mach, ушедший в тень MacOS X, и «игрушечную» Minix, благоздравствующую, но «незнаменитую» NetBSD и скандально ославившуюся SCO, а также SVR3 и SVR4, давно ставшие абстракциями учебников по Computer Science.

А вот следов поддержки FreeBSD в ранних версиях XFree86 найти не удаётся: похоже, что в её портах свободные Иксы появляются во второй половине 1994 года (собственно, одновременно с самой системой портов). Однако с этого момента XFree86 оказывается связанной с FreeBSD не менее тесно, чем с Linux'ом – и со временем мы увидим, что эта связь окажется особенно важной для нашей страны.

Как уже говорилось, изначально XFree86 была основана на X11R5, и так продолжалось во всех версиях 1-й и 2-й веток (нумерация их не имеет никакого отношения к версиям и релизам собственно Иксов). Последней представительницей этой линии была XFree86 2.1.1, вышедшая в мае 1994 года. Однако почти одновременно появляется и новая спецификация Иксов – X11R6, которая ложится в основу новых реализаций X-серверов. В их числе была и XFree86 3.0, увидевшая свет в конце августа 1994 года.

И это были те самые Иксы, с которыми впервые столкнулось большинство из ныне действующих применителей Linux первого и второго призыва. Те самые, которые появляются в портах FreeBSD. Иначе говоря, те самые, которые стали, как принято говорить, стандартом de facto для всех существовавших тогда свободных UNIX-подобных ОС. А со временем – и для несвободных тоже, но это будет не очень скоро.

XFree86: немного о внутренностях

Говоря о XFree86 как об одной из реализаций X-сервера, я был не совсем точен: это была не одна из реализаций, а множество реализаций оного. Откуда их столько взялось? Ответить нетрудно.

Ныне, когда речь заходит о видеоподсистеме и её поддержке в Linux'е, он обычно сводится к священной войне между приверженцами Nvidia и ATI/AMD. От которой дистанцируются резонные применители, любовно поглаживающие в сторонке свои встроенные Intel'я. И подчас вспоминающие даже о существовавших не так давно SiS и Matrox. Однако представить себе пестроту видеорешений, сосуществовавших каких-нибудь 15-20 лет назад, может только тот, кто видел её своими глазами.

Ибо это была пестрота восточного базара. На котором можно было встретить видеокарты на любом чипе из выпускавшихся в те годы: и откровенно рабоче-крестьянском Trident, и плебейски-претенциозном Cirrus Logic, и S3 – символе мещанского благополучия, и аристократическом ATI, скромном трудяге – Tseng и блистательном Imagine128, 3DLabs, знаменующем высоты профессионализма, и многих других, имена которых стёрлись в памяти даже ветеранов. И чуть ли не каждому производителю видеочипов в составе XFree86 полагался свой персональный X-сервер, а некоторым их доставалось по два (как S3), а то и по три (как ATI).

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

Но это будет ещё не скоро. А пока работа многих свободных X-серверов – результата «слепого» реинжиниринга фирменных решений – часто оставляла желать лучшего. Вплоть до того, что иногда графический режим просто не удавалось запустить с «родным» сервером. Правда, в составе XFree86 имелись «всечиповые» сервера VGA и SVGA, работающие на любых картах, поддерживающих соответствующие стандарты. Однако наблюдать на дисплее, подключённом к крутейшей видеокарте, что-нибудь вроде 640x480 при 16 цветах доставляла тогдашним пользователям не много радостей.

Конечно, не всё было так мрачно, и большинство карт на типовых чипах (особенно не гипермодерновых) с типовыми же X-серверами из поставок XFree86 работали вполне справно. Однако вопрос поддержки видеосистемы свободными Иксами в 90-х годах стоял весьма остро. И попытки его кардинального решения тем или иным образом предпринимались постоянно.

Первым направлением таких попыток было, разумеется, совершенствование самих X-серверов. На этом поприще особенно прославилась фирма S.u.S.E. – создатель одноимённого дистрибутива Linux, героя главы семнадцатой. Благодаря тесным контактам с фирмой Elsie – производителем высококлассных видеокарт, в том числе профессиональных, её разработчики очень быстро получали информацию о новинках «видеожелеза» и столь же оперативно вносили патчи в свои реализации X-серверов.

Вторым направлением было использование коммерческих X-серверов, вроде упоминавшегося выше Accelerated-X. Сами по себе они не были ни свободными, ни открытыми, но на определённых условиях могли распространяться (почти) бесплатно. Благодаря этому их нередко включали в состав дисковых наборов Linux-дистрибутивов и софта для них, вроде упомянутых в главе про Linux на Руси боксов от Walnut Creek и InfoMagic. Правда, тут возникали свои сложности, как лицензионные, так и чисто технические. А для Руси этот путь оказывался закрытым напрочь, потому что тот же Accelerated-X в принципе не поддавался кириллизации.

Наконец, третий путь продемонстрировала в 1998 году маленькая и неприметная тогда фирма Nvidia. Выпустив незадолго перед тем «народную» 3D-карту Riva 128, она вскоре сопроводила её и фирменным драйвером для работы в Linux'е – драйвером, работавшим безукоризненно.

Я не буду выстраивать причинно-следственных связей. Однако то, что звёздный час Nvidia начался с Riva 128 и её Linux'ового драйвера, остаётся медицинским фактом. На констиатации которого я и поставлю запятую в своей истории.

От XFree86 к Xorg

Хронологически привязанную часть прошлых разделов этой главы я закончил на появлении в августе 1994 года XFree86 версии 3.0 – той самой, которой суждено было со временем лечь в основу десктопного Linux'а. В нынешней же главе предлагаю посмотреть, что было со свободной реализацией Иксов дальше.

Между «тройкой» и «четвёркой»

А дальше на протяжении 1994-1996 годов плавно сменились версии 3.1 и 3.2, не прославившиеся какими-либо громкими новшествами. А затем в мае 1997 года выходит версия 3.3, ознаменовавшаяся появлением в ней XFree86 Acceleration Architecture (XAA). Архитектура эта, как явствует из названия, обеспечивала ускоренный вывод графики – пока ещё двухмерной: как это ни трудно нынче представить, но тогда последняя ещё нуждалась в акселерации. Именно на её почве расцвели пышным цветом те самые X-сервера, привязанные к видеочипам, о которых шла речь в заключительной части прошлой статьи.

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

О постоянном совершенствовании X-серверов, обеспечивавших базу для всего остального, я уже говорил. Далее, важным оказалось развитие поддержки шрифтов. Первоначально в XFree86 применялись, во-первых, растровые шрифты (форматов bdf и pcf), во-вторых, векторные шрифты формата PostScript (ATM Type 1). Сфера применения первых была ограничена – они использовались преимущественно в терминальных программах и текстовых редакторах. Назначение же вторых было, теоретически, вполне универсально. Практически же их широкому использованию мешало. во-первых, низкое качество самих шрифтов, во-вторых – не лучший их рендеринг.

До решения второй проблемы было ещё далеко. А вот в отношении первой в описываемое время произошли определённые подвижки, выразившиеся в появлении поддержки шрифтов True Type. Что сначала дало возможность использовать шрифты от Microsoft, штатно применявшиеся в Windows, начиная с версии 3.1 (Arial, Times New Roman, Courier New и так далее), по чьему-то недосмотру оказавшиеся в почти свободном доступе, хотя и в несколько извращённой форме. А потом оказалось толчком для разработки качественных ttf-шрифтов, уже полностью свободных (Bitstream Vera, DejaVu, Liberation).

Теперь надо сказать пару слов о поддержке устройств ввода – то есть клавиатур и мышей.

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

Ввод кириллицы в кодировках ISO 8859-5 (по историческим причинам изначально принятый в русских вариантах проприетарных UNIX'ов, в частности, в SunOS) и KOI8-R (утвердившейся, благодаря Андрею Чернову aka ache, во всех свободных UNIX-подобных системах), поддерживался ещё в XFree86 2.X, однако методом, считавшимся идеологически неправильным. Полноценная поддержка кириллических раскладок стала возможной только в версиях 3-й ветки – правда, ценой несовместимости с более старыми русифицированными приложениями, например, Netscape Navigator (легендарный предшественник современных FireFox'а и Thunderbird'а).

Параллельное использование более чем одной раскладки клавиатуры (впрочем, в те времена их число ограничивалось двумя) требовало средства переключения между ними. И такое средство ещё в версиях 2.X было жёстко встроено в саму раскладку. В частности, переключение с латиницы на кириллицу и обратно было привязано к клавише CapsLock (а функцию перевода алфавитных клавиш в верхний регистр выполняла комбинация Shift+CapsLock).

В XFree86 3.X появилась возможность переназначения переключателя раскладок, чем народ немедленно воспользовался: для переключения с латиницы на кириллицу пошли в ход Windows-подобные комбинации типа Control+Shift и Alt+Shift, и даже приснопамятные «два шифта».

Очередное отступление, или Легенда о двух Shift'ах. Во времена самостийных русификаций DOS и её приложений переключатели латинской и кириллической раскладок бывали самыми причудливыми. Однако, когда русский язык начал официально поддерживаться этой ОС (начиная с версии 4.01), в этом качестве утвердилась комбинация левого и правого Shift'ов. И ей суждена была долгая жизнь – но благодаря не DOS'у, а Linux'у.

В первых версиях Red Hat, самостоятельно, без участия российских пользователей, поддерживавших русский язык, выбор его на стадии установки автоматически приводил к тому, что умолчальной становилась кириллическая раскладка (причём об этом нигде не говорилось). Это на стадии создания аккаунтов делало невозможным ввод корректных паролей администратора и пользователя, если не переключиться на латиницу. Переключение это программе установки (и только в ней) осуществлялось комбинацией обоих Shift'ов – но это нигде не было документировано. И не одно поколение пользователей Red Hat, а затем и Fedora, имело повод поупражняться в солдатской смекалке, угадывая сначала, почему в ответ на ввод пароля выдаётся сообщение об ошибке, а потом – о способе её устранения. Ибо последние рецидивы данного бага (давно превратившегося в фичу) я наблюдал ещё в Fedora 11.

При этом поначалу наличие «заказного» переключателя раскладок не исключало и использование переключателя встроенного, то есть всё той же клавиши CapsLock. Что, казалось бы, никому не мешало – как и наличие бочек с красной и чёрной икрой при входе в магазин Рабиновича на Дерибасовской улице. Однако было сочтено излишеством – и в версии XFree86 3.4 встроенный переключатель раскладок исчез. Что скоро, с появлением средств автоматического конфигурирования Иксов, доставило много дополнительных развлечений не одному поколению начинающих линуксоидов и берклианцев.

Однако прежде чем отсутствие встроенного переключателя раскладок проявило себя во всей красе, произошла та самая забавная история, о которой я недавно упоминал. Суть её была в том, что в один прекрасный момент, с выходом XFree86 версии 3.3.2, русская раскладка для кодировки KOI8-R без всяких видимых причин просто перестала работать. Точнее, она делал вид, что работала, но выводе получалась абракадабра из русских букв.

Дело оказалось в том, что раскладка для кодировки KOI8-R подменялась таблицей для ISO 8859-5. А причина заключалась в банальной опечатке в исходниках главной Иксовой библиотеки – xlib. Более ни на что эта опечатка не влияла, и потому её выявление заняла довольно много времени. Это было сделано Иваном Паскалем, который и написал соответствующий патч для версии 3.3.2, штатно включённый в следующий релиз (3.3.3).

Отступление. Выше я упомянул о той роли, которую сыграло появление Иксов во FreeBSD для нашей страны (точнее, её государственного языка). Так вот, Иван Паскаль был вовсе не линуксоидом, как наверняка подумали многие. Нет, он был применителем FreeBSD, автором фундаментальных записок об этой ОС, сохранивших свою актуальность и поныне. Но, к сожалению, в момент сочинения этих строк недоступных.

Тем не менее, XFree86 в рамках ветки 3.3 от версии к версии всё совершенствовалась, пока система не приобрела законченный вид в релизе 3.3.6, вышедшем в декабре 1999 года. Она тут же была включена во все дистрибутивы Linux, и использовалась на протяжении долгого времени.

Однако на этом развитие 3-й XFree86 ветки фактически прекратилось – уже в марте 2000 года появляется первый релиз ветки 4-й, кардинально переработанной. Правда, разработчики XFree86 совершенно чётко позиционировали версию 4.0 как экспериментальную, и майнтайнеры всех распространённых дистрибутивов вняли их предупреждению, включая её в состав своих сборок в качестве опции: как основная графическая система ещё долгое время применялась версия 3.3.6.

Хроника поступательного движения

главным новшеством XFree86 4-й ветки была ликвидация зоопарка X-серверов, расплодившихся по принципу «один видеочип – один сервер». Отныне герой (то есть X-сервер) остался один. А вся чипо-специфическая его часть выносится в отдельные модули (по старой традиции называемые драйверами).

Далее, в XFree86 4.X появляются собственные средства автоконфигурирования. Если раньше к таковым понятие «авто» можно было применить чисто условно (см. следующие отступления), то теперь запуск команды

# X -configure

давал неизменно превосходный результат в виде конфигурационного файла /etc/X11/XF86Config компактного, но при этом исчерпывающе прокомментированного. А самое главное – почти всегда работающего без всяких дополнительных телодвижений. Лишь в нашем кириллическом окружении он требовал минимальной ручной доводки.

Настройка XFree86: как это делалось встарь Говорят, что во времена совсем былинные настроить Иксы можно было только лобовым созданием их конфигурационного файла в текстовом редакторе. Однако затем появились механизированные средства для решения этой задачи, и первое из них носило имя xf86config, издревле входившее в штатную поставку XFree86. Оно запускалось из командной строке и работало в интерактивном режиме. То есть – требовало нудного ответа на множество вопросов. И любая ошибка могла быть исправлена только одним способом – выходом из конфигуратора и повторением процедуры с самого начала. Однако это средство обладало одним несомненным достоинством – при должной аккуратности позволяло добиться результата (в виде сгенерированного файла /etc/XFree86.conf), почти не требующего ручной доводки (за исключением некоторой докрутки кириллицы и, для некоторых CRT-мониторов, юстирования частотных характеристик развёртки).

Настройка XFree86: как это делалось в Одессе В XFree86 появились меню-ориентированные программы настройки: Xconfigurator с псевдографическим интерфейсом, XF86Setup, работавшая в графическом режиме VGA, и xf86cfg, допускающая как текстовый, так и графический варианты запуска, причём в последнем она пыталась максимально точно определить параметры видеоподсистемы. Разумеется, работать через меню, да ещё и (в графических вариантах) управляемом мышью, было куда проще, чем отвечать на многочисленные вопросы. Да и вернуться к ошибочно определённому пункту было куда легче, чем перезапускать заново, с нуля, xf86config. Однако объём однако объём ручной правки после работы любой из перечисленных утилит, был куда больше, чем при использовании последнего.

Настройка XFree86: как это делалось в Linux'ах В конце 90-х годов ряд дистрибутивов, проявлявших наибольшую любовь к пользователям, штатно включили средства настройки Иксов в свои инсталляторы. В числе первых на этом поприще отметились Mandrake и Caldera OpenLinux – приоритет сейчас уже не определить. Да он и не очень важен. Более существенно то, что средства настройки Mandrake были унаследованы сначала его Russian Edition, а потом Altlinux'ом. Где были расширены, углублены и закалены в боях с кириллицей (или, правильней сказать, за кириллицу в Иксах). А под идейным влиянием дистрибутива от Caldera развивался инсталлятор ASPlinux, выпускавшийся одноимённой фирмой. А поскольку она тоже имела соплеменное происхождение, то и он доблестно показал себя на ниве кириллизации Иксов.

Разумеется, сказанным усовершенствования «четвёрки» не исчерпывались: тут были и возможность работы с двумя мониторам, и автоматическое распознавание большинства моделей «колесатых» мышей (ранее для их поддержки требовался отдельный пакет imwheel), и способность работать с графическими планшетами «рисовального» назначения.

Все эти «улучшательства», постепенно накапливавшиеся в ходе коротких жизненных циклов минорных релизов 4.0.X, привели к тому, что релиз 4.1, вышедший в июне 2001 года, широко распространился в дистрибутивах Linux в качестве «Иксов по умолчанию». А появлением в начале 2002 года релиза 4.2 «тройка» из их состава практически исчезла, уцелев разве что в ультраконсервативных системах типа Debian'а.

На этом поступательное развитие XFree86 не остановилось: в сентябре 2002 года выходит корректирующий релиз 4.2.1, а за ним, в феврале 2003, – «полумажорный» 4.3. В рамках последнего продолжают накапливаться усовершенствования, призванные воплотиться в будущем релизе 4.4, уже совсем «мажорном». Однако тут происходит поворот судьбы, значение которого для дальнейшего развития и Иксов, и Linux'а трудно преувелчить – хотя и до сих пор не ясно, как оценить.

Предпосылки Великого раскола

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

Основная часть разработчиков проекта утверждала тогда, что Кейт втихаря начал разработку проекта параллельного. И в результате в марте 2003 года его исключают из «партии XFree86» с закрытием доступа к «партийному распределителю» – дереву исходников. Сам же Паккард отрицал партизанский характер своих действий, хотя и активно критиковал бывших коллег за медлительность в рассмотрении патчей от сторонних разработчиков и общий консерватизм. И действительно, после изгнания «из рядов», создаёт собственный форк Иксов – тот самый, которому суждено было стать современным проектом Xorg. Обещая, что он будет развиваться более динамично и «инновационно».

Насколько эти обещания были выполнены на первом, ещё «безымянном», этапе развития нового проекта, судить трудно. Потому что это не был ещё сам Великий раскол: в итоге основу форка Xorg составил один из пре-релизов XFree86 – 4.4 RC2. А поводом для собственно раскола послужили лицензионные противоречия. Но это – совсем другая история, которая принадлежит скорее политике.

Повод к Великому расколу

Что потом началось – не опишешь в словах Владимир Высоцкий

Прошлый раздел завершился тем, что на базе последнего кандидата в релизы XFree86 4.4 RC2 был создан его форк. А вслед за этим происходит событие, приведшее к Великому расколу. Точнее, послужившее его непосредственным поводом – причины его, как мы только что видели, были гораздо глубже.

В феврале 2004 года выходит долгожданный релиз XFree86 4.4, аккумулирующий все новшества предшествующих корректирующих и «полумажорных» релизов. Однако – под скоректированной же лицензией. Если ранее XFree86 распространялась под стандартной «разрешительной» лицензией MIT, то в новой версии появился пункт, несколько напоминающий пресловутую «оговорку о рекламе» из первой версии BSD-лицензии, в последующем изъятую (подробности см. в главе второй).

Хотя, если вчитаться в текст лицензии, выясняется, что всё её новшество сводится к требованию включать в документацию дистрибутивов, использующих XFree86, такую фразу:

Данный продукт включает программное обеспечение, разработанное The XFree86 Project, Inc (http://www.xfree86.org/) и его сотрудниками.

То, что в просторечии обычно называется лицензией MIT, правильней именовать лицензией X11. Ибо в разных проектах MIT использовалось несколько видов лицензий, большинство из которых со временем вышли из употребления. Существующий же текст лицензии, под которой распространялась XFree86 вплоть до последнего кандидата в релизы версии 4.4, был сочинён специально на ранней стадии разработки Иксов и именно для них.

Казалось бы – чего страшного? Почему бы лишний раз не помянуть добрым словом разработчиков хорошей (и на тот момент времени практически незаменимой) системы? А вот именно её незаменимость и вызвала, думается, претензии: фактически каждый дистрибутив Linux'а общего назначения или операционная система BSD-семейства включали в себя Иксы – а альтернатив XFree86 к тому времени не было, ибо прочие X-сервера, о которых вскользь упоминалось в одном из предыдущих разделов, практически вымерли. И такое требование было воспринято сообществом (сначала – некоторыми, но влиятельными его членами) как беззастенчивая реклама проекта XFree86 за счёт разработчиков всех остальных, взаимосвязанных, но независимых проектов.

Так что дальнейшие события можно описать цитатой из классика, чьи слова приведены и в качестве эпиграфа раздела:

Тут поднялся галдёж и лай..

Новая лицензия была названа несовместимой с принципами свободы такими авторитетами, как Ричард Столлмана и разработчики Debian'а. К ним постепенно присоединились остальные ведущие разработчики, включая Тео де Раадта (OpenBSD) – его высказывания в этом плане были, пожалуй, наиболее резкими.

Правда, все эти разработчики поначалу пошли своими путями. В одни системы (Debian, OpenBSD) была включена XFree86 под последней «чистой» MIT-лицензией, большинство же переключилось на её форк – Xorg, первый официальный релиз которого появился в апреле 2004 года. Который вскоре и стал магистральной линией развития Иксов.

Конечно, были и отдельные «голоса из ветвей». Так, Патрик Фолькердинг высказался в том смысле, что его все эти политико-юридические игры не интересуют, и ничего крамольного в новой лицензии XFree86 он не видит. Однако был вынужден, в целях совместимости с прочими дистрибутивами Linux'а, перейти на Xorg.

А вот разработчики NetBSD вообще сочли, что новая лицензия – вполне нормальна с точки зрения BSD-стиля, и использовали XFree86 в своей ОС вплоть до её версии 4.0 включительно (вышла в самом конце 2007 года). Правда, в версии 5.0 (апрель 2009) и им пришлось от неё отказаться, ибо разработка XFree86 к этому времени фактически прекратилась: последний её релиз, 4.8, появился в конце 2008 года.

Конец XFree86...

That is the end of Solomon Grandy. Английское народное

Причин прекращения разработки XFree86 было несколько. Здесь можно назвать и её невостребованность в связи с переходом большинства, а затем и всех дистрибутивов Linux и BSD-систем на Xorg, и миграцию многих, если не большинства, бывших её разработчиков в томи же направлении. Но главной, на мой взгляд, причиной было то, что в XFree86, в сущности, стало нечего разрабатывать: уже к 2004 году она представляла собой устоявшуюся экосистему, кардинальные улучшения в которую можно было внести путём столь же кардинальных изменений. Так что участникам проекта, в сущности, оставалось только отлавливать баги и вносить коррективы в соответствие с изменениями остальных базовых компонентов. То есть осуществлять банальную техническую поддержку конечного продукта. А это для разработчиков Open Source, следующих курсу Just for Fun, что серпом по... ушам. Вот хлопцы и разбежались в разные стороны. Точнее, в сторону Xorg.

Однако в последнем случае нельзя исключить и влияние активной пропаганды порочности новой лицензии XFree86 с точки зрения идеалов свободы и демократии. А насколько такого рода пропаганда может быть действенной в сообществе Open Source, мы имели возможность убедиться совсем недавно – на примере тотальной systemd'изации всея Linux'а. Так что уделим обсуждению этого вопроса ещё несколько минут.

Как уже было сказано, с точки зрения здравого смысла и человеческой порядочности новая формулировка лицензии XFree86 не может вызвать никаких возражений: упоминание автора всегда считалось хорошим тоном в мире фундаментальной науки. А разработка Open Source, как ещё давно показал Николай Безруков, есть разновидность фундаментальной науки. По крайней мере, должна ею быть...

Интересно, что наиболее активные из тогдашних критиков новой лицензии XFree86 (не будем лишний раз поминать их всуе) и по сей день не упустят случая напомнить, что ОС Linux на самом деле должна называться GNU/Linux. Ибо Linux – это только ядро, а всё пользовательское окружение – достижения проекта GNU.

Но, если следовать этой логике, то термин вроде XFree86/Linux имел 10 лет назад куда больше прав на существование. Как сейчас более правомерен был бы термин Xorg/Linux. А во все времена и у всех народов – просто X/Linux. Ибо, с одной стороны, так называемое пользовательское окружение ядра Linux состоит не только из GNU-комопнентов. Более того, существуют дистрибутивы (например, Tiny Core), где их нет совсем. А вот без Иксов в том или ином их проявлении ни один дистрибутив общего назначения не обходился никогда.

Со стороны же другой, современный пользователь Linux может (то есть имеет не только право, но и возможность) даже не подозревать о пресловутом пользовательском GNU-окружении. Ибо часто работает исключительно в графической среде, то есть в Иксах и надстраивающих их оконных менеджерах или интегрированных десктопах. А потому без XFree86/Xorg ни о каком десктопном Linux'е не может идти и речи.

Так что новая лицензия XFree86 была только попыткой «легализовать» существующее положение дел. Причём без претензий на замену устоявшихся имён операционных систем, а только на уровне обязательности упоминания одного из важнейших, с точки зрения пользователя, их компонента. И, более того, не во всяких там копирайтах и копилефтах, а исключительно в документации, сопровождающей дистрибутивы. Тем не менее, она была дружно признана несовместимой с духом изначальных Иксов (Тео де Раадт), свободного софта вообще (Ричард Столлман) и буквой «самой свободной» из всех свободных лицензий, то есть с GPLv2. И потому подверглась всеобщему остракизму.

Новая лицензия проекта XFree86 по научному называлась Лицензия XFree86 версии 1.1 (под версией 1.0 следует понимать лицензию X11). Интересно, что GNU/FSF, в своё время столь категорически её осудившая, ныне признаёт её совместимость с лицензией GPLv3 – той самой, которую FSF в настоящее время считает наиболее правильной и всячески рекомендует её к употреблению. Однако с GPLv2 лицензия XFree86 версии 1.1 несовместима по прежнему – из-за требования упоминания её имени в документации.

Впрочем, ныне это уже не актуально. И может быть приведено только в качестве примера того, как юридические формулировки, придуманные, казалось бы, с самыми лучшими намерениями – ради защиты свободы – вступают в противоречие со здравым смыслом. А в конечном счёте – и с той же самой свободой. Ещё один такой пример мы уже видели при рассмотрении истории файловой системы ZFS (см. главу десятую).

... и начало Xorg

Если историю XFree86 уже в 2004 году можно было считать законченной (хотя она существует и доступна по сей день), то история Xorg только начиналась. И начиналась она весьма бурно.

Дабы отрешиться от старого мира, в проекте Xorg отказались от продолжения нумерации версий XFree86. И для начала продолжили нумерацию спецификаций оконной системы X вообще: первый релиз проекта (апрель 2004) именовался просто X11R6.7.0. Напомню, что предыдущая «общеиксовая» версия, X11R6.6, появилась на свет в апреле 2001 года. А спецификации «мажорные», то есть X11R6, на протяжении многих лет лежащие в основе XFree86, уходят в далёкий майский день 1994 года.

Со временем параллельно ей стала использоваться нумерация по версиям собственно сервера Xorg. В релизах X11R6.7.0 и X11R6.8.X в неявном виде подразумевалось, что он имеет номер версии 1.0. А далее к нему прибавлялась «мажорная» (1.X) или «минорная» (1.X.Y) единица. В настоящее время именование по версиям сервера Xorg является основным. Так, текущая его версия на момент сочинения этих строк – 1.15.

Итак, в апреле 2004 года появляется первая версия собственно Xorg – X11R6.7.0, основанная на исходниках XFree86 4.4 RC2 и мало чем от последней отличавшаяся. Точнее, не отличавшаяся ничем – имел удовольстве сравнивать их вживе. А далее версии сменяются с быстротой, заставляющей вспомнить ранние времена первозданных Иксов: 8 сентября 2004 – X11R6.8.0, 17 сентября 2004 – X11R6.8.1, февраль 2005 – X11R6.8.2.

В версии X11R6.8.0 впервые появляются такие ныне привычные вещи, как Composite – предварительная прорисовка изображения для вывода его на экран в уже готовом виде, прозрачность окон и прямая поддержка конфигураций с несколькими мониторами. «Минорные» же версии носили корректирующий характер.

Далее наступает некоторое затишье, продолжавшееся до 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 они почти редуцировались.

У истоков управления окнами: twm...

Следующим этапом в развитии оконных менеджеров стал twm, разработанный Томом Ластрэйнджем (Tom LaStrange) в 1987 году и включённый в качестве стандартного компонента в Иксы, начиная с X11R4 (декабрь 1989 года). Откуда он и попал в XFree86, появившуюся, как помнить читатель, в феврале 1991 года (LXF#168).

В отличие от ранее упомянутых оконных менеджеров, twm могли бы наблюдать многие из ныне действующих линуксоидов. Хотя развитие его прекратилось, twm до недавнего времени в качестве стандартного средства управления окнами входил практически во все сборки Иксов – как в XFree86, так и в Xorg. А некоторым и довелось наблюдать его: именно twm запускался по умолчанию в ответ на команды startx, если в пользовательском конфигурационном файле Иксов не было определено ничего другого.

Создатель twm, Том Ластрэйндж (Tom LaStrange), разрабатывал этот оконный менеджер для себя – и, вполне естественно, назвал его собственным именем: первоначальной расшифровкой аббервиатуры было: Tom's Window Manager. Такая практика в те годы была обычной (вспомним, например, Joe – Joe's Own Editor, то есть Личный Редактор Джозефа Аллена, его создателя) и отражала не манию величия или стремление увековечить своё имя. А напротив, как бы говорила: эту программу я сделал для себя. Подразумевая в скобках: а подойдёт ли она вам – не знаю.

При включении twm в штатный комплект Иксов Том передал права на своё произведение X-Консорциуму, стоящему в то время у руля управления графическими интерфейсами в UNIX'ах. И twm перестал быть его личным инструментом, а стал всенародным достоянием (на условиях X-лицензии, разумеется). К тому же новые разработчики добавили в него функцию объединения заголовков окон в единую панель с закладками (позднее нечто подобное будет реализовано во FluxBox'е, а сама идея закладок нашла применение в бессчётном количестве прикладных программ; говорят, что не так давно закладки появились даже в Internet Explorer). Так что twm с полным на то правом был переименован в Tabbed Window Manager.

А через четверть века после своего возникновения получила распространение более иная расшифровка имени twm: Timeless Window Manager. Что, применительно к случаю, я перевёл бы как Оконный Менеджер Всех Времён (а возможно, и народов).

Ныне место «аварийного» оконного менеджера в ряде дистрибутвов Linux занял IceWM. Однако и twm до сих пор сохраняется во многих сборках, например, его можно обнаружить в стандартной установке openSUSE.

Основным средством управления окнами в twm окончательно стала мышь. С её помощью, по щелчку правой кнопкой, вызывалось контекстное меню рабочего стола для запуска приложений и прекращения их работы, выполнения системных действий, таких, как выход из сеанса или рестарт машины, манипулирования открытыми окнами. Впрочем, управление окнами можно было осуществлять и действиями в строке заголовка – опять же с помощью мыши.

Собственного средства конфигурирования или каких-либо тем и стилей twm не имел: все настройки осуществлялись правкой единственного и весьма простого по устройству конфига – twmrc. Что, тем не менее, позволяло добиваться весьма причудливого и эффектного внешнего вида.

Современный оконный менеджер и, тем более, декстоп трудно представить себе без виртуальных рабочих столов – некоего аналога виртуальных терминалов консольного режима. Однако в twm их ещё не было. Зато допускалось применение виртуального разрешения экрана, и во времена, когда преобладали мониторы с физическим разрешением 640x480, а режим 800x600 считался предметом роскоши, это было более чем востребовано).

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

Ныне, в эпоху больших LCD-мониторов, виртуальное разрешение экрана устанавливается редко, обычно для каких-то специальных задач, и многие современные лиунгксоиды даже не подозревают о его существовании. Однако во времена, когда самым ходовым размером экрана было 14, много 15 дюймов, это была палочка-выручалочка при использовании таких нагруженных интерфейсными элементами рабочих сред, как KDE.

Кстати, оверлейный режим GNOME Shell, которые создатели «третьегнома» продают как последний писк прогресса, – ни что иное, как гальванизированная идея виртуального разрешения. Воистину, если не всё, то многое новое – это основательно испорченное старое.

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

... и его линия

Как уже было сказано, twm не поддерживал виртуальных рабочих столов. Однако эта функция появилась в его ближайших прямых потомках – vtwm (Virtual TWM) и tvtwm (Tom's Virtual Tab Window Manager – опять же разработка Ластрэйнджа для личного пользования). Которые, в сущности, только ею и отличались от родителя.

Из косвенных потомков twm наибольшее распространение и известность приобрёл FVWM, что изначально расшифровывалось как Feeble Virtual Window Manager (то есть хилый виртуальный менеджер окон), однако в дальнейшем значение первой литеры забылось, и она стала восприниматься символически. Он был создан в 1993 году Робертом Нэйшном (Robert Nation). И сначала – также для личного применения. Однако, будучи также автором эмулятора терминала rxvt, он начал распространять их совместно – и FVWM был принят народом «на ура».

Вскоре Роберт прекратил заниматься FVWM, и его на посту основного разработчика сменил Чарльз Хайнс (Charles Hines), который внёс изменения в формат конфигурационного файла, дополнив его рядом новых возможностей. Получившийся в результате оконный менеджер стал известен в народе как FVWM2, хотя до сих пор оба названия часто употребляются как синонимы.

FVWM, особенно в варианте FVWM2, прославился своей поистине безграничной настраиваемостью как функционала, так и внешнего вида. Правда, достигалась она кропотливой правкой конфигурационного файла, причём далеко не очевидной, требующей вдумчивого чтения документации. В этом отношении его можно сравнить с позднейшим KDE: хотя в нём настройка выполняется через собственный графический интерфейс, однако он тоже далеко не прозрачен и требует освоения. Впрочем, в обоих случаях затраченные усилия окупаются неизменно превосходным результатом.

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

По стопам Windows 95

Летом 1995 года появляется Windows 95 со своей сакраментальной кнопкой Пуск (она же Start). И сразу обретает бешенную популярность среди windows-профов (windows-профи в это время продолжают применять Windows 3.1/3.11 для офисных задач и NT 3.X – для задач всамделишних).

По закономерной случайности в это же примерно время Linux делает первую попытку обратиться лицом к пользователю в корпоративном его исполнении (LXF#150), а энтузиасты-линуксоиды начинают первую волну пропаганды своей любимой системы частным порядком, среди широких народных масс. А так как последние уже вкусили от прелестей кнопки Пуск, предпринимаются попытки обеспечить их таковой и в графических оболочках Иксов.

Отступление: про win-профи и win-профов. Вопреки устоявшемуся мнению, победное шествие Windows той линии, которую в фольклоре именовали «оболочкой дешёвой», началась не сразу с появлением Windows 95. Свидетельством чему – появившаяся в «Компьютерре» колонка тогдашнего её главного редактора, Георгия Кузнецова, о профи и профах. В которой прозвучала пророческая фраза (цитирую по памяти): «Профы поустанавливают Windows 95» дома, потом притащат её на работу, и профи придётся с этим разбираться.

Так оно и случилось. Хорошо помню время, когда на моей тогдашней службе проходила массовая замена незадолго перед тем внедрённой в качестве «фирменного стандарта» OS/2 на Windows 95 и затем на Windows 98. И проходила она по пожеланиям трудящихся. А поскольку среди трудящихся велик был процент не только простых докторов наук. но и академиков с член-коррами, пожелания эти по силе своей были близки к армейскому приказу.

Кстати, именно тогда мы впервые на практике массово применили Linux в условиях производственного десктопа. Оказалось, что самый быстрый и простой способ искоренения OS/2 – загрузка Linux'а с дискеты и запуск в нём команды # dd if=/dev/zero of=/dev/hda

В результате в 1996 году на свет божий появляется fvwm95 – весьма причудливая имитация интерфейса Windows 95. Она была образована из несколько облегчённого FVWM с прикрученной к нему панелью задач в win-стиле и, разумеется, кнопкой Пуск. Собственных средств его конфигурирования по прежнему не было, но настраивать стало легче, стало веселей. Потому что конфигурируемых параметров стало меньше, по сравнению с прототипом. В общем, на меня некогда этот оконный менеджер произвёл впечатление откровенной пародии – причём и на FVWM, и на Windows 95. Судя по тому, что он очень быстро сошёл со сцены – я был не одинок в своём мнении.

Однако дело кнопки Пуск не пропало. Его подхватили... и так далее, по Ульянову в скобках Ленину, разработчики других GUI, начиная с IceWM и кончая героями... Но о героях речь пойдёт в следующей главе. А здесь поговорим о IceWM.

Если fvwm95 выглядел поделкой, слепленной на скорую руку на потребу win-профам, IceWM, разработка Марко Мачека (Marko Maček), начатая им в 1997 году, производил впечатление продукта, сделанного не только с умом, но и с любовью. Кроме того, он был написан «с нуля», а не основывался на коде FVWM, хотя без идейного влияния последнего и не обошлось (в частности, в плане гибкости конфигурирования).

Основных особенностей, выделявших IceWM в ряду прочих оконных менеджеров (а я выше упомянул далеко не всех его современников – одних только эпигонов FVWM тогда существовало с полдюжины), изначально декларировалось три:

   • интуитивно понятный интерфейс (кто видел умолчальный FVWM, поймёт, о чём речь) с возможностью гибкой индивидуальной настройки (в этом отношении если IceWM и уступает FVWM, то не намного);

   • доступность полного функционала интерфейса с клавиатуры, без использования мыши, что для большинства современников было затруднительно: в те времена мне приходилось слышать высказывания, что в Иксах без мыши работать вообще невозможно; так вот, IceWM был живым их опровержением;

   • быстродействие и минимизация в использовании ресурсов.

Все эти цели были достигнуты – и плюс ещё ряд дополнительных. Например, хотя исходно предусматривалась только настройка IceWM традиционным путём правки конфигов (их довольно много, но они просты и понятны), очень быстро он был дополнен средством собственной настройки – графической утилитой IcePref. А простота создания тем для IceWM привела к тому, что таковых было создано много: кроме умолчальной стилизации под Windows 95, в сети можно было найти множество тем, воспроизводящих внешний вид OS/2, Motif и многих других систем. При наличии желания и толики свободного времени не составляло труда сделать и собственную тему.

Оконный менеджер IceWM продолжает своё развитие до сих пор: очередные его версии выходят не часто, ибо кардинально улучшать в нём уже нечего, но регулярно – в соответствие с необходимостью подгонки под новые версии библиотек, с которым он связан зависимостью. И, как уже было сказано, в сборках Xorg некоторых некоторых дистрибутивов IceWM сменил twm в качестве «умолчального» (или «аварийного») оконного менеджера, который может быть запущен, вне зависимости от наличия или целостности любых других графических сред.

Однако, как мы увидим в следующей статье, свет клином не сошёлся на линии FVWM и Windows-подобии. Напротив, наиболее яркие представители семейства оконных менеджеров представляли собой линии более иные.

По следам легенды

Вторая половина 90-х годов – период бурного развития оконных менеджеров: все ныне существующие их группы (за единственным исключением, о котором я упомяну в конце статьи) возникли в это время, в том числе и самые яркие, по моему мнению, представители семейства.

Кто же не помнит старика Крупского? Пардон, старика NeXT'а? Увы, наступил угар НЭПа, и имена героев информационной революции постепенно забываются. Так что как раз NeXT в качестве аппаратной архитектуры и NeXTStep в роли операционной системы для неё ныне вспоминают не часто. А ведь эта платформа стала легендой ещё при жизни...

О судьбе аппаратной составляющей платформы я скажу пару слов в отступлении. Здесь же речь пойдёт о продолжении дела программной составляющей – ОС NeXTStep. Каковое имело место быть отнюдь не в проприетарной OpenStep – совместном детище компаний NeXT и Solaris: ей суждено было стать жертвой аборта на ранней стадии беременности. И даже не в MacOS X – не смотря на общее происхождение, родства на генетическом уровне между ними оказалось не так уж много. А о продолжателях дела старика NeXT'а из мира свободного программного обеспечения.

Отступление. Операционная система NeXTStep изначально разрабатывалась для аппаратной платформы NeXT, созданной в 1987 году одноимённой фирмой, основанной и возглавлявшейся Стивом Джобсом в период его развода с Apple. Компьютер NeXT, сердцем которого был пламенный мотор от Motorola за номером 68040, выглядел тогда как пришелец из далёкого будущего: футуристический «чёрный кубик» (что было его народным названием) в качестве непременных компонентов включал в себя мощный видеоадаптер, привод компакт-дисков и звуковую карту. То, о чём в те годы рядовой пользователь не только PC, но и Mac'а не мог даже мечтать.

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

Однако учёные не принадлежат к самым богатым слоям прогрессивного человечества, и с золотым запаом у них часто напряги. И в итоге развитие NeXT как аппаратной платформы прекратилось в 1993 году. – именно по причине недостаточного объёма продаж Однако уход NeXT’а с «железного» рынка трудно назвать иначе чем триумфальным: последние месяцы продаж «чёрного кубика» ознаменовались ажиотажным на него спросом. И как раз со стороны научных учреждений, в том числе и российских, которые тогда вовсю начинали переживать свои не лучшие времена (продолжающиеся по сей день). Можно сказать, что NeXT «ушёл на дно, не опуская флаг»...

Интерфейс операционной системы NeXTStep отличался, с одной стороны, функциональностью, с другой – элегантностью, так с тех пор и непревзойдённой (на мой взгляд). И потому он послужил сначала образом для подражания в виде целой линии оконных менеджеров. Первым из них стал AfterStep, разрабатываемый с 1996 года. Он был основан на коде FVWM, но внешний вид его был приведён в соответствие с таковым NeXTStep. Казалось бы, процедура, аналогичная проделанной ранее с fvwm95 – однако результат был не сопоставимым. И, хотя AfterStep и не снискал большой популярности – он развивается до сих пор, и вокруг него сложилось небольшое, но преданное сообщество.

Отступление. Оконный менеджер AfterStep оказал влияние и на мир Windows: в 1997 году Франсис Гастеллу (Francis Gastellu) разработал его клон для платформы Win32 – LiteStep. Первоначально он настолько точно воспроизводил внешний вид прототипа, что невозможно было поверить в существование лежащей под ним банальной Windows 95/98. В дальнейшем он эволюционировал в сторону конструктора, позволяющего воспроизвести поверх Windows разного рода (в том числе и линии NT/2000/XP etc.) интерфейс любой рабочей среды для Иксов или создать интерфейс собственный. Оболочка LiteStep активно развивается по сей день: в частности, в ней реализована и поддержка Windows 8. Насколько широко она используется «записными подоконниками» – судить не берусь. Но ряд лично знакомых мне линуксоидов активно применяли её во время вынужденной работы в Windows.

Если AfterStep имел в своей основе код FVWM, то второй последователь NeXTStep, WindowMaker, разрабатывался «с нуля» Альфредо Коджимой (Alfredo Kojima), начиная с 1997 года. И первоначально этот оконный менеджер предназначался для кросс-платформенной среды GNUstep – попытке свободного воспроизведения OpenStep, того самого нерождённого дитяти от союза NeXT и Sun, которое поминалось выше.

Сама среда GNUstep угодила в долгий ящик – время от времени появлялись только её реализации на ядре Linux (что, впрочем, было свойственно всем амбициозным проектам, до которых антилопа GNU дотягивалась своими копытами). А WindowMaker же, как оконный менеджер для Иксов, вследствие своих несомненных достоинств (элегантность и, при некоторой привычке, удобство интерфейса, быстрота, нетребовательность к ресурсам) быстро завоевал заслуженную популярность.

Не последнюю роль в распространении WindowMaker’а сыграло то, что изначально он включал в себя утилиту настройки, работавшую в графическом режиме: необходимости в ручной правке конфигов больше не было. Хотя и запрета на неё тоже не налагалось. Кроме того, для него был разработан и комплекс служебных программ, что знаменовало первый шаг в направлении интегрированных десктопов (правда, дальнейших шагов в эту сторону не последовало – WindowMaker так и остался менеджером окон).

В нынешнем тысячелетии WindowMaker несколько захирел. В том числе и потому, что, когда всё прогрессивное человечество начало в массовом порядке переходить на UTF8, долгое время оставался верен восьмибитным кодировкам. Правда, в середине нулевых годов вышел релиз 0.95.0 с поддержкой юникода – но затем многие годы о WindowMaker'е не было слышно ничего. По традиции он входил в штатный набор графических сред ряда дистрибутивов, присутствовал в их репозиториях, официальных или дополнительных, но о былой популярности его говорить не приходилось.

Казалось, что WindowMaker обречён на тихую и незаметную кончину. Как вдруг случилось чудо: в январе 2012 года новой командой разработчиков было объявлено о реанимации проекта и выходе нового релиза – 0.95.1. А вслед за тем очередные версии этого оконного менеджера начали выходить регулярно – последняя на сегодняшний день (0.95.5) датируется августом 2013.

Начинание разработчиков этого оконного менеджера получило поддержку со стороны майнтайнеров некоторых дистрибутивов. И в начале июня 2013 года свет увидел LiveCD на базе Debian'а, в котором WindowMaker выступает в качестве рабочего окружения.

А в период стагнации WindowMaker оказал несомненное влияние на две самых модерновых рабочих среды современности: режьте меня на куски, но идея больших объёмных кнопок на панели запуска приложений вдоль боковины экрана в Unity и GNOME Shell ведёт своё начало от него. Хотя разработчики обеих сред не любят говорить об этом вслух. И, дабы окончательно обрубить концы преемственности, переместили эту панель справа (где она имела место быть в WindowMaker'е по умолчанию) налево.

Линия боксов

В основе интерфейса всех оконных менеджеров, о которых говорилось в предыдущей статье, лежал какой-нибудь прототип, «родной» (как первозданный twm) или пришедший из «другого мира» (Windows, NeXTStep). Однако в семействе их имеется линия абсолютно оригинальная – по крайней мере, прообразов для неё я не видел никогда и нигде. Это – линия так называемух *kbox'ов.

Прародитель семейства, Blackbox, был разработан Брэндли Хьюгсом (Bradley Hughes) в 1997 году как своего рода неявный ответ на IceWM: то есть как ещё боле лёгкий с точки зрения потребления ресурсов, ещё более минималистичный по своему интерфейсу, ещё более простой в настройке и использовании, не несущий к тому же никаких следов чужеродного воздействия. Иными словами – истинное воплощение True UNIX GUI в превосходной степени.

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

Blackbox быстро приобрёл популярность и, как следствие стал обрастать дополнениями в виде многочисленных тем рабочего стола и интерфейсных элементов (например, средства вывода запускающих пиктограмм на рабочий стол). Появилось и средство собственного конфигурирования – bbconf. Однако в нём самом, после первого периода «бури и натиска», фактически ничего не менялось, и всё по той же причине, которая вызвала «захирение» многих свободных проектов: что-то кардинально улучшить без смены парадигмы в нём было уже невозможно. А смена парадигмы привела бы к тому, что Blackbox перестал быть самим собой.

В результате в первой половине нулевых годов развитие этого оконного менеджера прекратилось – последняя его версия (0.70.1) на официальном сайте датируется ноябрём 2005 года. Однако сам по себе он не умер: майнтайнеры большинства популярных дистрибутивов держат его в своих официальных репозиториях, заодно поддерживая совместимость его с новыми версиями библиотек (благо зависимостей у Blackbox'а не мало, а очень мало).

Продолжал развиваться Blackbox и другим образом – в виде своих потомков. Из них до сего дня дожили два – Fluxbox и Openbox. Оба они в целом сохранили минималистический интерфейс родителя, но обогатили его некоторыми новшествами. Для Fluxbox'а (чистого клона Blackbox'а), возникшего на рубеже тысячелетий, главным из них была возможность объединения совместно используемых приложений (например, терминала, текстового редактора и браузера) в «группы по интересам». И перемещаться внутри них с помощью закладок – уже настоящих табов, а не тех их прототипов, что были в twm. Кстати, особенность эта до сих пор остаётся уникальной не только для оконных менеджеров, но и для десктопов.

Появившийся несколько позже (в 2002 году) Openbox также поначалу был клоном Blackbox'а, то есть основывался на его кодовой базе. Однако затем он был переписан на чистом C (Blackbox и Fluxbox написаны на C++), чем приобрёл самобытность, хотя и сохранил минимализм интерфейса предтечи. Однако главная составляющая его самобытности – это графическое средство конфигурирования, ObConf. Оно обеспечило ему место оконного менеджера в рабочей среде LXDE, у которой с собственными средствами настройки была (и сохраняется до сих пор) некоторая напряжёнка. Но об этом – в следующей главе.

И всё же ещё минималистичней...

Казалось бы, интерфейс минималистичней, чем у Blackbox'а, придумать трудно. Но предела совершенству нет ни в каком направлении – ни в усложнении, ни в упрощении. Что мы сейчас и проиллюстрируем.

Был некогда такой оконный менеджер – wm2 (что расшифровывалось просто – Window Manager 2). Разработанный Крисом Каттамом (Chris Cannam) в 1996 году, он отличался не просто простотой, а, я бы сказал, простецкостью. Ибо обеспечивал только перемещение окон, изменение их размера, скрытие и закрытие. Никаких других функций у него не было – ни виртуальных десктопов, ни средств запуска приложений, ни иконок, ни инструментов конфигурирования (кажется, и параметров конфигурирования не было тоже). И потому вид его был предопределён изначально. В частности, фирменной особенностью его была вертикальная ориентация строки заголовка.

Вероятно, автору этих возможностей (или, скорее, невозможностей) хватало. А вот Биллу Спитзаку (Bill Spitzak) – нет, хотя ему также были близки идеи минимализма и нравилась вертикальная ориентации строки заголовка. И потому он добавил в wm2 необходимые функции – расширенные средства управления окнами, средство запуска приложений из контекстного меню рабочего стола, поддержку виртуальных десктопов в неограниченном количестве. В результате чего получился FLWM (Fast Light Window Manager).

Появилось в FLWM и средство конфигурирования контекстного меню запуска программ, не требующее даже правки конфигурационных файлов. Достаточно было в каталоге ~/.wmx/, создать подкаталоги, соответствующие пунктам меню любой желаемой структуры (до десяти уровней вложенности). И поместить в них символические ссылки на исполняемые файлы необходимых приложений. После чего в контекстном меню появляются новые пункты.

Последняя авторская версия FLWM (1.02) датируется 2006 годом. Однако заложенные в нём идеи минимализма получили дальнейшее развитие в самом минималистичном дистрибутиве Linux – Tiny Core, включающем его версию, усовершенствованную разработчиком последнего, Робертом Шинглдекером (Robert Shingledecker). Именно в таком виде FLWM входит в репозитории ряда дистрибутивов (например, openSUSE и Ubuntu).

Оступление. В начале этой главы я писал, что работать в Иксах без оконного менеджера практически невозможно. Однако некогда это было не совсем так. Офисный пакет StarOffice позволял обходиться без всяких управителей окон – достаточно было обеспечить автоматический запуск терминала при старте иксового сеанса, а уже из его командной строки вызвать Desktop Manager этого офисного пакета. Который обеспечивал все необходимые средства управления окнами – правда, только для входящих в него приложений, то есть текстового процессора, электронной таблицы и так далее. С окнами любых других программ StarOffice Desktop Manager работать не умел. Но не это ли вековечная мечта любого руководителя – чтобы его сотрудники всё своё рабочее время занимались работой, а не играли бы в игры, слушали музыку и сидели в социальных сетях?

Способность работать без оконного менеджера была унаследована и первыми, после обретения свободы, версиями OpenOffice, но этот куплет – уже из другой песни.

Управители тайлингом

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

К тому же массовый приток новых пользователей из мира Windows (потому что больше им просто неоткуда было браться) вызвал снижение интереса к оконным менеджерам вообще – наступала эра интегрированных графических сред, выглядевших для мигрантов-«подоконников» более привычно. Да и линуксоиды первых призывов, вдоволь наигравших с редактированием конфигов и rc-файлов, всё чаще причаливали в тихой десктопной гавани. А оконные менеджеры всё больше становились инструментом энтузиастов.

Однако энтузиасты, как известно, потому так и называются, что ко всему относятся с энтузиазмом. В том числе и к интерфейсам. Им стало скучно в очередной раз реконфигурировать box'ы и FLWM'ы. И в первой половине нулевых годов они придумали новую парадигму управления окнами – тайлинг, реализовав её к их середине в виде многочисленных тайловых (или фреймовых) оконных менеджеров.

В основе тайловых менеджеров лежит та же идея, что и у консольной утилиты screen: расщепление на ряд независимых областей (фреймов), подобное покрытию пола кафелем (tiling), в каждой из которых запускается какое-либо приложение. Собственно, к программам этой группы понятие «оконный менеджер» применимо достаточно условно: они обеспечивают управление не столько окнами, сколько теми самыми областями экрана, в которых эти окна открываются. Каковое может быть статическим, с жёстко определёнными размерами фреймов, и динамическим, при котором размеры фреймов изменяются при масштабировании окон запущенных в них приложений.

Распространение больших широкоформатных LCD-мониторов сделало идею тайлинга очень актуальной, и тайловые менеджеры получили широкое распространение. А элементы тайлинга были задействованы и в некоторых интегрированных средах (Xfce, Unity, особенно активно – в Cinnamon'е). Однако я тайловых менеджеров практически не использовал – для моих задач больше походит принцип «один десктоп – одно окно». Так что описать их историю не могу – надеюсь, что кто-нибудь из знатоков и любителей тайловых менеджеров восполнит пробел в моём историческом обзоре.

Заключение

Подводя итог истории оконных менеджеров, процитирую великого русского поэта А.К. Толстого:

«К чему твоя баллада?» Иная спросит дева. – О жизнь моя, о лада, Ей-ей, не для припева!

Так вот, и я сочинил обе заметки на заданную тему, дабы чтобы развеять одно распространённое заблуждение: будто бы разработчики графических интерфейсов Иксов только и делали, что заимствовали и копировали решения из Windows и операционных систем для Macintosh'а (мало кто нынче помнит, что до появления MacOS X они назывались очень просто – System с добавлением номера версии).

Дело обстояло как раз наоборот: если не считать общих корней GUI, произраставших из Xerox PARC, все остальные атрибуты современных графических интерфейсов, представляющиеся сейчас самоочевидными, впервые получили распространение именно в оконных менеджерах для X Window System. Это и активное использование всех трёх кнопок мыши, и множественные виртуальные рабочие столы, и виртуальное разрешение экрана, и управляющие панели, и контекстные меню, и многое другое. В послужной список Windows можно вписать только сомнительную честь изобретения кнопки Пуск. А к вящей славе Mac'овских систем всегда служило не создание новых парадигм, а умелая и успешная реализация существующих.

В настоящей главе мы поговорим об истории комплексов программ, задумчиво именуемых интегрированными, или графическими, рабочими средами, они же – окружения (по английски – Graphic, или Intergated Desktop Environment). Впрочем, в народе их величают гораздо короче – просто декстопами или даже аббревиатурой DE.

Вступление

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

Средства конфигурирования десктопов изначально работали в графическом режиме, прямое редактирование настроек в них требовалось лишь в исключительных случаях. Ибо, вспоминая словам маршала Ланна, можно сказать, что GUI, который не может настроить себя своими GUI'ёвыми средствами – не GUI, а... нехорошее слово.

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

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

... губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколь-нибудь развязанное, какая у Балтазара Балтазаровича, да, пожалуй, прибавить к этому ещё дородности Ивана Павловича…

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

Предыстория десктопов

Разумеется, в этой статье будет говориться только о тех десктопах, которые работают в открытых и свободных UNIX-подобных системах, и сами принадлежат к миру FOSS. И потому за точку отсчёта времени в истории интегрированных сред можно принять осень 1996 года – начало работы Маттиаса Эттриха (Matthias Ettrich) над средой KDE. Однако рассмотрение предыстории вопроса опускается куда глубже, в недра проприетаризма.

Отдалённым прототипом современных интегрированных сред были первые, ещё до-иксовые графические интерфейсы фирмы Sun – SunView (Sun Visual Integrated Environment for Workstations, изначально SunTools), затем NeWS (Network extensible Window System) и, наконец, OpenWindows, о которых я упоминал в главе про историю Иксов. Они предназначались для операционной системы SunOS – фирменного варианта UNIX: именно здесь впервые была реализована идея интеграции операционной системы, GUI и пользовательских приложений, получившая дальнейшее развитие не только в мире UNIX, но и далеко за его пределами.

Именно графические интерфейсы, пришедшие из совершенно других миров – не UNIX'овых и не свободных, миров OS/2, Macintosh'а и Windows, оказали определяющее влияние на десктопы, о которых вскоре пойдёт речь.

Ныне мало кто помнит, но OS/2 не включала графический интерфейс пользователя как непременный атрибут операционной системы, однако обладала оригинальной и весьма совершенной графической оболочкой, Presentation Manager, позднее Workplace Shell (WPS). Она отличалась исключительной аккуратностью и вылизанностью, благодаря чему и послужила образцом при создании первого собственно Иксового десктопа – среды CDE.

Среда CDE (Common Desktop Environment) была разработана в 1993 году под эгидой The Open Group и при участии Hewlett-Packard, IBM, Novell и Sun. Она основывалась на библиотеках Motif и включала в себя оконный менеджер VUE (или HP-VUE – Visual User Environment), ранее применявшийся в HP-UX. Она быстро стала стандартным графическим интерфейсом для всех проприетарных UNIX'ов.

Как легко догадаться, CDE (как и лежащие в её основе библиотеки Motif) не была ни свободной, ни открытой. Именно потому влияние её на дальнейшее развитие десктопов, за единственным исключением (и, разумеется, самой идеи интеграции), оказалось не очень большим. Не изменило ситуации и открытие в начале десятых годов исходников и Motif'а, и CDE, ибо состоялось оно по принципу: возьми, боже, что мне не гоже. В то время, когда DOSS-десктопы давно превзошли своего первопредка и по функциональности, и по удобству.

Отступление. Среда CDE основывалась на библиотеке Motif – в те времена стандартном наборе для графических интерфейсов проприетарных UNIX. На нём же основывалось и множество приложений графического режима, некоторые из них были открытыми. Но, поскольку сами библиотеки были закрытами, свободными эти приложения быть не могли.

Поэтому был изобретён свободный аналог – библиотека OpenMotif. Правда, функционально обеднённый – и не все Motif-приложения могли быть с ним собраны.

В дальнейшем, уже в начале текущего десятилетия, и библиотека Motif, и среда CDE были последовательно открыты для народа. Но к тому времени они вышли из моды, морально устарели, и казалось что народу не нужны. Однако буквально в то время, как в эту книгу вносилась последняя правка (1 марта 2014 года), мир облетела весть о выходе первой, со времён открытия исходников (и, следовательно, первой свободной), версии CDE, за номером 2.2.1. Пока она доступна только в виде исходников, адптированных, как говорят разработчики, для сборки в любом дистрибутиве Linux или BSD-системе. Что из этого получится – поживём, увидим.

Ранние версии Windows, с версии 1-й по 3.X, представляли собой обычные графические псевдомногозадачные надстройки над DOS, хотя нынче об этом и не любят говорить вслух. Имя графическим DOS-надстройкам тогда было – легион: достаточно вспомнить такие среды, как GEM (много лет служившую для запуска Ventura Publisher), DesqView, GEOS и GeoWorks. И это не говоря уже о том, что многие популярные приложения, вроде Lotus 123, QuattroPro или WordRerfect, располагали собственными графическими оболочками. Влияние этих Windows за пределами своего мира также было невелико. Звёздный час Windows наступил в 1995 году, с выходом версии его имени. Но к этому вопросу мы ещё вернёмся.

В отличие от OS/2 и DOS/Windows, операционная система Macintosh'а, именовавшаяся в те времена просто и скромно – System 4, 5, 6 и так далее, – изначально в качестве неотъемлемого компонента включала в себя графическую среду, неотделимую от собственно операционки. На десктопы свободных UNIX-подобных систем она поначалу оказала влияние сугубо косвенное. Хотя и в те времена, как и по сей день, выступает в качестве своего эталона графического интерфейса пользователя.

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

Воистину судьбоносным в истории графических сред стал август 1995 года – момент выхода Windows 95. Именно в ней впервые появляется центральный элемент большинства графических интерфейсов последующих лет – сакраментальная кнопка Start (она же Пуск), располагающаяся на главной управляющей панели и вызывающая каскадное меню приложений.

Справедливости ради надо отметить, что прообраз этой кнопки, нёсший на себе изображение надкусанного яблока, появился в Macintosh'евских System. Управляющая панель в Windows 95 также в значительной мере унаследована от графической среды Macintosh'а, хотя нельзя исключить и влияние ранних оконных менеджеров Иксов. Наконец, из Иксов же, прямо или косвенно, в «девяностопятке» заимствуется идея контекстных меню рабочего стола.

Я надеюсь, никто не заподозрит меня в излишних симпатиях к Самой Великой ОС всех времён и народов. Однако, вопреки расхожему мнению, я не склонен считать, что разработчики Windows 95 взяли и просто так потибрили все перечисленные компоненты откуда бы то ни было. Во-первых, многие из них восходят к далёким временам экспериментальных графических интерфейсов, разрабатывавшихся в Исследовательском центре Пало-Альто компании Hewlett-Packard (PARC) и оказавших огромное влияние на все последующие графические системы и среды без исключения.

Во-вторых, интеграция всех указанных компонентов в виде, доступном для восприятия тем самым пресловутым простым пользователем, о котором так любят говорить и в проприетарной сфере, и в мире FOSS – это неоспоримая заслуга разработчиков Windows 95.

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

Рождение KDE

Не стал исключением и Маттиас Эттрих – создатель первого интегрированного десктопа для свободных UNIX'ов, когда он в 1995 году приступил к разработке KDE. Маттиас, в то время студент университета в Тюбингене, уже приобрёл известность как разработчик LyX – системы компьютерной вёрстки, которую с некоторой условностью можно считать надстройкой над TeX. И первые шаги по сбору команды для работы над KDE он предпринял в списках рассылки своего проекта.

Согласно легенде, Эттрих занялся разработкой интегрированного десктопа – делом тогда ещё новым и неосвоенным, для того, чтобы его девушка чувствовала себя в Linux'е так же комфортно, как и в Windows 95, к которой она, видимо, успела привыкнуть.

Так что, создавая KDE, Эттриху пришлось включить в неё и управляющую панель в стиле Windows 95, и кнопку Start. Однако было бы неправильно считать, что он тупо скопировал интерфейс Самой Великой ОС, о чём любят говорить несознательные (или неосведомлённые) граждане. Ибо гораздо больше в интерфейсе KDE было унаследовано от старых добрых оконных менеджеров для Иксов. В ней были и развитая система контекстных меню, и множественные виртуальные декстопы.

Как мы помним по прошлой главе, про оконные менеджеры, всё это в совокупности имело место быть и в оконных менеджерах, воспроизводивших внешность Windows 95, таких, как FVWM95 и IceWM. Однако в KDE имелось и кое-что ещё, и кое-что другое, а именно – набор штатных приложений. Набор этот включал в себя файловый менеджер kfm в стиле пресловутого Windows Explorer, эмулятор терминала konsole, сразу два текстовых редактора – KEdit типа Notepad'а и более «продвинутый» KWrite. Все эти приложения имели интерфейс в едином стиле, хорошо вписываемый в среду.

Отступление. Как показывают многочисленные вопросы на форумах, нынче мало кто помнит расшифровку названия KDE. А расшифровывалась эта аббревиатура очень просто: Kool Desktop Environment. Впрочем, это не прибавляет ясности и помнящим те времена почти былинные. Ибо никто так и не знает, что же вкладывалось создателем в слово Kool – его нет ни в английском языке, ни в немецком. Разве что если воспринимать его как попытку записать по немецким правилам английское слово Cool? Намёки на что можно найти в ранних обзорах этой среды.

Видимо, разработчики быстро поняли это, и ныне литера K в имени этого десктопа не означает ничего, кроме самой себя. То есть его название можно перевести на русский язык как «Рабочее окружение некоего гражданина K» – и не более того.

Самое же главное – в KDE имелось средство тотальной настройки, KDE Control Center (KCC), позволяющее настраивать параметры как самой среды, так и всех штатных приложений – этого в столь интегрированном виде ни у одного из оконных менеджеров для Иксов тогда не было и в помине.

Отступление. В традициях раннего KDE было называть все приложения для неё именами, начинающимися с заглавной буквы K, или, в редких случаях, ею оканчивающихся. В случае с эмулятором терминала это послужило основанием для многолетней путаницы, продолжающейся по сей день.

KDE создавалась как среда не исконно немецкая, а интернациональная, и потому имела английский интерфейс. По английски тектовая консоль, или виртуальный терминал (console) и терминальная программа из KDE (Konsole) пишутся несколько по разному. По немецки же они пишутся абсолютно одинаково (konsole) и столь же одинаково произносятся. Кстати, в русском языке ситуация аналогичная.

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

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

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

Всё это было очень логично организовано в несколько «авторских» пакетов, таких, как kdelibs – библиотеки, дополняющие основополагающую библиотеку Qt, kdebase – базовые приложения среды, kdenetworks – сетевые средства, kdemultimedia очевидного назначения, kdeartworks – набор украшательств, и так далее. А вскоре для KDE был создан даже офисный пакет KOffice, развиваемый и поныне под именем Calligra.

Среда KDE, как и все её приложения, основывалась на библиотеках Qt, разработанной незадолго до этого (также в 1996 году) норвежской фирмой Trolltech. Библиотека эта распространялась с открытыми исходниками, но не была свободной в понимании GNU/FSF. Ибо имела две версии – платную для коммерческого использования и бесплатную – для использования некоммерческого. Последняя и была положена в основу KDE и её собственного набора библиотек – kdelibs.

Не вполне свободный характер библиотеки Qt и послужил завязкой всего последующего сюжета, стержнем которого стало противостояние KDE и GNOME. Не смотря на то, что вскоре (осенью 1998 года) некоммерческий вариант Qt/X11 стал распространяться под лицензией GPL, работа над GNOME уже началась. Так что если бы Эттрих выбрал бы для своего десктопа любую другую библиотеку (а дальнейшие события показали, что он сделал лучший выбор), был бы найден более иной повод для создания «истинно свободной» интегрированной среды.

На самых ранних стадиях разработки KDE вокруг проекта собралась небольшая, но сплочённая группа товарищей, в основном вполне студенческого возраста. Они создали и некоммерческую организацию KDE e.V. (eingetragener Verein – зарегистрированное объединение, по немецки), уставной фон для которой набрали из карманных денег. И, как свидетельствуют очевидцы, например, один из соучередителей, Маттиас Далхаймер (Matthias Kalle Dalheimer), процесс разработки KDE проходил весьма весело, в лучших традициях университетских буршеншафтов.

К слову, Маттиас Далхаймер в те далёкие годы работал в фирме Star Division – той самой, в которой разрабатывался кросплатформенный офисный пакет StarOffice, предшественник современных OpenOffice и LibreOffice. И занимался он там как раз его портированием на Linux – исходно тот был предназначен для OS/2. Но эту историю я расскажу как-нибудь в другой раз.

А ещё Маттиас – один из авторов последних изданий знаменитой книжки «Запускаем Linux» (Running Linux).  Написанная в 1995 году Ларом Кауфманом (Lar Kaufman) и Мэттом Уэлшем (Matt Welsh), она, обрастая соавторами, за десять лет выдержала 5 изданий. И стала настольной книгой многих поколений линуксоидов, как начинающих, так и действующих.

KDE – в жизнь

Вследствие не вполне свободного характера библиотеки Qt, основанная на ней среда KDE была настороженно принята столпами дистроения, в первую очередь ревнителями идеологической чистоты, такими, как Debian и Red Hat.

Так что поначалу KDE самостоятельно собиралась исключительно энтузиастами в рамках более иных дистрибутивов. Однако звёздный час её был недалёк: в июле 1998 года выходит первая версия первого по настоящему юзерофильного дистрибутива – Mandrake Linux, потомком которого является современная Mandriva и ряд её дериватов.

Первая версия Mandrake, как ни странно, носила номер 5.1, ибо представляла собой достаточно точный клон Red Hat 5.1, появившегося на свет незадолго до того, весной 1998 года (кажется, с тех пор и пошла традиция для клонов – наследовать номера версии прародительской системы). Но её «юзерофилия» как раз и заключалась в том, что она штатно включила в себя среду KDE с её штатными приложениями, в том числе графическими и мультимедийными.

Более того, среда KDE была в первом Mandrake десктопом по умолчанию. А сам дистрибутив этот оказался первым, вообще получившим умолчальный десктоп. Ранее такого понятия просто не существовало – и тому было много причин, одна из которых – отсутствие свободных десктопов вообще (оговорки на счёт Qt будем считать юридическим крючкотворством, тем более что и повод для них скоро пропал).

Вслед за Mandrake, осенью 1998 года, среда KDE в качестве умолчальной была включена в версию 5.3 SUSE. И с тех пор судьба обоих этих дистрибутивов оказалась тесно с ней связанной. Хотя, разумеется, ни в том, ни в другом KDE не был единственным десктопом, да и простыми оконными менеджерами они не оскудели. Но, как говорится, оба они «затачивались» в первую очередь под KDE.

А затем, на рубеже тысячелетий, поднялся первый вал «Linux'ов с человеческим лицом», или, точнее, первых систем быстрого развёртывания, начиная со StromLinux'а. За которым последовал вал второй – VectorLinux, MEPIS и другие, ряд которых существует и сегодня. И во всех этих системах в качестве десктопа, теперь уже не просто умолчального, а единственного штатного, задействовалась среда KDE. Хотя в то время она была уже не единственным представителем своего класса, имелись и альтернативы, о которых пойдёт скоро пойдёт речь.

Среда для холериков

Как было только что сказано, к рубежу тысячелетий доминирование KDE в ряду графических интерфейсов свободных UNIX-подобных систем. Однако KDE существовало не в безвоздушном пространстве, в чём мы сейчас и убедимся.

Буквально через несколько месяцев после выхода KDE, появляется среда XFce. Говорят, что первоначально название её расшифровывалось как XForms Common Environment – разделяемая среда на библиотеке XForms. К тому времени, как я её впервые увидел, та же аббревиатура трактовалось как The Cholesterol Free Desktop Environment – «обезжиренный» свободный десктоп. Хотя мне больше нравилась трактовка названия как среды для холериков – её действительно отличала не просто быстрота реакции на действия пользователя, но именно порывистость. Однако давно уже в Xfce не осталось и следов от библиотек XForms, да и того взрывного впечатления, как некогда, она уже не производит. Так что, подобно большинству аббревиатур FOSS-мире, ныне Xfce не расшифровывается никак.

Среда Xfce была создана французом Оливером Форданом, и не столько под впечатлением и по примеру KDE, сколько как попытка создания свободного аналога CDE. И в интерфейсе её ранних версий чётко прослеживается влияние первой рабочей среды UNIX'ов.

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

Среда Xfce основывалась на наборе библиотек XForms весьма сложного происхождения, но восходившем в конечном счёте к IRIS GL, проприетарной графической библиотеке компании Silicon Grahics (ныне SGI). Да и сама XForms в то время не была свободной, а только лишь бесплатной для личного некоммерческого использования (настоящую свободу в понимании FSF она обрела годы спустя). И потому отношение к ней дистроителей было не менее настороженным, нежели к KDE. То есть её существование игнорировалось и Red Hat'ом, и Debian'ом. А поскольку по своей функциональности Xfce не намного превосходила развитые оконные менеджеры, то и большого интереса энтузиастов она тоже не вызывала.

Отчётливо маргинальное положение занимала среда Xfce во время жизненного цикла своей 1-й и 2-й версии. Версию же 3-ю Фордан весной 1999 года полностью переписал с использованием библиотек Gtk – тех самых, которые, как мы скоро увидим, перед тем легли в основу среды GNOME. В результате этого «освобождения» Xfce стала включаться как дополнительный десктоп в ряд дистрибутивов, в частности, в ту же Mandrake и её русскую редакцию. Однако дистрибутива, в котором она выступала бы десктопом по умолчанию, не существовало вплоть до середины нулевых, когда появились первые «лёгкие» системы быстрого развёртывания, такие, как Zenwalk, в которых она пришлась очень ко двору. Но это уже переход к следующему этапу нашей истории.

А пока – несколько слов об Xfce версии 3. Именно в отношении её название среды трактовалось «с холерическим уклоном» – и к тому были все основания. Она работала чрезвычайно быстро и, так сказать, «импульсивно». Ощущение это передать словами почти невозможно, но оно осталось незабываемым – больше нигде и никогда мне такого испытать не довелось.

Да и интерфейс её тогда сильно отличался от уже примелькавшихся к тому времени KDE и GNOME, не обнаруживая ни малейшего намёка на «Windows-подобие», и скорее вызывая в памяти WPS из OS/2 эпохи «Кривого Мерлина».

Завершая этот раздел, ещё раз подчеркну: появление Xfce не оказало большого влияния на мир рабочих сред для свободных UNIX-подобных систем. Ибо ось развития их проходила по линии противостояния KDE, о котором уже шла речь, и GNOME, к рассмотрению истории которого мы сейчас перейдём.

Disclaimer, он же – отмазка. Однако прежде чем перейти к истории GNOME я должен принести слова покаяния. Настоящая книга, как неоднократно декларировалось, написана, по мере возможности, в соответствие с заветом Тацита – «без гнева и пристрастия». Один раз, в главе девятнадцатой, я уже отступил от этого завета. И ныне вынужден сделать это вторично.

Ибо, когда речь заходит о среде GNOME, мне этого завета придерживаться трудно. Разумеется, никакого гнева против этого десктопа я не испытываю. Нет и особого пристрастия или противострастия – одно время я даже был его пользователем. А все предыдущие годы честно (хотя и безуспешно) пытался найти те самые его несравненные достоинства, о которых столько говорили его приверженцы.

Нет, речь идёт не о гневе или пристрастии, а скорее о чувстве недоумения: почему такая эклектическая, неорганизованная и даже не очень оригинальная в идейном плане среда завоевала столь широкую популярность. Разумеется, к тому были некоторые объективные предпосылки, о которых я скажу по ходу дела. Но во главе угла всё-таки стоял субъективный фактор – тот самый, который можно назвать кредитом доверия пользователей. И который, как мы увидим, оказался фактически безграничным, хотя разработчики GNOME раз за разом подвергали его испытанию на прочность. Причём таким, на какие не решалась даже компания Microsoft, чья Windows даже на заре своего существования имела несоизмеримо большую пользовательскую базу.

В общем, говоря об истории GNOME, мне очень трудно сохранять объективность – что и прошу учитывать читателя.

Радетели свободы

Однако вернёмся к истории. Пока и KDE, и Xfce базировались на не вполне «идеологически выдержанных» библиотеках, истинные радетели свободы готовили удар по проприетаризму. Во главе этих радетелей встали Мигель де Икаса (Miguel de Icaza) и Федерико Мена-Кинтеро (Federico Mena-Quintero), основавшие в 1997 году проект GNOME (GNU Network Object Model Environment). Его можно рассматривать как ответ «твёрдых искровцев»... пардон, истинных Freesoftware'овцев прихлёбным плюралистам из проекта KDE.

Целями проекта, насколько можно понять замысел его создателей, были (в порядке убывания приоритетов):

   1. создание полностью свободной, в терминах FSF, интегрированной рабочей среды;

   2. создание интегрированной среды, не похожей ни на одну из существующих сред;

   3. создание интегрированной среды, доступной для всех пользователей, вне зависимости от уровня их технической подготовки.

Достижение первой цели требовало выбора соответствующей библиотеки, на которой базировалась бы новая среда. А единственной по настоящему свободной графической библиотекой в то время была базовая xlib из штатной поставки XFree86, функционала которой для построения интегрированного десктопа было явно недостаточно. Более развитые же библиотеки, о которых я упоминал – Motif, XForms, Qt, – имели те или иные ограничения в использовании распространении.

И тут на помощь пришёл случай. Начиная с 1995 года Спенсером Кимбеллом и Питером Маттисом велась разработка растрового графического редактора, который получил название GIMP, что первоначально означало General Image Manipulation Program (буковка G приобрела значение GNU в 1997 году, года эта программа удостоилась чести войти в данный проект).

В ходе своей работы авторы программы столкнулись с острой потребностью в высокоуровневой графической библиотеке. Каковую они и создали, назвав её Gtk – GIMP ToolKit. Её первая стабильная версия была выпущена весной 1998 года под архисвободной лицензией LGPL. Библиотека эта создавалась с вполне конкретной, и достаточно узкой, целью. И в этом качестве она показала себя самым лучшим образом. Но как основа для интегрированной среды она не планировалась. Однако требование свободы оказалось сильнее технологических соображений, да и выбора-то особого у создателей GNOME не было: все остальные высокоуровневые графические библиотеки (Motif, Xforms, Qt) в то время несли на себе пятно тлетворного влияния проприетаризма. И это наложило отпечаток на всё дальнейшее развитие среды.

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

Так что третья цель – создание простой в использовании рабочей среды – по уровню приоритености оказалась где-то тридцать третьей. Да, первая версия GNOME, вышедшая весной 1999 года, была фантастически красива, загружаясь с заставкой в виде анимированного театрального занавеса. Вот только настраивать её было не очень просто. Да и до настройки обычно дело не доходило. Ибо среда эта в те годы хорошо умела делать только одно: свопировать саму себя на винчестер. По крайней мере, при работе в GNOME индикатор его активности обычно не гас ни на мгновение.

Тем не менее, GNOME получил активную поддержку со стороны дистроителей – тех самых, которые в штыки встретили KDE и просто проигнорировали Xfce. Практически сразу после выхода первого релиза он становится десктопом по умолчанию в Debian'е (март 1999 года) и в Red Hat'е (апрель 1999 года). Не побрезговали им и разработчики Mandrake, включив GNOME в качестве опциональной рабочей среды – именно в составе русской редакции этого дистрибутива я и пытался ознакомиться с его первыми версиями.

Однако, насколько я могу судить, объявление GNOME умолчальным десктопом в Debian'е и Red Hat'е было скорее теоретическим (или, если угодно, политическим). Среди лично мне знакомых в те годы дебианистов и редхатчиков пользователей этой среды я не припоминаю. Ну а в Mandrake он вообще присутствовал для галочки – чтоб было. И причина была в практической непригодности GNOME к реальному применению. Именно в те годы и родилось высказывание:

KDE разработали обычные программисты для удобства собственного и пользователей. А GNOME создали крутые программеры для доказательства собственной крутизны.

Надо сказать, что в те годы для такого утверждения были все основания. Да и ныне, во времена GNOME 3 и GNOMESell, оно не выглядит совсем беспочвенным.

Великое противостояние

Разумеется, так продолжаться не могло: одно из знамён свободного софта практически не применяется его сторонниками. И разработчики GNOME вынуждены были, поступившись своей крутизной, пойти по пути упрощения.

Началось всё со смены оконного менеджера – место красивого, но непрактичного Enlightenment'а занял непритязательный, но пригодный к употреблению Sawfish. А поскольку собственного оконного менеджера у GNOME не было никогда, смена «управителей окон» с тех пор стала в этой среде традиционной.

Следующим шагом на пути упрощения стал выход 2-й версии GNOME, в которой простота настройки и использования были объявлены высшими приоритеами. А поскольку эталоном простоты в некоторых кругах в то время считалась Windows, в сети прозвучал лозунг:

Сделать GNOME большей Windows, чем сама Windows.

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

С другой стороны, KDE, при всех его многочисленных недостатках (а старым верным пользователям этого десктопа они были известны лучше, чем любым критикам), обладал тремя несравненными достоинствами:

   1. обильным функционалом в отношении управления окнами и приложениями;

   2. абсолютной настраиваемостью всего и вся;

   3. набором штатных приложений и приложений от примкнувших сторонних разработчиков.

За средства настройки KDE подвергалась критике. И местами справедливой: они были запутанными, интуитивно не очень понятными, настройки связанных, казалось бы, параметров, часто оказывались раскиданными по противоположным пунктам меню. Но они были – и охватывали абсолютно все опции системы. Причём всё это поддавалось конфигурированию штатными средствами: необходимости в ручной правке конфигов практически не возникало. Разве что, как это часто бывало в истории (и неоднократно повторялось впоследствии – в том числе и в GNOME), она требовалась при настройке русской раскладки клавиатуры и её переключателей.

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

Отступление. В шутке про изменение мира есть только доля шутки. Одна бывшая наша соотечественница, будучи уволенной из NASA чуть ли не по подозрению в шпионаже (в пользу русской мафии, надо полагать), в поисках работы обратилась в том числе и в GNOME Foundation. Где на собеседовании её спросили: хотите ли вы участвовать в изменении мира? Вопрос этот показался ей смешным, и в результате в этот самый фонд её не взяли. Пришлось идти на работу в маленькую заштатную конторку, которая тогда называлась (да и сейчас называется) Google. А после капитализации последнего пришлось стать очень богатой женщиной. Так что политика GNOME подчас благотворно отражается на судьбах людей, с ней соприкоснувшихся.

Не случайно все опросы, касающиеся используемого десктопа, приносили в те годы чистую победу KDE – и с большим, подчас двухкратным, перевесом. Правда, в таких опросах, как правило, не участвовали представители так называемого корпоратива, использующие, как правило, не тот софт, который хочется, а который прикажут. И потому картину эту нельзя считать совсем точной. Ибо с момента зарождения GNOME его интенсивно поддерживала самая мощная Linux-компания – Red Hat, в те годы бесспорный лидер корпоративного поля. А в 2003 году, после того, как фирма SUSE, выпускавшая одноимённый дистрибутив, была приобретена компанией Novell, за внедрение GNOME взялся игрок номер два. Ибо после расщепления этого дистрибутива на две ветки – коммерческую SLE (Suse Linux Enterprise) и развиваемую сообществом openSUSE, в первой как десктоп по умолчанию был принят GNOME.

Почему – можно только гадать: ведь, как уже говорилось в предыдущеразделе, именно SUSE была одним из основных оплотов KDE. В качестве одной из причин указывалось то, что незадолго перед тем Novell прикупила команию Ximian, занимавшуюся разработкой Mono – свободной реализации Microsoft .NET Framework. А поскольку основателем Ximian'а был Мигель де Икаса, технологии Mono были тесно завязаны на GNOME.

Не скидывая со счетов этого факта, можно предложить и более простое объяснение. Приобретя SUSE, Novell ориентировала коммерческую ветку этого дистрибутива на корпоративный сектор американского рынка. Где, как уже было сказано, главным игроком была компания Red Hat со своим RHEL (Red Hat Enterprise Linux) и его десктопом GNOME. Так что Novell просто пришлось равняться на конкурента.

Тем не менее, при несомненных успехах RHEL и SLE в корпоративном секторе, на пользовательских десктопах результаты их деятельности по продвижению GNOME были не очень заметны. А началом коренного перелома в этом продвижении стал конец 2004 года, когда в мировом масштабе развернулось распространение дистрибутива Ubuntu, в качестве рабочей среды по умолчанию использовавшей GNOME. Однако предпосылки этого перелома закладывались ещё ранее, году в 2002, в то время, когда Марк Шаттлворт только приступал к реализации своего проекта. И когда он принял судьбоносное решение – использовать в новом дистрибутиве не KDE, а GNOME.

О возможной причине этого я уже говорил в главе шестнадцатой. К сказанному там добавлю только одно. Настройка KDE усложнялась от версии к версии (пропорционально росту функционала), тогда как GNOME как раз в это время резко сменил вектор развития: как недавно было сказано, если его позиционировали как крутейший десктоп от крутейших программеров, то теперь было решено сделать простейший десктоп, который может настроить и кухарка. А поскольку Ubuntu ориентировался (в том числе и) на эту категорию пользователей, выбор GNOME представлялся вполне логичным.

Однако главным фактором для предпочтения GNOME, как мне кажется, было всё-таки стремление выделить Ubuntu из ряда развивавшихся тогда (и, как казалось, не без успеха) Систем Быстрого Равёртывания (СБР), в качестве десктопа использовавших KDE.

Так или иначе, но вследствие сочетания обоих факторов – массовой бесплатной рассылки дисков с Ubuntu и «упрощения» GNOME – началось широкое распространение последнего. Причём первый фактор был, безусловно, более весом: в ряды линуксоидов влилось свежее пополнение, которое ничего, кроме Ubuntu и GNOME, в глаза не видело, и для них эти понятия стали, по крайней мере по первости, тождественны понятию Linux. Однако и второй фактор нельзя сбрасывать со счетов: если бы GNOME показался неофитам слишком сложным, диски с Ubuntu были бы выброшены ими на помойку без всякого сожаления, ибо халява. Так что тогдашний расчёт Марка оказался точным. Хотя более поздние события показали неоднозначность его последствий.

От KDE 4 до GNOME 3

Следующее судьбоносное событие, повлиявшее на распределение пользователей по десктопам (или десктопов по пользователям?) произошло в начале 2008 года. Это был выход KDE 4.0.

Эта версия KDE разрабатывалась примерно столько же времени, сколько хватило, чтобы смениться KDE 1, KDE 2 и KDE 3. И в анонсах на ранних стадиях разработки обещались если и не золотые горы, то по крайней мере серебряные. В частности, там содержались толстые намёки на то, что KDE 4 будет обходиться без Иксов (хотя каким образом – не уточнялось). Правда, со временем анонсы становились всё скромнее (в частности, из них исчезло упоминание об отказе от X-сервера), но по прежнему оставались многообщещающими.

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

Надо сказать, что разработчики KDE 4.0 честно предупреждали, что эта версия предназначена ещё не для практического применения, а лишь для ознакомления с новыми возможностями и их тестирования. Но сделали они это достаточно невнятно, и майнтайнеры дистрибутивов дружно бросились включать её в свои новые релизы (обычно, правда, параллельно с предыдущей, 3.5.X). А пользователи, приняв всё это за чистую монету, столь же дружно стали «нулевую четвёрку» устанавливать.

Результат оказался более чем предсказуем. Поскольку было вполне очевидно, что дни 3-й ветки сочтены, начался массовый отток пользователей KDE на запасные аэродромы. Для кого им стал XFce, кто вернулся ко временам информационной юности – на менеджеры окон. Но немало бывших пользователей KDE попросило политического убежища в стане GNOME.

Отступление. Сейчас, по прошествии нескольких лет, становится понятно, что разработчики KDE почти всё сделали правильно. Допустив лишь одну маленькую тактическую ошибку: они обозвали релизом достаточно сырую тестовую версию. И никакие объяснения, что это не совсем таки настоящий релиз, не в силах были преодолеть магию Слова. Хотя, с другой стороны, не пойди KDE'шики на такой отчаянный шаг, разбудивший здоровую рабочую злость и пользователей-тестировщиков, и сторонних разработчиков – кто знает, может быть, 4-я версия KDE отлаживалась бы и по сей день в тестовом режиме.

Тут-то и выяснилось, что в GNOME образца 2008-2009 годов жить можно. Конечно, огорчал подход к конфигурированию среды, когда в интерактивном режиме был доступен лишь самый минимум, необходимый, по мнению разработчиков, «простому» пользователю, а для реализации более сложных (по их же представлениям) опций следовало лезть в нечто вроде реестра, ещё менее интуитивно понятного, чем опции настройки KDE, и гораздо более бедного. Видимо, разработчики GNOME руководствовались старым советским принципом:

Что позволено парторгу – не позволено бичу.

Поначалу удручало убожество убожество штатных приложений – например, Gedit'а в сравнении с Kate или Nautilus'а – в сравнении с Konqueror'ом старого образца. Однако в этом оказались и свои плюсы: в GNOME органично интегрировались любые сторонние приложения, основанные на Gtk. И Gedit для всамделишней работы легко заменялся Geany, а Nautilus – дополнялся PCManFM'ом. Кроме того, GNOME оказался органично интегрированным с такими дистрибутивами, как Fedora.

Так что на рубеже первых десятилетий нынешнего века между KDE и GNOME был достигнут примерный паритет. Хотя KDE и сохранял некоторое преимущество – за счёт а) стойких его приверженцев и б) энтузиастов новаторства. Тем более, что на месте эта среда не стояла, а постепенно допиливалась до юзабельного состояния, сама по себе, во-первых, и портированием на 4-ю ветку «трёшечных» приложений – во-вторых. Я, утратив в то время всякий интерес к KDE, не следил за этим процессом. Но, по слухам, примерно к версии 4.4 KDE стал вполне похожим на настоящий как сам по себе, так и в отношении своих штатных компонентов.

Тем не менее, отток пользователей от KDE казался необратимым, и GNOME утвердился с ним на одной ступеньке пьедестала почёта, может быть, ну на полступеньки ниже. Повторяю, заслуги самого по себе GNOME в приближении к вершине пьедестала были минимальны, ибо главные роли в этом спектакле сыграли уже упомянутые факторы – массовое распространение Ubuntu и ошибки команды KDE в продвижении новой версии своей среды. К этому надо добавить неожиданный рост популярности дистрибутива Fedora, тесно интегрированного с GNOME. Причём рост этот начался не благодаря GNOME, а скорее вопреки ему: многие пользователи готовы были смириться с этой средой ради достоинств самого дистрибутива. Который как раз в это время временно отказался от своей роли «тестовой площадки» коммерческого RHEL'а и обратился лицом к пользователю.

Отступление. Была и попытка реанимации KDE 3 в виде, привычном для пользователей этой ветки (и всех ей предшествовавших версий). Это – проект Тимоти Пирсона (Timothy Pearson) под названием Trinity KDE. Он представлял собой дальнейшее развитие 3-й ветки с некоторыми заимствованиями из 4-й – теми, что не шли в разрез с исконной идеологией KDE.

Увы – начатый во второй половине 2010 года, он явно запоздал. За два с половиной года, прошедшие с момента выхода KDE 4.0, эта среда в своём традиционном виде растеряла изрядную часть своих некогда преданных поклонников: одни, скрепя сердцем, погрузились в мир плазмоидов 4-й ветки, другие же мигрировали на более иные десктопы. А новые пользователи воспринимали «четвёрку» как данность – тем более, что к этому времени она стала пригодной к употреблению. И Trinity оказалась просто невостребованной широкими народными массами. Хотя некоторое число приверженцев и обрела.

Сказанное выше касалось распространения GNOME в мировом масштабе. А в нашей стране дело его укрепилось благодаря успеху проекта Russian Fedora, деятельность которого воплощена была в сборках RFRemix, кардинально улучшавшихся от версии к версии, вплоть до RFRemix 14 – апофеоза отечественного дистроения. Который (и это не только моё мнение) можно было смело рекомендовать русскоязычным пользователям любой сферы деятельности и почти любого уровня подготовки.

Казалось бы, вот он – тот самый готовый к десктопу Linux, наделённый человеческим лицом в виде интегрированной среды GNOME. То есть то самое, о чём говорили со времён первой версии Mandrake с его KDE. Однако – увы, это только казалось.

Ибо свежий ветер перемен затронул и GNOME, да так, что обрушился с ураганной силой. Потому что в апреле 2011 года принёс он с собой GNOME 3 с его GNOME Shell. Если и раньше, во времена GNOME 2, среда эта не утомляла своего пользователя изобилием настроек, даже в собственном реестре, то с переходом к 3-й ветке настройки практически исчезли как класс – или, позднее, в очень ограниченном количестве стали доступны благодаря сторонним утилитам-твикерам. Что же до интерфейса – он выглядел настолько революционным, что от привычных рабочих сред, казалось бы, не осталось просто ничего.

Однако большинство нового – это хорошо испорченное старое. Так, оверлейный режим GNOME Shell'а вызывал в памяти времена, когда не было ещё фиксированных множественных рабочих столов, но был зато единый рабочий стол с виртуальным разрешением в два и более раз выше физического (см. главу двадцать третью). А вертикальный ряд пиктограмм вдоль левого края экрана выглядели как реплика Window Maker'а, который, в свою очередь унаследовал эту идею от NeXTSTEP'а.

Не известно, позаимствовали разработчики GNOME Shell'а эти идеи у предшественников, или изобрели свои велосипеды независимо от них. Но в любом случае – ничего ультра-революционного в плане интерфейса эта среда не содержала. Разве что слияние виртуального рабочего стола с вертикальными пиктограммами. В результате чего получилось бы, возможно, вполне удачное нишевое решение – например для планшетов и прочих устройств с сенсорным экраном. Да вот беда – никто из производителей таких гаджетов использовать GNOME 3 не торопился: ниша эта была прочно оккупирована Android'ом. А для использования на обычном десктопе или ноутбуке решение это было мало пригодно. По крайней мере, для тех применителей, которые на десктопе или ноуте преимущественно работали, а не развлекались.

Однако разработчики GNOME Shell'а с этим не согласились. И попытались представить своё нишевое решение как универсальное. Причём с такой агрессивностью, с какой я не сталкивался за полтора десятка лет соприкосновения с миром Open Source. На любую критику в адрес своей среды у её фанатиков (не фэнов, не фанатов, а самых натуральных фанатиков) существовал универсальный ответ: всё это гениально и прогрессивно, а кто того не понимает --- ретроград и обскурант.

Было среди пользователей GNOME и другое течение – страстотерпцев. Не будучи приверженцами модерна, но сохраняя приверженность GNOME, они полагали, что надо смириться и привыкать к новомодному GNOME Shell'у, по принципу «Стерпится – слюбится». И надо сказать, что не все они смирились с положением «терпил»: некоторые стали активно создавать всякого рода твикеры для настройки «третьегнома» – то есть того самого, чем его собственные создатели пренебрегли, вполне цинично возложив эту миссию на «самих утопающих».

Наконец, возникло и третье течение – приверженцев старого и доброго GNOME. Тех, кто не хотел привыкать к GNOME новому и недоброму. И они пошли своим путём, да не одним, а сразу двумя.

Первый путь был ультраконсервативным и заключался просто в создании форма GNOME 2, получившего имя MATE. В отличие от близкого по идее проекта Trinity KDE, этот проект был начат практически сразу по выходе «третьегнома», когда запас спортивной злости пользователей его 2-й версии ещё не был растерян в дискуссиях на форумах и блогах. И потому MATE развивался (и развивается) вполне успешно.

Отступление. Название десктопа MATE происходит от слова mate (с ударением на первом слоге) – латиноамериканского (в первую очередь аргентинского и парагвайского) чаеподобного напитка, изготовляемого из листьев Падуба парагвайского. В указанном регионе он пользуется очень большой популярностью. Антони Арлетти в своей книжке Трампеадор свидетельствует, что знатоки

...могут почувствовать разницу между мате «этим вечером на том же самом месте» и мате «муж что-то подозревает». Ооо, это дьявольский мате!

А вот почему название десктопа принято писать целиком заглавными буквами – покрыто тайной.

Второй же путь в рамках третьего течения был более радикальным. Ряд пользователей 2-го GNOME, понимая, что для него слова, некогда увиденные царём Валтасаром, уже написаны, занялись стилизацией интерфейса GNOME 3 под внешний вид предшествующей версии. И, надо сказать, тоже не без успеха. Однако проект этот, получивший имя Cinnamon, быстро перерос первоначальные рамки. Но это уже не история, а современность, о которой сейчас сочиняется цикл на Блогосайте.

Здесь можно было бы сказать и о среде Unity – однако и она ещё не стала историей.

А что же другие?

Этот фрагмент истории десктопов был начат кратким рассказом о Xfce и ею же уместно его и завершить. Мы оставили её на уровне 3-й версии, которая, будучи переписана на основе библиотек Gtk, обрела статус свободной среды. Но на этом её история не закончилась.

При подготовке релиза 4.0 Xfce снова была полностью переписана – теперь на основе следующей, 2-й, версии Gtk. И не просто переписана изнутри, а кардинальным образом сменила интерфейс. От былого сходства с CDE не осталось и следа – внешности её по умолчанию было придано GNOME-подобие, а со временем, в версии 4.6, она обрела и своего рода реестр xfconf, также представляющий собой аналог GConf из среды GNOME.

Потеряла Xfce и свой «холерический темперамент», хотя по прежнему оставалась достаточно «лёгкой» и быстрой (хотя по этим двум пунктам можно найти и возражения). Однако её компактность трудно подвергнуть сомнению. И благодаря этому она стала десктопом по умолчанию ряда систем быстрого развёртывания, строившихся по принципу «одна задача – одно приложение». Среди таких систем наибольшую известность получили, пожалуй, Zenwalk и его родственник – Salix. А затем она была задействована в Xubuntu – одном из представителей семейства дистрибутивов Ubuntu. Хотя сборки с Xfce нынче можно видеть и в большинстве «больших» дистрибутивов, таких, как Fedora, openSUSE, Debian и ряде других.

Однако, как я только что сказал, разрастание Xfce вызывало нарекания – хотя, на мой взгляд, не вполне обоснованные. Тем не менее, в противовес ей были созданы ещё более «лёгкие» десктопы – сначала LXDE, а затем Razor-qt, основанные на библиотеках Gtk 3 и Qt, соответственно. Ныне их разработчики обозначили намерение слить оба проекта воедино. Но здесь мы уже окончательно покидаем историю и переходим к современности.