ybx

A better analogy is the one that's twisted to fit my narrative.

(both you and the parent comment are kinda doing this)

"does that license apply retroactively to a checkout of the first N-1 commits"

No, unless you explicitly state it somewhere (and even then, I'm not certain).

If they add a license to the older commits via rewriting history then yes, those older commits will now be licensed. If they don't do so, then copyright will be default i.e. you can't do anything with it.

Now, if they had a large history and didn't retroactively license files, but just pushed the repository out all at once, I have no idea if the license on the latest commit would apply to the older commits. In the end, the question is all about whether or not Apple has the legal ability to sue you for copyright infringement.

It would probably have to be the entire IP address space, since they could transparently source NAT on the MITM server to make it look like it's coming from the user's IP.

It's pretty clearly a joke, as he "makes the mistake" that he was just describing was something you needed not to do.

> are so naive to waste electricity on collossal scales.

I know right? The last time I had to use 20 watts for an extra 5 seconds nearly bankrupted me

It's probably not at the point yet where you'd be interested in it (especially for tooling), but you might like Rust in the future.

I presume a collection can have multiple of the same thing, whereas a set cannot?

Well for one, LXC isn't necessarily a "thing" in itself - it's a combination of several Linux kernel systems (one of which is cgroups) that together provide machine-like containers.

How does flexible mean do it well?

"Do it well" is so vague of a saying that it really could mean any of those things, whether it be flexibility, or simplicity, or etc.

Is SSH really a dependency you have to worry about though? Basically every server out there runs SSH.

Yeah, there are plenty of authentication systems out there for this kind of thing, and preferably something like SRP would be used.

From a usability perspective, it's probably because dealing with keys that can't just be memorized is hard for most people.

The idea is that you're implicitly trusting the company (or website), as well as anyone who has (whether legit or not) access, to only keep that password in memory, and it's preferable to authenticate without requiring that trust.

You're still passing the output to the server, which can be repeated. Certainly better than just a password, but not as good as public key crypto.

In the end, I'd probably prefer something like SRP

The difference here though, is that the private key is not being sent verbatim to the server.