epwr

Thinking this through, using my domain might actually be much less risky than using a host's. If Gitlab closes down, and someone else buys the domain, then I'm forced to make a massive refactor with little notice.

If I own the domain, I'm likely to continue to owning it until I shut down my company. At which point, no one is likely to be running my code.

Possibly different if I was developing an open source library or something, but either way there's risk and need to be thoughtful of the risk versus impact.

Wouldn’t a zero data retention agreement be pretty close to this?

That is not true. State laws cannot interfere with the work of federal law enforcement, but can require certain behaviours.

Eg. States set speed limits. A federal LEO can break these when required for their duties (eg. chasing a suspect), but only when required (eg. if they are late for a meeting, they still have to obey traffic laws).

Body cameras do not seem to directly interfere with an LEO’s duty, unless “avoiding accountability” is literally their duty.

Likely they will be heat welded to a polyethylene. You can sew this for extra strength. Which I think means a fully recyclable jacket!

Could you elaborate or link something here? I think about this pretty frequently, so would love to read something!

What’s the better app? Would love one that’s actually teaching the rules, not just learning through pattern recognition

lru_cache has the benefit of being explicit about the replacement policy. So I find it more appropriate in cases where I want a size limit in the cache which, for me, is almost always.

I’m not sure use cases you see caches in, but any long running process should likely have a size limit on the cache.

+1 for uplift. I’ve had mine for two years and love it.

This statement seems pretty poorly thought out. I think the argument that's being made is actually that there should be comprehensive privacy legislation, not that the TSA's use of facial recognition is bad/dangerous.

I see three risks being pointed out:

1. "the potential privacy and bias risks" -> however it doesn't expand or explain these risks. I'm on team privacy in general, so I definitely worry about this, but I think it's almost comical that any description of this risk is absent.

2. While facial ID is currently optional, "there is no guarantee that will remain the case" -> this is a textbook slippery slope argument, which means they're arguing not that the current practice is bad but that someday they might start doing something bad.

3. "the very real possibility that our face eventually becomes our default ID" -> another slippery slope argument that has even less to do with the TSA. This would require a major effort by the rest of government, so this is more a "watch out for that big cliff over there" argument than a slippery slope argument.

After all that, I think the topic sentence of this statement should be" > This is [bad] because the United States lacks an overarching law to regulate the use of facial recognition to ensure the necessary transparency, accountability, and oversight to protect our privacy, civil liberties, and civil rights.

I haven’t read the underlying paper, but from the article it seems the paper looks at if a person gets healthier when they get married.

This seems flawed because you get older as you get married, which is generally something that makes you less healthy.

This does not seem to compare health between a cohort that stayed single and a cohort that got married, so I don’t place a lot of value on the conclusions.

You might want to look a bit more closely before you write functional programming off like this.

Eg. Clojure is a modern functional language that is used for a lot of things & happens to be dynamic.

> Is it black market when I pay the neighbor kid to mow my lawn and don't report their address? Nonsense.

No, but it is illegal for financial institutions (and many industries) to provide services without knowing who they are serving. Not sure how anyone is surprised that KYC requirements are coming for crypto..