Ars Longa, Vita Brevis » Linux

Исправление проблемы обхода хранителя экрана в X11

Vladimir — Thu, 19 Jan 2012 12:18:51 +0000

Программистов всё больше, а профессионалов всё меньше

В X.Org Server 1.11 обнаружена уязвимость, позволяющая через манипуляции с клавиатурой обойти режим блокировки экрана и получить доступ к заблокированному рабочему окружению пользователя.

Подробности либо по ссылке выше, либо на OpenNet.

Исправление: в файле /usr/share/X11/xkb/compat/xfree86 закомментировать следующие строки:

interpret XF86_Ungrab {
action = Private(type=0x86, data="Ungrab");
};
interpret XF86_ClearGrab {
action = Private(type=0x86, data="ClsGrb");
};

После чего перезапустить X Server.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Linux, консоль и деванагари

Vladimir — Mon, 05 Sep 2011 15:51:08 +0000

В то время, когда наши корабли бороздят просторы Вселенной…

Недавно отлаживал небольшой скрипт, транслитерирующий текст, записанный в системе IAST или ITRANS, на деванагари. Так как на домашней машине стоит Linux, то логично, что скрипт отлаживался в Linux — в терминале.

И тут меня ожидал огромный сюрприз…

В качестве теста брался отрывок из Брихадараньяка-упанишады, выглядящий следующим образом (в IAST):

pūrṇamadaḥ pūrṇamidam pūrṇāt pūrṇamudacyate
pūrṇasya pūrṇamādāya pūrṇamevāvaśiṣyate

По-русски это примерно так:

То — бесконечность, и это — бесконечность. Бесконечность исходит из бесконечности,
Обретая бесконечность бесконечного, она остается лишь бесконечностью.

На деванагари результат должен выглядеть так:

पूर्णमदः पूर्णमिदम् पूर्णात् पूर्णमुदच्यते
पूर्णस्य पूर्णमादाय पूर्णमेवावशिष्यते

Как оказалось, если взять результат, сохранить в файл, а потом вывести на экран (например, командой cat), то получится полный бред:

परणमदः परणमिदम परणात परणमदचयत
परणसय परणमादाय परणमवावशिषयत

В IAST это будет

paraṇamadaḥ paraṇamidama paraṇāta paraṇamadacayata
paraṇasaya paraṇamādāya paraṇamavāvaśiṣayata

Что в корне отличается от того, что было в оригинале.

Тут нужно сделать парочку лирических отступлений:

В деванагари есть такая особенность, что символы согласных звуков «по умолчанию» содержат гласный a. То есть क — это ka, а не k. Отсутствие этого a обозначается специальным подстрочным символом (символ вирама или халант). Например, комбинация, соответствующая звуку k будет записываться как क्.
Вторая особенность — гласные звуки имеют два варианта написания: гласный после гласной (или сам по себе) и после согласной записываются по-разному (во втором случае обычно используются диакритические знаки). Например, u — ku: उ — कु.

Возвращаясь к примеру: если сравнить первое слово того, что должно быть и того, что получилось:

पूर्णमदः — पू र् ण म दः — pū r ṇa ma daḥ
परणमदः — प र ण म दः — pa ra ṇa ma daḥ

Можно заметить одну особенность: терминал «обрезает» надстрочные и подстрочные символы (причём обрезает наглухо — при копировании копируется не исходный вариант, а обрезанный). Например, в पू подстрочный символ обозначает гласный ū (лирическое отступление №2), если подстрочный символ «обрезать», то останется просто प, который в соответствии с лирическим отступлением №1 будет pa.

क	ka	=>	क	ka
का	kā	=>	का	kā
कि	ki	=>	कि	ki
की	kī	=>	की	kī
कु	ku	=>	क	ka
कू	kū	=>	क	ka
कृ	kṛ	=>	क	ka
कॄ	kṝ	=>	क	ka
कॢ	kḷ	=>	क	ka
कॣ	kḹ	=>	क	ka
के	ke	=>	क	ka
कै	kai	=>	क	ka
को	ko	=>	को	ko
कौ	kau	=>	कौ	kau
कँ	kam̐	=>	क	ka
कं	kaṁ	=>	क	ka
कः	kaḥ	=>	कः	kaḥ
क्	k	=>	क	ka

Видим, что в терминале очень не везёт гласным u, ū, ṛ, ṝ, ḷ, ḹ, e и дифтонгу ai — они тихо превращаются в a. Вирама также погибает смертью храбрых, в результате чего к согласным добавляется звук a. Анусвара (ṃ) и чандрабинду (m̐) обрезаются.

Какой можно сделать вывод? Индийские тексты в терминале нечитаемы. Вообще. И это в век повсеместного Unicode и UTF-8! Честно говоря, в Linux достаточно проблем с Unicode: apport не воспринимает русские символы, command-not-found вылетает с ошибкой на не английских символах, Inkscape некорректно отображает деванагари, те же проблемы в LibreOffice… Грустно…

Установка Skype на Ubuntu Oneiric Ocelot AMD64

Vladimir — Fri, 26 Aug 2011 01:48:21 +0000

И так идут за годом год…

Прошло два года… Единственное изменение — в текущей бете Oneiric Ocelot в репозитории partner Skype нет. Вообще.

Skype из Natty Narwhal не прижился: проблема с зависимостями: ia32-libs зависит от lib32v4l-0, который зависит от libv4l-0 версии 0.8.3-2, при том, что в репозитории есть только 0.8.5-3ubuntu1. Понятно, что проблему с зависимостями в конце концов исправят, но без Skype плохо.

Решение пока такое:

Если поддержка multiarch не включена, включить:

echo foreign-architecture i386 > /etc/dpkg/dpkg.cfg.d/multiarch
apt-get update
Установить статическую сборку Skype (отсюда) — .deb-пакет всё равно не установится из-за проблем с зависимостями.
Доставить недостающие 32-битные пакеты:

apt-get install libxv1:i386 libxss1:i386
Возможно потребуются дополнительные пакеты. Узнать просто: нужно запустить Skype из консоли. Если чего-то не хватает, система пожалуется:
skype: error while loading shared libraries: libXv.so.1: cannot open shared object file: No such file or directory

Нужно найти, какому пакету принадлежит библиотека:

$ dpkg -S libXv.so
libxv1: /usr/lib/x86_64-linux-gnu/libXv.so.1.0.0

И устаносить 32-битную версию этого пакета:

apt-get install libxv1:i386

После этого Skype должен заработать.

UPDATE 2011-12-20: рекомендованный ныне способ:

echo foreign-architecture i386 > /etc/dpkg/dpkg.cfg.d/multiarch
aptitude update
aptitude install skype:i386 --without-recommends

nspluginwrapper: no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so

Vladimir — Mon, 22 Aug 2011 23:34:06 +0000

Исправление ошибки установки Flash Player в Ubuntu 11.10/AMD64

При обновлении Ubuntu Natty Narwhal до текущей альфы Oneiric Ocelot на архитектуре AMD64 возникает неприятная ошибка при обновлении пакета flashplugin-installer (Flash Player):

package flashplugin-installer 10.3.183.4ubuntu3 failed to install/upgrade:
nspluginwrapper: no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so

Лечение довольно простое:

Необходимо включить поддержку multiarch, если она еще не включена:

echo foreign-architecture i386 > /etc/dpkg/dpkg.cfg.d/multiarch
apt-get update

Это позволит устанавливать пакеты для архитектуры i386 на AMD64.
Затем нужно установить пакеты libnss3:i386 и libcurl3:i386:

aptitude install libnss3:i386 libcurl3:i386

В зависимостях подтянутся пакеты libnspr4:i386 и libsqlite3-0:i386.

После этого можно спокойно (пере)установить пакет flashplugin-installer — всё будет работать.

С отчётом об ошибке и комментариями пользователей можно ознакомиться здесь.

php: symbol zlibVersion, version libmysqlclient_16 not defined in in file libmysqlclient.so.16 with link time reference

Vladimir — Mon, 30 May 2011 16:13:54 +0000

Быстрое исправление 'relocation error'

Не везёт мне с PHP на CentOS…

Ситуация: имеется сервер на CentOS с установленной CPanel. PHP в случайные моменты времени завершается с ошибкой вида

php: relocation error: php: symbol zlibVersion, version libmysqlclient_16 not defined in in file libmysqlclient.so.16 with link time reference

Вместо zlibVersion может быть другое имя, например crc32.

Из-за CPanel/WHM возможности ограничены опциями, предоставляемыми EasyApache — обновить MySQL/PHP штатными средствами (например, через yum) не представляется возможным из-за риска сломать CPanel.

Текст ошибки явно указывает на проблему с версией библиотеки, поэтому в первую очередь нужно выянить, где на сервере находится libmysqlclient. В моём случае это /usr/lib64 и /usr/lib64/mysql.

Затем смотрим, какую из библиотек использует php:

$ ldd `which php` | grep libmysqlclient
libmysqlclient.so.16 => /usr/lib64/mysql/libmysqlclient.so.16 (0x00000034c6000000)
$ ls -la `/usr/lib64/mysql/libmysqlclient.so.16`
lrwxrwxrwx 1 root root 27 May 29 00:08 /usr/lib64/mysql/libmysqlclient.so.16 -> libmysqlclient.so.16.0.0*

Но libmysqlclient.so.16.0.0 существует и в /usr/lib64, и в /usr/lib64/mysql, поэтому посмотрим, где нужный символ есть:

$ nm /usr/lib64/mysql/mysql/libmysqlclient.so.16.0.0 | grep zlibVersion
nm: libmysqlclient.so.16.0.0: no symbols
$ nm /usr/lib64/mysql/libmysqlclient.so.16.0.0 | grep zlibVersion
00000034c60d64b0 T zlibVersion

Меняем символьную ссылку на нужный файл:

rm -f /usr/lib64/mysql/libmysqlclient.so.16
cd /usr/lib64/mysql
ln -s ../libmysqlclient.so.16.0.0 libmysqlclient.so.16

После чего ошибка исчезает.

ACSII-сортировка при помощи sort в Linux

Wandering Soul — Mon, 16 May 2011 22:49:04 +0000

О пользе RTFM

Всё не так очевидно, как кажется на первый взгляд.

Допустим, что имеется файл с таким текстом:

~a
~z
c
f
x
a
b

Так как ASCII-код тильды больше, чем у любой латинской буквы, то ожидаемый результат сортировки будет таким:

a
b
c
f
x
~a
~z

Тем не менее, если натравить команду sort на исходный набор данных, получим такой результат:

a
~a
b
c
f
x
~z

Для того, чтобы получить ожидаемый результат нужно внимательно прочитать подсказку программы:

*** WARNING ***
The locale specified by the environment affects sort order.
Set LC_ALL=C to get the traditional sort order that uses
native byte values.

Таким образом, для получения ожидаемого результата sort нужно запускать так:

LC_ALL=C sort file.txt

OpenMP, параллельный режим и утечки памяти в GNU Standard C++ Library

Vladimir — Sat, 14 May 2011 04:23:09 +0000

Скрестив ужа и ежа, Мичурин получил колючую проволоку

Стандартнуя библиотека GNU языка C++ поддерживает так называемый параллельный режим, который предоставляет экспериментальную поддержку параллельных алгоритмов из и . Для включения данного режима исходный код нужно компилировать с опеределённым макросом _GLIBCXX_PARALLEL, либо явно подключать заголовочные файлы из и использовать пространство имён __gnu_parallel.

В параллельном режиме для реализации параллелизма используется OpenMP.

Как оказалось, при использовании в своей программе OpenMP и параллельного режима libstdc++ можно столкнуться с очень неприятными и недокументированными особенностями реализации и получить незабываемое «удовольствие» при отладке.

Есть очень простая тестовая программа, использующая OpenMP:

#include
#include
#include
#include
#include

typedef std::vector<std::string> vector_t;

template<typename T>
std::string toString(const T& x)
{
std::stringstream converter;
converter << x;
return converter.str();
}

template<typename T>
T gen(void)
{
return std::rand();
}

template<>
std::string gen(void)
{
return toString(std::rand());
}

int main(int argc, char** argv)
{
vector_t v1(65536);
vector_t v2(65536);

#pragma omp parallel shared(v1, v2)
{
#pragma omp single nowait
{
#pragma omp task shared(v1)
std::generate(v1.begin(), v1.end(), gen<vector_t::value_type>);

std::generate(v2.begin(), v2.end(), gen<vector_t::value_type>);
}
}

return 0;
}

Программа использует два потока для заполнения двух векторов случайными строками. При использовании параллельного режима теоретически может использоваться более двух потоков — libstdc++ имеет параллельную версию алгоритма std::generate.

Сборка программы выполняется так:

g++ -fopenmp -O1 -g3 test.cpp -o test1
g++ -fopenmp -O1 -g3 -D_GLIBCXX_PARALLEL test.cpp -o test2

test1 не использует параллельный режим, test2 использует.

Самое интересное начинается при запуске обеих программ под Valgrind — с целью нахождения утечек памяти.
Запуск осуществляется так:

valgrind --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes ./test1
valgrind --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes ./test2

Получились такие результаты:

Без использования параллельного режима:

==10569== HEAP SUMMARY:
==10569== in use at exit: 2,936 bytes in 6 blocks
==10569== total heap usage: 262,152 allocs, 262,146 frees, 75,956,839 bytes allocated
…
==10569== LEAK SUMMARY:
==10569== definitely lost: 0 bytes in 0 blocks
==10569== indirectly lost: 0 bytes in 0 blocks
==10569== possibly lost: 912 bytes in 3 blocks
==10569== still reachable: 2,024 bytes in 3 blocks
==10569== suppressed: 0 bytes in 0 blocks

Явных утечек памяти нет; по поводу still reachable разработчики говорят, что это не ошибка (я с ними согласен).

Таким образом, при использовании OpenMP и стандартного режима libstdc++ всё выглядит довольно-таки хорошо.

С использованием параллельного режима:

==10628== HEAP SUMMARY:
==10628== in use at exit: 4,522,599 bytes in 131,078 blocks
==10628== total heap usage: 262,402 allocs, 131,324 frees, 77,022,766 bytes allocated
…
==10628== LEAK SUMMARY:
==10628== definitely lost: 4,519,595 bytes in 131,070 blocks
==10628== indirectly lost: 0 bytes in 0 blocks
==10628== possibly lost: 980 bytes in 5 blocks
==10628== still reachable: 2,024 bytes in 3 blocks
==10628== suppressed: 0 bytes in 0 blocks

Сразу бросается в глаза: definitely lost: 4,519,595 bytes in 131,070 blocks — это те самые два вектора (2×65536) плюс еще чуть-чуть.

Трасса вызовов выглядит так:

==10628== 34 bytes in 1 blocks are possibly lost in loss record 2 of 10
==10628== at 0x4C28B42: operator new(unsigned long) (vg_replace_malloc.c:261)
==10628== by 0x4ECBE6C: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.14)
==10628== by 0x402FBB: char* std::string::_S_construct(char*, char*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:138)
==10628== by 0x403002: std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) (basic_string.h:1649)
==10628== by 0x403234: std::string toString(int const&) (sstream:127)
==10628== by 0x401CBD: std::string gen() (test.cpp:27)
==10628== by 0x402373: _ZN14__gnu_parallel46__for_each_template_random_access_workstealingIN9__gnu_cxx17__normal_iteratorIPSsNSt9__cxx19986vectorISsSaISsEEEEEPFSsvENS_19__generate_selectorIS8_EENS_12_DummyReductEbEET0_T_SF_SE_RT1_T2_T3_RSJ_NSt15iterator_traitsISF_E15difference_typeE.omp_fn.4 (for_each_selectors.h:77)
==10628== by 0x40D68B: std::string (*__gnu_parallel::__for_each_template_random_access_workstealing<__gnu_cxx::__normal_iterator > >, std::string (*)(), __gnu_parallel::__generate_selector<__gnu_cxx::__normal_iterator > > >, __gnu_parallel::_DummyReduct, bool>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, std::string (*)(), __gnu_parallel::__generate_selector<__gnu_cxx::__normal_iterator > > >&, __gnu_parallel::_DummyReduct, bool, bool&, std::iterator_traits<__gnu_cxx::__normal_iterator > > >::difference_type))() (workstealing.h:297)
==10628== by 0x40D77C: std::string (*__gnu_parallel::__for_each_template_random_access<__gnu_cxx::__normal_iterator > >, std::string (*)(), __gnu_parallel::__generate_selector<__gnu_cxx::__normal_iterator > > >, __gnu_parallel::_DummyReduct, bool>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, std::string (*)(), __gnu_parallel::__generate_selector<__gnu_cxx::__normal_iterator > > >&, __gnu_parallel::_DummyReduct, bool, bool&, std::iterator_traits<__gnu_cxx::__normal_iterator > > >::difference_type, __gnu_parallel::_Parallelism))() (for_each.h:86)
==10628== by 0x40D814: void std::__parallel::__generate_switch<__gnu_cxx::__normal_iterator > >, std::string (*)()>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, std::string (*)(), std::random_access_iterator_tag, __gnu_parallel::_Parallelism) (algo.h:1556)
==10628== by 0x40258C: main.omp_fn.1 (algo.h:1584)
==10628== by 0x53C1A12: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10628== by 0x53C3748: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10628== by 0x53C1FBD: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==10628== by 0x57E4D8B: start_thread (pthread_create.c:304)
==10628== by 0x5AE204C: clone (clone.S:112)

==10628== 2,259,752 bytes in 65,534 blocks are definitely lost in loss record 9 of 10
==10628== at 0x4C28B42: operator new(unsigned long) (vg_replace_malloc.c:261)
==10628== by 0x4ECBE6C: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.14)
==10628== by 0x402FBB: char* std::string::_S_construct(char*, char*, std::allocator const&, std::forward_iterator_tag) (basic_string.tcc:138)
==10628== by 0x403002: std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) (basic_string.h:1649)
==10628== by 0x403234: std::string toString(int const&) (sstream:127)
==10628== by 0x401CBD: std::string gen() (test.cpp:27)
==10628== by 0x402373: _ZN14__gnu_parallel46__for_each_template_random_access_workstealingIN9__gnu_cxx17__normal_iteratorIPSsNSt9__cxx19986vectorISsSaISsEEEEEPFSsvENS_19__generate_selectorIS8_EENS_12_DummyReductEbEET0_T_SF_SE_RT1_T2_T3_RSJ_NSt15iterator_traitsISF_E15difference_typeE.omp_fn.4 (for_each_selectors.h:77)
==10628== by 0x40D68B: std::string (*__gnu_parallel::__for_each_template_random_access_workstealing<__gnu_cxx::__normal_iterator > >, std::string (*)(), __gnu_parallel::__generate_selector<__gnu_cxx::__normal_iterator > > >, __gnu_parallel::_DummyReduct, bool>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, std::string (*)(), __gnu_parallel::__generate_selector<__gnu_cxx::__normal_iterator > > >&, __gnu_parallel::_DummyReduct, bool, bool&, std::iterator_traits<__gnu_cxx::__normal_iterator > > >::difference_type))() (workstealing.h:297)
==10628== by 0x40D77C: std::string (*__gnu_parallel::__for_each_template_random_access<__gnu_cxx::__normal_iterator > >, std::string (*)(), __gnu_parallel::__generate_selector<__gnu_cxx::__normal_iterator > > >, __gnu_parallel::_DummyReduct, bool>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, std::string (*)(), __gnu_parallel::__generate_selector<__gnu_cxx::__normal_iterator > > >&, __gnu_parallel::_DummyReduct, bool, bool&, std::iterator_traits<__gnu_cxx::__normal_iterator > > >::difference_type, __gnu_parallel::_Parallelism))() (for_each.h:86)
==10628== by 0x40D814: void std::__parallel::__generate_switch<__gnu_cxx::__normal_iterator > >, std::string (*)()>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, std::string (*)(), std::random_access_iterator_tag, __gnu_parallel::_Parallelism) (algo.h:1556)
==10628== by 0x402566: main.omp_fn.0 (algo.h:1584)
==10628== by 0x40297B: main (test.cpp:35)

Ключ к пониманию даёт workstealing.h (адрес 0x40D68B в трассе). В коде есть такая строка:

# pragma omp parallel shared(__busy) num_threads(__num_threads)

Что получается: грубо говоря, следующее:

#pragma omp parallel
{
#pragma omp single nowait
{
#pragma omp task
{
// …
#pragma omp parallel num_threads(__num_threads)
// …
}
}
}

Есть предположение, что виноват num_threads во вложенном omp parallel (по крайней мере, если убрать num_threads, то утечки исчезают — но последствия изменений я не проверял).

Вроде бы в num_threads криминала нет — вложенный блок omp parallel создаёт новую группу потоков (при условии, что вложенность разрешена — либо через OMP_NESTED=TRUE, либо через вызов omp_set_nested(true)), а не изменяет количество потоков в существующей группе, но где-то что-то не до конца продумано.

Мораль на сегодняшний день такова: при использовании OpenMP параллельный режим глобально лучше не включать; при необходимости использования параллельных алгоритмов использовать алгоритм из пространства имён __gnu_parallel (и ни в коем случае не делать этого внутри блоков OpenMP).

Как правильно избавляться от fglrx

Vladimir — Wed, 13 Apr 2011 14:06:53 +0000

В действительности всё не так, как на самом деле

У драйвера fglrx есть одна неприятная особенность: его не так-то просто удалить. И дело даже не в том, что после удаления fglrx остаются лишние файлы — всё намного хуже: с не полностью удалённым fglrx проявляются неожиданные ошибки в открытых драйверах ati/radeon.

Симптомы не полностью удалённого fglrx включают:

система не загружается, в логах могут содержаться ошибки, упоминающие MTRR;
проблемы с производительностью, glxgears/glxinfo могут перестать работать;
неожиданные зависания, сбои, проблемы с отрисовкой изображений.

В частности, трассировка (backtrace), получаемая при сбое приложения, может содержать «отсылки» к fglrx, например:

Error: vlc crashed with SIGSEGV in XF86DRIQueryVersion()
Stacktrace:
XF86DRIQueryVersion () from /usr/lib/fglrx/libGL.so.1
XF86DRIQueryExtension () from /usr/lib/fglrx/libGL.so.1
?? () from /usr/lib/fglrx/libGL.so.1
?? () from /usr/lib/fglrx/libGL.so.1
glXQueryVersion () from /usr/lib/fglrx/libGL.so.1

Или

[ 57324.822] 0: /usr/bin/X (xorg_backtrace+0x26) [0x4a24d6]
[ 57324.822] 1: /usr/bin/X (0x400000+0x6219a) [0x46219a]
[ 57324.822] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fb5852f6000+0xfc60) [0x7fb585305c60]
[ 57324.822] 3: /usr/lib/xorg/extra-modules/modules/glesx.so (0x7fb57e5d2000+0x613a2) [0x7fb57e6333a2]
[ 57324.822] 4: /usr/lib/xorg/extra-modules/modules/glesx.so (0x7fb57e5d2000+0x5f633) [0x7fb57e631633]
[ 57324.822] 5: /usr/lib/xorg/extra-modules/modules/glesx.so (esutAddSrcSurf+0x1a) [0x7fb57e63074a]
[ 57324.822] 6: /usr/lib/xorg/extra-modules/modules/glesx.so (0x7fb57e5d2000+0x56fa0) [0x7fb57e628fa0]
[ 57324.822] 7: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0x7fb58183e000+0x4579b4) [0x7fb581c959b4]
[ 57324.823] 8: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0x7fb58183e000+0x45739a) [0x7fb581c9539a]
[ 57324.823] 9: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (xdl_xs110_swlDriBlockHandler+0x74) [0x7fb581cabeb4]
[ 57324.823] 10: /usr/bin/X (BlockHandler+0x8d) [0x43217d]
[ 57324.823] 11: /usr/bin/X (WaitForSomething+0x11d) [0x45c6ed]
[ 57324.824] 12: /usr/bin/X (0x400000+0x2dff2) [0x42dff2]
[ 57324.824] 13: /usr/bin/X (0x400000+0x21a4e) [0x421a4e]
[ 57324.824] 14: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xff) [0x7fb58422eeff]
[ 57324.824] 15: /usr/bin/X (0x400000+0x215f9) [0x4215f9]
[ 57324.824] Segmentation fault at address 0x10
[ 57324.824]
Caught signal 11 (Segmentation fault). Server aborting

Полное удаление fglrx (все действия должны выполняться от имени пользователя root):

apt-get remove --purge xorg-driver-fglrx fglrx\*
apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri fglrx-modaliases
dpkg-reconfigure xserver-xorg
apt-get install --reinstall xserver-xorg-core

Последняя команда нужна, если требуется поддержка эффектов рабочего стола (KDE, Compiz). Дело в том, что даже после полного удаления(!) fglrx от него остаётся файл libglx.so (он предоставляется пакетами fglrx и xserver-xorg-core); для нормальной работы в системе должна быть установлена правильная версия libglx.so.

Полное удаления fglrx и переустановка ati (все действия должны выполняться от имени пользователя root):

[ -x /usr/share/ati/fglrx-uninstall.sh ] && /usr/share/ati/fglrx-uninstall.sh
apt-get remove --purge fglrx\* xserver-xorg-video-ati xserver-xorg-video-radeon
apt-get install xserver-xorg-video-ati
apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-core
dpkg-reconfigure xserver-xorg
apt-get install fglrx-modaliases

Рекомендуется к прочтению: Troubleshooting when -fglrx Interferes with -radeon Driver

Кто там что говорил про дружественность Linux на десктопах?

Kopete и проблемы с ICQ

Wandering Soul — Fri, 19 Nov 2010 09:15:42 +0000

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

Недавно у Kopete начались проблемы с подключением к ICQ: Kopete жаловался на неверный пароль. При этом другие клиенты (старый добрый Jimm) успешно работали.

Проблема оказалась очень простой: сменился логин-сервер: если раньше по умолчанию использовался login.oscar.aol.com, то теперь он не работает для ICQ. Решение простое: нужно заменить стандартную информацию о сервере на login.icq.com:

Генерация карты сайта в HTML из XML: часть 2

Vladimir — Mon, 08 Nov 2010 12:04:38 +0000

Как сделать не более N ссылок на файл

Продолжение статьи «Генерация карты сайта в HTML из XML».

В этой части мы рассмотрим, как сделать так, чтобы на одной генерируемой странице располагалось не более определённого количества ссылок.

Нам понадобятся:

XSL из статьи «Преобразование карты сайта в список адресов для siege»:

version="1.0" encoding="utf-8"?>
version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:x="http://www.sitemaps.org/schemas/sitemap/0.9">
method="text" media-type="text-plain" indent="no"/>
elements="*"/>
match="/x:urlset/x:url">
select="x:loc" disable-output-escaping="yes"/>
> >
>
>
XSL из статьи «Генерация карты сайта в HTML из XML»:

version="1.0" encoding="utf-8"?>
version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:x="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns="http://www.w3.org/1999/xhtml" exclude-result-prefixes="x">
method="xml" indent="yes" encoding="UTF-8" doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/>
elements="*"/>

match="/x:urlset">
>
>
http-equiv="Content-Type" content="text/html; charset=utf-8"/>
>Site Map>
>
>
> href="http://blog.sjinks.pro/">Карта сайта>>
>
select="x:url"/>
>
>
>
>

match="/x:urlset/x:url">
>> href="{x:loc}"> select="x:loc" disable-output-escaping="yes"/>>>>
>
>
Немного фантазии

Алгоритм работы простой:

Преобразовываем исходную карту в текстовый список адресов (один URL на строку)
Разбиваем файл на несколько частей с заданным количеством строк
Преобразовываем каждый из полученных файлов в XML
Преобразовываем полученные XML-файлы в HTML

Пункты 3 и 4 можно совместить: вместо генерации XML-файла можно сразу генерировать HTML. Но на всякий случай будем генерировать и XML, и HTML.

Получим такой скрипт:

#! /bin/sh

xsltproc -o urls.txt sitemap2txt.xsl sitemap.xml
split -d -l 100 urls.txt map
for i in map*; do
awk '
BEGIN {
print "\
xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\
xsi:schemaLocation=\"http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd\"\
xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\">"
}
{
print ""$1""
}
END {
print ""
}
' $i > site$i.xml
xsltproc -o site$i.html sitemap2html.xsl site$i.xml
done

Всё просто!™