Hacker News: rst

New comment by rst in "Ten advances in mathematics and theoretical computer science"

rst — Sat, 01 Aug 2026 21:58:54 +0000

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

New comment by rst in "Why we built yet another Postgres connection pooler"

rst — Wed, 08 Jul 2026 02:21:55 +0000

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)?

New comment by rst in "Working With AI: A concrete example"

rst — Mon, 29 Jun 2026 22:21:36 +0000

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

New comment by rst in "You really shouldn't copy-paste errors into Claude Code"

rst — Mon, 29 Jun 2026 22:18:58 +0000

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.

New comment by rst in "Fable 5 pushed Gemma 4 to 255 tok/s on WebGPU"

rst — Thu, 18 Jun 2026 15:50:43 +0000

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.

New comment by rst in "Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc"

rst — Sat, 09 May 2026 23:51:04 +0000

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.

New comment by rst in "We reproduced Anthropic's Mythos findings with public models"

rst — Fri, 17 Apr 2026 15:17:50 +0000

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/

New comment by rst in "Astral to Join OpenAI"

rst — Thu, 19 Mar 2026 13:41:53 +0000

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.

New comment by rst in "Unix v4 (1973) – Live Terminal"

rst — Sun, 04 Jan 2026 00:31:58 +0000

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.

New comment by rst in "Unix v4 (1973) – Live Terminal"

rst — Sun, 04 Jan 2026 00:23:42 +0000

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

New comment by rst in "We Let AI Run Our Office Vending Machine. It Lost Hundreds of Dollars"

rst — Fri, 19 Dec 2025 03:11:14 +0000

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

New comment by rst in "The lost cause of the Lisp machines"

rst — Thu, 20 Nov 2025 17:01:50 +0000

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

New comment by rst in "SailfishOS: A Linux-based European alternative to dominant mobile OSes"

rst — Sat, 01 Nov 2025 23:49:41 +0000

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

New comment by rst in "Firefox 32-bit Linux Support to End in 2026"

rst — Mon, 08 Sep 2025 18:22:51 +0000

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.

New comment by rst in "Copilot broke audit logs, but Microsoft won't tell customers"

rst — Wed, 20 Aug 2025 01:22:15 +0000

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

New comment by rst in "Graphene OS: a security-enhanced Android build"

rst — Fri, 25 Jul 2025 12:24:48 +0000

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

New comment by rst in "CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview)"

rst — Wed, 28 May 2025 12:03:33 +0000

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

New comment by rst in "Claude 4 System Card"

rst — Sun, 25 May 2025 16:06:33 +0000

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.

New comment by rst in "32 bits that changed microprocessor design"

rst — Sat, 24 May 2025 17:23:10 +0000

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.

New comment by rst in "32 bits that changed microprocessor design"

rst — Fri, 23 May 2025 02:28:48 +0000

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