Linux 5.16 Released With Many Intel & AMD Additions, Memory Folios, AMX, FUTEX2

[qarium]

The funniest thing about open source in general and Linux in particular is that it's so much more popular in Russia than anywhere else.
Consider the opennet.ru website where the news piece for this kernel release has already seen 166 comments vs just 20 here despite Phoronix being an international website for the entire world.
And this doesn't include LOR where the news is yet to be published (they normally quickly follow opennet.ru but not today for some reasons).

maybe we have some new marketshare numbers but last time i checked it germany had the highest marketshare in linux compared to windows and macos...

so please show me marketshare numbers that proof the point that russia is at NR1 place in opensource/linux usage...

[Vistaus]

Wonderful, this is an amazing release!
Too bad Canonical will find again some excuse to not use it for the next Ubuntu version.

5.16 in 22.04 sure would be great, but 5.17 would've been more great as it also contains a lot of network improvements. Not only end-users, but also companies running 22.04 LTS would love that.

[birdie]

So they beat OpenMandriva this time? (normally, we have that one person on Phoronix commenting that package xyz has been updated in OM 5 minutes after it's been released)

Nothing beats Fedora.

[Vistaus]

and them add 5.16 final

https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.16/

So they beat OpenMandriva this time? (normally, we have that one person on Phoronix commenting that package xyz has been updated in OM 5 minutes after it's been released)

[birdie]

The funniest thing about open source in general and Linux in particular is that it's so much more popular in Russia than anywhere else.

Consider the opennet.ru website where the news piece for this kernel release has already seen 166 comments vs just 20 here despite Phoronix being an international website for the entire world.

And this doesn't include LOR where the news is yet to be published (they normally quickly follow opennet.ru but not today for some reasons).

[JPFSanders]

Apparently Valve and Collabora have been consistently funneling their efforts towards implementing and upstreaming futex_waitv for some time now, and apparently they know what they're doing since, due to their previous efforts, Wine has already transitioned from a mostly useless theoretical concept to a workable solution that's bound to change the Linux ecosystem; which means that apparently futex_waitv is already a good solution (predictable, since it's an evolution of the fsync concept and fsync is already good for many games, despite what that Wine dev was trying to say).

So apparently we should maybe start treating Valve and Collabora as the authorities-that-be on Wine development in place of the original Wine team, because the former apparently care about evolving Wine into a proper real-world solution that solves real-world use cases (even if they only care due to their desire to make it into a profitable product) while the latter are apparently growing more and more comparable to the GNU purists, systemd haters and the various other anachronistic entities that plague Linux these days. If we relied on them and their concepts of what's worthy to be merged and what isn't, we'd still be "playing" DX11 games in single digit framerates. Bah.

Please, do note that the bitter sarcasm is aimed not at you but at the Wine devs. Back when I told you (don't know if you remember our discussion) that I wasn't expecting futex_waitv support to be merged in Wine before at least both kernel 5.16 and Wine 7.0 were out of the door, I certainly wasn't expecting for it to be blocked from being merged indefinitely by the Wine devs due to Reasons™ - i.e. just as they've done with DXVK.

Don't you think you're being a bit unfair? Codeweavers is not stopping anybody from using Wine in any way shape or form. Including patching in whatever people would like to patch.

Why do you think Valve's or Collabora's goals have to align exactly with Codeweavers?

Wine is where it is and proton was made possible due to Codeweavers and the Wine developers decades long work.

Wine is perfect? no, so what?, as I've said nothing is stopping anybody from patching Wine to support anything, what one can't expect is developers submitting to your wimps.

I haven't read much about the futex_waitv situation, just posts here in phoronix, so won't comment on details.

Regarding DXVK is a very narrow and specific solution to a specific problem, even its author has said multiple times it doesn't cover all what Wine DirectX implementation covers, it only cares about making games fast and that it is a mess he would like to not have to maintain. And like above, can you point to the Wine developers trying to prevent or stop people using DXVK?

Why the bitter sarcasm? Why the bullshit about GNU purists? What are you on about?

If this is trolling I give you a 4 out of 10.

[cytomax55]

I appreciate what he was saying...
I too was the same way for a year or so running kubuntu ..
My simple point is if you're worried about what kernel your system is going to be running you should probably be running a different distro....
Ubuntu is about stability and reliability And you'll go crazy always wanting the latest kernel or worse yet you'll take a stable Ubuntu and start trying to put the newer kernels into it....
Maybe it's normal progression for Linux users cuz that's what I went through and eventually I landed on Manjaro I was just trying to save him the build up of time to the decision to bounce to a different distro but I guess you just can't speed up experience

[F.Ultra]

People running Ubuntu should not be caring about the latest and greatest.... Either accept the older and more stable or hop on a distro that runs more modern stuff.... You can't have both

He was talking about an yet not released version of Ubuntu, so the "older and more stable" does not apply here. An LTS becomes stable once released, not before that.

[Danny3]

What? are you talking about the amdpro proprietary graphics drivers? Because those are entirely in userland, and are therefore essentially kernel agnostic. I'm not aware of any AMD closed source kernel modules.

Yes, the proprietary or whatever is downloaded from their website that you need for any kind of compute.
Last time I tried it, it was very picky about using an old LTS version of Ubuntu and an old kernel.
I really hated it.

[Weasel]

Apparently Valve and Collabora have been consistently funneling their efforts towards implementing and upstreaming futex_waitv for some time now, and apparently they know what they're doing since, due to their previous efforts, Wine has already transitioned from a mostly useless theoretical concept to a workable solution that's bound to change the Linux ecosystem; which means that apparently futex_waitv is already a good solution (predictable, since it's an evolution of the fsync concept and fsync is already good for many games, despite what that Wine dev was trying to say).

So apparently we should maybe start treating Valve and Collabora as the authorities-that-be on Wine development in place of the original Wine team, because the former apparently care about evolving Wine into a proper real-world solution that solves real-world use cases (even if they only care due to their desire to make it into a profitable product) while the latter are apparently growing more and more comparable to the GNU purists, systemd haters and the various other anachronistic entities that plague Linux these days. If we relied on them and their concepts of what's worthy to be merged and what isn't, we'd still be "playing" DX11 games in single digit framerates. Bah.

Please, do note that the bitter sarcasm is aimed not at you but at the Wine devs. Back when I told you (don't know if you remember our discussion) that I wasn't expecting futex_waitv support to be merged in Wine before at least both kernel 5.16 and Wine 7.0 were out of the door, I certainly wasn't expecting for it to be blocked from being merged indefinitely by the Wine devs due to Reasons™ - i.e. just as they've done with DXVK.

"Maintenance burden" I can sort of understand a bit, but honestly the entire logic in his "it's not secure, it's not how Windows does it" makes no sense. esync (and fsync) are hidden behind options (environment variables, could also be registry keys).

They should stop trying to decide what users decide to opt-in for. If they don't give a shit about security and want performance THEN LET THEM. This is as cringe as the idiots who put mitigations up without a way to disable them.