wanted to check back in to say that the progess has been staggering, and I’m glad you’ve stuck with it. Eagerly awaiting the flatpak release

I don’t care about any kind moral high ground; it’s clear enough what that rhetoric leads to.

i don’t really feel like splitting hairs over fascism, but he’s effectively said that I’m not british because i’m not white

he believes people like me shouldn’t be in london.

never mind that i was born in this country.

https://tekin.co.uk/2025/09/the-ruby-community-has-a-dhh-problem

also mentioned here

https://kvibber.com/reviews/software/ladybird-inclusivity/

fedora

I used to use BCU back in the day.

who?!

That’s interesting. You generally don’t need to manually install that. You’ve prompted me to play around with arch once I return from the most beautiful city in the world.

Which distro and dgpu are you using, if you don’t mind me asking?

That’s really peculiar, both the kernel mode and userspace drivers are included by most disteos by default, but I can totally understand the nv proprietary driver making a significant enough change that users will need to address when swapping to Intel or AMD dgfx

Can you describe the process of installing AMD drivers in this environment? It should be plug and play, though admittedly this was my experience with EndeavourOS, I’ve not yet tried Cachy

That’s not correct, though it may be ASIC specific. Can you tell me which GPU you’re using?

IME, GCN4 and up are all seamlessly served by the radv mesa driver. If this person upgrades to a newer AMD GPU, they will not need to manually install a Vulkan ICD

To add, there are mesa vulkan drivers for Intel (ANV, which is the original basis of RADV), nvidia (NVK), Qualcomm (Turnip), and Apple Silicon (forgot the name but something apple-y I hope), and several others.

I’m not sure if there’s any caveats specific to arch, I’ve not used it much outside of EndeavourOS, and primarily use Fedora, though the former was a completely plug and play experience across several systems with various generations of AMD graphics.

Isn’t that part already covered by the radv mesa driver? I’m really confused. did you mean to refer to vulkan as a 3D gfx API rather than an engine? Or are there specific rendering engine workarounds included in the aforementioned package?

further back in the day, nvidia were the only ones to provide competent support for Linux desktops. The fglrx days were rough!

You should be fairly well served then. reach out to us if you face any bottlenecks with gfx compute.

huh, that’s interesting. what does that provide to the system? Is that like having the lunarg loader present on a windows install?

If any of your workflows rely on cuda (or any form of gfx compute), you may have a difficult time achieving comparable performance. hopefully rocm is directly packaged for arch + derivs soon, like it is with Fedora, as you’ll be able to use that codepath for OpenCL if they don’t directly offer support for HIP or ROCm.

My typical hangups there would be like, digital film production and other forms of rendering, CAD, physics simulations, and client apps like Folding@home.

FWIW most of us don’t like red hat and absolutely despise ibm 😅

rpmfusion is generally safe in my experience. They have dedicated repos for FOSS, as well as nonfree ones, including steam and nvidia’s proprietary gfx drivers. I’d sooner equate fedora copr to aur rather than rpmfusion, which I think is more thoroughly scrutinised.

You can grab the codecs directly from Discover directly from the Fedora project. This is how it looks for me on gnome: .

You shouldn’t need to enable any third party repos, though i think the option is presented to a user as part of installation onboarding.

I’ve never had issues with the steam rpm or flatpak on fedora. I use the former almost daily.

to be clear: this is 40 games verified for standalone mode, not streaming from a host system,

kinda of a raw deal given the effort valve has already put into fex emu (and likely, into the turnip mesa driver as well).

not that qualcomm seem to care much about desktop Linux, though that may change with oobe (and the expectations therein) for llm shit.