Why was this disclosed before the hole was patched in the stable release?

It's only been 18 days since the bug was reported to upstream, which is much shorter than typical vulnerability disclosure deadlines. The upstream commit (https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30...) has way less information than this blog post, so I think releasing this blog post now materially increases the chance that this will be exploited in the wild.

Update: The author was able to develop an exploit by prompting an LLM with just the upstream commit, but I still think this blog post raises the visibility of the vulnerability.

- Hacker News Guidelines https://news.ycombinator.com/newsguidelines.html

I have an M4 MacBook Air with 24 GB RAM and it doesn’t feel sufficient to run a substantial coding model (in addition to all my desktop apps). I’m thinking about upgrading to an M5 MacBook Pro with much more RAM, but I think the capabilities of cloud-hosted models will always run ahead of local models and it might never be that useful to do local inference. In the cloud you can run multiple models in parallel (e.g. to work on different problems in parallel) but locally you only have a fixed amount of memory bandwidth so running multiple model instances in parallel is slower.

[1] https://9to5mac.com/2026/03/03/apple-macbook-price-increase-...

Comments URL: https://news.ycombinator.com/item?id=47368376

Points: 3

# Comments: 0

The decision to pass all params as a JSON string to --params makes it unfriendly for humans to experiment with, although Claude Code managed to one-shot the right command for me, so I guess this is fine. This is an intentional design per https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...

Claude 4.6 Opus and Gemini 3.1 Pro can to some degree, although the 3D models they produce are often deficient in some way that my eval didn't capture.

My eval used OpenSCAD simply due to familiarity and not having time to experiment with build123d/CadQuery. There is an academic paper where they were successful at fine-tuning a small VLM to do CadQuery: https://arxiv.org/pdf/2505.14646

Comments URL: https://news.ycombinator.com/item?id=47147361

Points: 2

# Comments: 2

The simulator lets the LLM request renders from different angles/times, so the LLM can get visual feedback. For failures, the simulator also returns status codes like `object_fell` or `mount_initially_collided_with_object` depending on what happened. You can see what the tool call looks like by looking at the Transcript tab, e.g. here https://kerrickstaley.com/ai-cad-design-mount-viz/gso__mug__...

I agree it's not clear how much benefit models get from iteration. Many of the successful runs are one-shots. You can see some examples of basic spatial reasoning e.g. here https://kerrickstaley.com/ai-cad-design-mount-viz/gso__mug__... :

> The initial collision is because the mount was positioned at the same height as the mug's body center (z=-22), causing overlap. I need to lower the mount significantly so the mug starts above it and drops into the cradle.

Comments URL: https://news.ycombinator.com/item?id=47132842

Points: 15

# Comments: 4

  a = b = []

  b = []
  a = b

Unfortunately certain commands like `rg` will return non-zero by design when there are no matches, which could be an intentional outcome.

I think this tech has become "production-ready" recently due to a combination of research progress (the seminal paper was published in 2023 https://repo-sam.inria.fr/fungraph/3d-gaussian-splatting/) and improvements to differentiable programming libraries (e.g. PyTorch) and GPU hardware.

None of the frontier LLMs (Gemini, ChatGPT, Claude) produce usable designs when just prompted with some photos of the pump and a written description of the mount. I'm now building a simulator in Mujoco that the LLMs can use to test and iterate on their designs to see if they can do better in this setting.

I'm hoping to make an interesting blog post of it and maybe end up with a usable wall mount design.

Like the post mentions, I think this happens because the devices are missing two resistors that are needed to indicate, when connected via a USB-C to USB-C cable to a charging brick, that the device wants 5V power. Resistors are cheap and I think the only reason they get dropped is carelessness.

The whole point of USB-C is that you can charge any device with any power supply.