> Even if you can (ideally) pull a path from a cache instead of building it, you still have to pay Nix’s evaluation tax in determining the derivation’s store path in the first place. [...] Fortunately, FlakeHub now offers an elegant solution to this problem: resolved store paths.
If I may paraphrase:
> [fundamental problem with Nix] -> [proprietary solution].
Cachix and nixbuild feel like they're solving something at a different layer. They fit into the existing Nix ecosystem (binary cache, builders) and just provide a hosted version of an existing concept. They don't change anything fundamental about Nix.
I don't object to the product, I object to DetSys moving CppNix into more of an de-facto open core product[1]. This is just a symptom. DetSys contributes the majority of the code that actually gets prioritized and merged (because the maintainer is a DetSys employee), but asking them to build better caching mechanisms into CppNix (which, to be clear, I never asked, that's just Luc's strawman of me) instead of their proprietary product is suddenly "asking Eelco to work for free".
Sure, but you seem to sidestep the primary accusation that Nix itself got neglected in favor of DetSys. Which is most certainly true for at least the installer.
I don't get this argument. It is clear that if it wasn't for DetSys making a better installer, we wouldn't have one, period.
And now there is some movement from NixOS to bring the new installer as a replacement of the old one: https://github.com/NixOS/experimental-nix-installer. It doesn't seem that Eelco or anyone in CppNix is actively trying to sabotage the improvement in the installer, but they simple don't care enough to improve the situation (that is fair enough, I assume most in the core team use NixOS).
The expectation seems to be that Eelco work on Nix full time for free lest he be accused of neglect. Is there a way for Eelco to make money that you would approve of?
I would've replied to you but HN's intransparent timeout mechanism hit me.
I'd invite everyone to wonder why Lix exists (and is better enough to be used in some parts of Nix's CI now), why CppNix stable was stuck 6 versions behind on nixpkgs until half a year ago, and what kept Lix contributors from working on CppNix instead. Tip: "I want free labor from Eelco" is not the answer.
Nobody said this. I suggest that you not escalate the discussion in this direction. You're obviously biased given involvement with detsys, nobody expects you to think differently. This crass dismissal off the issue with a strawman isn't right.
Unfortunately, it's really hard to generalize. If the evaluation involves Nixpkgs, for example, Nix needs to copy Nixpkgs into the Nix store, which is many MB. And of course this needs to happen for all flake inputs. I've seen this evaluation take a few seconds and I've seen it take several minutes, but in general the more flake inputs the longer you can expect it to take.
Using flakes or not, any store path evaluation involving Nixpkgs is going to be computationally intensive, potentially too intensive for a memory-constrained device.
From my understanding of messing with Mastodon a bit, users can "subscribe" to other servers in the 'fediverse'. The proposed personal instance can act as a "Home" server and is a part of your handle in a way. It almost functions like a sub identifier. You can browse and interact all throughout the fediverse on a number of topics, while linking people back to the server you came from during engagement.
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.
