It’s not a bug, but a design choice in the Breeze theme. You can get rid of it by selecting this:

System Settings: Appearance & Style: Colors & Themes: Window Decorations: Plastik

(Or click Get New… and find another decoration set with angled corners.)

Gtk is the reason I’ve never bothered to try Budgie, let alone recommend it. I look forward to seeing what they do with Qt. (I hope client-side window decorations are not involved.)

Tor Browser is a modified Firefox ESR, which is just Firefox with less frequent releases.

There’s a lot more here than what the headline captures, about Flock, their lies, and how their systems’ widespread use affects communities. It’s worth a watch.

You may be underestimating the competency and speed of KDE devs. These people are the effing top.

I promise, my view of KDE developers is well informed. But it doesn’t matter, because KDE development alone isn’t going to fix deficiencies in the Wayland protocol.

so this is all a non-issue.

I think that view is overly optimistic. We shall see.

I might not agree with what ICE is doing but I also don’t agree with every corporation in the world having to morally police all of their customers for fear of being pilloried by cancel culturists.

I don’t think ICE behavior is remotely equivalent to celebrities who annoy people into trying to organize a boycott. To compare them like this suggests to me that the person doing so is either willfully complicit, or unfathomably out of touch. I hope you’ll give your position some more thought.

“The only thing nec­es­sary for the tri­umph of evil is for good men to do noth­ing.”

Yes, but I don’t want to dox myself here by pointing out specific issues that affect me, and I already have a plan to address my particular needs (although it will require significant work and still leave me with a worse Plasma experience).

I’m more concerned with the impact on the community as a whole. This will push some people into migrating to the ghetto of a very-long-term-support distribution, costing them time and making them second-class citizens, and is likely to push others into giving up Plasma entirely. I don’t think we will hear from many of them, since most people either do not participate in software discourse on social media, or will realize that there’s not much point in shouting when you’ve been deliberately left behind.

I have seen the amdgpu driver say ring gfx_0.0.0 timeout, but soft recovered every once in a while on certain kernel releases. It’s possible that there are multiple causes for messages like that.

I didn’t get a system crash; just a few seconds of sluggish behavior. In at least one case, it turned out to be a kernel driver bug that was fixed in a later version that reverted the offending commit. However, I suppose that ongoing work in this driver may lead to the problem returning.

Thanks for posting your findings. Have you reported them upstream, or searched for existing reports there?

https://gitlab.freedesktop.org/drm/amd/

Too soon, IMHO. This is going to be disruptive to people who rely on X11 functionality that’s unsupported or broken on Wayland and XWayland.

I can only hope that the fallout leads the wayland-protocols maintainers to finally address more of their project’s deficiencies.

Debian is just not present on gaming set ups

You are mistaken.

It’s not popular in that arena, but it’s definitely present.

Just in case you aren’t aware, int division throws away remainders. (And float/double tends to accumulate small inaccuracies.) You’ll want to keep that in mind if using this code for budgeting or any other money calculations.

Congratulations on writing a working program!

Thanks for clarifying. :)

You, I guess?

You’re saying that I am the ton of problems they were referring to? That’s either nonsensical or very rude.

Your.problem might be a perfect example of one of the many problems that keep popping up, that seem to only happen on the flatpak version.

What are you talking about? Running Steam in a flatpak works for me.

I’ve been using Steam in a flatpak for a couple years now, I think. What ton of problems are you referring to?

It wouldn’t surprise me if it processed vulkan shaders briefly every time, to check for recently used ones and upload them to Steam.

If it’s taking more than a few seconds every time, I would guess that either your last play session triggered a bunch of new shaders (for example if you explored a new area that used different visual effects), or you’ve stumbled upon a bug.

If you think it’s a bug, you should consider checking for reports on Valve’s issue tracker entry for that game, or on the Steam for Linux issue tracker if it affects many games. If there are no reports already, consider creating one.

The last sentence of the comment to which you replied covers this. What Valve does here is not the same thing, since it doesn’t involve the game developer or publisher, and doesn’t work for non-Steam games, and happens as an extra step. But it does come close to achieving the same effect (when it works), and it is pretty cool.

Edit: Graphics software enthusiasts who find the process interesting might want to check this out:

https://github.com/ValveSoftware/Fossilize

Every unit of a given console contains the same graphics hardware, so a single version of a game’s shaders can be compiled and shipped with the game, and they will run on every console of its kind.

(Also, early consoles didn’t use shaders.)

PC graphics hardware varies a lot, so shipping precompiled shaders with the game would require the developers to collect samples of all the world’s PC GPU families, compile the game’s shaders for each one, and ship all those compiled versions of all those shaders with the game. That would be impractical.

(The variance is arguably even greater in Linux gaming, which often involves graphics API translation, which can affect compiled shaders.)

It could be done for the Steam Deck, since every Deck has the same graphics hardware, if game developers & publishers were willing to make and distribute Deck-specific builds. However, that would rather defeat the Deck’s advantage of being able to run just about any PC game unmodified. Steam’s “processing Vulkan shaders” step is designed to more or less accomplish the same thing, at least for popular games.

Shaders are the tiny programs that generate a lot of the graphics you see in modern games. They have to be compiled into machine instructions in order to run on whatever hardware you have. Compiling each one takes a little time. Some games compile them all at once when you launch the game, so that they’re ready to go when needed during gameplay, while others let the graphics driver compile them on demand, which can lead to unpleasant frame rate hitches.

Steam’s Proton tries to help with this process by keeping tabs on the shaders that a game needs, compiling them for your hardware before launching the game, and collecting the compiled versions for use by other players with similar hardware. If someone has played the game with Proton before you, then Steam will give you copies of their shaders, so you don’t have to spend as much time waiting for your machine to compile them. (If this processing step is taking forever, it’s possible that you’ve encountered a bug, or a problem with the network or Steam’s servers.)

You can skip that step and jump right into the game, but then you might find the game’s frame times feeling stuttery or even pausing for seconds at a time while the shaders compile on demand. It won’t harm your system, but it can be annoying and make it hard for you to perform well in competitive action games. If you play through it for long enough, all the shaders that get used will eventually be compiled, and things will run smoothly thereafter.

Debian in general is not meant to run on the latest hardware.

When I see someone on social media claiming Debian is unsuitable for gaming, I know immediately that they don’t know what they’re talking about. I’ve been gaming on different distros since before Steam ran on Linux at all, and on Debian Stable for nearly a decade. This includes my current system, which was built a few months after the GPU was released.

In general, Debian can run just fine on new (Linux-compatible) hardware. If you’re talking about Debian Stable and hardware that was released less than a year ago, then you might have to pull in a newer kernel and/or firmware, but it’s not hard. In most cases, it’s as simple as enabling Debian’s Backports repository and installing the couple of new packages that you need. (You might not even have to do that, since Flatpak and Steam provide updates to much of what games need, but it would be wise to remember Backports anyway just in case you need them some day.)

The main thing to consider is that it’s not completely effortless. It will probably require a little more setup than a game-focused distro would, so if you’re considering Debian for a gaming system, you should know why you want it. For example, maybe you want a very low-maintenance system once it’s up and running. Or maybe Debian’s focus on Free software appeals to you. In such cases, a few extra steps when getting started might be worthwhile. But if you don’t have a specific need that Debian fills, then another distro might be more convenient.

Debian 13 is not going to get the latest versions of Nvidia drivers and there are better distros for us.

I don’t know if that’s true or not. Nvidia has a well-deserved reputation for making their hardware painful on Linux, and although the situation is less bad today than it once was, it’s still not great. If you’re determined to stick with them, then sure, a distro that does the extra work of packaging all of Nvidia’s driver releases might be a better choice for you.

(For what it’s worth, I finally ditched Nvidia in favor of AMD GPUs, and have been very happy with the results.)

I didn’t think I would have to spell this out, but when I wrote “as much as possible”, I was acknowledging that some libraries are either too complex or too security-sensitive to be reasonably homebrewed by the unqualified. (Perhaps “as much as reasonably possible” would have been better phrasing.) Where the line lies will depend on the person/team, of course, but the vast majority of libraries do not fall into that category. I was generalizing.

And yes, some third-party libs might get so much public scrutiny as to be considered safer than what someone would create in-house, depending on their skills. But safety in numbers sometimes turns out to be a false assumption, and at the end of the day, choosing this approach still pushes external risks (attack surface) onto users. Good luck. It hardly matters to the general point, though, because most libs do not have this level of scrutiny.

Let’s also remember that pinning dependencies is not a silver bullet. If I didn’t trust someone to follow “best practices”, I don’t think I would trust their certification of a third-party library hash any more than I would trust their own code.

With all that said, let me re-state my approach for clarity:

• I minimize dependencies first. Standard libraries are great for this.
• When something more cannot reasonably be avoided, I choose very carefully, prioritizing the safety of my users over my own convenience.
• Sometimes that means changing my original design, or spending my time learning or building things that I hadn’t planned to. I find the results to be worth it.