> As a non-English speaker I can really relate to this.I think the real mistake was Apple allowing to enter a non-ASCII password in the first place.

As a non-English speaker (Czech, actually), it is clear to me to not use non-ASCII characters in passwords, or generally not use characters that are at different position on default English keyboard and locally used keyboards, i.e. use only ASCII alphanumeric chars except 'Y' and 'Z'.

As keyboard setting is per-user setting, keyboard may be different on login screen than on regular desktop (and once-login password prompts).

> keyboard setting is per-user setting

Do you think most users know this?

Also, most devices nowadays ARE single user. And most (all?) OSes allow you to use alternative keyboards at the user-selection screen.

Also, all orgs recommend special characters in passwords. Czech keyboards default to accented letters on the top row instead of numbers, so why wouldn't your average Czech use those?

A related quote from A. N. Whitehead:

> It is a profoundly erroneous truism ... that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them.

Why not just use U2F or certificates on crypto-tokens?

Note that for eIDAS 1, a Czechia e-identity provider uses U2F tokens.

As bits are generally not addressable / not ordered, it makes no sense to call CPU architecture big/little bit-endian. That makes sense only for serial lines/buses.

Wrong for any CPU with bit manipulation instructions... which is nearly all of them.

'Arabic' numbers comes originally from India, from Brahmi numerals. And Brahmi script was left to right. So big-endian was 'normal' even originally, it was Arabs who kept left-to-right numbers within right-to-left script (and therefore use little-endian relative to direction of Arabic script).

> it was Arabs who kept left-to-right numbers within right-to-left script

Do they do this? I thought they swapped this as well.

There are actually two ways to read numbers in Arabic.

The most common is to start from the most significant digit and read left-to-right until the last two digits, which you then read right-to-left.

A less common alternative is to read right-to-left starting from the least significant digit.

Interesting! How do you know which alternative is being used?

To give an example, you could read 1234 as either 'one thousand and two hundred and four and thirty' or 'four and thirty and two hundred and one thousand'.

Now that I think about it though, I've only seen the latter way used for the year in a date.

There is one reason not mentioned in the article why it is worth testing code on big-endian systems – some bugs are more visible there than on little-endian systems. For example, accessing integer variable through pointer of wrong type (smaller size) often pass silently on little-endian (just ignoring higher bytes), while read/writ bad values on big-endian.

You can do radiative cooling in space (you just need big radiators). You cannot do that reasonably in desert.

Taking aside you certainly can do radiative cooling in desert at night just fine - you have air, which even if hot to desert standards during the day is still by magnitudes more effective for cooling via direct heat transfer than radiating heat away in vacuum.

I did realize geothermal would be the way to do it in the desert; the ground is still typically cooler than the heat computers give off.

It's still problematic that most deserts dont haveaccess to groundwater, so bootstraping and maintenance are an issue.

You can try to put the heat underground. Maybe there is an aquifer you can use. Or maybe your desert is close to the coast!

Still easier than radiating it into space.

The same system is used all over EU.

I could easily change mobile phone OS to ungoogled one (e.g. LineageOS) or fully Linux, than changing jurisdiction to non-EU.

Is this relevant for people that use regular (per-token credit-based) API key?

No, this is perfectly OK with the ToS.