> 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.
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.
"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.
"[Doesn't] get the job done"? Well, it gets my job done. You are welcome to use whatever you subjectively prefer (I use GNU's date(1) for a few scripts, but would prefer the English date grammar parsing as a tool of its own), but if you are unable to talk about anything in concrete terms there is not point in trying to discuss in good faith and I will just roll my eyes and move on.
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
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
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).
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 they need 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.
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.
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.
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?
"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:
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.
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.
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.)
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.
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.
> 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.
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
https://marc.info/?l=openbsd-tech&m=177411620801633&w=2
Posix is more an art form documenting the far gone past rather than a practical tool
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.
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.
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?
https://cvsweb.openbsd.org/ports/emulators/wine
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://man.openbsd.org/nv
[2]: https://man.openbsd.org/amdgpu
[3]: https://man.openbsd.org/intel
It is verifiable and has a clear exit criteria. Functional and performance parity.
[1]: https://www.openbsd.org/policy.html
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.
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.
There's even the remaster of The Witcher running! If I had money I would simply gift to those guys.