today at 3:05 PM
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
today at 4:13 PM
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.
today at 7:01 PM
Vkd3d is a PE executable, if wine works and Vulkan works then it works too, as long as the required extensions are present
today at 6:31 PM
It targets vulkan, so if BSD has vulkan drivers it is agnostic
today at 4:40 PM
Whoa, openbsd has 3d hardware drivers? Only open source i guess, no official drivers?
today at 4:47 PM
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
today at 6:19 PM
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 a few years longer, generally kept up to date with Linux stable throughout that time.
today at 7:06 PM
> ... and inteldrm/radeondrm for a few years longer ...
Since many years longer, including the nv(4) driver for old Nvidia GPUs up to the earliest GTX models.
today at 8:26 PM
nv(4) is the old 2D user modesetting X driver (DDX), for legacy devices.
There is no kms drm or 3D acceleration for nvidia on OpenBSD.
today at 8:15 PM
How's the performance ?
today at 9:02 PM
Acceptable in my opinion.
today at 4:55 PM
The open source drivers are the official ones for Intel and AMD.
today at 5:22 PM
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.
today at 9:42 PM
Obvious in hindsight, shows how much of a BSD noob I am :)
today at 7:02 PM
OpenBSD has had hardware-accelerated 2D and OpenGL since, well, forever-ish. Just not for modern Nvidia GPUs.
today at 4:45 PM
[flagged]
today at 4:55 PM
What about the most difficult game of all, Microsoft Office?
today at 9:42 PM
Hey, modern versions of Excel have a GPU-accelerated computation engine.
today at 7:46 PM
You could try Age of Empires, its menus have the same charm.
(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)
today at 9:01 PM
There was a whole era of mid '90s Microsoft games where they were still competing with "Exit to DOS to get the best game experience" so they went out of their way to make sure you were aware you were running in Windows while playing their games. Aside from the early Age of Empires games I also recall the "Madness" family of racing games had different takes on the same idea from a variety of different developers. I actually just reinstalled Monster Truck Madness 1 the other day and have been working my way through trying to bodge it in to being an acceptable experience for this exact reason. The game itself runs fine but the UI does a lot of weird things that may have worked on Windows 9x with a low-res CRT but are very annoying on a modern system.
today at 8:23 PM
I'm having a blast with AoE I on Linux, in this case the Definitive Edition. I don't think it looks like Office though ;) But what is true, it's tricky to get running on WINE. With Proton which I use the configuration works by default though IIRC.
today at 6:18 PM
Yeah I tried that game once it's not for me, I heard the old boss tried to EOL civilization as we know it!
today at 7:40 PM
I would've checked it, if their Office 365... sorry... COPILOT OFFICE... wasn't such a problem to install and test. Notepad++ is enough.
today at 7:48 PM
I think the canonical name is MS Copilot for Copilot.
today at 8:28 PM
It's Microsoft 365 Copilot ;)
today at 7:44 PM
Luckily(?) Office is browser based now.
today at 8:08 PM
I mean... You can open Office documents in the browser, but for anything beyond basic tasks it's not even close.
today at 9:11 PM
I honestly thought there wasn't even an offline installer anymore, and office.com was the only way to open documents in office these days.
today at 7:20 PM
Whoa, whoa, whoa, stop right there, Evel Knievel.
today at 3:20 PM
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.
today at 4:06 PM
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.
today at 2:57 PM
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
today at 3:17 PM
OpenBSD will probably fall even further behind
today at 3:39 PM
Yeah, they won't have a chance to rewrite cp and mv in Rust.
today at 3:44 PM
[flagged]
today at 3:46 PM
"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.
today at 4:46 PM
I use a Mac, so the CLIs are the BSD versions. I don't have any opinion on which is better, but it's just annoying that it's different from GNU, so a lot of my work ends up being on a Linux VM or server instead. POSIX compliance doesn't seem to buy me anything. I like the BSD license though.
today at 6:11 PM
The GNU versions work fine in macOS. Apple doesnât want to distribute them, but thatâs mean you canât use them.
today at 7:31 PM
> Apple doesnât want to distribute them
Apple can't distribute them - coreutils is GPLv3, which is incompatible with Apple's immutable system volume.
today at 9:08 PM
That's a brand new excuse, Apple refused to distribute GPLv3 when GPLv3 was first published, 20ish years ago. How is GPLv3 incompatible with their system volume, yet GPLv2 is still fine?
today at 10:25 PM
GPLv3 added language which specifically requires that GPLv3 software embedded in products be distributed with "Installation Information" explaining how modified versions of that software can be installed. It is not at all clear how this would apply to software in an immutable, signed system volume. This language was not present in GPLv2.
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.)
today at 9:14 PM
This isn't new, GPLv2 is somehow compatible. This is the entire reason Mac OS ships an old version of bash but recent git.
today at 7:20 PM
Of course, but any script meant for Mac is going to assume Mac core utils, even assume zsh instead of bash. You don't want to be the one person on the team with a non-stock setup.
today at 6:22 PM
> The GNU versions work fine in macOS. Apple doesnât want to distribute them, but thatâs mean you canât use them.
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.
today at 8:07 PM
POSIX compliance doesn't buy you anything because you're trying to use GNU extensions, which aren't in POSIX.
today at 8:21 PM
I'm not trying to. And it's not even like GNU/Linux/whatever is a superset of POSIX and I'm using the extensions. There are mutual differences in basic functionality.
today at 6:26 PM
If you stick to POSIX, things generally work everywhere. It's not really a question of what is better, just what is portable.
today at 7:27 PM
I don't know how compatible my Mac will really be with a Free/OpenBSD machine. Last time I tested this theory, some C code I was building on Mac clang didn't build on FreeBSD clang cause I was unknowingly using some extension enabled by default. But that was about 12 years ago.
today at 6:48 PM
Sounds like it's Apple who's behind
today at 7:22 PM
In some cases they are, but that's not the cause for the mismatch vs GNU.
today at 3:51 PM
Thats exactly what I mean. I dont care about Posix or the whining about "anti-features". The BSD stuff is a clear subset that doesnt get the job done.
Posix is more an art form documenting the far gone past rather than a practical tool
today at 4:36 PM
What are some GNU coreutil extensions that you find you can't live without?
today at 4:38 PM
The conventions for the long parameters on the command line.
today at 7:47 PM
Dunno, since learning Xenix in 1993, I got plenty of work done in UNIX clones.
today at 3:57 PM
"[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.
today at 6:10 PM
I am not the parent commenter, but I have the same sense that the GNU ones are better.
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.
today at 5:20 PM
That's kind of like saying that the MacOS UI can't even keep up with Microsoft Windows. Who wants inconsistent GNU halfassery?
today at 4:05 PM
I think that's a cultural thing in *BSD.
today at 4:13 PM
There are already OSes that include LLM code (such as Linux). It's fine to have a few that don't.
today at 6:47 PM
It is, but an already niche operating system that refuses to leverage the advantages of LLMs is only going to fall further and further behind. I say that as someone who has actively contributed to the BSDs since the 90s and would hate to see that happen.
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.
today at 7:20 PM
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?
today at 9:30 PM
As one example I can think of, there are a ton of devices that only work on Windows (or Windows and MacOS). The audio interface I have is one example: its "official drivers" are Windows and MacOS only. I know that someone is trying to make Linux drivers for it, using LLMs, because if there's one thing LLMs are very good at, it's RE and figuring out how hardware works. One of my other friends made an accessible equivalent to the Razer app for his Razer headphones because the official app is complete shit.
today at 7:32 PM
today at 8:18 PM
"Behind" what exactly? This isn't a race to a finish line, it's an OS being developed.
today at 9:46 PM
openBSD is ahead. depending on what u need. If u want a PC with tons of apps and even more security issues by all means, they are far behind ;).
today at 3:31 PM
Yep, drivers are one of if not the biggest blocker in my experience, and that's an area AI can help immensely
today at 3:54 PM
Then vibe up the ones you need for yourself.
today at 3:57 PM
âClick to write and install driverâ
today at 4:27 PM
> '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.
today at 4:58 PM
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.
today at 5:15 PM
That's also assuming the device is fully documented and that hardware behaves exactly as documented.
today at 7:44 PM
Anyone who has done any work with hardware can confirm that neither of these things is ever true. :(
today at 4:51 PM
> Theo de Raadt would spin in his grave
Isn't he still alive?
today at 5:08 PM
> â after the security implications of this to OpenBSD gives him a fatal aneurysm.
today at 7:43 PM
Excellent, it will remain stable
today at 6:22 PM
Good.
today at 4:06 PM
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).
today at 6:03 PM
Then learn Japanese. No? So you can write broken Japanese and he doesnât have to translate his words in English for you.
today at 3:40 PM
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
today at 3:49 PM
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
today at 3:57 PM
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.
today at 5:29 PM
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.
today at 5:44 PM
>Copyright is dead.
I remember hearing that in 1996 too.
today at 6:13 PM
How was the LLM training scene in 1996?
today at 6:48 PM
So long as there's big money interests around copyright, I assure you it will not die. And all the predictions about the knives coming out after the AI bubble pops are spot on.
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.
today at 8:38 PM
> It took a while for the DMCA to happen after Napster.
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.
today at 5:34 PM
> 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.
today at 5:45 PM
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.
today at 3:16 PM
Wow, I honestly didn't think HN would succumb to the AI := Slop perspective.
today at 8:13 PM
First time I've seen := used for equality and not assignment.
today at 8:44 PM
On mac AZERTY keyboard those keys are next to each other, maybe it was a typo ?
today at 3:20 PM
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.
today at 3:28 PM
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.
today at 6:39 PM
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.
today at 3:43 PM
I would hope that lazy polarization found some resistance on this particular forum
today at 4:49 PM
It has. You don't see a lot of people who are all-in on AI or against it.
today at 3:44 PM
Although Theo seems to imply AI code is not welcome, this commit says Claude was used: https://github.com/openbsd/src/commit/9c2b8e445a0bdfafdd6148...
today at 3:50 PM
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.
today at 6:04 PM
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/...
today at 8:10 PM
Neat little link trick for PDFs:
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.
today at 3:40 PM
how do you think they made this wine port lol?
today at 4:16 PM
Looks to me like it was made without AI assistance. https://github.com/NethIafin/wine/tree/openbsd-master
today at 5:28 PM
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.
today at 6:43 PM
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.
today at 6:47 PM
I'm way more ai skeptical than most HN users and I don't think you did anything wrong. Like I said in the reddit thread, the patches are cool. Kudos.
today at 7:52 PM
this strikes me as the responsible way to use AI period - test it out, see what works then clean it up until its something you understand & can feel good about.
today at 9:38 PM
Yes, treating it as an occasionally flawed/wrong personal tutor (instead of a code genie) seems like a good use of it. Nothing wrong with learning by whatever means necessary IMO.
today at 5:46 PM
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
today at 6:49 PM
At that time, that LLM built solution was like 3+ weeks old if not more. It's just me and Fabien for now though. Rest are working on helping us turn it into a nice Port Wine
today at 8:14 PM
Some people are actually competent and know what they're doing.
today at 6:46 PM
Soon like with Speedrun submissions, we will have to show ourselves livestream coding to avoid any AI usage suspicions
today at 3:43 PM
Do you have any evidence to support this claim?
today at 3:49 PM
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
today at 5:17 PM
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.
today at 3:44 PM
I find it amusing and appropriate that the surname of the author of that message is Frohwein. "Happy wine" in German.
today at 9:16 PM
It's ironic that it looks like "frown"
today at 6:13 PM
I came here looking for your comment!
today at 3:17 PM
Missed opportunity to call it Port.
today at 3:25 PM
Probably being reserved for the OpenBrandSherryDaquiri rebranding.
today at 6:57 PM
I was (and partially probably still am) hoping that it will go upstream in some shape or form so I kept the original name.
today at 5:20 PM
I feel like there was some WINE-related thing called Port.
today at 3:18 PM
I OK'd this port. I apologize in advance.
today at 5:59 PM
2026 is finally the year of the BSD gaming desktop!
today at 8:20 PM
I wish every post like this had an intro section that said:
âwhat is {insert obscure tech thing}â
âwhy do people typically use {insert obscure tech thing}â
today at 9:01 PM
You don't know what OpenBSD or WINE is? I'm afraid that is on you.
today at 3:00 PM
Finally I can run Zonealarm on OBSD
today at 3:34 PM
Still waiting on 64-bit BonziBuddy...
today at 3:03 PM
Kaspersky though
today at 3:57 PM
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?
today at 4:15 PM
"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
today at 4:08 PM
In their official CVS they link to this repo: https://github.com/NethIafin/wine/tree/openbsd-master
today at 7:38 PM
Against my better judgement and my personal sanity, I decided to keep issues there, at least for now
today at 4:11 PM
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
today at 4:52 PM
The GitHub mirror of the equivalent NetBSD package is here [1].
[1] https://github.com/NetBSD/pkgsrc/tree/trunk/emulators/wine
today at 5:15 PM
The port itself doesn't mirror the wine code. It is just the recipe on how to build in on OpenBSD + necessary patches.
today at 7:09 PM
I am sure this has something to do with all the PS5 jailbreak work that is massively happening recently.
today at 2:51 PM
Good lord this is awesome
today at 2:51 PM
That is awesome. I take it I can't run this with nVidia.
today at 3:26 PM
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
today at 3:48 PM
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.
today at 4:02 PM
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
today at 5:18 PM
Just be sure you understand the code 100% before sending it.
today at 2:48 PM
Out of curiosity, how much work/what sorts of openbsd-specific details must be addressed to get such a port working?
today at 3:24 PM
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.
today at 7:28 PM
There are some basic OpenBSD-isms like ucontext, stack mapping, mmap, fix trap context so rest of the %gs patching logic even knows where to work.
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
today at 2:51 PM
My first thought was this must have something to do with the development momentum around the PS5 but that apparently runs FreeBSD not OpenBSD.
today at 7:16 PM
Impressive! Wonderful to see that the BSDs are getting love these days.
today at 3:32 PM
Yes. More of this.
today at 4:04 PM
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.)
today at 3:40 PM
I wonder what's the state of 3D/OpenGL support on OpenBSD or if the games run into too many problems here
today at 7:42 PM
> And one of the great things of having a Wine port is that It just works.|
Todd Howard probably
today at 8:03 PM
There's been hardware-accelerated OpenGL in OpenBSD for ages.
today at 3:36 PM
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.
today at 3:22 PM
This is awessome!
today at 9:06 PM
[dead]
today at 2:42 PM
Insane work!
There's even the remaster of The Witcher running! If I had money I would simply gift to those guys.
today at 4:17 PM
[flagged]
today at 3:16 PM
[flagged]
today at 3:03 PM
[dead]
today at 4:52 PM
[dead]
today at 8:04 PM
Semi-related, but I was just thinking today I wonder what sort of performance improvements, if any, one could see by having one of the frontier models build a operating system from scratch that targets the subset of imports WINE uses as the standard library? Basically, build whatever syscalls (or shims) WINE and the open source vulkan drivers need and nothing more.
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.