3 ms·

This looks good. I know I'm about to speak towards the OS version and not the Nix that can run atop other distros, but I definitely had some hiccups on the way

This looks good. I know I'm about to speak towards the OS version and not the Nix that can run atop other distros, but I definitely had some hiccups on the way to my NixOS-on-ZFS-root install (1), such as the configuration of the root user, whether to declaratively or dynamically configure non-root users and wifi networks (and having a working wifi driver that worked with my onboard chip to begin with... I truly believe that linux installs should not be expected to have to bootstrap via Ethernet at this point). Admittedly, a few of these things were due to not using the official GUI installer, but IMHO the commandline non-GUI install of NixOS should be as painless as possible as well. (1) https://openzfs.github.io/openzfs-docs/Getting%20Started/NixOS/Root%20on%20ZFS.html https://openzfs.github.io/openzfs-docs/Getting%20Started/Nix... Regarding your argument against Bash, isn't it true that this is just a different version of the same bootstrapping problem, and that downloading a temporary but specific Bash version would get around that? (I agree that working with Bash leaves a lot to be desired. But it's also more accessible to end-users to hack on, observe, and learn from, than a compiled Rust binary is. And tools like Copilot and ChatGPT and https://www.shellcheck.net/ https://www.shellcheck.net/ make working in Bash MUCH more painless, I've found.) Couple more questions: 1) Is your installer idempotent? (I think it is, since you track what's been done in a JSON structure; just confirming! If the JSON file is lost, are you still idempotent though? lol) 2) Are you a profitable company or just a group of Nix believers?

deleted 4y ago
[deleted]
grhmc 4y ago
Whew, let's go. On NixOS: I generally agree, though it can be tricky to get that done with NixOS. I bet we can make some inroads there. Easy questions: > idempotent It isn't currently idempotent, but we're working on "curing" which brings some idempotency to it, and allows for "rescuing" installations that aren't working correctly. Curing will also support creating a JSON document for installs that don't already have one. > profitable company or just a group of Nix believers We are a for-profit company, and we are a group of Nix believers :). Bash: Bash is really hard to get right, and really hard to make fast, and really hard to extend its featureset to more complicated use cases. We could "just" download a bash, but when we're trying to navigate disk encryption and APFS volumes and mounts ... it is quite a lot easier to write and test that code in a "bigger" language. Also note that it isn't just Bash that we'd need to download, but coreutils and other utilities that Bash is really built on top of. We tried to fix a pretty simple bug last year in the Bash installer, and it took two weeks to validate a relatively straightforward, one line change was valid on all the platforms we target.
- aidenn0 4y ago
  > Also note that it isn't just Bash that we'd need to download, but coreutils and other utilities that Bash is really built on top of. We tried to fix a pretty simple bug last year in the Bash installer, and it took two weeks to validate a relatively straightforward, one line change was valid on all the platforms we target. This clarifies a lot of what confused me in TFA. I maintained millions of lines of bash code, some of which is decades old and run into only a single bash incompatibility that wasn't fixable with shopt. On the other hand, incompatibilities in programs bash is running are rampant, particularly between GNU and non-GNU systems (and even within GNU there are more surprises than you might think). The phrase "different bash implementations" was a major red herring for figuring out what you were talking about.
- pmarreck 4y ago
  Followup question then: Are you hiring? :) What type of work do you do? (is it "sysadmin-flavored," etc.?)
  - grhmc 4y ago
    We're working on broadening the use-cases that Nix is appropriate for. Things like https://zero-to-nix.com/ https://zero-to-nix.com/, https://www.riff.sh/ https://www.riff.sh/, and the Determinate Nix Installer's goal is to make installing Nix a "low cost" / "low risk" activity to bring people in. We're always looking for good writers, Rust devs, and security folks. People who are in to these things should reach out with their resume: careers@determinate.systems. Note that existing Nix expertise is not required.
- vinceguidry 4y ago
  > but coreutils and other utilities that Bash is really built on top of This really is the problem with bash. It doesn't have a stdlib. Posix tried but didn't succeed in sufficiently standardizing userlands. Bash is friendly and easy to hack on, but hard to manage at scale, for this reason. And this crops up all the damn time when you're working with compiled languages. Nobody wants to have two languages. But if one of your languages is compiled, then nobody wants to write and maintain literally everything in that language. At some point you need scripting. Bash is usually what's reached for. But OSX doesn't ship a recent bash. And your coders are probably running OSX. So you have to write scripts that target ancient bash so the devs can work locally, but also work in the cattle farm. You'll spend lots and lots of time fighting it. Or have ridiculous 'setup' docs that will trip up newbies and you'll have to troubleshoot their setups when they inevitably not follow them right or they just don't work leaving their personal systems in an unknown state. Or just, yannow, use a scripting language to script with instead of a shell. Or, hear me out here, use the 'scripting' language to build your whole app. You very very very probably can. Ruby's object oriented and is way friendlier than bash, ditto for Python.
abathur 4y ago
> Regarding your argument against Bash, isn't it true that this is just a different version of the same bootstrapping problem, and that downloading a temporary but specific Bash version would get around that? (I agree that working with Bash leaves a lot to be desired. But it's also more accessible to end-users to hack on, observe, and learn from, than a compiled Rust binary is. And tools like Copilot and ChatGPT and https://www.shellcheck.net/ https://www.shellcheck.net/ make working in Bash MUCH more painless, I've found.) I haven't been working on the detsys rust installer, but I think I'm the person who's contributed the most to the official bash multi-user installer since Graham did a lot of work on it several years ago. I ~like Shell, and I share your concern about it being less hackable. But the project has also been slowly bleeding goodwill around the lack of clean uninstall/reinstall for years, and I will make my peace with the compromises it takes to get there. The problem isn't so much conjuring good shell expressions. Nix leans a lot on Shell, and I feel like the community has a fair number of people around who know Shell fairly well. The problems are more like: - limited/tedious support for robust error-handling and recovery - needing a significant amount of new code to handle removing what Nix adds (even though I've done a lot of work to develop the patterns to support eventually getting here) - a fairly fat long tail of problems caused by things like edge-case environment/state differences (due to platform, due to users having surprising environments, etc.) and even flaky behavior on some systems - screwing up the installer is fairly high stakes (and it's very common for even one-line changes to break the installer in some way for someone somewhere and end up needing to get reverted for a rethink) - testing the installer is tedious (it's gotten a lot better over the past ~2 years--but that testing is also just covering the golden path), so iterating is slow - writing and reviewing installer changes tends to entail (and sometimes suffer from a lack of) really broad knowledge of different platforms, shells, utilities, options, permissions, and user configuration ~patterns Because the stakes are high and review is hard and testing is hard and iterating is slow, IME most of the people who are enthusiastic about working on it are naive about these headwinds. This might lead them to, say, submit a PR bigger than anyone will have the stomach to review/merge--or not have the time/energy to slog through weeks/months of review/edit/test iterations it takes to build high confidence in a big change. It's also a big drag on the number of people who have the stomach to continue making substantive installer PRs after they land one. Before detsys started looking at the rust installer, I had picked at a POC for just bundling a bash and everything we touch (iirc at least coreutils, diff, patch). If their effort failed, that's definitely the approach I was going to recommend next to reduce the frequency with which we get bitten by a utility quirk/change. But that still would've left quite a bit of work to do to support uninstall and idempotent reinstalls. I'm personally limiting the amount of non-fix work I do on the official installer to avoid falling into its gravity well and completely owning it. Once more, if any combination of the technical changes here are sufficient to multiply the number of people willing and able to touch the installer, I'll make my peace with the tradeoffs.

deleted 4y ago

[deleted]

grhmc 4y ago

Whew, let's go. On NixOS: I generally agree, though it can be tricky to get that done with NixOS. I bet we can make some inroads there. Easy questions: > idempotent It isn't currently idempotent, but we're working on "curing" which brings some idempotency to it, and allows for "rescuing" installations that aren't working correctly. Curing will also support creating a JSON document for installs that don't already have one. > profitable company or just a group of Nix believers We are a for-profit company, and we are a group of Nix believers :). Bash: Bash is really hard to get right, and really hard to make fast, and really hard to extend its featureset to more complicated use cases. We could "just" download a bash, but when we're trying to navigate disk encryption and APFS volumes and mounts ... it is quite a lot easier to write and test that code in a "bigger" language. Also note that it isn't just Bash that we'd need to download, but coreutils and other utilities that Bash is really built on top of. We tried to fix a pretty simple bug last year in the Bash installer, and it took two weeks to validate a relatively straightforward, one line change was valid on all the platforms we target.

aidenn0 4y ago
> Also note that it isn't just Bash that we'd need to download, but coreutils and other utilities that Bash is really built on top of. We tried to fix a pretty simple bug last year in the Bash installer, and it took two weeks to validate a relatively straightforward, one line change was valid on all the platforms we target. This clarifies a lot of what confused me in TFA. I maintained millions of lines of bash code, some of which is decades old and run into only a single bash incompatibility that wasn't fixable with shopt. On the other hand, incompatibilities in programs bash is running are rampant, particularly between GNU and non-GNU systems (and even within GNU there are more surprises than you might think). The phrase "different bash implementations" was a major red herring for figuring out what you were talking about.
pmarreck 4y ago
Followup question then: Are you hiring? :) What type of work do you do? (is it "sysadmin-flavored," etc.?)
- grhmc 4y ago
  We're working on broadening the use-cases that Nix is appropriate for. Things like https://zero-to-nix.com/ https://zero-to-nix.com/, https://www.riff.sh/ https://www.riff.sh/, and the Determinate Nix Installer's goal is to make installing Nix a "low cost" / "low risk" activity to bring people in. We're always looking for good writers, Rust devs, and security folks. People who are in to these things should reach out with their resume: careers@determinate.systems. Note that existing Nix expertise is not required.
vinceguidry 4y ago
> but coreutils and other utilities that Bash is really built on top of This really is the problem with bash. It doesn't have a stdlib. Posix tried but didn't succeed in sufficiently standardizing userlands. Bash is friendly and easy to hack on, but hard to manage at scale, for this reason. And this crops up all the damn time when you're working with compiled languages. Nobody wants to have two languages. But if one of your languages is compiled, then nobody wants to write and maintain literally everything in that language. At some point you need scripting. Bash is usually what's reached for. But OSX doesn't ship a recent bash. And your coders are probably running OSX. So you have to write scripts that target ancient bash so the devs can work locally, but also work in the cattle farm. You'll spend lots and lots of time fighting it. Or have ridiculous 'setup' docs that will trip up newbies and you'll have to troubleshoot their setups when they inevitably not follow them right or they just don't work leaving their personal systems in an unknown state. Or just, yannow, use a scripting language to script with instead of a shell. Or, hear me out here, use the 'scripting' language to build your whole app. You very very very probably can. Ruby's object oriented and is way friendlier than bash, ditto for Python.

abathur 4y ago

> Regarding your argument against Bash, isn't it true that this is just a different version of the same bootstrapping problem, and that downloading a temporary but specific Bash version would get around that? (I agree that working with Bash leaves a lot to be desired. But it's also more accessible to end-users to hack on, observe, and learn from, than a compiled Rust binary is. And tools like Copilot and ChatGPT and https://www.shellcheck.net/ https://www.shellcheck.net/ make working in Bash MUCH more painless, I've found.) I haven't been working on the detsys rust installer, but I think I'm the person who's contributed the most to the official bash multi-user installer since Graham did a lot of work on it several years ago. I ~like Shell, and I share your concern about it being less hackable. But the project has also been slowly bleeding goodwill around the lack of clean uninstall/reinstall for years, and I will make my peace with the compromises it takes to get there. The problem isn't so much conjuring good shell expressions. Nix leans a lot on Shell, and I feel like the community has a fair number of people around who know Shell fairly well. The problems are more like: - limited/tedious support for robust error-handling and recovery - needing a significant amount of new code to handle removing what Nix adds (even though I've done a lot of work to develop the patterns to support eventually getting here) - a fairly fat long tail of problems caused by things like edge-case environment/state differences (due to platform, due to users having surprising environments, etc.) and even flaky behavior on some systems - screwing up the installer is fairly high stakes (and it's very common for even one-line changes to break the installer in some way for someone somewhere and end up needing to get reverted for a rethink) - testing the installer is tedious (it's gotten a lot better over the past ~2 years--but that testing is also just covering the golden path), so iterating is slow - writing and reviewing installer changes tends to entail (and sometimes suffer from a lack of) really broad knowledge of different platforms, shells, utilities, options, permissions, and user configuration ~patterns Because the stakes are high and review is hard and testing is hard and iterating is slow, IME most of the people who are enthusiastic about working on it are naive about these headwinds. This might lead them to, say, submit a PR bigger than anyone will have the stomach to review/merge--or not have the time/energy to slog through weeks/months of review/edit/test iterations it takes to build high confidence in a big change. It's also a big drag on the number of people who have the stomach to continue making substantive installer PRs after they land one. Before detsys started looking at the rust installer, I had picked at a POC for just bundling a bash and everything we touch (iirc at least coreutils, diff, patch). If their effort failed, that's definitely the approach I was going to recommend next to reduce the frequency with which we get bitten by a utility quirk/change. But that still would've left quite a bit of work to do to support uninstall and idempotent reinstalls. I'm personally limiting the amount of non-fix work I do on the official installer to avoid falling into its gravity well and completely owning it. Once more, if any combination of the technical changes here are sufficient to multiply the number of people willing and able to touch the installer, I'll make my peace with the tradeoffs.