О дефиците

Выдержка из прайса одного крупного магазина

Понять бы еще, куда шкурку сдать хотя бы за 1000 - и была бы золотая жила.

P.S. Туда ставят Barracuda LP, как я понял.

P.P.S. Если кто метнется - вы мне должны авторских отчислений. Бутылку пива или (лучше) пакет сока :)

P.P.P.S Хотел еще красивее нарисовать, но дисков на 2Tb в данном магазине в продаже нет, кончились. Кончались они по 6600.

HDD/SSD price

В какой-то из презентаций этой осени, либо броузя веб, либо на Highload, я услышал/увидел следующую мысль:

Если вам не хватает производительности базы данных: замените HDD на SSD и все проекты по переходу на NoSQL можно будет надолго отложить.

И я с этой мыслью согласен.

Что делают (делали), когда не хватает IOPS-ов? Берут много дисков побыстрее. А какие диски побыстрее по IOPS-ам? 2.5" 15k RPM (т.е. Seagate Savvio 15k): они маленькие, голове нужно дрыгаться мало, поэтому seek time сильно меньше чем у 3.5", IOPS-ов там чуть не вдвое больше чем у 3.5".

А теперь смотрим картинку:

Ненависти к Drupal7 псто!

Поигрался с тестовым сайтом, поапгрейженным из Drupal6 в Drupal7, испытал мучительное недоумение.

Снес нахрен, поставил D7 с нуля, недоумение не стало менее мучительным.

У меня, по большому счету, требований очень мало:

  • Мне нужно писать тексты, причем я готов их прямо в HTML фигачить. От визивигов яваскриптовых - тошнит, если честно.
  • Мне нужно управлять текстом аннотации, которая на глагне показывается. И средств D6 мне более чем хватает (а там можно, если не доверяешь автомату, разделить текст на аннотацию и хвост, аннотации поставить галку "входит в полный текст"), т.е. я могу сколько хочу абзацев сделать аннотацией, а могу ее отдельно написать).
  • Мне нужно просто вставлять картинки:
    • простой браузер того, что уже залито на сервер.
    • простая кнопка, позволяющая поаплоадить (и задать alt/title, чем я не пользуюсь, впрочем)
    • вставка с указанием размера (оригинал, какие-то стандартные, возможность задать свои), выравнивания и действия при клике на картинку (ничего, открыть полный размер в новом/том же окне, перейти по ссылке).
  • Ну теги-категории, понятно и прочие мелкие галки (кросспост в ЖЖ, режим комментариев, задание URL)
  • Все, больше ничего не надо. Если захочу клип с Youtube - руками вставлю, надо редко.

Всю эту функциональность умеет Drupal6 из коробки + image/image assist + чуть-чуть других модулей.

А вот D7 привычную картину D6 нарушает в куче мест:

Услуги телепортации ?

Граждане читатели!

Посоветуйте транспортный сервис: нужно будет переслать лыжи (ски-тур т.е. по сути - горные) из Москвы в Барнаул.

Почта/EMS не подходит, там ограничение по длине 150см. У DHL/UPS предельные размеры на сайте быстро не нашел, но в лыжах тоже сомневаюсь. Про желдорэкспедицию знаю, но не очень хочу связываться, если только в крайнем случае, там процедура выглядит всякий раз так, как будто мне делают одолжение (очередь на прием к начальнику, он посмотрит возможность и подпишет накладную...), "передавать с проводником" тоже не очень хочу.

А вот всякие "отправщики сборных грузов", коих сейчас много - интересны, особенно интересно мнение тех, кто лично пользовался как частное лицо (гемороиться с заключением полноценного договора с юрлицом ради разовой отправки - не хочется).

Update: по комплексу формальных свойств (цена, пункты приема-выдачи) и положительных отзывов от читателей, для моего случая победил Грузовозофф, буду пробовать им. Если вдруг что не срастется - читатели блога будут извещены.

Drupal6 -> Drupal7

В очередной раз подошел к снаряду по имени Drupal7. Имею сказать:

1. Если у вас PostgreSQL, то даже Drupal 7.9 (текущий) не сможет поапгрейдиться гладко. Оно пытается сконвертировать поля типа text в тип bytea, а в PostgreSQL 9.1 (другие не пробовал) автоматического преобразования этих типов нет.

Лечение (применяется к базе PostgreSQL до апгрейда):

CREATE OR REPLACE FUNCTION text2bytea(text) RETURNS bytea AS
$BODY$
begin
 return convert_to($1,'UTF-8');
end;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
CREATE CAST (text as bytea) with function text2bytea(text) as implicit;
Может я тут что и перепутал и as implicit не нужно, но работает и "базовый" сайт (core modules) переносит.

2. А вот в том, что касается contributed modules - счастья у меня нет:

Душераздирающее зрелище

Не могу молчать, хочу писать.

Случившийся давеча бунт гаджетов (и сервисов) наводит на меня тоску:

  1. Сюрпризом для меня оказалось количество мест, дублирующих TZ database: операционная система (про которую было известно заранее), PHP, PostgreSQL (в ветке 8.x база TZ старая), Java - это только то, про что я сам знаю. А реально мест - существенно больше.
  2. Таким же сюрпризом оказалось то, что сервисы надо перестартовывать, просто апдейта TZdb и /etc/localtime - недостаточно.
  3. Владельцам продвинутых гаджетов веселухи добавила продвинутая автоматика, вроде установки времени "от GSM-сети" (а сети все проэтосамое, а может просто побоялись свитчи обновлять ради такой мелочи) или, еще веселее, установки таймзоны по GPS-координатам, как это во многих навигаторах сделано (проверил, в моем Garmin 62s просто нельзя поставить offset в часах, только по имени города).
  4. На этом фоне сообщение РЖД о том, что в ж/д сообщении с Украиной будет бардак до 3 декабря, а дальше будет видно - уже не вызывает удивления, хоть и вызвано это не IT-бардаком, а законодательными инициативами у братского народа: сначала отменой перехода на зимнее время (в сентябре, по мне так безумно поздно), а затем отменой отмены (в октябре, еще веселее).

Про перевод часов, таймзону, PHP и Drupal

Вдруг кому поможет, поэтому тут (у меня теплится слабая надежда, что в ближайшие годы новых экспериментов с летним временем не будет, поэтому самому такие записки вроде не нужны).

PHP:

  1. У PHP база данных таймзон вшита в пузо и, конечно, не обновляется регулярно.
  2. Но есть pecl-timezonedb, который ее оверрайдит, со свежей базой (последняя имеет номер версии 2011.13), с этим расширением с таймзонами все станет отлично и любимая всеми Europe/Moscow будет работать как полагается по новым правилам.
  3. Но если вы живете под FreeBSD, то там /usr/ports/misc/pecl-timezonedb не обновлялся очень давно, посему:
    • Меняем там в Makefile 2010.9 на 2011.13
    • удаляем distinfo
    • make && make install
  4. Добавляем timezonedb.so в список extensions.ini (на FreeBSD это сделает make install)
  5. Перестартовываем PHP-fastcgi или Apache или что у вас там работает процесс-сервером для PHP
  6. Ура, можно накатить первый стакан.

Drupal 6:

  1. Сам по себе сразу начинает жить правильно (ну, насколько мне показалось). Т.е. таймзона меняется после апдейта PHP-timezonedb с +0300 на +0400 сама.
  2. Но! В Administer-Date-and-time есть настройка про User Configurable time-zone. Если она включена, то пользователю будут показываться даты-времена в его таймзоне. И весь созданный им контент будет иметь время создания рассчитанное из юзерской таймзоны.
  3. Но. Юзерская таймзона специфицирована в секундах смещения от UTC.
  4. Выходов два: или для всех российских пользователей взять и поправить скриптом (по хорошему, с учетом даты регистрации), или просто отменить настройку пользовательских таймзон. Я пошел по второму пути.

"я не знаю, был ли я все еще воскресным или уже понедельничным"

Update: первое место на конкурсе известно кого занимает PHP, где таблица таймзон - вшитая, а не системная. Всех бы убил, да. pecl-timezonedb спасает.

Приз зрительских симпатий за перевод часов получает Яндекс-почта.

Рассказываю:

  • На часах 11:26 (правильного времени), вхожу в Я-почту, вижу там внизу "последний вход в 10:54"
  • Действительно, в 10:54 я туда заходил, написать сам себе письмо и посмотреть на даты в заголовках (и все было прилично).
  • Выхожу (на часах 11:26), вхожу, выхожу, вхожу.
  • Надпись внизу остается все та же, про 10:54.
  • Повторяю еще и еще раз, наконец в 11:55 добиваюсь, надпись меняется на 11:26 (время начала экспериментов). Хотя с 11:26 я входил и выходил раз 10 минимум (а в промежутке 10:54-11:26 - нет).
  • Подозреваю, что в следующий раз "время последнего входа" сменится в 12:26 MSK, через полчасика проверю. Yes! Теперь оно залипло на 11:56

О время-время, темпо-темпо

Ну что, сколько у кого серверов перевело время сегодня с утра?

О линейности RAW и ETTR

Рядовой Иванов, о чем вы думаете, глядя на эту кучу кирпича?

На картинке - кривая, которая применяется к RAW-данным камеры Sony NEX-C3 при их распаковке. NEX-C3 просто первая попалась под руку, в компрессированных RAW A77 или A900 совершенно такая же по смыслу кривая, немножно отличается в деталях.

После наложения этой кривой, RAW-данные становятся линейными. Соответственно, при упаковке используется обратная кривая, линейная в тенях и полутонах и загибающаяся в светах (последних 3 стопах диапазона). По сути, три верхних стопа диапазона сжали в 1 стоп сигнала.

Где именно происходит процесс сжатия светов из формы кривой (и процедуры распаковки) выяснить нельзя, это может быть и цифровой процесс над линейными данными обычного АЦП и сжатие в нелинейном АЦП или нелинейном предусилителе.

Собственно, ничего плохого в такой компрессии светов нет. От того, что в верхнем стопе будет не 2048 градаций (предполагая 12-битный АЦП), а "всего" около 600 - становится только хорошо, потому что поэкономленные 1400 градаций переезжают на второй и третий стопы сверху (полутона и следующий стоп за ними).

О китайском литии

Докладываю: тестирование хлопушек тестирование китайского лития прошло успешно, насколько это возможно в условиях эксперимента:

  • Методика: разряд током 500mA в Maha-C9000, девайс считает миллиампер-часы, разряд прекращается, когда запрошенный ток отдать уже не получается.
  • Протестировано 8 батарей, все они безусловно хорошие:
    • У всех емкость больше 2900 mA*h
    • у 6 из 8 - больше 3000 mA*h
    • у 3 из 8 - больше 3100mA*h
    Energizer заявляет емкость чуть ниже 3000 при разряде током 250mA, у меня ток вдвое выше, другими словами емкость соответствует ожиданию.
  • Какой-либо зависимости емкости от веса батарейки (а он в диапазоне от 14.39 до 14.82, разница заметная) или от напряжения неразряженной (1.797-1.831) не обнаружено. Тестировались и самые легкие и самые тяжелые и так далее.
  • Напряжение в процессе разряда держится в районе 1.35-1.2 В (о чем ниже).
Короче, конкретная партия у конкретного продавца хорошая, буду у него брать еще. Собственно, продавца я выбирал исходя из цены и отсутствия отрицательных отзывов на качество продукта (а не на долгую доставку и т.п.).

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

Об академической науке

Читаю на Роеме эпический тред про РОМИП и хочу рассказать следующую историю уже про обработку фото и академическую науку.

Существует огромное количество алгоритмов демозаики. Вот несколько устаревший список. Сайт куда-то подевался, поэтому из архива, но с 2009-го появилось еще немало публикаций, поверьте (или почитайте IEEE Image Processing и подобную литературу).

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

Так я о чем, собственно? А, вот: если алгоритм получился не совсем позорным, то в разделе "сравнение", ближе к хвосту статьи, как правило публикуют сравнение: вот маяк, обработанный нашим алгоритмом, а вот маяк, обработанный стандартным AHD, LMMSE, VCD, наш найкращий!. Так парадокс в том, что "стандартный AHD" в каждой статье - свой, особенный. И "стандартный маяк обработанный стандартным алгоритмом" - соответственно, заметно отличается от статьи к статье.

При этом производители коммерческих конверторов, которые за деньги их продают, на эту тему и вовсе не парятся и используют кто AHD, а кто и вовсе bilinear interpolation для скорости. И, собственно, я согласен: типичным на сегодня 16-18Mpix демозаика нафиг не нужна при печати до A4 (а может и крупнее), не говоря о показе на 2-мегапиксельном мониторе.

Pages

Subscribe to blog.lexa.ru: все статьи