3 ms·

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: > ide

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

by grhmc 4y ago

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.