Suppose if caching and compilation service becomes unavailable for whatever the reason, is there any readily available alternative service we can use? How easy is it to compile without the caching services?
I have just read about NPM Surprise NPM layoffs raise questions about the company culture | Packt Hub which makes me not wanting to use any service from them.
Just hypothetically if anything bad happens to current Nix service providers, can we easily switch to a new one?
Suppose if caching and compilation service becomes unavailable for whatever the reason, is there any readily available alternative service we can use? How easy is it to compile without the caching services?
Compilation without caching service: completely transparent, just slower.
Alternative caching services: Cachix does something, might not be prepared for a spike in load. Large Nix users ahve their internal buildfarms and caches for things they care about.
Full-scale alternative buildfarm or alternative large cache or both would need significant resources, and the scenario of cache.nixos.org or hydra.nixos.org is bad but not a complete grind-to-a-halt, so I do not expect people do this just in case. There seems to be a Chinese mirror of a subset of the cache that serves to reduce the number of international transfers (which are slow in China).
Of course, there is also an issue of stdenv bootstrap tools availability, and some upstream source packages have imperfect uptime track record (or just disappear). And I guess some takedown troll could easily temporarily block both GitHub repo of Nixpkgs and the channel CDN. Compared to these, cache is completely optional.
It will probably also lead to some breakage. Some build infrastructure (e.g. buildRustPackage) require hashes of vendored dependencies, these hashes have changed sometimes (e.g. due to changed is cargo vendor). Also, sometimes upstreams replace a tarball in-place with some fix without incrementing the version number. AFAIK in such cases, new builds do not fail, because the old hash is in the cache and it will happily fetch that. Of course, when the cache is blown away, sources will be redownloaded and you may find out that the hashes are not correct.
Anything can happen of course, but I find it comforting that Nix/NixOS/nixpkgs is backed by a non-profit foundation (Stichting NixOS), so they will always have the Nix ecosystem at their best interest. Also, anyone can help out to ensure that the foundation has enough funding.
< /commercial block>
Also, sometimes upstreams replace a tarball in-place with some fix without incrementing the version number. AFAIK in such cases, new builds do not fail, because the old hash is in the cache and it will happily fetch that.
… although tarballs.nixos.org is hash-addressed and sometimes also helps with upstream tarball replacement (but it is annoying either way)
Note that there are quite a few angles you can see the layoffs.
While it’s hard to say about company culture given that new leadership was set up, it is clear that they got inside information just a few months before github launched packaging service that they will need to lay off people since github is going to take majority of their customers.
Travis CI was basically the same story.
While companies come and go, the way it was done is clearly not how it could be.
Back to caching discussions:
I recommend cachix depending on the size of your cache since it’s pretty easy to get started.
I did however write an article on how to setup caching with S3; it was fairly straightforward
Fwiw that link has moved to setting up a Nix S3 binary cache | Farid Zakaria’s Blog
Thanks for writing that guide