That's probably the reason most grid black start facilities in my country (Brazil) are hydroelectric dams, which need none of these.

I stopped reading at this sentence. If you go to the source (https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...), you can see it's available in eight languages, none of them being Latin. In fact, I read elsewhere a few days ago that one of the novelties of this one is that, unlike all the preceding ones, it's not written in Latin; the Wikipedia article (https://en.wikipedia.org/wiki/Magnifica_Humanitas) also says that ("The encyclical was the first to be published without an official Latin version. This followed a recent change to Vatican regulations permitting such documents to be drafted in other languages.[4]").

If the article gets it this wrong already in the third paragraph, it's not worth reading any further.

Though more safety can in some cases bring a bit more performance. For instance, with Rust you can often avoid "defensive copies" of objects.

I have the opposite opinion. Its use being rare means CPU designers have less need to optimize for that rare case, and hardware optimizations are precisely where these kinds of issues tend to pop up.

And high 8-bit registers are a x86-specific feature, other CPU families don't have it. So that special case being less optimized (or even pessimized) is not much of a loss.

AI includes a lot of technologies, LLMs being just one of them. Several of these technologies use probabilistic algorithms, so having randomness does not disqualify something from being classified as AI.

I'm Brazilian. We learn early in school that water must always be boiled or filtered before drinking. I'd feel very uncomfortable drinking water directly from plumbing, no matter how much some people say it's safe.

Every place here (and I don't say that lightly, I don't think I've ever seen an exception) has either a water filter connected to the plumbing (for unlimited on-demand filtered water), or at least a separate standalone filter, or sometimes a drinking fountain which gets its water from large mineral water containers (and it's normally real mineral water bottled from real mineral springs, not that nonsense that is adding minerals to tap water and saying it's mineral water).

Edit: and IIRC, there's a law that bars and restaurants must provide filtered tap water to their clients without extra cost when requested. Even the law requires filtering.

Every time an issue is found, no matter how minor, it's fixed and updated everywhere. From now on, every car of that model (and future models, and related models) will no longer have that problem. Several passes of that improvement cycle, and self-driving cars become safer (and more efficient/comfortable/etc) than human drivers. At least, that's how it's supposed to work.

And by skipping some releases, you will have less of that work. When something is changed in one release, then changed again on the next one, by waiting you only have to do the change once, instead of twice. And sometimes you don't even have to do anything, when something is introduced in one release and reverted in the next one.

Unfortunately, that's not enough. Even if the vulnerable parts of the code are not being built, heck even if they have been completely erased from the source code, the auditors will still insist that you're vulnerable and must immediately upgrade, or else they will give your software a failing grade.

> Client takes its own public key and the server's public key and creates this signature.

According to https://www.rfc-editor.org/rfc/rfc4252#section-7 client takes its own public key, the "session identifier", and a few other things, and creates this signature (using the private key corresponding to that public key). According to https://www.rfc-editor.org/rfc/rfc4253#section-7.2 that "session identifier" is a byproduct of the key exchange.

> MITM can take its public key and the client's public key and send the resulting signature to the server instead of forwarding what it received from the client.

That's not possible, since the MITM doesn't know the client's private key (and using a different public key will be rejected by the server).

> Do pretty much the same exact thing: MITM PK + Server's PK -> Client. Now client has a signature as well. The signatures that client and server have are different but that is OK as long as MITM can see and change all communication.

You're confusing the Diffie-Hellman Key Exchange with the Public Key Authentication Method. When you MITM the key exchange, the shared secrets the client and server have are different (one side has a secret derived from the client and MITM keys, the other side has a secret derived from the MITM and server keys), but that works as long as the MITM can see and change all communication (basically, decrypting it and encrypting it again).

But since the secrets are different, the session identifier is also different. The MITM can't forward the signature from the client since the server will fail to verify it due to the mismatch in the session identifier; the MiTM can't create a new signature with the client public key since it doesn't have the corresponding private key; and the MITM can't create a valid signature with its own public key (and the corresponding private key) since that key won't be in the authorized keys list for that user account in the server.

It doesn't completely stop working; a MITM can still pretend to be the server, it just can't authenticate to the real server on your behalf. You could be doing all your work in a fake server controlled by the attacker, while the real server sits there untouched.

The client sends not only the public key, but also a signature, and that signature depends on the output from the key exchange, so it's "bound" to the shared keys negotiated between the client and the server. If the MITM server does separate key exchanges with the client (pretending to be the real server) and the server (pretending to be the real client), the signature won't match; if it forwards the key exchange between the real client and the real server, it won't be able to decrypt the packets.

That's the best thing about SSH public key authentication (and HTTPS client certificates): even when MITM can impersonate the server to the client (because the client didn't verify the host key), it can't impersonate the client to the real server.

To put it in context: everyone with a Brazilian bank account can use Pix. That's the reason "everyone" has it.

The most infuriating I've seen, is a bank which removed the anual tax report (which you need to do the anual income tax) from the online-banking website, requiring you to use the phone app... to download a PDF file, which you then have to transfer to the computer anyway so you can print it!

Unfortunately, not in my country.

> Sent from my Librem 5 running GNU/Linux.

Can I buy a Librem 5 here in Brazil? (Unless it has ANATEL certification, which I doubt it has, buying online from outside the country is not an option, since it will be rejected by customs.)

Could you please tell me, where are all these manifest flags documented? I asked about it a decade and a half ago at stackoverflow (https://stackoverflow.com/questions/5733085/application-mani...), and the only answer was "there isn't".

Because you're traveling for work, and carrying two separate laptops eats into your limited baggage size/weight. Things are marginally better now that everything uses the same standard charger, but not much.