And here I am having nothing to use it for, because all the software I run or need is now available for Linux.
I guess I should be glad, but it still feels a little sad? All that effort someone puts in, for a seemingly ever-decreasing need?
I recommend you to read the "Win32 Is the Only Stable ABI on Linux" post. Sums up perfectly why Wine is needed and doing perfectly https://blog.hiler.eu/win32-the-only-stable-abi/
The TLDR is that easier to make games for Windows (single OS and API) and just maintaining Wine/Proton (works across all distros) than actually making a Linux build too of the game.
Huge thread when it was posted here https://news.ycombinator.com/item?id=32471624
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.
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.
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.
Valve has its own container-only Linux distribution, the "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.
(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 )
Its remarkable that these days you can reasonably expect that just about every game will work flawlessly running in wine.
>Its remarkable that these days you can reasonably expect that just about every game will work flawlessly running in wine.
Almost every Windows game I check on ProtonDB has a non-platinum rating because of things like "game starts on a black screen until you blindly press a key" or "ending cutscene doesnt play" or "mouse acceleration doesn't work" or a billion other broken things. Is the game playable despite these issues? Sure it's playable. But the fact is that when game devs ignore Linux users assuming that Proton exists, then there is no incentive for them to fix these issues. Even a playable game today can become completely unplayable tomorrow because of a game update that works fine on Windows.
With a native build you get a guarantee from the dev that they'll fix their Linux issues.
This was very much not my experience, games would often be broken if you didn't use ubuntu, or if they were a few years old. And the company wouldn't care because the contractors who ported it are gone. Often even leaving the linux version out of date.
While any issue with the Windows one in wine, eventually basically any issue I encounter gets patched by an active team of open source devs, some funded by valve.
>While any issue with the Windows one in wine, eventually basically any issue I encounter gets patched by an active team of open source devs, some funded by valve.
We don't need to talk about your experience. Pick any game in ProtonDB that has a Platinum rating and you'll find 10 more that are lower because they have the issues I described.
>games would often be broken if you didn't use ubuntu
The reality is I game entirely on Linux and everything works perfect for me.
If only! In practice, there is no such guarantee; I've seen several Linux-native titles release breaking updates (anything from mild annoyances to rendering it completely unplayable) for a long time, sometimes for several months. The studio is very likely to de-prioritize or even ignore bugs report because the market share on Linux is just so insignificant.
There is also the fact that some games actually run better on Linux under Wine than they do with the native version.
I don't have data, but I'd guess that the Wine project resolves more issues in Linux games than the studios do with their native ports.
haha