Many years ago we had an iMac at the house as the shared desktop computer. After a few years, it started to have the signs that the harddisk is going to fail, and also we were mostly moved away from Apple's ecosystem, so we decided to trade it in and replace it with something else that's not from Apple.

Since we don't have anything immediate to buy from Apple, we traded it in with Apple gift cards.

Later, my partner needed to trade in an old iPad for a new one, so we used that gift card with credit card for the trade in. For that trade in, you first pay the full price with gift card+credit card, then they refund you the trade-in value after the trade-in is finalized.

The trade-in value of the old iPad is less than the value we paid via credit card, so we would reasonably assume that they would refund the total trade-in value to our credit card. But nope. They actually calculated the original gift card vs. credit card split ratio, and refunded according to that ratio.

A simplified example is say we paid $200 via gift card plus $300 via credit card for an $500 iPad, with trade-in value of $200 for the old iPad. Instead of refunding $200 to our credit card (so it's eventually $200 via gift card and $100 via credit card), they refunded us $120 to credit card and gave us another $80 gift card. So we have to find ways to spend that gift card again, and it cannot involve any trade-in (otherwise we're not going to be able to use it fully).

Of course _maybe_ at some point google will also force you to submit your debug key to them. But I don't believe that's the case now.

The only thing "promoted" are the functions associated with the embedded types, and when those actually conflicts, the compiler will tell you, as expected.

it has guest support (so people does not need a matrix account to comment), but if you use your own matrix account, you are essentially joining a matrix room per post.

There's Content-Length, and there's also the need to read it multiple times in case a redirect happens (so the same body need to be sent again when being redirected).

As a result, the implementation in stdlib would check a few common io.Reader implementations (bytes.Buffer, bytes.Reader, strings.Reader) and make sure it stores something that can be read multiple times (if it's none of the 3, it's read fully into memory and stored instead).

If there's a way to use Garmin's smartwatches without using their cloud I probably would consider that. But since their ransomware attack from 2020, I really can no longer trust their cloud any more, especially that the data collected from a smartwatch is on the more sensitive side. The only Garmin hardware I'm still using is their bicycle tail light+radar, which I just use with wahoo's bike computer instead of other Garmin products.

Recently I got an email from instagram saying it's "easier to get back to instagram", with my usual username. I can't check what's on that instagram user because they don't show you anything without logging in, so I asked my wife to check that instagram user for me. It doesn't have any photos nor profile photo or following, but it does have several followers that's my facebook friends (when I had the account), so at some point meta created that instagram account for me and associated it with my facebook account, I guess? I hope that account was not "AI-powered".

And (this is probably not emphasized enough) you really should never only use a single u2f key/passkey for a website, that's the recipe to get you locked out when you can't find your u2f key/get locked out of the provider of your passkey. I have at least 2 yubikeys on my keychain all the time (one for usb-a and one for usb-c), plus one for each of my computers, and passkeys from 1password, google, etc.. And whenever I add u2f keys/passkeys to a website I add all/most of them.

The nice thing about passkey is that unlike password, you can have multiple per account.

So you can register a passkey from 1password to website A, and also register a passkey from Apple keychain to website A, and also register a passkey from Google account to website A, and also register a passkey from yubikey to website A, so even if you are locked out from one of your accounts, you still have several other ways to log into your account at website A.

And _if_ your, say, Apple keychain is compromised, you can just revoke the passkeys from your Apple keychain from all the websites (yes it's tedious, but it's doable).

amd64 v3 are instructions included in CPUs starting from 2013, so basically any modern amd64 cpu supports all of them. As mentioned there on the Wikipedia page, QEMU 7.2 also implemented all of them. Those are more efficient instructions, thus "free performance boost".

But Rosetta doesn't. Which instruction(s) it doesn't implement doesn't really matter (I can't remember either). What matters is that when it runs an instruction it doesn't implement, it will throw an illegal instruction error and the code hard crashes.

So because of Rosetta, we can't build code with amd64 v3 enabled, and cannot have free performance boost (nice things).

Then it turned out Rosetta does not support that, so those docker images can no longer run on developers' mac laptops, so we have to revert it back. This is why we can't have nice things (we don't use any arm server so we never bothered to build multi-platform docker image).

[1]: https://go.dev/wiki/MinimumRequirements#amd64

And San Jose's Department of Transportation traffic signal unit at least has an email address I can use to tell them which traffic signal failed to detect bicycle and turn green, and they actually fix them.

One thing in particular is that the physical page turning buttons are very useful. None of Amazon's new Kindles have physical page turning buttons any more from what I see in the reports.