Программирование

... приличествующие анонсу двух ссылок:

Debian OpenSSL Predictable PRNG Toys
Исходное сообщение в DSA: DSA-1571-1 openssl -- predictable random number generator

Пользуясь случаем, в очередной раз вытираю ноги о миф, что открытость исходников - это путь к надежности. Баге - почти два года, система распространенная, сколько сейчас будет "взломов" (и без кавычек - тоже) - страшно подумать.

Не прислав мне никакого уведомления (хотя раньше присылали), NVidia выпустила CUDA 2.0 beta.

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

Из важного

• Поддержка Vista (32 и 64 бита);
• Нет поддержки GeForce 9800GTX (вышедшей на пару недель раньше этой беты), что довольно странно.
• С двойной точностью какая-то непонятная совсем история:
  1. В CuBLAS она заявлена в документации, символы в библиотеке имеются (собирать еще ничего не пробовал).
  2. В документации (programming guide) слово double встречается 8 раз (на 99 страниц текста), что как-то безобразно мало.
  3. Времена вычислений для double в соответствующей секции не описаны (но я подозреваю, что они другие, чем у float).
  4. Таблица с описанием double-функций (на которую есть указание в тексте) - отсутствует.
  Другими словами, работы ведутся и довольно скоро все может появиться.

Спешу обрадовать народы мира: проект, над которым последние два месяца мы работали совместно с Ильей Боргом наконец выпущен на публику.

LibRaw - библиотека для чтения raw-файлов:

• чтение (распаковка, раскодирование) неинтерполированых RAW-данных из файлов от 300 моделей цифровых фотокамер
• основана на исходных текстах dcraw
• громадье планов по избавлению от недостатков dcraw, небольшая часть которых уже выполнена

Потерял полдня, прежде чем сложил все кубики в пирамидку (и то, не уверен что правильно).

Нужно: получить PHP5 с клиентом PosgreSQL (всякие прочие extensions на вырост), в виде апачевского модуля, все происходит под FreeBSD7.

• Apache 1.3, все собираем из ports - не работает. SIGSEGV где-то внутри инициализации pthreads, хотя никому из участников эти threads нафиг не нужны и непонятно кто их приволок. /usr/local/bin/php - работает.
• Apache 1.3, собираем PHP --with-pgsql - все работает, пока нет загружаемых extensions. Как только появляется хоть одно - падаем.
• Apache 2.2, собираем все из ports - работает.
• FreeBSD6 в этот раз не пробовал, но когда в прошлый раз пробовал - работало.

Получается, из-за скромненькой фигулинки всем проектам показан переезд под Apache2 ? И mod_perl2 ? А mod_perl2 небось тоже не работает ?

MySQL не предлагать. С Apache я совладаю как-нибудь, а два сервера баз данных в моей жизни - это уже перебор. Снести семерку тоже не предлагать, UFS2 на терабайтных FS - уже перебор.

Продолжаем про острые углы.

Очень больно ударился об FreeBSD 7-STABLE на amd64, точнее об ейный компилятор C++.

Собирал buildworld 29-го февраля, с виду все как обычно. Однако часть собираемых на этой системе бинарников (наших, C/C++, никакого экстремизма) работает странно:

• один падает на ровном месте (не всегда, но есть test case), если отнести его на другую машину - продолжает падать. А если взять с другой машины (собранный там) и принести ко мне - все отлично работает;
• другой не может создать файлик BerkeleyDB 4.x (создав перед этим другой почти такой же). Аналогично, собранный на другой машине - у меня работает.

Сейчас опять делаю buildworld, если не поможет, то что, на 6.x откатываться ? А ZFS ?

Update

1. бинарный апгрейд на 7.0-RELEASE amd64 - не помог;
2. на 7.0-RELEASE 32bit - все отлично;
3. порча наступает на db->open(filename,DB_CREATE|DB_TRUNCATE), при этом файл создается (!) но код ошибки ENOENT

Update 2. На 32 бита не пересел, обидно ведь! С Berkeley DB совладал, но не понимаю почему этой проблемы не было на gcc 3 :). С самопадающим - совладать не могу пока.

Несмотря на мой пессимизм относительно сортировки строк с многобайтными символами в FreeBSD, жизнь оказалась лучше, чем мне казалось.

Наш читатель, Александр Загребин, любезно поделился исходником locale LC_COLLATE для FreeBSD, который лечит проблему сортировок для ru_RU.UTF-8. Я немножко поправил Makefile, чтобы результат ставился прямо поверх системного файла, выкладываю (с согласия автора, естественно) это для всеобщего использования:

• HTTP: http://blog.lexa.ru/files/ru_RU.UTF-8.LC_COLLATE.tar.gz
• FTP: ftp://ftp.lexa.ru/pub/domestic/misc/ru_RU.UTF-8.LC_COLLATE.tar.gz

Update
Я сделал работу над ошибками, обновленный вариант (с тем же URL) и комментарии к нему берите здесь.

Как я уже писал, при использовании UTF-8 в PostgreSQL под FreeBSD результат больно бъется: сортировка русских букв неправильная (касается это только буквы ё). Причина - в кривой locale под FreeBSD (и Mac OS X).

Естественно, на эти грабли уже много раз наступали и для PostgreSQL 8.1 существуют патчи имени Palle Girgensohn, позволяющие использовать IBM-овскую библиотеку ICU в которой все сделано правильно для безумного количества языков.

cd STLport-5.1.5/build/test/unit
gmake -f gcc.mak all-static 2>build.error >build.log

Получаю одно (!) сообщение об ошибке, размер сообщения 795 килобайт.

Как мне тут справедливо указали, настройка "приделывать rel=nofollow к комментариям и трекбекам" не влияет на содержимое тега CommentAuthorIdentity

Пятиминутный просмотр исходников показал, что это бага в MovableType, в функции реализующей вышеуказанный тег просто пропустили одну строчку

Прилагаемый патч решает эту проблему. Естественно, после приложения патча нужно перебилдить все странички.

Вот и пригодился ProNet-овский аккаунт. Я через него засабмитил тикет, посмотрим чем кончится.

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

Update: из саппорта ответили "читайте документацию" (см. комментарии). И ведь они правы.