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.

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.

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

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

I came here looking for your comment!

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

Probably being reserved for the OpenBrandSherryDaquiri rebranding.

"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

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

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

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

Still waiting on 64-bit BonziBuddy...

Kaspersky though

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

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.

Good.

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

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

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

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

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

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.

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

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

Do you have any evidence to support this claim?