fishywang

A lot of years ago, while living in Beijing, I once bought ticket to a morning (9:30 or so) show in a theatre. Then came that day, it rained unexpectedly, so I ended up getting there 10min late. When I get into the theatre, I found out that it's completely dark. I asked a staff, they told me that they only sold that one ticket and since I didn't show up within 5min, they cancelled the show and returned the film. They refunded me in the end.

I was flying out of LHR yesterday (Monday). I read the news before so asked the agent at security check "I don't need to empty my water bottle now right?" and she was like "nah that's only for up to 2 litres in a clear/plastic bottle, not a metal flask bottle" or something along those lines. I was using a Stanley metal water bottle. So I still had to empty my bottle.

lol I have another story regarding Apple gift cards.

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

I'm not sure it works that way. _In general_ before the recent announcement you are supposed to sign the debug build (what you feed into adb to install) with your debug key that's different from the release nor upload key, and the debug key is never submitted to google.

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.

I have a magnet that's a mosquito with text "Alaska state bird".

I don't understand how this got so many upvotes. Embedded struct fields are never "promoted", you always need to access them via the embedded type's name, so there's nothing to conflict.

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

I tried to use fish on some of my debian servers that i only rarely update packages/kernel, so I don't have to carry my bashrc there, but found their completion for apt is pretty naive. for example after updated kernel i would want to clean up the old ones, but `apt purge linux-image-<TAB>` would list all available kernel versions, not just the ones currently installed.

in the end i switched back to bash.

Yea I saw your other reply later and agree on most of it. But I'd say there's a balance between simplicity of the API and more specific cases. For example they can make an optional api to io.Reader to provide size info, and maybe another optional api to io.Reader to make it able to be read more than once, etc.. But at the same time, if you have all those info, that _usually_ means you already have either a []byte or string, and you would most likely use one of the 3 types to convert that into an io.Reader, so that special handling is enough without adding more public apis, and the go team is notoriously conservative when adding new public apis.

The request body on the client do a lot of other things than reading the body once (an io.Reader can only be read once).

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

He is also one of the authors that (almost) all his eBooks sold on Google Play are without DRM.

Garmin's hardware, including the hardware of their smartwatches, are very tempting. They are designed to be easy to use even with gloves, have good battery life, and on some high end they have solar and/or 40-meter scuba diving rated.

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.

I had a facebook account from the early days. I deleted my facebook account at 2018-ish. I never had an instagram account.

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

I'm not sure what UX you are talking about, the majority of the websites supporting u2f/passkey have UX to manage your u2f keys/passkeys. (the only exception I can think of is early Twitter when it first implemented u2f, and at that point it only allow you to add a single u2f key, but even Twitter fixed that later and supports multiple keys now).

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.

>exposing yourself to the mercy of a single organization

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