В меру лирическое вступление
Судя по всему, Linux "дорос" до состояния, когда им стали пользоваться люди, достаточно далёкие от вычислительной техники. Книги, журналы, on-line публикации всё чаще посвящаются использованию Linux в качестве десктопной ОС. Начисто лишённая средств разработки Ubuntu запросто теснит в рейтинге популярности дистрибутивов ориентированный на корпоративное использование Red Hat Enterprise Linux, а на форумах линуксоидов обсуждаются вопросы, само появление которых не оставляет сомнений: Linux используют люди, не подозревающие о существовании каких-либо компьютеров, кроме персональных, а понятия ОС и MS Windows до недавнего времени считавшие синонимами.
Число пользователей Linux увеличилось и, наверное, это хорошо, поскольку, как минимум, является свидетельством того, что идеи unix и энтузиазм сторонников open source привели к появлению ОС, которая уже сегодня может использоваться как ОС для десктопов.
При этом доля разработчиков от общего числа пользователей уменьшилась, что представляется вполне естественным. А между тем, своим появлением и развитием Linux обязан именно "ботаникам" и "революционерам", которые работают не благодаря организующему началу капитала в лице бизнес-менеджера, а лишь потому, что "интересно", "хочется" или "из принципа". Довольно часто — этому самому менеджеру вопреки.
Зададимся вопросом: откуда такие энтузиасты берутся? Не почкованием же их размножают? Рискну предположить, что "они" — это те же "мы", но заинтересованные до состояния энтузиазма. Осталось выяснить, насколько система, "абсолютно дружественная к пользователю" (эдакий набор кнопок для удовлетворения желаний) способствует появлению подобной заинтересованности. Сомнительно... И если развитие Mac OS - это забота Apple Co., то кто в отсутствие энтузиастов позаботится о развитии Linux? И как много таких энтузиастов найдётся, если система перестанет быть интересной? Если нет жадного капиталиста, принуждающего программистов искать всё новые пути развития ПО (а в отношении Linux это так и есть), то кто стимулирует это поиск?
Получается:
- для развития и существования (а в данном случае это одно и то же) Linux нужны энтузиасты;
- энтузиасты - это "особо" заинтересованные пользователи;
- а заинтересованность пользователей (имеется в виду заинтересованность в развитии системы, разумеется) тем менее вероятна, чем лучше Linux отвечает пользовательским потребностям — всё и так есть.
По-моему, круг замкнётся, если система не будет интересной на фоне достигнутой "дружественности к пользователю". Выход один: показывать, что интересной может быть модификация системы, даже вполне "удовлетворяющей" тебя изначально.
Именно в этом Linux разительно отличается от MS Windows: и та, и другая системы более-менее успешно служат удовлетворению потребностей пользователя, но только одна из них предлагает (и даже "призывает") поучаствовать в собственном развитии.
С точки зрения "чистого пользователя" разница эта может казаться совершенно несущественной. Linux-публикации в этом случае сведутся к ответам на вопрос "как пользоваться", а анализ новых дистрибутивов будет заключаться в обсуждении наличия в них графического инсталлятора, проприетарных кодеков и кириллизации "из коробки". Тоже интересно. Но время от времени у некоторых пользователей возникает вопрос "как сделать", и поиски ответа на него оказываются значительно интереснее "просто пользования". Именно в этот момент пользователь рискует пополнить собой ряды вышеупомянутых энтузиастов.
На этом "философскую преамбулу" можно считать законченной, а нижеследующий текст как раз и представляет собой попытку продемонстрировать эффективность методологии unix (известной как unix-way) в рамках "десктопных" задач из числа тех, полезность решения которых представляется "простому пользователю" очевидной. Разумеется, это скорее о том, "как сделать", чем "как пользоваться". Хочется, знаете ли, как-то содействовать "рекрутированию" энтузиастов open source из рядов "просто пользователей".
1. Применяя принципы...
Итак, что же могут дать пресловутые unix way и open source "простому пользователю", кроме бесплатной и уже довольно дружественной, если по судить по интерфейсу, ОС? Оказывается, кое-что могут. Оставим профессионалам возможность самостоятельного написания драйвера под любимую "железку" (будь то фотоаппарат от Canon или мобильник от Samsung) и обратимся к такой простой задаче, как мониторинг системы. Задача-то простая, но слишком масштабная, если учесть всё многообразие аппаратных средств, усугубляемое разнообразием потребностей: кого-то интересует температура процессора, а кого-то — интернет-трафик. Вот и множится число всевозможных "измерялок", а как хотелось бы всегда иметь "под рукой" данные, которые интересуют именно тебя...
С точки зрения unix-way, для реализации такого "идеального монитора" требуются две вещи:
- надёжные, по возможности элементарные, средства получения интересующей информации;
- интерфейс, позволяющий произвольно компоновать вывод на основании этой самой полученной информации.
Согласимся с тем, что gui-интерфейс доминирует на десктопах пользователей. Отметим также, что общепринятым "местом" вывода системной информации, является, как правило, system tray. У этого "места" есть, как минимум, два недостатка: ограниченный объём и зависимость от используемого window-менеджера или DE (никогда нельзя быть уверенным, что не найдутся таковые, которые откажутся выводить желаемое в правом нижнем углу экрана. Но и использование для системного монитора специального окна — не самое лучшее решение. Окон много, они имеют обыкновение перекрываться, а у нас только "рабочих столов" — четыре... Выход один: иметь визуализирующую часть, опирающуюся исключительно на X-Window, а выводить системную информацию прямо на десктоп, благо такая возможность имеется.
Не исключено, что приблизительно так рассуждали авторы Conky (http://conky.sourceforge.net). Во всяком случае, по умолчанию conky именно так и работает: выводя данные на десктоп в режиме так называемой "псевдо-прозрачности". Последняя заключается в том, что перед каждым выводом conky сначала "считывает" часть десктопа, затем дополняет её собственной информацией, а на последнем этапе опять выводит на десктоп, но уже со своими данными, разумеется.
Можно считать, как единое средство вывода "идеального монитора" conky нас вполне устраивает. Забегая вперёд, скажу, что conky, конечно, не только средство вывода. При работе программа определяет свыше сотни переменных, значения которых можно выводить непосредственно, без каких-либо дополнительных действий. Впрочем, "нельзя объять необъятное". И авторы это прекрасно понимают. Помимо параметров системы, определяемых conky непосредственно, в вывод можно включать результат работы любых программ. Нужно только, чтобы результат этот был представлен в ascii-коде, то есть — как текст. Вполне естественное пожелание в рамках unix-way. И достаточно просто выполнимое: очередной реверанс в адрес posix-систем, для которых текстовый ввод/вывод — правило.
Использование принципов unix-way в данном случае — налицо. Осталось оценить, насколько это может быть полезным.
2. Немного деталей...
Результат запуска "свежесобранного" conky представлен ниже:
Неплохо, но не совсем то, что хотелось бы. Нетрудно догадаться, что "подгонка" монитора под собственные потребности выполняется редактированием файла ~/.conkyrc (получаемого, в свою очередь, путём копирования в домашний каталог дистрибутивного файла conkyrc.sample). Часть переменных, определяемых в этом файле, задают атрибуты вывода (позиция, цвет, бордюр, тени и т.п.). Поскольку углублённое изучение настроек conky не является предметом настоящей статьи, то и описывать их все мы не будем. Ограничимся лишь тремя, задав использование Xft, фонт и позицию вывода:
use_xft yes
xftfont terminus:size=14
alignment top_right
Ещё одна группа переменных описывает параметры Mldonkey, MPD и pop3 серверов. Тут уж — каждому своё. Кто-то жить не может без MPD (Music Player Daemon), кому-то достаточно периодической проверки почтового ящика, а кого-то (как меня, например) не интересует ничто из перечисленного.
Самым же интересным в ~/.conkyrc, на мой взгляд, является непарный тег TEXT. Всё, что следует вслед за ним, будет выводиться conky с частотой, заданной переменной update_interval (умолчание — 10 сек). И пусть вас не вводят в заблуждение "решётки" в первой позиции строки: последняя строка, которую можно "закомментировать" таким образом, — это строка "TEXT". Далее же: сколько строк есть в ~/.conkyrc после тега TEXT, столько строк и будет выводиться.
Переменных, допустимых к использованию в секции TEXT, как уже было отмечено выше, более сотни. Условно можно разделить их на следующие группы:
- атрибуты декорирования вывода (фонт, цвет, выравнивание);
- данные хоста, системы и ядра;
- данные CPU;
- данные по использованию памяти;
- данные выполняемых процессов;
- переменные acpi и apm (FreeBSD only);
- данные hardware-мониторинга;
- данные файловой системы;
- данные сетевого обмена;
- счётчики непрочитанных почтовых сообщений;
- данные BMPx, MPD, Seti и xmms;
- данные log-файлов;
- данные времени;
- управляющие переменные.
Есть ещё специфические переменные для ноутбуков IBM Inspiron, переменные, обеспечивающие преобразование кодировок, довольно мощный монитор TCP-портов. Наряду с переменными, значения которых представляют собой текстовые строки, некоторые переменные обеспечивают вывод диаграмм и графиков, отражающих динамику изменения параметра. Спору нет: возможности conky впечатляют, но, во-первых, детальное изучение переменных, допустимых к использованию в секции TEXT (коих, как уже было отмечено, более ста), опять-таки, не входит в наши планы, а во-вторых, даже столь обширные возможности всё равно всех не удовлетворят.
И как раз поэтому существуют управляющие переменные, назначение которых - запускать внешние скрипты и программы, а также обеспечивать выполнение по условию. И переменных-то этих всего ничего:
- exec[bar|graph]
- if_[running|existing|mounted] ... endif
- else
- [t]execi[bar|graph]
Но "мал золотник — да дорог", поскольку посредством именно этих переменных мы получаем возможность передать conky практически любые данные, которые только можно получить в системе.
Назначение переменных в основном понятно из их названий:
- exec выводит на экран текст, возвращаемый вызываемой программой;
- execbar и execgraph визуализируют вывод исполняемой команды в виде диаграммы или графика (выводимое значение должно лежать в пределах 0..100);
- execi и texeci запускают команду циклически с интервалом (texeci — с интервалом, заведомо большим времени исполнения). execibar и execigraph полностью аналогичны execbar и execgraph, но для циклического выполнения команд;
- if_running, if_existing и if_mounted — выводят всё вплоть до endif, если выполняется процесс, существует файл и монтирована точка монтирования, соответственно;
- else — выводить, если ложны все вышестоящие выражения.
Заинтересовавшимся возможностями conky помимо входящих в дистрибутив пакета config_settings.html и variables.html можно рекомендовать познакомиться с конфигурациями и скриптами, представленными на странице http://conky.sourceforge.net/screenshots.html. Незнание английского, таким образом, можно компенсировать изучением примеров ~/.conkyrc.
Мы же проиллюстрируем не столько собственные возможности conky, сколько использование её для вывода произвольной информации.
3. Иллюстрации
Предположим, есть желание осуществлять мониторинг температурных датчиков и работы вентиляторов компьютера. Вариантов только два: либо использовать возможности шины SMB (System Managment Bus), известной также как i2c (если речь идёт о более-менее стандартном десктопе), либо — возможности acpi (если речь о современном ноутбуке). И в том, и в другом случае необходимая функциональность ядром обеспечивается (если оно 2.6, разумеется).
В первом случае (предполагаем, что Вы уже воспользовались пакетом lm_sensors и все необходимые модули загружены) достаточно выводить переменную i2c, указав тип (fan/temp) и номер датчика (придётся внимательно изучить /sys/bus/i2c/devices/). Получится что-то вроде:
CPU Temp: ${i2c temp 2}C - Fan: ${i2c fan 3}
Разобраться, какой датчик чему соответствует — ваша задача. На мой взгляд, это всё-таки лучше, чем готовая утилита, явно "путающая" датчики процессора и M/B.
Только во втором случае так просто не получится: хотя переменные acpitemp и acpifan существуют, но в единичном экземпляре, тогда как у вас может оказаться 3-4 температурных датчика и столько же вентиляторов. Ещё хуже то, что количество датчиков и вентиляторов вполне может не совпадать с количеством подкаталогов в /proc/acpi/thermal_zone и /proc/acpi/fan, соответственно. Ничего удивительного: ACPI BIOS может быть один и тот же у семейства ноутбуков, тогда как количество вентиляторов — характеристика модели.
Для преодоления обнаруженных трудностей есть, как минимум, три способа:
- переписать Linux.c из состава conky, заставив её присваивать переменным acpitemp и acpifan именно интересующие вас значения (совсем не так сложно, как можно подумать: всего лишь исправить строку, указывающую путь к нужному датчику) — open source мы в конце концов используем "или где?";
- воспользоваться внешней программой (например acpitool Дэвида Лиманса (David Leemans);
- получить данные непосредственно из ядра.
Даже любителю программировать на "С" совершенно очевидно, что последний вариант — наиболее рациональный. Нужная строка будет выглядеть так:
CPU Temp: ${execi 10 cat /proc/acpi/thermal_zone/TZ1/temperature | cut -b26-27}
Комментарий: execi с интервалом в 10 секунд читает файл /proc/acpi/thermal_zone/TZ1/temperature и передаёт его программе cut, которая в свою очередь, "вырезает" из неё байты 26..27. Эти два байта и представляют собой значение температуры в градусах Цельсия в форме двузначного числа. Именно они и будут выведены на экран. Для трёх датчиков строка получится втрое длиннее, для каждого из датчиков имя подкаталога TZN — своё.
Аналогично:
Fan: ${execi 10 cat /proc/acpi/fan/C263/state | cut -b26-}
AC: ${execi 10 cat /proc/acpi/ac_adapter/C16F/state | cut -b26-}
выведут состояние одного из вентиляторов и наличие внешнего источника питания (ключ cut -b26- означает: от 26-го байта и до конца). Все уточнения — по 'man cat' и 'man cut'
Вполне вероятно, что в случае с acpi не поможет и предлагаемая переменная battery. В этом случае для того, чтобы получить текущую ёмкость заряда батареи, строка ~/.conkyrc должна выглядеть приблизительно так:
Bat: ${execi 10 cat /proc/acpi/battery/C171/state | grep remaining | cut -b26-}
Очевидно, что данная строка отличается наличием "grep remaining" между выводом cat и вводом cut. Это связано с тем, что в данном случае файл state содержит несколько строк, а grep как раз и выделяет из них нужную.
Степень заряда батареи более естественно было бы выразить в процентах. Но такой информации ядро нам не предоставляет. Есть, однако, всё необходимое для расчёта требуемой величины. Строкой в ~/conkyrc на сей раз обойтись не удастся. В качестве возможного решения можно написать небольшой скрипт под названием bat_cents.sh, например. Поместить его в подходящее место (а, хотя бы и в ~/bin/) и вызывать его из conky следующей строкой:
Bat(%):${execi 30 ~/bin/bat_cents.sh}
Сам же скрипт выглядеть может так:
#!/usr/bin/bash
MAX=`cat /proc/acpi/battery/C171/info | grep 'design capacity:' | cut -b26-29`
CUR=`cat /proc/acpi/battery/C171/state | grep remaining | cut -d':' -f2 | cut -d' ' -f7`
PRC=$(( $CUR * 100 / $MAX ))
echo $PRC
Комментарии:
MAX и CUR - переменные, получаемые способом, аналогичным описанному для ~/conkyrc
CUR получается следующим образом (третья строка скрипта):
- grep remaining извлекает нужную строку из файла /proc/acpi/battery/C171/state
- cut -d':' -f2 выделяет из этой строки численное значение ёмкости батареи (фактически: выделяет 2-е поле, если разделителем считать символ двоеточия)
- cut -d' ' -f7 "убирает" из полученной подстроки единицы измерения (фактически: выделяет 7-е поле, если разделителем считать символ пробела)
PRC - результат вычисления выражения на языке bash
echo $PRC - вывод этого результата.
Разумеется, для "красоты" можно представить изменения показаний температурного датчика и уровень заряда батареи в виде графика:
${execigraph 10 cat /proc/acpi/thermal_zone/TZ1/temperature | cut -b26-27}
${execigraph 30 ~/bin/bat_cents.sh}
Хотя мне представляется более полезным в одной строке видеть три значения температуры, в другой — три флага работы вентиляторов, и численное значение уровня заряда батареи — в третьей. Например, так (верхний правый угол экрана):
На 3-D десктоп это похоже мало, но зато может быть полезным.
Таким образом, если в качестве исполняемых применять собственные скрипты, то предметом мониторинга может быть что угодно: температура воздуха в Лондоне, количество законченных технологических циклов АСУ, фамилия дежурного оператора, состояние склада или количество выписанных за текущие сутки счетов. Мне, признаться, трудно представить, какие ещё данные могут потребоваться пользователю на десктопе. Для рабочих станций АСУ, являющихся предметом моей ежедневной заботы, это: количество свободных портов УСО (Устройства Связи с Объектом), загрузка канала ethernet, наличие в сети моделирующей задачи и т.д. — вряд ли это кому-либо интересно.
А вот знакомство с упомянутыми выше скриншотами может быть в этом смысле более информативным. Кто-то выводит посредством conky любимый RSS Feed, кто-то наблюдает за ходом выполнения emerge (для незнакомых с Gentoo: emerge — команда инсталляции ПО, выполняющаяся подчас очень долго, поскольку включает в себя загрузку исходных текстов, патчей к ним, а потом и компиляцию ПО), кто-то регулярно проверяет gmail — и так далее вплоть до дискографии исполнителя, композиция которого проигрывается в настоящий момент xmms. Воистину: фантазия человека, самовыражающегося в творчестве — неисчерпаема.
В заключение несколько слов о старте cronky. С одной стороны, исходный тарбал программы не предлагает единого способа автозапуска. Да и возможен ли он при существующем разнообразии window-менеджеров и DE? Программа имеет специальный ключ (-d) для запуска в качестве "демона". Дабы не засорять память процессами, единственное назначение которых — запуск приложения, ключом этим, безусловно, стоит воспользоваться. Так, если при использовании KDE достаточно поместить ссылку на cronky в каталог ~/.kde/Autostart, то для icewm, придётся отредактировать общий стартовый файл (обычно: /usr/X11/share/icewm/startup, хотя это и не аксиома для всех дистрибутивов). Файл должен содержать строку:
conky -d
К сожалению, ничего не могу сказать по поводу Gnome — не пробовал.
Способы автозапуска несколько диссонируют с "прямыми как стрела" обращениями к ядру, не правда ли? "Шаманство" какое-то... Не могу не согласиться. В оправдание скажу лишь, что при этом универсальный способ запуска посредством командной строки (conky -d или conky&) по-прежнему работает. Нужно только найти, в какой файл эту строку поместить. Что подчас бывает не просто. И это тоже — Linux.
Заключение
И что же из этого всего следует? Не сложилось ли у читателя впечатление, что автор пытается навязать ему "конструкторскую" (чтобы не сказать "слесарную") манеру использования IBM PC? Отнюдь. Автор только хотел обратить внимание на то, что unix-way может быть полезен и на пользовательском десктопе.
Пусть будет больше реализаций Linux, допускающих использование "из коробки", пусть их дружественность к пользователю будет не хуже (или лучше?), чем у MS Windows. Но пусть при этом сохранится возможность соучастия в создании собственной системы, желательно не только на уровне выбора "обоев". Кому-то захочется изящным скриптом автоматизировать ежедневные операции, а кто-то посчитает для себя возможным заняться расширением функциональности ядра — бывает и такое...
Охотно верю, что число последних всегда будет меньше в сравнении с числом "просто пользователей" Linux, а в сравнении с числом пользователей IBM PC, быть может, просто пренебрежимо мало. Но они есть и, между прочим, именно благодаря им появились и Linux вообще, и возможность его использования в качестве ОС для десктопа — в частности.
