teraflop

I remember Postgres in the early 2000s, and it didn't have anywhere near this level of problems. It had its issues, especially in terms of performance, and there were of course occasional correctness bugs that tended to turn up when you were doing something unusual. But you could certainly rely on basic SQL operations to work correctly.

Back of the envelope math:

If you measure by the product of throughput and distance traveled, for an item with a stack size of 100 (e.g. metal plates), the player's inventory adds up to roughly the same capacity as 2500 yellow belts. And that's assuming 100% utilization running back and forth in both directions, with no unused inventory space and no wasted time.

A basic assembler can manufacture 2500 belts in about 21 minutes. So as a rule of thumb, if you're playing for longer than 21 minutes, belts are worth the investment (at least for bulk transport of raw materials).

(I guess maybe add an additional factor of at most √2, since the player can run diagonally and belts are orthogonal.)

They do have such sensors, and have for many years! Japan's shinkansen pioneered this tech in the 1960s (and has an essentially perfect safety record). It's just that by necessity, the sensing is done through the tracks, rather than directly by the train cars.

You might be imagining something like the automated emergency braking that's used in automobiles, where radar is used to detect an imminent collision. But high-speed trains have stopping distances measured in miles, and it's not feasible for one train to detect another at such distances (especially e.g. on parallel tracks or around curves).

So instead the train positions have to be monitored and relayed by sensors in the tracks, which necessitates a coordination system. And it seems that that system is what broke down. The automated system should have been (and presumably was) fail-safe, but instead of stopping trains until it was fixed, the operators chose to override it and use a much more fallible manual signaling system.

> Stuff like this just further enhances my fear of collective travelling.

I'm sure you're already aware that this is an irrational fear. As bad as this accident is, and as reprehensible as it was that it was allowed to happen, I'm pretty sure there have still been significantly fewer fatalities per passenger-km in Spain this year than there have been on US highways. It's just that we've become numb to the fact that 100 Americans die in car accidents every day.

> I don’t think you can get the SCT from a log without the log publishing it?

Well you can, but only if the log cooperates.

That is, the SCT is merely a promise to add the certificate to the log by some particular deadline. Nothing technically stops the log from disregarding that promise. But if it does fail to log the certificate, the SCT itself is proof of its misbehavior.

And it's not enough to subvert a single log, because browsers require SCTs from multiple distinct operators in order to consider a certificate valid.

For some reason, the author chose to imitate a "strikethrough" text effect by following each letter with "U+0336 COMBINING LONG STROKE OVERLAY", rather than just using the <s> HTML element.

Yes, but for one thing, floating-point math is non-associative so even if you use the exact same random seed, you can get different results on different implementation kernels.

For another, the dependence on a random seed is just one example of how you can get different behavior. You could just as well get different results due to e.g. a tiny difference in prompt wording or punctuation or whitespace.

If a model passes some test on 70% of random seeds, and fails on the other 30%, then knowing the rough probability of success is much more useful than knowing one random sample of the outcome.

And empirically this kind of probabilistic success is quite common, because many LLM benchmarks report "pass@k" success rates that are much higher than the "pass@1" success rate on a single attempt.

I'm reminded of Vernor Vinge's novel Rainbows End, which is set in 2025. It features a cyberattack against a rogue AI, which involves revoking a root CA certificate belonging to Credit Suisse, causing massive collateral damage to the European economy and infrastructure.

Vinge didn't quite get to see his rogue AI prediction become (sort of) reality, right on schedule, but he did at least outlive Credit Suisse.

That's an excellent reason to change the page design occasionally, so that people learn not to rely on it (the hard way if necessary).

Ethernet flow control doesn't really fix congestion except in very special cases.

Consider a very simple topology:

    A         C
     \       /
      S1===S2
     /       \
    B         D

Say hosts A and B are both sending data to C, as fast as they can, via switches S1 and S2 (which are connected via a high-speed link). And say the sum of these two flows is more than the capacity of the link to C.

S2 is receiving packets destined for C faster than it can forward them, but sending an Ethernet pause frame from S2 to S1 is not a very productive way to alleviate the situation, because it also disrupts any traffic that would be bound for D. It just moves the bottleneck elsewhere and causes collateral damage.