rst

Unfortunately, we seem to already have an example of an LLM producing a proof in a week known open problem (the Collatz conjecture) in which it looks like it was sneaking a flawed proof through bugs in the proof checker. https://infosec.exchange/@0xabad1dea/117002106099986943

Maybe don't reassign the sesssion to a different client so long as there's a cursor open (the way that most poolers have a mode that won't reassign a session that has a transaction open)?

One partial mitigation is to ask it to use plan mode -- and then very carefully review the plan before allowing it to execute.

Most of the time, the agent should be able to run the code and observe the errors for itself, but there are exceptions. For instance, I've had agents write code that's used to process data which, by company policy, can't be exposed to cloud services (confidential customer communications, etc.), a prohibition that includes cloud-hosted LLMs. When that blows up, I've had to give it a bug report -- what I do then to avoid excessive back-and-forth is to package it up well enough that the bot can reproduce the failure on sanitized excerpts and produce a fix autonomously using that.

They're kind of at the mercy of the US government on this, and the government seems to have them in the position you describe.

It couldn't run "hello, world" on systems where the include files were not located in the directory that it expected -- producing instead diagnostics saying, quite clearly, that the header files were not found. On systems where they were, it built versions of postgresql, redis, and several other things which passed their test suites completely.

If you've heard this problem described as a fundamental limitation of the compiler, and not the kind of packaging glitch that's routine to find in pre-alpha software of all descriptions, whoever described it to you that way is not serving their readers well.

I'm not saying CCC was production-ready, or close -- the total lack of an optimizer would be a killer in any real use, and I assume that there were problems with the diagnostics at least as bad as problems with performance and the include files, for similar reasons -- the LLMs hadn't been asked to optimize for that stuff yet, just test suite correctness. But it did achieve that, and the amount of cope I've seen on social media claiming otherwise is more than a bit disturbing.

Also, a lot of them talk about finding the same vulns -- and not about writing exploits for them, which is where Mythos is supposed to be a real step up. Quoting Anthropic's blog post:

"For example, Opus 4.6 turned the vulnerabilities it had found in Mozilla’s Firefox 147 JavaScript engine—all patched in Firefox 148—into JavaScript shell exploits only two times out of several hundred attempts. We re-ran this experiment as a benchmark for Mythos Preview, which developed working exploits 181 times, and achieved register control on 29 more."

https://red.anthropic.com/2026/mythos-preview/

On the flip side, I'm not sure I ever saw a revenue plan or exit strategy for Astral other than acquihire. And most plausible bidders are unfortunate in one way or another.

Well-known vulns are all over this code. For example, mkdir had a TOCTTOU which persisted into v7 (and I believe 2BSD); it was implemented as a setuid binary which did a mknod followed by a chown to create the directory. Code which invoked mkdir could set up a race replacing the root-owned directory, before the chown, with a link to something else -- which would then get chowned to the user running mkdir. The target had to be on the same filesystem as some writable directory, but on many installations of the day, a mkdir in /tmp followed by this race was good enough to get you ownership of /etc/passwd.

This was finally cleaned up in 4.2bsd, when mkdir was made a single syscall which was guaranteed to alter only the particular inode it allocated.

They were already mailing distribution tapes -- the software being run here was extracted off one of them (which had literally been lost in a store room for decades).

Anthropic's ahead of you -- the LLM that the reporters were interacting with here had an AI supervisor, "Seymour Cash", which uh... turned out to have some of the same vulnerabilities, though to a lesser extent. Anthropic's own writeup here describes the setup: https://www.anthropic.com/research/project-vend-2

Ummmm... yes. The problem with versioning file systems is that they only kept the last few versions; for files under active development, it was usually difficult to recover state older than a week or two.

(SCCS handled collaborative development and merges a lot worse than anything current, but... versioning file systems were worse there, too; one war story I heard involved an overenthusiastic developer "revising" someone else's file with enough new versions that by the time the original author came back to it, their last version of the code was unrecoverable.)

According to Wikipedia,there are apps that provide an emulated Android environment ("Easy Abroad", "Droitong"), they're incomplete and glitchy, and a lot of important apps won't run at all (including banking apps and streaming services).

If the libraries were missing entirely, I'm not sure 32-bit Firefox would even start. But if they were present and nothing was keeping them updated (pretty likely on an otherwise 64-bit system), they'd pretty likely become out of date -- which could certainly explain spurious crashes.

It already is fixed -- the complaint is that customers haven't been notified.

People go through all sorts of weird mental gymnastics about this. The FSF at one point took the position that binary blobs were cool so long as they could not be upgraded, because then you could pretend they weren't software at all, but just part of the wiring. I've seen this odd line of thought attributed to RMS himself, but here's an FSF statement, from when he was running it: https://www.fsf.org/blogs/community/task2-openmoko

WASM has a better security sandbox. (Designed in from the beginning, not the thousand-fingers-in-the-dike retrofit that was the Java SecurityManager -- which was eventually deprecated and abandoned along with the Applet tech it was intended to support.)

The numbers are branding, not metrics on anything. You can't do math to, say, determine the capability jump between GPT-4 and GPT-4o. Trying to do math to determine capability gaps between "3.7" and "4.0" doesn't actually make more sense.

In all those respects, the VAX was just following on to the IBM 360/67 and its S/370 successors -- they all had a register file of 32-bit general purpose registers which could be used to index byte-addressed virtual memory. It wasn't exactly an IBM knockoff -- there were a bunch of those, too (e.g., Amdahl's) -- but the influence is extremely clear.

You might want to be more specific by what you mean by "modern", because there were certainly machines with demand-paged virtual memory before the VAX. It was introduced on the Manchester Atlas in 1962; manufacturers that shipped the feature included IBM (on the 360/67 and all but the earliest machines in the 370 line), Honeywell (6180), and, well... DEC (later PDP-10 models, preceding the VAX).

Faint echoes of the very first optimizing compiler, Fortran I, which did a monte carlo simulation of the flow graph to attempt to detect hot spots in the flow graph so it could allocate registers to inner loops first.

Comments describing the organization and intent, perhaps. Comments just saying what a "require ..." line requires, not so much. (I find it will frequently put notes on the change it is making in comments, contrasting it with the previous state of the code; these aren't helpful at all to anyone doing further work on the result, and I wound up trimming a lot of them off by hand.)

The objection was to a separate file entirely outside of his subtree, describing its interface, which is apparently supposed to be duplicated instead in each rust driver that references it, for no clear reason -- other than his stated reason of not wanting to see languages other than C in the kernel at all.

They're assuming very quick transfers (rush hour service). But then again, a lot of transit planning seems to assume rush hour commutes are the only reason why it's there.

There are a few -- select the 79th street station on the #1 line (farthest west in Manhattan) and look at Brooklyn, due pretty much directly south. The 36th Street station on the D/N/R lines is reachable in 40 minutes because it gets express service, but the stations to the north and south are local stops, and for that reason, take longer to get to.

OpenAI is extremely cagey about what's in their test data set generally, but absent more specific info, they're widely assumed to be grabbing whatever they can. (Notably including copyrighted information used without explicit authorization -- I'll take no position on legal issues in the New York Times's lawsuit against OpenAI, but at the very least, getting their models to regurgitate NYT articles verbatim demonstrates pretty clearly that those articles are in the training set.)

Obfuscation isn't really possible. The identities of the crew are very public, and they all got hospitalized, so there isn't even room for guessing games about which one.

Note also that the two museums have different schedules, so you'll want to make sure you go when both are open.

SFO security is run by some company "under contract" to TSA -- probably required to follow all the same procedures, so it's not clear the business arrangement makes that much difference to the passengers. I've been through there a few times, and haven't found it any more organized or pleasant...

https://www.flysfo.com/about/airport-operations/safety-secur...

Also, some of this is accounted for by a difference in development philosophy. The typical NASA project tests finished designs to make sure that they'll work. SpaceX frequently (currently for Starship) tests half-finished designs because they want to know how they will fail, for future revision. (Example: between starship flight tests 1 and 2, the whole staging method changed; forward fins are being relocate on Starship starting, I think launch after next to reduce heating in reentry, etc.)

They do tests on production vehicles too, e.g. the static fires that precede just about every launch, but those aren't directly comparable to the stuff they deliberately blow up to see how that happens.