Status of macOS #116341
Comments
|
Just want to mention that Qt 5.15 builds on Hydra right now, it's only qt515.qtwebengine that is not trivial to get running with 10.12 SDK. |
|
Building with |
Reproducing the original OP for posterity.Status of macOS support in NixpkgsMost of this information is based on the Nix ❤️ macOS Open Collective wishlist and the Darwin maintainer tracking project. Apple SDK updateCurrent stdenv uses Apple SDK version 10.12. This means binaries built by Nix and cached in the official binary cache run on all versions of macOS since 10.12. Updating the version of the Apple SDK used in the darwin stdenv means dropping support for any Apple hardware that cannot be upgraded to the corresponding version of macOS. Issue #101229 makes it clear that updating the SDK is becoming a pressing concern. Some important packages require a version newer than the oldest supported by Apple, like CPython #105038 and Qt WebEngine 5.15 (Qt 5.12 will be EOL in December 2021 so we want to move to Qt 5.15), both requiring 10.15. Some work has already been done to ease the transition to a newer SDK. Basing stdenv on Text API, which is unavoidable as of 11.0 Big Sur, in #98541. And making it possible/easy to update packages in apple_source_releases individually, in #108590. Another factor in this decision are the Hydra build machines. There are currently 9 Intel Mac Minis, NixOS/foundation#5, and 6 Apple Silicon Mac Minis, #95903. All but the oldest support the latest version of macOS. All of them support 10.15 Catalina. What is the way forward? Do we package every SDK version and then default to the oldest supported but make it possible for packages to specify the minimum version they require? Do we focus on source releases instead, to limit the reliance on the SDK? Installation tutorialDue to changes in Catalina which locked down the filesystem root, mounting it read-only, installation has gotten less straightforward. It currently requires a separate non-encrypted APFS volume, as of NixOS/nix#3212. I will go through the installation process and write up a detailed tutorial to minimize friction for new users. Including setting up nix-darwin and home-manager. This will probably simply repeat information that's already out there in various blog posts but in more detail, potentially going over alternatives. Is there other documentation that is known to be missing or in need of improvement? ✅ Bootstrappable stdenv on Big SurWith the Text API stdenv builds on Big Sur are possible but during the bootstrap it still requires linking to an actual libSystem. This means the stdenv was only usable on Big Sur as long as a bootstrap was generated on Catalina or earlier. This issue is described in #104580 but should be fixed by #107013. Apple Silicon SupportThe next big hurdle is support for the new Apple Silicon (aarch64) CPU architecture. Several M1 Mac Minis are already available for CI, #95903. Work towards this is actively ongoing in #105026, with accompanying Hydra jobset for detailed progress on which and how many packages build succesfully. Sandbox supportWhile NixOS sandboxing works well on Linux, on macOS it has been plagued by problems for a long time, NixOS/nix#1821. Among other things the limitations of macOS's sandboxing framework as compared to Linux make it difficult to achieve the same degree of sandboxing. Is perfect the enemy of good enough here? Can we gradually introduce sandboxing on macOS, incrementally tightening down on the simplest measure to take next? Or do we need a thorough design from the ground up, which may result in a different approach to sandboxing from NixOS? Runnable NixOS testsMaking it possible to interactively run NixOS VMs on macOS has an unexpected advantage, #108984. Linux runners on CI providers like Circle CI and GitHub Actions cannot use KVM so NixOS tests are slow to run. Their macOS runners otoh do have access to macOS's KVM alternative, so running NixOS test VMs on macOS CI runners could provide a nice speedup. Installer improvementsCurrent work to enable the installer to encrypt the Nix store volume if FileVault is enabled is close to complete in NixOS/nix#4289. This PR and changes that have been previously merged will probably fix zsh-specific compatibility issues that have cropped up. @abathur also mentioned it might be possible to have the installer check a user's shell rc files for things that may cause issues, the use of absolute paths posed a problem for someone during install. And that these changes will make an uninstaller feasible. The changes include detecting and fixing problems with volume state, think permissions or whether the volume is encrypted if FileVault is enabled (potentially after installing Nix). This goes most of the way towards making the installer idempotent and an uninstaller would mostly deal with the same things. An apt summary of the work in this PR by abathur, "The goal is to remove any macOS-specific asterisks on the install step for Nix." Uninstallation and reinstallation should be easy, the former should lower the barrier to trying out nix and the latter allows for people to start over, taking away the stress of getting everything right the first time. Are there other missing features or problems with the installation procedure? CC NixOS/darwin-maintainers |
I believe M1 Macs support only Big Sur. |
|
Another minor thing that is broken because of this is zig see PR Regarding Apple SDK |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
I hit an issue on an m1 and my intel BigSur machine relating to dylibs not found. I commented with my findings on the issue for this here: #80177
|
|
Does anybody know what broke This is needed for this pr #106465 and possibly related to #119866. |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/missing-go-1-17-on-x86-64-darwin/15032/3 |
|
It would be nice if there was a quick explainer of how to potentially integrate Nix into a MacOS VM that is acting as the CI runner. Mac OS runners are appearing in gitlab and github and more. However the current installer script requires
|
|
The nixpkgs manual itself has an ios section, but there's no equivalent section to building GUI apps. The ios section says that it has to "symlink" to the natively installed XCode. It would be nice to explain this in more detail. |
|
This is from May, any updates? I tried to |
|
@MichaelVoelkel I created a ticket to track that one specifically: #188938 |
Status of macOS support in Nixpkgs
Most of this information is based on the Nix ❤️ macOS Open Collective wishlist and the Darwin maintainer tracking project.
Apple SDK update
Current stdenv uses Apple SDK version 10.12. This means binaries built by Nix and cached in the official binary cache run on all versions of macOS since 10.12. Updating the version of the Apple SDK used in the darwin stdenv means dropping support for any Apple hardware that cannot be upgraded to the corresponding version of macOS.
Issue #101229 makes it clear that updating the SDK is becoming a pressing concern. Some important packages require a version newer than the oldest supported by Apple, like CPython #105038 and Qt WebEngine 5.15 (Qt 5.12 will be EOL in December 2021 so we want to move to Qt 5.15), both requiring 10.15. In issue #86299 the required version is 10.13.
Some work has already been done to ease the transition to a newer SDK. Basing stdenv on Text API, which is unavoidable as of 11.0 Big Sur, in #98541. And making it possible/easy to update packages in apple_source_releases individually, in #108590.
Another factor in this decision are the Hydra build machines. There are currently 9 Intel Mac Minis, NixOS/foundation#5, and 6 Apple Silicon Mac Minis, #95903. All but the oldest support the latest version of macOS. The oldest Mini supports up to 10.15 Catalina.
(OfBorg has recently gotten much needed expansion of hardware to help maintainers verify Darwin fixes. There's five extra Darwin builders NixOS/infra#179.)
What is the way forward? Do we package every SDK version and then default to the oldest supported but make it possible for packages to specify the minimum version they require? Do we focus on source releases instead, to limit the reliance on the SDK?
✅ Installation tutorial
Due to changes in Catalina which locked down the filesystem root, mounting it read-only, installation has gotten less straightforward. It currently requires a separate non-encrypted APFS volume, as of NixOS/nix#3212.
I will go through the installation process and write up a detailed tutorial to minimize friction for new users. Including setting up nix-darwin and home-manager. This will probably simply repeat information that's already out there in various blog posts but in more detail, potentially going over alternatives. I have a draft in a Gist. Installation's actually a fairly simple process so the uninstalling information is the biggest contribution.
Is there other documentation that is known to be missing or in need of improvement?
✅ Bootstrappable stdenv on Big Sur
With the Text API stdenv builds on Big Sur are possible but during the bootstrap it still requires linking to an actual libSystem. This means the stdenv was only usable on Big Sur as long as a bootstrap was generated on Catalina or earlier. This issue is described in #104580 but should be fixed by #107013.
✅ Apple Silicon Support
The next big hurdle is support for the new Apple Silicon (aarch64) CPU architecture. Several M1 Mac Minis are already available for CI, #95903.
Work towards this has been merged in #105026, with accompanying Hydra jobset for detailed progress on which and how many packages build succesfully. The merge happened in time to make it into the 21.05 release! 🎉
Sandbox support
While NixOS sandboxing works well on Linux, on macOS it has been plagued by problems for a long time, NixOS/nix#1821. Among other things the limitations of macOS's sandboxing framework as compared to Linux make it difficult to achieve the same degree of sandboxing.
Recently confirmed broken in NixOS/nix#4658. Currently only one blocker is identified for this, namely NixOS/nix#4119, the sandbox files that are generated have too many rules, splitting them up and importing seems like a potential fix.
Is perfect the enemy of good enough here? Can we gradually introduce sandboxing on macOS, incrementally tightening down on the simplest measure to take next? Or do we need a thorough design from the ground up, which may result in a different approach to sandboxing from NixOS?
Runnable NixOS tests
Making it possible to interactively run NixOS VMs on macOS has an unexpected advantage, #108984. Linux runners on CI providers like Circle CI and GitHub Actions cannot use KVM so NixOS tests are slow to run. Their macOS runners otoh do have access to macOS's KVM alternative, so running NixOS test VMs on macOS CI runners could provide a nice speedup. There is now a working prototype by @r2r-dev. Qemu is starting to rely on newer SDK versions which could mean this gets blocked on x86_64 Darwin until we can bump the SDK to 10.14.
✅ Installer improvements
Current work to enable the installer to encrypt the Nix store volume if FileVault is enabled is complete, merged in NixOS/nix#4289. This PR and changes that have been previously merged will probably fix zsh-specific compatibility issues that have cropped up.
@abathur also mentioned it might be possible to have the installer check a user's shell rc files for things that may cause issues, the use of absolute paths posed a problem for someone during install. And that these changes will make an uninstaller feasible. The changes include detecting and fixing problems with volume state, think permissions or whether the volume is encrypted if FileVault is enabled (potentially after installing Nix). This goes most of the way towards making the installer idempotent and an uninstaller would mostly deal with the same things.
An apt summary of the work in this PR by abathur, "The goal is to remove any macOS-specific asterisks on the install step for Nix." Uninstallation and reinstallation should be easy, the former should lower the barrier to trying out nix and the latter allows for people to start over, taking away the stress of getting everything right the first time.
Nix 2.4 has been released and includes the work by abathur.
Are there other missing features or problems with the installation procedure?
Uninstall and Reinstall
Supporting re-running the installer and being able to easily remove Nix would be a large quality of life improvement for new users who may be hesitant to give Nix a shot because they don't want to mess up their system or because an earlier installation attempt went awry. This discourse thread has more details.
Support headless setups (VMs/EC2)
Some users have run into problems with headless setups, like in well documented issue NixOS/nix#4640. The only workaround so far involves getting a remote desktop session going and granting FDA permissions to
/bin/sh, which the Nix daemon inherits, through the GUI and giving the account that needs to mount the Nix Store APFS volume a SecureToken.Ruby across Darwin versions
#160103 highlights a problem with the current infrastructure for Ruby. The platform identifier ends up in the interpreter binary and causes it to refuse to run after a system update. Ruby should be rebuilt when this happens, as if the system it runs on is an input to the expression.
CC @NixOS/darwin-maintainers
Last updated: 2021-12-07
The text was updated successfully, but these errors were encountered: