HN user

ehzy

76 karma
Posts0
Comments32
View on HN
No posts found.

jj is not just a new interface for git, it has a lot of new and powerful features to offer, even when you're using the git backend with a colocated repo. Just to name a few:

- deferred conflict resolution

- The very expressive revset language

- the op log and ability to undo any operation

Many things that you can do with the git cli are significantly easier and in some cases comparatively effortless using jj. If all you do is git add and git commit then you probably aren't missing out on much, but if you ever split or rebase commits you should definitely try jj.

Does anyone know if this works with Yubikey 4? I have a lightning to USB adapter but I can't seem to get it to work with these keys. It worked fine with A USB-C + NFC Yubikey Security key and a Google Titan key, but not Yubikey 4.

My understanding is that it's actually quite difficult to fit a high quality camera into a laptop lid. If you look at how thin the lid is you'll notice it's at least twice as thin as a cell phone.

The point is not that the bank magically credits someone with $10. The $10 figure is arrived at after a series of infinitely recursive loans and deposits.

If you deposit $10, you still have $10, it's just in a bank account. If the bank then lends out $9 of that and hands it to them, that person now has $9, and you still have $10 (in your account). Presto, now there's $19 of money available. Of course if you both want to spend your money at the same time, then the bank will have to go back to the fed and say oops! we're illiquid and need to borrow $9. And the fed will say, ugh, you should manage your capital better but here's a loan for $9.

The same process that's occurred here can be done recursively, i.e. the person who borrowed $9 can deposit it in another bank, who then loans out $8.10, and so on...

This works out such that for every real dollar d, the total money supply is (d / r), where r is the reserve requirement, in this case, 10%.

My experience with paying through the app has been pretty subpar. Usually I'm required to type in my credit card by hand, on my phone. Yuck. If I have to use some app / website to order food at your restaurant it better support Apple/Google Pay.

Edit: the number one thing users want in a restaurant ordering system is ease. I'm in a restaurant to relax, eat, and enjoy good company. The last thing I want to do is register for get another app (because none of the restaurants use the same one) and type in my payment details. Some of the things you mention do sound more convenient than the traditional paper menu and human waiter, but if I have to type in a credit card number or sign up for an account, I'd prefer the human.

This is misleading. Android implemented full disk encryption around Android 5 (it's on 13 now), and later transitioned to file based encryption because it's a better fit for mobile phones.

You might be surprised to hear that the iPhone also doesn't have full disk encryption - it used file based encryption as well.

I think this really comes down to what your company needs to do.

If you are doing things that the middle 60% are capable of, top talent might not be worth it to you.

If you are doing things that only top talent is capable of, then top talent is worth any price you can bear.

Using Google on your device stores your location every time you turn it on. It stores your search history across all your devices in a separate database, meaning even if you were to delete said history on all your devices, Google would still have a record of it.

All of this can easily be disabled on the setting page for your Google account? And, location history is off by default.