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.
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
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.
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.
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.
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
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.
> 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.
> I can still download entire albums and movies in minutes 2 decades later.
Yeah, but you cannot do so legally; you can't build a business of it. The AI companies are trying to build a business, not download movies for their kids to watch during school holidays!
The DMCA was passed in 1998. Napster didn't really hit big until 1999.
The 90s young people are familiar with are... way different from the 90s I remember. Their understanding of it is like... if someone asked to AI-gen the decade.
Wow, you're right. The DMCA happened while I was out of the country doing something very not-tech-scene related, so I completely missed that it passed way the heck back then.
I suppose my point still stands if you are willing to stretch back to Usenet, BBSs, etc. as an inflection point in mass copyright infringement.
There's only two ways for copyright to go, either by being tightened up or by being loosened.
When has copyright protections ever loosened? We've got hundreds of years of copyright laws in multiple different jurisdictions, and I can't think of when they were, for all practical purposes, loosened.
If they are loosened, then sure, the AI companies win big here. If they are tightened, AI itself becomes almost useless (derivative of current works).
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).
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.
Learn to stop worrying and love the bomb, I guess.
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?
The basic, broad usability barriers that prevent adoption by (or increase adoption costs for) many users today -- OS features, application support, hardware drivers, etc -- which has historically been far too much work for a much small developer community to reasonably maintain at parity with more mainstream operating systems.
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.
In this case, reading the link you're replying under, it's being able to mount a disk formatted with a popular filesystem. The alternative here is waiting for a human to type this relatively "solved" problem, as a procedural requirement, more than anything.
So, it can easily mean "things won't work in this OS". But, that's to be expected with FreeBSD, for legitimately good (from the perspective of FreeBSD) reasons.
Bugfixes, feature implementation, and hardware support will not be able to be added to OpenBSD with the speed that they are added to Linux.
Whether you like this new reality or not, it is an objective fact that LLMs are the silver bullet Fred Brooks told us didn't exist—multiplying development speed by 10x or more—and that if you're not using them you are hobbling yourself. This especially goes for a "security-focused" OS like OpenBSD, because AI is more diligent about finding vulnerabilities and can do so without rest. Meaning that if you're serious about security, you are using AI to harden your software... and if not, someone else is using it to hack you.
I'm sitting here watching astra do in a day what would have taken me at least 3-6 months. The code is verified correct. The model finds, reads, understands, and then integrates the latest literature into its designs and plans. It implements the code, proves it correct, and has come up with its own novel solutions on top of the state of the art. It then refines its implementation to hit the performance goals I give it. This is the reality today.
That it would've taken you 3-6 months because you're bad at what you do and don't know much. Being 10 times faster and better than 0.05 isn't particularly impressive.
I work in formal verification, at a FANG, with three decades of experience. In a day, I throw a few thousands of dollars worth of tokens at the SOTA models and have them produce tens of thousands of lines of code alongside proofs of its correctness.
Which is what we're doing, and we're solving problems now that we never would have attempted previously. We couldn't have even staffed them if we wanted to -- there just aren't that many humans on earth that can do the work. Even if we had the people, it would be years of development before we saw usable results.
If you can't understand how this kind of work would take 3-6 months, you're the 0.05 developer in my world.
The number of OpenBSD contributors, since 2017 is going down. For all the praise the system gets here, the developer team is small. And feature-wise the system is a toy compared to Linux. It's like comparing DigitalOcean with AWS.
Ppl praise the stance of OpenBSD/NetBSD and what-not. That's commendable, but then close the tab, open their spotify and get back to agentic programming for their proprietary company source. But God-forbid if OpenBSD turns anything more than a museum OS, full of purity but with a user-base of five. Because the GPU doesn't work properly, the sound drive is clunjy, wifi might work, etc.
LLMs could port huge amount of drivers to both system with a fraction of the effort. Specs can be implemented easily and properly. Then of course, you need to test and that takes time, but it's technically easier and more ppl could contribute.
I get the feeling, but they're not OpenBSD a favor, if anything else I feel the exact opposite is happening.
Ironically with sloppy code we will be back to 2001 with non-concurrent OSS and shitty sound daemons as esd/arts, now merged into pipewire but with crappy patches around.
Meanwhile OpenBSD will get 9front's GeFS stabilized and it will work on a fraction of what BTRFS needs to function, and don't let me start on ZFS.
one of the reasons that BSDs are less popular is because of the community advice of "The best supported machine is a ten + year old thinkpad."
so yeah you're right there isn't a finish line, but you do need to keep up with current stuff enough to give a possible fan base a decent selection of hardware to run the thing on.
in other words : if the companies that the BSDs already had a hard time keeping up with hasten development via LLMs the gap will grow ever wider until a critical point is hit and the thing becomes irrelevant.
if linux is the only show in town that supports flashy-hardware-Z then it's going to drive audience migration.
the thing that has allowed openbsd to adopt new things so slowly is a rock-solid set of core competencies; the amount that bsd is entrenched into the internet itself makes irrelevance hard to imagine -- but it's still a facet.
I still hear people bitch that BSDs don't support WiFi, and that hasn't been true in years and years.
If you follow the provided link, you'll see that the objection is about copyright, not quality: https://marc.info/?l=openbsd-tech&m=177411620801633&w=2 As someone who has certainly had his work sucked up into LLMs without consent or compensation, this seems like a reasonable stance to me.
his reasoning is sound. no pc no vulns. this is simple logic. its maybe not practical, but that wasnt being debated. OpenBSD isnt very practical either. It is pretty securable though for an ring0/3 system.
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.
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)
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
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.
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.
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.
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.
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.
Another interesting story is that on FreeBSD, Nvidia actually provides a port of their proprietary binary driver. The user mode piece does not support cuda, but I successfully ran a Linux emulator container that can run cuda with a FreeBSD kernel. I use it to run llms on FreeBSD.
But that is freebsd, not openbsd. I couldn't imagine it on OpenBSD because the priorities are very different
Microsfot Office 365 Copilot for Microsoft Windows 11 with Microsoft Copilot, for Microsfot Copilot+ PCs brought to you by Microsoft Office 365 Copilot for Microsfot Windows 11 with Microsfot Copilot, for Microsfot Copilot+ PCs.
The typical Office installer is a small bootstrapper that requires an Internet connection to download required files, but applications themselves are native and work offline (some features and applications use web tech for UI, of course).
Subscription-based licensing requires periodic check-ins, but perpetual product key-based licensing is available, though compared to the subscription versions, the release cadence for new features is slow.
The online component of traditional apps like Excel works best as a means for sharing documents, with the web UIs useful for reading and light editing, and the same documents fully editable in the native apps.
For most users it is enough. I know a number of companies that nowadays only provides the basic office365 license to their employees (which disable access to desktop apps) for cost saving reasons. They only provide the full license to a small subset of administrative users who are totally irrelevant in an OpenBSD related discussion as they would use windows or MacOS desktop anyway.
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.
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.
This wasn't a joke. It is well-known that Wine is the best and the most stable implementation of the Win32 API out there (closely followed by ReactOS).
This is actually really easy, I've had an abliterated Qwen 3.8 FN working on it.
Current Wine just needs a couple of fixes from upstream libxml2 to be able to use the Retail C2R (Click-To-Run) installer, then the apps themselves work fine with a few Direct2D patches (see the effort to get Paint.NET running).
The real issue is that getting activation (even using MAS tooling) working requires a real Windows kernel running for the Warbird-protected activation system, after two weeks I gave up, 99% of my MSO needs are provided by Artcraft now anyway...
Most tools rely on functioning Windows crypto, which was more complicated than I was willing to delve into to replicate. It probably can be done, and the Warbird source was partially leaked a while ago.
> 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 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.
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:
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.)
181 comments
[ 0.28 ms ] story [ 95.4 ms ] threadThere's even the remaster of The Witcher running! If I had money I would simply gift to those guys.
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.
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
It is verifiable and has a clear exit criteria. Functional and performance parity.
[1]: https://www.openbsd.org/policy.html
https://marc.info/?l=openbsd-tech&m=177411620801633&w=2
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.
Isn't he still alive?
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.
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.
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.
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.
Yeah, but you cannot do so legally; you can't build a business of it. The AI companies are trying to build a business, not download movies for their kids to watch during school holidays!
The 90s young people are familiar with are... way different from the 90s I remember. Their understanding of it is like... if someone asked to AI-gen the decade.
I suppose my point still stands if you are willing to stretch back to Usenet, BBSs, etc. as an inflection point in mass copyright infringement.
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.
I mean, it's not like the BSDs stagnated and lost ground to Linux because of copyright lawsuits... oh, wait!
There's only two ways for copyright to go, either by being tightened up or by being loosened.
When has copyright protections ever loosened? We've got hundreds of years of copyright laws in multiple different jurisdictions, and I can't think of when they were, for all practical purposes, loosened.
If they are loosened, then sure, the AI companies win big here. If they are tightened, AI itself becomes almost useless (derivative of current works).
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.
Learn to stop worrying and love the bomb, I guess.
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?
In this case, reading the link you're replying under, it's being able to mount a disk formatted with a popular filesystem. The alternative here is waiting for a human to type this relatively "solved" problem, as a procedural requirement, more than anything.
So, it can easily mean "things won't work in this OS". But, that's to be expected with FreeBSD, for legitimately good (from the perspective of FreeBSD) reasons.
Whether you like this new reality or not, it is an objective fact that LLMs are the silver bullet Fred Brooks told us didn't exist—multiplying development speed by 10x or more—and that if you're not using them you are hobbling yourself. This especially goes for a "security-focused" OS like OpenBSD, because AI is more diligent about finding vulnerabilities and can do so without rest. Meaning that if you're serious about security, you are using AI to harden your software... and if not, someone else is using it to hack you.
That is not remotely an objective fact. It's an opinion, and it isn't even an accurate assessment of the tech at that.
I'm sitting here watching astra do in a day what would have taken me at least 3-6 months. The code is verified correct. The model finds, reads, understands, and then integrates the latest literature into its designs and plans. It implements the code, proves it correct, and has come up with its own novel solutions on top of the state of the art. It then refines its implementation to hit the performance goals I give it. This is the reality today.
I've got some bad news for you.
Which is what we're doing, and we're solving problems now that we never would have attempted previously. We couldn't have even staffed them if we wanted to -- there just aren't that many humans on earth that can do the work. Even if we had the people, it would be years of development before we saw usable results.
If you can't understand how this kind of work would take 3-6 months, you're the 0.05 developer in my world.
[[citation needed]]
Ppl praise the stance of OpenBSD/NetBSD and what-not. That's commendable, but then close the tab, open their spotify and get back to agentic programming for their proprietary company source. But God-forbid if OpenBSD turns anything more than a museum OS, full of purity but with a user-base of five. Because the GPU doesn't work properly, the sound drive is clunjy, wifi might work, etc.
LLMs could port huge amount of drivers to both system with a fraction of the effort. Specs can be implemented easily and properly. Then of course, you need to test and that takes time, but it's technically easier and more ppl could contribute.
I get the feeling, but they're not OpenBSD a favor, if anything else I feel the exact opposite is happening.
As someone who has to professionally deal with AWS's feature breadth, this does not hit the way you expect.
Hahaha, fair! I meant feature-wise :-P
Meanwhile OpenBSD will get 9front's GeFS stabilized and it will work on a fraction of what BTRFS needs to function, and don't let me start on ZFS.
Could, but they don't. Latest Linux versions give compiler/linker errors (undefined references) which speaks great lenghts about the code quality.
one of the reasons that BSDs are less popular is because of the community advice of "The best supported machine is a ten + year old thinkpad."
so yeah you're right there isn't a finish line, but you do need to keep up with current stuff enough to give a possible fan base a decent selection of hardware to run the thing on.
in other words : if the companies that the BSDs already had a hard time keeping up with hasten development via LLMs the gap will grow ever wider until a critical point is hit and the thing becomes irrelevant.
if linux is the only show in town that supports flashy-hardware-Z then it's going to drive audience migration.
the thing that has allowed openbsd to adopt new things so slowly is a rock-solid set of core competencies; the amount that bsd is entrenched into the internet itself makes irrelevance hard to imagine -- but it's still a facet.
I still hear people bitch that BSDs don't support WiFi, and that hasn't been true in years and years.
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 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
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.
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
https://bsd.network/@brynet/117407035545900963
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.
Since many years longer, including the nv(4) driver for old Nvidia GPUs up to the earliest GTX models.
Tere is no drm or 3D acceleration for nVidia GPUs in OpenBSD.
Over time there can be periodic drift and out of date drivers until they re-sync, but it usually works pretty well.
But that is freebsd, not openbsd. I couldn't imagine it on OpenBSD because the priorities are very different
Subscription-based licensing requires periodic check-ins, but perpetual product key-based licensing is available, though compared to the subscription versions, the release cadence for new features is slow.
The online component of traditional apps like Excel works best as a means for sharing documents, with the web UIs useful for reading and light editing, and the same documents fully editable in the native apps.
recent only office builds are not quite there, but far superior to office Web.
(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)
Current Wine just needs a couple of fixes from upstream libxml2 to be able to use the Retail C2R (Click-To-Run) installer, then the apps themselves work fine with a few Direct2D patches (see the effort to get Paint.NET running).
The real issue is that getting activation (even using MAS tooling) working requires a real Windows kernel running for the Warbird-protected activation system, after two weeks I gave up, 99% of my MSO needs are provided by Artcraft now anyway...
https://news.ycombinator.com/item?id=49746401
> 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.
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.
Todd Howard probably
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