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

Разница в хвате почему-то заметна до сих пор, вроде бы и время, и тренировки, а всё равно ощутимо.

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

Зато успел вывести на лёд сына в первый раз, тут главное не сомневаться, фигня что сам не умеешь кататься, уверенно надо выводить на лёд и пытаться проехать вместе. Кто за кого при этом держится — вопрос открытый, главное, что в конечном счёте никто не падает.

Думаю, с моим обширным опытом, пора уже покупать свои коньки. Тем более, март через неделю.

И проблемы-то известные, особенно, с KMail, но ни черта не делается, чтобы их решить. Это печально.

На этом фоне, слетание наглухо всех настроек KMail уже мелочь.

Что в новой openSUSE порадовало, так это скорость Konqueror. По умолчанию теперь используется движок WebKit и он таки быстр. Уже отвык от такой отзывчивости.

Но наверное было бы неправильно, если бы всё стало только лучше. Надо соблюдать баланс хорошего и не очень. Поэтому быстрый Konqueror теперь чаще падает. У меня уже набор страниц есть, заход на которые стабильно валит браузер. Похоже, что как-то связано с видео, но как, непонятно, флэша у меня нет, только gnash, но, видимо, надо и его попробовать зарезать.

P.S. А ведь так и есть, удаление gnash-а браузер лечит.

ДАЙ АЙТЮНС!

То что сам айтюнс не живёт под линуксом это само собой разумеющееся явление и оно не удивляет ни чуть. Но как можно не стесняясь продавать нерабочие кирпичи, говоря о том, что именно эти кирпичи зверски удобны, продуманны и круты, мне непонятно вообще. Очевидно ведь, достал из коробки — не работает. Не работает — говно.

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

Айпад в коробке

Торчащий айпад

Внутренности коробчки iPad

Евровилочка

Фактически, буква “б” получена тупым наращиванием хвоста на “о”. Из-за этого смотрится она ужасно, особенно без засечек.

Что ещё интереснее, не у одного CM такая проблема с русификацией, слева направо, DejaVu Sans, FreeSans, Nimbus Sans:

Даже можно задуматься, может так оно и надо, хоть и выглядит паршиво? Ан-нет, смотрим Droid Sans, Lucida Sans, Ubuntu:

Совсем ведь другое дело.

Впрочем, не одной буквой “б” жив шрифт, присмотревшись повнимательнее можно найти ещё много интересного, например, зверские клыки буквы “д” в том же CM. Того, из чего и складывается эффект, когда набранный английский текст смотрится ровненько и приятно, а русский абы как.

Вот и подбери после этого адекватный шрифт к какой-нибудь брошюрке или документу.

Approximately в мане очень порадовало.

Там же есть и ссылка на StackOverflow, где хитрые европейцы придумали как прикрутить костыль, чтобы получить в листингах умляуты. Всё бы неплохо, но нам в листингах нужны не умляуты, а кириллица.

В принципе, из костыля для умляутов вполне ясно направление возможного решения проблемы. Однако ж, насколько мне известно, каких-то нормальных сокращений для кириллицы нет (так чтобы написал «\Zh» и получил «Ж»), то есть, есть cyracc, но заставить его работать в LaTeX у меня не получилось. Зато обнаружился другой, ещё более злостный подход — прямая выборка символов из шрифта. После получасовой медитации у меня получился следующий рецепт:

\lstset{
literate={а}{{\selectfont\char224}}1
{б}{{\selectfont\char225}}1
{в}{{\selectfont\char226}}1
{г}{{\selectfont\char227}}1
{д}{{\selectfont\char228}}1
{е}{{\selectfont\char229}}1
{ё}{{\"e}}1
{ж}{{\selectfont\char230}}1
{з}{{\selectfont\char231}}1
{и}{{\selectfont\char232}}1
{й}{{\selectfont\char233}}1
{к}{{\selectfont\char234}}1
{л}{{\selectfont\char235}}1
{м}{{\selectfont\char236}}1
{н}{{\selectfont\char237}}1
{о}{{\selectfont\char238}}1
{п}{{\selectfont\char239}}1
{р}{{\selectfont\char240}}1
{с}{{\selectfont\char241}}1
{т}{{\selectfont\char242}}1
{у}{{\selectfont\char243}}1
{ф}{{\selectfont\char244}}1
{х}{{\selectfont\char245}}1
{ц}{{\selectfont\char246}}1
{ч}{{\selectfont\char247}}1
{ш}{{\selectfont\char248}}1
{щ}{{\selectfont\char249}}1
{ъ}{{\selectfont\char250}}1
{ы}{{\selectfont\char251}}1
{ь}{{\selectfont\char252}}1
{э}{{\selectfont\char253}}1
{ю}{{\selectfont\char254}}1
{я}{{\selectfont\char255}}1
{А}{{\selectfont\char192}}1
{Б}{{\selectfont\char193}}1
{В}{{\selectfont\char194}}1
{Г}{{\selectfont\char195}}1
{Д}{{\selectfont\char196}}1
{Е}{{\selectfont\char197}}1
{Ё}{{\"E}}1
{Ж}{{\selectfont\char198}}1
{З}{{\selectfont\char199}}1
{И}{{\selectfont\char200}}1
{Й}{{\selectfont\char201}}1
{К}{{\selectfont\char202}}1
{Л}{{\selectfont\char203}}1
{М}{{\selectfont\char204}}1
{Н}{{\selectfont\char205}}1
{О}{{\selectfont\char206}}1
{П}{{\selectfont\char207}}1
{Р}{{\selectfont\char208}}1
{С}{{\selectfont\char209}}1
{Т}{{\selectfont\char210}}1
{У}{{\selectfont\char211}}1
{Ф}{{\selectfont\char212}}1
{Х}{{\selectfont\char213}}1
{Ц}{{\selectfont\char214}}1
{Ч}{{\selectfont\char215}}1
{Ш}{{\selectfont\char216}}1
{Щ}{{\selectfont\char217}}1
{Ъ}{{\selectfont\char218}}1
{Ы}{{\selectfont\char219}}1
{Ь}{{\selectfont\char220}}1
{Э}{{\selectfont\char221}}1
{Ю}{{\selectfont\char222}}1
{Я}{{\selectfont\char223}}1
}

Это — злостный мега-костыль. Но он работает и реально позволяет иметь кириллицу в листингах. Единственный важный момент, используемое окружение:

\usepackage[utf8]{inputenc}
\usepackage[english,russian]{babel}
\usepackage[T2A]{fontenc}

С другими вариациями наверняка работать не будет.

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

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

С другой стороны, как только у чтеца появляется возможность залочить базу под себя, он её радостно берёт и… жуёт в течение этак полуминуты. Ладно ещё что это так много времени занимает, понятно, что индексов нет (иначе очень сильно деградирует запись), что в памяти базы нет и приходится её жевать полностью в прямом эфире. Но ведь, при этом невозможна никакая запись, а это уже не просто неприятно, тут можно дожить до переполнения буферов писателя и какие-то записи просто потерять!

Ближайшее простое решение видится исключительно в русле наращивания мускулов движка SQL, переход, например, на Drizzle или Firebird. Всё бы ничего, но разница в требуемых ресурсах измеряется кратно, этак на порядок, а ведь всё это хозяйство должно радостно работать не только на мощных машинках, но и на каких-нибудь чудесах об 500 МГц и 256 Мб памяти.

Конечно, пробовал найти какие-то альтернативы для подобного рода структурированного хранения, но не получилось. BerkeleyDB оперирует key->value, а больше ничего серьёзного для такого рода вещи не видно в принципе. Конечно, есть подозрение, что на уровне базы в виде файла, который открывается разными процессами с разными целями, проблема не решаема, поскольку если у читателя не будет возможности работать со своей стабильной копией, писатель обязательно найдёт способ ему нагадить.

С другой стороны, если взять какой-нибудь простецкий формат записи типа CSV, то, пожалуй, проблема читателей-писателей будет отсутствовать, но, появится проблема с адекватной по скорости выборкой, плюс с обновлением и, особенно, удалением записей.

Неужели придётся городить свой огород?

Но, заодно, почитал ГОСТы 1938-90 и 1940-90. Интересно.

Что, в общем, к лучшему, конечно.