And the fact that determining the true lat/long of one's location was best done by using mapquest.com (ah memories...). Unscrambled GPS for civilians didn't come along for another couple years.
The UK also gives people 6ish weeks (5 weeks to take when you want, plus 8 fixed bank holidays). I grew up in the US and am American more than I am anything else. I've lived in the UK for a relatively short time (6 years, under 20% of my life) -- but that's been my entire professional career. It's cultural differences like this that lead me to believe that America will never feel like "home" again -- I now can't imagine living somewhere where 6 weeks of vacation time seems like it's far outside the norm.
The UK minimum is "25 days, including Bank Holidays". Most decent places will make that "25 days, plus Bank Holidays". One place I worked did "25 days, plus Bank Holidays, but since we need in-office cover, you can work a Bank Holiday and take that day off somewhen else."
At $WORK, there's a process for automatically scanning docker images for packages that have CVEs against them. Any docker image that includes glibc instantly shoots to the top of the charts, mostly because of a boatload of high or critical severity CVEs relating to bugs in asm-implemented functions on platforms like ARM, POWER9, etc. Everything in our company runs on x86, but the CVE scanning tool is dumb, so a switch to alpine was heavily encouraged.
This broke teams that rely on python and on node, but the docker image guidelines come from a team whose ideal language is now go (and most of whose legacy code is in java), so they are not really sensitive to those concerns. Ironically we tried to move to distroless as implemented by google[1], but that's based on debian which includes glibc, so the un-nuanced CVE checker freaks out again. That effort was quietly dropped.
(I'm not actually disputing the proposition that alpine is better for security under certain circumstances, but I think a lot of "the push" comes from what might uncharitably be described as cargo culting, or with more insight as interpretations that make sense in one context [everything is a static binary, little to no reliance on traditional userland tools] being unquestioningly extended to other contexts.)
It's typical to use "to" rather than "in" when discussing odds. So the odds of getting a 1 on a 10-sided dice are 9 to 1 against (odds are also typically specified with the larger number first, because of the overlap between mathematical odds and betting-shop odds). And the probability of it happening is 1 in 10.
(I suspect that counter-pedantry on these lines might be part of why your post is getting downvoted; I wasn't one of the downvoters fwiw.)
It's less about pure random chance, and more about our uncertainty. Compare it to a weather forecast that says there's a 10% chance of rain tomorrow. In the same way that weather forecasts get better over time (better atmospheric measurements, more sophisticated computer models), we could potentially do more to measure what the outcome of the election will be. And it might be theoretically possible (albeit highly unrealistic) to predict it with complete accuracy, given enough data. But we're not in that situation, hence uncertainty.
(There are a couple of caveats about election forecasting as opposed to weather forecasting. The first is the "October surprise," a sudden revelation that changes the election. This cycle, it was arguably Trump's covid diagnosis, although that tended if anything to push the results further in the direction they seemed to be going on their own, rather than upset any trend. The second is that, unlike with weather systems, measuring voter behavior (and widespread reporting on these measures) can change people's behavior. The effect of this is hotly contested, but one of the many explanations of Trump's victory in 2016 which hinged on turnout in a few key states is that those states were predicted wins for Clinton, so Clinton voters didn't bother voting. Despite occasional jokes to the contrary, it doesn't rain just to spite the weatherman.)
My guess (for men, at least), is the still only partial eradication of homophobia from society. Before the 1970s or so, it was not threatening to be naked around other men because homosexual advances could be violently punished with relatively little fear of consequences. (This is at least my understanding, I was not alive at the time.) In present day European culture (including North America, Australia, etc.) expression of homophobia is not generally acceptable, but enough straight people are privately homophobic that they are not willing to participate in semi-public nudity. The exceptions to the generalization that group male nudity is not acceptable are either subcultures where overt homophobia is still practiced (fraternity initiations, some sports teams), or unusually "woke" spaces/groups.
In principle, we eventually may reach a stage where homosexuality is so destigmatized that straight men are not bothered by the possibility of being checked out while naked, and that might make public nudity once again acceptable in all-male spaces. I don't think it is particularly likely to happen soon given that there are other simmering cultural disagreements about how bodies relate to sexuality (e.g. how genital anatomy and gender identity interact) -- I think that consensus and stability around those questions are a precondition for the acceptability of same-sex group nudity.
The considerations for fully public (and by necessary implication all-gender) group nudity are broader, but I think an element of the above analysis is in the mix there too.
AFAIK vanilla GNU emacs uses NeXTStep APIs, which are also implemented by the GNUStep project[1]. So if/when X11 (and the many libraries that sit on top of it) learns how to do color emoji, then GNUStep can implement the Mac OS API, and emacs will support it.
The GNU position wrt. Mac support is that only the APIs that GNUStep also supports can be used. You may disagree with the principles underlying that choice, but it is a long-standing policy of the project. It was a mistake (according to this policy) for them to merge the emoji support, and when the mistake was pointed out they removed it. So it's a bit more nuanced than your comment makes out.
