What tells you that your brain is not a probabilistic machine?
1,416 karma · joined April 22, 2010
Or is the rulebook a simple rollback?
If this was fake, how do we know the robovans were not remotely operated? They might as well be too to get the stock price up?
There is no way to know. I am really doubting Tesla now. It wouldn’t surprise me that, in order to prevent mishaps during the event, everything is remotely operated…
People will say: that’s not true. But where did Tesla clearly specify this upfront?
I saw the initial fullscreen disclaimer. But that might also apply to the robovans right?
However for our use case we want total control over the server database. And wanted to store it in normalized tables.
The solution we went for us is streaming the mutation stream (basically the WAL) from/to client and server. And use table stream duality to store them in a table.
Permissions are handled on a table level.
When a client writes it sends a mutation to the servers. Or queues it locally if offline. Writes never conflict: we employ a CRDT “last write wins” policy.
Queries are represented by objects and need to be implemented both in Postgres as wel as SQLLite (if you want offline querying, often we don’t). A query we implement for small tables is: “SELECT *”.
Note that the result set being queried is updated realtime for any mutation coming in.
It’s by default not enforcing relational constraints on the clientside so no rollbacks needed.
However you can set a table in different modes: - online synchronous writes only: allows us to have relational constraints. And to validate the creation against other server only business rules.
The tech stack is Kotlin on client (KMM) and server, websocket for streaming. Kafka for all mutations messaging. And vanilla Postgres for storing.
The nice thing is that we now have a Kafka topic that contains all mutations that we can listen to. For example to send emails or handle other use cases.
For every table you: - create a serializable Kotlin data class - create a Postgres table on the server - implement reading and writing that data, and custom queries
Done: the apps have offline support for reading a single entity and upserts. Querying require to be online if not implemented on the client.
"We expect all of these will improve, likely dramatically, in future versions with the inclusion of multi-modal models and as the underlying foundation models"
So much hype, so much believe. I no believe no hype
For existing companies with AI features: more useful but mostly LLM bolted on with the same use cases. They can improve the product if used right. But for me it’s mostly often just a gimmick.
The problem with LLMs: They mostly generate stuff they have seen and are bad as truly new stuff. They make mistakes You need to put time and energy in the review it.
For stuff that transforms data it’s useful. Like rewriting a piece of text.
It’s also useful for search queries on the corpus the LLM is trained on.
It’s good at pattern recognition and lastly: human like voice interfaces.
But for generating novel stuff: good luck reviewing it.
People who just blindly copy paste the output of an LLM: that’s quite dangerous and potentially plain wrong.
At least that’s my experience.
- I got it to generate invalid SQL resulting in errors - it merely generates reasonable SQL, but in my case it generated to disjoint set of tables…. - In practice you have tot review all code - It can point you into the wrong direction. Novel systems often have something smart/abstract in there. This system creates mostly Straightforward simple systems. That’s not where the value is
All in all, it’s not worth it to me. Writing code myself is easier than having to review LLM code
Within our organization we have forbidden full LLM merge request because more often than not the code was suboptimal. And had sneaky bugs/mistakes.
I’m not saying these can’t be overcome. But not with current LLM design. They mostly generate stuff they have seen and are bad as truly new stuff.
I still get invited for drinking. I still join parties. I still act crazy. Just without the bad side effects.
Note: going to a dance party the whole night still gives you a hangover. But because you were active. Not because of the alcohol. It’s less extreme.
A solution is slow rollout. Not a manual deploy button
So he reversed engineered it, but its still secure: You need the token.
If you use only uuid in your outwards facing api then you still have the problem of slow queries. Since you need them to find the object (as mentioned below)
UUIDv7 has a random part, can be created distributedly, and indexes well.
It’s the best choice for modern application that support distributed data creation.
To survive is to predict the future better than the other animal. Survival of the fittest.
Thats the whole eureka thing to understand... To compress well, you need to understand. To predict the next word, you need to undestand the world.
Ilya explains it here: https://youtu.be/GI4Tpi48DlA?t=1053
https://innovationorigins.com/en/dutch-flying-car-soars-with...
Things like vertical food farms, huge greenhouses, intensive farming help us become (one of) the biggest
- milk and milk powder producer - apples (apples in South Africa are likely to come from the Netherlands) - tomato’s in Spain come from the Netherlands
Etc etc.
We had a customer k8s cluster per feature branch with e2e testing.
A middle ground is testcontainers for feature branches, and the trunk branch a full e2e suite deployed to a live cluster...
Test containers provide a middle ground.
For example we have pure unit tests. But also some tests that boot up Postgres. Test the db migration and gives you a db to play with for your specific “unit” test test case.
No need for a complete environment with Kafka etc. It provides a cost effective stepping stone to what you describe.
What would be nice if test containers could create a complete environment, on the test machine and delete it again.
Still a deploy with some smoke tests on a real env are nice.
In the end anything can be represented as a structured log.
A span is NOT what the OP calls a “system wide event”. A span has a begin and end time. What he/she describes doesn’t have that.
In the end giving different kind of instrumentation instruments a name makes sense, mainly for processing them / rendering them / altering on them.
In my experience LLM are smart but sometimes inconsistent and over a long chat it might say things that are logically self contradictions… when you tell it that it confirms it.
It just seems like it lacks a consistent world view.
I don’t trust them yet. Maybe with even more scale they become better.
They act a little bit like young children, with a lot of domain knowledge.