Здравствуй, хабр! 

Пришло время для моей новой статьи по Linux и в этот раз довольно необычной. Я буду разбирать способы “подружить” x64 архитектуру с компьютером на ARM64 (AArch64) архитектуре. 

Вообще, тут стоит сделать небольшое отступление и рассказать про развитие компьютеров в общем. 

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

Я не собираюсь в данном историческом экскурсе рассказывать про Apple II или Commodore Amiga, или ZX Spectrum 64/128K. Смысла имеет довольно мало. 

Историческая справка про IBM архитектуру

Начну свой рассказ с IBM, которая в конце 70-х начинала распространять свою архитектуру 8088, на которую в последствии был выпущен процессор intel 8086 в 78 году.

Архитектура была поистине революционной с точки зрения потребителя и разработчиков оборудования. IBM сделала ставку на модульность и открытость платформы. Каждый мог сделать свой модуль и продавать его (видеокарта/звуковуха - модуль).

Решение такое было принято не просто так, IBM хотели как можно быстрее выйти на рынок и обогнать конкурентов. Разрабатывать свою архитектуру с нуля и сделать к ней периферию дело, мягко скажем, стоит денег и времени. Благодаря модульности разработка периферии была вопросом уже сторонних компаний. 

Это была эпоха домашних ПК с MS-DOS и 16-ти битными процессорами.

Кстати, подобные ПК назывались (может кто-то ещё помнит такое название, словите ностальгию) IBM-совместимыми ПК. Как раз из-за модульности ПК, удобно было помечать на коробках с оборудоованием, что, например, вот "эта" графическая карта является IBM-совместимой (или, в данном случае, игра).

Позже произошёл нормальный процесс эволюции существующий архитектуры на 32-битную. Первым процессором Intel для 32-бит был Intel 80386. 

Ещё чуть позже IMB хотели сделать (и сделали) 64-битную архитектуру, но вот тут проблема. Они, по сути, хотели обнулить обратную совместимость со старыми технологиями, за что IA-64/Itanium и невзлюбили. 

Новую 64-битную архитектуру сделали также и AMD, что в итоге и стала стандартом до сих пор.

На данный момент, по сути, единственной современной архитектурой для настольных ПК осталась AMD64 и развития пока никакого дальше нет (интересно, а будет ли век 128-ми битных ПК?). 

Да, кстати, может многие не знают, но от названий процессоров пошло название архитектуры в том же Linux. Как стандарт приняли x86 (32-бита), которая называется почти везде i386 (от названия процессора Intel 80386), а x64 почти везде это AMD64 (уже именно от разработчика архитектуры, а не процессора). 

Фан факт. Например, когда вы устанавливаете GRUB как загрузчик, вы обязательно в комманде по установке, в target пишете архитектуру. Так вот, для x86 вы бы писали grub-install --target=i386, но для x64 не AMD64, а уже более полное название как grub-install --target=x86_64-efi. 

Причём тут я должен оговорится, что в первом случае это не совсем и архитектура процессора, а скорее маркер того, что в системе не поддерживается UEFI, а используется классический BIOS. 

Историческая справка про ARM архитектуру

История ARM архитектуры совсем другая, но её тоже стоит затронуть.

Итак, ARM как архитектура появилась в 83-м году в Англии. Цель была одна - получить энегроэффективную архитектуру и процессор, так как тогдашние процессоры и микроконтроллеры жрали энергию как не в себя (что и щас, кстати, продолжается. Пример, сравните macbook на ARM чипе и любой современный ноут. Если mac живёт от батареи как телефон [Около 18-24 часов], то обычный ноут хорошо если часов 6-8 проживёт. Мой вообще с завода держит ~2.5 часа. Позор) и было сделано решение сделать монолитную систему на чипе (SoC). 

По сути, SoC это просто плата где есть сразу всё - и процессор, и графика (обычно внутри процессора), и другие модули типа камер или динамиков. 

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

Я такой подход абсолютно не поддерживаю, но, скажем так, рыночек порешал. Мало кому действительно нужно, чтобы можно было что-то менять. Просто купят новый, если старое устарело, а не полезут там что-то менять.

Современные ARM устройства (ПК/Ноутбуки) могут поддерживать что-то унифицированное. Так, допустим, недавний ноут от Microsoft - Surface Laptop 7, который на Snapdragon X Elite, был продавлен теми же Microsoft для некой унификации и там есть UEFI, который вполне может поддерживать загрузку с флешки, но это далеко от большинства устройств на ARM. 

Приведу развитие ARM архитектуры:

ARMv1–v2 (1985–1986)

Зарождение архитектуры, первые Acorn Archimedes.

ARMv3 (1991)

Первая 32-битная полноценная функциональная версия, на базе которой Apple делала Newton.

ARM7TDMI (1994–1997)

Огромный коммерческий успех.
Этот чип стал популярен в мобильных телефонах и даже в Game Boy Advance.
Именно отсюда ARM стал «мировым» стандартом в мобильной электронике.

ARMv6 (2002)

Переход к мультимедиа, SIMD и улучшенной производительности.
Использовался, например, в первых iPhone (ARM11).

ARMv7 (2005–2009)

Появление Cortex-A8 / A9, переход к смартфонам как «мини-компьютерам».
Аппаратный FPU, NEON, большие кеши.

ARMv8-A (2011–2013)

Появление 64-битной архитектуры ARM.
Apple первой представила 64-битный ARM в iPhone 5s (A7) в 2013 году.

(список сделан ChatGPT).

В данный момент, все устройства выходят на архитектуре ARMv8-A или просто ARM64. Мой сегодняшний аппарат тоже на ARM64.

Какие именно различия есть между x64 и ARM

Тут стоит сразу оговорится, в данной статье я буду называть только 2 архитектуры - ARM и x64 для удобства. Под x64 я буду иметь ввиду что 32-битный софт, что 64-битный. У ARM такой проблемы не будет, так как найти софт под 32-битный ARMv7 это та ещё задачка.

Основное различие между двумя процессорами (тоже буду обобщать вот так) это, как минимум, их вариант ассемблера. На самом низком уровне они отличаются просто кардинально. 

Вот пример двух простых Hello World кода для x64 и ARM:

X64:

section .data
    msg db "Hello, world", 0xA
    len equ $ - msg

section .text
    global _start

_start:
    ; write(1, msg, len)
    mov rax, 1          ; syscall: sys_write
    mov rdi, 1          ; fd = 1 (stdout)
    mov rsi, msg        ; buf
    mov rdx, len        ; count
    syscall
    ; exit(0)
    mov rax, 60         ; syscall: sys_exit
    xor rdi, rdi        ; status = 0
    syscall

ARM:

.section .data

msg:
    .ascii "Hello, world\n"
    .equ msg_len, . - msg
    .section .text
    .global _start
    .type _start, %function

_start:
    ; write(1, msg, msg_len)
    mov     x0, 1          /* fd = 1 (stdout) */
    adr     x1, msg        /* buf (address of msg) */
    mov     x2, msg_len    /* count */
    mov     x8, 64         /* syscall: __NR_write = 64 */
    svc     0
    ; exit(0)
    mov     x0, 0          /* status = 0 */
    mov     x8, 93         /* syscall: __NR_exit = 93 */
    svc     0

Разница в данном примере особо не видна (кроме названий регистров), но тут есть моменты, где есть серьёзные отличия. В ARM ассемблере используется RISC ассемблер, у которого одно из свойств - быть “простым”. Команд в разы меньше, чем у того же AMD64.

Вот для примера:

• ARMv7 - 200+ Инструкций

• ARMv8 (AArch64) - ~150-200 Инструкций

• AMD64 - >1500 Инструкций

• AMD64 + AVX-512 - >2000 Инструкций

Поскольку статья не про ассемблер, я вдаваться в детали не вижу смысла. К тому же, я и сам его не знаю (всё хочу когда-нибудь попробовать что-то написать на нём), просто привёл как пример отличия. 

Просто взять и “запустить” приложение от x64 на ARM чисто физически не выйдет. 

Для этой цели есть бинарные трансляторы, которые берут бинарник AMD64 и “на лету” преобразовывают его в понятные для ARM инструкции, что и делает возможным его запуск.

По сути, если вы когда-либо сталкивались с .NET или Java, вы знаете что такое JIT - Just In Time Compilation (компиляция во времени). 

Когда вы компилируете .NET приложение на C#, вы получаете на выходе IL-код, который потом интерпретируется виртуальной машиной, которая уже его и запускает в виде бинарника. Это если очень упрощённо. Опять же, тут речь не про работу .NET или Java. Я взял это как пример.

Ваш код скомпилированный под x64 является ассемблерным. По сути, тот же IL-код, только низкоуровневый. Потом этот ассемблерный код с помощью бинарного транслятора запускается на ARM64.

Минусы данного подхода тоже есть, он медленный. Как и тот же JIT в разы медленнее, чем условный C++ скомпилированный в ассемблер (бинарь под конкретную архитектуру), но это всё равно быстрее, чем запускать целую виртуальную машину, где уже будет установлена система x64 (было бы устройство у меня мощнее, я бы там запустил QEMU, но увы. Я тут повешусь быстрее от такого удовольствия). 

В чём сложность с бинарными трансляторами для Linux. Сравнение с macOS и Windows

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

Linux в данном случае из своего преимущества превращается в лютое наказание. Я говорю про его “раздробленность”.

Как выглядит условное Windows-приложение? Это просто папка, где лежит сам бинарник (.exe) и его библиотеки. Это подход windows - тащить все зависимости с собой.

Так же устроены и mac-приложения. .app это, по сути, папка, где лежит бинарь, его какие-либо ассеты (картинки, иконки и тп) и, может быть, конфиг.

У Linux в данном случае хаос. Всё управляется пакетным менеджером и лежит по совершенно разным папкам (да, я буду называть директории папками, так удобнее). 

Допустим, вы решили установить GIMP. Написали команду типа

sudo apt install gimp
# или 
sudo pacman -Sy gimp

Как вы думаете, что происходит дальше?

А дальше начинает происходить хаос. 

Все библиотеки автоматически улетают в /usr/lib (не путать с /var/lib, там лежат не библиотеки, а данные. Убил бы того, кто давал названия дирректориям в UNIX), бинари в /usr/bin, ассеты в /usr/share, конфиг системный, скорее всего, в /etc (если он идёт вместе с приложением, а то может и не идти и будет там создан, ну или в окружении пользователя по пути $HOME/.config). 

И это удобно в контексте обычной системы. Так как у вас нет дублирования зависимостей.

Представьте себе, у вас установлено 100 приложений, и все эти приложения хотят одну и ту же библиотеку, gtk например. И вот они все её тащат с собой. У вас 100 приложений, 100 версий одной и той же библиотеки, которая работает одинаково, но зачем-то у вас сто различных её вариаций. 

И тут ещё один подвох, одно приложение использует обычно около 10-15 библиотек, а то и больше. А не много ли это? Много. 

Поэтому в Linux/Unix приняли решение держать всё в одном месте, где каждый нуждающийся может получить что ему надо.

Но от этого:

1. Вы не можете держать 2 версии одной и той же программы, ибо если одна старая, то она хочет старые зависимости, а ВСЯ система живёт по новой. Фиг вам, а не старая версия. 

2. Обновить одно приложение у вас НЕ выйдет, так как если ему нужно, условно, libc_10.1, а во всей системе используется libc_10.0, то у вас упадёт вся система и пакетник вас пошлёт очень далеко за такие деструктивные действия.

3. Одни библиотеки НЕ уживаются с другими. Конфликт зависимостей (у меня такое было, поставил из AUR программу, которая притянула ноду, а мне нужна была новая версия ноды. И вот тут начинается дилемма, нужна ли вам программа с одной версией ноды, или вам нужна новая нода, но тогда приложение скажет “досвидос”. 

А теперь о наболевшем. С запуском приложений через байтовые трансляторы начинается головная боль (тут должно было быть слово на букву Е, но на хабре матерится нельзя, а очень хочется). 

Представьте себе, что вы ставите программу, которая хочет QT. А теперь вопрос, как вам прокинуть ВЕСЬ QT к этой программе (тот который нужен разумеется, а не совсем всё)? А вот ответ. Никак.

Проблема ещё и в том, что скачать версию под AMD64 из интернета (не QT, а программы) вы врядли сможете вообще.

Система настолько заточена под пакетник, что бинарей собранных в инете просто не найти обычно (кроме deb-пакетов или .tar.zst). А уж библиотек - тем более.

У этого всего хаоса есть один способ решить проблему и я как раз его и покажу.

Поэтому, то, что работало спокойно в windows (библиотеки прям в папке с прогой) и в macOS (тоже самое), в linux работать НЕ БУДЕТ. 

Условная Rosetta 2 от Apple просто берёт все библиотеки из .app папки приложения. Prism (не Minecraft лаунчер, а бинарный транслятор от Microsoft) будет делать ровно тоже самое. 

Пакеты байтовых трансляторов на Linux

На linux я нашёл 2 адекватных варианта запуска прог x64 на ARM. Это пакеты Box64/86 и FEX. 

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

Либо я доку не вкурил, либо сам пакет сделан плохо (ну, пока не будет в этом потребности, ничего хорошего и не будет, а её пока нет, так как нет спроса на ARM ноуты). 

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

Но я в этой статье его, разумеется, покажу. Это стоит показать как вариант, который в “теории” может работать, хотя у меня ничего и не вышло.

А вот FEX это совершенно другой зверь. 

Насколько я знаю, за FEX стоят Valve, так как они хотят выпускать новый Steam Deck на ARM. Это как с Wine, как только за дело взялись Valve и начали активно контрибутить в wine, он резко стал лучше. Неожиданно, правда?

Причём Valve в этом всём даже адекватные. Они не забирают себе технологии и делают их платными, отнюдь, они всё выкладывают в открытый доступ для ВСЕХ. Габену однозначно респект за это. 

Но FEX работает очень… своеобразно. Ему обязательно нужен RootFS. 

Что такое RootFS и как его сделать

RootFS - корневая файловая система, по сути то, что находится у вас в /, только “автономная”. Её можно выкачать куда угодно и, сделав chroot, попасть в систему, со всеми её бенефитами в виде пакетника, файловой структуры и тп. 

Чтобы его сделать, его нужно откуда-то выкачать. А откуда? И какой именно лучше?

Я буду делать RootFS от Debian. Почему поясню чуть позже, когда мы дойдём до настройки подопытного.

PS. Я только щас понял одну очень важную проблему, которую я допустил в момент создания RootFS. Я сделал версию RootFS Debian 13, а установлена на ПК у меня 12! Лучше так не делать. Я всю статью кидал в 13 дебиан пакеты от 12. Лучше такое не делать, хотя у меня и всё работало.

Я не буду сейчас описывать детальное создание RootFS, его я дам чуть позже. Но команду для скачки и последующей настройки, лучше всего запускать на x64 ПК.

Почему именно так? Всё просто. 

Когда вы делаете chroot в “папку”, вы там запускаете шелл. Условно, не относительно всей системы, а относительно “папки” с этой RootFS. И он там будет x64. Когда вы пытаетесь сделать chroot на ARM, он пытается запустить x64 бинарь условного /usr/bin/bash, что он сделать не может и chroot не удаётся. 

Чисто в теории, это можно как то так настроить, чтобы можно было и с системы на ARM туда входить, но я пока не сильно понял как.

Хотя тут я немного слукавил. Способ есть - QEMU. Но вот вопрос, на вашем одноплатнике вообще мощности хватит запускать ВИРТУАЛЬНУЮ МАШИНУ? У меня точно нет. Поэтому этот способ есть, но он малопригоден для реальной эксплуатации (в моих условиях. Думаю, на Snapdragon X Elite с этим проблем не будет совсем). 

Чтобы выкачать RootFS образ (тарбол, который распакуется в папку) используется вот такая команда:

sudo debootstrap --arch=amd64 stable ./debian64 http://deb.debian.org/debian

Что она значит: --arch=amd64 - архитектура системы (можно поставить AArch64 и получить ARM образ), stable - релиз debian (есть также unstable, sid), ./debian64 - папка, куда будет сам образ распакован, http://deb.debian.org/debian - сервер Debian, откуда выкачивается RootFS. 

debootstrap надо предварительно установить в систему. 

На debian делается так:

sudo apt install debootstrap -y

На arch так (я буду делать с ноута, где установлен arch):

sudo pacman -Sy debootstrap --noconfirm

На чём буду тестировать я

У меня не особо большой выбор ARM устройств. Тем более куда я могу установить Linux. Телефоны не в счёт. 

Поэтому, тестировать и демонстрировать я буду всё с моего одноплатника - Orange Pi 3B.

Перед началом прикреплю его фотки

У меня есть напечатанный корпус для него, поэтому большую часть времени, если я и буду ещё прикреплять фотки его, он будет в нём.

Установка Debian 12 Bookworm (XFCE)

Вот тут начинаются сложности. ARM это не обычный IBM-совместимый ПК. 

Что вы делаете, если хотите поставить Linux на обычный комп? Ищете ISO образ, пишете на флешку и просто ставите. А вот тут - фиг вам.

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

Причём сложность в том, чтобы найти все драйвера, выставить бутфлаги* и тп. Это очень долго и муторно. Если у вас был опыт портирование прошивки на телефон (а у меня был), то знаете как это трудоёмко.

* - бутфлаги это опции для ядра Linux. Грубо, это как биос, но зависящий от системы, а не от оборудования. Там указывается что, когда и как нужно чтобы было запущено. Если хотите починить нерабочий выход HDMI - вам туда. Но там этих бутфлагов тысячи, чтобы найти что вам нужно, нужно потратить просто уйму времени.

Я ничего собирать сам не собираюсь, это слишком долго и нерелевантно для моих задач. 

У всех одноплатников (будь то малина, или апельсин) есть свой сайт. На нём, в разделе по вашему одноплатнику, будут лежать образы системы, которые вы можете накатить. 

Ссыль.

Выбор… не богат. Мягко скажем. 

Итого из этого:

• Android - мимо. Не работает с SD карты, хочет NVME диск или eMMC память. 

• AOSP - не проверял, но должен заработать *

• OrangePi OS (Arch) - фигня лагучая. Туда какой-то гений китаец приделал KDE! Оно вот просто запускается и виснет с 100% загрузкой почти с нулевой.

• Ubuntu - сломана к чертям, не заливается нормально на SD

• Debian (armbian) - работает отлично, его я и буду использоать

• OpenWRT - не мой профиль, но проверить будет интересно потом. Может быть в других статьях

* - Кхм, сколько сколько ты бл весишь?! Что там у тебя за звездолёт хранится- то, а? 25 гигов!! Куда тебе столько…

Чтобы записать сам образ на флешку, качаем его и записываем программой USBImager (Rufus или balenaEtcher мне ломали образ). Или обычным dd, если на linux.

Выбираем образ, флешку и ждём пока туда образ запишется.

Причём, с SD у меня произошёл “прикол”. У меня есть 2 флешки на 64 гига, 10 класс, но вот тут есть особенность. OPI у меня отказалась грузится с Kingston флешки, а с SP Elite - спокойно. Поведение странное, но как есть. Имейте ввиду.

Вообще, если у вас до сих пор нет ПК на linux - самое время его сделать. Так как флешка будет в формате ext4 и винда его просто не увидит (с драйвером увидит, но, вроде, только для чтения), так что нам в любом случае делать всё через него…

PS. Я пока тут делал себе флешку, решил посмотреть что такое OPI OS (OH) и да, я был прав. Это OpenHarmony (хуавеевская ось, на которой базируется HarmonyOS). Проблема в том, что она у меня не загрузится никогда. Как я это понял? А вот это по этим светодиодам. 

Если у вас горит жёлтый всегда (а не мигает), то “диск” (SD) не отвечает на команды и не читается. Причём тут это зависит от системы. Увидели, что оно не мерцает? В утиль ось и/или карточку. У меня так одна карта и стала непригодной (для этого одноплатника, в телефоне она хорошо работает как флешка), когда ни одна ось с неё не загрузилась ни разу…

Так, ну в общем. Я загрузил систему. Вот фотография (первая и последняя, пока ещё ничего не настроил), дальше будут скрины.

Что я рекомендую сделать сразу же:

1. Поставить нормальный пароль на пользователя, каждый раз orangepi вводить утомляет. Я обычно люблю ставить что-то типо 1234 (на тестовые машины тем более, кто их у меня дома взломает кроме меня?), но гнидство системы заключается в том, что вот фиг вам, а не короткий пароль, но через рута спокойно ставится.

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

3. Установить zsh и ohmyzsh. Тоже база для меня. Автокомплит по TAB в шелле для меня необходимость, чтобы потом не страдать (причём и на рут и на обычного пользователя, с разными темами для отличия кто есть кто)

4. Установить браузер свежее (FF в моём случае)

5. Установить samba для передачи файлов по локальной сети (я ей так и не воспользовался...)

6. Я себе поставил Konsole (простите kde-шника, не могу без неё) и spectacle для скриншотов

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

Вот финальный скрин на данный момент:

Кстати, для анализа того процессора, который тут стоит. 

Я делаю статьи в Google Docs и мне туда надо каким-либо образом передавать скрины. Я это обычно делаю через телегу или макс (я макс использую как буфер обмена между компами (тем более, где я могу накатить такое, что потом будет сносить не жалко), его не жалко забить барахлом в ЛС).

Так вот, я зашёл в FF и зашёл на оба ресурса по очереди (веб версии). Смотрите загрузку:

Они оба долбятся в 100% на данном проце. У меня больше нечего сказать про его производительность. 

Вообще, в моём OPI 3B стоит процессор Rockchip RK3566. Я сделал условное сравнение между 4 последними моими процессорами ARM в пользовании. 

1. Rockchip - OPI 3B

2. Snapdragon 665 - Mi A3

3. Snapdragon 778G - Mi 11 Lite 5g NE

4. Kirin 9000S1 - Huawei Pura 70 (текущий основной смарт)

Конечно, я не могу слепо доверять GPT в этих вопросах, да и самой табличке тоже, но для общего понимания характеристик этого точно достаточно. 

Я хотел найти на сайтах по сравнению, но на одном был Rockchip RK3566, а на другом не было никаких из других процессоров. 

Да, сравнение некорректное с точки зрения того, что Linux и Android довольно сильно отличаются, в сферах применения так точно, но просто показательно, что процессор Rockchip RK3566 21 года в разы слабее, чем средне-низко бюджетный Snap 665 19 года, и уж тем более чем Snapdragon 778G 21 года. 

Причём, если условно взять Antutu от RK3566 и от Snap 665 (разница в год, не в пользу snap), то разница в производительности аж в 2 раза, а если взять одногодку Snap 778G, то разница аж в 6 РАЗ! (синтетические тесты, конечно, не показатель, но вот работоспособность в реальности у меня это ужас. Я чувствовал будто сижу на первом пеньке в 11 винде. Всё очень медлено и всё виснет)

Установка необходимых пакетов для запуска x64

Box86/64

Данное чудо нужно собирать самостоятельно (в основном). Бинарных пакетов нигде нет, сборка у меня занимает ~1 час на одну прогу (а их 2). 

Я буду, логично что, ставить только одну версию. Так как её для показывания всего хватит за глаза (попробуйте ещё найти в современном мире 32-битную прогу под линь). 

Сайт Box64. 

Зависимости нужно смотерть на Github проекта, а точнее на странице документации.  

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

В этот раз я попробую поставить отсюда. Это по сути скрипт, поэтому я сделаю просто .sh файл и запущу его, но без последних строк:

Да, репа добавилась и я могу оттуда скачать Box64. Не буду в этот раз час ждать.

После установки проверяем установку простой командой Box64:

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

FEX

FEX - утилита довольно новая. Насколько знаю, была разработана Valve и будет установлена в новой консоли от Valve - Steam Deck 2 (название может быть другое). 

FEX работает совершенно по другому принципу внутри. Для работы ему нужен обязательный RootFS x64. 

Вообще, FEX позволяет загрузить свой, готовый RootFS образ системы (на выбор Ubuntu, Debian, Fedora, Arch), но тут есть проблема. Без VPN* он не загружается, просто сервера не дают ничего скачать.

Я VPN* для этого использовать не собираюсь и создам свой RootFS, может быть и более тяжёлый, может быть, более кривой, но лучше сделать самому, чем пытаться выкачать что-то готовое, но через кривой интерфейс.

Но перед началом создания RootFS я хочу обозначить свою позицию - что я вообще добиваюсь в итоге. 

Я хочу сделать такую систему, которая сможет спокойно “переварить” любой графический пакет (приложение), без дополнительных шаманств с библиотеками. Этого можно добиться простой установкой фреймворка QT или GTK+, а лучше и оба. 

Но вот это сделать сложно.

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

Если вы, допустим, качаете приложение от KDE, то логично, что у вас ДОЛЖНЫ быть библиотеки QT и некоторые библиотеки KDE. Чтобы выкачать всё, проще просто установить KDE, которое мы используем чисто для установки зависимостей. 

Да, это будет занимать ОЧЕНЬ много места (базовый RootFS на Debian весит ~1.2 Г, а с KDE (мета-пакет) 7.8Г!), но за последующий комфорт нужно, всё таки, платить. В данном случае - местом.

Я уверен, что есть менее варварский вариант установки всех стандартных зависимостей (не “влоб”) (да есть, скрипты с документации FEX. Я их просмотрел в первый раз), но я его не нашёл. Позже, мы доступ к RootFS, скорее всего, не получим. Поэтому делаем всё сразу. 

Создание RootFS x64 на x64 машине

Для создания правильного RootFS нужна машина на x64 (как я говорил выше, можно и с ARM, но с использованием QEMU). В моём случае это ноут. Он удобен тем, что в него встроен ридер именно MicroSD карт, а не SD (или вообще отсутствует).

Это означает, что я легко могу скопировать этот образ прямо на образ системы с Debian для ARM. 

На моём ноуте (MSI Modern 14 c12m) установлен Arch последней версии, на котором я уже делал до этого RootFS. Поэтому, программа debootstrap уже установлена. Если у вас её нет, то мотните статью чуть выше, где я рассказывал про RootFS и установите её. 

Далее, нужно выкачать чистый образ RootFS. Для этого воспользуемся командой:

sudo debootstrap --arch=amd64 stable ./DEB_RFS http://deb.debian.org/debian

Процесс пошёл, теперь только ждать пока RootFS скачается и его можно будет настраивать:

Так, у меня ошибка появилась. Вопрос отчего… Возможно от того, что я перед этим обновил свои пакеты pacman… Перезагружусь и попробую заново. (Да, именно после обновления пакетов у меня всё и навернулось. Там затронулся пакет с ip-tables и ещё что-то. У меня вся сеть отвалилась) 

Как только образ скачается, не спешите в него чрутаться.

Нам нужно внутрь него прокинуть файл /etc/resolve.conf, иначе не будет интернета в системе. 

Либо можете проверить что у вас в системе лежит в /etc/resolve.conf и в вашем RootFS. У меня что там, что там, вот это:

Заходим в систему RootFS:

sudo chroot DEB_RFS /bin/bash

Далее, делаем стандартное обновление чисто системы, ставим нужные пакеты:

sudo apt update
sudo apt upgrade -y
sudo apt install neovim less zsh git curl -y

Если что-либо будет ругаться на отсутсвие /proc, /dev и тп, просто смело игнорируйте. Это не нужно в нашей ситуации совершенно.

Я сразу поставил ещё и OMZ, что сделает дальнейшие действия в системе (и возможные вне ноута) проще:

А теперь думаем что ставить - Gnome или KDE. В прошлой тестовой сборке RootFS я ставил KDE. В этот раз поставлю Gnome, так как программ использующих GTK+ в разы больше, чем QT.

Для этого пишем:

sudo apt install gnome

Я потом покажу сколько на самом деле будет весить данный образ (и сколько весит с KDE).

Как только всё установилось, можно выходить со спокойной душой из RootFS, оно нам больше не нужно.

А вот моё обещанное сравнение веса с KDE и Gnome:

Ощутимо меньше.

Я не собираюсь копировать прям папку на SD. Это будет очень долго. Я предлагаю сделать тарбол с bz2 сжатием. Для этого напишем:

sudo tar -cjvf DEB_RFS.tar.bz2 DEB_RFS

В команде tar самое главное помнить, что первый аргумент это ВЫХОДНОЙ файл, а второй уже входной. Это вот специфика линукса, что всё наоборот. Сначала выход, потом вход. 

Опция -j означает, что он будет в момент создания запакован в bzip2 формат (точнее сжат, tar это архив, а bz2 уже формат сжатия). 

Вот тарбол с KDE весил на выходе 2.9 Г, а текущий тарбол с Gnome весит 1.4 Г:

Далее я копирую на свою SD-карту с помощью команды rsync (по некоторым личным причинам я не использую для этих целей cp).

sudo mount /dev/mmcblk0p2 /mnt

rsync -aP DEB_RFS.tar.bz2 /mnt/home/orangepi

Далее вынимаем SD и она готова для развёртывания FEX.

Установка FEX

Для установки FEX, заходим на сайт с докой и ставим оттуда все зависимости. Этот проект точно нужно будет собирать руками.

PS. Сайт может не загрузится без VPN◉.

PSS. Уже после написания статьи, я увидел, что FEX распространяет скрипты для создания своего образа RootFS по их образцу:

Может быть, я добавлю отдельную секцию в статью, но и текущий мой (костыльный) способ работает, поэтому пока делать я это точно не буду.

Нам нужны вот эти зависимости, я сделал большую команду:

sudo apt install \                                                                                                                                            
git \
cmake \
ninja-build \
pkgconf \
ccache \
clang \
llvm \
lld \
binfmt-support \
libssl-dev \
python3 \
g++-x86-64-linux-gnu \
libgcc-12-dev-i386-cross \
ibgcc-12-dev-amd64-cross \
nasm \
python3-clang \
libstdc++-12-dev-i386-cross \
libstdc++-12-dev-amd64-cross \
libstdc++-12-dev-arm64-cross \
squashfs-tools \
squashfuse \
libc-bin \
libc6-dev-i386-amd64-cross \
lib32stdc++-12-dev-amd64-cross \
qtdeclarative5-dev \
qml-module-qtquick-controls \
qml-module-qtquick-controls2 \
qml-module-qtquick-dialogs

Далее, выкачиваем сурсы, делаем папку Build, заходим, вызываем конфигурацию и запускаем сборку:

git clone --recurse-submodules https://github.com/FEX-Emu/FEX.git

cd FEX
mkdir Build
cd Build

CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DUSE_LINKER=lld -DENABLE_LTO=True -DBUILD_TESTING=False -DENABLE_ASSERTIONS=False -G Ninja ..

ninja

После сборки, написать 

sudo ninja install

Как всё установилось, можно продолжать:

По документации, создаём папку ~/.fex-emu/RootFS и туда распаковываем папку:

(тут заминка произошла, команда не сработала, я её распаковал в ~, а потом просто перенёс туда)

Размер папки после распаковки

Но фетчер RootFS почему-то не увидел мой RootFS…

Не беда, запускаем утилиту конфигурации FEX и настриваем RootFS там:

Отлично, конфигурация увидела этот RootFS. Жмём на кружок (он был пустой) и он добавляется как активный (можно ещё, как вариант, просто использовать переменную и в неё путь прокинуть, но я забыл название этой переменной :\).

Ещё раз вызовем утилиту по скачиванию RootFS

Ура, он больше не предлагает ничего скачивать. Всё правильно. 

Тестирование

FEX

Я не просто так начинаю тестирование именно с FEX. Он в разы интереснее, чем тот же Box64. 

Давайте запустим что-нибудь из стандартных утилит гнома. О, калькулятор.

Пишем вот такую команду. 

FEX .fex-emu/RootFS/DEB_RFS/usr/bin/gnome-calculator

Что тут происходит? А вот что. 

Из нашего RootFS берутся все зависимости. По сути, это такой огромный бандл, где есть всё необходимое. Бинарник оттуда же, но запускаем мы его уже вручную. 

Когда он начинает запрашивать библиотеку A, то FEX смотрит в /usr/lib ИЗ нашего RootFS:

После этого (спустя ~1 минуту ожидания) у меня запустился калькулятор. 

Он вполне себе функционирует, хотя и очень лагает.

Установка стороннего приложения в RootFS

Кстати, тетрис. Давайте поставим в наш RootFS новую прогу, в данном случае игру. Как это сделать, если мы не можем зайти внутрь? Довольно просто. Нам нужно получить deb пакет.

Какие есть варианты по скачиванию deb пакетов?

Веб интерфейс

Мы можем зайти на ftp сервер и просто выкачать оттуда пакет. Заходим сюда, выбираем нужную версию дистра (bookworm) и начинаем искать пакет. 

Это явно Games:

Вот этот пакет:

В чём преимущество - тут можно всегда посмотреть все зависимости:

Но! Мы же установили перед началом Gnome, все (АБСОЛЮТНО) зависимости у нас уже ЕСТЬ. Нам нужен чисто deb-пакет:

Вот тут можно его и выкачать

Вот, допустим, ссылка "http://ftp.us.debian.org/debian/pool/main/q/quadrapassel/quadrapassel_40.2-1_amd64.deb" по которой можно выкачать его. Можем использовать wget и просто его скачать (я покажу на WSL, так как на системе сделал иначе).

Теперь можно его будет просто установить.

НО, это не наш выход. Вы ведь не забыли, что я не просто так установил именно Debian на ARM?

Скачивание напрямую из пакетного менеджера

Есть вариант достать нужный пакет проще. В разы проще. Если у вас есть apt в системе (к слову, его можно даже в arch поставить, прописать debian репы и он будет работать, но насколько хорошо - тут не скажу). 

Но есть проблема. У нас, всё таки, arm архитектура, а apt не может качать инородние архитектуры. Но это тоже не беда. Её надо просто доабвить в систему. 

Чтобы это пофикисить, есть вариант добавить архитектуру:

sudo dpkg --add-architecture amd64

sudo apt update

И вот уже наша архитектура установлена:

Теперь можно просто написать:

apt download <package>:amd64

и будет выкачана именно версия под amd64!

Но вот теперь самый главный вопрос, а как это поставить? Вручную. Но для этого надо знать что внутри deb-пакета. 

До этого я никогда не распаковывал пакеты. Просто незачем было, хотя всегда было интересно что внутри. Если вам тоже, то вот что там на самом деле.

По сути, там есть только папка /usr, со всеми файлами пакета. Когда пакт устанавливается, он просто “распаковывается” в /usr. Так вот, нам надо сделать тоже самое.

Распаковать пакет можно с помощью команды

dpkg -x <package> <path>

Заметьте, распаковка идёт В КОРЕНЬ системы. Так как папка /usr именно там.

Чтобы её запустить делаем тоже самое, что и в случае с калькулятором. Чисто прокидываем бинарник в FEX, но у меня произашла некоторая проблема, которую я не заскринил. Проблема в общем со схемами. 

Проблему со схемами я решу чуть позже, но сначала поставлю ещё одну игру - gnome mines.

Также выкачиваем deb пакет, распаковываем и пробуем запускать:

А вот тут прикол, не хватает зависимости. Ну что, решаем ровно также, как и ставили пакет. Просто его качаем и распаковываем ТУДА ЖЕ:

После этого ловим ТУ ЖЕ ошибку со схемами… 

Схемы в GTK это нечто особенное. Весь интерфейс в гтк идёт в xml (если на андроид кодили, могли тоже самое увидеть там), но когда он запускается, он должен “скомпилироваться” в схемы. Это происходит автоматически. Но вот же беда, когда мы ставим пакет руками, этого не происходит, отчего вылезает ошибка. 

Чтобы это решить, нужно воспользоваться командой по их сборке:

Заметьте - я использую СИСТЕМНУЮ утилиту, а не утилиту внутрь RootFS. В качестве папки для выхода указываю схемы в RootFS. 

После этого запускаем Mines и вуаля:

Пробуем запускать тетрис, и…

Оно тоже работает (но у меня игра зависла…)

То есть, что я показал в этом блоке:

1. Как скачивать deb пакеты из интернета

2. Как скачивать пакеты deb amd64 на arm apt

3. Как добавить архитектуру

4. Как их “ставить” в RootFS

5. Что лежит в deb пакете

6. Как установить зависимость в RootFS

7. Работоспособность x64 приложений на arm linux

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

Установка Wine на FEX

Далее я буду показывать Wine установку на FEX, так как это самое частое его использование. Но вот игры будут очень специфичными.

Поскольку я уже демонстрировал установку wine в своей прошлой статье, я повторяться не буду и отправлю вас туда.

Тут я не буду пробовать ставить приложения с зависимостями и ковырянием wine, это очень долго и тут это будет работать очень плохо. Поэтому остановлюсь на чистой работоспособности (ps. Которой не будет совсем). 

Для начала, нам нужно поставить wine. На debian это сделать довольно проблематично.

В официальных репах нету вообще wine. Никакого. 

Изначально я хотел скачать версию с WineHQ, но вот проблема. Deb пакет, который можно скачать с репозитория (подключаемого) НЕ содержит, почему-то, бинарников. 

То есть, как я добавлял данный реп:

1. Добавил репозиторий в apt:

2. Скачал ключ и вставил его:

3. На выходе получил, что репозиторий подключился и можно с него выкачать deb пакет:

4. Качаю пакеты:

И вот что лежит внутри:

Вопрос - откуда брать пакеты в /opt? А вот не знаю (видимо их откуда-то качает пакетник и туда кладёт, но у меня нет пакетника, который это бы скачал).

Поэтому, я пошёл по пути наименьшего сопротивления - выкачал пребилд пакет с github:

Распаковал тарбол:

Скопировал в RootFS (я замещал прошлые битые файлы, поэтому из GUI делал. Так проще и быстрее):

Теперь тут прям бинарники:

И он даже запускается:

Попробовал запустить конфигурацию и получил отвал библиотеки:

Не беда, скачиваем библиотеку и суём куда надо.

apt download libc6:amd64 libc6:i386

И вот тут получаю вот такую ошибку:

И это на любую активность с wine. Что запуск .exe, что запуск встроенных утилит. Просто на всё. И это не проблема бинарника или программы. Это уже проблема FEX, которую я решать не буду. 

Для начала, я не знаю как. Документация у FEX хоть и есть, но она довольно скудная. Там не описано подобное поведение. Плюс, там нет вхождения как запускать wine или что-либо ещё (а это важно, так как может быть разное, очень непредсказуемое, поведение). 

Формально, FEX работает. Он запускает программы, он даже wine запустил, но вот не запустил всё остальное с wine. Так что проверка wine на FEX откладывается до лучших времён. Тут уже я встрял в самом инструменте (и я перепробовал массу способов это исправить, ни один из них не заработал). 

PS. Возможно, проблема может быть в бутфлагах или чём-либо ещё, но мне уже не хочется это изучать и смотреть, так как система работает так медленно, что сидеть на ней я уже не хочу совсем. Это пытка была, всё это тестировать и скринить. Я кажется не подойду больше к ARM ещё очень долго, помня этот опыт.

BOX64

Сразу скажу, что тут меня тоже ждал облом, но уже в другом. Но обо всём по порядку. 

Как установить Box64 я уже говорил чуть выше - либо собирать, либо репа в apt. У меня вариант 2.

Я не буду качать новых программ (смысла нет), так как у меня есть RootFS. Брать бинарники и библиотеки планирую оттудова.

Запускать я буду, успешно работающий, gnome-calculator. 

Для этого вводим команду:

box64 .fex-emu/RootFS/DEB_RFS/bin/gnome-calculator

На что получаем вот такой выхлоп:

Нам тут важна вот эта часть:

Он просто не может подгрузить библиотеки. А вот тут нужно сделать небольшое отступление и рассказать как это чудо работает с библиотеками и ассетами программ. 

Box64 очень хитрый и не хочет использовать только библиотеки от x64. Он берёт часть библиотек из системных и “оборачивает” вызовы так, чтобы x64 программа умела его использовать. Вот эта особенность и подвела меня под монастырь чуть позже. 

Ну ладно, думаю я, пофиг, прокинем библиотеки. Оно же так сработает? Ведь сработает?

Все библиотеки нужно прокидывать Box64 через специальную переменную - BOX64_LD_LIBRARY_PATH. Указывать нужно папку с ними. Если папок несколько - нужно разделять их : и \.

Пример:

export BOX64_LD_LIBRARY_PATH=\
"/rootfs/lib/x86_64-linux-gnu:\
/rootfs/usr/lib/x86_64-linux-gnu:\
/rootfs/usr/lib/x86_64-linux-gnu/gtk-3.0:\
/rootfs/usr/lib/x86_64-linux-gnu/gio/modules:\
/rootfs/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders:\
/rootfs/usr/lib/x86_64-linux-gnu/pango/1.8.0/modules"

У меня папка всего одна - .../usr/lib/x86_64-linux-gnu. Там лежат все нужные библиотеки. 

Команда у меня выглядит так:

А на выходе получаем чуть более огромный лог, чем в прошлый раз:

Притом, что он снова жалуется на отвалившиеся библиотеки… Сволочь, за что?!

Ладно, учапал в GPT за ответами. Он предложил мне создать полностью изолированную среду, чтобы Box64 даже не пытался тянуть библиотеки с системы. Зачем - расскажу чуть позже. 

Ну начал этот процесс. Он сделал вот такой скрипт, который копирует все библиотеки и бинари в отдельную папку в $HOME:

#!/bin/bash
set -e
ROOTFS="$HOME/.fex-emu/RootFS/DEB_RFS"   # <<< CHANGE THIS TO YOUR TRIXIE ROOTFS PATH
DEST="$HOME/calculator"
echo "Using Trixie rootfs: $ROOTFS"
echo "Copying into: $DEST"

# Create directory structure
mkdir -p "$DEST/runtime/lib"
mkdir -p "$DEST/runtime/share"
mkdir -p "$DEST/runtime/loades"
mkdir -p "$DEST/runtime/gtk4"
mkdir -p "$DEST/bin"

echo "Copying GNOME Calculator binary..."

rsync -aP "$ROOTFS/usr/bin/gnome-calculator" "$DEST/bin/"
echo "Copying core libraries..."

rsync -aP "$ROOTFS/usr/lib/x86_64-linux-gnu" "$DEST/runtime/lib/"
echo "Copying GTK4 modules..."

rsync -aP "$ROOTFS/usr/lib/x86_64-linux-gnu/gtk-4.0" "$DEST/runtime/gtk4/"
echo "Copying GDK-pixbuf loaders..."

rsync -aP "$ROOTFS/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0" "$DEST/runtime/loaders/"
echo "Copying GIO modules..."

if [ -d "$ROOTFS/usr/lib/x86_64-linux-gnu/gio/modules" ]; then
    mkdir -p "$DEST/runtime/lib/x86_64-linux-gnu/gio"
    rsync -aP "$ROOTFS/usr/lib/x86_64-linux-gnu/gio/modules" \
        "$DEST/runtime/lib/x86_64-linux-gnu/gio/"
fi

echo "Copying XDG data (themes, schemas, icons, locales)..."

rsync -aP "$ROOTFS/usr/share" "$DEST/runtime/share/"

echo "Copy finished successfully."

echo "Run GNOME Calculator with: ~/calculator/run-calculator.sh"

Этот скрипт буквально просто копирует те же файлы, но в другое место. 

Потом создаётся вот такой скрипт запуска:

#!/bin/bash

R="$HOME/calculator/runtime"
BIN="$HOME/calculator/bin/gnome-calculator"

export BOX64_LD_LIBRARY_PATH="$R/lib/x86_64-linux-gnu"
export GIO_EXTRA_MODULES="$R/lib/x86_64-linux-gnu/gio/modules"
export GDK_PIXBUF_MODULEDIR="$R/loaders/gdk-pixbuf-2.0/2.10.0/loaders"
export XDG_DATA_DIRS="$R/share"
export GTK_PATH="$R/gtk4"

box64 "$BIN"

После этого всего, вводится вот такие переменные, чтобы Box64 был полностью отвязан от системы:

(Спойлер - не помогло)

Для начала, всё копировалось на этой машине ОКОЛО 15 минут! А размер папки (по обещаниям GPT “всего 50 метров”) оказался равен.. 2.9 гига:

Ну ладно, пофиг на рамер. Запускаемся.

И снова тоже самое…

В этот раз оказалось проблемой то, что Box64, зараза, тягает все “иконки” и другие ассеты ИЗ СИСТЕМЫ. А тут, как бы сказать, системой стоит debian, но 12… а вот RootFS я делал под 13:

Несовместимость версий библиотек и/или данных просто не даёт их запустить. Поэтому Box64 меня шлёт очень далеко и надолго. 

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

Итоги

Что я хочу сказать в итоге. Запуск инородней архитектуры это лютейший гемор. Никому не порекомендую этот способ мазохизма. 

Box64 оказался наименее удачным, из-за своей архитектуры, а FEX работает сносно, но требует огромного ковыряния руками. Как минимум создание своего RootFS (стоковые скачать из россии просто нереально) и понимание того, как устанавливать туда потом приложения. 

На данный момент, вся эмуляция x64 на ARM сырая донельзя. Пока не будет пользовательской базы, кому это реально нужно, ничего двигаться не будет (или очень медленно). 

Запуск Wine под транслятором это тоже гемор. Это делали и довольно успешно. Причём FEX изначально и позиционируется для него, но, скорее всего, ему нужна другая среда, а не та, которая есть у меня. 

Плюс, я за написание этой статье просто возненавидел этот одноплатник. Ощущение, что я запустил 11 винду на первом пне. Она бы там и то лучше работала, чем Linux на этом чуде. Работать просто отвратительно и медленно. Сайты грузятся медленно, файлы копируются тоже медленно, всё виснет, лагает. Скриншотилка грузится под секунд 10 (АУ, ЭТО СКРИНШОТИЛКА, А НЕ ЗВЕЗДОЛЁТ). Про веб TG/Max я вообще молчу. Мне эти 2 сервиса тупо намертво комп повесили. Я даже написать никому ничего не мог, он просто скролить не давал и делал это с пингом в 1000. 

Если у меня будет более достойное железо, то я сделаю ещё статью, где уже распишу про wine (очень интересно с ним поиграться на ARM, на телефоне же он работает, а тут не работает даже ARM версия ну вот никак) и попробую поковырять другие инструменты, если они будут, по запуску x64 приложений на ARM. Тема интересная, но уж больно сырая. 

Основная проблема осваивать FEX и Box64/86 в том, что нет гайдов и документаций. Или очень мало. Фиксить баги это отстой, когда не знаешь что именно сломалось. ИИ в этом случае тоже не помогают, им неоткуда брать референсы и часто они галлюцинируют так, что лучше вообще ничего не делать. 

Надеюсь кому-то эта статья чем-то помогла или просто узнали что-то новое. Спасибо за чтение. Оставляйте комментарии, если у вас был или будет опыт заниматься чем-то подобным. Будет интересно узнать ваш опыт.

PS. Пишу перед самой публикацией. Считаю что данная статья может быть реально полезна тем, что отрицательный результат - тоже результат. Она показывает насколько обычному человеку, который столкнётся с проблемой запуска будет ТЯЖКО. Те программисты, что написали FEX или Box64 запустят-то всё, так как они понимают как это всё работает, а вот я, которй просто решил проверить, убил на это недели 2 ковыряний, но пришёл вот к таким результатам, когда работает процентов 20% и на этом всё. Увы и ах.

◉ - средства обхода блокировок запрещены на территории РФ