Статья Терминал macOS и Linux: В чем разница?

samhainhf · Вчера в 04:42

Если ты открыл эту статью, значит, ты уже переступил порог. Ты не из тех, кто видит в терминале чёрный ящик со страшными зелёными буквами. Для тебя это - рабочая среда. Воздух, которым дышит твоя машина. Но в какой-то момент ты столкнулся с тихой, почти незаметной шизофренией мира.

Ты садишься за терминал на своём макбуке, всё привычно и гладко. ls показывает файлы, grep ищет, ps перечисляет процессы. Затем ты подключаешься к серверу - чистому, аскетичному Linux - и твой пальцевой мышечный память начинает давать сбои. Скрипт, написанный на Mac, отказывается работать. Любимый трюк с флагом -G у ls вызывает ошибку. Ты лезешь в man и видишь, что опции - другие. Мир, который должен быть единым в своей текстовой простоте, оказывается расколотым.

Это не баг. Это - следствие.

Терминал macOS - это не просто доступ к командной строке. Это цивилизованный шлюз в недра Darwin, гибридной операционной системы с микроядром Mach и сердцем, доставшимся в наследство от BSD. Он полирован, предсказуем и живёт по строгим правилам дома, в который ты пришёл. Его команды - это BSD-версии, со своим специфичным синтаксисом. Его структура файлов (/Library, /System, /Users) - это архитектура, где пользователь - гость. Его сила - в бесшовной интеграции с целым миром проприетарных сервисов Apple, от pbcopy до launchd. Его слабость - в этой же закрытости. Ты можешь многое, но только в рамках, очерченных купертино.

Терминал Linux - это не программа, а состояние системы. Это первозданный интерфейс к монолитному ядру, окружённому морем утилит GNU. Здесь нет одного «правильного» терминала - есть десятки эмуляторов. Нет одной оболочки - есть выбор между bash, zsh, fish. Нет одного пути - есть священный стандарт FHS (/bin, /home, /etc). Это мир, где пакетный менеджер (apt, pacman, dnf) - верховный правитель, контролирующий всё от ядра до текстового редактора. Его сила - в абсолютной прозрачности и тотальном контроле. Его слабость - в ответственности, которую этот контроль на тебя возлагает. Система не поможет - она предоставит тебе все инструменты, чтобы ты помог себе сам.

Здесь мы не будем искать победителя. Мы заложим основу для понимания, что каждое несоответствие в синтаксисе, каждый различиный путь, каждый другой инструмент - это не случайность. Это логичное следствие выбора, сделанного десятилетия назад: пути Apple, купившей NeXTSTEP и построившей на её основе элегантную крепость, и пути сообщества, взявшего ядро Линуса и инструменты GNU, чтобы построить бесконечный, изменяемый город.

Ты узнаешь, почему sed ведёт себя по-разному, почему скрипты ломаются при переносе и почему «работает у меня на машине» - это не шутка, а диагноз. Мы снимем слой за слоем, от пользовательской оболочки до системных демонов, чтобы понять не что отличается, а почему это отличие фундаментально.

Внешний слой: Оболочка и ритуал входа

Когда пальцы впервые касаются клавиш в чёрном окне, происходит первичный ритуал инициализации. Это момент, где системы не просто отличаются - они заявляют о своих фундаментальных ценностях. Разговор об оболочке (shell) - это не спор о синтаксисе, это спор о том, кто ты: пользователь продукта или хозяин инструмента.

Оболочка: Полированная среда против гибкого скелета

macOS: Культ завершённого опыта с ZSH

В 2019 году с выпуском Catalina Apple совершила не просто техническое обновление, а культурный переворот. Смена оболочки по умолчанию с bash на Z Shell (zsh) была посланием: «Мы хотим, чтобы ваша командная строка была не менее удобной и продуманной, чем графический интерфейс».

zsh на macOS - это максимализм и предсказуемое удобство из коробки. Её не выбирали за скорость исполнения циклов. Её выбрали за подход к пользователю.

Контекстно-зависимое автодополнение (Completion System): Это не просто подстановка имён файлов. Zsh анализирует команду. Начал вводить git checkout ma - она предложит master и другие ветки из твоего репозитория. Ввёл ssh - и нажал Tab - увидишь не просто список файлов, а расшифровку всех флагов ssh. Она «понимает» аргументы сотен команд.
Исправление опечаток и глобальные алиасы: Опечатался в cd /usr/loca/bin? Zsh вежливо спросит: «Вы имели в виду /usr/local/bin?». Можно согласиться нажатием Enter. Плагины вроде Oh My Zsh превращают это в искусство: короткий алиас gco разворачивается в git checkout, gcm - в git commit -m.
Тематизация и визуальный feedback: Через фреймворки вроде Oh My Zsh или Prezto терминал становится визуальной средой. Цвета показывают состояние git-репозитория (есть ли изменения, какая ветка), значок в приглашении меняется при ошибке последней команды. Это создаёт плотный информационный слой без лишних запросов.
Глобальные настройки без боли: Файл ~/.zshrc становится центром управления. Но сообщество создало целую индустрию плагинов, которые одним добавлением строки дают поддержку Node.js (nvm), Python (pyenv), Docker и десятков других инструментов.

Обратная сторона медали - баш-наследие. В macOS всё ещё есть bash. Но это ископаемая версия 3.2.57(1), намертво вмороженная в систему. Apple остановила его развитие на моменте до перехода на лицензию GPLv3, которую она не приемлет. Это не просто старая версия - это символ. Символ того, что Apple оставляет тебе путь к отступлению в прошлое, но будущее строится на её условиях, с её инструментами.

Linux: Модульный мир, где BASH - это скелет, а не кожа

В дистрибутиве Linux оболочка - это не часть «опыта», а базовый системный компонент, такой же, как ядро или библиотека C. Его можно и нужно менять.

В 99% случаев, когда ты читаешь инструкцию «запусти в терминале», подразумевается GNU Bash. Это общий язык. Его сила в предсказуемости, широкой документации и том, что он установлен везде, от крошечного Alpine до корпоративного RHEL. Его .bashrc и .bash_profile - это священные тексты, которые кочуют с админами десятилетиями.

Но истинная мощь Linux в том, что ты не привязан к bash. Установка и смена оболочки - дело двух команд.

Zsh: Ту же самую zsh можно поставить и в Linux. Но здесь она - не дар свыше, а твой сознательный выбор. Ты сам соберёшь её из пакетов, сам настроится плагинами. Она не интегрирована в системные сервисы, как в macOS, но ты контролируешь каждый аспект.
Fish (Friendly Interactive Shell): Популярная альтернатива, которая ставит удобство выше совместимости. У неё умное автодополнение, синтаксический хайлайтинг прямо по мере ввода, но свой, не всегда bash-совместимый синтаксис скриптов. Это выбор для тех, кто живёт в интерактивном режиме, а не пишет переносимые скрипты.
Dash: Минималистичная, быстрая оболочка, часто используемая как /bin/sh для исполнения системных скриптов, где скорость запуска критична. Это демонстрирует принцип «правильный инструмент для задачи».

Суть различия: В macOS оболочка - это продуманная пользовательская среда, которую Apple предоставляет как часть единого, качественного продукта. Ты настраиваешь её в рамках дозволенного. В Linux оболочка - это инструментарий и интерпретатор, который ты выбираешь и собираешь под свои нужды, часто жертвуя унификацией ради специфичных преимуществ.

Системные утилиты: Великий раскол GNU и BSD

Это точка, где теория сталкивается с практикой жестоко и беспощадно. Твои мышечные памяти становятся врагами.

Когда ты вводишь ls, grep или sed, ты обращаешься не к абстрактной «команде UNIX», а к конкретной реализации. macOS использует утилиты, унаследованные из BSD (Berkeley Software Distribution). Linux использует утилиты от проекта GNU. Их разделяют десятилетия разной эволюции.

macOS (BSD-утилиты): Краткость, лаконичность и свои правила

Философия BSD-утилит исторически тяготеет к минимализму и краткости флагов, иногда в ущерб единообразию.

ls: Цвета и форматирование. Для цветного вывода используется ls -G. В Linux - ls --color=auto. Флаг -h (human-readable) для размеров работает, но -l (long listing) выводит информацию в немного другом формате (права доступа, количество ссылок). Чтобы показать все файлы, включая . и .., нужно ls -a, а чтобы скрыть их, но показать остальные скрытые - ls -A. В GNU ls это просто -A.
grep: Мир без Perl. Самая частая проблема. В Linux есть мощный флаг -P для Perl-совместимых регулярных выражений (\d для цифр, \s для пробелов). В BSD grep его нет. Только базовые (-G) и расширенные (-E) выражения. Поиск всех строк с цифрами: не grep -P '\d+', а grep -E '[0-9]+' или через POSIX-классы: grep '[[:digit:]]+'. Также флаг -r для рекурсивного поиска может вести себя иначе, чем GNU-аналог.
sed: Проклятие обратного слэша. Классический камень преткновения. Команда инлайнового редактирования файла в GNU: sed -i 's/foo/bar/g' file.txt. В BSD: sed -i '' 's/foo/bar/g' file.txt. BSD sed трактует следующий после -i аргумент как суффикс для резервной копии. Пустые кавычки '' говорят: «не создавай бэкап». Без них он попытается использовать 's/foo/bar/g' как суффикс для имени бэкапа и сломается. Это ловушка, в которую попадают все.
date: Другая логика времени. Получить unixtime: везде date +%s. Но преобразовать unixtime обратно в читаемую дату? В Linux: date -d @1640995200. В macOS флага -d нет. Вместо этого: date -r 1640995200. Абсолютно другой подход.
ps: Без дефиса в связке. Для просмотра всех процессов в Linux привычно ps aux (с дефисом у некоторых версий). В macOS тоже работает ps aux, но это исторический синтаксис BSD. Попытка использовать некоторые GNU-флаги из ps вызовет ошибку.

Linux (GNU coreutils): Богатство, единообразие и самодокументирование

Утилиты GNU создавались с идеей предоставить максимум возможностей и строго следовать своим же стандартам.

Длинные, мнемонические флаги: Помимо коротких -a, -l, есть длинные --all, --long. Флаг --help есть у почти каждой команды - это самодокументируемость. ls --color=auto --human-readable --group-directories-first - команда читается как предложение.
Предсказуемость и расширения: Поведение утилит чётко описано и соответствует ожиданиям, заданным большинством современных руководств. Наличие флагов вроде grep -P (Perl regex), grep -z (работа с null-байтами), sed --in-place (альтернатива -i) даёт огромную мощь.
Единая экосистема: Все утилиты следуют одним и тем же соглашениям об обработке аргументов, выводе ошибок, что создаёт ощущение цельности системы.

Практическое следствие катастрофично: Скрипт на bash, использующий GNU-специфичные возможности (sed -i, grep -P, date -d), молча сломается при запуске на macOS. Это не баг, это - архитектурная особенность. Обратная совместимость (из macOS в Linux) чуть лучше, так как GNU утилиты часто понимают старые BSD-флаги, но не наоборот.

Файловая иерархия: Чужая архитектура против открытого стандарта

То, как организованы файлы, определяет, как ты мыслишь систему.

macOS: Архитектура крепости, унаследованная от NeXTSTEP

Файловая система macOS - это исторический памятник.

/Users вместо /home: Не просто переименование. Это наследие OpenStep и NeXTSTEP. Твой дом - не home, а Users. Это сразу сигнализирует: «Ты не в классическом UNIX».

Жёсткое разделение:

/System: Святая святых. Защищена System Integrity Protection (SIP). Даже root не может сюда писать. Здесь живёт чистая ОС от Apple.
/Library и ~/Library: Глобальные и пользовательские настройки, ресурсы, плагины. Аналог /etc и ~/.config, но структурированный иначе, часто с .plist файлами.
/Applications и ~/Applications: GUI-приложения. В Linux приложение может раскидать свои файлы по /usr/bin, /usr/share, /etc. В macOS .app - это папка (Bundle), содержащая всё внутри себя, что живёт в этой директории.
/Volumes: Точки монтирования внешних накопителей и образов.

Библиотеки и фреймворки: Вместо стандартных /usr/lib и /usr/include, библиотеки часто упакованы в .framework или .dylib внутри этих самых Bundles. Системные фреймворки лежат в /System/Library/Frameworks. Это мир, ориентированный на изоляцию приложений и удобство их распространения (всё в одной папке), а не на системную целостность.

Linux: Священный стандарт FHS (Filesystem Hierarchy Standard)

Это конституция дистрибутива Linux. Её знание - обязанность.

/home/username: Каноничный домашний каталог. Здесь лежат твои данные, настройки (часто скрытые файлы вроде .bashrc), кэши.

Чёткое разделение ролей:

/bin, /sbin: Базовые команды для загрузки и восстановления (до монтирования /usr).
/usr/bin, /usr/sbin: Основные пользовательские и системные утилиты.
/usr/local/bin: Место для софта, установленного вручную, в обход пакетного менеджера. Прямая аналогия с тем, куда ставит Homebrew, но это - часть стандарта.
/etc: Конфигурационные файлы системы и приложений. Центр управления.
/var: Изменяющиеся данные: логи (/var/log), кэши, очереди, базы данных.
/tmp: Временные файлы (часто очищаемые при перезагрузке).

Единые пути для разработки: Заголовочные файлы - в /usr/include, библиотеки - в /usr/lib, общие данные - в /usr/share. Пакетный менеджер знает это и соблюдает. Это система, созданная для управления и сборки, где каждый компонент знает своё место.

Открывая терминал macOS, ты входишь в отполированный, дизайнерский интерфейс к мощной UNIX-основе. Тебе дают удобные, но нестандартные инструменты (zsh, BSD-утилиты) и ведут по пути, проложенному Apple (/Users, /Library). Ты - квалифицированный пользователь в прекрасно обустроенном парке, где можно многое, но ландшафтный дизайн менять нельзя.

Открывая терминал Linux, ты стоишь перед открытой мастерской со стандартными чертежами (FHS) и набором инструментов (GNU coreutils). Ты можешь выбрать любой инструмент (bash, zsh, fish), но должен знать, как им пользоваться. Ты - архитектор и строитель в одном лице, отвечающий за целостность и эффективность всей конструкции.

Это фундамент. На нём строится всё остальное: управление пакетами, службами, ядром. И именно этот фундамент объясняет, почему «работает на моей машине» - не шутка, а диагноз состояния индустрии.

Средний слой: Пакетный менеджер - сердце и пропасть между мирами

Если оболочка - это язык, на котором ты говоришь с системой, то пакетный менеджер - это её экономика, политика и система кровообращения. Именно здесь пропасть между macOS и Linux превращается в конкретные, ежедневные инженерные проблемы. Это не сравнение двух инструментов - это столкновение двух вселенных, где само понятие «установки программы» имеет противоположный смысл.

macOS

Исторический вакуум: Почему его не было изначально
В macOS никогда не было нативного пакетного менеджера командной строки. Это не случайность, а следствие оригинальной философии Apple, унаследованной от классической Mac OS (до 2001 года):

Модель «приложения в папке»: Программа - это .app bundle, самодостаточная папка, которую пользователь перетаскивает в /Applications. Всё её содержимое - внутри. Нет нужды в системном менеджере зависимостей.
App Store как «официальный» источник: С появлением Mac App Store (2011) Apple создала централизованный, контролируемый, но сугубо графический магазин с моделями sandbox и подписи. Командная строка осталась за бортом этой парадигмы.

В результате для всего, что не упаковано в .app (библиотеки, утилиты командной строки, серверный софт), образовался вакуум. Системный администратор или разработчик оказывался в положении каменного века: качать исходники, ./configure, make, make install, вручную разрешать зависимости.

Рождение Homebrew:
В 2009 году Макс Хоуэлл создал Homebrew не как аналог apt, а как хитрый обходной путь в рамках жёстких ограничений macOS. Его мысль изложена в знаменитом принципе: «The Mac missing package manager». Но его гениальность в понимании, чего нельзя делать.

Принцип ненасилия над системой (No sudo for installation): Brew устанавливает всё исключительно в /usr/local (на Intel) или /opt/homebrew (на Apple Silicon). Он никогда не трогает священные /usr/bin, /System, /Library. Он - гость, который живёт в отведённой ему комнате и не претендует на дом. Установка происходит от имени пользователя, а не root (хотя сам каталог /usr/local требует прав).
Формулы (Formulae) против бинарных пакетов: В отличие от Linux-менеджеров, которые ставят скомпилированные бинарники, Homebrew по умолчанию компилирует из исходников. Каждая формула - это Ruby-скрипт, описывающий, где взять исходный код, какие патчи применить, как сконфигурировать (./configure --prefix=/usr/local) и собрать. Это даёт гибкость, оптимизацию под конкретный Mac, но требует установленного компилятора (xcode-select --install) и времени.
Кеши и бутылки (Bottles): Для популярных пакетов (nginx, python) Brew предоставляет предварительно собранные бинарники - «бутылки». Это ускоряет установку. Но под капотом всё равно лежит идея сборки.
Управление зависимостями: Дерево, а не граф. Brew разрешает зависимости, но его модель проще, чем у apt. Нет сложных систем обратных зависимостей (reverse-depends) или альтернатив (provides). Это менеджер для пользовательского пространства, а не для всей ОС.

Практические следствия: Шизофрения путей и конфликты
Именно здесь удобство сталкивается с адом.

Двоемирие Python/Ruby/Node.js: В системе уже есть системные интерпретаторы от Apple (/usr/bin/python3, /usr/bin/ruby). Они старые, изменять их нельзя. Brew ставит свои, свежие версии в /usr/local/bin. Теперь у тебя два python3. Какой запустится - решает $PATH. По умолчанию Brew настраивает PATH так, что его версии приоритетнее. Но это порождает тонкие баги: скрипт, завязанный на системный Python, может сломаться; виртуальные окружения могут активироваться не от той версии.
Проблемы со сборкой и линковкой: Когда ты собираешь что-то из исходников вручную, компилятор может не найти библиотеки от Brew. Приходится явно указывать флаги вроде -I/usr/local/include -L/usr/local/lib. pkg-config нужно правильно настроить. Это постоянная ручная работа, которую в Linux решает пакетный менеджер.
Обновление системы vs. обновление Brew: Обновление macOS до новой мажорной версии может сломать скомпилированные формулы, потому что изменились системные библиотеки. После апдейта ОС часто нужно делать brew update && brew upgrade && brew reinstall $(brew list). В мире Linux обновление дистрибутива (apt dist-upgrade) обновляет всё согласованно.
Отсутствие управления ядром и драйверами: Brew не может обновить ядро, не может поставить графический драйвер NVIDIA, не может управлять системными службами на уровне launchd. Он - менеджер прикладного софта, но не системного.

Cask: Попытка захватить мир GUI
Расширение brew cask (теперь просто brew install --cask) - это попытка Homebrew управлять GUI-приложениями. Оно скачивает .app bundle и перемещает его в /Applications. Но это просто автоматизация загрузки и распаковки. Cask не управляет зависимостями приложения, не интегрируется с sandbox App Store, не может обновить приложение, если у того нет встроенного автоапдейтера. Это удобный скрипт для установки, но не полноценный менеджер пакетов в Linux-смысле.

Linux

В Linux дистрибутив и его пакетный менеджер - это единый организм. Менеджер не дополнение, а орган власти, определяющий само существование системы.

Дистрибутив как куратор: Модель доверия
Каждый дистрибутив (Debian, Arch, Fedora) - это организация, которая курирует тысячи пакетов. Команда мейнтейнеров:

Берет исходный код upstream (например, с nginx.org).
Патчит его для совместимости со своим дистрибутивом.
Создает билд-правила (Debian: debian/rules; Arch: PKGBUILD).
Собирает пакет в своих чистых средах (pbuilder, mock).
Подписывает пакет криптографически.
Помещает в репозитории с разными уровнями стабильности (main, testing, unstable).

Пользователь, устанавливая пакет через apt install nginx, полностью доверяет дистрибутиву. Он получает не просто программу, а интегрированный, протестированный системный компонент.

Ключевые архитектурные принципы:

Единая база данных зависимостей:
Менеджер (dpkg/apt, rpm/dnf, pacman) знает о каждом установленном файле в системе. Он строит гигантский направленный граф зависимостей. Пакет A зависит от библиотеки libB. При установке A менеджер найдёт и установит подходящий libB, а если требуется новая версия, которая конфликтует с пакетом C, - сообщит о конфликте и предложит решение. Это уровень целостности, недостижимый для Homebrew.
Чистые разделения:
В отличие от хаоса Brew, в Linux есть чёткая иерархия:
- Официальные репозитории: Основной источник стабильного, проверенного софта.
- /usr/bin vs /usr/local/bin: Системные пакеты - в /usr/bin, ручная сборка - в /usr/local/bin. Менеджер никогда не тронет /usr/local. Конфликта «системный vs пользовательский» Python не существует - есть только системный, управляемый пакетами.
- Библиотеки и заголовки: Разделение на runtime-библиотеки (libnginx) и dev-пакеты (libnginx-dev, nginx-devel), содержащие заголовочные файлы для сборки. Установка nginx из пакета автоматически тянет нужные runtime-зависимости, а для сборки чего-то против nginx нужно доставить dev-пакет.
Управление всей системой:
Одна команда обновляет всё: sudo apt update && sudo apt full-upgrade. Это обновит ядро, все библиотеки, системные утилиты, драйверы, среду рабочего стола. Система остаётся целостной. Откат (apt history, dnf history undo) также работает на уровне всей системы.
Менеджер запуска и конфигурации:
Многие пакеты автоматически регистрируют systemd-юниты (nginx.service), создают конфиги в /etc, пользователей и группы. После установки nginx он сразу готов к запуску через systemctl start nginx.

AUR (Arch User Repository) и PPA: Сообщество как движок
Linux признаёт, что официальных репозиториев недостаточно. Но решает это иначе, чем macOS.

AUR: Это не репозиторий бинарников, а гигантская пользовательская база PKGBUILD-скриптов. Пользователь устанавливает yay или paru, который для пакета из AUR скачает PKGBUILD, проверит его (пользователь может прочитать скрипт!), соберёт пакет локально и установит его через pacman. Пакет попадает в общую базу. Это модель контролируемого доверия и коллективной разработки, не имеющая аналогов в мире macOS.
PPA (Personal Package Archive) в Ubuntu: Позволяют разработчикам строить свои мини-репозитории с бинарными пакетами, собранными для конкретной версии Ubuntu. Более удобно, но менее прозрачно, чем AUR.

Сравнение в экстремальных условиях:

Развёртывание на air-gapped системе (без интернета).

macOS + Homebrew: Катастрофа. Homebrew заточен под онлайн-установку. Нет встроенного механизма создания локального зеркала всех формул и их зависимостей с исходниками/бутылками. Нужны костыльные скрипты для выкачки $(brew deps) и их оффлайн-установки. Практически нереализуемо в продакшене.
Linux + apt/dnf: Стандартная практика. Можно создать полное зеркало репозиториев (apt-mirror, reposync) на локальном сервере. Клиенты настраиваются на этот сервер. Установка идёт с локальной сети, быстро и надёжно. Это основа корпоративных развёртываний.

Воспроизводимость среды (Docker/управление конфигурацией).

macOS: Brewfile - список формул. Восстановление среды требует запуска Brew, который будет компилировать/качать актуальные версии. Версии могут «уплыть». Нет гарантии идемпотентности (повторный запуск может установить новые версии и сломать что-то).
Linux: Точный список пакетов с версиями (dpkg -l, pacman -Qe). Его можно передать другому identical-дистрибутиву и получить бит-в-бит такую же среду. Ansible/Puppet используют нативные пакетные менеджеры для гарантированной установки конкретных версий. Это фундамент инфраструктуры как кода.

Критическая уязвимость (CVE) и срочное обновление.

macOS: Ждать, пока мейнтейнер формулы обновит её до патченной версии. Или лезть в исходники и править/собирать вручную. Системные библиотеки (например, OpenSSL от Apple) обновляются только с апдейтом всей ОС через App Store.
Linux: Команда безопасности дистрибутива выпускает патченный пакет в репозиторий обновлений безопасности (security.debian.org). Админ запускает apt update && apt upgrade. Обновляется только нужная библиотека, перезапускаются зависящие службы. Процесс автоматизируется. Это индустриальный стандарт.

Глубинный слой: Ядро, утилиты и системное нутро - где расходятся миры

Здесь, за порогом пользовательского пространства, начинается царство демонов, системных вызовов и сырого железа. Различия между macOS и Linux перестают быть особенностями - они становятся сущностями. Это не два варианта одной системы, а две разные планеты, на которых эволюция пошла противоположными путями. Спускаясь на этот уровень, ты не настраиваешь систему - ты изучаете её анатомию.

Гибрид против Монолита (XNU vs Linux Kernel)

macOS: Гибридный мир XNU - наследие амбициозного эксперимента
Ядро macOS называется XNU (X is Not Unix). Это исторический гибрид, созданный в недрах NeXT, и его архитектура объясняет многое в современной системе.

Микроядро Mach: В основе лежит микроядро Mach, разработанное в Университете Карнеги-Меллона в 80-х. Его цель - минимализм. Mach отвечает только за самое примитивное: управление виртуальной памятью, потоками (threads), межпроцессное взаимодействие (IPC) и планирование задач. Всё остальное - драйверы, файловые системы, сетевой стек - должно работать как пользовательские службы. В теории это даёт невероятную стабильность (падение драйвера не крашит ядро) и гибкость.
Наслоение BSD: Поверх Mach намертво приклеен слой кода из FreeBSD (в основном из версии 4.4). Этот слой предоставляет классический UNIX API: системные вызовы (POSIX), модель процессов, базовую сетевую подсистему, файловые системы UFS/FFS. Для пользователя и программиста система выглядит как BSD, но под капотом все запросы транслируются в Mach-примитивы.
Практические следствия гибридности:
1. Сложность отладки: Паника ядра (kernel panic) - это часто результат рассогласования между слоем Mach и BSD. Трейс может быть крайне неочевидным.
2. Уникальные механизмы IPC: Межпроцессное взаимодействие через порты Mach (mach_msg) невероятно мощное и эффективное, но это абсолютно проприетарная, закрытая технология Apple. На этом построена вся внутренняя связь в macOS (например, между GUI и сервисами).
3. Драйверы в клетке (Kext → DriverKit): Традиционно драйверы для macOS - это Kernel Extensions (Kext), которые загружаются прямо в ядро, нарушая чистоту микроядерной архитектуры. Сейчас Apple агрессивно переводит всё на DriverKit - фреймворк, который выталкивает драйверы в пользовательское пространство. Драйвер теперь - это обычное приложение, общающееся с ядром через те же IPC-порты Mach. Это повышает стабильность, но убивает возможность написания низкоуровневых драйверов сообществом.

Linux: Монолит - цельность и скорость
Ядро Linux - классический монолит. Весь код: управление памятью, планировщик, драйверы, сетевой стек, файловые системы - выполняется в одном адресном пространстве, в режиме ядра.

Скорость и простота: Любой компонент может напрямую вызвать функцию другого. Нет накладных расходов на IPC для передачи данных между подсистемами. Это делает ядро невероятно быстрым и, как ни парадоксально, проще в разработке и отладке (всё в одном месте).
Динамически загружаемые модули: Хотя ядро монолитное, оно не статичное. Подавляющее большинство драйверов и расширений - это Loadable Kernel Modules (LKM), которые можно загружать и выгружать на лету (insmod, modprobe). Они выполняются в том же привилегированном режиме, что и ядро, поэтому падение модуля = паника ядра. Зато они имеют полный и прямой доступ ко всем внутренним структурам.
Открытая мастерская: /proc и /sys - это не просто файлы. Это интерфейс прямого управления ядром в реальном времени. Запись в /proc/sys/vm/swappiness мгновенно меняет поведение системы. Чтение из /sys/class/net/eth0/statistics/rx_packets даёт сырую статистику от драйвера. Всё прозрачно, всё настраивается. Ты можешь скомпилировать своё ядро, выкинув 90% кода, который тебе не нужен.

XNU в macOS - это инженерный компромисс, попытка соединить академическую идею микроядра с практическими нуждами UNIX. Linux - это прагматичный монолит, выросший из желания «просто работающей» системы. В первом случае сложность скрыта, но накладывает отпечаток на всё; во втором - сложность выставлена напоказ и отдана в руки пользователя.

Системные утилиты и инструменты наблюдения:

Здесь разница между «получить результат» и «понять процесс» проявляется ярче всего.

macOS: Инструменты оракула - мощно, но магически
Apple предоставляет набор уникальных, невероятно мощных инструментов, но они работают как оракулы: дают ответ, но часто скрывают путь.

DTrace: Коронная фишка. Инструмент динамической трассировки, заимствованный из Solaris. Позволяет ставить пробы (probes) практически куда угодно: на системные вызовы, на функции в ядре, на точки в пользовательских приложениях, даже на инструкции процессора. Скрипты на языке D позволяют в реальном времени агрегировать данные, строить гистограммы, искать аномалии. Аналогов в стандартном Linux нет. strace/ltrace - жалкие игрушки рядом с ним. Но Dtrace на macOS жёстко ограничен (для его использования нужны права SIP или загрузка в Recovery Mode), чтобы злоумышленник не мог бесшумно следить за всей системой.
Instruments: Графическая оболочка над Dtrace и другими низкоуровневыми фреймворками (Activity Monitor - лишь её бледная тень). Позволяет визуально профилировать потребление CPU, памяти, дисковые операции, активность сети на уровне отдельных вызовов функций. Инструмент уровня «профессиональной разработки под Apple», бесплатно поставляемый с Xcode.
sysctl vs /proc/sys: В macOS для настройки параметров ядра используется sysctl. Многие параметры, доступные в Linux через /proc/sys, в macOS либо отсутствуют, либо их настройка заблокирована SIP. Ты не можешь так же тонко настроить поведение виртуальной памяти или сетевого стека.
Отсутствие родных аналогов: В macOS нет iostat, vmstat, netstat в том виде, как в Linux (есть упрощённые версии). Вместо этого - универсальный top и Activity Monitor. Нет ss (socket statistics) - лучшего друга сисадмина. Нет iproute2 (команда ip) - самого мощного сетевого инструментария.

Linux: Кухня с открытым планом
В Linux ты не просто получаешь данные - ты видишь, как они готовятся. Каждый инструмент открывает конкретный люк в систему.

eBPF - открытый ответ Dtrace: Extended Berkeley Packet Filter - это технология, позволившая Linux догнать и во многом превзойти Dtrace. eBPF позволяет выполнять безопасные, проверенные программы прямо в ядре для наблюдения и модификации трафика. Инструменты на его основе (bpftrace, bcc) дают ту же мощь, что и Dtrace, но в полностью открытой экосистеме. Это не магия, а код, который ты можешь изучить и модифицировать.
procfs и sysfs - вселенная в файлах: Каталог /proc - это не просто «информация о процессах». Это иерархическое отображение внутреннего состояния ядра. /proc/irq, /proc/interrupts, /proc/slabinfo - ты можешь увидеть, как ядро распределяет прерывания, управляет кэшем памяти. sysfs (/sys) даёт доступ к устройствам, их атрибутам, настройкам питания.
Мощь iproute2: Пакет iproute2 (команды ip, tc, ss, bridge) - это единый, логичный фреймворк управления всей сетевой подсистемой. Старый ifconfig и route - это древние скрипты, которые теперь всего лишь обёртки над ip. С помощью ip ты можешь создавать сложные маршрутизационные правила, vlan-интерфейсы, туннели, управлять соседними записями (arp). tc (traffic control) позволяет формировать трафик с точностью до пакета. Это уровень контроля, недоступный в macOS из коробки.
systemd-analyze: В мире, где systemd стал стандартом, эта утилита позволяет не просто управлять службами, а анализировать время загрузки, строить граф зависимостей между юнитами, проверять их конфиги на корректность. Это инструмент системного инженера, который хочет понять процесс, а не просто запустить службу.

Драйверы и железо:

macOS: Экосистема как тюрьма (или курорт)
Apple контролирует железо, а значит, контролирует и драйверы.

Закрытые драйверы и Firmware: Драйверы для специфичного железа Mac (тачпад Force Touch, контроллер T2/T3, система управления питанием) - проприетарны и встроены в ОС. Ты не можешь их обновить отдельно, не можешь заменить.
Отсутствие аппаратной совместимости: Попытка поставить macOS на не-Apple железо (Hackintosh) - это постоянная битва с кекстами, патчами DSDT и неработающими функциями. Система не предназначена для этого. Драйверы просто отсутствуют.
User-Space DriverKit: Новый тренд - вынос драйверов в пользовательское пространство - делает систему стабильнее, но окончательно хоронит идею сторонних низкоуровневых драйверов. Теперь даже производитель периферии должен писать драйвер как приложение, подчиняющееся жёстким правилам sandbox.

Linux: Мир возможностей и головной боли
Ядро Linux содержит десятки тысяч драйверов в своём дереве исходников.

Поддержка легаси и экзотики: Из коробки система может работать с сетевыми картами 20-летней давности, странными USB-девайсами, самодельным оборудованием через GPIO. Если устройство хоть как-то популярно, драйвер для него, скорее всего, уже в ядре.
Прямой доступ к железу: Через sysfs, debugfs и прямую работу с /dev можно читать показания датчиков (lm-sensors), управлять скоростью вентиляторов, включать/выключать порты USB. Для энтузиастов и инженеров - это рай.
Головная боль с проприетарными драйверами: Обратная сторона - драйверы, которые не хотят становиться открытыми (NVIDIA, некоторые Wi-Fi-чипы). Их установка требует танцев с бубном, они ломаются при обновлении ядра, их поведение может быть нестабильным. Это цена за открытость.

Конкретные точки трения для хакера: Где резина встречается с асфальтом

Вот мы и добрались до сухой, технической соли. До мест, где разногласия между macOS и Linux перестают быть предметом дискуссий и становятся причиной сломанных деплоев, потерянных часов и тихого скрежета зубовного. Это - набор конкретных, тактико-технических различий, которые режут по живому при ежедневной работе. Знать их - не просто эрудиция. Это выживание.

Сеть: Искусство подсматривания и управления

Работа с сетью - фундамент любого системного хакинга, от аудита до пентеста. И здесь инструментарий расходится кардинально.

macOS: Мир lsof, ограничений и скрытой мощи.
Стандартный сетевой арсенал macOS ощутимо беднее. Классический netstat здесь - это BSD-версия, урезанная и с другим синтаксисом. Мощнейшего ss (socket statistics) из пакета iproute2 нет в системе. Но macOS предлагает свои, порой более изящные, обходные пути.

lsof -i - швейцарский нож: Команда, которая должна быть в мышечной памяти. lsof -i покажет все открытые сетевые соединения (TCP/UDP), сопоставив их с PID и процессом. lsof -i :8080 мгновенно покажет, кто занял порт 8080. Это быстрее и информативнее, чем копаться в выводе netstat.
netstat с флагом -an: Покажет открытые порты и соединения. Но забывай про многие привычные GNU-флаги.
Отсутствие ip и ss: Это главная боль. ip addr, ip route, ip neigh - стандарт индустрии для управления интерфейсами, маршрутами, ARP-таблицами. На macOS придётся использовать сборку старых команд: ifconfig (также BSD-версия, с другим выводом), route -n get default, arp -a. Это менее единообразно и мощно.
Продвинутый анализ: tcpdump, nettop и Wireshark. Базовый tcpdump есть. Для удобного мониторинга в реальном времени есть консольная утилита nettop. Wireshark в GUI - полноценный. Но для глубокого, программируемого анализа трафика на лету (как с nftables или bpfilter в Linux) придётся искать обходные пути или ставить сторонний софт через Brew.

Linux: Царство iproute2 и тотальной прозрачности.
Здесь тебе дают не просто инструменты, а полный пульт управления сетевой подсистемой ядра.

ss - наследник netstat: Быстрее, информативнее, показывает больше состояний. ss -tlnp - классика для просмотра всех слушающих TCP-портов с именами процессов.
ip - единый центр управления: Одна команда правит всем. ip addr show, ip link set eth0 up, ip route add, ip neigh flush. Синтаксис логичен и тотален.
nftables / iptables: Прямой доступ к фаерволу ядра. Можешь на лету в консоли строить сложные правила фильтрации, маскарадинга, тегирования трафика.
tcpdump и tshark: Фундамент сниффинга. В связке с ip можно творить чудеса анализа.

В macOS ты анализируешь сеть как наблюдатель, используя высокоуровневые инструменты (lsof). В Linux ты управляешь и конструируешь сеть как инженер, имея прямой доступ к её механизмам (ip, nftables).

Процессы: От простого списка до квантового сканирования

Просмотр и управление процессами - вроде бы база. Но и здесь глубины разные.

macOS: Два мира - простота ps и бездна dtrace.

ps aux - работает, но детали иные. Вывод BSD-версии ps отличается от GNU: иное форматирование, иной набор ключей. Например, для отображения дерева процессов привычный ps auxf может дать не тот результат. Простой pstree зачастую отсутствует.
top и htop (через Brew): Интерактивный мониторинг. htop после установки становится must-have.
dtrace - супероружие для интроспекции.
Вот где macOS бьёт Linux на голову в поставке из коробки. Dtrace позволяет ставить динамические пробы (probes) куда угодно: на системные вызовы (syscall:::), на функции в ядре, на пользовательские приложения. Хочешь узнать, какие файлы открывает процесс, какие библиотеки загружает, сколько системных вызовов делает? Пишешь скрипт на языке D. Это уровень анализа, для которого в Linux нужно поднимать целый арсенал perf, systemtap или bpftrace (которые, впрочем, на современных ядрах через eBPF могут быть даже мощнее). Но dtrace на macOS заблокирован SIP по умолчанию для полного доступа. Для реального хакинга нужно либо отключать защиту, либо загружаться в Recovery Mode. Это оружие, которое держат под замком.

Linux: Предсказуемость, дерево и растущая мощь eBPF.

ps aux, ps -ef - стандарт де-факто. Вывод предсказуем, его парсят все скрипты.
pstree - наглядная иерархия. Показывает родительско-детские связи процессов как красивое дерево. Незаменим.
/proc/$PID/ - вселенная в каталоге. Это не просто список. Это прямое окно в процесс: его память (/proc/$PID/maps), открытые файлы (/proc/$PID/fd), окружение (/proc/$PID/environ), текущий рабочий каталог (cwd). Прямой, низкоуровневый доступ для анализа и отладки.
strace/ltrace - классика отладки. Просмотр системных вызовов и библиотечных вызовов процесса. Проще, чем dtrace, для базовых задач.
eBPF и bpftrace - будущее сейчас. Современные ядра Linux позволяют загружать безопасные программы eBPF прямо в ядро для мониторинга. Инструмент bpftrace предоставляет D-подобный язык, приближаясь по удобству к dtrace, но в экосистеме Linux.

Для быстрого, повседневного просмотра процессов Linux удобнее предсказуемостью и pstree. Для глубочайшего, системного исследования и профилирования macOS предлагает встроенную магию dtrace, но с бюрократическим барьером SIP. Linux же требует установки дополнительных инструментов (eBPF), но даёт их в полностью открытом виде.

Разработка:

Попытка скомпилировать что-то нетривиальное (не из Brew) обнажает архитектурную пропасть.

macOS: Танцы с линковщиком и крестовый поход за зависимостями.
Проблема в разделении миров: системные библиотеки Apple в /usr/lib - неприкасаемы. Библиотеки от Brew - в /usr/local/lib. И они не всегда дружат.

Поиск заголовков: Компилятор может не найти openssl/ssl.h, потому что он лежит не в /usr/include, а в /usr/local/opt/openssl/include (симлинк от Brew). Решение: явно указать CFLAGS="-I/usr/local/opt/openssl/include".
Линковка против библиотек: Линковщик (ld) может ругаться, что не находит -lssl. Нужно добавить LDFLAGS="-L/usr/local/opt/openssl/lib".
pkg-config - твой новый лучший друг: Brew часто создаёт .pc файлы для pkg-config. Правильный подход: export PKG_CONFIG_PATH="/usr/local/opt/openssl/lib/pkgconfig", и тогда ./configure сам всё найдёт. Если, конечно, проект использует pkg-config.
Универсальные бинары и архитектуры: С появлением Apple Silicon (arm64) добавилась головная боль с поддержкой как x86_64, так и arm64. Флаги вроде -arch x86_64 -arch arm64 становятся привычными.

Linux: Сантимент «просто работает» (если знать правило).
Здесь царит порядок, навязанный пакетным менеджером.

Установка -dev пакетов: Нужно собрать программу, зависящую от библиотеки libfoo? Установи libfoo-dev (Debian/Ubuntu) или libfoo-devel (RHEL/Fedora). Пакетный менеджер положит заголовки в /usr/include, библиотеки для линковки в /usr/lib, а .pc файлы - куда надо. pkg-config или cmake найдут их автоматически.
Стандартные пути: Компилятор и линковщик по умолчанию ищут всё в /usr. Никаких дополнительных флагов не нужно. Классическая трилогия ./configure && make && sudo make install работает в 80% случаев.
Менеджеры пакетов для языков (pip, npm): Здесь они ведут себя одинаково на обеих системах, и проблемы кросс-платформенной совместимости чаще возникают именно на уровне нативных библиотек (тех самых, которые в macOS от Brew, а в Linux от apt).

Сборка на macOS - это постоянный дипломатический процесс согласования между системным миром Apple и пользовательским миром Brew. На Linux - это инженерная процедура по чёткому протоколу: установил dev-пакет, получил готовую среду для сборки.

И, наконец, главное различие в духе: что ты на самом деле можешь изменить.

macOS: Кастомизация пользовательского пространства. Твоя власть заканчивается на границе Darwin.

Можно: Менять оболочку, настраивать .zshrc, ставить темы для терминала, менять менеджер окон через Homebrew, патчить некоторые системные приложения.
Нельзя (без взлома SIP, что самоубийственно): Заменить ядро, заменить системный launchd, модифицировать системные библиотеки в /System, поменять драйверы ввода-вывода, пересобрать стек USB или сетевой драйвер. Можно кастомизировать поведение, но не фундамент.

Linux: Кастомизация всей системы. Ты ограничен только своей компетенцией и смелостью.

Init system: Не нравится systemd? Поставь OpenRC (Gentoo), runit (Void), s6. Или напиши свой.
Ядро: Собери своё. Выкини всё ненужное. Встрой нужные драйверы. Оптимизируй под своё железо.
Любая утилита: Можно заменить GNU coreutils на busybox или набор BSD-утилит. Можно поставить другую реализацию libc (musl вместо glibc). Можно собрать систему без /bin/sh.
Графический стек: От X11 к Wayland, от одного композитора к другому. Всё собирается из исходников, как мозаика.

Заключение

В конечном счёте, спор «что лучше» бессмысленен, как спор между скальпелем и кузнечным молотом. Скальпель (macOS) невероятно точен и хорош в руках хирурга, но попробуйте им выковать меч. Молот (Linux) может выковать что угодно, включая скальпель, но для тонкой операции он слишком груб.

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

Терминал - это не программа. Это дверь. И таких дверей - две. Мудрость не в том, чтобы всю жизнь ходить через одну, а в том, чтобы иметь ключи от обеих и точно знать, куда ведёт каждая. В мире, где наши системы давно стали гибридными, эта способность - и есть главный профессиональный навык. Включай одну, переключайся на другую, и пусть в обеих царит тишина, которую ты заслужил.

Поиск

Поиск