This is not specific to US law ...

To be fair the US is a bit on an outlier here, as it is not afraid to come down on US companies for things subsidiaries do in other jurisdictions, on questionable grounds. So it would not be enough for Let's Encrypt to operate a European operation to sign European certificates.

Should the US wish to sanction the Hague, somewhat famous for its international court of justice, they would absolutely go after ISRG and it would not be enough for them to sever the ties of the hypothetical Let's Encrypt Europe. That would not be legal or last least highly questionable in most other democratic countries.

Yes, but EU would have to convince Google and Apple to get a new root certificate to browsers.

Not really. They just have to convince an existing CA that cross-signing their CA won't make Google and Apple mad.

Cross-signed roots are common. Just takes money and maybe audits, but it's the same audit they'd need to get in the browser root stores anyway.

> for example I invest in an ESG index for environmental, social, and governance, ie no weapons or drugs

So, no weapons for Ukraine?

Seems like my tax dollars do plenty of that without my explicit consent. No need to invest in that more.

50% property tax is just seizure without compensation, which is generally considered human rights violation.

If government wants 50% of shares, it can just buy it (or expropriate it with compensation) and use its ability to get cheap long-term loans to finance it.

When converting between different depths, the 255-like approach has a property that minimum maps to minimum and maximum maps to maximum.

U2F token is used by one eIDAS identity provider in Czechia.

> Second, many people think that the C runtime doesn't know the amount of memory allocated to an array, but this is actually false. It's just the C abstract model that for some reason chose to not expose this information.

There are some counterpoints:

1) Conceptually, allocated memory block and data structure / array in it are not related. You can allocate memory block and then subdivide it to multiple different structures / arrays. You can implement sub-allocators.

2) Heap allocator does not need to store exact length of allocated object. For example, it could have several fixed-length slab allocators for smaller objects, select matching one during malloc() and use address range to find slab during free().

3) Array can be also on the stack (VLA or alloca()).

4) Arrays can be also on memory allocated outside of C library allocator (e.g. mmap()).

All are fair points, I was being a bit cavalier with the facts. I'll also add that many if not all modern malloc() implementations actually allocate somewhat larger amounts of memory than your request, to respect various alignment requirements and/or to avoid excessive fragmentation - even when not using pure slab allocations.

I do think the C++ bookkeeping from new[]/delete[] however has few if any similar caveats - the runtime really needs exactly the kind of information you also need in your code; the only caveat I can imagine is that it might omit this information for types that don't need destruction, such as `int`, but I don't know if this is a plausible optimization in realistic use cases that are not trivial.

These constraints, at least for electricity, are usually in end distribution networks, not in production. High-powered datacenter would get (and pay for) its own substation/transformer from higher-voltage network, thus avoiding the limitation.

The main point of ENUM was compatibility with open SIP, unfortunately that never really happened and most SIP operators do not accept incoming calls from public internet (and do not route outgoing calls based on ENUM).

IMHO soldering two wires together (or wires to connectors) is much harder and requires higher dexterity than through-hole soldering on PCB, which is really easy. PCB holds parts in place and directs solder where it belongs.