Steam in Ubuntu

Че?

А где посмотреть?

ждем ебилдов

Я у себя глянуть не могу, так распостраняют только лаунчер от стима, потом при первом запуске он скачивает самого клиента …

Понятно что Шапках, Арчах и т.д. там там куча либ из ubuntu12 а вот на Ubuntu тоже самое ? Или там какая ubuntu ?

в арчах есть steam native и steam runtime.

А можно нормально вопрос задать?

Понятно что Шапках, Арчах и т.д. там там куча либ из ubuntu12 а вот на Ubuntu тоже самое ?

Да. Конечно.

Valve как-то не упало возиться со всем этим зоопарком.

Steam чрут не использует нигде, используется Steam-Runtime через обычный LD_LIBRARY_PATH. И да, в Ubuntu этот рантайм тоже используется.

Ок.

А точно можно узнать от какой версии Ubuntu этот рантайм ? Я выше предположил что от 12ой, но я хз как точно узнать.

Steam -> Справка-> Сведения о системе

  "runtime" : {
    "path" : "/home/ihorse/.local/share/Steam/ubuntu12_32/steam-runtime",

Где точно узнать - не знаю. Но в каталоге со steam-runtime есть файлик manifest.txt с версиями пакетов, судя по нему там в основном древние пакеты (похоже, как раз с Ubuntu 12.04, на что и название самого каталога намекает), но есть там и относительно свежие пакеты (libvulkan1, libsdl2), видимо вручную собранные.

12.04

апрель 2012 года … хм.

Steam Runtime это сборник основных библиотек из Ubuntu всех LTS-версий начиная с 12.04. Так как библиотеки обожают менять ABI, то игра, скомпилированная в Ubuntu 14.04 (или для 18.04 в 20.04), может прекрасно перестать работать в 16.04, потому что libgnutls.so.58 превратилась в libgnutls.so.61 (libva.so.1 в libva.so.2, libpng15 в libpng17, libicu50 в libicu54). В рантайме же собраны они все. От всех убунт. Поэтому игра БУДЕТ работать, и не важно, какая у тебя ОСь и какой версии.

Какой ужас. Хоть музей открывай: «музей чего угодно, кроме нормального package management’а».

потому что libgnutls.so.58 превратилась в libgnutls.so.61

Насколько я знаю обычно совместимы снизу в вверх. И как правило есть ссылка libgnutls.so на конкретную версию libgnutls.so.ХХ и собирается как раз с libgnutls.so а не с конкретным номером. В зависимостях же к пакету указывают => Т.о. старый хвост не нужен.

Изначально Steam доустанавливал зависимости через apt-get. Я был бета-тестером Steam с октября 2012 года. Потом вышла Ubuntu 12.10, и оказалось, что Steam может запросить у apt-get несуществующий пакет, потому что библиотеки очень любят ломать ABI, а дистрибутивы очень любят удалять из репозиториев библиотеку со старым ABI. А игры очень любят кааак слинковаться с какой-нибудь библиотекой, которую рррраз - и удалили из дистров в новой версии!

Поэтому Valve очень помогла разработчикам игр. Компилируйте в Ubuntu любой LTS-версии. Хоть в 12.04, хоть в 14.04, хоть в 20.04. И не окажется так, что завтра вышла Ubuntu 20.10, из которой удалили библиотеку со старым ABI, из-за чего половина игр «отвалилась». Конечно, было бы здорово заставить всех пользоваться одной только Ubuntu 12.04 и собирать программы только под Ubuntu 12.04. Тогда бы зависимости успешно «подтягивались» apt-get-ом.

Всё не так. У тебя в системе libpng.so.15, а игра скомпилирована с libpng.so.14? Страдай. Игра работать не будет. Ты можешь на свой страх и риск сделать симлинк libpng.so.14, ведущий на libpng.so.15, но это не будет работать, потому что ломали ABI. Или доустановить libpng.so.14 из предыдущей версии дистрибутива. Тогда игра даже заработает.

libpng.so как симлинк на libpng.so.15 не используется программами. Он используется только компилятором, чтобы он знал, с какой именно библиотекой линковаться (вдруг там их две лежит). Именно поэтому файлы с расширением *.so лежат в -dev пакетах, а *.so.число лежат в обычных версиях пакетов.

Интересно а как же протон ? Насколько я знаю wine собирается под каждый дистр.

P.S. 12.04 скорее всего их SteamOS ведь насколько я помню у 12.04 была какая то расширенная поддержка до 2019 года.

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

Может. libva1 и libva2 вполне себе уживаются вместе. Как и libopenssl0.9.8 и libopenssl1. Или libgtk2 и libgtk3.

По идее все таки в пределах 1х должна быть совместимость сверху вниз. А когда переходят на 2х то старые также в дистре остаются … Вы что думаете после перехода на GTK3, gtk2 выкинули что ли ?

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

Список изменений в клиенте Steam за август (канал бета-обновлений)

Там большая часть библиотек действительно из 12.04, но многие библиотеки из более новых версий убунт. И судя по всему, новые библиотеки из новых убунт собирали в Ubuntu 12.04, а не просто копировали из более новой убунты. Чтобы новые библиотеки не хотели нового Glibc.

И судя по всему, новые библиотеки из новых убунт собирали в Ubuntu 12.04, а не просто копировали из более новой убунты. Чтобы новые библиотеки не хотели нового Glibc.

Это понятно, и как то печально … с другой стороны аля виндовс, наставить кучу vc рантаймов и кучу NET ….

Отвечая на исходное сообщение. Не надо триггериться на ubuntu-12, мол «протухшее, старое, а надо чтобы было новое».

Steam Runtime позволяет разработчику не париться и скомпилировать свою игру прямо в той убунте, которой он пользуется прямо сейчас. И если на дворе 2020 год, разработчик укажет в системных требованиях «Ubuntu 20.04 или выше». А Steam Runtime позволит его игре работать в Ubuntu 22.04, 24.04, 26.04...

А в 2028 году кто-то скажет «я нашёл в стиме библиотеки из старой убунты. Зачем они нужны? Давайте их заменим на библиотеки из новой убунты!». Обновят - и игра от того разработчика перестанет работать, не найдя sdl2, ведь в 2025 году её заменили на sdl3.

> Это понятно, и как то печально

Печально, что Steam не требует Glibc 2.31 в зависимостях? Прекрасно работая на версии 2.15 и выше?

> с другой стороны аля виндовс, наставить кучу vc рантаймов и кучу NET

Вот тут я не понял. Ты радуешься, что Steam Runtime избавляет от необходимости доустанавливать кучу vc, directx и dotnet? Или считаешь, что Steam Runtime это что-то сродни этому?

Если так, то всё наоборот - набор основных либ за последние 10 лет позволяет расслабиться как разработчику игры, так и пользователю. И не придётся доустанавливать дотнеты, директиксы и C++-ы. Всю головную боль берёт на себя Valve, создавая этот рантайм и наполняя его основными библиотеками от убунт LTS сразу пяти версий.

Всегда можно выключить Steam Runtime и Steam Runtime Heavy (который для WebKit), выставив переменную при запуске. Тогда будут использоваться новые либы из твоей системы. Однако они и так используются. Steam не зафигачивает глобальный LD_LIBRARY_PATH в эту директорию с 600 Мб библиотек. Стим смотрит версии библиотек в твоей системе (при помощи realpath), а потом создаёт список устаревших библиотек. Из Steam Runtime используются только те библиотеки, которые в твоей системе являются устаревшими. Там как-то хитро, создаётся директория, в которую кладутся симлинки (pins), и уже туда делается LD_LIBRARY_PATH.

Это жизнь. То, что этот Стим хорошо ложится на принципы пакетирования в nixos никак не поможет собрать его дистрибутив для убунты или суси. Кстати, как оно там в nixos - Стим распотрошён и опакечен в nix?

чанж-рут

чрут? Ииии? Оно свои убунтовские либы юзает не удивительно что чрут делает в себя. Да и даже хорошо что делает. В чём проблема то?

Кто использует сабж у вас клиент Steam

Я и как то по баробану как оно там вертится.

Инфы от тебя конечно море, откуда ставил, на бете или нет. На какой убунте?

И в чём проблема? Если какая либа по твоему устарела то просто удали её из стимовсткого каталога и подхватится твоя новая только после этого 50 на 50 либо всё упадёт или будет ок. Зато всё стабильно работает на любых системах. Слава богу что стим тащит своё причём именно то которое главное что работает и нехер трогать иначе было бы АДИЩЕ линуксового ада зависимостей и версий.

А как же всякие новые МЕСЫ, вулканы и т.д. им что пофигу что ли ?

Зачем вообще новые ядра делать ? Просто бы патчили бы старые ? (это я про ядро линя)

нормального package management’а

Если бы ты был мантейнером стима и он бы юзал «нормальный» package management принятый для софта в общем случае. Ты бы сидел на работе и плакал. Валв сделало самое грамотное решение базу таскать с собой она же к слову часть SDK для сборки под linux, а не просто так. Тем самым они обеспечивают беспроблемность работы (более менее) даже на самых маргинальных LFS от васянов из втрого Б класса. Так что всё нормально. А как человек билдящий игры для стима я скажу что всё просто прекрасно, если мне нужна своя версия либы то я просто её приложу и прелоад сделаю, в остальных случаях у меня есть база которая не меняется как перчатки хирурга.

Ты не понял, стим использует минимальную базу РАЗРАОТЧИКИ КОНПЕЛЯЮТ ПОД ЭТИ ЛИБЫ дабы гарантировать что после того как ты обновишь свой арч у тебя игры будут работать и не зависеть от кривизны установки чего либо в системе. Всё остальное берётся из системы. Меса, вулканы и прочее это на совести системы, а тащат они с собой минимальную базу ещё раз повторяю которая является частью SDK и нет никаких гарантий что если переложить всё это на обычный пакетный менеджер то во всех системах бы работало с наличием нужных зависимостей. Если бы валв сделал всё через пакетный менеждер то работал бы стим только на убунте и всё. А разработчики под linux прифигевали бы. И да есть вариант steam runtime, а ест вариант своего рантайма в котром не факт что ест то что нужно, а если нужно то не факт что оно ещё ABI совместимо. Там всё же программные инженеры сидят. Либо делать так как они, либо огребать боль и страдания для всех прлодить на ровном месте десятки тысяч багрепортов для сотен игр и прочий треш. Вот просто на пустом месте только для галочки мол мы юзаем пакетный менеждер как Ъ хотя технической выгоды и смысла нет ибо в линусах не принято по умолчанию что программа может просто взять и заработать в другом дистрибутиве, каждую надо отдельно готовить тоесть каждую игру в стиме нужно было бы отдельно готовить под версию отдельных дистрибутивов. Если кратко или так или нет игр и стима на линукс в принципе.

Месы/вулканы/ядро это имеющее стабильное предсказуемое состояние вещи, а libpng какая например может просто в любой момент сменить API/ABI и всё отвалилось всё что её использует тоесть процентов 80 стимовских игр. И тогда либо игра отдельно потащит либу или как сейчас стим включит её в себя, так постепенно и происходит, те библиотеки которые внезапно меняют API/ABI вернее получают deprecated функции или даже из которых выпиливается что-то то стим берёт на себя нужную версию и замораживает что бы игры собранный ранее продолжали работать.

Кстати справедливости ради скажу стим под винду тоже какой рунтайм притаскивает.

на ubunte, использует runtime библии 12 убунты вне зависимости от версии самой убунты
native если использовать это флаг при запуске будет использовать системные библии если они конечно есть, их нужно устанавливать,например в арче есть пакет который можно установить и поставит то что нужно,в генту с флагом -steamruntime, тоже самое,он поставит кучу 32бит и 64бит библиотеки которые нужны для запуска, в других дистрах такой прелести нет можно вручную но сразу скажу удачи в поисках такой библии как libpng12 версии в той же debian и таких старых либов нужно немало, так как габен не особо хочет обновлять ту же доту 2 с libpng12 на условно 16,да и вообще она для всех игр в linux нужна особенно от valve

Всё верно есть SDK для разработчиков в том числе steam API которое интегрируется в игры если разрабы хотят (облачные сохранения и настройки игры) всё это требует некого рантайма которого в винде конечно нет. Короче, что-бы тебя просто не парило зачем - это просто часть SDK с учётом или без которого пишутся игры и понятное дело оно должно сопровождать теперь их всегда вот и всё. К слову игры могут быть собраны вообще без него, но всё эе если разработчик не хочет проблем огребать и нужные библиотеки есть в базе он использует их например SDL2 зачем надеяться на то что установлена ли она у пользователя или нет, но при этом это одна из фундаментальных либ которую явно или нет юзает херова гора игр. Логично стабилизировать версию и положить в рантайм. Всем от этого лучше, разработчиками стабильность, юзерам стабильность, а в случае косяка фиксят напрямую, а не ждут апстрима. Конечно бывают косяки или обновление SDK где ооооооооооооооооочень рекомендуют потом пересобрать уже опубликованную игру. Но даже это не беда, стим держит несколько рантаймов ))))))).

К слову я недавно накатывал новый стим в дебиане, не вникал, но сейчас стало всё очень аккуратно, куча всего через симлинки. Опять же если что-то не устраивает весь рантайм стима на гитхабе лежит, бери пересобирай и подменяй если хочешь/не доверяешь. https://github.com/ValveSoftware/steam-runtime

eyeroll то-то игры в стиме просто засунуты в .deb пакеты с зависимостями от libgnutls58, ну.

То, что этот Стим хорошо ложится на принципы пакетирования в nixos

NixOS тут вообще не при чем. И ложится он на них как макияж на школьницу.

Способность пакетного менеджера подогнать программе зависимость нужной версии универсальная и ценна в любом пакетом менеджере.

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

Кстати, как оно там в nixos - Стим распотрошён и опакечен в nix?

Нет, конечно, как ты будешь пакетить закрытые игры из закрытого стима? Торчит себе монолитом, и ещё небось FHS ему эмулируют =D

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

Так у стима есть пакетный менеджер внутренний. Просто он встроен, там обновления постоянные и всё рулится не от балды, считай своя root fs внутри которой всё и живёт слава те хоспади не трогая систему и не мусоря.

Внутри половина всего через симлинки, всё аккуратно.

├── bin -> /home/xxx/.steam/bin32
├── bin32 -> /home/xxx/.steam/debian-installation/ubuntu12_32
├── bin64 -> /home/xxx/.steam/debian-installation/ubuntu12_64
├── debian-installation
│   ├── appcache
│   ├── bin
│   ├── clientui
│   ├── config
│   ├── controller_base
│   ├── depotcache
│   ├── friends
│   ├── graphics
│   ├── html5app
│   ├── legacycompat
│   ├── linux32
│   ├── linux64
│   ├── logs
│   ├── music
│   ├── package
│   ├── public
│   ├── resource
│   ├── servers
│   ├── skins
│   ├── steam
│   ├── steamapps
│   ├── steamui
│   ├── tenfoot
│   ├── ubuntu12_32
│   ├── ubuntu12_64
│   └── userdata
├── root -> /home/xxx/.steam/debian-installation
├── sdk32 -> /home/xxx/.steam/debian-installation/linux32
├── sdk64 -> /home/xxx/.steam/debian-installation/linux64
└── steam -> /home/xxx/.steam/debian-installation

xxx@gnu:~/.steam$ ls
bin    debian-installation         root   steam       steam.token
bin32  registry.vdf                sdk32  steam.pid
bin64  registry.vdf20201115101726  sdk64  steam.pipe
xxx@gnu:~/.steam$ 

Он докачивает нужные версии gnutls по мере установки зависящего от них софта?

Не, ты не так понял. У стима есть SDK под него пишут игры, а не стим докачивает нужные либы играм. Сам же стим вынужден иметь все рантаймы что бы работало всё начиная с 2012 года. Но по сути там не шибко то и много он тащит.

Ты хочешь сделать так как принято или «правильно» или «красиво», а там делают так что-бы работали тысячи игр выпущенные с периода 2012 по 2020 годы включая те которые были собраны 1 раз и более не обновлялись. Самое главное что бы всё работало. В дистрибутивах просто нет средств которые позволяли бы стиму без проблем гарантировать работу тысяч игр. Хотя стоп, есть LD_LIBRARY_PATH и LD_PRELOAD вот и всё. Или ты предлагаешь чтобы например debian выкачивал в систему зависимости стима? Вернее steam SDK которое для пользователя и есть рантайм позволяющий ещё раз повторяю не парится с 100500 дистрибутивами? Их подход, работает, а уровень совместимости выше чем у любого дистрибутива, steam это по сути и есть дистрибутив в дистрибутиве разве что chroot с пробросом иксов не делают и steam не через просто debootstrap разворачивают.

Или ты имеешь в виду что … То есть ты бы хотел что-бы можно было бы добавить в стим например программу свою и стим для него подтянул gnutls?

Нененнее это всё, это конец. Пакетные менеджеры и дистрибутивы гвоздями прибиты к версиям либ/софта и в конечном итоге целого дистрибутива, шаг в торону и всё сломалось. Никакой из дистрибутивов без явных костылей не запустит софт собранный давно если этот софт не тащит с собой нужные ему либы или пересобирай или досвидания. Кто-то скажет nixos! могу лишь только посмеяться, нет в никсе боли с версиями на 20% меньше чем в любых иных.

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

Ой всё короче суть в том что им ехать, а не шашечки. И если уж быть честными у меня с десяток программ из debian 6 которые у меня лежат в каталогах с зависимостями от шестого деба и запускаются через ld_libtary_path просто потому что они тупо работают, а пересобрать их под debian 10 это боль, нужно переписывать или таскать с собой патчи API/ABI всё поломано, некоторых зависимостей нет уже начиная с debian8 в репозиториях, всё это нужно перепакечивать по хорошему ещё в локальную репу положить, вот нахер оно мне всё это надо?

Пока пакетному менеджеру например в debian 10 нельзя сказать вот у меня из debian lenny пакет есть установи мне его и он не поперхнётся от dependency hell, а утавновит пакет и древние на него зависимости без лишних слов и коллизий в системе то всё тлен. Проблема линукса в данном случае это полная неработоспособность в отношении переносимости уже готового, полное отсутствие обратной совместимости без каких бы то ни было на то технических причин. А для стима надёжная обратка это фундамент, без него всё тлен. Как бы ты например отнёсся к тому что вдруг твоя программа в стиме затребовала бы библиотеку которую у тебя в системе выпилили в прошлом релизе? А программу ты в стиме купил, куда писать бы стал.

Для меня давно уже понятно, стим няшка, и он единственное ПО в линуксах такой сложности и такой массовости. Ничего в нем кривого нет, программы всегда могли и должны работать из /opt в юниксах. А кто считает иначе - мамкины борщееды.

Ничего в нем кривого нет

Выглядит чисто как с Windows. Хотя это во многом вина линуксов.

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

Как будто ДЕ винды не сильно отличаются. Взять ту же 8.1 и 10.

Не так. Вот когда у тебя Unity в Ubuntu 16.04 с кнопочками слева, а потом в Ubuntu 18.04 с комочками справа - это прям трах-бабах.

Ну или с доком вон сколько проблем на линуксах – сделано абы как через одно место.

В Windows такого себе не позволяют.

Наверное ВЫ мало работаете с виндой. Там такого целый вагон, к примеру кнопка выхода из системы в 8.1 и 10ке.

Недавно в 10ке (1909-проф) понадбилось локального юзера завести, решил по правильному сделать, залез … нету. В инете почитал, должно быть, даже с картинками. Плюнул сделал через старое управление, дабы такое еще не выпилили.

Здрасьте, а Steam до этого дела нет 🤣

Чисто) может сам клиент чистый а вот портиваные игры далеко не чистые я бы даже сказал грязные много лишнего мусора кода с винды я говорю про игры вальв

> А как человек билдящий игры для стима

Опа. Привет :-) А какая ОС используется в качестве билд-фермы?

Я сужу о том, как правильно билдить игры, по играм, выпущенными в своё время Loki Games и Icculus.

Например игра Doom III тащит с собой libstdc++.so.6 и libgcc.so.1. Игра была скомпилирована новым (на момент 2004 года) компилятором GCC 4.0, поэтому не у всех была новая библиотека в системе (была libstdc++.so.5). Вот поэтому игра и тащила с собой эти две библиотеки.

Я посмотрел на это и усвоил это для себя. Хотя libstdc++.so.6 теперь есть во всех системах - иногда бывает ситуация, когда игра говорит «GLIBCXX 3.4.26 not found». Я взял Ubuntu 12.04 и скомпилировал туда GCC 9. Скомпилировал при помощи этого GCC бинарник, и попробовал запустить. Получил ошибку, о которой я писал выше. Поэтому я положил эти две библиотеки с игрой, и всё стало работать.

Причём в libgcc.so.1 я не вижу смысла, потому что всё работает и без неё. Но раз Icculus приложил её к дистрибутиву Doom III, значит и её надо тоже.

Или например игры из Humble Bundle 2010 и 2011 годов. World of Goo, Cogs, VVVVVV, Super Meat Boy, Braid. У Linux-версий этих игр был любопытный скрипт, который запускал игру. Он состоял из трёх частей. Первый кусок выставлял текущую директорию, второй определял разрядность ОС, третий выставлял LD_LIBRARY_PATH либо на lib32, либо на lib64. После чего запускался бинарник игры.

Я считаю, что такой скрипт, это очень интересная вещь. Раньше я думал, что надо линковать статически (чтобы все зависимости были внутри бинарника игры). Но потом я понял, что библиотеки надо как-то обновлять. Поэтому надо положить их рядышком и подцеплять. А если библиотеки устарели и в них опасная уязвимость, их всегда можно вручную обновить.