By logging in to LiveJournal using a third-party service you accept LiveJournal's User agreement
Бывает. Случается такое, что skype перестаёт запускаться. И, казалось бы, skype не обновлялся, qt тоже за последний месяц не менялся и вдруг skype перестал запускаться. И выдаёт вот такую ошибку:
skype: symbol lookup error: /usr/lib/libQtDBus.so.4: undefined symbol: _ZN14QObjectPrivate15checkWindowRoleEvПервая же мысль линуксоида понятна — нет какой-то библиотеки. Надо проверить ldd. И делается следующее:
$ ldd /usr/bin/skype | grep 'not found'Но, увы, все библиотеки на месте. И тут большая часть linux-пользователей застревает. А следующий шаг - попытка зарезольвить символы.
$ ldd -r /usr/bin/skype | c++filt
linux-gate.so.1 => (0x002e1000)
libasound.so.2 => /usr/lib/libasound.so.2 (0x00808000)
libXv.so.1 => /usr/lib/libXv.so.1 (0x00c3b000)
libXss.so.1 => /usr/lib/libXss.so.1 (0x00304000)
librt.so.1 => /lib/librt.so.1 (0x0066d000)
libQtDBus.so.4 => /usr/lib/libQtDBus.so.4 (0x00b24000)
libQtGui.so.4 => /opt/google/earth/free/libQtGui.so.4 (0x00c41000)
libQtNetwork.so.4 => /opt/google/earth/free/libQtNetwork.so.4 (0x00110000)
libQtCore.so.4 => /opt/google/earth/free/libQtCore.so.4 (0x00308000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0023c000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00676000)
libm.so.6 => /lib/libm.so.6 (0x00256000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0027c000)
libc.so.6 => /lib/libc.so.6 (0x008ce000)
libdl.so.2 => /lib/libdl.so.2 (0x00298000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x01701000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x0029c000)
/lib/ld-linux.so.2 (0x00798000)
libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0x00602000)
libz.so.1 => /lib/libz.so.1 (0x002ac000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00a2b000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x002c3000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x002e2000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x002cc000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00645000)
libuuid.so.1 => /lib/libuuid.so.1 (0x002d6000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x002db000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x002fb000)
undefined symbol: qBadAlloc() (/usr/lib/libQtXml.so.4)
undefined symbol: QListData::detach_grow(int*, int) (/usr/lib/libQtXml.so.4)
undefined symbol: QListData::detach(int) (/usr/lib/libQtXml.so.4)
undefined symbol: QObjectPrivate::checkWindowRole() (/usr/lib/libQtDBus.so.4)
undefined symbol: qBadAlloc() (/usr/lib/libQtDBus.so.4)
undefined symbol: QMetaType::registerTypedef(char const*, int) (/usr/lib/libQtDBus.so.4)
undefined symbol: QListData::detach_grow(int*, int) (/usr/lib/libQtDBus.so.4)
undefined symbol: QListData::detach(int) (/usr/lib/libQtDBus.so.4)Кто уже догадался в чём проблема — молодец. А я же лезу в google/codesearch в поисках qBadAlloc() и вижу, что по идее он должен бы быть определён в libQtCore.so.4. И тут всё становится ясно — свежеустановленная Земля Гугла (которая Google.Earth) переопределила системную libQtCore.so.4 своей версией. Системная, естественно, лежит на своём месте в /usr/lib — значит, это какая-то магия с ld.so. В данном случае магическим оказался файл /etc/ld.so.conf.d/googleearth.conf, который googleearth совершенно не нужен, т.к. запускающий скрипт устанавливает корректную переменную LD_LIBRARY_PATH.
После удаления /etc/ld.so.conf.d/googleearth.conf и skype и googleearth работают корректно. А в багтрекере убунты этот баг вообще к пакету qt4-x11 умудрились повесить. Чудаки.
<message from="o***@jabber.ru" type="headline" to="l***@darkk.net.ru/main"> <event xmlns="http://jabber.org/protocol/pubsub#event"> <items node="storage:bookmarks"> <item id="current"> <storage xmlns="storage:bookmarks"> <conference minimize="0" autojoin="0" name="akunamatata" jid="akunamatata@conference.jabber.ru"> <nick>o***</nick> </conference> <conference minimize="0" autojoin="1" name="cyberindustrial" jid="cyberindustrial@conference.jabber.ru"> <nick>п***</nick> </conference> <conference minimize="0" autojoin="0" name="cyberindustrial" jid="cyberindustrial@conference.jabber.ru"> <nick>м***</nick> </conference> <conference minimize="0" autojoin="1" name="dslr" jid="dslr@conference.jabber.ru"> <nick>o***</nick> </conference> </storage> </item> </items> </event> <delay xmlns="urn:xmpp:delay" stamp="2010-06-23T13:31:24Z"/> </message>
ru_jabberСпросил тут у меня Юра Поздняков: «ты знаком с какой-нибудь бесплатной онлайн таск трекинг системой?» Да, конечно, с тысячами их: bugzilla, trac, redmine, flyspray, mantis и т.д. и т.п. Поговорив еще пару минут, я выяснил, что на самом деле нужно совсем другое. Нужен инструмент, повзволяющий единственному разработчику проекта устаканить происходящее в голове, разбить задачи на подзадачи, расставить очерёдность выполнения задач — и более ничего.
10 лет назад Joel предлагал использовать Excel вместо MS Project как один из инструментов управления проектом — т.е. использовать более общий инструмент для частной задачи, вместо использования одного из специализированных решений. По словам самого Джоеля эта статья про Excel устарела минимум года три назад, но принцип, высказанный еще Кеном Томпсоном остаётся по прежнему актуальным. When in doubt, use brute force.
Я года два назад нашёл полностью меня устраивающий кроссплатформенный инструмент для этой задачи — freemind. В меру «трендовая» вещь с красивым названием «карты памяти», а по сути для меня это всего лишь удобный древовидный блокнот с внешными ссылками, открываемыми в браузере. Утилита сия заменила мне персональный багтракер и локальную wiki. Единственное существенное дополнение к freemind в моём арсенале борьбы с проблемой хранения слабоструктурированной информации за последние полтора года — google calendar, используемый для отслеживания событий, строго привязанных к дате и времени.
Осознав возможность таск трекинга без таск трекера, Юра ушёл просветлённый.
7 месяцев назад я купил забавную железку — DIR-320, забавную тем, что на ней, как и на каждом первом SOHO-роутере, бегает linux и, более того, под которую несложно состряпать свою прошивку.
Увы, полгода назад ситуация с поддержкой DIR-320 ванильным ядром была довольно грустна: если хотелось сохранить работоспособного wi-fi, то требовалось ставить ядро 2.4, в котором довольно плохо поддерживался USB. Это «довольно плохо» выражалось в том, что в произвольные моменты времени подключенная через USB флэшка или винт «отваливались» и более в систему не возвращались без классического паса руками «выключить и снова включить».
В ядре 2.6 же в драйвере b43 на тот момент не было поддержки LP_PHY для чипа BCM4318, точнее, работа над ним только начиналась и реализация была помечена как BROKEN. Но и в настоящий момент поддержка железа тоже далека от идеала, на странице драйвера b43 отмечено, что режим точки доступа на чипах 4318 не поддерживается из-за больших потерь пакетов при высоких скоростях. Действительно, при попытке завести точку доступа на всех 54 мегабитах 802.11g клиент к точке даже не мог подключиться из-за потерь пакетов, но если ограничить аппетиты 11 мегабитами 802.11b, то связь хоть и достаточно паршиво, но работает — для серфинга хватает.
Другое занятное развлечение — упихать максимально возможный набор утилит в 3.5 мегабайта флэшки. У меня уместились:
Для более плотного утрамбовывания я выкинул httpd из busybox, заменил dnsmasq на связку из udhcpd (для DHCP-сервера) и скриптов для iptables, которые позволяют отдавать статические настройки DNS через DHCP, чем выйграл порядка 80 килобайт. Также я заменил «ядрёный» NFS-сервер на unfs3, тут выйгрыш составил более 200 кб. При сборке transmission я использовал статические версии openssl, curl и libevent, что дало еще порядка полумегабайта места. Конечно, в openwrt включён скрипт mklibs.py, оптимизирующий динамические версии библиотек, удаляя из них не используемый приложениями код, но в случае с transmission он по какой-то причине работал некорректно, приводя к segfault при запуске демона. Судя по информации, полученной скупыми отладочными утилитами, mklibs.py вырезает много лишнего из libnsl.so и librt.so. Статическая линковка же является более отработанной технологией и в случае, если библиотека используется только одним приложением, даёт даже более хорошие результаты чем использование mklibs.py, но, увы, uclibc и libm остаются не оптимизированными. Вероятно, размер прошивки можно уменьшить еще на ≈100 кб., совместив эти два метода.
Конечно, целый набор ложек дёгтя тоже имеет место. Памяти на маршрутизаторе всего 32 мегабайта и одновременный старт NFS-сервера и torrent-клиента приводят к неимоверным тормозам всего кроме самой маршрутизации, доводя LA до ≈5. Поэтому стоит написать какие-то скрипты, переключающие «режимы работы» роутера. Более того, эти скрипты вполне можно запускать с помощью ssh, web-браузера или кнопки на торце роутера. Другой неприятностью является далеко не идеальная работа wi-fi, но для нужд интернет-радио и просмотра фильма с NFS-сервера стабильности хватает. Третья — uClibc не поддерживает fallocate и, соответственно, быстрое выделение нефрагментированного участка диска на разделе с ext4, а eglibc без плясок с бубном не собирается. Других проблем я пока не обнаружил.
Если кому-то интересны мои конфиги — их можно взять по адресу http://darkk.net.ru/home/openwrt
Подумалось мне вчера: а какие риски есть в отключении запроса PIN-кода на SIM-карте. Плюсом обычно называется то, что вор, укравший телефон, будет достаточно глуп, чтоб позвонить с него и «засветить» своё местоположение и контакты, а честный человек, найдя потерянный телефон, сможет позвонить кому-нибудь из знакомых владельца. Для последнего, кстати, зачастую не требуется SIM-карта, т.к. многие телефоны хранят записную книжку во внутренней памяти.
Но есть и как минимум один минус, который может быть достаточно существенным. Не раз уже обсуждались проекты по использованию мобильного телефона в качестве некоторого элемента системы идентификации личности. В таких случаях кража/утеря SIM-карты вполне может привести к краже личности. Кстати, одна из существующих мошеннических схем в рунете напрямую является «кражей личности» — кража ICQ-аккаунта с последующей просьбой «занять webmoney» у доброй половины контактлиста.
Глобальная авторизация по SIM-карте — проект, граничащий с абсурдом, но и сейчас у утери симки есть довольно интересные побочные эффекты. Практически у любого ОпСоСа сегодня есть так называемый интернет-помощник. У меня на столе нашлись SIM-карты МТС и билайна: сайты обоих операторов предлагают возможность сменить пароль для доступа к интернет-помощнику, не зная старого, позвонив по определённому номеру. Помимо возможности отключения/подключения услуг на этих сайтах можно узнать полное имя владельца SIM-карты, а на сайте билайна — и его домашний адрес, что могло бы сильно подставить одного моего знакомого, таскавшего симку в качестве брелока на связке ключей…
Интересно, какая информация утекает в «личных кабинетах» других операторов?…
Судя по всему, снимать бан с rss-proxy в ближайшее время никто не собирается. Но небольшая шумика произвела и положительный эффект — один из разработчиков SUP сказал мне примерно следующее: «В мире много несчастий и нестандартных интерфейсов. Один из них — XML-RPC API livejournal.com. Документация устаревшая — но всегда можно погуглить, погуглить и найти код, который и есть лучшая документация».
Так я и поступил, на выходе получил скприт ljfeed.py, который одним запросом выгребает 50 последних записей с френденты и форматирует из них Atom-поток. Скрипт лежит на github, если кто-то хочет превратить его в вебсервис — помните про User-Agent, если кто-то хочет поставить его на свой сервер — помните о политике livejournal относительно ботов.
Полагаю, страждущим может помочь 
kalan, предлагавший помощь в виде некоего сервера. Инициатива, как говорится, наказуема — незнакомых мне желающих к нему и направляю, у меня же на сервере в crontab пока только одна строчка такого вида:
# Every 3 hours
42 */3 * * * $HOME/ljfeed/ljfeed.py --user darkk --pass_md5 1…4 --output $HOME/public_html/….xml
Также, в сообществе 
changelog появились записи про OAuth — возможно, через некоторое время политика livejournal относительно внешних вебсервисов будет более определённой, а до тех пор тратить больше часа-другого на возню с френдлентой в Google Reader смысла я не вижу.
