Сюрприз от 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

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
}

Коллекция Cocoa контролов

Я долгое время считал что количество дополнительных библиотек для Mac OS X и iOS очень скромное. В крайнем случае ни о каких библиотеках кроме как OmniGroup, BWToolkit и Sparkle я особо не слышал. Поэтому, сайт CocoaControls был для меня очень приятным открытием. Пусть большинство контролов и не подойдет для непосредственного использования, но вот как набор идей и подсказок сайт реально великолепен!