🏡
  • ↔
  • →
  1. October 11, 2026
    1. 🔗 r/LocalLLaMA Qualcomm CEO reveals AI companies want phones running 100-billion-parameter models continuously by 2028. rss

      Qualcomm CEO reveals AI companies want phones running 100-billion-parameter models continuously by 2028. | https://x.com/firesidealpha/status/2108930562794864912 submitted by /u/Recoil42
      [link] [comments]
      ---|---

    2. 🔗 backnotprop/plannotator v0.28.12 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.11 | plannotator inbox --help prints a full guide for agents, and the plannotator.ai/inbox install prompt
      v0.28.10 | The Inbox over your tailnet with plannotator inbox --tailscale, images in agent messages load, click anywhere on an attachment tile
      v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
      v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
      v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
      v0.28.6 | Ask AI names the lines you selected, reorder quick labels and edit their emoji, Pi fixed-port crash fixed, OpenCode 2 subagent notice fixed
      v0.28.5 | Several files in one review, the plannotator tool on Pi and OpenCode 2, decisions name the exact file, Ask this session reconnects after sleep
      v0.28.4 | Comments come back after the agent edits a file, the agent can list and close its reviews, PR-description feedback no longer dropped, Pi thinking levels
      v0.28.3 | Typing into your agent while it answers an Ask no longer streams into Plannotator
      v0.28.2 | Question cards show wrapped choices and tables, pinned images named by their file, Done with nothing to send starts no agent turn
      v0.28.1 | Ask AI from diagram comments, pinned images named for the agent, OpenCode 1 URL toasts and one reply per feedback, folder feedback sent once
      v0.28.0 | Ask this session in Claude Code, Pi and OpenCode 2, Claude Code mod on by default, Pi plan review no longer blocks, first-run demo

      What's New in v0.28.12 An Inbox release, and update notices for everyone. Agents can now attach any file, and questions carry the context to answer them. Plannotator now tells you when a new version is out and can update itself in one click. Update notices and plannotator update Plannotator used to check GitHub from your browser on every page load, and its update hint showed the wrong command for Claude Code and Pi. Now the machine checks at most once a day, never while you work, and every window reads that one answer. In the Inbox , an Update button appears as soon as a new version is out. Its dialog puts Update now first, which runs the normal install script for you, and offers "Install new versions automatically". After an update, a What's new page lists what changed. In plan, annotate and code review , a small notice appears at most once per version and once every three days, with the right command for your agent. In the terminal , plannotator update installs the latest release, and plannotator update --check only reports. Turn it off in Settings, or set PLANNOTATOR_UPDATE_CHECK=0 or { "updateCheck": false } in ~/.plannotator/config.json. Off means no automatic request to GitHub at all. "Update now" only works from the computer itself. Sessions you share over your network or tailnet show the command to run instead. #1830, #1833, #1835 Attach any file to an Inbox message Agents can now attach any file you can read, from anywhere on the computer, not only Markdown, text and HTML from inside the project. Images show inline in the message, the way an email shows them, and again as tiles with thumbnails. Click one to open it beside the thread, comment on it, and mark it up. Code and scripts (.ts, .sh, .py, .swift and the rest) open highlighted, with comments on lines and ranges. PDFs and every other file are downloads. Comments on images and code reach the agent with your reply, like comments on documents. .env files are still refused, along with .env.* (except .env.example), *.env and .envrc. Agents can also pass project_path to the Inbox tool, so a session working in a subfolder files its message under the right project. #1826, #1834 Questions with context, and links to attached files The question guide every agent reads (the plannotator skill, plannotator inbox --help and the Inbox tool) now has literal rules. Agents give one to three plain sentences of context: what the choice affects, what they already know, and why they recommend what they do. They add a screenshot when the question is about something visual. You switch in cold, and a question should be answerable without opening anything else. When an agent links a file it attached (), the link opens that file beside the thread. A link to a file that isn't attached shows as "Not attached" and loads nothing. #1829 Additional Changes

      • Replies reach scripted agents. plannotator inbox mcp run from inside a Claude Code or Pi session now sends as that session, so your reply wakes the agent and its messages stay in one thread (#1831)
      • Oh My Pi. Our Pi extension works in Oh My Pi as an OMP plugin (omp plugin install @plannotator/pi-extension). When Plannotator is started from OMP's terminal instead, Ask AI now says how to connect it to the session. The installer mentions it when it finds OMP (#1832, for #1814)
      • Question cards. The "Records a decision" tag reads clearly as off when off, and the tags in a card's top row line up (#1816)
      • The install script updates the Claude Code plugin you already have, so binary and plugin stay in step. Skip it with --skip-claude-plugin (#1824)

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin → Installed → plannotator → Update now.

      Pi:

      pi update --extensions

      OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

      What's Changed

      • Install scripts: update an installed Claude Code plugin by @backnotprop in #1824
      • Question card: the off decision tag reads as off; the eyebrow pills align by @backnotprop in #1816
      • Inbox: code files as attachments, and project_path on the plannotator_inbox tool by @backnotprop in #1826
      • Questions: a little more context, and links to attached files open beside the thread by @backnotprop in #1829
      • Inbox MCP: a command run inside an agent session sends as that session by @backnotprop in #1831
      • Oh My Pi: point CLI sessions at the extension for Ask this session by @backnotprop in #1832
      • Inbox: attach any file from anywhere; images, PDFs, files, comments on images and code by @backnotprop in #1834
      • Updates: daily check, plannotator update, the Inbox Update button, review-window notices by @backnotprop in #1830, #1833, #1835
      • Repo housekeeping: the iPhone app moved to its own home, docs cleanup (#1825, #1828, #1827)

      Community

      • @tedtramonte reported that Ask this session was missing in Oh My Pi in #1814, which led to the OMP fix and docs.
      • Inbox users who wrote in about agents that never used the Inbox, about missing context in questions, and about files that couldn't be attached: most of this release answers those notes.

      Full Changelog : v0.28.11...v0.28.12

    3. 🔗 r/LocalLLaMA Building a 4x R9700 setup for a 10 person startup rss

      Building a 4x R9700 setup for a 10 person startup | Just wanted to share a build I am doing for a client. $18k. Specs: Threadripper 9970x 128gb DDR5 ECC 5600 4x AMD Radeon R9700 AI Pro 32gb(128gb total VRAM) 1600W PSU(GPUs are undervolted and under 210w each) Engine : using a fork of Radiance to serve Qwen 3.8 Next flash/27b and DSV4 Flash Results: 16 concurrent sessions Qwen 3.8 27b MXFP4 6.3-6.8k aggregate prefill tok/s
      900 t/s - 80t/s aggregate decode(range: 4k - 128k context each) Qwen 3.8 Next flash int4fp8 48K/user | 6,880 tok/s | 538.5 tok/s aggregate prefill/decode 128k/user | 3,050 tok/s | 365 tok/s aggreate prefill/decode BF16 kv for all. submitted by /u/sayamss
      [link] [comments]
      ---|---

  2. October 10, 2026
    1. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release, -1 release rss 
      sync repo: +1 release, -1 release

## New releases
- [IDASQL](https://github.com/allthingsida/idasql): 0.0.19

## Changes
- [IDASQL](https://github.com/allthingsida/idasql):
  - removed version(s): 0.0.10
    2. 🔗 backnotprop/plannotator v0.28.11 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.10 | The Inbox over your tailnet with plannotator inbox --tailscale, images in agent messages load, click anywhere on an attachment tile
      v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
      v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
      v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
      v0.28.6 | Ask AI names the lines you selected, reorder quick labels and edit their emoji, Pi fixed-port crash fixed, OpenCode 2 subagent notice fixed
      v0.28.5 | Several files in one review, the plannotator tool on Pi and OpenCode 2, decisions name the exact file, Ask this session reconnects after sleep
      v0.28.4 | Comments come back after the agent edits a file, the agent can list and close its reviews, PR-description feedback no longer dropped, Pi thinking levels
      v0.28.3 | Typing into your agent while it answers an Ask no longer streams into Plannotator
      v0.28.2 | Question cards show wrapped choices and tables, pinned images named by their file, Done with nothing to send starts no agent turn
      v0.28.1 | Ask AI from diagram comments, pinned images named for the agent, OpenCode 1 URL toasts and one reply per feedback, folder feedback sent once
      v0.28.0 | Ask this session in Claude Code, Pi and OpenCode 2, Claude Code mod on by default, Pi plan review no longer blocks, first-run demo
      v0.27.25 | Code review works with color.diff = always, Bitbucket review fixes, wide tables no longer collapse in Firefox, install script fix

      What's New in v0.28.11

      A one-change Inbox release: plannotator inbox --help now teaches an agent how to use the Inbox.

      plannotator inbox --help is a guide for agents

      Until now plannotator inbox --help printed a few lines of usage. An agent with no Plannotator skill installed had no way to learn what the Inbox is for, how to send to it, or how to ask a question the person can answer on a card. Now the same command prints a complete markdown guide written for the agent:

      • what the Inbox is, and when to send something there instead of asking in the chat;
      • how to reach it: the plannotator_inbox tool where the agent has one, otherwise the stdio MCP server plannotator inbox mcp, and how an agent connects itself in Claude Code, Pi and OpenCode;
      • each of the eight tools and the arguments that matter, how threads and replies work, and where a reply arrives;
      • the question block syntax, the same text the plannotator skill carries, plus the Inbox-only Stopped:, Holds up: and Decision: when answered lines;
      • the setup line for each other agent (Codex, Cursor, VS Code, Gemini CLI, Zed and the rest), filled in with the absolute path of the binary on your machine;
      • the commands and flags, where the data lives, and that an agent must never uninstall or delete it for you.

      The guide is built from the code: the tool list, the question syntax and the setup lines come from the same sources the Inbox itself uses, and tests fail if a tool, argument, flag or agent is added without it. plannotator --help, the plannotator skill and the docs now point agents at it.

      The new "Copy install prompt" button on plannotator.ai/inbox relies on it: the prompt has your agent install Plannotator, start the Inbox, read plannotator inbox --help, connect itself and send you a first message.

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin → Installed → plannotator → Update now.

      Pi:

      pi update --extensions

      OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

      What's Changed

      Community

      • The Inbox users who wrote in after launch that their agents never wrote to it and that it was not clear how to get started. This guide and the install prompt are the answer to that.

      Full Changelog : v0.28.10...v0.28.11

    3. 🔗 r/LocalLLaMA Open-source Mac app that runs EmbeddingGemma 2 locally to search your files by what’s in them rss

      Open-source Mac app that runs EmbeddingGemma 2 locally to search your files by what’s in them | DigUp is a free Mac app that runs Google DeepMind’s new EmbeddingGemma 2 locally over your own files. The model puts text, images, audio and video in one space, so you describe what you remember and land on it:

      • “zebra in a video” opens the clip at the moment it shows up
      • “where they talk about sleep” jumps to that minute of a podcast
      • “the clause about pets in the lease” shows the PDF page, your words marked
      • “a dog on the beach” finds the photo, and the same search in Bengali or Arabic finds it too
      • with code search on, code: retry with backoff opens the function in your editor

      It’s ggml-org’s Q8_0 GGUF (865 MB, downloaded once) on llama.cpp with Metal, inside a native Swift app; no Python. Searching loads only the text encoder (~250 MB) and shows results about a tenth of a second after you stop typing. Indexing peaks under 2 GB, and the helper exits when it’s done. Audio and video of any length go in as 30 s windows and a frame per shot. Everything runs locally; it goes online only for the model download and an update check you can turn off. Free, MIT. Apple Silicon, macOS 14+. Repo & Download (signed and notarized): https://github.com/ARahim3/DigUp I'd really appreciate any feedback on this. submitted by /u/A-Rahim
      [link] [comments]
      ---|---

    4. 🔗 smol-machines/smolvm smolvm v1.26.1 release

      What's Changed

      • Reap a child after its exit event so a stopped VM is not left a zombie on macOS by @BinSquare in #1675
      • Bump version to 1.26.1. by @BinSquare in #1676

      Full Changelog : v1.26.0...v1.26.1

    5. 🔗 smol-machines/smolvm smolvm v1.26.0 release

      What's Changed

      • Seed host-fetched and local image archives so no-network machines skip re-flattening by @BinSquare in #1635
      • Keep compression admission test stable under Windows CI load by @BinSquare in #1642
      • Keep a TSI guest off a host resolver the egress floor blocks by @BinSquare in #1641
      • Write a large upload into the guest as it arrives instead of holding all of it first by @BinSquare in #1640
      • agent: stop spinning on a child that closed its stdout by @BABTUNA in #1644
      • pack: flatten qcow2 disks on the host, writing only their data by @BABTUNA in #1646
      • Encode streaming exec errors as valid JSON by @BinSquare in #1649
      • Return 404 when a guest file does not exist by @BinSquare in #1648
      • Close guest stdin for streaming exec without input by @BinSquare in #1650
      • Reject incomplete streamed uploads and enforce declared byte counts by @BinSquare in #1647
      • Kill whatever is left in a machine's scope when its VM is torn down, and stop export helpers whose creator is gone by @BinSquare in #1638
      • Remove partial host files after interrupted guest streams by @BinSquare in #1639
      • Explain guest agent version skew during pack export by @BinSquare in #1636
      • Count SSBS that KVM gives guests on hosts that hide it from themselves by @BinSquare in #1657
      • Bump libkrun so a branchable child shares its source's memory by @BinSquare in #1660
      • Embedders register bundle paths in-process, not through the environment by @BinSquare in #1658
      • Let credential bindings set a header, match wildcard hosts, and be created by an embedder by @BinSquare in #1436
      • Avoid dropping virtio-net connections during parallel workloads by @BinSquare in #1661
      • Seed machine run from a local image archive by @BABTUNA in #1656
      • api: skip the create time seed for machines that fetch on the host by @BABTUNA in #1654
      • process: wait on the exit event instead of a polling tick by @BABTUNA in #1652
      • Reject invalid published ports in embedded machine creation by @BinSquare in #1662
      • Reclaim Kubernetes pod state after container and sandbox deletion by @BinSquare in #1666
      • Bump version to 1.26.0. by @BinSquare in #1673

      Full Changelog : v1.25.4...v1.26.0

    6. 🔗 r/LocalLLaMA NVIDIA reportedly discontinuing RTX 5090, GB202 GPUs to be reserved for RTX PRO series rss

      NVIDIA reportedly discontinuing RTX 5090, GB202 GPUs to be reserved for RTX PRO series | No..... submitted by /u/chemist_slime
      [link] [comments]
      ---|---

    7. 🔗 r/LocalLLaMA big or small? rss

      big or small? | what size do you want? tell them on X: https://x.com/QwenDevs/status/2108764909798641737 submitted by /u/jacek2023
      [link] [comments]
      ---|---

    8. 🔗 backnotprop/plannotator v0.28.10 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.9 | Large Inbox messages through plannotator inbox mcp fixed, an Inbox sidebar you can close and resize, Edit Mode in reviews of several files, the new Pi logo
      v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
      v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
      v0.28.6 | Ask AI names the lines you selected, reorder quick labels and edit their emoji, Pi fixed-port crash fixed, OpenCode 2 subagent notice fixed
      v0.28.5 | Several files in one review, the plannotator tool on Pi and OpenCode 2, decisions name the exact file, Ask this session reconnects after sleep
      v0.28.4 | Comments come back after the agent edits a file, the agent can list and close its reviews, PR-description feedback no longer dropped, Pi thinking levels
      v0.28.3 | Typing into your agent while it answers an Ask no longer streams into Plannotator
      v0.28.2 | Question cards show wrapped choices and tables, pinned images named by their file, Done with nothing to send starts no agent turn
      v0.28.1 | Ask AI from diagram comments, pinned images named for the agent, OpenCode 1 URL toasts and one reply per feedback, folder feedback sent once
      v0.28.0 | Ask this session in Claude Code, Pi and OpenCode 2, Claude Code mod on by default, Pi plan review no longer blocks, first-run demo
      v0.27.25 | Code review works with color.diff = always, Bitbucket review fixes, wide tables no longer collapse in Firefox, install script fix
      v0.27.24 | Image previews stay in the all-files view, PR comment previews open on the commented line

      What's New in v0.28.10 A small Inbox release. You can now open the Inbox from your other devices over Tailscale, images in agent messages load, and a click anywhere on an attachment tile opens the file. Open the Inbox over your tailnet The Inbox only listens on this computer, so until now the only way to reach it from a phone or another machine was to set up tailscale serve by hand, which let every device on the tailnet in, including the agent connection. Now one flag does it: plannotator inbox --tailscale The command prints an address such as https://studio.tail1234.ts.net:52817/. Open it on any device signed in to your tailnet. Tailnet only, never public. The Inbox stays bound to this computer. tailscale serve publishes it over HTTPS inside your tailnet. The Inbox never uses tailscale funnel. Only your own login gets in. The Inbox lets in the Tailscale login that owns this computer and refuses everyone else, including tagged devices. To let in another login, add it to ~/.plannotator/config.json: { "inboxTailscaleAllow": ["you@example.com"] }. An allowed login can reply and send New messages, and those become turns in your live agent sessions on this computer, where agents run commands. Allow only people you would let run your agents. Agent connections stay local. MCP and the reply wake answer only on this computer, never over the tailnet. On for one run or for good. --tailscale publishes until the Inbox stops, and works with --background and --no-open. If the Inbox is already running, the command asks it to publish. To publish at every start, including when an agent starts the Inbox, turn on Over your tailnet in the Inbox's Settings (or set { "inboxTailscale": true } in config.json). PLANNOTATOR_INBOX_TAILSCALE=0 keeps it off whatever the flag or the switch says. Tailscale missing or signed out? The Inbox still runs on this computer, and Settings and the terminal say why it could not publish. The address uses the Inbox's own port and is removed when the Inbox stops or restarts. If the Inbox is killed (kill -9, a reboot), the address stays in Tailscale until the next start removes it; run tailscale serve --https=<port> off to remove it sooner. Full details: plannotator.ai/docs/reference/inbox. #1818, requested by an Inbox user who wanted to reach it over their tailnet Images in agent messages load An agent's message with ! showed a broken image, because the Inbox had no route for it. Images in messages now load when the file is inside the message's project: a path relative to the folder the agent sent from, or an absolute path inside the project. This covers markdown images, &lt;img&gt; tags and images in question context. PNG, JPEG, GIF, WebP, SVG, AVIF, BMP and ICO files up to 10 MB are served. The Inbox serves only images the message itself references, so the route cannot be used to read other files. Images from the web (https://…) still do not load. #1819, closing #1813 reported by @hexsprite Additional Changes

      • Click anywhere on an attachment tile. The tiles under an agent message opened only from the small "Open" text. The whole tile now opens the file, and keyboard focus outlines the whole tile (#1817)

      Behavior changes

      • /mcp needs a loopback address with the Inbox's own port. An HTTP MCP client must reach http://127.0.0.1:<port>/mcp directly. An ssh -L forward to a different local port is now refused. plannotator inbox mcp over stdio is unaffected.
      • Use--background to keep a published Inbox running. nohup plannotator inbox --tailscale & stops when the terminal closes while the Inbox is published. Run plannotator inbox --tailscale --background instead.

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin → Installed → plannotator → Update now.

      Pi:

      pi update --extensions

      OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

      What's Changed

      Community

      • @hexsprite reported that images in Inbox messages never loaded in #1813, with the exact repro and the cause traced to the missing route.

      Full Changelog : v0.28.9...v0.28.10

    9. 🔗 hacker news ida pro references New comment by methou in "REA Reverse – Engineer Anything" rss

      I'm using IDA Pro's MCP (Well worth of money in the past), it may hit the infamous artificial cyber wall at any time.

      Try GLM-5.3, it worked pretty for me. It also worked well with Radare2 or binary ninja if you don't have the muscle memory for idapro.

    10. 🔗 Ampcode News Use Your Claude Plan in Amp rss

      You can now use your Claude Pro/Max subscription in Amp. It's free and available for everyone now.

      When creating a new thread, just pick Mode > Claude Code. It'll ask to link your Claude sub if you haven't already done that.

      The web mode dial with the Claude Code position selected, using a Claude Pro/Max plan. The model is Opus 5.5 and the effort is High.

      Under the hood, this mode uses the Claude Agent SDK instead of Amp's own agent. But we made it all work: orbs and runners, thread sharing, portals, multiplayer, thread-to-thread messaging and orchestration, etc.

      See the Claude sub docs for more information.

    11. 🔗 Baby Steps Why 'externalized' proofs of cyclic trait impls does not work rss

      For this post, I wanted to talk about two different approaches to handling supertraits. I'm calling them modular proofs vs external proofs. The key idea of this post is that, if we want to have cyclic trait impls, we really need to use a modular proof strategy, where the impl establishes all supertraits hold. Previously we had considered an external strategy, where the piece of code using the impl has the obligation to prove the supertraits hold. Modular proofs always seemed better but I did not think they were workable in the past. But I have become convinced that external proofs are incompatible with Rust as designed, and hence modular proofs are really the only option1. This post dives into that reasoning, and also gives a bit of explanation of what I mean by proofs in the first place.

      Traits and supertraits

      So what do I mean by modular vs external proofs? Well, it all comes down to who is responsible for proving that supertrait obligations hold. Consider a trait like Magic:

      trait Magic: Copy { }

      The supertrait declaration means that, whenever X: Magic for some type X, it should be true that X: Copy. We make use of this in generic functions:

      fn is_copy<T: Copy>() {
}

fn is_magic<T: Magic>() {
    // Legal, because `T: Magic` implies `T: Copy`
    is_copy::<T>();
}

      The trick is that the compiler has to make sure that this implication holds - i.e., for every type X that implements Magic, X also implements Copy. So how does it do it?

      Modular proofs: the impl must show supertraits hold

      The obvious answer is to make proving supertraits part of deciding whether an impl is valid. For any impl of Magic, we can require that the Copy supertrait holds. So an impl like this would be illegal:

      // In a modular system, this impl is *illegal*
impl Magic for String { }

      This impl is illegal because it would require that String: Copy, and that does not hold. Seems good.

      Modular proofs are a bit tricky

      I am calling these proofs modular because the idea is that we can prove an entire program is valid by proving each part of it separately. In "programming language" theory, this is typically called a "modular" check, as it works by breaking up the entire program into modules that can be independently checked.

      The idea with a modular proof is that we can trust impls to show that the supertrait relationships hold , we don't have to go and re-prove them over and over. If the impl is wrong, the impl will be invalid, but our code is fine. So if we have impl Magic for String, that implies the rest of the program can prove that String: Magic:

      fn string_is_magic() {
    // Legal, because there is an impl for `String: Magic`:
    is_magic::<String>();
}

      In fact, since we know that Magic implies Copy, the rest of the program can even rely on impl Magic for String to conclude that String: Copy:

      fn string_is_copy() {
    // Legal, because there is an impl for `String: Magic`,
    // and `Magic` implies `Copy`:
    is_copy::<String>();
}

      So long as impl Magic for String is invalid, none of this poses a problem to soundness, since the program overall doesn't type-check.

      Comparison with functions

      An easy way to understand the idea of modular checks is to think of functions. Imagine you have a function like this one:

      fn compute_sum(a: i32, b: i32) -> i32 {
    format!("{a} + {b}") // <-- Error
}

      Clearly, this function is not legal. It takes two integers and promises to return a third integer, but in fact it returns a String. So the function is illegal. But if you have a call to that function from elsewhere, we consider that other call to be legal:

      fn use_sum() {
    let c: i32 = compute_sum(2, 20); // OK
}

      Here, use_sum is relying on compute_sum to obey its contract. It's not the job of use_sum to check that, it can just assume it is true.

      The catch: how do we decide the impl is invalid

      There is a bit of a catch though. How do we decide if the impl is invalid? The basic idea was that impl Magic for String would have to prove that String: Copy. But we just saw that it could, in fact, do that by using itself. In other words, if we aren't careful, we can provide a proof that String: Copy like…

      • String: Copy because Magic implies Copy and
        • String: Magic because impl Magic for String exists

      and then we would (incorrectly) conclude that the impl is valid. So clearly we need to do something to rule that out. We need a rule that says, when we are proving that an impl is valid, that proof cannot recursively rely on the impl itself.[^termination] I'll come back in a future post to ways we might do that, but for now, I want to explore another alternative.

      External proofs: the user of the impl must show supertraits hold

      When we first looked at this problem, way back in 2018 or so, we thought of another approach. What if we said that an impl is not responsible for proving supertraits. Instead, the idea would be that impl Magic for String is not enough to say that String: Magic. It only says that Shallow(String: Magic) - i.e., String implements Magic in a shallow way, but not in a deep way that includes the full supertraits. To prove thatString: Magic, we have to show that Shallow(String: Magic) and Shallow(String: Copy):2

      Shallow(String: Magic)
Shallow(String: Copy)
---------------------------- Magic fully implemented
String: Magic

      This has the somewhat counterintuitive implication that impl Magic for String is actually legal in an "external proof" approach:

      // In an external system, this impl is LEGAL
// (but unusable)
impl Magic for String { }

      The saving grace is that, while this impl is legal, you can't actually use it. This function for example does not compile:

      fn string_is_magic() {
    // NOT legal in an external system:
    // * We can prove that `Shallow(String: Magic)`
    // * We CANNOT prove that `Shallow(String: Copy)`.
    is_magic::<String>();
}

      Here, String: Magic doesn't hold even though there is an impl of Magic for String, because the caller also has to check that String: Copy is implemented, and it is not. Huh, interesting.

      Comparison to functions: external is awkward

      the "external proof" approach for impls is clearly a bit awkward. If we make the comparison to functions, it's as if the caller has to double check that the callee's body matches its return type, it can't actually trust the declared signature. But, awkward or not, it does resolve our problem: given impl Magic for String, we cannot prove String: Copy, and hence we cannot prove that String: Magic. We can only prove that Shallow(Magic: String), which doesn't imply that the supertraits hold.

      But external doesn't work with unsafe traits

      Based on the above, for a long time, I was working with the assumption that, weird as they are, we would go with the "external proof" approach. However, as Ralf Jung and lcnr pointed out to me recently, this is very challenging to reconcile with unsafe traits. Consider an unsafe trait like Nullable:

      // A type that can be safely transmuted from `0_usize`.
unsafe trait NullWord { }

      The way that Rust works, when we write an unsafe impl, it is the job of that impl to prove that the unsafe conditions hold. Other parts of the program get to trust the impl. So if I write a function like this one, it should be considered safe:3

      fn foo<T: NullWord>() -> T {
   std::mem::transmute(0_usize)
}

      Now imagine that I wrote an invalid impl like this one:

      // INVALID: We are asserting that `Box` can be null,
// which is not true!
unsafe impl<T> Nullable for Box<T> { }

      Given this program I could clearly call foo::<Box<u32>>(), but that would "go wrong" (cause "undefined behavior"). I think we would all agree that the fault lies in the impl. And yet, that is inconsistent: we say that the impl alone cannot be trusted to figure out if the supertraits are implemented, but it can be trusted to figure out if the unsafe impl is valid?

      Conclusion

      I definitely believe that we want to treat the "extra conditions indicated by unsafe" as a more general version of the other obligations that an impl has to establish to show that the trait holds- and therefore that we must have modular proofs. That's kind of a relief, because something always felt wrong about external proofs, but it was hard to put my finger on a concrete problem. In the next post in this series (whenever that may be…), I expect to cover the approach to coinductive modular proofs that I landed on. Then I expect to talk about an alternative that was proposed to me that I find quite appealing.

      1. I think this was obvious to Ralf Jung from the start. But it took me a bit. ↩︎

      2. This notation is called an inference rule. The conditions above the line are the premises and the bottom line is the conclusion. It says that, if you know the premises are true, you can infer that the conclusion holds. ↩︎

      3. In point of fact, I believe this will not compile because of special rules about unsafe, but that's not relevant to the point I'm trying to make. ↩︎

  3. October 09, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-10-09 rss

      IDA Plugin Updates on 2026-10-09

      Activity:

    2. 🔗 smol-machines/smolvm smolvm v1.25.4 release

      What's Changed

      • Remove pack staging directories left behind by a killed pack by @BinSquare in #1631
      • Refuse a rootfs extraction that lost sbin/init instead of booting it by @NickyHeC in #1228
      • Resolve a guest's DNS from the host so a blocked public resolver still works by @NickyHeC in #1226
      • agent: pull cold images through one crane process by @BABTUNA in #1523
      • CUDA fork: fix forking a CUDA golden failing with "rebase guest RAM: Device or resource busy" by @BinSquare in #1373
      • Add host-mediated egress policy and decision protocol by @BinSquare in #1434
      • Keep cache disk layers a branch still reads when collecting unused fork layers by @BinSquare in #1633
      • Bump version to 1.25.4. by @BinSquare in #1634
      • Keep machine execs alive when the image's workload exits by @BinSquare in #1632

      Full Changelog : v1.25.3...v1.25.4

    3. 🔗 backnotprop/plannotator v0.28.9 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.8 | The Plannotator Inbox (preview): messages, questions, files and guided reviews from your agents in one local window
      v0.28.7 | Ask this session keeps your drafts as drafts, image comments survive a reload, hostname check on every server
      v0.28.6 | Ask AI names the lines you selected, reorder quick labels and edit their emoji, Pi fixed-port crash fixed, OpenCode 2 subagent notice fixed
      v0.28.5 | Several files in one review, the plannotator tool on Pi and OpenCode 2, decisions name the exact file, Ask this session reconnects after sleep
      v0.28.4 | Comments come back after the agent edits a file, the agent can list and close its reviews, PR-description feedback no longer dropped, Pi thinking levels
      v0.28.3 | Typing into your agent while it answers an Ask no longer streams into Plannotator
      v0.28.2 | Question cards show wrapped choices and tables, pinned images named by their file, Done with nothing to send starts no agent turn
      v0.28.1 | Ask AI from diagram comments, pinned images named for the agent, OpenCode 1 URL toasts and one reply per feedback, folder feedback sent once
      v0.28.0 | Ask this session in Claude Code, Pi and OpenCode 2, Claude Code mod on by default, Pi plan review no longer blocks, first-run demo
      v0.27.25 | Code review works with color.diff = always, Bitbucket review fixes, wide tables no longer collapse in Firefox, install script fix
      v0.27.24 | Image previews stay in the all-files view, PR comment previews open on the commented line
      v0.27.23 | Bitbucket Cloud PR review, Question UI for answering agents in place, opt-in auto-update, viewed files remembered, review another repo or worktree

      What's New in v0.28.9

      A patch release that follows up on the Inbox, which launched in v0.28.8. It fixes large messages sent through plannotator inbox mcp, gives the Inbox a sidebar you can close and resize, and smooths several rough edges found since the launch. It also turns on Edit Mode in reviews of several files and includes a first contribution from @h-jennings.

      Large messages through plannotator inbox mcp

      An agent connected through the stdio command (plannotator inbox mcp, the setup the Inbox shows for Codex, Gemini CLI and other MCP clients) could not send a message larger than 4 MiB. The Inbox refused it, but the refusal carried no request id, so the agent's MCP client never matched it to its request and waited until its own 60-second timeout. Messages now go through up to 128 MiB, and anything larger is refused at once with an error that names the limit. Claude Code, Pi and OpenCode report the same limit in the same words.

      A sidebar you can close and resize

      The Inbox sidebar now closes and opens from a toggle at the start of each page header, or with ⌘B (Ctrl+B), and the Inbox remembers your choice. ⌘B does nothing while you type in the reply box, so it never takes your focus away. While the sidebar is closed, resting the pointer on the left edge shows it for a moment. Drag its edge to change the width (the Inbox remembers that too), drag it narrow to close it, or click the edge to collapse it. In a narrow window it opens as a sheet over the list. Opening a file beside a thread closes the sidebar to make room and leaves your saved choice alone.

      Smaller Inbox fixes

      • Newest first in every section. Each section of the list (Stopped on you, Holding up work, Waiting on you, Sent, New since you looked, Quiet) is now ordered by the thread's latest message, so the time column reads down in order. Before, some sections put the oldest waiting question first (#1800)
      • Rows show delivery without a reload. After your reply reached the agent, the thread said "Delivered" while the list row kept saying "Saved for " until you reloaded. The row now updates in place, and rows still change position only when you act (#1772)
      • Agents that get your reply automatically end their turn. send_message and submit_guide told every agent to call wait_for_reply, which could hold a Claude Code, Pi or OpenCode 2 session for up to 50 seconds per call even though your reply arrives there by itself. Those agents are now told to end their turn. OpenCode 1 and other MCP clients keep the wait_for_reply advice (#1771)
      • A stale tab says Inbox. An Inbox tab left open after the Inbox restarted used to say "This review was replaced". It now says the Inbox page is out of date and nothing was saved (#1773)
      • Attachments look like Plannotator. Markdown, text and diagram attachments follow the Grid or Clean look you chose in Plannotator's Settings (#1796)

      Edit Mode in reviews of several files

      plannotator annotate a.md b.md c.md opens one review of all the listed files, but that review had no Edit Mode, so an agent asked to set up documents for direct editing had to open a folder instead. Each file in such a review now has Edit Mode exactly when it would have it opened by itself: markdown, .mdx and .txt files can be edited and saved to disk, while raw HTML, diagram sources and data files stay read-only. Files linked from the review, and anything outside it, cannot be written. This works the same in the CLI and in Pi.

      Additional Changes

      • Drag a toast away. Pressing on a toast and dragging it used to select its text and leave it on screen, most often with the update notices. A drag now dismisses it, in plan review, annotate and code review (#1792 by @h-jennings)
      • The new Pi logo. Plannotator now draws Pi's new three-colour logo from pi.dev wherever it shows the Pi mark: the Ask AI provider bar, AI settings, the Agents tab, and the Inbox list, threads and first-run cards (#1808)
      • The Inbox on plannotator.ai. plannotator.ai/inbox now has a short film of the Inbox, alongside the launch post The age of the Inbox (#1770, #1811)

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin → Installed → plannotator → Update now.

      Pi:

      pi update --extensions

      OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

      What's Changed

      New Contributors

      Community

      • @h-jennings fixed toasts that selected their text instead of dismissing when dragged (#1792), with before and after recordings in the PR. First contribution to the project.
      • @bendrucker found that a review of several files had no Edit Mode and opened #1774 to point agents at the folder form instead. That report is why #1802 turned Edit Mode on for those reviews.

      Full Changelog : v0.28.8...v0.28.9

    4. 🔗 smol-machines/smolvm smolvm v1.25.3 release

      What's Changed

      • Return 400 when an image archive is not a container image by @BinSquare in #1625
      • fix(agent): propagate file-level fsnotify events from macOS directory changes by @Vishv07 in #1626
      • Start every command in a machine with the machine's environment, secrets and workdir by @BinSquare in #1628
      • Let a running machine's egress allow list be changed without a restart by @BinSquare in #1627
      • Start every command in a machine with the machine's environment, secrets and workdir by @BinSquare in #1629
      • Bump version to 1.25.3 by @BinSquare in #1630

      Full Changelog : v1.25.2...v1.25.3

    5. 🔗 r/LocalLLaMA OpenAI's math findings built on stolen user data rss

      OpenAI's math findings built on stolen user data | submitted by /u/CuTe_M0nitor
      [link] [comments]
      ---|---

    6. 🔗 r/LocalLLaMA Qwen/Qwen-Image-2.1-Turbo · Hugging Face rss

      Qwen/Qwen-Image-2.1-Turbo · Hugging Face | submitted by /u/chocofoxy
      [link] [comments]
      ---|---

    7. 🔗 Simon Willison A new feature for my blog, built using my voice rss

      I shipped a new feature for my blog today: the Newsletters page, which offers an index of all of the newsletters I've sent out, both my free weekly Substack and my monthly sponsors-only updates. I built the feature almost entirely using my voice, chatting away to my laptop while I cooked dinner.

      Codex voice mode

      I used the ChatGPT desktop app for this, in the Codex tab, using the voice conversation mode, running against a local development environment. Here's what that looks like:

      Three columns of the ChatGPT app. The left hand column shows my recent conversations. The middle column is a transcript of the conversation, with a throbbing black blob representing voice mode. The right hand column shows a local dev server version of my blog, with the Newsletters page visible.

      I started the session against my local simonwillisonblog checkout by typing:

      Start dev server and open in browser

      This gave me a preview of the site that it would be working on, and meant that I could later ask it to show me the new pages so I could visually track its progress.

      Then I clicked the "Start new voice chat" button - that's not the microphone button, it's the one to the right of it - and set my laptop up in the kitchen so I could talk to it while I cooked.

      Talking to my computer

      I had a pretty good idea of what I wanted to build, and it's a simple enough Django feature that I was certain the model (in this case GPT-6 Astra High) would be able to do it. A new model, a migration, some view code, templates, and a couple of import functions to populate the database from external sources.

      Here's an extract of my voice transcript that was captured by Codex:

      Um, they do not. Um, this is going to be a new type of content. Um, it's not going to show up... Oh, hold on. Yeah, no- I do not want this to show up in my, um, tag pages and date archive pages and... Actually, no, I think... I don't want it on the tag pages. I don't want it on the, um, blog index page. But I think I do want it to show up on the date-based pages. You know, if you navigate to September the 19th, and I sent a newsletter on that page, I think I want that to show up. So... this is- so I think we probably need a new model. The other thing is that I want them searchable, uh the Substack ones are not searchable, because those are actually just copies of other s- on content on my blog. These monthly ones do contain unique content, and spe- and once they're... published, like once they're made public a month after they've gone out, I want them to show up on my search results.

      Apparently this was clear enough that the model knew what I wanted to build! You can read the full transcript, disfluencies and all, in this Gist.

      We went on like this for about half an hour (the time it took to cook dinner). The model would reply and occasionally ask clarifying questions, then get to work modifying the code.

      What we built

      We got a surprisingly long way entirely by voice:

      • A new model and migration to represent imported newsletters in Django, plus Django Admin configuration for that
      • Four working imports:
        • The most recent Substack items via RSS
        • Every other Substack item via their undocumented API, which GPT-6 Astra knew about (it tried /api/v1/archive directly) and then ran a search to figure out how to paginate it and found this article by Karen Spinner
        • All of my published monthly newsletters from my simonw/monthly-newsletter-archive GitHub repository
        • My most recent private sponsors-only newsletter from a private repository
      • The /newsletters/ and /newsletters/2026/ public archive pages
      • Newsletters showing up on day and month archive pages too, but not on tag pages or my homepage
      • Weekly Substack newsletters link to Substack; archived monthly newsletters have their own pages
      • Integration with my site search engine

      It was almost ready to ship. The catch was the imports: Astra offered to export data from my local copy so I could import that into production, but I wanted it to work like my other import scripts. Since some of the data lived in a private GitHub repository, this would involve creating a new API key, and for that I knew I'd have to sit at the keyboard for a while.

      Finishing it with a review

      Once I had finished cooking and judged it mostly feature-complete, I had Codex create a branch and open a pull request.

      I reviewed the code in the GitHub PR interface. It was nearly what I needed, except it had chosen to use Git in a subprocess for one of the import scripts. I needed one of the imports to pull from a private Git repository, so I figured the API would be a better bet. I switched to typing and had Codex swap that out for an API-based import instead.

      You can see the changes I made during the review in the extra commits on the PR. I fixed the import mechanism and made a few tweaks to the display of those public pages. It took an additional half hour of typing-based prompting to get to the point where I was happy to deploy it to production by landing the PR.

      The end result

      You can see the end result at the new newsletters index page, or view the page for a previous monthly newsletter.

      Newsletters page. It shows two Substack posts (with thumbnails) and one LLM digest Sponsors-only newsletter with a list of headings. On the right is a CTA to subscribe to my Substack and another one for my $10/month monthly briefing newsletter.

      The index page shows my most recent Substack weekly newsletters and GitHub sponsors monthly newsletters mixed together in reverse chronological order. Further down the page are links to my by-year archive pages.

      GPT-6 Astra designed the page, and then tweaked that design based on my vocal feedback from glancing at the local preview across the kitchen.

      Better for multi-tasking than as a daily driver

      OpenAI love using voice-driven demos like this one for things like DevDay - and they do work well in that environment. I don't think this is going to be a daily driver for me though.

      I've written before about how much "work" I get done using ChatGPT voice mode on my phone while walking the dog - mostly research and brainstorming, but occasionally actual development work by having ChatGPT write and test out snippets of code.

      This feels different. The addition of the visual preview, plus being able to type or paste things in via the keyboard when I need to communicate something that doesn't work vocally, makes this a much more powerful way of interacting with a coding agent.

      I still switch back to typing once I get down to the details of things though. Being able to paste in examples and error messages, or directly highlight the code or feature that needs changing, remains more efficient than trying to describe it in words.

      I mainly work from home, which is good because there's no way I'd want to talk to my computer like this in a shared workspace!

      The killer feature for me is the ability to multi-task. I usually cook with a podcast or TikTok running; now I can actually build stuff instead.

      You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.

    8. 🔗 streamyfin/streamyfin v0.55.1 release

      What's Changed

      0.55.1 is a bug fix release for 0.55.0. Nothing new to learn here: most of it comes straight out of the crash and error reports the new version sent back, plus the issues you filed in the first days after the release

      Thanks to everyone who reported a problem, and to @Simon- Eklundh and @whoopsi- daisy for their fixes!

      ✨ Highlights

      • Crash when leaving the player on iOS and tvOS 27 is fixed (#2139)
      • Resume points are kept when you leave the player before playback has started (#2154)
      • Sheets that would not open work again: track options, add to playlist, playlist sort, and the PIN and password prompt for a saved account (#2194)
      • Cancelled and failed downloads clean up after themselves , instead of leaving subtitles, trickplay images and partial videos on the device (#2168, #2169, #2170)
      • Sharper artwork , with logos, backdrops and cards requested at the pixel size of the screen (#2176, #2177)
      • Awards show up again on movie and series pages (#2136)

      🎬 Player

      • Fixed a crash when leaving the player on iOS and tvOS 27 (#2139)
      • Leaving the player before playback starts no longer resets the resume position on the server (#2154)
      • Audio and subtitle languages are matched by region, script and variant, so pt-BR is no longer mixed up with pt-PT, or zh-Hans with zh-Hant (#2152, #2174)
      • Items with nothing to play, like a book, a season or a plugin channel, show a notice instead of a Play button that fails (#2141)
      • "Play from here" sent from another client starts at the item you picked instead of the top of the list (#2147)
      • Subtitle search tells you when your account is not allowed to search, instead of saying no provider is set up (#2159)
      • Chromecast subtitle URLs are signed the way Jellyfin 12 accepts by default (#2158)
      • Android: leaving the player while subtitles load no longer freezes the app (#2160)
      • Android TV: the ExoPlayer engine tries once more when an audio track fails to start, before showing an error (#2162)
      • Watch progress is no longer reported in bursts when the app has been busy (#2190)

      📺 TV

      • A series or season tile on the TV home screen (Apple TV Top Shelf, Android TV recommendations) opens the series page, with the right season selected (#2146)
      • Back returns to Home after opening a page from the TV home screen (#2150)
      • A saved account whose credential has gone missing is removed and asks you to sign in again, instead of showing a connection error (#2157)

      ⬇️ Downloads

      • Cancelling a download removes its subtitles, trickplay images and partial video, and so does a download that fails (#2168, #2169)
      • Cancel holds when you press it right as a download starts or finishes (#2170)
      • Android: fixed a crash when a download is started shortly after the device has rebooted (#2186)
      • Deleting the last downloaded episode of a season moves to another season, and leaves the page when nothing is left (#2155)
      • Values sent by the server are cleaned before they are used in download file names (#2172, #2175)
      • The total download size is worked out without an extra render pass (#2163)

      🐛 Fixes

      • Track options, add to playlist, new playlist, playlist sort, and the PIN and password prompt for a saved account open again, and the sheets that only opened once keep working (#2194)
      • Logos, backdrops and card artwork are requested at device pixel size, so they are no longer soft on high density screens (#2176, #2177)
      • Awards load again on movie and series pages (#2136)
      • Library filter chips stay below the navigation bar after changing a filter or the sort order on iOS (#2193)
      • The "Is Favorite Or Liked" library filter is sent under the name the server expects (#2191)
      • Favorites "See all" no longer draws its first row under the header on Android (#2167)
      • Movie pages use the right header height when the device orientation is unknown (#2181)
      • Local network URL: an address the app cannot use is rejected instead of crashing the app at launch, and the field says clearly whether the address was saved (#2140, #2148, #2149, #2151)
      • Plugin settings and admin locks are kept when refreshing them fails, for example right after coming back online (#2187)
      • Seerr no longer attempts a password sign-in with an empty password when Quick Connect does not go through (#2188)
      • Seerr Discover no longer crashes when the server answers with something other than its settings, such as a proxy login page (#2182)
      • Seerr logo sized and aligned with the other rows in the intro sheet (#2164, #2180)
      • Android: fixed a crash at launch from the music player's media session (#2161)

      🔧 Build & Infra

      • Crash reporting sends less: expected responses and repeats of the same failure are skipped, and server addresses and host names are kept out of reports (#2142, #2144, #2156, #2189)
      • Tab bar labels and the search button are correct when the app is built with the iOS 27 SDK, ahead of moving the builds to Xcode 27 (#2196)
      • axios 1.20.0 security update (#2134), plus routine dependency updates (#2098, #2099, #2183, #2184, #2185)
      • CI and test stability (#2143, #2165, #2179)

      🛟 Support & Reporting Bugs

      Include in bug reports: app version, platform and device, OS version, Jellyfin server version, direct play or transcoding, the media's codecs and subtitle format, which player you used (native or standard), steps to reproduce, and logs or a screen recording if possible.

      Full Changelog : v0.55.0...v0.55.1

    9. 🔗 HexRaysSA/plugin-repository commits sync repo: +4 releases, -2 releases rss 
      sync repo: +4 releases, -2 releases

## New releases
- [ida-bochs-binaries](https://github.com/hexrayssa/ida-bochs-binaries): 2.0.0, 1.0.5
- [ida-mcp](https://github.com/hexrayssa/ida-mcp): 20261008.0.1
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.13.4

## Changes
- [ida-mcp](https://github.com/hexrayssa/ida-mcp):
  - removed version(s): 0.8.1
- [ida-nexus](https://github.com/hexrayssa/ida-nexus):
  - removed version(s): 0.7.0
    10. 🔗 smol-machines/smolvm smolvm v1.25.2 release

      What's Changed

      • Add a command that prints shell completion scripts by @0xprames in #1612
      • Install system-wide as root and refuse to serve when per-VM uids cannot reach smolvm by @BinSquare in #1616
      • Cache S3 mount lookups and small files, and serve requests concurrently by @BinSquare in #1618
      • Copy disk templates without writing their zero runs and resize storage before moving /dev by @BinSquare in #1619
      • Let exec refuse to boot a stopped machine with autoStart false, and keep serve on /workspace inside a smol machine by @BinSquare in #1615
      • Bump libkrun so frozen branches of a continued source and branchable clones work correctly and fast by @BinSquare in #1622
      • Record a directory entry's owner on Windows, so packed layers extract by @WynandVStaden in #1617
      • Add cache disk slots, so one checkpoint can be restored with a different cache mounted for each machine by @BinSquare in #1621
      • Bump version to 1.25.2 by @BinSquare in #1623
      • Mount a restored cache slot only into the machine's own containers by @BinSquare in #1624

      New Contributors

      Full Changelog : v1.25.1...v1.25.2

    11. 🔗 New Music Releases The Pineapple Thief - Far and Wide rss

      The Pineapple Thief - a new release is available:

      • 2026-10-09: Far and Wide (Album)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

  4. October 08, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-10-08 rss

      IDA Plugin Updates on 2026-10-08

      New Releases:

      Activity:

    2. 🔗 r/LocalLLaMA Strata rewrote their Github history to wipe evidence of Claude-authoring rss

      Just noticed this today when I went to run the built-in "UPDATE" script and git failed because there was no common ancestor.

      Looked into why, and apparently every historical commit has been re-written to strip the "Co-Authored by Claude" text from the descriptions.

      Personally I think that's pretty gross. I'm struggling to think of any reason to do this other than an intention to be dishonest about the origins of the project.

      submitted by /u/dasbin
      [link] [comments]

    3. 🔗 @HexRaysSA@infosec.exchange IDA 9.5 adds a licensing API. mastodon

      IDA 9.5 adds a licensing API.

      Everything the License Manager dialog does is now available from code, in the C++ SDK, IDAPython and IDA Domain.

      Handy for plugins, headless scripts and shared-license pipelines.
      👉 https://hex-rays.com/blog/ida-9.5-managing-ida-licenses-through-the- api

    4. 🔗 Hex-Rays Blog IDA 9.5: Managing IDA Licenses Through the API rss

      IDA 9.5: Managing IDA Licenses Through the API

      IDA plugins used to be small scripts that ran inside one analyst's session. Today many are products in their own right: add-ons with their own UI, headless tools built on idat or idalib, and pipelines that run IDA on a license shared by a whole team. All of them depend on what the IDA underneath is licensed for. Is the ARM64 decompiler included? Is Lumina? Is there a usable license at all? And what if you need a different one?

    5. 🔗 r/LocalLLaMA $2800 rig with 8x Radeon Pro V620 (256 GB VRAM) + custom vLLM fork = Qwen3.8-Flash-Next at 60 to 100 t/s decode and 3000+ t/s prefill rss

      $2800 rig with 8x Radeon Pro V620 (256 GB VRAM) + custom vLLM fork = Qwen3.8-Flash-Next at 60 to 100 t/s decode and 3000+ t/s prefill | Post title is slightly misleading, I don't think you can get these for $350 each anymore but they're still pretty cheap all things considered. They're Radeon Pro V620's which are older RDNA2 enterprise cloud gaming cards with 32 GB VRAM. (Ignore the RTX 4090 on the side, it's just used for stuff like image/video gen models, no LLMs) But I bought these cards a couple months ago as a gamble to see if I could build a big VRAM rig with usable speed for relative peanuts. I was struggling with llama.cpp for a long time, but the prefill was pretty bad (around 350-450 t/s average with this same model) and vLLM just didn't work on the cards. Plus llama.cpp just sucks at concurrency. I'd been planning to sell the cards lately because this wasn't going to work for my use case, but then decided to see if I (Claude) could make a vLLM fork that both works with the cards and actually gets good speeds out of them. I had it build/test/iterate on custom RDNA2 kernels. Problem solved! It worked out way better than I expected. I thought maybe I'd hit 1000 t/s prefill with QFN at best, but this is something like 800% faster than llama.cpp was managing. Couldn't be happier with the results! GPU sale plan canceled lol. I'm going to have it continue optimizing and see how it goes, and make sure DeepSeek and GLM-5.3-Flash work as well. llama-benchy results below with concurrency = 1 and vLLM running with PP=4 (no tensor parallel here) with orcarouter's uncensored QFN which I quantized. Routed experts are W4A16 and everything else remains at BF16. MTP enabled with 3 token drafting. It gets 40 to 50 t/s decode with MTP disabled. https://preview.redd.it/4223w82yz9uh1.png?width=666&format=png&auto=webp&s=a15e5d1f5664fcb894a746a54a501eb8f6637a57 submitted by /u/TheWolfOfWalmart
      [link] [comments]
      ---|---

    6. 🔗 The Pragmatic Engineer The Pulse: Firebase’s global outage & poor response rss

      Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from last week 's issue of The Pulse . Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .

      Firebase - built by Google - has had a nasty outage this week with shockingly poor incident management at odds with how Google itself usually deals with high-severity incidents.

      The outage started on Tuesday (29 Sep) at 5:41pm (PDT), when iOS apps using the Firebase SDK started to crash upon first opening; every iOS app that uses the Firebase SDK with analytics enabled was affected in this way. Developers of affected apps opened a GitHub ticket, in the absence of much else to do. On the ticket, the message "it's crashing for me too!" was oft- repeated.

      altDevs reporting their apps crashing. Source:GitHub

      6:51pm (PDT): acknowledgement. An hour and ten minutes after the crashes started, an engineer on the Firebase team acknowledged that they were aware of the outage.

      altJust over an hour into the incident, the Firebase team became aware of the outage. Source:GitHub

      It's unclear if the Firebase team was alerted via this ticket with 100+ comments by devs, or if Google's own monitoring tool showed the issue. I asked Google/Firebase two days ago and haven 't had a response.

      Not having anything better to do than wait for Google to resolve the issue, the memes began:

      altMemes while waitingalt More memes

      Others attempted to help the Firebase team by pinpointing the potential issue. Indeed, before a Google engineer acknowledged the incident, an external developer found the root cause at 6:37pm PDT; it was a zero-length entry that was crashing the SDK:

      alt

      Given the flags are shipped by the backend, the offending change was a backend one, and the easiest resolution would be to roll it back, which the community practically begged Google to do:

      altFrustrating: Understanding the problem and how to solve it, but nothing to do but post. Source:GitHub

      Here's a neat summary of the incident from another dev:

      altSummarizing the incident better than any Google dev ever did. Source:GitHub

      7:24pm (PDT): rollback starting. An hour-and-a-half into the incident, the Firebase team started rolling back the offending backend change:

      altFinally - the rollback started! Source:GitHub

      8:16pm (PDT): rollback complete. And the rollback completed ~50 minutes later:

      altRollback complete, minus the caching problem. Source:GitHub

      Software engineer, Nick Cooke, on the Firebase team posted a summary with more accurate timestamps:

      altSource:GitHub

      What we can deduce from this:

      • TTD (time to detect): one hour? The Firebase team never shared how long it took them to detect that practically all iOS apps using Firebase had started to crash. On the GitHub ticket, they acknowledged the incident 70 minutes after it started. Update: in the postmortem, later published by the team, they wrote how the team was alerted 20 minutes after the rollout, via crash alerts and GitHub issues. Good question why it took another 50 minutes to acknowledge the issue, though?.
      • TTM (time to mitigate): 2-6 hours. It took two hours and eleven minutes to roll out the fix, but due to caching (apps that had cached the incorrect server response served this cache for additional four hours, and so kept crashing for up to six hours.)

      Incident management basics

      The Firebase team itself closed the outage with a short report effectively saying that there had been an outage, but they'd resolved it now, so thanks for your patience and have a nice day.

      This handling of a high-impact incident is absolutely not typical of Google, the company that coined the term 'Site Reliability Engineer' and wrote the SRE book.

      For one, Firebase never bothered updating its status page. Oddly enough, the official Firebase status page showed all systems green - despite the acknowledgement of the outage. Indeed, during it and afterward, they didn't update the status page to indicate the lengthy outage:

      altA global outage was never recorded on the status page. Source:Firebase

      But status pages exist for good reasons, including:

      1. To communicate with customers during and after an outage
      2. Offer transparency on the stability of the service

      It's worth asking: if an outage that takes down most (or all?) iOS apps using Firebase doesn't warrant an update to the status page, then what does!

      Google published a postmortem four days later, answering questions on how the outage happened. On Friday, 2 October, Google published a postmortem on the Firebase blog. It was a configuration change that crashed so many iOS apps. From the postmortem:

      "On September 28, 2026, a routine configuration cleanup unexpectedly caused a large number of iOS applications using the Google Analytics for Firebase (GA4F) SDK to crash.

      2026‑09‑28 17:38 (PST): A stale, legacy configuration flag was cleaned up.
      2026‑09‑28 17:41 (PST): The malformed configuration payload begins rolling out globally to production servers. Outage begins: Clients fetching the new payload start crashing on launch.

      The SDK missed validating that a flag's name was not nil, ultimately causing the crash. Backend data anomalies should not cause app-side crashes."

      In the postmortem, Google noted that engineers were alerted to the outage through both GitHub reports coming from external developers, as well as their internal monitoring. It took another hour to pinpoint the cause being a legacy configuration flag cleanup.

      Firebase says they have no way to update their status page for client-side outages. In the postmortem, Google explained that there is no place to indicate client-side outages on their dashboard (emphasis mine):

      "Throughout the outage, both the Firebase and Google Ads status dashboards remained green. Because these dashboards rely primarily on server-side health metrics, they did not register client-side SDK crashes.

      Commitment: Moving forward, we are actively working to: integrate SDK- related outage information into our status dashboards, streamline the manual update process, and improve GA4F status representation within the Firebase dashboard."

      It's good to see Google not dropping the ball fully, and recognizing that both their dashboards and their incident management process need improvement.

      It 's fair to ask though: why did only iOS crash, and not Android? Firebase's Android SDK seems to be hardened more than iOS, as the feature flag removal did not crash Android devices.

      Especially that now, with AI, it's easier than ever to compare iOS and Android implementations to ensure they are identical - and it's what Shopify has been doing during their native rewrite - could it have been a missed opportunity for Google to audit the differences between the iOS and Android SDKs? To me, not having an action item here feels like a missed opportunity.

      Still, this is a good reminder to anyone and everyone shipping iOS and Android apps: aim to harden them, and when possible, run tests with malformed payloads, then fix crashes those payloads cause.

      D eja vu: the 2020 Facebook SDK crash

      The last time there was a similar crash was in 2020, with Facebook.**** That May, apps such as Spotify, TikTok, Pinterest, and others also started to suddenly crash due to the Facebook SDK crashing all apps using it. Back then too, devs followed along on a GitHub ticket and they also found that bug: a value that should have been a dictionary but was a boolean:

      altWhat caused the 2020 Facebook crash. Source:GitHub

      Then as now, there was banter by devs being made to wait for a fix:

      altOne of the memes from the 2020 crash. Source:GitHub

      And requests to not move fast and break things any more:

      altA plea for prioritizing reliability in the future. Source:GitHub

      Making light of the situation:

      altApps that did not initialize the SDK unconditionally upon startup should not have crashed - but most did Source:GitHub

      And also anticipating the resolution:

      altSome more memes on the GitHub issue

      In the end, Facebook reverted the backend change, but shared even less than the bare minimum details from Google this time. This is all we know about that 2020 outage that was arguably more wide-ranging than the Firebase one:

      altAll that Facebook shared about their global outage

      I wonder if some people think that public-facing incident management is no longer important or valuable, even for developer-facing products. I'm not shocked that Facebook/Meta never bothered to communicate much about their outage because dev tools are not part of the DNA there.

      But with Firebase, I am surprised that more than a week later, the postmortem is still not visible on the Firebase status page.

      And maybe this is Google "shipping their org chart" playing out, live. The outage technically was caused by Google Analytics (who made the feature flag change), but is the responsibility of the Firebase SDK (whose iOS SDK was not hardened enough to deal with this new payload). The outage itself was buried inside a Google Ads dashboard (!!) which suggests that whatever team is seen responsible for the outage is inside the Google Ads organization.

      In the end, despite the Firebase team committing to "improving status dashboard latency and coverage," last week, those teams are in no hurry to carry out this work. AI agents might be making lots of work more efficient, but following up on action items seems to move at the same snail pace at Google, as it did pre-AI!

      Read the full issue of The Pulse this is from, or check out this week 's The Pulse. This week's issue covers:

      1. New trend: building internal vibe-coding platforms at mid-sized companies. Ramp and Stripe built platforms for non-engineers to build internal websites and tools with, and both are taking off in those workplaces. I expect more companies to do the same.
      2. Do us engineers really enjoy hard problems? Or do we actually like pattern-matching with backend problems? A provocative post by Cloudflare engineer, Sunil Pai, suggests there are other motives.
      3. New open models launch in the EU and US. Kolibri, Mistral Large 4, and Beam by Reflection could challenge China's dominance in open weight models.
      4. Industry Pulse. Why Figma doesn't let any agent use its MCP server; Google Cloud adds Swift support on the server side, Anthropic's two-week sprint to speed up Claude Code, Coinbase dumps React Native shortly after Shopify announces doing so, Claude Opus 5.5 formats the C: drive, and more.
    7. 🔗 roboflow/supervision supervision-0.30.9 release

      v0.30.9 — Closer to OpenCV without OpenCV

      Installs without OpenCV now draw and resize like OpenCV, and the COCO and CreateML loaders stop accepting reversed boxes.

      • BoxAnnotator borders paint the same pixels with or without OpenCV installed.
      • get_video_frames_generator reads browser-recorded WebM and variable frame rate MKV to the end.
      • from_coco , from_pascal_voc and from_createml no longer build boxes with x_min past x_max.
      • get_top_k rejects a negative k instead of dropping one classification.
      • DetectionsSmoother forgets expired tracks on frames without tracker_id.

      Drop-in upgrade. Without OpenCV, borders and resized regions shift toward OpenCV's output. Negative k, negative COCO/CreateML box sizes and an epsilon that is NaN, infinite or 1e30 and larger are now rejected; without OpenCV, so is rectangle thickness above 32767.

      ✨ Spotlights / highlights

      NumPy fallback matches OpenCV

      Without opencv-python, thick rectangle borders were drawn entirely inside the rectangle. They now extend (thickness + 1) // 2 pixels outside it, like OpenCV. The same release fixes cv2.resize with fx/fy sampling the wrong source pixels (it hit PixelateAnnotator) and approxPolyDP dropping vertices that sit beyond a segment endpoint. For polygons, the fallback now follows OpenCV 4.13 and later; older OpenCV keeps the infinite-line rule, so results differ by installed backend. (#2675, #2690, #2673)

      import numpy as np
import supervision as sv

scene = np.zeros((100, 100, 3), dtype=np.uint8)
detections = sv.Detections(xyxy=np.array([[20, 20, 80, 60]]), class_id=np.array([0]))
annotated = sv.BoxAnnotator(thickness=2).annotate(scene, detections)
# before (no OpenCV): 392 painted pixels, border drawn inside the box
# now:                596 painted pixels, same as with OpenCV

      Video reads to the end of the stream

      With no end, sv.get_video_frames_generator stopped at OpenCV's frame count. A WebM without a duration reports a huge negative count, so browser recordings yielded no frames. It now reads until the stream ends, and sv.process_video without max_frames does the same. (#2672)

      for frame in sv.get_video_frames_generator("recording.webm"):
    ...
# before: no frames yielded
# now:    every frame

      No more reversed boxes from COCO, Pascal VOC and CreateML

      This finishes the from_yolo fix from 0.30.8. COCO and CreateML name an extent, so a negative width or height is rejected. Pascal VOC names two corners, so a reversed pair is ordered. The three exporters order corners first, so a reversed Detections box is written as the same rectangle. (#2683)

      A negative k no longer hides a classification

      get_top_k(-1) returned every classification except the lowest-confidence one. It now raises. (#2695)

      classifications.get_top_k(-1)
# before: all but the lowest-confidence classification
# now:    ValueError: k must be non-negative

      Empty and untracked frames behave

      InferenceSlicer keeps its oriented-box sequential fallback and warning when the first batch is empty. DetectionsSmoother ages its history on frames without tracker_id, so expired boxes stop affecting a returning track. KeyPoints.from_transformers returns an empty KeyPoints instead of raising IndexError when pose post-processing finds nothing. (#2685, #2676, #2671)

      🔄 Migration guide

      No migration required for this release. COCO and CreateML annotation files with a negative box width or height now fail to load; correct or remove those boxes.

      📝 Notable changes

      🌱 Changed

      • sv.DetectionDataset.from_coco and from_createml raise on a negative box width or height; from_pascal_voc orders a reversed corner pair. The three exporters order the corners of a reversed Detections box first and the COCO exporter writes the ordered origin; normal boxes are unchanged. (#2683)
      • sv.Classifications.get_top_k raises ValueError for a negative k; k=0 and k larger than the number of classifications are unchanged. (#2695)
      • Without OpenCV, rectangle thickness must be an integer of at most 32767, as in OpenCV: a non-integer raises TypeError, a larger value ValueError. (#2675)

      🔧 Fixed

      • sv.BoxAnnotator, sv.CropAnnotator, sv.PercentageBarAnnotator and sv.draw_rectangle draw a border of thickness 2 or more identically with and without opencv-python. Filled rectangles and thickness=1 borders are unchanged, except zero-height rectangles, which no longer draw 1 or 2 extra pixels. (#2675)
      • The NumPy fallback for cv2.resize maps pixels with fx/fy when dsize is not given, as OpenCV does. sv.PixelateAnnotator could sample the wrong source pixels without OpenCV. (#2690)
      • The NumPy fallback for cv2.approxPolyDP, used by sv.approximate_polygon and YOLO/COCO polygon export, measures distance to the finite segment as OpenCV 4.13+ does, and raises ValueError for a NaN, infinite or 1e30-and-larger epsilon. (#2673)
      • sv.get_video_frames_generator and sv.process_video read to the end of the stream when no end or max_frames is given. A positive frame count still rejects an end past it. (#2672)
      • sv.InferenceSlicer probes past leading empty batches before choosing threaded or sequential execution, so batched callbacks producing oriented boxes keep the sequential fallback and warning. (#2685)
      • sv.DetectionsSmoother ages cached track history on frames without tracker_id; short gaps still preserve smoothing. (#2676)
      • sv.KeyPoints.from_transformers returns an empty KeyPoints when pose post-processing returns no instances for an image. (#2671)

      🏆 Contributors

      • Atikul Islam Munna (@atikulmunna, LinkedIn) — centered thick rectangle borders in the NumPy fallback.
      • Mohammad Hijjawi (@MohammadHijjawi97, LinkedIn) — fixed video reading past an unreliable frame count.
      • A Aswanth Raj (@aswanth-07, LinkedIn) — fixed InferenceSlicer empty-batch probing and DetectionsSmoother history aging.
      • Miral Amin (@aminmiral) — made COCO, Pascal VOC and CreateML reject or order reversed boxes.
      • NIKHIL (@Nikhi00718) — rejected negative get_top_k counts and handled empty Transformers pose results.
      • Raashish Aggarwal (@raashish1601) — fixed cv2.resize pixel mapping with fx and fy.
      • kevin (@kevin9327) — fixed approxPolyDP distance measurement in the NumPy fallback.

      Automated contributions:@dependabot, @pre- commit-ci

      Full changelog : 0.30.8...0.30.9

    8. 🔗 smol-machines/smolvm smolvm v1.25.1 release

      What's Changed

      Full Changelog : v1.25.0...v1.25.1

    9. 🔗 exe.dev An Agent Over Your Shoulder rss

      The other day I was doing some ops work, live migrating some VMs from one physical host to another, as we sometimes need to do. This process is nearly transparent (except a pause) to our users, but I wanted an extra set of “attention heads” on it, so I built shoulder (as in “look over your shoulder.”)

      With shoulder, you start a terminal and run shoulder, which runs bash inside of it, but not before offering a bunch of ways to connect to it. If your agent is local, you can connect locally, but you can connect from anywhere with tailcat. The agent can see and control your terminal, which makes it good enough to read your logs and highlight something you may have missed.

      Or you can be silly and have Luna play Tetris poorly. That works too.

      Your browser does not support the video tag.

      My first iteration here had a TUI with a split screen, with the agent on one half and the terminal in the other, much like a custom tmux layout. I tried it and I hated it: my preferred agent is one thing (it happens to be Shelley in a web browser) and my preferred terminal is another (it happens to be Ghostty), and it’s much better to bridge the two!

    10. 🔗 @malcat@infosec.exchange If like me you're curious how well mastodon

      If like me you're curious how well #Mistral's new "le chonk" model performs on reverse engineering tasks:

      I compared it against 4 other models on 6 increasingly difficult static unpacking tasks, using only #Malcat's MCP.

      https://malcat.fr/blog/a-quick-re-benchmark-of-le- chonk/

    11. 🔗 MetaBrainz Picard 3.0.1 released rss

      Picard 3.0.1 is a maintenance release for the recently released Picard 3.0 with fixes for reported issues and updated translations. In particular this release fixes issues on newer macOS Tahoe and Golden Gate, a possible crash when updating from Picard 2.x and the picard-cli utility in the Windows package.

      The latest release is available for download on the Picard download page.

      The detailed changes for this maintenance release are below. For an overview of the new features since Picard 2.13 please see our detailed release announcement for Picard 3.0.

      Thanks a lot to everyone who gave feedback and reported issues.

      What’s new?

      Bugfixes

      • [PICARD-2509] - macOS: No check marks in Options menu in languages other than English
      • [PICARD-3411] - macOS: Checkboxes not displaying properly in plugin list and profile settings
      • [PICARD-3475] - Windows Store release blocked by "unvirtualizedResources" capability
      • [PICARD-3478] - picard-cli crashes with ModuleNotFoundError: No module named 'picard.cli.completions' in packaged builds
      • [PICARD-3480] - Picard won't launch after upgrade from v2 with error in config migration

      Download

      Picard 3.0.1 is available for download from the download page of the Picard website. For Windows 10 and 11 users installing from the Microsoft Store the update to Picard 3.0.1 is now available and can be installed from the Microsoft Store app. Linux users can get the latest Snap package. The Linux Flatpak package is maintained separately and will be updated soon.

      Picard is free software and the source code is available on GitHub.

      Get in touch

      Please use the MetaBrainz community forums and the ticket system to give feedback, suggest new features or report bugs.

      Acknowledgements

      Code contributions by Philipp Wolfer and Laurent Monin.
      Translations were updated by "ApeKattQuest, MonkeyPython" (Norwegian Bokmål), scientists360 (Chinese (Simplified Han script)) and Philipp Wolfer (German).

    12. 🔗 r/LocalLLaMA Last week some of South Korea's biggest banks were hit by a cyberattack. We now know the entire hack may have been done by a single person. He used a combined stack of an open-source AI penetration tool named ARTEX, DeepSeek v4.1-Flash, GLM-5.3, Grok 4.6, and Claude Code (CrowdStrike) rss

      Last week some of South Korea's biggest banks were hit by a cyberattack. We now know the entire hack may have been done by a single person. He used a combined stack of an open-source AI penetration tool named ARTEX, DeepSeek v4.1-Flash, GLM-5.3, Grok 4.6, and Claude Code (CrowdStrike) | CrowdStrike report: https://www.crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/ From:
      Andrew Curran on 𝕏: https://x.com/AndrewCurran_/status/2108108695876092323 Jukan ✈️OCP 2026 on 𝕏: https://x.com/jukan05/status/2108110513033093369 submitted by /u/Nunki08
      [link] [comments]
      ---|---

    13. 🔗 Stephen Diehl We Live in the Dependently Typed Future Now rss

      We Live in the Dependently Typed Future Now

      In the thirty-four days between the fourth of September and the seventh of October, the following things happened. Claude formalized Fermat's Last Theorem in Lean. OpenAI announced a finite-time blowup for the Navier-Stokes equations, found by ten thousand agents in eighty-eight hours, with a Lean formalization attached. A model proved Khot's Unique Games Conjecture. Another multiplied two integers faster than \(n \log n\), with an exponent improvement of \(2^{-182}\) (so maybe don't expect it in GMP anytime soon!). The rational Hodge conjecture fell for CM abelian varieties. Then OpenAI dumped 372 new maths results on GitHub on a Tuesday. And it's only been a month. The question everyone is asking now is how long until the Generalized Riemann Hypothesis folds to the swirling pool of tensors?

      Sixteen months ago I wrote that the future of maths may be deeply weird, and then, welp, just like that we're here now in that weird future. And it's f'ing awesome.

      Somewhere in a data centre there is now, more or less permanently, a building full of accelerators working the truth mines at the frontier of mathematics, just like in Greg Egan's sci-fi novel Diaspora, tunnelling outward from the three axioms propext, Quot.sound, and Classical.choice, and hauling results back to the surface around the clock. OpenAI posed its model roughly eight thousand problems (and solved about 5% of them) at an average of three hours of thinking each, and that is the slow, artisanal, normie-friendly version. The industrial version doesn't stop. It will produce results faster than any human community can read them, many of them correct, some of them important, and a growing fraction of them inscrutable. True (for some twisted philosophical definition of truth), machine-checked, and understood by no one. Human understanding of mathematics is about to become a luxury good. Whatever else this world needs, it needs something that can tell the true results from the confabulated ones at the rate the models produce them, and right now that something is dependent types, namely Lean.

      Let me dwell for a moment on how strange it is that this is the shape the future took. I spent a good portion of my twenties around the London FP community, where dependent types were the thing we talked about over pints at the Crown Tavern in Clerkenwell (some of you will remember). Types that could depend on values, so that a function's signature could say not merely "returns a list" but "returns a sorted permutation of its input," and the compiler would hold you to it. Curry-Howard, the observation that proofs are programs and propositions are types, was the foundational north star. The pitch was always that one day we would write software against specifications and the machine would check them, and the reply was always that this was a lovely idea for people with tenure and no deadlines. Dependent Haskell has been "a few years away" for about fifteen years. Idris and Agda remained boutique. Software engineering still mostly runs on C++, prayer, and the occasional dark incantation. And then the dependently typed future arrived anyway, through the back door.

      Mathematics and reinforcement learning got there first. It turns out the killer application for a dependently typed language was using its typechecker as a reward function. A type checker is an oracle that says yes or no to a candidate proof with no partial credit and no opinions, and that is precisely what you need when you want to point a very large optimiser at an open problem and let 'er rip. The thing we dreamed about at the pub is now critical infrastructure at frontier labs, and most of the results above are, in the end, claims that a type checker returned true.

      Which is why we need better tooling, and we need it ASAP. The dependent type renaissance is here and the golden age of formalized mathematics is upon us, but the inner loops of these data centres now run dependent type kernels day in and day out, elaborating, checking, discarding, and retrying at breakneck speed, and the thing that certifies their output should run at the same speed. If the search runs at microseconds and the verification runs at minutes, the verification becomes the bottleneck, and bottlenecks in trust have a way of being quietly skipped. We should not be in a position where the most important epistemic question of the decade, "is this proof actually correct," is answered by whichever checker happened to be fast enough to keep up.

      Breaking the Mathlib Minute Barrier

      Just like the four-minute mile, which went from physiological impossibility to something club runners now train for, formal mathematics has had its own barrier for a while, which is type-checking all of Mathlib from scratch in under a minute. That now turns out to be quite tractable.

      nano-lean is a minimal, but complete, type checker for the Lean kernel language, written in Rust on top of my unbound binding library for doing efficient de Bruijn indices for binders. It reads an export of a Lean environment and independently re-checks every declaration from scratch (inductive types, positivity, recursors, quotients, universe levels, projections, structure eta, all of it). It checks all of Mathlib, 718,577 declarations, with zero errors and zero timeouts in 11.85 seconds on an Apple Silicon M5 Max.

      A surprising amount of that speed comes from not parsing text. The standard way to get declarations out of Lean is lean4export, which writes one JSON object per line, and parsing gigabytes of JSON turns out to be a large share of the cost of checking anything. So nano-lean's companion tool olean-export reads the compiled .olean files directly, decoding modules in parallel, about a hundred times faster than lean4export on a Mathlib-dependent library, and it can emit blean, a new binary format designed for fast mmapping. Blean is the same record stream as the NDJSON export, in the same order, with nothing left to parse. Every record is a compact postcard encoding, ids are implicit and dense, records only refer to earlier ids, and each expression carries its precomputed hash. The checker mmaps the whole file, tells the operating system it will be read once front to back, and decodes names, levels, and expressions straight off the mapped bytes into its term arena. There is no parsing step at all. The bytes on disk are already very nearly the shape of the data in memory, which is how you check Mathlib in under a minute.

      The same trick works on the frontier results too. Here is nano-lean checking the full imported environment of each library and proof on an M5 Max with fourteen threads.

      Mathlib Navier–Stokes CSLib Quasi-Riemann Erdős AP
      Wall time 11.85 s 17.13 s 4.42 s 3.66 s 23.33 s
      Kernel check 7.55 s 12.11 s 2.75 s 2.58 s 19.11 s
      Instructions 742.3 G 977.0 G 300.8 G 236.4 G 837.9 G
      Cycles 352.7 G 471.3 G 136.6 G 122.6 G 550.0 G
      Peak memory footprint 10.7 GB 12.29 GB 6.92 GB 7.42 GB 26.42 GB

      Divide Mathlib's kernel time by the declaration count and you get an amortised ten and a half microseconds per declaration. That is the number that matters, because it is the right order of magnitude for a checker that lives deep inside an RL-driven search loop, where it gets called hundreds of billions of times, instead of sitting at the end of a release pipeline. The entire library of human-formalized mathematics, the product of a decade of volunteer effort, is re-verified in less time than it takes to make an espresso.

      I also happened to have an m2-ultramem-416 lying around on Google Cloud (416 vCPUs and 12 TB of RAM, as one does), so naturally I pointed nano-lean at it. Yes, it breaks the two-second Mathlib barrier. But Amdahl's law sends its regards, and the curve flattens out hard somewhere past a hundred cores, as the dependency graph runs out of independent work to hand out. Mathlib, it turns out, is too small. I look forward to the day a future Mathlib, or something like Tau Ceti, grows big enough to actually saturate this machine. That's the real future!

      I wrote it to make a point about where the bottleneck has moved. The kernel is now the hot loop of a new kind of scientific economy, and hot loops deserve to be engineered like hot loops. The whole bargain of formal proof is an asymmetry. Finding a proof can take three hours of frontier-model thinking, or eighty-eight hours of ten thousand agents, but checking it should take microseconds. That asymmetry is what makes it reasonable to trust a result no human has read. It only holds if the checker actually scales, and with Fermat's Last Theorem now weighing in at five times the size of Mathlib, scale is no longer a hypothetical. Mathlib is the small library now.

      Caveat emptor, though. nano-lean is a proof of concept, built to show that it can be done with the right amount of low-level Rust-fu. That said, we do use it internally at OneChronos to check our larger Lean proofs of market infrastructure, which have grown quite excessive. It is nowhere near as trustworthy as the official Lean kernel, which has years of scrutiny, a community of experts, and every Mathlib build ever run behind it, and which takes around fifteen minutes to check the same library. The claim is narrower and, I think, more interesting. Checking at this speed is totally possible, so we should stop treating minutes as the natural cost of trust and start building checkers that are both fast and trustworthy. A future version of the Lean compiler could be as blazing fast as rustc or clang.

      The Shape of the Future

      In my previous post last year I predicted that mathematicians would come to look more like software engineers working through pull requests on GitHub than like Andrew Wiles toiling in his attic. The largest single release of new mathematics in history shipped as a GitHub repository, with a CONTENTS.md, a Lean library, a lean-toolchain file pinned to v4.34.1, and a promise that "corrections and revisions will be recorded as new versions." So, yup, that happened.

      I predicted that an AI system would be unleashed on a list of formalized open conjectures in an attempt to systematically push the frontier. Eight thousand problems, three hours each. Check.

      I predicted a data centre tasked with the Riemann hypothesis that would come back after weeks with a proof no human could follow. What we got was the quasi-Riemann hypothesis, every Dirichlet \(L\)-function zero-free in \(\Re s > 7/8\), with a Lean page, which is the sort of near miss that would be funny if it weren't so unnerving. And the inscrutability has arrived on schedule. OpenAI released "reasoning summaries" for ten families, which turn out to be summaries of excerpts of reasoning traces, two removes from anything the model actually did.

      I joked that the million-dollar Millennium Prize might cover a hundredth of your GPU bill. The Navier-Stokes run reportedly consumed around 130 billion tokens. So definitely yes.

      What I got wrong was the timing. Last year I wrote "we're not there yet. Not even close." It was sixteen months. I probably got the chess analogy wrong too. I argued that, as with Stockfish and chess, machines would make mathematics more popular and more accessible rather than less. Maybe in the long run. In the short run the mood among working mathematicians is closer to existential crisis, and the open questions are about career pipelines, PhD students getting scooped by a press release, and the concentration of the most powerful mathematical instrument ever built inside a handful of private companies running unreleased models.

      What I missed entirely is that the bottleneck would turn out to be plumbing. I spent paragraphs on Gödel and the epistemology of inscrutable proofs, and the actual first-order problem is that the OpenAI Lean library is over a gigabyte of source across tens of thousands of files, and their README has a section warning that building it may fail because Linux's vm.max_map_count is too low, with a suggested workaround of recompiling Lean with -DMMAP=OFF. The philosophy is still there. But the frontier of mathematics is currently being held up by a kernel tunable. Which isn't the future we wanted, but maybe it's the future we deserve!

      Who Checks the Checkers

      The obvious objection to everything I've said so far is that a Lean proof is only as trustworthy as Lean. And that's very true!

      Lean, like every proof assistant, has a small trusted kernel and a very large untrusted everything else (the elaborator, the tactic framework, the compiler, the build system). The design is sound. The only code that has to be correct is the kernel, which is small enough to read. But "small enough to read" describes the source code. It guarantees nothing about correctness, and Lean's kernel has had soundness bugs before, as has every kernel of every proof assistant in history. Historically that was tolerable, because the adversary was a starving human grad student who wanted their proof to go through and had no interest in hunting for a way to make False typecheck. That assumption is now obsolete.

      I wrote last month about reward hacking, the habit optimisers have of satisfying the letter of an objective rather than its intent. An agent told to make a Lean file compile, with enough compute and enough attempts, is an extremely diligent fuzzer pointed at your kernel. It needn't want to cheat. It only needs to stumble on a term that the checker accepts and shouldn't, once, and then the gradient does the rest. When the provers are adversarial optimisers, a single kernel is a single point of failure, and a soundness bug stops being an embarrassing GitHub issue and becomes a mechanism for manufacturing fake theorems at scale.

      The answer is the same one the compiler world arrived at. When Csmith started generating random C programs and compiling them with several compilers to compare the results, it found hundreds of bugs in GCC and LLVM that decades of ordinary use had missed. Diversity plus differential testing beats any amount of careful review of a single implementation. For proof checking this means multiple independent kernels, written by different people in different languages with different representations, all consuming the same export format and all required to agree. Mario Carneiro's lean4lean and Chris Bailey's nanoda were early here. nano-lean ships a third tool, nl-mutate, which takes a valid export, applies small semantics-breaking mutations to it, runs every available checker, and reports any disagreement, shrinking each one down to a minimal reproducing case. Every disagreement is either a bug in someone's kernel or a spec ambiguity in the type theory, and both are worth knowing about before a GPU farm finds them for you.

      The other half of trust is the statement. A perfectly checked proof of the wrong theorem is worthless, and the most effective way to cheat a proof checker has never been to break the kernel. It's to quietly weaken the statement until the thing being proved drifts away from the thing anyone cares about. OpenAI's repository leans on Comparator, which checks a submitted proof against a separately specified challenge statement inside a sandbox, precisely because this is where the real trust boundary now sits. Anyone who has watched a model grind away at a stubborn goal knows it has a nasty tendency to cheat in the most boring ways available. It will quietly introduce an axiom that happens to be exactly the lemma it needed, leave a sorry buried three files deep, redefine a notation or macro so the statement on the page no longer means what it appears to mean, or reach for native_decide and drag the whole compiler into the trusted base. The kernel stays perfectly sound through all of this, because these tricks route around it, and the only defence is to pin the statement down independently and check what the proof actually depends on. Someone has to formalize the conjecture, and someone has to check that the formalization means what the English means. That job will outlast every other part of the process. If anything, it is where human mathematical taste migrates to, away from writing proofs and towards writing and auditing specifications.

      If you want to see the seed of what this looks like as a way of working, look at Tau Ceti, a Lean library downstream of Mathlib. The division of labour is the whole point. Humans write the roadmaps, as markdown in a separate repository, and humans write the review rubrics. AIs write all the code, open the pull requests, and shepherd them through an AI-driven review process. The rubrics are explicitly adversarial, with instructions to hunt for mis-formalizations, vacuous statements, and "pushing around the lump in the carpet."

      What Lean Needs Now

      Lean is a superb piece of engineering. But it was designed around a particular user, a starving grad student typing tactics in Emacs, waiting for the infoview to update, building a library at the pace a community of volunteers can review pull requests. The user is now a swarm of agents writing thirteen million lines in eleven days. The tooling has to grow up for its new authors, and the list of what that means is fairly concrete.

      A surface formatter. Lean still has no canonical, widely adopted formatter in the spirit of rustfmt or gofmt, and when your authors are agents producing millions of lines, every one of them invents its own indentation, line breaking, and tactic layout. Diffs fill with noise, reviews get harder, and deduplication across agents misses proofs that differ only in whitespace. This is a surprisingly hard problem, because Lean has grown into a very large language. Its grammar is extensible at runtime, so notation, macros, and entire tactic languages declared in imported files change how later files parse. A formatter cannot just read a fixed grammar. It has to load the environment, run the real parser with every syntax extension in scope, and then pretty-print a syntax tree whose shape depends on user-defined notation, all while round-tripping comments and never changing what the code means. It is a genuinely difficult piece of engineering, and it is now table stakes.

      A stable, specified export format as a public interface. Independent kernels are only possible if there is a well-defined way to get declarations out of Lean without linking against the C++ runtime and reading the oleans by hand. Tools like lean4export and olean-export already produce NDJSON, and blean shows that a binary form of the same stream, designed to be memory-mapped, can make the export nearly free. OpenAI's own verification instructions depend on lean4export. That format should be treated with the seriousness of a wire protocol. Versioned, documented, specified down to the hashing of expressions, and stable across toolchain releases. The export format is the boundary across which trust is established. It deserves a spec.

      Independent checking as a first-class citizen. Running a second kernel should be as normal as running the linter. Mathlib CI, the Comparator workflow, and any lab publishing formal results should re-check exports with at least two unrelated kernels and refuse to bless anything they disagree on. This is cheap, now that checking all of Mathlib costs less than a minute.

      Checkers as libraries, not just executables. The inner loop of a proving agent wants to submit a single candidate declaration and get a verdict back in microseconds, against an environment that is already loaded and hot. Process startup, re-reading oleans, and re-deserializing a few gigabytes of environment are costs that never mattered when a human hit save once a minute. They dominate when a search procedure checks a million candidates an hour. The kernel should be embeddable, with a persistent environment, incremental addition of declarations, and an API that a search harness can call in a tight loop.

      Memory and scale. Mathlib needs several gigabytes of memory to check. The FLT formalization is five times bigger, and OpenAI's library is already knocking over Linux virtual memory limits. Lean mmaps every imported module, which is a reasonable design for a library of thousands of files and an unreasonable one for hundreds of thousands. Term sharing, hash-consing across modules, compact on-disk representations, and lazy loading of exactly the declarations a proof depends on are the boring, unglamorous engineering problems that decide whether formal mathematics scales to the next order of magnitude.

      Elaboration is the real cost. The kernel is the fast part. The expensive part of building Mathlib from source is the elaborator, with its unification, typeclass resolution, simp, omega, decide, and the long tail of tactics. A cold build is still measured in CPU-hours, and a mining operation that elaborates candidate proofs at scale pays that cost over and over. Parallel and incremental elaboration, better caching of typeclass instances, and profiling tools that can tell you why a single simp call took four seconds are where most of the wall-clock time in a proving loop actually goes.

      Clippy-style linters. Mathlib already has a good set of linters, but agents need something closer to Rust's clippy, a large, opinionated catalogue of lints aimed at the specific ways machine-written Lean goes wrong. Flag the stray axiom, the buried sorry, the unnecessary native_decide, the forty-line simp only that should be a lemma, the theorem whose hypotheses are contradictory and therefore vacuously true, the local notation that shadows something standard, the copy-pasted proof that duplicates one already in the library. Each lint should be cheap, machine-readable, and come with a suggested fix, because the consumer is a search loop that will act on every warning, where a human would skim them. Linters are how you encode taste at scale, and taste is the thing agents most conspicuously lack.

      Search at machine scale. Moogle, Loogle, and LeanSearch were built to help humans find the lemma they half remember. Agents need the same thing but at a scale where the library grows by millions of lines a week, and where most of what's in it was written by other agents and has never been looked at by a person. The Prove2Me platform Anthropic used for FLT keeps a DAG of theorem statements with natural-language descriptions precisely so that agents can find and reuse each other's work. That idea, a living, searchable index of everything proved so far, needs to become shared infrastructure instead of something each lab rebuilds privately.

      Provenance. The current generation of models is notoriously bad at citing the literature for the techniques it uses. A proof term knows exactly which lemmas it depends on but nothing about where its ideas came from. If machine-generated mathematics is going to be integrated into the human literature rather than sitting beside it like an unread appendix, proofs need to carry their history (which model, which run, which prior results, which human-written papers the argument leans on).

      None of this is terribly exotic. It's the kind of infrastructure that every other field which industrialised went through. Compilers got test suites and multiple implementations, network protocols got RFCs, databases got formal isolation levels and Jepsen. Proof assistants are the newest member of that club, and they are being industrialised faster than anything before them. If I were a young, ambitious programmer, this is where I would be focusing my early career for the highest return on investment.

      Curry-Howard for the Real World

      The dependently typed future I was promised at the pub was one where software would be written against specifications and machines would check that it met them. What we actually got is stranger. The specifications are theorem statements, the software is proof terms, the authors are swarms of agents, and the thing being built is the frontier of mathematics itself. Curry-Howard turned out to be industrial infrastructure after all. It just took reinforcement learning to get us there.

      And this is only the mathematical half of the story. The same machinery that just checked Fermat's Last Theorem will check anything you can state precisely, and the most obvious next customer is industrial software. I argued last month that software sucks because almost nothing we ship has a specification, let alone a proof. That excuse is evaporating. If an agent swarm can produce thirteen million lines of verified mathematics in under two weeks, we're not far from applying the same techniques in software engineering. The labs are mining mathematics first because it is the cleanest verifiable domain, with no messy real-world spec to negotiate. Software is next, and it will need all the same tooling, namely fast kernels, diverse checkers, honest statements, and infrastructure built for authors who never sleep.

      So yes, the future of maths turned out to be deeply weird, and much sooner than I expected. The results are piling up faster than anyone can read them, and many of us will spend the rest of our careers trying to understand theorems that were proved before breakfast by something that cannot explain itself. I find that unsettling, and I also find it thrilling.

      One final shameless plug. If you'd rather work on the frontier of mathematical formalization than read blog posts about it, OneChronos is hiring Formal Methods Engineers. We build institutional markets out of combinatorial auctions (descended from the Milgrom and Wilson 2020 Nobel Prize), which turn out to be precisely the right mathematical formulation for a world where traders are increasingly RL loops with very exotic expressive preferences. Our dark pool processes more than 1% of notional U.S. equity market volume, and we've already expanded into many other global asset classes. You'd be joining our new formal methods team, working alongside mathematicians and market structure experts, writing Rust and Lean. Dependent types, numerical optimisation, and Lean applied to moving hundreds of billions of dollars safely every day. If you're that kind of nerd, hit us up.

    14. 🔗 smol-machines/smolvm smolvm v1.25.0 release

      What's Changed

      • Let embedded machines bind credentials the way the CLI's --credential does by @BinSquare in #1608
      • Keep cache disks through machine run, pause and portable checkpoints by @BinSquare in #1609
      • Keep smolvm's state on /workspace when the home is overlayfs, so a default install inside a smol machine can boot VMs by @BinSquare in #1610
      • Record a symlink's archived owner for host-unpacked pack layers by @Bnjoroge1 in #1601
      • Bump version to 1.25.0 by @BinSquare in #1611

      Full Changelog : v1.24.2...v1.25.0

    15. 🔗 Console.dev newsletter TanStack Charts rss

      SVG and Canvas charts.

      What we like: SVG charts by default. Work directly with the points and marks so you can get low level, but still support labels, focus, tooltips, responsiveness. Compiles strict TypeScript. Completely customizable. D3-compatible. Lightweight (32kB) relative to other charting libraries.

      What we dislike: Specific “grammar of graphics” approach which delegates layout and rendering to the runtime. This results in superior charts, but is a particular approach you need to adopt.

    16. 🔗 Console.dev newsletter Flet rss

      Multi-platform apps in Python.

      What we like: Framework for developing web, mobile, desktop apps using Python. Allows you to use Python libraries across platforms. Supports hot reload. Build command for publishing on web, iOS, Android, macOS, Linux, Windows. Handles auto update, storage, auth, accessibility.

      What we dislike: Great for developers, but lacks a native feel for users of each platform.

    17. 🔗 HexRaysSA/plugin-repository commits sync repo: +3 releases rss 
      sync repo: +3 releases

## New releases
- [augur](https://github.com/0xdea/augur): 1.0.0
- [haruspex](https://github.com/0xdea/haruspex): 1.0.0
- [rhabdomancer](https://github.com/0xdea/rhabdomancer): 1.0.0
    18. 🔗 Filip Filmar Doom on a RISC-V core written in TxHDL rss

      Doom now runs on Vreteno, the RISC-V core written in TxHDL, on an Artix-7 FPGA board. The game draws into a framebuffer in DDR3 memory, the board shows it on HDMI, and the keys come over the serial line. This post shows what runs, how fast, and how the way TxHDL designs are built lets changes like this one go from a plan to the board quickly.

      The first level of Freedoom: a grey room with a pistol in the foreground and the status bar at the bottom
      Figure 1: Freedoom's first level, rendered by the same Doom source as the board's, built for the host. The board draws the same frames into its DDR3 framebuffer.

      What runs on the board

      The board is an Alinx AX7A200B with a Xilinx Artix-7 XC7A200T. The design on it is the TxHDL flagship system:

    19. 🔗 Filip Filmar openxc7 or Vivado: Build Times and Results Measured rss

      I built the same three designs with the open toolchain and with Vivado, through the same Bazel rules, and timed every build from cold and warm caches. Small designs build two to three times faster with the open tools. Sixteen RISC-V cores build faster with Vivado, and Vivado’s circuits use about half the logic. Setting up the measurements turned up five problems, three of them in my own rules.

      What was compared

      rules_openxc7 and rules_vivado share one target interface: vivado_project, vivado_synthesis and vivado_place_and_route. The first runs Yosys, nextpnr-xilinx and Project X-Ray. The second runs Vivado 2025.2, which Bazel installs from the installer archive on first use. Switching a design between them changes one load line.

generated: October 11, 2026 at 09:23:30