I know this is a weirdo hope, but I personally would wish to see KDE take a more clear stance against LLM code submissions, and to move away from relying on systemd so much. But I suppose most regular users would prefer more tangible features and changes.

A simple sync would show you when it actually finishes. However, it has system-wide effects. Perhaps KDE could lobby for a similar action to become available that is limited to e.g. a specific process id?

Windows could be considered uniquely responsible here since on a desktop you might think you’re safe from this if you always shut it down properly after use. Yet “fast startup” is a thing. It’s a questionable default that should be revisited.

Maybe it’s just me, but I find fully automated transit slightly creepy, at least when it comes to passenger trains. I personally prefer when there’s somebody human still on board having an eye on things.

Bug report asking them to undo it: https://bugzilla.mozilla.org/show_bug.cgi?id=2046154

I guess prepare for potential kernel rot: https://www.neowin.net/news/linus-torvalds-declares-massive-ai-fueled-code-surges-as-the-new-normal-for-linux/

deleted by creator

The studies about hidden errors don’t really care about how “slop” the code looks, as far as I understand them. That’s why LLM code is kind of dangerous.

My condolences.

Github seems to be down a lot, too, although perhaps not their pages part. Perhaps you could try to have just the pages in some other place?

I heard it’s alright for games and many apparently work. Sadly, FreeBSD simply doesn’t seem to have drivers for a lot of hardware that I’m using. And as far as I know, they don’t have an LLM policy yet (so they could still come out in favor of it).

I like that I can read this as you stating you use Atlassian yet hate Gitlab, and the statement still works either way 😅

That makes sense, since Gitlab seems to be trying to challenge Atlassian. In who manages to make worse software…

I’m saying if their policy is to accept AI code, which the link seems to demonstrate that it is, the rate of future hidden errors in the kernel code is likely going to go up. This is what all the studies are saying, including those involving competent coders.

The kernel policy seems to be what I think it is, since LLM slop patches have been merged.

I find it slightly contradictory to delete code due to hidden bugs on the one end, then insert LLM code at the other rather than hand-craft the code to avoid hidden bugs better.

I doubt the Linux kernel allowing slop patch submissions with potentially higher rate of hidden insidious bugs will help the LLM-pocalypse much…

any focused ideas on how this is triggered?

Be careful of what you say in front our Smart TV, warns Samsung