Then the question becomes: to what extent do you trust Xen and Qubes RPC?

I do have to somewhat trust Xen, but Qubes' isolation relies on hardware virtualization (VT-d), which statistically has much less security issues than Xen itself. Most Xen advisories do not affect Qubes: https://www.qubes-os.org/security/xsa/

Verified software should satisfy the liveness property; otherwise, an infinite loop that never returns would pass as "correct."

Verifying realtime software goes even further and enforces an upper bound on the maximum number of ticks it takes to complete the algorithm in all cases.

Just append

  X-Crawl-Reason: Finding spare license plates, throttled ONLY to prevent service disruption. To the best of my knowledge, [legalese claiming good faith and compliance to all applicable laws]

(Mandatory disclaimer: IANAL, ignorance is no excuse for breaking laws)

> Code is an asset.

Funnily enough, this doesn't contradict "code is debt" because Asset = Equity + Liability.

My next malloc(3) is returning NAN.

I've always considered NaN too definitive for general industry languages like C, JS or Cobol where not even physics with calculus should be assumed. Maybe its ok for languages that at least expect math for engineers like Fortran or up..

How about we call it "Maybe a Number" and since equality can't work for it we still need a separate way to ask like: Math.whoIsTheMaN(me)

maybe REST? I think a proper REST system of APIs is designed to be discoverable.

REST is a design principle, not a protocol.

As such you can make a REST system discoverable via e.g. external schemas (commonly OpenAPI) or self-documentation but there is no guarantee that either exists, and while the latter is intrinsic there is no standard discovery mechanism for the former (cf openapi-specification issues 724 or 2128).

Probably something like

  Error: stepping, NOT NULL constraint failed: messages.dkim (19)

because, unlike MySQL, SQLite apparently returns SQL NULL for JSON null value.

The affected platforms lack an OS (e.g., bootloaders) and/or an MMU/MPU (e.g., microprocessors like AVR)

I don't care about platform specific stuff. I'm talking about C which is actually intended to be portable. Nothing written with portability in mind in the past ~decade is going to be doing this.

C is not node.js. C exists for 50 years and is expected to have stable API. In scientific circles it's not unusual to compile c and f77 libraries built in the 70's, 80's.

BLAS, gemv, GEMM, SGEMM libraries are from 1979, 1984, 1989. You may have seen these words scroll by when compiling modern 2025 CUDA :)

I was writing C long before node.js existed :)

C has no backwards compatibility guarantee, and it never has. Try compiling K&R C with gcc's defaults, and see what happens.

You can build your legacy code with legacy compiler flags. Why do you care about the ability to build under the modern standards?

I think we're going a bit past each other.

In AVR or other MPU-less architecture you can literally modify the string literal memory without triggering a crash.

Why? Because there is no memory protection ("rodata") at all.

And such microprocessors are still in use today, so it's a bit too far fetched to say "really old code."

It's UB, sure, but how many embedded programmers actually care? The OP's proposal is trying to change the type system so that this UB becomes much less likely to trigger in practice.

Quoting a paragraph from OP (https://www.anthropic.com/research/tracing-thoughts-language...):

> Sometimes, this sort of “misfire” of the “known answer” circuit happens naturally, without us intervening, resulting in a hallucination. In our paper, we show that such misfires can occur when Claude recognizes a name but doesn't know anything else about that person. In cases like this, the “known entity” feature might still activate, and then suppress the default "don't know" feature—in this case incorrectly. Once the model has decided that it needs to answer the question, it proceeds to confabulate: to generate a plausible—but unfortunately untrue—response.

Fun fact, "confabulation", not "hallucinating" is the correct term what LLMs actually do.

Fun fact, the "correct" term is the one in use. Dictionaries define language after the fact, they do not prescribe its usage in the future.

Confabulation means generating false memories without intent to deceive, which is what LLMs do. They can't hallucinate because they don't perceive. 'Hallucination' caught on, but it's more metaphor than precision.