awkii

Oh neat! Yup, that's what I was looking for, and I totally missed this. Thanks for the tip.

I've developed something similar for personal use. A harness who's only job is to delegate to other harnesses (i.e: AntiGravity, Codex, Claude Code, Hermes) to create an opencode-web-like interface across multiple hosts.

For Claude Code, don't use remote-connections. Your best option is to look at how the closed-source VSCode plugin interfaces with Claude Code. The way it works is that it reads files directly. This API, although unofficial, is likely very stable, because an old VSCode extension still has to interact with new version of Claude Code.

If there's any interest in this sort of thing, maybe I'll open-source it. I would have to cleanup the slop though.

I'm apparently from the very small faction of users who's been running `--dangerously-skip-permissions` in every instance of Claude for the last year. It's almost a reflex to me. For the most part Claude behaves well, but I don't blindly trust it. LLMs are inherently dangerous tools, and reviewing individual commands (or spamming `y`) doesn't make them less so. Safety is the responsibility of the developer putting sane guardrails (like VCS, immutable filesystems, or read-only tokens). Using more Claude to categorize the safety of Claude commands is not the answer.

This poor soul. There are few protocols I hate implementing more than WebRTC. Getting a simple client going means you need to quickly acclimate to SDP, TURN/STUN, ice-candidates, offers, peer-to-peer protocols, and the complex handshake that is implemented from scratch each time. I can't imagine re-writing the whole trenchcoat of protocols and unintended "best-practices".

I'll take a contrarian view here. Disclaimer: I'm interpreting "safe" as in "usability". I've been driving Ubuntu for years for gaming purposes, and it's come a long way. Most drivers are installed out-of-the box. The apps I care about run just fine.

But.... Relative to MacOS Ubuntu is certainly not as user-friendly. It's worth noting that Linux distros will force you to confront the command line at some point. If you come from OS-es where the most technical thing you have to do is pop open settings to set screen-share permissions or "right-click -> open" to install a package, you'll notice a stark difference.

He is never late, nor is he early. He arrives precisely when he means to.

Amazing that this post went up ~20 minutes after the cert expired

Issued On: Tuesday, April 8, 2025 at 11:26:21 AM

Expires On: Monday, July 7, 2025 at 11:26:20 AM

What the author touches on with before and after "declarative thinking" is largely applicable to all Directed Acyclic Graph (DAG) workflows, and not just signals. They are 100% correct that there is a mental shift. Yes, you can use magic to implicitly declare your DAGs with signals. You can also be really explicit with dependencies.

DAG-based workflows incur a cost in terms of complexity, but there are a few advantages to using DAGs instead of sequential.

1. Parallelism becomes inherently built-in

2. It's easier for a new developer to understand the direct dependencies of a node on other nodes (compared to sequential). Sometime in the future, a developer may want to split off a task or move it up/downstream of other tasks.

3. Fault tolerance & recovery becomes easier. Just because 1 step fails, doesn't mean that the whole workflow must come to a halt.

I have aphantasia, and today I learned that I also have SDAM.

There are benefits. For example, I find that I have no issue forgiving people. It's more work for me to harbor a grudge. I don't relive the burden of that initial pain of betrayal when someone close to me harms me, so it's easy to forgive and literally forget.

Fun fact: My dreams are very rarely visual.

I think the author has a point with one-way doors slowing down the adoption of distributed systems. The best way to build two way doors is to push for industry adoption of a particular API. In theory the backend of these APIs matter little to me, the developer, so long as they are fast and consistent. Some examples that come to mind is that Apache Beam is a "programming model" for Data pipelines, Akka is a "programming model" for stateful distributed systems, OpenTelemetry for logging/telemetry, and Kubernetes for orchestration. Oh, and local development is a strong preference.

You're describing the parallelized web-scraper that they pointed to their own internal site? Yeah that was fun. Too bad everyone got the same question.