🏡
  • ↔
  • →
  1. July 26, 2026
    1. đź”— idalib-rs/idalib v0.10.0+9.4.260714 release

      release 0.10.0

    2. đź”— Jeremy Fielding (YouTube) Update On The Bee Chaser and WALL E rss

      Discord 👉https://discord.gg/F3XuyhNRPc New Facebook 👉https://www.facebook.com/profile.php? Instagram 👉 https://www.instagram.com/jeremy_fielding/?hl=en

      If you want to join my community of makers and Tinkers consider getting a YouTube membership 👉 https://www.youtube.com/@JeremyFieldingSr/join

      If you want to chip in a few bucks to support these projects and teaching videos, please visit my Patreon page or Buy Me a Coffee. 👉 https://www.patreon.com/jeremyfieldingsr 👉 https://www.buymeacoffee.com/jeremyfielding

      Social media, websites, and other channel

      Instagram 👉 https://www.instagram.com/jeremy_fielding/?hl=en Twitter 👉https://twitter.com/jeremy_fielding TikTok 👉https://www.tiktok.com/@jeremy_fielding0 LinkedIn 👉https://www.linkedin.com/in/jeremy-fielding-749b55250/ Facebook 👉https://www.facebook.com/profile.php?id=61591852348093 My websites 👉 https://www.jeremyfielding.com 👉https://www.fatherhoodengineered.com My other channel Fatherhood engineered channel 👉 https://www.youtube.com/channel/UC_jX1r7deAcCJ_fTtM9x8ZA

      Notes:

      Technical corrections

      Nothing yet

    3. đź”— r/reverseengineering Reverse engineering my Samsung Odyssey G5 monitor firmware (SPARC V8 scaler, hidden factory menu, dead TCON code) rss

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

    4. đź”— BarutSRB/OmniWM OmniWM v0.5.9 release

      What's New Since 0.5.8

      Breaking Changes — Action Required

      Settings TOML and Rule Fields

      There are no legacy aliases for the following names. Rename them before launching or reloading 0.5.9; old keys are ignored and fall back to defaults.

      • [niri].maxVisibleColumns → visibleContainerCount; the same rename applies in [[monitorNiriOverrides]].
      • singleWindowAspectRatio → singleWindowFit in [niri], [dwindle], [[monitorNiriOverrides]], and [[monitorDwindleOverrides]].
      • [niri].columnWidthPresets → containerPrimarySpanPresets.
      • [niri].defaultColumnWidth → defaultContainerPrimarySpan.
      • [[appRules]].initialColumnWidth → initialContainerPrimarySpan.
      • Single Window Fit value column_width, including the removed column-width and columnwidth aliases, → container_primary_span.
      • Rule CLI flag --initial-column-width → --initial-container-primary-span.
      • Rule IPC JSON field initialColumnWidth → initialContainerPrimarySpan.

      Custom Hotkey Action IDs

      Custom bindings that use the old Niri sizing action IDs are not loaded. Re- create them with the new actions:

      • cycleColumnWidthForward/Backward → cycleSizeForward/Backward.
      • cycleWindowWidthForward/Backward → cycleWindowPrimarySpanForward/Backward.
      • cycleWindowHeightForward/Backward → cycleWindowSecondarySpanForward/Backward.
      • toggleColumnFullWidth → toggleContainerFullPrimarySpan.
      • expandColumnToAvailableWidth → expandContainerToAvailablePrimarySpan.
      • resetWindowHeight → resetWindowSecondarySpan.
      • setColumnWidth.{decrease,increase}10Percent → setContainerPrimarySpan.{decrease,increase}10Percent.
      • setWindowWidth.{decrease,increase}10Percent → setWindowPrimarySpan.{decrease,increase}10Percent.
      • setWindowHeight.{decrease,increase}10Percent → setWindowSecondarySpan.{decrease,increase}10Percent.

      The default Option + ., Option + ,, and Option + Shift + F bindings continue under their new action IDs.

      CLI and IPC Protocol 8

      Upgrade or rebuild omniwmctl, scripts, and third-party IPC clients together with OmniWM. Protocol 7 clients are rejected, old wire names no longer decode, and the sizing commands were renamed:

      • cycle-column-width forward|backward → cycle-size forward|backward.
      • cycle-window-width forward|backward → cycle-window-primary-span forward|backward.
      • cycle-window-height forward|backward → cycle-window-secondary-span forward|backward.
      • toggle-column-full-width → toggle-container-full-primary-span.
      • expand-column-to-available-width → expand-container-to-available-primary-span.
      • reset-window-height → reset-window-secondary-span.
      • set-column-width → set-container-primary-span.
      • set-window-width → set-window-primary-span.
      • set-window-height → set-window-secondary-span.

      IPC raw command names use the corresponding hyphenated forms, such as cycle- column-width-forward → cycle-size-forward.

      Monitor Identities Must Be Re-saved

      OmniWM now binds displays by stable UUID. On UUID-capable displays, v0.5.8 numeric display-ID rows are deliberately preserved but left unbound to avoid attaching settings to the wrong monitor.

      • Run Settings → Monitors → Run Monitor Setup… to re-save custom routing.
      • Re-select and save any per-monitor Workspace Bar, orientation, Niri, Dwindle, or gap overrides in their Settings panes.
      • Re-select the specific display for any explicitly assigned workspace in Settings → Workspaces.

      For hand-edited TOML, monitorDisplayId becomes monitorDisplayUUID in all six per-monitor override arrays, and monitorAssignment.output.displayId becomes monitorAssignment.output.displayUUID for workspace assignments. The UUID cannot be derived safely from the old numeric ID.

      Motion, Portrait Controls, and Saved Restore State

      • OmniWM no longer follows System Settings → Accessibility → Display → Reduce motion. Turn off OmniWM’s own Enable Animations setting if you need motion disabled.
      • Niri navigation, movement, gestures, resizing, and size presets now follow each monitor’s primary and secondary axes. On portrait monitors, directional and sizing behavior therefore differs intentionally from 0.5.8.
      • A v0.5.8 private runtime state containing saved Niri placements cannot be decoded by the new sizing schema. OmniWM rebuilds that state, so remembered window/layout restore placement and other ephemeral app state may reset once after upgrading.

      Portrait-ready Niri

      • Niri now follows each monitor’s effective orientation end to end. Portrait displays scroll vertically, while directional focus and movement, trackpad gestures, resizing, size presets, tabbed containers, animation, reveal, and restore use primary and secondary axes consistently.
      • Settled viewports recover coverage after size changes without disturbing live-resize anchoring, and vertical animation no longer bleeds across containers.

      Guided Multi-monitor Setup

      • A one-time, replayable assistant explains OmniWM’s recommended macOS staircase, identifies displays with on-screen numbers, maps them to the physical desk, and applies custom routing with Mouse Warp.
      • Stable display UUIDs keep new monitor settings, routing, workspace assignments, and restore fingerprints attached through reconnects and runtime display-ID changes.

      Workspace Bar Customization and Polish

      • Choose app-bundled icon variants or custom image files for Workspace Bar apps, globally across monitors.
      • The whole workspace pill is now clickable, the active workspace remains visible when Hide Empty Workspaces is enabled, and narrow centered bars now hug their measured width.

      Easier Controls and Sturdier Window Management

      • Status-menu controls now show rich hover and keyboard-focus help with visual previews.
      • Fixed Chrome PWA focus events and ghost windows left behind after Chrome closes.
      • Hidden and scratchpad windows now receive verified Accessibility parking with retry and cancellation.
      • Workspace moves preserve focus handoff, stopped services keep surfaces cleared, and Niri hidden-window placement and viewport coverage are more reliable.

      Project

      • Added an Education section to recognize contributors whose teaching and research helped shape OmniWM.

      Release Integrity

      • OmniWM-v0.5.9.zip contains the Developer ID signed, notarized, and stapled OmniWM app.
      • OmniWM-v0.5.9.zip SHA-256: a1a3824e95101509ebce557639232c570bda0dc81e7d44c51642a244c076f274
      • GhosttyKit.xcframework-v0.5.9.zip SHA-256: 4e0e56b71489c6605bf8971dddcc873e2b1841a61fbd619f2e0b0a44b7904335
    5. đź”— r/reverseengineering [Open Source] Waypoint - A Ring-0 KMDF Virtual HID Mouse Driver with Lockless Shared-Memory IPC rss

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

    6. đź”— mhx/dwarfs dwarfs-0.15.6 release

      Bug fixes

      • Canonicalizing the mount point path in 0.15.4 fixed a bug on Linux, but introduced a new bug on Windows. With canonicalized paths, WinFsp does no longer allow mounting a DwarFS image unless MountUseMountmgrFromFSD is set to 1 in the registry. The fix is to only perform canonicalization on non-Windows platforms. Fixes GitHub issue #375.

      • Ensure UTF-8 safe number formatting on Windows. DwarFS historically uses char and UTF-8 for anything internally. That doesn't play nicely when it comes to stream formatting, in particular numbers, on Windows. The Linux world has workarounds for this in std::numpunct, but Windows does not and will happily return characters that are invalid UTF-8, which will eventually cause the fmt library to fall over. This change checks if the current locale requires number formatting characters that would end up as multi-byte UTF-8 sequences. If so, it will install a "safe" std::numpunct facet as well as a custom fmt::format_facet. The former will simply turn off fancy number formatting, while the latter will override formatting in the fmt library and use UTF-8 strings instead of single byte characters. This was discovered in the log output from GitHub issue #375.

      Other

      Full Changelog : v0.15.5...v0.15.6

      SHA-256 Checksums

      be22d1ef7e5a044d6f239a6e17d8e203f2226f8381d51c0dd5f2185705f871c3  dwarfs-0.15.6-Linux-aarch64.tar.xz
d0ecfa777f8cae647abbb8ebedd2e8a13fdd7461aba4046be80572202144b825  dwarfs-0.15.6-Linux-arm.tar.xz
914561a02ec1b9902b3256426a6b617210286904e20ca0e4c18b3ac9a5eeba27  dwarfs-0.15.6-Linux-i386.tar.xz
2e049b0d2e6f1adab04e3da3dcf0a17684a464106a16350f1b6c3017602d322e  dwarfs-0.15.6-Linux-loongarch64.tar.xz
0853633a7097e322b397bb760df9399f6deeb7a269e4d3585d3a4258ebce14f6  dwarfs-0.15.6-Linux-ppc64le.tar.xz
88f9a7d81c09be3b211e1b5f4b4f589e15fb7c66e561f24848d06ef54f680383  dwarfs-0.15.6-Linux-ppc64.tar.xz
1474e8ccde21f7d58d73ba641b372c137b17ebc935bb9000b0156e0902577928  dwarfs-0.15.6-Linux-riscv64.tar.xz
a198b4674d90c77543891ba921dd5a6e164706176bded53b4e44bfd110505dd5  dwarfs-0.15.6-Linux-s390x.tar.xz
a73d71ca5a0fe0afae4c096e0c6ab61145e825295e7d269f69e46be44a181374  dwarfs-0.15.6-Linux-x86_64.tar.xz
087b77c1d6a1f253df896b054f95ef17469c63b00be51f4d081633cc8817481c  dwarfs-0.15.6.tar.xz
3a861a2a35c1031da01a30eaed4d9c8031363253d369e7d0f8f999c1b0edbb06  dwarfs-0.15.6-Windows-AMD64.7z
c71ef8090dd419857eb7f3ebfe65c32b73c827269c18e3e0efc98318bae4451f  dwarfs-fuse-extract-0.15.6-Linux-aarch64
709802655dcb9755531956261db0cae4e6e0bcd80b536266b87652a2cd591aa2  dwarfs-fuse-extract-0.15.6-Linux-aarch64.upx
35867c6b436a14e8375fd7ca5bdab6b723a435c700c47377f5d723bacb14f7b5  dwarfs-fuse-extract-0.15.6-Linux-arm
a1b95c4d754e8c79ed3e58fe6ca226befae3ca68beb8bce4ed828a7f6950c864  dwarfs-fuse-extract-0.15.6-Linux-arm.upx
e40e96c490213ee6e8af44a64d41f6929a1510f40c049e46cdf8976e9e4483b1  dwarfs-fuse-extract-0.15.6-Linux-i386
a3dac48b63dd1e0d9158b4407fdfc233782cedbe733a2898dfc0e1da3e26c048  dwarfs-fuse-extract-0.15.6-Linux-i386.upx
5dfdae7452c7579bfad39d6505e8f7ce3f37ebe61d8d353343e813a4f0ffeee8  dwarfs-fuse-extract-0.15.6-Linux-loongarch64
5b23c25260dc49d6ab4278b31b25f0706370b8ad34faf14b6f2546ff0841318a  dwarfs-fuse-extract-0.15.6-Linux-ppc64
a748502b283f1967c5ed44cbac3c03adda066af506ad0999b32512700013ff3b  dwarfs-fuse-extract-0.15.6-Linux-ppc64le
c33786ef9b0a3733e4aa79bd8062e535fdfeed83b5332b8d6cc48830718bd2e4  dwarfs-fuse-extract-0.15.6-Linux-riscv64
da8ea894e7de150473aecf109d5ab0bf4731c5f7d417a030b884e8fe57694ae8  dwarfs-fuse-extract-0.15.6-Linux-riscv64.upx
06d21fc857b4f7998d880791298675e002a24e744c2ccaac8c3e2de200483c56  dwarfs-fuse-extract-0.15.6-Linux-s390x
415f6cce29d5fcb106ce2a12b33d711d0a810a40b1d3f36ce688b4fcaa018674  dwarfs-fuse-extract-0.15.6-Linux-x86_64
b13720b1d75e02db29fa5ca358b96f2a58a8b3641b7d79ea1e90e5aa00ca56e8  dwarfs-fuse-extract-0.15.6-Linux-x86_64.upx
2d513c43ad652163e5e31c1a96f3c736e7e188e661ff62fc9143ea7147bd936b  dwarfs-universal-0.15.6-Linux-aarch64
75d7ccfe6a0fde83942054495c0a6e075556e9a2346fbb9d3052ca8e27b8d7d0  dwarfs-universal-0.15.6-Linux-aarch64.upx
9e411fd7e6827a882052d64c64e4f63e1d02e2aa6a474e7bd7dc28408dbde62d  dwarfs-universal-0.15.6-Linux-arm
f19a01ee5f6a7c08421ba039c64ec5cea9bd8a7c8e6573df97204f690b439f20  dwarfs-universal-0.15.6-Linux-arm.upx
194ad408520706b462c7d89ae3fc14d9f39c4b438017aafb864c5f8d8a542aa3  dwarfs-universal-0.15.6-Linux-i386
94cad5fa18392eeb861ab81fd6fbae3b28cd1e5eaf6007a016bf88952cb7dff0  dwarfs-universal-0.15.6-Linux-i386.upx
16d3d9df8cedcf7690006006f6d994545fa096204e7fc78ef567234026e4fec6  dwarfs-universal-0.15.6-Linux-loongarch64
cfd7dd8dcada898d4f4f94bcf671596fd868dd043f00d47fd394e633444dcf37  dwarfs-universal-0.15.6-Linux-ppc64
2b71960672c108e413ef473b8a726feb858782ff3c9c28b6f4616e10097b0452  dwarfs-universal-0.15.6-Linux-ppc64le
b20be0530cbf1662d6b9e5ba27a57537e3bf50f90cdd6bb7922327b62f5f9417  dwarfs-universal-0.15.6-Linux-riscv64
69aa2b820f77ca226b78c54cb3962a67039d1da7e9072b989ec73cf653b1b032  dwarfs-universal-0.15.6-Linux-riscv64.upx
5b36eceaf673f50da90d858d49d87139783ee3fb5acd504c44574103adf56f2a  dwarfs-universal-0.15.6-Linux-s390x
50891c38ba359db8271819a6cbf6aaa8068681523f0c4f2b8242007a45edaa28  dwarfs-universal-0.15.6-Linux-x86_64
8cba2be06f0dd8ce1396a2ada5777d97d24d4dc561ca9eb816207703757a4959  dwarfs-universal-0.15.6-Linux-x86_64.upx
bfbc70e4dc060cf4f1b799bb3af6e31808495e993dbcacc7dbc5cf45776c49f4  dwarfs-universal-0.15.6-Windows-AMD64.exe
ad83d23655b98d4baa802e1c0e52f00082a43bee4586f237f2239ec3633b7815  dwarfs-universal-small-0.15.6-Linux-aarch64
a044c91667d8f0060ddc1fd8e5e5bce7b8f84f6f0c90e819a780434972354d61  dwarfs-universal-small-0.15.6-Linux-aarch64.upx
539249b247b3c24a4fb44f60fa9825aaea47288a051998b8d038508fdf0103d1  dwarfs-universal-small-0.15.6-Linux-arm
bdca6720331aad331b9f2c75c115562ec7b1a41e3636fa2bec773421d8b83fc9  dwarfs-universal-small-0.15.6-Linux-arm.upx
afd622ea87f3a0c540e0e513037cf1f5bb63103da3a0a5ba849ff2a401fc7d5e  dwarfs-universal-small-0.15.6-Linux-i386
fa39ce4b1303a48353bbf407f420ff274d7ba33179fa3c9513c62ac6556bb607  dwarfs-universal-small-0.15.6-Linux-i386.upx
4fe920480b23c83602f8cbe1a5faa1e9eed325cfdb478c42cf70b7b66e48fdc9  dwarfs-universal-small-0.15.6-Linux-loongarch64
d80476b302b5dada5d271ff5a7e1541c608abd07e05140df26a2530fd87f1304  dwarfs-universal-small-0.15.6-Linux-ppc64
85a391ec61ea40f40a42d52f061dd88df2f6e7d9ccf8e6d5f8c12d2a288726c2  dwarfs-universal-small-0.15.6-Linux-ppc64le
80abd9830c3fb9365a979c0a1a9f2a1724f38a74cec1c2a8fb91ad6d288a9a9b  dwarfs-universal-small-0.15.6-Linux-riscv64
efdb3c951080a0274b0a6647e1137e90c6443691017340701d355c499496ce74  dwarfs-universal-small-0.15.6-Linux-riscv64.upx
5ea8f5f9541aff2d599d7e5e1537a2da4f30ad7a82fc52be9baec9c8e72592c6  dwarfs-universal-small-0.15.6-Linux-s390x
34c07feff376458a3da11c2b22da5f553d51153b4c8308628af0133ea9bca6d5  dwarfs-universal-small-0.15.6-Linux-x86_64
d31695e1d8a85750e18c845c038d433f3387aa728673294b0b7b0f1739cdd950  dwarfs-universal-small-0.15.6-Linux-x86_64.upx
    7. đź”— @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up here: https://v35.us/dn6rcg5

    8. đź”— @binaryninja@infosec.exchange Our 10-year anniversary giveaways continue! Today, 1 very lucky winner will mastodon

      Our 10-year anniversary giveaways continue! Today, 1 very lucky winner will receive free entry to our Intro To Binary Ninja online training class. Make sure you’re subscribed to our newsletter to be entered: https://binary.ninja/10years

  2. July 25, 2026
    1. đź”— IDA Plugin Updates IDA Plugin Updates on 2026-07-25 rss

      IDA Plugin Updates on 2026-07-25

      New Releases:

      Activity:

      • ffxiv_bossmod
      • ida-multi-mcp
        • 2ac155a0: Merge pull request #30 from MeroZemory/feat/compat-guards
        • d93de799: fix: pin UTF-8 on every text file we read or write
        • 6f95cbef: docs(analysis): stop presenting the completion flag as a latch
        • c047d64d: fix(analysis): make analysis_wait honour its timeout, and stop pinnin…
        • 66063dd0: docs: split reference material out of the README
        • 7d9054c3: fix(router): keep the analysis warning on truncated results
        • 1798b2f3: feat(mcp): tell the agent to gate on auto-analysis, in three places
        • 09b8c6ba: feat(analysis): make auto-analysis completion detectable, and fix the…
        • 8dff433e: docs: collapse reference sections and drop the AmpCode example
        • 88fd6c54: fix(compat): shim the IDA APIs that moved, and fix infer_types on 9.x
        • 5ec6bb48: Merge pull request #29 from MeroZemory/docs/readme-modernize
        • 3a72c628: docs: modernize README and correct the tool-count claims
        • f0cae87d: Merge pull request #28 from MeroZemory/feat/native-cancellation
        • 9cea4c13: feat(sync): make the native-cancel grace window configurable
        • 4bcb6126: feat(sync): fire ida_kernwin.set_cancelled() at the tool deadline
        • 476748ca: Merge pull request #27 from MeroZemory/perf/concurrent-stdio-dispatch
        • bcad0482: perf(router): dispatch stdio requests concurrently
      • IDAPluginList
        • cef538dc: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • Luc-Nhan
    2. 🔗 r/reverseengineering CFP Open – Looking for Technical AI & Security Research for Après-Cyber Slopes Summit 2027 rss

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

    3. đź”— @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up here: https://v35.us/dn6rcg5

    4. 🔗 @binaryninja@infosec.exchange It’s day 3 of our 10-year anniversary celebration! Today, 3 winners will each mastodon

      It’s day 3 of our 10-year anniversary celebration! Today, 3 winners will each receive a Binary Ninja Journey bottle! Newsletter subscribers are automatically entered. Check out full list of giveaways: https://binary.ninja/10years

    5. đź”— Anton Zhiyanov Solod 0.3: Concurrency, JSON, more safety rss

      Solod (So) is a subset of Go that translates to regular C — with zero runtime, manual memory management, and source-level interop. It's designed for two main audiences:

      • Go developers who want low-level control without having to learn another language.
      • C developers who like Go's style.

      At the end of the v0.2 post, I said the obvious goal for the next release was concurrency, along with the stdlib packages that support it. That's what v0.3 is about. So now has threads, channels, worker pools, mutexes, and atomics — enough tools for parallel data processing or handling network connections.

      This release also adds a streaming JSON package, a bunch of safety checks (escape analysis, leak checking, nil-pointer panics, stack traces), and proper so test and so bench commands.

      Threads • Channels • Worker pools • Sharing state • JSON • Safety net • Tooling • Wrapping up

      Threads The new conc package is the foundation. It provides real OS threads, backed by pthreads. If you're familiar with Go's goroutines, the code will look similar — but there are some important differences. // greet prints a label three times. func greet(arg any) any { from := arg.(string) for i := range 3 { println(from, "->", i) } return nil } func main() { // Run greet on a separate OS thread, concurrently with main. name := "thread" th := conc.Go(greet, name) // Wait blocks until the thread finishes. th.Wait() println("done") } thread -> 0 thread -> 1 thread -> 2 done Solod doesn't support closures, so conc.Go takes a function and an any argument, instead of just a func() like you'd expect in Go. Other important differences: starting an OS thread isn't free, and you always have to Wait on it (or Detach it), or it will leak. That makes conc.Go a good fit for a small, fixed number of long-lived threads — but not for thousands of short-lived tasks. For those cases, it's better to use a pool (shown below). Channels Threads in Solod communicate with each other through channels, like goroutines in Go. A channel carries values of a specific type. By default, sending or receiving on a channel blocks until both sides are ready, so a channel also works as a synchronization point. // ping sends a single message on the given channel. func ping(arg any) any { messages := arg.(*conc.Chan[string]) messages.Send("ping") return nil } func main() { // An unbuffered channel (buffer size 0): each send blocks // until a receiver is ready to take the value. messages := conc.NewChan defer messages.Free() // Launch a thread that sends "ping" into the channel. th := conc.Go(ping, &messages) defer th.Wait() // Receive the message and print it. var msg string messages.Recv(&msg) println(msg) } ping A couple of So-specific moments here. When you create a channel, you give it an allocator (mem.System in this case), and you call Free when you're done with it. Also, Recv writes to a pointer you pass in, instead of returning the value directly. It returns a bool, which is false when the channel is closed and empty. So, a typical for msg := range ch loop in Go becomes for ch.Recv(&msg) { ... } in Solod. Allocators are a key concept in Solod. The language doesn't allow hidden heap allocations, so any function that needs to allocate memory must take an allocator (the mem.Allocator interface) as its first argument. Buffered channels can hold a limited number of values without having a receiver ready — just pass a non-zero size with NewChan. If you don't want to block forever, use RecvTimeout or SendTimeout with a duration. They return conc.Ok or conc.Timeout instead of getting stuck. Worker pools

      Threads are expensive, so spawning one per task doesn't scale. For handling many short-lived tasks, use conc.Pool: it uses a fixed number of worker threads that take tasks from a queue.

      // job holds input and the result.
type job struct {
    id     int
    result int
}

// process handles one job.
func process(arg any) {
    j := arg.(*job)
    time.Sleep(100*time.Millisecond)
    j.result = j.id * 2
}

func main() {
    // A pool of 4 worker threads. Each submitted job is handled
    // by the next available worker.
    pool := conc.NewPool(mem.System, conc.PoolOptions{NumThreads: 4})
    defer pool.Free()

    // Submit 8 jobs. Each writes into its own struct, so keep
    // the structs alive in a slice until the jobs finish.
    start := time.Now()
    jobs := make([]job, 8)
    for i := range jobs {
        jobs[i].id = i + 1
        pool.Go(process, &jobs[i])
    }

    // Wait until all submitted jobs have finished.
    pool.Wait()

    for i := range jobs {
        println("job", jobs[i].id, "->", jobs[i].result)
    }
    elapsed := time.Since(start) / 1_000_000
    println("took", elapsed, "ms")
}



job 1 -> 2
job 2 -> 4
job 3 -> 6
job 4 -> 8
job 5 -> 10
job 6 -> 12
job 7 -> 14
job 8 -> 16
took 200 ms

      pool.Wait() works similar to Go's WaitGroup.Wait — it blocks until all submitted jobs are finished. This program takes about 200 ms to run (even though there's 800 ms of total work), because 4 workers run concurrently.

      You might think OS threads are much slower than Go's goroutines, but for pools, that's not the case. On realistic workloads, conc.Pool is usually only about 10% slower than Go, whether the tasks are CPU-bound or waiting on I/O. Channels are a different story: handing off work between threads requires a kernel wakeup, while Go does this in user space, so it can be several times slower. Check out Go-flavored concurrency in C for more details.

      Sharing state One way to share state in Solod is by using channels to communicate it. However, sometimes you just need a shared counter or a lock. For that, the new release introduces the sync and sync/atomic packages. Here's an example of an atomic counter being updated by 50 tasks running on 4 threads: // increment atomically increases the shared counter 1000 times. func increment(arg any) { ops := arg.(*atomic.Uint64) for range 1000 { ops.Add(1) } } func main() { // An atomic value is safe for concurrent reads and writes. var ops atomic.Uint64 pool := conc.NewPool(mem.System, conc.PoolOptions{NumThreads: 4}) defer pool.Free() // 50 tasks, each incrementing the counter 1000 times. for range 50 { pool.Go(increment, &ops) } pool.Wait() println("ops:", ops.Load()) } ops: 50000 A regular int incremented with ops++ would cause a data race and give a different result each time. Here, the result is exactly 50,000 on every run, thanks to the atomic Uint64 counter. The atomic package provides Int64, Uint64, Bool, and Pointer[T] types, all of which are lock-free and safe for concurrent use. For anything more complex than a counter, use sync, which provides Mutex, Cond (a condition variable), and Once (runs a function exactly once). One thing to watch out for: unlike Go, a So mutex's zero value isn't ready to use — you need to Init it before locking and Free it when done. var mu sync.Mutex mu.Init() defer mu.Free() mu.Lock() defer mu.Unlock() // ... critical section ... JSON Go's encoding/json relies on reflection to marshal arbitrary structs. Solod has no reflection, and uses a different approach: a token-level API. You read and write one JSON token at a time, and the Encoder and Decoder types take care of the syntax — adding commas and colons, checking UTF-8, and rejecting bad input. Encoding is done through a series of calls that match the structure of your document: out := make([]byte, 256) sb := strings.FixedBuilder(out) enc := json.NewEncoder(&sb) enc.BeginObject() enc.Str("name") enc.Str("Alice") enc.Str("age") enc.Int(25) enc.EndObject() enc.Flush() println(sb.String()) {"name":"Alice","age":25} Decoding pulls one validated token at a time with Next. You can check each token with Kind and read its value using typed getters like Str, Int, or Bool: src := `{"name":"Alice","age":25}` dec := json.NewDecoder(mem.System, []byte(src)) defer dec.Free() var name string var age int64 dec.Next() // the opening { for dec.Next() && dec.Kind() == json.KindString { switch dec.Str() { case "name": dec.Next() name = dec.Str() case "age": dec.Next() age = dec.Int() default: dec.Next() dec.Skip() } } println(name, age) Alice 25 This is a simplified example that works only because the decoder doesn't allocate any memory. In a real-world situation, you'd need to use an allocator. The decoder works the same way whether you're using an in-memory document (NewDecoder) or reading from a stream with an io.Reader (NewReader). This means you can decode data directly from a source without having to buffer the entire message first. Both the encoder and decoder use minimal memory and will reject invalid JSON or non-UTF-8 strings. As you can see, API is low-level and not nearly as ergonomic as it is in Go, especially when it comes to decoding. But on the bright side, it's 10 times faster and almost doesn't allocate, unlike in Go. Safety net Solod compiles to plain C, which is fast but not very forgiving: if you use an out-of-bounds index, dereference nil, or divide by zero, you get undefined behavior that could crash the program or silently give wrong results. The new release addresses some of these issues. Escape analysis. Returning a pointer to a stack-allocated value is a classic C footgun. So now catches the common cases at compile time: type Point struct{ x, y int } func newPoint(x, y int) *Point { return &Point{x: x, y: y} // ^ compile-time error: stack-allocated // value escapes function frame } func main() { p := newPoint(3, 4) println(p.x, p.y) } so run: /tmp/sandbox/main.go:26:12: stack-allocated value escapes function frame return &Point{x: x, y: y} ^here (exit status 1) While the escape analyzer doesn't catch every case, it's still quite useful in practice. I actually found a couple of dangling pointers in the standard library code with it, even though I was sure there weren't any. Leak detection. Solod has no garbage collector, so a forgotten Free is a real memory leak. mem.Tracker helps catch these leaks: it wraps an allocator and keeps track of every allocation and free that goes through it. This way, you can monitor the program's memory usage in real time instead of guessing. Wrap mem.System once, allocate memory through the tracker, and have a background thread log the stats at regular intervals: // monitor periodically logs live allocation stats. func monitor(arg any) any { t := arg.(*mem.Tracker) for { time.Sleep(100 * time.Millisecond) s := t.Stats() println("live:", s.Mallocs-s.Frees, "allocations,", s.Alloc, "bytes") } return nil } func main() { // Wrap the system allocator to count every allocation and free. heap := &mem.Tracker{Allocator: mem.System} // Watch memory from a background thread. conc.Go(monitor, heap).Detach() // Allocate through heap so the monitor sees it. for i := range 10 { v := mem.Alloc // intentionally not freeing it *v = i time.Sleep(50*time.Millisecond) } // ... } live: 2 allocations, 16 bytes live: 4 allocations, 32 bytes live: 6 allocations, 48 bytes live: 8 allocations, 64 bytes live: 10 allocations, 80 bytes The tracker is lock-free and only uses a few atomic operations for each allocation, so it's cheap enough to keep enabled in production. Nil-pointer panics. If you try to dereference a nil pointer, it will cause a panic at runtime instead of a raw segmentation fault: type Rect struct{ width, height int } func (r *Rect) area() int { return r.width * r.height // ^ runtime error: nil pointer dereference } func main() { var r *Rect println(r.area()) } panic: nil pointer dereference Stack traces. When a program panics, the -panic flag controls what happens next: so run -panic=trace . # print a stack trace, then exit(1) - the default so run -panic=exit . # just exit(1) after the message so run -panic=abort . # raise SIGABRT for a debugger or core dump Stack trace frames represent each function in the call chain: func main() { Work() } func Work() { res := Calc(42) println(res) } func Calc(x int) int { if x == 42 { panic("can't handle 42") } return x * 2 } panic: can't handle 42 /tmp/solod_build764532392/main.c:27 (func main_Calc) /tmp/solod_run1106942066(main_Calc+0x51) /tmp/solod_run1106942066(main_Work+0x12) /tmp/solod_run1106942066(main+0x9) The same system handles assertions like slice bounds, index-out-of-range, c.Assert, and similar checks. Instead of calling C's assert, they panic in a way that respects the -panic flag. There's also a new -sanitize flag that enables C sanitizers (address and undefined by default) to help you catch more issues during development: so run -sanitize -panic=abort example/play Tooling

      'so test' and 'so bench'. Solod now has built-in test and benchmark runners. so test finds TestXxx(t *testing.T) functions in a package's test subdirectory, creates a runner, transpiles it, and runs it. so bench does the same for BenchmarkXxx(b *testing.B).

      A typical package layout with tests and benchmarks looks like this:

      so/uuid
├── bench
│   ├── main.go
│   └── uuid.go
├── test
│   ├── main.go
│   └── uuid.go
└── uuid.go

      There's also a quick check for memory leaks: t.Allocator() gives you a tracking allocator (described in the 'Safety net' section above), and the test will fail if anything allocated with it isn't freed by the end of the test.

      === RUN   TestAlloc
    memory leak: 1 unfreed allocation(s), 16 byte(s)
--- FAIL: TestAlloc

      Fuzzing. Since Solod is a strict subset of Go, any So package is also a valid Go package. This means you get Go's built-in fuzzer for free, making fuzz testing pretty easy. So's encoding/json package takes advantage of this by using Go's own encoding/json as an oracle, making sure that every JSON document accepted by So is also accepted by Go.

      Automatic linking. The new so:link directive lets a package specify which C library it needs, and so build gathers these libraries and passes them to the C compiler. The standard packages already use the new directive, so importing so/math links with -lm, and so/sync or so/conc links with -lpthread — you no longer have to set LDFLAGS manually.

      Wrapping up

      With v0.3, Solod reaches an important milestone: a program can now do multiple things at once. The JSON package gives programs a standard way to communicate, and the safety checks help prevent silent failures — both during development and in production.

      There's still a lot to do, of course. In the next release, the standard library will keep growing, and the language and tooling will get better to make programming in So more convenient and safe.

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

    6. đź”— modem-dev/hunk v0.17.6 release

      What's Changed

      • Avoid loading OpenTUI’s embedded native library for headless commands, preventing temporary native-library artifacts from leaking during help, version, session, daemon, markup, and non-interactive pager operations by @benvinegar in #590
      • Optimize terminal cell-width measurement for faster rendering of diffs containing CJK, emoji, and other wide characters by @kazu728 in #586
      • Republish the 0.17.5 application changes as 0.17.6 with downloadable binaries for every supported platform by @benvinegar in #593

      Full Changelog : v0.17.4...v0.17.6

    7. đź”— pydantic/pydantic-ai-harness v0.11.0 (2026-07-24) release

      What's Changed

      Full Changelog : v0.10.0...v0.11.0

    8. đź”— Filip Filmar Fuchsia Internals: A New Report Series for Hardware Engineers rss

      I have been writing a set of technical reports on the internals of Fuchsia, Google’s capability-based microkernel operating system, aimed squarely at electrical, RTL, and FPGA engineers rather than at kernel hackers. This post kicks off a series in which I walk through the reports one volume at a time, roughly one a month. The whole set is a fourteen-volume reference; the complete PDF is linked at the bottom of this post, and each future post will take one volume and put its PDF in front of you.

  3. July 24, 2026
    1. đź”— IDA Plugin Updates IDA Plugin Updates on 2026-07-24 rss

      IDA Plugin Updates on 2026-07-24

      New Releases:

      Activity:

      • augur
        • 043ba9cb: ci: set dependabot cooldown to 10 days
        • b9a59184: ci: add zizmor action
        • c4ef72c6: ci: add dependabot cooldown
        • 820baa96: ci: remove unnecessary submodules from doc workflow
        • 92b5f497: Merge pull request #2 from 0xdea/dependabot/cargo/anyhow-1.0.104
        • 5d82557b: Merge pull request #3 from 0xdea/dependabot/github_actions/actions-de…
        • 16609f77: ci: bump the actions-dependencies group with 3 updates
        • 1cdd3421: chore: bump anyhow from 1.0.103 to 1.0.104
        • 6e7f17c9: ci: add cargo-audit and dependabot config
      • capa
        • c1e7510d: build(deps): bump ws from 8.17.1 to 8.21.1 in /web/explorer (#3126)
        • cce0431d: Sync capa-testfiles submodule
        • 0683946f: Sync capa rules submodule
        • 04170f01: Sync capa rules submodule
        • db309bc2: Merge pull request #3131 from mandiant/dependabot/npm_and_yarn/web/ex…
        • 9cec0cd3: Merge pull request #3130 from mandiant/dependabot/npm_and_yarn/web/ex…
        • dafe1a7a: build(deps): bump pyasn1 from 0.6.3 to 0.6.4 (#3129)
        • 23ab04c6: build(deps): bump postcss from 8.5.15 to 8.5.23 in /web/explorer
        • 1561d891: build(deps-dev): bump js-yaml from 4.2.0 to 4.3.0 in /web/explorer
        • 4dd9274d: build(deps): bump python-flirt from 0.9.2 to 0.10.0 (#3128)
        • 5fe45bb9: build(deps-dev): bump mypy from 2.1.0 to 2.3.0 (#3127)
      • disrobe
        • 05b7022b: native: decode aarch64 scalar float and double registers, moves, load…
        • 6fd9f9da: native: reject an aarch64 high-half multiply whose operands are not 6…
        • e4c74f58: native: decode aarch64 rbit so trailing-zero count recovers, and reco…
        • a3369ef7: native: decode aarch64 rev, clz, umulh and bfi so byte-reverse, leadi…
        • 1d72b8d3: native: lift the aarch64 64-bit d-register post-index vector load and…
        • 05401791: native: recover the aarch64 vector lane insert as a read-modify-write…
        • 3324488b: native: rustfmt the recovery probe test
        • 23c61865: native: track the aarch64 recovery corpus, its clang generator, a non…
        • b4b42c63: native: recover the aarch64 conditional compare so a branchless short…
        • 647f99eb: native: recover the aarch64 signed-overflow condition so an adds-set …
        • 46ea21d0: native: lift the aarch64 sign-extended register add so a 32-bit index…
      • ffxiv_bossmod
      • haruspex
        • 89c46d0c: ci: set dependabot cooldown to 10 days
        • 0031da21: ci: add zizmor action
        • b90f9715: ci: add dependabot cooldown
        • 91965cc4: Merge pull request #6 from 0xdea/dependabot/cargo/thiserror-2.0.19
        • cb0d1c51: Merge pull request #4 from 0xdea/dependabot/cargo/anyhow-1.0.104
        • 908df22b: Merge pull request #5 from 0xdea/dependabot/github_actions/actions-de…
        • c28e3f8c: chore: bump thiserror from 2.0.18 to 2.0.19
        • 8bf08534: ci: bump the actions-dependencies group with 3 updates
        • d156dd20: chore: bump anyhow from 1.0.103 to 1.0.104
        • 15f19b8a: Create dependabot.yml
        • c38ef554: ci: add cargo-audit and dependabot config
      • ida-pro-mcp
        • 9236fc62: Merge pull request #478 from NeKroFR/fix/476-stale-strings-cache
        • 060d15d3: Merge pull request #488 from Zzoomrus/fix/idalib-sigterm-deadlock
        • b3cb7e5c: ci: allow approved fork PR checkout
        • 492a569f: fix(idalib): avoid SIGTERM/SIGINT handler deadlock in idalib_server
      • ida-pro-mcp
        • c798aee1: Make blackboard updates merge evidence under a write lock.
        • 8eebb592: Bind truncation tokens to the owning MCP connection.
        • 0ef263f8: Require risk_ack on mutating ops and expose session health.
      • IDAPluginList
        • 3f2bc811: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • mcrit-plugin
        • fa5fc331: defer MCRIT GUI imports until form use
      • rhabdomancer
        • 8d0eb6b0: ci: set dependabot cooldown to 10 days
        • 64438a26: ci: add zizmor action
        • cb6b13f8: ci: add dependabot cooldown
        • 5eb6bc90: Merge pull request #3 from 0xdea/dependabot/cargo/anyhow-1.0.104
        • 82036e63: Merge pull request #4 from 0xdea/dependabot/cargo/serde-1.0.229
        • 9945395b: Merge pull request #5 from 0xdea/dependabot/github_actions/actions-de…
        • c77c52d3: ci: bump the actions-dependencies group with 3 updates
        • 1edb0ded: chore: bump serde from 1.0.228 to 1.0.229
        • c5ebc34e: chore: bump anyhow from 1.0.103 to 1.0.104
        • fa95ed1a: ci: add cargo-audit and dependabot config
      • twdll
        • 79888454: docs: generate docs
        • 2432cdd3: fix: cleanup for proper import of twdll
        • 95cfc438: tools: set cpu affinity for win11
    2. 🔗 r/reverseengineering Reverse-engineered CME's undocumented USB-MIDI config protocol (U6MIDI Pro / U2MIDI Pro) off the wire — full byte map + a public-domain codec rss

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

    3. đź”— modem-dev/hunk v0.17.5 release

      chore(release): add 0.17.5 benchmark snapshot

    4. đź”— r/reverseengineering Fortinet ppl bypass rss

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

    5. đź”— 3Blue1Brown (YouTube) The 64 sugar cubes puzzle rss

      See all monthly puzzles: https://momath.org/mindbenders/

    6. 🔗 r/reverseengineering The quirks of CPU extended mode in “Comanche: Maximum Overkill” (1992) rss

      submitted by /u/alberto-m-dev
      [link] [comments]

    7. đź”— r/reverseengineering Workshop map for MECCHA CHAMELEON is a malware dropper (full breakdown) rss

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

    8. 🔗 r/reverseengineering Escaping Claude Cowork’s local VM sandbox via CVE-2026-46331 rss

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

    9. đź”— @binaryninja@infosec.exchange Last chance to register for our Firmware Reverse Engineering class next week! mastodon

      Last chance to register for our Firmware Reverse Engineering class next week! Some embedded architectures are completely unlike what we're used to from x86, ARM, or MIPs, and we want you to know about them: https://shop.binary.ninja/products/fre- july-26

      https://www.youtube.com/shorts/0AQPnGtivko

    10. đź”— New Music Releases Above & Beyond - One Mix with Above & Beyond rss

      Above & Beyond - a new release is available:

      • 2026-07-24: One Mix with Above & Beyond (Album)

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

      Visit muspy for more information.

    11. đź”— New Music Releases The Revivalists - Get It Honest rss

      The Revivalists - a new release is available:

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

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

      Visit muspy for more information.

    12. đź”— New Music Releases The HU - Hun rss

      The HU - a new release is available:

      • 2026-07-24: Hun (Album)

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

      Visit muspy for more information.

    13. đź”— Armin Ronacher Codeberg Divides rss

      Codeberg recently changed its terms to exclude projects that are largely written with generative AI. Since I want GitHub to face competition I have thoughts.

      Codeberg is entirely within its rights to do this. It is an association with members and a democratic process, and that process produced a result. But democracy is a way of making a decision, not a guarantee that the decision is inclusive, wise, or even good for the people already depending on it. A majority can still decide that certain projects and people no longer belong.

      GitHub's governance has never been democratic and there is plenty about the platform that I dislike. Yet democracy is not the main property I need from infrastructure. I need it to be predictable, dependable, and reasonably neutral towards the legal Open Source software hosted on it. A democratic provider without a clear constitution can be worse at those things than a corporation.

      The actual wording makes this more difficult. The terms prohibit projects that mostly consist of code written by generative AI tools. In an actively developed codebase, what does "mostly" mean, and who can still tell? I could not reliably assign authorship percentages to many of my own recent projects. The line is open to interpretation precisely where it needs to be enforceable. In practice the center will probably lose out, as it has a bias.

      A harsher line would probably be preferable. If Codeberg wants no LLM involvement, it should say so. If it wants to prevent autonomous repository spam and abusive resource consumption, it should write rules for those instead. The current middle ground delegates too much of the policy to moderators and community norms. I'm currently assuming the community around it draws a much harsher social boundary, making projects and maintainers unwelcome even when they technically comply.

      It is a real shame that the Open Source and Free Software communities are splitting this deeply over LLMs and agents. There are serious questions about copyright, labor, energy use, slop, and maintainers drowning in generated contributions. But these tools are also becoming part of how software is made. The Open Source world needs to figure out how to engage with that future, not just divide into camps. More importantly, LLMs if done and used well, should be welcome to all of us. They could be used to reclaim control and power, away from large corporations and institutions.

      As I mentioned before, I want GitHub to face true competition in the Open Source space. I would particularly like some of it to come from associations rather than another large corporation. As a European project, Codeberg naturally matters to me even more. It can choose to be a smaller community with a stronger political identity, but that is a different ambition from being a broad and dependable European alternative to GitHub.

      I wish Codeberg were more forward-looking here: willing to host the Open Source software of tomorrow, not only software made in the ways its community approves of today. It has every right to make the choice it made, but I just do not think it is a good one.

    14. đź”— exe.dev tailmix: Connect to Multiple Tailnets at Once rss

      Tailscale is one of those magical technologies that I can no longer imagine living without. Its use cases range from homelab setups to enterprise workloads spread across complex, disparate environments. At exe, we use it to connect much of our internal infrastructure.

      That said, there are points of friction. One of my pet peeves is having to switch tailnets whenever I want to briefly connect to Home Assistant or Frigate to see who’s at the door while working on exe’s infrastructure. Tailscale’s fast user switching helps, but switching still disconnects one tailnet before connecting the other. That disrupts existing connections, takes a few seconds, and requires me to remember to switch back.

      Why can’t I just be connected to multiple tailnets at the same time?

      A few technical complications make it tricky, starting with the fact that Tailscale allocates IPv4 addresses independently within each tailnet. This means two nodes in two different tailnets can end up with the same IPv4 address. If both tailnets were connected simultaneously, the address alone wouldn’t tell the client which node I intended to reach.

      I could disable IPv4 and use IPv6 exclusively, but that still doesn’t work everywhere. It’s getting better, but the long tail is, well, long. Disabling IPv4 requires updating the Tailscale policy file and passing some pain along to my teammates, which feels unjustified.

      Node sharing has similar challenges. Tailscale does the work of making sure those IPs don’t collide, but it requires that I be an admin on both tailnets, and I’d have to individually share every device I wanted to reach. As my kid is fond of saying: I don’t want to!

      A couple of weeks ago, I wondered whether I could have an agent write me a new Tailscale client that would let me connect to multiple tailnets at once. As usual, I spun up a new VM on exe and told Shelley about my problem, and we went back and forth on the design until I was convinced the solution would work for the vast majority of use cases.

      The solution was fairly straightforward: spin up a couple of tsnet.Server instances, put them behind a single TUN interface, assign each peer node in each tailnet a new IPv4 from a locally configured pool such as 10.58.0.0/16, and hijack MagicDNS to return those IPs. Traffic sent to one of them is then routed through the corresponding tailnet.

      It worked the first time I tried it. All of the Tailscale policies worked just as they should, and I didn’t have to implement any of that, as the upstream tsnet.Server is a full-fledged Tailscale client already.

      The result is tailmix, an independent, open-source client that lets one machine connect to multiple tailnets simultaneously. The source, installation instructions, and current limitations are all in the repository—or you can ask Shelley to tell you all about it.

      I still have two tailnets, two identities, and two separate sets of policies. The difference is that now my laptop no longer makes me choose between them.

  4. July 23, 2026
    1. đź”— IDA Plugin Updates IDA Plugin Updates on 2026-07-23 rss

      IDA Plugin Updates on 2026-07-23

      New Releases:

      Activity:

      • augur
      • binsync
        • 0b1b449b: Allow the server to correctly track which users are connected. (#519)
      • DeepExtractIDA
        • 7dbdbbb7: Add v3 schema (function addresses, imports/globals tables, EA-prefixe…
      • disrobe
        • e9361488: harden pyfreeze parser fuzz coverage
        • 313fddfc: native: keep sign and zero extended aarch64 indexes out of array aggr…
        • 34009fa0: native: model aarch64 sign and zero extended 32-bit index registers s…
        • b40470b6: harden scriptlang parse paths
        • b1ac85f9: native: decode aarch64 scaled register-index addressing [base, xindex…
        • 315fa0aa: native: accept aarch64 bitmask and move immediates above the signed r…
        • c56a8857: native: decode aarch64 umull and smull as 32-by-32 into 64 widening m…
        • 5a959c91: native: decode the aarch64 vector bic as an elementwise and-not
        • 43c12a25: harden py disasm fuzz paths
      • haruspex
        • ae585c22: test: improve unit test names
      • hrtng
        • 59dba8e5: - autorename: revert "ignoring nice names"
      • ida-hcli
        • c80e825c: fix: address install script review findings
        • d9d446a0: fix: use direct GitHub download URLs in install script
        • 87aa5b36: fix: use None check for falsy plugin setting defaults in non-interact…
        • 489bc306: fix: rename running binary aside before replacing during update (#261)
        • 2bda7356: fix: detect existing install dir before attempting ida install
        • 6542169d: fix: skip repo fetch for plugin subcommands that don't use it
        • 5542eaff: Merge pull request #253 from HexRaysSA/gha-update
        • 841ca17e: Fix zizmor findings
        • 93d3ecb4: Update and pin GHA
      • IDA-Plugins
        • ba11c7d4: Add new plugins and extend existing analysis features
        • 65f6c8b7: Consolidate IDA plugins into a single repo
      • ida-pro-mcp
        • e2664060: Add host tests for recent isolation and safety fixes.
        • 4d5bc997: Fix disasm start address and funcs write synchronization.
        • d0a4dc4b: Scope insight indexes to sessions and IDBs.
        • fab177c7: Use high-entropy continuation tokens for truncation.
        • f9908f35: Isolate blackboard workspaces per analysis session.
        • 436c1394: Clarify agent contract docs and enforce SKILL sync.
        • 7538ef2e: Tighten batch and graph result semantics.
        • 6c4fe5d0: Align semantic indexing with search entry-EA windows.
        • 652ff78d: Fix blackboard scoping and workspace brief hygiene.
        • 1aa49846: Harden policy fail-closed paths and installer packaging
        • b26fcad1: Gate destructive session actions and fix high-impact tool crashes
        • 2341c843: Harden MCP session ownership for tools, switch, and background jobs
      • Luc-Nhan
        • 3dbaa907: feat(glm): distinguish Standard vs Coding Plan endpoints
        • ba459fab: Merge remote-tracking branch 'EliteClassRoom/master'
        • 0e11cde0: adding emulation to rikugan
        • 08e49f93: fix(settings): show GLM in provider dropdown and auto-config on select
        • 2e9abc07: feat(glm): add GLM-5.x reasoning resilience
      • plugin-ida
        • 67ec8db7: Merge pull request #171 from RevEngAI/refactor/v3-collections-endpoints
        • 8187b3f0: refactor(PLU-325): use v3 collections endpoint for search
      • quokka
        • 0f01c85b: Merge pull request #134 from DarkaMaul/dm/fix-115
        • 9220e374: Merge pull request #133 from DarkaMaul/test/relax-ida93-inport-control
      • ToCode
        • b6d7f1c3: Merge pull request #12 from buzzer-re/dev/fix-deadlock
        • 3839dd57: Make the atomic-write lock test type-check on Linux
        • 35b0f392: Fix Windows-only mypy and test failures so ci-local passes
        • ea741be8: Drop the redundant Command log line from the CLI export path
        • 301e0639: Retry atomic file replace to survive transient Windows locks
      • twdll
        • 3db4cf22: build(gh-actions): fix more submodules
    2. đź”— modem-dev/hunk v0.17.4 release

      What's Changed

      • fix(ui): restore threaded rendering on macOS by @benvinegar in #539
      • fix(review): save draft notes exactly once under rapid Ctrl+S by @endotakuya in #581

      Full Changelog : v0.17.3...v0.17.4

    3. đź”— crosspoint-reader/crosspoint-reader v1.5.0 release

      Summary

      This is one of the biggest updates we've shipped: new hardware support, faster loading on big books, offline dictionary lookups, and a UI overhaul.

      Seeed reTerminal Sticky support

      For the first time, CrossPoint is expanding beyond its original ESP32-C3 roots (XTeink X3/X4). We are officially introducing support for ESP32-S3 devices!

      • First Supported Device: The upcoming Seeed reTerminal Sticky
      • A huge shoutout to Seeed Studio for reaching out, sending test hardware, and being incredible partners throughout the process.
      • Get Yours: You can order a Sticky (Launching July 30th) at crosspointreader.com/devices using our affiliate link to support the project.

      Note

      The XTeink X4 Pro isn't supported in this build yet, but a dedicated release will follow once we've got hardware to test against.

      Big books open fast now

      Big books used to take minutes to open the first time. That's basically gone: sections index on demand in the background while you read, so books open in around 5 seconds. Page turns feel smoother too, from rendering and memory work throughout the app, and we fixed memory allocation and CSS parser bugs that were causing out-of-memory crashes on complex EPUBs.

      Offline dictionary lookups

      Drop a StarDict dictionary onto your SD card and you can look up words with no connection. Select a word, get the definition popup. There's a setup guide if you want to get one running.

      "What to read next"

      Finish an EPUB and CrossPoint looks at what's on your device and suggests something next, right on the end-of-book screen.

      Text settings got a rework

      Font and layout options now live in one menu, with a live preview so you can watch line spacing, margins, and font changes happen without leaving the settings screen.

      There's also a new selection popup. Any setting with three or more choices opens a dialog now instead of making you cycle through options one at a time.

      Arabic, Farsi, and Urdu

      1.4.0 added right-to-left text support. This one finishes the job for Arabic, Farsi, and Urdu: proper bidi handling and contextual glyph shaping, built-in fonts with full Arabic character sets, and the UI itself translated into Arabic.

      Everything else

      KOReader sync now handles custom sync servers, account registration, and metadata uploads. Wi-Fi should behave better — it reconnects to saved networks automatically, including hidden ones, and picks access points more sensibly. The web UI shows image previews in the file browser now and lists device serial numbers. OPDS downloads let you set your own folder and file format.

      We also added the Vollkorn serif font (grab it from Manage Fonts), cleaned up <br> handling and list bullet alignment, and expanded CSS text-decoration support.
      Translations got updates across Swedish, Italian, Spanish, Catalan, Valencian, Czech, Turkish, Portuguese (BR & PT), and Vietnamese, and we added brand new Norwegian BokmĂĄl , Indonesian and Bosnian translations. Chinese entries are now shown correctly in the File Browser and chapters list.

      Note

      If you are upgrading from v1.0.0 or earlier , please upgrade to v1.4.1 first before installing the latest release. Skipping this step will cause your settings to be reset to their default values.

      What's Changed

      New Contributors

      Full Changelog : 1.4.1...1.5.0

    4. đź”— r/reverseengineering Remus Stealer Analysis: Fileless Execution, In-Memory Payload Extraction & C2 Discovery rss

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

    5. đź”— The Pragmatic Engineer The Pulse: New trend - concern about massive increase in code review load 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 .

      One thing I am hearing that's top of mind for many engineering leaders is what is being done to deal with the continuous increase in code review load. It's been a topic for a while, and more such conversations seem to be taking place.

      For me, it began in January, when Opus 4.5 and GPT 5.4 started to write more and better code at most companies. Around then, Director-level folks started talking about the bottleneck of building software moving from coding to the review phase.

      There 's been a boom in AI code review tools to deal with the increase in load since February, and an explosion of experimentation with and adoption of dedicated AI code review tools like CodeRabbit, Greptile, Qodo, SonarQube (now also Gitar). There's also tools offered by coding harnesses themselves like Claude Code review, Cursor review, GitHub Copilot review. And then tools previously not involved in code reviews - but which have context on the codebase - are also adding this, like Sentry 's Seer AI reviews, Linear code reviews.

      Larger companies are building in-house tools to improve the code review experience. Uber's Code Inbox is one case:

      altUber 's Code Inbox. From How Uber uses AI for software development

      Smart assignments are a feature inside Code Inbox for having reviews progress:

      altSmart assignment settings for Code Inbox

      Then there's Risk Profiles which estimate the impact of a change, and encourage devs to pay extra attention to risky ones:

      altCode Inbox tries to estimate the risk of a code change, and bring attention to it

      We covered how Uber uses AI for software development, and it's not just Uber: companies like Cloudflare (AI Code Reviewer), Faire (Fairey), and HubSpot (Sidekick) and many others have also built tools to make their code review flows more fluid, after finding that an in-house implementation worked better than integrating a vendor.

      Another approach is thinking about how to verify code, instead of reviewing. This is easier said than done; in theory, thorough testing should be able to verify that code works as expected. But how much testing is 'thorough'? What type of tests are we talking about? Integration and end-to- end as well? What about fuzz testing? Or formal methods? What about verifying that new tests exercise the functionality as expected? And how do we connect all of this with observability?

      Too much thorough code review is burning out engineers, and resulting in sub-par code reviews. I hear a lot anecdotally that devs see others as no longer able to review code with intent, whereby, if the AI code review has no real comments, they just approve it. Meanwhile, those devs who put the same effort and energy into code review as before feel overloaded by AI slop PRs sent their way.

      The problems exist, and the solutions feel more like experiments.

      What are you seeing inside your company, and how are you dealing with the increase in code reviews? Share your ideas for practical, workable "replacements"?

      Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today's issue covers:

      1. Moving video podcasts off Spotify due to constant reliability issues
      2. "Kimi K3" moment & a US lobby for closed-source AI models
      3. AWS laughs off huge billing error
      4. Industry Pulse

      Read the full issue here

    6. đź”— Hex-Rays Blog Teams: Git-native Versioning & Collaborative Reversing rss

      Teams: Git-native Versioning & Collaborative Reversing

      Teams is a collaboration add-on for IDA Pro recently revised to focus on two pillars: version control and team collaboration with features like Deep Links. It brings Git-based versioning and real-time sharing directly into IDA, so reverse engineering teams can work together on the same binaries without losing work, duplicating effort, or managing files manually.

    7. đź”— @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up for our newsletter here: https://v35.us/dn6rcg5

    8. đź”— @binaryninja@infosec.exchange 10 years ago today, we shipped the first build of Binary Ninja to our mastodon

      10 years ago today, we shipped the first build of Binary Ninja to our customers! We’re kicking off our anniversary celebration by giving away a Binary Ninja Non-Commercial license. See the full giveaway schedule: https://binary.ninja/10years

    9. đź”— r/reverseengineering Transformers Forged To Fight Revival Offline Version Updated rss

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

    10. đź”— tintinweb/pi-subagents v0.14.3 release

      No content.

    11. đź”— pydantic/pydantic-ai-harness v0.10.0 (2026-07-22) release

      What's Changed

      • feat: add ModalSandbox for isolated cloud sandboxes by @strawgate in #269
      • feat: Macroscope CLI code-review capability by @strawgate in #350
      • Fix step persistence snapshot after completed tool boundary by @nmoturi in #374
      • Fix ClampOversizedMessages clamping typed ToolCallPart subclasses (ToolSearchCallPart, LoadCapabilityCallPart) by @dsfaccini in #411
      • fix(memory): scope-qualify injection marker so multiple Memory capabilities coexist by @sevakva in #409
      • feat: add LocalStack capability for emulated AWS environments by @strawgate in #268
      • StepPersistence: drop the provider-validity gate, single error-save site, snapshot state classification by @dsfaccini in #412
      • Harden LocalStack capability after post-merge review by @dsfaccini in #425
      • docs(agent): capability CI scoping, post-merge resync, external-service refresh by @dsfaccini in #423
      • Fix release job silently skipping on tag pushes by @dsfaccini in #429
      • Actually fix release skipping on tag pushes: opt out of skipped-ancestor propagation by @dsfaccini in #430

      New Contributors

      Full Changelog : v0.9.0...v0.10.0

    12. đź”— Console.dev newsletter Databasement rss

      Description: Database server backups.

      What we like: Manage database (MySQL, Postgres, MongoDB, SQLite, Redis, etc) backups through a web UI. Supports local, S3, SFTP locations and connections to sources through SSH. Can be automated via an API and MCP server.

      What we dislike: No fine-grained user permissions. UI looks a bit vibe-coded.

    13. đź”— Console.dev newsletter Neko Master rss

      Description: Network traffic dashboard.

      What we like: Real time visualization of network traffic through a minimal PWA. Pulls data from the network gateway (OpenWrt, Linux, router, etc) through an agent or by directly connecting to the gateway. Runs as a simple container. Does domain, IP, proxy stats with trends.

      What we dislike: Data is stored in SQLite by default, which is a good place to start, but you can connect to Clickhouse for more robust storage.

    14. đź”— Drew DeVault's blog AI in Linux rss

      The role of AI tools (LLMs, mainly) in Linux is under discussion, or it was, until Linus Torvalds “put his foot down” in support of the use of AI in Linux kernel development.

      I can identify two major ways in which AI is used for Linux kernel development: authoring code and reviewing code. There are, at the time of writing, just over 1,200 kernel commits with an “Assisted-by” tag, from September 2025 to the present, most of which indicate patches which were written or assisted by LLM tools.

      The second important use of AI for Linux comes with a new code review tool called Sashiko, which generates code reviews for patches considered for various subsystems. Sashiko ignited the current debate on AI in Linux because it pushes the envelope on AI in Linux: people who oppose or do not want to use AI could previously just refrain from using it to write their patches, but now there is a growing expectation that anyone who wants to contribute to Linux will have to interact with Sashiko or other AI tools like it to iterate on AI-generated feedback on their work.

      One of the major lines of this discussion in the Linux kernel community has been with respect to the ethical considerations of the use of LLMs. Linus shuts this line of reasoning down entirely, firmly grounding the discussion in technical merits and rejecting any political discourse on the matter:

      The kernel project has been and will continue to be about the technology.

      Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that’s a side benefit, not the point of the project.

      This is NOT some kind of “social warrior” project, never has been, and never will be.

      In the kernel community we do open source because it results in better technology, not because of religious reasons.

      This argumentation is disingenuous and hypocritical. Linux is a political project and Linus is a political actor. Consider the use of the GPLv2 for licensing Linux. One can argue from technical merits – for instance, the copyleft nature of the GPLv2 pushes people, and in particular commercial entities, to upstream their drivers and other contributions into the Linux kernel. This contributes to the technical excellence for the kernel as a result.

      But is this not a political choice, and a political act? The purpose of this choice is to influence the behavior of others and to advance the interests of the kernel ahead of their own. And Linus stuck to this decision for political reasons when GPLv3 was introduced, reasoning from morality and ethics when objecting to the license and the manner in which it was deployed, and called for a tacit boycott of the FSF.

      Linus, and Linux, wields a tremendous degree of power and influence over the world, and it should be wielded responsibly. When Linus says the following:

      Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it.

      Or just walk away.

      I find it completely disingenuous. Linus is surely aware that, for all practical purposes, Linux cannot be forked. It is the world’s largest software project, and one of the most well-funded, too. The institutional knowledge among its contributors, the prospect of keeping up with the blistering pace of change, or even putting together a group of people with the time and funding to understand and maintain even a fraction of the kernel’s code independently of upstream, is, quite simply, intractable. Linus knows, this, too – it’s an explicitly cited reason for decisions like the use of the GPL, GPL-only symbols, and the unstable internal kernel ABI: to make the process of independently maintaining a fork of the kernel as difficult as possible.

      People are right to petition Linux upstream to amend its behavior and policies before resorting to the impossible. Working on Linux requires practicing politics, both internally – see for example Linus’ response to the discussions around bcachefs, which had high technical excellence and low social/political competence – and at the intersection of Linux and the rest of the world. Therefore, we must table political, moral, and ethical arguments when we discuss how we go about the work. It’s a cheap, weak argument to direct the discussion away from political and ethical considerations when it wouldn’t serve your point and to table it when it would.

      I’m willing to believe that the LLM-powered Sashiko code reviews provide a lot of good insights. However, to address just one externality of this tool, consider that AI companies are driving up the price of consumer hardware. An AI powered code review may improve a patch, but that patch won’t be of much use to the increasingly large cohort of people who are being priced out of the hardware they could run Linux on to enjoy the better patch.

      Looking at it from another angle: how many tons of CO₂ added to the atmosphere or liters of fresh water supplies disrupted is a tolerable price for a better code review? Temperatures during heat waves are exceeding 50°C in India, causing tens thousands of deaths. The AI built-out is by far the fastest growing energy consumer in the world, and they’re being built with fossil fuels, or drawing green energy demand away from replacing the fossil fuels depended on by other industries. The same process is pricing regular people out of the energy they need to power their air conditioner during those heat waves and the technology it enables is pushing them out of the labor market and into poverty.

      These externalities are very real, and are affecting a lot of people, including Linux kernel contributors and maintainers, and their friends and families, who are trying to bring these problems to Linus’ attention.

      And what of the intangible effects of the use of these tools in Linux? Linux is lending some of the project’s immense influence towards legitimizing the makers of these tools, and Linus’ insistence on focusing narrowly on the technical applications of these tools is a generous gift to them. They will be sure to mention his support in boardrooms, meetings between lobbyists and governments, and anywhere else it will advance their interests.

      It’s fair to ask: what are those interests, and what are they doing with this influence?

      Photograph prominently featuring Mark Zuckerberg, Jeff Bezos and his wife, Sundar Pichai, and Elon Musk
      Google CEO Sundar Pichai pictured at Donald Trump’s inauguration, together with other influential commercial leaders in AI. Sashiko primarily depends on Google Gemini for Linux kernel code reviews.

      There are a lot of smart, passionate people who care about these kinds of questions. Where is the technical excellence in refusing to do this moral calculus, refusing to allow anyone else to do so, and driving away the talented Linux contributors who care about these problems? Linus Torvalds, the Linux community, and all of our communities should have the courage and insight to address these dimensions of the AI question honestly and in good faith.

    15. đź”— Filip Filmar The FPGA Hardware Interview: A Topic Guide with Questions and Exercises rss

      Interviews for FPGA and digital-design roles draw from a stable, well-defined body of knowledge, yet candidates routinely stumble on it because the questions are asked crisply and must be answered under pressure. I am publishing a preparation guide for exactly that situation: a 29-page report, “The FPGA Hardware Interview”, organized as a sequence of topic reviews, each followed by interview-style questions with model answers and, for the design topics, coding exercises solved in both VHDL and SystemVerilog.

    16. đź”— Ampcode News Event Driven Orbs rss

      Amp's orbs can now receive requests and react to events outside Amp.

      That means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can send an HTTP request, it can wake an orb.

      More Ways to Wake an Orb

      GitHub issues are just one example. You can use the same pattern to:

      • Investigate every CI failure on main and post the findings to Slack.
      • Watch for new releases of your dependencies, then review the changes and open an upgrade PR.
      • Start a fresh thread when someone opens a Linear issue, then comment with a fix or report.
      • Turn a bug report from Discord into a reproduction and pull request.
      • Resume a rollout when a deployment or security scan reports back.

      The event decides when the orb wakes up. You decide what it does next.

      From a GitHub Event to an Orb

      Here is the whole setup. Start a thread in an orb for your repository and tell Amp which events to watch and what to do with them:

      Prompt asking Amp to monitor GitHub issues and pull requests with a webhook

      Amp turns that request into a project-specific plugin. It scopes the listener to the repository and events you asked for, verifies GitHub's signature, deduplicates deliveries, and starts a read-only orb thread with trusted event metadata.

      Amp describing the GitHub webhook plugin it will build

      Then Amp loads the plugin and registers its durable endpoint:

      Amp registering the plugin's durable webhook endpoint

      If the orb's GitHub token can administer repository webhooks, Amp connects the endpoint for you. In this case it could not, so Amp gave us one manual step without printing the private URL or signing secret into the thread:

      Amp explaining the manual GitHub webhook configuration step

      A Wild Issue Appears

      Once the webhook is active, someone opens issue #57:

      GitHub issue 57 reporting a typo in a completion description

      GitHub sends the signed event to Amp. Amp verifies it and starts a fresh orb thread with the trusted repository, event, issue, and actor metadata. The issue itself remains untrusted input, not agent instructions:

      A new Amp thread created from a verified GitHub issue webhook

      The new thread inspects the current issue and relevant code, then reports what it found:

      Amp report confirming issue 57 as a low-impact UI typo

      The typo is real, appears once, and only affects secondary menu text. Now the same workflow runs for every issue and pull request event while the original orb sleeps.

      How It Works

      Webhooks work through the Amp Plugin API. When you ask Amp to listen for an event, it creates a plugin in the orb and calls amp.createWebhook to register a durable endpoint for that thread. Then it loads the plugin and gives you the URL to connect to GitHub, Linear, Discord, or another service. If the orb already has access, Amp can connect it for you.

      When a request arrives, Amp stores the event and wakes the orb. The plugin validates and filters the payload, then handles it using the instructions you gave Amp. The URL stays the same across plugin reloads and orb restarts, so the orb does not need to keep running while it waits.

      React to Events However You Want

      amp.createWebhook gives the plugin a handler, not a fixed workflow. That handler is ordinary TypeScript with access to the rest of the Plugin API. The handler can:

      • Continue the owning thread with its context intact by appending the event to ctx.thread.
      • Start a fresh thread in an orb with amp.getBuiltinAgent(...).createThread({ executor: 'orb' }).
      • Keep durable state so it can react every time, or handle one matching event and then stop listening.

      That is where the flexibility comes from. Tell Amp how you want to handle an event and it writes the handler that way. It can also call external APIs to post results back to Slack, Linear, GitHub, or wherever the work began. Return to the owning thread whenever you want to change the behavior.

      The webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it.

    17. đź”— muffinman SpaceDeck X July devlog: upgrades, backgrounds, and more rss

      I've been developing SpaceDeck X since December last year. It started as me playing with a random framework I found fun, and it grew so much that I'm now working towards releasing it on Steam. I kept a devlog on Itch, but I feel like it is time to bring it to my own website. Especially considering that these updates are exclusive to the Steam version.

      I have a pretty clear vision for the release, and lately I've made amazing progress. Here are the major things I've made, in no particular order.

      Upgrades system

      The new upgrades system was brewing in my head for a long time. Honestly, I thought it would take me longer to implement it, but once I started, I got in the zone and built a completely new system.

      This is the new upgrades selection screen:

      New select an upgrade screen

      Compare it to the old one:

      Select an upgrade screen before the update

      Upgrades library

      Upgrades got their own library, so players can inspect and learn about all of them.

      New upgrade library screen

      In two days I managed to draw 44 upgrade icons. Some of them I just winged and now I'm retrofitting them to the actual game upgrades.

      Upgrade icons in aseprite

      Redesigned UI panels

      After making new upgrade cards, I got an urge to redesign some of the game's UI. I'm trying to avoid scope creep, but I had to create a way for the player to see their upgrades, so I decided to give a facelift to the deck panel as well.

      You can open both panels by holding Tab in the boss fight:

      New UI panels opened during a boss fight

      And they show automatically in the pause menu:

      New UI panels automatically open in the pause menu

      Ships

      Ships are not brand new, but in the last few weeks I tweaked their specific weapons and characteristics. It is still a work in progress, but all ships are functional and have their own quirks.

      All three ships shooting shown in the game level

      Backgrounds and shadows

      These are purely decorative, but I think they elevate the experience a lot. These background objects add more visual depth. They also change every few levels, giving the player a better sense of progression.

      For now I created two sets of backgrounds (the gray tech-industrial one and an Aztec/Protoss-inspired one). The plan is to have four or five for the full game. These are quite time consuming, but I enjoy doing pixel art.

      New backgrounds New backgrounds

      For the gray background set, I drew a tileset and I'm using Tiled to assemble them, while the Aztec ones are all drawn by hand.

      New backgrounds

      Other

      Run history is still in progress, but I have the base for the stats screen:

      Run stats screen

      I postponed it for months, and finally I created controller button customization:

      Controller buttons customization screen

      See you soon

      Ever since I started working on this game, I've been obsessed with game dev. You can probably tell from the fact that I haven't published almost any blog posts this year.

      That's why I'll keep these devlogs casual and try to post them more often.

generated: July 26, 2026 at 21:46:38