Live data from Hacker News

Valve is paying open-source developers to work on Proton, Mesa, and more

old.reddit.com

71–80 of 288 posts

Re: Valve is paying open-source developers to work on Proton, Mesa, and more

#71
post #57

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.

Nobody. Cares.

Re: Valve is paying open-source developers to work on Proton, Mesa, and more

#72
post #63

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

[deleted]

Re: Valve is paying open-source developers to work on Proton, Mesa, and more

#73
post #63

Thanks 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 played all of cyberpunk shortly after release on a 3950x and 3060ti on Steam+Proton+Ubuntu with very little problems. It did get very laggy in busy areas on occasion, but that was the exception not the rule. Obviously newer hardware helped, but it seemed Valve hurt the gaming experience less than CD Project Red did!

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

#74
post #57

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.

What does 'getting over' even mean here? These games are coded to APIs provided by Windows; but there's nothing stopping another platform from implementing these same APIs and happily running these games on not-Windows.

Re: Valve is paying open-source developers to work on Proton, Mesa, and more

#75
post #50

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

No. The Nix approach lets you retain the reuse, and it can be extended to allow quick, unified security patching as well (which has been done already in the Guix project).

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

#77
post #44

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

People say this but every test case I've seen has proven otherwise. Static binaries load much faster. Maybe it depends on the size of the libraries involved an the quality of the OS' dynamic linking machinery (supposedly OSX has better runtime dynamic linking startup times than linux), but at the very least it is conditional, not a pure win.

Re: Valve is paying open-source developers to work on Proton, Mesa, and more

#79
post #65

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

That's not enough information for me to understand what's wrong, but I suppose maybe I should find a Steam Deck and try things out myself. If you want to follow up privately, my email is in my profile.

Re: Valve is paying open-source developers to work on Proton, Mesa, and more

#80
post #44

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

You need to be regularly updating the higher level packages anyway though, as they might contain vulnerabilities that are not due to underlying libraries. At which point, we might as well update them for library issues too.
Post reply on HN