(And also note that the latest Byzantine Emperors repeatedly tried to mend the schism to secure Western aid in stabilizing their empire.)

Obviously, the quality of these sorts of tools is dependent on your ability to write a formal model that is comprehensive in allowing behavior you want to be acceptable and disallowing behavior you want to be unacceptable, and we're still surprisingly far from that in many fields.

The major rupture is the Protestant Reformation, where the split between Protestant and Catholic Christianity proves irreconcilable, and results in the end of the notional idea of a unified Christendom. This is also when you start to see an end towards the practice of writing in the literate language of Christendom (i.e., Latin) and instead move towards working in the vernacular, especially in endeavors like scientific research.

[1] The major exception is Britain, where the end of Roman rule is very abruptly realized, and there is a distinct clear horizon between sub-Roman Britannia and Anglo-Saxon Britain. But the British experience is largely the exception, not the rule.

Keep in mind that the baseline is that, when you send an email, it is encrypted from your computer to your email server, your email server to your recipients' email servers, and your recipients' email servers to their computers. The only people other than you and the recipients who can see it are the email servers involved in the middle, so the best you can get with encrypted emails is maybe cutting out some of the entities that have a critical role in the process (and which therefore can't entirely be cut out). In particular, encrypted email leaves all the email headers public, so it's not like the best case here is particularly private.

But encrypted email also breaks the ability to do any server-side processing of email, like server-side email filters (okay, not the hugest loss in the world). Or spam processing--no one's come up with a workable solution here, especially given the vast amount of spam that never hits an email folder (the things that get routed to your spam folder are the emails your spam filters aren't sure is spam). Users also expect the ability to log onto their email server's website and just read their email: such webmail is the dominant email client used, and even people like me who almost exclusively use email clients still end up using a webmail client from time-to-time. You can fix this by giving your email server your key... which puts them back on the list of people who can read your email again, oops, you've gained nothing over the status quo.

Worse still is the problem of key distribution. To send an email, you need to look up the recipients' keys... and the most practical approach to make that work at scale is probably to ask the mail server what its users' public keys are. The one entity that is guaranteed to be able to intercept literally every message to somebody, and thus is in prime position to offer its own key instead, strip the encryption, and re-encrypt it to the user without anybody else finding out. Alternative approaches like keyservers don't work: the PGP keyserver ecosystem collapsed several years ago when PGP encryption was of interest to fewer than a million users, far less scale than the billions of email users.

Encrypted email is a useless pipedream, and not because of the business models of email vendors, but because the architecture of email provides good-enough security today that makes improving on it very challenging without negating the supposed benefits of extra encryption.

For largest absolute net gain of land area, I guess Mongolia wins the cake, getting a very large slice of Siberia while losing almost no land. For a percentage net gain of land area, maybe one of the European microstates, or East Timor.

Largest absolute net loss of land area is Russia for sure. Largest percent loss is... probably Russia? Again, losing Siberia is a large fraction of its land, and nobody else seems to be so screwed by the distance.

Excluding overseas territories, there's three borders between Yakutia-cum-Japan and its current capital, Moscow, and another case of that in the far western reaches of Brazil. If you include overseas territories, well, French Polynesia is currently almost literally antipodal from Paris, and I don't really know how you would count 'most countries away' in that case, but you can't really get further than that.

The things you are talking about are a phenomenon largely of the COVID era and later. The biggest wage gains post-COVID have been in the lowest end of the job market, and services where almost-minimum-wage labor is a high fraction of their cost have commensurately risen in price the fastest (e.g., fast food). Similarly, a lot of the easy money flowing into unprofitable grow-then-make-money businesses (like delivery firms) have stopped flowing in, so those services have had to actually make money from customers, which causes their costs to rise.

Which this article basically does, at first glance. It assumes capitalism is bad for baby-rearing, doesn't really motivate why, and instead just goes East Germany had a higher birth rate than West Germany before reunification, then after reunification, it flipped, therefore capitalism causes low birth rates.

It's also worth mentioning that directly linked from this blog post are several in-depth examinations of historical military systems, including Mongol, broader steppe nomad (note that the Mongols were exceptional), Roman, Carthaginian, Macedonian, Greek, and Gallic specifically covered in depth, and a couple of other cases (e.g., Medieval Europe and Mamluk examples) more covered in passing. The detail you think is lacking can easily be found in those blog posts.

You can also find a nice summary of the different motivating factors at the end, with 21 specific examples distributed among them. Is that not enough for you?

In an alternative world where fork+exec never existed, a lot of those "usual APIs" would probably have had an explicit pid argument to them that let you modify process configuration from a different process. (This is how Fuschia works, e.g.). There's a lot of benefit to this world: the most obvious is that you don't have to magic up some IPC system just to report configuration errors, but there's actually a good amount of utility in being able to have a manager process that is tweaking attributes of its children (e.g., debuggers would love it).