Introducing the Determinate Nix Installer

75

Introducing the Determinate Nix Installer nix determinate.systems
authored by linuxhackerman 3 months ago | archive
Archive.org Archive.today Ghostarchive
| 33 comments

33

17

penguincoder 3 months ago | link

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
  
  grahamc 3 months ago | link
  
  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!
2. 1
  
  pbsds 3 months ago | link
  
  Freebsd has its own port though.
  1. 1
    
    penguincoder 3 months ago | link
    
    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
      
      linuxhackerman 3 months ago | link
      
      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 :)
15

Corbin 3 months ago | link

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
  
  grahamc 3 months ago | link
  
  Thanks, Corbin! I’m really glad to hear that :). We like it, too… props to Ana for raising the idea.
  1. 3
    
    nil 3 months ago | link
    
    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.
14
puffnfresh 3 months ago | link
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
  
  brendan 3 months ago | link
  
  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.
7

la 3 months ago | link

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
  
  grahamc 3 months ago | link
  
  I am so happy to hear that! Thank you for saying so!
5

insanitybit 3 months ago | link

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
  linuxhackerman edited 3 months ago | link
  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!
2. 4
  
  wimpress 3 months ago | link
  
  Yes 👍️ You can use the Determinate Nix Installer to “install” nix in Podman and Docker containers.
3

ssl 3 months ago | link

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
  
  mat 3 months ago | link
  
  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
    
    abathur 3 months ago | link
    
    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
  
  zimbatm 3 months ago | link
  
  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
    
    gerikson 3 months ago | link
    
    My Mac install nags me to move over to zsh. I just use bash as a launcher so don’t really care.
3

mrbonner 3 months ago | link

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.
3

river 3 months ago | link

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

Can we please please stop this
1. 23
  proctrap edited 3 months ago | link
  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
    gnubison 3 months ago | link
    
    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
      
      proctrap 3 months ago | link
      
      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
        
        phaer 3 months ago | link
        
        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
  
  puffnfresh 3 months ago | link
  
  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.
3. 13
  
  gerikson 3 months ago | link
  
  Agree, it’s missing a sudo!
4. 7
  
  matklad 3 months ago | link
  
  What’s a better alternative?
  1. 7
    
    briankung 3 months ago | link
    
    Just stop…everything https://github.com/kelseyhightower/nocode
5. 5
  
  nil 3 months ago | link
  
  Sure—just as soon as all software is verifiable, which projects like this are an important step towards :)
2

xo 3 months ago | link

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

Irene 3 months ago | link

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.