Steam for Linux client adds support for Linux namespaces | Hacker News Reader

Steam for Linux client adds support for Linux namespaces

steamcommunity.com

193 pointsbdz122 comments

This is amazing work from Valve, but I have to admit some fear that it'll eventually stop. They started to put a lot of work into Linux gaming/Steam Machines when the Microsoft Store was a potential existential threat on Windows, but with the multitude of stores now present -- Battle.net, Ubiplay, Origin, Epic -- that no longer seems to be as terrifying as it once was. In the meantime, their own survey indicates that only <1% of users are on Linux (https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw... -- click the "OS Version" entry in the table).

Still, as a full-time Linux user, I'm over the moon. I've always used Linux on my development laptop, but struggled to keep it on my desktop because the lure of gaming with remote friends has been too strong. However, after literally decades of trying to give up Windows entirely, between Proton, kernel contributions and efforts like this, I can play most of my backlog without having to resort to dual-booting or even VFIO. Even many fresh releases work without strife.

To anyone at Valve who reads HN: thanks. I know we're a tiny minority, and I'm really grateful for the continued on-going support.

Maybe this is part of an effort to build a Google Stadia competitor

This is the right answer. With Proton, Steam has a very good start for their Cloud Gaming offering.

Also, you already can play Steam games via in-home streaming on your TV or Android phone.

There is also a program that lets a remote player connect and play with your local computer. This way, you can play couch multi player games via the internet together.

Also, there was a reveal regarding steam gaming cloud recently: https://youtu.be/GqY5WYBDyyQ

Linux and Steam OS will continue to be an escape hatch, it is in their business interests to continue hedging their bets.

Just because the Microsoft Store didn't pan out a few years ago doesn't mean they won't try again.

An utopian escape hatch, store now also does Win32 and MSIX is the way forward.

Every year since XP I keep reading how PC gamers will switch in droves to Linux because of X, instead those of us that really enjoy gaming and high performance graphics are on Apple, Microsoft, Google, Sony and Nintendo platforms.

>gaming and high performance graphics

>Apple >Nintendo

What? Nintendo and apple do not provide high performance graphics for gaming. Apple actively tries to kill gaming on their platform by not supporting vulkan and killing open gl and nintendo has never had high performance graphics.

They do more high performance graphics than the large majority of GNU/Linux "gamming" environments.

Apple is not killing anything, anyone that has a name on the game industry already supports Metal, because professional game studios care about performance and productive tooling not about API religion wars.

Game consoles, outsolding any Linux based platform, also don't support Vulkan, so they are also killing gamming?

Yes, Switch does Vulkan, but their main 3D API is NVN and most of their titles are being done in Unity/Unreal, with Unity already having over 50% of Switch titles.

You are very uneducated on the topic if you think macos is a more suitable setup for gaming than Linux. The Mac gaming community consists mostly of casual gamers since the only hardware available is weak laptops or $10,000 workstations. Proton being built in to steam means that most games just work on Linux with a high level of performance. AMDs open source drivers are very good and included with the Linux kernel.

Currently there are no game consoles you could consider high performance but the switch is by far the lowest performance. Which is fine for what it is but it not even close to something you would substitute PC gaming with.

I bet I have been in more GDC events and some AAA studio offices than you have...

It appears to not have done you any good.

Not only did you get significant details wrong, but when faced with criticism, you immediately do an appeal to authority.

Not a good look.

Well, I am used to FOSS bias against what professional game developers care about, to the point that even random accounts get created just to reply to me.

First learn about what the corridors of IGDA, PAX, GDC, GDCE, Reboot Develop look like, then do your religious wars on graphics APIs.

Why have a war on graphics APIs when Linux and Wine implement most of them including the proprietary ones?

I have spent more hours playing warframe on linux at 144fps than I would like to admit.

gotta wonder how small the % of linux users was prior steam

not exactly what your asking for, but you can check out which OS's users were using for Steam for the past decade

https://web.archive.org/web/20160201000000*/http://store.ste...

Nice

I'm with you in that tiny minority. And fully share your perspective. Thanks to the folks making this happen!

> their own survey indicates that only <1% of users are on Linux

This is interesting to me because I spend 99.5% of my time on Linux (even for most of my gaming), but I still boot into a different OS when I want to use Steam, so I don't show up on the stat sheet. I wish I did. Two reasons I do this:

1. The Steam installation is kind of messy on my OS (Arch Linux). It involves a big client that doesn't integrate into the OS very well, requires a lot of 32 bit compatibility libraries that I wouldn't otherwise need, and leaves a bunch of large data files all over my home folder.

2. It simply feels weird and uncomfortable to run closed-source DRM-including software on Linux. I can't explain it any better than that, because it really is just a mental "purity" thing. I'd rather completely separate the "foreign" software that I have this instinctive distrust for onto a separate system entirely, where I already don't trust the OS.

I'm still grateful to Valve for the support, because it encourages developers to get their software to run on Linux, even if most of the games I play are DRM-free binaries purchased from the developer.

To me it feels weird to use binaries from outside the repos, period. On Windows double clicking an exe file feels natural. On Linux "chmod +x something && ./something" is icky.

That's a good point! Maybe that's the source of it. I've gotten used to it for a couple of statically compiled long-lived binaries (games), but other than that even software I compile myself gets packaged before I install it.

You can run GPU accelerated apps in a container. You just need to install the same video driver and expose the x11 socket and card device. The app could still be evil and screen scrape or key log but at least it has no access to your filesystem and when the container is off it is truly off (assuming reasonable container security). There are several tutorials out there for at least browsers.

You forgot sudo. IIRC Windows Steam asks for Admin rights.

You are correct, it does.

Uhm, sudo on a proprietary binary outside the repo? ...Yeah no thanks.

What difference does it make really. Running a program on linux as a regular user can access all of your files, record your screen, keylog you, grab your passwords from your browser, do basically anything. Run it with sudo and what more can it do? Mess up your grub config? If a malicious program was run as a regular user it could basically ruin everything you care about unless you happen to be sharing a computer with multiple people but even then it could just wait until you run something with sudo and keylog your password.

How could a unprivileged program keylog my sudo typings? (I am running Wayland)

What CPU are you running? Spectre mitigations enabled? Hyper Threading?

Greater issues with possible persistence, control over daemons and sockets, access to lots of files I don't let regular users have access to, etc.

Plus the other half which is the whole proprietary binary side of things. IMO, lack of transparency invites more bad behavior.

Multiplayer Windows games in general ship anti-cheating software implemented as kernel modules that are more invasive than even draconian DRM.

I've played several multiplayer games for Windows and I've only seen Fortnite do this.

Many "serious" multiplayer games will feature this. I mean VAC, EasyAntiCheat, BattlEye. They all have a kernel module component.

Not necessarily. [0]

Also, it is actually quite trivial bypassing UAC prompt in Windows. It simply gives a false sense of security.

Something as simple as SilentCleanup [1] still works to this day. This will bypass UAC with little effort.

Even worse, following that, it is also trivial to get NT AUTHORITY\SYSTEM using Windows Management Instrumentation Event Subscription. [2]

I've done it as an exercise in Go out of all languages and it ended up fully undetected both on disk and during runtime.

So Windows simply provides a false sense of security. After all Microsoft themselves said [3]:

  One important thing to know is that UAC
  is not a security boundary. UAC helps people
  be more secure, but it is not a cure all.
  UAC helps most by being the prompt before
  software is installed.

[0] https://amonitoring.ru/article/steam_vuln_3/

[1] https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10...

[2] https://attack.mitre.org/techniques/T1084/

[3] https://blogs.msdn.microsoft.com/e7/2009/02/05/update-on-uac...

> On Windows double clicking an exe file feels natural.

Isn't that just because the system is less structured in general, so you've been beaten into submission?

After spending years on Linux pretty much everything on Windows feels like it's potentially spewing ick all over the place (registry, arbitrary folders, etc, not to mention the lack of reproducibility)!

This is how I feel when I use Linux!

Windows is moving towards apps living only in their own little containers, nice little isolated folders that they can't write outside of, with the exception of their reserved folder in AppData.

In contrast, *nix bunches executables up en-masse into a handful of folders.

It likely comes down largely to what you are used to.

It's an issue of familiarity. I still feel that everything installed by distros' package manager or via "make install" is spewing ick all over /etc, /usr, /var, and God knows where. On Windows, almost everything only ever sticks to a) its installation folder, and b) the registry.

Truth is, Windows is a mess when installing stuff also. Beside installation folder and registry, there is also user's AppData folder, \ProgramData in system drive, and then installers tend to leave some MSIs in \Windows\Installer, all the libraries in System32 and sometimes, they also place stuff in Program Files\Common files.

The best at isolation has historically been macis, and then again you have plenty of packages installing to /Library, kernel extensions, uninstallers being placed in Applications/Utilities, MS updater being placed in /System and so on

I use separate debian nspawn containers for this kind of crap.

It doesn't bother me to turn on multilib support in a rootfs I only boot in a container just to run steam client and its games. Though I do have to reboot into a kernel w/32-bit support first which can be annoying.

> Though I do have to reboot into a kernel w/32-bit support first which can be annoying.

Isn't that in by default on pretty much everything? I'm not aware of any distro shipping an x86 kernel with 32-bit support disabled, anyways. Are you intentionally building your own kernels and removing 32-bit compatibility? Seems like an easier thing to fix than having to reboot every time.... (Unless I've misremembered and that is a default, in which case please correct me because that throws it the other way)

I build my own monolithic kernels, and only enable the features and drivers I use.

My host is all 64-bit userland, it's just exceptions like Steam stuff that need 32-bit support (even the Steamworks/Steampipe developer side is annoying like this). So I boot into that kernel when doing those things, and keep those userspaces in separate containers which also get "booted" when needed.

I run Steam under a different user account (and X server). It takes care of the junky home directory problem. However, the main reason is because I don't trust all the random game developers.

Why not just Flatpak Steam?

1) You complain of messiness on ArchLinux? Clearly you are not the target for ArchLinux and would be more suited to an easy to use distro, instead of one of the hardest to use.

I don't think Arch is messy. Difficult to use, certainly, but architecturally it's far more clean than Ubuntu.

Agreed, Linux gaming has finally gotten to the point where it's actually pretty good, largely thanks to Valve's efforts. I'm grateful to them for that.

I do also worry that it'll eventually stop, but right now, with the competition essentially actively discouraging native Linux ports (EGS exclusives with no support for Linux downloads)... well, I'll take whatever I can get with open arms.

You say that but while there's a few good games but not that many and if you talk to anyone that games on Linux I guaranty you that we all own all those games.

I think the author above is including Proton, which actually works pretty well for many Windows games running on Linux.

Eh, who cares how it works? What matters to me is that I want to play games on Linux[0] and I can.

[0] Well, I say want to, but I literally do not own a Windows machine, so it's more that I only can play games that work, in any reasonable way, on *nix.

I don't understand such comments. Maybe if you're chasing the latest AAA game. But all the last games I bought had Linux versions. Back in the era of Loki games, maybe what you said was true, but that's 20 years ago now.

It's easier to count the games that are hostile to Linux these days, and they're usually exclusive to Epic anyway.

I'm talking AAA games available on steam without having to run something like WINE.

I like games with strong immersion and narrative and on Linux that's restricted to Alien Isolation, the BioShock series, the Metro series, etc. and that's something which is rare on Linux unfortunately.

I, like many Linux users, have a windows boot partition just for games and the few Windows applications that I can't get on Linux I'd rather not have to do it but it is what it is.

I don't understand the need for the arbitrary "without running something like wine" distinction. Wine has gotten head and shoulders better in the past year or so. Between the gallium nine direct 3d state tracker which gives better performance in Linux than in windows for directx 9 games, (!!) dxvk giving directx 11 support, <edit> vkd3d adding directx 12 support,</edit> and Valve's seamless integration of wine in the Linux steam client, wine is just peachy.

If your objection to wine is philosophical as opposed to practical, why is dual booting into Windows an alternative?

I must admit I didn't realise Valve had WINE integration into Steam. When I used to do it I had to have a separate steam client which ran under WINE.

Basically I don't have the time to tinker anymore, I want things to work and I don't want to violate licensing agreements.

It's an option in the menu now and it just works.

Nice, I'll have to check it out.

>This is amazing work from Valve, but I have to admit some fear that it'll eventually stop. They started to put a lot of work into Linux gaming/Steam Machines when the Microsoft Store was a potential existential threat on Windows, but with the multitude of stores now present -- Battle.net, Ubiplay, Origin, Epic -- that no longer seems to be as terrifying as it once was. In the meantime, their own survey indicates that only <1% of users are on Linux (https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw.... -- click the "OS Version" entry in the table).

While this is true, I can also definitely see the logic in continuing to invest in a Plan B to protect the company from future external threats. I'm thinking along the lines of Apple maintaining an x86 port of MacOS for years before it ever became a public thing just in case.

Valve certainly has the resources to keep such an escape hatch open for themselves.

> Battle.net, Ubiplay, Origin, Epic

Not sure how relevant are the first 3 of those in this context. Battle.net, UPlay and Origin are basically just download/update systems for Blizzard, Ubisoft, EA and not a real competing store that could take over the whole market.

Epic's store is the only one that sells 3rd party titles.

More relevant competition would be GOG and to some extent itch.io (recently surpassed 200k titles in their catalog, but it's mostly very small indie games).

OT but pretty keen to figure out why someone decided that they needed to invest in a 52 core gaming rig last month (check the last line of the Linux table) https://store.steampowered.com/hwsurvey/cpus/

The thing is, Valve put in the initial investment to support Linux in a big way. Now that things seem more stable, they could pull that support and save money. But how much money would they save? Maintenance of what they have now is far cheaper than the initial investment.

So why not continue support? It’s always, always nice to have an escape hatch you can point to should Microsoft get that look in their eyes again.

I dunno. If Windows continues its downward slide Linux will eventually be the lesser of two crap-piles and Steam will be well positioned to take advantage of it. How long will it take EGS to catch up with that?

Does anyone know or have theories why Valve is doing all of this work? I mean, I love it. I use Steam on Linux and almost my entire library works perfectly. I couldn't be happier. But with Steam Machines seemingly dead, and such a small Linux base, why is Valve doing this?

And yes, seriously, _thank you_ Valve!

Their streaming service can easily use Linux, like Google does with Stadia. That would be a very obvious way to benefit from their own investment into Linux gaming ecosystem. Especially, since unlike Stadia, they are aiming at making their whole catalog work on Linux, using Wine (Proton) and etc.

> Does anyone know or have theories why Valve is doing all of this work?

I believe the running theory has been that it's a defense against Microsoft being Microsoft. If MS tries to do something like force all NT apps through their own store and take a cut of every sale, or anything else that poses too much threat to Valve, then Valve has an escape hatch in the form of Linux support. "You want 30% of our sales? Screw you, we'll tell our users to switch to Linux!" is a bit extreme, but it just needs to be a deterrent.

And they will get as many to switch as when DX 10 was only Vista, and other hurdles announced as the opportunity for GNU/Linux take over the gaming world.

Linux dominates mobile, supercomputing, servers and embedded.

There is no fundamental reason why it can't eventually take over gaming, or even desktop.

The fundamental reason is that there is no big company pushing Linux on the Desktop. The Linux Desktop community has thus far proven, if I'm being frank, completely retarded at making anything people actually want to use.

It's not as bad as you say. Ubuntu has made a decent attempt, with some (albeit minor) success. But Ubuntu seems to be moving away from desktop to also focus on cloud stuff. Valve has done a lot of work with Windows compatibility.

One thing I'm observing is that macOS and Windows are basically regressing to have the same type of nonsense and quality issues that are indeed typical on desktop Linux. It's possible (but not certain) that they'll eventually cross paths. Linux might not take over the consumer desktop market (unless it's under a proprietary shell, like Android / ChromeOS), but Linux could possibly take over the high-end/power user/workstation market.

Maybe, but that will still either require some big player to come in and make sane decisions to tear the Desktop portions away from the garbage way they're done now, or for the community to get it's act together. I have been waiting 20 years for the latter and do not expect it to ever happen at this point.

Android and iOS dominate mobile.

The kernel used by Android is completly irrelevant to userspace and can be changed tomorrow at Google's will, and only OEMs and rooted devices will actually notice it.

On embedded there are plenty of OSes to choose from, with FOSS embedded industry support moving to MIT/BSD licensed kernels, as OEMs don't want to deal with shipping GPL code on embedded devices, specially after v3 happened.

Steam would cease to exist and so would the thousand dollars worth of games people have accumulated in their accounts. As long as proton works there is a huge incentive to switch.

I bet that would happen as much as the massive gamer migration that has been going on since XP, which is to say, not really.

Same. Many thanks to Valve for their work. I went linux only before proton for ideological reasons and the relatively recent strides with proton, the steam client, and moves like this really make me happy to continue to be one of the 1%rs running steam on linux and support valve for their efforts. I can't wait to buy an index vr headset and try to dev with it in godot.

Valve, if you are reading this, just please make sure source 2 has a linux compatible editor! One thing I miss is modding source games.

macOS has a 14% market share, yet there are many products developed exclusively for macOS that are highly profitable.

Linux may have a 1% market share, but when you release on Windows, you will not only target a larger audience, but you will have to share that audience with a large number of studios. The AAA studios will take the lion share of the revenue.

I think in Linux there's still some room for indie games to thrive. Sometimes all it takes if you are using a game engine like Unity is to simply create a cross platform build that may work out of the box.

This is only tangential, but I realized I never wrote this down and figured I’d take the opportunity.

Ever since Steam published their non-Windows clients, we randomly get support requests from Steam users on Linux and macOS because the (all stacks) backtrace contains references to the WFMO WIN32 events library I open sourced many, many years back [0]. Always makes me smile though, my small contribution to Linux gaming. (Somewhat ironically, even Microsoft now uses this for cross-platform projects with VS Code being the primary example.)

I think all library developers (open source or otherwise) would probably do well to adopt the etilqs hack, you never know where your code will end up.

[0]: https://neosmart.net/blog/2011/waitformultipleobjects-and-wi...

Neat read, & thank you!

Thank you!

The main benefit is that it makes Steam not depend anymore on the installed packages of the host Linux distribution.

Part of this is that Steam can still use 32-bit libraries even when the host Linux distribution has fully moved to 64-bit.

See recent discussion at https://ubuntu.com/blog/statement-on-32-bit-i386-packages-fo...

While you would have expected from Valve to use an existing container platform, they went ahead and used directly the security features of the Linux kernel in Steam.

Assuming your kernel is compiled with IA32 emulation

It's not emulation; x86_64 processors are backwards compatible (to a fault, arguably...), so it's just a little bit of support that AFAIK everyone leaves enabled because why not.

I am aware, nevertheless the flag is called CONFIG_IA32_EMULATION because the 64bit kernel is emulating the 32bit syscall interface.

I'm building a new PC soon and plan on trying my hand at a Gentoo box. Is this something I want to make sure is set if I wish to use steam?

For now, I think it's the default everywhere.

> The main benefit is that it makes Steam not depend anymore on the installed packages of the host Linux distribution.

Now if only most other Linux software could do that.

Aah no!

You get this with Snaps, Flatpak and AppImages

I'd argue you really only get it with AppImage, which is treated like garbage by the community as a whole.

Its not needed since most linux software is open source and gets packaged properly for each distro.

And when it isn't one of those things, well, fuck you I guess. That's one of the biggest reasons I think a lot of people don't use Linux, yet the Linux Desktop community consistently ignores and dismisses the issue and then wonders why Linux Desktop isn't more popular.

Flatpak exists to solve this problem.

Flatpak unfortunately has other issues inherited from a repo-based approach. Like, it can't be installed to a separate disk than the rest of the system and you can't use anything not in your repo, forcing you to setup pretty much 1 repo/application, which is ridiculous.

That didn't stop macos or android devs from uploading their apps to the play store and app store.

Oh you mean those stores developers are constantly complaining about because of entry barriers and having no recourse when their software is arbitrarily booted out? Or the ones where users complain that they can't get older versions of software and have difficulty legitimate apps in seas of fakes?

Repo models are antithetical to the concept of personal computing in my opinion.

It could of course, see for example any big commercial software like Mathematica, Matlab etc. . However, doing things that way is something you really, really want to avoid if at all possible.

Why? Because it actually works and makes things simple instead of causing a giant headache for users? Because it gives users the power to consume software directly from developers, cutting out a third party repo maintainer?

Yeah sure, those are obviously the reasons.

This might actually get me back into using Steam on Linux. I've bought cheap old school games "ported" to Linux that were just Wine underneath and the endless hassle of trying to get the dependencies fixed to where it wouldn't crash took literally hours and then halfway through the game it crashes and I wasn't even able to fix that one. Being able to just wrap everything up all nice and neat in a fixed environment could be a godsend for some of these old games.

Something nobody else seems to have said here, is that Valve's work on Linux, Proton, streaming from one device to another (even phones), etc, puts them in an excellent position for cloud gaming, as pointed out by [1]. Namespaces support seems like an obvious next step here.

Valve is already in the best position for this, since they're the dominant market player and gamers already have their game libraries in Steam. Buying a game from Valve makes more sense than buying a game from Google Steam users get to keep a playable product even if the streaming product is a flop.

[1] https://www.gamingonlinux.com/articles/looks-like-valve-coul...

I recently moved to Linux as a primary (and only os). I was a windows user because of games and I was so fed up with automatic updates, privacy concerns and so on that I decided to fully go to Linux. I searched a lot over internet before choosing a distrib (I'm not pro Deb or rhel or else) so I ended up with Manjaro (KDE version). And it such a delight fully customizable. Steam installed with some of my games working without doing anything "complicated", I was impressed! And then I installed lutris for all non native games. I expected much much troubles but in fact, it was easy. I installed Epic games store first and oxenfree just to test. It runs smoothly! I also installed Control (great game) in standalone still with lutris. I finished the games with only two or three crashes. So yes gaming on Linux is not ideal it might not be with the best performances also but it was much much easier than I though before doing the big step from windows to Linux. I'll follow any new improvements for gaming on Linux and I hope in the future that every store and game will be accessible natively on Linux. And that more and more user have the choice of the os they want!

There was that time the Steam client rm-rf'd your home directory because of a typo in its wrapper shell script. Also, the client itself requires a bunch of packages that I'd rather not install on my machine, because my distro packages don't match what it wants, and because some of the packages it wants are 32-bit ones.

So I just run Steam itself in a Docker container. The home directory inside the container is mounted to a subdirectory of my home on the host, so even if Steam wipes everything from it the only thing I'd lose is Steam itself.

I didn't know you could run graphical apps in Docker. How does that work?

    rm -f ~/docker-games/root/.Xauthority
    touch ~/docker-games/root/.Xauthority
    xauth nlist "$DISPLAY" | sed -e 's/^..../ffff/' | xauth -f ~/docker-games/root/.Xauthority nmerge -
    chmod 0444 ~/docker-games/root/.Xauthority

    XSOCK="$(realpath /tmp/.X11-unix/*)"

    DBUS_SESSION_BUS_PATH="$(echo "$DBUS_SESSION_BUS_ADDRESS" | sed -e 's/^unix:path=//')"

    docker run -it --rm \
        --device '/dev/dri:/dev/dri' \
        -v "$XSOCK:$XSOCK" \
        -v "$(realpath ~/docker-games/root):/home/arnavion" \
        -v "$(realpath ~/.config/pulse/cookie):/home/arnavion/.config/pulse/cookie" \
        -v "$DBUS_SESSION_BUS_PATH:$DBUS_SESSION_BUS_PATH" \
        -e "DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS" \
        -e "DISPLAY=$DISPLAY" \
        -e "PULSE_SERVER=$(ip -4 addr show enp4s0 | grep -Po 'inet \K[^/]+'):4713" \
        -e 'XAUTHORITY=/home/arnavion/.Xauthority' \
        --shm-size '1G' \
        --hostname arnavion-docker-games \
        docker-games \
        $COMMAND

The XSOCK mount allows it to talk to the host X server, and the .Xauthority mount allows it to auth with the host X server. Apart from that:

* ~/docker-games/root is the home directory inside the container.

* The DBUS mount and env var is to allow Steam to show its icon in the system tray of the host DE. There's also a symlink for `~/.steam/public/steam_tray_mono.png` -> `~/docker-games/root/.steam/public/steam_tray_mono.png` so that the host DE can find the icon based on the path inside the container.

* The pulseaudio mount and env var is to allow sound. It requires pulseaudio to be set up to allow network clients.

Here's the full gist: https://gist.github.com/Arnavion/3212232d0761d49d9636f796c5a...

Wish I can find it now but there was an obscure article 10 years ago or so, maybe it wasn't an article even, which argued that the "desktop linux" will be gaming only. Linux will be as is now, enterprise, business, programming etc + gaming. But no middleground. Anyways just feels like we are closer and closer to that

There are 7 types of namespaces, I don't see it mentioned which types they use.

Mount namespaces are not a big deal to use, as long as you freely bind-mount from /dev and /sys whatever your software might need. The effect is mostly protecting your home directory against both reading and modification and isolating your system installations against version and configuration conflicts.

Uid namespaces are really challenging if you try to make some complex software system work. They give a lot of isolation from the host system, some would say also new risks that the isolation has unexpected privilege escalations.

Disclaimer: Not a gamer on any platform, so I don't know Steam other than from hearsay that it's the only serious one running on Linux.

Is there a list of games that actively take advantage of containerization (i.e. old libraries, etc..)?

For example, I can't run the GOG version of Legend of Grimrock on Fedora 31 because of libraries. This is the type thing that would that problem.

(How) does this affect graphics performance? And how does the container communicate with the graphics engine? Just an X11 socket linked into the container?

> (How) does this affect graphics performance?

Namespaces are default feature within the Linux Kernel. If a process isn't isolated in any way, it's automatically assigned the default namespace. So what they've done is simply run the game processes in the a separate namespace. Therefore there should be negligible performance impact if at all.

Can someone please do an ELI5 for Linux namespaces and why this is important for a better Linux Steam client?

I don't know the answer, but a sibling post confirmed by suspicion: It allows you to run games in a container without having to set it up yourself. If you want to run Windows games using Steam on Linux, you have to have a bunch of libraries available which you will almost certainly not use in your normal day to day activities. Having the software in a container means that all those libraries are bundled into the game distribution and you don't need to maintain them yourself.

This isolates steam games from the rest of the things running on the machine, which dramatically reduces the number of variables Valve has to consider for supporting a Linux game. This means they can support more games with fewer resources, or give better support to more games.

With namespaces and cgroups and chroot and bind mounts you can cobble together an isolated linux distro running on the same kernel as yours. So for example, Steam can target having a game run on Ubuntu 16.04, and ensure that it runs well there, while you can go ahead and use Arch, or Fedora 31 or whatever. It's like virtualization except that it doesn't translate every instruction, it only adds some overhead to certain syscalls.

Any opinions on which containers are easiest to get working on SteamOS? Any links on how-to-guides for this?

Is it using lxc?

Probably. I had that hunch too.. seems to be the shortest and cleanest path the get namespaces. Maybe a subset of that library without allocating system resources like a vm.

Maybe if they are back doing non-Microsoft build work, they can soon support Mac with case-sensitive filesystems?

Seems somewhat unlikely to me. Now that OpenGL is gone from MacOS, the Mac is basically dead as a cross-platform gaming system. Who's going to rewrite their renderer on Metal just to target such a tiny platform? Maybe if UE or Unity do the work, games might still get Mac releases...

There are libraries like [1] that expose a Vulkan api/abi on a Metal backend.

[1] https://github.com/gfx-rs/gfx

Valve uses MoltenVK[1] on their own games. They have used it since 2018 for Dota 2[2], but I can't find a lot of uptake by others.

[1] https://github.com/KhronosGroup/MoltenVK [2] https://www.khronos.org/news/permalink/vulkan-support-for-do...

My experience from nearly 20 years of gaming on Linux: Just because a developer can support a platform, doesn't mean they will (sadly). It becomes less likely with any additional complications such as special libraries.

MacOS was already dead for gaming since they have no hardware that can play most games. Killing OpenGL and not adding vulkan just finished it off.

Unity and Unreal did the work. Both support Metal.

Both are ridiculously huge and have the money and manpower to do it.

Indie game developers though, which Steam have a sizable amount of, likely do not have the same resources.

Many indie developers do use these platforms instead of writing their own engines. From scratch is usually the exceptions

A large part if not the majority of indie games (both on and outside of Steam) are based on Unity.

And yet there are more indie games for macOS than for Linux. Life is weird.

Reply on news.ycombinator.com