You don’t. The external system needs to run an approximation of the internal system, which the internal system will also run and only transmit differences.
There you go. Solved it. (By delegating to a new problem.)
The secret of AI is that it’s really exploited humans all the way down.
The unpaid people who produce the training data, the underpaid people who categorize it, the underpaid people who rate the model’s responses, and the underpaid (and t r a u m a t i z e d) people who review flagged user interactions.
It's the same playbook as ever. Doubt can only be explained by ignorance, failure can only be explained by under-committing,
The only way to have a "valid" opinion is to have already bought-in and be actively selling other people on it. It's the same mentality as a cult or a pyramid scheme.
I feel there now has to be a distinction made between “Capital Libertarians” and “Individual Libertarians”.
You might be interested in Isaiah Berlin's "Two Concepts of Liberty".
Basically, there is no absolute thing called "liberty", because anything you do changes the material world and the state of the material world also shapes what you're able to do. So you can't talk about simply "liberty", and must always describe it in terms of those two relationships. What Berlin calls "freedom to" and "freedom from".
For instance, I might consider my liberty to mean that I have the "freedom to" shoot a gun in the air. My neighbors might consider their liberty to mean that they have the "freedom from" falling bullets.
We can't create a policy which guarantees both "freedom to" and "freedom from" for all people. But we can create a policy that guarantees both for some people. We just have to allow that some people get to enjoy both the rights and the protections, while other people lack the rights and must suffer the consequences of others' actions.
And that might be why the contemporary conservative version of so-called "libertarianism" plays so well with a notion of a superior social class, whether that's economic, religious, or racial. You can invoke the word "liberty" in support of your attempts to bully others, and then you can invoke it again as a protection against others' attempts to bully you.
It is strange and striking that climate change activists have not committed any acts of terrorism. After all, terrorism is for the individual by far the modern world’s most effective form of political action, and climate change is an issue about which people feel just as strongly as about, say, animal rights. This is especially noticeable when you bear in mind the ease of things like blowing up petrol stations, or vandalising SUVs. In cities, SUVs are loathed by everyone except the people who drive them; and in a city the size of London, a few dozen people could in a short space of time make the ownership of these cars effectively impossible, just by running keys down the side of them, at a cost to the owner of several thousand pounds a time. Say fifty people vandalising four cars each every night for a month: six thousand trashed SUVs in a month and the Chelsea tractors would soon be disappearing from our streets. So why don’t these things happen?
But LoSavio had opted out of the arbitration agreement and was given the option of filing an amended complaint.
This is why it’s important to opt out of arbitration!
Also notice the potential for fuckery in the statute of limitations here:
the relevant statutes of limitations range from two to four years, and LoSavio sued over five years after buying the car. Under the delayed discovery rule, the limitations period begins when "the plaintiff has, or should have, inquiry notice of the cause of action."
But when Tesla declined to update his car's cameras in April 2022, "LoSavio allegedly discovered that he had been misled by Tesla's claim that his car had all the hardware needed for full automation."
Without that specific moment to point to, to reset the clock through delayed discovery, Tesla could just say “Yeah, we lied, but you bought the lie for 5 years, so now we’re in the clear!”
I'm talking about user interactions, not deployments.
In a monolith with a transactional data store, you can have a nice and clean atomic state transition from one complete, valid state to the next in a single request/response.
With a distributed system, you'll often have scenarios where the component which receives the initial request can't guarantee the final state of the system by the time it needs to produce a response.
If it did, it would spend most of its effort orchestrating other components. That would couple them together and be no more useful than a monolith, just with new and exciting failure modes. So really the best it can do is tell the client "Here's a token you can use to check back on the state of this operation later".
And because data is often partitioned between different services, you can end up having partially-applied state changes. This leaves the data in an otherwise-invalid state, which must be accounted for -- simply because of an implementation detail, not because it's semantically meaningful to the client.
In operations that have irreversible or non-idempotent external side-effects, this can be especially difficult to manage. You may want to allow the client to resume from immediately before or after the side-effect if there is a failure later on. Or you may want to schedule the side-effect, from the perspective of an earlier component in the chain, so that it happens even if a middle component fails (like the equivalent of a catch or finally block).
If you try to cut corners by representing these things as special cases where the later components send data back to earlier ones, you end up introducing cycles in the data flow of your microservices. And then you're in for a world of hurt. It's better if you can represent it as a finite state machine, from the perspective of some coordinator component that's not part of the data flow itself. But that's a ton of work.
It complicates every service that deals with it, and it gets really messy to just manage the data stores to track the state. And if you have queues and batching and throttling and everything else, along with granular permissions... Things can break. And they can break in really horrible ways, like infinitely sending the same data to an external service because the components keep tossing an event back to each other.
There are general patterns -- like sagas, distributed transactions, and event-sourcing -- which can... kind of ease this problem. But they're fundamentally limited by the CAP Theorem. And there isn't a universally-accepted clean way to implement them, so you're pretty much doing it from scratch each time.
Don't get me wrong. Sometimes "Here's a token to check back later" and modeling interactions as a finite state machine rather than an all-or-nothing is the right call. Some interactions should work that way. But you should build them that way on purpose, not to work around the downsides of a cool buzzword you decided to play around with.