I didn't get that either until I read this comment. I read "pushin" as one word, figured it was a made up proper name for a product.
Once upon a time, I, too, had a domain where the TLD was part of the actual name and required to read it correctly (think something like foobar-pl.us). In my experience this left most people confused and I abandoned that quite quickly.
Just two days ago, a preprint by Julia Stadlmann went up on arXiv [0] improving the prime gap from 246 to 240. Now OpenAI announces Astra has shown a gap of 186 [1]. That must really blow.
Based on her comments in the paper it sounds like she was aware that an AI result was coming and rushed to release her work beforehand. 240 was not a tight bound from her methods.
"No independent human semantic review. Whole-file sorry counts and a complete auxiliary-declaration audit are not established; separate declaration lint has not been run."
It cites to her at: [19] J. Stadlmann, On primes in arithmetic progressions and bounded gaps between many primes, Adv. Math. 468
(2025), Art. 110190. Numbered references use arXiv:2309.00425v3.
What's just as interesting is this morning Axiom Math announced 212 and OpenAI then appears to have rushed out their 186 announcement just 1-2 hours later followed by Astra. Did they accelerate the release of Astra itself? Not necessarily, but it definitely looks like they ended up pushing much harder and faster than planned on their 186 result. X activity suggests Anthropic had a similar result as well but wasn't as fast as OpenAI in packaging it up and sharing it in response to Axiom, so they mostly just bolted onto OpenAI's messaging.
The reason I think this is interesting is that Axiom is a tiny lab in comparison that wouldn't have had access to Astra at all. I'd be curious to learn how Axiom is able to effectively compete at this frontier with vastly fewer resources.
I can't think of a single mathematical proof being anywhere close to ten million characters. For all you know, 90% of the proof could be useless, 8% would be writing out Shakespeare, and 1% abusing another bug in Lean. Humanity gets zero value from that, aside from "some bot seems to think it's 186". Unusable by anyone.
Terence Tao says something surprisingly similar in a recent talk (https://news.ycombinator.com/item?id=49056620 ) Not that the proof is worthless but that the value comes after it's revised into a cleanly understandable form and then canonicalized so that other mathematicians can use it.
Tao is saying that there is very little insight from something like an LLM counterexample (e.g. Jacobian conjecture counterexample he investigated further on his blog) - you don't learn much about the subject and _why_ a conjecture was true or false from an LLM giving a counterexample. That's why he wrote the blog post - to analyse what the counterexample says about the subject.
Tao does not disbelieve the counterexample (it's seemingly easy enough for him to verify it is a counterexample).
Parent is saying something very different - they're saying they literally don't have any faith that this is a proof. Given its size, it could just be a bunch of completely useless statements that do pass the type checker.
You're putting a lot of words in my mouth. What I'm saying is that whether or not it's a proof, it's useless: it does not improve human knowledge, because the only thing able to consume 10MB of Lean to build upon it is another LLM that's going to build a 50MB piece of shit.
It's very much likely a proof. It's also completely useless.
If we accept that it is a proof then it does improve human knowledge, even if no one can understand how to get there.
If you were navigating a pitch dark cave, wouldn't you find it useful to be able to see the light of the cave opening even if it's not bright enough to illuminate your path to it?
I'd like to note that we should remember a formalized Lean proof does have value in that it enters the pantheon of true things other Lean proofs can rely on. Agreed that for the humans, descriptions and being able to 'grok' the proof / assess it for new tools and concepts is extremely helpful.
Iirc some mainstream physycists never acknowledged quantum theory because they couldn’t accept that universe was that unintuitive and hard to understand.
Ditto ones that opposed Einstein’s general relativity.
It's like hitting a local minima, it was given a technique, it brute forced it for a lot of money and slightly improved the result.
But nothing new was discovered, no new mathematical tool was built, only a huge file that no one will read or build on.
In 1799, Paolo Ruffini published a 500 pages long proof showing that there is no closed algebraic solution for the roots of a polynomial of degree five or higher. The proof is extremely verbose and brute-force, essentially enumerating and checking hundreds of cases by hand. It is by today’s standards insignificant.
About 25 years later, Evariste Galois proved the same result in about 95% less space by describing the first general theory of groups and fields. It is considered one of the greatest contributions to mathematics of that century, not because of the result, but because its approach opened up a whole new universe of questions, methods and insight. There would be no AES encryption without Galois.
It's probably not 10MB, but famously the groundwork to prove the statement 1+1=2 is nearly 400 pages in to principia mathematica. That's not even proving 1+1=2, it's just the set-theoretic proofs you need to EVENTUALLY get there.
Saying "proving 1+1=2" is pretty misleading though. The book deals with all the foundational things needed to set up a mathematical universe where 1+1=2 actually has meaning and is consistent. That setup took 400 pages.
You can have your opinions about modern math, its usefulness in the world as it is, whether or not knowing if hairy balls can divide by three is actually going to be beneficial for anything but just obscure knowledge's sake. You may even say it's useless.
Needless to say, a useless result that absolutely no mathematician will ever read, confirm, understand, agree with or even consider to solve their "useless" problems is an impressive waste of resources.
Worthless is a pretty good description IMO in the context of what Lean is trying to achieve: "enable correct, maintainable, and formally verified code". Tens of millions of lines of LLM vomit may be many things, but it often turns out to not be correct and certainly not maintainable. Formally verified remains as a thin fig leaf covering the uncomfortable truth that formal methods only provide assurances under assumptions (your toolchain, libraries, compiler, OS, and hardware are "correct" and don't expose some exploitable flaw).
It doesn't mean that it cannot improve over time, maybe the proof can be "minified" to a state where human reviewers are able to comprehend it; but as it stands there isn't really much insight or confidence to be gained from the artifact itself.
This does look legitimately exciting. A surprisingly large pain point when doing agentic work has been commenting on something in a larger plan document. I always find myself summarizing the surrounding text to contextualize a comment when all I really want to do is highlight and click "add comment".
Unrelatedly, I have been looking at Zed to centralize my agentic work at $job, where we use different API keys per project to better attribute spend and control model availability based on per-project data protection controls. All of the standard UIs I've tried for this don't really work, but the CLIs mostly do. Using ACP in Zed I was able to bridge that into the UI world and I'm quite happy with it.
I signed up for the beta and I look forward to trying it.
Precision feedback for CLI-based coding agents is terrible. We built and open sourced PlanBridge (https://plan.contextbridge.ai) to fix this. It is a CLI that lets your coding agent open a local browser with a rendered plan/spec (or just the last agent message) so you can select and comment directly on the text and iterate with precision.
Thanks for pointing that out. I tried the Codex App before but didn't see that.
I want to like the app, but I'm not sure if it actually fits well to my use case. With my current setup I need to fully quit and restart it if I want to work on a different project (to get it to use a different API key) and I cannot work in two threads belonging to different projects at the same time.
Also I generally prefer to handle sandbox the entire agent and disable its internal safeguards. Beside any doubts regarding the quality of the relevant sandbox implementations, I have just gotten my projects to work better this way.
Directly annotating parts of the convo is the feature that really unlocked Delta for me (have been testing the alpha). So much easier than trying to explain to the agent what I'm responding to in their giant text blob.
I loved garnix and I’m sad to see the service shut down. That said, open sourcing the platform is the best way to do it I can imagine. I wish the team success at Shopify.
Sonnet 5 is not currently available in the EU region on Bedrock, whereas previous models were and still are. I wonder if this is only due to early stages of the rollout or if this is due to recent US restrictions.
Unfortunately that means I won't be using it at work for now.
I personally find the "animals killed since you opened this page" number to be the most unsettling. YTD numbers are so large, I find them hard to process.
If you choose to eat meat, please be aware of the conditions most of these animals exist in and how they die. I'll spare you more numbers, because they don't do the cruel reality justice anyway. Instead, I'll leave you with some video material: https://animalequality.org/blog/factory-farming-facts/
The quantity of animals killed scales inversely with size. Most of the "animals killed since opening this page" are shrimp.
I am open to hearing evidence that shrimp have the capacity to care about the conditions in which they live and die but as of now I don't believe they do.
Gnome, for example. GDM now needs systemd's userdb.
It is indeed becoming harder and harder to avoid and I understand that this isn't great, but systemd tackles some genuinely hard problems that others don't. Which is to say I don't begrudge Gnome devs for this and personally prefer systemd over current alternatives.
I've looked at OpenRC, RUnit and S6. I haven't recently run any of them "in production", however.
Personally, I am a strong believer that declaring the desired state is a lot easier to get right than actually writing the code to get there. Beyond that, I'm not saying any of these are bad at being what they are, systemd just has more features, some of which I really like. Two examples I'm actively using currently are automount units and socket activation (S6 also has socket activation). I have some remote folders mounted via SSHFS automatically when I access them and this is incredibly useful for my workflow.
Could I find tools to slot into other init systems that do this for me? Probably. But systemd has this neatly packaged up, easy to configure and easy to introspect state.
It uses a folder with a subfolder for every service. Each subfolder contains a script called run. The system runs the run script. If it exits, it waits two seconds and runs it again. Repeatedly. It's very worse–is–better.
There are commands to control the services and check their status. For example, if a file called down exists next to the run script, it won't run it. This is how you disable a service.
It checks for service folders being created and deleted. New folders are started, and deleted ones are stopped cleanly. They can also be symlinks, so you don't need to worry about deleting a running service folder and you can remove a service from init without erasing the scripts you wrote.
The whole system is useful in many situations and not only as pid 1.
Maybe one day I'll invent a runit–based distribution.
Once upon a time, I, too, had a domain where the TLD was part of the actual name and required to read it correctly (think something like foobar-pl.us). In my experience this left most people confused and I abandoned that quite quickly.
reply