Wicd грузит процессор под 100%?

Уже довольно давно (месяца три) мучился с проблемой загрузки проца под 100% (причем обоих ядер) через какое-то время после загрузки Gnome. Вчера, в очередной раз намаявшись с тормозами системы, решил разобраться с проблемой. Htop показывал мне подозрительную загрузку процессора процессами python'а, связанными с wicd. Попытался их грохнуть, но тщетно, на них не действует даже SIGKILL. Остановка демона wicd, кстати, не помогла. Тогда из сеансов Gnome убрал wicd-client, заблокировал загрузку демона в rc.conf и перезапустил систему. Помогло! Более того, если после этого вручную запустить демон и клиент, то все равно система дышит ровно. Теперь вот все думаю, не слишком ли я увлекся параллельной загрузкой демонов? Возможно, wicd должен запускаться в определенном порядке, после полной загрузки некоторых демонов. Кстати, моя строка DAEMONS в rc.conf:

DAEMONS=(syslog-ng acpid !network hal @bluetooth @wicd !mpd netfs @alsa @samba @crond gpm @sshd hplip @cups @ntpd !tomcat @cpufreq fam !sensors !postgresql !avahi-daemon gdm)

Собираюсь поэкспериментировать с последовательностью загрузки...

Вести с полей: два непригодных к использованию диска за 17 миллионов рублей

Видя безразличие властей к проблеме внедрения СПО в школы, выкладываю ссылку на блог В.Алксниса:
http://v-alksnis2.livejournal.com/148057.html

Клавиатура определяется HAL

Решил-таки перейти на определение раскладки клавиатуры HAL'ом. Задолбался каждый раз заново настраивать xorg.conf при новой установке. Да и вообще запарило возиться с xorg'гом, ведь прогресс не стоит на месте.
Почитав у настроивших до меня, извлек для себя некоторую весьма полезную информацию.
В /usr/share/hal/fdi/policy/10osvendor находятся шаблоны XML-конфигов для HAL, нам нужен 10-keymap.fdi. В файле /usr/share/X11/xkb/rules/base.lst находятся опции настройки раскладки клавиатуры.
Собственно, начнем с xorg.conf. Удаляем в секции:

Section "ServerLayout"
Identifier "Xorg Configured"
Screen 0 "aticonfig-Screen[0]-0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "USB Mouse" "CorePointer"
EndSection

упоминание об устройстве ввода Keyboard0. Удаляем, соответственно, саму секцию:

Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us,ru"
Option "XkbVariant" "winkeys"
Option "XkbOptions" "grp:toggle,grp_led:scroll"
EndSection

выписав, естественно, свои настройки :) Разрешаем автодобавление новых устройств:

Section "ServerFlags"
Option "AutoAddDevices" "true"
EndSection

Или можно вообще удалить эту секцию, так как она была создана именно для блокирования HAL. Далее копируем указанный выше 10-keymap.fdi в каталог /etc/hal/fdi/policy/. Приводим этот файл к виду:


<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keymap">
<append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
</match>

<match key="info.capabilities" contains="input.keyboard">

<merge key="input.xkb.rules" type="string">base</merge>

<!-- If we're using Linux, we use evdev by default (falling back to keyboard otherwise). -->
<merge key="input.xkb.model" type="string">keyboard</merge>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux">

<merge key="input.xkb.model" type="string">evdev</merge>
</match>

<merge key="input.xkb.layout" type="string">us,ru</merge>
<merge key="input.xkb.variant" type="string">,winkeys</merge>
<merge key="input.xkb.options" type="string">grp:toggle,grp_led:scroll,caps:internal</merge>

</match>
</device>
</deviceinfo>


Чтобы настройки вступили в силу, надо перезапустить HAL и рестартануть X-сервер. После такой настройки мы хотя бы немного разгрузим xorg.conf от "лишней" информации. Огорчает только, что до сих пор не пофиксена "фича" с отсутствием реакции на двойной клик тачпада...

Проблема с просмотром сети в Nautilus решена

С недавних пор, сидя на Nautilus 2.26.2, заметил, что перестала просматриваться сеть, выскакивает ошибка "Не удалось получить список доступных на сервере ресурсов". При этом, если напрямую указать хост:

smb://server

то все отрабатывает без проблем. Порывшись в интернете после обнаружения ошибки, нашел жалобы только пользователей Ubuntu, но там грешили на smbclient.
Сегодня оказалось, что на него грешили напрасно. В репах появилось обновление Nautilus 2.26.3, которое исправляет ошибку, при этом smbclient не обновлен. По-моему, он вообще не причем, и просмотр сети осуществляется самим Nautilus'ом без сторонних утилит.
В какой-то момент мне показалось, что обновление на домашней системе не дало результата, т.к. получал ту же ошибку. Но все оказалось проще. У меня 2 компа сидят через маршрутизатор. Так вот на том, с которого сижу, samba не настроена и, соответственно, шары нет. а другой в это время был выключен. Я включил его, и после этого nautilus показал сеть с рабочей группой workgroup.

Arch на работе

На днях получил новый комп (CPU Intel Core2 Q6600 2.4 GHz, RAM 4 GB) и поставил на нем также Arch, хотя больше тяготел к Debian.Теперь буду возиться с Arch'ем не только дома, но и на работе. :)

Awesome 3.3 в community!

Теперь в community не устаревшая, а актуальная версия от 21 апреля. Даже в AUR старее, от 20 апреля :) Возможно, теперь можно будет забить на девелоперскую ветку, и нормально пользоваться. Понадеявшись на то, что старый конфиг будет переименован в .pacsave, обновил версию из git до текущей. Возможно, при удалении конфликтующего awesome-git был удален также мой конфиг, который я с таким трудом настроил (особенно в плане создания пунктов меню). Теперь все придется настраивать заново. Хорошо, хоть носил промежуточный конфиг на работу, и не придется восстанавливать все с чистого листа. Нет, надо все же настроить резервное копирование конфигов...

radeonhd forever!

Похоже, решение сменить драйвер видео было очень кстати, т.к. вчера прошла новость, что новый проприетарный драйвер Catalyst 9.4 уже не поддерживает мое встроенное видео Radeon x1270, в связи с чем AMD предлагает перейти (читай: принудительно пересаживает) на тот же radeonhd :)) Мда, веселенькие новости...
Не сказать, что я сильно огорчен, но недовольных много. Вроде чипсет RS690 не такой уж и старый, и непонятно, зачем бросать пользователей на произвол судьбы? Как бы то ни было, я в любом случае не собирался ставить после опробования свободного драйвера проприетарный. За разработкой свободных драйверов можно следить тут.