Valve have been cooking! A new Steam Client Beta is available with something quite special for Linux gamers, as Valve work to continue improving Linux gaming.
Why the fuck is it weird for a client to run inside a runtime environment with well-defined library versions, when that client has to ship that runtime environment anyways to ensure the games can actually run on a broad range of systems?
Oh, sure, it’s so much better if the client relies on system libraries instead. Yes please, I like incompatibilities and issues with debugging. So much better than loading a different set of libraries. Stupid Valve!
Alright, let’s just ignore the containerization because of the problem Valve creates by making you open Steam when you play games you paid for. It’s just 64-bit for the runtime, not even the client itself. It’s 2026. I’m not going to act like this is noteworthy or an accomplishment.
You can run steam games without opening steam as long as they don’t use the steamworks DRM or require an additional login (Ubisoft, Bethesda). Both of these issues are created by the developers / publishers, not steam.
Do you even know what any of the words you’re using mean? It doesn’t matter whether the Steam client is running in the runtime, you still want the same containerization to run your games, because that’s how they make sure the games run everywhere.
You’re just angrily flinging shit around without understanding what any of this is about. Don’t you have anything better to do?
I run most of my software in containers. Firefox is in a flatpak. My terminal shells are all containers using distrobox. My homelab services are all containers. My few VMs (i run a few vituralized rke2 clusters, sometimes a test version of my baremetal harvester cluster, and test versions of my desktops)? Also running in containers. My desktop OSs are also containers (ublue, SteamOS, and SUSE Elemental).
The future is now old man! :p
But honestly linux namespaces and overlay filesystems are the bees knees. Create reusable layers of filesystems, use just the ones needed for a given app/service. Expose just what a service or app needs to for a given function. You end up with an extemly portable, and consistent system that has cleaner seperations of concerns. For basically free. From an app dev perspective you remove a whole matrix of supported configurations to worry about (distro/version/packages installed/etc).
Qubes is really cool but it uses VM instead of containers, and for its use case you basically have too. Containers isolation at almost no cost come from actually share the underlying kernel and hardware. That isnt isolated enough for data domain seperation thay qubes is built around.
That is one reason i have multiple clusters actually, and the confidential container effort is actually light weight VMs with tools to intergrate them with the network of the host correctly (and multikey memory encryption to fully enforce the boundary). I havent goten around to deploying an app like that yet myself though
Containers all the way down.
My services are all running in containers, but I’ve some work to do to catch up to your skill level. That said, the above comment is music to my ears with where I am at in the learning process just now, it just resonates. Have a good weekend!
That it’s weird for Valve’s client to be running inside a container?
My other software isn’t containerized that I know of. I don’t run Firefox in Docker.
Why the fuck is it weird for a client to run inside a runtime environment with well-defined library versions, when that client has to ship that runtime environment anyways to ensure the games can actually run on a broad range of systems?
Oh, sure, it’s so much better if the client relies on system libraries instead. Yes please, I like incompatibilities and issues with debugging. So much better than loading a different set of libraries. Stupid Valve!
Alright, let’s just ignore the containerization because of the problem Valve creates by making you open Steam when you play games you paid for. It’s just 64-bit for the runtime, not even the client itself. It’s 2026. I’m not going to act like this is noteworthy or an accomplishment.
You can run steam games without opening steam as long as they don’t use the steamworks DRM or require an additional login (Ubisoft, Bethesda). Both of these issues are created by the developers / publishers, not steam.
Do you even know what any of the words you’re using mean? It doesn’t matter whether the Steam client is running in the runtime, you still want the same containerization to run your games, because that’s how they make sure the games run everywhere.
You’re just angrily flinging shit around without understanding what any of this is about. Don’t you have anything better to do?
Funnily enough, people running in Ubuntu do get Firefox in a container by default IIRC as it’s delivered as a snap
You recall correctly. It’s another one of Canonical’s attempts to shoehorn their trash.
I run most of my software in containers. Firefox is in a flatpak. My terminal shells are all containers using distrobox. My homelab services are all containers. My few VMs (i run a few vituralized rke2 clusters, sometimes a test version of my baremetal harvester cluster, and test versions of my desktops)? Also running in containers. My desktop OSs are also containers (ublue, SteamOS, and SUSE Elemental).
The future is now old man! :p
But honestly linux namespaces and overlay filesystems are the bees knees. Create reusable layers of filesystems, use just the ones needed for a given app/service. Expose just what a service or app needs to for a given function. You end up with an extemly portable, and consistent system that has cleaner seperations of concerns. For basically free. From an app dev perspective you remove a whole matrix of supported configurations to worry about (distro/version/packages installed/etc).
At that point, why not just go for Qubes OS?
Qubes is really cool but it uses VM instead of containers, and for its use case you basically have too. Containers isolation at almost no cost come from actually share the underlying kernel and hardware. That isnt isolated enough for data domain seperation thay qubes is built around.
That is one reason i have multiple clusters actually, and the confidential container effort is actually light weight VMs with tools to intergrate them with the network of the host correctly (and multikey memory encryption to fully enforce the boundary). I havent goten around to deploying an app like that yet myself though
Containers all the way down.
My services are all running in containers, but I’ve some work to do to catch up to your skill level. That said, the above comment is music to my ears with where I am at in the learning process just now, it just resonates. Have a good weekend!