Есть ли жизнь на arm'е или опыт установки Linux на Apple Silicon

Предвосхищая вопрос о целесообразности замены macOS'и на Linux. Кто‑то любит macOS, кто Linux, а кто‑то и Windows. Я люблю Linux и хочу им пользоваться. Для меня он субъективно удобнее и объективно лучше подходит под задачи. На момент устаревания моего Dell XPS 13 с Core i7 в четыре потока, M1 Pro был лучшим выбором. Наверное все, что говорят про эти ноуты — правда. Железяка и в самом деле превосходна, за подобные деньги — лучший выбор. Но. Полностью разделяю боль и гнев авторов статей касательно macOS и юзабилити от «Think Different», самому есть что дополнительно накинуть, о чем авторы не упоминали. После покупки, всерьез хотел продать, предлагал знакомым ИТшникам, но никто не решался. Выставлять как БУ'шный и терять в деньгах казалось сомнительно, т.к. аналоги от других производителей стоят дороже и будут хуже по производительности/автономности. Начали посещать мысли поставить Linux, но на тот момент невозможно было подключить внешний монитор и в целом проект был сырым, поэтому пришлось привыкать к macOS. Прошло полтора года.

Прочел хвалебную статью «Идеальная рабочая станция Linux на процессоре Apple M1 (ARM64)» и поверил автору на слово, который пишет:

нет ни одного программного пакета, который был бы мне необходим, и не работал бы в моей системе

Значит пришло время и мне приобщиться. Что получилось описывается далее. В общем, заметка написана с целью рассказать о переходе от macOS к Fedora Asahi Remix, встреченных проблемах, попытке их решения и умозаключениях, а не ради холивара в поисках идеальной ОС. Тем более, спорить тут не о чем. Есть плюсы, минусы, предпочтения и обстоятельства, остальное от лукавого.

На момент установки на подопытный MacBook Pro (M1 Pro) 16-inch, 2021 не поддерживались устройства:

• USB-C Displays

• Thunderbolt/USB4

• Microphone

• Touch ID

Первые два мной не используются, микрофон заменит bluetooth гарнитура, без Touch ID как-то жили раньше, нечего и начинать просто придется чаще набирать пароль. Вижу цель, не вижу преград. Процесс установки прост и описывать его не буду, в интернете много примеров.

Первое впечатление

Пространство под челкой, в котором у macOS располагается панель и выглядит эргономично, в Linux полностью недоступно и уменьшает рабочую область экрана на какое-то количество пикселей, как при полноэкранном режиме приложения в macOS. Картинка четкая на обоих мониторах, второй AOC U2790, 27", 3840 × 2160. Мониторы масштабируют картинку по отдельности и изображение отлично выглядит во всех приложениях. Субъективно, система в целом кажется более отзывчивой и менее тормозной. На контрасте после Макоси в Linux шрифты кажутся четче. Приятная и настраиваемая DE. Все отлично! Получил именно то, что хотел.

Из неработающего, по классике, отсутствие нормальной работы сна. Ноут иногда засыпает, если отправить команду из консоли или кнопкой в интерфейсе, и никогда не просыпается, только хардресет. Иногда вместо сна гаснет экран и продолжает работать, понять это можно при нажатии на клавиши громкости и звуковому отклику системы, тоже хардресет. С гибернацией наоборот, экран гаснет на секунду и снова включается, не меняя режим. При закрытии крышки продолжает работать, а утром при открытии радуясь, что ноут таки спал, вижу 30% заряда аккумулятора от 80 перед закрытием. Хотя документация говорит, что сон работает уже полгода, т. е. с первой ревизии документа.

Настройки ограничения максимального заряда аккумулятора слетали при перезагрузке, но этот и другие косяки отношу к Fedora (KDE), и описывать не буду.

В ходе эксплуатации двух систем обе получили обновления. Fedora обновилась с 39 версии на 40, macOS (Sonoma) же обновилась с 14.4.1 на 14.5. Загрузка ни одной из систем не сломалась. Спустя пару недель установочный скрипт был обновлен и предлагал к установке уже Fedora 40, а не 39.

Виджет календаря в KDE (как впрочем и в Mate, и Cinnamon) менее удобный, чем макоси. После использования Макоси хочется работающий системный календарь или виджет без дополнительного софта с возможностью синхронизации календарей из разных сервисов.

Bluetooth мышь приходилось сопрягать каждый раз при смене ОС (Linux ставится в dual boot с macOS) и в один момент она отвалилась в Линуксе и больше не подключалась с невнятной ошибкой. Никакие инструкции из интернета починить не помогли. В это же время на Маке и мобиле эта же мышь сопрягалась и работала. Другие bluetooth устройства, а именно гарнитура и мобильник не сломались.

Звук из микрофона гарнитуры при звонке в браузере удалось включить не сразу. В системных настройках звука (которых оказалось неожиданно много) перепробовано все, но собеседники не слышали голос. Firefox с заботой о пользователе блокировал передачу звука, и надо отключить антитрекинг для сайта. Для этого в левой части адресной строки нажать на значок щита и в открывшейся панели отключить Enhanced Tracking Protection.

Отдельно надо сказать про хоткеи. Кто переходил с Linux/Windows на macOS знают, что пальцы помнят сочетания хоткеев и надо переучиваться, привыкать. В обратную сторону так же, но привычка уже выработалась и от действительно удобных сочетаний отказываться не хочется, например для закрытия окна выигрывает Command+Q вместо Alt+F4. В Макоси можно переопределить хоткеи, но мне было лень. В Linux же легко можно назначить дополнительные к уже существующим (к сожалению, добавить придется по сочетанию для каждого языка раскладки). Как в примере с закрытыием окна, просто добавляется новое сочетание по Command+Q и они работают оба. Но сюда относится только оболочка и поставляемый с ней софт. При добавлении, например, Command+С/Command+V сочетание будет работать в Kate и «проводнике», но не будет в Firefox.

Поиск софта

Переход будет простым, думал я. На Linux под ARM популярны и работают сервера, это значит и на десктопах наверняка есть жизнь. Не зря же пилят Asahi Linux и уже более 10 лет существует ARM в виде Raspberry Pi. В действительности все не так радужно. Что-то действительно существует, но есть, как говорится, нюанс.

Из довольно небольшого используемого набора инструментов около половины не работают.

Не работает под Linux

• Dropbox. Исторически так сложилось, что все документы, важные файлы и рабочие записи храню там

• Yandex Disk и Google Drive. Могли бы стать заменой Dropbox

• Yandex Browser. Имеет киллер фичу потокового перевода и озвучки роликов в Ютубе на русский

• Google Chrome

• Google Authenticator и Authy. Первого нет даже под x64, второго только под ARM

• Atom, текстовый редактор. По функциональности уступает VS Code, но как по мне удобнее. За пару лет попыток так и не смог полностью пересесть с Atom на VS Code. Проект закрыт и сборок под ARM не предвидится

• Zoom, Skype, etc

• Ничего из десктопной виртуализации

Все из списка невозможно сбилдить самостоятельно, поскольку код закрытый и вариантов пока нет.

Работает под Linux

• Firefox, Chromium

• Vivaldi. Как альтернатива Yandex Browser. Имеет встроенный календарь и почтовый клиент

• KeePassXC. Умеет TOTP из коробки

• DBeaver из flatpak

• Mattermost клиент из flatpak

• Sublime text. Пакетов нет, скачивается архив и запускается бинарь. В KDE из коробки есть редактор Kate, приятно удивил с момента последнего использования. На первый взгляд достойная замена Sublime

• PyCharm CE и IntelliJ IDEA CE не тестировал, но архивы есть на сайте JetBrains

• VS Code

• Не официальный, но MS Teams

Из трех перечисленных браузеров при звонке в Yandex.Telemost (клиента под Linux не существует) видео показывает только в Firefox, в остальных разноцветные полосы. На скрине камера вещает из Chromium.

Казалось бы, с некоторыми ограничениями, но жить можно. Менее удобно, но это же Linux!

Многое остается в суперпозиции

• Пакет openvpn3 клиента есть в подключаемой репе, но содержит косяк с архитектурой в зависимостях и не ставится с ошибкой:

Error:
 Problem: conflicting requests
  - nothing provides libprotobuf.so.25()(64bit) needed by openvpn3-client-21-3.el9.aarch64 from copr:copr.fedorainfracloud.org:dsommers:openvpn3

• Telegram-desktop доступен из flatpak, но не запускается из-за 16K-страничного ядра Проблема известна, но не решена. Казалось бы, можно разобраться в деталях и собирать нужный софт самостоятельно, но делать это должен мейнтейнер, собирать для себя каждый пакет никто не будет.

Asahi ведет список сломанного софта, который не работает на 16K-страничном ядре, которое было предоставлено еще в альфа релизе два года назад и основной популярный софт, казалось бы, уже должен был подъехать.

Виртуализация

Libvirt и QEMU ставятся, пакеты есть. Стоить отметить, QEMU напрямую трогал впервые, поэтому не умею его правильно готовить и все, что касается эмуляции amd64 на arm64 надо подвергать сомнению и проверке.

Libvirt

Systemd сервис libvirtd при старте падает с ошибкой, нагуглилось мало, ковырять дальше не стал:

internal error: Child process (dmidecode -q -t 0,1,2,3,4,11,17) unexpected exit status 1: /sys/firmware/efi/systab: SMBIOS entry point missing

qemu-system-aarch64

Грузится с ISO, начинает ставить систему в псевдо графическом режиме, но установка заканчивается неудачей где-то при установке GRUB.

Причины

Все бы было сносно, если Asahi использовал 4K-страничное выделени памяти, но при 16K-страничном, которое выбрано из-за архитектурных особенностей и железа, имеем несовместимость. Интересная дискуссия развернулась на Гитхабе, в которой Hector Martin (marcan), лид проекта Asahi Linux, пытается убедить сообщество по умолчанию собирать бинарники с поддержкой всех стандартных размеров страниц (4K, 16K, 64K) и несмотря на начальные возражения владельцев репы, они согласились и внесли необходимые изменения. Чего нельзя сказать про разработчиков Telegram Desktop и jemalloc, которые отфутболивают пользователей друг к другу для решения проблемы.

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

Безысходность

Вариант хоть что-то запустить виделся в использовании Docker и базового образа под arm64, ядро которого по дефолту собирается с 4K-страничной памятью, даже выглядит не плохо, но пользоваться этим больно.

$ cat Dockerfile
FROM ubuntu:22.04
RUN apt-get update
RUN apt-get install -qqy telegram-desktop
CMD telegram-desktop

$ docker buildx build -t tel .
$ docker run -it --privileged --name tel --rm -v /tmp/.X11-unix:/tmp/.X11-unix --env=DISPLAY=${DISPLAY} tel

Этот же образ с эмуляцией в amd64 сбилдить не удалось, поскольку при попытке взаимодействия с базовым имаджем внутри контейнера, например простой apt update/install, происходит segmentation fault.

Просто запуск x64 имаджа через QEMU хоть с сегфолтами, но работает:
docker run --platform linux/amd64 -p 80:80 nginx:latest

Послесловие

Получается, что проблема совместимости софта с переходом на ARM есть. И если для macOS вопрос решили, и производители софта сделали дополнительные сборки, то переход на Linux оказался гораздо сложнее за сопоставимый период времени. Мало кто думает о двух с половиной пользователях, которые ради любви к искусству решили перейти на Linux. Если под macOS нет необходимых консольных утилит - brew install <package> решает почти все вопросы. На Линукс же Homebrew не поддерживает ARM, поскольку мейтейнеры не собирают бинарники под АРМ. Торвальдс так же высказывал похожее мнение немного в другом контексте еще 10 лет назад. Не только лишь все, мало кто может хочет билдить под ARM.

Существует проект для Raspberry Pi, где собирают популярный софт под АРМ, но саппортят только deb-like дистрибутивы. Сильно не вникал, но как вариант можно посмотреть и чем-то воспользоваться.

В какой-то момент прилетели обновления ядра, во время установки которых ОС зависла и после хард ресета решила не запускаться с ошибкой об отсутствующем файле initramfs.

Скрин с запуском Телеграма в докере остался на разделе Fedora с файловой системой Btrfs. Из мака за разумное время не получилось найти решение для монтирования этого раздела, поэтому решил поставить Asahi еще раз, надеясь, что повторная установка только обновит существующую, но пришлось накатывать рядом, поскольку установщик предлагает только отрезать дисковое пространство у Макоси и не может переиспользовать уже существующее от предыдущей установки. Скрин сделан после повторной установки.

В любом случае, будущее ноутбуков за ARM архитектурой, но придется подождать пока это поймут остальные и подъедет соответствующее железо с исправленным софтом.

Написанное справедливо и для Windows пользователей, находящихся в аналогичной ситуации.

Краткий пересказ или FAQ

Q. Насколько просто потом откатиться обратно?
A. Откат как таковой не потребуется. Linux ставится в dual/multi boot с macOS. Выбрать какую из них грузить в данный момент можно долгим зажатием кнопки включения при выключенном компьютере. По дефолту (который можно изменить там же или в System settings → General → Startup disk) после установки Linux всегда грузится Linux. Перед первой установкой лучше бэкап сделать на случай если что‑то пойдет не так.

Q. Работает ли виртуализация в Asahi Linux?
A. Тоже интересует этот вопрос. Libvirt демон пока что не запускается. QEMU что‑то делает, надо изучать дальше. По ссылке в начале статьи автор утверждает, что запустил FreeBSD.

Q. Есть смысл ставить Федору вместо вылизанной Макоси?
A. Есть плюсы, минусы, предпочтения и обстоятельства, остальное от лукавого.

Q. Есть ли Windows для ARM?
A. Ребята что‑то делают, сам проверять не буду.

Q. Время работы от батареи все так же полностью печально, по сравнению с макос?
A. Сопоставимо. Сo 100% до 20% MacOS разрядилась за 7 часов, все это время писал статью и делал ресерч. Linux за 5 часов, но при чуть большей нагрузке — собирал софт из исходников и докер имаджи, тестировал запуск контейнеров.

Q. Как дела обстоят с Docker?
A. Работает как демон, запускается нативно. Если запускать исключительно ARM образы — работает. Docker Desktop пока не существует под АРМ. Вместе с QEMU умеет запускать x64 образы, но есть проблема с segmentation fault, впрочем как и в macOS.

Q. Openvpn3 работает?
A. Да, но на данный момент требуется собирать из сорцов.