Не понимаю ценообразования

Все-таки это выше моего понимания. Берем какую-нибудь ходовую электронику, ну там карточка SDHC на 16 гигов. Для одинаковых items получаем вполне разумную разницу в 20-30% между US и Россией. Вполне можно идти в московский магазин и покупать (точнее, вызывать магазин на дом).

А вот берем кэноновскую батарею LP-E4. Минимум, который обнаружился в Москве - $230. А в одном из eBay stores - $120. Да, едет 4 недели (на себе проверил), да доставка стоит дополнительных денег, в результате при покупке двух штук получилось $150 за каждую.

Правильно ли я понимаю механизм:

  • Сначала европейский Canon (я посмотрел, европейская розничная цена тоже 120, но уже евров. Английская все-таки не 120, а 85 /без VAT/).
  • Потом таможня или даже нет никакой таможни (цифровые аппараты не облагаются, батареи к ним - возможно тоже).
  • Ну и розница возьмет себе свои законные 20-30%
Но почему нет такого же эффекта с теми же фотокамерами ? Тот же 1D mk III стоит всего на 17% дороже, чем на B&H, разница даже меньше чем у флэшек.

SSD диски и вообще flash

Пишут, дескать 10-20 процентов от ноутбуков, проданных с SSD-дисками возвращаются 'because of technical failure' (для ноутов с обычными дисками 1-2%).

Удивительно это слышать, конечно, ибо по стораджу для цифровых камер мои ощущения строго обратные - штука если не абсолютно надежная, то очень надежная (плюс-минус износ контактов и физическое разрушение, конечно). Но задумался, благо обе мои фотокамеры умеют писать бэкапы, а SDHC стоят примерно столько же, сколько CF.

Странный путь хорошего гаджета

В октябре по хардверным новостям пробежала новость: наконец сделали нормальный HDD Rack для SATA-дисков:

Отписались Akhibara news, Engadget и много кто еще, включая IXBT. Самое удивительное во всей этой писанине было то, что производитель не назывался.

Заметим, игрушка отличная и я ее сразу возжелал. Оно же позволяет решить проблему removable storage: 750-гигабайтная дискетка стоит сегодня $150, что в три раза дешевле (за гигабайт) и в 30 раз емче однослойного Blue-Ray (или в 4 раза дешевле и 15 раз емче двуслойного) и даже по USB-интерфейсу будет в разы быстрее. Я подозреваю, что за пару лет, за которые BR подешевеет до разумных величин, цена единицы хранения на HDD снизится еще в разы.

Леопард и мышь

На Mac Mini временами отваливается мышь. Bluetooth - просто перестает ездить и нажиматься. USB - курсор двигается, реакции на кнопки нет.
Экспериментально выяснено, что если сделать logout, а потом login, то все возвращается в норму.
Mac Mini на C2D, мыши Logitech (MX-518 и ноутбучная BT), Леопард 10.5.2

Изучение форумов показало, что мы не уникумы и даже не феномены. Бывает.

Кто виноват и что делать ?

Нечистая сила! FreeBSD 7 тоже больно бьется

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

Очень больно ударился об 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
Пошел пересаживаться на 7.0 32 бита.

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

Открытка Синодову

На roem.ru всю прошлую неделю была ругань между Ашмановым и Браверманом.
Потом ее взяли и удалили.

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

Неаккуратненько как-то.

FreeBSD: UTF-8 russian collate (вторая попытка)

Несколько дней назад я опубликовал исходник LC_COLLATE для кодировки ru_RU.UTF-8 для использования в FreeBSD. Там же я обещал, что если понадобится не "универсальная" сортировка, а такая же, как в FreeBSD, то сделаю и ее, а обещания нужно выполнять.

Помимо этого, старый вариант не имел вообще никаких шансов попасть в FreeBSD (причины этого мне объяснил Андрей Чернов: нарушается FreeBSD-шное правило, что большие буквы отдельно, а маленькие - отдельно), а новый - такие шансы еще не потерял.

go.mail.ru ≠ yandex.ru ?

Принято считать, что поисковая выдача на Mail.ru и поисковая выдача Яндекса - это одно и то же (с точностью до региональных настроек, которые разные). И последние года два это было так с какой-то точностью.
При этом трафик с go.mail.ru и с Яндекса был сильно скоррелирован. Аудитория, конечно, заметно отличается, поэтому по конкретным запросам отношение частот переходов не вполне соответствовали общерунетовскому среднему 1:6 (или около того, отношение довольно быстро меняется в сторону mail.ru), но выдача, насколько я ее смотрел, была одинаковой.

В последнюю неделю ситуация кардинально изменилась, на картинке среднесуточный трафик на блог:

blog-weekavg.png
Mail.ru стало давать в разы больше трафика, чем Яндекс, причем всего по нескольким запросам. Удивительнее всего то, что в мейловой выдаче отсутствует очевидный лидер по этому запросу (и это не мой блог :).

При проверке по другим запросам - выдача одинаковая по средне- и низкочастотникам, но по некоторым высокочастотникам - отличается. Mail редактирует поисковые результаты по избранным запросам?

FreeBSD: ru_RU.UTF-8 LC_COLLATE

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

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

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

Граждане, не забывайте про -Wall

Как-то я даже удивился, ударившись примерно об такое вот:

// external.c:
float func() { return 1.0; }

// main.c
#include "stdio.h"
int main(void) {
  float val = func();
  printf("%f %f\n",val,func());
}
stdio не в тех кавычках т.к. иначе RSS испортится, а < не понимает красивый форматтер :)

Лечение проблем LC_COLLATE при использовании UTF-8 в PostgreSQL под FreeBSD

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

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

Чудеса глобальной почты

Изучаю сайт usps.gov в части доставки в Россию. Нахожу там феноменальное:

Areas Served: All except Chaibucha, Yamsk, Garmanda, Gizhiga, Rep de Tchetchnya, Tachtoyamsk, and Verchniyi paren.
Ну ладно, простим им Чечню, хотя туда должно бы уже ходить. Но за что обижают Чайбуху, Ямск, Гарманду, Гижигу, Тахтоямск и Верхнего Парня ?

Начинаю разбираться. Выясняется, что все это - поселки в двух районах Магаданской области, Ольском и Северо-Эвенском. Но там еще МНОГО (по местным меркам) населенных пунктов (Северо-Эвенский район на Гугле).

Что, единственный почтальон в Эвенске согласен ездить в Тополовку, но не повезет iPod в Гижигу, которая ближе ? И мнение этого почтальона магическим образом преломилось и добралось до USPS ?

Pages

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