Симка для Турайи?

Пытаюсь выбрать симку для использования в мабиле Турайя (телефона еще нет, думаю взять в аренду). Турайя, как мы знаем, кушает любую партнерскую GSM-симку, вся наша гроссен тройка - партнеры. С точки зрения GSM-оператора, я просто в роуминге, в стране Турайя.

Проблема в том, что я сайт МТС читать умею и все там понимаю, а у остальных двух операторов никогда в клиентах не был и читать их сайты (и мелкий шрифт на них) не могу. Клиенты Мегафона/Билайна, помогите в них разобраться!

МТС

С МТС все понятно:

  • Берем любой тариф без абонентки.
  • Включаем на нем Мир без границ
  • Получаем
    • 19 рублей в день за "Мир без границ"
    • 150 рублей за первую минуту in и первую минуту out
    • 0 рублей за следующие 9 минут in
    • 8.90/минута за все остальное.

Непонятно что с СМС-ками, проще предположить что скидок на них нет и они так и будут по 19 рублей SMS-ки - в пакете 100 штук за 350.

Мегафон

О цветовой интерполяции

Навеяно вот этим вот обсуждением, пожалуй запишу.

Абстрагируясь от профилей камер, давайте представим себе профиль принтера.

К примеру, Monaco Profiler с удовольствием сделает вам цветовой профиль с таблицами 33x33x33. То бишь почти 108 тысяч коэффициентов (+тоновые кривые). Круто, да.

А на вход ему при этом подадут ну, скажем, 1728 патчей (12 в кубе). Так как жрет он не спектральные данные, а простой рабоче-крестьянский XYZ, то это будет примерно 5200 значений.

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

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

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

Я клоню к тому, что вижу в имеющемся подходе тупик: маленькие профили (с маленькой таблицей) дают плохую точность, это все знают из опыта. Большие профили (33x33x33) - основаны на выдуманных данных, а снабдить их невыдуманными данными, скажем промерять не пару тысяч патчей, а тысяч тридцать - невозможно на практике, слишком трудоемко.

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

P.S. То что мишени для тех же принтеров генерируются, как правило, путем равномерной расстановки точек по всему пространству координат - отдельная печальная песня.

О растре в GPS (HOWTO)

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

Задача

Задача проста - загнать в GPS-прибор (конкретно - Garmin 62s) растровые карты ("генштаб" с poehali.org) и спутниковые снимки, так чтобы все работало и не тормозило.

Ставший уже "классическим" способ описан на Веломании и в моем случае и с моим прибором у него оказалось два существенных недостатка:

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

О JNX

Бьюсь о JNX как рыба об лед:

  • Более-менее все работает, загнать 4 слоя Москвы (5,2,1-километровки и 500м) - удалось. Ну, не полностью (см. ниже), но удалось.
  • Загнать спутниковые снимки, выкачаные SAS.Планета - тоже, скорее получается. Но тоже, с приключениями какими-то.

Но

  • Нашелся лист километровки, который в JNX конвертируется, но не показывается прибором. Если порезать его на 4 куска, то с одним - все нормально, второй - конвертируется и не показывается. На втором я заплакал и дальше проверять не стал.
  • QLandkarte (единственная, вроде бы, десктопная софтина, понимающая JNX) показывает на моих JNX-ах полную кашу. Тайлы перепутаны, некоторые повторяются несколько раз, некоторые - на месте, некоторые - нет. Это касается и JNX-ов, которые прибором показываются нормально.
  • Здоровый спутниковый снимок (11x30 килопикселей до порезки) сконвертировался, в прибор входит, но прибор показывает не все тайлы.

Пользуюсь MAPC2MAPC, работаю как с просто привязанными картами (.map для Ozi), так и с геотифф и ECW (кои, в свою очередь, делаю GlobalMapper-ом с преобразованием в географические координаты из меркатора).

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

Пробовал MAP2JNX (из .ECW) - QLandkarte его вообще не показывает никак, в прибор еще не клал.

Короче, магия какая-то. Удивительнее всего то, что вроде бы "я один такой", в форумах обсуждают проблемы нестыковки листов на несколько пикселов, а так чтобы вообще не работало - вроде бы ни у кого такого нет.

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

Одна радость, с масштабами JNX разобрался, оказалось что надо их просто править в натуральных единицах и все.

Update: map2jnx версии 0.2.3 (но НЕ 0.2.4) решает, кажется проблему:

  • QLandkarte эти JNX нормально видит!
  • И прибор - тоже.

Экспериментальный снимок, который никак не давался - дался. Лист москвы, который никак не давался - тоже дался.

Фишка в том, что новая версия map2jnx (и, вероятно, свежие версии MAPC2MAPC - тоже) делают новую версию формата JNX. А где там дальше проблема, у утилит или у прибора - это не знаю и изучать не хочу.

Пойду, снимков москвы туда налью для интересу.

Не все йогурты одинаково полезны

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

Более того, реализаций для CPU уже две на виндах: AMD-шная входит в состав ATI Catalyst (драйверов для видеокарты) и даже при отсутствии подходящей видеокарты эта часть драйверов поставится. Кроме того, Intel-овский OpenCL на днях перешел из стадии альфа в бету. На Linux, кстати, есть еще IBM-овский OpenCL для CPU, все руки не доходят его ощупать.

Берем AMD-шный пример BitonicSort из APP SDK 2.4 (это AMD-шный SDK для GPGPU) и запускаем, без перекомпиляции, прямо на всех имеющихся в машине девайсах и реализациях. Сортируем 16 млн. элементов. В порядке падения быстродействия:

  1. Intel OpenCL (процессор i7-2600k @4.5Ghz): 10.6 сек.
  2. NVidia OpenCL (GTX480, драйвер 270.61): 16.4 сек.
  3. AMD OpenCL (Radeon 5870, драйвер 11.4): 29.3 cек.
  4. AMD OpenCL на CPU (тот же самый): 415 сек.
Я подозреваю, что AMD-шный OpenCL в случае CPU просто процессор не опознал и сгенерировал код для 8086 или что-то вроде этого. Для CPU AMD Kernel Analyzer показывает нам невекторизованый код, т.е. процессор не опознался и что под него генерировать AMD не знает. На предыдущем процессоре (i7-920) такой разницы с интеловским OpenCL (тогда он был в первой альфе) не было. При этом, при исполнении на AMD-OpenCL процессор загружен где-то на четверть, а "под интелом" - на 100%

Прикол тут в другом: по формальному быстродействию горшки ранжируются в обратном порядке: у AMD бешеные 2 терафлопса на float (по пресс-релизу AMD: 2.7 TFLOP/s), у NVidia - раза в два поменьше (в районе 1.35 TFLOP/s если формально считать), у CPU же, даже если AVX посчитать как 16 операций на такт (две AVX-операции на такт) получается 16 x 4 ядра x 4.5 гигагерца = 288 GFLOP/s.

Понятно, что сортировка - дело такое, для потоков плохо предназначенное.

Чтобы два раза не вставать: большинство AMD-шных примеров на GTX480 работает быстрее (и лишь некоторые - незначительно медленнее), чем на HD5870. Несмотря на формальные попугаи, говорящие об обратном. Обратного, чтобы OpenCL-примеры NVidia работали бы быстрее на AMD, - не наблюдается.

Update: Помучал тот же пример на машине с i7-920 и GTX280. AMD OpenCL/CPU никуда не годится и там, увы. Может быть надо kernel как-то иначе писать. Что же касается реализаций Intel (CPU) и NVidia (GPU), то на этой паре железок и BitonicSort они работают практически одинаково по скорости.

О барометрической альтиметрии

В обсуждении новых GPS-ов было высказано возмущение неотключаемым барометрическим альтиметром (еще).

Вместе с тем, FAQ (и форумы всякие - тоже) сообщает нам, что если перевести барометрический модуль в режим барометра, то высота будет писаться GPS-ная.

Значит надо взять и проверить.

Берем барокамеру (показана на картинке выше), помещаем в нее прибор в двух разных режимах, потом смотрим ему в графики и в сохраненные треки.

О крупноформатной печати

Был по делам на Пушкинской, "чтобы два раза не вставать" заглянул на Тверской Бульвар на Мир глазами россиян - 2011.

Удивительно, как плохо смотрится цветная струйная (?) печать цифровых картинок "метр на два" (там и больше есть) после "американских пейзажистов". Издали - нормально. Подойдешь поближе - тошнит.

Вывешиваемый там второй год подряд "Тобольский кремль" главного фотоблоггера страны огорчает отдельно.

С цибахромом/дурстом Белого Моря, который в первом этаже под пейзажистами висит аналогичная фигня. Если их смотреть до ч-б, то все отлично, а если после, то плохо.

Глобально спозиционировался: Garmin GPSMAP 62s

Как уже всем интересующимся стало ясно из каментов к предыдущему вопросу, я свой выбор сделал в пользу GPSMAP 62s.

Сначала два слова про Oregon 450. Благодаря любезности читателя, я его пять минут подержал в руках и мне все стало про него ясно:

  • Сенсорный интерфейс лично меня - не раздражает. И то, что точку надо ставить через выход в главное меню - тоже можно пережить.
  • Экранчик заметно хуже чем у 60Csx. Нет, во всех опробованных условиях удалось подобрать угол зрения или уровень подсветки и все более-менее было видно.
  • Но делать это добровольно я не согласен. То есть, да, видно, да, жить можно, но резко некомфортно, что при недостатке света (в подземном переходе), что при избытке (на солнце).
В результате был куплен 62s, о котором, по результатам эксплуатации в течение пары часов, имею сказать:

Если неясно что делать - делай по инструкции

[Оглавление раздела Hackinthosh]

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

Disk Utility → выбираем диск с системой → Repair Permissions

И что бы вы думали? Так тоже работает.

Смотрим заголовок поста.....

О глобальном позиционировании: Oregon 450 или GPSMAP 62s?

В прошлом обсуждении всплыла тема Garmin Oregon, который я для себя как-бы и не рассматривал, ибо тачскрин - зло.

Но призадумался, обчитался интернетов, сходил в лабаз пощупать, мнение так не выработал, спрошу у френдленты еще раз.

Garmin Oregon 450 выглядит капельку вкуснее, чем GPSMAP 62s:

  • Крупнее экран и в 2.5 раза больше точек, что для растровых карт может оказаться важным.
  • Легче.
  • Капельку дешевле (по прайсу разница $50, по факту у нас - баксов 20).
Минусы тоже понятны и вроде бы не очень существенны:
  • На 20% больше потребление батарей по спекам (компенсируется легкостью, получается примерно один фиг).
  • Более хлипкое крепление на тушке, ласточкин хвост против офигенной гайки.
  • Другая антенна. К Quad Helix у 60CSx у меня никаких претензий нет, а что с этим patch - мне непонятно.
  • Вроде бы не такой хороший экран в смысле читаемости на солнце.

Отсюда вопросы к владельцам Oregon и только к ним:

  1. Нормально ли работает экран на солнце, нужно ли при этом включать подсветку?
  2. Нет ли проблем с приемом сигнала (в сравнении с более продвинутыми антеннами)?
  3. Были ли хоть какие-то проблемы с тачскрином? Не тачался, тачался не так....
Маркетологам Гармина - незачет, устройства надо позиционировать чуть дальше друг от друга, раньше у меня проблем с выбором вообше никаких не было....

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

Update: Так как на эту статью попадают из поисковиков по запросу "62s или Oregon 450", делаю ссылку на страницу, на которой я описываю свой ответ на этот вопрос (62s).

В какой бубен дать?

[Оглавление раздела Hackinthosh]

Вот есть, я извиняюсь, Хакинтош.

В одной сети с ним (и в IP и в Ethernet смысле) есть Samba-сервер.

Имею проблему:

  • smbclient на этом Маке Хаке работает, равно как и прочие сетевые приложения. Проблем тут нет.
  • А вот коннект из Finder (Cmd-K, ввод smb://...) - не работает, даже пароль не спрашивает.
При этом:
  • Samba-сервер виден в "сетевом окружении" (секция Shared) в Finder, но приконнектиться к нему никак не получается, паролей не спрашивают.
  • Кроме того, на стороне Samba-сервера при попытке коннекта в сети - пусто (смотрю tcpdump, никаких пакетов ни на 139-й порт, ни на 445-й не прилетает). Если smbclient-ом ходить, то все нормально.
Вопросы обычные: кто виноват, что делать, куды поковырять. Firewall-а никакого на этом хакинтоше не включено и вообще - свежеустановленная машина.

Версия Mac OS X - 10.6.7, но 10.6.0 и 10.6.6 ведут себя аналогично. При включении в этот же Ethernet-шнурок Макбука - все работает отлично.

Update: какая-то удивительная херня. Если спрятать kext в котором драйвер (перенести куда-то, поапдейтить кэши), то коннектится мгновенно. После этого kext можно вернуть. Если не прятать - таймаут навсегда. Похоже, встроенный клиент хочет чего-то от драйвера, чего у того нету, а если драйвер попрятать (есть en0, а откуда он - не ведаем), то этого "чего-то" оно уже не хочет.

Update2:

Помогло вот это вот:

sudo chmod 0755 /System/Library/Extensions/smbfs.kext/Contents/Resources/load_smbfs
(права были 0644).

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

На настоящем маке, где все работало, права стоят 0755 и я их никогда сам не правил.

О классическом искусстве

Сегодня, наоборот, посетил Галерею Классической Фотографии, посмотреть на Анселя нашего Адамса и далее по списку.

Единственный минус: создается впечатление, что мир (ладно, США, раз у нас aмериканская пейзажная фотография) процентов на 70 состоит из Калифорнии, а в Калифорнии больше половины - это Йосемити. А в Йосемити этот самый их водопад виден отовсюду. То есть их каньонов - их ощутимо меньше, чем этого самого водопада.

А в остальном - все очень, очень и очень здорово. И размеры есть на все вкусы.

Лично я очарован Секстоном.

Pages

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