18 октября 2011, Нью-Йорк - Компания Canon представила профессиональную цифровую зеркальную камеру EOS-1D X. Новинка стала флагманом модельного ряда цифровых зеркальных камер Canon, открыв десятое поколение камер EOS. По словам производителя, устройство с поддержкой видео в формате Full HD 1080p «удовлетворит потребности практически любого профессионального фотографа».

Вчера, 12го октября Apple выпустила обновление iOS 5.0 и вместе с ним Xcode 4.2. Сразу бросилось в глаза, что в Build Settings из графы Architectures исчезла архитектура ARMv6, позволяющая запускать ваше приложение на iPhone 3G и более младших собратьях. Если вас не волнует поддержка старых моделей, оставляйте все как есть, в противном случае, необходимо в списке архитектур выбрать Other, нажать + и вручную вписать armv6.

Похоже, Apple стремясь увеличить объемы продаж начинает потихоньку теряет качество продукции. Может быть, винить непосредственно Apple и не совсем корректно, т.к. выходят из строя компоненты производимые сторонними поставщиками, но, как говорится, кого это волнует? Apple поставляет конечному пользователю готовый продукт, который должен работать, а если это не так, кого еще винить?

До определенного момента, качество продукции из Купертино в моей голове не вызывало никаких сомнений - за 3 года владения iPhone и Mac Book ниразу не пришлось вспоминать о гарантиях и сервисах. Однако, в этом году сразу несколько событий заставили меня пересмотреть свое мнение. Первой ложкой дегтя на репутации Apple стал банальный отказ HDD у знакомого на его iMac, спустя несколько месяцев после покупки. Вроде не так страшно, однако, просто так этот винт не заменить и пришлось связываться с сервисными центрами и менять все по гарантии, что заняло почти месяц. К слову, это был iMac "21.5 Mid 2010. Естественно, после сервиса пришлось еще возиться с восстановлением резервных копий и т.д.

Следующим "коричневым пятном" стало нечто посерьезнее - у нового iMac "27 Mid 2011, которому не было и месяца начала моргать подсветка экрана. Моргала по несколько раз за день, а через некоторое время и вовсе погасла у половины экрана:



Заказать новый экран по гарантии занимает от месяца и более и о счастье, что есть гарантия, иначе пришлось бы выложить половину стоимости самого моноблока за ремонт. Кстати говоря, поискав подобный дефект в интернете, я нашел достаточно много идентичных жалоб с приложенными фото. И у всех именно левая сторона экрана была темной, что наводит на мысль о массовом дефекте целой партии экранов.

У Apple для хранения резервных копий данных есть такое устройство под названием Time Capsule. Есть модели на 1, 2, 3TB, а может уже и больше есть... А что, если я не хочу тратить 10-20 тысяч родных рублей и хочу использовать уже имеющиеся средства, такие как NAS-сервер, или удаленную Linux машину с приличным массивом дисков? По простому, макосевскую Time Machine, а также Aperture Vault не подружить с сетевыми дисками, т.к. в ответ вы получите только ругань и упреки от Стива в том, что до сих пор не купили тайм капсулу. Но, все таки, надо что-то попробовать...

Итак, в этой статье я расскажу, как заставить Time Machine и Aperture сохранять все бекапы на Linux-сервере. Статья, также, может быть полезна владельцем NAS устройств, поддерживающих протокол AFP. Поехали! Первым делом нужно убедить Time Machine отображать в списке выбора дисков сетевые шары, для чего открываем терминал и выполняем команду:

Довольно просто пока, да? Далее, на linux-сервере (в моем случае под управлением Fedora), нужно установить netatalk версии не ниже 2.2. Важно, чтобы версия не была ниже, иначе ничего работать не будет! После установки, конфигурим следующим образом:

• В директории /etc/netatalk, в AppleVolumes.default в самом низу прописываем /mnt/storage/tm TimeMachine allow:YOURUSER rwlist:YOURUSER cnidscheme:tdb options:usedots,upriv,tm, где /mnt/storage/tm - путь до того места на сервере, где будут лежать бекапы, а YOURUSER - логин пользователя на сервере, под которым будет работать шара
• В afpd.conf тоже в самом низу добавляем - -uamlist uams_dhx.so,uams_dhx2.so -unixcodepage UTF-8 -maccodepage MAC_CYRILLIC -savepassword -setpassword -tcp -advertise_ssh
• Приводим вид содержимого файла netatalk.conf в такой вид:
  

Вот интересно стало, насколько различаются по производительности две абсолютно разные машины: массивный PC с хорошей видеокартой и компактный и красивый моноблок iMac. От последнего особой прыти не ожидалось, все таки место для мощных железяк в нем не много, с охлаждением скорее всего проблемы, да и вообще, внешне складывается ощущение, что сделан он для красоты, а производительность принесена в жертву. Итак, в тесте участвовали:

• Apple iMac mid 2011 27", Core i5 @ 3.10GHz, 4GB RAM, ATI HD6970M 1GB
• Intel PC, Core 2 Quad @ 2.70GHz, 8GB RAM, ATI HD5870 1GB

Понятное дело, что на iMac установлен более свежий процессор (Core i5 против Core 2 Quad на PC) да и частота побольше, зато в PC работает полноценная, мощная видеокарта приличного размера. Целью данного теста было исключительно абстрактное сравнение двух машин, чтобы каждый мог для себя прояснить, есть ли смысл переходить с более-менее подобной конфигурации хакинтоша на полноценный и компактный моноблок от Apple. Колонка справа отображает во сколько раз iMac лучше справился с тестом нежели хакинтош:

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

Для разбора нам понадобится два инструмента - очень тонкая крестовая отвертка, что-то острое, например, нож с тонким лезвием или тонкая минусовая отвертка, чтобы поддевать шлейфы и присоска, чтобы снять экран. Подойдет присоска от автомобильного держателя или от плюшевой игрушки. Если таковой нет под рукой (как у меня), можно воспользоваться ножом, но только очень осторожно. Первым делом необходимо извлечь сим-карту из телефона. Далее, снизу, там где порт подключения к компьютеру, откручиваем два миниатюрных винтика. Открученные винтики складываем аккуратно, чтобы ничего не укатилось и не потерялось. Затем, самая сложная часть разборки - нужно извлечь экран из корпуса присоской или тонким предметом. Для этого я аккуратно вставил лезвие ножа между хромированным ободком и резиновой прокладкой, которая прилегает к экрану. Здесь нужно быть очень осторожным, чтобы не повредить экран и саму прокладку. Вставив нож, осторожно, приложив небольшое усилие, приподнимаем экран. Будьте осторожны, т.к. вверху, в районе сим-карты, экран держится на 3х шлейфах, которые нужно будет отсоединить. Сначала отсоединяем шлейфы под номерами 1 и 2, и затем под вторым открывается вид на номер 3. С ним нужно быть осторожнее и, чтобы его отсоединить не повредив, надо тонким предметом приподнять клипсу на противоположном конце разъема и только после этого можно извлечь сам шлейф. Теперь экран можно отложить в сторону.

Перед нами материнская плата телефона, а под ней аккумулятор. Чтобы извлечь материнку - откручиваем 7 винтиков по периметру (7й винт под наклейкой "не откручивать"), отключаем шлейфы 4, 5, 6 и аккуратно вынимаем плату, поднимая ее за нижний край. Приподняв ее край, с обратной стороны отключаем шлейф, идущий от камеры и теперь, плату можно извлечь. Вот, собственно, и все. Далее все зависит от цели разбора: можно поменять стекло экрана, панельки, сам экран или батарейку. Моей целью было разобрать сим-ридер и восстановить на нем усики у контактов.

В прошлый четверг (23.06.2011) Apple выпустила последнее обновление Snow Leopard 10.6.8, которое, в первую очередь, призвано подготовить вашу систему к апдейту до OS X Lion через App Store. К сожалению, не обошлось без пропажи звука :). Но, нам повезло, велосипед изобретать не пришлось и, чтобы вернуть звук, достаточно сделать все тоже самое, что и после предыдущих обновлений, а именно - заменить /System/Library/Extensions/AppleHDA.kext на тот, что был до установки 10.6.8. Если у вас ALC888, взять кекст можно из предыдущих статей.

Предыдущие статьи по этой теме:

• Обновление Mac OS 10.6.5
• Обновление 10.6.4 и звук (ALC888)
• Обновление 10.6.3 и звук
• Обновление Леопарда до 10.6.2
• Установка Snow Leopard на Intel PC

Сегодня Apple официально анонсировала новую версию своего небезызвестного видеоредактора Final Cut Pro X. Этого события лично я ждал почти с того момента, как вышел последний iWork '11 с его iMovie. Ждал по одной простой причине, о которой ниже.

Для такого любителя, иногда снимающего видео, как я, до сегодняшнего дня было два варианта для монтажа отснятого материала - это либо iMovie, либо Final Cut (Adobe Premiere не рассматриваю, т.к. пробная версия не впечатлила вообще). Казалось бы, чем плох iMovie? Великолепная программа для любителя! Все просто, интуитивно понятно, удобно, красиво, а еще и быстро! Интерфейс у программы на высоте. Никаких проблем при знакомстве с ним не возникло, именно благодаря интуитивности. Нужно добавить красивый заголовок, симпатичный переход - нет проблем, все делается в один клик. При этом никаких рендерингов, все получившееся можно тут же просмотреть. В софте есть ровно то, что может понадобится и нет ничего лишнего. Программа имеет массу вариантов экспорта и не нужно никаких компрессоров. С импортом все тоже замечательно - iMovie умеет брать фото/видео из библиотеки iPhoto или Aperture. В чем же тогда проблема прекрасного iMovie? А в том, что качество результирующего видео прилично отличается от оригинала: заметно падает цветность с контрастностью, но самое главное - в темных местах видео, например, на фоновой тени сильно заметен цифровой шум, такой, как бывает при сьемке на высоком ISO. И дело тут не в моих настройках и кодеках, поиск по интернету показал, что проблема именно в iMovie '11.

В процессе длительной работы с двумя и более MySQL баз данных, между которым происходит репликация, можно столкнуться с массой мелких ошибок, вызванных, например, конфликтами первичных ключей, повреждениями журналов и т.п. Особенно, если репликация настроена, как мастер-мастер, конфликты гарантированы. Естественно, из-за мелких ошибок никто не станет полностью заново синхронизировать две базы данных, а скорее всего, пропустит ошибку через установку SQL_SLAVE_SKIP_COUNTER или slave-skip-errors. Со временем, две БД накопят некий запас неконсистентности, благодаря таким пропущенным конфликтам. Итак, что делать, если нужно восстановить полную консистентность, или в случае, когда ошибка в репликации совсем критичная и не решается вышеописанными способами? Единственный выход - полная синхронизация двух БД "с нуля" и сброс состояния репликации.

Порядок действий таков - на мастере:

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

На днях на одном из серверов внезапно остановилась репликация. Команда SHOW SLAVE STATUS показала ошибку: Last_Error: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Выглядит внушительно и слегка пугающе - все таки, не каждый день повреждаются файлы на жестком диске, к тому же файлы журнала репликации. Так или иначе, с ошибкой надо что-то делать и как всегда есть два варианта: простой, надежный, но муторный, связанный с ручной синхронизацией БД через импорт/экспорт, либо быстрый, но требующий внимания, т.к. связан со сбросом текущего положения "курсора" репликации на проблемном сервере.

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