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...

I imagine it's possible, but "no reason" is definitely a stretch. The parts of DC that are federal land are hardly contiguous, and trying to force a clean split between DC and Maryland looks like it would be a nightmare: https://www.washingtonpost.com/graphics/local/dc-marijuana-m...

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.

Won't this calculation overflow to +Infinity in JavaScript after a while? On the other hand, Python will try to compute the actual result using arbitrary precision integers, which is that's slower.

Are you sure pypy didn't just optimize out the loop entirely (as an aggressive C compiler would have done)?

I think the problem is Facebook's lack of transparency here. As a user, suppose I have some information that I've marked as "not available to third-party apps". Then I might be surprised to find out that Blackberry's servers have access to that data via a secret API, even if it is to implement a "Facebook experience".

Can't forget about direct messages on Instagram, either...

On the relative density of languages, here's an article about a study I think has been discussed on HN before: http://content.time.com/time/health/article/0,8599,2091477,0... Basically your intuition is pretty much correct: languages have roughly the same speed of information transfer because lower density is compensated for with greater speed.

There's another thread posted more recently with more discussion: https://news.ycombinator.com/item?id=14616196

It may seem like a little thing, but you have to be very careful while typing not to accidentally press Enter. I've found this to be surprisingly difficult, and it makes typing a lot more stressful.

I think I saw my Android phone use http://gstatic.com/generate_204, though more recent phones might use something different.

How is a Chrome extension able to detect what external monitors or running applications there are on the system?

He does mention 6am elsewhere in the article, so perhaps she works less than 8 hours. But spending 8 hours a day on commuting is a definite recipe for disaster.

In contrast to what Zed suggests, I would argue that the text/binary dichotomy that you describe is actually very important for beginners to learn. Until I learned Python 3, I never really understood how text encodings worked, which confused me whenever I had to deal with Unicode (I'm looking at you, UTF-16).

One problem with distributed systems is the lack of a centralized authority for usernames. (Who says @POTUS is POTUS?) So why not create a custom TLD for a Twitter-like service? Each domain would be required to implement the API for that service. This would solve the username problem, and allow the registar to remove abusive users, but also let users host their own content. The only problem is domain registration fees, but hey, .tk domain names are still free.

Years ago, when Google+ was first launched, you had to enter your birth date to create a Google+ profile. But my friends and I were under 13 at the time, and a few friends had their accounts disabled due to their age. There was a minor fuss about this online, including from people who had accidentally clicked the wrong birth date. (Though they did re-enable accounts if you sent them ID or made a $0.05 credit card purchase.)

As for me, though, I was terrified at the thought that my account could have been disabled, had I entered my actual birth date. Even back then, I had a fair amount of data stored on my Google account. The incident was enough to get me to start downloading data from Google Takeout once in a while.

It's been a while since my last backup, though. I hope this incident serves as a wake-up call to both me and everybody who "owns" a Google account. I also wish that Google would allow at least some disabled accounts to download their data from Takeout: that would make me feel just a little bit safer.

I'm a bit confused that TJSON only allows UTF-8 strings. The only way to escape Unicode characters in JSON is \uXXXX. But to encode astral characters with this syntax, UTF-16 surrogate pairs must be used. How does TJSON handle this, if strings must be encoded with UTF-8 only?

As I responded to another commenter, the purpose of "char * p" might simply be to indicate the type of p, not necessarily to indicate that it is uninitialized. If you wanted to indicate the type of p, what would you write instead?

Regarding pointers, though, you have a point that char * is commonly used for statically allocated strings. I concede that it's fair to criticize the interviewee for saying the memory was dynamically allocated (by the compiler??), though I don't know if that rises to the level of "Get out."