Inb4 it becomes “upload your passport to boot”

Yes, there’s definitely worse out there.

But this is still worth fighting. It’s a bellwether for more restrictive age+identity verification laws, and those should not exist in the US. The gov’t shouldn’t have any say in what I compute the same way they shouldn’t have any say in what I discuss using the mail. This is a clear step away from that and it’s important to make that clear to lawmakers now so they don’t use this as evidence the populace is ok with something stronger.

If the servers have public IPs and you want the minimum possible ports open, just SSH? With passwords disabled and large keys, it’s quite secure.

If that’s still not enough for you or you need a private gateway, then Wireguard. I can strongly recommend Tailscale - It’s really an orchestration layer on top of Wireguard. You can setup your own Derp relays and head scale if you are truly paranoid. But 99.9% you don’t need all that and Tailscale out of the box will work well.

Also Tailscale isn’t a single point of failure the way you’re imagining. It’s certainly possible for Tailscale’s servers to go down, but that won’t drop existing connections.

Uhh, clouds? Duh

No mention of VLC?

Unga bunga

Fibonacci heaps are pretty cool. Not used very often b/c they’re awful to implement, but better complexity than many other heaps.

Also Binary Lifting is closer to an algorithm than a data structure but it’s used in Competitive Programming a fair bit, and isn’t often taught: https://cp-algorithms.com/graph/lca_binary_lifting.html

And again closer to an algo tham a data structure, but Sum over Subsets DP in 3^n also has a cool little bit of math in it: https://cp-algorithms.com/algebra/all-submasks.html

https://paulgraham.com/avg.html

Go and Python and Typescript all have their own footguns.

I assume Rust is the same, but haven’t used it personally to see

Also the number of outcomes isn’t connected to the solution space reduction the way you say. If you don’t know whether the fake coin is heavier or lighter, both tilt-right and tilt-left are effectively the same result. So at least your first test really only has 2 meaningful outcomes.

In general, you’ll only reduce your solution space DOWN TO (not by) 1/(number of distinguishable outcomes) if the possible solutions are evenly divided among those outcomes. It’s easy to have a problem where “result 1 narrows it down a lot, result 2 doesn’t tell us much”

If you don’t know whether it’s heavier or lighter, after the first test shows uneven you still have 6 coins possible. You can do it in 3 tests only if you know lighter vs heavier for the fake coin.

Oddly enough, out of all of these the one the compiler has the best chance of optimizing out is the last one

Or say “ok, you got me there. But, two things can be true and I’m here to listen if you have something you want to talk about”

Also does not handle ‘IIIIIIIII’ -> ‘IX’ properly

For a first step you can get away with just add, commit, push, and pull. Maybe reset, but tbh using git like svn at first is fine.

Next branch, checkout and merge. At this point show, log, bisect and blame also start to be useful.

I’m not a fan of stash, and would instead recommend reflog and cherry-pick as the first two advanced commands to learn. Then rebase and squash.

He did! He did just diss the All Might Father, Emperor of Linux on Lemmy!

I absolutely agree. An even better structure wouldn’t have a raw password field on the user object at all.

In addition to the excellent points made by steventhedev and koper:

user.password = await hashPassword(user.password);

Just this one line of code alone is wrong.

1. It’s unclear, but quite likely that the type has changed here. Even in a duck typed language this is hard to manage and often leads to bugs.
2. Even without a type change, you shouldn’t reuse an object member like this. Dramatically better to have password and hashed_password so that they never get mixed up. If you don’t want the raw password available after this point, zero it out or delete it.
3. All of these style considerations apply 4x as strongly when it’s a piece of code that’s important to the security of your service, which obviously hashing passwords is.