I didn't watch the video -- and YT isn't letting me speed-read a transcript? -- but generally speaking, if you have a need for memory that isn't backed by the filesystem, and you're writing in C, just use malloc. It's designed for that purpose, although malloc might very well be calling to mmap to obtain an anonymous mapping under the hood. Even if you're going to hold on to memory for the entire lifetime of a program, still use malloc in C.

If your application does need some filesystem backing, or if you're allocating enough memory that hugepages might be reasonable, then that's when you'd want to use mmap.

Private party sales of cars in the USA use cash, yes. A fairly safe way to do this for a car is to do the sale in the lobby of the seller's bank or credit union. In specific detail, the buyer arrives and inspects the car to their satisfaction, they fill in most of the vehicle title transfer form but withhold the signature, then they go to the teller where the buyer produces the cash, the teller counts the funds and deposits it to the seller's account, and finally the buyer and seller sign the title transfer.

In this way, the buyer's risk is minimized (they're meeting in a quasi public place with cameras, so gunpoint robbery would be unlikely) and the seller's risk is minimized (they don't even have to handle or count the cash, so a bad buyer can't even rob them after the sale).

Not sure if this would be applicable to OP's situation, but it might be adaptable if the seller's bank is nearby and each party makes their own way to the bank to complete the sale, after inspecting the object.

Note: if instead of cash, the buyer pays with an official or cashier's check, then this whole procedure is still valid because the seller doesn't have to deal with the risk of a bad check: their bank has procedures to verify on-the-spot the funds on an official or cashier's check issued by another institution. For a personal check though, such checks have a TOCTTOU problem, so sellers should not accept such checks for the sale.

The CA cannot decypt: they don't have the secret key which only the server has. When requesting a new certificate from the CA, the server generated a secret key (aka private key) and then generated a derived public key that goes into a Certificate Signing Request (CSR). The CSR is what the CA receives, not the secret key, and then the CA returns the certificate file to the server, which has been endorsed by the CA and thus trusted by the user base.

Phrased another way, a certificate is the instrument that confirms that a purported public key can in-fact be safely used, and that no MITM attack is happening (assuming you trust the CA that signed the cert). But once you've confirmed the public key, the rest of the cryptography is public key cryptography, meaning the secrecy of the secret key is the whole game.

I'm deeply skeptical. If the whole premise is that natural language (which is how prompts to AI generation are given) is insufficiently precise to constrain output, and that formal specification is precise enough, then why are we bothering to use natural language generation? If this works as stated, then it's a tactic admission that the thing being checked is inherently flawed. Why not just use the formal specification to generate code then?

I suspect that two things are true: natural language is inherently insufficiently precise for nontrivial code generation, and also that formal specification is not broad enough to describe all the code which is being generated today using AI/LLMs.

Reliability of generated output was never an engineered goal for LLMs, and no amount of "reasoning by Lego" can fully compensate for this no matter how complex the mitigations in post. It's the same reason why safety (under any definition) cannot be "bolted on" to an LLM after the fact.

For folks that would like the cosmic distance ladder explained in video format, 3blue1brown sat down with Terence Tao: https://www.youtube.com/watch?v=YdOXS_9_P4U

Yes, it's that Terence Tao, the famed mathematician.

The 100 users for the Community edition is more of a suggestion and is not a hard cap, according to this answer: https://github.com/element-hq/ess-helm/issues/1027

I think Signal tries to be E2EE but has other problems, including that MLS (the E2EE mechanism) inherently requires a client app instead of being usable with just a browser.

I'm having trouble imagining what in Signal's implementation of the Double Ratchet, or any part of RFC9420 Message Layer Security, would inherently require a client app. Perhaps you mean that there is no readily available browser-implemented API for carefully managing secrets? Even in that situation, all the libraries needed to implement the RFC can be compiled as WebAssembly or to JavaScript (with the assumption that the browser and OS are outside a malicious actor's capabilities) and ran that way.

To be clear, I'm not suggesting Signal is perfect, and papers about problems found in Signal and other apps are readily found, like this one from last month. But with that said, it does appear that OP's described use-case involving hundreds of users in group chats is very much not what Signal was designed for,.

When examining why corporations toe the line for conservative endeavors, it's less useful to examine the financial aspect and more useful to look at the power dynamic. Oligopolies are like dictators, in that they need to occasionally perform a tour de force, as a way to suppress the exercise of soft power. That is to say, scare the opposition to fragment them and to disorganize them, so they don't get any bright ideas. Inspirational Skeletor warns precisely of this: https://mas.to/@skeletor/117191580571928662

What soft power would Visa and MasterCard have been afraid of? For context, in the USA, debit card transactions are capped at a fixed rate per transaction, whereas credit card transactions can have both a per-transaction and a percentage. Accordingly, the card networks would very much like to be processing more credit transactions than debit. But this revenue comes off the backs of consumers, in the form of higher prices because Visa's fee is rolled in, even for people paying with cash. Enough clamoring about cost of living could easily put the card processors front-and-center before a Congressional committee, a spotlight they don't really want.

Such furore would have to be driven from both consumers and businesses complaining about the extortionate practices by the card processors. Which is why the card networks hide in one domain and attack in another: deflect to greedy banks that are charging high interest directly to consumers (thus ignoring the cut that Visa/MasterCard take), and then clamp down on one segment of businesses, as a sign that they can be vicious if any other businesses start blabbing to the feds.

The card networks assume (unfortunately correctly) that small and medium businesses will not band together to overcome these monopolistic moves. And the largest businesses that process the most card transactions (eg Amazon, Walmart) are so entrenched in accepting card payments that they already negotiate deals directly with Visa and MasterCard, so they're not a risk.

In the end, this could be viewed as a conservative cause that happens to overlap with a need for a naked show of force. And in that endeavor, they've succeeded: every platform that takes cards is on heightened alert, and that's a real chilling effect on the marketplace. What Visa and MasterCard can do to one business segment, they can do to any other. But I guess for now, most businesses are just pricing that in as yet another "cost of doing business".

In a nutshell, an Australian anti-porn group put pressure on the credit card networks Visa and MasterCard, which process the grand majority of card payments worldwide, for both credit and debit cards.

https://www.thepinknews.com/2025/08/04/visa-mastercard-adult-purchases/

What remains unclear to me is why a somewhat obscure lobbying group was able to bring two American multinationals to heel. But in any case, I am of the opinion that this group sits well within the range of right wing reactionary, in spite of dressing itself up in the cloak of feminism. The group's Wikipedia page lists the founder as a conservative and anti-abortion activist.

As usual, Wilhoit's Law is instructive: this despicable group seeks to denigrate sex work, depictions of sex, and the legal market for sex art and anything arbitrarily similar, by denying this group of people from the financial system and from earning an income, and then leave them without any support or even a suggestion as to what these people should do instead. This is the "bind but does not protect" part of Wilhoit's Law. No different than American conservatives and TERFs that try to drive a wedge to isolate trans people, this group targets sex workers and they cannot be allowed to continue unabated.

The legal solutions are as straightforward as they seem: require that interstate financial services can only charge a fee if transactions are routed and processed neutrally. The economic solution would be the expansion of existing national payment clearing networks (ie ACH in the USA) to also process card payments as an alternative to the duopoly.

IMO, Leetcode and other programming exercises are a simulacrum for assessing aptitude. The exact exercise is not the point -- though many managers might think otherwise -- but rather is the process: can a candidate methodically approach a challenge with sufficient rigor as becoming of an engineer?

I've written before about what I look for when conducting interviews, in the context of embedded software engineers. In that realm, I'm usually probing for prior experience with computer architecture in general, not necessarily in the particular framework that the job will deal in. I want to see transferrable skills, because it's kinda rare to actually find perfect candidates that already meet our final requirements. So instead, I expect candidates to be quick studies, the sort of people that can draw analogies and get an approximate answer. Everything else can reasonably be looked up in man pages and web searches.

But this might just be specific to embedded, where we do actually care about the nitty gritty compiler and assembly details, when there's only 512 KB of RAM. And to be clear, a candidate that knows bit tricks will likely do well, but if that's the only tool in their toolbox and they don't or can't understand why writing maintainable, mostly-portable code is important in a medium sized organization, then that could be a problem. In this realm, programming exercises are still a view into a mindset. Other CS fields may vary.

My cursory understanding of the BlueSky/AT approach is that posts are not anchored to the identity, but to a value akin to a DOI like how research papers are referenced. And in that way, something like a BlueSky post can be hosted as a standalone document, whose provenance is through a linkage to the user identifier maintained by the separate identity infrastructure. I believe this is why hyperlinks to BlueSky posts do not -- and cannot -- include the author's handle, whereas Fediverse links often do (but aren't required to).

So yes, the server that hosts content is separate from the identity server. But the part I still don't see is how to update a document's associated identity if a user changes to a different identity server. It is indeed a separation of concern -- which is very healthy and I do follow developments in the AT space which could be used to drive improvements in the ActivityPub world -- but the same scenario is still doomed: if the identity server skips town suddenly, can former users restart with a new identity and reassociate to their prior documents? How can this be done securely?

But my original point remains: the challenge is nontrivial and no one should underestimate the complexity, whether it's in the ActivityPub or AT model. This federation thing is hard.

I'll take a stab at answering the titular question, which also requires answering the related question: "what really is federation?"

In my conception, federation makes the most sense if we rewind to a (almost) bygone era, in the early 21st Century where every specific communities hosted their own web forums, before a time when Facebook groups or Discord "servers" were mainstream. Of those, I think the ones which endured the longest are those related to automobile enthusiasts, usually about a specific model (eg Corvette), in order to exchange tips and servicing info.

What federation solves is the challenge of maintaining a different login -- aka identity -- on each web forum that someone frequents. Back then, it was a separate username and password for the car enthusiast forum, another for the regional gossip forum, yet another for the anarchist forum. And despite that, the underlying credential was usually the same: an email address.

So instead of managing an identity at each different web forum, federation is the idea of having a single identity that can travel to different domains. The open model of email is instructive, because sending an email necessarily interacts with the destination domain, which is usually not the same as one's own. Phrased another way, the postal system was the first federated communication system, where different states honored the single identity and allowed free* passage. One might compare this to one of the EU's four freedoms, the free movement of labor: a user may do work (ie write a post) on any instance in a federation, on equal standing whether they're local or not.

In the modern context in the 2020s, such a freedom is in stark contrast to the commercial alternatives: using a Facebook, Google, or Apple login to access any particular website more often than not puts oneself on a different (ie lower) standing than if they logged in with an untethered account. The usual problem is that such a common identity is tracked and sold to marketers, which explains why so many sites use these single sign-ons as a default, and only begrudgingly support "old school" account creation for that specific site.

And worse so, if Google decides you are unworthy of a Google Account, then you simultaneously lose your online identity and any semblance of access to those services which you were using. Federation solves the latter, because if your federated identity is banned from your home instance, the freedoms of federation means you can create an identity elsewhere and use that to access Fediverse services, apart from the one which originally had reason to ban you.

Nobody can deny you access to every instance, and that's what makes it powerful: there is no centralized arbiter for the network. Sure, this means there will be some very ugly parts of the Internet that get to exist and possibly interact with the rest of the decent web. But just like with the majors, the challenge of moderation still remains albeit different. Some segments are wholly an island unto themselves (eg certain right wing circles that also use Fediverse software) because nobody else will federate to their instance.

Going back to the original question, the central issue is that while the network is decentralized, a single identity necessarily is centralized on their home instance. And there's no real way around this, because having a single identity means it must be unambiguous to reference: if I @ you, there must be exactly one possible identity, or else everything breaks down. So the notion of "transferring" an identity would become a horrible routing kludge like how "portable telephone numbers" are implemented in the Telco space: the original exchange has to remain alive to forward to the new exchange. And that's basically unworkable in the decentralized Fediverse in general, because instances can come and go.

There is no way to guarantee that one's home instance stays alive forever, which limits the identity's lifetime. If we had it leave a note that you've moved, how to we retrieve the note after the original instance is down? Telco could do it because there's a centralized listing of all valid exchanges, but there is no such thing on the Fediverse. It's the sort of thing that requires a "dying message" ledger, and it's hard to imagine how something like DNS could solve that knowledge challenge issue.

At bottom, creating identity resilience is hard and we don't have it yet. But that's because federation was always going to be difficult, and in spite of that, we seek out the world we want, not compromise with the world we were given.