Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

phoronix.com

Post reply on HN
Print view View original

381–390 of 407 posts

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#381

Post by opello »

112233 wrote: post #342
opello wrote: post #254

Earlier quoted context omitted.

> Each of these characters is replaced by the - character to denote that a permission is absent in the ACL entry. Wouldn't the o::--- default ACL, like mode o-rwx, deny others access in the way you're describing?

See 6.2.1 of RFC8881, where NFSv4 ACLs are described. They are quite similar to Windows ACLs. Here is kernel dev telling they are against adding NFSv4 ACL implementation. The relevant RichAcls patch never got merged: https://lkml.org/lkml/2016/3/15/52

https://www.rfc-editor.org/rfc/rfc8881#section-6.2.1

I see what I misunderstood, even in the presence of an ALLOW entry, a DENY entry would prohibit access. I am familiar with that on the Windows side but haven't really dug into Linux ACLs. The ACCESS CHECK ALGORITHM[1] section of the acl(5) man page was pretty clear, I think.

[1] https://man7.org/linux/man-pages/man5/acl.5.html#ACCESS_CHEC...

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#382

Post by trinsic2 »

graynk wrote: post #361
trinsic2 wrote: post #340

Earlier quoted context omitted.

If you say so. Sorry not see any of this. Valve is a good company and there reputation has been developed over the years as such.

this is just willingly turning a blind eye. it's not about the reputation or being a "good company", it's about the facts of what they do.

I'm choosing not to place the blame on them as I don't see it as something they can control. And I trust Valve to do the right thing over most any large game studio out there. The history of reputation and actions matter. I think you want to to try and skew the narrative based on you own particular bias. The situation is much bigger than what you are making it out to be.

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#383

Post by ndsipa_pomu »

asdff wrote: post #293
Fiveplus wrote: post #17

Valve is practically singlehandedly dragging the Linux ecosystem forward in areas that nobody else wanted to touch. They needed Windows games to run on Linux so we got massive Proton/Wine advancements. They needed better display output for the deck and we got HDR and VRR support in wayland. They also needed smoother frame pacing and we got a scheduler that Zuck is now using to run data centers. Its funny to think tha…

I wish valve didn't abandon mac as a platform, honestly. As nice as these improvements are for linux and deck users they have effectively abandoned their mac ports as they never updated them to 64 bit like the linux and windows builds, so they can't run on new macs at all. You can coax them into running with wine on mac but it is a very tricky experience. My kegworks wine wrapper for tf2 is currently broken as of las…

It was likely about control. Valve saw that Microsoft was becoming more controlling about the Windows platform and that's what pushed them towards developing SteamOS on Linux as that means that Valve can put resources into fixing anything that they want to. The Apple platform is also under control of a single entity, so it doesn't make too much sense for Valve to care about that (as well as Apple not being known as a gaming platform).

What you should do is just buy a SteamDeck for gaming.

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#384

Post by tayo42 »

jraph wrote: post #230
tayo42 wrote: post #211

Earlier quoted context omitted.

That wasn't what I was thinking about. There's a phrase for it using active and back up partitions but I can't find what it's called

A/B updates?

Yeah that's what I was thinking of. Looks like it's also called seamless which I think the phrase I couldn't come up with was

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#385

Post by abustamam »

ffsm8 wrote: post #325
abustamam wrote: post #323

Earlier quoted context omitted.

Yes please! Stop making me download 100+gb patches!

The large file sizes are not because of bloat per-se... It's a technique which supposedly helped at one point in time to reduce loading times, helldiver's being the most note-able example of removing this "optimization". However, this is by design - specifically as an optimization. Can't really be calling that boat in the parents context of inefficient resource usage

Interesting, today I learned!

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#386

Post by thunderfork »

thanksgiving wrote: post #331
ffsm8 wrote: post #325

Earlier quoted context omitted.

The large file sizes are not because of bloat per-se... It's a technique which supposedly helped at one point in time to reduce loading times, helldiver's being the most note-able example of removing this "optimization". However, this is by design - specifically as an optimization. Can't really be calling that boat in the parents context of inefficient resource usage

We aren't talking about the initial downloads though. We are talking about updates. I am like 80% sure you should be able to send what changed without sending the whole game as if you were downloading it for the first time.

Generally "small patches" and "well-compressed assets" are on either end of a trade-off spectrum.

More compression means large change amplification and less delta-friendly changes.

More delta-friendly asset storage means storing assets in smaller units with less compression potential.

In theory, you could have the devs ship unpacked assets, then make the Steam client be responsible for packing after install, unpacking pre-patch, and then repacking game assets post-patch, but this basically gets you the worst of all worlds in terms of actual wall clock time to patch, and it'd be heavily constraining for developers.

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#387

Post by WackyFighter »

cosmic_cheese wrote: post #269
WackyFighter wrote: post #266

Earlier quoted context omitted.

That isn't it. Generally whatever the majority of users tend to use that where the majority of focus goes. The vast majority of people that were using Linux on the desktop before 2015 were either hobbyists, developers or people that didn't want to run proprietary software for whatever reason. These people generally didn't care about a lot of fancy tech mentioned. So this stuff didn't get fixed.

There’s some truth to that, but a lot of (maybe most) Linux desktop users are on laptops and yet there are many aspects of the Linux laptop experience that skew poor. I think the bigger problem is that commercial use cases suck much of the air out of the room, leaving little for end user desktop use cases.

What laptops though? Most people end up getting either Thinkpads, old Dell business laptop or something like a framework.

Most people learn that using some crap top will leave you with stuff on the laptop not working e.g. volume buttons, wifi buttons etc.

All of these just work with Linux.

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#388

Post by SkiFire13 »

baobun wrote: post #351
SkiFire13 wrote: post #344

Earlier quoted context omitted.

Do you have some resource for people outside this field to understand what it's about?

It goes all the way back to tapes, was still important for CDs, and still thought relevant for HDDs. Basically you can get much better read performance if you can read everything sequentially and you want to avoid random access at all costs. So you can basically "hydrate" the loading patterns for each state, storing the bytes in order as they're loaded from the game. The only point it makes things slower is once, on…

So this basically leads to duplicating data for each state it's needed in? If that's the case I wonder why this isn't solvable by compressing the update download data (potentially with the knowledge of the data already installed, in case the update really only reshuffles it around)

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#389

Post by Eggpants »

7bit wrote: post #56
asveikau wrote: post #38

Earlier quoted context omitted.

I was at Microsoft during the Windows 8 cycle. I remember hearing about a kernel feature I found interesting. Then I found linux had it for a few years at the time. I think the reality is that Linux is ahead on a lot of kernel stuff. More experimentation is happening.

And behind on a lot of stuff. The Microsoft's ACLs are nothing short of one of the best designed permission systems there are. On the surface, they are as simple as Linux UOG/rwx stuff if you want it to be, but you can really, REALLY dive into the technology and apply super specific permissions.

And yet, it requires kernel extension anti-cheat to stop a game mod from reading and writing memory locations in a running process. It’s a toy operating system if it can’t even prevent that. It’s why corporate machines are so locked down. Then there is the fact video drivers run in ring 0 and are allowed to phone home… but hey you can prevent notepad++ from running FTW.

Re: Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers

#390

Post by nextaccountic »

bigstrat2003 wrote: post #330
nextaccountic wrote: post #229

Earlier quoted context omitted.

That's why the anti-GPL push is so harmful. Specially in the Rust ecosystem

There is absolutely nothing harmful about permissive licenses. Let's say that Wine was under the MIT license, and Valve started publishing a proprietary fork. The original is still there! Nobody is harmed by some proprietary fork existing, because nothing was taken away from them.

It's harmful to the ecosystem, because the reason so many Linux drivers, and Wine contributions, and a lot of other things are free software today is because of the GPL
Post reply on HN