US dependencies

[inthesquarehole]

With a renewed trade war between the US and some countries trying to help Greenland, it's likely that someday in the next two years (Trump mentioned military action in "a few weeks"), although this could also be the next two weeks, all access to S3, Fastly, DNS (through ICANN), and GitHub will be turned off (and that's not even the worst case, since these services could certainly do much more damage).

(The "Steering committee" should have prepared an emergency plan to make sure that the economic value of an ecosystem built over decades wouldn't be destroyed, but apparently that was too much to expect from them, but here's your chance to correct. )

So, if you want to still have a nixpkgs to play with, migration is non-optional.

[vcunat]

I'd say these are very very unlikely.

[wolfgangwalther]

Not unlikely enough to outright reject, I'd say.

[inthesquarehole]

I'd say these are very very unlikely.

Then this is your chance to make money, since the rest of the world says it's 11% right now, which is much greater than "very very unlikely".

https://polymarket.com/event/will-the-us-invade-greenland-in-2026

[vcunat]

I meant the other part:

all access to S3, Fastly, DNS (through ICANN), and GitHub will be turned off

[inthesquarehole]

From my understanding of geopolitics, that's just about the first thing that would happen after the EU would deploy their sanctions, because it would be a highly effective instrument to very precisely manipulate the various EU populations on a per company basis (and you can be certain that they developed such infrastructure).

Anyway, I agree that the most likely outcome is "TACO", but if it happens, perhaps just having alternative solutions in place as part of the deployment with backups of the various data to at least be able to continue, if there is a need to switch after the plug has been pulled.

[cafkafk]

The "Steering committee" should have prepared an emergency plan to make sure that the economic value of an ecosystem built over decades wouldn't be destroyed, but apparently that was too much to expect from them, but here's your chance to correct.

Just to be clear if there was a US software embargo towards the EU like the one currently put on e.g. Iran, or a full scale intra-NATO conflict, you think that its unreasonable the Steering Committe doesn't have a contingency for that when we're currently a project that struggles to even fund our binary cache in the first place if it wasn't for the generousity of US companies?

---

Regardless, given the limited resources, we simply don't have an alternative to S3 for the binary cache, so that is absolutely just a thing we get to enjoy because of geopolitical stability.

But even then... If the proverbial shit truly hit the fan, then at least, we'd likely quickly be able to establish a new European repository for nixpkgs from one of the thousands of GitHub checkouts in circulation. Git is made to deal with this, and email communication would not be prevented.

To bootstrap the upstreams we'd be able to use the /nix/store inputs to create new repositories.

All of that alone would obviously be an undertaking. And yes, there would definitely be a period where beginner and even intermediate users would have to accept that they can not install new systems or update their computer. And there probably wouldn't be a binary cache.

Given that gravity of the scenario you're talking about... I think that we're very well positioned compared to most other projects or software used in such a scenario... and that is considering the resource restrictions we're currently operating under.

[cafkafk]

(That said, if you have any concrete proposals for contingencies or disaster recovery, I'd love to hear them and escalate them to the SC if they sound promising!)

[inthesquarehole]

Regardless, given the limited resources, we simply don't have an alternative to S3 for the binary cache, so that is absolutely just a thing we get to enjoy because of geopolitical stability.

One of the project risks is indeed cost to operate. I think it's a waste that the source code often has a small set of changes relative to the binary output, which is why binary diffs are a thing in commercial environments. Now, I can understand that before committing to anything big someone would want to see numbers for both the potentially higher server load vs lower bandwidth and the trade offs of that on various pieces of hardware, but it seems that storing and serving diffs could be better. I don't think it's a new idea, but I can imagine that the economics change every year, which suggests that having a model to compute what's best would be a good idea too.

I also think that an architecture in which people can register their cache as serving a set amount of data or a particular maximum amount of bandwidth via probably existing protocols in a way that's easy to turn on would alleviate cost of the cache. I think there's also quite some overhead in configuring to use a local cache right now and there are probably many people that just don't bother to turn it on.

A trivial method is that only nix store paths with prefix "aaaa1" are served by a server with a particular hostname or IP. Such an architecture would scale to millions of "servers", but I would strongly suggest some survey into distributed systems before hacking something together.

Ultimately, the cache is just too expensive for what it provides.

I think it would probably also be a good idea to have more heterogeneous systems build the source code and to add meta data to builds like "required memory", etc. I am pretty sure that if I were to build everything from scratch compilation errors would be found. So, a mechanism which compiles random projects from source dependent on the completion time for the download would increase resiliency. So, that would be a feature that's on by default and it would build a database of system models building an actual piece of software to track whether eventually everything is stable to build anywhere. This would also uncover hardware flaws in specific models, if these were to exist.

[cafkafk]

Binary diffs (e.g., CA-derivations) might help here by deduping identical outputs, but the compute trade-off for calculating/applying diffs at scale is non-trivial. There are CA-derivation efforts you could contribute to if you're interested.

Federated/P2P Cache has been experimented with, e.g. IPFS and other P2P layers for the store. The challenge is usually trust/signing and discovery latency. This is likely also an area where you'd be able to find projects to pick up or contribute to if you want to accelerate the timeline.

The current S3 backend should handle sharding transparently, but a community-run distributed cache would indeed need a DHT or consistent hashing approach. Implementing a distributed filesystem across community machines would be non-trivial, but if you're interested in pursuing it and find it trivial it would certainly be cool to see someone launch such a project.

[inthesquarehole]

Nobody would start such a project, unless beforehand the metrics for acceptation are defined. If someone builds something and then it's like "We don't like it", what's the point?

Also, before a single line of code is written, the economics should probably be proven (this would probably also easily take a few weeks of some engineer).

Just to be clear, I am not volunteering, although I would probably give feedback to whenever steps would be undertaken, but I think the SC should specify what would be accepted.

You said something about e-mail, but AFAIK if you ever get separated from me, there would be no way currently for me to prove that I am this user. So, I am saying that the social network would also break in such a scenario.

[cafkafk]

If someone builds something and then it's like "We don't like it", what's the point?

Most of my project are exactly like that to be honest. Nothing here is really mandatory anyways, and if you wanted to do this, you'd likely do yourself a major disservice by starting at a committee.

there would be no way currently for me to prove that I am this user.

That's the point of having GPG keys.

Just to be clear, I am not volunteering

Well, then I don't think you should be pushing this hard for it if you're not even willing to make it happen. Talk is very cheap, actually doing the work is hard. So I hope that satisfies as why the SC hasn't done this yet - we have bigger, different fish to fry, and our job isn't to do everything, it's to help people that want to do things.

[zimbatm]

What would be the best repo to have governance discussions?

The infra repo isn't it.

If you need help with setting things up we can help, but it has to be more concrete than the current level of conversation.

[KiaraGrouwstra]

the Discourse then, perhaps?
generally speaking, that platform may be fleeting, tho i imagine discoverability may be alleviated if such a successor thread were linked from here.

on-topic, on fediverse it was further pointed out that a hypothetical cut-off from might further hamper access to packages' source tarballs.

[danieldk]

on-topic, on fediverse it was further pointed out that a hypothetical cut-off from might further hamper access to packages' source tarballs.

That's me 😅 . Personally, I share the concern that blocking technology access for be blackmail is in the realm of possibilities. Of course, there will be larger issues (failing supermarket logistics systems, etc.), but I think it is worth preparing for because some critical infrastructure might also run on NixOS.

I don't think there needs to be a full replacement of the cache. Initially a EuroCache could only cache all Hydra builds for the current stable release and unstable starting from the point of the current stable release. Anything older could be garbage collected. This would provide various advantages over the current situation:

1. People who prefer only pulling from European services now can do so.
2. Tying in with (1): I think as part of tech sovereignty, compliance and audits will become more important and a US company-based cache might block the use of Nix/NixOS in some organizations.
3. If blocks do happen, there would be a usable cache for the NixOS/nixpkgs versions that people actually use, which is IMO much more important in such a situation than preserving historical output paths.

I would guess that hosting basically a cache of the last 6 months would be much smaller/cheaper than the current binary cache?