🏡


to read (pdf)

  1. I don't want your PRs anymore
  2. JitterDropper | OALABS Research
  3. DomainTools Investigations | DPRK Malware Modularity: Diversity and Functional Specialization
  4. EXHIB: A Benchmark for Realistic and Diverse Evaluation of Function Similarity in the Wild
  5. Neobrutalism components - Start making neobrutalism layouts today

  1. June 24, 2026
    1. 🔗 r/reverseengineering Reverse-engineered the Artiphon Orba 2's control protocol (MIDI + SysEx over USB/BLE), spec + Python/JS reference libs rss
    2. 🔗 @binaryninja@infosec.exchange We are live! Tune in now for a walkthrough of Zenyard + Binary Ninja on a real mastodon

      We are live! Tune in now for a walkthrough of Zenyard + Binary Ninja on a real target! We’re covering whole-binary analysis, file-wide renaming, multi-file analysis, and asking grounded agent questions with full-binary context. https://youtube.com/live/JG15oxrWgp0?si=enCtsPERsEIvJgOP

    3. 🔗 BarutSRB/OmniWM OmniWM v0.5.1 release

      CleanShot 2026-06-24 at 12 55 52

      What's New Since 0.5.0

      This release is mostly about making problems easier to explain and easier to fix. OmniWM can now help you spot common setup issues, record a problem while it happens, gather the useful files, and open a clearer GitHub issue without making you dig through hidden folders.

      Easier Troubleshooting

      • Added a new Troubleshooting area in Settings.
      • OmniWM now checks for common problems such as missing Accessibility permission, unavailable shortcuts, shortcuts that may also trigger macOS actions, Hyper-key shortcuts that were recorded too narrowly, Dock placement that can interfere with parked windows, display arrangements that can make edge behavior look wrong, and settings file problems.
      • Each warning explains what is wrong in plain language and, when possible, gives you a button to open the right System Settings page or reveal the right folder.
      • Recent troubleshooting files now appear in one place, with buttons to copy, reveal, or reuse them.

      Record a Problem

      • You can start a short problem recording from the menu bar or from Settings.
      • While recording, the menu bar icon changes so it is obvious that OmniWM is capturing what is happening.
      • When you stop recording, OmniWM saves the file and reveals it in Finder.
      • A recording captures the state before and after the problem, plus recent window events, shortcut input, mouse movement, layout changes, and where windows were placed. That makes fast or hard-to-repeat bugs much easier to understand.
      • Recordings stop automatically after ten minutes so they do not keep running by accident.

      Better Issue Reports

      • Added a Report Issue screen that creates a local zip file and opens a pre-filled GitHub issue in your browser.
      • The zip file can include the current troubleshooting report, recent crash logs, recent recordings, focused-window details, and your settings file.
      • OmniWM reveals the zip file in Finder so you can review it before attaching it to a public issue.
      • If the issue text is too long for a browser link, OmniWM copies it to the clipboard and still opens GitHub for you.
      • On supported Macs, OmniWM can use on-device Apple Intelligence to turn a rough report into a cleaner issue draft. On other Macs, it still formats your report into the same issue template without using AI.
      • If your report mentions a shortcut, OmniWM can compare it with your current shortcuts so the issue names the right command instead of guessing.

      Crash Follow-Up

      • If OmniWM recovers from a crash, Settings now shows a crash banner with a button to start a pre-filled report.
      • Crash logs are saved locally and kept with the other troubleshooting files, so the newest report can include what happened around the crash.

      Window-Specific Help

      • Added a way to save details about the focused window when one app or one window refuses to tile, floats unexpectedly, or behaves differently from normal windows.
      • That saved file can be included with the next issue report, which makes app-specific window problems easier to investigate.

      Focus Reliability

      • Rapid keyboard navigation is more reliable in both Niri and Dwindle layouts.
      • Fast repeated focus moves are less likely to end with OmniWM focusing the wrong window or losing the final move.

      Project Notes

      • Updated the documentation for the new issue-report prompt and troubleshooting workflow.
      • Added related OmniWM forks to the README.
      • Removed old cleanup files and simplified the release checks.

      Download Verification

      • OmniWM-v0.5.1.zip contains the Developer ID signed, notarized, and stapled OmniWM app.
      • OmniWM-v0.5.1.zip SHA-256: f337c0d5cfcb796815358d23f8aafecddbac6ac213aa10cbf35467604f48e878
      • GhosttyKit.xcframework-v0.5.1.zip SHA-256: 2267caddbe0b4b970a45d2a4f8c324ce6ce9485fa244c61560493b83da9caeed
    4. 🔗 anthropics/claude-code v2.1.190 release

      What's changed

      • Bug fixes and reliability improvements
    5. 🔗 crosspoint-reader/crosspoint-reader CrossPoint 1.4.0 release

      CrossPoint 1.4 is mostly about things users don't see: tighter memory management, better stability under load, and a faster, more reliable SD layer. It also ships several long-requested features: EPUB bookmarks, RTL language support, Quick Resume, and a clock on the X3.

      152 changes from 50 contributors, 32 of whom are new to the project.

      EPUB Reading

      • Bookmarks now work in EPUBs. Access it from the reader menu with Toggle Bookmark. You can also set it as a Long-press action from Settings > Controls > Long-press Menu.
      • Page turn speed and image quality improved on the X3 in AA mode
      • Large images load faster and no longer freeze the reader
      • Images no longer ghost onto the next page in AA mode
      • SD font indexing and page turn speed improved
      • Fixed missing images and broken footnote links
      • Sub-chapter TOC navigation now lands at the correct anchor instead of jumping to page 0
      • Cover images in OPF manifests are validated before use
      • OPDS downloads prefer EPUB over KEPUB
      • KOSync no longer glitches when syncing from the first page of a new chapter
      • Added superscript, subscript, and horizontal rule (<hr>) support

      RTL Language Support

      Right-to-left text is now supported in both the EPUB and TXT readers. Hebrew UI localization added.

      Memory & Stability

      • WiFi/LWIP teardown runs via a silent reboot that clears ~50KB of heap fragmentation. It routes you back where you were and looks like a screen refresh.
      • Home screen cover cache reduced from ~52KB to ~16KB
      • OTA install heap floor stays ~19KB during firmware downloads (was ~7.7KB)
      • Tiled grayscale rendering drops peak allocation from ~114KB to ~82–90KB
      • Fixed OOM crashes on books with thousands of ZIP entries
      • CSS resolveStyle path now does zero heap allocations — ~12,000 fewer per page render
      • Underline calculations skipped during font cache scans, cutting hundreds of SD reads on pages with heavy underline use

      Fonts

      Domitian and Libre Baskerville added to SD fonts. OpenDyslexic moved off flash, freeing ~30% of the flash space. The font picker now have a live preview pane that renders a sample in the currently highlighted font.

      New Features

      X3 Clock — Built-in clock with automatic time sync.

      Themed Reader Menus — Reader menus follow the active theme.

      Custom Sleep Timer — Free-entry field from 1 to 30 minutes (or never), replacing fixed presets.

      Recent Books — Long-press to remove individual books. Option to auto- remove once a book is finished.

      Quick Resume — Sleep setting that displays your last screen or page instead of a sleep image or cover.


      What's changed

      Features

      Fixes

      Internal

      Languages


      New Contributors


      Full Changelog: release/1.3.0...release/1.4.0

    6. 🔗 sacha chua :: living an awesome life Considering my time balance this schoolyear, and getting ready for summer rss

      It's A+'s last week of virtual Grade 4 before summer vacation. This time of the year, when the teachers turn to filler activities like games and movies, she tends to find the pace excruciatingly slow and of little interest to her. There was a substitute teacher on Monday. She's not keen on having a substitute teacher since they tend to run into technical issues or go at a much slower pace. She already finds the regular class pace agonizingly slow. Her classmates goof off a bit more around a sub, too. But I needed some time for paperwork, so she begrudgingly signed into class. She reported that, as predicted, they got absolutely nothing done. The students played games and watched a movie. On Tuesday, there was another substitute. I'd done my paperwork for now, so I called the school to let them know she'd be absent. We were about to head out for some ice cream after breakfast, but she got upset about something and decided to stay in her room for a bit. I finished putting together Emacs News and played a bit of Stardew Valley with the Tileman Reworked mod to destress after the last few days of paperwork, and then I started on this reflection.

      (Wednesday update: Back to the regular teacher, but now there's a Zoom update that's making it hard for the students to connect to class, so the teacher is switching back to Google Meet for a bit. It sounds like A+ managed to make it back on.)

      The change of routines to summer is a bit challenging for us. Well, the schoolyear is challenging for us too. I suppose summer is challenging in a different way. The playgrounds are busier and louder. The sun is brighter and hotter. The usual rhythms of playdates with her friends changes as they go to summer camps or other activities. I move from having medium-sized chunks of fairly predictable focus time to playing everything by ear.

      Time analysis

      Before we officially head into summer, I want to think about how I used my time this schoolyear, and how I can prepare for summer and next schoolyear. How to read this graph: gray is sleep, pink is childcare, blue is more focused time, orange is consulting. If you click on the image, it opens an SVG with tooltips.

      2024-2025.png
      Figure 1: 2024-2025 (grade 3)
      2025-2026.png
      Figure 2: 2025-2026 (grade 4)

      The biggest difference was that A+ wanted to exert more independence and autonomy when it came to school. In Grade 3, she wanted me to stay in her room so that she could ask me for help or hang out with me when she was bored. In grade 4, she preferred to have her room all to herself. W- helped me set up a little desk in the corner of another room on the same floor, so I could still be close by, but A+ mostly did things independently. Or didn't do things, as the case may be; I learned not to push her on schoolwork, since the only thing that accomplished was grumpiness all around. I've been practising stepping back. It's her experiment, after all, and the teachers can give her feedback on school things. I can keep myself busy with my own focused-time stuff so that I don't fret at her. After I got through my initial anxieties, I settled into doing more of my stuff during the schoolday.

      Category 2024-2025 % 2025-2026 % Diff % h/wk Diff h/wk
      Personal 9.2 13.8 4.6 23.2 7.7
      Discretionary - Productive 13.9 18.4 4.6 30.9 7.6
      Unpaid work 4.1 4.6 0.5 7.7 0.8
      Discretionary - Family 0.3 0.7 0.4 1.1 0.6
      Discretionary - Play 1.9 1.1 -0.8 1.9 -1.3
      Business 2.1 1.1 -1.0 1.8 -1.7
      Sleep 33.4 32.2 -1.1 54.2 -1.9
      A+ 35.1 28.1 -7.1 47.1 -11.9

      In grade 4, A+ started learning French. I started learning French too so that I could help her. I practised pronounciation with a virtual tutor once or twice a week, and I wrote journal entries in French too. (These images are just screenshots.) There were other discretionary activities, of course.

      Category 2024-2025 % 2025-2026 % Diff % h/wk Diff h/wk
      Discretionary - Productive - French 0.0 5.2 5.2 8.8 8.8
      Discretionary - Productive - Emacs 4.5 7.3 2.8 12.2 4.8
      Discretionary - Play - Stardew Valley 1.2 0.7 -0.5 1.2 -0.8
      Business - Earn - Consulting 2.0 0.8 -1.1 1.4 -1.9
      Discretionary - Productive - Writing 2.9 1.3 -1.6 2.2 -2.6
      2026-06-23_12-35-42.png
      Figure 3: Heatmap of time I spent on French (370 hours since Oct 23, 2025)

      I tended to turn to Stardew Valley for de-stressing or revenge bedtime procrastination. Interestingly, my nascent fixation on French pretty much replaced Stardew Valley until it got slowed down by other things happening in my life starting April, which also coincided with my time on Stardew Valley picking up again in April in order to unwind.

      2026-06-23_21-33-10.png
      Figure 4: Heatmap of the time I spent on Stardew Valley (175 hours since June 23, 2025)

      Emacs continued to be another good way to unwind. I gave myself permission to spend more time just having fun with Emacs. Following up on my reflection for Emacs Carnival March 2026: Mistakes and learning to reach out, I started scheduling conversations during A+'s schoolday. I did some Yay Emacs livestreams and Emacs Chat interviews as an experiment. I think it was a good way to get lots of tips out of people's heads and into videos/transcripts/screenshots, and I also improved my workflow for editing transcripts and extracting images. Not counting Emacs News, I wrote 47 Emacs-related posts during the previous schoolyear and 65 posts during the current schoolyear.

      Other changes this schoolyear:

      • Pre-adolescence: A+'s been having a harder time with her feelings. I think this might be related to pre-adolescence. Totally normal. One of my goals is to keep myself calm and regulated, and another one is to help her connect with more people she likes so that she can feel supported even when she's grumpy with me. She can chat with her aunts and cousins via Stars Messenger without needing to go through me, so that's good.
      • Gymnastics: We figured out how to get one-on-one gymnastics classes going, and A+ has been enjoying them.
      • Pokemon: A+ and I started playing Pokemon Go. We play it pretty casually, and we've joined a couple of the meetups. It's been a good excuse to go for the occasional walk, and it's also a good way to take advantage of a bike ride. She's also gone deep into the lore (so many books!) and has watched more than a dozen seasons of the Pokemon TV series. She occasionally plays Pokemon on W-'s old Game Boy Advance.
      • Dungeons & Dragons: We've also been playing D&D. We started playing in virtual sessions with my sisters and nieces. A+'s really taken to it, including experimenting with DMing. We've gone through much of the Keep on the Borderlands Starter Set (thanks to my sister) as a duet adventure, except for a number of the Caves of Chaos which were too scary for A+ even though I tried to balance things differently. She's more into roleplaying than combat, so we mostly improvise our own adventures. I keep a d20 and a d6 in my vest, and my phone has virtual dice too for when we're walking around.
      • W-: W- retired, yay! He's been enjoying biking and working on personal projects. A+ still hangs out with me more than with him, but that's fine.

      Thoughts for next year:

      • Neurodivergence: A+ and I find it a little challenging to adapt to changes in routine and also to handle boredom. I think I'll talk to our doctor about considering a neuropsych assessment in case knowing more about our brains can help make things a little bit easier for us. I think she'll still have a bit of leeway at school for the next few years, so it's a good time to experiment and figure out things that work better for us. We've been talking about neurodivergent strategies, too.
      • Pre-adolescence: It's probably going to be a little tougher next year (pre-adolescence, extended family challenges, etc.), but this is fine. We signed up for all of this, and this is where we get to see how our preparations work out. It's also good equanimity practice. The turbulence is natural. I want to stay loving, patient, and supportive.
      • Emacs: For now, Emacs Chats (and the transcription thereof) might actually be more useful to the wider Emacs community than my hacking around with idiosyncratic Emacs Lisp code, especially since I still have a hard time getting my brain to cooperate with the extra bit of polish needed to finish an idea and/or properly contribute things upstream. Livestreaming while I'm tweaking Emacs is an interesting trade-off which I think ends up being mostly positive: I'm slightly distracted because I have to talk out loud, but on the plus side, people's suggestions and questions (and the feeling that other people are watching) also help me focus on the current task instead of going down a different rabbit-hole. Or at least it encourages me to either capture the TODO for the next idea or leave myself some breadcrumbs if I really do want to go down that other rabbit-hole on stream. I'll pause these for summer. I'm looking forward to experimenting with them more next schoolyear, especially if I can balance it with the work I put into organizing EmacsConf.
      • Virtual school: Virtual school continues to feel like the right choice for us both in terms of health and the ability to manage stimulation levels. When she finds her classmates too noisy, she can lower the volume. When she needs a break, she can sign out and we can work independently. We hope next year will be a good fit too. This year, the Toronto District School Board consolidated all its virtual students into one virtual elementary school, which was nice because they didn't feel left out of hybrid activities. We still had the usual transition pains this schoolyear, but maybe next year will be smoother.

      Getting ready for summer

      Here's what my time looked like last summer:

      2025-summer.png
      Figure 5: Summer 2025

      Unsurprisingly, it's mostly childcare. A+ had a series of private swimming lessons (too short to do much during) and one afternoon summer camp (during which I did a lot of consulting). Aside from that, we basically hung out with each other unless she was grumpy with me or one of us was in the bathroom. She tended to wake up early, so I didn't usually get focus time during the morning. Or any time during the day, really. But now I can practise French in my head, so that's good. A+ is thinking of getting her own Bluetooth earbuds since they're helpful for managing overstimulation at the playground, so I'll be able to get mine back and maybe even listen to comprehensible input podcasts when she's not directly interacting with me.

      Comparing summer 2025 with schoolyear 2025-2026:

      Category Summer 2025 % SY 2025-2026 % Diff % h/wk Diff h/wk
      Discretionary - Productive 10.5 18.4 7.9 30.9 13.2
      Personal 9.8 13.8 4.0 23.2 6.7
      Sleep 30.7 32.2 1.6 54.2 2.6
      Discretionary - Family 0.1 0.7 0.6 1.1 1.0
      Unpaid work 4.3 4.6 0.2 7.7 0.4
      Business 1.5 1.1 -0.4 1.8 -0.7
      Discretionary - Play 6.2 1.1 -5.1 1.9 -8.5
      A+ 36.8 28.1 -8.8 47.1 -14.8

      As expected, the schoolyear means less time with A+ compared to summer (-14h / week), which mostly gets shifted to productive time (+13h/week). I actually get a little more time to sleep during the schoolyear, too. So, preparing for this upcoming summer, I can anticipate less sleep and more time with a possibly tetchy kiddo, but if I can take advantage of little moments here and there (like when she's in the bathroom for an unpredictable length of time, or when she needs space for me), then I can take care of whatever I need to stay sane.

      I'd like to continue with my sessions with French tutors, although I might have to experiment with the timing to see what works. Shortly after lunch might still be nice, since it's probably going to be too bright and hot to enjoy being at the playground. If I keep improving, then I can use little snippets of idle time (like when she's playing with her friends) to rehearse sentences, listen to comprehensible input, or write my journal entries.

      Let's compare summer 2024 with summer 2025:

      Category Summer 2024 % Summer 2025 % Diff % h/wk Diff h/wk
      Discretionary - Productive 2.5 10.5 8.0 17.7 13.5
      Discretionary - Play 1.6 6.2 4.6 10.4 7.7
      Personal 7.5 9.8 2.3 16.5 3.9
      Unpaid work 4.1 4.3 0.2 7.3 0.4
      Discretionary - Family 0.6 0.1 -0.5 0.1 -0.9
      Business 4.5 1.5 -3.0 2.5 -5.1
      A+ 42.5 36.8 -5.6 61.9 -9.5
      Sleep 36.6 30.7 -6.0 51.5 -10.0

      Some thoughts for this upcoming summer:

      • Sleep: I probably want to get back to about 8 hours of sleep a day (33%), which is totally doable if I resist the temptation to squeeze in gaming or coding. This probably means I need to take better care of myself during the day so that I don't feel the urge to indulge in revenge bedtime procrastination, which probably means (1) finding ways to spend time with A+ that I enjoy more, like D&D, biking, or swimming, and (2) using French or other portable pick-up-and-put-down activities to take advantage of little snippets of free time.
      • Childcare: A+ might want to spend lots of time with me, but less than the previous year as she becomes more independent, and the sharp drop in the time kids want to spend with their parents is coming inexorably. I can probably keep the discretionary stuff to just whatever keeps me sane, and focus on enjoying time with A+. Maybe more D&D, especially since we're figuring out ways to improvise on the go. Swimming is nice, too.

      FAQ:

      • How much time does it take to track and analyze your time?
        • Hardly any time to track it, maybe a couple of seconds between activities. I made a home-made web-based system for tracking my time, and I can easily update it by tapping buttons on my smartphone or specifying a less common category. It doesn't have to be super precise. Most of the analysis reuses code from previous years, including the web-based graphs. I generate the tables with Emacs Lisp in an Org Mode Babel block. Thinking about how I've been using the time takes time and reflection, but it's good for me.
      • Can you share your tracking system?
        • I used to let other people use it, but bots kept hammering it, so now it's just for me. Here's the source code just in case you want to try self-hosting.

      You can e-mail me at sacha@sachachua.com.

    7. 🔗 r/reverseengineering Transformers Forged To Fight Revival Discord Server rss
    8. 🔗 r/reverseengineering W1R3L355 the reverse framework rss
  2. June 23, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-23 rss

      IDA Plugin Updates on 2026-06-23

      Activity:

      • claude-of-alexandria
        • 1400d5d4: chore(deps-dev): bump the minor-and-patch group (#80)
        • eecdc966: chore(deps-dev): bump @anthropic-ai/claude-agent-sdk (#79)
      • distro
        • 9b95e0df: Add all-interface option to myip
      • ghidra
        • ac190bcd: Merge remote-tracking branch 'origin/patch'
        • a1caa912: Merge remote-tracking branch
        • 1541f3a7: GP-6934: Implement OS/shell-dependent escaping.
        • 082f7fe9: GP-0: Fixed potential NPE in ImageCor20Header.java (Closes #2246)
        • 3e9b4295: GP-0: Fixing potential NPE in User.java (Closes #1739)
        • a25f23b6: GP-0: Removing unnecessary DMG NPE check, and some cleanup
      • ida_graph_parser
      • IDAPluginList
        • 3dbf4a39: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • idasql
        • 8e552e52: chore(cli): remove dead hand-rolled HTTP code (#41)
        • fa6b19b6: feat(http): put -http and the plugin fully on the thinclient (#40)
        • bdf9020b: lib: resolve bookmark inodes via store enumeration, drop get_by_inode…
        • 669e82cb: feat(http): honor continue_on_error/include_sql/format on all HTTP pa…
        • bb528c42: chore: gitignore .DS_Store
        • e2036e47: docs: add project logo to README
        • d4b4a9ba: fix(plugin): make ida_compat.hpp self-contained (include )…
        • bad516bc: feat: ?format= output option + output guidance (#37)
        • 7e1a644c: lib: emulate bookmarks_t::get_by_inode() on pre-9.3 SDKs (#35)
      • playlist
    2. 🔗 earendil-works/pi v0.80.2 release

      Changed

      • Changed inherited pi-ai ApiKeyCredential to use the auth.json-compatible discriminator type: "api_key" and provider-scoped env values instead of type: "api-key" and metadata.
      • Renamed the inherited agent-core public harness shell execution options type from ExecutionEnvExecOptions to ShellExecOptions.

      Fixed

      • Fixed inherited Anthropic-compatible custom models to use explicit compatibility metadata instead of provider-name heuristics for session-affinity headers and unsupported tool-field omissions.
      • Fixed inherited request-scoped apiKey and env values to participate in provider auth resolution, so providers such as Cloudflare can derive request-specific base URLs from explicit call options (#6021).
      • Restored inherited temporary legacy per-API stream aliases such as streamSimpleOpenAICompletions on the pi-ai compat entrypoint (#6016, #6017).
      • Restored inherited runtime detectCompat fallback in openai-completions for models without explicit compat metadata (#6020).
    3. 🔗 anthropics/claude-code v2.1.187 release

      What's changed

      • Added sandbox.credentials setting to block sandboxed commands from reading credential files and secret environment variables
      • Added org-configured model restrictions to the model picker, --model, /model, and ANTHROPIC_MODEL, with a "restricted by your organization's settings" message when a restricted model is selected
      • Added mouse click support to select menus (permission prompts, /model, /config, etc.) in fullscreen mode
      • Fixed --resume failing with "No conversation found" when the original -p run produced no model turns
      • Fixed --json-schema and workflow agent({schema}) structured output: the model can no longer re-call StructuredOutput indefinitely after a successful call, and follow-up turns now reliably return structured output
      • Fixed remote MCP tool calls that hang with no response for 5 minutes — they now abort with an error instead of blocking indefinitely (override with CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT)
      • Fixed Claude Code Remote sessions taking ~2.7s longer to start after the agent proxy CA system-trust install was added
      • Fixed pasted Korean/CJK text turning into mojibake in terminals that deliver paste as per-byte extended-key events
      • Fixed /update over Remote Control hanging when a startup trust dialog would have shown
      • Fixed background jobs in the agents view getting stuck in "working" indefinitely when the agent ended a turn without producing structured output
      • Fixed channel connections dropping after navigating to the agents view and back, and after /bg, /tui, or /update
      • Fixed agent stop notifications not correctly attributing who stopped the agent, and improved wording ("finished"/"stopped" instead of "came to rest")
      • Fixed subagent depth tracking: resumed subagents now restore their original spawn depth, and forked subagents now count toward the depth cap
      • Fixed leaked agent worktree registrations: locked .git/worktrees/ entries from killed agents are now cleaned up automatically
      • Fixed Cmd+click not opening URLs in fullscreen mode in Ghostty on macOS
      • Fixed claude --help not listing the --bg/--background flag
      • Fixed Esc, Ctrl-C, and Ctrl-D not working while /share is uploading
      • Improved /install-github-app: GitHub Actions workflow setup is now optional — you can install just the GitHub App and skip the workflow/secret steps
      • Improved /btw with ←/→ arrow navigation to step through earlier answers
      • Improved /plugin to surface plugins you haven't used recently so you can clean them up
      • [VSCode] Fixed extension becoming unresponsive when resuming a large session
    4. 🔗 r/reverseengineering tiny memory scanner in rust rss
    5. 🔗 earendil-works/pi v0.80.1 release

      Fixed

      • Fixed inherited Amazon Bedrock scoped AWS_PROFILE endpoint resolution for built-in inference profile endpoints.
      • Fixed inherited Fireworks Anthropic-compatible requests to apply session-affinity and unsupported tool-field defaults for custom Fireworks models.
      • Fixed inherited Together MiniMax M2.7 metadata to avoid unsupported Together reasoning toggles.
    6. 🔗 earendil-works/pi v0.80.0 release

      Changed

      • Added Ctrl+J as a default newline keybinding alongside Shift+Enter.
      • Renamed the displayed zai provider label to ZAI Coding Plan (Global) for clarity (#5965).
      • pi-ai's old global API (stream/complete/completeSimple, getModel/getModels/getProviders, registerApiProvider, getEnvApiKey, ...) moved off the @earendil-works/pi-ai root entrypoint to @earendil-works/pi-ai/compat. Extensions are not affected at runtime: the extension loader resolves the pi-ai root to the compat entrypoint (a strict superset), so existing extensions keep working unchanged. Extension sources that typecheck against pi-ai's published types should switch those imports to @earendil-works/pi-ai/compat (or migrate to the new createModels()/provider-factory API). The compat entrypoint and the loader alias will be removed in a future release with a migration guide.

      Fixed

      • Fixed session names to normalize newline characters before storing or displaying labels (#5999 by @haoqixu).
      • Fixed the session selector to order threaded session trees by the latest activity anywhere in each subtree (#5784 by @Perlence).
      • Fixed extension-related crash and startup-failure reporting to suggest restarting with pi -ne.
      • Fixed inherited OpenAI Responses streams to fail before missing terminal events and fixed context usage and compaction estimates to ignore malformed all-zero assistant usage after truncated responses (#5526 by @dmmulroy).
      • Fixed inherited OpenAI Codex Responses WebSocket sessions to reconnect once when OpenAI's connection limit is reached before output starts (#5973).
      • Fixed inherited Amazon Bedrock endpoint resolution to honor scoped AWS_PROFILE values.
      • Fixed inherited Cloudflare providers to require account/gateway configuration and route built-in compat calls through provider auth.
      • Fixed provider-scoped auth environment values to reach inherited Models/ImagesModels API calls and compat API-key injection.
      • Fixed inherited OpenCode Go GLM-5.2 metadata to expose xhigh reasoning and send the provider's max reasoning effort (#5967).
      • Fixed pi --resume to load user package themes and resolve automatic light/dark theme settings.
      • Fixed models.json custom providers so stored credentials can satisfy auth without a redundant provider-level apiKey (#5953).

      Removed

      • Removed inherited selective-provider @earendil-works/pi-ai/base and @earendil-works/pi-agent-core/base entrypoints; use the root packages with explicit Models provider factories instead.
    7. 🔗 The Pragmatic Engineer Reliability fail: No automated zone failover for Coinbase’s global trading service 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 this past The Pulse issue . Full subscribers received the article below two weeks ago. If you 've been forwarded this email, you can subscribe here .

      On the evening of Thursday, 7 May, trading at Coinbase went offline and stayed that way for nearly 10 hours (!!). Customers could not buy, sell, deposit, receive, or withdraw. Basically, the core services of Coinbase were unavailable.

      The outage coincided with a regional AWS outage. But no other company suffered a global outage; the most I observed was a few infra companies like Datadog noting that some regions had issues, and were failing over to a healthy region.

      It's weird that Coinbase - a $40B company! - told customers to monitor AWS's status pages for recovery. This made it pretty clear that the company fully depends on a single AWS zone. Unusually, Coinbase deleted this information from its status page, but I got a screenshot first:

      altOut in the open: Coinbase shifts blame for outage to a cloud provider

      Coinbase later confirmed that it does indeed have a single-availability zone dependency. From its postmortem:

      "Our matching engine was pinned to a single building. The Coinbase Exchange matching engine runs as a Raft-based replicated cluster inside an AWS Cluster Placement Group. We make this choice deliberately. A matching engine that meets the latency and throughput demands of a serious market cannot tolerate inter-zone network hops between voting cluster members. The physics of distributed consensus and the economics of running a fair, liquid order book point to the same answer, which is co-location."

      A quick recap on the difference between an availability zone (AZ) and region:

      • Availability zone: One or more data centers (in the case of AWS, it is usually several data centers) located close enough to have low latency between them. Data centers in different AZs must be independently resilient. In the same AZ, there is no such requirement.
      • Region: Within AWS, this consists of at least three isolated, physically separated AZs, usually 10-30 miles apart. It's unlikely they'll go down simultaneously, even in extreme circumstances.

      altFrom deepdive, Three Cloud Providers, Three Outages, Three Different Responses

      Coinbase is saying that running from more than one availability zone (AZ) (building) would introduce too much latency to their product. This makes sense for low-latency activities like trading. But what about preparing for a failover as and when the AZ goes down? After all, an AZ is not guaranteed to have high uptime!

      Turns out, Coinbase did not prepare for a failover for an AZ. Also from its postmortem (emphasis mine):

      "We lacked an automated ability to fail over to another availability zone. When AWS terminated EC2 instances inside our placement group at 9:29 PM ET, three of five matching-engine nodes went down and we lost quorum. There was no automated cross-zone failover. Recovery required an emergency code change shipped during the incident to remove a startup assumption that all five cluster nodes were resolvable, the creation of a new node group outside the impaired placement group, and a careful sequence to restore a 3-of-5 quorum. This allowed us to reopen markets: first cancel-only, then auction mode, and finally full trading."

      Having no automated failovers is incredibly amateurish for an operation of Coinbase 's scale. Coinbase moves about 5.2 _trillion _dollars per year, and is valued at around $40B. The outage interrupted around $7 billion-worth of financial activity, based on my napkin math.

      Back in 2016, Uber was valued at roughly as much as Coinbase, and handled circa $40-50B yearly. It had two data centers on the east and west coasts, and operated more as if it ran out of two zones. I worked at Uber at the time and there were regular failover drills to another data center (another region), in preparation should a region go down. Uber's business, in terms of the financial figures, was a fraction of Coinbase's!

      My impression of Coinbase's engineering culture has sunk after this incident, and it's almost comical that CEO Brian Armstrong is boasting that non-technical teams now ship production code, thanks to AI. This feels like the wrong thing to focus on when Coinbase's infrastructure basics seem to be in far worse shape in 2026 than Uber's were a decade ago in 2016!

      It seems Coinbase did not learn lessons after getting burned by previous regional AWS outages. In October 2025, the company suffered a three-hour- long global trading outage due to issues with AWS's DynamoDB service. Following that outage, Coinbase engineering said (emphasis mine):

      "To be better prepared in the future, we are exploring all options, including reviewing our regional deployment strategy to implement immediate and long-term fixes to reduce the impact of these types of outages."

      That process of reviewing the regional deployment strategy evidently missed or ignored the risk of a single-zone dependency of the heart of the business, with no cross-zone failover.

      Read the full The Pulse issue.

    8. 🔗 Hex-Rays Blog IDA 9.4: Smarter Navigation and Quality-of-Life Improvements rss

      IDA 9.4: Smarter Navigation and Quality-of-Life Improvements

      IDA 9.4 makes getting around a binary faster. The Jump dialog becomes smarter by default, a new Pathfinder answers reachability questions directly from the cross-reference graph, and a batch of quality-of-life fixes smooth out the everyday interface.

    9. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +1 release rss
      sync repo: +1 plugin, +1 release
      
      ## New plugins
      - [DriverBuddyReloaded](https://github.com/voidsec/driverbuddyreloaded) (2.0.0)
      
    10. 🔗 sacha chua :: living an awesome life 2026-06-22 Emacs news rss

      There was lots of discussion around Rahul's post on Emacs 31. It's the first link in the list below, so I won't repeat the links here. Also, I like visualizations, so I thought these force-directed graphs (Reddit) and text-based mindmaps (Reddit, lobste.rs) were pretty cool. Enjoy!

      Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!

      You can e-mail me at sacha@sachachua.com.

    11. 🔗 Will McGugan Stop, don’t Slop rss

      So you find a bug in an Open Source project and wish to spend your tokens solving that issue for the good of humanity. Your fingers hover over the keyboard, trembling in anticipation of the glorious prompt that will unblock your fellow developers. Before you type “FIx issue X make no mistaks” Stop!

      AI is a modern marvel, but a Thanos level click of the fingers it is not. To prompt the best fix you need context. You need to diagnose the issue while considering the broader implications of your changes. I’m a maintainer of several open source packages, and let me tell you that well over half of issue reports incorrectly attribute the source of the bug and they often have grave misunderstandings about what the correct behavior is. No matter how good your AI is, if you give it a bum steer it may produce garbage.

      I’m faced with a few options for AI PRs, which I will list in order:

      1. Review them.
      2. Merge them without a full review.
      3. Reject them.

      Option 1 takes work, especially given AI’s tendency for loquacious bloviation. To figure out if the mechanical megabrain has solved the issue correctly requires that I solve it myself. The time taken to do this dwarfs the time taken to type the prompt.

      Option 2 would work for a while. Users would be happy—for a while. But each change that strays from the big picture design or introduces an edge case or compromises an invariant, degrades the code. It’s like taking a photocopy of a photocopy. Fuck, that dates me. It’s like taking a JPEG of a JPEG.

      Option 3 makes me look like the jerk. I’m not the jerk. You are not the jerk. There is no jerk here, both have good motivations. Unless the PR was submitted by your OpenFlaw, sorry, OpenClaw. Then you are the jerk. You are spending silly money to inconvenience Open Source maintainers, and I have no time for you.

      Realistically, option 3 is the only practical solution for now.

      I’d like to clarify that I’m not an AI doomer. We developers will all have to come to terms with a new way of working. But for libraries used by millions you need to be precious about every line, and that can only be done by a knowledgeable human or an AI under supervision of such a human. If you want to use AI to contribute to any of my projects I ask that you know enough that you could have written every line, even if AI did the grunt work for you.

      Before I go, let me point out that every project described as being created by AI ships with the majority of code in dependencies created by mammalian brains; imperfect, squishy, sometimes cranky, brains consisting of water, lipids, and protein. I don’t know for how much longer that will be the case, but while it is: Stop, don’t slop.

    12. 🔗 Armin Ronacher The Coming Loop rss

      I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

      — Boris Cherny

      Over the last months I have watched more and more people build something on top of coding agents that feels meaningfully different from just using a coding agent. Some of this happens on top of Pi which is cool to see for sure! The pattern is the same everywhere though: work is put into a queue of sorts, a machine picks it up, attempts it, stops, and then some harness decides whether that was actually the end.

      If not, the harness continues the same session, injects another message, starts a fresh session with modified context, or sends the task to another machine. The task stays alive beyond the point where the model by itself would normally have said: "I am done."

      I think about that type of loop more than I want to admit.

      There is already an agent loop inside every coding agent. The model calls a tool, incorporates the result, calls another tool, reads a file, edits a file, runs tests, and eventually produces some answer. That loop is one we have been quite familiar with for a long time. The other loop is the harness level loop: the loop outside the agent loop. That loop is also not new. We have been doing versions of this since early Claude Code days, but that loop is becoming ever more present in agentic engineering and in recent weeks it has started to dominate the Twitter discourse.

      I Am Not Good At This Yet

      My current status is that I have not had much success with this way of working for code I deeply care about which turns out to be quite a lot of code.

      Part of that is taste and part of it is control. I attempt to set a high bar for what I want code to look like, and I want to understand the code I ship. Under pressure, or in a discussion with another human, I want to be able to explain what the system does without first having to ask a clanker to explain it to me. Now there is obviously a question if this desire to understand the code is one that I will still have a few years from now. For now I have not moved past the point of comprehension being important to me.

      Given this desire, there is something I lack with my experience of code written without me paying attention, particularly from loops. Present-day models tend to produce code that is too defensive, too complex, too local in its reasoning. They avoid strong invariants. They add fallbacks instead of making bad states impossible. They duplicate code, invent bad abstractions, and paper over unclear design with more machinery. Worse though: I so far see very little progress of this improving. If anything, on that front it feels to me that we might even be making steps in the wrong direction. At least for my taste, present-day hands-off harnesses like Claude Code with ultracode produce worse code than what we were producing last autumn. That's because Claude Code, with Fable for instance will be working uninterrupted on a problem for thirty minutes or more, when previously the process would have been much more human in the loop.

      Furthermore it's well understood that models tend to observe some local failure and add a local defense. Karpathy mentioned how they are “mortally terrified of exceptions”. In systems with important invariants, especially persisted data formats or core infrastructure, the right fix is not "handle every malformed case." The right fix is to make the malformed case unrepresentable or impossible to write in the first place. Yet even with a lot of manual steering, that type of code does not come out of LLMs naturally, and even if the code comes out naturally like that, they will still attempt to handle now impossible errors.

      When you take that behavior and you put it behind loops, you tend to amplify it. If each iteration adds another small defense, the system slowly becomes less understandable while appearing more robust. The more hands-off you are, the more that happens. It also teaches really bad practices when tools like this are given to juniors without clear guidance. Because if you ask them, why they are doing all that, they will convincingly argue their case.

      Where Loops Work

      At the same time, it would be dishonest to pretend the loop pattern does not work because it already works astonishingly well in some domains.

      Porting code one of them. There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust. I have used it with success myself to port MiniJinja to Go. Performance explorations are another case where this works beautifully. A machine can try experiments, benchmark them, discard failures, and keep searching. Security scanning fits naturally too and so does almost any type of research: asking a system to explore a complex problem space and report back without necessarily committing lasting code. One thing that many of these have in common is that they either do not generate new code, but transform code that already exists, or they produce code that intentionally does not have a long shelf life. They either produce proof of concepts or ideas, surface findings or are more akin to mechnical transformation.

      I believe that loops that produce artifacts without necessity of longevity or that create some form of clearly verifiable mechnical translation matters more than the general ability of a harness to mechanically measure a goal. Many successful applications of loops use another LLM as a judge or as an orchestrator. The mechnical translation case can be verified with a binary test case, but it can also be judged by an LLM instead!

      Claude Code, for instance, is increasingly good at creating entire experimental workflows that it will then execute. Sure, the code it produces is slop, but that's more the fault of the model than the harness not being a good judge on if a step in the workflow resulted in a net improvement or completion.

      The harness just needs some signal that lets it continue. It does not have to be objective or binary, it just has to be useful enough to drive another iteration.

      I absolutely love loops already that take the boring parts out of my day to experiment and measure and to give me ideas.

      Software As Organism

      On the other hand using that same looping methodology to write lasting code does not yet sit well with me. The metaphor I like to reach for is one of moving from software as a deterministic machine to software as an organism.

      I became a software engineer in an enviornment that encouraged me to understand the machine. There was always a layer you could peel off to deepen your understanding. Machines that did not exhibit deterministic observable behavior were maybe accepted, but generally seen as not exactly optimal. Software architecture-wise, I saw it as desireable to push further towards more determinism rather than less. Likewise the ability to understand the code has been an undeniable goal. In practice not always possible we still took pride in writing code so that it became possible even for new engineers to navigate complex code bases through clever architecture. On well designed systems there were always engineers that knew where the invariantes lived, which parts were load-bearing and which changes were safe. Ideally all of that was also well documented. Where that understanding was lacking, it was generally regarded as something to improve upon.

      Obviously that ideal has always been strained. Many software systems, especially very successful ones had periods where engineers on the team were able to keep them clean. Large software systems are not infrequently too big, too dynamic and too dependent on external services to fit into anyone's head. Even without LLMs we already diagnose distributed systems somewhat like doctors in that we observe symptoms, form hypotheses, "order more tests", try some remedies, and observe again.

      Yet with LLMs we're pushing much further in that direction and much quicker. We use them to write the code and we also use them for diagnosis and remedy. There are plenty of engineers that already live in a world in which the first step after the occurrence of a production issue is followed by having a clanker read logs, propose root causes and proactively put up a patch. The resulting patch is then often picked up by another machine that reviews, sometimes even landing it on main without any human supervision.

      Obviously that is powerful and I cannot deny that it sounds appealing. But giving in to that idea, particularly with less and less human oversight means accepting that we may no longer understand the whole system in the same way. We treat it, we monitor it, we stabilize it, but we do not necessarily comprehend it.

      I have no doubts that for some software, that is okay. Not every line of code deserves human authorship and worse code might have been written in the past.

      But do I want all software to be authored this way?

      You Cannot Quite Opt Out

      What's very uncomfortable is that opting out of this fully machine-driven future may not be an option.

      Security is the clearest example today. Even if you do not use loops to build your software, other people will use loops against your software. Attackers will run machines continuously and even if it's not attackers, then security researchers will and some of that automated work will throw up dust but also find real issues. And both the signal and the noise will come your way at a volume that makes it almost impossible to deal with unless you yourself throw a machine at the problem.

      Daniel Stenberg's post about curl's summer of bliss is a good example of the pressure maintainers are already under. As far as I know, AI does not play a tremendous role in the core development of curl today. Yet despite all of this, maintainers are overwhelmed by reports, most of which are now AI-generated ones.

      If attackers and reporters loop, defenders will eventually need to loop too to keep up. Maybe not to write patches directly, maybe just to triage and reproduce and pressure will increase.

      The same is true competitively as some teams will out-build others through raw speed. Some projects will suddenly move faster because a tiny group figures out how to orchestrate machines effectively. Some startups will do with five people what used to require fifty. Some people might literally put a machine against your product in a loop and ask it to "make it like the other one." And if their users are happy, does it really matter?

      Not all software will be equally affected. Some domains will punish sloppiness and demand trust and responsibility, but a lot of software lives in a world where raw speed, quick experimentation, and vast coverage matter enormously.

      Building New Dependencies

      The scariest part to me is that we become dependent on these new machines in new ways. Software has always depended on tools. I remember the time when I had to pay for compilers. These new tools are a flashback to times where creating software came with real costs. But now it's no longer a one-time payment, it's a constant dependency. Not just a dependency on a filled wallet, but also a cognitive dependency.

      If a codebase is produced by loops, reviewed by loops, patched by loops, and kept alive by loops, what happens when you no longer have access to the same class of systems? What happens when some trade restrictions take away access to the most powerful models? What if just the cost becomes unbearable? What if you and your team just lose the last remaining ability to understand the code without using the machine?

      We may create codebases that are not merely hard to maintain by humans, but that assume machine participation as part of their maintenance model. This is already happening! It's not happening everywhere, and it might not even be happening in ways that are seen as problematic, but we see more and more of it. People more and more merge code they cannot fully explain. People lose their ability to create issue reports or discuss things in chat, without augmenting or rephrasing their messages with the context provided by a clanker. Too many people increasingly rely on a machine to summarize or contextualize it. More and more do I encounter people who converse with me through the indirection of an LLM.

      Again, maybe that is not even going to be wrong, but it's a massive change to how we did things.

      Future Harnesses

      I have little doubt that this is where things are going but going there will require us to do something about our tooling everywhere, and not just in the coding agents.

      Just orchestrating more loops won't be enough. Better visualizations of changes or orchestration or agents will not restore our understanding. Either we need to find clever ways to jolt the human back into the loop and make the changes of the loops legible long term, or we need to find better ways to compose these ever more complex systems.

      This is also where my thinking about the role of Pi is changing. Pi has been cautious, and I think that caution is good. I do not want a future where every interaction turns into an uncontrolled swarm of machines making changes I cannot follow. I would not want Pi to become an unmaintainable mess in an effort to win the race towards software that writes itself and I would not want Pi to promote this type of engineering either. At the same time Pi is a harness and harnesses are at the center of people running these new types of experiments.

      Task queues for coding tasks, orchestration of agents, subagents, durable sessions will matter more and more. Even those of us who have their reservations and are not blindly embracing loops will have to start doing those experiments. We need to, because we need to understand how to make this future bounded and survivable.

      Controlling Loops

      As you can read from this post, I'm very uneasy about this future. Not cause of fear, but because of caution given experiences with this technology so far.

      Adopting the idea of harness loops means that the harness decides when work is finished. In the agent loop, the model eventually says "done" and I review. Even before that, I usually steer along the way. I am involved and I enjoy learning along the way. In the harness operated loop I'm not sure what my role even is. Even the "done" signal loses all meanings and just becomes communicated to yet another machine that judges. My role is reduced to that of a messenger.

      Today I do not like much of the code that I see from systems built that way and neither do I enjoy interacting with too much of software built with AI assistence. Looping is powerful but it removes responsibility more and more, and it at least today very much encourages us to give in to the machine.

      And yet I have no doubts that this looping future is going to be our future despite the fact that I presently resent it. I already see astonishingly small teams building at impossible speed and I see codebases turning more and more into obscure and confusing organisms that can only be diagnosed by more machines. Those codebases are simultaniously useful and messy.

      So I guess I'm coming to terms with that the question is not whether we will loop because clearly we will. Maybe the question is that in a future of loops, how do we don't abdicate judgment, how we can retain rules of good engineering, how we can ensure that responsible human can continue to supervise, how we need to re-think how we architect code to retain sanity along the way.

    13. 🔗 exe.dev Building the exe.dev iOS app rss

      If you haven't checked out our app yet, it's in the App Store. We blogged about it the other day.

      Once we decided in one of our Tuesday in-person meetings to build our iOS app, my first stop was the Stonestown Mall Apple Store, to buy the best Mac Mini I could find. (The choices were slim!) From my experience building on the web with Shelley, I knew that I needed to set up a "software workshop" (I hesitate to call this one a factory) where the agent had access to the iOS simulator and the capacity to screenshot it.

      My building blocks were as follows:

      • An exe.dev VM ("the proxy") where I could access Shelley (the coding agent) on https://proxy-vm.shelley.exe.xyz/
      • Shelley, running on the Mac mini
      • SSH -R forwarding, such that port 9999 on the proxy VM connected back to Shelley on the Mac. Since exe.dev VMs are on the Internet behind an auth proxy, this lets me access my agent from my other computers and my phone.
      • XCode and the iOS simulator
      • The entertainingly-named xcodebuildmcp-cli and a quick AGENTS.md that told Shelley about it. Shelley calls this using the bash tool. There's no MCP here; the CLI was more than enough.
      • A USB cable to install the app onto my phone once, so that future builds could be delivered over the air. (If I were to do it over again, I'd investigate Fastlane match which manages these certs.)
      • A vibe-coded over-the-air (OTA) server which serves a manifest.plist on a (required) TLS connection. This OTA server builds my tree whenever it changes, and serves a button to install the tip onto my phone over the air. Cookies aren't sent once you go into the download flow, so if you run this on exe.dev, you need to make the server public, implement auth for the index page using "Login with exe" and serve the relevant downloads obscure but unprotected. (Or you can use Tailscale if your phone and Mac are on the same Tailscale network.)
      • If you don't want to dedicate a Mac to it, you can use a Tart VM, and that's pretty smooth too. I use a Tart VM for the CI builder. We continuously deploy test builds into TestFlight Employee builds from main, because, as Dani Rojas didn't say in Ted Lasso, "CD is Life."

      The exe.dev iOS development
workshop

      Once I could ask the agent for a change from my phone, using the app (or Shelley on mobile web), and download the subsequent build to try it, the workshop was complete: I could now use the app, identify something that's bothering me, and tee it up for the agent. Iteration, for the win.

      A few more vignettes from app development:

      The app has to synchronize with all the Shelley agents. Somehow, partial synchronization of a sqlite database (what's called "incremental view maintenance" in the literature) is very much not a cookie-cutter solved problem. I used two approaches. First, for the conversation list, every time there's a sqlite commit in Shelley, Shelley re-computes the "active conversations list," compares it to the previous one, and sends a jsondiff over the connected SSE stream to the app. Because the data is small (it's bounded to hundreds of conversations) and this only happens when you're active, this is fast enough. This allows the client keep an up to date conversation list view (per VM). Within a conversation, Shelley's messages table is an append-only log with dense sequence ids. This lets the client cache messages 1-17, and, when the client realizes that we're at 20, it can fetch 18-20 and stay up to date. Shelley's web UI uses the same protocols using encrypted IndexedDB as a cache. Image attachments to LLM calls get removed and fetched asynchronously, too. (The next optimization would be to remove tool call outputs as well.) I ended up porting this "ShelleyKit" library to vanilla Swift, so that I could run its tests on Linux easily.

      As you'd expect, during development, things were often slow. I used MetricsKit to send logs back to our backend, where I would analyze them with Clickhouse. I also built debug overlays on the conversation view that showed me what was coming over the stream, and what we were redrawing, and so on. The debug build also has a built-in profiler that shows a flamegraph of what's going on. With a little bit of iteration, I'm reasonably happy with the performance of the app, though there is always much more to do.

      Your browser does not support the video tag.

      For the terminal, we'd already built a web-based terminal with persistence. That works by running your login shell under dtach and connecting to the dtach unix socket using SSH from our proxy servers. The web-based terminal uses websockets to connect to that. This provides persistent sessions that survive browser reloads, Wifi interruptions, and so on. Our iOS terminal uses the same mechanism.

      When I was collecting e-mails from our users on Discord for TestFlight, I started, from habit, clicking on a Google Form. Then, I thought to myself, "what am I doing?!?!" and spun up a VM and vibe-coded a registration app. In the end, this app managed not just the TestFlight intake, but also helped me invite people to TestFlight, and kept track of builds.

      The following shape of a prompt was valuable for finding some issues ahead of the App Review cycle.

      Look through the apple iOS app guidelines as well as our iOS app systematically, using subagents. What needs to be fixed? https://developer.apple.com/app-store/review/guidelines/

      We hope you give the iOS app a whirl!

  3. June 22, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-22 rss

      IDA Plugin Updates on 2026-06-22

      Activity:

    2. 🔗 Simon Willison Porting the Moebius 0.2B image inpainting model to run in the browser with Claude Code rss

      This morning on Hacker News I saw Moebius: 0.2B Lightweight Image Inpainting Framework with 10B-Level Performance, describing a small but effective inpainting model - a model where you can mark regions of an image to remove and the model imagines what should fill the space. The released model required PyTorch and NVIDIA CUDA, but since it described itself as 0.2B I decided to try and get it running using WebGPU in a browser. TL;DR: I got it working, and you can try the demo at simonw.github.io/moebius-web/. Read on for the details.

      The finished tool

      Here's a video demo of the finished tool:

      You can open any image in it (non-square images get letterboxed), highlight areas to remove, click the "Run inpaint" button and wait for the model to do its magic.

      A parallel agent side-project

      My main project for today was landing a major feature in Datasette: a UI for creating and altering tables, as a follow-up to the insert and edit rows feature I released last week.

      I was working on that in Codex Desktop (here's the PR) and often found myself spending 5-10 minutes spinning my fingers waiting for it to complete a mid-sized refactor or add the finishing touches to a change to the UI.

      (An amusing thing about coding agents is that the harder a problem is the more time you have to get distracted while you wait for them to finish crunching!)

      So I decided to spin up Claude Code in a terminal window and see how far I could get at porting Moebius to the web.

      Some agentic research to kick off the project

      My first step was to ask regular Claude about the feasibility of this project. In Claude.ai, which has the ability to clone repos from GitHub:

      Clone https://github.com/hustvl/Moebius/ and tell me if they published the code and weights to run this model anywhere

      (I hadn't spotted the link to the weights yet, that's tucked away in the "News" section.)

      Then:

      For Moebius what are the options for running it right now - Python and NVIDIA CUDA only or other options too?

      And:

      Muse on the feasibility of porting it to Transformers.js or similar and running it in a browser

      I like telling models to "muse on X", it's the shortest way I've found of expressing that I want them to contemplate a problem for me without providing them with a concrete goal.

      Here's that chat transcript. I copied out the last answer and saved it as research.md for Claude Code to read later.

      Claude suggested using ONNX Runtime Web on the WebGPU backend - the layer below the Transformers.js library I had suggested.

      That was enough to convince me it was worth setting Claude Code loose and seeing how far it could get.

      I usually start projects like this by gathering as much information as the coding agent might need as possible. Since I didn't expect this project to actually work I did everything in my /tmp folder:

      cd /tmp
      mkdir Moebius
      cd Moebius
      # Grab the Moebius python code
      git clone https://github.com/hustvl/Moebius
      # And the model weights (Claude figured this out):
      GIT_LFS_SKIP_SMUDGE=0 git clone \
        https://huggingface.co/hustvl/Moebius Moebius-weights
      # Finally a couple of libraries we might use:
      git clone https://github.com/huggingface/transformers.js
      git clone https://github.com/microsoft/onnxruntime

      Setting off Claude Code

      I created a directory for the rest of the project and ran git init in that so Claude could start committing code notes:

      mkdir /tmp/Moebius/moebius-web
      cd /tmp/Moebius/moebius-web
      git init
      # Copy in that research.md from earlier
      git add research.md
      git commit -m "Initial research by Claude Opus 4.8"

      I fired up a claude instance in the /tmp/Moebius folder, the level above all of the research materials I had prepared for it. I prompted:

      Read ./moebius-web/research.md - your goal is to port this model to ONNX and WebGPU so we can run it directly in a browser, with a simple UI

      As it started to work I dropped in this follow-up (typos included):

      Bulid this in /tmp/Moebius/moebius-web and commit early and often, also maintain a notes.md file in there with notes about what you figure out along the way - also start by writing out a plan.md in there and update that plan as oy work too

      I often ask agents to keep notes like this - the end result is often interesting, both for myself and for the next agent session that touches the same project. Here's what that notes.md file looked like at the end of the project.

      I kicked it off and went back to my main project, checking in occasionally to see how Claude was doing. When it looked like it might have something that worked I prompted:

      Tell me what URL I can visit in my own browser to try this

      Then I tried it out in Chrome and pasted some errors (and screenshots of errors) back into Claude Code.

      After a few rounds of this we had something that appeared to work! Time to put it on the internet so other people could use it.

      How would we publish this to Hugging Face such that the model weights were on there and the HTML demo would show up in Hugging Face spaces?

      Claude Code knows how to use the hf CLI tool, so I created a model repo on Hugging Face, then created a token that could write to that repo and dropped it into a /tmp/Moebius/token.txt file so Claude could use it.

      It published the 1.24GB of converted ONNX weights to huggingface.co/simonw/Moebius-ONNX for me.

      I'd seen other demos load weights into the browser from Hugging Face before, so I knew it was possible. I decided to host my own frontend code on GitHub Pages, so I said:

      I want to publish the moebius-web folder to GitHub, minus the large files (so maybe minus the models/ folder), such that when I turn on GitHub Pages for that repo navigating to https://simonw.github.io/moebius-web/ serves the UI

      Telling it the final URL was important in case it needed to fix the URLs in the demos that it was building so they would work when deployed to production.

      After a few more rounds of iteration, in between working on my main project, we got to a working, deployed version!

      Except... each time I reloaded the page it seemed to download ~1.3GB of model weights. Browser caching seemed pretty important for this!

      anything clever we can do with serviceworkers or similar to help cache this stuff? It seems to reload every time, I am concerned that there might be something weird about the way HF redirects work that mean we don't benefit from browser caching

      I knew that Transformers.js projects could handle this properly, so I grabbed a copy of the Whisper Web demo, dropped it into /tmp/Moebius/whisper-web and said:

      look in /tmp/Moebius/whisper-web (with a subagent) and see how they do this

      That project was entirely obfuscated, built JavaScript files so I figured using a subagent would avoid spending the rest of my top-level token context deciphering those files.

      Claude figured out that it was using caches.open("transformers-cache") - the CacheStorage API - and added that to our project.

      I've shared the full Claude Code transcript for this project (published using my claude-code-transcripts tool).

      What did I learn from all of this?

      This definitely counts as vibe coding: I didn't look at a single line of code from the project, restricting my input to testing, suggesting small feature improvements (like a progress bar for the large file downloads) and pointing the model in the direction of examples of how I wanted things to work.

      Since I didn't write any code the amount I learned about the underlying technologies - WebGPU, ONNX, and the Moebius model itself - was very limited.

      As is usually the case with this kind of project the most important things I learned concerned what was possible:

      • Claude Opus 4.8 is capable of converting a PyTorch model to ONNX, publishing the result to Hugging Face and then building out a web application and interface that can load and execute that model.
      • Chrome, Firefox and Safari are all now capable of running this kind of model - I tried it in all three.
      • The CacheStorage API works with ~1.3GB model files.
      • ... which means we can have inpainting as a feature of a client-only web application! (If our users can tolerate the 1.3GB download.)

      I felt like I should probably try and learn a little more about my project. I fired up Claude.ai and prompted:

      Clone https://github.com/simonw/moebius-web/ and use it to teach me all about the model and ONNX and the process of converting a model to ONNX and WebGPU and basically everything I'd need to know in order to fully understand this repo

      Here's the transcript and the understanding.md Markdown file it created, which I've now added to the GitHub repo. I found the explanation of ONNX particularly enlightening:

      ONNX (Open Neural Network Exchange) is a portable, framework-neutral file format for neural networks. An .onnx file is essentially two things bundled together:

      1. A computation graph — a directed graph of nodes, where each node is an operator (Conv, MatMul, Add, Einsum, Softmax, Gather, Resize, …) wired together by named tensors flowing between them. This is the "recipe" for the forward pass.
      2. The weights — the learned parameter tensors (the convolution kernels, the embedding table, etc.), stored as initializers in that same graph.

      Crucially, ONNX describes what to compute, abstractly, without saying how or on what hardware. The operator set is versioned by an opset number (this repo uses opset 18), which pins down exactly which operators exist and what their semantics are.

      It turns out PyTorch has built in mechanisms for exporting to ONNX, as seen here in export_onnx.py:

      torch.onnx.export(
          dec, (lat,), dec_path, opset_version=args.opset,
          input_names=["latent"], output_names=["image"],
          dynamic_axes={"latent": {0: "B"}, "image": {0: "B"}},
      )

      Claude also included a handy glossary and an only-slightly-broken ASCII-art diagram showing how the model pipeline fits 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.

    3. 🔗 tomasz-tomczyk/crit v0.16.5 release

      What's Changed

      Hotfix for v0.16.4: on finishing a review round, we now again include the full comment payload from review.json (including dom_anchor, replies, and other fields). The finish modal copy prompt is also clearer for agents, with an explicit crit comments --json path and a single next-command line when changes are requested.

      Fixes

      Full Changelog : v0.16.4...v0.16.5

    4. 🔗 anthropics/claude-code v2.1.186 release

      What's changed

      • Added claude mcp login <name> and claude mcp logout <name> to authenticate MCP servers from the CLI without opening the interactive /mcp menu, with --no-browser stdin redirect support for completing over SSH
      • Added status filtering (press f) to the /workflows agent detail view
      • Added a "Skills" section to the /plugin Installed tab
      • Added teammateMode: "iterm2" setting with a warning when auto mode cannot find the it2 CLI
      • Added "Claude Platform on AWS - refresh credentials" option to /login when awsAuthRefresh is configured
      • ! bash commands now trigger Claude to respond to the output automatically; set "respondToBashCommands": false in settings.json to keep the previous context-only behavior
      • Fixed streaming requests failing with "Content block not found" or JSON parse errors after the machine wakes from sleep
      • Fixed subagent transcript scroll position bleeding into the main transcript on exit
      • Fixed background task previews flashing raw tool names before the agent's plan loaded
      • Fixed Chrome tab-group isolation not applying when the in-product permissions gate is off for concurrent CLI sessions
      • Fixed background session recaps being duplicated; the agent's own end-of-turn summary now shows as the recap line
      • Fixed opening a background session from claude agents leaving the previous screen painted behind it
      • Fixed Agent(type) deny rules and Agent(x,y) allowed-types restrictions not being enforced for named subagent spawns
      • Fixed Esc and Ctrl+C not responding while background agents are still running after the main turn ends
      • Fixed misaligned option numbers in permission prompts when the option text overflows
      • Fixed pressing x on a finished subagent in the agent panel not dismissing it
      • Fixed a misleading "MCP server disconnected" notice for intentionally retired tools when resuming older sessions
      • Fixed /plugin Installed showing a "more above" indicator when already scrolled to the top
      • Fixed ~~strikethrough~~ showing literal tildes in assistant messages instead of rendering as strikethrough
      • Fixed --tools allowing feature-gated tools to slip through before flags loaded on a cold first launch
      • Fixed background job status in claude agents showing a stale "needs input" message after replying
      • Fixed a dark-theme flash when opening a background session from claude agents on a light terminal
      • Fixed mouse-selected text staying highlighted after deleting it in claude agents
      • Fixed session cost not showing for usage-based Enterprise and Team subscribers
      • Fixed agent teams: teammates spawned via tmux/pane backends now inherit the leader's --effort level
      • Fixed Workflow agent({schema}) subagents looping forever on repeated schema validation failures instead of aborting after 5 attempts
      • Improved claude mcp get and claude mcp remove to suggest the closest configured server name on a typo and truncate long server lists
      • Improved memory: the agent is now reminded to compact its MEMORY.md index when nearing the size limit
      • Improved skill frontmatter: display-name, default-enabled, fallback, and metadata.* keys now accept kebab-case, snake_case, and camelCase
      • Improved malformed SKILL.md YAML frontmatter handling: loads the skill body with empty metadata instead of failing silently
      • Changed CLAUDE_CODE_MAX_RETRIES to cap at 15; for unattended sessions, use CLAUDE_CODE_RETRY_WATCHDOG instead
      • Changed background subagents to surface permission prompts in the main session instead of auto-denying; the dialog shows which agent is asking, and Esc denies just that tool
      • Changed /review <pr> to use the same review engine as /code-review medium
    5. 🔗 r/reverseengineering VAXD - 1.60 rss
    6. 🔗 r/reverseengineering CAN bus reverse engineering with AI [Claude Code] rss
    7. 🔗 @HexRaysSA@infosec.exchange IDA 9.4 pre-release teasers continue. mastodon

      IDA 9.4 pre-release teasers continue.

      This week: a dramatically improved Dyld Shared Cache workflow. No more loading the entire DSC just to keep cross-references intact. IDA 9.4 brings on-demand loading, fluid navigation, new specialized widgets, and a clean API usable by both humans and agents.

      👉 https://hex-rays.com/blog/ida-9.4-apple-dyld-shared-cache-workflow- improvements

    8. 🔗 Confessions of a Code Addict How Big Is a Physical Address? rss

      This is a short aside in our virtual memory series. We have talked extensively about the size of a virtual address and the virtual address space, but we haven't yet looked at the size of a physical address.

      As you might expect, physical addresses on x86-64 are smaller than 64 bits. But they are also not necessarily the same size as virtual addresses. In this video, we look at how big physical addresses are, how you can check this on your own machine, and why different processors may expose different physical address sizes.

      If you haven't read the virtual memory article, do check it out. You can also download the ebook as a PDF from the link below.

      Get the ebook

      Read more

    9. 🔗 tomasz-tomczyk/crit v0.16.4 release

      What's Changed

      Internal refactors

      New Contributors

      Full Changelog : v0.16.3...v0.16.4

    10. 🔗 backnotprop/plannotator v0.21.1 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.21.0 | Direct document editing in annotate mode, live git-status file tree, in-app agent terminal, open files in external apps, HTML renders as HTML
      v0.20.3 | Annotations no longer lost when clicking away, off-screen indicator for open comments
      v0.20.2 | Pierre CodeView all-files review, large-PR pipeline and instant-open checkout, unified agent engine selection, Pi programmatic plan mode
      v0.20.1 | Pi extension install hotfix (pinned @pierre/diffs after a broken upstream release)
      v0.20.0 | Multi-repo workspace reviews, semantic diff overview, UI 2.0 themes and plan look chooser, leaner single-source skill install
      v0.19.27 | Kiro CLI integration, Glimpse native window, annotate-last message picker
      v0.19.26 | Amp plugin production fixes, Mermaid rendering fix, Settings flicker fix, update notification toast and shimmer
      v0.19.24 | Amp integration, configurable data directory, Auto Mode permission option, Pi plan approval fix
      v0.19.23 | Droid integration, Windows Pi AI fix, quieter update indicator
      v0.19.22 | Safari copy fix in plan viewer, CLAUDE_CONFIG_DIR support for session logs
      v0.19.21 | Ask AI in plan review and annotate mode, shared AI runtime, origin-aware provider defaults


      What's New in v0.21.1

      A single-fix patch release. Annotating the last assistant message could open a blank page in any conversation with more than one response. This release fixes that.

      Annotate-Last No Longer Blanks on Multi-Message Sessions

      Running /plannotator-last (or plannotator last) opened a blank page whenever the session had two or more recent assistant messages. With zero or one message it worked, so it looked intermittent, but it was deterministic: the failure tracked message count. It was most visible on the Pi extension, where multi-turn sessions are the norm.

      The cause was a React rendering bug. When the annotate UI assembled the feedback payload during render, it reached a helper that wrote component state as a side effect. Because that state was a freshly built map on each pass, React never settled, hit its re-render limit, and threw before drawing anything, leaving an empty page. The fix makes that render-path helper a pure read of the same data, so the work that belongs at submit time no longer fires during render. The exported feedback is unchanged; the page renders.

      PR #950 closing #949, reported, diagnosed, and fixed by @emmaneugene.

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Extra skills (compound, setup-goal, visual-explainer), opt-in:

      npx skills add backnotprop/plannotator/apps/skills/extra
      

      Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".

      OpenCode: Clear cache and restart:

      rm -rf ~/.bun/install/cache/@plannotator
      

      Then in opencode.json:

      {
        "plugin": ["@plannotator/opencode@latest"]
      }
      

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension
      

      Droid: Install via the plugin marketplace:

      droid plugin marketplace add backnotprop/plannotator
      droid plugin install plannotator@plannotator
      

      Amp: Install the CLI first, then copy the plugin:

      mkdir -p ~/.config/amp/plugins
      curl -fsSL https://raw.githubusercontent.com/backnotprop/plannotator/main/apps/amp-plugin/plannotator.ts \
        -o ~/.config/amp/plugins/plannotator.ts
      

      Kiro CLI: The installer auto-detects Kiro and installs skills automatically. After installing the CLI, launch with:

      kiro-cli chat --agent plannotator
      

      Upgrading from before v0.20.0? Read the v0.20.0 release notes first; that release changed how skills install.


      What's Changed

      • fix(editor): stop setState-during-render loop in multi-message annotate by @backnotprop in #950

      Community

      Thanks to @emmaneugene, who reported the blank-page regression in #949, traced it to the exact render-path state write, and supplied the fix that this release ships.

      Full Changelog : v0.21.0...v0.21.1

    11. 🔗 earendil-works/pi v0.79.10 release

      New Features

      • Extension compaction event context - Extension session_before_compact and session_compact events now include reason and willRetry, so extensions can distinguish manual /compact, threshold auto-compaction, and overflow retry flows. See session_before_compact / session_compact and Custom Summarization via Extensions.
      • Safer update flow - pi update installs the exact checked Pi version, and update notices show the changelog URL, making upgrades more predictable. See Install and Manage.

      Added

      • Added reason and willRetry metadata to extension session_before_compact and session_compact events so extensions can distinguish manual, threshold, and overflow compaction flows (#5962 by @PizzaMarinara).

      Fixed

      • Fixed the find tool to respect nested git repository boundaries when parent .gitignore rules ignore the nested repo (#5960).
      • Fixed the usage docs slash command table to include /trust and /import (#5959).
      • Fixed inherited OpenAI-compatible streaming to preserve encrypted reasoning_details that arrive before matching tool call deltas (#5114).
      • Fixed broken TUI documentation links to the plan-mode extension example (#5957).
      • Fixed transient extension UI and session-start messages emitted during session replacement or reload so they remain visible, and kept reload input blocked until reload completes (#5943).
      • Fixed the plan-mode example to preserve active custom tools, skip the action prompt when no plan is found, and queue refinement/execution follow-ups correctly from agent_end (#5940).
      • Fixed pi update to install the exact version returned by the Pi update check, make --force reinstall that checked version, fail instead of falling back to an unversioned reinstall when no version is available, and report both the old and updated versions.
      • Fixed update notifications to display the actual changelog URL as the hyperlink text.
    12. 🔗 r/reverseengineering AirPlay 2 realtime audio sender, the encrypted RAOP/RTSP path reconstructed and documented rss
    13. 🔗 r/reverseengineering /r/ReverseEngineering's Weekly Questions Thread rss

      To reduce the amount of noise from questions, we have disabled self-posts in favor of a unified questions thread every week. Feel free to ask any question about reverse engineering here. If your question is about how to use a specific tool, or is specific to some particular target, you will have better luck on the Reverse Engineering StackExchange. See also /r/AskReverseEngineering.

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

    14. 🔗 r/reverseengineering HexWalk 2.1.0 Hex analyzer new release, new light theme, export analysis to csv, works both on Windows, Linux and MacOs, give it a try! rss
    15. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +1 release rss
      sync repo: +1 plugin, +1 release
      
      ## New plugins
      - [oh-my-dump](https://github.com/nevergiveupcpp/oh-my-dump) (1.0.15)
      
    16. 🔗 r/reverseengineering JavaScript Obfuscator rss
  4. June 21, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-21 rss

      IDA Plugin Updates on 2026-06-21

      New Releases:

      Activity:

      • atelier
        • f9876a21: fix(web-fetch): allow loopback and nonstandard ports
        • 743aea4a: feat(search): honest-empty verdicts to stop retrieval spirals
        • 2b39647e: chore: bump landing submodule (checkout, license flow, device manager)
        • af644844: feat(licensing): self-service device management (CLI + web magic-link)
        • 0f4a13b9: docs(contributing): add CLA and CLA-assistant workflow
        • e58f7269: feat(bench): sandbox egress guard and harbor agent updates
        • e2047308: feat(licensing): device-bound leases with auto-refresh and 3-device l…
        • 7d8108fb: refactor(doc-sync): slim agent-context generator and unify managed ma…
        • 4ade68fa: refactor(mcp): consolidate code-intel tools into explore
        • d295eaa4: chore(license): relicense under FSL-1.1-ALv2
      • disrobe
        • 0926b0b3: bump py recovery to 93.45% (5874/6286); update svgs
        • d36baae4: guard loop detection against else-arm misidentification and fix fused…
        • ef7dc095: regenerate recovery/card/verification svgs for py 93.05 bump
        • a95df9d6: recover dropped else branch when a guarded try is followed by a plain…
        • 5c2e53a0: add missing semicolon in nir-lift python emitter (clippy semicolon_if…
        • bd3334ff: extend arg-rest oracle with boa-graded leading-param shift cases (fun…
        • ca8543ea: remove stray UnaryOperator import from arg_rest.rs (unused after walk…
        • a38f4a96: rescue a try block preceded by a conditional guard into a guarded-try…
        • c68e5967: extend bracket_to_dot/literal_logic/template_literal walkers to cover…
        • e68b733f: pin the per-method javac recompile floor to 122/131 now that the reus…
        • e716daac: harden the go buildinfo pointer-form decode with explicit ptr-size bo…
        • d85546f2: split a local slot that holds a reference value and a primitive value…
        • 933f28f5: split a local slot that holds a reference value and a primitive value…
        • 18c7c78f: recover go modulename from the buildinfo blob, decode 32-bit abi type…
        • 9b8bc0e1: undo bundler export aliasing: rename a local binding to the name in `…
        • 2044ce4d: declare a local object when it holds both a constructed value and a c…
        • 959d7bf3: undo bundler import aliasing: restore the developer name from `import…
        • 15608126: recover the babel _createForOfIteratorHelper loop to for…of, runnin…
        • 65738ad2: apply rustfmt across all crates that diverged from fmt canonical
        • 6ca94bf1: apply rustfmt to disrobe-nir and disrobe-query
      • doki-ida
        • bd337e40: Update the theme now automatically crawl
      • NexusRE-MCP
        • 4825ef77: fix: Phase 0-2 architectural overhaul — runtime crashes, cache/sessio…
      • oh-my-dump
        • d75ba667: fix: make HCLI package pass lint
        • 0162fda9: Merge pull request #2 from nevergiveupcpp/dev
        • f76ca8e7: feat: add HCLI support
        • 7afef692: docs: update README
      • PseudoForge
        • db3109ea: docs: update README for temp provenance reporting
        • a75c6953: test: cover address taken temp provenance blockers
        • b503a16e: feat: strengthen temp base provenance reporting
        • 9c14c12f: feat: add cleanup integrity QA gate
        • 726eddad: feat: add dense structural hints
        • 743a7dc1: fix: clear stale llm fallback artifacts
        • 9c0eb6e2: fix: suppress risky unassigned llm renames
        • b1788466: fix: preserve multiline wrapped statements
        • 56b8ab95: feat: track indexed callback corpus evidence
        • 1ce6015e: feat: score indexed callback layout evidence
        • 3156ab47: feat: report indexed callback layout evidence
        • 8e5f5c84: feat: emit opaque target replay eas
        • 1c88af25: feat: group opaque merge targets
        • 074099d9: feat: report opaque merge call targets
        • 1729cc84: feat: classify parameter merge provenance
        • cde94c07: feat: expose merge provenance classes
        • eb014955: feat: report allocation null dominance metrics
        • c06ad448: feat: report call result equivalence metrics
        • e35146a8: feat: report temporary merge provenance metrics
        • 6b1339eb: fix: mask offset derefs in provenance comments
      • server_info
    2. 🔗 Simon Willison sqlite-utils 4.0rc1 adds migrations and nested transactions rss

      sqlite-utils is my combined Python library and CLI tool for working with SQLite databases. It provides an extensive set of higher-level operations on top of Python's default sqlite3 package, including support for complex table transformations, automatic table creation from JSON data and a whole lot more.

      I released sqlite-utils 4.0rc1, the first release candidate for sqlite-utils v4. The major version bump indicates some (minor) backwards incompatible changes, so I'm interested in having people try this out before I commit to a stable release.

      New feature: migrations

      There are two significant new features in this RC compared to the previous 4.0 alphas.

      The first is support for database migrations. This isn't a completely new implementation - it's a slightly modified port of the sqlite-migrate package I released a few years ago. I think that package has proved itself over time, so I'm now ready to bundle it with sqlite-utils directly.

      Here's what a set of migrations in a migrations.py file looks like:

      from sqlite_utils import Database, Migrations
      
      migrations = Migrations("creatures")
      
      @migrations()
      def create_table(db):
          db["creatures"].create(
              {"id": int, "name": str, "species": str},
              pk="id",
          )
      
      @migrations()
      def add_weight(db):
          db["creatures"].add_column("weight", float)

      This defines a set of two migrations, one creating the creatures table and another adding a column to it.

      You can then run those migrations either using Python:

      db = Database("creatures.db")
      migrations.apply(db)

      Or with the command-line migrate command:

      sqlite-utils migrate creatures.db migrations.py

      The system is deliberately small: it doesn't provide reverse migrations, so any mistakes you make should be fixed by deploying a fresh migration to undo them.

      Its predecessor has been used by LLM and various other projects for several years, so I'm confident that the design is stable and works well.

      The new migrations feature is documented here.

      New feature: db.atomic() transactions

      This feature is a lot less exercised than migrations, so it deserves more attention from testers.

      Previously, sqlite-utils mostly left transaction management up to its users, via a with db.conn: construct that reused the sqlite3 mechanism directly.

      SQLite supports nested transactions in the form of savepoints, so I wanted an abstraction that could make those as easy to use as possible.

      I borrowed the terminology "atomic" from Django and Peewee. Here's what the new API looks like:

      with db.atomic():
          db.table("dogs").insert({"id": 1, "name": "Cleo"}, pk="id")
          try:
              with db.atomic():
                  db.table("dogs").insert({"id": 2, "name": "Pancakes"})
                  raise ValueError("skip this one")
          except ValueError:
              pass
          db.table("dogs").insert({"id": 3, "name": "Marnie"})

      More details in the documentation.

      Backwards incompatible changes

      The backwards incompatible changes in v4 were described in the alpha release notes. For 4.0a0:

      • Upsert operations now use SQLite's INSERT ... ON CONFLICT SET syntax on all SQLite versions later than 3.23.1. This is a very slight breaking change for apps that depend on the previous INSERT OR IGNORE followed by UPDATE behavior. (#652)
      • Python library users can opt-in to the previous implementation by passing use_old_upsert=True to the Database() constructor, see Alternative upserts using INSERT OR IGNORE.
      • Dropped support for Python 3.8, added support for Python 3.13. (#646)
      • sqlite-utils tui is now provided by the sqlite-utils-tui plugin. (#648)
      • Test suite now also runs against SQLite 3.23.1, the last version (from 2018-04-10) before the new INSERT ... ON CONFLICT SET syntax was added. (#654)

      And for 4.0a1:

      • Breaking change: The db.table(table_name) method now only works with tables. To access a SQL view use db.view(view_name) instead. (#657)
      • The table.insert_all() and table.upsert_all() methods can now accept an iterator of lists or tuples as an alternative to dictionaries. The first item should be a list/tuple of column names. See Inserting data from a list or tuple iterator for details. (#672)
      • Breaking change: The default floating point column type has been changed from FLOAT to REAL, which is the correct SQLite type for floating point values. This affects auto-detected columns when inserting data. (#645)
      • Now uses pyproject.toml in place of setup.py for packaging. (#675)
      • Tables in the Python API now do a much better job of remembering the primary key and other schema details from when they were first created. (#655)
      • Breaking change: The table.convert() and sqlite-utils convert mechanisms no longer skip values that evaluate to False. Previously the --skip-false option was needed, this has been removed. (#542)
      • Breaking change: Tables created by this library now wrap table and column names in "double-quotes" in the schema. Previously they would use [square-braces]. (#677)
      • The --functions CLI argument now accepts a path to a Python file in addition to accepting a string full of Python code. It can also now be specified multiple times. (#659)
      • Breaking change: Type detection is now the default behavior for the insert and upsert CLI commands when importing CSV or TSV data. Previously all columns were treated as TEXT unless the --detect-types flag was passed. Use the new --no-detect-types flag to restore the old behavior. The SQLITE_UTILS_DETECT_TYPES environment variable has been removed. (#679)

      Try it out

      You can install the new RC like this:

      pip install sqlite-utils==4.0rc1

      Or try the CLI version directly with uvx like this:

      uvx --with sqlite-utils==4.0rc1 sqlite-utils --help

      Come chat with us about it in the sqlite-utils Discord channel, or file any bugs in GitHub Issues.

      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. 🔗 r/reverseengineering Scrutari - forensic statistical analyzer for opaque firmware blobs rss
    4. 🔗 Confessions of a Code Addict What Does a Page Table Entry Actually Store? rss

      This is the 5th video in our virtual memory series. In the previous video, we learned about the page table and how the hardware performs a page table walk to do address translation. But merely finding the physical frame address in the page table is not sufficient for the hardware to do a memory access. It also needs to do certain additional checks to make sure that the access is valid. For example, it has to ensure that the page table mapping itself is valid (e.g., the page might have been swapped). Similarly, when doing a memory write, the hardware has to ensure that the page(s) are writable.

      All these checks are done during address translation by looking up additional metadata stored against the page table entry. In this video, we cover what all these metadata bits needed by the hardware are, what their purpose is, and how they are stored in the page table.

      In the next video, we will discuss demand paging. In the meantime, if you haven't yet read the VM article, please do. And if you prefer reading it offline, get the ebook from the link below.

      Get the ebook

      Read more

    5. 🔗 r/reverseengineering Reverse once, run forever: designing client-side defenses that assume the attacker has already read every line rss
    6. 🔗 r/reverseengineering I reverse engineered Windows Copilot into a free OpenAI compatible API (GPT-4o, no API key, no billing) rss
    7. 🔗 r/reverseengineering NØW — Word-Based Shellcode Encoder rss
    8. 🔗 r/reverseengineering Note20 ABL Odin out-of-bounds read rss
    9. 🔗 Mitchell Hashimoto Pledging Another $400,000 to the Zig Software Foundation rss
      (empty)
    10. 🔗 Jamie Brandon 0060: SF rss
      (empty)