Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
Latest Comments by pleasereadthemanual
XZ tools and libraries compromised with a critical issue
30 March 2024 at 12:39 am UTC Likes: 9

Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

If so, someone needs to go through xz-utils with a fine toothed comb.
So it would seem that this new maintainer has been trying to gain control of XZ since 2021, and has had control of it since 2023. That's quite concerning and surprising. It seems unusual for bad actors to try to gain control of the supply chain long-term. Older XZ releases might have other unreported vulnerabilities even on stable distributions...

This maintainer has at least 750 commits to his name: https://hachyderm.io/@joeyh/112180715824680521

But to quote Glyph:

QuoteI really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/[email protected]/msg00567.html

Oh Snap! Canonical now doing manual reviews for new packages due to scam apps
29 March 2024 at 4:52 am UTC Likes: 6

Quoting: pilkI'm glad they're finally doing this, but this should've been implemented, at the very least, after the first time this happened.
In 2018?

SDL 3 will prefer Wayland Over X11, if certain protocols are available
28 March 2024 at 1:07 pm UTC Likes: 5

Sounds reasonable. Hope the protocol extensions get implemented sometime soon.

Just out of curiosity, I was counting the merge requests for protocol extensions in wayland-protocols today...

There are currently 86 open merge requests (MRs) in wayland-protocols. 4 protocol extensions were merged in the past 7 days, including the long-time linux-drm-syncobj-v1 protocol for explicit sync. 155 MRs have been merged in total (not all are protocols, but most are), and 51 have been closed (either in favor of new protocols or rejected outright).

Of the 86 open MRs, 43 of them were created in the past year. The remaining 43 are more than 1 year old. 14 MRs are between 1-2 years old. 9 MRs are between 2-3 years old. 12 MRs are between 3-4 years old. 8 MRs are between 4-5 years old, including the enormous Color Management protocol (#14), which is actually even older than that because this one predates the gitlab instance.

Did someone mention portals? Certainly not me.

FWIW, Explicit Sync and Color Management are the ones I really care about, and Explicit Sync is finally merged.

Nova, a Rust-based Linux driver for NVIDIA GPUs announced
27 March 2024 at 10:46 pm UTC Likes: 1

Quoting: Eike
Quoting: pleasereadthemanualYou see, it's actually really simple.

(...writes a manual...)


Quoting: Eike
Quoting: pleasereadthemanualI get the distinct feeling I'm missing something...

(Serious) question: Mesa?
Probably!

Nova, a Rust-based Linux driver for NVIDIA GPUs announced
27 March 2024 at 12:28 am UTC Likes: 9

I see there is some confusion about the Nova/Nouveau + NVK + Zink/Nouveau NVIDIA driver situation.

You see, it's actually really simple.

Graphics drivers always come in pairs, you see: there's a kernel driver, and then there's a userspace driver that sits on top of the kernel driver. First, we had the Nouveau kernel driver, which was a reverse-engineered open source driver alternative to the proprietary NVIDIA driver (it does not have a name). The proprietary NVIDIA driver, to keep things simple, is both the kernel and userspace driver in one. So, by itself, the Nouveau kernel driver is not useful, which is why it needs a userspace driver. To keep things simple, it was also called "Nouveau". It handled OpenGL calls.

Many years later, NVIDIA open sourced the kernel driver of their proprietary stack, often referred to as "open kernel modules". So now they have two drivers too!

Now we have NVK, which is a userspace driver just for Vulkan. Then Zink was written (which afaik was also being used for AMD) for the OpenGL calls, but what it really does is convert the OpenGL calls to Vulkan calls, which ends up being both faster than writing a new OpenGL driver and actually faster in performance because Vulkan is apparently the panacea to almost every problem on Linux.

So you can have a few stacks:

Nouveau (kernel) + Nouveau (userspace)
Nouveau (kernel) + NVK + Zink
Nova + NVK + Zink
NVIDIA (proprietary kernel) + NVIDIA (proprietary userspace)
NVIDIA (open modules) + NVIDIA (proprietary userspace)

The open modules are also "out of tree", which means they will never be mainlined like Nouveau, so they are no easier to install than the proprietary modules, and offer the same performance.

However, be careful! You can't combine the open modules from NVIDIA with Nouveau userspace or NVK + Zink. The open kernel modules only work with the proprietary driver.

I wonder if you could combine Nouveau (kernel) with NVK and Nouveau (userspace). Food for thought!

Then there's the GSP firmware for the GPUs. This is what will allow NVK to support HDMI 2.1+, because that code is inside the firmware. I think. I don't know anymore.

I get the distinct feeling I'm missing something...

Oh, and I almost certainly got the stuff about Zink wrong. I think that had something to do with converting the OpenGL code on the Nouveau userspace driver to Vulkan or something..?

SDL 3 has a first preview release out with HDR and Vulkan for the 2D rendering API
26 March 2024 at 8:45 am UTC

Quoting: Marlockthey could delay SDL3... but that only helps if Wayland devs clearly signal they'll solve their end of the issue soon with high priority... which seems a bit unlikely, though Valve does have plenty of people working for them on both things, iirc
This was brought up in the pull request, but it doesn't seem like something SDL is interested in doing. Either because they just don't believe they can get this protocol and implementations sorted out in time for the next release (ideally, that might take 6 months?), or because they don't want to delay it at all. That might change as SDL3 gets closer to release.

There are definitely Valve employees like Joshua Ashton who engage in Wayland Protocol discussion. Joshua Ashton has also done a few implementations for Wayland protocols such as in Mesa. I'm sure there's more I don't know about. For this particular protocol, at least Xaver Hugl (KDE), Joshua Ashton (Valve), Simon Ser (wlroots, gamescope) and Derek Foreman (Collabora) have been working on it. No idea how close it is to completion, and it seems to depend on another protocol that isn't finished.

Oh, and even flibitijibibo is commenting on the SDL pull request.

SDL 3 has a first preview release out with HDR and Vulkan for the 2D rendering API
25 March 2024 at 11:04 pm UTC

Quoting: hell0
Quoting: pleasereadthemanual
QuoteIf we do this, we are basically accepting these issues are unfixable for the next ten years (SDL4).

[...]

Shipping a broken default is the wrong thing to do. Unfortunately, that protocol is unlikely to be finished before SDL3's release (3+ months away).

Two bad options. There's suggestions of flipping the default later on in the lifecycle of SDL3 once this protocol is implemented, and that seems like what's going to happen. I'm not sure what the downsides of this are.

I'm not interested enough to go and read the whole debate. But is there really a 10 year life cycle for SDL? Or something preventing them from releasing SLD4 a year from now?
There is no evidence supporting this one way or the other that I can find, aside from Conan-Kudo's argument. He is the only one that mentioned it, and no one else responded about it. I couldn't find any information about how long SDL versions are supported for.

I can only assume it's based on the time between SDL1 and SDL2, and now SDL2 and SDL3.

SDL 3 has a first preview release out with HDR and Vulkan for the 2D rendering API
25 March 2024 at 1:17 pm UTC Likes: 5

Interesting to see two Valve employees, Joshua Ashton and Sam Lantinga, as contributors and even creator/maintainer of SDL. I wonder how many more there are.

Taking a look at the CREDITS.md file:

QuoteMike Sartain for incorporating SDL into Team Fortress 2 and cheering me on at Valve.
Pierre-Loup Griffais for his deep knowledge of OpenGL drivers.

And just as an interesting point-of-fact:

QuoteEverybody at Loki Software, Inc. for their great contributions!

That Wayland vs X11 issue is quite contentious. We've got everyone from Conan-Kudo, Xaver Hugl from KDE, to Mattias Klumpp weighing in on it. One thing that strikes me is how long it would take for Wayland support to be implemented if the missing protocol isn't merged in time for SDL3's release:

QuoteIf we do this, we are basically accepting these issues are unfixable for the next ten years (SDL4).

What's more, every major desktop is now Wayland-first, and GNOME is soon to be Wayland-only, maybe next year. The XWayland X server is still around, so there's still support for the features SDL needs...but it also has problems.

Shipping a broken default is the wrong thing to do. Unfortunately, that protocol is unlikely to be finished before SDL3's release (3+ months away).

Two bad options. There's suggestions of flipping the default later on in the lifecycle of SDL3 once this protocol is implemented, and that seems like what's going to happen. I'm not sure what the downsides of this are.

Explicit Sync Wayland Protocol Merged, Wayland Protocols 1.34 released
23 March 2024 at 1:32 pm UTC

Quoting: CalebQ42Good to see this is finally being fixed(ish). This is one of the main reasons I switched to AMD nearly a year ago as the issue ultimately comes down to NVIDIA deciding they want to do something a different way then everyone else and letting their users have a bad time. From the research I've done, there are some benefits to explicit sync over implicit sync, but since every other driver already has implicit sync no one was in too much of a rush to add it.
It seems like almost everybody is in favor of explicit sync: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317#note_1358617

There's a link to this article included: https://lwn.net/Articles/814587/

QuoteExplicit synchronization is the future of graphics and media. At
least, that seems to be the consensus among all the graphics people
I've talked to. I had a chat with one of the lead Android graphics
engineers recently who told me that doing explicit sync from the start
was one of the best engineering decisions Android ever made. It's
also the direction being taken by more modern APIs such as Vulkan.
I can't claim to have researched the topic in detail beyond what was necessary for me to understand the significance of this protocol for my flickering issue on Wayland, but this doesn't actually seem like a controversial issue: everybody wants explicit sync.

Glad to see this issue is finally going away, though.

GitLab takes down Nintendo Switch emulator suyu due to the DMCA
22 March 2024 at 6:32 am UTC Likes: 1

Quoting: LoftyHow is it different from emulating lets say a 20yr old PS2 game ? perhaps fundamentally it is not that far apart, but the developer is not losing money on sales for a start, the hardware is well and truly out of action and there is no effective DRM to bypass or machine to crack. Maybe that's just semantics.
Strictly speaking, the two are not mutually exclusive. The common rhetoric is that users should buy the Switch, hack it so it can dump game archives for cartridges they insert, and then for the user to purchase the game and dump it. Nintendo doesn't lose out on any sales this way.

What is the proportion of people doing that? That's a completely different story.

Some PS1 discs were protected by Libcrypt in 1998. Circumventing that today would still fall afoul of Section 1201 of the DMCA, no two ways about it.