SteamOS для самых маленьких
Вступление
Выход Steam Deck наделал много шума. По настоящему массовая x86-портативная консоль от именитой компании, за адекватную (на момент выхода) стоимость сразу привлекла к себе внимание.
А вишенкой на торте стал тот факт, что в роли операционной системы там находится не что-то самописное, и даже не windows, привычный большинству и раньше всегда используемый на x86-портативках. А некая SteamOS от самой компании Valve.
Но что это за зверь такой? Откуда он появился? Как Valve смогли её сделать? И делали ли они её вообще? И почему грамотный маркетинг всё ещё одна из основ рынка, позволяющая продать то, от чего в другой ситуации люди воротят нос.
Давайте разбираться!
При написании статьи я постараюсь найти баланс между глубокими техническими дебрями и пояснениями "для самых маленьких". Это означает что для одних статья будет неполной и поверхностной, а для других местами непонятной и сложной. Но этого не избежать. Так что, если вы чувствуете негодование при прочтении и желаете что-то дополнить или спросить непонятное, то комментарии открыты.
А ещё я могу вставлять очень глупые, но максимально понятные большинству аналогии.
Как Valve продаёт людям то, что они ни за что бы не купили
Для начала следует разобраться с тем, что вообще такое SteamOS.
Прямо на официальной странице указано: SteamOS — это операционная система на базе Linux, созданная Valve. И это описание полностью точное и избыточное. SteamOS это действительно просто собранный компанией Valve дистрибутив линукса.
Но что такое вообще линукс?
Всё просто - линукс это ядро. И больше ничего. Оно создавалось Линусом Торвальдсом именно как ядро.
Что делает ядро?
Оно взаимодействует с "железом", выполняет запуск, управляет процессами, памятью и т.д. В общем - делает всю "магию" скрытую от пользователя.
Но одного ядра мало для полноценной ОС. Хотелось бы этим ядром ещё как-то и управлять, запускать утилиты, работать с файлами, сетью и всем прочим, что мы привыкли делать на наших ПК. И вот этот дополнительный, более высокоуровневый слой утилит и превращает ядро в ОС.
А есть ещё понятие дистрибутива, которое Valve старательно избегает (и правильно делает, с коммерческой точки зрения). Дистрибутив это, по сути, сборка ОС. Например, пользователи Windows часто встречают сборки своей ОС от "репакеров" с вырезанным "мусорным" функционалом или с добавленным предустановленным ПО. Это тоже дистрибутивы, как и официальный образ с сайта M$.
В разрезе линукса, дистрибутив это ровно такая же сборка. Различают их так же предустановленный набор ПО, репозитории (сервера, откуда устанавливается ПО), пакетный менеджер, версии ядра и ПО, и много-много чего ещё.
Наверняка каждый хоть раз в жизни слышал про Ubuntu, Fedora, Debian, Arch. Всё это дистрибутивы линукса, которые представляют собой семейство ОС линукс, на базе ядра линукса.
Такая вот матрёшка.
Глупая аналогия:
Просто представьте, что ядро линукса это игровой движок. ОС - это инструменты для работы с графикой и анимацией, а дистрибутив - готовая игра. Причём мододелы могут выпускать свои версии сборок/дистрибутивов этой игры.
Таким образом мы приходим к выводу, что SteamOS это дистрибутив. Ведь так?
И да и нет. На самом деле, всё что я выше описал - не жесткие определения и рамки, которым все строго соответствуют. Споры о том где проходят границы этих терминов и чем является линукс идут с момента его зарождения. К тому же, одно вовсе не отменяет другого. Т.е. будучи дистрибутивом, ты автоматически являешься ОС. Только не самостоятельной.
Так что запись с официальной страницы не то чтобы врёт, она просто делает правильный ход, с точки зрения маркетологов - она не пугает пользователя страшными словами "дистрибутив линукса!" Ведь у пользователя будут ассоциации со страшной консолью, хакерами, бородатыми сисадминами... С чем угодно, но только не с играми.
А вот запись "ОС созданая Valve на базе линукса" уже не так пугает. И это действительно работает!
Например в разделе x86-портативок многие всё ещё верят в некую магию от Valve, которая доступна только лишь на их вручную сделанной ОС. Хотя реальность такова, что это просто дистрибутив на базе другого дистрибутива (да, в линуксе так можно. Привет BolgenOS), но с огромной проделанной работой.
SteamOS, форки и их отличия
SteamOS, как было сказано выше, это дистрибутив на базе Arch Linux. Но на самом деле, от Arch там только основная пакетная база. К тому же, в отличии от Arch, SteamOS - immutable дистрибутив.
Immutable - дистрибутивы в которых системные разделы находятся в режиме Read-Only. Это повышает надёжность, т.к. у пользователя просто нет возможности внести изменения в важные части ОС - ему доступны только пользовательские разделы.
Однако, у такого подхода есть существенный недостаток: из-за того, что системные разделы не доступны для записи, теряется и возможность установки дополнительного системного ПО, например драйверов. Но тут на выручку приходят технологии типа flatpak-пакетов.
Flatpak - система для создания, установки и запуска самодостаточных пакетов, т.е. они запускаются практически на любом дистрибутиве и работают одинаково. Они могут устанавливаться в пользовательские разделы, что спасает при использовании immutable-дистрибутивов. К тому же, они ещё имеют возможности для дополнительной изоляции, в целях повышения безопасности от вредоносного ПО.
Отличия SteamOS от Arch Linux заключаются не только в иммутабельности. Дополнительно Valve поставляет свою пропатченную версию ядра, сборка сразу включает в себя проприетарные драйвера для wifi и bluetooth, свои версии библиотек с патчами и многое другое
В целом, от Arch только берётся некий срез определённого состояния, потом он доводится до необходимого состояния и таким образом превращается в SteamOS.
Bazzite - это так же immutable дистрибутив, но уже на базе Fedora. К слову, Fedora задолго до этого имела свои собственные официальные иммутабельные варианты дистрибутива (Silverblue, Kinoite). Bazzite это просто более дружелюбный вариант подобных сборок, с уже предустановленным набором ПО, расчитанным на геймеров, и с некоторыми патчами от SteamOS.
Основным отличием будет тот факт, что в Bazzite присутствует дополнительный инструмент - rpm-ostree, который позволяет устанавливать в том числе и системные пакеты. Т.е. вполне спокойно можно установить драйвера для Nvidia, например.
Для x86-портативок в целом выбор дистрибутивов большой. По сути, любой линукс с установленным клиентом Steam добавленным в автозапуск в режиме Big Picture, автоматически превращает любой ПК в SteamOS. Вопрос только в оптимизации и дополнительных "quality of life" штуках.
Лучше ли производительность в играх на SteamOS?
Не совсем. Да, Valve использует свои патченные и самые свежие версии ядра и mesa (библиотека для работы с графикой), но рано или поздно эти патчи попадают и в остальные дистрибутивы. К тому же, все эти оптимизации проявляют себя, по сути, только на устройствах от Valve.
Почему же тогда все остальные не перейдут на патченные компоненты от Valve?
Дистрибутивы линукса это ОС общего назначения. Т.е. они должны быть одинаково стабильны как в работе, так и в играх. Даже если при этом они будут менее производительны в отдельных задачах. Стабильность и надёжность в приоритете.
Если вы хотите сделать себе домашнюю Steam Machine, на базе обычного ПК, и ждёте выхода дистрибутива от Valve - не тратьте время. Поставьте Bazzite или CachyOS. Те пару fps, которые для вас могла бы выиграть оригинальная SteamOS, не стоят затрат на время и подбор необходимого железа. А все патчи для VRR, HDR, FSR и т.д. либо уже в ядре, либо взяты этими дистрибутивами из патчей от Valve.
Если же вы выбираете дистрибутив для своей x86-портативки, то выбор уже не так однозначен, т.к. тут ещё имеет место быть энергопотребление. И если с самим Steam Deck или официально поддерживаемым Legion всё будет хорошо, что на SteamOS, что на Bazzite, то на всём остальном это немного лотерея из-за ACPI.
ACPI, это некая таблица, которая прошивается производителем железа в само устройство и из которого потом ОС может управлять частотами, TDP, гибернацией, батареей и вообще всем, что связанно с питанием устройства.
И даже если у вас именитый бренд, это вовсе не означает, что в нём есть необходимые или корректно написанные ACPI-таблицы, с которыми может взаимодействовать ОС. Отсюда и потенциальные проблемы - то что может не работать на одной версии ядра в одной сборке, может хорошо работать на другой версии в другой. И вполне даже может сломаться после очередного обновления.
Так что тут только пробовать и сравнивать. Иного варианта нет.
Proton или как продать под видом новинки то, что уже давно существует
Но не одной SteamOS известны Valve. Ведь в комплекте с ней, как неотъемлемая часть идёт ещё и Proton. Практически все, даже те кто далёк от линукс-гейминга, слышали как Valve сделали убер-инструмент для запуска игр на линуксе.
Вот только Valve ничего не изобретали, а просто очень удачно собрали в одном месте и доработали уже имеющиеся технологии.
Ещё в 90-х, с началом распространения Linux, энтузиастами был создан wine, ибо потребность запускать софт с только появившейся windows уже существовала.
Что такое Wine - его название говорит само за себя, т.к. это акроним. Расшифровывается он как: "Wine Is Not Emulator", т.е. Wine - это не эмулятор. И это очень важно!
Какие вообще существуют способы запуска софта от одной ОС на другой?
- Виртуализация. Это самый простой способ для конечного пользователя. Однако, он весьма накладный в части потребления ресурсов. Виртуальная ОС использует архитектуру CPU хоста, зачастую поддерживает проброс периферии и PCI-устройств, что избавляет от сложных настроек.
Т.е. пользователь буквально отдаёт физические RAM и ядра CPU виртуальной ОС. Зато при достаточно мощной аппаратной части у хоста, можно добиться весьма хорошей производительности для гостевой ОС.
Но главный недостаток виртуализации - можно запускать системы только той же архитектуры, что и у хоста.
- Эмуляция. Этот способ сложнее, т.к. приходится именно эмулировать другую архитектуру. Эмулируются как сам CPU, так и всё аппаратное окружение и взаимодействие между ними.
Этот способ позволяет запускать ОС и ПО от других архитектур.
Эмуляция бывает как софтовая, так и аппаратная.
Софтовая - это самая распространённая и используется практически во всех портативках.
Аппаратная - чаще всего сейчас это FPGA-платформы типа того же MiSTer FPGA. Ну или, например, во времена PS2, PS3 Sony распаивали на плате небольшую копию консоли предыдущего поколения именно для аппаратной эмуляции и запуска старых игр. Nintendo тоже любит такое.
Главный недостаток эмуляции - неточность в эмуляции, а так же, при эмуляции сложных платформ, очень большое потребление ресурсов.
- Трансляция. А это уже территория чёрной магии. В отличии от других способов, трансляция не требует наличия какой-либо прослойки для запуска, будь то виртуальная ОС, или эмулируемое окружение. При трансляции софт запускается из хостового окружения, транслятор перехватывает все вызовы и обращения от запущенной программы и транслирует их в вызовы хоста. Трансляция очень бережна к ресурсам- вполне реален вариант, когда потребляется ровно столько же ресурсов, сколько потреблялось бы на основной платформе.
Причём трансляция это не обязательно про перевод вызовов из виндовых приложений. Это вполне себе может быть и заход на территорию эмуляции. Самый яркий пример - Rosetta от Apple. Rosetta позволяла транслировать вызовы из архитектуры x86_64 в архитектуру aarch64 для процессоров Apple Silicon.
Самый большой недостаток трансляции - это сложно. Очень сложно! К тому же, количество вызовов, кастомных библиотек и обращений стремится к бесконечности, что приводит к отсутствию гарантий по запуску того или иного ПО.
Глупая аналогия:
Ты пришёл в ресторан-фастфуда и хочешь поесть нагетсы, но тебе подали стрипсы.
В случае с виртуализацией ты просто идёшь и покупаешь ещё порцию нагетсов без упаковки, вываливаешь их в тарелку со стрипсами и ешь. Ты используешь хост в виде тарелки для стрипсов, чтобы пользоваться гостевым продуктом в виде нагетсов.
В случае с эмуляцией ты берёшь стрипсы и начинаешь их мять придавая им форму нагетсов. Это не всегда получается точно, а при большой порции ты потратишь много времени, но рано или поздно ты получишь свои нагетсы, хотя базироваться они будут на стрипсах.
В случае с трансляцией, ты будешь менять свои стрипсы на нагетсы у другого посетителя. Не всегда посетитель сможет тебе сделать обмен, но если обмен удаётся, то ты гарантированно получишь нужный продукт.
Возвращаясь к Wine - это именно транслятор. Причём транслятор вызовов именно всей Windows, а не отдельного вида приложений.
Очень долгое время он находился в весьма плачевном состоянии. Он позволял запускать небольшой список игр, не очень современных, не очень требовательных. На каком-то железе оно могло работать, а на каком-то нет. Зачастую он требовал очень большого количества дополнительных настроек.
Ситуация кардинально изменилась в 2018 году, когда энтузиаст-одиночка выпустил в свет проект dxvk. Это слой трансляции, который переводит вызовы для DirectX в вызовы для Vulkan.
DirectX - API для работы с графическим чипом, нативное для Windows и не доступное на других ОС.
Vulkan - кросплатформенный API, доступный на разных ОС.
С релизом dxvk началась новая веха в жизни линукс-гейминга. Практически в одночасье пользователям стали доступны ААА-игры прямо в момент выхода игры. С хорошей производительностью и стабильностью.
Это была настоящая революция, которая изменила многое!
Но оставалось одно мааааленькое "но". Сам по себе dxvk - это просто ещё один слой трансляции, который отдельно от wine просто не существовал. И умел он только в работу с графикой. Ни ввод, ни сеть, ни звук - ничего этого он не умел и не должен был уметь. Вызовы всего этого делал как раз wine.
И вот тут и возникала проблема - у нас есть возможность для запуска игр, но сам запуск полностью перекладывается на пользователя. Т.е. пользователь сам должен был разобраться с тем как работает wine, научиться создавать префиксы, при надобности писать конфиги, указывать ключи для запуска и т.д.
Т.е. теоретически больше не было проблем с работоспособностью игр. Но фактически запустить их могли только опытные пользователю линукса.
И вот тут на сцене появляется Proton. Valve увидели потенциал в dxvk и уже через полгода взяли его на вооружение.
Proton - это целый набор ПО объединяющий в себе wine, dxvk и различные патчи. И всё это сразу интегрировано в клиент Steam. Proton сам создаёт для каждой игры отдельный префикс, для конкретных игр он может дополнительно сам добавлять файлы конфигураций, для более стабильной работы, при этом не отбирая у пользователя возможность запуска игр с определёнными ключами.
Получается Valve ничего не сделали и просто используют чужие наработки в своём Proton?
Нет! Точнее, пользователи неправильно интерпретируют фразу "Valve и Proton позволяют запускать windows игры на линуксе". Да, сам факт запуска обеспечивает dxvk, а управляет этим всем делом wine. Да, запуская игру просто через wine + dxvk ты, скорее всего, добьёшься ровно такой же производительности, что и при запуске её через Proton. Но:
- Valve используют свой форк wine с патчами и уже очень много лет участвуют в разработке основного wine.
- Ровно та же ситуация с dxvk.
- Они проделали огромную работу по созданию базы для тысяч игр из библиотеки Steam с необходимыми настройками для каждой игры.
- Они ведут базу ProtonDB, где пользователи делятся своими результатами запуска той или иной игры, с указанием оптимальных настроек на различном железе.
- Главное - они избавили пользователей от головной боли и теперь просто достаточно нажать кнопку "Играть" и магия сама собой происходит под капотом.
Valve проделали огромную работу по улучшению пользовательского опыта и активно участвуют в разработке всех сопутствующих инструментов.
Proton и wine - не конкуренты, а одно целое, где разработки одного проекта используются в другом.
Зачем тогда нужен отдельный wine, если Proton лучше во всём?
Ответ такой же, как и в вопросе почему все не перейдут на патчи для ядра и Mesa от Valve: Proton максимально оптимизирован для запуска в первую очередь именно игр. В то время как wine пытается быть инструментом общего назначения - и для запуска CAD-систем, и для запуска офисных приложений, и для запуска прочего ПО с windows.
К тому же, Proton расчитан на работу только в линуксе. А вайн изначально создавался как кросплатформенный софт для запуска на unix-like системах. Например на FreeBSD или MacOS.
Основной костяк разработчиков wine - сотрудники компании CodeWeavers, которая помимо бесплатного и открытого wine уже много лет разрабатывает коммерческий продукт CrossOver, расчитанный на запуск разностороннего ПО и работающий по принципу Proton - буквально за пару нажатий пользователь может установить и запустить ПО из windows на условной MacOS.
Так что оба инструмента имеют свою цель, свой рынок и свою аудиторию.
FEX, box64, Arm
Что такое FEX?
Короткий ответ - это аналог Rosetta от Apple. Только расчитанный на другой тип процессоров на архитектуре Arm.
Если более сложный ответ: FEX это и эмулятор и транслятор одновременно. В части эмуляции он создаёт x86 окружение, а в части трансляции он переводит "на лету" вызовы в нативные для Arm архитектуры.
И вот тут происходит некое вложение: сначала вызовы игры для windows транслируются в понятные команды для ядра линукса. А потом они же транслируются из архитектуры x86 в Arm. При этом ещё эмулируется окружение x86, чтобы игра изначально думала, что она запущена на родной архитектуре.
Звучит сложно? Разработка подобного ещё сложнее!
Как появился FEX и чья это разработка?
Тут история немного окутана тайной. С одной стороны - FEX разрабатывает группа энтузиастов, под предводительством одного ведущего разработчка. Это проект с открытым исходным кодом и чисто технически он не принадлежит никому и всем одновременно. Любой в праве делает его форк и разрабатывать или изменять самостоятельно, как душе угодно. Не заплатив при этом ни копейки.
Однако сам ведущий разработчик недавно обмолвился, что Valve спонсировали проект с самого начала и были одними из инициаторов разработки. Мы не знаем как оно было на самом деле, но, вероятнее всего, ребята сделали прототип, презентовали его Valve, те дали добро и обеспечили финансирование. Но это только домыслы.
Однако, Valve не выкупили проект, и даже не взяли энтузиастов в штат. Они платят им в виде донатов хорошие суммы денег (настолько, что основной разработчик может себе позволить нигде не работать и заниматься только разработкой FEX).
Один из вариантов почему Valve поступили именно так - они хотели оставить проект открытым, не привязанным к конкретной компании. В пользу этой теории говорит тот факт, что с экономической точки зрения Valve выгоднее отдавать FEX всем подряд, для установки на портативные Arm-приставки, где пользователи будут использовать Steam и приносить прибыль за счёт операций в магазине.
К тому же, открытый проект означает, что вендоры-разработчики портативок вполне могут принимать активное участие в разработке FEX, внося в него патчи для стабильной работы на своих конкретных устройствах, тем самым снимая эту головную боль с себя.
Но это тоже домыслы, разумеется.
А есть ли аналоги у FEX?
Да. Причём основной аналог на данный конкретный момент намного распространён чем FEX - это box64. У данного проекта нет красивой предыстории и такого мощного спонсора в лице Valve, но это не мешает ему быть популярным только за счёт сил энтузиастов.
При этом они устроены очень сильно по разному. Если FEX эмулирует окружение x86 и транслирует только определённые вызовы, то box64 не эмулирует окружение, а создаёт над нативными что-то типа прослойки-транслятора. И вызов сначала проходит через эту прослойку, транслируется и поступает в нужном виде в нативную библиотеку, в то время как у FEX эта библиотек просто бы эмулировалась.
С одной стороны, потенциально это может сильно улучшить производительность, за счёт отсутствия эмуляции и работы нативных компонентов. А с другой - проекту необходимо писать подобные прослойки-трансляторы для всех необходимых библиотек. И это просто огромный пласт работы.
Тем не менее, сообщество как-то справляется и самым явным результатом их работы является небезызвестный Winlator. По факту это связка wine и box64. Winlator запускает небольшое linux-окружение, wine позволяет запустить игру для windows в этом linux окружении, а box64 переводит вызовы из х86 в Arm.
Что FEX, что box64 - инструменты в первую очередь для Linux. Но если FEX может работать только с определённым списком Arm-чипов, то box64 доступен ещё и на других архитектурах. Например на RISC-V.
Steam Frame и Userspace
Для начала выясним что такое userspace.
Userspace - это общее окружение пользователя, включая программы, библиотеки и многое другое, что не имеет прямого доступа к аппаратной части.
Ещё есть kernel space - это само ядро, и в этом пространстве крутятся память, драйвера, процессы.
И они взаимодействуют между собой. Когда вы запускаете игру - она запускается в userspace. Игра создаёт специальный вызов "мне нужна видеокарта". Вызов обрабатывается библиотекой и передаётся в kernel space ядру, которое уже запускает видеокарту.
Напрямую сделать такой вызов из userspace невозможно.
Ранее рассмотренные FEX и box64 работают именно в userspace. Они не работают сами по себе с железом - они лишь посылают необходимые вызовы ядру линукса, а то уже взаимодействует с железом.
И так, у нас есть железо в виде Steam frame на архитектуре Arm. У нас есть эмулятор-транслятор в виде FEX, Valve даже выпустили нативный клиент Steam для Arm. Не хватает только одного - самой ОС.
Точнее как, поддержка Arm в линуксе была с незапамятных времён. Подавляющее большинство Arm устройств работает именно под управлением линукса. Вот только тот самый Arch Linux, который Valve выбрали для основы SteamOS, не был портирован под Arm. И это была большая головная боль.
За всё время существования Arch было множество попыток создать образ для Arm систем, но каждый раз это заканчивалось заброшенным проектом. Это связанно с моделью разработки дистрибутива, но сейчас это не важно.
Важно лишь то, что Valve в сотрудничестве с компанией Collabora сделали невозможное - портировали Arch на Arm.
Значит я могу запустить стим на своём android устройстве?
Нет. Нативный клиент для Arm != нативный клиент для Android. Даже с учётом того, что в android так же имеется линукс в виде kernel space.
Впрочем, некоторые модели телефонов позволяют при получении root установить на него линукс. И есть даже дистрибутивы линукса сделанные специально для смартфонов, где есть и возможность звонить, работать с камерой и отправлять сообщения.
На таких устройствах вполне работает box64 в котором можно устанавливать и запускать ПО с х86. Но вот с играми беда. Причём даже с нативными, а не только через транслятор т.к. устройства на которые можно установить линукс обычно весьма устаревшие. Тем не менее, технически это вполне возможно.
А что насчёт rasberry pi?
Ситуация ровно такая же - хоть и есть теоретическая возможность, но на практике железо слишком слабое.
А что насчёт драйверов?
Это довольно интересная тема, на самом деле. Изначально на устройствах с чипом Snapdragon драйвер был доступен только в виде блоба
Блоб - это заранее скомпилированный файл, зачастую намертво привязанный к конкретному устройству или ОС, без возможности его переноса на другие устройства.
Но относительно недавно ситуация кардинально изменилась. Сообщество подготовило открытый драйвер для данных чипов, под названием Turnip. По итогу драйвер оказался настолько удачным, что сейчас в его разработке учавствуют не только энтузиасты и Valve, а так же такие гиганты как Google. А недавно к разработке подключились и сами Qualcomm.
На самом деле, такие ситуации не редкость в мире линукса. В своё время компания AMD тоже отказалась от проприетарного драйвера для своих видеокарт, в пользу открытого решения.
Так что там со Steam Frame?
По сути, вот так и устроен Steam Frame: Железо на базе Arm, на него установлен линукс в виде SteamOS, который основан на базе портированного на Arm Arch Linux, в нём предустановлен нативный клиент Steam для Arm, игры из которого запускаются через proton, и при помощи FEX транслируются в нативные вызовы.
Всё остальное - работа железа. Какой-то дополнительной магии тут нет. Разумеется под капотом ещё огромное количество патчей, дополнительных библиотек и прочего, но концептуально оно устроено примерно именно так.
Armada OS, Rocknix, и все-все-все
Напоследок, пока ждём официального релиза SteamOS для Arm-устройст, обсудим сторонние дистрибутивы пытающиеся передать опыт SteamOS уже сейчас.
И начать стоит не с самого популярного, а с самого важного - Rocknix. Его сообщество в целом одно из старейших в части запуска линукса на портативках. Они много где были первопроходцами. В том числе и тут. Они одними из первых запустили нативный arm-клиент Steam, написали кучу скриптов и инструкций и софта (например ROCKNIX ABL - позволяющий делать дуалбут линукса и андроида на устройствах). К тому же, они разрабатывают свой форк ядра, которое либо целиком, либо в виде отдельных патчей применяется в других проектах.
Так же, у них довольно широкий охват поддерживаемых устройств.
Самым популярным же является Armada OS. Этот проект в целом концептуально ближе к Bazzite, чем к оригинальной SteamOS. В базе там так же, как и у Bazzite - Fedora. Причём так же immutable вариант. Ядро - смесь ядра из Fedora с патчами от Rocknix. В целом от Rocknix используется много наработок, особенно в плане поддержки железа. Userspcae там полностью собственный.
Pocknix OS - это ровно такой же проект, как Armada OS, только базируется он уже не на Fedora, а на Arch Linux. Он так же использует наработки от Rocknix и так же развивает своё пользовательское окружение.
Все вышеперечисленные проекты объединяет одно - они не используют полностью весь userspace от SteamOS, а развивают свои решения. А отличает их база, наборы патчей, а так же то, на какие конкретные устройства они ориентируются в первую очередь.
Дополнительно стоит рассмотреть такие проекты как Holodor, SteamOS-ARM-SM... и ещё парочка проектов.
Я их всех объединяю в одну группу, т.к. в своей сути они являются весьма схожими. А именно: ядро от Rocknix, userspace от SteamOS. Да, там есть так же отличия в отдельных патчах, предустановленных плагинах и списке устройств, на которые в первую очередь идёт прицел. Но я не вижу смысла расписывать их по отдельности, ибо изменения не шибко большие и все они доступны в описаниях на страницах данных проектов.
К тому же, они наименее интересны лично мне, т.к. помимо отдельных скриптов там практически нет какой-либо серьёзной разработки, способной удивить, ибо основные компоненты взяты из других куда более любопытных проектов.
Почему бы тогда не взять не только userspace от SteamOS, но и всё остальное?
А всё просто - потому что ничего кроме userspace от SteamOS для Arm, на данный момент просто не доступно.
Прямо сейчас SteamOS для Arm существует только в одном единственном виде - предустановленной на Steam Frame. Больше вы её нигде и никак не возьмёте.
Впрочем, это не так плохо. SteamOS для ПК тоже кое-как вышла спустя сколько лет? При этом там всё ещё есть проблемы с поддержкой железа и драйверами для карт Nvidia.
Зато за это время очень сильно развился Bazzite. Причём настолько, что многие предпочитают именно его. И это хорошо, т.к. развитие идёт не в полузакрытом решении от Valve, а в открытом проекте, наработки из которого потом могут лечь в основу чего-то большего.
Вполне вероятно, что в случае с Arm устройствами будет пройден ровно такой же путь.
А что же выбрать?
На самом деле - что угодно и что имеет поддержку вашего устройства, т.к. абсолютно все проекты на данный момент находятся на стадии экспериментальных сборок.
Причём сама SteamOS на Steam Frame не далеко ушла от них по стабильности.
Так что установить что-то одно и забыть не получится. Вам нужно будет периодически находить что-то новое или переустанавливать имеющееся.
Послесловие
В первую очередь я хочу извиниться перед теми, кто разбирается в вопросе. Я знаю, что написано очень плохо с кучей допущений и максимально поверхностно. Но таков был путь.
Я многое опустил, например Gamescope, срач между Wayland и Xorg, что такое Vulkan, OpenGL и DirectX... Но всё охватить невозможно. Тем не менее, я постарался дать самую базу. Причём языком, который будет хоть сколько-нибудь понятен читателю с любым уровнем понимания вопроса.
П.с. практически все прекрасные технологии, которые были указаны в данном материале - это проекты с открытым исходным кодом. Которые зачастую создаются самыми обычными людьми работающими над ними на полном энтузиазме без какой-либо финансовой выгоды. Сотни и тысячи таких же энтузиастов ежедневно помогают в разработке даже не за спасибо и не за имя в списке разработчиков, а просто из-за желания сделать наш мир чуточку лучше.
Пожалуйста, цените опенсорс и людей участвующих в его разработке, а по возможности помогайте открытым проектам.