Co-founder, Apache group (pre-ASF). I wrote a lot of the code that went into Apache httpd 1.0, adding resource pools and the extension API, among several other things, as briefly described here: http://httpd.apache.org/ABOUT_APACHE.html
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)?
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.
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."
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.
Which helps with some kinds of threats, but not all. It keeps someone from pretending to be the maintainer -- but if an actual maintainer is compromised, coerced, or just bad from the start and biding their time, they can still do whatever they want with full access rights.
Another example: on Android, look up scores of an ongoing sports event on mobile Chrome, and mobile Firefox. Mobile chrome gets you a box saying what the score actually is; mobile firefox just shows you the links to sports-league and news sites that you see under the score in mobile Chrome.
Click the "show desktop view" page on mobile firefox, reload, and suddenly the score is there. They're not discriminating that aggressively against competing desktop browsers. Yet.