Mac OS X в VMware: счастье есть!

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

Вот для чего нужно 32Gb памяти в машине (кликабельно)

А кроме шуток, внезапно с Mac OS X в VMWare случилось счастье и странные телодвижения более не нужны, все работает (т.е. я слоупок, этот самый анлокер давно существует и я про него давно знал, но сейчас только потестировал).

А именно:

  1. Берем VMWare Workstation (у меня - 8-я версия, с 9-й как-то любви не сложилось, правда это было с макосами поставленными старым странным способом, надо еще раз попробовать).
  2. Патчим ее VMWare unlocker-ом, в списке OS появляется Mac OS X (а в Program Files(x86)\VMWare\VMWare Workstation - появляется darwin.iso с VMWare tools).
  3. Берем и просто ставим Mac OS X:
    • Создаем новую VM
    • В качестве сидюка с OC - указываем ISO-образ с нужной нам версией Mac OS X (берем dmg с рутрекера и конвертируем в ISO)
    • Соглашаемся на все defaults, втч диск создаем как SCSI (я ставил памяти побольше и побольше ядер процессора отдавал, вот и все изменения).
    • Грузим виртуальную машину там вылезает инсталлятор
    • В инсталляторе идем в Disk Utility, создаем на диске один раздел (все остальное - defaults: GUID partition и все такое)
    • Диск становится виден инсталлятору - просто все ставим
  4. Подмонтируем вышеупомянутый darwin.iso и ставим с него VMWare Tools
  5. Скачиваем и ставим VMsvga2
И, собственно, все. Никаких kext, апдейты все ставятся с сайта Apple, 3D-акселерация работает (проверял шахматами), хотя и медленно, ПОЛНОЕ счастье.

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

Есть моментики:

RawDigger 0.9.18

RawDigger 0.9.18 успешно выпустился:

Брать здесь.

Впрочем, если вы пользователь, то вам ваша рабочая версия уже сказала.

В сравнении с Release Candidate 1 изменилось следующее:

  1. Добавление EXIF-тегов к экспорту работает на Mac с встроенным exiftool
  2. Exiftool (указанный пользователем в настройках) проверяется на наличие и на исполняемость файла.
  3. В диалоге экспорта добавлена галка "Open exported file with default application", если ее поставить, то будет запущено приложение, ассоциированное в вашей системе с .tif
  4. Windows: при смене типа экспорта, RD будет предлагать разумные имена файлов для экспорта. На маке, увы, это работает неустойчиво, лезть в дебри QFileDialog мне противно и там фишка выключена.

Про sRAW

Про внутреннее устройство sRAW я задумался, увидев вот такую вот гистограмму у темнового кадра (это 6D, ISO800, 20 секунд выдержки):

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

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

И вот что видно, если начать рассматривать:

Туристам: про литиевые батарейки в фонариках

Второй год наступаю на грабли о которых считаю нужным сообщить.

Перед поездкой: достаю из шкафа 3 литиевых батарейки Energizer Ultimate Lithium и вставляю их в фонарик (Petzl Tikka XP)

Где-то через неделю, в поездке, замечаю, что фонарик стал хреново светить (комплекта щелочных обычно хватает на две поездки). Удивляюсь, думаю "ну в рюкзаке включился" (да и то, уж часов 40 оно должно гореть на свежем комплекте то), ужасно мучаюсь, потом как-то выхожу из положения (в прошлом году в Хатгале купили обычные щелочные батарейки, в этом - был запас, мало ли).

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

Что оказалось: далеко не все светодиодные фонарики Petzl совместимы с одноразовым литием, а только новые (в чем там проблема - не знаю). У новых моделей в описании явно указывается "совместимо с литием", а про старые есть вот эта табличка (по смыслу: все старые фонари надо подарить кому-нибудь, если вы хотите таскать литий).

Мучаюсь теперь: Tikka XP2 привычнее и мельче, MYO RXP - сильно больше (и батареи АА, а не ААА, но в смысле совместимости с прочими потребителями оно и лучше) но и сильно мощнее.

P.S. Аналогичный случай, похоже, с программируемым тросиком PIXL: литий жрет сильно быстрее обычных щелочных батарей.

RawDigger 0.9.18 RC1

Граждане фотографы!

А потестируйте пожалуйста Release Candidate следующей версии RawDigger:

Всем спасибо, вышла 0.9.18 без лишних букв.

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

  1. 9 новых камер (см. Changelog)
  2. В CGATS-файлы пишется дополнительная информация (об использованных коэффициентах ББ, о множителе масштабирования, о максимумах данных), сами CGATS-файлы еще более приближены к стандарту.
  3. Можно делать RGB Rendering "как видит камера" (т.е. без наложения камерного профиля, конвертирующего в sRGB)

    Настройка Preferences - Display Options - Display RGB Render in RAW colors

    Если брать какой-то стандартный объект, скажем Color Checker, то чем менее насыщенными будут цвета в этом режиме, тем "шире фильтры". Вероятно, можно придумать какую-то метрику, которая будет это описывать.

    Если вы включите эту галку для 4-канальных не-RGBG RAW, то у вас пропадет RGB-rendering на экране (потому что как на RGB-экране посмотреть CMYG или там RGBE), но результат рендеринга можно будет экспортировать в 4-канальный TIFF и затем рассмотреть его в Фотошопе (который, правда, воспримет этот TIFF как CMYK :).

  4. Canon sRAW-файлы можно рассматривать "как они на самом деле устроены":

    В sRAW записаны данные в формате YCbCr, стандартная процедура декодирования (в LibRaw/RawSpeed) сразу конвертирует их в RGB и всего безумия, которое там творится, не видно.

    В новой версии RawDigger это преобразование можно отключить настройкой:

    Preferences - Data Processing - Show YCbCr data for Canon sRAW files

    И рассмотреть YCbCr данные как они есть.

    Очень поучительное зрелище, отвращает от этого формата надолго.

  5. Экспорт RAW/RGB-render данных в TIFF-файл.

    Menu - File - Export TIFF

    Несмотря на то, что эта штука во многом дублирует имеющиеся в LibRaw утилиты командной строки (dcraw_emu, 4channels, unprocessed_raw), пользоваться ею через GUI оказалось удобно.

На последней штуке остановлюсь подробнее:

Про оверклокинг i7-4770k

Вчера я писал, в числе прочего, что i7-4770k у меня на 4.5GHz на стресс-тестах подходит близко к TjMax, а на 4.6GHz - упирается в нее (и наступает throttling) на стресс-тестах и близко подходит при реальной работе.

Но. На третий день Зоркий Глаз заметил:

Для оверклока я использовал как настройки BIOS (там можно из менюшки выбрать, к примеру, "4.6GHz"), так и гигабайтовскую (чудовищную) утилиту EasyTune для автомагического подбора частоты горшка. Оба этих прибора ставят CPU VCore в 1.3 вольта с хреном (сотые не запомнил), а судя по обзорам - это много, хватит и меньшего.

Потратил часок на упражнения и увидел:

  • 4.5Ghz: 1.15V мало (система нестабильна), а вот 1.21V - в самый раз (может быть и меньше можно, проверять уже не стал). С 1.21V пиковая температура в стресс-тестах выше 81C не поднимается, обычно колеблется чуть ниже 80.
  • 4.6GHz: 1.22V мало (стресс-тест погонялся нормально, максимальная температура 84C, потом я стал писать этот пост - и Firefox упал), 1.245V - все нормально работает, пиковая температура в тестах 87С, обычно в стресс-тесте колеблется 80-82С.
Мораль: не верьте утилитам производителя, хоть и удобны они в использовании.

О линейности, профилях и конверсионных фильтрах

Есть мнение, что светофильтры (кроме, естественно, поляриков) при съемке цифрой не нужны.

А вот практика Ильи Борга свидетельствует о противоположном.

О бенчмарках

Вот так вот думает о моем новом процессоре AID64 3.0-beta:

А вот так вот версия 2.70.2250:

Да, я читал у них, что вот "разные версии AIDA не совместимы по результатам", но размеров дизастера не ожидал. Там, действительно, даже встроенные бд результатов разные, скажем i7-3770k в старой версии имеет в базе 18.8GB/sec по memory read, а в новой - 23.6.

Я к тому, что сравнивать результаты той же AIDA между разными обзорами - категорически нельзя.

Бета, заметим, профукивает (не показывает) оверклокинг.

Вместе с тем, про Haswell имею сказать, что апгрейд с Sandy Bridge мне кажется оправданным. Т.е. на оптимизированных под SandyBridge программах (своих) я вижу разницу раза в полтора, если на глазок. Более точно буду еще мерять.

Помимо этого, имею сказать:

Q: про PCIe свитчи

В свете выхода Haswell, встал (пока теоретический) вопрос о тотальном апгрейде всего.

У меня оно усугубляется тем, что

  • У процессора - 16 PCIe3 lanes
  • А мне их нужно, как минимум, вдвое больше (16 на видеокарту, если одну ставить, плюс два широких слота для 10Gbit адаптеров)
Соответственно, нужна материнская плата с PCIe-свитчом, который из 16 lanes делает 32. Таких материнок есть в количестве.

Но выбирая между ними, я увидел что есть два варианта:

  • 4 слота PCIe3 x16 (все слоты через свитч).
  • 5 слотов: или один слот мимо свитча, или более одного слота, но уже через свитч
И клянутся, что 1-слотовый случай дает меньшие задержки и все такое прочее.

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

Но увижу ли я хоть какую-то разницу "со свитчом" и "мимо свитча"?

Update: для материнок на Z77 с свитчом/без свитча, судя по тестам, значимой разницы нет.

Лето-2013: этап 1

Погуляли маленечко:
До 5000км чуть-чуть недокатались:
Фатально не повезло с погодой: по горам (нашему и монгольскому Алтаям) ходили циклоны, краешком задевая то что с юга (то есть нас). Как результат, вместо ожидавшегося солнца и жары - пасмурно, сильные ветра, песчаные бури и прочая плохая для съемки погода. Вместо финальной поездки в Монголию получилась рекогносцировка, через год-два придется повторить. Может оно и правильно получилось, время покажет.

P.S. Китайские гастарбайтеры стремительно строят асфальт от Ташанты (Цаган-Нура) до Улан-Батора, глядишь через пару лет получится пару дней на заездах поэкономить.

О журналистике? Об ошибках на сайтах вендоров?

В IXBT-шном обзоре GTX770 пишут:

Берется чип GTX 680 Перемычки, отвечающие за Device ID, ставятся иначе, и, оба-на получается GTX 770. Однако чтобы хоть как-то улучшить производительность в высоких разрешениях, а также в целом внести какое-нибудь отличие от вышеупомянутого GTX 680

С другой стороны, открываем список NVidia GPU по Compute Capability и читаем:

  • GeForce GTX 680 3.0
  • GeForce GTX 770 3.5
А 3.5, заметим, это Dynamic Parallelism, и прочие плюшки, связанные именно с одновременным исполнением разных kernels на одном чипе. Т.е. простой сменой Device ID тут не обойтись, нужна поддержка от чипа.

Хотелось бы понять, кто ошибся: обозреватель IXBT (и всех прочих изданий, написавших что GTX770 - это relabeled GTX680; и я не видел, чтобы NVidia кинулась их поправлять), или NVidia на своем сайте?

О "списках уязвимостей в программах"

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

Читаем:

LibRaw версии до 0.15.1

LibRaw-demosaic-pack-GPL2 версии до 0.15.1

LibRaw-demosaic-pack-GPL3 версии до 0.15.1

Имею сказать:
  • Не являясь специалистом в области ИБ, не могу сказать, является ли выход за пределы массива по фиксированному(!) адресу +4GB-1 (потому что там всегда 0xffffffff в индексе) возможностью выполнения произвольного кода. Возможно. Равно как является ли проблемой такой псевдокод a = malloc(..); free(a); free(a);. Возможно.
  • Эти проблемы в LibRaw 0.15.0 - были. Возможно, они серьезные, хотя мне так не кажется. Представить, что "удаленного пользователя" допустят до кода коррекции экспозиции - не могу.
  • Вот что я знаю точно:
    • Этих ошибок нет в LibRaw-demosaic-pack-GPL3, оно тут никоим боком.
    • этих ошибок нет в "версии до 0.15.1". Они есть в 0.15.0, а ветки 0.7...0.14 - не подвержены (по причине отсутствия соответствующего кода).
    Что позволяет мне предполагать, что никакого анализа никто не делал.

    SecurityFocus пишет что дескать vendor reported. Но ни одна скотина не пыталась сконтактировать с вендором и узнать подробностей.

Я собственно к чему - что теперь читая всякие security reports буду делить минимум на десять.

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

  • Если вы вендор - не надо репортить проблемы подробно (double call to free), все что вы написали - будет использовано против вас. Пишите просто "исправлена ошибка в обработке битых файлов Foveon"
  • Авторы этих репортов - не анализируют что сделано на самом деле, в каких версиях была ошибка и т.п. Соответственно нужно к этим репортам относиться: наличие репорта не означает проблемы (а отсутствие - отсутствия проблемы).

Pages

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