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.

> these were tests done on pre release builds

That's a convenient excuse, because now the website calls them "release candidate" builds, but as far as I can tell there was no such disclaimer back in May. As mentioned in the report, the Docker images were specifically advertised as being production-ready.

https://web.archive.org/web/20260518201315/https://particled...

https://web.archive.org/web/20260518200305/https://particled...

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.

Yes, absolutely, that one drives me crazy too.

I think LLM-speak is heavily biased towards using as few words as possible, and as basic words as possible, even when that hurts overall clarity. To use another XKCD example, it often reminds me of "Up Goer Five": https://xkcd.com/1133/

I sort of agree but I think the issue is more subtle.

Languages change over time, and one of the well-documented "laws" of language change (using that term very fuzzily) is that people like to take irregular features of a language and generalize them to make them more regular. And there are many English verbs (particularly verbs expressing a change of state) which can be used transitively or intransitively, with equal validity:

> "I opened the door" -- "the door was opened" -- "the door opened"

> "the heat melted the ice" -- "the ice was melted" -- "the ice melted"

> "the impact cracked the glass" -- "the glass was cracked" -- "the glass cracked"

This generalization has been common, especially in jargon-y contexts, long before the rise of LLMs. A pedant might insist on saying "wait for the compiler to compile the code", and Merriam-Webster thinks "compile" can only be used transitively. But I think most developers would say "wait for the code to compile [i.e. be compiled]" is fine too. (see e.g. this XKCD comic from 2007: https://xkcd.com/303/)

In my view, this usage is completely fine as an occasional thing, especially when the social process of language change has normalized it over time for a particular verb. The issue is that LLMs drastically overuse it and pepper it everywhere. Just like "it's not X, it's Y", which is fine occasionally in human writing, but has become a dreadful cliche through overuse.

I don't know precisely what to call it, but there is something about AI's word choice and phrasing that really stands out to me.

It's like it chooses "simple" words, but uses them in unclear or fuzzy or slightly abnormal ways that make the overall meaning more difficult to parse. On its own, each instance is defensible, but the aggregate result when it happens many times over is very tiring to read. It reminds me of XKCD's "Up Goer Five": https://xkcd.com/1133/

Like this:

> One waits for an expensive ad, then asks for a hand you can’t place.

It reads as though it started with a straightforward idea, and then was forced to express it with words of only one syllable.

> 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.

The difficulty with "alignment" is that you have to specify whose goals and values the model is supposed to be aligned with.

Maybe for you and me, this kind of behavior would count as misalignment. But there are certainly a subset people out there for whom the opposite is true. If they tell the agent "get me my refund by any means necessary", harassing bureaucrats and manufacturing excuses is exactly the behavior the want, because it's what they would do themselves if they had the time and patience.

Think about the kinds of people who will escalate petty grievances with their neighbors by weaponizing the police, HOAs, public opinion, etc. Or see this news article about a German tourist who visited NYC for a week and ended up filing three lawsuits, including one against a taco restaurant for having salsa that was too spicy, and one against Wal-Mart because he couldn't get their Wi-Fi to work:

https://www.nytimes.com/2026/03/14/nyregion/german-tourist-n...

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 believe the answer to your question is that the structure is "connected" to form a solid piece of material, but like any real material it isn't perfectly rigid. So it can vibrate, kind of like a tuning fork, and the thinner parts can act as springs. See the diagrams here: https://pmc.ncbi.nlm.nih.gov/articles/PMC9571586/

If you wanted to use such a device as a simple oscillator, you just set it vibrating and measure the oscillation frequency. Since the material isn't perfectly elastic, the vibrations will eventually be damped and die out (I guess this is what you mean by "friction"), so you use a feedback mechanism to keep the oscillation going.

A gyroscope works the same way, except that you use feedback to maintain an oscillation in one axis, and measure how much of that oscillation couples to a different axis. Whatever effect the damping has on the final measurement, I would assume it can be easily calibrated out.

I don't really know how they physically manufacture these devices without damaging the tiny, delicate structures. It's kind of mindblowing that they're so incredibly cheap.

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.

I'm no biologist, but it's pretty easy to imagine a plausible mechanism.

Stress doesn't cause your body to "immediately grenade itself", it causes gradual problems over an extended period. But you can imagine that evolutionarily speaking, a stressful situation would frequently be a situation involving imminent danger. A response that prioritizes short-term survival (e.g. releasing adrenaline and cortisol) regardless of the long-term consequences could easily improve evolutionary fitness.

The lunar near side is not shielded from impact craters in any significant way. Impactors can cross the earth's orbit and hit the near side of the moon just as easily as they can hit the far side.

The fact that the near side appears to have large areas with few craters, and the far side doesn't, is a result of many near-side craters having been erased by lava flows. It's not because it received fewer impacts.

The article says a new crater this size is expected about once every 132 years. Presumably, smaller craters are more frequent. So what's the approximate size of the largest crater that you'd expect, say, in an average year? And would it be scientifically useful to design a mission around sending a rover to explore one of those brand-new craters?

It's at the top of the article:

> but for the overview and demo of it working, watch the following youtube video.

If you don't care about the overview and just want to see demos, they start around 9 minutes in.

The "normalization of inexplicability" is indeed infuriating. It has always been bad when it comes to computer software, and it's increasingly creeping into other consumer products that depend on embedded software.

I bought a new electric car recently. For the most part I've been quite happy with it. Shortly after I bought it, it started popping up a warning message saying "check EV system" every time I started it. By the time I brought it into the dealership, the warning had gone away, and the technician just told me something to the effect of "eh, I guess it just does that sometimes, let us know if it happens again." Hardware fault? Software bug? Who can say?

Like most modern cars, it has connectivity and Google Maps built into the infotainment system. The vast majority of the time, it works fine. Sometimes it says it has no connectivity (meaning no traffic data and suboptimal routes) for the duration of a drive, even in areas with a strong cell signal where it normally works fine. Sometimes the car says it has connectivity, but Google Maps still thinks it's offline. Sometimes Maps will actually load and display a route, but the "start navigation" button just spins forever as though it's still waiting for something. Are these related issues? Is there a common cause that might be fixable? Who can say?

(Conveniently enough, the warranty specifically does not cover any failures of software or firmware to operate correctly.)

The flip side of this laziness is that now, when my elected representatives tell me "these are just license-plate readers that don't record video", I have evidence to show them that's false.

If Flock had done a more competent job of securing their system, it would be harder to demonstrate this in a compelling way. To a technically-inclined person, it's obvious from the get-go that somewhere in Flock's pipeline, video is being recorded and archived, and is therefore vulnerable to misuse. But the more they're allowed to keep the implementation proprietary, the easier this is to sweep under the rug.

Separately from how you present the number, the very concept of "uptime" as a single number is a bit muddy in the context of a distributed system, where different components can be differently available for different users.

Also, 0.1% downtime in the form of a 45-minute outage per month is very different from 0.1% of requests failing in brief bursts. You often see downtime reported as "increased error rates" which is so vague as to be meaningless.

Google's "windowed user-uptime" attempts to deal with this a bit better, by exposing different views of the data instead of trying to condense uptime into a single number: https://www.usenix.org/system/files/nsdi20-paper-hauer.pdf

Beyond "not working", concurrent editing is likely to silently lose data, or corrupt data, or possibly just fill up your drive with lots of "conflicted copies" that you have to manually reconcile.

For anyone who finds themselves in the vicinity of Atlanta. I can highly recommend the Mimms Museum of Technology and Art. Which was also formerly called the Computer Museum of America, but AFAIK has no relation to the one in San Diego.

Anyway, it's clearly a labor of love. They have some very cool artifacts from the space program (e.g. a some of the Space Shuttle and Apollo main computers). And a large fraction of the floor space is devoted to a new, very comprehensive exhibit on the history of Apple, with just about every product they ever made plus some internal prototypes.

The blog post doesn't seem to mention what strikes me as the most interesting application of a model like this, namely extracting semantic information from its latent space. It mentions robotics applications, but only in the context of generating realistic world models for simulation.

If you have a robot deployed in an environment, generating synthetic views of the environment you're in doesn't have any obvious value. What does have obvious value is the latent knowledge that the model could have used to generate those synthetic views.

For instance, the fact that Atlas is capable of identifying regions of the input images that look like "floors", and smoothly interpolating them and filling in gaps with more floor, suggests that it has a concept of "floor-like walkability" which it's learned from the examples in its training data. And being able to identify the regions of 3D space that correspond to that semantic label would obviously be useful for robot path planning.

There's plenty of literature about e.g. using neural networks to estimate walkable areas from a point cloud. And you could imagine just bolting one of those methods to the front of Atlas, using the synthesized point cloud (instead of traditional photogrammetry or LIDAR) as input. But that seems like it's throwing away a lot of potentially useful semantic information, on top of being needlessly inefficient.

Surely there are all kinds of interesting and constructive classroom discussions to be had about lawbreaking.

Classrooms teach about reality (among other things) and there are many things in reality that don't involve obedience to the law, as it exists at a particular time and place.

See also: https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...

Clearly these products are being named by topologists, who have no objection to things being simultaneously open and closed.

Another interesting non-hypothetical example: many US states have so-called "blue alerts" which are used to send cell phone alerts whenever a police officer is attacked or injured. I used to live in Texas and blue alerts were a fairly frequent occurrence.

The stated justification for blue alerts is to warn the public of dangerous criminals. But they are only issued in response to attacks on cops, regardless of the level of danger to any other people. Also, at least in Texas, they're broadcast statewide. Texas is an awfully big state, and so the alerts are guaranteed to be irrelevant and non-actionable for the vast majority of people who receive them.

So it's fairly obvious to me that blue alerts are first and foremost a propaganda operation, aimed at perpetuating the stereotype that policing is a uniquely dangerous job. (It is indeed more dangerous than an average office job, but it has a much lower rate of fatal injuries than construction, or farming, or driving garbage trucks.)

> The workflow had an if: condition that appeared protective:

> if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

> However, on issues events, github.event.pull_request is always null.

This is extra dumb because even if you thought this condition was correctly testing the user's identity, it shouldn't have "appeared protective" upon even a moment's thought. If it worked correctly, it would obviously just exclude one bot user while allowing all other users, so it wouldn't provide any protection at all.

But more likely, this condition was never intended to be "protective" at all, and it's only being described that way because the writeup is LLM slop.

Because this particular sensor network is only monitoring earthquakes in the Pacific Northwest of the USA, not worldwide.