Ah! You asked about flakes as well. Just saw that. Basically flakes are a construct in Nix that enable you to (a) ensure that your Nix code is always "pinned" to specific revisions of your inputs (for example Nixpkgs but other inputs as well) and (b) to provide a simple and well understood system for sharing Nix code. So this command, for example, enables me to build Tailscale:
nix build github:tailscale/tailscale
I point Nix at an "address" and it knows which set of Nix build instructions to use. Basically that Tailscale repo has a flake.nix in the root that Nix looks at, specifically at the flake outputs. From there, it sees that there is an attribute called "packages" and then it sees that there's a package for the current system called "default," and then it builds that. So Nix expressions have universal "addresses" (they also did before flakes but flakes provide a standard structure for outputs and built-in pinning via flake.lock files).
you lost me at the first sentence. all i understood is that it is a thingamajig that I can manipulate to package the stuff into window Puerto Rico the fox flies over area 54. ok.
I've been meaning to write something pithy on this and this is a great spur to action. Basically Nix is something you use to build software reproducibly, that is, where you can take the same inputs and get the exact same bytes on disk every time you build it. The "software" here could be something simple-ish like a CLI tool or a UNIX utility, and it could be as complex as an entire functioning Linux system, and it could be something that you usually build using other tools, like Docker or Podman containers. Nix can do all of this. I'd say that the things people most often use Nix for are:
1. Project-specific development environments. You want everyone on your team to have the exact same version of Python, jq, Terraform, Cargo, and Bun in a specific project? Nix can do that.
2. Home environments. You want to replace your dotfiles and Homebrew and apt-get with something declarative that you have an actual language for? Nix can do that.
So yeah, development environments, home environments, whole Linux systems, OCI containers, standard packages (like CLI tools), things like VS Code extension, Neovim plugins... all of this stuff can be built using Nix. Pretty powerful stuff.
Osh is stricter than bash. Anything written to osh should run in bash with no issues whatsoever.
Ysh implements new, non-compatible syntax and semantics.
Osh and ysh are two different shell languages from the Oils for UNIX project. The release build generates a single binary, oils-for-unix, and installation creates two symlinks for the two different shell personalities, similar to how the bash binary will behave in its POSIX-compliant mode when it is invoked as sh.
There is no "Oil shell" now, at least not without ambiguity.
