Valve is paying open-source developers to work on Proton, Mesa, and more • Hacker News Board

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

#101

Post by pxc » Sat, Dec 17, 2022, 6:17 PM UTC

butz wrote: 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.

Single player gaming, indie gaming, and retro gaming are all gaming niches where I'd say that a smooth Linux experience with widespread support is 'already there'.

It's really only the (crucial) segment of big, trendy multiplayer titles where support is still really hit-and-miss. If gaming is essential to your social network, Linux may not be ready for you to entirely switch over.

But if you're someone whose social hobbies lie elsewhere who enjoys solo gaming, there are way more excellent Linux games ready for you to enjoy than there is time for you to play them.

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

#102

Post by heywhatupboys » Sat, Dec 17, 2022, 6:17 PM UTC

smoldesu wrote: post #92

ParetoOptimal wrote: post #83

Earlier quoted context omitted.

I personally dislike cloudflare for not dropping KF, not sure if that's a majority opinion.

Yeah, even though I'd agree that KF is detestable, the way Cloudflare cracked under pressure was a public embarrassment. It's hard to give them the benefit of the doubt these days.

> Yeah, even though I'd agree that KF is detestable

I am very curious about this tbh. Has anyone here gone to that site? I read that they just report publicly available info that people have voluenteered online. While I understand that doxxing is terrible and so is targeted harassment, are they that much worse than the daily mail or any other gossip magazine?

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

#103

Post by Gordonjcp » Sat, Dec 17, 2022, 6:18 PM UTC

amelius wrote: post #37

candiddevmike wrote: post #34

Earlier quoted context omitted.

Id rather have static binaries than a flatpak/snap for "universal distribution", personally.

Snap really sucks because it forces you to have a /home/user/snap folder on the same filesystem as /. If you don't have that (e.g. home folder symlinked to another filesystem), then snap starts breaking in very weird ways. https://forum.snapcraft.io/t/limitations-in-snapd/9718 This actually means that at some point I will have to move away from Ubuntu.

Why don't you just mount your big disk on /home, like we used to do in the olden days?

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

#104

Post by freedomben » Sat, Dec 17, 2022, 6:22 PM UTC

bsurmanski wrote: post #12

yellow_lead wrote: post #6

Earlier quoted context omitted.

I was thinking of doing this - how do you like it? How's coding on it?

Not op, but I bought one. It's essentially a Linux laptop with a control interface built in. For emulators and steam games, it's really nice to have an option to play on the tv (with the dock). I don't see it being an especially nice coding experience; you'd need an external keyboard, mouse, and monitor. And without a dock, all it has is a single USBC port. Though it has a full KDE desktop, so it should be feasible.

yeah without a keyboard it sucks. it's like trying to code via SMS lol.

But the dockability makes it pretty damn awesome. you can code in first class style by docking it with a monitor and keyboard, and then when you leave you can take it with you and get a great portable game player or movie watcher or web browser with good battery life. the built in screen is pretty good. I was impressed

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

#105

Post by stusmall » Sat, Dec 17, 2022, 6:23 PM UTC

jimbob45 wrote: post #33

Kiro wrote: post #16

Is Valve the only company in the world that is not universally hated by the HN and reddit crowd?

JetBrains maybe?

Every now and then I see some brain-dead hand-wringing about them being an agent of the Russian state. I saw a lot soon after the war started. The other time I saw a lot was right after that hack that involved TeamCity.

HN and Reddit aren't hive minds and both hold a lot of diverse opinions. Nothing is universally loved on either. Today's society can longer agree on agree on fundamentals like if the earth is round or if democracy is good. So it isn't a huge surprise that not everyone has accepted The Infallible Glory that is the Jetbrains product roster (A little joking in that last bit.... but just a little. All praise CLion)

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

#106

Post by freedomben » Sat, Dec 17, 2022, 6:24 PM UTC

slavik81 wrote: post #79

cowmix wrote: post #65

Earlier quoted context omitted.

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.

AMD does have two different drivers (which I find maddening). I bought a monstrous GPU to use for hashcat, but the open source/built-in drivers don't support the openCL that hashcat (and crypto mining) need. The Pro driver doesn't get updated fast enough to work on Fedora, which is also a travesty for me. I really wish that weren't the case.

I can't speak for steam deck though, just my experience on a self build.

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

#107

Post by kaba0 » Sat, Dec 17, 2022, 6:30 PM UTC

ParetoOptimal wrote: post #81

AmalgatedAmoeba wrote: post #61

Earlier quoted context omitted.

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.

Huh, never heard it put this way. I guess it's true though. Anyone disagree?

What about completely optional dependencies which might get loaded at runtime based on some dynamic criteria? Dynamic libs are not primarily for space saving. Also, there are thousands of other packaging problems not solved by static binaries, so yes, I do disagree with grandparent commenter :D

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

#108

Post by pxc » Sat, Dec 17, 2022, 6:30 PM UTC

gpderetta wrote: post #99

jetbalsa wrote: post #95

Earlier quoted context omitted.

the DXVK project out of all this has been a godsend for the older DX11, DX9 games on modern hardware, its being used to increase FPS on older titles on windows

Isn't Intel even shipping DXVK on window for their shiny new GPUs as it is often works better than their DX9 drivers?

Yep. Their driver switches which DX9 implementation based on which game is running, according to which they've observed has better performance.

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

#109

Post by amelius » Sat, Dec 17, 2022, 6:31 PM UTC

Gordonjcp wrote: post #103

amelius wrote: post #37

Earlier quoted context omitted.

Snap really sucks because it forces you to have a /home/user/snap folder on the same filesystem as /. If you don't have that (e.g. home folder symlinked to another filesystem), then snap starts breaking in very weird ways. https://forum.snapcraft.io/t/limitations-in-snapd/9718 This actually means that at some point I will have to move away from Ubuntu.

Why don't you just mount your big disk on /home, like we used to do in the olden days?

Because I suspect that snap uses both /home/user/snap and /var/.../snap, and needs them to be on the same disk (to allow hardlinking, I suppose).

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

#110

Post by wccrawford » Sat, Dec 17, 2022, 6:32 PM UTC

nicoburns wrote: post #80

sgjohnson wrote: post #48

Earlier quoted context omitted.

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

Many games rarely update, though. They put out the original version, and then maybe a few patches to fix game-breaking bugs, and then that's how they exist from then on. If you're expecting them to update to address vulnerabilities, you're going to be very disappointed.

That said, if the library changes the API or functionality at all, dynamic linking is going to break the game, and that's not good either. So gamedevs are going to opt for static linking and call it a day rather than deal with support requests.