Hacker News Reader

Comment by AnIdiotOnTheNet | Hacker News Reader

> In some cases, running the Windows version inside Proton has actually worked out better for me than the native port

I, for one, am not surprised. Windows userland APIs are more stable, consistent, and well documented than their Linux equivalents.

View on HN

Keep in mind most "native" ports are just crappy, but official, wrappers that just do what proton does but worse. This is why you will see a lot of native ports perform worse, they weren't really native in the first place.

I'm gonna blow your mind: the word "native" doesn't actually mean anything in this context. The only thing that matters is official support from the developer, regardless of the technology used.

It's supposed to mean no system call translation but alas, you're right, it usually doesn't.

I was explaining how an official port could perform worse than an unofficial one, so yes "native" would absolutely mean something in this context. It's commonly understood that using the native system interfaces would usually be faster than using a compatibility layer.

> The only thing that matters is official support from the developer, regardless of the technology used.

The only thing that matters for what? I'm not sure what point you are trying to make.

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.

I don't believe that is correct.

> (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.

https://www.youtube.com/watch?v=h-XnlUMfkjM

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.

[1]: https://cpu.userbenchmark.com/Compare/Intel-Pentium-G3258-vs...

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.

I see now. I stand corrected.

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.

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.

[1] winmm dates to the Windows 3.x days!

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.

What dialog is that?

Perhaps this one?

https://www.dell.com/support/article/en-us/sln286269/how-to-...

About a third of the way down.

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?

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.

I hope that I never see the "Have disk" button again. The Linux way of distributing hardware drivers is so much easier.

As for usage, linux on the desktop is between .5% and 2% market share. And there reason to suspect that Linux usage is undercounted.

https://www.netmarketshare.com/operating-system-market-share...

https://store.steampowered.com/hwsurvey/

https://www.statista.com/statistics/268237/global-market-sha...

https://hostingtribunal.com/blog/operating-systems-market-sh...

> The Linux way of distributing hardware drivers is so much easier.

You mean having to recompile them whenever there's a new kernel because the developers consider a stable driver ABI to be abhorrent?

I don't think I've ever compiled a driver. So no, I don't think that's what they meant.

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.

For software like games, all that pain is abstracted away by SDL. No need to deal with userspace libraries!

And, of course, the syscall layer is stable in Linux, so no issues there either.

However, companies claim Linux is still a pain for other reasons, so I guess it is mostly about testing/support cost and perhaps OpenGL driver issues?

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.

Reply on news.ycombinator.com