Хакер - M1 для хакера. Тестируем Homebrew, виртуалки, Docker и Node на новой архитектуре Apple

https://t.me/hacker_frei

Denis Simonov

Содержание статьи

• Внешний монитор
• Homebrew и zsh
• Виртуальные машины
• Parallels Desktop
• VMware
• QEMU
• VirtualBox (спойлер: его нет)
• Metasploitable3
• Docker и Node.js
• Проксирование трафика приложений macOS
• Wi-Fi и захват пакетов
• Программы для iOS
• Выводы

В 2020 году Apple пред­ста­вила новую архи­тек­туру Apple Silicon на базе ARM и объ­яви­ла, что в течение двух лет переве­дет на нее все свои компь­юте­ры. Для прос­тых поль­зовате­лей миг­рация про­ходит прак­тичес­ки незамет­но, а как нас­чет прод­винутых? В этой статье я рас­ска­жу об ито­гах года исполь­зования MacBook Pro с M1 внут­ри и покажу те нем­ногие под­водные кам­ни, с которы­ми мне довелось стол­кнуть­ся.

ВНЕШНИЙ МОНИТОР

Мак­буки из пер­вого поколе­ния компь­юте­ров на M1 под­держи­вали все­го один внеш­ний монитор (к Mac mini мож­но под­клю­чить два). С выходом новых MacBook Pro на M1 Pro и M1 Max ситу­ация изме­нилась: у них есть порт HDMI, который мож­но исполь­зовать для вто­рого экра­на.

Ес­ли же менять ноут­бук ты пока не хочешь, а для работы нуж­но нес­коль­ко монито­ров, то решени­ем может стать док‑стан­ция с под­дер­жкой DisplayLink — нап­ример, Dell D6000 или CalDigit. Одна­ко я прос­то отка­зал­ся от исполь­зования трех монито­ров и купил один, но UltraWide. Да, это не Retina Display, но если тебе нуж­но раз­решение 5K, то выбор не велик — толь­ко LG UltraFine, сто­ящие 90 с чем‑то тысяч руб­лей.

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

Нап­ример, для дис­плея с раз­решени­ем 3440 × 1440 я рекомен­дую исполь­зовать сле­дующие нас­трой­ки.

Единс­твен­ная проб­лема, с которой я стол­кнул­ся при исполь­зовании BetterDummy, — невоз­можно выс­тавить высокую час­тоту обновле­ния (144 Гц). Ока­залось, что это огра­ниче­ние API CGVirtualDisplay в macOS, и испра­вить эту проб­лему может толь­ко Apple. Воз­можно, все изме­нит­ся, ког­да появит­ся под­дер­жка ProMotion для AirPlay или Sidecar.

Ес­ли ты хочешь иметь высокую час­тоту обновле­ния экра­на (144 Гц и выше) с раз­решени­ем 3440 на 1440 точек и более, то при­дет­ся отка­зать­ся от BetterDummy и купить отдель­ный кабель USB Type-C → DisplayPort. Через уни­вер­саль­ные хабы (у меня Native Union) работать с такими нас­трой­ками не вый­дет — не хва­тит про­пус­кной спо­соб­ности пор­та для одновре­мен­ного вывода изоб­ражения и под­клю­чения перифе­рии.

HOMEBREW И ZSH

Homebrew — популяр­ный сто­рон­ний пакет­ный менед­жер для macOS. Если тебе нуж­на какая‑то кон­соль­ная ути­лита, то, ско­рее все­го, ты най­дешь ее в Homebrew. С вер­сии 3.0 Homebrew под­держи­вает ARM. До это­го рабочим решени­ем была уста­нов­ка Homebrew через слой бинар­ной тран­сля­ции Rosetta 2. Соот­ветс­твен­но, все при­ложе­ния, уста­нов­ленные отту­да, тоже про­ходи­ли тран­сля­цию и работа­ли (но не так быс­тро, как мог­ли бы армов­ские бинар­ники).

Сей­час дос­таточ­но пос­тавить Homebrew через скрипт‑уста­нов­щик и получать натив­ные пакеты для ARM.

$ xcode-select --install

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

$ echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/$(logname)/.zprofile

$ eval "$(/opt/homebrew/bin/brew shellenv)"

Но если понадо­бит­ся перек­лючать­ся меж­ду архи­тек­турами, то можешь сде­лать себе такие али­асы в фай­ле ~/.bashrc или ~/.zshrc:

alias intel="env /usr/bin/arch -x86_64 /bin/zsh --login"

alias arm="env /usr/bin/arch -arm64 /bin/zsh --login"

Чуть поз­же мы стол­кнем­ся с прак­тичес­ким при­мене­нием такого решения, но если вкрат­це, то скрипт кон­фигура­ции (./configure) перед сбор­кой опре­деля­ет перемен­ные сис­темы, в том чис­ле и для какой архи­тек­туры ком­пилиро­вать про­ект. Нап­ример, если сей­час выб­рать режим i386 при уста­нов­ке Homebrew, то вмес­то бинар­ников для ARM64 мы получим вер­сии для x86_64, что при­ведет к потере про­изво­дитель­нос­ти.

ВИРТУАЛЬНЫЕ МАШИНЫ

Parallels Desktop

Про­дукт Parallels — это в дан­ный момент самое фун­кци­ональ­ное решение для вир­туали­зации на M1. Недаром его показы­вали на пре­зен­тации Apple. Через Parallels Desktop мож­но в один клик уста­новить дис­три­бути­вы Ubuntu, Fedora, Debian и macOS Monterey. С вер­сии 17.1.1 добав­лена под­дер­жка акту­аль­ной на дан­ной момент вер­сии Kali Linux — 2021.3.

Драй­веры гос­тевых машин опти­мизи­рова­ны и работа­ют без нарека­ний (буфер обме­на, сеть, динами­чес­кое раз­решение, 3D-уско­рение и про­чие фичи). Проб­рос адап­тера Wi-Fi или любого дру­гого устрой­ства работа­ет кор­рек­тно.

От­дель­но хочет­ся погово­рить о Windows 11 для ARM, которая уме­ет тран­сли­ровать код при­ложе­ний x86_64 в натив­ные вызовы ARM. При­чем дела­ет это весь­ма качес­твен­но, как и Rosetta 2. При помощи такой мат­решки мне уда­лось запус­тить отладчик для кода x64 и без проб­лем уви­деть регис­тры RBX, RSP, RBP и так далее.

Так же работа­ет и Visual Studio, которая смог­ла ском­пилиро­вать неболь­шой тес­товый про­ект (Quasar RAT) в клас­сичес­кую архи­тек­туру i386. И это все на вир­туаль­ной машине с гос­тевой Windows, для которой хос­том выс­тупа­ет macOS для ARM. Фан­тасти­ка!

Не могу не отме­тить энер­гоэф­фектив­ность при работе с вир­туаль­ными машина­ми. Запущен­ные фоном VM без серь­езной наг­рузки прак­тичес­ки не вли­яют на вре­мя работы от акку­муля­тора. Помимо это­го, в новых вер­сиях Parallels был добав­лен режим поез­дки, в котором еще силь­нее сни­жает­ся энер­гопот­ребле­ние при без­дей­ствии VM.

VMware

Еще один про­изво­дитель популяр­ных решений для вир­туали­зации до недав­него вре­мени был за бор­том зате­янно­го Apple перево­рота, но в кон­це сен­тября 2021 года ком­пания VMware пред­ста­вила на все­общее обоз­рение тех­ничес­кое превью VMware Fusion.

Сей­час VMware Fusion мож­но бес­плат­но заг­рузить на стра­нице про­дук­та или же по пря­мой ссыл­ке. Минималь­ный набор удобств при­сутс­тву­ет, одна­ко в Ubuntu мне не уда­лось нас­тро­ить VMware Tools. Я уста­новил откры­тую вер­сию — open-vm-tools, но и это не помог­ло мне сде­лать адап­тивное раз­решение экра­на и общий с хос­товой сис­темой буфер обме­на.

В общем, решение сырова­тое, но впол­не работос­пособ­ное и пока что бес­плат­ное.

QEMU

QEMU — это глы­ба не толь­ко сре­ди про­дук­тов эму­ляции, но и сре­ди средств аппа­рат­ной вир­туали­зации. Это осно­ва гипер­визора KVM, который исполь­зует аппа­рат­ные воз­можнос­ти сов­ремен­ных про­цес­соров. Базовая под­дер­жка Apple Silicon уже есть в QEMU, и ее активно дораба­тыва­ют. Так что его в ряде слу­чаев мож­но исполь­зовать как мощ­ное средс­тво вир­туали­зации на M1.

Установка QEMU

Для начала под­готовим необ­ходимые пакеты для сбор­ки:

$ brew install libffi gettext glib pkg-config autoconf automake pixman ninja

Кло­ниру­ем репози­торий QEMU, добав­ляем вет­ку со вклю­чен­ным рас­ширени­ем BFloat16 и при­меня­ем патч Алек­сан­дра Гра­фа:

$ git clone https://github.com/qemu/qemu && cd qemu

$ git checkout 3c93dfa42c394fdd55684f2fbf24cf2f39b97d47

$ curl https://patchwork.kernel.org/series/485309/mbox/ | git am

Со­бира­ем и уста­нав­лива­ем QEMU:

$ mkdir build && cd build

$ ../configure --target-list=aarch64-softmmu

$ make -j8

$ sudo make install

Го­тово, мож­но поль­зовать­ся!

Создание виртуальной машины с Ubuntu в QEMU

Да­вай поп­робу­ем пос­тавить Ubuntu для x86_64.

Пе­ред уста­нов­кой нуж­но под­готовить диск:

$ curl https://cdimage.ubuntu.com/releases/20.04/release/ubuntu-20.04.3-live-server-arm64.iso -o ubuntu-20.0.4.iso

$ qemu-img create -f qcow2 virtual-disk.qcow2 8G

$ cp $(dirname $(which qemu-img))/../share/qemu/edk2-aarch64-code.fd .

$ dd if=/dev/zero conv=sync bs=1m count=64 of=ovmf_vars.fd

$ qemu-system-aarch64 \

-machine virt,accel=hvf,highmem=off \

-cpu cortex-a72 -smp 4 -m 4G \

-device virtio-gpu-pci \

-device virtio-keyboard-pci \

-drive "format=raw,file=edk2-aarch64-code.fd,if=pflash,readonly=on" \

-drive "format=raw,file=ovmf_vars.fd,if=pflash" \

-drive "format=qcow2,file=virtual-disk.qcow2" \

-cdrom ubuntu-20.0.4.iso

Пос­ле этой коман­ды дол­жна запус­тить­ся уста­нов­ка Ubuntu. По завер­шении запус­каем вир­туаль­ную машину:

$ qemu-system-aarch64 \

-machine virt,accel=hvf,highmem=off \

-cpu cortex-a72 -smp 4 -m 4G \

-device virtio-gpu-pci \

-device virtio-keyboard-pci \

-drive "format=raw,file=edk2-aarch64-code.fd,if=pflash,readonly=on" \

-drive "format=raw,file=ovmf_vars.fd,if=pflash" \

-drive "format=qcow2,file=virtual-disk.qcow2" \

-nic hostfwd=tcp:127.0.0.1:4422-0.0.0.0:22 &

Для кон­некта по SSH:

$ ssh <username>@127.0.0.1 -p 4422

Для Windows все ана­логич­но, отли­чия в обо­рудо­вании, фор­мате обра­за дис­ка и еще вся­кое по мелочи. Единс­твен­ный минус пря­мой работы с QEMU — все при­дет­ся делать руками. С дру­гой сто­роны, это добав­ляет гиб­кости. Одна­ко мож­но и избе­жать лиш­него тру­да, если исполь­зовать ути­литу UTM.

UTM

QEMU — мощ­ная шту­ка и в уме­лых руках может тво­рить чудеса. Одна­ко не всег­да удоб­но раз­бирать­ся в пяти­этаж­ных аргу­мен­тах кон­фигура­ции, осо­бен­но если нуж­но что‑то быс­тро изме­нить или добавить.

UTM — это гра­фичес­кая обо­лоч­ка, которая зна­читель­но упро­щает работу с QEMU в macOS. У про­екта есть офи­циаль­ный сайт и ре­пози­торий на GitHub. Отдель­но сто­ит отме­тить галерею го­товых обра­зов для быс­трой рас­катки. Сре­ди ожи­даемых сис­тем мож­но най­ти ReactOS (x86), Sun Solaris (SPARC), Mac OS 9.2.1 (PPC) и ста­руш­ку Windows XP (x64). Конеч­но, эти ребята в эму­ляции будут работать не так быс­тро, как гос­тевые сис­темы с под­дер­жкой ARM, зато как зре­лищ­но!

Я прак­тичес­ки не исполь­зую это решение, пос­коль­ку работать с соф­том в гос­тевой ОС все же неудоб­но, да и ста­биль­ность не бле­щет. Но быва­ют слу­чаи, ког­да эта шту­ка может выручить.

Су­щес­тву­ет, кста­ти, и вер­сия UTM для iOS, но уста­новить ее мож­но толь­ко через сай­дло­адинг.

VirtualBox (спойлер: его нет)

Увы, раз­работ­чики это­го популяр­ного опен­сор­сно­го решения для вир­туали­зации пока что не доб­рались до M1. А это зна­чит, что нель­зя запус­тить и вир­туал­ки с Android вро­де Genymotion, NoxPlayer и BlueStacks. Так что пока при­ходит­ся доволь­ство­вать­ся Android Developer Studio.

Metasploitable3

Ког­да я попытал­ся исполь­зовать эту вир­туаль­ную машину для тес­тирова­ния экс­пло­итов, то стол­кнул­ся с проб­лемой. Запус­тить ее получи­лось лишь в QEMU, но работать с ком­фортом это не поз­воля­ет — про­изво­дитель­ность выходит слиш­ком низ­кая.

К тому же в macOS Big Sur и Monterey QEMU не может исполь­зовать проб­рос пор­тов через NAT из‑за отсутс­твия TAP-устрой­ств (вир­туаль­ные сетевые драй­веры ядра сис­темы для эму­ляции Ethernet). Единс­твен­ная воз­можность — пере­адре­сация локаль­ного пор­та на вир­туаль­ную машину, как в при­мере с уста­нов­кой Ubuntu Server выше и SSH-дос­тупом к ней.

DOCKER И NODE.JS

Сей­час с Docker слож­ностей прак­тичес­ки нет. При­ложе­ние дав­но натив­ное, уста­нов­ка — стан­дар­тная.

Единс­твен­ный нюанс, о котором хочет­ся рас­ска­зать, — это отсутс­твие в Docker Hub вер­сий некото­рых обра­зов для ARM. А еще быва­ет, что образ есть, но в нем несов­мести­мые биб­лиоте­ки, которые нуж­но переком­пилиро­вать. Если в пер­вом слу­чае все оче­вид­но, то о вто­рой проб­леме я бы хотел погово­рить под­робнее.

Нап­ример, в сво­ем про­екте я стол­кнул­ся с тем, что невоз­можно соб­рать модуль sharp@0.28.3 для Node.js в базовом обра­зе Node из Docker Hub.

INFO

Sharp — это высокос­корос­тной модуль Node.js для пре­обра­зова­ния боль­ших изоб­ражений рас­простра­нен­ных фор­матов (JPEG, PNG, AVIF и WebP) в более мел­кие.

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

Суть проб­лемы — в том, что в обра­зе Docker для сбор­ки зависи­мос­тей пакета sharp необ­ходима биб­лиоте­ка libvips вер­сии 8.10.6 или стар­ше, которая идет с glibc 2.29+. В сво­ем фай­ле сбор­ки я исполь­зовал образ node:16.3-buster-slim с glibc 2.24. Понадо­билось вруч­ную собирать под­ходящую вер­сию libvips.

Мой Dockerfile:

FROM node:16.3-buster-slim

WORKDIR /opt/app

ADD . .

RUN npm install

RUN npm run build api

CMD ["node", "./dist/apps/api/main.js"]

Лог уста­нов­ки Sharp на node:16.3-buster-slim:

#8 21.23 sharp: Installation error: Use with glibc 2.24 requires manual installation of libvips >= 8.10.6

#8 21.23 sharp: Please see https://sharp.pixelplumbing.com/install for required dependencies

#8 21.47 npm WARN The package typescript is included as both a dev and production dependency.

#8 21.48 npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/fsevents):

#8 21.48 npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm64"})

#8 21.48

#8 21.51 npm ERR! code ELIFECYCLE

#8 21.51 npm ERR! errno 1

#8 21.51 npm ERR! sharp@0.28.3 install: `(node install/libvips && node install/dll-copy && prebuild-install) || (node install/can-compile && node-gyp rebuild && node install/dll-copy)`

#8 21.51 npm ERR! Exit status 1

В такой ситу­ации нуж­но или пересо­бирать libvips для ARM64, или же исполь­зовать более све­жий образ опе­раци­онной сис­темы. Нап­ример, мож­но взять node:14-alpine, который уже содер­жит ском­пилиро­ван­ные для ARM бинар­ники и занима­ет на 700 Мбайт мень­ше, чем Debian.

Я выб­рал хар­дкор­ный вари­ант перес­борки биб­лиоте­ки libvips под ARM64. Добавил нес­коль­ко строк в Dockerfile:

FROM node:16.3-buster-slim

RUN apt-get update -qq && apt -y upgrade && \

apt-get install -y git build-essential libpng-dev wget pkg-config glib2.0-dev libexpat1-dev autoconf nasm libtool dpkg g++

RUN wget https://github.com/libvips/libvips/releases/download/v8.12.1/vips-8.12.1.tar.gz

RUN tar xf vips-8.12.1.tar.gz && cd vips-8.12.1 && ./configure && make && make install && ldconfig

WORKDIR /opt/app

ADD . .

RUN npm install

RUN npm run build api

CMD ["node", "./dist/apps/api/main.js"]

И собираю без оши­бок.

docker build -t test -f apps/api/Dockerfile .

В общем, ког­да работа­ешь на менее популяр­ной архи­тек­туре, это может вре­мя от вре­мени при­водить к проб­лемам вро­де той, что я опи­сал. Но зато теперь ты зна­ешь, что делать в таких слу­чаях!

ПРОКСИРОВАНИЕ ТРАФИКА ПРИЛОЖЕНИЙ MACOS

Для перех­вата и ана­лиза тра­фика есть отличная ути­лита mitmproxy, а в паре с ProxyChains-ng они спо­соб­ны замит­мить прак­тичес­ки любое при­ложе­ние macOS, которое исполь­зует HTTP.

В начале статьи мы делали быс­трые али­асы для перек­лючения архи­тек­тур, теперь самое вре­мя их при­менить. К сло­ву, под­дер­жку macOS Monterey и M1 в ProxyChains-ng добави­ли сов­сем недав­но — в начале янва­ря 2022 года.

Мы соберем две раз­ные вер­сии биб­лиотек libproxychains4.dylib для работы с обе­ими архи­тек­турами. Боль­шинс­тво прог­рамм уни­вер­саль­ны и ском­пилиро­ваны для двух архи­тек­тур сра­зу (Mach-O universal binary). Нап­ример:

$ file /usr/bin/python

/usr/bin/python: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]

/usr/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64

/usr/bin/python (for architecture arm64e): Mach-O 64-bit executable arm64e

Вер­сии для x86_64 и для ARM пред­назна­чены для работы с при­ложе­ниями, соб­ранны­ми под соот­ветс­тву­ющие архи­тек­туры. Нач­нем с x86_64.

$ intel

$ arch

i386

$ git clone https://github.com/rofl0r/proxychains-ng

$ cd proxychains-ng

$ ./configure

$ make && make install

Про­буем, нап­ример с TOR:

$ proxychains4 curl icanhazip.org

[proxychains] config file found: /usr/local/etc/proxychains.conf

[proxychains] preloading /usr/local/lib/libproxychains4.dylib

[proxychains] DLL init: proxychains-ng 4.15-git-8-g2739fb5

[proxychains] Strict chain ... 127.0.0.1:9050 ... icanhazip.org:80 ... OK

45.153.160.135

От­лично работа­ет для ути­литы curl. Давай поп­робу­ем сде­лать прок­си для Telegram. Он как раз написан толь­ко под ARM, и нам пот­ребу­ется пересоб­рать proxychains4.

Удос­товерим­ся, что это при­ложе­ние для ARM:

$ file /Applications/Telegram.app/Contents/MacOS/Telegram

/Applications/Telegram.app/Contents/MacOS/Telegram: Mach-O 64-bit executable arm64

Все так, теперь меня­ем архи­тек­туру:

$ arm

$ arch

arm64

Пе­ресо­берем ProxyChains-ng:

$ make clean

$ ./configure

$ make

Здесь я намерен­но не делал make inastall, так как зат­рется пре­дыду­щая вер­сия. Буду запус­кать из пап­ки proxychains-ng. Пос­ле сбор­ки бинар­ник и биб­лиоте­ка лежит в кор­не. Под­коррек­тирую кон­фиг:

$ cp src/proxychains.conf ./

$ sed -i '' 's/socks4/#socks4/g' proxychains.conf

$ echo "http 127.0.0.1 8080" >> proxychains.conf

Те­перь уста­новим mitmproxy:

$ brew install mitmproxy

Про­верим работу:

$ mitmproxy

Ус­тановим необ­ходимые сер­тифика­ты:

$ sudo security add-trusted-cert -d -p ssl -p basic -k /Library/Keychains/System.keychain ~/.mitmproxy/mitmproxy-ca-cert.pem

В одной вклад­ке тер­минала запус­каем mitmproxy, в дру­гой — Telegram через proxychains:

$ ./proxychains4 /Applications/Telegram.app/Contents/MacOS/Telegram

Ко­неч­но, помимо «Телег­рама», мы можем перех­ватывать, нап­ример, целый Firefox и смот­реть, куда летят зап­росы самого бра­узе­ра или его рас­ширений:

$ proxychains4 /Applications/Firefox.app/Contents/MacOS/firefox

Та­ким обра­зом мы можем зах­ватывать тра­фик прак­тичес­ки любых при­ложе­ний для macOS. К сло­ву, для ана­лиза тра­фика на интерфей­се всег­да мож­но исполь­зовать Wireshark, который с вер­сии 3.6.0 стал натив­ным при­ложе­нием для архи­тек­туры ARM.

WI-FI И ЗАХВАТ ПАКЕТОВ

Стан­дар­тный адап­тер Wi-Fi, который ста­вят в мак­буки, впол­не неп­лохо работа­ет в режиме монито­рин­га и поз­воля­ет зах­ватывать пакеты на опре­делен­ном канале. Про­демонс­три­рую это на прак­тике:

$ sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport

$ airport -s # Смотрим сети

$ sudo airport -z # Отключаемся от активных сетей

$ airport <interface> sniff <channel>

$ ls /tmp/airportSniff*.cap

Од­нако со встро­енным адап­тером не вый­дет исполь­зовать Wifite2 и про­чие подоб­ные ути­литы для Linux, так как aircrack-ng на M1 пока что соб­рать нель­зя. Если без них тебе не обой­тись, при­дет­ся исполь­зовать внеш­ний адап­тер и вир­туаль­ную машину.

WWW

До­пол­нитель­ную информа­цию о работе с Wi-Fi стан­дар­тны­ми метода­ми macOS можешь узнать из от­лично­го матери­ала Пав­ла Жов­нера.

ПРОГРАММЫ ДЛЯ IOS

На­пос­ледок — еще одно занят­ное отли­чие от машин с Intel. На «маках» с M1 воз­можен запуск при­ложе­ний, раз­работан­ных для iOS, для это­го дос­таточ­но зай­ти в App Store и выб­рать соот­ветс­тву­ющую вклад­ку. Это удоб­но. Нап­ример, у меня дома есть нес­коль­ко умных розеток, но, кро­ме мобиль­ного при­ложе­ния, спо­соба управлять ими нет. По умол­чанию все при­ложе­ния для iOS дос­тупны на «маках» с M1, но раз­работ­чики могут при желании зап­ретить исполь­зование на дес­кто­пе.

ВЫВОДЫ

Мо­гу с уве­рен­ностью ска­зать, что это один из луч­ших ноут­буков для работы. Исполь­зую его как замену дес­кто­па с док‑стан­цией и внеш­ним монито­ром (к сожале­нию, одним, но боль­шим и широким). Прек­расная энер­гоэф­фектив­ность и рекор­дная мощ­ность обес­печены луч­шим на сегод­няшний день тех­про­цес­сом и архи­тек­турой, где память рас­положе­на вплот­ную к про­цес­сору. Удоб­ная и безопас­ная ОС довер­шает кар­тину.

Бо­ять­ся ARM не нуж­но. При­ложе­ния для Intel велико­леп­но запус­кают­ся через Rosetta 2, вир­туали­зация отлично работа­ет прак­тичес­ки без потери про­изво­дитель­нос­ти, и даже Windows 11 ARM смо­жет тран­сли­ровать при­ложе­ния x86_x64 в код для ARM. Все твои при­ложе­ния внут­ри Windows будут работать, вплоть до дебаг­геров и Visual Studio с ком­пиляци­ей про­ектов в x86_64.

Да, проб­лемы еще встре­чают­ся, но они реша­емы, и раз­работ­чики активно тру­дят­ся над тем, что­бы через год‑дру­гой о сов­мести­мос­ти мож­но было не думать вов­се. Про­шед­ший год показы­вает, что это впол­не реаль­но.

Под­водя итог: Apple Silicon — это рабочее решение, которое я даже не думаю менять на что‑то дру­гое. А на самый край­ний слу­чай всег­да есть уда­лен­ный сер­вер с клас­сичес­кой архи­тек­турой.

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei