сумбурно обо всём

/*
часть 1-я, мелочная

"взмах крыла бабочки может породить бурю", так и в этот раз одна приятная мелочь (sic!) потянула за собой хуеву тучу изменений. имя этой "мелочи" - модуль E17-го "Places":



модуль написан товарищем DaveMDS и сегодня мы его довели в svn до идеального состояния. цель - гуй для мониторинга носителей и операций с ними при помощи связки dbus+udev+hal от лица простого юзера. тыканьё на иконку носителя конфигурируется и может запускать как любимый ФМ (после монтирования), так и любые скрипты на ваш выбор (естественно без эскалации привилегий).

для этого нужно было понять как именно работает махина "dbus+udev+hal" и разобраться в дивных xml настройках сего хозяйства. дальнейшее повествование будет чуток специфично относительно дистрибутива OpenSUSE, но может кому-то и пригодится. началось с попыток взнуздать гугл, но "пейсателей" развелось... посему клич "поможите люди добрые" был брошен на ЛОР-е:

поможите люди добрые

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

1) основные правила определяются .fdi файлами. искать тут:

/usr/share/hal/fdi
/etc/hal/fdi

2) информацию о девайсах, которыми можно управлять (это в принципе инструмент очень тонкой настройки) вам выдаст команда (пакет 'hal'):

/usr/bin/hal-device

"рулить" можно как составляя свои правила, так и при помощи команд:

/usr/bin/hal-get-property (получение сведений/свойств)
/usr/bin/hal-set-property (установка новых свойств устройству)

3) man PolicyKit - ОБЯЗАТЕЛЬНО к прочтению и пониманию почему (может блокироваться) блокируется то или иное свойство/действие, заданное/разрешённое в правилах. сам 'polkit' - тема отдельного разговора. зело мощная дубинушка и махать ей направо-налево надобно крайне осторожно (как впрочем и любыми инструментами, непосредственно работающими с железом).

4) (самое болезненное по крайней мере для меня обстоятельство) работа с dbus+udev+hal требует отказа от всех старых проверенных методов обращения с девайсами. если вы (как и я) привыкли к kernel automounter-у и autofs (где всё настраивается двумя линиями внятного текста в конфиге) - пришло время от этого отказаться. также если вы хотите монтировать/демонтировать диски при помощи hal, то /etc/fstab не должен содержать записей о них.

5) внимательно читайте инструкции/маны ибо (например) если сделать 'eject' на partition диска - не удивляйтесь если "отвалится" весь диск :).

итак, начинаем с того, что разрешаем пользователю оперировать с девайсамм от лица юзера через hal при явном указании "полкану" не мешать (это по сути самая важная часть):

> cat /etc/PolicyKit/PolicyKit.conf
pastebin.com

после этого выбираем только те партиции/диски, которые хотим видеть в этом модуле. для этого необходимо присвоить "ключу" 'volume.ignore' параметр 'false' (если желаем мониторить) или параметр 'true' (если хотим скрыть партицию/диск). пример команды (для мониторинга партиции):

sudo hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_80A8_1512' --key volume.ignore --bool false

также подобным макаром можно проставить метку/label на партицию (любой носитель):

sudo hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_80A8_1512' --key volume.label --string AUDIO

выше мы проставили метку 'AUDIO'. на этом собственно всё. модуль сегодня допилили и теперь пользователи Enlightenment-DR17 имеют в своём распоряжении отличный гуй для управления съёмными и фиксированными носителями. адрес проекта:

Dave's blog
адрес Google code

пользователи E в OpenSUSE могут просто пересобрать src.rpm и установить пакет, скомпиленный из current svn (в репо слегка устаревшая версия, что не позволяет отмонтирование пользованием локальных партиций по щелчку на кнопке).

часть 2-я, галопом по европам

починили 'esmart text object' - теперь E/ETK/EWL корректно реагирует на символы при переключении клавиатурной раскладки Xorg-ом. надеюсь, что починят и scim input method (базовый код уже в Ешке присутствует) и пофиксят глупый баг с нерабочим 'language' модулем (гуйня для переключения раскладок клавиатуры на лету). эх, лень моя... самому-бы надо...



активно дорабатывают новую дефолтную тему 17-го "Black&White". панель настроек унифицировали с illume (по крайней мере идёт активный поиск оптимальных диалогов конфигурации).



описать в двух словах все новости проекта Enlightenment не получится. при этом "допиливается" не только 17-ый, но и Enlightenment-DR16, что весьма радует. именно так и надо организовывать поддержку Продуктов. горд и доволен. завтра обещают прикрутить online интерфейс для скачивания тем/обоев не только с get-e.org, но и с E-Exchange. ждём-с.

часть 3-я, око-ёко-OpenMOKO...

выслушал упрёки анонимного пользователя телефона Free Runner о невозможности кастомизации интерфейса и подстойке его "под себя". удивился, заново полез в qemu и хватило ума обновиться без бэкапа (чего даже во хмелю не допускаю). инструкции по поводу запуска openmoko в qemu можете почитать тут:

общая инструкция
с использованием MokoMakefile

если будете этим заниматься прям сейчас - то во-первых нихуя у вас не заработает, а во-вторых последние development версии FR-а всё больше тяготеют к интерфейсу Qt/Qtopia (куда даже терминал засунуть не потрудились, что характерно - нахуя в Qt консоль?). другими словами Вам понадобится энное количество времени, чтобы:

1) найти рабочий билд кернела/лоадера
2) найти rootfs (корневую систему с дистрибутивом/ПО) с E17+illume в качестве GUI
3) прорюхать нужную команду для старта самого qemu (в целом предлагаемые шаблоны задают правильное направление поиска, но ... "есть нюансы", как говаривал Чапай).

скриншоты ниже сделаны "в ленивую", на qemu, слегонца "обточенном" даже без подключённой usb клавиатуры. всё сделано в гуях illume и 17-го:









как видим UI можно отстроить от и до. группировка приложений - в соответствии с xdg freedesktop спеками, темы оформления можно брать из E17-го, кастомизация интерфейса - такая же, как и в 17-ом (другими словами можно отстроить всё и вся. от виртуальных столов и до размера шрифта и типа его рендеринга). если вам интересна эта тема - оставьте здесь свой комментарий/пожелание и будем разбираться вместе.

к слову готовится новая редакция FR-а - gta03. будем надеяться, что аппаратная часть будет получше. в сегодняшних моделях (gta01 и gta02) шина обмена данными не блещет скоростью, из-за чего слышим справедливые упрёки о "тормозах". также дистрибутивы/сборки оптимальными как-то пока назвать не готов (есть вещи, которые не нравятся, но нет понимания пока насколько они критичны).

в целом это очень интересный и достойный продукт для энтузиастов Linux. сегодня там вроде как пофиксили GPS и пресловутые SMS-ки (в очередной раз? :)). всем же советую начинать именно с qemu. заодно некоторые могут узнать много нового о кросс/нативной-компиляции для ARM и специфике ARM-а как такового. в общем есть в этом мире, друг Горацио, множество забавных штукенций...

*/

Уменьшаем энергопотребление

/*

рассматривайте это как дополнение к статье товарища virens-а. там много написано... слов...

1. Монитор.

man xorg.conf на предмет DPMS, man xbacklight. плохие приблуды: klcddimmer, smartdimmer. хорошая приблуда - xvattr. обычно установить яркость на мониторе проще "подручными средствами" самого монитора. если у вас Enlightenment-DR17, то опции управления DPMS доступны в конфигурационной панели: Configuration Panel -> Screen -> Power Management.

2. Видеокарта.

профан, признаю. нормальное 2D, возможность хорошего рендеринга "картинки" MPlayer-ом, декодирование видео чипом GPU (xvmc) - вот сфера моих интересов. найти недорогой Matrox Parhelia-512 с видеопамятью от 128 Мб - предел мечтаний. в остальном imho рулят проприетарные драйвера nVidia. пока рулят. VIA, AMD/ATI и Intel прилагают очень много усилий для изменения данного факта. Intel же, как мне кажется, заинтересован в уничтожении производителей видеокарт как класса.

3. Винчестер.

man hdparm на предмет AAM и spindown (опции -M, -S). можно посмотреть на ключи -y и -Y. текущий статус винта проверяется как

sudo hdparm -C /dev/ВИНТ

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

примечание: держать сервис smartd включённым представляется весьма здравой идеей.

4. Оптические приводы и внешние винчестеры.

для cd/dvd приводов какой-то смысл есть в установлении фиксированной маленькой скорости вращения шпинделя (от 1 до 4-х). сделать можно так:

sudo eject -x 2 /dev/sr0

при смене диска (при открытии каретки) сей параметр обнуляется. если hdparm дотянется до внешнего винта - хорошо. нет - и суда нет.

5. Процессор.

узнать, что из управления частотой процессора cкомпилено модулем:

modprobe -l | grep cpufreq

узнать, что вообще доступно для текущей версии ядра:

zcat /proc/config.gz | grep -i freq

установить схему управления частотой процессора по умолчанию и саму частоту:

sudo cpufreq-set -g ondemand
sudo cpufreq-set -d 1000

примечание: пользователи Enlightenment-DR17 могут устанавливать/менять параметры работы процессора на лету при помощи модуля 'cpufreq'.

5. Процессор.

Мониторить систему поможет пакет sensors: man sensord, man sensors-detect, man sensors. Можно попробовать старый добрый gkrellm или прикрутить вывод статистики при помощи conky - на ваше усмотрение.

*/

сетевые интерфейсы

несколько совершенно элементарных опций, которые могут иногда пригодиться. вешаем 2-ой/энный интерфейс на сетевую карточку:

sudo ifconfig eth0:0 192.168.5.2
sudo ip addr add 192.168.5.3 dev eth0

ставим uml_utilities (User Mode Linux) и получаем возможность работать с "туннелями":

sudo modprobe tun
sudo tunctl -u user -t tun0 -f /dev/net/tun
sudo ifconfig tun0 192.168.5.1 up

пакет bridge-utils даст brctl - инструментом для "мостостроения" между различными сетями ethernet.

для экспериментов с виртуальными туннелями подойдёт пакет vtun. очень душевное описание работы с vtun:

http://www.citforum.ru/nets/articles/vpn_linux/
http://palm.opennet.ru/base/net/vtund_bridge.txt.html

и "король" операций с сетевыми интерфейсами - пакет iproute, с документацией, переведённой на русский язык :

http://megalib.com/books/1346/lartc.html

для управления режимами работы сетевой карты (дуплекс и т.п.) - ethtool.

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

самые простые вопросы - самые сложные... наверно да, посему и возникла мыслишка построить тут некую "песочницу" для "ниасиливших ямба с хореем"...

вопрос первый - где в ентом линуксе папочка, куды ярлычки на автозагрузку накидать можна, ась? и начинается дурдом. умники на форумах спрашивают какой WM/DE, чего-то там бубнят про сессии и ещё чёрт поймёт про что. а решение-то лежит на поверхности. и по старой доброй *nix традиции способов сих (приёмов и ухваток) множество (не стесняйтесь дополнить в комментариях чего упущено):

1. вопрос пусть и некритичный, но "влияющий на количество опций" - нужны ли нам иксы. если нет - то наилучшим местом для автозагрузки "глобально" будет модификация /etc/profile или ~/.profile для каждого пользователя.

2. если пользуем иксы - можем поиграть с Xsession (~/.xsession + ~/.xinitrc), создав скриптики с привязкой автозапуска к используемому WM/DE (не наш метод, но он вполне оправдан во многих жизненных ситуациях).

вопросами размера окон этих приложений, расположением на виртуальных столах и прочими "оконными" параметрами должен управлять WM. вот например шотик с "джентельменским набором" от Enlightenment-а:

то бишь настроил разок, запомнил и все дела. теперь можем спокойненько дописать в конец ~/.profile что-то похожее на:

if [ "`ps aux | grep mpd | grep -v grep`" = "" ]
then mpd &
fi

if [ "`ps aux | grep X | grep -v grep`" = "" ]
then exit
fi

if [ "`ps aux | grep stardict | grep -v grep`" = "" ]
then stardict &
fi

сперва мы проверяем, запущен ли демон mpd, если нет - запускаем его в "фоновом" режиме. потом - очень грубо смотрим на наш икс-сервер (есть ли возможность запускать приложения с GUI), если иксов нет - выходим не прощаясь, ежели что-то есть - пытаемся запустить stardict. в этом же духе можно продолжать пока не иссякнет фантазия.