Посмотрев на стандартную библиотеку C++, у меня появилась мысль попробовать решить ту же задачу средствами языка Го. У меня было время немного посмотреть на него, что-то понравилось, что-то так себе (это будет отдельной темой), было время прочитать ключевую работу тов. Хоара. Ну а чтобы лучше понять, как оно работает, неплохо бы попробовать что-нибудь сделать.
Читайте далее »
Попался занятный случай необходимости реализации ⋁-параллелизма на C++. Так получилось, что до этого я вообще не работал с std::thread и сопутствующим, решил поглядеть, что к чему.
Читайте далее »
Вот интересно, увижу ли я когда-нибудь виндовых программистов, умеющих грамотно пользоваться репозиториями кода? По некоей причине (говорят, она уходит корнями в ТФС) единственное, что может делать с репозиторием виндовый программист — это вываливать туда кучи мусора с комментариями типа «fixed». Понять, что изменилось, почему изменилось, какие нюансы, почему прикоммичены какие-то бинари, журналы, совершенно несвязанные изменения, невозможно никак.
Просто дамп состояния. Где-то с таким же успехом можно раз в день синхронизировать каталог с проектом по принципу рсинка, есть ощущение, что с точки зрения виндового программиста не поменяется ничего. Причём, различие проходит по чисто культурному признаку, программист может быть и весьма толковым, но коммитить код он будет именно так — большими несвязными кусками вместе с бинарями и прочим мусором, комментируя как «fixed» или «$DATE commit».
А так как различие чисто культурное, то и попытки пояснить, что бинари коммитить в репозиторий не надо, приводят к непониманию — а чего, собственно, плохого-то? Попытки поговорить о структурировании изменений, понятных подробных комментариях в сообщениях это вообще за гранью понимания, считается, что вот есть код и всё хорошо. А как в этом коде потом разбираться без понятной истории изменений?
И несмотря на опыт общения с, казалось бы, совсем разными виндовыми программистами, в этом аспекте они просто близнецы-братья. Как с этим бороться, непонятно. Может быть пора уже начать нести свет знаний в массы, когда-то такая мысль была, потому как красноглазые программисты тоже умеют коммитить что попало как попало, но там это и изначально реже, и бороть получается быстро, если встречается. А тут же ж просто беда.
Рассказ Алексея Березина трёхлетней давности как-то прошёл мимо меня, а он прекрасен, явно писан с натуры. С удовольствием наверстал упущенное. Как оказалось, нынче есть ещё и две экранизации: наша и импортная.
Некоторое время назад прикрутили к рабочим сборкам статический анализ кода с помощью Clang. В силу специфики собираемого это заняло определённое время, однако нынче всё работает автомагическим образом и еженощно выдаёт результаты анализа всего-всего, что собирается в продукте. Сама сборка, уже в силу специфики сборочной среды, при этом, осталась на GCC, анализ прикручен сбоку.
Разумеется, нашлось много интересного.
Читайте далее »
Полтора года прошло с момента обнаружения утечки рутового сертификата компании DigiNotar. В своё время история наделала немало шума, все посуетились, повыпускали заплаток, попрыгали и успокоились. С того времени были ещё схожие случаи, ну да и ладно, тоже что-то патчилось, обновлялось, блокировалось, всё чудесно.
А тут мне понадобилось посмотреть на патчи Debian для openssl и, глядь, вот он, block_diginotar.patch. Заглянул, чисто из интереса, посмотреть и слегка прибалдел. Патч просто-напросто блокирует все сертификаты в поле CN которых содержится подстрока «DigiNotar». Там, конечно, написано, на всякий случай, что «This is not meant as final patch.», но тем не менее, именно оно в стабильном Debian. И даже более того, пользуясь таким отличным примером, аналогичным образом был заблокирован малазийский Digicert.
Технически можно было просто удалить сертификаты из хранилища рутовых сертификатов поддерживаемого дистрибутивом. Можно было, если уж хочется понадёжнее, опереться на отпечаток (хэш) сертификата. Ну уж в самом крайнем случае полный сабжект сертификата, хотя тоже нехорошо. Но вместо этого имеем даже не заблокированные CN, а просто запрещённые слова в CN. На которые, в принципе, можно и случайно наткнуться, а потом долго гадать, почему получается вот так:
rik@sencha:~/CA$ openssl verify -CAfile cacert.pem cacert.pem cacert.pem: /O=The Sample Company/L=Metropolis/ST=New York/C=US/CN=No, it's not a DigiNotar error 23 at 0 depth lookup:certificate revoked
А оно так и получается, если воспользоваться простейшим мануалом по развёртыванию УЦ и правильно угадать с CN.
Что характерно, в той же openSUSE таких костылей нет и аналогичный сертификат живёт без проблем. Интересно, как оно в других дистрибутивах. Может, это у Debian карма такая, с кривым openssl жить?
Как оказалось, в «Дигикаме» баг на баге и багом погоняет. Даже удивительно что так кучно легли вокруг одного нехитрого параметра. Единственное логичное объяснение на данный момент у меня одно — настоящий ёпен сорс, он для правильных пацанов с полнокадровыми матрицами.
Единственная радость, что мой «Дигикам» уже таки корректирует всё правильно. Хотя, под конец он мне выдал ещё один финт, внезапно собравшись не с внешней библиотекой «Ленсфан», а с внутренней. Ну, в лучших традициях ёпен сорса, версия «Ленсфана» из openSUSE 12.2 собиралась ещё автохеллом и клала заголовок просто в /usr/include, а версия 0.2.6 собирается уже через cmake и кладёт заголовок (один) в /usr/include/lensfun, чтобы жить интереснее было.
Что, впрочем, заодно продемонстрировало во всей красе баг самого «ленсфана» в плане коррекции, на который я как бы и наткнулся по ходу мытарств с коррекцией, но как бы не совсем. После финта со сборкой «Дигикама» заход на эти грабли можно считать также полноценно выполненным, поскольку при уже корректном кроп-факторе я снова начал получать отличный от tmod результат. А выглядит этот баг так:
Читайте далее »
И ведь задача простая. Требуется структурировано хранить табличку. Всего-то на восемь столбцов. В неё надо регулярно писать. Периодически надо читать, причём, здесь нужна возможность параметризованной по столбцам выборки. Иногда надо обновлять одно поле. Иногда удалять записи. В общем-то, и всё. А поди ж ты, проблема!
Читайте далее »
MailScanner-4.74.16-1/lib/MailScanner/SweepViruses.pm:
# If you use Kaspersky, look at this code carefully
# and then be very grateful you didn't have to write it.
Написал я тут хороший (но очень секретный!) сервер со страшной многопоточностью и прицелом на большое число клиентов. И всё бы хорошо, да вот незадача — валится он странным образом при наваливании всё большего числа тех самых клиентов. Как оказалось, наткнулся я на достаточно известные (если знать что искать), но очень, очень качественные грабельки, так что грех не поделиться.
Читайте далее »