1. 75
  1. 17

    Excellent! I love that it’s enabled flakes by default. The choice of Rust over shell in this case is pretty choice, too. Mac ships an appallingly old bash that is wildly different from … every Linux distribution today.

    Can’t wait to try it. Does it work on FreeBSD?

    1. 11

      Unfortunately it doesn’t support FreeBSD yet. Nix/Nixpkgs itself has pretty poor support for FreeBSD today, so we didn’t build it out yet. We could definitely add it!

      1. 1

        Freebsd has its own port though.

        1. 1

          I haven’t had a lot of luck getting anything to work. If you have some idea/blog/website of how to bootstrap a new system, I’d love to hear about it. The official docs still download a little tarball of binaries built from a pre-existing nix system, and so far as I can tell, it’s not generally available for FreeBSD.

          1. 1

            I’ve been lurking in the Exotic Nix Targets Matrix room, and it looks like the folks there have been putting a lot of good work into supporting less widespread targets, including BSDs and Illumos, recently. That room might be worth joining if you’re interested in those developments :)

      2. 15

        Thanks for pushing this forward with a maximum of community engagement. Regardless of whether your particular Rust codebase replaces the upstream installers, I think that the concept of an “installation receipt” is a great idea that should be adopted upstream.

        1. 7

          Thanks, Corbin! I’m really glad to hear that :). We like it, too… props to Ana for raising the idea.

          1. 3

            I like it too! Come to think of it, it’s a lot like file system journals, isn’t it? At least, that’s the first thing it reminded me of, and I believe it’s designed to solve a similar problem.

        2. 14

          Although flakes and the unified CLI remain experimental features of Nix, we’re confident that new users should adopt them now and that more seasoned Nix users should make the transition ASAP.

          I’m a Nix user of 8 years. I avoided Nix Flakes until about 2 weeks ago. I wanted to wait for stability and I didn’t see any critical benefits.

          Big things I did get out of adopting flakes:

          • Conventions (e.g. hydraJobs, nixosConfigurations, etc)
          • More caching (i.e. can’t use NIX_PATH based timed caching - has to be in flake.lock)
          • More determinism (e.g. no builtins.currentSystem)
          • Easy to see all Nix inputs (e.g. helps with accidentally using different versions of nixpkgs)
          • Commands to manipulate inputs (I.e. you don’t have to know Nix to update nixpkgs in a project)

          I can definitely recommend starting to use flakes if you haven’t already. It’s a pretty good feature!

          1. 5

            Yeah – flakes was a big reason I finally managed to finally get into Nix. They aren’t perfect and still can be somewhat intimidating, they’ve made things much more approachable in my opinion, especially in combination with the unified nix command.

          2. 7

            nice! the zero to nix guide helped me understand nix a lot more then i did 2 weeks ago so thank you for that :D

            1. 6

              I am so happy to hear that! Thank you for saying so!

            2. 5

              Where would I make use of nix? Day to day I don’t even really touch apt all too much other than to update things. The main place where I do installations where this would seem relevant is in Dockerfiles - is that the intended use case?

              1. 16

                There are many “levels” at which Nix can be useful, for example:

                • you can install it and use it to manage software in container images as @wimpress suggests, if you’re using Dockerfiles to “test the waters” or need to be compatible with other components that only like Dockerfiles;
                • you can build Docker images entirely within Nix, making reproducing images easier and (often) resulting in more compact images;
                • you can use it to manage the everyday software you use on your workstation, simply by installing the software using Nix or by installing and configuring it using home-manager;
                • you can use nix run to try out software without worrying about uninstalling it again later;
                • you can put your entire OS together with Nix, as with NixOS or more specialised setups like liminix;

                All of these are options which will appeal to various people to various degrees, and you can pick and choose which ones you’re most interested in!

                1. 4

                  Yes 👍️ You can use the Determinate Nix Installer to “install” nix in Podman and Docker containers.

                2. 3

                  Different Bash implementations have subtle differences that make it hard to eliminate inconsistencies and edge cases—and it’s hard to discover those in the first place because Bash is all but untestable.

                  Am I being gaslit here, or where are the other bash impls than https://www.gnu.org/software/bash/ ?

                  1. 6

                    I would guess that part is talking about disparate platform and version number combinations of Bash, unless I am also uninformed on some other indie Bash impl

                    1. 8

                      I agree that it’s speaking a bit loosely about platform/version differences, plus utility/env differences.

                      For example, here’s a dumb edge-case we hit in the official installer around a bug in the bash that ships with macOS: https://github.com/NixOS/nix/pull/5951

                      Another recent example was that the installer was using rsync for ~idempotently copying the store seed into the nix store. Debian, iirc, lacked rsync, so someone changed it to a cp command. But the flags weren’t supporting an idempotent copy, so a lot of people started getting hard errors during partial reinstalls that would’ve otherwise worked.

                      We’ve also run into trouble recently because the platforms we were supporting were all using GNU diffutils. I took advantage of some of its flags for formatting less-programmer-centric diffs for some state-curing actions, and then macOS Ventura promptly dropped gnu diffutils for their own homegrown version without these flags.

                    2. 1

                      Just different versions. macOS ships with Bash 3.0, which is 10+ years old and has subtle bugs around empty arrays and other areas.

                      1. 1

                        My Mac install nags me to move over to zsh. I just use bash as a launcher so don’t really care.

                    3. 3

                      I couldn’t run it with single user mode. A hard pass for me as multi user mode causes a lot of problem (user number Id) where I work. Will check back in after they support it.

                      1. 3

                        curl –proto ‘=https’ –tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s – install

                        Can we please please stop this

                        1. 23

                          we’ve had this discussion before, it always comes full circle:

                          What is your solution to improve upon this shell piping ?

                          • Verify Checksum: Coming from the same source, you have to trust them
                          • download a .deb: Coming from the same source, you have to trust them and they have to provide a ton of different package formats
                          • apt install: it’s new, there is no shipped version
                          • docker: this isn’t made for docker - also docker doesn’t mean security
                          • VM: neat, but how do I get from the “vm” testing step to my actual installation ? I could just pipe this shell command in the VM anyway, so no need to provide a VM image (which format?).
                          • snap/flatpack/appimage.. which one of them, are they even useful for this installer ? also you’re still trusting the authors and now the snap servers too

                          You can only argue that downloading it to disk and then executing can leave a trace on the disk, so you can inspect the malware later on. We’re still downloading debian ISOs straight from the host, not that big of a difference. And I bet no relevant percentage checks the signatures or checksums.

                          1. 5

                            I sometimes see:

                            curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix >installer
                            less installer
                            sh installer install
                            rm installer

                            This way the website can’t detect whether it’s being piped to sh, and you don’t get screwed over if the connection fails halfway through.

                            1. 3

                              Downloading it first or putting it at some reliable hosting (where you can’t change the download for specific people by random just through compromised developer hosts) is definitely one step better. But it doesn’t change much in terms of the core complaints: Running shell scripts from the internet.

                              1. 5

                                Well, pretty much all free software boils down to “Running [executable code] from the internet”.

                                The question is whom you need to trust. The connection is HTTPS and you need to trust both, your TLS setup and determinate.systems anyway to use this installer, so not much is left.

                                Getting a an external signature/checksum would guard you against a compromised web server, but only if you can get that checksum out of band or from multiple, independent sources.

                          2. 18

                            If you need an offline install, or you’d prefer to run the binary directly, head to https://github.com/DeterminateSystems/nix-installer/releases then pick the version and platform most appropriate for your deployment target.

                            1. 13

                              Agree, it’s missing a sudo!

                              1. 7

                                What’s a better alternative?

                                1. 7
                                2. 5

                                  Sure—just as soon as all software is verifiable, which projects like this are an important step towards :)

                                3. 2

                                  Just used this as part of the intro to nix site—worked well!

                                  1. 1

                                    very exciting! I admit, I am a lot more likely to contribute to this than to the official installer, because it’s Rust.

                                    I’m going to have to try this out in a VM just to see how the flow works and everything.