Yandex.Money password token

Давно собирался написать об этом занятном приборчике, но всё руки не доходили. Исправляю сию досадную оплошность.

В общем, предыстория: банк, которым я пользуюсь, имеет прекрасную сцепляемость с кошельком Яндекс.Денег, поэтому выбор платёжной системы для меня был очевиден (пайпалы и прочие у меня отдельно).

Для Яндекс.Денег обычно используется дополнительный, платёжный пароль, не связанный с общими яндексовскими сервисами - каждый раз при проведении платежа необходимо его вводить, и это a little bit annoying, особенно если пароли генерируются какой-нибудь специальной программой.
Видимо, отчасти и поэтому (а ещё чтобы каждый раз не передавать платёжный пароль по сети) Яндексы ввели альтернативные системы проверки авторизации. Первый из них - уникальная для каждого пользователя таблица с числобуквенными кодами, для проведения платежа нужно ввести три кода из случайно выбранных системой ячеек. Табличка приходит в .jpg, можно её распечатать и носить с собой, можно там же заказать уже напечатанную на пластиковой карте (что не в пример удобней).
Другой способ - с использованием электронного токена, генерирующего случайный код при нажатии на кнопку.


Для активации работы с токеном в настройках кошелька нужно ввести его серийный номер.


После этого при всех платежах вместо пароля или кодов из таблицы нужно будет вводить номер, сгенерированный токеном по нажатию кнопки на нём.

Сам токен очень маленький, ношу его как брелок на ключах - удобно, не нужно держать в голове ещё один длиннющий разношёрстный пароль.

Seti@Home

Думаю, я не единственный человек, которого мало заботит скорость загрузки операционной системы - по той простой причине, что компьютер выключается крайне редко. В то время, как я не пользуюсь им непосредственно, ящик гудит, ест электричество и попутно качает-раздаёт торренты.
Однако торренты - довольно нерациональное расходование хардварных ресурсов, коли уж они в любом случае есть. Можно ещё немного озадачить железки, чтобы они приносили пользу науке, например.

Наверняка все уже слышали о распределённых вычислениях. Для тех, кто не в курсе, совсем вкратце: большую задачу можно разбить на много мелких и раскидать их по разным компьютерам в Сети. Получается гигантский (ну или не очень) кластер, который может делать что-то полезное. Ну, или не делать.
Одним из проектов университета Беркли является поиск вероятных внеземных сигналов. Для этого нужно проанализировать гигантские объёмы данных, что не под силу даже современным супермейнфреймам. Тут в игру вступает сообщество - отдав немножко вычислительных ресурсов компьютера (главным образом во время простоя) можно конкретно помочь такой благородной цели. Вообще, кроме поиска внеземного разума, проектов, использующих cloud computing вагон и тележка, и каждый может найти то, во что ему интересно внести свою лепту.

Для большинства из этих проектов используется программная платформа Boinc, которая от версии к версии всё больше обрастает разным полезным функционалом. По аналогии с распараллеливанием на разные компьютеры, при наличии нескольких ядер/процессоров поступившую задачу можно разделить на разные потоки. Одним из наиболее инновационных решений для расчётов является технология от Nvidia под названием CUDA. Если быть кратким, то она позволяет использовать вычислительные мощности процессоров видеокарты в пользовательских приложениях, а не только при использовании DirectX/OpenGL API.
Процессоры видеокарт довольно "узкоспециализированы" - они заточены под выполнение лишь некоторых математических преобразований, используемых для 3D-рендера. Однако многие эти же преобразования используются в упомянутых научных вычислениях, что может дать значительный прирост в скорости обсчёта и обработки данных. Эти же алгоритмы могут быть использованы, кстати, для сжатия видео тем же h264-кодеком - и этот подход предоставляет впечатляющие результаты. По сравнению даже с топовыми процессорами средняя видеокарта при полном использовании её процессоров даёт прирост вплоть до 10-20 раз! Это достигается не только "заточенностью" шейдеров видеокарты, но и большим её количеством - в моей далеко не самой новой Geforce 9600GT таких процессоров 64, причём каждый из них - многопоточный, и может брать на себя до 512 потоков. Таким образом, использование CUDA для многих сложных математических расчётов имеет более чем очевидную причину.

Ну, теперь от теории перейдём к сухой практике. Я запускал boinc-client на Ubuntu 9.04 x86-64, и хоть и дистрибутив и является самым популярным, "с полпинка" это дело не завелось.
Итак, первое, что нужно установить - это последние бета-драйвера от nvidia (на момент написания - 190.32). Подключение соответствующего репозитория описано в предыдущей записи этого блога, единственное, что хочу подчеркнуть - ставить нужно именно 190-ю версию драйвера, а не стабильную 185-ю.
После установки драйверов мы имеем поддержку CUDA (а также бонусом vdpau). Следущее, что нужно поставить отсюда - CUDA Toolkit и (опционально, но я рекомендую) CUDA SDK. Установка очевидна, так что вдаваться в подробности не буду. Жаль, конечно, что всё это инсталлируется из .sh-файлов, а не идеологически верных .deb-пакетов - надеюсь, скоро этот досадный недочёт исправят, и появится как минимум launchpad-репозиторий с соотв. содержанием.
После установки нужно "дообъяснять" системе, что CUDA есть и функционально - для этого в PATH нужно добавить путь к исполняемым файлам "куды" (по-дефолту /usr/local/cuda/bin), и дописать к LD_LIBRARY_PATH директорию с соответствующими библиотеками (/usr/local/cuda/lib или lib64). Проще всего создать новый .conf-файл в /etc/ld.so.conf.d/. Будьте внимательны, если у вас 64-разрядная система, прописывать нужно именно путь к lib64-директории!
После этого можно установить SDK (от пользователя) и попробовать скомпилировать тамошние примеры - есть интересные штуки, наглядно показывающие преимущества шейдеров над ЦП, ну и заодно можно проверить работоспособность самой технологии.

Итак, если всё вышеперечисленное заработало, можно "завершать операцию". Установка непосредственно boinc предельно проста - разве что я ставил его не из основного репозитория убунты, а из getdeb-а - там он самый свежий и точно "умеет" Cuda, если версия младше, кажется, 6.3, то уже ничего не получится. Ставить нужно только пакеты boinc и boinc-client, ну и boinc-seti-app-seti, если хотите присоединиться именно к поиску иноплане-тян. Для удобства настройки и использования также рекомендую пакет boinc-manager - он позволит управляться с демоном из гуя.

Несмотря на заявленную поддержку, сразу ничего не заработало, как водится - в логах упрямо пишется, что CUDA not found.
Первое, что нужно сделать - навести симлинк на /usr/local/cuda/lib/libcudart.so в /var/lib/boinc-client/ или, если не помогло, в /usr/lib/boinc-client/. Ну, не забывайте про особенности 64-битных систем - в их случае симлинк наводится на либу из соответствующей директории.
Из-за того, что демон boinc-а запускается под своим, отдельным юзером, возникает довольно неочевидная проблема - пользователь этот не имеет прямого доступа к видеокарточке. Исправить это можно, добавив его в группу video (usermod -a -G video boinc).

Собственно, после этого всё внезапно должно заработать - об этом довольно очевидно сообщат надписи в логе boinc вида "CUDA devices found" и "Coprocessor: GeForce 9600 GT (1)".

Самое главное во всех этих вычислениях - что мы, собственно, как старикан Вернандский завещал, работаем на ноосферу, а значит - всё одно на эволюцию.

Если заметите какие-то неточности в описании, или возникнут сложности - пишите, попробуем разобраться вместе.

Ubuntu+nvidia190+kernel2.6.31

9.04 убунту наконец-то можно довольно успешно срастить с ядром 2.6.31 и последними драйверами нвидии.

PPA-репозиторий последних нвидий: добавить /etc/apt/sources.list.d/nvidia-ppa.list с содержанием:

deb http://ppa.launchpad.net/nvidia-vdpau/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/nvidia-vdpau/ppa/ubuntu jaunty main

И импортировать ключ цифровой подписи для этих дебок:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CEC06767

Не забудьте сделать aptitude update, чтобы перечитать содержимое репозиториев (после добавления нового).
После этого можно уже свободно ставить дрова - на выбор есть стабильные 185-е и бета 190-х. Ищутся все через aptitude search nvidia-185 или nvidia-190, соответственно.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31/ - тут лежит 31-е ядро для i386 и amd64, ставится через dpkg. Модули нвидии и Sun-овского vbox-а собираются "на ура".

zsh+vcs trick

В одном из предыдущих постов я походя "зацепил" настройку шелла для поддержки одной из VCS - git. Так как сейчас приходится равнопеременно работать с творением Линуса и subversion, захотелось, чтобы было всё и сразу.

Велосипеды были отметены сразу, а последовательное гугление вывело на эту статью. Собственно, практически всё и было взято оттуда, с небольшими изменениями.

Итак, с места в карьер результат:


И (обработанная) часть конфига, которым удалость достигнуть видимого результата:

autoload colors
colors

autoload -Uz vcs_info

# set some colors
for COLOR in RED GREEN YELLOW WHITE BLACK CYAN; do
    eval PR_$COLOR='%{$fg[${(L)COLOR}]%}'
    eval PR_BRIGHT_$COLOR='%{$fg_bold[${(L)COLOR}]%}'
done
PR_RESET="%{${reset_color}%}";

# set formats
# %b - branchname
# %u - unstagedstr (see below)
# %c - stangedstr (see below)
# %a - action (e.g. rebase-i)
# %R - repository path
# %S - path in the repository
FMT_BRANCH="${PR_GREEN}%b%u:%c${PR_RESET}" # e.g. master¹²
FMT_ACTION="(${PR_CYAN}%a${PR_RESET}%)"   # e.g. (rebase-i)
FMT_PATH="%R${PR_YELLOW}/%S"              # e.g. ~/repo/subdir

function precmd {
    vcs_info 'prompt'
}

function rprompt {
    local brackets=$1
    local color1=$2  
    local color2=$3  

    local bracket_open="${color1}${brackets[1]}${PR_RESET}"
    local bracket_close="${color1}${brackets[2]}"          

    local git='$vcs_info_msg_0_'                           
    local cwd="${color2}%B%1~%b"

    RPROMPT="${PR_RESET}${bracket_open}${git}${cwd}${bracket_close}%# ${PR_RESET}"
}

function lprompt {
    local brackets=$1
    local color1=$2
    local color2=$3

    local bracket_open="${color1}${brackets[1]}${PR_RESET}"
    local bracket_close="${color1}${brackets[2]}${PR_RESET}"
    local colon="${color1}:"
    local at="${PR_BRIGHT_GREEN}@${PR_RESET}"

    local user_host="${PR_YELLOW}%n${at}${PR_YELLOW}%m"
    local vcs_cwd='${${vcs_info_msg_1_%%.}/$HOME/~}'
    local cwd="${color2}%B%20<..<${vcs_cwd}%<<%b"
    local inner="${user_host}${colon}${cwd}"

    PROMPT="${PR_RESET}${bracket_open}${inner}${bracket_close}${PR_RESET}$ "
}

lprompt '[]' $BR_BRIGHT_BLACK $PR_WHITE
rprompt '()' $BR_BRIGHT_BLACK $PR_WHITE

Изменения по сравнению с оригинальным "рецептом" из упомянутой статьи - изменены "стороны" показа директории и бранча; мне показалось, что будет логичней, если бранч будет "появляться" справа, а директория и остальная стандартная инфа - болтаться привычно слева. Ну и цвета сделал чуть более выделяющимися, да кое-где поставил делимитеров. Детальные описания всего этого священнодействия можно поглядеть всё в той же статье - не вижу смысла его сюда копипастить.

Если кому-то может пригодиться, мой полный конфиг zsh можно забрать тут.

Fibonacci\.(rb|c|java|php) и скука

Вечером в голову взъелась мысль самому проверить, настолько ли пхп тормознут, насколько убог. Попутно вышло немножко (пусть и баянно) потестировать производительность ещё кое-чего, решил поделиться результатами с общественностью.
Особенно растекаться мыслью по древу здесь нечего, поэтому изложу тезисно. Первое, что пришло на ум - ряд Фибоначчи. Простой, но ёмкий алгоритм, считать будем 100000-е число.
(реализации могут хромать, писалось на коленке "просто чтобы посмотреть")

Java (1.6.0.14 on Sun):

import java.io.*;
import java.math.BigInteger;
import java.util.Date;

class Fibonacci
{
    public static void main(String args[])
    {
        System.out.println("100000-е число Фибоначчи");
        long start_time = System.currentTimeMillis();
        fibonacci(100000);
        long end_time = System.currentTimeMillis();
        System.out.println("Время выполнения:" + (end_time - start_time));
    }

    public static void fibonacci(int n)
    {
        BigInteger a = BigInteger.valueOf(0);
        BigInteger b = BigInteger.valueOf(1);

        for (int i=0; i<n; i++) {
            a = a.add(b);
            b = a.subtract(b);
        }
        System.out.println(a.toString());
    }
}

"Чистое" время выполнения ~2.35c - надо учитывать, что сюда же входит время на загрузку виртуальной машины. Впрочем, учитывая, что библиотек импортируется минимум - основное время всё же тратится на цикл. В код включён замер времени выполнения самого цикла, отдаётся чистое количество миллисекунд (которое я ночью так и не раскурил).

Следующий пример - на ruby (1.8.7p72):

class FibonacciRb
  def self.main
    #puts "Num of seq:\n"
    puts "100000-е число Фибоначчи"
    n = 100000 #STDIN.readline.to_i
    fibonacci(n)
  end

  def self.fibonacci(n)
    starttime = Time.now.to_f
    a, b = 0, 1
    n.times do
      a, b = b, a + b
    end
    exectime = Time.now.to_f - starttime
    printf("%d\n", a)
    printf("Время выполнения: %.2fs\n", exectime)
  end
end
FibonacciRb.main()

Время вышло около 0.9с - один из лучших результатов на сегодня. Реализация jruby 1.3 (аналог ruby 1.8.6p287) выполнялся примерно на одну секунду с небольшим быстрее - 1.9-2.2. Скомпилированный javac класс опережает его не больше чем на 10мс.

Один из самых быстрых, но кошмарных результатов показал php. Встроенные средства или библиотеки не дают возможности работать с такими большими числами, поэтому был взят Math_BigInteger из Pear-а (не обновлявшийся уже несколько лет):

<?php
include('Math/BigInteger.php');

echo("100000-е число Фибоначчи:\n");

$n = 10000;

$a = new Math_BigInteger(0);
$b = new Math_BigInteger(1);

for ($i=0;$i<$n;$i++) {
    $a = $a->add($b);
    $b = $a->subtract($b);
}
echo($a->toString());

Даже в такой реализации PHP осилил всего 2090 целочисленных регистров (из 20899) за 0.9 секунды (дальше валится). Искать ещё-одну-костыльную-реализацию BigInteger меня заломало, хотя может быть и есть что-то работающее.

Несмотря на всё, наибольшую скорость показал (сюрприз, ага) ANSI C. Скомпилированный gcc с параметрами -O3 исполняемый файл посчитал искомое число всего за 0.3 секунды. Собственно, как нормальный макроассемблер С не умеет "из коробки" работать с 20000-значными числами, и для целей поддержки этого был беззастенчиво использован GNU MP.

#include <stdio.h>
#include <gmp.h>

int fibonacci(int n);

int main()
{
    int n;
    printf("100000-е число Фибоначчи:\n");
    n = 100000;
    fibonacci(n);
    return 0;
}

int fibonacci(int n)
{
    int i;
    mpz_t a, b;
    mpz_init(a);
    mpz_init(b);
    mpz_set_ui(a, 0);
    mpz_set_ui(b, 1);
    for (i = 0; i < n; i++) {
        mpz_add(a, a, b);
        mpz_add(b, a, b);
    }
    gmp_printf("%Zd\n", a);
    mpz_clear(a);
    mpz_clear(b);
    return 0;
}

Все эксперименты (в оконцовке) проводились на Ubuntu 9.04 x86-64, проц AMD Athlon 64 1.8GHz, 3Gb RAM (хотя все сырцы, кроме сишных, написаны и опробованы на ходу в метро на EeePC 900 =) ).

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

Upd.2: В комментарии было предложено реализовать варианты с использованием рекурсивного алгоритма. Да, в идеале он выглядит логичней и компактней, но... Попробуйте сами ;) Результата на ruby (1.8-1.9, jruby) я не дождался даже для 1000-го числа, 100-е за нормальное время посчитали только ruby 1.9 и (как ни странно) jruby (даже в режиме 1.8).
Всё остальное у меня валилось stack level too deep (что неудивительно, если рассчитать сложность алгоритма и количество рекурсий).

Upd.3: Камрад Денис из Уфы прислал "плоский вариант" на python:

def fibiter(a):
        i = 0
        j = 1
        count = 1
        while count < a:
                j = i + j
                i = j - i
                count = count + 1
        return j
print fibiter(100000)

(Блоки отступами - это полный вынос мозга)

Ну и напоследок - самый быстрый и "красивый" вариант, разумеется на Сях, и разумеется "читерский" :-) *барабанная дробь* Миллиардное число Фибоначчи! Рекомендую перенаправить вывод в файл, потому что число выйдет в длину около 200 мегабайтов.

#include <stdio.h>
#include <gmp.h>

int main()
{
    printf("100000-е число Фибоначчи:\n");
    mpz_t n;
    mpz_init(n);
    mpz_fib_ui(n, 1000000000);
    gmp_printf("%Zd\n", n);
    mpz_clear(n);
    return 0;
}

Ubuntu с глюками

"Безгрешных" дистрибутивов не бывает. Ну вот в принципе. Как были в софте баги, так и останутся они до конца времён. Очень часто баги эти бывают вызваны не столько некомпетентностью программистов (хотя это по-прежнему наиважнейший фактор их появления), сколько "удачным" стечением обстоятельств.
Баги в законченных дистрибутивах - это вообще отдельная песня. Если для отдельно используемого софта чаще всего можно отправить прямой багрепорт разработчику (хотя и это-то редко практикуется, к сожалению), то в дистрибутивах чаще всего бага проходит долгий путь "любимый форум - общий форум - форум разработчиков/дистрибутива - багрепорт в трекер ментейнеров - багрепорт в трекер программы". Последнее чаще всего уже происходит по инициативе ментейнера - если он толковый, разумеется. Почему всё так неспешно - очень часто сбой может быть инициирован "запилами" самих ментейнеров - сторонние патчи и всё такое. As result, разобраться в такой каше в том, кто же всё таки виноват, и кто должен всё исправлять, довольно проблематично. И бага продолжает болтаться со статусами вида "wontfix", а страдает конечный пользователь.
Разумеется, ещё чаще такое бывает из-за банального раздолбайства ментейнера - многие, особенно в небольших дистрибутивах, берут на себя море пакетов (пусть и беззастенчиво забирая их у какого-нибудь из "старших" дистроиздателей), и в итоге не справляются со своевременными заплатками. Однако огрехи (и крупные!) порой случаются и у "главных" дистроделов, причём такие, что впору хвататься за голову и бежать в горы.

Типичный пример - нынешняя ситуация в мейнстрим-убунте и ext4. Если кто не в курсе, кратко опишу ситуацию: в дефолтном 2.6.28 ядре работа с EXT4 из рук вон плохо. Это одна из самых быстрых современных файловых систем, и терять возможность работы с ней довольно удручающий факт. А глючит система при работе с ext4 не по-детски - при мало-мальски активной работе с винтом мгновенно следует полный фриз системы. Даже без SysRq. Как мне посчастливилось убедиться, баг этот присутствует исключительно в убунте, соответственно, виноват какой-то из ментейнеровых патчей. Баг серьёзный, и естественно присутствует в трекере, но что мы видим? До сих пор единственный метод лечения - поставить более свежее ядро.
Ну, в отдельных ppa-репозиториях можно найти и 2.6.29-е ядро. Вполне нормальное, работоспособное, ext4 можно использовать дальше. Что происходит дальше? Зарегистрированный, упрямый баг с ALSA - звук постоянно "икает". Забороть можно только установив ещё более свежее ядро.
Под 2.6.30 нет даже PPA. Добрые люди собирают и выкладывают его отдельно. Окей, dpkg -i в зубы - всё не руками собирать, нормально. Сразу можно мужаться - "ломается" изрепозиториевый драйвер убунты. В разнесчастном vesa-mode продолжаем блуждать по launchpad в поисках ещё одного ppa-репозитория с более свежими драйверами, бо скачанный с nvidia.com "некошерен" и вообще заставить его работать довольно нетривиальная задача (все знают).

В итоге, конечно, всё нужное найдено и поставлено - вполне по-людски, если не из репозиториев, то хотя бы из .deb-пакета, но "осадок"... Один из самых популярных дистрибутивов, такая тестируемость - и тут нате, на протяжении пяти месяцев явно critical бага остаётся в живых. В общем, выводы, по-моему, баянны и былинны: "не все убунты одинаково полезны", выбирать дистрибутив лучше исходя не из общественного мнения, а из собственного взгляда на жизнь и поставленные задачи, etc. В целом, убунта хорошо (лучше большинства) работает, если не делать ничего не-дефолтного. Если хочется каких-то нестандартных решений - приходится либо бороться с местечковыми проблемами, либо выбирать дистр изначально "широких" взглядов и проделывать там до кучи ещё и работу по приведению его в более-менее привычный вид.

Кстати, та же самая убунта у меня на EeePC 900 с неделю назад с хрустом развалилась на равные семядоли - это при "ровном" использовании, без апдейтов, без изменения настроек уже два-три месяца. Скрипты из /etc/rcS.d запускаются в произвольном порядке, драйвера кардридера сегфолтятся в любой момент времени, и прочие мелкие радости жизни. Память/SSD не битые, проверено. Свежеустановленный дебиан (тьфу-тьфу) работает как часы. Мистика-с...

Old-school

На еепце решил сменить привычный гном на window maker. Вот что из этого получилось:

Temporary workplace...

Acer Aspire 5310 Service Manual

Может кому-то понадобится - еле нашёл-скачал в Сети, nodevice.com предлагает такое только за бабки

Сервисный мануал Acer Aspire 5310

Это я сегодня разбирал-чистил свой большой ноут.

tip: цветной svn diff

После git-а в subversion оч не хватало цветного афроамериканского :) вывода svn diff.

Решение простое - ставим colordiff и в ~/.subversion/config прописываем в секции [helpers] параметр
diff-cmd = colordiff

colordiff есть в репозиториях основных linux-дистрибутивов.