Disco Elysium https://video.gamerstavern.online/w/qYjXr8dBauynzvEquJ7cP4
Hollow Knight https://video.gamerstavern.online/w/8tjjFRDtGJQZwxfE4ojVoC
Prey 2017 https://video.gamerstavern.online/w/vNxVThRcpijbT9FAQPcKdz
Death Stranding https://video.gamerstavern.online/w/rzz2TLCxcmneHsydukAFLU
Witcher 3 Remastered https://video.gamerstavern.online/w/oZcTRKL5JMiU4M4FqGKcNH
According to the reddit post:
AMD Ryzen 9 9900X, 16GB RAM, AMD Radeon RX 9070
For those not familiar with OpenBSD, it’s had an accelerated amdgpu driver since 2019, and inteldrm/radeondrm for a few years longer, generally kept up to date with Linux stable throughout that time.
Since many years longer, including the nv(4) driver for old Nvidia GPUs up to the earliest GTX models.
There is no kms drm or 3D acceleration for nvidia on OpenBSD.
Over time there can be periodic drift and out of date drivers until they re-sync, but it usually works pretty well.
(Its presentation is so stiff that I refused to play it - it's supposedly a very good game, but I just couldn't bear playing what felt like MS Office)
> I doubt much will be merged upstream. Many updates we have can technically run on other OSes (%gs stubs won't be built on Linux because %gs is correctly set, SIGUSR1 will work but less optimally, etc). However I picked an approach where everything that is done for OpenBSD is just marked as OpenBSD only. I did that purely to simplify my life while I was working on it and clearly mark the changes.
> When I was talking to Wine maintainers a month ago, they were hesitant to accept even patching Wine so it compiles for OpenBSD, mostly because it's another OS they will have to support and keep operational, while the %gs stub fix is something they definitely cannot take upstream. They are very hesitant to take anything that is changing the "emulated" application code.
Apple can't distribute them - coreutils is GPLv3, which is incompatible with Apple's immutable system volume.
https://www.gnu.org/licenses/gpl-3.0.en.html#section6
(There are other issues with GPLv3 which make it a dubious choice for companies like Apple, but this one is particularly problematic.)
We also test GNU coreutils on macOS. It is a bit tricky since the other maintainers and I don't own any macOS machines for testing. But we seem to do well enough with a shared system that Adélie Linux kindly allows the compile farm [1] to use, along with some additional CI machines.
Posix is more an art form documenting the far gone past rather than a practical tool
But the only concrete example I can think of is that `cat -n a b`, if `a` doesn't end in a newline, produces something that is obviously not what the user wanted. GNU cat does it right.
I didn't report it to the openbsd people because I didn't want them to yell at me that `-n` is nonstandard anyway with no "right" behavior, so I should STFU. Which would be what I'd expect from having reported problems in the past.
The slop problem is very real. People are spewing reams of bad code that generates entropy faster than humans or LLMs can clean it up. LLM best practices are not yet obvious, and we're still figuring out how best to leverage them while maintaining code quality and human understanding.
... but LLMs are coming whether we want them or not. Models keep consistently improving, the slop keeps getting better, and human-only development is going to struggle to keep up.
In my day job, I'm driving an enormous number of tokens at Astra+Ultramax solving problems in Lean 4 that previously we never would have attempted simply due to the incredible human engineering cost; we review the high-level lemmas and let it prove the rest.
LLMs are the only solution I've seen over these decades that could finally close the feature/usability gap between mainstream and more niche operating systems -- software support, features, drivers, and other broad usability barriers. All of that has historically been far too much work for a much smaller developer community to reasonably undertake.
Hating AI isn't going to make it go away.
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?
Theo de Raadt would spin in his grave — after the security implications of this to OpenBSD gives him a fatal aneurysm.
Either that, or he'll surprise-launch OpenLLM, a model bundled in the next OpenBSD release that produces driver code free of security bugs.
you could have the driver code prove it implements a spec, that there's no UB, that hardware invariants are maintained, that routines take a fixed time to execute.
the formal driver spec must still be written by sober, well-caffeinated humans of course.
Isn't he still alive?
Nothing in that post is against using an LLM. It's all about copyright:
>Since every file in OpenBSD has been continually verified to ensure correct Copyright, and we've even deleted code which has incorrect Copyright, the chances of us accepting such new code with such a suspicious Copyright situation is zero.
Once the current bubble pops we're going to see a lot of litigation over copyright enfringement by LLMs. Currently no one wants to rock the boat because everyone hopes to make a trillion dollars from AI, Oracle included, once they see they can't the knives are going to come out and I wouldn't want to be Linux at that point: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America
Also my personal opinion about copyright _in the FOSS domain_ is that I simply dont care. Copyleft as the GNU folks like to call it is just using the copyright laws to achieves certain free software objectives. If that doesnt work anymore there will be another fix
The BSD licences are not copyleft, or indeed part of the GNU copyright regime.
Copyright is dead.
I remember hearing that in 1996 too.
It took a while for the DMCA to happen after Napster. But it indeed happened, and we all know the saying about history repeating itself.
By the time they came for Napster technology had already moved on. I can still download entire albums and movies in minutes 2 decades later. Heck, Usenet is still a bastion of piracy and that's been around for 46 years.
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.
"Those that do not learn history" and so forth.
It polarizes people to either join the "the LLM is my god" crowd or the "if AI touches the repo, it's all slop" crowd.
The careful balance is rarely discussed, probably because that's the part that still takes work.
Agents and LLM-assisted coding currently work within the confines of already working hand-coded OSes, language frameworks, test harnesses and even CLI tooling. Pull one of those out, and agents become unhinged and they lose direction.
https://events.eurobsdcon.org/media/2026/submissions/ZGDXQR/...
Talked to bluhm@ after that talk in Brussels and the general feeling (from what I can remember from the conversation) so far is that there is a large increase in overall reports (good and bad), but that the severity of what is reported has not really increased. This also mirrors my own experience from reading source-changes@. In essence, it seems like we have known how to build secure software for the last thirty or so years, just that most do not seem to have bothered to do so.
https://www.reddit.com/r/openbsd/s/k0dz2WrkCo
In that thread I suggested he submit it to the ports tree, I'm not sure if he took my advice or came up with the idea on his own. At any rate this is cool.
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.
> 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
“what is {insert obscure tech thing}”
“why do people typically use {insert obscure tech thing}”
But of course, no one is born knowing, so here you go.
That has a static import from 13 hours ago. Anyone know if this wine port has its own repository somewhere else tracking the history of the development effort?
My guess is they based this on the similar NetBSD port but I don’t know where the repo is.
Edit: sibling commenter found it
[1] https://github.com/NetBSD/pkgsrc/tree/trunk/emulators/wine
[1]: https://man.openbsd.org/nv
It is verifiable and has a clear exit criteria. Functional and performance parity.
On the whole it looks well written to me, especially with how complex & low-level these areas of Wine are. Good work to the author. I'd encourage them to try upstreaming it if they're interested. Some of it looks a little hacky, which upstream will object to, but maybe they could get some help cleaning it up, which will avoid having to maintain a diff and result in an even better port.
Edit: Oh, looks like they already talked with upstream https://marc.info/?l=openbsd-ports&m=179241414029592 It's not a huge diff to maintain, so maybe that is the better route. Great work either way.
Rest is basically ~~two~~ three main issues 1. %gs/gsbase - we trap on %gs instructions because %gs=0 gsbase=0 so all of them illegally point at page zero. So we take the instruction, decode, turn it into %gs-less instruction, and stow it somewhere else. To do conversion we need a scratch register (now two, thanks MINGW32-GCC, you c*nt), we replace whatever gsbase should've been with our TEB pointer, and gogogo (with restore of the scratch register state {or two}). Old instruction (if wide enough) becomes jmp rel32 (I picked it because it is 5 bytes, and short jump branches are too... short). If it isn't, we are just constantly trap on that so we just create a hash between trap location and stub location. Those cases are thankfully rare.
Just this one patch gives us Notepad, Notepad++, Factorio, and many many other games
2. SIGUSR1. Basically Windows lets threads chat thru their thread API, and Electron apps (I really wanted Eve Online to work) and Chromium apps constantly chat and interrogate each other with that thread API. Wine decided to emulate some of the APIs with unix signals. Now the main issue here is that OpenBSD, does not allow one process to signal a thread in another process. So we catch it with the currently active thread, and reemit it now inside of the process as SIGUSR2. Read on SuspendThread, GetThreadContext, ReadProcessMemory, and why Mojo/Crashpad works how they work, very fun! Makes you really enjoy the security OpenBSD gives you. Another dev is making this code better and handle other SIGnals.
3. ReadProcessMemory / WriteProcessMemory (NtReadVirtualMemory / NtWriteVirtualMemory) - this is also for Electron/Chromium but mostly Steam. We only needed it majorly when we started pushing towards steam working. Steamwebhelper, steam overlay, and steam watching you play and tracking your game time, are completely against OpenBSD's security model. Wine processes are not descendants of wineserver, so wineserver cannot ptrace them unless you enable kern.global_ptrace=1. We were trying to keep kernel as stock as possible so...
2 and 3 are very much together and if you ever seen on windows how chrome looks in the Task Manager and how many chrome processes there are, well now you know my pain, haha
Todd Howard probably
Its hard to not think of the possibility that BSD might offer new or different advantages to keeping legacy windows applications safe until there is a willingness to adopt or develop alternatives.
There's even the remaster of The Witcher running! If I had money I would simply gift to those guys.
Probably outside the scope of what an individual could pull off on thier own in a reasonable time, but I could totally see for example Valve considering that approach for a later iteration of SteamOS.