amsha

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.

Good idea about the GitHub stub repo, I've added it here: https://github.com/Ash-Sandbox/bugs.

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.

Yeah I think that's a good point. I've added process-specific network access to the roadmap: https://github.com/Ash-Sandbox/bugs/issues/1

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)

Yeah I like the idea of allowing the sandbox to restrict network connections to specific processes. I'll put it on the roadmap: https://github.com/Ash-Sandbox/bugs/issues/1

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.

0: https://www.liebreich.com/hydrogen-ladder-version-5-0/

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.

Is that not the case?

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.

Are there any specific actions Seattle has taken to make the driving experience worse?

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.

Unfortunately ECS doesn't provide Kubernetes clusters, it's a proprietary orchestration platform with its own feature set.

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.

Yeah, disabling the discrete card made a huge difference to my laptop's stability (also 2010 15" MBP with NVIDIA GT 330M). There's an open-source app called gfxCardStatus [0] that lets you switch between integrated and discrete from the menubar.

On 10.12 the original app doesn't work properly, but one of its forks [1] fixes the issue.

[0] https://github.com/codykrieger/gfxCardStatus

[1] https://github.com/steveschow/gfxCardStatus/releases

Does anyone here have insight into how widely Pronovost's ideas have been implemented since the article was published?

Yes, email is federated.

Any programming language can do IPC, but Erlang/Elixir is the only language I've seen that makes it really easy. Erlang IPC is transparent whether you're sending messages between to local processes or remote processes. Most languages have trouble with local IPC (usually because of race conditions in data). Every other language I know of, including Go, needs custom code to handle remote IPC.

In my experience, writing (or any other art) is maybe the most downwardly-mobile profession there is. The supply of artists far outstrips the demand for art, and getting your first job often depends on proximity to industry gatekeepers. I can't speak specifically for the publishing industry, but in film and television people tend to get writing jobs through personal connections.

The four paths I've seen for people who make it in film/tv:

* Have a family member who gets you your first job.

* Have rich parents who completely subsidize your work for a few years and provide anonymous funding for your first feature film.

* Have upper-middle class parents who partially subsidize your work for a few years, and get ready to be an assistant for 3-25 years while you build connections with the business bros that determine your future.

* Have lower-middle class parents. Be extraordinarily driven and ignore all material needs while you win festivals and get noticed.

The lower you are on the list, the more effort it takes to maximize your probability of success. Realistically, almost no one makes it from the bottom category.

More concretely, Phoenix sets itself apart through its own features, Elixir's features, and an (as far as I've seen) unparalleled commitment to the community:

* PubSub, so if you're building a communication-based app your job is automatically easier.

* asynchronous jobs by default (it's a language feature), so if you need background processing your job is automatically easier.

* Rails-like database interactions. I don't know of any framework that makes dealing with the database as simple as Rails, and Phoenix (really Ecto, the ORM it uses) matches that simplicity. Models, validations, transactions, queries, migrations - it all feels very well thought-out. First-class support for PostgreSQL arrays and json(b) are nice-to-have, too.

* Fast templates. Template rendering is one of the biggest performance problems in Rails, and Phoenix solves it with some compile-time tricks.

* Built-in support for multiplexed real-time communication channels. If you need to push data to clients, your job just became easier (notice a trend?). It supports both WebSockets and long-polling so you don't have to make the hard choice about whether that new feature is worth the risk of losing users on outdated browsers.

* Asset building, another built-in goody that very few other frameworks have. The choice to use Brunch (rather than WebPack) is debatable, but I think that having a controversial build tool is 100x better than having no build tool.

* IRC support: If you ask a question, you will get a complete answer without anyone telling you to RTFM. This is both good and necessary because, although the official documentation is pretty good, Phoenix and its dependencies don't have the huge number of blogpost tutorials and StackOverflow answers that make Rails so easy to learn. I suspect this will change over time as the community grows.

* It keeps getting better. This is an outsider's perspective, but after lurking on #elixir-lang, Phoenix-Core, Phoenix-Talk, etc. it's obvious to me that Phoenix and Elixir are going to be better in 2017 than they are in 2016. Its core contributors are knowledgeable and dedicated, and many of them are being paid for their open-source work. That gives me confidence in the future.

Security and fault-tolerance are cost centers, so unless they are explicit features of a deliverable they will be ignored. Planes, cars, and banks all have anomaly detection and auditing because people demand it. They understand the risks of failure. Conversely, very few people are demanding remote loopback facilities for IP. That's not a criticism of fault-tolerance, but if it's important then we should communicate more effectively. Why is fault-tolerance important? What goes wrong without it? What catastrophes could have been averted if we had considered it?

Edit for clarity