A lot of people remain frustrated about the general Darwin situation. This is not a new issue, in 2021 when things were particularly bad I even wrote an RFC trying to make Darwin support tier 3, upon which the situation briefly improved slightly. Almost two years later, it’s time to revisit this topic again.
Basically, the main contention points I see are:
Darwin infrastructure still greatly lags behind
Darwin maintenance also requires resources from people who use Linux, and more especially who don’t want to support such a proprietary platform, or add value to such a platform for free in their free time.
Since that RFC, Apple has started moving their hardware away from x86 towards arm. This is a side tangent to this post, but regardless of the general Darwin situation, x86_64-darwin specifically is on a descending branch and will need treatment soon-ish.
So this time, instead of simply writing a new RFC or re-opening the old one, I’d like to have some open discussion first, to see how other people feel about this, gather different experiences, and then see how to best move forward with the situation.
So to share my personal opinion on this: I don’t care about Darwin, and I don’t want to waste a single second on supporting it. I want to be able to move freely without having to ever be held back by Darwin. This means that I don’t want to wait for the Darwin CI to run through, I don’t want to fix it if my change makes it fail, and I don’t want to see a channel ever blocked again because of Darwin. People who care about Darwin are free to invest their time (and/or money) to fix any issues or breakages that arise.
This means that, even if Darwin had the underlying infrastructure and developer support to be bearable (which it currently totally doesn’t have), I still
would want to downgrade it to Tier 3 support for the reasons above.
To be clear: I don’t want Darwin gone, I just don’t want to be held back by it in any way.
I actively use both nixos and aarch64-darwin machine. For the packages I maintain (or use) I do my best to ensure they worth across both platforms. It is clear that Darwin support isn’t as good as Linux, but for the most part it works well enough for my needs. I’d like to see it continue to improve.
If a maintainer doesn’t have a Darwin machine and isn’t able to fully fix a package without one, I have no problem with the package being marked as broke on Darwin. For core packages, ideally the existing or expanded Darwin maintainers group should ensure they continue to work.
I do think we need to consider x86_64-darwin separately and consider what level of support to give it. I suspect Apple has a couple more years left of ok-ish support for the platform, but it’s clear that all the momentum is on aarch64. At this point I would recommend spending most of our effort on aarch64 with the understanding that x86_64-darwin is on life support until Apple themselves no longer update the OS.
See, that’s the problem. From that sentence I read that there still is the expectation that maintainers at least try to fix Darwin issues on their packages. And that’s something I strongly disagree with at the moment.
By the way, by definition of Tier 2 the maximum expectation is a mention toward the platform team after waiting for the CI. I am not sure how do we drop Darwin platforms literally to the definition of the Tier 2.
Good question when we declare the CI infra broken enough that even waiting for it is too much. (I usually do wait for at least one of the two macOS platforms to give results unless I actively care about getting the update done really quickly; waiting for both has not been a reasonable idea in a long time; looking into Darwin issues beyond maybe making the feature-flag defaults conditional in the absolute most obvious cases is of course beyond my care for these platforms).
I do not personally use any Apple machines, but started a few projects with somewhat complex, multi language dependencies managed by nix, developed and used by people mostly on macos, with prod running on Linux.
As far as I am aware, there is no other dependency management software out there which supports this use case well.
From my perspective, this seems like one of our main selling points.
I have no idea how to fix the situation, but it seems important to fix, since it is something we provide which is unique
If their package is marked for use on the Darwin platform, then yes I would expect some level of effort. I understand this is extra effort over just Linux, but in my view that’s part of being a maintainer.
You could always take a strict path of removing Darwin from your packages, and requiring a Darwin user to help maintain if they want to add it back. That may not be the most community friendly route, but is your prerogative as a maintainer.
I would be quite surprised if the community as a whole agrees to drop Darwin support level, given it is a popular platform for Nix.
These are my expectations and I made no claim that they are official in any way. Reading through RFC 46 I don’t see this view being contrary to the accepted wording. While platform users are explicitly called out for providing support (as I suggested they should) the maintainers aren’t given free rein to ignore the platform either.
Is there a more current list of platform tiers than RFC 46?
I think this is perhaps too aggressive. For instance, if PR #X breaks feature Y on darwin, it would be best not to merge that right away. We shouldn’t be actively and knowingly breaking darwin. Now, maybe after a discussion (if only a brief one), if it’s determined not to be anyone’s priority, then we can merge #X anyway. But to simply ignore that darwin exists is simply cruel to our existing and sizeable darwin community.
Now I understand this may or may not be exactly what you meant, but I just want it to be clear that a bare minimum effort is extremely important, even if that just means taking the time to listen to others about darwin.
I feel like “Adding value to a proprietary platform,” is a harsh way of looking at it. I doubt anyone’s choosing Apple hardware because of the Nix support. Rather you’re adding value for users, voluntary or otherwise, of a proprietary platform. I’m also convinced that most of these users are active contributors to open source projects in general and that their contributions do not only benefit other Darwin users. Please don’t conflate the users and the platform.
Another factor to consider is that Nixpkgs is currently one of the biggest forces for pulling Darwin back into the open. I know of no other project that manages to build so many Darwin frameworks from sources with open tooling like xcbuild.
The build infrastructure being lacking is a major pain point, this holds from the perspective of contributors trying to improve the Darwin situation in Nixpkgs too. I’m not sure whether there’s a way forward here without more financial commitments from companies who benefit from the support.
Re support for x86_64-darwin I’d like to point out that keeping older Darwin hardware usable is probably the best way to “stick it to the man.” It’s also the main indicator Apple uses to decide when to drop support for certain hardware.
In my experience, better darwin support (in nixpkgs) is primarily lacking in people willing to put work into it. And maybe the platform is somewhat harder to support than linux, too.
There’s still people offering to join darwin-maintainers. Unpinning the issue will slow that down, of course. Maybe there’s other ways to keep putting the word out?
It’s a tall task to keep up with the contributions of thousands of Linux-based contributors though.
There’s also work by @ConnorBakertrying to add more SDK versions, which builds upon the work by @reckenrode. The hope is that packages will be able to depend on a newer SDK when necessary. This has been a major source of friction.
I just wanted to highlight this to make it clear that Darwin maintainers are sympathetic to problems caused for Linux-based contributors. They are problems for us too! Not only in the strictest sense but also in the sense that we are aware that every time Darwin holds up Linux we’re losing another slice of support from Linux-based maintainers who try their best to not break Darwin. I think I speak for all Darwin users if I say we’re grateful for any and all consideration the Darwin platform is shown!
Effectively, we no longer need to worry about the build status of Haskell packages on Darwin before merging haskell-updates into master.
Our main reasons for making this change were:
Hydra’s Darwin infrastructure is just so, so, so, so flakey. We constantly had to restart builds that died or were killed for some random reason on Darwin. This happens much less on Linux. Darwin builds can also be waaay slower than Linux builds. I don’t know if this is because there are more Linux build machines available, or if the Linux machines are just higher-spec, but it is frustrating having to frequently wait for Darwin builds.
This might be specific to the Haskell infrastructure, but there are relatively few true Darwin-based build failures. Haskell is relatively cross-platform (well, at least between Linux and Darwin), and it is pretty rare to have (1) an actual build problem caused because of some quirk of Darwin, and (2) the build problem be fixable.
Only one of the Haskell maintainers owns a Darwin-based development machine, so most of us aren’t able to fix things or really even confirm that user-submitted PRs work. (Except for using ofborg, hydra, etc. But that is really painful.)
Few users submit PRs fixing build problems on Darwin. Even when we alert users that their Haskell packages fail to build on Darwin, most users don’t care. Most users don’t have any way of debugging or fixing problems.
As for my own personal opinion about Darwin support in Nixpkgs, I feel exactly the same as @piegames:
However, with my Nixpkgs Maintainer hat on, I do like that Nix works reasonably well on Darwin. I like that non-Linux users are still able to use Nix/Nixpkgs. I like that those users are able to contribute back to Nixpkgs, and make improvements that benefit people on all systems.
I sometimes wonder if Nix/Nixpkgs supporting Darwin brings in an out-sized amount of users, attention, money, etc to the community. For example, even if the amount of Darwin contributors in Nixpkgs is small, maybe it is much easier for any given company to decide to adopt Nix (because it is common for companies to have developers that use both Darwin and Linux). If Nix/Nixpkgs never had Darwin support, maybe Nix would be much more niche than it currently is.
Do you happen to know off hand what the error was? While working on Tracking issue for Darwin stdenv LLVM update · Issue #234710 · NixOS/nixpkgs · GitHub, I’ve noticed that GHC in particular seems prone to bad file descriptor errors with clang. I had assumed they were due to changes in clang 16, but if they’ve been happening with clang 11, then that would actually be pretty helpful to know.
I use both NixOS and Nix x86_64-darwin every day. I agree that macOS support is very important, but also agree that there are major issues stemming from it.
There was talk in the past of having separate Linux/Darwin channels. This would help a lot with freeing up Linux to progress more rapidly, but would offload a lot of work onto the Darwin maintainers, and the Linux channel would still require some monitoring from the Darwin side for critical packages (thinking of things like the Curl issues a while back).
It would be helpful to have some way to be notified of upcoming breakage ahead of time. If I’m not monitoring master and staging I usually only notice my maintained packages have broken when the breakage hits master. This affects more than just Darwin, it can be difficult to keep static/cross-compilation/exotic and anything else that doesn’t have ofborg CI continually working.
Do we have any numbers on the popularity of the respective platforms? The people replying in this thread, or even reading it at all, let alone that RFC, are probably not an accurate representation of all Nix users. What does the “silent majority” look like?
Maybe Mac users are disproportionately more “beginner”, less likely to seek out forums, discussions, or help.
Not that it would necessarily change anything, but if Mac is a “gateway drug” for NixOS (it certainly was for me, so maybe I’m just projecting), it would at least be good to know. And if it isn’t, that would also be good to know
I doubt there is an ideal measure, but the community survey asks about platform use broadly. Here’s a screenshot of the chart in last year’s result thread
Absolutely! The benefit of reproducible developer environments on all machines is really appealing to companies, the only issues right now are maturity concerns, which are off-topic here.
If darwin support is dropped, the adoption rate would drop with it significantly, and I would have no argument in pitching nix to clients at all[1]. At that point, the projects will always choose the language-related package manager because that works reasonably well and consistently on both platforms.
[1]: Unless all developers were using Linux and it would be clear that they’d all be using Linux for the forseeable future, which is very rarely the case, and if it is the case the company relies on a single distro for very specific software and have no use for Nix anyway (i.e. a robotics company using ROS on Ubuntu).
