129
Linux gaming is getting faster because Windows APIs are becoming Linux kernel features
(www.xda-developers.com)
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
Except this is a scheduler issue from my understanding.
You can make the argument to put everything into user space, but it's a performance issue.
One of the growing huge applications of linux these days is gaming, which depends hugely on performance, and almost every gamer out there is likely using wine (generally, without even realising it).
It's not a scheduler issue, it's a windows apps do thread synchronization differently to linux apps. Additionally fsync in the vast majority of use cases works just fine, the article notes most performance comparisons are against vanilla wine synchronization, i.e. without fsync or even esync. Regardless I still don't think the kernel should be emulating windows scheduling behavior.
Don't compile it in then...
It's literally that simple.. but yeah, it is sync, you are correct
We could debate the advantage and disadvantages of a lot of things in the main kernel. There's so much stuff in there that only benefits certain limited applications, and we could make the argument for userspace for almost everything, including a lot of filesystem drivers
Like it or not, wine and gaming is probably the biggest avenue where Linux is winning on the desktop at the moment (especially thanks to steam). We shouldn't ignore it
I already don't compile it in...I'm just stating my opinion. I don't think that should be something in the kernel. I complain, but I also do something about it.
Yeah. That's fair enough.
Both sides have merit. I get both angles tbh
Also, I grew up trying games like Unreal tournament on Linux.
At the time, I thought wine was stupid and would never catch up.
However we're at the point that a lot of games already run better on Linux than windows even via wine.. There are even more opportunities here in the future