Or those common dumb ones could be attempted by someone just trying to snoop on your phone.

Their income is based on trust: that their target trusts them to keep their end of the bargain when paid. Without that trust, there’s no reason to pay them or engage at all other than to try to trap them.

Yeah, as the other commenter mentioned, git is a distributed source control system, so all clones have the full history (though you can bump up the “starting point” to reduce the overhead of storing all previous commits).

Hosts like github can add more features on top of that, which would have to be backed up separately, but you can automate the repository itself using a single command, which is the same command used to make a clone in the first place.

IMO everyone should have a local backup of everything they can get related to the repo. Like I know with git itself, anytime you clone the repo you get everything, but also the supporting stuff that is in the layer outside of git. IMO the host should mainly be the hub where everyone gets and interacts with the project, while everything else is already good to go in a new location, should the host either screw up in good faith, get corrupted by outside influences, or gets overrun by local or remote powers.

This makes me a bit curious about whether the overall risk to projects is higher from individual local device failure or politics around who controls remote hosting services and the nature of the project.

The cloud is already a thing.

I’d extend the advice to be more general and say if you are doing anything more sensitive or important than basically a casual chat about something interesting, you shouldn’t be using remote models because they are likely logging everything.

It is and it isn’t. The hand you get dealt is random (assuming no funny business) but the people who do consistently well are playing their opponents more than their cards.

Not sure how well that without work even if you could bridge them properly to share their vram, as the latency from the other gpu will be pretty high compared to the local vram. Frame times won’t be that great is my prediction. It works ok for LLMs because they aren’t a realtime compute task like gaming graphics is. If an LLM takes an extra 0.12s to compute its result, you don’t notice, but if a gpu misses a frame deadline by 0.12s, that’s a stutter that represents less than 10 fps.

I believe that’s why earlier attempts at dual gpu systems mostly fizzled out (plus cost concerns). You can get some pure acceleration if you can fit the entire working memory onto both GPUs’ vram (so your total vram is effectively min( GPUA_VRAM, GPUB_VRAM ) rather than GPUA_VRAM + GPUB_VRAM, though that also requires all pixels to be independent of anything calculated on the other GPU, other than maybe post processing effects that could be handled on whichever GPU is handling the display.

That’s not to say that you can’t get extra performance out of multi-gpu setups that don’t just mirror their RAM, but it’s more complicated than “sum of the capabilities of each GPU”.

How much of this is based on reality and how much is based on Star Trek wanting a mechanism to be able to communicate between star fleet and the Enterprise?

What exactly is subspace anyways?