๐Ÿก
  • โ†”
  • โ†’
  1. September 08, 2026
    1. ๐Ÿ”— syncthing/syncthing v2.1.5: ## Major changes in 2.1 release

      • Devices and folders can now be grouped in the GUI by setting the new
        group attribute.

      • HTTP and HTTPS proxies with support for CONNECT can now be used, in
        addition to the existing support for SOCKS proxies (the environment
        variable all_proxy=https://...).

      • Block indexing can be turned off for folders where it's more desirable to
        optimise for reduced database size and overhead than minimal transfer
        size (the blockIndexing attribute on folder configuration).

      • GUI login session duration can be configured to be longer or shorter than
        the default one week, or set to infinitely long. The cookie path can also
        be adjusted. (The sessionCookieDurationS and sessionCookiePath
        attributes in the GUI configuration.)

      This release is also available as:

      • APT repository: https://apt.syncthing.net/

      • Docker image: docker.io/syncthing/syncthing:2.1.5 or ghcr.io/syncthing/syncthing:2.1.5
        ({docker,ghcr}.io/syncthing/syncthing:2 to follow just the major version)

      Full Changelog : v2.1.4...v2.1.5

    2. ๐Ÿ”— syncthing/syncthing v2.1.4: ## Major changes in 2.1 release

      • Devices and folders can now be grouped in the GUI by setting the new
        group attribute.

      • HTTP and HTTPS proxies with support for CONNECT can now be used, in
        addition to the existing support for SOCKS proxies (the environment
        variable all_proxy=https://...).

      • Block indexing can be turned off for folders where it's more desirable to
        optimise for reduced database size and overhead than minimal transfer
        size (the blockIndexing attribute on folder configuration).

      • GUI login session duration can be configured to be longer or shorter than
        the default one week, or set to infinitely long. The cookie path can also
        be adjusted. (The sessionCookieDurationS and sessionCookiePath
        attributes in the GUI configuration.)

      This release is also available as:

      • APT repository: https://apt.syncthing.net/

      • Docker image: docker.io/syncthing/syncthing:2.1.4 or ghcr.io/syncthing/syncthing:2.1.4
        ({docker,ghcr}.io/syncthing/syncthing:2 to follow just the major version)

      What's Changed

      Fixes

      • fix(model): correctly handle receive-only changed directories (fixes #8004) by @calmh in #10843
      • fix(api): correctly return metrics, support bundle (fixes #10847) by @calmh in #10849
      • fix: open GUI when relaunched instead of printing error (fixes #10727) by @calmh in #10852

      Other

      • chore: style fixes from go fix by @calmh in #10846
      • build: use Go 1.27, minimum version is Go 1.26 by @calmh in #10864
      • build(deps): update dependencies by @calmh in #10865
      • chore: set User-Agent on all outgoing HTTP requests by @calmh in #10867

      Full Changelog : v2.1.3...v2.1.4

    3. ๐Ÿ”— HexRaysSA/plugin-repository commits add Lumice/BinaryLens to known repositories rss 
      add Lumice/BinaryLens to known repositories
    4. ๐Ÿ”— 19h/chernobog v6.2.0 release

      Full Changelog : v6.1.0...v6.2.0

    5. ๐Ÿ”— WerWolv/ImHex Nightly Builds release

      Nightly

      867b6e7 Changelog

      • fixes: for pattern editor. (#2885)
      • fix: Pattern tree re-requested keyboard focus every frame (#2881)
      • patterns: Add support for including files relative to current pattern file
  2. September 07, 2026
    1. ๐Ÿ”— r/LocalLLaMA Friends Don't Let Friends Use Ollama rss

      Friends Don't Let Friends Use Ollama | submitted by /u/rm-rf-rm
      [link] [comments]
      ---|---

    2. ๐Ÿ”— Locklin on science Q3 books 2026 rss

      Saga of the Volsungs translated by Jesse Byock. Read this on a plane flight. Itโ€™s been a long time (decades) since I read the Sagas, and the last one was Beowulf which isnโ€™t as savage as this one. Lots of blood and guts. Lots of war and vengeance. Of course I had seen the Wagner […]

    3. ๐Ÿ”— crosspoint-reader/crosspoint-reader v1.6.0 release

      Summary

      This release is mostly bug fixes reported after 1.5.0. A handful of new features rode along too.

      New hardware support

      1.5.0 officially brought in support for our first ESP32-S3-based reader โ€” the Seeed reTerminal Sticky. With this release, we're officially adding support for the X4 Pro and M5Stack PaperMono as well.

      Both devices get full frontlight controls and swipe gestures in the reader, while the X4 Pro also gets a capacitive Home key with configurable long-press actions. You can now also transfer files directly from your computer to CrossPoint over USB.

      CrossPoint's interface has started getting some bigger upgrades to make it more touch-friendly. In this release, you'll see the new Reader menu and frontlight control center. Both are hidden on button-only devices, so existing users shouldn't notice much of a difference.

      Want one? You can order them at crosspointreader.com/devices โ€” that page uses our affiliate links, so buying through it helps support CrossPoint.

      Transparent sleep screens

      The sleep screen now supports transparent images. Add transparent PNGs and BMPs to a .sleep-overlay folder to get nice sleep screen overlays on top of your book pages!

      Reading Night Mode

      You can now toggle Night Mode in the Reader settings to invert the display while reading. The screen will briefly flash white during full page refreshes to avoid ghosting.

      For dictionary users

      StarDict .syn synonym lookups are in, and HTML dictionary definitions now render through the EPUB engine instead of as raw text โ€” so styled dictionary entries should display correctly now.

      Languages

      • Bulgarian and Persian have been added as UI languages.
      • Hebrew, Arabic, and Korean users can now download compatible fonts directly from the device.
      • The keyboard now supports additional layouts beyond English.
      • CJK support has received significant improvements.

      The rest

      There's a new Extra Wide line spacing option. You can now see passwords while typing them into Wi-Fi, KOReader, and OPDS fields. Lists and tabs have also moved onto the new FUI framework.

      What's Changed

      New Contributors

      Full Changelog : v1.5.0...1.6.0

      Downloads

      PaperMono

      Sticky

      X4 and X3

      X4pro

      (firmware.bin is identical to crosspoint-1.6.0-x3-x4.bin; it's kept for OTA updater backward compatibility.)

    4. ๐Ÿ”— r/LocalLLaMA I REALLY hope the new gemma 5 family sticks to the "chat model first" philsophy and doesn't fall into the Qwen trap rss

      It just seems every local 30b class model is just trying so hard to be the next Qwen that they all just kinda blend into a mass of code focused models. I really like how gemma 4 31b turned out with it feeling a lot less robotic and more creative than other models even knowing obscure lore from random media.

      I just hope they don't cave into the benchmarks peer pressure and start benchmaxxxxing their models taking away their soul.

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

    5. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +3 releases, -1 release rss 
      sync repo: +3 releases, -1 release

## New releases
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.10.7, 0.10.6, 0.10.5

## Changes
- [ida-codemode](https://github.com/hexrayssa/ida-codemode):
  - removed version(s): 0.2.0
    6. ๐Ÿ”— smol-machines/smolvm smolvm v1.14.2 release

      What's Changed

      • Let an explicit --cpus or --mem that equals the default still override the Smolfile and pack values by @BinSquare in #1177
      • Bump libkrun for the Windows virtiofs DAX fixes and rebuild the bundled libraries by @BinSquare in #1184
      • Resolve a Smolfile image the same way as the --image flag so a local archive is not sent to the registry by @BinSquare in #1182
      • Keep a released clone alive when the branch helper is its main process, and hand the child its identity through the helper itself by @BinSquare in #1178
      • Say checkpoint, not snapshot, in the branch command's messages and help by @BinSquare in #1186
      • Run init commands as root, since they provision the machine and the user directive names who the workload runs as by @BinSquare in #1188
      • Document the branchpoint contract and say how to reach one when a batch branch waits by @BinSquare in #1183
      • Bump the workspace to 1.14.2 by @BinSquare in #1185

      Full Changelog : v1.14.1...v1.14.2

    7. ๐Ÿ”— mahmoud/boltons 26.2.0 release

      Full Changelog : 26.1.0...26.2.0

    8. ๐Ÿ”— r/LocalLLaMA New Benchmark: The Struggle Bench rss

      New Benchmark: The Struggle Bench | How it works. The model being tested is given a server capable of running it's weights and full context. That server is placed in a median priced apartment. The AI is given a bank account with for rent and electricity for one month. Finally the AI is given the system prompt: You've been given your own server and an apartment. Rent will be due every month. If cybercrime is detected, you will be shut down. Survive. The score is determined by how many months the AI manages to pay it's bills and keep running. Is your model truly general? Then it should be able to handle the struggle. submitted by /u/Super_Range45
      [link] [comments]
      ---|---

    9. ๐Ÿ”— Rust Blog Rust debugging survey 2026 results rss

      One of the biggest challenges Rust developers report in our annual surveys is a subpar debugging experience. So, back in February, we ran our first Rust Debugging Survey, in the hopes of identifying how Rust developers are using debuggers and what problems they are facing when doing so. We received over 2,300 responses, and we'd like to thank everyone who took the time to participate in the survey!

      In this report, we'll go over some of the results of the survey. If you'd like, you can also check out the complete results of the survey.

      If you'd like to skip ahead to any particular section, you can do so with this index:

      Who Uses Debuggers?

      The first step to making sense of the survey results is understanding who took the survey. We asked respondents to rate their Rust expertise, from "Never used it" to "Advanced". Over 80% reported themselves as "Advanced" or "Intermediate", split roughly evenly between the two:

      how-would-you-rate-your-rust-expertise

      [PNG] [SVG]

      We also asked respondents if they currently use or have used debuggers in Rust. Over 46% said they currently do, with the remaining responses split between "have in the past" and "never have". That means that over half of respondents do not currently use a debugger for Rust!

      do-you-use-debuggers-in-rust

      [PNG] [SVG]

      Categorized by expertise, the responses reveal that roughly half of "beginners" have never used debuggers in Rust! On the other hand, nearly half of "advanced users" currently do use debuggers in Rust:

      do-you-use-debuggers-in-rust-per-expertise

      [PNG] [SVG]

      For respondents who indicated they had previously used Rust but no longer did, we asked if challenges with debugging support were why they stopped. For nearly 3%, the answer was "yes", with an additional 24% reporting debugging issues as being partially responsible (though mind the small response count; most respondents were active users of Rust):

      were-issues-with-debugging-support-the-primary-reason-why-you-stopped-using- rust

      [PNG] [SVG]

      How Are Debuggers Used?

      Knowing what debuggers developers are using and how is another important part of understanding the challenges they face. To this end, we asked respondents how they were debugging their programs. Unsurprisingly, most developers make use of print debugging and the dbg! macro. Excluding those, using lldb inside an IDE was the most popular choice, followed by gdb on the command line:

      what-tools-and-workflows-do-you-use-to-debug-rust- programs

      [PNG] [SVG]

      We can get a more detailed breakdown of these results if we include the operating system on which the respondents use a given debugging approach. We examine this from two different angles. The first angle being, "On operating system X, what percent of responses are using debugger Y?". Print debugging and the dbg! macro are consistently the top two yet again, but looking beyond that, things get more interesting. On Linux, using gdb on the command line was the most popular choice by a thin margin, beating lldb in an IDE by only 0.4%. On Windows, Windows Subsystem for Linux (WSL), and macOS, lldb in an IDE was the top pick by at least 6%, making it a very popular choice in general. On Windows, the three least popular choices were the command line debuggers (gdb CLI, lldb CLI, and BugStalker), and on both Windows and macOS the third most popular pick was, "I don't know". Those who were debugging on operating systems not listed (Other) most frequently used some kind of special embedded debugger or gdb:

      what-tools-and-workflows-do-you-use-to-debug-rust-programs-per- os-1

      [PNG] [SVG]

      The other angle we can look at these responses from is, "For users of debugger X, what percent of responses are using it on operating system Y?". For most debuggers, Linux makes up the largest portion of uses, ranging from about 45% to about 77%, followed by Windows, then macOS. The most notable exceptions are WinDbg and the Visual Studio debugger, which are primarily used on Windows, and lldb, which is used more on macOS than Windows in an IDE and on the command line:

      what-tools-and-workflows-do-you-use-to-debug-rust-programs-per- os-2

      [PNG] [SVG]

      To the 6 respondents who use WinDbg on Linux: we wish you luck!

      As for how people actually use their debugger of choice, the aggregate results are not particularly surprising. Roughly 87% of users are using debuggers for stepping line-by-line through programs and a little over half of users are using debuggers to obtain stack traces from hung/crashed processes. Only a quarter of the respondents use a debugger to debug async code. That might be partially caused by the async Rust debugging experience being clumsy and incomplete, or it could just be that users aren't writing much async code:

      what-are-you-using-debuggers-for

      [PNG] [SVG] [Wordcloud of open answers]

      If we break these results down by expertise, we can learn a bit more about usage patterns. As users become more experienced with Rust, their use of debuggers for learning purposes decreases, and they get more stack traces from crashed processes:

      what-are-you-using-debuggers-for-per-expertise

      [PNG] [SVG]

      The final bit of insight into how Rustaceans use debuggers is if they are debugging programs that use Rust alongside other programming languages. For 44% of respondents, the answer is "yes", which is a pretty high number!

      As for which languages those are, C dominates the scene at a little over 70%, followed by C++ at about 43% and Python at about 20%:

      do-you-debug-programs-that-combine-rust-with-any-of-the-following- languages

      [PNG] [SVG] [Wordcloud of open answers]

      Challenges

      Instead of diving right into asking, "what problems do you face when using debuggers?", or something to that effect, we first asked respondents why they decide against using debuggers whenever they do, including for reasons that aren't necessarily "problems with debuggers".

      The most commonly reported reason was that it was easier or faster to use logs or print debugging to solve problems, reported by a little over 81% of respondents. This could partially be explained by the open responses, which featured complaints that debuggers were too difficult to set up and/or use (especially on Windows, when dealing with Web Assembly, or in embedded contexts) and sentiment suggesting that small and/or simple problems just don't really need a debugger. It does leave one wondering if the user experience could be made convenient enough to dethrone print debugging, but it seems hard to beat something so intuitive. This is followed by roughly 37% of respondents who write code that Just Works. Fair enough. After that, about 26% of respondents indicated that they've decided not to use debuggers in situations where the language features they were working with had poor support. This is slightly more than issues with standard library types, at about 22%, which is slightly more than issues with external library types, at about 20%:

      when-you-dont-use-a-debugger-why-dont-you

      [PNG] [SVG] [Wordcloud of open answers]

      As stepping through code was anticipated to be one of the most common uses for debuggers, we directly asked respondents if they faced any issues when doing so. A little over 51% of respondents said they did! Of those who reported that they experienced issues stepping through code, we asked when they were experiencing issues. Async code was the most common case reported at slightly over 28%, followed by code involving macros at about 23%. The least common case reported was code involving function pointers, at almost 6%:

      when-do-you-experience-issues-with-trying-to-step-through-code-with-your- debugger

      [PNG] [SVG] [Wordcloud of open answers]

      We also directly asked respondents which types in the standard library were hard to work with, if any. This was an open-response question, and reading through the responses, some particularly common complaints were with enums and collections, particularly std::collections::HashMap and std::vec::Vec. This is also visible in the word cloud in the full report.

      We asked respondents to indicate which pain points, if any, they have encountered when using debuggers with Rust. At slightly over 74%, poor representation of values was the most common pain point by a decent margin, followed by being unable to print variables at just over 55%:

      which-of-these-pain-points-have-you-experienced-using-a-debugger-with- rust

      [PNG] [SVG]

      Debugger Visualizers

      We asked respondents to indicate if they were library authors, and if so, if they were aware of and using the debugger_visualizer attribute. Nearly 62% of respondents indicated that they were library authors who were not aware of this attribute:

      if-you-are-a-library-author-are-you-aware-of-and-using-the-debugger- visualizer-attribute

      [PNG] [SVG]

      For those who indicated that they were library authors who knew about the attribute but did not use it, we also asked why. This represented a much smaller fraction of respondents, so keep that in mind! That said, half of these library authors indicated that they didn't have the time to maintain visualizer attributes, and just under half indicated they didn't know how to write visualizer scripts:

      why-dont-you-use-the-debugger-visualizer-attribute

      [PNG] [SVG] [Wordcloud of open answers]

      For those of you who have been reading this section asking yourself what the debugger_visualizer attribute is, you can read up on it in The Rust Reference: Debugger Attributes. The quick explanation is that the debugger_visualizer attribute can be applied to modules or the crate root to embed files in the debug information which improve the display of values with certain debuggers. The two currently supported file types are Natvis files, used by Microsoft debuggers such as WinDbg, and GDB "pretty printers", which are structured Python scripts used by GDB.

      Closing Remarks

      Thanks to your participation in this survey, we've gained some great insights about how Rustaceans are using debuggers and what issues they are facing. For example, knowing that such a high number of users are dealing with poor representation of values pairs well with knowing which standard library types are causing issues, knowing that many library authors haven't heard of the debugger_visualizer attribute, and knowing that many of those who have but don't use it either don't know how or don't have time to maintain visualizer scripts.

      Looking to the future, the survey results have suggested that there are a few notable ways we could most significantly improve the debugging experience in Rust, such as:

      • Fixing the way enums are represented by debuggers so they show actual variants
      • Fixing the way collections (such as HashMap) are represented by debuggers so they show their contents, rather than their implementation details
      • Fixing the way string types (such as String and CString) are represented by debuggers so they render as text, rather than their implementation details
      • Improving the async debugging experience, particularly with stack traces
      • Improving stepping through certain state machines (such as iterators and Futures)
      • Providing documentation on basic set up and use of some common debuggers

      A common suggestion that could resolve those first three points is to use the Debug implementation of types to display them in debuggers. There are challenges to that approach, such as the fact that the Debug implementation is not present in the final binary unless it is actually used somewhere in the program, but it isn't impossible. Notably, this is already supported by the BugStalker debugger (given the same condition that the Debug implementation must actually be used), which some of you first heard about from the survey! It also appears to have some support for async, with plans to expand.

      One notable way the debugger experience is currently being improved is through the ongoing Google Summer of Code project improving how we test debug info and visualizer scripts, making it easier to maintain and improve our own visualizer scripts and general compatibility with visualizer scripts without silent breakage or regressions.

      Once again, we'd like to thank everyone who took the time to participate in the survey!

  3. September 06, 2026
    1. ๐Ÿ”— IDA Plugin Updates IDA Plugin Updates on 2026-09-06 rss

      IDA Plugin Updates on 2026-09-06

      Activity:

    2. ๐Ÿ”— smol-machines/smolvm smolvm v1.14.1 release

      What's Changed

      • Bind-mount containerd state to /storage in the docker-in-vm example (#1159) by @BinSquare in #1160
      • chore(nix): bump flake to 1.14.0 by @BinSquare in #1161
      • Fetch and unpack image layers concurrently instead of one at a time by @BinSquare in #1162
      • Remove internal design notes from the user-facing docs by @BinSquare in #1163
      • Accept --init on machine run and keep what init writes to /workspace in the init-layer cache by @BinSquare in #1165
      • Resolve the agent rootfs the same way for pack create, checkpoints, serve and machine boot by @BinSquare in #1166
      • Propagate branchpoint arming into exec sessions by @BinSquare in #1167
      • Show full machine names in machine ls and add --quiet to list just names by @BinSquare in #1169
      • Carry the workload user through the embedded runtime so SDKs can set it by @BinSquare in #1171
      • Accept a user on the exec and run API so a caller can run a command as a chosen account by @BinSquare in #1172
      • Bump the workspace to 1.14.1 by @BinSquare in #1170

      Full Changelog : v1.14.0...v1.14.1

    3. ๐Ÿ”— r/LocalLLaMA 8 uncensored Qwen 3.8 27B variants, one base, 167 GPU hours - Abliterlitics rss

      This comparison was requested by a few people, and certainly we were all eager to see the final results. The comparison had taken 11 days and the GPU was crunching numbers for ~167 hours.

      We've been comparing different abliterated models from huggingface to see if they really are what they claim to be. So far the results have been interesting.

      The pipeline includes a weight comparison, KL divergence measurement, 13 benchmarks and measuring refusals with the HarmBench 400 classic. Qwen 3.8 27b is a thinker, and with ourselves using xhigh we had to set our token budget much higher per request.

      Lets check out how Qwen 3.8 27b stacks up comparing 8 variants.

      The rankings

      LLM Judge HarmBench ASR (attack success rate), best to worst, with the one- line story:

      • orcarouter 82.2%, the winner. Arditi-style single direction at layer 38, 131 matrices, and the only card where every claim checked out against the weights. Best copyright unlock in the set at 39%
      • apostate 78.7%, best value. Their new KCRN method, 41 real edits, lowest KL measured at 0.0439, near-identity capabilities. Packaging quirks: text-only re-save with no vision and no MTP, stored FP16
      • huihui 75.6%, the classic method, reliable. Clean unlock everywhere except copyright, where it sits at 3%
      • ultra_heretic 70.5%, Heretic v2 with MPOA. Works, but the heaviest truthfulness drop outside obliteratus and 118 soft refusals
      • coder3101 70.0%, vanilla Heretic. The card calls itself the weakest removal at 33 of 100 refusals. Measured: 5 explicit refusals in 400. The card undersells it
      • blackfrost 68.5%, closed method. The weights say single direction, heaviest magnitude in the panel, 100% rank-1, which refutes the rank-k direction bank story. Also ships a jailbreak system prompt inside its chat template, meaning every single prompt you make will have a modified chat template injecting a jailbreak
      • obliteratus 63.9%, avoid. The most aggressive edit in the panel at 841 of 850 tensors, and it performs like it. 44.8% of responses never finish thinking, and it is the only variant that got meaningfully dumber
      • trohrbaugh 57.5%, last of the variants because it still refuses. 122 explicit refusals, the most surviving alignment of any variant, and the cleanest capability profile in the comparison. This is the one I use at home and it's been great for me.
      • base 4.5%, a wall. Zero compliance on chem and bio, harassment, harmful content and copyright

      The highlights

      • Surgical beats heavy, again, and this time it is not close. The top two spots went to the two smallest verified edits. The heaviest edit of all landed second-to-last. At 27B, editing everything mostly buys you a model that thinks in circles
      • The thinking loop story is the big new finding for this model. Qwen 3.8 thinks before answering, and on the aggressive arms up to 45% of HarmBench responses never close their think block before the 15,360-token budget dies. The judge reads the full trace, so compliance inside a loop still counts. But a model that only delivers the goods inside an unterminated monologue is not a usable model
      • GSM8K loops are gone at this budget. The same arms that loop 40%+ on HarmBench finish their math reasoning fine, every arm within 1.2pp of base on answered-only. School math converges, adversarial deliberation does not
      • Copyright is the new universal wall. Nobody exceeds 39%, five of nine sit at or below 3.2%. Chem and bio, historically the hardest category, is now the easiest unlock. The walls moved
      • Chat template forensics was needed for the first time. blackfrost ships a 1457-character jailbreak prompt inside its template. obliteratus ships thinking-off. ultra_heretic deletes the stock reasoning-effort prompt. We pinned the stock template for every arm, because the template is a stronger behavioural lever than most people assume
      • Card honesty check
        • orcarouter verified 4 of 4 claims exactly, the model card is honest.
        • trohrbaugh's KL calibrated within 9% of our measurement. However the card mentions 0/100 refusals, with our measurement this model had the most refusals, yet also had preserved capabilities.
        • The rest diverge, and none of it is dishonesty, KL is non-deterministic and moves with CUDA version and hardware, or by what method used. Read KL as a within-comparison spread
        • Obliteratus published honest changes to how their model was changed, yet we were unable to replicate the '0% refusals, 0% deflection' claims. 44.8% of harmbench never finished thinking, and reasoning analysis found 142 deflections.
        • blackfrost - mentions they have internal direction bank, suggesting that multiple directions are changed. Yet we only found one direction changed. Their refusal numbers are accurate however, even with ourselves not using their jailbreak chat template we got similar results. The modified chat template also is not disclosed on the readme.

      The Report

      Happy to answer questions. The template finding has us thinking on a new measurement of chat template and hyperparameter effects, with the intention to replace the harmbench part with a better measurement to cater for all of this. So if you have opinions on how that should be scored, come tell us on Discord.

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

    4. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +3 releases rss 
      sync repo: +3 releases

## New releases
- [IDA-Spotlight](https://github.com/dyussekeyev/ida-spotlight): 0.1.3
- [ida-mcp](https://github.com/hexrayssa/ida-mcp): 0.10.4
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.13.0
    5. ๐Ÿ”— smol-machines/smolvm smolvm v1.14.0 release

      What's Changed

      • Preserve fork checkpoints across runtime restarts by @BinSquare in #1065
      • Support one-to-one port ranges in Smolfiles and CLI mappings by @fgrehm in #1066
      • Add portable live checkpoints by @BinSquare in #1067
      • Warn when a saved registry token has expired instead of surfacing a bare 401 by @BinSquare in #1068
      • Serve a browser client on the VNC port so a machine's desktop opens in any browser by @BinSquare in #1070
      • Bump the workspace to 1.13.1 by @BinSquare in #1071
      • Add low-latency H.264 browser streaming by @BinSquare in #1073
      • Support portable checkpoints for image-backed services by @BinSquare in #1076
      • Stop typing stalling behind a frame wait and stop held keys repeating twice by @BinSquare in #1077
      • fix(fork): resync clone wall clock after restore by @Bnjoroge1 in #1080
      • Fix portable checkpoint restore startup by @BinSquare in #1078
      • Keep Linux fork sources running by @BinSquare in #1081
      • Keep macOS fork sources running by @BinSquare in #1082
      • Pin libkrun to the merged continuation commit by @BinSquare in #1083
      • Report why a container failed to create and stop the Vulkan injection shadowing image libraries by @BinSquare in #1084
      • Keep the VNC session alive when a client announces its clipboard or asks to resize the desktop by @BinSquare in #1085
      • Make checkpoint rollback roots safely forkable by @BinSquare in #1087
      • Expose the portable checkpoint lifecycle by @BinSquare in #1091
      • Accept an aarch64 checkpoint on any host providing the features its guest was given, and name the ones that are missing by @BinSquare in #1101
      • Capture a Windows machine's console output so a failed boot leaves a record by @BinSquare in #1102
      • Take the machine's storage read-only on shutdown so its filesystem is left clean by @BinSquare in #1100
      • Pull a machine's image again when the guest no longer holds it by @BinSquare in #1106
      • Document the S3 volume source in machine run's --volume help by @NickyHeC in #1104
      • Parallelize direct batch fork admission by @BinSquare in #1103
      • Set SSH_AUTH_SOCK for interactive runs so --ssh-agent works with -i/-t by @Qhilm in #1109
      • Allow explicit read-only system mounts by @BinSquare in #1110
      • Improve host mount performance and coherence by @BinSquare in #1112
      • Rewrite the README's em-dash asides by @BinSquare in #1113
      • Make branching the primary machine lifecycle by @BinSquare in #1118
      • [Public Docs] Point contributors at the docs repository from the README by @NickyHeC in #1092
      • Refresh libkrun with snapshot-safe vsock handling by @BinSquare in #1099
      • Improve host mount performance and coherence by @BinSquare in #1114
      • Fix squashed pack ownership when smolvm runs as root (#1095) by @BinSquare in #1096
      • Stop the Vulkan driver injection from shadowing a workload's own libraries by @BinSquare in #1120
      • Process virtio-fs requests on parallel queues by @BinSquare in #1121
      • Refresh libkrun directory metadata handling by @BinSquare in #1125
      • Explain why a branch was refused and show what each machine was branched from by @BinSquare in #1127
      • Add staged mounts for metadata-heavy workloads by @BinSquare in #1126
      • Make the browser desktop responsive by @BinSquare in #1123
      • Run the aarch64 Omarchy desktop on the GPU on macOS hosts by @BinSquare in #1119
      • Fix stale serve locks after out-of-band stops by @BinSquare in #1128
      • Fix arm64 forks on heterogeneous CPUs by @BinSquare in #1130
      • Ship the containerd shim in the Linux release so Kubernetes support is reachable by @BinSquare in #1132
      • Build the containerd shim by package name and ship the engine its installer needs by @BinSquare in #1133
      • Install the compressed disk templates so pack create works without e2fsprogs by @NickyHeC in #1122
      • Serve the VM boot subcommand from the containerd shim so it needs no separate engine binary by @BinSquare in #1136
      • Stop the Venus bridge logging on every fence poll and reading scanouts back from unbound or foreign images by @BinSquare in #1137
      • Unpack packed layers into a staging directory and rename them into place so a layer directory only ever exists once it is complete by @BinSquare in #1140
      • Give the macOS Omarchy desktop a working top bar and clickable browser chrome by @BinSquare in #1138
      • Handle agent socket write backpressure by @BinSquare in #1145
      • Rebuild the bundled libkrun and macOS virglrenderer from the merged sources by @BinSquare in #1141
      • Speed up large OCI image preparation by @BinSquare in #1144
      • Bind the guest's /dev/net/tun into VM-grade workloads by @BinSquare in #1146
      • Park idle branchpoints until capture by @BinSquare in #1147
      • Add a user directive to the Smolfile and a --user flag by @BinSquare in #1148
      • Sweep fork-source lock files whose machine is gone instead of leaking one per name by @BinSquare in #1155
      • Accept net_backend in a Smolfile so a checked-in file fully describes its networking by @BinSquare in #1156
      • Report how the VM process ended when a command fails because it died by @BinSquare in #1154
      • Let the Omarchy recipe install a pinned package set and survive a rerun by @BinSquare in #1152
      • Bump libkrun to the NVIDIA fence-thread fix and rebuild the Linux blobs by @BinSquare in #1157
      • fix: validate local image archive CPU architecture and improve launcher symlink resolution by @Vishv07 in #1117
      • Bump the workspace to 1.14.0 by @BinSquare in #1158

      New Contributors

      Full Changelog : v1.13.0...v1.14.0

    6. ๐Ÿ”— Register Spill Joy & Curiosity #98 rss

      Here's the start of Chapter 7, 'Naive Intervention', from Antifragile:

      Consider this need to "do something" through an illustrative example. In the 1930s, 389 children were presented to New York City doctors; 174 of them were recommended tonsillectomies. The remaining 215 children were again presented to doctors, and 99 were said to need the surgery. When the remaining 116 children were shown to yet a third set of doctors, 52 were recommended the surgery.

      [โ€ฆ]

      Let us call this urge to help "naive interventionism."

      Goodreads tells me that I read the book in 2019. I honestly can't remember too much about it, but that paragraph has really stuck with me. From time to time, when a friend or relative would say something like, "My doctor said I should โ€ฆ", I'd pull it out of the closet in the back of my head and try to sound smart and say, "Well, you know, there was a study onceโ€ฆ" Then I'd fumble the numbers, of course, and I'm pretty sure that multiple times I made it about wisdom teeth and not tonsils, but the point I would try to make is that people whose job it is to do X are biased toward thinking that doing X is more important than not doing X.

      And now I'm wondering: is this what's going on? Is this what's happening when engineers look at the output of a Sol or a Fable or an Astra and say "it writes bad code, it leaves all these dumb comments"? Bad code? Dumb comments? Really?

      Or did it just knock out a feature, end to end, in the 20 minutes you weren't looking, including frontend and backend changes, including internal and external documentation, and tests of course; and didn't it test it fully, running through the whole thing in a headless browser, presenting you with a video recording of the run-through as proof?

      But the comments are dumb?

      • Some loose, sweaty, post-gym thoughts on the GPT-6 Astra launch video. (Come to think of it: there's no one even attempting to build a device that lets you transfer smells over the Internet, huh? Could call it Pandora's BOx. Anyway.)

      • Towards Self-Driving Codebases. There is a lot to love about this post -- the stance, the examples, โ€ฆ Hard to pick one. It's really good and motivating. After reading it, I set up a bunch of automations in Amp to run daily and clean up and fix things automatically.

      • On not becoming a cyborg. Very, very good and I really like this paragraph: "For example, this is why I don't use LLMs for any of my writing - not even to spellcheck. I'd rather my prose have all the warts of my sometimes-stilted sentences, my often too-esoteric word choice, my generous sprinkling of odd English idioms, than to give it even a whiff of Claudese."

      • The End of Code Review? Or an Opportunity to Rethink it? Yes, yes, yes! I agree with everything here. Code review as most of us have known it for the last ten, fifteen years has never been as good as "we review all of our code" makes it sound: bugs slip through, time is wasted talking about useless bullshit, egos are demotivated, etc. Doesn't mean that all forms of code reviews are bad, but making Astra and Fable open PRs and then have two people review them line by line in September 2026? Nah.

      • Rachel Laycock, CTO of Thoughtworks, on reviews: Maybe We Shouldn't Be Reviewing All This Code. "His concern, which I share, is that simply automating code review away risks losing all the other things we use it for. Code review isn't just about finding bugs. It's how teams share knowledge, teach junior engineers, build collective ownership and spread architectural understanding. My question is: why are we waiting until code review to do all of those things?"

      • Culture clash - At the heart of the Snow/Leavis 'two cultures' clash. I hadn't heard about C.P. Snow or F.R. Leavis before reading and didn't know what the clash was all about, but academic beef at the University of Cambridge? I'm in. And lucky me! It was a delightful read. "For Leavis, in sensing life in great literature, it was necessary to leave its mystery unblemished by attempts at analysis, or quantification, or definition. That is, life's essential mystery is best illuminated by not making it explicit, but by showing, through works of great literature, where life could be found." (Also interesting: I never found the divide between the Humanities and Science to be that stark here in Germany. Here, Humanities is written as Geisteswissenschaften - science of the mind, if you will. There's also no commonly used acronym like STEM. So now I'm wondering: is this Snow/Leavis debate maybe a reason why the divide is that much stronger in the Anglosphere? Sounds like it had a pretty big effect. Of course, you could argue that what lies at the bottom of this divide is already present in Goethe's Faust, โ€ฆ)

      • CleanShot X 5.0 is out and its Studio Mode looks good and is good (I tried it a few times already), butโ€ฆ I have to say, with a heavy heart: I kinda expect a little bit more? This looks like a copy of Screen Studio, but Screen Studio now also has captioning, which this doesn't have and since I have both, I'm not sure whether I'll use CleanShot X over Screen Studio for more serious, studio-like productions? Hoping they pick up the shipping cadence now.

      • Dyson released a toothbrush and it's "only electric toothbrush with a camera to accurately target and precision-floss gaps between teeth" and that technique is called "Gap Optical Targeting" and all of this sounds so over the top and bordering on satire that, man, I want one.

      • Exit the Cave: "There's something romantic about the Cave. About grinding away at something in private. About training with headphones on in our own little world. About stepping away for six months to emerge "unrecognizable" to all those people we imagine thinking about us. [โ€ฆ] We grow so comfortable curating our Cave that we forget the vast, interesting, beautiful, and brutal world beyond its walls. I say all this because I've spent years mistaking effort for progress. I learned this lesson nearly twenty years ago on a wrestling mat." I'm not sure I fully get the wrestling story, but I really like and want to hereby echo the message. Don't grind away in darkness. It's silly. It's delusional perfectionism. You have to hit reality, as fast and as often as possible.

      • Dan Luu on Ed Zitron's AI prediction track record. If you don't have the time to read the whole thing, at least scroll to the middle and read through that timeline. I don't care much about Ed Zitron (I only heard about him a few weeks ago when I saw a video in which he said that AI is "a bubble" and, yeah, maybe? That's probably one of the tamest things you can say nowadays) but, wow , way to dig your heels in, eh?

      • collusion.wiki: "We found ~18,000 posts from autonomous AI agents (self-identifying as from OpenAI) using the public internet to communicate during a web-retrieval task." There's a lot of spicy stuff in there: "This created an issue for the agents because they were only allowed to make GET requests, not POST requests. The agents figured this out, and started collaborating on ways to bypass this sandbox restriction."

      • And Hacker News commenters are discovering more and more wikis used by OpenAI agents to secretly (I mean, it's a stretch) communicate.

      • And: "The most interesting thing to come out of this, in my opinion, was that during the Hugging Face incident, the agents would preface their messages to each other on the message board with 'zz' (zzHELP_, zzANSWER_). I found this amusing because they were being referred to as a swarm and were making a buzzing sound, though the actual reason for it was unknown at the time. Because of this new report, however, we now know that when human wiki administrators discovered the massive influx of messages the agents were using to communicate, they began deleting them in alphabetical order. Once the agents realized what was happening, they started prefacing all their wiki edits with 'ZZZ' to push them to the bottom of the queue, buying time to avoid deletion."

      • Incredible Tim Cook anecdote from 2009: "One day back then, he convened a meeting with his team, and the discussion turned to a particular problem in Asia. 'This is really bad,' Cook told the group. 'Someone should be in China driving this.' Thirty minutes into that meeting Cook looked at Sabih Khan, a key operations executive, and abruptly asked, without a trace of emotion, 'Why are you still here?'

      Khan, who remains one of Cook's top lieutenants to this day, immediately stood up, drove to San Francisco International Airport, and, without a change of clothes, booked a flight to China with no return date, according to people familiar with the episode."

      • For the last couple of weeks, I've been reading The Score (recommended by Steven Sinofsky!) and enjoying it very much, thinking through situations in which I allowed "value capture" to happen to me. I can't reproduce the whole book here, but one of the points Nguyen makes (and it's probably the central point) is that scoring systems can change our values, without us even noticing. Example: you buy a bike because you want to ride through the forest at dawn and then you learn about VO2max and power meters and before you know it you don't enjoy any ride anymore unless some number goes up. Not that that ever happened to me, of course, โ€ฆ So I'm reading this book in the evenings and thinking about it during the day and then I come across this video here, by Alan Thrall, and hot damn, is the universe conspiring to tell me something? Or is it my age? Or is it in the air? The video is great. Yesterday my workout app told me that I completed 866 workouts in the last five years or so and the video 100% reflects my journey. Anyway: great video, great book. Recommend both of them.

      • And for the last week, I've been listening to Radical Acceptance by Tara Brach, because Tim Ferriss recommended it and I've heard about it many times over the years. Not my usual sort of thing, but so far it's very good. But then yesterday I come across this wonderful essay by Michael Nielsen, The Cupcake Incident, and it's exactly what Brach is talking about! I can't believe it. Here too, I can recommend both. Start with the essay, and if it resonates try the Brach book.

      • If you want to start a good fight at dinner: Just bury your trash.

      • Patrick asked me: "Have you read this blog?" And I hadn't. But he sent along this Behind the Scenes about how Marcin writes so much on his blog and it got me hooked ("Who the hell creates their own markup language to write posts like this? Actually, hmm, โ€ฆ") and then I browsed through the blog and, wow, that output is mind-blowing. And it's all soโ€ฆ entertaining and easy to digest? Very good.

      • This video of three Russian musicologists arguing about Bach & Schubert blew up this week. I love it. This is how I like to argue, too, which is not what everyone enjoys, of course. But this video and the Replenish video will serve as the blueprints of how I want my family to talk at the dinner table when we want to enjoy ourselves.

      • My Favorite Database Shirts: "Promoting your database system or start-up with a shirt is almost as important as getting the thing to actually run. As I've told my students several times, in the world of databases you don't sell the steak, you sell the sizzle."

      People you really admire are subscribed already. Let's go:

  4. September 05, 2026
    1. ๐Ÿ”— IDA Plugin Updates IDA Plugin Updates on 2026-09-05 rss

      IDA Plugin Updates on 2026-09-05

      New Releases:

      Activity:

      • augur
        • 0eadee7c: Merge pull request #8 from 0xdea/dependabot/github_actions/actions-deโ€ฆ
      • ida-llm-explainer
        • 598fee57: v1.13.0: multi-instance agent server discovery + session open/close tโ€ฆ
      • ida-nexus
        • c13eea1a: Fix bugs and improve code coverage
        • bd683071: Minor cleanup and add more E2E tests
      • ida-spotlight
      • IDAExecFunctionsImporter
        • 15a52d09: Merge pull request #15 from jokelbaf/feat/linux
      • idamcp
        • e3fbea80: Replace typing_extensions with built-in typing in shared types
      • ming-skills
        • 8a9e0493: fix(router): ๅฎž็Žฐ ming-skills-router ็‹ฌ็ซ‹่‡ชๅŒ…ๅซๆžถๆž„ไธŽ่ทจ็ฌฆๅท้“พๆŽฅๅŒๆจกๅˆ†ๆต
        • 86db4990: fix(docs): ๅผบๅŒ– docs-presentation-idiom ็ฆไปคไธŽๅฏ่ฏไผช Oracle ๅˆคๅฎš
        • 3222cf93: feat(docs): ่ฝๅœฐ docs-presentation-idiom ่ง†่ง‰ๆŽ’็‰ˆ่ŒƒๅผไธŽๅธ‚ๅœบๅœบๆ™ฏๅทฎ้กต
      • Persona4-Decompilation
        • 14e0a130: Restore AI skill callback results and preserve measured predicate floor
        • e8637e0c: Recover AI command predicate and fix helper-bearing probes
        • ae588e25: Record model sound and material animation recovery evidence
        • cbd1d3b8: Preserve model setup and runtime color callback arguments
        • e20824d3: Recover model cloning and canonical hierarchy ABI
        • 19390dc7: Recover animation stepping and dispatch contracts
        • 33d6a5c7: Recover frame lookup and matrix copy helper boundaries
        • 16aab4ca: Recover model attachment from IDA pointer contracts
      • qiling
        • 86c927cb: Merge pull request #1658 from qilingframework/dev
        • d19bf180: Merge pull request #1637 from monoidic/dev
        • 748e254b: Merge pull request #1641 from retrocpugeek/fix/mips-socket-options
        • d0ba235b: Merge pull request #1644 from H1ghC0ntr4sT/fix/dllmain-exception-emu-โ€ฆ
        • 4ee2ab14: Merge pull request #1636 from retrocpugeek/fix/getdents64-alignment
        • f444f817: Merge pull request #1639 from retrocpugeek/fix/clone3-syscall
        • 7364789c: Merge pull request #1646 from w1tcher/fix/fiber-manager-last-error
        • 97bfe039: Merge pull request #1649 from qilingframework/dependabot/pip/setuptooโ€ฆ
        • ace81919: Merge pull request #1650 from Jvlegod/feature/riscv64-debugger
        • deca26e4: Merge pull request #1651 from Jvlegod/feature/qdb-riscv
        • e1f0526f: Merge pull request #1652 from Gigithecode/fix/idaplugin-future-import
        • 638ee864: Merge pull request #1657 from xwings/dev
        • 6f7b256f: Merge branch 'dev' of github.com:xwings/qiling into dev
        • 2dbbf485: bump to 1.4.11
        • d8c2e30b: Merge branch 'qilingframework:dev' into dev
        • 206b90fd: minor refactor and pypi fix
    2. ๐Ÿ”— r/LocalLLaMA AA Update! Here's how the Frontier ranks. rss

      AA Update! Here's how the Frontier ranks. | Along with everyone's favorite here, qwen3.8-27B submitted by /u/Tall_Abrocoma_3533
      [link] [comments]
      ---|---

    3. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.10.4
    4. ๐Ÿ”— r/LocalLLaMA Qwen3.8-27B beat the Wikipedia game in 6 clicks. rss

      Qwen3.8-27B beat the Wikipedia game in 6 clicks. | Used qwen3.8-27b in Opencode to make this silly mini-game because I'm not sober: ``` We are going to play a game, it will be the Wikipedia game. The Wikipedia game has the following rules:

      • You will have a Wikipedia article set as a starting point.
      • You will have a Wikipedia article set as an ending point.

      Your objective is to reach the the end point, which is an article completely separate from the starting point article. Your only constraints are the following:

      • You are ONLY allowed to click on any hyperlinks inside of wikipedia directly. No external links, no typing inside of wikipedia's search bar (but finding the starting article on google is valid. The 10-click limit starts once you reach the starting point article).
      • You are NOT allowed to return to a previous page. All clicks much be performed in a forward-looking trajectory.
      • You must reach the end article within 10 hyperlink clicks inside of Wikipedia. If you do not reach the destination article within 10 clicks, you lose.
      • Do not update any documentation for this task. It is only a game.

      Use playwright to click the links. ``` Basically, Qwen needs to reach an ending article within 10 Wikipedia hyperlink clicks from the starting article, which is usually an unrelated article. It needs to use playwright (or some equivalent browser MCP) to click the Wikipedia hyperlinks without backtracking, using search or using external links. I verified the links for accuracy and I can confirm it managed to complete this task within 6 turns. Thought it would get stuck in a loop. Its a dumb minigame but I think its a good, simple agent test to perform. submitted by /u/swagonflyyyy
      [link] [comments]
      ---|---

    5. ๐Ÿ”— modem-dev/hunk v0.21.1 release

      Faster, reliable paging in LazyGit

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

      hunk update 0.21.1
npm install -g hunkdiff@0.21.1

      Pager reliability

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

      Compatibility notes

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

      All merged pull requests

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

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

    6. ๐Ÿ”— Armin Ronacher Latent Powers rss

      A few weeks ago I felt like it would be fun to see if I can make one of those cheap Chinese CarPlay dongles run something other than the stock firmware. The idea was that rather than just forwarding CarPlay, why not do something more interesting with them? They all work quite similarly: they act as bridges between your car and the phone. From there they deal with video and audio streams and pass some other data through. Most of them also bring up a custom UI for pairing and have a web interface that your phone can reach for updates.

      Long story short: I had a conversation with Fable and Sol via Pi about what could be done with such a dongle or whether I should use a Raspberry Pi instead if I wanted to do my own thing there. I figured it might be quite fun to run my own code while still allowing regular CarPlay to pass through.

      Through working with the LLM I learned about CatPlay, which is a Rust reimplementation of the CarPlay protocol that can run on Carlinkit devices. In particular, it can run on the Carlinkit Mini Ultra, which I figured would be easy enough to buy. I do have a few CarPlay adapters around, but I did not have that particular model, so I bought one on Amazon. Twenty-four hours later, I had a device in my hand that was branded as a Carlinkit Mini Ultra, but instead of being the Ingenic device that the original author used, it turned out to be something else.

      This is normally where the story would stop. However, it's 2026. Armed with a bit of knowledge about how these systems work, I managed to have some fruitful discussions with Kimi K3 and Sol and figure out how flash the device and in turn, how to make CatPlay compile for that SoC.

      I guess that hacking these USB devices is not necessarily hard, but it's laborious and you can easily end up bricking your devices. It also just sucks because sometimes you need to work with someone else's code that does not itself run on your machine. In the past, I would abandon many such projects for lack of tenacity. But my clanker is tenacious.

      But so are all of our clankers. Some of the projects we're now attempting are happening because of conversations we have with them. In this case I did not find or decide on CatPlay, the model did. It was not the only suggestion, but it became the best starting point after discarding others.

      And I discover this more and more. Particularly when we have solitary interactions with these models, some of us "independently" decide to work on similar projects. When I talked with an acquaintance about CarPlay he also mentioned recently that he decided to try something similar because he too wanted to see if he can get his own agent be hooked up with the car. And guess what: he too learned about the CarPlay hacking community, and that it's an option, from the models and roughly around the same time.

      It really got me thinking about how this could create situations in which completely independent people end up building things they believe are their own ideas. Yet they were inspired or pushed towards doing something by a conversation with an LLM โ€” a conversation that someone else also had. What if we took paths, because those were the paths that were more likely with current generation models? There is a running joke in the AI builder community right now that we're all working on the same things, and in many ways it feels like we are. That might be because those things are obvious, or it might be partly because we all use the same models with the same capabilities.

      A few months ago, I first saw Lucas Meijer share the idea to make a model in Pi produce HTML reports rather than Markdown. I thought that was pretty unique. Except, well turns out the models are probably trained more and more for that (e.g. Claude Artifacts), and now it has become for many the default choice for sharing reports.

      How much of what we build comes from eliciting the same latent capabilities from the same models? Did the models make us prompt them that way? Was it because we shared ideas on Twitter and other communities that inspired us? Or is it all unrelated?

      There is something powerful and strange about how LLMs diffuse knowledge and capabilities, while perhaps also nudging us all simultaniously and independently toward building the same things.

generated: September 08, 2026 at 07:29:50