djupblue

>For example, to build shared threads like OpenAI’s, you might end up creating a new collection, a caching layer, or an index just to connect messages that logically belong together.

Which messages belongs together depends on the context and when you discover that the fancy thread store you built your app around can't return a list of MY messages without a full sequential scan of every single thread you'll wish you could solve it with an index.

Around 20 years ago when I was trying to decide on what database to use my requirement were that it should store data reliably. I learned that MySQL in contrast to PostgreSQL: 1. wasn't ACID 2. didn't have foreign key constraints 3. could loose/corrupt committed data (no WAL)

Despite me not knowing much about databases it seemed like an obvious choice.

Is there an example demonstrating what it looks like and how it works?

My problem with blockchains is that they AREN'T decentralized. If controlling a blockchain becomes valuable enough then it's a matter of time before someone will figure out how to profit from it and invest the required resources.

Decentralized in my mind means there is not one single source of truth.

So here's a challenge if anyone is up for it: Build a container orchestration engine that can run in 16MB of RAM on top of a Linux kernel.

Must have:

- Some form of networking (duh)

- Distributed state

- Distributed message queue (simple)

- Distributed scheduler

- Logging

Out of scope:

- Authorization/Authentication/Encryption

- REST/JSON/SSL/Web

The main reason I thought Russia's invasion of Ukraine wouldn't cross the line of being a convincing threat was how little off ramps it left everyone involved. It's going to be hard to come up with an off ramp for Putin that is also remotely acceptable to the Ukrainian people.

>President Volodymyr Zelensky might be prepared to formally renounce his pursuit of NATO membership

If Ukrainians feel they have convincingly defended themselves against Russia that might be possible. However, in 1994 Russia signed a Treaty promising not to use military force or economic coercion against Ukraine as a condition for Ukraine giving up it's nukes. With that and the last decade in mind Ukraine is unlikely to consider a signed paper sufficient safety. Outside of NATO's nuclear umbrella they'll need a military defense strong enough to defend against Russia on it's own.

>The difficulty comes with compromises that are not fair. Why should Ukraine not seek EU or NATO membership?

Ukrainians were divided between wanting to align more with EU or more with Russia but by trying to force Ukraine not to join EU through indiscriminate bombing Putin turned a bureaucratic process into an act of defiance against tyranny. Staying out of NATO is one thing but I don't think it's going to be politically possible to tell Ukraine they can't join EU.

It's not, the editor banning words is what's lazy. Banning certain words is a symbolic action that makes it harder to use precise language.

If their journalists are lazy how would banning words fix that? If they stop telling journalists what words they can and can't use then maybe they could attract better talent.

The lazy solution to a lazy problem

Yes you can build more wind and solar but people need power also during the dark and sometimes windless winter months. Storing enough power isn't currently feasible so it's basically either coal, gas or nuclear.

Oh no! Anyway..

Imagine sitting on a huge carousel spinning fast, like 100 times the speed of sound fast. Now imagine jumping off and trying to get to the center of it.

Yes, gravity is holding us back from yeeting of into space but to get closer to the sun you need to slow down. A lot. It takes way less rocket fuel to speed up enough to leave the solar system than to get to the sun.

Please ask them to write a regex that filters out those naughty base64 strings! Yes, "12345678" is a valid base64 string and so is "clueless".

In my experience dealing with code written by people who only know ORM:s is about as fun as dealing with code written by people who refuse to use ORM:s when they really should have. The latter like to prove they don't need an ORM by creating their own "simple" libraries full of half broken functionality that pretty soon turns into to the ORM:s from hell.

Oh, be aware that SQL is not universal. Especially not if you do anything remotely advanced like triggers, non-trivial indexes or select queries that returns complex types.

Adding an index on tags.name is likely not very useful on its own but adding an index with an uniqueness constraint to prevent duplicates is probably a good idea. Assuming there are just a few different tags records (<1000) then a sequential scan is generally either insignificantly slower or even faster than an index scan.

>Not the subsequent years of maintenance.

I'd much rather maintain this example than a code base replicating the same behavior without an ORM.