Поскольку об этой мелочи я постоянно забываю, я решил написать про неё в блог. Речь идет о Java-плагине для браузеров в Ubuntu/Mint. Этот плагин можно установить при помощи aptitude:

Однако, этого недостаточно, чтобы плагин был обнаружен и «воспринят» браузером. Для этого нужно создать символьные ссылки на библиотеку плагина для нужных браузеров. Причём, от дистрибутива к дистрибутиву путь, по которому размещён этот файл, изменяется. Поэтому, перед тем как раскидывать линки, лучше уточнить путь к файлу libnpjp2.so. В Linux Mint 11/Ubuntu Natty amd64 библиотека плагиина размещается по пути /usr/lib64/jvm/java-6-sun/jre/lib/amd64/. В Linux Mint 12/Ubuntu Oneiric этот путь уже эквивалентен /usr/lib/jvm/java-6-sun/jre/lib/. Eсли платформа не amd64, а x86, то путь тоже поменяется. Само собой, что нужно, чтобы браузеры и библиотека были скомпилированы под одну платформу. Для Opera директория с плагинами обычно размещается по пути /usr/lib/opera/plugins, для Firefox — /usr/lib/mozilla/plugins. Туда и нужно линковать. Выглядеть это будет примерно так:

Real deal от Google, по идее, «подхватывает» этот плагин автоматически. Отмечу, что я использовал для примера выше путь к libnpjp2.so для Mint 11/Ubuntu Natty.

После создания символьных ссылок следует перезапустить браузеры, чтобы они подключили плагин. У Opera, на месте, где должен загружаться апплет,  может появиться сообщение, что плагин не обнаружен. Чтобы заработало, нужно просто покликать по этой области. Chrome у меня пожаловался на то, что плагин устарел. Возможно, это было связано с тем, что уже есть седьмая версия Java.  В любом случае, единственную альтернативу запуску апплета, которую сейчас может предложить Chrome — установку Java из самораспаковывающегося архива либо из rpm-пакета — для deb-систем нет смысла использовать.

Сегодня обнаружил пренеприятную вещь. Если в WP, будучи авторизованным, производить какие-либо действия, через некоторое время сайт перестаёт отзываться и выпадает в осадок на непродолжительное время. После этого всё опять начинает работать, как ни в чём не бывало, до следующего такого же события. Я полез в логи в поисках источника проблемы. В /var/log/syslog я нашел исчерпывающую информацию:

Оказалось, что это полезняшка-Suhosin прибивает скрипт wp-admin/admin.php по причине того, что последний по непонятной причине начинает жрать очень уж много памяти. Гораздо больше, чем задано в настройках PHP. Начав копаться в движке, я обнаружил, что разработчики весьма щедро одарили свой движок памятью (wp-includes/default-constants.php:27):

Подобная запись присутствовала в WP и раньше. Тогда значение просто было жёстко прописано в те же 256Мб. В конфиге php у меня установлено максимальное значение в 128Мб. Именно по этой причине Suhosin и валил выполняющийся скрипт.

На данный момент я не очень представляю, чего же такого делает admin.php, что требует больше 128 мегабайт памяти. Особенно учитывая, что это происходит во время отправки комментария. Не смотря на то, что скрипту требуется память, я решил не раздвигать установленные в 128Мб рамки. Скорее наоборот, я решил придавить WordPress этими 128 мегабайтами. Как видно из кода выше, это совсем нетрудно сделать — достаточно определить константу WP_MAX_MEMORY_LIMIT в wp-config.php:

Тогда вышеупомянутый код в wp-includes/default-constants.php не будет выполняться. Конечно, это полурешение. Более того, я ожидаю, что, если скрипту понадобится больше 128Мб, он также будет убиваться, но уже интерпретатором PHP. Однако, я все же посмотрю, как оно будет работать.

У Amazon есть много вариантов использования их вычислительного облака. И это относится не только к широкой линейке тарифов. Можно сказать, что количество тарифов можно умножить на два, поскольку инстансы бывают двух типов — on-demand и reserved. Их отличие только в стоимости. Первый удобно заказывать, когда необходимо взять вычислительную мощность на время, меньшее чем 1 год. В других случаях действительно выгоднее брать reserved-тип либо комбинировать оба. В принципе, ничто не мешает гонят on-demand instance годами, но финансовые потери в такой ситуации будут существенны, да и глупо это. Например, я подсчитал, что примерная месячная стоимость on-demand t1.micro с параметрами как на Free Tier будет составлять около $15.76 (я рассчитывал так, что ресурсы будут израсходованы по максимуму):

• Собственно вычислительная мощь: 0.48 * 30 * 12 = 172.8
• 10 ГБ EBS: 0.1 * 10 * 12 = 12
• 1 млн. I/O-операций на EBS: 0.1 * 12 = 0.12
• 1 ГБ S3 storage для EBS: 0.14 * 12 = 1.68
• 14 ГБ исходящего трафика (потому, что первый ГБ трафика ежемесячно бесплатен): 0.12 * 14 * 12 = 20.16

В год это $206.76 — дешевле, чем самый дешевый тариф от Linode.com. У Linode, правда, свои прелести есть. Например, 200 ГБ трафика дают на самом дешевом тарифе. Тем не менее, по сравнению с тем же AWS, on-demand выглядит дороже, когда узнаешь цену на reserved instance. Она составляет $54/1 год и $82/3 года. В принципе, можно было бы даже не учитывать всё, что навешивается дополнительно, достаточно сравнить первую цифру из расчетов с этими двумя. Что выбрать — 1 on-demand или 3 reserved t1.micro на год и пачку пива на вечер? :)

Хорошо, цифры смотрятся красиво, так как купить зарезервированный инстанс?

Тут есть два варианта. Первый — воспользоваться EC2 API Tools. Второй — из консоли управления AWS. Первый вариант я не пробовал, но всё же доверяю написанному. Быть может, кто-то из вас его попробует и потом поделится в комментариях опытом с благодарным Олежкой и читателями его блога . Кстати, если вы вознамерились делать первый вариант, и у вас при этом есть Ubuntu, то пользоваться ссылкой, которую я дал в начале абзаца, необязательно. EC2 API Tools есть в стандартных репозиториях Ubuntu, и проще поставить их традиционным способом:

Второй вариант — из консоли управления AWS.

По цифрам на картинке — Закладка «EC2» -> В категории «Instances» кликнуть по «Reserved instances» -> Кликнуть по кнопке «Purchase Reserved instances»:

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

На снимке показаны те параметры, которые были нужны мне. Внимательно выбирайте нужные вам параметры. Тут зарыта маленькая, но немного воняющая собачка. Дело в том, что на самом деле вы покупаете не инстанс. Вы покупаете гарантию того, что какой-то из ваших инстансов (а может и все) будет работать непрерывно всё то время, которое вы оплатили. Проще говоря, после нажатия кнопки Continue вы не получите интерфейс для выбора AMI и прочей требухи для инстанса. После получения от вас подтверждения в ваших намерениях вам просто скажут «Всё окей, чувак, мы списали денежки с твой карточки, жди результата».

Результатом будет появление ваших инстансов в категории Reserved instances, которая ранее пустовала. Если у вас такого инстанса нет (еще раз, внимательно смотрите на параметры резервируемых инстансов), вам необходимо его создать. В моей ситуации я уже имел работающий инстанс и во время резервирования указал именно его параметры. Инстанс появляется в категории Reserved не сразу, а в течение примерно 1 часа.

Вообще метод предоставления услуги весьма интересный. Вот, например, случай, в котором он сработает на клиента: допустим, у вас есть t1.micro в us-east-1a c Linux на борту и он зарезервирован. Вам понадобилось полностью обновить ПО, вместе с операционной системой. Разумеется, для этого нужно погасить старый инстанс, создать новый (с теми же параметрами, что и у старого, т.е. Linux-инстанс t1.micro в зоне us-east-1a) с нужной ОС и накатить на него софт. Так и делаете. В результате у вас два инстанса. Удаляете старый, и по прошествии определенного времени уже новый становится зарезервированным. Таким образом, вы не теряете уплаченные деньги, вам не нужно кантовать саппорт с просьбами переключить что-то на что-то, чтобы вернуть деньги или направить их в нужное «русло». Вы как будто поменяли плашку оперативной памяти в своем компьютере. Подробнее про то, как оно работает, можно почитать в этой ветке форума об AWS.

Однако, есть у меня один вопрос. Скажем, есть два одинаковых инстанса, находящихся в одной зоне. И вы покупаете резерв только для одного. Получается, что один резервируется, и один остается on-demand. Поскольку процесс резервирования происходит в режиме, который не контролируется пользователем, неизвестно, какой именно из этих двух инстансов будет зарезервирован. Это не имеет значения, даже смысла, когда два инстанса идентичны вплоть до выполняемых ими задач. Однако же, это имеет значение в противном случае.

UPD: Каюсь, был невнимателен, когда читал их документацию. Дело в том, что, покупая у Amazon reserved-инстансы, вы покупаете серьёзную скидку за час работы инстанса. Т.е., после покупки reserved-инстанса, вам всё равно будут начислять денежки за пользование, но, конечно же, в итоге получится дешевле, чем on-demand. Так что, к стоимости вычислительной мощи reserved-инстанса нужно прибавить ежемесячное пользование. Для t1.micro это (на данный момент — декабрь 2011 года) 0.007 * 24 * 30 (тут, понятное дело, я взял усредненно количество дней). Даже при таком раскладе получается дешевле, чем, наверное, везде.

Вы, наверное, думали, что под заголовком много всякой писанины про геморрой с установкой и настройкой? Нет, всё гораздо проще — php-fpm просто нет в репозиториях по умолчанию для Debian Squeeze. Это который 6. Забавно, я отлично помню кодовые имена для Debian и совершенно не помню, к каким версиям они относятся. Для Ubuntu же всё наоборот . Чтобы установить это расширение, нужно добавить сторонний репозиторий. Например, этот: http://packages.dotdeb.org. Добавляем репозиторий и причиндалы:

Не забыть обновить список:

Теперь можно ставить:

Вот и всё.

Даже не предполагал, что в Linux Mint столкнусь с такой проблемой. Команда разработчиков этого дистрибутива вылизывает настройки интерфейса в Ubuntu до такой степени, что, вне зависимости от того, какая gui-библиотека была использована при написании программы, эта программа выглядит практически также, как и GTK-приложения. В результате, графический интерфейс Linux Mint выглядит взрослее, чем интерфейс его родителя. Однако же, я всё-таки напоролся на проблему со шрифтами. Вот как она выглядела:

Как видно на снимке, кириллические символы отображаются каким-то шрифтом с засечками с невероятным расстоянием между символами, в то время, как с латинскими символами всё в порядке — они отрисовываются тем шрифтом, который задан в настройках. Проблема возникла после того, как я поставил дополнительные ttf-шрифты из стандартного репозитория. Я не спроста упоминал GTK в начале заметки, т.к. эта ситуация наблюдается в QT-приложениях, например qtconfig-qt4 (на снимке вверху), Gwenview и Skype. Приложения же, использующие GTK для отрисовки интерфейса, отображаются при этом нормально. Собственно настройки шрифтов для QT регулируются в qtconfig. Однако, это не касается случаев, когда на закладке «Внешний вид» выбрана тема GTK+, либо пользовательсткие настройки, как это было у меня. Поскольку это Linux Mint, очевидно, что под «Пользовательскими настройками» имеется в виду та же тема GTK+, только, может быть, «подкрученная». Короче, в такой ситуации QT использует настройки шрифтов из настроек GTK. Однако в них я ничего не менял, шрифт там оставался стандартный — Sans — который, разумеется не имеет засечек  .

Скорее всего, QT в каких-то своих умолчальных настройках, которые недоступны либо труднодоступны пользователю, имеет умолчальное же семейство шрифтов. Это семейство шрифтов и используется при отрисовке gui. В моем, а возможно и во всех случаях, это оказалось семейство sans-serif — без засечек. Я предполагаю, что после установки дополнительных шрифтов, QT каким-то непонятным образом не нашла шрифт Sans (а может никогда раньше и не находила) и использовала первый попавшийся sans-serif шрифт. Который, в свою очередь, оказался без поддержки кириллицы; что привело к откату QT на первый попавшийся шрифт с поддержкой кириллицы. Смахивает, кстати, на Georgia. Но установить, что это за шрифт, конечно, трудно. Как и то, какой шрифт без засечек использовался для латинских символов. Потому что много шрифтов, которые называются по разному, но отличаются один от другого в незначительных деталях.

В общем, я подыскал подходящий шрифт без засечек, который поддерживает кириллицу, и qt нормально его находит. Выставил его в настройках GTK и перезапустил qt-приложение.

Заработало нормально :)

Тем не менее, этот обходной путь не решил проблему, а лишь скрыл её. Если кто-нибудь знает, как заставить QT отрисовывать нормально gui с тем шрифтом, который задан в GTK, отпишитесь, пожалуйста  .

Сегодня понадобилось развернуть сайт, построенный на MODx Evolution, на сервере под управлением Nginx. Ниже — конфиг для этого движка. Строки в угловых скобках < и > нужно заменить на свои значения.

Напоследок замечу, что данная конфигурация работает на Debian-системах, для Nginx версии 0.8.54 и MODx ветки Evolution версии 1.0.5. Стоит иметь в виду, что со временем что-то может измениться.

Сегодня, 30 октября, должен был быть осуществлен переход на зимнее время. Это по старому. В соответствии с тем, что в начале года в нашей стране был отменен переход на зимнее время, этот перевод отменяется. Однако же, сегодня я на собственном телефоне убедился, что Android об этой russian-фиче пока не знает. В результате я сейчас наблюдаю часовую разницу между показателями телефона и своего компьютера.

Mint 11, кстати, знает об изменениях. Windows 7 — тоже. Отчетливо помню, как Windows Update предложил мне поставить апдейт настроек.

На данный момент я вручную выставил время, так как вариант с синхронизацией пока не хочет настраивать время в соответствии с новой действительностью.

Я обнаружил, что музыка в моей инсталляции Linux Mint (читай Ubuntu. Один хрен) воспроизводится с задержками между треками. Такую штуку можно легко заметить, если слушаешь какой-нибудь длиннючий микс, порезанный на треки. Воспроизводиться он должен непрерывно, иначе впечатление от музыки будет обнуляться с очередным треком . На карточках с нормальными чипами эти вещи работают «из коробки», на некоторых встроенных приходится поковыряться. Вот и мой ноутбук, разумеется, не стал исключением.

Тема, на самом деле, достаточно избита, но я всё же оставлю заметку, на память, так сказать :)

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

нужно дописать следующую строчку:

Если же это не помогает, то можно поискать опции тут:

Или сразу грепнуть этот файл по модели чипа. Модель чипа можно узнать так:

Та-дам:

Или так:

Та-дам:

После сохранения alsa-base.conf нужно перезапустить alsa

Нужный функционал после этого должен появиться.

Аналогичным способом я ранее настраивал микрофон на более старой модели ноутбука от Acer. Интересно, что на ноутбуке, фигурирующем в этой статье (Acer Aspire 5551g) микрофон у меня заработал сразу после установки системы, и ничего подобного прописывать не понадобилось. Более того, в alsa-base.conf параметров из старой статьи замечено не было. Прогресс, однако  .

Ранее я рассказывал про то, как занимался запоздалой войной с пылью и какие боевые потери понесла моя «армия» . Так вот, в один из моментов чистки своего старенького компьютера я случайно уронил его. Высота была небольшая, сантиметров двадцать от пола, но этого хватило, чтобы останавливающиеся блины жёсткого диска получили свое сотрясение. Видимо по ним зацепило головками чтения-записи, потому что уже после чистки я заметил, что загрузка Grub (да, ещё до этапа загрузки операционки) стала производиться медленнее секунд на пять. Через три дня стали появляться глюки, которые характерны для сыпающегося винчестера — операционка внезапно вставала намертво при открытии какого-либо файла. Через неделю глюки стали проявляться с надоедающей частотой, и я понял, что винчестеру пришел ОН. Ну что ж, железку я поменял, самые важные данные у меня сохранены, а те, что нет — через сотню reset-ов всё-таки были скопированы с умирающего устройства.

Ну да не суть. Важна вот какая ситуация. Я периодически покупаю музыку на очень популярном магазине музыки junodownload.com. И мне, конечно же, не улыбалось тратить деньги снова на уже купленную музыку после аварии с жёстким диском — согласитесь, это глупо и неоправданно дорого. Поэтому я решил попросить у ребят из Juno помощи в этом вопросе. Нашел контактную форму на их сайте и отправил сообщение с вопросом:

Hello,

My hard disk died so I'd like to ask you if there is any way to re-download previously bought items.

Thanks,

Oleg.

Ну а по-русски — я объяснил, что мой жесткий диск сказал мне «прости-прощай», и что я хотел бы узнать, возможно ли закачать по новой музыку, купленную ранее.

Спустя некоторое время я получил ответ:

Моей радости не было предела! Они снова включили мои загрузки, и теперь я мог закачать купленную мной музыку! Кому-то может быть, покажется, что это мелочь, но так чертовски приятно, что к тебе относятся с уважением и доверием!

Again, thanks a lot for your service!

Сегодня утром в Google Plus, на закладке Buzz, увидел сообщение о том, что Google скоро закрывает этот проект.

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

В общем-то, всё и так понятно — компания, видимо, руководствуется и таким принципом — «зачем плодить клонов?». Google Buzz, помимо того, что микроблоговоая платформа, по хорошему — просто кусок социальной сети. Её компонент, который называется «Стена». Ну или «Лента», если по гугловски. Логично, что он будет убран. Тем не менее, сообщения, отправленные в Buzz, можно будет просмотреть двумя способами — в профиле Google и через архиватор Google. Ну, вроде удобно всё. Осталось только дождаться даты убиения Buzz, чтобы узнать, какой именно профиль имеется в виду — профиль Google, который есть у пользователя, не пожелавшего создать аккаунт в Plus, или профиль в Google Plus ? А может, и там, и там?