Сюрприз от Installd

Вчера мне Installd сюрприз сделал. Конечно, можно сказать что нужно внимательнее читать документацию, но, всей документации не перечитаешь, поэтому сюрпризы не избежны. А суть сюрприза вот в чем.
Возникла задача следующего плана: надо взять приложение A, выпилить из него часть функций, воткнуть новые и в результате получить приложение B. Причем, приложения A и B должны уметь работать параллельно. Каждое из приложений содержит в себе драйвера, демоны и кучу других системных компонентов. Таким образом, на диске, получаем приблизительно такую структуру:

/-- Library
    +--Application Suport
        +-- Company Name
            +--Product A
            +--Product B

Где Product B – директория с системными файлами нового приложения. С учетом того, что инсталляторы в Mac OS X воспринимаются исключительно как автоматизированное средство для копирования файлов, решение было предельно простым: взять уже имеющийся инсталлятор и поменять в нем “Product A” на “Product B”, не забыв поправить конфигурирующие скрипты. Но не тут то было.
Если попытаться установить два продукта параллельно, то начиналась магия: установка продукта A деинсталлировала продукт B и vice versa. Перерыл все логи инсталлятора, греша на pred- и post- install скрипты – ни малейшего намека на то, кто удаляет продукт. Хотел уже было браться за DTrace, но тут коллеги напомнили о fs_usage… Нашелся виновник: installd. Но, казалось бы, причем тут Installd?! А вот при том, что инсталлятор не только распаковывает файлы в нужные директории, но еще и делает “обновление” для пакетов с одинаковыми идентификаторами!

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

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

Я прочитал эти темы, созданные Вами:
http://www.rsdn.ru/forum/apple.os/4951747.flat
http://www.rsdn.ru/forum/apple.os/4336664.1
1) Хочу спросить у Вас, полезно ли вообще среднестатистическому программисту iOS знать все эти вещи про устройство ядра? Я никогда не видел вакансий системного iOS-программиста (может потому, что живу в Минске =) ). Большинство вакансий связаны с вэбом, GUI или играми.

Знание внутреннего устройства среднестатистическому iOS разработчику совершенно бесполезно. Вакансий системного iOS-программиста нигде, кроме как в Купертино нет и, скорей всего, не будет, так как на не разлоченом iOS устройстве установить что-либо системное не представляется возможным, а разлоченых устройств не так уж и много.
Единственный плюс в понимании внутреннего устройства iOS в том, что сама iOS ничто иное как урезанная OSX, так что если ты имеешь представление об одной системе, то эти знания помогут и со второй. Только тут возникает еще одно “но” – вакансий для системного разработчика OSX тоже по пальцам пересчитать можно, в той же Мск люди с таким знанием нужны в паре-тройке компаний. Удаленной работы по данному направлению лично я найти не смог.

 2) Я как-то встречал такое мнение, что “и Линукс и Мак являются Юникс-системами (POSIX). С одного на другой [имеется в виду программирование] перейти несложно”. Насколько это верно?

Отчасти верно. Обе системы – UNIX-like системы, но при этом внутреннее устройство Darwin (ядро Mac OS X) и Linux кардинально различаются. Хотя, в Darwin много общего с BSD системами. Если говорить точнее, схоже все кроме управления памятью, процессами и потоками.
Так что, перейти с Mac OS X на Linux, если заниматься не ядром, а низкоуровневыми сервисами довольно легко, правда аналогичный переход с Windows на Linux, при условии что на Windows занимался низкоуровневыми вещами не на много более сложен.

Внутреннее устройство Mac OS X

Долгое время, единственной книгой по внутреннему устройству Mac OS X была Mac OS X Internals: A Systems Approach. Книга жутко тоскливая и по моим ощущениям на 50% состоящая из исходников XNU. Так вот, похоже что дело идет на поправку, и я только что наткнулся на OS X and iOS Kernel Programming. Пока что успел довольно поверхностно пролистать, но первые ощущения очень положительные.
Бумажная версия, как всегда, есть на Amazon.

Что почитать по Mac OS X для начала?

С литературой дела, на мой взгляд, обстоят довольно хреново. Т.е. нет ни одного автора, которого можно было бы поставить в один ряд с Русиновичем или Рихтером. А уж про “печатное и на русском” я вообще молчу. Тем не менее, кое что есть. Данную литературу я бы разделил на 2 части:

  1. Драйвера и системные приложения.
  2. GUI приложения для конечного пользователя.

Как начать писать приложения для Mac OS X и iOS

Итак, по пунктам, что надо сделать для начала разработки под Mac OS X или iOS:

  1. Покупка Mac или установка Хакинтош. Я бы крайне не рекомендовал начинать с работы с виртуальной машиной, они работаютнастолько тормознуто, что такой вариант подходит разве что для “одним глазком на Mac OS X взглянуть”. Поэтому наиболее дешевым и доступным вариантом будет либо Хикинтош, либо покупка Mac Mini.
  2. Бесплатно зарегистрироваться в качестве разработчика Apple. Это необходимо сделать для доступа к документации и возможности загрузить 3-й Xcode.
  3. Загрузить бесплатно 3-й Xcode или купить за $4.99 Xcode 4. С учетом стоимости Xcode 4, я думаю что его купить все же логичнее. В то же время, в Xcode 3 доступна iOS SDK 4.3 и SDK для Mac OS X 10.6, так что “на посмотреть” его хватит.

Continue reading

Приятные новости

Новая EULA к новой версии Mac OS X 10.7 радует!

(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software.

Ждем обновления от Parallels и/или VMware!

Tasks Explorer 1.5

Ура! Я допилил его! Из нововведений: появилась возможность посмотреть стек вызовов и я решил открыть код под BSD лицензией. Из неприятных нововведений – похоже он стал немного течь. Если у кого-то есть желание поучаствовать в разработке – добро пожаловать!
Выглядит эта радость как-то так:

Ищем быстро. Очень быстро.

Незнаю кто как, но я обычно пишу код в Vim, отлаживаюсь в GDB, ищу Grep. Если первые два пункта не вызывают никаких нареканий, но вот Grep на больших объемах данных, например на проекте с 1GB исходных кодов, несколько нерасторопен.
Решение проблемы довольно простое: надо скрестить Spotlight с Grep и получить шустрый и удобный в работе механизм. Для zsh это можно сделать так:

g()

{
mdfind -onlyin . $1 -0 | xargs -0 grep -n --color=always $1
}