3 ms·

Game developers would be fine to target a single distro like Ubuntu 22.04. And I say that as someone who does not use Ubuntu, because I run Steam in a docker (p

Game developers would be fine to target a single distro like Ubuntu 22.04. And I say that as someone who does not use Ubuntu, because I run Steam in a docker (podman) container of Ubuntu 22.04. It's a common base container for all "closed-source / not from my distro's repos" software - Steam, Discord, etc. The downside is that you have to mount whatever things you want to share from the host, like X11 socket, PulseAudio socket, D-Bus socket, etc. The upside is that you get to share only the things you want to trust the closed-source software with. The other day people were complaining how Discord made their system slow by scanning for game processes; Discord couldn't do that for me because it doesn't know about any processes other than itself.

RussianCow 4y ago
That sounds really interesting, and I'd love to learn more about this. Did you hack something together yourself to allow you to do this, or are you using some software to manage the containers for you?
- Arnavion 4y ago
  Hacked it together myself. I have a Containerfile with docker.io/library/ubuntu:22.04 base and a RUN step that installs steam + mesa-vulkan-drivers + some other GL and audio libs + 32-bit versions of those, creates a user with the same UID as my user on the host, and adds it to the input group (for controller support). Then I have a `~/.local/bin/steam` script that runs `podman container run --userns=keep-id` with parameters to pass through `/dev/dri` (for GPU), `/dev/input` (for controller), PulseAudio socket, X11 socket, and an empty directory as the home directory. Every week or so when I reboot my PC for updates, I rebuild the container image with whatever is the latest ubuntu base image and other packages at the time. `~/.local/bin/discord` is the same except it doesn't have the controller and GPU stuff, and it has a pre-processing step to download the Linux binary tarball from their website and unpack it into the home directory. I'd share it but it's part of a big private personal repo. I might separate it out into a GitHub Gist or something later.
  - Arnavion 4y ago
    https://gist.github.com/Arnavion/81006757190c29aa0b24c674e241bf2a https://gist.github.com/Arnavion/81006757190c29aa0b24c674e24... The first `#` line in each file is the path where that file should go. Use ~/src/non-oss-container/build.sh to build the container image and ~/.local/bin/steam to run a Steam container using that image. The Steam container-specific homedir will be ~/non-oss-root/steam The default COMMAND runs Steam with the built-in web browser disabled. I don't use it so I keep it disabled, except that you can't uninstall games from the default view if the web browser is disabled. Launch Big Picture View and uninstall from there. The X socket is mounted from the host, so if you're worried about malicious programs intercepting your other X windows or input devices, then this level of sandboxing will not help. (I don't care because I use a wayland compositor and run nothing of importance in Xwayland.) In this case you may want to consider running a nested X server like xephyr and mounting its socket in the container instead.
    - RussianCow 4y ago
      This is really cool, thanks for sharing! I might try this out as a sandboxing mechanism for a few of the apps I run.
cesarb 4y ago
> Game developers would be fine to target a single distro like Ubuntu 22.04. Valve has its own container-only Linux distribution, the "Steam Runtime" (https://github.com/ValveSoftware/steam-runtime https://github.com/ValveSoftware/steam-runtime ); especially for games distributed on Steam, it probably makes more sense to target that distribution instead of Ubuntu.
- deleted 4y ago
  [deleted]
- Arnavion 4y ago
  Right, though I vaguely remember that I had tried the pressure-vessel-based sandboxing a long time ago and it didn't work if Steam itself was inside a container. https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/issues/35 https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/i... seems familiar. (Why do I insist on running Steam inside a container? Because there's no way I'll trust it on my actual filesystem after https://github.com/ValveSoftware/steam-for-linux/issues/3671 https://github.com/ValveSoftware/steam-for-linux/issues/3671 )

RussianCow 4y ago

That sounds really interesting, and I'd love to learn more about this. Did you hack something together yourself to allow you to do this, or are you using some software to manage the containers for you?

Arnavion 4y ago
Hacked it together myself. I have a Containerfile with docker.io/library/ubuntu:22.04 base and a RUN step that installs steam + mesa-vulkan-drivers + some other GL and audio libs + 32-bit versions of those, creates a user with the same UID as my user on the host, and adds it to the input group (for controller support). Then I have a `~/.local/bin/steam` script that runs `podman container run --userns=keep-id` with parameters to pass through `/dev/dri` (for GPU), `/dev/input` (for controller), PulseAudio socket, X11 socket, and an empty directory as the home directory. Every week or so when I reboot my PC for updates, I rebuild the container image with whatever is the latest ubuntu base image and other packages at the time. `~/.local/bin/discord` is the same except it doesn't have the controller and GPU stuff, and it has a pre-processing step to download the Linux binary tarball from their website and unpack it into the home directory. I'd share it but it's part of a big private personal repo. I might separate it out into a GitHub Gist or something later.
- Arnavion 4y ago
  https://gist.github.com/Arnavion/81006757190c29aa0b24c674e241bf2a https://gist.github.com/Arnavion/81006757190c29aa0b24c674e24... The first `#` line in each file is the path where that file should go. Use ~/src/non-oss-container/build.sh to build the container image and ~/.local/bin/steam to run a Steam container using that image. The Steam container-specific homedir will be ~/non-oss-root/steam The default COMMAND runs Steam with the built-in web browser disabled. I don't use it so I keep it disabled, except that you can't uninstall games from the default view if the web browser is disabled. Launch Big Picture View and uninstall from there. The X socket is mounted from the host, so if you're worried about malicious programs intercepting your other X windows or input devices, then this level of sandboxing will not help. (I don't care because I use a wayland compositor and run nothing of importance in Xwayland.) In this case you may want to consider running a nested X server like xephyr and mounting its socket in the container instead.
  - RussianCow 4y ago
    This is really cool, thanks for sharing! I might try this out as a sandboxing mechanism for a few of the apps I run.

cesarb 4y ago

> Game developers would be fine to target a single distro like Ubuntu 22.04. Valve has its own container-only Linux distribution, the "Steam Runtime" (https://github.com/ValveSoftware/steam-runtime https://github.com/ValveSoftware/steam-runtime ); especially for games distributed on Steam, it probably makes more sense to target that distribution instead of Ubuntu.

deleted 4y ago
[deleted]
Arnavion 4y ago
Right, though I vaguely remember that I had tried the pressure-vessel-based sandboxing a long time ago and it didn't work if Steam itself was inside a container. https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/issues/35 https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/i... seems familiar. (Why do I insist on running Steam inside a container? Because there's no way I'll trust it on my actual filesystem after https://github.com/ValveSoftware/steam-for-linux/issues/3671 https://github.com/ValveSoftware/steam-for-linux/issues/3671 )