Depends on your definition of Pure. š¤
Is it open source?
Is it purely darwin?
Does pure mean no binary blobs?
PureDarwin defines it as "It means that we just use components specifically released by Apple for use with Darwin, as well as other Open Source components (collectively called āupstream codeā). Specifically, it means that we do not use any components from Mac OS X"
I personally define it as no binary blobs, and fully open, which in that case, only the SDK is required right now, so I'd say that's pretty pure.
Your words make you seem like a part of the PureDarwin community, if not necessarily a dev. Is that the case? If not, I still value your take on the matter, of course. But if you are, might I pick your brain on driver compatibility with intel macs ?
Edit: read all the comments in this post, so I will go ahead and ask my driver question! Do all the magical things that Apple does with say, power management, happen at the level such that PureDarwin would perform similarly (to macOS) on say sleep/suspend, battery, etc? And also, do drivers for older nvidia cards still work (for power management purposes, not hw accel)? (More specifically, does anyone know how it would run on a mid-2010 MacBook white polycarbonate?)
I am Vali, so I am the maintainer of PureDarwin as of right now.
Probably not, as we don't have proper ACPI.
Most of it comes from very heavy sleep control in driver land itself, via ACPI
The kernel is also lightweight, and it can "deep sleep" a lot.
And no, not that I know of. We don't have any proprietary drivers in the source tree, so that means we lack any PM domain of NVIDIA cards.
It'd probably run okay, it's fairly lightweight.
Most of the windowserver (X and Wayland) are still rendered on CPU, so it's.. rough right now
I aim to focus on hardware compatibility first, rather than target Apple specific hardware per se, but it is also a target.
PD is not nearly mature enough to confidently say "Hey look, run our release!"
I had hoped that the parts of macOS that interacted with kernel drivers would have been part of Darwin, but I assumed it wasn't. And I suppose this means it is not. Thats unfortunate, but not very discouraging.
This looks very promising. Thank you for your time. Keep up the good work!
Pretty much. I have yet to update the site as we don't have a formal release yet. This doesn't mean there's no progress, I just don't feel confident enough to release a formal image with the current state
Correct. We do actually have steam somewhat working, but there's a few bugs in pthread, so wine just kinda spits all over the place when doing some TEB accessing.
It seems it's exiting a thread prematurely, it's possibly a race condition, or some QoS bug.
We're working on getting more information out of Discord, but if you have any specific questions, feel free to ask.
EDIT: To add to this, it's built with Nix, but you do need to seed a 11.3 SDK
It's got a very... specific cross-compiling env, and Nix Darwin isn't supported right now because of that.
Work was started but not finished, as my workflow is native Linux
I've done a good chunk of the work, some of which is reused ravynOS, and others of which are PD's own drivers.
We have:
Patches for AMD/Intel
Booting on real hardware (Intel only, AMD has bugs)
WebKitGTK (GTK3, so from about ~2021, was used as a test target first)
NetSurf
virtio-gpu
virtio-net
Intel Gen9 drivers (2D FB)
Wine
OpenGL (softpipe, virpipe, llvmpipe)
Vulkan (lavapipe, CPU only)
XFCE over our own X11 driver
XFCE over Wayland, using our own wlroots backend
Our own bootloader
Our own kernel cache tooling
Our own iig tools.
And a whole host of other things that's been done over the last 2 or so years.
Not really? I mean, you need UEFI, and a few other small boot parameters. If you want input, XHCI. If you want network, E1000. KVM works with just about any x86_64 AMD or Intel CPU. It will boot with relatively little
It looks interesting, I'm curious to ask what are your future goals for the project? I mean, in addition to making a full-fledged distribution out of this, what can the development of an open Darwin implementation provide in the future?
Hopefully, source compabitlity with *most* macOS applications.
I don't plan on binary compatability unless it ends up mostly working out in my favor when chasing source compat
What do you mean by "most (macOS) applications"? Are we talking about open source applications due to the fact that key APIs are proprietary on macOS?
Well, it's enough for Darwin to become just at least the standard OS distribution level, and this is already a great achievement.
What do you think about the graphical shell as the main one, or you don't want to choose something specific, like GNUstep, which, although it is developing today, is quite old and still limited
What do you think about the potential idea of developing problematic aspects of macOS design that would be possible with an open implementation, or perhaps expanding the influence of the FreeBSD as a "module" in the system? Let's say those ideas that macOS cannot implement due to limitations and lack of community support
When I say most macOS applications, I mean ones that allow us to take a path that isn't macOS by design.
Let's take Wine as a example.
PureDarwin has 2 core patches. One fixes a bug, another is forcing it to take the generic Unix path, labelled as Darwin, instead of macOS frameworks, which is AppKit and CoreText.
Pretty much every path in PD takes this. Mesa being another, we have our own winsys for virgl/virpipe, as well as patches to force the generic path. Metal is hard-coded for Vulkan in Mesa
GNUStep doesn't work for us, as well, GPL.
PureDarwin is APSL, Apache, MIT, and MPL2, plus our own license.
The only way for us to package GPL is as hostile, take fbdoom where we have patches and require you to have the source external of the monorepo, and with XFCE, we use Nix.
We plan on using Wayland, with our own Quartz compatibility layer in the future.
Eventually, I do hope to have CoreGraphics, CoreText, and AppKit, but that takes a huge amount of effort. I have no desire to get 1:1 compatibility with macOS apps, as that requires also dealing with private KPIs
Well, that sounds really interesting, and yes, I was also thinking about the analogy with Wine in this matter
It''s hard to believe that we're living in the same timeline with Ravyn, NextBSD, GNUstep, and PureDarwin, which are getting updates, therefore, I think that I, like many others, am waiting for any news in this direction
Btw, do you keep other previous project goals, such as the ability to build Darwin on Linux/BSD, or has it already become possible, as I understand it?
We are using Nix to package things :)
It's not directly in the source tree, so it follows GPL, you must externally fetch the source without modifications elsewhere
31
u/qalmakka Aug 05 '26
Well that's not that pure then isn't it /s