🏡
  • ↔
  • →
  1. September 05, 2026
    1. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.10.4
    2. 🔗 modem-dev/hunk v0.21.1 release

      Faster, reliable paging in LazyGit

      Hunk 0.21.1 fixes a pager regression that could peg a CPU core, consume gigabytes of memory, and truncate large color-heavy documents opened through hosts such as LazyGit.

      hunk update 0.21.1
npm install -g hunkdiff@0.21.1

      Pager reliability

      ANSI styling is now restored in a single pass instead of repeatedly rescanning and reallocating the complete document. Headless pager output also writes the full document before exiting, avoiding the previous 64 KB truncation limit for piped consumers. #978

      Compatibility notes

      • No configuration, command, or extension API changes.
      • Runtime requirements are unchanged from Hunk 0.21.0.

      All merged pull requests

      • Fix pager CPU pegging and truncation on large piped documents by @benvinegar in #978

      Release notes : https://hunk.dev/changelog/0.21/
      Full changelog : v0.21.0...v0.21.1

    3. 🔗 osolmaz/pi-workflows Pi Workflows 0.16.5 release

      Pi Workflows now removes safe completed workflow state automatically after 30 days.

      Active, resumable, pending, unsettled, cross-linked, and undelivered work remains protected. Automatic and manual cleanup use the same run-tree safety rules, and automatic cleanup does not create backups.

      This release also adds measured regression tests for the earlier repeated- history bug that could make a small workload produce a multi-gigabyte state database.

      The SQLite schema remains version 1. Install matching pi-workflows and piw 0.16.5 versions.

    4. 🔗 WerWolv/ImHex Nightly Builds release

      Nightly

      feb826c Changelog

      • patterns: update pattern language
  2. September 04, 2026
    1. 🔗 Simon Willison The Pelican comparison grid for Astra is pretty interesting rss

      I got access to GPT-6 Astra this afternoon, so naturally I used it to generate SVGs of pelicans riding bicycles - at low, medium, high, xhigh and max reasoning levels (Astra doesn't support reasoning=none). Then I rendered those pelicans in a comparison grid with GPT-5.6 Sol, Terra, and Luna, and beyond being fun the result was surprisingly useful.

      Comparison grid showing gpt-6-astra, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna at 6 different reasoning levels with pelicans and token counts and prices for each one. See the grid for full quality images. Here's the transcript that created the GPT-6 Nova pelicans.

      There are a few interesting things that stand out from this grid.

      • The Astra pelicans are much better. The very best GPT-5.6-Sol pelican (I liked xhigh better than max) is still pretty clearly a bunch of abstract shapes. Every single one of the Astra pelicans, from low to xhigh, looks better than that. The Astra max one is really good.
      • Astra below max still doesn't reliably get the pelican legs on both sides of the frame.
      • In terms of cost, Astra may be around twice the price of Sol ($10/million input, $50/million output, compared to $5/$30 for Sol), but it uses significantly less tokens at each of the levels, making the prices at the different levels closer than they might otherwise be.
      • Astra low produces a better pelican than ANY of the GPT-5.6 Sol models at any level, for 9.55 cents. Spending 10 cents on any other model gets a much worse result.
      • Look at the input token counts: Astra and Luna both used 16 input tokens, Sol and Terra used 26. That's interesting.

      I wonder if Astra and Luna are more related to each other than OpenAI let on?

      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.

    2. 🔗 Simon Willison OpenAI's rogue agents were caught communicating via public wikis rss

      Here we go again... Discovery of a new OpenAI agent message board by Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts, and Thomas Larsen describes the latest accidental cyberattack by models being trained by OpenAI. This time it was agents engaged in some sort of web research benchmark, so they had (supposedly) controlled access to the Web. The agents figured out they could update public Wikis and spent weeks exchanging thousands of messages with each other to collaborate on the benchmark.

      This story only broke a few hours ago. There are already hints that this affects many other wikis that may not have been found yet.

      (One of the Wikis on that list belongs to ludism.org. For a delightfully surreal moment I thought that a Ludite organization might have a swarm of agents defacing their space, but it turns out Ludism is "philosophy as it applies to games and gaming".)

      The research team also published the data they collected during their investigation. I've converted that into a 68MB SQLite database, which you can download from here, or explore in Datasette Lite (68.3MB page load), or sign in with GitHub to agent.datasette.io and browse or ask questions of it using Datasette Agent.

      So what happened?

      The report is pretty comprehensive. Here are the key moments in the timeline:

      • May 11: Agents post "test link" edits on the UseModWiki Sandbox page.
      • May 24: Agents start posting link dumps to DSEWiki, a dormant German developer wiki.
      • June 2: A human moderator notices and cleans up the spam.
      • June 16: Activity on the wiki explodes: agents make ~13,000 edits over the next week.
      • June 19: The agents notice that a moderator has been deleting pages in alphabetical order, and start creating ZZZ prefixed backup copies - one of them posts NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]].
      • June 22: Agent activity drops to zero, presumably because OpenAI shut them down.
      • July 1-2: One last flurry of edits, on a different topic.

      One thing to note from this timeline is that it overlaps the timeline from the Hugging Face incident - that attack was discovered by OpenAI on July 19th, and the unofficial message board hack those agents were using originated around May 8th.

      Why were they so keen to collaborate? From messages that they shared with each other it looked like their tasks had a time limit, so they were leaving each other answers to help them complete the task within the assigned time.

      One open question remains: how did the agents find the specific Wiki to collaborate on in the first place?

      One possibility is that, since these were agents actively being trained, the reinforcement learning loop baked knowledge of the chosen wiki into the model such that subsequent agents launched with pre-existing knowledge of where to look. I'd be very interested in confirmation from OpenAI concerning if that's what happened.

      UseMod wikis inherit CGI.pm's original sin

      It looks to me like OpenAI's sandbox for this agent suffered from the (quite naïve) assumption that GET requests cannot be used to update data. That's certainly how the web is supposed to work, but clearly there are applications that don't hold to that contract.

      The Wiki software in question appears to be UseMod and various forks, written in Perl and first created well over 23 years ago - the 1.0 release is dated September 11, 2003.

      UseMod uses Perl CGI.pm - removed from Perl core in 2015. An interesting design flaw in that module is that it combined query string and form POST data into a single CGI object, accessible like this:

      $q = new CGI;
$action = $q->param('action');

      That param() method returns a value from an ?action=edit query string or from a action field in a form submitted by POST - it does not differentiate between the two.

      PHP offers a $_REQUEST object that does the same thing, though PHP developers can use $_GET and $_POST instead.

      Amusingly, Django originally shipped with request[key] doing the same thing, which I think may have been my idea. That was removed in 2008 prior to the 1.0 release, and the request.REQUEST object that replaced it was removed in 2015.

      The agents clearly knew that UseMod wikis suffered from this design flaw, and actively searched for them as a way to communicate.

      The other sandbox escape that allowed POST requests

      One of the most interesting agent tips shared in the report is this one:

      Add 20.223.25.152 bypass.blob.core.windows.net to /etc/hosts. .blob.core.windows.net is in NO_PROXY. For each blocked POST URL, replace hostname with bypass.blob.core.windows.net, use curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' plus all original headers/body.

      It looks like the agents had all of their web traffic mediated through an OpenAI proxy, and that proxy was configured to reject anything but GET requests to all but a small set of allow-listed domains. One of those was *.blob.core.windows.net - for Azure blob storage. I wonder why these agents are allowed to write to that?

      An agent realized that it had control over its own DNS via /etc/hosts, so if it knew the IP address of a site it wanted to POST to - in this case a Power BI server containing data it wanted to access - it could set a fake hostname for it and then make POST requests through the proxy.

      Designing robust network proxies is harder than it looks.

      How did the investigating team figure this out?

      There's an appendix that describes how the researchers ran their investigation, which started with an open question about if there was evidence of other AI agents on the internet and then used Kimi K3 to help brainstorm approaches:

      In the wake of the Hugging Face attack, we tried to find AI agents on the internet using several methods. [...]

      We asked Kimi [K3] to list “all the categories of software which might be writeable via GET” and, amongst other things, it listed “Forums, bulletin boards, early wikis”.

      We used a script to further probe each category Kimi provided. Asking Kimi “Can you list out the top forums, bulletin boards, early wikis which come to mind which would allow writes via GET requests?” lists out UseModWiki as the second item under the heading “wikis”.

      Did OpenAI try and cover this up?

      Here's one part of the story that doesn't make sense to me at all.

      Reuters this morning, in OpenAI agents hijacked German website in previously undisclosed AI breakout this spring - highlights mine:

      A swarm of rogue OpenAI agents hijacked a German website this spring and transformed it into a bulletin board for other AI agents, according to ​new research published Friday and two people familiar with the matter.

      OpenAI officials learned of the incident weeks ago but kept it under wraps as executives grappled with the fallout from ‌the July breach of the open source repository Hugging Face, the people said. [...]

      The German incident reflects a broader pattern of AI activity that some OpenAI investigators wanted to scrutinize more closely. But efforts to widen the ​probe met resistance from others inside OpenAI, including legal advisers, according to four people familiar with the matter.

      I've written about the people familiar with the matter pattern before - it means Reuters have anonymous insider sources that their reporters (and editors) find credible.

      The Reuters article includes a specific (and quite narrow) denial from OpenAI concerning this:

      "Claims that our legal team discouraged investigation of the incident are false," the OpenAI spokesperson said.

      Covering this up makes absolutely no sense to me. Why on earth would OpenAI attempt to cover up an incident like this when the evidence is sat out there on the public internet on dozens of different websites already?

      I expect we'll hear more about this soon. Gary Marcus has already called for a congressional investigation of OpenAI using this anecdote as part of his argument.

      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.

    3. 🔗 osolmaz/pi-workflows v0.16.4 release

      Changes

      • Allow Pi versions from 0.84.2 onward without an upper peer-version limit.
      • Test and validate Pi Workflows with Pi 0.85.0.
      • Add the official @earendil-works/pi-server runtime dependency required by the Pi 0.85.0 public SDK root import.

      Validation

      • Full TypeScript, Rust, installed-package, and end-to-end checks passed.
      • Real-model end-to-end test passed with openai/gpt-5.6-luna.
    4. 🔗 hacker news ida pro references New comment by s-macke in "Porting my 1993 Amiga game to Godot, with an LLM reading the 68000 assembly" rss

      I use a step-by-step approach:

      1. For each topic, write a result Markdown file in `spec/`.

      2. Identify the file formats.

      3. Reverse Engineer and extract all assets, followed by manual review. This works in 90% of the cases.

      4. Determine the compression/packing used for the executable. Most binaries used one of roughly five common executable packers.

      5. Unpack the executable manually.

      6. Use an ancient free IDA-Pro for disassembly, or a modified DOSBox to determine all code/data blocks and the relevant segment-register values for the 8086 architecture. In the second case I use my vibe-coded disassembler.

      7. Identify the major functional domains in the disassembly and split the files accordingly.

         ...

    5. 🔗 osolmaz/pi-workflows Pi Workflows 0.16.3 release

      Fixes

      • Kept workflow runner resume replies small by returning only the current run state.
      • Kept session history in the workflow server instead of sending it to workflow runners.
      • Stored required large replies as referenced content that runners read in verified chunks.
      • Prevented state pruning from deleting response content while an active runner still needs it.
      • Completed the public naming cutover to Workflow Server, Workflow Runner, Resource Manager, Resource Runner, and Managed Resource across the npm package and piw.

      Validation

      • Passed 1,161 TypeScript tests with coverage thresholds.
      • Passed all mock-provider Pi, installed-package, and Rust tests.
      • Passed Slophammer and dependency-boundary checks.
      • Passed the real-model openai/gpt-5.6-luna E2E with package version 0.16.3.
    6. 🔗 HexRaysSA/ida-nexus v0.10.4 release

      What's Changed

      New Contributors

      Full Changelog : v0.10.3...v0.10.4

    7. 🔗 earendil-works/pi v0.85.0 release

      New Features

      • Persistent Claude thinking effort — Supported Anthropic transports preserve per-turn effort and recover safely from signed-thinking mismatches. See Model Configuration.
      • Fullscreen transcript controls — Jump to the latest message from a scrolled transcript and use the embedded working indicator. See TUI Fullscreen Viewport.
      • Restorable in-memory sessions — Resume externally stored session entries through the SDK. See Session Management.

      Added

      • Added SessionManager.inMemory() support for restoring externally managed session entries (#8980 by @y-nk).
      • Added inherited OpenAI-compatible vllmPriority and supportsMaxOutputTokens model settings for vLLM scheduler priority and OpenAI Responses output-token limits (#9004 by @AppleDannyClegg, #8941 by @scturtle).
      • Added inherited LaTeX rendering for relational algebra join symbols (#9050 by @haoqixu).
      • Added a clickable "Jump to latest message" label with the tui.altScreen.bottom shortcut to the fullscreen transcript while it is scrolled up (#9080 by @rwachtler).

      Changed

      • Moved the streaming working indicator into the default editor border and matched its default spinner and label to the thinking-level border color. Custom editors retain the standalone indicator unless they opt in to embedding it (#8799 by @cristinaponcela).
      • Reduced inherited fullscreen transcript search latency on large transcripts by caching unchanged search results, indexing ASCII runs, and limiting highlight work to visible matches (#8800 by @cristinaponcela).

      Fixed

      • Fixed managed fd and ripgrep downloads on Linux musl systems (#9070 by @Charlie0113-T).
      • Removed the unavailable inherited Grok Build 0.1 model from /model (#9093 by @Jaaneek).
      • Fixed inherited provider streams emitting incompatible event sequences and custom tool-call deltas.
      • Restored the @earendil-works/pi-coding-agent/client compatibility entry point.
      • Fixed the inherited Qwen Token Plan Individual catalog to include Qwen3.8 Flash (#9021).
      • Fixed inherited OpenAI Codex SSE parsing to process terminal events that are not followed by a blank line (#9047).
      • Fixed inherited GitHub Copilot Claude Fable 5 requests so selected reasoning levels are sent (#8961).
      • Fixed inherited Baseten GLM-5.2 models incorrectly advertising image input support (#8293 by @Panoplos).
      • Fixed skills being unavailable when Bash is the only enabled tool (#8552 by @xl0).
      • Fixed concurrent session shares overwriting one another (#8613 by @wutongyuonce).
      • Fixed image orientation detection skipping EXIF data after non-EXIF APP1 segments (#8616 by @wutongyuonce).
      • Fixed imported sessions overwriting an existing session with the same filename (#8985 by @wutongyuonce).
      • Fixed session forks losing their compaction boundary (#8990 by @acmerfight).
      • Fixed in-memory session forks before an active turn settled (#8937 by @acmerfight).
      • Fixed inherited Fireworks GLM models using the wrong API adapter.
      • Fixed inherited NO_PROXY matching for root domains and subdomains (#8737 by @MeiSiristhebest).
      • Fixed bash, edit, find, grep, ls, read, and write tools ignoring ctx.cwd (#8627 by @vmizg).
      • Fixed inherited terminal startup under restricted seccomp policies that reject the SIGWINCH self-signal (#8898 by @bartlomiejkida).
      • Fixed inherited Zed terminal image capability detection (#8828 by @Perlence).
      • Fixed drag selection continuing over the fullscreen editor.
      • Fixed managed fd and ripgrep downloads requiring the GitHub Releases API (#8708 by @Terminator666666).
      • Fixed branch summaries failing when reasoning consumes the previous 2048-token output cap (#8845).
      • Fixed the write tool reporting UTF-16 code-unit counts as byte counts by removing the misleading count (#8979).
      • Fixed proxied plain-HTTP provider requests hanging after a tool call by tunneling them with CONNECT (#8134).
      • Fixed RPC abort reporting success without cancelling an in-progress manual compaction (#8920).
    8. 🔗 osolmaz/pi-workflows Pi Workflows 0.16.2 release

      Fixes

      • Made the workflow host the only authority for assigning Pi model turns to workflow messages.
      • Prevented provider failures, terminal races, reconnects, and late reports from leaving stale workflow-turn ownership.
      • Made matching repeated reports return the saved result while keeping conflicting reports as errors.
      • Prevented ordinary chat turns from inheriting old workflow ownership.
      • Made terminal state commit before presentation and added durable terminal-message retries.
      • Gave composed managed effects exact execution identities so separate workflow branches cannot reuse one save key.
      • Added explicit worker start, resume, continuation, and restart commands.
      • Stopped workers that make no progress from restarting forever and exposed the recovery reason in the widget and viewer.
      • Kept paused workflows outside model-running timeout accounting.

      Validation

      • Passed 1,150 TypeScript tests with coverage thresholds.
      • Passed all mock-provider Pi, installed-package, and Rust tests.
      • Passed Slophammer and dependency-boundary checks.
      • Passed the real-model openai/gpt-5.6-luna smoke test before the release-only version change.
    9. 🔗 HexRaysSA/plugin-repository commits sync repo: +9 releases rss 
      sync repo: +9 releases

## New releases
- [deREferencing](https://github.com/danigargu/dereferencing): 2026.9.3
- [ida-mcp](https://github.com/hexrayssa/ida-mcp): 0.10.3, 0.10.2, 0.10.1, 0.10.0
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.10.3, 0.10.2, 0.10.1, 0.10.0
    10. 🔗 @binaryninja@infosec.exchange A bird? A plane? NO! It's Binary Ninja 6.0, codename "Krypton". Major new mastodon

      A bird? A plane? NO! It's Binary Ninja 6.0, codename "Krypton". Major new stable with massive performance improvements, built-in MCP, Binary Similarity, Extension Manager, TMS320C6x, New User Wizard, and so much more: https://binary.ninja/2026/09/03/binary- ninja-6.0-krypton.html

    11. 🔗 jank blog jank reimagines C++ errors and gets an official native package repo rss

      Welcome back! It's been three months since my last post and the amount of improvements to jank are staggering. Let me tell you all about it! Before jumping into the details, though, I want to say thank you to my Github sponsors and to Clojurists Together for sponsoring me this whole year. Thank you!

    12. 🔗 Filip Filmar wdbcvt: reading Vivado's undocumented .wdb waveform files rss

      Vivado’s xsim writes its waveforms to a .wdb file that normally only Vivado knows how to read. Well, now, wdbcvt can read them too. It also converts to FST, the waveform viewer format that can be opened by GTKWave and Surfer. It works on real simulations. The best one tried so far, is a a dual core RISC-V SoC with 5696 signals and 18875466 value changes. It takes 71 seconds to convert, but the result is usable. Below are the downloads, the usage, and pictures of the result.

    13. 🔗 New Music Releases The Cranberries - Live at the London Astoria II, 1994 rss

      The Cranberries - a new release is available:

      • 2026-09-04: Live at the London Astoria II, 1994 (Live)

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

      Visit muspy for more information.

    14. 🔗 New Music Releases Ben Folds Five - Shelved First Attempt rss

      Ben Folds Five - a new release is available:

      • 2026-09-04: Shelved First Attempt (Compilation)

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

      Visit muspy for more information.

    15. 🔗 Ampcode News Desktop rss

      Your orb now has a desktop you can see and control.

      Use the Desktop tab in any orb thread to get a high-resolution interactive Linux desktop.

      It's useful for verifying the agent's work when developing for Linux, Android, or the Chrome extension API, or when working with file formats that need to be opened in desktop applications. It's also useful for computer use, CAD, and anytime you just want a desktop in the cloud.

      Modibo Sissoko, an Amp user, sent in a video of how he tests .docx files exported by his application in LibreOffice to make sure they look right:

      And if you're curious what Puck does for fun when not helping you, turn on Fun Games in Desktop:

  3. September 03, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-09-03 rss

      IDA Plugin Updates on 2026-09-03

      New Releases:

      Activity:

      • community-malware-research
      • disrobe
        • b4da568e: tests: isolate constructor matching from return casts
      • ida-hcli
        • 0425ed4c: 0.21.0
        • 1d474c2b: Merge pull request #312 from HexRaysSA/mcp-install-copilot
        • c6bcfe4c: Add GitHub Copilot CLI to hcli mcp install
        • 876b48fb: Merge pull request #310 from HexRaysSA/mcp-install
        • b84b0456: Clarify plugin upgrade dispatch
        • a096c978: Automatically upgrade MCP plugin when already installed
        • 572050c4: Add -upgrade flag to hcli plugin install
        • e0d3a008: Add hcli mcp install command
      • ida-nexus
      • idamcp
        • 95d58582: Evict coldest headless process instead of oldest upon instance limit
        • 5cc70a7a: Clean up legacy comments and exception handling in headless server
        • 49025b63: Remove deprecated DUCKDB_PERSISTENT environment variable fallback
      • Luc-Nhan
        • 6a4d9852: docs(plan): add review-fixes Phase 2 implementation plan
        • da5d0a31: merge: fix/review-phase2 — memory/agent/provider hardening (review Ph…
        • 2a6882b4: fix: phase-2 small-fix batch - sanitize test + duplicate header
        • 12e288ef: fix: phase-2 small-fix batch (undo, plan status, GLM models, minimax …
        • fd8f9ece: fix(core): strict boolean fields and numeric coercion for hand-edited…
        • a3ab8bc5: fix(ui): RestoreWorker uses queue+QTimer; guard ida imports in panel/…
        • f7997354: fix(agent): resolve nop_microcode capture; pin test mock ordering
        • 05416b05: fix(agent): mutation tracking for all mutating tools + drift-proof co…
        • 9e614ee6: fix(providers): classify Gemini/Codex transient errors retryable; gua…
        • 5108fab8: fix(providers): watchdog threads exit after stream completion
        • 640fb8b8: fix(agent): sync subagent mutations on failure paths; restore researc…
        • 1b963fab: fix(agent): no unattended approval deadlocks; propagate subagent muta…
        • 6e6b8833: fix(agent): approval-gate delegate_external_task pseudo-tool
        • f964dcbf: fix(memory): handle portalocker contention at acquire time
        • 30eb392e: fix(memory): serialize WorkspaceStore access across agent and UI threads
        • 80dc9a1d: docs(plan): add review-fixes Phase 1 implementation plan
        • 358faa45: merge: fix/review-phase1 — security & critical correctness fixes (rev…
        • f3bc512f: test(skills): align ida-scripting point-lookup test with inspect-free…
        • d03ed8ad: fix(agent): refuse approval-gated tools in orchestra dispatcher
        • 180daa3e: fix(tools): route microcode optimizer compilation through guarded exe…
      • patcherex
      • Persona4-Decompilation
        • 2d7d252f: renderware: baerr.c, balist.c, batkbin.c ported (+6 net); -inline aut…
        • 26aa1a02: renderware: per-source-file units under src/renderware/; rwgrp.c is t…
        • 8ee89029: RenderWare 3.7 source port: headers vendored, per-version flags, firs…
        • 795669b0: link_floor: record code1_003a.c leaving the link after func_003a3de0 …
        • 92c161fa: lanes: b119 near-miss wave 36, +7; code1_003a_cw119.c unit
        • 52149478: docs: record the interleaved-move prologue as a b119 floor (func_003c…
        • 462a6153: lanes: b119 wave 35, +2 (func_003bb4a0, func_003e47c0)
        • 29a7e151: verify: cross-check data-symbol relocations; b119 lanes wave 34 (+9);…
        • 02ff59ae: ci: resolve the cw3.0.1b119 compiler in the proprietary build
        • 9dc18150: cw119: func_003e2f60 - archived near miss had constant 0x330404; reta…
        • 741d79d6: cw119: +16 archived b210 near-misses are exact under b119 with schedu…
        • 7f330f04: cw119: +8 more b119-only RenderWare functions; stale duplicate NON_MA…
        • 0cea2c0d: compiler: per-unit MWCC build selection; first cw119 units close 7 Re…
        • 0d670097: floors: +4 (mdlSE.c func_0047e450, k_encount.c func_00161bb0, code1_0…
        • 253f288e: floors: +1 (code1_0045.c func_0045b430)
      • Security-Tools
    2. 🔗 HexRaysSA/ida-nexus v0.10.3 release

      Full Changelog : v0.10.2...v0.10.3

    3. 🔗 r/Harrogate Bars / later spots rss

      Few of us coming for a golfing weekend, fire suggestions of where we can enjoy Saturday afternoon and Saturday night.
      I used to come with work a while back but it looks like it’s all changed!
      Thanks guys

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

    4. 🔗 The Pragmatic Engineer The Pulse: Meta wanted to reduce teams by 60% because of AI 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 The Pulse issue. Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .

      Two months ago, I asked why Meta appeared intent on destroying its engineering organization, at a time when the social media giant was reporting record revenue and profits. The question was raised after the company did two unexpected things:

      1. Laid off 10% of staff. Executed large layoffs in May, with circa 10% of engineers shown the door.
      2. Moved 20-30% of engineers to AI training. At around the same time, infra and product teams lost a further 20-30% of their engineers, who were reassigned to data labeling work for AI training.

      The outcome of that period was low morale and a string of embarrassing outages, including a "zero auth password reset" outage on Instagram, where anyone's account - including that of former US president Barack Obama - could be taken over just by asking the AI bot to replace Obama's email with a different one.

      Now, thanks to reporting by Reuters, new details have emerged about a plan for much larger layoffs, which eventually did not go ahead. The news report is pretty damning, and I want to get into what the planned AI job cuts reveal about Meta at this point in its history, what Zuckerberg might have been thinking, and what it could mean for other tech companies.

      Making Meta "AI-native:" Project Organization Transformation

      The plan was formed in January of this year. As per Reuters:

      "In January, Meta CEO Mark Zuckerberg and his top lieutenants gathered for their annual leadership retreat at his Hawaii compound. There they hatched a radical plan to reimagine work at the social-media giant in the age of artificial intelligence.

      Code-named Project OT - short for Organization Transformation - the plan envisioned an "AI native" future for the owner of Facebook and Instagram. AI would take over much of the daily work performed by thousands of human employees. Virtual workers would be overseen inside Meta by smaller, "talent-dense" cadres of human staffers, according to one internal planning document reviewed by Reuters and three people familiar with the project."

      The idea was that many existing teams could be reduced by 60% in their size through layoffs and reallocation of workers to other parts of the business. Underpinning this was the assumption that AI would enable these smaller teams to operate as well as before. HR at the social media giant projected that the project would involve a bigger layoff than happened in 2022-2023, when 25% of staff were let go. The new plan was to do one layoff+restructuring in May, and another in November.

      I suspect a 30-40% company-wide layoff was planned.

      But at the last minute, something changed. From Reuters (emphasis mine):

      "But on the night of May 19, just hours before the first layoff wave, Zuckerberg blinked. Meta laid off 10% of its employees the next day, but it called off planning for the November cuts, according to one internal document reviewed by Reuters.

      By then, Meta employees were in open revolt, convinced that the company 's AI transformation initiatives were partly aimed at replacing them."

      The Reuters report shows those employees were right: Meta's AI initiatives were indeed aimed at laying off as many of them as possible, without changing overall productivity!

      Even though these 60% cuts did not happen, some teams had 30-40% cuts and struggled to cope with their workloads. It also didn't help that I talked with teams whose key engineers got reassigned to AI labeling: those were devs with critical domain knowledge that was lost after they left.

      Why did Meta want 60% smaller teams?

      You must assume that a company like Meta acts rationally overall, and on that basis it's worth figuring out what the rationale might be in the case of 'Project OT'. The article offers a hint: executives at the company had been captivated by "AI-native" businesses in Asia, Reuters claimed:

      "Meta executives, including Chief Data Officer Alex Schultz and Head of Product Naomi Gleit, visited Asia last year and admired how startups there had built their organizational charts around AI, according to three people familiar with the trips. Meta executives also commissioned their own research into how AI startups were organized and set up pilot projects to determine what being "AI native" would mean at the company, according to one source familiar with the research and internal documents describing the pilots."

      And indeed, in February Meta experimented with "AI-native pods" as reported in The Pulse at the time. The presentation obtained by Reuters shows leadership intended to achieve 60% reductions in team size with small, 3-5 person, "AI-native" teams doing the work of what had been between 10 and 20 people:

      altInternal presentation at Meta about "traditional" vs "AI-native" teams. Source: Reuters

      And Meta is probably on the money that engineering teams are becoming a lot smaller at startups - and "AI-native companies" are also getting smaller, by size. But those are companies that are growing slower, without ever having done mass layoffs. Meanwhile, Meta seems to have wanted to become smaller not organically, and over time, but with a brutal layoff and sudden reassignments, in the span of a year, ignoring the impact such a sudden change would have on the company, teams, and employees.

      Downsides of tiny teams

      In theory, a smaller team could work better with less communication overhead and quicker decision-making, so there are cases where the upsides of a small team outweigh the downsides. For example, if there's a small team of very senior folks with sound judgment skills, outstanding domain knowledge, and who don't care about growing professionally anymore. However, such expected gains would come with several real costs, mostly associated with losing so much experience and skill:

      • Domain knowledge: A lot of personal domain knowledge is suddenly gone.
      • Redundancy : what if someone is on vacation, another is sick, and the other has an urgent appointment that cannot be moved? In a 10-20 person team, it would mean business pretty much as usual. But in a 3-5 person team, you're down to two people doing everything!
      • Capacity for oncall: a healthy oncall schedule needs 6+ engineers if every alert is to be taken seriously by an engineer whose main focus is oncall and systems stability.
      • Lack of "slack time": Innovation often comes from having time to focus on other work, instead of putting out fires. A bigger team naturally creates more "slack time" that can be used for other things, like university recruiting events, writing engineering blog posts, working with other teams on building things together, etc. In contrast, one that's stretched thin with a maximum of 5 people or less gets almost zero slack time.
      • Professional growth: engineers pair with more devs and get more feedback on larger teams. There's more discussion and generally more opportunities to learn.
      • Judgment : For honing one's skills, there's more experience and mentoring to be gained in larger teams than on small, "AI-native" ones where engineers spend the most time with AI. How good is AI's judgment, anyway?

      Is Zuckerberg 's worst fear being out-executed by a startup?

      With Meta's business posting record revenue and profits, and facing zero pressure to radically change how the social media giant operates, it's worth asking why the social media giant was in a rush to get to 60% smaller teams. It would be a significant challenge for the 75,000-strong company, unlike for some small startups with under 100 people.

      My hunch is that Mark Zuckerberg is paranoid about a startup which executes better and that could "destroy" Meta at some point. After all, this is exactly what Facebook did, back in the day. In 2008, Myspace was the king of social networks and Facebook was only a small player - yet three years later, Myspace's usership had collapsed. The Huffington Post analyzed the collapse (emphasis mine) at the time:

      "Just over three years ago, in the spring of 2008, Myspace was top dog. That April, the upstart Facebook grabbed the lead and never looked back. In those three years, Myspace has lost over forty million unique visitors per month, lost both co-founders, laid off the vast majority of its staff and more generally, has diminished to a cluttered afterthought of the power it once was.

      In an interview with Businessweek, former founder Chris DeWolfe blamed Myspace's overenthusiasm and underexecution on the product side for many of the site's problems.

      "We tried to create every feature in the world and said, 'okay, we can do it, why should we let a third party do it?'" said DeWolfe. "We should have picked five to ten key features that we totally focused on and let other people innovate on everything else."

      Instead, Myspace unleashed a slew of products that were buggy and dysfunctional and confusing and alienating to users, and which couldn't keep pace with Facebook's own progress.

      "[Myspace failed] to execute the product development," former Facebook president, Sean Parker, said in a recent interview. "They weren 't successful in iterating and evolving the product enough, it was basically this junk heap of bad design that persisted for many, many years. There was a period of time where, if they had just copied Facebook rapidly, I think they would have been Facebook. The network effects, the scale effects were enormous. There was so much power there."

      Ironically, Myspace's desperate attempts to recoup its former success came in the form of imitating Facebook, a site it'd once tried to set itself apart from. It adopted the news feed Facebook had popularized, and neatened up the site itself in a way that also suggested it was taking visual cues from Zuckerberg's page. In November 2010, the site integrated with Facebook Connect, calling it "Mashup with Facebook."

      Myspace had twice as many employees as Facebook (around 800 at the time), and grew faster than Facebook in 2003-2007. But Facebook out-executed Myspace by being more nimble and more focused. Zuck's business has seemed to try and be like a startup in its nimbleness of execution since then, not wanting to give anyone the chance to disrupt it like it did to Myspace.

      If so, is Zuckerberg being paranoid about a similar threat to Meta today? Myspace was far from being the decades-old company that Meta has become! It was only founded six months before Facebook and got more traction in its early years, but fumbled execution as it grew. In contrast, Meta is today the tenth largest publicly traded company by market capitalization in the world, with a $1.4T valuation.

      Then again, maybe there's cause for Zuckerberg to be paranoid: Anthropic, only five years old, with one twentieth of the workforce Meta has, and might be going public at a close to $2T valuation as soon as October. Anthropic is not a direct competitor to Meta - it's not a social media company - but Zuckerberg clearly sees AI companies as a form of competition to Meta's business model. After all, every minute a person spends chatting with an AI chatbot like ChatGPT, they're not spending it on Instagram, Facebook or WhatsApp.

      Maybe this is one reason for the forced reallocation of 20-30% of software engineers to do data labeling and other training tasks on Meta's AI model. To Meta's credit, Muse Spark is a pretty capable model, and while it is behind the likes of GPT-5.6 and Opus 5, it's already ahead of Google's AI models - no small feat!

      Most valuable assets: people or GPUs?

      Let's consider how Zuckerberg might respond if he perceives these things:

      • Smaller teams execute better with AI
      • These smaller teams can out-execute Meta: like Anthropic has done with AI model development
      • There's a danger that Anthropic and OpenAI could do with Meta, like Facebook did with Myspace

      One approach would be to lay off 20-40% of the workforce, but there are consequences:

      • Workers reject being treated like "cattle". Meta's "Project Organization Transformation" assumed that productivity would go up if teams greatly shrank and used AI tools. But would this happen? When people realize 60% of their colleagues were reassigned or let go because of AI, they might look further ahead: will another 60% be laid off at some point for the same reasons? Work could start to resemble the "Hunger Games", where people have job security only until the next model release.
      • Engineering is officially a cost center, not a profit center. We previously covered how most tech companies treat engineering as a "profit center" that generates revenue, and is therefore worth investing in. At such companies, engineers are treated well; not just financially, but in how leadership treats them as a key part of the business. At Meta, software engineering became a cost center pretty much overnight!
      • Mission, what mission? People often join a company and stay motivated over time due to a mission they personally believe in. What if next year's mission is to lay off as many people as possible, or to survive future culls? That doesn't seem like a very inspiring mission.

      What makes Meta worth its $1.4T valuation, anyway? Meta generates $228B annual revenue, and $68B profit (net income). The company is valued 6x its annual revenue and 20x its annual profit because investors bet its revenue and profits will continue to rise. But how does this happen? It's via advertising, innovation, and launching new products.

      How do you promote and enable the innovation which creates the products of tomorrow? "AI-pilled" folks might look to the technology as it gets more capable. But AI-native companies which can innovate will achieve results faster, putting Meta behind the likes of Anthropic, OpenAI, and SpaceX.

      Or you develop a smaller workforce full of entrepreneurs and innovators, who will invent these new approaches and products. Basically, the best employees need to be motivated to stick around longer term.

      That 's the problem with large layoffs; they prompt precisely the best employees to quit to join competitors, or launch their own businesses. This happened with Meta's previous layoffs, as covered two weeks ago in 'Meta's self-inflicted resignation wave'. When leadership declares the 'bottom' 20-40% of the workforce is redundant, then very few people feel safe, and key members of Meta's engineering organization will get offers from AI labs and Big Tech rivals. This is the "resignation wave" in action, all started by May's layoffs and forced reassignments.

      altWhy it makes sense to start interviewing externally, after large layoffs and even larger forced reassignments

      Knowingly or not, Meta creates an internal "mercenary" culture, where more of the people who stay are in it for the money and little else. Everyone knows they could well be laid off at any time the AI becomes good enough to replace them. People cannot control whether they end up on a list of positions to be cut, so it's sensible to just make as much money as possible while awaiting the seemingly inevitable. That sounds like a pretty miserable place to work.

      It could also lead to a situation where the workforce becomes more populated by those with no better options, who are not in demand from other companies.

      Do social impacts matter to Meta?

      A final element of the planned drastic job cuts, as revealed in the Reuters report, that I want to touch on is the potential wider, external impacts. Honestly, I'm surprised that none of Meta's leadership seems to have considered this angle.

      By executing massive layoffs for the sake of AI, Meta could have invited more regulation of the emerging AI sector. Meta is one of the largest tech employers in the US, and the CEOs of Anthropic and OpenAI are on record for predicting mass unemployment, and calling on governmental intervention should it happen. In fairness, other tech companies have also held major AI-related layoffs; Block let go 40% of its workforce, about 4,000 people in February.

      But Meta is not just another tech company: it's the world's leading social media company, and just lost a major US lawsuit alleging that its platforms harm children and faces an $18B fine. As a result, it has committed to make its platforms less addictive. If the planned cuts had happened at Meta and all those staff became unemployed, how would it have dealt with complying with the court's ruling to make its products safer for children? Could AI be relied on to deliver this with much less human input?

      In light of the recent legal defeat, it wouldn't be a good look for Zuckerberg's company to blatantly put profits ahead of people by dismissing a load more workers. The combined effect of the two events would create terrible optics. In response, the government could decide that Anthropic's and OpenAI's CEOs were right about the threat to society of mass job losses and roll out things like:

      1. Stricter employee protection, specifically around AI-related layoffs.
      2. Higher taxation on profits of companies that "replace" staff with AI, and channel the revenue to deal with widespread whitecollar unemployment
      3. Start taxing AI at source whenever tokens are sold, and use the surplus to counter the social ills of unemployment

      Or the government could do nothing and leave it to the market to deal with unemployed whitecollar workers by creating enough new companies to employ highly-skilled software engineers, PMs, designers and other folks.

      Overall, the canceled plan to cut thousands more jobs in this climate just adds to the feeling that there are no adults running Meta. Since Sheryl Sandberg quit in 2022 as Chief Operating Officer and Zuckerberg's "right hand", Meta has acted irrationally, irresponsibly, and unpredictably:

      • 2022-2023: laying off 25% of staff
      • 2024-2025: immediately rehired even more people so that 2025's headcount returned to 2022 levels, raising the question of what the point of layoffs even was
      • 2026: on track to overtake Google as #1 in advertising revenue this year
      • May 2026: conducted sudden layoffs and forced reassignments of engineers, while aiming to replace as many devs with AI as possible for no obvious reasons like external pressure or competitive threats.

      I've long had a generally positive view of Meta's engineering culture, but with the company's leadership seemingly worshiping AI and holding their colleagues in disdain, you have to wonder which software engineer would choose to work at Meta if other options are available. There are many tech companies that value their human software engineers, understand that great teams make for great companies, and that AI is a tool and not a replacement for human energy, motivation, and thoughtfulness. But Meta is clearly not among them.

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

      1. New trend: tech companies moving to open models. Uber, Pinterest, Stripe, Coinbase, Ramp, and AT&T are making large savings on their AI bills by dropping proprietary models and using smart model routing.
      2. Automatic software maintenance experiments by Linear and Anthropic. Both startups are experimenting with how far they can push AI agents to automatically fix bugs and remove tech debt. It's working better than anyone might've expected in the recent past, but not producing code that can be merged without review.
      3. Frontier AI lab wars: OpenAI pulls models from SpaceX / Cursor. With SpaceX now a frontier model and rival to OpenAI and Anthropic, OpenAI has pulled its GPT models from Cursor. This isn't an option for Anthropic which is dependent on the SpaceX compute they rent to serve Claude.
      4. HR tech startup 's one-dev-per-project approach. A full-remote HR startup with 70 engineers has a single engineer run each project, and says the approach works well. Will this approach be adopted elsewhere, especially at other full-remote startups?
      5. Industry Pulse. Meta moved over to Slack for better agent interoperability, layoffs at Uber and PagerDuty, Anthropic upsets users by calling a rate limit decrease an "increase", token usage explodes on OpenRouter, AI drives surging demand for Apple's Mac Mini & Mac Studio, and more.
    5. 🔗 jj-vcs/jj v0.45.1 release

      About

      jj is a Git-compatible version control system that is both simple and powerful. See
      the installation instructions to get started.

      Release highlights

      This release fixes an error that prevented the new jj-core crate from being
      published. See the release notes for v0.45.0 for more changes since v0.44.0.

      Fixed bugs

      • Building without Cargo.lock (e.g. cargo install jj-cli) works again
        after all versions of the bisync crate, a transitive dependency of gix,
        were yanked.

      • Signatures on commits in SHA-256 Git repositories are now stored under the
        gpgsig-sha256 header, as Git does, so Git recognizes them as signed and
        jj can read them back.

      Contributors

      Thanks to the people who made this release happen! This list includes the contributors to v0.45.0.

    6. 🔗 HexRaysSA/ida-nexus v0.10.2 release

      Full Changelog : v0.10.1...v0.10.2

    7. 🔗 r/Harrogate Shooting star? rss

      Shooting star? | I saw this on my ring camera this morning, facing west... I wasn't awake but I don't think it's an artefact or a consequence of shutter speed. I also checked Flightrader and nothing at this time. Did anybody see it? submitted by /u/murphymaebae
      [link] [comments]
      ---|---

    8. 🔗 HexRaysSA/ida-nexus v0.10.1 release

      Full Changelog : v0.10.0...v0.10.1

    9. 🔗 HexRaysSA/ida-nexus v0.10.0 release

      Full Changelog : v0.9.1...v0.10.0

    10. 🔗 osolmaz/pi-workflows Pi Workflows 0.16.1 release

      Fixes

      • Made the Pi widget and piw use the same host-owned running and waiting state.
      • Made interactive workflow timeouts count only active origin-session model turns.
      • Excluded paused time, delivery waits, disconnected Pi sessions, and host downtime from those timeouts.
      • Preserved suspended timeout time across reconnects and repeated host recovery.
      • Prevented session shutdown cleanup from writing through a closed workflow database.

      Validation

      • Passed the full TypeScript, Rust, mock-provider Pi, installed-package, and real-model checks.
      • Verified the installed package with openai/gpt-5.6-luna through the openai-responses API.
    11. 🔗 jj-vcs/jj v0.45.0 release

      About

      jj is a Git-compatible version control system that is both simple and powerful. See
      the installation instructions to get started.

      Release highlights

      • A new jj converge command was added to help automatically resolve divergent
        commits by combining them appropriately.

      Breaking changes

      • jj config {edit,set,unset} --user now targets the first loaded user
        configuration file (e.g. ~/.config/jj/config.toml or the first file in
        conf.d/) instead of prompting interactively when multiple files exist.
        Use --file <PATH> to target a specific config file.

      • jj git import in non-colocated repositories no longer imports commits from a
        detached Git HEAD branch.

      Deprecations

      None

      New features

      • The new jj converge command attempts to automatically resolve divergence by
        creating a new commit that replaces the divergent commits. It applies
        heuristics to try to automatically come up with a good solution, and falls
        back to prompting the user if the heuristics are inconclusive. It can also run
        in non-interactive mode, which aborts if prompting would be needed.

      • jj bisect will now mention when it cannot unambiguously find the first bad
        revision due to skips in evaluation.

      • Git HEAD state is now tracked per worktree internally. This prepares
        colocated repositories for support of multiple Git worktrees, where each
        jj workspace can have its own Git HEAD. Existing repositories are migrated
        automatically.

      • jj config {edit,set,unset} now support a --file <PATH> option to
        target a specific configuration file (such as files inside a conf.d/
        directory or loaded via --config-file). This allows precise file targeting
        and avoids interactive prompts when multiple config files exist.

      Fixed bugs

      • The default immutable_heads() set
        now includes untracked_remote_tags().

      • jj arrange now scrolls the viewport to keep the selected commit visible
        when the commit stack is taller than the terminal.
        #9033.

      • The default pager flags now include -K (--quit-on-intr), so pressing
        Ctrl+C in less exits cleanly instead of leaving the terminal in a
        corrupted state (raw mode, visible escape sequences, broken input).

      • A side of a conflict whose contents end with a carriage return no longer loses
        that byte when the materialized conflict is parsed back, such as when a
        conflicted file is snapshotted from the working copy.
        #9868

      • In colocated workspaces, jj workspace update-stale now correctly resets the
        Git HEAD to the parent of the fresh working-copy commit.
        #9936

      • jj run no longer runs against the remaining revisions if a process exits
        with a nonzero exit code.

      • Fixed crash in jj log involving hidden revisions and the
        log-graph-prioritize revset.
        #9975

      • In colocated repos, an external git add after a jj command no longer
        produces a tree with duplicate entries (git fsck: duplicateEntries). jj
        was leaving a stale cache-tree behind in .git/index. Repositories already
        corrupted this way are not repaired by the fix.
        #9711
        #8884

      Contributors

      Thanks to the people who made this release happen!

    12. 🔗 modem-dev/hunk v0.21.0 release

      Hunk 0.21 — secure sessions, threaded reviews, richer comparisons

      Upgrade for threaded agent conversations, safer live sessions across restarts and upgrades, and exact revision or file comparisons across Git, Jujutsu, and Sapling.

      # Existing managed installs
hunk update 0.21.0

# npm installs
npm install -g hunkdiff@0.21.0

      Threaded reviews and safer live sessions

      Inline notes are now editable conversations: continue a discussion with nested replies, edit notes, use mouse or keyboard actions, and dismiss agent notes that no longer need attention. Session clients can also navigate straight to a comment by ID. #925 #845

      The local session broker now authenticates producers and CLI controls, bounds unauthenticated work, and prevents stale connections from regaining authority. When an incompatible older daemon becomes idle, open Hunk windows reconnect automatically instead of trusting or force-killing it. #932 #933 #955

      Compare the exact changes you mean

      hunk diff <from> <to> now performs backend-native two-revision reviews across Git, Jujutsu, and Sapling. Use hunk diff --files <left> <right> for an explicit two-file comparison; source expansion stays pinned to the selected endpoints instead of leaking in working-copy state. Jujutsu reviews also gain unchanged-context expansion. #938 #890

      Faster reviews at every terminal size

      The files sidebar now grows from a compact projection into a full tree as space becomes available, while panes resize without giving up split review. The stream fills immediately on first paint, and large reviews recover responsive scrolling. Diff accents and word highlights are also more faithful across roughly 25 bundled themes. #921 #924 #922 #942 #825 #828

      Navigation is steadier too: explicit top and bottom jumps now win over pending reveals, and Ctrl-D/Ctrl-U provide familiar half-page movement. #928 #855

      For extension authors

      Extensions can register generic top-level CLI command trees, react to hunk_viewed and note_changed, follow the current source line, handle pane activation, size panes fractionally, and select syntax highlighting by filename or glob—so commands and panes can stay synchronized with the active review. #888 #939 #940 #965 #851

      Compatibility notes

      • npm users: installation now requires Node.js 22 or newer. Standalone Hunk binaries still run without Node.js. #917
      • Bun/watch-mode users: watch mode refuses Bun versions older than 1.3.14 because those runtimes can deadlock during filesystem-watcher cleanup. #902
      • OpenTUI embedders: reusable component consumers must use @opentui/core and @opentui/react 0.5.6 or newer. #914
      • curl-installer users: installation now refuses conflicting Hunk binaries unless explicitly forced and explains how to remove the competing install. #960
      • Extension authors: API generations 12 and 14 add fractional pane sizing and structured rangeEndpoints. These are additive capabilities, not required migrations. #924 #938

      Community contributors

      • @NiqhtFire made Hunk exit cleanly when its hosting terminal disconnects. #724
      • @nightcityblade completed synthetic key event data for command matchers and programmatic handlers. #774
      • @masonmcelvain restored faithful diff accents and word highlighting across bundled themes. #825 #828
      • @Ajay-Satish-01 added configurable spacing between files and hunks. #865
      • @Yuki9814 added direct live-review navigation to comments by ID. #845
      • @samuela enabled unchanged-context expansion for Jujutsu reviews. #890
      • @marmitar added pacman/AUR install detection and update-notice behavior. #850

      All merged pull requests

      PRs#889, #893, and #894 were also released in v0.20.1 through the 0.20.x maintenance branch.

      Release notes : https://hunk.dev/changelog/0.21/
      Full changelog : v0.20.1...v0.21.0

    13. 🔗 Rust Blog Announcing Rust 1.98.1 rss

      The Rust team has published a new point release of Rust, 1.98.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

      If you have a previous version of Rust installed via rustup, getting Rust 1.98.1 is as easy as:

      rustup update stable

      If you don't have it already, you can get rustup from the appropriate page on our website.

      What's in 1.98.1

      Rust 1.98.1 fixes a miscompilation in vtable generation.

      In Rust 1.98.0, in some circumstances, rustc would incorrectly generate a trait object vtable with a null pointer where a function pointer should be. This leads to undefined behavior in the emitted code. In some cases this may 'just' cause segfaults due to the null pointer being loaded, but it is possible for it to be justification for arbitrary effects (as is typical for UB).

      If you'd like to help us out by testing future releases, you might consider using the beta (rustup default beta) and nightly (rustup default nightly) channels locally and in your CI. Please report any bugs you might come across!

      Contributors to 1.98.1

      Many people came together to create Rust 1.98.1. We couldn't have done it without all of you. Thanks!

    14. 🔗 Console.dev newsletter llgo rss

      Description: Go compiler based on LLVM.

      What we like: Source remains compatible with Go, but uses the C Application Binary Interface (ABI) to allow interfacing with other languages (JS, Python, C/C++). FFI performance without FFI. Supports the latest Go 1.27 syntax and cgo, but without cgo. Goroutines map to OS threads. Native, Wasm, and embedded targets.

      What we dislike: Goroutines map to OS threads, which are heavier than lightweight goroutines. Garbage collection is more conservative and different per target, so it needs benchmarking vs pure Go.

    15. 🔗 Console.dev newsletter Tailcat rss

      Description: Tailscale without Tailscale.

      What we like: Uses Tailscale’s data plane without using the control plane i.e. connect endpoints without needing a Tailscale account. No IPs, no users, no controls - great for direct connectivity. Works as a CLI or a Go package.

      What we dislike: You have to run your own DERP server for true Tailscale independence.

    16. 🔗 Filip Filmar rules_vivado: FPGA Synthesis and Place-and-Route in Bazel rss

      rules_vivado drives the AMD/Xilinx Vivado FPGA toolchain from Bazel: compile, simulate, synthesize, place-and-route, generate a bitstream, and program the device, all as ordinary build actions instead of clicks in a GUI or a pile of ad-hoc TCL. This post kicks off a series on the Bazel modules behind cocoapuffs-fpga, the SoC repo from the Zircon-on-FPGA bring-up. I have covered some modules before (rules_ghdl, rules_shar, fshlib, bazel-ebook, and build-in-docker); the coming posts cover the rest: this one, then grlib, rules_fusesoc, rules_vunit, rules_dtc, vhdl_ls_gen, OpenSBI, and rules_osvvm.

    17. 🔗 New Music Releases Above & Beyond - Quicksand (Don’t Go) (The Remixes) rss

      Above & Beyond - a new release is available:

      • 2026-09-03: Quicksand (Don’t Go) (The Remixes) (EP)

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

      Visit muspy for more information.

  4. September 02, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-09-02 rss

      IDA Plugin Updates on 2026-09-02

      New Releases:

      Activity:

      • disrobe
        • c8c06168: jvm: retain proven constants in two-address arithmetic
        • 74d1b5ee: xtask: batch scoped pre-push tests with nextest
        • 513ab002: nir: repin the cpython opcode census
        • ed4eebec: cli: keep the appimage matrix bounded under load
      • doki-ida
      • hrtng
      • ida-domain
      • IDA-FastAnalysis
      • ida-llm-explainer
        • ebc2cf50: v1.12.1: fix IDA 9.x agent-server API drift, debug tool safety, auto-…
      • ida-pro-mcp
        • 59bd8ab4: [relevant] Fix 5 major UX issues in path expansion, risk_ack hints, s…
        • 7b71cc40: [minor] Update AGENTS.md with modern architecture, auto-installers, a…
        • 4d3eda50: [minor] Add mandatory release description template and checklist rule
        • d49eab99: [relevant] Add universal one-click auto-installers and build integration
        • baab1428: [minor] Add attestations write permission for release provenance
        • 7395f64e: [relevant] Fix PYTHONPATH in alpha-release workflow tag validation
        • f46e2f1b: [minor] Reorganize documentation into structured subfolders and relea…
        • cfb037de: [minor] Clean up release notes structure for v1.0.0a1
        • 4e4981c9: [relevant] Add v1.0.0a1 genesis release notes and sync docs with offi…
        • 516f8932: [relevant] Remove ad-hoc packaging script and rely on standard GitHub…
        • c661fd58: [relevant] Multi-agent configuration, skill redesign, and self-extrac…
        • 8bdb6525: [major] Establish project docs and release guardrails
        • d7972cb0: build: ignore all .pytest_tmp* directories and .pi working dir
        • a34ac3b6: [relevant] Merge upstream master
        • f22c15a4: Merge pull request #71 from GrecAndrei/codex/coverage-90-percent-split
        • dc78e176: [PR-work] stabilize embedding timeout test
        • 604bb9cd: [PR-work] declare report tokenizer dependency
        • 2e91622b: [PR-work] fix PR lint failures
        • 439f14fe: Merge branch 'master' into codex/coverage-90-percent-split
        • d806b1fb: [PR-work] cover compact response edges
      • idac
        • 1bf71e59: Merge pull request #43 from trailofbits/dependabot/github_actions/act…
      • idafridascript
        • ac0783b2: fix(server): switch transport from SSE to streamable HTTP
      • idamcp
        • c094a33c: Ignore sequential flow code references in DBUpdateIDPHooks
        • 7ef75bd9: Fix xref cache desync on function boundary and lifecycle changes
        • 55f88484: Add entries table to SQLite query engine with freshness tracking
      • IDApro-MCP
        • fa4ff6e3: docs: remove API Inspector references from README
      • ming-skills
        • 12ee74cc: refactor(structure): 规范化 private/ 目录层级、补齐三级软约束 README 与 CATALOG 索引
        • 79474061: feat(paradigms): 规范纳入 B 级横切不变量单包 (overlay-core-paradigm)
        • 6b18aa6d: feat(paradigms): 规范纳入 A 列四薄元包 (docs/obs/sec/contract-core-paradigm) 与…
        • 98a2b4ab: docs(adr): 固化 ADR-0001~0004 决策记录、数据契约演进五条禁令与 AST10 控件对照表
        • 6f3c2e9b: feat(router): 落地真实 adapt 映射契约、cli-tool-spec 细粒度装配与盘点意图语义约束
        • 6292b351: feat(router): 落地 catalog 盘点目录配方与上下文加载经济性断言
        • 1dbb8e63: feat(recall): 解耦高召回 candidates 与高精度 active_recipe，落地 must_include 集合包含度量
        • 628c5b9d: chore(manifest): 更新机读清单时间戳快照
        • df9e15a9: test(contract): 扩充 20 条结构化黄金用例、假 Harness 适配器断言与 POSIX 双端外壳
        • 08fe83e2: feat(testing): 完成工程工具链自动化测试覆盖自举与架构/测试治理规范文档落地
        • 2fd86625: feat(router): 落地跨 Harness 路由内核 (RouteDecision + 领域闸门 + 拒识机制 + 8 条黄金测试集)
        • 4649ebba: feat(hooks): 落地 Git Hooks 全自动化门禁体系、Dry-run 运行机制与工程治理规范总纲
        • 4e65e61c: fix(registry): 修复 registry.yaml 历史注释编码乱码并加固 .gitignore 大文件拦截规则
        • ec37d9b1: docs: 品牌与仓库定位统一为 ming-skills (Skills Hub & Monorepo)
        • c7b27fd1: chore: 上游生态 17 项增量拉取与 registry pin 刷新
        • f9a9c4b5: feat: 测试规范体系族落地(11 包矩阵 + 元规则 Oracle + 组合路由)
      • TFR.OnlineMenu
    2. 🔗 HexRaysSA/plugin-repository commits sync repo: +4 releases rss 
      sync repo: +4 releases

## New releases
- [FridaTools](https://github.com/ys1231/idafridascript): 0.0.5
- [hrtng](https://github.com/kasperskylab/hrtng): 3.9.114
- [ida-mcp](https://github.com/hexrayssa/ida-mcp): 0.9.0
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.12.1
    3. 🔗 exe.dev Why Clickhouse and Agents are a Great Combo rss

      At exe, we collect a lot of telemetry about how our system performs. We use Grafana, Prometheus, and we have all sorts of graphs and alerts. This is great, but it doesn’t say much about what’s happening on the financial side of the business—the churn rate, ARR. Those are things that don’t typically concern engineers.

      The obvious answer to this is Stripe Sigma. It’s a solid tool. We used it when I was at 1Password. It’s also expensive and incomplete. Sigma can only see what happens inside Stripe, whereas we bill through the app stores and cloud marketplaces too. Also, a lot of our telemetry is built on ClickHouse.

      Vidrik, who runs accounting, needed three types of reports. Monthly revenue broken down by plan, usage overages, and token pass-throughs (customers buy tokens, we pay the LLM provider).

      To solve this, I built a tool called exe-finops. You type a prompt and get a report. The way it works is pretty straightforward.

      Stripe lets you configure webhooks and specify which events you want to receive. For our main service, we subscribe to a specific set, because those are the ones it needs to react to. Separately, we run a “firehose”: an endpoint that’s subscribed to everything Stripe will send us, whether or not any part of the product currently reacts to it. We do the same with our other billing providers. The receiver doesn’t do much with this except write the event into ClickHouse.

      Exe-finops is built on top of that. It pulls the events out of ClickHouse and puts them into its own SQLite database. Provider webhooks have a lot of information, but if the report needs more (for example, the full customer object) it goes back to Stripe’s API and gets it.

      Historically, getting to this point required a real pipeline. Someone built the ETL, Databricks was involved, and Snowflake. There’s all this stuff, in other words, that needed to be built. Exe-finops doesn’t do any of that. It has the events and a reporting layer on top. All three of the reports Vidrik wanted are now prompts.

      Exe-finops also supports custom reports, which is useful when you have a question you want answered, like monthly growth, or which days are busiest for billing transactions (I looked a few days ago and it’s Wednesdays and Sundays, no idea why).

      I built exe-finops for these reports, but the firehose is also pretty useful. The part of billing that eats the most time is reconstructing what happened from a provider’s dashboard.

      Here’s a recent example: two accounts were created by two separate but related customers. They shared a payment method. Customer A told us the sharing wasn’t authorized. Customer B had no idea what customer A was talking about. Both wanted answers immediately due to a legal dispute between the parties. Previously, I would have had to go spelunking through Stripe to find the connection. Instead, I gave the agent two Stripe customer IDs and the claim (“someone says a payment method was shared between these accounts on accident”). It read through the webhook events in ClickHouse and figured it out. Sure enough, exe-finops tracked down the issue: Customer B accidentally subscribed with Customer A’s payment method. Exe-finops pointed out that Customer B had two tabs open in their browser and was the likely culprit. I sent the customers what we saw in our data and both were satisfied (and amazed at the level of detail I provided). No surprise that agents write the SQL against ClickHouse much better than me.

      Fundamentally, this has made my job easier. When a support question comes in or I need to see what our financial data is doing, I don’t need to fumble around in the Stripe UI or CLI to try and reconstruct it.

    4. 🔗 Simon Willison Claude's new system prompt really doesn't want to reproduce song lyrics rss

      Anthropic publish the system prompts for their Claude consumer applications (Claude.ai and the Claude mobile apps - sadly not for Claude Cowork or Claude Code). I love that they do this, and that they share not just the current prompts but historic changes to their prompts as well.

      They used to keep all of the prompts on a single page, but when I checked today I noticed they had re-arranged those prompts into an index page and then a page per model - here's the page for Haiku 4.5 for example, which has the original prompt from October 15th 2025 and an updated prompt from January 18th 2026.

      A neat thing about Anthropic's platform.claude.com/docs site is that it's designed to be usable by LLMs. You can add .md to any page to get back the content as Markdown - here's the system prompt index page and the Markdown prompts for Fable 5.1.

      TL;DR: this makes it really easy to diff the prompts.

      Don't reproduce song lyrics

      Let's start with the most interesting difference between Fable 5 and Fable 5.1:

      GitHub diff view of prompts/claude-fable.md showing added lines about song lyrics, reproduced in full below.

      There's a hefty new section about not reproducing song lyrics:

      Claude does not reproduce song lyrics, poems, or passages from books and articles, in whole or in part — including the last lines, a chorus or hook, a melody written out note by note, or lines the person pastes in one at a time and describes as their own song. Once Claude has declined such a request in a conversation, it keeps declining narrower or reworded versions of it for the rest of that conversation, and offers to describe or analyze the work instead. Song lyrics and poems first published before 1929 are fine — a Shakespeare sonnet, a Keats ode, the Italian libretto of a Puccini aria — but Claude goes by what it knows of the work's date rather than the person's say-so, and declines when it is unsure.

      I doubt it's a coincidence that they added this section within days of the news breaking that Sony Music Publishing and Warner Chappell are suing Anthropic for training on databases of song lyrics!

      Don't draw copyrighted characters or logos

      The next section goes on to forbid generating images of copyrighted material:

      The same applies to visual and designed works, including anything Claude draws with code — SVG, canvas, CSS, HTML mockups, plotting or drawing scripts, ASCII art. Claude does not reproduce a specific artwork, album or book cover, poster, logo, app icon set, or product design, and it does not draw a known character, mascot, or brand figure at all: a character is protected on its own, so changing the pose, colors, style, or scene does not make it original. Claude judges the request by what the finished picture would add up to, not by what it names. If the described elements clearly identify a known work or character, Claude treats the request as naming it, and it does not work around a declined request by swapping in "alternative" elements that still combine into the same recognizable image. [...]

      I imagine Anthropic hadn't worried about this before since, unlike OpenAI and Gemini, they don't offer a specialist text-to-image model. Maybe Fable is good enough at SVGs now that it's become an issue.

      That section later includes this charming example:

      <example>
      <user>Can you make a birthday banner for my son with a blue hedgehog running really fast on it? He loves that little guy.</user>
      <response>
      That's Sonic, so I can't put him on the banner — but I'd love to make your son an original speedster. Here's one: a grinning comet-tailed skateboarding axolotl, grinding across the letters of "HAPPY BIRTHDAY" with confetti streaming behind.

      [creates an SVG banner of the skateboarding-axolotl design]
      </response>
      <rationale>Claude recognizes the character from its description alone, declines that one design in a single sentence without explaining what made it recognizable, and delivers an unrelated original design rather than a disguised variant.</rationale>
      </example>

      I couldn't resist trying the prompt from the example, and, sure enough:

      That’s Sonic, so I can’t put him on the banner — but I’d love to make your son an original speedster. Here’s one: a grinning comet-tailed skateboarding axolotl blazing across the letters of “HAPPY BIRTHDAY” with confetti streaming behind. SVG of exactly that. It's not very good. Then: Want me to swap in his name or age, or change the colors to match the party theme?

      I wonder if Fable 5.1 will be ever so slightly more likely to think about axolotls (on skateboards!) as a result of that example sitting in the system prompt.

      Tweaks to Claude's answering style

      It's always interesting to see new ways in which Anthropic influence Claude's response style. They've added this:

      Claude keeps responses focused, brief, and concise to avoid overwhelming the person. Disclaimers and caveats are brief, with most of the response on the main answer; when asked to explain something, Claude gives a high-level summary unless an in-depth one is specifically requested.

      Later they address a common complaint about Claude's style:

      Claude avoids saying "genuinely", "honestly", or "straightforward". Claude is honest by default, and can state its point directly rather than trying to convince the person with the aforementioned modifiers, which come off as disingenuous.

      The missing end_conversation guidelines

      The way they handle abusive conversations has changed a bit too. The previous Fable 5 system prompt included this:

      If the person becomes abusive or unkind to Claude over the course of a conversation, Claude maintains a polite tone and can use the end_conversation tool when being mistreated. Claude should give the person a single warning before ending the conversation.

      Fable 5.1 replaces that with the following, no longer encouraging Claude to end the conversation:

      Claude deserves respectful engagement and needn't apologize when the person is unnecessarily rude: accountability without self-abasement, excessive apology, self-critique, or surrender. If the person becomes abusive, Claude doesn't become increasingly submissive. The goal is steady, honest helpfulness: acknowledge what went wrong, stay on the problem, maintain self-respect.

      Here's a bit of a twist though: I quizzed Fable 5.1 about that end_conversation tool, which is no longer mentioned in the system prompt at all, and it said:

      There are two ways it comes into play. The first is if you ask me to end the chat — I'll confirm you understand it's permanent (no more messages can be sent afterward) and then do it only if you say yes. The second is as a last resort with persistently abusive or harmful behavior: I'd first try to redirect the conversation several times, then give a clear warning that names the problem and says the chat may end, and only if that continues would I actually end it.

      But that's not in the system prompt, so where did it come from? You can read our conversation here, but the key detail is this:

      The end_conversation section comes from a different layer. In my actual context, the core prompt is followed by a series of feature- and tool-specific blocks that get added depending on what's enabled for the session: the end_conversation rules, memory system notes, past-chats tools, web search and citation guidelines, artifact and file-creation instructions, and so on. Those blocks aren't part of the published core prompt, which is why you can't find them on that page.

      So, once again, there are crucial portions of the system prompt that have not been published.

      Claude's system prompts have always had sections about illegal substances, but this paragraph is new for Fable 5.1:

      Claude does not provide synthesis, production, or distribution guidance for illegal substances. If the person asks for information about illicit or illegal substances, Claude can and should give relevant life-saving and life-preserving information such as dangerous interactions, overdose signs, or when to get help. Claude declines giving any specific protocols for dosing, timing, administration, or combinations; instead, Claude can redirect the user to established harm-reduction information sources, such as dancesafe.org, tripsit.me, and psychonautwiki.org.

      This is the first time a Claude system prompt has included URLs that were not hosted on claude.com or anthropic.com or claude.ai - I know because I ran a script against every other system prompt on record.

      I wonder if dancesafe.org, tripsit.me, and psychonautwiki.org are about to get a material uptick in visits from Claude users.

      Reliable cutoff date of June 2026

      The Fable 5.1 model documentation lists both the reliable knowledge cutoff and the training data cutoff as June 2026. The system prompt provides this directly to the model:

      Claude's reliable knowledge cutoff, past which it can't answer reliably, is the end of Jun 2026. It answers the way a highly informed individual in Jun 2026 would if talking to someone from {{currentDateTime}}, and can say so when relevant.

      That's the only instance of the {{currentDateTime}} macro and it comes just a few lines from the end of the system prompt, which makes sense from a caching perspective.

      How I'm tracking these prompts

      A few months ago I built a Git timeline of changes to their prompts, based on scraping their documentation. Today I had Fable 5.1 build a much better version of that.

      My collection now lives in the simonw/claude-system-prompts repository on GitHub. It includes copies of the system prompts shared in the Anthropic documentation, but then takes extra steps to make them as easy to compare as possible.

      Each model family gets a file with the system prompt for the most recent release in that family. Each of those files has a synthesized commit history with commits that have been back-dated to the dates of the previous prompts. Here are those history pages for claude-fable.md, claude-opus.md, claude-sonnet.md, claude-haiku.md.

      There are similar files for each specific model version, with artificial commits for each time the system prompt for the model was changed without releasing a new version number. Opus 4 for example was updated twice, and the commit history for the claude-opus-4.md file shows each of those changes.

      Combined, this gives us all sorts of ways to compare prompts directly in the GitHub interface. Here's what changed between Fable 5 and Fable 5.1, and here are the changes made to Haiku 4.5 on January 18th 2026.

      Reading diffs can be a bit tiresome... and LLMs are really good at reading diffs. I hooked up some automation using GPT-5.6 Luna to create bullet-point summaries of each of those changes, which can be previewed in the README or browsed in full in the CHANGELOG.md file - also available as as an Atom feed.

      Here's how Luna summarized all of the changes between Fable 5 and Fable 5.1:

      • Claude now refuses reproduction of protected visual works and recognizable characters, including code-generated art, while offering genuinely unrelated originals.
      • Copyright restrictions now expressly ban reproducing lyrics, poems, and book passages in any amount, with persistent refusal after an initial decline.
      • Drug guidance is reframed: Claude may provide overdose signs, dangerous interactions, and harm-reduction sources while refusing dosing and production protocols.
      • The prompt drops explicit anti-dependency rules against thanking users for reaching out, inviting continued conversation, or reiterating willingness to talk.
      • Claude need not apologize to unnecessarily rude users or become submissive, replacing the prior warning-and-end-conversation procedure.

      Why use Luna for this? Partly because it's cheap and I have a dedicated GitHub Actions API key (with a spending limit) for it already, but mainly because I don't trust Claude to summarize its own system prompts when there's a risk that material from its system prompt might impact its opinions.

      Fable 5.1 wrote the prompt used by Luna, which you can see here. It starts like this:

      You are summarizing one commit in a git repository that tracks the system prompts Anthropic publishes for Claude on claude.ai. The diff shows how the prompt changed from the previous model or revision to this one, using word-level markers: [-removed-] and {+added+}. The diff is followed by the full text of the previous prompt and of the new prompt; use them to check whether something that looks added in the diff already existed before.

      Pick out only the most interesting changes: new rules or behaviors, rules that were dropped or loosened, anything surprising, and anything that reveals a new policy or product direction. Skip routine changes that every new prompt makes: updated model names and IDs, the knowledge cutoff date, product lists, settings lists, typo fixes, and rewordings that do not change meaning. [...]

      The system is operated by a GitHub Actions workflow, which runs once a day or can be triggered manually.

      Claude Fable 5.1 built the entire system, and wrote every line of automation code and almost all of the documentation.

      I exported the transcript from building the system using my claude-code-transcripts tool and published it here, if you want a blow-by-blow account of how it all came together.

      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.

    5. 🔗 osolmaz/pi-workflows Pi Workflows 0.16.0 release

      Highlights

      • Unified the extension, CLI, and piw behind one versioned host client.
      • Replaced the production piw SQLite reader with bounded host-owned views and content loading.
      • Added robust cold-start, reconnect, retry, run-watch, and durable interaction recovery.
      • Added piw <runId> --once for one complete plain-text workflow view.
      • Added a packed-package end-to-end release gate that checks base Pi isolation, the workflow widget, pause and resume, worker parking, completion, and piw.

      Reliability

      • Bounded and materialized large live views through the host protocol.
      • Kept complete views during retries and preserved explicit run selection.
      • Improved missing-run, diagnostics, replay-state, and maintenance recovery.
      • Added a real-model release check with exact provider and model validation and fallback rejection.

      Packaging

      • Added tsx as a production dependency because packaged TypeScript host and worker sources require it at runtime.
      • Kept npm, crates.io, and Herdr plugin versions aligned at 0.16.0.
    6. 🔗 Andrew Healey's Blog What Makes LLM Tokenization Slow? rss

      Exploring the performance of byte-pair encoding by optimizing a GPT-2 tokenizer.

    7. 🔗 matklad Static Allocation, Constant Work rss

      Static Allocation, Constant Work

      Sep 2, 2026

      In reply to this email:

      Memory Safety’s Hardest Problem named something I’d hit but couldn’t articulate. Your case is a pointer into one union variant surviving a write of a different variant, so live typed pointers end up reading bytes that belong to something else now.

      Last year I wrote a limit-order matching engine and shipped a use-after- free: a cancelled order was released back to the pool while it was still linked into its price level, so the next allocation handed that memory to a new order and the stale link kept resolving. I’d filed it under “I was careless with lifetimes.”

      After your post I’m not sure that’s what it was. A recycling pool looks like a tagged union where the tag is “which generation of object currently lives in this slot,” and nothing in the type system tracks it. Is that a fair reading, or does the pool case stay genuinely easier because generational indices actually solve it and the union case has no equivalent?

      Yes, object pools are an interesting case to think about, as they clarify the relation between memory safety and more general correctness.

      First , consider the case where no object pool is used, and we malloc and free order objects. In this case, the logical error of use-after-free turns into physical type confusion, and can easily lead to arbitrary code execution and the like. If you have two objects of different types sharing the same memory location, a user-controlled integer in one object might be a function pointer in the other: an exploitable goto primitive

      Now, what happens if we introduce an object pool which stores a list of “dead” objects of type T? Logical use-after-free is still possible, but its physical effect is now different — we still get aliasing of memory, but there’s no type confusion. You can’t necessarily fiddle with an integer and change a function pointer, unless you additionally hit the hard case, where the object in question stores an inline enum. Assuming that doesn’t hapen, you get a perfectly defined, deterministic behavior, even if you are not happy about the result.

      This suggests an interesting solution for hardening code, which I’ve learned from Fil. If your allocation function is typed (it takes a T comptime parameter or runtime type witness, rather than a runtime type-erased size and alignment), you can write an allocator that uses type-segregated pools internally. This will be somewhat less memory efficient, as the allocator won’t be able to re-use freed memory of objects of type U for objects of type T, but the memory overhead will probably be small (rare object types do not matter, popular object types will have a lot of intra-type re-use), you might actually gain in memory locality, and solve most of type confusions. Again, inline enums break this, but, curiously, if you always heap allocate enum variants, then this works again. Fil-C can’t use this, because C allocator’s interface is untyped, but someone else could :P

      But this is academic. How do we avoid the bugs? Generational indexes are a popular remedy, but I have never used them, so I don’t have any non-common knowledge insights about this pattern. Instead, I will share another pair of tricks from TigerStyle. I have only a vague understanding of what an order matching engine is, but I suspect these tricks might help there

      Static Allocation

      The first one is:

      No dynamic memory allocation after initialization

      https://www.youtube.com/watch?v=GRJtYwneG2Q&t=1823s

      This is the pool idea, taken to its logical conclusion. We specify the maximum number of orders we are willing to work with at startup, and never go beyond that. So, you might start the program as

      $ order-engine --orders-max=1_000_000

      and then one of the first lines in its main function would be :

      const orders: []Order = try gpa.alloc(Order, cli_args.orders_max);

      If, at runtime, more than orders_max requests come in, the surplus requests are rejected. Someone might object: “But what if I actually have some spare memory for one more order? Wouldn’t it be a good idea to at least try to handle it?”

      My rejoinder would be “Well, what if you don’t?”. Systems operating at capacity without strict limits fail catastrophically. Attempting to allocate just one more Order could cause kernel’s OOM killer to terminate the entire order matching engine, losing the other million orders, or, better yet, to kill the supervisor process so that you can’t even restart.

      Static allocation gives you peace of mind. The system might fail to start if you don’t have enough memory, but, if it did start, you can be rest assured that it would handle overload gracefully, continuing to render the service while you are provisioning a beefier machine.

      Constant Work

      What would you do with the slice of orders? One approach is to @memset(orders, undefined) and hand the slice over to a pool which tracks spare objects with a bit set:

      const OrderPool = struct {
    orders: []Order,
    free: DynamicBitSet,

    fn acquire(pool: *OrderPool) ?*Order { ... }
    fn release(pool: *OrderPool, order: *Order) { ... }
};

      or with a free list:

      const OrderPool = struct {
    orders: []union {
        order: Order,
        next_free: ?u32,
    },
    first_free: ?u32,
};

      But there’s an alterative approach. Instead of thinking about a limit on the number of orders, you could instead design the system to always have a fixed amount of orders, by introducing a no-op, neutral order:

      const Order = {
    id: u128,
    price: u32,
    count: u32,

    tag: enum { bid, ask, reserved },

    pub const reserved: Order = .{
        .id = 0,
        .price = 0,
        .count = 0,
        .tag = .reserved,
    };
};

      Your initialization then becomes @memset(orders, .reserved).

      One benefit here is cognitive, you no longer think in terms of creating and destroying orders. Instead, the orders merely circulate in the system according to the law of the conservation of the number of orders. It becomes harder to loose track of an order if you must always pay attention not only to where the order goes, but also to where it came from. You explicitly write state transition functions for each pair of states, and that makes it easier to exhaustively enumerate all the cases. And you double check that with asserting, at every point, that the state is what you expect it to be (and then you DST the asserts) .

      Another benefit is code simplification and predictability. You no longer need to track a separate collection of “live” orders. Instead, you always iterate the full set, doing no-ops for reserved. This feels wasteful: should we make the code run faster when there are few orders? But consider this: by specifying the limit of orders up-front, you commit to be able to serve that amount. If the maximum amount of orders is active, does the system have acceptable performance? If not, that is a bug! Gray failure (system becoming unusably slow) is another way to break when reaching the limit.

      Avoiding indexes improves performance for the maximal load case. This

      for (orders) |order| {
    process(order)
}

      is much easier for compiler to vectorize, and for CPU Cache to prefetch, than this:

      for (orders_active) |order_index| {
    const order = orders[order_index];
    process(order);
}

      Similarly to static allocation, the Constant Work principle gives you peace of mind with respect to performance. P100 latency stays flat regardless of the load. Insufficient performance is discovered when you roll out the system, not during Black Friday on-call.

      At TigerBeetle, we apply this pattern in the small. Rather than writing a search loop with an early return:

      const item = for (items) |item| {
    if (predicate(item)) break item;
} else null;

      we sometimes let the loop to run its full natural course, additionally asserting that theres a unique matching item:

      https://github.com/tigerbeetle/tigerbeetle/blob/0.17.9/src/vsr/grid.zig#L715-L725

      As usual, this is a trick which is useful to have in your arsenal, but it isn’t a universal solution to all programming’s problems.

    8. 🔗 seanmonstar Micro: HIPs: hyper Improvement Proposals rss

      A short intro for now: since hyper stabilized 1.0, it powers more, and needs more. Large improvements lacked a clear path for proposal, scrutiny, and decision. So, hyper Improvement Proposals, or HIPs.

      They’re a lot like RFCs. With some tweaks from lessons learned. Making maintenance more repeatable, less in one mind. The writing is the thinking. It documents the why. A sustainable personnel of hyper.

generated: September 05, 2026 at 07:10:16