Valve и Collabora показали предварительную версию Holo Core — варианта Arch Linux для архитектуры AArch64. Именно эта система должна стать основой программной платформы Steam Frame, нового устройства Valve с процессором на архитектуре Arm.
На первый взгляд новость выглядит довольно буднично: взяли Linux, пересобрали пакеты под другой процессор и опубликовали результат. На практике перед нами один из важнейших этапов подготовки нового оборудования Valve. Причём работа может оказаться полезной не только владельцам Steam Frame, но и всему сообществу Arch Linux.
SteamOS меняет архитектуру
Современная SteamOS построена на базе Arch Linux. Правда, Valve использует не обычную установку Arch, а тщательно зафиксированный снимок репозиториев, собственные исправления, графический интерфейс, механизмы обновления и компоненты, необходимые для запуска игр.
На Steam Deck эта схема работает на привычной для персональных компьютеров архитектуре x86_64. Большинство игр для ПК, Steam, Proton и огромное количество системных библиотек исторически ориентированы именно на неё.
Steam Frame, судя по опубликованной информации, использует процессор с архитектурой AArch64. Это 64-разрядный вариант Arm, широко применяемый в смартфонах, одноплатных компьютерах, энергоэффективных ноутбуках и устройствах виртуальной реальности.
Такой выбор вполне логичен. Для носимого устройства особенно важны энергопотребление, нагрев и время автономной работы. Мощный процессор x86_64 можно поставить почти куда угодно, но его ещё нужно охлаждать и питать от аккумулятора. В гарнитуре каждый лишний ватт превращается в тепло рядом с лицом пользователя.
Однако переход на Arm означает, что привычную программную основу SteamOS нельзя просто скопировать на новое устройство.
Почему Arch Linux нельзя было просто установить
Arch Linux официально не поддерживает AArch64. Существуют сторонние проекты, которые переносят систему на Arm, но Valve требуется не экспериментальная сборка для энтузиастов, а воспроизводимая промышленная платформа.
Разница огромна.
Домашнему пользователю достаточно однажды собрать рабочую систему. Производителю устройства нужно уметь снова и снова получать предсказуемый результат: для разработчиков, испытательных образцов, серийных устройств, обновлений и восстановления системы.
Collabora пришлось решать сразу несколько связанных задач:
⚙️ собирать свежие пакеты Arch Linux для чужой архитектуры;
🧩 вычислять правильный порядок сборки тысяч пакетов и их зависимостей;
🔄 учитывать постоянные изменения Arch Linux, поскольку это непрерывно обновляемый дистрибутив;
🏗️ создать инфраструктуру непрерывной интеграции, которой у исходного Arch Linux для такой задачи фактически нет;
📦 получать не разовый архив с файлами, а воспроизводимое дерево пакетов, пригодное для разработки и выпуска устройства.
Иными словами, Holo Core — это не только набор двоичных файлов. Главная ценность проекта скрывается в системе, способной эти файлы заново построить.
Несколько тысяч пакетов — и это ещё не весь Arch
Collabora пока не пересобрала весь репозиторий Arch Linux. Первоначальная цель скромнее: подготовить пакеты, необходимые для разработки Steam Frame и создания системных образов.
Но даже ограниченный набор вместе со средой сборки и рабочими зависимостями разрастается до нескольких тысяч пакетов.
Это хорошо показывает, насколько обманчиво выражение «перенести Linux на другую архитектуру». Само ядро Linux давно работает на AArch64. Проблема начинается выше: в компиляторах, интерпретаторах, системных библиотеках, упаковщиках, графическом стеке и инструментах, которые зависят друг от друга.
Чтобы собрать условный пакет А, может потребоваться пакет Б. Для пакета Б нужен инструмент В, а инструмент В собирается библиотекой Г. Если Г ещё не существует для новой архитектуры, вся цепочка останавливается.
Получается задача, похожая на строительство лестницы, по которой нужно подняться, пока самой лестницы ещё нет.
Зачем воспроизводить историю обновлений
Особенность Arch Linux — модель непрерывных обновлений. У системы нет редких крупных выпусков, между которыми программная основа долго остаётся неизменной. Пакеты постоянно переходят на новые версии.
Для обычного пользователя это удобно: свежие ядра, драйверы и программы появляются быстро. Для команды, которая догоняет Arch на новой архитектуре, та же особенность превращается в движущуюся мишень.
Представим, что разработчикам нужен Rust версии 1.91. Его нельзя во всех случаях собрать при помощи произвольной старой версии. Сначала может понадобиться Rust 1.90, для него — 1.89, а цепочка продолжится до версии, использованной при начальной загрузке системы.
Пропустить промежуточные ступени не всегда возможно. Более новые пакеты нередко создаются инструментами из непосредственно предшествующих выпусков. Поэтому инфраструктура Collabora должна не только смотреть на итоговое состояние репозитория, но и восстанавливать путь к нему.
Разработчики называют этот подход воспроизведением истории сборок. Система анализирует дерево зависимостей, находит необходимые промежуточные версии, исправляет порядок операций и последовательно доходит от начальной среды до выбранного снимка Arch Linux.
На мой взгляд, именно это является главным техническим достижением проекта. Готовый пакет можно потерять или заменить. Надёжный процесс его получения намного ценнее.
Порядок публикации не равен порядку сборки
В репозитории, хранящем историю состояния Arch Linux, пакеты не всегда появляются в последовательности, пригодной для полной пересборки системы с нуля.
Для работающего дистрибутива это обычно не проблема. Разработчики обновляют уже существующую среду, где старые библиотеки и инструменты доступны. Но при переносе на новую архитектуру приходится исходить из почти пустого пространства.
Поэтому Collabora самостоятельно строит корректную последовательность. Система должна понимать не только прямые зависимости пакета во время работы, но и инструменты, необходимые при его создании.
Особенно неприятны переходы между версиями системных библиотек, меняющими имя или номер своего двоичного интерфейса. Старый менеджер пакетов pacman может зависеть от прежней библиотеки, тогда как новый pacman должен быть связан уже с обновлённой. В момент сборки нужны обе версии, и их нельзя бездумно заменить одну другой.
Это тот случай, когда обновление одного компонента напоминает ремонт двигателя на движущемся автомобиле: новый инструмент создаётся при помощи старого, который сам зависит от заменяемых деталей.
Время тоже ломает сборки
Даже если сохранить описания пакетов и их версии, историческая сборка не обязательно повторится спустя несколько месяцев.
Исходный код мог переехать на другой сервер. Проект мог сменить владельца или систему размещения. Ссылка могла исчезнуть. Короткий идентификатор изменения в Git иногда начинает разрешаться иначе, а контрольная сумма загружаемого содержимого — перестаёт совпадать.
Есть и более современная проблема: серверы защищаются от ботов, массовых загрузчиков и сборщиков данных для искусственного интеллекта. Они ограничивают частоту запросов, временно блокируют адреса или требуют дополнительную проверку. Для человека это небольшая помеха, а для автоматизированной сборочной линии — причина падения всего процесса.
Получается парадокс: старое программное обеспечение может быть исправным, но собрать его сегодня сложнее, чем в день выпуска. Воспроизводимость требует сохранять не только рецепты, но иногда и исходные материалы, ключи, промежуточные инструменты и сведения об окружении.
Что уже опубликовано
Предварительная версия Holo Core включает исходники, готовые двоичные пакеты и контейнер для разработки. Опубликованные материалы соответствуют выбранному снимку состояния Arch Linux с исправлениями, необходимыми для AArch64.
Контейнер особенно интересен разработчикам. Если в распоряжении есть устройство на AArch64, среду можно запускать непосредственно. Если имеется только компьютер x86_64, команды для Arm разрешается выполнять через пользовательскую эмуляцию QEMU и механизм binfmt ядра Linux.
Схема выглядит так:
🖥️ компьютер x86_64 запускает контейнер, предназначенный для AArch64;
🔍 ядро распознаёт двоичный файл чужой архитектуры;
🧰 выполнение автоматически передаётся эмулятору QEMU;
📦 внутри контейнера разработчик получает Holo Core с pacman и обычными инструментами сборки;
🐢 программы работают медленнее, чем на настоящем процессоре Arm, зато для экспериментов не требуется отдельное устройство.
Collabora отдельно предупреждает о тонкостях запуска программ с повышенными привилегиями через эмуляцию. Изменение глобальных настроек binfmt может разрешить выполнение AArch64-файлов с установленным признаком смены пользователя. Это удобно для автоматической установки зависимостей, но затрагивает модель безопасности компьютера. Слепо копировать подобную настройку на рабочую машину не стоит.
Holo Core пока нельзя считать готовым дистрибутивом
Слово «предварительная» здесь важно. Collabora опубликовала доказательство работоспособности подхода, а не универсальную замену Arch Linux для всех устройств Arm.
Пока Holo Core ориентирован на конкретную продуктовую задачу — создание основы Steam Frame. В репозитории отсутствует часть пакетов обычного Arch Linux, некоторые программы могут не собираться, а сама инфраструктура формирования дерева пакетов ещё не открыта.
Тем не менее результат уже достаточно зрелый, чтобы разработчики могли запускать контейнер, устанавливать обновления из опубликованного репозитория и собирать собственные пакеты AArch64.
Это разумная стратегия. Публикация ранней версии позволяет проверить не только код, но и документацию, доступность исходников, поведение зеркал и реальные сценарии сторонних разработчиков. Чем раньше обнаружатся архитектурные тупики, тем дешевле их исправить до выпуска устройства.
Но как на Arm запускать компьютерные игры
Holo Core решает только нижнюю часть задачи. Операционная система может прекрасно работать на AArch64, однако большинство игр в Steam по-прежнему поставляется для x86_64. Proton помогает запускать игры Windows в Linux, но сам по себе не превращает команды одного процессора в команды другого.
Для Steam Frame потребуется дополнительный слой трансляции процессорных инструкций либо потоковая передача изображения с другого компьютера. Возможна и комбинация подходов: лёгкие приложения выполняются на устройстве, совместимые игры переводятся локально, а самые тяжёлые запускаются на игровом компьютере и передают изображение в гарнитуру.
Программная цепочка в локальном варианте становится многослойной:
🎮 игра содержит инструкции x86_64 и обращения к интерфейсам Windows;
🪟 Proton переводит системные и графические обращения Windows в понятные Linux компоненты;
🔁 транслятор процессорных инструкций преобразует код x86_64 для выполнения на AArch64;
🐧 Holo Core предоставляет системные библиотеки, драйверы, управление устройством и среду запуска;
🥽 графический стек выводит кадры на дисплеи Steam Frame и обрабатывает данные датчиков.
Каждый дополнительный слой способен увеличить задержку и нагрузку на процессор. Для обычной игры небольшой скачок времени кадра иногда незаметен. В виртуальной реальности задержка между поворотом головы и изменением изображения ощущается гораздо сильнее и может вызывать дискомфорт.
Поэтому качество Steam Frame будет зависеть не только от производительности его процессора. Критически важны согласованная работа планировщика, компиляции шейдеров, драйверов, трансляции кода и системы виртуальной реальности.
Почему Valve не взяла Android
Процессоры Arm привычно ассоциируются с Android, и возникает очевидный вопрос: зачем переносить Arch Linux, если готовая система уже существует?
Android действительно имеет зрелую поддержку Arm, но он устроен не как обычный настольный Linux. У него своя модель приложений, библиотек, разрешений, графического вывода и распространения программ. Перенос SteamOS на Android означал бы необходимость адаптировать значительную часть инфраструктуры Valve к другой платформе.
Holo Core позволяет сохранить привычные инструменты Linux: pacman, контейнеры, стандартные библиотеки, существующие службы и большую часть уже разработанной архитектуры SteamOS. Для Valve это возможность поменять аппаратную основу, не отказываясь от программной философии Steam Deck.
И здесь просматривается важная стратегия компании: SteamOS постепенно превращается из системы для одной портативной консоли в семейство платформ. Разные устройства могут иметь разные процессоры и способы взаимодействия, но пользоваться общей моделью обновлений, разработки и распространения игр.
Польза для Arch Linux может оказаться больше самого Steam Frame
Collabora планирует сотрудничать с основной командой Arch Linux и надеется открыть больше созданных инструментов. Если инфраструктура действительно будет передана сообществу, работа Valve может ускорить появление более официальной и воспроизводимой поддержки AArch64 в Arch.
Это особенно интересно на фоне роста количества настольных устройств Arm. Долгое время архитектура была почти синонимом смартфонов и встраиваемой техники. Теперь она постепенно осваивает ноутбуки, серверы, мини-компьютеры и игровые устройства.
Arch Linux хорошо подходит пользователям, которым нужны свежие ядра, Mesa и драйверы. Именно такие компоненты особенно быстро развиваются на новом оборудовании. Но без надёжной сборочной инфраструктуры поддержка новой архитектуры остаётся набором отдельных усилий.
Holo Core способен изменить положение:
🌱 сообщество получит практический опыт переноса тысяч актуальных пакетов;
🏭 появится проверенная модель непрерывной сборки для AArch64;
🧭 инструменты научатся отслеживать движущиеся зависимости Arch Linux;
🛠️ исправления совместимости смогут попадать в исходные проекты, а не храниться только внутри Valve;
💻 производителям устройств станет проще рассматривать Arch-подобную систему как основу продукта.
Разумеется, пока это скорее направление движения, чем гарантированный результат. Сами инструменты Collabora ещё готовятся к публикации, а интересы коммерческого устройства и универсального дистрибутива не всегда совпадают. Но намерение работать с основной командой Arch Linux выглядит хорошим знаком.
Что публикация говорит о готовности Steam Frame
Вместе с крупным обновлением интерфейса SteamVR появление публичной основы операционной системы создаёт ощущение, что проект перешёл из стадии лабораторных образцов в стадию подготовки программной экосистемы.
Обычно производителю нет смысла открывать контейнеры, пакеты и инструкции, если аппаратная платформа постоянно меняется. Такая публикация косвенно указывает на стабилизацию ключевых технических решений.
При этом делать вывод о скором начале продаж рано. Между работающим деревом пакетов и готовым потребительским устройством остаются испытания обновлений, энергопотребления, восстановления после сбоев, совместимости игр и драйверов. Для гарнитуры к этому добавляются отслеживание положения, обработка контроллеров, звук и жёсткие требования к задержке изображения.
Но фундамент уже виден. И это не рекламный макет, а вполне осязаемые исходники, пакеты и среда разработки.
Почему эта новость важнее очередного анонса Linux-сборки
Мне Holo Core интересен прежде всего как признак взросления игровой экосистемы Linux. Раньше аппаратный производитель мог собрать закрытый образ, выпустить устройство и годами поддерживать собственную ветку исправлений. Valve и Collabora пытаются создать процесс, который можно повторять, проверять и в перспективе передать выше по цепочке.
Это менее эффектно, чем демонстрация гарнитуры на сцене. Зато именно такая скучная инфраструктура определяет, будет ли устройство получать обновления через три года и смогут ли сторонние разработчики нормально с ним работать.
Главный риск понятен: Holo Core может остаться узкоспециализированной внутренней основой Steam Frame, а обещанное сближение с Arch Linux затянется. Перенос непрерывно обновляемого дистрибутива требует постоянных ресурсов. Недостаточно один раз догнать репозитории — после этого за ними нужно бежать без остановки.
Но если Collabora доведёт непрерывную сборку до состояния, когда она сможет следовать за Arch Linux почти автоматически, выигрыш окажется двойным. Valve получит устойчивую основу для Steam Frame и будущих устройств Arm, а сообщество — инструменты, которые давно были нужны для полноценного AArch64-направления.
Holo Core пока не отвечает на главный потребительский вопрос: насколько хорошо Steam Frame будет запускать игры. Зато он даёт ответ на другой, не менее важный: Valve строит для нового устройства не одноразовую прошивку, а полноценную Linux-платформу. И именно с таких незаметных технических решений обычно начинаются экосистемы, способные пережить первое поколение оборудования.
Источники
- GamingOnLinux — анонс предварительной версии Holo Core: https://www.gamingonlinux.com/2026/07/collabora-announce-a-preview-of-holo-core-an-aarch64-port-of-arch-linux-for-steam-frame/
- Collabora — техническое описание переноса Arch Linux на AArch64: https://www.collabora.com/news-and-blog/news-and-events/building-an-arch-linux-aarch64-port-for-holo-core.html
- Phoronix — публикация экспериментальной сборки Holo Core: https://www.phoronix.com/news/Holo-Core-Experimental-ARM64
- Репозиторий исходников Holo Core: https://gitlab.steamos.cloud/holo/holo-core-aarch64-preview
- Репозиторий двоичных пакетов Holo Core: https://holo-packages.steamos.cloud/holo-core-aarch64-preview/mash-20251118