Earlier quoted context omitted.
People always say this to shit on glibc meanwhile those guys bend over backwards to provide strong API compatibilities. It rubs me off the wrong way. What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version. Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application w…
No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.
Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
81–90 of 512 posts
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#82Reading these posts always make me feel like an imposter. People are dealing with such low level things, while i'm outta here building simple CRUDs.
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#83And then it never was more than half…
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#84Earlier quoted context omitted.
Those benchmark numbers are slightly misleading, as they are a comparison of Wine+ntsync against Wine+nothing. There has been a somewhat fast "fsync" library built around Linux's futex and the gains over Wine+fsync are modest (just a few % in most cases). That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests. (And it case it's not clear, ntsync is https://docs.kernel.org/…
> There has been a somewhat fast "fsync" library built around Linux's futex The article actually goes into that in quite a bit of detail about that.
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#85Earlier quoted context omitted.
The common gaming-focused Wine/Proton builds can also use esync (eventfd-based synchronization). IIRC, it doesn't need a patched kernel. The point being that these massive speed gains will probably not be seen by most people as you suggest, because most Linux gamers already have access to either esync or fsync.
Maybe you are right about esync but anyway I would also gather a lot of people don’t have that either. At least personally I don’t bother with custom proton builds or whatever so if Valve didn’t enable that on their build then I don’t have it.
The Proton build is Valve's build. It supports both fsync and esync, the latter of which does not require a kernel patch. If you're gaming on Linux with Steam, you're probably already using it.
https://github.com/ValveSoftware/Proton/?tab=readme-ov-file#...
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#86Reading these posts always make me feel like an imposter. People are dealing with such low level things, while i'm outta here building simple CRUDs.
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#87Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#88Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#89Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#90Reading these posts always make me feel like an imposter. People are dealing with such low level things, while i'm outta here building simple CRUDs.
The grass is always greener on the other side - many low-level programmers feel like an imposter when it comes to high-level systems such as CRUD apps.
He will talk about OS events, or any low level concept and it makes me feel like I don’t know anything, but he acts like I’m a genius if I talk about JavaScript Runtimes, browser engines, anything frontend.
It’s cool he teaches me new things, I teach him some