My thought is to not focus on whether they used the magic generator or not. My thought is to know who or what produced the code. Since I think it’s important to know where code comes from. Especially if dealing with projects that don’t want any generated code. Obviously the kernel isn’t one of those but still.

Or you could just shame them for not checking the output. People should never be get to freely deflect all blame to the LLMs, that’s just stupid and the fact it happens is complete brainrot caused by these things.

The LLM can come up with all the implementation details and such by itself, while the developer only provides wishes for new features. Figuring out where to draw the line between it just being fully “vibecoded” or being code the developer would have written manually is super hard, so why not just always say if LLM generated the code? What’s the harm in that?

True in some regards, however the word completion in my IDE is only active when I’m typing new code in, it only picks words that already exist in the code (along with language specific keywords, etc). It never types the following word for me, and I have to manually accept the completion I want. It is inactive when I’m typing comments in, and so on.

The LLM you tell to write you a function, and it writes the whole thing, comments and all. It’s not quite the same. The original GitHub Copilot was closest to traditional IDE completion though, and there if it wrote a whole long function for me I’d definitely give credit where it’s due.

My IDE does not write the code for me, at most it autocompletes words.

To me it matters because if you got code from someone else, you’d probably want to credit it to them, right? So why shouldn’t LLM output be treated the same?

Maybe developers could use that oh-so-amazing AI to optimize then…

Nope, blocked by the anti-cheat.

No idea. Since the path is a /run/media one, what’s the filesystem used there? Perhaps it’s incompatible. Have you tried putting the iso in your home directory and going from there instead?

But perhaps it would work best if you just do what the documentation tells you not to do and rpm-ostree install virt-manager (and libvirt and friends, if needed)

That /run/user/1000/doc/… path suggests it’s getting the .iso through the documents portal. So virt-manager is a flatpak? Sounds bad! Try using flatseal to give it direct access to all files.

Check the generic HD audio instead of USB audio. Or are those empty?

In alsamixer, is line unmuted and at a reasonable volume level and is “loopback mixing” enabled? Make sure you check on your actual soundcard, not the PipeWire fake card. And in any PulseAudio control panel (pavucontrol for example) make sure it’s set to the right port.

Note that depending on compositor switching to the legacy API might not help due to how they are designed. And with legacy you’ll also probably lose the fancy modern crap like HDR. A workaround I did in my own not-public fork of sway is to use the legacy API for cursor stuff and atomic for everything else. Seems to work well enough in getting the best of both worlds.

Sad, but does this problem only affect Wayland or also Xorg?

Wayland compositors only in my experience.

It is kinda simple. X.org and older Wayland compositors use the legacy KMS API, while modern compositors use the atomic API. The atomic API lets a compositor update everything for all planes in one go, this is a good thing because either all changes apply or none at all. The legacy API only lets things be updated individually.

Now why does atomic have more latency when it comes to mousing around? It’s because in a single atomic commit all properties have to be set, including cursor X & Y positions. Once an atomic commit has been sent to the kernel, it is locked and can’t be changed until the next monitor vblank. This means the cursor position is ever so slightly outdated. The legacy API does not have this limit, compositors can immediately move the cursor no problem, so less perceived latency. You can particularly see this while dragging windows around, on a modern Wayland compositor the cursor will be perfectly attached to the window, but in X.org it’ll be slightly ahead because of the reduced latency. Unless you don’t have a compositor running, of course.

There were proposed changes to address this years ago, but those seem to have fizzled out.

Oh and this is also why the cursor movement might visibly start stuttering during heavy GPU load. This is a problem that was solved back in the 80s but here we are…