Celebrating 6 years since Valve announced Steam Play Proton for Linux | Hacker News Reader

Celebrating 6 years since Valve announced Steam Play Proton for Linux

gamingonlinux.com

340 pointsfreedomben158 comments

Can confirm as a recent switcher from 25 years of Windows to a Fedora Linux Desktop that all the flagship games I downloaded from my steam library just worked, which was the final hurdle before being able to switch to Linux full-time.

I initially had some issues with not being able to run Wayland due to Nvidia drivers, but that's now fixed with Explicit Sync support in their recent driver upgrades and am now using Wayland.

Thanks to Docker, JetBrains IDEs and most Daily Apps I use are cross-platform Desktop Web Apps (e.g. VS Code, Discord, Obsidian, etc) I was able to run everything I wanted to. The command-line is also super charged in Linux starting with a GPU-accelerated Alacritty running Oh My Zsh that's enhanced with productivity tools like fzf, exa, bat, zoxide and starship. There's also awesome tools like lazydocker, lazygit, btop and neovim pushing the limits of what's possible in a terminal UI and distrobox which lets me easily run Ubuntu VMs to install experimental software without impacting my Fedora Desktop.

Anyway happy to have abandoned the Surveillance and Spyware train that Windows has become, thankfully never have to go back thanks to the great support of Steam and cross-platform Desktop Apps running natively on Linux.

Are all those features really more important than core features of the OS? I switched a couple years ago because of Windows' flaws. The constant notifications and other distractions such as updates, not being able to jump into programs reliably via the windows key search, broken sleep. Windows laptops fail at just being laptops, first and foremost they are delivery platforms for whatever Microsoft pushes.

Now I cut out Intel and Nvidia I have an AMD machine with Debian, and for the first time I have a stable, dependable machine. I know how long the battery lasts and I can leave the house without a charger. And looking back, windows always had you on your toes, it is so instilled in us to work around its flaws.

It is underrated how much a productivity hit the constant changes in windows cause

Exa has been discontinued, probably worth switching to eza.

https://github.com/eza-community/eza

Didn't know lazydocker. Thanks! I learned something today.

There is also oxker! https://github.com/mrjackwills/oxker

The situation outside steam is sadly still pretty bad.

Imagine you buy most of your games on DRM free platforms and they hardly even install on any gaming focused distribution.

There are now third party launchers for proton, such as: https://github.com/Open-Wine-Components/umu-launcher

As well as "game libraries": Lutris, Bottles, Heroic

Personally I use this alias to launch an exe via proton:

  alias proton='SteamGameId="${SteamGameId-1000}" PROTON_USE_WINESYNC=1 STEAM_COMPAT_CLIENT_INSTALL_PATH="$PWD" STEAM_COMPAT_DATA_PATH=$HOME/proton /usr/share/steam/compatibilitytools.d/proton-cachyos/proton waitforexitandrun'
  # cd /gamepath
  # proton Game.exe

I wonder if there is a chance Valve could release a standalone proton wrapper for such situations. Then We could install and run these DRM free games or even games you legally purchased years ago and still own.

I find heroic quite nice for gog and egs games.

As I often repeat in these threads, Proton was an amazing leap. Once it released, it took probably two years for me to boot Windows again, and it's only been getting better. Now I'm already used to assuming games will just work on my Linux machine, including new major titles. Age of Empires 4 and Baldur's Gate 3 just worked.

In broader terms, Proton is also a valuable lesson in how much the "last 10%" integration of software matters. Proton isn't developed from scratch by Valve, most of it is non-Valve code. Proton base is Wine plus DXVK plus gstreamer, but it's Valve's integration of those that allows the dramatic leap from "if you're a power user, you may get the game to work after lots of tinkering" to "just enable Proton for this game and click play".

Not only integration, proton also includes some patches of wine itself. Even though most of patches are merged back to upstream, but some are not.

Valve is also paying some developers of open source projects like DXVK or Mesa to keep working on it. I think it is also the key to its success. And it shows a good example to some big companies that how to use FOSS libraries correctly.

Yeah, my understanding is that the key element that makes Proton games run so well is running the graphics through DXVK instead of Wine's WineD3D solution. Wine is excellent at the Win32 API but its D3D solution never advanced enough to support many complex applications like games. DXVK is extremely good at that.

Valve pays DXVK devs, and I think CodeWeavers, with their long history of commercial Wine support, has also been getting paid by Valve to improve Wine in the specific ways required.

Yes, and it also creates a more active community. I played some old games with wine about 12 years ago. Like you said about WineD3D, it was not a good experience, just usable.

And wine does not implement all the APIs. If you do not submit requests or report bugs, the community will not fix it. So the source code contains a lot of "fixme" and stubs. Some APIs are implemented without the support of some flags.

In this case an active and sustainable community is very helpful. Not only for the business of Valve and CodeWeavers, but also the whole "running Windows apps on Linux" thing.

How relevant is the part about running Windows applications through Wine now? I'm under the impression it's less relevant than it used to be, due to web apps now having replaced a lot of native programs, and many native programs are just disguised webapps, like VS Code.

For example, you cannot get a copy of Windows 95/98/ME legally right now. So if a customer is asking you for a copy of your very old software product, maybe a copy running on wine is a good option. It is known that some systems in the world are still using floppy now. In that kind of case, wine with Linux can be seen as an alternative way of using that old illegal copies of Windows.

For modern applications, you do not need to do that. Even though it cannot run on Linux natively, you can always find some alternatives.

> For example, you cannot get a copy of Windows 95/98/ME legally right now.

The first sale doctrine and other countries' equivalent laws still applies.

Wine's Vkd3d translator is still used for DX12. DXVK does not support DX12. I believe WineD3D has gotten better, but it is also based around OpenGL rather than Vulkan like DXVK and Vkd3d are.

I was playing around with a Snapdragon 845 handheld running Linux like 2 years ago, and running older games like DMC4 using WineD3D fine. Using an additional translation layer of box86 to run x86 proton on ARM.

I tried to boot Windows recently because a friend wanted something from my Photoshop, and I realized it won't even boot now, the bootloader got hosed somehow. It's been years since I used it, thanks to Proton.

I recently bought a machine with an RTX 4090 and a 7950X3D.

Installed Pop OS; expected there might be one or two hiccups with the Nvidia drivers. Yet I had zero driver config/installation issues - and there's not been a single Windows game I could not play on Linux at full settings.

On top of it the Linux machine also streams to my Steam Deck.

I've abandoned Windows 2 years ago - I see no reason to ever return.

> there's not been a single Windows game I could not play on Linux at full settings

I also enjoy playing on Linux but this really depends on the type of games you play. If you play a lot of multiplayer games, you will be disappointed on Linux, Riot games won't work, Blizzard games won't work, Fortnite won't work

Even with Elden Ring that runs perfectly on my Linux machine, I cannot use any multiplayer features (summoning friends, reading messages etc.) because the EAC anticheat doesn't work on Linux

EAC anticheat does work on Linux, but it requires a little effort from the developer to enable it, for example I played New World on Linux which requires EAC anticheat.

As for Blizzard I have no idea about the other Blizzard games, but I play Diablo 4 using Lutris, other than one update that caused the Battle.net launcher problems it works fine, at least for D4 (and D3).

Yup. Most of the anti-cheats have been ported to Proton at this point. Usually when games don't enable it, its because the games haven't been well-engineered and are too easily exploitable.

Destiny 2 is another example, turning on BattlEye on Proton is literally flipping a switch in the SDK. And they had a Destiny build for Linux because it was running on Stadia. But Destiny has a horrible codebase, and even with BattlEye on Windows there is a decent chunk of hard cheating.

And its not that just the non-competitive games choose to allow Proton. Halo and Apex Legends are good examples that play on Proton.

You must be mistaken on the elden ring multiplayer bit, I was not too long ago summoned as a blue phantom when playing on my steam deck.

ER multiplayer works on Linux. It crashed for me when trying to invade but installing PulseAudio fixed the issue and been working flawlessly. Running Steam through the terminal can make debugging a bit easier

> Even with Elden Ring that runs perfectly on my Linux machine, I cannot use any multiplayer features (summoning friends, reading messages etc.) because the EAC anticheat doesn't work on Linux

I had to disable online features in Elden Ring in order to get rid of multitude of messages from other players. That was on Steam on Linux.

I haven't tried friend summoninig, but online features did work for sure.

I've played wow on my steam deck, in addition to Warcraft 3 remastered.

Blizz games are definitely doable now for the most part.

Hearthstone mostly works. Wow doesn't

Really? WoW used to work just fine back in the day (~2010). Is that no longer the case?

Most of the bots use headless linux VMs for WoW, which is why Blizzard stopped allowing WoW to run on linux.

WoW works and has worked perfectly fine on Linux for ages. Likely just unrelated user issues.

Playing wow on Linux for a while now. 4k/60fps, max detail. works just fine

All these comments are pretty funny, I’ve been considering building a new gaming desktop (the current one is reaching a decade of age) and was very much thinking of putting Linux on it rather than bothering with Microsoft’s ever worsening, it’s giving me fomo and making me consider switching the old machine in the first place.

How well are HDR and raytracing features supported on Linux?

Kind of a sore spot actually.

I think raytracing is fine, as Vulkan on Linux is phenomenally good & active, is seemingly the go-to spot for Vulkan as a whole. Proton turned on raytracing support by default 9 months ago, and it's probably not flawless, but runs many flashy games like Cyberpunk 2077.

Valve's Wayland compositor is called gamescope, and gamescope has kind of forged some kind of path to make HDR work. And that relies on kernel patches that dont seem intended for upstreaming. It's all packaged and works great on Steam Deck. I have tried and tried to get the same stack working locally with a rx580 but no dice, can't get gamescope embedded to run, to much chagrin & sadness.

Wayland and Linux both have been on a long sojourn to make good protocols & implement HDR. It's finally coming together; KDE is shipping something. I don't know if GNOME and Wlroots have actually started work but there are tickets. https://wiki.archlinux.org/title/HDR_monitor_support

Valve had the resources to cut their own path, and it's kind of awesome & excellent. They've made a Cathedral atop Linux. I want to think that if Wayland wasn't so new in general, if there was more bandwidth & focus & not tons of other necessary big work in flight, HDR might have advanced at a much more respectable rate. But who knows. I think it's important to have appropriate expectations, and this slow walk does show a weakness of the Bazaar model of development that Wayland embodies. But I really want to hope it's for an excellent end result, that HDR has well considered development path by the time it's really in the wild.

HDR soon! After a lot of puzzling it out.

Only Steam games, right?

A number of games (and non-games) can be added to Steam via the "add non-Steam game" option and then used with Proton. There's also Lutris.

I'm jumping on the occasion to reiterate here that Valve's Proton team hiring process is good, and although I wasn't picked, the time they took to help me improve, give me advices, as well as the overall communication make me think their company should be great to work with (at least 3-4 years ago)

Searching for "valve proton team" doesn't bring up much, how did you find a job ad from them?

Given Valve's structure (you choose what you work on) I wouldn't expect a job ad specifically for the Proton team. So it would probably fall under https://www.valvesoftware.com/en/jobs?job_id=57

Besides that, Valve does approach people who already do good open source work in the space.

Thanks!

Coming out of an interview process learning new stuff and happy in defeat will always make me feel good.

I switched my gaming PC to NixOS a few months ago, I couldn't be happier. Other than a few games that also had issues on Windows and VR, everything I run through Proton just works.

I also own a Steam Deck, which is a wonderful little device and it proved to me that I could safely go through with this switch and not lose access to much.

Congrats to both the Proton and hardware team at Valve, and the people who contributed to Wine; the Year of the Linux Desktop has come, as far as I'm concerned.

I've seen it joked that with Proton, Win32 is a good stable ABI for gaming on Linux.

Given that, and that I'm most comfortable developing on Linux and in C++, does anyone have a good toolchain recommendation for cross compiling C++ to Windows from Linux? (Ideally something that I can point CMake at and get a build that I can test in Proton.)

Well, CL.EXE works pretty well on Wine too.... It _technically_ breaks a few terms of the EULA, but that's not too bad though.

This works pretty well: https://github.com/mstorsjo/msvc-wine

Use it alongside something like this CMake toolchain file:

set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR amd64)

    set(CMAKE_C_COMPILER cl)
    set(CMAKE_CXX_COMPILER cl)
    set(CMAKE_AR lib)
    set(CMAKE_LINKER link)
    set(CMAKE_MT mt)

    set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
    set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
    set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
    set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

after adding the various scripts to path.

If you want to speed up a little you can use `clang-cl` with the MSVC libraries, and it will work fine too.

Pretty much any distribution you are on is going to let you install mingw, but you should also be able to just use clang and ldd these days (though the header files and library stubs would still come from mingw, unless you want to just compile against an official Microsoft SDK).

> I've seen it joked that with Proton, Win32 is a good stable ABI for gaming on Linux.

It's funny because it's quite literally true. Thanks Microsoft - unironically!

MinGW works well (e.g. mingw-w64 in Debian/Ubuntu). It works well with CMake, you just need to pass CMake flags like

  -DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-c++ -DCMAKE_C_COMPILER=x86_64-w64-mingw32-c

Something like SDL or Raylib is useful for cross platform windowing and sound if you are writing games

Hey, TuxMath is written with SDL, though there's a separate JS port now IIUC.

/? mingw: https://github.com/search?q=mingw&type=repositories

The msys2/MINGW-packages are PKGBUILD packages: https://github.com/msys2/MINGW-packages :

> Package scripts for MinGW-w64 targets to build under MSYS2.

> [..., SDL, gles, glfw, egl, glbinding, cargo-c, gtest, cppunit, qt5, gtk4, icu, ki-i18n-qt5, SDL2_pango, jack2, gstreamer, ffmpeg, blender, gegl, gnome-text-editor, gtksourceview, kdiff3, libgit2, libusb, libressl, libsodium, libserialport, libslirp, hugo]

PKGBUILD is a bash script packaging spec from Arch, which builds packages with makepkg.

msys2/setup-msys2: https://github.com/msys2/setup-msys2:

> setup-msys2 is a GitHub Action (GHA) to setup an MSYS2 environment (i.e. MSYS, MINGW32, MINGW64, UCRT64, CLANG32, CLANG64 and/or CLANGARM64 shells)

Though, if you're writing a 3d app/game, e.g. panda3d already builds for Windows, Mac, and Linux; and pygbag compiles panda3d to WASM, and there's also harfang-wasm, and TIL about leptos is more like React in Rust and should work for GUI apps, too.

panda3d > Building applications: https://docs.panda3d.org/1.11/python/distribution/building-b...

https://github.com/topics/mingw :

> nCine, win-sudo, drmingw debugger,

mstorsjo/llvm-mingw: https://github.com/mstorsjo/llvm-mingw :

> Address Sanitizer and Undefined Behaviour Sanitizer, LLVM Control Flow Guard -mguard=cf ; i686, x86_64, armv7 and arm64

msys2/MINGW-packages: "[Wish] Add 3D library for Python" https://github.com/msys2/MINGW-packages/issues/21325

panda3d/panda3d: https://github.com/panda3d/panda3d

Before Steam for Linux, there was tuxmath.

tux4kuds/tuxmath//mingw/ has CodeBlocks build config with mingw32 fwics: https://github.com/tux4kids/tuxmath/blob/master/mingw/tuxmat...

Code::Blocks: https://en.m.wikipedia.org/wiki/Code::Blocks

There's a CMake build: https://github.com/tux4kids/tuxmath/blob/master/CMakeLists.t...

But it says the autotools build is still it; configure.ac for autoconf and Makefile.am for automake

SDL supports SVG since SDL_image 2.0.2 with IMG_LoadSVG_RW() and since SDL_image 2.6.0 with IMG_LoadSizedSVG_RW: https://wiki.libsdl.org/SDL2_image/IMG_LoadSizedSVG_RW

conda-forge has SDL on Win/Mac/Lin.

conda-forge/sdl2-feedstock: https://github.com/conda-forge/sdl2-feedstock

emscripten-forge does not yet have SDL or .*gl.* or tuxmath or bash or busybox: https://github.com/emscripten-forge/recipes/tree/main/recipe...

conda-forge/panda3d-feedstock / recipe/meta.yaml builds panda3d on Win, Mac, Lin, and Github Actions containers: https://github.com/conda-forge/panda3d-feedstock/blob/main/r... :

  conda install -c conda-forge panda3d   # mamba install panda3d  # miniforge
  # pip install panda3d

Panda3d docs > Distributing Panda3D Applications > Third-party dependencies lists a few libraries that I don't think are in the MSYS or conda-forge package repos: https://docs.panda3d.org/1.10/python/distribution/thirdparty...

What about math games on open source operating systems, Steam?

A Manim renderer for [game engine] would be cool for school, and cool for STEM.

"Render and interact with through Blender, o3de, panda3d ManimCommunity/manim#3362" https://github.com/ManimCommunity/manim/issues/3362

Only if you consider HTML and JavaScript to be a good stable ABI for gaming on Windows.

Wine is indeed the most stable Linux ABI. I downloaded Freddy Fish (ScummVM), but without visible error, but readable when launching from the CLI it failed due to some LLVM runtime lib not being present with the correct version.

Instead of going through the pain that it always is on Arch to find and install the right version of the right package, I just selected the Windows version using Proton and called it a day. (Eventually I did figure out that I could modify the shell script to launch a ScummVM instance via flatpak instead of the bundled version)

Windows doesn't ship with any LLVM runtime libs either. The solution is the same in both cases: package your dependencies with the program. It's not particularly hard.

Now, if we could get the anti-cheat companies on board all would be right in the universe and I could stop pretending that Win10 doesn't drive me insane. Seriously, it's ridiculous that you can play an entire game in Linux with no issue but the second you load into multiplayer for some titles you risk getting your entire account banned.

The two biggest anti-cheat providers (EasyAntiCheat and Battleye) are on board, both can run natively on Linux or in Proton. The problem is that neither solution is anywhere near as robust as they are on Windows, so Linux support is offered on an opt-in basis and not all developers have chosen to opt-in.

Apex Legends did opt-in to EACs Linux support and the effect has been that nearly every cheat for that game now targets Linux, because it is so much easier to avoid being detected on there. I would be fascinated to know the ratio of actual genuine Linux users playing Apex versus those who just dual boot into Linux to cheat with impunity.

> Apex Legends did opt-in to EACs Linux support and the effect has been that nearly every cheat for that game now targets Linux, because it is so much easier to avoid being detected on there.

Source for that?

It makes no sense.

1. Cheating in Apex has been rampant for many years, way before the game started to work on Linux.

2. I have not heard that cheating would increase lately, especially linked to Linux.

3. A lot of cheating is being done by Chinese players. It sounds incredible (I literally don't believe) that those pesky cheaters would bother and would even be able to start using Linux on their home computers and in game dungeons.

> Source for that?

https://www.unknowncheats.me/forum/apex-legends/

Paid/private cheats are hard to keep track of but the free/open-source cheats are nearly all for Linux at this point, aside from the crude macro-based "cheats" which use AutoHotkey or similar. Apex enabled Linux support over two years ago so I wouldn't expect it to cause a recent uptick in cheating, it's been table stakes for a while.

Apex was released in the beginning of 2019, 5.5 years ago. It started to work on Linux over 3 years later.

You can easily find articles/videos from those pre-Linux days that talk about rampant cheating. Since Linux got introduced I have not seen any drastic changes to the worse, if anything it subjectively became better.

What does being Chinese have anything to do with the ability to set up Linux?

There are different cultural/gaming/technological/behavioral reasons. I will only mention one: the culture of gaming cafes; and you won't be installing Linux on those paid machines all of the sudden.

It has only been 6 years!? It has felt like a bed rock of Linux gaming in almost forever.

I cannot tell you the last time I have come across something that doesn't work via Proton.

It is one of the many crown jewels of Valve.

EDIT - ’From dust’ released in 2009 still doesn't work but that is due to Ubisofts awful DRM infrastructure.

My wife keeps complaining that Beyond Good and Evil doesn't work... but last I checked it didn't work on Windows either, thanks to Ubisoft buggy DRM and some other issue I forgot.

That sucks. Have you tried going the emulation route?

I don't know what it was like to use Windows anymore. It almost feels like I have never used Windows in the first place, and yet when I look back to the year I switched. 2018, when Proton was released, I am still kind of shocked how recent that is as a former user of Windows XP, Vista, 7 and Windows 10.

I've been so amazed at how well Proton works.

I've bought myself a Steam Deck a while ago, thinking that I _might_ be able to play some of my Windows games on it. I had some experience with Wine many many years ago and it just didn't work well so I always dual booted my PC with Windows for gaming. To my surprise I was able to play AAA titles like RDR2 and Fallout without any issues or tinkering about.

I'm so happy that a company like Valve was able to put their shoulders under an initiative like this and actually stuck with it. Thank you, Valve!

This is so cool! I am genuinely happy that through this I barely ever had to boot up windows anymore when I still had my gaming PC. I wish we could have something similar on Mac. I tried GPTK and Whiskey before but a bunch of my steam games that flawlessly worked on Proton won’t even start and if they do there is a fair chance they random crash and have unacceptable performance.

Yes, I'm doing the same ... Steam on Linux all the way and Windows has been wiped. Couldn't be happier.

We have a mostly MacOS household and I couldn't agree more. Even for games that work on MacOS, compatibility and FPS drops are major problems. It's funny because Wine always had "MacOS support", but it seems second class compared to Linux

No reason why it wouldn't be second or even lower class. That walled garden OS is slightly better than Windows but Linux (mainly arch, debian based) is way ahead in every way

Proton is absolutely amazing and everything has worked for me, some older badly made games haven't had ideal performance but with latest Proton even some of them have improved massively. Going from ~120 to stable locked 500FPS as expected. Soon, if not yet, the games will run better with Proton on Linux than natively on Windows, at least with AMD.

Arch and Debian based systems aren't further than RPM based distros, whatever they use in SUSE or Nix(OS). Stay factual

The solution for Mac is called „have a separate Windows ITX machine on the shelf and Steam Remote Stream the games to your MacBook“.

Works reasonably well on a fast wifi.

Valve's work is the single killer contribution for Linux gaming (even though there are still many games not running under Proton which is why running Win on SteamDeck is a thing) but let's not forget to mention Wine on which it is based and which had been running regular (non-DirectX/Y/Z) win32 apps surprisingly/shockingly well for like 20 years.

For those using Windows games from GOG or other none-steam supports, I recommend Lutris, it requires a little more setup, but after the initial groking you can have a library as nice as Steam and with a lot more manual settings and support for other platforms or emulators.

A nice trick with Lutris is to create 2 initial prefixes for wine 32 and 64 bits and then to duplicate them in the library for each game. Only the lauch settings will be different but you get all games installed in 2 wine instances.

I recommend "Heroic Games Launcher" specially to run the free games provided by Epic. Also very easy to use.

Or Bottles instead of Lutris.

John Carmack saw this coming, more than 10 years ago:

> Improving Wine for Linux gaming seems like a better plan than lobbying individual game developers for native ports. Why the hate?

(https://x.com/ID_AA_Carmack/status/298628243630723074)

During my last vacation I played Fallout 4 on my Kubuntu laptop on max settings and I had zero crashes throughout the complete time. With a Bethesda game, on Linux.

What a time to be alive.

Let me instead mourn the death of native Linux gaming and the potential for Linux to be an independent platform in the future.

Don't get me wrong, Proton and DXVK are very useful tools for compatibility with legacy software but Valve really jumped the shark by positioning it as the default way to run Games on linux and alledgedly even actively discouraging native ports. We had Wine long before Proton (or Steam for Linux for that matter) and so what if it's a little bit more convenient now.

IMO peak Linux gaming was between the early Humble Bundles that required cross platform support for inclusion to the Kickstarter era where many campaigns felt the need to promise Linux versions to the Steam Machine hype that even got some AAA developers on board. Not seeing anything like that these days even with the Steam deck - seems most developers don't care to provide official support when gamers will buy the games to run with Proton anyway.

Proton did't just allow me to play on linux. It allowed me to uninstall windows.

Ty valve

Less reasons to run anything but Linux by the minute.

At least they are spending the money earned from illegal (underage) gambling on something good

Care to explain a bit more? Sensing a grudge here.

Its literally the most predatory microtransaction in the entire gaming sphere right now

https://en.wikipedia.org/wiki/Skin_gambling

They've cracked down on skin gambling as far as the media is concerned. But it was a real issue with CS:GO for awhile, since you could cash in and out through external services.

Being able to cash out might be a requirement for some legal definitions of gambling but its absence doesn't really make the situation much better. The problem is abusing the dopamine reward mechanisms in vulnerable individuals to get them to spens unreasonable amounts of money. The reward here doesn't have to be monetary at all for it to be an issue.

Sins of a Solar Empire 2 launched this past week and it runs on proton flawlessly on day 1.

This is what finally let me drop VFIO, a VM with GPU passed through for the occasional game.

It's notable this happened at all because Valve supported what was there all along. They didn't go make their own path. They, and the ecosystem, all benefit.

Truly thankful

I am very thankful for the Proton effort, both for the product itself, and for the fact that the upgrades and modifications make it back to the community. Kudos for Valve for doing it this way.

The sad thing is what Jonathan Blow said - every program will run the same on the same cpu anywhere. It's just the OS that gets in the way that we have to deal with.

How would you run multiple applications at the same time created by various developers without an OS or something that end up looking like a OS?

I don't think Blow or parent imply there's no need for an OS, but that the instructions the CPU executes eventually are the same no matter the OS that executed the binary.

Yeah but what's the relevance of this statement? You still need an OS at the end of the day, don't you?

I think the idea is that the convention of different executable formats each with their own loader should be abandoned in favour of something closer to the machine representation. Frankly I haven't done anything that low level to be able to say how much merit this has, but on a surface level it sounds reasonable.

See also https://justine.lol/ape.html

I was under the impression that APE encapsulates the full binaries for different OSes completely. I don't understand enough about it to be able to tell either way though.

I think you're taking that too literally, he's not advocating against the use of OSes.

What's so interesting to me is that Win10 refuses to run some of the early 2000s game at all. I have a soft spot for Far Cry 1, no matter how much tweaking I did on its Win10 installation it-just-won't-run. Run the game on Linux through Wine or Proton? Effortless.

I know it's huge technical debt but Microsoft is really doing poor job, or no job at all, on its backward compatibility.

Now, Gabe, put some headcount towards Half Life 3 please, cheers

Windows 10 initially had a great support for DirectX 8 apps, but with every big update (starting with Anniversary Update), they broke something. At this point, running old games without d3d8to9[0] or dgVoodoo2[1] is impossible.

[0] https://github.com/crosire/d3d8to9

[1] http://www.dege.freeweb.hu/dgVoodoo2/

Alyx is everything I hoped for, and more. I spent a fucking fortune on hardware to play a single VR game - extravagant, but worth it.

Proton is a blessing. Proton-GE is the natural evolution of the blessing. UMU Launcher is the steroids over Proton-GE.

Buy game on Steam, install, play. Same as on Windows, sometimes even less issues, especially with really old games. And with recent renaissance of demos one can easily try a game compatibility before purchase.

Not only games, but also some Windows applications could run smoothly on wine and proton. Especially those applications that use CUDA or DirectX for hardware acceleration. They cannot be used with wine previously.

I think Steam is one of the few cases where genious software internals engineering completely match business.

Happy Steam Deck owner. Have Nintendo Switch and PS5 in place though.

Rememebr some time ago someone made an effort to paackage windows games in appimages

I wonder what happened to that

Turns out the best gaming API on Linux is WinAPI. Who woulda thought!

See the famous "Win32 Is the Only Stable ABI on Linux" article https://blog.hiler.eu/win32-the-only-stable-abi/

https://news.ycombinator.com/item?id=32471624

> You know how on Windows, you can just download a zip with a program in it, unzip, double click, and the thing runs? Wouldn't it be nice if we could have that on Linux? There's no technical reason we can't, just standard practices that are hostile to this goal.

Oh Linux.

The inability to trivially target arbitrary versions of glibc is so frustrating. So much of Linux is stuck with terrible patterns from the 80s.

To more or less this what snap, AppImage, flatpak etc tries to solve.

And honestly it works. One part of Steam Deck's success that it was entirely built on an immutable flatpak based distro (Arch)

Arch does not normally use or make you use flatpaks, nor is it immutable. You describe SteamOS, which is based on Arch, but with changes to it.

This is more clearing up ambiguity for others reading than a correction, there's a decent chance you knew this already.

Fedora Silverblue is a distro which heavily uses flatpaks and is immutable out of the box. I believe this is what Bazzite, a community alternative to SteamOS, is based on.

Yes my bad for the wording. I also use Fedora Kinoite on my daily driver Thinkpad.

AFAIK Arch is neither flatpack-based nor immutable by default, that's just how valve configured it, or am I missing something since I've used it a few years ago ?

Still nicely done on valve's part.

> more or less this what snap, AppImage, flatpak etc tries to solve.

Yes. Seems really complicated though. It’s a whole lot of machinery and complexity to achieve what should be a very simple zip + double-click.

The Linux model is just inherently complex.

The linux model exposes it's complexity to the end user. Because of this the model is usually a lot simpler(the average user is expected to understand it). In the windows world the model is this huge unknowable beast with a facade over it. if you are fine with the facade this works great, but when things go wrong, it is much harder, a soul crushing wall of propriety internal interfaces. that is, it makes the easy things easier and the hard things harder.

Don't get me wrong microsoft is one of the good guys here, compared to apple they are a very programmer focused company and try very hard to provide the information needed to do things with the os. There are people who are very good with windows and understand it well, I just never liked all the hidden complexity and am much happier with linux and it's explicit complexity. I have to admit that statement is a bit of a lie, I actually think linux is far to complex and am happier with openbsd, which exposes and expects even more of the end user and is correspondingly much simpler.

maximizing the amount of complexity just because your current users are capable of dealing it and often no other benefits whatsoever (of course not always) just doesn’t seem like a great strategy.

Why would any designer intentionally maximize complexity? It's one of the core tenants of design to minimize complexity.

> The linux model exposes it's complexity to the end user. Because of this the model is usually a lot simpler(the average user is expected to understand it). In the windows world the model is this huge unknowable beast with a facade over it. if you are fine with the facade this works great, but when things go wrong, it is much harder, a soul crushing wall of propriety internal interfaces. that is, it makes the easy things easier and the hard things harder.

This has not been my experience in the slightest. Supporting “Linux” is radically harder, more complex, more error prone, and more miserable than supporting Windows. YMMV.

AppImage literally lets you double click the file to run it, you don't even unzip it first. It couldn't be simpler. If you're a power user who eschews desktop environments, then you chmod+x the file and run it.

It's the other two that complicate the matter in order to provide sandboxing. Thankfully you can simply choose not to use snap or flatpack. Really though, to characterize AppImage that way makes your comment sounds like the sort of cope windows users tell themselves to explain to themselves why they continue to tolerate Microsoft's abusive business practices.

> tell themselves to explain to themselves why they continue to tolerate Microsoft's abusive business practices.

The arrogance and smugness of some Linux users is probably the main reason for me. I just don’t want to be associated with that kind of people..

Generally unpolished UX and poor UI design (even by Windows standards…) is the second reason. Overall IMHO usually for consumer/desktop use cases all the tinkering you need to do on Linux to do many of the things that just work on Windows/macOS it’s just more trouble that it’s worth.. (unless you’re into masochism and there is nothing wrong with that).

>Generally unpolished UX and poor UI design (even by Windows standards…) is the second reason.

Sure Linux has plenty of it's own issues, but nowadays it's Windows that has degraded so much on the UX and UI department that I would dare say it is inferior to KDE and specially inferior to Gnome.

When you first boot into Windows 11 you realize that all programs sourced from microsoft itself are all based on inconsistent UX and UI. No program "skin" look alike, no button look similar. No modal dialog with a simple yes no question look "proper". Compare that to Windows 95 where everything was 1000x more consistent, it's like night and day. Even the stuff that uses the latest and greatest internal toolkit (that will surely be deprecated in a year) have that plain "flat" ui taken to the extreme that I at least find boring as hell.

And then you have to deal with two control panels to configure the system, a legacy they've been trying to move away since the win 8 days, with some dialogs that came up straight from windows 95 and windows 3.1 that still has the UX from those days... it's like living in an apartheid state, where each department at microsoft has to battle for their dear existence and fail at cooperating with each other.

And yes, I do feel smug when I realize a 3 Trillion dollar company fails at things that the open source community been nailing more and more every year. I guess linux is a cathartic experience nowadays. Can't get enough of it!

Good news, installing Linux doesn't teleport me into your living room. Complaining about other users is just another lame cope windows users use to excuse themselves (which wouldn't even be necessary if they were actually happy with their choice to use windows.)

It’s kind of weird that you’re so concerned about the happiness of Windows users…

To be honest I’m surprisingly happy* about Windows 11, after minimal amount of tweaking (less than I need on any Linux distro I tried to make it usable) I turned off most of the annoying stuff and I don’t really have much to complain about it + WSL

*the only thing I really want from an OS these days is to stay out of my way and require the minimal amount of pointless busywork from me (all the package management nonsense on Linux + permanent issues with Nvidia’s drivers).

The phrase "a power user who eschews desktop environments" was irritating. It brings to mind a "power gamer", still playing Colossal Cave Adventure.

It’s complicated from the developer side.

> explain to themselves why they continue to tolerate Microsoft's abusive business practices.

I can’t possibly eye roll hard enough.

> It’s complicated from the developer side.

Not really.

You can have your zip (well, conventional would be .tar.gz/.xz etc.) + double click if you want. You do it the same way you'd do it on Windows: Bundle your dependencies in the archive minus base OS components with stable ABIs.

You can compile against the oldest glibc you want to support and it will work on newer ones.

How do big binary linux applications deal with it? ldd'ing my chrome, I see it using Ubuntu's /lib/x86_64-linux-gnu/libc.so.6 and even a lot of GTK/Gnome stuff is in there, with Gnome famously providing no backward compatibility guarantees at all.

They don't. They either just ship half a distro with the app (flatpak, etc) or make a couple builds for different popular distros and call it a day. Linux's userspace ABI compatibility is a joke. Who would want binary software right? Just build it from source!

You can make portable binaries if you statically link everything and use MUSL as your libc but this brings in a host of other problems. Dynamic linking is impossible to do completely portable too as the dynamic linker is a part of the distro and the executable bakes an absolute path to it!

This is FUD. Portable Linux distribution has been figured out as early as Loki and it's not all that different from Windows distribution: ship your dependenciens with your application (which is not even close to half a distro if actually care to think about what your dependencies are) instead of just assuming that whatever is on your dev machine will also be on other systems. It's really not that hard.

It will be half a distro if they meant alpine.

It's not the best, only the cheapest to port to if you already have a Windows version - at the cost of additional bloat from the abstraction layers added.

sigh still can't play PUBG cos of the anti cheat, designed for windoze, afaik.

Some game devs are dropping native elf/linux support because of proton.

proton is then, really, hurting native elf/linux gaming.

Some game devs are aware of that and still try to provide clean elf/linux binaries.

Not to mention, it is a version mess, namely most of the time you get games to run-ish less than optimaly (if it runs at all) and you need some exact version of proton (wine/vkd3d) since forward and backward compatibility is super shabby, but you often end up with "if you want to run game UHEOTHC optimally, you need an external custom version GMX.ultra.74389.12 of protron which does include direct copy of closed source windows components (and you better be careful since it is illegal to redistribute many windows components...).

It would have been 1 billion times cheaper, and saner, to write audit tools for ELF64 binaries in order to drive game devs at crafting clean binaries (glibc ABI selection, dynamic loading of video game core interface libs, static linking).

I am sorry, but there is nothing to be proud of, actually quite the other way around. They are doing the "embrace and extend": does embrace elf/linux but does extend it with abomination like proton.

Shame on you, valve.

You want game developers to learn a bunch of new tools in an unfamiliar operating system to solve an artificial problem that said operating system itself created just so they can target the minuscule sliver of the PC gaming market that runs Linux but don't dual-boot for games? Get real. Nobody is going to do that for such a tiny number of customers.

However you give them a tool to take the same Windows build they ship to the rest of their customers and they get to ship for Linux too? Why would they say no?

We're going to need a whole extra order of magnitude on the Linux desktop market share before we'll ever see serious investment from the games industry at large for native Linux builds.

And what does it matter if you're running a Windows PE calling Win32? The system is still Linux. How different is it to rely on Proton then it is to rely on flatpak or another containerization technology to ship your app. You still have to bolt on a giant pile of complexity just to ship a zip file of game.exe and its libraries.

This the classic hypocrisy of the chicken and egg issue of the "PC market".

You need already a significant "PC market share" to get video games, but you will never get that "PC market share" because you don't have video games.

But in the first place, you will really not get that "PC market share" because people uses what is installed by default on the PC they buy. So you will need mass default installation of elf/linux on PC first of all. Everything else is pointless for "PC market share", only hardcore (omega hardcore) regulation can do anything here.

Regulation for video games: forced support of a set of as simple as possible exe file format and OS interfaces, very stable in time, namely not msft ones which are disgusting and grotesquely complex and massive (but msft would be forced to support them). And if regulation happens, it will happen most likely for other more important things than video games (for instance, critical online services of administrations or utilities).

In the end, we are reasonably left only with the good will of game devs.

And I think proton is not helping here, to say the least.

In principle, mass default installation of elf/linux on PC happens now, because Win11 comes with WSL. I don't know if a Linux game could be distributed with a Windows installer that makes use of WSL: I suppose Linux game devs aren't motivated to explore that.

At what point does my weekend project become a "critical online service"? At what point does my Pong clone become a game that needs regulating on how it's built?

Is it illegal for me to create a piece of art (i.e. a game) whose sole purpose is to demonstrate the fragility/absurdity of modern software abstractions by building it in some insane nesting of APIs?

I don't ask these to rhetorically imply that we don't need more regulation. I completely agree that there are online services that need way more regulation as they have become infrastructural.

These are all questions that we have to collectively (and not just programmers) discuss and decide where the lines are. It's not as simple as "force a set of simple as possible exe file format and OS interfaces."

> native elf/linux support because of proton.

Longterm for Linux isn’t it better for games to be built against stable and backwards compatible APIs?

> It would have been 1 billion times cheaper, and saner, to write audit tools for ELF64 binaries

Regardless if it wouldn’t have been cheaper for game developers to spend time doing that to get a handful of additional users. What incentives would they have to use these tools? Now they can release games on Linux almost for free.

You can select the glibc ABI but game devs won't need to do it since most of them use already made game engines, and major game engines are already native elf/linux/vulkan3D ready (unity, UE5, etc) and supposed to do that job.

>to drive game devs at crafting clean binaries

But you can't! That's the whole point. You might have some indie devs support linux out of good will, but anything larger won't chase a 2% niche of a market _no matter how little extra development_ it would take. You either get Linux support "for free" or not at all.

This is not true. There was a significant uptick in Linux releases before Proton killed that. This included even games from big publishers.

https://www.phoronix.com/news/Steam-Survey-August-2024

Most game devs use game engines already native elf/linux/vulkan3D ready (UE5, unity, etc).

This is the native app vs Electron argument all over again (except limited to proprietary AAA games). "Don't let perfect be the enemy of good" and all that.

Yes, a few game devs will drop native Linux support because building and maintaining just the Windows version and relying on Proton will be cheaper for them. Some number of them would have inevitably dropped native Linux support anyway. Take Rocket League for example. For most games, very few would have EVER had a native version for Linux. Source: the decades of PC gaming history prior to Proton.

Even with regular WINE being available, it's not like game devs were testing how their game ran in WINE. Currently, if your game doesn't work in Proton (and therefore the Steam Deck), you get an "Unsupported" icon on your store page. Getting that Deck Verified green checkmark is an actual economic incentive for game devs to support Linux in any way, even if that way is unsavory to some.

So, like Electron, the argument is less "Electron app vs native app" and more "Electron(/Proton) app vs no app at all".

Also, given that Proton isn't preventing developers from still offering a native Linux version, you really can't say that Valve/Proton are why those devs are dropping it. The developer is still choosing to drop native support.

> This is the native app vs Electron argument all over again (except limited to proprietary AAA games). "Don't let perfect be the enemy of good" and all that.

Agreed and in both cases I'd rather have quality than quantity.

> Yes, a few game devs will drop native Linux support because building and maintaining just the Windows version and relying on Proton will be cheaper for them.

There have been pretty much no native ports of big games since proton got pushed by Steam. All Linux game porting companies have either shuttered or switched focus to only Mac and mobile.

> For most games, very few would have EVER had a native version for Linux. Source: the decades of PC gaming history prior to Proton.

There were many more native releases in the period before Proton than now.

> Getting that Deck Verified green checkmark is an actual economic incentive for game devs to support Linux in any way

In a way where they can in the future publish changes that break the game on Linux without you being able to complain because what you bought is a Windows game.

> So, like Electron, the argument is less "Electron app vs native app" and more "Electron(/Proton) app vs no app at all".

Absurd. There were plenty of native programs released before either compatibility layer.

> Agreed and in both cases I'd rather have quality than quantity.

Of course, but if there's a game that I really would like to play, it doesn't matter how good some hypothetical version of it might be if nobody ever ports it. The quality of a nonexistent game(/port) is zero, no?

> There have been pretty much no native ports of big games since proton got pushed by Steam. All Linux game porting companies have either shuttered or switched focus to only Mac and mobile. > There were many more native releases in the period before Proton than now.

I suppose we are just in different circles of "big games". Before Proton, I can't recall the last time I saw a AAA game with Linux support. The occasional indie game had support, but that's still the case. World of Goo 2 just came out with native Linux support, for example. DRM free too, if you buy it direct from them.

> In a way where they can in the future publish changes that break the game on Linux without you being able to complain because what you bought is a Windows game.

This is the case regardless of native vs Proton. Just because a game has a native Linux version at some point is not a guarantee that an update won't break it nor that they won't just drop Linux as a platform outright.

> Absurd. There were plenty of native programs released before either compatibility layer.

And there are still about as many (in my experience) with both compatibility layers.

Nothing stops you from doing pacman -S wesnoth openmw endless-sky openttd openrct2 naev. Your definition of elf/linux binaries seems to be narrowly defined to refer to proprietary games developed by professional game studios, who always had the ability to cancel Linux support at the drop of a hat.

>It would have been 1 billion times cheaper, and saner, to write audit tools for ELF64 binaries in order to drive game devs at crafting clean binaries

Are you sure? The man hours spent on Proton and wine and DXVK are nowhere near enough to port even a dozen triple A games. Even if they do, nobody is going to rewrite their renderer from DirectX to Vulkan just to support Linux, they will still rely on DXVK as a dependency. I don't remember which game it was, but they had an entire dev team to build a renderer just for Linux and they scrapped it, because at some point the Windows and Linux renderer diverged too much and that was the end of Linux support.

I am often playing a bunch of games that were built with 'nw' and there is no Linux version for them and the chromium version they use often doesn't work, because Wine doesn't support CEF sandboxing. What I do is download a recent 'nw' release and just copy it into the folder and overwrite all the 'nw' related files and then it works. According to your comment, this is a great evil, since I am enabling these developers to not provide an explicit Linux release. Instead you're suggesting that they and I would save billions by not copying 'nw' into the folder.

Most devs use cross-platform game engines which have native elf/linux/vulkan3D baked in (unity, UE5, etc).

Many of those that do also use a bunch of various custom native plugins, middleware etc.

And if we look the most popular/largest games the proportion that use Unreal/Unity gets much lower.

Backwards compatibility is also a thing. If you ship a binary for Windows you can be pretty sure that it will work for 10-20+ years, that’s hardly the case for Linux (because its developers hate proprietary binary software due to irrational “reasons”).

This exact tactic got us the failure of the steam machine. Valve has learned that they can't just will native Linux games into existance with 0 marketshare.

The only way to successfully migrate a large amount of user to any new system is to make sure it can do the same things as the old and then build from there.

The failure if the Steam machines was Valve wanting others to create the hardware for them but still sell it cheaply enough to gain adoption. There were plenty of native linux ports and many more lined up, including from big publishers.

> The only way to successfully migrate a large amount of user to any new system is to make sure it can do the same things as the old and then build from there.

This is contrary to every single new gaming console in history. If backwards compatibility is offered it is always an add on, usually only released after the system has already gained adoption.

>There were plenty of native linux ports

to quote pcgamer "It may get updates, and may have 3,525 games, but PlayerUnknown’s Battlegrounds isn’t one of them, and neither are Nier: Automata, Black Desert Online, Prey, nor The Witcher 3—these are all current Steam top sellers." - https://web.archive.org/web/20240701183442/https://www.pcgam...

>This is contrary to every single new gaming console in history

pc and console might be in the same genre but otherwise there buying habits and consumer culture aren't comparable. windows pc gamer never had to worry about not being able to play old games after over two decades and counting. they are used to steep sales and 3rd party stores.

You're completely backwards. The priority is more games running on Linux. The least important thing is the dynamic linking config or the games. Do not sacrifice - by raising dev costs to support Linux - game support for dynamic linking config.

If devs that supported Linux before can do so now for less effort, that's a good thing. I don't care what ldd says.

Also, wrapping up the myriad dependencies a game can have under a centralized system like Proton is better than native apps. Much easier to centralize compat fixes.

Interesting take. I would be interested in reading more about these game devs dropping native linux support. Could you provide some examples?

blaze rush (if I recall the name right) for instance, the update dropped native elf/linux support.

If we are honnest with ourselves, we know that many games devs which did provide native elf/linux builds and which are not announcing elf/linux support anymore for their future games, it is because of proton.

And at the same time, you have some "games" currently being developed which are running state-of-the-art UE5 engine (for instance "vein") with a native elf/linux build. And we are talking super small teams.

I just want to play a few games, none of which have any remote chance of getting a Linux version. Proton gives me this with very minimal tweaking (for 1 game I need to download 1 dll), I couldn't care less which api they use.

When I stopped using Windoze for Linux around 2006, I gave up on playing games on pc, which was fine as I always have latest generation consoles around anyways. Eventually it got annoying and expensive to keep consoles around, and more so now with the push to buy games digitally that you don't really even own and will stop working one day.

Finally when Valve got involved to fix wine with Proton, it changed everything as a Linux user, and finally I don't need dedicated consoles to play what few games I still do. If a game is loaded with invasive DRM to NOT work under Proton/Linux, they're doing me a favor as I don't want to support them anyways.

Proton alone made Valve saints to myself and most all Linux users in giving gaming back to the Linux world, far more than scabs like Epic that criticize Valve for market dominance ever will.

Reply on news.ycombinator.com