It’s still helpful to eg fold different phases in Nix, and different derivation output.
I work on garnix.io, which is exactly a Nix-based CI alternative for GitHub, and we had to build a lot of these small things to make the experience better.
We also do something similar at garnix, but when enabling incremental builds. Instead of just skipping the build stage, we also “normalize” the eval into just the store path, and skipping it the second time around.
Mentioned in passing in https://garnix.io/blog/incremental-builds. This is even more significant because in this case you might otherwise be eval-ing several layers of flakes.
You might be too deeply scarred to come close to it, but we just wrote a blog post about deploying NixOS servers without installing nix locally or provisioning work here that feels relevant: https://garnix.io/blog/hosting-nixos
if anyone is afraid of this happening to them, I'd recommend the deterministic nix installer. it has an atomic installation process where each step is reversible with the uninstaller. This is uniquely a macos issue since the setup is a bit different to other OS's in terms of creating a read only filesystem for the nix store, but the determinate installer was built to fix any worries of that happening.
can vouch for the detsys installer, and anecdotally, the resulting nix install seems more resilient across os updates. on a similar note, nix-darwin is a must-have. the typical nix-env stuff you see in introductions to nix on non-nixos systems really sells it short, as it feels like just another package manager to keep track of. by contrast, nix-darwin brings the centralised configuration.nix approach, which makes it way harder to hose your environment.
I looked at the docs, and it seems promising but I’d like to do something like: `garn add --dev git@2.3` and have git added at the given version as a dev tool. With config-as-code, is it possible?
It’s to allow interpolation of packages and environments. But in practice we don’t use it that often, so we were thinking of switching the main function to using just a second string argument. (In other words, I agree.)
import * as garn from "https://garn.io/ts/v0.0.14/mod.ts";
import * as pkgs from "https://garn.io/ts/v0.0.14/nixpkgs.ts";
export const main: garn.Executable = garn.shell`${pkgs.jq}/bin/jq --version`;
Put that in a 'garn.ts' file and run 'garn run main' and you should see the version of 'jq' that you can get from our 'nixpkgs' module.
But yeah, I completely agree with the sentiment here. This is a rather cumbersome syntax to support a use-case that we don't even have examples for. So clearly the normal usage shouldn't force you to use template strings.
This is coming from David Sinclair, who claimed resveratrol was the fountain of youth (it wasn't, but he still managed to sell his resveratrol company for hundreds of millions), and pushed rather hard also on NAD/NMN despite only very preliminary and limited results (he also has interests in NMN companies, and has been involved in removing it from the supplement market in favor of that company's right to market it as a drug). More likely than a cure for aging, Sinclair just found another cure for too few cars in his garage.
“ This is the first study showing that we can have precise control of the biological age of a complex animal; that we can drive it forwards and backwards at will”
And the paper doesn’t show that at all. The paper does not show them reversing the aging of anything.
I couldn't get access to the paper, but the abstract and the article both claimed they were able to reverse organ damage caused by the aging. Is that not backed up in the paper?
He is a professor at Harvard - I imagine he wouldn't get to that role if the science didn't have some merit.
Where did he ever say that resveratol was the fountain of youth? Interviews I've seen with him seem more reasonable then I always hear people make him out to be.
NMN does have some promising results based on recent studies- what do you mean he pushed hard? Where did he actually do that?
Andrew Huberman does take and talk about certain medications and supplements which haven't yet been proven effective. However, he has always been completely clear about what the science does and does not say so that people can make up their own minds. He has also consistently been open and ethical about conflicts of interest.
Without any doubt—The NIA Interventions Testing Program. They have 20 years of experience on effects of dietary interventions supporting longer lifespan.
There are lots of advantages and disadvantages to both, and use cases where one or the other shines. A proper response would probably be a blog post in length, but in brief, I find that Nix really makes everything explicit. You can see the source code and it reflects everything that went into a build; you can also control every bit of it. It is, however, consequently generally more verbose, and also requires a bit more learning. Nix also tends to compose much more cleanly than docker.
Maybe an analogy: nix is a package-lock.json. Docker is a package.json (with no version bounds) and a node_modules directory. You can just copy that node_modules directory around so everyone has the same setup, but it's much harder to introspect than a lock file, and the way you go about updating it is deleting the folder and rebuilding everything - no fine-grained control over one specific dependency.
