"Can't even match GNU's coreutils"? Care to elaborate? Last time I checked OpenBSD is pretty much in line with Posix and there are plenty of us that consider many of the GNU extensions to be anti-features.

That's kind of like saying that the MacOS UI can't even keep up with Microsoft Windows. Who wants inconsistent GNU halfassery?

I think that's a cultural thing in *BSD.

What does "behind" actually mean, though?

Think about how far Linux has/hasn't come in the last 10 years. The user experience is nicer, drivers "just work" more, there's more support for more stuff...but at the end of the day, the actual computing experience is mostly the same today as when I installed Debian back in 2016. It's polish, interoperability, etc that's improved.

Maybe VR takes off and takes over the desktop, and then openBSD can't keep up with that, but I don't think that's likely. So what are they trying to "keep up" with?

‘Click to write and install driver’

Copyright adaptation literally means billion dollar lawsuits, because copyright only adapts after court decisions.

The BSD licences are not copyleft, or indeed part of the GNU copyright regime.

> my personal opinion about copyright _in the FOSS domain_ is that I simply dont care.

You may not care, but if the OS you prefer to run is the defendant in a copyright case, that's likely to impact you in a negative way.

It has. You don't see a lot of people who are all-in on AI or against it.

OpenBSD's errata list has recently started growing rapidly, and the scale is a real departure from the past. I have taken to running syspatch much more regularly than in the past. Anyway, it's clear that the project's stance on AI is "as long as reports are detailed and high-quality (and probably from a person with a record of such work) the project will act on it." See slide 17 here: https://events.eurobsdcon.org/media/2026/submissions/ZGDXQR/...

I never hid the fact that I iterated with AI. It's pretty hard to commit to an approach if you don't even know if it will succeed. And boy oh boy this was a shot in the dark.

I also respect Wine and OpenBSD and their rules to not have any LLM code in the repo/ports. So my approach was to iterate over solutions, find approach that works, ask AI to "just see if my idea even works", learn what/how/why of that approach, generate some supporting manuals for myself (for example how to decode %gs instructions and how to reencode them) and then write my own code based just on decoding tables (and not LLM code).

I did not know how to work with REX/SIB/ModRM, how to detect prefixes, how to parse every single instruction that contains %gs, how offsets work, how to encode jmp rels, why I want to use JMP *0(%RIP) instead of JMP 32rel on return, why I want to leave stub on SIGUSR (or any other signal). But I do know now.

I was incredibly lucky that patching just these %gs instructions were enough to launch Factorio and play, with broken sound, but anyways! Holy molly this was and is so much FUN!

The approach still feels like cheating, and if it feels the same for you, I perfectly understand.

Yes, he said the same on the mailing list[0] when he asking about a related thing 3 weeks ago:

> I had some success in porting Wine to amd64.OpenBSD. Was able to run a few = games. But that required in memory patching of %gs commands (LLM's suggesti= on and 1st implementation, then I re-did it from scratch - I'm not that sma= rt with amd64 assembly code)

Also, it's not a single author. Other people contributed significantly and their contributions don't seem written by AI: https://github.com/NethIafin/wine/commits/openbsd-master/

[0]: https://marc.info/?l=openbsd-tech&m=179070255546118&w=2

If "slopcode" means code where the author consulted AI at all, yeah. But it's pretty easy to tell if the author AI-spammed without even reviewing all of it, or even if they did review it but didn't hand-type it. The email says "you did not write them, you said an AI did," so the author did admit to using AI at the same time they claimed copyright over the code.