Remix.run Logo
▲ Wine ported to OpenBSD(marc.info)
346 points by iamnothere 5 hours ago | 83 comments
▲haunter 4 hours ago | parent | next [-]

Gameplay videos

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

▲Maken 3 hours ago | parent | next [-]

I'm really surprised VKD3D works out of the box. So many abstraction layers stacked on top of each other feel like a jenga tower on the brink of falling.

▲braiamp 15 minutes ago | parent [-]

It targets vulkan, so if BSD has vulkan drivers it is agnostic

▲nottorp 2 hours ago | parent | prev | next [-]

Whoa, openbsd has 3d hardware drivers? Only open source i guess, no official drivers?

▲brynet 2 hours ago | parent | next [-]

Yes, the upcoming OpenBSD 8.0 release will have inteldrm/radeondrm/amdgpu drivers from Linux 6.18.y/6.18.53.

https://bsd.network/@brynet/117407035545900963

▲bentley 26 minutes ago | parent [-]

Correct, those are the versions in the coming release.

For those not familiar with OpenBSD, it’s had an accelerated amdgpu driver since 2019, and inteldrm/radeondrm for longer, generally kept up to date with Linux stable throughout that time.

▲Maken 2 hours ago | parent | prev | next [-]

The open source drivers are the official ones for Intel and AMD.

▲asveikau an hour ago | parent | prev [-]

They port the open source Linux drivers. FreeBSD does this too. Maybe others.

Over time there can be periodic drift and out of date drivers until they re-sync, but it usually works pretty well.

▲Onavo 2 hours ago | parent | prev [-]

What about the most difficult game of all, Microsoft Office?

▲sellmesoap 27 minutes ago | parent [-]

Yeah I tried that game once it's not for me, I heard the old boss tried to EOL civilization as we know it!

▲t-3 3 hours ago | parent | prev | next [-]

https://marc.info/?l=openbsd-ports&m=179241414029592

> 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.

▲iamnothere 3 hours ago | parent [-]

Yes, unfortunately OpenBSD maintainers will have to keep this running for now. NetBSD is apparently in a similar situation. Perhaps their efforts can be pooled at some point if the patches don’t diverge too much.

▲RunSet 4 hours ago | parent | prev | next [-]

Especially welcome news now that OpenBSD is shaping up to be a refuge from slopcode.

https://marc.info/?l=openbsd-tech&m=177411620801633&w=2

▲greyw 3 hours ago | parent | next [-]

OpenBSD will probably fall even further behind

▲vdombr 3 hours ago | parent | next [-]

Yeah, they won't have a chance to rewrite cp and mv in Rust.

▲Krssst 3 hours ago | parent | prev | next [-]

There are already OSes that include LLM code (such as Linux). It's fine to have a few that don't.

▲freedomben 3 hours ago | parent | prev | next [-]

Yep, drivers are one of if not the biggest blocker in my experience, and that's an area AI can help immensely

▲segmondy 3 hours ago | parent [-]

Then vibe up the ones you need for yourself.

▲Angostura 3 hours ago | parent [-]

‘Click to write and install driver’

▲overfeed 2 hours ago | parent [-]

> 'Click to write and install driver’

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.

▲ktta 2 hours ago | parent | next [-]

> Theo de Raadt would spin in his grave

Isn't he still alive?

▲boomlinde 2 hours ago | parent [-]

> — after the security implications of this to OpenBSD gives him a fatal aneurysm.

▲sterlind 2 hours ago | parent | prev [-]

honestly LLMs could probably write drivers in CompCert C or some other formally verified dialect. having AI discharge proof obligations seems like a terrific use for all this newly-developed mathematical process.

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.

▲speed_spread an hour ago | parent [-]

That's also assuming the device is fully documented and that hardware behaves exactly as documented.

▲lioeters 23 minutes ago | parent | prev | next [-]

Good.

▲noosphr 3 hours ago | parent | prev | next [-]

If you don't break the law you do indeed fall further behind people who do.

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

▲greyw 3 hours ago | parent [-]

Copyright will adapt.

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

▲noosphr 3 hours ago | parent | next [-]

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.

▲vconnor an hour ago | parent [-]

Yeah, the billion dollar lawsuits that are coming after the trillion dollar ones that are gonna hit the AI industry any day now.

Copyright is dead.

▲noosphr an hour ago | parent [-]

>Copyright is dead.

I remember hearing that in 1996 too.

▲vconnor 32 minutes ago | parent [-]

How was the LLM training scene in 1996?

▲toast0 an hour ago | parent | prev [-]

> 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.

▲JdeBP an hour ago | parent [-]

It is amusing to see this point made in a discussion that is notionally about one of the BSDs.

"Those that do not learn history" and so forth.

▲shevy-java 3 hours ago | parent | prev [-]

Well, they were always slow. But they made a stand against AI slop, which is great. Look at how AI slop infiltrated the ruby core team. You even get slop-spammed down when you try to interact with e. g. Hiroshi Shibata, who suddenly has ... perfect english language skills. A few years ago his command over the english language was rather weak (which is fine by the way, I much prefer broken english from a real human than AI slop spam text as filter acting in between humans).

▲atmosx 42 minutes ago | parent [-]

Then learn Japanese. No? So you can write broken Japanese and he doesn’t have to translate his words in English for you.

▲smlacy 3 hours ago | parent | prev | next [-]

Wow, I honestly didn't think HN would succumb to the AI := Slop perspective.

▲lionkor 3 hours ago | parent | next [-]

I think it's the complete saturation of the platform with members who make it feel like HN is a platform for people to boast about how many tokens they burnt to rewrite something that already worked fine.

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.

▲necovek 6 minutes ago | parent | next [-]

I think "careful balance" is the status quo even if people are unaware of it being so.

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.

▲kingcauchy 3 hours ago | parent | prev | next [-]

It really depends on the post anymore. Have had a lot of really thoughtful discussions about the nuance that came out of HN convos. Seems like most businesses and people are still just trying to figure out.

▲runeb 3 hours ago | parent | prev [-]

I would hope that lazy polarization found some resistance on this particular forum

▲mahboi 2 hours ago | parent [-]

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

▲ranger_danger 3 hours ago | parent | prev [-]

Although Theo seems to imply AI code is not welcome, this commit says Claude was used: https://github.com/openbsd/src/commit/9c2b8e445a0bdfafdd6148...

▲ninjin 3 hours ago | parent [-]

Plenty of issues that have been patched recently found using such tools as well. OpenBSD's policy remains largely the same as always: You need to understand the patch you propose and it needs to be maintainable. The link elsewhere in this thread is mainly discussing large patches where it is unclear if the LLM drew too heavily on code elsewhere.

▲raddan 41 minutes ago | parent [-]

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/...

▲hias 3 hours ago | parent | prev [-]

how do you think they made this wine port lol?

▲simonw 2 hours ago | parent | next [-]

Looks to me like it was made without AI assistance. https://github.com/NethIafin/wine/tree/openbsd-master

▲asveikau an hour ago | parent [-]

Afaik I think I saw the author say on reddit he used AI to prototype and then rewrote it.

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.

▲NethIafin 2 minutes ago | parent | next [-]

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.

▲MYEUHD an hour ago | parent | prev [-]

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

▲ranger_danger 3 hours ago | parent | prev [-]

Do you have any evidence to support this claim?

▲baq 3 hours ago | parent [-]

at this point in the timeline you need evidence to the contrary, safe to assume most code is AI generated or AI assisted at the very least

▲mahboi an hour ago | parent [-]

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.

▲ataraxia937 3 hours ago | parent | prev | next [-]

I find it amusing and appropriate that the surname of the author of that message is Frohwein. "Happy wine" in German.

▲spirographer 32 minutes ago | parent [-]

I came here looking for your comment!

▲philipallstar 3 hours ago | parent | prev | next [-]

Missed opportunity to call it Port.

▲mahboi an hour ago | parent | next [-]

I feel like there was some WINE-related thing called Port.

▲kingcauchy 3 hours ago | parent | prev [-]

Probably being reserved for the OpenBrandSherryDaquiri rebranding.

▲brynet 3 hours ago | parent | prev | next [-]

I OK'd this port. I apologize in advance.

▲Xunie an hour ago | parent | prev | next [-]

2026 is finally the year of the BSD gaming desktop!

▲simonw 3 hours ago | parent | prev | next [-]

OpenBSD apparently still uses CVS. I found this GitHub mirror of their ports repo which has the new wine port: https://github.com/openbsd/ports/tree/master/emulators/wine

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?

▲ninjin 3 hours ago | parent | next [-]

"Still uses CVS", I mean, CVS worked twenty years ago and it still works today for all the platforms OpenBSD supports. If you prefer something else, that is all right, but here is emulators/wine on CVSWeb:

https://cvsweb.openbsd.org/ports/emulators/wine

▲iamnothere 3 hours ago | parent | prev | next [-]

They mirror to GitHub regularly, but development still happens in CVS. They are building “got” as a potential replacement that allows git-driven development while following OpenBSD’s idiosyncratic approach: https://gameoftrees.org/goals.html

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

▲rjsw 2 hours ago | parent [-]

The GitHub mirror of the equivalent NetBSD package is here [1].

[1] https://github.com/NetBSD/pkgsrc/tree/trunk/emulators/wine

▲Maken 3 hours ago | parent | prev | next [-]

In their official CVS they link to this repo: https://github.com/NethIafin/wine/tree/openbsd-master

▲rootnod3 an hour ago | parent | prev [-]

The port itself doesn't mirror the wine code. It is just the recipe on how to build in on OpenBSD + necessary patches.

▲BlackRabbit1 4 hours ago | parent | prev | next [-]

Finally I can run Zonealarm on OBSD

▲GuinansEyebrows 3 hours ago | parent | next [-]

Still waiting on 64-bit BonziBuddy...

▲timcobb 4 hours ago | parent | prev [-]

Kaspersky though

▲Bluescreenbuddy 4 hours ago | parent | prev | next [-]

Good lord this is awesome

▲CodeCompost 4 hours ago | parent | prev | next [-]

That is awesome. I take it I can't run this with nVidia.

▲ninjin 3 hours ago | parent [-]

Nvidia support for OpenBSD is not really a thing [1]. With AMD and Intel, you have support for modern hardware in the tree [2,3].

[1]: https://man.openbsd.org/nv

[2]: https://man.openbsd.org/amdgpu

[3]: https://man.openbsd.org/intel

▲XenophileJKO 3 hours ago | parent [-]

The irony is that this seems like the perfect kind of problem to say point an Opus 5.5 instance at.

It is verifiable and has a clear exit criteria. Functional and performance parity.

▲ninjin 3 hours ago | parent [-]

How is that ironic? If you know how to do this, ensure that the license of the code is compatible [1], and maintain the code, then send the patch to tech@ for review and maybe it gets in.

[1]: https://www.openbsd.org/policy.html

▲rootnod3 an hour ago | parent [-]

Just be sure you understand the code 100% before sending it.

▲throwaway27448 4 hours ago | parent | prev | next [-]

Out of curiosity, how much work/what sorts of openbsd-specific details must be addressed to get such a port working?

▲coldpie 3 hours ago | parent [-]

You can download the attachment and take a look at the patches. Wine already supports FreeBSD and macOS, so it's not tooooo crazy hard to add another BSD/Unix to the pile. Looks like there's a few Unix APIs that have drifted, so the patches add some #if OpenBSD style stuff to avoid using some symbols that don't exist on OpenBSD. The gs register stuff is by far the most complex bit. IIRC that register is used for thread-local storage on Windows, but for other purposes on other OS's, so handling access from win32 binaries to the gs register is a big problem when porting to a new OS.

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.

▲ericfrederich 4 hours ago | parent | prev | next [-]

My first thought was this must have something to do with the development momentum around the PS5 but that apparently runs FreeBSD not OpenBSD.

▲imagetic 3 hours ago | parent | prev | next [-]

Yes. More of this.

▲shevy-java 3 hours ago | parent | prev | next [-]

Now the BSDs are not so popular compared to Linux, but I think this is great news as more eyes help here. Let's have EVERYTHING from windows portable towards linux. (I struggled with the 32-bit versus 64-bit stuff; this should also be a prime goal for wine to make this a trivial super-easy to solve thing for linux in general. Back then when I ran into this issue, it was not trivial to solve.)

▲raverbashing 3 hours ago | parent | prev | next [-]

I wonder what's the state of 3D/OpenGL support on OpenBSD or if the games run into too many problems here

▲j45 3 hours ago | parent | prev | next [-]

I remember reading once how far away something like this way to work - for all the time that BSD has kept servers and networks safer than other options, it's nice to see things like WINE making it there as well.

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.

▲saurilabs 3 hours ago | parent | prev | next [-]

This is awessome!

▲ndbe 4 hours ago | parent | prev [-]

Insane work!

There's even the remaster of The Witcher running! If I had money I would simply gift to those guys.