[0]: https://stripe.com/blog/online-migrations

Not sure I agree with his conclusion though - once all manufacturers are required to include the technology, surely they will still compete on price and find ways to get cheaper models to market? They will be unencumbered by the risk of patent violation to innovate on cheaper approaches to the same problem.

He also argues for riving knives and blade guards as an alternative, which are great, but not all cuts can be made with them in place.

As a hobby woodworker that sometimes makes mistakes, I've wanted a SawStop for a long time but have been stymied by the cost, so maybe I'm just being optimistic.

It seems to take the durable workflow idea and lock you into a specific language, operating system, and database, when other projects in the same space give you choice over those components.

I assume "candidates" was supposed to be "caveats" - and as an author of a "standard" macaroon implementation, I completely agree that this is the biggest downfall of Macaroons. With no common caveat language (and no independent "dischargers") it really limits their use to within a single org. And at that point you're basically asking everyone to invent their own token format anyway.

Though I don't personally use them much anymore - I think the use-cases for Macaroons are much more limited if you have a Zanzibar! - I appreciate seeing Macaroon discussions pop up and this post and the related discussions it linked out to were a great read.

The paper calls them Macaroons as a play on (browser) Cookies with layers (of caveats) - so clearly they meant macarons as well, since a macaroon doesn't have layers. Or at least, that's always been my interpretation of the name. It's possible it was just an arbitrary play on hMAC cookies and not the layers?

Internal applications don't have this problem, so you can easily keep your chart interface simple and scoped to the different ways you need to deploy your own stack.

With Kustomize, you just publish the base manifests and users can override whatever they want. Not that Kustomize doesn't have its own set of problems.

I've been dealing with this as well, and the uncertainty has been the most frustrating thing.

Medical bills from the same institution should be required to be high watermarks - i.e. if you give me a bill in March, you can't send me a bill in April that has charges from February that _weren't on the bill from March_. It feels like fraud (and maybe it is, but who has time to figure that out?)

One thing that stands out with Lutron products is their use of a unique spectrum[0], unlike almost all other smarthome products that share the same noisy bands.

[0]: https://assets.lutron.com/a/documents/clear_connect_technolo...

Wirecutter articles are essentially long, well-researched ads for the products they (affiliate) link to.

I always found these ads useful, at least as a starting point. But putting a paywall in front of the ads rubs me the wrong way, like an unwritten contract was broken.

- Authz data is kept in memory, so what you can authorize over is limited by the memory of the box you run OPAL/OPA. The docs also mention sharding, but I'm not clear on how you actually do that with OPA. [0] Maybe there's another doc that I missed.

- You can get a token representing the last time data was synced to the cache in an OPAL health check, but I'm not clear on how you'd use it to ensure consistency in your application since hydrating the cache is asynchronous. [1]

Anyway, those are the types of things Zanzibar is concerned with, so that comparison (instead of Cedar) would've made more sense to me. Without spending more time on it, I'm not sure if I've represented OPAL correctly above, that's just what I found when I went looking.

[0]: https://docs.opal.ac/faq/#handling-a-lot-of-data-in-opa

[1]: https://docs.opal.ac/faq/#how-does-opal-guarantee-that-the-p...

But policy engines are only really fast and simple if they already have all of the data they need at evaluation time.

If you look at the examples in the Cedar playground[0], they require you to provide a list of "entities" to Cedar at eval-time. These entities are some (potentially large) chunk of your application's data. And while the policy evaluation over that data may be fast, the round trip to your database is probably not. And then you start to think about caching, data consistency, and so on, and suddenly you're thinking about a lot of the problems that Zanzibar was designed to address (but you're on your own to build it out).

IMO policy engines are best suited for ambient request data: things you already know about a request because of a session, a route, or a network path, and policies that make sense to manage on the same lifecycle as your application.

Disclaimer: I work on SpiceDB[1], a Zanzibar implementation, but I do also like policy engines.

[0]: https://www.cedarpolicy.com/en/playground

[1]: https://github.com/authzed/spicedb

Found this paper from 1982: https://www.jstor.org/stable/44540143

Some that I've listened to are good on both fronts (in my opinion): Mission To Zyxx, Dungeons and Daddies, Beef and Dairy Network.

Make is still really about file to file transformations, and `go` already wraps up all of the behavior one would normally use make for. Plus you need make + a shell + go, vs. mage where all that's needed is go.

I can't speak for the author, but I assume they're reacting to how Makefiles tend to be used in go projects and not how make works generally.

It's more task-oriented, the way people tend to write Makefiles with .PHONY rules, but it's all in go. It can be bootstrapped just with go too, and comes with some utilities to do make-like incremental builds if you need to.

[0]: https://magefile.org/

In cue there's no real distinction between "schemas" and "documents". If you say:

   value: string
   value: "abc"

It's been a while since I've listened, but I remember it being pretty interesting.