* Document nix version pinning more explicitly
https://github.com/DeterminateSystems/nix-installer/issues/387#issuecomment-1581743074
Co-authored-by: Ana Hobden <operator@hoverbear.org>
* Fixed a single typo in README.md
* Link to nixos.org to explain Nix
* README: Delete now-incorrect link listing installed `nix` versions
---------
Co-authored-by: Peter Kolloch <peter.kolloch@nexxiot.com>
Co-authored-by: Ana Hobden <operator@hoverbear.org>
Co-authored-by: Mikko Lukas Räsänen <1522239+mikkolukas@users.noreply.github.com>
Co-authored-by: Mauricio Scheffer <mauricioscheffer@gmail.com>
Co-authored-by: Ilya Grigoriev <ilyagr@users.noreply.github.com>
* fix: workaround for lies from uname -m
On an arm64 mac, `uname -m` returns x86_64 which causes install script to install with the wrong architecture
* refactor: use same logic from rustup
* Tweak credit comment
* Prod ci
---------
Co-authored-by: oz <otech47@gmail.com>
* Fetch updates from i.d.s by default
Our goal is to deliver a solid experience with Nix flakes, including an upgrade path that is safe. Occasionally, the upstream Nix project may introduce regressions for the common flake path. This is not desirable for our users, who depend on a consistent and stable flakes experience.
Additionally, the Nix project isn't directly responsible for delivering updates to users as that role is delegated to the Nixpkgs project.
Overall, this means upgrades are not consistently delivered to users.
This update directs future update requests to install.determinate.systems, which we will upgrade as part of our standard release process.
Our standard release process includes proactive testing: validating our installer and Nix's behavior across a wide variety of platforms and scenarios.
After an update passes our proactive validation, we do a phased rollout of reactive monitoring: the update is released to a small percentage of users on GitHub Actions. We monitor the failure rate of the installer and overall workflows to ensure the updated Nix isn't causing widespread failure we weren't able to identify ahead of time.
Only after a release passes both proactive and reactive validation, our macOS .pkg and nix-upgrade paths are bumped to the most recent release. This gives user the confidence they're looking for that the Nix release they're getting is safe.
* Universal -> universal
* clippy: unnecessary guard
* create merge nix config clippy nit, old
* Clean up a clippy nit on an extra clone
* clippy nit legacy wsl detection error
Making everything 0o555 is too much, since many files in the store
are not supposed to be executable. Those should be 0o444. Instead
of splatting 0o555 out, take a more measured approach and remove
the writable flag from the on-disk mode.
* Support remote-building to macOS hosts
Our README has long featured a snippet to add to the zshenv, with a
caevat that it might behave strangely if you're writing a script with an
empty PATH.
It is pretty straightforward to eliminate those caveats while still
providing remote building for Nix to macOS hosts.
Co-authored-by: Ana Hobden <operator@hoverbear.org>
Qyriad
ktemkin