teraflop

The part of the article about the 158,000x slowdown doesn't really make sense to me.

It says that a nested query does a large number of iterations through the SQLite bytecode evaluator. And it claims that each iteration is 4x slower, with an additional 2-3x penalty from "cache pressure". (There seems to be no explanation of where those numbers came from. Given that the blog post is largely AI-generated, I don't know whether I can trust them not to be hallucinated.)

But making each iteration 12x slower should only make the whole program 12x slower, not 158,000x slower.

Such a huge slowdown strongly suggests that CCC's generated code is doing something asymptotically slower than GCC's generated code, which in turn suggests a miscompilation.

I notice that the test script doesn't seem to perform any kind of correctness testing on the compiled code, other than not crashing. I would find this much more interesting if it tried to run SQLite's extensive test suite.

Note that this article's summary has a significant error compared to the original press release[1]. The article says "90% range", whereas the press release says "90% capacity retention".

This is a big difference because there are all kinds of other factors besides energy capacity that can affect the efficiency of the whole system, and therefore affect range.

Most notably, air is about 28% denser at -40°C than at 25°C, so drag is about 28% higher. So you would expect roughly 28% less range at high speeds even if the battery has no capacity loss whatsoever.

As someone else mentioned, climate control also consumes a lot more power when it has to maintain a larger temperature difference between inside and outside.

[1]: https://www.catl.com/en/news/6720.html

Well, I think the paper answers that too. These problems are intended as a tool for honest researchers to use for exploring the capabilities of current AI models, in a reasonably fair way. They're specifically not intended as a rigorous benchmark to be treated adversarially.

Of course a math expert could solve the problems themselves and lie by saying that an AI model did it. In the same way, somebody with enough money could secretly film a movie and then claim that it was made by AI. That's outside the scope of what this paper is trying to address.

The point is not to score models based on how many of the problems they can solve. The point is to look at the models' responses and see how good they are at tackling the problem. And that's why the authors say that ideally, people solving these problems with AI would post complete chat transcripts (or the equivalent) so that readers can assess how much of the intellectual contribution actually came from AI.

I don't mean this as a knock on you, but your comment is a bit funny to me because it has very little to do with "modern" databases.

What you're describing would probably have been equally possible with Postgres from 20 years ago, running on an average desktop PC from 20 years ago. (Or maybe even with SQLite from 20 years ago, for that matter.)

Don't get me wrong, Postgres has gotten a lot better since 2006. But most of the improvements have been in terms of more advanced query functionality, or optimizations for those advanced queries, or administration/operational features (e.g. replication, backups, security).

If you read the discussion, they weren't kept because of their encyclopedic value, or because they were "widespread". I'm not sure why the parent commenter said that.

They were kept to preserve a record of their having been uploaded, and to not create a legal risk for third parties who might be relying on the Commons page as their way to provide attribution.

The original proposal was to keep the image pages with the metadata, but delete the image files. That turned out to have some technical hurdles, so instead the images were overwritten with versions containing big ugly attribution messages, to discourage their use.

Serious question: if the chance of evidence leading to a convistion is very very small, what would be the benefit of opening an investigation? Just to go through the motions on principle? And what would they even investigate?

I'd guess that everybody involved (including the coroner's office) tacitly understands that even if the baby was deliberately or negligently killed, there's very little chance after 20 years of finding evidence of who did it, in order to demonstrate guilt beyond a reasonable doubt. And if there's no chance of a conviction, there's no benefit to anybody from reopening the investigation.

The scientific case about infant opioid poisoning in general is a separate issue, of course. But assigning blame in this particular case doesn't have any bearing on that.

They said "could", not "should".

I believe the point is that it's much easier to create a plausible justification than an accurate justification. So simply requiring that the system produce some kind of explanation doesn't help, unless there are rigorous controls to make sure it's accurate.

The Internet Archive supports full-text search on (AFAIK) its entire scanned book collection, even books that aren't available for borrowing.

I don't really understand what you mean by this or how it relates to what I said.

I certainly wasn't suggesting that you can vertically scale a service to handle unlimited traffic on a single instance.

The point is that if you have stateless services, where the resources being consumed per request are mainly CPU and network bandwidth, then "scaling independently" is not a useful thing to do. You can just scale everything instead of artificially restricting which instances can handle which kinds of requests.

> You can easily scale different parts of your application independently.

Just to add that I think some people assume this is something they need, even when there's no basis for it.

Do you actually need 1 instance that handles Foo-type requests, and 99 instances that handle Bar-type requests, or would you be fine with 100 instances that are capable of handling either Foo or Bar as necessary?

The distinction only really matters if there is some significant fixed overhead associated with being available to serve Foo requests, such that running an extra 99 of those processes has a cost, regardless of how much traffic they serve. For instance, if every Foo server needs GBs of static data to be held in RAM, or needs to be part of a Paxos group, or something like that.

But if your services are stateless, then you probably don't benefit at all from scaling them independently.

Come on, even if that's true, it's obviously a very different situation.

For one thing, the grocery store is deciding what produce to stock and what suppliers to get it from. They can choose suppliers that have at least a minimum standard of quality. They don't just let anyone on the world slap a barcode on anything at all, claim it's a grapefruit, and put it into their stores.

For another, a large fraction of produce (though not all) is bought in person, and customers can see if it's obviously bad quality before buying it, unlike Amazon where all you have to go by is the product listing for the SKU.

> We pay roughly $0.30 per million requests

But the per-request cost is not the only one. You're also paying $0.02 per million CPU-microseconds. If you do the math, that's easily double or triple the equivalent hourly charge for VM instances from the various major cloud providers.

For now, you're benefiting from the zero idle charges and Cloudflare's generous free allowance, because you're at a small scale. As you get bigger, the effect of those factors -- as a fraction of your total spending -- will decrease by a lot, and you'll still be paying the inflated unit costs.

Go does hardcode system call numbers on Linux, but it doesn't on Windows. Instead it follows the normal Windows convention of calling the userspace wrappers from kernel32.dll and similar libraries.

https://cs.opensource.google/go/go/+/refs/tags/go1.25.6:src/...

Unlike on Linux, the low-level syscall numbers on the NT kernel are highly unstable across releases, so programs that try to call them directly will generally only work on a very specific kernel version.

There's a similar anecdote in Iain M. Banks' The Player of Games.

https://scifi.stackexchange.com/questions/270578/negotiator-...

In that respect, it reminds me a bit of the busy beaver problem.

I wonder: consider the decision problem of determining whether or not a given still life is glider-constructible. Is this problem known to be undecidable?

It's straightforward to show that an "inverse" of this problem -- given an arbitrary glider construction sequence, does it result in a still life? -- is undecidable, because gliders can construct patterns that behave like arbitrary Turing machines.

Cool demo!

I notice that the stars don't seem to be rendered correctly. If you zoom out, you can see the sun's position relative to the stars. As you scroll the date slider through the course of a year, the sun should make a complete 360-degree revolution around the ecliptic. Or, when the camera view is locked to the sun, the stars should appear to revolve relative to the sun.

Instead, the sun appears motionless against the stars, regardless of the time of year. (If the demo used actual star positions, I would be able to point to how the sun was in the wrong constellation for a given date. But the starfield is randomly generated, so you have to actually observe the sun in motion to see the bug.)

I guess it's just a display bug, then? Though it's hard to imagine what kind of bug would lead the game state and the visual representation to get out of sync in that particular way.

Don't get me wrong, it's fun to see performance optimizations like this.

But I'd expect that a naive implementation of the same strategy would already take like 0.1% of the time needed to actually generate embeddings for your chunks. So practically, is it really worth the effort of writing a bunch of non-trivial SIMD code to reduce that overhead from 0.1% to 0.001%?

It's referring to this: https://en.wikipedia.org/wiki/O-ring_theory_of_economic_deve...

The name is a reference to the Challenger disaster, which was caused by a failure of actual sealing O-rings, but the theory itself is abstract.

Basically, it's modeling complex production chains where the quality of the "weakest link" is the limiting factor of the quality of the whole process.

Careful -- that statement is half true.

It's true that no matter what symbolic representation format you choose (binary or otherwise) it will never be able to encode all irrational numbers, because there are uncountably many of them.

But it's certainly false that computers can only represent rational numbers. Sure, there are certain conventional formats that can only represent rational numbers (e.g. IEEE-754 floating point) but it's easy to come up with other formats that can represent irrationals as well. For instance, the Unicode string "√5" is representable as 4 UTF-8 bytes and unambiguously denotes a particular irrational.

You're muddying the waters by using the word "received".

The instant in time at which your letter is technically "received" by the USPS, in the sense of them having physical possession, has never mattered for any legal purposes whatsoever. That's because in many cases, there is absolutely no physical proof of exactly what instant in time that event happened.

Electoral rules aren't written based on when the USPS received your ballot, because that's typically unprovable. They're either based on when the ballot was delivered to the election office, or when the ballot was postmarked. The postmarking may happen at some point while the piece of mail is in USPS custody, or it may not happen at all if you don't specifically ask for it.

The rules are based on the postmark date because the postmark date is the only available documentary evidence of the date of mailing.

Again, this is not a change in policy, it's merely documenting the way the mail system has always worked.

The title of this summary blog post is grossly misleading. (To the point where I suspect it of being an AI hallucination, thanks to its use of ChatGPT's distinctive formatting style of bulleted list with Capitalized Colon-Delimited Headers:.)

As the linked PDF explains, this is not a change to the postmark date system. It's an acknowledgement that the date on the postmark may not be the date that you dropped the letter into a (possibly unattended) mailbox. This has always been true, because the stamping is not done until USPS actually processes the letter. USPS has no knowledge of when the letter physically "entered USPS custody" by being dropped in the mailbox, so the postmark has never accurately reflected that instant.

This rule does not change when postmarks are applied, and it doesn't change how any other parties make decisions based on postmarks. It merely documents the postmarking process that has existed basically forever.

That was already the case. This "rule" is not any kind of change in process, it's just a formal acknowledgement that the situation you're describing can happen. Why do you think that acknowledgement is a problem?

Maybe they are making progress. But given that they first started talking about this in 2018, and then in 2022 they announced that they were planning to release a version with CoreCLR in 2023, and then in 2024 they said it would be in beta in 2025, and now in 2025 they're planning to release it as a technical preview in 2026, but they're still talking about an "internal proof-of-concept" as though it's something coming in the future...

As an outsider, it certainly seems like there's reason for skepticism.

That 1956 article on the long-distance telephone network is fascinating reading.

The chart on page 24 gives the very first division of the US phone into area codes, many of which have of course remained unchanged today.

From page 82, when discussing automated in-band signaling on the phone lines:

> The signal component is a band about 100 cycles [Hz] wide centering on the signal frequency [2600 Hz]. [...] In the talking condition (tone off in both directions) the guard detector sensitivity is such that almost a pure tone is required to operate the receiver since other than signal frequencies will produce a voltage opposing its operation. The guard feature prevents false operation of the receiver from speech signals.

Of course in hindsight, the flaw in this is obvious. The guard band prevents accidental triggering of the signal mechanism by ordinary speech. It does nothing to stop someone from intentionally playing a pure 2600 Hz tone into the telephone handset, using e.g. a whistle from a cereal box.

The thing is that the abundance of IPv6 addresses enables fewer prefixes to be used, by allowing addresses to be allocated in much larger chunks.

For instance, Comcast (AS 7922) owns about 2^26 IPv4 addresses, distributed across 149 different prefixes. Almost all of these prefixes are non-contiguous with each other, so they each require separate routing table entries. Comcast can't consolidate those routes without swapping IP address blocks with other networks, and it can't grow its address space without acquiring new small blocks. (Since no more large blocks are available, as this article discusses.)

In contrast, Comcast owns about 2^109 IPv6 addresses, which are covered by just 5 prefixes (two big ones of 2^108 each, and three smaller ones). It can freely subdivide its own networks within those prefixes, without ever running out of addresses, and without having to announce new routes.

"The administration" is not a monolithic entity. For the last ~150 years, even though it's had political appointees at the top, the vast majority of its employees have been selected (at least ostensibly) on the basis of merit, not political loyalty. They're supposed to be somewhat insulated from the changing political winds. The layers of bureaucracy in between were created deliberately, to preserve some degree of decision-making independence.

When people talk about "the Trump administration tightening its hold", they mean Trump and his political appointees exerting direct control over things that have a strong precedent for being out of their direct control.

Using the word "administration" to conflate the presidency with the layers of organization below it is the main premise of the "unitary executive theory", which is an extremely recent development of the current Supreme Court. Previously, when Congress said "such-and-such a decision is supposed to be made by the staff of agency XYZ, not by the President/Secretary personally", the courts assumed they meant it.

> Expectations vs systemd/supervisord/tmux/dtach: where would you use this?

Sorry to be blunt, but I feel like this is a big unanswered question that you should be addressing. Why would I use your tool over the other well-known alternatives? I read through your overview and I don't see an answer.

You say that this is intended "for environments where you don’t want to stand up a full supervisor stack (or don’t have one)". And you compare it to systemd. But what Linux developer doesn't already have systemd installed?

Or to use a different comparison, what advantage does "fws run" have over "podman run"? Podman already supports PTYs that can be attached/detached, allows isolating different processes, and has an HTTP API.

It seems like you intend this for situations where you want a multi-pane text-base UI that resembles an IDE. But personally, I prefer to do this sort of thing by composing existing tools that provide that functionality (namely tmux/screen and Docker/Podman) rather than using a single integrated tool that tries to replace both.

The "incorrect state" being talked about is the IP prefix being misregistered in ARIN's database.

The "hijacking" happened later, when the IP prefix was announced via BGP by the registrant who it was incorrectly assigned to. Those are two different events.