qutIM — Компиляция из исходников на Gentoo 2008.0
Как известно, qutIM перешел на использование Qt 4.4. В Gentoo Linux 2008.0 Qt4.4 находится под хардмаском.
В
моем случае, в системе был установлен Qt 4.3. qutIM не может быть
скомпилирован на этой версии. Перекомпилировать все приложения,
использующие Qt 4.3 мне не хотелось. Поэтому предлагаю такой принцип
решения, которое в принципе должно подойти и для других дистрибутивов
Linux. Если коротко, то его суть в компиляции qt-4.4 и прописывании
пути к нему в cmake.
1. Качается Qt 4.4.3 с оф сайта
2. Распаковывается в какую-нибудь папочку
3. Запускаем
# ./configure -prefix /opt/qt-4.4.3
Таким образом, наш Qt будет находиться в отдельной папке и не будет мешать другим программам.
4. Компилируем и устанавливаем
# gmake
# sudo gmake install
Всё. Установка Qt 4.4 на это завершена.
Теперь приступаем к компиляции qutIM.
Забираем из SVN.
# svn co http://qutim.org/svn/qutim/
Переходим к плагинам и забираем ICQ.
# cd qutim/plugins
# svn co http://qutim.org/svn/icq
Компилируем qutIM.
# cd ../
# cmake -DQT_QMAKE_EXECUTABLE=/opt/qt-4.4.3/bin/qmake .
# make
Собственно -DQT_QMAKE_EXECUTABLE - и есть тот важный параметр.
Плагин к ICQ:
# cd plugins/icq
# /opt/qt-4.4.3/bin/qmake
# make
Также вас может заинтересовать icq, smaper, мобильный агент скачать
Проприетарные драйвера ATi на ядре 2.6.25
Поставил вот себе недавно Gentoo Linux 2008.0 с portage снапшотом от 12 ноября 2008 г. и ядром kernel-2.6.25-gentoo-r9. Решил поставить проприетарные драйвера на свой ATi Radeon 9600 Pro.
Решил воспользоваться факом Распространенные вопросы об ATI в Gentoo Linux. Но не тут то было. Получил по лбу ошибкой:
WARNING: modpost: module fglrx.ko uses symbol 'init_mm' marked UNUSED
Ну warning и warning скажете Вы. Но тем не менее удачно скомпилированный модуль отказывался запускаться:
FATAL: Error inserting fglrx (/lib/modules/2.6.25-gentoo-r9/fglrx/fglrx.ko): Unknown symbol in module, or unknown parameter (see dmesg)
init_mm собственно и является причиной.
В интернетах узнал, что у кого-то выползают ещё и такие ошибки:
fglrx: Unknown symbol flush_tlb_page Symbol init_mm is marked as UNUSED, however this module is using it |
Загуглив, решение было найдено.
Редактируем /usr/src/linux/arch/x86/kernel/init_task.c
Меняем строчку
EXPORT_UNUSED_SYMBOL(init_mm); /* will be removed in 2.6.26 */ |
На
EXPORT_SYMBOL(init_mm); |
Компилируем ядро и затем заново компилируем fglrx (ну или emerge ati-drivers).
Остается вопрос, как это всё будет выглядеть в 2.6.26.
Мысли о провинциальном интернете
Я вот живу в Тамбове. Город не такой уж и большой. В последнее время у нас появилось много новых провайдеров, предлагающих разные способы подключения к интернету, разные услуги, ТП. Но из-за того, что я живу в частном доме в частном секторе, где интернетом пользуется от силы человек 10, то у нас единственный способ подключения - Domolink DSL.
Все наверное знают насколько это дорого - пользоваться интернетом в провинции. За 128kbps я плачу 550 руб/месяц.
Недавно взял себе внешний ip. Так для этого пришлось идти в главный офис и писать там заявление.
В принципе, в статистике есть возможность добавления услуг и перехода на другой ТП, но они почему то не работают. Все равно надо идти в офис и писать заявление даже на такую мелочь как внешний IP.
Но всё бы ничего. Мне пришла в голову мысль, что можно было бы сделать услугу временного повышения скорости. Вот сейчас обновляю KDE с 4.0 до 4.1(фактически 4.0.99). При такой скорости это адски долго.
Почему никто не додумался сделать такую вот услугу. Посылаешь допустим смс-ку на короткий номер и у тебя допустим в течении суток скорость повысилась до 512 kbps. Да, в плане реализации это не так уж и легко. Биллинг будет очень замудрым. Но так ведь это выгодно для обеих сторон. Клиенту - удобство, прровайдеру - дополнительная прибыль.
Эх.. Придется ждать окончания закачки обновлений...
----------------
Now playing: Eyes Set To Kill - Reach
via FoxyTunes
Yet Another Tip: Всегда проверяйте входные параметры
Данная статья находится в стадии написания. Не обращайте внимание на ашипки. Ани сделаны спицальна.
"Вот и все... и нету Билла... жадность Билла погубила!" - м/ф "Остров сокровищ", Россия
Вот сколько народу не говори: "Проверяйте входные параметры! Не доверяйте им! Юзер может их изменить! Особенно, если эти данные потом идут в базу!", а всё равно народ про это забывает. Вот совсем недавно. В одном казино заметил такую фишку..
Товарищ, писавший его наверное где-то встречал подобные статьи на сабж, но или они были написаны чайником для промо своего сайта, или просто этот человек плохо читать умеет. Кодер сий написал однажды интернет казино.. Увы ООПом тут и не пахнет... Даже массивы используются раза два-три за весь проект... Контент сайта инклудится из обычных файлов. Да, эти файлы нельзя просто так нагло прочитать, религия htaccess не позволяет. Да и выйти на папку выше тоже не получается, проверяется этот параметр регэкспом вида альфанумерик. Это умно, это молодец. Кое какие параметры у него даже проверяются на содержание коварных символов ",`,' .. Да... Это он конечно молодец и несмотря на всю убогость кода, этот момент он пытался(именно пытался) продумать...
Главная убогость кода в том, что он работает только при register_globals = on! Но это вряд ли поможет, ибо зачастую(не всегда, но бывает) переменные определяются ручками. Однако! Перейдем к игре...
В казино есть игры, которые просто работают через <form> и метод POST. Игрок делает ставку, нажимает и получает результат. Все вроде нормально. Однако! Кодер ЛОПУХ! Разве можно доверять входным данным? Никак нет! НИКОГДА! Я даже своей бабушке верю больше чем им! Так вот попробуем догадаться как выглядит исходник... Напишу на родном русском языке:
если ставка больше суммы_на_счету то пошел на фиг;
если все нормально играем;
если мы выиграли то сумма_на_счету=сумма_на_счету + ставка умноженная на коеффициент выигрыша в игре, если мы проиграли, то сумма_на_счету=сумма_на_счету - ставка;
Поскольку все люди жадные, особенно те, что заведуют казино, то естественно выиграть вам там не дадут.... От того мы проигрываем больше чем выигрываем. С этим все согласятся... Ну и отсюда естественный вывод. А что если нам проиграть, но с отрицательной ставкой? А? Словили фишку? Вот тут то весь и прикол. Если параметр не проверяется, то будет так:
сумма_на_счету = сумма_на_счету - отрицательная_ставка;
Кто хотя бы отдаленно был когда то в далеком детстве знаком с математикой помнит глупое правило: минус на минус дают плюс... Да! Оно тут срабатывает, ибо параметр не проверяется. Эта штука также подходит к условию, что ставка должна быть меньше либа равна суммы на счету, ибо отрицательное число всегда меньше неотрицательного:) Истина)
Вот такие вот косяки и приводят к огромным проблемам!
А теперь бонус, кусок злого кода на PHP:
PHP:
mysql_query("update users set cash=cash-'$stavka' where login='$l'"); /** Юзер проиграл */
if ($card==$tuz2) /** Юзер выиграл */
{
$priz=$stavka*3;
mysql_query("update game_bank set wmr=wmr-'$priz' where name='lloto'");
mysql_query("update users set cash=cash+'$priz' where login='$l'");
}
Послесловие:
Также, ещё одно вполне разумное умозаключение имеет место быть. Допустим у нас игра наперстки. Это три наперстка, надо угадать где приз. Скрипту может передаваться также ведь и параметр с номером выбранного наперстка. Если же он не проверяется, то заменив его допустим на номер 4 мы будим всегда проигрывать!
Естественно я об этой фигне сказал админу этого казино, которому было кстати 17! Он все закрыл и отблагодарил меня) Трави бобров.. ой.. твори добро.. во!
Внимание, данные действия могут попадать под статьи УК РФ!
Bethrezen
настроение: Довольное
слушаю: Lamb Of God - Purified