Earlier quoted context omitted.
Why do you care? You really need to get over the "Linus said something bad about my mother 20 years ago" or whatever your issue is. It's just weird at this point.
You are the ones that need to get over the fact that these are Windows games, not Linux.
Valve is paying open-source developers to work on Proton, Mesa, and more
71–80 of 288 posts
Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#72Thanks to Valve Linux is single OS on my home computer. Most of the games from my medium sized Steam library are working, and few that does not work today, will probably be fixed in the future. Need to mention that I do not play new AAA titles or multiplayer games, but I enjoy older games, and some of those are broken on modern versions of Windows.
I had good luck even with newer titles. Right now I'm playing Red Dead Redemption 2, and it works like a charm, out of the box. Same flow as in Windows, even.
Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#73Thanks to Valve Linux is single OS on my home computer. Most of the games from my medium sized Steam library are working, and few that does not work today, will probably be fixed in the future. Need to mention that I do not play new AAA titles or multiplayer games, but I enjoy older games, and some of those are broken on modern versions of Windows.
Not really a gamer. Cyberpunk is probably my high water mark at 90 hours. It's so nice to not to have to make major concessions to run Linux.
Valve you have earned a customer with me.
Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#74Earlier quoted context omitted.
Why do you care? You really need to get over the "Linus said something bad about my mother 20 years ago" or whatever your issue is. It's just weird at this point.
You are the ones that need to get over the fact that these are Windows games, not Linux.
Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#75Earlier quoted context omitted.
Either static or dynamic is fine, package management has to be solved at another layer a la Nix.
Nix is effectively transforming dynamic binaries to static ones. Might as well skip the step, stop pretending that drive space is expensive, and link everything statically.
And if you really want a single redistributable binary, any existing package can easily be bundled into one without recompiling it.
Traditional static linking is strictly worse.
Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#76Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#77Earlier quoted context omitted.
Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback of these “huge” binaries? Wasn’t the reason to separate binaries and libraries in the first place to conserve disk space? They are then clearly versioned to signal that you can’t expect just any version of the library to work with the program you wrote. The t…
Shared libraries can reduce load time as they might already be in page cache. There’s also potential for a small impact in reduced instruction cache misses. On the other side, link time optimization on static libraries allows deletion of unused functions and more aggressive inlining, so you might get that performance back and more.
Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#78Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#79Earlier quoted context omitted.
That's interesting. I'm no expert on the Steam Deck, but I would have expected it to work. Do you have any more details about the problem?
Valve is using the 'wrong' AMD gpu driver.
Re: Valve is paying open-source developers to work on Proton, Mesa, and more
#80Earlier quoted context omitted.
Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback of these “huge” binaries? Wasn’t the reason to separate binaries and libraries in the first place to conserve disk space? They are then clearly versioned to signal that you can’t expect just any version of the library to work with the program you wrote. The t…
> what is the actual drawback of these “huge” binaries? The problem isn’t size. The problem is that with static linking it gets significantly more difficult to patch security vulnerabilities, because with dynamic linking, the vuln is gone once the underlying library is updated, however this wouldn’t happen with static linking.