Всем привет!
!Отличная статья!
Оригинал на Хакере:
Предположим, ты недавно приобрел «мак» или раздумываешь, не сделать ли это. Но macOS кажется чуждой и непонятной, да и вообще ходят слухи о том, что там чихнуть нельзя без разрешения Тима Кука. Другая распространенная небылица — что macOS всего лишь чуть‑чуть переделанный Linux. В этой статье мы пройдемся по всем основным механизмам macOS и заодно поговорим о том, какие в реальности есть ограничения и можно ли их обойти.
Краткая история macOS
История macOS, как и в целом история Apple, увлекательна и полна захватывающих перипетий. Здесь я перескажу ее в очень сокращенном и упрощенном виде.
Все началось в далекие восьмидесятые годы с компьютеров Apple II. Операционной системы в современном понимании этого слова у них, по сути, не было: сейчас их ОС мы бы назвали прошивкой. Как и в случае с другими домашними компьютерами той эпохи, в нее входил интерпретатор BASIC, служивший для выполнения пользовательских команд.
Компьютер Apple Macintosh, вышедший на рынок в 1984 году, разительно отличался от этих машин. Его операционная система сразу включала в себя графический пользовательский интерфейс с поддержкой мыши. Оконный интерфейс по тем временам считался удивительной новинкой — до этого его не было ни у одного серийно производимого компьютера (Windows 1.0 появился через два года после Macintosh и многое у него позаимствовал).
Одна из первых версий MacOS
Классическая Mac OS активно развивалась до 1996 года, а последний ее релиз вышел в 2001 году. И если для конца восьмидесятых она считалась передовой, то в девяностые ее архитектура с устаревшей моделью разделения памяти постепенно стала преградой для развития Apple. В качестве экстренной меры руководство компании решило приобрести стартап NeXT, основанный ранее вытесненным из Apple Стивом Джобсом.
Mac OS 9 — последний большой релиз «классики»
Главной разработкой NeXT была графическая операционная система NeXTSTEP, в основе которой — Unix-образное ядро и окружение, продвинутый графический движок и набор объектно ориентированных фреймворков. Последний позволял разработчикам легко создавать оконные приложения на продвинутом по тем временам языке Objective-C. На компьютерах NeXT, к примеру, был создан прототип первого веб‑браузера.
NeXTSTEP
После того как команда разработчиков NeXT перешла в Apple, совместными усилиями была создана новая система — Mac OS X. Позднее ее переименовали в OS X, а затем в macOS (отдел маркетинга в Apple никогда не сидит сложа руки). Технически Mac OS X основана на NeXTSTEP, однако ее интерфейс многое почерпнул из классической Mac OS.
MacOS X 10.1 Cheetah
В переходный период «макинтоши» поддерживали как классическую Mac OS, так и Mac OS X. С 2002 года все компьютеры Apple стали выходить с предустановленной Mac OS X, а Mac OS 9 еще несколько лет можно было запускать в режиме совместимости.
Ядро XNU
В основе macOS, как и в основе любой другой ОС, лежит ядро. Оно отвечает за выделение процессорного времени, управление оперативной памятью и кешем, взаимодействием с устройствами и сетью. В то же время оно обрабатывает системные вызовы приложений и обеспечивает взаимодействие процессов.
Современная macOS работает на ядре XNU, которое пришло из NeXTSTEP. За основу его кода в свое время был взят проект Match — ответвление от ядра FreeBSD.
XNU означает X is Not Unix, «X — не Unix». Эта расшифровка — давно утерявший актуальность программистский юмор: macOS все же по большому счету считается одной из разновидностей Unix. Однако XNU не имеет бинарной совместимости с FreeBSD, то есть программы для FreeBSD в macOS нельзя запустить без изменений и перекомпиляции.
Ядро XNU — гибридное. Это значит, что в отличие от микроядер оно может быть дополнено расширениями, но при этом не является монолитным, как ядро Linux, где все функции собраны в один гигантский бинарный файл.
До macOS 10.15 основным способом расширения ядра были модули kext. Поскольку «кексты» работают в пространстве ядра, сбои в них могут приводить к нестабильной работе компьютера. К тому же они открывали большие возможности для недобросовестных разработчиков.
Сейчас «кексты» считаются устаревшим методом, и со временем он будет отключен. Вместо этого в Apple предлагают разработчикам использовать фреймворки DriverKit и SystemExtension, которые позволяют создавать драйверы и расширения, работающие в пространстве пользователя.
Архитектура macOS
Darwin
Операционная система — это не только ядро. Вместе с Match в NeXTSTEP, а затем и в Mac OS X перекочевал набор библиотек и исполняемых файлов, которые вместе с XNU обеспечивают поддержку POSIX — Portable Operating System Interface, «портируемого интерфейса операционной системы». Это стандарт, которому в той или иной мере соответствуют все Unix-образные операционные системы и который обеспечивает низкоуровневую совместимость между ними.
В macOS этот слой называется Darwin и по сути представляет собой самостоятельную операционную систему. Сюда не входят графическая среда и библиотеки, нужные для работы оконных приложений, но входят ядро, драйверы, сетевой стек, набор системных и пользовательских утилит командной строки, а также система запуска служб и приложений launchd.
При желании Darwin можно установить как самостоятельную минималистичную ОС с текстовым интерпретатором команд. Код Darwin с самого начала был открыт, однако со временем в нем появилось множество закрытых компонентов, включая специфичные для «маков» драйверы.
Последние версии Darwin уже было невозможно собрать и заставить работать без средств, доступных только программистам Apple. Получилось, что публикация исходников в таком виде стала не нужна ни Apple, ни сообществу, и ее просто прекратили. Код XNU тем временем по‑прежнему
на GitHub и продолжает обновляться.
Сейчас силами сообщества поддерживается проект
— по‑настоящему открытая реализация Darwin.
Графическая система
Графический слой в macOS обычно называют Quartz, хотя подразумевается под этим набор библиотек Core Graphics. Две его важнейшие части — это Quartz 2D и Quartz Compositor.
Quartz 2D
Quartz 2D отвечает за все, что связано с двумерной графикой. В его основные задачи входит отрисовка текста и превращение графических примитивов, описанных в формате PostScript, в растровые изображения, которые затем передаются в Quartz Compositor.
Формат PostScript изначально был разработан в компании Adobe и предназначался для вывода документов на печать. Также PostScript лег в основу формата PDF и, что важно для нас, использовался в компьютерах NeXT для описания выводимой на экран графики. Оттуда он и пришел в macOS. Благодаря такому близкому родству PostScript и PDF «маки» и айфоны прекрасно справляются с отображением PDF без установки Adobe Acrobat или другого просмотрщика.
Quartz Compositor
Quartz Compositor одновременно играет роль графического сервера и композитного оконного менеджера. С одной стороны, он получает от приложений растровые изображения их окон и собирает из них картинку для отображения на экране (это и есть композиция), с другой — обрабатывает события, связанные с устройствами ввода: клики мышью и нажатия на кнопки клавиатуры. Quartz Compositor определяет, к какому окну относятся события, и пересылает их соответствующим приложениям.
Поскольку Quartz Compositor — это еще и оконный менеджер, в его задачи входит отрисовка пользовательского интерфейса. Это шрифты, меню, рамки окон, панели и прочие виджеты, которые коллективно называются интерфейсом Aqua. В ранних версиях Mac OS X некоторые его элементы действительно походили на капли воды, но с тех пор дизайн многократно меняли, и теперь это просто название.
XQuartz
Если порыться в средствах разработки для macOS, то можно откопать еще один интересный артефакт — XQuartz. Это реализация оконного сервера XWindow из Unix. Долгое время его свободная реализация X.Org входила в каждый дистрибутив Linux и была стандартом де‑факто. Сейчас старые и не очень добрые «иксы» постепенно заменяют системами вроде Wayland и Mir, в чем‑то схожими по устройству с маковским Quartz Compositor.
XQuartz
Что до XQuartz, то он явно создавался в Apple с мыслью, что неплохо бы иметь возможность запускать графические приложения для Unix и Linux. Однако нужда в этом оказалась не так велика, и никакого развития XQuartz не получил. В Linux большинство графических программ опирается на библиотеки сред Gnome и KDE, а их портирование на «мак» в планы Apple не входило. В итоге XQuartz может пригодиться только для самых простых графических программ, которые общаются с XWindow напрямую.
APFS
До выхода macOS 10.13 High Sierra файловой системой по умолчанию на любом «маке» была HFS+, унаследованная еще от классической Mac OS. В свое время она считалась передовой — у HFS+, к примеру, есть поддержка Unicode и журналирования (журнал ФС — история операций, которая помогает сохранить целостность данных в случае сбоя или отключения питания). Однако исходная HFS проектировалась еще в восьмидесятых годах и, несмотря на апгрейд до HFS+ в конце девяностых, не поддерживала многие важные новшества.
В Apple разработали и в 2017 году успешно внедрили в iOS новую файловую систему, названную APFS — Apple File System. Она обладает множеством достоинств, которые пришлись кстати не только на айфонах и айпадах, но и на «маке».
APFS изначально спроектирована с учетом использования твердотельных накопителей (SSD), в частности поддерживает команду TRIM. Также она может адресовать файлы с использованием 64-разрядных идентификаторов (вместо 32-разрядных в HFS+), поддерживает разреженные файлы (если файл пустой, система не занимает пространство нулями, а сжимает их), может шифровать данные на уровне файлов и каталогов (а не только весь диск) и позволяет открывать сетевой доступ к дискам с помощью разных сетевых протоколов.
APFS дает прирост в скорости, заметный в повседневной работе. Например, гораздо быстрее, чем на HFS+, подсчитывается размер каталогов и копируются файлы.
Создание тома APFS в Disk Utility
Наконец, самая заметная фича APFS — это возможность не задавать фиксированный размер логических томов. Они разделяют общее физическое пространство, и каждый из них будет занимать столько, сколько занимают его данные.
Спецификации APFS открыты в достаточной мере, чтобы создавать драйверы «только для чтения». Однако уже существуют экспериментальные драйверы для Linux, работающие с APFS в режиме «чтение и запись».
Важная особенность APFS, о которой стоит знать пользователю, — это нечувствительность к регистру. То есть FILE, file, FiLe и прочие подобные вариации — это с точки зрения APFS ровно одно и то же. Чувствительность к регистру можно включить при форматировании тома, но по умолчанию на всех «маках» эта настройка выключена.
iCloud
Еще с начала двухтысячных в Apple экспериментировали с поддержкой собственных облачных сервисов на уровне macOS. iCloud предшествовали iTools, .Mac и MobileMe. Названия менялись, но основная суть всегда сводилась к синхронизации данных между устройствами.
Здесь мы не будем погружаться в устройство iCloud. Важно знать лишь то, что его использование опционально, но значительно упрощает синхронизацию между компьютерами и гаджетами Apple.
Наиболее заметный и важный компонент iCloud — это iCloud Drive, куда пользователь может сохранять документы, после чего система будет автоматически следить за их состоянием и передавать изменения в облако. Помимо этого, существует фреймворк CloudKit, который разработчики используют для синхронизации настроек и прочих отличных от документов данных.
iCloud тесно связан с учетной записью Apple ID, однако это не одно и то же. Строго говоря, иметь Apple ID, чтобы пользоваться «маком», необязательно, но без этой учетки нельзя будет скачивать приложения из App Store. С Apple ID пользователь получает небольшое бесплатное хранилище в iCloud, на данный момент — 5 Гбайт.
Защита
SIP
Раньше на «маках» пользователь с привилегиями администратора имел все те же возможности, что и root — «корневой» пользователь в Unix. Подтвердив команду вводом пароля, он мог, к примеру, изменять или удалять любые файлы в системе.
Это оставляло лазейку для вредоносного ПО: если убаюкать осторожность пользователя и заставить его ввести пароль, то дальше можно скрытно творить что угодно.
В OS X 10.11 El Capitan появилась система System Integrity Protection (SIP) — «защита целостности системы». На практике это реализованный на уровне ядра целый комплекс мер, который не дает затрагивать работу системы даже администратору.
Системные файлы и каталоги теперь под защитой — это реализовано как специальный расширенный атрибут у файла; запрещена инъекция кода в процессы, причем не только системные, но и другие; запрещена загрузка в ядро неподписанных расширений.
Конечно, бывают случаи, когда SIP мешает сделать что‑то нужное. Как любитель покопаться в системе, я спотыкаюсь об эту защиту регулярно с момента ее появления.
Отключить SIP возможно. Для этого нужно перезагрузить компьютер в режиме восстановления, открыть терминал и использовать утилиту csrutil. Затем еще одна перезагрузка, и еще две — чтобы потом включить SIP обратно (что все же рекомендуется делать).
Gatekeeper
Еще один механизм, призванный защитить «мак» от вирусов, называется Gatekeeper. Это система, которая, опираясь на базы данных Apple, распознает потенциально вредоносные файлы и препятствует их запуску.
Работает это вот как. Каждый скачанный файл помещается в карантин, получая соответствующий расширенный атрибут. При попытке запустить исполняемый файл, стоящий на карантине, система проверяет, не находится ли он в черном списке, есть ли у него подпись сертифицированного разработчика, и если да, то не изменено ли содержимое файла.
В зависимости от результатов проверки система либо сразу запускает файл, либо отказывается это делать. Если проблема в отсутствии подписи, то это легко обойти — достаточно открыть файл через контекстное меню, а не двойным кликом.
Gatekeeper при желании можно полностью отключить одной командой, причем не требуется даже перезагрузка. Хоть это и облегчит жизнь, делать так не рекомендуется. Программы просто так не попадают в черные списки!
Secure Enclave
В «маках» с чипами серии M либо с процессорами Intel и дополнительными чипами серии T используется специальное аппаратное решение для надежного хранения и подтверждения ключей шифрования и биометрической информации — Secure Enclave.
Пользователю Secure Enclave не виден, взаимодействовать с ним напрямую никак нельзя. Зато система общается с ним каждый раз, когда ты подтверждаешь платеж или ввод пароля отпечатком пальца или разблокируешь компьютер при помощи Apple Watch.
App Sandbox
Отдельно от SIP и Gatekeeper существует механизм App Sandbox, который контролирует доступ сторонних приложений к пользовательским и системным файлам и папкам. Точнее, позволяет разработчикам самим ограничивать возможности приложений! Для программ, распространяемых через App Store, это необходимое условие, для загружаемых другими способами — опциональное.
Настройка App Sandbox в Xcode
Подключив App Sandbox в Xcode при сборке проекта, разработчик выбирает, какие функции могут понадобиться приложению: доступ к определенным папкам, сетевым протоколам, возможностям вроде Apple Pay. Приложение при работе будет просить пользователя подтвердить, что он разрешает использовать тот или иной ресурс.
FairPlay
Помимо механизмов, призванных защитить данные пользователей, в macOS есть и одна система, защищающая данные от пользователей. Речь о FairPlay — местной реализации цифровой защиты авторских прав (DRM). Это, пожалуй, единственное серьезное ограничение, намертво зашитое в macOS.
FairPlay может распространяться как на отдельные файлы в форматах MP4 (видео) и AAC (звук), так и на потоковое вещание (FairPlay Streaming). В частности, эту защиту используют в Netflix.
FairPlay жестко ограничивает копирование защищенной информации, поэтому если попытаться сделать скриншот фильма из Netflix или Apple TV, то получится только черный прямоугольник. Записать видео или захватить аудио из защищенного источника тоже не выйдет без дополнительных ухищрений.
Программирование
Даже при беглом знакомстве с macOS легко заметить, что большинство программ здесь имеют единый визуальный стиль, стандартные диалоги открытия и сохранения файлов, выбора шрифтов и цвета и прочие общие элементы. Все это — благодаря тому, что они основаны на стандартных объектных библиотеках, реализующих интерфейс Aqua.
Такой подход не только обеспечивает консистентный стиль и предсказуемое поведение программ, но еще и экономит оперативную память, а также позволяет Apple в любой момент вносить разного рода изменения. К примеру, когда в macOS 10.14 Mojave появился темный режим, его внедрение потребовало минимум усилий от разработчиков программ.
Однако говорить о том, что в macOS есть только одна оконная библиотека, в наше время не приходится. В реальности фреймворков несколько: какие‑то из них оставлены для совместимости, другие пока носят экспериментальный характер.
Objective-C
Традиционный и до сих пор самый надежный способ разработки программ для macOS — это использование языка Objective-C и фреймворка Cocoa, известного также как AppKit (или NSApp, если заглянуть во времена NeXTSTEP).
Разработка в Xcode на Objective-C
Objective-C — это высокоуровневый объектно ориентированный язык с поддержкой разных видов типизации. Он унаследовал идеи Smalltalk (объекты и сообщения) и C (базовый синтаксис, прямое управление памятью). Абстрактно его можно считать эппловским аналогом C++ или в какой‑то мере — C# и Java.
AppKit
Знания одного только Objective-C недостаточно для разработки маковских приложений. Гораздо больший пласт — это разнообразные API и фреймворки, которые поставляются с системой. Любой программист практически сразу же столкнется с Foundation Kit, где реализованы базовые объекты и структуры, а при написании графических приложений — с AppKit.
AppKit реализует привычную в наше время схему MVC, то есть «модель — вид — контроллер», где модель отвечает за структуру данных, вид — за их отображение, а контроллер — за реакцию на действия пользователя. С помощью AppKit описывается внешний вид и поведение всех окон, меню, кнопок, текстовых полей и других элементов интерфейса.
Для разработки программ на основе AppKit часто применяется Interface Builder, входящий в Xcode. Это визуальное средство разработки интерфейсов, которое позволяет собрать приложение из составных частей, как в детском конструкторе (если ты сразу вспомнил Visual Basic, Delphi, C++Builder или Qt Designer, то это верная аналогия). Разработчики нередко критикуют этот подход: вместо навыков программирования он требует именно умения обращаться с Interface Builder.
Swift
Objective-C служил NeXT и Apple верой и правдой с восьмидесятых годов и неплохо справлялся со своими задачами. Однако за все это время он очень мало изменился и лишен многих возможностей, привычных современным программистам.
В 2014 году на конференции WWDC анонсировали новый язык для написания маковских приложений — Swift. За его созданием стоит Крис Латтнер, известный как один из основных разработчиков универсального компилятора LLVM.
Как и Objective-C, Swift — компилируемый язык, нацеленный на разработку стабильных и производительных приложений. Он тоже использует схожий с С синтаксис, однако унаследовал некоторые парадигмы от скриптовых языков вроде JavaScript и Python.
По своим возможностям Swift уже способен полностью заменить Objective-C и превосходит его в производительности. Однако базовые фреймворки еще не все переписаны на Swift, поэтому пока что разработчикам сложных приложений приходится регулярно сталкиваться с Objective-C и его наследием.
SwiftUI
NSApp/AppKit разрабатывался вместе с Objective-C и с учетом его возможностей. И хоть из Swift и можно обращаться к нему, аналогичной парой для нового языка должен стать интерфейс SwiftUI.
За основу SwiftUI взяли UIKit (CocoaTouch) — более новую модификацию AppKit, разработанную для iOS. SwiftUI должен заменить оба этих фреймворка и позволяет писать приложения, которые будут работать на всех платформах Apple: часах, телефонах, планшетах, компьютерах и телеприставках.
Главная фишка SwiftUI — это возможность описывать приложения в декларативном стиле. То есть вместо того, чтобы команда за командой перечислять, какие элементы интерфейса куда поместить, достаточно описать, как будет выглядеть приложение, а промежуточные шаги и раскладку SwiftUI возьмет на себя. Interface Builder при этом уже не нужен.
Разработка интерфейса на SwiftUI
SwiftUI позволяет разработчикам экономить массу усилий, когда задумка совпадает с доступными возможностями. В противном же случае SwiftUI может стать серьезной преградой. Возможно, с развитием SwiftUI станет легче, но пока что ситуации, о которых в Apple не подумали заранее, встречаются на каждом шагу и вынуждают разработчика возвращаться к AppKit — благо смешивать его со SwiftUI никто не мешает.
Catalyst
И еще один современный эппловский фреймворк, о котором стоит упомянуть, называется Catalyst. Катализировать он призван портирование на «мак» приложений, написанных для iOS на UIKit. По заверениям Apple, создать десктопную программу из мобильной можно буквально за один день.
В доказательство на презентации показали официальный клиент Twitter, портированный с iOS. И... им действительно при желании можно пользоваться. Однако по поведению он заметно отличается от «родных» маковских приложений.
Клиент Twitter на Catalyst
Catalyst — это переходный фреймворк, и постепенно его должен полностью вытеснить универсальный SwiftUI. Собственно, приложений, перенесенных на «мак» при помощи Catalyst, оказалось немного, и, скорее всего, его отправят на пенсию даже раньше времени.
Carbon
История с Catalyst немало напоминает другой эпизод из жизни Apple. Когда Mac OS X была совсем новой и нуждалась в приложениях, в Apple решили помочь разработчикам программ для классической Mac OS переехать на новую систему.
Так родился фреймворк Carbon, предоставляющий поддержку старых API, но для пользователя рисующий все тот же интерфейс Aqua. Carbon оказался серьезным подспорьем для разработчиков, и его, в частности, использовали в продуктах Adobe — вплоть до выхода Creative Suite 5.
WebObjects
Наконец, тебе еще кое‑где может встретиться слово WebObjects. Это название эппловского объектно ориентированного веб‑фреймворка, созданного на заре интернета и пришедшего еще из NeXT. По своим возможностям он серьезно опередил время, но использовать «мак» в качестве веб‑сервера было странной идеей что тогда, что сейчас. Единственная компания, которая до сих пор применяет WebObjects, — это сама Apple. На этой технологии частично работают App Store и Apple Music.
Apple Silicon
В Apple очень серьезно относятся к тому, чтобы иметь не только собственный софт, но и свое железо, идеально подходящее к софту. Выбор центрального процессора здесь играет важнейшую стратегическую роль. В Apple уже трижды меняли тип CPU «макинтошей»: Motorola 68000 (32-разрядный CISC) на PowerPC (32- и 64-разрядный RISC), затем на Intel (32- и 64-разрядный CISC) и в 2020 году — на ARM (64-разрядный RISC).
К моменту последнего перехода в Apple уже снабжали iPhone, iPad и прочие гаджеты своими системами на чипе серии A на основе ARM. Так что перевод «маков» на ту же аппаратную платформу не стал неожиданностью. Этого события ждали давно, и если что‑то и удивило, так это его почти полная безболезненность и даже невидимость изменений для пользователей.
«Макинтоши» на Apple Silicon (так официально называется эппловская разновидность ARM) не потеряли совместимость почти ни с одним приложением — в первую очередь за счет системы бинарной трансляции, известной как Rosetta 2.
Rosetta 2 при первом запуске исполняемого файла, предназначенного для «маков» с чипом Intel, переводит инструкции x86 в инструкции ARM, то есть производит «компиляцию перед использованием» — AOT. При необходимости доступна и динамическая компиляция — JIT.
Все это позволяет запускать те же приложения, что и раньше, даже если их разработчик не позаботился о пересборке под новую архитектуру. Причем зачастую производительность не только не уступает производительности «маков» с чипами x86, но и превосходит ее!
Свою роль в том, что переход на Apple Silicon был легким и незаметным, сыграла и та подготовка, которую начали за много лет до решающего момента. В Apple очень ловко убрали поддержку старых 32-разрядных приложений за год до анонса Apple Silicon — в операционной системе macOS 10.15 Catalina. Rosetta 2 не позволяет запускать такие программы, и лишний год дал сторонним разработчикам время подготовиться.
Что до приложений и фреймворков, поставляемых с macOS, то в них поддержку 64-разрядных архитектур начали добавлять еще c 2009 года, когда вышла Mac OS X 10.6 Snow Leopard. Библиотеки Carbon, не имевшие 64-разрядной версии, перестали поддерживать в 2012 году в OS X 10.8 Mountain Lion.
Такие планомерные уборки в чулане позволяют Apple с легкостью менять аппаратные платформы и поддерживать «легаси» только в переходные периоды.
Прочее
Помимо перечисленного, в macOS есть еще несколько компонентов, которые роднят эту ОС с миром Linux. К примеру, это система печати CUPS и сервер VNC, используемый для шейринга экрана. И конечно, командная оболочка Bash, стандартная для любого Linux (в последних версиях macOS по умолчанию установлен еще и ZSH).
Долгое время с macOS поставлялись интерпретаторы языков Python, Perl и PHP. В macOS 12 Monterey убрали Python 2.7 и PHP, оставив только Perl, однако вместе с Xcode или Command Line Tools for Xcode устанавливается Python 3.
Причина «уборки» — в том, что нужны эти языки в основном программистам и энтузиастам, причем зачастую в гораздо более новой версии, чем есть в системе. А раз ставить новую все равно придется, то старая будет только мешать.
Выводы
Итак, думаю, ты уже понял, что macOS — это не Linux, хотя и гораздо более близкая к нему система, чем, например, Windows.
Здесь используются свои ядро, графическая система, оконная среда и графические фреймворки. Поддержка стандарта POSIX обеспечивает возможность портировать на macOS Unix-совместимые программы. Некоторые из них уже поставляются вместе с системой.
Что до слухов о том, насколько macOS закрыта, то они сильно преувеличены. «Закрыта» она не в большей мере, чем Windows, а местами в гораздо меньшей. С другой стороны, понятно, что это не Linux, где почти каждый компонент есть в нескольких вариантах и при желании можно сделать новый форк любого из них. И конечно, широко известно, что macOS официально нельзя установить на другие компьютеры, кроме «маков».
Критика этих фактов каким‑то образом переродилась в слухи о том, что в macOS нельзя слушать музыку, если ты не купил ее в iTunes Store, или запустить скачанные из интернета приложения. Все это, конечно, полнейшая ерунда.
Существует опасение, что macOS постепенно объединят с куда более закрытыми iOS и iPad OS. Чтобы понять стратегию Apple в этом плане, достаточно взглянуть на SwiftUI. Он позволяет писать единые приложения, имеющие разный внешний вид и поведение на разных устройствах с учетом их размера, возможностей и схемы использования. Очевидно, что и дальше в Apple будут не изничтожать, а скорее подчеркивать отличия между разными видами компьютеров.
Так что объединение, с одной стороны, вряд ли произойдет, с другой — уже вовсю происходит. Просто оно работает совсем на другом уровне: унифицируют внутренние системы (например, APFS), создают общий базис для разработки приложений (SwiftUI), в macOS постепенно добавляют некоторые новые фичи из iOS (и наоборот — iOS и iPad OS получают кое‑что с «мака»).
Уже много лет macOS — отличный выбор как для повседневной работы, так и для творчества и для многих видов разработки. Непрерывная оптимизация и чистка, практикуемые в Apple, позволяют сохранить производительность и внедрять новшества на всех уровнях системы. К тому же в macOS есть огромный потенциал для автоматизации, о котором мы уже не раз писали и еще вернемся к нему в будущем.
!Отличная статья!
Оригинал на Хакере:
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Предположим, ты недавно приобрел «мак» или раздумываешь, не сделать ли это. Но macOS кажется чуждой и непонятной, да и вообще ходят слухи о том, что там чихнуть нельзя без разрешения Тима Кука. Другая распространенная небылица — что macOS всего лишь чуть‑чуть переделанный Linux. В этой статье мы пройдемся по всем основным механизмам macOS и заодно поговорим о том, какие в реальности есть ограничения и можно ли их обойти.
Краткая история macOS
История macOS, как и в целом история Apple, увлекательна и полна захватывающих перипетий. Здесь я перескажу ее в очень сокращенном и упрощенном виде.
Все началось в далекие восьмидесятые годы с компьютеров Apple II. Операционной системы в современном понимании этого слова у них, по сути, не было: сейчас их ОС мы бы назвали прошивкой. Как и в случае с другими домашними компьютерами той эпохи, в нее входил интерпретатор BASIC, служивший для выполнения пользовательских команд.
Компьютер Apple Macintosh, вышедший на рынок в 1984 году, разительно отличался от этих машин. Его операционная система сразу включала в себя графический пользовательский интерфейс с поддержкой мыши. Оконный интерфейс по тем временам считался удивительной новинкой — до этого его не было ни у одного серийно производимого компьютера (Windows 1.0 появился через два года после Macintosh и многое у него позаимствовал).
Классическая Mac OS активно развивалась до 1996 года, а последний ее релиз вышел в 2001 году. И если для конца восьмидесятых она считалась передовой, то в девяностые ее архитектура с устаревшей моделью разделения памяти постепенно стала преградой для развития Apple. В качестве экстренной меры руководство компании решило приобрести стартап NeXT, основанный ранее вытесненным из Apple Стивом Джобсом.
Главной разработкой NeXT была графическая операционная система NeXTSTEP, в основе которой — Unix-образное ядро и окружение, продвинутый графический движок и набор объектно ориентированных фреймворков. Последний позволял разработчикам легко создавать оконные приложения на продвинутом по тем временам языке Objective-C. На компьютерах NeXT, к примеру, был создан прототип первого веб‑браузера.
NeXTSTEP
После того как команда разработчиков NeXT перешла в Apple, совместными усилиями была создана новая система — Mac OS X. Позднее ее переименовали в OS X, а затем в macOS (отдел маркетинга в Apple никогда не сидит сложа руки). Технически Mac OS X основана на NeXTSTEP, однако ее интерфейс многое почерпнул из классической Mac OS.
MacOS X 10.1 Cheetah
В переходный период «макинтоши» поддерживали как классическую Mac OS, так и Mac OS X. С 2002 года все компьютеры Apple стали выходить с предустановленной Mac OS X, а Mac OS 9 еще несколько лет можно было запускать в режиме совместимости.
Ядро XNU
В основе macOS, как и в основе любой другой ОС, лежит ядро. Оно отвечает за выделение процессорного времени, управление оперативной памятью и кешем, взаимодействием с устройствами и сетью. В то же время оно обрабатывает системные вызовы приложений и обеспечивает взаимодействие процессов.
Современная macOS работает на ядре XNU, которое пришло из NeXTSTEP. За основу его кода в свое время был взят проект Match — ответвление от ядра FreeBSD.
XNU означает X is Not Unix, «X — не Unix». Эта расшифровка — давно утерявший актуальность программистский юмор: macOS все же по большому счету считается одной из разновидностей Unix. Однако XNU не имеет бинарной совместимости с FreeBSD, то есть программы для FreeBSD в macOS нельзя запустить без изменений и перекомпиляции.
Ядро XNU — гибридное. Это значит, что в отличие от микроядер оно может быть дополнено расширениями, но при этом не является монолитным, как ядро Linux, где все функции собраны в один гигантский бинарный файл.
До macOS 10.15 основным способом расширения ядра были модули kext. Поскольку «кексты» работают в пространстве ядра, сбои в них могут приводить к нестабильной работе компьютера. К тому же они открывали большие возможности для недобросовестных разработчиков.
Сейчас «кексты» считаются устаревшим методом, и со временем он будет отключен. Вместо этого в Apple предлагают разработчикам использовать фреймворки DriverKit и SystemExtension, которые позволяют создавать драйверы и расширения, работающие в пространстве пользователя.
Архитектура macOS
Darwin
Операционная система — это не только ядро. Вместе с Match в NeXTSTEP, а затем и в Mac OS X перекочевал набор библиотек и исполняемых файлов, которые вместе с XNU обеспечивают поддержку POSIX — Portable Operating System Interface, «портируемого интерфейса операционной системы». Это стандарт, которому в той или иной мере соответствуют все Unix-образные операционные системы и который обеспечивает низкоуровневую совместимость между ними.
В macOS этот слой называется Darwin и по сути представляет собой самостоятельную операционную систему. Сюда не входят графическая среда и библиотеки, нужные для работы оконных приложений, но входят ядро, драйверы, сетевой стек, набор системных и пользовательских утилит командной строки, а также система запуска служб и приложений launchd.
При желании Darwin можно установить как самостоятельную минималистичную ОС с текстовым интерпретатором команд. Код Darwin с самого начала был открыт, однако со временем в нем появилось множество закрытых компонентов, включая специфичные для «маков» драйверы.
Последние версии Darwin уже было невозможно собрать и заставить работать без средств, доступных только программистам Apple. Получилось, что публикация исходников в таком виде стала не нужна ни Apple, ни сообществу, и ее просто прекратили. Код XNU тем временем по‑прежнему
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Сейчас силами сообщества поддерживается проект
Чтобы увидеть нужно авторизоваться или зарегистрироваться.
Графическая система
Графический слой в macOS обычно называют Quartz, хотя подразумевается под этим набор библиотек Core Graphics. Две его важнейшие части — это Quartz 2D и Quartz Compositor.
Quartz 2D
Quartz 2D отвечает за все, что связано с двумерной графикой. В его основные задачи входит отрисовка текста и превращение графических примитивов, описанных в формате PostScript, в растровые изображения, которые затем передаются в Quartz Compositor.
Формат PostScript изначально был разработан в компании Adobe и предназначался для вывода документов на печать. Также PostScript лег в основу формата PDF и, что важно для нас, использовался в компьютерах NeXT для описания выводимой на экран графики. Оттуда он и пришел в macOS. Благодаря такому близкому родству PostScript и PDF «маки» и айфоны прекрасно справляются с отображением PDF без установки Adobe Acrobat или другого просмотрщика.
Quartz Compositor
Quartz Compositor одновременно играет роль графического сервера и композитного оконного менеджера. С одной стороны, он получает от приложений растровые изображения их окон и собирает из них картинку для отображения на экране (это и есть композиция), с другой — обрабатывает события, связанные с устройствами ввода: клики мышью и нажатия на кнопки клавиатуры. Quartz Compositor определяет, к какому окну относятся события, и пересылает их соответствующим приложениям.
Поскольку Quartz Compositor — это еще и оконный менеджер, в его задачи входит отрисовка пользовательского интерфейса. Это шрифты, меню, рамки окон, панели и прочие виджеты, которые коллективно называются интерфейсом Aqua. В ранних версиях Mac OS X некоторые его элементы действительно походили на капли воды, но с тех пор дизайн многократно меняли, и теперь это просто название.
XQuartz
Если порыться в средствах разработки для macOS, то можно откопать еще один интересный артефакт — XQuartz. Это реализация оконного сервера XWindow из Unix. Долгое время его свободная реализация X.Org входила в каждый дистрибутив Linux и была стандартом де‑факто. Сейчас старые и не очень добрые «иксы» постепенно заменяют системами вроде Wayland и Mir, в чем‑то схожими по устройству с маковским Quartz Compositor.
Что до XQuartz, то он явно создавался в Apple с мыслью, что неплохо бы иметь возможность запускать графические приложения для Unix и Linux. Однако нужда в этом оказалась не так велика, и никакого развития XQuartz не получил. В Linux большинство графических программ опирается на библиотеки сред Gnome и KDE, а их портирование на «мак» в планы Apple не входило. В итоге XQuartz может пригодиться только для самых простых графических программ, которые общаются с XWindow напрямую.
APFS
До выхода macOS 10.13 High Sierra файловой системой по умолчанию на любом «маке» была HFS+, унаследованная еще от классической Mac OS. В свое время она считалась передовой — у HFS+, к примеру, есть поддержка Unicode и журналирования (журнал ФС — история операций, которая помогает сохранить целостность данных в случае сбоя или отключения питания). Однако исходная HFS проектировалась еще в восьмидесятых годах и, несмотря на апгрейд до HFS+ в конце девяностых, не поддерживала многие важные новшества.
В Apple разработали и в 2017 году успешно внедрили в iOS новую файловую систему, названную APFS — Apple File System. Она обладает множеством достоинств, которые пришлись кстати не только на айфонах и айпадах, но и на «маке».
APFS изначально спроектирована с учетом использования твердотельных накопителей (SSD), в частности поддерживает команду TRIM. Также она может адресовать файлы с использованием 64-разрядных идентификаторов (вместо 32-разрядных в HFS+), поддерживает разреженные файлы (если файл пустой, система не занимает пространство нулями, а сжимает их), может шифровать данные на уровне файлов и каталогов (а не только весь диск) и позволяет открывать сетевой доступ к дискам с помощью разных сетевых протоколов.
APFS дает прирост в скорости, заметный в повседневной работе. Например, гораздо быстрее, чем на HFS+, подсчитывается размер каталогов и копируются файлы.
Наконец, самая заметная фича APFS — это возможность не задавать фиксированный размер логических томов. Они разделяют общее физическое пространство, и каждый из них будет занимать столько, сколько занимают его данные.
Спецификации APFS открыты в достаточной мере, чтобы создавать драйверы «только для чтения». Однако уже существуют экспериментальные драйверы для Linux, работающие с APFS в режиме «чтение и запись».
Важная особенность APFS, о которой стоит знать пользователю, — это нечувствительность к регистру. То есть FILE, file, FiLe и прочие подобные вариации — это с точки зрения APFS ровно одно и то же. Чувствительность к регистру можно включить при форматировании тома, но по умолчанию на всех «маках» эта настройка выключена.
iCloud
Еще с начала двухтысячных в Apple экспериментировали с поддержкой собственных облачных сервисов на уровне macOS. iCloud предшествовали iTools, .Mac и MobileMe. Названия менялись, но основная суть всегда сводилась к синхронизации данных между устройствами.
Здесь мы не будем погружаться в устройство iCloud. Важно знать лишь то, что его использование опционально, но значительно упрощает синхронизацию между компьютерами и гаджетами Apple.
Наиболее заметный и важный компонент iCloud — это iCloud Drive, куда пользователь может сохранять документы, после чего система будет автоматически следить за их состоянием и передавать изменения в облако. Помимо этого, существует фреймворк CloudKit, который разработчики используют для синхронизации настроек и прочих отличных от документов данных.
iCloud тесно связан с учетной записью Apple ID, однако это не одно и то же. Строго говоря, иметь Apple ID, чтобы пользоваться «маком», необязательно, но без этой учетки нельзя будет скачивать приложения из App Store. С Apple ID пользователь получает небольшое бесплатное хранилище в iCloud, на данный момент — 5 Гбайт.
Защита
SIP
Раньше на «маках» пользователь с привилегиями администратора имел все те же возможности, что и root — «корневой» пользователь в Unix. Подтвердив команду вводом пароля, он мог, к примеру, изменять или удалять любые файлы в системе.
Это оставляло лазейку для вредоносного ПО: если убаюкать осторожность пользователя и заставить его ввести пароль, то дальше можно скрытно творить что угодно.
В OS X 10.11 El Capitan появилась система System Integrity Protection (SIP) — «защита целостности системы». На практике это реализованный на уровне ядра целый комплекс мер, который не дает затрагивать работу системы даже администратору.
Системные файлы и каталоги теперь под защитой — это реализовано как специальный расширенный атрибут у файла; запрещена инъекция кода в процессы, причем не только системные, но и другие; запрещена загрузка в ядро неподписанных расширений.
Конечно, бывают случаи, когда SIP мешает сделать что‑то нужное. Как любитель покопаться в системе, я спотыкаюсь об эту защиту регулярно с момента ее появления.
Отключить SIP возможно. Для этого нужно перезагрузить компьютер в режиме восстановления, открыть терминал и использовать утилиту csrutil. Затем еще одна перезагрузка, и еще две — чтобы потом включить SIP обратно (что все же рекомендуется делать).
Gatekeeper
Еще один механизм, призванный защитить «мак» от вирусов, называется Gatekeeper. Это система, которая, опираясь на базы данных Apple, распознает потенциально вредоносные файлы и препятствует их запуску.
Работает это вот как. Каждый скачанный файл помещается в карантин, получая соответствующий расширенный атрибут. При попытке запустить исполняемый файл, стоящий на карантине, система проверяет, не находится ли он в черном списке, есть ли у него подпись сертифицированного разработчика, и если да, то не изменено ли содержимое файла.
В зависимости от результатов проверки система либо сразу запускает файл, либо отказывается это делать. Если проблема в отсутствии подписи, то это легко обойти — достаточно открыть файл через контекстное меню, а не двойным кликом.
Gatekeeper при желании можно полностью отключить одной командой, причем не требуется даже перезагрузка. Хоть это и облегчит жизнь, делать так не рекомендуется. Программы просто так не попадают в черные списки!
Secure Enclave
В «маках» с чипами серии M либо с процессорами Intel и дополнительными чипами серии T используется специальное аппаратное решение для надежного хранения и подтверждения ключей шифрования и биометрической информации — Secure Enclave.
Пользователю Secure Enclave не виден, взаимодействовать с ним напрямую никак нельзя. Зато система общается с ним каждый раз, когда ты подтверждаешь платеж или ввод пароля отпечатком пальца или разблокируешь компьютер при помощи Apple Watch.
App Sandbox
Отдельно от SIP и Gatekeeper существует механизм App Sandbox, который контролирует доступ сторонних приложений к пользовательским и системным файлам и папкам. Точнее, позволяет разработчикам самим ограничивать возможности приложений! Для программ, распространяемых через App Store, это необходимое условие, для загружаемых другими способами — опциональное.
Настройка App Sandbox в Xcode
Подключив App Sandbox в Xcode при сборке проекта, разработчик выбирает, какие функции могут понадобиться приложению: доступ к определенным папкам, сетевым протоколам, возможностям вроде Apple Pay. Приложение при работе будет просить пользователя подтвердить, что он разрешает использовать тот или иной ресурс.
FairPlay
Помимо механизмов, призванных защитить данные пользователей, в macOS есть и одна система, защищающая данные от пользователей. Речь о FairPlay — местной реализации цифровой защиты авторских прав (DRM). Это, пожалуй, единственное серьезное ограничение, намертво зашитое в macOS.
FairPlay может распространяться как на отдельные файлы в форматах MP4 (видео) и AAC (звук), так и на потоковое вещание (FairPlay Streaming). В частности, эту защиту используют в Netflix.
FairPlay жестко ограничивает копирование защищенной информации, поэтому если попытаться сделать скриншот фильма из Netflix или Apple TV, то получится только черный прямоугольник. Записать видео или захватить аудио из защищенного источника тоже не выйдет без дополнительных ухищрений.
Программирование
Даже при беглом знакомстве с macOS легко заметить, что большинство программ здесь имеют единый визуальный стиль, стандартные диалоги открытия и сохранения файлов, выбора шрифтов и цвета и прочие общие элементы. Все это — благодаря тому, что они основаны на стандартных объектных библиотеках, реализующих интерфейс Aqua.
Такой подход не только обеспечивает консистентный стиль и предсказуемое поведение программ, но еще и экономит оперативную память, а также позволяет Apple в любой момент вносить разного рода изменения. К примеру, когда в macOS 10.14 Mojave появился темный режим, его внедрение потребовало минимум усилий от разработчиков программ.
Однако говорить о том, что в macOS есть только одна оконная библиотека, в наше время не приходится. В реальности фреймворков несколько: какие‑то из них оставлены для совместимости, другие пока носят экспериментальный характер.
Objective-C
Традиционный и до сих пор самый надежный способ разработки программ для macOS — это использование языка Objective-C и фреймворка Cocoa, известного также как AppKit (или NSApp, если заглянуть во времена NeXTSTEP).
Objective-C — это высокоуровневый объектно ориентированный язык с поддержкой разных видов типизации. Он унаследовал идеи Smalltalk (объекты и сообщения) и C (базовый синтаксис, прямое управление памятью). Абстрактно его можно считать эппловским аналогом C++ или в какой‑то мере — C# и Java.
AppKit
Знания одного только Objective-C недостаточно для разработки маковских приложений. Гораздо больший пласт — это разнообразные API и фреймворки, которые поставляются с системой. Любой программист практически сразу же столкнется с Foundation Kit, где реализованы базовые объекты и структуры, а при написании графических приложений — с AppKit.
AppKit реализует привычную в наше время схему MVC, то есть «модель — вид — контроллер», где модель отвечает за структуру данных, вид — за их отображение, а контроллер — за реакцию на действия пользователя. С помощью AppKit описывается внешний вид и поведение всех окон, меню, кнопок, текстовых полей и других элементов интерфейса.
Для разработки программ на основе AppKit часто применяется Interface Builder, входящий в Xcode. Это визуальное средство разработки интерфейсов, которое позволяет собрать приложение из составных частей, как в детском конструкторе (если ты сразу вспомнил Visual Basic, Delphi, C++Builder или Qt Designer, то это верная аналогия). Разработчики нередко критикуют этот подход: вместо навыков программирования он требует именно умения обращаться с Interface Builder.
Swift
Objective-C служил NeXT и Apple верой и правдой с восьмидесятых годов и неплохо справлялся со своими задачами. Однако за все это время он очень мало изменился и лишен многих возможностей, привычных современным программистам.
В 2014 году на конференции WWDC анонсировали новый язык для написания маковских приложений — Swift. За его созданием стоит Крис Латтнер, известный как один из основных разработчиков универсального компилятора LLVM.
Как и Objective-C, Swift — компилируемый язык, нацеленный на разработку стабильных и производительных приложений. Он тоже использует схожий с С синтаксис, однако унаследовал некоторые парадигмы от скриптовых языков вроде JavaScript и Python.
По своим возможностям Swift уже способен полностью заменить Objective-C и превосходит его в производительности. Однако базовые фреймворки еще не все переписаны на Swift, поэтому пока что разработчикам сложных приложений приходится регулярно сталкиваться с Objective-C и его наследием.
SwiftUI
NSApp/AppKit разрабатывался вместе с Objective-C и с учетом его возможностей. И хоть из Swift и можно обращаться к нему, аналогичной парой для нового языка должен стать интерфейс SwiftUI.
За основу SwiftUI взяли UIKit (CocoaTouch) — более новую модификацию AppKit, разработанную для iOS. SwiftUI должен заменить оба этих фреймворка и позволяет писать приложения, которые будут работать на всех платформах Apple: часах, телефонах, планшетах, компьютерах и телеприставках.
Главная фишка SwiftUI — это возможность описывать приложения в декларативном стиле. То есть вместо того, чтобы команда за командой перечислять, какие элементы интерфейса куда поместить, достаточно описать, как будет выглядеть приложение, а промежуточные шаги и раскладку SwiftUI возьмет на себя. Interface Builder при этом уже не нужен.
SwiftUI позволяет разработчикам экономить массу усилий, когда задумка совпадает с доступными возможностями. В противном же случае SwiftUI может стать серьезной преградой. Возможно, с развитием SwiftUI станет легче, но пока что ситуации, о которых в Apple не подумали заранее, встречаются на каждом шагу и вынуждают разработчика возвращаться к AppKit — благо смешивать его со SwiftUI никто не мешает.
Catalyst
И еще один современный эппловский фреймворк, о котором стоит упомянуть, называется Catalyst. Катализировать он призван портирование на «мак» приложений, написанных для iOS на UIKit. По заверениям Apple, создать десктопную программу из мобильной можно буквально за один день.
В доказательство на презентации показали официальный клиент Twitter, портированный с iOS. И... им действительно при желании можно пользоваться. Однако по поведению он заметно отличается от «родных» маковских приложений.
Клиент Twitter на Catalyst
Catalyst — это переходный фреймворк, и постепенно его должен полностью вытеснить универсальный SwiftUI. Собственно, приложений, перенесенных на «мак» при помощи Catalyst, оказалось немного, и, скорее всего, его отправят на пенсию даже раньше времени.
Carbon
История с Catalyst немало напоминает другой эпизод из жизни Apple. Когда Mac OS X была совсем новой и нуждалась в приложениях, в Apple решили помочь разработчикам программ для классической Mac OS переехать на новую систему.
Так родился фреймворк Carbon, предоставляющий поддержку старых API, но для пользователя рисующий все тот же интерфейс Aqua. Carbon оказался серьезным подспорьем для разработчиков, и его, в частности, использовали в продуктах Adobe — вплоть до выхода Creative Suite 5.
WebObjects
Наконец, тебе еще кое‑где может встретиться слово WebObjects. Это название эппловского объектно ориентированного веб‑фреймворка, созданного на заре интернета и пришедшего еще из NeXT. По своим возможностям он серьезно опередил время, но использовать «мак» в качестве веб‑сервера было странной идеей что тогда, что сейчас. Единственная компания, которая до сих пор применяет WebObjects, — это сама Apple. На этой технологии частично работают App Store и Apple Music.
Apple Silicon
В Apple очень серьезно относятся к тому, чтобы иметь не только собственный софт, но и свое железо, идеально подходящее к софту. Выбор центрального процессора здесь играет важнейшую стратегическую роль. В Apple уже трижды меняли тип CPU «макинтошей»: Motorola 68000 (32-разрядный CISC) на PowerPC (32- и 64-разрядный RISC), затем на Intel (32- и 64-разрядный CISC) и в 2020 году — на ARM (64-разрядный RISC).
К моменту последнего перехода в Apple уже снабжали iPhone, iPad и прочие гаджеты своими системами на чипе серии A на основе ARM. Так что перевод «маков» на ту же аппаратную платформу не стал неожиданностью. Этого события ждали давно, и если что‑то и удивило, так это его почти полная безболезненность и даже невидимость изменений для пользователей.
«Макинтоши» на Apple Silicon (так официально называется эппловская разновидность ARM) не потеряли совместимость почти ни с одним приложением — в первую очередь за счет системы бинарной трансляции, известной как Rosetta 2.
Rosetta 2 при первом запуске исполняемого файла, предназначенного для «маков» с чипом Intel, переводит инструкции x86 в инструкции ARM, то есть производит «компиляцию перед использованием» — AOT. При необходимости доступна и динамическая компиляция — JIT.
Все это позволяет запускать те же приложения, что и раньше, даже если их разработчик не позаботился о пересборке под новую архитектуру. Причем зачастую производительность не только не уступает производительности «маков» с чипами x86, но и превосходит ее!
Свою роль в том, что переход на Apple Silicon был легким и незаметным, сыграла и та подготовка, которую начали за много лет до решающего момента. В Apple очень ловко убрали поддержку старых 32-разрядных приложений за год до анонса Apple Silicon — в операционной системе macOS 10.15 Catalina. Rosetta 2 не позволяет запускать такие программы, и лишний год дал сторонним разработчикам время подготовиться.
Что до приложений и фреймворков, поставляемых с macOS, то в них поддержку 64-разрядных архитектур начали добавлять еще c 2009 года, когда вышла Mac OS X 10.6 Snow Leopard. Библиотеки Carbon, не имевшие 64-разрядной версии, перестали поддерживать в 2012 году в OS X 10.8 Mountain Lion.
Такие планомерные уборки в чулане позволяют Apple с легкостью менять аппаратные платформы и поддерживать «легаси» только в переходные периоды.
Прочее
Помимо перечисленного, в macOS есть еще несколько компонентов, которые роднят эту ОС с миром Linux. К примеру, это система печати CUPS и сервер VNC, используемый для шейринга экрана. И конечно, командная оболочка Bash, стандартная для любого Linux (в последних версиях macOS по умолчанию установлен еще и ZSH).
Долгое время с macOS поставлялись интерпретаторы языков Python, Perl и PHP. В macOS 12 Monterey убрали Python 2.7 и PHP, оставив только Perl, однако вместе с Xcode или Command Line Tools for Xcode устанавливается Python 3.
Причина «уборки» — в том, что нужны эти языки в основном программистам и энтузиастам, причем зачастую в гораздо более новой версии, чем есть в системе. А раз ставить новую все равно придется, то старая будет только мешать.
Выводы
Итак, думаю, ты уже понял, что macOS — это не Linux, хотя и гораздо более близкая к нему система, чем, например, Windows.
Здесь используются свои ядро, графическая система, оконная среда и графические фреймворки. Поддержка стандарта POSIX обеспечивает возможность портировать на macOS Unix-совместимые программы. Некоторые из них уже поставляются вместе с системой.
Что до слухов о том, насколько macOS закрыта, то они сильно преувеличены. «Закрыта» она не в большей мере, чем Windows, а местами в гораздо меньшей. С другой стороны, понятно, что это не Linux, где почти каждый компонент есть в нескольких вариантах и при желании можно сделать новый форк любого из них. И конечно, широко известно, что macOS официально нельзя установить на другие компьютеры, кроме «маков».
Критика этих фактов каким‑то образом переродилась в слухи о том, что в macOS нельзя слушать музыку, если ты не купил ее в iTunes Store, или запустить скачанные из интернета приложения. Все это, конечно, полнейшая ерунда.
Существует опасение, что macOS постепенно объединят с куда более закрытыми iOS и iPad OS. Чтобы понять стратегию Apple в этом плане, достаточно взглянуть на SwiftUI. Он позволяет писать единые приложения, имеющие разный внешний вид и поведение на разных устройствах с учетом их размера, возможностей и схемы использования. Очевидно, что и дальше в Apple будут не изничтожать, а скорее подчеркивать отличия между разными видами компьютеров.
Так что объединение, с одной стороны, вряд ли произойдет, с другой — уже вовсю происходит. Просто оно работает совсем на другом уровне: унифицируют внутренние системы (например, APFS), создают общий базис для разработки приложений (SwiftUI), в macOS постепенно добавляют некоторые новые фичи из iOS (и наоборот — iOS и iPad OS получают кое‑что с «мака»).
Уже много лет macOS — отличный выбор как для повседневной работы, так и для творчества и для многих видов разработки. Непрерывная оптимизация и чистка, практикуемые в Apple, позволяют сохранить производительность и внедрять новшества на всех уровнях системы. К тому же в macOS есть огромный потенциал для автоматизации, о котором мы уже не раз писали и еще вернемся к нему в будущем.
