Yeah, the underlying sandbox technology between Ash and CC is fundamentally different.
Ash is built on the Endpoint Security and Network Extension APIs. Together, they cover the full gamut of potential sandbox escapes, and it's a simple process to update sandbox rules while the sandboxed process is running.
Claude Code sandbox is built mainly on sandbox-exec, an older macOS sandbox technology. It works for filesystem and IO device control, but it can only filter network requests by IP address. CC uses an application-level network proxy as a workaround, but not every network client respects the HTTP_PROXY env variable it requires. There are other workarounds in CC sandbox for complex use cases (e.g. dangerouslyDisableSandbox) that Ash does not need.
Your feedback about permissions is something I'm working on fixing now. Apple requires multiple permissions for Endpoint Security and Network Extension APIs and the current setup process doesn't walk users through that process as elegantly as I would like it to.
I'd be interested in seeing a breakdown in which ones use:
- VMs
- Containers
- sandbox-exec (macOS builtin tool)
- Endpoint Security + Network Extension (AFAIK this is just Ash but it would be good to see company here)
There is a very to-the-point diagram called the Hydrogen Ladder [0] that classifies the usefulness of hydrogen by domain. The author makes a good case that, despite its versatility, hydrogen is almost always worse than some other clean technology for any use case. It’s hard to make, store, and use in a scalable/cheap way, and even generous estimates of future progress show a cost curve that requires subsidies basically forever.
Buses are classified as a “Most Uncompetitive” category. Electricity, whether wired or battery powered, is cheaper and easier to scale for the predicable everyday energy use of a city bus.
Email federation is more than just the addressing system. Even with a consistent address, your host still needs to be able to send and receive SMTP messages to participate in the ecosystem.
Address lock-in is real but doesn't fully negate the benefits of federation. Even if you don't control your address's domain, you can switch providers without losing the ability to send and receive email. There is extra cost in pointing your bank account to your new address, but it is possible. If your bank communicated to you via a non-federated protocol like WhatsApp, switching would be impossible.
One unmentioned feature of federation is that it lowers the cost of switching. If your provider begins to misbehave, you can jump to another one. This is especially true in email, where you can move from one host to another by updating your domain's MX records.
Without federation, switching means migrating both your host and your network of participants simultaneously. That is a much harder and more expensive coordination problem.
This looks pretty interesting. Besides telephony and other message-passing applications, what are the hero use cases for an actor system on an embedded device?
The structure of your website's data is less important than its moderation process. High quality online communities tend to have strong, well-defined moderation policies – Wikipedia and Stack Overflow are good examples, as are HN and certain subreddits (eg AskHistorians).
Regardless of the technology behind a website, online communities without strong moderation tend to die over time as low quality content crowds out everything else.
> I think that in studying economic growth, we (and especially we in the Silicon Valley) focus way too much on gadgets, and too little on the simple fact of human knowledge of how to do things.
This is a major component of software's power – it's a tool for formalizing knowledge and skills permanently and distributing it rapidly at ~0 marginal cost. If a piece of software is both correct and performant, it can last a very, very long time, possibly outliving its creators. And the best software composes, so one program can build on top of another to build up a massive skillset.
It’s dynamically-typed and it doesn’t have real arrays. It can sometimes be frustratingly slow to do things that imperative languages do easily, but that’s the price of entry for functional languages. Luckily you can drop down into Rust or C if you need high performance.
Otherwise, it’s a great language. I’m consistently happy with the decisions that the Erlang and Elixir core teams make, and it’s my go-to language for web development.
That's true. My performance claims are biased toward offline-capable editors, where the last consistent state between sites may be thousands or millions of edits ago. For online-only editors the set of edits between now and the most recent consistent state may be much smaller.
My understanding of OT is that each change requires traveling backward though the edit history to find the first state that is consistent between sites, then traveling forward to transform the new change against past edits. In the worst case, an edit requires transformation against the document’s origin state.
Here's the key sentence: "concrete implementations of CRDT in co-editors revealed key missing steps in CRDT literature." This paper may be correct for academic CRDTs but it is very wrong when looking at industry implementations.
My hunch is that because CRDTs are so much easier to grok than OT, engineers are empowered to make use case-specific improvements that aren't reflected in academic literature.
For example, the Logoot/LSEQ CRDTs have issues with concurrent insert interleaving; however, this can be solved by dedicating a bit-space in each ID solely for followup inserts. The "Inconsistent-Position-Integer-Ordering" problem is solved by comparing ids level-by-level instead of in one shot.
Fundamentally, CRDTs have strong strategic advantages over OT. Given a document size N and a document edit history H:
* CRDT size is O(N) where OT is O(H)
* CRDT updates are O(log N) where OT is O(H^2)
In any nontrivial document, H ≫ N. This means CRDTs have much better perf than OT. Additionally, the best CRDTs (like Logoot/LSEQ) don't require tombstones, garbage collection, or "quiescence." The complexity burden is far lower.
To top it off, CRDTs are offline-capable by default.
I would go with the simplest solution that lets you ship. For basic web apps, I find k8s is overkill.
However, once you need service discovery, secret management, auto scaling, etc k8s is the least bad solution I’ve found. I ended up using GKS but that was before AWS released a competitor.
That's what I'm currently using! The downside with configuring via CLI is that anyone who needs to update the cluster has to download the tool, make sure they have the right AWS keypair installed, make sure their config is correct, etc. I guess I could just install kops on a server, but provisioning a server to provision the server that provisions servers is just too meta for me.
A saas that puts a UI on top of kops would be ideal, but that might not exist as a standalone service.
I'd mostly agree, and the packages you've written (ExRM and Distillery) make releases super easy to build, start, and stop.
The main benefit of Go, I think, is that it can cross-compile builds. Erlang and Elixir don't have any way to do that, so if you develop on Mac and deploy on Linux you'll need to build your release in a VM or on a build server running Linux.
Ash is built on the Endpoint Security and Network Extension APIs. Together, they cover the full gamut of potential sandbox escapes, and it's a simple process to update sandbox rules while the sandboxed process is running.
Claude Code sandbox is built mainly on sandbox-exec, an older macOS sandbox technology. It works for filesystem and IO device control, but it can only filter network requests by IP address. CC uses an application-level network proxy as a workaround, but not every network client respects the HTTP_PROXY env variable it requires. There are other workarounds in CC sandbox for complex use cases (e.g. dangerouslyDisableSandbox) that Ash does not need.