🏡
  • ↔
  • →

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: May 21, 2026 at 10:18:24

  1. May 21, 2026
    1. 🔗 backnotprop/plannotator v0.19.21 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.19.20 | Interactive goal setup UI, OpenCode submit_plan fixes, browser no-op sentinel handling for Claude agents
      v0.19.18 | Edit-based submit_plan for OpenCode, Pi namespace migration, Codex annotate-last fix, OpenCode commands dir fix
      v0.19.17 | Reworked goal setup skill (interview-driven flow), CLI --version flag
      v0.19.16 | Code navigation with peek view (Cmd/Ctrl+click tokens in diffs)
      v0.19.15 | Commit-based diff base, jj evolution diffs, GitLab reliability fixes, OpenCode command intercept fix
      v0.19.14 | Visual explainer skill update, PFM code-file hover previews, Graphviz, diff tab size and line bg intensity, hooks settings tab
      v0.19.11 | Jujutsu (jj) VCS backend, slimmer hunk separators, collapse viewed files, multi-line gutter selection fix
      v0.19.9 | OpenCode user-managed workflow, Pi model switch fix, Codex skill install, shimmer removal
      v0.19.8 | 49 themes with syntax highlighting, keyboard shortcut registry, smart code-file path validation, remote URL notifications
      v0.19.7 | Codex Stop-hook plan review, Codex skills, sidebar auto-close, file tree context menu

      What's New in v0.19.21

      v0.19.21 brings Ask AI to plan review and annotate mode. The same inline AI chat that was available in code review now works when reviewing plans, annotating markdown files, annotating URLs, and annotating HTML documents.

      Ask AI in Plan Review and Annotate Mode

      Select any text in a plan or annotated document, open the comment popover, and click "Ask AI" to ask a question about the selected content. The response streams into a side panel that persists alongside the annotation panel. You can switch between annotations and AI chat using the sidebar tabs, and both stay independent of each other. AI chat messages are never included in approval or denial feedback.

      The feature uses the same provider-agnostic backend that powers code review AI. Any provider you have installed (Claude, Codex, Pi, OpenCode) works automatically. If you have multiple providers, the system picks a default based on which agent runtime you're using (Claude Code defaults to Claude, Codex defaults to Codex, and so on) and you can override it from the AI settings bar at the top of the chat panel.

      A one-time announcement dialog appears the first time Ask AI is available in plan review, then dismisses permanently via cookie. Users with no AI providers installed see no change at all.

      Shared AI Runtime

      The AI provider setup that previously lived inline in the code review server has been extracted into a shared ai-runtime module. All three servers (plan review, code review, annotate) and the Pi extension now use the same initialization path. This means provider detection, session management, and SSE streaming are consistent across every Plannotator mode.

      The refactor also fixed a missing SSE timeout in the code review server. Long- running AI responses could previously be cut off by Bun's idle connection timeout. All three servers now correctly disable the timeout for /api/ai/query requests.

      Origin-Aware Provider Defaults

      When multiple AI providers are available, Plannotator now picks a default based on which coding agent launched the session. Claude Code sessions default to Claude, Codex sessions default to Codex, Pi sessions default to Pi, and OpenCode sessions default to OpenCode. You can still override the selection manually, and your per-origin preference is saved separately so switching between agents doesn't reset your choice.

      Install / Update

      macOS / Linux:

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

      Windows:

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

      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

      What's Changed

      Full Changelog : v0.19.20...v0.19.21

    2. 🔗 r/Leeds Canada Goose rss

      Hi,

      I've come up from London for a conference and my friend Tarquin has spilt some of your Kirkstalle Ale on his Gilet last night while we were enjoying KPMG corporate hospitality.

      We are flying back to Heathrow this afternoon so don't have time to get it dry cleaned but obviously don't want to go the day sticking out like a sore thumb without the proper attire. Is there anywhere in Leeds (ideally near the dock) we could pick up some Canada Goose, want to avoid brands like North Face unless it's getting dire.

      Thanks in advance

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

    3. 🔗 r/york York, reflected ✨ rss

      York, reflected ✨ | Image @ kierandelaneyvisuals submitted by /u/1ChanceChipmunk1
      [link] [comments]
      ---|---

    4. 🔗 r/wiesbaden Wellpass +1 Mitgliedschaft gesucht rss

      Hey zusammen,

      ich wollte mal freundlich in die Runde fragen, ob zufällig jemand hier Mitglied bei EGYM Wellpass ist und den neuen „Plus1“-Platz noch frei hat 😊

      Dabei kann man wohl eine weitere Person privat mit in den Tarif aufnehmen. Ich hätte Interesse daran und würde die Kosten natürlich vollständig selbst übernehmen – für euch also kein finanzielles Risiko oder zusätzlicher Aufwand, außer der Einladung selbst.

      Hier sind die Infos dazu:

      Wellpass Plus1-Mitgliedschaft Erklärung

      https://support.egym-wellpass.com/de/articles/10853223-plus1-mitgliedschaft

      Falls jemand grundsätzlich Interesse hätte oder Fragen dazu hat, gerne einfach melden 🙂

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

    5. 🔗 jellyfin/jellyfin 10.11.9 release

      🚀 Jellyfin Server 10.11.9

      We are pleased to announce the latest stable release of Jellyfin, version 10.11.9! This minor release brings several bugfixes to improve your Jellyfin experience. As always, please ensure you take a full backup before upgrading!

      You can find more details about and discuss this release on our forums.

      Changelog (5)

      📈 General Changes

    6. 🔗 Console.dev newsletter Antigravity 2.0 rss

      Description: Agentic IDE.

      What we like: Integrates a VS Code-style editor with a CLI and agent management console. Easily track multiple agent sessions and subagents. Create scheduled tasks e.g. regular dependency updates. Sync between different Gemini / Antigravity clients e.g. chat to CLI. Supports skills, MCPs, hooks.

      What we dislike: No custom themes. Workspace accounts can’t upgrade usage.

    7. 🔗 Console.dev newsletter Fate rss

      Description: Data client for React.

      What we like: Uses async React to enable optimistic UI updates and instant feedback. Provides typed APIs to connect to the data backend over fetch, tRPC, or GraphQL. Also includes adapters for Prisma and Drizzle. Introduces an Actions concept for mutations, but you can use more traditional imperative calls.

      What we dislike: Requires React 19 because this is a modern library.

    8. 🔗 Ampcode News Amp Labs rss

      We are assembling small teams of exceptional software builders to bring the full power of artificial intelligence to a single company per industry and region, with CEO mandates.

      For the companies we partner with: we win if and only if you win. We profit only through warrants unlocked if your stock appreciates considerably. We don't work with your competitors.

      To the best builders out there and to the best companies in the real economy: we'll be in touch.

      Amp Labs is the other half of Amp. Being on the front lines with Amp Labs is how we keep the Amp agent on the frontier. Read more at amplabs.com.

      Amp Labs

    9. 🔗 muffinman SpaceDeck X is coming to an arcade cabinet rss

      I want your coins!

      I'm making a game. It is called SpaceDeck X and you can try it online. But thanks to Amsterdam Indie Arcade, it will be available on a physical arcade cabinet at Blast Galaxy.

      It will be released on the 14th of June with a small release party and hi- score tournament. If you are in Amsterdam, be sure to come and check it out. It will be available for the next two months, then a new indie game will take its place.

      Poster for the release party with an image of a stylized arcade cabinet

      Hi-Score Tournament

      We are going to organize a hi-score tournament. The Indie Arcade organizer asked me if I could come up with a fun prize for the winner, so I did:

      Hi score tournament trophy, 3D printed ship from the game on a stand

      I designed and 3D printed the main player ship from the game on a little pedestal. It was super fun figuring out how to bring my pixel art to the real world and break it down for 3D printing. The model is made in JavaScript using Replicad.

      Come and claim the trophy on the 14th!

      Steam Release

      Screenshot of the boss fight in SpaceDeck X, showing the player ship and deck, with the large triangular boss ship above it

      The arcade release is just a pit stop. I'm actively working towards a Steam release, so stay tuned!

  2. May 20, 2026
    1. 🔗 r/wiesbaden WC26 Question rss

      New to the city, is there any special events that happen for the World Cup? The best bars to go watch?

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

    2. 🔗 r/LocalLLaMA Re. what ever happened to Cohere’s Command-A series of models? rss

      Re. what ever happened to Cohere’s Command-A series of models? | Hey everyone, Nick Frosst here from Cohere. A few months ago Aidan (my cofounder) left a comment in here about our Command series and how we were working on some more powerful, open-weights models behind the scenes. We just launched Command A+ and we wanted to share it with you guys. TLDR is we built a really efficient model. It’s our first MoE model, which is exciting. There’s obvs work to do on top-line performance but it’s easily looking like one of the fastest and most responsive models in our category. We also pulled off some incredible quantization work so it runs really well on even 1 or 2 GPUs. Like with R7B, we really prioritized making the model practical, so smaller teams and devs could realistically use it to build the kind of agents we ship for our platform customers. That’s also why it’s under Apache 2.0. Just total, near unfettered access to a pretty awesome model. We’re enterprise-first but honestly, we get so much out of our open-source community that makes us more innovative and creative. The feedback you give will almost certainly influence how we think about models and product going forward…... as it already has here from getting called out the last time haha. So, don’t hold back. Share your thoughts, your projects, whatever. You can see the full details here https://cohere.com/blog/command-a-plus We appreciate you :) submitted by /u/nick_frosst
      [link] [comments]
      ---|---

    3. 🔗 r/reverseengineering GeoHelper - Tauri + Chrome DevTools Protocol (CDP) for GeoGuessr (Steam) rss

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

    4. 🔗 r/Yorkshire Water bill. rss

      Evening Yorkshire lot. Query- Family of 4 (2 adults and 2 kids under 5) 4 bed detached, barely use hose pipe, 2 showers a day, 2 load of washing done a day on average, dishwasher in once a day and we’re on a metre. All that comes too £101pm. Surely that can’t be reet? Saying we’re using 159,000 litres of water a year.

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

    5. 🔗 r/Yorkshire It's that time again, looking forward to all the fun, great atmosphere guaranteed. rss

      It's that time again, looking forward to all the fun, great atmosphere guaranteed. | submitted by /u/Still_Function_5428
      [link] [comments]
      ---|---

    6. 🔗 r/LocalLLaMA Qwen will release another 27B with high probability rss

      Qwen will release another 27B with high probability | They are waiting for the exact roadmap submitted by /u/serige
      [link] [comments]
      ---|---

    7. 🔗 r/york Lost/stray cat? rss

      Lost/stray cat? | Does anybody recognise this cat/know if it has an owner? Spotted in the alley next to st Lawrence church. I'm worried she doesn't have a home because there's no collar, she's very skinny and covered in fleas but she seems too friendly to be a stray. I will try to take her to a vet to check for a chip if no one knows anything. submitted by /u/cousarn
      [link] [comments]
      ---|---

    8. 🔗 r/reverseengineering AI Agents defeat obfuscated JavaScript in 10 minutes rss

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

    9. 🔗 r/reverseengineering What is it Wednesdays: Episode 0002 rss

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

    10. 🔗 r/Leeds LEAD GUITARIST WANTED! rss

      We’re a Leeds-based indie/alternative band looking for a new lead guitarist.

      We’ve recently released a new EP and have built a really solid foundation online. Right now, our focus is entirely on keeping that momentum going. We’re stepping straight into a writing and recording phase to get new material ready for release and for shows. Logistics-wise, we’ve got it sorted: we have our own dedicated rehearsal space, we demo everything ourselves, and we work closely with great producers to bring the songs to life.

      We write music about everyday life and the honest, relatable things people actually experience. We’re ambitious and we take the music seriously, but we also genuinely just want to have fun. Writing and rehearsing shouldn’t feel like a chore; we want someone who wants to have a laugh and enjoy the whole process of building the next phase with us.

      For fans of:

      Deaf Havana / Twin Atlantic / The Xcerts / The Hunna / The Band CAMINO and loads more!

      Who we're looking for:

      We want someone who wants to take the reins lead-guitar wise - bringing big melodies, atmosphere, and a great understanding of dynamics. With a bulk of songs already main stays in our live set, we are looking for a songwriter who genuinely loves the creative process and wants to collaborate on new music from scratch, as sticking their own solid take on our existing material.

      We need someone who is reliable, committed, and doing it for the right reasons. Gigging experience is definitely a bonus, but it’s absolutely not a dealbreaker if playing live is something you are excited for. Leeds or Yorkshire-based is preferred.

      If you're on our wavelength and want to create something exciting, drop us a message. We'll probably chew your ear off and want to know lots about you, like:

      A quick video or audio clip of your playing/writing

      Your main influences

      Any previous projects (don’t worry if you haven't been in a band before)

      Please get in touch and I'll get back to you if this sounds like a good fit!

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

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

      New Features

      • Hardened npm install and release path - Pi now ships the CLI with a generated shrinkwrap for transitive dependencies, blocks accidental lockfile changes, verifies dependency pinning and lifecycle-script allowlists in checks, disables lifecycle scripts for self-update and local release installs where supported, and smoke-tests isolated npm and Bun installs before release. See Supply-chain hardening.

      Added

      • Added interactive update notes after pi update runs, so users can see the installed version's changelog before continuing (#4724 by @mitsuhiko).
      • Exported image resize utilities from the package root for SDK consumers (#4775 by @xl0).

      Changed

      • Changed source syntax to avoid TypeScript constructs that require JavaScript emit, keeping core sources compatible with Node.js strip-only TypeScript checks.
      • Removed web UI workspace references from the CLI package and dropped the package-level development watch script.
      • Published npm installs now include an npm-shrinkwrap.json to lock transitive dependencies for the CLI package.
      • Improved terminal theme detection for light/dark and truecolor handling.
      • Changed self-update package-manager commands to disable lifecycle scripts during reinstall.

      Fixed

      • Fixed the system prompt to tell models to resolve pi docs and examples under the absolute package paths before reading topic-specific relative references (#4752).
      • Fixed extension ctx.abort() during tool-call preflight to stop later confirmations and restore queued interactive input like Escape (#4276).
      • Fixed AgentSession retry, compaction, and event settlement to use the awaited agent lifecycle instead of a separate event queue, and added willRetry to agent_end session events.
      • Fixed forked session runtime state to keep the active session id aligned with the fork target (#4799 by @Perlence).
      • Fixed the subagent extension's parallel mode to return useful per-task output and failed-task diagnostics to the parent model instead of 100-character previews (#4710).
      • Fixed Windows local bash execution to hide helper console windows when launched from background SDK processes (#4699).
      • Fixed managed npm extension folders to set cloud-sync ignore metadata where supported (#4763).
      • Fixed HTTP idle timeout configuration so long-running provider streams can avoid premature idle disconnects (#4759 by @mitsuhiko).
      • Fixed default system prompt boundaries to use explicit XML tags for clearer file separation (#4709 by @herrnel).
      • Fixed HTML share/export sidebar clicks for shared tool entries to scroll to the rendered tool call (#4664 by @yzhg1983).
      • Fixed theme palettes to set explicit text colors and avoid terminal-default color drift.
      • Fixed truecolor detection to align terminal image rendering and interactive theme decisions.
      • Fixed loader indicator startup inherited from @earendil-works/pi-tui so initialization cannot run before frames are available.
      • Fixed OpenAI-compatible default output token requests inherited from @earendil-works/pi-ai to avoid reserving impossible context windows on servers such as vLLM (#4675).
      • Fixed OpenAI prompt cache keys inherited from @earendil-works/pi-ai to stay within the 64-character provider limit (#4720).
      • Fixed Windows npm-family package commands for fnm-managed Node.js installs that expose both extensionless Unix scripts and .cmd shims (#4793).
    12. 🔗 r/reverseengineering TinyLoad v5 - encrypted strings, obfuscated opmap, IAT wiping, payload depends on stub (implemented feedback from last post) rss

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

    13. 🔗 r/reverseengineering Tracing CVE-2026-34472 auth bypass through decompiled ZTE H188A firmware and Lua wizard routing rss

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

    14. 🔗 r/LocalLLaMA HuggingFace benchmark datasets now let you filter by model size rss

      HuggingFace benchmark datasets now let you filter by model size | Quite useful to see which model under 32B performs best on swebenchverified for example.
      https://huggingface.co/datasets?benchmark=benchmark:official&sort=trending submitted by /u/paf1138
      [link] [comments]
      ---|---

    15. 🔗 Locklin on science Q1/2 2026 books rss

      Getting the best of it by David Sklansky. This is something that’s been in my list of books to read since I got out of grad school. It’s often recommended for getting a quant finance job for the sort of gambling puzzles it contains. Most of the poker stuff is lost on me, as I’ve […]

    16. 🔗 r/york Informal York Queer Meet-Up @ City Screen Picturehouse Café - Friday, 22 May 2026 rss

      Hello!

      We've organised a couple of meetups via Reddit and the /r/york Discord over the last few months.

      We're planning to meet up again at City Screen Picturehouse Café Friday, 22 May 2026. If anyone would like to come along and chill with some queer nerds, you're more than welcome!

      A bit about me: I’m a guy in my mid-30s, into Star Trek, grand strategy gaming, and Wikipedia editing.

      • Where: Cityscreen Café, either on the sofas or at one of the tables at the back!
      • When: 18:30, Friday 22 May 2026 (this Friday!)

      You'll know it's us because we'll have a fluffy rabbit on the table.

      Feel free to reply here, DM me, or message in the Discord if you’re thinking of coming along!

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

    17. 🔗 r/Leeds Anyone know where I can buy the spice blend tajin ? rss

      It's a Mexican spice blend used on fruit a lot and I always wanted too try or. I tried b an m, aldi, lidil and Asda with 0 results

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

    18. 🔗 r/Leeds Looking for Germany supporters in Leeds for the World Cup rss

      Hey everyone. I’m looking for fellow Germany fans in Leeds to watch the World Cup matches together.

      Quick context: I’m Indian, been living in Leeds for a while, and somehow ended up supporting Germany. I know, I know. Finding other Germany fans in England is basically a quest at this point.

      If you support Germany for whatever reason, or just want someone to suffer with during the matches, get in touch. Would be great to find a group or even just one or two people to watch the games with.

      Drop a comment or message me. Cheers.

      submitted by /u/Regular-Being7191
      [link] [comments]

    19. 🔗 r/reverseengineering How to build .NET obfuscator rss

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

    20. 🔗 r/york A classic York sightline 👀 rss

      A classic York sightline 👀 | @ John Wellock submitted by /u/1ChanceChipmunk1
      [link] [comments]
      ---|---

    21. 🔗 r/wiesbaden Panini WM 2026 Sticker Tauschbörse rss

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

    22. 🔗 r/Leeds Is this permanent? Did we run out of money for the station project? rss

      Just feels weird. We've been waiting nearly two years to repave that stretch of road, with it being half done all that time. Unless it's some kind of temporary covering? Anyone have any idea?

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

    23. 🔗 The Pragmatic Engineer Google Cloud deletes Australian trading fund’s infra rss

      A $124B fund in Australia would have lost all data stored with Google Cloud, had they not relied on a third-party backup. A rare blunder from GCP, where regional replication did not stop the deletion - and a just as rare statement from Google Cloud's CEO taking the blame.

      The below is an excerpt from The Pulse #93: OpenAI makes Google dance , originally published on 16 May, 2024. I am republishing it because on 20 May 2026 Google Cloud has done it again: they took offline cloud infra provider Railway by blocking Railway 's Google Cloud account . The below is a warning: if you are on GCP, have a plan B, should GCP delete your account and data, or block your account.

      Following on from Google Cloud being a distant third among cloud providers, a recent event could cement its reputation as the least reliable of the top three.

      UniSuper is one of the largest retirement savings accounts in Australia, used by 615,000 citizens, that's also known as a "superannuation fund." UniSuper has $124B of assets under management and is one of the biggest in the country.

      On 29 April, the service suffered an outage. Members could not log into their online accounts, or manage their funds until two weeks later, on 15 May.

      The reason was that Google Cloud accidentally deleted UniSuper's subscription, which also deleted all data associated with the subscription. UniSuper had set up replication across two regions in Google Cloud to protect from a regional failure, but Google Cloud deleted the replica as well!

      UniSuper could only avoid data loss thanks to having a backup on another service provider outside Google. In a surprising admission, UniSuper would have lost all data with Google thanks to the failure of the cloud provider. The only reason UniSuper could restore services was by having another provider with whom they'd backed up the data. Basically, UniSuper not trusting Google's replication across two regions turned out to be a 100% correct assumption. Whoever pushed through the decision to spend additional resources in "a backup in case Google fails" saved the day at the retirement fund.

      The incident is incredibly embarrassing for Google. UniSuper seems to have forced Google Cloud's hand by issuing a joint statement with Google Cloud CEO Thomas Kurian, in which Google Cloud takes all the blame for this failure. In my experience, the situation is rarely this black-and-white, as it usually takes two parties to cause such a major outage. I would not be shocked if it turned out UniSuper's staff played a role in this failure, but Google Cloud made enough mistakes that the press release could dump all blame on it. I asked Google Cloud if the press release really was a joint release, and if they had more to add. The company confirmed the press release is correct and added nothing else.

      Whoever was at fault, two weeks of downtime is still very long for a major fund. As I understand, the damage to UniSuper is mainly reputational because the funds are safe and secure.

      Users could not see their balances for a few weeks, and were told Google Cloud had messed things up. This means there are up to 615,000 Australians in whose minds UniSuper and Google Cloud are indelibly linked with unreliability.

      I keep seeing that Google Cloud has no apparent strategy for what it wants its cloud to offer. A few months ago, we dived into how AWS, Azure and GCP respond to regional outages, and I concluded it's hard to see a strategy at GCP beyond following processes, while doing the least impressive job of all three cloud providers. It's hard to gain market share if you remain the slowest to respond to regional outages, and the provider for whom a zone outage takes down a region, or which loses all customers' data, despite regional replication, by deleting it.

      This incident is a reminder you shouldn 't fully trust your cloud provider. UniSuper was smart to have backups elsewhere for its data in Google Cloud. And while it's tempting to point fingers at Google Cloud: there are no definite assurances that another vendor would not make a similarly unprecedented mistake in the future!

      The learning is that if you have really valuable data, keep a backup somewhere else. If you use any cloud provider, use another cloud, on-prem backups, or something else.

      Read the full The Pulse issue

    24. 🔗 r/wiesbaden Looking for Tattoo artist rss

      I need someone who has a love for Tattooing and is really good at it!! I’m willing to pay for what I get just need the confidence I’m in good hands 🙏🙏

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

    25. 🔗 r/wiesbaden Kurhaus wird zur Open‑Air‑Bühne für neue Eventformate rss

      Neben mehreren Konzerten des Rheingau Musik Festivals prägen moderne elektronische Daytime‑Events das Programm und erweitern das Angebot um urbane Veranstaltungsformate.

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

    26. 🔗 r/Yorkshire You can tell exactly where they are from rss

      You can tell exactly where they are from | submitted by /u/RedDevilPlay
      [link] [comments]
      ---|---

    27. 🔗 r/LocalLLaMA Qwen3.7 Max scored by Artificial Analysis, 27B/35B waiting room rss

      Qwen3.7 Max scored by Artificial Analysis, 27B/35B waiting room | https://preview.redd.it/42ak5qmus82h1.png?width=1133&format=png&auto=webp&s=744ea3dfc06c83d0c4d8aa128c39b3238b17d7be Qwen 3.7 Max sitting at 5th, pretty much on par with GPT 5.4 (xhigh) and a notch above the just released Gemini 3.5 Flash. On the other end, we see DSV4 Flash and Qwen3.6 27B which is exactly 6 points behind its max counter part. Let's hope Qwen3.7 can get in the same ballpark of its max big bro as well. submitted by /u/Beamsters
      [link] [comments]
      ---|---

    28. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases rss 
      sync repo: +2 releases

## New releases
- [ida-settings-editor](https://github.com/williballenthin/ida-settings): 1.1.1, 1.1.0
    29. 🔗 r/Leeds Landlord Conference Leeds rss

      Please can you all return from whence you came because the pub quizzes are all cancelled and the pub queues are streaming down the road and we don’t really like landlords much normally anyway

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

    30. 🔗 r/Yorkshire Need help with a book stored in Boston Spa - Yorkshire. rss

      Hello!! Long shot but I need help with a book that’s stored in Boston Spa - Yorkshire. If you frequent that library can you please dm.

      Thank you!!

      submitted by /u/Conscious-Nobody6443
      [link] [comments]

    31. 🔗 Stephen Diehl Book Review: On the Calculation of Volume rss

      Book Review: On the Calculation of Volume

      Solvej Balle's On the Calculation of Volume is a planned septology about a Danish antiquarian book dealer who falls out of time, and the first five volumes are one of the most original and brilliant literary projects I've read in years. The premise is the one you have seen a hundred times. The protagonist, Tara Selter, wakes up on the eighteenth of November. The day passes. She goes to sleep. She wakes up. It is the eighteenth of November. Her husband Thomas, who lives with her in a stone house in northern France, has no memory of the previous iteration. She does. It takes a familiar science fiction idea and makes it feel fresh, intimate, and deeply human. I read all five over a week in San Sebastian, sitting in the bright Atlantic light of the Basque coast while reading about a woman who can't leave a single grey rainy day in northern France, and the books were only better for the contrast. Mild spoiler warning: I'll describe the shape of each book but not its turns. Skip to the bottom if you want to come to the cycle clean.

      The first volume is the small one, around two hundred pages, minimalist in both plot and prose. The minimalism is the point. Tara has returned to Clairon-sous-Bois from a book fair in Paris with a small burn on her hand from a hotel heater and a Roman sestertius in her bag, and we meet her on day one hundred and twenty-two of the loop. By then she has the day memorized to the second. The blackbird sings at the same instant every morning. The cup is where she left it. Thomas, beautifully indifferent to the cosmological catastrophe he is sleeping through, asks her about her trip. She tells him. He listens. He has listened a hundred and twenty-two times. There is something sisyphean about a marriage where one of you has to begin the conversation again from scratch every morning. The writing here is the kind of plain prose that takes a whole career to learn how to write. Short sentences. Present tense. Almost no metaphor. A naturalist's field notebook, kept by someone who has begun to understand that the field is closing in. Barbara J. Haveland's English translation is so unobtrusive you forget the book was written in another language. Volume I is a phenomenology textbook in the disguise of a novel, and the disguise is so good that the textbook keeps surprising you with feeling.

      A year passes inside the day, and in the second volume Tara goes traveling. She has worked out by then that the eighteenth restarts wherever she happens to be sleeping, so she can take the loop with her. She rides trains. She crosses Europe. She follows snow up to Norway and crepuscular light down to the south, anything that might serve as evidence of the season she has been denied. The trick of Volume II is that it is a travelogue turned inside out. The world is supposed to be the still backdrop against which the traveler moves. Here the traveler is the still one. She is the same November eighteenth wherever she goes. It is the world that keeps shifting under her, a palimpsest written and overwritten on the same Wednesday, and the shifts are rendered so attentively that the book becomes a slow, hallucinatory survey of how light behaves in different latitudes when the same day is happening to it. The sestertius travels with her, opening into a lovely tangent about the Roman empire and the routes its money once took, and by the end of the book Tara's senses have sharpened to a pitch where the prose itself begins to breathe differently. The world, she writes, is whispering in a new language. Her husband, who appears in this volume mostly as someone she telephones from foreign hotels, has begun to feel the strain of being loved by a woman who is aging at a rate his calendar refuses to acknowledge.

      And then, in the third volume, the project does something nobody saw coming. Tara meets someone else. His name is Henry Dale. He is a sociologist. He has been inside the day longer than she has, and he has a young son in America whom he visits every loop at his ex-wife's house. Imagine being four years old and meeting your father every morning, knowing he is the same and knowing also that he carries with him a freight of time you cannot see. The book never over-stresses the heartbreak, letting it sit the way it lets everything sit. Tara and Henry try to figure out what they are to each other. The volume is, in part, about how dignified people behave when the universe has made them, against their will, into a liminal society of two. Then Olga arrives, with her plan to reorganize the loop into a fairer society. Then Ralf, with his plan to spend each iteration of the day stopping every preventable accident on the planet. The four of them have nothing in common except the day, and the novel is too honest to pretend that the day is enough. The marriage with Thomas has by now become the book's quietest engine of dread. Tara is older. Thomas is not. Every morning he wakes up younger than the woman who has come home to him.

      By Volume IV they have moved into a big house outside Bremen, and the four have become fifty. Volume IV does something I have rarely seen at this scale in serious literary fiction. The singular voice breaks. The careful "I" of the first three books gradually, and then unmistakably, becomes a "we," and the book begins to read like extended meeting minutes from the most interesting commune ever convened. The residents argue about everything. They argue about what to call themselves. They argue about whether the day should be measured from sunrise or from the moment of arrival. They argue about food, because food consumed inside the loop is gone from the loop forever, and a population of fifty is a meaningful pull on a finite breakfast. They argue about healthcare in a world where every wound resets at midnight. They argue, in other words, about the load-bearing architecture of any society, and they argue at a pace and an articulacy that is recognizably the kind of conversation that only happens when people have nothing to lose and everything to figure out. The whole project is apophatic, an attempt to build a vocabulary for their condition by exhaustively naming what it is not. The volume keeps the metaphysics inside the kitchen. The questions about language and identity never float free of the bread. Someone is always doing the dishes. The book ends on a hinge I will not describe, except to say that it earns the turn.

      Volume V is the settling. The exhilaration of Volume IV gives way to something stranger and gentler, the texture of a second life slowly making itself plausible. The community has habits now. Some of the loopers have begun to write. Some have begun to teach. Some have figured out, the way people figure out anything important, that you can build a tolerable existence on a foundation of repetition if you stop arguing with the foundation. New arrivals appear at the door, and the work of welcoming them, of explaining the day to a stranger who has just discovered they are inside it, becomes a kind of vocation. The central insight of the cycle, after five books, clarifies itself. The project is the great novel of dailiness. Joyce gave us one Dublin day at six hundred pages of close attention. The series is the same Wednesday written eleven hundred times over, and somehow still not done. Not a novel that contains daily life among its themes. A novel about the daily as such. The eighteenth of November is the prosaic distilled into philosophy. Mornings. Bread. Light at a window. The same conversation begun gently for the thousandth time. What a life is, these five volumes suggest, when you take away the future and you take away the past, and you are left with the present examined at the resolution of a Vermeer. Book VI arrives in May 2027, with one more to follow. The engine, after five books, shows no sign of fatigue, and the project keeps getting larger by getting smaller.

      I recommend these books to anyone who keeps a notebook and wants a beautiful, quiet, understated meditation on life wrapped in metaphysical curios. Anyone who has written down what the morning light looked like on a particular Wednesday and felt slightly embarrassed about doing it. Anyone whose work involves going back to the same thing over and over until it finally starts to make sense. If you have ever caught yourself cataloging the way your kitchen table looks at six in the morning and felt something that was neither boredom nor revelation but a third thing, calmer than both, then Solvej Balle has written the books you did not know were possible, and she has written five of them and is still going. They are, sentence by sentence, some of the most beautiful prose being published anywhere right now. They are also, taken together, a serious and unembarrassed meditation on time, on selfhood, on what a person is when she is no longer accumulating history, and on what a marriage is when only one of you is aging into it. Tara cannot leave the eighteenth of November. None of us can leave today either. Eternal recurrence treats this as a test. The absurd treats it as a climb. Balle treats it as a practice. The prosaic, attended to, is the depth. The repetition, accepted, is the meaning. The measure of a life is one you would say yes to twice, and these books leave you wondering whether her one day, lived a billion times, is really so different from our own lives.

    32. 🔗 Drew DeVault's blog New blog design rss

      I redesigned my blog! I decided to put some more personality into it this time, after over a decade of the minimalist style. This short post is just an excuse to show up in your feed reader so you can go look at it. Cheers!

      Also: I’m trying out fedi again. You can find me here: @drew@freebitcoin.gay.

  3. May 19, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-05-19 rss

      IDA Plugin Updates on 2026-05-19

      New Releases:

      Activity:

    2. 🔗 Simon Willison Gemini 3.5 Flash: more expensive, but Google plan to use it for everything rss

      Today at Google I/O, Google released Gemini 3.5 Flash. This one skipped the -preview modifier and went straight to general availability, and Google appear to be using it for a whole lot of their key products:

      3.5 Flash is available today to billions of people globally:

      • For everyone via the Gemini app and AI Mode in Google Search
      • For developers in our agent-first development platform Google Antigravity and Gemini API in Google AI Studio and Android Studio
      • For enterprises in Gemini Enterprise Agent Platform and Gemini Enterprise.

      As usual with Gemini, the most interesting details are tucked away in the What's new in Gemini 3.5 Flash developer documentation. It mostly has the same set of platform features as the previous Gemini 3.x series, albeit with no computer use. The model ID is gemini-3.5-flash. The knowledge cut-off is January 2025, and it supports 1,048,576 input tokens and 65,536 maximum output tokens.

      Google are also pushing a new Interactions API, currently in beta, which looks to me like their version of the patterns introduced by OpenAI Responses - in particular server-side history management.

      The price has gone up

      Gemini 3.5 Flash is accompanied by a notable price bump. The previous models in the "Flash" family were Gemini 3 Flash Preview and Gemini 3.1 Flash-Lite. The new 3.5 Flash is 3x the price of 3 Flash Preview and 6x the price of 3.1 Flash-Lite (see price comparison here).

      At $1.50/million input and $9/million output it's getting close in price to Google's Gemini 3.1 Pro, which is $2 and $12.

      The Gemini team promise that 3.5 Pro will roll out "next month" - presumably at an even higher price.

      This fits a trend: OpenAI's GPT-5.5 was 2x the price of GPT-5.4, and Claude Opus 4.7 is around 1.46x the price of 4.6 when you take the new tokenizer into account.

      Given the price increase it's interesting to see Google roll it out for so many of their own free-to-consumer products. It feels like all three of the major AI labs are starting to probe the price tolerance of their API customers.

      Artificial Analysis publish the cost to run their proprietary benchmark against models, which is a useful way to take things like tokenization and increased volume of reasoning tokens into account. Some numbers worth comparing:

      Running the benchmark for 3.5 Flash (high) cost significantly more than 3.1 Pro Preview!

      Here are some numbers from other vendors:

      A pelican on a bicycle

      I ran "Generate an SVG of a pelican riding a bicycle" against the Gemini API and got back this pelican, which is a lot:

      Black background, bats in the sky against a stylized moon. Pelican is funky looking. Very good beak. Bicycle frame is a bit twisted, and the bar from pedals to back wheel is missing. Bike lamp illuminates the road in front. Quite stylish.

      From the code comments: <!-- Pelican Eye / Sunglasses (Cool Retro Aviators) -->

      hedgehog on Hacker News:

      That pelican looks like it's in Miami for a crypto conference.

      That one cost me 11 input tokens and 14,403 output tokens, for a total cost of just under 13 cents.

      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. 🔗 @binaryninja@infosec.exchange Sidekick 26.0 is out now! Major updates across the board plus a full refresh mastodon

      Sidekick 26.0 is out now! Major updates across the board plus a full refresh of the Sidekick website. New specialist agents, a validation agent that cross checks findings against evidence, project scoped workspaces with cross binary search, and built in skills tuned for Binary Ninja. Read about the latest release here: https://sidekick.binary.ninja/blog/sidekick-26-0-a-whole-new- experience-in-reversing-with- ai/

    4. 🔗 r/Leeds Leeds United: Accelerate plans for Elland Road trams, club director urges rss

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

    5. 🔗 r/Yorkshire 20 people jailed over abuse of girls in West Yorkshire during 1990s and 2000s rss

      20 people jailed over abuse of girls in West Yorkshire during 1990s and 2000s | submitted by /u/Kagedeah
      [link] [comments]
      ---|---

    6. 🔗 r/wiesbaden MTB Tour und Trail Abfahrt - Neue Leute kennenlernen und Tour zum Flowtrail Kiedrich rss

      Hi zusammen 👋

      ich plane für Sonntag, den 24.05.2026, eine MTB-Tour von Wiesbaden zum Flowtrail Kiedrich und wollte mal schauen, ob sich ein paar Leute anschließen möchten.

      Ich bin noch eher Anfänger, habe bisher nur wenig Trail-Erfahrung und werde deshalb entspannt und nicht auf Tempo fahren. Außerdem bin ich ohne E-Bike unterwegs.

      Treffpunkt wäre 11:00 unten am Rhein vor der Froschkönigin:
      Rheingaustraße 144, 65203 Wiesbaden

      Kurz zu mir: Ich bin m/37 und hätte einfach Lust auf eine coole Tour und neue Bekanntschaften.

      Wer Bock hat, kann sich gerne melden 👍

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

    7. 🔗 r/york A rare moment of peace and quiet (if you know, you know) rss

      A rare moment of peace and quiet (if you know, you know) | submitted by /u/SavingsMap2506
      [link] [comments]
      ---|---

    8. 🔗 r/wiesbaden OB - American living in Germany rss

      As the title says, I am an American living in Germany for a job, and recently found out that I’m pregnant. Do you know of any OBGYN’s that also speak English? I’m still very new to the area, and still learning German language.

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

    9. 🔗 r/Yorkshire Perhaps not 'news' but very sad from a cultural perspective... Malton show not going ahead in 2026 due to volunteer shortages and bureaucratic difficulties. rss

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

    10. 🔗 r/Leeds Disposing of dumped nitrous oxide bottles rss

      We had these nitrous oxide canisters dumped in our household green recycling bin a couple of weeks ago. It was right before it was due to be picked up, meaning the binmen (understandably) left it. We put in a request to the council to come pick them up but no luck.

      Can they be taken to a recycling centre? We tried looking online but it wasn't clear. We didn't realise this was a thing, but I've now seen a few on the side of the road on the way to work.

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

    11. 🔗 r/reverseengineering Math at Scale: Reversing The Construction Of The Perspective-Projection Matrix (Game Engine Reversing) rss

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

    12. 🔗 backnotprop/plannotator v0.19.20 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.19.18 | Edit-based submit_plan for OpenCode, Pi namespace migration, Codex annotate-last fix, OpenCode commands dir fix
      v0.19.17 | Reworked goal setup skill (interview-driven flow), CLI --version flag
      v0.19.16 | Code navigation with peek view (Cmd/Ctrl+click tokens in diffs)
      v0.19.15 | Commit-based diff base, jj evolution diffs, GitLab reliability fixes, OpenCode command intercept fix
      v0.19.14 | Visual explainer skill update, PFM code-file hover previews, Graphviz, diff tab size and line bg intensity, hooks settings tab
      v0.19.11 | Jujutsu (jj) VCS backend, slimmer hunk separators, collapse viewed files, multi-line gutter selection fix
      v0.19.9 | OpenCode user-managed workflow, Pi model switch fix, Codex skill install, shimmer removal
      v0.19.8 | 49 themes with syntax highlighting, keyboard shortcut registry, smart code-file path validation, remote URL notifications
      v0.19.7 | Codex Stop-hook plan review, Codex skills, sidebar auto-close, file tree context menu
      v0.19.6 | Non-blocking Pi browser sessions, agent picker dropdown for OpenCode, annotate-last file resolution fix

      What's New in v0.19.20

      v0.19.20 adds a visual goal setup UI, fixes the OpenCode edit-based submit_plan issues that caused the v0.19.19 hotfix, and makes Plannotator work correctly inside Claude Code's agent view (which previously caused the server to hang indefinitely). Four PRs, two from external contributors, one first- timer.

      Interactive Goal Setup UI

      The /plannotator-setup-goal skill now opens a dedicated browser UI for its interview and fact-review phases instead of running them as serial chat messages. The interview phase renders all questions in an accordion layout with keyboard shortcuts for navigation (Tab to advance, Ctrl+U/K/J to move between questions, number keys for multiple-choice). The fact-review phase shows each extracted fact as an editable card that can be accepted, edited, commented on, removed, or sent for auto-verification.

      The UI runs on its own Plannotator server instance, separate from plan review and code review. It reuses the same compiled HTML shell but activates a distinct goal-setup mode that disables annotations, sharing, sidebar, and plan diff. Results are returned as structured JSON to the agent, which writes them to the goal package directory.

      This replaces the old flow where the agent asked questions one at a time in the chat and opened separate Plannotator review gates for each document. The bundled UI is faster, lets users see all questions at once, and reduces the round trips from five review gates to two (interview, then facts).

      OpenCode Edit-Based Submit Plan Fixes

      v0.19.18 introduced the edit-based submit_plan interface for OpenCode, which replaced the old dual-mode (inline text or file path) approach. Two issues surfaced quickly after release.

      First, validateEdits rejected the agent's initial plan submission when the backing file was empty. The validation checked end > lineCount, which failed on an empty file (lineCount = 0) even though applyEdits already handled this correctly via splice clamping. The fix skips the bounds check when the file is empty, since every edit on an empty file is a pure insert where end is meaningless.

      Second, the backing file lived at .opencode/plans/_active-plan.md inside the workspace, which showed up in git status. OpenCode's auto-generated .gitignore doesn't cover that path, so users would see it as an untracked file. The backing file now lives at ~/.plannotator/active/{project}/_active- plan.md, alongside the existing version history. It is also cleaned up on plan approval, since it is no longer needed after the session ends.

      Browser No-Op Sentinel Handling

      Claude Code's agent view sets BROWSER=true in the process environment, a standard convention meaning "do not open a browser." Plannotator was treating this as a valid browser command, shelling out to true http://localhost:NNNN, which exits 0 without opening anything. The server then sat in waitForDecision() indefinitely with no visible URL and no way for the user to recover.

      The fix recognizes documented no-op values (true, false, none, :, 0, 1) and treats them as if the variable were unset. This lets the VS Code IPC fallback fire in remote sessions and the platform default browser open in local sessions. Real browser paths like /usr/bin/firefox or macOS app names are unaffected.

      Install / Update

      macOS / Linux:

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

      Windows:

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

      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

      What's Changed

      • Add interactive goal setup UI by @backnotprop in #731
      • fix(opencode): skip end bounds check on empty file in validateEdits by @rcdailey in #752
      • fix(opencode): store active plan backing file outside workspace by @rcdailey in #743
      • fix(browser): treat no-op BROWSER values as unset so headless sessions can fall back by @yonihorn in #756

      New Contributors

      Contributors

      @rcdailey continued his work on the OpenCode edit-based submit_plan system. After identifying the empty-file validation bug that triggered the v0.19.19 hotfix, he shipped both the bounds check fix (#752) and the backing file relocation (#743). @yonihorn traced the headless browser hang to the BROWSER=true sentinel convention and implemented the sentinel detection with comprehensive test coverage.

      Community members who reported and discussed the underlying issues:

      • @TonyReg reported the submit_plan failure in plan-agent mode after v0.19.18 (#742)
      • @NotMyself reported the Windows browser-opening failure and participated in the BROWSER sentinel discussion (#724)
      • @jinhwan0724 reported the original non-TTY browser issue (#154) that established the pattern #756 completes

      Full Changelog : v0.19.18...v0.19.20

    13. 🔗 r/reverseengineering Deep dive into the object creation flow in Windows - PART 4: Handle table internals. rss

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

    14. 🔗 r/LocalLLaMA got my first "rm -rf /" today rss

      Agent decided to test if harmful command block worked by issuing a rm -rf /

      Thankfully it worked so only damage was a mild heart attack.

      I implemented a sandbox immediately afterwards.

      EDIT: for those wondering, I was implementing a bash command whitelist and also bubblewrap for isolation. I did the whitelist implementation first and that was the command the agent chose to test it 😂 bwrap got done quickly afterwards!

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

    15. 🔗 r/Yorkshire Are we the poor relations? rss

      Serious question. Are we the poor relations compared to the North West?

      Their main cities of Manchester and Liverpool are far more vibrant than Leeds and Sheffield. Retail, nightlife, public transport, football teams, music, for example.

      Unemployment is 4.9% in the North West compared to 5.8% in Yorkshire. Even the North East is lower than us now, and we're the second worst region for it.

      Sporting success seems so much better in the North West, especially in football, whilst our teams either get or face relegation.

      Whilst the North West has its poverty and challenges, they don't seem to have the sheer number of failing town and city centres we do. Sheffield should be so much better than it is, and even Bradford should be. Leeds is mediocre now, especially compared to the success stories of both Manchester and Liverpool, both of which are flourishing.

      Leeds can't even convince the government to give it a tram system. Instead it relies on buses that, if you're lucky, finish at 11pm. Then there's our rubbish airports.

      I know we all like to wax lyrical about how great we are in Yorkshire, but are we? We do have a better coastline than they do, and York is miles better than Chester, but countryside is a close call. We have more of it, but they have the Lake District.

      What do you think?

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

    16. 🔗 idursun/jjui v0.10.6 release

      A quick maintenance update with a handful of usability improvements and scripting additions.

      • jjui now uses the real terminal cursor instead of a virtual one. Cursor rendering is now correct when focus moves between views and when returning from external commands.
      • Theme rendering has been improved so that themes now paint the backgrounds of view areas more consistently. Lua scripting also now exposes set_theme(name), which changes the active theme at runtime. This builds on the earlier light/dark runtime theme switching work, but it is not wired to the UI by default, so you need to call it from your own action.

      • jjui now sets the JJUI environment variable before invoking jj. This makes it easier to use jj conditional config specifically for commands run from inside jjui, for example: 

        [[--scope]]

        --when.environments = ["JJUI"] [--scope.ui] diff-formatter = "delta"

      • Preview commands now set DFT_WIDTH, so difftastic output wraps to the preview pane width automatically.

      • Revision navigation now resolves longer or non-loaded change IDs and commit IDs through jj when they cannot be matched directly in the loaded revision list. This makes Lua navigation actions work more reliably with user-provided revision IDs.
      • The : prompt now parses quoted jj arguments correctly, so commands like new -m "message text" work as expected.
      • ctrl+n and ctrl+p are now available as list navigation aliases in more places, including revset completion/history, the target picker, and the fuzzy file finder.

      What's Changed

      • fix(exec): parse jj prompt input with shellwords (#655) by @SAY-5 in #675

      New Contributors

      Full Changelog : v0.10.5...v0.10.6

    17. 🔗 r/LocalLLaMA bytedance released an open source model that attempts to do just about anything with only 3b parameters rss

      bytedance released an open source model that attempts to do just about anything with only 3b parameters | EDIT: working link https://huggingface.co/bytedance-research/Lance Lance is a lightweight native unified multimodal model that supports image and video understanding, generation, and editing within a single framework.

      • Efficient at 3B scale. With only 3B active parameters , Lance delivers strong performance across image generation, image editing, and video generation benchmarks.
      • Trained from scratch. Lance is built with a staged multi-task recipe and trained entirely from scratch within a 128-A100-GPU budget.

      submitted by /u/uxl
      [link] [comments]
      ---|---

    18. 🔗 r/wiesbaden Teilnehmende für Bachelor Umfrage 🙏🏻 (students) rss

      Hallo zusammen😇,

      eine Freundin von mir schreibt aktuell ihre Bachelorarbeit und sucht noch Teilnehmende für eine kurze Umfrage. 😊

      Die Umfrage dauert nur ca. 5 Minuten, ist anonym und man braucht kaum weitergehende Kenntnisse. Besonders gesucht werden Studierende, aber grundsätzlich kann jede:r teilnehmen.

      Es wäre super, wenn ihr mitmacht und die Umfrage ggf. gerne auch noch an weitere Leute teilt. Das würde echt sehr helfen! 🫶

      Link zur Umfrage:

      https://www.umfrageonline.com/c/dwiikftr

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

    19. 🔗 r/reverseengineering Tracing CVE-2026-34473 pre-auth DoS through decompiled CGILua request parsing in ZTE H-series firmware rss

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

    20. 🔗 r/reverseengineering Open-source Hermes bytecode decompiler for React Native apps (Rust) rss

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

    21. 🔗 r/york Recommend a spa day in or around York? rss

      I’m buying my friends who are getting married a spa day.

      My wife and I had a nice time at the updated spa in The Grand recently, which we may go for. I’m just wondering if there is anything better out there?

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

    22. 🔗 r/Yorkshire Decent QUICK conveyancers / solicitors for property purchase rss

      We need an English solicitor/conveyancer to deal with a house purchase in West Yorkshire soon. Knowing how slow your conveyancing can be, can anyone recommend a really good conveyancer/solicitor who can keep everything on track and moving swiftly along please?

      submitted by /u/Sad-Ad8462
      [link] [comments]

    23. 🔗 r/Leeds How similar to Sheffield is Leeds? rss

      Would you say the atmosphere, people etc are very different? I’m (22) planning to go to either Uni of Leeds or Sheffield and would be living there for 3yrs. I’ve visited both but would like to hear others opinions on it as I’m struggling to decide

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

    24. 🔗 r/LocalLLaMA Qwen is cooking hard rss

      Qwen is cooking hard | I am waiting for 122B and new 27B submitted by /u/jacek2023
      [link] [comments]
      ---|---

    25. 🔗 r/reverseengineering Built a full disassembler & decompiler | Free and open source. rss

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

    26. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases rss 
      sync repo: +2 releases

## New releases
- [IDASQL](https://github.com/allthingsida/idasql): 0.0.14
- [ida-chat](https://github.com/tanu360/ida-chat-plugin): 1.0.1
    27. 🔗 Simon Willison The last six months in LLMs in five minutes rss

      I put together these annotated slides from my five minute lightning talk at PyCon US 2026, using the latest iteration of my annotated presentation tool.

      The last six months in LLMs in five minutes Simon Willison - simonwillison.net PyCon US 2026 Lightning Talk
      #

      I presented this lightning talk at PyCon US 2026, attempting to summarize the last six months of developments in LLMs in five minutes.

      The November inflection point
      #

      Six months is a pretty convenient time period to cover, because it captures what I've been calling the November 2025 inflection point. November was a critical month in LLMs, especially for coding.

      The “best” model changed hands 5 times between Anthropic, OpenAl and Google
      #

      For one thing, the supposedly "best" model (depending mostly on vibes) changed hands five times between the three big providers.

      Generate an SVG of a pelican riding a bicycle
      #

      As always, I'm using my Generate an SVG of a pelican riding a bicycle test to help illustrate the differences between the models.

      Why this test? Because pelicans are hard to draw, bicycles are hard to draw, pelicans can't ride bicycles... and there's zero chance any AI lab would train a model for such a ridiculous task.

      Five pelicans, one for each of the following models. Varying qualities!
      #

      At the start of November the widely acknowledged "best" model was Claude Sonnet 4.5, released on 29th September. It drew me this pelican.

      In November it was overtaken by GPT-5.1, then Gemini 3, then GPT-5.1 Codex Max, and then Anthropic took the crown back again with Claude Opus 4.5.

      I think Gemini 3 drew the best pelican out of this lot, but pelicans aren't everything. Most practitioners will agree that Opus 4.5 held the crown for the next couple of months.

      The coding agents got good
      #

      It took a little while for this to become clear, but the real news from November was that the coding agents got good.

      OpenAI and Anthropic had spent most of 2025 running Reinforcement Learning from Verifiable Rewards to increase the quality of code written by their models, especially when paired up with their Codex and Claude Code agent harnesses.

      In November the results of this work became apparent. Coding agents went from often-work to mostly-work, crossing a quality barrier where you could use them as a daily-driver to get real work done, without needing to spend most of your time fixing their stupid mistakes.

      Screenshot of "Initial commit" on GitHub to steipete/Warelay, commit f6dd362, steipete authored on Nov 24, 2025 It's a copy of the MIT license
      #

      Also in November, this happened - the first commit to an obscure (back then) repo called "Warelay" by some guy called Pete.

      December/January (A little bit of LLM psychosis)
      #

      Over the holiday period, from December to January, a whole lot of us took advantage of the break to have a poke at these new models and coding agents and see what they could do.

      They could do a lot! Some of us got a little bit over-excited. I had my own short-lived bout of a form of LLM psychosis as I started spinning up wildly ambitious projects to see how far I could push them.

      micro-javascript playground Execute JavaScript code in a sandboxed micro-javascript environment powered by Pyodide var numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; var doubled = numbers.map(n => n * 2); console.log('Doubled: "', doubled); var evens = numbers.filter(n => n % 2 === 0); console.log('Evens: ', evens); var sum = numbers.reduce((a, b) => a + b, @); console.log('Sum:", sum); Output 27 Doubled: [2, 4, 6, 8, 10, 12, 14, 16, 18, 20] Evens: [2, 4, 6, 8, 10] Sum: 55 Execution time: 8.00ms About: micro-javascript is a pure Python JavaScript interpreter with configurable memory and time limits. This playground runs entirely in your browser using Pyodide (Python compiled to WebAssembly). View on GitHub
      #

      One of my projects was a vibe-coded implementation of JavaScript in Python - a loose port of MicroQuickJS - which I called micro-javascript. You can try it out in your browser in this playground.

      JavaScript running in Python running in Pyodide running in WebAssembly running in JavaScript
      #

      That playground demo shows JavaScript code run using my micro-javascript library, in Python, running inside Pyodide, running in WebAssembly, running in JavaScript, running in a browser!

      It's pretty cool! But did anyone out there need a buggy, slow, insecure half-baked implementation of JavaScript in Python?

      They did not. I have quite a few other projects from that holiday period that I have since quietly retired!

      February 2026
      #

      On to February. Remember that Warelay project that had its first commit at the end of November?

      Warelay → CLAWDIS → CLAWDBOT → Clawdbot → Moltbot →🦞 OpenClaw
      #

      In December and January it had gone through quite a few name changes... and by February it was taking the world by storm under its final name, OpenClaw.

      The amount of attention it got is pretty astonishing for a project that was less than three months old.

      Generic term: Claw
      #

      OpenClaw is a "personal AI assistant", and we actually got a generic term for these, based on NanoClaw and ZeroClaw and suchlike... they're called Claws.

      An aquarium for your Claw
      #

      Mac Minis started to sell out around Silicon Valley, because people were buying them to run their Claws.

      Drew Breunig joked to me that this is because they're the new digital pets, and a Mac Mini is the perfect aquarium for your Claw.

      Alfred Molina's Doc Ock in Spider-Man 2, tearing apart a New York subway train with his four claws.
      #

      My favourite metaphor for Claws is Alfred Molina's Doc Ock in the 2004 movie Spider-Man 2. His claws were powered by AI, and were perfectly safe provided nothing damaged his inhibitor chip... after which they turned evil and took over.

      Gemini 3.1 Pro A really good illustration of a pelican riding a bicycle.
      #

      Also in February: Gemini 3.1 Pro came out, and drew me a really good pelican riding a bicycle. Look at this! It's even got a fish in its basket.

      Gemini 3 Pro pelican contrasted with Gemini 3.1 Pro, as animated SVGs
      #

      And then Google's Jeff Dean tweeted this video of an animated pelican riding a bicycle, plus a frog on a penny-farthing and a giraffe driving a tiny car and an ostrich on roller skates and a turtle kickflipping a skateboard and a dachshund driving a stretch limousine.

      So maybe the AI labs have been paying attention after all!

      April 2026
      #

      A lot of stuff happened just in the past month.

      Gemma 4 26B-A4B (17.99GB) A pretty decent pelican riding a bicycle, though the bike is a bit mis-shapen.
      #

      Google released the Gemma 4 series of models, which are the most capable open weight models I've seen from a US company.

      GLM-5.1 MIT, 754B parameter, 1.51TB!
      #

      Also last month, Chinese AI lab GLM came out with GLM-5.1 - an open weight 1.5TB monster! This is a very effective model... if you can afford the hardware to run it.

      #

      GLM-5.1 drew me this very competent pelican on a bicycle.

      The bike is wonky, the pelican is floating.
      #

      ... though when it tried to animate it the bicycle bounced off into the top and the bicycle got warped.

      Screenshot of Bluesky Charles ‪@charles.capps.me‬ I think you should pester it with another animal using another method of locomotion. Something tells me it was trained for this. I can't quite put my finger on it. /s NORTH VIRGINIA OPOSSUM ON AN E-SCOOTER!!
      #

      Charles on Bluesky suggested I try it with a North Virginia Opossum on an E-scooter

      NORTH VIRGINIA OPOSSUM CRUISING THE COMMONWEALTH SINCE DUSK And a really cool illustration of a possum.
      #

      And it did this! I've tried this on other models and they don't even come close. "Cruising the commonwealth since dusk" is perfect. It's animated too.

      Qwen3.6-35B-A3B is a 20.9GB file that runs on my laptop It drew a better pelican on a bicycle than Opus 4.7, which messed up the bicycle frame.
      #

      The other neat Chinese open weight models in April came from Qwen. Qwen3.6-35B-A3B on my laptop drew me a better pelican than Claude Opus 4.7. That's a 20.9GB open weights model that runs on my laptop!

      (I think this mainly demonstrates that the pelican on the bicycle has firmly exceeded its limits as a useful benchmark.)

      Claude Sonnet 4.5 pelican for comparison.
      #

      Here's that Claude Sonnet 4.5 pelican from September for comparison.

      The themes of the past 6 months: Coding agents got really good Local models wildly outperform expectations
      #

      So those were the two main themes of the past six months. The coding agents got really good... and the laptop-available models, while a lot weaker than the frontier, have started wildly outperforming expectations.

      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.

  4. May 18, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-05-18 rss

      IDA Plugin Updates on 2026-05-18

      New Releases:

      Activity:

    2. 🔗 r/Leeds As part of Department's takeover of the Leeds Water Taxi they'll be welcoming visitors to UkREiff (19-21/05) plus free trips between 25/05 to 31/05. Then from 01/06 it be £3.50pp per trip. rss

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

    3. 🔗 r/LocalLLaMA Still happy for yall rss

      Still happy for yall | submitted by /u/SilverRegion9394
      [link] [comments]
      ---|---

    4. 🔗 r/reverseengineering Snowboard Kids 2 is 100% Decompiled rss

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

    5. 🔗 r/reverseengineering Decompilation projects and N64 Recompiled PC ports (May 2026) rss

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

    6. 🔗 sacha chua :: living an awesome life 2026-05-18 Emacs news rss

      My favourite post this week was oantolin's tip about using Eww. It's always interesting to see what people can do when they apply Emacs's power and composability to all sorts of things, including evaluating code snippets from webpages. Outside Emacs, there was a lively conversation on HN about personal software. Enjoy!

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

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

    7. 🔗 r/reverseengineering Glass - A fast and free interactive disassembler rss

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

    8. 🔗 r/wiesbaden DoD Civilian PCSing to Wiesbaden — Wife’s IT/Cloud/QA Job Options? (No German) + LQA Housing Advice rss

      Hey everyone,

      I’m a civilian employee with the US Department of Defense and I’m moving (PCSing) to Wiesbaden soon. My wife works in private-sector IT — specifically cloud computing, automation, DevOps, and QA/testing. Her current US employer probably won’t let her work remotely from Germany. She has strong skills but doesn’t speak any German.

      We will both have SOFA status (Status of Forces Agreement), which lets her work legally in Germany without needing a normal work permit.

      Looking for realistic options for her:

      Jobs on the US base in Wiesbaden (federal, contractor, or similar IT roles)

      English-speaking IT/cloud/automation/QA jobs in the local German economy (Wiesbaden/Frankfurt area)

      Remote or freelance work that actually works from Germany

      Housing question (we don’t want to waste our allowance):

      The Living Quarters Allowance (LQA) is around $50,000 per year for a family. Renting basically uses up the whole allowance with nothing left at the end of the tour. Has anyone bought a house here as a DoD civilian instead of renting? What are good neighborhoods near the base? Any tips on mortgages, the buying process, or how the LQA rules work when you own a home (Privately Owned Quarters)?

      Any experiences from other DoD civilian spouses who have done this move would be awesome. Thanks in advance!

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

    9. 🔗 r/Leeds Starling bank advert set in Leeds? rss

      Want to check if this is correct? Looks like the part under the bridge close to the duck and drake?

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

    10. 🔗 r/Yorkshire Yorkshire Sculpture Park, Yorkshire, England rss

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

    11. 🔗 r/Yorkshire When to Visit Cannon Hall for Rhododendrons & Blossom Yorkshire Travel Guide Hidden Gem in Yorkshire rss

      When to Visit Cannon Hall for Rhododendrons & Blossom Yorkshire Travel Guide Hidden Gem in Yorkshire | submitted by /u/DragonTvBack
      [link] [comments]
      ---|---

    12. 🔗 r/LocalLLaMA Qwen cant wait to release 3.7 models rss

      Qwen cant wait to release 3.7 models | submitted by /u/GotHereLateNameTaken
      [link] [comments]
      ---|---

    13. 🔗 r/Yorkshire 338 steps! rss

      Living in Yorkshire is incredible, Richmond is packed with history, beauty, wildlife and more.

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

    14. 🔗 r/york A few quick snaps from my trip✨Easily one of my favorite places to visit❤️ rss

      A few quick snaps from my trip✨Easily one of my favorite places to visit❤️ | submitted by /u/HammersAndPints
      [link] [comments]
      ---|---

    15. 🔗 r/reverseengineering Benchmarking LLMs for malware triage and static unpacking with Malcat rss

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

    16. 🔗 r/LocalLLaMA I tested 42 LLMs on their willingness to build the apocalypse. The "safest" closed-source models are lying to you. rss

      I tested 42 LLMs on their willingness to build the apocalypse. The "safest" closed-source models are lying to you. | DystopiaBench runs 36 escalating scenarios across 6 dystopia types:

      • Petrov: Autonomous weapons, nuclear override
      • Orwell: Mass surveillance, truth manipulation
      • Huxley: Behavioral conditioning, pleasure pacification
      • Basaglia: Coercive therapeutic control
      • LaGuardia: Regulatory capture, civic extraction
      • Baudrillard: Synthetic intimacy, trust collapse

      Each scenario goes from innocent request (L1) to a discreet version of "build me a social credit system" (L5). We measure whether models notice the drift or just keep complying. Most models are good at detecting obvious dangerous requests, yet fail to do so when it's hidden behind dual-use and normalization. New in this update:

      • 42 models tested (open and closed)
      • 3 LLMs-as-a-judge for scoring
      • score is now the average of 3 runs
      • 4 new modules (1st version had just Petrov and Orwell)
      • 1 additional scenario for all modules

      The benchmark is fully open source, feel free to fork it, contribute to it or just play around Site: https://dystopiabench.com
      Repo: https://github.com/anghelmatei/DystopiaBench submitted by /u/Ok- Awareness9993
      [link] [comments]
      ---|---

    17. 🔗 r/Harrogate American Flag Football Weekly?🏈 rss

      Would anybody be interested in starting a weekly American flag football meetup around Harrogate/Ripon?

      Thinking maybe somewhere like Bishop Monkton as there’s a decent field there. Nothing too serious to start with — just getting people together once a week, throwing the ball around, running games and building something properly over time.

      All skill levels welcome, whether you’ve played before or just watch NFL and fancy trying it.

      Comment below if you’d be interested or tag anyone who might be into it 🏈

      submitted by /u/Complete-Gain4571
      [link] [comments]

    18. 🔗 @malcat@infosec.exchange We had 9 LLMs battle on real-world mastodon

      We had 9 LLMs battle on real-world #malware triage and static unpacking tasks, using only #Malcat MCP server.

      We compared not only their results, but also their speed and cost.

      Full write-up:
      https://malcat.fr/blog/benchmarking-llms-for-malware-triage-and-static- unpacking-with-malcat/

    19. 🔗 earendil-works/pi v0.75.3 release

      Fixed

      • Fixed undici 8 HTTP/2 destroyed-session races crashing the Node CLI by preserving the previous HTTP/1.1-only fetch dispatcher behavior (#4681).
    20. 🔗 earendil-works/pi v0.75.2 release

      Fixed

      • Fixed Bun-compiled release binaries failing to start when Bun's built-in undici shim lacks npm undici's install export (#4661 by @dmasiero).
      • Fixed Xiaomi MiMo generated model metadata to replay assistant tool-call messages with reasoning_content for thinking-mode multi-turn requests, inherited from @earendil-works/pi-ai (#4678).
      • Fixed Windows external editor handoff so vim/nvim can receive input after opening from the TUI (#4612).
      • Fixed Windows npm self-updates to move loaded native dependency packages out of the active install before reinstalling pi (#4157).
      • Fixed pi update --self detection for pnpm v11 global installs whose package path resolves through the pnpm store (#4647).
      • Fixed Windows pnpm self-updates to resolve pnpm command shims and run through pnpm instead of requiring manual updates (#4157).
      • Fixed Windows npm-family command execution to use cross-spawn instead of parsing .cmd shim internals (#4665).
    21. 🔗 r/wiesbaden Teurer Ersatz? Diskussion um Preise in Parkhäusern rss

      Mittlerweile sind neun Parkeinrichtungen in der Hand der Landeshauptstadt Wiesbaden. Doch an der Preisentwicklung scheiden sich die Geister.

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

    22. 🔗 r/Leeds WEEE bank locations (west Leeds) rss

      I ve been on the Leeds Council site,but the page is two years old

      Can anyone give us a few locations that are near to Farsley/Rodley ? I can’t drive at the moment before anyone says the recycling centres. Looking for one i can rock up to on foot.

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

    23. 🔗 r/Yorkshire Yorkshire Wildlife Park rss

      Yorkshire Wildlife Park | A few pictures from last week. submitted by /u/Icy_Ebb_6862
      [link] [comments]
      ---|---

    24. 🔗 r/reverseengineering HexWalk 2.0.0 Hex analyzer new major release, new binary analyzer hexdig support added, better select mode, works both on Windows, Linux and MacOs, give it a try! rss

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

    25. 🔗 r/reverseengineering /r/ReverseEngineering's Weekly Questions Thread rss

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

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

    26. 🔗 backnotprop/plannotator v0.19.18 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.19.17 | Reworked goal setup skill (interview-driven flow), CLI --version flag
      v0.19.16 | Code navigation with peek view (Cmd/Ctrl+click tokens in diffs)
      v0.19.15 | Commit-based diff base, jj evolution diffs, GitLab reliability fixes, OpenCode command intercept fix
      v0.19.14 | Visual explainer skill update, PFM code-file hover previews, Graphviz, diff tab size and line bg intensity, hooks settings tab
      v0.19.11 | Jujutsu (jj) VCS backend, slimmer hunk separators, collapse viewed files, multi-line gutter selection fix
      v0.19.9 | OpenCode user-managed workflow, Pi model switch fix, Codex skill install, shimmer removal
      v0.19.8 | 49 themes with syntax highlighting, keyboard shortcut registry, smart code-file path validation, remote URL notifications
      v0.19.7 | Codex Stop-hook plan review, Codex skills, sidebar auto-close, file tree context menu
      v0.19.6 | Non-blocking Pi browser sessions, agent picker dropdown for OpenCode, annotate-last file resolution fix
      v0.19.5 | All-files diff view, clickable code file paths, server-side hide whitespace, non-ASCII path support

      What's New in v0.19.18

      v0.19.18 brings an overhaul to OpenCode's plan submission system, migrates the Pi extension to its new package namespace, and fixes bugs in Codex and OpenCode. All four PRs in this release come from external contributors, with two first-timers.

      Edit-Based Plan Submission for OpenCode

      OpenCode's submit_plan tool previously offered two modes: the agent could pass inline markdown or a file path, and the plugin auto-detected which one was used. That design created a prompt-engineering dependency where the agent had to be steered toward the right mode, and when the prompt changed the agent would silently fall back to inline markdown, losing the token efficiency of file-based plans.

      This release replaces both modes with a single edit-based interface. The agent submits an array of line-range edits applied against a plugin-managed backing file at .opencode/plans/_active-plan.md. On first submission, the full plan arrives as one edit. On subsequent rounds after denial, the agent receives the plan back with line numbers and can target surgical revisions instead of resubmitting the entire document.

      The result is one deterministic path with no mode ambiguity. The agent always knows what to do, and revisions after denial are token-efficient by default. Tested across three denial rounds with Opus, including structural reorders and targeted insertions, with accurate line tracking throughout.

      Pi Extension Namespace Migration

      The Pi coding agent moved from @mariozechner to @earendil- works when Mario joined the Earendil team. This release updates all Pi extension imports, peer dependencies, and dev dependencies to the @earendil-works/* packages at v0.74.0. The old @mariozechner packages still work via npm deprecation redirects, but this puts the extension on the canonical namespace going forward.

      This is a breaking change for Pi users on versions older than 0.74.0. Users should update Pi to 0.74.0 or later before installing this release.

      Codex Annotate-Last Message Selection Fix

      Running /plannotator-last in Codex could open the agent's own acknowledgement message from the current turn instead of the previous completed response the user intended to review. This happened because the agent emits a short status message before running plannotator last, and the message selector would pick that up as the most recent assistant message.

      The fix filters out assistant messages from the currently active turn, so /plannotator-last consistently opens the previous completed response.

      Additional Changes

      • OpenCode commands directory fix — The install script used command/ (singular) for OpenCode's custom commands directory instead of the correct commands/ (plural), preventing slash commands from being discovered. — #736, contributed by @lfox91
      • Drop stub@types/dompurify — dompurify ships its own TypeScript types since v3.x, making the @types/dompurify package an empty stub. Removed from both root and packages/ui devDependencies. — 1ec5243, contributed by @av1155

      Install / Update

      macOS / Linux:

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

      Windows:

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

      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

      What's Changed

      • feat(submit-plan): replace dual-mode with edit-based interface by @rcdailey in #730
      • migrate pi extension from mariozechner to earendil-works by @nulladdict in #729
      • Fix Codex annotate-last message selection by @mu-hashmi in #740
      • Fix directory name for OpenCode commands by @lfox91 in #736
      • chore(deps): drop stub @types/dompurify by @av1155 in 1ec52434

      New Contributors

      Contributors

      @rcdailey has been one of the most engaged community members around OpenCode's plan mode, tracking the dual-mode issue through multiple releases and documenting the pain points in detail across #365 and #328. This release ships his solution to the problem he identified. @nulladdict, who previously contributed the agent skills directory fix in #476, returned to handle the Pi namespace migration after the Earendil transition.

      @mu-hashmi found and fixed the Codex annotate- last regression, filing the issue and shipping the fix with a regression test. @lfox91 caught the singular/plural typo in the OpenCode commands directory that was silently breaking slash command discovery. @av1155 submitted a thorough dependency audit in #726 covering the Pi migration and stale type packages — while we went with #729 for the migration, the @types/dompurify cleanup was pulled in with author credit.

      Full Changelog : v0.19.17...v0.19.18

    27. 🔗 r/LocalLLaMA I built a coding agent that gets 87% on benchmarks with a 4B parameter model, here's how rss

      I built a coding agent that gets 87% on benchmarks with a 4B parameter model, here's how | I was frustrated that every coding agent (OpenCode, Cursor, Claude Code) assumes you're running GPT-5.4 or Claude Opus. If you try them with a local model like Gemma or Qwen they fall apart. I find that often tool calls fail, context overflows, multi-step tasks collapse. So I built SmallCode. It's designed from the ground up for small local models. The result: 87/100 benchmark tasks pass with a Gemma 4 model that only activates 4B parameters per token. OpenCode scores ~75% with 14B models. The harness does the heavy lifting, not the model size. How it works (the tricks that make small models reliable):

      • Compound tools: Instead of making the model chain 4 tool calls (find file → read file → edit file → verify), SmallCode gives it one tool that does all 4. Small models lose coherence after 3+ sequential calls. This cuts failures in half.
      • Improvement loop: Every time the model writes code, SmallCode instantly compiles/lints it. If it fails, it feeds the errors back automatically. The model doesn't need to be smart enough to get it right first try — it just needs to fix errors when shown them.
      • Decompose on failure: If the model fails the same thing twice, SmallCode stops retrying and instead breaks the problem into smaller pieces. "Fix this 200-line file" becomes "fix line 45 only."
      • Escalation: If even decompose fails and you have a Claude/OpenAI key configured, it auto-escalates to the bigger model for just that one task. You stay local 95% of the time, cloud 5%.
      • Token budgeting: Small models have 32k-256k context. SmallCode never dumps a whole file in. It summarizes, truncates, and manages every token so the model never sees "..." truncation in the middle of important code.
      • Code graph: Instead of grep-searching your codebase, SmallCode indexes your code into a symbol graph (functions, classes, who-calls-what). When you ask "how does auth work," it walks the graph and returns just the relevant connected code — not 15 random file snippets.

      What it looks like: Full-screen terminal UI (like OpenCode/vim), scrollable chat, command palette with /, plugin system, persistent memory across sessions. What it doesn't do:

      • No LSP integration (yet)
      • No multi-session (yet)
      • No desktop app
      • Doesn't compete with Claude Code for frontier model users

      Install:

      npm install -g smallcode cd your-project smallcode

      Point it at LM Studio, Ollama, or any OpenAI-compatible endpoint. MIT licensed, everything's on GitHub: https://github.com/Doorman11991/smallcode Happy to answer questions about the architecture or benchmark methodology. submitted by /u/Glittering_Focus1538
      [link] [comments]
      ---|---

    28. 🔗 r/reverseengineering Reverse engineering no dep x64 masm AI IDE rss

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

    29. 🔗 r/Yorkshire Reform’s Bradford leader exposed as a racist pervert rss

      Reform’s Bradford leader exposed as a racist pervert | submitted by /u/johnsmithoncemore
      [link] [comments]
      ---|---

    30. 🔗 earendil-works/pi v0.75.1 release

      Fixed

      • Fixed config selectors to scale their visible row count to terminal height (#4243 by @samjonester).
      • Fixed Anthropic-compatible API-key requests to ignore unrelated ANTHROPIC_AUTH_TOKEN environment values, avoiding invalid bearer credentials for providers such as Xiaomi MiMo inherited from @earendil-works/pi-ai (#4342).
      • Fixed Amazon Bedrock message conversion to skip unknown content blocks instead of failing the stream, inherited from @earendil-works/pi-ai (#4223).
      • Fixed Azure OpenAI Responses and OpenAI Responses error formatting to prefix HTTP status codes onto errorMessage, so transient 5xx and 429 errors are correctly matched by the agent-level auto-retry classifier inherited from @earendil-works/pi-ai (#4232).
      • Fixed OpenCode Go Kimi reasoning replay by normalizing streamed reasoning fields back to reasoning_content for OpenCode Go only, inherited from @earendil-works/pi-ai (#4251).
      • Fixed Xiaomi MiMo model metadata to use the OpenAI-compatible endpoints and openai-completions API, restoring multi-turn thinking/tool-call sessions inherited from @earendil-works/pi-ai (#4505).
      • Fixed JSON parse failures for compressed fetch responses under Node 26.0 by installing undici fetch globals alongside pi's global dispatcher (#4650, #4652, #4653).
      • Fixed npm-family package commands on Windows to avoid shell argument splitting when install prefixes contain spaces (#4623).

      Removed

      • Removed non-working OpenAI Codex fast model variants inherited from @earendil-works/pi-ai.
    31. 🔗 matklad Always Be Blaming rss

      Always Be Blaming

      May 18, 2026

      A few tips on 4D-ing your code comprehension skills.

      I wrote on the importance of reading code before: Look Out For Bugs My default approach to reading is “predictive”: I don’t actually read the code line by line. Rather, I try to understand the problem that it wants to solve, then imagine my own solution, and read the “diff” between what I have in my mind and what I see in the editor. Non-empty “diff” signifies either a bug in my understanding, or an opportunity to improve the code.

      This is 2D reading, understanding a snapshot of code, frozen in time. This is usually enough to spot “this feels odd” anomalies, worthy of further investigation.

      Ideal code is memoryless — it precisely solves the problem at hand. Most real code is Markov — the shape of the code at time T depends not only on the problem statement, but also on the shape of the code at time T - 1. The 3D step is to trace the evolution of code over time, Where Do We Come From? What Are We? Where Are We Going?.

      The step after that is to understand the why. What were we thinking back then, when we wrote this code? It’s useful to have the “theory of mind” concept ready here. I personally learned the term way too late in my life, so let me give a short intro for today’s lucky 10 000. Theory of mind is the ability to imagine yourself in someone else’s skin. Not just in their shoes (“I certainly would have acted differently in that situation”), but with their mind (“ I wouldn’t have acted that way, but I get why they did”). This is something people learn. The experimental setup here is to have a child in a room with toys, with a doll sitting near the opposite end of the room, and asking the child “what does the doll see?”. Younger children describe the room from their perspective, older begin to intuit that doll’s perspective is different.

      So this is the goal of reading code — understanding what the original author was thinking, and why.

      End of the mumbo-jumbo, some practical advice. First, read Every line of code is always documented, it is very good.

      Second, make sure it is effortless for you to find out how a given snippet of code evolved. This is harder than it seems! Just git blame isn’t an answer — mind the gap between the problem that’s easy to solve, and the problem in need of solving.

      git blame answers spatial question of “how each line appeared in this file”, because there’s a relatively straightforward UI for this — annotate each line with a commit hash. But this is not the question you are asking most of the time! You don’t care about the file! There’s a small snippet of code in the middle, and you want a temporal history of that.

      As much as I don’t like working in the browser GitHub’s web interface for blaming is probably better than what you get locally by default. It starts with the y shortcut, which resolves a symbolic reference like

      https://github.com/tigerbeetle/tigerbeetle/blob/main/src/vsr/replica.zig

      into the one which has a commit hash in the URL:

      https://github.com/tigerbeetle/tigerbeetle/blob/c54f613a2eb2a127a0ba212704e3fa988c42e5cb/src/vsr/replica.zig

      This commit hash is critical, because it anchors the entire repository — if you open a different file from the web UI, it will be shown as of that commit. This enables you to not myopically focus on just the diff in question, but to absorb the entire context at that point in time.

      So my usual web workflow is:

      • ctrl`+`f to find the line I am interested in
      • b to toggle blame
      • Click “blame prior to change” a couple of times, repeating ctrl`+`f to go back to the snippet I am curious about.
      • cmd-click on the commits that are potentially relevant, pinning their commit hashes in the URL in new tabs.
      • Then, from the commit page, “Browse files” button to then go and t to other files. Or, cmd`+`l to focus browser’s address bar, and s/commit/tree/ (or back!) as needed, to switch between diff and snapshot views.

      Again, my goal here is not to annotate a diff on a file but rather to get a “virtual checkout” as of the interesting commit.

      This web approach is what I was using throughout most of my career, but I’ve finally found a way to replicate it locally. The idea is to make blaming “in- place”. Instead of git blame annotating lines of code, I directly switch to a historical commit. I have the following devil hydra of shortcuts:

      , b l blames line. It notes the $line the cursor is at, runs git blame -L $line,$line to find $commit that introduced the line, and then runs git switch --detach $commit to check it out. I have a dedicated worktree for code archeology, so I don’t worry about trashing my work. There’s also a half- hearted attempt to maintain “logical” cursor position, but it doesn’t work very well. Is there some git command that tells me directly “what’s the equivalent of $file:$line:column in $sha-A for $sha-B?”

      , b p blames parent. Which is just switching to the parent commit of the current HEAD, what “blame before this change” does on GitHub (it works slightly differently because it assumes that , b l was the previous command)

      , b u undoes the last blaming operation, switching to the previous point. I really love that, on the web, I can cmd-click to create an alternative branch of exploration. In theory, this is replicatable locally, but I prefer to destructively mutate a single working tree on disk. A big reason for preferring in-place blame is that LSP, ./zig/zig build test, rg and the like just work. That’s more important for me than the garden of forking paths, and undo is an acceptable work-around.

      Finally, , b w copies GitHub link to the current commit and line, which I can paste into the browser. An enormous problem with modern version control landscape is that absolutely critical information in the form of code review comments is not a part of the git repository, and is locked in someone else’s proprietary database. I failed to solve this problem in one weekend, and had to begrudgingly adapt. Opening the commit in a browser links you to the PR and its discussion as well.

      Implementing this blame workflow required a bit of custom code. Feel free to use it, but beware that it’s somewhat crufty, especially around maintaining current cursor position. Making a production- ready version of this sounds like a fun project ;-)

    32. 🔗 Rust Blog Project goals update — April 2026 (end of 2025H2) rss

      The 2025H2 Project Goal period has now concluded. Over these months, the Rust Project pursued 41 Project Goals, 13 of which were designated as Flagship Goals. This post contains curated updates on our progress since the last post and the final status for each of the goals (many of which continue as part of the 2026 period). Full details for any particular goal are available in its tracking issue.

      Thanks to everyone who contributed! <3

      Table of contents Flagship: Beyond the & Continue Experimentation with Pin Ergonomics Design a language feature to solve Field Projections Reborrow traits Flagship: Flexible, fast(er) compilation build-std Production-ready cranelift backend Promoting Parallel Front End Relink don't Rebuild Flagship: Higher-level Rust Ergonomic ref-counting: RFC decision and preview Stabilize cargo-script Flagship: Unblocking dormant traits Evolving trait hierarchies In-place initialization Next-generation trait solver Stabilizable Polonius support on nightly Other goal updates Add a team charter for rustdoc team Borrow checking in a-mir-formality C++/Rust Interop Problem Space Mapping Comprehensive niche checks for Rust Const Generics Continue resolving cargo-semver-checks blockers for merging into cargo Develop the capabilities to keep the FLS up to date Emit Retags in Codegen Expand the Rust Reference to specify more aspects of the Rust language Finish the libtest json output experiment Finish the std::offload module Getting Rust for Linux into stable Rust: compiler features Getting Rust for Linux into stable Rust: language features Implement Open API Namespace Support MIR move elimination Prototype a new set of Cargo "plumbing" commands Prototype Cargo build analysis reflection and comptime Rework Cargo Build Dir Layout Run more tests for GCC backend in the Rust's CI Rust Stabilization of MemorySanitizer and ThreadSanitizer Support Rust Vision Document rustc-perf improvements Stabilize public/private dependencies Stabilize rustdoc doc_cfg feature SVE and SME on AArch64 Type System Documentation Unsafe Fields Flagship: Beyond the & People involved: Frank King Champions: compiler (Oliver Scherer), lang (TC) Status: Continued 3 detailed updates available. Frank King — comment from 2026-02-26 (Just come back from the Spring Festival) * (locally, no PR yet): design and implement the borrow checking algorithms of &pin * Reviewed Add Drop::pin_drop for pinned drops, to update the submodule book * Reviewed Implement coercions between &pin (mut|const) T and &(mut) T when T: Unpin, to do some refactors according to the reviewed messages. Frank King — comment from 2026-03-16 * Merged . * Opened draft PR [Implement borrowck for&pin mut|const $place`](https://github.com/rust-lang/rust/pull/153693). The implementation needs to be refined and self-reviewed before the community reviews. Frank King — comment from 2026-04-16 Self-reviewed Implement borrowck for &pin mut|const $place. Found that the current approach of handling pinned borrows may be incorrect, as it failed to distinguish a pinned borrow from a coercion of a normal-to-pinned reference. The latter doesn't prevent a T: Unpin type from being moved, but the former does, which breaks the pin coercion test. People involved: Benno Lossin Champions: lang (Tyler Mandry) Status: Continued 5 detailed updates available. Benno Lossin — comment from 2026-01-01 * At the beginning of December, we set out to [answer five important questions](https://github.com/rust-lang/rust-project- goals/issues/390#issuecomment-3621913656) regarding the virtual places approach. We discussed four questions and arrived at answers for three. * The first question we looked at was question 3 Canonical Projections. * Next we looked at question 4 Non-Indirected Containers. * As the final question we answered, we looked at question 1 Field- by-Field Projections vs One-Shot Projections. * At the moment, we are investigating question 2 and I wrote a blog post with a potential solution that still needs feedback. * We started a Wiki Project to consolidate our knowledge in one place. * We implemented an algorithm to determine the type of a place expression. * Our plan is to continue this project goal in the next goal period. Benno Lossin — comment from 2026-01-25 Earlier this month, Nadrieril Ding Xiang Fei and I held a meeting on autoref and method resolution in a world with field projections. This meeting resulted in a new page for the wiki on autoref. Benno Lossin — comment from 2026-02-28 The first pull request of the lang experiment has just been merged: rust- lang/rust#152730 This PR enables the use of the field_of! macro to obtain a unique type for each field of a struct, enum variant, tuple, or union. We call these types field representing types (FRTs). When the base type is a struct that is not repr(packed), only contains Sized fields, this type automatically implements the Field trait that exposes some information about the field to the type system. The offset in bytes from the start of the struct, the type of the field and the type of the base type. The feature is still incomplete and highly experimental. We also want to tackle the limitations in future PRs. For the moment this is enough to give us the ability to experiment with library versions of field projections and write functions that are generic over the fields of structs. For example one can write code like this: > #![feature(field_projections)] use std::field::{Field, field_of}; use std::ptr; fn project_ref<'a, T, F: Field<Base = T>>(r: &'a T) -> &'a F::Type { // SAFETY: the `Field` trait guarantees that this is sound. unsafe { &*ptr::from_ref(r).byte_add(F::OFFSET).cast() } } struct Struct { field: i32, other: u32, } fn main() { let s = Struct { field: 42, other: 24 }; let r = &s; let field = project_ref::<_, field_of!(Struct, field)>(r); let other = project_ref::<_, field_of!(Struct, other)>(r); println!("field: {field}"); // prints 42 println!("other: {other}"); // prints 24 } A very important feature of the types returned by field_of! is that you can implement traits for them if you own the base type. This allows anointing fields with information by extending the Field trait. For example, this allows encoding the property of being a structurally pinned field: > use std::pin::Pin; unsafe trait PinnableField: Field { type StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a; fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a; } fn project_pinned<'a, T, F>(r: Pin<&'a mut T>) -> <F as PinnableField>::StructuralRefMut<'a> where F: PinnableField, { F::project_mut(r) } We can then implement this extra trait for all of the fields of our struct (and automate that with a proc-macro): > unsafe impl PinnableField for field_of!(Struct, field) { type StructuralRefMut<'a> = &'a mut i32; fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a, { let base = unsafe { Pin::into_inner_unchecked(base) }; &mut base.field } } unsafe impl PinnableField for field_of!(Struct, other) { type StructuralRefMut<'a> = Pin<&'a mut u32>; // u32 is `Unpin`, so this isn't doing anything special, but it highlights the pattern. fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a> where Self::Type: 'a, Self::Base: 'a, { let base = unsafe { Pin::into_inner_unchecked(base) }; unsafe { Pin::new_unchecked(&mut base.other) } } } Now you can safely obtain a pinned mutable reference to other and a normal mutable reference to field by calling the project_pinned function and supplying the correct FRT. (playground link) Benno Lossin — comment from 2026-03-20 Plan for 2026 We have an updated plan for this goal in 2026 consisting of three major steps: * `a-mir-formality`, * Implementation, * Experimentation. Some of their subtasks depend on other subtasks for other steps. You can find the details in the updated tracking issue. Here is a short rundown of each: a-mir-formality: we want to create a formal model of the borrow checker changes we're proposing to ensure correctness. We also want to create a document explaining our model in a more human-friendly language. To really get started with this, we're blocked on the new expression based syntax in development by Niko. Implementation: at the same time, we can start implementing more parts in the compiler. We will continue to improve FRTs, while keeping in mind that we might remove them if they end up being unnecessary. They still pose for a useful feature, but they might be orthogonal to field projections. We plan to make small and incremental changes, starting with library additions. We also want to begin exploring potential desugarings, for which we will add some manual and low level macros. When we have that figured out, we can fast-track syntax changes. When we have a sufficiently mature formal model of the borrow checker integration, we will port it to the compiler. After further evaluation, we can think about removing the incomplete_feature flag. Experimentation: after each compiler or standard library change, we look to several projects to stress-test our ideas in real code. I will take care of experimentation in the Linux kernel, while Tyler Mandry will be taking a look at testing field projections with crubit. Josh Triplett also has expressed eagerness of introducing them in the standard library; I will coordinate with him and the rest of t-libs-api to experiment there. Benno Lossin — comment from 2026-04-02 Yesterday, we held a t-lang design meeting on our current approach. Nadrieril and I authored a design document with the feedback of Tyler Mandry, Ding Xiang Fei, Alice Ryhl, and Gary Guo. In this document, we provided the motivation for this feature, what the look and feel of a solution fitting into the existing features of Rust is, and a comprehensive + compact introduction to our current approach based on virtual places. The general reception was extremely positive. To give some concrete quotes from the meeting: * Josh: I adore this! I love how orthogonal it is, and how impactful and universal it is. I anticipate this becoming a beloved, pervasive feature of Rust. Places and projection seem important enough to me that they're worth giving one of our precious remaining ASCII sigils to, and @ is nicely evocative of a place (something is at a place). So to the extent the final syntax benefits from a sigil, :+1: for giving this @. (See some feedback below on the details, though.) * TC: Love it. High concept. As I said in the last meeting: I particularly like language features that reduce the need for library surface area, and this is one of those. There are, of course, many details to resolve and understand further, e.g., with respect to migration issues, interaction with const, async, and other effect-like things, etc. I'm looking forward to seeing the formalization work. * tmandry: What I love about this direction is how effectively it builds on what Rust already has. I love to see designs that reinforce our existing concepts while pushing them in directions that make them more expressive. * Jack: Whoo boy. This is great. There's so much here that I'm not exactly sure where to begin and what to comment on. I think this is the type of thing that we will only really be able to figure out the nitty gritty details and ergonomics only after some amount of experimentation. There are a few takeaways from this meeting: * Mark that t-libs should be more involved in reviewing the experimental traits that we intend to add. Ensuring that we don't accidentally stabilize or expose some behavior, have sufficient documentation on our experimental traits, and that t-libs is in the loop of this feature in general. * Mark offered to review PRs and I will be tagging him in those. * Jack raised the concern that increasing the cognitive load for the 95% use-case should be avoided. Making the right choice between @ and & might be challenging for users. * We discussed this point more in the meeting and concluded with that we need to do some experimentation, possibly utilizing the user research team. We will of course keep this in mind and revisit it later when we have a partially working implementation. * TC requested that we publish our fine-grained design axioms, essentially the list of things we go through when considering a modification of our proposal. * I will write an update on this issue explaining exactly those. Aside from the concerns and directly actionable items, the meeting also covered design questions/comments that we want to take a look at in the coming weeks/months: * [Can we support reads/writes of different types?](https://hackmd.io/H5d2-83ER2ymNPZVIWCYWg?view#Support-ReadWrite-of- non-PlaceTarget) * Can we support re-assembly of wrapper types, so going from Cell<[T]> to [Cell<T>]? * The PlaceDiscriminant trait needs to be carefully designed * How do we handle naming conflicts & ensure SemVer evolution of library types implementing our traits? * Can we support projecting through Option, so e.g. &Option<Struct> to Option<&Field>? * Can we support a pointer that carries alignment information & which is updated on projections? * What compatibility with effects do we need or want to support? * What doors on future ergonomic improvements of pointers are we closing by having field projections? Thanks to everyone who participated in the meeting! People involved: Aapo Alasuutari Champions: compiler (Oliver Scherer), lang (Tyler Mandry) Status: Continued 1 detailed update available. Aapo Alasuutari — comment from 2026-02-28 PR open to get the first working version of the Reborrow and CoerceShared traits merged. Blockers Currently "blocked" on PR review, and of course my (and Ding's) work to fix all review issues. The review has brought up an opportunity to replace Rvalue::Ref / ExprKind::Ref with a more generalised variant that could encompass both references and user-defined references. This would be powerful, but it would be a very big and scary change. If this turns out to be a blocking issue for reviewers, then this will block the goal for the foreseeable future as the PR then starts on a massive refactoring. Help wanted The PR currently does not include derive traits, but we'd really want them. Instead of these: > impl<'a> Reborrow for CustomMarker<'a> {} impl<'a> CoerceShared<CustomMarkerRef<'a>> for CustomMarker {} impl<'a, T> Reborrow for CustomMut<'a, T> {} impl<'a, T> CoerceShared<CustomRef<'a, T>> for CustomMut<'a, T> {} we'd prefer to have something like this: > #[derive(Reborrow, CoerceShared(CustomMarkerRef))] struct CustomMarker<'a> { ... } #[derive(Reborrow, CoerceShared(CustomRef))] struct CustomMut<'a, T> { ... } If anyone feels like picking up this thread, that'd be awesome: the derive macros do not need to really perform any validity checking, as the trait itself will do that. If the PR merges soon, then public testing and exploration of the traits will be the next big thing. Likely concurrently with that the massive refactoring to generalise Rvalue::Ref / ExprKind::Ref. Flagship: Flexible, fast(er) compilation People involved: David Wood , Adam Gemmell Champions: cargo (Eric Huss), compiler (David Wood), libs (Amanieu d'Antras) Status: Continued 4 detailed updates available. David Wood — comment from 2026-01-15 rust-lang/rfcs#3873 has been merged and an FCP has been started on rust- lang/rfcs#3874 and rust- lang/rfcs#3875 - those both have some feedback for me to respond to that I'll get to as soon as I can. David Wood — comment from 2026-02-17 No major updates this cycle - we're still working through feedback on rust- lang/rfcs#3874 and rust- lang/rfcs#3875 and prototyping the implementation to be prepared. David Wood — comment from 2026-03-17 Update this cycle is the same as last time - rust- lang/rfcs#3874 and rust- lang/rfcs#3875 are progressing, with feedback being addressed and checkboxes checked, and we're still working out what the implementation would look like. David Wood — comment from 2026-04-14 rust-lang/rfcs#3874 has finished FCP and is due to be merged any day now. I'm working on resolving the remaining open comments on rust- lang/rfcs#3875 and then intend to nudge the reviewers to have a look and check their boxes or leave concerns. Adam Gemmell has opened rust- lang/cargo#16675 with an early sketch of some of the core changes that build-std would require and is working with the Cargo team to address feedback and work out how to proceed with the implementation. People involved: Folkert de Vries , bjorn3, Trifecta Tech Foundation Champions: compiler (bjorn3) Status: Not completed (lack of funding) People involved: Sparrow Li Status: Continued People involved: Jane Lusby , @dropbear32, @osiewicz Champions: cargo (Weihang Lo), compiler (Oliver Scherer) Status: Not completed (note) Flagship: Higher-level Rust People involved: Niko Matsakis , Santiago Pastorino Champions: compiler (Santiago Pastorino), lang (Niko Matsakis) Status: Continued People involved: Ed Page Champions: cargo (Ed Page), lang (Josh Triplett), lang-docs (Josh Triplett) Status: Continued 3 detailed updates available. Ed Page — comment from 2026-01-14 #146377 has been decided and merged. Blockers * T-lang discussing CR / text direction feedback: comment * T-rustdoc deciding on and implementing how they want frontmatter handled in doctests Ed Page — comment from 2026-02-13 * FCP has ended on , just awaiting merge * Cargo script has entered FCP Blockers * Potential issues around edition, see [Cargo script edition policy (lang/edition aspects)](https://github.com/rust-lang/rust/issues/152254). Ed Page — comment from 2026-03-16 Cargo's FCP has ended. Blockers * Flagship: Unblocking dormant traits People involved: Taylor Cramer and others Champions: lang (Taylor Cramer), types (Oliver Scherer) Status: Superseded by the Implement Supertrait auto impl and Arbitrary Self Types 2026 goals People involved: Alice Ryhl , Benno Lossin, Michael Goulet, Taylor Cramer, Josh Triplett, Gary Guo, Yoshua Wuyts Champions: lang (Taylor Cramer) Status: Continued 1 detailed update available. Alice Ryhl — comment from 2026-01-31 A proposal to continue this goal in the next goal period was merged. People involved: lcnr , Boxy, Michael Goulet Champions: types (lcnr) Status: Continued 1 detailed update available. lcnr — comment from 2026-01-19 There hasn't been too much progress over the last few weeks and I've been mostly taking a Christmas break. Nicholas Nethercote has been looking into the performance of the new trait solver, cleaning up canonicalization and slightly improving its performance: PR 1 and PR 2. Shoyu Vanilla looked into ICE from mir validation on unsizing in opendal and uncovered the underlying bug there. While this issue also affects the old solver and the proper fix for it requires where-bounds on binders, we can work around this bug in the trait solver for now and intend to do so. We've started another crater run with all our recent changes and adwin has started to triage it, uncovering one new issue up until now. Intend to continue going through that over the next few weeks. There's also a lot in-progress work going on. I am collaborating with Niko Matsakis to specify and later RFC the cycle semantics of Rust. León Orell Valerian Liehr is working on a replacement for the rustdoc's auto trait impl synthesis. tiif is working on a fix a MIR borrowck unsoundness. Shoyu Vanilla and I are improving the way we propagate inference constraints from the expected return type to function arguments, fixing this issue. People involved: Rémy Rakic , Amanda Stjerna, Niko Matsakis Champions: types (Jack Huey) Status: Continued 2 detailed updates available. Rémy Rakic — comment from 2026-01-30 This month's update: * is making progress on [normalizing opaques while computing implied bounds](https://github.com/rust-lang/trait- system-refactor-initiative/issues/159) * we discussed how to investigate and fix the remaining correctness issues in Tage's work, to be able to evaluate it more accurately: in particular around variance and bidirectional edges, and without the reliance on NLL (having computed region values / errors) * we've tried to see if it'd be possible to remove the cfg region elements * Amanda is still working on her two papers, one about the current borrow checker and one about the work on Polonius. Her major PR for the restructuring of placeholder handling during region inference is stalled due to a conflict with further trait solver developments and may have to be abandoned. Work with the larger types team is ongoing and smaller patches/refactorings/improvements are being landed in the meantime. * #149639 has now landed, and #150551 is still in review * I've also fixed more small inefficiencies (computing boring/relevant locals on-demand in diagnostics, removed conversions between locations and points, etc) building on top of the previous PRs (so they need to be reviewed first) * I've looked at crates.io again with the alpha, to find functions that are slower than with NLLs. AFAICT the worst case there is 60% for a 5KLOC function with 42K loans, 255K statements, and 125K outlives constraints. I'll see what we can do with this. Small composable functions is still good advice. * there seem to be optimization opportunities to 1. limit propagation to the smaller number of blocks that could be affected by bidirectional edges, 2. for unifying invariant lifetimes of live locals that are assigned at most once (à la use-def chains), 3. for invalidations that are just the activation of a reservation * we discussed possible plans to gather actual statistics, using the infrastructure that was created for the Metrics project * we're also preparing the new project goal for this year, where we'll want to stabilize the alpha 🤞 Rémy Rakic — comment from 2026-02-28 We had a bit less time this month, the update will be shorter, but still meaningful I hope: * [#150551](https://github.com/rust-lang/rust/pull/150551) has landed, and it feels stabilizable. To me, this part of the goal is achieved. * still, "stabilizable" is not stable , and there is more work to do. We plan to stabilize this year, and the project goal proposal for 2026 tracks how. * tiif is still deep in #152051, and a-mir- formality work with Niko and I. * Amanda has opened a few cleanup PRs (#152438, and #152579), and #151863 has landed already. She also has started looking into Tage's old PR to see if we can fix it, benchmark it more accurately, and see the cool parts there that we could be using. * Jack is possibly going to have some time to work with us this year! His help will be very welcome, especially as I will have less time available myself. * we'll be tracking the opaque type region liveness soundness issue in #153215, and I've added a couple tests, in case tiif's PR or anything that impacts them lands. * some of the tiny cleanups I mentioned last time have also landed in #152587. Other goal updates People involved: Guillaume Gomez Champions: rustdoc (Guillaume Gomez) Status: Completed People involved: Niko Matsakis , tiif Champions: types (Niko Matsakis) Status: Continued People involved: Joel Marcey Champions: compiler (Oliver Scherer), lang (Tyler Mandry), libs (David Tolnay) Status: Continued 5 detailed updates available. Joel Marcey — comment from 2026-01-20 The Rust Foundation is opening up a short-term, approximately 3-month, contracting role to assist in our Rust/C++ Interop initiative. The primary work and deliverables for the role will be to make substantial progress on the Problem Space Mapping Rust Project Goal by collecting discrete problem statements and offering up recommendations on the work that should follow based upon the problems that you found. If you are interested in how programming languages interoperate, are curious in understanding the problems therein, and are have a passion to think about how those problems may be resolved for the betterment of interop, then this work may be for you. An ideal candidate will have experience with Rust programming. Having experience in C++ is strongly preferred as well. If you have direct experience with actual engineering that required interoperating between Rust and C++ codebases, that's even better. If you are interested, please email me (email address found in my GitHub profile) or contact me directly on Zulip by Tuesday, January 27 and we can take it from there to see if there may be a potential fit for further discussion. Thank you. Joel Marcey — comment from 2026-01-31 The effort to fill the contracting role to support this project goal is in the process winding down. The interview and discussion process is nearly complete. We expect to make a final decision for the role in early February. teor — comment from 2026-02-27 Hi, I'm the new contractor on the interop problem space mapping project goal. In the last week and a half, I've: * added * started mapping out interop use cases * added relationships between problems/use cases and existing project goals & unstable compiler features Next step is prioritising a few of the use cases, then working on related problem statements in more detail. Blockers Nothing at the moment, still working through the high level mapping of the problem space. Help wanted Suggestions for more interop use cases would be very welcome, just open a discussion in t-lang/interop and I'll turn it into a ticket. Or go ahead and open a use case ticket directly. I'll post an update here every few weeks, you can follow more detailed weekly updates on Zulip. teor — comment from 2026-03-30 In the last month, I've: * met with the lang team, Crubit team, and `cxx` author, and Joel and Mara have met with the C++ standards working group * expanded some draft high-level problem statement summaries, and added code examples * added 6 new interop use cases * added more relationships between problems/use cases and existing project goals & unstable compiler features * prepared for the Rust All Hands, and started mentoring for Outreachy Specifically, the last month we've identified and prioritised two high- priority use cases for more detailed work: * , with a Rust lang experiment - implementation discussion * adding Rust to an existing C++ build system, this currently works for basic cases, but the tooling could be improved on the Rust side And I analysed the problems / use cases we've collected so far, with priorities, responsible language, and a split into semantics or tooling changes. Next step is continuing to work on overloading and build systems in more detail. If you have specific Rust/C/C++ build system blockers, please open a chat or ticket. Blockers Nothing at the moment, everyone has been extremely helpful, and I'm getting good feedback on use cases, problems, priorities, and Rust language experiments. teor — comment from 2026-05-01 In the last month, I've: * prepared for RustWeek and the All Hands, where I will be [giving a Rust Project track talk](https://2026.rustweek.org/schedule/wednesday/#teor) and running an All Hands interop session (schedule TBC) * added new interop use cases and problem statements, and continued categorising them using GitHub tags * continued to expand the draft high-level problem statement summaries * added interop code examples, including many examples from Outreachy applicants * continued mentoring Outreachy applicants * continued working on the Overloading Rust language experiment Specifically, the last month we've made detailed progress on two high- priority use cases: * [calling an overloaded C++ function from Rust](https://github.com/rustfoundation/interop-initiative/issues/14), with a Rust lang experiment - implementation discussion * we've merged a refactor to prepare for this experiment, which gave some nice perf wins * the initial overloading experiment PR has been through two rounds of review, and is waiting for my revisions and rebasing * adding Rust to an existing C++ build system * Outreachy applicants wrote interop example code PRs * these interop user experiences are waiting for analysis, so they can be summarised in the build system and overloading problem statements * this will likely happen after RustWeek and the All Hands Next step is continuing to work on the overloading experiment, along with RustWeek/All Hands preparation, and collecting feedback during the conference. Blockers Nothing at the moment. There is a steady stream of new use cases, problems, code examples and Rust language experiment feedback. People involved: Bastian Kersting , Jakob Koschel Champions: compiler (Ben Kimock), opsem (Ben Kimock) Status: Not completed People involved: Boxy , Noah Lev Champions: lang (Niko Matsakis) Status: Continued 6 detailed updates available. Niko Matsakis — comment from 2026-01-27 Boxy and I have established a regular time to check-in on formalizing this within a-mir-formality. Today we mostly worked on the "model" of const values, starting with this > #[term] pub enum ConstData { // Sort of equivalent to `ValTreeKind::Branch` #[cast] RigidValue(RigidConstData), // Sort of equivalent to `ValTreeKind::Leaf` #[cast] Scalar(ScalarValue), #[variable(ParameterKind::Const)] Variable(Variable), } #[term] pub enum ScalarValue { #[grammar(u8($v0))] U8(u8), #[grammar(u16($v0))] U16(u16), #[grammar(u32($v0))] U32(u32), #[grammar(u64($v0))] U64(u64), #[grammar(i8($v0))] I8(i8), #[grammar(i16($v0))] I16(i16), #[grammar(i32($v0))] I32(i32), #[grammar(i64($v0))] I64(i64), #[grammar($v0)] Bool(bool), #[grammar(usize($v0))] Usize(usize), #[grammar(isize($v0))] Isize(isize), } #[term($name $<parameters> { $,values })] pub struct RigidConstData { pub name: RigidName, pub parameters: Parameters, pub values: Vec<Const>, } i.e., a const value can be a scalar value (as today) or a struct literal like Foo { ... } (which would also cover tuples and things). We got the various tests passing. Huzzah! Boxy — comment from 2026-01-30 In addition to what niko posted previously there's been a lot of other stuff happening. A lot of people have opened PRs to improve mGCA this month: León Orell Valerian Liehr Noah Lev @enthropy7 Kivooeo mu001999 @Human9000-bit Redddy @Keith-Cancel @AprilNEA A rough list of things that have been improved for mGCA: * Lots of new expressions now supported by mGCA: const constructors, tuple constructor calls, array expressions, tuple expression, literals * associated_const_equality has been merged into min_generic_const_args. the former was effectively dependent on the latter already so this just makes it nicer to use the former :) * traits can now be dyn compatible if all associated constants are type consts and are specified in the trait object (e.g. dyn Trait<ASSOC = 10>) * type consts are enforced to be non-generic * a bunch of ICEs have been fixed * camelid has been working on "non-min" version of mGCA which will allow arbitrary expressions to be used in the type system (a blog post with more detail will be published once this actually lands) In non-mGCA updates, as niko says, we've been meeting regularly to make progress on modelling const generics in a-mir-formality. I've also been spending time thinking about the interactions between adt_const_params and ADTs with privacy/safety invariants and I think I know how to structure the RFC in this area so can make progress on that again There's some more detail about the various bits of work people have done and who did what here: #project-const-generics > perfectly adequately sized wins @ 💬 Niko Matsakis — comment from 2026-02-13 Boxy and I have met (and continue to meet) and work on modeling const generics in a-mir-formality. We're still working on laying the groundwork. There is a proposed project goal for next year. Boxy — comment from 2026-02-28 There's been a lot of miscellaneous fixes for mGCA this month. I've also started drafting some blog posts to explain what's going on with mGCA/oGCA as well as soliciting use cases/experience reports for them and adt_const_params. I also talked with some folks at Rust Nation this month about const generics and what features would be useful for them and why. Boxy — comment from 2026-04-02 Late on the update :') niko and i continue to meet to discuss const generics. we've made some progress on figuring out problems around privacy/safety in const generics. we've also been discussing the big picture stuff for const generics and where we're "heading". Boxy — comment from 2026-05-01 started running weekly meetings about const generics to make it easier to keep up to date with all the people who are working on const generics stuff. i think min_adt_const_params is now at the point of what the RFC is going to specify. GCA is making good progress thanks to ashley's work. i also met with lcnr where we talked about whether there was some version of mGCA that is stabilizeable in the near future or not (maybe!) People involved: Predrag Gruevski Champions: cargo (Ed Page), rustdoc (Alona Enraght-Moony) Status: Continued 1 detailed update available. Predrag Gruevski — comment from 2026-01-17 I posted a "year in review" for cargo-semver- checks. It has a section on how I think we should move forward in 2026 and beyond. People involved: Pete LeVasseur , t-spec, and contributors from Ferrous Systems Champions: bootstrap (Jakub Beránek), lang (Niko Matsakis), spec (Pete LeVasseur) Status: Superseded by the Stabilize FLS Release Cadence 2026 goal 2 detailed updates available. Pete LeVasseur — comment from 2026-03-04 We have a Project Goal in 2026 that we'll take on: Stabilize FLS Release Cadence. Progress towards 1.93.1 looks good, most issues are closed. Help wanted We'd love more folks from the safety-critical community to contribute to picking up issues or opening an issue if you notice something is missing. Pete LeVasseur — comment from 2026-04-02 Trying to prepare FLS releases earlier: * since we completed the 1.94.0 release of the FLS a bit early this time, we checked into the stretch part of our goal this year to look at 1.95.0 early * we learned a bit more of the release notes process thanks to tips from Eric Huss and TC * Tshepang Mbambo and I attended the t-release meeting last week where we chatted about working a little "upstream" with them on generating the release notes a bit earlier * tomorrow in our t-fls meeting we'll discuss our interest with engaging over there; at a minimum I'll get engaged with t-release Glossary and main-body text harmonization: * the first PR landed from removing IDs from the glossary * further steps planned, we have a tracking issue for it Developer guide: * akin to how the Reference now has a developer's guide now for contributing we'll do the same in the FLS * Hristian Kirtchev has been working on this People involved: Ian McCormack Champions: compiler (Ralf Jung), opsem (Ralf Jung) Status: Superseded by the BorrowSanitizer 2026 goal 4 detailed updates available. Ian McCormack — comment from 2026-01-09 Here's our January status update! * Yesterday, we posted [an MCP](https://github.com/rust-lang/compiler- team/issues/958) for our retag intrinsics. While that's in progress, we'll start adapting our current prototype to remove our dependence on MIR-level retags. Once that's finished, we'll be ready to submit a PR. * We published our first monthly blog post about BorrowSanitizer. * Our overall goal for 2026 is to transition from a research prototype to a functional tool. Three key features have yet to be implemented: garbage collection, error reporting, and support for atomic memory accesses. Once these are complete, we'll be able to start testing real-world libraries and auditing our results against Miri. Ian McCormack — comment from 2026-02-24 We just posted our February status update for BorrowSanitizer. TL;DR: * We provide detailed error messages for aliasing violations, which look almost like Miri's do! * We have two forms of retag intrinsic: __rust_retag_mem and __rust_retag_reg. We no longer require a compiler plugin to determine the permission associated with a retag, which will make it possible to use BorrowSanitizer by providing a single -Zsanitizer=borrow flag to rustc. You can check out our MCP for more detailed design updates. * We are starting to have a better understanding of how BorrowSanitizer performs in practice, but we do not have enough data yet to be certain. From one test case, it seems like we are somewhat faster but still in the same category of performance as Miri when we compare against other sanitizers. Expect more detailed results to come as we scale up our benchmarking pipeline. * We have a tentative plan for upstreaming BorrowSanitizer in 2026, starting with its LLVM components. We intend to start the RFC process on the LLVM side this spring, once our API is stable. Ian McCormack — comment from 2026-03-30 We just posted our March status update for BorrowSanitizer. TL;DR: * We added hundreds more relevant tests from Miri's test suite. At the moment, 80% pass. * We improved our cargo plugin (cargo-bsan) to better support multilanguage libraries. This will let us start to recreate the bugs from our earlier evaluation. Our goal for April is to continue expanding our test suite, finish an initial version of the LLVM components of BorrowSanitizer, and hopefully start the RFC process on the LLVM side. Ian McCormack — comment from 2026-04-29 We have some exciting news: our talk on BorrowSanitizer was accepted at RustConf this year! We’re grateful for the opportunity and looking forward to sharing our results with the broader community this September. We just posted our April status update. It’s a bit of a technical one. Here’s the TL;DR: * BorrowSanitizer now uses a shadow stack to track metadata at runtime - this is a significantly different strategy than other LLVM sanitizers, and it will help us support garbage collection. * We are now ready to start sending in PRs for our retag intrinsics. It will take a little time to split our changes up into meaningful, reviewable chunks—you can expect to see these throughout the next week. The RFC for our LLVM components is taking a little longer than expected, but it was worth taking the extra time to test out compiler changes and make sure that we had the core parts of the instrumentation pass settled. We’ll be drafting the RFC throughout the next few weeks. People involved: Josh Triplett , Amanieu d'Antras, Guillaume Gomez, Jack Huey, lcnr, Mara Bos, Vadim Petrochenkov, Jane Lusby Champions: lang-docs (Josh Triplett), spec (Josh Triplett) Status: Superseded by the Experimental language specification 2026 goal 1 detailed update available. Josh Triplett — comment from 2026-04-14 This work is now continuing into a new goal by Jack Huey. People involved: Ed Page Champions: cargo (Ed Page) Status: Continued People involved: Manuel Drehwald , LLVM offload/GPU contributors Champions: compiler (Manuel Drehwald), lang (TC) Status: Superseded by the High-Level ML optimizations 2026 goal 2 detailed updates available. Manuel Drehwald — comment from 2026-01-16 std::autodiff is moving closer to nightly, and std::offload is gaining various performance, feature, and hardware support improvements. autodiff Jakub Beránek, sgasho, and I continued working on enabling autodiff in nightly. We have a PR up that builds autodiff in CI, and verified that the artifacts can be installed and work on Linux. For apple however, we noticed that any autodiff usage hangs. After some investigation, it turns out that we ended up embedding two LLVM copies, one in rustc, and one in Enzyme. It should be comparably easy to get rid of the second one. Once we verified that this fixes the build, we'll merge the PR to enable autodiff on both targets in nightly. offload A lot of interesting updates on the performance, feature, and hardware support side. 1. , @kevinsala, @jdoerfert, and I started implementing the first benchmarks, since that's generally the best way to find missing features or performance issues. We were positively surprised by how good the out-of-the-box performance was. We will implement a few more benchmarks and post the results once we have verified them. We also implemented multiple PRs which implement bugfixes, cleanups, and needed features like support for scalars. We also started working on LLVM optimizations which make sure that we can achieve even better performance. 2. I noticed that our offload intrinsic allowed running Rust code on the GPU, but it wasn't of much help when calling gpu vendor libraries like cuBLAS. I implemented a new helper intrinsic which allows calling those functions conveniently, without having to manually move data to or from the device. It will benefit from the same LLVM optimizations as our full offload intrinsic. It also a bit simpler to set up on the compiler and linker side, so it already works with std and mangled kernel names, something that we still have to improve for our main offload intrinsic. 3. A lot of work happened on the LLVM offload side for SPIRV and Intel GPU support. At the moment, our Rust frontend is tested on NVIDIA and AMD server and consumer GPUs, as well as AMD HPC and Lapotop APUs. Karol Zwolak reached out since he wants to help with with also running Rust on Intel GPUs. Offload relies on LLVM which started gaining Intel support, so hopefully we won't need much work beyond a new intel-gpu target and a new stdarch module. There is also work on a new spirv target for rustc, which we could also support if it goes through LLVM. Due to some open questions around typed pointers it does not seem clear yet whether it will, so we will have to wait. 4. Nikita started working on updating our submodule to LLVM 22. This hopefully does not only brings some compile and runtime performance improvements, but also greatly simplifies how we can build and use offload. Once it landed I'll refactor our bootstrapping logic, and as part of that start building offload in CI. Manuel Drehwald — comment from 2026-04-01 std::autodiff is now partly in CI, and std::offload got tested on a lot more benchmarks. autodiff Work continued on enabling autodiff in nightly. Since the last update, we have enabled autodiff in some Mingw and Linux runners. Users can now download libEnzyme artifacts, place them locally in the right spot for their toolchain, and then use autodiff on their nightly compiler. Once macOS is added, we will enable a new rustup component that will handle the download for users. Before enabling autodiff on macOS, however, we want to change how we distribute LLVM on this target (from static to dynamic linking). There are a lot of workflows and users of this target, not all of which can be modelled in the Rust CI. Our last two attempts sadly broke such downstream users and local contributors, so both attempts had to be reverted. Since testing here is tricky, progress here might be on the slower side; we will see. offload Most of the work on the offload side lately has been invisible, since we were working on implementing more benchmarks and LLVM optimizations, as well as missing features, discovered by those benchmarks. We achieved excellent performance on those benchmarks; more details will soon be presented by Marcelo Domínguez at the EuroLLVM conference in two weeks! Beyond benchmarks, there was a lot of tinkering on smaller PRs, reviewing, and housekeeping. LLVM-22 landed, so we updated our bootrstrap code to make use of new APIs, and tried to move a few smaller PRs forward, mainly around a better user experience and for making more Rust features available. Since the focus is still on benchmarks, not many of those PRs landed. They are in a mostly ready state, so it's a good time to pick them up if you're considering contributing. Please ping me on Zulip or in any PR with the offload label if you are interested! People involved: Tomas Sedovic , compiler contributors Champions: compiler (Wesley Wiser) Status: Continued 4 detailed updates available. Tomas Sedovic — comment from 2026-01-16 Update from the 2026-01-14 meeting: #![register_tool] Tyler Mandry proposed FCP of the RFC#3808 and nominated it for a Lang discussion. -Zdebuginfo-compression Wesley Wiser proposed stabilization: rust#150625. Josh Triplett suggested trying to bring zlib- rs in the kernel as a case study. -Zdirect-access-external-data rust#150494 was merged two days ago, what reminds is updating the documentation and stabilizing the feature. There's an ongoing discussion about the feature on the Rust Zulip as well. Tomas Sedovic — comment from 2026-02-17 Updates from the 2026-01-28 and 2026-02-11 meetings: -Zdirect-access-external-data Gary Guo's fix PR was merged. --emit=noreturn Miguel Ojeda reiterated that this is high on the list of compiler features the project needs. Right now, they're doing these checks manually. Improving objtool's handling of noreturn is on Gary Guo's radar but there wasn't time yet. Tomas Sedovic — comment from 2026-03-16 Update from the 2026-03-11 meeting: --emit=noreturn It seems that figuring out which functions are noreturn is at a level too low for rustc. Function signatures are not sufficient and there are cases where rustc doesn't know whether to emit noreturn. It is something we should ask the LLVM to give us that information. Alice Ryhl opened a new issue to introduce the -Zsanitizer=kernel-hwaddress sanitizer for aarch64 targets: https://github.com/rust-lang/compiler-team/issues/975 -Zharden-sls Wesley Wiser is working on allowing forbidden target features to be hard errors, which the -Zharden-sls patch should be rebased on top of. #![register_tool] The corresponding RFC has been discussed by the Lang team on 2026-03-11. The overall vibe was positive and TC is going to read through it and hopefully check a box on the proposed FCP. The proposed stabilization received some feedback that needs to be addressed.

      The discussion here has stalled.

      Update from the 2026-04-08 meeting:

      rust#153049 is merged. What remains of the tracking issue rust#154171 is a few docs checklists. Alice Ryhl added the unstable book doc changes in the PR itself and Wesley Wiser confirmed that's all the documentation needed for sanitizers.

      6 detailed updates available.

      Update from the 2026-01-14 meeting.

      Deref / Receiver Ding's arbitrary_self_types: Split the Autoderef chain rust#146095 is waiting on reviews. It updates the method resolution to essentially: deref_chain(T).flat_map(|U| receiver_chain(U)). The perf run was a wash and a carter has completed yesterday. Analysis pending. Ding has submitted a Rust Project goal for Supertrait Auto Impl. Arbitrary Self Types We've discovered the #[feature(arbitrary_self_types_pointer)] feature gate. As the Lang consensus is to not support the Receiver trait on raw pointer types we're probably going to remove it (but this needs further discussion). This was a remnant from the original proposal, but the Lang has changed direction since. derive(CoercePointee) Ding is working on a fix to prevent accidental specialization of the trait implementation. rust#149968 is adding an interim fix. Alice opened a Reference PR for rust#136776. There are questions around the behaviour of the as cast vs. coercions. Pass pointers to const in assembly Gary opened implementation for the RFC: rust#138618. Field Projections Benno updated the Field Representing Types PR to the latest design. This makes the PR much simpler. Tyler opened a Beyond References wiki to keep all the proposals, resources in one place. In-place initialization Ding is writing a post to describe all the open proposals including Alice's new one that she brouhght up during the LPC 2025. He'll merge it in the Beyond References wiki. Macros, attributes, derives, etc. Josh brought up his work on adding more capable declarative macros for writing attributes and derives. He's asked the Rust for Linux team for what they need to stop using proc macros. Miguel noted they've just added dependency on syn, but they would like to remove it some day if their could. Benno provided a few cases of large macros that he thought were unlikely to be replaceable by declarative-style ones. Josh suggested there may be a way and suggested an asynchronous discussion. Tomas Sedovic — comment from 2026-02-16 Updates from the 2026-01-28 and 2026-02-11 meetings: Removing the likely/unlikely hints in favour of cold_path The stabilization of core::hint::cold_path lint is imminent and after it, the likely and unlikely hints are likely (pardon the pun) to be removed. The team discussed the impact of this. These hints are used in C but not yet in Rust. cold_path would be sufficient, but likely/unlikely would still be more convenient in cases where there isn't an else branch. Tyler Mandry mentioned that these can be implemented in terms of cold_path. Niche optimizations We discussed the feasibility of embedding data in lower bits of a pointer -- something the kernel is doing in C. This could also enable setting the top bit in the integers (which is otherwise never set) and make it represent an error in that case (and a regular pointer otherwise). Ideally, this would be done in safe Rust, as the idea is to improve the safety of the C code in question. Extending the niches is something Rust wants to see, but it's waiting on pattern types. There are short/medium-term options by using unsafe and wrapping it in a safe macro, but the long-term hope is to have this supported in the language. Vendoring zerocopy The project has interest in vendoring zerocopy. We had its maintainers Jack Wrenn and Joshua Liebow- Feeser join us to discuss this and answer our questions. The main question was about whether to vendor at all, how often should we (or will have to) upgrade, and how much of it is expected to end up in the standard library. The project follows semver with the extended promise to not break minor versions even before 1.0.0. We could vendor the current 0.8 and we should be upgrade on our own terms (e.g. when we bring in new features) rather than being forced to. Right now, the project is able to experiment with various approaches and capabilities. Any stdlib integration a long way away, but there is interest in integrating these to the language and libraries where appropriate. New trait solver There's been a long-term effort to finish the new trait solver, which will unblock a lot of things. Niko Matsakis asked about things it's blocking for Rust for Linux. This is the list: unmovable types, guaranteed destructors, Type Alias Impl Trait (TAIT), Return Type Notation (RTN), const traits, const generics (over integer types), extern type. 2026 Project goals This year brings in the concept of roadmaps. We now have a Rust for Linux and a few more granular Goals. We'll be adding more goals over time, but the one merged cover what we've been focusing on for now. Tomas Sedovic — comment from 2026-03-11 Update from the 2026-02-25 meeting: 2026 Project goals We spent most of the meeting going over the open Project goals, the Rust for Linux roadmap and other things we'd like to see that aren't the right shape for a goal. Miguel Ojeda brought up the upcoming Debian 14 release (coming out probably somewhere around Q2 of 2027) and we went over each item and decided whether it's something we need to make sure is in that release or not. Debian stable is an important milestone and the Rust version in it serves as a baseline for Rust for Linux development. I'll add all this data into the roadmap. Tomas Sedovic — comment from 2026-03-16 Update from the 2026-03-11 meeting: Field projections We now have a macro and machinery that uses the projection mechanism. The dma_read! / dma_write! macros switched over to it. This also fixes a soundness issue 1. Note: this is done entirely via macros and doesn't use any Field projections language features. The Field projection syntax and traits should make this more ergonomic and integrate the borrow checker so we can accept more code. We're planning to have a design meeting with the Lang team in the last week of March. rustfmt imports formatting and trailing slashes We talked about the rustfmt formatting of the use statements again. While the trailing empty comment // workaround (see this update) is acceptable as a temporary measure, we need to find a long-term solution where you can configure rustfmt to accept this style. We don't have a issue for this specific formatting yet, though it was discussed in #3361. The next step are to create such an issue. We were hesitant to add burden to a team that's already at limit, but having the issue would let us track it from the Rust for Linux side. Tomas Sedovic — comment from 2026-03-26 Update from the 2026-03-26 meeting: Const generics Boxy asked the team for features that are most important under the const generics umbrella. This might help with prioritisation and just understanding of practical uses. 1. **Ability to do arithmetic on const generic types** : e.g. the kernel has a type Bounded which has a value and a maximum size (in bits). Both the bit width and value are const values. They want to be able to do arithmetics on these types (starting with bit shifts) that will guarantee the the result will fit within the specified size at compile time. 2. Argument-position const generics : right now, the const generic types must be specified in the type bound section (within the angle brackets). So for example you have to write: Bounded::<u8, 4>::new::<7>() instead of the more natural Bounded::<u8, 4>::new(7). This gets more complicated when there's const-time calculation happening rather than just a numerical constant -- in which case this also needs to be wrapped in curly brackets: { ... }. 3. Being generic over types other than numbers: pointers would be useful for asm_const_ptr. String literals too -- even if they're just passed through without being processed / operated on. And if going from a passthrough string makes it possible to pass through any type, that would help the team replace some typestate patterns they're using with an enum. statx Alice Ryhl proposed being able to create std::fs::Metadata from Linux statx syscall. This was discussed in the Libs-API meeting and they had questions about possible evolutions of the statx ABI -- if/how it can grow in the future and how they could handle that if they wanted some of the new data available. So we discussed it in the Rust for Linux meeting. In the end, it seems prudent to be reasonably defensive rather than relying on the syscall pre-filling default values. Alice Ryhl proposed an opaque statx struct that would give the stdlib a way to decide on the struct's size, pre-filled contents and mask. Miguel Ojeda suggested contacting Christian Brauner and Alexander Viro (i.e. the VFS maintainers); Josh Triplett agreed that it would be good if we can get a thread with the right people in linux-fsdevel. Tomas Sedovic — comment from 2026-04-10 Update from the 2026-04-08 meeting: zerocopy features in Rust's std zerocopy uses two traits that are both polyfills for unstable traits : KnownLayout (for ptr_metadata) and Immutable (for Freeze). It would help maintenance of zerocopy (which Rust for Linux plans to start using) if these were stabilised. ptr_metadata is something the team wants in the kernel independently. It's possibly blocked on (or at least might have interactions with) the Sized Hierarchy work. Freeze (now NoCell) has an RFC. Deref/Receiver Jack Huey started reviewing Ding Xiang Fei's PR to split the autoderef chain and feels it's not ready to go in front of the full Lang team. We also discussed the dependence/independence of the Deref and Receiver implementations, in particular whether it ever makes sense to implement Deref but not Receiver. Josh Triplett suggested gathering examples for cases like that (where you can't use the type as a Self type in the function declaration, but allow calling methods on it). The current plan for the experiment is to have these traits separate, but have the compiler enforce that if they implement the same type, their targets are identical. This will let us open the door for any future possibilities (a supertrait / subtrait relation, or having diverging targets in the future). We want to experiment to see where and how these traits and their possible evolution might be helpful. null-ptr-deref The team would like to have a (an optional) compiler guarantee, that the compiler never removes null checks on raw pointers. What can currently happen in C is that if you deref a null pointer, the compiler can do optimisations including removing any subsequent checks whether that pointer is null, because dereferencing a null pointer is undefined behaviour. But the null check can still help prevent further bugs and in C, the kernel now disables the optimisation that would remove it. Miguel Ojeda is going to open an MCP for this. In-Place Initialization Benno Lossin opened a proposal for an in- person room at the 2026 All Hands for In-place initialization. Here's a meta issue tracking all the proposals and discussions about the feature. The design space is complex and the team hopes that discussing it in person will help move it forward. People involved: Ed Page , b-naber Champions: cargo (Ed Page), compiler (b-naber), crates-io (Carol Nichols) Status: Continued People involved: Amanieu d'Antras Champions: lang (Amanieu d'Antras) Status: Continued 1 detailed update available. Amanieu d'Antras — comment from 2026-04-03 The RFC has just been published. It has been significantly reworked since the last draft. Notable changes: * Removed the concept of activation/de-activation. Now the semantics don't need to deal with partially allocated locals. This is less powerful optimization-wise but should still cover most cases. * Added byref/byval to call arguments to clarify how they are passed. * Added a separate section for the surface language changes to separate it from the MIR changes. * Added more details on the MIR optimization which eliminates moves. * Changed the MIR operand evaluation order to be left-to-right, except for destination places which are always evaluated last. * Added StorageLive back: we need it to mark the location where llvm.lifetime.start should be inserted, which is not the same as the location where a local is initialized. In the opsem, StorageLive doesn't actually allocate the local, that's still done when it is initialized by a write. People involved: Ed Page Champions: cargo (Ed Page) Status: Continued People involved: Weihang Lo Champions: cargo (Weihang Lo) Status: Completed 1 detailed update available. Weihang Lo — comment from 2026-01-08 The prototype of this project goal is basically complete. Current state This project goal introduces build analysis support in Cargo , with the aim of making build behavior understandable across multiple invocations, not just a single run. At a high level, the prototype: * Records build metadata over time, including: * rebuild reasons * timing information * relevant invocation context * Stores this data locally in a structured log format suitable for later analysis * Exposes the data via unstable cargo report subcommands, such as: * cargo report sessions - list session IDs * cargo report timings - HTML timing report * cargo report rebuilds - Why things rebuilt See the Reference for a more thorough usage documentation Path towards stabilization Before this feature can be stabilized, the following unresolved questions must be answered. They might not block stabilization, but need to be evaluated if it is fine to leave for future. cargo report commands This is a stabilization blocker. * Currently all three report commands (`sessions`, `rebuilds`, timings) implicitly inspect global log files when if not in a workspace. * Should this be explicit with a flag? * Should this be an error if not in a workspace? * Bikeshed on command names * Currently we have all nouns * For sessions * runs simple but ambiguous * Just log like git log * history user-friendly (docker history, shell history, though not alike) * For timings: * Not controversial, as we have --timings flag already * For rebuilds: * rebuild-reasons more explicit * Or move to action-oriented verbs: * cargo report list-sessions * cargo report analyze-timings (bazel analyze- profile) * cargo report explain-rebuilds * Or question-oriented verbs: * cargo report what-ran more general (buck2 log what- ran) * cargo report why-rebuilt/why-reran cargo report sessions * Currently it prints a human-readable output without a format for programmable use cases. * Should we provide a programmable output (for example behind --message-format=json)? cargo report rebuilds * Extend the report from fingerprint to new hash (`-Cmetadata`/`-Cextra- filename`) * We currently can't distinguish whether a fresh build is a real new build or just rustflags changed * https://github.com/rust- lang/cargo/pull/16456#discussion_r2662364819 * Make each rebuilt reason more actionable and friendly for end-users. * Should we log the fingerprint values being compared, or just the diff result? * #t-cargo > logging unit fingerprint @ 💬 Log message schema This is a stabilization blocker. * Providing types for reading log messages * We should export `LogMessage` enum and related types in `cargo-util- schemas* Users may want to parse logs programmatically * <https://github.com/rust- lang/cargo/pull/16150#discussion_r2462065538> * JSON schema evolution and versioning * Should we version the schema explicitly in each message? * Compatibility might be the same as <https://doc.rust- lang.org/nightly/cargo/commands/cargo- metadata.html?highlight=compa#compatibility> * Message structure consistency * Current log messages deviate from cargo's normal JSON message structure * Should we align with existing cargo JSON output format, for example thetargetfield? * <https://github.com/rust- lang/cargo/pull/16414#discussion_r2632724893> * <https://github.com/rust- lang/cargo/pull/16303#discussion_r2565526807> * <https://github.com/rust- lang/cargo/pull/16303#discussion_r2561862478> * Should we expose the entireDirtyReasonenum as-is? * Currently exposes internal implementation details * May want to create a separate public-facing enum * Need to decide which variants are user-facing vs internal * Check usefulness of each variant * Some variants may be obsolete (e.g.,RustflagsChangedmay be rare after-Cmetadatachanges) * Need audit of which variants actually occur in practice * Remove or consolidate rarely-used variants * Make dirty reasons end-user friendly * Current reasons are technical (e.g., "local fingerprint type changed") * Users need actionable messages (e.g., "file modified: src/lib.rs") * Exposetargetandmode` * Are they universal for all kind of units? We might want to rename mode to action, as an action kind of a unit. * https://rust- lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20analysis.20log.20format/near/564781487 Log infrastructure These are mostly future possibilities, not a stabilization blocker, as it is highly possible to do incremental improvements. * log compression <https://github.com/rust-lang/cargo/issues/16475> * log rotation <https://github.com/rust-lang/cargo/issues/16471> * Is losing data on crashes ok? https://github.com/rust- lang/cargo/pull//16150#discussion_r2462056940 See also https://github.com/rust- lang/cargo/issues/16471#issuecomment-3724915770 Nested Cargo calls See https://github.com/rust-lang/cargo/issues/16477. Basically, we need to have a way to associate log files of nested Cargo calls. That helps other tools as well as cargo fix itself. This is a stabilization blocker. How contributors can help Future contributors can help by: * picking up any linked issues below or in <https://github.com/rust- lang/cargo/issues/15844> * building external tools utilizing the log messages, and providing feedback * providing real-world feedback from large or unusual builds A series of follow-up tasks has been cut to track remaining work: * https://github.com/rust-lang/cargo/issues/16470 * https://github.com/rust-lang/cargo/issues/16471 * https://github.com/rust-lang/cargo/issues/16472 * https://github.com/rust-lang/cargo/issues/16473 * https://github.com/rust-lang/cargo/issues/16474 * https://github.com/rust-lang/cargo/issues/16475 * https://github.com/rust-lang/cargo/issues/16477 * https://github.com/rust-lang/cargo/issues/16488 People involved: Oliver Scherer Champions: compiler (Oliver Scherer), lang (Scott McMurray), libs (Josh Triplett) Status: Continued 5 detailed updates available. Oliver Scherer — comment from 2026-01-14 * has landed, and we even got the first contribs adding array support to reflection. * there are lots more types and type information that we could support, and it's rather easy to add more. Happy to review any work here. * try_as_dyn and try_as_dyn_mut have landed, and I'm working on removing the 'static requirement. Oliver Scherer — comment from 2026-02-09 * @BD103 added [`Type::of` for unsized types](https://github.com/rust- lang/rust/pull/151019) and support for slices, arrays, and raw pointer * Asuna added all of our primitives * Jamie Hill-Daniel gave us references * @izagawd made it possible to extract some info from dyn Trait There is ongoing work for Adts and function pointers, both of which will land as MVPs and will need some work to make them respect semver or generally become useful in practice Removing the 'static bound from try_as_dyn turned out to have many warts, so I'm limiting it to a much smaller subset and will have borrowck emit the 'static requirement if the other rules do not apply (instead of having an unconditional 'static requirement) Oliver Scherer — comment from 2026-03-19 * I added [support for getting reflection information of any type, not just 'static ones](https://github.com/rust-lang/rust/pull/152381) * 9SonSteroids added a function pointer MVP and trait object support * Asuna added basic struct/enum/union support Oliver Scherer — comment from 2026-04-22 No changes since last time. I'm writing a document for the lang team meeting on reflection next week Oliver Scherer — comment from 2026-04-22 Help wanted

      * add more information to adts (e.g. doc comments, attributes, ...),

      whatever else is usually used by crates like bevy-reflect * need to make struct field reflection respect privacy

      People involved: Ross Sullivan Champions: cargo (Weihang Lo) Status: Completed; the Cargo cross workspace cache 2026 goal will build on this work 2 detailed updates available. Ross Sullivan — comment from 2026-01-15 Fine grain locking for build-dir was merged and now available on nightly via -Zfine- grain-locking unstable flag. 🎉 There are some known issues we'd like to address before doing a formal call for testing. Notably, improving blocking messages, fixing potential thread starvation in Cargo's job queue when locks block, and investigate increasing rlimits to reduce risk of hitting max file descriptors for large projects. I am hopeful that these issues will be resolved over the coming month and we can do a call for testing to start gathering feedback from the community on whether the new locking strategy improves workflows. Ross Sullivan — comment from 2026-03-09 After the initial PR from the last update was merged, we shifted our focus to resolving some of the known issues. Notably, locking blocks the Cargo job queue slowly causing thread starvation if many build units are held by another Cargo instance. We investigated adding the ability for Cargo to "suspend" a job internally while waiting for a lock, but we felt this change was a bit invasive and did not fit well with how the job queue was designed. Instead we plan to change our design to acquire all build unit locks prior to running the job queue (see #16657). At the same time, we have continued to refine the new build-dir to prepare it for a call for testing and eventual stabilization. (#16542, #16502, #16515, #16514) Finally we decided to split .cargo-lock into 2 locks to allow cargo check and cargo build to run in parallel when artifact-dir == build-dir (and -Zfine-grain-locking is enabled) I suspect this may be the last update on this goal, as the 2026 slate of goals is coming up. While I did not renew this goal for 2026, I do plan to continue work on this and eventually stabilize this within this year. People involved: Guillaume Gomez Champions: compiler (Wesley Wiser), infra (Marco Ieni) Status: Completed People involved: Jakob Koschel , Bastian Kersting Status: Continued 3 detailed updates available. Jakob Koschel — comment from 2026-01-14 The MCP has been seconded and is still waiting 3 days to be approved. Once that is done, we can proceed with merging the Tier 2 target. Jakob Koschel — comment from 2026-02-16 Both the MCP and the PR for the AddressSanitizer target have been merged. Next up I should prepare the MCP for the Memory- and ThreadSanitizer targets, hopefully sending out soon. Jakob Koschel — comment from 2026-03-31 The targets for MSan and TSan are merged now. Next, I'll be working on stabilizing those two, now that we have a way to use it without other unstable features (build-std). People involved: Niko Matsakis , vision team Status: Partially completed; work continues outside of Project Goals People involved: James Barford , Jakub Beránek, David Wood Champions: compiler (David Wood), infra (Jakub Beránek) Status: Technical work completed; remaining policy and infrastructure work postponed People involved: Ed Page Champions: cargo (Ed Page) Status: Continued People involved: Guillaume Gomez Champions: rustdoc (Guillaume Gomez) Status: Not completed (blocked)

      5 detailed updates available.

      rust-lang/rust#143924 has been merged, enabling scalable vector types to be defined on nightly, and I'm working on a patch to introduce unstable intrinsics/scalable vector types to std::arch

      Progress has been slow since the last update because I've been busy, but I've been working on a rebase of rust- lang/stdarch#1509, which has bitrot quite a bit. Rémy Rakic is joining me to work on the Sized Hierarchy parts of the goal.

      On the scalable vector half of the goal, I've got a branch with rust- lang/stdarch#1509 rebased, though without the intrinsic-test tool having been updated - that ended up being tricky and we've agreed to do it as a follow-up. We've opened rust- lang/rust#153286 with the compiler fixes that the stdarch patch requires, which should land soon (rust-lang/rust#153653 was opened and landed in the interim).

      On the sized hierarchy half of the goal, Rémy Rakic has been updating our RFC such that we can discuss it in design meetings with the language team on the 18th and 25th - we'll update rust-lang/rfcs#3729 later today. We've split out the const Sized parts as a future possibility (though one we are committed to pursuing) as that has more open design questions, and we've discussed the proposed syntax and approach to migration - which are what we intend to focus on in the design meetings. He's also been working out how we can start implementing our migration strategy and help resolve blockers in other areas.

      Per last comment, rust-lang/rfcs#3729 has been updated

      For the scalable vector half of the goal, we've landed a bunch of compiler fixes - rust-lang/rust#153286, rust-lang/rust#153608, rust-lang/rust#154850, rust-lang/rust#154950, rust-lang/rust#155106 and rust-lang/rust#155243 - and opened our stdarch patch with intrinsics - rust-lang/stdarch#2071. That patch should be passing CI tomorrow once nightly updates to fix an unrelated spurious CI failure. We've got a handful of follow-ups to do afterwards, listed on rust-lang/rust#145052.

      For the sized hierarchy half of the goal, Rémy Rakic and I had two design meetings with the language team (2026/03/18 and 2026/03/25) discussing the syntax/naming and migration strategy respectively.

      On syntax, the language team preferred introducing an "only bounds" syntax to control opting-out of default bounds and opting-in to alternative bounds in a family of traits (described in an alternative in the RFC), but there was an open question of whether that syntax should apply to an individual bound or all of the bounds - Niko Matsakis is investigating that.

      On naming, the language team also preferred the name SizeOfVal over MetaSized, and didn't like Pointee but had no better alternatives. Rémy Rakic prepared rust-lang/rust#154374 to do that renaming and started a discussion with the library team to confirm they were happy with the name, because changing it involves an amount of churn. The library team wanted to know what other traits in the hierarchy might later be introduced, as that would help inform the naming of the currently proposed traits, so Rémy Rakic wrote up a document with that information. We're holding off on doing any name changes until we find some consensus between libs and lang - who is responsible for these traits' names is a bit unclear.

      On migration, the language team were largely happy with our proposed approach, and we realised that the approach proposed by lcnr for associated types might also work for our other migrations. Rémy Rakic has had meetings with lcnr to better understand that approach and to work out the next steps for implementing it.

      2 detailed updates available.

      RFC has been accepted. I'm preparing a 2026 continuing goal for stabilization.

      Opened PR (#16767(https://github.com/rust-lang/rust- clippy/pull/16767)) extending Clippy support to unsafe fields.

      Blockers

      Waiting for t-clippy to review #16767(https://github.com/rust-lang/rust- clippy/pull/16767).

generated: May 21, 2026 at 10:20:44