Программный продукт, использующий 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В левом верхнем углу открылось окно 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 как текстовое, позволяет отметить (при постоянно нажатой первой кнопке или последовательными нажатиями третьей) часть текста. Выделенный текст можно немедленно вставить в любое окно текстового ввода нажатием второй кнопки. Утилита xcutsel предоставляет возможность работы с буфером обмена cutbuffer), в котором текст может храниться сколь угодно долго.
Сеанс работы с X11
Как догадался Мефодий, команда startx делает несколько больше, чем просто запуск X-сервера, она кроме того запускает несколько X-приложений. Для удобной работы в X11 пользователю прямо при запуске графической подсистемы потребуется сразу несколько приложений. Во-первых, нужно запустить приложение, которое позволит управлять окнами (как минимум перемещать их), чего не делает сам X-сервер, такие приложения называются диспетчеры окон и будут обсуждаться немного позднее. Кроме того, полезно сразу запустить разные мелкие программки, вроде индикатора загрузки системы xload или экранных часов xclock. Сам X-сервер не мешает настроить с помощью xset (можно поменять курсор, звуковой сигнал, переименовать кнопки мыши). Одним словом, пользователю, как правило, нужен небольшой стартовый сценарий, который запускался бы вместе с X-сервером.
С другой стороны, сервер хорошо бы останавливать, когда он больше не используется. Это, конечно, относится к схеме без диспетчера экрана (xdm): пользователь работает с терминала, потом запускает X-сервер для выполнения графических программ, выполняет их и останавливает сервер, чтобы графическим устройством мог воспользоваться кто-нибудь другой. Стандартный способ аварийного завершения работы XFree86 (Ctrl + Alt + Backspace), во-первых, доступен только на XFree86, во-вторых, его можно отключить, а в-третьих, все запущенные приложения порлучат в этом случае сообщение о внезапной смерти сервера и тоже завершатся аварийно.
Если запускать не сам X-сервер, а некоторую оболочку вокруг него, называемую startx, то алгоритм работы будет такой. Сначала запустится X-сервер и сформирутся значение переменной окружения DISPLAY. Затем запустится сценарий .xinitrc, находящийся в домашнем каталоге пользователя, а если такого нет — системный стартовый сценарий /usr/X11R6/lib/X11/xinit/xinitrc. Предполагается, что X-сервер будет работать до тех пор, пока выполняется . xinitrc. Когда все команды из .xinitrc отработают, его выполнение завершится, а вместе с ним завершится и сервер. Поэтому рекомендуется все X-приложения из .xinitrc, кроме последнего, запускать в фоне, чтобы командный интерпретатор не дожидался окончания их работы. В этом случае с завершением последнего приложения из .xinitrc завершится и сам X-сервер. Последней программой в стартовом сценарии может быть xterm, как это сделано в стандартном xinitrc, или диспетчер окон. Для завершения xterm (а с ним и всего сеанса работы X11) достаточно послать «^D» запущенному в нём shell, а окновод обычно имеет какую- нибудь кнопочку или менюшку «Exit». Программа, с завершением которой завершается сеанс X11, называется лидером сеанса (session leader).
Лидер сеанса может быть указан и в качестве параметра startx в командной строке, например, по команде startx /usr/X11R6/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, со своей стороны, предоставляет универсальный способ хранить такие настройки в файле. Многие приложения хранят свои настройки по умолчанию в /usr/X11R6/lib/X11/app-defaults/ИмяКласса (в некоторых системах этот каталог перенесён, как ему и подобает, в /etc/X11). ИмяКласса — это имя класса самого главного окна этого приложения. Пользователь может дополнить настройки ресурсов, которые сервер накапливает при старте, при помощи команды xrdb -merge файл_настроек или переписать их заново (ключ «-load»). Приложению остаётся только вызвать специальную функцию Xlib, которая считывает настройку с определённым именем из таблиц сервера. Если xrdb не запускалась ни разу (в том числе и в стартовом сценарии), запрос приложения направится не в таблицу сервера, а непосредственно в файл ресурсов .Xdefaults, лежащий в домашнем каталоге. В этом случае для изменения настроек не надо запускать xrdb.
Кроме файла .Xdefaults в домашнем каталоге пользователя можно обнаружить файл .Xresources, очень похожий по функции и аналогичный по синтаксису. Разница между этими файлами в использовании: .Xresources загружается только в процессе исполнения xinitrc при помощи утилиты xrdb, а .Xdefaults в дополнение к этому читается автоматически средствами libX11.
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).
Не путать с диспетчером экранов, который занимается совсем другим: подменяет утилиту login.
- диспетчер окон
- Программа, основная функция которой — обеспечивать манипуляции с окнами: перемещение, изменение размера, сворачивание и т. п.
Благодаря стандартному протоколу X11 появилось такое множество диспетчеров окон для X Window System, что перечислить их все просто невозможно. Все они различаются видом и кругом возможностей для манипулирования окнами: от самых простых (рамочка вокруг окна позволяет двигать его, изменять размер и поднимать из глубины; собственно, всё) до весьма изощрённых (виртуальные экраны, анимированные полупрозрачные меню, панели интрументов, причудливой формы украшения на окнах; сами окна ползают по экранам, кувыркаются, растворяются как утренний туман; всё это лязгает, попискивает и разговаривает приятным женским голосом). Когда Мефодий в первый раз запустил команду startx, была запущена утилита wm-select, которая предложила ему выбрать, какой из установленных в его системе диспетчеров окон запустить.
Выбор диспетчера окон на свой вкус — очень непростое и вдумчивое занятие. Мы советуем просто соблюдать меру, сообразуясь с тем, для чего вы используете оконную систему: обилие ярких декораций отвлекает от работы (а если они вдобавок шевелятся?), а слишком строгий минимализм её усложняет. Имейте в виду, что чем причудливее и многообразнее возможности окновода, тем труднее будет его полностью настроить именно под себя. Скорее всего, вы просто согласитесь пользоваться уже настроенными — общеупотребительными — возможностями, не доводя их до совершенства.
Работа с окнами
Совершенно необязательно начинать сеанс работы в X11 с запуска диспетчера окон, его можно запустить в любой момент. Например, Мефодий может к уже запущенному им X-серверу подключить любой диспетчер окон, запустив его всё из той же виртуальной консоли. Например, чтобы запустить WindowMaker, достаточно выполнить команду wmaker.
WindowMakerС запуском диспетчера окон экран X-сервера заметно преобразился: одноцветный фон сменился изображением, по углам возникли квадратные кнопки, а вокруг окна xterm образовалась рамка с названием окна и кнопками. Эта рамка — «органы управления» окном, так называемые оконные примитивы (их собственное имя — «widgets» — сокращение от «window gadgets», «оконные безделушки»). «Ухватившись» мышью за рамку, Мефодий поменял размеры окна, а нажав на правую кнопку мыши на заголовке окна — увидел меню, состоящее из списка операций, которые можно произвести над этим окном. Все эти возможности предоставлены диспетчером окон WindowMaker.
Удобства
Однако помимо своей основной функции — операций с окнами — многие диспетчеры окон владеют массой других приёмов по упрощению работы пользователя и повышению наглядности. Самые главные из таких удобств — кнопки для запуска типичных задач: нажатие на кнопку заменяет собой выполнение команды в эмуляторе терминала. Команда может быть длинной или забываться, а нажатие одно и кнопка всё время на виду — это удобно для привычных повседневных действий. Например, в правом верхнем углу экрана WindowMaker присутствует кнопка с изображением монитора — для запуска xterm. Вторая важнейшая возможность — общее меню, в котором классифицированы доступные в системе приложения, при помощи такого меню пользователь может найти и запустить нужную прикладную задачу.
WindowMakerБольшое удобство, предоставляемое очень многими диспетчерами окон для 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
Пример 6. Загрузка компьютера во время работы KDE
Первое, что бросилось ему в глаза — множество процессов, запущенных явно средой 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
Пример 7. Вывод команды vmstat
Этот опыт произвёл отрицательное впечатление на Мефодия, и он решил устраивать себе графическое рабочее место на основании какого-нибудь менее громоздкого инструмента. Впрочем, провести границу, где заканчиваются обязанности диспетчера окон и начинаются ухищрения рабочего стола, очень трудно. Видимо, разумно считать, что диспетчер окон делается средой рабочего стола, когда появляются пользовательские приложения с использованием его особых свойств и его библиотек. Если главная задача рабочего места — запускать xterm, то достаточен даже очень старый диспетчер окон twm (он всегда есть в составе XFree86, но редко используется по причине некрасивовго, «плоского» оформления интерфейса). Вместо него можно использовать диспетчеры, подобные icewm или fluxbox, обладающие большими возможностями, и при этом нетребовательными к ресурсам. Если необходимо просто и незамысловато обеспечить доступ к основным пользовательским X-приложениям, подойдёт XFCE. Наконец, диспетчеры, подобные WindowMaker или fwvm, предоставляют множество возможностей и гибко настраиваются, не «вытягивая» за собой ресурсоёмких программных структур, используемых в KDE или Gnome.
Поразмыслив, Мефодий решил остановиться на WindowMaker: система меню показалась ему приятной для глаз, а способ быстрого запуска — удобным. Кроме того, его позабавили «активные иконки», шевелящиеся в момент запуска соответствующего приложения.