gengkev

I tried this but the DMV doesn't let you request it ;-( Alas, probably for the better...

At each DMV there are a stack of license plates that they hand out on-site. So requesting a vanity plate of the same format would probably require them to search those stacks (across all DMVs) to pick out the plate.

With my car, trying to lock the doors just doesn't work if one is left open — not always the most obvious failure mode, but it's been enough to get me to notice something's wrong.

Suppose it takes 2 seconds of 100% cpu usage to compute the password hash (you probably wouldn't want to wait much longer).

Then brute forcing a 4 digit PIN will take 20000 seconds ≈ 6 hours maximum. There's no way around that, no matter what hash function you use.

For me, at least, there's an important difference missing from the debate over the term "C/C++": compiling C code is always much faster than you would expect, but compiling C++ code is always much slower than you would expect...

Pixel phones can take "Motion Photos" — it seems like this is basically just an mp4 file stuffed into a jpg somehow (but without sound). The Google Photos app lets you export it as an mp4 or gif file, or pick a specific timestamp to export a still image.

It looks like the Samsung Camera has something similar, but I'm not sure if it's compatible...

Right, I'm really surprised that there isn't at least a hash or something for that reason...

Conversely, I think the beauty is that they _are_ the same as top-level functions, just in a special namespace. This means that you can call "instance methods" directly from a class, i.e. the following are equivalent:

    (1) + 2
    (1).__add__(2)
    int.__add__(1, 2)

This comports with the "explicit is better than implicit" policy in Python. The only "magic" part is when dot-notation is used to call an instance method, which is just syntactic sugar. Another example of this philosophy is that operator overloading is simply reduced to implementing a method with a specific name.

I think a "magic" this keyword can create a lot of nasty edge cases that can be difficult to reason about; the way "this" is used in JavaScript is notoriously complex in ways that it might not be in a statically typed language like C++. What should "this" evaluate to outside of an instance method? What about in a class definition inside an instance method? What if an instance method is called directly instead of on an instance? All of these situations require making their own "rules", whereas in Python the correct answers can be easily reasoned about by starting from first principles.

> And Sundar has needed to go for a long time... How do you turn the largest consumer and commercial OS into a dumpster fire of exploits, half-finished ideas (Settings vs. Control Panel, anyone?!?)...

So Windows was made by... Google?

I always found this an interesting phenomenon. I hate being "wrong" as much as anyone else. But it seems like the best way to not be wrong is being aware of the uncertainties in your understanding, not making claims about topics where you have gaps in your knowledge, and adjusting your understanding based on new information. To have absolute confidence in what you are saying without regard for reality seems like the easiest way to be wrong...

On a related note, the finance-related apps on my phone all offer me the option to sign in with a fingerprint sensor. Arguably you have two forms of authentication there: the presence of the physical device itself (using the secure element or whatever it is), as well as the biometric identifier (fingerprint scanner).

Neither of those are present when logging into your bank from its website, and I would also suspect that jailbreaking a phone significantly reduces the trust you can have in either.

Also, from a bank's perspective, all they care about is reducing their liability, without inconveniencing too many customers. In that context, it makes a lot of sense for banks to disallow their products from being used on jailbroken phones.

This isn't even quite right, since the first argument of strncat needs to be a null-terminated string, and strncpy may not null-terminate. I would honestly just give up and write

    size_t len = strlen(source);
    char *dest = malloc(len + sizeof("@example.com")-1 + 1);
    strcpy(dest, source);
    strcpy(dest + len, "@example.com");

Yeah, isn't Plaid basically teaching users to fall for phishing attacks? As with any account, the only sane advice is to only enter your password for account X into the website or app for X. Which is the exact opposite of the expectation Plaid creates.

Also, it's one thing for me to let a third party withdraw money from my checking account (if I provide my account number), but that doesn't mean I want to give them the ability to do things like change my password, disable 2FA, read my transaction history, transfer money out of my other accounts, cancel my cards, and so on — which they can if they have my password. That's just insane.

Funnily enough, when I need a USB-C cable to charge my phone, I'm usually able to borrow one from a friend who uses USB-C to charge their Macbook...

Probably that the original binding of p is immutable, as it would be in a functional language: you can create a new binding, but you can't actually change the value of the existing binding.