Разобрался с hook-ами в сабже… Написал хук, который перед коммитом смотрит на измененные файлы, запускает для них astyle (по сути можно подсунуть другой форматировщик кода, но я более вменяемого с CLI не нашел). Если есть недоформатированные файлы, то коммит отклоняется.
Поставил себе этот релиз… Сделал все, что написано в треде If you have a performance problem, PLEASE read this first.
Какого-либо заметного ускорения KDE4 на своем GeForce Go 7400 я не заметил.. Konsole как тормозил так и тормозит. В mutt/vim как было ощущение работы по SSH так и осталось… Надо сказать, что тот же nv работает заметно шустрее.
Не, одно отличие таки есть… Сломали hibernate. Им это удалось. :) Оно работало фиг знает сколько релизов, включая последний 176.14.xx… Работает даже с nv. А тут после просыпания тупо виснут иксы… После нажатия SysRq+K, через примерно полторы минуты получаю:
[ 462.785401] INFO: task Xorg:5482 blocked for more than 120 seconds.
[ 462.785467] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 462.785571] Xorg D 00000100 0 5482 5476
[ 462.785685] c2011d00 00003086 f704e000 00000100 f704e000 c04d1080 f706fb70 f706fcc8
[ 462.786000] f9c42de3 f704e01c f5fef800 f9c42de3 f7085900 f706fcc8 f783e060 f783e058
[ 462.786361] c2011d3c 00000001 181e7a22 7fffffff f63b1f64 00000002 f63b1f68 c03931ed
[ 462.786726] Call Trace:
[ 462.786848] [] _nv004501rm+0x19/0x1d [nvidia]
[ 462.787164] [] _nv004501rm+0x19/0x1d [nvidia]
[ 462.787460] [] schedule_timeout+0xbd/0xf0
[ 462.787551] [] enqueue_task_fair+0xa9/0xc0
[ 462.787646] [] check_preempt_wakeup+0xb9/0xe0
[ 462.787746] [] try_to_wake_up+0x6d/0x150
[ 462.787854] [] wait_for_common+0x8c/0x130
[ 462.787956] [] default_wake_function+0x0/0x10
[ 462.788066] [] os_acquire_sema+0x77/0x80 [nvidia]
[ 462.788333] [] _nv004075rm+0x9/0x12 [nvidia]
[ 462.788630] [] _nv004192rm+0x9/0xd [nvidia]
[ 462.788915] [] rm_check_pci_config_space+0x1a8/0x80e [nvidia]
[ 462.789222] [] nv_kern_ioctl+0x96/0x380 [nvidia]
[ 462.789679] [] irq_entries_start+0x60c/0x840
[ 462.789770] [] nv_kern_unlocked_ioctl+0x18/0x20 [nvidia]
[ 462.790034] [] nv_kern_unlocked_ioctl+0x0/0x20 [nvidia]
[ 462.790289] [] vfs_ioctl+0x2b/0x90
[ 462.790391] [] do_vfs_ioctl+0x67/0x200
[ 462.790491] [] sys_ioctl+0x66/0x70
[ 462.790584] [] sysenter_past_esp+0x6a/0x91
[ 462.790671] [] irq_entries_start+0x60c/0x840
[ 462.790788] =======================
Отписался на nvnews.net. Может починят то, что сломали :)
Гладиолус: Pong from Гладиолус after -85601.2 secs.
<message from='***@conference.jabber.ru/Зомби' to='gluxi@inhex.net/GluxiBot-dev' xml:lang='en' type='groupchat'>
<body>Гладиолус: Pong from Гладиолус after -85601.2 secs.</body>
</message>
</pre>
PS. Кроме какого-то переполнения на ум ничего не приходит… С другой стороны, на пинги таймаут стоит, который гарантированно влезит в long…
Поставил себе сабж… (KDE4-версию). Первый раз с подобной игрой я познакомился наверное лет 10 назад :) Еще под DOS. Очень понравилось, что сохранили все оригинальные уровни. Управление мышкой ниасилил.. А вот клавиатурное — вполне себе удобно..
Прошел первых 7 оригинальных уровней. Надо будет еще аналог старого Sokoban-а поставить. По apt-cache search sokoban находится некоторое количество софта.
Мне таки кажется, что на jabber.ru установлен какой-то умный шейпер не только на c2s но и на s2s. Станзы <presence /> и <iq /> доставляются моментально, а <message /> тормозят… Очень похоже, что есть ограничение в количество станз в единицу времени на все конференции.
Судя по тому, что с другими серверами, вроде jabbus.org все нормально, это таки не канал.
Надо будет как-то померять что-то.
Вот уже почти три месяца как в mailing-list-е Mercurial тянется флейм по поводу того, должна ли VCS конвертировать имена файлов в кодировку пользователя и обратно.
Тот же SVN хранит имена файлов в “своей” кодировке (UTF-8?). При чекауте имена всех файлов конвертируются в кодировку системы. При коммите соответственно наоборот. Таким образом можно счекаутить репозиторий на машине с любой локалью, поддерживающей кириллицу, и имена файлов останутся читаемыми.
Mercurial же понимает имена файлов как набор байт (подобно UNIX-овым файловым системам). То есть, репозиторий, созданный в другой локали (или на венде), будет чекаутиться криво. Аргументируется это поведение тем, что “make” сможет собрать такой проект, так как имена файлов будут в той же кодировке, что и Makefile.
Мне вот поведение SVN-а нравится больше… Исходники мало кто обзывает нелатинскими буквами. А вот хранить файлы, имена которые будут читаться только пользователем (например документы OpenOffice) вполне себе удобно.
Надо будет посмотреть, как ведут себя другие VCS (как минимум — git, darcs).
UPD: В Mailing list-е кинули ссылку на git-версию треда :)
Я тут подумал, чем лучше всего архивировать файлы для бэкапов.. Труъ UNIX way в виде tar.(gz|bz2) мне не очень нравится, потому что, в случае повреждения архива, вытянуть что-то за местом повреждения практически нереально. Архиватор должен обязательно уметь сохранять UNIX права доступа, поддерживать симлинки.
continue reading
Похоже, что новые версии OpenID плагина (>2.1.9) сломали… Они просто не авторизирует. Вот
тут похожая проблема… Копаться в php-коде мне лень… Просто пока не буду его обновлять.
aufs — «наследник» unionfs. Позволяет на лету обьединять несколько файловых систем в одну. Я уже достаточно давно подумываю применить это к созданию инкрементальных бэкапов.
Идея заключается в том, что можно создать первый (полный) бэкап всего раздела. Затем можно тем же LVM-ом заблокировать раздел от дальнейших изменений. Дальше монтируется aufs с двумя бранчами:
- read-only — содержит уже забэкапленные данные;
- read-write — сюда будут сохраняться новые данные
Таким образом для создания первого инкрементального бэкапа достаточно забэкапить «read-write» бранч. Дальше нужно как-то обьеденить эти два бранча.. Все изменения нужно как-то перенести в «read-only» бранч, чтобы не бэкапить их еще раз. Вот как это сделать простым методом я пока что не совсем себе представляю..
Для созданных/измененных файлов достаточно просто передвинуть эти файлы с заменой. А вот удаленные файлы нужно обрабатывать как-то сложней. В read-write бранче уделение файла «somefile.txt» сохраняется в виде создания файла «.wh.somefile.txt». По идее можно поискать все файлы, которые начинаются с префикса «.wh.» и удалить соответствующие им файлы в read-only бранче… Но не хотелось бы пользоваться такими вот грязными хаками. Плюс не факт, что такой способ хранения останется в следующих версиях aufs.
Спросил в рассылке aufs-users@. Может что посоветуют.
Сам aufs должен быть достаточно ровным. Куча всяких LiveCD его используют. Я попробовал положить в read-only бранч исходник linux-2.6.26 и собрать его на read-write бранче. Ядр собралось (make -j 4) и даже загружается…
Сегодня исполняется ровно две недели с момента, как я поставил себе KDE4.1. В принципе можно сказать, что оно уже рабочее. Сносить его я в ближайшее время не буду.. Жаль только, KDE4 в debian так опакетили, что оно конфликтует с KDE3. В частности, чтобы сменить тему оформления в KDE3-софте, нужно либо ставить kcontrol из KDE3 (что автоматом снесет KDE4), либо делать это на другом тазике (например виртуалке) и переносить конфиги.
Когда NVIDIA поправит свой драйвер (если вообще поправит), то будет совсем хорошо…
Посмотрел на сабж… Завелось сразу. Умеет в workspace отмечать значками измененные файлы. Плюс достаточно удобно выглядит annotate (aka blame).
Добавлять/удалять файлы все равно удобней руками с помощью команды hg addremove, которая с ключем -s умеет угадывать перемещения файлов.
Открыл для себя эту ленту. Туда добавили мой блог по тегу “jabber”.
http://planet.jrudevels.org/
Разгреб накопившуюся стогиговую файлопомойку. Удалил кучу лишнего мусора. Засунул часть конфигов из $HOME в Mercurial репозиторий. Туда же положил часть самописных скриптов из $HOME/bin. Нарисовал скрипт, которые раскидывает симлинки куда надо с клона этого репозитория.
Уменьшил размер /home, вынес /usr и /var на отдельные разделы, потом урезал корень. LVM рулит. Reiserfs не менее рулит за возможность нормального и безглючного resize. В сторону увеличения — в онлайне без отмонтирования. В сторону уменьшения — к сожалению с предварительным отмонтированием раздела.
Заменил sysvinit на upstart. Увеличения скорости загрузки не заметил. А вот выключаться система начала заметно быстрей.
Поставил /bin/dash в качестве /bin/sh. Вроде работает.
PS. Подумываю, где секюрно хранить GPG/SSH ключи и другую подобную информацию.
Хочется иметь нормальный способ создания бэкапов. В частности под нормальным способом я понимаю:
- Создание полных бэкапов и инкрементальных;
- CD/DVD в качестве носителей;
- Как можно проще. Клиент-серверное не нужно. Command-line или в крайнем случае ncurses. Запустил скрипт (руками или из крона), в определенный каталог положился файл (файлы). На почту прислалось уведомледние, что нужно записать файлы на носители;
- Возможность посмотреть, что будет забэкаплено в инкрементальном бэкапе и влиять на это, например сказать, а вот этот файл засовывать в инкрементальный бэкап не нужно, потому что он весит 10 гиг и потерять в принципе не жалко;
- Сохранять информацию про удаление файлов. То есть, например, если на в полном бэкапе файл был, а к следующему инкрементальному бэкапу этот файл удалили, то распаковывание полного бэкапа и накатывание поверх него инкрементального, файл должен удалиться;
- Стандартный формат файлов бэкапа, например tar.gz/tar.bz2. И, как минимум, в случае потери одного из инкрементальных бэкапов (например не читается болванка), нужно иметь возможность востанавливать данные из последующих;
- Желательно уметь делать xdelta для некоторых достаточно больших файлов (например образы HDD VirtualBox-а);
- Желательно иметь возможность обьяснить, что определенные файлы нужно бэкапить не так часто, как остальные.
Сейчас я периодически руками запускаю tar с ключем —after-date, но это не совсем удобно. По apt-cache search incremental backup ничего подходящего не вижу.
Пока я себе тут создаю amd64 чрут, загрузился с x86_64 ядром, используя при этом свой i386 корень. Проприетарный дравйвер nvidia естественно отказался работать. Чтобы таки запустить иксы, я заюзал nv.
Теперь konsole стала тормозить заметно меньше… Можно даже сказать, что оно почти не уступает kde3-версии. Глюки плазмы при запущенном eclipse исчезли…
/me терзают смутные сомнения (c)
Открыл для себя сабж. Умеет для любого блочного девайса, содержащего таблицу разделов (например образ винта qemu), создавать девайсы вида /dev/loop0pX. То есть можно нормально монтировать разделы на таких вот образах. К KDE отношения не имеет ;)
Откопал свой старый патч (еще со времен Psi 0.9-0.10), спортировал его на Psi из SVN-а.
Теперь по клику на фотке в VCard она отображается в масштабе 1:1.
Нарисовалась сегодня непонятно кто… Позвонила, говорит, что мой телефон в интернете нашла.. Прогуглил тему, вроде не засвечен нигде…
Они таки асилили это….
http://developer.motorola.com/docstools/motodevstudio/linux/downloads/
Правда только для MOTOMAGX, то есть “старые” мобилки идут лесом. Плюс непонятно, зачем ему жаба и VMWare player… Надо будет скачать, посмотреть.
Интересно, как они с Trolltech-ом урегулировали на счет лицензий на Qt/Embedded.
Вот интересно, есть куча всяких плееров, которые умеют создавать коллекции музыки и потом из этих коллекция создавать плейлисты. Те, что я использую — amarok и mpd.
Достаточно реальная ситуация: альбом записан несколькими исполнителями вместе. Как его правильно добавить в коллекцию, чтобы он был доступен при поиске как по «Artist1», так и по «Artist2».
Можно в тег «Artist» вписать нечто типа «Artist1 && Artist2». Но это создаст новую сущность, а не добавит альбом к двум уже имеющимся.
В случае файловой системы можно допустим создать каталог «Artist1 && Artist2», положить туда альбом и сделать симлинки в каталоги «Artist1» и «Artist2». Это частично решает проблему. Альбом будет виден у обоих исполнителей. Но, тем не менее, плеером это будет трактоваться как два _разных_ альбома (а то и все три). И это не есть удобно. Например, при просмотре альбомов «Aritst1» не будет видно, что этот альбом исполняется совместно с «Artist2».
Нормального решения я пока что не вижу, но хотелось бы…
Меня таки начал напрягать ярко белый фон в окнах чата Psi. Изменить его средствами qtconfig-qt4 у меня так и не вышло. Сегодня я решил пойти другим путем. Заменил в исходнике Psi создание QApplication на KApplication. Ну и слинковал её с libkdeui. Теперь все окна чатов (class QTextBrowser) отрисовываются с правильным фоном.
Патч: http://inhex.net/dion/psi/08_kde_integration.diff
Таскбар иногда очень странно глючит при наведении мыши. При чем это воспроизводится только при запуске некоторого софта. Из замеченного — OpenOffice и Eclipse. С GIMP и Netbeans все работает.

Запускаю qtconfig-qt4. Нажимаю кнопку «Tune palette». Для «Base» выбираю не белый цвет, а чуть темней (не хочу слишком ярких цветов). Нажимаю сохранить. В этом qtconfig изменения моментально применились. Также изменения применились в рядом запущенном Psi. Перезапускаю Psi, цвет опять стал ярко белым… Открываю qtconfig снова, там изменений тоже нет…
Без KDE4 точно работало… Связи не вижу…
Сегодня узнал про две интересные иксовые утилитки: xsel и xdotool.
xsel позволяет управлять иксовыми буфферами обмена (как для копирования/вставки средней кнопкой мыши, так и для обычного буффера обмена, доступного по Ctrl+C, Ctrl+V).
xdotool умеет эмулировать нажатия/отпускания клавиш на клавиатуре, управлять мышью, производить некоторые операции с окнами и виртуальными десктопами.
Используя эти две утилиты я сделал хоткей для вставки названия играющего трека в плеере. Вообще должно было хватить xdotool:
xdotool type `get_now_playing`
Но у меня такой вариант не заработал для композиций с юникодными символами. Пришлось сначала копировать текст в буффер обмена, потом нажимать Shift+Insert:
#!/bin/sh
NP=`mpc | head -n 1`
echo -n "$NP" | xsel -b -i
xdotool key "Shift+Insert"