🏑


  1. September 25, 2026
    1. πŸ”— New Music Releases The Ocean - Solaris rss

      The Ocean - a new release is available:

      • 2026-09-25: Solaris (Album)

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

      Visit muspy for more information.

  2. September 18, 2026
    1. πŸ”— New Music Releases O.A.R. - Three Tinted Windows rss

      O.A.R. - a new release is available:

      • 2026-09-18: Three Tinted Windows (Album)

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

      Visit muspy for more information.

  3. August 14, 2026
    1. πŸ”— New Music Releases Saliva - Breaking Through rss

      Saliva - a new release is available:

      • 2026-08-14: Breaking Through (Album)

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

      Visit muspy for more information.

  4. July 24, 2026
    1. πŸ”— New Music Releases The Revivalists - Get It Honest rss

      The Revivalists - a new release is available:

      • 2026-07-24: Get It Honest (Album)

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

      Visit muspy for more information.

  5. July 14, 2026
    1. πŸ”— New Music Releases Saliva - Longshot rss

      Saliva - a new release is available:

      • 2026-07-14: Longshot (Single)

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

      Visit muspy for more information.

  6. July 10, 2026
    1. πŸ”— New Music Releases Bring Me the Horizon - Count Your Blessings | Repented rss

      Bring Me the Horizon - a new release is available:

      • 2026-07-10: Count Your Blessings | Repented (Album)

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

      Visit muspy for more information.

    2. πŸ”— New Music Releases If These Trees Could Talk - The Hidden Hand rss

      If These Trees Could Talk - a new release is available:

      • 2026-07-10: The Hidden Hand (Album)

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

      Visit muspy for more information.

  7. June 28, 2026
    1. πŸ”— r/reverseengineering WinPE as a stateless harness for Windows driver testing and fuzzing rss
    2. πŸ”— r/reverseengineering Reverse-engineering VMware's encrypted + compressed VM memory checkpoint format (vTPM "partial" encryption) rss
    3. πŸ”— backnotprop/plannotator v0.21.3 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.21.2 | Custom reviews as Agent Skills, Cursor + OpenCode review engines, whole-file/general findings, deleted-annotation fix, Codex Ask AI outside git repos
      v0.21.1 | Annotate-last blank-page fix on multi-message sessions
      v0.21.0 | Direct document editing in annotate mode, live git-status file tree, in-app agent terminal, open files in external apps, HTML renders as HTML
      v0.20.3 | Annotations no longer lost when clicking away, off-screen indicator for open comments
      v0.20.2 | Pierre CodeView all-files review, large-PR pipeline and instant-open checkout, unified agent engine selection, Pi programmatic plan mode
      v0.20.1 | Pi extension install hotfix (pinned @pierre/diffs after a broken upstream release)
      v0.20.0 | Multi-repo workspace reviews, semantic diff overview, UI 2.0 themes and plan look chooser, leaner single-source skill install
      v0.19.27 | Kiro CLI integration, Glimpse native window, annotate-last message picker
      v0.19.26 | Amp plugin production fixes, Mermaid rendering fix, Settings flicker fix, update notification toast and shimmer
      v0.19.24 | Amp integration, configurable data directory, Auto Mode permission option, Pi plan approval fix
      v0.19.23 | Droid integration, Windows Pi AI fix, quieter update indicator


      What's New in v0.21.3

      A follow-up to the code-review work in v0.21.2. The headline is file-scoped comments in code review with a reworked comment experience, and the rest of the release is fixes and polish: a new contributor fixed clipboard and keyboard handling in the VS Code extension, the CLI now prints help for its subcommands, Codex Ask AI moved onto a more reliable transport, and the Ask AI sidebar got a few rough edges sanded down. Eight changes land in total, including a first contribution from @rushelex.

      File Comments in Code Review

      Until now a code-review comment always attached to a line range. This release adds file-scoped comments β€” a comment that belongs to a whole file rather than any single line. In the single-file view it renders as a full-text banner directly below the file path; in the all-files view it sits in the file header for expanded files. Guided reviews that produce file-level findings now anchor them where they belong instead of forcing them onto a line.

      The comment experience was also unified. Clicking a comment β€” whether the inline card in the diff, the sidebar entry, or the file banner β€” replays its stored line range as a controlled highlight, and clicking it again clears the highlight. Scrolling the viewport to a comment is reserved for the sidebar and findings list, so clicking a comment inside the diff highlights it without yanking the page around. The inline, sidebar, and file-banner cards now share a single identity row (badges, author, timestamp), a single action row (edit, copy, delete), and a consistent file-name chip, replacing three separately built layouts that had drifted apart.

      PR #973, by @backnotprop.

      VS Code Clipboard and Keyboard Handling

      The VS Code extension renders Plannotator inside a webview, and two long- standing problems made that webview feel second-class. Copy and paste didn't work β€” clipboard content never crossed the webview boundary β€” and standard VS Code keybindings like Cmd+P stopped responding while a Plannotator tab was focused. This release bridges the clipboard so copy, cut, and paste work inside the webview, and forwards keystrokes to VS Code so its keybindings resolve as expected.

      PR #970 closing #864 and #969, by @rushelex β€” who both reported the bugs and contributed the fix.

      Codex Ask AI on the App-Server Transport

      Codex Ask AI no longer drives codex exec through the @openai/codex-sdk package. It now runs a long-lived codex app-server process over JSON-RPC, which respects the user's and enterprise-managed approval policy and supports interactive Allow/Deny approvals surfaced as cards in the UI. The provider id stays codex-sdk so existing saved preferences keep working. A startup edge case is also fixed: if the app-server process spawned but stalled on its initialize handshake, it was left running and every later question hung until an idle timer reaped it. The process is now killed on a failed handshake, so the next question starts cleanly.

      PR #971, by @backnotprop.

      CLI Subcommand Help

      Running plannotator review --help (and the same for other subcommands) launched the review UI instead of printing help text. The CLI now resolves --help and -h for each subcommand before dispatching, so the help flag prints usage and exits without starting a server.

      PR #974 closing #964, reported by @rrei.

      Clickable Ask AI Announcement Cards

      The first time Ask AI appears, an announcement dialog presents the available providers as cards. Those cards were missing their click handler, so selecting a provider from the announcement did nothing. They are clickable now and select the provider as expected.

      PR #975 closing #972, reported by @Duo-Huang.

      Ask AI Sidebar Polish

      Two smaller fixes in the code-review Ask AI sidebar. The per-file chat groups used to start collapsed, so every file you had asked about had to be opened by hand; they now default to expanded, while manual collapse still works and persists. And clicking a sidebar comment that no longer matches the active PR or diff scope β€” for example after switching PRs in place β€” used to do nothing at all; it now clears the current selection so the click gives visible feedback instead of appearing broken.

      Additional Changes

      • Dependency maintenance β€” GitHub Actions used by the build and release workflows were updated (actions/checkout to v7, softprops/action-gh-release to v3, and others). PR #791, by @renovate.

      Install / Update

      macOS / Linux:

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

      Windows:

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

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

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

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

      OpenCode: Clear cache and restart:

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

      Then in opencode.json:

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

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension
      

      Droid: Install via the plugin marketplace:

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

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

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

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

      kiro-cli chat --agent plannotator
      

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


      What's Changed

      • feat(review): file comments in the diff + unified click-to-highlight comment UX by @backnotprop in #973
      • fix(vscode): bridge clipboard and forward keystrokes in webview by @rushelex in #970
      • fix(annotate): make Ask AI announcement provider cards clickable by @backnotprop in #975
      • fix(cli): print per-subcommand help instead of launching the UI by @backnotprop in #974
      • fix(ai): drive Codex Ask AI via codex app-server by @backnotprop in #971
      • fix(ai): kill codex app-server if the initialize handshake fails by @backnotprop
      • fix(review): default Ask AI per-file chat groups to expanded by @backnotprop
      • fix(review): clear selection on out-of-scope sidebar annotation click by @backnotprop
      • chore(deps): update github actions by @renovate in #791

      New Contributors

      Contributors

      @rushelex landed their first contribution, and a complete one: they reported that the VS Code extension couldn't paste from the clipboard (#864) and that VS Code keybindings stopped working while a Plannotator tab was focused (#969), then fixed both in #970.

      Thanks also to the people who reported the bugs this release fixes:

      • @rrei reported that plannotator review --help launched the UI instead of printing help (#964), fixed in #974.
      • @Duo-Huang reported that the Ask AI announcement provider cards were not clickable (#972), fixed in #975.

      Full Changelog : v0.21.2...v0.21.3

    4. πŸ”— symgraph/IDAssist Fixes OpenWebUI provider issue. release

      No content.

    5. πŸ”— jellyfin/jellyfin 12.0 RC2 release

      πŸš€ Jellyfin Server 12.0 RC2

      We are pleased to announce the second release candidate preview release of Jellyfin 12.0!

      This is a preview release, intended for those interested in testing 12.0 before it's final public release. We welcome testers to help find as many bugs as we can before the final release.

      As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!

      A note about versioning

      Starting with this release, we are dropping the preceeding10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was. For more information, please see the RC1 release notes.

      What's new?

      The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.

      There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests. You can also view the Web side changelog here.

      Note: You must be on Jellyfin 10.10.7+ or 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. Ensure you upgrade to one of these versions first!

      Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process. You can leverage the (newly improved!) startup UI on your local network to see specific progress, or off-network to see general progress, by visiting the server URL in your web browser during startup.

      Note: If you install the RC, you should disable all external plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.

      Installing

      This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.

      • For all non-Docker environments, you can find the files for manual download in our repository by selecting "Stable Preview" for your OS.
      • For Docker, you can pull the 12.0-rc2 or preview tags.

      What's Changed (since

      v12.0-rc1)

      New Contributors

      Full Changelog : v12.0-rc1...v12.0-rc2

    6. πŸ”— r/reverseengineering Blindspot rss
    7. πŸ”— r/reverseengineering GitHub - iss4cf0ng/NebulaPulsar: NebulaPulsar is a proof-of-concept in-memory implant framework for Java (JSP) and ASP.NET (ASPX/ASHX/ASMX) webshells, originally developed as part of the Alien project. rss
    8. πŸ”— r/reverseengineering WPA3-SAE + 802.11w on the Broadcom BCM4360 (closed wl blob) rss
    9. πŸ”— r/reverseengineering Static BYOVD hunter: Capstone-based IOCTL dispatch extraction rss
    10. πŸ”— The Pragmatic Engineer Pollen tried to remove my article about CEO Callum Negus-Fancey and CTO Bradley Wright, and Google is assisting with it rss

      Pollen tried to remove my article about CEO Callum Negus-Fancey and CTO
Bradley Wright, and Google is assisting with
it

      In 2022, I wrote about the damning fall of events tech company Pollen. The short of it:

      Pollen seemed to have pulled off the improbable feat of building a business in the notoriously low margin industry of events, surviving Covid-19, and building a solid software engineering organization. In April this year, the company announced it had raised another $150M in fresh funding.

      But just three weeks later, Pollen laid off about 200 people, a third of staff. Leadership assured employees all was well. However, from that point on, things got worse. Leadership later pulled the plug on Slack, employees were not paid wages, pension contributions went missing, and vendors were not paid. Some vendors took matters into their own hands; on 9 August 2022, JIRA was suspended when Atlassian tired of the company's failure to pay.

      On 10 August 2022, Pollen went bankrupt, collapsing into administration.

      The article looked bad on Pollen's founder, Callum Negus-Fancey. He was ultimately responsible for lying to staff, not paying salaries, the missing pension contributions, and the unpaid health insurance for US employees. The story was so bad that the BBC created a documentary titled Crashed: $800M Festival Fail _. _

      And then there was the $3.2M dobule charge for customers, manually initiated by CTO Bradley Wright, detailed extensively in the documentary Crashed: $800M Festival Fail. That double charge would have been trivial to reverse, but the reversal never happened, customers never got their money back, and the postmortem of the incident was never released to staff.

      Four years later, Pollen and Callum Negus-Fancey are attempting to erase this shameful story from the public record. The article is my original writing, and thus I am the copyright holder of it. So imagine my surprise when I was notified that Google removed the article from its search results thanks to a copyright infringement claim it received:

      Pollen tried to remove my article about CEO Callum Negus-Fancey and CTO
Bradley Wright, and Google is assisting with
itPollen
tried to remove my article about CEO Callum Negus-Fancey and CTO Bradley
Wright, and Google is assisting with
it

      It seems that anyone can file a bogus copyright claim to get an article they don 't like removed from Google's search index. This happened in this case. I have no information on who filed the copyright claim. Even less so on who claims to be the copyright owner? Because I am the only possible copyright owner!

      And Google has gone ahead and removed my article about Pollen's shameful collapse from its search results.

      I have the option to appeal, which I have done so.

      Google 's copyright removal system is clearly being abused, to a comical degree. Someone doesn't like that I went into extreme detail about the events at Pollen - all of which are facts. And, for some reason, bogus copyright requests can be weaponized to remove information like this from Google's search index.

      I managed to find the bogus DMCA complaint submission, after Google removed my site from search results. It is absolute BS: it claims that my original article is a copy of a The New York Post article. Which is absolute nonsense!

      Pollen tried to remove my article about CEO Callum Negus-Fancey and CTO
Bradley Wright, and Google is assisting with
it

      This "Ellie Piee" claimed that this 1998 article titled Band Leader Hits Winning Chord was copied by my article Inside Pollen's Collapse: "$200M Raised" but Staff Unpaid - Exclusive. The two do not even share a single sentence!

      The fake DMCA is made by a fake profile from a country with zero inhabitants. The removal requests by this "Ellie Piee" are made from the country called Bouvet Island, an uninhabited Norwegian dependent territory in the South Atlantic/Southern Ocean near Antarctica. It has zero inhabitants, and is referred to as the "world's most remote island."

      Pollen tried to remove my article about CEO Callum Negus-Fancey and CTO
Bradley Wright, and Google is assisting with
itBouvet Island. No inhabitants, and yet Google accepted a fake DMCA takedown request from a fake person claiming to reside here. What a joke

      Why does Google allow fraudulent DMCA notices to be filed with no penalty? My own speculation is that it is clear enough that either Pollen, or its former CEO Callum Negus-Fancey, or its cofounder and COO Liam Negus-Fancey or someone else related to the company hired reputation firms to remove Pollen articles from Google. This firm then files the most bogus requests under fake names supposedly residing in uninhabited regions of the world, and Google complies.

      I never thought I would have to revisit the shameful history of Pollen, but someone at the company felt the need to prompt me to do so.

      Lawsuits are still ongoing against Pollen, by the way. Now that someone from Pollen tried to erase the record of this story, I got a bit of renewed interest in what has happened since. In California, the lawsuit Tayler Ulmer vs Pollen is still in progress, summarized as:

      • Tayler Ulmer and five other named former employees, on behalf of themselves and "all similarly situated employees" claim to have been laid off without paid wages and benefits, plus claiming possible fraud
      • The filing says that Pollen executives Callum Negus‑Fancey, Liam Negus‑Fancey, and James Ellis are personally liable in this lawsuit
      • The lawsuit wants to reclaim unpaid wages, unpaid severance, restoration of lost 401(k) contributions, and a uling that all the named entities and individuals are jointly liable, including successor entities, so employees can collect regardless of how Pollen shuffled assets and dissolved subsidiaries

      I am wishing best of luck to the claimants - former Pollen employees - and we will see how the judge rules in this lawsuit. The more Pollen wants to silence me writing about this, the more I'll likely pay attention.

      Pollen executives should have read what the Streinsand effect means!

  8. June 27, 2026
    1. πŸ”— IDA Plugin Updates IDA Plugin Updates on 2026-06-27 rss

      IDA Plugin Updates on 2026-06-27

      Activity:

    2. πŸ”— r/reverseengineering Reverse Engineering dobreprogramy.pl Bundler - Extracting Clean Download URLs Without Executing Adware rss
    3. πŸ”— Locklin on science Statistical picture of Quantum Mechanics rss

      The statistical picture of quantum mechanics is an idea I had in my mind more or less as the correct picture, while occasionally simultaneously holding the gaseous nonsense that the Schroedinger equation somehow describes things the individual particles are doing. Stated simply, the modulus of the solutions to the Schroedinger equation describe a statistical ensemble […]

    4. πŸ”— iv-org/invidious v2.20260626.0 release

      v2.20260626.0

      Wrap-up

      This release hardens playlists, channels, and search, adds a privacy option for searches, and modernizes the packaging and CI pipeline.

      Searches can now be submitted via POST so queries do not leak into server logs or browser history, Invidious cookies work across alternative domains, and "Watch on YouTube" / embed redirects use the correct timestamp and host. Playlist and channel parsing issues got fixed: outdated playlist parsing that hid all videos, paid course videos breaking imports, RSS feeds exposing private playlists without auth, broken author verification badges, and channel videos/playlists not loading from search. Thumbnail paths /pl_c / /tvfilm_banner are now supported, YouTube comments that were written in Japanese, Chinese, Korean and probably other languages do not longer swallows the last character when an emoji is present in the comment, and the search filters dropped the deprecated "sort by rating/date" options.

      Packaging moves Docker builds to the 84codes Crystal compiler image, updates OpenSSL to 3.6.2 and Crystal to 1.20.x in OCI, bumps Alpine to 3.24, and unifies the ARM64 and AMD64 Dockerfiles. Developers benefit from continued encapsulation of constants/helpers/translation/video-parser logic into dedicated modules, an api/v1/channels.cr lint pass, trailing-whitespace cleanup, and a sweep of dependency and GitHub Actions bumps.

      New features & important changes

      For Users

      • Searches can be submitted through POST requests so queries stay out of URLs, server logs and browser history (#5551)
      • Invidious cookies are honoured across alternative configured domains (#5647)
      • Embed and "Watch on YouTube" redirects use the correct t/start parameter and the www.youtube.com host consistently (#5660, #5768)
      • The referrerpolicy/noreferrer handling was corrected now that YouTube requires referrers on embeds (#5642)
      • The listen button on the title updates its elapsed time, and the deprecated "sort by rating/date" search filter options were removed (#5625, #5629)

      For instance owners

      • Docker builds switched to the 84codes Crystal compiler container image, and OCI images were updated to Crystal 1.20.x with OpenSSL 3.6.2 (#5473, #5692)
      • Alpine was bumped to 3.24 in the Docker image (#5778)
      • ARM64 and AMD64 Dockerfiles were unified into a single workflow (#5700)

      For developers

      • Constants and functions were encapsulated into dedicated I18n, Helpers, Invidious::Videos::Parser and Invidious::Videos::Clip modules (#5637, #5639, #5745)
      • api/v1/channels.cr received a lint pass and trailing whitespaces were removed from the codebase (#5693, #5634)
      • CI bumped the Crystal version matrix and displayed compile progress/stats, and the crystal-lang/install-crystal action was updated (#5691, #5696, #5703, #5686)

      Bugs fixed

      User-side

      • Playlists showed no videos because of outdated playlist parsing; this is fixed along with paid course videos breaking the importer (#5774, #5207)
      • Private Invidious playlists were reachable through RSS feeds without authentication (#5776)
      • Channel videos and playlists failed to load from search, and channel author verification was broken (#5736, #5751)
      • A missing collectionThumbnailViewModel hash key crashed channel browsing (#5725)
      • The quality=medium query parameter was appended to videos about to premiere (#5755)
      • YouTube/Invidious links did not rewind their timestamp when playback position was rewound (#5601)
      • The last character of a comment was lost when the comment contained emoji (#5587)
      • Playlist RSS watch URLs only joined params with & when params were present, and thumbnail paths /pl_c and /tvfilm_banner are now supported (#5646, #5742)

      For instance owners

      • Docker/OCI builds keep current with Crystal 1.20.1, OpenSSL 3.6.2, Alpine 3.24 and the unified multi-arch Dockerfile (#5703, #5701, #5778, #5700)

      For developers

      • Dependency and GitHub Actions bumps kept CI current: docker/login-action, build-push-action, metadata-action, setup-buildx-action, int128/docker-manifest-create-action and crystal-lang/install-crystal (#5705, #5766, #5721, #5686, #5661, #5662, #5663, #5664)

      Full list of pull requests merged since the last release (newest first)

      • fix: fix playlists not showing any videos due to outdated playlist parsing (#5774, by @Fijxu)
      • chore(deps): bump alpine from 3.23 to 3.24 in /docker (#5778, by @dependabot[bot])
      • fix: fix private invidious playlists on rss feeds from being fetched without authentication (#5776, by @Fijxu)
      • Use "www.youtube.com" consistently (#5768, by @janmoesen)
      • chore(deps): bump int128/docker-manifest-create-action from 2.21.0 to 2.22.0 (#5766, by @dependabot[bot])
      • Add support for alternative domains for Invidious cookies (#5647, by @Fijxu)
      • Only include '&' if params are present in watch urls for playlist RSS (#5646, by @Fijxu)
      • Dockerfile: Switch to 84codes crystal compiler container image (#5473, by @Fijxu)
      • fix: Do not append query params quality=medium to videos that are about to premiere (#5755, by @Fijxu)
      • Fix Youtube and Invidious links not rewinding their time when video playback position is rewound (#5601, by @Fijxu)
      • feat: Add support for POST requests on searches for privacy (#5551, by @Fijxu)
      • Fix last character disappearance if emoji are in comment (#5587, by @shiny-comic)
      • Encapsulate videos parser and clip functions inside it's own Invidious::Videos::Parser and Invidious::Videos::Clip module (#5745, by @Fijxu)
      • fix: fix author verification in channels (#5751, by @Fijxu)
      • Add support for /pl_c and /tvfilm_banner paths (thumbnails used in some playlists) (#5742, by @Fijxu)
      • fix: fix channel videos and playlists on searches (#5736, by @Fijxu)
      • fix: fix Missing hash key: "collectionThumbnailViewModel" (#5725, by @Fijxu)
      • chore(deps): bump int128/docker-manifest-create-action from 2.20.0 to 2.21.0 (#5721, by @dependabot[bot])
      • chore: update openssl to 3.6.2 in OCI (#5701, by @Fijxu)
      • Bump int128/docker-manifest-create-action from 2.19.0 to 2.20.0 (#5705, by @dependabot[bot])
      • CI: Unify ARM64 and AMD64 Dockerfiles (#5700, by @Fijxu)
      • CI: update Crystal 1.20.0 to 1.20.1 in ci.yml matrix (#5703, by @Fijxu)
      • CI: display progress and stats when compiling Invidious in ci.yml matrix (#5696, by @Fijxu)
      • CI: Bump Crystal version matrix (#5691, by @Fijxu)
      • chore: update Crystal to 1.20.0 in OCI (#5692, by @Fijxu)
      • player: Use correct time parameter for YouTube embed redirects (#5660, by @radmorecameron)
      • chore: lint api/v1/channels.cr (#5693, by @Fijxu)
      • Encapsulate helpers constants and functions inside it's own Helpers module (#5639, by @Fijxu)
      • Encapsulate translation constants and functions inside it's own I18n module (#5637, by @Fijxu)
      • Bump crystal-lang/install-crystal from 1.9.1 to 1.9.2 (#5686, by @dependabot[bot])
      • Playlists: fix parsing error when some videos are paid for in a course (#5207, by @ChunkyProgrammer)
      • Bump docker/login-action from 3 to 4 (#5661, by @dependabot[bot])
      • Bump docker/build-push-action from 6 to 7 (#5662, by @dependabot[bot])
      • Bump docker/metadata-action from 5 to 6 (#5663, by @dependabot[bot])
      • Bump docker/setup-buildx-action from 3 to 4 (#5664, by @dependabot[bot])
      • Remove noreferrer since youtube now requires referrers on embeds (#5642, by @ashleyirispuppy143)
      • Remove trailing whitespaces from codebase (#5634, by @Fijxu)
      • Add title listen button time updates (#5625, by @JeroenBoersma)
      • Remove sort by rating and date in video search filters (#5629, by @Fijxu)
    5. πŸ”— r/reverseengineering I Reverse Engineered An Undocumented Laptop's Embedded Controller rss
    6. πŸ”— r/reverseengineering I reverse engineered DeepSeek Chat into a free OpenAI compatible API (V4 & R1 models, no API key, no billing) rss
    7. πŸ”— HexRaysSA/plugin-repository commits sync plugin-repository.json rss
      sync plugin-repository.json
      
      No plugin changes detected
      
    8. πŸ”— HexRaysSA/plugin-repository commits sync repo: +1 release rss
      sync repo: +1 release
      
      ## New releases
      - [ida-settings-editor](https://github.com/williballenthin/ida-settings): 1.2.1
      
    9. πŸ”— r/reverseengineering GitHub - vichhka-git/renef-skills: Agent Skill (Claude Code + OpenCode) for operating renef.io β€” Android ARM64 dynamic instrumentation: hook native/Java, patch memory, trace syscalls, bypass SSL pinning/root detection; port Frida & GameGuardian scripts to renef Lua. rss
  9. June 26, 2026
    1. πŸ”— IDA Plugin Updates IDA Plugin Updates on 2026-06-26 rss

      IDA Plugin Updates on 2026-06-26

      New Releases:

      Activity:

      • ida-settings
        • e4f483c1: Merge pull request #25 from williballenthin/add-idc-show-function
        • f674ad43: v3.5.1
        • 03429519: v3.5.0
        • 14ab204d: fix: resolve remaining ruff lint warnings
        • e250c145: fix: ruff formatting
        • 50156100: plugin: rename IDC function to ida_settings_show_plugin_settings
        • 96edbffd: plugin: add ida_settings_show IDC function for cross-plugin integration
    2. πŸ”— backnotprop/plannotator v0.21.2 release

      Follow @plannotator on X for updates

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


      What's New in v0.21.2

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

      Custom Reviews as Agent Skills

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

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

      PR #955, by @backnotprop. Requested by @gwynnnplaine in #897.

      Cursor and OpenCode Review Engines

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

      PR #959, by @backnotprop.

      Deleted Review Annotations Stay Deleted

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

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

      Codex Ask AI Outside Git Repos

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

      PR #965, by @ericclemmons.

      Codex Desktop Review URL Surfacing

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

      PR #966, by @ericclemmons.

      Additional Changes

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

      Install / Update

      macOS / Linux:

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

      Windows:

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

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

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

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

      OpenCode: Clear cache and restart:

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

      Then in opencode.json:

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

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension
      

      Droid: Install via the plugin marketplace:

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

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

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

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

      kiro-cli chat --agent plannotator
      

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


      What's Changed

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

      New Contributors

      Contributors

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

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

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

    3. πŸ”— r/reverseengineering Im Trying To Reverse GTAIV And Including Scripts, Here Is My Progress rss
    4. πŸ”— r/reverseengineering Project IGI (1999) reverse engineering - partial docs, honest about gaps rss
    5. πŸ”— Anton Zhiyanov Solod v0.2: Networking, new targets, friendlier interop rss

      Solod (So) is a system-level language with Go syntax, zero runtime, and a familiar standard library. It's designed for two main audiences:

      • Go developers who want low-level control and zero-cost C interop without having to learn Zig or Odin.
      • C developers who like Go's style.

      The previous version (v0.1) focused on porting core Go stdlib packages and providing convenient C interop. At the end of that post, I said the next release would focus on networking, concurrency, or both. Now, networking is here β€” the v0.2 release I'm sharing today includes support for TCP, UDP, and Unix domain sockets. Concurrency is still planned for the future, so for now, servers handle one connection at a time.

      This release also lets you compile So to more targets, like 32-bit platforms, WebAssembly, and bare metal. And C interop even smoother!

      Networking β€’ TCP server β€’ TCP client β€’ Deadlines β€’ IP addresses β€’ Targets β€’ Interop β€’ Stdlib β€’ Wrapping up

      Networking

      The main feature in v0.2 is the net package. It's a simplified version of Go's net package which supports the three most commonly used transports:

      • TCP (networks tcp, tcp4, tcp6) via ResolveTCPAddr, DialTCP, and ListenTCP, with the TCPConn and TCPListener types.
      • UDP (networks udp, udp4, udp6) via ResolveUDPAddr, DialUDP (a connected socket), and ListenUDP (an unconnected socket with ReadFrom/WriteTo).
      • Unix domain sockets (unix for streams, unixgram for datagrams) via ResolveUnixAddr, DialUnix, ListenUnix, and ListenUnixgram.

      The API mirrors Go closely, so most of it will feel familiar. The big difference is that So has no goroutines, so there's no concurrent server support β€” you accept and serve connections sequentially. More on that in a moment.

      TCP server

      Let's build a classic: an echo server that accepts a connection, reads a message, and sends it back.

      package main
      
      import "solod.dev/so/net"
      
      func main() {
          // Resolve the local address to listen on.
          laddr, err := net.ResolveTCPAddr("tcp", "127.0.0.1:8080")
          if err != nil {
              panic(err)
          }
      
          // Start listening on the local address.
          ln, err := net.ListenTCP("tcp", &laddr)
          if err != nil {
              panic(err)
          }
          defer ln.Close()
          println("listening on", "127.0.0.1:8080")
      
          // Accept connections and serve them in a loop.
          for {
              conn, err := ln.Accept()
              if err != nil {
                  panic(err)
              }
              serve(&conn)
          }
      }
      
      // serve reads one message from the connection, echoes it back,
      // and closes the connection.
      func serve(conn *net.TCPConn) {
          defer conn.Close()
      
          var buf [256]byte
          n, err := conn.Read(buf[:])
          if err != nil {
              return
          }
          conn.Write(buf[:n])
      }
      
      
      
      listening on 127.0.0.1:8080
      

      If you've written a TCP server in Go, this should look familiar β€” ListenTCP, an Accept loop, and Read/Write on the connection. The only thing missing is a go serve(conn): without goroutines, each connection is handled to completion before moving on to the next Accept.

      TCP client

      The client starts the connection using DialTCP, then uses Write to send a request and Read to get the reply:

      package main
      
      import "solod.dev/so/net"
      
      func main() {
          // Resolve the server address.
          raddr, err := net.ResolveTCPAddr("tcp", "127.0.0.1:8080")
          if err != nil {
              panic(err)
          }
      
          // A nil laddr lets the system choose the local address.
          conn, err := net.DialTCP("tcp", nil, &raddr)
          if err != nil {
              panic(err)
          }
          defer conn.Close()
      
          // Send a request and read the reply.
          conn.Write([]byte("hello"))
      
          var buf [256]byte
          n, err := conn.Read(buf[:])
          if err != nil {
              panic(err)
          }
          println(string(buf[:n]))
      }
      
      
      
      hello
      

      UDP and Unix domain sockets work in a similar way. For UDP, an unconnected ListenUDP socket uses ReadFrom to get data and the sender's address, and WriteTo to send a reply. For Unix sockets, there are ListenUnix (stream) and ListenUnixgram (datagram).

      Deadlines

      By default, Accept, Read, and Write are blocking. In Go, you'd typically use goroutines and contexts to prevent getting stuck forever. Since that's not available in So (yet), every connection and listener supports deadlines instead:

      // Give the client 5 seconds to send something.
      conn.SetReadDeadline(time.Now().Add(5 * time.Second))
      
      n, err := conn.Read(buf[:])
      if err == net.ErrTimeout {
          // The client went quiet; drop the connection.
          return
      }
      

      SetDeadline, SetReadDeadline, and SetWriteDeadline are available on TCPConn, UDPConn, UnixConn, and listener types. When the deadline passes, any pending call fails with net.ErrTimeout. If you don't set a deadline, a blocked call will wait forever. This isn't concurrency, but it's enough to keep a single-threaded server responsive.

      IP addresses

      Along with net, v0.2 ports Go's net/netip package, which provides small, allocation-free value types for IP addresses. Addr represents an IP address, AddrPort combines an IP address with a port, and Prefix is an IP with a prefix length (a CIDR block):

      addr, err := netip.ParseAddr("192.168.1.10")
      if err != nil {
          panic(err)
      }
      println(addr.Is4())            // true
      
      ap := netip.AddrPortFrom(addr, 8080)
      println(ap.Port())             // 8080
      
      prefix := netip.MustParsePrefix("192.168.1.0/24")
      println(prefix.Contains(addr)) // true
      

      These are simple value types that don't use any heap allocation, which fits well with So's explicit-memory approach. The net package also provides SplitHostPort and JoinHostPort functions to help you work with host:port strings.

      New targets

      Solod compiles to plain C, which (in theory) means it can target anything a C compiler can. Because of this, v0.2 adds new targets:

      • 32-bit platforms. The compiler and stdlib now work correctly on 32-bit platforms, where int and pointers are narrower.
      • WebAssembly (WASI). You can compile a So program to wasm32-wasi and run it under any WASI runtime.
      • Freestanding mode. So programs can run on bare-metal systems without any C standard library. No libc means no malloc, but you can use mem.Arena instead.

      Here's the complete toolchain you need to build a freestanding wasm32 binary using zig cc:

      export CC="zig cc"
      export CFLAGS="-Oz --target=wasm32-freestanding -nostdlib -Wl,--no-entry -Wl,--export=main"
      so build -o main.wasm .
      

      A large part of the standard library (bytes, strings, strconv, slices, maps, math, encoding/binary, and more) works just fine in freestanding mode. For more details, check out the freestanding guide.

      Friendlier interop

      A bunch of smaller changes make Solod nicer to write.

      Three new directives for low-level work, all documented in the interop guide:

      //so:volatile
      var counter int       // emits a C volatile
      
      //so:thread_local
      var perThread int     // emits C11 _Thread_local
      
      //so:attr packed
      type header struct {  // emits __attribute__((packed))
          version byte
          length  int
      }
      

      so:attr works with variables, constants, types, and functions. You can use it on multiple lines, and the attributes will stack. For example, //so:attr aligned(16) will combine with //so:attr packed.

      Type aliases. So now supports Go-style type aliases:

      type Byte = uint8
      

      Numeric C types. The so/c package now includes named types for C's numeric types β€” Int, UInt, Long, Short, UChar, LongLong, and others. When you declare an extern function, you can use the actual C types in its signature instead of trying to guess the correct fixed-width Go type for your platform.

      Third-party packages. You can now add external So packages using go install or by vendoring, and you can organize your own code into multiple modules. So doesn't have a real package ecosystem yet, but it's a good start.

      Better diagnostics. By default, panic messages report the C file and line. Pass --track-source to report the original So source location instead:

      so run --track-source .
      

      There's also an optional --check-nil flag that adds nil-pointer checks when accessing struct fields and calling interface methods. This way, if there's a bad dereference, the program will panic cleanly instead of causing a segmentation fault. Both options are off by default to keep the generated code more readable.

      More stdlib

      Beyond net and net/netip, v0.2 adds a few more packages:

      • encoding/hex β€” hex encoding and decoding, including Dump for hexdump-style output.
      • uuid β€” generating and parsing UUIDs (v4 and v7), with random components from a cryptographically secure source.

      And a small but handy update to memory management: mem.Arena.Free now reclaims the last allocation if you give it the matching pointer. It's a minor optimization, but it means a quick alloc/free pair on an arena no longer wastes space.

      Stdlib documentation

      Wrapping up

      With v0.2, Solod has evolved from just "command-line tools and C glue" into something you can actually use on a network β€” like a TCP or UDP server, a small protocol client, or a Unix-socket daemon. The new targets (32-bit, WASM, freestanding) mean the same code can now run in more places, even down to bare metal.

      The big thing that's still missing is concurrency. A server that handles requests one at a time works for some tasks, but a real network service needs to manage many connections at once. That's the obvious goal for v0.3 β€” adding some kind of concurrency, along with the stdlib packages that support it.

      If you're interested, take a look at So's readme β€” it has everything you need to get started. Or try So online without installing anything.

    6. πŸ”— MetaBrainz Welcome Summer of Code 2026 contributors! rss

      We are excited to announce the 7 GSOC participants working with us this summer on MetaBrainz projects!
      Our apologies for not publishing this sooner, in this complicated first part of the year we simply forgot the announcement, but rest assured the work is progressing on all projects.

      As always, the selection process was incredibly tough. We received a great batch of proposals and had a limited number of slots.
      We want to sincerely thank everyone who took the time to meet our community and submit a proposal with us!

      The whole list of selected proposals can be found on the GSOC website but here is a TL;DR breakdown:

      ListenBrainz proposals:

      Integrate MusicBrainz events into ListenBrainz

      (Shirsak)

      MusicBrainz has data about past and upcoming concerts that ListenBrainz users can't see yet. This project will bring live music events directly into ListenBrainz, allowing you to discover shows tailored to your favorite artists.

      Compose Multiplatform Migration of ListenBrainz-Android

      (Nirvan)

      Currently, ListenBrainz has a native Android app but no iOS version. This project will migrate the app to a single, shared codebase using Kotlin Multiplatform. This means future features and bug fixes will launch on both Android and iOS at the same time.

      Playlists Sorting and Organization

      (Yateen)

      Giving ListenBrainz playlists a massive user-experience upgrade. Users will soon be able to search through playlists, organize them using custom tags, sort tracks (by artist, title, or date added), and convert their MusicBrainz collections straight into playlists.

      MusicBrainz proposals:

      Modernize search storage format for the MusicBrainz database

      (Junaid)

      Cleaning up the under-the-hood engine that powers MusicBrainz search (Solr). By upgrading internal configurations and removing data redundancy, this project will optimize performance and make searching for music faster and more efficient.

      GraphQL Server as a Musicbrainz API Alternative

      (Sreehari)

      Building a fast, modern alternative way for external developers to request MusicBrainz data. This makes it significantly easier and more efficient for third-party developers to build apps using our database.

      BookBrainz proposals:

      Set Up BookBrainz for Internationalization

      (Garv)

      Breaking down language barriers! BookBrainz is currently English-only. This project lays the technical groundwork to support multiple languages and sets up a BookBrainz project on translations.metabrainz.org where volunteer translators can start translating the site immediately.

      Development of a new Calibre plugin for BookBrainz

      (Waqib)

      Connecting BookBrainz with Calibre (the popular e-book management software). This plugin will allow Calibre users to automatically pull book metadata and collections directly from BookBrainz to organize their personal digital libraries.

      What if you’re not in GSoC 2026?

      Reading this and feeling inspired for contributing to the code still? Volunteer contributors are very welcome all year round even though we might have slightly less time available to help you during the summer. It is also putting you in an ideal situation for applying to next year’s GSoC. You can find some tips for applying to GSoC with us in one of our previous posts. When you are ready, join us on the MetaBrainz Matrix Channel and showcase your initiative and your skills!

    7. πŸ”— r/reverseengineering Reversed the game I grew up on, COD: BO2 Zombies and made a game cheat for it rss
    8. πŸ”— New Music Releases Muse - The Wow! Signal rss

      Muse - a new release is available:

      • 2026-06-26: The Wow! Signal (Album)

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

      Visit muspy for more information.

    9. πŸ”— New Music Releases Chromeo - A Little Lucky (remixes) rss

      Chromeo - a new release is available:

      • 2026-06-26: A Little Lucky (remixes) (EP)

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

      Visit muspy for more information.

  10. June 25, 2026
    1. πŸ”— IDA Plugin Updates IDA Plugin Updates on 2026-06-25 rss

      IDA Plugin Updates on 2026-06-25

      New Releases:

      Activity:

      • ida-ios-helper
        • 449815b9: Merge pull request #21 from gilboz/bugfix/objc-sugar-line-merging
      • ida_ifl
        • 2dbdb564: Merge pull request #21 from Jah-yee/fix/refered-typo
      • plugin-ida
        • 277b3cb4: chore: Release v3.0.2 (#18)
        • 6548e165: fix: Pick PySide6 directly on IDA 9.2+ to avoid PyQt5 shim (#17)
        • a5f5c2cd: chore(deps): Bump actions/checkout from 6.0.3 to 7.0.0 (#16)
    2. πŸ”— r/reverseengineering Luma: A new workspace for Frida rss
    3. πŸ”— HexRaysSA/plugin-repository commits sync repo: +2 releases rss
      sync repo: +2 releases
      
      ## New releases
      - [hrtng](https://github.com/kasperskylab/hrtng): 3.9.105
      - [threatray](https://github.com/threatray/plugin-ida): 3.0.2
      
    4. πŸ”— @HexRaysSA@infosec.exchange IDA 9.4 teasers continue with two new navigation features: mastodon

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

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

    5. πŸ”— MetaBrainz Upcoming changes to user accounts and authentication rss

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

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

      New MetaBrainz login page

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

      Changes for users

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

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

      Changes for developers

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

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

      ⚠ Note on

      DIGEST Auth TOKENS

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

      Timeline

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

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

    6. πŸ”— r/reverseengineering VAXD now with support for ARM rss
    7. πŸ”— Andrew Healey's Blog A Tiny Compiler for Data-Parallel Kernels rss

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

    8. πŸ”— Rust Blog The many journeys of learning Rust rss

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

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

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

      Many paths to needing Rust

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

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

      Rust learning resources

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

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

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

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

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

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

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

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

      Beginner stumblings and unlearning habits

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

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

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

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

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

      Learning to work with the borrow checker

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

      The compiler as teacher

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

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

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

      Learning by doing

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

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

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

      Letting go of "clone guilt"

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

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

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

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

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

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

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

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

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

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

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

      Teaching Rust in academia

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

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

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

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

      Learning using LLMs

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

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

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

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

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

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

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

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

      Organizational considerations for Rust learners

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

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

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

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

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

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

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

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

      Silent attrition

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

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

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

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

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

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

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

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

      Feedback on near-bounces from survey

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

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

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

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

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

      Need more focused work on silent attritrion

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

      Conclusions

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

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

      What seems worth trying

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

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

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

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

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

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

      What we still don't know

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

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

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

    9. πŸ”— Console.dev newsletter Go Micro rss

      Description: Agent harness & service framework.

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

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

    10. πŸ”— Console.dev newsletter Hasp rss

      Description: Local secret broker.

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

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

    11. πŸ”— New Music Releases Bring Me the Horizon - Dehumanized rss

      Bring Me the Horizon - a new release is available:

      • 2026-06-25: Dehumanized (Single)

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

      Visit muspy for more information.