Графический интерфейс в Linux

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

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

Однако все задачи управления системой в Linux решаются посредством текстового терминала, да и очень многие задачи пользователя -- как заметил Мефодий даже по своему небольшому опыту -- тоже, поэтому никакой системной необходимости в графических средствах ввода-вывода в Linux нет. Графический интерфейс в Linux -- это отдельная задача, наподобие системной службы или демона, поэтому в некоторых системах может даже вовсе отсутствовать программное обеспечение для организации графического интерфейса(1). Такая задача получает единоличный доступ к устройству графического вывода (видеокарта), а программам, использующим графические ресурсы, она предоставляет объектную модель графических примитивов (функции рисования линий, прямоугольников, отображения цвета и т. п.), наподобие того, как ядро предоставляет доступ к ресурсам жёсткого диска в терминах объектной модели файловой системы. Поэтому весь комплекс программ для работы с графическими устройствами принято называть графической подсистемой.

Пользователю домашнего настольного компьютера графический интерфейс почти наверняка понадобится при каждом сеансе работы. Можно настроить систему таким образом, чтобы процесс начальной загрузки завершался запуском графической подсистемы, так что даже регистрация пользователей будет происходить уже в графическом режиме при помощи специальной программы -- экранного диспетчера (см. лекцию Этапы загрузки системы). Экранный диспетчер опознать очень просто: он всегда отображает окно с приглашением к регистрации login: и password:, которое может быть оформлено и минималистично, и с барочной пышностью. После регистрации в экранном диспетчере пользователю предоставляется сразу и доступ к системе, и доступ к графической подсистеме.

Однако ни в одной из систем, в которых работает Мефодий, ему не случалось встречаться с экранным диспетчером, и всюду он регистрировался в системе и работал только в текстовом режиме на виртуальной консоли. Поскольку графическая подсистема -- отдельная задача, авторизованный пользователь может запустить ей из командной строки в любой момент(2), для этого используется команда startx, которую Мефодий и исполнил.

В некоторое недоумение поставил Мефодия предложенный ему выбор из нескольких кнопок. Проконсультировавшись у Гуревича, он выяснил, что каждая из кнопок соответствует программе, по-своему организующей графический интерфейс, и что он может попробовать все по очереди и выбрать ту, которая будет наиболее подходящей для его стиля работы. Не мудрствуя лукаво, Мефодий нажал на первую же кнопку, обозначенную "KDE".

После некоторого ожидания на мониторе возникло всё то, что Мефодий ожидал увидеть в графическом интерфейсе: иконки, панель с кнопками внизу экрана, меню. Однако если бы после запуска startx Мефодий выбрал другую кнопку вместо "KDE", графический интерфейс предстал бы перед ним совсем в другом виде и предоставлял бы несколько другие возможности и приёмы работы. Далее в лекции объясняется устройство графической подсистемы в Linux. Станет понятно, почему процесс запуска графического интерфейса оказался таким двухступенчатым и почему работа с графическим интерфейсом в Linux может быть организована по-разному.

X Window System

Обратите внимание на то, что все заглавные буквы "X" в этой лекции -- латинские.

На свете существует множество графических устройств, управление которыми на низком уровне (вывод изображений и ввод данных, например, о перемещении мыши) -- задача совсем не для пользователя, тем более, что каждый вид устройства управляется по-своему. Заботы о вводе и выводе на низком уровне берёт на себя графическая подсистема Linux -- X Window System, предоставляя пользовательским программам возможность работать в терминах оконного интерфейса.

X Window System появилась всё в той же UNIX, проект этот был настолько наукоёмок и настолько полно охватывал тогдашнюю область задач, связанную с графикой, что ему так и не возникло никаких серьёзных альтернатив.

X-сервер и X-клиенты. Протокол X11

X Window System использует традиционную оконную модель, в которой пространством ресурсов является экран. Экран -- это прямоугольник, на котором отображаются команды графического вывода и организуется обратная связь с устройствами графического ввода. Пример обратной связи -- указатель мыши. Сама мышь -- довольно простое устройство ввода, способное передавать информацию о его перемещении и состоянии кнопок. Указатель же отображает мнение подсистемы об абсолютных координатах гипотетической "точки ввода".

В примере указатель мыши показывает расположение точки ввода (на кнопке "WindowMaker"). Если сейчас Мефодий нажмёт на левую клавишу мыши, графическая подсистема зафиксирует это событие ввода и передаст его той задаче, которой принадлежит соответствующая кнопка. Именно задачи (а не сидящий за монитором пользователь) и являются субъектами для X Window System, между ними разделяются графические ресурсы. Каждой задаче принадлежит одно или несколько окон, представленных некоторой (как правило, прямоугольной) частью экрана. Внутри окна выполняются графические операции (вывод) и именно окнам передаётся поток данных от устройств ввода. Какое окно получит события ввода -- определяется с помощью синтетического понятия фокус: вводимые данные передаются от графической подсистемы только тому окну, которое "получило фокус", по умолчанию это происходит, когда указатель мыши попадает в часть экрана, занимаемую этим окном.

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

Программа, которая отвечает за работу с устройствами графического ввода и вывода и обеспечивает при этом логику оконной системы, называется X-сервером (X Server, то есть сервер системы "Икс"). В рамках X Window System, X-сервер -- это ядро. Подобно ядру, он выполняет низкоуровневые операции и взаимодействует с аппаратурой, ничего самостоятельно не предпринимая. Подобно ядру, он предоставляет задачам унифицированный интерфейс к этим низкоуровневым функциям, а также занимается разделением доступа (окно и фокус) к графическим ресурсам. X-сервер не волнует, отчего эти задачи вообще появляются и чем живут. Он только принимает запросы на выполнение графических действий и передаёт по назначению вводимые данные. Жизнеобеспечение процессов и даже способ передачи X-запросов -- дело исключительно операционной системы, по отношению к которой и сам X-сервер -- задача.

Задачи, которые обращаются к X-серверу с запросами, называются X-клиентами. Обычно X-клиент сначала регистрирует окно (можно несколько), которое и будет ему полем ввода-вывода. Потом он сможет рисовать в этом окне и обрабатывать происходящие с окном события: активность устройств ввода и изменение свойств самого окна (размер, перемещение, превращение в иконку, закрытие и т. п.). X-клиент в Linux -- это процесс, запускаемый обычно в фоне (не связанный по вводу с терминальной линией). В самом деле, зачем процессу читать с терминала, когда для ввода он может использовать X-сервер? Если с X-сервером связаться не удастся, на стандартном выводе ошибок может появиться какое-нибудь сообщение -- его легко перенаправить в файл.

Клиент передаёт серверу X-запросы любым доступным ему способом. В разных версиях Linux, например, могут использоваться различные объекты файловой системы (чаще всего -- т. н. сокеты, сходные по функциональности с двунаправленными каналами). Во многих случаях запросы передаются по сети, при этом неважно, какой именно транспортный уровень будет использован для соединения клиента с сервером (в современных системах это, чаще всего, сеть TCP/IP и протокол TCP). Главное, чтобы клиент посылал стандартные запросы, соответствующие определённому протоколу обмена данными. Кстати сказать, другое имя X Window System -- X11 (или X11R6) -- это просто номер версии X-протокола, стандартизующего X-запросы, при этом "R6" обозначает номер подверсии (revision) и вполне может увеличиться, если X11R6 устареет настолько, что потребует нового пересмотра (revision).

"Голый" X-сервер, к которому ни присоединён ни один X-клиент, можно запустить из командной строки, для этого достаточно выполнить команду "X" (одна заглавная латинская буква X). Именно так и поступил Мефодий, текстовая консоль сменилась чёрным экраном без всяких окон(3).

На экране есть только крест, который перемещается при перемещении мыши -- курсор. Эта картина означает, что X-сервер запущен корректно, установил необходимую связь с устройствами графического ввода и вывода, и ожидает, когда к нему с X-запросами обратится какой-нибудь X-клиент. Однако для пользователя, пока не запущено ни одного X-клиента, X-сервер совершенно бесполезен: кроме перемещения курсора ничего и невозможно сделать. Мефодий мог бы растеряться, оказавшись перед чёрным экраном X-сервера, если бы не знал о том, что может переключиться обратно на любую виртуальную консоль, нажав сочетание клавиш Ctrl + Alt + F N, где N -- номер консоли от 1 до 12(4). Переключиться обратно на экран, управляемый X-сервером, он сможет комбинацией клавиш Ctrl + Alt + F7.

DISPLAY

Чтобы начать работу с графической средой, X-клиенты должны каким-то образом доставить свой запрос X-серверу, для этого у X-сервера должен быть какой-то точный адрес. Адрес X-сервера, к которому должны обращаться с запросом X-клиенты, хранится в переменной окружения DISPLAY. Формат DISPLAY прост: способ_доступа:номер_сервера.номер_экрана. Под способом доступа может подразумеваться сеть (тогда используется сетевой адрес машины с X-сервером) или какой-нибудь ещё механизм, принятый в конкретной системе. Если не написать ничего, будет выбран способ по умолчанию. Номер сервера нужен для различения разных X-серверов, запущенных на одном компьютере. В Linux можно запустить несколько X-серверов и переключаться между ними как между виртуальными консолями -- с помощью Ctrl + Alt + F7, Ctrl + Alt + F8 и т. д. В системе может быть несколько виртуальных серверов (см. раздел Виртуальный сервер). Все они должны иметь разные номера. Наконец, один сервер может работать с несколькими экранами -- и физически (есть видеокарты с выходами на несколько мониторов), и виртуально (вот тут уж никаких ограничений нет). Правда, это бывает нечасто, и номер экрана тоже можно не указывать.

Адрес X-сервера, запущенного Мефодием, будет выглядеть так: ":0" -- поскольку сервер запущен на той же машине, на которой работает Мефодий, можно использовать способ доступа по умолчанию (поэтому адрес начинается с двоеточия), поскольку сервер единственный, он получил номер "0", а экран можно не указывать. Теперь Мефодий может в любой командной оболочке (shell) указать адрес X-сервера в переменной DISPLAY, так что любой запущенный из этой shell X-клиент унаследует это значение и будет отправлять X-запросы тому серверу, который запустил Мефодий.

methody@susanin:~ $ export DISPLAY=:0
methody@susanin:~ $ echo $DISPLAY
:0
methody@susanin:~ $ xcalc &

В результате этих действий изменился экран X-сервера: в левом верхнем углу открылось окно калькулятора -- xcalc. Произошло следующее: при запуске xcalc проверил значение переменной DISPLAY и направил X-запрос по указанному там адресу; по запросу от X-клиента (xcalc) X-сервер выделил ему окно и выполнил необходимые операции графического вывода, чтобы отрисовать содержимое окна (опять же, по запросам xcalc). Теперь при помощи мыши и клавиатуры, переместив точку ввода на это окно, вполне можно что-нибудь вычислить, однако ни переместить окно, ни изменить его размер, ни свернуть -- те операции, к которым так привыкли пользователи оконного интерфейса -- сам X-сервер не выполняет, для этих операций требуется специальная программа -- диспетчер окон, о которой речь пойдёт ниже.

С помощью специальных X-запросов можно изменить вид и поведение самого X-сервера из той же командной оболочки, в которой установлена переменная окружения DISPLAY. Например, команда "xsetroot -solid green &" изменит цвет фона на экране сервера на зелёный.

Итак, X-сервер запускается на одном компьютере, а X-клиенты вполне могут работать на других (причём на нескольких!), посылая ему запросы. С точки зрения человека, сидящего за (обратите внимание!) X-сервером, каждый такой клиент представлен в виде окна. Требования к аппаратуре на машинах, запускающих X- клиенты, будут изрядно отличаться от требований к аппаратуре машины для X- сервера. Типичная машина с X-сервером -- это рабочее место (workstation). Она должна быть оборудована качественными устройствами ввода-вывода -- монитором, видеокартой, клавиатурой и мышью. Что же касается её вычислительных способностей, то их должно быть достаточно для выполнения X-запросов, и только. Такой компьютер не обязан работать под управлением Linux, на нём даже может вообще не быть операционной системы! В восьмидесятые годы выпускались подобные устройства, называемые "X-терминал" (X terminal).

В отличие от машины с X-сервером, компьютер для запуска X-клиентов может совсем не иметь устройств графического ввода-вывода. Его задача в том, чтобы все X-программы и запустившие их пользователи не мешали друг другу работать. На такой машине нужна хорошо настроенная операционная среда, с достаточным для запуска многих процессов быстродействием и объёмом оперативной памяти. Пара X11--Linux весьма неплохо работает на т. н. бездисковых комплексах. Рабочие станции в таких комплексах -- самые настоящие X-терминалы, они не имеют жёстких дисков. Вся работа происходит на центральном компьютере, с которого на рабочую станцию загружается по сети урезанный вариант системы, достаточный для запуска X-сервера, и сам X-сервер. В таких комплексах администрировать нужно одну только центральную машину, они надёжнее компьютерных залов и, что немаловажно, стоят дешевле, причём в качестве X-терминалов можно использовать и довольно маломощные, пожилые компьютеры.

Виртуальный сервер

Одно из многих достоинств X-протокола -- в том, что X-сервером может служить любая программа, исполняющая X-запросы, а работает ли она на самом деле с каким-нибудь графическим устройством или только притворяется -- неважно. Протоколом X11 пользуется сервер печати Xprt, который выводит на принтер все X-запросы или Xvnc -- X-сервер, управлять которым по специальному протоколу можно с нескольких машин. С помощью Xvnc (другой вариант названия -- vncserver) можно устраивать показ работы какого-нибудь X-клиента по сети. При этом все пользователи одновременно смогут запустить VNC-клиент (vncviewer) и гонять по экрану один и тот же указатель мыши (что, конечно, можно и запретить).

Виртуальный X-сервер может вообще никаких действий не выполнять, а только передавать X-запросы куда-нибудь дальше, например, "настоящему" X-серверу. Так поступает демон Secure Shell, sshd (программа терминального доступа, о которой шла речь в лекции Сетевые и серверные возможности), переправляя X-запросы X-серверу в зашифрованном виде. Этим свойством sshd можно воспользоваться, если сообщение по X-протоколу между двумя компьютерами невозможно (запрещено межсетевым экраном), или вы считаете такое соединение небезопасным.

methody@sakura:~ ssh methody@fuji
 methody@fuji's password: 
 Last login: Sat Dec 25 13:26:40 2004 from localhost
methody@fuji:~ $ xcalc
 Error: Can't open display: 
methody@fuji:~ $ export DISPLAY=sakura:0
methody@fuji:~ $ xcalc
 Error: Can't open display: sakura:0
methody@fuji:~ $ logout
 Connection to fuji closed.
methody@sakura:~ ssh -X methody@fuji
 methody@fuji's password: 
 Last login: Sun Dec 26 11:13:08 2004 from sakura.nipponman.ru
methody@fuji:~ $ echo $DISPLAY 
 localhost:10.0
methody@fuji:~ $ xcalc
 # работает :) !

Допустим, Мефодий хочет запустить X-клиент (например, xcalc) на другой машине в локальной сети -- fuji, где у него есть учётная запись (тоже methody). После всех операций, проделанных в примере, на экране X-сервера на локальной машине Мефодия (за которой он сидит), появится ещё одно окно xcalc, при этом этот xcalc в действительности запущен на машине fuji и все вычислительные операции выполняются именно там.

Демон SSH заводит виртуальный X-сервер на удалённой машине, причём номер_сервера обычно заводится таким, чтобы не пересекаться с X-серверами, которые могут быть запущены на этой машине (в примере номер_сервера равен 10). Виртуальный sshd-X сервер принимает все X-запросы с того же компьютера и передаёт их -- в зашифрованном виде -- на компьютер, где запущен ssh и невиртуальный X-сервер. Здесь все X-запросы вынимаются из SSH-"водопровода" и передаются местному серверу, как если бы они исходили от местного X-клиента (так оно и сеть: этот клиент -- ssh).

XFree86 и X.Org

Наиболее распространённая версия реализации X11R6 до начала 2000-х годов называлась XFree86. Эта графическая подсистема изначально проектировалась как реализация X11R5 для машин архитектуры i386 -- самых распространённых на сегодня персональных компьютеров. Главная особенность этой архитектуры -- бесчисленное многообразие устройств графического вывода (т. н. видеокарт) и непрестанное нарушение их разработчиками всех мыслимых стандартов. Поэтому главной задачей создателей XFree86 было устроить гибкую структуру компоновки и настройки X-сервера в соответствии с подвернувшимся под руку устройством графического вывода, а заодно и ввода, потому что клавиатур, мышей и заменяющих их устройств на свете тоже немало. Сегодня XFree86 существует для многих архитектур и многих операционных систем.

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

Конфигурация X-сервера

Чтобы приспособить графическую подсистему (в любой реализации) к имеющемуся оборудованию, требуется организовать соответствующий профиль. Профиль графической подсистемы находится в каталоге /etc/X11, основной конфигурационный файл X.Org называется xorg.conf, именно его считывает при запуске X-сервер. Конфигурационный файл XFree86 называется XF86Config (или XF86Config-4).

Мы рассмотрим конфигурацию графической подсистемы на примере X.Org. Файл xorg.conf структурирован: состоит из нескольких обязательных разделов, которые могут следовать в любом порядке. В раздел объединяется часть профиля, связанная с одной из сторон деятельности X-сервера. Каждый раздел имеет такую структуру:

Section  "НазваниеРаздела"
КлючевоеСлово "Параметры"
. . .
EndSection

Внутри раздела содержатся записи, каждая из которых занимает обычно одну строку и задаёт значение для одного из параметров профиля X.Org. В начале записи стоит КлючевоеСлово, за которым следуют Параметры, количество и формат которых зависит от ключевого слова. Ниже приводится список обязательных разделов с краткими аннотациями, для чего они служат.

Files          Пути к файлам с ресурсами, необходимыми X-серверу
ServerFlags    Общие параметры X-сервера 
Module         Расширения, которые следует загрузить
InputDevice    Описание устройств ввода
Device         Описание устройства вывода (видеокарты)
Monitor        Описание монитора
Modes          Описание видеорежимов 
Screen         Описание экрана (связывает монитор и видеокарту)
ServerLayout   Конфигурация сервера

Почти каждый из перечисленных разделов может присутствовать в конфигурационном файле в нескольких экземплярах, например, может быть несколько разделов (InputDevice), описывающих разные устройства ввода (разные мыши и клавиатуры). Однако эти разделы не равноправны, а образуют иерархическую структуру, самым главным (корневым) элементом которой является конфигурация сервера (ServerLayout). В этом разделе указывается, какие именно из описанных в файле устройств ввода (разделы InputDevice, как минимум два -- для клавиатуры и мыши) и вывода (Screen, который связывает в единое устройство вывода монитор и видеокарту, ссылаясь на их описания в соответствующих разделах) будут использованы при работе X-сервера. В каждом разделе присутствует строка "Identifier "идентификатор"", именно эта строка используется для выбора нужного из однотипных устройств в разделе "ServerLayout". Например, на машине, где работает Мефодий, общая конфигурация сервера выглядит так:

Section "ServerLayout"
        Identifier "layout1"
        Screen     "screen1"
        InputDevice "Mouse1" "CorePointer"
        InputDevice "Keyboard1" "CoreKeyboard"
EndSection

Соответственно, при запуске сервера будут использованы тот раздел Screen, в котором содержится запись "Identifier "screen1"", мышь "Mouse1" и клавиатура "Keyboard1".

Чтобы разобраться в подробностях каждого раздела, требуются определённые познания в работе и характеристиках устройств ввода и вывода, поэтому здесь мы не будем приводить конкретных примеров. Подробно о формате xorg.conf можно прочитать в соответствующем руководстве xorg.conf(5). Для многих пользователей будет достаточно профиля графической подсистемы, созданного одним из существующих мастеров, включаемых разработчиками дистрибутивов Linux в процедуру установки системы. С их помощью можно создать более или менее подходящий профиль, не вникая в тонкости, нередко -- непосредственно при установке системы. Во всяком случае, у пользователя всегда остаётся возможность корректировать профиль вручную, отредактировав конфигурационный файл. Простой конфигурационный файл можно получить, запустив X-сервер с ключом -configure с правами суперпользователя. При этом в текущем каталоге создастся файл xorg.conf.new, в котором X-сервер сохранит результаты автоматического определения внешних устройств.

Модули и расширения

Требование гибкости привело к тому, что в реализации XFree86 и X.Org графическая подсистема стала совсем уже похожа на операционную систему. Сам X-сервер играет роль ядра. Запускаясь, сервер подгружает драйверы -- специальные компоненты, работающие с выбранной видеокартой, и модули -- компоненты, расширяющие функциональные возможности сервера (в конфигурационном файле xorg.conf необходимые модули перечисляются в разделе Modules). Есть весьма нужные расширения, вроде glx (высокоуровневые функции трёхмерной графики) или freetype (поддержка шрифтов TrueType), а есть экзотические, которые иногда могут понадобиться, например, RECORD, позволяющее записывать, а после -- "проигрывать" все происходящие с сервером события.

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

X-приложения

Программный продукт, использующий X11, называется приложением (application, другое значение -- "применение"). Если считать, что сами графические возможности уже реализованы X-сервером и библиотеками, то программа и на самом деле окажется приложением к системе, и вся её заслуга будет состоять в том, что она применила эти возможности для решения своей задачи.

Эмулятор терминала

С графикой или без, основным интерфейсом управления Linux была и остаётся командная строка. X11, предлагая иной способ взаимодействия с компьютером, не должна лишать пользователя возможности работать с самой системой испытанным и эффективным методом -- через терминал. Поэтому первое совершенно необходимое X-приложение должно предоставлять возможность доступа к терминалу в X Window System.

Задача дать пользователю X11 командную строку решается довольно легко. Нужно завести X-приложение, окно которого работает аналогично окну терминала: передаёт символьную информацию от пользователя системе и обратно. Делается это уже описанным в лекции Mount механизмом псевдотерминалов tty/pty (или pts/ptmx): X-приложение получает во владение специальное устройство типа pty, связанное по вводу и выводу с терминальным устройством типа tty, с которым работает shell. Общее название таким программам -- эмулятор терминала для X11 (xterm). Мефодий может запустить xterm всё из той же виртуальной консоли, в которой определено значение переменной окружения DISPLAY и получить доступ к командной строке уже из графической оболочки.

В левом верхнем углу открылось окно xterm, которое легло "поверх" открытого ранее xcalc. В открывшемся окне xterm Мефодий увидел привычное приглашение командной строки bash: теперь из этой командной строки можно выполнять любые команды, в том числе и запускать новые X-приложения, например, ещё один xterm. Чтобы при этом избежать наложения окон друг на друга, можно запустить xterm с параметром "-geometry +150+150", что заставить X-сервер выдать ему окно, верхний левый угол которого отстоит на 150 экранных точек (пикселей) от левой границы экрана, и на 150 же -- от левой. В этом xterm значение DISPLAY унаследовано от родительского процесса и равно ":0", так что окна всех запущенных из него X-приложений откроются на этом же экране.

Не следует путать программу xterm со способом организации рабочей станции (т. н. "X-терминал"): термины эти созвучны, но относятся к разным областям знаний. Нередко бывает, что на экране X-терминала (компьютера) есть окно терминала X11 (программы xterm). XTerm передаёт сигналы как настоящий терминал, имеет богатый набор управляющих последовательностей (унаследованный от устройства "DEC VT102/VT220"), а вдобавок позволяет воспользоваться всеми преимуществами графической среды: выбрать шрифт, запомнить текст на экране (даже тот, что уже исчез с экрана) и многое другое.

Кстати сказать, копирование текста при помощи мыши -- свойство совсем не только XTerm. На самом деле любое окно, зарегистрированное в X11 как текстовое, позволяет отметить (при постоянно нажатой первой кнопке или последовательными нажатиями третьей) часть текста. Выделенный текст можно немедленно вставить в любое окно текстового ввода нажатием второй (обычно -- средней) кнопки. Различают временное хранилище (т. н. cut buffer), содержимое которого обновляется всякий раз, когда пользователь выделяет текст, и буфер обмена (т. н. clipboard), содержимое которого заполняется, если пользователь вызвал соответствующую команду (например, выбрал пункт меню "Copy"). Cut buffer -- удобное средства копирования в два движения (выделить в одном месте, нажать среднюю кнопку в другом). Clipboard -- более традиционный, но более трудоёмкий инструмент (выделить, скопировать, выделить вставить).

Сеанс работы с X11

Как догадался Мефодий, команда startx делает несколько больше, чем просто запуск X-сервера, она кроме того запускает несколько X-приложений. Для удобной работы в X11 пользователю прямо при запуске графической подсистемы потребуется сразу несколько приложений. Во-первых, нужно запустить приложение, которое позволит управлять окнами (как минимум перемещать их), чего не делает сам X-сервер, такие приложения называются диспетчеры окон и будут обсуждаться немного позднее. Кроме того, полезно сразу запустить разные мелкие программки, вроде индикатора загрузки системы xload или экранных часов xclock. Сам X-сервер не мешает настроить с помощью xset (можно поменять курсор, звуковой сигнал, переименовать кнопки мыши). Одним словом, пользователю, как правило, нужен небольшой стартовый сценарий, который запускался бы вместе с X-сервером.

С другой стороны, сервер хорошо бы останавливать, когда он больше не используется. Это, конечно, относится к схеме без диспетчера экрана (xdm): пользователь работает с терминала, потом запускает X-сервер для выполнения графических программ, выполняет их и останавливает сервер, чтобы графическим устройством мог воспользоваться кто-нибудь другой. Стандартный способ аварийного завершения работы X.Org (Ctrl + Alt + Backspace), во-первых, доступен только на X.Org, во-вторых, его можно отключить, а в-третьих, все запущенные приложения получат в этом случае сообщение о внезапной смерти сервера и тоже завершатся аварийно.

Если запускать не сам X-сервер, а некоторую оболочку вокруг него, называемую startx, то алгоритм работы будет такой. Сначала запустится X-сервер и сформируется значение переменной окружения DISPLAY. Затем запустится сценарий .xinitrc, находящийся в домашнем каталоге пользователя, а если такого нет -- системный стартовый сценарий /etc/X11/xinit/xinitrc. Предполагается, что X-сервер будет работать до тех пор, пока выполняется .xinitrc. Когда все команды из .xinitrc отработают, его выполнение завершится, а вместе с ним завершится и сервер. Поэтому рекомендуется все X-приложения из .xinitrc, кроме последнего, запускать в фоне, чтобы командный интерпретатор не дожидался окончания их работы. В этом случае с завершением последнего приложения из .xinitrc завершится и сам X-сервер. Последней программой в стартовом сценарии может быть xterm, как это сделано в стандартном xinitrc, или диспетчер окон. Для завершения xterm (а с ним и всего сеанса работы X11) достаточно послать "^D" запущенному в нём shell, а окновод обычно имеет какую- нибудь кнопочку или менюшку "Exit". Программа, с завершением которой завершается сеанс X11, называется лидером сеанса (session leader).

Лидер сеанса может быть указан и в качестве параметра startx в командной строке, например, по команде startx /usr/bin/xterm будет открыт сеанс X11, лидером которого будет xterm, его окно откроется при запуске на экране X-сервера.

Диспетчер экрана организует сеанс работы с X11 сходным образом. Единственное отличие -- в том, что ко времени запуска startx вручную пользователь уже имеет настроенное окружение (этим занимается стартовый командный интерпретатор), а после регистрации в диспетчере экрана -- нет. Поэтому стартовый сценарий нужно запускать другой -- .xsession. На самом деле и сам X-сервер необходимо перезапускать и при использовании xdm. Несмотря на то, что пользователи взаимодействуют только с X-сервером, не используя виртуальные консоли, было бы неудобно и небезопасно сохранять какие бы то ни было настройки, сделанные одним пользователем ко времени работы другого. Самое неприятное -- это т. н. "клавиатурный вор" (keyboard grabber), программа, притворяющаяся окноводом -- для того лишь, чтобы запоминать всё, что пользователь ввёл с клавиатуры (злоумышленников интересуют, как правило, пароли).

Нарушения безопасности легко избежать, если не использовать xhost (авторизацию на основе адреса) и не доверять X-серверу, запущенному не при вас. Можно доверять автоматически запускаемой в сеансе программе xauth, которая связывается с X-сервером и записывает в файл ~/.Xauthority специальный ключ доступа. Все X-приложения пользуются библиотекой libX11, которая обязательно обращается к этому файлу. Таким образом, X-приложение может воспользоваться X-сервером, если оно знает его адрес (указанный в переменной окружения DISPLAY или переданный ключом -display) и авторизовано сервером (по адресу компьютера или по ключу доступа в ~/.Xauthority).

Ресурсы X11

X-приложения создаются с помощью разнообразных готовых инструментариев. Большая их часть разрабатывается независимыми авторами по всему миру (это общее свойство свободного ПО, см. Политика свободного лицензирования. История Linux: от ядра к дистрибутивам), но библиотека самого низкого уровня, "X Lib", и несколько более высокоуровневых с давних пор включаются в основной дистрибутив X11. Из них наиболее примечательна "X Toolkit" (Xt), организующая из стандартных окон X11 оконные примитивы (widgets).

Дело в том, что каждый объект X11 обладает некоторым набором свойств, вроде размера окна, цвета фона или текстового содержимого. Для удобства доступа примитивы Xt, реализованные поверх объектов Xlib, имеют собственные имена (у каждого объекта своё) и фамилии (одинаковые у всех объектов одного класса). Более того, программа, написанная на Xt, имеет карту объектов, в которой указано, какой объект внутри какого находится, и приведены имена объектов и их классов. Посмотреть структуру запущенного X-приложения можно с помощью программы editres ("Commands/Get Tree"). Например, программа xlogo состоит из трёх примитивов: xlogo (класс XLogo) и вложенными в него xlogo.xlogo (класс Logo) и shellext (неоконный, класс VendorShellExt). Мало того, свойства этих примитивов можно подменить прямо в работающей программе. Можно, например, на время работы перекрасить фон xlogo в красный цвет.

Xlib, со своей стороны, предоставляет универсальный способ хранить такие настройки в файле. Многие приложения хранят свои настройки по умолчанию в /etc/X11/app-defaults/ИмяКласса (в некоторых системах этот каталог перенесён, как ему и подобает, в /etc/X11). ИмяКласса -- это имя класса самого главного окна этого приложения. Пользователь может дополнить настройки ресурсов, которые сервер накапливает при старте, при помощи команды xrdb -merge файл_настроек или переписать их заново (ключ "-load"). Приложению остаётся только вызвать специальную функцию Xlib, которая считывает настройку с определённым именем из таблиц сервера. Если xrdb не запускалась ни разу (в том числе и в стартовом сценарии), запрос приложения направится не в таблицу сервера, а непосредственно в файл ресурсов .Xdefaults(5), лежащий в домашнем каталоге. В этом случае для изменения настроек не надо запускать xrdb.

Xt добавляет в эту процедуру иерархию ресурсов. Как это можно наблюдать в editres, при задании свойства ресурса используются четыре конструкции: имя ресурса, имя класса, разделитель ".", означающий, что один ресурс вложен в другой непосредственно, и разделитель "*", означающий, что ресурс вложен в другой в конце концов (возможно, по цепочке). Например, для задания цвета фона в программе xload можно использовать именование xload.paned.load.background (это всё по именам). Можно попробовать единым махом изменить цвет фона всех примитивов этой программы, записав в .Xdefaults (или передав xrdb) строку вида "XLoad*background: midnightblue".

Если в .Xdefaults есть несколько строк, удовлетворяющих имени ресурса, то имена собственные имеют преимущество над классами, а "." -- над "*". Так что запись вида "*Text*background: peachpuff" повлияет только на те примитивы класса Text и вложенные в них, для которых нет более строгого указания (например, "*Text.background" или "XConsole*Text*background"). Обратите внимание, как поэтично называются порой цвета в X11! Посмотреть таблицу цветов можно командой xlscolors.

К сожалению, Xt -- всё-таки довольно старая библиотека, не во всём следующая новым веяниям в области графического интерфейса. Для быстрой разработки оконных программ нужны разнообразные и мощные инструменты, которые манипулируют понятиями, далеко ушедшими от стандартного "окно--меню--кнопка". Если такие инструментарии написаны с применением Xt (например Xm, "open Motif", Xaw, "Athena Widget"), их настройки можно поселить в .Xdefaults. Незадача ещё и в том, что структуру классов Xt неудобно использовать при программировании на языке C++, а именно на нём сейчас пишется большинство оконных приложений. Так что самые мощные инструментарии для X11 -- Qt ("The Q Toolkit") и GTK ("The GIMP toolkit") -- не используют App-defaults.

Диспетчер окон

Задача диспетчера окон

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

Ответ очевиден: этим должна заниматься программа, основная задача которой состоит в том, чтобы отслеживать перекрытие, изменять размер, двигать, превращать в иконку и так далее. По совместительству эта же программа будет рисовать при окнах всякие красивости: рамочки, заголовки, кнопки и меню управления -- словом, делать всё, что нужно для организации логики управления окнами. Для этого придётся также обрабатывать практически все события, передаваемые от устройств ввода, и многочисленные "подсказки" от приложений относительно того, какими они хотят видеть собственные окна. Это X-приложение называется диспетчером окон (window manager)(6).

Благодаря стандартному протоколу X11 появилось такое множество диспетчеров окон для X Window System, что перечислить их все просто невозможно. Все они различаются видом и кругом возможностей для манипулирования окнами: от самых простых (рамочка вокруг окна позволяет двигать его, изменять размер и поднимать из глубины; собственно, всё) до весьма изощрённых (виртуальные экраны, анимированные полупрозрачные меню, панели инструментов, причудливой формы украшения на окнах; сами окна ползают по экранам, кувыркаются, растворяются как утренний туман; всё это лязгает, попискивает и разговаривает приятным женским голосом). Когда Мефодий в первый раз запустил команду startx, была запущена утилита wm-select, которая предложила ему выбрать, какой из установленных в его системе диспетчеров окон запустить.

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

Работа с окнами

Совершенно необязательно начинать сеанс работы в X11 с запуска диспетчера окон, его можно запустить в любой момент. Например, Мефодий может к уже запущенному им X-серверу подключить любой диспетчер окон, запустив его всё из той же виртуальной консоли. Например, чтобы запустить WindowMaker, достаточно выполнить команду wmaker.

С запуском диспетчера окон экран X-сервера заметно преобразился: одноцветный фон сменился изображением, по углам возникли квадратные кнопки, а вокруг окна xterm образовалась рамка с названием окна и кнопками. Эта рамка -- "органы управления" окном, так называемые оконные примитивы (их собственное имя -- "widgets" -- сокращение от "window gadgets", "оконные безделушки"). "Ухватившись" мышью за рамку, Мефодий поменял размеры окна, а нажав на правую кнопку мыши на заголовке окна -- увидел меню, состоящее из списка операций, которые можно произвести над этим окном. Все эти возможности предоставлены диспетчером окон WindowMaker.

Удобства

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

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

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

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

Настройка диспетчера окон

Удобство графического интерфейса -- понятие очень субъективное, при этом технологически безразлично, рисовать ли кнопки в левом верхнем углу или в правом нижнем, какой цвет и шрифт использовать в меню и т. п. -- всё это составляет профиль диспетчера окон. Поэтому в подавляющем большинстве диспетчеров окон существуют более или менее развитые возможности изменить внешний вид и оформление графической среды. В WindowMaker для этого используется специальная утилита с графическим интерфейсом (Мефодий может её вызвать при помощи самой верхней кнопки в левом верхнем углу экрана). В других диспетчерах окон, как, например, в очень развитом и fvwm, профиль может просто храниться в конфигурационном файле (~/.fvwm2rc), для изменения внешнего вида fvwm следует редактировать этот файл.

Среди диспетчеров окон в тяжёлых весовых категориях выступают и fvwm2 (множество функций), и Enlightenment (настоящая игрушка), и WindowMaker, и некоторые другие. Человеку, проводящему рабочее время за экраном компьютера, важен комфорт на рабочем месте, поэтому всякая мелочь или её отсутствие может иметь решающее значение при выборе того или иного диспетчера окон.

Рабочий стол

С появлением универсальных высокоуровневых инструментариев стала обретать плоть идея полного воплощения метафоры "рабочего стола", впервые реализованная в системах семейства MacOS. Смысл рабочего стола в том, чтобы предложить принципиально иной способ взаимодействия человека и компьютера -- способ, основанный на манипуляции единичными именованными объектами. Каталоги превращаются в "папки с документами", причём каждый тип документов можно "открыть" с помощью специального "документатора". Программы превращаются в эдакие поместилища абстрактных функциональностей: "Интернет", "Почта", "Видео" и т. п. Рабочий стол особенно потребен человеку, чья область деятельности далека от компьютерного дела, для кого он -- не вычислительная машина, а инструмент решения отдельных -- типовых и, чаще всего, непрофильных -- задач.

Компьютер так стремительно вошёл "в каждый дом", что давно уже стал бытовым прибором для игр, чтения электронной почты, просмотра WWW, а в последнее время -- музыкальным центром и видеопроигрывателем. Грешно требовать от садящейся за клавиатуру домохозяйки или какого-нибудь оболтуса строгого следования принципам проективной системы. Лучше дать им в руки красивую и сравнительно безопасную игрушку, которая способна удовлетворять бытовые их нужды. Таких игрушек для X11 несколько. Две мощные среды "офисного" плана -- KDE (основанное на Qt переосмысление коммерческой среды CDE) и Gnome (основанная на GTK) -- содержат всё необходимое для деловой работы (включая собственные офисные приложения и средства просмотра WWW). Или, например, среда XFCE (основанная также на GTK) -- крепко сколоченный минималистский вариант CDE, простой и ясный, как выдвижной ящик.

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

До сей поры Мефодий считал, что его -- не такой уж новый -- компьютер вполне подходит для работы в Linux, и ничто этому утверждению не противоречило. Для того, чтобы проверить, чем же занимается система, он запустил команду top, нажал "M" для того, чтобы посмотреть, какие процессы занимают больше всего памяти и обнаружил довольно неприятную, хотя и вполне терпимую картину:

00:55:08  up 13:20, 13 users,  load average: 1,71, 1,87, 0,97
29 processes: 28 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 60,6% user, 14,6% system,  6,2% nice,  0,0% iowait, 18,4% idle
Mem:    54232k av,   53076k used,    1156k free,       0k shrd,    1628k buff
        18032k active,              22620k inactive
Swap:  200772k av,  108288k used,   92484k free                   15812k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
15410 methody   13   5  9448 8980  8096 S N   0,0 16,5   0:01 kdeinit
15379 methody    9   0  9656 7928  7184 S     0,1 14,6   0:06 kdeinit
15404 methody    9   0  9652 7612  7428 S     0,0 14,0   0:02 kdeinit
15395 methody    9   0  9596 7376  7372 S     0,0 13,6   0:02 kdeinit
15406 methody    9   0 10084 7216  6192 S     0,0 13,3   0:09 konqueror
15397 methody    9   0  8592 7140  6560 S     0,5 13,1   0:03 korgac
15387 methody    9   0  8464 6920  6748 S     0,0 12,7   0:02 kdeinit
15390 methody    9   0  8488 6644  6640 S     0,0 12,2   0:01 kdeinit
15393 methody    9   0  8576 6636  6632 S     0,0 12,2   0:02 kkbswitch
15407 methody    9   0  6864 6164  6064 S     0,0 11,3   0:00 kdeinit
15377 methody    9   0  7592 5844  5440 S     0,0 10,7   0:04 kdeinit
15380 methody    9   0  6564 5736  5624 S     0,0 10,5   0:00 kdeinit
15346 methody    9   0  6652 5028  4744 S     0,1  9,2   0:02 kdeinit
15368 methody    9   0  6864 4972  4972 S     0,0  9,1   0:02 kdeinit
15376 methody    9   0  6164 4504  4504 S     0,0  8,3   0:01 kdeinit
15356 methody    9   0  6608 4436  4432 S     0,0  8,1   0:01 kdeinit
15366 methody    9   0  6008 4436  4436 S     0,0  8,1   0:01 kdeinit
15343 methody    9   0  5248 4388  4156 S     0,1  8,0   0:00 kdeinit
15385 methody    9   0  5412 3984  3876 S     0,0  7,3   0:01 apt-indicator
15341 methody    9   0  4540 3768  3612 S     0,0  6,9   0:00 kdeinit
15338 methody    8   0  2260 1444  1368 S     0,0  2,6   0:00 kdeinit
15411 methody   15   0  1092 1040   844 R     2,3  1,9   0:01 top
15200 methody    9   0   628  520   520 S     0,0  0,9   0:00 xinit
15159 methody    9   0   912  508   508 S     0,0  0,9   0:00 bash
15209 methody    9   0   640  476   472 S     0,0  0,8   0:01 startkde
15185 methody    9   0   564  408   408 S     0,0  0,7   0:00 startx
15364 methody    9   0   304  276   256 S     0,0  0,5   0:00 kwrapper

Первое, что бросилось ему в глаза -- множество процессов, запущенных явно средой KDE (кому же ещё может принадлежать программа kdeinit?), Мефодий подсчитал число процессов, начинающихся на "kde" (ps ax | grep kde | grep -v grep | wc -l) -- их оказалось 17 штук. Каждый из этих процессов затребовал у системы по три-четыре мегабайта памяти (поле SIZE), из которых полтора-два (поле RSS) немедленно использовал. Не так уж и много, если бы такая программа запускалась одна. Но две дюжины kdeinit вполне способны израсходовать всю оперативную память компьютера, если объём его физической памяти равен, как на компьютере Мефодия, 64 мегабайта (из них порядка девяти мегабайтов заняло ядро -- эта память не отображается в поле mem -- и сколько-то уходит на сам X-сервер и прочие программы, не принадлежащие Мефодию).

Впрочем, даже в таком состоянии Linux продолжает работать довольно-таки бодро. Дело в том, что большинство из этих процессов (по словам top -- все, коме одного, самого top, об это говорит строка "1 running") в данный момент неактивны (sleeping). Большинство полученных ими ресурсов система давно уже отправила в область подкачки (swap) на диске. Затруднения начнутся, если несколько неактивных программ "проснутся": система начнёт поднимать из swap их ресурсы, а чтобы для них хватило места в оперативной памяти -- откачивать туда память других программ (отсюда и неожиданная дисковая активность, на которую Мефодий обратил внимание). Хуже всего, если для работы всех активных процессов одновременно не хватает места, тогда процесс откачки-закачки будет отнимать большую часть процессорного времени, для полезных задач его просто не останется. Определить такую ситуацию (она называется "дребезг", threshing), можно по высоким значениям полей system, а ещё по постоянно ненулевым значениям в полях si и so команды vmstat.

   procs                      memory      swap          io     system      cpu
 r  b  w   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id
 0  1  0 106092   1352   1168  19380   14   10   265    33  127   407 14  4 82

Этот опыт произвёл отрицательное впечатление на Мефодия, и он решил устраивать себе графическое рабочее место на основании какого-нибудь менее громоздкого инструмента. Впрочем, провести границу, где заканчиваются обязанности диспетчера окон и начинаются ухищрения рабочего стола, очень трудно. Видимо, разумно считать, что диспетчер окон делается средой рабочего стола, когда появляются пользовательские приложения с использованием его особых свойств и его библиотек. Если главная задача рабочего места -- запускать xterm, то достотачен даже очень старый диспетчер окон twm (он есть в составе X.Org, но редко используется по причине некрасивого, "плоского" оформления интерфейса). Вместо него можно использовать диспетчеры, подобные IceWM или OpenBox, обладающие большими возможностями, и при этом нетребовательными к ресурсам. Диспетчеры в среде XFCE, WindowMaker или fwvm, предоставляют множество возможностей, дополнительных модулей и мелких удобств. Они гибко настраиваются, не "вытягивая" за собой ресурсоёмких программных структур, используемых в KDE или Gnome.

Поразмыслив, Мефодий решил остановиться на WindowMaker: система меню показалась ему приятной для глаз, а способ быстрого запуска -- удобным. Кроме того, его позабавили "активные иконки", шевелящиеся в момент запуска соответствующего приложения.

(1) Такие системы -- не теоретическая выдумка, они вполне реальны и многочисленны. Например, графический интерфейс совершенно ни к чему на сервере, который занимается только маршрутизацией пакетов в сети.

(2) Каким пользователям разрешено запускать и останавливать графическую систему -- зависит от профиля системы.

(3) В некоторых вариантах X Window System экран по умолчанию раскрашивается в чёрно-белую крапинку.

(4) Эта функция не будет работать, если в конфигурационном файле X-сервера включён параметр "DontVTSwitch".

(5) Кроме этого файла в домашнем каталоге пользователя можно обнаружить файл .Xresources, очень похожий по функции и аналогичный по синтаксису. Разница между этими файлами в использовании: .Xresources загружается только в процессе исполнения xinitrc при помощи утилиты xrdb, а .Xdefaults в дополнение к этому читается автоматически средствами libX11.

(6) Не путать с диспетчером экранов, который занимается совсем другим: подменяет утилиту login.