🏡
  • ↔
  • →

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

generated: June 25, 2026 at 20:33:52

  1. June 25, 2026
    1. 🔗 threatray/plugin-ida v3.0.2 release

      What's Changed

      • fix: Use markdown image syntax for hex-rays store rendering by @jray0 in #9
      • chore(deps): Bump step-security/harden-runner from 2.19.0 to 2.19.4 by @dependabot[bot] in #12
      • chore: add uv cooldown (exclude-newer=7 days) by @jray0 in #13
      • chore(deps): Bump actions/checkout from 6.0.2 to 6.0.3 by @dependabot[bot] in #14
      • chore(deps-dev): Update mypy requirement from ~=1.10 to >=1.10,<3.0 by @dependabot[bot] in #15
      • chore(deps): Bump actions/checkout from 6.0.3 to 7.0.0 by @dependabot[bot] in #16
      • fix: Pick PySide6 directly on IDA 9.2+ to avoid PyQt5 shim by @jray0 in #17
      • chore: Release v3.0.2 by @jray0 in #18

      Full Changelog : v3.0.0...v3.0.2

    2. 🔗 huggingface/candle 0.10.2 release

      v0.10.2

    3. 🔗 @HexRaysSA@infosec.exchange IDA 9.4 teasers continue with two new navigation features: mastodon

      IDA 9.4 teasers continue with two new navigation features:
      1️⃣ Jump Anywhere is now the default G dialog — search functions, names, types, and segments in one box with live previews.
      2️⃣ Pathfinder, a new tool for asking "can this code reach that?" directly from the xref graph.

      Read the blog for the full breakdown.
      👉 https://hex-rays.com/blog/ida-9.4-smarter-navigation-and-quality-of-life- improvements

    4. 🔗 MetaBrainz Upcoming changes to user accounts and authentication rss

      We are in the process of moving user accounts, authentication and OAuth applications from the MusicBrainz website to the MetaBrainz website.
      This centralizes our account management between all the *Brainz projects, along with some security improvements.

      Historically, all accounts were managed on the MusicBrainz website simply because it existed before the MetaBrainz Foundation itself. However, creating a MusicBrainz account just to use ListenBrainz or our other sister projects doesn't make much sense.
      We are changing this legacy setup to improve the user experience and bring better cohesion to the entire MetaBrainz ecosystem.

      New MetaBrainz login page

      Here is what you need to know about how this transition affects you:

      Changes for users

      If you use MusicBrainz, ListenBrainz, BookBrainz or any other *Brainz project, most of your experience won't change. However, note the following updates:

      • Account login/creation: When logging in or creating a new account, you will be redirected to the MetaBrainz website to complete the process.
      • Login page localization: We are currently translating the new login pages. Your preferred language might not be fully available yet while this work is in progress. If you can help with translation, please head over to our translation platform.
      • Digest authentication in the web service (API) is deprecated:
        • Existing users: If you already use digest authentication, it will continue to work normally for the time being, using whatever account password you had at the time of the migration.
        • Password changes: If you update your account password, the new password cannot be used for digest authentication. (The old password will continue to work until you generate a token; see below.)
        • Digest authentication tokens: We're adding support for tokens which can be generated from the Applications page. The token should be used in place of your account password in applications that ask for it. As a user, it's strongly recommended that you generate a token if you're currently providing your account password to an application.
        • New users: Digest authentication is disabled by default. New users must generate a digest authentication token from the Applications page.

      Changes for developers

      If you maintain an application or script that integrates with MusicBrainz, you will need to update your authentication flow:

      • OAuth applications : the OAuth applications page will move to the MetaBrainz website after the migration: https://metabrainz.org/profile/applications
      • New auth URLs: The endpoints for authentication are migrated as well. You will need to update these base URLs in your code: https://**music** brainz.org/oauth2/... -> https://**meta** brainz.org/oauth2/...
      • Existing OAuth applications currently set up on musicbrainz.org are deprecated. They will continue to work through the https://musicbrainz.org/oauth2/ endpoint for the time being, but will not be migrated to MetaBrainz OAuth. New applications must be created on MetaBrainz.
      • Mandatory PKCE: Proof Key for Code Exchange (PKCE) is now mandatory for all OAuth flows to ensure better security.
      • Drop digest auth: Move your applications from legacy digest authentication to OAuth. As a transitional measure, you can inform your users about generating a digest auth token.

      ⚠ Note on

      DIGEST Auth TOKENS

      While MusicBrainz digest authentication tokens will be supported as a transitional measure, they will be removed in the future. OAuth is strongly preferred and recommended for all applications.

      Timeline

      • Monday July 6th : account migration
        • We will have a short downtime for all MetaBrainz services while we transfer user accounts
      • July 1st 2027 : 1 year after the migration, digest authentication and MusicBrainz Oauth apps will be removed
        • The deprecated digest authentication will be retired and this authentication flow will stop working. Please migrate your applications to use OAuth.
        • Existing OAuth applications created on MusicBrainz will stop working. Please create a new OAuth application on MetaBrainz

      If you run into issues or have questions, do let us know on the community forums or reach out on Matrix/Discord/IRC.

    5. 🔗 backnotprop/plannotator v0.21.2 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.21.1 | Annotate-last blank-page fix on multi-message sessions
      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

      What's New in v0.21.2

      Six PRs land in this release, with most of the work going into code review. You can now run your own Agent Skills as review profiles, and the review engine picker gains two new options — Cursor and OpenCode — alongside the existing Claude and Codex paths. A draft-persistence bug that resurrected deleted annotations is fixed, and Codex users get two improvements from a first-time contributor.

      Custom Reviews as Agent Skills

      Until now the code review engine ran a fixed review prompt. This release lets you point a review at any Agent Skill you already have installed. Enable a skill as a review profile and the agent runs that skill's instructions against your diff instead of the built-in prompt, so a security skill, a style-guide skill, or any review methodology you've written becomes a one-click review.

      Findings also gained two new shapes. A review can now attach a finding to an entire file rather than a specific line, and it can raise a general finding that applies to the whole changeset instead of any single location. Whole-file and general findings render in their own sections and flow through to the exported feedback the agent receives, so nothing a reviewer raises gets dropped because it didn't map to a line.

      PR #955, by @backnotprop.

      Cursor and OpenCode Review Engines

      The review engine selection now includes Cursor and OpenCode in addition to Claude and Codex. Both run through a unified "marker" protocol: the agent runs its own CLI (agent for Cursor, opencode run for OpenCode) against your changes and returns findings in a delimited block that Plannotator parses back into annotations. The engines are opt-in and only appear when their CLI is installed, and they share the same finding pipeline as the existing engines, so whole-file and general findings work across all four.

      PR #959, by @backnotprop.

      Deleted Review Annotations Stay Deleted

      In code review, deleting an annotation and then refreshing the page brought it back. The draft autosave kept the last saved copy, and a deletion wasn't being persisted as a real edit, so the next load restored the annotation the user had removed. This release records deletions with a generation tombstone so they survive a refresh and a late autosave can't revive them, while leaving genuine drafts intact.

      PR #951 closing #948, reported by @alexanderkreidich.

      Codex Ask AI Outside Git Repos

      Ask AI on the Codex provider assumed it was running inside a git repository and failed when it wasn't. It now probes for a working tree and skips the git- repo check when there isn't one, so Ask AI works in plain directories that aren't under version control.

      PR #965, by @ericclemmons.

      Codex Desktop Review URL Surfacing

      When Plannotator runs inside the Codex desktop app, the session URL wasn't easy to find. It now prints the review URL to the terminal when it detects the Codex desktop host, so the link is visible instead of buried.

      PR #966, by @ericclemmons.

      Additional Changes

      • Landing page section order — the capabilities section now sits above the demos on the marketing site. PR #953, by @backnotprop.

      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(review): persist annotation deletions so they don't resurrect on refresh by @backnotprop in #951
      • feat(marketing): restructure landing page section order by @backnotprop in #953
      • feat(review): custom reviews as Agent Skills + whole-file/general findings by @backnotprop in #955
      • feat(review): Cursor + OpenCode review engines (unified marker-review) by @backnotprop in #959
      • Allow Codex Ask AI outside git repos by @ericclemmons in #965
      • Improve Codex App review URL discoverability by @ericclemmons in #966

      New Contributors

      Contributors

      @ericclemmons landed two Codex improvements in his first contributions to the project: making Ask AI work outside git repositories in #965, and surfacing the review URL when running inside the Codex desktop app in #966.

      Thanks to @alexanderkreidich, who reported in #948 that deleted review annotations reappeared after a refresh — the bug this release fixes.

      Full Changelog : v0.21.1...v0.21.2

    6. 🔗 KasperskyLab/hrtng v3.9.105 release

      Added

      • deinline new modes:
        • split head and exit blocks (#45);
        • very short inlines are cut from inside a single block (#54)
        • inlines loading from work-folder too
        • keep compatibility with earlier inlines library
      • Force update hex-rays's global xrefs cache on "Create MSIG file" in "All user named functions" mode, this reduces re-decompilation time when you need "Global xrefs" update;

      Changed

      • Var reuse: manual mode if nothing found;
      • Unflattening:
        • assign variable pointer mode
        • message when unflattening is failed

      Removed

      • deinline FIND_MATCHED_PATHS mode
      • "Jump to visited indirect call... (Shift-J)" removed as duplicate, now jump by double-click/Enter-key on auto-comment

      Fixed

      • Autorename: ban C++ mangled vftable names (#58)
      • Fix unflatterer looping and register size issues
      • Fix "Auto turn on 'Functions' window synchronisation" broken in IDA 9.3
      • Fix crash on "Decompile obfuscated code Alt-F5", fix proc deletion and nav history;
      • Fix "name-to-type" for union types;
    7. 🔗 r/LocalLLaMA NVIDIA has released Nemotron-TwoTower-30B-A3B-Base-BF16, an unusual diffusion-based language model built from the Nemotron 3 Nano 30B-A3B backbone. rss

      NVIDIA has released Nemotron-TwoTower-30B-A3B-Base-BF16, an unusual diffusion-based language model built from the Nemotron 3 Nano 30B-A3B backbone. | NVIDIA has released Nemotron-TwoTower-30B-A3B-Base-BF16, an unusual diffusion-based language model built from the Nemotron 3 Nano 30B-A3B backbone. Instead of generating strictly one token at a time, it uses a frozen autoregressive context tower plus a diffusion denoiser tower that iteratively fills blocks of tokens in parallel. NVIDIA says its default mask-diffusion setup retains 98.7% of the autoregressive baseline’s aggregate benchmark quality while reaching 2.42× its wall-clock generation throughput. submitted by /u/nikhilprasanth
      [link] [comments]
      ---|---

    8. 🔗 r/LocalLLaMA If LLMs are so good at coding… rss

      How come things like ROCm and the intel stack aren’t able to rapidly improve their software ecosystems to be a match for CUDA? Until the software from other vendors catches up with NVIDIA, they’re always going to get away with charging a massive premium on their “it just works” products.

      This is a genuine question, I’m using NVIDIA and Apple Silicon for my AI adventures thus far, but like everyone else on this subreddit, I want the prices to be more affordable. They won’t get that way until there is genuine competition in the market.

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

    9. 🔗 Andrew Healey's Blog A Tiny Compiler for Data-Parallel Kernels rss

      Exploring how compilers lower ordinary loops into explicit data-parallel kernels.

    10. 🔗 Rust Blog The many journeys of learning Rust rss

      This is another post in our series covering what we learned through the Vision Doc process. We previouslydescribed the overall approach and what we learned about doing user research, we explored what people love about Rust, dug into what it takes to ship safety-crticial Rust, and described some of the major challenges that people face when using Rust.

      In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.

      As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.

      Many paths to needing Rust

      The interviews surfaced several different paths into Rust: curiosity, embedded work, job-market pressure, organizational adoption, and reassignment after a team or company chose Rust. That last path matters because many learners are not evaluating Rust from a blank slate; they are trying to become productive after Rust has already arrived in their work.

      "Funny enough, I've advocated for more niche languages than Rust in the past. Rust has pretty much stopped being as much of a niche language as it was, but it's not Java." -- Fractional CTO

      Rust learning resources

      Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.

      "I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier

      Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.

      "The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant

      "Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage

      These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.

      "We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry

      Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.

      Beginner stumblings and unlearning habits

      It's pretty typical for Rust to be the 2nd, 3rd or Nth programming language that someone picks up. They'd end up writing their most familiar language in Rust, whether C++ patterns, Java patterns, or whatever they knew, for months or even years. Eventually they got comfortable enough to start writing idiomatic Rust.

      "There's a bit of a drop in productivity compared to C if you're already familiar with it just because you're learning new rules, new syntax." -- Principal Firmware Engineer (mobile robotics)

      "In the beginning it was more poking around the code and adding and removing some ampersands and asterisks to try to make sense of mut and not mut and whatever." -- Senior engineer with 20 years of Java experience in cloud and IoT

      We also spoke with someone who found that not having much of a programming background seemed to benefit people picking up Rust. Not having worn-in grooves from other languages may play a role here, and it's worth investigating further.

      "I had someone who had never programmed much before start working on the internals of [our Rust project]. She was just fine with getting into Rust. It's more of the senior people that struggle as they need to unlearn practices which may work in other languages, but it's not the 'Rust' way." -- Researcher, Automotive OEM R&D Lab

      Learning to work with the borrow checker

      We heard a lot about learning to work with the borrow checker instead of against it. People get there through different paths, but a few patterns came up repeatedly.

      The compiler as teacher

      Rust's diagnostics did the teaching on their own, especially around lifetimes.

      "If you mess up the lifetimes in a piece of code that you've written by hand, I usually find that Rust's diagnostics are very helpful" -- Researcher working on static analysis of Rust programs

      "Whatever's missing, the compiler usually fills in: it tells me 'you need to declare the lifetime of this reference', so I know and can figure it out. That all generally works pretty well." -- Senior Software Engineer

      Learning by doing

      Others felt like they only really internalized the borrow checker after writing a lot of Rust. It took projects, coding challenges, prototyping and so on until at some point it clicked.

      "I actually did not understand the borrow checker until I spent a lot of time writing Rust" -- Founder of a startup built on Rust

      "Besides the prototyping work, I also did coding-challenge-type stuff to get familiar with Rust for Advent of Code. [..] It eventually clicked to the point where I wasn't fighting with Rust, it was working for me. I had that experience other people describe: when I managed to get my program to fit with Rust, it worked. I didn't spend time debugging." -- Principal Software Engineer, large SaaS provider

      Letting go of "clone guilt"

      Some learners arrive with the assumption that good Rust means zero clones, zero copies, lifetimes threaded through everything. They set the bar at optimal before they've learned how to write idiomatic Rust, and it makes the borrow checker feel harder than it needs to be at the outset.

      "On one of my first projects, I was like, 'I don't ever want to copy or clone anything,' so I carefully wove through all the lifetimes and got myself into a bit of a bind. Then I saw someone else just cloning the struct I was working with, and it was super cheap. Sometimes you can just clone and it's going to be okay." -- Researcher at a university

      The experienced Rust developers we spoke with consistently said the same thing: clone freely while you're learning, then optimize when you understand the problem. Rust's reputation for performance and correctness feeds this. Newcomers assume anything less than optimal is wrong before they've written a first working program, and clone guilt is how that shows up.

      We think it could be an interesting area of future study to check into the patterns Rust programmers employ at different levels of experience and under which circumstances. One member of the Rust Vision doc team that's very experienced with Rust noted that there's kind of an "expected shape" they understand as passing the compiler. This knowledge influences how they approach writing code which wouldn't take that shape and they naturally find themselves understanding when to use so-called workarounds, such as passing around indices into arrays or Vecs.

      Multi-paradigm, but not the OOP some are used to

      The Rust programming language is multi-paradigm, and how that lands depends on what you're coming from. We heard some that came from a functional background were delighted with digging into learning how much Rust inherits from that lineage. Some others noted that they and others on their teams struggled to unlearn the object-oriented style they'd come to use heavily in other languages like C++ and Java.

      "Developers coming from C++ tend to think object-oriented. I think that's a difference between C++ and Rust." -- Architect at Automotive OEM

      "I had exactly that thing, where I would apply all my years of Java and JS thinking, where I could just create some object, not care about it, return it, have it sloshing around between various functions. Found myself reaching for these patterns and then being told 'no, you cannot do that'." -- Principal Engineer at a SaaS company

      Developers coming from functional programming had less to unlearn: strong typing, pattern matching, and an expression-oriented style were already familiar.

      "My background has been more functional programming, strong typing. That originated for me as a Lisper: once a Lisper, always a Lisper." -- Principal Software Engineer working on Rust tooling for safety-regulated industries

      "The languages I primarily used before Rust were things like OCaml. Way back, I came from C and C++, the classic languages, and then I spent quite a long time doing primarily pure functional stuff. These days I've ended up back in what I like to think of as a pragmatic center ground [with Rust]." -- Fractional CTO

      Teaching Rust in academia

      We spoke with a university professor that's been teaching Rust generally. In the academic environment, they were able to use proxies for some things such as "traits are like interfaces in Java" because the students had already gone through a set of courses in their first and second years that taught them Java. They introduced concepts slowly throughout the course, choosing to deal with some more complex topics like generics later. The outcome generally was that students had no problem picking up Rust in this setting.

      "I couldn't see any big difference on the embedded side. We also teach an embedded class, and we did an experiment. Half of the students' feedback was worse on the Rust class, mostly because they needed to build the project themselves. The C students just got one from [an LLM], absolutely no problem." -- University Professor, on teaching Rust

      The C cohort leaned on LLMs for the project in ways the Rust cohort couldn't. We don't yet have a clear answer for why.

      What did come through clearly was the Rust cohort's experience with the community. Some students needed to figure out which drivers to use for the embedded project and how to use them. Their professor encouraged them to open issues and ask questions directly on GitHub, and the maintainers responded. Students who had never contributed to open source before were getting answers from the people who wrote the code.

      Learning using LLMs

      Some experienced folks shared that they saw LLMs as a tool that can help someone come up to speed quickly, either as a research tool or for generating example Rust code to understand concepts.

      "I'm optimistic that there's a way to work [LLMs] in that will cut down that learning curve. One of the big things these tools bring is reducing the learning curve in general; these are very good tools to help you navigate a space that you don't know yet." -- Maintainer of large open source Rust crate

      "I try [LLMs] out once a month, usually for generating an example or something like this. Just like with Stack Overflow: when you read an example, you should read it carefully and try to understand it. Not copy and paste it, but type it in your own words in code and then check it, because that's where the teeny tiny little mistakes are." -- Founder of startup built on Rust

      For some learners, an LLM is just another way to find answers, no different than a search engine.

      "So for the most part, picking up Rust - how do I learn? I'll [use web search for] things, I'll ask [an LLM], I'll just poke around and read the code." -- Senior Software Engineer working in a regulated space

      One founder went further and claimed that LLMs change who can become a Rust developer. One consulting company founder described hiring high school graduates with no systems programming background and training them as Rust developers, with LLMs filling in the learning gaps that would previously have required years of experience.

      "At the beginning, I was worried, but now that we have [LLMs] supporting development, the difficulty of the language doesn't matter. I'm seeing a huge opportunity behind strong runtime languages like Rust. [..] In [Developing Country] we hire 20-25 high school graduates, train them to be Rust programmers, then they enhance our workforce worldwide." -- Founder of a consulting company

      We heard this from one organization. This is a claim that the combination of Rust's compiler and LLM tooling can dramatically shorten the path from beginner to working developer. Whether it generalizes depends on questions we can't answer from a single interview: how long these developers stay, what kind of code they can maintain independently, and whether this training/learning model works outside this company's particular structure. If it holds up, the pool of people who can become Rust developers is much larger than the usual hiring profile suggests.

      Organizational considerations for Rust learners

      We spoke with a number of folks on teams that are using Rust in larger organizations. Teams wanted to know that everyone would end up at roughly the same level of competence, which led a good number to invest in training courses to get there. Some leaders found that staff was able to ramp well enough by reading The Rust Programming Language, going through Rustlings, and then picking up lower risk and priority tickets to work on. Having a sense of community was also important within companies; it helps people know they are not alone when they are asked to work on Rust after, say, a reorganization happens.

      "[..] the idea with the class as opposed to 'just read the Rust book on your own' was that this gives everyone kind of the same baseline going in." -- Principal Firmware Engineer (mobile robotics)

      "So typically we're going to have people work through Rustlings, work through The Rust Programming Language. We have them then start to pick up lower risk tickets to work on." -- Principal Engineer at a large SaaS provider

      "We've got an internal Slack channel for Rust learning where people can drop questions and others will come in and answer them. That helps build up understanding and community." -- Software Engineer at a large corporation

      Some organizations found that while the person they'd hire would need to learn Rust, it was still preferable to the alternative of hiring someone for a critical piece of software written in another language.

      "They needed to grow and maintain this C++ codebase. They had a C++ wizard, and they tried for about two years to find someone with the same level of expertise. They ended up hiring people that didn't know Rust and ramping them up, creating FFI bindings from the C++ side so they could work in Rust. And you can feel it: the borrow checker is teaching these people the right way to handle their systems." -- Principal Engineer at an Automotive OEM

      The community and helping each other aspect seems to grow bonds as organizations mature.

      "Our team is [all about] mentorship. I've mentored people coming up to speed on Rust, and people help each other hugely." -- Principal Software Engineer at a large SaaS company

      Silent attrition

      We identified some cases where people have approached Rust and bounced off of it, for one reason or another. In the below case, someone with a background in a language with fewer guardrails found themselves frustrated enough with Rust to walk away.

      "All of that means that that embedded ecosystem is very frustrating to somebody who comes from C and is like, why can't I just get a pointer to this peripheral and then write into the registers. What are you doing to me? [..] My friend never got over that. He looked at it and said, I'm not going to deal with this and walked away." -– A second University Professor

      There may be language features that for a particular domain are not seen as comfortable or usable yet, such as async Rust usage in a safety domain. We'd like to map which language features feel off-limits in which domains; async in safety-critical work probably isn't the only case.

      "We're not fully sure how async [Rust] will work out in the long run in our domain. [..] People don't feel comfortable yet since C++14 doesn't provide such concepts. [..] It's the chicken-and-egg problem again: we probably need to gain some experience to see whether we can actually benefit from these new concepts in the automotive and safety domains." -- Team Lead at Automotive Supplier (ASIL D target)

      We heard in at least one case, that while the language was challenging and there was a near bounce, the tooling helped keep them coming back and trying.

      "Well, I think my early impressions of Rust - one is I find C++ so intimidating, and I think a big part of why I was able to succeed at [..] learning Rust is the tooling. I mean, all this makes sense [..] but it's like, for me, getting started with Rust, the language was challenging, but the tooling was incredibly easy." -- Founder of another startup built on Rust

      While it might be considered more of a community concern, if there are interactions online and in spaces that point to learners having so-called "skill issues" this feeds into the narrative that Rust must be hard to learn. We may be unintentionally turning away Rust Project contributors and maintainers due to the vibes being put out when new learners show up in certain spaces.

      "People are very helpful, but generally the attitude is: if your program is very complicated, it's mostly a skill issue. There's not that much empathy when people get stuck learning, and a lot of people are just pushed away by it. There's probably a huge number of people who silently stop wanting to write Rust, because at some point it gets complicated and the feedback they get is 'you just need to be a better programmer, obviously'." -- Software Engineer at a SaaS Provider

      Feedback on near-bounces from survey

      We found a few interesting perspectives collected in the Rust Vision doc survey which we administered with examples of bouncing and coming back:

      "I started before 1.0, got stuck very soon when trying to translate patterns from C++ to Rust (due to borrow checking). I tried again after 1.0 and it stuck. [..]" -- Survey Respondent A

      Survey Respondent A went on to share in a more detailed response about a perceived weakness in Rust learning materials related to lifetimes and the borrow checker are explained. There was an observation that it's fairly easy to run into more complex situations with lifetimes and the borrow checker. They felt that the current state of this sort of material and tutorials is fairly superficial and can leave learners stuck when they run into those more complex situations.

      One respondent that bounced once and came back shared challenges around usage of async. In concert with Rust's memory-safety and the borrow checker, they found some of the nitty-gritty details of async were difficult to learn. While we're aware of the Rust Project's continuous efforts to improve Rust's async story, this is another data point of a user that faced challenges.

      Another survey respondent shared how they had multiple times bounced in trying to learn Rust. They returned after a year or so and found Rustlings to be highly motivating. We note that having multiple pathways for folks to learn Rust opens up more possibilities for those that nearly bounced, just like this person.

      Need more focused work on silent attritrion

      The thing that stood out most to us was the lack of real, first-hand knowledge of having bounced when learning Rust. While this is an obvious effect of soliciting answers to our survey and opportunities to interview through Rust channels and our networks, this cohort is good future candidate where interviews could start.

      Conclusions

      Across these conversations, the experience of learning Rust depended heavily on context. Why someone was learning and what support they had mattered as much as the borrow checker. The same kinds of examples kept coming up: a training course that got a team to a shared baseline, a maintainer answering a student's first GitHub issue, and a colleague whose code showed that cloning was okay.

      That context is largely something the community has a hand in. With that in mind, here is what we take away from what we heard, and what we still don't know.

      What seems worth trying

      Learning materials aimed at unlearning. Syntax barely came up when people described their struggles. People struggled with unlearning habits from previous languages, whether OOP structuring from C++ and Java or the instinct to grab a raw pointer to a peripheral. Most of our learning materials teach Rust from first principles, and that works. What we didn't come across is much written for, say, the engineer with ten years of Java who lands on a Rust team after a reorg: material that names the patterns they'll reach for that won't transfer, and shows what to do instead. The professor we spoke with did a version of this in the classroom, leaning on "traits are like interfaces in Java" and saving generics for later in the course, and the students did fine. Something similar could work outside the classroom too.

      Put the "clone freely while you're learning" advice somewhere official. Every experienced developer we spoke with gave the same advice, but learners seem to mostly pick it up by accident, like the researcher who happened to see someone else cloning the struct they had been carefully threading lifetimes through. Saying it early in official materials would take some of the steepness out of the curve. The broader version belongs there too: idiomatic Rust doesn't have to mean optimal Rust, especially on a first project.

      Diagnostics are already a primary learning resource: several people told us the compiler taught them lifetimes before any documentation did. Diagnostics reach learners right at the moment they're stuck. When writing new ones, it seems worth keeping the confused newcomer in mind alongside the expert, because for a lot of people this is where the learning happens.

      Is "the book" actually out of date? Whether or not The Rust Programming Language or other materials are actually behind, a team evaluating Rust looked at its repository, saw unresolved issues and unmerged PRs, and moved on. As more companies evaluate adoption, more people will look at these materials with the same fresh eyes. Visible issue triage and some communication about what's current and what's planned would address the perception, separately from whatever content work may or may not be needed.

      How stuck learners get treated is shaping who stays. We heard about students getting answers on GitHub from the maintainers who wrote the code, and we heard about learners being told their struggles were a skill issue. The first group came away with a lasting good impression of Rust. Some of the second group walked away entirely, and because they leave quietly, it's easy to underestimate how many of them there are. The welcoming side of the community came up unprompted as a reason people stayed, so we know it makes a difference when we get this right.

      Every organization we spoke with described essentially the same ramp-up for bringing a team to Rust. Teams that brought groups of developers to Rust described roughly the same approach: get everyone to a shared baseline with a training course or with The Rust Programming Language and Rustlings, start people on lower-risk tickets, and give them somewhere internal to ask questions. Several organizations also found that hiring developers without Rust experience and ramping them up worked out better than continuing to search for rare expertise in another language. None of this is complicated, and teams weighing adoption don't need to invent a training program from scratch.

      What we still don't know

      The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.

      We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.

      The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.

    11. 🔗 Console.dev newsletter Go Micro rss

      Description: Agent harness & service framework.

      What we like: Supports a variety of runtime primitives including model routing, memory, tools, guardrails, and durable workflows. Automatically creates MCP gateway. Built-in A2A gateway. All abstractions are Go interfaces to make it easily pluggable. Orchestrates multiple services with a local dev server and deploy tooling.

      What we dislike: Encourages microservices, which are often overkill - especially at the beginning of a new project.

    12. 🔗 Console.dev newsletter Hasp rss

      Description: Local secret broker.

      What we like: Local-first secret storage with project bindings to allow access to specific secrets. Can launch apps with the secrets injected or act as a broker with on-demand supply of secrets. Time-bounded grants. First-class support for agents to request secrets. Access auditing.

      What we dislike: Local-first is by design in v1, but also a limitation because there’s no control plane or cloud sync.

  2. June 24, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-24 rss

      IDA Plugin Updates on 2026-06-24

      Activity:

      • ghidra
        • 6f1a6eaa: GP-0: Log error when populate FID has language mismatch (Closes #9287)
        • 3b22c3a0: Merge branch 'GP-0_ryanmkurtz_PR-9304_pgalbraith_fix_9303-npe'
        • c49db1f7: Merge remote-tracking branch 'origin/patch'
        • 4f02c88d: Merge remote-tracking branch 'origin/GP-941_ghidorahrex_sparcv9_reg_d…
        • 2c94b3a9: Merge remote-tracking branch 'origin/GP-6966_d-millar_autosetup-SQUA…
        • 89378dfc: GP-6523: Reducing ComLoader false positives
        • 00320b3a: 9303: aligning fix with #9188
        • bd725326: GP-6966: fix for tests
        • bab81cb6: GP-941: Correct SparcV9 register operand display to be consistent
        • 58c44a03: Merge branch 'GP-7001_ryanmkurtz_pyghidra' (Closes #9288)
        • d36e9af5: GP-7001: PyGhidra doesn't swallow GhidraScript exceptions anymore
        • bf1f42fc: 9303: Varnode.High NP gate in ForceUnionAction.findUnion
      • ida-ios-helper
        • 8a8fc417: [objc] fix objc_sugar bug that merged a line into a line that is erased
    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. 🔗 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 (&lt;hr&gt;) 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

    4. 🔗 r/LocalLLaMA The Swiss Federal Supreme Court is evaluating Heretic rss

      “Oh no, are they banning abliterated models now?!?”

      If that was your first thought when you read the title I can’t blame you. But that’s actually not what’s happening in this case.

      Instead, the Swiss Federal Supreme Court is evaluating Heretic for their own use!

      As it turns out, the Court has been suffering from the same problem as many people on this sub: LLMs refusing perfectly legitimate requests. The paper “Measuring & Mitigating Over-Alignment for LLMs in Multilingual Criminal Law Courts” investigates potential solutions to this problem, including abliteration, and specifically evaluates Heretic in Section 5.2, with a favorable conclusion.

      Please remember that only criminals and terrorists use abliterated models 😏

      submitted by /u/-p-e-w-
      [link] [comments]

    5. 🔗 r/LocalLLaMA Unlimited-OCR is now on ModelScope! A 3.3B multilingual OCR model for one-shot parsing across single images, multi-page documents, and PDFs. License: MIT rss

      Unlimited-OCR is now on ModelScope! A 3.3B multilingual OCR model for one-shot parsing across single images, multi-page documents, and PDFs. License: MIT | Full-document parsing instead of cropped-region OCR 32K output length for long OCR sequences Base and gundam image modes for different document layouts Transformers inference + SGLang serving with OpenAI-compatible streaming requests Built to push DeepSeek-OCR-style document parsing further. source: https://x.com/ModelScope2022/status/2069335055965491525 https://github.com/baidu/Unlimited-OCR submitted by /u/Sporeboss
      [link] [comments]
      ---|---

    6. 🔗 Jamie Brandon I'm not a cat rss
      (empty)
  3. 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. 🔗 roboflow/supervision supervision-0.29.1 release

      What's new

      🚀 KeyPoints.with_nms() — NMS for pose estimation

      import supervision as sv

key_points = model.predict(image)  # sv.KeyPoints
key_points = key_points.with_nms(threshold=0.5)  # removes duplicate skeletons

      Derives axis-aligned bounding boxes from each skeleton's valid (non-zero and visible) keypoints, then applies standard box NMS. Supports class_agnostic mode and any OverlapMetric (IOU, IOS). Raises ValueError if detection_confidence is not set.

      feat-keypoints-with-nms-compressed.mp4

      Notable changes

      Bug fixes

      • sv.DetectionDataset.as_pascal_voc no longer mutates bounding boxes (#2341) Previously, every export shifted every bounding box by +1 px in-place. A second call compounded the shift. Fixed by rebinding to a new array; on-disk XML output is unchanged.

      • sv.Precision and sv.F1Score correctly count background false positives (#2331) Predictions on images with no ground-truth objects, and predictions of classes absent from any annotation, were previously ignored. Under MICRO and MACRO averaging they are now counted as false positives. WEIGHTED averaging is unchanged. Users should re-evaluate existing metric results after upgrading.

      • sv.DetectionsSmoother works with confidence-free detections (#2333) The smoother no longer raises when detections have no confidence scores. Confidence is averaged over the frames that carry it; tracks without any confidence produce None.

      • sv.Detections.from_vlm is robust to malformed Gemini/Qwen output (#2342) Valid JSON that is not a list, or whose elements are not dicts, now degrades to empty Detections instead of raising TypeError. A malformed mask value in Gemini 2.5 responses no longer misaligns the xyxy/confidence/masks arrays.

      • sv.JSONSink serializes NumPy scalars in custom_data (#2334) np.int64 frame indices and other NumPy scalars in custom_data no longer raise TypeError at flush time. NumPy arrays are serialized as lists. The file handle closes even when serialization fails.

      • sv.approximate_polygon respects the point-count budget (#2332) The function now returns at most floor(N * (1 - percentage)) points (minimum 3). Previously it could return more points than requested. epsilon_step is now validated to be positive.

      • COCO export preserves all segments for multi-part masks (#2322) Previously, only the first polygon was written when a non-crowd detection had disjoint mask segments. All polygon parts are now written.

      Performance

      • sv.HaloAnnotator is ~4× faster with CompactMask detections (#2339) HaloAnnotator now uses the same optimized CompactMask paint path as MaskAnnotator. Previously it materialized each mask full-frame; now it operates on the bounding-box crop. Annotated output is unchanged.

      • Mask IoU uses less peak memory (#2323) Mask IoU computation now uses matrix multiplication on flattened masks instead of an explicit (N, M, H, W) tensor. For masks larger than 4096×4096 px, computation promotes to float64 automatically. Results are numerically identical.

      • sv.mask_to_xyxy and sv.KeyPoints.as_detections vectorized (#2330) Both functions now use batched NumPy operations instead of per-element loops. Outputs are bit-identical.

      Contributors

      • Ruben Haisma (@RubenHaisma, LinkedIn) — VLM robustness, Pascal VOC export fix, DetectionsSmoother, JSONSink, metrics correctness, polygon budgeting, vectorization
      • Agis Kounelis (@kounelisagis, LinkedIn) — HaloAnnotator perf, mask IoU matmul, mask_to_xyxy/KeyPoints.as_detections vectorization, OBB cookbook
      • Piotr Skalski (@SkalskiP, LinkedIn) — KeyPoints.with_nms()
      • Abdelrahman Gomaa (@abdogomaa201099, LinkedIn) — COCO multi-polygon export

      Full Changelog : 0.29.0...0.29.1

    3. 🔗 r/LocalLLaMA Not ironclad confirmation, but.. rss

      Not ironclad confirmation, but.. | Over here: https://huggingface.co/papers/2606.21906 Kudos to xyzblaz for asking. submitted by /u/Kodix
      [link] [comments]
      ---|---

    4. 🔗 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.

    5. 🔗 r/LocalLLaMA 7 Chinese companies are already shipping H100/H200-class AI chips, most IPO'd in the last 6 months. I mapped all of them. rss

      7 Chinese companies are already shipping H100/H200-class AI chips, most IPO'd in the last 6 months. I mapped all of them. | Three dragons, four snakes, and the silicon nobody outside China can name. For the past few months, many peoples in my timeline has been arguing about the same thing: NVIDIA export controls, H20 quotas, and whether Jensen gets to sell to China at all. Almost nobody is asking the question that actually matters. What is China going to run instead? Here's the part the Western AI crowd has mostly missed. At least seven Chinese companies are already shipping AI accelerators today. Current-generation parts land around NVIDIA H100, and next-gen is targeting H200. Most of them IPO'd in the last six months. In many cases the people who designed them are the same engineers who designed the chips at NVIDIA, AMD, and Intel that they're now competing with. I run open-weight Chinese models (Qwen, DeepSeek, GLM) on a 4×3090 rig in my apartment every day. So when the hardware those models are being tuned for starts moving this fast, I pay attention. This is the map I wish someone had drawn for me.

      Source note: most of the specifics below come from a talk by Dmitry Shilov, CTO of CHITEX and the accompanying deck. Where a claim is spicy or unverified, I flag it as his claim, not gospel. Specs, revenue, and IPO dates are from the deck. Treat performance comparisons as vendor or analyst figures, not independent benchmarks.

      The Chinese frame for this market is wonderfully Chinese: "three dragons and four snakes." Three Big Tech giants that also make silicon, and four pure-play chip companies that just went public.

      The three dragons: big tech silicon

      These are companies worth $100B or more that also build full-stack GPUs: chips, servers, clusters, and the software to run them. In Chinese terms a "cluster" starts at 10,000 cards. At roughly 8 cards per server, do that math. All three have their own answers to NVLink and NVSwitch. Huawei Ascend, number one in China https://preview.redd.it/wx96coxpv39h1.png?width=3000&format=png&auto=webp&s=d059137749034def184e85b733f1d818406c8ec5 - Revenue (Huawei, 2024): ¥862B, about .
      - Market position: number one Chinese AI-chip vendor at 812K cards, 49% of the 1.65M domestic supply and about 20% of the full ~4M-card market. 42% of national AI-accelerator supply.
      - Ascend 910C: mass production in 2025 (~300K units), with a plan for 600K in 2026.
      - Ascend 910D: 5nm, 4-die package, FP8 support, mass production Q2 to Q3 2026, positioned against the H100.
      - Ascend 950PR and 950DT: next gen, rolling out across 2026, with Huawei's own HBM (HiZQ 2.0, 4 TB/s), so independence from SK Hynix.
      - Target: 4 ZFLOPS of FP4 by 2028. Huawei is the one vendor here whose hardware is deliberately not CUDA-compatible. They built their own stack with global expansion in mind. The one Ascend headline that does leak into Western media is that the 950PR reportedly beats the H200 outright, well past the H20. (That's the vendor and talk claim. I haven't seen independent numbers.) Alibaba T-Head, number two, and the box that should scare you https://preview.redd.it/t04dc64sv39h1.png?width=3000&format=png&auto=webp&s=3a208d64ed304b2eee1907387baa827eadaa3bce - Revenue (Alibaba, FY2025): about .
      - Market position: number two Chinese vendor at ~265K cards, 16% of domestic supply.
      - PPU: 96GB HBM2e, 400W TDP, positioned against the H20.
      - IPO: T-Head spin-off and listing process started January 2026. The detail that stopped me is the Alibaba PG1 server. Sixteen PG1_810E cards at 96GB each is 1,536 GB of VRAM in a single box, with two Intel Xeon 8558P and 2TB of system RAM. That's enough to hold GLM 5.x in BF16: a private, on-prem, full- fat frontier-model box, your own Claude Code in a chassis, no cloud and no telemetry. Backed by Alibaba Cloud, the number one CSP in China. Baidu Kunlunxin, number three, inference-first https://preview.redd.it/h9i6h57vv39h1.png?width=3000&format=png&auto=webp&s=b55f9288ed36018a850edd6679d523a0ff7a4f61 - Revenue (Baidu, 2025): $18.5B, market cap about .
      - Market position: number three at ~116K cards (7%), neck-and-neck with Cambricon.
      - Kunlun M100: inference-optimized, already shipping (Q1 2026).
      - Kunlun M300: training plus multimodal inference, 2027.
      - Tianchi Super Nodes 256/512: up to 1 trillion parameters, available 2026.
      - IPO: Baidu is weighing a Kunlunxin spin-off and listing (Dec 2026).

      The four snakes: the pure-plays that just IPO'd

      These companies went public on the Hong Kong and Shanghai STAR exchanges starting December 2025. Their previous gen is roughly A100, current gen roughly H100, all in OAM form factor (the open-standard analog of NVIDIA's SXM). One thread runs through all of them: they were founded by ex-NVIDIA and ex-AMD people, frequently the literal architects of the chips they're now cloning. MetaX (曦云), the one that tells the whole story https://preview.redd.it/nil52xeyv39h1.png?width=3000&format=png&auto=webp&s=0549af5456bbba013d60909daee68e83b9fb5a4c - Revenue (2025): ¥1.64B (~$230M), up 121% year over year, net loss ¥830M.
      - IPO: Shanghai STAR (688802.SS), Dec 17 2025, up 693% on day one, about ¥332B (~$47B) market cap at debut.
      - C600: 144GB HBM3e, MXMACA architecture, positioned against the H200, mass production Q3 2026.
      - C700: next gen, fully Chinese production from 2027.
      - The number: revenue went from ¥426K in 2022 to ¥1.6B in 2025, roughly 3,800x in three years. Now look at who built it. The founding team: - Chen Weiliang (CEO): 22+ years in GPU design, global chief GPU architect and global chief SoC architect at AMD.
      - Peng Li (Hardware): 19+ years, first female engineer at AMD China.
      - Yang Jian (Software): 24+ years, first research fellow at AMD China. https://preview.redd.it/f3sttt21w39h1.png?width=3000&format=png&auto=webp&s=f64c4e20c26fe747c84a95b122e9d62b6d805332 Moore Threads, gaming and AI - Revenue (2025): ¥1.505B (~$219M), up 243% year over year, net loss narrowing.
      - IPO: Shanghai STAR (688795.SS), Dec 5 2025, up 400% on day one, raised about .
      - MTT S5000: flagship, 80GB, 1 PFLOPS AI compute, 1.6 TB/s bandwidth, FP8 to FP64, and it explicitly supports GLM-5.x and Qwen3.5+.
      - Differentiator: the only Chinese vendor doing gaming and AI on one architecture, with DX12 Ultimate, the only Chinese graphics API at that level. Biren Technology, outspending its own revenue https://preview.redd.it/dyi57p75w39h1.png?width=3000&format=png&auto=webp&s=9af403068bc89bd632939fbc1b12632ccfc4698a - Revenue (2025): ¥1.03B (~$150M), up 207% year over year, gross margin 53.8%.
      - IPO: Hong Kong (06082.HK), Jan 2026, the year's first major listing, raised about $624M, cash position over .
      - BR20X: next gen, 2026, FP8/FP4, inference-optimized.
      - The tell: Biren spent more on R&D (¥1.48B) than it earned (¥1.03B), R&D at 144% of revenue. That's not a company milking a product. That's a company sprinting. Iluvatar CoreX, the edge play https://preview.redd.it/rh0ix5g7w39h1.png?width=3000&format=png&auto=webp&s=20d2a866b67ca1e97b4294d5082522a5703d5e18 - Revenue (2025): ¥1.03B (~$149M), up 92% year over year, GPU business at 89% of revenue and up 150% year over year.
      - IPO: Hong Kong, Jan 8 2026, about $4.5B valuation, raised ~$475M, 340+ customers across finance, healthcare, and transport.
      - Data-center line: BiV100 (32GB), BiV150 (64GB), BiV200 (80GB), B300 (144GB).
      - Edge line (the sleeper): the TY-series, tiny boxes from 130 to 300 TOPS, Orin-class, plug-and-play, drop-in replacements for NVIDIA's edge modules at a fraction of the price. Iluvatar built it because its backers are retail companies that need cheap edge inference for robots and IoT. https://preview.redd.it/r36mcsh8w39h1.png?width=3000&format=png&auto=webp&s=c49060b80ae3602c64cdafc6bc6d054e60a890f9 Founder Li Yunpeng is ex-Oracle R&D. The roadmap openly states the goal: beat NVIDIA Rubin within two years.

      The shift nobody's pricing in

      Three things are happening at once, and together they're a regime change.

      1. Production moved home. All the new parts (Ascend 950, MetaX C600, Iluvatar's 300-series) are shifting from TSMC to SMIC. Officially "12nm." (In the talk Shilov claims the real node is well below that and nobody admits it on paper. Take that as his read, not a fact.)
      2. NVIDIA's China share is collapsing. Per IDC, about 2.2M GPUs shipped to China in 2025, likely one of the last big NVIDIA waves. NVIDIA's share fell from 95% to 55% in two years, a 40-point drop. When the US floated easing sanctions in June, the Chinese answer was reportedly: thanks, no longer needed. Datacenter utilization for Chinese cards is near 100%, with a roughly 3-month queue for new servers.

      https://preview.redd.it/c13mtolaw39h1.png?width=3000&format=png&auto=webp&s=3064d9e64dbd6f96c92d3e006ec7006adadc45c0

      1. The models are following the metal. This is the part that matters most for anyone running open weights. Chinese open-source models are increasingly optimized for Chinese silicon first. DeepSeek-V4 is the canary: part of why it slipped is that it's being tuned for domestic GPUs. Qwen will follow (it's Alibaba). The rest will too. And right now, essentially every good open-weight model is Chinese.

      Put those together and you get a line I think will age well. Within about two years, the talk argues, China flips from importing AI chips to exporting them.

      Why I care, and why you should

      I'm not a geopolitics account. I care because of a very concrete thing sitting under my desk. Today I run Chinese open models on Western silicon: 4×3090, 96GB, llama.cpp, vLLM, SGLang. That setup is the bridge. But the models I'm running are being tuned for hardware that isn't NVIDIA, by teams that used to be NVIDIA and AMD, shipping into a market that's already 45 points less NVIDIA than it was two years ago. The Chinese GPU story isn't a sanctions footnote. It's a parallel hardware ecosystem with its own form factor, interconnect, HBM, and fabs, and its own models being co-designed with the metal. The West is busy debating who gets to sell H20s. The question for the rest of us is quietly becoming simpler: in two years, what's actually in the box? I run Chinese open models on NVIDIA today. My next box might not be NVIDIA at all. That's the shift I'm watching, even if the West isn't. Edit: rewrote the full article, a few of you (fairly) didn't want to leave for Twitter. All 7 vendors and sources are above. Anyway, I'll be glad to see you at that very place: https://x.com/superalesha/status/2069415581237813437 submitted by /u/awfulalexey
      [link] [comments]
      ---|---

    6. 🔗 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.

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

    9. 🔗 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.

    10. 🔗 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!

  4. 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. 🔗 r/LocalLLaMA DeepSeek raises $7.4B USD at $60B valuation. Remarkably, Liang Wenfeng invests $3B in DeepSeek himself. rss

      DeepSeek raises $7.4B USD at $60B valuation. Remarkably, Liang Wenfeng invests $3B in DeepSeek himself. | submitted by /u/FullOf_Bad_Ideas
      [link] [comments]
      ---|---

    4. 🔗 @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

    5. 🔗 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

    6. 🔗 r/LocalLLaMA Chinese Hackers Latest Masterpiece with NVIDIA rss

      They spent a year to reverse-engineered the Tesla v100's 2,963 pinouts signals, soldered it onto a half height PCB, with full NVLink support (up to 8 way capable), then naming it Tesla v100 v4.

      Price (with 3 years warranty):

      16G version: 1499 rmb (220 usd)

      32G version: 3999 rmb (590 usd)

      2 way NVLink adapter: 199 rmb (29 usd)

      8 way NVLink adapter: 799 rmb (118 usd)

      The hacker's op: https://t.bilibili.com/1211458176581369862

      The engineer: https://space.bilibili.com/1560089206

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

    7. 🔗 r/LocalLLaMA GLM5.2 @7tg on 4x3090 + 192GB on budget motherboard + cpu rss

      GLM5.2 @7tg on 4x3090 + 192GB on budget motherboard + cpu | I finally finished by home lab computer I started working on in May. I carefully waited and bought the 3090s in three local transactions. Every single seller was a gamer who was upgrading to 4090 or 5090 and none had any interest in AI. I bought the 192GB of 5200MHz of DDR5 and have overclocked it to 5600 MHz. I power capped the 3090s to 200W each in Linux. I used an Aegis prebuilt off eBay and replaced the PSU to a 1250W platinum. I kept the cpu and water cooling loop. I’ve probably spent 40 hours and $6000 on this rig, and I think it’s perfect for what I like to do. I run GLM5.2 at 7 tg as a planner. MiniMax 2.7 all on VRAM at 45tg as my coder. I use Flux2Klein for diffusion and I haven’t tried the throughput with all 4 cards but 2x was giving me about 1 image per 6 seconds when I batched. Qwen3.6 27B at q8 as my checker and testing loop model at 50 tg. My purpose of keeping it on consumer hardware was for financial reasons. A server with ECC ram would double the throughput with more channels but it’s about double the price for ram and threadripper. I build enterprise automated workflows as a forward-deployed engineer for more than a dozen companies. I’m a solo dev who has enjoyed automating things for years and now it’s easy to do it locally with solar power. They could block my IP from Claude and OpenAI and I wouldn’t really care anymore. Upgrade path is pretty much just upgrading GPU. Might build a dedicated server just for GLM in the future but for now I’m pretty set until data centers start dumping RTX6000 Pros. submitted by /u/Important_Quote_1180
      [link] [comments]
      ---|---

    8. 🔗 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

    9. 🔗 r/LocalLLaMA been tracking EU DDR5 data for 25 days: Prices are dropping, and the DE vs. NL gap is wild (good news for local LLM builders in EU) rss

      hey again!

      been tracking DDR5 prices across 4 EU countries (DE, NL, ES, BE) for the past month. some findings relevant to local LLM builders:

      prices are falling:

      • G.Skill DDR5 Aegis 2x16GB 6000: -28% in 25 days (€579 → €419)
      • Kingston FURY Beast RGB 2x16GB 6000: -26% (€499 → €369)
      • G.Skill Trident Z Neo 2x32GB 6000: -23% (€1200 → €927)
      • Corsair Vengeance 2x16GB 6000: -13% across multiple kits

      cross-country gaps are real:

      • G.Skill Trident Z5 RGB 2x32GB DDR5-6400: €799 in NBB (de) vs €1180 in Megekko and Azerty (NL) - same EAN, same kit
      • generally Germany 10-20% cheaper than Netherlands/Belgium on the same kits

      for entry-level LLM inference: DDR5-6000 2x16GB kits are hitting a sweet spot:
      DDR5-6000 2x16GB kits have dropped significantly and are now the sweet spot. if you've been waiting to upgrade for bandwidth, now might be the time :)

      tracker is live at: www.pricesquirrel.com (EU only, no US data sorry)

      btw: i just recently added RAM and CPUs so it's a fresh beta, so data is still selective. i'm squashing bugs and adding more EU retailers weekly. if you spot a bug, have a feature request, or want a specific shop added next, lmk!

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

    10. 🔗 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)
    11. 🔗 r/LocalLLaMA GLM-5.2 is on DeepSWE rss

      GLM-5.2 is on DeepSWE |

      TOP-RIGHT corner is the best, price gets CHEAPER as you go towards the

      RIGHT.

      https://deepswe.datacurve.ai/ Alternate scores by ArtificialAnalysis: https://artificialanalysis.ai/agents/coding-agents Side note, why does this sub dislike DeepSWE? I want to know more and did some research and found this post which has since been retracted by the original author (highly respect them as they handled the correction well and admitted bias) Another criticism was Opus 4.6 being low, which is true, but Opus 4.6 also dropped in swe-rebench since February, as I assume it's being deprecated. I'm interested in other opinions and what you think is a good benchmark. One thing that is true is that DeepSeek scores were done before the 75% discount on the v1 bench. They should be ~4-5x cheaper. submitted by /u/agentcubed
      [link] [comments]
      ---|---

generated: June 25, 2026 at 20:36:11