Turns out the best gaming API on Linux is WinAPI. Who woulda thought!
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.
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."
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.
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.
Most game devs use game engines already native elf/linux/vulkan3D ready (UE5, unity, etc).
This is not true. There was a significant uptick in Linux releases before Proton killed that. This included even games from big publishers.
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”).
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.
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.
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.
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.
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.
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.
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
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
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.
I've played wow on my steam deck, in addition to Warcraft 3 remastered.
Blizz games are definitely doable now for the most part.
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.
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.
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.
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.
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 find heroic quite nice for gog and egs games.
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.
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
Didn't know lazydocker. Thanks! I learned something today.
There is also oxker! https://github.com/mrjackwills/oxker
Exa has been discontinued, probably worth switching to eza.
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'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.)
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.
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 gamesPretty 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).
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.
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!
Only if you consider HTML and JavaScript to be a good stable ABI for gaming on Windows.
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.
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.
I think you're taking that too literally, he's not advocating against the use of OSes.
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.
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
Yes, I'm doing the same ... Steam on Linux all the way and Windows has been wiped. Couldn't be happier.
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.
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
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.
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.
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.
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.
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.
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.
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.
Proton is a blessing. Proton-GE is the natural evolution of the blessing. UMU Launcher is the steroids over Proton-GE.
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.
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.
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?
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.
sigh still can't play PUBG cos of the anti cheat, designed for windoze, afaik.
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!
Sins of a Solar Empire 2 launched this past week and it runs on proton flawlessly on day 1.
Proton did't just allow me to play on linux. It allowed me to uninstall windows.
Ty valve
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.
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
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.
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.
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.
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.
Less reasons to run anything but Linux by the minute.
Rememebr some time ago someone made an effort to paackage windows games in appimages
I wonder what happened to that
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
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)
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.
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.
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).
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.)
The phrase "a power user who eschews desktop environments" was irritating. It brings to mind a "power gamer", still playing Colossal Cave Adventure.
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!
It’s complicated from the developer side.
I can’t possibly eye roll hard enough.
Not really.
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.
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.
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.
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.
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'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.