> bubbles are notoriously unpredictable and generally don't happen when they are loudly and widely proclaimed to happen any minute now.
Is that true? It seemed to me that the most common opinion before the recent Chinese real estate crash was that it was a bubble; architect friends of mine who worked in China said the government had no doubt prices were unreasonably high; the thing they remained hopeful about is whether a soft landing was possible. Similarly it seems like it was by no means an uncommon opinion in the Japanese asset bubble, NFTs, beanie babies, and even the dotcom boom that this is (to use Greenspan’s phrase leading up to the dotcom bubble) “irrational exuberance”.
Thomas Aquinas believed cruelty to animals was wrong not because animals have souls (and with that all the standard moral rights), but because it can teach us cruelty to other humans.
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
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.)
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.
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.
You need to get caching right if the builds aren't going to take forever, which is a bit of work, especially since smart GC is hard, and it can be slow (the nix store gets big very quickly!). Then you also would ideally provide that cache (as a nix store cache) for yourself and others, so you don't have to rebuild it. But GH Actions doesn't do that, so you need to find a way on your own, or pay for a service like Cachix. Pushing the nix cache can be quite slow. Then the logs are formatted in a very nix-unaware way, which makes it hard to find what you want. And Github doesn't yet even have M1 Mac VMs, so you would get to test/cache that. (I think it's also not possible to do other architectures, like aarch64.)
Also, for whatever reason (in addition to the specific ones above), GitHub action runners are just slow...
In short: garnix is faster, has more features, and is easier to set up.
I do care. I also was born in a developing country. (Though the correlation between development of country and proportion of green/renewable energy usage is I think quite low (and might not even be positive?) [0].)
I think access to software and services shouldn't be be based on the country you happen to live in, and I wouldn't want to contribute to that. But I would have thought either using a hosted service, or else self-hosting in a different country, are almost always options. Why is hosting CI on the other side of the planet for you a no-go?
(Also, I think right now a license that simply says "must be run with renewable energy" is infeasible almost everywhere still.)
I think you're absolutely right that there are nuances such as what you described. More: I imagine there are very few offices/homes that run completely on clean energy - in the most naive formulation of the license, no one could test the software locally!
Likely first you'd need some progressive system (e.g.: no less than 80% now, no less than 100% by 2030).
But I disagree with you on that people in many countries would not be allowed to use the software - you would still be able to use the service (i.e., visit garnix.io, have it build things), or even host it yourself in a different country. Yes, countries with more green energy (rather than exclusively cheap energy) would benefit. But the countries with high green/renewable energy aren't even primarily rich ones [0], so I don't feel too bad about that.
Note that this argument only applies to services such as garnix, where you can still use the service (so it would be a bad license for, for example, a text editor).
The main difference is that you don't have to host anything. For most people, setting up servers (likely for multiple architectures) is time consuming, expensive, and wasteful (since your server is sitting idle while you/your team sleep).
There are of course situations in which you'd prefer that, though!