[HN Gopher] Cloudflare R2-Backed Nix Binary Cache on Fly.io
___________________________________________________________________
Cloudflare R2-Backed Nix Binary Cache on Fly.io
Author : bsnnkv
Score : 67 points
Date : 2024-01-17 16:32 UTC (6 hours ago)
(HTM) web link (lgug2z.com)
(TXT) w3m dump (lgug2z.com)
| thomastjeffery wrote:
| Something that's been itching at the back of my mind for a while:
| the nixpkgs binary cache is a perfect candidate for P2P. I wonder
| how hard it would be to put it on bittorrent.
| Nullabillity wrote:
| There was a project a while back to add support for an IPFS
| backend.. not sure what came of it though.
| piperswe wrote:
| Content-addressed derivations are a blocker for proper IPFS
| binary cache support. They're still a work-in-progress.
| Ericson2314 wrote:
| Yeah see what I said in
| https://news.ycombinator.com/item?id=39033274
|
| Though to be fair, there is no reason that experimental
| features cannot depend on other experimental features.
| __MatrixMan__ wrote:
| There's work happening in that direction:
| https://discourse.nixos.org/t/obsidian-systems-is-excited-to...
|
| My impression is that although nix makes it easier to achieve
| repeatable builds, not all nix builds are repeatable. It takes
| some diligence on the part of the package author as well.
|
| Switching nix from an inputs-addressed model to a content
| addressed one may shine a light on this, which will be nice for
| discovering the hidden variables which contribute to
| nondeterminism, but might come with its own headaches re: "why
| do I get a different hash than expected? Is it broken?"
|
| I'm still excited to see it happen, but I think there's a
| certain crowd who might be disappointed that it's not as
| magical as they envisioned it.
| Ericson2314 wrote:
| See https://github.com/NixOS/hydra/issues/838 for making
| content-addressed derivations supported by hydra.nixos.org.
| At that point, we can actually try out the XP feature at
| scale.
|
| Also see https://github.com/NixOS/nix/issues/8919 for this
| accepted RFC
|
| Once those things are done, we can get back to merging in the
| IPFS code.
|
| Now that there is an Nix team and I am on it, there is much,
| much less of an issue of these experiments being caught in
| limbo :).
| hamandcheese wrote:
| Nix derivations are not actually content addressable, at least
| not yet. Derivations are _input_ addressed.
|
| That means that the only way to validate the contents would be
| to take all the inputs and build the derivation yourself,
| defeating the purpose of using the cache. That means that nix
| caches must be trusted to not be malicious, with no
| computationally efficient way to protect against cache
| poisoning.
|
| There is a project underway to transition the nix store to be
| content addressable, which will decouple trust from
| distribution.
| k__ wrote:
| Interesting!
|
| I always had the impression that derivations being content
| addressable was one of Nix' main selling points. For
| reproducibility etc.
| thomastjeffery wrote:
| When that work is done, will it be a strong enough guarantee
| to use instead of just gpg-signing derivations?
|
| The father I dive into Nix, the more I get the feeling that
| nixpkgs is only half of a package manager; and that the other
| half has been perpetually put on hold, while we wait for the
| eventual perfect implementation of Nix to make that half
| implicitly obsolete.
|
| The more I use Nix (especially NixOS), the more I feel like
| that second half of the package manager is precisely what I
| am missing. Even when it it's obsoleted by guaranteed
| reproduciblity, I may still find value in it.
|
| I would love to have a nix store that accommodates
| traditional gpg-signed packages. The usefulness of that would
| extend beyond Nix and nixpkgs.
| Ericson2314 wrote:
| derivations are build plans. derivation _outputs_ you mean.
|
| derivations are always content-addressed.
|
| derivations outputs can be input-addressed or content-
| addressed, but the latter is still an experimental feature.
| tjoff wrote:
| You don't have to do it yourself. Someone you trust need to
| do it, but the distribution itself don't need to be trusted.
| esafak wrote:
| Can you run any DB on R2?
| drexlspivey wrote:
| their R2 DB is called D1
| SteveNuts wrote:
| So could you run DB2 on DB1 backed by R2?
| mulmen wrote:
| No because the service is called D1 and is based on SQLite.
___________________________________________________________________
(page generated 2024-01-17 23:01 UTC)