First, I love my dog. Next, I don’t use these. He is a good boy and has a regular ol’ collar. But those are not intended to injure. They apply pressure evenly around the neck, which according to the creators lowers the force generally applied directly to the trachea causing some injuries. Again, I don’t know anything about the truth of that. I have just read some about them.

I assume you’d find its users probably generally love their dogs even if they completely wrong about the safety.

Yes like herm springer but they are not intended to injure. Not supporting them, just saying that isn’t the intent. Created by a veterinarian I think.

Not at all. Tongue was firmly in cheek. I work with jvm professionally. I was specifically trying to clarify that I find the beam vm exciting but not jvm and was therefore just kidding around when I made the first comment. Not gate keeping at all. Like whatever you please.

I won’t argue that isn’t true. I’m just saying beam is a value prop that speaks to me. Jvm isn’t, but objectively is for sure.

That feels like a false dilemma to me. The country and government, ideally, are the people.

At least there is a good reason to use elixir. Beam.

It also means the people operating them will have a high threshold for consequences and maybe not care so much about the community.

What would that do? Dead bodies don’t put off heat very long. Well aside from decomposition, but that’s negligible.

Proton also has mail and password management.

Hey, don’t talk about our friend Denjin that way.

And we’re only halfway through the rawring 20’s. I’m imagining massive global human migrations away from the equator for compounding reasons in the next few decades.

These birds are so fun to watch. Very nimble little creatures, alongside nuthatches that actually walk headlong down trees.

What funny is it is Mozilla giving away free cookies with a sign that says, “Only accept my cookies”.

Pepperidge Farm remembers.

Actually going this year. Have wanted to for many. Really looking forward to it.

Modelling how you want to handle trust in your architecture doesn’t have a best answer really. Many ways to pet a cat, and all that jazz. Some prefer to trust only end to end, meaning not just establishing trust at the API entry, but all the way to the backend. There are arguments to be made for doing it either way. As long as your services behind the API gateway are in a private network, it is maybe okay to establish complete trust here and you could even terminate TLS and use clear communications. Another more secure pattern is to authenticate the call to the API, authorize which backends can be called, then verify the source caller in the backend as well.

There are many public sector organizations that need programming done. There are also organizations that back FOSS work. However, if it can’t involve devops, cloud, or containers, I don’t know how much will be left for you to do. There are tasks that don’t involve those, but they’re few and far between. And anybody who said those aren’t part of “REAL programming” wouldn’t get a second listen from me in a hiring scenario.

That’s dark, hilarious, and horrifying.

Actually great questions. Yes and no. There are vulnerabilities if the private key leaks, but public keys are just that; perfectly okay public in any hands. You only encrypt data with it.

What makes the Signal protocol so awesome, and other algorithms like it, is that it reduces the threat surface area further by using onetime keys. So even if your key is leaked, it cannot be used to decrypt old or forthcoming messages as the keys have already ratcheted to the next pair.

They share it with you. Their public key is generated by them. You encrypt a message to them with their public key. They use their private key to decrypt it.

I want to add before I get completely roasted here, that this is intentionally reductive. Signal actually uses a much more interesting multikey sharing algorithm, double ratchet. This uses onetime keypairs, and really is worth reading about.