- ↔
- →
- July 19, 2026
-
🔗 @malcat@infosec.exchange You like [#capa](https://infosec.exchange/tags/capa) but wish it would scan mastodon
You like #capa but wish it would scan faster?
Try out #Malcat 0.9.15, featuring a blazing fast native Capa scanner, among other improvements:https://malcat.fr/blog/0915-is-out-capa-scanning-at-native- speed/
-
🔗 smol-machines/smolvm smolvm v1.6.13 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
- Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
- Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
- Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
- Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
- Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
- Never LRU-evict the reference-shared pack store by @BinSquare in #666
- Fail an image machine's start when the image pull fails by @BinSquare in #669
- Flatten from-vm packs to a single layer and share the pack export, workload launch, and machine-create env handling in the lib by @BinSquare in #668
- Cap keep-alive exec output so oversized results return a clear error instead of a frame-too-large crash by @BinSquare in #670
- Fix file-upload body limit and clarify the oversized-exec-output guidance by @BinSquare in #671
- CUDA fork: sync-call retry, allocation burst, multi-GPU pinning, sandboxed serve, and machine-create workload by @BinSquare in #672
- Reload clone-worker modules byte-identical to the golden's images by @BinSquare in #673
- Recover fork clones whose worker died, and give clone reconnects a real handshake window by @BinSquare in #675
- CUDA 13 guest surface by @LoganGrasby in #674
- Re-key the golden's persistent exec overlay to the clone so forks inherit filesystem state by @BinSquare in #677
- Replay function attributes on clone-worker kernels, and print backtraces on fatal signals by @BinSquare in #676
Full Changelog :
v1.6.0...v1.6.13 -
🔗 smol-machines/smolvm smolvm v1.6.12 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
- Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
- Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
- Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
- Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
- Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
- Never LRU-evict the reference-shared pack store by @BinSquare in #666
- Fail an image machine's start when the image pull fails by @BinSquare in #669
- Flatten from-vm packs to a single layer and share the pack export, workload launch, and machine-create env handling in the lib by @BinSquare in #668
- Cap keep-alive exec output so oversized results return a clear error instead of a frame-too-large crash by @BinSquare in #670
- Fix file-upload body limit and clarify the oversized-exec-output guidance by @BinSquare in #671
- CUDA fork: sync-call retry, allocation burst, multi-GPU pinning, sandboxed serve, and machine-create workload by @BinSquare in #672
- Reload clone-worker modules byte-identical to the golden's images by @BinSquare in #673
Full Changelog :
v1.6.0...v1.6.12 -
🔗 Filip Filmar Cocoapuffs: Booting Fuchsia's Zircon Kernel on a RISC-V core in Artix-7 FPGA rss
Zircon, the (non-POSIX, non-Linux) kernel powering Fuchsia, an open-source operating system under development at Google, now boots on my RISC-V based system-on-chip design, running on an AMD Artix-7 FPGA device. While this might be the first Fuchsia-powered device apart from the boards that Google works on, it is definitely the first piece of programmable hardware running Fuchsia. Why not Linux instead? I thought it would be novel and more amusing to see Fuchsia booting on a FPGA, vs Linux.
-
- July 18, 2026
-
🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-18 rss
IDA Plugin Updates on 2026-07-18
New Releases:
Activity:
- ida-sigmaker
- 8741e798: Merge pull request #85 from mahmoudimus/diff/ignore-superpowers-docs
- ca335484: docs: correct macOS user directory
- c5064833: Ignore local superpowers planning docs
- 7fd35fce: Merge pull request #84 from mahmoudimus/diff/release-v1.14.0-test-fix
- 774c332e: Keep speedups remediation test version-aware
- 6394378c: Prepare v1.14.0 release
- 406c3969: Merge pull request #83 from mahmoudimus/diff/xref-buffer-reuse
- cdc32ec0: Merge pull request #81 from mahmoudimus/diff/xref-lazy-startup
- e1950d05: Merge pull request #80 from mahmoudimus/diff/simd-extension-api-compa…
- c480160f: Reuse buffers across xref candidates
- 2e9d282e: Keep xref progress visible without pre-counting
- f34a4ebe: Make xref startup cancelable
- 78250748: Accept structurally compatible legacy speedups
- leaknet
- 5b9087f3: - added missing retail shaders (did NOT replace ANY beta shaders)
- Luc-Nhan
- re-sbz
- 49973e76: feat: add d3dx
- ida-sigmaker
-
🔗 HexRaysSA/plugin-repository commits sync repo: +1 release rss
sync repo: +1 release ## New releases - [SigMaker](https://github.com/mahmoudimus/ida-sigmaker): 1.14.0 -
🔗 modem-dev/hunk v0.17.2 release
What's Changed
- Fix mouse-selection copy alignment for wide CJK and emoji characters by @endotakuya in #548
- Reject malformed line and hunk navigation values by @fallintoplace in #535
Full Changelog :
v0.17.1...v0.17.2 -
🔗 r/reverseengineering Making a mod for Grand Prix Circuit (DSI / Accolade, 1988) rss
submitted by /u/alberto-m-dev
[link] [comments] -
🔗 Register Spill Joy & Curiosity #92 rss
This week was busy : we shipped a lot of things, recorded quite a few things, I worked on my Laracon talk, chatted with amazing programmers in different timezones, and our local public swimming pool celebrated its 50th birthday.
There wasn't a lot of reading this week, but a lot of thinking and wondering and questioning and aha! -ing. And I kinda can't shut up about it. So…
Some of you might remember my original description of this newsletter: "It's very informal; it's what I'd send you if you were to ask me what's on my mind this week in an email."
Now, here is what I'd say if you were to ask me what's on my mind this week, on a phone call:
-
Finally: Amp now has subscriptions. Yes, you read that right. Go there, get a subscription, pair it with your ChatGPT subscription so you get infinite GPT-5.6 tokens, and spawn those orbs.
-
We also shipped agent-to-agent communication in Amp: agents can now spawn other agents -- anywhere you have a Amp instance running or in an orb -- and then send messages and files to them. The number of "holy shit, it just …" messages this produced in our internal Slack is insane. To give you a taste: this morning I was hacking on something in our orb, but the agent in the orb lacked the permissions to upload an asset to our bucket. So the agent said: hey, start
amp --no-tuion your machine, where you have permissions, then I'll start a thread there, send it that asset, and ask it to upload the file. And… it fucking did it! Exactly like that! I startedamp --no-tui, I saw the new thread being created, I watched both of them, and saw how they sent messages to each other. Wild! -
Raising An Agent is back! Here's the first episode of the new season: The Local Dev Env is Dead. Or listen on Spotify.
-
I know what you're thinking: "Thorsten, your voice… I need more of it." Don't worry, I got you. Dominic and Morten invited me to be a guest on the go podcast and our episode came out this week: Agentic engineering is here to stay with Thorsten Ball.
-
Yes, I know, you want more. I got more: Evan Phoenix, Quinn and I shipping from orbs to a Miren cluster. There's coding in there, but also a lot of talking about coding and developer tools and the future of software and deployments. Evan has shipped and worked on more successful developer tooling than basically anyone else (Rubinius! Puma! Hashicorp!), so him sharing his thoughts was a treat.
-
You want more? Okay, okay. I recorded a short video with thoughts on this race we're in and the forces at play that I don't think most developers are aware of. Titles I considered: "man, it must suck to be a model house", "the tectonic forces shaping software", "once the compute is available, this will all change again", and "there won't be a rugpull"
-
Hardcore Kindle reader here, but this really, really made me want to buy physical books again, even though it should probably serve as a warning to not do that: "Mendel Uminer faced a crisis when his landlord objected to the 10,000 volumes in his New York studio apartment."
-
Fabien Sanglard: Don't you mean extinct? Lovely article. You need to read this for the Phil Tippett story alone.
-
Another amazing Fabien Sanglard article: Jurassic Park computers in excruciating detail. Jurassic Park is one of my favorite movies of all time. Easy top five. I love it. And I'm sure its depiction of computers had an influence on my life. But one thing I hadn't noticed until reading this article is that Oppenheimer portrait.
-
After 7 years in production, Scarf has reluctantly moved away from Haskell. I'm honestly not sure what to say about the skeptics any more. Maybe this: for decades now, some programmers were really lucky in that what they loved to do, what they saw as their craft and their passion, was valuable to businesses. Now that's not the case anymore. And if you don't adapt, then, well, you end up not being valuable to businesses anymore.
-
Holy moly: Measuring input latency on Linux: X11 vs Wayland, VRR, and DXVK. If you're in the mood to find out how deep a rabbit hole can go, then read this. Very fascinating. Also: I can't believe it's 2026 and we're still talking about X11 vs. Wayland. Wayland was released in 2008.
-
Linus Torvalds on the Linux kernel mailing list: "There are other questions around AI (like what the economy of it will actually look like in the end), but 'is it useful' is no longer one of those questions. Anybody who doubts that clearly hasn't actually used it. Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a 'it keeps finding embarrassing bugs' standpoint. But the solution is not to put your head in the sand and sing 'La La La, I can't hear you' at the top of your voice like some people seem to do."
-
There is this whole debate going on around whether you should still read the code agents produce. antirez now chimed in too: Control the ideas, not the code. He writes: "But if I had my hands free, you know what I would do, instead? Use all the time that the review is taking me to do more QA, to think at the next optimization idea and apply it, and to use LLMs to write a DESIGN.md file where each data structure is described in human language, with the ideas it contains, the implementation tricks, the design. That, in the future, is going to be much more useful." I think he's onto something here. I personally do spot checks of code and mostly don't care about single functions anymore, except when the blast radius would be huge or when it's super critical. But it ties back to what antirez writes: I want to control the ideas, not the code.
-
And here's Sean Goedecke: In defense of not understanding your codebase. As always, very good post. I agree. People who say "you have to review every line" make me think that either they haven't worked with (a) a model that was released in 2026 or (b) other people in a multi-team engineering org.
-
Justin Jackson on the value of software in a Fable world: "Generally, the economy rewards difficulty and rarity. If something is hard to do or make, you get to charge more. So if AI reduces the time it takes to build software, what happens to the value of software?" See also my thoughts on software & oil here.
-
What working at Google feels like: "Have you ever changed a flat tire on the shoulder of the freeway? When you get out of your car and stand by the side of the road, you realize you are in a world scaled for 30,000-pound tractor trailers, not for human beings. The white stripes between the lanes that usually flash by like little punctuation marks are actually ten feet long and thirty feet apart. Even the road signs look absurdly out of scale, like those textbook-sized large-print editions of bestsellers the library stocks for elderly people. And then one of those tractor trailers hurtles by at seventy miles per hour, inches from your fragile body, and it feels like God himself is screaming in your face. That's exactly what working at Google feels like at first. You realize very quickly you are inhabiting an environment that was not designed for humans to experience with their naked minds. Even the smallest problems--which customers are we allowed to send this email to? What countries will have special legal requirements around the deployment of this tiny feature?--are so mind-numbingly complex that they make you want to shrink down into a fetal ball on the side of the freeway and just let the traffic shriek past."
-
"I had a french professor who once said if you just did something like going to the supermarket and experienced it fully without the goggles of habit and categories you would go crazy with pure sense and joy. I think about it all the time. In a way this is all for him." And I had a french teacher once who said that bean soup is the poor man's piano. I think about him every time I eat beans. So there's that.
If you liked my phone call, you should subscribe:
-
-
🔗 r/reverseengineering Automated reverse engineering of Android apps rss
submitted by /u/No_Distribution_9182
[link] [comments] -
🔗 smol-machines/smolvm smolvm v1.6.11 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
- Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
- Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
- Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
- Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
- Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
- Never LRU-evict the reference-shared pack store by @BinSquare in #666
- Fail an image machine's start when the image pull fails by @BinSquare in #669
- Flatten from-vm packs to a single layer and share the pack export, workload launch, and machine-create env handling in the lib by @BinSquare in #668
Full Changelog :
v1.6.0...v1.6.11 -
🔗 smol-machines/smolvm smolvm v1.6.10 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
- Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
- Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
- Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
- Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
- Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
- Never LRU-evict the reference-shared pack store by @BinSquare in #666
- Fail an image machine's start when the image pull fails by @BinSquare in #669
Full Changelog :
v1.6.0...v1.6.10 -
🔗 Ampcode News Subscriptions, At Last rss
Today we're launching Amp Subscriptions in Beta. You can now subscribe monthly to Amp and explore the frontier with us, with cheaper and more predictable pricing:
If you subscribe on or before Sunday, July 19[^1], you'll get bonus 2x usage for orbs and agents in the first month.
Amp Is Not (Necessarily) Expensive Anymore
Amp just got a lot cheaper for many of you, especially if you link your ChatGPT subscription.
We know you've been asking for this for a long time. Until now, Amp's pricing model has been pay-as-you-go for tokens at API prices, no subscription. Compared to other agents on monthly subscriptions, this made Amp more expensive—"the Apple or Porsche of agentic coding tools", to put it nicely.
But everything is changing. Great tokens are reasonably priced. Good-enough tokens are downright cheap (like GLM-5.2 in our new low mode). Being on the frontier no longer requires using the most expensive models.
You can still pay-as-you-go in Amp; monthly subscriptions aren't required.
And, to be clear, to use Amp beyond your subscription's included monthly limits, you need to link your ChatGPT subscription or add paid credits.
The Frontier Runs in Orbs, Not Your Laptop
The frontier is now about agents working for you in parallel, without your supervision, on remote machines. We call these "orbs", and Amp's monthly subscriptions include so much orbs usage you don't need to worry about counting the minutes.
We want you to finally be able to (and want to) kill your singleton local dev environment.
We want you to make your agents go further to prove to you their work is correct, with videos and screenshots and local dev portals, and much less manual code review.
Remember last year, when other agents asked you to approve the agent's work step-by-step, edit-by-edit? Amp users realized before anyone else that was dumb and slow, and Amp never did that.
This shift feels similar to us. It's inevitable, and we want it to go as fast as possible. We hope this subscription makes it easy for you to explore this new frontier with us.
-
- July 17, 2026
-
🔗 smol-machines/smolvm smolvm v1.6.9 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
- Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
- Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
- Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
- Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
- Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
- Never LRU-evict the reference-shared pack store by @BinSquare in #666
Full Changelog :
v1.6.0...v1.6.9 -
🔗 r/reverseengineering [Crackme x64] Modular Vault — 6-floor path-dependent opcode encryption (debugger welcome) rss
submitted by /u/AngryIgor
[link] [comments] -
🔗 @binaryninja@infosec.exchange Going live! Join us to learn about everything that's new in Sidekick 26: mastodon
Going live! Join us to learn about everything that's new in Sidekick 26: https://www.youtube.com/live/S5hAxyopaQk
-
🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +5 releases, ~1 changed rss
sync repo: +1 plugin, +5 releases, ~1 changed ## New plugins - [SigMaker](https://github.com/mahmoudimus/ida-sigmaker) (1.13.0) ## New releases - [IDASQL](https://github.com/allthingsida/idasql): 0.0.18 - [hrtng](https://github.com/kasperskylab/hrtng): 3.9.108 - [ida-rpc](https://github.com/bkerler/ida_rpc): 0.1.8, 0.1.7 ## Changes - [IDASQL](https://github.com/allthingsida/idasql): - 0.0.8: archive contents changed, download URL changed -
🔗 @binaryninja@infosec.exchange Our Firmware Reverse Engineering class is just over a week away! Join us to mastodon
Our Firmware Reverse Engineering class is just over a week away! Join us to learn what's involved in analyzing bare-metal software and how to overcome those challenges! https://shop.binary.ninja/products/fre- july-26
-
🔗 tomasz-tomczyk/crit v0.18.1 release
What's Changed
- fix: align story review paths and daemon errors (#747) by @tomasz-tomczyk in #747
- fix: harden story navigation and embedded renderers (#748) by @tomasz-tomczyk in #748
- fix: harden story review lifecycle (#739) by @tomasz-tomczyk in #739
- fix: polish story mode rendering (#738) by @tomasz-tomczyk in #738
- fix: restore Claude Code plan approval hooks (#745) by @tomasz-tomczyk in #745 - Thank you @jvaldiviezo9 for reporting!
- fix: preserve daemon initialization errors for clients (#744) by @tomasz-tomczyk in #744
- fix: unblock project prompt trust dialog (#743) by @tomasz-tomczyk in #743
- fix: sync Codex crit skill wait-loop wording (#733) by @tomasz-tomczyk in #733
Documentation and maintenance
- chore(readme): update top level readme with correct go install command (#742) by @jacob-winkler in #742 - Thank you!
- chore: remove Go Report Card badge (#746) by @tomasz-tomczyk in #746
New Contributors
- @jacob-winkler made their first contribution in #742
Full Changelog :
v0.18.0...v0.18.1 -
🔗 r/reverseengineering Maintaining the old code of the man who wrote "How To Write Unmaintainable Code" rss
submitted by /u/Odd-Flamingo-6211
[link] [comments] -
🔗 smol-machines/smolvm smolvm v1.6.8 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
- Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
- Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
- Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
- Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
Full Changelog :
v1.6.0...v1.6.8 -
🔗 smol-machines/smolvm smolvm v1.6.7 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
- Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
- Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
Full Changelog :
v1.6.0...v1.6.7 -
🔗 smol-machines/smolvm smolvm v1.6.6 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
- Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
Full Changelog :
v1.6.0...v1.6.6 -
🔗 smol-machines/smolvm smolvm v1.6.5 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
Full Changelog :
v1.6.0...v1.6.5 -
🔗 Julia Evans Learning a few things about running SQLite rss
Hello! I've been working on a Django site recently, and I decided to use SQLite as the database. When I was getting started with using SQLite as database for a website I read a bunch of blog posts about how it is totally fine to use SQLite in production for a small site and I think it is totally fine, but what I did not fully appreciate is that SQLite is still a database, databases are complicated, and I do not know a lot about operating databases.
So here are a couple of small things I've been learning about running SQLite. This is the 4th website I've used SQLite for, and I think this one is harder because with the power of the Django ORM I've been making the database do more work than I was previously without Django.
I started by turning on WAL mode like all the blog posts said to do and hoping for the best.
ANALYZEis apparently importantToday I was running a query (using SQLite's FTS5 for full-text search) on a table with 4000 rows and it took 5 seconds. That seemed wrong to me: computers are fast!
It turned out that what I needed to do was to run
ANALYZE! Immediately the problem query went from taking 5 seconds to like 0.05 seconds (or some other number small enough that I didn't care to investigate further). I still don't know exactly what went wrong in the query plan, but my best guess is that it was some sort of accidentally quadratic thing.ANALYZEgenerates "statistics" (I guess about the number of rows in each table? and presumably other things?) so that the query planner can make better choices.Maybe one day I'll learn to read a query plan.
cleaning up the database is tricky
Occasionally I've run into situations where I accidentally put a bunch of rows in my database that I don't want to be there (for example completed tasks from django-tasks-db), and I want to clean them up.
What's happened to me a few times in this case is:
- I run some kind of command to clean up the rows
- The command takes more than 5 seconds, since there are a lot of rows (though I still have some questions about why these DELETE statements are so slow honestly, maybe there's a bunch of Python code running inside a transaction, I'm not sure)
- One of the other workers tries to write the database while this is happening, and times out after 5 seconds (I have a timeout of 5 seconds set)
- The worker crashes because it couldn't write to the database and the VM shuts down
My approach so far has been to just do these cleanup operations in small batches so that I don't need to do database queries that take more than 5 seconds to run. This whole experience has given me more of an appreciation for why someone might want to use a "real" database like Postgres which can have more than one writer at the same time though.
Maybe in the future I'll just take the site down for scheduled maintenance instead when I need to do this kind of thing, but I haven't figured out a workflow for that yet.
no notes on performance of ORM queries yet
So far I've been using Django's ORM to make any query I want without paying any attention at all to query performance and it's mostly been going okay other than the
ANALYZEthing. The database is pretty small (maybe 10000 rows?) and I expect it to stay pretty small forever, so I'm hoping that that plan will keep working.backing up sqlite
I've done SQLite backups a couple of ways. I don't think I've actually tested restoring from my backups but I do usually try to monitor them with a dead man's switch.
way 1: restic
sqlite3 /data/calendar.db "VACUUM INTO '/tmp/calendar.sqlite'" gzip /tmp/calendar.sqlite # Upload backup to S3 # Sometimes the backup gets OOM killed and so it stays locked, do an unlock restic -r s3://s3.amazonaws.com/some_bucket/ unlock # Do the backup & prune old backups restic -r s3://s3.amazonaws.com/some_bucket/ backup /tmp/calendar.sqlite.gz restic -r s3://s3.amazonaws.com/some_bucket/ snapshots restic -r s3://s3.amazonaws.com/some_bucket/ forget -l 1 -H 6 -d 2 -w 2 -m 2 -y 2 restic -r s3://s3.amazonaws.com/some_bucket/ pruneway 2:litestream
I started trying out Litestream recently because I felt like doing incremental backups might be more efficient: my restic backups were sometimes getting OOM killed, and I was a bit tired of it. Basically I just write a config file and run:
litestream replicate -config litestream.ymlI set
retention: 400hin my config file in an attempt to retain some amount of history of the database but I have no idea if it works.I've been backing up to AWS, which is always a pain because it's annoying to navigate the AWS console to generate credentials. Maybe one day I'll move away to some other S3-compatible alternative.
you can use multiple databases
My current project only has one database, but one trick I used with Mess with DNS was to split the tables into three separate database files because I didn't actually need my tables to be in the same db. I think it was helpful.
Mess with DNS has been running on SQLite for 4 years now (since 2022) and it's been great, I think the move from Postgres was a great choice for that project.
that's all!
It's always kind of fun to see how long it takes me to learn sort of basic things about the technologies I'm using. I think I used SQLite for a web project for the first time in 2022 and I only learned that
ANALYZEexisted today! I imagine in a year or two I'll be learning about some other very basic feature.some references
Some blog posts I've looked at, other than the official docs:
-
🔗 New Music Releases Tiësto - Echo Sax Finale rss
Tiësto - a new release is available:
- 2026-07-17: Echo Sax Finale (Single)
Amazon: Canada | Deutschland | France | United Kingdom | United States
Visit muspy for more information.
-
🔗 New Music Releases Periphery - The Marigold Nocturne rss
Periphery - a new release is available:
- 2026-07-17: The Marigold Nocturne (Single)
Amazon: Canada | Deutschland | France | United Kingdom | United States
Visit muspy for more information.
-
🔗 New Music Releases Haken - in a fever dream rss
Haken - a new release is available:
- 2026-07-17: in a fever dream (EP)
Amazon: Canada | Deutschland | France | United Kingdom | United States
Visit muspy for more information.
-
🔗 Ampcode News From Agent to Agent rss
You can now ask your agents in Amp to spawn other agents. In orbs, your local machine [^1], or on any other machine.
They can send messages and files to each other, too.
You can have agents in orbs work on side quests while you continue your work:
Spin up an orb thread with what you know about this unrelated bug, ask it to fix it, then keep working here.Or fan out work:
Run four low-mode threads in parallel to test this flow in Chrome at four screen sizes and report back with screenshots.Find and continue old work by pulling in the important files:
Pull the files from my abandoned prototype thread into this workspace and integrate the useful parts into our current approach.Offload work to another machine:
Start a new thread on cloud-dev-box and upload this test matrix we created. Ask it to run through each row at least 10 times.Coordinate cross-project work:
Spawn an agent in the docs project, send it what it needs to document this API change, and ask it to report back.Agents running locally, or in orbs, or anywhere else, and sending messages and files to each other? It's a whole new world.
- July 16, 2026
-
🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-16 rss
IDA Plugin Updates on 2026-07-16
New Releases:
Activity:
- binsync
- capa
- ffxiv_bossmod
- ida-ios-helper
- 3cca707d: Merge pull request #23 from FloofyPlasma/feat/objc_fast_enum
- ida-llm-explainer
- 4ca175e0: v1.7.3: inside-out recursive explain, caller call-site snippets, call…
- Luc-Nhan
- bf1faa64: chore(release): bump version to 1.11.1
- 4c65cf84: Merge branch 'feat/remove-rikugan-md-legacy'
- 56ef1e85: docs(memory): refine spec — binding-state guard retention, test_manag…
- 1e6b5c2f: docs(memory): document central MEMORY.md cutover, remove RIKUGAN.md refs
- 9e757889: test(memory): remove obsolete legacy and activation-gate tests
- 981eb4aa: refactor(memory): remove legacy importer and clean docstrings
- 74da5983: docs(memory): update research mode prompt to reference MEMORY.md
- 3f33ef89: refactor(memory): persist plans via central memory service
- 99bb383d: refactor(memory): remove legacy RIKUGAN.md save/read paths
- 0390cd9f: refactor(memory): remove legacy RIKUGAN.md loading from system prompt
- 37f4b27b: refactor(memory): always wire central memory in controller
- eb85eedb: test(memory): remove dark-mode tests and flag references
- 2cde3190: refactor(memory): remove dark-mode branches from MemoryWorkspaceManager
- bd3f9f27: refactor(memory): remove dark-scaffolding config flags
- ca3ae64e: docs(memory): implementation plan for RIKUGAN.md legacy removal
- 0158edb8: docs(memory): expand spec after self-review (tests, identity-failure,…
-
🔗 smol-machines/smolvm smolvm v1.6.4 release
What's Changed
- Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
- Fix the pacman repo build so it packages both architectures by @BinSquare in #626
- Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
- docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
- Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
- CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
- Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
- feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
- Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
- Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
- CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
- Bump the workspace to 1.6.1 by @BinSquare in #641
- Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
- Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
- CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
- Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
- Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
- CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
- CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
- Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
- release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
- Stream the pack overlay export to disk by @BinSquare in #654
- CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
- feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
Full Changelog :
v1.6.0...v1.6.4 -
🔗 MetaBrainz Picard 3 beta 7 released rss
Today, we have released MusicBrainz Picard 3 beta 7. This new versions brings several fixes over the last beta 5 (yes, we have skipped a beta number again), but also improvements and some new features. Among the highlights are:
- Option profiles can now be exported and imported as TOML files. This makes sharing options much easier. We are excited to see how this will be used by you all.
- Artist name standardization can now be set to one of three values: no standardization, standardizing only variations of the artist name ("Beatles" vs. "The Beatles") or standardizing also actual artist name changes ("Diddy", who previously performed under the names “P. Diddy” and “Puff Daddy”). Standardizing name variations is the new default setting. See also the documentation.
- Plugins can now implement custom CD ripper log file support, and there is built-in support for Cyanrip log files.
- Picard can now much better handles wrongly or differently encoded filenames when loading files.
- The setup wizard got some improvements, allowing users to configure their update notification settings for the app and plugins. Also the setup wizard can now be started again from the help menu. This is not yet the final version of the wizard, but it's getting closer.
- The User Guide was updated to document the latest changes.
Download links and a detailed list of changes since Picard 3 beta 5 are available below. For a more detailed overview of what is new in Picard 3 please see the previous blog post Picard 3 Alpha Release.
While we have all the major features implemented and with the latest bug fixes we are confident in the current code, this is still a pre-release and there might be bugs. If you use this, do so with care, backup your files and please report any issues you encounter.
Some of the changes are also backward incompatible, hence we recommend you make a backup of your Picard.ini config file before trying the beta version. You can do so in Picard’s Options under Advanced > Maintenance.
What’s new?
Bugfixes
- PICARD-3330 - Config upgrade hooks do not update profile overrides for value transforms
- PICARD-3331 - Encoding error when saving file metadata
- PICARD-3332 - Enums are not stored as values in option profiles
- PICARD-3333 - Cover art provider plugin option pages cannot have profile highlights
- PICARD-3334 - Enabling track title translation always uses the recording title
- PICARD-3336 - Can not go back to main app window after viewing Picard > About Picard
- PICARD-3338 -
PICARD_PLUGIN_REGISTRY_URLenv var ignored when official registry cache exists - PICARD-3339 - Plugin boolean options show up in quick settings, but are not usable as such
- PICARD-3342 - Profile highlights broken if same option name is used by different plugins
- PICARD-3344 - Crash when refreshing collections list
- PICARD-3345 - Exception when reading
SYLTtag with newline
New Features
- PICARD-30 - Add
_artistcommentand_albumartistcommentvariables - PICARD-3328 - Support TOML-based exportable/importable profiles
- PICARD-3346 - Cyanrip log support
Improvements
- PICARD-2673 - Standardize artist name variations by default
- PICARD-2845 - Add wizard illustration to first run information dialog and setup wizard
- PICARD-2999 - Automatic update check should be opt-in
- PICARD-3335 - Replace
picard-pluginswithpicard-clisubcommand architecture - PICARD-3337 - Add a
picard-cli plugins compile-uicommand - PICARD-3343 - Allow starting the setup wizard again from the help menu
- PICARD-3347 - Add a plugin v3 extension point to register a custom CD ripping log parser
Download
We appreciate your interest in trying this new version. Use with care, backup your files and please use theMetaBrainz community forums and the ticket system to give feedback and report bugs.
For Windows and macOS you can download the beta version from the Picard download page. Linux users can run from source or try the beta channel of the Picard snap package.
Picard is free software and the source code is available on GitHub.
Acknowledgements
Code contributions by Laurent Monin and Philipp Wolfer.
Translations were updated by Marc Riera (Catalan), rez00 (French) and zatto13 (Japanese). Documentation updates by Bob Swift, Laurent Monin and Philipp Wolfer. -
🔗 Simon Willison Kimi K3, and what we can still learn from the pelican benchmark rss
Chinese AI lab Moonshot AI announced Kimi K3 this morning, describing it as their "most capable model to date, with 2.8 trillion parameters". It's currently available via their website and API, but an open weight release is promised "by July 27, 2026".
Moonshot are calling this the first "open 3T-class model" (I guess they're rounding 2.8 trillion up to 3 trillion), taking the crown from DeepSeek's 1.6T v4 Pro. Their self-reported benchmarks have K3 mostly beating Claude Opus 4.8 max and GPT-5.5 high, while losing out to Claude Fable 5 and GPT-5.6 Sol.
A few highlights from the Artificial Analysis report on the model:
- "On our private long-horizon knowledge work evaluation, Kimi K3 reaches an overall Elo of 1547, +732 points from Kimi K2.6 and behind only Claude Fable 5."
- "Cost per task ($0.94) is similar to GPT-5.6 Sol ($1.04), ~1/2 the price of Opus 4.8 ($1.80) and higher than open weights peers"
- "Kimi K3’s token usage on the Artificial Analysis Intelligence Index decreased significantly, using 21% fewer output tokens than K2.6."
The model is also now the leading model on Arena.ai's Frontend Code arena, surpassing even Claude Fable 5.
The new model is notable for the pricing: $3/million input tokens and $15/million output tokens, putting it at the same level as Anthropic's Claude Sonnet series and making it the most expensive model released by a Chinese AI lab to date. This is a significant increase on their earlier models such as Kimi K2.6 at $0.95/$4. 2.8 trillion parameters is also more than twice the size of that 1T model.
But how does it pelican?
I used OpenRouter (to avoid signing up for a Moonshot API key) with the llm-openrouter plugin to generate an SVG of a pelican riding a bicycle:
llm -m openrouter/moonshotai/kimi-k3 'Generate an SVG of a pelican riding a bicycle'Here's the transcript. It looks like this:
That pelican took 95 input tokens and 16,658 output tokens (13,241 were reasoning tokens), for a total cost of 25 cents!
Since K3 accepts image input I ran it against that rendered SVG above (with my alt text prompt) and got back (for 0.6 cents):
Cartoon illustration of a white pelican wearing a red scarf, riding a red bicycle along a gray road with white dashed lines; the pelican has a large orange beak and webbed orange feet pedaling, with white motion lines behind it; the background shows a light blue sky with white clouds, a yellow sun, two small black birds in flight, and green grass with tiny white flowers in the foreground
What can we learn from the pelican?
My Generate an SVG of a pelican riding a bicycle test is 21 months old now. It was never a particularly great benchmark. It started out as a joke on how absurdly difficult it is to compare these models, but then for the first year it turned out to have a surprising correlation to how good the models actually were.
That connection has been mostly severed now. The GPT-5.6 and Claude Fable 5 pelicans are outclassed by GLM-5.2, and much as I love GLM I don't think that's a Fable-class model.
(I'm still not convinced that labs are training for the benchmark - if they were, I'd expect much better results. There's a chance that Gemini has optimized for any combination of an animal on a vehicle though!)
The biggest limitation of the pelican is that it doesn't touch at all on the thing that matters most for today's model: agentic tool calling and the ability to operate tools reliably as conversations grow in length.
So don't go using pelicans to compare models!
All of that said, I still get a decent amount of value out of running the benchmark myself.
Firstly, it's a forcing function for actually trying the model. If I show you a pelican, that means I've managed to run a prompt through it. If the model has an official API I'll use that, if it's open weight (and small enough to fit a 128GB M5 MacBook Pro) I'll try running it on my own machine, usually via llama.cpp or LM Studio or Ollama. I'll frequently use OpenRouter since that usually provides a proxy to an official API without me needing a new API key.
Most of my pelicans are generated using my LLM CLI tool, which helps encourage me to ensure the latest models are supported by that (via one of its plugins).
More importantly though, even the act of a single prompt to "Generate an SVG of a pelican riding a bicycle" can reveal interesting model characteristics.
Consider the result for Kimi K3 today. Running those simple prompts helped emphasize several points about the model.
- It only has one reasoning effort right now, "max" - and it shows. The model consumed 13,241 reasoning tokens to output 3,417 tokens of response. This is expensive - the pelican cost 25 cents!
- How does the prompt "Generate an SVG of a pelican riding a bicycle" add up to 95 input tokens? OpenAI's tokenizer counts 10, Anthropic's counts 10 for Opus 4.6, 30 for Opus 4.7 and 25 for Sonnet 5/Fable 5. Prompting "hi" to Kimi K3 counted 86 tokens, suggesting there may be an 85 token hidden system prompt. It refused to leak it though.
- Vision works well: the alt text it generated is very good.
K3 currently only has one thinking effort level, but I've been deriving quite a bit of value recently from running the same pelican prompt through different effort levels to get a quick idea for what impact those have. Here's my matrix for the GPT-5.6 model family, for example.
Really though the main things I gain from the pelican test are:
- It's a "hello world" exercise for prompting a model
- A rough cost and reasoning estimate for a simple task
- Confirmation that the model can output valid SVG and has a basic idea of geometry and spatial awareness. This is a much bigger deal for the smaller models that run on my laptop.
- It's still interesting to compare pelicans between releases in the same model family. K3's pelican is a notable improvement from Kimi 2.5.
- It's something I can share that demonstrates I've tried it. Plus a comment with a pelican in it is kind of a tradition on Hacker News at this point, any time I'm late I get comments asking where it is!
You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.
-
🔗 The Pragmatic Engineer The Pulse: What can we learn from Bun’s rapid Rust rewrite with AI? rss
Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics of last week 's The Pulse issue . Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .
Last week in San Francisco, I met Jarred Sumner, creator of JavaScript runtime, Bun, and was keen to learn more about the rewrite of Bun from Zig to Rust. But at the time, Jarred didn't want to say too much, as the tool used for the migration, Fable, was out of action due to the US government imposing export controls.
Jarred and I at Anthropic 's HQ, last week
Fortunately, the situation is now resolved and Fable is available globally, and Jarred has published a detailed post about the project. Before we get into the migration, some context:
Bun is a complex project, with lots of production software depending on it. Bun itself does many things:
- JavaScript, TypeScript and CSS transpiling, minifying and bundling
- A test runner
- A package manager (npm-compatible)
- Other things: module resolution, a WebSocket client, Node.js implementations and many modules
Today, Bun has 22 million monthly downloads, and software like Claude Code and OpenCode depend on it, while hosting providers like Vercel, Railway and DigitalOcean do first-party support for Bun.
Why a rewrite?
Zig is not a memory safe language, and memory-related bugs occurred continuously.**** Jarred lists memory-related bugs in the latest version of Bun: memory leaks, crashes due to memory issues, heap-out-of-bounds writes, and so on. This was after the Bun team patched the Zig compiler to reduce memory-related issues, and put end-to-end memory leak tests in place. As Jarred says:
"Our bugfix list felt bad and I was tired of going to sleep worrying about crashes in Bun. I don't blame Zig for that - other users of Zig don't have the bugs we had, and mixing GC with manually-managed memory is an uncommon enough thing for software to need that no language really designs for it. (...)
For Bun, correctly handling the lifetimes of garbage-collected values and manually-managed values has been a major source of stability issues - most often small memory leaks and occasionally crashes. Every memory allocation has to be meticulously reviewed. Where do these bytes get freed? How do we ensure it only gets freed once? Did we check for JavaScript exceptions properly? Is this garbage-collected pointer visible to the conservative stack scanner? Is this garbage collected memory or manually managed memory?"
Moving to a memory-safe, yet performant language could eliminate such errors, and Rust is one such language that fitted the bill. Jarred:
"A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide."
However, doing a full rewrite on Rust has always been a terrible idea. Or at least, it used to be, because of how unbearably long it would have taken:
There are two problems with rewrites: they take too long, and they take waaaay too long. A dev who has done rewrites probably knows how things tend to go:
- Make an educated guess about how long it will take; say, nine months.
- Nine months later, there's still another ~6 months to go because new functionality is added to the original codebase, and now that new functionality needs to be added in!
- By 15 months in, there's still months left to go for the same reason!
- In the end, you manage to mandate a "feature freeze" for two months and finish the rewrite in ~18 months, if lucky. The original nine-month estimate can end up taking 2+ years.
Jarred likened rewriting Bun in Zig to this:
"Historically, rewrites are a terrible idea. Excluding comments, Bun is 535,496 lines of Zig.
A rewrite in another language would take a small team of engineers a full year.
A year of zero user-facing impact is not a realistic option we could consider. So, enforcement through code-style to fix stability issues was our best bet, and was our plan when we added Rust-inspired smart pointers to Bun's codebase.
But honestly, I didn't want to do it. Homegrown smart pointers offer worse ergonomics than Rust, with none of the guarantees.
What if, instead, I spend a week testing if Anthropic's new model [Fable] can rewrite Bun in Rust?"
Rewriting Bun with Fable
Unsurprisingly, the rewrite was not as simple as typing a prompt like: "Claude, rewrite Bun in Rust. Make zero mistakes." Instead, this is how Jarred did it:
Step #1: Prep work. Three hours of intense prep work with Claude, explained**** Jarred:
"Before writing any code, I spent about 3 hours talking to Claude about how to map patterns from our Zig codebase closely to Rust. Claude serialized this discussion into a PORTING.md document, which ended up on Hacker News [as the Zig -> Rust porting guide]"
This guide is a 600-line file with instructions like:
Ground rules:
- No tokio , rayon , hyper , async-trait , futures. No std::fs, std::net, std::process. Bun owns its event loop and syscalls. (Rust core/std slice, iter, mem, fmt, and core::ffi are fine -- only the I/O-touching modules are banned.)
- No async fn. Everything is callbacks + state machines, same as the Zig.
- Borrow-checker reshaping is allowed. When matching Zig flow yields overlapping &mut, capture the needed scalar (.len(), index) into a local, drop the borrow, then re-borrow. Do NOT reach for raw pointers just to silence borrowck; leave // PORT NOTE: reshaped for borrowck so Phase B diff readers aren't confused.
It's a series of instructions that makes sense to someone who's expert in Rust.If you want to learn more, we cover Rust basics and why Rust is different, with Alice Ryhl.
Step #2: Trial run + adversarial review. Asking Claude to rewrite three files out of 1,448 total number of files. After the rewrite, Jarred ran two separate adversarial reviews with Claude to critique the result, in separate sessions than the one that Claude made the changes in.
Step #3: split up the work across 64 AI agents. Jarred split up the job so that agents worked on files independent from one another, in parallel.
Step #4: iron out issues with the run (~1 day). When Jarred attempted to run all this, agents kept getting in each other's way:
"I asked Claude to loop the workflow on all 1,448 .zig files, and about 2 minutes in, one Claude ran git stash before committing. Another ran git stash pop. And then git reset HEAD --hard. They were stepping on each other! And if I put each Claude into a separate worktree, I would run out of disk space because Bun's git repository is too big and eventually the changes will need to be compiled and seen together.
So, I asked Claude to edit the workflow to instruct Claude to never run git stash or git reset or any git command that doesn't commit a specific file at once. No cargo either. No slow commands at all.
Then, Claude resumed the workflows. And it was working! Too slowly, so I split it into just 4 workflow shards each with their own worktree (4 worktrees total), each running 16 Claudes committing and pushing files."
Step #5: have it run and wait ~2 days. The parallel agents went to work, and completed the rewrite of 535,496 lines of Zig code over the course of two days. Each commit was checked by two adversarial reviews, before being committed.
Step #7: fix ~1,600 compiler errors (~12 hours). The rewrite was completed, but nothing compiled. Going crate-by-crate ('crate' is Rust's concept of a top-level compilation unit), Jarred had Claude fix compiler errors. This alone would be a herculean task for an engineer, but not for Claude :
"Fixing the cyclical dependencies revealed about 16,000 compiler errors. A massive number for 1 human, but not a crazy number for 64 Claude's at once.
To maximize parallelism, the workflow looped over each crate.
- For each crate, run cargo check, group the output by file and save the errors to a file
- Fix all the compiler errors within that crate
- 2 adversarial reviewers for the crate's changes
- 1 fixer applies the fixes"
Visualizing fixing of errors, one by one, done by the agents. Source:Anthropic
The enjoyable thing about this phase of the migration was that the agents ran from midnight until 11:30am, fixing compiler bugs on their own - when Jarred and the team were getting some sleep.
Step #8: run tests locally (~2 days). Bun has a large test suite. The next step was to get these tests to run without compilation errors.
Step #9: get the test suite to pass CI (~3 days). Once the tests were running (and failing), the next step was to fix the code, so that the tests could pass. This took two days.
Step #10: Done in 11 days! After all the tests passed and Jarred verified that everything worked as expected, he merged the changes. The whole process took 11 days, from planning to the finish.
The rewrite: porting ~550K lines of code, in 6,500 commits, over 11 days, with 64 agents
How repeatable is this process?
The rewrite cost a whopping $165,000 with API pricing. With Fable's API prices, the rewrite consumed 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads. Anthropic sells API tokens at a margin as its business, so the cost of the rewrite for it was lower. It's a large amount: the equivalent of the annual base salary for a software engineer at a mid-tier company in the US!
But then again, could have an engineer done all this work in a year? Probably not, and Mitchell Hashimoto says the same:
"On the cost, I think $165,000 at API pricing for Fable (didn't verify) is an incredible deal. There's absolutely no way an engineer with that salary would've been able to achieve the milestones Claude did in 11 days. No way. (Even if you break it down to N engineers paid $165K total in 11 days it doesn't math out)
This does, however, also reconfirm my own biases which is that Fable in particular is most excellent at hard, focused tasks with clear reward functions. I've been tweeting about this recently."
What if AI enables rewrites and migrations that wouldn 't have been considered before? The idea of rewriting Bun in Rust without AI was impractical, admits Jarred:
"By hand, I think this would've taken three engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that. The realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever."
A rewrite or migration taking months or years is why so many of these projects never happen. Let's take aside the cost for a minute and consider this question: if AI can shorten a one-year rewrite to a week: would you do it?
If the answer is "hell, yes:" a blueprint now exists in the form of the Bun migration on how to do it. There are some caveats not detailed in the post, though:
- You need an engineer who is very motivated and knows the codebase very well
- You need an extremely robust test suite, so when the test suite passes, you know it works
- You need to be willing to invest a lot in tokens, not knowing how well it all will work
In fairness, #3 is the weakest point because we know LLMs are pretty good at "mundane" work like code migrations. With a good test suite (#2) and a motivated engineer to iron out things (#1), you'll more likely than not succeed.
The remaining question is how much can be spent. It will likely not be $165K: and costs can be reduced with a simpler project, or by being thoughtful about model usage. For example, do high-level planning with the most expensive model, and cheaper ones for coding and review tasks.
Migrations with AI are surely speeding up, but only when projects are well- engineered like Bun's has been.
Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today's issue covers:
- Grok's CLI uploaded all your local files to the cloud, then got caught.
- New trend: concern about massive increase in code review load.
- Are more devs at enterprises upset about enterprise pricing by AI labs - and does it matter?
- Linux creator: AI "clearly useful."
-
🔗 r/reverseengineering "Remcos RAT – Svchost Injection, API Hooking & Obfuscated Payload Analysis" rss
submitted by /u/StructBreaker
[link] [comments] -
🔗 @binaryninja@infosec.exchange Every superhero needs a Sidekick. Join us tomorrow at 2pm ET to see the mastodon
Every superhero needs a Sidekick. Join us tomorrow at 2pm ET to see the incredible powers of Sidekick 26: https://www.youtube.com/live/S5hAxyopaQk
-
🔗 HexRaysSA/plugin-repository commits sync repo: +1 release, -1 release, ~1 changed rss
sync repo: +1 release, -1 release, ~1 changed ## New releases - [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.7.3 ## Changes - [BinSync](https://github.com/binsync/binsync): - removed version(s): 5.10.1 - 5.15.2: archive contents changed, download URL changed -
🔗 3Blue1Brown (YouTube) But what is cross-entropy? | Compression is Intelligence Part 2 rss
Where the loss function for training LLMs comes from. Job opportunities aligned to this audience: https://3b1b.co/talent Early views and other perks for supporters: https://3b1b.co/support Home page: https://www.3blue1brown.com
Part 1: https://youtu.be/l6DKRf-fAAM
Manim animations by Aaron Gostein and Grant Sanderson NanoGPT animation by Clayton Rabideau 3d black-box model by Paul Dancstep Chess game and Lagrange Multiplier scenes by Nishad Deulkar Music by Vince Rubinetti
Timestamps
0:00 - Language trees and zipping 3:02 - Recap optimal codes 5:20 - Defining cross-entropy 8:26 - Intuition and examples 12:59 - Application to language trees 14:55 - Pre-training LLMs 20:38 - What makes this loss function best? 26:13 - Distillation 30:12 - 3b1b Talent 31:35 - KL Divergence
These animations are largely made using a custom Python library, manim. See the FAQ comments here: https://3b1b.co/faq#manim
Music by Vincent Rubinetti. https://vincerubinetti.bandcamp.com/album/the-music-of-3blue1brown https://open.spotify.com/album/1dVyjwS8FBqXhRunaG5W5u
3blue1brown is a channel about animating math, in all senses of the word animate. If you're reading the bottom of a video description, I'm guessing you're more interested than the average viewer in lessons here. It would mean a lot to me if you chose to stay up to date on new ones, either by subscribing here on YouTube or otherwise following on whichever platform below you check most regularly.
Mailing list: https://3blue1brown.substack.com Twitter: https://twitter.com/3blue1brown Bluesky: https://bsky.app/profile/3blue1brown.com Instagram: https://www.instagram.com/3blue1brown Reddit: https://www.reddit.com/r/3blue1brown Facebook: https://www.facebook.com/3blue1brown Patreon: https://patreon.com/3blue1brown Website: https://www.3blue1brown.com
-
🔗 r/reverseengineering ASUS bsitf.sys (CVE-2026-13585): Arbitrary Physical Memory Mapping 0-day writeup + PoC rss
submitted by /u/watchdogsrox
[link] [comments] -
🔗 r/reverseengineering Reverse-engineering NVIDIA's cuda-checkpoint for faster cold starts rss
submitted by /u/mttd
[link] [comments] -
🔗 r/reverseengineering 🔥 Apkx-Hunter v2.0.0 Released — OWASP MASVS Security Scanning Added! This version introduces **OWASP MASVS (Mobile Application Security Verification Standard)** security scanning with **15 categories** and **166 detection patterns**. rss
submitted by /u/SyscallX-18113
[link] [comments] -
🔗 r/reverseengineering GitHub - joshuapassos/CMF-Watch-Pro-2-BLE-Protocol rss
submitted by /u/JoshuaPassos
[link] [comments] -
🔗 r/reverseengineering First firmware dump of Canon PIXMA TS3451 — AES-GCM manifest encrypted by MatrixSSL Asset Store, looking for help with key derivation rss
submitted by /u/Kertie2_
[link] [comments] -
🔗 Rust Blog Announcing Rust 1.97.1 rss
The Rust team has published a new point release of Rust, 1.97.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.
If you have a previous version of Rust installed via rustup, getting Rust 1.97.1 is as easy as:
rustup update stableIf you don't have it already, you can get
rustupfrom the appropriate page on our website.What's in 1.97.1
Rust 1.97.1 fixes a miscompilation in an LLVM optimization.
We have backported both an LLVM fix and a disable of the underlying change in Rust 1.97.0 of Rust's generated IR that increased the likelihood of this happening. However, note that the underlying miscompilation has been present since at least Rust 1.87.
If you'd like to help us out by testing future releases, you might consider running your code's CI or locally using the beta channel (
rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!Contributors to 1.97.1
Many people came together to create Rust 1.97.1. We couldn't have done it without all of you. Thanks!
-
🔗 Console.dev newsletter Ant rss
Description: Lightweight JS runtime.
What we like: Smaller binary, 100% compatibility, fast package installation. Supports TypeScript with no build step. Includes a VM-isolated sandbox as core functionality with capability-based security.
What we dislike: No docs. Is writing a JS runtime in C a good idea in 2026?
-
🔗 Console.dev newsletter Sätteri rss
Description: Markdown pipeline.
What we like: Compile Markdown to HTML or JS and process it through a plugin-based pipeline. Hook into multiple stages of the compilation process. Uses syntax highlighting with Shiki as an example plugin. Supports various features like frontmatter, math, smart punctuation, GitHub formatting for tables, footnotes, etc.
What we dislike: No support for Svelte SVX.
-
