The implication from the comment was that Wine is better at running old Windows games than Windows itself. I’m not sure where this Linux vs. Windows comparison is coming from.
No, you mis-read. chaorace said that Windows EXEs running in Proton gives them better results than running the Linux binary that the game developer ships ("native"). AnIdiotOnTheNet stated that Windows APIs are more stable and better documented than Linux APIs.
As a long-time Linux dev (see my profile), I have also found this to be true. Linux userland APIs are unstable and change all the time. Some transitions that come to mind that have affected me personally: ALSA->pulse; libudev->libudev2->systemd; gstreamer 0.10->1.0. All of those changes required modifications to my software, and the backwards-compat tools that are provided are buggy and insufficient. Meanwhile, you can still write and run winmm[1] applications on Windows 10, and they will work in almost all cases. It's simply the case that the win32 API is more stable than Linux userland APIs, so it's entirely plausible that games will run better in Wine, which shares that stable ABI, than they will on Linux, especially as time goes on and Linux userland shifts yet again.
The audio subsystem changes definitely could have been done better. Ideally /dev/dsp should have been extended like has been done on the BSDs instead of inventing completely new interfaces. That said, doesn't libasound still work with pulse?
gstreamer on the other hand is something you can just as easily ship yourself. I wouldn't consider that a Linux userland API as much as a random library that is present on many Linux system just like some crap you'd find in system32.
I'm less familiar about the API/ABI changes in the libudev transition - is there anything there that broke API compatibility.
The "lower level" userland libraries (glibc, libGL, libX11) tend to be pretty good at maintaining backwards compat. Well, except for Mesa pulling in the C++ standard library which can be a real problem when older games also dynamically link (incompatible) versions.
I've been suspicious of user-led development (e.g. open source), expecially Linux. Its popular to put in new features; less so to test, endure backward compatibility, control user experience. So it doesn't get done (much) in Linux.
My cohort have a phrase they attribute to me: Linux is not ready until they get the 'Have Disk' dialog.
Eh, I don't agree. Linux has been "ready" for my usecase for more than a decade. There's pros and cons to each certainly, but I find Linux much more pleasant to use than Windows, and I like actually being in control of and able to modify the software I run. Until I can do that, Windows is not ready for me :)
Right. But the point is the vast, vast (non-HNer) use case is not in favor of Linux. For every 1 Linux-on-the-desktop person, there are what, 1M others?
Only because the disto does it for you. If they mean because the driver is distributed from a centralized repository over the internet... that's how it works in Windows too, only Windows also has the option to use alternate media and a stable enough driver ABI to have that make some kind of sense.
I don't know if API stability is a barrier to adoption or not, but I was just explaining my experience with both platforms. For me, I don't much care how many people use Linux; I just want to use my computer how I like to, and Linux suits my needs best.
> (Dead Cells, for example. The native port crashes the Steam overlay and lacks Steam Controller support, but running the Windows version in Proton is seamless)
Suggests the comment is about running the Windows version under Proton being a better experience than running the native Linux version.
Both are correct. Some native ports run better under Proton because the port sucks, but I recently saw a video where they compared Doom Eternal with Proton vs running native on Windows, and the Proton version ran better than the Windows version running natively.
It would be interesting to have some analysis digging into potential causes for this result. As someone who was recently surprised at how much impact a CPU upgrade (G3258 -> 4570 on the same LGA 1150 motherboard [1]) had on overall performance even in older indie titles where I wouldn't have expected it to matter much, I would be curious to look at what background services are running, what their cpu/memory footprint is, and how well the OS handles scheduling them.
Even without the obvious pigs like virus scanner, printer utility, launchers for other storefronts, various chrome-embeds like Slack and Spotify, I wouldn't be surprised if the Linux desktop does a better job of this.
The most common theory is that it's the Denuvo anti-piracy software. It's known to cause performance drops on Windows, and it often has to be bypassed or disabled in Linux games.
Ah, the parent comment is actually correct here. Dead Cells is a modern release with a released Linux port. Unfortunately, it isn't interacting correctly with the Steam overlay API and the issues haven't been fixed for months. Running the Windows version via Proton, ironically, is a more stable experience for my use-case.
