NyxWulf

I think generally you can still rely on that aspect, compared to the alternative of UUIDv1-4. Even the worst cases he mentioned would cause minimal page splitting problems in a database compared to even the best cases with UUIDv1-4. The biggest take away I got from the article is that there is some wiggle room in how things can be implemented in the UUIDv7 spec, and it's important to be aware of the implementations you are using.

Many schemes do exactly this, if all you are doing is single table inserts that works pretty well.

If you do anything that creates related records via foreign keys you start to run into lock contention. For example:

If your insert requires a parent record with a single child record, you have to get the next sequential id which involves a non-preemptable single threaded lock, increment it, and send it back to the connection which requested it. In most databases this would mean writing the parent record and getting the sequential id of the parent record back so you can set the foreign key reference on the child record. Stored procedures are one way to mitigate the network transit time, but they don't solve the single threaded lock acquisition time.

The reason most distributed systems use UUIDs or another flavor of distributed id is so you can generate the id for the parent record on the client, set the foreign key there as well, then send both records in as simple inserts. It's not that there aren't ways to work around it or mitigate it. Using a coordination free id, is just much easier to work with and scale in practice.

In my testing the primary bottleneck isn't about writing to the same partition. Lock coordination to increment the serial key, then send it back across a connection was the real culprit. Virtually all databases make updates into RAM and to a write ahead log, which is then spooled to disk in the background. No matter which pages are written or updated, the changes all go sequentially in order into the WAL. For me, getting rid of Serial Keys was the big hot spot in processing. YMMV.

The biggest advantage I've seen for UUID come with distributed systems imo. The ability to create an id without lock coordination allows for much easier horizontal scaling. UUIDv1 avoids the collision issue by using a portion of the MAC in the id, but v1-4 all have sorting issues. UUIDv7 is a good choice if your use case warrants it. If you can get away with a single integer field like a database primary key and not get bottlenecked that's much easier. When that doesn't work anymore one of the distributed id schemes like UUID are the only real options available.

It's not just index pages. Generally databases write records into pages, which are then grouped into extents. If the primary key gives an ordering you can create new pages and start filling them up in an orderly fashion. If it's random, you are doing random inserts into pages everywhere all the time, then you start running out of room in pages and have to start splitting them. UUIDv7 solves the most painful parts of this problem in general and is a much better option for a Primary Key than UUIDv1-4.

He did say murder is well covered in criminal law for that, but things not leading to murder like these AI cases are not.

The writing sounds like Claude to me

Recursive Self Improvement

Which models, and at what effort level?

The author didn't argue that you should never use radians, or tau. Just that for some use cases there is an alternative that is simpler using turns. Your argument can be true and his proposal can also be true, it just depends what your use case looks like.

Here is an excerpt from the system prompt for UltraCode (Same for Fable,Opus,Sonnet):

"Ultracode. When a system-reminder confirms ultracode is on, that opt-in is standing: author and run a workflow for every substantive task by default. The goal is the most exhaustive, correct answer you can produce — token cost is not a constraint."

Maybe I'm not understanding this, but how is it that you can know enough about the data to process it without undermining the fundamental concept of encryption? Isn't encrypted data supposed to be just random noise without the key? The more you know about the underlying data the easier it gets to decrypt? Does this mean someone can just steal your encrypted data and use that to steal your identity without even needing to decrypt it anymore?

The arrest/conviction generally follow the pulled over stopped rates. It's pretty hard to arrest/convict people you aren't stopping. These types of biases and stereo types are often pervasive within certain groups of people, including law enforcement, prosecutors, judges, and often the subset of the local community in power. If you've ever been to court (even traffic court) you'll find the word of the officer is given tremendous weight, while the word of the defendant is almost totally marginalized (no matter what your race). Even though you are "presumed innocent", the defendant has a natural incentive to lie and the officer presumably doesn't.

To top that off there is almost no "suitable oversight" of any police departments in the US of any kind, let alone by the community.

There really are no simple solutions to this, even places not plagued by bigotry and racism have major structural power problems for the average citizen.

People believe a lot of things, especially when the other side has power. The point is that people complain about how the power is used by the other side. When power switches sides, they don't roll that power back. They pretty much always leave it in place.

Both can be true, because the experience depends on the skill of the user. The article the other day here on HN that LLMs reward skill is my exact experience. If you are are good at what you are trying to use it for they can be a skill amplifier, and they are definitely getting much better rapidly for the work I do with them. At the same time people are complaining that they are getting dumber. Saying that both can't be true ignores the skill requirement to use them and the completely different perspectives of people using them.

Even if both aren't true, your evidence was people saying two opposing things. The truth (if there is a single objective truth on a given thing) has little bearing on whether or not different people agree on it.