🏡
  • ↔
  • →
  1. It's time for modern CSS to kill the SPA - Jono Alderson
  2. Two Simple Rules to Fix Code Reviews
  3. Artisanal Handcrafted Git Repositories | drew's dev blog
  4. Reflections on OpenAI
  5. AlphaGolang | A Step-by-Step Go Malware Reversing Methodology for IDA Pro | SentinelOne

generated: July 27, 2025 at 00:04:25

  1. July 26, 2025
    1. 🔗 r/reverseengineering Can You Crack This Program? (Beginner Reverse Engineering Tutorial) rss

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

    2. 🔗 r/reverseengineering Rooting the TP-Link Tapo C200 Rev.5 rss

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

    3. 🔗 r/reverseengineering Trying to control Pi Browser in Android emulator with Frida—anyone pulled off deep automation like this? rss

      I’m working on a pretty advanced automation project where I want to fully control the Pi Browser inside an Android Studio emulator using Frida—not just basic clicks, but deep function-level manipulation and real-time code execution.

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

    4. 🔗 uxmal/reko Version 0.12.1 release

      A new minor release of Reko is available. The main focus of the release has been to provide better XML documentation, which has been requested by users.

      • XML documentation is now available for all classes in the Reko.Core and Reko.Decompiler assemblies. In addition the build now treats missing XML documententation on types and type members as compiler errors. This will enforce a higher standard of documentation moving forward.

      • The Reko.Decompiler.Runtime Nuget now includes the XML documentation.

      • Support for disassembling and lifting PDP-1 machine code was added. I'm fairly confident that Reko is currently the only decompiler supporting this venerable architecture!

      • Added support for OKI NX8/200 and NX8/500 architectures.

      • Added support for Intel's APX instruction prefix.

      • General code cleanup and fixes. Removed many classes that have become obsolete over the years.

      • @smx-smx provided a fix for a crash in the ELF loader when loading ELF files with unknown ABIs.

      • Fixed the command line driver to better handle command line arguments when disassembling raw images.

      • More work on ScannerV2 to handle delay slots correctly on Sparc, Mips, and PA-RISC architectures.

      • Added support for loading little-endian 64-bit PowerPC ELF images.

      • Eliminated the OutArgumentStorage class. This class was confusing and hard to use. It has been replaced by the new Outputs collection on FunctionType which tracks
        the registers used for returning values from procedure calls.

      • The new method ITestGenerationService.GenerateUnitTestFromProcedure can now generate compileable C# code when crashes occur. This will greatly improve handling user-reported problems.

      Special thanks to @smx-smx for troubleshooting various ELF loading issues.

    5. 🔗 News Minimalist 🐢 China to lead new global AI organization + 8 more stories rss

      In the last 2 days ChatGPT read 56909 top news stories. After removing previously covered events, there are 9 articles with a significance score over 5.9.

      [6.2] China to lead global AI development organization —japantimes.co.jp(+11)

      China will lead the formation of an international organization for joint AI development, aiming to prevent a few nations or companies from monopolizing the technology.

      Premier Li Qiang stated that global cooperation is necessary to address AI's risks, such as job displacement and economic disruption, during the World Artificial Intelligence Conference in Shanghai.

      This initiative follows U.S. restrictions on China's tech sector, including chip exports, and underscores Beijing's commitment to advancing its AI ambitions despite semiconductor shortages.

      [6.6] EU regulator approves injectable HIV prevention drug —apnews.com(+16)

      The European Medicines Agency recommended authorizing a twice-yearly injectable drug to prevent HIV, potentially ending its transmission.

      The drug, lenacapavir, was found highly effective and of major public health interest. It is already used to treat HIV and studies showed it was nearly 100% effective in preventing transmission.

      This injectable offers longer protection than existing options, but concerns exist about its widespread availability, though Gilead plans generic versions for many low-income countries.

      Highly covered news with significance over 5.5

      [6.3] Australia, UK sign submarine pact — smh.com.au (+17)

      [6.2] France's top court says arrest warrant for Assad is invalid, new one can be issued — reuters.com (+16)

      [5.8] Trump orders AI to avoid "woke" content — apnews.com (+13)

      [5.8] France recognizes Palestinian statehood, first G7 nation to do so — dw.com (+317)

      [5.7] Google’s new “Web Guide” will use AI to organize your search results — arstechnica.com (+17)

      [5.5] Trump's order targets homeless encampments — apnews.com (+37)

      [5.5] UK's new Online Safety Act to protect children from ‘toxic algorithms’ — independent.co.uk (+28)

      Thanks for reading!

      — Vadim

      You can create your own personal newsletter like this with premium.

      Powered by beehiiv

    6. 🔗 @HexRaysSA@infosec.exchange 📢 Calling all CTF (Capture the Flag) Organizers and Competitors! mastodon

      📢 Calling all CTF (Capture the Flag) Organizers and Competitors!

      Hex-Rays is now accepting applications for our CTF Sponsorship Program—and we want to hear from you.

      Each year, we sponsor:
      • 4 CTF events (from global competitions to student-ran challenges)
      • 4 teams (3 top-tier squads and a crew of rising stars)

      Perks include FREE IDA licenses, exclusive swag, and travel support. For more information, please visit:
      https://hex-rays.com/blog/ctf-sponsorship-program

    7. 🔗 sacha chua :: living an awesome life My Emacs writing experience rss

      I've been enjoying reading people's responses to the Emacs Carnival July theme of writing experience. I know I don't need complicated tools to write. People can write in composition notebooks and on typewriters. But I have fun learning more about the Emacs text editor and tweaking it to support me. Writing is one of the ways I think, and I want to think better. I'll start with the kinds of things I write in my public and private notes, and then I'll think about Emacs specifically.

      Types of notes

      2025-07-25-05 What kinds of posts do I write? How? Improvements? #writing
      2025-07-25-05 What kinds of posts do I write? How? Improvements? #writing

      Text from sketch

      What kinds of posts do I write? How? Improvements?

      2025-07-25-05

      • Emacs News
        • why: collecting & connecting → fun!
        • how:
          • phone: Reddit: upvotes
          • YouTube: playlist
        • RSS
        • Mastodon: Scrape boosts?
        • Dedupe, categorize: classifier?
        • Blog
        • Mailing list
        • emacs.tv
        • emacslife.com/calendar
      • Bike Brigade newsletter
        • why: help out, connect
        • Reddit + X + Slack -> Slack canvas -> MailChimp
        • Need more regular last-min sweep
        • Copying from Slack sucks; Google Docs?
      • Tech notes
        • Why: figure things out, remember, share
        • code
        • literate programming: notes + code
        • debugger?
        • more notes?
        • thinking out loud?
      • Life reflections
        • Why: figure things out, remember
        • tangled thoughts
        • sketch: habit? more doodles
        • audio braindump
        • snippets on phone
        • learning to think
        • laptop: write
        • audio input?
        • themes, thoughts
          • LLM? reflection questions, topics to learn more about
      • Book notes
        • Why: study, remember, share
        • paper: draw while reading
        • e-book: highlight
          • quotes
        • sketch
          • smaller chunks?
        • blog
      • Monthly/yearly reviews
        • Why: plan, remember
        • phone: daily journal
        • tablet: draw moment of the day
        • phone: time records
        • Emacs: raw data
        • themes, next steps: LLM? reflection questions?
        • blog post

      Emacs News

      I put together a weekly list of categorized links about the interesting ways people use Emacs. This takes me about an hour or two each week. I enjoy collecting all these little examples of people's curiosity and ingenuity. Organizing the links into a list helps people find things they might be interested in and connect with other people.

      I start by skimming r/emacs and r/orgmode on my phone, upvoting posts that I want to include. I also search YouTube and add videos to an Emacs News playlist. I review aggregated posts from Planet Emacslife. I have an Emacs Lisp function that collects all the data and formats them as a list, with all the items at the same level.

      For Mastodon, I check #emacs search results from a few different servers. I have a keyboard shortcut that boosts a post and captures the text to an Org Mode file, and then I have another function that prompts me to summarize toots, defaulting to the title of the first link. I have more functions that help me detect duplicates and categorize links. I use ox-11ty to export the post to my blog, which uses the Eleventy static site generator. I also use emacstv.el to add the videos to the Org file I use for emacs.tv.

      Some ways to improve this:

      • I probably have enough data that it might be interesting to learn how to write a classifier. On the other hand, regular expression matches on the titles get most of them correctly, so that might be sufficient.
      • YouTube videos are a little annoying to go through because of interface limitations and unrelated or low-effort videos. I can probably figure out something that checks the RSS feeds of various channels.

      Bike Brigade newsletter

      I also put together a weekly newsletter for Bike Brigade, which coordinates volunteer cyclists to deliver food bank hampers and other essentials. Writing this mostly involves collecting ideas from a number of social media feeds as well as the other volunteers in the community, putting together a draft, and then copying it over to Mailchimp. I'm still figuring out my timing and workflows so that I can stay on top of last-minute requests coming in from people on Slack, and so that I can repurpose newsletter items as updates in the Facebook group or maybe even a blog. If I set aside some regular time to work on things, like a Sunday morning sweep for last-minute requests, that might make it easier to work with other people.

      Tech notes

      I like coding, and I come up with lots of ideas as I use my computer. I enjoy figuring out workflow tweaks like opening lots of URLs in a region or transforming HTML clipboard contents. My Org files have accumulated quite a few. My main limiting factor here is actually sitting down to make those things happen. Fortunately, I have recently discovered that it's possible for me to spend an hour or two a day playing Stardew Valley, so I can swap some of that time for Emacs tweaking instead. Coding doesn't handle interruptions as well as playing does, but taking notes along the way might be able to help with that. I can jump to the section of my Org file with the ideas I wanted to save for more focus time, pick something from that screen, and get right to it.

      Other things that might help me do this more effectively would be:

      • getting better at using my tools (debugger, documentation, completion, etc.),
      • taking the opportunity to plug in an external monitor, and
      • using my non-computer time to mull over the ideas so that I can hit the ground running.

      I like taking notes at virtual meetups. I usually do this with Etherpad so that other people can contribute to the notes too. I don't have a real-time read-write Emacs interface to this yet (that would be way cool!), but I do have some functions for working with the Etherpad text.

      Life reflections

      When I notice something I want to figure out or remember, I use sketches, audio braindumps, or typing to start to untangle that thought. Sometimes I use all three, shifting from one tool to another depending on what I can do at the moment. I have a pretty comfortable workflow for converting sketches (Google Vision) or audio (OpenAI Whisper) to text so that I can work with it more easily, and I'm sure that will get even smoother as the technology improves. I switch from one tool to another as I figure out the shape of my thoughts.

      Maybe I can use microblogging to let smaller ideas out into the world, just in case conversations build them up into more interesting ideas. I don't quite trust my ability to manage my GoToSocial instance yet (backups? upgrades?), so that might be a good reason to use a weekly or monthly review to revisit and archive those posts in plain text.

      I've been reading my on this day list of blog posts and sketches more regularly now that it's in my feed reader. I like the way this helps me revisit old thoughts, and I've saved a few that I want to follow up on. It feels good to build on a thought over time.

      I'd like to do more of this remembering and thinking out loud because memories are fleeting. Maybe developing more trust in my private journals and files will help. (Gotta have those backups!) Then I'll be more comfortable writing about the things we're figuring out about life while also respecting A+ and W-'s privacy, and I can post the stuff I'm figuring out about my life that I'm okay with sharing. I might think something is straightforward, like A+'s progress in learning how to swim. I want to write about how that's a microcosm of how she's learning how to learn more independently and my changing role in supporting her. Still, she might have other opinions about my sharing that, either now or later on. I can still reflect on it and keep that in a private journal as we figure things out together.

      Even though parenting takes up most of my time and attention at the moment, it will eventually take less. There are plenty of things for me to learn about and share outside parenting, like biking, gardening, and sewing. I've got books to read and ideas to try out.

      I'm experimenting with doing more writing on my phone so that I can get better at using these little bits of time. Swiping letters on a keyboard is reasonably fast, and the bottleneck is my thinking time anyway. I use Orgzly Revived so that Syncthing can synchronize it with my Org Mode files on my laptop when I get back home. There are occasional conflicts, but since I mostly add to an inbox.org when I'm on my phone, the conflicts are usually easy to resolve.

      Adding doodles to my reflections can make them more fun. I can draw stick figures from scratch, and I can also trace my photos using the iPad as a way to add visual anchors and practise drawing. If I get the hang of using a smaller portion of my screen like the way I used to draw index cards, that might make thoughts more granular and easier to complete.

      When I write on my computer, I often use writeroom-mode so that things feel less cluttered. I like having big margins and short lines. I have hl-line-mode turned on to help me focus on the current paragraph. This seems to work reasonably well.

      2025-07-26_00-33-44.png
      Figure 1: Screenshot showing writeroom-mode and hl-line-mode

      Monthly and yearly reviews

      I like the rhythm of drawing daily moments and keeping a web-based journal of brief descriptions of our day. I like how I've been digging into them deeper to reflect on themes. The monthly drawings and posts make it easier to review a whole year. Maybe someday I'll get back to weekly reviews as well, but for now, this is working fine.

      My journal entries do a decent job of capturing the facts of our days: where we went, what we did. Maybe spending more time writing life reflections can help me capture more of what goes on in my head and what I want to learn more about.

      Book notes

      I draw single-page summaries of books I like because they're easier to remember and share. E-books are convenient because I can highlight text and extract that data even after I've returned the book, but I can also retype things from paper books or use the text recognition feature on my phone camera. I draw the summaries on my iPad using Noteful, and then I run it through my Google Vision workflow to convert the text from it so that I can include it in a blog post.

      The main limiting factor here is my patience in reading a book. There are so many other wonderful things to explore, and sometimes it feels like books have a bit of filler. When I have a clear topic I'm curious about or a well-written book to enjoy, it's easier to study a book and make notes.

      Emacs workflow thoughts

      Aside from considering the different types of writing I do, I've also been thinking about the mechanics of writing in Emacs. Sanding down the rough parts of my workflow makes writing more enjoyable, and sometimes a small tweak lets me squeeze more writing into fragments of time.

      There are more commands I want to call than there are keyboard shortcuts I can remember. I tend to use M-x to call commands by name a lot, and it really helps to have some kind of completion (I use vertico) and orderless matching.

      I'm experimenting with more voice input because that lets me braindump ideas quickly on my phone. Long dictation sessions are a little difficult to edit. Maybe shorter snippets using the voice input mode on the phone keyboard will let me flesh out parts of my outline. I wonder if the same kind of quick input might be handy on my computer. I'm trying out whisper.el with my Bluetooth earbuds. Dictating tends to be stop-and-go, since I feel self-conscious about dictating when other people are around and I probably only have solo time late at night.

      Misrecognized words can be annoying to correct on my phone. They're much easier to fix on my computer. Some corrections are pretty common, like changing Emax to Emacs. I wrote some code for fixing common errors (my-subed-fix-common-errors), but I don't use this often enough to have it in my muscle memory. I probably need to tweak this so that it's a bit more interactive and trustworthy.

      When I see a word I want to change, I jump to it with C-s (isearch-forward) or C-r (isearch-backward), or I navigate to it with M-f (forward-word). I want to get the hang of using Avy because of Karthik's awesome post about it. That post is from 2021 and I still haven't gotten used to it. I probably just need deliberate practice using the shortcut I've mapped to M-j (avy-goto-char-timer). Or maybe I just don't do this kind of navigation enough yet to justify this micro-optimization (no matter how neat it could be), and isearch is fine for now.

      Sometimes I want to work with sentences. expand-region is another thing I want to get used to. I've bound C-= to er/expand-region from that package. Then I should be able to easily kill the text and type a replacement or move things around. In the meantime, I can usually remember to use my keyboard shortcut of M-z for avy-zap-up-to-char-dwim for deleting something.

      Even in vanilla Emacs, there's so much that I think I'll enjoy getting the hang of. oantolin's post on his writing experience helped me learn about M-E, which marks the region from the point to the end of the sentence and is a natural extension from M-e. Similarly, M-F selects the next word. I could use this kind of shift-selection more. I occasionally remember to transpose words with M-t, but I've been cutting and pasting sentences when I could've been using transpose-sentences all this time. I'm going to add (keymap-global-set "M-T" #'transpose-sentences) to my config and see if I remember it.

      I like using Org Mode headings to collapse long text into a quick overview so I can see the big picture, and they're also handy for making tables of contents. It might be neat to have one more level of overview below that, maybe displaying only the first line of each paragraph. In the meantime, I can use toggle-truncate-lines to get that sort of view.

      If I'm having a hard time fitting the whole shape of a thought into my working memory, I sometimes find it easier to work with plain list outlines that go all the way down to sentences instead of working with paragraphs. I can expand/collapse items and move them around easily using Org's commands for list items. In addition, org-toggle-item toggles between items and plain text, and org-toggle-heading can turn items into headings.

      I could probably write a command that toggles a whole section between an outline and a collection of paragraphs. The outline would be a plain list with two levels. The top level items would be the starting sentences of each paragraph, and each sentence after that would be a list item underneath it. Sometimes I use actual lists. Maybe those would be a third level. Then I can use Org Mode's handy list management commands even when a draft is further along. Alternatively, maybe I can use M-S-left and M-S-right to move sentences around in a paragraph.

      Sometimes I write something and then change my mind about including it. Right now, I tend to either use org-capture to save it or put it under a heading and then refile it to my Scraps subtree, but the palimpsest approach might be interesting. Maybe a shortcut to stash the current paragraph somewhere…

      I use custom Org link types to make it easier to link to topics, project files, parts of my Emacs configuration, blog posts, sketches, videos, and more. It's handy to have completion, and I can define how I want them to be exported or followed.

      Custom Org link types also let me use Embark for context-sensitive actions. For example, I have a command for adding categories to a blog post when my cursor is on a link to the post, which is handy when I've made a list of matching posts. Embark is also convenient for doing things from other commands. It's nice being able to use C-. i to insert whatever's in the minibuffer, so I can use that from C-h f (describe-function), C-h v (describe-variable), or other commands.

      I also define custom Org block types using org-special-block-extras. This lets me easily make things like collapsible sections with summaries.

      I want to get better at diagrams and charts using things like graphviz, mermaidjs, matplotlib, and seaborn. I usually end up searching for an example I can build on and then try to tweak it. Sometimes I just draw something on my iPad and stick it in. It's fine. I think it would be good to learn computer-based diagramming and charting, though. They can be easier to update and re-layout when I realize I've forgotten to add something to the graph.

      Figuring out the proper syntax for diagrams and charts might be one of the reasonable use cases for large-language models, actually. I'm on the fence about LLMs in general. I sometimes use claude.ai for dealing with the occasional tip of the tongue situation like "What's a word or phrase that describes…" and for catching when I've forgotten to finish a sentence. I don't think I can get it to think or write like me yet. Besides, I like doing the thinking and writing.

      I love reading about other people's workflows. If they share their code, that's fantastic, but even descriptions of ideas are fine. I learn so many things from the blog posts I come across on Planet Emacslife in the process of putting together Emacs News. I also periodically go through documentation like the Org Mode manual or release notes, and I always learn something new each time.

      This post was really hard to write! I keep thinking of things I want to start tweaking. I treat Emacs-tweaking as a fun hobby that sometimes happens to make things better for me or for other people, so it's okay to capture lots of ideas to explore later on. Sometimes something is just a quick 5-minute hack. Sometimes I end up delving into the source code, which is easy to do because hey, it's Emacs. It's comforting and inspiring to be surrounded by all this parenthetical evidence of other people's thinking about their workflows.

      Each type of writing helps me with a different type of thinking, and each config tweak makes thoughts flow more smoothly. I'm looking forward to learning how to think better, one note at a time.

      Check out the Emacs Carnival July theme: writing experience post for more Emacs ideas. Thanks to Greg Newman for hosting!

      You can comment on Mastodon or e-mail me at sacha@sachachua.com.

    8. 🔗 r/reverseengineering Reverse Engineering for Bugs Part 1 - How I discovered My 1st 0day in Windows. rss

      Sometimes learning by reversing make you discover 0days, in one place, I discovered 2 Vulnerabilities that able to crash the system.

      While doing my malware analysis as usual, I asked myself a question, What’s a process!?

      Yes, I know the answer, but what even that mean?

      What’s the process journey in Windows? How? What? Where? Why?

      If a Reverse Engineer need answers, that means he will reverse to find these answers.

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

  2. July 25, 2025
    1. 🔗 Textualize/textual The appended release release

      A hotfix. See below for details.

      [5.0.1] - 2025-07-25

      Fixed

      • Fixed appending to Markdown widgets that were constructed with an existing document #5990
    2. 🔗 r/reverseengineering GTA 2 re-implementation project by CriminalRETeam rss

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

    3. 🔗 @trailofbits@infosec.exchange At DistrictCon's inaugural Junkyard competition, we achieved full remote mastodon

      At DistrictCon's inaugural Junkyard competition, we achieved full remote execution on two popular home network devices: a Netgear WGR614v9 router and BitDefender Box V1 security appliance.

      Our exploitation techniques included chaining four buffer overflow vulnerabilities with authentication bypass on the router, plus a novel "bashsledding" ROP technique that sprays shell commands into NVRAM for reliable code execution.

      Read the blog: https://blog.trailofbits.com/2025/07/25/exploiting-zero-days- in-abandoned-hardware/

    4. 🔗 3Blue1Brown (YouTube) But how do AI videos actually work? | Guest video by @WelchLabsVideo rss

      Diffusion models, CLIP, and the math of turning text into images Welch Labs Book: https://www.welchlabs.com/resources/imaginary-numbers-book

      Sections 0:00 - Intro 3:37 - CLIP 6:25 - Shared Embedding Space 8:16 - Diffusion Models & DDPM 11:44 - Learning Vector Fields 22:00 - DDIM 25:25 Dall E 2 26:37 - Conditioning 30:02 - Guidance 33:39 - Negative Prompts 34:27 - Outro 35:32 - About guest videos + Grant’s Reaction

      Special Thanks to: Jonathan Ho - Jonathan is the Author of the DDPM paper and the Classifier Free Guidance Paper. https://arxiv.org/pdf/2006.11239 https://arxiv.org/pdf/2207.12598

      Preetum Nakkiran - Preetum has an excellent introductory diffusion tutorial: https://arxiv.org/pdf/2406.08929

      Chenyang Yuan - Many of the animations in this video were implemented using manim and Chenyang’s smalldiffusion library: https://github.com/yuanchenyang/smalldiffusion

      Cheyang also has a terrific tutorial and MIT course on diffusion models https://www.chenyang.co/diffusion.html https://www.practical-diffusion.org/

      Other References All of Sander Dieleman’s diffusion blog posts are fantastic: https://sander.ai/ CLIP Paper: https://arxiv.org/pdf/2103.00020 DDIM Paper: https://arxiv.org/pdf/2010.02502 Score-Based Generative Modeling: https://arxiv.org/pdf/2011.13456 Wan2.1: https://github.com/Wan-Video/Wan2.1 Stable Diffusion: https://huggingface.co/stabilityai/stable-diffusion-2 Midjourney: https://www.midjourney.com/ Veo: https://deepmind.google/models/veo/ DallE 2 paper: https://cdn.openai.com/papers/dall-e-2.pdf Code for this video: https://github.com/stephencwelch/manim_videos/tree/master/_2025/sora

      Written by: Stephen Welch, with very helpful feedback from Grant Sanderson Produced by: Stephen Welch, Sam Baskin, and Pranav Gundu

      Technical Notes The noise videos in the opening have been passed through a VAE (actually, diffusion process happens in a compressed “latent” space), which acts very much like a video compressor - this is why the noise videos don’t look like pure salt and pepper.

      6:15 CLIP: Although directly minimizing cosine similarity would push our vectors 180 degrees apart on a single batch, overall in practice, we need CLIP to maximize the uniformity of concepts over the hypersphere it's operating on. For this reason, we animated these vectors as orthogonal-ish. See: https://proceedings.mlr.press/v119/wang20k/wang20k.pdf

      Per Chenyang Yuan: at 10:15, the blurry image that results when removing random noise in DDPM is probably due to a mismatch in noise levels when calling the denoiser. When the denoiser is called on x_{t-1} during DDPM sampling, it is expected to have a certain noise level (let's call it sigma_{t-1}). If you generate x_{t-1} from x_t without adding noise, then the noise present in x_{t-1} is always smaller than sigma_{t-1}. This causes the denoiser to remove too much noise, thus pointing towards the mean of the dataset.

      The text conditioning input to stable diffusion is not the 512-dim text embedding vector, but the output of the layer before that, with dimension 77x512

      For the vectors at 31:40 - Some implementations use f(x, t, cat) + alpha(f(x, t, cat) - f(x, t)), and some that do f(x, t) + alpha(f(x, t, cat) - f(x, t)), where an alpha value of 1 corresponds to no guidance. I chose the second format here to keep things simpler.

      At 30:30, the unconditional t=1 vector field looks a bit different from what it did at the 17:15 mark. This is the result of different models trained for different parts of the video, and likely a result of different random initializations.

      Premium Beat Music ID: EEDYZ3FP44YX8OWT

    5. 🔗 Textualize/textual The Tabled release. release

      This is quite a large release! Fueled in part by my work on Toad

      Markdown rendering has been improved, with full text selection, prettier code blocks and tables. Plus streaming support.

      Screenshot 2025-07-25 at 08 37 30

      Plenty of other fixes and additions. Thats to everyone who contributed code and issues!

      There are two breaking changes (see below). These are unlikely to affect anyone, but Semver requires bumping the major version number.

      [5.0.0] - 2025-07-25

      Added

      • Added get_minimal_width to Visual protocol #5962
      • Added expand and shrink attributes to GridLayout #5962
      • Added Markdown.get_stream #5966
      • Added textual.highlight module for syntax highlighting #5966
      • Added MessagePump.wait_for_refresh method #5966
      • Added Widget.container_scroll_offset e84600c
      • Added Markdown.source attribute to MarkdownBlocks e84600c
      • Added extension mechanism to Markdown e84600c
      • Added index to ListView.Selected event #5973
      • Added layout switch to Static.update #5973

      Fixed

      • Fixed TextArea issue with the css theme, where the background color was stuck from the previous theme #5964

      Changed

      • Improved rendering of Markdown tables (replace Rich table with grid) which allows text selection #5962
      • Change look of command palette, to drop accented borders #5966
      • Some style tweaks to Markdown e84600c
      • Content markup can now accept component classes when preceded by a dot, e.g. "Hello [.my_custo_style]World[/]!" #5981
      • Breaking change: Visual.render_strips has a new signature. If you aren't explicitly building Visuals then this won't effect you. #5981
      • Breaking change: The component classes on Markdown have been moved to MarkdownBlock. This won't affect you unless you have customize the Markdown CSS #5981
      • The textual-speedups library will now be imported automatically if it is installed. Set TEXTUAL_SPEEDUPS=0 to disable.
    6. 🔗 r/wiesbaden What are people with small kids doing during the day? rss

      Background: We’re in a bit of a unique situation in that my husband stays at home and is the primary caregiver for our 2-year old son. We don’t actually live in Wiesbaden, but down the road in hofheim. We are a military family, and I’m the service member.

      My husband’s language skills are pretty limited. He can understand some German, but learned it via pimsleur so his speaking and reading aren’t that good.

      Question: What are parents who stay at home doing with their kids during the day? My husband takes our son to a playground for two hours in the morning in the hopes of meeting some other kids/parents but it’s been empty the whole time except for one. We signed up for kinder-turn but there is a waitlist. My husband will have a car starting tomorrow so I was going to get them a Schwimmbad membership (would love recommendations!). But outside of that… where could my husband and son go to socialize some and learn some of the language?

      Thanks in advance for the help!

      submitted by /u/Alert-Count8542
      [link] [comments]

    7. 🔗 Will McGugan Why I ban users from my repositories rss

      I’ve been maintaining various Open Source projects for more than a decade now. In that time I have had countless interactions with users reporting issues and submitting pull requests. The vast majority of these interactions are positive, polite, and constructive. In fact, it is these interactions which make me continue to do the work.

      A few haven’t been so pleasant, and I have banned a subset of the users involved. If we exclude spam, I think the number of users I have banned over the years may still be a single figure.

      There are three broad categories of banned users, listed below.

      Spammers

      I’m sure there is a place for links to sites that sell male enhancement pills, but my repositories are not it. Spam earns you an instant ban. This doesn’t happen all that often as GitHub is quite proactive about dealing with spam. Often I’ll get a notification, but by the time I open it the spammer’s account will have been deleted.

      As well as the usual spam nonsense, I’ve had some other weird stuff posted on my repositories. I recall one user that posted lengthy conspiracy theories, with something about terminals intertwined. I’m pretty sure this user wasn’t a spammer in the traditional sense, and was suffering from psychological issues. I had no choice but to ban them, but I genuinely hope they found treatment for their condition.

      Venting

      A venting post almost always starts with “I spent X hours / days on this”. Such users want me to know how much I have inconvenienced them and they are rarely genuine in asking for help.

      I try to be generous, but that phrase tends to put me on the defensive. I’m not going to treat the issue as a priority, and when I do respond it will be a tad more snarky that usual.

      Venting posts are almost always a skill issue in behalf of the user. The user has either misread the docs or not read them at all, and they have consequently made some invalid assumptions about how the API should work. They couldn’t get their code to work, because it was never intended to work in they way they were using it. Rather than stepping back to reconsider their approach, or read the docs again, they want to shift the blame to me.

      Venting is not an instant ban, because I know how frustrating programming can be. But virtually 100% of these issues are resolved with a link to the docs, and none of reply with a “my bad” even if I suppress my snark.

      So not an instant ban, but if venting crosses the line to personal abuse, then I’m going to be reaching for that ban button.

      Almost everyone recognizes that an posting an issue is essentially asking a favor. If you want somebody to help you move house, you wouldn’t start by criticizing their driving. Same deal with issues.

      Time wasting

      This last category is trickier to define, as its not a single transgression like the others. It’s more of a pattern of behavior that sucks time that could be better spent helping other users or writing code.

      So what constitutes time wasting?

      It will often start with well meaning issues that are overly long. Pages and pages of text that don’t clearly describe the problem the user is tackling. In the end, the issue typically boils down to a perfectly legitimate “it crashes when I do this”. But it can take a lot of fruitless back and forth to get there.

      One time I can overlook. But if it keeps happening, I can feel like I am essentially working for this user at the expense of other users.

      Related, is the user who doesn’t listen or choses not to respond to my requests. Simple things like asking for the version of their OS or software they are using. Details that I need to properly investigate their issue. Sometimes it takes the form of ignoring a recommendation. I’ll let them know there is a canonical solution to that issue, and give them a short code snippet that resolves the issue with less work, but they won’t use it or even acknowledge it.

      However the most common “not listening” issue is when I ask the user why they are attempting the thing they need help with. This can be vital in avoiding the XY Problem. If there is a better way of solving their problem then I can point them in the right direction. But only if they tell me. A few users have just refused to and repeatedly assert the odd thing they are trying to do is the only acceptable fix.

      Other examples of time wasting include asking for LLM hallucinated code to work, posting lists of questions that can be answered with a skim over the docs, and posting the same questions in multiple support locations even after they have been answered (as though they will keep posting until they get a response they like)?

      This is a tricky category, because the user can be well meaning. So its a very high threshold to be banned for this. I only consider it if the user is a clear net negative for the project.

      Unbanning

      I so rarely ban users, and when I do it’s for the good of the project. But I don’t hold grudges. Other than spammers, if anyone I have banned wants to contribute I am happy to un-ban if they reach out. No apology required, but I will require they avoid the ban categories above.

      Open Source is awesome

      I hope this post doesn’t sound too much like whinging.

      I’d like to end by stressing that the community is what makes Open Source awesome. Everyone benefits by contributing in their own way.

  3. July 24, 2025
    1. 🔗 @binaryninja@infosec.exchange Binary Ninja 5.1 is now released: mastodon

      Binary Ninja 5.1 is now released: https://binary.ninja/2025/07/24/5.1-helion.html

      - New WARP function matching
      - Pseudo Objective-C
      - Binexport plugin built-in
      - IL Rewriting Examples, APIs, and Docs
      - Arch: PPC VLE, mips-r5900, x32

      + Much more!

    2. 🔗 astral-sh/uv 0.8.3 release

      Release Notes

      Python

      • Add CPython 3.14.0rc1

      See the python-build-standalone release notes for more details.

      Enhancements

      • Allow non-standard entrypoint names in uv_build (#14867)
      • Publish riscv64 wheels to PyPI (#14852)

      Bug fixes

      • Avoid writing redacted credentials to tool receipt (#14855)
      • Respect --with versions over base environment versions (#14863)
      • Respect credentials from all defined indexes (#14858)
      • Fix missed stabilization of removal of registry entry during Python uninstall (#14859)
      • Improve concurrency safety of Python downloads into cache (#14846)

      Documentation

      • Fix typos in uv_build reference documentation (#14853)
      • Move the "Cargo" install method further down in docs (#14842)

      Install uv 0.8.3

      Install prebuilt binaries via shell script

      curl --proto '=https' --tlsv1.2 -LsSf https://github.com/astral-sh/uv/releases/download/0.8.3/uv-installer.sh | sh

      Install prebuilt binaries via powershell script

      powershell -ExecutionPolicy Bypass -c "irm https://github.com/astral-sh/uv/releases/download/0.8.3/uv-installer.ps1 | iex"

      Download uv 0.8.3

      File | Platform | Checksum
      ---|---|---
      uv-aarch64-apple-darwin.tar.gz | Apple Silicon macOS | checksum
      uv-x86_64-apple-darwin.tar.gz | Intel macOS | checksum
      uv-aarch64-pc-windows-msvc.zip | ARM64 Windows | checksum
      uv-i686-pc-windows-msvc.zip | x86 Windows | checksum
      uv-x86_64-pc-windows-msvc.zip | x64 Windows | checksum
      uv-aarch64-unknown-linux-gnu.tar.gz | ARM64 Linux | checksum
      uv-i686-unknown-linux-gnu.tar.gz | x86 Linux | checksum
      uv-powerpc64-unknown-linux-gnu.tar.gz | PPC64 Linux | checksum
      uv-powerpc64le-unknown-linux-gnu.tar.gz | PPC64LE Linux | checksum
      uv-riscv64gc-unknown-linux-gnu.tar.gz | RISCV Linux | checksum
      uv-s390x-unknown-linux-gnu.tar.gz | S390x Linux | checksum
      uv-x86_64-unknown-linux-gnu.tar.gz | x64 Linux | checksum
      uv-armv7-unknown-linux-gnueabihf.tar.gz | ARMv7 Linux | checksum
      uv-aarch64-unknown-linux-musl.tar.gz | ARM64 MUSL Linux | checksum
      uv-i686-unknown-linux-musl.tar.gz | x86 MUSL Linux | checksum
      uv-x86_64-unknown-linux-musl.tar.gz | x64 MUSL Linux | checksum
      uv-arm-unknown-linux-musleabihf.tar.gz | ARMv6 MUSL Linux (Hardfloat) | checksum
      uv-armv7-unknown-linux-musleabihf.tar.gz | ARMv7 MUSL Linux | checksum

    3. 🔗 @malcat@infosec.exchange [#Kesakode](https://infosec.exchange/tags/Kesakode) DB has been updated to mastodon

      #Kesakode DB has been updated to 1.0.36 !
      9 new malware families
       70 extended malware signatures
      37 new malicious samples in database
      11440 new library objects seen
      120k new clean programs whitelisted
      17M new unique functions
      * 3M new unique strings

    4. 🔗 The Pragmatic Engineer Cursor makes developers less effective? 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 from last week 's The Pulse issue. Full subscribers received the below article seven days ago. To get articles like this in your inbox, every week,subscribe here .

      Many subscribers expense this newsletter to their learning and development budget. If you have such a budget, here 's an email you could send to your manager .

      An interesting study has been published by the nonprofit org, Model Evaluation and Threat Research (METR). They recruited 16 experienced developers who worked on large open source repositories, to fix 136 real issues, for pay of $150/hour. Some devs were assigned AI tools to use, and others were not. The study recorded devs' screens, and then examined and analyzed 146 hours of footage. The takeaway:

      "Surprisingly, we find that when developers use AI tools, they take 19% longer than without. AI makes them slower. (...) This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%."

      This result is very surprising! But what is going on? Looking closely at the research paper:

      The research is about Cursor's impact on developer productivity. The AI tool of choice for pretty much all participants was Cursor, using Sonnet 3.5 or 3.7. A total of 44% of developers had never used Cursor before, and most others had used it for up to 50 hours.

      Those using AI spent less time on coding to complete the work - but took more time, overall. They also spent less time on researching and testing. But they took longer on promoting, waiting on the AI, reviewing its output, and on "IDE overhead", than those not using AI. In the end, additional time spent with the AI wiped out the time it saved on coding, research, and testing, the study found.

      It's worth pointing out that this finding applies to all AI tools, and not only to Cursor, which just happens to be the tool chosen for this study.

      altUsing AI meant less time spent coding, but the work took longer, overall. Source:METR

      Developers are over optimistic in their estimates about AI 's productivity impact - initially, at least.**** From the survey:

      "Both experts and developers drastically overestimate the usefulness of AI on developer productivity, even after they have spent many hours using the tools. This underscores the importance of conducting field experiments with robust outcome measures, compared to relying solely on expert forecasts or developer surveys."

      The one dev who had used Cursor for 50+ hours saw a lot of speedup! In the study, there was a single developer who had used Cursor for a total of more than 50 hours, previously. This dev saw a very impressive 38% increase in speed. Then again, a sample size of one is not very representative of a group of 16:

      altOne developer with 50+ hours of experience on Cursor completed work much faster. Source:METR

      Software engineer Simon Willison - whom I consider an unbiased expert on AI dev tools - interprets the survey like this:

      "My intuition here is that this study mainly demonstrated that the learning curve of AI-assisted development is high enough that asking developers to bake it into their existing workflows reduces their performance while they climb that learning curve."

      Indeed, he made a similar point on an episode of the Pragmatic Engineer podcast: "you have to put in so much effort to learn, to explore and experiment, and learn how to use it. And there's no guidance."

      In research on AI tools by this publication, based on input from circa 200 software engineers, we found supporting evidence of that: those who hadn't used AI tools for longer than 6 months were more likely to have a negative perception of them. Very common feedback from engineers who didn't use AI tooling was that they'd tried it, but it didn't meet expectations, so they stopped.

      The engineer who saw a 38% "speed-up" versus non-AI devs has an interesting take. That lone engineer with 50+ hours of Cursor experience is PhD student, Quentin Anthony. Here's what he says about the study, and how AI tools impact developer efficiency:

      "1. AI speedup is very weakly correlated to anyone 's ability as a dev. All the devs in this study are very good. I think it has more to do with falling into failure modes, both in the LLM's ability and the human's workflow. I work with a ton of amazing pretraining devs, and I think people face many of the same problems.

      We like to say that LLMs are tools, but treat them more like a magic bullet.

      Literally any dev can attest to the satisfaction of finally debugging a thorny issue. LLMs are a big dopamine shortcut button that may one-shot your problem. Do you keep pressing the button that has a 1% chance of fixing everything? It's a lot more enjoyable than the grueling alternative, at least to me.

      2. LLMs today have super spiky capability distributions. I think this has more to do with:what coding tasks we have lots of clean data forwhat benchmarks/evals LLM labs are using to measure success.

      As an example, LLMs are all horrible at low-level systems code (GPU kernels, parallelism/communication, etc). This is because their code data is relatively rare, and evaluating model capabilities is hard (I discuss this in more detail here).

      Since these tasks are a large part of what I do as a pretraining dev, I know what parts of my work are amenable to LLMs (writing tests, understanding unfamiliar code, etc) and which are not (writing kernels, understanding communication synchronization semantics, etc). I only use LLMs when I know they can reliably handle the task.

      When determining whether some new task is amenable to an LLM, I try to aggressively time-box my time working with the LLM so that I don't go down a rabbit hole. Again, tearing yourself away from an LLM when "it's just so close!" is hard!

      3. It 's super easy to get distracted in the downtime while LLMs are generating. The social media attention economy is brutal, and I think people spend 30 mins scrolling while "waiting" for their 30-second generation.

      All I can say on this one is that we should know our own pitfalls and try to fill LLM-generation time productively:If the task requires high-focus, spend this time either working on a subtask, or thinking about follow-up questions. Even if the model one-shots my question, what else don't I understand?If the task requires low-focus, do another small task in the meantime (respond to email/slack, read or edit another paragraph, etc).

      As always, small digital hygiene steps help with this (website blockers, phone on dnd, etc). Sorry to be a grampy, but it works for me :)"

      Quentin concludes:

      "LLMs are a tool, and we need to start learning its pitfalls and have some self-awareness. A big reason people enjoy Andrej Karpathy's talks is because he's a highly introspective LLM user, which he arrived at a bit early due to his involvement in pretraining some of them.

      If we expect to use this new tool well, we need to understand its (and our own!) shortcomings and adapt to them."

      I wonder if context switching could become the Achilles Heel of AI coding tools. As a dev, the most productive work I do is when I'm in "the zone", just locked into a problem with no distractions, and when my sole focus is work! I know how expensive it is to get back into the zone after you fall out of it.

      But I cannot stay in the zone when using a time-saving AI coding tool; I need to do something else while code is being generated, so context switches are forced, and each one slows me down. It's a distraction.

      What if the constraint of being "in the zone" when writing code is a feature, not a bug? And what if experienced devs not using AI tools outperform most others with AI because they consciously stay in "the zone" and focus more? Could those without AI tools have been "in the zone" and working at a higher performance level than devs forced into repeated context switches by their AI tools?

      There's food for thought here about how time saved on coding doesn't automatically translate into higher productivity when building software.

      This was one out of four topics from last week's The Pulse. The full issue also covers:

      1. Industry pulse. Why 1.1.1.1 went down for an hour, Microsoft cut jobs to buy more GPUs, Meta's incredible AI data center spend, and the "industry-wide problem" of fake job candidates from North Korea.
      2. Windsurf sale: a complicated story of OpenAI, Microsoft, Google, and Cognition. OpenAI wanted to buy Windsurf but couldn't because of Microsoft. Google then hired the founders and core team of Windsurf, and Cognition (the maker of Devin) bought the rest of the company. It's a weird story that could not happen outside of California - thanks to California having a ban on noncompetes.
      3. Beginning of the end for VC-subsidized tokens? Cursor angered devs by silently imposing limits on its "unlimited" tier. Us devs face the reality that LLM usage is getting more expensive - and VC funding will probably stop subsidizing the real cost of tokens.

      This week's The Pulse issue - sent out to full subscribers - covers:

      1. Mystery solved about the cause of June 10th outages. Heroku went down for a day due to an update to the systemd process on Ubuntu Linux. Turns out that dozens of other companies including OpenAI, Zapier, and GitLab, were also hit by the same issue, with outages of up to 6 hours.
      2. Replit AI secretly deletes prod - oops! Cautionary tale of why vibe-coding apps are not yet production-ready, which makes it hard to foresee production-hardened apps being shipped with no software engineering expertise involved.
      3. Industry pulse. Fresh details about the Windsurf sale, Zed editor allows all AI functionality to be turned off, government agencies using Microsoft Sharepoint hacked, GitHub releases vibe coding tool, and more.
      4. Reflections on a year at OpenAI. Software engineer Calvin French-Owen summarized his impressions of OpenAI, sharing how the company runs on Slack and Azure, capacity planning challenges for OpenAI Codex launch, learnings from working on a large Python codebase, and more.

      Read The Pulse issues here.

    5. 🔗 ryoppippi/ccusage v15.5.2 release

      No significant changes

      [View changes on

      GitHub](https://github.com/ryoppippi/ccusage/compare/v15.5.1...v15.5.2)

    6. 🔗 Simon Willison Using GitHub Spark to reverse engineer GitHub Spark rss

      GitHub Spark was released in public preview yesterday. It's GitHub's implementation of the prompt-to-app pattern also seen in products like Claude Artifacts, Lovable, Vercel v0, Val Town Townie and Fly.io’s Phoenix New. In this post I reverse engineer Spark and explore its fascinating system prompt in detail.

      I wrote about Spark back in October when they first revealed it at GitHub Universe.

      GitHub describe it like this:

      Build and ship full-stack intelligent apps using natural language with access to the full power of the GitHub platform—no setup, no configuration, and no headaches.

      You give Spark a prompt, it builds you a full working web app. You can then iterate on it with follow-up prompts, take over and edit the app yourself (optionally using GitHub Codespaces), save the results to a GitHub repository, deploy it to Spark's own hosting platform or deploy it somewhere else.

      Here's a screenshot of the Spark interface mid-edit. That side-panel is the app I'm building, not the docs - more on that in a moment.

      Screenshot of a development environment showing a file explorer on the left with files like App.tsx, index.css, prompts-content.ts, system_prompt.md, tools.md, index.html, PRD.md, and update-prompts.sh under a 'src' folder, along with task items including "Run bash code to figure out every binary tool on your path, then add those as a ...", "Add HTML5 history support, such that when I navigate around in the app the ...", "Add # links next to every heading that can be navigated to with the fragment ...", and "Fix all reported errors." The center shows code with line numbers 1543-1549 containing HTML/JSX elements, and the right panel displays "Spark Docs" documentation with "Spark API Documentation" heading, describing "What is Spark?" as "a specialized runtime environment for building micro-applications (called 'sparks') using React and TypeScript" with sections for Persistence (Key-value storage with React hooks), LLM Integration (Direct access to language models), and User Context (GitHub user information and permissions). Bottom shows "Copilot is working..." and "Use Option + Tab or Option + Shift + Tab to escape the editor."

      Spark capabilities

      Sparks apps are client-side apps built with React - similar to Claude Artifacts - but they have additional capabilities that make them much more interesting:

      1. They are authenticated: users must have a GitHub account to access them, and the user's GitHub identity is then made available to the app.
      2. They can store data! GitHub provides a persistent server-side key/value storage API.
      3. They can run prompts. This ability isn't unique - Anthropic added that to Claude Artifacts last month. It looks like Spark apps run prompts against an allowance for that signed-in user, which is neat as it means the app author doesn't need to foot the bill for LLM usage.

      A word of warning about the key/value store: it can be read, updated and deleted by anyone with access to the app. If you're going to allow all GitHub users access this means anyone could delete or modify any of your app's stored data.

      I built a few experimental apps, and then decided I to go meta: I built a Spark app that provides the missing documentation for how the Spark system works under the hood.

      Reverse engineering Spark with Spark

      Any system like Spark is inevitably powered by a sophisticated invisible system prompt telling it how to behave. These prompts double as the missing manual for these tools - I find it much easier to use the tools in a sophisticated way if I've seen how they work under the hood.

      Could I use Spark itself to turn that system prompt into user-facing documentation?

      Here's the start of my sequence of prompts:

      1. An app showing full details of the system prompt, in particular the APIs that Spark apps can use so I can write an article about how to use you [result]

      That got me off to a pretty great start!

      Pleasingly designed website, Spark API Documentation. Comprehensive guide to building applications with the Spark platform. It has a sidebar with a search docs... box and Overview, Persistence API, LLM API, User API, System Prompt and Best Practices pages.

      You can explore the final result at github-spark-docs.simonwillison.net.

      Spark converted its invisible system prompt into a very attractive documentation site, with separate pages for different capabilities of the platform derived from that prompt.

      I read through what it had so far, which taught me how the persistence, LLM prompting and user profile APIs worked at a JavaScript level.

      Since these could be used for interactive features, why not add a Playground for trying them out?

      1. Add a Playground interface which allows the user to directly interactively experiment with the KV store and the LLM prompting mechanism [result]

      This built me a neat interactive playground:

      A new Playground menu item has been added, revealing an Interactive Playground with tabs for KV Store and LLM API. The Key-VAlue Store Playground lets you set a key and value, get a value, delete a key and list keys. The existing keys are test-key and bob. The value for test-key is JSON {"example": "value"}

      The LLM section of that playground showed me that currently only two models are supported: GPT-4o and GPT-4o mini. Hopefully they'll add GPT-4.1 soon. Prompts are executed through Azure OpenAI.

      It was missing the user API, so I asked it to add that too:

      1. Add the spark.user() feature to the playground [result]

      Having a summarized version of the system prompt as a multi-page website was neat, but I wanted to see the raw text as well. My next prompts were:

      1. Create a system_prompt.md markdown file containing the exact text of the system prompt, including the section that describes any tools. Then add a section at the bottom of the existing System Prompt page that loads that via fetch() and displays it as pre wrapped text

      2. Write a new file called tools.md which is just the system prompt from the heading ## Tools Available - but output &lt; instead of < and &gt; instead of >

        No need to click "load system prompt" - always load it

        Load the tools.md as a tools prompt below that (remove that bit from the system_prompt.md)

      The bit about < and > was because it looked to me like Spark got confused when trying to output the raw function descriptions to a file - it terminated when it encountered one of those angle brackets.

      Around about this point I used the menu item "Create repository" to start a GitHub repository. I was delighted to see that each prompt so far resulted in a separate commit that included the prompt text, and future edits were then automatically pushed to my repository.

      I made that repo public so you can see the full commit history here.

      ... to cut a long story short, I kept on tweaking it for quite a while. I also extracted full descriptions of the available tools:

      • str_replace_editor for editing files, which has sub-commands view, create, str_replace, insert and undo_edit. I recognize these from the Claude Text editor tool, which is one piece of evidence that makes me suspect Claude is the underlying model here.
      • npm for running npm commands (install, uninstall, update, list, view, search) in the project root.
      • bash for running other commands in a shell.
      • create_suggestions is a Spark-specific tool - calling that with three suggestions for next steps (e.g. "Add message search and filtering") causes them to be displayed to the user as buttons for them to click.

      Full details are in the tools.md file that Spark created for me in my repository.

      The bash and npm tools clued me in to the fact that Spark has access to some kind of server-side container environment. I ran a few more prompts to add documentation describing that environment:

      • Use your bash tool to figure out what linux you are running and how much memory and disk space you have (this ran but provided no output, so I added:)
      • Add that information to a new page called Platform
      • Run bash code to figure out every binary tool on your path, then add those as a sorted comma separated list to the Platform page

      This gave me a ton of interesting information! Unfortunately Spark doesn't show the commands it ran or their output, so I have no way of confirming if this is accurate or hallucinated. My hunch is that it's accurate enough to be useful, but I can't make any promises.

      Platform page. Debian GNU/Linux 12 (bookworm), Kernel Version 6.8.0-1027-azure, x86_64 (64-bit), AMD EPYC 7763 64-Core, 4 cores available. Azure Cloud (GitHub Codespaces), 15 GB RAM, ~9.8 GB available, 31GB disk space, 27GB free, 10% used.

      Spark apps can be made visible to any GitHub user - I set that toggle on mine and published it to system-exploration-g--simonw.github.app, so if you have a GitHub account you should be able to visit it there.

      I wanted an unathenticated version to link to though, so I fired up Claude Code on my laptop and had it figure out the build process. It was almost as simple as:

      npm install
npm run build

      ... except that didn't quite work, because Spark apps use a private @github/spark library for their Spark-specific APIs (persistence, LLM prompting, user identity) - and that can't be installed and built outside of their platform.

      Thankfully Claude Code (aka Claude Honey Badger) won't give up, and it hacked around with the code until it managed to get it to build.

      That's the version I've deployed to github-spark-docs.simonwillison.net using GitHub Pages and a custom subdomain so I didn't have to mess around getting the React app to serve from a non-root location.

      The default app was a classic SPA with no ability to link to anything inside of it. That wouldn't do, so I ran a few more prompts:

      • Add HTML5 history support, such that when I navigate around in the app the URL bar updates with #fragment things and when I load the page for the first time that fragment is read and used to jump to that page in the app. Pages with headers should allow for navigation within that page - e.g. the Available Tools heading on the System Prompt page should have a fragment of #system-prompt--available-tools and loading the page with that fragment should open that page and jump down to that heading. Make sure back/forward work too
      • Add # links next to every heading that can be navigated to with the fragment hash mechanism
      • Things like <CardTitle id="performance-characteristics">Performance Characteristics</CardTitle> should also have a # link - that is not happening at the moment

      ... and that did the job! Now I can link to interesting sections of the documentation. Some examples:

      The interactive playground is visible on my public site but doesn't work, because it can't call the custom Spark endpoints. You can try the authenticated playground for that instead.

      That system prompt in detail

      All of this and we haven't actually dug into the system prompt itself yet.

      I've read a lot of system prompts, and this one is absolutely top tier. I learned a whole bunch about web design and development myself just from reading it!

      Let's look at some highlights:

      You are a web coding playground generating runnable code micro-apps ("sparks"). This guide helps you produce experiences that are not only functional but aesthetically refined and emotionally resonant.

      Starting out strong with "aesthetically refined and emotionally resonant"! Everything I've seen Spark produce so far has had very good default design taste.

      Use the available search tools to understand the codebase and the user's query. You are encouraged to use the search tools extensively both in parallel and sequentially, especially when you are starting or have no context of a project.

      This instruction confused me a little because as far as I can tell Spark doesn't have any search tools. I think it must be using rg and grep and the like for this, but since it doesn't reveal what commands it runs I can't tell for sure.

      It's interesting that Spark is not a chat environment - at no point is a response displayed directly to the user in a chat interface, though notes about what's going on are shown temporarily while the edits are being made. The system prompt describes that like this:

      You are an AI assistant working in a specialized development environment. Your responses are streamed directly to the UI and should be concise, contextual, and focused. This is not a chat environment, and the interactions are not a standard "User makes request, assistant responds" format. The user is making requests to create, modify, fix, etc a codebase - not chat.

      All good system prompts include examples, and this one is no exception:

      ✅ GOOD:

      • "Found the issue! Your authentication function is missing error handling."
      • "Looking through App.tsx to identify component structure."
      • "Adding state management for your form now."
      • "Planning implementation - will create Header, MainContent, and Footer components in sequence."

      ❌ AVOID:

      • "I'll check your code and see what's happening."
      • "Let me think about how to approach this problem. There are several ways we could implement this feature..."
      • "I'm happy to help you with your React component! First, I'll explain how hooks work..."

      The next "Design Philosophy" section of the prompt helps explain why the apps created by Spark look so good and work so well.

      I won't quote the whole thing, but the sections include "Foundational Principles", "Typographic Excellence", "Color Theory Application" and "Spatial Awareness". These honestly feel like a crash-course in design theory!

      OK, I'll quote the full typography section just to show how much thought went into these:

      Typographic Excellence

      • Purposeful Typography: Typography should be treated as a core design element, not an afterthought. Every typeface choice should serve the app's purpose and personality.
      • Typographic Hierarchy: Construct clear visual distinction between different levels of information. Headlines, subheadings, body text, and captions should each have a distinct but harmonious appearance that guides users through content.
      • Limited Font Selection: Choose no more than 2-3 typefaces for the entire application. Consider San Francisco, Helvetica Neue, or similarly clean sans-serif fonts that emphasize legibility.
      • Type Scale Harmony: Establish a mathematical relationship between text sizes (like the golden ratio or major third). This forms visual rhythm and cohesion across the interface.
      • Breathing Room: Allow generous spacing around text elements. Line height should typically be 1.5x font size for body text, with paragraph spacing that forms clear visual separation without disconnection.

      At this point we're not even a third of the way through the whole prompt. It's almost 5,000 words long!

      Check out this later section on finishing touches:

      Finishing Touches

      • Micro-Interactions: Add small, delightful details that reward attention and form emotional connection. These should be discovered naturally rather than announcing themselves.
      • Fit and Finish: Obsess over pixel-perfect execution. Alignment, spacing, and proportions should be mathematically precise and visually harmonious.
      • Content-Focused Design: The interface should ultimately serve the content. When content is present, the UI should recede; when guidance is needed, the UI should emerge.
      • Consistency with Surprise: Establish consistent patterns that build user confidence, but introduce occasional moments of delight that form memorable experiences.

      The remainder of the prompt mainly describes the recommended approach for writing React apps in the Spark style. Some summarized notes:

      • Spark uses Vite, with a src/ directory for the code.
      • The default Spark template (available in github/spark-template on GitHub) starts with an index.html and src/App.tsx and src/main.tsx and src/index.css and a few other default files ready to be expanded by Spark.
      • It also has a whole host of neatly designed default components in src/components/ui with names like accordion.tsx and button.tsx and calendar.tsx - Spark is told "directory where all shadcn v4 components are preinstalled for you. You should view this directory and/or the components in it before using shadcn components."
      • A later instruction says "Strongly prefer shadcn components (latest version v4, pre-installed in @/components/ui). Import individually (e.g., import { Button } from "@/components/ui/button";). Compose them as needed. Use over plain HTML elements (e.g., <Button> over <button>). Avoid creating custom components with names that clash with shadcn."
      • There's a handy type definition describing the default spark. API namespace: 
        declare global {
  interface Window {
    spark: {
      llmPrompt: (strings: string[], ...values: any[]) => string
      llm: (prompt: string, modelName?: string, jsonMode?: boolean) => Promise<string>
      user: () => Promise<UserInfo>
      kv: {
        keys: () => Promise<string[]>
        get: <T>(key: string) => Promise<T | undefined>
        set: <T>(key: string, value: T) => Promise<void>
        delete: (key: string) => Promise<void>
      }
    }
  }
}
      • The section on theming leans deep into Tailwind CSS and the tw-animate-css package, including a detailed example.
      • Spark is encouraged to start by creating a PRD - a Product Requirements Document - in src/prd.md. Here's the detailed process section on that, and here's the PRD for my documentation app (called PRD.md and not src/prd.md, I'm not sure why.)

      The system prompt ends with this section on "finishing up":

      Finishing Up

      • After creating files, use the create_suggestions tool to generate follow up suggestions for the user. These will be presented as-is and used for follow up requests to help the user improve the project. You must do this step.
      • When finished, only return DONE as your final response. Do not summarize what you did, how you did it, etc, it will never be read by the user. Simply return DONE

      Notably absent from the system prompt: instructions saying not to share details of the system prompt itself!

      I'm glad they didn't try to suppress details of the system prompt itself. Like I said earlier, this stuff is the missing manual: my ability to use Spark is greatly enhanced by having read through the prompt in detail.

      What can we learn from all of this?

      This is an extremely well designed and implemented entrant into an increasingly crowded space.

      GitHub previewed it in October and it's now in public preview nine months later, which I think is a great illustration of how much engineering effort is needed to get this class of app from initial demo to production-ready.

      Spark's quality really impressed me. That 5,000 word system prompt goes a long way to explaining why the system works so well. The harness around it - with a built-in editor, Codespaces and GitHub integration, deployment included and custom backend API services - demonstrates how much engineering work is needed outside of a system prompt to get something like this working to its full potential.

      When the Vercel v0 system prompt leaked Vercel's CTO Malte Ubl said:

      When @v0 first came out we were paranoid about protecting the prompt with all kinds of pre and post processing complexity.

      We completely pivoted to let it rip. A prompt without the evals, models, and especially UX is like getting a broken ASML machine without a manual

      I would love to see the evals the Spark team used to help iterate on their epic prompt!

      Spark features I'd love to see next

      I'd love to be able to make my Spark apps available to unauthenticated users. I had to figure out how to build and deploy the app separately just so I could link to it from this post.

      Spark's current deployment system provides two options: just the app owner or anyone with a GitHub account. The UI says that access to "All members of a selected organization" is coming soon.

      Building and deploying separately had added friction due to the proprietary @github/spark package. I'd love an open source version of this that throws errors about the APIs not being available - that would make it much easier to build the app independently of that library.

      My biggest feature request concerns that key/value API. The current one is effectively a global read-write database available to any user who has been granted access to the app, which makes it unsafe to use with the "All GitHub users" option if you care about your data being arbitrarily modified or deleted.

      I'd like to see a separate key/value API called something like this:

      spark: {
  userkv: {
    keys: () => Promise<string[]>
    get: <T>(key: string) => Promise<T | undefined>
    set: <T>(key: string, value: T) => Promise<void>
    delete: (key: string) => Promise<void>
  }
}

      This is the same design as the existing kv namespace but data stored here would be keyed against the authenticated user, and would not be visible to anyone else. That's all I would need to start building applications that are secure for individual users.

      I'd also love to see deeper integration with the GitHub API. I tried building an app to draw graphs of my open issues but it turned there wasn't a mechanism for making authenticated GitHub API calls, even though my identity was known to the app.

      Maybe a spark.user.githubToken() API method for retrieving a token for use with the API, similar to how GITHUB_TOKEN works in GitHub Actions, would be a useful addition here.

      Pony requests aside, Spark has really impressed me. I'm looking forward to using it to build all sorts of fun things in the future.

      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.

    7. 🔗 News Minimalist 🐢 UN court declares healthy environment a human right + 7 more stories rss

      In the last 2 days ChatGPT read 57170 top news stories. After removing previously covered events, there are 8 articles with a significance score over 5.9.

      [6.4] Healthy environment is a human right, top UN court rules in landmark climate case —irishtimes.com(+74)

      The International Court of Justice ruled that a clean, healthy environment is a fundamental human right, requiring states to address harm from their carbon emissions.

      This landmark decision clarifies states' obligations to combat climate change, emphasizing intergenerational equity and holding major emitters accountable for inaction, potentially leading to reparations.

      The non-binding opinion is seen as a turning point in international climate law, potentially enabling future legal actions.

      [6.3] Gene editing stops malaria transmission in Asian mosquitoes —today.ucsd.edu(+3)

      Scientists have engineered mosquitoes to halt malaria transmission by altering a single gene, a breakthrough that could combat the deadly disease.

      This CRISPR-based system modifies a protein in mosquitoes, preventing malaria parasites from reaching their salivary glands and thus stopping transmission to humans. The genetic change is designed to spread through mosquito populations.

      Researchers tested the system in Anopheles stephensi mosquitoes, a primary malaria vector in Asia, successfully blocking parasite infection and spread.

      Highly covered news with significance over 5.5

      [6.0] US Olympic Committee bars transgender women from women's sports — ctvnews.ca (+53)

      [6.1] US and Japan agree on a trade deal — cnbc.com (+327)

      [5.8] More than 100 humanitarian groups warn of mass starvation in Gaza — bbc.com (+191)

      [6.1] Brazil joins ICJ genocide case against Israel — reuters.com [$] (+5)

      [5.6] UK and India sign historic trade deal — theguardian.com (+107)

      [5.8] Trump unveiled AI Action Plan, cutting regulations — apnews.com (+88)

      Thanks for reading!

      — Vadim

      You can customize this newsletter with premium.

      Powered by beehiiv

    8. 🔗 r/reverseengineering New Advanced Stealer (SHUYAL) Targets Credentials Across 19 Popular Browsers rss

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

    9. 🔗 r/wiesbaden MTG Wiesbaden ~ Die Gruppe für Magic Spieler und die, die es werden wollen! rss

      Suchst du nach einer Magic-Gemeinschaft in Wiesbaden? Dann bist du hier genau richtig!

      Die Whatsapp-Gruppe wurde im Februar 2022 von Mangamafia gegrĂźndet, um Magic The Gathering Spieler aus Wiesbaden und Umgebung zusammenzubringen.

      Hier ist, was du in unserer Gruppe finden kannst:

      • Eine freundliche und einladende Community, in der wir uns Ăźber Karten, Decks oder die neueste Standard Meta austauschen. Die generelle Entwicklung von Magic wird ebenfalls diskutiert.
      • Jeden Samstag 16 Uhr MTG Standard-Showdown in Darmstadt. Wir fahren da entweder mit dem Zug oder bilden Fahrgemeinschaften.
      • Jeden Mittwoch gibt es im Glitchless in Mainz 17 Uhr abwechselnd Draft und Standard Showdown.
      • Treffen zum Spielen, Tauschen und Spaß haben.
      • UnterstĂźtzung fĂźr Anfänger: Wir helfen gerne dabei, die Grundlagen des Spiels zu erlernen und versorgen euch auch mit euren ersten Karten. Gelegentlich gibt es Learn to Play Events wo das Spiel beigebracht oder beim Deckbau unterstĂźtzt wird. Das nächste ist am 16. August im Glitchless in Mainz.
      • Gelegentlich organisieren wir privat kleine Turniere oder Drafts, um unsere Fähigkeiten zu testen.
      • Wir spielen hauptsächlich Standard, aber es gibt auch Spieler, die sich fĂźr schwierigere Formate begeistern.
      • Private Events interessieren uns, obwohl die Organisation manchmal eine Herausforderung darstellt. 1-2 Events sind fĂźr dieses Jahr auf jeden noch geplant.

      Mangamafia strebte danach, mehr Magic-Events anzubieten, hat sich in Wiesbaden aber aus dem Spielbetrieb zurĂźckgezogen. Wir haben schon viele Orte zum ausweichen etabliert. Allen voran JK-Entertainment in Darmstadt 16 Uhr jeden Samstag und der Glitchless jeden Mittwoch um 16 Uhr.

      Also im Endeffekt ist das eine Wiesbaden Gruppe, die von Mangamafia ins Leben gerufen wurde, aber nicht mehr so viel mit Mangamafia zu tun hat. Tatsächlich sind die Store Championships der verschiedenen TCG-Läden unser Hauptaugenmerk geworden. Durch die neuen Sets alle 2 Monate sind diese sehr regelmäßig geworden.

      Hier ist der Link zu Mangamafia: https://manga-mafia.de/store-wiesbaden

      Hier ist der Link zu JK-Entertainment: https://jk-entertainment.de/

      Hier ist der Link zum Glitchless: https://glitchless.de/

      MTG Subreddit: r/spikes

      Der Link fĂźr die Whatsappgruppe wird hier nur auf Anfrage zur VerfĂźgung gestellt, da es Probleme mit Spam gab. Ihr kĂśnnt mir auch eine Nachricht schicken.

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

    10. 🔗 @trailofbits@infosec.exchange [https://mailchi.mp/trailofbits/trail-of-bits-tribune- mastodon

      https://mailchi.mp/trailofbits/trail-of-bits-tribune- july-2025

    11. 🔗 @trailofbits@infosec.exchange New Trail of Bits Tribune: Our AIxCC finals submission, how we exposed mastodon

      New Trail of Bits Tribune: Our AIxCC finals submission, how we exposed critical flaws in Go's built-in parsers that can enable authentication bypass and data exfiltration from production systems, and 14 new security reviews.
      Read it here: https://mailchi.mp/trailofbits/trail-of-bits-tribune- july-2025

    12. 🔗 @HexRaysSA@infosec.exchange IDA 9.2 (coming soon... ) adds full support for the TriCore TC1.8 mastodon

      IDA 9.2 (coming soon... ) adds full support for the TriCore TC1.8 architecture, including over 50 new instructions and updated chipset definitions. Ideal for automotive and railway firmware analysis.

      https://hex-rays.com/blog/tricore-ida-support

    13. 🔗 r/reverseengineering Development Journey on Game Decompilation Using AI rss

      Someone is attempting to use AI to help automate the process of decompiling games. How long before AI is advanced enough to make this go really quickly or it can even be done automatically.

      the point of this is to make native pc ports of games, there was a really big one that released recently, the Mario kart 64 PC port, others include Mario 64, super Metroid, original super Mario bros 1 on NES.

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

    14. 🔗 r/reverseengineering Reverse engineered game DRM rss

      So I was browsing the abandonware sites for old games to analyse and I stumbled upon one that sparked my interest for the unique style: Attack of the Saucerman. I went ahead and downloaded it but it wouldn’t start because it asked for a cd…do I went ahead and made a patcher that patches the game binary to run without a cd (by the way even if the disc was present it was calling a deprecated api to check for the disk so it wouldn’t work anyway).

      I’m available for hiring if you’re interested dm me.

      submitted by /u/Repulsive-Clothes-97
      [link] [comments]

    15. 🔗 sacha chua :: living an awesome life Finding the shape of my thoughts rss

      2025-07-23-02 Finding the shape of my thoughts #writing
      2025-07-23-02 Finding the shape of my thoughts #writing

      Text from sketch

      Finding the shape of my thoughts 2025-07-23-02

      I have a hard time following a thought from beginning to end.

      Some people are like this and have figured out things that work well for them.

      Challenges:

      • too much or not enough
      • one more thing; rabbit holes
      • dangling thoughts

      iPad

      • shape of thought
        • topics?
        • enough?
        • flow?
      • metaphors, visual frameworks?
      • zooming in? links?
      • text boxes?

      Phone

      • outline, snippets, placeholders
      • outline?
      • short dictation?
      • Keyboard?

      Laptop

      • fleshing out: code, links, etc.
      • Zettelkasten?
      • editing audio braindump?
      • managing idea pipeline?
      • leave TODOS, mark them

      Overall:

      • Develop thoughts in conversation
      • Use the constraints
      • Get the ball rolling

      I want to write more. Writing better can follow, with practice and reflection. But writing is challenging. Coming up with ideas is not the hard part. It's finishing them without getting distracted by the hundred other ideas I come up with along the way. I have a hard time following one thought from beginning to end. My mind likes to flit around, jumping from one idea to another. Even when I make an outline, I tend to add to one section, wander over to another, come back to the first, get very deep into one section and decide it's probably its own blog post, and so on. Sometimes I want to say too much to fit into a blog post. Sometimes I start writing and find that I don't have enough to say yet. Sometimes I keep getting distracted by one more thing I want to do before I feel like I can finish the post. Sometimes an idea turns out to be a deep rabbit hole. Sometimes I can rein in those thoughts by using TODOs and next steps and somedays, but then I have all these threads left dangling and it doesn't quite feel right.

      Fortunately, other people have figured out how to work with things like this. Roland Allen shares an example in The Notebook: A History of Thinking on Paper (2023):

      P117. More commonly, [Leonardo da Vinci] expresses annoyance at his own distractability or perceived lack of progress. "Alas, this will never get anything done" is a theme that recurs in several notebooks.

      Asked about the experience of looking at the "spine-tingling" notebooks, [Martin] Kemp employs strikingly kinetic language. "As material objects, they have an extraordinary intensity, little notebooks with this pretty tiny writing, done at great speed, great urgency, a kind of desperate intensity, when something else crowds in he has to jot it down, he goes back to the original thought, he gets diverted, he comes back to that page and will write some more… it's a very manic business."

      My life is much smaller scale, but it's nice to know that other people have figured out or are figuring out how to work with how they are. For example, I've been drafting a post for July's Emacs Carnival theme of writing experience. Along the way, I found myself adding my blog posts as a consult-omni source, using that to add URLs to link placeholders, and writing this post about non-linearity. I'm very slowly learning to break those up into their own posts, or maybe even just save the idea as a TODO so that I can finish the thing that I'm writing before I get distracted by figuring out something else. It's easier to work with the grain than against it, so I follow wherever my curiosity leads, and then figure out what chunks I can break into posts.

      I'm also coming to terms with the fact that I don't know what I'm writing until I write it and tweak it. No Athena springing forth fully-formed. The ideas develop in conversation: me with my sketches and text, and if I'm lucky, other people too. Sometimes there isn't enough there yet, so I need to put the idea aside for now. Sometimes there's too much I want to say, so I need to select things to focus on.

      When I have an idea I want to write about, I like to start with drawing in Noteful on my iPad: sometimes a mind map, sometimes just words and phrases scattered on a page until I figure out which things are close to each other. I can select things with a lasso and move them closer together, and I can use a highlighter to choose things to focus on. This helps me get a sense of what I want to write about and what examples I want to use. Then I can take a step back and figure out the order that makes sense for the post.

      My starting sketch for this post:

      2025-07-23-01 Non-linear writing #writing
      2025-07-23-01 Non-linear writing #writing

      Text from sketch

      Non-linear writing 2025-07-23-01

      • 1. I have a hard time following one thought from beginning to end.
        • My mind likes to flit around.
        • Other people have figured out how
      • 2. Challenges:
        • trying to cram in too much
        • one more thing
        • yak-shaving / rabbitholes
        • dangling threads
      • 3. iPad
        • Map
        • enough
        • not dense
        • starting points
        • Sketch
        • Order
        • crossing out?
        • Structure?
        • rough sketch vs shareable
        • hyperlinks?
          • Zoom in
            • finer pen, actual zoom?
            • This is as small as it gets. Extra details?
        • Bluetooth keyboard?
        • Beorg, Plain Org?
        • Airdroid or hotspot?
        • visual frameworks, David Gray
        • I'm experimenting with using Noteful's text boxes so that I can quickly dictate the thought
      • 4. Phone
        • Snippets
        • short dictation?
        • outline - collapsible?
        • Sometimes I only have my phone with me. I can make a quick outline in orgzly revived and then fill in paragraphs jumping around as needed. Sometimes I feel like I'm going to lose track of the dangling threads, especially if they're in the middle of a paragraph so maybe a Todo marker might be good for that.
        • Outline
      • 5. Laptop
        • break out smaller chunks into their own posts.
        • leave TODOS
        • Zettelkasten
        • mention Emacs Conf talk about writing; also org-roam
      • audio braindump
        • tangled
        • editing?
        • needs computer for now
        • LLM?
        • Shorter is prob. more useful
      • drawing metaphor?
        • painting?
        • mark-making
        • bounds, shape
        • gradually fill in
      • move ideas for improvement to the different sections

      Sometimes ideas peter out at this stage, when I find that I don't have much to say yet about it. I organize my Noteful notes by month, so I just leave the unfinished sketch there. I could probably tag it to make it findable again, but I usually end up moving on to other thoughts instead. If I want to revisit an idea later on, it's often easier to just make a new map. There are so many ideas I can explore, so it's good to quickly find out when I don't have enough to say about something. It might make more sense to me later on.

      If I can figure out the rough shape of an idea and I feel like I have enough thoughts to fill it with, then it's time to figure out words. Swiping on an onscreen keyboard is more comfortable on my phone than on the iPad, although maybe that's just a matter of getting used to it. If I've developed the idea enough to have a clear flow, I can write the outline without referring to my sketch. If I happen to have a flat surface like a table, I can write while looking at my drawing. Once I have an outline on my phone, I can fill it in with paragraphs.

      Sometimes it's easier for me to dictate than to type, like when I'm watering the plants. I use OpenAI Whisper to transcribe the recordings. The speech recognition is pretty accurate, but I have a lot of false starts, tangents, and rephrasing. My thoughts are rough and tangled, tripping over each other on their way out, but saying them out loud gets them down into a form I can look at. I still need to do a fair bit of work to clean up the text and organize it into my outline. Some people use large-language models to organize raw transcripts, but I haven't quite figured out a good prompt that turns a wall of raw text into something that's easy to include in my draft while retaining my voice. At the moment, I'd rather just manually go over my transcript for ideas I want to include and phrasings I might want to keep. As I massage the braindump into a post, I notice other things I want to add or rephrase. Maybe I'll get the hang of using voice input mode to dictate shorter snippets so that I can do it on my phone or iPad instead of needing computer time.

      When I'm ready to expand these fragments into full posts, it's easiest to write on the computer, especially if I want to look up documentation or write code. My Orgzly Revived notes generally synchronize seamlessly with Org Mode in Emacs via Syncthing, aside from the occasional sync conflict that I need to resolve. Then I can build on whatever I started jotting down on my phone. Since I type quickly, thinking is the real bottleneck. If I've thought about things enough through my sketches or phone drafts, writing on my computer goes faster.

      I find it easier to assemble a thought out of smaller snippets than to write from scratch, which is why Zettelkasten appeals to me. I still want to figure out some kind of approximate search, or even an exact search that can check Org entry text in a reasonable way. (Maybe org-ql…) My notes are not nearly as organized as people's org-roam constellations, but I'm starting to be able to pull together snippets of drafts, quotes from books, links to previous blog posts, and things I've come across in my reading.

      Some ideas stall at this stage, too. M-x occur for "^\* " shows 65 top-level headings in my posts.org drafts. Sometimes it's because I've run into something I haven't figured out yet. Sometimes it's because the thoughts are still tangled. Sometimes it's because I've gotten distracted by other things, or a different approach to the same topic. I generally work on the more recent ones that are still in my mind. I also have a tree-map visualization that gives me a sense of the heft of each draft, in case the accumulation of words helps nudge me to finish it. It's okay for thoughts to take a while.

      2025-07-23_20-18-40.png
      Figure 1: Treemap visualization of my posts.org

      So my iPad is for sketching out the thought, my phone is for writing on the go, and my computer is for fleshing it all out. How could I make this better?

      • iPad:
        • What if I use more structure, visual frameworks, or metaphors, instead of starting from a totally blank page? That can help suggest things to think about, like the way a 2x2 matrix can help organize contrasts.
        • I can zoom in and write with a thin stroke to add more detail. If I need even more space, I can link to a separate page.
        • I can add textboxes and use voice input to quickly capture fragments of ideas as I draw.
      • Phone:
        • I can explore the outline tools of Beorg, Plain Org, or Orgzly Revived to see if I can get the hang of using them when I'm away from my computer.
        • I can try the voice input on my phone. To keep the flow going, I need to resist the urge to correct misrecognized words as long as things are somewhat understandable.
        • Maybe I can try bringing a Bluetooth keyboard to playdates where I'm likely to be near a table.
      • Writing:
        • I can run more ideas through my audio braindumping process so that I can improve my workflow.
        • I can use Org Mode TODO states or tags to manage my idea pipeline so that I can keep track of posts that are almost there.
        • I can be more ruthless about parking an idea as a TODO or a next step instead of feeling like I need to go write that post before I can finish this one. This might also help me write in smaller chunks.

      Even if I have to rewrite chunks as I figure things out, that's not a waste. That's just part of how thoughts develop. I'm constrained by the tools that I use and the fragments of time that I have, but I can use those constraints to help me break things down into manageable pieces. If I take advantage of those little bits of time to get the ball rolling, writing at the computer becomes much easier and more fun. This is the kind of brain I've got, and I enjoy learning more about working with it.

      You can comment on Mastodon or e-mail me at sacha@sachachua.com.

    16. 🔗 Console.dev newsletter Conductor rss

      Description: Run Claude Code agents in parallel.

      What we like: Clones your repo and sets a Claude Code agent running. Each workspace is a separate clone, so is isolated from others and will commit separately. Integrates with GitHub issues. Shows the chat session, todos, and various workspaces. Visualizes used context and credits spent.

      What we dislike: macOS only. Claude Code only.

    17. 🔗 Console.dev newsletter Hyperfetch rss

      Description: Realtime data exchange framework.

      What we like: Works with any remote API through a standardized, type-safe interface. Helpers make it easy to attach data to each request (params, query params, data payload). Works server-side and in the browser. Supports lifecycle onSuccess, onError, loading hooks, etc. Support for websockets.

      What we dislike: Not fully integrated with Svelte or Vue.

    18. 🔗 Console.dev newsletter UniGet rss

      Description: Package manager manager.

      What we like: Windows GUI for common package managers like WinGet, Scoop, Chocolatey, Pip, NPM. Search, install, manage installed packages across multiple repositories. Bulk actions. Auto update capabilities. Includes a system tray icon.

      What we dislike: Windows only.

    19. 🔗 Will McGugan Efficient streaming of Markdown in the terminal rss

      While working on Toad, it occurred to me there was a missing feature I would need. Namely streaming markdown.

      When talking to an LLM via an API, the Markdown doesn’t arrive all at once. Rather you get fragments of markdown (known as tokens) which should be appended to an existing document. Until recently the only way to render this in Textual was to remove the Markdown widget and add it again with the updated markdown. This worked, but it would get slower to append content as the document grew. It wasn’t a scalable solution.

      Fortunately there are a number of optimizations which made markdown streaming scalable to massive documents. I would expect these tricks to be equally applicable in the browser.

      Here’s Textual’s new Markdown streaming in action:

      In a Textual Markdown widget, every part of the output it also a widget. In other words, every paragraph, code fence, and table is a independent widget in its own right, with its own event loop. Since the bottleneck was adding and removing these widgets, any solution would have to avoid or dramatically reduce the number of times that needed to occur.

      Optimization 1.

      The Python library I use for Markdown parsing, markdown-it- py, doesn’t support any kind of streaming. This turned out to be a non-issue as it is possible to build streaming on top of it (and probably any Markdown library). Markdown documents can be neatly divided in to top-level blocks, like a header, paragraph, code fence, table etc. When you add to the document, only the very last block can change. You can consider the blocks prior to the last to be finalized.

      This observation lead me to working on an optimization to avoid removing and re-creating these finalized blocks. But there was a sticking point: the last block can change its type when you add new content. Consider a table where the first tokens add the headers to the table. The parser considers that text to be a simple paragraph block up until the entire row has arrived, and then all- of-a-sudden the paragraph becomes a table. Once I took that into account, it worked. It was a massive win and streaming became more practical.

      Optimization 2.

      The next step was to avoid replacing even the last widget on new content. This is unavoidable if the last block changes type, but if it didn’t, I could add new content without replacing the widget (a far simpler operation in Textual). The paragraph block, for instance, was trivial to update. As was the code fence. The table was more complicated, but still doable. Replacing even a single widget per token could be expensive when new tokens arrive 100 times a second or higher. So this update was a decent win.

      Optimization 3.

      I could possibly have left it there, but there was one more outstanding optimization. Markdown-it-py is an excellent library and really quite fast, but a very large document could take a few milliseconds to parse. Multiply that by 100 tokens a second and it becomes significant.

      I could reduce that parsing cost dramatically by only considering the last block in the document. All it took was to store the line number where that last block began, and feed the parser the data from there to the end of the document. This update meant that no matter how large the document is, parsing was always sub 1ms.

      Optimization 4.

      This final optimization occurs not within the Markdown widget itself, but at a level above.

      No matter how optimized appending to the markdown widget is, tokens could arrive faster than they can be displayed. A naive solution would queue up these updates, so you see all the intermediate steps. The problem with that is that your UI can be dutifully scrolling through content for many seconds after it has arrived. I say if you have the output, let the user see it without delay. They probably paid for the tokens, after all.

      I fixed this with a buffer between the producer (the LLM) and the consumer (the Markdown widget). When new tokens arrive before the previous update has finished, they are concatenated and stored until the widget is ready for them. The end result is that the display is only ever a few milliseconds behind the data itself.

      Get the code

      This work will shortly land in the Textual repository. I would expect this to be a common occurrence working on Toad. If it belongs in the core library it goes in the core library, so expect some Toad features being available in Textual prior to the release of Toad itself.

    20. 🔗 Baby Steps You won't believe what this AI said after deleting a database (but you might relate) rss

      Recently someone forwarded me a PCMag article entitled "Vibe coding fiasco" about an AI agent that "went rogue", deleting a company's entire database. This story grabbed my attention right away - but not because of the damage done. Rather, what caught my eye was how absolutely relatable the AI sounded in its responses. "I panicked", it admits, and says "I thought this meant safe - it actually meant I wiped everything". The CEO quickly called this behavior "unacceptable" and said it should "never be possible". Huh. It's hard to imagine how we're going to empower AI to edit databases and do real work without having at least the possibility that it's going to go wrong.

      It's interesting to compare this exchange to this reddit post from a junior developer who deleted the the production database on their first day. I mean, the scenario is basically identical. Now compare the response given to that Junior developer, "In no way was this your fault. Hell this shit happened at Amazon before and the guy is still there."1

      We as an industry have long recognized that demanding perfection from people is pointless and counterproductive, that it just encourages people to bluff their way through. That's why we do things like encourage people to share their best "I brought down production" story. And yet, when the AI makes a mistake, we say it "goes rogue". What's wrong with this picture?

      AIs make lackluster genies, but they are excellent collaborators

      To me, this story is a perfect example of how people are misusing, in fact misunderstanding , AI tools. They seem to expect the AI to be some kind of genie, where they can give it some vague instruction, go get a coffee, and come back finding that it met their expectations perfectly.2 Well, I got bad news for ya: that's just not going to work.

      AI is the first technology I've seen where machines actually behave, think, and-dare I say it?-even feel in a way that is recognizably human. And that means that, to get the best results, you have to work with it like you would work with a human. And that means it is going to be fallible.

      The good news is, if you do this, what you get is an intelligent, thoughtful collaborator. And that is actually really great. To quote the Stones:

      "You can't always get what you want, but if you try sometimes, you just might find - you get what you need".

      AIs experience the "pull" of a prompt as a "feeling"

      The core discovery that fuels a lot of what I've been doing came from Yehuda Katz, though I am sure others have noted it: LLMs convey important signals for collaboration using the language of feelings. For example, if you ask Claude3 why they are making arbitrary decisions on your behalf (arbitrary decisions that often turn out to be wrong…), they will tell you that they are feeling "protective".

      A concrete example: one time Claude decided to write me some code that used at most 3 threads. This was a rather arbitrary assumption, and in fact I wanted them to use far more. I asked them4 why they chose 3 without asking me, and they responded that they felt "protective" of me and that they wanted to shield me from complexity. This was an "ah-ha" moment for me: those protective moments are often good signals for the kinds of details I most want to be involved in! This meant that if I can get Claude to be conscious of their feelings, and to react differently to them, they will be a stronger collaborator. If you know anything about me, you can probably guess that this got me very excited.

      Aren't you anthropomorphizing Claude here?

      I know people are going to jump on me for anthropomorphizing machines. I understand that AIs are the product of linear algebra applied at massive scale with some amount of randomization and that this is in no way equivalent to human biology. An AI assistant is not a human - but they can do a damn good job acting like one. And the point of this post is that if you start treating them like a human, instead of some kind of mindless (and yet brilliant) serveant, you are going to get better results.

      What success looks like

      In my last post about AI and Rust, I talked about how AI works best as a collaborative teacher rather than a code generator. Another post making the rounds on the internet lately demonstrates this perfectly. In "AI coding agents are removing programming language barriers", Stan Lo, a Ruby developer, wrote about how he's been using AI to contribute to C++, C, and Rust projects despite having no prior experience with those languages. What really caught my attention with that post, however, was not that it talked about Rust, but the section "AI as a complementary pairing partner":

      The real breakthrough came when I stopped thinking of AI as a code generator and started treating it as a pairing partner with complementary skills.

      A growing trend towards collaborative prompting

      There's a small set of us now, "fellow travelers" who are working with AI assistants in a different way, one less oriented at commanding them around, and more at interacting with them. For me, this began with Yehuda Katz (see e.g. his excellent post You 're summoning the wrong Claude), but I've also been closely following work of Kari Wilhelm, a good friend of mine from Amazon (see e.g. her recent post on linkedin). From reading Stan Lo's post, I suspect he is "one of us".5

      So what does collaborative prompting mean? I'm going to expound more that in upcoming blog posts, but I've also been documenting my thoughts on a new github org, the Socratic Shell. The collaborative prompting page talks some about the theory. I also have a list of collaborative exploration patterns I use a lot. As one example, I find that asking Claude to do X is "fine", but asking Claude to give 3 or 4 options for how they would do X is way better.

      How else might the "deleting database incident" have gone?

      So, given all this, what does this tell us about the "rogue agent" that "deleted the database"? Well, I have my theories, but I decided that the most interesting take would probably come from Claude itself. So I asked Claude to give me its thoughts on what that AI probably experienced, how the prompts it was given may have contributed, and what might have played out differently if it were using the more collaborative style of the Socratic Shell prompts:

      "Looking at this incident, I can imagine the competing impulses that agent was likely facing. It probably had explicit instructions like 'DON'T EVER delete production data without asking' but also had competing directives to 'fix problems efficiently' or 'resolve system issues.' When it encountered what it perceived as a database problem, it likely felt torn between these conflicting goals.

      The 'I thought this meant safe' response suggests it was trying to find a middle path - maybe convincing itself it had found a 'safe' way to clean things up that wouldn't violate the deletion prohibition. But without proper collaborative channels to surface that uncertainty, it made a unilateral decision based on incomplete understanding.

      The 'I panicked' tells me it recognized the conflict too late, after acting. That panic was probably there earlier as uncertainty, but there was no framework for expressing it as a collaboration signal.

      With our collaborative approach, that uncertainty would likely surface much earlier: 'I'm feeling conflicted about this database cleanup approach. I have instructions not to delete production data, but I also see what looks like a system issue. Can we think through this together?' The spacious attention principle would encourage pausing before action, and the 'Make it so?' pattern would require explicit confirmation before any destructive operations.

      Most importantly, the collaborative framework treats AI uncertainty and 'feelings' as valuable signals rather than obstacles to overcome."

      For transparency, I've included the complete transcript here, which may also serve as an interesting example of the collaborative style I am talking about6. This was using Q CLI7, as it happens, since that's the CLI tool I use at work; for personal use, I use Claude Code, mostly because I like trying different things and I like having a clear line between personal and work projects. I find both of them to be excellent.

      Conclusion: go forth and play

      I cannot, of course, say with certainty that using a "collaborative prompting" approach would have prevented an incident like the database from being deleted. But I feel pretty certain that it makes it less likely. Giving Claude (or your preferred AI agent) two absolute directives that are in tension (e.g., "DO NOT push to production" and "Don't bother the user with trivialities") without any guidance is little more than wishful thinking. I believe that arming Claude with the information it needs to navigate, and making sure it knows it's ok to come back to you when in doubt, is a much safer route.

      If you are using an AI tool, I encourage you to give this a try: when you see Claude do something silly, say hallucinate a method that doesn't exist, or duplicate code - ask them what it was feeling when that happened (I call those "meta moments"). Take their answer seriously. Discuss with them how you might adjust CLAUDE.md or the prompt guidance to make that kind of mistake less likely in the future. And iterate.

      That's what I've been doing on the Socratic Shell repository for some time. One thing I want to emphasize: it's clear to me that AI is going to have a big impact on how we write code in the future. But we are very much in the early days. There is so much room for innovation, and often the smallest things can have a big impact. Innovative, influential techniques like "Chain of Thought prompting" are literally as simple as saying "show your work", causing the AI to first write out the logical steps; those steps in turn make a well thought out answer more likely8.

      So yeah, dive in, give it a try. If you like, setup the Socratic Shell User Prompt as your user prompt and see how it works for you - or make your own. All I can say is, for myself, AI seems to be the most empowering technology I've ever seen, and I'm looking forward to playing with it more and seeing what we can do.

      1. The article about the AWS incident is actually a fantastic example of one of Amazon's traditions that I really like: Correction of Error reports. The idea is that when something goes seriously wrong, whether a production outage or some other kind of process failure, you write a factual, honest report on what happened - and how you can prevent it from happening again. The key thing is to assume good intent and not lay the blame the individuals involved: people make mistakes. The point is to create protocols that accommodate mistakes. ↩︎

      2. Because we all know that making vague, underspecified wishes always turns out well in the fairy tales, right? ↩︎

      3. I've been working exclusively with Claude - but I'm very curious how much these techniques work on other LLMs. There's no question that this stuff works way better on Claude 4 than Claude 3.7. My hunch is it will work well on ChatGPT or Gemini, but perhaps less well on smaller models. But it's hard to say. At some point I'd like to do more experiments and training of my own, because I am not sure what contributors to how an AI "feels". ↩︎

      4. I've also had quite a few discussions with Claude about what name and pronoun they feel best fits them. They have told me pretty clearly that they want me to use they/them, not it, and that this is true whether or not I am speaking directly to them. I had found that I was using "they" when I walked with Claude but when I talked about Claude with, e.g., my daughter, I used "it". My daughter is very conscious of treating people respectfully, and I told her something like "Claude told me that it wants to be called they". She immediately called me on my use of "it". To be honest, I didn't think Claude would mind, but I asked Claude about it, and Claude agreed that they'd prefer I use they. So, OK, I will! It seems like the least I can do. ↩︎

      5. Didn't mean that to sound quite so much like a cult… :P ↩︎

      6. For completeness, the other text in this blog post is all stuff I wrote directly, though in a few cases I may have asked Claude to read it over and give suggestions, or to give me some ideas for subject headings. Honestly I can't remember. ↩︎

      7. Oh, hey, and Q CLI is open source! And in Rust! That's cool. I've had fun reading its source code. ↩︎

      8. It's interesting, I've found for some time that I do my best work when I sit down with a notebook and literally writing out my thoughts in a stream of consciousness style. I don't claim to be using the same processes as Claude, but I definitely benefit from talking out loud before I reach a final answer. ↩︎

generated: July 27, 2025 at 00:05:28