9 лет с macOS

Внезапно осознал, что приблизительно 9 лет назад, в 2009 году, я перешел с Windows на Mac OS X. Сейчас, не дотянув 1 года до ровных 10 лет, я окончательно ушел с macOS на Linux + Windows. Всё это, само собой, относится к повседневному домашнему использованию и мелким личным проектам, на работе как были все 3 платформы с macOS в качестве основной рабочей среды, так и остались.

В 2009 году решения от Apple действительно впечатляли как своими дизайнерскими и инженерными решениями, так и тем что “всё просто работает”. Да и в профессиональном плане эта миграция 9-ти летней давности была очень удачным решением для меня. Именно благодаря этому я в своё время оказался в Лаборатории Касперского и получил невероятно интересный и полезный опыт. Но время шло, конкуренты развивались, Apple деградировал и в последнии годы я был вынужден сначала уйти с iOS на Android, который внезапно стал предлагать на много более адекватное сочетание цены/качества, а потом и на PC индивидуальной сборки.

В принципе, для человека занимающегося графическим дизайном или просто использующего компьютер для набора текстов, интернета и просмотра фильмов, но практически не играющий в ресурсоемкие игры решения Apple (iMac, все виды MacBook) до сих пор на высоте как минимум с точки зрения железа. К сожалению с точки зрения софта ситуация не столько радужная до боли стала напоминать древние Windows, когда до выхода SP1 о переходе на новую версию ОС и думать было нечего, так как с большой вероятностью что-то отваливалось. Так что на macOS всё до сих пор вроде “просто работает”, но только после Нового Года. Каждую осень выходит нечто непотребное, это нечто усиленно латают 2-3 месяца и после НГ уже можно обновляться на новую ОС.

Хотя дальнейшая пригодность macOS для дизайнеров мне кажется тоже под большим вопросом после новости о том, что OpenCL объявлен устаревшим, так как миграция всех продуктов со сложными расчетами на Metal Performance Shaders, который поддерживается исключительно Apple, мне кажется довольно невероятным развитием событий. Собственно, отношение к GPGPU со стороны Apple для меня и стало последней каплей. Мало того, что на всех компьютерах устанавливаются GPU от AMD, так еще и никакое кросс-платформенное API типа Vulkan, а теперь еще и OpenCL, не поддерживается. Хотя и до последнего анонса максимально поддерживаемая версия OpenCL была всего лишь 1.2.

В процессе миграции на Windows + Linux я с удивлением осознал что за прошедшие 9 лет Windows так и не стал дружественной к разработчику платформой. Всё те же пляски вокруг установки разных SDK, Студий, никакенная консоль, нет менеджера пакетов даже для продуктов Майкрософт… Ту же CUDA я так и не смог нормально запустить на Windows за где-то 8 часов чистого времени (то не та версия студии, то компонент уже установлен, но часть dll почему-то не установилась вообще, то еще 1001 невнятная проблема) но сделал это за 15 минут на Ubuntu, что мне кажется довольно показательно, с Ubuntu я ведь те же 9 лет не имел дела.

В итоге у меня теперь Windows для C1 и Photoshop, к сожалению на Linux нет и не будет ничего сопоставимого, и Ubuntu для всего остального

Устанавливаем OpenCV 3 для Python 3 на macOS

Конфигурация OpenCV 3 + Python 3 на macOS внезапно оказалась немного неожиданной в настройке. Изначально я ожидал что надо будет пару раз вызвать Brew, но оказалось несколько сложнее. Последовательность:

Смотрим где находятся site-packages для интерпретатора, которым собираемся пользоваться, понадобится ниже для создания симлинки на OpenCV:

>>> import site; site.getsitepackages()
['/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages', '/Library/Python/3.6/site-packages']
>>>

Ставим, собираем, делаем линку (если нет TBB и/или Qt5, ий стоит либо поставить заранее, либо убрать соответствующие флаги):

brew install numpy --with-python3
brew install opencv3 --with-tbb --with-qt5 --with-python3 --with-examples --with-contrib --c++11
sudo mkdir -p /Library/Python/3.6/site-packages
sudo ln -s /usr/local/opt/opencv3/lib/python3.6/site-packages/cv2.cpython-36m-darwin.so /Library/Python/3.6/site-packages/cv2.so

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

>>> import cv2; cv2.__version__
'3.2.0'
>>>

async && GCD

std::async из C++11 хорош практически всем: прост, удобен, универсален. И только одна особенность стандарта несколько портит этот праздник – нет четкой регламентации того, где и как должна выполниться асинхронная задача; задача может быть выполнена как в отдельном потоке, так и в пуле потоков. В итоге это приводит к тому, что разработчики STL не утруждают себя пулом потоков (даже при наличии оного в ОС по-умолчанию) и плодят по протоку на каждый std::async вызванный с флагом std::launch::async. В случае с macOS, как мне кажется, это довольно большая оплошность, так как в системе уже есть готовый пул потоков, которым остается только воспользоваться!
В итоге я немного поковырялся в стандарте, доступных реализациях и вышло у меня следующее: Continue reading

Браузер в песочнице

По не совсем понятным мне причинам, ряд критичных к наличию уязвимость приложений, например широко распространенный браузер Firefix, игнорируют использование встроенной в OS X песочницы. Казалось бы, много какие приложения могут игнорировать песочницу, но никак не те, которые скачивают и так или иначе исполняют произвольный контент из интернета. Возмущаться, конечно, можно долго, а можно просто взять и запустить этот самый Firefox в песочнице. Безопасно, интересно и познавательно

Для начала, какой тип песочницы лучше всего подойдет для интернет-браузера? Я решил остановиться на варианте с белым списком, т.е. приложению запрещено все кроме того, что разрешено. Дальне возникает вопрос как получить список разрешенных действий и тут есть варианты:

  • Запустить генератор профайла и выкинуть все лишнее;
  • Запускать приложение и отслеживать все, что выводится в консоль с тегом sandbox.

Continue reading

Swift – это изумительно!

Давно ничего не писал по программированию, т.к. у меня возрадилось старое хобби – фотография. Но про такое я просто не могу молчать! Язык Swift просто покорил меня с первого взгляда! Я долго откладывал знакомство с ним, воспринимая язык как улучшенную версию Objective-C в чем был сильно не прав. Первые впечатления которые оставляет язык – это как Python, только лучше и со статической типизацией. Основная крайне досадная проблема связанная с языком – поддержка исключительно OSX. Хотя, насколько я помню, было обещание Apple выпустить язык под какой-то свободной лицензией, что меня сильно обнадеживает.

На данный же момент мы получили просто мечту OSX/iOS разработчика.
Continue reading

Secure Coding Guide от Apple

На днях Apple опубликовала Secure Coding Guide. Главный недостаток документа – наличие большого количества “воды”, т.е. он мог бы быть с легкостью ужат со 123 до 50 страниц без потери качества. Тем не менее, OSX разработчикам крайне рекомендуется к прочтению или как минимум к пролистыванию.

Rust в ядре OSX

Как-то в дискуссии на РСДН-е проскользнула мысль о том, что одной из ключевых сфер применения Rust может оказаться разработка не User-mode приложений, а драйверов. Вот и результат небольшого эксперимента:

17/12/13 23:43:23,000 kernel[0]: hello from rust

Continue reading

Make && 10.9

В 10.9 подложили неожиданную пакость. Make внезапно стал запускаться с дополнительной выставленной переменной окружения следующего вида: SDKROOT=/. А так как у нас есть своя, довольно развесистая логика определения используемой SDK, она, конечно же, развалилась.
Микро Makefile:

$(info $(shell env))

И если напустить на него make в консоли получим приблизительно следующее:

... _=/usr/bin/make SDKROOT=/

WTF?!

Переменные окружения в OSX

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

Стандартный путь довольно прост: необходимо вписать в файл /etc/launchd.conf новые пути, следующим способом.

setenv PATH /new/path/a:/new/path/b

Собственно, я так делал всегда и все было нормально. Но, внезапно, а может и не очень, к примеру после какого-то обновления, ряд приложений (тот же Eclipse и Wireshark) перестал видеть что-либо за пределами переменных, прописанных в /etc/launchd.conf. В итоге, по мнению этого ряда приложений “исчезло” все, VJM, dir, ls да совсем-совсем все.

Гугла подсказала, что пользовательские переменные, которые должны стать доступны всем, можно добавить еще в пару файлов, например в /private/etc/paths. Формат файла прост: одна линия – один путь.

/new/path/a
/new/path/b

Working with TrustedBSD in Mac OS X

For a long time, we have been controlling access to files and applications at our computers using Discretionary Access Control (DAC). Usually, this approach looks like a combination of a user with restricted privileges having access to a number of strictly defined resources (files, applications, etc.) and an administrator with full access to all system resources.

Generally, this approach seems to be mostly sufficient, and — for users — sometimes even excessive, which is confirmed by a great number of users working with administrator privileges at their computers. Continue reading